[PATCH 6/7] PM: i2c-designware-platdrv: Optimize power management

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

Optimize the power management in i2c-designware-platdrv by making it
set the DPM_FLAG_SMART_SUSPEND and DPM_FLAG_LEAVE_SUSPENDED which
allows some code to be dropped from its PM callbacks.

First, setting DPM_FLAG_SMART_SUSPEND causes the intel-lpss driver
to avoid resuming i2c-designware-platdrv devices in its ->prepare
callback, so they can stay in runtime suspend after that point even
if the direct-complete feature is not used for them.

It also causes the ACPI PM domain and the PM core to avoid invoking
"late" and "noirq" suspend callbacks for these devices if they are
in runtime suspend at the beginning of the "late" phase of device
suspend during system suspend.  That guarantees dw_i2c_plat_suspend()
to be called for a device only if it is not in runtime suspend.

Moreover, it causes the device's runtime PM status to be set to
"active" after calling dw_i2c_plat_resume() for it, so the
driver doesn't need internal flags to avoid invoking either
dw_i2c_plat_suspend() or dw_i2c_plat_resume() twice in a row.

Second, setting DPM_FLAG_LEAVE_SUSPENDED enables the optimization
allowing the device to stay suspended after system resume under
suitable conditions, so again the driver doesn't need to take
care of that by itself.

Accordingly, the internal "suspended" and "skip_resume" flags
used by the driver are not necessary any more, so drop them and
simplify the driver's PM callbacks.

Additionally, notice that dw_i2c_plat_complete() only needs to
schedule runtime PM resume for the device if platform firmware
has been involved in resuming the system, so make it call
pm_resume_via_firmware() to check that.  Also make it check the
runtime PM status of the device instead of its direct_complete
flag which also works if the device remained suspended due to
the DPM_FLAG_LEAVE_SUSPENDED driver flag.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/i2c/busses/i2c-designware-core.h|2 -
 drivers/i2c/busses/i2c-designware-platdrv.c |   31 ++--
 2 files changed, 12 insertions(+), 21 deletions(-)

