Re: [PATCH] dt-bindings: i2c: Use correct vendor prefix for Atmel

[Thierry Reding]

On Fri, Nov 23, 2018 at 12:40:19PM +, Peter Rosin wrote:
> On 2018-11-23 13:10, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > The "at," prefix was never correct for Atmel, so fix the few occurrences
> > that got it wrong. Use "atmel," instead.
> 
> Fully agreed. However, given that atmel,24c08 is documented in 
> .../eeprom/at24.txt
> I think it would be better to remove at,24c08 from trivial-devices.txt

Good point, will respin.

Thanks,
Thierry


signature.asc
Description: PGP signature

Re: [PATCH 1/2] module: Overwrite st_size instead of st_info

[Miroslav Benes]

On Thu, 22 Nov 2018, Jessica Yu wrote:

> +++ Vincent Whitchurch [22/11/18 13:24 +0100]:
> >On Thu, Nov 22, 2018 at 12:01:54PM +, Dave Martin wrote:
> >> On Mon, Nov 19, 2018 at 05:25:12PM +0100, Vincent Whitchurch wrote:
> >> > st_info is currently overwritten after relocation and used to store the
> >> > elf_type().  However, we're going to need it fix kallsyms on ARM's
> >> > Thumb-2 kernels, so preserve st_info and overwrite the st_size field
> >> > instead.  st_size is neither used by the module core nor by any
> >> > architecture.
> >> >
> >> > Signed-off-by: Vincent Whitchurch 
> >> > ---
> >> > v4: Split out to separate patch.  Use st_size instead of st_other.
> >> > v1-v3: See PATCH 2/2
> >> >
> >> >  kernel/module.c | 4 ++--
> >> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/kernel/module.c b/kernel/module.c
> >> > index 49a405891587..3d86a38b580c 100644
> >> > --- a/kernel/module.c
> >> > +++ b/kernel/module.c
> >> > @@ -2682,7 +2682,7 @@ static void add_kallsyms(struct module *mod, const
> >> > struct load_info *info)
> >> >
> >> >   /* Set types up while we still have access to sections. */
> >> >   for (i = 0; i < mod->kallsyms->num_symtab; i++)
> >> > -mod->kallsyms->symtab[i].st_info
> >> > +mod->kallsyms->symtab[i].st_size
> >> > = elf_type(>kallsyms->symtab[i], info);
> >> >
> >> >  /* Now populate the cut down core kallsyms for after init. */
> >> > @@ -4061,7 +4061,7 @@ int module_get_kallsym(unsigned int symnum,
> >> > unsigned long *value, char *type,
> >> >kallsyms = rcu_dereference_sched(mod->kallsyms);
> >> >if (symnum < kallsyms->num_symtab) {
> >> >  *value = kallsyms->symtab[symnum].st_value;
> >> > -*type = kallsyms->symtab[symnum].st_info;
> >> > +*type = kallsyms->symtab[symnum].st_size;
> >> > strlcpy(name, symname(kallsyms, symnum), KSYM_NAME_LEN);
> >> > strlcpy(module_name, mod->name, MODULE_NAME_LEN);
> >> > *exported = is_exported(name, *value, mod);
> >>
> >> This is fine if st_size is really unused, but how sure are you of that?
> >>
> >> grepping for st_size throws up some hits that appear ELF-related, but
> >> I've not investigated them in detail.
> >>
> >> (The fact that struct stat has an identically named field throws up
> >> a load of false positives too.)
> >
> >$ git describe --tags
> >v4.20-rc3-93-g92b419289cee
> >
> >$ rg -m1 '[\.>]st_size'  --iglob '!**/tools/**' --iglob '!**/vdso*' --iglob
> >'!**/scripts/**' --iglob '!**/usr/**' --iglob '!**/samples/**' | cat
> >| kernel/kexec_file.c:   if (sym->st_size != size) {
> >
> >Symbols in kexec kernel.
> >
> >| fs/stat.c: tmp.st_size = stat->size;
> >| Documentation/networking/tls.txt:  sendfile(sock, file, ,
> >| stat.st_size);
> >| net/9p/client.c:   ret->st_rdev, ret->st_size, ret->st_blksize,
> >| net/9p/protocol.c: >st_rdev,
> >| >st_size,
> >| fs/9p/vfs_inode_dotl.c:i_size_write(inode, stat->st_size);
> >| fs/hostfs/hostfs_user.c:   p->size = buf->st_size;
> >| arch/powerpc/boot/mktree.c:nblks = (st.st_size + IMGBLK) / IMGBLK;
> >| arch/alpha/kernel/osf_sys.c:   tmp.st_size = lstat->size;
> >| arch/x86/ia32/sys_ia32.c:  __put_user(stat->size, >st_size) ||
> >
> >Not Elf_Sym.
> >
> >| arch/x86/kernel/machine_kexec_64.c: sym->st_size);
> >
> >Symbols in kexec kernel.
> >
> >| arch/sparc/boot/piggyback.c:   st4(buffer + 12, s.st_size);
> >| arch/sparc/kernel/sys_sparc32.c:   err |= put_user(stat->size,
> >| >st_size);
> >| arch/um/os-Linux/file.c:   .ust_size= src->st_size,/*
> >| total size, in bytes */
> >| arch/um/os-Linux/start_up.c:   size = (buf.st_size + 
> >UM_KERN_PAGE_SIZE) &
> >| ~(UM_KERN_PAGE_SIZE - 1);
> >| arch/s390/kernel/compat_linux.c:   tmp.st_size = stat->size;
> >| arch/arm/kernel/sys_oabi-compat.c: tmp.st_size = stat->size;
> >| arch/mips/boot/compressed/calc_vmlinuz_load_addr.c:vmlinux_size =
> >| (uint64_t)sb.st_size;
> >| drivers/net/ethernet/marvell/sky2.c:   hw->st_idx =
> >| RING_NEXT(hw->st_idx, hw->st_size);
> >
> >Not Elf_Sym.
> 
> [ added Miroslav to CC, just in case he would like to check :) ]
> 
> I have just double checked as well, and am fairly certain that the
> Elf_Sym st_size field is not used to apply module relocations in any
> arches, and it is not used in the core module loader nor in the module
> kallsyms code. We'd like to avoid overwriting st_info in any case, to
> fix kallsyms on Thumb-2 and also so that livepatch won't run into any
> issues with delayed relocations, should livepatch support ever expand
> to arches (e.g., arm) that rely on st_info for module relocations.

I checked and came to the same conclusion.

Regards,
Miroslav

Re: [PATCH v1] mm/memory_hotplug: drop "online" parameter from add_memory_resource()

[David Hildenbrand]

On 23.11.18 13:54, Michal Hocko wrote:
> On Fri 23-11-18 13:37:40, David Hildenbrand wrote:
>> User space should always be in charge of how to online memory and
>> if memory should be onlined automatically in the kernel. Let's drop the
>> parameter to overwrite this - XEN passes memhp_auto_online, just like
>> add_memory(), so we can directly use that instead internally.
> 
> Heh, I wanted to get rid of memhp_auto_online so much and now we have it
> in the core memory_hotplug. Not a win on my side I would say :/

That is actually a good point: Can we remove memhp_auto_online or is it
already some sort of kernel ABI?

(as it is exported via /sys/devices/system/memory/auto_online_blocks)

> On the other hand this can be seen as a cleanup because it removes that
> ambiguity that some callers might be unaware of the memhp_auto_online
> leading to a different behavior.

I would say this patch is a step into the right direction - remove the
flag from the interfaces, then drop it (eventually, as stated not sure
if that train has left the station).

> 
>> Cc: Boris Ostrovsky 
>> Cc: Juergen Gross 
>> Cc: Stefano Stabellini 
>> Cc: Andrew Morton 
>> Cc: Dan Williams 
>> Cc: Oscar Salvador 
>> Cc: Pavel Tatashin 
>> Cc: Michal Hocko 
>> Cc: David Hildenbrand 
>> Cc: Joonsoo Kim 
>> Cc: Arun KS 
>> Cc: Mathieu Malaterre 
>> Cc: Stephen Rothwell 
>> Signed-off-by: David Hildenbrand 
> 
> Acked-by: Michal Hocko 
> 


-- 

Thanks,

David / dhildenb

Re: [RFC PATCH v4 1/5] glibc: Perform rseq(2) registration at nptl init and thread creation

[Florian Weimer]

* Rich Felker:

>> I'm not entirely sure because the glibc terminology is confusing, but I
>> think it places intial-exec TLS into the static TLS area (so that it has
>> a fixed offset from the TCB).  The static TLS area is placed on the
>> user-supplied stack.
>
> This is an implementation detail that should not leak to applications,
> and I believe it's still considered a bug, in that, with large static
> TLS, it could overflow or leave unusably little space left on an
> otherwise-plenty-large application-provided stack.

Sure, but that does not matter in this context because right now, there
is no fix for this bug, and when we fix it, we can take backwards
compatibility into account.

Any library that ends up using rseq will need to coordinate with the
toolchain.  I think that's unavoidable given the kernel interface.

>> > One issue here is that early adopter libraries cannot always use
>> > the IE model. I tried using it for other TLS variables in lttng-ust, and
>> > it ended up hanging our CI tests when tracing a sample application with
>> > lttng-ust under a Java virtual machine: being dlopen'd in a process that
>> > possibly already exhausts the number of available backup TLS IE entries
>> > seems to have odd effects. This is why I'm worried about using the IE model
>> > within lttng-ust.
>> 
>> You can work around this by preloading the library.  I'm not sure if
>> this is a compelling reason not to use initial-exec TLS memory.
>
> Use of IE model from a .so file (except possibly libc.so or something
> else that inherently needs to be present at program startup for other
> reasons) should be a considered a bug and unsupported usage.
> Encouraging libraries to perpetuate this behavior is going backwards
> on progress that's being made to end it.

Why?  Just because glibc's TCB allocation strategy is problematic?
We can fix that, even with dlopen.

If you are only concerned about the interactions with dlopen, then why
do you think initial-exec TLS is the problem, and not dlopen?

>> > The per-thread reference counter is a way to avoid issues that arise from
>> > lack of destructor ordering. Is it an acceptable approach for you, or
>> > you have something else in mind ?
>> 
>> Only for the involved libraries.  It will not help if other TLS
>> destructors run and use these libraries.
>
> Presumably they should have registered their need for rseq too,
> thereby incrementing the reference count. I'm not sure this is a good
> idea, but I think I understand it now.

They may have to increase the reference count from 0 to 1, though, so
they have to re-register the rseq area.  This tends to get rather messy.

I still I think implicit destruction of the rseq area is preferable over
this complexity.

Thanks,
Florian

Re: [PATCH 3/3] gpio: Add reference counting for non-exclusive GPIOs

[Mark Brown]

On Fri, Nov 23, 2018 at 10:57:29AM +, Charles Keepax wrote:

> It's fixing something in the case of two regulators using the
> same GPIO. The direction this patch chain takes is that the end
> drivers own the GPIOs not the regulator core (except for the
> legacy case). So both of the end drivers will devm_ request their

The situation with descriptor based GPIOs is a bug - the reason why the
core does the request in the legacy case is precisely the problem Linus
identified.  Once a GPIO is shared all the users of the GPIO need to
coordinate with each other in order to set the value so the refcount by
itself in the GPIO core isn't super useful unless it can also serve to
help the multiple users find each other somehow.  I think what we want
to do here is either push the gpiod requests into the regulator core or
change things so that once the regulator is registered with the
regulator core the regulator core owns and is responsible for freeing
the regulator.


signature.asc
Description: PGP signature

Re: [PATCH] printk: Make printk_emit() local function.

[Tetsuo Handa]

On 2018/11/23 21:24, Petr Mladek wrote:
> On Thu 2018-11-22 23:59:28, Tetsuo Handa wrote:
>> printk_emit() is called from only devkmsg_write() in the same file.
>> Save object size by making it a local function.
>>
>> Signed-off-by: Tetsuo Handa 
>> ---
>>  include/linux/printk.h |  5 -
>>  kernel/printk/printk.c | 31 +++
>>  2 files changed, 15 insertions(+), 21 deletions(-)
>>
>> --- a/kernel/printk/printk.c
>> +++ b/kernel/printk/printk.c
>> @@ -752,6 +752,20 @@ struct devkmsg_user {
>>  char buf[CONSOLE_EXT_LOG_MAX];
>>  };
>>  
>> +static __printf(3, 4) __cold int devkmsg_emit(int facility, int level,
>> +  const char *fmt, ...);
> 
> There is no need for the forward declaration. __printf(3, 4)
> and __cold could be part of the function definition.
> Or do I miss anything?

If you meant below one, it fails with "error: expected ',' or ';' before '{' 
token".
Attributes annotation needs to be done as the prototype definition.
(Though I don't know whether __cold here makes sense...)

static int devkmsg_emit(int facility, int level, const char *fmt, ...)
__printf(3, 4) __cold
{
va_list args;
int r;

va_start(args, fmt);
r = vprintk_emit(facility, level, NULL, 0, fmt, args);
va_end(args);

return r;
}

Re: [RFC PATCH v4 1/5] glibc: Perform rseq(2) registration at nptl init and thread creation

[Florian Weimer]

* Mathieu Desnoyers:

 I don't think you need unregistering if the memory is initial-exec TLS
 memory.  Initial-exec TLS memory is tied directly to the TCB and cannot
 be freed while the thread is running, so it should be safe to put the
 rseq area there even if glibc knows nothing about it.
>>>
>>> Is it true for user-supplied stacks as well ?
>> 
>> I'm not entirely sure because the glibc terminology is confusing, but I
>> think it places intial-exec TLS into the static TLS area (so that it has
>> a fixed offset from the TCB).  The static TLS area is placed on the
>> user-supplied stack.
>
> You said earlier in the email thread that user-supplied stack can be
> reclaimed by __free_tcb () while the thread still runs, am I correct ?
> If so, then we really want to unregister the rseq TLS before that.

No, dynamic TLS can be reclaimed.  Static TLS (which I assume includes
initial-exec TLS) is not deallocated.

> I notice that __free_tcb () calls __deallocate_stack (), which invokes
> _dl_deallocate_tls (). Accessing the TLS from the kernel upon preemption
> would appear fragile after this call.

_dl_deallocate_tls only covers dynamic TLS.

Thanks,
Florian

Re: [PATCH V2] exportfs: do not read dentry after free

[Al Viro]

On Fri, Nov 23, 2018 at 03:56:33PM +0800, Pan Bian wrote:
> The function dentry_connected calls dput(dentry) to drop the previously
> acquired reference to dentry. In this case, dentry can be released.
> After that, IS_ROOT(dentry) checks the condition
> (dentry == dentry->d_parent), which may result in a use-after-free bug.
> This patch directly compares dentry with its parent obtained before
> dropping the reference.

It's a bit more subtle than the description implies (the race has
dentry connected during dget_parent() and the child we'd reached it
through moved elsewhere during the dput()), but you are right - the
race is there and that patch fixes it.

I wonder if we could avoid those dget_parent()/dput() completely -
looks like we might be able to with rcu_read_lock() and some
care.  OTOH, that's not going to be a hot path, anyway...

Applied.

Re: [PATCH v2 2/4] clk: meson: clk-regmap: add read-only gate ops

[Neil Armstrong]

On 22/11/2018 22:40, Martin Blumenstingl wrote:
> Some of the gate clocks are described as "just in case" bits in the
> datasheet. Examples are the ABP, PERIPH, AXI and L2 DRAM clocks on
> Meson8b.
> The datasheet suggests that these bits are not touched. The full
> explanation is:
> "Set to 1 to manually disable the [...] clock when changing the mux
> selection. Typically this bit is set to 0 since the clock muxes can
> switch without glitches.".
> 
> This adds new read-only ops for gate clocks so we can describe these
> clocks in our clock controller drivers while ensuring that we can't
> accidentally modify the registers.
> 
> Signed-off-by: Martin Blumenstingl 
> ---
>  drivers/clk/meson/clk-regmap.c | 5 +
>  drivers/clk/meson/clk-regmap.h | 1 +
>  2 files changed, 6 insertions(+)
> 
> diff --git a/drivers/clk/meson/clk-regmap.c b/drivers/clk/meson/clk-regmap.c
> index 305ee307c003..c515f67322a3 100644
> --- a/drivers/clk/meson/clk-regmap.c
> +++ b/drivers/clk/meson/clk-regmap.c
> @@ -50,6 +50,11 @@ const struct clk_ops clk_regmap_gate_ops = {
>  };
>  EXPORT_SYMBOL_GPL(clk_regmap_gate_ops);
>  
> +const struct clk_ops clk_regmap_gate_ro_ops = {
> + .is_enabled = clk_regmap_gate_is_enabled,
> +};
> +EXPORT_SYMBOL_GPL(clk_regmap_gate_ro_ops);
> +
>  static unsigned long clk_regmap_div_recalc_rate(struct clk_hw *hw,
>   unsigned long prate)
>  {
> diff --git a/drivers/clk/meson/clk-regmap.h b/drivers/clk/meson/clk-regmap.h
> index ed2d4348dbe2..e9c5728d40eb 100644
> --- a/drivers/clk/meson/clk-regmap.h
> +++ b/drivers/clk/meson/clk-regmap.h
> @@ -51,6 +51,7 @@ clk_get_regmap_gate_data(struct clk_regmap *clk)
>  }
>  
>  extern const struct clk_ops clk_regmap_gate_ops;
> +extern const struct clk_ops clk_regmap_gate_ro_ops;
>  
>  /**
>   * struct clk_regmap_div_data - regmap backed adjustable divider specific 
> data
> 

Acked-by: Neil Armstrong 

Re: [for-next][PATCH 15/18] function_graph: Use new curr_ret_depth to manage depth instead of curr_ret_stack

[Steven Rostedt]

On Thu, 22 Nov 2018 11:03:22 +0100
Peter Zijlstra  wrote:

> On Wed, Nov 21, 2018 at 07:28:16PM -0500, Steven Rostedt wrote:
> > @@ -188,14 +186,20 @@ int function_graph_enter(unsigned long ret, unsigned 
> > long func,
> > struct ftrace_graph_ent trace;
> >  
> > trace.func = func;
> > -   trace.depth = current->curr_ret_stack + 1;
> > +   trace.depth = ++current->curr_ret_depth;
> >  
> > /* Only trace if the calling function expects to */
> > if (!ftrace_graph_entry())
> > -   return -EBUSY;
> > +   goto out;
> >  
> > -   return ftrace_push_return_trace(ret, func, ,
> > -   frame_pointer, retp);
> > +   if (ftrace_push_return_trace(ret, func,
> > +frame_pointer, retp))  
> 
> You can unwrap that line, by my counting that's at 69 chars, so unless
> you're editing on a C64 it should fit your screen.

Thanks I may add a clean up patch. I already ran this code under
several hours of testing, and only plan on touching it if there's more
than cosmetic issues.

The reason that looks like that is because I just massaged the line it
replaced, and didn't take into account that I could now make it into a
single line.

> 
> > +   goto out;
> > +
> > +   return 0;
> > + out:
> > +   current->curr_ret_depth--;
> > +   return -EBUSY;
> >  }  
> 
> [diff "default"]
>   xfuncname = "^[[:alpha:]$_].*[^:]$"
> 
> avoids the need for that ludicrous label indenting.

I still prefer the 'space', and it fits with the rest of the file ;-)

TomAYto / TomAHto

> 
> Also, "error" might be a better label name.

True. I'll add that on top too, but for the stable/rc release, that
isn't needed.

Thanks for taking a look at this code.

-- Steve

Re: [PATCH 2/3] regulator: Only free GPIOs if the core requested them

[Mark Brown]

On Thu, Nov 22, 2018 at 05:30:14PM +, Charles Keepax wrote:
> Currently, the regulator core will take ownership of any GPIO passed
> into it. Makes end driver code fairly error prone as the normal devm_
> patterns of allocation don't work. Update the regulator core to only
> free the GPIO if it requested it, this allows the drivers to manage the
> GPIO lifetime as they normally would.

I think this is fine in conjunction with patch 3 in that adding that
patch sorts out the double free problems with shared regulators but
without that pushing the GPIO management into the individual regulator
drivers is going to create trouble as something needs to coordinate to
make sure that we only free when the last user is gone.

However even with patch 3 I think it'd be better to base this off the
rest of Linus' series for converting to descriptors (which is currently
sitting waiting for some more testing) since that will convert
everything to descriptors and so remove the code that's doing requests
in the core entirely.


signature.asc
Description: PGP signature

Re: [PATCH V3 5/5] arm64/mm: Enable HugeTLB migration for contiguous bit HugeTLB pages

[Catalin Marinas]

On Tue, Oct 23, 2018 at 06:32:01PM +0530, Anshuman Khandual wrote:
> Let arm64 subscribe to the previously added framework in which architecture
> can inform whether a given huge page size is supported for migration. This
> just overrides the default function arch_hugetlb_migration_supported() and
> enables migration for all possible HugeTLB page sizes on arm64. With this,
> HugeTLB migration support on arm64 now covers all possible HugeTLB options.
> 
> CONT PTEPMDCONT PMDPUD
> ------
> 4K:64K  2M32M  1G
> 16K:2M 32M 1G
> 64K:2M512M16G
> 
> Reviewed-by: Naoya Horiguchi 
> Signed-off-by: Anshuman Khandual 

Acked-by: Catalin Marinas 

Re: [PATCH V3 4/5] arm64/mm: Enable HugeTLB migration

[Catalin Marinas]

On Tue, Oct 23, 2018 at 06:32:00PM +0530, Anshuman Khandual wrote:
> Let arm64 subscribe to generic HugeTLB page migration framework. Right now
> this only works on the following PMD and PUD level HugeTLB page sizes with
> various kernel base page size combinations.
> 
>CONT PTEPMDCONT PMDPUD
>------
> 4K: NA 2M NA  1G
> 16K:NA32M NA
> 64K:NA   512M NA
> 
> Reviewed-by: Naoya Horiguchi 
> Signed-off-by: Anshuman Khandual 

Acked-by: Catalin Marinas 

Re: [PATCH 4/6] clk: mvebu: ap806: Fix clock name for the cluster

[Gregory CLEMENT]

Hi Stephen,
 
 On mer., oct. 17 2018, Stephen Boyd  wrote:

> Quoting Gregory CLEMENT (2018-09-22 11:17:07)
>> Actually, the clocks exposed for the cluster are not the CPU clocks, but
>> the PLL clock used as entry clock for the CPU clocks. The CPU clock will
>> be managed by a driver submitting in the following patches.
>> 
>> Signed-off-by: Gregory CLEMENT 
>
> Does this need a fixes tag?

It doesn't fix a regression so I don't thing it needs a fixes tag.

Gregory

>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com

Re: [PATCH 02/11] mfd: da9055-core: make it explicitly non-modular

[Paul Gortmaker]

[Re: [PATCH 02/11] mfd: da9055-core: make it explicitly non-modular] On 
22/11/2018 (Thu 22:14) Paul Gortmaker wrote:

> [Re: [PATCH 02/11] mfd: da9055-core: make it explicitly non-modular] On 
> 23/11/2018 (Fri 10:21) kbuild test robot wrote:
> 

[...]

> > 
> > All errors (new ones prefixed by >>):
> > 
> >drivers/mfd/da9055-i2c.o: In function `da9055_i2c_remove':
> > >> drivers/mfd/da9055-i2c.c:53: undefined reference to `da9055_device_exit'
> 
> Thanks for the report -- I'll look into what causes it, why my testing
> didn't see it, and get an update to Lee as soon as possible.

OK, mystery solved.  I chose this smaller subset of MFD "simple" patches
from my pending queue of MFD patches - to create a reasonable sized
maintainer-friendly send, based on patches with zero runtime changes.

My other pending MFD patches have a trivial runtime behavior change;
deleting a ".remove" field/function - that will never be used for a
non-module case, but in theory could be (pointlessly) triggered by
forcing a driver unbind.  (see mainline 98b72b94def9 as an example)
Patches like this were left behind for a future send batch.

Unfortunately that allowed me to overlook the fact that patch #2 link
depended on the below ".remove" patch (not sent) to be applied 1st.

Lee, what would you like to have happen?  I can resend the queue with
this patch, or I can resend with #2 being temporarily deferred until
a future patch batch that has the below da9055-i2c in it, or ...

Whatever is easiest for you - let me know.

Paul.
--

>From da28030dbcdcd5cb4807ad18dfa6fd4773719ad0 Mon Sep 17 00:00:00 2001
From: Paul Gortmaker 
Date: Sun, 6 Sep 2015 22:10:34 -0400
Subject: [PATCH] mfd: da9055-i2c: Make it explicitly non-modular

The Makefile/Kconfig currently controlling compilation of this code is:

drivers/mfd/Makefile:da9055-objs := da9055-core.o da9055-i2c.o
drivers/mfd/Makefile:obj-$(CONFIG_MFD_DA9055)   += da9055.o

...meaning that it currently is not being built as a module by anyone.

Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.

We explicitly disallow a driver unbind, since that doesn't have a
sensible use case anyway, and it allows us to drop the ".remove"
code for non-modular drivers.

Since module_init was not in use by this code, the init ordering
remains unchanged with this commit.

Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.

We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.

Cc: Support Opensource 
Cc: Lee Jones 
Cc: David Dajun Chen 
Signed-off-by: Paul Gortmaker 

diff --git a/drivers/mfd/da9055-i2c.c b/drivers/mfd/da9055-i2c.c
index b53e100f577c..7c66f82522f0 100644
--- a/drivers/mfd/da9055-i2c.c
+++ b/drivers/mfd/da9055-i2c.c
@@ -11,7 +11,7 @@
  *
  */
 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -46,15 +46,6 @@ static int da9055_i2c_probe(struct i2c_client *i2c,
return da9055_device_init(da9055);
 }
 
