Re: [PATCH v2] Input: applespi - register touchpad device synchronously in probe

2019-07-29 Thread Life is hard, and then you die


  Hi Dmitry,

On Mon, Jul 29, 2019 at 03:22:03PM +0200, Dmitry Torokhov wrote:
> Hi Ronald,
> 
> On Sun, Jul 21, 2019 at 12:05:23AM -0700, Ronald Tschalär wrote:
> > This allows errors during registration to properly fail the probe
> > function.
> > 
> > Doing this requires waiting for a response from the device inside the
> > probe function. While this generally takes about 15ms, in case of errors
> > it could be arbitrarily long, and hence a 3 second timeout is used.
> > 
> > This also adds 3 second timeouts to the drain functions to avoid the
> > potential for suspend or remove hanging forever.
> 
> Question: is it possible to read command response synchronously as well?
> I.e. I was wondering if we could add 2 (or 1?) more read xfers for the
> actual result that is coming after the status response, and then we
> could use spi_sync() to send the command and read the whole thing.

Yes'ish. But you still need to wait for the GPE to know when to read
the response, and while you're doing so any number of keyboard and
trackpad events may arrive (i.e. you may need to do any number of read
xfers). I suppose those events could all just be discarded, though. So
something like this:

assemble-info-cmd(write_msg)
spi_sync(write_msg)

while (1) {
wait_event_timeout(wait_queue, gpe_received, timeout)
spi_sync(read_msg)
if (is-info-cmd-response(read_msg))
break
}

and also modify the gpe-handler to wake the wait_queue instead of
issuing an spy_async() while doing the above.

I guess the advantage would certainly be the need to avoid the
spi-flushing in case of a timeout, at the expense of some slight
duplication of some of the received-message handling logic (would
refactor make most re-usable, of course).

So would this be the preferred approach then?


  Cheers,

  Ronald



Re: [RFC PATCH 00/16] KVM RISC-V Support

2019-07-29 Thread Andreas Schwab
ERROR: "riscv_cs_get_mult_shift" [arch/riscv/kvm/kvm.ko] undefined!
ERROR: "riscv_isa" [arch/riscv/kvm/kvm.ko] undefined!
ERROR: "smp_send_reschedule" [arch/riscv/kvm/kvm.ko] undefined!
ERROR: "riscv_timebase" [arch/riscv/kvm/kvm.ko] undefined!

Andreas.

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


Re: [RFC PATCH 13/16] RISC-V: KVM: Add timer functionality

2019-07-29 Thread Andreas Schwab
On Jul 29 2019, Atish Patra  wrote:

> Strange. We never saw this error.

It is part of CONFIG_KERNEL_HEADER_TEST.  Everyone developing a driver
should enable it.

> #include 
>
> Can you try it at your end and confirm please ?

Confirmed.

Andreas.

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


Re: [PATCH v5 2/3] treewide: Remove dev_err() usage after platform_get_irq()

2019-07-29 Thread Greg Kroah-Hartman
On Mon, Jul 29, 2019 at 10:38:44PM -0700, Stephen Boyd wrote:
> We don't need dev_err() messages when platform_get_irq() fails now that
> platform_get_irq() prints an error message itself when something goes
> wrong. Let's remove these prints with a simple semantic patch.
> 
> // 
> @@
> expression ret;
> struct platform_device *E;
> @@
> 
> ret =
> (
> platform_get_irq(E, ...)
> |
> platform_get_irq_byname(E, ...)
> );
> 
> if ( \( ret < 0 \| ret <= 0 \) )
> {
> (
> -if (ret != -EPROBE_DEFER)
> -{ ...
> -dev_err(...);
> -... }
> |
> ...
> -dev_err(...);
> )
> ...
> }
> // 
> 
> While we're here, remove braces on if statements that only have one
> statement (manually).

I like this, and I like patch 1/3, but this is going to conflict like
crazy all over the tree with who ever ends up taking it in their tree.

Can you just break this up into per-subsystem pieces and send it through
those trees, and any remaining ones I can take, but at least give
maintainers a chance to take it.

You are also going to have to do a sweep every other release or so to
catch the stragglers.

thanks,

greg k-h


Re: [PATCH v5] PM / wakeup: show wakeup sources stats in sysfs

