Re: [PATCH v5 02/11] mm: mempolicy: add queue_pages_node_check()

[Mel Gorman]

On Fri, May 19, 2017 at 12:37:38PM -0400, Zi Yan wrote:
> > As you say, there is no functional change but the helper name is vague
> > and gives no hint to what's it's checking for. It's somewhat tolerable as
> > it is as it's obvious what is being checked but the same is not true with
> > the helper name.
> >
> 
> Does queue_pages_invert_nodemask_check() work? I can change the helper name
> in the next version.
> 

Not particularly, maybe queue_pages_required and invert the check with a
comment above it explaining what it's checking for would be ok.

-- 
Mel Gorman
SUSE Labs

Re: [PATCH 2/2] efifb: Avoid reconfiguration of BAR that covers the framebuffer

[Bjorn Helgaas]

On Fri, May 19, 2017 at 05:37:30PM +0100, Ard Biesheuvel wrote:
> Hi Bjorn,
> 
> On 19 May 2017 at 17:27, Bjorn Helgaas  wrote:
> > [+cc linux-pci]
> >
> > On Tue, Apr 04, 2017 at 04:27:44PM +0100, Ard Biesheuvel wrote:
> >> On UEFI systems, the PCI subsystem is enumerated by the firmware,
> >> and if a graphical framebuffer is exposed by a PCI device, its base
> >> address and size are exposed to the OS via the Graphics Output
> >> Protocol (GOP).
> >>
> >> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
> >> scratch at boot. This may result in the GOP framebuffer address to
> >> become stale, if the BAR covering the framebuffer is modified. This
> >> will cause the framebuffer to become unresponsive, and may in some
> >> cases result in unpredictable behavior if the range is reassigned to
> >> another device.
> >>
> >> So add a non-x86 quirk to the EFI fb driver to find the BAR associated
> >> with the GOP base address, and claim the BAR resource so that the PCI
> >> core will not move it.
> >
> > I know this has already been merged as 55d728a40d36 ("efi/fb: Avoid
> > reconfiguration of BAR that covers the framebuffer"), and I'm not
> > suggesting that we revert it, but I have some misgivings.
> ...

> > Another is the use of pci_claim_resource() to express the idea that "this
> > BAR can not be moved".  We have IORESOURCE_PCI_FIXED for that purpose, and
> > previous versions of the patch used that.  I understand there was some
> > problem with that, but I wish we could figure out and fix that problem
> > instead of using a different mechanism.
> 
> OK. The problem was that IORESOURCE_PCI_FIXED does not prevent the PCI
> subsystem from handing out the same range to another device.

Yes, this would definitely be a problem.  There must be a path where
we start doing the reassignment before we claim the resources that
have already been assigned.  That's what seems backwards to me -- it
seems like we should claim things that are valid first so we know to
avoid them.

> > I'm not even completely sold on the idea that we need to prevent the BAR
> > from being moved.  I'm not a UEFI expert, but if this requirement is in the
> > spec, we should reference it.  If not, it should be sufficient to remember
> > the boot-time BAR value, match the GOP base to *that*, and map it to
> > whatever the current BAR value is.
> 
> There is no such requirement in the spec. The graphics output protocol
> is not described in terms of PCI, BARs etc. The framebuffer is simply
> a memory range with side effects that is left enabled when handing
> over to the OS.
> 
> In summary, I am as unhappy with the patch as you are, but it is still
> an improvement over the previous situation, so let's simply
> collaborate to get this into shape going forward.
> 
> My preference would be to investigate IORESOURCE_PCI_FIXED again,
> because that still seems like the best way to deal with a live
> framebuffer on a PCI device that has memory decoding enabled. It
> should also address the issue with the current version of the patch,
> i.e., that claiming resources at this point is not possible if the
> device resides behind a bridge.
> 
> So is there any guidance you can give as to how to proceed? If we set
> IORESOURCE_PCI_FIXED, how should be prevent the PCI layer from
> assigning this resource elsewhere if we cannot claim it yet?

My preference would actually be to remember the boot BAR values and
map to the current values because that avoids the unnecessary
restriction.  The IORESOURCE_PCI_FIXED uses that seem legitimate to me
are the legacy VGA and IDE things (stuff that's not described by BARs
and *can't* be moved) and the new "Enhanced Allocation" stuff
(basically a way to describe more non-BAR resources).

We do something sort of similar with pci_revert_fw_address(), although
it's currently only implemented for x86.  I could imagine a more
generic solution that could be used for this GOP issue and could also
replace pci_revert_fw_address().

Conceptually it could be as simple as adding 7 u64 boot-time BAR
values (6 BARs + the ROM) to struct pci_dev.  We went to a lot of
trouble to implement the pcibios_fwaddrmap stuff on x86, and I can't
remember why it's x86-specific.  Maybe we thought the extra 56 bytes
per dev was too much overhead (it does seem like a lot for such a
limited use case).  Maybe there's a clever way to store just the BARs
we actually change and keep that long enough for efifb to use it.

It *would* be nice to fix the problem with IORESOURCE_PCI_FIXED, and I
think it would help clean up PCI resource management a lot.  Ideally
we would be able to claim host bridge resources even before scanning
the bus, then claim BARs immediately when we discover them.  That
would allow us to automatically use any setup done by firmware, and
reassign anything that we couldn't claim.

But I think this will end up being difficult because we currently do
the PCI bus scan before looking at ACPI 

Re: [PATCH 1/6] kmod: add dynamic max concurrent thread count

[Dmitry Torokhov]

On Thu, May 18, 2017 at 08:24:39PM -0700, Luis R. Rodriguez wrote:
> We currently statically limit the number of modprobe threads which
> we allow to run concurrently to 50. As per Keith Owens, this was a
> completely arbitrary value, and it was set in the 2.3.38 days [0]
> over 16 years ago in year 2000.
> 
> Although we haven't yet hit our lower limits, experimentation [1]
> shows that when and if we hit this limit in the worst case, will be
> fatal -- consider get_fs_type() failures upon mount on a system which
> has many partitions, some of which might even be with the same
> filesystem. Its best to be prudent and increase and set this
> value to something more sensible which ensures we're far from hitting
> the limit and also allows default build/user run time override.
> 
> The worst case is fatal given that once a module fails to load there
> is a period of time during which subsequent request for the same module
> will fail, so in the case of partitions its not just one request that
> could fail, but whole series of partitions. This later issue of a
> module request failure domino effect can be addressed later, but
> increasing the limit to something more meaninful should at least give us
> enough cushion to avoid this for a while.
> 
> Set this value up with a bit more meaninful modern limits:
> 
> Bump this up to 64  max for small systems (CONFIG_BASE_SMALL)
> Bump this up to 128 max for larger systems (!CONFIG_BASE_SMALL)
> 
> Also allow the default max limit to be further fine tuned at compile
> time and at initialization at run time at boot up using the kernel
> parameter: max_modprobes.
> 
> [0] 
> https://git.kernel.org/cgit/linux/kernel/git/history/history.git/commit/?id=ab1c4ec7410f6ec64e1511d1a7d850fc99c09b44
> [1] https://github.com/mcgrof/test_request_module

If we actually run into this issue, instead of slamming the system with
bazillion concurrent requests, can we wait for the other modprobes to
finish and then continue?

Thanks.

-- 
Dmitry

Re: Use case for TASKS_RCU

[Ingo Molnar]

* Paul E. McKenney  wrote:

> On Tue, May 16, 2017 at 08:22:33AM +0200, Ingo Molnar wrote:
> > 
> > * Paul E. McKenney  wrote:
> > 
> > > Hello!
> > > 
> > > The question of the use case for TASKS_RCU came up, and here is my
> > > understanding.  Steve will not be shy about correcting any misconceptions
> > > I might have.  ;-)
> > > 
> > > The use case is to support freeing of trampolines used in tracing/probing
> > > in CONFIG_PREEMPT=y kernels.  It is necessary to wait until any task
> > > executing in the trampoline in question has left it, taking into account
> > > that the trampoline's code might be interrupted and preempted.  However,
> > > the code in the trampolines is guaranteed never to context switch.
> > > 
> > > Note that in CONFIG_PREEMPT=n kernels, synchronize_sched() suffices.
> > > It is therefore tempting to think in terms of disabling preemption across
> > > the trampolines, but there is apparently not enough room to accommodate
> > > the needed preempt_disable() and preempt_enable() in the code invoking
> > > the trampoline, and putting the preempt_disable() and preempt_enable()
> > > in the trampoline itself fails because of the possibility of preemption
> > > just before the preempt_disable() and just after the preempt_enable().
> > > Similar reasoning rules out use of rcu_read_lock() and rcu_read_unlock().
> > 
> > So how was this solved before TASKS_RCU? Also, nothing uses 
> > call_rcu_tasks() at 
> > the moment, so it's hard for me to review its users. What am I missing?
> 
> Before TASKS_RCU, the trampolines were just leaked when CONFIG_PREEMPT=y.
> 
> Current mainline kernel/trace/ftrace.c uses synchronize_rcu_tasks().
> So yes, currently one user.

So why not schedule a worklet on every CPU to drive the trampoline freeing? To 
guarantee that nothing was preempted it could run at SCHED_IDLE and could 
observe 
nr_running from the worklet and use a short timeout loop. Batching and 
hysteresis 
would ensure that this is only running rarely in practice.

It doesn't have to be fast or particularly elegant, but it could use existing 
kernel facilites just fine: it's a corner case cost and quirk of our live 
kernel 
text modifying trampoline code and our current CONFIG_PREEMPT=y model.

I.e. don't make it an RCU facility that complicates not just the RCU code but 
has 
various costs in generic code as well:

kernel/exit.c:  TASKS_RCU(int tasks_rcu_i);
kernel/exit.c:  TASKS_RCU(preempt_disable());
kernel/exit.c:  TASKS_RCU(tasks_rcu_i = __srcu_read_lock(_rcu_exit_srcu));
kernel/exit.c:  TASKS_RCU(preempt_enable());
kernel/exit.c:  TASKS_RCU(__srcu_read_unlock(_rcu_exit_srcu, 
tasks_rcu_i));

I.e. I question that this should be a generic RCU facility.

Thanks,

Ingo

[PATCH v2 0/2] Make iowait_boost optional and default to policy

[Joel Fernandes]

iowait_boost is causing power regression on our arm64 SoC. Really going to max
frequency is bad for power on mobile devices and not wise.
These patches make it optional and default to what the policy suggests coming
from the cpufreq driver as input to the governor.

Here are some power numbers collected on an arm64 based Qualcomm SoC on a mobile
device running a YouTube video for 30 seconds:

Before: 8.042533 mWh
After: 7.948377 mWh
Energy savings is ~1.2%

Joel Fernandes (2):
  cpufreq: Make iowait boost a policy option
  sched: Use iowait boost policy option in schedutil

 drivers/cpufreq/intel_pstate.c   |  1 +
 include/linux/cpufreq.h  |  3 +++
 kernel/sched/cpufreq_schedutil.c | 32 
 3 files changed, 36 insertions(+)

Cc: Srinivas Pandruvada 
Cc: Len Brown 
Cc: Rafael J. Wysocki 
Cc: Viresh Kumar 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
-- 
2.13.0.303.g4ebf302169-goog

[PATCH v2 2/2] sched: Make iowait_boost optional in schedutil

[Joel Fernandes]

We should apply the iowait boost only if cpufreq policy has iowait boost
enabled. Also make it a schedutil configuration from sysfs so it can be turned
on/off if needed (by default initialize it to the policy value).

For systems that don't need/want it enabled, such as those on arm64 based
mobile devices that are battery operated, it saves energy when the cpufreq
driver policy doesn't have it enabled (details below):

Here are some results for energy measurements collected running a YouTube video
for 30 seconds:
Before: 8.042533 mWh
After: 7.948377 mWh
Energy savings is ~1.2%

Cc: Srinivas Pandruvada 
Cc: Len Brown 
Cc: Rafael J. Wysocki 
Cc: Viresh Kumar 
Cc: Ingo Molnar  
Cc: Peter Zijlstra  
Signed-off-by: Joel Fernandes 
---
 kernel/sched/cpufreq_schedutil.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 76877a62b5fa..0e392b58b9b3 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -24,6 +24,7 @@
 struct sugov_tunables {
struct gov_attr_set attr_set;
unsigned int rate_limit_us;
+   bool iowait_boost_enable;
 };
 
 struct sugov_policy {
@@ -171,6 +172,11 @@ static void sugov_get_util(unsigned long *util, unsigned 
long *max)
 static void sugov_set_iowait_boost(struct sugov_cpu *sg_cpu, u64 time,
   unsigned int flags)
 {
+   struct sugov_policy *sg_policy = sg_cpu->sg_policy;
+
+   if (!sg_policy->tunables->iowait_boost_enable)
+   return;
+
if (flags & SCHED_CPUFREQ_IOWAIT) {
sg_cpu->iowait_boost = sg_cpu->iowait_boost_max;
} else if (sg_cpu->iowait_boost) {
@@ -386,10 +392,34 @@ static ssize_t rate_limit_us_store(struct gov_attr_set 
*attr_set, const char *bu
return count;
 }
 
+static ssize_t iowait_boost_enable_show(struct gov_attr_set *attr_set,
+   char *buf)
+{
+   struct sugov_tunables *tunables = to_sugov_tunables(attr_set);
+
+   return sprintf(buf, "%u\n", tunables->iowait_boost_enable);
+}
+
+static ssize_t iowait_boost_enable_store(struct gov_attr_set *attr_set,
+const char *buf, size_t count)
+{
+   struct sugov_tunables *tunables = to_sugov_tunables(attr_set);
+   bool enable;
+
+   if (kstrtobool(buf, ))
+   return -EINVAL;
+
+   tunables->iowait_boost_enable = enable;
+
+   return count;
+}
+
 static struct governor_attr rate_limit_us = __ATTR_RW(rate_limit_us);
+static struct governor_attr iowait_boost_enable = 
__ATTR_RW(iowait_boost_enable);
 
 static struct attribute *sugov_attributes[] = {
_limit_us.attr,
+   _boost_enable.attr,
NULL
 };
 
@@ -543,6 +573,8 @@ static int sugov_init(struct cpufreq_policy *policy)
tunables->rate_limit_us *= lat;
}
 
+   tunables->iowait_boost_enable = policy->iowait_boost_enable;
+
policy->governor_data = sg_policy;
sg_policy->tunables = tunables;
 
-- 
2.13.0.303.g4ebf302169-goog

RE: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

[Chen, Xiaoguang]

>-Original Message-
>From: Alex Williamson [mailto:alex.william...@redhat.com]
>Sent: Thursday, May 18, 2017 10:56 PM
>To: Chen, Xiaoguang 
>Cc: Gerd Hoffmann ; Tian, Kevin ;
>linux-kernel@vger.kernel.org; zhen...@linux.intel.com; Lv, Zhiyuan
>; intel-gvt-...@lists.freedesktop.org; Wang, Zhi A
>
>Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
>
>On Thu, 18 May 2017 01:51:38 +
>"Chen, Xiaoguang"  wrote:
>
>> Hi Alex,
>>
>> >-Original Message-
>> >From: Alex Williamson [mailto:alex.william...@redhat.com]
>> >Sent: Thursday, May 18, 2017 5:44 AM
>> >To: Chen, Xiaoguang 
>> >Cc: Gerd Hoffmann ; Tian, Kevin
>> >; linux-kernel@vger.kernel.org;
>> >zhen...@linux.intel.com; Lv, Zhiyuan ;
>> >intel-gvt-...@lists.freedesktop.org; Wang, Zhi A
>> >
>> >Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the
>> >dmabuf
>> >
>> >On Tue, 16 May 2017 10:16:28 +
>> >"Chen, Xiaoguang"  wrote:
>> >
>> >> Hi Alex,
>> >>
>> >> >-Original Message-
>> >> >From: Alex Williamson [mailto:alex.william...@redhat.com]
>> >> >Sent: Tuesday, May 16, 2017 1:44 AM
>> >> >To: Chen, Xiaoguang 
>> >> >Cc: Gerd Hoffmann ; Tian, Kevin
>> >> >; intel-...@lists.freedesktop.org;
>> >> >linux-kernel@vger.kernel.org; zhen...@linux.intel.com; Lv, Zhiyuan
>> >> >; intel-gvt- d...@lists.freedesktop.org;
>> >> >Wang, Zhi A 
>> >> >Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting
>> >> >the dmabuf
>> >> >
>> >> >On Mon, 15 May 2017 03:36:50 + "Chen, Xiaoguang"
>> >> > wrote:
>> >> >
>> >> >> Hi Alex and Gerd,
>> >> >>
>> >> >> >-Original Message-
>> >> >> >From: Alex Williamson [mailto:alex.william...@redhat.com]
>> >> >> >Sent: Saturday, May 13, 2017 12:38 AM
>> >> >> >To: Gerd Hoffmann 
>> >> >> >Cc: Chen, Xiaoguang ; Tian, Kevin
>> >> >> >; intel-...@lists.freedesktop.org; linux-
>> >> >> >ker...@vger.kernel.org; zhen...@linux.intel.com; Lv, Zhiyuan
>> >> >> >; intel-gvt-...@lists.freedesktop.org;
>> >> >> >Wang, Zhi A 
>> >> >> >Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting
>> >> >> >the dmabuf
>> >> >> >
>> >> >> >On Fri, 12 May 2017 11:12:05 +0200 Gerd Hoffmann
>> >> >> > wrote:
>> >> >> >
>> >> >> >>   Hi,
>> >> >> >>
>> >> >> >> > If the contents of the framebuffer change or if the
>> >> >> >> > parameters of the framebuffer change?  I can't image that
>> >> >> >> > creating a new dmabuf fd for every visual change within the
>> >> >> >> > framebuffer would be efficient, but I don't have any
>> >> >> >> > concept of what a dmabuf actually
>> >does.
>> >> >> >>
>> >> >> >> Ok, some background:
>> >> >> >>
>> >> >> >> The drm subsystem has the concept of planes.  The most
>> >> >> >> important plane is the primary framebuffer (i.e. what gets
>> >> >> >> scanned out to the physical display).  The cursor is a plane
>> >> >> >> too, and there can be additional overlay planes for stuff like video
>playback.
>> >> >> >>
>> >> >> >> Typically there are multiple planes in a system and only one
>> >> >> >> of them gets scanned out to the crtc, i.e. the fbdev
>> >> >> >> emulation creates one plane for the framebuffer console.  The
>> >> >> >> X-Server creates a plane too, and when you switch between
>> >> >> >> X-Server and framebuffer console via ctrl-alt-fn the intel
>> >> >> >> driver just reprograms the encoder to scan out the one or the other
>plane to the crtc.
>> >> >> >>
>> >> >> >> The dma-buf handed out by gvt is a reference to a plane.  I
>> >> >> >> think on the host side gvt can see only the active plane
>> >> >> >> (from encoder/crtc register
>> >> >> >> programming) not the inactive ones.
>> >> >> >>
>> >> >> >> The dma-buf can be imported as opengl texture and then be
>> >> >> >> used to render the guest display to a host window.  I think
>> >> >> >> it is even possible to use the dma-buf as plane in the host
>> >> >> >> drm driver and scan it out directly to a physical display.
>> >> >> >> The actual framebuffer content stays in gpu memory all the
>> >> >> >> time, the cpu never has
>> >to touch it.
>> >> >> >>
>> >> >> >> It is possible to cache the dma-buf handles, i.e. when the
>> >> >> >> guest boots you'll get the first for the fbcon plane, when
>> >> >> >> the x-server starts the second for the x-server framebuffer,
>> >> >> >> and when the user switches to the text console via
>> >> >> >> ctrl-alt-fn you can re-use the fbcon dma-buf you already have.
>> >> >> >>
>> >> >> >> The 

[PATCH v2 1/2] cpufreq: Make iowait boost a policy option

[Joel Fernandes]

Make iowait boost a cpufreq policy option and enable it for intel_pstate
cpufreq driver. Governors like schedutil can use it to determine if
boosting for tasks that wake up with p->in_iowait set is needed.

Cc: Srinivas Pandruvada 
Cc: Len Brown 
Cc: Rafael J. Wysocki 
Cc: Viresh Kumar 
Cc: Ingo Molnar  
Cc: Peter Zijlstra  
Signed-off-by: Joel Fernandes 
---
 drivers/cpufreq/intel_pstate.c | 1 +
 include/linux/cpufreq.h| 3 +++
 2 files changed, 4 insertions(+)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index b7de5bd76a31..5dddc21da4f6 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -2239,6 +2239,7 @@ static int intel_cpufreq_cpu_init(struct cpufreq_policy 
*policy)
 
policy->cpuinfo.transition_latency = INTEL_CPUFREQ_TRANSITION_LATENCY;
policy->transition_delay_us = INTEL_CPUFREQ_TRANSITION_DELAY;
+   policy->iowait_boost_enable = true;
/* This reflects the intel_pstate_get_cpu_pstates() setting. */
policy->cur = policy->cpuinfo.min_freq;
 
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index a5ce0bbeadb5..0783d8b52ec8 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -127,6 +127,9 @@ struct cpufreq_policy {
 */
unsigned inttransition_delay_us;
 
+   /* Boost switch for tasks with p->in_iowait set */
+   bool iowait_boost_enable;
+
 /* Cached frequency lookup from cpufreq_driver_resolve_freq. */
unsigned int cached_target_freq;
int cached_resolved_idx;
-- 
2.13.0.303.g4ebf302169-goog

Re: [PATCH net-next V5 0/9] vhost_net rx batch dequeuing

[Jason Wang]

On 2017年05月18日 04:59, Michael S. Tsirkin wrote:

On Wed, May 17, 2017 at 12:14:36PM +0800, Jason Wang wrote:

This series tries to implement rx batching for vhost-net. This is done
by batching the dequeuing from skb_array which was exported by
underlayer socket and pass the sbk back through msg_control to finish
userspace copying. This is also the requirement for more batching
implemention on rx path.

Tests shows at most 7.56% improvment bon rx pps on top of batch
zeroing and no obvious changes for TCP_STREAM/TCP_RR result.

Please review.

Thanks

A surprisingly large gain for such as simple change.  It would be nice
to understand better why this helps - in particular, does the optimal
batch size change if ring is bigger or smaller?


Will test, just want to confirm. You mean virtio ring not tx_queue_len here?

Thanks


But let's merge it
meanwhile.

Series:

Acked-by: Michael S. Tsirkin 




Changes from V4:
- drop batch zeroing patch
- renew the performance numbers
- move skb pointer array out of vhost_net structure

Changes from V3:
- add batch zeroing patch to fix the build warnings

Changes from V2:
- rebase to net-next HEAD
- use unconsume helpers to put skb back on releasing
- introduce and use vhost_net internal buffer helpers
- renew performance numbers on top of batch zeroing

Changes from V1:
- switch to use for() in __ptr_ring_consume_batched()
- rename peek_head_len_batched() to fetch_skbs()
- use skb_array_consume_batched() instead of
   skb_array_consume_batched_bh() since no consumer run in bh
- drop the lockless peeking patch since skb_array could be resized, so
   it's not safe to call lockless one

Jason Wang (8):
   skb_array: introduce skb_array_unconsume
   ptr_ring: introduce batch dequeuing
   skb_array: introduce batch dequeuing
   tun: export skb_array
   tap: export skb_array
   tun: support receiving skb through msg_control
   tap: support receiving skb from msg_control
   vhost_net: try batch dequing from skb array

Michael S. Tsirkin (1):
   ptr_ring: add ptr_ring_unconsume

  drivers/net/tap.c |  25 +++--
  drivers/net/tun.c |  31 ---
  drivers/vhost/net.c   | 128 +++---
  include/linux/if_tap.h|   5 ++
  include/linux/if_tun.h|   5 ++
  include/linux/ptr_ring.h  | 120 +++
  include/linux/skb_array.h |  31 +++
  7 files changed, 327 insertions(+), 18 deletions(-)

--
2.7.4

Re: [PATCH] mmc: sdhci-iproc: suppress spurious interrupt with Multiblock read

[Adrian Hunter]

On 18/05/17 19:57, Srinath Mannam wrote:
> The stingray SDHCI hardware supports ACMD12 and automatically
> issues after multi block transfer completed.
> 
> If ACMD12 in SDHCI is disabled, spurious tx done interrupts are seen
> on multi block read command with below error message:
> 
> Got data interrupt 0x0002 even though no data
> operation was in progress.
> 
> This patch uses SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 to enable
> ACM12 support in SDHCI hardware and suppress spurious interrupt.
> 
> Signed-off-by: Srinath Mannam 
> Reviewed-by: Ray Jui 
> Reviewed-by: Scott Branden 

Acked-by: Adrian Hunter 

> 
> diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c
> index 3275d49..61666d2 100644
> --- a/drivers/mmc/host/sdhci-iproc.c
> +++ b/drivers/mmc/host/sdhci-iproc.c
> @@ -187,7 +187,8 @@ static const struct sdhci_iproc_data iproc_cygnus_data = {
>  };
>  
>  static const struct sdhci_pltfm_data sdhci_iproc_pltfm_data = {
> - .quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK,
> + .quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
> +   SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12,
>   .quirks2 = SDHCI_QUIRK2_ACMD23_BROKEN,
>   .ops = _iproc_ops,
>  };
> 

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

[Christoph Hellwig]

On Thu, May 18, 2017 at 06:13:55PM -0700, Andy Lutomirski wrote:
> a) Leave the Dell quirk in place until someone from Dell or Samsung
> figures out what's actually going on.  Add a blanket quirk turning off
> the deepest sleep state on all Intel devices [1] at least until
> someone from Intel figures out what's going on -- Hi, Keith!  Deal
> with any other problems as they're reported.

I think we should just blacklist the 60p entirely.  It also seems to
corrupt data 100% reliable when used with XFS.

Re: [PATCH v2 2/2] sched: Make iowait_boost optional in schedutil

[Viresh Kumar]

On 18-05-17, 23:23, Joel Fernandes wrote:
> We should apply the iowait boost only if cpufreq policy has iowait boost
> enabled. Also make it a schedutil configuration from sysfs so it can be turned
> on/off if needed (by default initialize it to the policy value).
> 
> For systems that don't need/want it enabled, such as those on arm64 based
> mobile devices that are battery operated, it saves energy when the cpufreq
> driver policy doesn't have it enabled (details below):
> 
> Here are some results for energy measurements collected running a YouTube 
> video
> for 30 seconds:
> Before: 8.042533 mWh
> After: 7.948377 mWh
> Energy savings is ~1.2%
> 
> Cc: Srinivas Pandruvada 
> Cc: Len Brown 
> Cc: Rafael J. Wysocki 
> Cc: Viresh Kumar 
> Cc: Ingo Molnar  
> Cc: Peter Zijlstra  
> Signed-off-by: Joel Fernandes 
> ---
>  kernel/sched/cpufreq_schedutil.c | 32 
>  1 file changed, 32 insertions(+)
> 
> diff --git a/kernel/sched/cpufreq_schedutil.c 
> b/kernel/sched/cpufreq_schedutil.c
> index 76877a62b5fa..0e392b58b9b3 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -24,6 +24,7 @@
>  struct sugov_tunables {
>   struct gov_attr_set attr_set;
>   unsigned int rate_limit_us;
> + bool iowait_boost_enable;

I suggested s/iowait_boost_enable/iowait_boost/ and you said okay for
that change.

>  };
>  
>  struct sugov_policy {
> @@ -171,6 +172,11 @@ static void sugov_get_util(unsigned long *util, unsigned 
> long *max)
>  static void sugov_set_iowait_boost(struct sugov_cpu *sg_cpu, u64 time,
>  unsigned int flags)
>  {
> + struct sugov_policy *sg_policy = sg_cpu->sg_policy;
> +
> + if (!sg_policy->tunables->iowait_boost_enable)
> + return;
> +
>   if (flags & SCHED_CPUFREQ_IOWAIT) {
>   sg_cpu->iowait_boost = sg_cpu->iowait_boost_max;
>   } else if (sg_cpu->iowait_boost) {
> @@ -386,10 +392,34 @@ static ssize_t rate_limit_us_store(struct gov_attr_set 
> *attr_set, const char *bu
>   return count;
>  }
>  
> +static ssize_t iowait_boost_enable_show(struct gov_attr_set *attr_set,
> + char *buf)
> +{
> + struct sugov_tunables *tunables = to_sugov_tunables(attr_set);
> +
> + return sprintf(buf, "%u\n", tunables->iowait_boost_enable);
> +}
> +
> +static ssize_t iowait_boost_enable_store(struct gov_attr_set *attr_set,
> +  const char *buf, size_t count)
> +{
> + struct sugov_tunables *tunables = to_sugov_tunables(attr_set);
> + bool enable;
> +
> + if (kstrtobool(buf, ))
> + return -EINVAL;
> +
> + tunables->iowait_boost_enable = enable;
> +
> + return count;
> +}
> +
>  static struct governor_attr rate_limit_us = __ATTR_RW(rate_limit_us);
> +static struct governor_attr iowait_boost_enable = 
> __ATTR_RW(iowait_boost_enable);
>  
>  static struct attribute *sugov_attributes[] = {
>   _limit_us.attr,
> + _boost_enable.attr,
>   NULL
>  };

Do we really need this right now? I mean, are you going to use it this
way? It may never get used eventually and may be better to leave the
sysfs option for now.

> @@ -543,6 +573,8 @@ static int sugov_init(struct cpufreq_policy *policy)
>   tunables->rate_limit_us *= lat;
>   }
>  
> + tunables->iowait_boost_enable = policy->iowait_boost_enable;
> +
>   policy->governor_data = sg_policy;
>   sg_policy->tunables = tunables;

-- 
viresh

Re: [PATCH v2 00/10] rt2x00: rt2x00: improve calling conventions for register accessors

[Arnd Bergmann]

On Fri, May 19, 2017 at 7:18 AM, Kalle Valo  wrote:
> Arnd Bergmann  writes:
>
>> I've managed to split up my long patch into a series of reasonble
>> steps now.
>>
>> The first two are required to fix a regression from commit 41977e86c984
>> ("rt2x00: add support for MT7620"), the rest are just cleanups to
>> have a consistent state across all the register access functions.
>
> Can these all go to 4.13 or would you prefer me to push the first two
> 4.12? Or what?

I think you can reasonably argue either way: the second patch does
fix a real bug that may or may not lead to an exploitable stack overflow
when CONFIG_KASAN is enabled, which would be a reason to put it
into 4.12. On the other hand, I have another 20 patches for similar
(or worse) stack overflow issues with KASAN that I'm hoping to all
get into 4.13 and backported into stable kernel later if necessary,
so we could treat this one like the others.

The only difference between this and the others is that in rt2x00 it
is a regression against 4.11, while the others have all been present
for a long time.

  Arnd

Re: [PATCH v2 00/10] rt2x00: rt2x00: improve calling conventions for register accessors

[Arnd Bergmann]

On Fri, May 19, 2017 at 8:44 AM, Tom Psyborg  wrote:
> warning: 'rt2800_bbp_read' used but never defined
>  static u8 rt2800_bbp_read(struct rt2x00_dev *rt2x00dev,
>^
> /home/ubuntu/Music/openwrt/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7620/compat-wireless-2016-05-12/drivers/net/wireless/ralink/rt2x00/rt2800lib.h:262:13:
> warning: 'rt2800_bbp_write' used but never defined
>  static void rt2800_bbp_write(struct rt2x00_dev *rt2x00dev,
>  ^
>   CC [M]
> /home/ubuntu/Music/openwrt/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7620/compat-wireless-2016-05-12/drivers/net/wireless/ralink/rt2x00/rt2800pci.o
> In file included from
> /home/ubuntu/Music/openwrt/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7620/compat-wireless-2016-05-12/drivers/net/wireless/ralink/rt2x00/rt2800pci.c:43:0:
> /home/ubuntu/Music/openwrt/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7620/compat-wireless-2016-05-12/drivers/net/wireless/ralink/rt2x00/rt2800lib.h:259:11:
> warning: 'rt2800_bbp_read' declared 'static' but never defined
> [-Wunused-function]
>  static u8 rt2800_bbp_read(struct rt2x00_dev *rt2x00dev,
>^

On which base version did you apply my patches? There may be a conflict
against patches that are in your tree but not yet in linux-next, as I don't see
the warning and also see no reference to rt2800_bbp_read in rt2800lib.h

  Arnd

[PATCH v2 1/9] crypto: add hmac IPAD/OPAD constant

[Corentin Labbe]

Many HMAC users directly use directly 0x36/0x5c values.
It's better with crypto to use a name instead of directly some crypto
constant.

This patch simply add HMAC_IPAD_VALUE/HMAC_OPAD_VALUE defines in a new
include file "crypto/hmac.h" and use them in crypto/hmac.c

Signed-off-by: Corentin Labbe 
---
 crypto/hmac.c | 5 +++--
 include/crypto/hmac.h | 7 +++
 2 files changed, 10 insertions(+), 2 deletions(-)
 create mode 100644 include/crypto/hmac.h

diff --git a/crypto/hmac.c b/crypto/hmac.c
index 72e38c098bb3..92871dc2a63e 100644
--- a/crypto/hmac.c
+++ b/crypto/hmac.c
@@ -16,6 +16,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -74,8 +75,8 @@ static int hmac_setkey(struct crypto_shash *parent,
memcpy(opad, ipad, bs);
 
for (i = 0; i < bs; i++) {
-   ipad[i] ^= 0x36;
-   opad[i] ^= 0x5c;
+   ipad[i] ^= HMAC_IPAD_VALUE;
+   opad[i] ^= HMAC_OPAD_VALUE;
}
 
return crypto_shash_init(shash) ?:
diff --git a/include/crypto/hmac.h b/include/crypto/hmac.h
new file mode 100644
index ..ef09f7938204
--- /dev/null
+++ b/include/crypto/hmac.h
@@ -0,0 +1,7 @@
+#ifndef _CRYPTO_HMAC_H
+#define _CRYPTO_HMAC_H
+
+#define HMAC_IPAD_VALUE 0x36
+#define HMAC_OPAD_VALUE 0x5c
+
+#endif /* _CRYPTO_HMAC_H */
-- 
2.13.0

[PATCH v2 7/9] crypto: qat - Use IPAD/OPAD constant

[Corentin Labbe]

This patch simply replace all occurrence of HMAC IPAD/OPAD value by their
define.

Signed-off-by: Corentin Labbe 
---
 drivers/crypto/qat/qat_common/qat_algs.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/qat/qat_common/qat_algs.c 
b/drivers/crypto/qat/qat_common/qat_algs.c
index 20f35df8a01f..5b5efcc52cb5 100644
--- a/drivers/crypto/qat/qat_common/qat_algs.c
+++ b/drivers/crypto/qat/qat_common/qat_algs.c
@@ -51,6 +51,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -178,8 +179,8 @@ static int qat_alg_do_precomputes(struct 
icp_qat_hw_auth_algo_blk *hash,
for (i = 0; i < block_size; i++) {
char *ipad_ptr = ipad + i;
char *opad_ptr = opad + i;
-   *ipad_ptr ^= 0x36;
-   *opad_ptr ^= 0x5C;
+   *ipad_ptr ^= HMAC_IPAD_VALUE;
+   *opad_ptr ^= HMAC_OPAD_VALUE;
}
 
if (crypto_shash_init(shash))
-- 
2.13.0

[PATCH] mount.2: revise description of MS_REMOUNT | MS_BIND

[NeilBrown]

MS_REMOUNT|MS_BIND affect all per-mount-point
flag.  MS_READONLY is only special because it,
uniquely, is both a per-mount-point flag *and* a
per-filesystem flag.

So the sections of per-mount-point flags and
MS_REMOUNT can usefully be clarified.

Signed-off-by: NeilBrown 
---
 man2/mount.2 | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/man2/mount.2 b/man2/mount.2
index 35fdda084d61..3e5348368757 100644
--- a/man2/mount.2
+++ b/man2/mount.2
@@ -288,6 +288,12 @@ are also settable on a per-mount-point basis.
 The
 .B MS_RELATIME
 flag is also settable on a per-mount-point basis.
+Since Linux 2.6.16,
+.B MS_RDONLY
+can be set or cleared on a per-mount-point basis as well as on
+the underlying filesystem.  The mounted filesystem will only be
+writable if neither the filesystem nor the mountpoint are flagged as
+read-only.
 .\"
 .SS Remounting an existing mount
 An existing mount may be remounted by specifying
@@ -317,6 +323,10 @@ and
 arguments should match the values used in the original
 .BR mount ()
 call, except for those parameters that are being deliberately changed.
+Another exception is that
+.B MS_BIND
+has a different meaning for remount, and it should only be included if
+explicitly desired.
 
 The following
 .I mountflags
@@ -351,17 +361,20 @@ then the remount operation preserves the existing values 
of these flags
 (rather than defaulting to
 .BR MS_RELATIME ).
 
-Since Linux 2.6.26, this flag can also be used to make
+Since Linux 2.6.26, this flag can be used with
+.B MS_BIND
+to only modify the per-mount-point flags.
 .\" See https://lwn.net/Articles/281157/
-an existing bind mount read-only by specifying
+This is particularly useful for setting or clearing the "read-only"
+flag on a mount point without changing the underlying filesystem.
+Specifying
 .IR mountflags
 as:
 
 MS_REMOUNT | MS_BIND | MS_RDONLY
 
-Note that only the
-.BR MS_RDONLY
-setting of the bind mount can be changed in this manner.
+will make access through this mountpoint read-only, without affecting
+other mount points.
 .\"
 .SS Creating a bind mount
 If
-- 
2.12.2



signature.asc
Description: PGP signature

[PATCH v2 2/9] crypto: brcm - Use IPAD/OPAD constant

[Corentin Labbe]

This patch simply replace all occurrence of HMAC IPAD/OPAD value by their
define.

Signed-off-by: Corentin Labbe 
---
 drivers/crypto/bcm/cipher.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/bcm/cipher.c b/drivers/crypto/bcm/cipher.c
index cc0d5b98006e..61393dc70b0b 100644
--- a/drivers/crypto/bcm/cipher.c
+++ b/drivers/crypto/bcm/cipher.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2510,8 +2511,8 @@ static int ahash_hmac_setkey(struct crypto_ahash *ahash, 
const u8 *key,
memcpy(ctx->opad, ctx->ipad, blocksize);
 
for (index = 0; index < blocksize; index++) {
-   ctx->ipad[index] ^= 0x36;
-   ctx->opad[index] ^= 0x5c;
+   ctx->ipad[index] ^= HMAC_IPAD_VALUE;
+   ctx->opad[index] ^= HMAC_OPAD_VALUE;
}
 
flow_dump("  ipad: ", ctx->ipad, blocksize);
-- 
2.13.0

[PATCH v2 6/9] crypto: omap-sham - Use IPAD/OPAD constant

[Corentin Labbe]

This patch simply replace all occurrence of HMAC IPAD/OPAD value by their
define.

Signed-off-by: Corentin Labbe 
---
 drivers/crypto/omap-sham.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index d0b16e5e4ee5..1864a57caaa4 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define MD5_DIGEST_SIZE16
@@ -1326,8 +1327,8 @@ static int omap_sham_setkey(struct crypto_ahash *tfm, 
const u8 *key,
memcpy(bctx->opad, bctx->ipad, bs);
 
for (i = 0; i < bs; i++) {
-   bctx->ipad[i] ^= 0x36;
-   bctx->opad[i] ^= 0x5c;
+   bctx->ipad[i] ^= HMAC_IPAD_VALUE;
+   bctx->opad[i] ^= HMAC_OPAD_VALUE;
}
}
 
-- 
2.13.0

Re: [PATCH v3 0/3] Add support for the S6E3HF2 panel on TM2e board

[Hoegeun Kwon]

Dear Thierry,

Could you check these patches?
I think this patches have accumulated enough dust.
If you have a another opinion, please tell me.

Best regards,
Hoegeun

On 04/18/2017 05:40 PM, Hoegeun Kwon wrote:

Hi all,

The purpose of this patch is add support for s6e3hf2 AMOLED panel on
the TM2e board. The panel has 1600x2560 resolution in 5.65" physical
panel in the TM2e device.

The s6e3hf2 panel(5.65") is simliar to the previous s6e3ha2 panel(5.7"),
but resolution and some command message are different. So it can be
distinguished as a compatiblitiy string.

Best regards,
Hoegeun

Changes for V3:
- Remove te-gpios property in dts.
- Added Reviewed-by: Andrzej Hajda  on all patches.
- Added Reviewed-by: Inki Dae  on patch (2/3).

Changes for V2:
- Add new compatible string to "samsung,s6e3ha2.txt binding with comments.
- Fix the panel name from s6e3ha2-e to s6e3hf2

Hoegeun Kwon (3):
   dt-bindings: Add support for samsung s6e3hf2 panel
   drm/panel: s6e3ha2: Add support for s6e3hf2 panel on TM2e board
   arm64: dts: exynos: Add support for s6e3hf2 panel device on TM2e board

  .../bindings/display/panel/samsung,s6e3ha2.txt |  5 +-
  arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 11 
  drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 64 +++---
  3 files changed, 72 insertions(+), 8 deletions(-)

[PATCH v2 8/9] crypto: mediatek - Use IPAD/OPAD constant

[Corentin Labbe]

This patch simply replace all occurrence of HMAC IPAD/OPAD value by their
define.

Signed-off-by: Corentin Labbe 
---
 drivers/crypto/mediatek/mtk-sha.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/mediatek/mtk-sha.c 
b/drivers/crypto/mediatek/mtk-sha.c
index 2226f12d1c7a..5f4f845adbb8 100644
--- a/drivers/crypto/mediatek/mtk-sha.c
+++ b/drivers/crypto/mediatek/mtk-sha.c
@@ -12,6 +12,7 @@
  * Some ideas are from atmel-sha.c and omap-sham.c drivers.
  */
 
+#include 
 #include 
 #include "mtk-platform.h"
 
@@ -825,8 +826,8 @@ static int mtk_sha_setkey(struct crypto_ahash *tfm, const 
u8 *key,
memcpy(bctx->opad, bctx->ipad, bs);
 
for (i = 0; i < bs; i++) {
-   bctx->ipad[i] ^= 0x36;
-   bctx->opad[i] ^= 0x5c;
+   bctx->ipad[i] ^= HMAC_IPAD_VALUE;
+   bctx->opad[i] ^= HMAC_OPAD_VALUE;
}
 
return 0;
-- 
2.13.0

[PATCH v2 4/9] crypto: marvell - Use IPAD/OPAD constant

[Corentin Labbe]

This patch simply replace all occurrence of HMAC IPAD/OPAD value by their
define.

Signed-off-by: Corentin Labbe 
---
 drivers/crypto/marvell/hash.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
index 77c0fb936f47..e61b08566093 100644
--- a/drivers/crypto/marvell/hash.c
+++ b/drivers/crypto/marvell/hash.c
@@ -12,6 +12,7 @@
  * by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 
@@ -1164,8 +1165,8 @@ static int mv_cesa_ahmac_pad_init(struct ahash_request 
*req,
memcpy(opad, ipad, blocksize);
 
for (i = 0; i < blocksize; i++) {
-   ipad[i] ^= 0x36;
-   opad[i] ^= 0x5c;
+   ipad[i] ^= HMAC_IPAD_VALUE;
+   opad[i] ^= HMAC_OPAD_VALUE;
}
 
return 0;
-- 
2.13.0

[PATCH v2 0/9] crypto: add HMAC IPAD/OPAD constant

[Corentin Labbe]

Hello

Many HMAC users directly use directly 0x36/0x5c values.
It's better with crypto to use a name instead of directly some crypto constant.

Changes since v1:
- Moved constant to include/crypto/hmac.h
- Added  to includes

Corentin Labbe (9):
  crypto: add hmac IPAD/OPAD constant
  crypto: brcm - Use IPAD/OPAD constant
  crypto: ixp4xx - Use IPAD/OPAD constant
  crypto: marvell - Use IPAD/OPAD constant
  crypto: mv_cesa - Use IPAD/OPAD constant
  crypto: omap-sham - Use IPAD/OPAD constant
  crypto: qat - Use IPAD/OPAD constant
  crypto: mediatek - Use IPAD/OPAD constant
  crypto: ccp - Use IPAD/OPAD constant

 crypto/hmac.c| 5 +++--
 drivers/crypto/bcm/cipher.c  | 5 +++--
 drivers/crypto/ccp/ccp-crypto-sha.c  | 5 +++--
 drivers/crypto/ixp4xx_crypto.c   | 3 +--
 drivers/crypto/marvell/hash.c| 5 +++--
 drivers/crypto/mediatek/mtk-sha.c| 5 +++--
 drivers/crypto/mv_cesa.c | 5 +++--
 drivers/crypto/omap-sham.c   | 5 +++--
 drivers/crypto/qat/qat_common/qat_algs.c | 5 +++--
 include/crypto/hmac.h| 7 +++
 10 files changed, 32 insertions(+), 18 deletions(-)
 create mode 100644 include/crypto/hmac.h

-- 
2.13.0

Re: [greybus-dev] [PATCH] staging: greybus: mark PM functions as __maybe_unused

[Arnd Bergmann]

On Fri, May 19, 2017 at 5:40 AM, Viresh Kumar  wrote:
> On 18-05-17, 16:51, Arnd Bergmann wrote:
>> I find that a lot of users get the #ifdef wrong, either using the wrong
>> macro (CONFIG_PM vs CONFIG_PM_SLEEP) or not using the right
>> set of functions (e.g. calling a function only from the suspend handler).
>>
>> The __maybe_unused annotation avoids both problems and also gives
>> better build time coverage, so that's what I tend to use.
>
> Thanks for the explanation Arnd. I hope these unused routines will not
> be part of the binary that gets generated. Right?

Correct. Ancient compilers (gcc-4.1) had a bug where a function would
still be part of the binary if the only reference to it was from a function
pointer that got dropped through dead code elimination, but that is not
the case here, and those old compilers are not used in real life any more
either.

   Arnd

[PATCH v2 3/9] crypto: ixp4xx - Use IPAD/OPAD constant

[Corentin Labbe]

This patch simply replace all occurrence of HMAC IPAD/OPAD value by their
define.

Signed-off-by: Corentin Labbe 
---
 drivers/crypto/ixp4xx_crypto.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/crypto/ixp4xx_crypto.c b/drivers/crypto/ixp4xx_crypto.c
index 771dd26c7076..427cbe012729 100644
--- a/drivers/crypto/ixp4xx_crypto.c
+++ b/drivers/crypto/ixp4xx_crypto.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -90,8 +91,6 @@
 #define CTL_FLAG_PERFORM_AEAD  0x0008
 #define CTL_FLAG_MASK  0x000f
 
-#define HMAC_IPAD_VALUE   0x36
-#define HMAC_OPAD_VALUE   0x5C
 #define HMAC_PAD_BLOCKLEN SHA1_BLOCK_SIZE
 
 #define MD5_DIGEST_SIZE   16
-- 
2.13.0

Re: [PATCH 21/30] men-chameleon-bus.txt: standardize document format

[Johannes Thumshirn]

On 05/19/2017 03:24 AM, Mauro Carvalho Chehab wrote:
> Each text file under Documentation follows a different
> format. Some doesn't even have titles!
>
> Change its representation to follow the adopted standard,
> using ReST markups for it to be parseable by Sphinx:
>
> - Adjust identations;
> - Remove title numbering;
> - mark literal blocks;
> - comment its TOC.
>
> Signed-off-by: Mauro Carvalho Chehab 
> ---
Looks good,
Acked-by: Johannes Thumshirn 

[PATCH v2 9/9] crypto: ccp - Use IPAD/OPAD constant

[Corentin Labbe]

This patch simply replace all occurrence of HMAC IPAD/OPAD value by their
define.

Signed-off-by: Corentin Labbe 
---
 drivers/crypto/ccp/ccp-crypto-sha.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/ccp/ccp-crypto-sha.c 
b/drivers/crypto/ccp/ccp-crypto-sha.c
index 6b46eea94932..ce97b3868f4a 100644
--- a/drivers/crypto/ccp/ccp-crypto-sha.c
+++ b/drivers/crypto/ccp/ccp-crypto-sha.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -308,8 +309,8 @@ static int ccp_sha_setkey(struct crypto_ahash *tfm, const 
u8 *key,
}
 
for (i = 0; i < block_size; i++) {
-   ctx->u.sha.ipad[i] = ctx->u.sha.key[i] ^ 0x36;
-   ctx->u.sha.opad[i] = ctx->u.sha.key[i] ^ 0x5c;
+   ctx->u.sha.ipad[i] = ctx->u.sha.key[i] ^ HMAC_IPAD_VALUE;
+   ctx->u.sha.opad[i] = ctx->u.sha.key[i] ^ HMAC_OPAD_VALUE;
}
 
sg_init_one(>u.sha.opad_sg, ctx->u.sha.opad, block_size);
-- 
2.13.0

[PATCH v2 5/9] crypto: mv_cesa - Use IPAD/OPAD constant

[Corentin Labbe]

This patch simply replace all occurrence of HMAC IPAD/OPAD value by their
define.

Signed-off-by: Corentin Labbe 
---
 drivers/crypto/mv_cesa.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 451fa18c1c7b..bf25f415eea6 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -822,8 +823,8 @@ static int mv_hash_setkey(struct crypto_ahash *tfm, const 
u8 * key,
memcpy(opad, ipad, bs);
 
for (i = 0; i < bs; i++) {
-   ipad[i] ^= 0x36;
-   opad[i] ^= 0x5c;
+   ipad[i] ^= HMAC_IPAD_VALUE;
+   opad[i] ^= HMAC_OPAD_VALUE;
}
 
rc = crypto_shash_init(shash) ? :
-- 
2.13.0

[PATCH v2] staging: iio: light: Replace symbolic permissions as per coding style

[surenderpolsani]

From: Surender Polsani 

Fixed the following checkpatch.pl warnings:
octal permissions are more preferable than symbolic permissions

Replaced DEVICE_ATTR family macros with DEVICE_ATTR_RW family
as suggested by Greg K-H. Changed attributes and function
names where ever required to satisfy internal macro definitions
like __ATTR__RW().

Signed-off-by: Surender Polsani 
---
Changes for v2:

- Made few changes as suggested by Greg K-H and modified
  description accordingly.
---
 drivers/staging/iio/light/tsl2x7x_core.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x_core.c 
b/drivers/staging/iio/light/tsl2x7x_core.c
index af3910b..c63fe6a 100644
--- a/drivers/staging/iio/light/tsl2x7x_core.c
+++ b/drivers/staging/iio/light/tsl2x7x_core.c
@@ -1498,34 +1498,34 @@ static int tsl2x7x_write_raw(struct iio_dev *indio_dev,
return 0;
 }
 
-static DEVICE_ATTR(power_state, S_IRUGO | S_IWUSR,
+static DEVICE_ATTR(power_state, 0644,
tsl2x7x_power_state_show, tsl2x7x_power_state_store);
 
-static DEVICE_ATTR(in_proximity0_calibscale_available, S_IRUGO,
+static DEVICE_ATTR(in_proximity0_calibscale_available, 0444,
tsl2x7x_prox_gain_available_show, NULL);
 
-static DEVICE_ATTR(in_illuminance0_calibscale_available, S_IRUGO,
+static DEVICE_ATTR(in_illuminance0_calibscale_available, 0444,
tsl2x7x_gain_available_show, NULL);
 
-static DEVICE_ATTR(in_illuminance0_integration_time, S_IRUGO | S_IWUSR,
+static DEVICE_ATTR(in_illuminance0_integration_time, 0644,
tsl2x7x_als_time_show, tsl2x7x_als_time_store);
 
-static DEVICE_ATTR(in_illuminance0_target_input, S_IRUGO | S_IWUSR,
+static DEVICE_ATTR(in_illuminance0_target_input, 0644,
tsl2x7x_als_cal_target_show, tsl2x7x_als_cal_target_store);
 
-static DEVICE_ATTR(in_illuminance0_calibrate, S_IWUSR, NULL,
+static DEVICE_ATTR(in_illuminance0_calibrate, 0200, NULL,
tsl2x7x_do_calibrate);
 
-static DEVICE_ATTR(in_proximity0_calibrate, S_IWUSR, NULL,
+static DEVICE_ATTR(in_proximity0_calibrate, 0200, NULL,
tsl2x7x_do_prox_calibrate);
 
-static DEVICE_ATTR(in_illuminance0_lux_table, S_IRUGO | S_IWUSR,
+static DEVICE_ATTR(in_illuminance0_lux_table, 0644,
tsl2x7x_luxtable_show, tsl2x7x_luxtable_store);
 
-static DEVICE_ATTR(in_intensity0_thresh_period, S_IRUGO | S_IWUSR,
+static DEVICE_ATTR(in_intensity0_thresh_period, 0644,
tsl2x7x_als_persistence_show, tsl2x7x_als_persistence_store);
 
-static DEVICE_ATTR(in_proximity0_thresh_period, S_IRUGO | S_IWUSR,
+static DEVICE_ATTR(in_proximity0_thresh_period, 0644,
tsl2x7x_prox_persistence_show, tsl2x7x_prox_persistence_store);
 
 /* Use the default register values to identify the Taos device */
-- 
1.9.1

[PATCH 0/4] net-next: stmmac: rework the speed selection

[Corentin Labbe]

Hello

The current stmmac_adjust_link() part which handle speed have
some if (has_platform) code and my dwmac-sun8i will add more of them.

So we need to handle better speed selection.
Moreover the struct link member speed and port are hard to guess their
purpose. And their unique usage are to be combined for writing speed.

My first try was to create an adjust_link() in stmmac_ops but it duplicate some 
code

The current solution is to have direct value for 10/100/1000 and a mask for 
them.

The first 3 patchs fix some minor problem found in stmmac_adjust_link() and 
reported by Florian Fainelli in my previous serie.
The last patch is the real work.

This serie is tested on cubieboard2 (dwmac1000) and opipc (dwmac-sun8i).

Regards

Corentin Labbe (4):
  net-next: stmmac: Convert new_state to bool
  net-next: stmmac: Remove unnecessary parenthesis
  net-next: stmmac: use SPEED_xxx instead of raw value
  net-next: stmmac: rework the speed selection

 drivers/net/ethernet/stmicro/stmmac/common.h   |  8 +++---
 .../net/ethernet/stmicro/stmmac/dwmac1000_core.c   | 26 ++
 .../net/ethernet/stmicro/stmmac/dwmac100_core.c|  6 +++--
 drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c  | 26 ++
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c  | 31 +++---
 5 files changed, 48 insertions(+), 49 deletions(-)

-- 
2.13.0

[PATCH v4 4/6] ARM: sun8i: a83t: Add CCU device nodes

[Chen-Yu Tsai]

Now that we have support for the A83T CCU, add a device node for it,
and replace any existing placeholder clock phandles with the correct
ones.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index c0a1e4f74b89..c9a5d07b2ada 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -162,13 +162,23 @@
#size-cells = <1>;
ranges;
 
+   ccu: clock@1c2 {
+   compatible = "allwinner,sun8i-a83t-ccu";
+   reg = <0x01c2 0x400>;
+   clocks = <>, <>;
+   clock-names = "hosc", "losc";
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+   };
+
pio: pinctrl@1c20800 {
compatible = "allwinner,sun8i-a83t-pinctrl";
interrupts = ,
 ,
 ;
reg = <0x01c20800 0x400>;
-   clocks = <>;
+   clocks = < 45>, <>, <>;
+   clock-names = "apb", "hosc", "losc";
gpio-controller;
interrupt-controller;
#interrupt-cells = <3>;
@@ -214,7 +224,8 @@
interrupts = ;
reg-shift = <2>;
reg-io-width = <4>;
-   clocks = <>;
+   clocks = < 53>;
+   resets = < 40>;
status = "disabled";
};
 
-- 
2.11.0

[PATCH v4 0/6] clk: sunxi-ng: Add support for A83T CCU

[Chen-Yu Tsai]

Hi everyone,

This is v4 of my A83T CCU series. This is for 4.13.

Changes since v3:

  - Dropped predivider for new timing mode on mmc2 clock. Replaced with
a TODO note for new timing mode support. This is the last trace of
new timing mode code.

  - Simplified PLL_CPUx clocks into multiplier clocks, just like we did
for the A80. At probe time the extra P dividers are forced to /1.
These P dividers should only be used for clock rates under 288 MHz,
and never used by the boot loader or the BSP kernel.

Changes since v2:

  - Dropped patches "clk: Provide option to query hardware for clk phase"
and "clk: sunxi-ng: Add class of phase clocks supporting MMC new timing
modes".

  - Dropped support for MMC new timing mode. This will be added later with
MMC support. The goal for this series is to get clk support for the A83t
in. This is long overdue.

  - Explicitly include ccu_mux.h and select SUNXI_CCU_MUX

Changes since v1:

  - Dropped two patches that were merged

  - Added clk core flag to disable caching of clock phases

  - Added support for multiple variable pre-dividers

  - Merged "pll-periph-ahb1" pre-divider clock into "ahb1" clock
with multiple variable pre-dividers

  - Introduced new class of phase clocks that return -ENOTSUPP
when the clock is in new timing mode

  - Force mmc2 clock to new timing mode

  - Added back mmc2 output and sample clocks

  - Fixed bit ops for forcing audio PLL configuration

  - Added requirement for "losc" clock in device tree binding

  - Stripped leading 0 in device node name

  - Updated subject prefixes for various patches

Patch 1 adds a compatible string for the A83T CCU to the sunxi-ccu
bindings.

Patch 2 adds support for multiple variable pre-dividers to the sunxi-ng
mux class.

Patch 3 adds the driver for the A83T CCU.

Patch 4 adds the CCU device nodes, and fixes up any existing clock
phandles in the dtsi, without using the macros.

Patch 5 sets the clock accuracy for the main oscillator.

Patch 6 is for the next -rc2, switch the clock indices from raw numbers
to macros we introduced with the driver. This will be updated if more
peripherals are introduced in the same cycle.

Let me know what you think.

Cover letter excerpt from v1:

This is yet another series that adds support for the A83T CCU.
The A83T CCU has a mix of new styled (like the A80) clocks at
old (like A3x) offsets. Some differences include:

  - D1/D2 style PLL clocks
  - divisible audio module clocks
  - new timing mode for mmc2 module clock


Regards
ChenYu


Chen-Yu Tsai (6):
  dt-bindings: clock: sunxi-ccu: Add compatible string for A83T CCU
  clk: sunxi-ng: Support multiple variable pre-dividers
  clk: sunxi-ng: Add driver for A83T CCU
  ARM: sun8i: a83t: Add CCU device nodes
  ARM: sun8i: a83t: Set clock accuracy for 24MHz oscillator
  ARM: sun8i: a83t: Switch to CCU device tree binding macros

 .../devicetree/bindings/clock/sunxi-ccu.txt|   2 +
 arch/arm/boot/dts/sun8i-a83t.dtsi  |  19 +-
 drivers/clk/sunxi-ng/Kconfig   |  11 +
 drivers/clk/sunxi-ng/Makefile  |   1 +
 drivers/clk/sunxi-ng/ccu-sun50i-a64.c  |  10 +-
 drivers/clk/sunxi-ng/ccu-sun6i-a31.c   |  10 +-
 drivers/clk/sunxi-ng/ccu-sun8i-a23.c   |  10 +-
 drivers/clk/sunxi-ng/ccu-sun8i-a33.c   |  10 +-
 drivers/clk/sunxi-ng/ccu-sun8i-a83t.c  | 922 +
 drivers/clk/sunxi-ng/ccu-sun8i-a83t.h  |  64 ++
 drivers/clk/sunxi-ng/ccu-sun8i-h3.c|  10 +-
 drivers/clk/sunxi-ng/ccu-sun8i-r.c |  10 +-
 drivers/clk/sunxi-ng/ccu-sun8i-v3s.c   |  10 +-
 drivers/clk/sunxi-ng/ccu_mux.c |  15 +-
 drivers/clk/sunxi-ng/ccu_mux.h |  13 +-
 include/dt-bindings/clock/sun8i-a83t-ccu.h | 140 
 include/dt-bindings/reset/sun8i-a83t-ccu.h |  98 +++
 17 files changed, 1306 insertions(+), 49 deletions(-)
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-a83t.h
 create mode 100644 include/dt-bindings/clock/sun8i-a83t-ccu.h
 create mode 100644 include/dt-bindings/reset/sun8i-a83t-ccu.h

-- 
2.11.0

[PATCH v4 2/6] clk: sunxi-ng: Support multiple variable pre-dividers

[Chen-Yu Tsai]

On the A83T, the AHB1 clock has a shared pre-divider on the two
PLL-PERIPH clock parents. To support such instances of shared
pre-dividers, this patch extends the mux clock type to support
multiple variable pre-dividers.

As the pre-dividers are only used to calculate the rate, but
do not participate in the factorization process, this is fairly
straightforward.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 10 +-
 drivers/clk/sunxi-ng/ccu-sun6i-a31.c  | 10 +-
 drivers/clk/sunxi-ng/ccu-sun8i-a23.c  | 10 +-
 drivers/clk/sunxi-ng/ccu-sun8i-a33.c  | 10 +-
 drivers/clk/sunxi-ng/ccu-sun8i-h3.c   | 10 +-
 drivers/clk/sunxi-ng/ccu-sun8i-r.c| 10 +-
 drivers/clk/sunxi-ng/ccu-sun8i-v3s.c  | 10 +-
 drivers/clk/sunxi-ng/ccu_mux.c| 15 ---
 drivers/clk/sunxi-ng/ccu_mux.h| 13 -
 9 files changed, 51 insertions(+), 47 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c 
b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index f54114c607df..2bb4cabf802f 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -211,6 +211,9 @@ static SUNXI_CCU_M(axi_clk, "axi", "cpux", 0x050, 0, 2, 0);
 
 static const char * const ahb1_parents[] = { "osc32k", "osc24M",
 "axi", "pll-periph0" };
+static const struct ccu_mux_var_prediv ahb1_predivs[] = {
+   { .index = 3, .shift = 6, .width = 2 },
+};
 static struct ccu_div ahb1_clk = {
.div= _SUNXI_CCU_DIV_FLAGS(4, 2, CLK_DIVIDER_POWER_OF_TWO),
 
@@ -218,11 +221,8 @@ static struct ccu_div ahb1_clk = {
.shift  = 12,
.width  = 2,
 
-   .variable_prediv= {
-   .index  = 3,
-   .shift  = 6,
-   .width  = 2,
-   },
+   .var_predivs= ahb1_predivs,
+   .n_var_predivs  = ARRAY_SIZE(ahb1_predivs),
},
 
.common = {
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c 
b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
index df97e25aec76..4d6078fca9ac 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
@@ -195,6 +195,9 @@ static SUNXI_CCU_DIV_TABLE(axi_clk, "axi", "cpu",
 
 static const char * const ahb1_parents[] = { "osc32k", "osc24M",
 "axi", "pll-periph" };
+static const struct ccu_mux_var_prediv ahb1_predivs[] = {
+   { .index = 3, .shift = 6, .width = 2 },
+};
 
 static struct ccu_div ahb1_clk = {
.div= _SUNXI_CCU_DIV_FLAGS(4, 2, CLK_DIVIDER_POWER_OF_TWO),
@@ -203,11 +206,8 @@ static struct ccu_div ahb1_clk = {
.shift  = 12,
.width  = 2,
 
-   .variable_prediv= {
-   .index  = 3,
-   .shift  = 6,
-   .width  = 2,
-   },
+   .var_predivs= ahb1_predivs,
+   .n_var_predivs  = ARRAY_SIZE(ahb1_predivs),
},
 
.common = {
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a23.c 
b/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
index 5c6d37bdf247..8a753ed0426d 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
@@ -169,6 +169,9 @@ static SUNXI_CCU_M(axi_clk, "axi", "cpux", 0x050, 0, 2, 0);
 
 static const char * const ahb1_parents[] = { "osc32k", "osc24M",
 "axi" , "pll-periph" };
+static const struct ccu_mux_var_prediv ahb1_predivs[] = {
+   { .index = 3, .shift = 6, .width = 2 },
+};
 static struct ccu_div ahb1_clk = {
.div= _SUNXI_CCU_DIV_FLAGS(4, 2, CLK_DIVIDER_POWER_OF_TWO),
 
@@ -176,11 +179,8 @@ static struct ccu_div ahb1_clk = {
.shift  = 12,
.width  = 2,
 
-   .variable_prediv= {
-   .index  = 3,
-   .shift  = 6,
-   .width  = 2,
-   },
+   .var_predivs= ahb1_predivs,
+   .n_var_predivs  = ARRAY_SIZE(ahb1_predivs),
},
 
.common = {
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c 
b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
index 8d38e6510e29..10b38dc46f75 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
@@ -180,6 +180,9 @@ static SUNXI_CCU_M(axi_clk, "axi", "cpux", 0x050, 0, 2, 0);
 
 static const char * const ahb1_parents[] = { "osc32k", "osc24M",
 "axi" , "pll-periph" };
+static const struct ccu_mux_var_prediv ahb1_predivs[] = {
+   { .index = 3, .shift = 6, .width = 2 },
+};
 static struct ccu_div ahb1_clk = {
.div= _SUNXI_CCU_DIV_FLAGS(4, 2, CLK_DIVIDER_POWER_OF_TWO),
 
@@ -187,11 +190,8 @@ static struct ccu_div ahb1_clk = {
 

[PATCH 1/4] net-next: stmmac: Convert new_state to bool

[Corentin Labbe]

This patch convert new_state from int to bool since it store only 1 or 0

Signed-off-by: Corentin Labbe 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 1da17cd519f6..2b778f63d1d5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -785,7 +785,7 @@ static void stmmac_adjust_link(struct net_device *dev)
struct stmmac_priv *priv = netdev_priv(dev);
struct phy_device *phydev = dev->phydev;
unsigned long flags;
-   int new_state = 0;
+   bool new_state = 0;
 
if (!phydev)
return;
-- 
2.13.0

[PATCH v4 1/6] dt-bindings: clock: sunxi-ccu: Add compatible string for A83T CCU

[Chen-Yu Tsai]

The A83T clock control unit is a hybrid of some new style clock designs
from the A80, and old style layout from the other Allwinner SoCs.

Like the A80, the SoC does not have a low speed 32.768 kHz oscillator.
Unlike the A80, there is no clock input either. The only low speed clock
available is the internal oscillator which runs at around 16 MHz,
divided by 512, yielding a low speed clock around 31.250 kHz.

Signed-off-by: Chen-Yu Tsai 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/clock/sunxi-ccu.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt 
b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
index e9c5a1d9834a..34b2a9249a94 100644
--- a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
@@ -6,6 +6,7 @@ Required properties :
- "allwinner,sun6i-a31-ccu"
- "allwinner,sun8i-a23-ccu"
- "allwinner,sun8i-a33-ccu"
+   - "allwinner,sun8i-a83t-ccu"
- "allwinner,sun8i-h3-ccu"
- "allwinner,sun8i-h3-r-ccu"
- "allwinner,sun8i-v3s-ccu"
@@ -18,6 +19,7 @@ Required properties :
 - clocks: phandle to the oscillators feeding the CCU. Two are needed:
   - "hosc": the high frequency oscillator (usually at 24MHz)
   - "losc": the low frequency oscillator (usually at 32kHz)
+   On the A83T, this is the internal 16MHz oscillator divided by 512
 - clock-names: Must contain the clock names described just above
 - #clock-cells : must contain 1
 - #reset-cells : must contain 1
-- 
2.11.0

Re: [dm-devel] [PATCH v7 0/2] dm: boot a mapped device without an initramfs

[Enric Balletbo Serra]

Hi,

2017-05-18 18:29 GMT+02:00 Enric Balletbo i Serra
:
> Dear all,
>
> So here is a new version of the patches to be reviewed, this time as
> suggested by Alasdair the patches are reworked to match with the new
> dmsetup bootformat feature [1]. These patches are not reviewed yet but
> the format was discussed in the IRC and was suggested to send the
> kernel patches in parallel.
>
> Changes since v6:
>  - Add a new function to issue the equivalent of a DM ioctl programatically.
>  - Use the new ioctl interface to create the devices.
>  - Use a comma-delimited and semi-colon delimited dmsetup-like commands.
>
> Changes since v5:
>  - https://www.redhat.com/archives/dm-devel/2016-February/msg00112.html
>
> [1] https://www.redhat.com/archives/linux-lvm/2017-May/msg00047.html
>
> Wating for your feedback,
>
> Enric Balletbo i Serra (1):
>   dm ioctl: add a device mapper ioctl function.
>
> Will Drewry (1):
>   init: add support to directly boot to a mapped device
>
>  Documentation/admin-guide/kernel-parameters.rst |   1 +
>  Documentation/admin-guide/kernel-parameters.txt |   3 +
>  Documentation/device-mapper/dm-boot.txt |  65 
>  drivers/md/dm-ioctl.c   |  45 +++
>  include/linux/device-mapper.h   |   6 +
>  init/Makefile   |   1 +
>  init/do_mounts.c|   1 +
>  init/do_mounts.h|  10 +
>  init/do_mounts_dm.c | 459 
> 
>  9 files changed, 591 insertions(+)
>  create mode 100644 Documentation/device-mapper/dm-boot.txt
>  create mode 100644 init/do_mounts_dm.c
>
> --
> 2.9.3
>
> --
> dm-devel mailing list
> dm-de...@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel

Rebasing the patches against current linux-next I just noticied that
there is a build error due commit

commit e516db4f676ac88c7c7f698f8047178e8accc3b8
Author: Mikulas Patocka 
Date:   Fri May 5 11:12:52 2017 -0700

dm ioctl: add a new DM_DEV_ARM_POLL ioctl

So I'll send v8 to fix this.

Best regards,
  Enric

[PATCH v2 3/3] ACPI / EC: Fix media keys not working problem on some Asus laptops

[Lv Zheng]

From: Chris Chiu 

Some Asus laptops (verified on X550VXK/FX502VD/FX502VE) get no
interrupts when pressing media keys thus the corresponding functions
are not invoked. It's due to the _GPE defines in DSDT for EC returns
differnt value compared to the GPE Number in ECDT. Confirmed with Asus
that the vale in ECDT is the correct one. This commit use a DMI quirk
to prevent calling _GPE when doing ec_parse_device() and keep the ECDT
GPE number setting for the EC device.

Link: https://phabricator.endlessm.com/T16033
  https://phabricator.endlessm.com/T16722
Link: https://bugzilla.kernel.org/show_bug.cgi?id=195651
Tested-by: Daniel Drake 
Signed-off-by: Chris Chiu 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/ec.c | 50 --
 1 file changed, 44 insertions(+), 6 deletions(-)

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index e232a1c..b6d28ef 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -190,6 +190,7 @@ static struct workqueue_struct *ec_query_wq;
 
 static int EC_FLAGS_QUERY_HANDSHAKE; /* Needs QR_EC issued when SCI_EVT set */
 static int EC_FLAGS_CORRECT_ECDT; /* Needs ECDT port address correction */
+static int EC_FLAGS_IGNORE_DSDT_GPE; /* Needs ECDT GPE as correction setting */
 
 /* --
  *   Logging/Debugging
@@ -1371,12 +1372,21 @@ ec_parse_device(acpi_handle handle, u32 Level, void 
*context, void **retval)
if (ec->data_addr == 0 || ec->command_addr == 0)
return AE_OK;
 
-   /* Get GPE bit assignment (EC events). */
-   /* TODO: Add support for _GPE returning a package */
-   status = acpi_evaluate_integer(handle, "_GPE", NULL, );
-   if (ACPI_FAILURE(status))
-   return status;
-   ec->gpe = tmp;
+   if (boot_ec && EC_FLAGS_IGNORE_DSDT_GPE) {
+   /*
+* First boot_ec is always ECDT EC.
+* Always inherit the GPE number setting from the first
+* boot_ec.
+*/
+   ec->gpe = boot_ec->gpe;
+   } else {
+   /* Get GPE bit assignment (EC events). */
+   /* TODO: Add support for _GPE returning a package */
+   status = acpi_evaluate_integer(handle, "_GPE", NULL, );
+   if (ACPI_FAILURE(status))
+   return status;
+   ec->gpe = tmp;
+   }
/* Use the global lock for all EC transactions? */
tmp = 0;
acpi_evaluate_integer(handle, "_GLK", NULL, );
@@ -1769,11 +1779,39 @@ static int ec_correct_ecdt(const struct dmi_system_id 
*id)
return 0;
 }
 
+/*
+ * Some DSDTs contain wrong GPE setting.
+ * Asus FX502VD/VE, X550VXK, X580VD
+ * Link: https://bugzilla.kernel.org/show_bug.cgi?id=195651
+ */
+static int ec_honor_ecdt_gpe(const struct dmi_system_id *id)
+{
+   pr_debug("Detected system needing ignore DSDT GPE setting.\n");
+   EC_FLAGS_IGNORE_DSDT_GPE = 1;
+   return 0;
+}
+
 static struct dmi_system_id ec_dmi_table[] __initdata = {
{
ec_correct_ecdt, "MSI MS-171F", {
DMI_MATCH(DMI_SYS_VENDOR, "Micro-Star"),
DMI_MATCH(DMI_PRODUCT_NAME, "MS-171F"),}, NULL},
+   {
+   ec_honor_ecdt_gpe, "ASUS FX502VD", {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "FX502VD"),}, NULL},
+   {
+   ec_honor_ecdt_gpe, "ASUS FX502VE", {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "FX502VE"),}, NULL},
+   {
+   ec_honor_ecdt_gpe, "ASUS X550VXK", {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "X550VXK"),}, NULL},
+   {
+   ec_honor_ecdt_gpe, "ASUS X580VD", {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "X580VD"),}, NULL},
{},
 };
 
-- 
2.7.4

[PATCH v2 2/3] ACPI / EC: Add support to skip boot stage DSDT probe

[Lv Zheng]

Long time ago, Linux EC driver won't probe DSDT EC during boot. It was
added by the following commit (see link #1 for bug report):
  Commit: c5279dee26c0e8d7c4200993bfc4b540d2469598
  Subject: ACPI: EC: Add some basic check for ECDT data
This is wrong as the only way to know if the DSDT EC is valid is to
evaluate its _STA control method, but it's not proper to evaluate this
control method that early and out of the ACPI enumeration process.

But after we reverted back to the expected behavior, someone reported a
regression (see link #2 for reference). On that platform, there is no ECDT,
but the platform control methds access EC operation region earlier than
Linux expects. Without knowing the exact device enumeration order on
Windows, we in fact cannot conclude anything but can just follow the
regression rule to revert to old wrong behavior to probe DSDT EC at the old
position.

Now we've been reported 3rd functional breakage (link #3). The safest way
of solving it includes evaluating _STA. Due to the reason above, it is not
such safe to evaluate _STA in acpi_ec_dsdt_probe(). In order to handle both
issues (link #2 and link #3), we could just skip boot stage DSDT probe when
ECDT exists.

Note this change doesn't solve the reported problem, it can only be
resolved by a GPE setting quirk, and without this commit but with only the
GPE setting quirk, the reported problem can be solved. However, this commit
can improve our code quality by making unexpected behavior less effective.

Link: http://bugzilla.kernel.org/show_bug.cgi?id=11880 [#1]
Link: http://bugzilla.kernel.org/show_bug.cgi?id=119261 [#2]
Link: http://bugzilla.kernel.org/show_bug.cgi?id=195651 [#3]
Tested-by: Daniel Drake 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/ec.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index a920db6..e232a1c 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -1679,6 +1679,14 @@ int __init acpi_ec_dsdt_probe(void)
struct acpi_ec *ec;
int ret;
 
+   /*
+* If a platform has ECDT, there is no need to proceed as the
+* following unsafe probe is not a part of ACPI device enumeration,
+* and hence _STA is not executed.
+*/
+   if (boot_ec)
+   return -ENODEV;
+
ec = acpi_ec_alloc();
if (!ec)
return -ENOMEM;
-- 
2.7.4

[PATCH] mm/vmstat: add oom_kill counter

[Konstantin Khlebnikov]

Show count of global oom killer invocations in /proc/vmstat

Signed-off-by: Konstantin Khlebnikov 
---
 include/linux/vm_event_item.h |1 +
 mm/oom_kill.c |1 +
 mm/vmstat.c   |1 +
 3 files changed, 3 insertions(+)

diff --git a/include/linux/vm_event_item.h b/include/linux/vm_event_item.h
index d84ae90ccd5c..1707e0a7d943 100644
--- a/include/linux/vm_event_item.h
+++ b/include/linux/vm_event_item.h
@@ -41,6 +41,7 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
KSWAPD_LOW_WMARK_HIT_QUICKLY, KSWAPD_HIGH_WMARK_HIT_QUICKLY,
PAGEOUTRUN, PGROTATED,
DROP_PAGECACHE, DROP_SLAB,
+   OOM_KILL,
 #ifdef CONFIG_NUMA_BALANCING
NUMA_PTE_UPDATES,
NUMA_HUGE_PTE_UPDATES,
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 04c9143a8625..c734c42826cf 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -883,6 +883,7 @@ static void oom_kill_process(struct oom_control *oc, const 
char *message)
 */
do_send_sig_info(SIGKILL, SEND_SIG_FORCED, victim, true);
mark_oom_victim(victim);
+   count_vm_event(OOM_KILL);
pr_err("Killed process %d (%s) total-vm:%lukB, anon-rss:%lukB, 
file-rss:%lukB, shmem-rss:%lukB\n",
task_pid_nr(victim), victim->comm, K(victim->mm->total_vm),
K(get_mm_counter(victim->mm, MM_ANONPAGES)),
diff --git a/mm/vmstat.c b/mm/vmstat.c
index 76f73670200a..fe80b81a86e0 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -1018,6 +1018,7 @@ const char * const vmstat_text[] = {
 
"drop_pagecache",
"drop_slab",
+   "oom_kill",
 
 #ifdef CONFIG_NUMA_BALANCING
"numa_pte_updates",

[PATCH v2 0/3] ACPI / EC: Add quirk modes for boot EC support

[Lv Zheng]

It's reported that Asus laptop X580VD/X550VXK/FX502VD/FX502VE have a BIOS
bug where the ECDT correctly states that EC events trigger GPE 0x23, but
the DSDT _GPE method incorrectly returns GPE 0x33.

This patchset fixes this issue.

Link: https://www.spinics.net/lists/linux-acpi/msg73763.html
  https://bugzilla.kernel.org/show_bug.cgi?id=195651

v2: Stops doing craps related to EC_ID (it's already too complicated), and
reduces one unnecessary boot parameter. For the final bug fix, prefers
the fix from endlessm.com developers.

Chris Chiu (1):
  ACPI / EC: Fix media keys not working problem on some Asus laptops

Lv Zheng (2):
  ACPI / EC: Enhance boot EC sanity check
  ACPI / EC: Add support to skip boot stage DSDT probe

 drivers/acpi/ec.c | 66 ++-
 1 file changed, 60 insertions(+), 6 deletions(-)

-- 
2.7.4

[PATCH v2 1/3] ACPI / EC: Enhance boot EC sanity check

[Lv Zheng]

It's reported that some buggy BIOS tables can contain 2 DSDT ECs and one of
them is invalid. As we shouldn't evaluate _STA from acpi_ec_dsdt_probe()
due to the unknown Windows enumeration order, this patch simply enhances
sanity checks in ec_parse_device() as a workaround to skip probing wrong
namespace ECs.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=195651
Tested-by: Daniel Drake 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/ec.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index c24235d..a920db6 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -1362,6 +1362,14 @@ ec_parse_device(acpi_handle handle, u32 Level, void 
*context, void **retval)
 ec_parse_io_ports, ec);
if (ACPI_FAILURE(status))
return status;
+   /*
+* It's better to evaluate _STA to determine if the device is
+* valid. But that could potentially trigger issues related to
+* the unknown orders of _INI/_STA evaluations.
+* However we can abort due to invalid _CRS information here.
+*/
+   if (ec->data_addr == 0 || ec->command_addr == 0)
+   return AE_OK;
 
/* Get GPE bit assignment (EC events). */
/* TODO: Add support for _GPE returning a package */
-- 
2.7.4

[PATCH v4 5/6] ARM: sun8i: a83t: Set clock accuracy for 24MHz oscillator

[Chen-Yu Tsai]

The datasheets for Allwinner SoCs set strict requirements on the
stability of the external crystal oscillators. Add the accuracy
for the main 24MHz oscillator to the device tree.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index c9a5d07b2ada..e12dd7170b8f 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -126,6 +126,7 @@
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <2400>;
+   clock-accuracy = <5>;
clock-output-names = "osc24M";
};
 
-- 
2.11.0

[PATCH v4 3/6] clk: sunxi-ng: Add driver for A83T CCU

[Chen-Yu Tsai]

The A83T clock control unit is a hybrid of some new style clock designs
from the A80, and old style layout from the other Allwinner SoCs.

Like the A80, the SoC does not have a low speed 32.768 kHz oscillator.
Unlike the A80, there is no clock input either. The only low speed clock
available is the internal oscillator which runs at around 16 MHz,
divided by 512, yielding a low speed clock around 31.250 kHz.

Also, the MMC2 module clock supports switching to a "new timing" mode.
This mode divides the clock output by half, and disables the CCU based
clock delays. The MMC controller must be configure to the same mode,
and then use its internal clock delays.

This driver does not support runtime switching of the timing modes.
Instead, the new timing mode is enforced at probe time. Consumers can
check which mode is active by trying to get the current phase delay
of the MMC2 phase clocks, which will return -ENOTSUPP if the new
timing mode is active.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/clk/sunxi-ng/Kconfig   |  11 +
 drivers/clk/sunxi-ng/Makefile  |   1 +
 drivers/clk/sunxi-ng/ccu-sun8i-a83t.c  | 922 +
 drivers/clk/sunxi-ng/ccu-sun8i-a83t.h  |  64 ++
 include/dt-bindings/clock/sun8i-a83t-ccu.h | 140 +
 include/dt-bindings/reset/sun8i-a83t-ccu.h |  98 +++
 6 files changed, 1236 insertions(+)
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-a83t.h
 create mode 100644 include/dt-bindings/clock/sun8i-a83t-ccu.h
 create mode 100644 include/dt-bindings/reset/sun8i-a83t-ccu.h

diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
index b5706fc73f3e..a384c695b388 100644
--- a/drivers/clk/sunxi-ng/Kconfig
+++ b/drivers/clk/sunxi-ng/Kconfig
@@ -116,6 +116,17 @@ config SUN8I_A33_CCU
default MACH_SUN8I
depends on MACH_SUN8I || COMPILE_TEST
 
+config SUN8I_A83T_CCU
+   bool "Support for the Allwinner A83T CCU"
+   select SUNXI_CCU_DIV
+   select SUNXI_CCU_GATE
+   select SUNXI_CCU_MP
+   select SUNXI_CCU_MUX
+   select SUNXI_CCU_NKMP
+   select SUNXI_CCU_NM
+   select SUNXI_CCU_PHASE
+   default MACH_SUN8I
+
 config SUN8I_H3_CCU
bool "Support for the Allwinner H3 CCU"
select SUNXI_CCU_DIV
diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
index be616279450e..0185c6ffadcb 100644
--- a/drivers/clk/sunxi-ng/Makefile
+++ b/drivers/clk/sunxi-ng/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_SUN5I_CCU)   += ccu-sun5i.o
 obj-$(CONFIG_SUN6I_A31_CCU)+= ccu-sun6i-a31.o
 obj-$(CONFIG_SUN8I_A23_CCU)+= ccu-sun8i-a23.o
 obj-$(CONFIG_SUN8I_A33_CCU)+= ccu-sun8i-a33.o
+obj-$(CONFIG_SUN8I_A83T_CCU)   += ccu-sun8i-a83t.o
 obj-$(CONFIG_SUN8I_H3_CCU) += ccu-sun8i-h3.o
 obj-$(CONFIG_SUN8I_V3S_CCU)+= ccu-sun8i-v3s.o
 obj-$(CONFIG_SUN8I_DE2_CCU)+= ccu-sun8i-de2.o
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c 
b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
new file mode 100644
index ..4a201a7e03b8
--- /dev/null
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
@@ -0,0 +1,922 @@
+/*
+ * Copyright (c) 2017 Chen-Yu Tsai. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+
+#include "ccu_common.h"
+#include "ccu_reset.h"
+
+#include "ccu_div.h"
+#include "ccu_gate.h"
+#include "ccu_mp.h"
+#include "ccu_mux.h"
+#include "ccu_nkmp.h"
+#include "ccu_nm.h"
+#include "ccu_phase.h"
+
+#include "ccu-sun8i-a83t.h"
+
+#define CCU_SUN8I_A83T_LOCK_REG0x208
+
+/*
+ * The CPU PLLs are actually NP clocks, with P being /1 or /4. However
+ * P should only be used for output frequencies lower than 228 MHz.
+ * Neither mainline Linux, U-boot, nor the vendor BSPs use these.
+ *
+ * For now we can just model it as a multiplier clock, and force P to /1.
+ */
+#define SUN8I_A83T_PLL_C0CPUX_REG  0x000
+#define SUN8I_A83T_PLL_C1CPUX_REG  0x004
+
+static struct ccu_mult pll_c0cpux_clk = {
+   .enable = BIT(31),
+   .lock   = BIT(0),
+   .mult   = _SUNXI_CCU_MULT_OFFSET_MIN_MAX(8, 8, 0, 12, 0),
+   .common = {
+   .reg= SUN8I_A83T_PLL_C0CPUX_REG,
+   .lock_reg   = CCU_SUN8I_A83T_LOCK_REG,
+   .features   = CCU_FEATURE_LOCK_REG,
+   .hw.init= CLK_HW_INIT("pll-c0cpux", "osc24M",
+ _mult_ops,
+ 

[PATCH v4 6/6] ARM: sun8i: a83t: Switch to CCU device tree binding macros

[Chen-Yu Tsai]

Now that the CCU device tree binding headers have been merged, we can
use the properly named macros in the device tree, instead of raw
numbers.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index e12dd7170b8f..050d3e347740 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -44,6 +44,9 @@
 
 #include 
 
+#include 
+#include 
+
 / {
interrupt-parent = <>;
#address-cells = <1>;
@@ -178,7 +181,7 @@
 ,
 ;
reg = <0x01c20800 0x400>;
-   clocks = < 45>, <>, <>;
+   clocks = < CLK_BUS_PIO>, <>, <>;
clock-names = "apb", "hosc", "losc";
gpio-controller;
interrupt-controller;
@@ -225,8 +228,8 @@
interrupts = ;
reg-shift = <2>;
reg-io-width = <4>;
-   clocks = < 53>;
-   resets = < 40>;
+   clocks = < CLK_BUS_UART0>;
+   resets = < RST_BUS_UART0>;
status = "disabled";
};
 
-- 
2.11.0

Re: [lkp-robot] [sched/cfs] 625ed2bf04: unixbench.score -7.4% regression

[Vincent Guittot]

On 19 May 2017 at 08:07, kernel test robot  wrote:
>
> Greeting,
>
> FYI, we noticed a -7.4% regression of unixbench.score due to commit:

That's interesting because it's just the opposite of what I received 4
days ago for unixbench  shell1 test. I'm going to have a look:

>From kernel test robot :

Greeting,

FYI, we noticed a 12.3% improvement of unixbench.score due to commit:


commit: 6947ec09a6a15c9c2c2bf71d7fea7c65d54f8a33 ("sched/cfs: Make
util/load_avg more stable")
https://git.kernel.org/cgit/linux/kernel/git/peterz/queue.git schd/wip

in testcase: unixbench
on test machine: 192 threads Skylake-4S with 768G memory
with following parameters:

runtime: 300s
nr_task: 1
test: shell1
cpufreq_governor: performance

test-description: UnixBench is the original BYTE UNIX benchmark suite
aims to test performance of Unix-like system.
test-url: https://github.com/kdlucas/byte-unixbench

In addition to that, the commit also has significant impact on the
following tests:

+--+---+
| testcase: change | netperf: netperf.Throughput_tps 36.1% improvement
|
| test machine | 56 threads Intel(R) Xeon(R) CPU E5-2695 v3 @
2.30GHz with 256G memory |
| test parameters  | cluster=cs-localhost
|
|  | cpufreq_governor=performance
|
|  | ip=ipv4
|
|  | nr_threads=200%
|
|  | runtime=300s
|
|  | test=SCTP_RR
|
+--+---+
| testcase: change | aim9: aim9.shell_rtns_3.ops_per_sec 1.6%
improvement  |
| test machine | 88 threads Intel(R) Xeon(R) CPU E5-2699 v4 @
2.20GHz with 64G memory  |
| test parameters  | cpufreq_governor=performance
|
|  | test=shell_rtns_3
|
|  | testtime=300s
|
+--+---+
| testcase: change | aim9: aim9.shell_rtns_1.ops_per_sec 1.4%
improvement  |
| test machine | 88 threads Intel(R) Xeon(R) CPU E5-2699 v4 @
2.20GHz with 64G memory  |
| test parameters  | cpufreq_governor=performance
|
|  | test=shell_rtns_1
|
|  | testtime=300s
|
+--+---+

--




>
>
> commit: 625ed2bf049d5a352c1bcca962d6e133454eaaff ("sched/cfs: Make 
> util/load_avg more stable")
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
>
> in testcase: unixbench
> on test machine: 88 threads Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz with 
> 64G memory
> with following parameters:
>
> runtime: 300s
> nr_task: 100%
> test: spawn
> cpufreq_governor: performance
>
> test-description: UnixBench is the original BYTE UNIX benchmark suite aims to 
> test performance of Unix-like system.
> test-url: https://github.com/kdlucas/byte-unixbench
>
>
>
> Details are as below:
> -->
>
>
> To reproduce:
>
> git clone https://github.com/01org/lkp-tests.git
> cd lkp-tests
> bin/lkp install job.yaml  # job file is attached in this email
> bin/lkp run job.yaml
>
> testcase/path_params/tbox_group/run: 
> unixbench/300s-100%-spawn-performance/lkp-bdw-ep3b
>
> 8663effb24f94303  625ed2bf049d5a352c1bcca962
>   --
>  %stddev  change %stddev
>  \  |\
>     -7%   8234unixbench.score
>  11626  31%  15267unixbench.time.system_time
>   5084  23%   6259
> unixbench.time.percent_of_cpu_this_job_got
>   5203   5%   5455unixbench.time.user_time
>   66039778  -7%   61588314
> unixbench.time.voluntary_context_switches
>  7.932e+08  -7%   7.34e+08unixbench.time.minor_page_faults
>   24502668 -52%   11794316
> unixbench.time.involuntary_context_switches
> 628084 -17% 518637
> interrupts.CAL:Function_call_interrupts
>   6000 ą 57%  1e+04  19033 ą 58%  
> latency_stats.sum.call_rwsem_down_read_failed.__percpu_down_read.exit_signals.do_exit.do_group_exit.SyS_exit_group.entry_SYSCALL_64_fastpath
> 715117 ą 58% -4e+05 300172 ą 12%  
> 

[PATCH] lockdep: do not count lock class operations without CONFIG_DEBUG_LOCKDEP

[Konstantin Khlebnikov]

Currently this counter shown in /proc/lockdep if CONFIG_DEBUG_LOCKDEP=y
This patch disables it completely if this option is disabled.

This counter might be useful for debugging lockdep itself, but for normal
debugging it seems useless. Lockstat provides more detailed statistics.

This atomic_inc is a hot spot inside __lock_acquire() for debug kernel.

With patch "netperf -H localhost" shows some boost: 2500 -> 2600

Signed-off-by: Konstantin Khlebnikov 
---
 kernel/locking/lockdep.c |4 
 1 file changed, 4 insertions(+)

diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index c0e31bfee25c..60bd16984546 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -1375,7 +1375,9 @@ static void print_lock_class_header(struct lock_class 
*class, int depth)
 
printk("%*s->", depth, "");
print_lock_name(class);
+#ifdef CONFIG_DEBUG_LOCKDEP
printk(KERN_CONT " ops: %lu", class->ops);
+#endif
printk(KERN_CONT " {\n");
 
for (bit = 0; bit < LOCK_USAGE_STATES; bit++) {
@@ -3256,7 +3258,9 @@ static int __lock_acquire(struct lockdep_map *lock, 
unsigned int subclass,
if (!class)
return 0;
}
+#ifdef CONFIG_DEBUG_LOCKDEP
atomic_inc((atomic_t *)>ops);
+#endif
if (very_verbose(class)) {
printk("\nacquire class [%p] %s", class->key, class->name);
if (class->name_version > 1)

Re: [v2] mwifiex: pcie: de-duplicate buffer allocation code

[Kalle Valo]

Brian Norris  wrote:
> This code was duplicated as part of the PCIe FLR code added to this
> driver. Let's de-duplicate it to:
> 
>  * make things easier to read (mwifiex_pcie_free_buffers() now has a
>corresponding mwifiex_pcie_alloc_buffers())
>  * reduce likelihood of bugs
>  * make error logging equally verbose
>  * save lines of code!
> 
> Also drop some of the commentary that isn't really needed.
> 
> Signed-off-by: Brian Norris 

Patch applied to wireless-drivers-next.git, thanks.

d41bf5c1c0ed mwifiex: pcie: de-duplicate buffer allocation code

-- 
https://patchwork.kernel.org/patch/9734777/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: Make BCMA a menuconfig to ease disabling it all

[Kalle Valo]

Vincent Legoll  wrote:
> No need to get into the submenu to disable all BCMA-related config entries
> 
> Signed-off-by: Vincent Legoll 

I would like to get an ack from someone before I'll apply this.

Patch set to Deferred.

-- 
https://patchwork.kernel.org/patch/9683685/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

[lkp-robot] [waitid()] 75f64d68f9: Kernel_panic-not_syncing:Attempted_to_kill_init!exitcode=

[kernel test robot]

FYI, we noticed the following commit:

commit: 75f64d68f9816a1c244b8685f056389b24d97e98 ("waitid(): switch copyout of 
siginfo to unsafe_put_user()")
url: 
https://github.com/0day-ci/linux/commits/Al-Viro/move-compat-wait4-and-waitid-next-to-native-variants/20170516-084127


in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -smp 2 -m 512M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+--+++
|  | 3b8d2673bc 
| 75f64d68f9 |
+--+++
| boot_successes   | 8  
| 0  |
| boot_failures| 4  
| 17 |
| invoked_oom-killer:gfp_mask=0x   | 4  
||
| Mem-Info | 4  
||
| Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes | 4  
||
| Kernel_panic-not_syncing:Attempted_to_kill_init!exitcode=| 0  
| 17 |
+--+++



[   13.075040] Freeing unused kernel memory: 712K
[   13.077939] x86/mm: Checked W+X mappings: passed, no W+X pages found.
[   13.077939] x86/mm: Checked W+X mappings: passed, no W+X pages found.
[   13.087208] random: init: uninitialized urandom read (12 bytes read)
[   13.087208] random: init: uninitialized urandom read (12 bytes read)
[   13.101738] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x0600
[   13.101738] 
[   13.101738] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x0600
[   13.101738] 
[   13.103770] CPU: 0 PID: 1 Comm: init Not tainted 4.12.0-rc1-8-g75f64d6 #1
[   13.103770] CPU: 0 PID: 1 Comm: init Not tainted 4.12.0-rc1-8-g75f64d6 #1
[   13.105333] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   13.105333] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   13.107557] Call Trace:
[   13.107557] Call Trace:
[   13.108112]  dump_stack+0x27/0x31
[   13.108112]  dump_stack+0x27/0x31
[   13.108856]  panic+0x115/0x31b
[   13.108856]  panic+0x115/0x31b
[   13.109534]  do_exit+0x111d/0x1120
[   13.109534]  do_exit+0x111d/0x1120
[   13.110296]  do_group_exit+0x3d/0x110
[   13.110296]  do_group_exit+0x3d/0x110
[   13.05]  SyS_exit_group+0x24/0x30
[   13.05]  SyS_exit_group+0x24/0x30
[   13.111925]  entry_SYSCALL_64_fastpath+0x1a/0xa4
[   13.111925]  entry_SYSCALL_64_fastpath+0x1a/0xa4
[   13.112947] RIP: 0033:0x7fede11ca408
[   13.112947] RIP: 0033:0x7fede11ca408
[   13.113752] RSP: 002b:7ffe406929e8 EFLAGS: 0246 ORIG_RAX: 
00e7
[   13.113752] RSP: 002b:7ffe406929e8 EFLAGS: 0246 ORIG_RAX: 
00e7
[   13.115403] RAX: ffda RBX: 7fede217 RCX: 7fede11ca408
[   13.115403] RAX: ffda RBX: 7fede217 RCX: 7fede11ca408
[   13.116957] RDX: 0006 RSI: 003c RDI: 0006
[   13.116957] RDX: 0006 RSI: 003c RDI: 0006
[   13.118505] RBP: 7fede16d1000 R08: 00e7 R09: ffa0
[   13.118505] RBP: 7fede16d1000 R08: 00e7 R09: ffa0
[   13.120065] R10: 7fede14c5fa8 R11: 0246 R12: 00218220
[   13.120065] R10: 7fede14c5fa8 R11: 0246 R12: 00218220
[   13.121616] R13:  R14: 7fede2177048 R15: 7fede21714e8
[   13.121616] R13:  R14: 7fede2177048 R15: 7fede21714e8
[   13.123174] Kernel Offset: disabled


To reproduce:

git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.12.0-rc1 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y

Re: [01/11] mwifiex: fixup error cases in mwifiex_add_virtual_intf()

[Kalle Valo]

Brian Norris  wrote:
> If we fail to add an interface in mwifiex_add_virtual_intf(), we might
> hit a BUG_ON() in the networking code, because we didn't tear things
> down properly. Among the problems:
> 
>  (a) when failing to allocate workqueues, we fail to unregister the
>  netdev before calling free_netdev()
>  (b) even if we do try to unregister the netdev, we're still holding the
>  rtnl lock, so the device never properly unregistered; we'll be at
>  state NETREG_UNREGISTERING, and then hit free_netdev()'s:
>   BUG_ON(dev->reg_state != NETREG_UNREGISTERED);
>  (c) we're allocating some dependent resources (e.g., DFS workqueues)
>  after we've registered the interface; this may or may not cause
>  problems, but it's good practice to allocate these before registering
>  (d) we're not even trying to unwind anything when mwifiex_send_cmd() or
>  mwifiex_sta_init_cmd() fail
> 
> To fix these issues, let's:
> 
>  * add a stacked set of error handling labels, to keep error handling
>consistent and properly ordered (resolving (a) and (d))
>  * move the workqueue allocations before the registration (to resolve
>(c); also resolves (b) by avoiding error cases where we have to
>unregister)
> 
> [Incidentally, it's pretty easy to interrupt the alloc_workqueue() in,
> e.g., the following:
> 
>   iw phy phy0 interface add mlan0 type station
> 
> by sending it SIGTERM.]
> 
> This bugfix covers commits like commit 7d652034d1a0 ("mwifiex: channel
> switch support for mwifiex"), but parts of this bug exist all the way
> back to the introduction of dynamic interface handling in commit
> 93a1df48d224 ("mwifiex: add cfg80211 handlers add/del_virtual_intf").
> 
> Cc: 
> Signed-off-by: Brian Norris 

11 patches applied to wireless-drivers-next.git, thanks.

8535107aa4ef mwifiex: fixup error cases in mwifiex_add_virtual_intf()
e0b636e5ee15 mwifiex: Don't release tx_ba_stream_tbl_lock while iterating
90ad0be83676 mwifiex: Don't release cmd_pending_q_lock while iterating
09bdb6500551 mwifiex: Add locking to mwifiex_11n_delba
0f13acf0c612 mwifiex: don't drop lock between list-retrieval / list-deletion
6eb2d002d4ea mwifiex: don't leak stashed beacon buffer on reset
bc69ca391eff mwifiex: remove useless 'mwifiex_lock'
7170862738dc mwifiex: remove redundant 'adapter' check in 
mwifiex_adapter_cleanup
7ade530e7384 mwifiex: 11h: drop unnecessary check for '!priv'
fa4651e12ae8 mwifiex: pcie: remove useless pdev check
68efd0386988 mwifiex: pcie: stop setting/clearing 'surprise_removed'

-- 
https://patchwork.kernel.org/patch/9724599/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH v5 4/5] arm64: dts: exynos: Remove the OF graph from DSI node

[Hoegeun Kwon]

On 05/16/2017 01:48 AM, Krzysztof Kozlowski wrote:

On Wed, Mar 08, 2017 at 01:54:11PM +0900, Hoegeun Kwon wrote:

The OF graph is not needed because the panel is a child of dsi. Remove
the ports node in DSI node.

Signed-off-by: Hoegeun Kwon 
Reviewed-by: Andrzej Hajda 
Reviewed-by: Andi Shyti 
---
  arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 14 --
  1 file changed, 14 deletions(-)


Hi,

I wanted to apply this (and 5/5) but it seems that DRM change is not
merged. Was it included in v4.12-rc1?

Best regards,
Krzysztof


Hi,

Sorry for my belated reply.

The DRM patch(3/5) is not merged in v4.12-rc1 (mainline)...
I have checked the David's branch, but not merged.
However it was merged into Inki's exynos drm branch.

Inki, Could you check the patch(3/5).

Best regards,
Hoegeun

Re: [PATCH 1/6] kmod: add dynamic max concurrent thread count

[Dmitry Torokhov]

On Fri, May 19, 2017 at 02:45:29PM -0700, Luis R. Rodriguez wrote:
> On May 19, 2017 1:45 PM, "Dmitry Torokhov" 
> wrote:
> 
> On Thu, May 18, 2017 at 08:24:39PM -0700, Luis R. Rodriguez wrote:
> > We currently statically limit the number of modprobe threads which
> > we allow to run concurrently to 50. As per Keith Owens, this was a
> > completely arbitrary value, and it was set in the 2.3.38 days [0]
> > over 16 years ago in year 2000.
> >
> > Although we haven't yet hit our lower limits, experimentation [1]
> > shows that when and if we hit this limit in the worst case, will be
> > fatal -- consider get_fs_type() failures upon mount on a system which
> > has many partitions, some of which might even be with the same
> > filesystem. Its best to be prudent and increase and set this
> > value to something more sensible which ensures we're far from hitting
> > the limit and also allows default build/user run time override.
> >
> > The worst case is fatal given that once a module fails to load there
> > is a period of time during which subsequent request for the same module
> > will fail, so in the case of partitions its not just one request that
> > could fail, but whole series of partitions. This later issue of a
> > module request failure domino effect can be addressed later, but
> > increasing the limit to something more meaninful should at least give us
> > enough cushion to avoid this for a while.
> >
> > Set this value up with a bit more meaninful modern limits:
> >
> > Bump this up to 64  max for small systems (CONFIG_BASE_SMALL)
> > Bump this up to 128 max for larger systems (!CONFIG_BASE_SMALL)
> >
> > Also allow the default max limit to be further fine tuned at compile
> > time and at initialization at run time at boot up using the kernel
> > parameter: max_modprobes.
> >
> > [0] https://git.kernel.org/cgit/linux/kernel/git/history/
> history.git/commit/?id=ab1c4ec7410f6ec64e1511d1a7d850fc99c09b44
> > [1] https://github.com/mcgrof/test_request_module
> 
> If we actually run into this issue, instead of slamming the system with
> bazillion concurrent requests, can we wait for the other modprobes to
> finish and then continue?
> 
> 
> Yes ! That I have a patch that does precisely that ! That is actually still
> *not enough* to not fail fatally but this would be subject of another
> series with more debatable approaches.
> 

Then please post it.

> This at least pushes us to closer safer limits for now while also making it
> configurable.

Making it configurable depending on how big/little box is makes no
sense, especially if the above is implemented, as depth of modprobe
invocations depends on configuration and not computing power of the
hardware the system is running on.

Thanks.

-- 
Dmitry

Re: [PATCH] iio: light: isl29018: Only declare ACPI table when ACPI is enabled

[Guenter Roeck]

On Fri, May 19, 2017 at 2:28 PM, Matthias Kaehlcke  wrote:
> This fixes the following warning when building with clang:
>
> drivers/iio/light/isl29018.c:808:36: error: variable
> 'isl29018_acpi_match' is not needed and will not be emitted
> [-Werror,-Wunneeded-internal-declaration]
>
> Signed-off-by: Matthias Kaehlcke 

Reviewed-by: Guenter Roeck 

> ---
>  drivers/iio/light/isl29018.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/iio/light/isl29018.c b/drivers/iio/light/isl29018.c
> index 917dd8b43e72..61f5924b472d 100644
> --- a/drivers/iio/light/isl29018.c
> +++ b/drivers/iio/light/isl29018.c
> @@ -807,6 +807,7 @@ static SIMPLE_DEV_PM_OPS(isl29018_pm_ops, 
> isl29018_suspend, isl29018_resume);
>  #define ISL29018_PM_OPS NULL
>  #endif
>
> +#ifdef CONFIG_ACPI
>  static const struct acpi_device_id isl29018_acpi_match[] = {
> {"ISL29018", isl29018},
> {"ISL29023", isl29023},
> @@ -814,6 +815,7 @@ static const struct acpi_device_id isl29018_acpi_match[] 
> = {
> {},
>  };
>  MODULE_DEVICE_TABLE(acpi, isl29018_acpi_match);
> +#endif
>
>  static const struct i2c_device_id isl29018_id[] = {
> {"isl29018", isl29018},
> --
> 2.13.0.303.g4ebf302169-goog
>

Re: [PATCH 2/2] efifb: Avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 19 May 2017 at 21:44, Bjorn Helgaas  wrote:
> On Fri, May 19, 2017 at 05:37:30PM +0100, Ard Biesheuvel wrote:
>> Hi Bjorn,
>>
>> On 19 May 2017 at 17:27, Bjorn Helgaas  wrote:
>> > [+cc linux-pci]
>> >
>> > On Tue, Apr 04, 2017 at 04:27:44PM +0100, Ard Biesheuvel wrote:
>> >> On UEFI systems, the PCI subsystem is enumerated by the firmware,
>> >> and if a graphical framebuffer is exposed by a PCI device, its base
>> >> address and size are exposed to the OS via the Graphics Output
>> >> Protocol (GOP).
>> >>
>> >> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
>> >> scratch at boot. This may result in the GOP framebuffer address to
>> >> become stale, if the BAR covering the framebuffer is modified. This
>> >> will cause the framebuffer to become unresponsive, and may in some
>> >> cases result in unpredictable behavior if the range is reassigned to
>> >> another device.
>> >>
>> >> So add a non-x86 quirk to the EFI fb driver to find the BAR associated
>> >> with the GOP base address, and claim the BAR resource so that the PCI
>> >> core will not move it.
>> >
>> > I know this has already been merged as 55d728a40d36 ("efi/fb: Avoid
>> > reconfiguration of BAR that covers the framebuffer"), and I'm not
>> > suggesting that we revert it, but I have some misgivings.
>> ...
>
>> > Another is the use of pci_claim_resource() to express the idea that "this
>> > BAR can not be moved".  We have IORESOURCE_PCI_FIXED for that purpose, and
>> > previous versions of the patch used that.  I understand there was some
>> > problem with that, but I wish we could figure out and fix that problem
>> > instead of using a different mechanism.
>>
>> OK. The problem was that IORESOURCE_PCI_FIXED does not prevent the PCI
>> subsystem from handing out the same range to another device.
>
> Yes, this would definitely be a problem.  There must be a path where
> we start doing the reassignment before we claim the resources that
> have already been assigned.  That's what seems backwards to me -- it
> seems like we should claim things that are valid first so we know to
> avoid them.
>
>> > I'm not even completely sold on the idea that we need to prevent the BAR
>> > from being moved.  I'm not a UEFI expert, but if this requirement is in the
>> > spec, we should reference it.  If not, it should be sufficient to remember
>> > the boot-time BAR value, match the GOP base to *that*, and map it to
>> > whatever the current BAR value is.
>>
>> There is no such requirement in the spec. The graphics output protocol
>> is not described in terms of PCI, BARs etc. The framebuffer is simply
>> a memory range with side effects that is left enabled when handing
>> over to the OS.
>>
>> In summary, I am as unhappy with the patch as you are, but it is still
>> an improvement over the previous situation, so let's simply
>> collaborate to get this into shape going forward.
>>
>> My preference would be to investigate IORESOURCE_PCI_FIXED again,
>> because that still seems like the best way to deal with a live
>> framebuffer on a PCI device that has memory decoding enabled. It
>> should also address the issue with the current version of the patch,
>> i.e., that claiming resources at this point is not possible if the
>> device resides behind a bridge.
>>
>> So is there any guidance you can give as to how to proceed? If we set
>> IORESOURCE_PCI_FIXED, how should be prevent the PCI layer from
>> assigning this resource elsewhere if we cannot claim it yet?
>
> My preference would actually be to remember the boot BAR values and
> map to the current values because that avoids the unnecessary
> restriction.  The IORESOURCE_PCI_FIXED uses that seem legitimate to me
> are the legacy VGA and IDE things (stuff that's not described by BARs
> and *can't* be moved) and the new "Enhanced Allocation" stuff
> (basically a way to describe more non-BAR resources).
>
> We do something sort of similar with pci_revert_fw_address(), although
> it's currently only implemented for x86.  I could imagine a more
> generic solution that could be used for this GOP issue and could also
> replace pci_revert_fw_address().
>

I already proposed something like this a while ago:
http://marc.info//?l=linux-fbdev=149190021316410=2

> Conceptually it could be as simple as adding 7 u64 boot-time BAR
> values (6 BARs + the ROM) to struct pci_dev.  We went to a lot of
> trouble to implement the pcibios_fwaddrmap stuff on x86, and I can't
> remember why it's x86-specific.  Maybe we thought the extra 56 bytes
> per dev was too much overhead (it does seem like a lot for such a
> limited use case).  Maybe there's a clever way to store just the BARs
> we actually change and keep that long enough for efifb to use it.
>
> It *would* be nice to fix the problem with IORESOURCE_PCI_FIXED, and I
> think it would help clean up PCI resource management a lot.  Ideally
> we would be able to claim host bridge resources even before scanning
> the bus, 

Re: linux-next: build warning after merge of the drivers-x86 tree

[Darren Hart]

On Fri, May 19, 2017 at 01:23:17PM +1000, Stephen Rothwell wrote:
> Hi Darren,
> 
> After merging the drivers-x86 tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
> 
> drivers/platform/x86/ideapad-laptop.c:438:16: warning: 'touchpad_store' 
> defined but not used [-Wunused-function]
>  static ssize_t touchpad_store(struct device *dev,
> ^
> 
> Introduced by commit
> 
>   7f363145992c ("platform/x86: ideapad-laptop: Switch touchpad attribute to 
> be RO")

Thank you Stephen,

Andy, you warned me about this and I had forgotten before I included it in next.

Would you like to drop this change, or drop the touchpad_store function?

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH 00/41] omap_hsmmc: Add ADMA support and UHS/HS200/DDR support

[Tony Lindgren]

Hi,

* Kishon Vijay Abraham I <kis...@ti.com> [170519 01:19]:
> This series adds UHS, HS200, DDR mode and ADMA support to
> omap_hsmmc driver used to improve the throughput of MMC/SD in dra7
> SoCs.

Certainly seems way less intrusive than earlier before the
dmaengine changes :)

> *) tuning ratio of MMC in dra7 is different from sdhci

Hmm what's the tuning ratio?

> This series has been tested on beagleboard, pandaboard, beaglebone-black,
> beaglebone, am335x-evm, am437x-evm, dra7xx-evm, dra72x-evm, am571x-idk
> and am572x-idk.

I gave this a quick try after manally applying next-20170519
after reverting 67d0687224a9 ("mm: drop HASH_ADAPT"). Looks like
something is missing as I got:

arch/arm/mach-omap2/pdata-quirks.c:445:23: error:
'struct omap_hsmmc_platform_data' has no member named 'version'
...

It's possible I messed up something while manually applying.

> I can split the series to go into Ulf Hansson's tree and Tony's tree 
> separately if that is required.

Yes please. Maybe send the dts parts first that are ready to
get merged, like the fixes and all the iodelay configuration.

Then the mmc driver changes as a separate set.

Then third set to follow-up and enable things once the mmc
driver changes are merged.

Regards,

Tony

Re: [PATCH net] bonding: fix randomly populated arp target array

[Jarod Wilson]

On 2017-05-19 4:38 PM, Mahesh Bandewar (महेश बंडेवार) wrote:

On Fri, May 19, 2017 at 11:46 AM, Jarod Wilson  wrote:

In commit dc9c4d0fe023, the arp_target array moved from a static global
to a local variable. By the nature of static globals, the array used to
be initialized to all 0. At present, it's full of random data, which
that gets interpreted as arp_target values, when none have actually been
specified. Systems end up booting with spew along these lines:

[   32.161783] IPv6: ADDRCONF(NETDEV_UP): lacp0: link is not ready
[   32.168475] IPv6: ADDRCONF(NETDEV_UP): lacp0: link is not ready
[   32.175089] 8021q: adding VLAN 0 to HW filter on device lacp0
[   32.193091] IPv6: ADDRCONF(NETDEV_UP): lacp0: link is not ready
[   32.204892] lacp0: Setting MII monitoring interval to 100
[   32.211071] lacp0: Removing ARP target 216.124.228.17
[   32.216824] lacp0: Removing ARP target 218.160.255.255
[   32.222646] lacp0: Removing ARP target 185.170.136.184
[   32.228496] lacp0: invalid ARP target 255.255.255.255 specified for removal
[   32.236294] lacp0: option arp_ip_target: invalid value (-255.255.255.255)
[   32.243987] lacp0: Removing ARP target 56.125.228.17
[   32.249625] lacp0: Removing ARP target 218.160.255.255
[   32.255432] lacp0: Removing ARP target 15.157.233.184
[   32.261165] lacp0: invalid ARP target 255.255.255.255 specified for removal
[   32.268939] lacp0: option arp_ip_target: invalid value (-255.255.255.255)
[   32.276632] lacp0: Removing ARP target 16.0.0.0
[   32.281755] lacp0: Removing ARP target 218.160.255.255
[   32.287567] lacp0: Removing ARP target 72.125.228.17
[   32.293165] lacp0: Removing ARP target 218.160.255.255
[   32.298970] lacp0: Removing ARP target 8.125.228.17
[   32.304458] lacp0: Removing ARP target 218.160.255.255

None of these were actually specified as ARP targets, and the driver does
seem to clean up the mess okay, but it's rather noisy and confusing, leaks
values to userspace, and the 255.255.255.255 spew shows up even when debug
prints are disabled.

The fix: just zero out arp_target at init time.

While we're in here, init arp_all_targets_value in the right place.

Fixes: dc9c4d0fe023 ("bonding: reduce scope of some global variables")
CC: Mahesh Bandewar 
CC: Jay Vosburgh 
CC: Veaceslav Falico 
CC: Andy Gospodarek 
CC: net...@vger.kernel.org
CC: sta...@vger.kernel.org
Signed-off-by: Jarod Wilson 
---
  drivers/net/bonding/bond_main.c | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 2be78807fd6e..73313318399c 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4271,10 +4271,10 @@ static int bond_check_params(struct bond_params *params)
 int arp_validate_value, fail_over_mac_value, primary_reselect_value, i;
 struct bond_opt_value newval;
 const struct bond_opt_value *valptr;
-   int arp_all_targets_value;
+   int arp_all_targets_value = 0;


I think this is unnecessary as long as the var is initialized before it's use.


No, it's not part of the fix, it just irked me. The extra line is 
completely unnecessary, less lines is good. Possibly shouldn't have 
folded it into this fix, will respin and submit the cleanup another 
time, if necessary.



 u16 ad_actor_sys_prio = 0;
 u16 ad_user_port_key = 0;
-   __be32 arp_target[BOND_MAX_ARP_TARGETS];
+   __be32 arp_target[BOND_MAX_ARP_TARGETS] = { 0 };


this is the only change required to avoid reported error.


Absolutely correct.

--
Jarod Wilson
ja...@redhat.com

[GIT PULL] SCSI fixes for 4.12-rc1

[James Bottomley]

This is the first sweep of mostly minor fixes.  There's one security
one: the read past the end of a buffer in qedf, and a panic fix for
lpfc SLI-3 adapters, but the rest are a set of include and build
dependency tidy ups and assorted other small fixes and updates.

The patch is available here:

git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes

The short changelog is:

Bart Van Assche (1):
  scsi: scsi_lib: Add #include 

Christoph Hellwig (1):
  scsi: MAINTAINERS: update OSD entries

Colin Ian King (2):
  scsi: pmcraid: remove redundant check to see if request_size is less than 
zero
  scsi: lpfc: ensure els_wq is being checked before destroying it

Dan Carpenter (2):
  scsi: qedf: Cleanup the type of io_log->op
  scsi: lpfc: double lock typo in lpfc_ns_rsp()

Guenter Roeck (1):
  scsi: cxlflash: Select IRQ_POLL

Gustavo A. R. Silva (1):
  scsi: qedf: properly update arguments position in function call

Hannes Reinecke (1):
  scsi: libfc: do not flood console with messages 'libfc: queue full ...'

James Smart (1):
  scsi: lpfc: Fix panic on BFS configuration

Kees Cook (1):
  scsi: qedf: Avoid reading past end of buffer

Zhou Zhengping (1):
  scsi: Skip deleted devices in __scsi_device_lookup

And the diffstat:

 MAINTAINERS   |  4 
 drivers/scsi/cxlflash/Kconfig |  1 +
 drivers/scsi/libfc/fc_fcp.c   | 15 +--
 drivers/scsi/lpfc/lpfc_crtn.h |  1 +
 drivers/scsi/lpfc/lpfc_ct.c   |  2 +-
 drivers/scsi/lpfc/lpfc_init.c |  9 -
 drivers/scsi/lpfc/lpfc_sli.c  | 19 ---
 drivers/scsi/pmcraid.c|  3 ---
 drivers/scsi/qedf/qedf.h  |  2 +-
 drivers/scsi/qedf/qedf_els.c  |  2 +-
 drivers/scsi/qedf/qedf_main.c |  2 +-
 drivers/scsi/scsi.c   |  2 ++
 drivers/scsi/scsi_lib.c   |  1 +
 13 files changed, 38 insertions(+), 25 deletions(-)

With full diffs below.

James

---

diff --git a/MAINTAINERS b/MAINTAINERS
index 08360bb0468b..0e174d4b86a3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9530,10 +9530,6 @@ F:   drivers/net/wireless/intersil/orinoco/
 
 OSD LIBRARY and FILESYSTEM
 M: Boaz Harrosh 
-M: Benny Halevy 
-L: osd-...@open-osd.org
-W: http://open-osd.org
-T: git git://git.open-osd.org/open-osd.git
 S: Maintained
 F: drivers/scsi/osd/
 F: include/scsi/osd_*
diff --git a/drivers/scsi/cxlflash/Kconfig b/drivers/scsi/cxlflash/Kconfig
index c052104e523e..a011c5dbf214 100644
--- a/drivers/scsi/cxlflash/Kconfig
+++ b/drivers/scsi/cxlflash/Kconfig
@@ -5,6 +5,7 @@
 config CXLFLASH
tristate "Support for IBM CAPI Flash"
depends on PCI && SCSI && CXL && EEH
+   select IRQ_POLL
default m
help
  Allows CAPI Accelerated IO to Flash
diff --git a/drivers/scsi/libfc/fc_fcp.c b/drivers/scsi/libfc/fc_fcp.c
index a808e8ef1d08..234352da5c3c 100644
--- a/drivers/scsi/libfc/fc_fcp.c
+++ b/drivers/scsi/libfc/fc_fcp.c
@@ -407,11 +407,12 @@ static void fc_fcp_can_queue_ramp_up(struct fc_lport 
*lport)
  * can_queue. Eventually we will hit the point where we run
  * on all reserved structs.
  */
-static void fc_fcp_can_queue_ramp_down(struct fc_lport *lport)
+static bool fc_fcp_can_queue_ramp_down(struct fc_lport *lport)
 {
struct fc_fcp_internal *si = fc_get_scsi_internal(lport);
unsigned long flags;
int can_queue;
+   bool changed = false;
 
spin_lock_irqsave(lport->host->host_lock, flags);
 
@@ -427,9 +428,11 @@ static void fc_fcp_can_queue_ramp_down(struct fc_lport 
*lport)
if (!can_queue)
can_queue = 1;
lport->host->can_queue = can_queue;
+   changed = true;
 
 unlock:
spin_unlock_irqrestore(lport->host->host_lock, flags);
+   return changed;
 }
 
 /*
@@ -1896,11 +1899,11 @@ int fc_queuecommand(struct Scsi_Host *shost, struct 
scsi_cmnd *sc_cmd)
 
if (!fc_fcp_lport_queue_ready(lport)) {
if (lport->qfull) {
-   fc_fcp_can_queue_ramp_down(lport);
-   shost_printk(KERN_ERR, lport->host,
-"libfc: queue full, "
-"reducing can_queue to %d.\n",
-lport->host->can_queue);
+   if (fc_fcp_can_queue_ramp_down(lport))
+   shost_printk(KERN_ERR, lport->host,
+"libfc: queue full, "
+"reducing can_queue to %d.\n",
+lport->host->can_queue);
}
rc = SCSI_MLQUEUE_HOST_BUSY;
goto out;
diff --git a/drivers/scsi/lpfc/lpfc_crtn.h b/drivers/scsi/lpfc/lpfc_crtn.h
index 944b32ca4931..1c55408ac718 100644
--- a/drivers/scsi/lpfc/lpfc_crtn.h
+++ b/drivers/scsi/lpfc/lpfc_crtn.h
@@ -294,6 +294,7 @@ int 

Re: [PATCH net] bonding: fix accounting of active ports in 3ad

[Jarod Wilson]

On 2017-05-19 5:14 PM, David Miller wrote:

From: Jarod Wilson 
Date: Wed, 17 May 2017 11:11:44 -0400


As of 7bb11dc9f59d and 0622cab0341c, bond slaves in a 3ad bond are not
removed from the aggregator when they are down, and the active slave count
is NOT equal to number of ports in the aggregator, but rather the number
of ports in the aggregator that are still enabled.

  ...

Remedy it by using the same logic introduced in
7bb11dc9f59d in __bond_3ad_get_active_agg_info(), so sysfs, procfs and

   

netlink all report the number of active ports.


I think you mean to reference commit 0622cab0341c here not 7bb11dc9f59d.


D'oh, yes, you are entirely correct. Should I submit a v2 with that 
correction?


--
Jarod Wilson
ja...@redhat.com

Re: [PATCH 5/6] kmod: preempt on kmod_umh_threads_get()

[Dmitry Torokhov]

On Thu, May 18, 2017 at 08:24:43PM -0700, Luis R. Rodriguez wrote:
> In theory it is possible multiple concurrent threads will try to
> kmod_umh_threads_get() and as such atomic_inc(_concurrent) at
> the same time, therefore enabling a small time during which we've
> bumped kmod_concurrent but have not really enabled work. By using
> preemption we mitigate this a bit.
> 
> Preemption is not needed when we kmod_umh_threads_put().
> 
> Signed-off-by: Luis R. Rodriguez 
> ---
>  kernel/kmod.c | 24 ++--
>  1 file changed, 22 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/kmod.c b/kernel/kmod.c
> index 563600fc9bb1..7ea11dbc7564 100644
> --- a/kernel/kmod.c
> +++ b/kernel/kmod.c
> @@ -113,15 +113,35 @@ static int call_modprobe(char *module_name, int wait)
>  
>  static int kmod_umh_threads_get(void)
>  {
> + int ret = 0;
> +
> + /*
> +  * Disabling preemption makes sure that we are not rescheduled here
> +  *
> +  * Also preemption helps kmod_concurrent is not increased by mistake
> +  * for too long given in theory two concurrent threads could race on
> +  * atomic_inc() before we atomic_read() -- we know that's possible
> +  * and but we don't care, this is not used for object accounting and
> +  * is just a subjective threshold. The alternative is a lock.
> +  */
> + preempt_disable();
>   atomic_inc(_concurrent);
>   if (atomic_read(_concurrent) <= max_modprobes)

That is very "fancy" way to basically say:

if (atomic_inc_return(_concurrent) <= max_modprobes)
...

> - return 0;
> + goto out;
> +
>   atomic_dec(_concurrent);
> - return -EBUSY;
> + ret = -EBUSY;
> +out:
> + preempt_enable();
> + return ret;
>  }
>  
>  static void kmod_umh_threads_put(void)
>  {
> + /*
> +  * Preemption is not needed given once work is done we can
> +  * pace ourselves on our way out.
> +  */
>   atomic_dec(_concurrent);
>  }
>  
> -- 
> 2.11.0
> 

Thanks.

-- 
Dmitry

Re: [PATCH v5 0/5] Add ARM Mali Midgard device tree bindings and gpu node for rk3288

[Heiko Stuebner]

Hi Guillaume,

Am Mittwoch, 3. Mai 2017, 10:56:24 CEST schrieb Guillaume Tucker:
> The ARM Mali Midgard GPU kernel driver is only available
> out-of-tree and is not going to be merged in its current form.
> However, it would be useful to have its device tree bindings
> merged.  In particular, this would enable distributions to create
> working driver packages (dkms...) without having to patch the
> kernel.
> 
> The bindings for the earlier Mali Utgard GPU family have already
> been merged, so this is essentially the same scenario but for
> newer GPUs (Mali-T604 ~ Mali-T880).
> 
> This series of patches first imports the bindings from the latest
> driver release with some clean-up then adds a gpu node for the
> rk3288 SoC.  This was successfully tested on Radxa Rock2 Square,
> Firefly, Veyron Minnie and Jerry boards using Mali kernel driver
> r16p0 and r12p0 user-space binary.

as nobody complained anymore, I've applied all patches for 4.13
with the following small changes:
- patch2: node name to
gpu_opp_table: gpu-opp-table
  from the original
gpu_opp_table: opp_table0
- patches3-5: moved {} to its alphabetical correct position
  (below  and above )


Heiko

Re: work queue of scsi fc transports should be serialized

[Bart Van Assche]

On Fri, 2017-05-19 at 09:36 +, Dashi DS1 Cao wrote:
> It seems there is a race of multiple "fc_starget_delete" of the same rport,
> thus of the same SCSI host. The race leads to the race of scsi_remove_target
> and it cannot be prevented by the code snippet alone, even of the most recent
> version:
> spin_lock_irqsave(shost->host_lock, flags);
> list_for_each_entry(starget, >__targets, siblings) {
> if (starget->state == STARGET_DEL ||
> starget->state == STARGET_REMOVE)
> continue;
> If there is a possibility that the starget is under deletion(state ==
> STARGET_DEL), it should be possible that list_next_entry(starget, siblings)
> could cause a read access violation.

Hello Dashi,

Something else must be going on. From scsi_remove_target():

restart:
spin_lock_irqsave(shost->host_lock, flags);
list_for_each_entry(starget, >__targets, siblings) {
if (starget->state == STARGET_DEL ||
starget->state == STARGET_REMOVE)
continue;
if (starget->dev.parent == dev || >dev == dev) {
kref_get(>reap_ref);
starget->state = STARGET_REMOVE;
spin_unlock_irqrestore(shost->host_lock, flags);
__scsi_remove_target(starget);
scsi_target_reap(starget);
goto restart;
}
}
spin_unlock_irqrestore(shost->host_lock, flags);

In other words, before scsi_remove_target() decides to call
__scsi_remove_target(), it changes the target state into STARGET_REMOVE
while holding the host lock. This means that scsi_remove_target() won't
call __scsi_remove_target() twice and also that it won't invoke
list_next_entry(starget, siblings) after starget has been freed.

Bart.

Bluez 3.0+HS support

[Eugene So]

Please inform whether or not the latest Bluez 5.45 supports Bluetooth
3.0+HS 24Mbps?  I did some testing using the wilink 8 and only obtain
speeds of up to 156Kbps.  Thanks.  Please CC my email address when
responding.

Thanks,
Eugene

Re: mm, something wring in page_lock_anon_vma_read()?

[Hugh Dickins]

On Fri, 19 May 2017, Xishi Qiu wrote:
> On 2017/5/19 16:52, Xishi Qiu wrote:
> > On 2017/5/18 17:46, Xishi Qiu wrote:
> > 
> >> Hi, my system triggers this bug, and the vmcore shows the anon_vma seems 
> >> be freed.
> >> The kernel is RHEL 7.2, and the bug is hard to reproduce, so I don't know 
> >> if it
> >> exists in mainline, any reply is welcome!
> >>
> > 
> > When we alloc anon_vma, we will init the value of anon_vma->root,
> > so can we set anon_vma->root to NULL when calling
> > anon_vma_free -> kmem_cache_free(anon_vma_cachep, anon_vma);
> > 
> > anon_vma_free()
> > ...
> > anon_vma->root = NULL;
> > kmem_cache_free(anon_vma_cachep, anon_vma);
> > 
> > I find if we do this above, system boot failed, why?
> > 
> 
> If anon_vma was freed, we should not to access the root_anon_vma, because it 
> maybe also
> freed(e.g. anon_vma == root_anon_vma), right?
> 
> page_lock_anon_vma_read()
>   ...
>   anon_vma = (struct anon_vma *) (anon_mapping - PAGE_MAPPING_ANON);
>   root_anon_vma = ACCESS_ONCE(anon_vma->root);
>   if (down_read_trylock(_anon_vma->rwsem)) {  // it's not safe
>   ...
>   if (!atomic_inc_not_zero(_vma->refcount)) {  // check anon_vma was 
> not freed
>   ...
>   anon_vma_lock_read(anon_vma);  // it's safe
>   ...

You're ignoring the rcu_read_lock() on entry to page_lock_anon_vma_read(),
and the SLAB_DESTROY_BY_RCU (recently renamed SLAB_TYPESAFE_BY_RCU) nature
of the anon_vma_cachep kmem cache.  It is not safe to muck with anon_vma->
root in anon_vma_free(), others could still be looking at it.

Hugh

Re: [GIT PULL] KVM fixes for v4.12-rc2

[Linus Torvalds]

So I noticed that my diffstat didn't match either the KVM or the Xen pull.

The *reason* seems to be that both Radim and Juergen have enabled the
"patience" diff, because if I add "--patience" to the diff line, I get
the same numbers you guys report.

On Fri, May 19, 2017 at 11:43 AM, Radim Krčmář  wrote:
>
>  28 files changed, 297 insertions(+), 125 deletions(-)

Without "--patience" (the default) I get:

 28 files changed, 292 insertions(+), 120 deletions(-)

which is close, but not the exact same thing.

So I don't mind people using the patience version of the diffing code,
but on the whole it's a loss as often as it is a win, so I'm wondering
_why_ you do this? Is there some other project that has started
suggesting using the patience diff (either with a command line option
or by just doing

  git config diff.algorithm patience

anyway, it's not a big deal, I'm just curious..

   Linus

Re: [PATCH 6/6] kmod: use simplified rate limit printk

[Dmitry Torokhov]

On Thu, May 18, 2017 at 08:24:44PM -0700, Luis R. Rodriguez wrote:
> Just use the simplified rate limit printk when the max modprobe
> limit is reached, while at it throw out a bone should the error
> be triggered.
> 
> Reviewed-by: Petr Mladek 
> Signed-off-by: Luis R. Rodriguez 
> ---
>  kernel/kmod.c | 10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/kernel/kmod.c b/kernel/kmod.c
> index 7ea11dbc7564..56cd2a16e7ac 100644
> --- a/kernel/kmod.c
> +++ b/kernel/kmod.c
> @@ -166,7 +166,6 @@ int __request_module(bool wait, const char *fmt, ...)
>   va_list args;
>   char module_name[MODULE_NAME_LEN];
>   int ret;
> - static int kmod_loop_msg;
>  
>   /*
>* We don't allow synchronous module loading from async.  Module
> @@ -191,13 +190,8 @@ int __request_module(bool wait, const char *fmt, ...)
>  
>   ret = kmod_umh_threads_get();
>   if (ret) {
> - /* We may be blaming an innocent here, but unlikely */
> - if (kmod_loop_msg < 5) {
> - printk(KERN_ERR
> -"request_module: runaway loop modprobe %s\n",
> -module_name);
> - kmod_loop_msg++;
> - }
> + pr_err_ratelimited("%s: module \"%s\" reached limit (%u) of 
> concurrent modprobe calls\n",
> +__func__, module_name, max_modprobes);

This is completely different behavior, isn't it? Instead of reporting
first 5 occurrences we now reporting every once in a while. Why is this
new behavior better?

-- 
Dmitry

Re: [PATCH] Use ctlr directly in rdac_failover_get()

[Bart Van Assche]

On Fri, 2017-05-19 at 14:06 +0200, Artem Savkov wrote:
> rdac_failover_get references struct rdac_controller as
> ctlr->ms_sdev->handler_data->ctlr for no apparent reason. Besides being
> inefficient this also introduces a null-pointer dereference as
> send_mode_select() sets ctlr->ms_sdev to NULL before calling
> rdac_failover_get():
> 
> [ ... ]
> Signed-off-by: Artem Savkov 

Hello Artem,

Although this patch looks fine to me, please consider adding the "Fixes:" and
"Cc: " tags.

Bart.

Re: [PATCH 03/18] xen/pvcalls: initialize the module and register the xenbus backend

[Stefano Stabellini]

On Thu, 18 May 2017, Stefano Stabellini wrote:
> On Wed, 17 May 2017, Juergen Gross wrote:
> > On 16/05/17 21:58, Stefano Stabellini wrote:
> > > On Tue, 16 May 2017, Juergen Gross wrote:
> > >> On 15/05/17 22:35, Stefano Stabellini wrote:
> > >>> The pvcalls backend has one ioworker per cpu: the ioworkers are
> > >>> implemented as a cpu bound workqueue, and will deal with the actual
> > >>> socket and data ring reads/writes.
> > >>>
> > >>> ioworkers are global: we only have one set for all the frontends. They
> > >>> process requests on their wqs list in order, once they are done with a
> > >>> request, they'll remove it from the list. A spinlock is used for
> > >>> protecting the list. Each ioworker is bound to a different cpu to
> > >>> maximize throughput.
> > >>>
> > >>> Signed-off-by: Stefano Stabellini 
> > >>> CC: boris.ostrov...@oracle.com
> > >>> CC: jgr...@suse.com
> > >>> ---
> > >>>  drivers/xen/pvcalls-back.c | 64 
> > >>> ++
> > >>>  1 file changed, 64 insertions(+)
> > >>>
> > >>> diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
> > >>> index 2dbf7d8..46a889a 100644
> > >>> --- a/drivers/xen/pvcalls-back.c
> > >>> +++ b/drivers/xen/pvcalls-back.c
> > >>> @@ -25,6 +25,26 @@
> > >>>  #include 
> > >>>  #include 
> > >>>  
> > >>> +struct pvcalls_ioworker {
> > >>> +   struct work_struct register_work;
> > >>> +   atomic_t io;
> > >>> +   struct list_head wqs;
> > >>> +   spinlock_t lock;
> > >>> +   int num;
> > >>> +};
> > >>> +
> > >>> +struct pvcalls_back_global {
> > >>> +   struct pvcalls_ioworker *ioworkers;
> > >>> +   int nr_ioworkers;
> > >>> +   struct workqueue_struct *wq;
> > >>> +   struct list_head privs;
> > >>> +   struct rw_semaphore privs_lock;
> > >>> +} pvcalls_back_global;
> > >>> +
> > >>> +static void pvcalls_back_ioworker(struct work_struct *work)
> > >>> +{
> > >>> +}
> > >>> +
> > >>>  static int pvcalls_back_probe(struct xenbus_device *dev,
> > >>>   const struct xenbus_device_id *id)
> > >>>  {
> > >>> @@ -59,3 +79,47 @@ static int pvcalls_back_uevent(struct xenbus_device 
> > >>> *xdev,
> > >>> .uevent = pvcalls_back_uevent,
> > >>> .otherend_changed = pvcalls_back_changed,
> > >>>  };
> > >>> +
> > >>> +static int __init pvcalls_back_init(void)
> > >>> +{
> > >>> +   int ret, i, cpu;
> > >>> +
> > >>> +   if (!xen_domain())
> > >>> +   return -ENODEV;
> > >>> +
> > >>> +   ret = xenbus_register_backend(_back_driver);
> > >>> +   if (ret < 0)
> > >>> +   return ret;
> > >>> +
> > >>> +   init_rwsem(_back_global.privs_lock);
> > >>> +   INIT_LIST_HEAD(_back_global.privs);
> > >>> +   pvcalls_back_global.wq = alloc_workqueue("pvcalls_io", 0, 0);
> > >>> +   if (!pvcalls_back_global.wq)
> > >>> +   goto error;
> > >>> +   pvcalls_back_global.nr_ioworkers = num_online_cpus();
> > >>
> > >> Really? Recently I cam across a system with 640 dom0 cpus. I don't think
> > >> we want 640 workers initialized when loading the backend module. I'd
> > >> prefer one or a few workers per connected frontend.
> > > 
> > > I think we want to keep the ioworker allocation to be based on the
> > > number of vcpus: we do not want more ioworkers than vcpus because it is
> > > a waste of resources and leads to worse performance.  Also, given that
> > > they do memcpy's, I also think it is a good idea to bind them to vcpus
> > > (and pin vcpus to pcpus) to get best performance.
> > 
> > This will cause a lot of pain for the cpu offline case. Please don't try
> > to work against the hypervisor scheduler by designing a backend based on
> > a vcpu pin policy. This might result in best performance for your
> > special workload, but generally it is a bad idea!
> 
> You are right. Of course, vcpu pinning is not a fundamental requirement
> for this backend. I wrote about vcpu pinning only to help with the
> explanation.
> 
> However, pvcalls is a memcpy based protocol and to perform memcpys
> efficiently is very important to keep caches hot. The target is to hit
> the same cacheline when reading and writing, which makes a huge
> difference; it depends on processor and architecture but it is easily
> 20%. To get caching benefits, we need to do memcpys for the same socket
> on the same vcpu (and on the same pcpu as well, that's why I mentioned
> vcpu pinning, but we'll trust the Xen scheduler to do the right thing
> when there is no contention).
> 
> This is why in this backend, regardless of the workqueue
> design/allocation we use, I think we have to stick to two basic
> principles:
> 
> - each socket is bound to one vcpu
> - sockets are distributed evenly across vcpus

[...]

> It might be possible to create an ioworker for each socket (instead of
> an ioworker for each vcpu) if we wanted to, as long as we bind it to a
> vcpu and distribute them evenly 

[PATCH] ext4: handle the rest of ext4_mb_load_buddy() ENOMEM errors

[Konstantin Khlebnikov]

I've got another report about breaking ext4 by ENOMEM error returned from
ext4_mb_load_buddy() caused by memory shortage in memory cgroup.
This time inside ext4_discard_preallocations().

This patch replaces ext4_error() with ext4_warning() where errors returned
from ext4_mb_load_buddy() are not fatal and handled by caller:
* ext4_mb_discard_group_preallocations() - called before generating ENOSPC,
  we'll try to discard other group or return ENOSPC into user-space.
* ext4_trim_all_free() - just stop trimming and return ENOMEM from ioctl.

Some callers cannot handle errors, thus __GFP_NOFAIL is used for them:
* ext4_discard_preallocations()
* ext4_mb_discard_lg_preallocations()

The only unclear case is ext4_group_add_blocks(), probably ext4_std_error()
should handle ENOMEM as warning and don't break filesystem.

Fixes: adb7ef600cc9 ("ext4: use __GFP_NOFAIL in ext4_free_blocks()")
Signed-off-by: Konstantin Khlebnikov 
---
 fs/ext4/mballoc.c |   23 ++-
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index 5083bce20ac4..b7928cddd539 100644
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -3887,7 +3887,8 @@ ext4_mb_discard_group_preallocations(struct super_block 
*sb,
 
err = ext4_mb_load_buddy(sb, group, );
if (err) {
-   ext4_error(sb, "Error loading buddy information for %u", group);
+   ext4_warning(sb, "Error %d loading buddy information for %u",
+err, group);
put_bh(bitmap_bh);
return 0;
}
@@ -4044,10 +4045,11 @@ void ext4_discard_preallocations(struct inode *inode)
BUG_ON(pa->pa_type != MB_INODE_PA);
group = ext4_get_group_number(sb, pa->pa_pstart);
 
-   err = ext4_mb_load_buddy(sb, group, );
+   err = ext4_mb_load_buddy_gfp(sb, group, ,
+GFP_NOFS|__GFP_NOFAIL);
if (err) {
-   ext4_error(sb, "Error loading buddy information for %u",
-   group);
+   ext4_error(sb, "Error %d loading buddy information for 
%u",
+  err, group);
continue;
}
 
@@ -4303,11 +4305,14 @@ ext4_mb_discard_lg_preallocations(struct super_block 
*sb,
spin_unlock(>lg_prealloc_lock);
 
list_for_each_entry_safe(pa, tmp, _list, u.pa_tmp_list) {
+   int err;
 
group = ext4_get_group_number(sb, pa->pa_pstart);
-   if (ext4_mb_load_buddy(sb, group, )) {
-   ext4_error(sb, "Error loading buddy information for %u",
-   group);
+   err = ext4_mb_load_buddy_gfp(sb, group, ,
+GFP_NOFS|__GFP_NOFAIL);
+   if (err) {
+   ext4_error(sb, "Error %d loading buddy information for 
%u",
+  err, group);
continue;
}
ext4_lock_group(sb, group);
@@ -5127,8 +5132,8 @@ ext4_trim_all_free(struct super_block *sb, ext4_group_t 
group,
 
ret = ext4_mb_load_buddy(sb, group, );
if (ret) {
-   ext4_error(sb, "Error in loading buddy "
-   "information for %u", group);
+   ext4_warning(sb, "Error %d loading buddy information for %u",
+ret, group);
return ret;
}
bitmap = e4b.bd_bitmap;

[PATCH v2] kbuild: simplify silent build (-s) detection

[Masahiro Yamada]

This allows to detect -s (--silent) option without checking GNU Make
version.

As commit e36aaea28972 ("kbuild: Fix silent builds with make-4")
pointed out, GNU Make 4.x changed the way/order it presents the
command line options into MAKEFLAGS.

In Make 3.8x, 's' is always be the first in a group of short options.
The group could be prefixed with '-'.

In Make 4.x, 's' is always the last in a group of short options.

As commit e6ac89fabd03 ("kbuild: Correctly deal with make options
which contain an 's'") addressed, we also need to deal with long
options that end with 's', like --warn-undefined-variables.

Test cases:

[1] command line input:make --silent
 -> MAKEFLAGS for Make 3.8x:s
 -> MAKEFLAGS for Make 4.x :s

[2] command line input:make -srR
 -> MAKEFLAGS for Make 3.8x:sRr
 -> MAKEFLAGS for Make 4.x :rRs

[3] command line input:make -s -rR --warn-undefined-variables
 -> MAKEFLAGS for Make 3.8x:--warn-undefined-variables -sRr
 -> MAKEFLAGS for Make 4.x :rRs --warn-undefined-variables

We can take care of them, by filtering out long options (--%),
then matching -s% s% %s patterns.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Fix makefiles under tools as well

 Makefile   | 9 +
 tools/build/Makefile.build | 8 +---
 tools/scripts/Makefile.include | 8 +---
 3 files changed, 3 insertions(+), 22 deletions(-)

diff --git a/Makefile b/Makefile
index b1ee4a49efa2..d8b5c4230da0 100644
--- a/Makefile
+++ b/Makefile
@@ -84,17 +84,10 @@ endif
 # If the user is running make -s (silent mode), suppress echoing of
 # commands
 
-ifneq ($(filter 4.%,$(MAKE_VERSION)),) # make-4
-ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),)
+ifneq ($(filter -s% s% %s,$(filter-out --%,$(MAKEFLAGS))),)
   quiet=silent_
   tools_silent=s
 endif
-else   # make-3.8x
-ifneq ($(filter s% -s%,$(MAKEFLAGS)),)
-  quiet=silent_
-  tools_silent=-s
-endif
-endif
 
 export quiet Q KBUILD_VERBOSE
 
diff --git a/tools/build/Makefile.build b/tools/build/Makefile.build
index e279a71c650d..850fe9ce47d3 100644
--- a/tools/build/Makefile.build
+++ b/tools/build/Makefile.build
@@ -19,15 +19,9 @@ else
   Q=@
 endif
 
-ifneq ($(filter 4.%,$(MAKE_VERSION)),) # make-4
-ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),)
+ifneq ($(filter -s% s% %s,$(filter-out --%,$(MAKEFLAGS))),)
   quiet=silent_
 endif
-else   # make-3.8x
-ifneq ($(filter s% -s%,$(MAKEFLAGS)),)
-  quiet=silent_
-endif
-endif
 
 build-dir := $(srctree)/tools/build
 
diff --git a/tools/scripts/Makefile.include b/tools/scripts/Makefile.include
index fc74db62fef4..7fda39adf3cc 100644
--- a/tools/scripts/Makefile.include
+++ b/tools/scripts/Makefile.include
@@ -58,15 +58,9 @@ else
 NO_SUBDIR = :
 endif
 
-ifneq ($(filter 4.%,$(MAKE_VERSION)),)  # make-4
-ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),)
+ifneq ($(filter -s% s% %s,$(filter-out --%,$(MAKEFLAGS))),)
   silent=1
 endif
-else   # make-3.8x
-ifneq ($(filter s% -s%,$(MAKEFLAGS)),)
-  silent=1
-endif
-endif
 
 #
 # Define a callable command for descending to a new directory
-- 
2.7.4

[PATCH 4/4] net-next: stmmac: rework the speed selection

[Corentin Labbe]

The current stmmac_adjust_link() part which handle speed have
some if (has_platform) code and my dwmac-sun8i will add more of them.

So we need to handle better speed selection.
Moreover the struct link member speed and port are hard to guess their
purpose. And their unique usage are to be combined for writing speed.

So this patch replace speed/port by simpler
speed10/speed100/speed1000/speed_mask variables.

In dwmac4_core_init and dwmac1000_core_init, port/speed value was used
directly without using the struct link. This patch convert also their
usage to speedxxx.

Signed-off-by: Corentin Labbe 
---
 drivers/net/ethernet/stmicro/stmmac/common.h   |  8 ---
 .../net/ethernet/stmicro/stmmac/dwmac1000_core.c   | 26 +-
 .../net/ethernet/stmicro/stmmac/dwmac100_core.c|  6 +++--
 drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c  | 26 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c  | 21 -
 5 files changed, 43 insertions(+), 44 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h 
b/drivers/net/ethernet/stmicro/stmmac/common.h
index b7ce3fbb5375..e82b4b70b7be 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -549,9 +549,11 @@ extern const struct stmmac_hwtimestamp stmmac_ptp;
 extern const struct stmmac_mode_ops dwmac4_ring_mode_ops;
 
 struct mac_link {
-   int port;
-   int duplex;
-   int speed;
+   u32 speed_mask;
+   u32 speed10;
+   u32 speed100;
+   u32 speed1000;
+   u32 duplex;
 };
 
 struct mii_regs {
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index f3d9305e5f70..b8848a9d70c5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -45,15 +45,17 @@ static void dwmac1000_core_init(struct mac_device_info *hw, 
int mtu)
if (hw->ps) {
value |= GMAC_CONTROL_TE;
 
-   if (hw->ps == SPEED_1000) {
-   value &= ~GMAC_CONTROL_PS;
-   } else {
-   value |= GMAC_CONTROL_PS;
-
-   if (hw->ps == SPEED_10)
-   value &= ~GMAC_CONTROL_FES;
-   else
-   value |= GMAC_CONTROL_FES;
+   value &= ~hw->link.speed_mask;
+   switch (hw->ps) {
+   case SPEED_1000:
+   value |= hw->link.speed1000;
+   break;
+   case SPEED_100:
+   value |= hw->link.speed100;
+   break;
+   case SPEED_10:
+   value |= hw->link.speed10;
+   break;
}
}
 
@@ -531,9 +533,11 @@ struct mac_device_info *dwmac1000_setup(void __iomem 
*ioaddr, int mcbins,
mac->mac = _ops;
mac->dma = _dma_ops;
 
-   mac->link.port = GMAC_CONTROL_PS;
mac->link.duplex = GMAC_CONTROL_DM;
-   mac->link.speed = GMAC_CONTROL_FES;
+   mac->link.speed10 = GMAC_CONTROL_PS;
+   mac->link.speed100 = GMAC_CONTROL_PS | GMAC_CONTROL_FES;
+   mac->link.speed1000 = 0;
+   mac->link.speed_mask = GENMASK(15, 14);
mac->mii.addr = GMAC_MII_ADDR;
mac->mii.data = GMAC_MII_DATA;
mac->mii.addr_shift = 11;
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
index 1b3609105484..8ef517356313 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
@@ -175,9 +175,11 @@ struct mac_device_info *dwmac100_setup(void __iomem 
*ioaddr, int *synopsys_id)
mac->mac = _ops;
mac->dma = _dma_ops;
 
-   mac->link.port = MAC_CONTROL_PS;
mac->link.duplex = MAC_CONTROL_F;
-   mac->link.speed = 0;
+   mac->link.speed10 = 0;
+   mac->link.speed100 = 0;
+   mac->link.speed1000 = 0;
+   mac->link.speed_mask = MAC_CONTROL_PS;
mac->mii.addr = MAC_MII_ADDR;
mac->mii.data = MAC_MII_DATA;
mac->mii.addr_shift = 11;
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index 48793f2e9307..d371e18b122c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -35,15 +35,17 @@ static void dwmac4_core_init(struct mac_device_info *hw, 
int mtu)
if (hw->ps) {
value |= GMAC_CONFIG_TE;
 
-   if (hw->ps == SPEED_1000) {
-   value &= ~GMAC_CONFIG_PS;
-   } else {
-   value |= GMAC_CONFIG_PS;
-
-   if (hw->ps == SPEED_10)
-   value &= ~GMAC_CONFIG_FES;
- 

[PATCH 3/4] net-next: stmmac: use SPEED_xxx instead of raw value

[Corentin Labbe]

Signed-off-by: Corentin Labbe 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index e008cded388e..a1ab52e29359 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -812,12 +812,12 @@ static void stmmac_adjust_link(struct net_device *dev)
if (phydev->speed != priv->speed) {
new_state = 1;
switch (phydev->speed) {
-   case 1000:
+   case SPEED_1000:
if (priv->plat->has_gmac ||
priv->plat->has_gmac4)
ctrl &= ~priv->hw->link.port;
break;
-   case 100:
+   case SPEED_100:
if (priv->plat->has_gmac ||
priv->plat->has_gmac4) {
ctrl |= priv->hw->link.port;
@@ -826,7 +826,7 @@ static void stmmac_adjust_link(struct net_device *dev)
ctrl &= ~priv->hw->link.port;
}
break;
-   case 10:
+   case SPEED_10:
if (priv->plat->has_gmac ||
priv->plat->has_gmac4) {
ctrl |= priv->hw->link.port;
-- 
2.13.0

[PATCH] kbuild: add GNU Make version check

[Masahiro Yamada]

As Documentation/process/changes.rst says, Kbuild now depends on
GNU Make 3.81 or later.

If invoked with older versions, it fails with an unclear error
message.

$ make defconfig
  HOSTCC  scripts/basic/fixdep
scripts/Makefile.host:135: *** missing separator.  Stop.
make: *** [defconfig] Error 2

Stop building with a clearer message:

Makefile:16: *** GNU Make >= 3.81 is required.  You are running version 3.80.  
Stop.

I borrowed the idea from Buildroot.

Signed-off-by: Masahiro Yamada 
---

 Makefile | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Makefile b/Makefile
index d8b5c4230da0..5baaebf8f23a 100644
--- a/Makefile
+++ b/Makefile
@@ -10,6 +10,12 @@ NAME = Fearless Coyote
 # Comments in this file are targeted only to the developer, do not
 # expect to learn how to build the kernel reading this file.
 
+# Check Make version (note: this check will break at Make 10.x)
+MIN_MAKE_VERSION := 3.81
+ifneq ($(firstword $(sort $(MAKE_VERSION) 
$(MIN_MAKE_VERSION))),$(MIN_MAKE_VERSION))
+$(error GNU Make >= $(MIN_MAKE_VERSION) is required.  You are running version 
$(MAKE_VERSION))
+endif
+
 # o Do not use make's built-in rules and variables
 #   (this increases performance and avoids hard-to-debug behaviour);
 # o Look for make include files relative to root of kernel src
-- 
2.7.4

[PATCH 2/4] net-next: stmmac: Remove unnecessary parenthesis

[Corentin Labbe]

Signed-off-by: Corentin Labbe 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 2b778f63d1d5..e008cded388e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -799,7 +799,7 @@ static void stmmac_adjust_link(struct net_device *dev)
 * If not, we operate in half-duplex mode. */
if (phydev->duplex != priv->oldduplex) {
new_state = 1;
-   if (!(phydev->duplex))
+   if (!phydev->duplex)
ctrl &= ~priv->hw->link.duplex;
else
ctrl |= priv->hw->link.duplex;
-- 
2.13.0

[PATCH v8 1/2] init: add support to directly boot to a mapped device

[Enric Balletbo i Serra]

From: Will Drewry 

Add a dm= kernel parameter modeled after the md= parameter from
do_mounts_md. It allows for device-mapper targets to be configured at
boot time for use early in the boot process (as the root device or
otherwise).

Signed-off-by: Will Drewry 
Signed-off-by: Kees Cook 
[rework to use dm_ioctl calls]
Signed-off-by: Enric Balletbo i Serra 
---
 Documentation/admin-guide/kernel-parameters.rst |   1 +
 Documentation/admin-guide/kernel-parameters.txt |   3 +
 Documentation/device-mapper/dm-boot.txt |  65 
 init/Makefile   |   1 +
 init/do_mounts.c|   1 +
 init/do_mounts.h|  10 +
 init/do_mounts_dm.c | 459 
 7 files changed, 540 insertions(+)
 create mode 100644 Documentation/device-mapper/dm-boot.txt
 create mode 100644 init/do_mounts_dm.c

diff --git a/Documentation/admin-guide/kernel-parameters.rst 
b/Documentation/admin-guide/kernel-parameters.rst
index d76ab39..5301f45 100644
--- a/Documentation/admin-guide/kernel-parameters.rst
+++ b/Documentation/admin-guide/kernel-parameters.rst
@@ -92,6 +92,7 @@ parameter is applicable::
BLACKFIN Blackfin architecture is enabled.
CLK Common clock infrastructure is enabled.
CMA Contiguous Memory Area support is enabled.
+   DM  Device mapper support is enabled.
DRM Direct Rendering Management support is enabled.
DYNAMIC_DEBUG Build in debug messages and enable them at runtime
EDD BIOS Enhanced Disk Drive Services (EDD) is enabled
diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index f85bfe0..0ea65c2 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -829,6 +829,9 @@
 
dis_ucode_ldr   [X86] Disable the microcode loader.
 
+   dm= [DM] Allows early creation of a device-mapper device.
+   See Documentation/device-mapper/boot.txt.
+
dma_debug=off   If the kernel is compiled with DMA_API_DEBUG support,
this option disables the debugging code at boot.
 
diff --git a/Documentation/device-mapper/dm-boot.txt 
b/Documentation/device-mapper/dm-boot.txt
new file mode 100644
index 000..50f08ec
--- /dev/null
+++ b/Documentation/device-mapper/dm-boot.txt
@@ -0,0 +1,65 @@
+Boot time creation of mapped devices
+
+
+It is possible to configure a device mapper device to act as the root
+device for your system in two ways.
+
+The first is to build an initial ramdisk which boots to a minimal
+userspace which configures the device, then pivot_root(8) in to it.
+
+The second is to possible when the device-mapper and any targets are
+compiled into the kernel (not a module), one or more device-mappers may
+be created and used as the root device at boot time with the parameters
+given with the boot line dm=...
+
+The format is specified as a simple string of data separated by commas and
+optionally semi-colons, where:
+ - a comma is used to separate fields like name, uuid, flags and table 
(specifies
+   one device)
+ - a semi-colon is used to separate devices.
+
+So the format will look like this:
+
+ 
dm=,,,[,+][;,,,[,+]]+
+
+Where,
+ ::= The device name.
+ ::= ---- | ""
+::= "ro" | "rw"
+::=
+ ::= "verity" | "bootcache" | ...
+
+The dm line may be as normal when using the dmsetup tool when using the
+--bootformat argument.
+
+Unless renamed by udev, the device node created will be dm-0 as the
+first minor number for the device-mapper is used during early creation.
+
+Examples
+
+An example of booting to a linear array made up of user-mode linux block
+devices:
+
+  dm="lroot,,rw, 0 4096 linear 98:16 0, 4096 4096 linear 98:32 0" \
+  root=/dev/dm-0
+
+This will boot to a rw dm-linear target of 8192 sectors split across two
+block devices identified by their major:minor numbers.  After boot, udev
+will rename this target to /dev/mapper/lroot (depending on the rules).
+No uuid was assigned.
+
+An example of multiple device-mappers, with the dm="..." contents shown
+here split on multiple lines for readability:
+
+vboot,,ro,
+  0 1768000 bootcache
+aa55b119-2a47-8c45-946a-5ac57765011f+1
+76e9be054b15884a9fa85973e9cb274c93afadb6
+1768000 10 23 2;
+vroot,,ro,
+  0 1740800 verity 254:0 254:0 1740800 sha1
+76e9be054b15884a9fa85973e9cb274c93afadb6
+5b3549d54d6c7a3837b9b81ed72e49463a64c03680c47835bef94d768e5646fe;
+vram,,rw,
+  0 32768 linear 1:0 0,
+  32768 32768 linear 1:1 0
diff --git a/init/Makefile b/init/Makefile
index 

[PATCH v8 0/2] dm: boot a mapped device without an initramfs

[Enric Balletbo i Serra]

Dear all,

So here is a new version of the patches to be reviewed, this time as
suggested by Alasdair the patches are reworked to match with the new
dmsetup bootformat feature [1]. These patches are not reviewed yet but
the format was discussed in the IRC and was suggested to send the
kernel patches in parallel.

Changes since v7:
 - Fix build error due commit
e516db4f67 (dm ioctl: add a new DM_DEV_ARM_POLL ioctl)

Changes since v6:
 - Add a new function to issue the equivalent of a DM ioctl programatically.
 - Use the new ioctl interface to create the devices.
 - Use a comma-delimited and semi-colon delimited dmsetup-like commands.

Changes since v5:
 - https://www.redhat.com/archives/dm-devel/2016-February/msg00112.html

[1] https://www.redhat.com/archives/linux-lvm/2017-May/msg00047.html

Wating for your feedback,

Enric Balletbo i Serra (1):
  dm ioctl: add a device mapper ioctl function.

Will Drewry (1):
  init: add support to directly boot to a mapped device

 Documentation/admin-guide/kernel-parameters.rst |   1 +
 Documentation/admin-guide/kernel-parameters.txt |   3 +
 Documentation/device-mapper/dm-boot.txt |  65 
 drivers/md/dm-ioctl.c   |  50 +++
 include/linux/device-mapper.h   |   6 +
 init/Makefile   |   1 +
 init/do_mounts.c|   1 +
 init/do_mounts.h|  10 +
 init/do_mounts_dm.c | 459 
 9 files changed, 596 insertions(+)
 create mode 100644 Documentation/device-mapper/dm-boot.txt
 create mode 100644 init/do_mounts_dm.c

-- 
2.9.3

[PATCH] rcu: mark debug_lockdep_rcu_enabled() as pure

[Konstantin Khlebnikov]

This allows to get rid of unneeded invocations.

Function debug_lockdep_rcu_enabled() becomes really hot if several
debug options are enabled together with CONFIG_PROVE_RCU.

Hottest path ends with:
  debug_lockdep_rcu_enabled
  is_ftrace_trampoline
  __kernel_text_address

Here debug_lockdep_rcu_enabled() is called from condition
(debug_lockdep_rcu_enabled() && !__warned && (c)) inside macro
do_for_each_ftrace_op(), where "c" is false.

With this patch "netperf -H localhost" shows boost from 2400 to 2500.

Signed-off-by: Konstantin Khlebnikov 
---
 include/linux/rcupdate.h |2 +-
 kernel/rcu/update.c  |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index e1e5d002fdb9..9ecb3cb715bd 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -472,7 +472,7 @@ extern struct lockdep_map rcu_lock_map;
 extern struct lockdep_map rcu_bh_lock_map;
 extern struct lockdep_map rcu_sched_lock_map;
 extern struct lockdep_map rcu_callback_map;
-int debug_lockdep_rcu_enabled(void);
+int __pure debug_lockdep_rcu_enabled(void);
 
 int rcu_read_lock_held(void);
 int rcu_read_lock_bh_held(void);
diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
index 273e869ca21d..a0c30abefdcd 100644
--- a/kernel/rcu/update.c
+++ b/kernel/rcu/update.c
@@ -292,7 +292,7 @@ struct lockdep_map rcu_callback_map =
STATIC_LOCKDEP_MAP_INIT("rcu_callback", _callback_key);
 EXPORT_SYMBOL_GPL(rcu_callback_map);
 
-int notrace debug_lockdep_rcu_enabled(void)
+int __pure notrace debug_lockdep_rcu_enabled(void)
 {
return rcu_scheduler_active != RCU_SCHEDULER_INACTIVE && debug_locks &&
   current->lockdep_recursion == 0;

[PATCH v8 2/2] dm ioctl: add a device mapper ioctl function.

[Enric Balletbo i Serra]

Add a dm_ioctl_cmd to issue the equivalent of a DM ioctl call in kernel.

Signed-off-by: Enric Balletbo i Serra 
---
 drivers/md/dm-ioctl.c | 50 +++
 include/linux/device-mapper.h |  6 ++
 2 files changed, 56 insertions(+)

diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c
index d45c681..033e31d 100644
--- a/drivers/md/dm-ioctl.c
+++ b/drivers/md/dm-ioctl.c
@@ -2011,3 +2011,53 @@ int dm_copy_name_and_uuid(struct mapped_device *md, char 
*name, char *uuid)
 
return r;
 }
+
+/**
+ * dm_ioctl_cmd - Device mapper ioctl's
+ * @command: ioctl command
+ * @param: Pointer to device mapped ioctl struct
+ */
+int dm_ioctl_cmd(uint command, struct dm_ioctl *param)
+{
+   int r = 0;
+   int ioctl_flags;
+   unsigned int cmd;
+   ioctl_fn fn = NULL;
+   size_t input_param_size;
+   struct file *filp = NULL;
+
+   if (_IOC_TYPE(command) != DM_IOCTL)
+   return -ENOTTY;
+
+   /* DM_DEV_ARM_POLL is not supported */
+   if (command == DM_DEV_ARM_POLL)
+   return -EINVAL;
+
+   cmd = _IOC_NR(command);
+
+   /*
+* Nothing more to do for the version command.
+*/
+   if (cmd == DM_VERSION_CMD)
+   return 0;
+
+   fn = lookup_ioctl(cmd, _flags);
+   if (!fn) {
+   DMWARN("dm_ioctl: unknown command 0x%x", command);
+   return -ENOTTY;
+   }
+
+   input_param_size = param->data_size;
+   r = validate_params(cmd, param);
+   if (r)
+   return r;
+
+   param->data_size = sizeof(*param);
+   r = fn(filp, param, input_param_size);
+
+   if (unlikely(param->flags & DM_BUFFER_FULL_FLAG) &&
+   unlikely(ioctl_flags & IOCTL_FLAGS_NO_PARAMS))
+   DMERR("ioctl %d tried to output some data but has 
IOCTL_FLAGS_NO_PARAMS set", cmd);
+
+   return r;
+}
diff --git a/include/linux/device-mapper.h b/include/linux/device-mapper.h
index f4c639c..f81ba42 100644
--- a/include/linux/device-mapper.h
+++ b/include/linux/device-mapper.h
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct dm_dev;
 struct dm_target;
@@ -446,6 +447,11 @@ int dm_noflush_suspending(struct dm_target *ti);
 void dm_accept_partial_bio(struct bio *bio, unsigned n_sectors);
 union map_info *dm_get_rq_mapinfo(struct request *rq);
 
+/*
+ * Device mapper ioctl function.
+ */
+int dm_ioctl_cmd(unsigned int command, struct dm_ioctl *param);
+
 struct queue_limits *dm_get_queue_limits(struct mapped_device *md);
 
 /*
-- 
2.9.3

Re: [PATCH v2 00/10] rt2x00: rt2x00: improve calling conventions for register accessors

[Kalle Valo]

Arnd Bergmann  writes:

> On Fri, May 19, 2017 at 8:44 AM, Tom Psyborg  
> wrote:
>> warning: 'rt2800_bbp_read' used but never defined
>>  static u8 rt2800_bbp_read(struct rt2x00_dev *rt2x00dev,
>>^
>> /home/ubuntu/Music/openwrt/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7620/compat-wireless-2016-05-12/drivers/net/wireless/ralink/rt2x00/rt2800lib.h:262:13:
>> warning: 'rt2800_bbp_write' used but never defined
>>  static void rt2800_bbp_write(struct rt2x00_dev *rt2x00dev,
>>  ^
>>   CC [M]
>> /home/ubuntu/Music/openwrt/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7620/compat-wireless-2016-05-12/drivers/net/wireless/ralink/rt2x00/rt2800pci.o
>> In file included from
>> /home/ubuntu/Music/openwrt/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7620/compat-wireless-2016-05-12/drivers/net/wireless/ralink/rt2x00/rt2800pci.c:43:0:
>> /home/ubuntu/Music/openwrt/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7620/compat-wireless-2016-05-12/drivers/net/wireless/ralink/rt2x00/rt2800lib.h:259:11:
>> warning: 'rt2800_bbp_read' declared 'static' but never defined
>> [-Wunused-function]
>>  static u8 rt2800_bbp_read(struct rt2x00_dev *rt2x00dev,
>>^
>
> On which base version did you apply my patches? There may be a conflict
> against patches that are in your tree but not yet in linux-next, as I don't 
> see
> the warning and also see no reference to rt2800_bbp_read in rt2800lib.h

I did a test build with current wireless-drivers-next and I also don't
see any warnings.

-- 
Kalle Valo

Re: [PATCH v5 15/17] dt-bindings: qca7000: append UART interface to binding

[Stefan Wahren]

Hi Rob,

Am 12.05.2017 um 08:43 schrieb Jakub Kicinski:
> On Fri, 12 May 2017 06:15:52 +, Michael Heimpold wrote:
>> Hi,
>>
>> Zitat von Jakub Kicinski :
>>
>>> On Thu, 11 May 2017 21:12:22 +0200, Michael Heimpold wrote:  
 Am Mittwoch, 10. Mai 2017, 10:53:26 CEST schrieb Stefan Wahren:  
> This merges the serdev binding for the QCA7000 UART driver (Ethernet over
> UART) into the existing document.
>
> Signed-off-by: Stefan Wahren 
> ---
>  .../devicetree/bindings/net/qca-qca7000.txt| 32
> ++ 1 file changed, 32 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/qca-qca7000.txt
> b/Documentation/devicetree/bindings/net/qca-qca7000.txt index
> a37f656..08364c3 100644
> --- a/Documentation/devicetree/bindings/net/qca-qca7000.txt
> +++ b/Documentation/devicetree/bindings/net/qca-qca7000.txt
> @@ -54,3 +54,35 @@ ssp2: spi@80014000 {
>   local-mac-address = [ A0 B0 C0 D0 E0 F0 ];
>   };
>  };
> +
> +(b) Ethernet over UART
> +
> +In order to use the QCA7000 as UART slave it must be defined as
 a child of  
> a +UART master in the device tree. It is possible to preconfigure the UART
> +settings of the QCA7000 firmware, but it's not possible to change them
> during +runtime.
> +
> +Required properties:
> +- compatible: Should be "qca,qca7000-uart"  
 I already discussed this with Stefan off-list a little bit, but I would 
 like
 to bring this to a broader audience: I'm not sure whether the compatible
 should contain the "-uart" suffix, because the hardware chip is the  
 very same
 QCA7000 chip which can also be used with SPI protocol.
 The only difference is the loaded firmware within the chip which can either
 speak SPI or UART protocol (but not both at the same time - due to shared
 pins). So the hardware design decides which interface type is used.

 At the moment, this patch series adds a dedicated driver for the UART
 protocol, in parallel to the existing SPI driver. So a different compatible
 string is needed here to match against the new driver.

 An alternative approach would be to re-use the existing compatible string
 "qca,qca7000" for both, the SPI and UART protocol, because a "smarter"
 (combined) driver would detect which protocol to use. For example the 
 driver
 could check for spi-cpha and/or spi-cpol which are required for SPI  
 protocol:
 if these exists the driver could assume that SPI must be used, if both are
 missing then UART protocol should be used.
 (This way it would not be necessary to check whether the node is a child of
 a SPI or UART master node - but maybe this is even easier - I don't know)

 Or in shorter words: my concern is that while "qca7000-uart" describes the
 hardware, it's too closely coupled to the driver implementation. Having
 some feedback of the experts would be nice :-)  
>>> I'm no expert, but devices which can do both I2C and SPI are quite
>>> common, and they usually have the same compatible string for both
>>> buses.  
>> do you have an example driver at hand? I only found GPIO mcp23s08 driver,
>> which can handle both I2C and SPI chips, but there are different compatible
>> strings used to distinguish several chip models.
> I think drivers/tty/serial/sc16is7xx.c has the same strings, and some
> Kconfig magic to work when either bus is enabled in .config.
>
> Quick grep shows there are couple more potential ones to look at:
>
> $ find . -name Kconfig | xargs grep -n 'SPI_MASTER.* I2C' 
> ./drivers/tty/serial/Kconfig:1208:depends on (SPI_MASTER && !I2C) || 
> I2C
> ./drivers/mfd/Kconfig:327:depends on (SPI_MASTER || I2C)
> ./drivers/iio/dac/Kconfig:10: depends on (SPI_MASTER && I2C!=m) || I2C
> ./drivers/iio/dac/Kconfig:34: depends on (SPI_MASTER && I2C!=m) || I2C
> ./drivers/iio/dac/Kconfig:57: depends on (SPI_MASTER && I2C!=m) || I2C
> ./drivers/gpio/Kconfig:1231:  depends on (SPI_MASTER && !I2C) || I2C
> $ find . -name Kconfig | xargs grep -n 'I2C.*||.*SPI_MASTER' 
> ./drivers/mfd/Kconfig:1094:   depends on (I2C=y || SPI_MASTER=y)
> ./drivers/iio/gyro/Kconfig:55:depends on (I2C || SPI_MASTER)
> ./drivers/iio/gyro/Kconfig:107:   depends on (I2C || SPI_MASTER) && SYSFS
> ./drivers/iio/accel/Kconfig:153:  depends on (I2C || SPI_MASTER) && SYSFS
> ./drivers/iio/pressure/Kconfig:20:depends on (I2C || SPI_MASTER)
> ./drivers/iio/pressure/Kconfig:161:   depends on (I2C || SPI_MASTER) && SYSFS
> ./drivers/iio/magnetometer/Kconfig:118:   depends on (I2C || SPI_MASTER) 
> && SYSFS
>
> drivers/mfd/mc13xxx-*.c seems to have the same strings.  The iio/dac drivers
> don't support DT but do share names.  The MCP GPIO chip you mention indeed has
> different product names based on the bus it's made for (0 vs s 

Re: [PATCH v2] staging: iio: light: Replace symbolic permissions as per coding style

[Greg KH]

On Fri, May 19, 2017 at 12:33:11PM +0530, surenderpols...@gmail.com wrote:
> From: Surender Polsani 
> 
> Fixed the following checkpatch.pl warnings:
> octal permissions are more preferable than symbolic permissions
> 
> Replaced DEVICE_ATTR family macros with DEVICE_ATTR_RW family
> as suggested by Greg K-H. Changed attributes and function
> names where ever required to satisfy internal macro definitions
> like __ATTR__RW().

No you did not:

> -static DEVICE_ATTR(power_state, S_IRUGO | S_IWUSR,
> +static DEVICE_ATTR(power_state, 0644,
>   tsl2x7x_power_state_show, tsl2x7x_power_state_store);

???

Wrong patch?

Re: [PATCH 3/5] mmc: cavium: Prevent crash with incomplete DT

[Ulf Hansson]

On 16 May 2017 at 11:36, Jan Glauber  wrote:
> In case the DT specifies neither a regulator nor a gpio
> for the shared power the driver will crash accessing the regulator.
> Prevent the crash by checking the regulator before use.
>
> As the MMC devices would likely not be usable without power
> check for that condition during probe and print a warning.
>
> Signed-off-by: Jan Glauber 
> ---
>  drivers/mmc/host/cavium.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/cavium.c b/drivers/mmc/host/cavium.c
> index 58b51ba..63f96dc 100644
> --- a/drivers/mmc/host/cavium.c
> +++ b/drivers/mmc/host/cavium.c
> @@ -839,14 +839,14 @@ static void cvm_mmc_set_ios(struct mmc_host *mmc, 
> struct mmc_ios *ios)
> cvm_mmc_reset_bus(slot);
> if (host->global_pwr_gpiod)
> host->set_shared_power(host, 0);
> -   else
> +   else if (mmc->supply.vmmc)

Please do this instead:

else if (!IS_ERR(mmc->supply.vmmc))

> mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
> break;
>
> case MMC_POWER_UP:
> if (host->global_pwr_gpiod)
> host->set_shared_power(host, 1);
> -   else
> +   else if (mmc->supply.vmmc)

Ditto

> mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 
> ios->vdd);
> break;
> }
> @@ -976,6 +976,7 @@ static int cvm_mmc_of_parse(struct device *dev, struct 
> cvm_mmc_slot *slot)
>  * Legacy Octeon firmware has no regulator entry, fall-back to
>  * a hard-coded voltage to get a sane OCR.
>  */
> +   mmc->supply.vmmc = NULL;

... and then you shall remove this.

> mmc->ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
> } else {
> ret = mmc_regulator_get_ocrmask(mmc->supply.vmmc);
> @@ -983,6 +984,9 @@ static int cvm_mmc_of_parse(struct device *dev, struct 
> cvm_mmc_slot *slot)
> mmc->ocr_avail = ret;
> }
>
> +   if (!mmc->supply.vmmc && !slot->host->global_pwr_gpiod)
> +   dev_warn(dev, "Missing power regulator or gpio, device may 
> not work.\n");
> +

While you re-spins this, I suggest you to also convert to use the
mmc_regulator_get_supply() API.
That should simply the code a bit and also avoid you from needing to
print anything like this above, as there are already some printing
being done in mmc_regulator_get_supply().

> /* Common MMC bindings */
> ret = mmc_of_parse(mmc);
> if (ret)
> --
> 2.9.0.rc0.21.g322
>

Kind regards
Uffe

Re: [PATCH v2 00/10] rt2x00: rt2x00: improve calling conventions for register accessors

[Kalle Valo]

Arnd Bergmann  writes:

> On Fri, May 19, 2017 at 7:18 AM, Kalle Valo  wrote:
>> Arnd Bergmann  writes:
>>
>>> I've managed to split up my long patch into a series of reasonble
>>> steps now.
>>>
>>> The first two are required to fix a regression from commit 41977e86c984
>>> ("rt2x00: add support for MT7620"), the rest are just cleanups to
>>> have a consistent state across all the register access functions.
>>
>> Can these all go to 4.13 or would you prefer me to push the first two
>> 4.12? Or what?
>
> I think you can reasonably argue either way: the second patch does
> fix a real bug that may or may not lead to an exploitable stack overflow
> when CONFIG_KASAN is enabled, which would be a reason to put it
> into 4.12. On the other hand, I have another 20 patches for similar
> (or worse) stack overflow issues with KASAN that I'm hoping to all
> get into 4.13 and backported into stable kernel later if necessary,
> so we could treat this one like the others.
>
> The only difference between this and the others is that in rt2x00 it
> is a regression against 4.11, while the others have all been present
> for a long time.

Having all of these in 4.12 sounds a bit excessive and splitting the set
(the first two into 4.12 and the rest into 4.13) sounds too much work.
So I would prefer to queue these to 4.13, if it's ok for everyone?

-- 
Kalle Valo

Re: [linux-sunxi] [PATCH v6 9/9] arm64: allwinner: a64: enable Wi-Fi for Pine64

[Maxime Ripard]

On Fri, May 19, 2017 at 11:03:33AM +0800, Icenowy Zheng wrote:
> >The patch looks OK, but given the module is removable, I think it
> >should be
> >an overlay. The overlay would enable WiFi + Bluetooth, and all the
> >peripherals needed to connect them.
> >
> >That way, if the module is not installed, we avoid confusing the user
> >with
> >unused peripherals, and avoid having live voltage on an unoccupied
> >header.
> 
> But as this header have specific usage, we will also confuse user
> if it's not enabled as its target usage.

Yet you would enable unused resources.

This was already pointed out here:
https://patchwork.kernel.org/patch/9670235/

Maxime

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


signature.asc
Description: PGP signature

[PATCH] ext4: keep existing extra fields when inode expands

[Konstantin Khlebnikov]

ext4_expand_extra_isize() should clear only space between old and new size.

Signed-off-by: Konstantin Khlebnikov 
---
 fs/ext4/inode.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 5834c4d76be8..7204e1a2801a 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -5637,8 +5637,9 @@ static int ext4_expand_extra_isize(struct inode *inode,
/* No extended attributes present */
if (!ext4_test_inode_state(inode, EXT4_STATE_XATTR) ||
header->h_magic != cpu_to_le32(EXT4_XATTR_MAGIC)) {
-   memset((void *)raw_inode + EXT4_GOOD_OLD_INODE_SIZE, 0,
-   new_extra_isize);
+   memset((void *)raw_inode + EXT4_GOOD_OLD_INODE_SIZE +
+  EXT4_I(inode)->i_extra_isize, 0,
+  new_extra_isize - EXT4_I(inode)->i_extra_isize);
EXT4_I(inode)->i_extra_isize = new_extra_isize;
return 0;
}

Re: [PATCH v2 00/10] rt2x00: rt2x00: improve calling conventions for register accessors

[Arnd Bergmann]

On Fri, May 19, 2017 at 9:15 AM, Kalle Valo  wrote:
> Arnd Bergmann  writes:
>
>> On Fri, May 19, 2017 at 7:18 AM, Kalle Valo  wrote:
>>> Arnd Bergmann  writes:
>>>
 I've managed to split up my long patch into a series of reasonble
 steps now.

 The first two are required to fix a regression from commit 41977e86c984
 ("rt2x00: add support for MT7620"), the rest are just cleanups to
 have a consistent state across all the register access functions.
>>>
>>> Can these all go to 4.13 or would you prefer me to push the first two
>>> 4.12? Or what?
>>
>> I think you can reasonably argue either way: the second patch does
>> fix a real bug that may or may not lead to an exploitable stack overflow
>> when CONFIG_KASAN is enabled, which would be a reason to put it
>> into 4.12. On the other hand, I have another 20 patches for similar
>> (or worse) stack overflow issues with KASAN that I'm hoping to all
>> get into 4.13 and backported into stable kernel later if necessary,
>> so we could treat this one like the others.
>>
>> The only difference between this and the others is that in rt2x00 it
>> is a regression against 4.11, while the others have all been present
>> for a long time.
>
> Having all of these in 4.12 sounds a bit excessive and splitting the set
> (the first two into 4.12 and the rest into 4.13) sounds too much work.
> So I would prefer to queue these to 4.13, if it's ok for everyone?

Ok, sounds fine. Thanks,

  Arnd

Re: [PATCH 08/14] mm, compaction: skip over holes in __reset_isolation_suitable

[Vlastimil Babka]

On 05/15/2017 10:58 AM, Michal Hocko wrote:
> From: Michal Hocko 
> 
> __reset_isolation_suitable walks the whole zone pfn range and it tries
> to jump over holes by checking the zone for each page. It might still
> stumble over offline pages, though. Skip those by checking
> pfn_to_online_page()
> 
> Signed-off-by: Michal Hocko 

Acked-by: Vlastimil Babka 

> ---
>  mm/compaction.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 613c59e928cb..fb548e4c7bd4 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -236,10 +236,9 @@ static void __reset_isolation_suitable(struct zone *zone)
>  
>   cond_resched();
>  
> - if (!pfn_valid(pfn))
> + page = pfn_to_online_page(pfn);
> + if (!page)
>   continue;
> -
> - page = pfn_to_page(pfn);
>   if (zone != page_zone(page))
>   continue;
>  
> 

Re: [linux-sunxi] [PATCH v6 9/9] arm64: allwinner: a64: enable Wi-Fi for Pine64

[icenowy]

在 2017-05-19 15:19，Maxime Ripard 写道：

On Fri, May 19, 2017 at 11:03:33AM +0800, Icenowy Zheng wrote:

>The patch looks OK, but given the module is removable, I think it
>should be
>an overlay. The overlay would enable WiFi + Bluetooth, and all the
>peripherals needed to connect them.
>
>That way, if the module is not installed, we avoid confusing the user
>with
>unused peripherals, and avoid having live voltage on an unoccupied
>header.

But as this header have specific usage, we will also confuse user
if it's not enabled as its target usage.


Yet you would enable unused resources.

This was already pointed out here:
https://patchwork.kernel.org/patch/9670235/


I think, before we have an official repository of device tree
overlays (either directly in torvalds/linux or maintained by
linux-sunxi), we shouldn't rely on device tree overlay
functionality.



Maxime

___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 07/14] mm: consider zone which is not fully populated to have holes

[Vlastimil Babka]

On 05/18/2017 06:42 PM, Michal Hocko wrote:
> On Thu 18-05-17 18:14:39, Vlastimil Babka wrote:
>> On 05/15/2017 10:58 AM, Michal Hocko wrote:
> [...]
>>>  #ifdef CONFIG_MEMORY_HOTPLUG
>>> +/*
>>> + * Return page for the valid pfn only if the page is online. All pfn
>>> + * walkers which rely on the fully initialized page->flags and others
>>> + * should use this rather than pfn_valid && pfn_to_page
>>> + */
>>> +#define pfn_to_online_page(pfn)\
>>> +({ \
>>> +   struct page *___page = NULL;\
>>> +   \
>>> +   if (online_section_nr(pfn_to_section_nr(pfn)))  \
>>> +   ___page = pfn_to_page(pfn); \
>>> +   ___page;\
>>> +})
>>
>> This seems to be already assuming pfn_valid() to be true. There's no
>> "pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS" check and the comment
>> suggests as such, but...
> 
> Yes, we should check the validity of the section number. We do not have
> to check whether the section is valid because online sections are a
> subset of those that are valid.
> 
>>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>>> index 05796ee974f7..c3a146028ba6 100644
>>> --- a/mm/memory_hotplug.c
>>> +++ b/mm/memory_hotplug.c
>>> @@ -929,6 +929,9 @@ static int online_pages_range(unsigned long start_pfn, 
>>> unsigned long nr_pages,
>>> unsigned long i;
>>> unsigned long onlined_pages = *(unsigned long *)arg;
>>> struct page *page;
>>> +
>>> +   online_mem_sections(start_pfn, start_pfn + nr_pages);
>>
>> Shouldn't this be moved *below* the loop that initializes struct pages?
>> In the offline case you do mark sections offline before "tearing" struct
>> pages, so that should be symmetric.
> 
> You are right! Andrew, could you fold the following intot the patch?
> ---
> From 0550b61203d6970b47fd79f5e6372dccd143cbec Mon Sep 17 00:00:00 2001
> From: Michal Hocko 
> Date: Thu, 18 May 2017 18:38:24 +0200
> Subject: [PATCH] fold me "mm: consider zone which is not fully populated to
>  have holes"
> 
> - check valid section number in pfn_to_online_page - Vlastimil
> - mark sections online after all struct pages are initialized in
>   online_pages_range - Vlastimil
> 
> Signed-off-by: Michal Hocko 

Both the patch and fix:

Acked-by: Vlastimil Babka 

[PATCH v3] pci-sysfs: Make PCI bridge attribute visible in sysfs

[Wong Vee Khee]

From: vwong 

 In this commit, we are exposing PCIe bridges attributes
 such as secondary bus number, subordinate bus number,
 max link speed and link width, current link speed and
 link width to sysfs located in /sys/bus/pci/devices/...

 Part of the reasons we are doing this rather than getting
 these information through parsing lspci is due to the fact
 that accessing PCIe link information via lspci require root
 privilege.

 This changes also allow clients to get PCIe bridges information
 easily because lspci list out all PCIe devices.

Signed-off-by: Wong Vee Khee 
Signed-off-by: Hui Chun Ong 
---
 drivers/pci/pci-sysfs.c   | 197 +-
 include/uapi/linux/pci_regs.h |   1 +
 2 files changed, 194 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 31e9961..a2ada91 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -154,6 +154,127 @@ static ssize_t resource_show(struct device *dev, struct 
device_attribute *attr,
 }
 static DEVICE_ATTR_RO(resource);
 
+static ssize_t max_link_speed_show(struct device *dev,
+  struct device_attribute *attr, char *buf)
+{
+   struct pci_dev *pci_dev = to_pci_dev(dev);
+   u32 linkcap;
+   int err;
+   const char *speed;
+
+   err = pcie_capability_read_dword(pci_dev, PCI_EXP_LNKCAP, );
+
+   if (!err) {
+   switch (linkcap & PCI_EXP_LNKCAP_SLS) {
+   case PCI_EXP_LNKCAP_SLS_8_0GB:
+   speed = "8 GT/s";
+   break;
+   case PCI_EXP_LNKCAP_SLS_5_0GB:
+   speed = "5 GT/s";
+   break;
+   case PCI_EXP_LNKCAP_SLS_2_5GB:
+   speed = "2.5 GT/s";
+   break;
+   default:
+   speed = "Unknown speed";
+   }
+
+   return sprintf(buf, "%s\n", speed);
+   }
+
+   return -EINVAL;
+}
+static DEVICE_ATTR_RO(max_link_speed);
+
+static ssize_t max_link_width_show(struct device *dev,
+  struct device_attribute *attr, char *buf)
+{
+   struct pci_dev *pci_dev = to_pci_dev(dev);
+   u32 linkcap;
+   int err;
+
+   err = pcie_capability_read_dword(pci_dev, PCI_EXP_LNKCAP, );
+
+   return err ? -EINVAL : sprintf(
+   buf, "%u\n", (linkcap & PCI_EXP_LNKCAP_MLW) >> 4);
+}
+static DEVICE_ATTR_RO(max_link_width);
+
+static ssize_t current_link_speed_show(struct device *dev,
+  struct device_attribute *attr, char *buf)
+{
+   struct pci_dev *pci_dev = to_pci_dev(dev);
+   u16 linkstat;
+   int err;
+   const char *speed;
+
+   err = pcie_capability_read_word(pci_dev, PCI_EXP_LNKSTA, );
+
+   if (!err) {
+   switch (linkstat & PCI_EXP_LNKSTA_CLS) {
+   case PCI_EXP_LNKSTA_CLS_8_0GB:
+   speed = "8 GT/s";
+   break;
+   case PCI_EXP_LNKSTA_CLS_5_0GB:
+   speed = "5 GT/s";
+   break;
+   case PCI_EXP_LNKSTA_CLS_2_5GB:
+   speed = "2.5 GT/s";
+   break;
+   default:
+   speed = "Unknown speed";
+   }
+
+   return sprintf(buf, "%s\n", speed);
+   }
+
+   return -EINVAL;
+}
+static DEVICE_ATTR_RO(current_link_speed);
+
+static ssize_t current_link_width_show(struct device *dev,
+  struct device_attribute *attr, char *buf)
+{
+   struct pci_dev *pci_dev = to_pci_dev(dev);
+   u16 linkstat;
+   int err;
+
+   err = pcie_capability_read_word(pci_dev, PCI_EXP_LNKSTA, );
+
+   return err ? -EINVAL : sprintf(
+   buf, "%u\n",
+   (linkstat & PCI_EXP_LNKSTA_NLW) >> PCI_EXP_LNKSTA_NLW_SHIFT);
+}
+static DEVICE_ATTR_RO(current_link_width);
+
+static ssize_t secondary_bus_number_show(struct device *dev,
+struct device_attribute *attr,
+char *buf)
+{
+   struct pci_dev *pci_dev = to_pci_dev(dev);
+   u8 sec_bus;
+   int err;
+
+   err = pci_read_config_byte(pci_dev, PCI_SECONDARY_BUS, _bus);
+
+   return err ? -EINVAL : sprintf(buf, "%u\n", sec_bus);
+}
+static DEVICE_ATTR_RO(secondary_bus_number);
+
+static ssize_t subordinate_bus_number_show(struct device *dev,
+  struct device_attribute *attr,
+  char *buf)
+{
+   struct pci_dev *pci_dev = to_pci_dev(dev);
+   u8 sub_bus;
+   int err;
+
+   err = pci_read_config_byte(pci_dev, PCI_SUBORDINATE_BUS, _bus);
+
+   return err ? -EINVAL : sprintf(buf, "%u\n", sub_bus);
+}
+static 

Re: [PATCH v3 00/21] drm: sun4i: Add support for the HDMI controller

[Chen-Yu Tsai]

On Wed, May 17, 2017 at 3:40 PM, Maxime Ripard
 wrote:
> Hi,
>
> Here is an attempt at getting the HDMI controller running.
>
> This HDMI controller is found on a number of old Allwinner SoCs (A10, A10s,
> A20, A31).
>
> This driver only supports for now the A10s because it was an easy target,
> being very close to the A13 that is already supported by our DRM driver.
>
> There's nothing out of the extraordinary there, except maybe the clock
> setup. All the internal clocks (TMDS, DDC) have been modeled using the
> common clock framework, the TMDS clock being the parent of the DDC one.
>
> While this might sound overkill, other SoC have a different, external
> source for the DDC clock, which will be easier to support through the clock
> framework.
>
> The IP also supports audio (through an already supported i2s controller,
> and some missing configuration in the HDMI controller) and CEC. Both will
> come eventually.
>
> Let me know what you think!
> Maxime
>
> Changes from v2:
>   - Fixed the PLL control macros definitions
>   - Called clk_enable / disable on the DDC clock
>   - Added the flags to enable the connection polling
>   - Fixed the vtotal computation in TCON's code, and added a comment
>   - Added and documented the A10s display engine compatible
>   - Reworked the component parsing code to bail out when a standard
> connector is found
>   - Fixed a inconsistent comment in the predivider unapplication
>   - Fixed a commit log
>   - Added Chen-Yu's and Rob's Acked-By
>   - Changed divider_round_rate to a static, inline function in the header
>   - Added and document the A10s display pipeline compatible
>   - Rebased on top of 4.12
>
> Changes from v1:
>   - Fixed typos in the CCU header and the HDMI code
>   - Reintroduced the comment for the backporch timings
>   - Renamed the hdmi node to hdmi, instead of hdmi0
>   - Added support for hdmi-connector
>   - Added a separate Kconfig option for the HDMI support
>   - Changed the TCON muxing configuration for an explicit call in the
> TCON's "clients"
>   - Fixed the initialisation sequence that was clearing the clocks bits
>   - Constified the HDMI's structures and removed whitespaces errors
>   - Fixed an issue in the sunxi-ng code that was not reporting the proper
> parent clock rate if it was modified
>   - Removed unused headers
>   - Removed CLK_SET_RATE_PARENT for the DDC clock
>   - Used the DDC address defines
>   - Removed the interlace flag that wasn't supported at the moment
>   - Moved most of the HDMI encoder init to the bind function like we do for
> the other encoders
>   - Switched to drm_of_find_possible_crtcs
>   - Removed the extra printk that were still in my code
>   - Rebased on top of linux-next
>   - Removed the patch changing the divider_round_rate prototype to
> introduce a new function instead that takes the parent clock to
> evaluate
>   - Added a clk_set_rate for the hdmi module clock
>   - Fixed the V_TOTAL TCON ch0 calculation to be consistent with ch1's
>   - Defined all registers, and remove the TODOs
>   - Fixed the EDID issues by increasing the timeout.
>   - Added an atomic_check to prevent the DBLCLK modes to be used, as it is
> not supported yet
>   - Updated the binding to add the interrupts and DMA channels
>
> Maxime Ripard (21):
>   clk: divider: Make divider_round_rate take the parent clock
>   clk: sunxi-ng: Pass the parent and a pointer to the clocks round rate
>   clk: sunxi-ng: div: Switch to divider_round_rate
>   clk: sunxi-ng: mux: Don't just rely on the parent for CLK_SET_RATE_PARENT
>   clk: sunxi-ng: mux: split out the pre-divider computation code
>   clk: sunxi-ng: mux: Change pre-divider application function prototype
>   clk: sunxi-ng: mux: Re-adjust parent rate
>   clk: sunxi-ng: sun5i: Export video PLLs

Merged patches 1 ~ 8 and ...

>   drm/sun4i: tcon: Add channel debug
>   drm/sun4i: tcon: Move the muxing out of the mode set function
>   drm/sun4i: tcon: Switch mux on only for composite
>   drm/sun4i: tcon: Fix tcon channel 1 backporch calculation
>   drm/sun4i: tcon: Change vertical total size computation inconsistency
>   drm/sun4i: tcon: multiply the vtotal when not in interlace
>   drm/sun4i: Ignore the generic connectors for components
>   dt-bindings: display: sun4i: Add HDMI display bindings
>   dt-bindings: display: sun4i: Add allwinner,tcon-channel property
>   drm/sun4i: Add HDMI support
>   drm/sun4i: Add compatible for the A10s pipeline

>   ARM: sun5i: a10s: Add the HDMI controller node
>   ARM: sun5i: a10s-olinuxino: Enable HDMI

... 20 ~ 21 for 4.13.

ChenYu

Re: [PATCH v2] staging: iio: light: Replace symbolic permissions as per coding style

[suri]

On Friday 19 May 2017 12:45 PM, Greg KH wrote:

On Fri, May 19, 2017 at 12:33:11PM +0530, surenderpols...@gmail.com wrote:

From: Surender Polsani 

Fixed the following checkpatch.pl warnings:
octal permissions are more preferable than symbolic permissions

Replaced DEVICE_ATTR family macros with DEVICE_ATTR_RW family
as suggested by Greg K-H. Changed attributes and function
names where ever required to satisfy internal macro definitions
like __ATTR__RW().


No you did not:


-static DEVICE_ATTR(power_state, S_IRUGO | S_IWUSR,
+static DEVICE_ATTR(power_state, 0644,
tsl2x7x_power_state_show, tsl2x7x_power_state_store);


???

Wrong patch?



Sorry i sent wrong patch by mistake. I will send correct patch shortly.

Re: [RFC 1/6] mm, page_alloc: fix more premature OOM due to race with cpuset update

[Michal Hocko]

On Thu 18-05-17 14:07:45, Cristopher Lameter wrote:
> On Thu, 18 May 2017, Michal Hocko wrote:
> 
> > > See above. OOM Kill in a cpuset does not kill an innocent task but a task
> > > that does an allocation in that specific context meaning a task in that
> > > cpuset that also has a memory policty.
> >
> > No, the oom killer will chose the largest task in the specific NUMA
> > domain. If you just fail such an allocation then a page fault would get
> > VM_FAULT_OOM and pagefault_out_of_memory would kill a task regardless of
> > the cpusets.
> 
> Ok someone screwed up that code. There still is the determination that we
> have a constrained alloc:

It would be much more easier if you read emails more carefully. In order
to have a constrained OOM you have to have either a non-null nodemask or
zonelist which. And as I've said above you do not have them from the
pagefault_out_of_memory context. The whole point of this discussion is
_that_ failing allocations will not work currently!

> oom_kill:
>   /*
>  * Check if there were limitations on the allocation (only relevant 
> for
>  * NUMA and memcg) that may require different handling.
>  */
> constraint = constrained_alloc(oc);
> if (constraint != CONSTRAINT_MEMORY_POLICY)
> oc->nodemask = NULL;
> check_panic_on_oom(oc, constraint);
> 
> -- Ok. A constrained failing alloc used to terminate the allocating
>   process here. But it falls through to selecting a "bad process"

This behavior is there for ~10 years.
[...]
> Can we restore the old behavior? If I just specify the right memory policy
> I can cause other processes to just be terminated?

Not normally. Because out_of_memory called from the page allocator
context makes sure to kill tasks from the same NUMA domain (see
oom_unkillable_task).
 
> > > Regardless of that the point earlier was that the moving logic can avoid
> > > creating temporary situations of empty sets of nodes by analysing the
> > > memory policies etc and only performing moves when doing so is safe.
> >
> > How are you going to do that in a raceless way? Moreover the whole
> > discussion is about _failing_ allocations on an empty cpuset and
> > mempolicy intersection.
> 
> Again this is only working for processes that are well behaved and it
> never worked in a different way before. There was always the assumption
> that a process does not allocate in the areas that have allocation
> constraints and that the process does not change memory policies nor
> store them somewhere for late etc etc. HPC apps typically allocate memory
> on startup and then go through long times of processing and I/O.

I would call it a bad design which then triggered a lot of work to make
it semi-working over years. This is what Vlastimil tries to address now.
And yes that might mean we would have to do some restrictions on the
semantics. But as you know this is a user visible API and changing
something that has been fundamentally underdefined initially is quite
hard to fix.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH -next] drm/i915: Fix return value check in kfence selftests

[Chris Wilson]

On Fri, May 19, 2017 at 12:26:05AM +, Wei Yongjun wrote:
> From: Wei Yongjun 
> 
> Fix the return value check which testing the wrong variable.

Already fixed up yesterday:

commit ac0a73fb526100adc521ec2069623e47ca3997a8
Author: Colin Ian King 
Date:   Thu May 18 14:39:42 2017 +0100

drm/i915: Check C for null pointer rather than B

Thanks for the patch.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [PATCH] mmc: block: use memdup_user

[Ulf Hansson]

On 13 May 2017 at 05:15, Geliang Tang  wrote:
> Use memdup_user() helper instead of open-coding to simplify the code.
>
> Signed-off-by: Geliang Tang 
> ---
>  drivers/mmc/core/block.c | 14 --
>  1 file changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
> index 8273b07..47ccb2a 100644
> --- a/drivers/mmc/core/block.c
> +++ b/drivers/mmc/core/block.c
> @@ -342,21 +342,15 @@ static struct mmc_blk_ioc_data 
> *mmc_blk_ioctl_copy_from_user(
> return idata;
> }
>
> -   idata->buf = kmalloc(idata->buf_bytes, GFP_KERNEL);
> -   if (!idata->buf) {
> -   err = -ENOMEM;
> +   idata->buf = memdup_user((void __user *)(unsigned long)
> +idata->ic.data_ptr, idata->buf_bytes);
> +   if (IS_ERR(idata->buf)) {
> +   err = PTR_ERR(idata->buf);
> goto idata_err;
> }
>
> -   if (copy_from_user(idata->buf, (void __user *)(unsigned long)
> -   idata->ic.data_ptr, 
> idata->buf_bytes)) {
> -   err = -EFAULT;
> -   goto copy_err;
> -   }
> -
> return idata;
>
> -copy_err:
> kfree(idata->buf);

As we aren't using the copy_err label no more, you can also remove the
above line.

>  idata_err:
> kfree(idata);
> --
> 2.9.3
>

Kind regards
Uffe

[PATCH v2 0/8] fujitsu-laptop: use device-specific data instead of module-wide globals

[Michał Kępień]

fujitsu-laptop registers two ACPI drivers that access each other's
module-wide structures.  To improve data encapsulation and lay the
groundwork for separating the two aforementioned ACPI drivers into
separate modules, move away from module-wide global data structures by
using device-specific data instead.

To avoid breaking a working feature (backlight power synchronization
upon module load), this series leaves the module-wide struct fujitsu_bl
in place.  It will be taken care of when the backlight driver is split
into a separate module.

As we agreed that grabbing a handle to an ACPI device using its absolute
path is not a truly elegant solution, this series uses a different
approach to call_fext_func() than v1.  By passing that function a
pointer to a struct acpi_device instead of an acpi_handle, all relevant
static functions of the module will now use the same type for their
first argument and the acpi_handle fields of both module-wide structures
are removed altogether.

This patch series was tested on a Lifebook S7020 and a Lifebook E744.

As with v1, adhering to the "one logical change per patch" rule was
tricky.  If the changes introduced are illegible, I will be happy to
further explain and/or improve the series.  Using --color-words should
make reviewing much more manageable.

Changes from v1:

  - Drop patch 01/10 from v1, i.e. do not introduce fext_*() helper
functions.

  - Drop patch 02/10 from v1 as the acpi_handle fields of both
module-wide structures are removed altogether by other patches.

  - Replace patch 03/10 from v1 with patch 6/8, passing call_fext_func()
a pointer to struct acpi_device instead of an acpi_handle.

  - Drop patch 04/10 from v1, thus deferring driver separation until the
split into separate modules.  Consider patch 5/8 a partial spiritual
successor ;)  More information is available in the commit message of
that patch.

  - Add an additional check to patch 2/8 to avoid a NULL dereference
which could happen due to patch 04/10 from v1 being dropped.

  - Do not store ACPI handles in private structures.  Instead, extract
them directly from struct acpi_device pointers passed as function
arguments.

  - Updated commit messages.

  - As the above might be a bit confusing, here is the patch number
mapping from v1 to v2:

v1| v2
--+
01/10 | dropped
02/10 | dropped
03/10 | 6/8
04/10 | 5/8
05/10 | 1/8
06/10 | 2/8
07/10 | 3/8
08/10 | 4/8
09/10 | 7/8
10/10 | 8/8

 drivers/platform/x86/fujitsu-laptop.c | 417 +-
 1 file changed, 213 insertions(+), 204 deletions(-)

-- 
2.13.0

[PATCH v2 4/8] platform/x86: fujitsu-laptop: allocate struct fujitsu_laptop in acpi_fujitsu_laptop_add()

[Michał Kępień]

Only allocate memory for struct fujitsu_laptop when the FUJ02E3 ACPI
device is present.  Use devm_kzalloc() for allocating memory to simplify
cleanup.

Signed-off-by: Michał Kępień 
---
 drivers/platform/x86/fujitsu-laptop.c | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/platform/x86/fujitsu-laptop.c 
b/drivers/platform/x86/fujitsu-laptop.c
index 1124070aad2d..3916f0ae59f3 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -776,6 +776,7 @@ static int acpi_fujitsu_laptop_leds_register(struct 
acpi_device *device)
 
 static int acpi_fujitsu_laptop_add(struct acpi_device *device)
 {
+   struct fujitsu_laptop *priv;
int state = 0;
int error;
int i;
@@ -783,11 +784,16 @@ static int acpi_fujitsu_laptop_add(struct acpi_device 
*device)
if (!device)
return -EINVAL;
 
+   priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
+   if (!priv)
+   return -ENOMEM;
+
+   fujitsu_laptop = priv;
fujitsu_laptop->acpi_handle = device->handle;
sprintf(acpi_device_name(device), "%s",
ACPI_FUJITSU_LAPTOP_DEVICE_NAME);
sprintf(acpi_device_class(device), "%s", ACPI_FUJITSU_CLASS);
-   device->driver_data = fujitsu_laptop;
+   device->driver_data = priv;
 
/* kfifo */
spin_lock_init(_laptop->fifo_lock);
@@ -1014,22 +1020,14 @@ static int __init fujitsu_init(void)
 
/* Register laptop driver */
 
-   fujitsu_laptop = kzalloc(sizeof(struct fujitsu_laptop), GFP_KERNEL);
-   if (!fujitsu_laptop) {
-   ret = -ENOMEM;
-   goto err_unregister_platform_driver;
-   }
-
ret = acpi_bus_register_driver(_fujitsu_laptop_driver);
if (ret)
-   goto err_free_fujitsu_laptop;
+   goto err_unregister_platform_driver;
 
pr_info("driver " FUJITSU_DRIVER_VERSION " successfully loaded\n");
 
return 0;
 
-err_free_fujitsu_laptop:
-   kfree(fujitsu_laptop);
 err_unregister_platform_driver:
platform_driver_unregister(_pf_driver);
 err_unregister_acpi:
@@ -1042,8 +1040,6 @@ static void __exit fujitsu_cleanup(void)
 {
acpi_bus_unregister_driver(_fujitsu_laptop_driver);
 
-   kfree(fujitsu_laptop);
-
platform_driver_unregister(_pf_driver);
 
acpi_bus_unregister_driver(_fujitsu_bl_driver);
-- 
2.13.0

[PATCH v2 8/8] platform/x86: fujitsu-laptop: use device-specific data in remaining module code

[Michał Kępień]

To avoid using module-wide data in remaining module code, employ
acpi_driver_data() and dev_get_drvdata() to fetch device-specific data
to work on in each function.  This makes the input local variables in
hotkey-related callbacks and the module-wide struct fujitsu_laptop
redundant, so remove them.  Adjust whitespace to make checkpatch happy.

Signed-off-by: Michał Kępień 
---
 drivers/platform/x86/fujitsu-laptop.c | 123 ++
 1 file changed, 64 insertions(+), 59 deletions(-)

diff --git a/drivers/platform/x86/fujitsu-laptop.c 
b/drivers/platform/x86/fujitsu-laptop.c
index 3d33be9f88f6..1c6fdd952c75 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -152,7 +152,6 @@ struct fujitsu_laptop {
int flags_state;
 };
 
-static struct fujitsu_laptop *fujitsu_laptop;
 static struct acpi_device *fext;
 
 #ifdef CONFIG_FUJITSU_LAPTOP_DEBUG
@@ -290,9 +289,11 @@ static const struct backlight_ops fujitsu_bl_ops = {
 static ssize_t lid_show(struct device *dev, struct device_attribute *attr,
char *buf)
 {
-   if (!(fujitsu_laptop->flags_supported & FLAG_LID))
+   struct fujitsu_laptop *priv = dev_get_drvdata(dev);
+
+   if (!(priv->flags_supported & FLAG_LID))
return sprintf(buf, "unknown\n");
-   if (fujitsu_laptop->flags_state & FLAG_LID)
+   if (priv->flags_state & FLAG_LID)
return sprintf(buf, "open\n");
else
return sprintf(buf, "closed\n");
@@ -301,9 +302,11 @@ static ssize_t lid_show(struct device *dev, struct 
device_attribute *attr,
 static ssize_t dock_show(struct device *dev, struct device_attribute *attr,
 char *buf)
 {
-   if (!(fujitsu_laptop->flags_supported & FLAG_DOCK))
+   struct fujitsu_laptop *priv = dev_get_drvdata(dev);
+
+   if (!(priv->flags_supported & FLAG_DOCK))
return sprintf(buf, "unknown\n");
-   if (fujitsu_laptop->flags_state & FLAG_DOCK)
+   if (priv->flags_state & FLAG_DOCK)
return sprintf(buf, "docked\n");
else
return sprintf(buf, "undocked\n");
@@ -312,9 +315,11 @@ static ssize_t dock_show(struct device *dev, struct 
device_attribute *attr,
 static ssize_t radios_show(struct device *dev, struct device_attribute *attr,
   char *buf)
 {
-   if (!(fujitsu_laptop->flags_supported & FLAG_RFKILL))
+   struct fujitsu_laptop *priv = dev_get_drvdata(dev);
+
+   if (!(priv->flags_supported & FLAG_RFKILL))
return sprintf(buf, "unknown\n");
-   if (fujitsu_laptop->flags_state & FLAG_RFKILL)
+   if (priv->flags_state & FLAG_RFKILL)
return sprintf(buf, "on\n");
else
return sprintf(buf, "killed\n");
@@ -571,19 +576,22 @@ static int acpi_fujitsu_laptop_input_setup(struct 
acpi_device *device)
return input_register_device(priv->input);
 }
 
-static int fujitsu_laptop_platform_add(void)
+static int fujitsu_laptop_platform_add(struct acpi_device *device)
 {
+   struct fujitsu_laptop *priv = acpi_driver_data(device);
int ret;
 
-   fujitsu_laptop->pf_device = platform_device_alloc("fujitsu-laptop", -1);
-   if (!fujitsu_laptop->pf_device)
+   priv->pf_device = platform_device_alloc("fujitsu-laptop", -1);
+   if (!priv->pf_device)
return -ENOMEM;
 
-   ret = platform_device_add(fujitsu_laptop->pf_device);
+   platform_set_drvdata(priv->pf_device, priv);
+
+   ret = platform_device_add(priv->pf_device);
if (ret)
goto err_put_platform_device;
 
-   ret = sysfs_create_group(_laptop->pf_device->dev.kobj,
+   ret = sysfs_create_group(>pf_device->dev.kobj,
 _pf_attribute_group);
if (ret)
goto err_del_platform_device;
@@ -591,18 +599,20 @@ static int fujitsu_laptop_platform_add(void)
return 0;
 
 err_del_platform_device:
-   platform_device_del(fujitsu_laptop->pf_device);
+   platform_device_del(priv->pf_device);
 err_put_platform_device:
-   platform_device_put(fujitsu_laptop->pf_device);
+   platform_device_put(priv->pf_device);
 
return ret;
 }
 
-static void fujitsu_laptop_platform_remove(void)
+static void fujitsu_laptop_platform_remove(struct acpi_device *device)
 {
-   sysfs_remove_group(_laptop->pf_device->dev.kobj,
+   struct fujitsu_laptop *priv = acpi_driver_data(device);
+
+   sysfs_remove_group(>pf_device->dev.kobj,
   _pf_attribute_group);
-   platform_device_unregister(fujitsu_laptop->pf_device);
+   platform_device_unregister(priv->pf_device);
 }
 
 static int logolamp_set(struct led_classdev *cdev,
@@ -798,16 +808,15 @@ static int acpi_fujitsu_laptop_add(struct acpi_device 
*device)
WARN_ONCE(fext, "More than one FUJ02E3 ACPI device was found.  Driver 
may not work as 

[PATCH v2 3/8] platform/x86: fujitsu-laptop: use device-specific data in backlight code

[Michał Kępień]

To prevent using module-wide data in backlight-related code, employ
acpi_driver_data() and bl_get_data() where possible to fetch
device-specific data to work on in each function.  This makes the input
local variable in acpi_fujitsu_bl_notify() and the acpi_handle field of
struct fujitsu_bl redundant, so remove them.

Signed-off-by: Michał Kępień 
---
 drivers/platform/x86/fujitsu-laptop.c | 75 ++-
 1 file changed, 38 insertions(+), 37 deletions(-)

diff --git a/drivers/platform/x86/fujitsu-laptop.c 
b/drivers/platform/x86/fujitsu-laptop.c
index 63a9b98967fa..1124070aad2d 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -130,7 +130,6 @@
 
 /* Device controlling the backlight and associated keys */
 struct fujitsu_bl {
-   acpi_handle acpi_handle;
struct input_dev *input;
char phys[32];
struct backlight_device *bl_device;
@@ -189,14 +188,15 @@ static int call_fext_func(int func, int op, int feature, 
int state)
 
 /* Hardware access for LCD brightness control */
 
-static int set_lcd_level(int level)
+static int set_lcd_level(struct acpi_device *device, int level)
 {
+   struct fujitsu_bl *priv = acpi_driver_data(device);
acpi_status status;
char *method;
 
switch (use_alt_lcd_levels) {
case -1:
-   if (acpi_has_method(fujitsu_bl->acpi_handle, "SBL2"))
+   if (acpi_has_method(device->handle, "SBL2"))
method = "SBL2";
else
method = "SBLL";
@@ -212,71 +212,74 @@ static int set_lcd_level(int level)
vdbg_printk(FUJLAPTOP_DBG_TRACE, "set lcd level via %s [%d]\n",
method, level);
 
-   if (level < 0 || level >= fujitsu_bl->max_brightness)
+   if (level < 0 || level >= priv->max_brightness)
return -EINVAL;
 
-   status = acpi_execute_simple_method(fujitsu_bl->acpi_handle, method,
-   level);
+   status = acpi_execute_simple_method(device->handle, method, level);
if (ACPI_FAILURE(status)) {
vdbg_printk(FUJLAPTOP_DBG_ERROR, "Failed to evaluate %s\n",
method);
return -ENODEV;
}
 
-   fujitsu_bl->brightness_level = level;
+   priv->brightness_level = level;
 
return 0;
 }
 
-static int get_lcd_level(void)
+static int get_lcd_level(struct acpi_device *device)
 {
+   struct fujitsu_bl *priv = acpi_driver_data(device);
unsigned long long state = 0;
acpi_status status = AE_OK;
 
vdbg_printk(FUJLAPTOP_DBG_TRACE, "get lcd level via GBLL\n");
 
-   status = acpi_evaluate_integer(fujitsu_bl->acpi_handle, "GBLL", NULL,
-  );
+   status = acpi_evaluate_integer(device->handle, "GBLL", NULL, );
if (ACPI_FAILURE(status))
return 0;
 
-   fujitsu_bl->brightness_level = state & 0x0fff;
+   priv->brightness_level = state & 0x0fff;
 
-   return fujitsu_bl->brightness_level;
+   return priv->brightness_level;
 }
 
-static int get_max_brightness(void)
+static int get_max_brightness(struct acpi_device *device)
 {
+   struct fujitsu_bl *priv = acpi_driver_data(device);
unsigned long long state = 0;
acpi_status status = AE_OK;
 
vdbg_printk(FUJLAPTOP_DBG_TRACE, "get max lcd level via RBLL\n");
 
-   status = acpi_evaluate_integer(fujitsu_bl->acpi_handle, "RBLL", NULL,
-  );
+   status = acpi_evaluate_integer(device->handle, "RBLL", NULL, );
if (ACPI_FAILURE(status))
return -1;
 
-   fujitsu_bl->max_brightness = state;
+   priv->max_brightness = state;
 
-   return fujitsu_bl->max_brightness;
+   return priv->max_brightness;
 }
 
 /* Backlight device stuff */
 
 static int bl_get_brightness(struct backlight_device *b)
 {
-   return b->props.power == FB_BLANK_POWERDOWN ? 0 : get_lcd_level();
+   struct acpi_device *device = bl_get_data(b);
+
+   return b->props.power == FB_BLANK_POWERDOWN ? 0 : get_lcd_level(device);
 }
 
 static int bl_update_status(struct backlight_device *b)
 {
+   struct acpi_device *device = bl_get_data(b);
+
if (b->props.power == FB_BLANK_POWERDOWN)
call_fext_func(FUNC_BACKLIGHT, 0x1, 0x4, 0x3);
else
call_fext_func(FUNC_BACKLIGHT, 0x1, 0x4, 0x0);
 
-   return set_lcd_level(b->props.brightness);
+   return set_lcd_level(device, b->props.brightness);
 }
 
 static const struct backlight_ops fujitsu_bl_ops = {
@@ -372,20 +375,21 @@ static int acpi_fujitsu_bl_input_setup(struct acpi_device 
*device)
 
 static int fujitsu_backlight_register(struct acpi_device *device)
 {
+   struct fujitsu_bl *priv = acpi_driver_data(device);
const struct backlight_properties props = {
-   

[PATCH v2 7/8] platform/x86: fujitsu-laptop: use device-specific data in LED-related code

[Michał Kępień]

In order to perform their duties, all LED callbacks need a pointer to
the struct acpi_device representing the FUJ02E3 ACPI device.  To limit
the use of the module-wide pointer, the same pointer should be extracted
from data that gets passed to LED callbacks as arguments.  However, LED
core does not currently support supplying driver-specific pointers to
struct led_classdev callbacks, so the latter have to be implemented a
bit differently than backlight device callbacks and platform device
attribute callbacks.  As the FUJ02E3 ACPI device is the parent device of
all LED class devices registered by fujitsu-laptop, struct acpi_device
representing the former can be extracted by following the parent link
present inside the struct device belonging to the struct led_classdev
passed as an argument to each LED callback.

To get rid of module-wide structures defining LED class devices,
allocate them dynamically using devm_kzalloc() and initialize them in
acpi_fujitsu_laptop_leds_register().

Signed-off-by: Michał Kępień 
---
 drivers/platform/x86/fujitsu-laptop.c | 102 +-
 1 file changed, 52 insertions(+), 50 deletions(-)

diff --git a/drivers/platform/x86/fujitsu-laptop.c 
b/drivers/platform/x86/fujitsu-laptop.c
index b78c97ebfee4..3d33be9f88f6 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -608,6 +608,7 @@ static void fujitsu_laptop_platform_remove(void)
 static int logolamp_set(struct led_classdev *cdev,
enum led_brightness brightness)
 {
+   struct acpi_device *device = to_acpi_device(cdev->dev->parent);
int poweron = FUNC_LED_ON, always = FUNC_LED_ON;
int ret;
 
@@ -617,136 +618,128 @@ static int logolamp_set(struct led_classdev *cdev,
if (brightness < LED_FULL)
always = FUNC_LED_OFF;
 
-   ret = call_fext_func(fext, FUNC_LEDS, 0x1, LOGOLAMP_POWERON, poweron);
+   ret = call_fext_func(device, FUNC_LEDS, 0x1, LOGOLAMP_POWERON, poweron);
if (ret < 0)
return ret;
 
-   return call_fext_func(fext, FUNC_LEDS, 0x1, LOGOLAMP_ALWAYS, always);
+   return call_fext_func(device, FUNC_LEDS, 0x1, LOGOLAMP_ALWAYS, always);
 }
 
 static enum led_brightness logolamp_get(struct led_classdev *cdev)
 {
+   struct acpi_device *device = to_acpi_device(cdev->dev->parent);
int ret;
 
-   ret = call_fext_func(fext, FUNC_LEDS, 0x2, LOGOLAMP_ALWAYS, 0x0);
+   ret = call_fext_func(device, FUNC_LEDS, 0x2, LOGOLAMP_ALWAYS, 0x0);
if (ret == FUNC_LED_ON)
return LED_FULL;
 
-   ret = call_fext_func(fext, FUNC_LEDS, 0x2, LOGOLAMP_POWERON, 0x0);
+   ret = call_fext_func(device, FUNC_LEDS, 0x2, LOGOLAMP_POWERON, 0x0);
if (ret == FUNC_LED_ON)
return LED_HALF;
 
return LED_OFF;
 }
 
-static struct led_classdev logolamp_led = {
-   .name = "fujitsu::logolamp",
-   .brightness_set_blocking = logolamp_set,
-   .brightness_get = logolamp_get
-};
-
 static int kblamps_set(struct led_classdev *cdev,
   enum led_brightness brightness)
 {
+   struct acpi_device *device = to_acpi_device(cdev->dev->parent);
+
if (brightness >= LED_FULL)
-   return call_fext_func(fext, FUNC_LEDS, 0x1, KEYBOARD_LAMPS,
+   return call_fext_func(device, FUNC_LEDS, 0x1, KEYBOARD_LAMPS,
  FUNC_LED_ON);
else
-   return call_fext_func(fext, FUNC_LEDS, 0x1, KEYBOARD_LAMPS,
+   return call_fext_func(device, FUNC_LEDS, 0x1, KEYBOARD_LAMPS,
  FUNC_LED_OFF);
 }
 
 static enum led_brightness kblamps_get(struct led_classdev *cdev)
 {
+   struct acpi_device *device = to_acpi_device(cdev->dev->parent);
enum led_brightness brightness = LED_OFF;
 
-   if (call_fext_func(fext,
+   if (call_fext_func(device,
   FUNC_LEDS, 0x2, KEYBOARD_LAMPS, 0x0) == FUNC_LED_ON)
brightness = LED_FULL;
 
return brightness;
 }
 
-static struct led_classdev kblamps_led = {
-   .name = "fujitsu::kblamps",
-   .brightness_set_blocking = kblamps_set,
-   .brightness_get = kblamps_get
-};
-
 static int radio_led_set(struct led_classdev *cdev,
 enum led_brightness brightness)
 {
+   struct acpi_device *device = to_acpi_device(cdev->dev->parent);
+
if (brightness >= LED_FULL)
-   return call_fext_func(fext, FUNC_FLAGS, 0x5, RADIO_LED_ON,
+   return call_fext_func(device, FUNC_FLAGS, 0x5, RADIO_LED_ON,
  RADIO_LED_ON);
else
-   return call_fext_func(fext, FUNC_FLAGS, 0x5, RADIO_LED_ON,
+   return call_fext_func(device, FUNC_FLAGS, 0x5, RADIO_LED_ON,
  0x0);
 }
 
 static enum led_brightness radio_led_get(struct led_classdev