-static int da9055_i2c_remove(struct i2c_client *i2c)
-{
-   struct da9055 *da9055 = i2c_get_clientdata(i2c);
-
-   da9055_device_exit(da9055);
-
-   return 0;
-}
-
 /*
  * DO NOT change the device Ids. The naming is intentionally specific as both
  * the PMIC and CODEC parts of this chip are instantiated separately as I2C
@@ -66,7 +57,6 @@ static struct i2c_device_id da9055_i2c_id[] = {
{"da9055-pmic", 0},
{ }
 };
-MODULE_DEVICE_TABLE(i2c, da9055_i2c_id);
 
 static const struct of_device_id da9055_of_match[] = {
{ .compatible = "dlg,da9055-pmic", },
@@ -75,11 +65,11 @@ static const struct of_device_id da9055_of_match[] = {
 
 static struct i2c_driver da9055_i2c_driver = {
.probe = da9055_i2c_probe,
-   .remove = da9055_i2c_remove,
.id_table = da9055_i2c_id,
.driver = {
.name = "da9055-pmic",
.of_match_table = of_match_ptr(da9055_of_match),
+   .suppress_bind_attrs = true,
},
 };
 
@@ -96,13 +86,3 @@ static int __init da9055_i2c_init(void)
return 0;
 }
 subsys_initcall(da9055_i2c_init);
-
-static void __exit da9055_i2c_exit(void)
-{
-   i2c_del_driver(_i2c_driver);
-}
-module_exit(da9055_i2c_exit);
-
-MODULE_AUTHOR("David Dajun Chen ");
-MODULE_DESCRIPTION("I2C driver for Dialog DA9055 PMIC");
-MODULE_LICENSE("GPL");
-- 
2.8.0

[PATCH] clk: tegra: Change to use DEFINE_SHOW_ATTRIBUTE macro

[Yangtao Li]

Use macro to simplify the code.

Signed-off-by: Yangtao Li 
---
 drivers/clk/tegra/clk-dfll.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/clk/tegra/clk-dfll.c b/drivers/clk/tegra/clk-dfll.c
index ebb0e1b6bf01..609e363dabf8 100644
--- a/drivers/clk/tegra/clk-dfll.c
+++ b/drivers/clk/tegra/clk-dfll.c
@@ -1184,17 +1184,7 @@ static int attr_registers_show(struct seq_file *s, void 
*data)
return 0;
 }
 
-static int attr_registers_open(struct inode *inode, struct file *file)
-{
-   return single_open(file, attr_registers_show, inode->i_private);
-}
-
-static const struct file_operations attr_registers_fops = {
-   .open   = attr_registers_open,
-   .read   = seq_read,
-   .llseek = seq_lseek,
-   .release= single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(attr_registers);
 
 static void dfll_debug_init(struct tegra_dfll *td)
 {
-- 
2.17.0

Re: [PATCH] dmaengine: ti: omap-dma: Configure LCH_TYPE for OMAP1

[Russell King - ARM Linux]

On Fri, Nov 23, 2018 at 02:35:04PM +0200, Peter Ujfalusi wrote:
> > Also we can't deal with the omap_set_dma_dest_burst_mode() setting -
> > DMAengine always uses a 64 byte burst, but udc wants a smaller burst
> > setting.  Does this matter?
> 
> The tusb also fiddled with the burst before the conversion, I believe
> what the DMAengine driver is doing should be fine. If not then we fix it
> while converting the omap_udc.

That's good news, so I can ignore that difference.

> > I'm also not sure about this:
> > 
> > if (cpu_is_omap15xx())
> > end++;
> > 
> > in dma_dest_len() - is that missing from the omap-dma driver?  It looks
> > like a work-around for some problem on OMAP15xx, but I can't make sense
> > about why it's in the UDC driver rather than the legacy DMA driver.
> 
> afaik no other legacy drivers were doing similar thing, this must be
> something which is needed for the omap_udc driver to fix up something?
> 
> > 
> > I'm also confused by:
> > 
> > end |= start & (0x << 16);
> > 
> > also in dma_dest_len() - omap_get_dma_dst_pos() returns in the high 16
> > bits the full address:
> > 
> > if (dma_omap1())
> > offset |= (p->dma_read(CDSA, lch) & 0x);
> 
> CDSA is OMAP_DMA_REG_2X16BIT for omap1
> The CPC/CDAC holds the LSB of the _current_ DMA pointer. The code gets
> the MSB of the address from the CDSA registers.
> 
> > 
> > so if the address crosses a 64k physical address boundary, surely orring
> > in the start address is wrong?  The more I look at dma_dest_len(), the
> > more I wonder whether that and dma_src_len() are anywhere near correct,
> > and whether that is a source of breakage for Aaro.
> 
> Hrm, again... the position reporting on OMAP1 is certainly not something
> I would put my life on :o

My feeling is - if the code in plat-omap/dma.c doesn't work, we've got
the same problems in the dmaengine driver, so the reported residue will
be wrong.  Any workarounds need to be within the dmaengine driver, not
in individual drivers.  We can't just go subtracting 1 from the residue
reported by dmaengine.

> > diff --git a/drivers/usb/gadget/udc/omap_udc.c 
> > b/drivers/usb/gadget/udc/omap_udc.c
> > index 3a16431da321..a37e1d2f0f3e 100644
> > --- a/drivers/usb/gadget/udc/omap_udc.c
> > +++ b/drivers/usb/gadget/udc/omap_udc.c
> > @@ -204,6 +204,7 @@ static int omap_ep_enable(struct usb_ep *_ep,
> > ep->dma_channel = 0;
> > ep->has_dma = 0;
> > ep->lch = -1;
> > +   ep->dma = NULL;
> > use_ep(ep, UDC_EP_SEL);
> > omap_writew(udc->clr_halt, UDC_CTRL);
> > ep->ackwait = 0;
> > @@ -576,21 +577,49 @@ static void finish_in_dma(struct omap_ep *ep, struct 
> > omap_req *req, int status)
> >  static void next_out_dma(struct omap_ep *ep, struct omap_req *req)
> >  {
> > unsigned packets = req->req.length - req->req.actual;
> > -   int dma_trigger = 0;
> > +   struct dma_async_tx_descriptor *tx;
> > +   struct dma_chan *dma = ep->dma;
> > +   dma_cookie_t cookie;
> > u16 w;
> >  
> > -   /* set up this DMA transfer, enable the fifo, start */
> > -   packets /= ep->ep.maxpacket;
> > -   packets = min(packets, (unsigned)UDC_RXN_TC + 1);
> > +   packets = min_t(unsigned, packets / ep->ep.maxpacket, UDC_RXN_TC + 1);
> > req->dma_bytes = packets * ep->ep.maxpacket;
> > -   omap_set_dma_transfer_params(ep->lch, OMAP_DMA_DATA_TYPE_S16,
> > -   ep->ep.maxpacket >> 1, packets,
> > -   OMAP_DMA_SYNC_ELEMENT,
> > -   dma_trigger, 0);
> > -   omap_set_dma_dest_params(ep->lch, OMAP_DMA_PORT_EMIFF,
> > -   OMAP_DMA_AMODE_POST_INC, req->req.dma + req->req.actual,
> > -   0, 0);
> > -   ep->dma_counter = omap_get_dma_dst_pos(ep->lch);
> > +
> > +   if (dma) {
> > +   struct dma_slave_config cfg = {
> > +   .direction = DMA_DEV_TO_MEM,
> > +   .src_addr_width = DMA_SLAVE_BUSWIDTH_2_BYTE,
> > +   /*
> > +* DMAengine uses frame sync mode, setting maxburst=1
> > +* is equivalent to element sync mode.
> > +*/
> > +   .src_maxburst = 1,
> 
> We should fix the omap-dma driver for slave_sg  instead:
> 
> if (!burst)
>   burst = 1;
> 
> I thought that I already did that.

It isn't in 4.19, and I see no changes between 4.19 and 4.20-rc for
ti/omap-dma.c.

> > +   struct dma_chan *dma;
> > +
> > dma_channel = OMAP_DMA_USB_W2FC_RX0 - 1 + channel;
> > -   status = omap_request_dma(dma_channel,
> > -   ep->ep.name, dma_error, ep, >lch);
> > -   if (status == 0) {
> > +
> > +   dma = __dma_request_channel(, omap_dma_filter_fn,
> > +   (void *)dma_channel);
> 
> dma_request_chan(dev, "ch_name");
> 
> where ch_name: rx0/1/2, tx0/1/2
> 
> and we don't need the omap_dma_filter_fn in here as all taken care via
> the dma_slave_map

Yea, we can 

Re: [PATCH] locking/atomics: build atomic headers as required

[Mark Rutland]

On Fri, Nov 23, 2018 at 03:33:21PM +, Mark Rutland wrote:
> Andrew and Ingo report that the check-atomics.sh script is simply too
> slow to run for every kernel build, and it's impractical to make it
> faster without rewriting it in something other than shell.
> 
> Rather than committing the generated headers, let's regenerate these
> as-required for a pristine tree.

> The diffstat looks nice, at least...

>  include/asm-generic/atomic-instrumented.h | 1787 --
>  include/asm-generic/atomic-long.h | 1012 -
>  include/linux/atomic-fallback.h   | 2294 
> -

As a heads-up, I generated the diff with git format-patch -D, to omit
the preimage for those ~5000 lines being deleted. Unfortunately, git-am
will refuse to apply that, with something like:

| error: removal patch leaves file contents
| error: include/asm-generic/atomic-instrumented.h: patch does not apply

I've pushed the patch to my atomics/regenerate branch [1] for now. I can resend
with the full context (or leaving the stale files for a subsequent deletion),
if that's preferable?

Thanks,
Mark.

[1] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git 
atomics/regenerate

Re: [PATCH 2/3] dt-bindings: mfd: atmel-usart: add DMA bindings for SPI mode

[Radu Nicolae Pirea]

On Wed, 2018-11-21 at 10:41 -0600, Rob Herring wrote:
> On Wed, Nov 21, 2018 at 5:29 AM Radu Pirea  > wrote:
> > The bindings for DMA are now common for both drivers of the USART
> > IP.
> > 
> > The node given as an example for USART in SPI mode has been updated
> > in
> > order to include DMA bindings.
> > 
> > Signed-off-by: Radu Pirea 
> > ---
> >  .../devicetree/bindings/mfd/atmel-usart.txt   | 15 ++-
> > 
> >  1 file changed, 10 insertions(+), 5 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/mfd/atmel-usart.txt
> > b/Documentation/devicetree/bindings/mfd/atmel-usart.txt
> > index 7f0cd72f47d2..8ad008175343 100644
> > --- a/Documentation/devicetree/bindings/mfd/atmel-usart.txt
> > +++ b/Documentation/devicetree/bindings/mfd/atmel-usart.txt
> > @@ -17,17 +17,19 @@ Required properties for USART in SPI mode:
> >  - cs-gpios: chipselects (internal cs not supported)
> >  - atmel,usart-mode : Must be  (found in dt-
> > bindings/mfd/at91-usart.h)
> > 
> > +Optional properties in serial and SPI mode:
> > +- dma bindings for dma transfer:
> > +   - dmas: DMA specifier, consisting of a phandle to DMA
> > controller node,
> > +   memory peripheral interface and USART DMA channel
> > ID, FIFO configuration.
> > +   Refer to dma.txt and atmel-dma.txt for details.
> > +   - dma-names: "rx" for RX channel, "tx" for TX channel.
> > +   dma-names = "tx", "rx";
> 
> The dma-names should have a defined order.

Thanks Rob.
I will specify in bindings a fixed order for dmas and dma-names.

> 
> Rob

Re: [PATCH 05/17] soc: ti: pruss: Configure SYSCFG properly during probe/remove

[Tony Lindgren]

* Roger Quadros  [181122 11:39]:
> +/* firmware must be idle when calling this function */
> +static void pruss_disable_module(struct device *dev)
> +{
> + struct pruss_soc_bus *psoc_bus = dev_get_drvdata(dev);
> +
> + /* configure Smart Standby */
> + pruss_soc_bus_rmw(psoc_bus->syscfg, SYSCFG_STANDBY_MODE_MASK,
> +   SYSCFG_STANDBY_MODE_SMART);
> +
> + /* initiate MStandby */
> + pruss_soc_bus_rmw(psoc_bus->syscfg, SYSCFG_STANDBY_INIT,
> +   SYSCFG_STANDBY_INIT);
> +
> + /* tell PRCM to initiate IDLE request */
> + pm_runtime_put_sync(dev);
> +}
> +
> +static int pruss_enable_module(struct device *dev)
> +{
> + struct pruss_soc_bus *psoc_bus = dev_get_drvdata(dev);
> + int ret;
> +
> + /* tell PRCM to de-assert IDLE request */
> + ret = pm_runtime_get_sync(dev);
> + if (ret < 0) {
> + pm_runtime_put_noidle(dev);
> + return ret;
> + }
> +
> + /* configure for Smart Idle & Smart Standby */
> + pruss_soc_bus_rmw(psoc_bus->syscfg, SYSCFG_IDLE_MODE_MASK,
> +   SYSCFG_IDLE_MODE_SMART);
> + pruss_soc_bus_rmw(psoc_bus->syscfg, SYSCFG_STANDBY_MODE_MASK,
> +   SYSCFG_STANDBY_MODE_SMART);
> +
> + return ret;
> +}

Yeah so nothing PRU specific here, this you should be able to
handle in a generic way with drivers/bus/ti-sysc.c.

Regards,

Tony

Re: [PATCH v3 2/2] proc: add /proc//arch_state

[Dave Martin]

On Thu, Nov 22, 2018 at 09:40:24AM +0800, Li, Aubrey wrote:
> On 2018/11/21 17:53, Peter Zijlstra wrote:
> > On Wed, Nov 21, 2018 at 09:19:36AM +0100, Peter Zijlstra wrote:
> >> On Wed, Nov 21, 2018 at 09:39:00AM +0800, Li, Aubrey wrote:
>  Also; you were going to shop around with the other architectures to see
>  what they want/need for this interface. I see nothing on that.
> 
> >>> I'm open for your suggestion, :)
> >>
> >> Well, we have linux-arch and the various maintainers are also listed in
> >> MAINTAINERS. Go forth and ask..
> > 
> > Ok, so I googled a wee bit (you could have too).
> > 
> > There's not that many architectures that build big hot chips
> > (powerpc,x86,arm64,s390) (mips, sparc64 and ia64 are pretty dead I
> > think, although the Fujitsu Sparc M10 X+/X SIMD looked like it could be
> > 'fun').
> > 
> > Of those, powerpc altivec doesn't seem to be very wide, but you'd have
> > to ask the power folks. Same for s390 z13.
> > 
> > The Fujitsu/ARM64-SVE stuff looks like it can be big and hot.
> > 
> > And RISC-V has was vector extention, but I don't think anybody is
> > actually building big hot versions of that just yet.
> > 
> Thanks Peter. Add more maintainers here.
> 
> On some x86 architectures, the tasks using simd instruction(AVX512 
> particularly)
> need to be dealt with specially against the tasks not using simd instruction.
> I proposed an interface to expose such CPU specific information for the user
> space tools to apply different scheduling policies.
> 
> The interface can be refined to be the format as /proc//status. Not sure
> if it's useful to any other architectures.
> 
> Welcome any comments.

For SVE:

We currently monitor SVE use by trapping only.  We also made an ABI
decision that a syscall throws away the task's SVE state -- this
falls out naturally from the fact that the SVE state is caller-save
for regular function calls in the AArch64 ABI.

There isn't an explicit means like VZEROUPPER for userspace to
mark the SVE state as non-live without entering the kernel today.

Currently I expose as little detail to userspace as possible regarding
how/when SVE is enabled/disabled or used.


For the /proc interface:

It would be nice to expose some information to userspace about when/
where major hardware functional units are in use, but beyond the
information already supplied by hardware perf events, it's not
obvious what should be exposed.

AFAICT, the exposed flags would be partly an arbitrary artifact of
kernel implementation details: i.e., how often and when the kernel
saves/restores the task's state may affect the pattern of observed
values in non-trivial ways.

For SVE today, a task that does a lot of syscalls may appear to be using
SVE less than a second task that does fewer syscalls but is otherwise
identical -- simply because a syscall is our only way to detect that
SVE is not in use today.


This kind of issue means that userspace may struggle to make good
decisions using this data: instead it's going to rely on some kind of
tuning which may become wrong as soon as the workload, kernel version
or hardware changes.


A /proc//file would need to be polled (which doesn't sound great)
and also suffers from all the usual /proc raciness.

Cheers
---Dave

[PATCH v2] dt-bindings: i2c: Use correct vendor prefix for Atmel

[Thierry Reding]

From: Thierry Reding 

The "at," prefix was never correct for Atmel, so fix the few occurrences
that got it wrong. Use "atmel," instead.

While at it, remove the at,24c08 compatible string from the list of
trivial devices because it is already documented in eeprom/at24.txt.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- remove at,24c08 compatible from trivial-devices since it is already
  documented in Documentation/devicetree/bindings/eeprom/at24.txt

 Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt | 2 +-
 Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt | 2 +-
 Documentation/devicetree/bindings/i2c/nxp,pca9541.txt | 2 +-
 Documentation/devicetree/bindings/trivial-devices.txt | 1 -
 4 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt 
b/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
index 1e98c6b3a721..c661b9083ec6 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
@@ -43,7 +43,7 @@ Example:
reg = <0>;
 
eeprom@50 {
-   compatible = "at,24c02";
+   compatible = "atmel,24c02";
reg = <0x50>;
};
};
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt 
b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
index ccf6c86ed076..30ac6a60f041 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
@@ -54,7 +54,7 @@ Example:
reg = <2>;
 
eeprom@54 {
-   compatible = "at,24c08";
+   compatible = "atmel,24c08";
reg = <0x54>;
};
};
diff --git a/Documentation/devicetree/bindings/i2c/nxp,pca9541.txt 
b/Documentation/devicetree/bindings/i2c/nxp,pca9541.txt
index 0fbbc6970ec5..42bfc09c8918 100644
--- a/Documentation/devicetree/bindings/i2c/nxp,pca9541.txt
+++ b/Documentation/devicetree/bindings/i2c/nxp,pca9541.txt
@@ -22,7 +22,7 @@ Example:
#size-cells = <0>;
 
eeprom@54 {
-   compatible = "at,24c08";
+   compatible = "atmel,24c08";
reg = <0x54>;
};
};
diff --git a/Documentation/devicetree/bindings/trivial-devices.txt 
b/Documentation/devicetree/bindings/trivial-devices.txt
index 6ab001fa1ed4..94beb5a63ac2 100644
--- a/Documentation/devicetree/bindings/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/trivial-devices.txt
@@ -21,7 +21,6 @@ adi,adt7490   +/-1C TDM Extended Temp Range I.C
 adi,adxl345Three-Axis Digital Accelerometer
 adi,adxl346Three-Axis Digital Accelerometer 
(backward-compatibility value "adi,adxl345" must be listed too)
 ams,iaq-core   AMS iAQ-Core VOC Sensor
-at,24c08   i2c serial eeprom  (24cxx)
 atmel,at97sc3204t  i2c trusted platform module (TPM)
 capella,cm32181CM32181: Ambient Light Sensor
 capella,cm3232 CM3232: Ambient Light Sensor
-- 
2.19.1

Re: [PATCH v2 31/43] drm/sun4i: Add a dedicated ioctl call for allocating tiled buffers

[Paul Kocialkowski]

Hi,

On Fri, 2018-11-23 at 11:30 +, Brian Starkey wrote:
> Hi Paul,
> 
> On Fri, Nov 23, 2018 at 10:25:03AM +0100, Paul Kocialkowski wrote:
> > This introduces a dedicated ioctl for allocating buffers for the VPU
> > tiling mode. It allows setting up buffers that comply to the hardware
> > alignment requirements, by aligning the stride and height to 32 bytes.
> > 
> > Only YUV semiplanar and planar formats are allowed by the ioctl, as the
> > hardware does not support the tiling mode for other formats.
> 
> What's the general feeling about a more generic version of this ioctl?
> There doesn't seem to be anything Allwinner-specific in the ioctl
> arguments.

That's a great suggestion, I am totally in favour of making a generic
fashion of this!

It would also remove the need for a new header dedicated to the sun4i-
drm driver, which was really only motivated by the need for this ioctl.

> It effectively boils down to:
> 
>   size = driver->get_fb_size_with_modifier(...);
>   cma_obj = drm_gem_cma_create(drm, size);
> 
> It would look exactly the same for Mali-DP, and probably others too.
> Is it better to try and define something we can share instead of Arm
> adding another nearly identical ioctl() later?
> 
> I think the minimal viable thing would be to just add modifiers to
> your structure (I put them first because padding):
> 
>   struct drm_gem_create_with_modifiers {
>   __u64 modifiers[4];
>   __u32 height;
>   __u32 width;
>   __u32 format;
>   /* handle, offsets, pitches, size will be returned */
>   __u32 handle;
>   __u32 pitches[4];
>   __u32 offsets[4];
>   __u64 size;
>   };

That would totally work for me and our usecase.

Cheers,

Paul

> Thanks,
> -Brian
> 
> > Signed-off-by: Paul Kocialkowski 
> > ---
> > drivers/gpu/drm/sun4i/sun4i_drv.c | 89 +++
> > include/uapi/drm/sun4i_drm.h  | 42 +++
> > 2 files changed, 131 insertions(+)
> > create mode 100644 include/uapi/drm/sun4i_drm.h
> > 
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
> > b/drivers/gpu/drm/sun4i/sun4i_drv.c
> > index ccdeae6299eb..5ae32973cf34 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> > @@ -21,6 +21,7 @@
> > #include 
> > #include 
> > #include 
> > +#include 
> > 
> > #include "sun4i_drv.h"
> > #include "sun4i_frontend.h"
> > @@ -28,6 +29,92 @@
> > #include "sun4i_tcon.h"
> > #include "sun8i_tcon_top.h"
> > 
> > +int drm_sun4i_gem_create_tiled(struct drm_device *drm, void *data,
> > +  struct drm_file *file_priv)
> > +{
> > +   struct drm_sun4i_gem_create_tiled *args = data;
> > +   struct drm_gem_cma_object *cma_obj;
> > +   struct drm_gem_object *gem_obj;
> > +   uint32_t luma_stride, chroma_stride;
> > +   uint32_t luma_height, chroma_height;
> > +   uint32_t chroma_width;
> > +   const struct drm_format_info *info;
> > +   int ret;
> > +
> > +   info = drm_format_info(args->format);
> > +   if (!info)
> > +   return -EINVAL;
> > +
> > +   /* The tiled output format only applies to non-packed YUV formats. */
> > +   if (!info->is_yuv || info->num_planes == 1)
> > +   return -EINVAL;
> > +
> > +   memset(args->pitches, 0, sizeof(args->pitches));
> > +   memset(args->offsets, 0, sizeof(args->offsets));
> > +
> > +   /* Stride and height are aligned to 32 bytes for our tiled format. */
> > +   luma_stride = ALIGN(args->width, 32);
> > +   luma_height = ALIGN(args->height, 32);
> > +
> > +   chroma_width = args->width;
> > +
> > +   /* Semiplanar formats have both U and V data in their chroma plane. */
> > +   if (drm_format_info_is_yuv_semiplanar(info))
> > +   chroma_width *= 2;
> > +
> > +   chroma_stride = ALIGN(DIV_ROUND_UP(chroma_width, info->hsub), 32);
> > +   chroma_height = ALIGN(DIV_ROUND_UP(args->height, info->vsub), 32);
> > +
> > +   if (drm_format_info_is_yuv_semiplanar(info)) {
> > +   args->pitches[0] = luma_stride;
> > +   args->pitches[1] = chroma_stride;
> > +
> > +   args->offsets[0] = 0;
> > +   args->offsets[1] = luma_stride * luma_height;
> > +
> > +   args->size = luma_stride * luma_height +
> > +chroma_stride * chroma_height;
> > +   } else if (drm_format_info_is_yuv_planar(info)) {
> > +   args->pitches[0] = luma_stride;
> > +   args->pitches[1] = chroma_stride;
> > +   args->pitches[2] = chroma_stride;
> > +
> > +   args->offsets[0] = 0;
> > +   args->offsets[1] = luma_stride * luma_height;
> > +   args->offsets[2] = luma_stride * luma_height +
> > +  chroma_stride * chroma_height;
> > +
> > +   args->size = luma_stride * luma_height +
> > +chroma_stride * chroma_height * 2;
> > +   } else {
> > +   /* No support for other formats in tiled mode. */
> > +   return -EINVAL;
> > +   }
> > +
> > +   cma_obj = 

Re: [RFC PATCH 0/4] mm, memory_hotplug: allocate memmap from hotadded memory

[David Hildenbrand]

On 23.11.18 13:42, Michal Hocko wrote:
> On Fri 23-11-18 12:55:41, Oscar Salvador wrote:
>> On Thu, Nov 22, 2018 at 10:21:24AM +0100, David Hildenbrand wrote:
>>> 1. How are we going to present such memory to the system statistics?
>>>
>>> In my opinion, this vmemmap memory should
>>> a) still account to total memory
>>> b) show up as allocated
>>>
>>> So just like before.
>>
>> No, it does not show up under total memory and neither as allocated memory.
>> This memory is not for use for anything but for creating the pagetables
>> for the memmap array for the section/s.
> 
> I haven't read through your patches yet but wanted to clarfify few
> points here.
> 
> This should essentially follow the bootmem allocated memory pattern. So
> it is present and accounted to spanned pages but it is not managed.
> 
>> It is not memory that the system can use.
> 
> same as bootmem ;)

Fair enough, just saying that it represents a change :)

(but people also already complained if their VM has XGB but they don't
see actual XGB as total memory e.g. due to the crash kernel size)

>  
>> I also guess that if there is a strong opinion on this, we could create
>> a counter, something like NR_VMEMMAP_PAGES, and show it under /proc/meminfo.
> 
> Do we really have to? Isn't the number quite obvious from the size of
> the hotpluged memory?

At least the size of vmmaps cannot reliably calculated from "MemTotal" .
But maybe based on something else. (there, it is indeed obvious)

> 
>>
>>> 2. Is this optional, in other words, can a device driver decide to not
>>> to it like that?
>>
>> Right now, is a per arch setup.
>> For example, x86_64/powerpc/arm64 will do it inconditionally.
>>
>> If we want to restrict this a per device-driver thing, I guess that we could
>> allow to pass a flag to add_memory()->add_memory_resource(), and there
>> unset MHP_MEMMAP_FROM_RANGE in case that flag is enabled.
> 
> I believe we will need to make this opt-in. There are some usecases
> which hotplug an expensive (per size) memory via hotplug and it would be
> too wasteful to use it for struct pages. I haven't bothered to address
> that with my previous patches because I just wanted to make the damn
> thing work first.
> 

Good point.


-- 

Thanks,

David / dhildenb

Re: [PATCH 08/10] ARM64: dts: renesas: Add all CPUs in cooling maps

[Simon Horman]

On Fri, Nov 16, 2018 at 03:34:31PM +0530, Viresh Kumar wrote:
> Each CPU can (and does) participate in cooling down the system but the
> DT only captures a handful of them, normally CPU0, in the cooling maps.
> Things work by chance currently as under normal circumstances its the
> first CPU of each cluster which is used by the operating systems to
> probe the cooling devices. But as soon as this CPU ordering changes and
> any other CPU is used to bring up the cooling device, we will start
> seeing failures.
> 
> Also the DT is rather incomplete when we list only one CPU in the
> cooling maps, as the hardware doesn't have any such limitations.
> 
> Update cooling maps to include all devices affected by individual trip
> points.
> 
> Signed-off-by: Viresh Kumar 

Thanks, applied for v4.21.

Re: [PATCH 3/3] lockdep: Use line-buffered printk() for lockdep messages.

[Petr Mladek]

On Sat 2018-11-10 17:52:17, Tetsuo Handa wrote:
> On 2018/11/10 0:43, Petr Mladek wrote:
> > On Fri 2018-11-09 18:55:26, Tetsuo Handa wrote:
> >> How early_printk requirement affects line buffered printk() API?
> >>
> >> I don't think it is impossible to convert from
> >>
> >>  printk("Testing feature XYZ..");
> >>  this_may_blow_up_because_of_hw_bugs();
> >>  printk(KERN_CONT " ... ok\n");
> >>
> >> to
> >>
> >>  printk("Testing feature XYZ:\n");
> >>  this_may_blow_up_because_of_hw_bugs();
> >>  printk("Testing feature XYZ.. ... ok\n");
> >>
> >> in 
> >> https://lore.kernel.org/lkml/CA+55aFwmwdY_mMqdEyFPpRhCKRyeqj=+acqe5nn108v8elf...@mail.gmail.com/
> >>  .
> > 
> > I just wonder how this pattern is common. I have tried but I failed
> > to find any instance.
> > 
> > This problem looks like a big argument against explicit buffers.
> > But I wonder if it is real.
> 
> An example of boot up messages where buffering makes difference.
> 
> Vanilla:
> 
> [0.260459] smp: Bringing up secondary CPUs ...
> [0.269595] x86: Booting SMP configuration:
> [0.270461]  node  #0, CPUs:  #1
> [0.066578] Disabled fast string operations
> [0.066578] mce: CPU supports 0 MCE banks
> [0.066578] smpboot: CPU 1 Converting physical 2 to logical package 1
> [0.342569]  #2
> [0.066578] Disabled fast string operations
> [0.066578] mce: CPU supports 0 MCE banks
> [0.066578] smpboot: CPU 2 Converting physical 4 to logical package 2
> [0.413442]  #3
> [0.066578] Disabled fast string operations
> [0.066578] mce: CPU supports 0 MCE banks
> [0.066578] smpboot: CPU 3 Converting physical 6 to logical package 3
> [0.476562] smp: Brought up 1 node, 4 CPUs
> [0.477477] smpboot: Max logical packages: 8
> [0.477514] smpboot: Total of 4 processors activated (22691.70 BogoMIPS)
> 
> With try_buffered_printk() patch:
> 
> [0.279768] smp: Bringing up secondary CPUs ...
> [0.288825] x86: Booting SMP configuration:
> [0.066748] Disabled fast string operations
> [0.066748] mce: CPU supports 0 MCE banks
> [0.066748] smpboot: CPU 1 Converting physical 2 to logical package 1
> [0.066748] Disabled fast string operations
> [0.066748] mce: CPU supports 0 MCE banks
> [0.066748] smpboot: CPU 2 Converting physical 4 to logical package 2
> [0.066748] Disabled fast string operations
> [0.066748] mce: CPU supports 0 MCE banks
> [0.066748] smpboot: CPU 3 Converting physical 6 to logical package 3
> [0.495862]  node  #0, CPUs:  #1 #2 #3
6smp: Brought up 1 node, 4 
> CPUs
> [0.496833] smpboot: Max logical packages: 8
> [0.497609] smpboot: Total of 4 processors activated (22665.22 BogoMIPS)
> 
> 
> 
> Hmm, arch/x86/kernel/smpboot.c is not emitting '\n' after #num
> 
> if (system_state < SYSTEM_RUNNING) {
> if (node != current_node) {
> if (current_node > (-1))
> pr_cont("\n");
> current_node = node;
> 
> printk(KERN_INFO " node %*s#%d, CPUs:  ",
>node_width - num_digits(node), " ", node);
> }
> 
> /* Add padding for the BSP */
> if (cpu == 1)
> pr_cont("%*s", width + 1, " ");
> 
> pr_cont("%*s#%d", width - num_digits(cpu), " ", cpu);
> 
> } else
> pr_info("Booting Node %d Processor %d APIC 0x%x\n",
> node, cpu, apicid);
> 
> and causing
> 
> pr_info("Brought up %d node%s, %d CPU%s\n",
> num_nodes, (num_nodes > 1 ? "s" : ""),
> num_cpus,  (num_cpus  > 1 ? "s" : ""));
> 
> line to be concatenated to previous line.
> Maybe disable try_buffered_printk() if system_state !=
> SYSTEM_RUNNING ?

We need to solve continuous lines also during boot. Also similar
problems might be in the code that is called in SYSTEM_RUNNING state.

This is yet another clue that try_buffered_printk() approach is not
that good idea.

Best Regards,
Petr

unsubcribe

[Zorg]

Re: [PATCH 10/17] mailbox: bcm2835: Switch to SPDX identifier

[Stefan Wahren]

Hi Jassi,

Am 11.11.18 um 12:25 schrieb Lubomir Rintel:
> On Sat, 2018-11-10 at 16:59 +0100, Stefan Wahren wrote:
>> Adopt the SPDX license identifier headers to ease license compliance
>> management.
>>
>> Cc: Lubomir Rintel 
>> Signed-off-by: Stefan Wahren 
>> ---
>>  drivers/mailbox/bcm2835-mailbox.c | 8 +---
>>  1 file changed, 1 insertion(+), 7 deletions(-)
>>
>> diff --git a/drivers/mailbox/bcm2835-mailbox.c
>> b/drivers/mailbox/bcm2835-mailbox.c
>> index e92bbc5..bb3ee72 100644
>> --- a/drivers/mailbox/bcm2835-mailbox.c
>> +++ b/drivers/mailbox/bcm2835-mailbox.c
>> @@ -1,15 +1,9 @@
>> +// SPDX-License-Identifier: GPL-2.0
>>  /*
>>   *  Copyright (C) 2010,2015 Broadcom
>>   *  Copyright (C) 2013-2014 Lubomir Rintel
>>   *  Copyright (C) 2013 Craig McGeachie
>>   *
>> - * 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 device provides a mechanism for writing to the mailboxes,
>> - * that are shared between the ARM and the VideoCore processor
>> - *
>>   * Parts of the driver are based on:
>>   *  - arch/arm/mach-bcm2708/vcio.c file written by Gray Girling that
>> was
>>   *obtained from branch "rpi-3.6.y" of
>> git://github.com/raspberrypi/
> Acked-by: Lubomir Rintel 
>
are you fine with this patch?

Stefan

[PATCH 2/2] serial: mvebu-uart: initialize over sampling stack register

[Miquel Raynal]

The baudrate derivation relies on the state of the programmable over
sampling stack (OSAMP register) being empty, while never initializing
it.

Set all the fields of this register to 0 (except reserved areas) to
ensure a x16 divisor, as assumed by the driver.

The suspend/resume callbacks are untouched because they already
save/restore correctly this register.

Suggested-by: Thomas Petazzoni 
Signed-off-by: Miquel Raynal 
---
 drivers/tty/serial/mvebu-uart.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/mvebu-uart.c b/drivers/tty/serial/mvebu-uart.c
index df6e4d8cdbd6..231f751d1ef4 100644
--- a/drivers/tty/serial/mvebu-uart.c
+++ b/drivers/tty/serial/mvebu-uart.c
@@ -73,6 +73,7 @@
 
 #define UART_OSAMP 0x14
 #define  OSAMP_DEFAULT_DIVISOR 16
+#define  OSAMP_DIVISORS_MASK   0x3F3F3F3F
 
 #define MVEBU_NR_UARTS 2
 
@@ -446,7 +447,7 @@ static int mvebu_uart_baud_rate_set(struct uart_port *port, 
unsigned int baud)
 {
struct mvebu_uart *mvuart = to_mvuart(port);
unsigned int d_divisor, m_divisor;
-   u32 brdv;
+   u32 brdv, osamp;
 
if (IS_ERR(mvuart->clk))
return -PTR_ERR(mvuart->clk);
@@ -469,6 +470,10 @@ static int mvebu_uart_baud_rate_set(struct uart_port 
*port, unsigned int baud)
brdv |= d_divisor;
writel(brdv, port->membase + UART_BRDV);
 
+   osamp = readl(port->membase + UART_OSAMP);
+   osamp &= ~OSAMP_DIVISORS_MASK;
+   writel(osamp, port->membase + UART_OSAMP);
+
return 0;
 }
 
-- 
2.19.1

[PATCH 1/2] serial: mvebu-uart: clarify the baud rate derivation

[Miquel Raynal]

The current comment in ->set_baud_rate() is rather incomplete as it
fails to describe what are the actual stages for the baudrate
derivation. Replace this comment with something more explicit and
close to the functional specification. Also adapt the variable names
to it.

Signed-off-by: Miquel Raynal 
---
 drivers/tty/serial/mvebu-uart.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/tty/serial/mvebu-uart.c b/drivers/tty/serial/mvebu-uart.c
index 170e446a2f62..df6e4d8cdbd6 100644
--- a/drivers/tty/serial/mvebu-uart.c
+++ b/drivers/tty/serial/mvebu-uart.c
@@ -72,6 +72,7 @@
 #define  BRDV_BAUD_MASK 0x3FF
 
 #define UART_OSAMP 0x14
+#define  OSAMP_DEFAULT_DIVISOR 16
 
 #define MVEBU_NR_UARTS 2
 
@@ -444,23 +445,28 @@ static void mvebu_uart_shutdown(struct uart_port *port)
 static int mvebu_uart_baud_rate_set(struct uart_port *port, unsigned int baud)
 {
struct mvebu_uart *mvuart = to_mvuart(port);
-   unsigned int baud_rate_div;
+   unsigned int d_divisor, m_divisor;
u32 brdv;
 
if (IS_ERR(mvuart->clk))
return -PTR_ERR(mvuart->clk);
 
/*
-* The UART clock is divided by the value of the divisor to generate
-* UCLK_OUT clock, which is 16 times faster than the baudrate.
-* This prescaler can achieve all standard baudrates until 230400.
-* Higher baudrates could be achieved for the extended UART by using the
-* programmable oversampling stack (also called fractional divisor).
+* The baudrate is derived from the UART clock thanks to two divisors:
+*   > D ("baud generator"): can divide the clock from 2 to 2^10 - 1.
+*   > M ("fractional divisor"): allows a better accuracy for
+* baudrates higher than 230400.
+*
+* As the derivation of M is rather complicated, the code sticks to its
+* default value (x16) when all the prescalers are zeroed, and only
+* makes use of D to configure the desired baudrate.
 */