2019-07-29 Thread Greg KH
On Mon, Jul 29, 2019 at 07:43:09PM -0700, Tri Vo wrote:
> Userspace can use wakeup_sources debugfs node to plot history of suspend
> blocking wakeup sources over device's boot cycle. This information can
> then be used (1) for power-specific bug reporting and (2) towards
> attributing battery consumption to specific processes over a period of
> time.
> 
> However, debugfs doesn't have stable ABI. For this reason, create a
> 'struct device' to expose wakeup sources statistics in sysfs under
> /sys/class/wakeup/wakeup/*.

I agree with Rafael here, no need for the extra "wakeup" in the device
name as you are in the "wakeup" namespace already.

If you have an IDA-allocated name, there's no need for the extra
'wakeup' at all.

> +int wakeup_source_sysfs_add(struct device *parent, struct wakeup_source *ws)
> +{
> + struct device *dev;
> + int id;
> +
> + id = ida_simple_get(&wakeup_ida, 0, 0, GFP_KERNEL);
> + if (id < 0)
> + return id;

No lock needed for this ida?  Are you sure?

> + ws->id = id;
> +
> + dev = device_create_with_groups(wakeup_class, parent, MKDEV(0, 0), ws,
> + wakeup_source_groups, "wakeup%d",
> + ws->id);
> + if (IS_ERR(dev)) {
> + ida_simple_remove(&wakeup_ida, ws->id);
> + return PTR_ERR(dev);
> + }
> +
> + ws->dev = dev;
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(wakeup_source_sysfs_add);
> +
> +/**
> + * wakeup_source_sysfs_remove - Remove wakeup_source attributes from sysfs.
> + * @ws: Wakeup source to be removed from sysfs.
> + */
> +void wakeup_source_sysfs_remove(struct wakeup_source *ws)
> +{
> + device_unregister(ws->dev);
> + ida_simple_remove(&wakeup_ida, ws->id);

Again, no lock, is that ok?  I think ida's can work without a lock, but
not always, sorry, I don't remember the rules anymore given the recent
changes in that code.

thanks,

greg k-h


Re: [PATCH 4/5] sched/deadline: Cleanup on_dl_rq() handling

2019-07-29 Thread Juri Lelli
On 29/07/19 18:49, Peter Zijlstra wrote:
> On Fri, Jul 26, 2019 at 09:27:55AM +0100, Dietmar Eggemann wrote:
> > Remove BUG_ON() in __enqueue_dl_entity() since there is already one in
> > enqueue_dl_entity().
> > 
> > Move the check that the dl_se is not on the dl_rq from
> > __dequeue_dl_entity() to dequeue_dl_entity() to align with the enqueue
> > side and use the on_dl_rq() helper function.
> > 
> > Signed-off-by: Dietmar Eggemann 
> > ---
> >  kernel/sched/deadline.c | 8 +++-
> >  1 file changed, 3 insertions(+), 5 deletions(-)
> > 
> > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> > index 1fa005f79307..a9cb52ceb761 100644
> > --- a/kernel/sched/deadline.c
> > +++ b/kernel/sched/deadline.c
> > @@ -1407,8 +1407,6 @@ static void __enqueue_dl_entity(struct 
> > sched_dl_entity *dl_se)
> > struct sched_dl_entity *entry;
> > int leftmost = 1;
> >  
> > -   BUG_ON(!RB_EMPTY_NODE(&dl_se->rb_node));
> > -
> > while (*link) {
> > parent = *link;
> > entry = rb_entry(parent, struct sched_dl_entity, rb_node);
> > @@ -1430,9 +1428,6 @@ static void __dequeue_dl_entity(struct 
> > sched_dl_entity *dl_se)
> >  {
> > struct dl_rq *dl_rq = dl_rq_of_se(dl_se);
> >  
> > -   if (RB_EMPTY_NODE(&dl_se->rb_node))
> > -   return;
> > -
> > rb_erase_cached(&dl_se->rb_node, &dl_rq->root);
> > RB_CLEAR_NODE(&dl_se->rb_node);
> >  
> > @@ -1466,6 +1461,9 @@ enqueue_dl_entity(struct sched_dl_entity *dl_se,
> >  
> >  static void dequeue_dl_entity(struct sched_dl_entity *dl_se)
> >  {
> > +   if (!on_dl_rq(dl_se))
> > +   return;
> 
> Why allow double dequeue instead of WARN?

As I was saying to Valentin, it can currently happen that a task could
have already been dequeued by update_curr_dl()->throttle called by
dequeue_task_dl() before calling __dequeue_task_dl(). Do you think we
should check for this condition before calling into dequeue_dl_entity()?


Re: [RFC] net: phy: read link status twice when phy_check_link_status()

2019-07-29 Thread liuyonglong



On 2019/7/30 14:35, liuyonglong wrote:
> :/sys/kernel/debug/tracing$ cat trace
> # tracer: nop
> #
> # entries-in-buffer/entries-written: 45/45   #P:128
> #
> #  _-=> irqs-off
> # / _=> need-resched
> #| / _---=> hardirq/softirq
> #|| / _--=> preempt-depth
> #||| / delay
> #   TASK-PID   CPU#  TIMESTAMP  FUNCTION
> #  | |   |      | |
> kworker/64:2-1028  [064]    172.295687: mdio_access: mii-:bd:00.0 
> read  phy:0x01 reg:0x02 val:0x001c
> kworker/64:2-1028  [064]    172.295726: mdio_access: mii-:bd:00.0 
> read  phy:0x01 reg:0x03 val:0xc916
> kworker/64:2-1028  [064]    172.296902: mdio_access: mii-:bd:00.0 
> read  phy:0x01 reg:0x01 val:0x79ad
> kworker/64:2-1028  [064]    172.296938: mdio_access: mii-:bd:00.0 
> read  phy:0x01 reg:0x0f val:0x2000
> kworker/64:2-1028  [064]    172.321213: mdio_access: mii-:bd:00.0 
> read  phy:0x01 reg:0x00 val:0x1040
> kworker/64:2-1028  [064]    172.343209: mdio_access: mii-:bd:00.1 
> read  phy:0x03 reg:0x02 val:0x001c
> kworker/64:2-1028  [064]    172.343245: mdio_access: mii-:bd:00.1 
> read  phy:0x03 reg:0x03 val:0xc916
> kworker/64:2-1028  [064]    172.343882: mdio_access: mii-:bd:00.1 
> read  phy:0x03 reg:0x01 val:0x79ad
> kworker/64:2-1028  [064]    172.343918: mdio_access: mii-:bd:00.1 
> read  phy:0x03 reg:0x0f val:0x2000
> kworker/64:2-1028  [064]    172.362658: mdio_access: mii-:bd:00.1 
> read  phy:0x03 reg:0x00 val:0x1040
> kworker/64:2-1028  [064]    172.385961: mdio_access: mii-:bd:00.2 
> read  phy:0x05 reg:0x02 val:0x001c
> kworker/64:2-1028  [064]    172.385996: mdio_access: mii-:bd:00.2 
> read  phy:0x05 reg:0x03 val:0xc916
> kworker/64:2-1028  [064]    172.386646: mdio_access: mii-:bd:00.2 
> read  phy:0x05 reg:0x01 val:0x79ad
> kworker/64:2-1028  [064]    172.386681: mdio_access: mii-:bd:00.2 
> read  phy:0x05 reg:0x0f val:0x2000
> kworker/64:2-1028  [064]    172.411286: mdio_access: mii-:bd:00.2 
> read  phy:0x05 reg:0x00 val:0x1040
> kworker/64:2-1028  [064]    172.433225: mdio_access: mii-:bd:00.3 
> read  phy:0x07 reg:0x02 val:0x001c
> kworker/64:2-1028  [064]    172.433260: mdio_access: mii-:bd:00.3 
> read  phy:0x07 reg:0x03 val:0xc916
> kworker/64:2-1028  [064]    172.433887: mdio_access: mii-:bd:00.3 
> read  phy:0x07 reg:0x01 val:0x79ad
> kworker/64:2-1028  [064]    172.433922: mdio_access: mii-:bd:00.3 
> read  phy:0x07 reg:0x0f val:0x2000
> kworker/64:2-1028  [064]    172.452862: mdio_access: mii-:bd:00.3 
> read  phy:0x07 reg:0x00 val:0x1040
> ifconfig-1324  [011]    177.325585: mdio_access: mii-:bd:00.1 
> read  phy:0x03 reg:0x00 val:0x1040
>   kworker/u257:0-8 [012]    177.325642: mdio_access: mii-:bd:00.1 
> read  phy:0x03 reg:0x04 val:0x01e1
>   kworker/u257:0-8 [012]    177.325654: mdio_access: mii-:bd:00.1 
> write phy:0x03 reg:0x04 val:0x05e1
>   kworker/u257:0-8 [012]    177.325708: mdio_access: mii-:bd:00.1 
> read  phy:0x03 reg:0x01 val:0x79ad
>   kworker/u257:0-8 [012]    177.325744: mdio_access: mii-:bd:00.1 
> read  phy:0x03 reg:0x09 val:0x0200
>   kworker/u257:0-8 [012]    177.325779: mdio_access: mii-:bd:00.1 
> read  phy:0x03 reg:0x00 val:0x1040
>   kworker/u257:0-8 [012]    177.325788: mdio_access: mii-:bd:00.1 
> write phy:0x03 reg:0x00 val:0x1240
>   kworker/u257:0-8 [012]    177.325843: mdio_access: mii-:bd:00.1 
> read  phy:0x03 reg:0x01 val:0x798d
>   kworker/u257:0-8 [003]    178.360488: mdio_access: mii-:bd:00.1 
> read  phy:0x03 reg:0x01 val:0x7989
>   kworker/u257:0-8 [000]    179.384479: mdio_access: mii-:bd:00.1 
> read  phy:0x03 reg:0x01 val:0x7989
>   kworker/u257:0-8 [000]    180.408477: mdio_access: mii-:bd:00.1 
> read  phy:0x03 reg:0x01 val:0x7989
>   kworker/u257:0-8 [000]    181.432474: mdio_access: mii-:bd:00.1 
> read  phy:0x03 reg:0x01 val:0x79a9
>   kworker/u257:0-8 [000]    181.432510: mdio_access: mii-:bd:00.1 
> read  phy:0x03 reg:0x0a val:0x7800
>   kworker/u257:0-8 [000]    181.432546: mdio_access: mii-:bd:00.1 
> read  phy:0x03 reg:0x09 val:0x0200
>   kworker/u257:0-8 [000]    181.432582: mdio_access: mii-:bd:00.1 
> read  phy:0x03 reg:0x05 val:0xc1e1
>   kworker/u257:0-8 [000]    182.456510: mdio_access: mii-:bd:00.1 
> read  phy:0x03 reg:0x01 val:0x79ad
>   kworker/u257:0-8 [000]    182.456546: mdio_access: mii-:bd:00.1 
> read  phy:0x03 reg:0x0a val:0x4800
>   kworker/u257:0-8 [000]    182.456582: mdio_access: mii-:bd:00.1 
> read  phy:

Re: [PATCH 01/12] rdmacg: Replace strncmp with str_has_prefix

2019-07-29 Thread Chuhong Yuan
Kees Cook  于2019年7月30日周二 下午12:26写道:
>
> On Mon, Jul 29, 2019 at 11:13:46PM +0800, Chuhong Yuan wrote:
> > strncmp(str, const, len) is error-prone.
> > We had better use newly introduced
> > str_has_prefix() instead of it.
>
> Wait, stop. :) After Laura called my attention to your conversion series,
> mpe pointed out that str_has_prefix() is almost redundant to strstarts()
> (from 2009), and the latter has many more users. Let's fix strstarts()
> match str_has_prefix()'s return behavior (all the existing callers are
> doing boolean tests, so the change in return value won't matter), and
> then we can continue with this replacement. (And add some documentation
> to Documenation/process/deprecated.rst along with a checkpatch.pl test
> maybe too?)
>

Thanks for your advice!
Does that mean replacing strstarts()'s implementation with
str_has_prefix()'s and then use strstarts() to substitute
strncmp?

I am not very clear about how to add the test into checkpatch.pl.
Should I write a check for this pattern or directly add strncmp into
deprecated_apis?

> Actually I'd focus first on the actually broken cases first (sizeof()
> without the "-1", etc):
>
> $ git grep strncmp.*sizeof | grep -v -- '-' | wc -l
> 17
>
> I expect the "copy/paste" changes could just be a Coccinelle script that
> Linus could run to fix all the cases (and should be added to the kernel
> source's list of Coccinelle scripts). Especially since the bulk of the
> usage pattern are doing literals like this:
>

Actually I am using a Coccinelle script to detect the cases and
have found 800+ places of strncmp(str, const, len).
But the script still needs some improvement since it has false
negatives and only focuses on detecting, not replacement.
I can upload it after improvement.
In which form should I upload it? In a patch's description or put it
in coccinelle scripts?

> arch/alpha/kernel/setup.c:   if (strncmp(p, "mem=", 4) == 0) {
>
> $ git grep -E 'strncmp.*(sizeof|, *[0-9]*)' | wc -l
> 2565
>
> And some cases are weirdly backwards:
>
> tools/perf/util/callchain.c:  if (!strncmp(tok, "none", strlen(tok))) {
>
> -Kees
>

I think with the help of Coccinelle script, all strncmp(str, const, len)
can be replaced and these problems will be eliminated. :)

Regards,
Chuhong

> > Signed-off-by: Chuhong Yuan 
> > ---
> >  kernel/cgroup/rdma.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/cgroup/rdma.c b/kernel/cgroup/rdma.c
> > index ae042c347c64..fd12a227f8e4 100644
> > --- a/kernel/cgroup/rdma.c
> > +++ b/kernel/cgroup/rdma.c
> > @@ -379,7 +379,7 @@ static int parse_resource(char *c, int *intval)
> >   return -EINVAL;
> >   return i;
> >   }
> > - if (strncmp(value, RDMACG_MAX_STR, len) == 0) {
> > + if (str_has_prefix(value, RDMACG_MAX_STR)) {
> >   *intval = S32_MAX;
> >   return i;
> >   }
> > --
> > 2.20.1
> >
>
> --
> Kees Cook


Re: [RFC] net: phy: read link status twice when phy_check_link_status()

2019-07-29 Thread liuyonglong
:/sys/kernel/debug/tracing$ cat trace
# tracer: nop
#
# entries-in-buffer/entries-written: 45/45   #P:128
#
#  _-=> irqs-off
# / _=> need-resched
#| / _---=> hardirq/softirq
#|| / _--=> preempt-depth
#||| / delay
#   TASK-PID   CPU#  TIMESTAMP  FUNCTION
#  | |   |      | |
kworker/64:2-1028  [064]    172.295687: mdio_access: mii-:bd:00.0 
read  phy:0x01 reg:0x02 val:0x001c
kworker/64:2-1028  [064]    172.295726: mdio_access: mii-:bd:00.0 
read  phy:0x01 reg:0x03 val:0xc916
kworker/64:2-1028  [064]    172.296902: mdio_access: mii-:bd:00.0 
read  phy:0x01 reg:0x01 val:0x79ad
kworker/64:2-1028  [064]    172.296938: mdio_access: mii-:bd:00.0 
read  phy:0x01 reg:0x0f val:0x2000
kworker/64:2-1028  [064]    172.321213: mdio_access: mii-:bd:00.0 
read  phy:0x01 reg:0x00 val:0x1040
kworker/64:2-1028  [064]    172.343209: mdio_access: mii-:bd:00.1 
read  phy:0x03 reg:0x02 val:0x001c
kworker/64:2-1028  [064]    172.343245: mdio_access: mii-:bd:00.1 
read  phy:0x03 reg:0x03 val:0xc916
kworker/64:2-1028  [064]    172.343882: mdio_access: mii-:bd:00.1 
read  phy:0x03 reg:0x01 val:0x79ad
kworker/64:2-1028  [064]    172.343918: mdio_access: mii-:bd:00.1 
read  phy:0x03 reg:0x0f val:0x2000
kworker/64:2-1028  [064]    172.362658: mdio_access: mii-:bd:00.1 
read  phy:0x03 reg:0x00 val:0x1040
kworker/64:2-1028  [064]    172.385961: mdio_access: mii-:bd:00.2 
read  phy:0x05 reg:0x02 val:0x001c
kworker/64:2-1028  [064]    172.385996: mdio_access: mii-:bd:00.2 
read  phy:0x05 reg:0x03 val:0xc916
kworker/64:2-1028  [064]    172.386646: mdio_access: mii-:bd:00.2 
read  phy:0x05 reg:0x01 val:0x79ad
kworker/64:2-1028  [064]    172.386681: mdio_access: mii-:bd:00.2 
read  phy:0x05 reg:0x0f val:0x2000
kworker/64:2-1028  [064]    172.411286: mdio_access: mii-:bd:00.2 
read  phy:0x05 reg:0x00 val:0x1040
kworker/64:2-1028  [064]    172.433225: mdio_access: mii-:bd:00.3 
read  phy:0x07 reg:0x02 val:0x001c
kworker/64:2-1028  [064]    172.433260: mdio_access: mii-:bd:00.3 
read  phy:0x07 reg:0x03 val:0xc916
kworker/64:2-1028  [064]    172.433887: mdio_access: mii-:bd:00.3 
read  phy:0x07 reg:0x01 val:0x79ad
kworker/64:2-1028  [064]    172.433922: mdio_access: mii-:bd:00.3 
read  phy:0x07 reg:0x0f val:0x2000
kworker/64:2-1028  [064]    172.452862: mdio_access: mii-:bd:00.3 
read  phy:0x07 reg:0x00 val:0x1040
ifconfig-1324  [011]    177.325585: mdio_access: mii-:bd:00.1 
read  phy:0x03 reg:0x00 val:0x1040
  kworker/u257:0-8 [012]    177.325642: mdio_access: mii-:bd:00.1 
read  phy:0x03 reg:0x04 val:0x01e1
  kworker/u257:0-8 [012]    177.325654: mdio_access: mii-:bd:00.1 
write phy:0x03 reg:0x04 val:0x05e1
  kworker/u257:0-8 [012]    177.325708: mdio_access: mii-:bd:00.1 
read  phy:0x03 reg:0x01 val:0x79ad
  kworker/u257:0-8 [012]    177.325744: mdio_access: mii-:bd:00.1 
read  phy:0x03 reg:0x09 val:0x0200
  kworker/u257:0-8 [012]    177.325779: mdio_access: mii-:bd:00.1 
read  phy:0x03 reg:0x00 val:0x1040
  kworker/u257:0-8 [012]    177.325788: mdio_access: mii-:bd:00.1 
write phy:0x03 reg:0x00 val:0x1240
  kworker/u257:0-8 [012]    177.325843: mdio_access: mii-:bd:00.1 
read  phy:0x03 reg:0x01 val:0x798d
  kworker/u257:0-8 [003]    178.360488: mdio_access: mii-:bd:00.1 
read  phy:0x03 reg:0x01 val:0x7989
  kworker/u257:0-8 [000]    179.384479: mdio_access: mii-:bd:00.1 
read  phy:0x03 reg:0x01 val:0x7989
  kworker/u257:0-8 [000]    180.408477: mdio_access: mii-:bd:00.1 
read  phy:0x03 reg:0x01 val:0x7989
  kworker/u257:0-8 [000]    181.432474: mdio_access: mii-:bd:00.1 
read  phy:0x03 reg:0x01 val:0x79a9
  kworker/u257:0-8 [000]    181.432510: mdio_access: mii-:bd:00.1 
read  phy:0x03 reg:0x0a val:0x7800
  kworker/u257:0-8 [000]    181.432546: mdio_access: mii-:bd:00.1 
read  phy:0x03 reg:0x09 val:0x0200
  kworker/u257:0-8 [000]    181.432582: mdio_access: mii-:bd:00.1 
read  phy:0x03 reg:0x05 val:0xc1e1
  kworker/u257:0-8 [000]    182.456510: mdio_access: mii-:bd:00.1 
read  phy:0x03 reg:0x01 val:0x79ad
  kworker/u257:0-8 [000]    182.456546: mdio_access: mii-:bd:00.1 
read  phy:0x03 reg:0x0a val:0x4800
  kworker/u257:0-8 [000]    182.456582: mdio_access: mii-:bd:00.1 
read  phy:0x03 reg:0x09 val:0x0200
  kworker/u257:0-8 [000]    182.456618: mdio_access: mii-:bd:00.1 
read  phy:0x03 reg:0x05 val:0xc1e1
  kworker/u257:0-8 [001]    183.480476: mdio_access: mii-:bd:00.1 

Re: [PATCH v2 00/12] tracing/probe: Add multi-probes per event support

2019-07-29 Thread Masami Hiramatsu
Hi Steve,

Have you already picked this series?
If not yet, should I update and resend this series?

Thank you,

On Thu, 4 Jul 2019 07:28:33 -0400
Steven Rostedt  wrote:

> On Thu, 4 Jul 2019 15:39:58 +0900
> Masami Hiramatsu  wrote:
> 
> > Hi Steve,
> > 
> > Would you have any comment on this?
> > 
> 
> Hi Masami,
> 
> It's on my todo list. As today is a US holiday, I'll look at this on
> Monday.
> 
> Thanks for the reminder!
> 
> -- Steve
> 
> 
> > Thank you,
> > 
> > On Thu, 20 Jun 2019 00:07:09 +0900
> > Masami Hiramatsu  wrote:
> > 
> > > Hello,
> > > 
> > > This is the 2nd version of multi-probes per event support on ftrace
> > > and perf-tools.
> > > 
> > > Previous version is here;
> > > https://lkml.org/lkml/2019/5/31/573
> > >   
> > > >From this version, I omitted first 9 patches which has been picked  
> > > to Steve's tree.
> > > In this version, I've fixed some bugs and hardened some unexpected
> > > error cases according to Steve's comment.
> > > Here are changes in this version:
> > > 
> > >  - [1/12] This have below changes. 
> > > - Warn if the primary trace_probe does not exist.
> > > - Fix enable_trace_kprobe() to not return error if the any probes
> > >   are "gone" state. If all probes have gone or any other error
> > >   reason, the event can not be enabled and return error.
> > > - Fix trace_probe_enable() to roll back all enabled uprobe if
> > >   any one of uprobe is failed to enable.
> > >  - [7/12] Swap the checking order of filename for avoiding unexpected
> > >  memory access.
> > > 
> > > 
> > > 
> > > For trace-event, we can insert same trace-event on several places
> > > on the code, and those can record similar information as a same event
> > > with same format.
> > > 
> > > This series implements similar feature on probe-event. Since the probe
> > > event is based on the compiled binary, sometimes we find that the target
> > > source line is complied into several different addresses, e.g. inlined
> > > function, unrolled loop, etc. In those cases, it is useful to put a
> > > same probe-event on different addresses.
> > > 
> > > With this series, we can append multi probes on one event as below
> > > 
> > >   # echo p:testevent _do_fork r1=%ax r2=%dx > kprobe_events
> > >   # echo p:testevent fork_idle r1=%ax r2=%cx >> kprobe_events
> > >   # kprobe_events
> > >   p:kprobes/testevent _do_fork r1=%ax r2=%dx
> > >   p:kprobes/testevent fork_idle r1=%ax r2=%cx
> > > 
> > > This means testevent is hit on both of _do_fork and fork_idle.
> > > As you can see, the appended event must have same number of arguments
> > > and those must have same 'type' and 'name' as original one. This is like
> > > a function signature, it checks whether the appending event has the same
> > > type and name of event arguments and same probe type, but doesn't care
> > > about the assignment.
> > > 
> > > So, below appending commands will be rejected.
> > > 
> > >   # echo p:testevent _do_fork r1=%ax r2=%dx > kprobe_events
> > >   # echo p:testevent fork_idle r1=%ax >> kprobe_events
> > >   (No 2nd argument)
> > >   # echo p:testevent fork_idle r1=%ax r2=%ax:x8 >> kprobe_events
> > >   (The type of 2nd argument is different)
> > > 
> > > If one inlined code has an argument on a register, but another
> > > inlined code has fixed value (as a result of optimization),
> > > you can also specify the fixed immediate value, e.g.
> > > 
> > >   # echo p:testevent _do_fork r1=%ax r2=%dx > kprobe_events
> > >   # echo p:testevent fork_idle r1=%ax r2=\1 >> kprobe_events
> > > 
> > > 
> > > Thank you,
> > > 
> > > ---
> > > 
> > > Masami Hiramatsu (12):
> > >   tracing/probe: Split trace_event related data from trace_probe
> > >   tracing/dynevent: Delete all matched events
> > >   tracing/dynevent: Pass extra arguments to match operation
> > >   tracing/kprobe: Add multi-probe per event support
> > >   tracing/uprobe: Add multi-probe per uprobe event support
> > >   tracing/kprobe: Add per-probe delete from event
> > >   tracing/uprobe: Add per-probe delete from event
> > >   tracing/probe: Add immediate parameter support
> > >   tracing/probe: Add immediate string parameter support
> > >   selftests/ftrace: Add a testcase for kprobe multiprobe event
> > >   selftests/ftrace: Add syntax error test for immediates
> > >   selftests/ftrace: Add syntax error test for multiprobe
> > > 
> > > 
> > >  Documentation/trace/kprobetrace.rst|1 
> > >  Documentation/trace/uprobetracer.rst   |1 
> > >  kernel/trace/trace.c   |8 -
> > >  kernel/trace/trace_dynevent.c  |   10 +
> > >  kernel/trace/trace_dynevent.h  |7 -
> > >  kernel/trace/trace_events_hist.c   |4 
> > >  kernel/trace/trace_kprobe.c|  241 
> > > ++
> > >  kernel/trace/trace_probe.c |  176 +

[PATCH v3 2/2] mmc: Add support for the ASPEED SD controller

2019-07-29 Thread Andrew Jeffery
Add a minimal driver for ASPEED's SD controller, which exposes two
SDHCIs.

The ASPEED design implements a common register set for the SDHCIs, and
moves some of the standard configuration elements out to this common
area (e.g. 8-bit mode, and card detect configuration which is not
currently supported).

The SD controller has a dedicated hardware interrupt that is shared
between the slots. The common register set exposes information on which
slot triggered the interrupt; early revisions of the patch introduced an
irqchip for the register, but reality is it doesn't behave as an
irqchip, and the result fits awkwardly into the irqchip APIs. Instead
I've taken the simple approach of using the IRQ as a shared IRQ with
some minor performance impact for the second slot.

Ryan was the original author of the patch - I've taken his work and
massaged it to drop the irqchip support and rework the devicetree
integration. The driver has been smoke tested under qemu against a
minimal SD controller model and lightly tested on an ast2500-evb.

Signed-off-by: Ryan Chen 
Signed-off-by: Andrew Jeffery 

---
v3:
* Add AST2600 compatible
* Drop SDHCI_QUIRK2_CLOCK_DIV_ZERO_BROKEN
* Ensure slot number is valid
* Fix build with CONFIG_MODULES
* Fix module license string
* Non-PCI devices won't die
* Rename aspeed_sdc_configure_8bit_mode()
* Rename aspeed_sdhci_pdata
* Switch to sdhci_enable_clk()
* Use PTR_ERR() on the right `struct platform_device *`
---
 drivers/mmc/host/Kconfig   |  12 ++
 drivers/mmc/host/Makefile  |   1 +
 drivers/mmc/host/sdhci-of-aspeed.c | 328 +
 3 files changed, 341 insertions(+)
 create mode 100644 drivers/mmc/host/sdhci-of-aspeed.c

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 14d89a108edd..0f8a230de2f3 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -154,6 +154,18 @@ config MMC_SDHCI_OF_ARASAN
 
  If unsure, say N.
 
+config MMC_SDHCI_OF_ASPEED
+   tristate "SDHCI OF support for the ASPEED SDHCI controller"
+   depends on MMC_SDHCI_PLTFM
+   depends on OF
+   help
+ This selects the ASPEED Secure Digital Host Controller Interface.
+
+ If you have a controller with this interface, say Y or M here. You
+ also need to enable an appropriate bus interface.
+
+ If unsure, say N.
+
 config MMC_SDHCI_OF_AT91
tristate "SDHCI OF support for the Atmel SDMMC controller"
depends on MMC_SDHCI_PLTFM
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 73578718f119..390ee162fe71 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -84,6 +84,7 @@ obj-$(CONFIG_MMC_SDHCI_ESDHC_IMX) += sdhci-esdhc-imx.o
 obj-$(CONFIG_MMC_SDHCI_DOVE)   += sdhci-dove.o
 obj-$(CONFIG_MMC_SDHCI_TEGRA)  += sdhci-tegra.o
 obj-$(CONFIG_MMC_SDHCI_OF_ARASAN)  += sdhci-of-arasan.o
+obj-$(CONFIG_MMC_SDHCI_OF_ASPEED)  += sdhci-of-aspeed.o
 obj-$(CONFIG_MMC_SDHCI_OF_AT91)+= sdhci-of-at91.o
 obj-$(CONFIG_MMC_SDHCI_OF_ESDHC)   += sdhci-of-esdhc.o
 obj-$(CONFIG_MMC_SDHCI_OF_HLWD)+= sdhci-of-hlwd.o
diff --git a/drivers/mmc/host/sdhci-of-aspeed.c 
b/drivers/mmc/host/sdhci-of-aspeed.c
new file mode 100644
index ..d31785ec90d7
--- /dev/null
+++ b/drivers/mmc/host/sdhci-of-aspeed.c
@@ -0,0 +1,328 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/* Copyright (C) 2019 ASPEED Technology Inc. */
+/* Copyright (C) 2019 IBM Corp. */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sdhci-pltfm.h"
+
+#define ASPEED_SDC_INFO0x00
+#define   ASPEED_SDC_S1MMC8BIT(25)
+#define   ASPEED_SDC_S0MMC8BIT(24)
+
+struct aspeed_sdc {
+   struct clk *clk;
+   struct resource *res;
+
+   spinlock_t lock;
+   void __iomem *regs;
+};
+
+struct aspeed_sdhci {
+   struct aspeed_sdc *parent;
+   u32 width_mask;
+};
+
+static void aspeed_sdc_configure_8bit_mode(struct aspeed_sdc *sdc,
+  struct aspeed_sdhci *sdhci,
+  bool bus8)
+{
+   u32 info;
+
+   /* Set/clear 8 bit mode */
+   spin_lock(&sdc->lock);
+   info = readl(sdc->regs + ASPEED_SDC_INFO);
+   if (bus8)
+   info |= sdhci->width_mask;
+   else
+   info &= ~sdhci->width_mask;
+   writel(info, sdc->regs + ASPEED_SDC_INFO);
+   spin_unlock(&sdc->lock);
+}
+
+static void aspeed_sdhci_set_clock(struct sdhci_host *host, unsigned int clock)
+{
+   int div;
+   u16 clk;
+
+   if (clock == host->clock)
+   return;
+
+   sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL);
+
+   if (clock == 0)
+   goto out;
+
+   for (div = 1; div < 256; div *= 2) {
+   if ((host->max_clk / div) <= clock)
+   break;
+   }
+   div >>

[PATCH v3 0/2] mmc: Add support for the ASPEED SD controller

2019-07-29 Thread Andrew Jeffery
Hello,

v3 of the ASPEED SDHCI driver makes a bunch of fixes to the driver and the
devicetree binding, including the addition of the AST2600 compatible string.

v2 can be found here:

https://lists.ozlabs.org/pipermail/linux-aspeed/2019-July/002013.html

Please review!

Andrew

Andrew Jeffery (2):
  dt-bindings: mmc: Document Aspeed SD controller
  mmc: Add support for the ASPEED SD controller

 .../devicetree/bindings/mmc/aspeed,sdhci.yaml | 100 ++
 drivers/mmc/host/Kconfig  |  12 +
 drivers/mmc/host/Makefile |   1 +
 drivers/mmc/host/sdhci-of-aspeed.c| 328 ++
 4 files changed, 441 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
 create mode 100644 drivers/mmc/host/sdhci-of-aspeed.c

-- 
2.20.1



[PATCH v3 1/2] dt-bindings: mmc: Document Aspeed SD controller

2019-07-29 Thread Andrew Jeffery
The ASPEED SD/SDIO/eMMC controller exposes two slots implementing the
SDIO Host Specification v2.00, with 1 or 4 bit data buses, or an 8 bit
data bus if only a single slot is enabled.

Signed-off-by: Andrew Jeffery 

---
v3:
* Fix compatible enums
* Add AST2600 compatibles
* Describe #address-cells / #size-cells
---
 .../devicetree/bindings/mmc/aspeed,sdhci.yaml | 100 ++
 1 file changed, 100 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml

diff --git a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml 
b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
new file mode 100644
index ..dd2a00c59641
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/aspeed,sdhci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASPEED SD/SDIO/eMMC Controller
+
+maintainers:
+  - Andrew Jeffery 
+  - Ryan Chen 
+
+description: |+
+  The ASPEED SD/SDIO/eMMC controller exposes two slots implementing the SDIO
+  Host Specification v2.00, with 1 or 4 bit data buses, or an 8 bit data bus if
+  only a single slot is enabled.
+
+  The two slots are supported by a common configuration area. As the SDHCIs for
+  the slots are dependent on the common configuration area, they are described
+  as child nodes.
+
+properties:
+  compatible:
+enum:
+  - aspeed,ast2400-sd-controller
+  - aspeed,ast2500-sd-controller
+  - aspeed,ast2600-sd-controller
+  reg:
+maxItems: 1
+description: Common configuration registers
+  "#address-cells":
+const: 1
+  "#size-cells":
+const: 1
+  ranges: true
+  clocks:
+maxItems: 1
+description: The SD/SDIO controller clock gate
+
+patternProperties:
+  "^sdhci@[0-9a-f]+$":
+type: object
+properties:
+  compatible:
+enum:
+  - aspeed,ast2400-sdhci
+  - aspeed,ast2500-sdhci
+  - aspeed,ast2600-sdhci
+  reg:
+maxItems: 1
+description: The SDHCI registers
+  clocks:
+maxItems: 1
+description: The SD bus clock
+  interrupts:
+maxItems: 1
+description: The SD interrupt shared between both slots
+required:
+  - compatible
+  - reg
+  - clocks
+  - interrupts
+
+additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - "#address-cells"
+  - "#size-cells"
+  - ranges
+  - clocks
+
+examples:
+  - |
+#include 
+sdc@1e74 {
+compatible = "aspeed,ast2500-sd-controller";
+reg = <0x1e74 0x100>;
+#address-cells = <1>;
+#size-cells = <1>;
+ranges = <0 0x1e74 0x1>;
+clocks = <&syscon ASPEED_CLK_GATE_SDCLK>;
+
+sdhci0: sdhci@100 {
+compatible = "aspeed,ast2500-sdhci";
+reg = <0x100 0x100>;
+interrupts = <26>;
+sdhci,auto-cmd12;
+clocks = <&syscon ASPEED_CLK_SDIO>;
+};
+
+sdhci1: sdhci@200 {
+compatible = "aspeed,ast2500-sdhci";
+reg = <0x200 0x100>;
+interrupts = <26>;
+sdhci,auto-cmd12;
+clocks = <&syscon ASPEED_CLK_SDIO>;
+};
+};
-- 
2.20.1



[PATCH] x86/mce: Remove redundant irq work

2019-07-29 Thread Santosh Sivaraj
IRQ work currently only does a schedule work to process the mce
events. Since irq work does no other function, remove it.

Signed-off-by: Santosh Sivaraj 
---
 arch/x86/kernel/cpu/mce/core.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index 743370ee4983..658da808c031 100644
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -119,7 +119,7 @@ DEFINE_PER_CPU(mce_banks_t, mce_poll_banks) = {
 mce_banks_t mce_banks_ce_disabled;
 
 static struct work_struct mce_work;
-static struct irq_work mce_irq_work;
+static void mce_schedule_work(void);
 
 static void (*quirk_no_way_out)(int bank, struct mce *m, struct pt_regs *regs);
 
@@ -154,7 +154,7 @@ EXPORT_PER_CPU_SYMBOL_GPL(injectm);
 void mce_log(struct mce *m)
 {
if (!mce_gen_pool_add(m))
-   irq_work_queue(&mce_irq_work);
+   mce_schedule_work();
 }
 
 void mce_inject_log(struct mce *m)
@@ -472,11 +472,6 @@ static void mce_schedule_work(void)
schedule_work(&mce_work);
 }
 
-static void mce_irq_work_cb(struct irq_work *entry)
-{
-   mce_schedule_work();
-}
-
 /*
  * Check if the address reported by the CPU is in a format we can parse.
  * It would be possible to add code for most other cases, but all would
@@ -1333,7 +1328,7 @@ void do_machine_check(struct pt_regs *regs, long 
error_code)
mce_panic("Fatal machine check on current CPU", &m, msg);
 
if (worst > 0)
-   irq_work_queue(&mce_irq_work);
+   mce_schedule_work();
 
mce_wrmsrl(MSR_IA32_MCG_STATUS, 0);
 
@@ -1984,7 +1979,6 @@ int __init mcheck_init(void)
mcheck_vendor_init_severity();
 
INIT_WORK(&mce_work, mce_gen_pool_process);
-   init_irq_work(&mce_irq_work, mce_irq_work_cb);
 
return 0;
 }
-- 
2.20.1



Re: [PATCH RESEND 0/8] Fix mmap base in bottom-up mmap

2019-07-29 Thread Alexandre Ghiti

On 6/20/19 7:03 AM, Alexandre Ghiti wrote:

This series fixes the fallback of the top-down mmap: in case of
failure, a bottom-up scheme can be tried as a last resort between
the top-down mmap base and the stack, hoping for a large unused stack
limit.

Lots of architectures and even mm code start this fallback
at TASK_UNMAPPED_BASE, which is useless since the top-down scheme
already failed on the whole address space: instead, simply use
mmap_base.

Along the way, it allows to get rid of of mmap_legacy_base and
mmap_compat_legacy_base from mm_struct.

Note that arm and mips already implement this behaviour.

Alexandre Ghiti (8):
   s390: Start fallback of top-down mmap at mm->mmap_base
   sh: Start fallback of top-down mmap at mm->mmap_base
   sparc: Start fallback of top-down mmap at mm->mmap_base
   x86, hugetlbpage: Start fallback of top-down mmap at mm->mmap_base
   mm: Start fallback top-down mmap at mm->mmap_base
   parisc: Use mmap_base, not mmap_legacy_base, as low_limit for
 bottom-up mmap
   x86: Use mmap_*base, not mmap_*legacy_base, as low_limit for bottom-up
 mmap
   mm: Remove mmap_legacy_base and mmap_compat_legacy_code fields from
 mm_struct

  arch/parisc/kernel/sys_parisc.c  |  8 +++-
  arch/s390/mm/mmap.c  |  2 +-
  arch/sh/mm/mmap.c|  2 +-
  arch/sparc/kernel/sys_sparc_64.c |  2 +-
  arch/sparc/mm/hugetlbpage.c  |  2 +-
  arch/x86/include/asm/elf.h   |  2 +-
  arch/x86/kernel/sys_x86_64.c |  4 ++--
  arch/x86/mm/hugetlbpage.c|  7 ---
  arch/x86/mm/mmap.c   | 20 +---
  include/linux/mm_types.h |  2 --
  mm/debug.c   |  4 ++--
  mm/mmap.c|  2 +-
  12 files changed, 26 insertions(+), 31 deletions(-)



Hi everyone,

This is just a preparatory series for the merging of x86 mmap top-down 
functions with
the generic ones (those should get into v5.3), if you could take some 
time to take a look,

that would be great :)

Thanks,

Alex



Re: [RFC] net: phy: read link status twice when phy_check_link_status()

2019-07-29 Thread Heiner Kallweit
On 30.07.2019 06:03, liuyonglong wrote:
> 
> 
> On 2019/7/30 4:57, Heiner Kallweit wrote:
>> On 29.07.2019 05:59, liuyonglong wrote:
>>>
>>>
>>> On 2019/7/27 2:14, Heiner Kallweit wrote:
 On 26.07.2019 11:53, Yonglong Liu wrote:
> According to the datasheet of Marvell phy and Realtek phy, the
> copper link status should read twice, or it may get a fake link
> up status, and cause up->down->up at the first time when link up.
> This happens more oftem at Realtek phy.
>
 This is not correct, there is no fake link up status.
 Read the comment in genphy_update_link, only link-down events
 are latched. Means if the first read returns link up, then there
 is no need for a second read. And in polling mode we don't do a
 second read because we want to detect also short link drops.

 It would be helpful if you could describe your actual problem
 and whether you use polling or interrupt mode.

>>>
>>> [   44.498633] hns3 :bd:00.1 eth5: net open
>>> [   44.504273] hns3 :bd:00.1: reg=0x1, data=0x79ad -> called from 
>>> phy_start_aneg
>>> [   44.532348] hns3 :bd:00.1: reg=0x1, data=0x798d -> called from 
>>> phy_state_machine,update link.
>>
>> This should not happen. The PHY indicates link up w/o having aneg finished.
>>
>>>
>>> According to the datasheet:
>>> reg 1.5=0 now, means copper auto-negotiation not complete
>>> reg 1.2=1 now, means link is up
>>>
>>> We can see that, when we read the link up, the auto-negotiation
>>> is not complete yet, so the speed is invalid.
>>>
>>> I don't know why this happen, maybe this state is keep from bios?
>>> Or we may do something else in the phy initialize to fix it?
>>> And also confuse that why read twice can fix it?
>>>
>> I suppose that basically any delay would do.
>>
>>> [   44.554063] hns3 :bd:00.1: invalid speed (-1)
>>> [   44.560412] hns3 :bd:00.1 eth5: failed to adjust link.
>>> [   45.194870] hns3 :bd:00.1 eth5: link up
>>> [   45.574095] hns3 :bd:00.1: phyid=3, reg=0x1, data=0x7989
>>> [   46.150051] hns3 :bd:00.1 eth5: link down
>>> [   46.598074] hns3 :bd:00.1: phyid=3, reg=0x1, data=0x7989
>>> [   47.622075] hns3 :bd:00.1: phyid=3, reg=0x1, data=0x79a9
>>> [   48.646077] hns3 :bd:00.1: phyid=3, reg=0x1, data=0x79ad
>>> [   48.934050] hns3 :bd:00.1 eth5: link up
>>> [   49.702140] hns3 :bd:00.1: phyid=3, reg=0x1, data=0x79ad
>>>
> I add a fake status read, and can solve this problem.
>
> I also see that in genphy_update_link(), had delete the fake
> read in polling mode, so I don't know whether my solution is
> correct.
>
>>
>> Can you test whether the following fixes the issue for you?
>> Also it would be interesting which exact PHY models you tested
>> and whether you built the respective PHY drivers or whether you
>> rely on the genphy driver. Best use the second patch to get the
>> needed info. It may make sense anyway to add the call to
>> phy_attached_info() to the hns3 driver.
>>
> 
> [   40.100716] RTL8211F Gigabit Ethernet mii-:bd:00.3:07: attached PHY 
> driver [RTL8211F Gigabit Ethernet] (mii_bus:phy_addr=mii-:bd:00.3:07, 
> irq=POLL)
> [   40.932133] hns3 :bd:00.3 eth7: net open
> [   40.932458] hns3 :bd:00.3: invalid speed (-1)
> [   40.932541] 8021q: adding VLAN 0 to HW filter on device eth7
> [   40.937149] hns3 :bd:00.3 eth7: failed to adjust link.
> 
> [   40.662050] Generic PHY mii-:bd:00.2:05: attached PHY driver [Generic 
> PHY] (mii_bus:phy_addr=mii-:bd:00.2:05, irq=POLL)
> [   41.563511] hns3 :bd:00.2 eth6: net open
> [   41.563853] hns3 :bd:00.2: invalid speed (-1)
> [   41.563943] 8021q: adding VLAN 0 to HW filter on device eth6
> [   41.568578] IPv6: ADDRCONF(NETDEV_CHANGE): eth6: link becomes ready
> [   41.568898] hns3 :bd:00.2 eth6: failed to adjust link.
> 
> I am using RTL8211F, but you can see that, both genphy driver and
> RTL8211F driver have the same issue.
> 
>>
>> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
>> index 6b5cb87f3..fbecfe210 100644
>> --- a/drivers/net/phy/phy_device.c
>> +++ b/drivers/net/phy/phy_device.c
>> @@ -1807,7 +1807,8 @@ int genphy_read_status(struct phy_device *phydev)
>>  
>>  linkmode_zero(phydev->lp_advertising);
>>  
>> -if (phydev->autoneg == AUTONEG_ENABLE && phydev->autoneg_complete) {
>> +if (phydev->autoneg == AUTONEG_ENABLE &&
>> +(phydev->autoneg_complete || phydev->link)) {
>>  if (phydev->is_gigabit_capable) {
>>  lpagb = phy_read(phydev, MII_STAT1000);
>>  if (lpagb < 0)
>>
> 
> I have try this patch, have no effect. I suppose that at this time,
> the autoneg actually not complete yet.
> 
> Maybe the wrong phy state is passed from bios? Invalid speed just
> happen at the first time when ethX up, after that, repeat the
> ifconfig down/ifconfig up command can not see that again.
> 
> So I think the bios should power off 

[PATCH V2] scsi: ufs: revamp string descriptor reading

2019-07-29 Thread Tomas Winkler
Define new a type: uc_string_id for easier string
handling and less casting. Reduce number or string
copies in price of a dynamic allocation.

Signed-off-by: Tomas Winkler 
Tested-by: Avri Altman 
---
V2:
   a. Use u8 instead of char as result string is utf8
   b. In ufshcd_read_desc_param() keep buffer typed u8*

 drivers/scsi/ufs/ufs-sysfs.c |  18 ++--
 drivers/scsi/ufs/ufs.h   |   2 +-
 drivers/scsi/ufs/ufshcd.c| 162 +--
 drivers/scsi/ufs/ufshcd.h|   7 +-
 4 files changed, 112 insertions(+), 77 deletions(-)

diff --git a/drivers/scsi/ufs/ufs-sysfs.c b/drivers/scsi/ufs/ufs-sysfs.c
index f478685122ff..969a36b15897 100644
--- a/drivers/scsi/ufs/ufs-sysfs.c
+++ b/drivers/scsi/ufs/ufs-sysfs.c
@@ -571,9 +571,10 @@ static ssize_t _name##_show(struct device *dev,
\
int ret;\
int desc_len = QUERY_DESC_MAX_SIZE; \
u8 *desc_buf;   \
+   \
desc_buf = kzalloc(QUERY_DESC_MAX_SIZE, GFP_ATOMIC);\
-   if (!desc_buf)  \
-   return -ENOMEM; \
+   if (!desc_buf)  \
+   return -ENOMEM; \
ret = ufshcd_query_descriptor_retry(hba,\
UPIU_QUERY_OPCODE_READ_DESC, QUERY_DESC_IDN_DEVICE, \
0, 0, desc_buf, &desc_len); \
@@ -582,14 +583,13 @@ static ssize_t _name##_show(struct device *dev,   
\
goto out;   \
}   \
index = desc_buf[DEVICE_DESC_PARAM##_pname];\
-   memset(desc_buf, 0, QUERY_DESC_MAX_SIZE);   \
-   if (ufshcd_read_string_desc(hba, index, desc_buf,   \
-   QUERY_DESC_MAX_SIZE, true)) {   \
-   ret = -EINVAL;  \
+   kfree(desc_buf);\
+   desc_buf = NULL;\
+   ret = ufshcd_read_string_desc(hba, index, &desc_buf,\
+ SD_ASCII_STD);\
+   if (ret < 0)\
goto out;   \
-   }   \
-   ret = snprintf(buf, PAGE_SIZE, "%s\n",  \
-   desc_buf + QUERY_DESC_HDR_SIZE);\
+   ret = snprintf(buf, PAGE_SIZE, "%s\n", desc_buf);   \
 out:   \
kfree(desc_buf);\
return ret; \
diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
index 99a9c4d16f6b..3327981ef894 100644
--- a/drivers/scsi/ufs/ufs.h
+++ b/drivers/scsi/ufs/ufs.h
@@ -541,7 +541,7 @@ struct ufs_dev_info {
  */
 struct ufs_dev_desc {
u16 wmanufacturerid;
-   char model[MAX_MODEL_LEN + 1];
+   u8 *model;
 };
 
 /**
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index a383d0f54f5d..507fd51e8039 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -299,16 +299,6 @@ static void ufshcd_scsi_block_requests(struct ufs_hba *hba)
scsi_block_requests(hba->host);
 }
 
-/* replace non-printable or non-ASCII characters with spaces */
-static inline void ufshcd_remove_non_printable(char *val)
-{
-   if (!val)
-   return;
-
-   if (*val < 0x20 || *val > 0x7e)
-   *val = ' ';
-}
-
 static void ufshcd_add_cmd_upiu_trace(struct ufs_hba *hba, unsigned int tag,
const char *str)
 {
@@ -3211,7 +3201,7 @@ int ufshcd_read_desc_param(struct ufs_hba *hba,
 static inline int ufshcd_read_desc(struct ufs_hba *hba,
   enum desc_idn desc_id,
   int desc_index,
-  u8 *buf,
+  void *buf,
   u32 size)
 {
return ufshcd_read_desc_param(hba, desc_id, desc_index, 0, buf, size);
@@ -3229,49 +3219,78 @@ static int ufshcd_read_device_desc(struct ufs_hba *hba, 
u8 *buf, u32 size)
return ufshcd_read_desc(hba, QUERY_DESC_IDN_DEVICE, 0, buf, size);
 }
 
+/**
+ * struct uc_string_id - unicode string
+ *
+ * @len: size o

[PATCH v5 14/14] riscv: Make mmap allocation top-down by default

2019-07-29 Thread Alexandre Ghiti
In order to avoid wasting user address space by using bottom-up mmap
allocation scheme, prefer top-down scheme when possible.

Before:
root@qemuriscv64:~# cat /proc/self/maps
0001-00016000 r-xp  fe:00 6389   /bin/cat.coreutils
00016000-00017000 r--p 5000 fe:00 6389   /bin/cat.coreutils
00017000-00018000 rw-p 6000 fe:00 6389   /bin/cat.coreutils
00018000-00039000 rw-p  00:00 0  [heap]
156000-16d000 r-xp  fe:00 7193   /lib/ld-2.28.so
16d000-16e000 r--p 00016000 fe:00 7193   /lib/ld-2.28.so
16e000-16f000 rw-p 00017000 fe:00 7193   /lib/ld-2.28.so
16f000-17 rw-p  00:00 0
17-172000 r-xp  00:00 0  [vdso]
174000-176000 rw-p  00:00 0
176000-1555674000 r-xp  fe:00 7187   /lib/libc-2.28.so
1555674000-1555678000 r--p 000fd000 fe:00 7187   /lib/libc-2.28.so
1555678000-155567a000 rw-p 00101000 fe:00 7187   /lib/libc-2.28.so
155567a000-15556a rw-p  00:00 0
3fffb9-3fffbb1000 rw-p  00:00 0  [stack]

After:
root@qemuriscv64:~# cat /proc/self/maps
0001-00016000 r-xp  fe:00 6389   /bin/cat.coreutils
00016000-00017000 r--p 5000 fe:00 6389   /bin/cat.coreutils
00017000-00018000 rw-p 6000 fe:00 6389   /bin/cat.coreutils
2de81000-2dea2000 rw-p  00:00 0  [heap]
3ff7eb6000-3ff7ed8000 rw-p  00:00 0
3ff7ed8000-3ff7fd6000 r-xp  fe:00 7187   /lib/libc-2.28.so
3ff7fd6000-3ff7fda000 r--p 000fd000 fe:00 7187   /lib/libc-2.28.so
3ff7fda000-3ff7fdc000 rw-p 00101000 fe:00 7187   /lib/libc-2.28.so
3ff7fdc000-3ff7fe2000 rw-p  00:00 0
3ff7fe4000-3ff7fe6000 r-xp  00:00 0  [vdso]
3ff7fe6000-3ff7ffd000 r-xp  fe:00 7193   /lib/ld-2.28.so
3ff7ffd000-3ff7ffe000 r--p 00016000 fe:00 7193   /lib/ld-2.28.so
3ff7ffe000-3ff7fff000 rw-p 00017000 fe:00 7193   /lib/ld-2.28.so
3ff7fff000-3ff800 rw-p  00:00 0
3fff888000-3fff8a9000 rw-p  00:00 0  [stack]

Signed-off-by: Alexandre Ghiti 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Kees Cook 
Reviewed-by: Luis Chamberlain 
---
 arch/riscv/Kconfig | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 8ef64fe2c2b3..8d0d8af1a744 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -54,6 +54,19 @@ config RISCV
select EDAC_SUPPORT
select ARCH_HAS_GIGANTIC_PAGE
select ARCH_WANT_HUGE_PMD_SHARE if 64BIT
+   select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
+   select HAVE_ARCH_MMAP_RND_BITS
+
+config ARCH_MMAP_RND_BITS_MIN
+   default 18 if 64BIT
+   default 8
+
+# max bits determined by the following formula:
+#  VA_BITS - PAGE_SHIFT - 3
+config ARCH_MMAP_RND_BITS_MAX
+   default 33 if RISCV_VM_SV48
+   default 24 if RISCV_VM_SV39
+   default 17 if RISCV_VM_SV32
 
 config MMU
def_bool y
-- 
2.20.1



[PATCH v5 13/14] mips: Use generic mmap top-down layout and brk randomization

2019-07-29 Thread Alexandre Ghiti
mips uses a top-down layout by default that exactly fits the generic
functions, so get rid of arch specific code and use the generic version
by selecting ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT.
As ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT selects ARCH_HAS_ELF_RANDOMIZE,
use the generic version of arch_randomize_brk since it also fits.
Note that this commit also removes the possibility for mips to have elf
randomization and no MMU: without MMU, the security added by randomization
is worth nothing.

Signed-off-by: Alexandre Ghiti 
Acked-by: Paul Burton 
Reviewed-by: Kees Cook 
Reviewed-by: Luis Chamberlain 
---
 arch/mips/Kconfig |  2 +-
 arch/mips/include/asm/processor.h |  5 --
 arch/mips/mm/mmap.c   | 96 ---
 3 files changed, 1 insertion(+), 102 deletions(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index d50fafd7bf3a..4e85d7d2cf1a 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -5,7 +5,6 @@ config MIPS
select ARCH_32BIT_OFF_T if !64BIT
select ARCH_BINFMT_ELF_STATE if MIPS_FP_SUPPORT
select ARCH_CLOCKSOURCE_DATA
-   select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAS_UBSAN_SANITIZE_ALL
select ARCH_SUPPORTS_UPROBES
@@ -13,6 +12,7 @@ config MIPS
select ARCH_USE_CMPXCHG_LOCKREF if 64BIT
select ARCH_USE_QUEUED_RWLOCKS
select ARCH_USE_QUEUED_SPINLOCKS
+   select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
select ARCH_WANT_IPC_PARSE_VERSION
select BUILDTIME_EXTABLE_SORT
select CLONE_BACKWARDS
diff --git a/arch/mips/include/asm/processor.h 
b/arch/mips/include/asm/processor.h
index aca909bd7841..fba18d4a9190 100644
--- a/arch/mips/include/asm/processor.h
+++ b/arch/mips/include/asm/processor.h
@@ -29,11 +29,6 @@
 
 extern unsigned int vced_count, vcei_count;
 
-/*
- * MIPS does have an arch_pick_mmap_layout()
- */
-#define HAVE_ARCH_PICK_MMAP_LAYOUT 1
-
 #ifdef CONFIG_32BIT
 #ifdef CONFIG_KVM_GUEST
 /* User space process size is limited to 1GB in KVM Guest Mode */
diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
index d5106c26ac6a..00fe90c6db3e 100644
--- a/arch/mips/mm/mmap.c
+++ b/arch/mips/mm/mmap.c
@@ -16,49 +16,10 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 
 unsigned long shm_align_mask = PAGE_SIZE - 1;  /* Sane caches */
 EXPORT_SYMBOL(shm_align_mask);
 
-/* gap between mmap and stack */
-#define MIN_GAP(128*1024*1024UL)
-#define MAX_GAP((STACK_TOP)/6*5)
-#define STACK_RND_MASK (0x7ff >> (PAGE_SHIFT - 12))
-
-static int mmap_is_legacy(struct rlimit *rlim_stack)
-{
-   if (current->personality & ADDR_COMPAT_LAYOUT)
-   return 1;
-
-   if (rlim_stack->rlim_cur == RLIM_INFINITY)
-   return 1;
-
-   return sysctl_legacy_va_layout;
-}
-
-static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack)
-{
-   unsigned long gap = rlim_stack->rlim_cur;
-   unsigned long pad = stack_guard_gap;
-
-   /* Account for stack randomization if necessary */
-   if (current->flags & PF_RANDOMIZE)
-   pad += (STACK_RND_MASK << PAGE_SHIFT);
-
-   /* Values close to RLIM_INFINITY can overflow. */
-   if (gap + pad > gap)
-   gap += pad;
-
-   if (gap < MIN_GAP)
-   gap = MIN_GAP;
-   else if (gap > MAX_GAP)
-   gap = MAX_GAP;
-
-   return PAGE_ALIGN(STACK_TOP - gap - rnd);
-}
-
 #define COLOUR_ALIGN(addr, pgoff)  \
addr) + shm_align_mask) & ~shm_align_mask) +\
 (((pgoff) << PAGE_SHIFT) & shm_align_mask))
@@ -156,63 +117,6 @@ unsigned long arch_get_unmapped_area_topdown(struct file 
*filp,
addr0, len, pgoff, flags, DOWN);
 }
 
-unsigned long arch_mmap_rnd(void)
-{
-   unsigned long rnd;
-
-#ifdef CONFIG_COMPAT
-   if (TASK_IS_32BIT_ADDR)
-   rnd = get_random_long() & ((1UL << mmap_rnd_compat_bits) - 1);
-   else
-#endif /* CONFIG_COMPAT */
-   rnd = get_random_long() & ((1UL << mmap_rnd_bits) - 1);
-
-   return rnd << PAGE_SHIFT;
-}
-
-void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack)
-{
-   unsigned long random_factor = 0UL;
-
-   if (current->flags & PF_RANDOMIZE)
-   random_factor = arch_mmap_rnd();
-
-   if (mmap_is_legacy(rlim_stack)) {
-   mm->mmap_base = TASK_UNMAPPED_BASE + random_factor;
-   mm->get_unmapped_area = arch_get_unmapped_area;
-   } else {
-   mm->mmap_base = mmap_base(random_factor, rlim_stack);
-   mm->get_unmapped_area = arch_get_unmapped_area_topdown;
-   }
-}
-
-static inline unsigned long brk_rnd(void)
-{
-   unsigned long rnd = get_random_long();
-
-   rnd = rnd << PAGE_SHIFT;
-   /* 32MB for 32bit, 1GB for 64bit */
-   if (!IS_ENABLED(CONFIG_64BIT) |

[PATCH v5 12/14] mips: Replace arch specific way to determine 32bit task with generic version

2019-07-29 Thread Alexandre Ghiti
Mips uses TASK_IS_32BIT_ADDR to determine if a task is 32bit, but
this define is mips specific and other arches do not have it: instead,
use !IS_ENABLED(CONFIG_64BIT) || is_compat_task() condition.

Signed-off-by: Alexandre Ghiti 
Acked-by: Paul Burton 
Reviewed-by: Kees Cook 
Reviewed-by: Luis Chamberlain 
---
 arch/mips/mm/mmap.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
index ff6ab87e9c56..d5106c26ac6a 100644
--- a/arch/mips/mm/mmap.c
+++ b/arch/mips/mm/mmap.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 unsigned long shm_align_mask = PAGE_SIZE - 1;  /* Sane caches */
 EXPORT_SYMBOL(shm_align_mask);
@@ -191,7 +192,7 @@ static inline unsigned long brk_rnd(void)
 
rnd = rnd << PAGE_SHIFT;
/* 32MB for 32bit, 1GB for 64bit */
-   if (TASK_IS_32BIT_ADDR)
+   if (!IS_ENABLED(CONFIG_64BIT) || is_compat_task())
rnd = rnd & (SZ_32M - 1);
else
rnd = rnd & (SZ_1G - 1);
-- 
2.20.1



Re: [Xen-devel] [PATCH v4 8/9] xen/gntdev.c: Convert to use vm_map_pages()

2019-07-29 Thread Souptick Joarder
On Mon, Jul 29, 2019 at 7:06 PM Marek Marczykowski-Górecki
 wrote:
>
> On Mon, Jul 29, 2019 at 02:02:54PM +0530, Souptick Joarder wrote:
> > On Mon, Jul 29, 2019 at 1:35 PM Souptick Joarder  
> > wrote:
> > >
> > > On Sun, Jul 28, 2019 at 11:36 PM Marek Marczykowski-Górecki
> > >  wrote:
> > > >
> > > > On Fri, Feb 15, 2019 at 08:18:31AM +0530, Souptick Joarder wrote:
> > > > > Convert to use vm_map_pages() to map range of kernel
> > > > > memory to user vma.
> > > > >
> > > > > map->count is passed to vm_map_pages() and internal API
> > > > > verify map->count against count ( count = vma_pages(vma))
> > > > > for page array boundary overrun condition.
> > > >
> > > > This commit breaks gntdev driver. If vma->vm_pgoff > 0, vm_map_pages
> > > > will:
> > > >  - use map->pages starting at vma->vm_pgoff instead of 0
> > >
> > > The actual code ignores vma->vm_pgoff > 0 scenario and mapped
> > > the entire map->pages[i]. Why the entire map->pages[i] needs to be mapped
> > > if vma->vm_pgoff > 0 (in original code) ?
>
> vma->vm_pgoff is used as index passed to gntdev_find_map_index. It's
> basically (ab)using this parameter for "which grant reference to map".
>
> > > are you referring to set vma->vm_pgoff = 0 irrespective of value passed
> > > from user space ? If yes, using vm_map_pages_zero() is an alternate
> > > option.
>
> Yes, that should work.

I prefer to use vm_map_pages_zero() to resolve both the issues. Alternatively
the patch can be reverted as you suggested. Let me know you opinion and wait
for feedback from others.

Boris, would you like to give any feedback ?

>
> > > >  - verify map->count against vma_pages()+vma->vm_pgoff instead of just
> > > >vma_pages().
> > >
> > > In original code ->
> > >
> > > diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> > > index 559d4b7f807d..469dfbd6cf90 100644
> > > --- a/drivers/xen/gntdev.c
> > > +++ b/drivers/xen/gntdev.c
> > > @@ -1084,7 +1084,7 @@ static int gntdev_mmap(struct file *flip, struct
> > > vm_area_struct *vma)
> > > int index = vma->vm_pgoff;
> > > int count = vma_pages(vma);
> > >
> > > Count is user passed value.
> > >
> > > struct gntdev_grant_map *map;
> > > - int i, err = -EINVAL;
> > > + int err = -EINVAL;
> > > if ((vma->vm_flags & VM_WRITE) && !(vma->vm_flags & VM_SHARED))
> > > return -EINVAL;
> > > @@ -1145,12 +1145,9 @@ static int gntdev_mmap(struct file *flip,
> > > struct vm_area_struct *vma)
> > > goto out_put_map;
> > > if (!use_ptemod) {
> > > - for (i = 0; i < count; i++) {
> > > - err = vm_insert_page(vma, vma->vm_start + i*PAGE_SIZE,
> > > - map->pages[i]);
> > >
> > > and when count > i , we end up with trying to map memory outside
> > > boundary of map->pages[i], which was not correct.
> >
> > typo.
> > s/count > i / count > map->count
>
> gntdev_find_map_index verifies it. Specifically, it looks for a map matching
> both index and count.
>
> > >
> > > - if (err)
> > > - goto out_put_map;
> > > - }
> > > + err = vm_map_pages(vma, map->pages, map->count);
> > > + if (err)
> > > + goto out_put_map;
> > >
> > > With this commit, inside __vm_map_pages(), we have addressed this 
> > > scenario.
> > >
> > > +static int __vm_map_pages(struct vm_area_struct *vma, struct page 
> > > **pages,
> > > + unsigned long num, unsigned long offset)
> > > +{
> > > + unsigned long count = vma_pages(vma);
> > > + unsigned long uaddr = vma->vm_start;
> > > + int ret, i;
> > > +
> > > + /* Fail if the user requested offset is beyond the end of the object */
> > > + if (offset > num)
> > > + return -ENXIO;
> > > +
> > > + /* Fail if the user requested size exceeds available object size */
> > > + if (count > num - offset)
> > > + return -ENXIO;
> > >
> > > By checking count > num -offset. (considering vma->vm_pgoff != 0 as well).
> > > So we will never cross the boundary of map->pages[i].
> > >
> > >
> > > >
> > > > In practice, this breaks using a single gntdev FD for mapping multiple
> > > > grants.
> > >
> > > How ?
>
> gntdev uses vma->vm_pgoff to select which grant entry should be mapped.
> map struct returned by gntdev_find_map_index() describes just the pages
> to be mapped. Specifically map->pages[0] should be mapped at
> vma->vm_start, not vma->vm_start+vma->vm_pgoff*PAGE_SIZE.
>
> When trying to map grant with index (aka vma->vm_pgoff) > 1,
> __vm_map_pages() will refuse to map it because it will expect map->count
> to be at least vma_pages(vma)+vma->vm_pgoff, while it is exactly
> vma_pages(vma).
>
> > > > It looks like vm_map_pages() is not a good fit for this code and IMO it
> > > > should be reverted.
> > >
> > > Did you hit any issue around this code in real time ?
>
> Yes, relevant strace output:
> [pid   857] ioctl(7, IOCTL_GNTDEV_MAP_GRANT_REF, 0x7ffd3407b6d0) = 0
> [pid   857] mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 7, 0) = 
> 0x777f1211b000
> [pid   857] ioctl(7, IOCTL_GNTDEV_SET_UNMAP_NOTIFY, 0x7ffd3407b710) = 0
> [pid   857] ioctl(7, IOCTL_GNTDEV_MAP_GRANT_REF, 0x7ffd3407b6d0) = 0
> [pid   857] mmap(NUL

[PATCH v5 11/14] mips: Adjust brk randomization offset to fit generic version

2019-07-29 Thread Alexandre Ghiti
This commit simply bumps up to 32MB and 1GB the random offset
of brk, compared to 8MB and 256MB, for 32bit and 64bit respectively.

Suggested-by: Kees Cook 
Signed-off-by: Alexandre Ghiti 
Acked-by: Paul Burton 
Reviewed-by: Kees Cook 
Reviewed-by: Luis Chamberlain 
---
 arch/mips/mm/mmap.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
index a7e84b2e71d7..ff6ab87e9c56 100644
--- a/arch/mips/mm/mmap.c
+++ b/arch/mips/mm/mmap.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 unsigned long shm_align_mask = PAGE_SIZE - 1;  /* Sane caches */
 EXPORT_SYMBOL(shm_align_mask);
@@ -189,11 +190,11 @@ static inline unsigned long brk_rnd(void)
unsigned long rnd = get_random_long();
 
rnd = rnd << PAGE_SHIFT;
-   /* 8MB for 32bit, 256MB for 64bit */
+   /* 32MB for 32bit, 1GB for 64bit */
if (TASK_IS_32BIT_ADDR)
-   rnd = rnd & 0x7ful;
+   rnd = rnd & (SZ_32M - 1);
else
-   rnd = rnd & 0xffful;
+   rnd = rnd & (SZ_1G - 1);
 
return rnd;
 }
-- 
2.20.1



[PATCH v5 10/14] mips: Use STACK_TOP when computing mmap base address

2019-07-29 Thread Alexandre Ghiti
mmap base address must be computed wrt stack top address, using TASK_SIZE
is wrong since STACK_TOP and TASK_SIZE are not equivalent.

Signed-off-by: Alexandre Ghiti 
Acked-by: Kees Cook 
Acked-by: Paul Burton 
Reviewed-by: Luis Chamberlain 
---
 arch/mips/mm/mmap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
index f5c778113384..a7e84b2e71d7 100644
--- a/arch/mips/mm/mmap.c
+++ b/arch/mips/mm/mmap.c
@@ -22,7 +22,7 @@ EXPORT_SYMBOL(shm_align_mask);
 
 /* gap between mmap and stack */
 #define MIN_GAP(128*1024*1024UL)
-#define MAX_GAP((TASK_SIZE)/6*5)
+#define MAX_GAP((STACK_TOP)/6*5)
 #define STACK_RND_MASK (0x7ff >> (PAGE_SHIFT - 12))
 
 static int mmap_is_legacy(struct rlimit *rlim_stack)
@@ -54,7 +54,7 @@ static unsigned long mmap_base(unsigned long rnd, struct 
rlimit *rlim_stack)
else if (gap > MAX_GAP)
gap = MAX_GAP;
 
-   return PAGE_ALIGN(TASK_SIZE - gap - rnd);
+   return PAGE_ALIGN(STACK_TOP - gap - rnd);
 }
 
 #define COLOUR_ALIGN(addr, pgoff)  \
-- 
2.20.1



[PATCH v5 09/14] mips: Properly account for stack randomization and stack guard gap

2019-07-29 Thread Alexandre Ghiti
This commit takes care of stack randomization and stack guard gap when
computing mmap base address and checks if the task asked for randomization.
This fixes the problem uncovered and not fixed for arm here:
https://lkml.kernel.org/r/20170622200033.25714-1-r...@redhat.com

Signed-off-by: Alexandre Ghiti 
Acked-by: Kees Cook 
Acked-by: Paul Burton 
Reviewed-by: Luis Chamberlain 
---
 arch/mips/mm/mmap.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
index d79f2b432318..f5c778113384 100644
--- a/arch/mips/mm/mmap.c
+++ b/arch/mips/mm/mmap.c
@@ -21,8 +21,9 @@ unsigned long shm_align_mask = PAGE_SIZE - 1; /* Sane caches 
*/
 EXPORT_SYMBOL(shm_align_mask);
 
 /* gap between mmap and stack */
-#define MIN_GAP (128*1024*1024UL)
-#define MAX_GAP ((TASK_SIZE)/6*5)
+#define MIN_GAP(128*1024*1024UL)
+#define MAX_GAP((TASK_SIZE)/6*5)
+#define STACK_RND_MASK (0x7ff >> (PAGE_SHIFT - 12))
 
 static int mmap_is_legacy(struct rlimit *rlim_stack)
 {
@@ -38,6 +39,15 @@ static int mmap_is_legacy(struct rlimit *rlim_stack)
 static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack)
 {
unsigned long gap = rlim_stack->rlim_cur;
+   unsigned long pad = stack_guard_gap;
+
+   /* Account for stack randomization if necessary */
+   if (current->flags & PF_RANDOMIZE)
+   pad += (STACK_RND_MASK << PAGE_SHIFT);
+
+   /* Values close to RLIM_INFINITY can overflow. */
+   if (gap + pad > gap)
+   gap += pad;
 
if (gap < MIN_GAP)
gap = MIN_GAP;
-- 
2.20.1



Re: [PATCH net-next 1/2] net: phy: broadcom: set features explicitly for BCM54616S

2019-07-29 Thread Heiner Kallweit
On 30.07.2019 07:05, Tao Ren wrote:
> On 7/29/19 8:35 PM, Andrew Lunn wrote:
>> On Mon, Jul 29, 2019 at 05:25:32PM -0700, Tao Ren wrote:
>>> BCM54616S feature "PHY_GBIT_FEATURES" was removed by commit dcdecdcfe1fc
>>> ("net: phy: switch drivers to use dynamic feature detection"). As dynamic
>>> feature detection doesn't work when BCM54616S is working in RGMII-Fiber
>>> mode (different sets of MII Control/Status registers being used), let's
>>> set "PHY_GBIT_FEATURES" for BCM54616S explicitly.
>>
>> Hi Tao
>>
>> What exactly does it get wrong?
>>
>>  Thanks
>>  Andrew
> 
> Hi Andrew,
> 
> BCM54616S is set to RGMII-Fiber (1000Base-X) mode on my platform, and none of 
> the features (1000BaseT/100BaseT/10BaseT) can be detected by 
> genphy_read_abilities(), because the PHY only reports 1000BaseX_Full|Half 
> ability in this mode.
> 
Are you going to use the PHY in copper or fibre mode?
In case you use fibre mode, why do you need the copper modes set as supported?
Or does the PHY just start in fibre mode and you want to switch it to copper 
mode?

> 
> Thanks,
> 
> Tao
> 
Heiner


[PATCH v5 08/14] arm: Use generic mmap top-down layout and brk randomization

2019-07-29 Thread Alexandre Ghiti
arm uses a top-down mmap layout by default that exactly fits the generic
functions, so get rid of arch specific code and use the generic version
by selecting ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT.
As ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT selects ARCH_HAS_ELF_RANDOMIZE,
use the generic version of arch_randomize_brk since it also fits.
Note that this commit also removes the possibility for arm to have elf
randomization and no MMU: without MMU, the security added by randomization
is worth nothing.
Note that it is safe to remove STACK_RND_MASK since it matches the default
value.

Signed-off-by: Alexandre Ghiti 
Acked-by: Kees Cook 
Reviewed-by: Luis Chamberlain 
---
 arch/arm/Kconfig |  2 +-
 arch/arm/include/asm/processor.h |  2 --
 arch/arm/kernel/process.c|  5 ---
 arch/arm/mm/mmap.c   | 62 
 4 files changed, 1 insertion(+), 70 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 33b00579beff..81b08b027e4e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -7,7 +7,6 @@ config ARM
select ARCH_HAS_BINFMT_FLAT
select ARCH_HAS_DEBUG_VIRTUAL if MMU
select ARCH_HAS_DEVMEM_IS_ALLOWED
-   select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_KEEPINITRD
select ARCH_HAS_KCOV
@@ -30,6 +29,7 @@ config ARM
select ARCH_SUPPORTS_ATOMIC_RMW
select ARCH_USE_BUILTIN_BSWAP
select ARCH_USE_CMPXCHG_LOCKREF
+   select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
select ARCH_WANT_IPC_PARSE_VERSION
select BINFMT_FLAT_ARGVP_ENVP_ON_STACK
select BUILDTIME_EXTABLE_SORT if MMU
diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
index 20c2f42454b8..614bf829e454 100644
--- a/arch/arm/include/asm/processor.h
+++ b/arch/arm/include/asm/processor.h
@@ -140,8 +140,6 @@ static inline void prefetchw(const void *ptr)
 #endif
 #endif
 
-#define HAVE_ARCH_PICK_MMAP_LAYOUT
-
 #endif
 
 #endif /* __ASM_ARM_PROCESSOR_H */
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index f934a6739fc0..9485acc520a4 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -319,11 +319,6 @@ unsigned long get_wchan(struct task_struct *p)
return 0;
 }
 
-unsigned long arch_randomize_brk(struct mm_struct *mm)
-{
-   return randomize_page(mm->brk, 0x0200);
-}
-
 #ifdef CONFIG_MMU
 #ifdef CONFIG_KUSER_HELPERS
 /*
diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
index 0b94b674aa91..b8d912ac9e61 100644
--- a/arch/arm/mm/mmap.c
+++ b/arch/arm/mm/mmap.c
@@ -17,43 +17,6 @@
addr)+SHMLBA-1)&~(SHMLBA-1)) +  \
 (((pgoff)<> (PAGE_SHIFT - 12))
-
-static int mmap_is_legacy(struct rlimit *rlim_stack)
-{
-   if (current->personality & ADDR_COMPAT_LAYOUT)
-   return 1;
-
-   if (rlim_stack->rlim_cur == RLIM_INFINITY)
-   return 1;
-
-   return sysctl_legacy_va_layout;
-}
-
-static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack)
-{
-   unsigned long gap = rlim_stack->rlim_cur;
-   unsigned long pad = stack_guard_gap;
-
-   /* Account for stack randomization if necessary */
-   if (current->flags & PF_RANDOMIZE)
-   pad += (STACK_RND_MASK << PAGE_SHIFT);
-
-   /* Values close to RLIM_INFINITY can overflow. */
-   if (gap + pad > gap)
-   gap += pad;
-
-   if (gap < MIN_GAP)
-   gap = MIN_GAP;
-   else if (gap > MAX_GAP)
-   gap = MAX_GAP;
-
-   return PAGE_ALIGN(STACK_TOP - gap - rnd);
-}
-
 /*
  * We need to ensure that shared mappings are correctly aligned to
  * avoid aliasing issues with VIPT caches.  We need to ensure that
@@ -181,31 +144,6 @@ arch_get_unmapped_area_topdown(struct file *filp, const 
unsigned long addr0,
return addr;
 }
 
-unsigned long arch_mmap_rnd(void)
-{
-   unsigned long rnd;
-
-   rnd = get_random_long() & ((1UL << mmap_rnd_bits) - 1);
-
-   return rnd << PAGE_SHIFT;
-}
-
-void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack)
-{
-   unsigned long random_factor = 0UL;
-
-   if (current->flags & PF_RANDOMIZE)
-   random_factor = arch_mmap_rnd();
-
-   if (mmap_is_legacy(rlim_stack)) {
-   mm->mmap_base = TASK_UNMAPPED_BASE + random_factor;
-   mm->get_unmapped_area = arch_get_unmapped_area;
-   } else {
-   mm->mmap_base = mmap_base(random_factor, rlim_stack);
-   mm->get_unmapped_area = arch_get_unmapped_area_topdown;
-   }
-}
-
 /*
  * You really shouldn't be using read() or write() on /dev/mem.  This
  * might go away in the future.
-- 
2.20.1



[PATCH] ARM: dts: aspeed: Add Mihawk BMC platform

2019-07-29 Thread Ben Pai
The Mihawk BMC is an ASPEED ast2500 based BMC that is part of an
OpenPower Power9 server.

This adds the device tree description for most upstream components. It
is a squashed commit from the OpenBMC kernel tree.

Signed-off-by: Ben Pai 
---
 arch/arm/boot/dts/Makefile  |   1 +
 arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts | 922 
 2 files changed, 923 insertions(+)
 create mode 100755 arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index eb6de52c1936..262345544359 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1281,5 +1281,6 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
aspeed-bmc-opp-vesnin.dtb \
aspeed-bmc-opp-witherspoon.dtb \
aspeed-bmc-opp-zaius.dtb \
+   aspeed-bmc-opp-mihawk.dtb \
aspeed-bmc-portwell-neptune.dtb \
aspeed-bmc-quanta-q71l.dtb
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts 
b/arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts
new file mode 100755
index ..cfa20e0b2939
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts
@@ -0,0 +1,922 @@
+/dts-v1/;
+
+#include "aspeed-g5.dtsi"
+#include 
+#include 
+
+/ {
+   model = "Mihawk BMC";
+   compatible = "ibm,mihawk-bmc", "aspeed,ast2500";
+
+
+   chosen {
+   stdout-path = &uart5;
+   bootargs = "console=ttyS4,115200 earlyprintk";
+   };
+
+   memory@8000 {
+   reg = <0x8000 0x2000>; /* address and size of 
RAM(512MB) */
+   };
+
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   flash_memory: region@9800 {
+   no-map;
+   reg = <0x9800 0x0400>; /* 64M */
+   };
+
+   gfx_memory: framebuffer {
+   size = <0x0100>;
+   alignment = <0x0100>;
+   compatible = "shared-dma-pool";
+   reusable;
+   };
+
+   video_engine_memory: jpegbuffer {
+   size = <0x0200>;/* 32MM */
+   alignment = <0x0100>;
+   compatible = "shared-dma-pool";
+   reusable;
+   };
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+
+   air-water {
+   label = "air-water";
+   gpios = <&gpio ASPEED_GPIO(F, 6) GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+
+   checkstop {
+   label = "checkstop";
+   gpios = <&gpio ASPEED_GPIO(J, 2) GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+
+   ps0-presence {
+   label = "ps0-presence";
+   gpios = <&gpio ASPEED_GPIO(Z, 2) GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+
+   ps1-presence {
+   label = "ps1-presence";
+   gpios = <&gpio ASPEED_GPIO(Z, 0) GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+   id-button {
+   label = "id-button";
+   gpios = <&gpio ASPEED_GPIO(F, 1) GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+   };
+
+   gpio-keys-polled {
+   compatible = "gpio-keys-polled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   poll-interval = <1000>;
+
+   fan0-presence {
+   label = "fan0-presence";
+   gpios = <&pca9552 9 GPIO_ACTIVE_LOW>;
+   linux,code = <9>;
+   };
+
+   fan1-presence {
+   label = "fan1-presence";
+   gpios = <&pca9552 10 GPIO_ACTIVE_LOW>;
+   linux,code = <10>;
+   };
+
+   fan2-presence {
+   label = "fan2-presence";
+   gpios = <&pca9552 11 GPIO_ACTIVE_LOW>;
+   linux,code = <11>;
+   };
+
+   fan3-presence {
+   label = "fan3-presence";
+   gpios = <&pca9552 12 GPIO_ACTIVE_LOW>;
+   linux,code = <12>;
+   };
+
+   fan4-presence {
+   label = "fan4-presence";
+   gpios = <&pca9552 13 GPIO_ACTIVE_LOW>;
+   linux,code = <13>;
+   };
+
+   fan5-presence {
+   label = "fan5-presence";
+   gpios = <&pca9552 14 GPIO_ACTIVE_LOW>;
+   linux,code = <14>;
+   };
+   };
+
+   leds {
+  

[PATCH v5 07/14] arm: Use STACK_TOP when computing mmap base address

2019-07-29 Thread Alexandre Ghiti
mmap base address must be computed wrt stack top address, using TASK_SIZE
is wrong since STACK_TOP and TASK_SIZE are not equivalent.

Signed-off-by: Alexandre Ghiti 
Acked-by: Kees Cook 
Reviewed-by: Luis Chamberlain 
---
 arch/arm/mm/mmap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
index bff3d00bda5b..0b94b674aa91 100644
--- a/arch/arm/mm/mmap.c
+++ b/arch/arm/mm/mmap.c
@@ -19,7 +19,7 @@
 
 /* gap between mmap and stack */
 #define MIN_GAP(128*1024*1024UL)
-#define MAX_GAP((TASK_SIZE)/6*5)
+#define MAX_GAP((STACK_TOP)/6*5)
 #define STACK_RND_MASK (0x7ff >> (PAGE_SHIFT - 12))
 
 static int mmap_is_legacy(struct rlimit *rlim_stack)
@@ -51,7 +51,7 @@ static unsigned long mmap_base(unsigned long rnd, struct 
rlimit *rlim_stack)
else if (gap > MAX_GAP)
gap = MAX_GAP;
 
-   return PAGE_ALIGN(TASK_SIZE - gap - rnd);
+   return PAGE_ALIGN(STACK_TOP - gap - rnd);
 }
 
 /*
-- 
2.20.1



[PATCH v5 06/14] arm: Properly account for stack randomization and stack guard gap

2019-07-29 Thread Alexandre Ghiti
This commit takes care of stack randomization and stack guard gap when
computing mmap base address and checks if the task asked for randomization.
This fixes the problem uncovered and not fixed for arm here:
https://lkml.kernel.org/r/20170622200033.25714-1-r...@redhat.com

Signed-off-by: Alexandre Ghiti 
Acked-by: Kees Cook 
Reviewed-by: Luis Chamberlain 
---
 arch/arm/mm/mmap.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
index f866870db749..bff3d00bda5b 100644
--- a/arch/arm/mm/mmap.c
+++ b/arch/arm/mm/mmap.c
@@ -18,8 +18,9 @@
 (((pgoff)<> (PAGE_SHIFT - 12))
 
 static int mmap_is_legacy(struct rlimit *rlim_stack)
 {
@@ -35,6 +36,15 @@ static int mmap_is_legacy(struct rlimit *rlim_stack)
 static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack)
 {
unsigned long gap = rlim_stack->rlim_cur;
+   unsigned long pad = stack_guard_gap;
+
+   /* Account for stack randomization if necessary */
+   if (current->flags & PF_RANDOMIZE)
+   pad += (STACK_RND_MASK << PAGE_SHIFT);
+
+   /* Values close to RLIM_INFINITY can overflow. */
+   if (gap + pad > gap)
+   gap += pad;
 
if (gap < MIN_GAP)
gap = MIN_GAP;
-- 
2.20.1



[PATCH v5 05/14] arm64, mm: Make randomization selected by generic topdown mmap layout

2019-07-29 Thread Alexandre Ghiti
This commits selects ARCH_HAS_ELF_RANDOMIZE when an arch uses the generic
topdown mmap layout functions so that this security feature is on by
default.
Note that this commit also removes the possibility for arm64 to have elf
randomization and no MMU: without MMU, the security added by randomization
is worth nothing.

Signed-off-by: Alexandre Ghiti 
Acked-by: Catalin Marinas 
Acked-by: Kees Cook 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Luis Chamberlain 
---
 arch/Kconfig|  1 +
 arch/arm64/Kconfig  |  1 -
 arch/arm64/kernel/process.c |  8 
 mm/util.c   | 11 +--
 4 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index a0bb6fa4d381..d4c1f0551dfe 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -705,6 +705,7 @@ config HAVE_ARCH_COMPAT_MMAP_BASES
 config ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
bool
depends on MMU
+   select ARCH_HAS_ELF_RANDOMIZE
 
 config HAVE_COPY_THREAD_TLS
bool
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 14a194e63458..399f595ef852 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -16,7 +16,6 @@ config ARM64
select ARCH_HAS_DMA_MMAP_PGPROT
select ARCH_HAS_DMA_PREP_COHERENT
select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
-   select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FAST_MULTIPLIER
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_GCOV_PROFILE_ALL
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index f674f28df663..8ddc2471b054 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -548,14 +548,6 @@ unsigned long arch_align_stack(unsigned long sp)
return sp & ~0xf;
 }
 
-unsigned long arch_randomize_brk(struct mm_struct *mm)
-{
-   if (is_compat_task())
-   return randomize_page(mm->brk, SZ_32M);
-   else
-   return randomize_page(mm->brk, SZ_1G);
-}
-
 /*
  * Called from setup_new_exec() after (COMPAT_)SET_PERSONALITY.
  */
diff --git a/mm/util.c b/mm/util.c
index 0781e5575cb3..16f1e56e2996 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -321,7 +321,15 @@ unsigned long randomize_stack_top(unsigned long stack_top)
 }
 
 #ifdef CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
-#ifdef CONFIG_ARCH_HAS_ELF_RANDOMIZE
+unsigned long arch_randomize_brk(struct mm_struct *mm)
+{
+   /* Is the current task 32bit ? */
+   if (!IS_ENABLED(CONFIG_64BIT) || is_compat_task())
+   return randomize_page(mm->brk, SZ_32M);
+
+   return randomize_page(mm->brk, SZ_1G);
+}
+
 unsigned long arch_mmap_rnd(void)
 {
unsigned long rnd;
@@ -335,7 +343,6 @@ unsigned long arch_mmap_rnd(void)
 
return rnd << PAGE_SHIFT;
 }
-#endif /* CONFIG_ARCH_HAS_ELF_RANDOMIZE */
 
 static int mmap_is_legacy(struct rlimit *rlim_stack)
 {
-- 
2.20.1



[PATCH v5 04/14] arm64, mm: Move generic mmap layout functions to mm

2019-07-29 Thread Alexandre Ghiti
arm64 handles top-down mmap layout in a way that can be easily reused
by other architectures, so make it available in mm.
It then introduces a new config ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
that can be set by other architectures to benefit from those functions.
Note that this new config depends on MMU being enabled, if selected
without MMU support, a warning will be thrown.

Suggested-by: Christoph Hellwig 
Signed-off-by: Alexandre Ghiti 
Acked-by: Catalin Marinas 
Acked-by: Kees Cook 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Luis Chamberlain 
---
 arch/Kconfig   | 10 
 arch/arm64/Kconfig |  1 +
 arch/arm64/include/asm/processor.h |  2 -
 arch/arm64/mm/mmap.c   | 76 -
 kernel/sysctl.c|  6 ++-
 mm/util.c  | 78 +-
 6 files changed, 92 insertions(+), 81 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index a7b57dd42c26..a0bb6fa4d381 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -696,6 +696,16 @@ config HAVE_ARCH_COMPAT_MMAP_BASES
  and vice-versa 32-bit applications to call 64-bit mmap().
  Required for applications doing different bitness syscalls.
 
+# This allows to use a set of generic functions to determine mmap base
+# address by giving priority to top-down scheme only if the process
+# is not in legacy mode (compat task, unlimited stack size or
+# sysctl_legacy_va_layout).
+# Architecture that selects this option can provide its own version of:
+# - STACK_RND_MASK
+config ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
+   bool
+   depends on MMU
+
 config HAVE_COPY_THREAD_TLS
bool
help
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 3adcec05b1f6..14a194e63458 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -72,6 +72,7 @@ config ARM64
select ARCH_SUPPORTS_INT128 if GCC_VERSION >= 5 || CC_IS_CLANG
select ARCH_SUPPORTS_NUMA_BALANCING
select ARCH_WANT_COMPAT_IPC_PARSE_VERSION if COMPAT
+   select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
select ARCH_WANT_FRAME_POINTERS
select ARCH_WANT_HUGE_PMD_SHARE if ARM64_4K_PAGES || (ARM64_16K_PAGES 
&& !ARM64_VA_BITS_36)
select ARCH_HAS_UBSAN_SANITIZE_ALL
diff --git a/arch/arm64/include/asm/processor.h 
b/arch/arm64/include/asm/processor.h
index 844e2964b0f5..65e2de00913f 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -281,8 +281,6 @@ static inline void spin_lock_prefetch(const void *ptr)
 "nop") : : "p" (ptr));
 }
 
