[tip:perf/core] perf record: Synthesize namespace events for current processes

[tip-bot for Hari Bathini]

Commit-ID:  e907caf3a07ee42ef08ba689a436fd1eb99fbf62
Gitweb: http://git.kernel.org/tip/e907caf3a07ee42ef08ba689a436fd1eb99fbf62
Author: Hari Bathini 
AuthorDate: Wed, 8 Mar 2017 02:11:51 +0530
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 14 Mar 2017 15:16:09 -0300

perf record: Synthesize namespace events for current processes

Synthesize PERF_RECORD_NAMESPACES events for processes that were running prior
to invocation of perf record. The data for this is taken from /proc/$PID/ns.
These changes make way for analyzing events with regard to namespaces.

Committer notes:

Check if 'tool' is NULL in perf_event__synthesize_namespaces(), as in the
test__mmap_thread_lookup case, i.e. 'perf test Lookup mmap thread".

Testing it:

  # ps axH > /tmp/allthreads
  # perf record -a --namespaces usleep 1
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 1.169 MB perf.data (8 samples) ]
  # perf report -D | grep PERF_RECORD_NAMESPACES | wc -l
  602
  # wc -l /tmp/allthreads
  601 /tmp/allthreads
  # tail /tmp/allthreads
  16951 pts/4T  0:00 git rebase -i 
a033bf1bfacdaa25642e6bcc857a7d0f67cc3c92^
  16952 pts/4T  0:00 /bin/sh /usr/libexec/git-core/git-rebase -i 
a033bf1bfacdaa25642e6bcc857a7d0f67cc3c92^
  17176 pts/4T  0:00 git commit --amend --no-post-rewrite
  17204 pts/4T  0:00 vim /home/acme/git/linux/.git/COMMIT_EDITMSG
  18939 ?S  0:00 [kworker/2:1]
  18947 ?S  0:00 [kworker/3:0]
  18974 ?S  0:00 [kworker/1:0]
  19047 ?S  0:00 [kworker/0:1]
  19152 pts/6S+ 0:00 weechat
  19153 pts/7R+ 0:00 ps axH
  # perf report -D | grep PERF_RECORD_NAMESPACES | tail
  0 0 0x125068 [0xa0]: PERF_RECORD_NAMESPACES 17176/17176 - nr_namespaces: 7
  0 0 0x1255b8 [0xa0]: PERF_RECORD_NAMESPACES 17204/17204 - nr_namespaces: 7
  0 0 0x125df0 [0xa0]: PERF_RECORD_NAMESPACES 18939/18939 - nr_namespaces: 7
  0 0 0x125f00 [0xa0]: PERF_RECORD_NAMESPACES 18947/18947 - nr_namespaces: 7
  0 0 0x126010 [0xa0]: PERF_RECORD_NAMESPACES 18974/18974 - nr_namespaces: 7
  0 0 0x126120 [0xa0]: PERF_RECORD_NAMESPACES 19047/19047 - nr_namespaces: 7
  0 0 0x126230 [0xa0]: PERF_RECORD_NAMESPACES 19152/19152 - nr_namespaces: 7
  0 0 0x129330 [0xa0]: PERF_RECORD_NAMESPACES 19154/19154 - nr_namespaces: 7
  0 0 0x12a1f8 [0xa0]: PERF_RECORD_NAMESPACES 19155/19155 - nr_namespaces: 7
  0 0 0x12b0b8 [0xa0]: PERF_RECORD_NAMESPACES 19155/19155 - nr_namespaces: 7
  #

Humm, investigate why we got two record for the 19155 pid/tid...