-   baud_rate_div = DIV_ROUND_UP(port->uartclk, baud * 16);
+   m_divisor = OSAMP_DEFAULT_DIVISOR;
+   d_divisor = DIV_ROUND_UP(port->uartclk, baud * m_divisor);
+
brdv = readl(port->membase + UART_BRDV);
brdv &= ~BRDV_BAUD_MASK;
-   brdv |= baud_rate_div;
+   brdv |= d_divisor;
writel(brdv, port->membase + UART_BRDV);
 
return 0;
-- 
2.19.1

Re: [PATCH] dmaengine: ti: omap-dma: Configure LCH_TYPE for OMAP1

[Russell King - ARM Linux]

Hi Peter,

Here's the patch, which should now support IN as well as OUT.
Completely untested, as mentioned before.

 drivers/usb/gadget/udc/omap_udc.c | 286 ++
 drivers/usb/gadget/udc/omap_udc.h |   3 +-
 2 files changed, 135 insertions(+), 154 deletions(-)

diff --git a/drivers/usb/gadget/udc/omap_udc.c 
b/drivers/usb/gadget/udc/omap_udc.c
index 3a16431da321..ad6f315e4327 100644
--- a/drivers/usb/gadget/udc/omap_udc.c
+++ b/drivers/usb/gadget/udc/omap_udc.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -203,7 +204,7 @@ static int omap_ep_enable(struct usb_ep *_ep,
/* set endpoint to initial state */
ep->dma_channel = 0;
ep->has_dma = 0;
-   ep->lch = -1;
+   ep->dma = NULL;
use_ep(ep, UDC_EP_SEL);
omap_writew(udc->clr_halt, UDC_CTRL);
ep->ackwait = 0;
@@ -468,43 +469,6 @@ static int read_fifo(struct omap_ep *ep, struct omap_req 
*req)
 
 /*-*/
 
-static u16 dma_src_len(struct omap_ep *ep, dma_addr_t start)
-{
-   dma_addr_t  end;
-
-   /* IN-DMA needs this on fault/cancel paths, so 15xx misreports
-* the last transfer's bytecount by more than a FIFO's worth.
-*/
-   if (cpu_is_omap15xx())
-   return 0;
-
-   end = omap_get_dma_src_pos(ep->lch);
-   if (end == ep->dma_counter)
-   return 0;
-
-   end |= start & (0x << 16);
-   if (end < start)
-   end += 0x1;
-   return end - start;
-}
-
-static u16 dma_dest_len(struct omap_ep *ep, dma_addr_t start)
-{
-   dma_addr_t  end;
-
-   end = omap_get_dma_dst_pos(ep->lch);
-   if (end == ep->dma_counter)
-   return 0;
-
-   end |= start & (0x << 16);
-   if (cpu_is_omap15xx())
-   end++;
-   if (end < start)
-   end += 0x1;
-   return end - start;
-}
-
-
 /* Each USB transfer request using DMA maps to one or more DMA transfers.
  * When DMA completion isn't request completion, the UDC continues with
  * the next DMA transfer for that USB transfer.
@@ -512,34 +476,53 @@ static u16 dma_dest_len(struct omap_ep *ep, dma_addr_t 
start)
 
 static void next_in_dma(struct omap_ep *ep, struct omap_req *req)
 {
-   u16 txdma_ctrl, w;
-   unsignedlength = req->req.length - req->req.actual;
-   const int   sync_mode = cpu_is_omap15xx()
-   ? OMAP_DMA_SYNC_FRAME
-   : OMAP_DMA_SYNC_ELEMENT;
-   int dma_trigger = 0;
+   struct dma_async_tx_descriptor *tx;
+   struct dma_chan *dma = ep->dma;
+   dma_cookie_t cookie;
+   unsigned burst, length;
+   u16 txdma_ctrl, w;
+   struct dma_slave_config omap_udc_in_cfg = {
+   .direction = DMA_MEM_TO_DEV,
+   .dst_addr = UDC_DATA_DMA,
+   };
+
+   length = req->req.length - req->req.actual;
 
/* measure length in either bytes or packets */
-   if ((cpu_is_omap16xx() && length <= UDC_TXN_TSC)
-   || (cpu_is_omap15xx() && length < ep->maxpacket)) {
+   if ((cpu_is_omap16xx() && length <= UDC_TXN_TSC) ||
+   (cpu_is_omap15xx() && length < ep->maxpacket)) {
+   omap_udc_in_cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
txdma_ctrl = UDC_TXN_EOT | length;
-   omap_set_dma_transfer_params(ep->lch, OMAP_DMA_DATA_TYPE_S8,
-   length, 1, sync_mode, dma_trigger, 0);
+   burst = length;
} else {
-   length = min(length / ep->maxpacket,
-   (unsigned) UDC_TXN_TSC + 1);
+   omap_udc_in_cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_2_BYTE;
+   length = min_t(unsigned, length / ep->maxpacket,
+  UDC_TXN_TSC + 1);
txdma_ctrl = length;
-   omap_set_dma_transfer_params(ep->lch, OMAP_DMA_DATA_TYPE_S16,
-   ep->ep.maxpacket >> 1, length, sync_mode,
-   dma_trigger, 0);
length *= ep->maxpacket;
+   burst = ep->ep.maxpacket >> 1;
}
-   omap_set_dma_src_params(ep->lch, OMAP_DMA_PORT_EMIFF,
-   OMAP_DMA_AMODE_POST_INC, req->req.dma + req->req.actual,
-   0, 0);
 
-   omap_start_dma(ep->lch);
-   ep->dma_counter = omap_get_dma_src_pos(ep->lch);
+   if (!cpu_is_omap15xx())
+   burst = 1;
+
+   omap_udc_in_cfg.dst_maxburst = burst;
+
+   if (WARN_ON(dmaengine_slave_config(dma, _udc_in_cfg)))
+   return;
+
+   tx = dmaengine_prep_slave_single(dma, req->req.dma + req->req.actual,
+length, DMA_MEM_TO_DEV, 0);
+   if (WARN_ON(!tx))
+   return;
+
+   cookie = 

[PATCH] pinctrl: nuvoton: check for devm_kasprintf() failure

[Nicholas Mc Guire]

devm_kasprintf() may return NULL on failure of internal allocation thus
the assignment to  .label  is not safe if not checked. On error
npcm7xx_gpio_of() returns negative values so -ENOMEM in the
(unlikely) failure case of devm_kasprintf() should be fine here.

Signed-off-by: Nicholas Mc Guire 
Fixes: 3b588e43ee5c ("pinctrl: nuvoton: add NPCM7xx pinctrl and GPIO driver")
---

Problem located with experimental coccinelle script

The only call-site is the probe function (npcm7xx_pinctrl_probe()) wich
will bail out on error - it seems like no further cleanup is expected.

Also while the code generally uses the  if (!var)  construct that would
not be very readable in this case so I think the:
 if (pctrl->gpio_bank[id].gc.label == NULL)
is more appropriate here not sure though what the general preference is.

Patch was compile tested with: multi_v7_defconfig + ARCH_NPCM=y,
ARCH_NPCM7XX=y (implies PINCTRL_NPCM7XX=y)
(sparse reports a number of "obsolete array initializer" warnings)

Patch is against 4.20-rc3 (localversion-next is next-20181123)

 drivers/pinctrl/nuvoton/pinctrl-npcm7xx.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pinctrl/nuvoton/pinctrl-npcm7xx.c 
b/drivers/pinctrl/nuvoton/pinctrl-npcm7xx.c
index b455209..17f909d 100644
--- a/drivers/pinctrl/nuvoton/pinctrl-npcm7xx.c
+++ b/drivers/pinctrl/nuvoton/pinctrl-npcm7xx.c
@@ -1925,6 +1925,9 @@ static int npcm7xx_gpio_of(struct npcm7xx_pinctrl *pctrl)
pctrl->gpio_bank[id].gc.label =
devm_kasprintf(pctrl->dev, GFP_KERNEL, "%pOF",
   np);
+   if (pctrl->gpio_bank[id].gc.label == NULL)
+   return -ENOMEM;
+
pctrl->gpio_bank[id].gc.dbg_show = npcmgpio_dbg_show;
pctrl->gpio_bank[id].direction_input =
pctrl->gpio_bank[id].gc.direction_input;
-- 
2.1.4

Re: [PATCH 09/17] irqchip: bcm283x: Switch to SPDX identifier

[Stefan Wahren]

Hi Marc,

> Marc Zyngier  hat am 23. November 2018 um 16:34 
> geschrieben:
> 
> 
> On 23/11/2018 15:23, Stefan Wahren wrote:
> > Hi Jason,
> > hi Marc,
> > 
> > Am 10.11.18 um 16:54 schrieb Stefan Wahren:
> >> Adopt the SPDX license identifier headers to ease license compliance
> >> management.
> >>
> >> Cc: Simon Arlott 
> >> Cc: Eric Anholt 
> >> Signed-off-by: Stefan Wahren 
> >> ---
> >>  drivers/irqchip/irq-bcm2835.c | 11 +--
> >>  drivers/irqchip/irq-bcm2836.c | 11 +--
> >>  2 files changed, 2 insertions(+), 20 deletions(-)
> >>
> >> diff --git a/drivers/irqchip/irq-bcm2835.c b/drivers/irqchip/irq-bcm2835.c
> >> index d2da8a1..418245d 100644
> >> --- a/drivers/irqchip/irq-bcm2835.c
> >> +++ b/drivers/irqchip/irq-bcm2835.c
> >> @@ -1,17 +1,8 @@
> >> +// SPDX-License-Identifier: GPL-2.0+
> >>  /*
> >>   * Copyright 2010 Broadcom
> >>   * Copyright 2012 Simon Arlott, Chris Boot, Stephen Warren
> >>   *
> >> - * 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; either version 2 of the License, or
> >> - * (at your option) any later version.
> >> - *
> >> - * 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.
> >> - *
> >>   * Quirk 1: Shortcut interrupts don't set the bank 1/2 register pending 
> >> bits
> >>   *
> >>   * If an interrupt fires on bank 1 that isn't in the shortcuts list, bit 8
> >> diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
> >> index dfe4a46..2038693 100644
> >> --- a/drivers/irqchip/irq-bcm2836.c
> >> +++ b/drivers/irqchip/irq-bcm2836.c
> >> @@ -1,17 +1,8 @@
> >> +// SPDX-License-Identifier: GPL-2.0+
> >>  /*
> >>   * Root interrupt controller for the BCM2836 (Raspberry Pi 2).
> >>   *
> >>   * Copyright 2015 Broadcom
> >> - *
> >> - * 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; either version 2 of the License, or
> >> - * (at your option) any later version.
> >> - *
> >> - * 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 
> > 
> > Eric already made a review. Are you fine with it?
> 
> Sure. How do you want this to go in?

i would prefer if this patch go via irqchip tree.

Thanks Stefan

> If you have a series repainting
> multiple subsystems, I'd rather it stays as such, and you can stick my
> 
> Acked-by: Marc Zyngier 
> 
> on it.
> 
> Thanks,
> 
>   M.
> -- 
> Jazz is not dead. It just smells funny...

Re: [RFC PATCH 0/4] mm, memory_hotplug: allocate memmap from hotadded memory

[Michal Hocko]

On Fri 23-11-18 12:55:41, Oscar Salvador wrote:
> On Thu, Nov 22, 2018 at 10:21:24AM +0100, David Hildenbrand wrote:
> > 1. How are we going to present such memory to the system statistics?
> > 
> > In my opinion, this vmemmap memory should
> > a) still account to total memory
> > b) show up as allocated
> > 
> > So just like before.
> 
> No, it does not show up under total memory and neither as allocated memory.
> This memory is not for use for anything but for creating the pagetables
> for the memmap array for the section/s.

I haven't read through your patches yet but wanted to clarfify few
points here.

This should essentially follow the bootmem allocated memory pattern. So
it is present and accounted to spanned pages but it is not managed.

> It is not memory that the system can use.

same as bootmem ;)
 
> I also guess that if there is a strong opinion on this, we could create
> a counter, something like NR_VMEMMAP_PAGES, and show it under /proc/meminfo.

Do we really have to? Isn't the number quite obvious from the size of
the hotpluged memory?

> 
> > 2. Is this optional, in other words, can a device driver decide to not
> > to it like that?
> 
> Right now, is a per arch setup.
> For example, x86_64/powerpc/arm64 will do it inconditionally.
> 
> If we want to restrict this a per device-driver thing, I guess that we could
> allow to pass a flag to add_memory()->add_memory_resource(), and there
> unset MHP_MEMMAP_FROM_RANGE in case that flag is enabled.

I believe we will need to make this opt-in. There are some usecases
which hotplug an expensive (per size) memory via hotplug and it would be
too wasteful to use it for struct pages. I haven't bothered to address
that with my previous patches because I just wanted to make the damn
thing work first.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH 3/3] lockdep: Use line-buffered printk() for lockdep messages.

[Tetsuo Handa]

On 2018/11/23 21:46, Petr Mladek wrote:
> I am more and more wondering if the buffered printk is worth
> the effort. The more buffers we use the more we risk that nobody
> would see some important message. Even a part of the line
> might be crucial in some situations.
> 
> Steven told me on Plumbers conference that even few initial
> characters saved him a day few times.

Yes, few initial characters of one line might sometimes help.
But emitting one line at a time also helps sometimes; especially
when we need to interpret multiple lines and group these lines from
concurrent printk() callers.

> 
> 
>> But updating printk() users to always end with '\n' will be preferable.
> 
> This sounds like a whack a mole game. If I get it correctly, you write
> that it is "an impossible task for anybody" just few lines above.

Yes, updating printk() users is almost impossible. I think that something
like diff shown below is what we can afford at best. If you believe that
line buffering is wrong, I can tolerate with switching via kernel config
option like CONFIG_DEBUG_AID_FOR_SYZBOT=y.

 kernel/printk/printk.c | 263 +
 1 file changed, 176 insertions(+), 87 deletions(-)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 315718b..2276c99 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -584,6 +584,15 @@ static int log_store(int facility, int level,
struct printk_log *msg;
u32 size, pad_len;
u16 trunc_msg_len = 0;
+   static char id[32];
+   u16 id_len;
+
+   if (in_task())
+   id_len = scnprintf(id, sizeof(id), "[T%u] ", current->pid);
+   else
+   id_len = scnprintf(id, sizeof(id), "[C%u] ",
+  raw_smp_processor_id());
+   text_len += id_len;
 
/* number of '\0' padding bytes to next message */
size = msg_used_size(text_len, dict_len, _len);
@@ -607,12 +616,16 @@ static int log_store(int facility, int level,
log_next_idx = 0;
}
 
+   text_len -= id_len;
+
/* fill message */
msg = (struct printk_log *)(log_buf + log_next_idx);
-   memcpy(log_text(msg), text, text_len);
-   msg->text_len = text_len;
+   memcpy(log_text(msg), id, id_len);
+   memcpy(log_text(msg) + id_len, text, text_len);
+   msg->text_len = text_len + id_len;
if (trunc_msg_len) {
-   memcpy(log_text(msg) + text_len, trunc_msg, trunc_msg_len);
+   memcpy(log_text(msg) + id_len + text_len, trunc_msg,
+  trunc_msg_len);
msg->text_len += trunc_msg_len;
}
memcpy(log_dict(msg), dict, dict_len);
@@ -620,10 +633,7 @@ static int log_store(int facility, int level,
msg->facility = facility;
msg->level = level & 7;
msg->flags = flags & 0x1f;
-   if (ts_nsec > 0)
-   msg->ts_nsec = ts_nsec;
-   else
-   msg->ts_nsec = local_clock();
+   msg->ts_nsec = ts_nsec;
memset(log_dict(msg) + dict_len, 0, pad_len);
msg->len = size;
 
@@ -1758,87 +1768,154 @@ static inline void printk_delay(void)
 }
 
 /*
- * Continuation lines are buffered, and not committed to the record buffer
- * until the line is complete, or a race forces it. The line fragments
- * though, are printed immediately to the consoles to ensure everything has
- * reached the console in case of a kernel crash.
+ * Continuation lines are buffered based on type of context, and not committed
+ * to the record buffer until the line is complete, or a race forces it.
+ *
+ * While this context calculation is not perfect, asking printk() callers to
+ * explicitly pass "struct printk_buffer" (except "context" field) as their
+ * function arguments will require too large tree-wide changes. Therefore,
+ * let's tolerate failing to separate "up to one line of messages", and avoid
+ * bloating kernel code size for addressing infrequently happening races.
  */
-static struct cont {
-   char buf[LOG_LINE_MAX];
-   size_t len; /* length == 0 means unused buffer */
-   struct task_struct *owner;  /* task of first print*/
-   u64 ts_nsec;/* time of first print */
-   u8 level;   /* log level of first message */
-   u8 facility;/* log facility of first message */
-   enum log_flags flags;   /* prefix, newline flags */
-} cont;
-
-static void cont_flush(void)
+static inline unsigned long printk_context(void)
 {
-   if (cont.len == 0)
-   return;
-
-   log_store(cont.facility, cont.level, cont.flags, cont.ts_nsec,
- NULL, 0, cont.buf, cont.len);
-   cont.len = 0;
-}
+   unsigned long base;
 
-static bool cont_add(int facility, int level, enum log_flags flags, const char 
*text, size_t len)
-{
-   /* If the line gets too long, split it up in separate 

Re: [RFC PATCH 0/4] mm, memory_hotplug: allocate memmap from hotadded memory

[Michal Hocko]

On Fri 23-11-18 13:51:57, David Hildenbrand wrote:
> On 23.11.18 13:42, Michal Hocko wrote:
> > On Fri 23-11-18 12:55:41, Oscar Salvador wrote:
[...]
> >> It is not memory that the system can use.
> > 
> > same as bootmem ;)
> 
> Fair enough, just saying that it represents a change :)
> 
> (but people also already complained if their VM has XGB but they don't
> see actual XGB as total memory e.g. due to the crash kernel size)

I can imagine. I have seen many "where's my memory dude" questions... We
have so many unaccounted usages that it is simply impossible to see the
full picture of where the memory is consumed. The current implementation
would account memmaps in unreclaimable slabs but you still do not know
how much was spent for it...
 
> >> I also guess that if there is a strong opinion on this, we could create
> >> a counter, something like NR_VMEMMAP_PAGES, and show it under 
> >> /proc/meminfo.
> > 
> > Do we really have to? Isn't the number quite obvious from the size of
> > the hotpluged memory?
> 
> At least the size of vmmaps cannot reliably calculated from "MemTotal" .
> But maybe based on something else. (there, it is indeed obvious)

Everybody knows the struct page size obviously :p and the rest is a
simple exercise. But more seriously, I see what you are saying. We do
not have a good counter now and the patch doesn't improve that. But I
guess this is a separate discussion.

-- 
Michal Hocko
SUSE Labs

[PATCH 06/12] dt-bindings: PCI: aardvark: describe the reset-gpios property

[Miquel Raynal]

A GPIO might be used to reset the PCI IP. Describe the property needed
in this case.

Signed-off-by: Miquel Raynal 
---
 Documentation/devicetree/bindings/pci/aardvark-pci.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/aardvark-pci.txt 
b/Documentation/devicetree/bindings/pci/aardvark-pci.txt
index 310ef7145c47..252934237138 100644
--- a/Documentation/devicetree/bindings/pci/aardvark-pci.txt
+++ b/Documentation/devicetree/bindings/pci/aardvark-pci.txt
@@ -20,6 +20,10 @@ contain the following properties:
define the mapping of the PCIe interface to interrupt numbers.
  - bus-range: PCI bus numbers covered
 
+The following are optional properties:
+
+ - reset-gpios: GPIO to reset the device
+
 In addition, the Device Tree describing an Aardvark PCIe controller
 must include a sub-node that describes the legacy interrupt controller
 built into the PCIe controller. This sub-node must have the following
@@ -48,6 +52,7 @@ Example:
<0 0 0 2 _intc 1>,
<0 0 0 3 _intc 2>,
<0 0 0 4 _intc 3>;
+   reset-gpios = < 3 GPIO_ACTIVE_HIGH>;
pcie_intc: interrupt-controller {
interrupt-controller;
#interrupt-cells = <1>;
-- 
2.19.1

[PATCH 04/12] PCI: aardvark: add clock support

[Miquel Raynal]

The IP relies on a gated clock. When we will add S2RAM support, this
clock will need to be resumed before any PCIe registers are
accessed. Add support for this clock.

Signed-off-by: Miquel Raynal 
---
 drivers/pci/controller/pci-aardvark.c | 29 +++
 1 file changed, 29 insertions(+)

diff --git a/drivers/pci/controller/pci-aardvark.c 
b/drivers/pci/controller/pci-aardvark.c
index da695572a2ed..108b3f15c410 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -8,6 +8,7 @@
  * Author: Hezi Shahmoon 
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -190,6 +191,7 @@
 
 struct advk_pcie {
struct platform_device *pdev;
+   struct clk *clk;
void __iomem *base;
struct list_head resources;
struct irq_domain *irq_domain;
@@ -1083,6 +1085,29 @@ static int advk_pcie_setup_phy(struct advk_pcie *pcie)
return ret;
 }
 
+static int advk_pcie_setup_clk(struct advk_pcie *pcie)
+{
+   struct device *dev = >pdev->dev;
+   int ret;
+
+   pcie->clk = devm_clk_get(dev, NULL);
+   if (IS_ERR(pcie->clk) && (PTR_ERR(pcie->clk) == -EPROBE_DEFER))
+   return PTR_ERR(pcie->clk);
+
+   /* Old bindings miss the clock handle */
+   if (IS_ERR(pcie->clk)) {
+   dev_warn(dev, "Clock unavailable (%ld)\n", PTR_ERR(pcie->clk));
+   pcie->clk = NULL;
+   return 0;
+   }
+
+   ret = clk_prepare_enable(pcie->clk);
+   if (ret)
+   dev_err(dev, "Clock initialization failed (%d)\n", ret);
+
+   return ret;
+}
+
 static int advk_pcie_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -1118,6 +1143,10 @@ static int advk_pcie_probe(struct platform_device *pdev)
return ret;
}
 
+   ret = advk_pcie_setup_clk(pcie);
+   if (ret)
+   return ret;
+
ret = advk_pcie_setup_phy(pcie);
if (ret)
return ret;
-- 
2.19.1

[PATCH 12/12] ARM64: dts: marvell: armada-3720-espressobin: declare PCIe PHY

[Miquel Raynal]

The PCIe node is wired to the second PHY of the COMPHY IP.

Signed-off-by: Miquel Raynal 
---
 arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts 
b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
index 76a508da80b9..43e8e1edc467 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
@@ -49,6 +49,7 @@
pinctrl-names = "default";
pinctrl-0 = <_pins>;
reset-gpios = < 3 GPIO_ACTIVE_HIGH>;
+   phys = < 0>;
 };
 
 /* J6 */
-- 
2.19.1

[PATCH 09/12] ARM64: dts: marvell: armada-37xx: declare PCIe reset pin

[Miquel Raynal]

One GPIO can be muxed as PCIe reset.

Signed-off-by: Miquel Raynal 
---
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi 
b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index 65bf774516ec..9f7e932c8144 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -295,6 +295,10 @@
function = "mii";
};
 
+   pcie_pins: pcie-pins {
+   groups = "pcie1";
+   function = "gpio";
+   };
};
 
eth0: ethernet@3 {
-- 
2.19.1

[PATCH v3 2/4] iio: adc: add STMPE ADC driver using IIO framework

[Philippe Schenker]

From: Stefan Agner 

This adds an ADC driver for the STMPE device using the industrial
input/output interface. The driver supports raw reading of values.
The driver depends on the MFD STMPE driver. If the touchscreen
block is enabled too, only four of the 8 ADC channels are available.

Signed-off-by: Stefan Agner 
Signed-off-by: Max Krummenacher 
Signed-off-by: Philippe Schenker 
---

Changes in v3:
 - Undo ADC-settings related code-deletions in stmpe-ts.c that the code is
   backwards-compatible to older devicetrees.

Changes in v2:
 - Code formatting
 - Move code to setup ADC to MFD device, as it is used by both drivers
   adc and touchscreen
 - Removed unused includes
 - Defined the macro STMPE_START_ONE_TEMP_CONV with other macros.
 - Added new macro that defines the channel of the temperature sensor.
   Took new name for STMPE_MAX_ADC->STMPE_ADC_LAST_NR and used it throughout
   the code for better readability.
 - Added mutex_unlock where missing.

 drivers/iio/adc/Kconfig  |   7 +
 drivers/iio/adc/Makefile |   1 +
 drivers/iio/adc/stmpe-adc.c  | 326 +++
 drivers/input/touchscreen/stmpe-ts.c |  36 +--
 drivers/mfd/Kconfig  |   3 +-
 drivers/mfd/stmpe.c  |  81 +++
 include/linux/mfd/stmpe.h|   9 +
 7 files changed, 437 insertions(+), 26 deletions(-)
 create mode 100644 drivers/iio/adc/stmpe-adc.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index a52fea8749a9..224f2067494d 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -734,6 +734,13 @@ config STM32_DFSDM_ADC
  This driver can also be built as a module.  If so, the module
  will be called stm32-dfsdm-adc.
 
+config STMPE_ADC
+   tristate "STMicroelectronics STMPE ADC driver"
+   depends on OF && MFD_STMPE
+   help
+ Say yes here to build support for ST Microelectronics STMPE
+ built-in ADC block (stmpe811).
+
 config STX104
tristate "Apex Embedded Systems STX104 driver"
depends on PC104 && X86
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index a6e6a0b659e2..cba889c30bf9 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -69,6 +69,7 @@ obj-$(CONFIG_STM32_ADC_CORE) += stm32-adc-core.o
 obj-$(CONFIG_STM32_ADC) += stm32-adc.o
 obj-$(CONFIG_STM32_DFSDM_CORE) += stm32-dfsdm-core.o
 obj-$(CONFIG_STM32_DFSDM_ADC) += stm32-dfsdm-adc.o
+obj-$(CONFIG_STMPE_ADC) += stmpe-adc.o
 obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
 obj-$(CONFIG_TI_ADC0832) += ti-adc0832.o
 obj-$(CONFIG_TI_ADC084S021) += ti-adc084s021.o
diff --git a/drivers/iio/adc/stmpe-adc.c b/drivers/iio/adc/stmpe-adc.c
new file mode 100644
index ..bea3f3c27bb5
--- /dev/null
+++ b/drivers/iio/adc/stmpe-adc.c
@@ -0,0 +1,326 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *  STMicroelectronics STMPE811 IIO ADC Driver
+ *
+ *  4 channel, 10/12-bit ADC
+ *
+ *  Copyright (C) 2013-2018 Toradex AG 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define STMPE_REG_INT_STA  0x0B
+#define STMPE_REG_ADC_INT_EN   0x0E
+#define STMPE_REG_ADC_INT_STA  0x0F
+
+#define STMPE_REG_ADC_CTRL10x20
+#define STMPE_REG_ADC_CTRL20x21
+#define STMPE_REG_ADC_CAPT 0x22
+#define STMPE_REG_ADC_DATA_CH(channel) (0x30 + 2 * (channel))
+
+#define STMPE_REG_TEMP_CTRL0x60
+#define STMPE_TEMP_CTRL_ENABLE BIT(0)
+#define STMPE_TEMP_CTRL_ACQBIT(1)
+#define STMPE_TEMP_CTRL_THRES_EN   BIT(3)
+#define STMPE_START_ONE_TEMP_CONV  (STMPE_TEMP_CTRL_ENABLE | \
+   STMPE_TEMP_CTRL_ACQ | \
+   STMPE_TEMP_CTRL_THRES_EN)
+#define STMPE_REG_TEMP_DATA0x61
+#define STMPE_REG_TEMP_TH  0x63
+#define STMPE_ADC_LAST_NR  7
+#define STMPE_TEMP_CHANNEL (STMPE_ADC_LAST_NR + 1)
+
+#define STMPE_ADC_CH(channel)  ((1 << (channel)) & 0xff)
+
+#define STMPE_ADC_TIMEOUT  msecs_to_jiffies(1000)
+
+struct stmpe_adc {
+   struct stmpe *stmpe;
+   struct clk *clk;
+   struct device *dev;
+
+   /* We are allocating plus one for the temperature channel */
+   struct iio_chan_spec stmpe_adc_iio_channels[STMPE_ADC_LAST_NR + 2];
+
+   struct completion completion;
+
+   u8 channel;
+   u32 value;
+};
+
+static int stmpe_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val,
+ int *val2,
+ long mask)
+{
+   struct stmpe_adc *info = iio_priv(indio_dev);
+   long ret;
+
+   switch (mask) {
+   case IIO_CHAN_INFO_RAW:
+   case IIO_CHAN_INFO_PROCESSED:
+
+   mutex_lock(_dev->mlock);
+
+   info->channel = (u8)chan->channel;
+
+

[PATCH v3 1/4] mfd: stmpe: Move ADC related defines to header of mfd

[Philippe Schenker]

Move defines that are ADC related to the header of the overlying mfd,
so they can be used from multiple sub-devices.

Signed-off-by: Philippe Schenker 
---

Changes in v3:
 - None

Changes in v2:
 - This is a new added commit. Separate commit for moving the defines out of
   drivers/input/touchscreen/stmpe-ts.c to overlying mfd-device 
drivers/mfd/stmpe.c
 - Pre-fix defines with STMPE_

 drivers/input/touchscreen/stmpe-ts.c | 34 +++-
 include/linux/mfd/stmpe.h| 11 +
 2 files changed, 24 insertions(+), 21 deletions(-)

diff --git a/drivers/input/touchscreen/stmpe-ts.c 
b/drivers/input/touchscreen/stmpe-ts.c
index 2a78e27b4495..c5d9006588a2 100644
--- a/drivers/input/touchscreen/stmpe-ts.c
+++ b/drivers/input/touchscreen/stmpe-ts.c
@@ -49,17 +49,6 @@
 
 #define STMPE_IRQ_TOUCH_DET0
 
-#define SAMPLE_TIME(x) ((x & 0xf) << 4)
-#define MOD_12B(x) ((x & 0x1) << 3)
-#define REF_SEL(x) ((x & 0x1) << 1)
-#define ADC_FREQ(x)(x & 0x3)
-#define AVE_CTRL(x)((x & 0x3) << 6)
-#define DET_DELAY(x)   ((x & 0x7) << 3)
-#define SETTLING(x)(x & 0x7)
-#define FRACTION_Z(x)  (x & 0x7)
-#define I_DRIVE(x) (x & 0x1)
-#define OP_MODE(x) ((x & 0x7) << 1)
-
 #define STMPE_TS_NAME  "stmpe-ts"
 #define XY_MASK0xfff
 
@@ -213,9 +202,10 @@ static int stmpe_init_hw(struct stmpe_touch *ts)
return ret;
}
 
-   adc_ctrl1 = SAMPLE_TIME(ts->sample_time) | MOD_12B(ts->mod_12b) |
-   REF_SEL(ts->ref_sel);
-   adc_ctrl1_mask = SAMPLE_TIME(0xff) | MOD_12B(0xff) | REF_SEL(0xff);
+   adc_ctrl1 = STMPE_SAMPLE_TIME(ts->sample_time) |
+   STMPE_MOD_12B(ts->mod_12b) | STMPE_REF_SEL(ts->ref_sel);
+   adc_ctrl1_mask = STMPE_SAMPLE_TIME(0xff) | STMPE_MOD_12B(0xff) |
+STMPE_REF_SEL(0xff);
 
ret = stmpe_set_bits(stmpe, STMPE_REG_ADC_CTRL1,
adc_ctrl1_mask, adc_ctrl1);
@@ -225,15 +215,17 @@ static int stmpe_init_hw(struct stmpe_touch *ts)
}
 