-#define HAVE_ARCH_PICK_MMAP_LAYOUT
-
 #endif
 
 extern unsigned long __ro_after_init signal_minsigstksz; /* sigframe size */
diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c
index e4acaead67de..3028bacbc4e9 100644
--- a/arch/arm64/mm/mmap.c
+++ b/arch/arm64/mm/mmap.c
@@ -20,82 +20,6 @@
 
 #include 
 
-/*
- * Leave enough space between the mmap area and the stack to honour ulimit in
- * the face of randomisation.
- */
-#define MIN_GAP (SZ_128M)
-#define MAX_GAP(STACK_TOP/6*5)
-
-static int mmap_is_legacy(struct rlimit *rlim_stack)
-{
-   if (current->personality & ADDR_COMPAT_LAYOUT)
-   return 1;
-
-   if (rlim_stack->rlim_cur == RLIM_INFINITY)
-   return 1;
-
-   return sysctl_legacy_va_layout;
-}
-
-unsigned long arch_mmap_rnd(void)
-{
-   unsigned long rnd;
-
-#ifdef CONFIG_COMPAT
-   if (is_compat_task())
-   rnd = get_random_long() & ((1UL << mmap_rnd_compat_bits) - 1);
-   else
-#endif
-   rnd = get_random_long() & ((1UL << mmap_rnd_bits) - 1);
-   return rnd << PAGE_SHIFT;
-}
-
-static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack)
-{
-   unsigned long gap = rlim_stack->rlim_cur;
-   unsigned long pad = stack_guard_gap;
-
-   /* Account for stack randomization if necessary */
-   if (current->flags & PF_RANDOMIZE)
-   pad += (STACK_RND_MASK << PAGE_SHIFT);
-
-   /* Values close to RLIM_INFINITY can overflow. */
-   if (gap + pad > gap)
-   gap += pad;
-
-   if (gap < MIN_GAP)
-   gap = MIN_GAP;
-   else if (gap > MAX_GAP)
-   gap = MAX_GAP;
-
-   return PAGE_ALIGN(STACK_TOP - gap - rnd);
-}
-
-/*
- * This function, called very early during the creation of a new process VM
- * image, sets up which VM layout function to use:
- */
-void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack)
-{
-   unsigned long random_factor = 0UL;
-
-   if (current->flags & PF_RANDOMIZE)
-   random_factor = arch_mmap_rnd();
-
-   /*
-* Fall back to the standard layout if the personality bit is set, or
-* if the expected stack growth is unlimited:
-*/
-   if (mmap_is_legacy(rlim_stack)) {
-   mm->mmap_base = TASK_UNMAPPED_BASE + random_factor;
-   m

[PATCH v5 03/14] arm64: Consider stack randomization for mmap base only when necessary

2019-07-29 Thread Alexandre Ghiti
Do not offset mmap base address because of stack randomization if
current task does not want randomization.
Note that x86 already implements this behaviour.

Signed-off-by: Alexandre Ghiti 
Acked-by: Catalin Marinas 
Acked-by: Kees Cook 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Luis Chamberlain 
---
 arch/arm64/mm/mmap.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c
index bb0140afed66..e4acaead67de 100644
--- a/arch/arm64/mm/mmap.c
+++ b/arch/arm64/mm/mmap.c
@@ -54,7 +54,11 @@ unsigned long arch_mmap_rnd(void)
 static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack)
 {
unsigned long gap = rlim_stack->rlim_cur;
-   unsigned long pad = (STACK_RND_MASK << PAGE_SHIFT) + stack_guard_gap;
+   unsigned long pad = stack_guard_gap;
+
+   /* Account for stack randomization if necessary */
+   if (current->flags & PF_RANDOMIZE)
+   pad += (STACK_RND_MASK << PAGE_SHIFT);
 
/* Values close to RLIM_INFINITY can overflow. */
if (gap + pad > gap)
-- 
2.20.1



[PATCH v5 01/14] mm, fs: Move randomize_stack_top from fs to mm

2019-07-29 Thread Alexandre Ghiti
This preparatory commit moves this function so that further introduction
of generic topdown mmap layout is contained only in mm/util.c.

Signed-off-by: Alexandre Ghiti 
Acked-by: Kees Cook 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Luis Chamberlain 
---
 fs/binfmt_elf.c| 20 
 include/linux/mm.h |  2 ++
 mm/util.c  | 22 ++
 3 files changed, 24 insertions(+), 20 deletions(-)

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index d4e11b2e04f6..cec3b4146440 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -670,26 +670,6 @@ static unsigned long load_elf_interp(struct elfhdr 
*interp_elf_ex,
  * libraries.  There is no binary dependent code anywhere else.
  */
 
-#ifndef STACK_RND_MASK
-#define STACK_RND_MASK (0x7ff >> (PAGE_SHIFT - 12))/* 8MB of VA */
-#endif
-
-static unsigned long randomize_stack_top(unsigned long stack_top)
-{
-   unsigned long random_variable = 0;
-
-   if (current->flags & PF_RANDOMIZE) {
-   random_variable = get_random_long();
-   random_variable &= STACK_RND_MASK;
-   random_variable <<= PAGE_SHIFT;
-   }
-#ifdef CONFIG_STACK_GROWSUP
-   return PAGE_ALIGN(stack_top) + random_variable;
-#else
-   return PAGE_ALIGN(stack_top) - random_variable;
-#endif
-}
-
 static int load_elf_binary(struct linux_binprm *bprm)
 {
struct file *interpreter = NULL; /* to shut gcc up */
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 0334ca97c584..ae0e5d241eb8 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2351,6 +2351,8 @@ extern int install_special_mapping(struct mm_struct *mm,
   unsigned long addr, unsigned long len,
   unsigned long flags, struct page **pages);
 
+unsigned long randomize_stack_top(unsigned long stack_top);
+
 extern unsigned long get_unmapped_area(struct file *, unsigned long, unsigned 
long, unsigned long, unsigned long);
 
 extern unsigned long mmap_region(struct file *file, unsigned long addr,
diff --git a/mm/util.c b/mm/util.c
index e6351a80f248..15a4fb0f5473 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -16,6 +16,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 
@@ -293,6 +295,26 @@ int vma_is_stack_for_current(struct vm_area_struct *vma)
return (vma->vm_start <= KSTK_ESP(t) && vma->vm_end >= KSTK_ESP(t));
 }
 
+#ifndef STACK_RND_MASK
+#define STACK_RND_MASK (0x7ff >> (PAGE_SHIFT - 12)) /* 8MB of VA */
+#endif
+
+unsigned long randomize_stack_top(unsigned long stack_top)
+{
+   unsigned long random_variable = 0;
+
+   if (current->flags & PF_RANDOMIZE) {
+   random_variable = get_random_long();
+   random_variable &= STACK_RND_MASK;
+   random_variable <<= PAGE_SHIFT;
+   }
+#ifdef CONFIG_STACK_GROWSUP
+   return PAGE_ALIGN(stack_top) + random_variable;
+#else
+   return PAGE_ALIGN(stack_top) - random_variable;
+#endif
+}
+
 #if defined(CONFIG_MMU) && !defined(HAVE_ARCH_PICK_MMAP_LAYOUT)
 void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack)
 {
-- 
2.20.1



Re: [PATCH 00/10] make "order" unsigned int

2019-07-29 Thread Pengfei Li
On Mon, Jul 29, 2019 at 4:34 PM Mel Gorman  wrote:
>
> On Sun, Jul 28, 2019 at 12:44:36AM +0800, Pengfei Li wrote:
> > On Fri, Jul 26, 2019 at 3:26 PM Mel Gorman  
> > wrote:
> > >
> >
> > Thank you for your comments.
> >
> > > On Fri, Jul 26, 2019 at 02:42:43AM +0800, Pengfei Li wrote:
> > > > Objective
> > > > 
> > > > The motivation for this series of patches is use unsigned int for
> > > > "order" in compaction.c, just like in other memory subsystems.
> > > >
> > >
> > > Why? The series is relatively subtle in parts, particularly patch 5.
> >
> > Before I sent this series of patches, I took a close look at the
> > git log for compact.c.
> >
> > Here is a short history, trouble you to look patiently.
> >
> > 1) At first, "order" is _unsigned int_
> >
> > The commit 56de7263fcf3 ("mm: compaction: direct compact when a
> > high-order allocation fails") introduced the "order" in
> > compact_control and its type is unsigned int.
> >
> > Besides, you specify that order == -1 is the flag that triggers
> > compaction via proc.
> >
>
> Yes, specifying that compaction in that context is for the entire zone
> without any specific allocation context or request.

Yes

>
> > 2) Next, because order equals -1 is special, it causes an error.
> >
> > The commit 7be62de99adc ("vmscan: kswapd carefully call compaction")
> > determines if "order" is less than 0.
> >
> > This condition is always true because the type of "order" is
> > _unsigned int_.
> >
> > -   compact_zone(zone, &cc);
> > +   if (cc->order < 0 || !compaction_deferred(zone))
> >
> > 3) Finally, in order to fix the above error, the type of the order
> > is modified to _int_
> >
> > It is done by commit: aad6ec3777bf ("mm: compaction: make
> > compact_control order signed").
> >
> > The reason I mention this is because I want to express that the
> > type of "order" is originally _unsigned int_. And "order" is
> > modified to _int_ because of the special value of -1.
> >
>
> And in itself, why does that matter?

The -1 makes order is int, which breaks the consistency of the type of order.

>
> > If the special value of "order" is not a negative number (for
> > example, -1), but a number greater than MAX_ORDER - 1 (for example,
> > MAX_ORDER), then the "order" may still be _unsigned int_ now.
> >
>
> Sure, but then you have to check that every check on order understands
> the new special value.
>

Since this check is done by is_via_compact_memory(), it is easy to modify the
special value being checked.

I have checked every check many times and now I need some reviews from
the community.

> > > There have been places where by it was important for order to be able to
> > > go negative due to loop exit conditions.
> >
> > I think that even if "cc->order" is _unsigned int_, it can be done
> > with a local temporary variable easily.
> >
> > Like this,
> >
> > function(...)
> > {
> > for(int tmp_order = cc->order; tmp_order >= 0; tmp_order--) {
> > ...
> > }
> > }
> >
>
> Yes, it can be expressed as unsigned but in itself why does that justify
> the review of a large series?

At first glance it seems that this series of patches is large. But at least
half of it is to modify the corresponding trace function. And you can see
that except patch 4 and patch 5, other patches only modify the type of
order.

Even for patch 5 with function modifications, the modified code has only
about 50 lines.

> There is limited to no performance gain
> and functionally it's equivalent.

This is just clean up. And others have done similar work before.

commit d00181b96eb8 ("mm: use 'unsigned int' for page order")
commit 7aeb09f9104b ("mm: page_alloc: use unsigned int for order in
more places")

>
> > > If there was a gain from this
> > > or it was a cleanup in the context of another major body of work, I
> > > could understand the justification but that does not appear to be the
> > > case here.
> > >
> >
> > My final conclusion:
> >
> > Why "order" is _int_ instead of unsigned int?
> >   => Because order == -1 is used as the flag.
> > => So what about making "order" greater than MAX_ORDER - 1?
> >   => The "order" can be _unsigned int_ just like in most places.
> >
> > (Can we only pick -1 as this special value?)
> >
>
> No, but the existing code did make that choice and has been debugged
> with that decision.

But this choice breaks the consistency of the order type, isn't it?

Because the check is done in is_via_compact_memory() , you don't need to
worry too much about the modification.

>
> > This series of patches makes sense because,
> >
> > 1) It guarantees that "order" remains the same type.
> >
>
> And the advantage is?

As I mentioned earlier, maintaining the consistency of the order type.

Do you really like to see such a call stack?

__alloc_pages_slowpath(unsigned int order, ...)
/* The type has changed! */
  => should_compact_retry(int order, ...)
=> compaction_zonelist_suitable(int order, ...)
  => __compaction_s

[PATCH v5 02/14] arm64: Make use of is_compat_task instead of hardcoding this test

2019-07-29 Thread Alexandre Ghiti
Each architecture has its own way to determine if a task is a compat task,
by using is_compat_task in arch_mmap_rnd, it allows more genericity and
then it prepares its moving to mm/.

Signed-off-by: Alexandre Ghiti 
Acked-by: Catalin Marinas 
Acked-by: Kees Cook 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Luis Chamberlain 
---
 arch/arm64/mm/mmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c
index b050641b5139..bb0140afed66 100644
--- a/arch/arm64/mm/mmap.c
+++ b/arch/arm64/mm/mmap.c
@@ -43,7 +43,7 @@ unsigned long arch_mmap_rnd(void)
unsigned long rnd;
 
 #ifdef CONFIG_COMPAT
-   if (test_thread_flag(TIF_32BIT))
+   if (is_compat_task())
rnd = get_random_long() & ((1UL << mmap_rnd_compat_bits) - 1);
else
 #endif
-- 
2.20.1



[PATCH 13/13] mm: allow HMM_MIRROR on all architectures with MMU

2019-07-29 Thread Christoph Hellwig
There isn't really any architecture specific code in this page table
walk implementation, so drop the dependencies.

Signed-off-by: Christoph Hellwig 
---
 mm/Kconfig | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/mm/Kconfig b/mm/Kconfig
index 56cec636a1fc..b18782be969c 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -677,8 +677,7 @@ config DEV_PAGEMAP_OPS
 
 config HMM_MIRROR
bool "HMM mirror CPU page table into a device page table"
-   depends on (X86_64 || PPC64)
-   depends on MMU && 64BIT
+   depends on MMU
select MMU_NOTIFIER
help
  Select HMM_MIRROR if you want to mirror range of the CPU page table 
of a
-- 
2.20.1



Re: [PATCH v4 0/3] Introduce Bandwidth OPPs for interconnects

2019-07-29 Thread Saravana Kannan
On Mon, Jul 29, 2019 at 10:28 PM Sibi Sankar  wrote:
>
> Hey Viresh,
>
> On 7/30/19 8:16 AM, Viresh Kumar wrote:
> > On 29-07-19, 13:16, Saravana Kannan wrote:
> >> Sibi might be working on doing that for the SDM845 CPUfreq driver.
> >> Georgi could also change his GPU driver use case to use this BW OPP
> >> table and required-opps.
> >>
> >> The problem is that people don't want to start using this until we
> >> decide on the DT representation. So it's like a chicken and egg
> >> situation.
> >
> > Yeah, I agree to that.
> >
> > @Georgi and @Sibi: This is your chance to speak up about the proposal
> > from Saravana and if you find anything wrong with them. And specially
> > that it is mostly about interconnects here, I would like to have an
> > explicit Ack from Georgi on this.
> >
> > And if you guys are all okay about this then please at least commit
> > that you will convert your stuff based on this in coming days.
>
> I've been using both Saravana's and Georgi's series for a while
> now to scale DDR and L3 on SDM845. There is currently no consensus
> as to where the votes are to be actuated from, hence couldn't post
> anything out.
>
> DCVS based on Saravana's series + passive governor:
> https://github.com/QuinAsura/linux/tree/lnext-072619-SK-series

Thanks Sibi! You might want to convert your patches so that until the
passive governor is ready, you just look up the required opps and vote
for BW directly from the cpufreq driver. Once devfreq governor is
ready, you can switch to it.

-Saravana

>
> DCVS based on Georgi's series: (I had already posted this out)
> https://github.com/QuinAsura/linux/tree/lnext-072619-GJ-series
>
> --
> Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc, is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project


[PATCH v5 00/14] Provide generic top-down mmap layout functions

2019-07-29 Thread Alexandre Ghiti
This series introduces generic functions to make top-down mmap layout
easily accessible to architectures, in particular riscv which was
the initial goal of this series.
The generic implementation was taken from arm64 and used successively
by arm, mips and finally riscv.

Note that in addition the series fixes 2 issues:
- stack randomization was taken into account even if not necessary.
- [1] fixed an issue with mmap base which did not take into account
  randomization but did not report it to arm and mips, so by moving
  arm64 into a generic library, this problem is now fixed for both
  architectures.

This work is an effort to factorize architecture functions to avoid
code duplication and oversights as in [1].

[1]: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1429066.html

Changes in v5:
  - Fix [PATCH 11/14]
  - Rebase on top of v5.3rc2 and commit
"riscv: kbuild: add virtual memory system selection"
  - [PATCH 14/14] now takes into account the various virtual memory systems

Changes in v4:
  - Make ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT select ARCH_HAS_ELF_RANDOMIZE
by default as suggested by Kees,
  - ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT depends on MMU and defines the
functions needed by ARCH_HAS_ELF_RANDOMIZE => architectures that use
the generic mmap topdown functions cannot have ARCH_HAS_ELF_RANDOMIZE
selected without MMU, but I think it's ok since randomization without
MMU does not add much security anyway.
  - There is no common API to determine if a process is 32b, so I came up with
!IS_ENABLED(CONFIG_64BIT) || is_compat_task() in [PATCH v4 12/14].
  - Mention in the change log that x86 already takes care of not offseting mmap
base address if the task does not want randomization.
  - Re-introduce a comment that should not have been removed.
  - Add Reviewed/Acked-By from Paul, Christoph and Kees, thank you for that.
  - I tried to minimize the changes from the commits in v3 in order to make
easier the review of the v4, the commits changed or added are:
- [PATCH v4 5/14]
- [PATCH v4 8/14]
- [PATCH v4 11/14]
- [PATCH v4 12/14]
- [PATCH v4 13/14]

Changes in v3:
  - Split into small patches to ease review as suggested by Christoph
Hellwig and Kees Cook
  - Move help text of new config as a comment, as suggested by Christoph
  - Make new config depend on MMU, as suggested by Christoph

Changes in v2 as suggested by Christoph Hellwig:
  - Preparatory patch that moves randomize_stack_top
  - Fix duplicate config in riscv
  - Align #if defined on next line => this gives rise to a checkpatch
warning. I found this pattern all around the tree, in the same proportion
as the previous pattern which was less pretty:
git grep -C 1 -n -P "^#if defined.+\|\|.*$"

Alexandre Ghiti (14):
  mm, fs: Move randomize_stack_top from fs to mm
  arm64: Make use of is_compat_task instead of hardcoding this test
  arm64: Consider stack randomization for mmap base only when necessary
  arm64, mm: Move generic mmap layout functions to mm
  arm64, mm: Make randomization selected by generic topdown mmap layout
  arm: Properly account for stack randomization and stack guard gap
  arm: Use STACK_TOP when computing mmap base address
  arm: Use generic mmap top-down layout and brk randomization
  mips: Properly account for stack randomization and stack guard gap
  mips: Use STACK_TOP when computing mmap base address
  mips: Adjust brk randomization offset to fit generic version
  mips: Replace arch specific way to determine 32bit task with generic
version
  mips: Use generic mmap top-down layout and brk randomization
  riscv: Make mmap allocation top-down by default

 arch/Kconfig   |  11 +++
 arch/arm/Kconfig   |   2 +-
 arch/arm/include/asm/processor.h   |   2 -
 arch/arm/kernel/process.c  |   5 --
 arch/arm/mm/mmap.c |  52 --
 arch/arm64/Kconfig |   2 +-
 arch/arm64/include/asm/processor.h |   2 -
 arch/arm64/kernel/process.c|   8 ---
 arch/arm64/mm/mmap.c   |  72 ---
 arch/mips/Kconfig  |   2 +-
 arch/mips/include/asm/processor.h  |   5 --
 arch/mips/mm/mmap.c|  84 --
 arch/riscv/Kconfig |  13 
 fs/binfmt_elf.c|  20 --
 include/linux/mm.h |   2 +
 kernel/sysctl.c|   6 +-
 mm/util.c  | 107 -
 17 files changed, 139 insertions(+), 256 deletions(-)

-- 
2.20.1



Re: [PATCH 1/1] power: supply: sbs-battery: Add ability to force load a battery via the devicetree

2019-07-29 Thread Richard Tresidder

Hi Guenter
  See below
Richard Tresidder

Cheers

  Richard Tresidder

**
On 30/07/2019 12:09 pm, Guenter Roeck wrote:

On Mon, Jul 29, 2019 at 8:02 PM Richard Tresidder
 wrote:

Hi Nick and Guenter
Just adding you to this one also seeing as you're looking at that other
sbs_battery patch for me.
Not sure why the get maintainers didn't list you for this one.

Cheers
 Richard Tresidder

Add the ability to force load a hot pluggable battery during boot where
there is no gpio detect method available and the module is statically
built. Normal polling will then occur on that battery when it is inserted.

Signed-off-by: Richard Tresidder 
---

Notes:
  Add the ability to force load a hot pluggable battery during boot where
  there is no gpio detect method available and the module is statically
  built. Normal polling will then occur on that battery when it is inserted.

   drivers/power/supply/sbs-battery.c | 6 +-
   1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/power/supply/sbs-battery.c 
b/drivers/power/supply/sbs-battery.c
index 048d205..ea8ba3e 100644
--- a/drivers/power/supply/sbs-battery.c
+++ b/drivers/power/supply/sbs-battery.c
@@ -161,6 +161,7 @@ struct sbs_info {
   int poll_time;
   u32 i2c_retry_count;
   u32 poll_retry_count;
+ boolforce_load;
   struct delayed_work work;
   struct mutexmode_lock;
   u32 flags;
@@ -852,6 +853,9 @@ static int sbs_probe(struct i2c_client *client,
   if (rc)
   chip->poll_retry_count = 0;

+ chip->force_load = of_property_read_bool(client->dev.of_node,
+ "sbs,force-load");
+

Maybe it is documented in another patch, which I have not seen. If it
isn't, it will have to be documented and reviewed by a devicetree
maintainer. Either case, I don't immediately see why the variable
needs to reside in struct sbs_info; it seems to be used only in the
probe function.
Good point, we don't actually need to store the value, it can just be a 
local.
Yep I had done a device tree documentation patch, but confused myself 
when submitting due to it having to be in a separate patch
I think I need to create 2 different patches but submit in the same 
email via send-patch as a multipart patch..

I'll try to fix that when I send it in again.



   if (pdata) {
   chip->poll_retry_count = pdata->poll_retry_count;
   chip->i2c_retry_count  = pdata->i2c_retry_count;
@@ -890,7 +894,7 @@ static int sbs_probe(struct i2c_client *client,
* Before we register, we might need to make sure we can actually talk
* to the battery.
*/
- if (!(force_load || chip->gpio_detect)) {
+ if (!(force_load || chip->gpio_detect || chip->force_load)) {
   rc = sbs_read_word_data(client, sbs_data[REG_STATUS].addr);

   if (rc < 0) {






Re: [PATCH v5] PM / wakeup: show wakeup sources stats in sysfs

2019-07-29 Thread Rafael J. Wysocki
On Tue, Jul 30, 2019 at 4:45 AM Tri Vo  wrote:
>
> Userspace can use wakeup_sources debugfs node to plot history of suspend
> blocking wakeup sources over device's boot cycle. This information can
> then be used (1) for power-specific bug reporting and (2) towards
> attributing battery consumption to specific processes over a period of
> time.
>
> However, debugfs doesn't have stable ABI. For this reason, create a
> 'struct device' to expose wakeup sources statistics in sysfs under
> /sys/class/wakeup/wakeup/*.
>
> Co-developed-by: Greg Kroah-Hartman 
> Signed-off-by: Greg Kroah-Hartman 
> Co-developed-by: Stephen Boyd 
> Signed-off-by: Stephen Boyd 
> Signed-off-by: Tri Vo 
> Tested-by: Tri Vo 
> Tested-by: Kalesh Singh 
> Reported-by: kbuild test robot 
> ---
>  Documentation/ABI/testing/sysfs-class-wakeup |  76 +
>  drivers/acpi/device_pm.c |   3 +-
>  drivers/base/power/Makefile  |   2 +-
>  drivers/base/power/wakeup.c  |  21 ++-
>  drivers/base/power/wakeup_stats.c| 171 +++
>  fs/eventpoll.c   |   4 +-
>  include/linux/pm_wakeup.h|  15 +-
>  kernel/power/autosleep.c |   2 +-
>  kernel/power/wakelock.c  |  10 ++
>  kernel/time/alarmtimer.c |   2 +-
>  10 files changed, 294 insertions(+), 12 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-class-wakeup
>  create mode 100644 drivers/base/power/wakeup_stats.c
>
> v2:
> - Updated Documentation/ABI/, as per Greg.
> - Removed locks in attribute functions, as per Greg.
> - Lifetimes of struct wakelock and struck wakeup_source are now different due 
> to
>   the latter embedding a refcounted kobject. Changed it so that struct 
> wakelock
>   only has a pointer to struct wakeup_source, instead of embedding it.
> - Added CONFIG_PM_SLEEP_STATS that enables/disables wakeup source statistics 
> in
>   sysfs.
>
> v3:
> Changes by Greg:
> - Reworked code to use 'struct device' instead of raw kobjects.
> - Updated documentation file.
> - Only link wakeup_stats.o when CONFIG_PM_SLEEP_STATS is enabled.
> Changes by Tri:
> - Reverted changes to kernel/power/wakelock.c. 'struct device' hides kobject
>   operations. So no need to handle lifetimes in wakelock.c
>
> v4:
> - Added 'Co-developed-by:' and 'Tested-by:' fields to commit message.
> - Moved new documentation to a separate file
>   Documentation/ABI/testing/sysfs-class-wakeup, as per Greg.
> - Fixed copyright header in drivers/base/power/wakeup_stats.c, as per Greg.
>
> v5:
> - Removed CONFIG_PM_SLEEP_STATS
> - Used PTR_ERR_OR_ZERO instead of if(IS_ERR(...)) + PTR_ERR, reported by
>   kbuild test robot 
> - Stephen reported that a call to device_init_wakeup() and writing 'enabled' 
> to
>   that device's power/wakeup file results in multiple wakeup source being
>   allocated for that device.  Changed device_wakeup_enable() to check if 
> device
>   wakeup was previously enabled.
> Changes by Stephen:
> - Changed stats location from /sys/class/wakeup//* to
>   /sys/class/wakeup/wakeup/*, where ID is an IDA-allocated integer. This
>   avoids name collisions in /sys/class/wakeup/ directory.
> - Added a "name" attribute to wakeup sources, and updated documentation.
> - Device registering the wakeup source is now the parent of the wakeup source.
>   Updated wakeup_source_register()'s signature and its callers accordingly.

And I really don't like these changes.  Especially having "wakeup"
twice in the path.

Couldn't you find a simpler way to avoid the name collisions?


[PATCH v2 2/5] pinctrl: uniphier: Add another audio I/O pin-mux settings for LD20

2019-07-29 Thread Kunihiko Hayashi
This adds support for pinmux settings of aout1b group. This group includes
audio I/O signals derived from xirq pins, and it is equivalent to "aout1"
in functionality.

Signed-off-by: Kunihiko Hayashi 
---
 drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c 
b/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c
index 28e54b3..8d4fb65 100644
--- a/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c
+++ b/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c
@@ -544,6 +544,8 @@ static const struct pinctrl_pin_desc uniphier_ld20_pins[] = 
{
 
 static const unsigned aout1_pins[] = {137, 138, 139, 140, 141, 142};
 static const int aout1_muxvals[] = {0, 0, 0, 0, 0, 0};
+static const unsigned aout1b_pins[] = {150, 151, 152, 153, 154, 155, 156};
+static const int aout1b_muxvals[] = {1, 1, 1, 1, 1, 1, 1};
 static const unsigned aoutiec1_pins[] = {135, 136};
 static const int aoutiec1_muxvals[] = {0, 0};
 static const unsigned int emmc_pins[] = {19, 20, 21, 22, 23, 24, 25};
@@ -664,6 +666,7 @@ static const unsigned int gpio_range2_pins[] = {
 
 static const struct uniphier_pinctrl_group uniphier_ld20_groups[] = {
UNIPHIER_PINCTRL_GROUP(aout1),
+   UNIPHIER_PINCTRL_GROUP(aout1b),
UNIPHIER_PINCTRL_GROUP(aoutiec1),
UNIPHIER_PINCTRL_GROUP(emmc),
UNIPHIER_PINCTRL_GROUP(emmc_dat8),
@@ -707,7 +710,7 @@ static const struct uniphier_pinctrl_group 
uniphier_ld20_groups[] = {
UNIPHIER_PINCTRL_GROUP_GPIO(gpio_range2),
 };
 
-static const char * const aout1_groups[] = {"aout1"};
+static const char * const aout1_groups[] = {"aout1", "aout1b"};
 static const char * const aoutiec1_groups[] = {"aoutiec1"};
 static const char * const emmc_groups[] = {"emmc", "emmc_dat8"};
 static const char * const ether_rgmii_groups[] = {"ether_rgmii"};
-- 
2.7.4



[PATCH v2] gpio: remove less important #ifdef around declarations

2019-07-29 Thread Masahiro Yamada
The whole struct/function declarations in this header are surrounded
by #ifdef.

As far as I understood, the motivation of this is probably to break
the build earlier if a driver misses to select or depend on correct
CONFIG options in Kconfig.

Since commit 94bed2a9c4ae ("Add -Werror-implicit-function-declaration")
no one cannot call functions that have not been declared.

So, I see some benefit in doing this in the cost of uglier headers.

In reality, it would not be so easy to catch missed 'select' or
'depends on' because GPIOLIB, GPIOLIB_IRQCHIP etc. are already selected
by someone else eventually. So, this kind of error, if any, will be
caught by randconfig bots.

In summary, I am not a big fan of cluttered #ifdef nesting, and this
does not matter for normal developers. The code readability wins.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - rebase

 include/linux/gpio/driver.h | 27 ---
 1 file changed, 8 insertions(+), 19 deletions(-)

diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
index 6a0e420915a3..f28f534f451a 100644
--- a/include/linux/gpio/driver.h
+++ b/include/linux/gpio/driver.h
@@ -20,9 +20,6 @@ struct module;
 enum gpiod_flags;
 enum gpio_lookup_flags;
 
-#ifdef CONFIG_GPIOLIB
-
-#ifdef CONFIG_GPIOLIB_IRQCHIP
 /**
  * struct gpio_irq_chip - GPIO interrupt controller
  */
@@ -161,7 +158,6 @@ struct gpio_irq_chip {
 */
void(*irq_disable)(struct irq_data *data);
 };
-#endif /* CONFIG_GPIOLIB_IRQCHIP */
 
 /**
  * struct gpio_chip - abstract a GPIO controller
@@ -441,16 +437,12 @@ bool gpiochip_line_is_valid(const struct gpio_chip *chip, 
unsigned int offset);
 /* get driver data */
 void *gpiochip_get_data(struct gpio_chip *chip);
 
-struct gpio_chip *gpiod_to_chip(const struct gpio_desc *desc);
-
 struct bgpio_pdata {
const char *label;
int base;
int ngpio;
 };
 
-#if IS_ENABLED(CONFIG_GPIO_GENERIC)
-
 int bgpio_init(struct gpio_chip *gc, struct device *dev,
   unsigned long sz, void __iomem *dat, void __iomem *set,
   void __iomem *clr, void __iomem *dirout, void __iomem *dirin,
@@ -463,10 +455,6 @@ int bgpio_init(struct gpio_chip *gc, struct device *dev,
 #define BGPIOF_READ_OUTPUT_REG_SET BIT(4) /* reg_set stores output value */
 #define BGPIOF_NO_OUTPUT   BIT(5) /* only input */
 
-#endif /* CONFIG_GPIO_GENERIC */
-
-#ifdef CONFIG_GPIOLIB_IRQCHIP
-
 int gpiochip_irq_map(struct irq_domain *d, unsigned int irq,
 irq_hw_number_t hwirq);
 void gpiochip_irq_unmap(struct irq_domain *d, unsigned int irq);
@@ -555,15 +543,11 @@ static inline int gpiochip_irqchip_add_nested(struct 
gpio_chip *gpiochip,
 }
 #endif /* CONFIG_LOCKDEP */
 
-#endif /* CONFIG_GPIOLIB_IRQCHIP */
-
 int gpiochip_generic_request(struct gpio_chip *chip, unsigned offset);
 void gpiochip_generic_free(struct gpio_chip *chip, unsigned offset);
 int gpiochip_generic_config(struct gpio_chip *chip, unsigned offset,
unsigned long config);
 
-#ifdef CONFIG_PINCTRL
-
 /**
  * struct gpio_pin_range - pin range controlled by a gpio chip
  * @node: list for maintaining set of pin ranges, used internally
@@ -576,6 +560,8 @@ struct gpio_pin_range {
struct pinctrl_gpio_range range;
 };
 
+#ifdef CONFIG_PINCTRL
+
 int gpiochip_add_pin_range(struct gpio_chip *chip, const char *pinctl_name,
   unsigned int gpio_offset, unsigned int pin_offset,
   unsigned int npins);
@@ -586,8 +572,6 @@ void gpiochip_remove_pin_ranges(struct gpio_chip *chip);
 
 #else /* ! CONFIG_PINCTRL */
 
-struct pinctrl_dev;
-
 static inline int
 gpiochip_add_pin_range(struct gpio_chip *chip, const char *pinctl_name,
   unsigned int gpio_offset, unsigned int pin_offset,
@@ -619,6 +603,11 @@ void gpiochip_free_own_desc(struct gpio_desc *desc);
 void devprop_gpiochip_set_names(struct gpio_chip *chip,
const struct fwnode_handle *fwnode);
 
+
+#ifdef CONFIG_GPIOLIB
+
+struct gpio_chip *gpiod_to_chip(const struct gpio_desc *desc);
+
 #else /* CONFIG_GPIOLIB */
 
 static inline struct gpio_chip *gpiod_to_chip(const struct gpio_desc *desc)
@@ -630,4 +619,4 @@ static inline struct gpio_chip *gpiod_to_chip(const struct 
gpio_desc *desc)
 
 #endif /* CONFIG_GPIOLIB */
 
-#endif
+#endif /* __LINUX_GPIO_DRIVER_H */
-- 
2.17.1



[PATCH v2 4/5] pinctrl: uniphier: Add Pro5 PCIe pin-mux settings

2019-07-29 Thread Kunihiko Hayashi
Pro5 PCIe interface uses the following pins:
XPERST, XPEWAKE, XPECLKRQ

Signed-off-by: Kunihiko Hayashi 
---
 drivers/pinctrl/uniphier/pinctrl-uniphier-pro5.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/pinctrl/uniphier/pinctrl-uniphier-pro5.c 
b/drivers/pinctrl/uniphier/pinctrl-uniphier-pro5.c
index 1d418e3..0c0af99 100644
--- a/drivers/pinctrl/uniphier/pinctrl-uniphier-pro5.c
+++ b/drivers/pinctrl/uniphier/pinctrl-uniphier-pro5.c
@@ -807,6 +807,8 @@ static const unsigned nand_pins[] = {19, 20, 21, 22, 23, 
24, 25, 28, 29, 30,
 static const int nand_muxvals[] = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
0};
 static const unsigned nand_cs1_pins[] = {26, 27};
 static const int nand_cs1_muxvals[] = {0, 0};
+static const unsigned pcie_pins[] = {109, 110, 111};
+static const int pcie_muxvals[] = {0, 0, 0};
 static const unsigned sd_pins[] = {250, 251, 252, 253, 254, 255, 256, 257, 
258};
 static const int sd_muxvals[] = {0, 0, 0, 0, 0, 0, 0, 0, 0};
 static const unsigned spi0_pins[] = {120, 121, 122, 123};
@@ -902,6 +904,7 @@ static const struct uniphier_pinctrl_group 
uniphier_pro5_groups[] = {
UNIPHIER_PINCTRL_GROUP(i2c5b),
UNIPHIER_PINCTRL_GROUP(i2c5c),
UNIPHIER_PINCTRL_GROUP(i2c6),
+   UNIPHIER_PINCTRL_GROUP(pcie),
UNIPHIER_PINCTRL_GROUP(sd),
UNIPHIER_PINCTRL_GROUP(spi0),
UNIPHIER_PINCTRL_GROUP(spi1),
@@ -936,6 +939,7 @@ static const char * const i2c3_groups[] = {"i2c3"};
 static const char * const i2c5_groups[] = {"i2c5", "i2c5b", "i2c5c"};
 static const char * const i2c6_groups[] = {"i2c6"};
 static const char * const nand_groups[] = {"nand", "nand_cs1"};
+static const char * const pcie_groups[] = {"pcie"};
 static const char * const sd_groups[] = {"sd"};
 static const char * const spi0_groups[] = {"spi0"};
 static const char * const spi1_groups[] = {"spi1"};
@@ -967,6 +971,7 @@ static const struct uniphier_pinmux_function 
uniphier_pro5_functions[] = {
UNIPHIER_PINMUX_FUNCTION(i2c5),
UNIPHIER_PINMUX_FUNCTION(i2c6),
UNIPHIER_PINMUX_FUNCTION(nand),
+   UNIPHIER_PINMUX_FUNCTION(pcie),
UNIPHIER_PINMUX_FUNCTION(sd),
UNIPHIER_PINMUX_FUNCTION(spi0),
UNIPHIER_PINMUX_FUNCTION(spi1),
-- 
2.7.4



[PATCH v2 1/5] pinctrl: uniphier: Separate modem group from UART ctsrts group

2019-07-29 Thread Kunihiko Hayashi
It depends on the board implementation whether to have each pins of
CTS/RTS, and others for modem. So it is necessary to divide current
uart_ctsrts group into uart_ctsrts and uart_modem groups.

Since the number of implemented pins for modem differs depending
on SoC, each uart_modem group also has a different number of pins.

Signed-off-by: Kunihiko Hayashi 
---
 drivers/pinctrl/uniphier/pinctrl-uniphier-ld11.c | 10 +++---
 drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c | 10 +++---
 drivers/pinctrl/uniphier/pinctrl-uniphier-ld4.c  | 10 +++---
 drivers/pinctrl/uniphier/pinctrl-uniphier-ld6b.c | 10 +++---
 drivers/pinctrl/uniphier/pinctrl-uniphier-pro4.c | 10 +++---
 drivers/pinctrl/uniphier/pinctrl-uniphier-pro5.c | 10 +++---
 drivers/pinctrl/uniphier/pinctrl-uniphier-pxs2.c | 10 +++---
 drivers/pinctrl/uniphier/pinctrl-uniphier-pxs3.c | 10 +++---
 drivers/pinctrl/uniphier/pinctrl-uniphier-sld8.c | 10 +++---
 9 files changed, 63 insertions(+), 27 deletions(-)

diff --git a/drivers/pinctrl/uniphier/pinctrl-uniphier-ld11.c 
b/drivers/pinctrl/uniphier/pinctrl-uniphier-ld11.c
index 92fef3a..c390a55 100644
--- a/drivers/pinctrl/uniphier/pinctrl-uniphier-ld11.c
+++ b/drivers/pinctrl/uniphier/pinctrl-uniphier-ld11.c
@@ -526,8 +526,10 @@ static const unsigned uart2_pins[] = {90, 91};
 static const int uart2_muxvals[] = {1, 1};
 static const unsigned uart3_pins[] = {94, 95};
 static const int uart3_muxvals[] = {1, 1};
-static const unsigned uart3_ctsrts_pins[] = {96, 97, 98, 99, 100, 101};
-static const int uart3_ctsrts_muxvals[] = {1, 1, 1, 1, 1, 1};
+static const unsigned uart3_ctsrts_pins[] = {96, 98};
+static const int uart3_ctsrts_muxvals[] = {1, 1};
+static const unsigned uart3_modem_pins[] = {97, 99, 100, 101};
+static const int uart3_modem_muxvals[] = {1, 1, 1, 1};
 static const unsigned usb0_pins[] = {46, 47};
 static const int usb0_muxvals[] = {0, 0};
 static const unsigned usb1_pins[] = {48, 49};
@@ -600,6 +602,7 @@ static const struct uniphier_pinctrl_group 
uniphier_ld11_groups[] = {
UNIPHIER_PINCTRL_GROUP(uart2),
UNIPHIER_PINCTRL_GROUP(uart3),
UNIPHIER_PINCTRL_GROUP(uart3_ctsrts),
+   UNIPHIER_PINCTRL_GROUP(uart3_modem),
UNIPHIER_PINCTRL_GROUP(usb0),
UNIPHIER_PINCTRL_GROUP(usb1),
UNIPHIER_PINCTRL_GROUP(usb2),
@@ -636,7 +639,8 @@ static const char * const system_bus_groups[] = 
{"system_bus",
 static const char * const uart0_groups[] = {"uart0"};
 static const char * const uart1_groups[] = {"uart1"};
 static const char * const uart2_groups[] = {"uart2"};
-static const char * const uart3_groups[] = {"uart3", "uart3_ctsrts"};
+static const char * const uart3_groups[] = {"uart3", "uart3_ctsrts",
+   "uart3_modem"};
 static const char * const usb0_groups[] = {"usb0"};
 static const char * const usb1_groups[] = {"usb1"};
 static const char * const usb2_groups[] = {"usb2"};
diff --git a/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c 
b/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c
index 7fbc965..28e54b3 100644
--- a/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c
+++ b/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c
@@ -619,8 +619,10 @@ static const unsigned uart2_pins[] = {90, 91};
 static const int uart2_muxvals[] = {1, 1};
 static const unsigned uart3_pins[] = {94, 95};
 static const int uart3_muxvals[] = {1, 1};
-static const unsigned uart3_ctsrts_pins[] = {96, 97, 98, 99, 100, 101};
-static const int uart3_ctsrts_muxvals[] = {1, 1, 1, 1, 1, 1};
+static const unsigned uart3_ctsrts_pins[] = {96, 98};
+static const int uart3_ctsrts_muxvals[] = {1, 1};
+static const unsigned uart3_modem_pins[] = {97, 99, 100, 101};
+static const int uart3_modem_muxvals[] = {1, 1, 1, 1};
 static const unsigned usb0_pins[] = {46, 47};
 static const int usb0_muxvals[] = {0, 0};
 static const unsigned usb1_pins[] = {48, 49};
@@ -695,6 +697,7 @@ static const struct uniphier_pinctrl_group 
uniphier_ld20_groups[] = {
UNIPHIER_PINCTRL_GROUP(uart2),
UNIPHIER_PINCTRL_GROUP(uart3),
UNIPHIER_PINCTRL_GROUP(uart3_ctsrts),
+   UNIPHIER_PINCTRL_GROUP(uart3_modem),
UNIPHIER_PINCTRL_GROUP(usb0),
UNIPHIER_PINCTRL_GROUP(usb1),
UNIPHIER_PINCTRL_GROUP(usb2),
@@ -734,7 +737,8 @@ static const char * const system_bus_groups[] = 
{"system_bus",
 static const char * const uart0_groups[] = {"uart0"};
 static const char * const uart1_groups[] = {"uart1"};
 static const char * const uart2_groups[] = {"uart2"};
-static const char * const uart3_groups[] = {"uart3", "uart3_ctsrts"};
+static const char * const uart3_groups[] = {"uart3", "uart3_ctsrts",
+   "uart3_modem"};
 static const char * const usb0_groups[] = {"usb0"};
 static const char * const usb1_groups[] = {"usb1"};
 static const char * const usb2_groups[] = {"usb2"};
diff --git a/drivers/pinctrl/uniphier/pinctrl-uniphier-ld4.c 
b/drivers/pinctrl/uniphier/pinctrl-uniphier-l

[PATCH v2 0/5] pinctrl: uniphier: Add some improvements and new settings

2019-07-29 Thread Kunihiko Hayashi
This series adds some improvements and new settings for pin-mux.

Changes since v1:
- sort arrays in alphabetical order
- sort pin numbers in ascending order
- merge "aout1b" pin-mux to aout1_group
- change "4th" in the subject to "5th"
- add Acked-by: lines

Kunihiko Hayashi (5):
  pinctrl: uniphier: Separate modem group from UART ctsrts group
  pinctrl: uniphier: Add another audio I/O pin-mux settings for LD20
  pinctrl: uniphier: Add 5th LD20 MPEG2-TS input pin-mux setting
  pinctrl: uniphier: Add Pro5 PCIe pin-mux settings
  pinctrl: uniphier: Fix Pro5 SD pin-mux setting

 drivers/pinctrl/uniphier/pinctrl-uniphier-ld11.c | 10 +++---
 drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c | 20 
 drivers/pinctrl/uniphier/pinctrl-uniphier-ld4.c  | 10 +++---
 drivers/pinctrl/uniphier/pinctrl-uniphier-ld6b.c | 10 +++---
 drivers/pinctrl/uniphier/pinctrl-uniphier-pro4.c | 10 +++---
 drivers/pinctrl/uniphier/pinctrl-uniphier-pro5.c | 17 +
 drivers/pinctrl/uniphier/pinctrl-uniphier-pxs2.c | 10 +++---
 drivers/pinctrl/uniphier/pinctrl-uniphier-pxs3.c | 10 +++---
 drivers/pinctrl/uniphier/pinctrl-uniphier-sld8.c | 10 +++---
 9 files changed, 78 insertions(+), 29 deletions(-)

-- 
2.7.4



[PATCH v2 3/5] pinctrl: uniphier: Add 5th LD20 MPEG2-TS input pin-mux setting

2019-07-29 Thread Kunihiko Hayashi
The 5th serial TS interface uses the following pins:
  hscin4_s: PCA[11-14]

Signed-off-by: Kunihiko Hayashi 
Acked-by: Masahiro Yamada 
---
 drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c 
b/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c
index 8d4fb65..0a8b186 100644
--- a/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c
+++ b/drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c
@@ -576,6 +576,8 @@ static const unsigned hscin2_s_pins[] = {124, 125, 126, 
127};
 static const int hscin2_s_muxvals[] = {3, 3, 3, 3};
 static const unsigned hscin3_s_pins[] = {129, 130, 131, 132};
 static const int hscin3_s_muxvals[] = {3, 3, 3, 3};
+static const unsigned hscin4_s_pins[] = {80, 81, 82, 83};
+static const int hscin4_s_muxvals[] = {3, 3, 3, 3};
 static const unsigned hscout0_ci_pins[] = {113, 114, 115, 116, 117, 118, 119,
   120, 121, 122, 123};
 static const int hscout0_ci_muxvals[] = {1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1};
@@ -679,6 +681,7 @@ static const struct uniphier_pinctrl_group 
uniphier_ld20_groups[] = {
UNIPHIER_PINCTRL_GROUP(hscin1_s),
UNIPHIER_PINCTRL_GROUP(hscin2_s),
UNIPHIER_PINCTRL_GROUP(hscin3_s),
+   UNIPHIER_PINCTRL_GROUP(hscin4_s),
UNIPHIER_PINCTRL_GROUP(hscout0_ci),
UNIPHIER_PINCTRL_GROUP(hscout0_p),
UNIPHIER_PINCTRL_GROUP(hscout0_s),
@@ -721,6 +724,7 @@ static const char * const hscin0_groups[] = {"hscin0_ci",
 static const char * const hscin1_groups[] = {"hscin1_p", "hscin1_s"};
 static const char * const hscin2_groups[] = {"hscin2_s"};
 static const char * const hscin3_groups[] = {"hscin3_s"};
+static const char * const hscin4_groups[] = {"hscin4_s"};
 static const char * const hscout0_groups[] = {"hscout0_ci",
  "hscout0_p",
  "hscout0_s"};
@@ -757,6 +761,7 @@ static const struct uniphier_pinmux_function 
uniphier_ld20_functions[] = {
UNIPHIER_PINMUX_FUNCTION(hscin1),
UNIPHIER_PINMUX_FUNCTION(hscin2),
UNIPHIER_PINMUX_FUNCTION(hscin3),
+   UNIPHIER_PINMUX_FUNCTION(hscin4),
UNIPHIER_PINMUX_FUNCTION(hscout0),
UNIPHIER_PINMUX_FUNCTION(hscout1),
UNIPHIER_PINMUX_FUNCTION(i2c0),
-- 
2.7.4



[PATCH v2 5/5] pinctrl: uniphier: Fix Pro5 SD pin-mux setting

2019-07-29 Thread Kunihiko Hayashi
SD uses the following pins starting from 247:
SDCD, SDWP, SDVOLC, SDCLK, SDCMD, SDDAT{0,1,2,3}

Signed-off-by: Kunihiko Hayashi 
Acked-by: Masahiro Yamada 
---
 drivers/pinctrl/uniphier/pinctrl-uniphier-pro5.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/uniphier/pinctrl-uniphier-pro5.c 
b/drivers/pinctrl/uniphier/pinctrl-uniphier-pro5.c
index 0c0af99..4277d49 100644
--- a/drivers/pinctrl/uniphier/pinctrl-uniphier-pro5.c
+++ b/drivers/pinctrl/uniphier/pinctrl-uniphier-pro5.c
@@ -809,7 +809,7 @@ static const unsigned nand_cs1_pins[] = {26, 27};
 static const int nand_cs1_muxvals[] = {0, 0};
 static const unsigned pcie_pins[] = {109, 110, 111};
 static const int pcie_muxvals[] = {0, 0, 0};
-static const unsigned sd_pins[] = {250, 251, 252, 253, 254, 255, 256, 257, 
258};
+static const unsigned sd_pins[] = {247, 248, 249, 250, 251, 252, 253, 254, 
255};
 static const int sd_muxvals[] = {0, 0, 0, 0, 0, 0, 0, 0, 0};
 static const unsigned spi0_pins[] = {120, 121, 122, 123};
 static const int spi0_muxvals[] = {0, 0, 0, 0};
-- 
2.7.4



[PATCH v5 1/3] driver core: platform: Add an error message to platform_get_irq*()

2019-07-29 Thread Stephen Boyd
A grep of the kernel shows that many drivers print an error message if
they fail to get the irq they're looking for. Furthermore, those drivers
all decide to print the device name, or not, and the irq they were
requesting, or not, etc. Let's consolidate all these error messages into
the API itself, allowing us to get rid of the error messages in each
driver.

Cc: Rob Herring 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Javier Martinez Canillas 
Cc: Andrzej Hajda 
Cc: Mark Brown 
Cc: Russell King - ARM Linux 
Cc: Marek Szyprowski 
Cc: Markus Elfring 
Reviewed-by: Rafael J. Wysocki 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Stephen Boyd 
---
 drivers/base/platform.c | 42 +
 1 file changed, 34 insertions(+), 8 deletions(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 506a0175a5a7..55ecc3edf8a1 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -99,12 +99,7 @@ void __iomem *devm_platform_ioremap_resource(struct 
platform_device *pdev,
 EXPORT_SYMBOL_GPL(devm_platform_ioremap_resource);
 #endif /* CONFIG_HAS_IOMEM */
 
-/**
- * platform_get_irq - get an IRQ for a device
- * @dev: platform device
- * @num: IRQ number index
- */
-int platform_get_irq(struct platform_device *dev, unsigned int num)
+static int __platform_get_irq(struct platform_device *dev, unsigned int num)
 {
 #ifdef CONFIG_SPARC
/* sparc does not have irqs represented as IORESOURCE_IRQ resources */
@@ -163,6 +158,33 @@ int platform_get_irq(struct platform_device *dev, unsigned 
int num)
return -ENXIO;
 #endif
 }
+
+/**
+ * platform_get_irq - get an IRQ for a device
+ * @dev: platform device
+ * @num: IRQ number index
+ *
+ * Gets an IRQ for a platform device and prints an error message if finding the
+ * IRQ fails. Device drivers should check the return value for errors so as to
+ * not pass a negative integer value to the request_irq() APIs.
+ *
+ * Example:
+ * int irq = platform_get_irq(pdev, 0);
+ * if (irq < 0)
+ * return irq;
+ *
+ * Return: IRQ number on success, negative error number on failure.
+ */
+int platform_get_irq(struct platform_device *dev, unsigned int num)
+{
+   int ret;
+
+   ret = __platform_get_irq(dev, num);
+   if (ret < 0 && ret != -EPROBE_DEFER)
+   dev_err(&dev->dev, "IRQ index %u not found\n", num);
+
+   return ret;
+}
 EXPORT_SYMBOL_GPL(platform_get_irq);
 
 /**
@@ -175,7 +197,7 @@ int platform_irq_count(struct platform_device *dev)
 {
int ret, nr = 0;
 
-   while ((ret = platform_get_irq(dev, nr)) >= 0)
+   while ((ret = __platform_get_irq(dev, nr)) >= 0)
nr++;
 
if (ret == -EPROBE_DEFER)
@@ -228,7 +250,11 @@ int platform_get_irq_byname(struct platform_device *dev, 
const char *name)
}
 
r = platform_get_resource_byname(dev, IORESOURCE_IRQ, name);
-   return r ? r->start : -ENXIO;
+   if (r)
+   return r->start;
+
+   dev_err(&dev->dev, "IRQ %s not found\n", name);
+   return -ENXIO;
 }
 EXPORT_SYMBOL_GPL(platform_get_irq_byname);
 
-- 
Sent by a computer through tubes



[PATCH v3] mailbox: imx: add support for imx v1 mu

2019-07-29 Thread Richard Zhu
There is a version1.0 MU on i.MX7ULP platform.
One new version ID register is added, and it's offset is 0.
TRn registers are defined at the offset 0x20 ~ 0x2C.
RRn registers are defined at the offset 0x40 ~ 0x4C.
SR/CR registers are defined at 0x60/0x64.
Extend this driver to support it.

Signed-off-by: Richard Zhu 
Suggested-by: Oleksij Rempel 
Reviewed-by: Dong Aisheng 
Reviewed-by: Oleksij Rempel 
---
 drivers/mailbox/imx-mailbox.c | 55 ++-
 1 file changed, 38 insertions(+), 17 deletions(-)

diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index 25be8bb..c81be1c 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -12,19 +12,11 @@
 #include 
 #include 
 
-/* Transmit Register */
-#define IMX_MU_xTRn(x) (0x00 + 4 * (x))
-/* Receive Register */
-#define IMX_MU_xRRn(x) (0x10 + 4 * (x))
-/* Status Register */
-#define IMX_MU_xSR 0x20
 #define IMX_MU_xSR_GIPn(x) BIT(28 + (3 - (x)))
 #define IMX_MU_xSR_RFn(x)  BIT(24 + (3 - (x)))
 #define IMX_MU_xSR_TEn(x)  BIT(20 + (3 - (x)))
 #define IMX_MU_xSR_BRDIP   BIT(9)
 
-/* Control Register */
-#define IMX_MU_xCR 0x24
 /* General Purpose Interrupt Enable */
 #define IMX_MU_xCR_GIEn(x) BIT(28 + (3 - (x)))
 /* Receive Interrupt Enable */
@@ -44,6 +36,13 @@ enum imx_mu_chan_type {
IMX_MU_TYPE_RXDB,   /* Rx doorbell */
 };
 
+struct imx_mu_dcfg {
+   u32 xTR[4]; /* Transmit Registers */
+   u32 xRR[4]; /* Receive Registers */
+   u32 xSR;/* Status Register */
+   u32 xCR;/* Control Register */
+};
+
 struct imx_mu_con_priv {
unsigned intidx;
charirq_desc[IMX_MU_CHAN_NAME_SIZE];
@@ -61,12 +60,27 @@ struct imx_mu_priv {
struct mbox_chanmbox_chans[IMX_MU_CHANS];
 
struct imx_mu_con_priv  con_priv[IMX_MU_CHANS];
+   const struct imx_mu_dcfg*dcfg;
struct clk  *clk;
int irq;
 
boolside_b;
 };
 
+static const struct imx_mu_dcfg imx_mu_cfg_imx6sx = {
+   .xTR= {0x0, 0x4, 0x8, 0xc},
+   .xRR= {0x10, 0x14, 0x18, 0x1c},
+   .xSR= 0x20,
+   .xCR= 0x24,
+};
+
+static const struct imx_mu_dcfg imx_mu_cfg_imx7ulp = {
+   .xTR= {0x20, 0x24, 0x28, 0x2c},
+   .xRR= {0x40, 0x44, 0x48, 0x4c},
+   .xSR= 0x60,
+   .xCR= 0x64,
+};
+
 static struct imx_mu_priv *to_imx_mu_priv(struct mbox_controller *mbox)
 {
return container_of(mbox, struct imx_mu_priv, mbox);
@@ -88,10 +102,10 @@ static u32 imx_mu_xcr_rmw(struct imx_mu_priv *priv, u32 
set, u32 clr)
u32 val;
 
spin_lock_irqsave(&priv->xcr_lock, flags);
-   val = imx_mu_read(priv, IMX_MU_xCR);
+   val = imx_mu_read(priv, priv->dcfg->xCR);
val &= ~clr;
val |= set;
-   imx_mu_write(priv, val, IMX_MU_xCR);
+   imx_mu_write(priv, val, priv->dcfg->xCR);
spin_unlock_irqrestore(&priv->xcr_lock, flags);
 
return val;
@@ -111,8 +125,8 @@ static irqreturn_t imx_mu_isr(int irq, void *p)
struct imx_mu_con_priv *cp = chan->con_priv;
u32 val, ctrl, dat;
 
-   ctrl = imx_mu_read(priv, IMX_MU_xCR);
-   val = imx_mu_read(priv, IMX_MU_xSR);
+   ctrl = imx_mu_read(priv, priv->dcfg->xCR);
+   val = imx_mu_read(priv, priv->dcfg->xSR);
 
switch (cp->type) {
case IMX_MU_TYPE_TX:
@@ -138,10 +152,10 @@ static irqreturn_t imx_mu_isr(int irq, void *p)
imx_mu_xcr_rmw(priv, 0, IMX_MU_xCR_TIEn(cp->idx));
mbox_chan_txdone(chan, 0);
} else if (val == IMX_MU_xSR_RFn(cp->idx)) {
-   dat = imx_mu_read(priv, IMX_MU_xRRn(cp->idx));
+   dat = imx_mu_read(priv, priv->dcfg->xRR[cp->idx]);
mbox_chan_received_data(chan, (void *)&dat);
} else if (val == IMX_MU_xSR_GIPn(cp->idx)) {
-   imx_mu_write(priv, IMX_MU_xSR_GIPn(cp->idx), IMX_MU_xSR);
+   imx_mu_write(priv, IMX_MU_xSR_GIPn(cp->idx), priv->dcfg->xSR);
mbox_chan_received_data(chan, NULL);
} else {
dev_warn_ratelimited(priv->dev, "Not handled interrupt\n");
@@ -159,7 +173,7 @@ static int imx_mu_send_data(struct mbox_chan *chan, void 
*data)
 
switch (cp->type) {
case IMX_MU_TYPE_TX:
-   imx_mu_write(priv, *arg, IMX_MU_xTRn(cp->idx));
+   imx_mu_write(priv, *arg, priv->dcfg->xTR[cp->idx]);
imx_mu_xcr_rmw(priv, IMX_MU_xCR_TIEn(cp->idx), 0);
break;
case IMX_MU_TYPE_TXDB:
@@ -257,7 +271,7 @@ static void imx_mu_init_generic(struct imx_mu_priv *priv)
return;
 
/* Set default MU configuration */
-   imx_mu_write(priv, 0, IMX_MU_xCR);
+   imx_mu_write(priv, 0, priv->dcfg->xCR);
 }
 
 static int imx_mu_probe(st

[PATCH v3] mailbox: imx: add support for imx v1 mu

2019-07-29 Thread Richard Zhu
Change logs:

v2 --> v3:
  - Format the patch-set refer to Oleksij's guidance.
  - Init the register array by a simple way recommended by Oleksij.
  - Add Reviewed-by: Oleksij Rempel  tag.

v1 --> v2:
  - Use to have the register layout linked on probe, suggested by
  Oleksij Rempel .
  - Add Reviewed-by: Dong Aisheng  tag.

Richard Zhu (1):
  mailbox: imx: add support for imx v1 mu

 drivers/mailbox/imx-mailbox.c | 55 ++-
 1 file changed, 38 insertions(+), 17 deletions(-)

-- 
2.7.4



Re: [PATCH] powerpc: workaround clang codegen bug in dcbz

2019-07-29 Thread Christophe Leroy




Le 29/07/2019 à 22:32, Nathan Chancellor a écrit :

On Mon, Jul 29, 2019 at 01:25:41PM -0700, Nick Desaulniers wrote:

Commit 6c5875843b87 ("powerpc: slightly improve cache helpers") exposed
what looks like a codegen bug in Clang's handling of `%y` output
template with `Z` constraint. This is resulting in panics during boot
for 32b powerpc builds w/ Clang, as reported by our CI.

Add back the original code that worked behind a preprocessor check for
__clang__ until we can fix LLVM.

Further, it seems that clang allnoconfig builds are unhappy with `Z`, as
reported by 0day bot. This is likely because Clang warns about inline
asm constraints when the constraint requires inlining to be semantically
valid.

Link: https://bugs.llvm.org/show_bug.cgi?id=42762
Link: https://github.com/ClangBuiltLinux/linux/issues/593
Link: 
https://lore.kernel.org/lkml/20190721075846.GA97701@archlinux-threadripper/
Debugged-by: Nathan Chancellor 
Reported-by: Nathan Chancellor 
Reported-by: kbuild test robot 
Suggested-by: Nathan Chancellor 
Signed-off-by: Nick Desaulniers 
---
Alternatively, we could just revert 6c5875843b87. It seems that GCC
generates the same code for these functions for out of line versions.
But I'm not sure how the inlined code generated would be affected.


For the record:

https://godbolt.org/z/z57VU7

This seems consistent with what Michael found so I don't think a revert
is entirely unreasonable.


Your example functions are too simple to show anything. The functions 
takes only one parameter so of course GCC won't use two registers 
allthough given the opportunity.


Christophe



Either way:

Reviewed-by: Nathan Chancellor 



Re: [PATCH v4 0/3] Introduce Bandwidth OPPs for interconnects

2019-07-29 Thread Sibi Sankar

Hey Viresh,

On 7/30/19 8:16 AM, Viresh Kumar wrote:

On 29-07-19, 13:16, Saravana Kannan wrote:

Sibi might be working on doing that for the SDM845 CPUfreq driver.
Georgi could also change his GPU driver use case to use this BW OPP
table and required-opps.

The problem is that people don't want to start using this until we
decide on the DT representation. So it's like a chicken and egg
situation.


Yeah, I agree to that.

@Georgi and @Sibi: This is your chance to speak up about the proposal
from Saravana and if you find anything wrong with them. And specially
that it is mostly about interconnects here, I would like to have an
explicit Ack from Georgi on this.

And if you guys are all okay about this then please at least commit
that you will convert your stuff based on this in coming days.


I've been using both Saravana's and Georgi's series for a while
now to scale DDR and L3 on SDM845. There is currently no consensus
as to where the votes are to be actuated from, hence couldn't post
anything out.

DCVS based on Saravana's series + passive governor:
https://github.com/QuinAsura/linux/tree/lnext-072619-SK-series

DCVS based on Georgi's series: (I had already posted this out)
https://github.com/QuinAsura/linux/tree/lnext-072619-GJ-series

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


Re: [RFC PATCH 00/16] KVM RISC-V Support

2019-07-29 Thread Anup Patel
On Tue, Jul 30, 2019 at 3:17 AM Paolo Bonzini  wrote:
>
> On 29/07/19 13:56, Anup Patel wrote:
> > This series adds initial KVM RISC-V support. Currently, we are able to boot
> > RISC-V 64bit Linux Guests with multiple VCPUs.
> >
> > Few key aspects of KVM RISC-V added by this series are:
> > 1. Minimal possible KVM world-switch which touches only GPRs and few CSRs.
> > 2. Full Guest/VM switch is done via vcpu_get/vcpu_put infrastructure.
> > 3. KVM ONE_REG interface for VCPU register access from user-space.
> > 4. PLIC emulation is done in user-space. In-kernel PLIC emulation, will
> >be added in future.
> > 5. Timer and IPI emuation is done in-kernel.
> > 6. MMU notifiers supported.
> > 7. FP lazy save/restore supported.
> > 8. SBI v0.1 emulation for KVM Guest available.
> >
> > More feature additions and enhancments will follow after this series and
> > eventually KVM RISC-V will be at-par with other architectures.
>
> This looks clean and it shouldn't take long to have it merged.  Please
> sort out the MAINTAINERS additions.  It would also be nice if
> tools/testing/selftests/kvm/ worked with RISC-V from the beginning;
> there have been recent ARM and s390 ports that you can take some
> inspiration from.

Thanks Paolo.

We will certainly include a patch in v2 series for MAINTAINERS entry.

We referred existing implementation of KVM ARM/ARM64, KVM powerpc
and KVM mips when we started KVM RISC-V port.

Here's a brief TODO list which we want to immediately work upon after this
series:
1. Handle trap from unpriv access in SBI v0.1 emulation
2. In-kernel PLIC emulation
3. SBI v0.2 emulation in-kernel
4. SBI v0.2 hart hotplug emulation in-kernel
5. . and so on .

We will include above TODO list in v2 series cover letter as well.

Apart from above, we also have a more exhaustive TODO list based on study
of other KVM ports which we want to discuss at upcoming LPC 2019.

We were thinking to keep KVM RISC-V disabled by default (i.e. keep it
experimental) until we have validated it on some FPGA or real HW. For now,
users can explicitly enable it and play-around on QEMU emulation. I hope
this is fine with most people ?

Regards,
Anup


[PATCH v10 2/4] uprobe: use original page when all uprobes are removed

2019-07-29 Thread Song Liu
Currently, uprobe swaps the target page with a anonymous page in both
install_breakpoint() and remove_breakpoint(). When all uprobes on a page
are removed, the given mm is still using an anonymous page (not the
original page).

This patch allows uprobe to use original page when possible (all uprobes
on the page are already removed). As suggested by Oleg, we unmap the
old_page and let the original page fault in.

Suggested-by: Oleg Nesterov 
Signed-off-by: Song Liu 
---
 kernel/events/uprobes.c | 66 +++--
 1 file changed, 51 insertions(+), 15 deletions(-)

diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 84fa00497c49..648f47553bff 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -143,10 +143,12 @@ static loff_t vaddr_to_offset(struct vm_area_struct *vma, 
unsigned long vaddr)
  *
  * @vma:  vma that holds the pte pointing to page
  * @addr: address the old @page is mapped at
- * @page: the cowed page we are replacing by kpage
- * @kpage:the modified page we replace page by
+ * @old_page: the page we are replacing by new_page
+ * @new_page: the modified page we replace page by
  *
- * Returns 0 on success, -EFAULT on failure.
+ * If @new_page is NULL, only unmap @old_page.
+ *
+ * Returns 0 on success, negative error code otherwise.
  */
 static int __replace_page(struct vm_area_struct *vma, unsigned long addr,
struct page *old_page, struct page *new_page)
@@ -166,10 +168,12 @@ static int __replace_page(struct vm_area_struct *vma, 
unsigned long addr,
 
VM_BUG_ON_PAGE(PageTransHuge(old_page), old_page);
 
-   err = mem_cgroup_try_charge(new_page, vma->vm_mm, GFP_KERNEL, &memcg,
-   false);
-   if (err)
-   return err;
+   if (new_page) {
+   err = mem_cgroup_try_charge(new_page, vma->vm_mm, GFP_KERNEL,
+   &memcg, false);
+   if (err)
+   return err;
+   }
 
/* For try_to_free_swap() and munlock_vma_page() below */
lock_page(old_page);
@@ -177,15 +181,20 @@ static int __replace_page(struct vm_area_struct *vma, 
unsigned long addr,
mmu_notifier_invalidate_range_start(&range);
err = -EAGAIN;
if (!page_vma_mapped_walk(&pvmw)) {
-   mem_cgroup_cancel_charge(new_page, memcg, false);
+   if (new_page)
+   mem_cgroup_cancel_charge(new_page, memcg, false);
goto unlock;
}
VM_BUG_ON_PAGE(addr != pvmw.address, old_page);
 
-   get_page(new_page);
-   page_add_new_anon_rmap(new_page, vma, addr, false);
-   mem_cgroup_commit_charge(new_page, memcg, false, false);
-   lru_cache_add_active_or_unevictable(new_page, vma);
+   if (new_page) {
+   get_page(new_page);
+   page_add_new_anon_rmap(new_page, vma, addr, false);
+   mem_cgroup_commit_charge(new_page, memcg, false, false);
+   lru_cache_add_active_or_unevictable(new_page, vma);
+   } else
+   /* no new page, just dec_mm_counter for old_page */
+   dec_mm_counter(mm, MM_ANONPAGES);
 
if (!PageAnon(old_page)) {
dec_mm_counter(mm, mm_counter_file(old_page));
@@ -194,8 +203,9 @@ static int __replace_page(struct vm_area_struct *vma, 
unsigned long addr,
 
flush_cache_page(vma, addr, pte_pfn(*pvmw.pte));
ptep_clear_flush_notify(vma, addr, pvmw.pte);
-   set_pte_at_notify(mm, addr, pvmw.pte,
-   mk_pte(new_page, vma->vm_page_prot));
+   if (new_page)
+   set_pte_at_notify(mm, addr, pvmw.pte,
+ mk_pte(new_page, vma->vm_page_prot));
 
page_remove_rmap(old_page, false);
if (!page_mapped(old_page))
@@ -488,6 +498,10 @@ int uprobe_write_opcode(struct arch_uprobe *auprobe, 
struct mm_struct *mm,
ref_ctr_updated = 1;
}
 
+   ret = 0;
+   if (!is_register && !PageAnon(old_page))
+   goto put_old;
+
ret = anon_vma_prepare(vma);
if (ret)
goto put_old;
@@ -501,8 +515,30 @@ int uprobe_write_opcode(struct arch_uprobe *auprobe, 
struct mm_struct *mm,
copy_highpage(new_page, old_page);
copy_to_page(new_page, vaddr, &opcode, UPROBE_SWBP_INSN_SIZE);
 
+   if (!is_register) {
+   struct page *orig_page;
+   pgoff_t index;
+
+   VM_BUG_ON_PAGE(!PageAnon(old_page), old_page);
+
+   index = vaddr_to_offset(vma, vaddr & PAGE_MASK) >> PAGE_SHIFT;
+   orig_page = find_get_page(vma->vm_file->f_inode->i_mapping,
+ index);
+
+   if (orig_page) {
+   if (PageUptodate(orig_page) &&
+   pages_identical(new_page, orig_page)) {
+   /* let

[PATCH v10 1/4] mm: move memcmp_pages() and pages_identical()

2019-07-29 Thread Song Liu
This patch moves memcmp_pages() to mm/util.c and pages_identical() to
mm.h, so that we can use them in other files.

Acked-by: Kirill A. Shutemov 
Signed-off-by: Song Liu 
---
 include/linux/mm.h |  7 +++
 mm/ksm.c   | 18 --
 mm/util.c  | 13 +
 3 files changed, 20 insertions(+), 18 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 0334ca97c584..f189176dabed 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2891,5 +2891,12 @@ void __init setup_nr_node_ids(void);
 static inline void setup_nr_node_ids(void) {}
 #endif
 
+extern int memcmp_pages(struct page *page1, struct page *page2);
+
+static inline int pages_identical(struct page *page1, struct page *page2)
+{
+   return !memcmp_pages(page1, page2);
+}
+
 #endif /* __KERNEL__ */
 #endif /* _LINUX_MM_H */
diff --git a/mm/ksm.c b/mm/ksm.c
index 3dc4346411e4..dbee2eb4dd05 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -1029,24 +1029,6 @@ static u32 calc_checksum(struct page *page)
return checksum;
 }
 
-static int memcmp_pages(struct page *page1, struct page *page2)
-{
-   char *addr1, *addr2;
-   int ret;
-
-   addr1 = kmap_atomic(page1);
-   addr2 = kmap_atomic(page2);
-   ret = memcmp(addr1, addr2, PAGE_SIZE);
-   kunmap_atomic(addr2);
-   kunmap_atomic(addr1);
-   return ret;
-}
-
-static inline int pages_identical(struct page *page1, struct page *page2)
-{
-   return !memcmp_pages(page1, page2);
-}
-
 static int write_protect_page(struct vm_area_struct *vma, struct page *page,
  pte_t *orig_pte)
 {
diff --git a/mm/util.c b/mm/util.c
index e6351a80f248..0d5e2f425612 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -783,3 +783,16 @@ int get_cmdline(struct task_struct *task, char *buffer, 
int buflen)
 out:
return res;
 }
+
+int memcmp_pages(struct page *page1, struct page *page2)
+{
+   char *addr1, *addr2;
+   int ret;
+
+   addr1 = kmap_atomic(page1);
+   addr2 = kmap_atomic(page2);
+   ret = memcmp(addr1, addr2, PAGE_SIZE);
+   kunmap_atomic(addr2);
+   kunmap_atomic(addr1);
+   return ret;
+}
-- 
2.17.1



[PATCH v10 3/4] mm, thp: introduce FOLL_SPLIT_PMD

2019-07-29 Thread Song Liu
This patches introduces a new foll_flag: FOLL_SPLIT_PMD. As the name says
FOLL_SPLIT_PMD splits huge pmd for given mm_struct, the underlining huge
page stays as-is.

FOLL_SPLIT_PMD is useful for cases where we need to use regular pages,
but would switch back to huge page and huge pmd on. One of such example
is uprobe. The following patches use FOLL_SPLIT_PMD in uprobe.

Acked-by: Kirill A. Shutemov 
Signed-off-by: Song Liu 
---
 include/linux/mm.h | 1 +
 mm/gup.c   | 8 ++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index f189176dabed..74db879711eb 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2614,6 +2614,7 @@ struct page *follow_page(struct vm_area_struct *vma, 
unsigned long address,
 #define FOLL_COW   0x4000  /* internal GUP flag */
 #define FOLL_ANON  0x8000  /* don't do file mappings */
 #define FOLL_LONGTERM  0x1 /* mapping lifetime is indefinite: see below */
+#define FOLL_SPLIT_PMD 0x2 /* split huge pmd before returning */
 
 /*
  * NOTE on FOLL_LONGTERM:
diff --git a/mm/gup.c b/mm/gup.c
index 98f13ab37bac..3c514e223ce3 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -399,7 +399,7 @@ static struct page *follow_pmd_mask(struct vm_area_struct 
*vma,
spin_unlock(ptl);
return follow_page_pte(vma, address, pmd, flags, &ctx->pgmap);
}
-   if (flags & FOLL_SPLIT) {
+   if (flags & (FOLL_SPLIT | FOLL_SPLIT_PMD)) {
int ret;
page = pmd_page(*pmd);
if (is_huge_zero_page(page)) {
@@ -408,7 +408,7 @@ static struct page *follow_pmd_mask(struct vm_area_struct 
*vma,
split_huge_pmd(vma, pmd, address);
if (pmd_trans_unstable(pmd))
ret = -EBUSY;
-   } else {
+   } else if (flags & FOLL_SPLIT) {
if (unlikely(!try_get_page(page))) {
spin_unlock(ptl);
return ERR_PTR(-ENOMEM);
@@ -420,6 +420,10 @@ static struct page *follow_pmd_mask(struct vm_area_struct 
*vma,
put_page(page);
if (pmd_none(*pmd))
return no_page_table(vma, flags);
+   } else {  /* flags & FOLL_SPLIT_PMD */
+   spin_unlock(ptl);
+   split_huge_pmd(vma, pmd, address);
+   ret = pte_alloc(mm, pmd);
}
 
return ret ? ERR_PTR(ret) :
-- 
2.17.1



[PATCH v10 4/4] uprobe: use FOLL_SPLIT_PMD instead of FOLL_SPLIT

2019-07-29 Thread Song Liu
This patch uses newly added FOLL_SPLIT_PMD in uprobe. This preserves the
huge page when the uprobe is enabled. When the uprobe is disabled, newer
instances of the same application could still benefit from huge page.

For the next step, we will enable khugepaged to regroup the pmd, so that
existing instances of the application could also benefit from huge page
after the uprobe is disabled.

Acked-by: Kirill A. Shutemov 
Reviewed-by: Srikar Dronamraju 
Signed-off-by: Song Liu 
---
 kernel/events/uprobes.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 648f47553bff..27b596f14463 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -155,7 +155,7 @@ static int __replace_page(struct vm_area_struct *vma, 
unsigned long addr,
 {
struct mm_struct *mm = vma->vm_mm;
struct page_vma_mapped_walk pvmw = {
-   .page = old_page,
+   .page = compound_head(old_page),
.vma = vma,
.address = addr,
};
@@ -166,8 +166,6 @@ static int __replace_page(struct vm_area_struct *vma, 
unsigned long addr,
mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, mm, addr,
addr + PAGE_SIZE);
 
-   VM_BUG_ON_PAGE(PageTransHuge(old_page), old_page);
-
if (new_page) {
err = mem_cgroup_try_charge(new_page, vma->vm_mm, GFP_KERNEL,
&memcg, false);
@@ -481,7 +479,7 @@ int uprobe_write_opcode(struct arch_uprobe *auprobe, struct 
mm_struct *mm,
 retry:
/* Read the page with vaddr into memory */
ret = get_user_pages_remote(NULL, mm, vaddr, 1,
-   FOLL_FORCE | FOLL_SPLIT, &old_page, &vma, NULL);
+   FOLL_FORCE | FOLL_SPLIT_PMD, &old_page, &vma, NULL);
if (ret <= 0)
return ret;
 
-- 
2.17.1



[PATCH v10 0/4] THP aware uprobe

2019-07-29 Thread Song Liu
This set makes uprobe aware of THPs.

Currently, when uprobe is attached to text on THP, the page is split by
FOLL_SPLIT. As a result, uprobe eliminates the performance benefit of THP.

This set makes uprobe THP-aware. Instead of FOLL_SPLIT, we introduces
FOLL_SPLIT_PMD, which only split PMD for uprobe.

TODO (temporarily removed in v7+):
After all uprobes within the THP are removed, regroup the PTE-mapped pages
into huge PMD.

This set (plus a few THP patches) is also available at

   https://github.com/liu-song-6/linux/tree/uprobe-thp

Changes v9 => v10:
1. 2/4 incorporate suggestion by Oleg Nesterov.
2. Reword change log of 4/4.

Changes v8 => v9:
1. To replace with orig_page, only unmap old_page. Let the orig_page fault
   in (Oleg Nesterov).

Changes v7 => v8:
1. check PageUptodate() for orig_page (Oleg Nesterov).

Changes v6 => v7:
1. Include Acked-by from Kirill A. Shutemov for the first 4 patches;
2. Keep only the first 4 patches (while I working on improving the last 2).

Changes v5 => v6:
1. Enable khugepaged to collapse pmd for pte-mapped THP
   (Kirill A. Shutemov).
2. uprobe asks khuagepaged to collaspe pmd. (Kirill A. Shutemov)

Note: Theast two patches in v6 the set apply _after_ v7 of set "Enable THP
  for text section of non-shmem files"

Changes v4 => v5:
1. Propagate pte_alloc() error out of follow_pmd_mask().

Changes since v3:
1. Simplify FOLL_SPLIT_PMD case in follow_pmd_mask(), (Kirill A. Shutemov)
2. Fix try_collapse_huge_pmd() to match change in follow_pmd_mask().

Changes since v2:
1. For FOLL_SPLIT_PMD, populated the page table in follow_pmd_mask().
2. Simplify logic in uprobe_write_opcode. (Oleg Nesterov)
3. Fix page refcount handling with FOLL_SPLIT_PMD.
4. Much more testing, together with THP on ext4 and btrfs (sending in
   separate set).
5. Rebased.

Changes since v1:
1. introduces FOLL_SPLIT_PMD, instead of modifying split_huge_pmd*();
2. reuse pages_identical() from ksm.c;
3. rewrite most of try_collapse_huge_pmd().

Song Liu (4):
  mm: move memcmp_pages() and pages_identical()
  uprobe: use original page when all uprobes are removed
  mm, thp: introduce FOLL_SPLIT_PMD
  uprobe: use FOLL_SPLIT_PMD instead of FOLL_SPLIT

 include/linux/mm.h  |  8 +
 kernel/events/uprobes.c | 72 ++---
 mm/gup.c|  8 +++--
 mm/ksm.c| 18 ---
 mm/util.c   | 13 
 5 files changed, 80 insertions(+), 39 deletions(-)

--
2.17.1


[PATCH v2] psi: get poll_work to run when calling poll syscall next time

2019-07-29 Thread Jason Xing
Only when calling the poll syscall the first time can user
receive POLLPRI correctly. After that, user always fails to
acquire the event signal.

Reproduce case:
1. Get the monitor code in Documentation/accounting/psi.txt
2. Run it, and wait for the event triggered.
3. Kill and restart the process.

If the user doesn't kill the monitor process, it seems the
poll_work works fine. After killing and restarting the monitor,
the poll_work in kernel will never run again due to the wrong
value of poll_scheduled. Therefore, we should reset the value
as group_init() does after the last trigger is destroyed.

[PATCH V2]
In the patch v2, I put the atomic_set(&group->poll_scheduled, 0);
into the right place.
Here I quoted from Johannes as the best explaination:
"The question is why we can end up with poll_scheduled = 1 but the work
not running (which would reset it to 0). And the answer is because the
scheduling side sees group->poll_kworker under RCU protection and then
schedules it, but here we cancel the work and destroy the worker. The
cancel needs to pair with resetting the poll_scheduled flag."

Signed-off-by: Jason Xing 
Reviewed-by: Caspar Zhang 
Reviewed-by: Joseph Qi 
Reviewed-by: Suren Baghdasaryan 
Acked-by: Johannes Weiner 
---
 kernel/sched/psi.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c
index 7acc632..acdada0 100644
--- a/kernel/sched/psi.c
+++ b/kernel/sched/psi.c
@@ -1131,7 +1131,14 @@ static void psi_trigger_destroy(struct kref *ref)
 * deadlock while waiting for psi_poll_work to acquire trigger_lock
 */
if (kworker_to_destroy) {
+   /*
+* After the RCU grace period has expired, the worker
+* can no longer be found through group->poll_kworker.
+* But it might have been already scheduled before
+* that - deschedule it cleanly before destroying it.
+*/
kthread_cancel_delayed_work_sync(&group->poll_work);
+   atomic_set(&group->poll_scheduled, 0);
kthread_destroy_worker(kworker_to_destroy);
}
kfree(t);
-- 
1.8.3.1



linux-next: Tree for Jul 30

2019-07-29 Thread Stephen Rothwell
Hi all,

Changes since 20190729:

New tree: fsverity

The keys tree gained a semantic conflict against the fsverity tree for
which I applied a merge fix patch.

Non-merge commits (relative to Linus' tree): 2756
 3095 files changed, 191869 insertions(+), 78406 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 301 trees (counting Linus' and 72 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (2a11c76e5301 Merge tag 'for_linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost)
Merging fixes/master (c309b6f24222 Merge tag 'docs/v5.3-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media)
Merging kbuild-current/fixes (609488bc979f Linux 5.3-rc2)
Merging arc-current/for-curr (24a20b0a443f ARC: [plat-hsdk]: Enable AXI DW DMAC 
in defconfig)
Merging arm-current/fixes (c5d0e49e8d8f ARM: 8867/1: vdso: pass --be8 to linker 
if necessary)
Merging arm-soc-fixes/arm/fixes (7bd9d465140a Merge tag 'imx-fixes-5.3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes)
Merging arm64-fixes/for-next/fixes (eca92a53a6ab arm64: module: Mark expected 
switch fall-through)
Merging m68k-current/for-linus (f28a1f16135c m68k: Don't select 
ARCH_HAS_DMA_PREP_COHERENT for nommu or coldfire)
Merging powerpc-fixes/fixes (609488bc979f Linux 5.3-rc2)
Merging s390-fixes/fixes (8480657280ee vfio-ccw: make vfio_ccw_async_region_ops 
static)
Merging sparc/master (038029c03e21 sparc: remove unneeded uapi/asm/statfs.h)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (7bd6ba4ef4b2 net: hamradio: baycom_epp: Mark expected 
switch fall-through)
Merging bpf/master (5d01ab7bac46 libbpf: fix erroneous multi-closing of BTF FD)
Merging ipsec/master (22d6552f827e xfrm interface: fix management of phydev)
Merging netfilter/master (91826ba13855 netfilter: add include guard to 
xt_connlabel.h)
Merging ipvs/master (58e8b37069ff Merge branch 'net-phy-dp83867-add-some-fixes')
Merging wireless-drivers/master (5f9e832c1370 Linus 5.3-rc1)
Merging mac80211/master (b55f3b841099 mac80211_hwsim: Fix possible null-pointer 
dereferences in hwsim_dump_radio_nl())
Merging rdma-fixes/for-rc (b7165bd0d6cb IB/mlx5: Fix RSS Toeplitz setup to be 
aligned with the HW specification)
Merging sound-current/for-linus (37151a41df80 ALSA: pcm: fix lost wakeup event 
scenarios in snd_pcm_drain)
Merging sound-asoc-fixes/for-linus (3a03327120de Merge branch 'asoc-5.3' into 
asoc-linus)
Merging regmap-fixes/for-linus (5f9e832c1370 Linus 5.3-rc1)
Merging regulator-fixes/for-linus (a853c0a0b013 regulator: lp87565: Fix probe 
failure for "ti,lp87565")
Merging spi-fixes/for-linus (d24f33303ad1 Merge branch 'spi-5.3' into spi-linus)
Merging pci-current/for-linus (5f9e832c1370 Linus 5.3-rc1)
Merging driver-core.current/driver-core-linus (5f9e832c1370 Linus 5.3-rc1)
Merging tty.current/tty-linus (61d51456f357 vt: Grab console_lock around 
con_is_bound in show_bind)
Merging usb.current/usb-linus (609488bc979f Linux 5.3-rc2)
Merging usb-gadget-fixes/fixes (42de8afc40c9 usb: dwc2: Use generic PHY width 
in params setup)
Merging usb-serial-fixes/usb-linus (f8377eff5481 USB: serial: ftdi_sio: add ID 
f

Re: [PATCH net-next 1/2] net: phy: broadcom: set features explicitly for BCM54616S

2019-07-29 Thread Tao Ren
On 7/29/19 8:35 PM, Andrew Lunn wrote:
> On Mon, Jul 29, 2019 at 05:25:32PM -0700, Tao Ren wrote:
>> BCM54616S feature "PHY_GBIT_FEATURES" was removed by commit dcdecdcfe1fc
>> ("net: phy: switch drivers to use dynamic feature detection"). As dynamic
>> feature detection doesn't work when BCM54616S is working in RGMII-Fiber
>> mode (different sets of MII Control/Status registers being used), let's
>> set "PHY_GBIT_FEATURES" for BCM54616S explicitly.
> 
> Hi Tao
> 
> What exactly does it get wrong?
> 
>  Thanks
>   Andrew

Hi Andrew,

BCM54616S is set to RGMII-Fiber (1000Base-X) mode on my platform, and none of 
the features (1000BaseT/100BaseT/10BaseT) can be detected by 
genphy_read_abilities(), because the PHY only reports 1000BaseX_Full|Half 
ability in this mode.


Thanks,

Tao


CVE-2019-13648: Linux kernel: powerpc: kernel crash in TM handling triggerable by any local user

2019-07-29 Thread Michael Neuling
The Linux kernel for powerpc since v3.9 has a bug in the TM handling  where any
unprivileged local user may crash the operating system.

This bug affects machines using 64-bit CPUs where Transactional Memory (TM) is
not present or has been disabled (see below for more details on affected CPUs).

To trigger the bug a process constructs a signal context which still has the MSR
TS bits set. That process then passes this signal context to the sigreturn()
system call. When returning back to userspace, the kernel then crashes with a
bad TM transition (TM Bad Thing) or by executing TM code on a non-TM system.

All 64bit machines where TM is not present are affected. This includes PowerPC
970 (G5), PA6T, POWER5/6/7 VMs under KVM or LPARs under PowerVM and POWER9 bare
metal. 

Additionally systems with TM hardware but where TM is disabled in software (via
ppc_tm=off kernel cmdline) are also affected. This includes POWER8/9 VMs under
KVM or LPARs under PowerVM and POWER8 bare metal.

The bug was introduced in commit:
  2b0a576d15e0 ("powerpc: Add new transactional memory state to the signal 
context")

Which was originally merged in v3.9. 

The upstream fix is here:
  https://git.kernel.org/torvalds/c/f16d80b75a096c52354c6e0a574993f3b0dfbdfe

The fix can be verified by running `sigfuz -m` from the kernel selftests:
 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/powerpc/signal/sigfuz.c?h=v5.2

cheers
Mikey



[PATCH v6 2/8] PCI: Add dev_is_untrusted helper

2019-07-29 Thread Lu Baolu
There are several places in the kernel where it is necessary to
check whether a device is a pci untrusted device. Add a helper
to simplify the callers.

Signed-off-by: Lu Baolu 
Reviewed-by: Christoph Hellwig 
---
 include/linux/pci.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/pci.h b/include/linux/pci.h
index 9e700d9f9f28..960352a75a10 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1029,6 +1029,7 @@ void pcibios_setup_bridge(struct pci_bus *bus, unsigned 
long type);
 void pci_sort_breadthfirst(void);
 #define dev_is_pci(d) ((d)->bus == &pci_bus_type)
 #define dev_is_pf(d) ((dev_is_pci(d) ? to_pci_dev(d)->is_physfn : false))
+#define dev_is_untrusted(d) ((dev_is_pci(d) ? to_pci_dev(d)->untrusted : 
false))
 
 /* Generic PCI functions exported to card drivers */
 
@@ -1766,6 +1767,7 @@ static inline struct pci_dev *pci_dev_get(struct pci_dev 
*dev) { return NULL; }
 
 #define dev_is_pci(d) (false)
 #define dev_is_pf(d) (false)
+#define dev_is_untrusted(d) (false)
 static inline bool pci_acs_enabled(struct pci_dev *pdev, u16 acs_flags)
 { return false; }
 static inline int pci_irqd_intx_xlate(struct irq_domain *d,
-- 
2.17.1



Re: [PATCH net-next 2/2] net: phy: broadcom: add 1000Base-X support for BCM54616S

2019-07-29 Thread Tao Ren
On 7/29/19 6:32 PM, Vladimir Oltean wrote:
> Hi Tao,
> 
> On Tue, 30 Jul 2019 at 03:31, Tao Ren  wrote:
>>
>> Configure the BCM54616S for 1000Base-X mode when "brcm-phy-mode-1000bx"
>> is set in device tree. This is needed when the PHY is used for fiber and
>> backplane connections.
>>
>> The patch is inspired by commit cd9af3dac6d1 ("PHYLIB: Add 1000Base-X
>> support for Broadcom bcm5482").
> 
> As far as I can see, for the commit you referenced,
> PHY_BCM_FLAGS_MODE_1000BX is referenced from nowhere in the entire
> mainline kernel:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__elixir.bootlin.com_linux_latest_ident_PHY-5FBCM-5FFLAGS-5FMODE-5F1000BX&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=iYElT7HC77pRZ3byVvW8ng&m=gy6Y-3Ylme-_GQcGF4fvOX10irgAT4xh253Weo0np38&s=KL__E2bvsmvUL-hBL9hUmOS5vyPQ92EMj6fEfByn8t8&e=
>  
> (it is supposed to be put by the MAC driver in phydev->dev_flags prior
> to calling phy_connect). But I don't see the point to this - can't you
> check for phydev->interface == PHY_INTERFACE_MODE_1000BASEX?
> This has the advantage that no MAC driver will need to know that it's
> talking to a Broadcom PHY. Additionally, no custom DT bindings are
> needed.
> Also, for backplane connections you probably want 1000Base-KX which
> has its own AN/LT, not plain 1000Base-X.

Thank you Vladimir for the quick review!
Perhaps I misunderstood the purpose of phydev->interface, and I thought it was 
usually used to defined the interface between MAC and PHY. For example, if I 
need to pass both "rgmii-id" and "1000base-x" from MAC to PHY driver, what 
would be the preferred way?

>> Signed-off-by: Tao Ren 
>> ---
>>  drivers/net/phy/broadcom.c | 58 +++---
>>  include/linux/brcmphy.h|  4 +--
>>  2 files changed, 56 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
>> index 2b4e41a9d35a..6c22ac3a844b 100644
>> --- a/drivers/net/phy/broadcom.c
>> +++ b/drivers/net/phy/broadcom.c
>> @@ -383,9 +383,9 @@ static int bcm5482_config_init(struct phy_device *phydev)
>> /*
>>  * Select 1000BASE-X register set (primary SerDes)
>>  */
>> -   reg = bcm_phy_read_shadow(phydev, BCM5482_SHD_MODE);
>> -   bcm_phy_write_shadow(phydev, BCM5482_SHD_MODE,
>> -reg | BCM5482_SHD_MODE_1000BX);
>> +   reg = bcm_phy_read_shadow(phydev, BCM54XX_SHD_MODE);
>> +   bcm_phy_write_shadow(phydev, BCM54XX_SHD_MODE,
>> +reg | BCM54XX_SHD_MODE_1000BX);
>>
>> /*
>>  * LED1=ACTIVITYLED, LED3=LINKSPD[2]
>> @@ -451,6 +451,34 @@ static int bcm5481_config_aneg(struct phy_device 
>> *phydev)
>> return ret;
>>  }
>>
>> +static int bcm54616s_config_init(struct phy_device *phydev)
>> +{
>> +   int err, reg;
>> +   struct device_node *np = phydev->mdio.dev.of_node;
>> +
>> +   err = bcm54xx_config_init(phydev);
>> +
>> +   if (of_property_read_bool(np, "brcm-phy-mode-1000bx")) {
>> +   /* Select 1000BASE-X register set. */
>> +   reg = bcm_phy_read_shadow(phydev, BCM54XX_SHD_MODE);
>> +   bcm_phy_write_shadow(phydev, BCM54XX_SHD_MODE,
>> +reg | BCM54XX_SHD_MODE_1000BX);
>> +
>> +   /* Auto-negotiation doesn't seem to work quite right
>> +* in this mode, so we disable it and force it to the
>> +* right speed/duplex setting.  Only 'link status'
>> +* is important.
>> +*/
>> +   phydev->autoneg = AUTONEG_DISABLE;
>> +   phydev->speed = SPEED_1000;
>> +   phydev->duplex = DUPLEX_FULL;
>> +
> 
> 1000Base-X AN does not include speed negotiation, so hardcoding
> SPEED_1000 is probably correct.
> What is wrong with the AN of duplex settings?

FULL_DUPLEX bit is set on my platform by default. Let me enable AN and test it 
out; will share you results tomorrow.

>> +   phydev->dev_flags |= PHY_BCM_FLAGS_MODE_1000BX;
>> +   }
>> +
>> +   return err;
>> +}
>> +
>>  static int bcm54616s_config_aneg(struct phy_device *phydev)
>>  {
>> int ret;
>> @@ -464,6 +492,27 @@ static int bcm54616s_config_aneg(struct phy_device 
>> *phydev)
>> return ret;
>>  }
>>
>> +static int bcm54616s_read_status(struct phy_device *phydev)
>> +{
>> +   int ret;
>> +
>> +   ret = genphy_read_status(phydev);
>> +   if (ret < 0)
>> +   return ret;
>> +
>> +   if (phydev->dev_flags & PHY_BCM_FLAGS_MODE_1000BX) {
>> +   /* Only link status matters for 1000Base-X mode, so force
>> +* 1000 Mbit/s full-duplex status.
>> +*/
>> +   if (phydev->link) {
>> +   phydev->speed = SPEED_1000;
>> +   phydev->duplex = DUPLEX_FULL;
>> +   }
>> +   }
>> 

[PATCH v6 3/8] swiotlb: Split size parameter to map/unmap APIs

2019-07-29 Thread Lu Baolu
This splits the size parameter to swiotlb_tbl_map_single() and
swiotlb_tbl_unmap_single() into an alloc_size and a mapping_size
parameter, where the latter one is rounded up to the iommu page
size.

Suggested-by: Christoph Hellwig 
Signed-off-by: Lu Baolu 
Reviewed-by: Christoph Hellwig 
---
 drivers/xen/swiotlb-xen.c |  8 
 include/linux/swiotlb.h   |  8 ++--
 kernel/dma/direct.c   |  2 +-
 kernel/dma/swiotlb.c  | 30 +++---
 4 files changed, 30 insertions(+), 18 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index cfbe46785a3b..58d25486971e 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -400,8 +400,8 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev, 
struct page *page,
 */
trace_swiotlb_bounced(dev, dev_addr, size, swiotlb_force);
 
-   map = swiotlb_tbl_map_single(dev, start_dma_addr, phys, size, dir,
-attrs);
+   map = swiotlb_tbl_map_single(dev, start_dma_addr, phys,
+size, size, dir, attrs);
if (map == (phys_addr_t)DMA_MAPPING_ERROR)
return DMA_MAPPING_ERROR;
 
@@ -411,7 +411,7 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev, 
struct page *page,
 * Ensure that the address returned is DMA'ble
 */
if (unlikely(!dma_capable(dev, dev_addr, size))) {
-   swiotlb_tbl_unmap_single(dev, map, size, dir,
+   swiotlb_tbl_unmap_single(dev, map, size, size, dir,
attrs | DMA_ATTR_SKIP_CPU_SYNC);
return DMA_MAPPING_ERROR;
}
@@ -447,7 +447,7 @@ static void xen_unmap_single(struct device *hwdev, 
dma_addr_t dev_addr,
 
/* NOTE: We use dev_addr here, not paddr! */
if (is_xen_swiotlb_buffer(dev_addr))
-   swiotlb_tbl_unmap_single(hwdev, paddr, size, dir, attrs);
+   swiotlb_tbl_unmap_single(hwdev, paddr, size, size, dir, attrs);
 }
 
 static void xen_swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr,
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 361f62bb4a8e..cde3dc18e21a 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -46,13 +46,17 @@ enum dma_sync_target {
 
 extern phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
  dma_addr_t tbl_dma_addr,
- phys_addr_t phys, size_t size,
+ phys_addr_t phys,
+ size_t mapping_size,
+ size_t alloc_size,
  enum dma_data_direction dir,
  unsigned long attrs);
 
 extern void swiotlb_tbl_unmap_single(struct device *hwdev,
 phys_addr_t tlb_addr,
-size_t size, enum dma_data_direction dir,
+size_t mapping_size,
+size_t alloc_size,
+enum dma_data_direction dir,
 unsigned long attrs);
 
 extern void swiotlb_tbl_sync_single(struct device *hwdev,
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 59bdceea3737..6c183326c4e6 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -297,7 +297,7 @@ void dma_direct_unmap_page(struct device *dev, dma_addr_t 
addr,
dma_direct_sync_single_for_cpu(dev, addr, size, dir);
 
if (unlikely(is_swiotlb_buffer(phys)))
-   swiotlb_tbl_unmap_single(dev, phys, size, dir, attrs);
+   swiotlb_tbl_unmap_single(dev, phys, size, size, dir, attrs);
 }
 EXPORT_SYMBOL(dma_direct_unmap_page);
 
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 9de232229063..89066efa3840 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -444,7 +444,9 @@ static void swiotlb_bounce(phys_addr_t orig_addr, 
phys_addr_t tlb_addr,
 
 phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
   dma_addr_t tbl_dma_addr,
-  phys_addr_t orig_addr, size_t size,
+  phys_addr_t orig_addr,
+  size_t mapping_size,
+  size_t alloc_size,
   enum dma_data_direction dir,
   unsigned long attrs)
 {
@@ -464,6 +466,9 @@ phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
pr_warn_once("%s is active and system is using DMA bounce 
buffers\n",
 sme_active() ? "SME" : "SEV");
 
+   if (WARN_ON(mapping_size > alloc_size))
+   return (phys_addr_t)DMA_MAPPING_ERROR;
+
mask = dma_get_seg_boundary(hwdev);
 

Re: [PATCH 0/4] new driver for TI eQEP

2019-07-29 Thread William Breathitt Gray
On Thu, Jul 25, 2019 at 05:52:21PM -0500, David Lechner wrote:
> On 7/25/19 7:40 AM, William Breathitt Gray wrote:
> > On Mon, Jul 22, 2019 at 10:45:34AM -0500, David Lechner wrote:
> >> This series adds device tree bindings and a new counter driver for the 
> >> Texas
> >> Instruments Enhanced Quadrature Encoder Pulse (eQEP).
> >>
> >> As mentioned in one of the commit messages, to start with, the driver only
> >> supports reading the current counter value and setting the min/max values.
> >> Other features can be added on an as-needed basis.
> >>
> >> The only other feature I am interested in is adding is getting time data in
> >> order to calculate the rotational speed of a motor. However, there probably
> >> needs to be a higher level discussion of how this can fit into the counter
> >> subsystem in general first.
> > 
> > I believe exposing some sort of time data has merit. Quadrature counter
> > devices in particular are commonly used for position tracking of
> > automation systems, and such systems would benefit from velocity/speed
> > information. So let's try to introduce that sort of functionality in this
> > driver if possible.
> > 
> > First, let's discuss your specific use case and requirements, and hopefully 
> > we
> > can generalize it enough to be of use for future drivers. From your 
> > description,
> > it sounds like you're attaching some sort of rotary encoder to the eQEP 
> > device.
> > Is that correct? What sort of time data are you hoping to use; does the eQEP
> > device provide a clock value, or would you be grabbing a timestamp from the
> > system?
> 
> My use case is robotics using LEGO MINDSTORMS. More specifically, I am using
> motors that have a cheap optical rotary encoder (plastic wheel and infrared
> LED/detectors) that give 360 counts per 1 rotation of the motor shaft. One 
> count
> is defined as the rising edge or falling edge of the A signal. We are looking 
> at
> anywhere from 0 to around 2000 counts per second. We use the speed as 
> feedback in
> a control algorithm to drive the motor at a constant speed. The control loop
> updates on the order of 1 to 10 ms.
> 
> Because the encoder resolution and speeds are relatively low, we are currently
> logging a timestamp for each count. If no count occurs for 50ms, then we log 
> the
> same count again with a new timestamp (otherwise we would never see 0 speed). 
> To
> get the actual speed, we find the first timestamp > 20 ms before the current
> timestamp then compute the speed as the change in position divided by the 
> change
> in time between these two samples. This give a fairly accurate speed across 
> most
> of the range, but does get a bit noisy once we get below 100 counts per 
> second.
> It also means that we need a ring buffer that holds about 50 samples.
> 
> The timestamp itself comes from the eQEP, not the system. There are latching
> registers to ensure that the timestamp read is from exactly the moment when
> the count register was read.

So if I understand correctly, there are two registers you're reading: a
count register and a timestamp register. The count register is updated
by the rotation of the motor shaft, while the timestamp register is
updated by reading the count register (thus logging the time associated
with the read count value).

> > I'm not sure yet if it would make sense to expose rotational speed directly 
> > as
> > an attribute. If we were to expose just the count value and timestamp since 
> > the
> > last read, that should be enough for a user to compute the delta and derive
> > speed. I'll think more about this since some devices may simplify that case 
> > if
> > the hardware is able to compute the speed for us.
> > 
> 
> I agree that it probably doesn't make sense to expect drivers to compute the
> speed. There isn't really a general way to do that works for an arbitrary
> speed. For example at high speeds, it is better to just look at the change
> in counts over a fixed interval rather than triggering a timestamp based on
> a certain number of counts.

This is a good point. Depending on the resolution the user cares about,
they may be more interested in the speed over a short time interval
versus a long time interval. It doesn't seem practical to have the driver
try to handle all possible speed calculations when the user can decide
themselves how best to use the data.

> I also don't think having a timestamp sysfs attribute would be very useful.
> To make it work at all, I think it would have to be implemented such that
> it returns the timestamp for the count that was most recently read via sysfs.
> And it would require 4 syscalls (2 seeks and 2 reads) to get a single count/
> timestamp pair in a control loop. On a 300MHz ARM9 processor, this is not
> a negligible amount of time.

This is a concern I've had as well. The sysfs interface is useful in
that it provides an intuitive and human-friendly way to expose data
about devices. But as you note, there is considerable overhead i

Re: [PATCH] drivers/macintosh/smu.c: Mark expected switch fall-through

2019-07-29 Thread Stephen Rothwell
Hi all,

On Tue, 30 Jul 2019 14:37:04 +1000 Stephen Rothwell  
wrote:
>
> Mark switch cases where we are expecting to fall through.
> 
> This patch fixes the following warning (Building: powerpc):
> 
> drivers/macintosh/smu.c: In function 'smu_queue_i2c':
> drivers/macintosh/smu.c:854:21: warning: this statement may fall through 
> [-Wimplicit-fallthrough=]
>cmd->info.devaddr &= 0xfe;
>~~^~~
> drivers/macintosh/smu.c:855:2: note: here
>   case SMU_I2C_TRANSFER_STDSUB:
>   ^~~~
> 
> Cc: Benjamin Herrenschmidt 
> Cc: Gustavo A. R. Silva 
> Cc: Kees Cook 
> Signed-off-by: Stephen Rothwell 

Fixes: 0365ba7fb1fa ("[PATCH] ppc64: SMU driver update & i2c support")

Sorry, forgot :-)
-- 
Cheers,
Stephen Rothwell


pgpuPJJXElTz1.pgp
Description: OpenPGP digital signature


[RFC PATCH] ARM: zynq: Use memcpy_toio instead of memcpy on smp bring-up

2019-07-29 Thread Luis Araneda
This fixes a kernel panic (read overflow) on memcpy when
FORTIFY_SOURCE is enabled.

The computed size of memcpy args are:
- p_size (dst): 4294967295 = (size_t) -1
- q_size (src): 1
- size (len): 8

Additionally, the memory is marked as __iomem, so one of
the memcpy_* functions should be used for read/write

Signed-off-by: Luis Araneda 
---

For anyone trying to reproduce / debug this, it panics
before the console has any output.
I used JTAG to find the panic, but I had to comment-out
the call to "zynq_slcr_cpu_stop" as it stops the JTAG
interface and the connection is dropped, at least with OpenOCD.

I run-tested this on a Digilent Zybo Z7 board
---
 arch/arm/mach-zynq/platsmp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-zynq/platsmp.c b/arch/arm/mach-zynq/platsmp.c
index a7cfe07156f4..407abade7336 100644
--- a/arch/arm/mach-zynq/platsmp.c
+++ b/arch/arm/mach-zynq/platsmp.c
@@ -57,7 +57,7 @@ int zynq_cpun_start(u32 address, int cpu)
* 0x4: Jump by mov instruction
* 0x8: Jumping address
*/
-   memcpy((__force void *)zero, &zynq_secondary_trampoline,
+   memcpy_toio(zero, &zynq_secondary_trampoline,
trampoline_size);
writel(address, zero + trampoline_size);
 
-- 
2.22.0



[PATCH] drivers/macintosh/smu.c: Mark expected switch fall-through

2019-07-29 Thread Stephen Rothwell
Mark switch cases where we are expecting to fall through.

This patch fixes the following warning (Building: powerpc):

drivers/macintosh/smu.c: In function 'smu_queue_i2c':
drivers/macintosh/smu.c:854:21: warning: this statement may fall through 
[-Wimplicit-fallthrough=]
   cmd->info.devaddr &= 0xfe;
   ~~^~~
drivers/macintosh/smu.c:855:2: note: here
  case SMU_I2C_TRANSFER_STDSUB:
  ^~~~

Cc: Benjamin Herrenschmidt 
Cc: Gustavo A. R. Silva 
Cc: Kees Cook 
Signed-off-by: Stephen Rothwell 
---
 drivers/macintosh/smu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/macintosh/smu.c b/drivers/macintosh/smu.c
index 276065c888bc..23f1f41c8602 100644
--- a/drivers/macintosh/smu.c
+++ b/drivers/macintosh/smu.c
@@ -852,6 +852,7 @@ int smu_queue_i2c(struct smu_i2c_cmd *cmd)
break;
case SMU_I2C_TRANSFER_COMBINED:
cmd->info.devaddr &= 0xfe;
+   /* fall through */
case SMU_I2C_TRANSFER_STDSUB:
if (cmd->info.sublen > 3)
return -EINVAL;
-- 
2.22.0

-- 
Cheers,
Stephen Rothwell


pgp4mRaHpufRH.pgp
Description: OpenPGP digital signature


Re: [PATCH 19/20] pstore: fs superblock limits

2019-07-29 Thread Kees Cook
On Mon, Jul 29, 2019 at 06:49:23PM -0700, Deepa Dinamani wrote:
> Also update the gran since pstore has microsecond granularity.

So, I'm fine with this, but technically the granularity depends on the
backend storage... many have no actual time keeping, though. My point is,
pstore's timestamps are really mostly a lie, but the most common backend
(ramoops) is seconds-granularity.

So, I'm fine with this, but it's a lie but it's a lie that doesn't
matter, so ...

Acked-by: Kees Cook 

I'm open to suggestions to improve it...

-Kees

> 
> Signed-off-by: Deepa Dinamani 
> Cc: an...@enomsg.org
> Cc: ccr...@android.com
> Cc: keesc...@chromium.org
> Cc: tony.l...@intel.com
> ---
>  fs/pstore/inode.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
> index 89a80b568a17..ee752f9fda57 100644
> --- a/fs/pstore/inode.c
> +++ b/fs/pstore/inode.c
> @@ -388,7 +388,9 @@ static int pstore_fill_super(struct super_block *sb, void 
> *data, int silent)
>   sb->s_blocksize_bits= PAGE_SHIFT;
>   sb->s_magic = PSTOREFS_MAGIC;
>   sb->s_op= &pstore_ops;
> - sb->s_time_gran = 1;
> + sb->s_time_gran = NSEC_PER_USEC;
> + sb->s_time_min  = S64_MIN;
> + sb->s_time_max  = S64_MAX;
>  
>   parse_options(data);
>  
> -- 
> 2.17.1
> 

-- 
Kees Cook


Re: [PATCH v2] libata: zpodd: Fix small read overflow in zpodd_get_mech_type()

2019-07-29 Thread Kees Cook
On Mon, Jul 29, 2019 at 04:00:08PM -0600, Jens Axboe wrote:
> On 7/29/19 3:58 PM, Nick Desaulniers wrote:
> > On Mon, Jul 29, 2019 at 2:55 PM Jens Axboe  wrote:
> >>
> >> On 7/29/19 3:47 PM, Kees Cook wrote:
> >>> Jeffrin reported a KASAN issue:
> >>>
> >>> BUG: KASAN: global-out-of-bounds in ata_exec_internal_sg+0x50f/0xc70
> >>> Read of size 16 at addr 91f41f80 by task scsi_eh_1/149
> >>> ...
> >>> The buggy address belongs to the variable:
> >>>   cdb.48319+0x0/0x40
> >>>
> >>> Much like commit 18c9a99bce2a ("libata: zpodd: small read overflow in
> >>> eject_tray()"), this fixes a cdb[] buffer length, this time in
> >>> zpodd_get_mech_type():
> >>>
> >>> We read from the cdb[] buffer in ata_exec_internal_sg(). It has to be
> >>> ATAPI_CDB_LEN (16) bytes long, but this buffer is only 12 bytes.
> >>
> >> Applied, thanks.
> > 
> > Dropped my reviewed by tag. :(
> > https://lkml.org/lkml/2019/7/22/865

Argh, sorry!

> I'll add it.

Thanks! :)

-- 
Kees Cook


Re: [PATCH] Revision of pc87413_wdt driver to use watchdog subsystem

2019-07-29 Thread Guenter Roeck

On 7/29/19 8:50 PM, Mark Balantzyan wrote:

This patch rewrites the pc87413_wdt driver to use the watchdog subsystem. In
doing so, it also addresses a potential race condition owing from the
swc_base_addr variable being used before being set.

Signed-off-by: Mark Balantzyan 



"Revision of ..." is an odd subject line. Also, please start the subject line 
with
"watchdog: pc87413: ".


---
  drivers/watchdog/Kconfig   |   1 +
  drivers/watchdog/pc87413_wdt.c | 294 +
  2 files changed, 39 insertions(+), 256 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 9af07fd9..84a7326d 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1166,6 +1166,7 @@ config SCx200_WDT
  
  config PC87413_WDT

tristate "NS PC87413 watchdog"
+   select WATCHDOG_CORE
depends on X86
---help---
  This is the driver for the hardware watchdog on the PC87413 chipset
diff --git a/drivers/watchdog/pc87413_wdt.c b/drivers/watchdog/pc87413_wdt.c
index 06a892e3..d1d32771 100644
--- a/drivers/watchdog/pc87413_wdt.c
+++ b/drivers/watchdog/pc87413_wdt.c
@@ -22,12 +22,10 @@
  
  #include 

  #include 
-#include 
  #include 
  #include 
  #include 


Is this used anywhere ?


  #include 
-#include 
  #include 


notifier.h and reboot.h should not be needed if the code is changed
to use watchdog_stop_on_reboot().


  #include 
  #include 


No longer needed.


@@ -65,7 +63,6 @@ static char expect_close; /* is the close 
expected? */
  
  static DEFINE_SPINLOCK(io_lock);	/* to guard us from io races */
  

No longer needed.


-static bool nowayout = WATCHDOG_NOWAYOUT;
  
  /* -- Low level function */
  
@@ -216,41 +213,32 @@ static inline void pc87413_disable_sw_wd_trg(void)
  
  /* -- Higher level functions */
  
-/* Enable the watchdog */

+/* Enable/start the watchdog */
  
-static void pc87413_enable(void)

+static void pc87413_start(void)


I am quite sure you still see a warning here, or rather where the function is 
referenced.


  {
-   spin_lock(&io_lock);
-
pc87413_swc_bank3();
pc87413_programm_wdto(timeout);
pc87413_enable_wden();
pc87413_enable_sw_wd_tren();
pc87413_enable_sw_wd_trg();
  
-	spin_unlock(&io_lock);

  }
  
-/* Disable the watchdog */

+/* Disable/stop the watchdog */
  
-static void pc87413_disable(void)

+static void pc87413_stop(void)


Same here.


  {
-   spin_lock(&io_lock);
-
pc87413_swc_bank3();
pc87413_disable_sw_wd_tren();
pc87413_disable_sw_wd_trg();
pc87413_programm_wdto(0);
-
-   spin_unlock(&io_lock);
  }
  
-/* Refresh the watchdog */

+/* Refresh/keepalive the watchdog */
  
-static void pc87413_refresh(void)

+static void pc87413_keepalive(struct watchdog_device *wdd)
  {
-   spin_lock(&io_lock);
-
pc87413_swc_bank3();
pc87413_disable_sw_wd_tren();
pc87413_disable_sw_wd_trg();
@@ -258,195 +246,11 @@ static void pc87413_refresh(void)
pc87413_enable_wden();
pc87413_enable_sw_wd_tren();
pc87413_enable_sw_wd_trg();
-
-   spin_unlock(&io_lock);
-}
-
-/* -- File operations ---*/
-
-/**
- * pc87413_open:
- * @inode: inode of device
- * @file: file handle to device
- *
- */
-
-static int pc87413_open(struct inode *inode, struct file *file)
-{
-   /* /dev/watchdog can only be opened once */
-
-   if (test_and_set_bit(0, &timer_enabled))
-   return -EBUSY;
-
-   if (nowayout)
-   __module_get(THIS_MODULE);
-
-   /* Reload and activate timer */
-   pc87413_refresh();
-
-   pr_info("Watchdog enabled. Timeout set to %d minute(s).\n", timeout);
-
-   return nonseekable_open(inode, file);
-}
-
-/**
- * pc87413_release:
- * @inode: inode to board
- * @file: file handle to board
- *
- * The watchdog has a configurable API. There is a religious dispute
- * between people who want their watchdog to be able to shut down and
- * those who want to be sure if the watchdog manager dies the machine
- * reboots. In the former case we disable the counters, in the latter
- * case you have to open it again very soon.
- */
-
-static int pc87413_release(struct inode *inode, struct file *file)
-{
-   /* Shut off the timer. */
-
-   if (expect_close == 42) {
-   pc87413_disable();
-   pr_info("Watchdog disabled, sleeping again...\n");
-   } else {
-   pr_crit("Unexpected close, not stopping watchdog!\n");
-   pc87413_refresh();
-   }
-   clear_bit(0, &timer_enabled);
-   expect_close = 0;
return 0;
  }
  
-/**

- * pc87413_status:
- *
- *  return, if the watchdog is enabled (timeout is set...)
- */
-
-
-static int pc87413_status(void)
-{
- return 0; /* currently n

Re: [PATCH 01/12] rdmacg: Replace strncmp with str_has_prefix

2019-07-29 Thread Kees Cook
On Mon, Jul 29, 2019 at 11:13:46PM +0800, Chuhong Yuan wrote:
> strncmp(str, const, len) is error-prone.
> We had better use newly introduced
> str_has_prefix() instead of it.

Wait, stop. :) After Laura called my attention to your conversion series,
mpe pointed out that str_has_prefix() is almost redundant to strstarts()
(from 2009), and the latter has many more users. Let's fix strstarts()
match str_has_prefix()'s return behavior (all the existing callers are
doing boolean tests, so the change in return value won't matter), and
then we can continue with this replacement. (And add some documentation
to Documenation/process/deprecated.rst along with a checkpatch.pl test
maybe too?)

Actually I'd focus first on the actually broken cases first (sizeof()
without the "-1", etc):

$ git grep strncmp.*sizeof | grep -v -- '-' | wc -l
17

I expect the "copy/paste" changes could just be a Coccinelle script that
Linus could run to fix all the cases (and should be added to the kernel
source's list of Coccinelle scripts). Especially since the bulk of the
usage pattern are doing literals like this:

arch/alpha/kernel/setup.c:   if (strncmp(p, "mem=", 4) == 0) {

$ git grep -E 'strncmp.*(sizeof|, *[0-9]*)' | wc -l
2565

And some cases are weirdly backwards:

tools/perf/util/callchain.c:  if (!strncmp(tok, "none", strlen(tok))) {

-Kees

> Signed-off-by: Chuhong Yuan 
> ---
>  kernel/cgroup/rdma.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/cgroup/rdma.c b/kernel/cgroup/rdma.c
> index ae042c347c64..fd12a227f8e4 100644
> --- a/kernel/cgroup/rdma.c
> +++ b/kernel/cgroup/rdma.c
> @@ -379,7 +379,7 @@ static int parse_resource(char *c, int *intval)
>   return -EINVAL;
>   return i;
>   }
> - if (strncmp(value, RDMACG_MAX_STR, len) == 0) {
> + if (str_has_prefix(value, RDMACG_MAX_STR)) {
>   *intval = S32_MAX;
>   return i;
>   }
> -- 
> 2.20.1
> 

-- 
Kees Cook


Re: [PATCH] tracing: Prevent RCU EQS breakage in preemptirq events

2019-07-29 Thread Joel Fernandes
On Mon, Jul 29, 2019 at 10:15 PM Steven Rostedt  wrote:
[snip]
> > If the problem was only with userstacktrace, it will be reasonable to
> > surround only the userstack unwinder. But the situation is similar to
> > the previous "tracing vs CR2" case. As Peter taught me in
> > https://lore.kernel.org/lkml/20190708074823.gv3...@hirez.programming.kicks-ass.net/
> > there are some other codes likely to to user access.
> > So I surround preemptirq events earlier.
>
> I disagree. The issue is with the attached callbacks that call
> something (a stack unwinder) that can fault.
>
> This is called whenever irqs are disabled. I say we surround the
> culprit (the stack unwinder or stack trace) and not punish the irq
> enable/disable events.

I agree with everything Steve said.

thanks,

 - Joel


REPLY URGENT PLS.

2019-07-29 Thread Dr.James Kabore
Dear friend,

Greetings to you, I got your contact through International business
directory, my names are Hon.Dr. James Kabore from Burkina Faso, West
Africa. I am a politician with government position. am pleased to
contact you for your assistance to help me invest in real estate or
any provitable sector in your country through you as my partner and as
a citizen of your country.

I am eager to visit in person with you and of course provide more
details, once you reply and promise to assist. Because I am aware that
most of well connected people very rarely use this means of approach
via inter-net, for a huge business of this size due to scam syndicates
out there.

Waiting for your urgent respond.

Best regards,
Dr.James Kabore.


Re: [PATCH 0/3] Add IMX290 CMOS image sensor support

2019-07-29 Thread Manivannan Sadhasivam
On Thu, Jul 04, 2019 at 12:32:27AM +0530, Manivannan Sadhasivam wrote:
> Hello,
> 
> This patchset adds support for IMX290 CMOS image sensor from Sony.
> Sensor can be programmed through I2C and 4-wire interface but the
> current driver only supports I2C interface. Also, the sensor is
> capable of outputting frames in following 3 interfaces:
> 
> * CMOS logic parallel SDR output
> * Low voltage LVDS serial DDR output
> * CSI-2 serial data output
> 
> But the current driver only supports CSI-2 output available from 4 lanes.
> In the case of sensor resolution, driver only supports 1920x1080 and
> 1280x720 at mid data rate of 445.5 Mpbs.
> 
> The driver has been validated using Framos IMX290 module interfaced to
> 96Boards Dragonboard410c.
> 

Ping on the patchset!

Thanks,
Mani

> Thanks,
> Mani
> 
> Manivannan Sadhasivam (3):
>   dt-bindings: media: i2c: Add IMX290 CMOS sensor binding
>   media: i2c: Add IMX290 CMOS image sensor driver
>   MAINTAINERS: Add entry for IMX290 CMOS image sensor driver
> 
>  .../devicetree/bindings/media/i2c/imx290.txt  |  51 ++
>  MAINTAINERS   |   8 +
>  drivers/media/i2c/Kconfig |  11 +
>  drivers/media/i2c/Makefile|   1 +
>  drivers/media/i2c/imx290.c| 845 ++
>  5 files changed, 916 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/imx290.txt
>  create mode 100644 drivers/media/i2c/imx290.c
> 
> -- 
> 2.17.1
> 


Re: [PATCH 1/1] power: supply: sbs-battery: Add ability to force load a battery via the devicetree

2019-07-29 Thread Guenter Roeck
On Mon, Jul 29, 2019 at 8:02 PM Richard Tresidder
 wrote:
>
> Hi Nick and Guenter
> Just adding you to this one also seeing as you're looking at that other
> sbs_battery patch for me.
> Not sure why the get maintainers didn't list you for this one.
>
> Cheers
> Richard Tresidder
> > Add the ability to force load a hot pluggable battery during boot where
> > there is no gpio detect method available and the module is statically
> > built. Normal polling will then occur on that battery when it is inserted.
> >
> > Signed-off-by: Richard Tresidder 
> > ---
> >
> > Notes:
> >  Add the ability to force load a hot pluggable battery during boot where
> >  there is no gpio detect method available and the module is statically
> >  built. Normal polling will then occur on that battery when it is 
> > inserted.
> >
> >   drivers/power/supply/sbs-battery.c | 6 +-
> >   1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/power/supply/sbs-battery.c 
> > b/drivers/power/supply/sbs-battery.c
> > index 048d205..ea8ba3e 100644
> > --- a/drivers/power/supply/sbs-battery.c
> > +++ b/drivers/power/supply/sbs-battery.c
> > @@ -161,6 +161,7 @@ struct sbs_info {
> >   int poll_time;
> >   u32 i2c_retry_count;
> >   u32 poll_retry_count;
> > + boolforce_load;
> >   struct delayed_work work;
> >   struct mutexmode_lock;
> >   u32 flags;
> > @@ -852,6 +853,9 @@ static int sbs_probe(struct i2c_client *client,
> >   if (rc)
> >   chip->poll_retry_count = 0;
> >
> > + chip->force_load = of_property_read_bool(client->dev.of_node,
> > + "sbs,force-load");
> > +

Maybe it is documented in another patch, which I have not seen. If it
isn't, it will have to be documented and reviewed by a devicetree
maintainer. Either case, I don't immediately see why the variable
needs to reside in struct sbs_info; it seems to be used only in the
probe function.

> >   if (pdata) {
> >   chip->poll_retry_count = pdata->poll_retry_count;
> >   chip->i2c_retry_count  = pdata->i2c_retry_count;
> > @@ -890,7 +894,7 @@ static int sbs_probe(struct i2c_client *client,
> >* Before we register, we might need to make sure we can actually talk
> >* to the battery.
> >*/
> > - if (!(force_load || chip->gpio_detect)) {
> > + if (!(force_load || chip->gpio_detect || chip->force_load)) {
> >   rc = sbs_read_word_data(client, sbs_data[REG_STATUS].addr);
> >
> >   if (rc < 0) {
>


Re: [RFC] net: phy: read link status twice when phy_check_link_status()

2019-07-29 Thread liuyonglong



On 2019/7/30 4:57, Heiner Kallweit wrote:
> On 29.07.2019 05:59, liuyonglong wrote:
>>
>>
>> On 2019/7/27 2:14, Heiner Kallweit wrote:
>>> On 26.07.2019 11:53, Yonglong Liu wrote:
 According to the datasheet of Marvell phy and Realtek phy, the
 copper link status should read twice, or it may get a fake link
 up status, and cause up->down->up at the first time when link up.
 This happens more oftem at Realtek phy.

>>> This is not correct, there is no fake link up status.
>>> Read the comment in genphy_update_link, only link-down events
>>> are latched. Means if the first read returns link up, then there
>>> is no need for a second read. And in polling mode we don't do a
>>> second read because we want to detect also short link drops.
>>>
>>> It would be helpful if you could describe your actual problem
>>> and whether you use polling or interrupt mode.
>>>
>>
>> [   44.498633] hns3 :bd:00.1 eth5: net open
>> [   44.504273] hns3 :bd:00.1: reg=0x1, data=0x79ad -> called from 
>> phy_start_aneg
>> [   44.532348] hns3 :bd:00.1: reg=0x1, data=0x798d -> called from 
>> phy_state_machine,update link.
> 
> This should not happen. The PHY indicates link up w/o having aneg finished.
> 
>>
>> According to the datasheet:
>> reg 1.5=0 now, means copper auto-negotiation not complete
>> reg 1.2=1 now, means link is up
>>
>> We can see that, when we read the link up, the auto-negotiation
>> is not complete yet, so the speed is invalid.
>>
>> I don't know why this happen, maybe this state is keep from bios?
>> Or we may do something else in the phy initialize to fix it?
>> And also confuse that why read twice can fix it?
>>
> I suppose that basically any delay would do.
> 
>> [   44.554063] hns3 :bd:00.1: invalid speed (-1)
>> [   44.560412] hns3 :bd:00.1 eth5: failed to adjust link.
>> [   45.194870] hns3 :bd:00.1 eth5: link up
>> [   45.574095] hns3 :bd:00.1: phyid=3, reg=0x1, data=0x7989
>> [   46.150051] hns3 :bd:00.1 eth5: link down
>> [   46.598074] hns3 :bd:00.1: phyid=3, reg=0x1, data=0x7989
>> [   47.622075] hns3 :bd:00.1: phyid=3, reg=0x1, data=0x79a9
>> [   48.646077] hns3 :bd:00.1: phyid=3, reg=0x1, data=0x79ad
>> [   48.934050] hns3 :bd:00.1 eth5: link up
>> [   49.702140] hns3 :bd:00.1: phyid=3, reg=0x1, data=0x79ad
>>
 I add a fake status read, and can solve this problem.

 I also see that in genphy_update_link(), had delete the fake
 read in polling mode, so I don't know whether my solution is
 correct.

> 
> Can you test whether the following fixes the issue for you?
> Also it would be interesting which exact PHY models you tested
> and whether you built the respective PHY drivers or whether you
> rely on the genphy driver. Best use the second patch to get the
> needed info. It may make sense anyway to add the call to
> phy_attached_info() to the hns3 driver.
> 

[   40.100716] RTL8211F Gigabit Ethernet mii-:bd:00.3:07: attached PHY 
driver [RTL8211F Gigabit Ethernet] (mii_bus:phy_addr=mii-:bd:00.3:07, 
irq=POLL)
[   40.932133] hns3 :bd:00.3 eth7: net open
[   40.932458] hns3 :bd:00.3: invalid speed (-1)
[   40.932541] 8021q: adding VLAN 0 to HW filter on device eth7
[   40.937149] hns3 :bd:00.3 eth7: failed to adjust link.

[   40.662050] Generic PHY mii-:bd:00.2:05: attached PHY driver [Generic 
PHY] (mii_bus:phy_addr=mii-:bd:00.2:05, irq=POLL)
[   41.563511] hns3 :bd:00.2 eth6: net open
[   41.563853] hns3 :bd:00.2: invalid speed (-1)
[   41.563943] 8021q: adding VLAN 0 to HW filter on device eth6
[   41.568578] IPv6: ADDRCONF(NETDEV_CHANGE): eth6: link becomes ready
[   41.568898] hns3 :bd:00.2 eth6: failed to adjust link.

I am using RTL8211F, but you can see that, both genphy driver and
RTL8211F driver have the same issue.

> 
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 6b5cb87f3..fbecfe210 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -1807,7 +1807,8 @@ int genphy_read_status(struct phy_device *phydev)
>  
>   linkmode_zero(phydev->lp_advertising);
>  
> - if (phydev->autoneg == AUTONEG_ENABLE && phydev->autoneg_complete) {
> + if (phydev->autoneg == AUTONEG_ENABLE &&
> + (phydev->autoneg_complete || phydev->link)) {
>   if (phydev->is_gigabit_capable) {
>   lpagb = phy_read(phydev, MII_STAT1000);
>   if (lpagb < 0)
> 

I have try this patch, have no effect. I suppose that at this time,
the autoneg actually not complete yet.

Maybe the wrong phy state is passed from bios? Invalid speed just
happen at the first time when ethX up, after that, repeat the
ifconfig down/ifconfig up command can not see that again.

So I think the bios should power off the phy(writing reg 1.11 to 1)
before it starts the OS? Or any other way to fix this in the OS?





Re: [PATCH V14 13/13] PCI: tegra: Add Tegra194 PCIe support

2019-07-29 Thread Vidya Sagar

On 7/24/2019 11:18 PM, Vidya Sagar wrote:

Bjorn / Lorenzo,
Can you please review this change?

Thanks,
Vidya Sagar


Add support for Synopsys DesignWare core IP based PCIe host controller
present in Tegra194 SoC.

Signed-off-by: Vidya Sagar 
Acked-by: Thierry Reding 
---
V14:
* Addressed Lorenzo's review comments
* Removed unused header files
* Gathered all ASPM related programming under one define
* Refactored tegra_pcie_dw_host_init() API to avoid using upward goto statement
* Started using dw_pcie_wait_for_link() API for link up check
* Modified condition to call tegra_bpmp_transfer_atomic()/tegra_bpmp_transfer() 
APIs

V13:
* Modified according to modifications in PATCH V13 01/12

V12:
* None

V11:
* None

V10:
* Used _relaxed() versions of readl() & writel()

V9:
* Made it dependent on ARCH_TEGRA_194_SOC directly

V8:
* Addressed review comments from Thierry

V7:
* Removed code around "nvidia,disable-aspm-states" DT property
* Refactored code to remove code duplication

V6:
* Addressed review comments from Thierry

V5:
* None

V4:
* None

V3:
* Changed 'nvidia,init-speed' to 'nvidia,init-link-speed'
* Changed 'nvidia,pex-wake' to 'nvidia,wake-gpios'
* Removed .runtime_suspend() & .runtime_resume() implementations

V2:
* Made CONFIG_PCIE_TEGRA194 as 'm' by default from its previous 'y' state
* Modified code as per changes made to DT documentation
* Refactored code to address Bjorn & Thierry's review comments
* Added goto to avoid recursion in tegra_pcie_dw_host_init() API
* Merged .scan_bus() of dw_pcie_host_ops implementation to 
tegra_pcie_dw_host_init() API

  drivers/pci/controller/dwc/Kconfig |   10 +
  drivers/pci/controller/dwc/Makefile|1 +
  drivers/pci/controller/dwc/pcie-tegra194.c | 1630 
  3 files changed, 1641 insertions(+)
  create mode 100644 drivers/pci/controller/dwc/pcie-tegra194.c

diff --git a/drivers/pci/controller/dwc/Kconfig 
b/drivers/pci/controller/dwc/Kconfig
index 6ea778ae4877..49475f5c42c3 100644
--- a/drivers/pci/controller/dwc/Kconfig
+++ b/drivers/pci/controller/dwc/Kconfig
@@ -220,6 +220,16 @@ config PCI_MESON
  and therefore the driver re-uses the DesignWare core functions to
  implement the driver.
  
+config PCIE_TEGRA194

+   tristate "NVIDIA Tegra194 (and later) PCIe controller"
+   depends on ARCH_TEGRA_194_SOC || COMPILE_TEST
+   depends on PCI_MSI_IRQ_DOMAIN
+   select PCIE_DW_HOST
+   select PHY_TEGRA194_P2U
+   help
+ Say Y here if you want support for DesignWare core based PCIe host
+ controller found in NVIDIA Tegra194 SoC.
+
  config PCIE_UNIPHIER
bool "Socionext UniPhier PCIe controllers"
depends on ARCH_UNIPHIER || COMPILE_TEST
diff --git a/drivers/pci/controller/dwc/Makefile 
b/drivers/pci/controller/dwc/Makefile
index b085dfd4fab7..b30336181d46 100644
--- a/drivers/pci/controller/dwc/Makefile
+++ b/drivers/pci/controller/dwc/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o
  obj-$(CONFIG_PCIE_KIRIN) += pcie-kirin.o
  obj-$(CONFIG_PCIE_HISI_STB) += pcie-histb.o
  obj-$(CONFIG_PCI_MESON) += pci-meson.o
+obj-$(CONFIG_PCIE_TEGRA194) += pcie-tegra194.o
  obj-$(CONFIG_PCIE_UNIPHIER) += pcie-uniphier.o
  
  # The following drivers are for devices that use the generic ACPI

diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c 
b/drivers/pci/controller/dwc/pcie-tegra194.c
new file mode 100644
index ..f7d9ecf9e019
--- /dev/null
+++ b/drivers/pci/controller/dwc/pcie-tegra194.c
@@ -0,0 +1,1630 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * PCIe host controller driver for Tegra194 SoC
+ *
+ * Copyright (C) 2019 NVIDIA Corporation.
+ *
+ * Author: Vidya Sagar 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "pcie-designware.h"
+#include 
+#include 
+#include "../../pci.h"
+
+#define APPL_PINMUX0x0
+#define APPL_PINMUX_PEX_RSTBIT(0)
+#define APPL_PINMUX_CLKREQ_OVERRIDE_EN BIT(2)
+#define APPL_PINMUX_CLKREQ_OVERRIDEBIT(3)
+#define APPL_PINMUX_CLK_OUTPUT_IN_OVERRIDE_EN  BIT(4)
+#define APPL_PINMUX_CLK_OUTPUT_IN_OVERRIDE BIT(5)
+#define APPL_PINMUX_CLKREQ_OUT_OVRD_EN BIT(9)
+#define APPL_PINMUX_CLKREQ_OUT_OVRDBIT(10)
+
+#define APPL_CTRL  0x4
+#define APPL_CTRL_SYS_PRE_DET_STATEBIT(6)
+#define APPL_CTRL_LTSSM_EN BIT(7)
+#define APPL_CTRL_HW_HOT_RST_ENBIT(20)
+#define APPL_CTRL_HW_HOT_RST_MODE_MASK GENMASK(1, 0)
+#define APPL_CTRL_HW_HOT_RST_MODE_SHIFT22
+#define APPL_CTRL_HW_HOT_RST_MODE_IMDT_RST 0x1
+
+#define APPL_INTR_EN_L0_0  0x8
+#define APPL_INTR_EN_L0_0_LINK_STATE_INT_ENBIT(0)
+#defi

Re: [PATCH V2 4/4] thermal: qoriq: Add clock operations

2019-07-29 Thread Fabio Estevam
Hi Anson,

On Tue, Jul 30, 2019 at 12:00 AM Anson Huang  wrote:

> Shawn already applied the patch, and Abel has the AHB clock patch to fix that,
> so just wait for the AHB clock patch in instead of revert the TMU clock patch?

Sorry, I don't understand Abel's patch as there is not a proper
description of what it tries to fix.

If I understand correctly Abel's patch is not the proper fix and the
real fix for the kernel TMU hang in linux-next is to manage the TMU
clock inside the TMU driver, like you did in this patch.

To avoid a revert one possible solution would be to send only this one
as a fix for 5.3. You can point that it Fixes the commit that adds
i.MX8M support for the TMU driver.


Re: linux-next: build warnings after merge of the keys tree

2019-07-29 Thread Stephen Rothwell
Hi Eric,

On Mon, 29 Jul 2019 20:47:04 -0700 Eric Biggers  wrote:
>
> On Tue, Jul 30, 2019 at 12:30:42PM +1000, Stephen Rothwell wrote:
> > +static struct key_acl fsverity_acl = {
> > +   .usage  = REFCOUNT_INIT(1),
> > +   .possessor_viewable = true,  
> 
> I don't think .possessor_viewable should be set here, since there's no
> KEY_POSSESSOR_ACE(KEY_ACE_VIEW) in the ACL.  David, this bool is supposed to
> mean such an entry is present, right?  Is it really necessary, since it's
> redundant with the ACL itself?

OK, I can take that out of the patch for tomorrow.

> Otherwise this looks good, thanks Stephen.  I'll want to remove a few of these
> permissions in a separate patch later, but for now we can just keep it
> equivalent to the original code as you've done.

Thanks for the review.

> We'll have the same problem in fs/crypto/ in a week or two if/when I apply
> another patch series.  For that one I'll send you a merge resolution so you
> don't have to do it yourself...

That will be great, thanks.

-- 
Cheers,
Stephen Rothwell


pgpBYHG0BrA6y.pgp
Description: OpenPGP digital signature


[PATCH] Revision of pc87413_wdt driver to use watchdog subsystem

2019-07-29 Thread Mark Balantzyan
This patch rewrites the pc87413_wdt driver to use the watchdog subsystem. In
doing so, it also addresses a potential race condition owing from the
swc_base_addr variable being used before being set.

Signed-off-by: Mark Balantzyan 

---
 drivers/watchdog/Kconfig   |   1 +
 drivers/watchdog/pc87413_wdt.c | 294 +
 2 files changed, 39 insertions(+), 256 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 9af07fd9..84a7326d 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1166,6 +1166,7 @@ config SCx200_WDT
 
 config PC87413_WDT
tristate "NS PC87413 watchdog"
+   select WATCHDOG_CORE
depends on X86
---help---
  This is the driver for the hardware watchdog on the PC87413 chipset
diff --git a/drivers/watchdog/pc87413_wdt.c b/drivers/watchdog/pc87413_wdt.c
index 06a892e3..d1d32771 100644
--- a/drivers/watchdog/pc87413_wdt.c
+++ b/drivers/watchdog/pc87413_wdt.c
@@ -22,12 +22,10 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -65,7 +63,6 @@ static char expect_close; /* is the close 
expected? */
 
 static DEFINE_SPINLOCK(io_lock);   /* to guard us from io races */
 
-static bool nowayout = WATCHDOG_NOWAYOUT;
 
 /* -- Low level function */
 
@@ -216,41 +213,32 @@ static inline void pc87413_disable_sw_wd_trg(void)
 
 /* -- Higher level functions */
 
-/* Enable the watchdog */
+/* Enable/start the watchdog */
 
-static void pc87413_enable(void)
+static void pc87413_start(void)
 {
-   spin_lock(&io_lock);
-
pc87413_swc_bank3();
pc87413_programm_wdto(timeout);
pc87413_enable_wden();
pc87413_enable_sw_wd_tren();
pc87413_enable_sw_wd_trg();
 
-   spin_unlock(&io_lock);
 }
 
-/* Disable the watchdog */
+/* Disable/stop the watchdog */
 
-static void pc87413_disable(void)
+static void pc87413_stop(void)
 {
-   spin_lock(&io_lock);
-
pc87413_swc_bank3();
pc87413_disable_sw_wd_tren();
pc87413_disable_sw_wd_trg();
pc87413_programm_wdto(0);
-
-   spin_unlock(&io_lock);
 }
 
-/* Refresh the watchdog */
+/* Refresh/keepalive the watchdog */
 
-static void pc87413_refresh(void)
+static void pc87413_keepalive(struct watchdog_device *wdd)
 {
-   spin_lock(&io_lock);
-
pc87413_swc_bank3();
pc87413_disable_sw_wd_tren();
pc87413_disable_sw_wd_trg();
@@ -258,195 +246,11 @@ static void pc87413_refresh(void)
pc87413_enable_wden();
pc87413_enable_sw_wd_tren();
pc87413_enable_sw_wd_trg();
-
-   spin_unlock(&io_lock);
-}
-
-/* -- File operations ---*/
-
-/**
- * pc87413_open:
- * @inode: inode of device
- * @file: file handle to device
- *
- */
-
-static int pc87413_open(struct inode *inode, struct file *file)
-{
-   /* /dev/watchdog can only be opened once */
-
-   if (test_and_set_bit(0, &timer_enabled))
-   return -EBUSY;
-
-   if (nowayout)
-   __module_get(THIS_MODULE);
-
-   /* Reload and activate timer */
-   pc87413_refresh();
-
-   pr_info("Watchdog enabled. Timeout set to %d minute(s).\n", timeout);
-
-   return nonseekable_open(inode, file);
-}
-
-/**
- * pc87413_release:
- * @inode: inode to board
- * @file: file handle to board
- *
- * The watchdog has a configurable API. There is a religious dispute
- * between people who want their watchdog to be able to shut down and
- * those who want to be sure if the watchdog manager dies the machine
- * reboots. In the former case we disable the counters, in the latter
- * case you have to open it again very soon.
- */
-
-static int pc87413_release(struct inode *inode, struct file *file)
-{
-   /* Shut off the timer. */
-
-   if (expect_close == 42) {
-   pc87413_disable();
-   pr_info("Watchdog disabled, sleeping again...\n");
-   } else {
-   pr_crit("Unexpected close, not stopping watchdog!\n");
-   pc87413_refresh();
-   }
-   clear_bit(0, &timer_enabled);
-   expect_close = 0;
return 0;
 }
 
-/**
- * pc87413_status:
- *
- *  return, if the watchdog is enabled (timeout is set...)
- */
-
-
-static int pc87413_status(void)
-{
- return 0; /* currently not supported */
-}
-
-/**
- * pc87413_write:
- * @file: file handle to the watchdog
- * @data: data buffer to write
- * @len: length in bytes
- * @ppos: pointer to the position to write. No seeks allowed
- *
- * A write to a watchdog device is defined as a keepalive signal. Any
- * write of data will do, as we we don't define content meaning.
- */
-
-static ssize_t pc87413_write(struct file *file, const char __user *data,
-   

Re: [PATCH 1/2] KEYS: Replace uid/gid/perm permissions checking with an ACL

2019-07-29 Thread Eric Biggers
Hi David,

On Tue, Jul 09, 2019 at 06:16:01PM -0700, Eric Biggers wrote:
> On Thu, May 23, 2019 at 04:58:27PM +0100, David Howells wrote:
> > Replace the uid/gid/perm permissions checking on a key with an ACL to allow
> > the SETATTR and SEARCH permissions to be split.  This will also allow a
> > greater range of subjects to represented.
> > 
> 
> This patch broke 'keyctl new_session', and hence broke all the fscrypt tests:
> 
> $ keyctl new_session
> keyctl_session_to_parent: Permission denied
> 
> Output of 'keyctl show' is
> 
> $ keyctl show
> Session Keyring
>  605894913 --alswrv  0 0  keyring: _ses
>  189223103 s-rv      0 0   \_ user: invocation_id
> 
> - Eric

This bug is still present in next-20190729.

- Eric


Re: linux-next: build warnings after merge of the keys tree

2019-07-29 Thread Eric Biggers
On Tue, Jul 30, 2019 at 12:30:42PM +1000, Stephen Rothwell wrote:
> Subject: [PATCH] fsverity: merge fix for keyring_alloc API change
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  fs/verity/signature.c | 17 ++---
>  1 file changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/verity/signature.c b/fs/verity/signature.c
> index c8b255232de5..a7aac30c56ae 100644
> --- a/fs/verity/signature.c
> +++ b/fs/verity/signature.c
> @@ -131,15 +131,26 @@ static inline int __init fsverity_sysctl_init(void)
>  }
>  #endif /* !CONFIG_SYSCTL */
>  
> +static struct key_acl fsverity_acl = {
> + .usage  = REFCOUNT_INIT(1),
> + .possessor_viewable = true,

I don't think .possessor_viewable should be set here, since there's no
KEY_POSSESSOR_ACE(KEY_ACE_VIEW) in the ACL.  David, this bool is supposed to
mean such an entry is present, right?  Is it really necessary, since it's
redundant with the ACL itself?

> + .nr_ace = 2,
> + .aces = {
> + KEY_POSSESSOR_ACE(KEY_ACE_SEARCH | KEY_ACE_JOIN |
> +   KEY_ACE_INVAL),
> + KEY_OWNER_ACE(KEY_ACE_VIEW | KEY_ACE_READ | KEY_ACE_WRITE |
> +   KEY_ACE_CLEAR | KEY_ACE_SEARCH |
> +   KEY_ACE_SET_SECURITY | KEY_ACE_REVOKE),
> + }
> +};
> +
>  int __init fsverity_init_signature(void)
>  {
>   struct key *ring;
>   int err;
>  
>   ring = keyring_alloc(".fs-verity", KUIDT_INIT(0), KGIDT_INIT(0),
> -  current_cred(), KEY_POS_SEARCH |
> - KEY_USR_VIEW | KEY_USR_READ | KEY_USR_WRITE |
> - KEY_USR_SEARCH | KEY_USR_SETATTR,
> +  current_cred(), &fsverity_acl,
>KEY_ALLOC_NOT_IN_QUOTA, NULL, NULL);

Otherwise this looks good, thanks Stephen.  I'll want to remove a few of these
permissions in a separate patch later, but for now we can just keep it
equivalent to the original code as you've done.

We'll have the same problem in fs/crypto/ in a week or two if/when I apply
another patch series.  For that one I'll send you a merge resolution so you
don't have to do it yourself...

Thanks,

- Eric


Re: [PATCH 3/4] RISC-V: Support case insensitive ISA string parsing.

2019-07-29 Thread Palmer Dabbelt

On Fri, 26 Jul 2019 15:20:47 PDT (-0700), Atish Patra wrote:

On 7/26/19 1:47 PM, Paul Walmsley wrote:

On Fri, 26 Jul 2019, Atish Patra wrote:


As per riscv specification, ISA naming strings are
case insensitive. However, currently only lower case
strings are parsed during cpu procfs.

Support parsing of upper case letters as well.

Signed-off-by: Atish Patra 


Is there a use case that's driving this, or


Currently, we use all lower case isa string in kvmtool. But somebody can
have uppercase letters in future as spec allows it.


can we just say, "use

lowercase letters" and leave it at that?



In that case, it will not comply with RISC-V spec. Is that okay ?


We could make the platform spec say "use lowercase letters" and wipe our hands
of it -- IIRC we still only support the lower case letters in GCC due to
multilib headaches, so it's kind of the de-facto standard already.





- Paul



Re: [PATCH] net: phy: phy_led_triggers: Fix a possible null-pointer dereference in phy_led_trigger_change_speed()

2019-07-29 Thread David Miller
From: Andrew Lunn 
Date: Tue, 30 Jul 2019 05:32:29 +0200

> On Tue, Jul 30, 2019 at 10:25:36AM +0800, Jia-Ju Bai wrote:
>> 
>> 
>> On 2019/7/29 21:45, Andrew Lunn wrote:
>> >On Mon, Jul 29, 2019 at 05:24:24PM +0800, Jia-Ju Bai wrote:
>> >>In phy_led_trigger_change_speed(), there is an if statement on line 48
>> >>to check whether phy->last_triggered is NULL:
>> >> if (!phy->last_triggered)
>> >>
>> >>When phy->last_triggered is NULL, it is used on line 52:
>> >> led_trigger_event(&phy->last_triggered->trigger, LED_OFF);
>> >>
>> >>Thus, a possible null-pointer dereference may occur.
>> >>
>> >>To fix this bug, led_trigger_event(&phy->last_triggered->trigger,
>> >>LED_OFF) is called when phy->last_triggered is not NULL.
>> >>
>> >>This bug is found by a static analysis tool STCheck written by us.
>> >Who is 'us'?
>> 
>> Me and my colleague...
> 
> Well, we can leave it very vague, giving no idea who 'us' is. But
> often you want to name the company behind it, or the university, or
> the sponsor, etc.

I agree, if you are going to mention that there is a tool you should be
clear exactly who and what organization are behind it.

Thank you.


Re: [PATCH net-next 1/2] net: phy: broadcom: set features explicitly for BCM54616S

2019-07-29 Thread Andrew Lunn
On Mon, Jul 29, 2019 at 05:25:32PM -0700, Tao Ren wrote:
> BCM54616S feature "PHY_GBIT_FEATURES" was removed by commit dcdecdcfe1fc
> ("net: phy: switch drivers to use dynamic feature detection"). As dynamic
> feature detection doesn't work when BCM54616S is working in RGMII-Fiber
> mode (different sets of MII Control/Status registers being used), let's
> set "PHY_GBIT_FEATURES" for BCM54616S explicitly.

Hi Tao

What exactly does it get wrong?

 Thanks
Andrew


Re: [PATCH 5.2 000/215] 5.2.5-stable review

2019-07-29 Thread kernelci.org bot
stable-rc/linux-5.2.y boot: 122 boots: 0 failed, 75 passed with 45 offline, 2 
untried/unknown (v5.2.4-216-g0c4d120e771a)

Full Boot Summary: 
https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.2.y/kernel/v5.2.4-216-g0c4d120e771a/
Full Build Summary: 
https://kernelci.org/build/stable-rc/branch/linux-5.2.y/kernel/v5.2.4-216-g0c4d120e771a/

Tree: stable-rc
Branch: linux-5.2.y
Git Describe: v5.2.4-216-g0c4d120e771a
Git Commit: 0c4d120e771a048ef7ae9a4130169b1cf03c36da
Git URL: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 72 unique boards, 27 SoC families, 17 builds out of 209

Offline Platforms:

riscv:

defconfig:
gcc-8
sifive_fu540: 1 offline lab

arm64:

defconfig:
gcc-8
meson-axg-s400: 1 offline lab
meson-g12a-u200: 1 offline lab
meson-g12a-x96-max: 1 offline lab
meson-gxbb-odroidc2: 1 offline lab
meson-gxl-s905d-p230: 1 offline lab
meson-gxl-s905x-libretech-cc: 1 offline lab
meson-gxl-s905x-nexbox-a95x: 1 offline lab
meson-gxl-s905x-p212: 1 offline lab
meson-gxm-nexbox-a1: 1 offline lab
rk3399-firefly: 1 offline lab
sun50i-a64-pine64-plus: 1 offline lab

mips:

pistachio_defconfig:
gcc-8
pistachio_marduk: 1 offline lab

arm:

exynos_defconfig:
gcc-8
exynos5250-arndale: 1 offline lab
exynos5420-arndale-octa: 1 offline lab
exynos5800-peach-pi: 1 offline lab

multi_v7_defconfig:
gcc-8
bcm72521-bcm97252sffe: 1 offline lab
bcm7445-bcm97445c: 1 offline lab
exynos5250-arndale: 1 offline lab
exynos5420-arndale-octa: 1 offline lab
exynos5800-peach-pi: 1 offline lab
imx6dl-wandboard_dual: 1 offline lab
imx6dl-wandboard_solo: 1 offline lab
imx6q-wandboard: 1 offline lab
imx7s-warp: 1 offline lab
meson8b-odroidc1: 1 offline lab
omap3-beagle: 1 offline lab
omap4-panda: 1 offline lab
qcom-apq8064-ifc6410: 1 offline lab
stih410-b2120: 1 offline lab
sun4i-a10-cubieboard: 1 offline lab
sun7i-a20-bananapi: 1 offline lab
vf610-colibri-eval-v3: 1 offline lab

omap2plus_defconfig:
gcc-8
omap3-beagle: 1 offline lab
omap4-panda: 1 offline lab

qcom_defconfig:
gcc-8
qcom-apq8064-ifc6410: 1 offline lab

davinci_all_defconfig:
gcc-8
da850-evm: 1 offline lab
dm365evm,legacy: 1 offline lab

imx_v6_v7_defconfig:
gcc-8
imx6dl-wandboard_dual: 1 offline lab
imx6dl-wandboard_solo: 1 offline lab
imx6q-wandboard: 1 offline lab
imx7s-warp: 1 offline lab
vf610-colibri-eval-v3: 1 offline lab

sunxi_defconfig:
gcc-8
sun4i-a10-cubieboard: 1 offline lab
sun7i-a20-bananapi: 1 offline lab

---
For more info write to 


Re: [PATCH 4.14 000/293] 4.14.135-stable review

2019-07-29 Thread kernelci.org bot
stable-rc/linux-4.14.y boot: 106 boots: 1 failed, 64 passed with 41 offline 
(v4.14.134-294-gf6ba73a2e356)

Full Boot Summary: 
https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.14.134-294-gf6ba73a2e356/
Full Build Summary: 
https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.134-294-gf6ba73a2e356/

Tree: stable-rc
Branch: linux-4.14.y
Git Describe: v4.14.134-294-gf6ba73a2e356
Git Commit: f6ba73a2e356d3f40ed298dbf4097561f2cd9973
Git URL: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 58 unique boards, 25 SoC families, 16 builds out of 201

Boot Failure Detected:

arc:
hsdk_defconfig:
gcc-8:
hsdk: 1 failed lab

Offline Platforms:

arm64:

defconfig:
gcc-8
meson-gxbb-odroidc2: 1 offline lab
meson-gxl-s905d-p230: 1 offline lab
meson-gxl-s905x-libretech-cc: 1 offline lab
meson-gxl-s905x-nexbox-a95x: 1 offline lab
meson-gxl-s905x-p212: 1 offline lab
meson-gxm-nexbox-a1: 1 offline lab
rk3399-firefly: 1 offline lab
sun50i-a64-pine64-plus: 1 offline lab

mips:

pistachio_defconfig:
gcc-8
pistachio_marduk: 1 offline lab

arm:

tegra_defconfig:
gcc-8
tegra20-iris-512: 1 offline lab

exynos_defconfig:
gcc-8
exynos5250-arndale: 1 offline lab
exynos5420-arndale-octa: 1 offline lab
exynos5800-peach-pi: 1 offline lab

multi_v7_defconfig:
gcc-8
exynos5250-arndale: 1 offline lab
exynos5420-arndale-octa: 1 offline lab
exynos5800-peach-pi: 1 offline lab
imx6dl-wandboard_dual: 1 offline lab
imx6dl-wandboard_solo: 1 offline lab
imx6q-wandboard: 1 offline lab
imx7s-warp: 1 offline lab
meson8b-odroidc1: 1 offline lab
omap3-beagle: 1 offline lab
omap4-panda: 1 offline lab
qcom-apq8064-ifc6410: 1 offline lab
stih410-b2120: 1 offline lab
sun4i-a10-cubieboard: 1 offline lab
sun7i-a20-bananapi: 1 offline lab
tegra20-iris-512: 1 offline lab
vf610-colibri-eval-v3: 1 offline lab

omap2plus_defconfig:
gcc-8
omap3-beagle: 1 offline lab
omap4-panda: 1 offline lab

qcom_defconfig:
gcc-8
qcom-apq8064-ifc6410: 1 offline lab

davinci_all_defconfig:
gcc-8
da850-evm: 1 offline lab
dm365evm,legacy: 1 offline lab

imx_v6_v7_defconfig:
gcc-8
imx6dl-wandboard_dual: 1 offline lab
imx6dl-wandboard_solo: 1 offline lab
imx6q-wandboard: 1 offline lab
imx7s-warp: 1 offline lab
vf610-colibri-eval-v3: 1 offline lab

sunxi_defconfig:
gcc-8
sun4i-a10-cubieboard: 1 offline lab
sun7i-a20-bananapi: 1 offline lab

---
For more info write to 


Re: [PATCH] net: phy: phy_led_triggers: Fix a possible null-pointer dereference in phy_led_trigger_change_speed()

2019-07-29 Thread Andrew Lunn
On Tue, Jul 30, 2019 at 10:25:36AM +0800, Jia-Ju Bai wrote:
> 
> 
> On 2019/7/29 21:45, Andrew Lunn wrote:
> >On Mon, Jul 29, 2019 at 05:24:24PM +0800, Jia-Ju Bai wrote:
> >>In phy_led_trigger_change_speed(), there is an if statement on line 48
> >>to check whether phy->last_triggered is NULL:
> >> if (!phy->last_triggered)
> >>
> >>When phy->last_triggered is NULL, it is used on line 52:
> >> led_trigger_event(&phy->last_triggered->trigger, LED_OFF);
> >>
> >>Thus, a possible null-pointer dereference may occur.
> >>
> >>To fix this bug, led_trigger_event(&phy->last_triggered->trigger,
> >>LED_OFF) is called when phy->last_triggered is not NULL.
> >>
> >>This bug is found by a static analysis tool STCheck written by us.
> >Who is 'us'?
> 
> Me and my colleague...

Well, we can leave it very vague, giving no idea who 'us' is. But
often you want to name the company behind it, or the university, or
the sponsor, etc.

Andrew


RE: [PATCH] rtw88: pci: Use general byte arrays as the elements of RX ring

2019-07-29 Thread Tony Chuang
> > > > While allocating all 512 buffers in one block (just over 4MB)
> > > > is probably not a good idea, you may need to allocated (and dma map)
> > > > then in groups.
> > >
> > > Thanks for reviewing.  But got questions here to double confirm the
> idea.
> > > According to original code, it allocates 512 skbs for RX ring and dma
> > > mapping one by one.  So, the new code allocates memory buffer 512
> > > times to get 512 buffer arrays.  Will the 512 buffers arrays be in one
> > > block?  Do you mean aggregate the buffers as a scatterlist and use
> > > dma_map_sg?
> >
> > If you malloc a buffer of size (8192+32) the allocator will either
> > round it up to a whole number of (often 4k) pages or to a power of
> > 2 of pages - so either 12k of 16k.
> > I think the Linux allocator does the latter.
> > Some of the allocators also 'steal' a bit from the front of the buffer
> > for 'red tape'.
> >
> > OTOH malloc the space 15 buffers and the allocator will round the
> > 15*(8192 + 32) up to 32*4k - and you waste under 8k across all the
> > buffers.
> >
> > You then dma_map the large buffer and split into the actual rx buffers.
> > Repeat until you've filled the entire ring.
> > The only complication is remembering the base address (and size) for
> > the dma_unmap and free.
> > Although there is plenty of padding to extend the buffer structure
> > significantly without using more memory.
> > Allocate in 15's and you (probably) have 512 bytes per buffer.
> > Allocate in 31's and you have 256 bytes.
> >
> > The problem is that larger allocates are more likely to fail
> > (especially if the system has been running for some time).
> > So you almost certainly want to be able to fall back to smaller
> > allocates even though they use more memory.
> >
> > I also wonder if you actually need 512 8k rx buffers to cover
> > interrupt latency?
> > I've not done any measurements for 20 years!
> 
> Thanks for the explanation.
> I am not sure the combination of 512 8k RX buffers.  Maybe Realtek
> folks can give us some idea.
> Tony Chuang any comment?
> 
> Jian-Hong Pan
> 

512 RX buffers is not necessary I think. But I haven't had a chance to
test if reduce the number of RX SKBs could affect the latency.
I can run some throughput tests and then decide a minimum numbers
that RX ring requires. Or if you can try it.

Thanks.
Yan-Hsuan


Re: [RFC PATCH 08/21] KVM: x86: Add kvm_x86_ops hook to short circuit emulation

2019-07-29 Thread Sean Christopherson
On Fri, Jul 26, 2019 at 10:52:01PM -0700, Sean Christopherson wrote:
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index 48c865a4e5dd..0fb8b60eb136 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -7115,10 +7115,25 @@ static int nested_enable_evmcs(struct kvm_vcpu *vcpu,
>   return -ENODEV;
>  }
>  
> -static bool svm_need_emulation_on_page_fault(struct kvm_vcpu *vcpu)
> +static bool svm_is_emulatable(struct kvm_vcpu *vcpu, void *insn, int 
> insn_len)
>  {
>   bool is_user, smap;
>  
> + if (likely(!insn || insn_len))
> + return true;
> +
> + /*
> +  * Under certain conditions insn_len may be zero on #NPF.  This can
> +  * happen if a guest gets a page-fault on data access but the HW table
> +  * walker is not able to read the instruction page (e.g instruction
> +  * page is not present in memory). In those cases we simply restart the
> +  * guest, with the exception of AMD Erratum 1096 which is unrecoverable.
> +  */
> + if (unlikely(insn && !insn_len)) {
> + if (!kvm_x86_ops->need_emulation_on_page_fault(vcpu))
> + return 1;
> + }

Doh, obviously forgot to compile for SVM when rebasing.


[PATCH 006/107] perf trace: Order -e syscalls table

2019-07-29 Thread Arnaldo Carvalho de Melo
From: Arnaldo Carvalho de Melo 

The ev_qualifier is an array with the syscall ids passed via -e on the
command line, sort it as we'll search it when setting up the
BPF_MAP_TYPE_PROG_ARRAY.

Cc: Adrian Hunter 
Cc: Jiri Olsa 
Cc: Luis Cláudio Gonçalves 
Cc: Namhyung Kim 
Link: https://lkml.kernel.org/n/tip-c8hprylp3ai6e0z9burn2...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-trace.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index bfd739a321d1..9bd5ecd6a8dd 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -1528,6 +1528,13 @@ static int trace__read_syscall_info(struct trace *trace, 
int id)
return syscall__set_arg_fmts(sc);
 }
 
+static int intcmp(const void *a, const void *b)
+{
+   const int *one = a, *another = b;
+
+   return *one - *another;
+}
+
 static int trace__validate_ev_qualifier(struct trace *trace)
 {
int err = 0;
@@ -1591,6 +1598,7 @@ static int trace__validate_ev_qualifier(struct trace 
*trace)
}
 
trace->ev_qualifier_ids.nr = nr_used;
+   qsort(trace->ev_qualifier_ids.entries, nr_used, sizeof(int), intcmp);
 out:
if (printed_invalid_prefix)
pr_debug("\n");
-- 
2.21.0



[PATCH 013/107] perf augmented_raw_syscalls: Support copying two string syscall args

2019-07-29 Thread Arnaldo Carvalho de Melo
From: Arnaldo Carvalho de Melo 

Starting with the renameat and renameat2 syscall, that both receive as
second and fourth parameters a pathname:

  # perf trace -e rename* mv one ANOTHER
  LLVM: dumping 
/home/acme/git/perf/tools/perf/examples/bpf/augmented_raw_syscalls.o
  mv: cannot stat 'one': No such file or directory
  renameat2(AT_FDCWD, "one", AT_FDCWD, "ANOTHER", RENAME_NOREPLACE) = -1 ENOENT 
(No such file or directory)
  #

Since the per CPU scratch buffer map has space for two maximum sized
pathnames, the verifier is satisfied that there will be no overrun.

Cc: Adrian Hunter 
Cc: Jiri Olsa 
Cc: Luis Cláudio Gonçalves 
Cc: Namhyung Kim 
Link: https://lkml.kernel.org/n/tip-x2uboyg5kx2wqeru28820...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-trace.c|  2 ++
 .../examples/bpf/augmented_raw_syscalls.c | 20 +++
 2 files changed, 22 insertions(+)

diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index a681b8c2ee4e..c64f7c99db15 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -873,9 +873,11 @@ static struct syscall_fmt {
{ .name = "recvmsg",
  .arg = { [2] = { .scnprintf = SCA_MSG_FLAGS, /* flags */ }, }, },
{ .name = "renameat",
+ .bpf_prog_name = { .sys_enter = "!syscalls:sys_enter_renameat", },
  .arg = { [0] = { .scnprintf = SCA_FDAT, /* olddirfd */ },
   [2] = { .scnprintf = SCA_FDAT, /* newdirfd */ }, }, },
{ .name = "renameat2",
+ .bpf_prog_name = { .sys_enter = "!syscalls:sys_enter_renameat", },
  .arg = { [0] = { .scnprintf = SCA_FDAT, /* olddirfd */ },
   [2] = { .scnprintf = SCA_FDAT, /* newdirfd */ },
   [4] = { .scnprintf = SCA_RENAMEAT2_FLAGS, /* flags */ }, }, 
},
diff --git a/tools/perf/examples/bpf/augmented_raw_syscalls.c 
b/tools/perf/examples/bpf/augmented_raw_syscalls.c
index ce308b9a317c..df52d92e1c69 100644
--- a/tools/perf/examples/bpf/augmented_raw_syscalls.c
+++ b/tools/perf/examples/bpf/augmented_raw_syscalls.c
@@ -70,6 +70,7 @@ pid_filter(pids_filtered);
 struct augmented_args_filename {
struct syscall_enter_args args;
struct augmented_filename filename;
+   struct augmented_filename filename2;
 };
 
 bpf_map(augmented_filename_map, PERCPU_ARRAY, int, struct 
augmented_args_filename, 1);
@@ -148,6 +149,25 @@ int sys_enter_openat(struct syscall_enter_args *args)
return perf_event_output(args, &__augmented_syscalls__, 
BPF_F_CURRENT_CPU, augmented_args, len);
 }
 
+SEC("!syscalls:sys_enter_renameat")
+int sys_enter_renameat(struct syscall_enter_args *args)
+{
+   int key = 0;
+   struct augmented_args_filename *augmented_args = 
bpf_map_lookup_elem(&augmented_filename_map, &key);
+   const void *oldpath_arg = (const void *)args->args[1],
+  *newpath_arg = (const void *)args->args[3];
+   unsigned int len = sizeof(augmented_args->args), oldpath_len;
+
+if (augmented_args == NULL)
+return 1; /* Failure: don't filter */
+
+   oldpath_len = augmented_filename__read(&augmented_args->filename, 
oldpath_arg, sizeof(augmented_args->filename.value));
+   len += oldpath_len + augmented_filename__read((void 
*)(&augmented_args->filename) + oldpath_len, newpath_arg, 
sizeof(augmented_args->filename.value));
+
+   /* If perf_event_output fails, return non-zero so that it gets recorded 
unaugmented */
+   return perf_event_output(args, &__augmented_syscalls__, 
BPF_F_CURRENT_CPU, augmented_args, len);
+}
+
 SEC("raw_syscalls:sys_enter")
 int sys_enter(struct syscall_enter_args *args)
 {
-- 
2.21.0



[PATCH 017/107] perf trace beauty: Make connect's addrlen be printed as an int, not hex

2019-07-29 Thread Arnaldo Carvalho de Melo
From: Arnaldo Carvalho de Melo 

  # perf trace -e connec* ssh www.bla.com
  connect(3, { .family: PF_LOCAL, path: 
/var/run/nscd/socket }, 110) = -1 ENOENT (No such file or directory)
  connect(3, { .family: PF_LOCAL, path: 
/var/run/nscd/socket }, 110) = -1 ENOENT (No such file or directory)
  connect(4, { .family: PF_LOCAL, path: 
/var/lib/sss/pipes/nss }, 110) = 0
  connect(7, { .family: PF_LOCAL, path: /var/run/nscd/socket }, 110) = -1 
ENOENT (No such file or directory)
  connect(7, { .family: PF_LOCAL, path: /var/run/nscd/socket }, 110) = -1 
ENOENT (No such file or directory)
  connect(5, { .family: PF_LOCAL, path: /var/run/nscd/socket }, 110) = -1 
ENOENT (No such file or directory)
  connect(5, { .family: PF_LOCAL, path: 
/var/run/nscd/socket }, 110) = -1 ENOENT (No such file or directory)
  connect(5, { .family: PF_INET, port: 
53, addr: 192.168.44.1 }, 16) = 0
  connect(5, { .family: PF_INET, port: 
22, addr: 146.112.61.108 }, 16) = 0
  connect(5, { .family: PF_INET6, port: 
22, addr: :::146.112.61.108 }, 28) = 0
  ^Cconnect(5, { .family: PF_INET, port: 
22, addr: 146.112.61.108 }, 16) = -1 (unknown) (INTERNAL ERROR: strerror_r(512, 
[buf], 128)=22)
  #

Argh, the SCA_FD needs to invalidate its cache when close is done...

It works if the 'close' syscall is not filtered out ;-\

  # perf trace -e close,connec* ssh www.bla.com
  close(3)= 0
  close(3) = 0
  close(3)= 0
  close(3) = 0
  close(3) = 0
  close(3)= 0
  close(3) = 0
  close(3) = 0
  close(3)  = 0
  close(3)  = 0
  close(3)= 0
  close(3) = 0
  close(3) = 0
  close(3) = 0
  close(3) = 0
  close(3)= 0
  close(3)= 0
  close(3)= 0
  close(3)= 0
  close(4)= 0
  close(3)= 0
  close(3)= 0
  connect(3, { .family: PF_LOCAL, path: 
/var/run/nscd/socket }, 110) = -1 ENOENT (No such file or directory)
  close(3)= 0
  connect(3, { .family: PF_LOCAL, path: 
/var/run/nscd/socket }, 110) = -1 ENOENT (No such file or directory)
  close(3)= 0
  close(3)= 0
  close(3)= 0
  close(3)= 0
  connect(4, { .family: PF_LOCAL, path: 
/var/lib/sss/pipes/nss }, 110) = 0
  ^C
  #

Will disable this beautifier when 'close' is filtered out...

Cc: Adrian Hunter 
Cc: Jiri Olsa 
Cc: Luis Cláudio Gonçalves 
Cc: Namhyung Kim 
Link: https://lkml.kernel.org/n/tip-ekuiciyx4znchvy95c8p1...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-trace.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 5258399a1c94..123d7efc12e8 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -725,7 +725,8 @@ static struct syscall_fmt {
{ .name = "close",
  .arg = { [0] = { .scnprintf = SCA_CLOSE_FD, /* fd */ }, }, },
{ .name = "connect",
- .arg = { [1] = { .scnprintf = SCA_SOCKADDR, /* servaddr */ }, }, },
+ .arg = { [1] = { .scnprintf = SCA_SOCKADDR, /* servaddr */ },
+  [2] = { .scnprintf = SCA_INT, /* addrlen */ }, }, },
{ .name = "epoll_ctl",
  .arg = { [1] = STRARRAY(op, epoll_ctl_ops), }, },
{ .name = "eventfd2",
-- 
2.21.0



[PATCH 003/107] perf evsel: Store backpointer to attached bpf_object

2019-07-29 Thread Arnaldo Carvalho de Melo
From: Arnaldo Carvalho de Melo 

We may want to get to this bpf_object, to search for other BPF programs,
etc.

Cc: Adrian Hunter 
Cc: Jiri Olsa 
Cc: Luis Cláudio Gonçalves 
Cc: Namhyung Kim 
Link: https://lkml.kernel.org/n/tip-3y8hrb6lszjfi23vjlic3...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/bpf-loader.c   | 4 ++--
 tools/perf/util/bpf-loader.h   | 2 +-
 tools/perf/util/evsel.c| 1 +
 tools/perf/util/evsel.h| 3 +++
 tools/perf/util/parse-events.c | 3 ++-
 5 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/tools/perf/util/bpf-loader.c b/tools/perf/util/bpf-loader.c
index c61974a50aa5..6d0dfb777a79 100644
--- a/tools/perf/util/bpf-loader.c
+++ b/tools/perf/util/bpf-loader.c
@@ -763,7 +763,7 @@ int bpf__foreach_event(struct bpf_object *obj,
 
if (priv->is_tp) {
fd = bpf_program__fd(prog);
-   err = (*func)(priv->sys_name, priv->evt_name, fd, arg);
+   err = (*func)(priv->sys_name, priv->evt_name, fd, obj, 
arg);
if (err) {
pr_debug("bpf: tracepoint call back failed, 
stop iterate\n");
return err;
@@ -788,7 +788,7 @@ int bpf__foreach_event(struct bpf_object *obj,
return fd;
}
 
-   err = (*func)(tev->group, tev->event, fd, arg);
+   err = (*func)(tev->group, tev->event, fd, obj, arg);
if (err) {
pr_debug("bpf: call back failed, stop 
iterate\n");
return err;
diff --git a/tools/perf/util/bpf-loader.h b/tools/perf/util/bpf-loader.h
index 3f46856e3330..8c3441a4b72c 100644
--- a/tools/perf/util/bpf-loader.h
+++ b/tools/perf/util/bpf-loader.h
@@ -46,7 +46,7 @@ struct parse_events_term;
 #define PERF_BPF_PROBE_GROUP "perf_bpf_probe"
 
 typedef int (*bpf_prog_iter_callback_t)(const char *group, const char *event,
-   int fd, void *arg);
+   int fd, struct bpf_object *obj, void 
*arg);
 
 #ifdef HAVE_LIBBPF_SUPPORT
 struct bpf_object *bpf__prepare_load(const char *filename, bool source);
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 52459dd5ad0c..7d1757a2ec46 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -234,6 +234,7 @@ void perf_evsel__init(struct perf_evsel *evsel,
evsel->scale   = 1.0;
evsel->max_events  = ULONG_MAX;
evsel->evlist  = NULL;
+   evsel->bpf_obj = NULL;
evsel->bpf_fd  = -1;
INIT_LIST_HEAD(&evsel->node);
INIT_LIST_HEAD(&evsel->config_terms);
diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
index cad54e8ba522..b27935a6d36c 100644
--- a/tools/perf/util/evsel.h
+++ b/tools/perf/util/evsel.h
@@ -82,6 +82,8 @@ enum perf_tool_event {
PERF_TOOL_DURATION_TIME = 1,
 };
 
+struct bpf_object;
+
 /** struct perf_evsel - event selector
  *
  * @evlist - evlist this evsel is in, if it is in one.
@@ -152,6 +154,7 @@ struct perf_evsel {
char*group_name;
boolcmdline_group_boundary;
struct list_headconfig_terms;
+   struct bpf_object   *bpf_obj;
int bpf_fd;
boolauto_merge_stats;
boolmerged_stat;
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index fac6b32ef94a..0540303e5e97 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -630,7 +630,7 @@ struct __add_bpf_event_param {
struct list_head *head_config;
 };
 
-static int add_bpf_event(const char *group, const char *event, int fd,
+static int add_bpf_event(const char *group, const char *event, int fd, struct 
bpf_object *obj,
 void *_param)
 {
LIST_HEAD(new_evsels);
@@ -672,6 +672,7 @@ static int add_bpf_event(const char *group, const char 
*event, int fd,
pr_debug("adding %s:%s to %p\n",
 group, event, pos);
pos->bpf_fd = fd;
+   pos->bpf_obj = obj;
}
list_splice(&new_evsels, list);
return 0;
-- 
2.21.0



[PATCH 015/107] perf augmented_raw_syscalls: Rename augmented_args_filename to augmented_args_payload

2019-07-29 Thread Arnaldo Carvalho de Melo
From: Arnaldo Carvalho de Melo 

It'll get other stuff in there than just filenames, starting with
sockaddr for 'connect' and 'bind'.

Cc: Adrian Hunter 
Cc: Jiri Olsa 
Cc: Luis Cláudio Gonçalves 
Cc: Namhyung Kim 
Link: https://lkml.kernel.org/n/tip-bsexidtsn91ehdpzcd6n5...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 .../examples/bpf/augmented_raw_syscalls.c | 22 ++-
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/tools/perf/examples/bpf/augmented_raw_syscalls.c 
b/tools/perf/examples/bpf/augmented_raw_syscalls.c
index df52d92e1c69..77bb6a0edce3 100644
--- a/tools/perf/examples/bpf/augmented_raw_syscalls.c
+++ b/tools/perf/examples/bpf/augmented_raw_syscalls.c
@@ -67,13 +67,15 @@ struct augmented_filename {
 
 pid_filter(pids_filtered);
 
-struct augmented_args_filename {
+struct augmented_args_payload {
struct syscall_enter_args args;
-   struct augmented_filename filename;
-   struct augmented_filename filename2;
+   struct {
+  struct augmented_filename filename;
+  struct augmented_filename filename2;
+   };
 };
 
-bpf_map(augmented_filename_map, PERCPU_ARRAY, int, struct 
augmented_args_filename, 1);
+bpf_map(augmented_args_tmp, PERCPU_ARRAY, int, struct augmented_args_payload, 
1);
 
 static inline
 unsigned int augmented_filename__read(struct augmented_filename 
*augmented_filename,
@@ -111,7 +113,7 @@ int syscall_unaugmented(struct syscall_enter_args *args)
 
 /*
  * This will be tail_called from SEC("raw_syscalls:sys_enter"), so will find in
- * augmented_filename_map what was read by that raw_syscalls:sys_enter and go
+ * augmented_args_tmp what was read by that raw_syscalls:sys_enter and go
  * on from there, reading the first syscall arg as a string, i.e. open's
  * filename.
  */
@@ -119,7 +121,7 @@ SEC("!syscalls:sys_enter_open")
 int sys_enter_open(struct syscall_enter_args *args)
 {
int key = 0;
-   struct augmented_args_filename *augmented_args = 
bpf_map_lookup_elem(&augmented_filename_map, &key);
+   struct augmented_args_payload *augmented_args = 
bpf_map_lookup_elem(&augmented_args_tmp, &key);
const void *filename_arg = (const void *)args->args[0];
unsigned int len = sizeof(augmented_args->args);
 
@@ -136,7 +138,7 @@ SEC("!syscalls:sys_enter_openat")
 int sys_enter_openat(struct syscall_enter_args *args)
 {
int key = 0;
-   struct augmented_args_filename *augmented_args = 
bpf_map_lookup_elem(&augmented_filename_map, &key);
+   struct augmented_args_payload *augmented_args = 
bpf_map_lookup_elem(&augmented_args_tmp, &key);
const void *filename_arg = (const void *)args->args[1];
unsigned int len = sizeof(augmented_args->args);
 
@@ -153,7 +155,7 @@ SEC("!syscalls:sys_enter_renameat")
 int sys_enter_renameat(struct syscall_enter_args *args)
 {
int key = 0;
-   struct augmented_args_filename *augmented_args = 
bpf_map_lookup_elem(&augmented_filename_map, &key);
+   struct augmented_args_payload *augmented_args = 
bpf_map_lookup_elem(&augmented_args_tmp, &key);
const void *oldpath_arg = (const void *)args->args[1],
   *newpath_arg = (const void *)args->args[3];
unsigned int len = sizeof(augmented_args->args), oldpath_len;
@@ -171,7 +173,7 @@ int sys_enter_renameat(struct syscall_enter_args *args)
 SEC("raw_syscalls:sys_enter")
 int sys_enter(struct syscall_enter_args *args)
 {
-   struct augmented_args_filename *augmented_args;
+   struct augmented_args_payload *augmented_args;
/*
 * We start len, the amount of data that will be in the perf ring
 * buffer, if this is not filtered out by one of pid_filter__has(),
@@ -185,7 +187,7 @@ int sys_enter(struct syscall_enter_args *args)
struct syscall *syscall;
int key = 0;
 
-augmented_args = bpf_map_lookup_elem(&augmented_filename_map, &key);
+augmented_args = bpf_map_lookup_elem(&augmented_args_tmp, &key);
 if (augmented_args == NULL)
 return 1;
 
-- 
2.21.0



[PATCH] staging: rtl8723bs: core: Remove Macro "IS_MAC_ADDRESS_BROADCAST"

2019-07-29 Thread Hariprasad Kelam
Remove unused macro IS_MAC_ADDRESS_BROADCAST. In future if one wants use
it ,use generic API "is_broadcast_ether_addr"

Signed-off-by: Hariprasad Kelam 
---
 drivers/staging/rtl8723bs/core/rtw_ioctl_set.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c 
b/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
index 8eb0ff5..eb08569 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
@@ -9,13 +9,6 @@
 #include 
 #include 
 
-#define IS_MAC_ADDRESS_BROADCAST(addr) \
-(\
-   ((addr[0] == 0xff) && (addr[1] == 0xff) && \
-   (addr[2] == 0xff) && (addr[3] == 0xff) && \
-   (addr[4] == 0xff) && (addr[5] == 0xff))  ? true : false \
-)
-
 u8 rtw_validate_bssid(u8 *bssid)
 {
u8 ret = true;
-- 
2.7.4



[PATCH 004/107] perf trace: Add pointer to BPF object containing __augmented_syscalls__

2019-07-29 Thread Arnaldo Carvalho de Melo
From: Arnaldo Carvalho de Melo 

So that we can use it when looking for other components of that object
file, such as other programs to add to the BPF_MAP_TYPE_PROG_ARRAY and
use with bpf_tail_call().

Cc: Adrian Hunter 
Cc: Jiri Olsa 
Cc: Luis Cláudio Gonçalves 
Cc: Namhyung Kim 
Link: https://lkml.kernel.org/n/tip-1ibmz7ouv6llqxajy7m8i...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-trace.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 4f0bbffee05f..6aa080845a84 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -96,6 +96,7 @@ struct trace {
struct perf_evlist  *evlist;
struct machine  *host;
struct thread   *current;
+   struct bpf_object   *bpf_obj;
struct cgroup   *cgroup;
u64 base_time;
FILE*output;
@@ -3895,6 +3896,20 @@ int cmd_trace(int argc, const char **argv)
 
if (evsel) {
trace.syscalls.events.augmented = evsel;
+
+   evsel = perf_evlist__find_tracepoint_by_name(trace.evlist, 
"raw_syscalls:sys_enter");
+   if (evsel == NULL) {
+   pr_err("ERROR: raw_syscalls:sys_enter not found in the 
augmented BPF object\n");
+   goto out;
+   }
+
+   if (evsel->bpf_obj == NULL) {
+   pr_err("ERROR: raw_syscalls:sys_enter not associated to 
a BPF object\n");
+   goto out;
+   }
+
+   trace.bpf_obj = evsel->bpf_obj;
+
trace__set_bpf_map_filtered_pids(&trace);
trace__set_bpf_map_syscalls(&trace);
}
-- 
2.21.0



[PATCH 042/107] perf evsel: Rename perf_evsel__enable() to evsel__enable()

2019-07-29 Thread Arnaldo Carvalho de Melo
From: Jiri Olsa 

Rename perf_evsel__enable() to evsel__enable(), so we don't have a name
clash when we add perf_evsel__enable() in libperf.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: Alexey Budankov 
Cc: Andi Kleen 
Cc: Michael Petlan 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20190721112506.12306-16-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/arm/util/cs-etm.c| 2 +-
 tools/perf/arch/x86/util/intel-bts.c | 2 +-
 tools/perf/arch/x86/util/intel-pt.c  | 2 +-
 tools/perf/tests/event-times.c   | 6 +++---
 tools/perf/tests/switch-tracking.c   | 2 +-
 tools/perf/util/evlist.c | 4 ++--
 tools/perf/util/evsel.c  | 2 +-
 tools/perf/util/evsel.h  | 2 +-
 8 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/tools/perf/arch/arm/util/cs-etm.c 
b/tools/perf/arch/arm/util/cs-etm.c
index 91c64daa4487..4b70b9504603 100644
--- a/tools/perf/arch/arm/util/cs-etm.c
+++ b/tools/perf/arch/arm/util/cs-etm.c
@@ -834,7 +834,7 @@ static int cs_etm_snapshot_finish(struct auxtrace_record 
*itr)
 
evlist__for_each_entry(ptr->evlist, evsel) {
if (evsel->attr.type == ptr->cs_etm_pmu->type)
-   return perf_evsel__enable(evsel);
+   return evsel__enable(evsel);
}
return -EINVAL;
 }
diff --git a/tools/perf/arch/x86/util/intel-bts.c 
b/tools/perf/arch/x86/util/intel-bts.c
index c845531d383a..d27832fcb34c 100644
--- a/tools/perf/arch/x86/util/intel-bts.c
+++ b/tools/perf/arch/x86/util/intel-bts.c
@@ -330,7 +330,7 @@ static int intel_bts_snapshot_finish(struct auxtrace_record 
*itr)
 
evlist__for_each_entry(btsr->evlist, evsel) {
if (evsel->attr.type == btsr->intel_bts_pmu->type)
-   return perf_evsel__enable(evsel);
+   return evsel__enable(evsel);
}
return -EINVAL;
 }
diff --git a/tools/perf/arch/x86/util/intel-pt.c 
b/tools/perf/arch/x86/util/intel-pt.c
index e4dfe8c3d5c3..e3dacb2bf01b 100644
--- a/tools/perf/arch/x86/util/intel-pt.c
+++ b/tools/perf/arch/x86/util/intel-pt.c
@@ -801,7 +801,7 @@ static int intel_pt_snapshot_finish(struct auxtrace_record 
*itr)
 
evlist__for_each_entry(ptr->evlist, evsel) {
if (evsel->attr.type == ptr->intel_pt_pmu->type)
-   return perf_evsel__enable(evsel);
+   return evsel__enable(evsel);
}
return -EINVAL;
 }
diff --git a/tools/perf/tests/event-times.c b/tools/perf/tests/event-times.c
index 0f74ca103c41..6f9995df2c27 100644
--- a/tools/perf/tests/event-times.c
+++ b/tools/perf/tests/event-times.c
@@ -77,7 +77,7 @@ static int attach__current_disabled(struct evlist *evlist)
}
 
thread_map__put(threads);
-   return perf_evsel__enable(evsel) == 0 ? TEST_OK : TEST_FAIL;
+   return evsel__enable(evsel) == 0 ? TEST_OK : TEST_FAIL;
 }
 
 static int attach__current_enabled(struct evlist *evlist)
@@ -104,7 +104,7 @@ static int detach__disable(struct evlist *evlist)
 {
struct evsel *evsel = perf_evlist__last(evlist);
 
-   return perf_evsel__enable(evsel);
+   return evsel__enable(evsel);
 }
 
 static int attach__cpu_disabled(struct evlist *evlist)
@@ -133,7 +133,7 @@ static int attach__cpu_disabled(struct evlist *evlist)
}
 
cpu_map__put(cpus);
-   return perf_evsel__enable(evsel);
+   return evsel__enable(evsel);
 }
 
 static int attach__cpu_enabled(struct evlist *evlist)
diff --git a/tools/perf/tests/switch-tracking.c 
b/tools/perf/tests/switch-tracking.c
index ac5da4fd222f..acc4b5ff0cea 100644
--- a/tools/perf/tests/switch-tracking.c
+++ b/tools/perf/tests/switch-tracking.c
@@ -509,7 +509,7 @@ int test__switch_tracking(struct test *test __maybe_unused, 
int subtest __maybe_
goto out_err;
}
 
-   err = perf_evsel__enable(cycles_evsel);
+   err = evsel__enable(cycles_evsel);
if (err) {
pr_debug("perf_evlist__disable_event failed!\n");
goto out_err;
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 4627cc47de3e..e87c43e339d0 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -363,7 +363,7 @@ void perf_evlist__enable(struct evlist *evlist)
evlist__for_each_entry(evlist, pos) {
if (!perf_evsel__is_group_leader(pos) || !pos->fd)
continue;
-   perf_evsel__enable(pos);
+   evsel__enable(pos);
}
 
evlist->enabled = true;
@@ -1927,7 +1927,7 @@ int perf_evlist__start_sb_thread(struct evlist *evlist,
goto out_delete_evlist;
 
evlist__for_each_entry(evlist, counter) {
-   if (perf_evsel__enable(counter))
+   if (evsel__enable(counter))
goto out_delete_evlist;
}
 
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.

  1   2   3   4   5   6   7   8   9   10   >