Index: linux-pm/drivers/i2c/busses/i2c-designware-core.h
===
--- linux-pm.orig/drivers/i2c/busses/i2c-designware-core.h
+++ linux-pm/drivers/i2c/busses/i2c-designware-core.h
@@ -280,8 +280,6 @@ struct dw_i2c_dev {
int (*acquire_lock)(struct dw_i2c_dev *dev);
void(*release_lock)(struct dw_i2c_dev *dev);
boolpm_disabled;
-   boolsuspended;
-   boolskip_resume;
void(*disable)(struct dw_i2c_dev *dev);
void(*disable_int)(struct dw_i2c_dev *dev);
int (*init)(struct dw_i2c_dev *dev);
Index: linux-pm/drivers/i2c/busses/i2c-designware-platdrv.c
===
--- linux-pm.orig/drivers/i2c/busses/i2c-designware-platdrv.c
+++ linux-pm/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "i2c-designware-core.h"
 
@@ -372,7 +373,10 @@ static int dw_i2c_plat_probe(struct plat
ACPI_COMPANION_SET(>dev, ACPI_COMPANION(>dev));
adap->dev.of_node = pdev->dev.of_node;
 
-   dev_pm_set_driver_flags(>dev, DPM_FLAG_SMART_PREPARE);
+   dev_pm_set_driver_flags(>dev,
+   DPM_FLAG_SMART_PREPARE |
+   DPM_FLAG_SMART_SUSPEND |
+   DPM_FLAG_LEAVE_SUSPENDED);
 
/* The code below assumes runtime PM to be disabled. */
WARN_ON(pm_runtime_enabled(>dev));
@@ -448,7 +452,13 @@ static int dw_i2c_plat_prepare(struct de
 
 static void dw_i2c_plat_complete(struct device *dev)
 {
-   if (dev->power.direct_complete)
+   /*
+* The device can only be in runtime suspend at this point if it has not
+* been resumed throughout the ending system suspend/resume cycle, so if
+* the platform firmware might mess up with it, request the runtime PM
+* framework to resume it.
+*/
+   if (pm_runtime_suspended(dev) && pm_resume_via_firmware())
pm_request_resume(dev);
 }
 #else
@@ -461,16 +471,9 @@ static int dw_i2c_plat_suspend(struct de
 {
struct dw_i2c_dev *i_dev = dev_get_drvdata(dev);
 
-   if (i_dev->suspended) {
-   i_dev->skip_resume = true;
-   return 0;
-   }
-
i_dev->disable(i_dev);
i2c_dw_plat_prepare_clk(i_dev, false);
 
-   i_dev->suspended = true;
-
return 0;
 }
 
@@ -478,19 +481,9 @@ static int dw_i2c_plat_resume(struct dev
 {
struct dw_i2c_dev *i_dev = dev_get_drvdata(dev);
 
-   if (!i_dev->suspended)
-   return 0;
-
-   if (i_dev->skip_resume) {
-   i_dev->skip_resume = 

[PATCH 0/7] PM / core: Direct handling of DPM_FLAG_SMART_SUSPEND and DPM_FLAG_LEAVE_SUSPENDED

[Rafael J. Wysocki]

On Sunday, December 10, 2017 12:55:23 AM CET Rafael J. Wysocki wrote:
> Hi All,
> 
> This series is a follow-up for
> 
> https://marc.info/?l=linux-doc=151101644105835=2
> 
> Patches[1-3/6] from the above have been reviewed and agreed on, so
> they are in linux-next now and here's a next version of the rest.
> 
> Patches [1-2/4] are preparatory.  The first one is just really small
> code duplication avoidance on top of this recent fix:
> 
> https://patchwork.kernel.org/patch/10097563/
> 
> and the second one simply moves some code to separate functions.
> 
> Patch [3/4] causes the PM core to carry out some optimizations for
> drivers of devices with DPM_FLAG_SMART_SUSPEND set whose "late"
> and "noirq" suspend (or equivalent) driver callbacks are invoked
> directly by the core.
> 
> The underlying observation is that if the device is suspended (via
> runtime PM) during the "late suspend" phase of a system transition,
> invoking the "late" and "noirq" callbacks from the driver for it is not
> going to make it more suspended, so to speak, so it doesn't make sense to
> invoke them at all.
> 
> [That optimization is only done for devices with DPM_FLAG_SMART_SUSPEND
> set, because drivers setting that flag are expected to be prepared for
> skipping their "late" and "noirq" callbacks if the device is already
> suspended.]
> 
> Patch [4/4] makes the core do an analogous thing for devices with
> DPM_FLAG_LEAVE_SUSPENDED set whose "noirq" and "early" resume (or
> equivalent) driver callbacks are directly invoked by the core.
> 
> In that case the observation is that if such devices can be left in
> suspend after the system transition to the working state, running
> resume callbacks from their drivers is simply not necessary.
> 
> Pathes [3-4/4] have been reoredered and reworked a bit since the last
> iteration, so they are regarded as new.
> 
> The series is on top of the linux-next branch of the linux-pm.git tree
> that should be merged into linux-next on Monday.
> 
> [I have developed debug bus type and driver modules to test that code,
> but they are not ready to be made available at this point.]

Resending the original series (except for the first patch that has been
applied already) along with some driver code changes based on them as
requested by Ulf.

The driver patches are an intel-lpss change (already reviewed), two
modifications of i2c-designware-platdrv (posted previously but slightly
changed since then) and a PCIe port driver change.

At this point patches [1-3/7] are pretty much on the way in and the driver
material depends on review comments (it is pointless to apply [4/7] without
[5-6/7], so it depends on them in my view).

I'm sending this from a system running with all of the series applied, although
admittedly not using i2c-designware-platdrv.  However, one of my test machines
has this one and I haven't seen any adverse effects of these changes on it so
far.

Thanks,
Rafael

[PATCH 6/7] PM: i2c-designware-platdrv: Optimize power management

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

Optimize the power management in i2c-designware-platdrv by making it
set the DPM_FLAG_SMART_SUSPEND and DPM_FLAG_LEAVE_SUSPENDED which
allows some code to be dropped from its PM callbacks.

First, setting DPM_FLAG_SMART_SUSPEND causes the intel-lpss driver
to avoid resuming i2c-designware-platdrv devices in its ->prepare
callback, so they can stay in runtime suspend after that point even
if the direct-complete feature is not used for them.

It also causes the ACPI PM domain and the PM core to avoid invoking
"late" and "noirq" suspend callbacks for these devices if they are
in runtime suspend at the beginning of the "late" phase of device
suspend during system suspend.  That guarantees dw_i2c_plat_suspend()
to be called for a device only if it is not in runtime suspend.

Moreover, it causes the device's runtime PM status to be set to
"active" after calling dw_i2c_plat_resume() for it, so the
driver doesn't need internal flags to avoid invoking either
dw_i2c_plat_suspend() or dw_i2c_plat_resume() twice in a row.

Second, setting DPM_FLAG_LEAVE_SUSPENDED enables the optimization
allowing the device to stay suspended after system resume under
suitable conditions, so again the driver doesn't need to take
care of that by itself.

Accordingly, the internal "suspended" and "skip_resume" flags
used by the driver are not necessary any more, so drop them and
simplify the driver's PM callbacks.

Additionally, notice that dw_i2c_plat_complete() only needs to
schedule runtime PM resume for the device if platform firmware
has been involved in resuming the system, so make it call
pm_resume_via_firmware() to check that.  Also make it check the
runtime PM status of the device instead of its direct_complete
flag which also works if the device remained suspended due to
the DPM_FLAG_LEAVE_SUSPENDED driver flag.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/i2c/busses/i2c-designware-core.h|2 -
 drivers/i2c/busses/i2c-designware-platdrv.c |   31 ++--
 2 files changed, 12 insertions(+), 21 deletions(-)

Index: linux-pm/drivers/i2c/busses/i2c-designware-core.h
===
--- linux-pm.orig/drivers/i2c/busses/i2c-designware-core.h
+++ linux-pm/drivers/i2c/busses/i2c-designware-core.h
@@ -280,8 +280,6 @@ struct dw_i2c_dev {
int (*acquire_lock)(struct dw_i2c_dev *dev);
void(*release_lock)(struct dw_i2c_dev *dev);
boolpm_disabled;
-   boolsuspended;
-   boolskip_resume;
void(*disable)(struct dw_i2c_dev *dev);
void(*disable_int)(struct dw_i2c_dev *dev);
int (*init)(struct dw_i2c_dev *dev);
Index: linux-pm/drivers/i2c/busses/i2c-designware-platdrv.c
===
--- linux-pm.orig/drivers/i2c/busses/i2c-designware-platdrv.c
+++ linux-pm/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "i2c-designware-core.h"
 
@@ -372,7 +373,10 @@ static int dw_i2c_plat_probe(struct plat
ACPI_COMPANION_SET(>dev, ACPI_COMPANION(>dev));
adap->dev.of_node = pdev->dev.of_node;
 
-   dev_pm_set_driver_flags(>dev, DPM_FLAG_SMART_PREPARE);
+   dev_pm_set_driver_flags(>dev,
+   DPM_FLAG_SMART_PREPARE |
+   DPM_FLAG_SMART_SUSPEND |
+   DPM_FLAG_LEAVE_SUSPENDED);
 
/* The code below assumes runtime PM to be disabled. */
WARN_ON(pm_runtime_enabled(>dev));
@@ -448,7 +452,13 @@ static int dw_i2c_plat_prepare(struct de
 
 static void dw_i2c_plat_complete(struct device *dev)
 {
-   if (dev->power.direct_complete)
+   /*
+* The device can only be in runtime suspend at this point if it has not
+* been resumed throughout the ending system suspend/resume cycle, so if
+* the platform firmware might mess up with it, request the runtime PM
+* framework to resume it.
+*/
+   if (pm_runtime_suspended(dev) && pm_resume_via_firmware())
pm_request_resume(dev);
 }
 #else
@@ -461,16 +471,9 @@ static int dw_i2c_plat_suspend(struct de
 {
struct dw_i2c_dev *i_dev = dev_get_drvdata(dev);
 
-   if (i_dev->suspended) {
-   i_dev->skip_resume = true;
-   return 0;
-   }
-
i_dev->disable(i_dev);
i2c_dw_plat_prepare_clk(i_dev, false);
 
-   i_dev->suspended = true;
-
return 0;
 }
 
@@ -478,19 +481,9 @@ static int dw_i2c_plat_resume(struct dev
 {
struct dw_i2c_dev *i_dev = dev_get_drvdata(dev);
 
-   if (!i_dev->suspended)
-   return 0;
-
-   if (i_dev->skip_resume) {
-   i_dev->skip_resume = false;
-   return 0;
-   }
-

[PATCH 0/7] PM / core: Direct handling of DPM_FLAG_SMART_SUSPEND and DPM_FLAG_LEAVE_SUSPENDED

[Rafael J. Wysocki]

On Sunday, December 10, 2017 12:55:23 AM CET Rafael J. Wysocki wrote:
> Hi All,
> 
> This series is a follow-up for
> 
> https://marc.info/?l=linux-doc=151101644105835=2
> 
> Patches[1-3/6] from the above have been reviewed and agreed on, so
> they are in linux-next now and here's a next version of the rest.
> 
> Patches [1-2/4] are preparatory.  The first one is just really small
> code duplication avoidance on top of this recent fix:
> 
> https://patchwork.kernel.org/patch/10097563/
> 
> and the second one simply moves some code to separate functions.
> 
> Patch [3/4] causes the PM core to carry out some optimizations for
> drivers of devices with DPM_FLAG_SMART_SUSPEND set whose "late"
> and "noirq" suspend (or equivalent) driver callbacks are invoked
> directly by the core.
> 
> The underlying observation is that if the device is suspended (via
> runtime PM) during the "late suspend" phase of a system transition,
> invoking the "late" and "noirq" callbacks from the driver for it is not
> going to make it more suspended, so to speak, so it doesn't make sense to
> invoke them at all.
> 
> [That optimization is only done for devices with DPM_FLAG_SMART_SUSPEND
> set, because drivers setting that flag are expected to be prepared for
> skipping their "late" and "noirq" callbacks if the device is already
> suspended.]
> 
> Patch [4/4] makes the core do an analogous thing for devices with
> DPM_FLAG_LEAVE_SUSPENDED set whose "noirq" and "early" resume (or
> equivalent) driver callbacks are directly invoked by the core.
> 
> In that case the observation is that if such devices can be left in
> suspend after the system transition to the working state, running
> resume callbacks from their drivers is simply not necessary.
> 
> Pathes [3-4/4] have been reoredered and reworked a bit since the last
> iteration, so they are regarded as new.
> 
> The series is on top of the linux-next branch of the linux-pm.git tree
> that should be merged into linux-next on Monday.
> 
> [I have developed debug bus type and driver modules to test that code,
> but they are not ready to be made available at this point.]

Resending the original series (except for the first patch that has been
applied already) along with some driver code changes based on them as
requested by Ulf.

The driver patches are an intel-lpss change (already reviewed), two
modifications of i2c-designware-platdrv (posted previously but slightly
changed since then) and a PCIe port driver change.

At this point patches [1-3/7] are pretty much on the way in and the driver
material depends on review comments (it is pointless to apply [4/7] without
[5-6/7], so it depends on them in my view).

I'm sending this from a system running with all of the series applied, although
admittedly not using i2c-designware-platdrv.  However, one of my test machines
has this one and I haven't seen any adverse effects of these changes on it so
far.

Thanks,
Rafael

Re: cgroups(7): documenting cgroup.stat

[Michael Kerrisk (man-pages)]

Hello Roman,

On 01/02/2018 10:57 PM, Roman Gushchin wrote:
> Hello, Michael!
> 
> Thank you for working on this!

You're welcome. Thanks for reviewing the text!

> Please, find my comments below.
> 
> On Tue, Jan 02, 2018 at 07:22:33PM +0100, Michael Kerrisk (man-pages) wrote:
>> Hello Roman,
>>
>> I wish to add documentation to cgroups(7) for the cgroup.stat file
>> that you added in Linux 4.14. I wrote some text based on your text
>> added to the cgroup-v2.txt file, but added some pieces, and also have
>> a question (see below). The plain-text version for (easy review)
>> is shown below. Could you please review this text? (Please note 
>> the FIXME!)
>>
>> The branch containing the pending cgroups(7) changes can be found at :
>> https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/log/?h=draft_cgroup_updates
>>
>> [[
>>Cgroups v2 cgroup.stat file
>>Each   cgroup   in   the  v2  hierarchy  contains  a  read-only
>>cgroup.stat file (first introduced in Linux 4.14) that consists
>>of  lines  containing key-value pairs.  The following keys cur‐
>>rently appear in this file:
>>
>>nr_descendants
>>   This is the  total  number  of  visible  (i.e.,  living)
>>   descendant cgroups underneath this cgroup.
>>
>>   ┌─┐
>>   │FIXME│
>>   ├─┤
>>   │For  the  following text on nr_dying_descendants, it │
>>   │would I think be  helpful  to  describe  a  condrete │
>>   │example of when one might see nr_dying_descendants a │
>>   │nonzero value for this  key.  Ideally,  the  example │
>>   │would be one that the reader could easily reproduce. │
>>   │Is there such an example?│
>>   └─┘
> 
> Hm, basically any cgroup which had some pagecache, associated during the
> lifetime, will spend some time in the dying state. This means that for
> most cgroups this number will be non-zero for some amount of time,
> which depends on global memory pressure.
> It's also very implementation-defined, and will be likely changed
> in the following kernel versions.
> 
> So, I'm not sure, that such an example will be useful for a user.
> Until this number is huge and constantly growing, it shouldn't be
> interesting for an user at all.

Fair enough. I added some vague text about resources needing to be freed
before the cgroup is destroyed. See below.


>>nr_dying_descendants
>>   This is the total number  of  dying  descendant  cgroups
>>   underneath this cgroup.  A cgroup enters the dying state
>>   after being deleted.  It remains in that  state  for  an
>>   undefined  period  (which  will  depend  on system load)
>>   before being destroyed.
>>
>>   A process can't be made a member of a dying cgroup,  and
>>   a dying cgroup can't be brought back to life.
> 
> So, maybe it worth it to add a statement, that some amount of dying cgroups
> is normal and it's not a signal of any problem?

Okay, I added some text along those lines. The first paragraph now reads:

   nr_dying_descendants
  This is the total number  of  dying  descendant  cgroups
  underneath this cgroup.  A cgroup enters the dying state
  after being deleted.  It remains in that  state  for  an
  undefined  period  (which  will  depend  on system load)
  while  resources  are  freed  before   the   cgroup   is
  destroyed.   Note  that  the presence of some cgroups in
  the dying state is normal, and is not indicative of  any
  problem.

Thanks,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: cgroups(7): documenting cgroup.stat

[Michael Kerrisk (man-pages)]

Hello Roman,

On 01/02/2018 10:57 PM, Roman Gushchin wrote:
> Hello, Michael!
> 
> Thank you for working on this!

You're welcome. Thanks for reviewing the text!

> Please, find my comments below.
> 
> On Tue, Jan 02, 2018 at 07:22:33PM +0100, Michael Kerrisk (man-pages) wrote:
>> Hello Roman,
>>
>> I wish to add documentation to cgroups(7) for the cgroup.stat file
>> that you added in Linux 4.14. I wrote some text based on your text
>> added to the cgroup-v2.txt file, but added some pieces, and also have
>> a question (see below). The plain-text version for (easy review)
>> is shown below. Could you please review this text? (Please note 
>> the FIXME!)
>>
>> The branch containing the pending cgroups(7) changes can be found at :
>> https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/log/?h=draft_cgroup_updates
>>
>> [[
>>Cgroups v2 cgroup.stat file
>>Each   cgroup   in   the  v2  hierarchy  contains  a  read-only
>>cgroup.stat file (first introduced in Linux 4.14) that consists
>>of  lines  containing key-value pairs.  The following keys cur‐
>>rently appear in this file:
>>
>>nr_descendants
>>   This is the  total  number  of  visible  (i.e.,  living)
>>   descendant cgroups underneath this cgroup.
>>
>>   ┌─┐
>>   │FIXME│
>>   ├─┤
>>   │For  the  following text on nr_dying_descendants, it │
>>   │would I think be  helpful  to  describe  a  condrete │
>>   │example of when one might see nr_dying_descendants a │
>>   │nonzero value for this  key.  Ideally,  the  example │
>>   │would be one that the reader could easily reproduce. │
>>   │Is there such an example?│
>>   └─┘
> 
> Hm, basically any cgroup which had some pagecache, associated during the
> lifetime, will spend some time in the dying state. This means that for
> most cgroups this number will be non-zero for some amount of time,
> which depends on global memory pressure.
> It's also very implementation-defined, and will be likely changed
> in the following kernel versions.
> 
> So, I'm not sure, that such an example will be useful for a user.
> Until this number is huge and constantly growing, it shouldn't be
> interesting for an user at all.

Fair enough. I added some vague text about resources needing to be freed
before the cgroup is destroyed. See below.


>>nr_dying_descendants
>>   This is the total number  of  dying  descendant  cgroups
>>   underneath this cgroup.  A cgroup enters the dying state
>>   after being deleted.  It remains in that  state  for  an
>>   undefined  period  (which  will  depend  on system load)
>>   before being destroyed.
>>
>>   A process can't be made a member of a dying cgroup,  and
>>   a dying cgroup can't be brought back to life.
> 
> So, maybe it worth it to add a statement, that some amount of dying cgroups
> is normal and it's not a signal of any problem?

Okay, I added some text along those lines. The first paragraph now reads:

   nr_dying_descendants
  This is the total number  of  dying  descendant  cgroups
  underneath this cgroup.  A cgroup enters the dying state
  after being deleted.  It remains in that  state  for  an
  undefined  period  (which  will  depend  on system load)
  while  resources  are  freed  before   the   cgroup   is
  destroyed.   Note  that  the presence of some cgroups in
  the dying state is normal, and is not indicative of  any
  problem.

Thanks,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: general protection fault in __netlink_ns_capable

[Andrei Vagin]

On Tue, Jan 02, 2018 at 10:58:01AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 75aa5540627fdb3d8f86229776ea87f995275351
> git://git.cmpxchg.org/linux-mmots.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+e432865c29eb4c48c...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> netlink: 3 bytes leftover after parsing attributes in process
> `syzkaller140561'.
> netlink: 3 bytes leftover after parsing attributes in process
> `syzkaller140561'.
> netlink: 3 bytes leftover after parsing attributes in process
> `syzkaller140561'.
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault:  [#1] SMP KASAN
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 3149 Comm: syzkaller140561 Not tainted 4.15.0-rc4-mm1+ #47
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:__netlink_ns_capable+0x8b/0x120 net/netlink/af_netlink.c:868

NETLINK_CB(skb).sk is NULL here. It looks like we have to use
sk_ns_capable instead of netlink_ns_capable:

diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index c688dc564b11..408c75de52ea 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1762,7 +1762,7 @@ static struct net *get_target_net(struct sk_buff
*skb, int netnsid)
/* For now, the caller is required to have CAP_NET_ADMIN in
 * the user namespace owning the target net ns.
 */
-   if (!netlink_ns_capable(skb, net->user_ns, CAP_NET_ADMIN)) {
+   if (!sk_ns_capable(skb->sk, net->user_ns, CAP_NET_ADMIN)) {
put_net(net);
return ERR_PTR(-EACCES);
}

> RSP: 0018:8801c880f348 EFLAGS: 00010206
> RAX: dc00 RBX:  RCX: 8443f900
> RDX: 007b RSI: 86510f40 RDI: 03d8
> RBP: 8801c880f360 R08:  R09: 110039101e4f
> R10:  R11: 0001 R12: 86510f40
> R13: 000c R14: 0004 R15: 0011
> FS:  01a1a880() GS:8801db30() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 20151000 CR3: 0001c9511005 CR4: 001606e0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>  netlink_ns_capable+0x26/0x30 net/netlink/af_netlink.c:886
>  get_target_net+0x9d/0x120 net/core/rtnetlink.c:1765
>  rtnl_dump_ifinfo+0x2e5/0xee0 net/core/rtnetlink.c:1806
>  netlink_dump+0x48c/0xce0 net/netlink/af_netlink.c:
>  __netlink_dump_start+0x4f0/0x6d0 net/netlink/af_netlink.c:2319
>  netlink_dump_start include/linux/netlink.h:214 [inline]
>  rtnetlink_rcv_msg+0x7f0/0xb10 net/core/rtnetlink.c:4485
>  netlink_rcv_skb+0x21e/0x460 net/netlink/af_netlink.c:2441
>  rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4540
>  netlink_unicast_kernel net/netlink/af_netlink.c:1308 [inline]
>  netlink_unicast+0x4be/0x6a0 net/netlink/af_netlink.c:1334
>  netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1897
>  sock_sendmsg_nosec net/socket.c:628 [inline]
>  sock_sendmsg+0xca/0x110 net/socket.c:638
>  sock_write_iter+0x31a/0x5d0 net/socket.c:907
>  call_write_iter include/linux/fs.h:1776 [inline]
>  new_sync_write fs/read_write.c:469 [inline]
>  __vfs_write+0x684/0x970 fs/read_write.c:482
>  vfs_write+0x189/0x510 fs/read_write.c:544
>  SYSC_write fs/read_write.c:589 [inline]
>  SyS_write+0xef/0x220 fs/read_write.c:581
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x43fd49
> RSP: 002b:7ffc7fb92238 EFLAGS: 0203 ORIG_RAX: 0001
> RAX: ffda RBX:  RCX: 0043fd49
> RDX: 001f RSI: 20151000 RDI: 0005
> RBP: 006ca018 R08:  R09: 
> R10:  R11: 0203 R12: 004016b0
> R13: 00401740 R14:  R15: 
> Code: fa 48 c1 ea 03 80 3c 02 00 0f 85 95 00 00 00 48 8b 5b 18 48 b8 00 00
> 00 00 00 fc ff df 48 8d bb d8 03 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f
> 85 80 00 00 00 48 8b 9b d8 03 00 00 48 b8 00 00
> RIP: __netlink_ns_capable+0x8b/0x120 net/netlink/af_netlink.c:868 RSP:
> 8801c880f348
> ---[ end trace d7574f6bd3eea534 ]---
> 
> 
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to 

Re: general protection fault in __netlink_ns_capable

[Andrei Vagin]

On Tue, Jan 02, 2018 at 10:58:01AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 75aa5540627fdb3d8f86229776ea87f995275351
> git://git.cmpxchg.org/linux-mmots.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+e432865c29eb4c48c...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> netlink: 3 bytes leftover after parsing attributes in process
> `syzkaller140561'.
> netlink: 3 bytes leftover after parsing attributes in process
> `syzkaller140561'.
> netlink: 3 bytes leftover after parsing attributes in process
> `syzkaller140561'.
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault:  [#1] SMP KASAN
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 3149 Comm: syzkaller140561 Not tainted 4.15.0-rc4-mm1+ #47
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:__netlink_ns_capable+0x8b/0x120 net/netlink/af_netlink.c:868

NETLINK_CB(skb).sk is NULL here. It looks like we have to use
sk_ns_capable instead of netlink_ns_capable:

diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index c688dc564b11..408c75de52ea 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1762,7 +1762,7 @@ static struct net *get_target_net(struct sk_buff
*skb, int netnsid)
/* For now, the caller is required to have CAP_NET_ADMIN in
 * the user namespace owning the target net ns.
 */
-   if (!netlink_ns_capable(skb, net->user_ns, CAP_NET_ADMIN)) {
+   if (!sk_ns_capable(skb->sk, net->user_ns, CAP_NET_ADMIN)) {
put_net(net);
return ERR_PTR(-EACCES);
}

> RSP: 0018:8801c880f348 EFLAGS: 00010206
> RAX: dc00 RBX:  RCX: 8443f900
> RDX: 007b RSI: 86510f40 RDI: 03d8
> RBP: 8801c880f360 R08:  R09: 110039101e4f
> R10:  R11: 0001 R12: 86510f40
> R13: 000c R14: 0004 R15: 0011
> FS:  01a1a880() GS:8801db30() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 20151000 CR3: 0001c9511005 CR4: 001606e0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>  netlink_ns_capable+0x26/0x30 net/netlink/af_netlink.c:886
>  get_target_net+0x9d/0x120 net/core/rtnetlink.c:1765
>  rtnl_dump_ifinfo+0x2e5/0xee0 net/core/rtnetlink.c:1806
>  netlink_dump+0x48c/0xce0 net/netlink/af_netlink.c:
>  __netlink_dump_start+0x4f0/0x6d0 net/netlink/af_netlink.c:2319
>  netlink_dump_start include/linux/netlink.h:214 [inline]
>  rtnetlink_rcv_msg+0x7f0/0xb10 net/core/rtnetlink.c:4485
>  netlink_rcv_skb+0x21e/0x460 net/netlink/af_netlink.c:2441
>  rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4540
>  netlink_unicast_kernel net/netlink/af_netlink.c:1308 [inline]
>  netlink_unicast+0x4be/0x6a0 net/netlink/af_netlink.c:1334
>  netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1897
>  sock_sendmsg_nosec net/socket.c:628 [inline]
>  sock_sendmsg+0xca/0x110 net/socket.c:638
>  sock_write_iter+0x31a/0x5d0 net/socket.c:907
>  call_write_iter include/linux/fs.h:1776 [inline]
>  new_sync_write fs/read_write.c:469 [inline]
>  __vfs_write+0x684/0x970 fs/read_write.c:482
>  vfs_write+0x189/0x510 fs/read_write.c:544
>  SYSC_write fs/read_write.c:589 [inline]
>  SyS_write+0xef/0x220 fs/read_write.c:581
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x43fd49
> RSP: 002b:7ffc7fb92238 EFLAGS: 0203 ORIG_RAX: 0001
> RAX: ffda RBX:  RCX: 0043fd49
> RDX: 001f RSI: 20151000 RDI: 0005
> RBP: 006ca018 R08:  R09: 
> R10:  R11: 0203 R12: 004016b0
> R13: 00401740 R14:  R15: 
> Code: fa 48 c1 ea 03 80 3c 02 00 0f 85 95 00 00 00 48 8b 5b 18 48 b8 00 00
> 00 00 00 fc ff df 48 8d bb d8 03 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f
> 85 80 00 00 00 48 8b 9b d8 03 00 00 48 b8 00 00
> RIP: __netlink_ns_capable+0x8b/0x120 net/netlink/af_netlink.c:868 RSP:
> 8801c880f348
> ---[ end trace d7574f6bd3eea534 ]---
> 
> 
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to 

Re: [RESEND PATCH v2 01/15] dt-bindings: soc: qcom: Add bindings for APR bus

[Bjorn Andersson]

On Thu 14 Dec 09:33 PST 2017, srinivas.kandaga...@linaro.org wrote:

> From: Srinivas Kandagatla 
> 
> This patch add dt bindings for Qualcomm APR bus driver
> 
> Signed-off-by: Srinivas Kandagatla 
> ---
>  .../devicetree/bindings/soc/qcom/qcom,apr.txt  | 28 
> ++
>  1 file changed, 28 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
> 
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt 
> b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
> new file mode 100644
> index ..4e93213ae98d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
> @@ -0,0 +1,28 @@
> +Qualcomm APR (Asynchronous Packet Router) binding
> +
> +This binding describes the Qualcomm APR. APR is a IPC protocol for
> +communication between Application processor and QDSP. APR is mainly
> +used for audio/voice services on the QDSP.
> +
> +- compatible:
> + Usage: required
> + Value type: 
> + Definition: must be "qcom,apr-" example: "qcom,apr-msm8996"

This is not the only apr on msm8996 and some platform seems to have 3-4
aprs. I'm therefor hesitant to use the compatible to pick the static
list of services available on the particular firmware.

If this scheme is followed we at least would need to rename this
qcom,msm8996-apr-audio-svc

But I think it would be preferable to go with qcom,apr-v2 and then list
the static services as child nodes.

> +
> +
> +- qcom,smd-channel:
> + Usage: required
> + Value type: 
> + Definition: standard SMD property specifying the SMD channel used for
> + communication with the APR on QDSP.
> + Should be "apr_audio_svc".

This is not the only APR channel, but for apr itself this doesn't matter
and might as well be qcom,glink-channels; so perhaps we can omit this
from this document?

> + Described in soc/qcom/qcom,smd.txt
> +
> += EXAMPLE
> +The following example represents a QDSP based sound card on a MSM8996 device
> +which uses apr as communication between Apps and QDSP.
> +
> + apr {
> + compatible = "qcom,apr-msm8996";
> + qcom,smd-channels = "apr_audio_svc";
> + };

Regards,
Bjorn

Re: [RESEND PATCH v2 01/15] dt-bindings: soc: qcom: Add bindings for APR bus

[Bjorn Andersson]

On Thu 14 Dec 09:33 PST 2017, srinivas.kandaga...@linaro.org wrote:

> From: Srinivas Kandagatla 
> 
> This patch add dt bindings for Qualcomm APR bus driver
> 
> Signed-off-by: Srinivas Kandagatla 
> ---
>  .../devicetree/bindings/soc/qcom/qcom,apr.txt  | 28 
> ++
>  1 file changed, 28 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
> 
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt 
> b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
> new file mode 100644
> index ..4e93213ae98d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
> @@ -0,0 +1,28 @@
> +Qualcomm APR (Asynchronous Packet Router) binding
> +
> +This binding describes the Qualcomm APR. APR is a IPC protocol for
> +communication between Application processor and QDSP. APR is mainly
> +used for audio/voice services on the QDSP.
> +
> +- compatible:
> + Usage: required
> + Value type: 
> + Definition: must be "qcom,apr-" example: "qcom,apr-msm8996"

This is not the only apr on msm8996 and some platform seems to have 3-4
aprs. I'm therefor hesitant to use the compatible to pick the static
list of services available on the particular firmware.

If this scheme is followed we at least would need to rename this
qcom,msm8996-apr-audio-svc

But I think it would be preferable to go with qcom,apr-v2 and then list
the static services as child nodes.

> +
> +
> +- qcom,smd-channel:
> + Usage: required
> + Value type: 
> + Definition: standard SMD property specifying the SMD channel used for
> + communication with the APR on QDSP.
> + Should be "apr_audio_svc".

This is not the only APR channel, but for apr itself this doesn't matter
and might as well be qcom,glink-channels; so perhaps we can omit this
from this document?

> + Described in soc/qcom/qcom,smd.txt
> +
> += EXAMPLE
> +The following example represents a QDSP based sound card on a MSM8996 device
> +which uses apr as communication between Apps and QDSP.
> +
> + apr {
> + compatible = "qcom,apr-msm8996";
> + qcom,smd-channels = "apr_audio_svc";
> + };

Regards,
Bjorn

Re: [wrecked] mm-swap-unify-cluster-based-and-vma-based-swap-readahead.patch removed from -mm tree

[Minchan Kim]

Hi Andrew,

I want to keep this patchset rather than wrecking.
It is needed to code more neat to fix a bug James reported.

https://marc.info/?l=linux-mm=151493906616938

On Tue, Jan 02, 2018 at 04:23:34PM -0800, a...@linux-foundation.org wrote:
> 
> The patch titled
>  Subject: mm: swap: unify cluster-based and vma-based swap readahead
> has been removed from the -mm tree.  Its filename was
>  mm-swap-unify-cluster-based-and-vma-based-swap-readahead.patch
> 
> This patch was dropped because other changes were merged, which wrecked this 
> patch
> 
> --
> From: Minchan Kim 
> Subject: mm: swap: unify cluster-based and vma-based swap readahead
> 
> This patch makes do_swap_page() not need to be aware of two different swap
> readahead algorithms.  Just unify cluster-based and vma-based readahead
> function call.
> 
> Link: 
> http://lkml.kernel.org/r/1509520520-32367-3-git-send-email-minc...@kernel.org
> Signed-off-by: Minchan Kim 
> Cc: Hugh Dickins 
> Cc: Huang Ying 
> Signed-off-by: Andrew Morton 
> ---
> 
>  include/linux/swap.h |   27 ++-
>  mm/memory.c  |   11 +++--
>  mm/shmem.c   |5 +++-
>  mm/swap_state.c  |   48 +++--
>  4 files changed, 53 insertions(+), 38 deletions(-)
> 
> diff -puN 
> include/linux/swap.h~mm-swap-unify-cluster-based-and-vma-based-swap-readahead 
> include/linux/swap.h
> --- 
> a/include/linux/swap.h~mm-swap-unify-cluster-based-and-vma-based-swap-readahead
> +++ a/include/linux/swap.h
> @@ -401,7 +401,6 @@ int generic_swapfile_activate(struct swa
>  #define SWAP_ADDRESS_SPACE_SHIFT 14
>  #define SWAP_ADDRESS_SPACE_PAGES (1 << SWAP_ADDRESS_SPACE_SHIFT)
>  extern struct address_space *swapper_spaces[];
> -extern bool swap_vma_readahead;
>  #define swap_address_space(entry)\
>   (_spaces[swp_type(entry)][swp_offset(entry) \
>   >> SWAP_ADDRESS_SPACE_SHIFT])
> @@ -423,10 +422,10 @@ extern struct page *read_swap_cache_asyn
>  extern struct page *__read_swap_cache_async(swp_entry_t, gfp_t,
>   struct vm_area_struct *vma, unsigned long addr,
>   bool *new_page_allocated);
> -extern struct page *swapin_readahead(swp_entry_t, gfp_t,
> - struct vm_area_struct *vma, unsigned long addr);
> -extern struct page *do_swap_page_readahead(swp_entry_t fentry, gfp_t 
> gfp_mask,
> -struct vm_fault *vmf);
> +extern struct page *swap_cluster_readahead(swp_entry_t entry, gfp_t flag,
> + struct vm_fault *vmf);
> +extern struct page *swapin_readahead(swp_entry_t entry, gfp_t flag,
> + struct vm_fault *vmf);
>  
>  /* linux/mm/swapfile.c */
>  extern atomic_long_t nr_swap_pages;
> @@ -434,11 +433,6 @@ extern long total_swap_pages;
>  extern atomic_t nr_rotate_swap;
>  extern bool has_usable_swap(void);
>  
> -static inline bool swap_use_vma_readahead(void)
> -{
> - return READ_ONCE(swap_vma_readahead) && !atomic_read(_rotate_swap);
> -}
> -
>  /* Swap 50% full? Release swapcache more aggressively.. */
>  static inline bool vm_swap_full(void)
>  {
> @@ -534,19 +528,14 @@ static inline void put_swap_page(struct
>  {
>  }
>  
> -static inline struct page *swapin_readahead(swp_entry_t swp, gfp_t gfp_mask,
> - struct vm_area_struct *vma, unsigned long addr)
> +static inline struct page *swap_cluster_readahead(swp_entry_t entry,
> + gfp_t gfp_mask, struct vm_fault *vmf)
>  {
>   return NULL;
>  }
>  
> -static inline bool swap_use_vma_readahead(void)
> -{
> - return false;
> -}
> -
> -static inline struct page *do_swap_page_readahead(swp_entry_t fentry,
> - gfp_t gfp_mask, struct vm_fault *vmf)
> +static inline struct page *swapin_readahead(swp_entry_t swp, gfp_t gfp_mask,
> + struct vm_fault *vmf)
>  {
>   return NULL;
>  }
> diff -puN 
> mm/memory.c~mm-swap-unify-cluster-based-and-vma-based-swap-readahead 
> mm/memory.c
> --- a/mm/memory.c~mm-swap-unify-cluster-based-and-vma-based-swap-readahead
> +++ a/mm/memory.c
> @@ -2889,7 +2889,8 @@ int do_swap_page(struct vm_fault *vmf)
>   if (si->flags & SWP_SYNCHRONOUS_IO &&
>   __swap_count(si, entry) == 1) {
>   /* skip swapcache */
> - page = alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma, 
> vmf->address);
> + page = alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma,
> + vmf->address);
>   if (page) {
>   __SetPageLocked(page);
>   __SetPageSwapBacked(page);
> @@ -2898,12 +2899,8 @@ int 

Re: [wrecked] mm-swap-unify-cluster-based-and-vma-based-swap-readahead.patch removed from -mm tree

[Minchan Kim]

Hi Andrew,

I want to keep this patchset rather than wrecking.
It is needed to code more neat to fix a bug James reported.

https://marc.info/?l=linux-mm=151493906616938

On Tue, Jan 02, 2018 at 04:23:34PM -0800, a...@linux-foundation.org wrote:
> 
> The patch titled
>  Subject: mm: swap: unify cluster-based and vma-based swap readahead
> has been removed from the -mm tree.  Its filename was
>  mm-swap-unify-cluster-based-and-vma-based-swap-readahead.patch
> 
> This patch was dropped because other changes were merged, which wrecked this 
> patch
> 
> --
> From: Minchan Kim 
> Subject: mm: swap: unify cluster-based and vma-based swap readahead
> 
> This patch makes do_swap_page() not need to be aware of two different swap
> readahead algorithms.  Just unify cluster-based and vma-based readahead
> function call.
> 
> Link: 
> http://lkml.kernel.org/r/1509520520-32367-3-git-send-email-minc...@kernel.org
> Signed-off-by: Minchan Kim 
> Cc: Hugh Dickins 
> Cc: Huang Ying 
> Signed-off-by: Andrew Morton 
> ---
> 
>  include/linux/swap.h |   27 ++-
>  mm/memory.c  |   11 +++--
>  mm/shmem.c   |5 +++-
>  mm/swap_state.c  |   48 +++--
>  4 files changed, 53 insertions(+), 38 deletions(-)
> 
> diff -puN 
> include/linux/swap.h~mm-swap-unify-cluster-based-and-vma-based-swap-readahead 
> include/linux/swap.h
> --- 
> a/include/linux/swap.h~mm-swap-unify-cluster-based-and-vma-based-swap-readahead
> +++ a/include/linux/swap.h
> @@ -401,7 +401,6 @@ int generic_swapfile_activate(struct swa
>  #define SWAP_ADDRESS_SPACE_SHIFT 14
>  #define SWAP_ADDRESS_SPACE_PAGES (1 << SWAP_ADDRESS_SPACE_SHIFT)
>  extern struct address_space *swapper_spaces[];
> -extern bool swap_vma_readahead;
>  #define swap_address_space(entry)\
>   (_spaces[swp_type(entry)][swp_offset(entry) \
>   >> SWAP_ADDRESS_SPACE_SHIFT])
> @@ -423,10 +422,10 @@ extern struct page *read_swap_cache_asyn
>  extern struct page *__read_swap_cache_async(swp_entry_t, gfp_t,
>   struct vm_area_struct *vma, unsigned long addr,
>   bool *new_page_allocated);
> -extern struct page *swapin_readahead(swp_entry_t, gfp_t,
> - struct vm_area_struct *vma, unsigned long addr);
> -extern struct page *do_swap_page_readahead(swp_entry_t fentry, gfp_t 
> gfp_mask,
> -struct vm_fault *vmf);
> +extern struct page *swap_cluster_readahead(swp_entry_t entry, gfp_t flag,
> + struct vm_fault *vmf);
> +extern struct page *swapin_readahead(swp_entry_t entry, gfp_t flag,
> + struct vm_fault *vmf);
>  
>  /* linux/mm/swapfile.c */
>  extern atomic_long_t nr_swap_pages;
> @@ -434,11 +433,6 @@ extern long total_swap_pages;
>  extern atomic_t nr_rotate_swap;
>  extern bool has_usable_swap(void);
>  
> -static inline bool swap_use_vma_readahead(void)
> -{
> - return READ_ONCE(swap_vma_readahead) && !atomic_read(_rotate_swap);
> -}
> -
>  /* Swap 50% full? Release swapcache more aggressively.. */
>  static inline bool vm_swap_full(void)
>  {
> @@ -534,19 +528,14 @@ static inline void put_swap_page(struct
>  {
>  }
>  
> -static inline struct page *swapin_readahead(swp_entry_t swp, gfp_t gfp_mask,
> - struct vm_area_struct *vma, unsigned long addr)
> +static inline struct page *swap_cluster_readahead(swp_entry_t entry,
> + gfp_t gfp_mask, struct vm_fault *vmf)
>  {
>   return NULL;
>  }
>  
> -static inline bool swap_use_vma_readahead(void)
> -{
> - return false;
> -}
> -
> -static inline struct page *do_swap_page_readahead(swp_entry_t fentry,
> - gfp_t gfp_mask, struct vm_fault *vmf)
> +static inline struct page *swapin_readahead(swp_entry_t swp, gfp_t gfp_mask,
> + struct vm_fault *vmf)
>  {
>   return NULL;
>  }
> diff -puN 
> mm/memory.c~mm-swap-unify-cluster-based-and-vma-based-swap-readahead 
> mm/memory.c
> --- a/mm/memory.c~mm-swap-unify-cluster-based-and-vma-based-swap-readahead
> +++ a/mm/memory.c
> @@ -2889,7 +2889,8 @@ int do_swap_page(struct vm_fault *vmf)
>   if (si->flags & SWP_SYNCHRONOUS_IO &&
>   __swap_count(si, entry) == 1) {
>   /* skip swapcache */
> - page = alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma, 
> vmf->address);
> + page = alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma,
> + vmf->address);
>   if (page) {
>   __SetPageLocked(page);
>   __SetPageSwapBacked(page);
> @@ -2898,12 +2899,8 @@ int do_swap_page(struct vm_fault *vmf)
>   swap_readpage(page, true);
> 

Re: [RESEND PATCH v2 13/15] dt-bindings: sound: qcom: Add devicetree bindings for apq8096

[Bjorn Andersson]

On Thu 14 Dec 09:34 PST 2017, srinivas.kandaga...@linaro.org wrote:

> +++ b/Documentation/devicetree/bindings/sound/qcom,apq8096.txt

Wouldn't it be possible to describe all(?) qdsp based machines in this
one document? I.e. should we name it a little bit more generic?

> @@ -0,0 +1,22 @@
> +* Qualcomm Technologies APQ8096 ASoC sound card driver
> +
> +This binding describes the APQ8096 sound card, which uses qdsp for audio.
> +
> +- compatible:
> + Usage: required
> + Value type: 
> + Definition: must be "qcom,apq8096-sndcard"
> +
> +- qcom,audio-routing:
> + Usage: Optional
> + Value type: 
> + Definition:  A list of the connections between audio components.

Double space before A

> +   Each entry is a pair of strings, the first being the
> +   connection's sink, the second being the connection's
> +   source. Valid names could be power supplies, MicBias
> +   of codec and the jacks on the board:
> +Example:
> + sound {
> + compatible  = "qcom,snd-apq8096";

Indentation

> + qcom,model = "DB820c";
> + };

Regards,
Bjorn

Re: [RESEND PATCH v2 13/15] dt-bindings: sound: qcom: Add devicetree bindings for apq8096

[Bjorn Andersson]

On Thu 14 Dec 09:34 PST 2017, srinivas.kandaga...@linaro.org wrote:

> +++ b/Documentation/devicetree/bindings/sound/qcom,apq8096.txt

Wouldn't it be possible to describe all(?) qdsp based machines in this
one document? I.e. should we name it a little bit more generic?

> @@ -0,0 +1,22 @@
> +* Qualcomm Technologies APQ8096 ASoC sound card driver
> +
> +This binding describes the APQ8096 sound card, which uses qdsp for audio.
> +
> +- compatible:
> + Usage: required
> + Value type: 
> + Definition: must be "qcom,apq8096-sndcard"
> +
> +- qcom,audio-routing:
> + Usage: Optional
> + Value type: 
> + Definition:  A list of the connections between audio components.

Double space before A

> +   Each entry is a pair of strings, the first being the
> +   connection's sink, the second being the connection's
> +   source. Valid names could be power supplies, MicBias
> +   of codec and the jacks on the board:
> +Example:
> + sound {
> + compatible  = "qcom,snd-apq8096";

Indentation

> + qcom,model = "DB820c";
> + };

Regards,
Bjorn

Re: [RESEND PATCH v2 15/15] arm64: dts: msm8996: db820c: Add sound card support

[Bjorn Andersson]

On Thu 14 Dec 09:34 PST 2017, srinivas.kandaga...@linaro.org wrote:

> From: Srinivas Kandagatla 
> 
> This patch adds hdmi sound card support to db820c via qdsp.
> 
> Signed-off-by: Srinivas Kandagatla 
> ---
>  arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi |  5 +
>  arch/arm64/boot/dts/qcom/msm8996.dtsi| 33 
> 
>  2 files changed, 38 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi 
> b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
> index 9769053957af..b955769b100d 100644
> --- a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
> +++ b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
> @@ -190,6 +190,11 @@
>   };
>   };
>  
> + snd {
> + compatible = "qcom,apq8096-sndcard";
> + qcom,model = "DB820c";
> + iommus = <_q6_smmu 1>;
> + };
>  
>   gpio_keys {
>   compatible = "gpio-keys";
> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi 
> b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> index a144cec7bb71..25c43fb8ab49 100644
> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> @@ -1262,6 +1262,7 @@
>  
>   phys = <_phy>;
>   phy-names = "hdmi_phy";
> + #sound-dai-cells = <0>;
>  
>   ports {
>   #address-cells = <1>;
> @@ -1297,6 +1298,33 @@
> "ref_clk";
>   };
>   };
> +
> + lpass_q6_smmu: arm,smmu-lpass_q6@160 {

name this node "iommu"

> + compatible = "qcom,msm8996-smmu-v2";
> + reg = <0x160 0x2>;
> + #iommu-cells = <1>;
> +power-domains = < HLOS1_VOTE_LPASS_CORE_GDSC>;

Indentation

> +
> + #global-interrupts = <1>;
> + interrupts = ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ;
> +
> + clocks = < GCC_HLOS1_VOTE_LPASS_CORE_SMMU_CLK>,
> +  < GCC_HLOS1_VOTE_LPASS_ADSP_SMMU_CLK>;
> + clock-names = "iface", "bus";
> +status = "okay";
> + };
>   };
>  
>   adsp-pil {
> @@ -1325,6 +1353,11 @@
>   qcom,ipc = < 16 8>;
>   qcom,smd-edge = <1>;
>   qcom,remote-pid = <2>;
> +
> + apr {

"apr-audio-svc", as this is not the only apr channel on this edge.

> + compatible = "qcom,apr-msm8996";
> + qcom,smd-channels = "apr_audio_svc";
> + };
>   };

Regards,
Bjorn

Re: [RESEND PATCH v2 15/15] arm64: dts: msm8996: db820c: Add sound card support

[Bjorn Andersson]

On Thu 14 Dec 09:34 PST 2017, srinivas.kandaga...@linaro.org wrote:

> From: Srinivas Kandagatla 
> 
> This patch adds hdmi sound card support to db820c via qdsp.
> 
> Signed-off-by: Srinivas Kandagatla 
> ---
>  arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi |  5 +
>  arch/arm64/boot/dts/qcom/msm8996.dtsi| 33 
> 
>  2 files changed, 38 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi 
> b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
> index 9769053957af..b955769b100d 100644
> --- a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
> +++ b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
> @@ -190,6 +190,11 @@
>   };
>   };
>  
> + snd {
> + compatible = "qcom,apq8096-sndcard";
> + qcom,model = "DB820c";
> + iommus = <_q6_smmu 1>;
> + };
>  
>   gpio_keys {
>   compatible = "gpio-keys";
> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi 
> b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> index a144cec7bb71..25c43fb8ab49 100644
> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> @@ -1262,6 +1262,7 @@
>  
>   phys = <_phy>;
>   phy-names = "hdmi_phy";
> + #sound-dai-cells = <0>;
>  
>   ports {
>   #address-cells = <1>;
> @@ -1297,6 +1298,33 @@
> "ref_clk";
>   };
>   };
> +
> + lpass_q6_smmu: arm,smmu-lpass_q6@160 {

name this node "iommu"

> + compatible = "qcom,msm8996-smmu-v2";
> + reg = <0x160 0x2>;
> + #iommu-cells = <1>;
> +power-domains = < HLOS1_VOTE_LPASS_CORE_GDSC>;

Indentation

> +
> + #global-interrupts = <1>;
> + interrupts = ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ;
> +
> + clocks = < GCC_HLOS1_VOTE_LPASS_CORE_SMMU_CLK>,
> +  < GCC_HLOS1_VOTE_LPASS_ADSP_SMMU_CLK>;
> + clock-names = "iface", "bus";
> +status = "okay";
> + };
>   };
>  
>   adsp-pil {
> @@ -1325,6 +1353,11 @@
>   qcom,ipc = < 16 8>;
>   qcom,smd-edge = <1>;
>   qcom,remote-pid = <2>;
> +
> + apr {

"apr-audio-svc", as this is not the only apr channel on this edge.

> + compatible = "qcom,apr-msm8996";
> + qcom,smd-channels = "apr_audio_svc";
> + };
>   };

Regards,
Bjorn

Re: stable/linux-4.1.y build: 169 builds: 2 failed, 167 passed, 13 errors, 253 warnings (v4.1.48)

[Arnd Bergmann]

On Wed, Dec 20, 2017 at 11:49 PM, kernelci.org bot  wrote:

> Errors summary:
> 1 arch/mips/sgi-ip22/Platform:29: *** gcc doesn't support needed option 
> -mr10k-cache-barrier=store. Stop.

This needs a backport of

c018595d83a3 ("MIPS: ip22: Fix ip28 build for modern gcc")

> 6 include/linux/irqdesc.h:94:33: error: 'NR_IRQS' undeclared here (not in a 
> function)
> 1 arch/mips/jz4740/gpio.c:46:32: error: initializer element is not constant
> 1 arch/mips/jz4740/gpio.c:45:32: error: initializer element is not constant
> 1 arch/mips/jz4740/gpio.c:44:32: error: initializer element is not constant
> 1 arch/mips/jz4740/gpio.c:43:32: error: initializer element is not constant
> 1 arch/mips/jz4740/gpio.c:426:14: error: implicit declaration of function 
> 'JZ4740_IRQ_INTC_GPIO' [-Werror=implicit-function-declaration]
> 1 arch/mips/jz4740/gpio.c:268:9: error: implicit declaration of function 
> 'JZ4740_IRQ_GPIO' [-Werror=implicit-function-declaration]

Not sure, may have been fixed by

832f5dacfa0b ("MIPS: Remove all the uses of custom gpio.h")

which doesn't look appropriate for stable backports

> Warnings summary:
> 81 include/linux/blkdev.h:624:26: warning: switch condition has boolean value 
> [-Wswitch-bool]
> 23 drivers/mtd/mtd_blkdevs.c:100:2: warning: switch condition has boolean 
> value [-Wswitch-bool]

10fbd36e362a ("blk: rq_data_dir() should not return a boolean")

> 35 mm/page_alloc.c:5435:34: warning: array subscript is below array bounds 
> [-Warray-bounds]

I think this was fixed by

90cae1fe1c35 ("mm/init: fix zone boundary creation")
which was intended to address another problem but got backported to 4.4

> 20 arch/arm/include/asm/cmpxchg.h:122:3: warning: value computed is not used 
> [-Wunused-value]
> 5 arch/arm/include/asm/cmpxchg.h:205:3: warning: value computed is not used 
> [-Wunused-value]

d975440bf80c ("asm-generic: cmpxchg: avoid warnings from macro-ized
cmpxchg() implementations")

> 10 drivers/rtc/rtc-pcf8563.c:444:5: warning: 'alm_pending' may be used 
> uninitialized in this function [-Wmaybe-uninitialized]

cd1420d3a909 ("rtc: pfc8563: fix uninitialized variable warning")

> 6 crypto/wp512.c:987:1: warning: the frame size of 1112 bytes is larger than 
> 1024 bytes [-Wframe-larger-than=]
> 1 crypto/wp512.c:987:1: warning: the frame size of 1344 bytes is larger than 
> 1024 bytes [-Wframe-larger-than=]
> 1 crypto/wp512.c:987:1: warning: the frame size of 1280 bytes is larger than 
> 1024 bytes [-Wframe-larger-than=]
> 1 crypto/wp512.c:987:1: warning: the frame size of 1152 bytes is larger than 
> 1024 bytes [-Wframe-larger-than=]
> 1 crypto/wp512.c:987:1: warning: the frame size of 1144 bytes is larger than 
> 1024 bytes [-Wframe-larger-than=]
> 1 crypto/wp512.c:987:1: warning: the frame size of 1120 bytes is larger than 
> 1024 bytes [-Wframe-larger-than=]
> 1 crypto/serpent_generic.c:436:1: warning: the frame size of 1472 bytes is 
> larger than 1024 bytes [-Wframe-larger-than=]
> 1 crypto/serpent_generic.c:436:1: warning: the frame size of 1456 bytes is 
> larger than 1024 bytes [-Wframe-larger-than=]
7d6e9105026 ("crypto: improve gcc optimization flags for serpent and wp512")

> 4 fs/nfsd/nfs4state.c:3962:3: warning: 'old_deny_bmap' may be used 
> uninitialized in this function [-Wmaybe-uninitialized]

6ac75368e1a6 ("nfsd: work around a gcc-5.1 warning")

> 3 drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c:1478:8: warning: 'skb' 
> may be used uninitialized in this function [-Wmaybe-uninitialized]

22f44150aad7 ("brcmfmac: avoid gcc-5.1 warning")

> 2 lib/iommu-common.c:15:24: warning: large integer implicitly truncated to 
> unsigned type [-Woverflow]

447f6a95a9c8 ("lib/iommu-common.c: do not use 0xl for
computing align_mask")

> 2 drivers/hid/hid-input.c:1163:67: warning: logical not is only applied to 
> the left hand side of comparison [-Wlogical-not-parentheses]

09a5c34e8d6b ("HID: hid-input: Add parentheses to quell gcc warning")

> 2 drivers/atm/iphase.c:1176:12: warning: this 'if' clause does not guard... 
> [-Wmisleading-indentation]

cbb41b91e68a ("atm: iphase: fix misleading indention")

> 2 arch/x86/include/asm/msr.h:209:23: warning: right shift count >= width of 
> type [-Wshift-count-overflow]

cf991de2f614 ("x86/asm/msr: Make wrmsrl_safe() a function")
47edb65178cb ("x86/asm/msr: Make wrmsrl() a function")

> 1 fs/gfs2/dir.c:978:8: warning: 'leaf_no' may be used uninitialized in this 
> function [-Wmaybe-uninitialized]
> 1 fs/gfs2/dir.c:759:9: warning: 'leaf_no' may be used uninitialized in this 
> function [-Wmaybe-uninitialized]

d39cb4a59729 ("gfs2: avoid uninitialized variable warning")

> 1 drivers/net/ethernet/ti/cpmac.c:1238:2: warning: #warning FIXME: unhardcode 
> gpio bits [-Wcpp]

d43e6fb4ac4a ("cpmac: remove hopeless #warning")


> 1 drivers/scsi/mvsas/mv_sas.c:736:3: warning: this 'else' clause does not 
> guard... [-Wmisleading-indentation]

7789cd39274c ("mvsas: fix misleading indentation")

> 1 

Re: stable/linux-4.1.y build: 169 builds: 2 failed, 167 passed, 13 errors, 253 warnings (v4.1.48)

[Arnd Bergmann]

On Wed, Dec 20, 2017 at 11:49 PM, kernelci.org bot  wrote:

> Errors summary:
> 1 arch/mips/sgi-ip22/Platform:29: *** gcc doesn't support needed option 
> -mr10k-cache-barrier=store. Stop.

This needs a backport of

c018595d83a3 ("MIPS: ip22: Fix ip28 build for modern gcc")

> 6 include/linux/irqdesc.h:94:33: error: 'NR_IRQS' undeclared here (not in a 
> function)
> 1 arch/mips/jz4740/gpio.c:46:32: error: initializer element is not constant
> 1 arch/mips/jz4740/gpio.c:45:32: error: initializer element is not constant
> 1 arch/mips/jz4740/gpio.c:44:32: error: initializer element is not constant
> 1 arch/mips/jz4740/gpio.c:43:32: error: initializer element is not constant
> 1 arch/mips/jz4740/gpio.c:426:14: error: implicit declaration of function 
> 'JZ4740_IRQ_INTC_GPIO' [-Werror=implicit-function-declaration]
> 1 arch/mips/jz4740/gpio.c:268:9: error: implicit declaration of function 
> 'JZ4740_IRQ_GPIO' [-Werror=implicit-function-declaration]

Not sure, may have been fixed by

832f5dacfa0b ("MIPS: Remove all the uses of custom gpio.h")

which doesn't look appropriate for stable backports

> Warnings summary:
> 81 include/linux/blkdev.h:624:26: warning: switch condition has boolean value 
> [-Wswitch-bool]
> 23 drivers/mtd/mtd_blkdevs.c:100:2: warning: switch condition has boolean 
> value [-Wswitch-bool]

10fbd36e362a ("blk: rq_data_dir() should not return a boolean")

> 35 mm/page_alloc.c:5435:34: warning: array subscript is below array bounds 
> [-Warray-bounds]

I think this was fixed by

90cae1fe1c35 ("mm/init: fix zone boundary creation")
which was intended to address another problem but got backported to 4.4

> 20 arch/arm/include/asm/cmpxchg.h:122:3: warning: value computed is not used 
> [-Wunused-value]
> 5 arch/arm/include/asm/cmpxchg.h:205:3: warning: value computed is not used 
> [-Wunused-value]

d975440bf80c ("asm-generic: cmpxchg: avoid warnings from macro-ized
cmpxchg() implementations")

> 10 drivers/rtc/rtc-pcf8563.c:444:5: warning: 'alm_pending' may be used 
> uninitialized in this function [-Wmaybe-uninitialized]

cd1420d3a909 ("rtc: pfc8563: fix uninitialized variable warning")

> 6 crypto/wp512.c:987:1: warning: the frame size of 1112 bytes is larger than 
> 1024 bytes [-Wframe-larger-than=]
> 1 crypto/wp512.c:987:1: warning: the frame size of 1344 bytes is larger than 
> 1024 bytes [-Wframe-larger-than=]
> 1 crypto/wp512.c:987:1: warning: the frame size of 1280 bytes is larger than 
> 1024 bytes [-Wframe-larger-than=]
> 1 crypto/wp512.c:987:1: warning: the frame size of 1152 bytes is larger than 
> 1024 bytes [-Wframe-larger-than=]
> 1 crypto/wp512.c:987:1: warning: the frame size of 1144 bytes is larger than 
> 1024 bytes [-Wframe-larger-than=]
> 1 crypto/wp512.c:987:1: warning: the frame size of 1120 bytes is larger than 
> 1024 bytes [-Wframe-larger-than=]
> 1 crypto/serpent_generic.c:436:1: warning: the frame size of 1472 bytes is 
> larger than 1024 bytes [-Wframe-larger-than=]
> 1 crypto/serpent_generic.c:436:1: warning: the frame size of 1456 bytes is 
> larger than 1024 bytes [-Wframe-larger-than=]
7d6e9105026 ("crypto: improve gcc optimization flags for serpent and wp512")

> 4 fs/nfsd/nfs4state.c:3962:3: warning: 'old_deny_bmap' may be used 
> uninitialized in this function [-Wmaybe-uninitialized]

6ac75368e1a6 ("nfsd: work around a gcc-5.1 warning")

> 3 drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c:1478:8: warning: 'skb' 
> may be used uninitialized in this function [-Wmaybe-uninitialized]

22f44150aad7 ("brcmfmac: avoid gcc-5.1 warning")

> 2 lib/iommu-common.c:15:24: warning: large integer implicitly truncated to 
> unsigned type [-Woverflow]

447f6a95a9c8 ("lib/iommu-common.c: do not use 0xl for
computing align_mask")

> 2 drivers/hid/hid-input.c:1163:67: warning: logical not is only applied to 
> the left hand side of comparison [-Wlogical-not-parentheses]

09a5c34e8d6b ("HID: hid-input: Add parentheses to quell gcc warning")

> 2 drivers/atm/iphase.c:1176:12: warning: this 'if' clause does not guard... 
> [-Wmisleading-indentation]

cbb41b91e68a ("atm: iphase: fix misleading indention")

> 2 arch/x86/include/asm/msr.h:209:23: warning: right shift count >= width of 
> type [-Wshift-count-overflow]

cf991de2f614 ("x86/asm/msr: Make wrmsrl_safe() a function")
47edb65178cb ("x86/asm/msr: Make wrmsrl() a function")

> 1 fs/gfs2/dir.c:978:8: warning: 'leaf_no' may be used uninitialized in this 
> function [-Wmaybe-uninitialized]
> 1 fs/gfs2/dir.c:759:9: warning: 'leaf_no' may be used uninitialized in this 
> function [-Wmaybe-uninitialized]

d39cb4a59729 ("gfs2: avoid uninitialized variable warning")

> 1 drivers/net/ethernet/ti/cpmac.c:1238:2: warning: #warning FIXME: unhardcode 
> gpio bits [-Wcpp]

d43e6fb4ac4a ("cpmac: remove hopeless #warning")


> 1 drivers/scsi/mvsas/mv_sas.c:736:3: warning: this 'else' clause does not 
> guard... [-Wmisleading-indentation]

7789cd39274c ("mvsas: fix misleading indentation")

> 1 

Re: [RESEND PATCH v2 14/15] ASoC: qcom: apq8096: Add db820c machine driver

[Bjorn Andersson]

On Thu 14 Dec 09:34 PST 2017, srinivas.kandaga...@linaro.org wrote:

> From: Srinivas Kandagatla 
> 
> uThis patch adds support to DB820c machine driver.

Drop 'u' and expand the message to claim that this is the machine driver
for 8996, used by the db820c.

[..]
> +static struct snd_soc_dai_link msm8996_dai_links[] = {

Are there any differences between the DAI links of apq8096 and msm8996?

> + /* FrontEnd DAI Links */
> + {
> + .name   = "MultiMedia1 Playback",
> + .stream_name= "MultiMedia1",
> + .cpu_dai_name   = "MM_DL1",
> + .platform_name  = "q6asm_dai",
> + .dynamic= 1,
> + .dpcm_playback  = 1,
> +
> + .codec_dai_name = "snd-soc-dummy-dai",
> + .codec_name = "snd-soc-dummy",
> + },
> + /* Backend DAI Links */
> + {
> + .name   = "HDMI Playback",
> + .stream_name= "q6afe_dai",
> + .cpu_dai_name   = "HDMI",
> + .platform_name  = "q6routing",
> + .no_pcm = 1,
> + .dpcm_playback  = 1,
> + .be_hw_params_fixup = msm8996_be_hw_params_fixup,
> + .codec_dai_name = "i2s-hifi",
> + .codec_name = "hdmi-audio-codec.0.auto",
> + },
> +};
> +
> +static int apq8096_sbc_parse_of(struct snd_soc_card *card)

msm8996_parse_of()

> +{
> + struct device *dev = card->dev;
> + int ret;
> +
> + ret = snd_soc_of_parse_card_name(card, "qcom,model");
> + if (ret)
> + dev_err(dev, "Error parsing card name: %d\n", ret);
> +
> + return ret;
> +}
> +
> +static int msm_snd_apq8096_probe(struct platform_device *pdev)

msm_snd_msm8996_probe()?

> +{
> + int ret;
> + struct snd_soc_card *card;
> +
> + card = devm_kzalloc(>dev, sizeof(*card), GFP_KERNEL);
> + if (!card)
> + return -ENOMEM;
> +
> + card->dev = >dev;
> +
> + ret = dma_coerce_mask_and_coherent(card->dev, DMA_BIT_MASK(32));
> + if (ret)
> + return ret;
> +
> + card->dai_link = msm8996_dai_links;
> + card->num_links = ARRAY_SIZE(msm8996_dai_links);
> +
> + ret = apq8096_sbc_parse_of(card);
> + if (ret) {
> + dev_err(>dev, "Error parsing OF data\n");

No need to print in both parse_of() and here.

> + return ret;
> + }
> +
> + ret = devm_snd_soc_register_card(>dev, card);
> + if (ret)
> + dev_err(>dev, "sound card register failed (%d)!\n", ret);
> + else
> + dev_err(>dev, "sound card register Sucessfull\n");

This isn't an error, skip the print here.

> +
> + return ret;
> +}
> +
> +static const struct of_device_id msm_snd_apq8096_dt_match[] = {
> + {.compatible = "qcom,apq8096-sndcard"},
> + {}
> +};
> +
> +static struct platform_driver msm_snd_apq8096_driver = {
> + .probe  = msm_snd_apq8096_probe,
> + .driver = {
> + .name = "msm-snd-apq8096",
> + .owner = THIS_MODULE,

Drop the .owner

Regards,
Bjorn

Re: [RESEND PATCH v2 14/15] ASoC: qcom: apq8096: Add db820c machine driver

[Bjorn Andersson]

On Thu 14 Dec 09:34 PST 2017, srinivas.kandaga...@linaro.org wrote:

> From: Srinivas Kandagatla 
> 
> uThis patch adds support to DB820c machine driver.

Drop 'u' and expand the message to claim that this is the machine driver
for 8996, used by the db820c.

[..]
> +static struct snd_soc_dai_link msm8996_dai_links[] = {

Are there any differences between the DAI links of apq8096 and msm8996?

> + /* FrontEnd DAI Links */
> + {
> + .name   = "MultiMedia1 Playback",
> + .stream_name= "MultiMedia1",
> + .cpu_dai_name   = "MM_DL1",
> + .platform_name  = "q6asm_dai",
> + .dynamic= 1,
> + .dpcm_playback  = 1,
> +
> + .codec_dai_name = "snd-soc-dummy-dai",
> + .codec_name = "snd-soc-dummy",
> + },
> + /* Backend DAI Links */
> + {
> + .name   = "HDMI Playback",
> + .stream_name= "q6afe_dai",
> + .cpu_dai_name   = "HDMI",
> + .platform_name  = "q6routing",
> + .no_pcm = 1,
> + .dpcm_playback  = 1,
> + .be_hw_params_fixup = msm8996_be_hw_params_fixup,
> + .codec_dai_name = "i2s-hifi",
> + .codec_name = "hdmi-audio-codec.0.auto",
> + },
> +};
> +
> +static int apq8096_sbc_parse_of(struct snd_soc_card *card)

msm8996_parse_of()

> +{
> + struct device *dev = card->dev;
> + int ret;
> +
> + ret = snd_soc_of_parse_card_name(card, "qcom,model");
> + if (ret)
> + dev_err(dev, "Error parsing card name: %d\n", ret);
> +
> + return ret;
> +}
> +
> +static int msm_snd_apq8096_probe(struct platform_device *pdev)

msm_snd_msm8996_probe()?

> +{
> + int ret;
> + struct snd_soc_card *card;
> +
> + card = devm_kzalloc(>dev, sizeof(*card), GFP_KERNEL);
> + if (!card)
> + return -ENOMEM;
> +
> + card->dev = >dev;
> +
> + ret = dma_coerce_mask_and_coherent(card->dev, DMA_BIT_MASK(32));
> + if (ret)
> + return ret;
> +
> + card->dai_link = msm8996_dai_links;
> + card->num_links = ARRAY_SIZE(msm8996_dai_links);
> +
> + ret = apq8096_sbc_parse_of(card);
> + if (ret) {
> + dev_err(>dev, "Error parsing OF data\n");

No need to print in both parse_of() and here.

> + return ret;
> + }
> +
> + ret = devm_snd_soc_register_card(>dev, card);
> + if (ret)
> + dev_err(>dev, "sound card register failed (%d)!\n", ret);
> + else
> + dev_err(>dev, "sound card register Sucessfull\n");

This isn't an error, skip the print here.

> +
> + return ret;
> +}
> +
> +static const struct of_device_id msm_snd_apq8096_dt_match[] = {
> + {.compatible = "qcom,apq8096-sndcard"},
> + {}
> +};
> +
> +static struct platform_driver msm_snd_apq8096_driver = {
> + .probe  = msm_snd_apq8096_probe,
> + .driver = {
> + .name = "msm-snd-apq8096",
> + .owner = THIS_MODULE,

Drop the .owner

Regards,
Bjorn

Re: [patch v6 2/3] platform/mellanox: mlxreg-hotplug: allow driver for ARM architecture

[Darren Hart]

On Wed, Dec 20, 2017 at 05:11:51PM +0800, kbuild test robot wrote:
> Hi Vadim,
> 

Hi Vadim,

This has been a long time in development, and has been tricky to get everyone
aligned for review. I'm prioritizing this series now and will commit to
reviewing in a timely manner. I assume you have seen the build error below -
will you prepare a v7 which addresses the build issue?

Regards,

> I love your patch! Yet something to improve:
> 
> [auto build test ERROR on platform-drivers-x86/for-next]
> [also build test ERROR on v4.15-rc4 next-20171220]
> [cannot apply to linus/master]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Vadim-Pasternak/drivers-platform-replace-module-x86-mlxcpld-hotplug-with-mellanox-mlxreg-hotplug/20171220-163359
> base:   git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git 
> for-next
> config: sparc64-allyesconfig (attached as .config)
> compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=sparc64 
> 
> Note: the 
> linux-review/Vadim-Pasternak/drivers-platform-replace-module-x86-mlxcpld-hotplug-with-mellanox-mlxreg-hotplug/20171220-163359
>  HEAD 7e98e72a743e69069c34f3bbd3b9289740e30de0 builds fine.
>   It only hurts bisectibility.
> 
> All errors (new ones prefixed by >>):
> 
>drivers/platform/mellanox/mlxreg-hotplug.c: In function 
> 'mlxreg_hotplug_attr_show':
> >> drivers/platform/mellanox/mlxreg-hotplug.c:224:17: error: implicit 
> >> declaration of function 'inb' [-Werror=implicit-function-declaration]
>   reg_val = !!!(inb(priv->plat->psu_reg_offset) & BIT(index));
> ^~~
>drivers/platform/mellanox/mlxreg-hotplug.c: In function 
> 'mlxreg_hotplug_work_helper':
> >> drivers/platform/mellanox/mlxreg-hotplug.c:305:2: error: implicit 
> >> declaration of function 'outb' [-Werror=implicit-function-declaration]
>  outb(0, offset + MLXREG_HOTPLUG_MASK_OFF);
>  ^~~~
>cc1: some warnings being treated as errors
> 
> vim +/inb +224 drivers/platform/mellanox/mlxreg-hotplug.c
> 
> 86a4f473 drivers/platform/mellanox/mlxreg-hotplug.c Vadim Pasternak 
> 2017-12-18  210  
> ebea1439 drivers/platform/mellanox/mlxreg-hotplug.c Vadim Pasternak 
> 2017-12-18  211  static ssize_t mlxreg_hotplug_attr_show(struct device *dev,
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20  212   struct device_attribute 
> *attr,
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20  213   char *buf)
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20  214  {
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20  215   struct platform_device *pdev = to_platform_device(dev);
> ebea1439 drivers/platform/mellanox/mlxreg-hotplug.c Vadim Pasternak 
> 2017-12-18  216   struct mlxreg_hotplug_priv_data *priv = 
> platform_get_drvdata(pdev);
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20  217   int index = to_sensor_dev_attr_2(attr)->index;
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20  218   int nr = to_sensor_dev_attr_2(attr)->nr;
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20  219   u8 reg_val = 0;
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20  220  
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20  221   switch (nr) {
> ebea1439 drivers/platform/mellanox/mlxreg-hotplug.c Vadim Pasternak 
> 2017-12-18  222   case MLXREG_HOTPLUG_ATTR_TYPE_PSU:
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20  223   /* Bit = 0 : PSU is present. */
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20 @224   reg_val = !!!(inb(priv->plat->psu_reg_offset) & 
> BIT(index));
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20  225   break;
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20  226  
> ebea1439 drivers/platform/mellanox/mlxreg-hotplug.c Vadim Pasternak 
> 2017-12-18  227   case MLXREG_HOTPLUG_ATTR_TYPE_PWR:
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20  228   /* Bit = 1 : power cable is attached. */
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20  229   reg_val = !!(inb(priv->plat->pwr_reg_offset) & 
> BIT(index %
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20  230  

Re: [patch v6 2/3] platform/mellanox: mlxreg-hotplug: allow driver for ARM architecture

[Darren Hart]

On Wed, Dec 20, 2017 at 05:11:51PM +0800, kbuild test robot wrote:
> Hi Vadim,
> 

Hi Vadim,

This has been a long time in development, and has been tricky to get everyone
aligned for review. I'm prioritizing this series now and will commit to
reviewing in a timely manner. I assume you have seen the build error below -
will you prepare a v7 which addresses the build issue?

Regards,

> I love your patch! Yet something to improve:
> 
> [auto build test ERROR on platform-drivers-x86/for-next]
> [also build test ERROR on v4.15-rc4 next-20171220]
> [cannot apply to linus/master]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Vadim-Pasternak/drivers-platform-replace-module-x86-mlxcpld-hotplug-with-mellanox-mlxreg-hotplug/20171220-163359
> base:   git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git 
> for-next
> config: sparc64-allyesconfig (attached as .config)
> compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=sparc64 
> 
> Note: the 
> linux-review/Vadim-Pasternak/drivers-platform-replace-module-x86-mlxcpld-hotplug-with-mellanox-mlxreg-hotplug/20171220-163359
>  HEAD 7e98e72a743e69069c34f3bbd3b9289740e30de0 builds fine.
>   It only hurts bisectibility.
> 
> All errors (new ones prefixed by >>):
> 
>drivers/platform/mellanox/mlxreg-hotplug.c: In function 
> 'mlxreg_hotplug_attr_show':
> >> drivers/platform/mellanox/mlxreg-hotplug.c:224:17: error: implicit 
> >> declaration of function 'inb' [-Werror=implicit-function-declaration]
>   reg_val = !!!(inb(priv->plat->psu_reg_offset) & BIT(index));
> ^~~
>drivers/platform/mellanox/mlxreg-hotplug.c: In function 
> 'mlxreg_hotplug_work_helper':
> >> drivers/platform/mellanox/mlxreg-hotplug.c:305:2: error: implicit 
> >> declaration of function 'outb' [-Werror=implicit-function-declaration]
>  outb(0, offset + MLXREG_HOTPLUG_MASK_OFF);
>  ^~~~
>cc1: some warnings being treated as errors
> 
> vim +/inb +224 drivers/platform/mellanox/mlxreg-hotplug.c
> 
> 86a4f473 drivers/platform/mellanox/mlxreg-hotplug.c Vadim Pasternak 
> 2017-12-18  210  
> ebea1439 drivers/platform/mellanox/mlxreg-hotplug.c Vadim Pasternak 
> 2017-12-18  211  static ssize_t mlxreg_hotplug_attr_show(struct device *dev,
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20  212   struct device_attribute 
> *attr,
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20  213   char *buf)
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20  214  {
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20  215   struct platform_device *pdev = to_platform_device(dev);
> ebea1439 drivers/platform/mellanox/mlxreg-hotplug.c Vadim Pasternak 
> 2017-12-18  216   struct mlxreg_hotplug_priv_data *priv = 
> platform_get_drvdata(pdev);
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20  217   int index = to_sensor_dev_attr_2(attr)->index;
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20  218   int nr = to_sensor_dev_attr_2(attr)->nr;
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20  219   u8 reg_val = 0;
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20  220  
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20  221   switch (nr) {
> ebea1439 drivers/platform/mellanox/mlxreg-hotplug.c Vadim Pasternak 
> 2017-12-18  222   case MLXREG_HOTPLUG_ATTR_TYPE_PSU:
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20  223   /* Bit = 0 : PSU is present. */
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20 @224   reg_val = !!!(inb(priv->plat->psu_reg_offset) & 
> BIT(index));
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20  225   break;
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20  226  
> ebea1439 drivers/platform/mellanox/mlxreg-hotplug.c Vadim Pasternak 
> 2017-12-18  227   case MLXREG_HOTPLUG_ATTR_TYPE_PWR:
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20  228   /* Bit = 1 : power cable is attached. */
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20  229   reg_val = !!(inb(priv->plat->pwr_reg_offset) & 
> BIT(index %
> 30488704 drivers/platform/x86/mlxcpld-hotplug.c Vadim Pasternak 
> 2016-10-20  230  

Re: PROBLEM: i915 causes complete desktop freezes in 4.15-rc5

[Alexandru Chirvasitu]

For comparison, here's another one produced by the same kernel, on the
same laptop, but a different hard drive.

The OS was installed on a USB stick that I'd boot the laptop off
of. Recently I started getting lags when copying to / from the stick,
so I moved the OS to an external SSD.

Everything else stayed the same, and booting the same kernel resulted
in the same type of freeze. 

On Tue, Jan 02, 2018 at 04:39:22PM -0500, Alexandru Chirvasitu wrote:
> Attached. Crashed quite a bit faster than before this time.
> 
> It always seems to have something to do with opening and alt-tabbing
> between windows. This time what produced the crash was an attempt to
> open a new terminal.
> 
> The hanging happened right after issuing the keyboard shortcut, before
> the focus had time to switch to the newly-opened terminal window.
> 
> Still unable to crash it reliably though, so there's no telling how
> promptly I can produce these.
> 
> 
> 
> 
> On Tue, Jan 02, 2018 at 04:53:45PM +, Chris Wilson wrote:
> > Quoting Alexandru Chirvasitu (2018-01-01 21:13:57)
> > > All right, we're in business with the new dmesg: It hung again, with a
> > > 4.15-rc6 kernel with kasan support.
> > > 
> > > The new dmesg is attached; the trace is longer now, as you expected.
> > 
> > Ok, still the same poison but kasan didn't report a use-after-free. Odd.
> > 
> > Can you disable CONFIG_SLAB_MERGE_DEFAULT and try again? This will stop
> > anyone else from overwriting the i915_dependency.
> > -Chris

> [0.00] microcode: microcode updated early to revision 0x62, date = 
> 2017-04-27
> [0.00] Linux version 4.15.0-rc6-x-void-noslb (root@axiomatic) (gcc 
> version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)) #1 SMP PREEMPT Tue 
> Jan 2 13:03:34 EST 2018
> [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-rc6-x-void-noslb 
> root=UUID=66d5a55f-8ca3-47a1-850d-a0886325481c ro loglevel=4 slub_debug=P 
> page_poison=1
> [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
> registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
> [0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
> [0.00] x86/fpu: xstate_offset[3]:  832, xstate_sizes[3]:   64
> [0.00] x86/fpu: xstate_offset[4]:  896, xstate_sizes[4]:   64
> [0.00] x86/fpu: Enabled xstate features 0x1f, context size is 960 
> bytes, using 'compacted' format.
> [0.00] e820: BIOS-provided physical RAM map:
> [0.00] BIOS-e820: [mem 0x-0x0009c3ff] usable
> [0.00] BIOS-e820: [mem 0x0009c400-0x0009] reserved
> [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
> [0.00] BIOS-e820: [mem 0x0010-0x86ebbfff] usable
> [0.00] BIOS-e820: [mem 0x86ebc000-0x871bbfff] ACPI NVS
> [0.00] BIOS-e820: [mem 0x871bc000-0x880e2fff] usable
> [0.00] BIOS-e820: [mem 0x880e3000-0x880e3fff] ACPI NVS
> [0.00] BIOS-e820: [mem 0x880e4000-0x880e4fff] reserved
> [0.00] BIOS-e820: [mem 0x880e5000-0x8c227fff] usable
> [0.00] BIOS-e820: [mem 0x8c228000-0x8cb97fff] reserved
> [0.00] BIOS-e820: [mem 0x8cb98000-0x8cc67fff] usable
> [0.00] BIOS-e820: [mem 0x8cc68000-0x8cfe1fff] ACPI NVS
> [0.00] BIOS-e820: [mem 0x8cfe2000-0x8d3fdfff] reserved
> [0.00] BIOS-e820: [mem 0x8d3fe000-0x8d3fefff] usable
> [0.00] BIOS-e820: [mem 0x8d3ff000-0x8fff] reserved
> [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
> [0.00] BIOS-e820: [mem 0xfe00-0xfe010fff] reserved
> [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
> [0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved
> [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
> [0.00] BIOS-e820: [mem 0xff00-0x] reserved
> [0.00] BIOS-e820: [mem 0x0001-0x00086eff] usable
> [0.00] NX (Execute Disable) protection: active
> [0.00] random: fast init done
> [0.00] SMBIOS 3.0.0 present.
> [0.00] DMI: Notebook N24_25BU/N24_25BU, BIOS 
> 5.12 02/17/2017
> [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
> [0.00] e820: remove [mem 0x000a-0x000f] usable
> [0.00] e820: last_pfn = 0x86f000 max_arch_pfn = 0x4
> [0.00] MTRR default type: write-back
> [0.00] 

Re: PROBLEM: i915 causes complete desktop freezes in 4.15-rc5

[Alexandru Chirvasitu]

For comparison, here's another one produced by the same kernel, on the
same laptop, but a different hard drive.

The OS was installed on a USB stick that I'd boot the laptop off
of. Recently I started getting lags when copying to / from the stick,
so I moved the OS to an external SSD.

Everything else stayed the same, and booting the same kernel resulted
in the same type of freeze. 

On Tue, Jan 02, 2018 at 04:39:22PM -0500, Alexandru Chirvasitu wrote:
> Attached. Crashed quite a bit faster than before this time.
> 
> It always seems to have something to do with opening and alt-tabbing
> between windows. This time what produced the crash was an attempt to
> open a new terminal.
> 
> The hanging happened right after issuing the keyboard shortcut, before
> the focus had time to switch to the newly-opened terminal window.
> 
> Still unable to crash it reliably though, so there's no telling how
> promptly I can produce these.
> 
> 
> 
> 
> On Tue, Jan 02, 2018 at 04:53:45PM +, Chris Wilson wrote:
> > Quoting Alexandru Chirvasitu (2018-01-01 21:13:57)
> > > All right, we're in business with the new dmesg: It hung again, with a
> > > 4.15-rc6 kernel with kasan support.
> > > 
> > > The new dmesg is attached; the trace is longer now, as you expected.
> > 
> > Ok, still the same poison but kasan didn't report a use-after-free. Odd.
> > 
> > Can you disable CONFIG_SLAB_MERGE_DEFAULT and try again? This will stop
> > anyone else from overwriting the i915_dependency.
> > -Chris

> [0.00] microcode: microcode updated early to revision 0x62, date = 
> 2017-04-27
> [0.00] Linux version 4.15.0-rc6-x-void-noslb (root@axiomatic) (gcc 
> version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)) #1 SMP PREEMPT Tue 
> Jan 2 13:03:34 EST 2018
> [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-rc6-x-void-noslb 
> root=UUID=66d5a55f-8ca3-47a1-850d-a0886325481c ro loglevel=4 slub_debug=P 
> page_poison=1
> [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
> registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
> [0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
> [0.00] x86/fpu: xstate_offset[3]:  832, xstate_sizes[3]:   64
> [0.00] x86/fpu: xstate_offset[4]:  896, xstate_sizes[4]:   64
> [0.00] x86/fpu: Enabled xstate features 0x1f, context size is 960 
> bytes, using 'compacted' format.
> [0.00] e820: BIOS-provided physical RAM map:
> [0.00] BIOS-e820: [mem 0x-0x0009c3ff] usable
> [0.00] BIOS-e820: [mem 0x0009c400-0x0009] reserved
> [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
> [0.00] BIOS-e820: [mem 0x0010-0x86ebbfff] usable
> [0.00] BIOS-e820: [mem 0x86ebc000-0x871bbfff] ACPI NVS
> [0.00] BIOS-e820: [mem 0x871bc000-0x880e2fff] usable
> [0.00] BIOS-e820: [mem 0x880e3000-0x880e3fff] ACPI NVS
> [0.00] BIOS-e820: [mem 0x880e4000-0x880e4fff] reserved
> [0.00] BIOS-e820: [mem 0x880e5000-0x8c227fff] usable
> [0.00] BIOS-e820: [mem 0x8c228000-0x8cb97fff] reserved
> [0.00] BIOS-e820: [mem 0x8cb98000-0x8cc67fff] usable
> [0.00] BIOS-e820: [mem 0x8cc68000-0x8cfe1fff] ACPI NVS
> [0.00] BIOS-e820: [mem 0x8cfe2000-0x8d3fdfff] reserved
> [0.00] BIOS-e820: [mem 0x8d3fe000-0x8d3fefff] usable
> [0.00] BIOS-e820: [mem 0x8d3ff000-0x8fff] reserved
> [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
> [0.00] BIOS-e820: [mem 0xfe00-0xfe010fff] reserved
> [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
> [0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved
> [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
> [0.00] BIOS-e820: [mem 0xff00-0x] reserved
> [0.00] BIOS-e820: [mem 0x0001-0x00086eff] usable
> [0.00] NX (Execute Disable) protection: active
> [0.00] random: fast init done
> [0.00] SMBIOS 3.0.0 present.
> [0.00] DMI: Notebook N24_25BU/N24_25BU, BIOS 
> 5.12 02/17/2017
> [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
> [0.00] e820: remove [mem 0x000a-0x000f] usable
> [0.00] e820: last_pfn = 0x86f000 max_arch_pfn = 0x4
> [0.00] MTRR default type: write-back
> [0.00] 

[PATCH V6] mmc:host:sdhci-pci:Addition of Arasan PCI Controller with integrated phy.

[Atul Garg]

The Arasan Controller is based on a FPGA platform and has integrated phy
with specific registers used during initialization and
management of different modes. The phy and the controller are integrated
and registers are very specific to Arasan.

Arasan being an IP provider, licenses these IPs to various companies for
integration of IP in custom SOCs. The custom SOCs define own register
map depending on how bits are tied inside the SOC for phy registers,
depending on SOC memory plan and hence will require own platform drivers.

If more details on phy registers are required, an interface document is
hosted at https: //arasandotcom/NF/eMMC5.1 PHY Programming in Linux.pdf.

Signed-off-by: Atul Garg 
---
V6 - Parameters are enclosed in parantheses in macros. Adjusted tab space.
Removed ret variable in arasan_phy_addr_poll.
V5 - Separated arasan_phy_poll function into arasan_phy_addr_poll and
arasan_phy_sts_poll  Tabspace corrected. Checked return values of poll 
functions.
Removed static declaration of sdhci_pci_enable_dma and defined in
sdhci-pci.h as suggested by Adrian Hunter .
V4 - Created arasan_phy_poll function to have common timeout call.
.Restructured arasan_set_phy to arasan_select_phy_clock and
.arasan_phy_set to have single set of registers to be programmed for different 
modes.
.Applied code style suggestions from Adrian Hunter .
V3 - Removed sdhci-pci-arasan.h. Code and interface document mentioned
above are made relevant..Applied code style suggestions from
Sekhar Nori  and .Adrian Hunter .
V2 - Removed code from sdhci-pci-core.c and created sdhci-pci-arasan.c and
.sdhci-pci-arasan.h.
V1 - Initial Patch coded in sdhci-pci-core.c.

 drivers/mmc/host/Makefile   |   2 +-
 drivers/mmc/host/sdhci-pci-arasan.c | 338 
 drivers/mmc/host/sdhci-pci-core.c   |   4 +-
 drivers/mmc/host/sdhci-pci.h|   7 +-
 4 files changed, 347 insertions(+), 4 deletions(-)
 create mode 100644 drivers/mmc/host/sdhci-pci-arasan.c

diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 191a040..84cd138 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -11,7 +11,7 @@ obj-$(CONFIG_MMC_MXC) += mxcmmc.o
 obj-$(CONFIG_MMC_MXS)  += mxs-mmc.o
 obj-$(CONFIG_MMC_SDHCI)+= sdhci.o
 obj-$(CONFIG_MMC_SDHCI_PCI)+= sdhci-pci.o
-sdhci-pci-y+= sdhci-pci-core.o sdhci-pci-o2micro.o
+sdhci-pci-y+= sdhci-pci-core.o sdhci-pci-o2micro.o 
sdhci-pci-arasan.o
 obj-$(subst m,y,$(CONFIG_MMC_SDHCI_PCI))   += sdhci-pci-data.o
 obj-$(CONFIG_MMC_SDHCI_ACPI)   += sdhci-acpi.o
 obj-$(CONFIG_MMC_SDHCI_PXAV3)  += sdhci-pxav3.o
diff --git a/drivers/mmc/host/sdhci-pci-arasan.c 
b/drivers/mmc/host/sdhci-pci-arasan.c
new file mode 100644
index 000..79d1f74
--- /dev/null
+++ b/drivers/mmc/host/sdhci-pci-arasan.c
@@ -0,0 +1,338 @@
+/*
+ * Copyright (C) 2017 Arasan Chip Systems Inc.
+ *
+ * Author: Atul Garg 
+ *
+ * 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 "sdhci.h"
+#include "sdhci-pci.h"
+
+/* Extra registers for Arasan SD Host Controller for eMMC5.1 PHY */
+#define PHY_ADDR_REG   0x300
+#define PHY_DAT_REG0x304
+
+#define PHY_WRITE  BIT(8)
+#define PHY_BUSY   BIT(9)
+#define DATA_MASK  0xFF
+
+/* eMMC5.1 PHY Specific Registers */
+#define DLL_STATUS 0x00
+#define IPAD_CTRL1 0x01
+#define IPAD_CTRL2 0x02
+#define IPAD_STS   0x03
+#define IOREN_CTRL10x06
+#define IOREN_CTRL20x07
+#define IOPU_CTRL1 0x08
+#define IOPU_CTRL2 0x09
+#define ITAP_DELAY 0x0C
+#define OTAP_DELAY 0x0D
+#define STRB_SEL   0x0E
+#define CLKBUF_SEL 0x0F
+#define MODE_CTRL  0x11
+#define DLL_TRIM   0x12
+#define CMD_CTRL   0x20
+#define DATA_CTRL  0x21
+#define STRB_CTRL  0x22
+#define CLK_CTRL   0x23
+#define PHY_CTRL   0x24
+
+#define DLL_ENBL   BIT(3)
+#define RTRIM_EN   BIT(1)
+#define PDB_ENBL   BIT(1)
+#define RETB_ENBL  BIT(6)
+#define ODEN_CMD   BIT(1)
+#define ODEN_DAT   0xFF
+#define REN_STRB   BIT(0)
+#define REN_CMND   BIT(1)
+#define REN_DATA   0xFF
+#define PU_CMD BIT(1)
+#define PU_DAT 0xFF
+#define ITAPDLY_EN BIT(0)
+#define OTAPDLY_EN BIT(0)
+#define OD_REL_CMD BIT(1)
+#define OD_REL_DAT 0xFF
+#define DLLTRM_ICP 0x8
+#define PDB_CMND   BIT(0)
+#define PDB_DATA   

[PATCH V6] mmc:host:sdhci-pci:Addition of Arasan PCI Controller with integrated phy.

[Atul Garg]

The Arasan Controller is based on a FPGA platform and has integrated phy
with specific registers used during initialization and
management of different modes. The phy and the controller are integrated
and registers are very specific to Arasan.

Arasan being an IP provider, licenses these IPs to various companies for
integration of IP in custom SOCs. The custom SOCs define own register
map depending on how bits are tied inside the SOC for phy registers,
depending on SOC memory plan and hence will require own platform drivers.

If more details on phy registers are required, an interface document is
hosted at https: //arasandotcom/NF/eMMC5.1 PHY Programming in Linux.pdf.

Signed-off-by: Atul Garg 
---
V6 - Parameters are enclosed in parantheses in macros. Adjusted tab space.
Removed ret variable in arasan_phy_addr_poll.
V5 - Separated arasan_phy_poll function into arasan_phy_addr_poll and
arasan_phy_sts_poll  Tabspace corrected. Checked return values of poll 
functions.
Removed static declaration of sdhci_pci_enable_dma and defined in
sdhci-pci.h as suggested by Adrian Hunter .
V4 - Created arasan_phy_poll function to have common timeout call.
.Restructured arasan_set_phy to arasan_select_phy_clock and
.arasan_phy_set to have single set of registers to be programmed for different 
modes.
.Applied code style suggestions from Adrian Hunter .
V3 - Removed sdhci-pci-arasan.h. Code and interface document mentioned
above are made relevant..Applied code style suggestions from
Sekhar Nori  and .Adrian Hunter .
V2 - Removed code from sdhci-pci-core.c and created sdhci-pci-arasan.c and
.sdhci-pci-arasan.h.
V1 - Initial Patch coded in sdhci-pci-core.c.

 drivers/mmc/host/Makefile   |   2 +-
 drivers/mmc/host/sdhci-pci-arasan.c | 338 
 drivers/mmc/host/sdhci-pci-core.c   |   4 +-
 drivers/mmc/host/sdhci-pci.h|   7 +-
 4 files changed, 347 insertions(+), 4 deletions(-)
 create mode 100644 drivers/mmc/host/sdhci-pci-arasan.c

diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 191a040..84cd138 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -11,7 +11,7 @@ obj-$(CONFIG_MMC_MXC) += mxcmmc.o
 obj-$(CONFIG_MMC_MXS)  += mxs-mmc.o
 obj-$(CONFIG_MMC_SDHCI)+= sdhci.o
 obj-$(CONFIG_MMC_SDHCI_PCI)+= sdhci-pci.o
-sdhci-pci-y+= sdhci-pci-core.o sdhci-pci-o2micro.o
+sdhci-pci-y+= sdhci-pci-core.o sdhci-pci-o2micro.o 
sdhci-pci-arasan.o
 obj-$(subst m,y,$(CONFIG_MMC_SDHCI_PCI))   += sdhci-pci-data.o
 obj-$(CONFIG_MMC_SDHCI_ACPI)   += sdhci-acpi.o
 obj-$(CONFIG_MMC_SDHCI_PXAV3)  += sdhci-pxav3.o
diff --git a/drivers/mmc/host/sdhci-pci-arasan.c 
b/drivers/mmc/host/sdhci-pci-arasan.c
new file mode 100644
index 000..79d1f74
--- /dev/null
+++ b/drivers/mmc/host/sdhci-pci-arasan.c
@@ -0,0 +1,338 @@
+/*
+ * Copyright (C) 2017 Arasan Chip Systems Inc.
+ *
+ * Author: Atul Garg 
+ *
+ * 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 "sdhci.h"
+#include "sdhci-pci.h"
+
+/* Extra registers for Arasan SD Host Controller for eMMC5.1 PHY */
+#define PHY_ADDR_REG   0x300
+#define PHY_DAT_REG0x304
+
+#define PHY_WRITE  BIT(8)
+#define PHY_BUSY   BIT(9)
+#define DATA_MASK  0xFF
+
+/* eMMC5.1 PHY Specific Registers */
+#define DLL_STATUS 0x00
+#define IPAD_CTRL1 0x01
+#define IPAD_CTRL2 0x02
+#define IPAD_STS   0x03
+#define IOREN_CTRL10x06
+#define IOREN_CTRL20x07
+#define IOPU_CTRL1 0x08
+#define IOPU_CTRL2 0x09
+#define ITAP_DELAY 0x0C
+#define OTAP_DELAY 0x0D
+#define STRB_SEL   0x0E
+#define CLKBUF_SEL 0x0F
+#define MODE_CTRL  0x11
+#define DLL_TRIM   0x12
+#define CMD_CTRL   0x20
+#define DATA_CTRL  0x21
+#define STRB_CTRL  0x22
+#define CLK_CTRL   0x23
+#define PHY_CTRL   0x24
+
+#define DLL_ENBL   BIT(3)
+#define RTRIM_EN   BIT(1)
+#define PDB_ENBL   BIT(1)
+#define RETB_ENBL  BIT(6)
+#define ODEN_CMD   BIT(1)
+#define ODEN_DAT   0xFF
+#define REN_STRB   BIT(0)
+#define REN_CMND   BIT(1)
+#define REN_DATA   0xFF
+#define PU_CMD BIT(1)
+#define PU_DAT 0xFF
+#define ITAPDLY_EN BIT(0)
+#define OTAPDLY_EN BIT(0)
+#define OD_REL_CMD BIT(1)
+#define OD_REL_DAT 0xFF
+#define DLLTRM_ICP 0x8
+#define PDB_CMND   BIT(0)
+#define PDB_DATA   0xFF
+#define PDB_STRB   BIT(0)
+#define PDB_CLOCK  BIT(0)
+#define CALDONE_MASK   0x10
+#define DLL_RDY_MASK   

Re: platform/x86/thinkpad_acpi: Adjustments for four function implementations

[Darren Hart]

On Sat, Dec 23, 2017 at 08:12:21AM +0100, SF Markus Elfring wrote:
> >> Do you find the Linux allocation failure report insufficient in this case?
> > 
> > Leave those pr_ messages alone, please,
> 
> Have you got special software development concerns?
> 
> 
> > unless they are really causing some sort of issue (which?).
> 
> Can the code be redundant here?
> 
> 
> > Doing it just for "compliance" with a doc isn't nearly good enough reason.
> 
> Do you give only a low value to coding style guidelines in this use case?

Hi Markus,

Thanks for submitting the patch. I understand it can be frustrating to
encounter different policies across kernel maintainers. You'll even run
in to this with maintainers of the same subsystem from time to time.
While we try to be as consistent as possible, and to document policy as
we resolve vague areas, this is unfortunately still part of kernel
development.

I'm supportive of cleaning up old code in general, and we routinely
apply such patches as these developed with cocci. We have also had them
fail in unexpected ways.

Andy and Henrique raised a few reasons why these patches should not be
accepted:

1. This is init code )so any space savings is short lived)
2. There is no functional fix, and the change is to code which supports
   a lot of unique platforms, most of which we have no way to test. We are
   particularly cautious with drivers such as the thinkpad driver for this
   reason.

So it isn't that we place a low value on coding style guidelines, but
rather we place higher value on not perturbing code we can't fully test
without a demonstrable functional reasons to do so.

Thanks,

-- 
Darren Hart
VMware Open Source Technology Center

Re: platform/x86/thinkpad_acpi: Adjustments for four function implementations

[Darren Hart]

On Sat, Dec 23, 2017 at 08:12:21AM +0100, SF Markus Elfring wrote:
> >> Do you find the Linux allocation failure report insufficient in this case?
> > 
> > Leave those pr_ messages alone, please,
> 
> Have you got special software development concerns?
> 
> 
> > unless they are really causing some sort of issue (which?).
> 
> Can the code be redundant here?
> 
> 
> > Doing it just for "compliance" with a doc isn't nearly good enough reason.
> 
> Do you give only a low value to coding style guidelines in this use case?

Hi Markus,

Thanks for submitting the patch. I understand it can be frustrating to
encounter different policies across kernel maintainers. You'll even run
in to this with maintainers of the same subsystem from time to time.
While we try to be as consistent as possible, and to document policy as
we resolve vague areas, this is unfortunately still part of kernel
development.

I'm supportive of cleaning up old code in general, and we routinely
apply such patches as these developed with cocci. We have also had them
fail in unexpected ways.

Andy and Henrique raised a few reasons why these patches should not be
accepted:

1. This is init code )so any space savings is short lived)
2. There is no functional fix, and the change is to code which supports
   a lot of unique platforms, most of which we have no way to test. We are
   particularly cautious with drivers such as the thinkpad driver for this
   reason.

So it isn't that we place a low value on coding style guidelines, but
rather we place higher value on not perturbing code we can't fully test
without a demonstrable functional reasons to do so.

Thanks,

-- 
Darren Hart
VMware Open Source Technology Center

Re: [RESEND PATCH v2 12/15] ASoC: qcom: qdsp6: Add support to q6asm dai driver

[Bjorn Andersson]

On Thu 14 Dec 09:33 PST 2017, srinivas.kandaga...@linaro.org wrote:

[..]
> +
> +enum stream_state {
> + IDLE = 0,
> + STOPPED,
> + RUNNING,

These are too generic.

> +};
> +
> +struct q6asm_dai_rtd {
> + struct snd_pcm_substream *substream;
> + dma_addr_t phys;
> + unsigned int pcm_size;
> + unsigned int pcm_count;
> + unsigned int pcm_irq_pos;   /* IRQ position */
> + unsigned int periods;
> + uint16_t bits_per_sample;
> + uint16_t source; /* Encoding source bit mask */
> +
> + struct audio_client *audio_client;
> + uint16_t session_id;
> +
> + enum stream_state state;
> + bool set_channel_map;
> + char channel_map[8];

There's a define for this 8

> +};
> +
> +struct q6asm_dai_data {
> + u64 sid;
> +};
> +
> +static struct snd_pcm_hardware q6asm_dai_hardware_playback = {
> + .info = (SNDRV_PCM_INFO_MMAP |
> + SNDRV_PCM_INFO_BLOCK_TRANSFER |
> + SNDRV_PCM_INFO_MMAP_VALID |
> + SNDRV_PCM_INFO_INTERLEAVED |
> + SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME),
> + .formats =  (SNDRV_PCM_FMTBIT_S16_LE |
> + SNDRV_PCM_FMTBIT_S24_LE),
> + .rates =SNDRV_PCM_RATE_8000_192000,
> + .rate_min = 8000,
> + .rate_max = 192000,
> + .channels_min = 1,
> + .channels_max = 8,
> + .buffer_bytes_max = (PLAYBACK_MAX_NUM_PERIODS *
> + PLAYBACK_MAX_PERIOD_SIZE),
> + .period_bytes_min = PLAYBACK_MIN_PERIOD_SIZE,
> + .period_bytes_max = PLAYBACK_MAX_PERIOD_SIZE,
> + .periods_min =  PLAYBACK_MIN_NUM_PERIODS,
> + .periods_max =  PLAYBACK_MAX_NUM_PERIODS,

If you just put the numbers here, instead of using the PLAYBACK_
defines, it's possible to grok the values of this struct without having
to jump to the defines for each one.

> + .fifo_size =0,
> +};
> +
> +/* Conventional and unconventional sample rate supported */
> +static unsigned int supported_sample_rates[] = {
> + 8000, 11025, 12000, 16000, 22050, 24000, 32000, 44100, 48000,
> + 88200, 96000, 176400, 192000
> +};
> +
> +static struct snd_pcm_hw_constraint_list constraints_sample_rates = {

This is unreferenced.

> + .count = ARRAY_SIZE(supported_sample_rates),
> + .list = supported_sample_rates,
> + .mask = 0,
> +};
> +
> +static void event_handler(uint32_t opcode, uint32_t token,
> +   uint32_t *payload, void *priv)
> +{
> + struct q6asm_dai_rtd *prtd = priv;
> + struct snd_pcm_substream *substream = prtd->substream;
> +
> + switch (opcode) {
> + case ASM_CLIENT_EVENT_CMD_RUN_DONE:
> + q6asm_write_nolock(prtd->audio_client,
> +prtd->pcm_count, 0, 0, NO_TIMESTAMP);
> + break;
> + case ASM_CLIENT_EVENT_CMD_EOS_DONE:
> + prtd->state = STOPPED;
> + break;
> + case ASM_CLIENT_EVENT_DATA_WRITE_DONE: {
> + prtd->pcm_irq_pos += prtd->pcm_count;
> + snd_pcm_period_elapsed(substream);
> + if (prtd->state == RUNNING)
> + q6asm_write_nolock(prtd->audio_client,
> +prtd->pcm_count, 0, 0, NO_TIMESTAMP);
> +
> + break;
> + }
> + default:
> + break;
> + }
> +}
> +
> +static int q6asm_dai_prepare(struct snd_pcm_substream *substream)
> +{
> + struct snd_pcm_runtime *runtime = substream->runtime;
> + struct snd_soc_pcm_runtime *soc_prtd = substream->private_data;
> + struct q6asm_dai_rtd *prtd = runtime->private_data;
> + struct q6asm_dai_data *pdata;
> + int ret;
> +
> + pdata = dev_get_drvdata(soc_prtd->platform->dev);
> + if (!pdata)
> + return -EINVAL;
> +
> + if (!prtd || !prtd->audio_client) {
> + pr_err("%s: private data null or audio client freed\n",
> + __func__);
> + return -EINVAL;
> + }
> +
> + prtd->pcm_count = snd_pcm_lib_period_bytes(substream);
> + prtd->pcm_irq_pos = 0;
> + /* rate and channels are sent to audio driver */
> + if (prtd->state) {
> + /* clear the previous setup if any  */
> + q6asm_cmd(prtd->audio_client, CMD_CLOSE);
> + q6asm_unmap_memory_regions(substream->stream,
> +prtd->audio_client);
> + q6routing_dereg_phy_stream(soc_prtd->dai_link->id,
> +  SNDRV_PCM_STREAM_PLAYBACK);
> + }
> +
> + ret = q6asm_map_memory_regions(substream->stream, prtd->audio_client,
> +prtd->phys,
> +(prtd->pcm_size / prtd->periods),
> +prtd->periods);
> +

Re: [RESEND PATCH v2 12/15] ASoC: qcom: qdsp6: Add support to q6asm dai driver

[Bjorn Andersson]

On Thu 14 Dec 09:33 PST 2017, srinivas.kandaga...@linaro.org wrote:

[..]
> +
> +enum stream_state {
> + IDLE = 0,
> + STOPPED,
> + RUNNING,

These are too generic.

> +};
> +
> +struct q6asm_dai_rtd {
> + struct snd_pcm_substream *substream;
> + dma_addr_t phys;
> + unsigned int pcm_size;
> + unsigned int pcm_count;
> + unsigned int pcm_irq_pos;   /* IRQ position */
> + unsigned int periods;
> + uint16_t bits_per_sample;
> + uint16_t source; /* Encoding source bit mask */
> +
> + struct audio_client *audio_client;
> + uint16_t session_id;
> +
> + enum stream_state state;
> + bool set_channel_map;
> + char channel_map[8];

There's a define for this 8

> +};
> +
> +struct q6asm_dai_data {
> + u64 sid;
> +};
> +
> +static struct snd_pcm_hardware q6asm_dai_hardware_playback = {
> + .info = (SNDRV_PCM_INFO_MMAP |
> + SNDRV_PCM_INFO_BLOCK_TRANSFER |
> + SNDRV_PCM_INFO_MMAP_VALID |
> + SNDRV_PCM_INFO_INTERLEAVED |
> + SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME),
> + .formats =  (SNDRV_PCM_FMTBIT_S16_LE |
> + SNDRV_PCM_FMTBIT_S24_LE),
> + .rates =SNDRV_PCM_RATE_8000_192000,
> + .rate_min = 8000,
> + .rate_max = 192000,
> + .channels_min = 1,
> + .channels_max = 8,
> + .buffer_bytes_max = (PLAYBACK_MAX_NUM_PERIODS *
> + PLAYBACK_MAX_PERIOD_SIZE),
> + .period_bytes_min = PLAYBACK_MIN_PERIOD_SIZE,
> + .period_bytes_max = PLAYBACK_MAX_PERIOD_SIZE,
> + .periods_min =  PLAYBACK_MIN_NUM_PERIODS,
> + .periods_max =  PLAYBACK_MAX_NUM_PERIODS,

If you just put the numbers here, instead of using the PLAYBACK_
defines, it's possible to grok the values of this struct without having
to jump to the defines for each one.

> + .fifo_size =0,
> +};
> +
> +/* Conventional and unconventional sample rate supported */
> +static unsigned int supported_sample_rates[] = {
> + 8000, 11025, 12000, 16000, 22050, 24000, 32000, 44100, 48000,
> + 88200, 96000, 176400, 192000
> +};
> +
> +static struct snd_pcm_hw_constraint_list constraints_sample_rates = {

This is unreferenced.

> + .count = ARRAY_SIZE(supported_sample_rates),
> + .list = supported_sample_rates,
> + .mask = 0,
> +};
> +
> +static void event_handler(uint32_t opcode, uint32_t token,
> +   uint32_t *payload, void *priv)
> +{
> + struct q6asm_dai_rtd *prtd = priv;
> + struct snd_pcm_substream *substream = prtd->substream;
> +
> + switch (opcode) {
> + case ASM_CLIENT_EVENT_CMD_RUN_DONE:
> + q6asm_write_nolock(prtd->audio_client,
> +prtd->pcm_count, 0, 0, NO_TIMESTAMP);
> + break;
> + case ASM_CLIENT_EVENT_CMD_EOS_DONE:
> + prtd->state = STOPPED;
> + break;
> + case ASM_CLIENT_EVENT_DATA_WRITE_DONE: {
> + prtd->pcm_irq_pos += prtd->pcm_count;
> + snd_pcm_period_elapsed(substream);
> + if (prtd->state == RUNNING)
> + q6asm_write_nolock(prtd->audio_client,
> +prtd->pcm_count, 0, 0, NO_TIMESTAMP);
> +
> + break;
> + }
> + default:
> + break;
> + }
> +}
> +
> +static int q6asm_dai_prepare(struct snd_pcm_substream *substream)
> +{
> + struct snd_pcm_runtime *runtime = substream->runtime;
> + struct snd_soc_pcm_runtime *soc_prtd = substream->private_data;
> + struct q6asm_dai_rtd *prtd = runtime->private_data;
> + struct q6asm_dai_data *pdata;
> + int ret;
> +
> + pdata = dev_get_drvdata(soc_prtd->platform->dev);
> + if (!pdata)
> + return -EINVAL;
> +
> + if (!prtd || !prtd->audio_client) {
> + pr_err("%s: private data null or audio client freed\n",
> + __func__);
> + return -EINVAL;
> + }
> +
> + prtd->pcm_count = snd_pcm_lib_period_bytes(substream);
> + prtd->pcm_irq_pos = 0;
> + /* rate and channels are sent to audio driver */
> + if (prtd->state) {
> + /* clear the previous setup if any  */
> + q6asm_cmd(prtd->audio_client, CMD_CLOSE);
> + q6asm_unmap_memory_regions(substream->stream,
> +prtd->audio_client);
> + q6routing_dereg_phy_stream(soc_prtd->dai_link->id,
> +  SNDRV_PCM_STREAM_PLAYBACK);
> + }
> +
> + ret = q6asm_map_memory_regions(substream->stream, prtd->audio_client,
> +prtd->phys,
> +(prtd->pcm_size / prtd->periods),
> +prtd->periods);
> +

Re: [PATCH v3 0/3] Support Perf Extension on AMD KVM guests

[Natarajan, Janakarajan]

On 12/8/2017 4:39 PM, Janakarajan Natarajan wrote:

This patchset adds support for Perf Extension on AMD KVM guests.

When perf runs on a guest with family = 15h || 17h, the MSRs that are
accessed, when the Perf Extension flag is made available, differ from
the existing K7 MSRs. The accesses are to the AMD Core Performance
Extension counters which provide 2 extra counters and new MSRs for both
the event select and counter registers.

Since the new event select and counter MSRs are interleaved and K7 MSRs
are contiguous, the logic to map them to the gp_counters[] is changed.

This patchset has been tested with Family 17h and Opteron G1 guests.

v1->v2:
* Rearranged MSR #defines based on Boris's suggestion.

v2->v3:
* Changed the logic of mapping MSR to gp_counters[] index based on
   Boris's feedback.
* Removed use of family checks based on Radim's feedback.
* Removed KVM bugfix patch since it is already applied.

Janakarajan Natarajan (3):
   x86/msr: Add AMD Core Perf Extension MSRs
   x86/kvm: Add support for AMD Core Perf Extension in guest
   x86/kvm: Expose AMD Core Perf Extension flag to guests


Are there any concerns regarding this patchset?



  arch/x86/include/asm/msr-index.h |  14 
  arch/x86/kvm/cpuid.c |   8 ++-
  arch/x86/kvm/pmu_amd.c   | 140 +++
  arch/x86/kvm/x86.c   |   1 +
  4 files changed, 148 insertions(+), 15 deletions(-)

Re: [PATCH v3 0/3] Support Perf Extension on AMD KVM guests

[Natarajan, Janakarajan]

On 12/8/2017 4:39 PM, Janakarajan Natarajan wrote:

This patchset adds support for Perf Extension on AMD KVM guests.

When perf runs on a guest with family = 15h || 17h, the MSRs that are
accessed, when the Perf Extension flag is made available, differ from
the existing K7 MSRs. The accesses are to the AMD Core Performance
Extension counters which provide 2 extra counters and new MSRs for both
the event select and counter registers.

Since the new event select and counter MSRs are interleaved and K7 MSRs
are contiguous, the logic to map them to the gp_counters[] is changed.

This patchset has been tested with Family 17h and Opteron G1 guests.

v1->v2:
* Rearranged MSR #defines based on Boris's suggestion.

v2->v3:
* Changed the logic of mapping MSR to gp_counters[] index based on
   Boris's feedback.
* Removed use of family checks based on Radim's feedback.
* Removed KVM bugfix patch since it is already applied.

Janakarajan Natarajan (3):
   x86/msr: Add AMD Core Perf Extension MSRs
   x86/kvm: Add support for AMD Core Perf Extension in guest
   x86/kvm: Expose AMD Core Perf Extension flag to guests


Are there any concerns regarding this patchset?



  arch/x86/include/asm/msr-index.h |  14 
  arch/x86/kvm/cpuid.c |   8 ++-
  arch/x86/kvm/pmu_amd.c   | 140 +++
  arch/x86/kvm/x86.c   |   1 +
  4 files changed, 148 insertions(+), 15 deletions(-)

Re: [PATCH v7 02/10] module: allow symbol exports to be disabled

[Ard Biesheuvel]

On 2 January 2018 at 23:47, Nicolas Pitre  wrote:
> On Tue, 2 Jan 2018, Ard Biesheuvel wrote:
>
>> To allow existing C code to be incorporated into the decompressor or
>> the UEFI stub, introduce a CPP macro that turns all EXPORT_SYMBOL_xxx
>> declarations into nops, and #define it in places where such exports
>> are undesirable. Note that this gets rid of a rather dodgy redefine
>> of linux/export.h's header guard.
> [...]
>
>> --- a/include/linux/export.h
>> +++ b/include/linux/export.h
>> @@ -83,6 +83,15 @@ extern struct module __this_module;
>>   */
>>  #define __EXPORT_SYMBOL(sym, sec)=== __KSYM_##sym ===
>>
>> +#elif defined(__DISABLE_EXPORTS)
>> +
>> +/*
>> + * Allow symbol exports to be disabled completely so that C code may
>> + * be reused in other execution contexts such as the UEFI stub or the
>> + * decompressor.
>> + */
>> +#define __EXPORT_SYMBOL(sym, sec)
>> +
>
> I think you should rather put this first thing in the #if sequence so to
> override the defined(__KSYM_DEPS__) case too.  No need to create build
> dependencies for module symbols that you're going to stub out
> afterwards anyway.
>

I wasn't sure, so thanks for clearing that up.

Re: [PATCH v7 02/10] module: allow symbol exports to be disabled

[Ard Biesheuvel]

On 2 January 2018 at 23:47, Nicolas Pitre  wrote:
> On Tue, 2 Jan 2018, Ard Biesheuvel wrote:
>
>> To allow existing C code to be incorporated into the decompressor or
>> the UEFI stub, introduce a CPP macro that turns all EXPORT_SYMBOL_xxx
>> declarations into nops, and #define it in places where such exports
>> are undesirable. Note that this gets rid of a rather dodgy redefine
>> of linux/export.h's header guard.
> [...]
>
>> --- a/include/linux/export.h
>> +++ b/include/linux/export.h
>> @@ -83,6 +83,15 @@ extern struct module __this_module;
>>   */
>>  #define __EXPORT_SYMBOL(sym, sec)=== __KSYM_##sym ===
>>
>> +#elif defined(__DISABLE_EXPORTS)
>> +
>> +/*
>> + * Allow symbol exports to be disabled completely so that C code may
>> + * be reused in other execution contexts such as the UEFI stub or the
>> + * decompressor.
>> + */
>> +#define __EXPORT_SYMBOL(sym, sec)
>> +
>
> I think you should rather put this first thing in the #if sequence so to
> override the defined(__KSYM_DEPS__) case too.  No need to create build
> dependencies for module symbols that you're going to stub out
> afterwards anyway.
>

I wasn't sure, so thanks for clearing that up.

Re: [PATCH v7 02/10] module: allow symbol exports to be disabled

[Nicolas Pitre]

On Tue, 2 Jan 2018, Ard Biesheuvel wrote:

> To allow existing C code to be incorporated into the decompressor or
> the UEFI stub, introduce a CPP macro that turns all EXPORT_SYMBOL_xxx
> declarations into nops, and #define it in places where such exports
> are undesirable. Note that this gets rid of a rather dodgy redefine
> of linux/export.h's header guard.
[...]

> --- a/include/linux/export.h
> +++ b/include/linux/export.h
> @@ -83,6 +83,15 @@ extern struct module __this_module;
>   */
>  #define __EXPORT_SYMBOL(sym, sec)=== __KSYM_##sym ===
>  
> +#elif defined(__DISABLE_EXPORTS)
> +
> +/*
> + * Allow symbol exports to be disabled completely so that C code may
> + * be reused in other execution contexts such as the UEFI stub or the
> + * decompressor.
> + */
> +#define __EXPORT_SYMBOL(sym, sec)
> +

I think you should rather put this first thing in the #if sequence so to 
override the defined(__KSYM_DEPS__) case too.  No need to create build 
dependencies for module symbols that you're going to stub out 
afterwards anyway.


Nicolas

Re: [PATCH v7 02/10] module: allow symbol exports to be disabled

[Nicolas Pitre]

On Tue, 2 Jan 2018, Ard Biesheuvel wrote:

> To allow existing C code to be incorporated into the decompressor or
> the UEFI stub, introduce a CPP macro that turns all EXPORT_SYMBOL_xxx
> declarations into nops, and #define it in places where such exports
> are undesirable. Note that this gets rid of a rather dodgy redefine
> of linux/export.h's header guard.
[...]

> --- a/include/linux/export.h
> +++ b/include/linux/export.h
> @@ -83,6 +83,15 @@ extern struct module __this_module;
>   */
>  #define __EXPORT_SYMBOL(sym, sec)=== __KSYM_##sym ===
>  
> +#elif defined(__DISABLE_EXPORTS)
> +
> +/*
> + * Allow symbol exports to be disabled completely so that C code may
> + * be reused in other execution contexts such as the UEFI stub or the
> + * decompressor.
> + */
> +#define __EXPORT_SYMBOL(sym, sec)
> +

I think you should rather put this first thing in the #if sequence so to 
override the defined(__KSYM_DEPS__) case too.  No need to create build 
dependencies for module symbols that you're going to stub out 
afterwards anyway.


Nicolas

Re: [PATCH v2] platform/x86: silead_dmi: Add entry for the Teclast X98 Plus II

[Darren Hart]

On Tue, Jan 02, 2018 at 07:39:27PM +0100, Paul Cercueil wrote:
> Add touchscreen platform data for the Teclast X98 Plus II tablet.
> 
> Signed-off-by: Paul Cercueil 
> Acked-by: Hans de Goede 
> ---
>  drivers/platform/x86/silead_dmi.c | 24 
>  1 file changed, 24 insertions(+)
> 
>  v2: Rebased on top of 
> http://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git/shortlog/refs/heads/review-andy

Generally "testing" is the branch you want to base on if linus/master
doesn't work as the review-* branches *will* rebase frequently.
Exceptions exist of course, and this patch is just fine - just for
future reference.

Andy pushed his changes to testing already, so this is no longer
dependent on his review queue. I have applied to review-dvhart, will go
to testing shortly.

Thank you Paul.

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH v2] platform/x86: silead_dmi: Add entry for the Teclast X98 Plus II

[Darren Hart]

On Tue, Jan 02, 2018 at 07:39:27PM +0100, Paul Cercueil wrote:
> Add touchscreen platform data for the Teclast X98 Plus II tablet.
> 
> Signed-off-by: Paul Cercueil 
> Acked-by: Hans de Goede 
> ---
>  drivers/platform/x86/silead_dmi.c | 24 
>  1 file changed, 24 insertions(+)
> 
>  v2: Rebased on top of 
> http://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git/shortlog/refs/heads/review-andy

Generally "testing" is the branch you want to base on if linus/master
doesn't work as the review-* branches *will* rebase frequently.
Exceptions exist of course, and this patch is just fine - just for
future reference.

Andy pushed his changes to testing already, so this is no longer
dependent on his review queue. I have applied to review-dvhart, will go
to testing shortly.

Thank you Paul.

-- 
Darren Hart
VMware Open Source Technology Center

Re: [GIT PULL] cpupower update for 4.16-rc1

[Rafael J. Wysocki]

On Wed, Jan 3, 2018 at 12:13 AM, Shuah Khan  wrote:
> Hi Rafael,

Hi,

> Please pull the cpupower update for 4.16-rc1.

Pulled, thanks!

Re: [GIT PULL] cpupower update for 4.16-rc1

[Rafael J. Wysocki]

On Wed, Jan 3, 2018 at 12:13 AM, Shuah Khan  wrote:
> Hi Rafael,

Hi,

> Please pull the cpupower update for 4.16-rc1.

Pulled, thanks!

[no subject]

[Mr Sheng Li Hung]

-- 
I am Mr.Sheng Li Hung, from china I got your information while search for
a reliable person, I have a very profitable business proposition for you
and i can assure you that you will not regret been part of this mutual
beneficial transaction after completion. Kindly get back to me for more
details on this email id: shengl...@hotmail.com

Thanks
Mr Sheng Li Hung

[no subject]

[Mr Sheng Li Hung]

-- 
I am Mr.Sheng Li Hung, from china I got your information while search for
a reliable person, I have a very profitable business proposition for you
and i can assure you that you will not regret been part of this mutual
beneficial transaction after completion. Kindly get back to me for more
details on this email id: shengl...@hotmail.com

Thanks
Mr Sheng Li Hung

Re: [PATCH] USB: usbip: remove useless call in usbip_recv

[Shuah Khan]

On 01/02/2018 07:02 AM, Gustavo A. R. Silva wrote:
> Calling msg_data_left() is only useful for its return value,
> which in this particular case is ignored.
> 
> Fix this by removing such call.
> 
> Addresses-Coverity-ID: 1427080
> Fixes: 90120d15f4c3 ("usbip: prevent leaking socket pointer address in 
> messages")
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/usb/usbip/usbip_common.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/usb/usbip/usbip_common.c 
> b/drivers/usb/usbip/usbip_common.c
> index 7b219d9..b5af6fc 100644
> --- a/drivers/usb/usbip/usbip_common.c
> +++ b/drivers/usb/usbip/usbip_common.c
> @@ -325,7 +325,6 @@ int usbip_recv(struct socket *sock, void *buf, int size)
>   usbip_dbg_xmit("enter\n");
>  
>   do {
> - msg_data_left();
>   sock->sk->sk_allocation = GFP_NOIO;
>  
>   result = sock_recvmsg(sock, , MSG_WAITALL);
> 

Thanks for the patch. Looks good to me.

Acked-by: Shuah Khan 

Greg, please pick this patch up.

thanks,
-- Shuah

Re: [PATCH] USB: usbip: remove useless call in usbip_recv

[Shuah Khan]

On 01/02/2018 07:02 AM, Gustavo A. R. Silva wrote:
> Calling msg_data_left() is only useful for its return value,
> which in this particular case is ignored.
> 
> Fix this by removing such call.
> 
> Addresses-Coverity-ID: 1427080
> Fixes: 90120d15f4c3 ("usbip: prevent leaking socket pointer address in 
> messages")
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/usb/usbip/usbip_common.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/usb/usbip/usbip_common.c 
> b/drivers/usb/usbip/usbip_common.c
> index 7b219d9..b5af6fc 100644
> --- a/drivers/usb/usbip/usbip_common.c
> +++ b/drivers/usb/usbip/usbip_common.c
> @@ -325,7 +325,6 @@ int usbip_recv(struct socket *sock, void *buf, int size)
>   usbip_dbg_xmit("enter\n");
>  
>   do {
> - msg_data_left();
>   sock->sk->sk_allocation = GFP_NOIO;
>  
>   result = sock_recvmsg(sock, , MSG_WAITALL);
> 

Thanks for the patch. Looks good to me.

Acked-by: Shuah Khan 

Greg, please pick this patch up.

thanks,
-- Shuah

Re: [PATCH v1 00/15] ASoC: fsl_ssi: Clean up - program flow level

[Caleb Crome]

On Tue, Dec 19, 2017 at 9:00 AM, Nicolin Chen  wrote:
>
> ==Background==
> The fsl_ssi driver was designed for PPC originally and then it has
> been updated to support different modes for i.MX Series, including
> SDMA, I2S Master mode, AC97 and older i.MXs with FIQ, by different
> contributors for different use cases in different coding styles.
>
> Additionally, in order to fix/work-around hardware bugs and design
> flaws, the driver made a lot of compromise so now its program flow
> looks very complicated and it's getting hard to maintain or update.
>
> So I am going to clean up the driver on both coding style level and
> program flow level.
>
> ==Introduction==
> This series of patches is the second set to clean up fsl_ssi driver
> in the program flow level. Any patch here may impact a fundamental
> test case like playback or record.
>
> ==Verification==
> This series of patches require fully tested. I have done such tests
> on i.MX6SoloX with WM8962 using imx_v6_v7_defconfig as:
>  - Playback via I2S Master and Slave mode
>  - Record via I2S Master and Slave mode
>  - Simultaneous playback and record via I2S Master and Slave mode
>  - Background playback with foreground record (starting at different
>time) via I2S Master and Slave mode
>  - Background record with foreground playback (starting at different
>time) via I2S Master and Slave mode
>  * All tests above by hacking offline_config to true in imx51.
>
> Example of uncovered tests: TDM, AC97, PowerPC and FIQ.
>
> Nicolin Chen (15):
>   ASoC: fsl_ssi: Clean up set_dai_tdm_slot()
>   ASoC: fsl_ssi: Maintain a mask of active streams
>   ASoC: fsl_ssi: Rename fsl_ssi_disable_val macro
>   ASoC: fsl_ssi: Clear FIFO directly in fsl_ssi_config()
>   ASoC: fsl_ssi: Clean up helper functions of trigger()
>   ASoC: fsl_ssi: Add DAIFMT define for AC97
>   ASoC: fsl_ssi: Clean up fsl_ssi_setup_regvals()
>   ASoC: fsl_ssi: Set xFEN0 and xFEN1 together
>   ASoC: fsl_ssi: Use snd_soc_init_dma_data instead
>   ASoC: fsl_ssi: Move one-time configurations to dai_probe()
>   ASoC: fsl_ssi: Setup AC97 in dai_probe()
>   ASoC: fsl_ssi: Clean up _fsl_ssi_set_dai_fmt()
>   ASoC: fsl_ssi: Remove cpu_dai_drv from fsl_ssi structure
>   ASoC: fsl_ssi: Move DT related code to a separate probe()
>   ASoC: fsl_ssi: Use ssi->streams instead of reading register
>
>  sound/soc/fsl/fsl_ssi.c | 710 
> 
>  1 file changed, 348 insertions(+), 362 deletions(-)
>
> --
> 2.7.4
>

tested this patch set on MX6 SSI against broonie for-next (4.15-rc5),
no problems.
Do I send a separate Tested-by for each patch, or just the 00/15 one?



Tested-by: Caleb Crome 

Re: [PATCH v1 00/15] ASoC: fsl_ssi: Clean up - program flow level

[Caleb Crome]

On Tue, Dec 19, 2017 at 9:00 AM, Nicolin Chen  wrote:
>
> ==Background==
> The fsl_ssi driver was designed for PPC originally and then it has
> been updated to support different modes for i.MX Series, including
> SDMA, I2S Master mode, AC97 and older i.MXs with FIQ, by different
> contributors for different use cases in different coding styles.
>
> Additionally, in order to fix/work-around hardware bugs and design
> flaws, the driver made a lot of compromise so now its program flow
> looks very complicated and it's getting hard to maintain or update.
>
> So I am going to clean up the driver on both coding style level and
> program flow level.
>
> ==Introduction==
> This series of patches is the second set to clean up fsl_ssi driver
> in the program flow level. Any patch here may impact a fundamental
> test case like playback or record.
>
> ==Verification==
> This series of patches require fully tested. I have done such tests
> on i.MX6SoloX with WM8962 using imx_v6_v7_defconfig as:
>  - Playback via I2S Master and Slave mode
>  - Record via I2S Master and Slave mode
>  - Simultaneous playback and record via I2S Master and Slave mode
>  - Background playback with foreground record (starting at different
>time) via I2S Master and Slave mode
>  - Background record with foreground playback (starting at different
>time) via I2S Master and Slave mode
>  * All tests above by hacking offline_config to true in imx51.
>
> Example of uncovered tests: TDM, AC97, PowerPC and FIQ.
>
> Nicolin Chen (15):
>   ASoC: fsl_ssi: Clean up set_dai_tdm_slot()
>   ASoC: fsl_ssi: Maintain a mask of active streams
>   ASoC: fsl_ssi: Rename fsl_ssi_disable_val macro
>   ASoC: fsl_ssi: Clear FIFO directly in fsl_ssi_config()
>   ASoC: fsl_ssi: Clean up helper functions of trigger()
>   ASoC: fsl_ssi: Add DAIFMT define for AC97
>   ASoC: fsl_ssi: Clean up fsl_ssi_setup_regvals()
>   ASoC: fsl_ssi: Set xFEN0 and xFEN1 together
>   ASoC: fsl_ssi: Use snd_soc_init_dma_data instead
>   ASoC: fsl_ssi: Move one-time configurations to dai_probe()
>   ASoC: fsl_ssi: Setup AC97 in dai_probe()
>   ASoC: fsl_ssi: Clean up _fsl_ssi_set_dai_fmt()
>   ASoC: fsl_ssi: Remove cpu_dai_drv from fsl_ssi structure
>   ASoC: fsl_ssi: Move DT related code to a separate probe()
>   ASoC: fsl_ssi: Use ssi->streams instead of reading register
>
>  sound/soc/fsl/fsl_ssi.c | 710 
> 
>  1 file changed, 348 insertions(+), 362 deletions(-)
>
> --
> 2.7.4
>

tested this patch set on MX6 SSI against broonie for-next (4.15-rc5),
no problems.
Do I send a separate Tested-by for each patch, or just the 00/15 one?



Tested-by: Caleb Crome 

Re: [PATCH 01/33] clk_ops: change round_rate() to return unsigned long

[Stephen Boyd]

On 01/02, Bryan O'Donoghue wrote:
> On 02/01/18 19:01, Stephen Boyd wrote:
> >On 12/31, Bryan O'Donoghue wrote:
> >>On 30/12/17 16:36, Mikko Perttunen wrote:
> >>>FWIW, we had this problem some years ago with the Tegra CPU clock
> >>>- then it was determined that a simpler solution was to have the
> >>>determine_rate callback support unsigned long rates - so clock
> >>>drivers that need to return rates higher than 2^31 can instead
> >>>implement the determine_rate callback. That is what's currently
> >>>implemented.
> >>>
> >>>Mikko
> >>
> >>Granted we could work around it but, having both zero and less than
> >>zero indicate error means you can't support larger than LONG_MAX
> >>which is I think worth fixing.
> >>
> >
> >Ok. But can you implement the determine_rate op instead of the
> >round_rate op for your clk?
> 
> Don't know .

Please try.

> 
> >It's not a work-around, it's the
> >preferred solution. That would allow rates larger than 2^31 for
> >the clk without pushing through a change to all the drivers to
> >express zero as "error" and non-zero as the rounded rate.
> >
> >I'm not entirely opposed to this approach, because we probably
> >don't care to pass the particular error value from a clk provider
> >to a clk consumer about what the error is.
> 
> Which was my thought. The return value of clk_ops->round_rate()
> appears not to get pushed up the stack, which is what the last patch
> in this series deals with.
> 
> [PATCH 33/33] clk: change handling of round_rate() such that only
> zero is an error

Hmm? clk_core_determine_round_nolock() returns 'rate' if rate < 0
from the round_rate op. clk_core_round_rate_nolock() returns that
value to clk_round_rate() which returns it to the consumer.

> 
> >It's actually what we
> >proposed as the solution for clk_round_rate() to return values
> >larger than LONG_MAX to consumers. But doing that consumer API
> >change or this provider side change is going to require us to
> >evaluate all the consumers of these clks to make sure they don't
> >check for some error value that's less than zero. This series
> >does half the work,
> 
> Do you mean users of clk_rounda_rate() ? I have a set of patches for
> that but wanted to separate that from clk_ops->round_rate() so as
> not to send ~70 patches out to LKML at once - even if they are in
> two blocks.

Ok. What have you done to the consumers of clk_round_rate()?
Made them treat 0 as an error instead of less than zero? The
documentation in clk.h needs to be updated. See this patch from
Paul Wamsley[1] for one proposed patch that went nowhere. Also
include Russell King please. It was also proposed to change the
function signature of clk_round_rate() to return unsigned long,
but that didn't go anywhere either.

> 
> If so, I can publish that set too for reference.
> 
> AFAICT on clk_ops->round_rate the last patch #33 ought to cover the
> usage of the return value of clk_ops->round_rate().
> 
> Have I missed something ?

Hopefully not!

> 
> >by changing the provider side, while ignoring
> >the consumer side and any potential fallout of the less than zero
> >to zero return value change.
> >
> 
> Can you look at #33 ? I'm not sure if you saw that one.
> 

Yeah I looked at it. From what I can tell it makes
clk_round_rate() return 0 now instead of whatever negative value
the clk_ops::round_rate function returns.

[1] https://lkml.kernel.org/r/alpine.DEB.2.02.1311251603310.23090@tamien

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

Re: [PATCH 01/33] clk_ops: change round_rate() to return unsigned long

[Stephen Boyd]

On 01/02, Bryan O'Donoghue wrote:
> On 02/01/18 19:01, Stephen Boyd wrote:
> >On 12/31, Bryan O'Donoghue wrote:
> >>On 30/12/17 16:36, Mikko Perttunen wrote:
> >>>FWIW, we had this problem some years ago with the Tegra CPU clock
> >>>- then it was determined that a simpler solution was to have the
> >>>determine_rate callback support unsigned long rates - so clock
> >>>drivers that need to return rates higher than 2^31 can instead
> >>>implement the determine_rate callback. That is what's currently
> >>>implemented.
> >>>
> >>>Mikko
> >>
> >>Granted we could work around it but, having both zero and less than
> >>zero indicate error means you can't support larger than LONG_MAX
> >>which is I think worth fixing.
> >>
> >
> >Ok. But can you implement the determine_rate op instead of the
> >round_rate op for your clk?
> 
> Don't know .

Please try.

> 
> >It's not a work-around, it's the
> >preferred solution. That would allow rates larger than 2^31 for
> >the clk without pushing through a change to all the drivers to
> >express zero as "error" and non-zero as the rounded rate.
> >
> >I'm not entirely opposed to this approach, because we probably
> >don't care to pass the particular error value from a clk provider
> >to a clk consumer about what the error is.
> 
> Which was my thought. The return value of clk_ops->round_rate()
> appears not to get pushed up the stack, which is what the last patch
> in this series deals with.
> 
> [PATCH 33/33] clk: change handling of round_rate() such that only
> zero is an error

Hmm? clk_core_determine_round_nolock() returns 'rate' if rate < 0
from the round_rate op. clk_core_round_rate_nolock() returns that
value to clk_round_rate() which returns it to the consumer.

> 
> >It's actually what we
> >proposed as the solution for clk_round_rate() to return values
> >larger than LONG_MAX to consumers. But doing that consumer API
> >change or this provider side change is going to require us to
> >evaluate all the consumers of these clks to make sure they don't
> >check for some error value that's less than zero. This series
> >does half the work,
> 
> Do you mean users of clk_rounda_rate() ? I have a set of patches for
> that but wanted to separate that from clk_ops->round_rate() so as
> not to send ~70 patches out to LKML at once - even if they are in
> two blocks.

Ok. What have you done to the consumers of clk_round_rate()?
Made them treat 0 as an error instead of less than zero? The
documentation in clk.h needs to be updated. See this patch from
Paul Wamsley[1] for one proposed patch that went nowhere. Also
include Russell King please. It was also proposed to change the
function signature of clk_round_rate() to return unsigned long,
but that didn't go anywhere either.

> 
> If so, I can publish that set too for reference.
> 
> AFAICT on clk_ops->round_rate the last patch #33 ought to cover the
> usage of the return value of clk_ops->round_rate().
> 
> Have I missed something ?

Hopefully not!

> 
> >by changing the provider side, while ignoring
> >the consumer side and any potential fallout of the less than zero
> >to zero return value change.
> >
> 
> Can you look at #33 ? I'm not sure if you saw that one.
> 

Yeah I looked at it. From what I can tell it makes
clk_round_rate() return 0 now instead of whatever negative value
the clk_ops::round_rate function returns.

[1] https://lkml.kernel.org/r/alpine.DEB.2.02.1311251603310.23090@tamien

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

Re: [RESEND PATCH v2 11/15] ASoC: qcom: qdsp6: Add support to q6afe dai driver

[Bjorn Andersson]

On Thu 14 Dec 09:33 PST 2017, srinivas.kandaga...@linaro.org wrote:

> From: Srinivas Kandagatla 
> 
> This patch adds support to q6afe backend dais driver.
> 

Isn't the list of backend DAIs platform-dependent?

[..]
> +static const struct snd_soc_dapm_widget hdmi_dapm_widgets[] = {
> + SND_SOC_DAPM_AIF_OUT("HDMI", "HDMI Playback", 0, 0, 0, 0),
> + SND_SOC_DAPM_OUTPUT("HDMI-RX"),
> +};
> +
> +static const struct snd_soc_component_driver msm_dai_hdmi_q6_component = {

How will this look beyond HDMI? I'm having issues mapping this to
downstream.

> + .name   = "msm-dai-q6-hdmi",
> + .dapm_widgets = hdmi_dapm_widgets,
> + .num_dapm_widgets = ARRAY_SIZE(hdmi_dapm_widgets),
> + .controls = hdmi_config_controls,
> + .num_controls = ARRAY_SIZE(hdmi_config_controls),
> + .dapm_routes = hdmi_dapm_routes,
> + .num_dapm_routes = ARRAY_SIZE(hdmi_dapm_routes),
> +};
> +

Regards,
Bjorn

Re: [RESEND PATCH v2 11/15] ASoC: qcom: qdsp6: Add support to q6afe dai driver

[Bjorn Andersson]

On Thu 14 Dec 09:33 PST 2017, srinivas.kandaga...@linaro.org wrote:

> From: Srinivas Kandagatla 
> 
> This patch adds support to q6afe backend dais driver.
> 

Isn't the list of backend DAIs platform-dependent?

[..]
> +static const struct snd_soc_dapm_widget hdmi_dapm_widgets[] = {
> + SND_SOC_DAPM_AIF_OUT("HDMI", "HDMI Playback", 0, 0, 0, 0),
> + SND_SOC_DAPM_OUTPUT("HDMI-RX"),
> +};
> +
> +static const struct snd_soc_component_driver msm_dai_hdmi_q6_component = {

How will this look beyond HDMI? I'm having issues mapping this to
downstream.

> + .name   = "msm-dai-q6-hdmi",
> + .dapm_widgets = hdmi_dapm_widgets,
> + .num_dapm_widgets = ARRAY_SIZE(hdmi_dapm_widgets),
> + .controls = hdmi_config_controls,
> + .num_controls = ARRAY_SIZE(hdmi_config_controls),
> + .dapm_routes = hdmi_dapm_routes,
> + .num_dapm_routes = ARRAY_SIZE(hdmi_dapm_routes),
> +};
> +

Regards,
Bjorn

Re: [PATCH] sched/isolation: Make CPU_ISOLATION depend on SMP or COMPILE_TEST

[Nicolas Pitre]

On Tue, 2 Jan 2018, Geert Uytterhoeven wrote:

> On uniprocessor systems, critical and non-critical tasks cannot be
> isolated, as there is only a single CPU core.  Hence enabling CPU
> isolation by default on such systems does not make much sense.
> 
> Instead of changing the default for !SMP, fix this by making the feature
> depend on SMP, with an override for compile-testing.  Note that its sole
> selector (NO_HZ_FULL) already depends on SMP.
> 
> This decreases kernel size for a default uniprocessor kernel by ca. 1
> KiB.
> 
> Fixes: 2c43838c99d9d23f ("sched/isolation: Enable CONFIG_CPU_ISOLATION=y by 
> default")
> Signed-off-by: Geert Uytterhoeven 

Acked-by: Nicolas Pitre 


> ---
>  init/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index 690a381adee0d164..c1221332e128c700 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -461,6 +461,7 @@ endmenu # "CPU/Task time and stats accounting"
>  
>  config CPU_ISOLATION
>   bool "CPU isolation"
> + depends on SMP || COMPILE_TEST
>   default y
>   help
> Make sure that CPUs running critical tasks are not disturbed by
> -- 
> 2.7.4
> 
> 

Re: [PATCH] sched/isolation: Make CPU_ISOLATION depend on SMP or COMPILE_TEST

[Nicolas Pitre]

On Tue, 2 Jan 2018, Geert Uytterhoeven wrote:

> On uniprocessor systems, critical and non-critical tasks cannot be
> isolated, as there is only a single CPU core.  Hence enabling CPU
> isolation by default on such systems does not make much sense.
> 
> Instead of changing the default for !SMP, fix this by making the feature
> depend on SMP, with an override for compile-testing.  Note that its sole
> selector (NO_HZ_FULL) already depends on SMP.
> 
> This decreases kernel size for a default uniprocessor kernel by ca. 1
> KiB.
> 
> Fixes: 2c43838c99d9d23f ("sched/isolation: Enable CONFIG_CPU_ISOLATION=y by 
> default")
> Signed-off-by: Geert Uytterhoeven 

Acked-by: Nicolas Pitre 


> ---
>  init/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index 690a381adee0d164..c1221332e128c700 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -461,6 +461,7 @@ endmenu # "CPU/Task time and stats accounting"
>  
>  config CPU_ISOLATION
>   bool "CPU isolation"
> + depends on SMP || COMPILE_TEST
>   default y
>   help
> Make sure that CPUs running critical tasks are not disturbed by
> -- 
> 2.7.4
> 
> 

Re: v3.18.86 build: 0 failures 1 warnings (v3.18.86)

[Arnd Bergmann]

On Wed, Dec 6, 2017 at 1:18 AM, Build bot for Mark Brown
 wrote:

> ---
> x86_64-defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches
>
> Warnings:
> ../include/linux/ftrace.h:632:36: warning: calling 
> '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
> ../include/linux/ftrace.h:632:36: warning: calling 
> '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
> ---

This warning keeps coming up in 3.18 and 4.1 builds, which lack a backport of

ef6000b4c670 ("Disable the __builtin_return_address() warning globally
after all")

The other build bots use different gcc versions that don't report the
warning here,
so only Mark's bot triggers it. The warning in this file is harmless,
and the patch
only turns off the warning flag.

   Arnd

Re: v3.18.86 build: 0 failures 1 warnings (v3.18.86)

[Arnd Bergmann]

On Wed, Dec 6, 2017 at 1:18 AM, Build bot for Mark Brown
 wrote:

> ---
> x86_64-defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches
>
> Warnings:
> ../include/linux/ftrace.h:632:36: warning: calling 
> '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
> ../include/linux/ftrace.h:632:36: warning: calling 
> '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
> ---

This warning keeps coming up in 3.18 and 4.1 builds, which lack a backport of

ef6000b4c670 ("Disable the __builtin_return_address() warning globally
after all")

The other build bots use different gcc versions that don't report the
warning here,
so only Mark's bot triggers it. The warning in this file is harmless,
and the patch
only turns off the warning flag.

   Arnd

[PATCH] exec: Weaken dumpability for secureexec

[Kees Cook]

This is a logical revert of:

commit e37fdb785a5f ("exec: Use secureexec for setting dumpability")

This weakens dumpability back to checking only for uid/gid changes in
current (which is useless), but userspace depends on dumpability not
being tied to secureexec.

https://bugzilla.redhat.com/show_bug.cgi?id=1528633

Reported-by: Tom Horsley 
Fixes: e37fdb785a5f ("exec: Use secureexec for setting dumpability")
Cc: sta...@vger.kernel.org
Signed-off-by: Kees Cook 
---
 fs/exec.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/fs/exec.c b/fs/exec.c
index 5688b5e1b937..7eb8d21bcab9 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1349,9 +1349,14 @@ void setup_new_exec(struct linux_binprm * bprm)
 
current->sas_ss_sp = current->sas_ss_size = 0;
 
-   /* Figure out dumpability. */
+   /*
+* Figure out dumpability. Note that this checking only of current
+* is wrong, but userspace depends on it. This should be testing
+* bprm->secureexec instead.
+*/
if (bprm->interp_flags & BINPRM_FLAGS_ENFORCE_NONDUMP ||
-   bprm->secureexec)
+   !(uid_eq(current_euid(), current_uid()) &&
+ gid_eq(current_egid(), current_gid(
set_dumpable(current->mm, suid_dumpable);
else
set_dumpable(current->mm, SUID_DUMP_USER);
-- 
2.7.4


-- 
Kees Cook
Pixel Security

[PATCH] exec: Weaken dumpability for secureexec

[Kees Cook]

This is a logical revert of:

commit e37fdb785a5f ("exec: Use secureexec for setting dumpability")

This weakens dumpability back to checking only for uid/gid changes in
current (which is useless), but userspace depends on dumpability not
being tied to secureexec.

https://bugzilla.redhat.com/show_bug.cgi?id=1528633

Reported-by: Tom Horsley 
Fixes: e37fdb785a5f ("exec: Use secureexec for setting dumpability")
Cc: sta...@vger.kernel.org
Signed-off-by: Kees Cook 
---
 fs/exec.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/fs/exec.c b/fs/exec.c
index 5688b5e1b937..7eb8d21bcab9 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1349,9 +1349,14 @@ void setup_new_exec(struct linux_binprm * bprm)
 
current->sas_ss_sp = current->sas_ss_size = 0;
 
-   /* Figure out dumpability. */
+   /*
+* Figure out dumpability. Note that this checking only of current
+* is wrong, but userspace depends on it. This should be testing
+* bprm->secureexec instead.
+*/
if (bprm->interp_flags & BINPRM_FLAGS_ENFORCE_NONDUMP ||
-   bprm->secureexec)
+   !(uid_eq(current_euid(), current_uid()) &&
+ gid_eq(current_egid(), current_gid(
set_dumpable(current->mm, suid_dumpable);
else
set_dumpable(current->mm, SUID_DUMP_USER);
-- 
2.7.4


-- 
Kees Cook
Pixel Security

Re: [PATCH] PM / runtime: Rework pm_runtime_force_suspend/resume()

[Rafael J. Wysocki]

On Tue, Jan 2, 2018 at 8:07 PM, Rafael J. Wysocki  wrote:
> On Tuesday, January 2, 2018 2:04:04 PM CET Lukas Wunner wrote:
>> On Tue, Jan 02, 2018 at 12:02:18PM +0100, Rafael J. Wysocki wrote:
>> > On Tue, Jan 2, 2018 at 11:51 AM, Lukas Wunner  wrote:
>> > > On Tue, Jan 02, 2018 at 01:56:28AM +0100, Rafael J. Wysocki wrote:
>> > >> + if (atomic_read(>power.usage_count) <= 1 &&
>> > >> + atomic_read(>power.child_count) == 0)
>> > >> + pm_runtime_set_suspended(dev);
>> > >>
>> > >> - pm_runtime_set_suspended(dev);
>> > >
>> > > The ->runtime_suspend callback *has* been executed at this point.
>> > > If the status is only updated conditionally, it may not reflect
>> > > the device's actual power state correctly.  That doesn't seem to
>> > > be a good idea.
>> >
>> > It doesn't matter, because this is done with runtime PM disabled, isn't it?
>>
>> It might not make a difference for the use case I have in mind, but
>> pm_runtime_status_suspended() will return an incorrect result and is
>> called from 47 files in 4.15-rc6 according to lxr.free-electrons.com.
>
> Generally, the runtime PM status is only meaningful for devices with runtime 
> PM
> enabled.
>
> There is an exception, which is during system suspend/resume, when runtime PM
> is automatically disabled by the core, but that only under certain 
> assumptions.
>
> Basically, you have to assume that no one else will mess up with the device
> between the times you call pm_runtime_status_suspended() to check its runtime
> PM status (or between the first time you do that and the last time runtime PM
> has been enabled for the device).
>
> This patch doesn't change the situation in that respect.

BTW, I'm not sure why you are worrying about the "status" field alone
and not about the usage counter that can be greater than 0 after
pm_runtime_force_suspend() which is inconsistent with the device's
physical state (and with the "status" field too for that matter -
always without the patch and in some cases with it) then.  As a matter
of fact, the information left by the runtime PM framework is messed up
with here this way or another and so anyway the only party that can
make sense of it after pm_runtime_force_suspend() is the subsequent
pm_runtime_force_resume().

Thanks,
Rafael

Re: [PATCH] PM / runtime: Rework pm_runtime_force_suspend/resume()

[Rafael J. Wysocki]

On Tue, Jan 2, 2018 at 8:07 PM, Rafael J. Wysocki  wrote:
> On Tuesday, January 2, 2018 2:04:04 PM CET Lukas Wunner wrote:
>> On Tue, Jan 02, 2018 at 12:02:18PM +0100, Rafael J. Wysocki wrote:
>> > On Tue, Jan 2, 2018 at 11:51 AM, Lukas Wunner  wrote:
>> > > On Tue, Jan 02, 2018 at 01:56:28AM +0100, Rafael J. Wysocki wrote:
>> > >> + if (atomic_read(>power.usage_count) <= 1 &&
>> > >> + atomic_read(>power.child_count) == 0)
>> > >> + pm_runtime_set_suspended(dev);
>> > >>
>> > >> - pm_runtime_set_suspended(dev);
>> > >
>> > > The ->runtime_suspend callback *has* been executed at this point.
>> > > If the status is only updated conditionally, it may not reflect
>> > > the device's actual power state correctly.  That doesn't seem to
>> > > be a good idea.
>> >
>> > It doesn't matter, because this is done with runtime PM disabled, isn't it?
>>
>> It might not make a difference for the use case I have in mind, but
>> pm_runtime_status_suspended() will return an incorrect result and is
>> called from 47 files in 4.15-rc6 according to lxr.free-electrons.com.
>
> Generally, the runtime PM status is only meaningful for devices with runtime 
> PM
> enabled.
>
> There is an exception, which is during system suspend/resume, when runtime PM
> is automatically disabled by the core, but that only under certain 
> assumptions.
>
> Basically, you have to assume that no one else will mess up with the device
> between the times you call pm_runtime_status_suspended() to check its runtime
> PM status (or between the first time you do that and the last time runtime PM
> has been enabled for the device).
>
> This patch doesn't change the situation in that respect.

BTW, I'm not sure why you are worrying about the "status" field alone
and not about the usage counter that can be greater than 0 after
pm_runtime_force_suspend() which is inconsistent with the device's
physical state (and with the "status" field too for that matter -
always without the patch and in some cases with it) then.  As a matter
of fact, the information left by the runtime PM framework is messed up
with here this way or another and so anyway the only party that can
make sense of it after pm_runtime_force_suspend() is the subsequent
pm_runtime_force_resume().

Thanks,
Rafael

Re: stable/linux-3.16.y build: 178 builds: 1 failed, 177 passed, 2 errors, 57 warnings (v3.16.52)

[Arnd Bergmann]

On Tue, Jan 2, 2018 at 12:48 PM, kernelci.org bot  wrote:

Hi Ben,

almost a clean build with kernelci!

> Errors summary:
> 1 drivers/scsi/mpt2sas/mpt2sas_base.c:3550:1: internal compiler error: in 
> extract_constrain_insn, at recog.c:2190
> 1 drivers/scsi/mpt2sas/mpt2sas_base.c:3550:1: error: insn does not satisfy 
> its constraints:

See earlier discussion https://www.spinics.net/lists/stable/msg195996.html

> Warnings summary:
> 54 include/linux/stddef.h:8:14: warning: 'return' with a value, in function 
> returning void

This comes from an incorrect backport of commit
49e67dd17649 ("of: fdt: add missing allocation-failure check")

It's harmless, and stable/linux-3.18.y has the correct version:

--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -380,6 +380,6 @@ static void __unflatten_device_tree(void *blob,
/* Allocate memory for the expanded device tree */
mem = dt_alloc(size + 4, __alignof__(struct device_node));
if (!mem)
-   return NULL;
+   return;

memset(mem, 0, size);


> 2 ipc/sem.c:377:6: warning: '___p1' may be used uninitialized in this 
> function [-Wmaybe-uninitialized]

This code was last touched in 3.16 by the backport of commit
5864a2fd3088 ("ipc/sem.c: fix complex_count vs. simple op race")

The warning is in "smp_load_acquire(>complex_mode))", and I suspect
that commit 27d7be1801a4 ("ipc/sem.c: avoid using spin_unlock_wait()")
avoided the warning upstream by removing the smp_mb() before it.

The code is way too complex for a fly-by analysis, so I'm adding Manfred
to Cc here. It may be worth comparing the full list of backports that
went into ipc/sem.c in 3.16.y with those in 3.18.y and 4.1.y that don't
have the warning. Here is what I see in the git history:

$ git log --oneline v3.16..stable/linux-3.16.y ipc/sem.c
accb9f16adba ipc/sem.c: fix complex_count vs. simple op race
5b11c133308b ipc: remove use of seq_printf return value
08397b1a5cd4 sysv, ipc: fix security-layer leaking
35cfc2b3a9da ipc/sem.c: fully initialize sem_array before making it visible
69a9a86b645f ipc/sem.c: update/correct memory barriers
30f995ba77ca ipc/sem.c: change memory barrier in sem_lock() to smp_rmb()
76ce4fe19d6b ipc,sem: fix use after free on IPC_RMID after a task
using same semaphore set exits

$ git log --oneline v3.16..stable/linux-3.18.y ipc/sem.c
7dd90826dfba sysv, ipc: fix security-layer leaking
ff12efa03da1 ipc/sem.c: update/correct memory barriers
38b50c47c25e ipc,sem: fix use after free on IPC_RMID after a task
using same semaphore set exits
e8577d1f0329 ipc/sem.c: fully initialize sem_array before making it visible

$ git log --oneline v3.16..stable/linux-4.1.y ipc/sem.c
e2b438fdfa4d sysv, ipc: fix security-layer leaking
b6805da60f01 ipc/sem.c: update/correct memory barriers
7be83cf01024 ipc,sem: fix use after free on IPC_RMID after a task
using same semaphore set exits
7f032d6ef615 ipc: remove use of seq_printf return value
52644c9ab3fa ipc,sem: use current->state helpers
2e094abfd1f2 ipc/sem.c: change memory barrier in sem_lock() to smp_rmb()
e8577d1f0329 ipc/sem.c: fully initialize sem_array before making it visible

$ git log --oneline v3.16..stable/linux-4.4.y ipc/sem.c
f6031d95320d ipc/sem.c: fix complex_count vs. simple op race
62659f0b9ed7 sysv, ipc: fix security-layer leaking
3ed1f8a99d70 ipc/sem.c: update/correct memory barriers
a97955844807 ipc,sem: remove uneeded sem_undo_list lock usage in exit_sem()
602b8593d2b4 ipc,sem: fix use after free on IPC_RMID after a task
using same semaphore set exits
55b7ae50167e ipc: rename ipc_obtain_object
7f032d6ef615 ipc: remove use of seq_printf return value
52644c9ab3fa ipc,sem: use current->state helpers
2e094abfd1f2 ipc/sem.c: change memory barrier in sem_lock() to smp_rmb()
e8577d1f0329 ipc/sem.c: fully initialize sem_array before making it visible

$ git log --oneline v3.16..stable/linux-4.9.y ipc/sem.c
2a1613a586de ipc/sem.c: add cond_resched in exit_sme
5864a2fd3088 ipc/sem.c: fix complex_count vs. simple op race
9b24fef9f041 sysv, ipc: fix security-layer leaking
be3e78449803 locking/spinlock: Update spin_unlock_wait() users
33ac279677dc locking/barriers: Introduce smp_acquire__after_ctrl_dep()
a5f4db877177 ipc/sem: make semctl setting sempid consistent
1d5cfdb07628 tree wide: use kvfree() than conditional kfree()/vfree()
3ed1f8a99d70 ipc/sem.c: update/correct memory barriers
a97955844807 ipc,sem: remove uneeded sem_undo_list lock usage in exit_sem()
602b8593d2b4 ipc,sem: fix use after free on IPC_RMID after a task
using same semaphore set exits
55b7ae50167e ipc: rename ipc_obtain_object
7f032d6ef615 ipc: remove use of seq_printf return value
52644c9ab3fa ipc,sem: use current->state helpers
2e094abfd1f2 ipc/sem.c: change memory barrier in sem_lock() to smp_rmb()
e8577d1f0329 ipc/sem.c: fully initialize sem_array before making it visible

> 1 arch/arm/kernel/head-nommu.S:167: Warning: Use of r13 as a source register 
> is deprecated when r15 is the destination 

Re: stable/linux-3.16.y build: 178 builds: 1 failed, 177 passed, 2 errors, 57 warnings (v3.16.52)

[Arnd Bergmann]

On Tue, Jan 2, 2018 at 12:48 PM, kernelci.org bot  wrote:

Hi Ben,

almost a clean build with kernelci!

> Errors summary:
> 1 drivers/scsi/mpt2sas/mpt2sas_base.c:3550:1: internal compiler error: in 
> extract_constrain_insn, at recog.c:2190
> 1 drivers/scsi/mpt2sas/mpt2sas_base.c:3550:1: error: insn does not satisfy 
> its constraints:

See earlier discussion https://www.spinics.net/lists/stable/msg195996.html

> Warnings summary:
> 54 include/linux/stddef.h:8:14: warning: 'return' with a value, in function 
> returning void

This comes from an incorrect backport of commit
49e67dd17649 ("of: fdt: add missing allocation-failure check")

It's harmless, and stable/linux-3.18.y has the correct version:

--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -380,6 +380,6 @@ static void __unflatten_device_tree(void *blob,
/* Allocate memory for the expanded device tree */
mem = dt_alloc(size + 4, __alignof__(struct device_node));
if (!mem)
-   return NULL;
+   return;

memset(mem, 0, size);


> 2 ipc/sem.c:377:6: warning: '___p1' may be used uninitialized in this 
> function [-Wmaybe-uninitialized]

This code was last touched in 3.16 by the backport of commit
5864a2fd3088 ("ipc/sem.c: fix complex_count vs. simple op race")

The warning is in "smp_load_acquire(>complex_mode))", and I suspect
that commit 27d7be1801a4 ("ipc/sem.c: avoid using spin_unlock_wait()")
avoided the warning upstream by removing the smp_mb() before it.

The code is way too complex for a fly-by analysis, so I'm adding Manfred
to Cc here. It may be worth comparing the full list of backports that
went into ipc/sem.c in 3.16.y with those in 3.18.y and 4.1.y that don't
have the warning. Here is what I see in the git history:

$ git log --oneline v3.16..stable/linux-3.16.y ipc/sem.c
accb9f16adba ipc/sem.c: fix complex_count vs. simple op race
5b11c133308b ipc: remove use of seq_printf return value
08397b1a5cd4 sysv, ipc: fix security-layer leaking
35cfc2b3a9da ipc/sem.c: fully initialize sem_array before making it visible
69a9a86b645f ipc/sem.c: update/correct memory barriers
30f995ba77ca ipc/sem.c: change memory barrier in sem_lock() to smp_rmb()
76ce4fe19d6b ipc,sem: fix use after free on IPC_RMID after a task
using same semaphore set exits

$ git log --oneline v3.16..stable/linux-3.18.y ipc/sem.c
7dd90826dfba sysv, ipc: fix security-layer leaking
ff12efa03da1 ipc/sem.c: update/correct memory barriers
38b50c47c25e ipc,sem: fix use after free on IPC_RMID after a task
using same semaphore set exits
e8577d1f0329 ipc/sem.c: fully initialize sem_array before making it visible

$ git log --oneline v3.16..stable/linux-4.1.y ipc/sem.c
e2b438fdfa4d sysv, ipc: fix security-layer leaking
b6805da60f01 ipc/sem.c: update/correct memory barriers
7be83cf01024 ipc,sem: fix use after free on IPC_RMID after a task
using same semaphore set exits
7f032d6ef615 ipc: remove use of seq_printf return value
52644c9ab3fa ipc,sem: use current->state helpers
2e094abfd1f2 ipc/sem.c: change memory barrier in sem_lock() to smp_rmb()
e8577d1f0329 ipc/sem.c: fully initialize sem_array before making it visible

$ git log --oneline v3.16..stable/linux-4.4.y ipc/sem.c
f6031d95320d ipc/sem.c: fix complex_count vs. simple op race
62659f0b9ed7 sysv, ipc: fix security-layer leaking
3ed1f8a99d70 ipc/sem.c: update/correct memory barriers
a97955844807 ipc,sem: remove uneeded sem_undo_list lock usage in exit_sem()
602b8593d2b4 ipc,sem: fix use after free on IPC_RMID after a task
using same semaphore set exits
55b7ae50167e ipc: rename ipc_obtain_object
7f032d6ef615 ipc: remove use of seq_printf return value
52644c9ab3fa ipc,sem: use current->state helpers
2e094abfd1f2 ipc/sem.c: change memory barrier in sem_lock() to smp_rmb()
e8577d1f0329 ipc/sem.c: fully initialize sem_array before making it visible

$ git log --oneline v3.16..stable/linux-4.9.y ipc/sem.c
2a1613a586de ipc/sem.c: add cond_resched in exit_sme
5864a2fd3088 ipc/sem.c: fix complex_count vs. simple op race
9b24fef9f041 sysv, ipc: fix security-layer leaking
be3e78449803 locking/spinlock: Update spin_unlock_wait() users
33ac279677dc locking/barriers: Introduce smp_acquire__after_ctrl_dep()
a5f4db877177 ipc/sem: make semctl setting sempid consistent
1d5cfdb07628 tree wide: use kvfree() than conditional kfree()/vfree()
3ed1f8a99d70 ipc/sem.c: update/correct memory barriers
a97955844807 ipc,sem: remove uneeded sem_undo_list lock usage in exit_sem()
602b8593d2b4 ipc,sem: fix use after free on IPC_RMID after a task
using same semaphore set exits
55b7ae50167e ipc: rename ipc_obtain_object
7f032d6ef615 ipc: remove use of seq_printf return value
52644c9ab3fa ipc,sem: use current->state helpers
2e094abfd1f2 ipc/sem.c: change memory barrier in sem_lock() to smp_rmb()
e8577d1f0329 ipc/sem.c: fully initialize sem_array before making it visible

> 1 arch/arm/kernel/head-nommu.S:167: Warning: Use of r13 as a source register 
> is deprecated when r15 is the destination register.

Fixed by 

[GIT PULL] cpupower update for 4.16-rc1

[Shuah Khan]

Hi Rafael,

Please pull the cpupower update for 4.16-rc1.

This update consists of a patch to remove FSF address.
Diff is attached.

thanks,
-- Shuah

--
The following changes since commit ae64f9bd1d3621b5e60d7363bc20afb46aede215:

  Linux 4.15-rc2 (2017-12-03 11:01:47 -0500)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux 
tags/linux-cpupower-4.16-rc1

for you to fetch changes up to 0e96a0c83f0842d5cfd83b0a896bc82ff61f9849:

  cpupower: Remove FSF address (2017-12-15 08:27:39 -0700)


linux-cpupower-4.16-rc1

This update consists of a patch to remove FSF address.


Laura Abbott (1):
  cpupower: Remove FSF address

 tools/power/cpupower/lib/cpufreq.h | 4 
 1 file changed, 4 deletions(-)

--
diff --git a/tools/power/cpupower/lib/cpufreq.h b/tools/power/cpupower/lib/cpufreq.h
index 3b005c39f068..60beaf5ed2ea 100644
--- a/tools/power/cpupower/lib/cpufreq.h
+++ b/tools/power/cpupower/lib/cpufreq.h
@@ -11,10 +11,6 @@
  *  but WITHOUT ANY WARRANTY; without even the implied warranty of
  *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  *  GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 
 #ifndef __CPUPOWER_CPUFREQ_H__

[GIT PULL] cpupower update for 4.16-rc1

[Shuah Khan]

Hi Rafael,

Please pull the cpupower update for 4.16-rc1.

This update consists of a patch to remove FSF address.
Diff is attached.

thanks,
-- Shuah

--
The following changes since commit ae64f9bd1d3621b5e60d7363bc20afb46aede215:

  Linux 4.15-rc2 (2017-12-03 11:01:47 -0500)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux 
tags/linux-cpupower-4.16-rc1

for you to fetch changes up to 0e96a0c83f0842d5cfd83b0a896bc82ff61f9849:

  cpupower: Remove FSF address (2017-12-15 08:27:39 -0700)


linux-cpupower-4.16-rc1

This update consists of a patch to remove FSF address.


Laura Abbott (1):
  cpupower: Remove FSF address

 tools/power/cpupower/lib/cpufreq.h | 4 
 1 file changed, 4 deletions(-)

--
diff --git a/tools/power/cpupower/lib/cpufreq.h b/tools/power/cpupower/lib/cpufreq.h
index 3b005c39f068..60beaf5ed2ea 100644
--- a/tools/power/cpupower/lib/cpufreq.h
+++ b/tools/power/cpupower/lib/cpufreq.h
@@ -11,10 +11,6 @@
  *  but WITHOUT ANY WARRANTY; without even the implied warranty of
  *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  *  GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 
 #ifndef __CPUPOWER_CPUFREQ_H__

Re: 4.15-rc6 PTI regression: L1 TLB mismatch MCE on Athlon64

[Thomas Gleixner]

On Tue, 2 Jan 2018, Borislav Petkov wrote:
> On Tue, Jan 02, 2018 at 10:49:16PM +0200, Meelis Roos wrote:
> > This is on a socket 939 Athlon64 3500+, with PTI enabled.
> 
> LOL.
> 
> > [  316.384669] mce: [Hardware Error]: Machine check events logged
> > [  316.384698] [Hardware Error]: Corrected error, no action required.
> > [  316.384719] [Hardware Error]: CPU:0 (f:2f:2) MC1_STATUS[-|CE|-|-|AddrV]: 
> > 0x94010011
> > [  316.384742] [Hardware Error]: Error Addr: 0x81e000e0
> 
> That's the [47:12] slice of the virtual address which it tried to execute.
> 
> According to our map in mm.txt:
> 
> 8000 - 87ff (=43 bits) guard hole, reserved for 
> hypervisor
> 
> vs
> 
> 81e000e0...
> 
> which makes me think: WTF now?!
> 
> I don't see any hypervisor happening in dmesg...

Meelis, can you please enable CONFIG_X86_PTDUMP. If you select M then
please load the resulting module 'debug_pagetables'.

Then please do the following from a shell:

# cat /sys/kernel/debug/page_tables/* >t.txt

and provide the output.

Thanks,

tglx

Re: 4.15-rc6 PTI regression: L1 TLB mismatch MCE on Athlon64

[Thomas Gleixner]

On Tue, 2 Jan 2018, Borislav Petkov wrote:
> On Tue, Jan 02, 2018 at 10:49:16PM +0200, Meelis Roos wrote:
> > This is on a socket 939 Athlon64 3500+, with PTI enabled.
> 
> LOL.
> 
> > [  316.384669] mce: [Hardware Error]: Machine check events logged
> > [  316.384698] [Hardware Error]: Corrected error, no action required.
> > [  316.384719] [Hardware Error]: CPU:0 (f:2f:2) MC1_STATUS[-|CE|-|-|AddrV]: 
> > 0x94010011
> > [  316.384742] [Hardware Error]: Error Addr: 0x81e000e0
> 
> That's the [47:12] slice of the virtual address which it tried to execute.
> 
> According to our map in mm.txt:
> 
> 8000 - 87ff (=43 bits) guard hole, reserved for 
> hypervisor
> 
> vs
> 
> 81e000e0...
> 
> which makes me think: WTF now?!
> 
> I don't see any hypervisor happening in dmesg...

Meelis, can you please enable CONFIG_X86_PTDUMP. If you select M then
please load the resulting module 'debug_pagetables'.

Then please do the following from a shell:

# cat /sys/kernel/debug/page_tables/* >t.txt

and provide the output.

Thanks,

tglx

Re: [PATCH] clk: Fix debugfs_create_*() usage

[Stephen Boyd]

On 01/02, Geert Uytterhoeven wrote:
> On Tue, Jan 2, 2018 at 8:23 PM, Stephen Boyd  wrote:
> > On 01/02, Geert Uytterhoeven wrote:

> >> --- a/drivers/clk/clk.c
> >> +++ b/drivers/clk/clk.c
> >> @@ -58,7 +58,7 @@ struct clk_core {
> >>   unsigned long   new_rate;
> >>   struct clk_core *new_parent;
> >>   struct clk_core *new_child;
> >> - unsigned long   flags;
> >> + unsigned intflags;
> >
> > This doesn't look good.
> 
> Why not?
> It's not like flags is used with bitops, which would  mandate unsigned long.
> And you can't start using bits 32-63 without changing flags to u64, else
> the extra bits are not available on 32-bit platforms.

Fair enough. We don't need to change it if we print better
information in debugfs though. That's all I'm saying.

> 
> >> @@ -2600,43 +2600,43 @@ static int clk_debug_create_one(struct clk_core 
> >> *core, struct dentry *pdentry)
> >>
> >>   core->dentry = d;
> >>
> >> - d = debugfs_create_u32("clk_rate", S_IRUGO, core->dentry,
> >> - (u32 *)>rate);
> >> + d = debugfs_create_ulong("clk_rate", S_IRUGO, core->dentry,
> >> +  >rate);
> >
> > As you're changing these lines, can you also change S_IRUGO to
> > the octal values. That's the preferred style now.
> 
> Yes, I can. That would be a separate patch, though.

Uhhh ok. I will fold them together if you don't :)

> 
> >>   d = debugfs_create_x32("clk_flags", S_IRUGO, core->dentry,
> >> - (u32 *)>flags);
> >> +>flags);
> >
> > Maybe we need a new debugfs API like debugfs_create_ulong_hex()
> > or something that prints out an unsigned long as a hex value?
> 
> That's possible.  I already have that locally (for another user which uses
> u32 or u64 depending on platform).
> My main worry was the change from 0x to 0x
> on 64-bit platforms, which you don't seem to see as a blocker, as
> debugfs isn't ABI?

That's right. Debugfs isn't an ABI.

> 
> > clk_flags file would have something like
> >
> > CLK_SET_RATE_PARENT
> > CLK_SET_RATE_GATE
> >
> > if those flags are set.
> 
> But some flags are internal to platform-specific drivers, right?

Nope. Platform specific drivers shouldn't be passing internal
flags in this field. It's for the clk core to use. Perhaps we
should enforce that by failing non-core flags on registration.
I've been catching this in review so far.

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

Re: [PATCH] clk: Fix debugfs_create_*() usage

[Stephen Boyd]

On 01/02, Geert Uytterhoeven wrote:
> On Tue, Jan 2, 2018 at 8:23 PM, Stephen Boyd  wrote:
> > On 01/02, Geert Uytterhoeven wrote:

> >> --- a/drivers/clk/clk.c
> >> +++ b/drivers/clk/clk.c
> >> @@ -58,7 +58,7 @@ struct clk_core {
> >>   unsigned long   new_rate;
> >>   struct clk_core *new_parent;
> >>   struct clk_core *new_child;
> >> - unsigned long   flags;
> >> + unsigned intflags;
> >
> > This doesn't look good.
> 
> Why not?
> It's not like flags is used with bitops, which would  mandate unsigned long.
> And you can't start using bits 32-63 without changing flags to u64, else
> the extra bits are not available on 32-bit platforms.

Fair enough. We don't need to change it if we print better
information in debugfs though. That's all I'm saying.

> 
> >> @@ -2600,43 +2600,43 @@ static int clk_debug_create_one(struct clk_core 
> >> *core, struct dentry *pdentry)
> >>
> >>   core->dentry = d;
> >>
> >> - d = debugfs_create_u32("clk_rate", S_IRUGO, core->dentry,
> >> - (u32 *)>rate);
> >> + d = debugfs_create_ulong("clk_rate", S_IRUGO, core->dentry,
> >> +  >rate);
> >
> > As you're changing these lines, can you also change S_IRUGO to
> > the octal values. That's the preferred style now.
> 
> Yes, I can. That would be a separate patch, though.

Uhhh ok. I will fold them together if you don't :)

> 
> >>   d = debugfs_create_x32("clk_flags", S_IRUGO, core->dentry,
> >> - (u32 *)>flags);
> >> +>flags);
> >
> > Maybe we need a new debugfs API like debugfs_create_ulong_hex()
> > or something that prints out an unsigned long as a hex value?
> 
> That's possible.  I already have that locally (for another user which uses
> u32 or u64 depending on platform).
> My main worry was the change from 0x to 0x
> on 64-bit platforms, which you don't seem to see as a blocker, as
> debugfs isn't ABI?

That's right. Debugfs isn't an ABI.

> 
> > clk_flags file would have something like
> >
> > CLK_SET_RATE_PARENT
> > CLK_SET_RATE_GATE
> >
> > if those flags are set.
> 
> But some flags are internal to platform-specific drivers, right?

Nope. Platform specific drivers shouldn't be passing internal
flags in this field. It's for the clk core to use. Perhaps we
should enforce that by failing non-core flags on registration.
I've been catching this in review so far.

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

Re: [RESEND PATCH v2 10/15] ASoC: qcom: qdsp6: Add support to q6routing driver

[Bjorn Andersson]

On Thu 14 Dec 09:33 PST 2017, srinivas.kandaga...@linaro.org wrote:

> From: Srinivas Kandagatla 
> 
> This patch adds support to q6 routing driver which configures route
> between ASM and AFE module using ADM apis.
> 
> This driver uses dapm widgets to setup the matrix between AFE ports and
> ASM streams.
> 

Why is this a separate driver from the q6adm?

> Signed-off-by: Srinivas Kandagatla 
> ---
>  sound/soc/qcom/Kconfig   |   5 +
>  sound/soc/qcom/qdsp6/Makefile|   1 +
>  sound/soc/qcom/qdsp6/q6routing.c | 386 
> +++
>  sound/soc/qcom/qdsp6/q6routing.h |   9 +
>  4 files changed, 401 insertions(+)
>  create mode 100644 sound/soc/qcom/qdsp6/q6routing.c
>  create mode 100644 sound/soc/qcom/qdsp6/q6routing.h
> 
> diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig
> index 121b9c957024..dd8fb0cde614 100644
> --- a/sound/soc/qcom/Kconfig
> +++ b/sound/soc/qcom/Kconfig
> @@ -60,12 +60,17 @@ config SND_SOC_QDSP6_CORE
>   tristate
>   default n
>  
> +config SND_SOC_QDSP6_ROUTING
> + tristate
> + default n
> +
>  config SND_SOC_QDSP6
>   tristate "SoC ALSA audio driver for QDSP6"
>   select SND_SOC_QDSP6_AFE
>   select SND_SOC_QDSP6_ADM
>   select SND_SOC_QDSP6_ASM
>   select SND_SOC_QDSP6_CORE
> + select SND_SOC_QDSP6_ROUTING
>   help
>To add support for MSM QDSP6 Soc Audio.
>This will enable sound soc platform specific
> diff --git a/sound/soc/qcom/qdsp6/Makefile b/sound/soc/qcom/qdsp6/Makefile
> index ad7f10691e54..c1ad060a2341 100644
> --- a/sound/soc/qcom/qdsp6/Makefile
> +++ b/sound/soc/qcom/qdsp6/Makefile
> @@ -2,3 +2,4 @@ obj-$(CONFIG_SND_SOC_QDSP6_AFE) += q6afe.o
>  obj-$(CONFIG_SND_SOC_QDSP6_ADM) += q6adm.o
>  obj-$(CONFIG_SND_SOC_QDSP6_ASM) += q6asm.o
>  obj-$(CONFIG_SND_SOC_QDSP6_CORE) += q6core.o
> +obj-$(CONFIG_SND_SOC_QDSP6_ROUTING) += q6routing.o
> diff --git a/sound/soc/qcom/qdsp6/q6routing.c 
> b/sound/soc/qcom/qdsp6/q6routing.c
> new file mode 100644
> index ..f5f12d61a1ee
> --- /dev/null
> +++ b/sound/soc/qcom/qdsp6/q6routing.c
> @@ -0,0 +1,386 @@
> +/* SPDX-License-Identifier: GPL-2.0
> +* Copyright (c) 2011-2016, The Linux Foundation
> +* Copyright (c) 2017, Linaro Limited
> +*/
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "q6afe.h"
> +#include "q6asm.h"
> +#include "q6adm.h"
> +#include "q6routing.h"
> +
> +struct session_data {
> + int state;
> + int port_id;
> + int path_type;
> + int app_type;
> + int acdb_id;
> + int sample_rate;
> + int bits_per_sample;
> + int channels;
> + int format;
> + int perf_mode;
> + int numcopps;
> + int fedai_id;
> + unsigned long copp_map;
> +};
> +
> +struct msm_routing_data {
> + struct session_data sessions[MAX_SESSIONS];
> + struct device *dev;
> + struct mutex lock;
> +};
> +
> +static struct msm_routing_data *routing_data;
> +
> +/**
> + * q6routing_reg_phy_stream() - Register a new stream for route setup
> + *
> + * @fedai_id: Frontend dai id.
> + * @perf_mode: Performace mode.

"Performance"

> + * @stream_id: ASM stream id to map.
> + * @stream_type: Direction of stream
> + *
> + * Return: Will be an negative on error or a zero on success.
> + */
> +int q6routing_reg_phy_stream(int fedai_id, int perf_mode,

q6routing_stream_open() ?

> +int stream_id, int stream_type)
> +{
> + int j, topology, num_copps = 0;
> + struct route_payload payload;
> + int copp_idx;
> + struct session_data *session;
> +
> + if (!routing_data) {
> + pr_err("Routing driver not yet ready\n");
> + return -EINVAL;
> + }
> +
> + session = _data->sessions[stream_id - 1];
> + mutex_lock(_data->lock);
> + session->fedai_id = fedai_id;
> + payload.num_copps = 0; /* only RX needs to use payload */
> + topology = NULL_COPP_TOPOLOGY;
> + copp_idx = q6adm_open(routing_data->dev, session->port_id,
> +   session->path_type, session->sample_rate,
> +   session->channels, topology, perf_mode,
> +   session->bits_per_sample, 0, 0);
> + if ((copp_idx < 0) || (copp_idx >= MAX_COPPS_PER_PORT)) {

Make q6adm_open() not return >= MAX_COPPS_PER_PORT.

And drop the extra parenthesis.

> + mutex_unlock(_data->lock);
> + return -EINVAL;
> + }
> +
> + set_bit(copp_idx, >copp_map);
> + for (j = 0; j < MAX_COPPS_PER_PORT; j++) {

Use for_each_set_bit()

> + unsigned long copp = session->copp_map;
> +
> + if (test_bit(j, )) {
> + payload.port_id[num_copps] = session->port_id;
> + payload.copp_idx[num_copps] = j;
> +  

Re: [RESEND PATCH v2 10/15] ASoC: qcom: qdsp6: Add support to q6routing driver

[Bjorn Andersson]

On Thu 14 Dec 09:33 PST 2017, srinivas.kandaga...@linaro.org wrote:

> From: Srinivas Kandagatla 
> 
> This patch adds support to q6 routing driver which configures route
> between ASM and AFE module using ADM apis.
> 
> This driver uses dapm widgets to setup the matrix between AFE ports and
> ASM streams.
> 

Why is this a separate driver from the q6adm?

> Signed-off-by: Srinivas Kandagatla 
> ---
>  sound/soc/qcom/Kconfig   |   5 +
>  sound/soc/qcom/qdsp6/Makefile|   1 +
>  sound/soc/qcom/qdsp6/q6routing.c | 386 
> +++
>  sound/soc/qcom/qdsp6/q6routing.h |   9 +
>  4 files changed, 401 insertions(+)
>  create mode 100644 sound/soc/qcom/qdsp6/q6routing.c
>  create mode 100644 sound/soc/qcom/qdsp6/q6routing.h
> 
> diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig
> index 121b9c957024..dd8fb0cde614 100644
> --- a/sound/soc/qcom/Kconfig
> +++ b/sound/soc/qcom/Kconfig
> @@ -60,12 +60,17 @@ config SND_SOC_QDSP6_CORE
>   tristate
>   default n
>  
> +config SND_SOC_QDSP6_ROUTING
> + tristate
> + default n
> +
>  config SND_SOC_QDSP6
>   tristate "SoC ALSA audio driver for QDSP6"
>   select SND_SOC_QDSP6_AFE
>   select SND_SOC_QDSP6_ADM
>   select SND_SOC_QDSP6_ASM
>   select SND_SOC_QDSP6_CORE
> + select SND_SOC_QDSP6_ROUTING
>   help
>To add support for MSM QDSP6 Soc Audio.
>This will enable sound soc platform specific
> diff --git a/sound/soc/qcom/qdsp6/Makefile b/sound/soc/qcom/qdsp6/Makefile
> index ad7f10691e54..c1ad060a2341 100644
> --- a/sound/soc/qcom/qdsp6/Makefile
> +++ b/sound/soc/qcom/qdsp6/Makefile
> @@ -2,3 +2,4 @@ obj-$(CONFIG_SND_SOC_QDSP6_AFE) += q6afe.o
>  obj-$(CONFIG_SND_SOC_QDSP6_ADM) += q6adm.o
>  obj-$(CONFIG_SND_SOC_QDSP6_ASM) += q6asm.o
>  obj-$(CONFIG_SND_SOC_QDSP6_CORE) += q6core.o
> +obj-$(CONFIG_SND_SOC_QDSP6_ROUTING) += q6routing.o
> diff --git a/sound/soc/qcom/qdsp6/q6routing.c 
> b/sound/soc/qcom/qdsp6/q6routing.c
> new file mode 100644
> index ..f5f12d61a1ee
> --- /dev/null
> +++ b/sound/soc/qcom/qdsp6/q6routing.c
> @@ -0,0 +1,386 @@
> +/* SPDX-License-Identifier: GPL-2.0
> +* Copyright (c) 2011-2016, The Linux Foundation
> +* Copyright (c) 2017, Linaro Limited
> +*/
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "q6afe.h"
> +#include "q6asm.h"
> +#include "q6adm.h"
> +#include "q6routing.h"
> +
> +struct session_data {
> + int state;
> + int port_id;
> + int path_type;
> + int app_type;
> + int acdb_id;
> + int sample_rate;
> + int bits_per_sample;
> + int channels;
> + int format;
> + int perf_mode;
> + int numcopps;
> + int fedai_id;
> + unsigned long copp_map;
> +};
> +
> +struct msm_routing_data {
> + struct session_data sessions[MAX_SESSIONS];
> + struct device *dev;
> + struct mutex lock;
> +};
> +
> +static struct msm_routing_data *routing_data;
> +
> +/**
> + * q6routing_reg_phy_stream() - Register a new stream for route setup
> + *
> + * @fedai_id: Frontend dai id.
> + * @perf_mode: Performace mode.

"Performance"

> + * @stream_id: ASM stream id to map.
> + * @stream_type: Direction of stream
> + *
> + * Return: Will be an negative on error or a zero on success.
> + */
> +int q6routing_reg_phy_stream(int fedai_id, int perf_mode,

q6routing_stream_open() ?

> +int stream_id, int stream_type)
> +{
> + int j, topology, num_copps = 0;
> + struct route_payload payload;
> + int copp_idx;
> + struct session_data *session;
> +
> + if (!routing_data) {
> + pr_err("Routing driver not yet ready\n");
> + return -EINVAL;
> + }
> +
> + session = _data->sessions[stream_id - 1];
> + mutex_lock(_data->lock);
> + session->fedai_id = fedai_id;
> + payload.num_copps = 0; /* only RX needs to use payload */
> + topology = NULL_COPP_TOPOLOGY;
> + copp_idx = q6adm_open(routing_data->dev, session->port_id,
> +   session->path_type, session->sample_rate,
> +   session->channels, topology, perf_mode,
> +   session->bits_per_sample, 0, 0);
> + if ((copp_idx < 0) || (copp_idx >= MAX_COPPS_PER_PORT)) {

Make q6adm_open() not return >= MAX_COPPS_PER_PORT.

And drop the extra parenthesis.

> + mutex_unlock(_data->lock);
> + return -EINVAL;
> + }
> +
> + set_bit(copp_idx, >copp_map);
> + for (j = 0; j < MAX_COPPS_PER_PORT; j++) {

Use for_each_set_bit()

> + unsigned long copp = session->copp_map;
> +
> + if (test_bit(j, )) {
> + payload.port_id[num_copps] = session->port_id;
> + payload.copp_idx[num_copps] = j;
> + num_copps++;
> + }
> + }
> +
> + 

Re: [PATCH v2 4/6] clk: ingenic: Add JZ47xx TCU clocks driver

[Stephen Boyd]

On 01/02, Paul Cercueil wrote:
> >> +  goto err_free_tcu;
> >> +  }
> >> +
> >> +  tcu->clocks.clk_num = nb_clks;
> >> +  tcu->clocks.clks = kcalloc(nb_clks, sizeof(struct clk *),
> >>GFP_KERNEL);
> >> +  if (!tcu->clocks.clks) {
> >> +  pr_err("%s: cannot allocate memory\n", __func__);
> >
> >We don't need allocation error messages. Please run checkpatch.
> 
> I did run checkpatch, which warned about this, but that's a false
> positive to me.
> The callback passed to CLK_OF_DECLARE() has a return type void, so
> there's no
> way I can return -ENOMEM, and I don't want the error to be unnoticed.

The kernel typically spews a bunch of information when an
allocation error happens, so your pr_err() will be lost in the
spew, which is why it's not really necessary.

> 
> About the other remarks - I agree with you, I'll fix these in the V2.
> 

Ok.

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

Re: [PATCH v2 4/6] clk: ingenic: Add JZ47xx TCU clocks driver

[Stephen Boyd]

On 01/02, Paul Cercueil wrote:
> >> +  goto err_free_tcu;
> >> +  }
> >> +
> >> +  tcu->clocks.clk_num = nb_clks;
> >> +  tcu->clocks.clks = kcalloc(nb_clks, sizeof(struct clk *),
> >>GFP_KERNEL);
> >> +  if (!tcu->clocks.clks) {
> >> +  pr_err("%s: cannot allocate memory\n", __func__);
> >
> >We don't need allocation error messages. Please run checkpatch.
> 
> I did run checkpatch, which warned about this, but that's a false
> positive to me.
> The callback passed to CLK_OF_DECLARE() has a return type void, so
> there's no
> way I can return -ENOMEM, and I don't want the error to be unnoticed.

The kernel typically spews a bunch of information when an
allocation error happens, so your pr_err() will be lost in the
spew, which is why it's not really necessary.

> 
> About the other remarks - I agree with you, I'll fix these in the V2.
> 

Ok.

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

Re: [PATCH v2] PCI: imx6: Add PHY reference clock source support

[Fabio Estevam]

Hi Ilya,

+ Rob and dt list

On Sun, Dec 31, 2017 at 6:31 AM, Ilya Ledvich  wrote:
> i.MX7D variant of the IP can use either Crystal Oscillator input
> or internal clock input as a Reference Clock input for PCIe PHY.
> Add support for an optional property 'pcie-phy-refclk-internal'.
> If present then an internal clock input is used as PCIe PHY
> reference clock source. By default an external oscillator input
> is still used.
>
> Verified on Compulab SBC-iMX7 Single Board Computer.
>
> Signed-off-by: Ilya Ledvich 
> ---
>  Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt | 5 +
>  drivers/pci/dwc/pci-imx6.c   | 8 +++-
>  2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt 
> b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> index 7b1e48b..581bc09 100644
> --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> @@ -50,6 +50,11 @@ Additional required properties for imx7d-pcie:
>- "pciephy"
>- "apps"
>
> +Additional optional properties for imx7d-pcie:
> +- pcie-phy-refclk-internal: If present then an internal PLL input is used as
> +  PCIe PHY reference clock source. By default an external oscillator input
> +  is used.

Should this contain the vendor prefix, like fsl,pcie-phy-refclk-internal ?

Re: [PATCH v2] PCI: imx6: Add PHY reference clock source support

[Fabio Estevam]

Hi Ilya,

+ Rob and dt list

On Sun, Dec 31, 2017 at 6:31 AM, Ilya Ledvich  wrote:
> i.MX7D variant of the IP can use either Crystal Oscillator input
> or internal clock input as a Reference Clock input for PCIe PHY.
> Add support for an optional property 'pcie-phy-refclk-internal'.
> If present then an internal clock input is used as PCIe PHY
> reference clock source. By default an external oscillator input
> is still used.
>
> Verified on Compulab SBC-iMX7 Single Board Computer.
>
> Signed-off-by: Ilya Ledvich 
> ---
>  Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt | 5 +
>  drivers/pci/dwc/pci-imx6.c   | 8 +++-
>  2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt 
> b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> index 7b1e48b..581bc09 100644
> --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> @@ -50,6 +50,11 @@ Additional required properties for imx7d-pcie:
>- "pciephy"
>- "apps"
>
> +Additional optional properties for imx7d-pcie:
> +- pcie-phy-refclk-internal: If present then an internal PLL input is used as
> +  PCIe PHY reference clock source. By default an external oscillator input
> +  is used.

Should this contain the vendor prefix, like fsl,pcie-phy-refclk-internal ?

Re: [PATCH 1/2] Move kfree_call_rcu() to slab_common.c

[Rao Shoaib]

On 01/02/2018 02:23 PM, Matthew Wilcox wrote:

On Tue, Jan 02, 2018 at 12:11:37PM -0800, rao.sho...@oracle.com wrote:

-#define kfree_rcu(ptr, rcu_head)   \
-   __kfree_rcu(&((ptr)->rcu_head), offsetof(typeof(*(ptr)), rcu_head))
+#define kfree_rcu(ptr, rcu_head_name)  \
+   do { \
+   typeof(ptr) __ptr = ptr;\
+   unsigned long __off = offsetof(typeof(*(__ptr)), \
+ rcu_head_name); \
+   struct rcu_head *__rptr = (void *)__ptr + __off; \
+   __kfree_rcu(__rptr, __off); \
+   } while (0)

I feel like you're trying to help people understand the code better,
but using longer names can really work against that.  Reverting to
calling the parameter 'rcu_head' lets you not split the line:
I think it is a matter of preference, what is the issue with line 
splitting ?
Coming from a background other than Linux I find it very annoying that 
Linux allows variables names that are meaning less. Linux does not even 
enforce adding a prefix for structure members, so trying to find out 
where a member is used or set is impossible using cscope.
I can not change the Linux requirements so I will go ahead and make the 
change in the next rev.




+#define kfree_rcu(ptr, rcu_head)   \
+   do { \
+   typeof(ptr) __ptr = ptr;\
+   unsigned long __off = offsetof(typeof(*(__ptr)), rcu_head); \
+   struct rcu_head *__rptr = (void *)__ptr + __off; \
+   __kfree_rcu(__rptr, __off); \
+   } while (0)

Also, I don't understand why you're bothering to create __ptr here.
I understand the desire to not mention the same argument more than once,
but you have 'ptr' twice anyway.

And it's good practice to enclose macro arguments in parentheses in case
the user has done something really tricksy like pass in "p + 1".

In summary, I don't see anything fundamentally better in your rewrite
of kfree_rcu().  The previous version is more succinct, and to my
mind, easier to understand.
I did not want to make thins change but it is required due to the new 
tests added for macro expansion where the same name as in the macro can 
not be used twice. It takes care of the 'p + 1' hazard that you refer to 
above.



+void call_rcu_lazy(struct rcu_head *head, rcu_callback_t func)
+{
+   __call_rcu(head, func, _sched_state, -1, 1);
+}
-void kfree_call_rcu(struct rcu_head *head,
-   rcu_callback_t func)
-{
-   __call_rcu(head, func, rcu_state_p, -1, 1);
-}

You've silently changed this.  Why?  It might well be the right change,
but it at least merits mentioning in the changelog.
This was to address a comment about me not changing the tiny 
implementation to be same as the tree implementation.


Shoaib


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

Re: [PATCH 1/2] Move kfree_call_rcu() to slab_common.c

[Rao Shoaib]

On 01/02/2018 02:23 PM, Matthew Wilcox wrote:

On Tue, Jan 02, 2018 at 12:11:37PM -0800, rao.sho...@oracle.com wrote:

-#define kfree_rcu(ptr, rcu_head)   \
-   __kfree_rcu(&((ptr)->rcu_head), offsetof(typeof(*(ptr)), rcu_head))
+#define kfree_rcu(ptr, rcu_head_name)  \
+   do { \
+   typeof(ptr) __ptr = ptr;\
+   unsigned long __off = offsetof(typeof(*(__ptr)), \
+ rcu_head_name); \
+   struct rcu_head *__rptr = (void *)__ptr + __off; \
+   __kfree_rcu(__rptr, __off); \
+   } while (0)

I feel like you're trying to help people understand the code better,
but using longer names can really work against that.  Reverting to
calling the parameter 'rcu_head' lets you not split the line:
I think it is a matter of preference, what is the issue with line 
splitting ?
Coming from a background other than Linux I find it very annoying that 
Linux allows variables names that are meaning less. Linux does not even 
enforce adding a prefix for structure members, so trying to find out 
where a member is used or set is impossible using cscope.
I can not change the Linux requirements so I will go ahead and make the 
change in the next rev.




+#define kfree_rcu(ptr, rcu_head)   \
+   do { \
+   typeof(ptr) __ptr = ptr;\
+   unsigned long __off = offsetof(typeof(*(__ptr)), rcu_head); \
+   struct rcu_head *__rptr = (void *)__ptr + __off; \
+   __kfree_rcu(__rptr, __off); \
+   } while (0)

Also, I don't understand why you're bothering to create __ptr here.
I understand the desire to not mention the same argument more than once,
but you have 'ptr' twice anyway.

And it's good practice to enclose macro arguments in parentheses in case
the user has done something really tricksy like pass in "p + 1".

In summary, I don't see anything fundamentally better in your rewrite
of kfree_rcu().  The previous version is more succinct, and to my
mind, easier to understand.
I did not want to make thins change but it is required due to the new 
tests added for macro expansion where the same name as in the macro can 
not be used twice. It takes care of the 'p + 1' hazard that you refer to 
above.



+void call_rcu_lazy(struct rcu_head *head, rcu_callback_t func)
+{
+   __call_rcu(head, func, _sched_state, -1, 1);
+}
-void kfree_call_rcu(struct rcu_head *head,
-   rcu_callback_t func)
-{
-   __call_rcu(head, func, rcu_state_p, -1, 1);
-}

You've silently changed this.  Why?  It might well be the right change,
but it at least merits mentioning in the changelog.
This was to address a comment about me not changing the tiny 
implementation to be same as the tree implementation.


Shoaib


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

Re: [PATCH 3/4] extcon: axp288: Redo charger type dection a couple of seconds after probe()

[Hans de Goede]

Hi,

On 02-01-18 01:54, Chanwoo Choi wrote:

Hi Hans,

s/dection/detection on patch title.


Thank you for all the reviews.

I've fixed the typo in my personal tree.


On 2017년 12월 22일 21:36, Hans de Goede wrote:

The axp288 extcon code depends on other drivers to do things like mux the
data lines, enable/disable vbus based on the id-pin, etc.

Sometimes the BIOS has not set these things up correctly resulting in the
initial charger cable type detection giving a wrong result and we end up
not charging or charging at only 0.5A.

This commit starts a second charger-detection cycle a couple of seconds
after the first one finishes, giving the other drivers time to load and
do their thing.

Signed-off-by: Hans de Goede 
---
  drivers/extcon/extcon-axp288.c | 32 ++--
  1 file changed, 30 insertions(+), 2 deletions(-)

diff --git a/drivers/extcon/extcon-axp288.c b/drivers/extcon/extcon-axp288.c
index 386afb7d1160..cc7c35c7ff02 100644
--- a/drivers/extcon/extcon-axp288.c
+++ b/drivers/extcon/extcon-axp288.c
@@ -1,6 +1,7 @@
  /*
   * extcon-axp288.c - X-Power AXP288 PMIC extcon cable detection driver
   *
+ * Copyright (C) 2016-2017 Hans de Goede 
   * Copyright (C) 2015 Intel Corporation
   * Author: Ramakrishna Pallala 
   *
@@ -97,9 +98,11 @@ struct axp288_extcon_info {
struct device *dev;
struct regmap *regmap;
struct regmap_irq_chip_data *regmap_irqc;
+   struct delayed_work det_work;
int irq[EXTCON_IRQ_END];
struct extcon_dev *edev;
unsigned int previous_cable;
+   bool first_detect_done;


The first_detect_done is used only one time in the 
axp288_handle_chrg_det_event().
The other function don't use it. So, you better to define and use
'static bool first_detect_done' in the axp288_handle_chrg_det_event()
instead of defining the 'first_detect_done' in the struct axp288_extcon_info.


But what if a device has 2 axp288 PMICs (unlikely I know) then only the
first one to check this will do the re-detect 2 seconds later, unless they
race, which is bad in itself too.

In general using static function variables is a bad idea and should be
avoided, it does not work when their are multiple instances of the device
and it is racy. So sorry but I'm not going to make this change.




  };
  
  /* Power up/down reason string array */

@@ -137,6 +140,25 @@ static void axp288_extcon_log_rsi(struct 
axp288_extcon_info *info)
regmap_write(info->regmap, AXP288_PS_BOOT_REASON_REG, clear_mask);
  }
  
+static void axp288_chrg_detect_complete(struct axp288_extcon_info *info)

+{
+   /*
+* We depend on other drivers to do things like mux the data lines,
+* enable/disable vbus based on the id-pin, etc. Sometimes the BIOS has
+* not set these things up correctly resulting in the initial charger
+* cable type detection giving a wrong result and we end up not charging
+* or charging at only 0.5A.
+*
+* So we schedule a second cable type detection after 2 seconds to
+* give the other drivers time to load and do their thing.
+*/
+   if (!info->first_detect_done) {
+   queue_delayed_work(system_wq, >det_work,
+  msecs_to_jiffies(2000));
+   info->first_detect_done = true;
+   }
+}


The axp288_chrg_detect_complete() is only used in the 
axp288_handle_chrg_det_event()
and axp288_chrg_detect_complete() is not a complicate. I think that you don't 
need
to make the separate function. I'd like you to add the


+
  static int axp288_handle_chrg_det_event(struct axp288_extcon_info *info)
  {
int ret, stat, cfg, pwr_stat;
@@ -201,6 +223,8 @@ static int axp288_handle_chrg_det_event(struct 
axp288_extcon_info *info)
info->previous_cable = cable;
}
  
+	axp288_chrg_detect_complete(info);


As I commented, you better to add the code directly instead of separate 
function.


I would prefer to keep this as a separate function, that keeps the main
flow of the axp288_handle_chrg_det_event function a lot more readable IMHO.

axp288_handle_chrg_det_event already has a non trivial code flow adding more
conditional code to it only makes it harder to read.

But if you insist I can move the code inside the function for v2. Note that
this will not make a difference for the code generated by the compiler, the
compiler will auto-inline it anyways.





+
return 0;
  
  dev_det_ret:

@@ -222,8 +246,11 @@ static irqreturn_t axp288_extcon_isr(int irq, void *data)
return IRQ_HANDLED;
  }
  
-static void axp288_extcon_enable(struct axp288_extcon_info *info)

+static void axp288_extcon_det_work(struct work_struct *work)
  {
+   struct axp288_extcon_info *info =
+   container_of(work, struct axp288_extcon_info, det_work.work);
+
regmap_update_bits(info->regmap, AXP288_BC_GLOBAL_REG,
   

Re: [PATCH 3/4] extcon: axp288: Redo charger type dection a couple of seconds after probe()

[Hans de Goede]

Hi,

On 02-01-18 01:54, Chanwoo Choi wrote:

Hi Hans,

s/dection/detection on patch title.


Thank you for all the reviews.

I've fixed the typo in my personal tree.


On 2017년 12월 22일 21:36, Hans de Goede wrote:

The axp288 extcon code depends on other drivers to do things like mux the
data lines, enable/disable vbus based on the id-pin, etc.

Sometimes the BIOS has not set these things up correctly resulting in the
initial charger cable type detection giving a wrong result and we end up
not charging or charging at only 0.5A.

This commit starts a second charger-detection cycle a couple of seconds
after the first one finishes, giving the other drivers time to load and
do their thing.

Signed-off-by: Hans de Goede 
---
  drivers/extcon/extcon-axp288.c | 32 ++--
  1 file changed, 30 insertions(+), 2 deletions(-)

diff --git a/drivers/extcon/extcon-axp288.c b/drivers/extcon/extcon-axp288.c
index 386afb7d1160..cc7c35c7ff02 100644
--- a/drivers/extcon/extcon-axp288.c
+++ b/drivers/extcon/extcon-axp288.c
@@ -1,6 +1,7 @@
  /*
   * extcon-axp288.c - X-Power AXP288 PMIC extcon cable detection driver
   *
+ * Copyright (C) 2016-2017 Hans de Goede 
   * Copyright (C) 2015 Intel Corporation
   * Author: Ramakrishna Pallala 
   *
@@ -97,9 +98,11 @@ struct axp288_extcon_info {
struct device *dev;
struct regmap *regmap;
struct regmap_irq_chip_data *regmap_irqc;
+   struct delayed_work det_work;
int irq[EXTCON_IRQ_END];
struct extcon_dev *edev;
unsigned int previous_cable;
+   bool first_detect_done;


The first_detect_done is used only one time in the 
axp288_handle_chrg_det_event().
The other function don't use it. So, you better to define and use
'static bool first_detect_done' in the axp288_handle_chrg_det_event()
instead of defining the 'first_detect_done' in the struct axp288_extcon_info.


But what if a device has 2 axp288 PMICs (unlikely I know) then only the
first one to check this will do the re-detect 2 seconds later, unless they
race, which is bad in itself too.

In general using static function variables is a bad idea and should be
avoided, it does not work when their are multiple instances of the device
and it is racy. So sorry but I'm not going to make this change.




  };
  
  /* Power up/down reason string array */

@@ -137,6 +140,25 @@ static void axp288_extcon_log_rsi(struct 
axp288_extcon_info *info)
regmap_write(info->regmap, AXP288_PS_BOOT_REASON_REG, clear_mask);
  }
  
+static void axp288_chrg_detect_complete(struct axp288_extcon_info *info)

+{
+   /*
+* We depend on other drivers to do things like mux the data lines,
+* enable/disable vbus based on the id-pin, etc. Sometimes the BIOS has
+* not set these things up correctly resulting in the initial charger
+* cable type detection giving a wrong result and we end up not charging
+* or charging at only 0.5A.
+*
+* So we schedule a second cable type detection after 2 seconds to
+* give the other drivers time to load and do their thing.
+*/
+   if (!info->first_detect_done) {
+   queue_delayed_work(system_wq, >det_work,
+  msecs_to_jiffies(2000));
+   info->first_detect_done = true;
+   }
+}


The axp288_chrg_detect_complete() is only used in the 
axp288_handle_chrg_det_event()
and axp288_chrg_detect_complete() is not a complicate. I think that you don't 
need
to make the separate function. I'd like you to add the


+
  static int axp288_handle_chrg_det_event(struct axp288_extcon_info *info)
  {
int ret, stat, cfg, pwr_stat;
@@ -201,6 +223,8 @@ static int axp288_handle_chrg_det_event(struct 
axp288_extcon_info *info)
info->previous_cable = cable;
}
  
+	axp288_chrg_detect_complete(info);


As I commented, you better to add the code directly instead of separate 
function.


I would prefer to keep this as a separate function, that keeps the main
flow of the axp288_handle_chrg_det_event function a lot more readable IMHO.

axp288_handle_chrg_det_event already has a non trivial code flow adding more
conditional code to it only makes it harder to read.

But if you insist I can move the code inside the function for v2. Note that
this will not make a difference for the code generated by the compiler, the
compiler will auto-inline it anyways.





+
return 0;
  
  dev_det_ret:

@@ -222,8 +246,11 @@ static irqreturn_t axp288_extcon_isr(int irq, void *data)
return IRQ_HANDLED;
  }
  
-static void axp288_extcon_enable(struct axp288_extcon_info *info)

+static void axp288_extcon_det_work(struct work_struct *work)
  {
+   struct axp288_extcon_info *info =
+   container_of(work, struct axp288_extcon_info, det_work.work);
+
regmap_update_bits(info->regmap, AXP288_BC_GLOBAL_REG,
BC_GLOBAL_RUN, 0);
/* Enable 

Re: [PATCH v5 03/78] xarray: Add the xa_lock to the radix_tree_root

[Matthew Wilcox]

On Tue, Jan 02, 2018 at 10:01:55AM -0800, Darrick J. Wong wrote:
> On Tue, Dec 26, 2017 at 07:58:15PM -0800, Matthew Wilcox wrote:
> > spin_lock_irqsave(>pages, flags);
> > __delete_from_page_cache(page, NULL);
> > spin_unlock_irqrestore(>pages, flags);
> >
> > More details here: https://9p.io/sys/doc/compiler.html
> 
> I read the link, and I understand (from section 3.3) that replacing
> foo.bar.baz.goo with foo.goo is less typing, but otoh the first time I
> read your example above I thought "we're passing (an array of pages |
> something that doesn't have the word 'lock' in the name) to
> spin_lock_irqsave? wtf?"

I can see that being a bit jarring initially.  If you think about what
object-oriented languages were offering in the nineties, this is basically
C++ multiple-inheritance / Java interfaces.  So when I read the above
example, I think "lock the mapping pages, delete from page cache, unlock
the mapping pages", and I don't have a wtf moment.  It's just simpler to
read than "lock the mapping pages lock", and less redundant.

> I suppose it does force me to go dig into whatever mapping->pages is to
> figure out that there's an unnamed spinlock_t and that the compiler can
> insert the appropriate pointer arithmetic, but now my brain trips over
> 'pages' being at the end of the selector for parameter 1 which slows
> down my review reading...
> 
> OTOH I guess it /did/ motivate me to click the link, so well played,
> sir. :)

Now if only I can trick you into giving your ACK on patch 1,
"xfs: Rename xa_ elements to ail_"

Re: [PATCH v5 03/78] xarray: Add the xa_lock to the radix_tree_root

[Matthew Wilcox]

On Tue, Jan 02, 2018 at 10:01:55AM -0800, Darrick J. Wong wrote:
> On Tue, Dec 26, 2017 at 07:58:15PM -0800, Matthew Wilcox wrote:
> > spin_lock_irqsave(>pages, flags);
> > __delete_from_page_cache(page, NULL);
> > spin_unlock_irqrestore(>pages, flags);
> >
> > More details here: https://9p.io/sys/doc/compiler.html
> 
> I read the link, and I understand (from section 3.3) that replacing
> foo.bar.baz.goo with foo.goo is less typing, but otoh the first time I
> read your example above I thought "we're passing (an array of pages |
> something that doesn't have the word 'lock' in the name) to
> spin_lock_irqsave? wtf?"

I can see that being a bit jarring initially.  If you think about what
object-oriented languages were offering in the nineties, this is basically
C++ multiple-inheritance / Java interfaces.  So when I read the above
example, I think "lock the mapping pages, delete from page cache, unlock
the mapping pages", and I don't have a wtf moment.  It's just simpler to
read than "lock the mapping pages lock", and less redundant.

> I suppose it does force me to go dig into whatever mapping->pages is to
> figure out that there's an unnamed spinlock_t and that the compiler can
> insert the appropriate pointer arithmetic, but now my brain trips over
> 'pages' being at the end of the selector for parameter 1 which slows
> down my review reading...
> 
> OTOH I guess it /did/ motivate me to click the link, so well played,
> sir. :)

Now if only I can trick you into giving your ACK on patch 1,
"xfs: Rename xa_ elements to ail_"

Re: [PATCH] virtio: make VIRTIO a menuconfig to ease disabling it all

[Michael Ellerman]

Michael Ellerman  writes:

> Vincent Legoll  writes:
>
>> Hello,
>>
>> thanks for the help, and sorry for the poor patch,
>>
>> On Thu, Dec 21, 2017 at 11:53 AM, Michael Ellerman  
>> wrote:
>>> This breaks all existing .configs *and* defconfigs that use VIRTIO.
>>>
>>> Please don't do that.
>>>
>>> If you make it default y then everything will continue to work.
>>
>> Do you want me to respin it with the added default ?
>
> Yes please, either that or revert it.

This still seems to be broken.

cheers

Re: [PATCH] virtio: make VIRTIO a menuconfig to ease disabling it all

[Michael Ellerman]

Michael Ellerman  writes:

> Vincent Legoll  writes:
>
>> Hello,
>>
>> thanks for the help, and sorry for the poor patch,
>>
>> On Thu, Dec 21, 2017 at 11:53 AM, Michael Ellerman  
>> wrote:
>>> This breaks all existing .configs *and* defconfigs that use VIRTIO.
>>>
>>> Please don't do that.
>>>
>>> If you make it default y then everything will continue to work.
>>
>> Do you want me to respin it with the added default ?
>
> Yes please, either that or revert it.

This still seems to be broken.

cheers

Re: [PATCH 4.14 000/146] 4.14.11-stable review

[Shuah Khan]

On 01/01/2018 07:36 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.11 release.
> There are 146 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Jan  3 14:00:12 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.11-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.14.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.14 000/146] 4.14.11-stable review

[Shuah Khan]

On 01/01/2018 07:36 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.11 release.
> There are 146 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Jan  3 14:00:12 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.11-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.14.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.9 00/75] 4.9.74-stable review

[Neal Cardwell]

On Tue, Jan 2, 2018 at 3:08 PM, Greg KH  wrote:
> On Tue, Jan 02, 2018 at 02:11:25PM -0500, Neal Cardwell wrote:
...
>> Thanks, Greg and David. Looks like these 2 patches will cherry-pick
>> cleanly if cherry-picked in the following sequence, on top of
>> 4.9.74-rc1, which already has 6c9e73ef9aa7 ("tcp_bbr: record "full bw
>> reached" decision in new full_bw_reached bit"):
>>
>> $ git checkout linux-stable-rc/linux-4.9.y
>>
>> $ git cherry-pick 2f6c498e4f15
>> Performing inexact rename detection: 100% (17803152/17803152), done.
>> [detached HEAD 0982234c57e1] tcp_bbr: reset full pipe detection on
>> loss recovery undo
>>  Date: Thu Dec 7 12:43:31 2017 -0500
>>  1 file changed, 4 insertions(+)
>>
>> $ git cherry-pick 600647d467c6
>> Performing inexact rename detection: 100% (17803152/17803152), done.
>> [detached HEAD 7e866eccd083] tcp_bbr: reset long-term bandwidth
>> sampling on loss recovery undo
>>  Date: Thu Dec 7 12:43:32 2017 -0500
>>  1 file changed, 1 insertion(+)
>>
>> $ git log --oneline --decorate | head -3
>> 7e866eccd083 (HEAD) tcp_bbr: reset long-term bandwidth sampling on
>> loss recovery undo
>> 0982234c57e1 tcp_bbr: reset full pipe detection on loss recovery undo
>> 79070be7f1ae (linux-stable-rc/linux-4.9.y) Linux 4.9.74-rc1
>>
>> I verified that this compiles without warnings, and boots, and BBR works.
>>
>> Shall I prepare another version of these 2 patches, or do we think
>> this recipe will be sufficient? (Sorry I am not more familiar with the
>> backport-to-stable process.)
>
> That works, those two patches are now queued up for the next stable
> release, thanks!
>
> greg k-h

Great. Thank you, Greg and David!

neal

Re: [PATCH 4.9 00/75] 4.9.74-stable review

[Neal Cardwell]

On Tue, Jan 2, 2018 at 3:08 PM, Greg KH  wrote:
> On Tue, Jan 02, 2018 at 02:11:25PM -0500, Neal Cardwell wrote:
...
>> Thanks, Greg and David. Looks like these 2 patches will cherry-pick
>> cleanly if cherry-picked in the following sequence, on top of
>> 4.9.74-rc1, which already has 6c9e73ef9aa7 ("tcp_bbr: record "full bw
>> reached" decision in new full_bw_reached bit"):
>>
>> $ git checkout linux-stable-rc/linux-4.9.y
>>
>> $ git cherry-pick 2f6c498e4f15
>> Performing inexact rename detection: 100% (17803152/17803152), done.
>> [detached HEAD 0982234c57e1] tcp_bbr: reset full pipe detection on
>> loss recovery undo
>>  Date: Thu Dec 7 12:43:31 2017 -0500
>>  1 file changed, 4 insertions(+)
>>
>> $ git cherry-pick 600647d467c6
>> Performing inexact rename detection: 100% (17803152/17803152), done.
>> [detached HEAD 7e866eccd083] tcp_bbr: reset long-term bandwidth
>> sampling on loss recovery undo
>>  Date: Thu Dec 7 12:43:32 2017 -0500
>>  1 file changed, 1 insertion(+)
>>
>> $ git log --oneline --decorate | head -3
>> 7e866eccd083 (HEAD) tcp_bbr: reset long-term bandwidth sampling on
>> loss recovery undo
>> 0982234c57e1 tcp_bbr: reset full pipe detection on loss recovery undo
>> 79070be7f1ae (linux-stable-rc/linux-4.9.y) Linux 4.9.74-rc1
>>
>> I verified that this compiles without warnings, and boots, and BBR works.
>>
>> Shall I prepare another version of these 2 patches, or do we think
>> this recipe will be sufficient? (Sorry I am not more familiar with the
>> backport-to-stable process.)
>
> That works, those two patches are now queued up for the next stable
> release, thanks!
>
> greg k-h

Great. Thank you, Greg and David!

neal

Re: [PATCH] xfs: destroy mutex qi_tree_lock before free xfs_quotainfo_t object

[Xiongwei Song]

2018-01-03 4:38 GMT+08:00 Darrick J. Wong :
> On Sun, Dec 24, 2017 at 08:34:47PM +0800, Xiongwei Song wrote:
>> The mutex qi_tree_lock of xfs_quotainfo_t object was initialized when
>> calling xfs_qm_init_quotainfo, but it was not destroyed before free
>> xfs_quotainfo_t object when calling xfs_qm_destroy_quotainfo, this was
>> incorrect, so destroy it in function xfs_qm_destroy_quotainfo.
>
> Already in for-next, but thank you for catching this.
>
> https://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git/commit/?h=for-next=2196881566225f3c3428d1a5f847a992944daa5b


Apologies for the noise.


Yours sincerely,
Xiongwei


> --D
>
>> Signed-off-by: Xiongwei Song 
>> ---
>>  fs/xfs/xfs_qm.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/fs/xfs/xfs_qm.c b/fs/xfs/xfs_qm.c
>> index ec952dfad359..deceef5cbbf3 100644
>> --- a/fs/xfs/xfs_qm.c
>> +++ b/fs/xfs/xfs_qm.c
>> @@ -737,6 +737,7 @@ xfs_qm_destroy_quotainfo(
>>   qi->qi_pquotaip = NULL;
>>   }
>>   mutex_destroy(>qi_quotaofflock);
>> + mutex_destroy(>qi_tree_lock);
>>   kmem_free(qi);
>>   mp->m_quotainfo = NULL;
>>  }
>> --
>> 2.15.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] xfs: destroy mutex qi_tree_lock before free xfs_quotainfo_t object

[Xiongwei Song]

2018-01-03 4:38 GMT+08:00 Darrick J. Wong :
> On Sun, Dec 24, 2017 at 08:34:47PM +0800, Xiongwei Song wrote:
>> The mutex qi_tree_lock of xfs_quotainfo_t object was initialized when
>> calling xfs_qm_init_quotainfo, but it was not destroyed before free
>> xfs_quotainfo_t object when calling xfs_qm_destroy_quotainfo, this was
>> incorrect, so destroy it in function xfs_qm_destroy_quotainfo.
>
> Already in for-next, but thank you for catching this.
>
> https://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git/commit/?h=for-next=2196881566225f3c3428d1a5f847a992944daa5b


Apologies for the noise.


Yours sincerely,
Xiongwei


> --D
>
>> Signed-off-by: Xiongwei Song 
>> ---
>>  fs/xfs/xfs_qm.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/fs/xfs/xfs_qm.c b/fs/xfs/xfs_qm.c
>> index ec952dfad359..deceef5cbbf3 100644
>> --- a/fs/xfs/xfs_qm.c
>> +++ b/fs/xfs/xfs_qm.c
>> @@ -737,6 +737,7 @@ xfs_qm_destroy_quotainfo(
>>   qi->qi_pquotaip = NULL;
>>   }
>>   mutex_destroy(>qi_quotaofflock);
>> + mutex_destroy(>qi_tree_lock);
>>   kmem_free(qi);
>>   mp->m_quotainfo = NULL;
>>  }
>> --
>> 2.15.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4.4 00/63] 4.4.109-stable review

[Shuah Khan]

On 01/01/2018 07:24 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.109 release.
> There are 63 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Jan  3 13:59:54 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.109-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.4.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.4 00/63] 4.4.109-stable review

[Shuah Khan]

On 01/01/2018 07:24 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.109 release.
> There are 63 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Jan  3 13:59:54 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.109-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.4.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.9 00/75] 4.9.74-stable review

[Shuah Khan]

On 01/01/2018 07:31 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.74 release.
> There are 75 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Jan  3 14:00:03 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.74-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.9 00/75] 4.9.74-stable review

[Shuah Khan]

On 01/01/2018 07:31 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.74 release.
> There are 75 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Jan  3 14:00:03 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.74-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 1/2] Move kfree_call_rcu() to slab_common.c

[Matthew Wilcox]

On Tue, Jan 02, 2018 at 12:11:37PM -0800, rao.sho...@oracle.com wrote:
> -#define kfree_rcu(ptr, rcu_head) \
> - __kfree_rcu(&((ptr)->rcu_head), offsetof(typeof(*(ptr)), rcu_head))

> +#define kfree_rcu(ptr, rcu_head_name)\
> + do { \
> + typeof(ptr) __ptr = ptr;\
> + unsigned long __off = offsetof(typeof(*(__ptr)), \
> +   rcu_head_name); \
> + struct rcu_head *__rptr = (void *)__ptr + __off; \
> + __kfree_rcu(__rptr, __off); \
> + } while (0)

I feel like you're trying to help people understand the code better,
but using longer names can really work against that.  Reverting to
calling the parameter 'rcu_head' lets you not split the line:

+#define kfree_rcu(ptr, rcu_head)   \
+   do { \
+   typeof(ptr) __ptr = ptr;\
+   unsigned long __off = offsetof(typeof(*(__ptr)), rcu_head); \
+   struct rcu_head *__rptr = (void *)__ptr + __off; \
+   __kfree_rcu(__rptr, __off); \
+   } while (0)

Also, I don't understand why you're bothering to create __ptr here.
I understand the desire to not mention the same argument more than once,
but you have 'ptr' twice anyway.

And it's good practice to enclose macro arguments in parentheses in case
the user has done something really tricksy like pass in "p + 1".

In summary, I don't see anything fundamentally better in your rewrite
of kfree_rcu().  The previous version is more succinct, and to my
mind, easier to understand.

> +void call_rcu_lazy(struct rcu_head *head, rcu_callback_t func)
> +{
> + __call_rcu(head, func, _sched_state, -1, 1);
> +}

> -void kfree_call_rcu(struct rcu_head *head,
> - rcu_callback_t func)
> -{
> - __call_rcu(head, func, rcu_state_p, -1, 1);
> -}

You've silently changed this.  Why?  It might well be the right change,
but it at least merits mentioning in the changelog.

Re: [PATCH 1/2] Move kfree_call_rcu() to slab_common.c

[Matthew Wilcox]

On Tue, Jan 02, 2018 at 12:11:37PM -0800, rao.sho...@oracle.com wrote:
> -#define kfree_rcu(ptr, rcu_head) \
> - __kfree_rcu(&((ptr)->rcu_head), offsetof(typeof(*(ptr)), rcu_head))

> +#define kfree_rcu(ptr, rcu_head_name)\
> + do { \
> + typeof(ptr) __ptr = ptr;\
> + unsigned long __off = offsetof(typeof(*(__ptr)), \
> +   rcu_head_name); \
> + struct rcu_head *__rptr = (void *)__ptr + __off; \
> + __kfree_rcu(__rptr, __off); \
> + } while (0)

I feel like you're trying to help people understand the code better,
but using longer names can really work against that.  Reverting to
calling the parameter 'rcu_head' lets you not split the line:

+#define kfree_rcu(ptr, rcu_head)   \
+   do { \
+   typeof(ptr) __ptr = ptr;\
+   unsigned long __off = offsetof(typeof(*(__ptr)), rcu_head); \
+   struct rcu_head *__rptr = (void *)__ptr + __off; \
+   __kfree_rcu(__rptr, __off); \
+   } while (0)

Also, I don't understand why you're bothering to create __ptr here.
I understand the desire to not mention the same argument more than once,
but you have 'ptr' twice anyway.

And it's good practice to enclose macro arguments in parentheses in case
the user has done something really tricksy like pass in "p + 1".

In summary, I don't see anything fundamentally better in your rewrite
of kfree_rcu().  The previous version is more succinct, and to my
mind, easier to understand.

> +void call_rcu_lazy(struct rcu_head *head, rcu_callback_t func)
> +{
> + __call_rcu(head, func, _sched_state, -1, 1);
> +}

> -void kfree_call_rcu(struct rcu_head *head,
> - rcu_callback_t func)
> -{
> - __call_rcu(head, func, rcu_state_p, -1, 1);
> -}

You've silently changed this.  Why?  It might well be the right change,
but it at least merits mentioning in the changelog.

Re: [PATCH 3.18 00/32] 3.18.91-stable review

[Shuah Khan]

On 01/01/2018 07:22 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.91 release.
> There are 32 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Jan  3 13:59:44 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.91-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-3.18.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 3.18 00/32] 3.18.91-stable review

[Shuah Khan]

On 01/01/2018 07:22 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.91 release.
> There are 32 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Jan  3 13:59:44 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.91-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-3.18.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH v3 09/34] clk: bcm2835: change clk_get_rate() helper return type

[Eric Anholt]

Bryan O'Donoghue  writes:

> bcm2835_pll_rate_from_divisor returns a long but the function calling it
> returns an unsigned long. There's no reason to have a type disparity here
> so tidy up the return type of bcm2835_pll_rate_from_divisor() from signed
> to unsigned long.

I'm still surprised that clocks are using longs instead of u64s, but
this seems like a fine change.  For the 2 bcm2835 patches,

Reviewed-by: Eric Anholt 


signature.asc
Description: PGP signature

Re: [PATCH] net: systemport: Delete an error message for a failed memory allocation in two functions

[Florian Fainelli]

On 01/01/2018 08:54 AM, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Mon, 1 Jan 2018 17:50:02 +0100
> 
> Omit an extra message for a memory allocation failure in these functions.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Acked-by: Florian Fainelli 
-- 
Florian

Re: [PATCH v3 09/34] clk: bcm2835: change clk_get_rate() helper return type

[Eric Anholt]

Bryan O'Donoghue  writes:

> bcm2835_pll_rate_from_divisor returns a long but the function calling it
> returns an unsigned long. There's no reason to have a type disparity here
> so tidy up the return type of bcm2835_pll_rate_from_divisor() from signed
> to unsigned long.

I'm still surprised that clocks are using longs instead of u64s, but
this seems like a fine change.  For the 2 bcm2835 patches,

Reviewed-by: Eric Anholt 


signature.asc
Description: PGP signature

Re: [PATCH] net: systemport: Delete an error message for a failed memory allocation in two functions

[Florian Fainelli]

On 01/01/2018 08:54 AM, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Mon, 1 Jan 2018 17:50:02 +0100
> 
> Omit an extra message for a memory allocation failure in these functions.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Acked-by: Florian Fainelli 
-- 
Florian

[PATCH] ARM: dts: n900: Add aliases for lcd and tvout displays

[Ivaylo Dimitrov]

When both lcd and tv are enabled, the order in which they will be probed is
unknown, so it might happen (and it happens in reality) that tv is
configured as display0 and lcd as display1, which results in nothing
displayed on lcd, as display1 is disabled by default.

Fix that by providing correct aliases for lcd and tv

Signed-off-by: Ivaylo Dimitrov 
---
 arch/arm/boot/dts/omap3-n900.dts | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 669c51c..4b9c3a7 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -35,6 +35,8 @@
i2c1 = 
i2c2 = 
i2c3 = 
+   display0 = 
+   display1 = 
};
 
cpus {
@@ -965,7 +967,7 @@
ti,esd-recovery-timeout-ms = <8000>;
};
 
-   acx565akm@2 {
+   lcd: acx565akm@2 {
compatible = "sony,acx565akm";
spi-max-frequency = <600>;
reg = <2>;
-- 
1.9.1

[PATCH] ARM: dts: n900: Add aliases for lcd and tvout displays

[Ivaylo Dimitrov]

When both lcd and tv are enabled, the order in which they will be probed is
unknown, so it might happen (and it happens in reality) that tv is
configured as display0 and lcd as display1, which results in nothing
displayed on lcd, as display1 is disabled by default.

Fix that by providing correct aliases for lcd and tv

Signed-off-by: Ivaylo Dimitrov 
---
 arch/arm/boot/dts/omap3-n900.dts | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 669c51c..4b9c3a7 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -35,6 +35,8 @@
i2c1 = 
i2c2 = 
i2c3 = 
+   display0 = 
+   display1 = 
};
 
cpus {
@@ -965,7 +967,7 @@
ti,esd-recovery-timeout-ms = <8000>;
};
 
-   acx565akm@2 {
+   lcd: acx565akm@2 {
compatible = "sony,acx565akm";
spi-max-frequency = <600>;
reg = <2>;
-- 
1.9.1