ret = stmpe_set_bits(stmpe, STMPE_REG_ADC_CTRL2,
-   ADC_FREQ(0xff), ADC_FREQ(ts->adc_freq));
+   STMPE_ADC_FREQ(0xff), STMPE_ADC_FREQ(ts->adc_freq));
if (ret) {
dev_err(dev, "Could not setup ADC\n");
return ret;
}
 
-   tsc_cfg = AVE_CTRL(ts->ave_ctrl) | DET_DELAY(ts->touch_det_delay) |
-   SETTLING(ts->settling);
-   tsc_cfg_mask = AVE_CTRL(0xff) | DET_DELAY(0xff) | SETTLING(0xff);
+   tsc_cfg = STMPE_AVE_CTRL(ts->ave_ctrl) |
+ STMPE_DET_DELAY(ts->touch_det_delay) |
+ STMPE_SETTLING(ts->settling);
+   tsc_cfg_mask = STMPE_AVE_CTRL(0xff) | STMPE_DET_DELAY(0xff) |
+  STMPE_SETTLING(0xff);
 
ret = stmpe_set_bits(stmpe, STMPE_REG_TSC_CFG, tsc_cfg_mask, tsc_cfg);
if (ret) {
@@ -242,14 +234,14 @@ static int stmpe_init_hw(struct stmpe_touch *ts)
}
 
ret = stmpe_set_bits(stmpe, STMPE_REG_TSC_FRACTION_Z,
-   FRACTION_Z(0xff), FRACTION_Z(ts->fraction_z));
+   STMPE_FRACTION_Z(0xff), 
STMPE_FRACTION_Z(ts->fraction_z));
if (ret) {
dev_err(dev, "Could not config touch\n");
return ret;
}
 
ret = stmpe_set_bits(stmpe, STMPE_REG_TSC_I_DRIVE,
-   I_DRIVE(0xff), I_DRIVE(ts->i_drive));
+   STMPE_I_DRIVE(0xff), STMPE_I_DRIVE(ts->i_drive));
if (ret) {
dev_err(dev, "Could not config touch\n");
return ret;
@@ -263,7 +255,7 @@ static int stmpe_init_hw(struct stmpe_touch *ts)
}
 
ret = stmpe_set_bits(stmpe, STMPE_REG_TSC_CTRL,
-   OP_MODE(0xff), OP_MODE(OP_MOD_XYZ));
+   STMPE_OP_MODE(0xff), STMPE_OP_MODE(OP_MOD_XYZ));
if (ret) {
dev_err(dev, "Could not set mode\n");
return ret;
diff --git a/include/linux/mfd/stmpe.h b/include/linux/mfd/stmpe.h
index 4a827af17e59..c0353f6431f9 100644
--- a/include/linux/mfd/stmpe.h
+++ b/include/linux/mfd/stmpe.h
@@ -10,6 +10,17 @@
 
 #include 
 
+#define STMPE_SAMPLE_TIME(x)   ((x & 0xf) << 4)
+#define STMPE_MOD_12B(x)   ((x & 0x1) << 3)
+#define STMPE_REF_SEL(x)   ((x & 0x1) << 1)
+#define STMPE_ADC_FREQ(x)  (x & 0x3)
+#define STMPE_AVE_CTRL(x)  ((x & 0x3) << 6)
+#define STMPE_DET_DELAY(x) ((x & 0x7) << 3)
+#define STMPE_SETTLING(x)  (x & 0x7)
+#define STMPE_FRACTION_Z(x)(x & 0x7)
+#define STMPE_I_DRIVE(x)   (x & 0x1)
+#define STMPE_OP_MODE(x)   ((x & 0x7) << 1)
+
 struct device;
 struct regulator;
 
-- 
2.19.1

Re: [PATCH RFC 1/8] drm/bridge: dw-hdmi: Add SCDC and TMDS Scrambling support

[Laurent Pinchart]

Hi Neil,

Thank you for the patch.

On Friday, 23 November 2018 16:02:14 EET Neil Armstrong wrote:
> Add support for SCDC Setup for TMDS Clock > 3.4GHz and enable TMDS
> Scrambling when supported or mandatory.
> 
> This patch also adds an helper to setup the control bit to support
> the hight TMDS Bit Period/TMDS Clock-Period Ratio as required with

s/hight/high/ ?

> TMDS Clock > 3.4GHz for HDMI2.0 3840x2160@60/50 modes.

Why do you need a helper for this, is there no way it could be handled 
internally ?

> These changes were based on work done by Huicong Xu 
> and Nickey Yang  to support HDMI2.0 modes
> on the Rockchip 4.4 BSP kernel at [1]
> 
> [1] https://github.com/rockchip-linux/kernel/tree/release-4.4
> 
> Cc: Nickey Yang 
> Cc: Huicong Xu 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 45 +--
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.h |  1 +
>  include/drm/bridge/dw_hdmi.h  |  1 +
>  3 files changed, 44 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> 5971976284bf..523508af70b0 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> 
>  #include 
> @@ -1015,6 +1016,20 @@ void dw_hdmi_phy_i2c_write(struct dw_hdmi *hdmi,
> unsigned short data, }
>  EXPORT_SYMBOL_GPL(dw_hdmi_phy_i2c_write);
> 
> +void dw_hdmi_set_high_tmds_clock_ratio(struct dw_hdmi *hdmi)
> +{
> + unsigned long mtmdsclock = hdmi->hdmi_data.video_mode.mpixelclock;
> +
> + /* Control for TMDS Bit Period/TMDS Clock-Period Ratio */
> + if (hdmi->connector.display_info.hdmi.scdc.supported) {
> + if (mtmdsclock > 34000)

You use the 3.4GHz frequency in a few places, how about creating a macro ?

> + drm_scdc_set_high_tmds_clock_ratio(hdmi->ddc, 1);
> + else
> + drm_scdc_set_high_tmds_clock_ratio(hdmi->ddc, 0);
> + }
> +}
> +EXPORT_SYMBOL_GPL(dw_hdmi_set_high_tmds_clock_ratio);
> +
>  static void dw_hdmi_phy_enable_powerdown(struct dw_hdmi *hdmi, bool enable)
> {
>   hdmi_mask_writeb(hdmi, !enable, HDMI_PHY_CONF0,
> @@ -1340,11 +1355,12 @@ static void hdmi_tx_hdcp_config(struct dw_hdmi
> *hdmi)
> 
>  static void hdmi_config_AVI(struct dw_hdmi *hdmi, struct drm_display_mode
> *mode) {
> + bool is_hdmi2_sink = hdmi->connector.display_info.hdmi.scdc.supported;
>   struct hdmi_avi_infoframe frame;
>   u8 val;
> 
>   /* Initialise info frame from DRM mode */
> - drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
> + drm_hdmi_avi_infoframe_from_display_mode(, mode, is_hdmi2_sink);
> 
>   if (hdmi_bus_fmt_is_yuv444(hdmi->hdmi_data.enc_out_bus_format))
>   frame.colorspace = HDMI_COLORSPACE_YUV444;
> @@ -1503,7 +1519,8 @@ static void
> hdmi_config_vendor_specific_infoframe(struct dw_hdmi *hdmi, static void
> hdmi_av_composer(struct dw_hdmi *hdmi,
>const struct drm_display_mode *mode)
>  {
> - u8 inv_val;
> + u8 inv_val, bytes;
> + struct drm_hdmi_info *hdmi_info = >connector.display_info.hdmi;
>   struct hdmi_vmode *vmode = >hdmi_data.video_mode;
>   int hblank, vblank, h_de_hs, v_de_vs, hsync_len, vsync_len;
>   unsigned int vdisplay;
> @@ -1513,7 +1530,9 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
>   dev_dbg(hdmi->dev, "final pixclk = %d\n", vmode->mpixelclock);
> 
>   /* Set up HDMI_FC_INVIDCONF */
> - inv_val = (hdmi->hdmi_data.hdcp_enable ?
> + inv_val = (hdmi->hdmi_data.hdcp_enable ||
> +vmode->mpixelclock > 34000 ||
> +hdmi_info->scdc.scrambling.low_rates ?
>   HDMI_FC_INVIDCONF_HDCP_KEEPOUT_ACTIVE :
>   HDMI_FC_INVIDCONF_HDCP_KEEPOUT_INACTIVE);
> 
> @@ -1562,6 +1581,26 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
>   vsync_len /= 2;
>   }
> 
> + /* Scrambling Control */
> + if (hdmi_info->scdc.supported) {
> + if (vmode->mpixelclock > 34000 ||
> + hdmi_info->scdc.scrambling.low_rates) {
> + drm_scdc_readb(>i2c->adap, SCDC_SINK_VERSION,
> +);
> + drm_scdc_writeb(>i2c->adap, SCDC_SOURCE_VERSION,
> + bytes);

Shouldn't the source version be min(sink version, highest supported source 
version) ?

> + drm_scdc_set_scrambling(>i2c->adap, 1);
> + hdmi_writeb(hdmi, (u8)~HDMI_MC_SWRSTZ_TMDSSWRST_REQ,
> + HDMI_MC_SWRSTZ);
> + hdmi_writeb(hdmi, 1, HDMI_FC_SCRAMBLER_CTRL);
> + } else {
> + hdmi_writeb(hdmi, 0, HDMI_FC_SCRAMBLER_CTRL);
> + hdmi_writeb(hdmi, 

[PATCH v3 3/4] iio: adc: add STMPE ADC devicetree bindings

[Philippe Schenker]

From: Stefan Agner 

This adds the devicetree bindings for the STMPE ADC.

Signed-off-by: Stefan Agner 
Signed-off-by: Max Krummenacher 
Signed-off-by: Philippe Schenker 
---

Changes in v3:
 - Reformatted documentation for touchscreen to use tabs and have a better
   overview of the settings.
 - Added note which adc-settings will take precedence.
 - changed typo in sample-time setting from 144 clocks to 124 clocks, as stated
   in the datasheet.

Changes in v2:
 - Moved the bindings for ADC to the overlying mfd.
 - Reformatted for better readability

 .../devicetree/bindings/iio/adc/stmpe-adc.txt | 21 +++
 .../bindings/input/touchscreen/stmpe.txt  | 60 ---
 .../devicetree/bindings/mfd/stmpe.txt | 28 ++---
 3 files changed, 80 insertions(+), 29 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt

diff --git a/Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt 
b/Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
new file mode 100644
index ..480e66422625
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
@@ -0,0 +1,21 @@
+STMPE ADC driver
+
+
+Required properties:
+ - compatible: "st,stmpe-adc"
+
+Optional properties:
+Note that the ADC is shared with the STMPE touchscreen. ADC related settings
+have to be done in the mfd.
+- st,norequest-mask: bitmask specifying which ADC channels should _not_ be
+  requestable due to different usage (e.g. touch)
+
+Node name must be stmpe_adc and should be child node of stmpe node to
+which it belongs.
+
+Example:
+
+   stmpe_adc {
+   compatible = "st,stmpe-adc";
+   st,norequest-mask = <0x0F>; /* dont use ADC CH3-0 */
+   };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt 
b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
index 127baa31a77a..414586513a02 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
@@ -5,36 +5,52 @@ Required properties:
  - compatible: "st,stmpe-ts"
 
 Optional properties:
-- st,sample-time: ADC converstion time in number of clock.  (0 -> 36 clocks, 1 
->
-  44 clocks, 2 -> 56 clocks, 3 -> 64 clocks, 4 -> 80 clocks, 5 -> 96 clocks, 6
-  -> 144 clocks), recommended is 4.
-- st,mod-12b: ADC Bit mode (0 -> 10bit ADC, 1 -> 12bit ADC)
-- st,ref-sel: ADC reference source (0 -> internal reference, 1 -> external
-  reference)
-- st,adc-freq: ADC Clock speed (0 -> 1.625 MHz, 1 -> 3.25 MHz, 2 || 3 -> 6.5 
MHz)
-- st,ave-ctrl: Sample average control (0 -> 1 sample, 1 -> 2 samples, 2 -> 4
-  samples, 3 -> 8 samples)
-- st,touch-det-delay: Touch detect interrupt delay (0 -> 10 us, 1 -> 50 us, 2 
->
-  100 us, 3 -> 500 us, 4-> 1 ms, 5 -> 5 ms, 6 -> 10 ms, 7 -> 50 ms) recommended
-  is 3
-- st,settling: Panel driver settling time (0 -> 10 us, 1 -> 100 us, 2 -> 500 
us, 3
-  -> 1 ms, 4 -> 5 ms, 5 -> 10 ms, 6 for 50 ms, 7 -> 100 ms) recommended is 2
-- st,fraction-z: Length of the fractional part in z (fraction-z ([0..7]) = 
Count of
-  the fractional part) recommended is 7
-- st,i-drive: current limit value of the touchscreen drivers (0 -> 20 mA 
typical 35
-  mA max, 1 -> 50 mA typical 80 mA max)
+- st,ave-ctrl  : Sample average control
+   0 -> 1 sample
+   1 -> 2 samples
+   2 -> 4 samples
+   3 -> 8 samples
+- st,touch-det-delay   : Touch detect interrupt delay (recommended is 3)
+   0 -> 10 us  5 -> 5 ms
+   1 -> 50 us  6 -> 10 ms
+   2 -> 100 us 7 -> 50 ms
+   3 -> 500 us
+   4-> 1 ms
+- st,settling  : Panel driver settling time (recommended is 2)
+   0 -> 10 us  5 -> 10 ms
+   1 -> 100 us 6 for 50 ms
+   2 -> 500 us 7 -> 100 ms
+   3 -> 1 ms
+   4 -> 5 ms
+- st,fraction-z: Length of the fractional part in z 
(recommended is 7)
+ (fraction-z ([0..7]) = Count of the fractional part)
+- st,i-drive   : current limit value of the touchscreen drivers
+   0 -> 20 mA (typical 35mA max)
+   1 -> 50 mA (typical 80 mA max)
+
+Optional properties common with MFD (deprecated):
+ - st,sample-time  : ADC conversion time in number of clock.
+   0 -> 36 clocks  4 -> 80 clocks 
(recommended)
+   1 -> 44 clocks  5 -> 96 clocks
+   2 -> 56 clocks  6 -> 124 clocks
+   3 

[PATCH v3 4/4] ARM: dts: Add stmpe-adc driver to relevant devicetrees

[Philippe Schenker]

From: Philippe Schenker 

Activate the stmpe-adc driver as found on Apalis/Colibri iMX6/T30 modules

Signed-off-by: Philippe Schenker 
---

Changes in v3:
 - None

Changes in v2:
 - Put common ADC settings in mfd

 arch/arm/boot/dts/imx6qdl-apalis.dtsi  | 22 ++
 arch/arm/boot/dts/imx6qdl-colibri.dtsi | 23 +++
 arch/arm/boot/dts/tegra30-apalis.dtsi  | 22 ++
 arch/arm/boot/dts/tegra30-colibri.dtsi | 22 ++
 4 files changed, 57 insertions(+), 32 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi 
b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
index 3dc99dd8dde1..8db476d8978d 100644
--- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
@@ -331,11 +331,18 @@
id = <0>;
blocks = <0x5>;
irq-trigger = <0x1>;
+   /* 3.25 MHz ADC clock speed */
+   st,adc-freq = <1>;
+   /* 12-bit ADC */
+   st,mod-12b = <1>;
+   /* internal ADC reference */
+   st,ref-sel = <0>;
+   /* ADC converstion time: 80 clocks */
+   st,sample-time = <4>;
+   /* forbid to use ADC channels 3-0 (touch) */
 
stmpe_touchscreen {
compatible = "st,stmpe-ts";
-   /* 3.25 MHz ADC clock speed */
-   st,adc-freq = <1>;
/* 8 sample average control */
st,ave-ctrl = <3>;
/* 7 length fractional part in z */
@@ -345,17 +352,16 @@
 * current limit value
 */
st,i-drive = <1>;
-   /* 12-bit ADC */
-   st,mod-12b = <1>;
-   /* internal ADC reference */
-   st,ref-sel = <0>;
-   /* ADC converstion time: 80 clocks */
-   st,sample-time = <4>;
/* 1 ms panel driver settling time */
st,settling = <3>;
/* 5 ms touch detect interrupt delay */
st,touch-det-delay = <5>;
};
+
+   stmpe_adc {
+   compatible = "st,stmpe-adc";
+   st,norequest-mask = <0x0F>;
+   };
};
 };
 
diff --git a/arch/arm/boot/dts/imx6qdl-colibri.dtsi 
b/arch/arm/boot/dts/imx6qdl-colibri.dtsi
index 87e15e7cb32b..2e303d79c7f8 100644
--- a/arch/arm/boot/dts/imx6qdl-colibri.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-colibri.dtsi
@@ -262,11 +262,18 @@
id = <0>;
blocks = <0x5>;
irq-trigger = <0x1>;
+   /* 3.25 MHz ADC clock speed */
+   st,adc-freq = <1>;
+   /* 12-bit ADC */
+   st,mod-12b = <1>;
+   /* internal ADC reference */
+   st,ref-sel = <0>;
+   /* ADC converstion time: 80 clocks */
+   st,sample-time = <4>;
+   /* forbid to use ADC channels 3-0 (touch) */
 
stmpe_touchscreen {
compatible = "st,stmpe-ts";
-   /* 3.25 MHz ADC clock speed */
-   st,adc-freq = <1>;
/* 8 sample average control */
st,ave-ctrl = <3>;
/* 7 length fractional part in z */
@@ -276,17 +283,17 @@
 * current limit value
 */
st,i-drive = <1>;
-   /* 12-bit ADC */
-   st,mod-12b = <1>;
-   /* internal ADC reference */
-   st,ref-sel = <0>;
-   /* ADC converstion time: 80 clocks */
-   st,sample-time = <4>;
/* 1 ms panel driver settling time */
st,settling = <3>;
/* 5 ms touch detect interrupt delay */
st,touch-det-delay = <5>;
};
+
+   stmpe_adc {
+   compatible = "st,stmpe-adc";
+   /* 3.25 MHz ADC clock speed */
+   st,norequest-mask = <0x0F>;
+   };
};
 };
 
diff --git a/arch/arm/boot/dts/tegra30-apalis.dtsi 
b/arch/arm/boot/dts/tegra30-apalis.dtsi
index 7f112f192fe9..850b0d13549a 100644
--- a/arch/arm/boot/dts/tegra30-apalis.dtsi
+++ b/arch/arm/boot/dts/tegra30-apalis.dtsi
@@ -976,11 +976,18 @@
id = <0>;
blocks = <0x5>;
irq-trigger = <0x1>;
+   /* 3.25 MHz ADC clock speed */
+   st,adc-freq = <1>;
+   /* 12-bit ADC */
+   st,mod-12b = <1>;
+   /* internal ADC reference */
+

Re: [RFC PATCH 2/3] mm, thp, proc: report THP eligibility for each vma

[Vlastimil Babka]

On 11/20/18 11:35 AM, Michal Hocko wrote:
> From: Michal Hocko 
> 
> Userspace falls short when trying to find out whether a specific memory
> range is eligible for THP. There are usecases that would like to know
> that
> http://lkml.kernel.org/r/alpine.deb.2.21.1809251248450.50...@chino.kir.corp.google.com
> : This is used to identify heap mappings that should be able to fault thp
> : but do not, and they normally point to a low-on-memory or fragmentation
> : issue.
> 
> The only way to deduce this now is to query for hg resp. nh flags and
> confronting the state with the global setting. Except that there is
> also PR_SET_THP_DISABLE that might change the picture. So the final
> logic is not trivial. Moreover the eligibility of the vma depends on
> the type of VMA as well. In the past we have supported only anononymous
> memory VMAs but things have changed and shmem based vmas are supported
> as well these days and the query logic gets even more complicated
> because the eligibility depends on the mount option and another global
> configuration knob.
> 
> Simplify the current state and report the THP eligibility in
> /proc//smaps for each existing vma. Reuse transparent_hugepage_enabled
> for this purpose. The original implementation of this function assumes
> that the caller knows that the vma itself is supported for THP so make
> the core checks into __transparent_hugepage_enabled and use it for
> existing callers. __show_smap just use the new transparent_hugepage_enabled
> which also checks the vma support status (please note that this one has
> to be out of line due to include dependency issues).
> 
> Signed-off-by: Michal Hocko 

Not thrilled by this, but kernel is always better suited to report this,
than userspace piecing it together from multiple sources, relying on
possibly outdated knowledge of kernel implementation details...

Acked-by: Vlastimil Babka 

A nitpick:

> ---
>  Documentation/filesystems/proc.txt |  3 +++
>  fs/proc/task_mmu.c |  2 ++
>  include/linux/huge_mm.h| 13 -
>  mm/huge_memory.c   | 12 +++-
>  mm/memory.c|  4 ++--
>  5 files changed, 30 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/filesystems/proc.txt 
> b/Documentation/filesystems/proc.txt
> index b1fda309f067..06562bab509a 100644
> --- a/Documentation/filesystems/proc.txt
> +++ b/Documentation/filesystems/proc.txt
> @@ -425,6 +425,7 @@ SwapPss:   0 kB
>  KernelPageSize:4 kB
>  MMUPageSize:   4 kB
>  Locked:0 kB
> +THPeligible:   0

I would use THP_Eligible. There are already fields with underscore in smaps.

Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state

[Vokáč Michal]

On 22.11.2018 20:03, Uwe Kleine-König wrote:
> On Thu, Nov 22, 2018 at 04:46:39PM +, Vokáč Michal wrote:
>> On 22.11.2018 17:23, Uwe Kleine-König wrote:
>>> On Thu, Nov 22, 2018 at 03:42:14PM +, Vokáč Michal wrote:
 On 16.11.2018 09:25, Uwe Kleine-König wrote:
> On Fri, Nov 16, 2018 at 08:34:30AM +0100, Lothar Waßmann wrote:
>> No. You can disable the output driver via pinctrl, so that only the
>> selected pull-up/down is relevant. The pin function and GPIO register
>> settings don't matter at all in this case.

 Lothar, please can you be more specific how would you do that? IFAIK the
 pull-up/down internal resistors have effect only if the pin is configured
 as GPIO *input* (on i.MX6 at least). See the TRM, 29.4.2.2 Output driver:

 "Internal pull-up, pull-down resistors, and pad keeper are disabled in
  output mode."
> 
> This would mean you'd have to rely on an external pull up for your use
> case. I wouldn't be surprised however if DSE=0 wouldn't count as "output
> mode". Given the reliability of NXP documentation I wouldn't bet neither
> on one nor the other possibility.

Yeah, the NXP documentation sometimes does not really match reality.
My use case is based on the fact that I configure the pin as input in
the driver. Then it works just fine.

>>> So I'd expect this to really work on i.MX6 but not the earlier SoCs
>>> without a gpio specifier.
>>
>> Maybe you would expect it to work but I already tested and measured
>> that weeks ago ;) It did not work.
> 
> Which pin/gpio do we talk about? Which i.MX6 variant did you test this
> on? (Assuming i.MX6D or i.MX6Q and PAD_DISP0_DATA09, did you try setting
> 
>   IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA09 (0x020E0194) = 0x0005
>   IOMUXC_SW_PAD_CTL_PAD_DISP0_DATA09 (0x020E04A8) = 0xb080
> 
> and then play with GPIO 4.30 direction and output value?)

My test setup is as follows:
- SoC is i.MX6DL or i.MX6S - I have three board variants in total.
- Pin used for PWM/GPIO is PAD_GPIO9.
- The pin is not connected to any circuit. Just a test point.
- pinctrl setup in DT:
   - for "pwm":
 - fsl,pins = 
 - IOMUXC_SW_MUX_CTL_PAD_GPIO09 = 0x0004
 - IOMUXC_SW_PAD_CTL_PAD_GPIO09 = 0x0008

   - for "gpio":
- fsl,pins = 
- IOMUXC_SW_MUX_CTL_PAD_GPIO09 = 0x0005
- IOMUXC_SW_PAD_CTL_PAD_GPIO09 = 0xb000

Test scenario:

- In bootloader configure the pin as GPIO output, set it LOW (0V).
   I set it LOW to start in the oposite state than I want to end up in.
- Boot Linux
- Use sysfs to configure the PWM to produce some signal.
- In the PWM driver select the "pwm" pinctrl state.
- Measure the output - expected waveform on the scope.
- Use sysfs to stop the PWM "echo 0 > /sys/class/pwm/pwmchip0/pwm0/enable°
- In the PWM driver select the "gpio" pinctrl state.
- Then in the PWM driver:

a) non-working variant
- Do not request the GPIO - so do not touch its pad control reg.
   It is set as output from the bootloader, data register = 0.
- Measure voltage on the output
   - against GND = 0V
   - against VCC = 0V
- Measure resistance against VCC: Hi-Z

The pin is in Hi-Z mode. That is fine but that does not satisfy any
logic level.

b) working variant
- Request the GPIO, configure it as input.
- Measure voltage on the output
   - against GND = VCC (3.3V)
   - against VCC = 0V
- Measure resistance against VCC = 91.1kOhm

The pull-up is active.

I can repeat the results on both i.MX6DL and i.MX6S on pwm1 and pwm4.
All pull-up and pull-down combinations gave me the expected results
only if the pin is configured as input. So if I repeat the test and
do not touch the pin in bootloader at all, it works as well even if
I do not request/configure the GPIO in the PWM driver.

But we can not rely on the fact that the pin is correctly configured
from bootloader or that it is in the after-reset state. It should
just work regardless of what state it was left in.

Best regards,
Michal

[PATCH] locking/atomics: build atomic headers as required

[Mark Rutland]

Andrew and Ingo report that the check-atomics.sh script is simply too
slow to run for every kernel build, and it's impractical to make it
faster without rewriting it in something other than shell.

Rather than committing the generated headers, let's regenerate these
as-required for a pristine tree.

That ensures they're always up-to-date, allows them to be built in
parallel, and avoid redundant rebuilds, which is a 2-8s saving per
incremental build. Since the results are not committed, it's very
obvious that they should not be modified directly. If we need to
generate more headers in future, it's easy to extend Makefile.genheader
to permit this.

I've verified that this works in the cases we previously had issues with
(out-of-tree builds and where scripts have no execute permissions), and
have tested these cases for both x86_64 and arm64.

The diffstat looks nice, at least...

Signed-off-by: Mark Rutland 
Cc: Andrew Morton 
Cc: Boqun Feng 
Cc: Borislav Petkov 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Will Deacon 
Cc: linux-kernel@vger.kernel.org
---
 Kbuild|   18 +-
 Makefile  |8 +-
 arch/arm64/include/asm/atomic.h   |2 +-
 arch/x86/include/asm/atomic.h |2 +-
 include/asm-generic/atomic-instrumented.h | 1787 --
 include/asm-generic/atomic-long.h | 1012 -
 include/linux/atomic-fallback.h   | 2294 -
 include/linux/atomic.h|4 +-
 scripts/Makefile.genheader|   23 +
 scripts/atomic/check-atomics.sh   |   19 -
 10 files changed, 35 insertions(+), 5134 deletions(-)
 delete mode 100644 include/asm-generic/atomic-instrumented.h
 delete mode 100644 include/asm-generic/atomic-long.h
 delete mode 100644 include/linux/atomic-fallback.h
 create mode 100644 scripts/Makefile.genheader
 delete mode 100755 scripts/atomic/check-atomics.sh

Andrew, Ingo, 

Could you please let me know whether you're happy with this?

This is based on the tip locking/core branch.

Locally, for a -j64 build this saves me ~2s for a pristine tree, and ~5s
for a rebuild:

  # before, pristine
  make -j64 -s  195.32s user 15.65s system 1670% cpu 12.631 total

  # before, rebuild
  make -j64 -s  2.55s user 1.64s system 64% cpu 6.468 total

  # after, pristine
  make -j64 -s  194.46s user 15.82s system 1965% cpu 10.701 total

  # after, rebuild
  make -j64 -s  2.34s user 1.02s system 179% cpu 1.865 total

Thanks,
Mark.

diff --git a/Kbuild b/Kbuild
index 780048056ac5..005304205482 100644
--- a/Kbuild
+++ b/Kbuild
@@ -6,8 +6,7 @@
 # 2) Generate timeconst.h
 # 3) Generate asm-offsets.h (may need bounds.h and timeconst.h)
 # 4) Check for missing system calls
-# 5) check atomics headers are up-to-date
-# 6) Generate constants.py (may need bounds.h)
+# 5) Generate constants.py (may need bounds.h)
 
 #
 # 1) Generate bounds.h
@@ -73,20 +72,7 @@ missing-syscalls: scripts/checksyscalls.sh $(offsets-file) 
FORCE
$(call cmd,syscalls)
 
 #
-# 5) Check atomic headers are up-to-date
-#
-
-always += old-atomics
-targets += old-atomics
-
-quiet_cmd_atomics = CALL$<
-  cmd_atomics = $(CONFIG_SHELL) $<
-
-old-atomics: scripts/atomic/check-atomics.sh FORCE
-   $(call cmd,atomics)
-
-#
-# 6) Generate constants for Python GDB integration
+# 5) Generate constants for Python GDB integration
 #
 
 extra-$(CONFIG_GDB_SCRIPTS) += build_constants_py
diff --git a/Makefile b/Makefile
index 6c40d547513c..fd871d2c2f54 100644
--- a/Makefile
+++ b/Makefile
@@ -224,7 +224,7 @@ clean-targets := %clean mrproper cleandocs
 no-dot-config-targets := $(clean-targets) \
 cscope gtags TAGS tags help% %docs check% coccicheck \
 $(version_h) headers_% archheaders archscripts \
-%asm-generic kernelversion %src-pkg
+%asm-generic genheader kernelversion %src-pkg
 no-sync-config-targets := $(no-dot-config-targets) install %install \
   kernelrelease
 
@@ -1089,7 +1089,7 @@ endif
 # prepare2 creates a makefile if using a separate output directory.
 # From this point forward, .config has been reprocessed, so any rules
 # that need to depend on updated CONFIG_* values can be checked here.
-prepare2: prepare3 outputmakefile asm-generic
+prepare2: prepare3 outputmakefile asm-generic genheader
 
 prepare1: prepare2 $(version_h) $(autoksyms_h) include/generated/utsrelease.h
$(cmd_crmodverdir)
@@ -1113,6 +1113,10 @@ uapi-asm-generic:
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.asm-generic \
src=uapi/asm obj=arch/$(SRCARCH)/include/generated/uapi/asm
 
+PHONY += genheader
+genheader:
+   $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.genheader 
obj=include/generated
+
 PHONY += prepare-objtool
 prepare-objtool: $(objtool_target)
 
diff --git a/arch/arm64/include/asm/atomic.h 

Re: [RFC PATCH 3/3] mm, proc: report PR_SET_THP_DISABLE in proc

[Vlastimil Babka]

On 11/20/18 11:35 AM, Michal Hocko wrote:
> From: Michal Hocko 
> 
> David Rientjes has reported that 1860033237d4 ("mm: make
> PR_SET_THP_DISABLE immediately active") has changed the way how
> we report THPable VMAs to the userspace. Their monitoring tool is
> triggering false alarms on PR_SET_THP_DISABLE tasks because it considers
> an insufficient THP usage as a memory fragmentation resp. memory
> pressure issue.
> 
> Before the said commit each newly created VMA inherited VM_NOHUGEPAGE
> flag and that got exposed to the userspace via /proc//smaps file.
> This implementation had its downsides as explained in the commit message
> but it is true that the userspace doesn't have any means to query for
> the process wide THP enabled/disabled status.
> 
> PR_SET_THP_DISABLE is a process wide flag so it makes a lot of sense
> to export in the process wide context rather than per-vma. Introduce

Agreed.

> a new field to /proc//status which export this status.  If
> PR_SET_THP_DISABLE is used then it reports false same as when the THP is
> not compiled in. It doesn't consider the global THP status because we
> already export that information via sysfs
> 
> Fixes: 1860033237d4 ("mm: make PR_SET_THP_DISABLE immediately active")
> Signed-off-by: Michal Hocko 

Acked-by: Vlastimil Babka 

Re: [PATCH v4 2/4] namei: O_BENEATH-style path resolution flags

[Andy Lutomirski]

> On Nov 23, 2018, at 5:10 AM, Jürg Billeter  wrote:
>
> Hi Aleksa,
>
>> On Tue, 2018-11-13 at 01:26 +1100, Aleksa Sarai wrote:
>> * O_BENEATH: Disallow "escapes" from the starting point of the
>>  filesystem tree during resolution (you must stay "beneath" the
>>  starting point at all times). Currently this is done by disallowing
>>  ".." and absolute paths (either in the given path or found during
>>  symlink resolution) entirely, as well as all "magic link" jumping.
>
> With open_tree(2) and OPEN_TREE_CLONE, will O_BENEATH still be
> necessary?

This discussion reminds me of something I’m uncomfortable with in the
current patches: currently, most of the O_ flags determine some
property of the returned opened file.  The new O_ flags you're adding
don't -- instead, they affect the lookup of the file.  So O_BENEATH
doesn't return a descriptor that can only be used to loop up files
beneath it -- it just controls whether open(2) succeeds or fails.  It
might be nice for the naming of the flags to reflect this.  I also
don't love that we have some magic AT_ flags that work with some
syscalls and some magic O_ flags that work with others.

In this regard, I liked the AT_ naming better.  Although I don't love
adding AT_ flags because the restrict our ability to usefully use the
high bits of the fd in the future.

--Andy

Re: [PATCH v1 3/3] arm64: dts: mt7622: Drop the general purpose timer node

[Matthias Brugger]

On 12/11/2018 02:28, Ryder Lee wrote:
> The crash http://termbin.com/zitb is caused by the timer register
> into system in early pahse during kernel boot, but the clock
> sources didn't get ready at that time.
> 
> A better way is to switch to use CLK_OF_DECLARE() in driver for things
> that need them early, but this node is actually useless in MT7622.
> So we drop it.

I suppose the root cause is, that the driver doesn't check the error
timer_of_init returned.

Would you mind to test the following patch to see if this fixes the problem?

--->8
>From be91e56ed527261137335af340845eb3dd3dd33a Mon Sep 17 00:00:00 2001
From: Matthias Brugger 
Date: Fri, 23 Nov 2018 17:04:08 +0100
Subject: [PATCH] clocksource/drivers/timer-mediatek: error out on probe defer

If the clocks are not yet present, because they are loaded after
the timer is initialized, we are unable to boot.
Check if the return value of timer_of_init and return on EPROBE_DEFER.

Error seen is:
[0.008337] Failed to get clock for /timer@10004000
[0.013435] WARNING: CPU: 0 PID: 0 at ../drivers/clk/clk.c:3615
__clk_put+0xf0/0x120
[0.021453] Modules linked in:
[0.024614] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.20.0-rc1-00063-g2859d9abd7e8 #2
[0.032902] Hardware name: MediaTek MT7622 RFB1 board (DT)
[0.038580] pstate: 2085 (nzCv daIf -PAN -UAO)
[0.043538] pc : __clk_put+0xf0/0x120
[0.047328] lr : clk_put+0xc/0x18
[0.050753] sp : 09163ed0
[0.054178] x29: 09163ed0 x28: 41010018
[0.059676] x27:  x26: 
[0.065174] x25: 090cb008 x24: 80001dfd7800
[0.070672] x23: 08f934b8 x22: 80001dfdeae0
[0.076169] x21: 80001dfdeae0 x20: fdfb
[0.081668] x19: 0929ac40 x18: 
[0.087166] x17:  x16: 
[0.092664] x15: 091696c8 x14: 892cd70f
[0.098162] x13: 092cd71d x12: 09181348
[0.103661] x11: 09181000 x10: 05f5e0ff
[0.109159] x9 : 0040 x8 : 09181400
[0.114657] x7 : 80001c800270 x6 : 
[0.120155] x5 : 80001c800248 x4 : 
[0.125653] x3 :  x2 : 
[0.131151] x1 :  x0 : fdfb
[0.136649] Call trace:
[0.139175]  __clk_put+0xf0/0x120
[0.142605]  timer_of_cleanup+0x60/0x7c
[0.146572]  mtk_gpt_init+0x18c/0x1a0
[0.150359]  timer_probe+0x74/0x10c
[0.153969]  time_init+0x14/0x44
[0.157307]  start_kernel+0x29c/0x414
[0.161098] ---[ end trace c3137b005300b618 ]---

Fixes: a0858f937960 ("clocksource/drivers/timer-mediatek: Convert the driver to
timer-of")
Fixes: e3af677607d9 ("clocksource/drivers/timer-mediatek: Add support for system
timer")
Signed-off-by: Matthias Brugger 
---
 drivers/clocksource/timer-mediatek.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/timer-mediatek.c
b/drivers/clocksource/timer-mediatek.c
index eb10321f8517..d40c77a65b08 100644
--- a/drivers/clocksource/timer-mediatek.c
+++ b/drivers/clocksource/timer-mediatek.c
@@ -276,8 +276,12 @@ static int __init mtk_syst_init(struct device_node *node)
to.of_irq.handler = mtk_syst_handler;

ret = timer_of_init(node, );
-   if (ret)
+   if (ret) {
+   if (ret == -EPROBE_DEFER)
+   return ret;
+
goto err;
+   }

clockevents_config_and_register(, timer_of_rate(),
TIMER_SYNC_TICKS, 0x);
@@ -301,8 +305,12 @@ static int __init mtk_gpt_init(struct device_node *node)
to.of_irq.handler = mtk_gpt_interrupt;

ret = timer_of_init(node, );
-   if (ret)
+   if (ret) {
+   if (ret == -EPROBE_DEFER)
+   return ret;
+
goto err;
+   }

/* Configure clock source */
mtk_gpt_setup(, TIMER_CLK_SRC, GPT_CTRL_OP_FREERUN);
-- 
2.19.1

Re: [PATCH 2/2] page cache: Store only head pages in i_pages

[Matthew Wilcox]

On Fri, Nov 23, 2018 at 01:56:44PM +0300, Kirill A. Shutemov wrote:
> On Thu, Nov 22, 2018 at 01:32:24PM -0800, Matthew Wilcox wrote:
> > Transparent Huge Pages are currently stored in i_pages as pointers to
> > consecutive subpages.  This patch changes that to storing consecutive
> > pointers to the head page in preparation for storing huge pages more
> > efficiently in i_pages.
> 
> I probably miss something, I don't see how it wouldn't break
> split_huge_page().
> 
> I don't see what would replace head pages in i_pages with
> formerly-tail-pages?

You're quite right.  Where's your test-suite?  ;-)

I think this should do the job:

+++ b/mm/huge_memory.c
@@ -2464,6 +2464,9 @@ static void __split_huge_page(struct page *page, struct 
list_head *list,
if (IS_ENABLED(CONFIG_SHMEM) && PageSwapBacked(head))
shmem_uncharge(head->mapping->host, 1);
put_page(head + i);
+   } else if (!PageAnon(page)) {
+   __xa_store(>mapping->i_pages, head[i].index,
+   head + i, 0);
}
}
 

Having looked at this area, I think there was actually a bug in the patch
you wrote that I'm cribbing from.  You inserted the tail pages before
calling __split_huge_page_tail(), so a racing lookup would have found
a tail page before it got transformed into a non-tail page.

Re: Sleeping in user_access section

[Russell King - ARM Linux]

On Fri, Nov 23, 2018 at 11:57:31AM +, Julien Thierry wrote:
> 
> 
> On 23/11/18 10:50, Russell King - ARM Linux wrote:
> >On Fri, Nov 23, 2018 at 01:57:12AM -0800, h...@zytor.com wrote:
> >>You should never call a sleeping function from a user_access section.
> >>It is intended for very limited regions.
> >
> >So, what happens if the "unsafe" user access causes a page fault that
> >ends up sleeping?
> >
> 
> Thanks for pointing that out.
> 
> On the arm64 side, PAN state is saved in spsr and (if PAN feature is enabled
> in SCTLR) PAN bit gets set (disabling the user accesses). For software PAN
> we follow the same behaviour on exception entry. So upon exception we
> implicitly exit user_access mode and then re-enter it when returning from
> the exception.
> 
> On x86, the EFLAGS.AC bit is also saved upon exception and I think it is
> cleared upon exception entry so there is implicit exit from the user_access
> mode when taking exception/interrupt.
> 
> This however is just how those two architectures happen to behave and
> doesn't seem to be specified as part of the user_access API...
> 
> Which is why I'd like to clarify the semantics of user_access region wrt
> sleeping functions.

Explicitly calling a sleeping function may not be recommended, but
it's a rather fundamental fact of the Linux kernel that if we want
to access userspace, we must be either prepared to sleep, or fail
the access and return an error.

Looking at kernel/exit.c and kernel/compat.c, I see no sign of any
retry mechanism in the current call sites, so any failed user access
would return an error to userspace - which is not the behaviour that
userspace would expect.

It's possible that, when user_access_begin() et.al. are implemented,
access_ok() also comes with the requirement to make sure that the
userspace pages are accessible, but even _that_ would be racy,
because there's no way to pin the pages, so another thread/CPU could
page those user pages back out... leading to a fault.

So, realistically, with how user_access_begin()..user_access_end()
is currently being used, an architecture fundamentally has to be
prepared for threads to sleep within that section of code through
the action of the page fault handling.  I can't see any other
realistic possibility here.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

[PATCH 05/12] PCI: aardvark: add suspend to RAM support

[Miquel Raynal]

Add suspend and resume callbacks. The priority of these are
"_noirq()", to workaround early access to the registers done by the
PCI core through the ->read()/->write() callbacks at resume time.

Signed-off-by: Miquel Raynal 
---
 drivers/pci/controller/pci-aardvark.c | 52 +++
 1 file changed, 52 insertions(+)

diff --git a/drivers/pci/controller/pci-aardvark.c 
b/drivers/pci/controller/pci-aardvark.c
index 108b3f15c410..7ecf1ac4036b 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -1108,6 +1108,55 @@ static int advk_pcie_setup_clk(struct advk_pcie *pcie)
return ret;
 }
 
+static int __maybe_unused advk_pcie_suspend(struct device *dev)
+{
+   struct advk_pcie *pcie = dev_get_drvdata(dev);
+
+   advk_pcie_disable_phy(pcie);
+
+   clk_disable_unprepare(pcie->clk);
+
+   return 0;
+}
+
+static int __maybe_unused advk_pcie_resume(struct device *dev)
+{
+   struct advk_pcie *pcie = dev_get_drvdata(dev);
+   int ret;
+
+   ret = clk_prepare_enable(pcie->clk);
+   if (ret)
+   return ret;
+
+   /*
+* Empirical delay needed after enabling the clock and before
+* accessing any register.
+*/
+   msleep(10);
+
+   ret = advk_pcie_enable_phy(pcie);
+   if (ret)
+   return ret;
+
+   advk_pcie_hard_reset(pcie);
+
+   advk_pcie_setup_hw(pcie);
+
+   advk_sw_pci_bridge_init(pcie);
+
+   return 0;
+}
+
+/*
+ * The PCI core will try to reconfigure the bus quite early in the resume path.
+ * We must use the _noirq() alternatives to ensure the controller is ready when
+ * the core uses the ->read()/->write() callbacks.
+ */
+static const struct dev_pm_ops advk_pcie_dev_pm_ops = {
+   SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(advk_pcie_suspend,
+ advk_pcie_resume)
+};
+
 static int advk_pcie_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -1188,6 +1237,8 @@ static int advk_pcie_probe(struct platform_device *pdev)
return ret;
}
 