Signed-off-by: Hari Bathini 
Tested-by: Arnaldo Carvalho de Melo 
Acked-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: Alexei Starovoitov 
Cc: Ananth N Mavinakayanahalli 
Cc: Aravinda Prasad 
Cc: Brendan Gregg 
Cc: Daniel Borkmann 
Cc: Eric Biederman 
Cc: Peter Zijlstra 
Cc: Sargun Dhillon 
Cc: Steven Rostedt 
Link: 
http://lkml.kernel.org/r/14889193.25309.11073854609798681633.st...@hbathini.in.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-record.c | 29 --
 tools/perf/util/event.c | 94 ++---
 tools/perf/util/event.h |  6 +++
 3 files changed, 119 insertions(+), 10 deletions(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 99562c7..04faef7 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -986,6 +986,7 @@ static int __cmd_record(struct record *rec, int argc, const 
char **argv)
 */
if (forks) {
union perf_event *event;
+   pid_t tgid;
 
event = malloc(sizeof(event->comm) + machine->id_hdr_size);
if (event == NULL) {
@@ -999,10 +1000,30 @@ static int __cmd_record(struct record *rec, int argc, 
const char **argv)
 * cannot see a correct process name for those events.
 * Synthesize COMM event to prevent it.
 */
-   perf_event__synthesize_comm(tool, event,
-   rec->evlist->workload.pid,
-   process_synthesized_event,
-   machine);
+   tgid = perf_event__synthesize_comm(tool, event,
+  rec->evlist->workload.pid,
+  process_synthesized_event,
+  machine);
+   free(event);
+
+   if (tgid == -1)
+   goto out_child;
+
+   event = 

Re: [PATCH v2 2/4] pinctrl: rockchip: convert to raw spinlock

[John Keeping]

On Wed, 15 Mar 2017 13:23:09 -0500, Julia Cartwright wrote:
> On Wed, Mar 15, 2017 at 07:16:53PM +0100, Heiko Stuebner wrote:
> > Am Mittwoch, 15. März 2017, 18:08:06 CET schrieb John Keeping:  
> > > On Wed, 15 Mar 2017 13:01:37 -0500, Julia Cartwright wrote:  
> > > > On Wed, Mar 15, 2017 at 05:46:52PM +, John Keeping wrote:  
> > > > > This lock is used from rockchip_irq_set_type() which is part of the
> > > > > irq_chip implementation and thus must use raw_spinlock_t as documented
> > > > > in Documentation/gpio/driver.txt.
> > > > > 
> > > > > Signed-off-by: John Keeping 
> > > > > Reviewed-by: Heiko Stuebner 
> > > > > Tested-by: Heiko Stuebner 
> > > > > ---
> > > > > v2: unchanged
> > > > > ---
> > > > > 
> > > > >  drivers/pinctrl/pinctrl-rockchip.c | 30 
> > > > > +++---
> > > > >  1 file changed, 15 insertions(+), 15 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/pinctrl/pinctrl-rockchip.c
> > > > > b/drivers/pinctrl/pinctrl-rockchip.c index 128c383ea7ba..8c1cae6d78d7
> > > > > 100644  
> [..]
> > > > > @@ -1295,14 +1295,14 @@ static int rockchip_set_pull(struct
> > > > > rockchip_pin_bank *bank,> > 
> > > > >   switch (ctrl->type) {
> > > > > 
> > > > >   case RK2928:
> > > > > - spin_lock_irqsave(>slock, flags);
> > > > > + raw_spin_lock_irqsave(>slock, flags);
> > > > > 
> > > > >   data = BIT(bit + 16);
> > > > >   if (pull == PIN_CONFIG_BIAS_DISABLE)
> > > > >   
> > > > >   data |= BIT(bit);  
> > > > 
> > > > This should be lifted out from under the lock.
> > > >   
> > > > >   ret = regmap_write(regmap, reg, data);  
> > > > 
> > > > How is this legal?  The regmap_write() here is going to end up acquiring
> > > > the regmap mutex.  
> > > 
> > > It's not, the spinlock can be deleted here.  I only have RK3288 hardware
> > > to test and I missed this when checking the uses of slock.  
> > 
> > That part could very well also use regmap_update_bits like the other parts.
> > Not really sure, why we use regmap_write here, but I'm also not sure, if it 
> > matters at all.  
> 
> regmap_update_bits also acquires the regmap lock, which would similarly
> be a problem here.[1]
> 
> But, if we could pull this entire operation out of the lock (and
> convince ourselves that it's okay to do so), then even better!

Yes, we can delete the lock here for the same reason as all of the
others that are removed in patch 1.

I don't think it makes much difference whether we use regmap_write or
regmap_update_bits here (although consistently using regmap_update_bits
might be nice) so I won't change it as part of this series, especially
since I don't have an RK2928 to test.


John

Re: [PATCH v2 8/8] irqchip, gicv3-its, cma: Use CMA for allocation of large device tables

[Marc Zyngier]

On 15/03/17 18:37, Robert Richter wrote:
> On 14.03.17 12:40:45, Shanker Donthineni wrote:
> 
>> I don't see anywhere in this patch, code calls explicitly CMA API to
>> allocate memory for device table.  The CMA feature is an optional in
>> kernel, and will be handled transparently inside the the DMA
>> layer. It would be nicer to not mention CMA word in the commit
>> subject.
> 
> Still CMA is *essential* and used for large tables. IMO this needs to
> be emphasized. That's the reason for using devm_alloc_coherent().
> 
>> On 03/06/2017 06:57 AM, Robert Richter wrote:
>>> The gicv3-its device table may have a size of up to 16MB. With 4k
>>> pagesize the maximum size of memory allocation is 4MB. Use CMA for
>>> allocation of large tables.
>> Just say use devm_alloc_coherent() to allocate memory.
>>
>>> We use the device managed version of dma_alloc_coherent(). Thus, we
>>> don't need to release it manually on device removal.
>>>
>>> Signed-off-by: Robert Richter 
>>> ---
>>>  drivers/irqchip/irq-gic-v3-its.c | 69 
>>> +++-
>>>  1 file changed, 40 insertions(+), 29 deletions(-)
>>>
>>> diff --git a/drivers/irqchip/irq-gic-v3-its.c 
>>> b/drivers/irqchip/irq-gic-v3-its.c
>>> index 6625b3a505f0..6d293a0165b0 100644
>>> --- a/drivers/irqchip/irq-gic-v3-its.c
>>> +++ b/drivers/irqchip/irq-gic-v3-its.c
> 
>>> @@ -876,13 +878,26 @@ static int its_setup_baser(struct its_node *its, 
>>> struct its_baser *baser,
>>> order = get_order(GITS_BASER_PAGES_MAX * psz);
>>> }
>>>  
>>> -   base = (void *)devm_get_free_pages(>dev, GFP_KERNEL | __GFP_ZERO,
>>> -  order);
>>> -   if (!base)
>>> +   base = dmam_alloc_coherent(>dev,
>>> +   PAGE_ORDER_TO_SIZE(order),
>>> +   _handle,
>>> +   GFP_KERNEL | __GFP_ZERO);
> 
>> Not just for 1st level device table, you have do a similar code
>> change when allocating memory for 2nd level device table.
> 
> The 2nd level tables are much smaller, so no need for
> dmam_alloc_coherent() there.
> 
> Though, we could use device managed devm_get_free_pages() there too.
> 
>>> +
>>> +   if (!base && order >= MAX_ORDER) {
>>> +   order = MAX_ORDER - 1;
>>> +   dev_warn(>dev, "Device Table too large, reduce ids %u->%u, 
>>> no CMA memory available\n",
>>> +   its->device_ids,
>>> +   ilog2(PAGE_ORDER_TO_SIZE(order) / (int)esz));
>>> +   goto retry_alloc_baser;
>>> +   }
>>> +
>>> +   if (!base) {
>>> +   dev_err(>dev, "Failed to allocate device table\n");
>>> return -ENOMEM;
>>> +   }
> 
>>> @@ -1698,6 +1706,9 @@ static int __init its_init_one(struct its_node *its)
>>> return err;
>>> }
>>>  
>>> +   /* Setup dma_ops for dmam_alloc_coherent() */
>>> +   arch_setup_dma_ops(>dev, 0, 0, NULL, true);
>>> +
> 
>> Why you are hard-coding DMA coherent property to true here ? It
>> breaks the MSI(x) functionally on systems where ITS hardware doesn't
>> support coherency.
> 
> Aren't current ITS tables coherent only?

No, there is no such guarantee. Actually, there is strictly no need for
coherency, as the ITS tables are only written by the ITS itself, for its
own purpose.

The only things that may benefit from coherency are the property table
and the command queue.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH v4 11/18] dt-bindings: power: supply: add AXP20X/AXP22X battery DT binding

[Quentin Schulz]

Hi,

On 15/03/2017 23:28, Sebastian Reichel wrote:
> Hi,
> 
> On Wed, Mar 15, 2017 at 11:55:30AM +0100, Quentin Schulz wrote:
>> The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply.
>>
>> This patch adds the DT binding documentation for the battery power
>> supply which gets various data from the PMIC, such as the battery status
>> (charging, discharging, full, dead), current max limit, current current,
>> battery capacity (in percentage), voltage max and min limits, current
>> voltage and battery capacity (in Ah).
>>
>> Signed-off-by: Quentin Schulz 
>> Acked-by: Chen-Yu Tsai 
>> Acked-by: Maxime Ripard 
> 
> I suggest to do "s/battery-power-supply/battery-fuel-gauge/g"
> 

The IP is way more than a simple fuel gauge, you have info about the
voltage, current, you can set different things, even though you have the
percentage of the battery returned by the PMIC.

Does it really make sense to rename it that way?

Thanks,
Quentin

>> ---
>>
>> v4:
>>  - added monitored-battery optional property,
>>  - added example with battery,
>>
>> v3:
>>  - removed constant charge current property, now should use the WIP
>>  battery framework,
>>
>> v2:
>>  - changed DT node name from ac_power_supply to ac-power-supply,
> 
> ac-power-supply?
> 
> -- Sebastian
> 
>>  - removed io-channels and io-channel-names from DT (the IIO mapping is
>>  done in the IIO ADC driver now),
>>  - added x-powers,constant-charge-current property to set the maximal
>>  default constant current charge of the battery,
>>  .../bindings/power/supply/axp20x_battery.txt   | 30 
>> ++
>>  1 file changed, 30 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt 
>> b/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
>> new file mode 100644
>> index 000..89cb7a2
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
>> @@ -0,0 +1,30 @@
>> +AXP20x and AXP22x battery power supply
>> +
>> +Required Properties:
>> + - compatible, one of:
>> +"x-powers,axp209-battery-power-supply"
>> +"x-powers,axp221-battery-power-supply"
>> +
>> +Optional properties:
>> + - monitored-battery, phandle to a fixed battery
>> +
>> +This node is a subnode of the axp20x/axp22x PMIC.
>> +
>> +The AXP20X and AXP22X can read the battery voltage, charge and discharge
>> +currents of the battery by reading ADC channels from the AXP20X/AXP22X
>> +ADC.
>> +
>> +Example:
>> +
>> +battery: battery {
>> +compatible = "fixed-battery";
>> +voltage-min-design-microvolt = <320>;
>> +constant-charge-microamp = <30>;
>> +};
>> +
>> + {
>> +battery_power_supply: battery-power-supply {
>> +compatible = "x-powers,axp209-battery-power-supply";
>> +monitored-battery = <>;
>> +}
>> +};
>> -- 
>> 2.9.3
>>
>>
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 4/4] eeprom: at24: Add OF device ID table

[Andy Shevchenko]

On Wed, Mar 15, 2017 at 1:39 PM, Javier Martinez Canillas
 wrote:
> Hello Andy,
>
> On 03/15/2017 08:21 AM, Andy Shevchenko wrote:
>> On Wed, Mar 15, 2017 at 12:58 PM, Javier Martinez Canillas
>>  wrote:
>>> On 03/15/2017 04:58 AM, Wolfram Sang wrote:
>>
>>> Unfortunately some maintainers do and don't accept patches adding I2C tables
>>> only to have module autoloading working so I still think it should be fixed.
>>
>> Wait, how does it work for now?!

> It only works if you have an I2C device ID table, but that may not be the case
> for DT-only drivers that could only have an OF device ID table. In the latter
> case module autoload won't work.

OK.

>> Sounds for me you are trying to solve non-existing issue.

> It's an existing issue. You _must_ have an I2C device ID table if you want to
> autload a device driver which is superfluous for DT-only drivers.

Okay, can you scope only affected drivers then? Looking to spread
patches from you over all drivers I dunno they are all affected right
now.

P.S. Personally I agree with maintainers who do *not* apply this. Sorry.

-- 
With Best Regards,
Andy Shevchenko

Re: [scsi] scsi: ufshcd-platform: remove the useless cast in ERR_PTR/IS_ERR

[Subhash Jadavani]

On 2017-03-14 05:19, Tomas Winkler wrote:

IS_ERR and ERR_PTR already forcefully cast their argument,
hence there is no need for additional (complex) casting.

Signed-off-by: Tomas Winkler 
---
 drivers/scsi/ufs/ufshcd-pltfrm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c 
b/drivers/scsi/ufs/ufshcd-pltfrm.c

index a72a4ba78125..8e5e6c04c035 100644
--- a/drivers/scsi/ufs/ufshcd-pltfrm.c
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -309,8 +309,8 @@ int ufshcd_pltfrm_init(struct platform_device 
*pdev,


mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
mmio_base = devm_ioremap_resource(dev, mem_res);
-   if (IS_ERR(*(void **)_base)) {
-   err = PTR_ERR(*(void **)_base);
+   if (IS_ERR(mmio_base)) {
+   err = PTR_ERR(mmio_base);
goto out;
}


LGTM.
Reviewed-by: Subhash Jadavani 

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

[PATCH 2/2] kthread, cgroup: close race window where new kthreads can be migrated to non-root cgroups

[Tejun Heo]

Creation of a kthread goes through a couple interlocked stages between
the kthread itself and its creator.  Once the new kthread starts
running, it initializes itself and wakes up the creator.  The creator
then can further configure the kthread and then let it start doing its
job by waking it up.

In this configuration-by-creator stage, the creator is the only one
that can wake it up but the kthread is visible to userland.  When
altering the kthread's attributes from userland is allowed, this is
fine; however, for cases where CPU affinity is critical,
kthread_bind() is used to first disable affinity changes from userland
and then set the affinity.  This also prevents the kthread from being
migrated into non-root cgroups as that can affect the CPU affinity and
many other things.

Unfortunately, the cgroup side of protection is racy.  While the
PF_NO_SETAFFINITY flag prevents further migrations, userland can win
the race before the creator sets the flag with kthread_bind() and put
the kthread in a non-root cgroup, which can lead to all sorts of
problems including incorrect CPU affinity and starvation.

This bug got triggered by userland which periodically tries to migrate
all processes in the root cpuset cgroup to a non-root one.  Per-cpu
workqueue workers got caught while being created and ended up with
incorrected CPU affinity breaking concurrency management and sometimes
stalling workqueue execution.

This patch introduces KTHREAD_INITIALIZED which is set after the
kthread finishes initialization.  cgroup core closes the race window
by testing kthread_initialized() and rejecting migration accordingly.

It'd be better to wait for the initialization instead of failing but I
couldn't think of a way of implementing that without adding either a
new PF flag, or sleeping and retrying from waiting side.  Even if
userland depends on changing cgroup membership of a kthread, it either
has to be synchronized with kthread_create() or periodically repeat,
so it's unlikely that this would break anything.

Signed-off-by: Tejun Heo 
Cc: Oleg Nesterov 
Cc: Linus Torvalds 
Cc: Andrew Morton 
Cc: Peter Zijlstra (Intel) 
Cc: Thomas Gleixner 
Reported-and-debugged-by: Chris Mason 
Cc: sta...@vger.kernel.org # v4.3+ (we can't close the race < v4.3)
---
 include/linux/kthread.h |1 +
 kernel/cgroup/cgroup.c  |   10 ++
 kernel/kthread.c|   21 -
 3 files changed, 27 insertions(+), 5 deletions(-)

--- a/include/linux/kthread.h
+++ b/include/linux/kthread.h
@@ -49,6 +49,7 @@ struct task_struct *kthread_create_on_cp
 })
 
 void free_kthread_struct(struct task_struct *k);
+bool kthread_initialized(struct task_struct *k);
 void kthread_bind(struct task_struct *k, unsigned int cpu);
 void kthread_bind_mask(struct task_struct *k, const struct cpumask *mask);
 int kthread_stop(struct task_struct *k);
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -2425,11 +2425,13 @@ ssize_t __cgroup_procs_write(struct kern
tsk = tsk->group_leader;
 
/*
-* Workqueue threads may acquire PF_NO_SETAFFINITY and become
-* trapped in a cpuset, or RT worker may be born in a cgroup
-* with no rt_runtime allocated.  Just say no.
+* kthreads may acquire PF_NO_SETAFFINITY during initialization.
+* If userland migrates such kthread to a non-root cgroup, it can
+* become trapped in a cpuset, or RT kthread may be born in a
+* cgroup with no rt_runtime allocated.  Just say no.
 */
-   if (tsk == kthreadd_task || (tsk->flags & PF_NO_SETAFFINITY)) {
+   if (tsk == kthreadd_task || (tsk->flags & PF_NO_SETAFFINITY) ||
+   ((tsk->flags & PF_KTHREAD) && !kthread_initialized(tsk))) {
ret = -EINVAL;
goto out_unlock_rcu;
}
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -50,6 +50,7 @@ struct kthread {
 
 enum KTHREAD_BITS {
KTHREAD_IS_PER_CPU = 0,
+   KTHREAD_INITIALIZED,
KTHREAD_SHOULD_STOP,
KTHREAD_SHOULD_PARK,
KTHREAD_IS_PARKED,
@@ -57,7 +58,7 @@ enum KTHREAD_BITS {
 
 static inline void set_kthread_struct(void *kthread)
 {
-   /* paired with smp_read_data_barrier_depends() in to_kthread() */
+   /* paired with smp_read_barrier_depends() in to_kthread() */
smp_wmb();
 
/*
@@ -95,6 +96,23 @@ void free_kthread_struct(struct task_str
 }
 
 /**
+ * kthread_initialized - has the kthread finished initialization?
+ * @k: thread created by kthread_create().
+ *
+ * Test whether @k, which must be a kthread, finished initialization and is
+ * ready to execute the threadfn.  The kthread owner finishes
+ * initialization by waking up the new kthread for the first time.  If this
+ * function returns %false, the kthread owner could still be configuring
+ * the kthread.
+ */
+bool 

Re: [PATCH 3/6] cpufreq: schedutil: ensure max frequency while running RT/DL tasks

[Rafael J. Wysocki]

On Wed, Mar 15, 2017 at 3:40 PM, Patrick Bellasi
 wrote:
> On 15-Mar 12:52, Rafael J. Wysocki wrote:
>> On Friday, March 03, 2017 12:38:30 PM Patrick Bellasi wrote:
>> > On 03-Mar 14:01, Viresh Kumar wrote:
>> > > On 02-03-17, 15:45, Patrick Bellasi wrote:
>> > > > diff --git a/kernel/sched/cpufreq_schedutil.c 
>> > > > b/kernel/sched/cpufreq_schedutil.c
>> > > > @@ -293,15 +305,29 @@ static void sugov_update_shared(struct 
>> > > > update_util_data *hook, u64 time,
>> > > > if (curr == sg_policy->thread)
>> > > > goto done;
>> > > >
>> > > > +   /*
>> > > > +* While RT/DL tasks are running we do not want FAIR tasks to
>> > > > +* overwrite this CPU's flags, still we can update utilization 
>> > > > and
>> > > > +* frequency (if required/possible) to be fair with these 
>> > > > tasks.
>> > > > +*/
>> > > > +   rt_mode = task_has_dl_policy(curr) ||
>> > > > + task_has_rt_policy(curr) ||
>> > > > + (flags & SCHED_CPUFREQ_RT_DL);
>> > > > +   if (rt_mode)
>> > > > +   sg_cpu->flags |= flags;
>> > > > +   else
>> > > > +   sg_cpu->flags = flags;
>> > >
>> > > This looks so hacked up :)
>> >
>> > It is... a bit... :)
>> >
>> > > Wouldn't it be better to let the scheduler tell us what all kind of 
>> > > tasks it has
>> > > in the rq of a CPU and pass a mask of flags?
>> >
>> > That would definitively report a more consistent view of what's going
>> > on on each CPU.
>> >
>> > > I think it wouldn't be difficult (or time consuming) for the
>> > > scheduler to know that, but I am not 100% sure.
>> >
>> > Main issue perhaps is that cpufreq_update_{util,this_cpu} are
>> > currently called by the scheduling classes codes and not from the core
>> > scheduler. However I agree that it should be possible to build up such
>> > information and make it available to the scheduling classes code.
>> >
>> > I'll have a look at that.
>> >
>> > > IOW, the flags field in cpufreq_update_util() will represent all tasks 
>> > > in the
>> > > rq, instead of just the task that is getting enqueued/dequeued..
>> > >
>> > > And obviously we need to get some utilization numbers for the RT and DL 
>> > > tasks
>> > > going forward, switching to max isn't going to work for ever :)
>> >
>> > Regarding this last point, there are WIP patches Juri is working on to
>> > feed DL demands to schedutil, his presentation at last ELC partially
>> > covers these developments:
>> >   
>> > https://www.youtube.com/watch?v=wzrcWNIneWY=37=PLbzoR-pLrL6pSlkQDW7RpnNLuxPq6WVUR
>> >
>> > Instead, RT tasks are currently covered by an rt_avg metric which we
>> > already know is not fitting for most purposes.
>> > It seems that the main goal is twofold: move people to DL whenever
>> > possible otherwise live with the go-to-max policy which is the only
>> > sensible solution to satisfy the RT's class main goal, i.e. latency
>> > reduction.
>> >
>> > Of course such a go-to-max policy for all RT tasks we already know
>> > that is going to destroy energy on many different mobile scenarios.
>> >
>> > As a possible mitigation for that, while still being compliant with
>> > the main RT's class goal, we recently posted the SchedTune v3
>> > proposal:
>> >   https://lkml.org/lkml/2017/2/28/355
>> >
>> > In that proposal, the simple usage of CGroups and the new capacity_max
>> > attribute of the (existing) CPU controller should allow to define what
>> > is the "max" value which is just enough to match the latency
>> > constraints of a mobile application without sacrificing too much
>> > energy.
>
> Given the following interesting question, let's add Thomas Gleixner to
> the discussion, which can be interested in sharing his viewpoint.
>
>> And who's going to figure out what "max" value is most suitable?  And how?
>
> That's usually up to the system profiling which is part of the
> platform optimizations and tunings.
> For example it's possible to run  experiments to measure the bandwidth
> and (completion) latency requirements from the RT workloads.
>
> It's something which people developing embedded/mobile systems are
> quite aware of.

Well, I was expecting an answer like this to be honest and let me say
that it is not too convincing from my perspective.

At least throwing embedded and mobile into one bag seems to be a
stretch, because the usage patterns of those two groups are quite
different, even though they may be similar from the hardware POV.

Mobile are mostly used as general-purpose computers nowadays (and I
guess we're essentially talking about anything running Android, not
just phones, aren't we?) with applications installed by users rather
than by system integrators, so I'm doubtful about the viability of the
"system integrators should take care of it" assumption in this
particular case.

> I'm also quite confident on saying that most of
> them can agree that just going to the max OPP, each and every time a
> 

Re: [PATCH v3 4/8] mm, page_alloc: count movable pages when stealing from pageblock

[Joonsoo Kim]

On Tue, Mar 07, 2017 at 02:15:41PM +0100, Vlastimil Babka wrote:
> When stealing pages from pageblock of a different migratetype, we count how
> many free pages were stolen, and change the pageblock's migratetype if more
> than half of the pageblock was free. This might be too conservative, as there
> might be other pages that are not free, but were allocated with the same
> migratetype as our allocation requested.

I think that too conservative is good for movable case. In my experiments,
fragmentation spreads out when unmovable/reclaimable pageblock is
changed to movable pageblock prematurely ('prematurely' means that
allocated unmovable pages remains). As you said below, movable allocations
falling back to other pageblocks don't causes permanent fragmentation.
Therefore, we don't need to be less conservative for movable
allocation. So, how about following change to keep the criteria for
movable allocation conservative even with this counting improvement?

threshold = (1 << (pageblock_order - 1));
if (start_type == MIGRATE_MOVABLE)
threshold += (1 << (pageblock_order - 2));

if (free_pages + alike_pages >= threshold)
...

Thanks.

[PATCH v1 7/7] dt-bindings: document rockchip rk3328-evb board

[cl]

From: Chen Liang 

Use "rockchip,rk3328-evb" compatible string for Rockchip RK3328
evaluation board.

Signed-off-by: Chen Liang 
---
 Documentation/devicetree/bindings/arm/rockchip.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt 
b/Documentation/devicetree/bindings/arm/rockchip.txt
index cc4ace6..17611cd 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -141,3 +141,7 @@ Rockchip platforms device tree bindings
 - Tronsmart Orion R68 Meta
 Required root node properties:
   - compatible = "tronsmart,orion-r68-meta", "rockchip,rk3368";
+
+- Rockchip RK3328 evb:
+Required root node properties:
+  - compatible = "rockchip,rk3328-evb", "rockchip,rk3328";
-- 
1.9.1

[PATCH 2/4] staging: atomisp: fix inconsistent indenting

[Daeseok Youn]

Fix warnings from the smatch tool

atomisp_cmd.c:5698
   atomisp_set_fmt_to_snr() warn: inconsistent indenting
atomisp_cmd.c:5714
   atomisp_set_fmt_to_snr() warn: inconsistent indenting

Signed-off-by: Daeseok Youn 
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
index 9c3ba11..6160119 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
@@ -5693,7 +5693,7 @@ static int atomisp_set_fmt_to_snr(struct video_device 
*vdev,
/* Disable dvs if resolution can't be supported by sensor */
if (asd->params.video_dis_en &&
source_pad == ATOMISP_SUBDEV_PAD_SOURCE_VIDEO) {
-   vformat.which = V4L2_SUBDEV_FORMAT_TRY;
+   vformat.which = V4L2_SUBDEV_FORMAT_TRY;
ret = v4l2_subdev_call(isp->inputs[asd->input_curr].camera,
pad, set_fmt, _cfg, );
if (ret)
@@ -5710,7 +5710,7 @@ static int atomisp_set_fmt_to_snr(struct video_device 
*vdev,
}
dev_dbg(isp->dev, "sensor width: %d, height: %d\n",
ffmt->width, ffmt->height);
-vformat.which = V4L2_SUBDEV_FORMAT_ACTIVE;
+   vformat.which = V4L2_SUBDEV_FORMAT_ACTIVE;
ret = v4l2_subdev_call(isp->inputs[asd->input_curr].camera, pad,
   set_fmt, NULL, );
if (ret)
-- 
1.9.1

[PATCH 4/4] staging: atomisp: fix "alignment should match open parenthesis"

[Daeseok Youn]

Fix checkpatch.pl issues in atomisp_cmd.c
 : "CHECK: Alignment should match open parenthesis"

Signed-off-by: Daeseok Youn 
---
 .../media/atomisp/pci/atomisp2/atomisp_cmd.c   | 179 +++--
 1 file changed, 90 insertions(+), 89 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
index 82e7382..d97a8df 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
@@ -158,7 +158,7 @@ static unsigned short atomisp_get_sensor_fps(struct 
atomisp_sub_device *asd)
unsigned short fps;
 
if (v4l2_subdev_call(isp->inputs[asd->input_curr].camera,
-   video, g_frame_interval, _interval)) {
+   video, g_frame_interval, _interval)) {
fps = 0;
} else {
if (frame_interval.interval.numerator)
@@ -481,7 +481,7 @@ static void atomisp_3a_stats_ready_event(struct 
atomisp_sub_device *asd, uint8_t
 }
 
 static void atomisp_metadata_ready_event(struct atomisp_sub_device *asd,
-   enum atomisp_metadata_type 
md_type)
+enum atomisp_metadata_type md_type)
 {
struct v4l2_event event = {0};
 
@@ -622,14 +622,14 @@ irqreturn_t atomisp_isr(int irq, void *dev)
}
if (irq_infos & CSS_IRQ_INFO_EVENTS_READY)
atomic_set(>sequence,
-   atomic_read(>sequence_temp));
+  atomic_read(>sequence_temp));
}
 
if (irq_infos & CSS_IRQ_INFO_CSS_RECEIVER_SOF)
irq_infos &= ~CSS_IRQ_INFO_CSS_RECEIVER_SOF;
 
if ((irq_infos & CSS_IRQ_INFO_INPUT_SYSTEM_ERROR) ||
-   (irq_infos & CSS_IRQ_INFO_IF_ERROR)) {
+   (irq_infos & CSS_IRQ_INFO_IF_ERROR)) {
/* handle mipi receiver error */
u32 rx_infos;
enum ia_css_csi2_port port;
@@ -684,7 +684,7 @@ void atomisp_clear_css_buffer_counters(struct 
atomisp_sub_device *asd)
memset(asd->s3a_bufs_in_css, 0, sizeof(asd->s3a_bufs_in_css));
for (i = 0; i < ATOMISP_INPUT_STREAM_NUM; i++)
memset(asd->metadata_bufs_in_css[i], 0,
-   sizeof(asd->metadata_bufs_in_css[i]));
+  sizeof(asd->metadata_bufs_in_css[i]));
asd->dis_bufs_in_css = 0;
asd->video_out_capture.buffers_in_css = 0;
asd->video_out_vf.buffers_in_css = 0;
@@ -804,7 +804,7 @@ void atomisp_flush_params_queue(struct atomisp_video_pipe 
*pipe)
 
while (!list_empty(>per_frame_params)) {
param = list_entry(pipe->per_frame_params.next,
-   struct atomisp_css_params_with_list, list);
+  struct atomisp_css_params_with_list, list);
list_del(>list);
atomisp_free_css_parameters(>params);
atomisp_kernel_free(param);
@@ -983,7 +983,7 @@ void atomisp_buf_done(struct atomisp_sub_device *asd, int 
error,
memset(, 0, sizeof(struct atomisp_css_buffer));
buffer.css_buffer.type = buf_type;
err = atomisp_css_dequeue_buffer(asd, stream_id, css_pipe_id,
-   buf_type, );
+buf_type, );
if (err) {
dev_err(isp->dev,
"atomisp_css_dequeue_buffer failed: 0x%x\n", err);
@@ -1000,12 +1000,12 @@ void atomisp_buf_done(struct atomisp_sub_device *asd, 
int error,
switch (buf_type) {
case CSS_BUFFER_TYPE_3A_STATISTICS:
list_for_each_entry_safe(s3a_buf, _s3a_buf_tmp,
-   >s3a_stats_in_css, list) {
+>s3a_stats_in_css, list) {
if (s3a_buf->s3a_data ==
buffer.css_buffer.data.stats_3a) {
list_del_init(_buf->list);
list_add_tail(_buf->list,
-   >s3a_stats_ready);
+ >s3a_stats_ready);
break;
}
}
@@ -1021,12 +1021,12 @@ void atomisp_buf_done(struct atomisp_sub_device *asd, 
int error,
 
md_type = atomisp_get_metadata_type(asd, css_pipe_id);
list_for_each_entry_safe(md_buf, _md_buf_tmp,
-   >metadata_in_css[md_type], list) {
+>metadata_in_css[md_type], list) {
if (md_buf->metadata ==
buffer.css_buffer.data.metadata) {
list_del_init(_buf->list);
list_add_tail(_buf->list,
-

[PATCH 3/4] staging: atomisp: remove useless #ifdef ISP2401 on top of atomisp_cmd.c

[Daeseok Youn]

There is no reason to have "#ifdef ISP2401" condition
on top of atomisp_cmd.c file

Signed-off-by: Daeseok Youn 
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
index 6160119..82e7382 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
@@ -1,6 +1,3 @@
-#ifdef ISP2401
-
-#endif
 /*
  * Support for Medifield PNW Camera Imaging ISP subsystem.
  *
-- 
1.9.1

lening bieden

[SAFETY NET CREDIT]

Goede dag,

 Dit is vangnet krediet leningen aan te bieden.

  Vangnet CREDIT biedt flexibele en betaalbare leningen voor welk doel u te 
helpen uw doelen te bereiken. we lening tegen lage rente van 3%. Hier zijn een 
aantal belangrijke kenmerken van de persoonlijke lening aangeboden door vangnet 
CREDIT. Hier zijn de Loan Factoren we werken met de toonaangevende Britse 
makelaars die toegang hebben tot de top kredietverstrekkers hebben en in staat 
zijn om de beste financiële oplossing tegen een betaalbare price.Please vinden 
als u geïnteresseerd bent vriendelijk contact met ons op via deze e-mail: 
safetynetcred...@gmail.com

Na de reactie, zal u een aanvraag voor een lening te vullen ontvangen. Geen 
sociale zekerheid en geen credit check, 100% gegarandeerd.

Het zal ons een eer zijn als u ons toelaten om u van dienst zijn.


INFORMATIE NODIG

Jullie namen:
Adres: ...
Telefoon: ...
Benodigd 
Looptijd: ...
Beroep: ...
Maandelijks Inkomen Level: 
Geslacht: ...
Geboortedatum: 
Staat: ..
Land: ..
Doel: .

Ontmoeting uw financiële behoeften is onze trots.


Dr.John Mahama.

[PATCH 0/4] arm64: dts: rockchip: add more nodes for RK3368 SoCs

[Jianqun Xu]

Add more nodes to RK3368 core dts file for RK3368 SoCs, and disable mailbox
in core dts file.

Jianqun Xu (4):
  ASoC: rockchip: add bindings for rk3368 i2s
  arm64: dts: rockchip: add i2s nodes support for RK3368 SoCs
  arm64: dts: rockchip: add amba node support for RK3368 SoCs
  arm64: dts: rockchip: disable mailbox of RK3368 SoCs defaultly

 .../devicetree/bindings/sound/rockchip-i2s.txt |  1 +
 arch/arm64/boot/dts/rockchip/rk3368.dtsi   | 70 ++
 2 files changed, 71 insertions(+)

-- 
1.9.1

Re: [PATCH 2/2] x86/mm/KASLR: Correct the upper boundary of KALSR mm regions if adjacent to EFI

[Baoquan He]

PING!

Is there any suggestion for this code bug fix?

Boris added comment in patch 1/2 thread that it can also be fixed by
swapping the naming - EFI_VA_START and EFI_VA_END. As he said the
swapping can remove the confusion about the naming, while the con is
changing it now could confuse more people who have the current
mental picture of the mapping direction.

And there's also a well known similar use case, stack, like stack_end
naming in arch/x86/boot/main.c which is the low addr boundary of stack
region.

Any idea?

Thanks
Baoquan

On 03/08/17 at 03:47pm, Baoquan He wrote:
> EFI allocates runtime services regions top-down, starting from EFI_VA_START
> to EFI_VA_END. So EFI_VA_START is bigger than EFI_VA_END and is the end of
> EFI region. The upper boundary of memory regions randomized by KASLR should
> be EFI_VA_END if it's adjacent to EFI region, but not EFI_VA_START.
> 
> Correct it in this patch.
> 
> Signed-off-by: Baoquan He 
> ---
>  arch/x86/mm/kaslr.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
> index 887e571..aed2064 100644
> --- a/arch/x86/mm/kaslr.c
> +++ b/arch/x86/mm/kaslr.c
> @@ -48,7 +48,7 @@ static const unsigned long vaddr_start = __PAGE_OFFSET_BASE;
>  #if defined(CONFIG_X86_ESPFIX64)
>  static const unsigned long vaddr_end = ESPFIX_BASE_ADDR;
>  #elif defined(CONFIG_EFI)
> -static const unsigned long vaddr_end = EFI_VA_START;
> +static const unsigned long vaddr_end = EFI_VA_END;
>  #else
>  static const unsigned long vaddr_end = __START_KERNEL_map;
>  #endif
> @@ -105,7 +105,7 @@ void __init kernel_randomize_memory(void)
>*/
>   BUILD_BUG_ON(vaddr_start >= vaddr_end);
>   BUILD_BUG_ON(IS_ENABLED(CONFIG_X86_ESPFIX64) &&
> -  vaddr_end >= EFI_VA_START);
> +  vaddr_end >= EFI_VA_END);
>   BUILD_BUG_ON((IS_ENABLED(CONFIG_X86_ESPFIX64) ||
> IS_ENABLED(CONFIG_EFI)) &&
>vaddr_end >= __START_KERNEL_map);
> -- 
> 2.5.5
> 

[PATCH 1/4] ASoC: rockchip: add bindings for rk3368 i2s

[Jianqun Xu]

Add devicetree bindings for i2s controller found on rk3368
processors from rockchip.

Signed-off-by: Jianqun Xu 
---
 Documentation/devicetree/bindings/sound/rockchip-i2s.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/sound/rockchip-i2s.txt 
b/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
index a6600f6..206aba1 100644
--- a/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
@@ -9,6 +9,7 @@ Required properties:
- "rockchip,rk3066-i2s": for rk3066
- "rockchip,rk3188-i2s", "rockchip,rk3066-i2s": for rk3188
- "rockchip,rk3288-i2s", "rockchip,rk3066-i2s": for rk3288
+   - "rockchip,rk3368-i2s", "rockchip,rk3066-i2s": for rk3368
- "rockchip,rk3399-i2s", "rockchip,rk3066-i2s": for rk3399
 - reg: physical base address of the controller and length of memory mapped
   region.
-- 
1.9.1

Re: [PATCH] serial: 8250: 8250_core: Use dev_name() during request_irq()

[Jisheng Zhang]

On Tue, 14 Mar 2017 17:59:01 +0200 Andy Shevchenko wrote:

> On Tue, Mar 14, 2017 at 3:44 PM, Vignesh R  wrote:
> > On Monday 13 March 2017 01:35 AM, Andy Shevchenko wrote:  
> >> On Wed, Mar 8, 2017 at 2:19 PM, Vignesh R  wrote:  
> >>> Passing "serial" as name during request_irq() results in all serial port
> >>> irqs have same name. This does not help much to easily identify which
> >>> irq belongs to which serial port instance. Therefore pass dev_name()
> >>> during request_irq() so that better identifiable name is listed for
> >>> serial ports in cat /proc/interrupts output.
> >>>
> >>> Output of cat /proc/interrupts
> >>> Before this patch:
> >>>  26:689  0 GICv2 309 Edge  serial
> >>> After this patch:
> >>>  26:696  0 GICv2 309 Edge  2530c00.serial  
> 
> >  But, this change is making interrupt name more descriptive  
> 
> It doesn't in PCI case, it makes it worse.

indeed, in PCI case, I see 

4: ... 00:03.3

what about "dev_driver_string(up->port.dev)[dev_name(up->port.dev)]" as
we did for ahci case?

Thanks

[PATCH 2/4] arm64: dts: rockchip: add i2s nodes support for RK3368 SoCs

[Jianqun Xu]

I2S of RK3368 SoCs keep same as RK3066 SoCs found on Rockchip,
add nodes to support them.

Signed-off-by: Jianqun Xu 
---
 arch/arm64/boot/dts/rockchip/rk3368.dtsi | 38 
 1 file changed, 38 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index a635adc..a6eb3e4 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -684,6 +684,30 @@
interrupts = ;
};
 
+   i2s0: i2s0@ff89 {
+   compatible = "rockchip,rk3368-i2s", "rockchip,rk3066-i2s";
+   reg = <0x0 0xff89 0x0 0x1000>;
+   interrupts = ;
+   dmas = <_bus 6>, <_bus 7>;
+   dma-names = "tx", "rx";
+   clock-names = "i2s_clk", "i2s_hclk";
+   clocks = < SCLK_I2S_2CH>, < HCLK_I2S_2CH>;
+   status = "disabled";
+   };
+
+   i2s1: i2s1@ff898000 {
+   compatible = "rockchip,rk3368-i2s", "rockchip,rk3066-i2s";
+   reg = <0x0 0xff898000 0x0 0x1000>;
+   interrupts = ;
+   dmas = <_bus 0>, <_bus 1>;
+   dma-names = "tx", "rx";
+   clock-names = "i2s_clk", "i2s_hclk";
+   clocks = < SCLK_I2S_8CH>, < HCLK_I2S_8CH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <>;
+   status = "disabled";
+   };
+
gic: interrupt-controller@ffb71000 {
compatible = "arm,gic-400";
interrupt-controller;
@@ -886,6 +910,20 @@
};
};
 
+   i2s {
+   i2s1: i2s1 {
+   rockchip,pins = <2 12 RK_FUNC_1 
_pull_none>,
+   <2 13 RK_FUNC_1 
_pull_none>,
+   <2 14 RK_FUNC_1 
_pull_none>,
+   <2 15 RK_FUNC_1 
_pull_none>,
+   <2 16 RK_FUNC_1 
_pull_none>,
+   <2 17 RK_FUNC_1 
_pull_none>,
+   <2 18 RK_FUNC_1 
_pull_none>,
+   <2 19 RK_FUNC_1 
_pull_none>,
+   <2 20 RK_FUNC_1 
_pull_none>;
+   };
+   };
+
pwm0 {
pwm0_pin: pwm0-pin {
rockchip,pins = <3 8 RK_FUNC_2 _pull_none>;
-- 
1.9.1

[PATCH 3/4] arm64: dts: rockchip: add amba node support for RK3368 SoCs

[Jianqun Xu]

There are two dmacs found on RK3368 SoCs, peripher dmac and bus dmac,
and the dmacs are same as previous SoCs' dmac.

Signed-off-by: Jianqun Xu 
---
 arch/arm64/boot/dts/rockchip/rk3368.dtsi | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index a6eb3e4..90f72c2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -204,6 +204,37 @@
 <_b2>, <_b3>;
};
 
+   amba {
+   compatible = "simple-bus";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   dmac_peri: dma-controller@ff25 {
+   compatible = "arm,pl330", "arm,primecell";
+   reg = <0x0 0xff25 0x0 0x4000>;
+   interrupts = ,
+;
+   #dma-cells = <1>;
+   clocks = < ACLK_DMAC_PERI>;
+   clock-names = "apb_pclk";
+   arm,pl330-broken-no-flushp;
+   peripherals-req-type-burst;
+   };
+
+   dmac_bus: dma-controller@ff60 {
+   compatible = "arm,pl330", "arm,primecell";
+   reg = <0x0 0xff60 0x0 0x4000>;
+   interrupts = ,
+;
+   #dma-cells = <1>;
+   clocks = < ACLK_DMAC_BUS>;
+   clock-names = "apb_pclk";
+   arm,pl330-broken-no-flushp;
+   peripherals-req-type-burst;
+   };
+   };
+
psci {
compatible = "arm,psci-0.2";
method = "smc";
-- 
1.9.1

[PATCH 4/4] arm64: dts: rockchip: disable mailbox of RK3368 SoCs defaultly

[Jianqun Xu]

Default to disable mailbox in rk3368 core dts file.

Signed-off-by: Jianqun Xu 
---
 arch/arm64/boot/dts/rockchip/rk3368.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index 90f72c2..36aeed0 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -662,6 +662,7 @@
clocks = < PCLK_MAILBOX>;
clock-names = "pclk_mailbox";
#mbox-cells = <1>;
+   status = "disabled";
};
 
pmugrf: syscon@ff738000 {
-- 
1.9.1

Re: [PATCH v2 1/6] powerpc/perf: Define big-endian version of perf_mem_data_src

[Michael Ellerman]

Hi Peter,

Peter Zijlstra  writes:
> On Tue, Mar 14, 2017 at 02:31:51PM +0530, Madhavan Srinivasan wrote:
>
>> >Huh? PPC hasn't yet implemented this? Then why are you fixing it?
>> 
>> yes, PPC hasn't implemented this (until now).
>
> until now where?

On powerpc there is currently no kernel support for filling the data_src
value with anything meaningful.

A user can still request PERF_SAMPLE_DATA_SRC (perf report -d), but they
just get the default value from perf_sample_data_init(), which is
PERF_MEM_NA.

Though even that is currently broken with a big endian perf tool.

>> And did not understand "Then why are you fixing it?"
>
> I see no implementation; so why are you poking at it.

Maddy has posted an implementation of the kernel part for powerpc in
patch 2 of this series, but maybe you're not on Cc?


Regardless of us wanting to do the kernel side on powerpc, the current
API is broken on big endian.

That's because in the kernel the PERF_MEM_NA value is constructed using
shifts:

  /* TLB access */
  #define PERF_MEM_TLB_NA   0x01 /* not available */
  ...
  #define PERF_MEM_TLB_SHIFT26
  
  #define PERF_MEM_S(a, s) \
(((__u64)PERF_MEM_##a##_##s) << PERF_MEM_##a##_SHIFT)
  
  #define PERF_MEM_NA (PERF_MEM_S(OP, NA)   |\
PERF_MEM_S(LVL, NA)   |\
PERF_MEM_S(SNOOP, NA) |\
PERF_MEM_S(LOCK, NA)  |\
PERF_MEM_S(TLB, NA))

Which works out as:

  ((0x01 << 0) | (0x01 << 5) | (0x01 << 19) | (0x01 << 24) | (0x01 << 26))


Which means the PERF_MEM_NA value comes out of the kernel as 0x5080021
in CPU endian.

But then in the perf tool, the code uses the bitfields to inspect the
value, and currently the bitfields are defined using little endian
ordering.

So eg. in perf_mem__tlb_scnprintf() we see:
  data_src->val = 0x5080021
 op = 0x0
lvl = 0x0
  snoop = 0x0
   lock = 0x0
   dtlb = 0x0
   rsvd = 0x5080021


So this patch does what I think is the minimal fix, of changing the
definition of the bitfields to match the values that are already
exported by the kernel on big endian. And it makes no change on little
endian.

cheers

Re: [lkp-robot] [f2fs] 4ac912427c: -33.7% aim7.jobs-per-min regression

[Ye Xiaolong]

On 03/15, Jaegeuk Kim wrote:
>On 03/14, Ye Xiaolong wrote:
>> On 03/14, Chao Yu wrote:
>> >On 2017/3/14 3:22, Jaegeuk Kim wrote:
>> >> On 03/13, Thorsten Leemhuis wrote:
>> >>> @Chao Yu/@Jaegeuk Kim: I'm considering to add this to the regressions
>> >>> report for 4.11; or is there a reason why it shouldn't be considered a
>> >>> regression? Ciao, Thorsten
>> >>
>> >> Hi,
>> >>
>> >> I'm planning to submit f2fs updates for 4.11-rcX including a patch which
>> >> resolves this issue as well, as I expect.
>> >>
>> >> https://lkml.org/lkml/2017/3/7/813
>> >
>> >Sorry for late repay.
>> >
>> >I expect below patches in Jaegeuk's tree could help to recover the 
>> >performance
>> >as well
>> >
>> >f2fs: skip scanning free nid bitmap of full NAT blocks
>> >f2fs: combine nat_bits and free_nid_bitmap cache
>> 
>> These 2 patches do help recover the performance back. Details as below.
>> 
>> Tested-by: Xiaolong Ye 
>> 
>> commit:
>>   4ac912427c4214d8031d9ad6fbc3bc75e71512df ("f2fs: introduce free nid 
>> bitmap")
>>   ced2c7ea8e99b46755a270872cd5ba61c27cffad <= parent commit of 4ac912427c
>>   c0e39d642e41be12937f4532721fc2538182e264 ("f2fs: combine nat_bits and 
>> free_nid_bitmap cache")
>
>Thank you for testing them.
>
>BTW, I found one missing clear_bit_le conversion from c0e39d642e41b.
>I updated the original patch and uploaded it into f2fs.git.
>
>  d00030cf9cd0bb9 ("f2fs: use __set{__clear}_bit_le")
>  1382c0f3f9d3f93 ("f2fs: combine nat_bits and free_nid_bitmap cache")
>
>Could you please test the above patches from f2fs.git one more time?
>I need to confirm there-in root-cause for next upstream.

Got it, I'll test the head commit of dev-test branch in f2fs.git, is it ok for
you?

Thanks,
Xiaolong
>
>Thanks,
>
>> 
>> 4ac912427c4214d8 ced2c7ea8e99b46755a270872c c0e39d642e41be12937f453272
>>  -- --
>>  %stddev %change %stddev %change %stddev
>>  \  |\  |\
>>  77863 ±  0% +50.8% 117419 ±  1% +50.9% 117500 ±  0%  
>> aim7.jobs-per-min
>> 231.63 ±  0% -33.6% 153.78 ±  1% -33.7% 153.67 ±  0%  
>> aim7.time.elapsed_time
>> 231.63 ±  0% -33.6% 153.78 ±  1% -33.7% 153.67 ±  0%  
>> aim7.time.elapsed_time.max
>> 896604 ±  0% -10.1% 805644 ±  3% -20.8% 710207 ±  1%  
>> aim7.time.involuntary_context_switches
>>   6240 ±  0% -13.3%   5408 ±  1% -14.2%   5353 ±  1%  
>> aim7.time.system_time
>>357 ±  3%  -1.3%1097209 ±  2%  -7.8%1024716 ±  0%  
>> aim7.time.voluntary_context_switches
>>5600256 ±  9%  -9.5%5066069 ±  0%  -9.3%5078220 ± 13%  
>> meminfo.DirectMap2M
>>  78738 ±  8% +72.1% 135538 ±  8% +23.2%  96995 ±  6%  
>> meminfo.Dirty
>> 315.50 ± 12%+210.8% 980.67 ± 16%+123.9% 706.40 ± 22%  
>> meminfo.Writeback
>>   1328 ± 18%+357.1%   6069 ± 57%+231.1%   4397 ± 75%  
>> softirqs.NET_RX
>> 669152 ±  3%  -7.4% 619333 ±  4% -14.4% 572896 ±  1%  
>> softirqs.RCU
>> 170724 ±  0% -25.0% 128030 ±  2% -23.0% 131531 ±  4%  
>> softirqs.SCHED
>>2688290 ±  0% -13.3%2331994 ±  1% -14.7%2292443 ±  1%  
>> softirqs.TIMER
>>   4948 ±  3% +55.6%   7701 ±  1% +55.8%   7710 ±  0%  
>> vmstat.io.bo
>>  39.00 ±  2% +65.8%  64.67 ±  2% -52.8%  18.40 ± 30%  
>> vmstat.procs.b
>> 171.50 ±  2% +94.4% 333.33 ±  7% +29.7% 222.40 ±  7%  
>> vmstat.procs.r
>>  13425 ±  1% +30.6%  17530 ±  1% +43.9%  19321 ± 10%  
>> vmstat.system.cs
>>  45100 ±  1%  +5.6%  47642 ±  1%  +6.3%  47957 ±  0%  
>> vmstat.system.in
>>  19068 ±  0% +75.8%  33522 ±  4% +24.5%  23745 ±  5%  
>> proc-vmstat.nr_dirty
>>  80.00 ±  3%+195.0% 236.00 ± 14%+126.0% 180.80 ± 23%  
>> proc-vmstat.nr_writeback
>>  19222 ±  0% +76.4%  33907 ±  4% +24.9%  24004 ±  5%  
>> proc-vmstat.nr_zone_write_pending
>> 
>> Thanks,
>> Xiaolong
>> >
>> >Xiaolong, Thorsten
>> >
>> >Could you help to test these patches?
>> >
>> >Thanks,
>> >
>> >>
>> >> Thanks,
>> >>
>> >>>
>> >>> On 08.03.2017 02:21, kernel test robot wrote:
>> 
>>  Greeting,
>> 
>>  We noticed a -33.7 regression of aim7.jobs-per-min due to commit:
>> 
>>  commit: 4ac912427c4214d8031d9ad6fbc3bc75e71512df ("f2fs: introduce free 
>>  nid bitmap")
>>  https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>> 
>>  in testcase: aim7
>>  on test machine: 40 threads Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz 
>>  with 384G memory
>>  with following parameters:
>> 
>>  disk: 1BRD_48G
>>  fs: f2fs
>>  test: disk_wrt
>>  load: 3000
>>    

Re: [PATCH v3] clk: imx: clk-imx6ul: The i.mx6ul has no aips_tz3 clock

[Shawn Guo]

On Tue, Mar 14, 2017 at 11:55:14AM +0100, Robin van der Gracht wrote:
> On Fri,  3 Mar 2017 15:14:05 +0100
> Robin van der Gracht  wrote:
> 
> > The clock was mapped on CG15 (gpio2_clocks) in the CCRG0 register.
> > 
> > Reviewed-by: Fabio Estevam 
> > Signed-off-by: Robin van der Gracht 
> 
> Sasha or Shawn would you mind pushing this patch upstream?
> I don't have a path.

I think Stephen will take care of it.

Shawn

[PATCH] vc04_services: Fixing coding guideline error

[Pushkar Jambhlekar]

Fixing 'if' block coding style. '{' should follow 'if' for multiline block

Signed-off-by: Pushkar Jambhlekar 
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c 
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
index 48984ab..ca896a5 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
@@ -797,8 +797,7 @@ int32_t vchi_get_peer_version(const VCHI_SERVICE_HANDLE_T 
handle, short *peer_ve
 {
int32_t ret = -1;
SHIM_SERVICE_T *service = (SHIM_SERVICE_T *)handle;
-   if (service)
-   {
+   if (service) {
VCHIQ_STATUS_T status;
 
status = vchiq_get_peer_version(service->handle, peer_version);
-- 
2.7.4

Re: [PATCH 2/2] x86/mm/KASLR: Correct the upper boundary of KALSR mm regions if adjacent to EFI

[Baoquan He]

On 03/15/17 at 02:13pm, Baoquan He wrote:
> PING!
> 
> Is there any suggestion for this code bug fix?
> 
> Boris added comment in patch 1/2 thread that it can also be fixed by
> swapping the naming - EFI_VA_START and EFI_VA_END. As he said the
> swapping can remove the confusion about the naming, while the con is
> changing it now could confuse more people who have the current
> mental picture of the mapping direction.

If swapping the naming is suggested, I can post v2 to change efi code.
Both of them is fine to me.

> 
> And there's also a well known similar use case, stack, like stack_end
> naming in arch/x86/boot/main.c which is the low addr boundary of stack
> region.
> 
> Any idea?
> 
> Thanks
> Baoquan
> 
> On 03/08/17 at 03:47pm, Baoquan He wrote:
> > EFI allocates runtime services regions top-down, starting from EFI_VA_START
> > to EFI_VA_END. So EFI_VA_START is bigger than EFI_VA_END and is the end of
> > EFI region. The upper boundary of memory regions randomized by KASLR should
> > be EFI_VA_END if it's adjacent to EFI region, but not EFI_VA_START.
> > 
> > Correct it in this patch.
> > 
> > Signed-off-by: Baoquan He 
> > ---
> >  arch/x86/mm/kaslr.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
> > index 887e571..aed2064 100644
> > --- a/arch/x86/mm/kaslr.c
> > +++ b/arch/x86/mm/kaslr.c
> > @@ -48,7 +48,7 @@ static const unsigned long vaddr_start = 
> > __PAGE_OFFSET_BASE;
> >  #if defined(CONFIG_X86_ESPFIX64)
> >  static const unsigned long vaddr_end = ESPFIX_BASE_ADDR;
> >  #elif defined(CONFIG_EFI)
> > -static const unsigned long vaddr_end = EFI_VA_START;
> > +static const unsigned long vaddr_end = EFI_VA_END;
> >  #else
> >  static const unsigned long vaddr_end = __START_KERNEL_map;
> >  #endif
> > @@ -105,7 +105,7 @@ void __init kernel_randomize_memory(void)
> >  */
> > BUILD_BUG_ON(vaddr_start >= vaddr_end);
> > BUILD_BUG_ON(IS_ENABLED(CONFIG_X86_ESPFIX64) &&
> > -vaddr_end >= EFI_VA_START);
> > +vaddr_end >= EFI_VA_END);
> > BUILD_BUG_ON((IS_ENABLED(CONFIG_X86_ESPFIX64) ||
> >   IS_ENABLED(CONFIG_EFI)) &&
> >  vaddr_end >= __START_KERNEL_map);
> > -- 
> > 2.5.5
> > 

Crypto Fixes for 4.11

[Herbert Xu]

Hi Linus:

This push fixes the following issues:

- Self-test failure of crc32c on powerpc.
- Regressions of ecb(aes) when used with xts/lrw in s5p-sss.
- A number of bugs in the omap RNG driver.


Please pull from

git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus


Daniel Axtens (1):
  crypto: powerpc - Fix initialisation of crc32c context

Krzysztof Kozlowski (2):
  crypto: s5p-sss - Fix completing crypto request in IRQ handler
  crypto: s5p-sss - Fix spinlock recursion on LRW(AES)

Thomas Petazzoni (3):
  hwrng: omap - write registers after enabling the clock
  hwrng: omap - use devm_clk_get() instead of of_clk_get()
  hwrng: omap - Do not access INTMASK_REG on EIP76

 arch/powerpc/crypto/crc32c-vpmsum_glue.c |2 +-
 drivers/char/hw_random/omap-rng.c|   16 +++-
 drivers/crypto/s5p-sss.c |  132 +++---
 3 files changed, 100 insertions(+), 50 deletions(-)

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v5 1/2] mailbox: Add driver for Broadcom FlexRM ring manager

[Anup Patel]

On Tue, Mar 14, 2017 at 10:24 PM, Jassi Brar  wrote:
> On Mon, Mar 6, 2017 at 10:40 AM, Anup Patel  wrote:
>> Some of the Broadcom iProc SoCs have FlexRM ring manager
>> which provides a ring-based programming interface to various
>> offload engines (e.g. RAID, Crypto, etc).
>>
>> This patch adds a common mailbox driver for Broadcom FlexRM
>> ring manager which can be shared by various offload engine
>> drivers (implemented as mailbox clients).
>>
>> Reviewed-by: Ray Jui 
>> Reviewed-by: Scott Branden 
>> Reviewed-by: Pramod KUMAR 
>> Signed-off-by: Anup Patel 
>> ---
>>  drivers/mailbox/Kconfig  |  11 +
>>  drivers/mailbox/Makefile |   2 +
>>  drivers/mailbox/mailbox-flexrm/Makefile  |   6 +
>>  drivers/mailbox/mailbox-flexrm/flexrm-desc.c | 764 
>>  drivers/mailbox/mailbox-flexrm/flexrm-desc.h |  47 ++
>>  drivers/mailbox/mailbox-flexrm/flexrm-main.c | 829 
>> +++
>>  include/linux/mailbox/brcm-message.h |  14 +-
>>  7 files changed, 1669 insertions(+), 4 deletions(-)
>>  create mode 100644 drivers/mailbox/mailbox-flexrm/Makefile
>>  create mode 100644 drivers/mailbox/mailbox-flexrm/flexrm-desc.c
>>  create mode 100644 drivers/mailbox/mailbox-flexrm/flexrm-desc.h
>>  create mode 100644 drivers/mailbox/mailbox-flexrm/flexrm-main.c
>>
> I would avoid platform specific sub-directory if possible, because
> people tend to take it as  their fenced island where they can do
> whatever they like.

Sure, I will remove driver directory and merge everything into one
driver source file.

>
> Can you break this into an upper BRCM specific code (desc management)
> and a lower purely mailbox driver (only sets up pointers/addresses to
> create rings and track the flexrm's PC)?   Is there a reason why you

Sure, I will organize merged driver source file as-per your suggestion

> must dma_map, the buffers to send, in the spinlock protected
> .send_data()?

The dma_map() happens only for brcm_message with
SPU2 message type. The SPU2 crypto mailbox client driver
will just prepare src and dst scatterlist using the scatterlist
passed by Linux crypto framework and pass it to mailbox
controller driver (i.e. FlexRM driver or PDC driver). The
pages in src and dst scatterlist will not be DMA mapped
hence we first dma_map() scatterlist and then create
descriptors using DMA addresses.

I am fine in doing dma_map() outside spinlock protected
.send_data() for SPU2 message type but this will impact
three drivers:
1. BCM SPU2 Crypto driver (already merged)
2. BCM PDC mailbox driver (already merged)
3. BCM FlexRM mailbox driver (this patch)

If required we should have separate patch to move
dma_map() out of .send_data() because it impacts
three different drivers.

Regards,
Anup

[PATCH v6 2/2] dt-bindings: Add DT bindings info for FlexRM ring manager

[Anup Patel]

This patch adds device tree bindings document for the FlexRM
ring manager found on Broadcom iProc SoCs.

Acked-by: Rob Herring 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
Signed-off-by: Anup Patel 
---
 .../bindings/mailbox/brcm,iproc-flexrm-mbox.txt| 59 ++
 1 file changed, 59 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt

diff --git 
a/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt 
b/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt
new file mode 100644
index 000..752ae6b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt
@@ -0,0 +1,59 @@
+Broadcom FlexRM Ring Manager
+
+The Broadcom FlexRM ring manager provides a set of rings which can be
+used to submit work to offload engines. An SoC may have multiple FlexRM
+hardware blocks. There is one device tree entry per FlexRM block. The
+FlexRM driver will create a mailbox-controller instance for given FlexRM
+hardware block where each mailbox channel is a separate FlexRM ring.
+
+Required properties:
+
+- compatible:  Should be "brcm,iproc-flexrm-mbox"
+- reg: Specifies base physical address and size of the FlexRM
+   ring registers
+- msi-parent:  Phandles (and potential Device IDs) to MSI controllers
+   The FlexRM engine will send MSIs (instead of wired
+   interrupts) to CPU. There is one MSI for each FlexRM ring.
+   Refer devicetree/bindings/interrupt-controller/msi.txt
+- #mbox-cells: Specifies the number of cells needed to encode a mailbox
+   channel. This should be 3.
+
+   The 1st cell is the mailbox channel number.
+
+   The 2nd cell contains MSI completion threshold. This is the
+   number of completion messages for which FlexRM will inject
+   one MSI interrupt to CPU.
+
+   The 3nd cell contains MSI timer value representing time for
+   which FlexRM will wait to accumulate N completion messages
+   where N is the value specified by 2nd cell above. If FlexRM
+   does not get required number of completion messages in time
+   specified by this cell then it will inject one MSI interrupt
+   to CPU provided atleast one completion message is available.
+
+Optional properties:
+
+- dma-coherent:Present if DMA operations made by the FlexRM engine 
(such
+   as DMA descriptor access, access to buffers pointed by DMA
+   descriptors and read/write pointer updates to DDR) are
+   cache coherent with the CPU.
+
+Example:
+
+crypto_mbox: mbox@6700 {
+   compatible = "brcm,iproc-flexrm-mbox";
+   reg = <0x6700 0x20>;
+   msi-parent = <_its 0x7f00>;
+   #mbox-cells = <3>;
+};
+
+crypto@672c {
+   compatible = "brcm,spu2-v2-crypto";
+   reg = <0x672c 0x1000>;
+   mboxes = <_mbox 0 0x1 0x>,
+<_mbox 1 0x1 0x>,
+<_mbox 16 0x1 0x>,
+<_mbox 17 0x1 0x>,
+<_mbox 30 0x1 0x>,
+<_mbox 31 0x1 0x>;
+};
-- 
2.7.4

[PATCH v6 1/2] mailbox: Add driver for Broadcom FlexRM ring manager

[Anup Patel]

Some of the Broadcom iProc SoCs have FlexRM ring manager
which provides a ring-based programming interface to various
offload engines (e.g. RAID, Crypto, etc).

This patch adds a common mailbox driver for Broadcom FlexRM
ring manager which can be shared by various offload engine
drivers (implemented as mailbox clients).

Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
Reviewed-by: Pramod KUMAR 
Signed-off-by: Anup Patel 
---
 drivers/mailbox/Kconfig  |   11 +
 drivers/mailbox/Makefile |2 +
 drivers/mailbox/bcm-flexrm-mailbox.c | 1595 ++
 include/linux/mailbox/brcm-message.h |   14 +-
 4 files changed, 1618 insertions(+), 4 deletions(-)
 create mode 100644 drivers/mailbox/bcm-flexrm-mailbox.c

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index ceff415..305018c 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -152,4 +152,15 @@ config BCM_PDC_MBOX
  Mailbox implementation for the Broadcom PDC ring manager,
  which provides access to various offload engines on Broadcom
  SoCs. Say Y here if you want to use the Broadcom PDC.
+
+config BCM_FLEXRM_MBOX
+   tristate "Broadcom FlexRM Mailbox"
+   depends on ARM64 || COMPILE_TEST
+   depends on HAS_DMA
+   select GENERIC_MSI_IRQ_DOMAIN
+   default ARCH_BCM_IPROC
+   help
+ Mailbox implementation of the Broadcom FlexRM ring manager,
+ which provides access to various offload engines on Broadcom
+ SoCs. Say Y here if you want to use the Broadcom FlexRM.
 endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 7dde4f6..e2bcb03 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -30,4 +30,6 @@ obj-$(CONFIG_HI6220_MBOX) += hi6220-mailbox.o
 
 obj-$(CONFIG_BCM_PDC_MBOX) += bcm-pdc-mailbox.o
 
+obj-$(CONFIG_BCM_FLEXRM_MBOX)  += bcm-flexrm-mailbox.o
+
 obj-$(CONFIG_TEGRA_HSP_MBOX)   += tegra-hsp.o
diff --git a/drivers/mailbox/bcm-flexrm-mailbox.c 
b/drivers/mailbox/bcm-flexrm-mailbox.c
new file mode 100644
index 000..da67882
--- /dev/null
+++ b/drivers/mailbox/bcm-flexrm-mailbox.c
@@ -0,0 +1,1595 @@
+/* Broadcom FlexRM Mailbox Driver
+ *
+ * Copyright (C) 2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Each Broadcom FlexSparx4 offload engine is implemented as an
+ * extension to Broadcom FlexRM ring manager. The FlexRM ring
+ * manager provides a set of rings which can be used to submit
+ * work to a FlexSparx4 offload engine.
+ *
+ * This driver creates a mailbox controller using a set of FlexRM
+ * rings where each mailbox channel represents a separate FlexRM ring.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* == FlexRM register defines = */
+
+/* FlexRM configuration */
+#define RING_REGS_SIZE 0x1
+#define RING_DESC_SIZE 8
+#define RING_DESC_INDEX(offset)\
+   ((offset) / RING_DESC_SIZE)
+#define RING_DESC_OFFSET(index)\
+   ((index) * RING_DESC_SIZE)
+#define RING_MAX_REQ_COUNT 1024
+#define RING_BD_ALIGN_ORDER12
+#define RING_BD_ALIGN_CHECK(addr)  \
+   (!((addr) & ((0x1 << RING_BD_ALIGN_ORDER) - 1)))
+#define RING_BD_TOGGLE_INVALID(offset) \
+   (((offset) >> RING_BD_ALIGN_ORDER) & 0x1)
+#define RING_BD_TOGGLE_VALID(offset)   \
+   (!RING_BD_TOGGLE_INVALID(offset))
+#define RING_BD_DESC_PER_REQ   32
+#define RING_BD_DESC_COUNT \
+   (RING_MAX_REQ_COUNT * RING_BD_DESC_PER_REQ)
+#define RING_BD_SIZE   \
+   (RING_BD_DESC_COUNT * RING_DESC_SIZE)
+#define RING_CMPL_ALIGN_ORDER  13
+#define RING_CMPL_DESC_COUNT   RING_MAX_REQ_COUNT
+#define RING_CMPL_SIZE \
+   (RING_CMPL_DESC_COUNT * RING_DESC_SIZE)
+#define RING_VER_MAGIC 0x76303031
+
+/* Per-Ring register offsets */
+#define RING_VER   0x000
+#define RING_BD_START_ADDR 0x004
+#define RING_BD_READ_PTR   0x008
+#define RING_BD_WRITE_PTR  0x00c
+#define RING_BD_READ_PTR_DDR_LS0x010
+#define RING_BD_READ_PTR_DDR_MS 

[PATCH v6 0/2] Broadcom FlexRM ring manager support

[Anup Patel]

The Broadcom FlexRM ring manager provides producer-consumer style
ring interface for offload engines on Broadcom iProc SoCs. We can
have one or more instances of Broadcom FlexRM ring manager in a SoC.

This patchset adds a mailbox driver for Broadcom FlexRM ring manager
which can be used by offload engine drivers as mailbox clients.

The Broadcom FlexRM mailbox driver is feature complete for RAID and
Crypto offload engines. We will have incremental patches in-future
for ring-level statistics using debugfs and minor optimizations.

This patchset is based on Linux-4.11-rc2 and it is also available
at flexrm-v6 branch of https://github.com/Broadcom/arm64-linux.git

Changes since v5:
 - Rebased patches for Linux-4.11-rc2
 - Merged all source files into one source file and removed
   driver directory

Changes since v4:
 - Rebased patches for Linux-4.11-rc1

Changes since v3:
 - Fixed mailbox client example DT node in DT bindings document

Changes since v2:
 - Rebased patches for Linux-4.10-rc2

Changes since v1:
 - Use compatile string as brcm,iproc-flexrm-mbox
 - Rephrase commit message and text in DT bindings patch

Anup Patel (2):
  mailbox: Add driver for Broadcom FlexRM ring manager
  dt-bindings: Add DT bindings info for FlexRM ring manager

 .../bindings/mailbox/brcm,iproc-flexrm-mbox.txt|   59 +
 drivers/mailbox/Kconfig|   11 +
 drivers/mailbox/Makefile   |2 +
 drivers/mailbox/bcm-flexrm-mailbox.c   | 1595 
 include/linux/mailbox/brcm-message.h   |   14 +-
 5 files changed, 1677 insertions(+), 4 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt
 create mode 100644 drivers/mailbox/bcm-flexrm-mailbox.c

-- 
2.7.4

[PATCH] perf/record: make perf_event__synthesize_mmap_events() scale

[Stephane Eranian]

This patch significantly improves the execution time of
perf_event__synthesize_mmap_events() when running perf record
on systems where processes have lots of threads. It just happens
that cat /proc/pid/maps support uses a O(N^2) algorithm to generate
each map line in the maps file.  If you have 1000 threads, then you have
necessarily 1000 stacks.  For each vma, you need to check if it corresponds
to a thread's stack.  With a large number of threads, this can take a very long 
time. I have seen latencies >> 10mn.

As of today, perf does not use the fact that a mapping is a stack,
therefore we can work around the issue by using /proc/pid/tasks/pid/maps.
This entry does not try to map a vma to stack and is thus much
faster with no loss of functonality.

The proc-map-timeout logic is kept in case user still want some uppre limit.

Signed-off-by: Stephane Eranian 
---
 tools/perf/util/event.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 4ea7ce7..b137566 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -255,8 +255,8 @@ int perf_event__synthesize_mmap_events(struct perf_tool 
*tool,
if (machine__is_default_guest(machine))
return 0;
 
-   snprintf(filename, sizeof(filename), "%s/proc/%d/maps",
-machine->root_dir, pid);
+   snprintf(filename, sizeof(filename), "%s/proc/%d/tasks/%d/maps",
+machine->root_dir, pid, pid);
 
fp = fopen(filename, "r");
if (fp == NULL) {
-- 
2.5.0

Re: [linux-sunxi] [PATCH v3 4/5] ARM: dts: sun8i: h3: enable USB OTG on Orange Pi One

[Chen-Yu Tsai]

On Tue, Mar 7, 2017 at 6:34 AM, Icenowy Zheng  wrote:
> Orange Pi One features a MicroUSB port that can work in both host mode
> and peripheral mode.
>
> When in host mode, its VBUS is controlled via a GPIO; when in peripheral
> mode, its VBUS cannot be used to power up the board.
>
> Add support for this port.
>
> Signed-off-by: Icenowy Zheng 

Acked-by: Chen-Yu Tsai 

[PATCH] net: mvneta: support suspend and resume

[Jane Li]

Add basic support for handling suspend and resume.

Signed-off-by: Jane Li 
---
 drivers/net/ethernet/marvell/mvneta.c | 44 +++
 1 file changed, 44 insertions(+)

diff --git a/drivers/net/ethernet/marvell/mvneta.c 
b/drivers/net/ethernet/marvell/mvneta.c
index 61dd446..4f16342 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -4405,6 +4405,49 @@ static int mvneta_remove(struct platform_device *pdev)
return 0;
 }
 
+#ifdef CONFIG_PM_SLEEP
+static int mvneta_suspend(struct device *device)
+{
+   struct net_device *dev = dev_get_drvdata(device);
+   struct mvneta_port *pp = netdev_priv(dev);
+
+   if (netif_running(dev))
+   mvneta_stop(dev);
+   netif_device_detach(dev);
+   clk_disable_unprepare(pp->clk_bus);
+   clk_disable_unprepare(pp->clk);
+   return 0;
+}
+
+static int mvneta_resume(struct device *device)
+{
+   struct net_device *dev = dev_get_drvdata(device);
+   struct mvneta_port *pp = netdev_priv(dev);
+   int err;
+
+   clk_prepare_enable(pp->clk);
+   clk_prepare_enable(pp->clk_bus);
+   mvneta_defaults_set(pp);
+   err = mvneta_port_power_up(pp, pp->phy_interface);
+   if (err < 0) {
+   dev_err(device, "can't power up port\n");
+   return err;
+   }
+
+   if (pp->use_inband_status)
+   mvneta_fixed_link_update(pp, dev->phydev);
+
+   netif_device_attach(dev);
+   if (netif_running(dev))
+   mvneta_open(dev);
+   return 0;
+}
+#endif
+
+static const struct dev_pm_ops mvneta_pm_ops = {
+   SET_LATE_SYSTEM_SLEEP_PM_OPS(mvneta_suspend, mvneta_resume)
+};
+
 static const struct of_device_id mvneta_match[] = {
{ .compatible = "marvell,armada-370-neta" },
{ .compatible = "marvell,armada-xp-neta" },
@@ -4419,6 +4462,7 @@ static int mvneta_remove(struct platform_device *pdev)
.driver = {
.name = MVNETA_DRIVER_NAME,
.of_match_table = mvneta_match,
+   .pm = _pm_ops,
},
 };
 
-- 
1.9.1

Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)

[gregkh]

On Tue, Feb 28, 2017 at 02:31:51PM +0100, Arnd Bergmann wrote:
> On Sun, Feb 26, 2017 at 2:47 PM, kernelci.org bot  wrote:
> > stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings
> 
> A lot of fixes for these build problems have now landed in mainline, and
> we could backport them as soon as they are considered stable enough.
> If all of these make it into stable, we should have a clean build on MIPS and
> ARM, and only the KASAN warnings remaining x86 and arm64.
> 
> > capcella_defconfig (mips) — PASS, 0 errors, 1 warning, 0 section mismatches
> >
> > Warnings:
> > crypto/wp512.c:987:1: warning: the frame size of 1112 bytes is larger than
> > 1024 bytes [-Wframe-larger-than=]
> 
> 7d6e91050267 ("crypto: improve gcc optimization flags for serpent and wp512")
> 
> > defconfig+CONFIG_KASAN=y (x86) — PASS, 0 errors, 5 warnings, 0 section
> > mismatches
> >
> > Warnings:
> > drivers/tty/vt/keyboard.c:1470:1: warning: the frame size of 2344 bytes is
> > larger than 2048 bytes [-Wframe-larger-than=]
> > net/wireless/nl80211.c:1410:1: warning: the frame size of 2232 bytes is
> > larger than 2048 bytes [-Wframe-larger-than=]
> > net/wireless/nl80211.c:4389:1: warning: the frame size of 2232 bytes is
> > larger than 2048 bytes [-Wframe-larger-than=]
> > net/wireless/nl80211.c:5689:1: warning: the frame size of 2064 bytes is
> > larger than 2048 bytes [-Wframe-larger-than=]
> > net/wireless/nl80211.c:1895:1: warning: the frame size of 3720 bytes is
> > larger than 2048 bytes [-Wframe-larger-than=]
> 
> I'm still working on the fix, the same thing happens in mainline.
> 
> > Warnings:
> > arch/mips/configs/ip22_defconfig:70:warning: symbol value 'm' invalid for
> > NF_CT_PROTO_DCCP
> > arch/mips/configs/ip22_defconfig:71:warning: symbol value 'm' invalid for
> > NF_CT_PROTO_UDPLITE
> 
> 9ddc16ad8e0b ("MIPS: Update defconfigs for NF_CT_PROTO_DCCP/UDPLITE change")
> 
> > ip27_defconfig (mips) — FAIL, 4 errors, 1 warning, 0 section mismatches
> >
> > Errors:
> > arch/mips/include/asm/mach-generic/spaces.h:28:0: error: "CAC_BASE"
> > redefined [-Werror]
> > arch/mips/include/asm/mach-generic/spaces.h:28:0: error: "CAC_BASE"
> > redefined [-Werror]
> 
> 1742ac265046 ("MIPS: VDSO: avoid duplicate CAC_BASE definition")
> 
> > drivers/net/ethernet/qlogic/qlge/qlge_main.c:4819:1: error: insn does not
> > satisfy its constraints:
> > drivers/net/ethernet/qlogic/qlge/qlge_main.c:4819:1: internal compiler
> > error: in extract_constrain_insn, at recog.c:2190
> > Warnings:
> 
> b61764946839 ("MIPS: ip27: Disable qlge driver in defconfig")
> 
> > arch/mips/configs/ip27_defconfig:136:warning: symbol value 'm' invalid for
> > SCSI_DH
> 
> ea58fca1842a ("MIPS: Update ip27_defconfig for SCSI_DH change")
> 
> > ip28_defconfig (mips) — FAIL, 1 error, 0 warnings, 0 section mismatches
> >
> > Errors:
> > arch/mips/sgi-ip22/Platform:29: *** gcc doesn't support needed option
> > -mr10k-cache-barrier=store. Stop.
> 
> 23ca9b522383 ("MIPS: ip22: Fix ip28 build for modern gcc")
> 
> > lemote2f_defconfig (mips) — PASS, 0 errors, 2 warnings, 0 section mismatches
> >
> > Warnings:
> > arch/mips/configs/lemote2f_defconfig:42:warning: symbol value 'm' invalid
> > for CPU_FREQ_STAT
> 
> b3f6046186ef ("MIPS: Update lemote2f_defconfig for CPU_FREQ_STAT change")
> 
> > msp71xx_defconfig (mips) — PASS, 0 errors, 1 warning, 0 section mismatches
> >
> > Warnings:
> > drivers/mtd/maps/pmcmsp-flash.c:149:30: warning: passing argument 1 of
> > 'strncpy' discards 'const' qualifier from pointer target type
> > [-Wdiscarded-qualifiers]
> 
> 906b268477bc ("mtd: pmcmsp: use kstrndup instead of kmalloc+strncpy")
> 
> > rt305x_defconfig (mips) — PASS, 0 errors, 5 warnings, 0 section mismatches
> >
> > Warnings:
> > arch/mips/ralink/prom.c:70:2: warning: 'argc' is used uninitialized in this
> > function [-Wuninitialized]
> > arch/mips/ralink/prom.c:70:2: warning: 'argv' is used uninitialized in this
> > function [-Wuninitialized]
> 
> 9c48568b3692 ("MIPS: ralink: Cosmetic change to prom_init().")
> 
> > arch/mips/ralink/timer.c:104:13: warning: 'rt_timer_disable' defined but not
> > used [-Wunused-function]
> > arch/mips/ralink/timer.c:74:13: warning: 'rt_timer_free' defined but not
> > used [-Wunused-function]
> 
> d92240d12a9c ("MIPS: ralink: Remove unused timer functions")
> 
> > arch/mips/ralink/rt305x.c:92:13: warning: 'rt305x_wdt_reset' defined but not
> > used [-Wunused-function]
> 
> 886f9c69fc68 ("MIPS: ralink: Remove unused rt*_wdt_reset functions")

All now queued up in the stable trees, thanks.

greg k-h

Re: [linux-sunxi] [PATCH v3 5/5] ARM: dts: sun8i: h2+: enable USB OTG for Orange Pi Zero board

[Chen-Yu Tsai]

Hi,

On Tue, Mar 7, 2017 at 6:34 AM, Icenowy Zheng  wrote:
> Orange Pi Zero board features a USB OTG port, which has a ID pin, and
> can be used to power up the board. However, even if the board is powered
> via +5V pin in GPIO/expansion headers, the VBUS in the OTG port cannot
> be powered up, thus it's impossible to use it in host mode with simple
> OTG cables.
>
> Add support for it in peripheral mode.
>
> If someone really want to use it in host mode, the mode of PHY can be
> switch via sysfs, then use a powered USB OTG cable or powered USB HUB to
> power up external USB devices.
>
> Signed-off-by: Icenowy Zheng 
> ---
> New patch in v3.
>
>  arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts 
> b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
> index b7ca916d871d..63f819394b98 100644
> --- a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
> +++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
> @@ -96,6 +96,10 @@
> };
>  };
>
> + {
> +   status = "okay";
> +};
> +
>   {
> status = "okay";
>  };
> @@ -132,6 +136,10 @@
> bias-pull-up;
>  };
>
> + {
> +   status = "okay";
> +};
> +
>   {
> status = "okay";
>  };
> @@ -154,7 +162,13 @@
> status = "disabled";
>  };
>
> +_otg {
> +   dr_mode = "peripheral";
> +   status = "okay";
> +};
> +
>   {
> /* USB VBUS is always on */

This comment does not match your commit message, which says it's always off.

ChenYu

> status = "okay";
> +   usb0_id_det-gpios = < 6 12 GPIO_ACTIVE_HIGH>; /* PG12 */
>  };
> --
> 2.11.1
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Re: stable build: 199 builds: 1 failed, 198 passed, 1 error, 31 warnings (v4.4.52)

[gregkh]

On Tue, Feb 28, 2017 at 02:55:42PM +0100, Arnd Bergmann wrote:
> On Sun, Feb 26, 2017 at 3:09 PM, kernelci.org bot  wrote:
> > stable build: 199 builds: 1 failed, 198 passed, 1 error, 31 warnings
> 
> A few additional patches are missing here, besides the ones I have
> listed for 4.9 and v4.10
> 
> > Warnings:
> > drivers/net/ethernet/ti/cpmac.c:1240:2: warning: #warning FIXME: unhardcode
> > gpio bits [-Wcpp]
> 
> d43e6fb4ac4a ("cpmac: remove hopeless #warning")
> 
> > ci20_defconfig (mips) — PASS, 0 errors, 1 warning, 0 section mismatches
> >
> > Warnings:
> > mm/memcontrol.c:4153:27: warning: 'mem_cgroup_id_get_online' defined but not
> > used [-Wunused-function]
> 
> 358c07fcc3b6 ("mm: memcontrol: avoid unused function warning")
> 
> > decstation_defconfig (mips) — PASS, 0 errors, 3 warnings, 0 section
> > mismatches
> >
> > Warnings:
> > arch/mips/dec/int-handler.S:149: Warning: macro instruction expanded into
> > multiple instructions in a branch delay slot
> > arch/mips/dec/int-handler.S:198: Warning: macro instruction expanded into
> > multiple instructions in a branch delay slot
> 
> 3021773c7c3e ("MIPS: DEC: Avoid la pseudo-instruction in delay slots")
> 
> > nlm_xlp_defconfig (mips) — PASS, 0 errors, 4 warnings, 0 section mismatches
> >
> > Warnings:
> > arch/mips/netlogic/common/reset.S:53:0: warning: "CP0_EBASE" redefined
> > arch/mips/netlogic/common/smpboot.S:51:0: warning: "CP0_EBASE" redefined
> 
> 32eb6e8bee14 ("MIPS: Netlogic: Fix CP0_EBASE redefinition warnings")

And I've added these as well, thanks.

greg k-h

hwclock make clock_gettime not accurate

[li feng]

HI guys.

I'm doing some tests about clock_gettime.
And I found that clock_gettime will be affected by hwclock.
It makes clock_gettime slip advance some milliseconds.

Actually, each line prints out every 1ms.


 $ ./a.out -r CLOCK_MONOTONIC
   130 ↵
Using delay=1 ms between loop.
Using clock=CLOCK_MONOTONIC.
Clock resolution sec=0 nsec=1
Initial time sec=1621884 nsec=285113956

[delay=1ms] Slip time: 0 s 32 ms <-hwclock
[delay=1ms] Slip time: 0 s 16 ms <-hwclock

>From perf:

$ perf record -F 999 hwclock

# To display the perf.data header info, please use
--header/--header-only options.

#

# Samples: 22  of event 'cpu-clock'

# Event count (approx.): 22022022

#

# Overhead  Command  Shared Object  Symbol

#   ...  .  ...

#

   77.27%  hwclock  [kernel.kallsyms]  [k] native_read_tsc

   13.64%  hwclock  [kernel.kallsyms]  [k] delay_tsc

4.55%  hwclock  [kernel.kallsyms]  [k] _raw_spin_unlock_irqrestore

4.55%  hwclock  libc-2.17.so   [.] __strftime_l




$perf record -F 999 ./a.out

# To display the perf.data header info, please use
--header/--header-only options.

#

# Samples: 7K of event 'cpu-clock'

# Event count (approx.): 79010100220

#

# Overhead  Command  Shared Object  Symbol

#   ...  .  ...

#

   28.18%  a.out[kernel.kallsyms]  [k] _raw_spin_unlock_irqrestore

   20.64%  a.out[vdso] [.] __vdso_clock_gettime

   18.46%  a.out[kernel.kallsyms]  [k] native_read_tsc

9.81%  a.outa.out  [.] busy_loop

4.62%  a.outa.out  [.] calc_1ms

2.15%  a.outlibc-2.17.so   [.] clock_gettime

2.02%  a.outa.out  [.] overhead_clock

I thought there is a lock contention.
However, when I ran two a.out, the output is correct, not like hwclock.

Anyone knows why?

Thanks.

Re: Fwd: stable build: 111 builds: 2 failed, 109 passed, 1 error, 29 warnings (v4.10.2)

[gregkh]

On Mon, Mar 13, 2017 at 04:51:41PM +0100, Arnd Bergmann wrote:
> On Sun, Mar 12, 2017 at 10:44 AM, kernelci.org bot  wrote:
> > Build Failures Detected:
> 
> All but two failures have been fixed, nice!
> 
> > x86: gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)
> > allmodconfig+CONFIG_OF=n FAIL
> 
> Not sure what's going on here, I've seen this failure a few times on kernelci
> but cannot reproduce it here:
> 
> /bin/sh: 1: 
> /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/stable/build-x86/tools/objtool//fixdep:
> Permission denied
> /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/stable/tools/build/Makefile.build:91:
> recipe for target
> '/home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/stable/build-x86/tools/objtool/pager.o'
> failed
> make[5]: *** 
> [/home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/stable/build-x86/tools/objtool/pager.o]
> Error 126
> make[5]: *** Waiting for unfinished jobs
> 
> > Warnings summary:
> > 4 crypto/wp512.c:987:1: warning: the frame size of 1112 bytes is larger 
> > than 1024 bytes [-Wframe-larger-than=]
> > 2 crypto/wp512.c:987:1: warning: the frame size of 1120 bytes is larger 
> > than 1024 bytes [-Wframe-larger-than=]
> > 2 arch/mips/configs/ip22_defconfig:71:warning: symbol value 'm' invalid for 
> > NF_CT_PROTO_UDPLITE
> > 2 arch/mips/configs/ip22_defconfig:70:warning: symbol value 'm' invalid for 
> > NF_CT_PROTO_DCCP
> > 1 drivers/mtd/maps/pmcmsp-flash.c:149:30: warning: passing argument 1 of 
> > 'strncpy' discards 'const' qualifier from pointer target type 
> > [-Wdiscarded-qualifiers]
> > 1 crypto/wp512.c:987:1: warning: the frame size of 1344 bytes is larger 
> > than 1024 bytes [-Wframe-larger-than=]
> > 1 crypto/wp512.c:987:1: warning: the frame size of 1280 bytes is larger 
> > than 1024 bytes [-Wframe-larger-than=]
> > 1 crypto/wp512.c:987:1: warning: the frame size of 1152 bytes is larger 
> > than 1024 bytes [-Wframe-larger-than=]
> > 1 crypto/wp512.c:987:1: warning: the frame size of 1144 bytes is larger 
> > than 1024 bytes [-Wframe-larger-than=]
> > 1 crypto/serpent_generic.c:436:1: warning: the frame size of 1456 bytes is 
> > larger than 1024 bytes [-Wframe-larger-than=]
> > 1 crypto/serpent_generic.c:436:1: warning: the frame size of 1440 bytes is 
> > larger than 1024 bytes [-Wframe-larger-than=]
> > 1 arch/mips/ralink/timer.c:74:13: warning: 'rt_timer_free' defined but not 
> > used [-Wunused-function]
> > 1 arch/mips/ralink/timer.c:104:13: warning: 'rt_timer_disable' defined but 
> > not used [-Wunused-function]
> > 1 arch/mips/ralink/rt305x.c:92:13: warning: 'rt305x_wdt_reset' defined but 
> > not used [-Wunused-function]
> > 1 arch/mips/ralink/prom.c:70:2: warning: 'argv' is used uninitialized in 
> > this function [-Wuninitialized]
> > 1 arch/mips/ralink/prom.c:70:2: warning: 'argc' is used uninitialized in 
> > this function [-Wuninitialized]
> > 1 arch/mips/configs/nlm_xlr_defconfig:93:warning: symbol value 'm' invalid 
> > for NF_CT_PROTO_UDPLITE
> > 1 arch/mips/configs/nlm_xlp_defconfig:113:warning: symbol value 'm' invalid 
> > for NF_CT_PROTO_UDPLITE
> > 1 arch/mips/configs/maltaup_xpa_defconfig:65:warning: symbol value 'm' 
> > invalid for NF_CT_PROTO_UDPLITE
> > 1 arch/mips/configs/maltaup_xpa_defconfig:64:warning: symbol value 'm' 
> > invalid for NF_CT_PROTO_DCCP
> > 1 arch/mips/configs/malta_kvm_defconfig:64:warning: symbol value 'm' 
> > invalid for NF_CT_PROTO_UDPLITE
> > 1 arch/mips/configs/malta_kvm_defconfig:63:warning: symbol value 'm' 
> > invalid for NF_CT_PROTO_DCCP
> > 1 arch/mips/configs/lemote2f_defconfig:42:warning: symbol value 'm' invalid 
> > for CPU_FREQ_STAT
> 
> These should all be addressed by the set of patches I pointed out in a
> previous reply.
> 
> Greg, I'm not sure if you still have the list in your inbox. For now,
> I'll monitor the build warnings here, unless you pick the patches or
> want me to resend the list I made.

Should now be caught up with these, if anything new shows up, please let
me know.

thanks,

greg k-h

Re: stable build: 203 builds: 3 failed, 200 passed, 5 errors, 28 warnings (v4.9.13)

[gregkh]

On Tue, Feb 28, 2017 at 02:50:03PM +0100, Arnd Bergmann wrote:
> On Sun, Feb 26, 2017 at 2:52 PM, kernelci.org bot  wrote:
> >
> > stable build: 203 builds: 3 failed, 200 passed, 5 errors, 28 warnings 
> > (v4.9.13)
> 
> Only one warning that doesn't also show up in v4.10-stable
> 
> > bcm63xx_defconfig (mips) — PASS, 0 errors, 1 warning, 0 section mismatches
> >
> > Warnings:
> > drivers/net/ethernet/broadcom/bcm63xx_enet.c:1130:3: warning: 'phydev' may 
> > be used uninitialized in this function [-Wmaybe-uninitialized]
> 
> df384d435a5c ("bcm63xx_enet: avoid uninitialized variable warning")

Also added, thanks.

greg k-h

Re: [PATCH] net: mvneta: support suspend and resume

[Jisheng Zhang]

Hi Jane,

On Wed, 15 Mar 2017 15:08:34 +0800 Jane Li  wrote:

> Add basic support for handling suspend and resume.
> 
> Signed-off-by: Jane Li 
> ---
>  drivers/net/ethernet/marvell/mvneta.c | 44 
> +++
>  1 file changed, 44 insertions(+)
> 
> diff --git a/drivers/net/ethernet/marvell/mvneta.c 
> b/drivers/net/ethernet/marvell/mvneta.c
> index 61dd446..4f16342 100644
> --- a/drivers/net/ethernet/marvell/mvneta.c
> +++ b/drivers/net/ethernet/marvell/mvneta.c
> @@ -4405,6 +4405,49 @@ static int mvneta_remove(struct platform_device *pdev)
>   return 0;
>  }
>  
> +#ifdef CONFIG_PM_SLEEP
> +static int mvneta_suspend(struct device *device)
> +{
> + struct net_device *dev = dev_get_drvdata(device);
> + struct mvneta_port *pp = netdev_priv(dev);
> +
> + if (netif_running(dev))
> + mvneta_stop(dev);
> + netif_device_detach(dev);
> + clk_disable_unprepare(pp->clk_bus);
> + clk_disable_unprepare(pp->clk);
> + return 0;
> +}
> +
> +static int mvneta_resume(struct device *device)
> +{
> + struct net_device *dev = dev_get_drvdata(device);
> + struct mvneta_port *pp = netdev_priv(dev);
> + int err;
> +
> + clk_prepare_enable(pp->clk);
> + clk_prepare_enable(pp->clk_bus);

we may miss the necessary registers setting in mvneta_bm_port_init() and
mvneta_conf_mbus_windows(). those registers also need to be restored.


> + mvneta_defaults_set(pp);

before restore the default setting, is it safer to mvneta_port_disable()?

Thanks,
Jisheng

> + err = mvneta_port_power_up(pp, pp->phy_interface);
> + if (err < 0) {
> + dev_err(device, "can't power up port\n");
> + return err;
> + }
> +
> + if (pp->use_inband_status)
> + mvneta_fixed_link_update(pp, dev->phydev);
> +
> + netif_device_attach(dev);
> + if (netif_running(dev))
> + mvneta_open(dev);
> + return 0;
> +}
> +#endif
> +
> +static const struct dev_pm_ops mvneta_pm_ops = {
> + SET_LATE_SYSTEM_SLEEP_PM_OPS(mvneta_suspend, mvneta_resume)
> +};
> +
>  static const struct of_device_id mvneta_match[] = {
>   { .compatible = "marvell,armada-370-neta" },
>   { .compatible = "marvell,armada-xp-neta" },
> @@ -4419,6 +4462,7 @@ static int mvneta_remove(struct platform_device *pdev)
>   .driver = {
>   .name = MVNETA_DRIVER_NAME,
>   .of_match_table = mvneta_match,
> + .pm = _pm_ops,
>   },
>  };
>  

Re: [PATCH v2 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver

[Wolfgang Grandegger]

Hello Akshay,

Am 15.03.2017 um 05:44 schrieb Akshay Bhat:

Hi Wolfgang,

On Tue, Mar 14, 2017 at 2:08 PM, Wolfgang Grandegger  
wrote:
...snip

/disconnect cable
  can0  2088   [8]  00 00 00 19 00 00 28 00   ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{40}{0}}
  can0  2088   [8]  00 00 00 19 00 00 58 00   ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{88}{0}}
  can0  2088   [8]  00 00 00 19 00 00 80 00   ERRORFRAME
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{128}{0}}



TX error warning is missing.



This support was missing in the driver, added in V4 patch.


  can0  208C   [8]  00 20 00 19 00 00 80 00   ERRORFRAME
controller-problem{tx-error-passive}
protocol-violation{{}{acknowledge-slot}}
bus-error
error-counter-tx-rx{{128}{0}}



Here "tx-error-passiv" is packed with a bus error. What I'm looking for are
state change messages similar to:

   can0  2204  [8] 00 08 00 00 00 00 60 00   ERRORFRAME
controller-problem{tx-error-warning}
state-change{tx-error-warning}
error-counter-tx-rx{{96}{0}}
   can0  2204  [8] 00 30 00 00 00 00 80 00   ERRORFRAME
controller-problem{tx-error-passive}
state-change{tx-error-passive}
error-counter-tx-rx{{128}{0}

They should always come, even with "berr-reporting off".



HI-3110 has only 1 bus error interrupt. There is no dedicated state
change interrupts like other controllers.


To double check: Could you please read INTF, ERR and STATF at the 
beginning of the ISR and print it out (using dev_dbg and fiends). Then 
run a test with no cable connected and bus error reporting off.


Wolfgang.

[PATCH v2 2/2] drm/panel: add innolux,p079zca panel driver

[Chris Zhong]

Support Innolux P079ZCA 7.85" 768x1024 TFT LCD panel, it is a MIPI DSI
panel.

Signed-off-by: Chris Zhong 
---

Changes in v2:
- add some error check
- always use Low power mode to send commend
- add comments for all the sleep
- use DRM_DEV_ERROR instead of dev_err

 drivers/gpu/drm/panel/Kconfig |  11 +
 drivers/gpu/drm/panel/Makefile|   1 +
 drivers/gpu/drm/panel/panel-innolux-p079zca.c | 344 ++
 3 files changed, 356 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-innolux-p079zca.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 62aba97..99dd010 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -18,6 +18,17 @@ config DRM_PANEL_SIMPLE
  that it can be automatically turned off when the panel goes into a
  low power state.
 
+config DRM_PANEL_INNOLUX_P079ZCA
+   tristate "Innolux P079ZCA panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for Innolux P079ZCA
+ TFT-LCD modules. The panel has a 1024x768 resolution and uses
+ 24 bit RGB per pixel. It provides a MIPI DSI interface to
+ the host and has a built-in LED backlight.
+
 config DRM_PANEL_JDI_LT070ME05000
tristate "JDI LT070ME05000 WUXGA DSI panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index a5c7ec0..bda2aa4 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
+obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
 obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
 obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
new file mode 100644
index 000..b8c34e0
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -0,0 +1,344 @@
+/*
+ * Copyright (c) 2017, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct innolux_panel {
+   struct drm_panel base;
+   struct mipi_dsi_device *link;
+
+   struct backlight_device *backlight;
+   struct regulator *supply;
+   struct gpio_desc *enable_gpio;
+
+   bool prepared;
+   bool enabled;
+};
+
+static inline struct innolux_panel *to_innolux_panel(struct drm_panel *panel)
+{
+   return container_of(panel, struct innolux_panel, base);
+}
+
+static int innolux_panel_disable(struct drm_panel *panel)
+{
+   struct innolux_panel *innolux = to_innolux_panel(panel);
+   int err;
+
+   if (!innolux->enabled)
+   return 0;
+
+   if (innolux->backlight) {
+   innolux->backlight->props.power = FB_BLANK_POWERDOWN;
+   backlight_update_status(innolux->backlight);
+   }
+
+   err = mipi_dsi_dcs_set_display_off(innolux->link);
+   if (err < 0)
+   DRM_DEV_ERROR(panel->dev, "failed to set display off: %d\n",
+ err);
+
+   innolux->enabled = false;
+
+   return 0;
+}
+
+static int innolux_panel_unprepare(struct drm_panel *panel)
+{
+   struct innolux_panel *innolux = to_innolux_panel(panel);
+   int err;
+
+   if (!innolux->prepared)
+   return 0;
+
+   err = mipi_dsi_dcs_enter_sleep_mode(innolux->link);
+   if (err < 0) {
+   DRM_DEV_ERROR(panel->dev, "failed to enter sleep mode: %d\n",
+ err);
+   return err;
+   }
+
+   gpiod_set_value_cansleep(innolux->enable_gpio, 0);
+
+   /* T8: 80ms - 1000ms */
+   msleep(80);
+
+   err = regulator_disable(innolux->supply);
+   if (err < 0)
+   return err;
+
+   innolux->prepared = false;
+
+   return 0;
+}
+
+static int innolux_panel_prepare(struct drm_panel *panel)
+{
+   struct innolux_panel *innolux = to_innolux_panel(panel);
+   int err, ret;
+
+   if (innolux->prepared)
+   return 0;
+
+   gpiod_set_value_cansleep(innolux->enable_gpio, 0);
+
+   err = regulator_enable(innolux->supply);
+   if (err < 0)
+   return err;
+
+   /* T2: 15ms - 1000ms */
+   usleep_range(15000, 16000);
+
+   gpiod_set_value_cansleep(innolux->enable_gpio, 1);
+
+   /* T4: 15ms - 1000ms */
+   usleep_range(15000, 16000);
+

[PATCH v2 1/2] dt-bindings: Add INNOLUX P079ZCA panel bindings

[Chris Zhong]

The Innolux P079ZCA is a 7.85" panel with a 768X1024 resolution and
connected to DSI using four lanes.

Signed-off-by: Chris Zhong 
---

Changes in v2: None

 .../bindings/display/panel/innolux,p079zca.txt | 23 ++
 1 file changed, 23 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt 
b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
new file mode 100644
index 000..5c70a83
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
@@ -0,0 +1,23 @@
+Innolux P079ZCA 7.85" 768x1024 TFT LCD panel
+
+Required properties:
+- compatible: should be "innolux,p079zca"
+- reg: DSI virtual channel of the peripheral
+- power-supply: phandle of the regulator that provides the supply voltage
+- enable-gpios: panel enable gpio
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+
+   _dsi {
+   panel {
+   compatible = "innolux,p079zca";
+   reg = <0>;
+   power-supply = <...>;
+   backlight = <>;
+   enable-gpios = < 13 GPIO_ACTIVE_HIGH>;
+   status = "okay";
+   };
+   };
-- 
2.6.3

Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access

[Ayyappa Ch]

Is it possible on Carrizo asics? Or only supports on newer asics?

On Mon, Mar 13, 2017 at 6:11 PM, Christian König
 wrote:
> From: Christian König 
>
> Try to resize BAR0 to let CPU access all of VRAM.
>
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29 +
>  drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  |  8 +---
>  drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |  8 +---
>  4 files changed, 40 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 3b81ded..905ded9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1719,6 +1719,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device 
> *adev, struct ttm_tt *ttm,
>  struct ttm_mem_reg *mem);
>  void amdgpu_vram_location(struct amdgpu_device *adev, struct amdgpu_mc *mc, 
> u64 base);
>  void amdgpu_gtt_location(struct amdgpu_device *adev, struct amdgpu_mc *mc);
> +void amdgpu_resize_bar0(struct amdgpu_device *adev);
>  void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64 size);
>  int amdgpu_ttm_init(struct amdgpu_device *adev);
>  void amdgpu_ttm_fini(struct amdgpu_device *adev);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 118f4e6..92955fe 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -692,6 +692,35 @@ void amdgpu_gtt_location(struct amdgpu_device *adev, 
> struct amdgpu_mc *mc)
> mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
>  }
>
> +/**
> + * amdgpu_resize_bar0 - try to resize BAR0
> + *
> + * @adev: amdgpu_device pointer
> + *
> + * Try to resize BAR0 to make all VRAM CPU accessible.
> + */
> +void amdgpu_resize_bar0(struct amdgpu_device *adev)
> +{
> +   u32 size = max(ilog2(adev->mc.real_vram_size - 1) + 1, 20) - 20;
> +   int r;
> +
> +   r = pci_resize_resource(adev->pdev, 0, size);
> +
> +   if (r == -ENOTSUPP) {
> +   /* The hardware don't support the extension. */
> +   return;
> +
> +   } else if (r == -ENOSPC) {
> +   DRM_INFO("Not enoigh PCI address space for a large BAR.");
> +   } else if (r) {
> +   DRM_ERROR("Problem resizing BAR0 (%d).", r);
> +   }
> +
> +   /* Reinit the doorbell mapping, it is most likely moved as well */
> +   amdgpu_doorbell_fini(adev);
> +   BUG_ON(amdgpu_doorbell_init(adev));
> +}
> +
>  /*
>   * GPU helpers function.
>   */
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c 
> b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> index dc9b6d6..36a7aa5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> @@ -367,13 +367,15 @@ static int gmc_v7_0_mc_init(struct amdgpu_device *adev)
> break;
> }
> adev->mc.vram_width = numchan * chansize;
> -   /* Could aper size report 0 ? */
> -   adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
> -   adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
> /* size in MB on si */
> adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
> adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 
> 1024ULL;
>
> +   if (!(adev->flags & AMD_IS_APU))
> +   amdgpu_resize_bar0(adev);
> +   adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
> +   adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
> +
>  #ifdef CONFIG_X86_64
> if (adev->flags & AMD_IS_APU) {
> adev->mc.aper_base = ((u64)RREG32(mmMC_VM_FB_OFFSET)) << 22;
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c 
> b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> index c087b00..7761ad3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> @@ -459,13 +459,15 @@ static int gmc_v8_0_mc_init(struct amdgpu_device *adev)
> break;
> }
> adev->mc.vram_width = numchan * chansize;
> -   /* Could aper size report 0 ? */
> -   adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
> -   adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
> /* size in MB on si */
> adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
> adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 
> 1024ULL;
>
> +   if (!(adev->flags & AMD_IS_APU))
> +   amdgpu_resize_bar0(adev);
> +   adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
> +   adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
> +
>  #ifdef CONFIG_X86_64
> if (adev->flags & AMD_IS_APU) {
> adev->mc.aper_base = ((u64)RREG32(mmMC_VM_FB_OFFSET)) << 22;
> --
> 2.7.4
>
> 

[PATCH v5 0/3] Use data tune for CMD line tune

[Yong Mao]

yong mao (3):
  mmc: dt-bindings: update Mediatek MMC bindings
  ARM64: dts: mediatek: configure some fixed mmc parameters
  mmc: mediatek: Use data tune for CMD line tune

 Documentation/devicetree/bindings/mmc/mtk-sd.txt |  12 ++
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts  |   3 +
 drivers/mmc/host/mtk-sd.c| 168 ---
 3 files changed, 167 insertions(+), 16 deletions(-)

-- 
1.8.1.1.dirty

[PATCH v5 3/3] mmc: mediatek: Use data tune for CMD line tune

[Yong Mao]

From: yong mao 

If we don't select a set of better parameters for our emmc host,
It may easily occur CMD response CRC error. And also it may cause
cannot boot up issue.

Fot getting a set of better parameters, our emmc host supports
data tune mechanism.Therefore, our emmc driver also should change
to use data tune for CMD line.

Because our emmc host use the different clock source to sample the
CMD signal between HS200 and HS400 mode, the parameters are also
different between these two modes.
Separate cmd internal delay for HS200/HS400 mode.

This change can fix "System can not boot up" issue.

Signed-off-by: Yong Mao 
Signed-off-by: Chaotian Jing 
---
 drivers/mmc/host/mtk-sd.c |  168 -
 1 file changed, 152 insertions(+), 16 deletions(-)

diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 80ba034..07f3236 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -75,6 +75,7 @@
 #define MSDC_PATCH_BIT1  0xb4
 #define MSDC_PAD_TUNE0xec
 #define PAD_DS_TUNE  0x188
+#define PAD_CMD_TUNE 0x18c
 #define EMMC50_CFG0  0x208
 
 /*--*/
@@ -210,13 +211,18 @@
 #define MSDC_PATCH_BIT_SPCPUSH(0x1 << 29)  /* RW */
 #define MSDC_PATCH_BIT_DECRCTMO   (0x1 << 30)  /* RW */
 
+#define MSDC_PAD_TUNE_DATWRDLY   (0x1f <<  0)  /* RW */
 #define MSDC_PAD_TUNE_DATRRDLY   (0x1f <<  8)  /* RW */
 #define MSDC_PAD_TUNE_CMDRDLY(0x1f << 16)  /* RW */
+#define MSDC_PAD_TUNE_CMDRRDLY   (0x1f << 22)  /* RW */
+#define MSDC_PAD_TUNE_CLKTDLY(0x1f << 27)  /* RW */
 
 #define PAD_DS_TUNE_DLY1 (0x1f << 2)   /* RW */
 #define PAD_DS_TUNE_DLY2 (0x1f << 7)   /* RW */
 #define PAD_DS_TUNE_DLY3 (0x1f << 12)  /* RW */
 
+#define PAD_CMD_TUNE_RX_DLY3 (0x1f << 1)  /* RW */
+
 #define EMMC50_CFG_PADCMD_LATCHCK (0x1 << 0)   /* RW */
 #define EMMC50_CFG_CRCSTS_EDGE(0x1 << 3)   /* RW */
 #define EMMC50_CFG_CFCSTS_SEL (0x1 << 4)   /* RW */
@@ -284,12 +290,14 @@ struct msdc_save_para {
u32 patch_bit0;
u32 patch_bit1;
u32 pad_ds_tune;
+   u32 pad_cmd_tune;
u32 emmc50_cfg0;
 };
 
 struct msdc_tune_para {
u32 iocon;
u32 pad_tune;
+   u32 pad_cmd_tune;
 };
 
 struct msdc_delay_phase {
@@ -331,6 +339,10 @@ struct msdc_host {
unsigned char timing;
bool vqmmc_enabled;
u32 hs400_ds_delay;
+   u32 hs200_cmd_int_delay; /* cmd internal delay for HS200/SDR104 */
+   u32 hs400_cmd_int_delay; /* cmd internal delay for HS400 */
+   bool hs400_cmd_resp_sel_rising;
+/* cmd response sample selection for HS400 */
bool hs400_mode;/* current eMMC will run at hs400 mode */
struct msdc_save_para save_para; /* used when gate HCLK */
struct msdc_tune_para def_tune_para; /* default tune setting */
@@ -600,8 +612,14 @@ static void msdc_set_mclk(struct msdc_host *host, unsigned 
char timing, u32 hz)
} else {
writel(host->saved_tune_para.iocon, host->base + MSDC_IOCON);
writel(host->saved_tune_para.pad_tune, host->base + 
MSDC_PAD_TUNE);
+   writel(host->saved_tune_para.pad_cmd_tune,
+  host->base + PAD_CMD_TUNE);
}
 
+   if (timing == MMC_TIMING_MMC_HS400)
+   sdr_set_field(host->base + PAD_CMD_TUNE,
+ MSDC_PAD_TUNE_CMDRRDLY,
+ host->hs400_cmd_int_delay);
dev_dbg(host->dev, "sclk: %d, timing: %d\n", host->sclk, timing);
 }
 
@@ -1302,7 +1320,7 @@ static struct msdc_delay_phase get_best_delay(struct 
msdc_host *host, u32 delay)
len_final = len;
}
start += len ? len : 1;
-   if (len >= 8 && start_final < 4)
+   if (len >= 12 && start_final < 4)
break;
}
 
@@ -1325,36 +1343,67 @@ static int msdc_tune_response(struct mmc_host *mmc, u32 
opcode)
struct msdc_host *host = mmc_priv(mmc);
u32 rise_delay = 0, fall_delay = 0;
struct msdc_delay_phase final_rise_delay, final_fall_delay = { 0,};
+   struct msdc_delay_phase internal_delay_phase;
u8 final_delay, final_maxlen;
+   u32 internal_delay = 0;
int cmd_err;
-   int i;
+   int i, j;
+
+   if (mmc->ios.timing == MMC_TIMING_MMC_HS200 ||
+   mmc->ios.timing == MMC_TIMING_UHS_SDR104)
+   sdr_set_field(host->base + MSDC_PAD_TUNE,
+ MSDC_PAD_TUNE_CMDRRDLY,
+ host->hs200_cmd_int_delay);
 
sdr_clr_bits(host->base + MSDC_IOCON, MSDC_IOCON_RSPL);
for (i = 0 ; i < PAD_DELAY_MAX; i++) {
sdr_set_field(host->base + MSDC_PAD_TUNE,
  MSDC_PAD_TUNE_CMDRDLY, i);
-   mmc_send_tuning(mmc, opcode, _err);
-   if 

[PATCH v5 1/3] mmc: dt-bindings: update Mediatek MMC bindings

[Yong Mao]

From: yong mao 

Add description for mediatek,hs200-cmd-int-delay
Add description for mediatek,hs400-cmd-int-delay
Add description for mediatek,hs400-cmd-resp-sel-rising

Signed-off-by: Yong Mao 
---
 Documentation/devicetree/bindings/mmc/mtk-sd.txt |   12 
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt 
b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
index 0120c7f..4182ea3 100644
--- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
+++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
@@ -21,6 +21,15 @@ Optional properties:
 - assigned-clocks: PLL of the source clock
 - assigned-clock-parents: parent of source clock, used for HS400 mode to get 
400Mhz source clock
 - hs400-ds-delay: HS400 DS delay setting
+- mediatek,hs200-cmd-int-delay: HS200 command internal delay setting.
+   This field has total 32 stages.
+   The value is an integer from 0 to 31.
+- mediatek,hs400-cmd-int-delay: HS400 command internal delay setting
+   This field has total 32 stages.
+   The value is an integer from 0 to 31.
+- mediatek,hs400-cmd-resp-sel-rising:  HS400 command response sample selection
+  If present,HS400 command responses are 
sampled on rising edges.
+  If not present,HS400 command responses 
are sampled on falling edges.
 
 Examples:
 mmc0: mmc@1123 {
@@ -38,4 +47,7 @@ mmc0: mmc@1123 {
assigned-clocks = < CLK_TOP_MSDC50_0_SEL>;
assigned-clock-parents = < CLK_TOP_MSDCPLL_D2>;
hs400-ds-delay = <0x14015>;
+   mediatek,hs200-cmd-int-delay = <26>;
+   mediatek,hs400-cmd-int-delay = <14>;
+   mediatek,hs400-cmd-resp-sel-rising;
 };
-- 
1.7.9.5

Re: [PATCH v2 04/10] mm: make the try_to_munlock void function

[Vlastimil Babka]

On 03/15/2017 06:24 AM, Minchan Kim wrote:
> try_to_munlock returns SWAP_MLOCK if the one of VMAs mapped
> the page has VM_LOCKED flag. In that time, VM set PG_mlocked to
> the page if the page is not pte-mapped THP which cannot be
> mlocked, either.
> 
> With that, __munlock_isolated_page can use PageMlocked to check
> whether try_to_munlock is successful or not without relying on
> try_to_munlock's retval. It helps to make try_to_unmap/try_to_unmap_one
> simple with upcoming patches.
> 
> Cc: Vlastimil Babka 
> Acked-by: Kirill A. Shutemov 
> Signed-off-by: Minchan Kim 

Acked-by: Vlastimil Babka 

[PATCH v5 2/3] ARM64: dts: mediatek: configure some fixed mmc parameters

[Yong Mao]

From: yong mao 

configure some fixed mmc parameters

Signed-off-by: Yong Mao 
Signed-off-by: Chaotian Jing 
---
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts |3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts 
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index 0ecaad4..1c3634f 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -134,6 +134,9 @@
bus-width = <8>;
max-frequency = <5000>;
cap-mmc-highspeed;
+   mediatek,hs200-cmd-int-delay=<26>;
+   mediatek,hs400-cmd-int-delay=<14>;
+   mediatek,hs400-cmd-resp-sel-rising;
vmmc-supply = <_vemc_3v3_reg>;
vqmmc-supply = <_vio18_reg>;
non-removable;
-- 
1.7.9.5

Re: [PATCH] drm/exynos: Print kernel pointers in a restricted form

[Andrzej Hajda]

Hi Tobias,

On 14.03.2017 21:41, Tobias Jakobi wrote:
> Krzysztof Kozlowski wrote:
>> On Tue, Mar 14, 2017 at 08:17:35PM +0100, Tobias Jakobi wrote:
>>> Krzysztof Kozlowski wrote:
 On Tue, Mar 14, 2017 at 08:01:41PM +0100, Tobias Jakobi wrote:
> Hello Krzysztof,
>
> I was wondering about the benefit of this. From a quick look these are
> all messages that end up in the kernel log / dmesg.
>
> IIRC %pK does nothing there, since dmest_restrict is supposed to be used
> to deny an unpriviliged user the access to the kernel log.
>
> Or am I missing something here?
 These are regular printks so depending on kernel options (e.g. dynamic
 debug, drm.debug) these might be printed also in the console. Of course
 we could argue then if access to one of the consoles is worth
 securing.
>>> This here suggests otherwise.
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/sysctl/kernel.txt#n388
>>>
>>> I have not tested this, but IIRC %pK is not honored by the kernel
>>> logging infrastucture. That's why dmesg_restrict is there.
>>>
>>> Correct me if I'm wrong.
>> The %pK will not help for dmesg or /proc/kmsg but it will help for
>> console (/dev/ttySACN, ttySN etc) because effectively it uses the same
>> vsprintf()/pointer() functions.
> Thanks for the explanation, I didn't know that there was a difference
> there. In that case, looks good to me.
>
>

Just to clarify %pK:

Documentation/printk-formats.txt:
%pK 0x01234567 or 0x0123456789abcdef

For printing kernel pointers which should be hidden from
unprivileged
users. The behaviour of %pK depends on the kptr_restrict sysctl
- see
Documentation/sysctl/kernel.txt for more details.

Documentation/sysctl/kernel.txt:

kptr_restrict:

This toggle indicates whether restrictions are placed on
exposing kernel addresses via /proc and other interfaces.

When kptr_restrict is set to (0), the default, there are no restrictions.

When kptr_restrict is set to (1), kernel pointers printed using the %pK
format specifier will be replaced with 0's unless the user has CAP_SYSLOG
and effective user and group ids are equal to the real ids. This is
because %pK checks are done at read() time rather than open() time, so
if permissions are elevated between the open() and the read() (e.g via
a setuid binary) then %pK will not leak kernel pointers to unprivileged
users. Note, this is a temporary solution only. The correct long-term
solution is to do the permission checks at open() time. Consider removing
world read permissions from files that use %pK, and using dmesg_restrict
to protect against uses of %pK in dmesg(8) if leaking kernel pointer
values to unprivileged users is a concern.

When kptr_restrict is set to (2), kernel pointers printed using
%pK will be replaced with 0's regardless of privileges.
---

Regards
Andrzej

Re: [PATCH 4.4 17/25] USB: serial: digi_acceleport: fix OOB data sanity check

[Greg Kroah-Hartman]

On Mon, Mar 13, 2017 at 06:14:37PM +0100, Johan Hovold wrote:
> On Fri, Feb 24, 2017 at 06:55:02PM +0100, Greg Kroah-Hartman wrote:
> > On Fri, Feb 24, 2017 at 06:33:04PM +0100, Johan Hovold wrote:
> > > On Fri, Feb 24, 2017 at 01:38:25PM +, Ben Hutchings wrote: > On Fri, 
> > > 2017-02-24 at 09:25 +0100, Greg Kroah-Hartman wrote:
> > > > > 4.4-stable review patch.  If anyone has any objections, please let me 
> > > > > know.
> > > > > 
> > > > > --
> > > > > 
> > > > > From: Johan Hovold 
> > > > > 
> > > > > commit 2d380889215fe20b8523345649dee0579821800c upstream.
> > > > > 
> > > > > Make sure to check for short transfers to avoid underflow in a loop
> > > > > condition when parsing the receive buffer.
> > > > > 
> > > > > Also fix an off-by-one error in the incomplete sanity check which 
> > > > > could
> > > > > lead to invalid data being parsed.
> > > > 
> > > > This appears to *introduce* an off-by-one.  Which is not as serious as
> > > > the underflow, but is still a regression.
> > > > 
> > > > Suppose we have urb->actual_length == 4:
> > > > 
> > > > [...]
> > > > > - for (i = 0; i < urb->actual_length - 3;) {
> > > > 
> > > > i < 1 is true, so we would run the loop once.
> > > > 
> > > > > - opcode = ((unsigned char *)urb->transfer_buffer)[i++];
> > > > > - line = ((unsigned char *)urb->transfer_buffer)[i++];
> > > > > - status = ((unsigned char *)urb->transfer_buffer)[i++];
> > > > > - val = ((unsigned char *)urb->transfer_buffer)[i++];
> > > > > + for (i = 0; i < urb->actual_length - 4; i += 4) {
> > > > 
> > > > i < 0 is false, so we now skip the loop.
> > > 
> > > Good catch, thanks! The original loop condition was indeed correct
> > > (modulo the missing underflow check), and I'll post a follow-up fix to
> > > address this.
> > > 
> > > > > + opcode = buf[i];
> > > > > + line = buf[i + 1];
> > > > > + status = buf[i + 2];
> > > > > + val = buf[i + 3];
> > > 
> > > You should probably not apply this one until after the follow-up is in
> > > Linus' tree as this patch breaks TIOCMGET.
> > 
> > Ok, I'll drop this one from the stable tree now.  Remind me to pick this
> > one up when the fixup hits Linus's tree.
> 
> The follow-up fix is now in Linus's tree so both this one:
> 
>   2d380889215f ("USB: serial: digi_acceleport: fix OOB data sanity check")
> 
> and the follow-up:
> 
>   2e46565cf622 ("USB: serial: digi_acceleport: fix OOB-event processing")
> 
> can now be applied to the stable trees.

Thanks, now queued up.

greg k-h

Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access

[Christian König]

Carizzo is an APU and resizing BARs isn't needed nor supported there. 
The CPU can access the full stolen VRAM directly on that hardware.


As far as I know ASICs with support for this are Tonga, Fiji and all 
Polaris variants.


Christian.

Am 15.03.2017 um 08:23 schrieb Ayyappa Ch:

Is it possible on Carrizo asics? Or only supports on newer asics?

On Mon, Mar 13, 2017 at 6:11 PM, Christian König
 wrote:

From: Christian König 

Try to resize BAR0 to let CPU access all of VRAM.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29 +
  drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  |  8 +---
  drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |  8 +---
  4 files changed, 40 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 3b81ded..905ded9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1719,6 +1719,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device 
*adev, struct ttm_tt *ttm,
  struct ttm_mem_reg *mem);
  void amdgpu_vram_location(struct amdgpu_device *adev, struct amdgpu_mc *mc, 
u64 base);
  void amdgpu_gtt_location(struct amdgpu_device *adev, struct amdgpu_mc *mc);
+void amdgpu_resize_bar0(struct amdgpu_device *adev);
  void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64 size);
  int amdgpu_ttm_init(struct amdgpu_device *adev);
  void amdgpu_ttm_fini(struct amdgpu_device *adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 118f4e6..92955fe 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -692,6 +692,35 @@ void amdgpu_gtt_location(struct amdgpu_device *adev, 
struct amdgpu_mc *mc)
 mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
  }

+/**
+ * amdgpu_resize_bar0 - try to resize BAR0
+ *
+ * @adev: amdgpu_device pointer
+ *
+ * Try to resize BAR0 to make all VRAM CPU accessible.
+ */
+void amdgpu_resize_bar0(struct amdgpu_device *adev)
+{
+   u32 size = max(ilog2(adev->mc.real_vram_size - 1) + 1, 20) - 20;
+   int r;
+
+   r = pci_resize_resource(adev->pdev, 0, size);
+
+   if (r == -ENOTSUPP) {
+   /* The hardware don't support the extension. */
+   return;
+
+   } else if (r == -ENOSPC) {
+   DRM_INFO("Not enoigh PCI address space for a large BAR.");
+   } else if (r) {
+   DRM_ERROR("Problem resizing BAR0 (%d).", r);
+   }
+
+   /* Reinit the doorbell mapping, it is most likely moved as well */
+   amdgpu_doorbell_fini(adev);
+   BUG_ON(amdgpu_doorbell_init(adev));
+}
+
  /*
   * GPU helpers function.
   */
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
index dc9b6d6..36a7aa5 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
@@ -367,13 +367,15 @@ static int gmc_v7_0_mc_init(struct amdgpu_device *adev)
 break;
 }
 adev->mc.vram_width = numchan * chansize;
-   /* Could aper size report 0 ? */
-   adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
-   adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
 /* size in MB on si */
 adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
 adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;

+   if (!(adev->flags & AMD_IS_APU))
+   amdgpu_resize_bar0(adev);
+   adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
+   adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
+
  #ifdef CONFIG_X86_64
 if (adev->flags & AMD_IS_APU) {
 adev->mc.aper_base = ((u64)RREG32(mmMC_VM_FB_OFFSET)) << 22;
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index c087b00..7761ad3 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
@@ -459,13 +459,15 @@ static int gmc_v8_0_mc_init(struct amdgpu_device *adev)
 break;
 }
 adev->mc.vram_width = numchan * chansize;
-   /* Could aper size report 0 ? */
-   adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
-   adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
 /* size in MB on si */
 adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
 adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;

+   if (!(adev->flags & AMD_IS_APU))
+   amdgpu_resize_bar0(adev);
+   adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
+   adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
+
  #ifdef CONFIG_X86_64
 if (adev->flags & AMD_IS_APU) {
 

Re: [PATCH] mm: move pcp and lru-pcp drainging into single wq

[Michal Hocko]

On Tue 14-03-17 18:07:38, Yang Li wrote:
> On Mon, Mar 13, 2017 at 4:58 AM, Michal Hocko  wrote:
> > On Fri 10-03-17 17:31:56, Yang Li wrote:
> >> On Tue, Mar 7, 2017 at 7:17 AM, Michal Hocko  wrote:
> >> > From: Michal Hocko 
> >> >
> >> > We currently have 2 specific WQ_RECLAIM workqueues in the mm code.
> >> > vmstat_wq for updating pcp stats and lru_add_drain_wq dedicated to drain
> >> > per cpu lru caches. This seems more than necessary because both can run
> >> > on a single WQ. Both do not block on locks requiring a memory allocation
> >> > nor perform any allocations themselves. We will save one rescuer thread
> >> > this way.
> >> >
> >> > On the other hand drain_all_pages() queues work on the system wq which
> >> > doesn't have rescuer and so this depend on memory allocation (when all
> >> > workers are stuck allocating and new ones cannot be created). This is
> >> > not critical as there should be somebody invoking the OOM killer (e.g.
> >> > the forking worker) and get the situation unstuck and eventually
> >> > performs the draining. Quite annoying though. This worker should be
> >> > using WQ_RECLAIM as well. We can reuse the same one as for lru draining
> >> > and vmstat.
> >> >
> >> > Changes since v1
> >> > - rename vmstat_wq to mm_percpu_wq - per Mel
> >> > - make sure we are not trying to enqueue anything while the WQ hasn't
> >> >   been intialized yet. This shouldn't happen because the initialization
> >> >   is done from an init code but some init section might be triggering
> >> >   those paths indirectly so just warn and skip the draining in that case
> >> >   per Vlastimil
> >>
> >> So what's the plan if this really happens?  Shall we put the
> >> initialization of the mm_percpu_wq earlier?
> >
> > yes
> >
> >> Or if it is really harmless we can probably remove the warnings.
> >
> > Yeah, it is harmless but if we can move it earlier then it would be
> > prefferable to fix this.
> >
> >>
> >> I'm seeing this on arm64 with a linux-next tree:
> > [...]
> >> [0.279000] [] drain_all_pages+0x244/0x25c
> >> [0.279065] [] start_isolate_page_range+0x14c/0x1f0
> >> [0.279137] [] alloc_contig_range+0xec/0x354
> >> [0.279203] [] cma_alloc+0x100/0x1fc
> >> [0.279263] [] dma_alloc_from_contiguous+0x3c/0x44
> >> [0.279336] [] atomic_pool_init+0x7c/0x208
> >> [0.279399] [] arm64_dma_init+0x44/0x4c
> >> [0.279461] [] do_one_initcall+0x38/0x128
> >> [0.279525] [] kernel_init_freeable+0x1a0/0x240
> >> [0.279596] [] kernel_init+0x10/0xfc
> >> [0.279654] [] ret_from_fork+0x10/0x20
> >
> > The following should address this. I didn't get to test it yet though.
> > ---
> > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > index 21ee5503c702..8362dca071cb 100644
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -32,6 +32,8 @@ struct user_struct;
> >  struct writeback_control;
> >  struct bdi_writeback;
> >
> > +void init_mm_internals(void);
> > +
> >  #ifndef CONFIG_NEED_MULTIPLE_NODES /* Don't use mapnrs, do it properly 
> > */
> >  extern unsigned long max_mapnr;
> >
> > diff --git a/init/main.c b/init/main.c
> > index 51aa8f336819..c72d35250e84 100644
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -1023,6 +1023,8 @@ static noinline void __init kernel_init_freeable(void)
> >
> > workqueue_init();
> >
> > +   init_mm_internals();
> > +
> > do_pre_smp_initcalls();
> > lockup_detector_init();
> >
> > diff --git a/mm/vmstat.c b/mm/vmstat.c
> > index 4bbc775f9d08..d0871fc1aeca 100644
> > --- a/mm/vmstat.c
> > +++ b/mm/vmstat.c
> > @@ -1762,7 +1762,7 @@ static int vmstat_cpu_dead(unsigned int cpu)
> >
> >  struct workqueue_struct *mm_percpu_wq;
> >
> > -static int __init setup_vmstat(void)
> > +void __init init_mm_internals(void)
> >  {
> > int ret __maybe_unused;
> >
> > @@ -1792,9 +1792,7 @@ static int __init setup_vmstat(void)
> > proc_create("vmstat", S_IRUGO, NULL, _vmstat_file_operations);
> > proc_create("zoneinfo", S_IRUGO, NULL, 
> > _zoneinfo_file_operations);
> >  #endif
> > -   return 0;
> >  }
> > -module_init(setup_vmstat)
> >
> >  #if defined(CONFIG_DEBUG_FS) && defined(CONFIG_COMPACTION)
> 
> I did a test on arm64.  This do fix the warnings.

Thanks! Can I assume your
Tested-by: Yang Li 

-- 
Michal Hocko
SUSE Labs

Re: [linux-sunxi] [PATCH v3 3/5] ARM: dts: sun8i: h3: add usb_otg and OHCI/EHCI for usbc0 on H3

[Chen-Yu Tsai]

On Tue, Mar 7, 2017 at 6:34 AM, Icenowy Zheng  wrote:
> Allwinner H3 have a dual-routed USB PHY0 -- routed to either OHCI/EHCI
> or MUSB controller.
>
> Add device nodes for these controllers.
>
> Signed-off-by: Icenowy Zheng 

Acked-by: Chen-Yu Tsai 

Re: [PATCH] sched/deadline: Add missing update_rq_clock() in dl_task_timer()

[Wanpeng Li]

Ping, :)
2017-03-07 13:51 GMT+08:00 Wanpeng Li :
> From: Wanpeng Li 
>
> The following warning can be triggered by hot-unplugging the CPU
> on which an active SCHED_DEADLINE task is running on:
>
>  [ cut here ]
>  WARNING: CPU: 7 PID: 0 at kernel/sched/sched.h:833 
> replenish_dl_entity+0x71e/0xc40
>  rq->clock_update_flags < RQCF_ACT_SKIP
>  CPU: 7 PID: 0 Comm: swapper/7 Tainted: GB   4.11.0-rc1+ #24
>  Hardware name: LENOVO ThinkCentre M8500t-N000/SHARKBAY, BIOS FBKTC1AUS 
> 02/16/2016
>  Call Trace:
>   
>   dump_stack+0x85/0xc4
>   __warn+0x172/0x1b0
>   warn_slowpath_fmt+0xb4/0xf0
>   ? __warn+0x1b0/0x1b0
>   ? debug_check_no_locks_freed+0x2c0/0x2c0
>   ? cpudl_set+0x3d/0x2b0
>   replenish_dl_entity+0x71e/0xc40
>   enqueue_task_dl+0x2ea/0x12e0
>   ? dl_task_timer+0x777/0x990
>   ? __hrtimer_run_queues+0x270/0xa50
>   dl_task_timer+0x316/0x990
>   ? enqueue_task_dl+0x12e0/0x12e0
>   ? enqueue_task_dl+0x12e0/0x12e0
>   __hrtimer_run_queues+0x270/0xa50
>   ? hrtimer_cancel+0x20/0x20
>   ? hrtimer_interrupt+0x119/0x600
>   hrtimer_interrupt+0x19c/0x600
>   ? trace_hardirqs_off+0xd/0x10
>   local_apic_timer_interrupt+0x74/0xe0
>   smp_apic_timer_interrupt+0x76/0xa0
>   apic_timer_interrupt+0x93/0xa0
>
> The DL task will be migrated to a suitable later deadline rq once the DL
> timer fires and currnet rq is offline. The rq clock of the new rq should
> be updated. This patch fixes it by updating the rq clock after holding
> the new rq's rq lock.
>
> Cc: Juri Lelli 
> Cc: Peter Zijlstra 
> Cc: Ingo Molnar 
> Cc: Thomas Gleixner 
> Cc: Matt Fleming 
> Signed-off-by: Wanpeng Li 
> ---
>  kernel/sched/deadline.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index 99b2c33..c6db3fd 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -638,6 +638,7 @@ static enum hrtimer_restart dl_task_timer(struct hrtimer 
> *timer)
> lockdep_unpin_lock(>lock, rf.cookie);
> rq = dl_task_offline_migration(rq, p);
> rf.cookie = lockdep_pin_lock(>lock);
> +   update_rq_clock(rq);
>
> /*
>  * Now that the task has been migrated to the new RQ and we
> --
> 2.7.4
>

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

[Michal Hocko]

On Tue 14-03-17 14:20:14, Igor Mammedov wrote:
> On Mon, 13 Mar 2017 13:28:25 +0100
> Michal Hocko  wrote:
> 
> > On Mon 13-03-17 11:55:54, Igor Mammedov wrote:
> > > On Thu, 9 Mar 2017 13:54:00 +0100
> > > Michal Hocko  wrote:
[...]
> > > > The kernel is supposed to provide a proper API and that is sysfs
> > > > currently. I am not entirely happy about it either but pulling a lot of
> > > > code into the kernel is not the rigth thing to do. Especially when
> > > > different usecases require different treatment.  
> > >
> > > If it could be done from kernel side alone, it looks like a better way
> > > to me not to involve userspace at all. And for ACPI based x86/ARM it's
> > > possible to implement without adding a lot of kernel code.  
> > 
> > But this is not how we do the kernel development. We provide the API so
> > that userspace can implement the appropriate policy on top. We do not
> > add random knobs to implement the same thing in the kernel. Different
> > users might want to implement different onlining strategies and that is
> > hardly describable by a single global knob. Just look at the s390
> > example provided earlier. Please try to think out of your usecase scope.
>
> And could you think outside of legacy sysfs based onlining usecase scope?

Well, I always prefer a more generic solution which supports more
usecases and I am trying really hard to understand usecases you are
coming up with. So far I have heard that the current sysfs behavior is
broken (which is true!) and some very vague arguments about why we need
to online as quickly as possible to the point that userspace handling is
an absolute no go.

To be honest I still consider the later a non-issue. If the only thing
you care about is the memory footprint of the first phase then I believe
this is fixable. Memblock and section descriptors should be the only
necessary thing to allocate and that is not much.

As an aside, the more I think about the way the original authors
separated the physical hotadd from onlining the more I appreciate that
decision because the way how the memory can be online is definitely not
carved in stone and evolves with usecases. I believe nobody expected
that memory could be onlined as movable back then and I am pretty sure
new ways will emerge over time.
 
> I don't think that S390 comparing with x86 is correct as platforms
> and hardware implementations of memory hotplug are different with
> correspondingly different requirements, hence 
> CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE
> were introduced to allows platform specify behavior.

There are different usecases which are arch agnostic. E.g. decide the
movability based on some criterion (e.g. specific node, physical address
range and what not). Global auto onlining cannot handle those for obvious
reasons and a config option will not do achieve that for the same
reason.

> For x86/ARM(+ACPI) it's possible to implement hotplug in race free
> way inside kernel without userspace intervention, onlining memory
> using hardware vendor defined policy (ACPI SRAT/Memory device describe
> memory sufficiently to do it) so user won't have to do it manually,
> config option is a convenient way to enable new feature for platforms
> that could support it.

Sigh. Can you see the actual difference between the global kernel policy
and the policy coming from the specific hardware (ACPI etc...)? I am not
opposing auto onlining based on the ACPI attributes. But what we have
now is a policy _in_the_kernel_. This is almost always a bad idea and
I do not see any strong argument why it would be any different in this
particular case. Actually your current default in Fedora makes it harder
for anybody to use movable zones/nodes.

> It's good to maintain uniform API to userspace as far as API does
> the job, but being stuck to legacy way isn't good when
> there is a way (even though it's limited to limited set of platforms)
> to improve it by removing need for API, making overall less complex
> and race-less (more reliable) system.

then convince your virtualization platform to provide necessary data
for the memory auto onlining via ACPI etc...

> > > That's one more of a reason to keep CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE
> > > so we could continue on improving kernel only auto-onlining
> > > and fixing current memory hot(un)plug issues without affecting
> > > other platforms/users that are no interested in it.  
> > 
> > I really do not see any reason to keep the config option. Setting up
> > this to enabled is _wrong_ thing to do in general purpose
> > (distribution) kernel and a kernel for the specific usecase can achieve
> > the same thing via boot command line.
>
> I have to disagree with you that setting policy 'not online by default'
> in kernel is more valid than opposite policy 'online by default'.
> It maybe works for your usecases but it doesn't mean that it suits
> needs of others.

Well, as described above there are good reasons to not hardwire any
policy into the kernel 

Re: [PATCH] [media] v4l2-dv-timings: Introduce v4l2_calc_fps()

[Hans Verkuil]

On 03/14/2017 08:14 PM, Jose Abreu wrote:
> Hi Hans,
> 
> 
> On 14-03-2017 07:24, Hans Verkuil wrote:
>>> Right, I was forgetting about this ...
>>>
>>> So:
>>> 1) Most of HDMI receivers do not have the expected precision in
>>> measuring pixel clock value;
>> s/Most/Some/
>>
>> Newer HDMI receivers tend to have better precision.
>>
>> However, the 1000/1001 factor is within the error of margin that the HDMI
>> spec has for the pixelclock, so even if it is 59.94 you still (theoretically)
>> do not know if that is because it really has that fps or if the source just 
>> has
>> a bad clock.
> 
> Hmm. But if source has a bad clock then it won't send at the
> expected frame rate, so if we are able to measure pixel clock
> value we will get the approximated frame rate for that source,
> right? Unless the source also doesn't have standard h/v timings,
> but as long as receiver detects this correctly then we can calculate.

s/bad clock/slightly different clock/

The problem is that the HDMI spec has an error of margin for the pixelclock of
(I think) 0.25%. The difference in pixelclock between 60 and 59.94 Hz is about
0.1%. In addition the source clock and the sink clock will run at slightly 
different
speeds. So all this makes it hard to reliably measure.

Now, we never tested this and in reality the difference between 60 an 59.94 
might
be as clear as day and night (for receivers with sufficient timer resolution).

So that's why more information is needed.

> 
>>
>> It's a bit theoretical, in practice you can assume the source really is 
>> sending
>> at 59.94 AFAIK.
>>
>>> 2) Most (I would guess all of them?) have access to AVI infoframe
>>> contents;
>> All will have that.
>>
>>> 3) The FPS value is generally used by applications to calculate
>>> expected frame rate and number of frames dropped (right?);
>> Not really. Most HDMI drivers do not implement g_parm, instead they fill in
>> the detected pixelclock in QUERY_DV_TIMINGS, leaving it up to the application
>> to calculate the fps from that.
>>
>>> 4) The factor in FPS value can be adjusted by 1000/1001;
>>>
>>> From these points I would propose in just using the vic and drop
>>> the resolution in fps a little bit, do you agree?
>> The reality is that how to detect the 1000/1001 reduced fps is fuzzy. Part of
>> the reason for that is that most of the HDMI receivers we have in the kernel
>> were developed by Cisco/Tandberg (i.e. mostly me) for our video conferencing
>> systems, and those all run at 60 Hz. So we never had the need to detect 
>> 59.94 vs
>> 60 Hz. In addition, some of the older Analog Devices devices didn't have the
>> resolution to detect the difference.
>>
>> So I always held off a bit with defining exactly how to do this since I had
>> no experience with it.
>>
>> My question to you is: can you reliably detect the difference between 60 and 
>> 59.94
>> Hz and between 24 and 23.976 Hz by just the measured pixelclock?
>>
>> You need to test this with different sources, not just signal generators. You
>> probably get a range of pixelclock values for the same framerate for 
>> different
>> sources, since each source has their own clock.
> 
> I will have to conduct more tests to confirm but the expected
> resolution is more than enough to detect 1000/1001 changes.
> 
>>
>> My preference would be to extend query_dv_timings a bit for this:
>>
>> 
>> Add a flag V4L2_DV_FL_CAN_DETECT_REDUCED_FPS. If set, then the hw can detect 
>> the
>> difference between regular fps and 1000/1001 fps. Note: this is only valid 
>> for
>> timings of VIC codes with the V4L2_DV_FL_CAN_REDUCE_FPS flag set.
> 
> Where should we set the flag? In v4l2_dv_timings_cap?

I was thinking v4l2_bt_timings, but a capability in v4l2_bt_timings_cap is not
a bad idea. Although that's global while having it in v4l2_bt_timings makes it
specific to the detected timings. Just in case the hardware can detect it for
some pixelclock frequencies, but not for others. But I'm not sure if that can
happen.

> 
>>
>> Allow V4L2_DV_FL_REDUCED_FPS to be used for receivers if 
>> V4L2_DV_FL_CAN_DETECT_REDUCED_FPS
>> is set.
>>
>> For standard VIC codes the pixelclock returned by query_dv_timings is that 
>> of the
>> corresponding VIC timing, not what is measured. This will ensure fixed fps 
>> values
>>
>> g_parm should calculate the fps based on the v4l2_bt_timings struct, looking 
>> at the
>> REDUCES_FPS flags.
>>
>> For those receivers that cannot detect the difference, the fps will be 
>> 24/30/60 Hz,
>> for those that can detect the difference g_parm can check if both 
>> V4L2_DV_FL_CAN_DETECT_REDUCED_FPS
>> and V4L2_DV_FL_REDUCED_FPS are set and reduce the fps by 1000/1001.
>> 
>>
>> If your hw can reliably detect the difference, then now is a good time to 
>> close
>> this gap in the DV_TIMINGS API.
> 
> Sounds nice :) Let me conduct more tests first and I will try to
> make the patch.

Nice!

Regards,

Hans

> 
> Best regards,
> Jose Miguel Abreu
> 
>>
>> Regards,
>>
>>  

Re: [PATCH] mtd: nand: use .read_oob() instead of .cmdfunc() for bad block check

[Boris Brezillon]

On Wed, 15 Mar 2017 09:55:13 +0900
Masahiro Yamada  wrote:

> Hi Boris,
> 
> Thanks for your review.
> 
> 2017-03-15 5:58 GMT+09:00 Boris Brezillon 
> :
> > On Wed, 15 Mar 2017 02:45:48 +0900
> > Masahiro Yamada  wrote:
> >  
> >> The nand_default_block_markbad() is the default implementation of
> >> chip->block_markbad().  This is called for marking a block as bad.
> >> It invokes nand_do_write_oob(), then calls a higher level accessor
> >> ecc->write_oob().
> >>
> >> On the other hand, when reading BBM from the OOB, chip->block_bad()
> >> is called, and nand_block_bad() is the default implementation.  This
> >> function calls a lower level chip->cmdfunc().  If a driver wants to
> >> re-use nand_block_bad(), it is required to support NAND_CMD_READOOB
> >> in its cmdfunc().  
> >
> > This is part of the basic/mandatory operations that should be supported
> > by all drivers.  
> 
> 
> My main motivation of this patch is to save NAND_CMD_READOOB
> implemenation in cmdfunc().
> 
> 
> Please look at line 1292 of drivers/mtd/nand/denali.c
> 
> case NAND_CMD_READOOB:
> /* TODO: Read OOB data */
> break;
> 

Yes, I know, and unfortunately that's not the only driver to partially
implement the set of operation the core assume to be always supported.

> 
> Currently, this driver can not check BBM at all.
> 
> 
> If all drivers should support NAND_CMD_READOOB
> regardless of this patch, my main motivation of this patch will be lost.

Well, I see another reason to move to the ecc->read_oob() approach:
some NAND controllers are protecting the BBM with ECC, if you just use
->cmdfunc(READOOB) + ->read_buf() you don't get this ECC protection.

> 
> 
> >> This is strange.  If the controller supports
> >> optimized read operation and the driver has its own ecc->read_oob(),
> >> it should be able to use it.  
> >
> > I agree with this one. I guess the idea behind this default
> > implementation was to avoid reading the whole OOB area, or maybe this
> > function was implemented before we had ECC support. Anyway, the
> > overhead should be negligible with your approach.
> >  
> >> Besides, NAND_CMD_READOOB (0x50) is
> >> not a real command for large page devices.  So, recent drivers may
> >> not be happy to handle this command.  
> >
> > Well, that's the whole problem with the ->cmdfunc() hook, even if it's
> > passed raw NAND command identifiers, these are actually encoding NAND
> > operations, and not necessarily the exact command that should be sent to
> > the NAND.  
> 
> 
> I was misunderstanding this.
> 
> If operations are hooked by higher level accessors
> and some low-level commands never get chance to be executed,
> I thought I need not implement them.

That's true for some of them (for example ->onfi_set/get_features()),
but there's no clear rule saying which commands have to be supported in
->cmdfunc() and which one can be implemented as high-level hooks.

Most of the time, I recommend to implement ->cmd_ctrl() and rely on the
default ->cmdfunc() implementation, so that, each time a new feature
(support for a new NAND operation) is added to the core your driver will
support it natively.

I know some controllers are not fitting so well in this model, but most
of them do.

> 
> > See what's done in nand_command_lp(), and how some commands are
> > actually generating a sequence of 2 commands [1], or how
> > NAND_CMD_READOOB is transformed into NAND_CMD_READ0 [2].  
> 
> So, what should I do for denali.c?
> 
> Maybe, copy the most logic of nand_command_lp() into denali_cmdfunc()?

Ideally, get rid of denali_cmdfunc() and implement denali_cmd_ctrl(),
but I'm not sure how feasible this is.

> 
> 
> 
> >>   if (chip->bbt_options & NAND_BBT_SCANLASTPAGE)
> >>   ofs += mtd->erasesize - mtd->writesize;
> >> @@ -364,30 +364,26 @@ static int nand_block_bad(struct mtd_info *mtd, 
> >> loff_t ofs)
> >>   page = (int)(ofs >> chip->page_shift) & chip->pagemask;
> >>
> >>   do {
> >> - if (chip->options & NAND_BUSWIDTH_16) {
> >> - chip->cmdfunc(mtd, NAND_CMD_READOOB,
> >> - chip->badblockpos & 0xFE, page);
> >> - bad = cpu_to_le16(chip->read_word(mtd));
> >> - if (chip->badblockpos & 0x1)
> >> - bad >>= 8;
> >> + res = chip->ecc.read_oob(mtd, chip, page);
> >> + if (!res) {
> >> + bad = chip->oob_poi[chip->badblockpos];  
> >
> > Hm, even if the current code is only testing one byte, I wonder
> > if we shouldn't test the 2 bytes here when we're dealing with 16bits
> > NANDs.  
> 
> 
> 
> I was not quite sure about this, so I tried my best
> to keep the current behavior.

I'll check in the ONFI spec.

> 
> 
> 
> >>
> >> - if (likely(chip->badblockbits == 8))
> >> - res = bad != 0xFF;
> >> - else
> >> - res = hweight8(bad) < 

Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

[Michal Hocko]

On Tue 14-03-17 20:35:21, Andrea Arcangeli wrote:
> Hello,
> 
> On Mon, Mar 13, 2017 at 10:21:45AM +0100, Michal Hocko wrote:
> > On Fri 10-03-17 13:00:37, Reza Arbab wrote:
> > > On Fri, Mar 10, 2017 at 04:53:33PM +0100, Michal Hocko wrote:
> > > >OK, so while I was playing with this setup some more I probably got why
> > > >this is done this way. All new memblocks are added to the zone Normal
> > > >where they are accounted as spanned but not present.
> > > 
> > > It's not always zone Normal. See zone_for_memory(). This leads to a
> > > workaround for having to do online_movable in descending block order.
> > > Instead of this:
> > > 
> > > 1. probe block 34, probe block 33, probe block 32, ...
> > > 2. online_movable 34, online_movable 33, online_movable 32, ...
> > > 
> > > you can online_movable the first block before adding the rest:
> > 
> > I do I enforce that behavior when the probe happens automagically?
> 
> What I provided as guide to online as movable in current and older
> kernels is:
> 
> 1) Remove udev rule
> 2) After adding memory with qemu/libvirt API run in the guest
> 
> --- workaround start 
> #!/bin/bash
> for i in `ls -d1 /sys/devices/system/memory/memory* | sort -nr -t y -k 5`; do 
> if [ "`cat $i/state`" == "offline" ]; then echo online_movable > $i/state ; 
> fi; done
> --- workaround end 
> 
> That's how bad is onlining as movable for memory hotunplug.

Yeah, this is really yucky. Fortunately, I already have a working prototype
which removes this restriction altogether.

> > > 1. probe block 32, online_movable 32
> > > 2. probe block 33, probe block 34, ...
> > >   - zone_for_memory() will cause these to start Movable
> > > 3. online 33, online 34, ...
> > >   - they're already in Movable, so online_movable is equivalentr
> > > 
> > > I agree with your general sentiment that this stuff is very nonintuitive.
> > 
> > My criterion for nonintuitive is probably different because I would call
> > this _completely_unusable_. Sorry for being so loud about this but the
> > more I look into this area the more WTF code I see. This has seen close
> > to zero review and seems to be building up more single usecase code on
> > top of previous. We need to change this, seriously!
> 
> It's not a bug, but when I found it I called it a "constraint" and
> when I debugged it (IIRC) it originated here:
> 
>   } else if (online_type == MMOP_ONLINE_MOVABLE) {
>   if (!zone_can_shift(pfn, nr_pages, ZONE_MOVABLE, _shift))
>   return -EINVAL;
>   }
> 
> Fixing it so you could online as movable even if it wasn't the last
> block was in my todo list but then we had other plans.
> 
> Unfortunately unless pfn+nr_pages of the newly created Movable zone
> matches the end of the normal zone (or whatever was there that has to
> be converted to Movable), it will fail onlining as movable.

Well, I think the main problem is that we associate pages added in the
first phase (probe) to the Normal zone. The everything else is just a
fallout and fiddling to make it work somehow.
 
[...]

> To be clear, I'm not necessarily against eventually removing
> _DEFFAULT_ONLINE, but an equally reliable and comparably fast
> alternative should be provided first and there's no such alternative
> right now.

As pointed in other reply that is not an intention here. I primarily
wanted to understand the scope of the problem. I believe this config
option was rushed into the kernel without considering other alternatives
which would make the hotplug more usable by others as well.
 
> If s390 has special issues requiring admin or a software hotplug
> manager app to enable blocks of memory by hand, the _DEFFAULT_ONLINE
> could be then an option selected or not selected by
> arch/*/Kconfig. The udev rule is still an automatic action so it's 1:1
> with the in-kernel feature. If the in-kernel automatic onlining is not
> workable on s390 I would assume the udev rule is also not workable.

But this is not about s390. It is about different usecases which require
different onlining policy and that is the main problem of the hardcoded
one in the kernel. See the other reply.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH 4/4] eeprom: at24: Add OF device ID table

[Wolfram Sang]

> So there isn't an agreement if is better to just rely in the current behavior
> (and have a superfluous I2C device ID table) or fix the I2C core (and need a
> OF device ID table).

For at24, the i2c_device_id table is not superfluous! It is used outside
the DT world as well.

> Indeed, but these all are compatible strings used by DTS in mainline and so
> should be in the OF device ID table in order to be matched and the proper
> modalias reported (once the I2C core is fixed).

I'd think we should fix the DTS files instead to contain a fallback we
agree on. Say, we agree on "atmel,at24c01" as a the generic fallback,
the DTS should contain:

compatible = ",", "atmel,at24c01"

And we shall only keep compatible values in the source file which differ
in behaviour fromt the generic case.

> One option is to add #ifdef CONFIG_OF guards for the OF device table 
> definition
> but again there's no agreement on that one since some maintainers say the it 
> is
> better to always build the OF ID table than having #ifdefery in C code...

I don't like the #ifdeffery as well.



signature.asc
Description: PGP signature

Re: [PATCH v6 0/4] Broadcom SBA RAID support

[Anup Patel]

On Tue, Mar 14, 2017 at 10:26 PM, Dan Williams  wrote:
> On Mon, Mar 6, 2017 at 1:43 AM, Anup Patel  wrote:
>> The Broadcom SBA RAID is a stream-based device which provides
>> RAID5/6 offload.
>>
>> It requires a SoC specific ring manager (such as Broadcom FlexRM
>> ring manager) to provide ring-based programming interface. Due to
>> this, the Broadcom SBA RAID driver (mailbox client) implements
>> DMA device having one DMA channel using a set of mailbox channels
>> provided by Broadcom SoC specific ring manager driver (mailbox
>> controller).
>>
>> The Broadcom SBA RAID hardware requires PQ disk position instead
>> of PQ disk coefficient. To address this, we have added raid_gflog
>> table which will help driver to convert PQ disk coefficient to PQ
>> disk position.
>>
>> This patchset is based on Linux-4.11-rc1 and depends on patchset
>> "[PATCH v5 0/2] Broadcom FlexRM ring manager support"
>>
>> It is also available at sba-raid-v6 branch of
>> https://github.com/Broadcom/arm64-linux.git
>>
> [..]
>>
>> Anup Patel (4):
>>   lib/raid6: Add log-of-2 table for RAID6 HW requiring disk position
>>   async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome()
>>   dmaengine: Add Broadcom SBA RAID driver
>>   dt-bindings: Add DT bindings document for Broadcom SBA RAID driver
>
> For the dmaengine and async_tx changes:
>
> Acked-by: Dan Williams 
>

Thanks Dan ...

Regards,
Anup

Re: [PATCH v6 0/4] Broadcom SBA RAID support

[Anup Patel]

On Wed, Mar 15, 2017 at 12:18 AM, Shaohua Li  wrote:
> On Tue, Mar 14, 2017 at 09:56:35AM -0700, Dan Williams wrote:
>> On Mon, Mar 6, 2017 at 1:43 AM, Anup Patel  wrote:
>> > The Broadcom SBA RAID is a stream-based device which provides
>> > RAID5/6 offload.
>> >
>> > It requires a SoC specific ring manager (such as Broadcom FlexRM
>> > ring manager) to provide ring-based programming interface. Due to
>> > this, the Broadcom SBA RAID driver (mailbox client) implements
>> > DMA device having one DMA channel using a set of mailbox channels
>> > provided by Broadcom SoC specific ring manager driver (mailbox
>> > controller).
>> >
>> > The Broadcom SBA RAID hardware requires PQ disk position instead
>> > of PQ disk coefficient. To address this, we have added raid_gflog
>> > table which will help driver to convert PQ disk coefficient to PQ
>> > disk position.
>> >
>> > This patchset is based on Linux-4.11-rc1 and depends on patchset
>> > "[PATCH v5 0/2] Broadcom FlexRM ring manager support"
>> >
>> > It is also available at sba-raid-v6 branch of
>> > https://github.com/Broadcom/arm64-linux.git
>> >
>> [..]
>> >
>> > Anup Patel (4):
>> >   lib/raid6: Add log-of-2 table for RAID6 HW requiring disk position
>> >   async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome()
>> >   dmaengine: Add Broadcom SBA RAID driver
>> >   dt-bindings: Add DT bindings document for Broadcom SBA RAID driver
>>
>> For the dmaengine and async_tx changes:
>>
>> Acked-by: Dan Williams 
>>
>> The raid change should get an ack from Shaohua.
>
> For the raid6 part:
>
> Acked-by: Shaohua Li 

Thanks Shaohua ...

Regards,
Anup

Re: [PATCH v2 16/23] MAINTAINERS: Add file patterns for powerpc device tree bindings

[Geert Uytterhoeven]

Hi Michael,

On Wed, Mar 15, 2017 at 1:19 AM, Michael Ellerman  wrote:
> Geert Uytterhoeven  writes:
>> Submitters of device tree binding documentation may forget to CC
>> the subsystem maintainer if this is missing.
>>
>> Signed-off-by: Geert Uytterhoeven 
>> Cc: Benjamin Herrenschmidt 
>> Cc: Paul Mackerras 
>> Cc: Michael Ellerman 
>> Cc: linuxppc-...@lists.ozlabs.org
>> ---
>> Please apply this patch directly if you want to be involved in device
>> tree binding documentation for your subsystem.
>>
>> v2:
>>   - Rebased on top of commit a42715830d552d7c ("MAINTAINERS: Remove
>> powerpc's "opal" pattern match), which just added "powerpc/opal",
>> while obviously the whole "powerpc" hierarchy is of interest.
>>
>> Impact on next-20170310:
>
> Actual diff ignoring ordering etc:
>
>  +Benjamin Herrenschmidt  (supporter:LINUX FOR 
> POWERPC (32-BIT AND 64-BIT))
>  +Paul Mackerras  (supporter:LINUX FOR POWERPC (32-BIT AND 
> 64-BIT))
>  +linuxppc-...@lists.ozlabs.org (open list:LINUX FOR POWERPC (32-BIT AND 
> 64-BIT))
>  -Scott Wood  (commit_signer:5/11=45%)
>  -Zhao Qiang  (commit_signer:4/11=36%,authored:4/11=36%)
>  -Christian Lamparter  (commit_signer:1/11=9%)
>  -yangbo lu  (authored:1/11=9%)
>  -"Otto Kekäläinen"  (authored:1/11=9%)
>  -Chris Packham  (authored:1/11=9%)
>  -York Sun  (authored:1/11=9%)
>
> Which looks bad as all the NXP folks get dropped, but they should be
> reading linuxppc-dev. So I think I'll merge this, unless anyone
> disagrees.

They got dropped because in the absence of a maintainer entry, the
last committers are listed. If they need to be listed, I can send patches to add
more specific entries for 4xx and fsl DT bindings, like:

diff --git a/MAINTAINERS b/MAINTAINERS
index 0f1c2f96c99aa936..40b392a4f399adbe 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5266,6 +5266,7 @@ M:Scott Wood 
 L: linuxppc-...@lists.ozlabs.org
 L: linux-arm-ker...@lists.infradead.org
 S: Maintained
+F: Documentation/devicetree/bindings/powerpc/fsl/
 F: drivers/soc/fsl/
 F: include/linux/fsl/

@@ -7540,6 +7541,7 @@ M:Matt Porter 
 W: http://www.penguinppc.org/
 L: linuxppc-...@lists.ozlabs.org
 S: Maintained
+F: Documentation/devicetree/bindings/powerpc/4xx/
 F: arch/powerpc/platforms/40x/
 F: arch/powerpc/platforms/44x/


OK?

Gr{oetje,eeting}s,

Geert

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

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

Re: [RESEND PATCH v3 2/2] phy: Group vendor specific phy drivers

[Heiko Stübner]

Am Dienstag, 14. März 2017, 11:52:50 CET schrieb Vivek Gautam:
> Adding vendor specific directories in phy to group
> phy drivers under their respective vendor umbrella.
> 
> Also updated the MAINTAINERS file to reflect the correct
> directory structure for phy drivers.
> 
> Signed-off-by: Vivek Gautam 
> Acked-by: Heiko Stuebner 
> Acked-by: Viresh Kumar 
> Cc: Kishon Vijay Abraham I 
> Cc: David S. Miller 
> Cc: Geert Uytterhoeven 
> Cc: Yoshihiro Shimoda 
> Cc: Guenter Roeck 
> Cc: Heiko Stuebner 
> Cc: Viresh Kumar 
> Cc: Maxime Ripard 
> Cc: Chen-Yu Tsai 
> Cc: Sylwester Nawrocki 
> Cc: Krzysztof Kozlowski 
> Cc: Jaehoon Chung 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-o...@vger.kernel.org
> Cc: linux-renesas-...@vger.kernel.org
> Cc: linux-rockc...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> ---
> 
> Corrected Krzysztof's email-id. Added linux-arm-msm.
> 
> Hi Heiko, Viresh,
> It's been a year since the last version of this patch was posted.
> Kishon has agreed to pull this change now. I am carrying forward
> your Acks since there are no functional changes.
> I have taken care of the drivers that were added/removed since
> the last version.
> Please feel free to jump in if you have any concerns.

still looks all good and I gave that a try on 4.11-rc2 yesterday as well.


Heiko

[v2 PATCH] powernv-cpuidle: Validate DT property array size

[Gautham R. Shenoy]

From: "Gautham R. Shenoy" 

The various properties associated with powernv idle states such as
names, flags, residency-ns, latencies-ns, psscr, psscr-mask are
exposed in the device-tree as property arrays such the pointwise
entries in each of these arrays correspond to the properties of the
same idle state.

This patch validates that the lengths of the property arrays are the
same. If there is a mismatch, the patch will ensure that we bail out
and not expose the platform idle states via cpuidle.

Signed-off-by: Gautham R. Shenoy 
---
v1: https://lkml.org/lkml/2017/2/23/349
Changes from v1: Print the full property array name in warning message.

 drivers/cpuidle/cpuidle-powernv.c | 64 +--
 1 file changed, 61 insertions(+), 3 deletions(-)

diff --git a/drivers/cpuidle/cpuidle-powernv.c 
b/drivers/cpuidle/cpuidle-powernv.c
index 3705930..a06df51 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -197,11 +197,25 @@ static inline void add_powernv_state(int index, const 
char *name,
stop_psscr_table[index].mask = psscr_mask;
 }
 
+/*
+ * Returns 0 if prop1_len == prop2_len. Else returns -1
+ */
+static inline int validate_dt_prop_sizes(const char *prop1, int prop1_len,
+const char *prop2, int prop2_len)
+{
+   if (prop1_len == prop2_len)
+   return 0;
+
+   pr_warn("cpuidle-powernv: array sizes don't match for %s and %s\n",
+   prop1, prop2);
+   return -1;
+}
+
 static int powernv_add_idle_states(void)
 {
struct device_node *power_mgt;
int nr_idle_states = 1; /* Snooze */
-   int dt_idle_states;
+   int dt_idle_states, count;
u32 latency_ns[CPUIDLE_STATE_MAX];
u32 residency_ns[CPUIDLE_STATE_MAX];
u32 flags[CPUIDLE_STATE_MAX];
@@ -226,6 +240,21 @@ static int powernv_add_idle_states(void)
goto out;
}
 
+   count = of_property_count_u32_elems(power_mgt,
+   "ibm,cpu-idle-state-latencies-ns");
+
+   if (validate_dt_prop_sizes("ibm,cpu-idle-state-flags", dt_idle_states,
+  "ibm,cpu-idle-state-latencies-ns",
+  count) != 0)
+   goto out;
+
+   count = of_property_count_strings(power_mgt,
+ "ibm,cpu-idle-state-names");
+   if (validate_dt_prop_sizes("ibm,cpu-idle-state-flags", dt_idle_states,
+  "ibm,cpu-idle-state-names",
+  count) != 0)
+   goto out;
+
/*
 * Since snooze is used as first idle state, max idle states allowed is
 * CPUIDLE_STATE_MAX -1
@@ -260,6 +289,22 @@ static int powernv_add_idle_states(void)
has_stop_states = (flags[0] &
   (OPAL_PM_STOP_INST_FAST | OPAL_PM_STOP_INST_DEEP));
if (has_stop_states) {
+   count = of_property_count_u64_elems(power_mgt,
+   "ibm,cpu-idle-state-psscr");
+   if (validate_dt_prop_sizes("ibm,cpu-idle-state-flags",
+  dt_idle_states,
+  "ibm,cpu-idle-state-psscr",
+  count) != 0)
+   goto out;
+
+   count = of_property_count_u64_elems(power_mgt,
+   
"ibm,cpu-idle-state-psscr-mask");
+   if (validate_dt_prop_sizes("ibm,cpu-idle-state-flags",
+  dt_idle_states,
+  "ibm,cpu-idle-state-psscr-mask",
+  count) != 0)
+   goto out;
+
if (of_property_read_u64_array(power_mgt,
"ibm,cpu-idle-state-psscr", psscr_val, dt_idle_states)) {
pr_warn("cpuidle-powernv: missing 
ibm,cpu-idle-state-psscr in DT\n");
@@ -274,8 +319,21 @@ static int powernv_add_idle_states(void)
}
}
 
-   rc = of_property_read_u32_array(power_mgt,
-   "ibm,cpu-idle-state-residency-ns", residency_ns, 
dt_idle_states);
+   count = of_property_count_u32_elems(power_mgt,
+   "ibm,cpu-idle-state-residency-ns");
+
+   if (count < 0) {
+   rc = count;
+   } else if (validate_dt_prop_sizes("ibm,cpu-idle-state-flags",
+ dt_idle_states,
+ "ibm,cpu-idle-state-residency-ns",
+ count) != 0) {
+   goto out;
+   } else {
+   rc = of_property_read_u32_array(power_mgt,
+   
"ibm,cpu-idle-state-residency-ns",
+ 

Re: [PATCH v3 0/7] mmc: bcm2835: Add new driver for the sdhost controller

[Gerd Hoffmann]

  Hi,

> First the flipping of the mmc host driver for the SD card slot will
> cause issues for users that build it as a module. When I tested this
> on Fedora the first update I ended up with a system that didn't boot.

Yep, switching drivers is a pain point here indeed.

Possibly we could fix that by adding a MODULE_SOFTDEP() to the iproc
driver?  Comments?  Better ideas?

> Also i often see the device hang for a long period when systemd probes
> for rfkill status, sometimes it needs to be reset but it generally
> gets there.

What device is that?  rpi3 with wifi?

> [6.529079] Hardware name: Generic DT based system
> [6.529106] [] (unwind_backtrace) from []
> (show_stack+0x18/0x1c)
> [6.529122] [] (show_stack) from []
> (dump_stack+0x80/0xa0)
> [6.529137] [] (dump_stack) from [] (__warn+0xe4/0x104)
> [6.529150] [] (__warn) from []
> (warn_slowpath_fmt+0x3c/0x4c)
> [6.529166] [] (warn_slowpath_fmt) from []
> (check_flush_dependency+0xac/0x134)
> [6.529184] [] (check_flush_dependency) from []
> (flush_work+0xa0/0x178)
> [6.529201] [] (flush_work) from []
> (drain_all_pages+0x1a8/0x1cc)
> [6.529221] [] (drain_all_pages) from []
> (start_isolate_page_range+0x168/0x1b4)
> [6.529239] [] (start_isolate_page_range) from
> [] (alloc_contig_range+0xd4/0x314)
> [6.529258] [] (alloc_contig_range) from []
> (cma_alloc+0x188/0x300)
> [6.529275] [] (cma_alloc) from []
> (__alloc_from_contiguous+0x40/0xd8)
> [6.529290] [] (__alloc_from_contiguous) from
> [] (cma_allocator_alloc+0x3c/0x44)
> [6.529303] [] (cma_allocator_alloc) from []
> (__dma_alloc+0x1d4/0x2f0)
> [6.529317] [] (__dma_alloc) from []
> (arm_dma_alloc+0x3c/0x48)
> [6.529331] [] (arm_dma_alloc) from []
> (dma_pool_alloc+0x124/0x240)
> [6.529356] [] (dma_pool_alloc) from []
> (bcm2835_dma_create_cb_chain+0xb0/0x1dc [bcm2835_dma])
> [6.529385] [] (bcm2835_dma_create_cb_chain
> [bcm2835_dma]) from [] (bcm2835_dma_prep_slave_sg+0xf0/0x25c
> [bcm2835_dma])
> [6.529418] [] (bcm2835_dma_prep_slave_sg [bcm2835_dma])
> from [] (bcm2835_request+0x2a4/0x3f4 [bcm2835])
> [6.529548] [] (bcm2835_request [bcm2835]) from
> [] (mmc_start_request+0x1f8/0x264 [mmc_core])
> [6.529756] [] (mmc_start_request [mmc_core]) from
> [] (mmc_start_areq+0x2c8/0x318 [mmc_core])
> [6.529890] [] (mmc_start_areq [mmc_core]) from
> [] (mmc_blk_issue_rw_rq+0xc0/0x308 [mmc_block])
> [6.529943] [] (mmc_blk_issue_rw_rq [mmc_block]) from
> [] (mmc_blk_issue_rq+0x418/0x428 [mmc_block])
> [6.529997] [] (mmc_blk_issue_rq [mmc_block]) from
> [] (mmc_queue_thread+0x148/0x1bc [mmc_block])
> [6.530031] [] (mmc_queue_thread [mmc_block]) from
> [] (kthread+0x120/0x138)
> [6.530049] [] (kthread) from []
> (ret_from_fork+0x14/0x3c)
> [6.530055] ---[ end trace 221a5a14ca55fa22 ]---
> [6.545765]  mmcblk0: p1 p2 p3 p4
> [6.566015] random: fast init done
> [6.623699] mmc1: new high speed SDIO card at address 0001

Looks more like a cma allocator issue on a quick glance.

cheers,
  Gerd

RE: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access

[Zhou, David(ChunMing)]

Does that means we don't need invisible vram later?

David

-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Christian K?nig
Sent: Wednesday, March 15, 2017 3:38 PM
To: Ayyappa Ch 
Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; 
amd-...@lists.freedesktop.org; platform-driver-...@vger.kernel.org; 
helg...@kernel.org; dri-de...@lists.freedesktop.org
Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access

Carizzo is an APU and resizing BARs isn't needed nor supported there. 
The CPU can access the full stolen VRAM directly on that hardware.

As far as I know ASICs with support for this are Tonga, Fiji and all Polaris 
variants.

Christian.

Am 15.03.2017 um 08:23 schrieb Ayyappa Ch:
> Is it possible on Carrizo asics? Or only supports on newer asics?
>
> On Mon, Mar 13, 2017 at 6:11 PM, Christian König 
>  wrote:
>> From: Christian König 
>>
>> Try to resize BAR0 to let CPU access all of VRAM.
>>
>> Signed-off-by: Christian König 
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu.h|  1 +
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29 
>> +
>>   drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  |  8 +---
>>   drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |  8 +---
>>   4 files changed, 40 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> index 3b81ded..905ded9 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> @@ -1719,6 +1719,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device 
>> *adev, struct ttm_tt *ttm,
>>   struct ttm_mem_reg *mem);
>>   void amdgpu_vram_location(struct amdgpu_device *adev, struct amdgpu_mc 
>> *mc, u64 base);
>>   void amdgpu_gtt_location(struct amdgpu_device *adev, struct 
>> amdgpu_mc *mc);
>> +void amdgpu_resize_bar0(struct amdgpu_device *adev);
>>   void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64 size);
>>   int amdgpu_ttm_init(struct amdgpu_device *adev);
>>   void amdgpu_ttm_fini(struct amdgpu_device *adev); diff --git 
>> a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> index 118f4e6..92955fe 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> @@ -692,6 +692,35 @@ void amdgpu_gtt_location(struct amdgpu_device *adev, 
>> struct amdgpu_mc *mc)
>>  mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
>>   }
>>
>> +/**
>> + * amdgpu_resize_bar0 - try to resize BAR0
>> + *
>> + * @adev: amdgpu_device pointer
>> + *
>> + * Try to resize BAR0 to make all VRAM CPU accessible.
>> + */
>> +void amdgpu_resize_bar0(struct amdgpu_device *adev) {
>> +   u32 size = max(ilog2(adev->mc.real_vram_size - 1) + 1, 20) - 20;
>> +   int r;
>> +
>> +   r = pci_resize_resource(adev->pdev, 0, size);
>> +
>> +   if (r == -ENOTSUPP) {
>> +   /* The hardware don't support the extension. */
>> +   return;
>> +
>> +   } else if (r == -ENOSPC) {
>> +   DRM_INFO("Not enoigh PCI address space for a large BAR.");
>> +   } else if (r) {
>> +   DRM_ERROR("Problem resizing BAR0 (%d).", r);
>> +   }
>> +
>> +   /* Reinit the doorbell mapping, it is most likely moved as well */
>> +   amdgpu_doorbell_fini(adev);
>> +   BUG_ON(amdgpu_doorbell_init(adev));
>> +}
>> +
>>   /*
>>* GPU helpers function.
>>*/
>> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c 
>> b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>> index dc9b6d6..36a7aa5 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>> @@ -367,13 +367,15 @@ static int gmc_v7_0_mc_init(struct amdgpu_device *adev)
>>  break;
>>  }
>>  adev->mc.vram_width = numchan * chansize;
>> -   /* Could aper size report 0 ? */
>> -   adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
>> -   adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
>>  /* size in MB on si */
>>  adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 
>> 1024ULL;
>>  adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL 
>> * 1024ULL;
>>
>> +   if (!(adev->flags & AMD_IS_APU))
>> +   amdgpu_resize_bar0(adev);
>> +   adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
>> +   adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
>> +
>>   #ifdef CONFIG_X86_64
>>  if (adev->flags & AMD_IS_APU) {
>>  adev->mc.aper_base = 
>> ((u64)RREG32(mmMC_VM_FB_OFFSET)) << 22; diff --git 
>> a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c 
>> b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
>> index c087b00..7761ad3 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
>> @@ -459,13 +459,15 

Re: [PATCH] tpm: select CONFIG_CRYPTO

[Jarkko Sakkinen]

Arnd,

On Tue, Mar 14, 2017 at 10:40:24PM +0100, Arnd Bergmann wrote:
> As we need the CRYPTO_HASH_INFO implementation, we should also
> select CRYPTO itself to avoid this build warning:
> 
> warning: (TCG_TPM && TRUSTED_KEYS && IMA) selects CRYPTO_HASH_INFO which has 
> unmet direct dependencies (CRYPTO)
> 
> Fixes: c1f92b4b04ad ("tpm: enhance TPM 2.0 PCR extend to support multiple 
> banks")
> Signed-off-by: Arnd Bergmann 

I've already merged this and put to my next branch.

/Jarkko

> ---
>  drivers/char/tpm/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
> index af985cca413c..d520ac51c11c 100644
> --- a/drivers/char/tpm/Kconfig
> +++ b/drivers/char/tpm/Kconfig
> @@ -6,6 +6,7 @@ menuconfig TCG_TPM
>   tristate "TPM Hardware Support"
>   depends on HAS_IOMEM
>   select SECURITYFS
> + select CRYPTO
>   select CRYPTO_HASH_INFO
>   ---help---
> If you have a TPM security chip in your system, which
> -- 
> 2.9.0
> 

Re: [PATCH v2] xfs: remove kmem_zalloc_greedy

[Michal Hocko]

On Wed 15-03-17 01:14:27, Luis R. Rodriguez wrote:
> On Tue, Mar 14, 2017 at 11:07:38AM -0700, Darrick J. Wong wrote:
> > On Tue, Mar 14, 2017 at 05:57:45PM +0100, Luis R. Rodriguez wrote:
> > > On Tue, Mar 07, 2017 at 04:35:28PM -0800, Darrick J. Wong wrote:
> > > > The sole remaining caller of kmem_zalloc_greedy is bulkstat, which uses
> > > > it to grab 1-4 pages for staging of inobt records.  The infinite loop in
> > > > the greedy allocation function is causing hangs[1] in generic/269, so
> > > > just get rid of the greedy allocator in favor of kmem_zalloc_large.
> > > > This makes bulkstat somewhat more likely to ENOMEM if there's really no
> > > > pages to spare, but eliminates a source of hangs.
> > > > 
> > > > [1] 
> > > > http://lkml.kernel.org/r/20170301044634.rgidgdqqiiwsmfpj%40XZHOUW.usersys.redhat.com
> > > > 
> > > > Signed-off-by: Darrick J. Wong 
> > > > ---
> > > > v2: remove single-page fallback
> > > > ---
> > > 
> > > Since this fixes a hang how about *at the very least* a respective Fixes 
> > > tag ?
> > > This fixes an existing hang so what are the stable considerations here ? I
> > > realize the answer is not easy but figured its worth asking.
> > 
> > I didn't think it was appropriate to "Fixes: 77e4635ae1917" since we're
> > not fixing _greedy so much as we are killing it.  The patch fixes an
> > infinite retry hang when bulkstat tries a memory allocation that cannot
> > be satisfied; and having done that, realizes there are no remaining
> > callers of _greedy and garbage collects it.  The code that was there
> > before also seems capable of sleeping forever, I think.
> > 
> > So the minimally invasive fix is to apply the allocation conversion in
> > bulkstat, and if there aren't any other callers of _greedy then you can
> > get rid of it too.
> 
> For the stake of stable XFS users then why not do the less invasive change
> first, Cc stable, and then move on to the less backward portable solution ?

The thing is that the permanent failures for vmalloc were so unlikely
prior to 5d17a73a2ebe ("vmalloc: back off when the current task is
killed") that this was basically a non-issue before this (4.11) merge
window.
-- 
Michal Hocko
SUSE Labs

Re: [...] "How does the new naming scheme look like, precisely?"

[poma]

On 14.03.2017 17:16, Tom Horsley wrote:
> And the consistent names change every single time some
> developer decides he just has to rewrite the algorithm
> to make it better, or systemd decides to engluph yet
> another component and not be backward compatible, or
> a kernel developer gets a new motherboard where the
> scheme doesn't work and his fix has the side effect
> of changing the names on thousands of existing systems, etc.
> 
> There have been at least 3 different "immutable" name
> schemes in the short time the whole concept has existed.
> 
> I finally decided to eradicate it and go back to eth0
> and friends because it was infinitely more reliable than
> having to discover yet another naming scheme in every damn
> release.
> 
> Now my only problem will be that they'll probably keep changing
> the name of the kernel option to disable it :-).
> 

This sounds quite disturbing,
can someone from the systemd and kernel campus comment here,
as Tom claims, whether these are the facts?

Re: [PATCH] drivers/staging/goldfish/goldfish_nand.c: Fixed Coding style Warnings.

[Dan Carpenter]

Fix the subject.  The subsystem prefix is wrong and it's too vague.
Change it to:

[PATCH] Staging: goldfish: use __func__ instead of embedded function names


On Tue, Mar 14, 2017 at 08:53:50PM -0700, mshan wrote:
> Embedded function names are less appropriate to use when
> refactoring, can cause function renaming.  Prefer the use
> of "%s", __func__ to embedded function names
> 
> Signed-off-by: mshan 

Please use your legal/formal name as if you were signing a legal
document.  Also change the From header on your email to match.

regards,
dan carpenter

Re: [PATCH] s390/decompressor: fix initrd corruption caused by bss clear

[Heiko Carstens]

On Mon, Mar 13, 2017 at 12:14:58PM -0300, Marcelo Henrique Cerri wrote:
> Reorder the operations in decompress_kernel() to ensure initrd is moved
> to a safe location before the bss section is zeroed.
> 
> During decompression bss can overlap with the initrd and this can
> corrupt the initrd contents depending on the size of the compressed
> kernel (which affects where the initrd is placed by the bootloader) and
> the size of the bss section of the decompressor.
> 
> Also use the correct initrd size when checking for overlaps with
> parmblock.
> 
> Fixes: 06c0dd72aea3 ([S390] fix boot failures with compressed kernels)
> Cc: sta...@vger.kernel.org
> Reviewed-by: Joy Latten 
> Reviewed-by: Vineetha HariPai 
> Signed-off-by: Marcelo Henrique Cerri 
> ---
>  arch/s390/boot/compressed/misc.c | 35 +++
>  1 file changed, 19 insertions(+), 16 deletions(-)

Applied. Thank you!

[PATCH 3/3] drm/rockchip/dsi: correct the grf_switch_reg name

[Chris Zhong]

For the RK3399, the grf_switch_reg name should be RK3399_GRF_SOC_CON20,
not RK3399_GRF_SOC_CON19.

Signed-off-by: Chris Zhong 
---

 drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index d8f24f2..ddd5dba 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -34,7 +34,7 @@
 #define RK3288_DSI0_SEL_VOP_LITBIT(6)
 #define RK3288_DSI1_SEL_VOP_LITBIT(9)
 
-#define RK3399_GRF_SOC_CON19   0x6250
+#define RK3399_GRF_SOC_CON20   0x6250
 #define RK3399_DSI0_SEL_VOP_LITBIT(0)
 #define RK3399_DSI1_SEL_VOP_LITBIT(4)
 
@@ -1146,7 +1146,7 @@ static struct dw_mipi_dsi_plat_data 
rk3288_mipi_dsi_drv_data = {
 static struct dw_mipi_dsi_plat_data rk3399_mipi_dsi_drv_data = {
.dsi0_en_bit = RK3399_DSI0_SEL_VOP_LIT,
.dsi1_en_bit = RK3399_DSI1_SEL_VOP_LIT,
-   .grf_switch_reg = RK3399_GRF_SOC_CON19,
+   .grf_switch_reg = RK3399_GRF_SOC_CON20,
.grf_dsi0_mode = RK3399_GRF_DSI_MODE,
.grf_dsi0_mode_reg = RK3399_GRF_SOC_CON22,
.max_data_lanes = 4,
-- 
2.6.3

[PATCH 2/3] drm/rockchip/dsi: enable the grf clk before writing grf registers

[Chris Zhong]

For RK3399, the grf clk should be enabled before writing grf registers,
otherwise the register value can not be changed.

Signed-off-by: Chris Zhong 
---

 drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index f84f9ae..d8f24f2 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -291,6 +291,7 @@ struct dw_mipi_dsi {
struct regmap *grf_regmap;
void __iomem *base;
 
+   struct clk *grf_clk;
struct clk *pllref_clk;
struct clk *pclk;
struct clk *phy_cfg_clk;
@@ -979,6 +980,16 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder 
*encoder)
dw_mipi_dsi_dphy_interface_config(dsi);
dw_mipi_dsi_clear_err(dsi);
 
+   /*
+* For the RK3399, the clk of grf must be enabled before writing grf
+* register.
+*/
+   ret = clk_prepare_enable(dsi->grf_clk);
+   if (ret) {
+   dev_err(dsi->dev, "Failed to enable grf_clk\n");
+   return;
+   }
+
if (pdata->grf_dsi0_mode_reg)
regmap_write(dsi->grf_regmap, pdata->grf_dsi0_mode_reg,
 pdata->grf_dsi0_mode);
@@ -1003,6 +1014,8 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder 
*encoder)
regmap_write(dsi->grf_regmap, pdata->grf_switch_reg, val);
dev_dbg(dsi->dev, "vop %s output to dsi0\n", (mux) ? "LIT" : "BIG");
dsi->dpms_mode = DRM_MODE_DPMS_ON;
+
+   clk_disable_unprepare(dsi->grf_clk);
 }
 
 static int
@@ -1238,6 +1251,17 @@ static int dw_mipi_dsi_bind(struct device *dev, struct 
device *master,
dev_dbg(dev, "have not phy_cfg_clk\n");
}
 
+   dsi->grf_clk = devm_clk_get(dev, "grf");
+   if (IS_ERR(dsi->grf_clk)) {
+   ret = PTR_ERR(dsi->grf_clk);
+   if (ret != -ENOENT) {
+   dev_err(dev, "Unable to get grf_clk: %d\n", ret);
+   return ret;
+   }
+   dsi->grf_clk = NULL;
+   dev_dbg(dev, "have not grf_clk\n");
+   }
+
ret = clk_prepare_enable(dsi->pllref_clk);
if (ret) {
dev_err(dev, "%s: Failed to enable pllref_clk\n", __func__);
-- 
2.6.3

[PATCH 1/3] dt-bindings: add the grf clock for dw-mipi-dsi

[Chris Zhong]

For RK3399, the grf clock should be controlled by dw-mipi-dsi driver,
add the description for this clock.

Signed-off-by: Chris Zhong 
---

 .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
index 188f6f7..7e17a60 100644
--- 
a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
+++ 
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
@@ -10,7 +10,7 @@ Required properties:
 - interrupts: Represent the controller's interrupt to the CPU(s).
 - clocks, clock-names: Phandles to the controller's pll reference
   clock(ref) and APB clock(pclk). For RK3399, a phy config clock
-  (phy_cfg) is additional required. As described in [1].
+  (phy_cfg) and a grf clock(grf) are additional required. As described in [1].
 - rockchip,grf: this soc should set GRF regs to mux vopl/vopb.
 - ports: contain a port node with endpoint definitions as defined in [2].
   For vopb,set the reg = <0> and set the reg = <1> for vopl.
-- 
2.6.3

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

[Marko Rauhamaa]

Filip Štědronský :

> there are basically two classes of uses for a fantotify-like
> interface:
>
> (1) Keeping an up-to-date representation of the file system. For this,
> superblock watches are clearly what you want.
>
> [...]
>
> All those factors speak greatly in favour of superblock
> watches.
>
> (2) Tracking filesystem *activity*. Now you are not building
> an image of current filesystem state but rather a log of what
> happened. Perhaps you are also interested in who
> (user/process/...) did what. Permission events also fit mostly in
> this category.
>
> For those it *might* make sense to have mount-scoped watches, for
> example if you want to monitor only one container or a subset of
> processes.
>
> We both concentrate on the first but we shouldn't forget about the
> second, which was one of the original motivations for fanotify.

My (employer's) needs are centered around (2). We definitely crave
permission events with a filesystem scope. At the moment, you can avoid
permission checks with a simple unshare command (https://lkml.org/lkml/2016/12/21/144>).

So I must be able to see everything that is happening in my universe. It
might also be useful to monitor a subuniverse of mine, but the former
need is critical at the moment.

As for "who (user/process/...) did what", the fanotify API is flawed in
that we don't have a CLOSE_WRITE_PERM event. The hit-and-run process is
long gone by the time we receive the event. That's more of a rule than
an exception.


Marko

[PATCH 1/2] mmc: core: guard dereference of optional parameter

[Tobin C. Harding]

Various functions take as parameter an optional pointer. Pointer
should be guarded with non-NULL check before dereferencing.

Add non-NULL check before dereference of pointer.

Signed-off-by: Tobin C. Harding 
---
 drivers/mmc/core/sdio_io.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/core/sdio_io.c b/drivers/mmc/core/sdio_io.c
index 74195d7..3482314 100644
--- a/drivers/mmc/core/sdio_io.c
+++ b/drivers/mmc/core/sdio_io.c
@@ -373,7 +373,8 @@ u8 sdio_readb(struct sdio_func *func, unsigned int addr, 
int *err_ret)
u8 val;
 
if (!func) {
-   *err_ret = -EINVAL;
+   if (err_ret)
+   *err_ret = -EINVAL;
return 0xFF;
}
 
@@ -407,7 +408,8 @@ void sdio_writeb(struct sdio_func *func, u8 b, unsigned int 
addr, int *err_ret)
int ret;
 
if (!func) {
-   *err_ret = -EINVAL;
+   if (err_ret)
+   *err_ret = -EINVAL;
return;
}
 
@@ -635,7 +637,8 @@ unsigned char sdio_f0_readb(struct sdio_func *func, 
unsigned int addr,
unsigned char val;
 
if (!func) {
-   *err_ret = -EINVAL;
+   if (err_ret)
+   *err_ret = -EINVAL;
return 0xFF;
}
 
@@ -673,7 +676,8 @@ void sdio_f0_writeb(struct sdio_func *func, unsigned char 
b, unsigned int addr,
int ret;
 
if (!func) {
-   *err_ret = -EINVAL;
+   if (err_ret)
+   *err_ret = -EINVAL;
return;
}
 
-- 
2.7.4

[PATCH 0/2] mmc: core: null pointer dereference bug

[Tobin C. Harding]

Various functions take as parameter an optional pointer. Pointer
should be guarded with non-NULL check before dereferencing.

While fixing this bug it was found that the file contains multiple
functions doing variations on the same thing, sdio_readb(),
sdio_writeb(), sdio_readw(), sdio_writew() etc. Although the functions
have very similar logic the code is laid out in a variety of
ways. This makes it overly complicated to read. There is a already a
nice clean chunk of code, if we use this format for all instances then
we will have cleaned up the code, reduced the line count and lessened
the cognitive load required while reading.

Patch 01 adds non-NULL check before dereference of pointer.

Patch 02 cleans up the return code to be simple and uniform.

Code has not been tested. sdio_io.c with patches applied has been
checked with checkpatch, Sparse, and Smatch. Each patch has been
applied and built on x86_64 and PowerPC

Tobin C. Harding (2):
  mmc: core: guard dereference of optional parameter
  mmc: core: simplify return code

 drivers/mmc/core/sdio_io.c | 54 ++
 1 file changed, 21 insertions(+), 33 deletions(-)

-- 
2.7.4

[PATCH 2/2] mmc: core: simplify return code

[Tobin C. Harding]

File contains multiple functions doing variations on the same thing,
sdio_readb(), sdio_writeb()f, sdio_readw(), sdio_writew()
etc. Although the functions have very similar logic the code is laid
out in a variety of ways. This makes it overly complicated to
read. There is a already a nice clean chunk of code, if we use this
format for all instances then we will have cleaned up the code,
reduced the line count and lessened the cognitive load required while
reading. Less lines equals less bugs.

Pick the most simple and clear code flow and change all functions to
be the same.

Signed-off-by: Tobin C. Harding 
---
 drivers/mmc/core/sdio_io.c | 42 +-
 1 file changed, 13 insertions(+), 29 deletions(-)

diff --git a/drivers/mmc/core/sdio_io.c b/drivers/mmc/core/sdio_io.c
index 3482314..d40744b 100644
--- a/drivers/mmc/core/sdio_io.c
+++ b/drivers/mmc/core/sdio_io.c
@@ -378,15 +378,11 @@ u8 sdio_readb(struct sdio_func *func, unsigned int addr, 
int *err_ret)
return 0xFF;
}
 
-   if (err_ret)
-   *err_ret = 0;
-
ret = mmc_io_rw_direct(func->card, 0, func->num, addr, 0, );
-   if (ret) {
-   if (err_ret)
-   *err_ret = ret;
+   if (err_ret)
+   *err_ret = ret;
+   if (ret)
return 0xFF;
-   }
 
return val;
 }
@@ -443,7 +439,7 @@ u8 sdio_writeb_readb(struct sdio_func *func, u8 write_byte,
if (err_ret)
*err_ret = ret;
if (ret)
-   val = 0xff;
+   return 0xff;
 
return val;
 }
@@ -531,15 +527,11 @@ u16 sdio_readw(struct sdio_func *func, unsigned int addr, 
int *err_ret)
 {
int ret;
 
-   if (err_ret)
-   *err_ret = 0;
-
ret = sdio_memcpy_fromio(func, func->tmpbuf, addr, 2);
-   if (ret) {
-   if (err_ret)
-   *err_ret = ret;
+   if (err_ret)
+   *err_ret = ret;
+   if (ret)
return 0x;
-   }
 
return le16_to_cpup((__le16 *)func->tmpbuf);
 }
@@ -583,15 +575,11 @@ u32 sdio_readl(struct sdio_func *func, unsigned int addr, 
int *err_ret)
 {
int ret;
 
-   if (err_ret)
-   *err_ret = 0;
-
ret = sdio_memcpy_fromio(func, func->tmpbuf, addr, 4);
-   if (ret) {
-   if (err_ret)
-   *err_ret = ret;
+   if (err_ret)
+   *err_ret = ret;
+   if (ret)
return 0x;
-   }
 
return le32_to_cpup((__le32 *)func->tmpbuf);
 }
@@ -642,15 +630,11 @@ unsigned char sdio_f0_readb(struct sdio_func *func, 
unsigned int addr,
return 0xFF;
}
 
-   if (err_ret)
-   *err_ret = 0;
-
ret = mmc_io_rw_direct(func->card, 0, 0, addr, 0, );
-   if (ret) {
-   if (err_ret)
-   *err_ret = ret;
+   if (err_ret)
+   *err_ret = ret;
+   if (ret)
return 0xFF;
-   }
 
return val;
 }
-- 
2.7.4

RE: [PATCH v2 net-next 4/5] sunvnet: count multicast packets

[David Laight]

From: Shannon Nelson
> Sent: 14 March 2017 17:25
...
> + if (unlikely(is_multicast_ether_addr(eth_hdr(skb)->h_dest)))
> + dev->stats.multicast++;

I'd guess that:
dev->stats.multicast += is_multicast_ether_addr(eth_hdr(skb)->h_dest);
generates faster code.
Especially if is_multicast_ether_addr(x) is (*x >> 7).

David

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Jon Hunter]

On 13/03/17 14:42, Ulf Hansson wrote:
> On 13 March 2017 at 15:09, Jon Hunter  wrote:
>> Hi Ulf,
>>
>> On 13/03/17 11:45, Ulf Hansson wrote:
>>> +Björn
>>>
>>> On 13 March 2017 at 10:37, Jon Hunter  wrote:
 Hi Rafael, Kevin, Ulf,

 Looks like there is still some interest/needs in/for this. Any thoughts
 on how we can move this forward?
>>>
>>> At the Linaro Connect last week, I was talking to Björn, Rajendra and
>>> Stephen more about these related issues.
>>>
>>> It definitely seems like we need to progress with this somehow,
>>> meaning we need a solution for being able to associate a device with
>>> more than one PM domain. In that context, I don't think genpd based on
>>> its current design, is a good fit to solve the problem.
>>>
>>> Instead I think we need something entirely new (perhaps some code can
>>> be borrowed from genpd), which is more similar to the clock/regulator
>>> framework. In other words, what you also were suggesting in a earlier
>>> reply.
>>> In this way, the driver/subsystem gains full flexibility of managing
>>> its device's PM domains, which seems like the best future-proof
>>> solution.
>>
>> I agree, I think that that would give us the most flexibility to handle
>> whatever scenario. However, I was thinking that we could still use the
>> genpd core to register pm-domains with and control. My thought was to
>> allow devices to have a bindings with multiple pm-domains ...
>>
>> dev-xyz {
>> ...
>> power-domains = <>, <>;
>> };
> 
> This could work. However, let's involve DT maintainers to make sure we
> get their input to this. Perhaps they prefer a different approach.

No problem. I should point out the above is for the #power-domain-cells
= <0> case.

>>
>> Then in the genpd core we do having something like ...
>>
>> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
>> index e697dec9d25b..d1ae6ddf4903 100644
>> --- a/drivers/base/power/domain.c
>> +++ b/drivers/base/power/domain.c
>> @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev)
>> "samsung,power-domain", 0);
>> if (!pd_args.np)
>> return -ENOENT;
>> +   } else if (ret > 1) {
>> +   /*
>> +* If there are more than one PM domain defined for a device,
>> +* then these need to be manually controlled by the device
>> +* driver because the genpd core cannot bind a device with
>> +* more than one PM domain.
>> +*/
>> +   dev_dbg(dev, "cannot add PM domains, %d detected!\n", ret);
>> +   return 0;
>> }
>>
>> Then add some new public APIs for getting and controlling the pm-domains ...
>>
>> struct generic_pm_domain *pm_genpd_get(struct device *dev, char *name);
>> - Use 'dev->of_node' to look-up pm-domain if populated, else uses name.
>>
>> struct generic_pm_domain *of_pm_genpd_get(struct device *dev, int index);
>> void pm_genpd_put(struct generic_pm_domain *pd);
>> int pm_genpd_power_on(struct generic_pm_domain *pd);
>> int pm_genpd_power_off(struct generic_pm_domain *pd);
>> - Power on/off APIs would be synchronous types
>>
>> Are there any potential pitfalls of the above?
> 
> So if I understand correctly, you would like to extend genpd with some
> new APIs. It's worth a try, however my main worries are these:
> 
> 1) These new API must not be allowed to be abused.
> I have seen that before as when people try to handle some corner
> cases, I don't want to that to happen again. To avoid that, perhaps we
> should continue the re-structuring and thus move structures/datas that
> are currently public, to be internal to genpd. To get a clean
> interface.

OK, fair enough. Any in particular you are concerned about?

> 2) I wouldn't be surprised if we run into some tricky corner cases, as
> we get a mixture of devices handled by runtime PM and in some other
> cases via new APIs. Perhaps that can be sorted out!?

Right that is a concern, however, I think that in the long-term we would
be better off with the power-domains being controlled by the same
underlying code as opposed to something different.

Cheers
Jon

-- 
nvpublic

[PATCH v2 1/5] mm: add tlb_flush_mmu_free_batches

[Aaron Lu]

There are two places doing page free related to struct mmu_gather_batch:
1 in tlb_flush_mmu_free, where pages gathered in mmu_gather_batch list
  are freed;
2 in tlb_flush_mmu_finish, where pages for the mmu_gather_batch
  structure(let's call it the batch page) are freed.

There will be yet another place in the parallel free worker thread
introduced in the following patch to free both the pages pointed to by
the mmu_gather_batch list and the batch pages themselves. To avoid code
duplication, add a new function named tlb_flush_mmu_free_batches for
this purpose.

Another reason to add this function is that after the following patch,
cond_resched will need to be added at places where more than 10K pages
can be freed, i.e. in tlb_flush_mmu_free and the worker function.
Instead of adding cond_resched at multiple places, using a single
function to reduce code duplication.

There should be no functionality change.

Signed-off-by: Aaron Lu 
---
 mm/memory.c | 28 +---
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/mm/memory.c b/mm/memory.c
index 14fc0b40f0bb..cdb2a53f251f 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -250,14 +250,25 @@ static void tlb_flush_mmu_tlbonly(struct mmu_gather *tlb)
__tlb_reset_range(tlb);
 }
 
-static void tlb_flush_mmu_free(struct mmu_gather *tlb)
+static void tlb_flush_mmu_free_batches(struct mmu_gather_batch *batch_start,
+  bool free_batch_page)
 {
-   struct mmu_gather_batch *batch;
+   struct mmu_gather_batch *batch, *next;
 
-   for (batch = >local; batch && batch->nr; batch = batch->next) {
-   free_pages_and_swap_cache(batch->pages, batch->nr);
-   batch->nr = 0;
+   for (batch = batch_start; batch; batch = next) {
+   next = batch->next;
+   if (batch->nr) {
+   free_pages_and_swap_cache(batch->pages, batch->nr);
+   batch->nr = 0;
+   }
+   if (free_batch_page)
+   free_pages((unsigned long)batch, 0);
}
+}
+
+static void tlb_flush_mmu_free(struct mmu_gather *tlb)
+{
+   tlb_flush_mmu_free_batches(>local, false);
tlb->active = >local;
 }
 
@@ -273,17 +284,12 @@ void tlb_flush_mmu(struct mmu_gather *tlb)
  */
 void tlb_finish_mmu(struct mmu_gather *tlb, unsigned long start, unsigned long 
end)
 {
-   struct mmu_gather_batch *batch, *next;
-
tlb_flush_mmu(tlb);
 
/* keep the page table cache within bounds */
check_pgt_cache();
 
-   for (batch = tlb->local.next; batch; batch = next) {
-   next = batch->next;
-   free_pages((unsigned long)batch, 0);
-   }
+   tlb_flush_mmu_free_batches(tlb->local.next, true);
tlb->local.next = NULL;
 }
 
-- 
2.7.4

[PATCH v2 4/5] mm: add force_free_pages in zap_pte_range

[Aaron Lu]

force_flush in zap_pte_range is set in the following 2 conditions:
1 When no more batches can be allocated (either due to no memory or
  MAX_GATHER_BATCH_COUNT has reached) to store those to-be-freed page
  pointers;
2 When a TLB_only flush is needed before dropping the PTE lock to avoid
  a race condition as explained in commit 1cf35d47712d ("mm: split
  'tlb_flush_mmu()' into tlb flushing and memory freeing parts").

Once force_flush is set, the pages accumulated thus far will all be
freed. Since there is no need to do page free for condition 2, add a new
variable named force_free_pages to decide if page free should be done
and it will only be set in condition 1.

With this change, the page accumulation will not be interrupted by
condition 2 anymore. In the meantime, rename force_flush to
force_flush_tlb for condition 2.

Signed-off-by: Aaron Lu 
---
 mm/memory.c | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/mm/memory.c b/mm/memory.c
index 19b25bb5f45b..83b38823aaba 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1199,7 +1199,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
struct zap_details *details)
 {
struct mm_struct *mm = tlb->mm;
-   int force_flush = 0;
+   int force_flush_tlb = 0, force_free_pages = 0;
int rss[NR_MM_COUNTERS];
spinlock_t *ptl;
pte_t *start_pte;
@@ -1239,7 +1239,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
 
if (!PageAnon(page)) {
if (pte_dirty(ptent)) {
-   force_flush = 1;
+   force_flush_tlb = 1;
set_page_dirty(page);
}
if (pte_young(ptent) &&
@@ -1251,7 +1251,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
if (unlikely(page_mapcount(page) < 0))
print_bad_pte(vma, addr, ptent, page);
if (unlikely(__tlb_remove_page(tlb, page))) {
-   force_flush = 1;
+   force_free_pages = 1;
addr += PAGE_SIZE;
break;
}
@@ -1279,18 +1279,14 @@ static unsigned long zap_pte_range(struct mmu_gather 
*tlb,
arch_leave_lazy_mmu_mode();
 
/* Do the actual TLB flush before dropping ptl */
-   if (force_flush)
+   if (force_flush_tlb) {
+   force_flush_tlb = 0;
tlb_flush_mmu_tlbonly(tlb);
+   }
pte_unmap_unlock(start_pte, ptl);
 
-   /*
-* If we forced a TLB flush (either due to running out of
-* batch buffers or because we needed to flush dirty TLB
-* entries before releasing the ptl), free the batched
-* memory too. Restart if we didn't do everything.
-*/
-   if (force_flush) {
-   force_flush = 0;
+   if (force_free_pages) {
+   force_free_pages = 0;
tlb_flush_mmu_free(tlb);
if (addr != end)
goto again;
-- 
2.7.4

[PATCH v2 5/5] mm: add debugfs interface for parallel free tuning

[Aaron Lu]

Make it possible to set different values for async_free_threshold and
max_gather_batch_count through debugfs.

With this, we can do tests for different purposes:
1 Restore vanilla kernel bahaviour for performance comparison.
  Set max_gather_batch_count to a value like 20 to effectively restore
  the behaviour of vanilla kernel since this will make page gathered
  always smaller than async_free_threshold(effectively disable parallel
  free);
2 Debug purpose.
  Set async_free_threshold to a very small value(like 128) to trigger
  parallel free even on ordinary processes, ideal for debug purpose with
  a virtual machine that doesn't have much memory assigned to it;
3 Performance tuning.
  Use a different value for async_free_threshold and max_gather_batch_count
  other than the default to test if parallel free performs better or worse.

Signed-off-by: Aaron Lu 
---
 mm/memory.c | 33 +++--
 1 file changed, 31 insertions(+), 2 deletions(-)

diff --git a/mm/memory.c b/mm/memory.c
index 83b38823aaba..3a971cc1fc3b 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -183,6 +183,35 @@ static void check_sync_rss_stat(struct task_struct *task)
 
 #ifdef HAVE_GENERIC_MMU_GATHER
 
+static unsigned long async_free_threshold = ASYNC_FREE_THRESHOLD;
+static unsigned long max_gather_batch_count = MAX_GATHER_BATCH_COUNT;
+
+#ifdef CONFIG_DEBUG_FS
+static int __init tlb_mmu_parallel_free_debugfs(void)
+{
+   umode_t mode = 0644;
+   struct dentry *dir;
+
+   dir = debugfs_create_dir("parallel_free", NULL);
+   if (!dir)
+   return -ENOMEM;
+
+   if (!debugfs_create_ulong("async_free_threshold", mode, dir,
+   _free_threshold))
+   goto fail;
+   if (!debugfs_create_ulong("max_gather_batch_count", mode, dir,
+   _gather_batch_count))
+   goto fail;
+
+   return 0;
+
+fail:
+   debugfs_remove_recursive(dir);
+   return -ENOMEM;
+}
+late_initcall(tlb_mmu_parallel_free_debugfs);
+#endif
+
 static bool tlb_next_batch(struct mmu_gather *tlb)
 {
struct mmu_gather_batch *batch;
@@ -193,7 +222,7 @@ static bool tlb_next_batch(struct mmu_gather *tlb)
return true;
}
 
-   if (tlb->batch_count == MAX_GATHER_BATCH_COUNT)
+   if (tlb->batch_count == max_gather_batch_count)
return false;
 
batch = (void *)__get_free_pages(GFP_NOWAIT | __GFP_NOWARN, 0);
@@ -307,7 +336,7 @@ static void tlb_flush_mmu_free(struct mmu_gather *tlb)
 {
struct batch_free_struct *batch_free = NULL;
 
-   if (tlb->page_nr >= ASYNC_FREE_THRESHOLD)
+   if (tlb->page_nr >= async_free_threshold)
batch_free = kmalloc(sizeof(*batch_free),
 GFP_NOWAIT | __GFP_NOWARN);
 
-- 
2.7.4

[PATCH v2 2/5] mm: parallel free pages

[Aaron Lu]

For regular processes, the time taken in its exit() path to free its
used memory is not a problem. But there are heavy ones that consume
several Terabytes memory and the time taken to free its memory could
last more than ten minutes.

To optimize this use case, a parallel free method is proposed and it is
based on the current gather batch free.

The current gather batch free works like this:
For each struct mmu_gather *tlb, there is a static buffer to store those
to-be-freed page pointers. The size is MMU_GATHER_BUNDLE, which is
defined to be 8. So if a tlb tear down doesn't free more than 8 pages,
that is all we need. If 8+ pages are to be freed, new pages will need
to be allocated to store those to-be-freed page pointers.

The structure used to describe the saved page pointers is called
struct mmu_gather_batch and tlb->local is of this type. tlb->local is
different than other struct mmu_gather_batch(es) in that the page
pointer array used by tlb->local points to the previouslly described
static buffer while the other struct mmu_gather_batch(es) page pointer
array points to the dynamically allocated pages.

These batches will form a singly linked list, starting from >local.

tlb->local.pages  => tlb->pages(8 pointers)
  \|/
  next => batch1->pages => about 510 pointers
\|/
next => batch2->pages => about 510 pointers
  \|/
  next => batch3->pages => about 510 pointers
... ...

The proposed parallel free did this: if the process has many pages to be
freed, accumulate them in these struct mmu_gather_batch(es) one after
another till 256K pages are accumulated. Then take this singly linked
list starting from tlb->local.next off struct mmu_gather *tlb and free
them in a worker thread. The main thread can return to continue zap
other pages(after freeing pages pointed by tlb->local.pages).

Note that since we may be accumulating as many as 256K pages now, the
soft lockup on !CONFIG_PREEMPT issue which is fixed by
commit 53a59fc67f97 ("mm: limit mmu_gather batching to fix soft lockups
on !CONFIG_PREEMPT") can reappear. For that matter, add cond_resched()
in tlb_flush_mmu_free_batches where many pages can be freed.

Signed-off-by: Aaron Lu 
---
 include/asm-generic/tlb.h | 15 +++--
 mm/memory.c   | 57 ++-
 2 files changed, 64 insertions(+), 8 deletions(-)

diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
index 4329bc6ef04b..7c2ac179cc47 100644
--- a/include/asm-generic/tlb.h
+++ b/include/asm-generic/tlb.h
@@ -78,13 +78,10 @@ struct mmu_gather_batch {
 #define MAX_GATHER_BATCH   \
((PAGE_SIZE - sizeof(struct mmu_gather_batch)) / sizeof(void *))
 
-/*
- * Limit the maximum number of mmu_gather batches to reduce a risk of soft
- * lockups for non-preemptible kernels on huge machines when a lot of memory
- * is zapped during unmapping.
- * 10K pages freed at once should be safe even without a preemption point.
- */
-#define MAX_GATHER_BATCH_COUNT (1UL/MAX_GATHER_BATCH)
+#define ASYNC_FREE_THRESHOLD (256*1024UL)
+#define MAX_GATHER_BATCH_COUNT \
+   DIV_ROUND_UP(ASYNC_FREE_THRESHOLD, MAX_GATHER_BATCH)
+#define PAGE_FREE_NR_TO_YIELD (1UL)
 
 /* struct mmu_gather is an opaque type used by the mm code for passing around
  * any data needed by arch specific code for tlb_remove_page.
@@ -108,6 +105,10 @@ struct mmu_gather {
struct page *__pages[MMU_GATHER_BUNDLE];
unsigned intbatch_count;
int page_size;
+   /* how many pages we have gathered to be freed */
+   unsigned intpage_nr;
+   /* list for spawned workers that do the free jobs */
+   struct list_headworker_list;
 };
 
 #define HAVE_GENERIC_MMU_GATHER
diff --git a/mm/memory.c b/mm/memory.c
index cdb2a53f251f..001c7720d773 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -228,6 +228,9 @@ void tlb_gather_mmu(struct mmu_gather *tlb, struct 
mm_struct *mm, unsigned long
tlb->local.max  = ARRAY_SIZE(tlb->__pages);
tlb->active = >local;
tlb->batch_count = 0;
+   tlb->page_nr= 0;
+
+   INIT_LIST_HEAD(>worker_list);
 
 #ifdef CONFIG_HAVE_RCU_TABLE_FREE
tlb->batch = NULL;
@@ -254,22 +257,65 @@ static void tlb_flush_mmu_free_batches(struct 
mmu_gather_batch *batch_start,
   bool free_batch_page)
 {
struct mmu_gather_batch *batch, *next;
+   int nr = 0;
 
for (batch = batch_start; batch; batch = next) {
next = batch->next;
if (batch->nr) {
free_pages_and_swap_cache(batch->pages, batch->nr);
+   nr += batch->nr;
batch->nr = 0;
}
-   if (free_batch_page)
+   if (free_batch_page) {
free_pages((unsigned 

Re: [PATCH v2 2/3] printk: rename selected_console -> preferred_console

[Petr Mladek]

On Thu 2017-03-02 10:01:53, Steven Rostedt wrote:
> On Thu,  2 Mar 2017 16:11:33 +0300
> Aleksey Makarov  wrote:
> 
> > The variable selected_console is set in __add_preferred_console()
> > to point to the last console parameter that was added to the
> > console_cmdline array.
> > 
> > Rename it to preferred_console so that the name reflects the usage.
> 
> As I said previously, I prefer "selected_console" but since
> "__add_preferred_console()" sets it, I'm fine with this change.
> Although, I would probably have changed that function to
> "__add_selected_console()" :)

If I get it correctly, the selected_console/preferred_console
value is used to keep the console first in the console_drivers list.
IMHO, the main effect is that each line will first appear on this
console, see call_console_drivers(). But the message will still
appear also on all other enabled consoles. From this point,
the name "preferred" sounds better to me. More consoles
are selected (enabled) and only one is preferred (first).

Well, I am not a native speaker and might be wrong. Also
it is possible that I missed something.

Anyway, the change looks fine to me.

Acked-by: Petr Mladek 

Best Regards,
Petr

Re: [PATCH v4 05/11] mm: thp: enable thp migration in generic path

[Geert Uytterhoeven]

On Tue, Mar 14, 2017 at 10:55 PM, Zi Yan  wrote:
 include/linux/swapops.h:223:2: warning: missing braces around initializer 
 [-Wmissing-braces]
>>  return (pmd_t){ 0 };
>>  ^
>>include/linux/swapops.h:223:2: warning: (near initialization for 
>> '(anonymous).pmd') [-Wmissing-braces]
>
> I do not have any warning with gcc 6.3.0. This seems to be a GCC bug
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119).

I guess you need

return (pmd_t) { { 0, }};

to kill the warning.

Gr{oetje,eeting}s,

Geert

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

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

[PATCH v2 3/5] mm: use a dedicated workqueue for the free workers

[Aaron Lu]

Introduce a workqueue for all the free workers so that user can fine
tune how many workers can be active through sysfs interface: max_active.
More workers will normally lead to better performance, but too many can
cause severe lock contention.

Note that since the zone lock is global, the workqueue is also global
for all processes, i.e. if we set 8 to max_active, we will have at most
8 workers active for all processes that are doing munmap()/exit()/etc.

Signed-off-by: Aaron Lu 
---
 mm/memory.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/mm/memory.c b/mm/memory.c
index 001c7720d773..19b25bb5f45b 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -253,6 +253,19 @@ static void tlb_flush_mmu_tlbonly(struct mmu_gather *tlb)
__tlb_reset_range(tlb);
 }
 
+static struct workqueue_struct *batch_free_wq;
+static int __init batch_free_wq_init(void)
+{
+   batch_free_wq = alloc_workqueue("batch_free_wq",
+   WQ_UNBOUND | WQ_SYSFS, 0);
+   if (!batch_free_wq) {
+   pr_warn("failed to create workqueue batch_free_wq\n");
+   return -ENOMEM;
+   }
+   return 0;
+}
+subsys_initcall(batch_free_wq_init);
+
 static void tlb_flush_mmu_free_batches(struct mmu_gather_batch *batch_start,
   bool free_batch_page)
 {
@@ -306,7 +319,7 @@ static void tlb_flush_mmu_free(struct mmu_gather *tlb)
batch_free->batch_start = tlb->local.next;
INIT_WORK(_free->work, batch_free_work);
list_add_tail(_free->list, >worker_list);
-   queue_work(system_unbound_wq, _free->work);
+   queue_work(batch_free_wq, _free->work);
 
tlb->batch_count = 0;
tlb->local.next = NULL;
-- 
2.7.4

[PATCH v2 0/5] mm: support parallel free of memory

[Aaron Lu]

For regular processes, the time taken in its exit() path to free its
used memory is not a problem. But there are heavy ones that consume
several Terabytes memory and the time taken to free its memory in its
exit() path could last more than ten minutes if THP is not used.

As Dave Hansen explained why do this in kernel:
"
One of the places we saw this happen was when an app crashed and was
exit()'ing under duress without cleaning up nicely.  The time that it
takes to unmap a few TB of 4k pages is pretty excessive.
"

To optimize this use case, a parallel free method is proposed here and
it is based on the current gather batch free(the following description
is taken from patch 2/5's changelog).

The current gather batch free works like this:
For each struct mmu_gather *tlb, there is a static buffer to store those
to-be-freed page pointers. The size is MMU_GATHER_BUNDLE, which is
defined to be 8. So if a tlb tear down doesn't free more than 8 pages,
that is all we need. If 8+ pages are to be freed, new pages will need
to be allocated to store those to-be-freed page pointers.

The structure used to describe the saved page pointers is called
struct mmu_gather_batch and tlb->local is of this type. tlb->local is
different than other struct mmu_gather_batch(es) in that the page
pointer array used by tlb->local points to the previouslly described
static buffer while the other struct mmu_gather_batch(es) page pointer
array points to the dynamically allocated pages.

These batches will form a singly linked list, starting from >local.

tlb->local.pages  => tlb->pages(8 pointers)
  \|/
  next => batch1->pages => about 510 pointers
\|/
next => batch2->pages => about 510 pointers
  \|/
  next => batch3->pages => about 510 pointers
... ...

The proposed parallel free did this: if the process has many pages to be
freed, accumulate them in these struct mmu_gather_batch(es) one after
another till 256K pages are accumulated. Then take this singly linked
list starting from tlb->local.next off struct mmu_gather *tlb and free
them in a worker thread. The main thread can return to continue zap
other pages(after freeing pages pointed by tlb->local.pages).

A test program that did a single malloc() of 320G memory is used to see
how useful the proposed parallel free solution is, the time calculated
is for the free() call. Test machine is a Haswell EX which has
4nodes/72cores/144threads with 512G memory. All tests are done with THP
disabled.

kernel time
v4.10  10.8s  ±2.8%
this patch(with default setting)   5.795s ±5.8%

Patch 3/5 introduced a dedicated workqueue for the free workers and
here are more results when setting different values for max_active of
this workqueue:

max_active:   time
1 8.9s   ±0.5%
2 5.65s  ±5.5%
4 4.84s  ±0.16%
8 4.77s  ±0.97%
164.85s  ±0.77%
326.21s  ±0.46%

Comments are welcome and appreciated.

v2 changes: Nothing major, only minor ones.
 - rebased on top of v4.11-rc2-mmotm-2017-03-14-15-41;
 - use list_add_tail instead of list_add to add worker to tlb's worker
   list so that when doing flush, the first queued worker gets flushed
   first(based on the comsumption that the first queued worker has a
   better chance of finishing its job than those later queued workers);
 - use bool instead of int for variable free_batch_page in function
   tlb_flush_mmu_free_batches;
 - style change according to ./scripts/checkpatch;
 - reword some of the changelogs to make it more readable.

v1 is here:
https://lkml.org/lkml/2017/2/24/245

Aaron Lu (5):
  mm: add tlb_flush_mmu_free_batches
  mm: parallel free pages
  mm: use a dedicated workqueue for the free workers
  mm: add force_free_pages in zap_pte_range
  mm: add debugfs interface for parallel free tuning

 include/asm-generic/tlb.h |  15 ++---
 mm/memory.c   | 141 +++---
 2 files changed, 128 insertions(+), 28 deletions(-)

-- 
2.7.4

Re: [PATCH 1/3] dt-bindings: add the grf clock for dw-mipi-dsi

[Heiko Stübner]

Am Mittwoch, 15. März 2017, 16:42:30 CET schrieb Chris Zhong:
> For RK3399, the grf clock should be controlled by dw-mipi-dsi driver,
> add the description for this clock.
> 
> Signed-off-by: Chris Zhong 
> ---
> 
>  .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt   | 2
> +- 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git
> a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.t
> xt
> b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.t
> xt index 188f6f7..7e17a60 100644
> ---
> a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.t
> xt +++
> b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.t
> xt @@ -10,7 +10,7 @@ Required properties:
>  - interrupts: Represent the controller's interrupt to the CPU(s).
>  - clocks, clock-names: Phandles to the controller's pll reference
>clock(ref) and APB clock(pclk). For RK3399, a phy config clock
> -  (phy_cfg) is additional required. As described in [1].
> +  (phy_cfg) and a grf clock(grf) are additional required. As described in
> [1].

your "grf" clock is optional, as it is not present on all socs (like the 
rk3288) so should probably move to a separate section and not be in the 
required properties


Heiko

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Jon Hunter]

Hi Rajendra,

On 15/03/17 03:47, Nayak, Rajendra wrote:
> Hey Jon,
> 
 Looks like there is still some interest/needs in/for this. Any thoughts
 on how we can move this forward?
>>>
>>> At the Linaro Connect last week, I was talking to Björn, Rajendra and
>>> Stephen more about these related issues.
>>>
>>> It definitely seems like we need to progress with this somehow,
>>> meaning we need a solution for being able to associate a device with
>>> more than one PM domain. In that context, I don't think genpd based on
>>> its current design, is a good fit to solve the problem.
>>>
>>> Instead I think we need something entirely new (perhaps some code can
>>> be borrowed from genpd), which is more similar to the clock/regulator
>>> framework. In other words, what you also were suggesting in a earlier
>>> reply.
>>> In this way, the driver/subsystem gains full flexibility of managing
>>> its device's PM domains, which seems like the best future-proof
>>> solution.
>>
>> I agree, I think that that would give us the most flexibility to handle
>> whatever scenario. However, I was thinking that we could still use the
>> genpd core to register pm-domains with and control. My thought was to
>> allow devices to have a bindings with multiple pm-domains ...
>>
>> dev-xyz {
>> ...
>> power-domains = <>, <>;
>> };
>>
>> Then in the genpd core we do having something like ...
>>
>> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
>> index e697dec9d25b..d1ae6ddf4903 100644
>> --- a/drivers/base/power/domain.c
>> +++ b/drivers/base/power/domain.c
>> @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev)
>>
>> "samsung,power-domain", 0);
>> if (!pd_args.np)
>> return -ENOENT;
>> +   } else if (ret > 1) {
>> +   /*
>> +* If there are more than one PM domain defined for a
>> device,
>> +* then these need to be manually controlled by the
>> device
>> +* driver because the genpd core cannot bind a device
>> with
>> +* more than one PM domain.
>> +*/
>> +   dev_dbg(dev, "cannot add PM domains, %d detected!\n",
>> ret);
>> +   return 0;
>> }
>>
>> Then add some new public APIs for getting and controlling the
>> pm-domains ...
>>
>> struct generic_pm_domain *pm_genpd_get(struct device *dev, char *name);
>> - Use 'dev->of_node' to look-up pm-domain if populated, else uses name.
>>
>> struct generic_pm_domain *of_pm_genpd_get(struct device *dev, int index);
>> void pm_genpd_put(struct generic_pm_domain *pd);
>> int pm_genpd_power_on(struct generic_pm_domain *pd);
>> int pm_genpd_power_off(struct generic_pm_domain *pd);
>> - Power on/off APIs would be synchronous types
> 
> These would also need some kind of usecounting I guess, since genpd
> otherwise relies on runtime PM to do the usecounting.

Yes exactly.

> This overall seems like a reasonable approach to solve the problem we
> have. While we discussed this approach at connect, we thought it would
> be a good idea to bring out some RFC on these lines to get the
> discussion going. Do you think you would be able to work on some quick
> RFC around these lines, else if you think you would be busy in the near
> term I can help with hacking up the changes as well.

Yes I plan too. I will let you know if I get side tracked on something else.

Cheers!
Jon

-- 
nvpublic

Re: [PATCH v6 00/11] perf: arm64: Support for Hisilicon SoC Hardware event counters

[Anurup M]

Please have a look at this patch series. Looking forward for any 
feedback and comments.


Thanks,
Anurup

On Friday 10 March 2017 11:55 AM, Anurup M wrote:

Provide Support for Hisilicon SoC(HiP05/06/07) Hardware event counters.
The Hisilicon SoC HiP0x series has many uncore or non-CPU performance
events and counters units.

This v6 version is rebased to 4.11-rc1.

This patch series is implemented refering to arm-cci, Intel/AMD uncore and
also the cavium thunderX and xgene uncore pmu patches.

Support for Hisilicon L3 cache(L3C) and Miscellaneous nodes(MN) hardware
events and counters are added in this implementation.

The uncore PMU units are registered as separate PMUs.
e.g. in the case of L3 cache, which consist of 4 banks/instances, each bank
is registered with perf as separate PMU, as each bank have separate control
registers and interrupts. These units are also not CPU affine in the current
chip versions.

The Hisilicon uncore PMUs can be found under /sys/bus/event_source/devices.
The counters are exported via sysfs in the corresponding events files
under the PMU directory so the perf tool can list the event names.

There is no counter overflow IRQ support in hardware for these uncore PMUs.
So the driver use poll method using hrtimer to avoid overflow.

ToDo:
1) ACPI probe and reset support.

Version history
---
v6
--
- Rebase to 4.11-rc1
- Modify Copyright year to 2017.

v5
--
- Use hrtimer to avoid overflow as MN counter overflow IRQ is broken
   in hardware.
- Remove IRQ handling of MN in driver and update pmu dt-bindings.
- Fix reveiw comments in v4 version.

v4
--
- Counter overflow IRQ handling for MN PMU.
- Use hrtimer to avoid counter overflow in L3 Cache PMU.
- Use hisi-cpu- and hisi-io- for djtag compatible field.
- Fix reveiw comments in v3 version.

v3
--
- Fix review comments of v2 version.
- Handle event groups. Do not allow group of mixed PMUs.
- Use hip0x prefix for compatible names.
- Fix all sparse and gcc W=1 warnings.

v2
--
- Fix review comments of v1 version.
- Move djtag driver to drivers/perf/hisilicon.
- Have separate PMU instance for each L3 cache banks.
- Modify device properties in DTS as per review comments.
- Handle hardware version difference.
- Change compatible names of djtag so use prefix hisi-
   and remove chip version as driver only depend on djtag
   hw version.
- use devm_kzalloc.
- Remove DDRC changes in this series. As the DDRC PMU doesnot
   depend on djtag it will be send separately.

v1
--
-Initial version with support for L3C, MN and DDRC event counters
-Djtag driver is used to access registers of L3 cache and MN.

Anurup M (8):
   arm64: MAINTAINERS: hisi: Add hisilicon SoC PMU support
   dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU
   Documentation: perf: hisi: Documentation for HiP05/06/07 PMU event
 counting.
   drivers: perf: hisi: Update Kconfig for Hisilicon PMU support
   drivers: perf: hisi: Add support for Hisilicon SoC event counters
   drivers: perf: hisi: use poll method to avoid L3C counter overflow
   drivers: perf: hisi: use poll method when no IRQ for MN counter
 overflow
   dts: arm64: hip07: Add Hisilicon SoC PMU support

Shaokun Zhang (1):
   drivers: perf: hisi: Miscellanous node(MN) event counting in perf

Tan Xiaojun (2):
   dt-bindings: hisi: Add Hisilicon HiP05/06/07 Djtag dts bindings
   drivers: perf: hisi: Add support for Hisilicon Djtag driver

  .../devicetree/bindings/arm/hisilicon/djtag.txt|  76 ++
  .../devicetree/bindings/arm/hisilicon/pmu.txt  |  87 +++
  Documentation/perf/hisi-pmu.txt|  76 ++
  MAINTAINERS|   9 +
  arch/arm64/boot/dts/hisilicon/hip07.dtsi   |  79 +++
  drivers/perf/Kconfig   |   8 +
  drivers/perf/Makefile  |   1 +
  drivers/perf/hisilicon/Makefile|   1 +
  drivers/perf/hisilicon/djtag.c | 773 +
  drivers/perf/hisilicon/djtag.h |  42 ++
  drivers/perf/hisilicon/hisi_uncore_l3c.c   | 653 +
  drivers/perf/hisilicon/hisi_uncore_mn.c| 528 ++
  drivers/perf/hisilicon/hisi_uncore_pmu.c   | 445 
  drivers/perf/hisilicon/hisi_uncore_pmu.h   | 137 
  14 files changed, 2915 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
  create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
  create mode 100644 Documentation/perf/hisi-pmu.txt
  create mode 100644 drivers/perf/hisilicon/Makefile
  create mode 100644 drivers/perf/hisilicon/djtag.c
  create mode 100644 drivers/perf/hisilicon/djtag.h
  create mode 100644 drivers/perf/hisilicon/hisi_uncore_l3c.c
  create mode 100644 drivers/perf/hisilicon/hisi_uncore_mn.c
  create mode 100644 drivers/perf/hisilicon/hisi_uncore_pmu.c
  create mode 100644 

RE: [RFC PATCH] iommu/dma: check pci host bridge dma_mask for IOVA allocation

[Oza Oza]

Hi Robin,

I tried applying

[1]:http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1306545.ht
ml
[3]:http://www.spinics.net/lists/arm-kernel/msg566947.html

Because of 3 its crashing on our platform. (with SDHCI running with iommu
both enabled and disabled)

[   19.925018] PC is at sdhci_send_command+0x648/0xb30
[   19.930048] LR is at sdhci_send_command+0x588/0xb30
[   19.935078] pc : [] lr : [] pstate:
a1c5
[   19.942707] sp : 80097ff1ede0
[   19.946123] x29: 80097ff1ede0 x28: 
[   19.951623] x27: 0001 x26: 08923ca8
[   19.957124] x25: 8009750dc0d8 x24: 8009750dacc0
[   19.962625] x23: 00418958 x22: 0003
[   19.968125] x21: 8009750dc118 x20: 8009750dc198
[   19.973626] x19: 8009750dac00 x18: 0400
[   19.979126] x17:  x16: 
[   19.984627] x15: 8009764e4880 x14: 800976811548
[   19.990128] x13: 0008 x12: 7e0025ff9580
[   19.995628] x11: 800976d28080 x10: 0840
[   20.001129] x9 : 0040 x8 : 800976801020
[   20.006629] x7 : 0009d000 x6 : 08441358
[   20.012130] x5 :  x4 : 
[   20.017631] x3 : 800976465080 x2 : 
[   20.023130] x1 : 7e0025ce7802 x0 : ffe4
[   20.028630]
[   20.030165] ---[ end trace cd394f1ca2a1b19b ]---
[   20.034925] Call trace:
[   20.037446] Exception stack(0x80097ff1ec10 to 0x80097ff1ed40)
[   20.044089] ec00:   8009750dac00
0001
[   20.052165] ec20: 80097ff1ede0 085c9cb0 
0001
[   20.060242] ec40: 80097ff1ec90 084402b4 800976421000
800976465040
[   20.068318] ec60: 800976465040  80097659c850
80097653d810
[   20.076393] ec80: 0001 800973cb9300 80097ff1ecb0
08440324
[   20.084470] eca0: 800976421000 01c0 ffe4
7e0025ce7802
[   20.092547] ecc0:  800976465080 

[   20.100623] ece0: 08441358 0009d000 800976801020
0040
[   20.108699] ed00: 0840 800976d28080 7e0025ff9580
0008
[   20.116776] ed20: 800976811548 8009764e4880 

[   20.124853] [] sdhci_send_command+0x648/0xb30
[   20.130959] [] sdhci_irq+0x9e8/0xa20
[   20.136259] [] __handle_irq_event_percpu+0x9c/0x128
[   20.142901] [] handle_irq_event_percpu+0x1c/0x58
[   20.149275] [] handle_irq_event+0x48/0x78
[   20.155022] [] handle_fasteoi_irq+0xb8/0x1a0
[   20.161036] [] generic_handle_irq+0x24/0x38
[   20.166962] [] __handle_domain_irq+0x5c/0xb8
[   20.172977] [] gic_handle_irq+0xbc/0x168

Regards,
Oza.
-Original Message-
From: Oza Oza [mailto:oza@broadcom.com]
Sent: Tuesday, March 14, 2017 5:16 PM
To: 'Robin Murphy'; 'Joerg Roedel'
Cc: 'io...@lists.linux-foundation.org'; 'linux-kernel@vger.kernel.org';
'linux-arm-ker...@lists.infradead.org';
'bcm-kernel-feedback-l...@broadcom.com'; 'a...@arndb.de'; 'Nikita
Yushchenko'
Subject: RE: [RFC PATCH] iommu/dma: check pci host bridge dma_mask for
IOVA allocation

My responses inline:

-Original Message-
From: Robin Murphy [mailto:robin.mur...@arm.com]
Sent: Tuesday, March 14, 2017 4:27 PM
To: Oza Pawandeep; Joerg Roedel
Cc: io...@lists.linux-foundation.org; linux-kernel@vger.kernel.org;
linux-arm-ker...@lists.infradead.org;
bcm-kernel-feedback-l...@broadcom.com; a...@arndb.de; Nikita Yushchenko
Subject: Re: [RFC PATCH] iommu/dma: check pci host bridge dma_mask for
IOVA allocation

On 14/03/17 08:48, Oza Pawandeep wrote:
> It is possible that PCI device supports 64-bit DMA addressing, and
> thus it's driver sets device's dma_mask to DMA_BIT_MASK(64), however
> PCI host bridge may have limitations on the inbound transaction
> addressing. As an example, consider NVME SSD device connected to
> iproc-PCIe controller.

Aw heck, not another one :(

> Currently, the IOMMU DMA ops only considers PCI device dma_mask when
> allocating an IOVA. This is particularly problematic on
> ARM/ARM64 SOCs where the IOMMU (i.e. SMMU) translates IOVA to PA for
> in-bound transactions only after PCI Host has forwarded these
> transactions on SOC IO bus. This means on such ARM/ARM64 SOCs the IOVA
> of in-bound transactions has to honor the addressing restrictions of
> the PCI Host.

Depending on whether this most closely matches the R-Car situation[1] or
the X-Gene situation[2], this may not address the real problem at all (if
the non-IOMMU case is also affected). Either way it also fails to help
non-PCI devices which can face the exact same problem.

I am not fully aware of R-car and X-gene situation, but for iproc based
SOCs, our pcie host floats addresses in higher order dma_mask is set.

> This patch tries to solve above described IOVA allocation problem by:
> 1. Adding 

Re: crypto: deadlock between crypto_alg_sem/rtnl_mutex/genl_mutex

[Dmitry Vyukov]

On Tue, Mar 14, 2017 at 4:25 PM, Sowmini Varadhan
 wrote:
> On (03/14/17 09:14), Dmitry Vyukov wrote:
>> Another one now involving rds_tcp_listen_stop
>:
>> kworker/u4:1/19 is trying to acquire lock:
>>  (sk_lock-AF_INET){+.+.+.}, at: [] lock_sock
>> include/net/sock.h:1460 [inline]
>>  (sk_lock-AF_INET){+.+.+.}, at: []
>> rds_tcp_listen_stop+0x5c/0x150 net/rds/tcp_listen.c:288
>>
>> but task is already holding lock:
>>  (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x17/0x20
>> net/core/rtnetlink.c:70
>
> Is this also a false positive?
>
> genl_lock_dumpit takes the genl_lock and then waits on the rtnl_lock
> (e.g., out of tipc_nl_bearer_dump).
>
> netdev_run_todo takes the rtnl_lock and then wants lock_sock()
> for the TCP/IPv4 socket.
>
> Why is lockdep seeing a circular dependancy here? Same pattern
> seems to be happening  for
>   http://www.spinics.net/lists/netdev/msg423368.html
> and maybe also http://www.spinics.net/lists/netdev/msg423323.html?
>
> --Sowmini
>
>> Chain exists of:
>>   sk_lock-AF_INET --> genl_mutex --> rtnl_mutex
>>
>>  Possible unsafe locking scenario:
>>
>>CPU0CPU1
>>
>>   lock(rtnl_mutex);
>>lock(genl_mutex);
>>lock(rtnl_mutex);
>>   lock(sk_lock-AF_INET);
>>
>>  *** DEADLOCK ***
>>
>> 4 locks held by kworker/u4:1/19:
>>  #0:  ("%s""netns"){.+.+.+}, at: []
>> __write_once_size include/linux/compiler.h:283 [inline]
>>  #0:  ("%s""netns"){.+.+.+}, at: [] atomic64_set
>> arch/x86/include/asm/atomic64_64.h:33 [inline]
>>  #0:  ("%s""netns"){.+.+.+}, at: [] atomic_long_set
>> include/asm-generic/atomic-long.h:56 [inline]
>>  #0:  ("%s""netns"){.+.+.+}, at: [] set_work_data
>> kernel/workqueue.c:617 [inline]
>>  #0:  ("%s""netns"){.+.+.+}, at: []
>> set_work_pool_and_clear_pending kernel/workqueue.c:644 [inline]
>>  #0:  ("%s""netns"){.+.+.+}, at: []
>> process_one_work+0xab3/0x1c10 kernel/workqueue.c:2089
>>  #1:  (net_cleanup_work){+.+.+.}, at: []
>> process_one_work+0xb07/0x1c10 kernel/workqueue.c:2093
>>  #2:  (net_mutex){+.+.+.}, at: []
>> cleanup_net+0x22b/0xa90 net/core/net_namespace.c:429
>>  #3:  (rtnl_mutex){+.+.+.}, at: []
>> rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70



After I've applied the patch these reports stopped to happen, and I
have not seem any other reports that look relevant.
However, it there was one, but it looks like a different issue and it
was probably masked by massive amounts of original deadlock reports:


[ INFO: possible circular locking dependency detected ]
4.10.0+ #29 Not tainted
---
syz-executor5/29222 is trying to acquire lock:
 (genl_mutex){+.+.+.}, at: [] genl_lock
net/netlink/genetlink.c:32 [inline]
 (genl_mutex){+.+.+.}, at: []
genl_family_rcv_msg+0xdae/0x1040 net/netlink/genetlink.c:547

but task is already holding lock:
 (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x17/0x20
net/core/rtnetlink.c:70

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (rtnl_mutex){+.+.+.}:
   validate_chain kernel/locking/lockdep.c:2267 [inline]
   __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
   lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
   __mutex_lock_common kernel/locking/mutex.c:756 [inline]
   __mutex_lock+0x172/0x1730 kernel/locking/mutex.c:893
   mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
   rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70
   nl80211_dump_wiphy+0x45/0x6d0 net/wireless/nl80211.c:1946
   genl_lock_dumpit+0x68/0x90 net/netlink/genetlink.c:479
   netlink_dump+0x54d/0xd40 net/netlink/af_netlink.c:2168
   __netlink_dump_start+0x4e5/0x760 net/netlink/af_netlink.c:2258
   genl_family_rcv_msg+0xd9d/0x1040 net/netlink/genetlink.c:546
   genl_rcv_msg+0xa6/0x140 net/netlink/genetlink.c:620
   netlink_rcv_skb+0x2ab/0x390 net/netlink/af_netlink.c:2339
   genl_rcv+0x28/0x40 net/netlink/genetlink.c:631
   netlink_unicast_kernel net/netlink/af_netlink.c:1272 [inline]
   netlink_unicast+0x514/0x730 net/netlink/af_netlink.c:1298
   netlink_sendmsg+0xa9f/0xe50 net/netlink/af_netlink.c:1844
   sock_sendmsg_nosec net/socket.c:633 [inline]
   sock_sendmsg+0xca/0x110 net/socket.c:643
   ___sys_sendmsg+0x8fa/0x9f0 net/socket.c:1985
   __sys_sendmsg+0x138/0x300 net/socket.c:2019
   SYSC_sendmsg net/socket.c:2030 [inline]
   SyS_sendmsg+0x2d/0x50 net/socket.c:2026
   do_syscall_64+0x2e8/0x930 arch/x86/entry/common.c:281
   return_from_SYSCALL_64+0x0/0x7a

-> #0 (genl_mutex){+.+.+.}:
   check_prev_add kernel/locking/lockdep.c:1830 [inline]
   check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1940
   validate_chain kernel/locking/lockdep.c:2267 [inline]
   __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
   lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
   

[PATCH] Staging: goldfish: use __func__ instead of embedded function names

[mshan]

Embedded function names are less appropriate to use when
refactoring, can cause function renaming.  Prefer the use
of "%s", __func__ to embedded function names

Signed-off-by: Mohsin Shan 
---
 drivers/staging/goldfish/goldfish_nand.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/goldfish/goldfish_nand.c 
b/drivers/staging/goldfish/goldfish_nand.c
index 76d60ee..8f92ff4 100644
--- a/drivers/staging/goldfish/goldfish_nand.c
+++ b/drivers/staging/goldfish/goldfish_nand.c
@@ -114,8 +114,8 @@ static int goldfish_nand_erase(struct mtd_info *mtd, struct 
erase_info *instr)
len = len / mtd->writesize * (mtd->writesize + mtd->oobsize);
 
if (goldfish_nand_cmd(mtd, NAND_CMD_ERASE, ofs, len, NULL) != len) {
-   pr_err("goldfish_nand_erase: erase failed, start %llx, len %x, 
dev_size %llx, erase_size %x\n",
-  ofs, len, mtd->size, mtd->erasesize);
+   pr_err("%s: erase failed, start %llx, len %x, dev_size %llx, 
erase_size %x\n",
+  __func__, ofs, len, mtd->size, mtd->erasesize);
return -EIO;
}
 
@@ -125,8 +125,8 @@ static int goldfish_nand_erase(struct mtd_info *mtd, struct 
erase_info *instr)
return 0;
 
 invalid_arg:
-   pr_err("goldfish_nand_erase: invalid erase, start %llx, len %x, 
dev_size %llx, erase_size %x\n",
-  ofs, len, mtd->size, mtd->erasesize);
+   pr_err("%s: invalid erase, start %llx, len %x, dev_size %llx, 
erase_size %x\n",
+  __func__, ofs, len, mtd->size, mtd->erasesize);
return -EINVAL;
 }
 
@@ -254,8 +254,8 @@ static int goldfish_nand_block_isbad(struct mtd_info *mtd, 
loff_t ofs)
return goldfish_nand_cmd(mtd, NAND_CMD_BLOCK_BAD_GET, ofs, 0, NULL);
 
 invalid_arg:
-   pr_err("goldfish_nand_block_isbad: invalid arg, ofs %llx, dev_size 
%llx, write_size %x\n",
-  ofs, mtd->size, mtd->writesize);
+   pr_err("%s: invalid arg, ofs %llx, dev_size %llx, write_size %x\n",
+  __func__, ofs, mtd->size, mtd->writesize);
return -EINVAL;
 }
 
@@ -277,8 +277,8 @@ static int goldfish_nand_block_markbad(struct mtd_info 
*mtd, loff_t ofs)
return 0;
 
 invalid_arg:
-   pr_err("goldfish_nand_block_markbad: invalid arg, ofs %llx, dev_size 
%llx, write_size %x\n",
-  ofs, mtd->size, mtd->writesize);
+   pr_err("%s: invalid arg, ofs %llx, dev_size %llx, write_size %x\n",
+  __func__, ofs, mtd->size, mtd->writesize);
return -EINVAL;
 }
 
-- 
2.7.4

Re: [PATCH v10 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID

[H. Peter Anvin]

,"open list:KERNEL SELFTEST FRAMEWORK" 
,kvm list 
From: h...@zytor.com
Message-ID: 

On March 14, 2017 12:23:40 PM PDT, Andy Lutomirski  wrote:
>On Tue, Mar 14, 2017 at 12:01 PM, H. Peter Anvin  wrote:
>> and at least theoretically we
>> could be indirecting though the ->stack pointer for every one if gcc
>> can't tell it won't have changed (we really need to get thread_info
>> moved into the task_struct allocation and away from the kernel stack,
>> especially since on x86 the pointer is the same size as the vestigial
>> structure it points to.)
>
>Solved by use of time machine:
>
>commit 15f4eae70d365bba26854c90b6002aaabb18c8aa
>Author: Andy Lutomirski 
>Date:   Tue Sep 13 14:29:25 2016 -0700
>
>x86: Move thread_info into task_struct
>
>
>:)

My apologies, -ESTALEBRAINCACHE...
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[RFC PATCH] rework memory hotplug onlining

[Michal Hocko]

Hi,
this is a follow up for [1]. In short the current semantic of the memory
hotplug is awkward and hard/impossible to use from the udev to online
memory as movable. The main problem is that only the last memblock or
the adjacent to highest movable memblock can be onlined as movable:
: Let's simulate memory hot online manually
: # echo 0x1 > /sys/devices/system/memory/probe
: # grep . /sys/devices/system/memory/memory32/valid_zones
: Normal Movable
: 
: which looks reasonably right? Both Normal and Movable zones are allowed
: 
: # echo $((0x1+(128<<20))) > /sys/devices/system/memory/probe
: # grep . /sys/devices/system/memory/memory3?/valid_zones
: /sys/devices/system/memory/memory32/valid_zones:Normal
: /sys/devices/system/memory/memory33/valid_zones:Normal Movable
: 
: Huh, so our valid_zones have changed under our feet...
: 
: # echo $((0x1+2*(128<<20))) > /sys/devices/system/memory/probe
: # grep . /sys/devices/system/memory/memory3?/valid_zones
: /sys/devices/system/memory/memory32/valid_zones:Normal
: /sys/devices/system/memory/memory33/valid_zones:Normal
: /sys/devices/system/memory/memory34/valid_zones:Normal Movable
: 
: and again. So only the last memblock is considered movable. Let's try to
: online them now.
: 
: # echo online_movable > /sys/devices/system/memory/memory34/state
: # grep . /sys/devices/system/memory/memory3?/valid_zones
: /sys/devices/system/memory/memory32/valid_zones:Normal
: /sys/devices/system/memory/memory33/valid_zones:Normal Movable
: /sys/devices/system/memory/memory34/valid_zones:Movable Normal

Now consider that the userspace gets the notification when the memblock
is added. If the udev context tries to online it it will a) race with
new memblocks showing up which leads to undeterministic behavior and
b) it will see memblocks ordered in growing physical addresses while
the only reliable way to online blocks as movable is exactly from other
directions. This is just plain wrong!

It seems that all this is just started by the semantic introduced by
9d99aaa31f59 ("[PATCH] x86_64: Support memory hotadd without sparsemem")
quite some time ago. When the movable onlinining has been introduced it
just built on top of this. It seems that the requirement to have
freshly probed memory associated with the zone normal is no longer
necessary. HOTPLUG depends on CONFIG_SPARSEMEM these days.

The following blob [2] simply removes all the zone specific operations
from __add_pages (aka arch_add_memory) path.  Instead we do page->zone
association from move_pfn_range which is called from online_pages. The
criterion for movable/normal zone association is really simple now. We
just have to guarantee that zone Normal is always lower than zone
Movable. It would be actually sufficient to guarantee they do not
overlap and that is indeed trivial to implement now. I didn't do that
yet for simplicity of this change though.

I have lightly tested the patch and nothing really jumped at me. I
assume there will be some rough edges but it should be sufficient to
start the discussion at least. Please note the diffstat. We have added
a lot of code to tweak on top of the previous semantic which is just
sad. Instead of developing a robust solution the memory hotplug is full
of tweaks to satisfy particular usecase without longer term plans.

Please note that this is just for x86 now but I will address other
arches once there is an agreement this is the right approach.

Thoughts, objections?

[1] http://lkml.kernel.org/r/20170310135807.gi3...@dhcp22.suse.cz
[2] I didn't get to split it out to proper patches yet because I would
like to hear back about potential issues which would basically block the
whole thing before I spend more time on this
---
 arch/x86/mm/init_32.c  |   4 +-
 arch/x86/mm/init_64.c  |   9 +-
 drivers/base/memory.c  |  52 +++---
 include/linux/memory_hotplug.h |  11 +-
 include/linux/mmzone.h |  13 +-
 mm/memory_hotplug.c| 360 +++--
 mm/page_alloc.c|  11 +-
 mm/sparse.c|   3 +-
 8 files changed, 137 insertions(+), 326 deletions(-)

diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index 928cfde76232..9deded3728bf 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -819,12 +819,10 @@ void __init mem_init(void)
 int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
 {
struct pglist_data *pgdata = NODE_DATA(nid);
-   struct zone *zone = pgdata->node_zones +
-   zone_for_memory(nid, start, size, ZONE_HIGHMEM, for_device);
unsigned long start_pfn = start >> PAGE_SHIFT;
unsigned long nr_pages = size >> PAGE_SHIFT;
 
-   return __add_pages(nid, zone, start_pfn, nr_pages);
+   return __add_pages(nid, start_pfn, nr_pages);
 }
 
 #ifdef CONFIG_MEMORY_HOTREMOVE
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 7eef17239378..bc53f24e6703 100644
--- 

Re: [PATCH v5 2/5] powerpc: kretprobes: override default function entry offset

[Naveen N. Rao]

On 2017/03/14 10:18AM, Arnaldo Carvalho de Melo wrote:
> Em Thu, Mar 09, 2017 at 05:37:38PM +1100, Michael Ellerman escreveu:
> > "Naveen N. Rao"  writes:
> > > On 2017/03/08 11:29AM, Arnaldo Carvalho de Melo wrote:
> > >> > I wasn't sure if you were planning on picking up KPROBES_ON_FTRACE for 
> > >> > v4.11. If so, it would be good to take this patch through the powerpc 
> > >> > tree. Otherwise, this can go via Ingo's tree.
> > >> 
> > >> If you guys convince Ingo that this should go _now_, then just cherry
> > >> pick what was merged into tip/perf/core that is needed for the arch
> > >> specific stuff and go from there.
> > >
> > > Ok, in hindsight, I think Michael's concern was actually for v4.12 
> > 
> > Yes I was talking about 4.12, sorry I thought that was implied :)
> > 
> > > itself, in which case this particular patch can go via powerpc tree, 
> > > while the rest of the patches in this series can go via your tree.
> > >
> > > Michael?
> > 
> > Yeah I think that's the easiest option. The function will be temporarily
> > unused until the two trees are merged, but I think that's fine.
> 
> Ok, done that, now compile testing building it in my
> multi-distro/x-build containers.

Thanks, Arnaldo!

I did however notice that you don't seem to have applied Patch 1/5 from 
this series:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1347858.html

That patch is needed to ensure perf continues to work when ftrace README 
advertises support for ref_reloc_sym+offset for kretprobes. Can you 
please apply that as well?

- Naveen

Re: [PATCH 1/3] kvm: arm/arm64: Take mmap_sem in stage2_unmap_vm

[Christoffer Dall]

On Tue, Mar 14, 2017 at 02:52:32PM +, Suzuki K Poulose wrote:
> From: Marc Zyngier 
> 
> We don't hold the mmap_sem while searching for the VMAs when
> we try to unmap each memslot for a VM. Fix this properly to
> avoid unexpected results.
> 
> Fixes: commit 957db105c997 ("arm/arm64: KVM: Introduce stage2_unmap_vm")
> Cc: sta...@vger.kernel.org # v3.19+
> Cc: Christoffer Dall 
> Signed-off-by: Marc Zyngier 
> Signed-off-by: Suzuki K Poulose 
> ---
>  arch/arm/kvm/mmu.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index 962616f..f2e2e0c 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -803,6 +803,7 @@ void stage2_unmap_vm(struct kvm *kvm)
>   int idx;
>  
>   idx = srcu_read_lock(>srcu);
> + down_read(>mm->mmap_sem);
>   spin_lock(>mmu_lock);
>  
>   slots = kvm_memslots(kvm);
> @@ -810,6 +811,7 @@ void stage2_unmap_vm(struct kvm *kvm)
>   stage2_unmap_memslot(kvm, memslot);
>  
>   spin_unlock(>mmu_lock);
> + up_read(>mm->mmap_sem);
>   srcu_read_unlock(>srcu, idx);
>  }
>  
> -- 
> 2.7.4
> 

Are we sure that holding mmu_lock is valid while holding the mmap_sem?

Thanks,
-Christoffer