+   dev_set_drvdata(dev, pcie);
+
return 0;
 }
 
@@ -1200,6 +1251,7 @@ static struct platform_driver advk_pcie_driver = {
.driver = {
.name = "advk-pcie",
.of_match_table = advk_pcie_of_match_table,
+   .pm = _pcie_dev_pm_ops,
/* Driver unloading/unbinding currently not supported */
.suppress_bind_attrs = true,
},
-- 
2.19.1

[PATCH 02/12] PCI: aardvark: add reset GPIO support

[Miquel Raynal]

The IP supports a reset GPIO. When S2RAM will be added, we must ensure
the reset line (if any) is deasserted when resuming. Add support for
it.

Signed-off-by: Miquel Raynal 
---
 drivers/pci/controller/pci-aardvark.c | 57 +++
 1 file changed, 57 insertions(+)

diff --git a/drivers/pci/controller/pci-aardvark.c 
b/drivers/pci/controller/pci-aardvark.c
index b95eb2aa00bb..1d31d74ddab7 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -9,6 +9,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -17,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "../pci.h"
@@ -201,6 +203,7 @@ struct advk_pcie {
u16 msi_msg;
int root_bus_nr;
struct pci_bridge_emul bridge;
+   struct gpio_desc *reset_gpio;
 };
 
 static inline void advk_writel(struct advk_pcie *pcie, u32 val, u64 reg)
@@ -973,6 +976,55 @@ static int advk_pcie_parse_request_of_pci_ranges(struct 
advk_pcie *pcie)
return err;
 }
 
+static int advk_pcie_hard_reset(struct advk_pcie *pcie)
+{
+   if (!pcie->reset_gpio)
+   return -EINVAL;
+
+   gpiod_set_value_cansleep(pcie->reset_gpio, 0);
+   msleep(1);
+   gpiod_set_value_cansleep(pcie->reset_gpio, 1);
+
+   return 0;
+}
+
+static int advk_pcie_setup_reset_gpio(struct advk_pcie *pcie)
+{
+   struct device *dev = >pdev->dev;
+   enum of_gpio_flags of_flags;
+   unsigned long gpio_flags;
+   int gpio_nb;
+   int ret;
+
+   gpio_nb = of_get_named_gpio_flags(dev->of_node, "reset-gpios", 0,
+ _flags);
+   if (gpio_nb == -EPROBE_DEFER)
+   return gpio_nb;
+
+   /* Old bindings miss the reset GPIO handle */
+   if (!gpio_is_valid(gpio_nb)) {
+   dev_warn(dev, "Reset GPIO unavailable\n");
+   return 0;
+   }
+
+   if (of_flags & OF_GPIO_ACTIVE_LOW)
+   gpio_flags = GPIOF_ACTIVE_LOW |
+GPIOF_OUT_INIT_LOW;
+   else
+   gpio_flags = GPIOF_OUT_INIT_HIGH;
+
+   ret = devm_gpio_request_one(dev, gpio_nb, gpio_flags,
+   "pcie-aardvark-reset");
+   if (ret) {
+   dev_err(dev, "Failed to retrieve reset GPIO (%d)\n", ret);
+   return ret;
+   }
+
+   pcie->reset_gpio = gpio_to_desc(gpio_nb);
+
+   return 0;
+}
+
 static int advk_pcie_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -1008,6 +1060,11 @@ static int advk_pcie_probe(struct platform_device *pdev)
return ret;
}
 
+   ret = advk_pcie_setup_reset_gpio(pcie);
+   if (ret)
+   return ret;
+
+   advk_pcie_hard_reset(pcie);
advk_pcie_setup_hw(pcie);
 
advk_sw_pci_bridge_init(pcie);
-- 
2.19.1

[PATCH 03/12] PCI: aardvark: add PHY support

[Miquel Raynal]

The IP needs its PHY to be properly configured to work. While the PHY
is usually already configured by the bootloader, we will need this
feature when adding S2RAM support. Take care of registering and
configuring the PHY from the driver itself.

Signed-off-by: Miquel Raynal 
---
 drivers/pci/controller/pci-aardvark.c | 62 +++
 1 file changed, 62 insertions(+)

diff --git a/drivers/pci/controller/pci-aardvark.c 
b/drivers/pci/controller/pci-aardvark.c
index 1d31d74ddab7..da695572a2ed 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -204,6 +205,7 @@ struct advk_pcie {
int root_bus_nr;
struct pci_bridge_emul bridge;
struct gpio_desc *reset_gpio;
+   struct phy *phy;
 };
 
 static inline void advk_writel(struct advk_pcie *pcie, u32 val, u64 reg)
@@ -1025,6 +1027,62 @@ static int advk_pcie_setup_reset_gpio(struct advk_pcie 
*pcie)
return 0;
 }
 
+static void advk_pcie_disable_phy(struct advk_pcie *pcie)
+{
+   phy_power_off(pcie->phy);
+   phy_exit(pcie->phy);
+}
+
+static int advk_pcie_enable_phy(struct advk_pcie *pcie)
+{
+   int ret;
+
+   if (!pcie->phy)
+   return 0;
+
+   ret = phy_init(pcie->phy);
+   if (ret)
+   return ret;
+
+   ret = phy_set_mode(pcie->phy, PHY_MODE_PCIE);
+   if (ret) {
+   phy_exit(pcie->phy);
+   return ret;
+   }
+
+   ret = phy_power_on(pcie->phy);
+   if (ret) {
+   phy_exit(pcie->phy);
+   return ret;
+   }
+
+   return 0;
+}
+
+static int advk_pcie_setup_phy(struct advk_pcie *pcie)
+{
+   struct device *dev = >pdev->dev;
+   struct device_node *node = dev->of_node;
+   int ret = 0;
+
+   pcie->phy = devm_of_phy_get(dev, node, NULL);
+   if (IS_ERR(pcie->phy) && (PTR_ERR(pcie->phy) == -EPROBE_DEFER))
+   return PTR_ERR(pcie->phy);
+
+   /* Old bindings miss the PHY handle */
+   if (IS_ERR(pcie->phy)) {
+   dev_warn(dev, "PHY unavailable (%ld)\n", PTR_ERR(pcie->phy));
+   pcie->phy = NULL;
+   return 0;
+   }
+
+   ret = advk_pcie_enable_phy(pcie);
+   if (ret)
+   dev_err(dev, "Failed to initialize PHY (%d)\n", ret);
+
+   return ret;
+}
+
 static int advk_pcie_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -1060,6 +1118,10 @@ static int advk_pcie_probe(struct platform_device *pdev)
return ret;
}
 
+   ret = advk_pcie_setup_phy(pcie);
+   if (ret)
+   return ret;
+
ret = advk_pcie_setup_reset_gpio(pcie);
if (ret)
return ret;
-- 
2.19.1

[PATCH 00/12] Bring suspend to RAM support to PCIe Aardvark driver

[Miquel Raynal]

Hello,

As part of an effort to bring suspend to RAM support to Armada 3700
SoCs (main target: ESPRESSObin), this series handles the work around
the PCIe IP.

First, more configuration is done in the 'setup' helper as inspired
from the U-Boot driver. This is needed to entirely initialize the IP
during future resume operation (patch 1).

Then, reset GPIO, PHY and clock support are introduced (patch 2-4). As
current device trees do not provide the corresponding properties, not
finding one of these properties is not an error and just produces a
warning. However, if the property is present, an error during PHY
initialization will fail the probe of the driver.

Note: To be sure the clock will be resumed before this driver, a first
series adding links between clocks and consumers has been submitted,
see [1].

Patch 5 adds suspend/resume hooks, re-using all the above.

Finally, bindings and device trees are updated to reflect the hardware
(patch 6-12). While the clock depends on the SoC, the reset GPIO and
the PHY depends on the board so the clock is added in the
armada-37xx.dtsi file while the two other properties are added in
armada-3720-espressobin.dts.

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-November/614527.html

Thanks,
Miquèl


Miquel Raynal (12):
  PCI: aardvark: configure more registers in the configuration helper
  PCI: aardvark: add reset GPIO support
  PCI: aardvark: add PHY support
  PCI: aardvark: add clock support
  PCI: aardvark: add suspend to RAM support
  dt-bindings: PCI: aardvark: describe the reset-gpios property
  dt-bindings: PCI: aardvark: describe the clocks property
  dt-bindings: PCI: aardvark: describe the PHY property
  ARM64: dts: marvell: armada-37xx: declare PCIe reset pin
  ARM64: dts: marvell: armada-3720-espressobin: declare PCIe reset GPIO
  ARM64: dts: marvell: armada-37xx: declare PCIe clock
  ARM64: dts: marvell: armada-3720-espressobin: declare PCIe PHY

 .../devicetree/bindings/pci/aardvark-pci.txt  |   9 +
 .../dts/marvell/armada-3720-espressobin.dts   |   4 +
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi  |   5 +
 drivers/pci/controller/pci-aardvark.c | 214 ++
 4 files changed, 232 insertions(+)

-- 
2.19.1

[PATCH 01/12] PCI: aardvark: configure more registers in the configuration helper

[Miquel Raynal]

Mimic U-Boot configuration to be sure all hardware registers are set
properly. This will be needed for future S2RAM operation.

Signed-off-by: Miquel Raynal 
---
 drivers/pci/controller/pci-aardvark.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/pci/controller/pci-aardvark.c 
b/drivers/pci/controller/pci-aardvark.c
index 750081c1cb48..b95eb2aa00bb 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -100,6 +100,8 @@
 #define PCIE_CORE_CTRL2_STRICT_ORDER_ENABLEBIT(5)
 #define PCIE_CORE_CTRL2_OB_WIN_ENABLE  BIT(6)
 #define PCIE_CORE_CTRL2_MSI_ENABLE BIT(10)
+#define PCIE_PHY_REFCLK(CONTROL_BASE_ADDR + 
0x14)
+#define PCIE_PHY_REFCLK_BUF_CTRL   0x1342
 #define PCIE_MSG_LOG_REG   (CONTROL_BASE_ADDR + 0x30)
 #define PCIE_ISR0_REG  (CONTROL_BASE_ADDR + 0x40)
 #define PCIE_MSG_PM_PME_MASK   BIT(7)
@@ -243,6 +245,9 @@ static void advk_pcie_setup_hw(struct advk_pcie *pcie)
 {
u32 reg;
 
+   /* Set HW Reference Clock Buffer Control */
+   advk_writel(pcie, PCIE_PHY_REFCLK_BUF_CTRL, PCIE_PHY_REFCLK);
+
/* Set to Direct mode */
reg = advk_readl(pcie, CTRL_CONFIG_REG);
reg &= ~(CTRL_MODE_MASK << CTRL_MODE_SHIFT);
@@ -274,6 +279,15 @@ static void advk_pcie_setup_hw(struct advk_pcie *pcie)
PCIE_CORE_CTRL2_TD_ENABLE;
advk_writel(pcie, reg, PCIE_CORE_CTRL2_REG);
 
+   /* Set PCIe Device Control and Status 1 PF0 register */
+   reg = PCIE_CORE_DEV_CTRL_STATS_RELAX_ORDER_DISABLE |
+   PCIE_CORE_DEV_CTRL_STATS_SNOOP_DISABLE;
+   advk_writel(pcie, reg, PCIE_CORE_DEV_CTRL_STATS_REG);
+
+   /* Program PCIe Control 2 to disable strict ordering */
+   reg = PCIE_CORE_CTRL2_RESERVED | PCIE_CORE_CTRL2_TD_ENABLE;
+   advk_writel(pcie, reg, PCIE_CORE_CTRL2_REG);
+
/* Set GEN2 */
reg = advk_readl(pcie, PCIE_CORE_CTRL0_REG);
reg &= ~PCIE_GEN_SEL_MSK;
-- 
2.19.1

[PATCH 10/12] ARM64: dts: marvell: armada-3720-espressobin: declare PCIe reset GPIO

[Miquel Raynal]

Add a reset-gpios property to the PCIe node.

Signed-off-by: Miquel Raynal 
---
 arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts 
b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
index 094994a9c68e..76a508da80b9 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
@@ -46,6 +46,9 @@
 /* J9 */
  {
status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   reset-gpios = < 3 GPIO_ACTIVE_HIGH>;
 };
 
 /* J6 */
-- 
2.19.1

[PATCH 07/12] dt-bindings: PCI: aardvark: describe the clocks property

[Miquel Raynal]

Describe the missing gated clock feeding the PCIe IP.

Signed-off-by: Miquel Raynal 
---
 Documentation/devicetree/bindings/pci/aardvark-pci.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/aardvark-pci.txt 
b/Documentation/devicetree/bindings/pci/aardvark-pci.txt
index 252934237138..c275c3e39cde 100644
--- a/Documentation/devicetree/bindings/pci/aardvark-pci.txt
+++ b/Documentation/devicetree/bindings/pci/aardvark-pci.txt
@@ -12,6 +12,7 @@ contain the following properties:
  - #size-cells: set to <2>
  - device_type: set to "pci"
  - ranges: ranges for the PCI memory and I/O regions
+ - clocks: the clock feeding the IP
  - #interrupt-cells: set to <1>
  - msi-controller: indicates that the PCIe controller can itself
handle MSI interrupts
@@ -41,6 +42,7 @@ Example:
#address-cells = <3>;
#size-cells = <2>;
bus-range = <0x00 0xff>;
+   clocks = <_periph_clk 13>;
interrupts = ;
#interrupt-cells = <1>;
msi-controller;
-- 
2.19.1

[PATCH 08/12] dt-bindings: PCI: aardvark: describe the PHY property

[Miquel Raynal]

Document the possibility to reference a PHY.

Signed-off-by: Miquel Raynal 
---
 Documentation/devicetree/bindings/pci/aardvark-pci.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/aardvark-pci.txt 
b/Documentation/devicetree/bindings/pci/aardvark-pci.txt
index c275c3e39cde..b41c69968e38 100644
--- a/Documentation/devicetree/bindings/pci/aardvark-pci.txt
+++ b/Documentation/devicetree/bindings/pci/aardvark-pci.txt
@@ -24,6 +24,7 @@ contain the following properties:
 The following are optional properties:
 
  - reset-gpios: GPIO to reset the device
+ - phys: the PCIe PHY handle
 
 In addition, the Device Tree describing an Aardvark PCIe controller
 must include a sub-node that describes the legacy interrupt controller
@@ -55,6 +56,7 @@ Example:
<0 0 0 3 _intc 2>,
<0 0 0 4 _intc 3>;
reset-gpios = < 3 GPIO_ACTIVE_HIGH>;
+   phys = < 0>;
pcie_intc: interrupt-controller {
interrupt-controller;
#interrupt-cells = <1>;
-- 
2.19.1

[PATCH 11/12] ARM64: dts: marvell: armada-37xx: declare PCIe clock

[Miquel Raynal]

The PCIe IP is fed by a gated clock.

Signed-off-by: Miquel Raynal 
---
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi 
b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index 9f7e932c8144..854b1d59b2ca 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -418,6 +418,7 @@
#address-cells = <3>;
#size-cells = <2>;
bus-range = <0x00 0xff>;
+   clocks = <_periph_clk 13>;
interrupts = ;
#interrupt-cells = <1>;
msi-parent = <>;
-- 
2.19.1

[PATCH] thermal/intel_powerclamp: Change to use DEFINE_SHOW_ATTRIBUTE macro

[Yangtao Li]

Use macro to simplify the code.

Signed-off-by: Yangtao Li 
---
 drivers/thermal/intel_powerclamp.c | 14 +-
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/drivers/thermal/intel_powerclamp.c 
b/drivers/thermal/intel_powerclamp.c
index cde891c54cde..7571f7c2e7c9 100644
--- a/drivers/thermal/intel_powerclamp.c
+++ b/drivers/thermal/intel_powerclamp.c
@@ -708,19 +708,7 @@ static int powerclamp_debug_show(struct seq_file *m, void 
*unused)
return 0;
 }
 
-static int powerclamp_debug_open(struct inode *inode,
-   struct file *file)
-{
-   return single_open(file, powerclamp_debug_show, inode->i_private);
-}
-
-static const struct file_operations powerclamp_debug_fops = {
-   .open   = powerclamp_debug_open,
-   .read   = seq_read,
-   .llseek = seq_lseek,
-   .release= single_release,
-   .owner  = THIS_MODULE,
-};
+DEFINE_SHOW_ATTRIBUTE(powerclamp_debug);
 
 static inline void powerclamp_create_debug_files(void)
 {
-- 
2.17.0

[PATCH] clk: nomadik: Change to use DEFINE_SHOW_ATTRIBUTE macro

[Yangtao Li]

Use macro to simplify the code.

Signed-off-by: Yangtao Li 
---
 drivers/clk/clk-nomadik.c | 14 ++
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/drivers/clk/clk-nomadik.c b/drivers/clk/clk-nomadik.c
index 84a24875c629..e331634d34df 100644
--- a/drivers/clk/clk-nomadik.c
+++ b/drivers/clk/clk-nomadik.c
@@ -479,17 +479,7 @@ static int nomadik_src_clk_show(struct seq_file *s, void 
*what)
return 0;
 }
 
-static int nomadik_src_clk_open(struct inode *inode, struct file *file)
-{
-   return single_open(file, nomadik_src_clk_show, NULL);
-}
-
-static const struct file_operations nomadik_src_clk_debugfs_ops = {
-   .open   = nomadik_src_clk_open,
-   .read   = seq_read,
-.llseek = seq_lseek,
-   .release= single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(nomadik_src_clk_debugfs);
 
 static int __init nomadik_src_clk_init_debugfs(void)
 {
@@ -499,7 +489,7 @@ static int __init nomadik_src_clk_init_debugfs(void)
src_pcksr0_boot = readl(src_base + SRC_PCKSR0);
src_pcksr1_boot = readl(src_base + SRC_PCKSR1);
debugfs_create_file("nomadik-src-clk", S_IFREG | S_IRUGO,
-   NULL, NULL, _src_clk_debugfs_ops);
+   NULL, NULL, _src_clk_debugfs_fops);
return 0;
 }
 device_initcall(nomadik_src_clk_init_debugfs);
-- 
2.17.0

Re: [PATCH 09/17] irqchip: bcm283x: Switch to SPDX identifier

[Stefan Wahren]

Hi Jason,
hi Marc,

Am 10.11.18 um 16:54 schrieb Stefan Wahren:
> Adopt the SPDX license identifier headers to ease license compliance
> management.
>
> Cc: Simon Arlott 
> Cc: Eric Anholt 
> Signed-off-by: Stefan Wahren 
> ---
>  drivers/irqchip/irq-bcm2835.c | 11 +--
>  drivers/irqchip/irq-bcm2836.c | 11 +--
>  2 files changed, 2 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/irqchip/irq-bcm2835.c b/drivers/irqchip/irq-bcm2835.c
> index d2da8a1..418245d 100644
> --- a/drivers/irqchip/irq-bcm2835.c
> +++ b/drivers/irqchip/irq-bcm2835.c
> @@ -1,17 +1,8 @@
> +// SPDX-License-Identifier: GPL-2.0+
>  /*
>   * Copyright 2010 Broadcom
>   * Copyright 2012 Simon Arlott, Chris Boot, Stephen Warren
>   *
> - * 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; either version 2 of the License, or
> - * (at your option) any later version.
> - *
> - * 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.
> - *
>   * Quirk 1: Shortcut interrupts don't set the bank 1/2 register pending bits
>   *
>   * If an interrupt fires on bank 1 that isn't in the shortcuts list, bit 8
> diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
> index dfe4a46..2038693 100644
> --- a/drivers/irqchip/irq-bcm2836.c
> +++ b/drivers/irqchip/irq-bcm2836.c
> @@ -1,17 +1,8 @@
> +// SPDX-License-Identifier: GPL-2.0+
>  /*
>   * Root interrupt controller for the BCM2836 (Raspberry Pi 2).
>   *
>   * Copyright 2015 Broadcom
> - *
> - * 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; either version 2 of the License, or
> - * (at your option) any later version.
> - *
> - * 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 

Eric already made a review. Are you fine with it?

Stefan

Re: Official Linux system wrapper library?

[Szabolcs Nagy]

On 23/11/18 14:11, David Newall wrote:
> On 24/11/18 12:04 am, Florian Weimer wrote:
>> But socketcall does not exist on all architectures.  Neither does
>> getpid, it's called getxpid on some architectures.
>> ...
>> I think it would be a poor approach to expose application developers to
>> these portability issues.  We need to abstract over these differences at
>> a certain layer, and applications are too late.
> 
> Interesting.  I think the opposite.  I think exposing the OS's interfaces is 
> exactly what a c-library should do.  It might also provide
> alternative interfaces that work consistently across different platforms, but 
> in addition to, not instead of the OS interface.

you don't understand the point of the c language if you think so.

Re: [PATCH 1/2] irq/irq_sim: provide irq_sim_fire_edge()

[Bartosz Golaszewski]

śr., 21 lis 2018 o 20:15 Uwe Kleine-König
 napisał(a):
>
> Hello Bartosz,
>
> On Wed, Nov 21, 2018 at 05:34:32PM +0100, Bartosz Golaszewski wrote:
> > wt., 20 lis 2018 o 18:17 Uwe Kleine-König
> >  napisał(a):
> > >
> > > On Tue, Nov 20, 2018 at 02:40:31PM +0100, Bartosz Golaszewski wrote:
> > > > From: Bartosz Golaszewski 
> > > >
> > > > The irq_sim irqchip doesn't allow to configure the sensitivity so every
> > > > call to irq_sim_fire() fires a dummy interrupt. This used to not matter
> > > > for gpio-mockup (one of the irq_sim users) until commit fa38869b0161
> > > > ("gpiolib: Don't support irq sharing for userspace") which made it
> > > > impossible for gpio-mockup to ignore certain events (e.g. only receive
> > > > notifications about rising edge events).
> > > >
> > > > Introduce a specialized variant of irq_sim_fire() which takes another
> > > > argument called edge. allowing to specify the trigger type for the
> > > > dummy interrupt.
> > >
> > > I wonder if it's worth the effort to fix irq_sim. If you take a look in
> > > my gpio-simulator patch, it is trivial to get it right without external
> > > help with an amount of code that is usual for a driver that handles
> > > irqs.
> >
> > You're basically recommending handcrafting another local piece of code
> > for simulating interrupts - something that multiple users may be
> > interested in. You did that in your proposed gpio-simulator and I
> > still can't understand why you couldn't reuse the existing solution.
> > Even if it's broken for your use-case, it's surely easier to fix it
> > than to rewrite and duplicate it? There are very few cases where code
> > consolidation is not a good thing and I don't think this is one of
> > them.
>
> I don't say that factoring out common stuff is bad. But if in the end
> you call
>
> irq_sim_something(some, parameters, offset);
>
> with the simulator and if you don't use the irq simulator you do
>
> irq = irq_find_mapping(irqdomain, offset);
> generic_handle_irq(irq);
>
> I prefer the latter because it's only a single additional line and in
> return it's more obvious what it does because it's the same that many
> other drivers (for real hardware) also do.
>

I'm not sure I'm following you. You still need to add ~150 LOC for the
gpio_simulator_irqtrigger() worker and gpio_simulator_irq_*() routines
locally as you did in your gpio-simulator patch. A generic simulator +
using the irq_work saves you that.

Bart

Re: [PATCH] perf symbols: Cannot disassemble some routines when debuginfo present

[Jiri Olsa]

On Fri, Nov 23, 2018 at 02:25:26AM -0800, Eric Saint-Etienne wrote:
> When the kernel is compiled with -ffunction-sections and perf uses the
> kernel debuginfo, perf fails the very first symbol lookup and ends up with
> an hex offset inside [kernel.vmlinux]. It's due to how perf loads the maps.
> 
> Indeed only .text gets loaded by map_groups__find() into al->map.
> Consequently al->map address range encompass the whole code.
> But map__load() has just loaded many function maps by splitting al->map,
> which reduced al->map range drastically. Very likely the target address is
> now in one of those newly created function maps, so we need to lookup the
> map again to find that new map.
> 
> This issue is not specific to the kernel but to how the image is linked.
> For the kernel, when we're not using the kernel debuginfo, perf will
> fallback to using kallsyms and then the first lookup will work.
> 
> This patch makes sure that the event address we're looking-up is indeed
> within the map we've found, otherwise we lookup another map again.
> Only one extra lookup at most is required for the proper map to be found,
> if it exists.
> 
> Signed-off-by: Eric Saint-Etienne 
> Reviewed-by: Darren Kenny 
> ---
>  tools/perf/util/event.c | 23 ++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
> index e9c108a..a69ef52 100644
> --- a/tools/perf/util/event.c
> +++ b/tools/perf/util/event.c
> @@ -1571,7 +1571,28 @@ struct map *thread__find_map(struct thread *thread, u8 
> cpumode, u64 addr,
>*/
>   if (load_map)
>   map__load(al->map);
> - al->addr = al->map->map_ip(al->map, al->addr);
> +
> + /*
> +  * When using -ffunction-sections, only .text gets loaded by
> +  * map_groups__find() into al->map. Consequently al->map address
> +  * range encompass the whole code.
> +  *
> +  * But map__load() has just loaded many function maps by
> +  * splitting al->map, which reduced al->map range drastically.
> +  * Very likely the target address is now in one of those newly
> +  * created function maps, so we need to lookup the map again
> +  * to find that new map.
> +  */

hum, so map__load actualy can split the map to create new maps?

cold you please point me to that code? I haven't touch
this area for some time and I can't find it

thanks,
jirka

> + if (al->addr < al->map->start || al->addr >= al->map->end)
> + al->map = map_groups__find(mg, al->addr);
> +
> + /*
> +  * The new map *ought* to exist because the initial al->map
> +  * contained that address and subsequently has been split into
> +  * many *contiguous* maps.
> +  */
> + if (al->map != NULL)
> + al->addr = al->map->map_ip(al->map, al->addr);
>   }
>  
>   return al->map;
> -- 
> 1.8.3.1
> 

Re: [PATCH 2/4] base/drivers/arch_topology: Replace mutex with READ_ONCE / WRITE_ONCE

[Daniel Lezcano]

On 23/11/2018 14:58, Sudeep Holla wrote:
> On Mon, Oct 29, 2018 at 05:23:18PM +0100, Daniel Lezcano wrote:
>> The mutex protects a per_cpu variable access. The potential race can
>> happen only when the cpufreq governor module is loaded and at the same
>> time the cpu capacity is changed in the sysfs.
>>
> 
> I wonder if we really need that sysfs entry to be writable. For some
> reason, I had assumed it's read only, obviously it's not. I prefer to
> make it RO if there's no strong reason other than debug purposes.

Are you suggesting to remove the READ_ONCE/WRITE_ONCE patch and set the
sysfs file read-only ?


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

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH] x86: only use ERMS for user copies for larger sizes

[Linus Torvalds]

On Fri, Nov 23, 2018 at 2:12 AM David Laight  wrote:
>
> I've just patched my driver and redone the test on a 4.13 (ubuntu) kernel.
> Calling memcpy_fromio(kernel_buffer, PCIe_address, length)
> generates a lot of single byte TLP.

I just tested it too - it turns out that the __inline_memcpy() code
never triggers, and "memcpy_toio()" just generates a memcpy.

So that code seems entirely dead.

And, in fact, the codebase I looked at was the historical one, because
I had been going back and looking at the history. The modern tree
*does* have the "__inline_memcpy()" function I pointed at, but it's
not actually hooked up to anything!

This actually has been broken for _ages_. The breakage goes back to
2010, and commit 6175ddf06b61 ("x86: Clean up mem*io functions"), and
it seems nobody really ever noticed - or thought that it was ok.

That commit claims that iomem has no special significance on x86, but
that really really isn't true, exactly because the access size does
matter.

And as mentioned, the generic memory copy routines are not at all
appropriate, and that has nothing to do with ERMS. Our "do it by hand"
memory copy routine does things like this:

.Lless_16bytes:
cmpl $8,%edx
jb   .Lless_8bytes
/*
 * Move data from 8 bytes to 15 bytes.
 */
movq 0*8(%rsi), %r8
movq -1*8(%rsi, %rdx),  %r9
movq %r8,   0*8(%rdi)
movq %r9,   -1*8(%rdi, %rdx)
retq

and note how for a 8-byte copy, it will do *two* reads of the same 8
bytes, and *two* writes of the same 8 byte destination. That's
perfectly ok for regular memory, and it means that the code can handle
an arbitrary 8-15 byte copy without any conditionals or loop counts,
but it is *not* ok for iomem.

Of course, in practice it all just happens to work in almost all
situations (because a lot of iomem devices simply won't care), and
manual access to iomem is basically extremely rare these days anyway,
but it's definitely entirely and utterly broken.

End result: we *used* to do this right. For the last eight years our
"memcpy_{to,from}io()" has been entirely broken, and apparently even
the people who noticed oddities like David, never reported it as
breakage but instead just worked around it in drivers.

Ho humm.

Let me write a generic routine in lib/iomap_copy.c (which already does
the "user specifies chunk size" cases), and hook it up for x86.

David, are you using a bus analyzer or something to do your testing?
I'll have a trial patch for you asap.

   Linus

Re: [PATCH 2/4] base/drivers/arch_topology: Replace mutex with READ_ONCE / WRITE_ONCE

[Daniel Lezcano]

On 23/11/2018 17:20, Sudeep Holla wrote:
> On Fri, Nov 23, 2018 at 05:04:18PM +0100, Daniel Lezcano wrote:
>> On 23/11/2018 14:58, Sudeep Holla wrote:
>>> On Mon, Oct 29, 2018 at 05:23:18PM +0100, Daniel Lezcano wrote:
 The mutex protects a per_cpu variable access. The potential race can
 happen only when the cpufreq governor module is loaded and at the same
 time the cpu capacity is changed in the sysfs.

>>>
>>> I wonder if we really need that sysfs entry to be writable. For some
>>> reason, I had assumed it's read only, obviously it's not. I prefer to
>>> make it RO if there's no strong reason other than debug purposes.
>>
>> Are you suggesting to remove the READ_ONCE/WRITE_ONCE patch and set the
>> sysfs file read-only ?
>>
> 
> Just to be sure, if we retain RW capability we still need to fix the
> race you are pointing out.
> 
> However I just don't see the need for RW cpu_capacity sysfs and hence
> asking the reason here. IIRC I had pointed this out long back(not sure
> internally or externally) but seemed to have missed the version that got
> merged. So I am just asking if we really need write capability given that
> it has known issues.
> 
> If user-space starts writing the value to influence the scheduler, then
> it makes it difficult for kernel to change the way it uses the
> cpu_capacity in future.
> 
> Sorry if there's valid usecase and I am just making noise here.

It's ok [added Juri Lelli]

I've been through the history:

commit be8f185d8af4dbd450023a42a48c6faa8cbcdfe6
Author: Juri Lelli 
Date:   Thu Nov 3 05:40:18 2016 +

arm64: add sysfs cpu_capacity attribute

Add a sysfs cpu_capacity attribute with which it is possible to read and
write (thus over-writing default values) CPUs capacity. This might be
useful in situations where values needs changing after boot.

The new attribute shows up as:

 /sys/devices/system/cpu/cpu*/cpu_capacity

Cc: Will Deacon 
Cc: Mark Brown 
Cc: Sudeep Holla 
Signed-off-by: Juri Lelli 
Signed-off-by: Catalin Marinas 

Juri do you have a use case where we want to override the capacity?

Shall we switch the sysfs attribute to read-only?


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

Follow Linaro:   Facebook |
 Twitter |
 Blog

[PATCH] irqchhip: Convert to using %pOFn instead of device_node.name

[Yangtao Li]

In preparation to remove the node name pointer from struct device_node,
convert printf users to use the %pOFn format specifier.

Signed-off-by: Yangtao Li 
---
 drivers/irqchip/irq-mscc-ocelot.c |  6 +++---
 drivers/irqchip/irq-stm32-exti.c  |  6 +++---
 drivers/irqchip/irq-tango.c   | 10 +-
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/irqchip/irq-mscc-ocelot.c 
b/drivers/irqchip/irq-mscc-ocelot.c
index b63e40c00a02..88143c0b700c 100644
--- a/drivers/irqchip/irq-mscc-ocelot.c
+++ b/drivers/irqchip/irq-mscc-ocelot.c
@@ -72,7 +72,7 @@ static int __init ocelot_irq_init(struct device_node *node,
domain = irq_domain_add_linear(node, OCELOT_NR_IRQ,
   _generic_chip_ops, NULL);
if (!domain) {
-   pr_err("%s: unable to add irq domain\n", node->name);
+   pr_err("%pOFn: unable to add irq domain\n", node);
return -ENOMEM;
}
 
@@ -80,14 +80,14 @@ static int __init ocelot_irq_init(struct device_node *node,
 "icpu", handle_level_irq,
 0, 0, 0);
if (ret) {
-   pr_err("%s: unable to alloc irq domain gc\n", node->name);
+   pr_err("%pOFn: unable to alloc irq domain gc\n", node);
goto err_domain_remove;
}
 
gc = irq_get_domain_generic_chip(domain, 0);
gc->reg_base = of_iomap(node, 0);
if (!gc->reg_base) {
-   pr_err("%s: unable to map resource\n", node->name);
+   pr_err("%pOFn: unable to map resource\n", node);
ret = -ENOMEM;
goto err_gc_free;
}
diff --git a/drivers/irqchip/irq-stm32-exti.c b/drivers/irqchip/irq-stm32-exti.c
index 0a2088e12d96..363385750fa7 100644
--- a/drivers/irqchip/irq-stm32-exti.c
+++ b/drivers/irqchip/irq-stm32-exti.c
@@ -678,8 +678,8 @@ static int __init stm32_exti_init(const struct 
stm32_exti_drv_data *drv_data,
domain = irq_domain_add_linear(node, drv_data->bank_nr * IRQS_PER_BANK,
   _exti_domain_ops, NULL);
if (!domain) {
-   pr_err("%s: Could not register interrupt domain.\n",
-  node->name);
+   pr_err("%pOFn: Could not register interrupt domain.\n",
+  node);
ret = -ENOMEM;
goto out_unmap;
}
@@ -768,7 +768,7 @@ __init stm32_exti_hierarchy_init(const struct 
stm32_exti_drv_data *drv_data,
  host_data);
 
if (!domain) {
-   pr_err("%s: Could not register exti domain.\n", node->name);
+   pr_err("%pOFn: Could not register exti domain.\n", node);
ret = -ENOMEM;
goto out_unmap;
}
diff --git a/drivers/irqchip/irq-tango.c b/drivers/irqchip/irq-tango.c
index 580e2d72b9ba..ae28d8648679 100644
--- a/drivers/irqchip/irq-tango.c
+++ b/drivers/irqchip/irq-tango.c
@@ -184,11 +184,11 @@ static int __init tangox_irq_init(void __iomem *base, 
struct resource *baseres,
 
irq = irq_of_parse_and_map(node, 0);
if (!irq)
-   panic("%s: failed to get IRQ", node->name);
+   panic("%pOFn: failed to get IRQ", node);
 
err = of_address_to_resource(node, 0, );
if (err)
-   panic("%s: failed to get address", node->name);
+   panic("%pOFn: failed to get address", node);
 
chip = kzalloc(sizeof(*chip), GFP_KERNEL);
chip->ctl = res.start - baseres->start;
@@ -196,12 +196,12 @@ static int __init tangox_irq_init(void __iomem *base, 
struct resource *baseres,
 
dom = irq_domain_add_linear(node, 64, _generic_chip_ops, chip);
if (!dom)
-   panic("%s: failed to create irqdomain", node->name);
+   panic("%pOFn: failed to create irqdomain", node);
 
err = irq_alloc_domain_generic_chips(dom, 32, 2, node->name,
 handle_level_irq, 0, 0, 0);
if (err)
-   panic("%s: failed to allocate irqchip", node->name);
+   panic("%pOFn: failed to allocate irqchip", node);
 
tangox_irq_domain_init(dom);
 
@@ -219,7 +219,7 @@ static int __init tangox_of_irq_init(struct device_node 
*node,
 
base = of_iomap(node, 0);
if (!base)
-   panic("%s: of_iomap failed", node->name);
+   panic("%pOFn: of_iomap failed", node);
 
of_address_to_resource(node, 0, );
 
-- 
2.17.0

Re: [PATCH 1/2] module: Overwrite st_size instead of st_info

[Dave Martin]

On Thu, Nov 22, 2018 at 05:49:23PM +, Russell King - ARM Linux wrote:
> On Thu, Nov 22, 2018 at 06:40:45PM +0100, Ard Biesheuvel wrote:
> > On Thu, 22 Nov 2018 at 17:29, Jessica Yu  wrote:
> > >
> > > +++ Vincent Whitchurch [22/11/18 13:24 +0100]:
> > > >On Thu, Nov 22, 2018 at 12:01:54PM +, Dave Martin wrote:
> > > >> On Mon, Nov 19, 2018 at 05:25:12PM +0100, Vincent Whitchurch wrote:
> > > >> > st_info is currently overwritten after relocation and used to store 
> > > >> > the
> > > >> > elf_type().  However, we're going to need it fix kallsyms on ARM's
> > > >> > Thumb-2 kernels, so preserve st_info and overwrite the st_size field
> > > >> > instead.  st_size is neither used by the module core nor by any
> > > >> > architecture.
> > > >> >
> > > >> > Signed-off-by: Vincent Whitchurch 
> > > >> > ---
> > > >> > v4: Split out to separate patch.  Use st_size instead of st_other.
> > > >> > v1-v3: See PATCH 2/2
> > > >> >
> > > >> >  kernel/module.c | 4 ++--
> > > >> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > >> >
> > > >> > diff --git a/kernel/module.c b/kernel/module.c
> > > >> > index 49a405891587..3d86a38b580c 100644
> > > >> > --- a/kernel/module.c
> > > >> > +++ b/kernel/module.c
> > > >> > @@ -2682,7 +2682,7 @@ static void add_kallsyms(struct module *mod, 
> > > >> > const struct load_info *info)
> > > >> >
> > > >> >/* Set types up while we still have access to sections. */
> > > >> >for (i = 0; i < mod->kallsyms->num_symtab; i++)
> > > >> > -  mod->kallsyms->symtab[i].st_info
> > > >> > +  mod->kallsyms->symtab[i].st_size
> > > >> >= elf_type(>kallsyms->symtab[i], info);
> > > >> >
> > > >> >/* Now populate the cut down core kallsyms for after init. */
> > > >> > @@ -4061,7 +4061,7 @@ int module_get_kallsym(unsigned int symnum, 
> > > >> > unsigned long *value, char *type,
> > > >> >kallsyms = rcu_dereference_sched(mod->kallsyms);
> > > >> >if (symnum < kallsyms->num_symtab) {
> > > >> >*value = kallsyms->symtab[symnum].st_value;
> > > >> > -  *type = kallsyms->symtab[symnum].st_info;
> > > >> > +  *type = kallsyms->symtab[symnum].st_size;
> > > >> >strlcpy(name, symname(kallsyms, symnum), 
> > > >> > KSYM_NAME_LEN);
> > > >> >strlcpy(module_name, mod->name, MODULE_NAME_LEN);
> > > >> >*exported = is_exported(name, *value, mod);
> > > >>
> > > >> This is fine if st_size is really unused, but how sure are you of that?
> > > >>
> > > >> grepping for st_size throws up some hits that appear ELF-related, but
> > > >> I've not investigated them in detail.
> > > >>
> > > >> (The fact that struct stat has an identically named field throws up
> > > >> a load of false positives too.)
> > > >
> > > >$ git describe --tags
> > > >v4.20-rc3-93-g92b419289cee
> > > >
> > > >$ rg -m1 '[\.>]st_size'  --iglob '!**/tools/**' --iglob '!**/vdso*' 
> > > >--iglob '!**/scripts/**' --iglob '!**/usr/**' --iglob '!**/samples/**' | 
> > > >cat
> > > >| kernel/kexec_file.c: if (sym->st_size != size) {
> > > >
> > > >Symbols in kexec kernel.
> > > >
> > > >| fs/stat.c:   tmp.st_size = stat->size;
> > > >| Documentation/networking/tls.txt:  sendfile(sock, file, , 
> > > >stat.st_size);
> > > >| net/9p/client.c: ret->st_rdev, ret->st_size, 
> > > >ret->st_blksize,
> > > >| net/9p/protocol.c:   >st_rdev, 
> > > >>st_size,
> > > >| fs/9p/vfs_inode_dotl.c:  i_size_write(inode, 
> > > >stat->st_size);
> > > >| fs/hostfs/hostfs_user.c: p->size = buf->st_size;
> > > >| arch/powerpc/boot/mktree.c:  nblks = (st.st_size + IMGBLK) / IMGBLK;
> > > >| arch/alpha/kernel/osf_sys.c: tmp.st_size = lstat->size;
> > > >| arch/x86/ia32/sys_ia32.c:__put_user(stat->size, 
> > > >>st_size) ||
> > > >
> > > >Not Elf_Sym.
> > > >
> > > >| arch/x86/kernel/machine_kexec_64.c:   sym->st_size);
> > > >
> > > >Symbols in kexec kernel.
> > > >
> > > >| arch/sparc/boot/piggyback.c: st4(buffer + 12, s.st_size);
> > > >| arch/sparc/kernel/sys_sparc32.c: err |= put_user(stat->size, 
> > > >>st_size);
> > > >| arch/um/os-Linux/file.c: .ust_size= src->st_size,
> > > >/* total size, in bytes */
> > > >| arch/um/os-Linux/start_up.c: size = (buf.st_size + UM_KERN_PAGE_SIZE) 
> > > >& ~(UM_KERN_PAGE_SIZE - 1);
> > > >| arch/s390/kernel/compat_linux.c: tmp.st_size = stat->size;
> > > >| arch/arm/kernel/sys_oabi-compat.c:   tmp.st_size = stat->size;
> > > >| arch/mips/boot/compressed/calc_vmlinuz_load_addr.c:  vmlinux_size = 
> > > >(uint64_t)sb.st_size;
> > > >| drivers/net/ethernet/marvell/sky2.c: hw->st_idx = 
> > > >RING_NEXT(hw->st_idx, hw->st_size);
> > > >
> > > >Not Elf_Sym.
> > >
> > > [ added Miroslav to CC, just in case he would like to check :) ]
> > >
> > > I have just double checked as well, and am fairly certain that the
> > > 

Re: [PATCH v2] arm64: dts: rockchip: Add DT for nanopc-t4

[Heiko Stuebner]

Hi Tomeu,

Am Freitag, 23. November 2018, 08:46:30 CET schrieb Tomeu Vizoso:
> diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt 
> b/Documentation/devicetree/bindings/arm/rockchip.txt
> index 0cc71236d639..e907d309486e 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip.txt
> +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
> @@ -71,6 +71,10 @@ Rockchip platforms device tree bindings
>  Required root node properties:
>- compatible = "firefly,roc-rk3399-pc", "rockchip,rk3399";
>  
> +- FriendlyElec NanoPC-T4 board:
> +Required root node properties:
> +  - compatible = "friendlyarm,nanopc-t4", "rockchip,rk3399";
> +

alphabetical please

>  - ChipSPARK PopMetal-RK3288 board:
>  Required root node properties:
>- compatible = "chipspark,popmetal-rk3288", "rockchip,rk3288";
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
> b/arch/arm64/boot/dts/rockchip/Makefile
> index 49042c477870..ed90cd1e5a8b 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -20,3 +20,4 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rock960.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rockpro64.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire-excavator.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopc-t4.dtb

alphabetical please

> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi 
> b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
> new file mode 100644
> index ..148f85b4bd49
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi

[...]

General comment about regulators, the vendor-kernel dts' regularly
don't model regulators in a nice way representing the hardware.

There is obviously schematics available for the board
http://wiki.friendlyarm.com/wiki/images/d/dd/NanoPi-M4-2GB-1807-Schematic.pdf

Please model the regulator tree following the naming scheme from the
schematics and including correct supply chaining, so that
$debug/regulator/regulator_summary looks nice.

This makes it way easier to find issues later on if needed and represents
the hardware in a correct way.

I guess in the end it should look pretty similar to the rock960 or other
rk3399 boards (except gru), as most boards follow the reference schematics
for a big part.

> + vcc3v3_sys: vcc3v3-sys {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc3v3_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + };
> +
> + vcc5v0_host: vcc5v0-host-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc5v0_host";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + };
> +
> + vcc5v0_sys: vcc5v0-sys {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc5v0_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + };
> +
> + vccadc_ref: vccadc-ref {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc1v8_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + };
> +
> + vcc_sd: vcc-sd {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = < 1 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_sd_h>;
> + regulator-name = "vcc_sd";
> + regulator-min-microvolt = <300>;
> + regulator-max-microvolt = <300>;
> + };
> +
> + vcc_phy: vcc-phy-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc_phy";
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + vcc_lcd: vcc-lcd {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc_lcd";
> + gpio = < 30 GPIO_ACTIVE_HIGH>;
> + startup-delay-us = <2>;
> + enable-active-high;
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-boot-on;
> + vin-supply = <_sys>;
> + };
> +
> + vcc5v0_typec: vcc5v0-typec-regulator {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpios = < 26 GPIO_ACTIVE_HIGH>;
> + regulator-name = "vcc5v0_typec";
> + regulator-always-on;
> + 

Re: [PATCH] dt-bindings: i2c: Use correct vendor prefix for Atmel

[Peter Rosin]

On 2018-11-23 13:10, Thierry Reding wrote:
> From: Thierry Reding 
> 
> The "at," prefix was never correct for Atmel, so fix the few occurrences
> that got it wrong. Use "atmel," instead.

Fully agreed. However, given that atmel,24c08 is documented in 
.../eeprom/at24.txt
I think it would be better to remove at,24c08 from trivial-devices.txt

Cheers,
Peter

> Signed-off-by: Thierry Reding 
> ---
>  Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt | 2 +-
>  Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt | 2 +-
>  Documentation/devicetree/bindings/i2c/nxp,pca9541.txt | 2 +-
>  Documentation/devicetree/bindings/trivial-devices.txt | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt 
> b/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
> index 1e98c6b3a721..c661b9083ec6 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
> @@ -43,7 +43,7 @@ Example:
>   reg = <0>;
>  
>   eeprom@50 {
> - compatible = "at,24c02";
> + compatible = "atmel,24c02";
>   reg = <0x50>;
>   };
>   };
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt 
> b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
> index ccf6c86ed076..30ac6a60f041 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
> @@ -54,7 +54,7 @@ Example:
>   reg = <2>;
>  
>   eeprom@54 {
> - compatible = "at,24c08";
> + compatible = "atmel,24c08";
>   reg = <0x54>;
>   };
>   };
> diff --git a/Documentation/devicetree/bindings/i2c/nxp,pca9541.txt 
> b/Documentation/devicetree/bindings/i2c/nxp,pca9541.txt
> index 0fbbc6970ec5..42bfc09c8918 100644
> --- a/Documentation/devicetree/bindings/i2c/nxp,pca9541.txt
> +++ b/Documentation/devicetree/bindings/i2c/nxp,pca9541.txt
> @@ -22,7 +22,7 @@ Example:
>   #size-cells = <0>;
>  
>   eeprom@54 {
> - compatible = "at,24c08";
> + compatible = "atmel,24c08";
>   reg = <0x54>;
>   };
>   };
> diff --git a/Documentation/devicetree/bindings/trivial-devices.txt 
> b/Documentation/devicetree/bindings/trivial-devices.txt
> index 6ab001fa1ed4..b7a7eaf2979a 100644
> --- a/Documentation/devicetree/bindings/trivial-devices.txt
> +++ b/Documentation/devicetree/bindings/trivial-devices.txt
> @@ -21,7 +21,7 @@ adi,adt7490 +/-1C TDM Extended Temp Range I.C
>  adi,adxl345  Three-Axis Digital Accelerometer
>  adi,adxl346  Three-Axis Digital Accelerometer 
> (backward-compatibility value "adi,adxl345" must be listed too)
>  ams,iaq-core AMS iAQ-Core VOC Sensor
> -at,24c08 i2c serial eeprom  (24cxx)
> +atmel,24c08  i2c serial eeprom  (24cxx)
>  atmel,at97sc3204ti2c trusted platform module (TPM)
>  capella,cm32181  CM32181: Ambient Light Sensor
>  capella,cm3232   CM3232: Ambient Light Sensor
> 

Re: [PATCH 3/3] lockdep: Use line-buffered printk() for lockdep messages.

[Petr Mladek]

On Sat 2018-11-10 11:42:03, Tetsuo Handa wrote:
> On 2018/11/10 0:43, Petr Mladek wrote:
> >> + * Line buffered printk() tries to assign a buffer when printk() from a 
> >> new
> >> + * context identifier comes in. And it automatically releases that buffer 
> >> when
> >> + * one of three conditions listed below became true.
> >> + *
> >> + *   (1) printk() from that context identifier emitted '\n' as the last
> >> + *   character of output.
> >> + *   (2) printk() from that context identifier tried to print a too long 
> >> line
> >> + *   which cannot be stored into a buffer.
> >> + *   (3) printk() from a new context identifier noticed that some context
> >> + *   identifier is reserving a buffer for more than 10 seconds without
> >> + *   emitting '\n'.
> >> + *
> >> + * Since (3) is based on a heuristic that somebody forgot to emit '\n' as 
> >> the
> >> + * last character of output(), pr_cont()/KERN_CONT users are expected to 
> >> emit
> >> + * '\n' within 10 seconds even if they reserved a buffer.
> > 
> > This is my main concern about this approach. It is so easy to omit
> > the final '\n'.
> 
> If it is so easy to forget the final '\n', there will be a lot of implicit
> pr_cont() users (because pr_cont() assumes that previous printk() omitted the
> final '\n'), and "I am going to investigate much more pr_cont() users." will
> be insufficient for getting meaningful conclusion.
> 
> Checking "lack of the the final '\n'" means that we need to check
> "all printk() users who are not emitting the final '\n'" and evaluate
> "whether there is a possibility that subsequent printk() will not be
>  called from that context due to e.g. conditional branches". That is an
> impossible task for anybody, for there might be out-of-tree code doing it.
> > 
> > They are currently delayed until another printk(). Even this is bad.
> > Unfortunately we could not setup timer from printk() because it
> > would add more locks into the game.
> 
> We could use interval timer for flushing incomplete line.

I am more and more wondering if the buffered printk is worth
the effort. The more buffers we use the more we risk that nobody
would see some important message. Even a part of the line
might be crucial in some situations.

Steven told me on Plumbers conference that even few initial
characters saved him a day few times.


> But updating printk() users to always end with '\n' will be preferable.

This sounds like a whack a mole game. If I get it correctly, you write
that it is "an impossible task for anybody" just few lines above.

Best Regards,
Petr

Re: [PATCH] btrfs: relocation: set trans to be NULL after free

[David Sterba]

On Fri, Nov 23, 2018 at 06:10:15PM +0800, Pan Bian wrote:
> The function relocate_block_group calls btrfs_end_transaction to release
> trans when update_backref_cache returns 1, and then continues the loop
> body. If btrfs_block_rsv_refill fails this time, it will jump out the
> loop and the freed trans will be accessed. This may result in a
> use-after-free bug. The patch assigns NULL to trans after trans is
> released so that it will not be accessed.
> 
> Fixes: 0647bf564f1("Btrfs: improve forever loop when doing balance
> relocation")
> 
> Signed-off-by: Pan Bian 

Good catch, thanks.

Reviewed-by: David Sterba 

Re: Official Linux system wrapper library?

[David Newall]

On 24/11/18 12:04 am, Florian Weimer wrote:

But socketcall does not exist on all architectures.  Neither does
getpid, it's called getxpid on some architectures.
...
I think it would be a poor approach to expose application developers to
these portability issues.  We need to abstract over these differences at
a certain layer, and applications are too late.


Interesting.  I think the opposite.  I think exposing the OS's 
interfaces is exactly what a c-library should do.  It might also provide 
alternative interfaces that work consistently across different 
platforms, but in addition to, not instead of the OS interface.

Re: [PATCH V6 2/2] can: flexcan: add self wakeup support

[Marc Kleine-Budde]

On 11/23/18 9:35 AM, Joakim Zhang wrote:
> From: Aisheng Dong 
> 
> If wakeup is enabled, enter stop mode, else enter disabled mode. Self wake
> can only work on stop mode.
> 
> Starting from IMX6, the flexcan stop mode control bits is SoC specific,
> move it out of IP driver and parse it from devicetree.
> 
> Signed-off-by: Aisheng Dong 
> Signed-off-by: Joakim Zhang 
> ---
> ChangeLog:
> V1->V2:
>   *add a vendor prefix in property (stop-mode -> fsl,stop-mode).
> V2->V3:
>   *add FLEXCAN_QUIRK_SETUP_STOP_MODE quirk.
>   *rename function.
>   *fix system can't be wakeuped during suspend.
> V3->V4:
>   *normalize the code following Aisheng Dong's comments.
> V4->V5:
>   *move enable/disable self wakeup feature into
>enter/exit_stop_mode() function.
> V5->V6:
>   *exchange the order of flexcan_enable_wakeup_irq(priv, false)
>and disable_irq_wake(dev->irq).
> ---
>  drivers/net/can/flexcan.c | 172 --
>  1 file changed, 163 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
> index 8e972ef08637..da08a8c113d2 100644
> --- a/drivers/net/can/flexcan.c
> +++ b/drivers/net/can/flexcan.c
> @@ -19,11 +19,14 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define DRV_NAME "flexcan"
>  
> @@ -131,7 +134,8 @@
>   (FLEXCAN_ESR_ERR_BUS | FLEXCAN_ESR_ERR_STATE)
>  #define FLEXCAN_ESR_ALL_INT \
>   (FLEXCAN_ESR_TWRN_INT | FLEXCAN_ESR_RWRN_INT | \
> -  FLEXCAN_ESR_BOFF_INT | FLEXCAN_ESR_ERR_INT)
> + FLEXCAN_ESR_BOFF_INT | FLEXCAN_ESR_ERR_INT | \
> + FLEXCAN_ESR_WAK_INT)

I've fixed the indention while applying the patch.

>  
>  /* FLEXCAN interrupt flag register (IFLAG) bits */
>  /* Errata ERR005829 step7: Reserve first valid MB */
> @@ -190,6 +194,7 @@
>  #define FLEXCAN_QUIRK_USE_OFF_TIMESTAMP  BIT(5) /* Use timestamp based 
> offloading */
>  #define FLEXCAN_QUIRK_BROKEN_PERR_STATE  BIT(6) /* No interrupt for 
> error passive */
>  #define FLEXCAN_QUIRK_DEFAULT_BIG_ENDIAN BIT(7) /* default to BE 
> register access */
> +#define FLEXCAN_QUIRK_SETUP_STOP_MODEBIT(8) /* Setup stop 
> mode to support wakeup */
>  
>  /* Structure of the message buffer */
>  struct flexcan_mb {
> @@ -254,6 +259,14 @@ struct flexcan_devtype_data {
>   u32 quirks; /* quirks needed for different IP cores */
>  };
>  
> +struct flexcan_stop_mode {
> + struct regmap *gpr;
> + u8 req_gpr;
> + u8 req_bit;
> + u8 ack_gpr;
> + u8 ack_bit;
> +};
> +
>  struct flexcan_priv {
>   struct can_priv can;
>   struct can_rx_offload offload;
> @@ -270,6 +283,7 @@ struct flexcan_priv {
>   struct clk *clk_per;
>   const struct flexcan_devtype_data *devtype_data;
>   struct regulator *reg_xceiver;
> + struct flexcan_stop_mode stm;
>  
>   /* Read and Write APIs */
>   u32 (*read)(void __iomem *addr);
> @@ -293,7 +307,8 @@ static const struct flexcan_devtype_data 
> fsl_imx28_devtype_data = {
>  
>  static const struct flexcan_devtype_data fsl_imx6q_devtype_data = {
>   .quirks = FLEXCAN_QUIRK_DISABLE_RXFG | FLEXCAN_QUIRK_ENABLE_EACEN_RRS |
> - FLEXCAN_QUIRK_USE_OFF_TIMESTAMP | 
> FLEXCAN_QUIRK_BROKEN_PERR_STATE,
> + FLEXCAN_QUIRK_USE_OFF_TIMESTAMP | 
> FLEXCAN_QUIRK_BROKEN_PERR_STATE |
> + FLEXCAN_QUIRK_SETUP_STOP_MODE,
>  };
>  
>  static const struct flexcan_devtype_data fsl_vf610_devtype_data = {
> @@ -353,6 +368,49 @@ static inline void flexcan_write_le(u32 val, void 
> __iomem *addr)
>   iowrite32(val, addr);
>  }
>  
> +static void flexcan_enable_wakeup_irq(struct flexcan_priv *priv, bool enable)
> +{
> + struct flexcan_regs __iomem *regs = priv->regs;
> + u32 reg_mcr;
> +
> + reg_mcr = priv->read(>mcr);
> +
> + if (enable)
> + reg_mcr |= FLEXCAN_MCR_WAK_MSK;
> + else
> + reg_mcr &= ~FLEXCAN_MCR_WAK_MSK;
> +
> + priv->write(reg_mcr, >mcr);
> +}
> +
> +static inline void flexcan_enter_stop_mode(struct flexcan_priv *priv)
> +{
> + struct flexcan_regs __iomem *regs = priv->regs;
> + u32 reg_mcr;
> +
> + reg_mcr = priv->read(>mcr);
> + reg_mcr |= FLEXCAN_MCR_SLF_WAK;
> + priv->write(reg_mcr, >mcr);
> +
> + /* enable stop request */
> + regmap_update_bits(priv->stm.gpr, priv->stm.req_gpr,
> +1 << priv->stm.req_bit, 1 << priv->stm.req_bit);
> +}
> +
> +static inline void flexcan_exit_stop_mode(struct flexcan_priv *priv)
> +{
> + struct flexcan_regs __iomem *regs = priv->regs;
> + u32 reg_mcr;
> +
> + /* remove stop request */
> + regmap_update_bits(priv->stm.gpr, priv->stm.req_gpr,
> +1 << priv->stm.req_bit, 0);
> +
> + reg_mcr = priv->read(>mcr);
> + reg_mcr &= ~FLEXCAN_MCR_SLF_WAK;
> + 

Re: [PATCH v2 1/4] dt-bindings: clock: meson8b: export the CPU post dividers

[Neil Armstrong]

On 22/11/2018 22:40, Martin Blumenstingl wrote:
> There are four CPU clock post dividers:
> - ABP
> - PERIPH (used as input for the ARM global timer and ARM TWD timer)
> - AXI
> - L2 DRAM
> 
> Export these so we can use them in .dts files.
> 
> Signed-off-by: Martin Blumenstingl 
> Acked-by: Jerome Brunet 
> ---
>  include/dt-bindings/clock/meson8b-clkc.h | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/include/dt-bindings/clock/meson8b-clkc.h 
> b/include/dt-bindings/clock/meson8b-clkc.h
> index a60f47b49231..5fe2923382d0 100644
> --- a/include/dt-bindings/clock/meson8b-clkc.h
> +++ b/include/dt-bindings/clock/meson8b-clkc.h
> @@ -103,5 +103,9 @@
>  #define CLKID_MPLL1  94
>  #define CLKID_MPLL2  95
>  #define CLKID_NAND_CLK   112
> +#define CLKID_ABP124
> +#define CLKID_PERIPH 126
> +#define CLKID_AXI128
> +#define CLKID_L2_DRAM130
>  
>  #endif /* __MESON8B_CLKC_H */
> 

Kevin,

Martin asked my a tag for this patch since he has a dependency on it.

You can find it here :

The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:

  Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)

are available in the Git repository at:

  git://github.com/BayLibre/clk-meson.git tags/meson-clk-headers-4.21-1

for you to fetch changes up to 8e1dd17c8b0e3f8c66ed2a3f88a440d36135e589:

  dt-bindings: clock: meson8b: export the CPU post dividers (2018-11-23 
15:11:55 +0100)


Update for meson clocks bindings targeted at v4.21:
- Export Meson8b CPU post dividers


Martin Blumenstingl (1):
  dt-bindings: clock: meson8b: export the CPU post dividers

 include/dt-bindings/clock/meson8b-clkc.h | 4 
 1 file changed, 4 insertions(+)

Neil

Re: [PATCH v2] kmemleak: Turn kmemleak_lock to raw spinlock on RT

[Steven Rostedt]

On Fri, 23 Nov 2018 11:31:31 +
Catalin Marinas  wrote:

> With qwrlocks, the readers will normally block if there is a pending
> writer (to avoid starving the writer), unless in_interrupt() when the
> readers are allowed to starve a pending writer.
> 
> TLA+/PlusCal model here:  ;)
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/kernel-tla.git/tree/qrwlock.tla
> 


And the code appears to confirm it too:

void queued_read_lock_slowpath(struct qrwlock *lock)
{
/*
 * Readers come here when they cannot get the lock without waiting
 */
if (unlikely(in_interrupt())) {
/*
 * Readers in interrupt context will get the lock immediately
 * if the writer is just waiting (not holding the lock yet),
 * so spin with ACQUIRE semantics until the lock is available
 * without waiting in the queue.
 */
atomic_cond_read_acquire(>cnts, !(VAL & _QW_LOCKED));
return;
}
atomic_sub(_QR_BIAS, >cnts);

/*
 * Put the reader into the wait queue
 */
arch_spin_lock(>wait_lock);
atomic_add(_QR_BIAS, >cnts);



-- Steve

Re: [PATCH] perf map: remove extra indirection from map__find()

[Jiri Olsa]

On Fri, Nov 23, 2018 at 02:42:39AM -0800, Eric Saint-Etienne wrote:
> A double pointer is used in map__find() where a single pointer is enough
> because the function doesn't affect the rbtree and the rbtree is locked.
> 
> Signed-off-by: Eric Saint-Etienne 

Acked-by: Jiri Olsa 

thanks,
jirka

> ---
>  tools/perf/util/map.c | 13 ++---
>  1 file changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
> index 354e545..3dac766 100644
> --- a/tools/perf/util/map.c
> +++ b/tools/perf/util/map.c
> @@ -846,19 +846,18 @@ void maps__remove(struct maps *maps, struct map *map)
>  
>  struct map *maps__find(struct maps *maps, u64 ip)
>  {
> - struct rb_node **p, *parent = NULL;
> + struct rb_node *p;
>   struct map *m;
>  
>   down_read(>lock);
>  
> - p = >entries.rb_node;
> - while (*p != NULL) {
> - parent = *p;
> - m = rb_entry(parent, struct map, rb_node);
> + p = maps->entries.rb_node;
> + while (p != NULL) {
> + m = rb_entry(p, struct map, rb_node);
>   if (ip < m->start)
> - p = &(*p)->rb_left;
> + p = p->rb_left;
>   else if (ip >= m->end)
> - p = &(*p)->rb_right;
> + p = p->rb_right;
>   else
>   goto out;
>   }
> -- 
> 1.8.3.1
> 

Re: [RFC 00/60] Coscheduling for Linux

[Frederic Weisbecker]

On Thu, Sep 27, 2018 at 11:36:34AM -0700, Subhra Mazumdar wrote:
> 
> 
> On 09/26/2018 02:58 AM, Jan H. Schönherr wrote:
> >On 09/17/2018 02:25 PM, Peter Zijlstra wrote:
> >>On Fri, Sep 14, 2018 at 06:25:44PM +0200, Jan H. Schönherr wrote:
> >>
> >>>Assuming, there is a cgroup-less solution that can prevent simultaneous
> >>>execution of tasks on a core, when they're not supposed to. How would you
> >>>tell the scheduler, which tasks these are?
> >>Specifically for L1TF I hooked into/extended KVM's preempt_notifier
> >>registration interface, which tells us which tasks are VCPUs and to
> >>which VM they belong.
> >>
> >>But if we want to actually expose this to userspace, we can either do a
> >>prctl() or extend struct sched_attr.
> >Both, Peter and Subhra, seem to prefer an interface different than cgroups
> >to specify what to coschedule.
> >
> >Can you provide some extra motivation for me, why you feel that way?
> >(ignoring the current scalability issues with the cpu group controller)
> >
> >
> >After all, cgroups where designed to create arbitrary groups of tasks and
> >to attach functionality to those groups.
> >
> >If we were to introduce a different interface to control that, we'd need to
> >introduce a whole new group concept, so that you make tasks part of some
> >group while at the same time preventing unauthorized tasks from joining a
> >group.
> >
> >
> >I currently don't see any wins, just a loss in flexibility.
> >
> >Regards
> >Jan
> I think cgroups will the get the job done for any use case. But we have,
> e.g. affinity control via both sched_setaffinity and cgroup cpusets. It
> will be good to have an alternative way to specify co-scheduling too for
> those who don't want to use cgroup for some reason. It can be added later
> on though, only how one will override the other will need to be sorted out.

I kind of agree with Jan here that this is just going to add yet another task
group mechanism, very similar to the existing one, with runqueues inside and 
all.

Can you imagine kernel/sched/fair.c now dealing with both groups 
implementations?
What happens when cgroup task groups and cosched sched groups don't match wrt.
their tasks, their priorities, etc...

I understand cgroup task group has become infamous. But it may be a better idea
in the long run to fix it.

Re: [PATCH 08/17] soc: ti: pruss: Add a PRUSS irqchip driver for PRUSS interrupts

[Tony Lindgren]

* Roger Quadros  [181122 11:39]:
> The PRUSS INTC module is reference counted during the interrupt
> setup phase through the irqchip's irq_request_resources() and
> irq_release_resources() ops. This restricts the module from being
> removed as long as there are active interrupt users.

So are there any reasons why this could not be just a regular
drivers/irqchip driver nowadays?

Regards,

Tony

[PATCH] ufs: clean up indentation issues, replace spaces with tabs

[Colin King]

From: Colin Ian King 

There is a hunk of code where spaces are used for identations, and it
off by one in an editor. Clean this up by replacing them with tabs.
Also remove one blank line.

Signed-off-by: Colin Ian King 
---
 fs/ufs/inode.c | 87 +-
 1 file changed, 43 insertions(+), 44 deletions(-)

diff --git a/fs/ufs/inode.c b/fs/ufs/inode.c
index c843ec858cf7..c4fb99eddff4 100644
--- a/fs/ufs/inode.c
+++ b/fs/ufs/inode.c
@@ -1066,52 +1066,51 @@ static int ufs_alloc_lastblock(struct inode *inode, 
loff_t size)
 
lastpage = ufs_get_locked_page(mapping, lastfrag >>
   (PAGE_SHIFT - inode->i_blkbits));
-   if (IS_ERR(lastpage)) {
-   err = -EIO;
-   goto out;
-   }
-
-   end = lastfrag & ((1 << (PAGE_SHIFT - inode->i_blkbits)) - 1);
-   bh = page_buffers(lastpage);
-   for (i = 0; i < end; ++i)
-   bh = bh->b_this_page;
-
-
-   err = ufs_getfrag_block(inode, lastfrag, bh, 1);
-
-   if (unlikely(err))
-  goto out_unlock;
-
-   if (buffer_new(bh)) {
-  clear_buffer_new(bh);
-  clean_bdev_bh_alias(bh);
-  /*
-   * we do not zeroize fragment, because of
-   * if it maped to hole, it already contains zeroes
-   */
-  set_buffer_uptodate(bh);
-  mark_buffer_dirty(bh);
-  set_page_dirty(lastpage);
-   }
-
-   if (lastfrag >= UFS_IND_FRAGMENT) {
-  end = uspi->s_fpb - ufs_fragnum(lastfrag) - 1;
-  phys64 = bh->b_blocknr + 1;
-  for (i = 0; i < end; ++i) {
-  bh = sb_getblk(sb, i + phys64);
-  lock_buffer(bh);
-  memset(bh->b_data, 0, sb->s_blocksize);
-  set_buffer_uptodate(bh);
-  mark_buffer_dirty(bh);
-  unlock_buffer(bh);
-  sync_dirty_buffer(bh);
-  brelse(bh);
-  }
-   }
+   if (IS_ERR(lastpage)) {
+   err = -EIO;
+   goto out;
+   }
+
+   end = lastfrag & ((1 << (PAGE_SHIFT - inode->i_blkbits)) - 1);
+   bh = page_buffers(lastpage);
+   for (i = 0; i < end; ++i)
+   bh = bh->b_this_page;
+
+   err = ufs_getfrag_block(inode, lastfrag, bh, 1);
+
+   if (unlikely(err))
+   goto out_unlock;
+
+   if (buffer_new(bh)) {
+   clear_buffer_new(bh);
+   clean_bdev_bh_alias(bh);
+   /*
+* we do not zeroize fragment, because of
+* if it maped to hole, it already contains zeroes
+*/
+   set_buffer_uptodate(bh);
+   mark_buffer_dirty(bh);
+   set_page_dirty(lastpage);
+   }
+
+   if (lastfrag >= UFS_IND_FRAGMENT) {
+   end = uspi->s_fpb - ufs_fragnum(lastfrag) - 1;
+   phys64 = bh->b_blocknr + 1;
+   for (i = 0; i < end; ++i) {
+   bh = sb_getblk(sb, i + phys64);
+   lock_buffer(bh);
+   memset(bh->b_data, 0, sb->s_blocksize);
+   set_buffer_uptodate(bh);
+   mark_buffer_dirty(bh);
+   unlock_buffer(bh);
+   sync_dirty_buffer(bh);
+   brelse(bh);
+   }
+   }
 out_unlock:
-   ufs_put_locked_page(lastpage);
+   ufs_put_locked_page(lastpage);
 out:
-   return err;
+   return err;
 }
 
 static void ufs_truncate_blocks(struct inode *inode)
-- 
2.19.1

Re: [RFC PATCH v4 1/5] glibc: Perform rseq(2) registration at nptl init and thread creation

[Mathieu Desnoyers]

- On Nov 23, 2018, at 9:28 AM, Rich Felker dal...@libc.org wrote:
[...]
> 
> Absolutely. As long as it's in libc, implicit destruction will happen.
> Actually I think the glibc code shound unconditionally unregister the
> rseq address at exit (after blocking signals, so no application code
> can run) in case a third-party rseq library was linked and failed to
> do so before thread exit (e.g. due to mismatched ref counts) rather
> than respecting the reference count, since it knows it's the last
> user. This would make potentially-buggy code safer.

OK, let me go ahead with a few ideas/questions along that path.

Let's say our stated goal is to let the "exit" system call from the
glibc thread exit path perform rseq unregistration (without explicit
unregistration beforehand). Let's look at what we need.

First, we need the TLS area to be valid until the exit system call
is invoked by the thread. If glibc defines __rseq_abi as a weak symbol,
I'm not entirely sure we can guarantee the IE model if another library
gets its own global-dynamic weak symbol elected at execution time. Would
it be better to switch to a "strong" symbol for the glibc __rseq_abi
rather than weak ?

If we rely on implicit unregistration by the exit system call, then we
need to be really sure that the __rseq_abi TLS area can be accessed
(load and store) from kernel preemption up to the point where exit
is invoked. If we have that guarantee with the IE model, then we should
be fine. This means the memory area with the __rseq_abi sits can only
be re-used after the tid field in the TLB is set to 0 by the exit system
call. Looking at allocatestack.c, it looks like the FREE_P () macro
does exactly that.

With all the above respected, we could rely on implicit rseq unregistration
by thread exit rather than do an explicit unregister. We could still need
to increment the __rseq_refcount upon thread start however, so we can
ensure early adopter libraries won't unregister rseq while glibc is using
it. No need to bring the refcount back to 0 in glibc though.

There has been presumptions about signals being blocked when the thread
exits throughout this email thread. Out of curiosity, what code is
responsible for disabling signals in this situation ? Related to this,
is it valid to access a IE model TLS variable from a signal handler at
_any_ point where the signal handler nests over thread's execution ?
This includes early start and just before invoking the exit system call.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: [PATCH] dmaengine: ti: omap-dma: Configure LCH_TYPE for OMAP1

[Peter Ujfalusi]

On 22/11/2018 17.12, Russell King - ARM Linux wrote:
> On Thu, Nov 22, 2018 at 10:29:48AM +, Russell King - ARM Linux wrote:
>> On Tue, Nov 20, 2018 at 11:04:06PM +0200, Aaro Koskinen wrote:
>>> I had switched to PIO mode in 2015 since the WARNs about legacy DMA
>>> API were too annoying and flooding the console. And now that I tried
>>> using DMA again with g_ether, it doesn't work anymore. The device get's
>>> recognized on host side, but no traffic goes through. Switching back to
>>> PIO makes it to work again.
>>
>> A solution to that would be to do what the warning message says, and
>> update the driver to the DMAengine API.
> 
> Here's a partial conversion (not even build tested) - it only supports
> OUT transfers with dmaengine at the moment.

Thanks!

What I learned with the tusb that we need to rearrange things for
DMAengine (4cadc711cdc7 usb: musb: tusb6010_omap: Allocate DMA channels
upfront)

But that was within the musb framework, so omap_udc might be simpler.

> There's at least one thing that doesn't make sense - the driver
> apparently can transfer more than req->length bytes, surely if it does
> that, it's a serious problem - shouldn't it be noisy about that?


> Also we can't deal with the omap_set_dma_dest_burst_mode() setting -
> DMAengine always uses a 64 byte burst, but udc wants a smaller burst
> setting.  Does this matter?

The tusb also fiddled with the burst before the conversion, I believe
what the DMAengine driver is doing should be fine. If not then we fix it
while converting the omap_udc.

> 
> I've kept the old code for reference (and the driver will fall back if
> we can't get a dmaengine channel.)  I haven't been through and checked
> that we result in the channel setup largely the same either.
> 
> There will be one major difference - UDC uses element sync, where
> an element is 16bits, ep->ep.maxpacket/2 in a frame, and "packets"
> frames.  DMAengine is using frame sync, with a 16bit element, one
> element in a frame, and packets*ep->ep.maxpacket/2 frames.  This
> should be functionally equivalent but I'd like confirmation of that.

Yes, I think it should be fine also.

> 
> I'm also not sure about this:
> 
> if (cpu_is_omap15xx())
> end++;
> 
> in dma_dest_len() - is that missing from the omap-dma driver?  It looks
> like a work-around for some problem on OMAP15xx, but I can't make sense
> about why it's in the UDC driver rather than the legacy DMA driver.

afaik no other legacy drivers were doing similar thing, this must be
something which is needed for the omap_udc driver to fix up something?

> 
> I'm also confused by:
> 
> end |= start & (0x << 16);
> 
> also in dma_dest_len() - omap_get_dma_dst_pos() returns in the high 16
> bits the full address:
> 
> if (dma_omap1())
> offset |= (p->dma_read(CDSA, lch) & 0x);

CDSA is OMAP_DMA_REG_2X16BIT for omap1
The CPC/CDAC holds the LSB of the _current_ DMA pointer. The code gets
the MSB of the address from the CDSA registers.

> 
> so if the address crosses a 64k physical address boundary, surely orring
> in the start address is wrong?  The more I look at dma_dest_len(), the
> more I wonder whether that and dma_src_len() are anywhere near correct,
> and whether that is a source of breakage for Aaro.

Hrm, again... the position reporting on OMAP1 is certainly not something
I would put my life on :o

> As I've already said, I've no way to test this on hardware.
> 
> Please review and let me know whether I missed anything on the OUT
> handling path.
> 
> Fixing the IN path is going to be a bit more head-scratching.
> 
>  drivers/usb/gadget/udc/omap_udc.c | 154 
> +-
>  drivers/usb/gadget/udc/omap_udc.h |   2 +
>  2 files changed, 120 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/usb/gadget/udc/omap_udc.c 
> b/drivers/usb/gadget/udc/omap_udc.c
> index 3a16431da321..a37e1d2f0f3e 100644
> --- a/drivers/usb/gadget/udc/omap_udc.c
> +++ b/drivers/usb/gadget/udc/omap_udc.c
> @@ -204,6 +204,7 @@ static int omap_ep_enable(struct usb_ep *_ep,
>   ep->dma_channel = 0;
>   ep->has_dma = 0;
>   ep->lch = -1;
> + ep->dma = NULL;
>   use_ep(ep, UDC_EP_SEL);
>   omap_writew(udc->clr_halt, UDC_CTRL);
>   ep->ackwait = 0;
> @@ -576,21 +577,49 @@ static void finish_in_dma(struct omap_ep *ep, struct 
> omap_req *req, int status)
>  static void next_out_dma(struct omap_ep *ep, struct omap_req *req)
>  {
>   unsigned packets = req->req.length - req->req.actual;
> - int dma_trigger = 0;
> + struct dma_async_tx_descriptor *tx;
> + struct dma_chan *dma = ep->dma;
> + dma_cookie_t cookie;
>   u16 w;
>  
> - /* set up this DMA transfer, enable the fifo, start */
> - packets /= ep->ep.maxpacket;
> - packets = min(packets, (unsigned)UDC_RXN_TC + 1);
> + packets = min_t(unsigned, packets / ep->ep.maxpacket, UDC_RXN_TC + 1);
>   req->dma_bytes = packets * 

Linux 4.9.140

[Greg KH]

Sorry for the quick follow-on release, but this resolves two reported
issues that should have gotten into the previous release.

I'm announcing the release of the 4.9.140 kernel.

All users of the 4.9 kernel series must upgrade.

The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.9.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile   |2 -
 arch/x86/kernel/cpu/bugs.c |   57 -
 kernel/cpu.c   |   11 
 net/ipv6/route.c   |   11 ++--
 4 files changed, 16 insertions(+), 65 deletions(-)

Greg Kroah-Hartman (3):
  Revert "x86/speculation: Enable cross-hyperthread spectre v2 STIBP 
mitigation"
  Revert "ipv6: set rt6i_protocol properly in the route when it is 
installed"
  Linux 4.9.140



signature.asc
Description: PGP signature

Re: Linux 4.9.140

[Greg KH]

diff --git a/Makefile b/Makefile
index a6959d96316d..a9aed2326233 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 9
-SUBLEVEL = 139
+SUBLEVEL = 140
 EXTRAVERSION =
 NAME = Roaring Lionus
 
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 647a702c29dc..6221166e3fca 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -33,10 +33,12 @@ static void __init spectre_v2_select_mitigation(void);
 static void __init ssb_select_mitigation(void);
 static void __init l1tf_select_mitigation(void);
 
-/* The base value of the SPEC_CTRL MSR that always has to be preserved. */
-u64 x86_spec_ctrl_base;
+/*
+ * Our boot-time value of the SPEC_CTRL MSR. We read it once so that any
+ * writes to SPEC_CTRL contain whatever reserved bits have been set.
+ */
+u64 __ro_after_init x86_spec_ctrl_base;
 EXPORT_SYMBOL_GPL(x86_spec_ctrl_base);
-static DEFINE_MUTEX(spec_ctrl_mutex);
 
 /*
  * The vendor and possibly platform specific bits which can be modified in
@@ -320,46 +322,6 @@ static enum spectre_v2_mitigation_cmd __init 
spectre_v2_parse_cmdline(void)
return cmd;
 }
 
-static bool stibp_needed(void)
-{
-   if (spectre_v2_enabled == SPECTRE_V2_NONE)
-   return false;
-
-   if (!boot_cpu_has(X86_FEATURE_STIBP))
-   return false;
-
-   return true;
-}
-
-static void update_stibp_msr(void *info)
-{
-   wrmsrl(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base);
-}
-
-void arch_smt_update(void)
-{
-   u64 mask;
-
-   if (!stibp_needed())
-   return;
-
-   mutex_lock(_ctrl_mutex);
-   mask = x86_spec_ctrl_base;
-   if (cpu_smt_control == CPU_SMT_ENABLED)
-   mask |= SPEC_CTRL_STIBP;
-   else
-   mask &= ~SPEC_CTRL_STIBP;
-
-   if (mask != x86_spec_ctrl_base) {
-   pr_info("Spectre v2 cross-process SMT mitigation: %s STIBP\n",
-   cpu_smt_control == CPU_SMT_ENABLED ?
-   "Enabling" : "Disabling");
-   x86_spec_ctrl_base = mask;
-   on_each_cpu(update_stibp_msr, NULL, 1);
-   }
-   mutex_unlock(_ctrl_mutex);
-}
-
 static void __init spectre_v2_select_mitigation(void)
 {
enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
@@ -459,9 +421,6 @@ static void __init spectre_v2_select_mitigation(void)
setup_force_cpu_cap(X86_FEATURE_USE_IBRS_FW);
pr_info("Enabling Restricted Speculation for firmware calls\n");
}
-
-   /* Enable STIBP if appropriate */
-   arch_smt_update();
 }
 
 #undef pr_fmt
@@ -854,8 +813,6 @@ static ssize_t l1tf_show_state(char *buf)
 static ssize_t cpu_show_common(struct device *dev, struct device_attribute 
*attr,
   char *buf, unsigned int bug)
 {
-   int ret;
-
if (!boot_cpu_has_bug(bug))
return sprintf(buf, "Not affected\n");
 
@@ -870,12 +827,10 @@ static ssize_t cpu_show_common(struct device *dev, struct 
device_attribute *attr
return sprintf(buf, "Mitigation: __user pointer 
sanitization\n");
 
case X86_BUG_SPECTRE_V2:
-   ret = sprintf(buf, "%s%s%s%s%s\n", 
spectre_v2_strings[spectre_v2_enabled],
+   return sprintf(buf, "%s%s%s%s\n", 
spectre_v2_strings[spectre_v2_enabled],
   boot_cpu_has(X86_FEATURE_USE_IBPB) ? ", IBPB" : 
"",
   boot_cpu_has(X86_FEATURE_USE_IBRS_FW) ? ", 
IBRS_FW" : "",
-  (x86_spec_ctrl_base & SPEC_CTRL_STIBP) ? ", 
STIBP" : "",
   spectre_v2_module_string());
-   return ret;
 
case X86_BUG_SPEC_STORE_BYPASS:
return sprintf(buf, "%s\n", ssb_strings[ssb_mode]);
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 8d7bace9a7b2..b5a0165b7300 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -1970,12 +1970,6 @@ static void cpuhp_online_cpu_device(unsigned int cpu)
kobject_uevent(>kobj, KOBJ_ONLINE);
 }
 
-/*
- * Architectures that need SMT-specific errata handling during SMT hotplug
- * should override this.
- */
-void __weak arch_smt_update(void) { };
-
 static int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval)
 {
int cpu, ret = 0;
@@ -2002,10 +1996,8 @@ static int cpuhp_smt_disable(enum cpuhp_smt_control 
ctrlval)
 */
cpuhp_offline_cpu_device(cpu);
}
-   if (!ret) {
+   if (!ret)
cpu_smt_control = ctrlval;
-   arch_smt_update();
-   }
cpu_maps_update_done();
return ret;
 }
@@ -2016,7 +2008,6 @@ static int cpuhp_smt_enable(void)
 
cpu_maps_update_begin();
cpu_smt_control = CPU_SMT_ENABLED;
-   arch_smt_update();
for_each_present_cpu(cpu) {
/* Skip online CPUs and CPUs on offline nodes */
if (cpu_online(cpu) || !node_online(cpu_to_node(cpu)))

Re: [RFC PATCH 1/3] mm, proc: be more verbose about unstable VMA flags in /proc//smaps

[Vlastimil Babka]

On 11/20/18 11:35 AM, Michal Hocko wrote:
> From: Michal Hocko 
> 
> Even though vma flags exported via /proc//smaps are explicitly
> documented to be not guaranteed for future compatibility the warning
> doesn't go far enough because it doesn't mention semantic changes to
> those flags. And they are important as well because these flags are
> a deep implementation internal to the MM code and the semantic might
> change at any time.
> 
> Let's consider two recent examples:
> http://lkml.kernel.org/r/20181002100531.gc4...@quack2.suse.cz
> : commit e1fb4a086495 "dax: remove VM_MIXEDMAP for fsdax and device dax" has
> : removed VM_MIXEDMAP flag from DAX VMAs. Now our testing shows that in the
> : mean time certain customer of ours started poking into /proc//smaps
> : and looks at VMA flags there and if VM_MIXEDMAP is missing among the VMA
> : flags, the application just fails to start complaining that DAX support is
> : missing in the kernel.
> 
> http://lkml.kernel.org/r/alpine.deb.2.21.1809241054050.224...@chino.kir.corp.google.com
> : Commit 1860033237d4 ("mm: make PR_SET_THP_DISABLE immediately active")
> : introduced a regression in that userspace cannot always determine the set
> : of vmas where thp is ineligible.
> : Userspace relies on the "nh" flag being emitted as part of /proc/pid/smaps
> : to determine if a vma is eligible to be backed by hugepages.
> : Previous to this commit, prctl(PR_SET_THP_DISABLE, 1) would cause thp to
> : be disabled and emit "nh" as a flag for the corresponding vmas as part of
> : /proc/pid/smaps.  After the commit, thp is disabled by means of an mm
> : flag and "nh" is not emitted.
> : This causes smaps parsing libraries to assume a vma is eligible for thp
> : and ends up puzzling the user on why its memory is not backed by thp.
> 
> In both cases userspace was relying on a semantic of a specific VMA
> flag. The primary reason why that happened is a lack of a proper
> internface. While this has been worked on and it will be fixed properly,
> it seems that our wording could see some refinement and be more vocal
> about semantic aspect of these flags as well.
> 
> Cc: Jan Kara 
> Cc: Dan Williams 
> Cc: David Rientjes 
> Signed-off-by: Michal Hocko 

Agreed, although no amount of docs will override the
do-not-break-userspace rule I'm afraid :)

Acked-by: Vlastimil Babka 

On top of typos reported by Mike:

> ---
>  Documentation/filesystems/proc.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/filesystems/proc.txt 
> b/Documentation/filesystems/proc.txt
> index 12a5e6e693b6..b1fda309f067 100644
> --- a/Documentation/filesystems/proc.txt
> +++ b/Documentation/filesystems/proc.txt
> @@ -496,7 +496,9 @@ flags associated with the particular virtual memory area 
> in two letter encoded
>  
>  Note that there is no guarantee that every flag and associated mnemonic will
>  be present in all further kernel releases. Things get changed, the flags may
> -be vanished or the reverse -- new added.
> +be vanished or the reverse -- new added. Interpretatation of their meaning

^ interpretation

> +might change in future as well. So each consumnent of these flags have to
> +follow each specific kernel version for the exact semantic.
>  
>  This file is only present if the CONFIG_MMU kernel configuration option is
>  enabled.
> 

Re: [RFC PATCH v4 1/5] glibc: Perform rseq(2) registration at nptl init and thread creation

[Rich Felker]

On Fri, Nov 23, 2018 at 02:10:14PM +0100, Florian Weimer wrote:
> * Rich Felker:
> 
> >> I'm not entirely sure because the glibc terminology is confusing, but I
> >> think it places intial-exec TLS into the static TLS area (so that it has
> >> a fixed offset from the TCB).  The static TLS area is placed on the
> >> user-supplied stack.
> >
> > This is an implementation detail that should not leak to applications,
> > and I believe it's still considered a bug, in that, with large static
> > TLS, it could overflow or leave unusably little space left on an
> > otherwise-plenty-large application-provided stack.
> 
> Sure, but that does not matter in this context because right now, there
> is no fix for this bug, and when we fix it, we can take backwards
> compatibility into account.
> 
> Any library that ends up using rseq will need to coordinate with the
> toolchain.  I think that's unavoidable given the kernel interface.

Right. I don't agree with this. What I'm saying is that this behavior
(putting static TLS in the caller-provided stack) should not be
documented as a behavior applications can rely on or accounted as a
solution to the rseq problem, since doing so would preclude fixing the
"application doesn't have as much stack as it requested" bug.

> >> > One issue here is that early adopter libraries cannot always use
> >> > the IE model. I tried using it for other TLS variables in lttng-ust, and
> >> > it ended up hanging our CI tests when tracing a sample application with
> >> > lttng-ust under a Java virtual machine: being dlopen'd in a process that
> >> > possibly already exhausts the number of available backup TLS IE entries
> >> > seems to have odd effects. This is why I'm worried about using the IE 
> >> > model
> >> > within lttng-ust.
> >> 
> >> You can work around this by preloading the library.  I'm not sure if
> >> this is a compelling reason not to use initial-exec TLS memory.
> >
> > Use of IE model from a .so file (except possibly libc.so or something
> > else that inherently needs to be present at program startup for other
> > reasons) should be a considered a bug and unsupported usage.
> > Encouraging libraries to perpetuate this behavior is going backwards
> > on progress that's being made to end it.
> 
> Why?  Just because glibc's TCB allocation strategy is problematic?
> We can fix that, even with dlopen.
> 
> If you are only concerned about the interactions with dlopen, then why
> do you think initial-exec TLS is the problem, and not dlopen?

The initial-exec model, *by design*, only works for TLS objects that
exist at initial execution time. That's why it's called initial-exec.
This is not an implementation flaw/limitation in glibc but
fundamental to the fact that you don't have an unlimited-size (or
practically unlimited) virtual address space range for each thread.
The global-dynamic model is the one that admits dynamic creation of
new TLS objects at runtime (thus the name).

> >> > The per-thread reference counter is a way to avoid issues that arise from
> >> > lack of destructor ordering. Is it an acceptable approach for you, or
> >> > you have something else in mind ?
> >> 
> >> Only for the involved libraries.  It will not help if other TLS
> >> destructors run and use these libraries.
> >
> > Presumably they should have registered their need for rseq too,
> > thereby incrementing the reference count. I'm not sure this is a good
> > idea, but I think I understand it now.
> 
> They may have to increase the reference count from 0 to 1, though, so
> they have to re-register the rseq area.  This tends to get rather messy.
> 
> I still I think implicit destruction of the rseq area is preferable over
> this complexity.

Absolutely. As long as it's in libc, implicit destruction will happen.
Actually I think the glibc code shound unconditionally unregister the
rseq address at exit (after blocking signals, so no application code
can run) in case a third-party rseq library was linked and failed to
do so before thread exit (e.g. due to mismatched ref counts) rather
than respecting the reference count, since it knows it's the last
user. This would make potentially-buggy code safer.

Rich

Re: [PATCH 4.19 00/42] 4.19.4-stable review

[Thomas Voegtle]

On Fri, 23 Nov 2018, Greg Kroah-Hartman wrote:


On Thu, Nov 22, 2018 at 09:53:35PM +0100, Thomas Voegtle wrote:


Doesn't compile for me on OpenSuSE 15.0 (gcc 7.3.1):

  CALLscripts/checksyscalls.sh
  DESCEND  objtool
  CHK include/generated/compile.h
  CC [M]  drivers/gpu/drm/i915/i915_gem_gtt.o
drivers/gpu/drm/i915/i915_gem_gtt.c: In function ‘gen6_dump_ppgtt’:
drivers/gpu/drm/i915/i915_gem_gtt.c:1771:41: error: format ‘%llx’ expects
argument of type ‘long long unsigned int’, but argument 5 has type ‘long
unsigned int’ [-Werror=format=]
seq_printf(m, "\t\t(%03d, %04d) %08llx: ",
~^
%08lx
cc1: all warnings being treated as errors


Warnings treated as errors?  That's rough, sorry, don't do that :)


I had CONFIG_DRM_I915_WERROR=y for whatever reason. 
The whole thing confused me a lot.

Sorry.

  Thomas

Re: [PATCH net-next 3/3] vhost: don't touch avail ring if in_order is negotiated

[Michael S. Tsirkin]

On Fri, Nov 23, 2018 at 11:00:16AM +0800, Jason Wang wrote:
> Device use descriptors table in order, so there's no need to read
> index from available ring. This eliminate the cache contention on
> avail ring completely.

Well this isn't what the in order feature says in the spec.

It forces the used ring to be in the same order as
the available ring. So I don't think you can skip
checking the available ring. And in fact depending on
ring size and workload, using all of descriptor buffer might
cause a slowdown.
Rather you should be able to get
about the same speedup, but from skipping checking
the used ring in virtio.


> Virito-user + vhost_kernel + XDP_DROP gives about ~10% improvement on
> TX from 4.8Mpps to 5.3Mpps on Intel(R) Core(TM) i7-5600U CPU @
> 2.60GHz.
> 
> Signed-off-by: Jason Wang 
> ---
>  drivers/vhost/vhost.c | 19 ---
>  1 file changed, 12 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index 3a5f81a66d34..c8be151bc897 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -2002,6 +2002,7 @@ int vhost_get_vq_desc(struct vhost_virtqueue *vq,
>   __virtio16 avail_idx;
>   __virtio16 ring_head;
>   int ret, access;
> + bool in_order = vhost_has_feature(vq, VIRTIO_F_IN_ORDER);
>  
>   /* Check it isn't doing very strange things with descriptor numbers. */
>   last_avail_idx = vq->last_avail_idx;
> @@ -2034,15 +2035,19 @@ int vhost_get_vq_desc(struct vhost_virtqueue *vq,
>  
>   /* Grab the next descriptor number they're advertising, and increment
>* the index we've seen. */
> - if (unlikely(vhost_get_avail(vq, ring_head,
> -  >avail->ring[last_avail_idx & (vq->num - 1)]))) {
> - vq_err(vq, "Failed to read head: idx %d address %p\n",
> -last_avail_idx,
> ->avail->ring[last_avail_idx % vq->num]);
> - return -EFAULT;
> + if (!in_order) {
> + if (unlikely(vhost_get_avail(vq, ring_head,
> + >avail->ring[last_avail_idx & (vq->num - 1)]))) {
> + vq_err(vq, "Failed to read head: idx %d address %p\n",
> + last_avail_idx,
> + >avail->ring[last_avail_idx % vq->num]);
> + return -EFAULT;
> + }
> + head = vhost16_to_cpu(vq, ring_head);
> + } else {
> + head = last_avail_idx & (vq->num - 1);
>   }
>  
> - head = vhost16_to_cpu(vq, ring_head);
>  
>   /* If their number is silly, that's an error. */
>   if (unlikely(head >= vq->num)) {
> -- 
> 2.17.1

Re: [PATCH 2/3] ntb_hw_switchtec: Added support of >=4G memory windows

[kbuild test robot]

Hi Paul,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v4.20-rc3 next-20181123]
[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/Wesley-Sheng/ntb_hw_switchtec-Added-support-of-4G-memory-windows/20181123-231700
config: i386-randconfig-x077-201846 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/ntb/hw/mscc/ntb_hw_switchtec.c: In function 
'switchtec_ntb_mw_set_direct':
>> drivers/ntb/hw/mscc/ntb_hw_switchtec.c:292:17: warning: right shift count >= 
>> width of type [-Wshift-count-overflow]
 iowrite32(size >> 32, >bar_ext_entry[bar].win_size);
^~
   drivers/ntb/hw/mscc/ntb_hw_switchtec.c: In function 'crosslink_setup_mws':
   drivers/ntb/hw/mscc/ntb_hw_switchtec.c:1061:18: warning: right shift count 
>= width of type [-Wshift-count-overflow]
  iowrite32(size >> 32, >bar_ext_entry[bar].win_size);
 ^~

vim +292 drivers/ntb/hw/mscc/ntb_hw_switchtec.c

   277  
   278  static void switchtec_ntb_mw_set_direct(struct switchtec_ntb *sndev, 
int idx,
   279  dma_addr_t addr, 
resource_size_t size)
   280  {
   281  int xlate_pos = ilog2(size);
   282  int bar = sndev->peer_direct_mw_to_bar[idx];
   283  struct ntb_ctrl_regs __iomem *ctl = sndev->mmio_peer_ctrl;
   284  u32 ctl_val;
   285  
   286  ctl_val = ioread32(>bar_entry[bar].ctl);
   287  ctl_val |= NTB_CTRL_BAR_DIR_WIN_EN;
   288  
   289  iowrite32(ctl_val, >bar_entry[bar].ctl);
   290  iowrite32(xlate_pos | (size & 0xF000),
   291>bar_entry[bar].win_size);
 > 292  iowrite32(size >> 32, >bar_ext_entry[bar].win_size);
   293  iowrite64(sndev->self_partition | addr,
   294>bar_entry[bar].xlate_addr);
   295  }
   296  

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


.config.gz
Description: application/gzip

Re: [PATCH 2/4] base/drivers/arch_topology: Replace mutex with READ_ONCE / WRITE_ONCE

[Sudeep Holla]

On Fri, Nov 23, 2018 at 05:04:18PM +0100, Daniel Lezcano wrote:
> On 23/11/2018 14:58, Sudeep Holla wrote:
> > On Mon, Oct 29, 2018 at 05:23:18PM +0100, Daniel Lezcano wrote:
> >> The mutex protects a per_cpu variable access. The potential race can
> >> happen only when the cpufreq governor module is loaded and at the same
> >> time the cpu capacity is changed in the sysfs.
> >>
> >
> > I wonder if we really need that sysfs entry to be writable. For some
> > reason, I had assumed it's read only, obviously it's not. I prefer to
> > make it RO if there's no strong reason other than debug purposes.
>
> Are you suggesting to remove the READ_ONCE/WRITE_ONCE patch and set the
> sysfs file read-only ?
>

Just to be sure, if we retain RW capability we still need to fix the
race you are pointing out.

However I just don't see the need for RW cpu_capacity sysfs and hence
asking the reason here. IIRC I had pointed this out long back(not sure
internally or externally) but seemed to have missed the version that got
merged. So I am just asking if we really need write capability given that
it has known issues.

If user-space starts writing the value to influence the scheduler, then
it makes it difficult for kernel to change the way it uses the
cpu_capacity in future.

Sorry if there's valid usecase and I am just making noise here.

--
Regards,
Sudeep

[PATCH] ext4: clean up indentation issues, remove extraneous tabs

[Colin King]

From: Colin Ian King 

There are several lines that are indented too far, clean these
up by removing the tabs.

Signed-off-by: Colin Ian King 
---
 fs/ext4/migrate.c | 12 ++--
 fs/ext4/super.c   |  2 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/fs/ext4/migrate.c b/fs/ext4/migrate.c
index 61a9d1927817..5ae61cd8c5c9 100644
--- a/fs/ext4/migrate.c
+++ b/fs/ext4/migrate.c
@@ -535,22 +535,22 @@ int ext4_ext_migrate(struct inode *inode)
if (i_data[EXT4_IND_BLOCK]) {
retval = update_ind_extent_range(handle, tmp_inode,
le32_to_cpu(i_data[EXT4_IND_BLOCK]), );
-   if (retval)
-   goto err_out;
+   if (retval)
+   goto err_out;
} else
lb.curr_block += max_entries;
if (i_data[EXT4_DIND_BLOCK]) {
retval = update_dind_extent_range(handle, tmp_inode,
le32_to_cpu(i_data[EXT4_DIND_BLOCK]), );
-   if (retval)
-   goto err_out;
+   if (retval)
+   goto err_out;
} else
lb.curr_block += max_entries * max_entries;
if (i_data[EXT4_TIND_BLOCK]) {
retval = update_tind_extent_range(handle, tmp_inode,
le32_to_cpu(i_data[EXT4_TIND_BLOCK]), );
-   if (retval)
-   goto err_out;
+   if (retval)
+   goto err_out;
}
/*
 * Build the last extent
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 5603a4a1a864..15fc71398747 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -1940,7 +1940,7 @@ static int handle_mount_opt(struct super_block *sb, char 
*opt, int token,
 #ifdef CONFIG_FS_DAX
ext4_msg(sb, KERN_WARNING,
"DAX enabled. Warning: EXPERIMENTAL, use at your own risk");
-   sbi->s_mount_opt |= m->mount_opt;
+   sbi->s_mount_opt |= m->mount_opt;
 #else
ext4_msg(sb, KERN_INFO, "dax option not supported");
return -1;
-- 
2.19.1

[PATCH] jbd2: clean up indentation issue, replace spaces with tab

[Colin King]

From: Colin Ian King 

There is a statement that is indented with spaces, replace it with
a tab.

Signed-off-by: Colin Ian King 
---
 fs/jbd2/transaction.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/jbd2/transaction.c b/fs/jbd2/transaction.c
index c0b66a7a795b..4af8ff17ad5c 100644
--- a/fs/jbd2/transaction.c
+++ b/fs/jbd2/transaction.c
@@ -910,7 +910,7 @@ do_get_write_access(handle_t *handle, struct journal_head 
*jh,
 * this is the first time this transaction is touching this buffer,
 * reset the modified flag
 */
-   jh->b_modified = 0;
+   jh->b_modified = 0;
 
/*
 * If the buffer is not journaled right now, we need to make sure it
-- 
2.19.1

Re: [PATCH 14/17] ARM: OMAP2+: use pdata quirks for PRUSS reset lines on AM335x

[Tony Lindgren]

* Roger Quadros  [181122 11:40]:
> From: Suman Anna 
> 
> The omap_device API is needed to perform the reset management for
> any IP instances with PRCM RSTCTRL registers (hard reset lines).
> This API is limited to the mach-omap2 layer, and cannot be exposed
> to drivers layer directly. So use platform data ops and pdata quirks
> for the PRUSS IP in AM335x SoCs to plumb the required omap_device
> API. The PRUSS SoC bus driver can then use these pdata ops to
> achieve the required reset functionality.
> 
> This is being implemented this way as there is no separate reset
> driver at the moment.

If the reset-simple approach has issues we can certainly do
this until the issues are fixed. I believe Suman had an issue
where we need to prevent the related clockdomain from idling.

Regards,

Tony

Re: [PATCH] x86: only use ERMS for user copies for larger sizes

[Josh Poimboeuf]

On Thu, Nov 22, 2018 at 12:13:41PM +0100, Ingo Molnar wrote:
> Note to self: watch out for patches that change altinstructions and don't 
> make premature vmlinux size impact assumptions. :-)

I noticed a similar problem with ORC data.  As it turns out, size's
"text" calculation also includes read-only sections.  That includes
.rodata and anything else not writable.

Maybe we need a more sensible "size" script for the kernel.  It would be
trivial to implement based on the output of "readelf -S vmlinux".

-- 
Josh

Re: [PATCH] exec: separate MM_ANONPAGES and RLIMIT_STACK accounting

[Guenter Roeck]

Hi,

On Mon, Nov 12, 2018 at 05:09:10PM +0100, Oleg Nesterov wrote:
> get_arg_page() checks bprm->rlim_stack.rlim_cur and re-calculates the
> "extra" size for argv/envp pointers every time, this is a bit ugly and
> even not strictly correct: acct_arg_size() must not account this size.
> 
> Remove all the rlimit code in get_arg_page(). Instead, add bprm->argmin
> calculated once at the start of __do_execve_file() and change copy_strings
> to check bprm->p >= bprm->argmin.
> 
> The patch adds the new helper, prepare_arg_pages() which initializes
> bprm->argc/envc and bprm->argmin.
> 
> Signed-off-by: Oleg Nesterov 
> Acked-by: Kees Cook 

This patch results in various qemu boot failures in -next. Bisect logs
are attached. It looks like all nommu boots are failing. I bisected an385
and m68k, but xtensa (kc705-nommu) fails with the same error.

[5.416926] Run /sbin/init as init process
[5.419792] Failed to execute /sbin/init (error -7)
[5.421128] Run /sbin/init as init process
[5.423284] Starting init: /sbin/init exists but couldn't execute it (error 
-7)
[5.424747] Run /etc/init as init process
[5.428507] Run /bin/init as init process
[5.430478] Run /bin/sh as init process
[5.433179] Starting init: /bin/sh exists but couldn't execute it (error -7)

Guenter

---
an385:

# bad: [8c9733fd9806c71e7f2313a280f98cb3051f93df] Add linux-next specific files 
for 20181123
# good: [9ff01193a20d391e8dbce4403dd5ef87c7eaaca6] Linux 4.20-rc3
git bisect start 'HEAD' 'v4.20-rc3'
# good: [34c2101b4f765edf1b91c2837da9c60fbf9f6912] Merge remote-tracking branch 
'spi-nor/spi-nor/next'
git bisect good 34c2101b4f765edf1b91c2837da9c60fbf9f6912
# good: [15367a0657fc8027ff3466bf0202bde9f270259b] Merge remote-tracking branch 
'kgdb/kgdb-next'
git bisect good 15367a0657fc8027ff3466bf0202bde9f270259b
# good: [d29686ab179c34c5dbaac067a9effbeeb6a8073e] Merge remote-tracking branch 
'soundwire/next'
git bisect good d29686ab179c34c5dbaac067a9effbeeb6a8073e
# good: [3381311f9a261c9d2863f0d52e9499c88ccb1f44] Merge remote-tracking branch 
'cgroup/for-next'
git bisect good 3381311f9a261c9d2863f0d52e9499c88ccb1f44
# good: [b5bf9c4c28a25b74475c3f3d3fe6d5d737629ab7] Merge remote-tracking branch 
'pinctrl/for-next'
git bisect good b5bf9c4c28a25b74475c3f3d3fe6d5d737629ab7
# good: [a75f6952444a401f5464e977caff2a84118b66c9] fs/epoll: deal with 
wait_queue only once
git bisect good a75f6952444a401f5464e977caff2a84118b66c9
# good: [d83de16290eefb4372520a61744b11bddb6e8f7e] Merge remote-tracking branch 
'slimbus/for-next'
git bisect good d83de16290eefb4372520a61744b11bddb6e8f7e
# good: [f2d2d58687c8300fe4ebf09d78b26cd68c825df7] Merge remote-tracking branch 
'xarray/xarray'
git bisect good f2d2d58687c8300fe4ebf09d78b26cd68c825df7
# bad: [eac22eb65c3cc96d8cb2c7aac7dd816030a86955] ipc: allow boot time 
extension of IPCMNI from 32k to 8M
git bisect bad eac22eb65c3cc96d8cb2c7aac7dd816030a86955
# good: [fb95dde314b136e9598a56350b3de3994d272486] exec: increase 
BINPRM_BUF_SIZE to 256
git bisect good fb95dde314b136e9598a56350b3de3994d272486
# bad: [fb704fe633a3ca80a68282d5c3c665c4382f500b] 
exec-separate-mm_anonpages-and-rlimit_stack-accounting-checkpatch-fixes
git bisect bad fb704fe633a3ca80a68282d5c3c665c4382f500b
# bad: [eed684faf14610c2063c1f03e0a1f5ef56f23bb4] exec: separate MM_ANONPAGES 
and RLIMIT_STACK accounting
git bisect bad eed684faf14610c2063c1f03e0a1f5ef56f23bb4
# first bad commit: [eed684faf14610c2063c1f03e0a1f5ef56f23bb4] exec: separate 
MM_ANONPAGES and RLIMIT_STACK accounting

---
m68k:

# bad: [8c9733fd9806c71e7f2313a280f98cb3051f93df] Add linux-next specific files 
for 20181123
# good: [9ff01193a20d391e8dbce4403dd5ef87c7eaaca6] Linux 4.20-rc3
git bisect start 'HEAD' 'v4.20-rc3'
# good: [34c2101b4f765edf1b91c2837da9c60fbf9f6912] Merge remote-tracking branch 
'spi-nor/spi-nor/next'
git bisect good 34c2101b4f765edf1b91c2837da9c60fbf9f6912
# good: [15367a0657fc8027ff3466bf0202bde9f270259b] Merge remote-tracking branch 
'kgdb/kgdb-next'
git bisect good 15367a0657fc8027ff3466bf0202bde9f270259b
# good: [d29686ab179c34c5dbaac067a9effbeeb6a8073e] Merge remote-tracking branch 
'soundwire/next'
git bisect good d29686ab179c34c5dbaac067a9effbeeb6a8073e
# good: [3381311f9a261c9d2863f0d52e9499c88ccb1f44] Merge remote-tracking branch 
'cgroup/for-next'
git bisect good 3381311f9a261c9d2863f0d52e9499c88ccb1f44
# good: [b5bf9c4c28a25b74475c3f3d3fe6d5d737629ab7] Merge remote-tracking branch 
'pinctrl/for-next'
git bisect good b5bf9c4c28a25b74475c3f3d3fe6d5d737629ab7
# good: [a75f6952444a401f5464e977caff2a84118b66c9] fs/epoll: deal with 
wait_queue only once
git bisect good a75f6952444a401f5464e977caff2a84118b66c9
# good: [d83de16290eefb4372520a61744b11bddb6e8f7e] Merge remote-tracking branch 
'slimbus/for-next'
git bisect good d83de16290eefb4372520a61744b11bddb6e8f7e
# good: [f2d2d58687c8300fe4ebf09d78b26cd68c825df7] Merge remote-tracking branch 
'xarray/