linux-next: Tree for Sep 28

[Stephen Rothwell]

Hi all,

Changes since 20160927:

The rdma tree still had its build failure so I disabled the staging
driver affected.

The drm tree gained a conflict agains Linus' tree.

The drm-misc tree gained conflicts against the drm tree.

The staging tree gained cnflicts against the vfs-miklos tree.

Non-merge commits (relative to Linus' tree): 12771
 9543 files changed, 529888 insertions(+), 289312 deletions(-)



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

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

Below is a summary of the state of the merge.

I am currently merging 243 trees (counting Linus' and 34 trees of patches
pending for Linus' tree).

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (08895a8b6b06 Linux 4.8-rc8)
Merging fixes/master (d3396e1e4ec4 Merge tag 'fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging kbuild-current/rc-fixes (d3e2773c4ede builddeb: Skip gcc-plugins when 
not configured)
Merging arc-current/for-curr (3eab887a5542 Linux 4.8-rc4)
Merging arm-current/fixes (1a57c286d8ce ARM: pxa/lubbock: add pcmcia clock)
Merging m68k-current/for-linus (6bd80f372371 m68k/defconfig: Update defconfigs 
for v4.7-rc2)
Merging metag-fixes/fixes (97b1d23f7bcb metag: Drop show_mem() from mem_init())
Merging powerpc-fixes/fixes (b79331a5eb9f powerpc/powernv/pci: Fix m64 checks 
for SR-IOV and window alignment)
Merging sparc/master (4620a06e4b3c shmem: Fix link error if huge pages support 
is disabled)
Merging net/master (7b8147aae741 Merge branch 'act_ife-fixes')
Merging ipsec/master (b1f2beb87bb0 Merge tag 'media/v4.8-7' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media)
Merging netfilter/master (440f895aa97f drivers: net: phy: xgene: Fix 'remove' 
function)
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (db64c5fa590b Merge tag 
'iwlwifi-for-kalle-2016-09-15' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (7ac327318e09 Merge tag 'mac80211-for-davem-2016-09-16' 
of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211)
Merging sound-current/for-linus (0eec880966e7 ALSA: hda - Add the top speaker 
pin config for HP Spectre x360)
Merging pci-current/for-linus (035ee288ae7a PCI: Fix bridge_d3 update on device 
removal)
Merging driver-core.current/driver-core-linus (c6935931c189 Linux 4.8-rc5)
Merging tty.current/tty-linus (c6935931c189 Linux 4.8-rc5)
Merging usb.current/usb-linus (3be7988674ab Linux 4.8-rc7)
Merging usb-gadget-fixes/fixes (d8a4100ddc75 usb: gadget: udc: atmel: fix 
endpoint name)
Merging usb-serial-fixes/usb-linus (f190fd92458d USB: serial: simple: add 
support for another Infineon flashloader)
Merging usb-chipidea-fixes/ci-for-usb-stable (6f3c4fb6d05e usb: chipidea: udc: 
fix NULL ptr dereference in isr_setup_status_phase)
Merging staging.current/staging-linus (9395452b4aab Linux 4.8-rc6)
Merging char-misc.current/char-misc-linus (c6935931c189 Linux 4.8-rc5)
Merging input-current/for-linus (9fb6de1b0bf4 Input: joydev - recognize devices 
with Z axis as joysticks)
Merging crypto-current/master (0cf43f509f72 crypto: rsa-pkcs1pad - Handle 
leading zero for decryption)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/users/pcmoore/audit)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module i

Re: [PATCH] perf: remove orphan DEBUG_PERF_USE_VMALLOC

[Peter Zijlstra]

On Tue, Sep 27, 2016 at 09:51:35AM -0700, Vineet Gupta wrote:
> On 09/27/2016 09:37 AM, Kim Phillips wrote:
> > On Tue, 27 Sep 2016 07:53:56 -0700
> > Vineet Gupta  wrote:
> > 
> >> > This doesn't seem to be used anywhere
> > I thought so too, until I got this response for an equivalent patch:
> > 
> > https://lkml.org/lkml/2016/8/31/53
> 
> So this is some sort of "developer shortcut" to quickly enable 2 options with 
> one
> option. Purpose seems dubious to me ! It would still be possible to enable 
> vmalloc
> backed mmap on x86 by simply enabling that option from Kconfig.

PERF_USE_VMALLOC is not a user selectable option. Also
DEBUG_PERF_USE_VMALLOC clearly indicates its a _DEBUG_ option. Heck,
even the help text says what its for.

Re: [PATCH 2/3] DT: EVM: add LEDs

[H. Nikolaus Schaller]

Hi,

> Am 28.09.2016 um 05:37 schrieb Tony Lindgren :
> 
> * H. Nikolaus Schaller  [160927 13:11]:
>>> Am 27.09.2016 um 21:49 schrieb Tony Lindgren :
>>> How about this for defaults:
>>> 
>>> - heartbeat for led3
>>> - cpu0 for led4
>>> - cpu1 for led5
>> 
>> Good idea. Will try.
>> 
>> What I don't exactly know is if these gpios based on an I2C-expander
>> can handle cpu activity triggers or if they are locked up if this i2c
>> processing triggers another cpu activity...
> 
> Oh right, if the GPIOs are on the i2c bus

yes, they are all gpio9 which is the tca6424 on i2c5.

> it's probably not a good
> idea :) Or at least will be inaccurate if the bus can sleep.

I have tested a little by writing to /sys/class/leds/.../trigger.

If I make one LED trigger by "cpu0" it is always on and if I make
a second one triggered by "cpu1" the heartbeat becomes irregular.

So indeed this does not work.

BR,
Nikolaus

Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event

[Peter Zijlstra]

On Tue, Sep 27, 2016 at 11:26:14AM -0400, Prarit Bhargava wrote:
> I see now that the issue is not understanding the difference between physical
> and soft thread removal.  I will write that up and get back to everyone.

You don't seem to understand that from the kernels POV there is no such
distinction.

There is only one unplug operation that caters to both cases. Therefore
unplug needs to assume the most stringent (ie. physical) for things to
work right.

There is no 'soft thread removal', except maybe in the userspace API,
you're the one that is confused.

Re: [PATCH] virtio/s390: add missing \n to end of dev_err message

[Christian Borntraeger]

On 09/27/2016 10:08 PM, Colin King wrote:
> From: Colin Ian King 
> 
> Trival fix, dev_err message is missing a \n, so add it.
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/s390/virtio/virtio_ccw.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/s390/virtio/virtio_ccw.c 
> b/drivers/s390/virtio/virtio_ccw.c
> index 8688ad4..9d36dc4 100644
> --- a/drivers/s390/virtio/virtio_ccw.c
> +++ b/drivers/s390/virtio/virtio_ccw.c
> @@ -462,7 +462,7 @@ static void virtio_ccw_del_vq(struct virtqueue *vq, 
> struct ccw1 *ccw)
>* This may happen on device detach.
>*/
>   if (ret && (ret != -ENODEV))
> - dev_warn(&vq->vdev->dev, "Error %d while deleting queue %d",
> + dev_warn(&vq->vdev->dev, "Error %d while deleting queue %d\n",
>ret, index);
> 
>   vring_del_virtqueue(vq);
> 

Thanks, applied.

Re: linux-next: manual merge of the staging tree with the vfs-miklos tree

[Greg KH]

On Wed, Sep 28, 2016 at 03:00:22PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/staging/lustre/lustre/llite/file.c
> 
> between commit:
> 
>   302d50e7203e ("switch generic_file_splice_read() to use of ->read_iter()")
> 
> from the vfs-miklos tree and commits:
> 
>   5b8a39c53a16 ("staging: lustre: llite: Replace write mutex with range lock")
>   ee5532436a7d ("staging: lustre: lov: remove LL_IOC_RECREATE_{FID, OBJ}")
> 
> from the staging tree.
> 
> I fixed it up (I think - see below) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

Looks good to me, one of these days we will get lustre out of staging to
make this easier...

thanks,

greg k-h

[PATCH v5 2/7] proc: Reduce cache miss in snmp_seq_show

[Jia He]

This is to use the generic interfaces snmp_get_cpu_field{,64}_batch to
aggregate the data by going through all the items of each cpu sequentially.
Then snmp_seq_show is split into 2 parts to avoid build warning "the frame
size" larger than 1024.

Signed-off-by: Jia He 
---
 net/ipv4/proc.c | 68 ++---
 1 file changed, 46 insertions(+), 22 deletions(-)

diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index 9f665b6..e01f4df 100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -46,6 +46,8 @@
 #include 
 #include 
 
+#define TCPUDP_MIB_MAX max_t(u32, UDP_MIB_MAX, TCP_MIB_MAX)
+
 /*
  * Report socket allocation statistics [m...@utu.fi]
  */
@@ -378,13 +380,15 @@ static void icmp_put(struct seq_file *seq)
 /*
  * Called from the PROCfs module. This outputs /proc/net/snmp.
  */
-static int snmp_seq_show(struct seq_file *seq, void *v)
+static int snmp_seq_show_ipstats(struct seq_file *seq, void *v)
 {
int i;
+   u64 buff64[IPSTATS_MIB_MAX];
struct net *net = seq->private;
 
-   seq_puts(seq, "Ip: Forwarding DefaultTTL");
+   memset(buff64, 0, IPSTATS_MIB_MAX * sizeof(u64));
 
+   seq_puts(seq, "Ip: Forwarding DefaultTTL");
for (i = 0; snmp4_ipstats_list[i].name != NULL; i++)
seq_printf(seq, " %s", snmp4_ipstats_list[i].name);
 
@@ -393,57 +397,77 @@ static int snmp_seq_show(struct seq_file *seq, void *v)
   net->ipv4.sysctl_ip_default_ttl);
 
BUILD_BUG_ON(offsetof(struct ipstats_mib, mibs) != 0);
+   snmp_get_cpu_field64_batch(buff64, snmp4_ipstats_list,
+  net->mib.ip_statistics,
+  offsetof(struct ipstats_mib, syncp));
for (i = 0; snmp4_ipstats_list[i].name != NULL; i++)
-   seq_printf(seq, " %llu",
-  snmp_fold_field64(net->mib.ip_statistics,
-snmp4_ipstats_list[i].entry,
-offsetof(struct ipstats_mib, 
syncp)));
+   seq_printf(seq, " %llu", buff64[i]);
 
-   icmp_put(seq);  /* RFC 2011 compatibility */
-   icmpmsg_put(seq);
+   return 0;
+}
+
+static int snmp_seq_show_tcp_udp(struct seq_file *seq, void *v)
+{
+   int i;
+   struct net *net = seq->private;
+   unsigned long buff[TCPUDP_MIB_MAX];
+
+   memset(buff, 0, TCPUDP_MIB_MAX * sizeof(unsigned long));
 
seq_puts(seq, "\nTcp:");
for (i = 0; snmp4_tcp_list[i].name != NULL; i++)
seq_printf(seq, " %s", snmp4_tcp_list[i].name);
 
seq_puts(seq, "\nTcp:");
+   snmp_get_cpu_field_batch(buff, snmp4_tcp_list,
+net->mib.tcp_statistics);
for (i = 0; snmp4_tcp_list[i].name != NULL; i++) {
/* MaxConn field is signed, RFC 2012 */
if (snmp4_tcp_list[i].entry == TCP_MIB_MAXCONN)
-   seq_printf(seq, " %ld",
-  snmp_fold_field(net->mib.tcp_statistics,
-  snmp4_tcp_list[i].entry));
+   seq_printf(seq, " %ld", buff[i]);
else
-   seq_printf(seq, " %lu",
-  snmp_fold_field(net->mib.tcp_statistics,
-  snmp4_tcp_list[i].entry));
+   seq_printf(seq, " %lu", buff[i]);
}
 
+   memset(buff, 0, TCPUDP_MIB_MAX * sizeof(unsigned long));
+
+   snmp_get_cpu_field_batch(buff, snmp4_udp_list,
+net->mib.udp_statistics);
seq_puts(seq, "\nUdp:");
for (i = 0; snmp4_udp_list[i].name != NULL; i++)
seq_printf(seq, " %s", snmp4_udp_list[i].name);
-
seq_puts(seq, "\nUdp:");
for (i = 0; snmp4_udp_list[i].name != NULL; i++)
-   seq_printf(seq, " %lu",
-  snmp_fold_field(net->mib.udp_statistics,
-  snmp4_udp_list[i].entry));
+   seq_printf(seq, " %lu", buff[i]);
+
+   memset(buff, 0, TCPUDP_MIB_MAX * sizeof(unsigned long));
 
/* the UDP and UDP-Lite MIBs are the same */
seq_puts(seq, "\nUdpLite:");
+   snmp_get_cpu_field_batch(buff, snmp4_udp_list,
+net->mib.udplite_statistics);
for (i = 0; snmp4_udp_list[i].name != NULL; i++)
seq_printf(seq, " %s", snmp4_udp_list[i].name);
-
seq_puts(seq, "\nUdpLite:");
for (i = 0; snmp4_udp_list[i].name != NULL; i++)
-   seq_printf(seq, " %lu",
-  snmp_fold_field(net->mib.udplite_statistics,
-  snmp4_udp_list[i].entry));
+   seq_printf(seq, " %lu", buff[i]);
 
seq_putc(seq, '\n');
return 0;
 }
 
+static int snmp_seq_show(struct seq_file *seq, void *v)
+{

[PATCH v5 7/7] net: Suppress the "Comparison to NULL could be written" warnings

[Jia He]

This is to suppress the checkpatch.pl warning "Comparison to NULL
could be written". No functional changes here.

Signed-off-by: Jia He 
---
 net/ipv4/proc.c | 32 
 net/sctp/proc.c |  2 +-
 2 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index e01f4df..1a7a773 100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -357,22 +357,22 @@ static void icmp_put(struct seq_file *seq)
atomic_long_t *ptr = net->mib.icmpmsg_statistics->mibs;
 
seq_puts(seq, "\nIcmp: InMsgs InErrors InCsumErrors");
-   for (i = 0; icmpmibmap[i].name != NULL; i++)
+   for (i = 0; icmpmibmap[i].name; i++)
seq_printf(seq, " In%s", icmpmibmap[i].name);
seq_puts(seq, " OutMsgs OutErrors");
-   for (i = 0; icmpmibmap[i].name != NULL; i++)
+   for (i = 0; icmpmibmap[i].name; i++)
seq_printf(seq, " Out%s", icmpmibmap[i].name);
seq_printf(seq, "\nIcmp: %lu %lu %lu",
snmp_fold_field(net->mib.icmp_statistics, ICMP_MIB_INMSGS),
snmp_fold_field(net->mib.icmp_statistics, ICMP_MIB_INERRORS),
snmp_fold_field(net->mib.icmp_statistics, ICMP_MIB_CSUMERRORS));
-   for (i = 0; icmpmibmap[i].name != NULL; i++)
+   for (i = 0; icmpmibmap[i].name; i++)
seq_printf(seq, " %lu",
   atomic_long_read(ptr + icmpmibmap[i].index));
seq_printf(seq, " %lu %lu",
snmp_fold_field(net->mib.icmp_statistics, ICMP_MIB_OUTMSGS),
snmp_fold_field(net->mib.icmp_statistics, ICMP_MIB_OUTERRORS));
-   for (i = 0; icmpmibmap[i].name != NULL; i++)
+   for (i = 0; icmpmibmap[i].name; i++)
seq_printf(seq, " %lu",
   atomic_long_read(ptr + (icmpmibmap[i].index | 
0x100)));
 }
@@ -389,7 +389,7 @@ static int snmp_seq_show_ipstats(struct seq_file *seq, void 
*v)
memset(buff64, 0, IPSTATS_MIB_MAX * sizeof(u64));
 
seq_puts(seq, "Ip: Forwarding DefaultTTL");
-   for (i = 0; snmp4_ipstats_list[i].name != NULL; i++)
+   for (i = 0; snmp4_ipstats_list[i].name; i++)
seq_printf(seq, " %s", snmp4_ipstats_list[i].name);
 
seq_printf(seq, "\nIp: %d %d",
@@ -400,7 +400,7 @@ static int snmp_seq_show_ipstats(struct seq_file *seq, void 
*v)
snmp_get_cpu_field64_batch(buff64, snmp4_ipstats_list,
   net->mib.ip_statistics,
   offsetof(struct ipstats_mib, syncp));
-   for (i = 0; snmp4_ipstats_list[i].name != NULL; i++)
+   for (i = 0; snmp4_ipstats_list[i].name; i++)
seq_printf(seq, " %llu", buff64[i]);
 
return 0;
@@ -415,13 +415,13 @@ static int snmp_seq_show_tcp_udp(struct seq_file *seq, 
void *v)
memset(buff, 0, TCPUDP_MIB_MAX * sizeof(unsigned long));
 
seq_puts(seq, "\nTcp:");
-   for (i = 0; snmp4_tcp_list[i].name != NULL; i++)
+   for (i = 0; snmp4_tcp_list[i].name; i++)
seq_printf(seq, " %s", snmp4_tcp_list[i].name);
 
seq_puts(seq, "\nTcp:");
snmp_get_cpu_field_batch(buff, snmp4_tcp_list,
 net->mib.tcp_statistics);
-   for (i = 0; snmp4_tcp_list[i].name != NULL; i++) {
+   for (i = 0; snmp4_tcp_list[i].name; i++) {
/* MaxConn field is signed, RFC 2012 */
if (snmp4_tcp_list[i].entry == TCP_MIB_MAXCONN)
seq_printf(seq, " %ld", buff[i]);
@@ -434,10 +434,10 @@ static int snmp_seq_show_tcp_udp(struct seq_file *seq, 
void *v)
snmp_get_cpu_field_batch(buff, snmp4_udp_list,
 net->mib.udp_statistics);
seq_puts(seq, "\nUdp:");
-   for (i = 0; snmp4_udp_list[i].name != NULL; i++)
+   for (i = 0; snmp4_udp_list[i].name; i++)
seq_printf(seq, " %s", snmp4_udp_list[i].name);
seq_puts(seq, "\nUdp:");
-   for (i = 0; snmp4_udp_list[i].name != NULL; i++)
+   for (i = 0; snmp4_udp_list[i].name; i++)
seq_printf(seq, " %lu", buff[i]);
 
memset(buff, 0, TCPUDP_MIB_MAX * sizeof(unsigned long));
@@ -446,10 +446,10 @@ static int snmp_seq_show_tcp_udp(struct seq_file *seq, 
void *v)
seq_puts(seq, "\nUdpLite:");
snmp_get_cpu_field_batch(buff, snmp4_udp_list,
 net->mib.udplite_statistics);
-   for (i = 0; snmp4_udp_list[i].name != NULL; i++)
+   for (i = 0; snmp4_udp_list[i].name; i++)
seq_printf(seq, " %s", snmp4_udp_list[i].name);
seq_puts(seq, "\nUdpLite:");
-   for (i = 0; snmp4_udp_list[i].name != NULL; i++)
+   for (i = 0; snmp4_udp_list[i].name; i++)
seq_printf(seq, " %lu", buff[i]);
 
seq_putc(seq, '\n');
@@ -492,21 +492,21 @@ static int netstat_seq_show(struct seq_file *seq, void *v)
struct net *net = seq->private;
 
seq_puts(seq, "TcpExt:");

[PATCH v5 4/7] proc: Reduce cache miss in sctp_snmp_seq_show

[Jia He]

This is to use the generic interfaces snmp_get_cpu_field{,64}_batch to
aggregate the data by going through all the items of each cpu sequentially.

Signed-off-by: Jia He 
---
 net/sctp/proc.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/net/sctp/proc.c b/net/sctp/proc.c
index ef8ba77..9e7f4a7 100644
--- a/net/sctp/proc.c
+++ b/net/sctp/proc.c
@@ -73,13 +73,17 @@ static const struct snmp_mib sctp_snmp_list[] = {
 /* Display sctp snmp mib statistics(/proc/net/sctp/snmp). */
 static int sctp_snmp_seq_show(struct seq_file *seq, void *v)
 {
-   struct net *net = seq->private;
int i;
+   struct net *net = seq->private;
+   unsigned long buff[SCTP_MIB_MAX];
+
+   memset(buff, 0, sizeof(unsigned long) * SCTP_MIB_MAX);
 
+   snmp_get_cpu_field_batch(buff, sctp_snmp_list,
+net->sctp.sctp_statistics);
for (i = 0; sctp_snmp_list[i].name != NULL; i++)
seq_printf(seq, "%-32s\t%ld\n", sctp_snmp_list[i].name,
-  snmp_fold_field(net->sctp.sctp_statistics,
- sctp_snmp_list[i].entry));
+   buff[i]);
 
return 0;
 }
-- 
2.5.5

[PATCH v5 6/7] ipv6: Remove useless parameter in __snmp6_fill_statsdev

[Jia He]

The parameter items(always ICMP6_MIB_MAX) is useless for __snmp6_fill_statsdev.

Signed-off-by: Jia He 
---
 net/ipv6/addrconf.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 2f1f5d4..35d4baa 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -4961,18 +4961,18 @@ static inline size_t inet6_if_nlmsg_size(void)
 }
 
 static inline void __snmp6_fill_statsdev(u64 *stats, atomic_long_t *mib,
- int items, int bytes)
+   int bytes)
 {
int i;
-   int pad = bytes - sizeof(u64) * items;
+   int pad = bytes - sizeof(u64) * ICMP6_MIB_MAX;
BUG_ON(pad < 0);
 
/* Use put_unaligned() because stats may not be aligned for u64. */
-   put_unaligned(items, &stats[0]);
-   for (i = 1; i < items; i++)
+   put_unaligned(ICMP6_MIB_MAX, &stats[0]);
+   for (i = 1; i < ICMP6_MIB_MAX; i++)
put_unaligned(atomic_long_read(&mib[i]), &stats[i]);
 
-   memset(&stats[items], 0, pad);
+   memset(&stats[ICMP6_MIB_MAX], 0, pad);
 }
 
 static inline void __snmp6_fill_stats64(u64 *stats, void __percpu *mib,
@@ -5005,7 +5005,7 @@ static void snmp6_fill_stats(u64 *stats, struct inet6_dev 
*idev, int attrtype,
 offsetof(struct ipstats_mib, syncp));
break;
case IFLA_INET6_ICMP6STATS:
-   __snmp6_fill_statsdev(stats, idev->stats.icmpv6dev->mibs, 
ICMP6_MIB_MAX, bytes);
+   __snmp6_fill_statsdev(stats, idev->stats.icmpv6dev->mibs, 
bytes);
break;
}
 }
-- 
2.5.5

[PATCH v5 5/7] proc: Reduce cache miss in xfrm_statistics_seq_show

[Jia He]

This is to use the generic interfaces snmp_get_cpu_field{,64}_batch to
aggregate the data by going through all the items of each cpu sequentially.

Signed-off-by: Jia He 
---
 net/xfrm/xfrm_proc.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/net/xfrm/xfrm_proc.c b/net/xfrm/xfrm_proc.c
index 9c4fbd8..dc0cea6 100644
--- a/net/xfrm/xfrm_proc.c
+++ b/net/xfrm/xfrm_proc.c
@@ -50,12 +50,18 @@ static const struct snmp_mib xfrm_mib_list[] = {
 
 static int xfrm_statistics_seq_show(struct seq_file *seq, void *v)
 {
-   struct net *net = seq->private;
int i;
+   struct net *net = seq->private;
+   unsigned long buff[LINUX_MIB_XFRMMAX];
+
+   memset(buff, 0, sizeof(unsigned long) * LINUX_MIB_XFRMMAX);
+
+   snmp_get_cpu_field_batch(buff, xfrm_mib_list,
+net->mib.xfrm_statistics);
for (i = 0; xfrm_mib_list[i].name; i++)
seq_printf(seq, "%-24s\t%lu\n", xfrm_mib_list[i].name,
-  snmp_fold_field(net->mib.xfrm_statistics,
-  xfrm_mib_list[i].entry));
+   buff[i]);
+
return 0;
 }
 
-- 
2.5.5

[PATCH v5 0/7] Reduce cache miss for snmp_fold_field

[Jia He]

In a PowerPc server with large cpu number(160), besides commit
a3a773726c9f ("net: Optimize snmp stat aggregation by walking all
the percpu data at once"), I watched several other snmp_fold_field
callsites which would cause high cache miss rate.

test source code:

My simple test case, which read from the procfs items endlessly:
/***/
#include 
#include 
#include 
#include 
#include 
#define LINELEN  2560
int main(int argc, char **argv)
{
int i;
int fd = -1 ;
int rdsize = 0;
char buf[LINELEN+1];

buf[LINELEN] = 0;
memset(buf,0,LINELEN);

if(1 >= argc) {
printf("file name empty\n");
return -1;
}

fd = open(argv[1], O_RDWR, 0644);
if(0 > fd){
printf("open error\n");
return -2;
}

for(i=0;i<0x;i++) {
while(0 < (rdsize = read(fd,buf,LINELEN))){
//nothing here
}

lseek(fd, 0, SEEK_SET);
}

close(fd);
return 0;
}
/**/

compile and run:

gcc test.c -o test

perf stat -d -e cache-misses ./test /proc/net/snmp
perf stat -d -e cache-misses ./test /proc/net/snmp6
perf stat -d -e cache-misses ./test /proc/net/sctp/snmp
perf stat -d -e cache-misses ./test /proc/net/xfrm_stat

before the patch set:

 Performance counter stats for 'system wide':

 355911097  cache-misses
 [40.08%]
2356829300  L1-dcache-loads 
 [60.04%]
 355642645  L1-dcache-load-misses #   15.09% of all L1-dcache 
hits   [60.02%]
 346544541  LLC-loads   
 [59.97%]
389763  LLC-load-misses   #0.11% of all LL-cache 
hits[40.02%]

   6.245162638 seconds time elapsed

After the patch set:
===
 Performance counter stats for 'system wide':

 194992476  cache-misses
 [40.03%]
6718051877  L1-dcache-loads 
 [60.07%]
 194871921  L1-dcache-load-misses #2.90% of all L1-dcache 
hits   [60.11%]
 187632232  LLC-loads   
 [60.04%]
464466  LLC-load-misses   #0.25% of all LL-cache 
hits[39.89%]

   6.868422769 seconds time elapsed
The cache-miss rate can be reduced from 15% to 2.9%

changelog
=
v5:
- order local variables from longest to shortest line
v4:
- move memset into one block of if statement in snmp6_seq_show_item
- remove the changes in netstat_seq_show considerred the stack usage is too 
large
v3:
- introduce generic interface (suggested by Marcelo Ricardo Leitner)
- use max_t instead of self defined macro (suggested by David Miller)
v2:
- fix bug in udplite statistics.
- snmp_seq_show is split into 2 parts

Jia He (7):
  net:snmp: Introduce generic interfaces for snmp_get_cpu_field{,64}
  proc: Reduce cache miss in snmp_seq_show
  proc: Reduce cache miss in snmp6_seq_show
  proc: Reduce cache miss in sctp_snmp_seq_show
  proc: Reduce cache miss in xfrm_statistics_seq_show
  ipv6: Remove useless parameter in __snmp6_fill_statsdev
  net: Suppress the "Comparison to NULL could be written" warnings

 include/net/ip.h |  23 
 net/ipv4/proc.c  | 100 +++
 net/ipv6/addrconf.c  |  12 +++
 net/ipv6/proc.c  |  32 -
 net/sctp/proc.c  |  12 ---
 net/xfrm/xfrm_proc.c |  12 +--
 6 files changed, 131 insertions(+), 60 deletions(-)

-- 
2.5.5

[PATCH v5 1/7] net:snmp: Introduce generic interfaces for snmp_get_cpu_field{,64}

[Jia He]

This is to introduce the generic interfaces for snmp_get_cpu_field{,64}.
It exchanges the two for-loops for collecting the percpu statistics data.
This can aggregate the data by going through all the items of each cpu
sequentially.

Signed-off-by: Jia He 
Suggested-by: Marcelo Ricardo Leitner 
---
 include/net/ip.h | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/include/net/ip.h b/include/net/ip.h
index 9742b92..bc43c0f 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -219,6 +219,29 @@ static inline u64 snmp_fold_field64(void __percpu *mib, 
int offt, size_t syncp_o
 }
 #endif
 
+#define snmp_get_cpu_field64_batch(buff64, stats_list, mib_statistic, offset) \
+{ \
+   int i, c; \
+   for_each_possible_cpu(c) { \
+   for (i = 0; stats_list[i].name; i++) \
+   buff64[i] += snmp_get_cpu_field64( \
+   mib_statistic, \
+   c, stats_list[i].entry, \
+   offset); \
+   } \
+}
+
+#define snmp_get_cpu_field_batch(buff, stats_list, mib_statistic) \
+{ \
+   int i, c; \
+   for_each_possible_cpu(c) { \
+   for (i = 0; stats_list[i].name; i++) \
+   buff[i] += snmp_get_cpu_field( \
+   mib_statistic, \
+   c, stats_list[i].entry); \
+   } \
+}
+
 void inet_get_local_port_range(struct net *net, int *low, int *high);
 
 #ifdef CONFIG_SYSCTL
-- 
2.5.5

[PATCH v5 3/7] proc: Reduce cache miss in snmp6_seq_show

[Jia He]

This is to use the generic interfaces snmp_get_cpu_field{,64}_batch to
aggregate the data by going through all the items of each cpu sequentially.

Signed-off-by: Jia He 
---
 net/ipv6/proc.c | 32 +++-
 1 file changed, 23 insertions(+), 9 deletions(-)

diff --git a/net/ipv6/proc.c b/net/ipv6/proc.c
index 679253d0..e047701 100644
--- a/net/ipv6/proc.c
+++ b/net/ipv6/proc.c
@@ -30,6 +30,11 @@
 #include 
 #include 
 
+#define MAX4(a, b, c, d) \
+   max_t(u32, max_t(u32, a, b), max_t(u32, c, d))
+#define SNMP_MIB_MAX MAX4(UDP_MIB_MAX, TCP_MIB_MAX, \
+   IPSTATS_MIB_MAX, ICMP_MIB_MAX)
+
 static int sockstat6_seq_show(struct seq_file *seq, void *v)
 {
struct net *net = seq->private;
@@ -192,13 +197,19 @@ static void snmp6_seq_show_item(struct seq_file *seq, 
void __percpu *pcpumib,
const struct snmp_mib *itemlist)
 {
int i;
-   unsigned long val;
-
-   for (i = 0; itemlist[i].name; i++) {
-   val = pcpumib ?
-   snmp_fold_field(pcpumib, itemlist[i].entry) :
-   atomic_long_read(smib + itemlist[i].entry);
-   seq_printf(seq, "%-32s\t%lu\n", itemlist[i].name, val);
+   unsigned long buff[SNMP_MIB_MAX];
+
+   if (pcpumib) {
+   memset(buff, 0, sizeof(unsigned long) * SNMP_MIB_MAX);
+
+   snmp_get_cpu_field_batch(buff, itemlist, pcpumib);
+   for (i = 0; itemlist[i].name; i++)
+   seq_printf(seq, "%-32s\t%lu\n",
+  itemlist[i].name, buff[i]);
+   } else {
+   for (i = 0; itemlist[i].name; i++)
+   seq_printf(seq, "%-32s\t%lu\n", itemlist[i].name,
+  atomic_long_read(smib + itemlist[i].entry));
}
 }
 
@@ -206,10 +217,13 @@ static void snmp6_seq_show_item64(struct seq_file *seq, 
void __percpu *mib,
  const struct snmp_mib *itemlist, size_t 
syncpoff)
 {
int i;
+   u64 buff64[SNMP_MIB_MAX];
+
+   memset(buff64, 0, sizeof(unsigned long) * SNMP_MIB_MAX);
 
+   snmp_get_cpu_field64_batch(buff64, itemlist, mib, syncpoff);
for (i = 0; itemlist[i].name; i++)
-   seq_printf(seq, "%-32s\t%llu\n", itemlist[i].name,
-  snmp_fold_field64(mib, itemlist[i].entry, syncpoff));
+   seq_printf(seq, "%-32s\t%llu\n", itemlist[i].name, buff64[i]);
 }
 
 static int snmp6_seq_show(struct seq_file *seq, void *v)
-- 
2.5.5

Re: [PATCH] Fixes: 3d44a78f0d8b ("staging: rtl8712: Remove unnecessary 'else'")

[Greg KH]

On Tue, Sep 27, 2016 at 11:07:54PM -0400, Matthew Kilgore wrote:
> An "unnecessary" 'else' was removed due to complains from checkpatch.pl
> as it is preceded by a 'return', however the 'else' branch is necessary
> as an earlier branch of the 'if' falls through. By removing the 'else',
> that route now hits the 'break' and the 'while' loop exits prematurely.
> 
> This commit reverts that change and puts the original 'else' back in
> place.

Ugh, good catch, sorry for missing this, my fault.

greg k-h

Re: [PATCH v3 0/9] dmaengine: ti drivers: enable COMPILE_TESTing

[Peter Ujfalusi]

Vinod,

On 09/28/16 06:26, Vinod Koul wrote:
> On Wed, Sep 21, 2016 at 03:41:26PM +0300, Peter Ujfalusi wrote:
>> Hi,
>>
>> Changes since v2:
>> - Instead of converting to use enum for the of_device_id data parameter the 
>> two
>>   patch for edma and ti-dma-crossbar is using pointers to u32 variables to 
>> make
>>   sure that the code compile (and in theory work) on all architectures.
>> - fixed issue in the ti-dma-crossbar driver I have made with the enum change 
>> to
>>   not handle the DMA offset parameters correctly.
>>
>> Changes since v1:
>> - added the compiler warning message to ti-dma-crossbar enum type patch
>> - moved the Kconfig patches at the end of the seris
>>
>> The following series will enable unconditional COMPILE_TEST coverage for the
>> following drivers: omap-dma, edma and ti-dma-crossbar
>>
>> The series includes fixes noticed when compiling the drivers for x86_64 and
>> aarch64.
> 
> I have applied the series after fixing code style nit-picks.
> 
> Also applied the edma patch and reordered the series to have that come
> before compile test enable patch
> 
> Please verify.

Looks good, thank you!

-- 
Péter

RE: ATA failure regression

[Shah, Nehal-bakulchandra]

Hi 

Can someone please help me to debug this issue?

Regards
Nehal

-Original Message-
From: Shah, Nehal-bakulchandra 
Sent: Monday, September 26, 2016 3:45 PM
To: 'Bharat Kumar Gogada' 
Cc: Deucher, Alexander ; linux-...@vger.kernel.org; 
hol...@ahsoftware.de; t...@kernel.org; linux-...@vger.kernel.org; 
linux-kernel@vger.kernel.org
Subject: RE: ATA failure regression

Hi Bharat

Thanks for the reply. I have observed following thing

If IOMMU is enabled in BIOS and I use following option FCH SATA Debug Options 
--> Unused SATA Port Auto Shut Down Disabled. Issue is not happening. I have 
attached dmesg and lspci output with this option

Also I have attached lspci log with IOMMU disabled.

When issue is happening I am not able to take lspci logs as it stops in 
initramfs itself. I will try to get.


Thanks

Nehal
-Original Message-
From: Bharat Kumar Gogada [mailto:bharat.kumar.gog...@xilinx.com]
Sent: Friday, September 23, 2016 3:40 PM
To: Shah, Nehal-bakulchandra ; 
linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; hol...@ahsoftware.de; 
t...@kernel.org; linux-...@vger.kernel.org
Cc: Deucher, Alexander 
Subject: RE: ATA failure regression

> Hi All,
> 
> Resending this wider audience
> 
> Currently I am working on AMD future platform.  I am hitting the same 
> bug of ATA Failure Regression reported in past.
> (https://patchwork.kernel.org/patch/6875661/) or 
> http://lkml.iu.edu/hypermail/linux/kernel/1507.3/01961.html
> 
> I am newbie to this and because of this Ubuntu  16.04 is not booting. 
> If disable IOMMU and MSI obviously it works but that is not solution. 
> Even when I bisected it boiled to same place which was mentioned in past 
> discussion.
> 
So here when you are disabling MSI, it is working with legacy interrupts or 
MSI-X.
Can you post the end sata device lscpi -xxx -vvv content. 

Bharat

Re: [RFC] mm: a question about high-order check in __zone_watermark_ok()

[Joonsoo Kim]

On Mon, Sep 26, 2016 at 01:02:31PM +0200, Michal Hocko wrote:
> On Mon 26-09-16 18:17:50, Xishi Qiu wrote:
> > On 2016/9/26 17:43, Michal Hocko wrote:
> > 
> > > On Mon 26-09-16 17:16:54, Xishi Qiu wrote:
> > >> On 2016/9/26 16:58, Michal Hocko wrote:
> > >>
> > >>> On Mon 26-09-16 16:47:57, Xishi Qiu wrote:
> >  commit 97a16fc82a7c5b0cfce95c05dfb9561e306ca1b1
> >  (mm, page_alloc: only enforce watermarks for order-0 allocations)
> >  rewrite the high-order check in __zone_watermark_ok(), but I think it
> >  quietly fix a bug. Please see the following.
> > 
> >  Before this patch, the high-order check is this:
> >  __zone_watermark_ok()
> > ...
> > for (o = 0; o < order; o++) {
> > /* At the next order, this order's pages become 
> >  unavailable */
> > free_pages -= z->free_area[o].nr_free << o;
> > 
> > /* Require fewer higher order pages to be free */
> > min >>= 1;
> > 
> > if (free_pages <= min)
> > return false;
> > }
> > ...
> > 
> >  If we have cma memory, and we alloc a high-order movable page, then 
> >  it's right.
> > 
> >  But if we alloc a high-order unmovable page(e.g. alloc kernel stack in 
> >  dup_task_struct()),
> >  and there are a lot of high-order cma pages, but little high-order 
> >  unmovable
> >  pages, the it is still return *true*, but we will alloc *failed* 
> >  finally, because
> >  we cannot fallback from migrate_unmovable to migrate_cma, right?
> > >>>
> > >>> AFAIR CMA wmark check was always tricky and the above commit has made
> > >>> the situation at least a bit more clear. Anyway IIRC 
> > >>>
> > >>> #ifdef CONFIG_CMA
> > >>> /* If allocation can't use CMA areas don't use free CMA pages */
> > >>> if (!(alloc_flags & ALLOC_CMA))
> > >>> free_cma = zone_page_state(z, NR_FREE_CMA_PAGES);
> > >>> #endif
> > >>>
> > >>> if (free_pages - free_cma <= min + 
> > >>> z->lowmem_reserve[classzone_idx])
> > >>> return false;
> > >>>
> > >>> should reduce the prioblem because a lot of CMA pages should just get us
> > >>> below the wmark + reserve boundary.
> > >>
> > >> Hi Michal,
> > >>
> > >> If we have many high-order cma pages, and the left pages 
> > >> (unmovable/movable/reclaimable)
> > >> are also enough, but they are fragment, then it will triger the problem.
> > >> If we alloc a high-order unmovable page, water mark check return *true*, 
> > >> but we
> > >> will alloc *failed*, right?
> > > 
> > > As Vlastimil has written. There were known issues with the wmark checks
> > > and high order requests.
> > 
> > Shall we backport to stable?
> 
> I dunno, it was a part of a larger series with high atomic reserves and
> changes which sound a bit intrusive for the stable kernel. Considering
> that CMA was known to be problematic and there are still some issues
> left I do not think this is worth the trouble/risk.

CMA problem is known one. I mentioned it on my ZONE_CMA series v1 but
removed due to Mel's high atomic reserve series.

That series is rather large and has some problems so I think that it
is not suitable for stable tree.

Thanks.

RE: [PATCH v2] UFS: Date Segment only need for WRITE DESCRIPTOR

[Kiwoong Kim]

Hi, Martin.

I think that the patch is correct.
UFS spec says "The Data Segment area is empty" for Read Descriptor.
I have been using similar code with it and it works.
That have been already applied in Android kernel.

Reviewed-by: Kiwoong Kim 

Regards.

> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of Martin K. Petersen
> Sent: Wednesday, September 28, 2016 2:14 PM
> To: subha...@codeaurora.org
> Cc: Zang Leigang; vinholika...@gmail.com; j...@linux.vnet.ibm.com;
> martin.peter...@oracle.com; linux-s...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-scsi-ow...@vger.kernel.org
> Subject: Re: [PATCH v2] UFS: Date Segment only need for WRITE DESCRIPTOR
> 
> > "Subhash" == subhashj   writes:
> 
> Subhash> Looks good to me.
> 
> > -   /* Data segment length */
> > -   ucd_req_ptr->header.dword_2 = UPIU_HEADER_DWORD(
> > -   0, 0, len >> 8, (u8)len);
> > +   /* Data segment length only need for WRITE_DESC */
> > +   if (query->request.upiu_req.opcode == UPIU_QUERY_OPCODE_WRITE_DESC)
> > +   ucd_req_ptr->header.dword_2 =
> > +   UPIU_HEADER_DWORD(0, 0, (len >> 8), (u8)len);
> > +   else
> > +   ucd_req_ptr->header.dword_2 = 0;
> 
> What about READ_DESC?
> 
> --
> Martin K. PetersenOracle Linux Engineering
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

[PATCH] [media] atmel-isc: start dma in some scenario

[Songjun Wu]

If a new vb buf is added to vb queue, the queue is
empty and steaming, dma should be started.

Signed-off-by: Songjun Wu 
---

 drivers/media/platform/atmel/atmel-isc.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/atmel/atmel-isc.c 
b/drivers/media/platform/atmel/atmel-isc.c
index ccfe13b..8e25d3f 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -617,7 +617,13 @@ static void isc_buffer_queue(struct vb2_buffer *vb)
unsigned long flags;
 
spin_lock_irqsave(&isc->dma_queue_lock, flags);
-   list_add_tail(&buf->list, &isc->dma_queue);
+   if (!isc->cur_frm && list_empty(&isc->dma_queue) &&
+   vb2_is_streaming(vb->vb2_queue)) {
+   isc->cur_frm = buf;
+   isc_start_dma(isc->regmap, isc->cur_frm,
+   isc->current_fmt->reg_dctrl_dview);
+   } else
+   list_add_tail(&buf->list, &isc->dma_queue);
spin_unlock_irqrestore(&isc->dma_queue_lock, flags);
 }
 
-- 
2.7.4

Re: [PATCH v5 3/6] mm/cma: populate ZONE_CMA

[Joonsoo Kim]

On Thu, Sep 22, 2016 at 05:59:46PM +0200, Vlastimil Babka wrote:
> On 09/22/2016 08:50 AM, Joonsoo Kim wrote:
> >On Thu, Sep 22, 2016 at 02:45:46PM +0900, Joonsoo Kim wrote:
> >>>
> >>> > /* Free whole pageblock and set its migration type to MIGRATE_CMA. */
> >>> > void __init init_cma_reserved_pageblock(struct page *page)
> >>> > {
> >>> > unsigned i = pageblock_nr_pages;
> >>> >+unsigned long pfn = page_to_pfn(page);
> >>> > struct page *p = page;
> >>> >+int nid = page_to_nid(page);
> >>> >+
> >>> >+/*
> >>> >+ * ZONE_CMA will steal present pages from other zones by 
> >>> >changing
> >>> >+ * page links so page_zone() is changed. Before that,
> >>> >+ * we need to adjust previous zone's page count first.
> >>> >+ */
> >>> >+adjust_present_page_count(page, -pageblock_nr_pages);
> >>> >
> >>> > do {
> >>> > __ClearPageReserved(p);
> >>> > set_page_count(p, 0);
> >>> >-} while (++p, --i);
> >>> >+
> >>> >+/* Steal pages from other zones */
> >>> >+set_page_links(p, ZONE_CMA, nid, pfn);
> >>> >+} while (++p, ++pfn, --i);
> >>> >+
> >>> >+adjust_present_page_count(page, pageblock_nr_pages);
> >>>
> >>> This seems to assign pages to ZONE_CMA on the proper node, which is
> >>> good. But then ZONE_CMA on multiple nodes will have unnecessary
> >>> holes in the spanned pages, as each will contain only a subset.
> >>
> >>True, I will fix it and respin the series.
> >
> >I now realize that it's too late to send full series for next
> >merge window. I will send full series after next merge window is closed.
> 
> I think there might still be rc8 thus another week.

Indeed. I will send full series, soon.

> 
> >Anyway, I'd like to confirm that following incremental patch will solve
> >your concern.
> 
> Yeah that should work, as long as single cma areas don't include multiple 
> nodes?

Single cma areas cannot include multiple nodes at least until now.
There is a check that single cma area is on a single zone.

Thanks.

> 
> >Thanks.
> >
> >
> >-->8--
> > mm/cma.c | 25 -
> > 1 file changed, 16 insertions(+), 9 deletions(-)
> >
> >diff --git a/mm/cma.c b/mm/cma.c
> >index d69bdf7..8375554 100644
> >--- a/mm/cma.c
> >+++ b/mm/cma.c
> >@@ -146,22 +146,29 @@ static int __init cma_init_reserved_areas(void)
> > {
> >int i;
> >struct zone *zone;
> >-   unsigned long start_pfn = UINT_MAX, end_pfn = 0;
> >+   pg_data_t *pgdat;
> >
> >if (!cma_area_count)
> >return 0;
> >
> >-   for (i = 0; i < cma_area_count; i++) {
> >-   if (start_pfn > cma_areas[i].base_pfn)
> >-   start_pfn = cma_areas[i].base_pfn;
> >-   if (end_pfn < cma_areas[i].base_pfn + cma_areas[i].count)
> >-   end_pfn = cma_areas[i].base_pfn + cma_areas[i].count;
> >-   }
> >+   for_each_online_pgdat(pgdat) {
> >+   unsigned long start_pfn = UINT_MAX, end_pfn = 0;
> >
> >-   for_each_zone(zone) {
> >-   if (!is_zone_cma(zone))
> >+   for (i = 0; i < cma_area_count; i++) {
> >+   if (page_to_nid(pfn_to_page(cma_areas[i].base_pfn)) 
> >!=
> 
> We have pfn_to_nid() (although the implementation is just like this).

Will fix.

Thanks.

Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

[Krzysztof Hałasa]

Andrey Utkin  writes:

> Lockup happens only on 6010. In provided log you can see that 6110
> passes just fine right before 6010. Also if 6010 PCI ID is removed from
> solo6x10 driver's devices list, the freeze doesn't happen.

Probably explains why I don't see lockups :-)

I will have a look.
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

Re: [PATCH v2] UFS: Date Segment only need for WRITE DESCRIPTOR

[Martin K. Petersen]

> "Subhash" == subhashj   writes:

Subhash> Looks good to me.

> - /* Data segment length */
> - ucd_req_ptr->header.dword_2 = UPIU_HEADER_DWORD(
> - 0, 0, len >> 8, (u8)len);
> + /* Data segment length only need for WRITE_DESC */
> + if (query->request.upiu_req.opcode == UPIU_QUERY_OPCODE_WRITE_DESC)
> + ucd_req_ptr->header.dword_2 =
> + UPIU_HEADER_DWORD(0, 0, (len >> 8), (u8)len);
> + else
> + ucd_req_ptr->header.dword_2 = 0;

What about READ_DESC?

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCHv2] MAINTAINERS: Update open-iscsi maintainers

[Martin K. Petersen]

> "Lee" == Lee Duncan  writes:

Lee> Yes, that would be great. Thank you.

Applied to 4.9/scsi-queue.

>> Is it your plan to go through the SCSI tree?

Lee> Yes, the iscsi initiator kernel code updates have been going
Lee> through the Linux SCSI mailing list and repository for a while,
Lee> now.

Yep. Just wanted to make sure.

Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event

[Borislav Petkov]

On Tue, Sep 27, 2016 at 07:45:56AM -0400, Prarit Bhargava wrote:
> Yes.  But *where* is it relative to the cores and socket(s)?

And you need that information because...

> > If you need to show the package id, you still iterate over the core
> > numbers in an increasing order and show '*' for the offlined ones.
> > 
> 
> Explain this in more detail please?

Just s/package id/core id/ and then it makes sense - I meant "core id".

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

Re: [PATCH] scsi: be2iscsi: mark symbols static where possible

[Martin K. Petersen]

> "Baoyou" == Baoyou Xie  writes:

Baoyou> We get 6 warnings when building kernel with W=1:
Baoyou> drivers/scsi/be2iscsi/be_main.c:65:1: warning: no previous
Baoyou> prototype for 'beiscsi_log_enable_disp' [-Wmissing-prototypes]
Baoyou> drivers/scsi/be2iscsi/be_main.c:78:1: warning: no previous
Baoyou> prototype for 'beiscsi_log_enable_change' [-Wmissing-prototypes]
Baoyou> drivers/scsi/be2iscsi/be_main.c:97:1: warning: no previous
Baoyou> prototype for 'beiscsi_log_enable_store' [-Wmissing-prototypes]
Baoyou> drivers/scsi/be2iscsi/be_main.c:116:1: warning: no previous
Baoyou> prototype for 'beiscsi_log_enable_init' [-Wmissing-prototypes]
Baoyou> drivers/scsi/be2iscsi/be_main.c:4587:5: warning: no previous
Baoyou> prototype for 'beiscsi_iotask_v2' [-Wmissing-prototypes]
Baoyou> drivers/scsi/be2iscsi/be_main.c:4976:6: warning: no previous
Baoyou> prototype for 'beiscsi_hba_attrs_init' [-Wmissing-prototypes]

Applied to 4.9/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event

[Borislav Petkov]

On Tue, Sep 27, 2016 at 11:26:14AM -0400, Prarit Bhargava wrote:
> I see now that the issue is not understanding the difference between physical
> and soft thread removal.  I will write that up and get back to everyone.

No need - we understand the issue.

What I don't understand is what information you need *exactly* in sysfs
from the offlined cores and why. Something like "I need to know the id
of the thread on core X on socket Y because..."

I've been trying to get it out of you but I've failed so far at it.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

RE: [PATCH] i2c: imx: defer probe if bus recovery GPIOs are not ready

[Leo Li]

> -Original Message-
> From: Stefan Agner [mailto:ste...@agner.ch]
> Sent: Monday, September 26, 2016 7:19 PM
> To: w...@the-dreams.de
> Cc: Leo Li ; linux-...@vger.kernel.org; u.kleine-
> koe...@pengutronix.de; linux-kernel@vger.kernel.org; Stefan Agner
> 
> Subject: [PATCH] i2c: imx: defer probe if bus recovery GPIOs are not ready
> 
> Some SoC might load the GPIO driver after the I2C driver and
> using the I2C bus recovery mechanism via GPIOs. In this case
> it is crucial to defer probing if the GPIO request functions
> do so, otherwise the I2C driver gets loaded without recovery
> mechanisms enabled.
> 
> Signed-off-by: Stefan Agner 

Acked-by: Li Yang 

> ---
> This is an actual issue on NXP Vybrid devices on which the GPIO
> driver gets loaded rather later.
> 
> --
> Stefan
> 
>  drivers/i2c/busses/i2c-imx.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index 592a8f2..47fc1f1 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -1009,10 +1009,13 @@ static int i2c_imx_init_recovery_info(struct
> imx_i2c_struct *i2c_imx,
>   rinfo->sda_gpio = of_get_named_gpio(pdev->dev.of_node, "sda-gpios",
> 0);
>   rinfo->scl_gpio = of_get_named_gpio(pdev->dev.of_node, "scl-gpios",
> 0);
> 
> - if (!gpio_is_valid(rinfo->sda_gpio) ||
> - !gpio_is_valid(rinfo->scl_gpio) ||
> - IS_ERR(i2c_imx->pinctrl_pins_default) ||
> - IS_ERR(i2c_imx->pinctrl_pins_gpio)) {
> + if (rinfo->sda_gpio == -EPROBE_DEFER ||
> + rinfo->scl_gpio == -EPROBE_DEFER) {
> + return -EPROBE_DEFER;
> + } else if (!gpio_is_valid(rinfo->sda_gpio) ||
> +!gpio_is_valid(rinfo->scl_gpio) ||
> +IS_ERR(i2c_imx->pinctrl_pins_default) ||
> +IS_ERR(i2c_imx->pinctrl_pins_gpio)) {
>   dev_dbg(&pdev->dev, "recovery information incomplete\n");
>   return 0;
>   }
> --
> 2.10.0

Re: [PATCH v2] pinctrl: Add SX150X GPIO Extender Pinctrl Driver

[Peter Rosin]

On 2016-09-27 17:48, Neil Armstrong wrote:
> Since the I2C sx150x GPIO expander driver uses platform_data to manage
> the pins configurations, rewrite the driver as a pinctrl driver using
> pinconf to get/set pin configurations from DT or debugfs.
> 
> The pinctrl driver is functionnally equivalent as the gpio-only driver
> and can use DT for pinconf. The platform_data confirmation is dropped.
> 
> This patchset removed the gpio-only driver and selects the Pinctrl driver
> config instead. This patchset also migrates the gpio dt-bindings to pinctrl
> and add the pinctrl optional properties.
> 
> The driver was tested with a SX1509 device on a BeagleBone black with
> interrupt support and on an X86_64 machine over an I2C to USB converter.
> 
> Signed-off-by: Neil Armstrong 

Works here for sx1502 (without interrupts) on a custom arm board (SAMA5D3).

Tested-by: Peter Rosin 

Cheers,
Peter

linux-next: manual merge of the staging tree with the vfs-miklos tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in:

  drivers/staging/lustre/lustre/llite/file.c

between commit:

  302d50e7203e ("switch generic_file_splice_read() to use of ->read_iter()")

from the vfs-miklos tree and commits:

  5b8a39c53a16 ("staging: lustre: llite: Replace write mutex with range lock")
  ee5532436a7d ("staging: lustre: lov: remove LL_IOC_RECREATE_{FID, OBJ}")

from the staging tree.

I fixed it up (I think - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/staging/lustre/lustre/llite/file.c
index d1d1efac1431,6e3a188baaae..
--- a/drivers/staging/lustre/lustre/llite/file.c
+++ b/drivers/staging/lustre/lustre/llite/file.c
@@@ -1141,8 -1121,8 +1121,8 @@@ ll_file_io_generic(const struct lu_env 
struct cl_io *io;
ssize_tresult;
  
-   CDEBUG(D_VFSTRACE, "file: %pD, type: %d ppos: %llu, count: %zd\n",
 -  CDEBUG(D_VFSTRACE, "file: %s, type: %d ppos: %llu, count: %zu\n",
 - file->f_path.dentry->d_name.name, iot, *ppos, count);
++  CDEBUG(D_VFSTRACE, "file: %pD, type: %d ppos: %llu, count: %zu\n",
 + file, iot, *ppos, count);
  
  restart:
io = vvp_env_thread_io(env);
@@@ -1150,26 -1130,59 +1130,45 @@@
  
if (cl_io_rw_init(env, io, iot, *ppos, count) == 0) {
struct vvp_io *vio = vvp_env_io(env);
-   int write_mutex_locked = 0;
+   bool range_locked = false;
+ 
+   if (file->f_flags & O_APPEND)
+   range_lock_init(&range, 0, LUSTRE_EOF);
+   else
+   range_lock_init(&range, *ppos, *ppos + count - 1);
  
vio->vui_fd  = LUSTRE_FPRIVATE(file);
 -  vio->vui_io_subtype = args->via_io_subtype;
 +  vio->vui_iter = args->u.normal.via_iter;
 +  vio->vui_iocb = args->u.normal.via_iocb;
-   if ((iot == CIT_WRITE) &&
++  /*
++   * Direct IO reads must also take range lock,
++   * or multiple reads will try to work on the same pages
++   * See LU-6227 for details.
++   */
++  if (((iot == CIT_WRITE) ||
++   (iot == CIT_READ && (file->f_flags & O_DIRECT))) &&
 +  !(vio->vui_fd->fd_flags & LL_FILE_GROUP_LOCKED)) {
-   if (mutex_lock_interruptible(&lli->lli_write_mutex)) {
-   result = -ERESTARTSYS;
++  CDEBUG(D_VFSTRACE, "Range lock [%llu, %llu]\n",
++ range.rl_node.in_extent.start,
++ range.rl_node.in_extent.end);
++  result = range_lock(&lli->lli_write_tree,
++  &range);
++  if (result < 0)
 +  goto out;
-   }
-   write_mutex_locked = 1;
+ 
 -  switch (vio->vui_io_subtype) {
 -  case IO_NORMAL:
 -  vio->vui_iter = args->u.normal.via_iter;
 -  vio->vui_iocb = args->u.normal.via_iocb;
 -  /*
 -   * Direct IO reads must also take range lock,
 -   * or multiple reads will try to work on the same pages
 -   * See LU-6227 for details.
 -   */
 -  if (((iot == CIT_WRITE) ||
 -   (iot == CIT_READ && (file->f_flags & O_DIRECT))) &&
 -  !(vio->vui_fd->fd_flags & LL_FILE_GROUP_LOCKED)) {
 -  CDEBUG(D_VFSTRACE, "Range lock [%llu, %llu]\n",
 - range.rl_node.in_extent.start,
 - range.rl_node.in_extent.end);
 -  result = range_lock(&lli->lli_write_tree,
 -  &range);
 -  if (result < 0)
 -  goto out;
 -
 -  range_locked = true;
 -  }
 -  down_read(&lli->lli_trunc_sem);
 -  break;
 -  case IO_SPLICE:
 -  vio->u.splice.vui_pipe = args->u.splice.via_pipe;
 -  vio->u.splice.vui_flags = args->u.splice.via_flags;
 -  break;
 -  default:
 -  CERROR("Unknown IO type - %u\n", vio->vui_io_subtype);
 -  LBUG();
++  range_locked = true;
   

Re: [PATCH 2/2] hid: input: add HID_QUIRK_REUSE_AXES and fix dragonrise

[Vladislav Naumov]

On Tue, Sep 27, 2016 at 10:44 PM, Ioan-Adrian Ratiu  wrote:
> Can you please wait a little until I post v2 later today and test v2
> directly? Because the change in it's current form has no effect on
> 0079:0011 (the current quirk is enabled only for 0006).

Sure thing!
Just drop me a line when it's ready.

Re: [PATCH v3 00/11] re-enable DAX PMD support

[Dave Chinner]

On Tue, Sep 27, 2016 at 07:08:42PM -0700, Christoph Hellwig wrote:
> On Tue, Sep 27, 2016 at 02:47:51PM -0600, Ross Zwisler wrote:
> > DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
> > locking.  This series allows DAX PMDs to participate in the DAX radix tree
> > based locking scheme so that they can be re-enabled.
> > 
> > Jan and Christoph, can you please help review these changes?
> 
> About to get on a plane, so it might take a bit to do a real review.
> In general this looks fine, but I guess the first two ext4 patches
> should just go straight to Ted independent of the rest?
> 
> Also Jan just posted a giant DAX patchbomb, we'll need to find a way
> to integrate all that work, and maybe prioritize things if we want
> to get bits into 4.9 still.

I'm not going to have time to do much review or testing of the DAX
changes (apart from the cursor comments I've already made) because
of the huge pile of XFS reflink changes I've got ot get through
first. However, I've already got the iomap dax bits in the XFS tree
so I can pull everything through there if review and testing is
covered otherwise..

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCH] pinctrl: freescale: avoid overwriting pin config when freeing GPIO

[Viresh Kumar]

On 27-09-16, 20:38, Stefan Agner wrote:
> The i.MX I2C driver touches the pinctrl in its prepare/unprepare
> callbacks.
> 
> So, on a i.MX or Vybrid, the call chain looks like this:
> 
> i2c_generic_gpio_recovery
> -> i2c_get_gpios_for_recovery
>-> gpio_request_one
> -> i2c_generic_recovery
>-> prepare_recovery (i2c_imx_prepare_recovery)
>   -> pinctrl_select_state [gpio]

Why is this done here? And not in gpio_request_one?

>-> unprepare_recovery (i2c_imx_unprepare_recovery)
>   -> pinctrl_select_state [default]
> -> i2c_put_gpios_for_recovery
>-> gpio_free
> 
> 
> And for the pinctrl/GPIO driver of Vybrid this is actually a problem
> because gpio_free disables the output driver of the pad, and when that
> happens after the (I2C) default pinctrl state gets selected the pad is
> no longer active.
> 
> --
> Stefan

-- 
viresh

[PATCH] perf tools: Fix building in 32 bit platform

[Wang Nan]

On ARM32 building it report following error:

util/data-convert-bt.c: In function 'add_bpf_output_values':
util/data-convert-bt.c:440:3: error: format '%lu' expects argument of type 
'long unsigned int', but argument 5 has type 'unsigned int' [-Werror=format]
cc1: all warnings being treated as errors

Fix it by changing %lu to %zu.

Signed-off-by: Wang Nan 
Cc: Arnaldo Carvalho de Melo 
Cc: Jiri Olsa 
---
 tools/perf/util/data-convert-bt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/data-convert-bt.c 
b/tools/perf/util/data-convert-bt.c
index 4f979bb..7123f4d 100644
--- a/tools/perf/util/data-convert-bt.c
+++ b/tools/perf/util/data-convert-bt.c
@@ -437,7 +437,7 @@ add_bpf_output_values(struct bt_ctf_event_class 
*event_class,
int ret;
 
if (nr_elements * sizeof(u32) != raw_size)
-   pr_warning("Incorrect raw_size (%u) in bpf output event, skip 
%lu bytes\n",
+   pr_warning("Incorrect raw_size (%u) in bpf output event, skip 
%zu bytes\n",
   raw_size, nr_elements * sizeof(u32) - raw_size);
 
len_type = bt_ctf_event_class_get_field_by_name(event_class, "raw_len");
-- 
1.8.3.4

[PATCH 3/3] bindings: add compatible "fsl,ls1043-ucc-hdlc" to bindings

[Zhao Qiang]

Signed-off-by: Zhao Qiang 
---
 Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt 
b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt
index 03c7416..325e3e2 100644
--- a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt
+++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt
@@ -45,7 +45,7 @@ Example:
 * HDLC
 
 Currently defined compatibles:
-- fsl,ucc-hdlc
+- "fsl,ucc-hdlc", "fsl,ls1043-ucc-hdlc"
 
 Properties for fsl,ucc-hdlc:
 - rx-clock-name
-- 
2.1.0.27.g96db324

[PATCH v6 2/4] irqchip/qeic: merge qeic init code from platforms to a common function

[Zhao Qiang]

The codes of qe_ic init from a variety of platforms are redundant,
merge them to a common function and put it to irqchip/irq-qeic.c

For non-p1021_mds mpc85xx_mds boards, use "qe_ic_init(np, 0,
qe_ic_cascade_low_mpic, qe_ic_cascade_high_mpic);" instead of
"qe_ic_init(np, 0, qe_ic_cascade_muxed_mpic, NULL);".

qe_ic_cascade_muxed_mpic was used for boards has the same interrupt
number for low interrupt and high interrupt, qe_ic_init has checked
if "low interrupt == high interrupt"

Signed-off-by: Zhao Qiang 
---
Changes for v2:
- modify subject and commit msg
- add check for qeic by type
Changes for v3:
- na
Changes for v4:
- na
Changes for v5:
- na
Changes for v6:
- rebase

 arch/powerpc/platforms/83xx/misc.c| 15 ---
 arch/powerpc/platforms/85xx/corenet_generic.c |  9 -
 arch/powerpc/platforms/85xx/mpc85xx_mds.c | 14 --
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 16 
 arch/powerpc/platforms/85xx/twr_p102x.c   | 14 --
 drivers/irqchip/irq-qeic.c| 16 
 6 files changed, 16 insertions(+), 68 deletions(-)

diff --git a/arch/powerpc/platforms/83xx/misc.c 
b/arch/powerpc/platforms/83xx/misc.c
index d75c981..c09a135 100644
--- a/arch/powerpc/platforms/83xx/misc.c
+++ b/arch/powerpc/platforms/83xx/misc.c
@@ -93,24 +93,9 @@ void __init mpc83xx_ipic_init_IRQ(void)
 }
 
 #ifdef CONFIG_QUICC_ENGINE
-void __init mpc83xx_qe_init_IRQ(void)
-{
-   struct device_node *np;
-
-   np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
-   if (!np) {
-   np = of_find_node_by_type(NULL, "qeic");
-   if (!np)
-   return;
-   }
-   qe_ic_init(np, 0, qe_ic_cascade_low_ipic, qe_ic_cascade_high_ipic);
-   of_node_put(np);
-}
-
 void __init mpc83xx_ipic_and_qe_init_IRQ(void)
 {
mpc83xx_ipic_init_IRQ();
-   mpc83xx_qe_init_IRQ();
 }
 #endif /* CONFIG_QUICC_ENGINE */
 
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c 
b/arch/powerpc/platforms/85xx/corenet_generic.c
index 1179115..1d96c3f 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -41,8 +41,6 @@ void __init corenet_gen_pic_init(void)
unsigned int flags = MPIC_BIG_ENDIAN | MPIC_SINGLE_DEST_CPU |
MPIC_NO_RESET;
 
-   struct device_node *np;
-
if (ppc_md.get_irq == mpic_get_coreint_irq)
flags |= MPIC_ENABLE_COREINT;
 
@@ -50,13 +48,6 @@ void __init corenet_gen_pic_init(void)
BUG_ON(mpic == NULL);
 
mpic_init(mpic);
-
-   np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
-   if (np) {
-   qe_ic_init(np, 0, qe_ic_cascade_low_mpic,
-   qe_ic_cascade_high_mpic);
-   of_node_put(np);
-   }
 }
 
 /*
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c 
b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index d7e440e..06f34a9 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -283,20 +283,6 @@ static void __init mpc85xx_mds_qeic_init(void)
of_node_put(np);
return;
}
-
-   np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
-   if (!np) {
-   np = of_find_node_by_type(NULL, "qeic");
-   if (!np)
-   return;
-   }
-
-   if (machine_is(p1021_mds))
-   qe_ic_init(np, 0, qe_ic_cascade_low_mpic,
-   qe_ic_cascade_high_mpic);
-   else
-   qe_ic_init(np, 0, qe_ic_cascade_muxed_mpic, NULL);
-   of_node_put(np);
 }
 #else
 static void __init mpc85xx_mds_qe_init(void) { }
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c 
b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index 1006950..000d385 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -48,10 +48,6 @@ void __init mpc85xx_rdb_pic_init(void)
 {
struct mpic *mpic;
 
-#ifdef CONFIG_QUICC_ENGINE
-   struct device_node *np;
-#endif
-
if (of_machine_is_compatible("fsl,MPC85XXRDB-CAMP")) {
mpic = mpic_alloc(NULL, 0, MPIC_NO_RESET |
MPIC_BIG_ENDIAN |
@@ -66,18 +62,6 @@ void __init mpc85xx_rdb_pic_init(void)
 
BUG_ON(mpic == NULL);
mpic_init(mpic);
-
-#ifdef CONFIG_QUICC_ENGINE
-   np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
-   if (np) {
-   qe_ic_init(np, 0, qe_ic_cascade_low_mpic,
-   qe_ic_cascade_high_mpic);
-   of_node_put(np);
-
-   } else
-   pr_err("%s: Could not find qe-ic node\n", __func__);
-#endif
-
 }
 
 /*
diff --git a/arch/powerpc/platforms/85xx/twr_p102x.c 
b/arch/powerpc/platforms/85xx/twr_p102x.c
index 360f625..6be9b33 100644
--- a/arch/powerpc/platforms/85xx/twr

[PATCH 2/3] ls1043ardb: add ds26522 node to dts

[Zhao Qiang]

add ds26522 node to fsl-ls1043a-rdb.dts

Signed-off-by: Zhao Qiang 
---
 arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
index 4fc60e7..206a8f5 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
@@ -122,6 +122,22 @@
reg = <0>;
spi-max-frequency = <100>; /* input clock */
};
+
+   slic@2 {
+   compatible = "maxim,ds26522";
+   reg = <2>;
+   spi-max-frequency = <200>;
+   fsl,spi-cs-sck-delay = <100>;
+   fsl,spi-sck-cs-delay = <50>;
+   };
+
+   slic@3 {
+   compatible = "maxim,ds26522";
+   reg = <3>;
+   spi-max-frequency = <200>;
+   fsl,spi-cs-sck-delay = <100>;
+   fsl,spi-sck-cs-delay = <50>;
+   };
 };
 
 &uqe {
-- 
2.1.0.27.g96db324

[PATCH 1/3] ls1043ardb: add qe node to ls1043ardb

[Zhao Qiang]

Signed-off-by: Zhao Qiang 
---
 arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 16 ++
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi| 66 +++
 2 files changed, 82 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
index 4084631..4fc60e7 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
@@ -124,6 +124,22 @@
};
 };
 
+&uqe {
+   ucc_hdlc: ucc@2000 {
+   compatible = "fsl,ls1043-ucc-hdlc", "fsl,ucc-hdlc";
+   rx-clock-name = "clk8";
+   tx-clock-name = "clk9";
+   fsl,rx-sync-clock = "rsync_pin";
+   fsl,tx-sync-clock = "tsync_pin";
+   fsl,tx-timeslot-mask = <0xfffe>;
+   fsl,rx-timeslot-mask = <0xfffe>;
+   fsl,tdm-framer-type = "e1";
+   fsl,tdm-id = <0>;
+   fsl,siram-entry-id = <0>;
+   fsl,tdm-interface;
+   };
+};
+
 &duart0 {
status = "okay";
 };
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index e669fbd..f6b6775 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -388,6 +388,72 @@
#interrupt-cells = <2>;
};
 
+   uqe: uqe@240 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   device_type = "qe";
+   compatible = "fsl,qe", "simple-bus";
+   ranges = <0x0 0x0 0x240 0x4>;
+   reg = <0x0 0x240 0x0 0x480>;
+   brg-frequency = <1>;
+   bus-frequency = <2>;
+
+   fsl,qe-num-riscs = <1>;
+   fsl,qe-num-snums = <28>;
+
+   qeic: qeic@80 {
+   compatible = "fsl,qe-ic";
+   reg = <0x80 0x80>;
+   #address-cells = <0>;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   interrupts = <0 77 0x04 0 77 0x04>;
+   };
+
+   si1: si@700 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,ls1043-qe-si",
+   "fsl,t1040-qe-si";
+   reg = <0x700 0x80>;
+   };
+
+   siram1: siram@1000 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "fsl,ls1043-qe-siram",
+   "fsl,t1040-qe-siram";
+   reg = <0x1000 0x800>;
+   };
+
+   ucc@2000 {
+   cell-index = <1>;
+   reg = <0x2000 0x200>;
+   interrupts = <32>;
+   interrupt-parent = <&qeic>;
+   };
+
+   ucc@2200 {
+   cell-index = <3>;
+   reg = <0x2200 0x200>;
+   interrupts = <34>;
+   interrupt-parent = <&qeic>;
+   };
+
+   muram@1 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "fsl,qe-muram", "fsl,cpm-muram";
+   ranges = <0x0 0x1 0x6000>;
+
+   data-only@0 {
+   compatible = "fsl,qe-muram-data",
+   "fsl,cpm-muram-data";
+   reg = <0x0 0x6000>;
+   };
+   };
+   };
+
lpuart0: serial@295 {
compatible = "fsl,ls1021a-lpuart";
reg = <0x0 0x295 0x0 0x1000>;
-- 
2.1.0.27.g96db324

[PATCH v6 4/4] irqchip/qeic: remove PPCisms for QEIC

[Zhao Qiang]

QEIC was supported on PowerPC, and dependent on PPC,
Now it is supported on other platforms, so remove PPCisms.

Signed-off-by: Zhao Qiang 
---
Changes for v6:
- new added

 drivers/irqchip/irq-qeic.c | 28 +---
 include/soc/fsl/qe/qe_ic.h | 12 ++--
 2 files changed, 23 insertions(+), 17 deletions(-)

diff --git a/drivers/irqchip/irq-qeic.c b/drivers/irqchip/irq-qeic.c
index 4f49d4b..98a8b38 100644
--- a/drivers/irqchip/irq-qeic.c
+++ b/drivers/irqchip/irq-qeic.c
@@ -18,7 +18,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -266,13 +269,13 @@ static struct qe_ic_info qe_ic_info[] = {
 
 static inline u32 qe_ic_read(volatile __be32  __iomem * base, unsigned int reg)
 {
-   return in_be32(base + (reg >> 2));
+   return ioread32be(base + (reg >> 2));
 }
 
 static inline void qe_ic_write(volatile __be32  __iomem * base, unsigned int 
reg,
   u32 value)
 {
-   out_be32(base + (reg >> 2), value);
+   iowrite32be(value, base + (reg >> 2));
 }
 
 static inline struct qe_ic *qe_ic_from_irq(unsigned int virq)
@@ -374,7 +377,7 @@ static const struct irq_domain_ops qe_ic_host_ops = {
.xlate = irq_domain_xlate_onetwocell,
 };
 
-/* Return an interrupt vector or NO_IRQ if no interrupt is pending. */
+/* Return an interrupt vector or 0 if no interrupt is pending. */
 unsigned int qe_ic_get_low_irq(struct qe_ic *qe_ic)
 {
int irq;
@@ -385,12 +388,12 @@ unsigned int qe_ic_get_low_irq(struct qe_ic *qe_ic)
irq = qe_ic_read(qe_ic->regs, QEIC_CIVEC) >> 26;
 
if (irq == 0)
-   return NO_IRQ;
+   return 0;
 
return irq_linear_revmap(qe_ic->irqhost, irq);
 }
 
-/* Return an interrupt vector or NO_IRQ if no interrupt is pending. */
+/* Return an interrupt vector or 0 if no interrupt is pending. */
 unsigned int qe_ic_get_high_irq(struct qe_ic *qe_ic)
 {
int irq;
@@ -401,7 +404,7 @@ unsigned int qe_ic_get_high_irq(struct qe_ic *qe_ic)
irq = qe_ic_read(qe_ic->regs, QEIC_CHIVEC) >> 26;
 
if (irq == 0)
-   return NO_IRQ;
+   return 0;
 
return irq_linear_revmap(qe_ic->irqhost, irq);
 }
@@ -447,7 +450,7 @@ static int __init qe_ic_init(unsigned int flags)
qe_ic->virq_high = irq_of_parse_and_map(node, 0);
qe_ic->virq_low = irq_of_parse_and_map(node, 1);
 
-   if (qe_ic->virq_low == NO_IRQ) {
+   if (qe_ic->virq_low == 0) {
pr_err("Failed to map QE_IC low IRQ\n");
ret = -ENOMEM;
goto err_domain_remove;
@@ -479,7 +482,7 @@ static int __init qe_ic_init(unsigned int flags)
irq_set_handler_data(qe_ic->virq_low, qe_ic);
irq_set_chained_handler(qe_ic->virq_low, qe_ic_cascade_low_mpic);
 
-   if (qe_ic->virq_high != NO_IRQ &&
+   if (qe_ic->virq_high != 0 &&
qe_ic->virq_high != qe_ic->virq_low) {
irq_set_handler_data(qe_ic->virq_high, qe_ic);
irq_set_chained_handler(qe_ic->virq_high,
@@ -500,7 +503,8 @@ err_put_node:
 void qe_ic_set_highest_priority(unsigned int virq, int high)
 {
struct qe_ic *qe_ic = qe_ic_from_irq(virq);
-   unsigned int src = virq_to_hw(virq);
+   struct irq_data *irq_data = irq_get_irq_data(virq);
+   irq_hw_number_t src = WARN_ON(!irq_data) ? 0 : irq_data->hwirq;
u32 temp = 0;
 
temp = qe_ic_read(qe_ic->regs, QEIC_CICR);
@@ -518,7 +522,8 @@ void qe_ic_set_highest_priority(unsigned int virq, int high)
 int qe_ic_set_priority(unsigned int virq, unsigned int priority)
 {
struct qe_ic *qe_ic = qe_ic_from_irq(virq);
-   unsigned int src = virq_to_hw(virq);
+   struct irq_data *irq_data = irq_get_irq_data(virq);
+   irq_hw_number_t src = WARN_ON(!irq_data) ? 0 : irq_data->hwirq;
u32 temp;
 
if (priority > 8 || priority == 0)
@@ -548,7 +553,8 @@ int qe_ic_set_priority(unsigned int virq, unsigned int 
priority)
 int qe_ic_set_high_priority(unsigned int virq, unsigned int priority, int high)
 {
struct qe_ic *qe_ic = qe_ic_from_irq(virq);
-   unsigned int src = virq_to_hw(virq);
+   struct irq_data *irq_data = irq_get_irq_data(virq);
+   irq_hw_number_t src = WARN_ON(!irq_data) ? 0 : irq_data->hwirq;
u32 temp, control_reg = QEIC_CICNR, shift = 0;
 
if (priority > 2 || priority == 0)
diff --git a/include/soc/fsl/qe/qe_ic.h b/include/soc/fsl/qe/qe_ic.h
index 6113699..863cfec 100644
--- a/include/soc/fsl/qe/qe_ic.h
+++ b/include/soc/fsl/qe/qe_ic.h
@@ -76,7 +76,7 @@ static inline void qe_ic_cascade_low_ipic(struct irq_desc 
*desc)
struct qe_ic *qe_ic = irq_desc_get_handler_data(desc);
unsigned int cascade_irq = qe_ic_get_low_irq(qe_ic);
 
-   if (cascade_irq != NO_IRQ)
+   if (cascade_irq != 0)
generic_handle_irq(cascade_irq);
 }
 
@@ -85,7 +85,7 @@ static inline void qe_ic_

[PATCH v6 1/4] irqchip/qeic: move qeic driver from drivers/soc/fsl/qe

[Zhao Qiang]

move the driver from drivers/soc/fsl/qe to drivers/irqchip,
merge qe_ic.h and qe_ic.c into irq-qeic.c.

Signed-off-by: Zhao Qiang 
---
Changes for v2:
- modify the subject and commit msg
Changes for v3:
- merge .h file to .c, rename it with irq-qeic.c
Changes for v4:
- modify comments
Changes for v5:
- disable rename detection
Changes for v6:
- rebase

 drivers/irqchip/Makefile   |   1 +
 drivers/{soc/fsl/qe/qe_ic.c => irqchip/irq-qeic.c} |  95 ++-
 drivers/soc/fsl/qe/Makefile|   2 +-
 drivers/soc/fsl/qe/qe_ic.h | 103 -
 4 files changed, 94 insertions(+), 107 deletions(-)
 rename drivers/{soc/fsl/qe/qe_ic.c => irqchip/irq-qeic.c} (85%)
 delete mode 100644 drivers/soc/fsl/qe/qe_ic.h

diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 4c203b6..face608 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -71,3 +71,4 @@ obj-$(CONFIG_MVEBU_ODMI)  += irq-mvebu-odmi.o
 obj-$(CONFIG_LS_SCFG_MSI)  += irq-ls-scfg-msi.o
 obj-$(CONFIG_EZNPS_GIC)+= irq-eznps.o
 obj-$(CONFIG_ARCH_ASPEED)  += irq-aspeed-vic.o
+obj-$(CONFIG_QUICC_ENGINE) += irq-qeic.o
diff --git a/drivers/soc/fsl/qe/qe_ic.c b/drivers/irqchip/irq-qeic.c
similarity index 85%
rename from drivers/soc/fsl/qe/qe_ic.c
rename to drivers/irqchip/irq-qeic.c
index ec2ca86..48ceded 100644
--- a/drivers/soc/fsl/qe/qe_ic.c
+++ b/drivers/irqchip/irq-qeic.c
@@ -1,7 +1,7 @@
 /*
- * arch/powerpc/sysdev/qe_lib/qe_ic.c
+ * drivers/irqchip/irq-qeic.c
  *
- * Copyright (C) 2006 Freescale Semiconductor, Inc.  All rights reserved.
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.  All rights reserved.
  *
  * Author: Li Yang 
  * Based on code from Shlomi Gridish 
@@ -30,7 +30,96 @@
 #include 
 #include 
 
-#include "qe_ic.h"
+#define NR_QE_IC_INTS  64
+
+/* QE IC registers offset */
+#define QEIC_CICR  0x00
+#define QEIC_CIVEC 0x04
+#define QEIC_CRIPNR0x08
+#define QEIC_CIPNR 0x0c
+#define QEIC_CIPXCC0x10
+#define QEIC_CIPYCC0x14
+#define QEIC_CIPWCC0x18
+#define QEIC_CIPZCC0x1c
+#define QEIC_CIMR  0x20
+#define QEIC_CRIMR 0x24
+#define QEIC_CICNR 0x28
+#define QEIC_CIPRTA0x30
+#define QEIC_CIPRTB0x34
+#define QEIC_CRICR 0x3c
+#define QEIC_CHIVEC0x60
+
+/* Interrupt priority registers */
+#define CIPCC_SHIFT_PRI0   29
+#define CIPCC_SHIFT_PRI1   26
+#define CIPCC_SHIFT_PRI2   23
+#define CIPCC_SHIFT_PRI3   20
+#define CIPCC_SHIFT_PRI4   13
+#define CIPCC_SHIFT_PRI5   10
+#define CIPCC_SHIFT_PRI6   7
+#define CIPCC_SHIFT_PRI7   4
+
+/* CICR priority modes */
+#define CICR_GWCC  0x0004
+#define CICR_GXCC  0x0002
+#define CICR_GYCC  0x0001
+#define CICR_GZCC  0x0008
+#define CICR_GRTA  0x0020
+#define CICR_GRTB  0x0040
+#define CICR_HPIT_SHIFT8
+#define CICR_HPIT_MASK 0x0300
+#define CICR_HP_SHIFT  24
+#define CICR_HP_MASK   0x3f00
+
+/* CICNR */
+#define CICNR_WCC1T_SHIFT  20
+#define CICNR_ZCC1T_SHIFT  28
+#define CICNR_YCC1T_SHIFT  12
+#define CICNR_XCC1T_SHIFT  4
+
+/* CRICR */
+#define CRICR_RTA1T_SHIFT  20
+#define CRICR_RTB1T_SHIFT  28
+
+/* Signal indicator */
+#define SIGNAL_MASK3
+#define SIGNAL_HIGH2
+#define SIGNAL_LOW 0
+
+struct qe_ic {
+   /* Control registers offset */
+   volatile u32 __iomem *regs;
+
+   /* The remapper for this QEIC */
+   struct irq_domain *irqhost;
+
+   /* The "linux" controller struct */
+   struct irq_chip hc_irq;
+
+   /* VIRQ numbers of QE high/low irqs */
+   unsigned int virq_high;
+   unsigned int virq_low;
+};
+
+/*
+ * QE interrupt controller internal structure
+ */
+struct qe_ic_info {
+   /* location of this source at the QIMR register. */
+   u32 mask;
+
+   /* Mask register offset */
+   u32 mask_reg;
+
+   /*
+* for grouped interrupts sources - the interrupt
+* code as appears at the group priority register
+*/
+   u8  pri_code;
+
+   /* Group priority register offset */
+   u32 pri_reg;
+};
 
 static DEFINE_RAW_SPINLOCK(qe_ic_lock);
 
diff --git a/drivers/soc/fsl/qe/Makefile b/drivers/soc/fsl/qe/Makefile
index 2031d38..51e4726 100644
--- a/drivers/soc/fsl/qe/Makefile
+++ b/drivers/soc/fsl/qe/Makefile
@@ -1,7 +1,7 @@
 #
 # Makefile for the linux ppc-specific parts of QE
 #
-obj-$(CONFIG_QUICC_ENGINE)+= qe.o qe_common.o qe_ic.o qe_io.o
+obj-$(CONFIG_QUICC_ENGINE)+= qe.o qe_common.o qe_io.o
 obj-$(CONFIG_CPM)  += qe_common.o
 obj-$(CONFIG_UCC) 

Re: [PATCH] pinctrl: freescale: avoid overwriting pin config when freeing GPIO

[Stefan Agner]

On 2016-09-27 19:00, Viresh Kumar wrote:
> On 27-09-16, 12:34, Stefan Agner wrote:
>> Added Viresh Kumar to the discussion, he implemented the I2C recovery
>> functions.
>>
>> Yes, reordering the pinctrl/gpio_free calls would fix the problem too.
>>
>> However, I guess there is no explicit rule to that ("request/free GPIOs
>> only when they are muxed as GPIO"), so I think of it that the issue is
>> actually in the pinctrl driver.
>>
>> On top of that it is not entirely trivial to reorder the calls the way
>> i2c_generic_gpio_recovery and i2c_generic_recovery are set up right now.
> 
> AFAICT, these routines don't touch the muxing part at all. Perhaps it is done
> internally by the GPIO calls. Can you please elaborate the exact change you 
> are
> hinting towards here ?

The i.MX I2C driver touches the pinctrl in its prepare/unprepare
callbacks.

So, on a i.MX or Vybrid, the call chain looks like this:

i2c_generic_gpio_recovery
-> i2c_get_gpios_for_recovery
   -> gpio_request_one
-> i2c_generic_recovery
   -> prepare_recovery (i2c_imx_prepare_recovery)
  -> pinctrl_select_state [gpio]
   -> unprepare_recovery (i2c_imx_unprepare_recovery)
  -> pinctrl_select_state [default]
-> i2c_put_gpios_for_recovery
   -> gpio_free


And for the pinctrl/GPIO driver of Vybrid this is actually a problem
because gpio_free disables the output driver of the pad, and when that
happens after the (I2C) default pinctrl state gets selected the pad is
no longer active.

--
Stefan

[PATCH v7] QE: remove PPCisms for QE

[Zhao Qiang]

QE was supported on PowerPC, and dependent on PPC,
Now it is supported on other platforms. so remove PPCisms.

Signed-off-by: Zhao Qiang 
---
Changes for v2:
- na
Changes for v3:
- add NO_IRQ
Changes for v4:
- modify spin_event_timeout to opencoded timeout loop
- remove NO_IRQ
- modify virq_to_hw to opencoed code
Changes for v5:
- modify commit msg
- modify depends of QUICC_ENGINE
- add kerneldoc header for qe_issue_cmd
Changes for v6:
- add dependency on FSL_SOC and PPC32 for drivers
  depending on QUICC_ENGING but not available on ARM
Changes for v7:
- split qeic part to another patch
- rebase

 drivers/net/ethernet/freescale/Kconfig | 10 ++---
 drivers/soc/fsl/qe/Kconfig |  2 +-
 drivers/soc/fsl/qe/qe.c| 80 --
 drivers/soc/fsl/qe/qe_io.c | 42 --
 drivers/soc/fsl/qe/qe_tdm.c|  8 ++--
 drivers/soc/fsl/qe/ucc.c   | 10 ++---
 drivers/soc/fsl/qe/ucc_fast.c  | 68 ++---
 drivers/tty/serial/Kconfig |  2 +-
 drivers/usb/gadget/udc/Kconfig |  2 +-
 drivers/usb/host/Kconfig   |  2 +-
 include/soc/fsl/qe/qe.h|  1 -
 11 files changed, 118 insertions(+), 109 deletions(-)

diff --git a/drivers/net/ethernet/freescale/Kconfig 
b/drivers/net/ethernet/freescale/Kconfig
index d1ca45f..6677aff 100644
--- a/drivers/net/ethernet/freescale/Kconfig
+++ b/drivers/net/ethernet/freescale/Kconfig
@@ -5,10 +5,10 @@
 config NET_VENDOR_FREESCALE
bool "Freescale devices"
default y
-   depends on FSL_SOC || QUICC_ENGINE || CPM1 || CPM2 || PPC_MPC512x || \
-  M523x || M527x || M5272 || M528x || M520x || M532x || \
-  ARCH_MXC || ARCH_MXS || (PPC_MPC52xx && PPC_BESTCOMM) || \
-  ARCH_LAYERSCAPE
+   depends on FSL_SOC || (QUICC_ENGINE && PPC32) || CPM1 || CPM2 || \
+  PPC_MPC512x || M523x || M527x || M5272 || M528x || M520x || \
+  M532x || ARCH_MXC || ARCH_MXS || \
+  (PPC_MPC52xx && PPC_BESTCOMM) || ARCH_LAYERSCAPE
---help---
  If you have a network (Ethernet) card belonging to this class, say Y.
 
@@ -72,7 +72,7 @@ config FSL_XGMAC_MDIO
 
 config UCC_GETH
tristate "Freescale QE Gigabit Ethernet"
-   depends on QUICC_ENGINE
+   depends on QUICC_ENGINE && FSL_SOC && PPC32
select FSL_PQ_MDIO
select PHYLIB
---help---
diff --git a/drivers/soc/fsl/qe/Kconfig b/drivers/soc/fsl/qe/Kconfig
index 73a2e08..b26b643 100644
--- a/drivers/soc/fsl/qe/Kconfig
+++ b/drivers/soc/fsl/qe/Kconfig
@@ -4,7 +4,7 @@
 
 config QUICC_ENGINE
bool "Freescale QUICC Engine (QE) Support"
-   depends on FSL_SOC && PPC32
+   depends on OF && HAS_IOMEM
select GENERIC_ALLOCATOR
select CRC32
help
diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index 2707a82..2b53e85 100644
--- a/drivers/soc/fsl/qe/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -33,8 +33,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 
 static void qe_snums_init(void);
 static int qe_sdma_init(void);
@@ -109,15 +107,27 @@ void qe_reset(void)
panic("sdma init failed!");
 }
 
+/* issue commands to QE, return 0 on success while -EIO on error
+ *
+ * @cmd: the command code, should be QE_INIT_TX_RX, QE_STOP_TX and so on
+ * @device: which sub-block will run the command, QE_CR_SUBBLOCK_UCCFAST1 - 8
+ * , QE_CR_SUBBLOCK_UCCSLOW1 - 8, QE_CR_SUBBLOCK_MCC1 - 3,
+ * QE_CR_SUBBLOCK_IDMA1 - 4 and such on.
+ * @mcn_protocol: specifies mode for the command for non-MCC, should be
+ * QE_CR_PROTOCOL_HDLC_TRANSPARENT, QE_CR_PROTOCOL_QMC, QE_CR_PROTOCOL_UART
+ * and such on.
+ * @cmd_input: command related data.
+ */
 int qe_issue_cmd(u32 cmd, u32 device, u8 mcn_protocol, u32 cmd_input)
 {
unsigned long flags;
u8 mcn_shift = 0, dev_shift = 0;
-   u32 ret;
+   int ret;
+   int i;
 
spin_lock_irqsave(&qe_lock, flags);
if (cmd == QE_RESET) {
-   out_be32(&qe_immr->cp.cecr, (u32) (cmd | QE_CR_FLG));
+   iowrite32be((cmd | QE_CR_FLG), &qe_immr->cp.cecr);
} else {
if (cmd == QE_ASSIGN_PAGE) {
/* Here device is the SNUM, not sub-block */
@@ -134,20 +144,26 @@ int qe_issue_cmd(u32 cmd, u32 device, u8 mcn_protocol, 
u32 cmd_input)
mcn_shift = QE_CR_MCN_NORMAL_SHIFT;
}
 
-   out_be32(&qe_immr->cp.cecdr, cmd_input);
-   out_be32(&qe_immr->cp.cecr,
-(cmd | QE_CR_FLG | ((u32) device << dev_shift) | (u32)
- mcn_protocol << mcn_shift));
+   iowrite32be(cmd_input, &qe_immr->cp.cecdr);
+   iowrite32be((cmd | QE_CR_FLG | ((u32)device << dev_shift) |
+  

[PATCH v6 3/4] irqchip/qeic: merge qeic_of_init into qe_ic_init

[Zhao Qiang]

qeic_of_init just get device_node of qeic from dtb and call qe_ic_init,
pass the device_node to qe_ic_init.
So merge qeic_of_init into qe_ic_init to get the qeic node in
qe_ic_init.

Signed-off-by: Zhao Qiang 
---
Changes for v2:
- modify subject and commit msg
- return 0 and add put node when return in qe_ic_init
Changes for v3:
- na
Changes for v4:
- na
Changes for v5:
- na
Changes for v6:
- rebase

 drivers/irqchip/irq-qeic.c | 91 +-
 include/soc/fsl/qe/qe_ic.h |  7 
 2 files changed, 50 insertions(+), 48 deletions(-)

diff --git a/drivers/irqchip/irq-qeic.c b/drivers/irqchip/irq-qeic.c
index 1463731..4f49d4b 100644
--- a/drivers/irqchip/irq-qeic.c
+++ b/drivers/irqchip/irq-qeic.c
@@ -406,27 +406,38 @@ unsigned int qe_ic_get_high_irq(struct qe_ic *qe_ic)
return irq_linear_revmap(qe_ic->irqhost, irq);
 }
 
-void __init qe_ic_init(struct device_node *node, unsigned int flags,
-  void (*low_handler)(struct irq_desc *desc),
-  void (*high_handler)(struct irq_desc *desc))
+static int __init qe_ic_init(unsigned int flags)
 {
+   struct device_node *node;
struct qe_ic *qe_ic;
struct resource res;
-   u32 temp = 0, ret, high_active = 0;
+   u32 temp = 0, high_active = 0;
+   int ret = 0;
+
+   node = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
+   if (!node) {
+   node = of_find_node_by_type(NULL, "qeic");
+   if (!node)
+   return -ENODEV;
+   }
 
ret = of_address_to_resource(node, 0, &res);
-   if (ret)
-   return;
+   if (ret) {
+   ret = -ENODEV;
+   goto err_put_node;
+   }
 
qe_ic = kzalloc(sizeof(*qe_ic), GFP_KERNEL);
-   if (qe_ic == NULL)
-   return;
+   if (qe_ic == NULL) {
+   ret = -ENOMEM;
+   goto err_put_node;
+   }
 
qe_ic->irqhost = irq_domain_add_linear(node, NR_QE_IC_INTS,
   &qe_ic_host_ops, qe_ic);
if (qe_ic->irqhost == NULL) {
-   kfree(qe_ic);
-   return;
+   ret = -ENOMEM;
+   goto err_free_qe_ic;
}
 
qe_ic->regs = ioremap(res.start, resource_size(&res));
@@ -437,9 +448,9 @@ void __init qe_ic_init(struct device_node *node, unsigned 
int flags,
qe_ic->virq_low = irq_of_parse_and_map(node, 1);
 
if (qe_ic->virq_low == NO_IRQ) {
-   printk(KERN_ERR "Failed to map QE_IC low IRQ\n");
-   kfree(qe_ic);
-   return;
+   pr_err("Failed to map QE_IC low IRQ\n");
+   ret = -ENOMEM;
+   goto err_domain_remove;
}
 
/* default priority scheme is grouped. If spread mode is*/
@@ -466,13 +477,24 @@ void __init qe_ic_init(struct device_node *node, unsigned 
int flags,
qe_ic_write(qe_ic->regs, QEIC_CICR, temp);
 
irq_set_handler_data(qe_ic->virq_low, qe_ic);
-   irq_set_chained_handler(qe_ic->virq_low, low_handler);
+   irq_set_chained_handler(qe_ic->virq_low, qe_ic_cascade_low_mpic);
 
if (qe_ic->virq_high != NO_IRQ &&
qe_ic->virq_high != qe_ic->virq_low) {
irq_set_handler_data(qe_ic->virq_high, qe_ic);
-   irq_set_chained_handler(qe_ic->virq_high, high_handler);
+   irq_set_chained_handler(qe_ic->virq_high,
+   qe_ic_cascade_high_mpic);
}
+   of_node_put(node);
+   return 0;
+
+err_domain_remove:
+   irq_domain_remove(qe_ic->irqhost);
+err_free_qe_ic:
+   kfree(qe_ic);
+err_put_node:
+   of_node_put(node);
+   return ret;
 }
 
 void qe_ic_set_highest_priority(unsigned int virq, int high)
@@ -579,39 +601,26 @@ static struct device device_qe_ic = {
.bus = &qe_ic_subsys,
 };
 
-static int __init init_qe_ic_sysfs(void)
+static int __init init_qe_ic(void)
 {
-   int rc;
+   int ret;
 
-   printk(KERN_DEBUG "Registering qe_ic with sysfs...\n");
+   ret = qe_ic_init(0);
+   if (ret)
+   return ret;
 
-   rc = subsys_system_register(&qe_ic_subsys, NULL);
-   if (rc) {
-   printk(KERN_ERR "Failed registering qe_ic sys class\n");
+   ret = subsys_system_register(&qe_ic_subsys, NULL);
+   if (ret) {
+   pr_err("Failed registering qe_ic sys class\n");
return -ENODEV;
}
-   rc = device_register(&device_qe_ic);
-   if (rc) {
-   printk(KERN_ERR "Failed registering qe_ic sys device\n");
+   ret = device_register(&device_qe_ic);
+   if (ret) {
+   pr_err("Failed registering qe_ic sys device\n");
return -ENODEV;
}
-   return 0;
-}
-
-static int __init qeic_of_init(void)
-{
-   struct device_node *np;
 
-   np = o

Re: [PATCH 2/3] DT: EVM: add LEDs

[Tony Lindgren]

* H. Nikolaus Schaller  [160927 13:11]:
> > Am 27.09.2016 um 21:49 schrieb Tony Lindgren :
> > How about this for defaults:
> > 
> > - heartbeat for led3
> > - cpu0 for led4
> > - cpu1 for led5
> 
> Good idea. Will try.
> 
> What I don't exactly know is if these gpios based on an I2C-expander
> can handle cpu activity triggers or if they are locked up if this i2c
> processing triggers another cpu activity...

Oh right, if the GPIOs are on the i2c bus it's probably not a good
idea :) Or at least will be inaccurate if the bus can sleep.

Regards,

Tony

[PATCH 2/2] mfd: intel-lpss: Avoid resuming runtime-suspended lpss unnecessarily

[Chen Yu]

We have report that the intel_lpss_prepare() takes too much time during
suspend, and this is because we first resume the devices from runtime
suspend by resume_lpss_device(), to make sure they are in proper state
before system suspend, which takes 100ms for each LPSS devices(PCI power
state from D3_cold to D0). And since resume_lpss_device() resumes the
devices synchronously, we might get huge latency if we have many
LPSS devices.

So first try is to use pm_request_resume() instead, to make the runtime
resume process asynchronously. Unfortunately the asynchronous runtime
resume relies on pm_wq, which is freezed at early stage. So we choose
another method, that is to avoid resuming runtime-suspended devices,
if they are already runtime suspended. This is safe because for LPSS
driver, the runtime suspend and system suspend are of the same
hook - i.e., intel_lpss_suspend(). And moreover, this device is
neither runtime wakeup source nor system wakeup source.

Acked-by: Mika Westerberg 
Reviewed-by: Andy Shevchenko 
Cc: Andy Shevchenko 
Cc: Mika Westerberg 
Cc: Rafael J. Wysocki 
Signed-off-by: Chen Yu 
---
 drivers/mfd/intel-lpss.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/mfd/intel-lpss.c b/drivers/mfd/intel-lpss.c
index 41b1138..2ba8d19 100644
--- a/drivers/mfd/intel-lpss.c
+++ b/drivers/mfd/intel-lpss.c
@@ -485,6 +485,15 @@ static int resume_lpss_device(struct device *dev, void 
*data)
 int intel_lpss_prepare(struct device *dev)
 {
/*
+* This is safe because:
+* 1. The runtime suspend and system suspend
+* are of the same hook.
+* 2. This device is neither runtime wakeup source
+* nor system wakeup source.
+*/
+   if (pm_runtime_status_suspended(dev))
+   return RPM_SUSPENDED;
+   /*
 * Resume both child devices before entering system sleep. This
 * ensures that they are in proper state before they get suspended.
 */
-- 
2.7.4

[PATCH 0/2] Define positive return value to RPM_SUSPEND for runtime-suspended devices

[Chen Yu]

This patch set is to define the positive value returned
by device .prepare() callbacks, which is used to indicate
the devices are OK to remain in runtime-suspended during
system sleep. A precise return value would make the code
more readable.

Based on this definition, optimized the suspend process
in intel-lpss driver.

Chen Yu (2):
  PM / sleep: Return RPM_SUSPENDED to keep devices in runtime-suspended
  mfd: intel-lpss: Avoid resuming runtime-suspended lpss unnecessarily

 Documentation/power/devices.txt| 8 
 Documentation/power/runtime_pm.txt | 2 +-
 drivers/base/power/main.c  | 8 ++--
 drivers/mfd/intel-lpss.c   | 9 +
 4 files changed, 20 insertions(+), 7 deletions(-)

-- 
2.7.4

[PATCH 1/2] PM / sleep: Return RPM_SUSPENDED to keep devices in runtime-suspended

[Chen Yu]

Currently if the ->prepare() callback of a device returns a positive number,
the PM core will regard that as an indication that it may leave the
device runtime-suspended. However it would be more convenient to define
this positive number then makes it more maintainable. Consider there might be
already some device drivers using different positive values, this patch
prints a warning if the positive value is other than RPM_SUSPENDED, and hoping
driver developers would adjust their return values to RPM_SUSPENDED, then
at last we can modify the code to only enable this feature for values return
of RPM_SUSPENDED rather than arbitrary positive value.

Suggested-by: Lee Jones 
Suggested-by: Rafael J. Wysocki 
Signed-off-by: Chen Yu 
---
 Documentation/power/devices.txt| 8 
 Documentation/power/runtime_pm.txt | 2 +-
 drivers/base/power/main.c  | 8 ++--
 3 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
index 8ba6625..fc585a5 100644
--- a/Documentation/power/devices.txt
+++ b/Documentation/power/devices.txt
@@ -331,8 +331,8 @@ the phases are:
prepare callback can be used to indicate to the PM core that it may
safely leave the device in runtime suspend (if runtime-suspended
already), provided that all of the device's descendants are also left in
-   runtime suspend.  Namely, if the prepare callback returns a positive
-   number and that happens for all of the descendants of the device too,
+   runtime suspend.  Namely, if the prepare callback returns RPM_SUSPENDED
+   and that happens for all of the descendants of the device too,
and all of them (including the device itself) are runtime-suspended, the
PM core will skip the suspend, suspend_late and suspend_noirq suspend
phases as well as the resume_noirq, resume_early and resume phases of
@@ -344,7 +344,7 @@ the phases are:
Note that this direct-complete procedure applies even if the device is
disabled for runtime PM; only the runtime-PM status matters.  It follows
that if a device has system-sleep callbacks but does not support runtime
-   PM, then its prepare callback must never return a positive value.  This
+   PM, then its prepare callback must never return RPM_SUSPENDED.  This
is because all devices are initially set to runtime-suspended with
runtime PM disabled.
 
@@ -422,7 +422,7 @@ When resuming from freeze, standby or memory sleep, the 
phases are:
the resume callbacks occur; it's not necessary to wait until the
complete phase.
 
-   Moreover, if the preceding prepare callback returned a positive number,
+   Moreover, if the preceding prepare callback returned RPM_SUSPENDED,
the device may have been left in runtime suspend throughout the whole
system suspend and resume (the suspend, suspend_late, suspend_noirq
phases of system suspend and the resume_noirq, resume_early, resume
diff --git a/Documentation/power/runtime_pm.txt 
b/Documentation/power/runtime_pm.txt
index 1fd1fbe..5316daf 100644
--- a/Documentation/power/runtime_pm.txt
+++ b/Documentation/power/runtime_pm.txt
@@ -667,7 +667,7 @@ suspend began in the suspended state.
 
 To this end, the PM core provides a mechanism allowing some coordination 
between
 different levels of device hierarchy.  Namely, if a system suspend .prepare()
-callback returns a positive number for a device, that indicates to the PM core
+callback returns RPM_SUSPENDED for a device, that indicates to the PM core
 that the device appears to be runtime-suspended and its state is fine, so it
 may be left in runtime suspend provided that all of its descendants are also
 left in runtime suspend.  If that happens, the PM core will not execute any
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index e44944f..03a047e 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -1603,14 +1603,18 @@ unlock:
return ret;
}
/*
-* A positive return value from ->prepare() means "this device appears
+* A return value of RPM_SUSPENDED from ->prepare() means "this device 
appears
 * to be runtime-suspended and its state is fine, so if it really is
 * runtime-suspended, you can leave it in that state provided that you
 * will do the same thing with all of its descendants".  This only
 * applies to suspend transitions, however.
 */
spin_lock_irq(&dev->power.lock);
-   dev->power.direct_complete = ret > 0 && state.event == PM_EVENT_SUSPEND;
+   if (ret > 0 && state.event == PM_EVENT_SUSPEND) {
+   dev->power.direct_complete = true;
+   if (ret != RPM_SUSPENDED)
+   dev_warn(dev, "->prepare() should return 
RPM_SUSPENDED.\n");
+   }
spin_unlock_irq(&dev->power.lock);
return 0;
 }
-- 
2.7.4

Re: [PATCH v3 0/9] dmaengine: ti drivers: enable COMPILE_TESTing

[Vinod Koul]

On Wed, Sep 21, 2016 at 03:41:26PM +0300, Peter Ujfalusi wrote:
> Hi,
> 
> Changes since v2:
> - Instead of converting to use enum for the of_device_id data parameter the 
> two
>   patch for edma and ti-dma-crossbar is using pointers to u32 variables to 
> make
>   sure that the code compile (and in theory work) on all architectures.
> - fixed issue in the ti-dma-crossbar driver I have made with the enum change 
> to
>   not handle the DMA offset parameters correctly.
> 
> Changes since v1:
> - added the compiler warning message to ti-dma-crossbar enum type patch
> - moved the Kconfig patches at the end of the seris
> 
> The following series will enable unconditional COMPILE_TEST coverage for the
> following drivers: omap-dma, edma and ti-dma-crossbar
> 
> The series includes fixes noticed when compiling the drivers for x86_64 and
> aarch64.

I have applied the series after fixing code style nit-picks.

Also applied the edma patch and reordered the series to have that come
before compile test enable patch

Please verify.

Thanks
-- 
~Vinod

[PATCH] Fixes: 3d44a78f0d8b ("staging: rtl8712: Remove unnecessary 'else'")

[Matthew Kilgore]

An "unnecessary" 'else' was removed due to complains from checkpatch.pl
as it is preceded by a 'return', however the 'else' branch is necessary
as an earlier branch of the 'if' falls through. By removing the 'else',
that route now hits the 'break' and the 'while' loop exits prematurely.

This commit reverts that change and puts the original 'else' back in
place.

Signed-off-by: Matthew Kilgore 
---
drivers/staging/rtl8712/rtl8712_recv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/rtl8712_recv.c 
b/drivers/staging/rtl8712/rtl8712_recv.c
index cf46592be472..66f0e0a35167 100644
--- a/drivers/staging/rtl8712/rtl8712_recv.c
+++ b/drivers/staging/rtl8712/rtl8712_recv.c
@@ -508,7 +508,8 @@ static int enqueue_reorder_recvframe(struct 
recv_reorder_ctrl *preorder_ctrl,
plist = plist->next;
else if (SN_EQUAL(pnextattrib->seq_num, pattrib->seq_num))
return false;
-   break;
+   else
+   break;
}
list_del_init(&(prframe->u.hdr.list));
list_add_tail(&(prframe->u.hdr.list), plist);
--
2.10.0

Re: [PATCH v3 6/9] dmaengine: ti-dma-crossbar: Fix of_device_id data parameter usage

[Vinod Koul]

On Wed, Sep 21, 2016 at 03:41:32PM +0300, Peter Ujfalusi wrote:
> @@ -395,7 +403,7 @@ static int ti_dra7_xbar_probe(struct platform_device 
> *pdev)
>  
>   xbar->dmarouter.dev = &pdev->dev;
>   xbar->dmarouter.route_free = ti_dra7_xbar_free;
> - xbar->dma_offset = (u32)match->data;
> + xbar->dma_offset = *(u32*)match->data;
 
we need space between u32 and *

>   mutex_init(&xbar->mutex);
>   platform_set_drvdata(pdev, xbar);
> @@ -428,7 +436,7 @@ static int ti_dma_xbar_probe(struct platform_device *pdev)
>   if (unlikely(!match))
>   return -EINVAL;
>  
> - switch ((u32)match->data) {
> + switch (*(u32*)match->data) {

here too please

-- 
~Vinod

Re: [PATCHv2] MAINTAINERS: Update open-iscsi maintainers

[Mike Christie]

On 09/26/2016 05:25 PM, Lee Duncan wrote:
> Chris Leech and I are taking over as open-iscsi maintainers.
> 
> Changes since v1:
>  * Updated URL to open-iscsi.com
>  * Removed git repository, since code in tree
> ---
>  MAINTAINERS | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 01bff8ea28d8..81384a2562e7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6448,10 +6448,10 @@ S:Maintained
>  F:   drivers/firmware/iscsi_ibft*
>  
>  ISCSI
> -M:   Mike Christie 
> +M:   Lee Duncan 
> +M:   Chris Leech 
>  L:   open-is...@googlegroups.com
> -W:   www.open-iscsi.org
> -T:   git 
> git://git.kernel.org/pub/scm/linux/kernel/git/mnc/linux-2.6-iscsi.git
> +W:   www.open-iscsi.com
>  S:   Maintained
>  F:   drivers/scsi/*iscsi*
>  F:   include/scsi/*iscsi*
> 

After over 10 years, I will get to take a vacation where I do not have
to think about iSCSI :)

Reviewed-by: Mike Christie 

[PATCH V2] checkpatch: Improve the octal permissions tests

[Joe Perches]

The function calls with octal permissions commonly span multiple lines.
The current test is line oriented and fails to find some matches.

Make the test use the $stat variable instead of the $line variable to
span multiple lines.

Also add a few functions to the known functions with permissions list.

Move the SYMBOLIC_PERMS test to a separate section to find all the
S_ permissions in any form not just those that have specific
function names.

This can now find and fix permissions uses like:
 .mode = S_ | S_;

Signed-off-by: Joe Perches 
---

V2: Move the SYMBOLIC_PERMS test.

 scripts/checkpatch.pl | 60 +--
 1 file changed, 44 insertions(+), 16 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 0ef3d837f2aa..22055004c56a 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -524,7 +524,11 @@ our @mode_permission_funcs = (
["module_param_array_named", 5],

["debugfs_create_(?:file|u8|u16|u32|u64|x8|x16|x32|x64|size_t|atomic_t|bool|blob|regset32|u32_array)",
 2],
["proc_create(?:_data|)", 2],
-   ["(?:CLASS|DEVICE|SENSOR)_ATTR", 2],
+   ["(?:CLASS|DEVICE|SENSOR|SENSOR_DEVICE|IIO_DEVICE)_ATTR", 2],
+   ["IIO_DEV_ATTR_[A-Z_]+", 1],
+   ["SENSOR_(?:DEVICE_|)ATTR_2", 2],
+   ["SENSOR_TEMPLATE(?:_2|)", 3],
+   ["__ATTR", 2],
 );
 
 #Create a search pattern for all these functions to speed up a loop below
@@ -6079,45 +6083,69 @@ sub process {
 # Mode permission misuses where it seems decimal should be octal
 # This uses a shortcut match to avoid unnecessary uses of a slow foreach loop
if ($^V && $^V ge 5.10.0 &&
+   defined $stat &&
$line =~ /$mode_perms_search/) {
foreach my $entry (@mode_permission_funcs) {
my $func = $entry->[0];
my $arg_pos = $entry->[1];
 
+   my $lc = $stat =~ tr@\n@@;
+   $lc = $lc + $linenr;
+   my $stat_real = raw_line($linenr, 0);
+   for (my $count = $linenr + 1; $count <= $lc; 
$count++) {
+   $stat_real = $stat_real . "\n" . 
raw_line($count, 0);
+   }
+
my $skip_args = "";
if ($arg_pos > 1) {
$arg_pos--;
$skip_args = 
"(?:\\s*$FuncArg\\s*,\\s*){$arg_pos,$arg_pos}";
}
my $test = 
"\\b$func\\s*\\(${skip_args}($FuncArg(?:\\|\\s*$FuncArg)*)\\s*[,\\)]";
-   if ($line =~ /$test/) {
+   if ($stat =~ /$test/) {
my $val = $1;
$val = $6 if ($skip_args ne "");
if (($val =~ /^$Int$/ && $val !~ 
/^$Octal$/) ||
($val =~ /^$Octal$/ && length($val) 
ne 4)) {
ERROR("NON_OCTAL_PERMISSIONS",
- "Use 4 digit octal (0777) 
not decimal permissions\n" . $herecurr);
+ "Use 4 digit octal (0777) 
not decimal permissions\n" . "$here\n" . $stat_real);
}
if ($val =~ /^$Octal$/ && (oct($val) & 
02)) {
ERROR("EXPORTED_WORLD_WRITABLE",
- "Exporting writable files 
is usually an error. Consider more restrictive permissions.\n" . $herecurr);
-   }
-   if ($val =~ 
/\b$mode_perms_string_search\b/) {
-   my $to = 0;
-   while ($val =~ 
/\b($mode_perms_string_search)\b(?:\s*\|\s*)?\s*/g) {
-   $to |=  
$mode_permission_string_types{$1};
-   }
-   my $new = sprintf("%04o", $to);
-   if (WARN("SYMBOLIC_PERMS",
-"Symbolic permissions 
are not preferred. Consider using octal permissions $new.\n" . $herecurr) &&
-   $fix) {
-   $fixed[$fixlinenr] =~ 
s/\Q$val\E/$new/;
-   }
+ "Exporting writable files 
is usually an error. Consider more restrictive

Re: [PATCH v5] powerpc: Do not make the entire heap executable

[Jason Gunthorpe]

On Wed, Sep 28, 2016 at 11:42:11AM +1000, Michael Ellerman wrote:

> But this is not really a powerpc patch, and I'm not an ELF expert. So
> I'm not comfortable merging it via the powerpc tree. It doesn't look
> like we really have a maintainer for binfmt_elf.c, so I'm not sure who
> should be acking that part.

Thanks a bunch for looking at this Michael.

> I've added Al Viro to Cc, he maintains fs/ and might be interested.

> I've also added Andrew Morton who might be happy to put this in his
> tree, and see if anyone complains?

For those added to the CC, I would re-state my original commit message
more clearly.

My research showed that the ELF loader bug fixed in this patch is the
root cause bug fix required to implement this hunk:

> > -#define VM_DATA_DEFAULT_FLAGS32(VM_READ | VM_WRITE | VM_EXEC | \
> > +#define VM_DATA_DEFAULT_FLAGS32 \
> > +   (((current->personality & READ_IMPLIES_EXEC) ? VM_EXEC : 0) | \
> > +VM_READ | VM_WRITE | \
> >  VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)

Eg that 32 bit powerpc currently unconditionally injects writable,
executable pages into a user space process.

This critically undermines all the W^X security work that has been
done in the tool chain and user space by the PPC community.

I would encourage people to view this as an important security patch
for 32 bit powerpc environments.

Regards,
Jason

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

[Herbert Xu]

On Tue, Sep 27, 2016 at 04:46:44PM -0300, Marcelo Cerri wrote:
> 
> Can you check if the problem occurs with this patch?

In light of the fact that padlock-sha is the correct example
to follow, you only need to add one line to the init_tfm fucntion
to update the descsize based on that of the fallback.

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

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

[Herbert Xu]

On Tue, Sep 27, 2016 at 05:01:03AM -0400, Jan Stancek wrote:
> 
> Also, does that mean that padlock_sha has similar problem?
> It does not seem to reserve any space for fallback __ctx and it calls
> init()/update()/export() with padlock_sha_desc's fallback:
> 
> struct padlock_sha_desc {
> struct shash_desc fallback;
> };
> 
> static struct shash_alg sha1_alg = {
> .descsize   =   sizeof(struct padlock_sha_desc),

Actually I was wrong when I said that the API couldn't handle
a dynamic fallback.  It can and padlock-sha does the right thing
by updating descsize in the cra_init function.

So this is what vmx should do too.

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

Re: [PATCH 00/17] clean up readlinks

[Al Viro]

On Tue, Sep 27, 2016 at 11:38:33AM +0200, Miklos Szeredi wrote:
> > I have no problem with "let's get rid of generic_readlink" - not 
> > that
> > it bought us much, but sure, if you want to have decision made based upon
> > the combination of flags, let's do it.  Just make NULL ->readlink + non-NULL
> > ->get_link() mean generic_readlink(), and we are done.
> 
> Indeed.  Except it really should be the other way round:
> 
> - .get_link always returning the symlink body
> - only proc setting .jump_link to do its thing
> - RIP .readlink

> But that's an extra branch in the symlink following.  I was worried
> about that and hence gone for the unification of the two.

Symlink traversal is a much hotter path than readlink() would ever be.
What's more, we do have jumps on normal symlink traversal - after all,
absolute symlinks are exactly that; it's "jump to root, then traverse
the following sequence of components".  So having ->get_link() that
includes jumps is not that much of a stretch (note that it could both
jump and return a relative pathname to traverse after that; none of the
procfs-style ones do that, but there's no reason to prohibit that).

What I'd prefer is
* it's a symlink iff it has ->get_link()
* readlink(2) on a symlink is normally just using generic_readlink()
* that can be overridden by supplying a ->readlink() method.
* the first time readlink() hits a symlink it will check both
->get_link() and ->readlink() presence.  Then, if it's a normal symlink,
the inode will get marked as such and all subsequent calls will just call
generic_readlink().  IOW, I would go for
if (unlikely(!marked)) {
if ->readlink is present
call ->readlink and return
if ->get_link is absent
fail
mark
}
call generic_readlink

> Yeah.  We can do your above suggestion, it's certainly less brittle.
> But I think it's rather confusing, having ->get_link normally do
> readlink, except for proc, where readlink is done by ->readlink.

->readlink() is just an override for the cases when readlink(2) wants
to fake something (or, as in case of AFS ugliness, is used on non-symlinks).
The primary function of symlinks is traversal, not readlink...

Re: [PATCH v3] Net Driver: Add Cypress GX3 VID=04b4 PID=3610.

[David Miller]

From: 
Date: Tue, 27 Sep 2016 09:57:50 -0600

> From: Chris Roth 
> 
> From Allan Chou 
> From: Chris Roth 

Three From lines, it's actually quite amazing how you were
able to achieve this.

Please take some time, and carefully craft your patch emails but don't
send them to the list.

Instead, email yourself, and look at what you receive.

Do not post this patch to the list until the test emails you send to
yourself look correct.

Thank you.

linux-next: manual merge of the drm-misc tree with the drm tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-misc tree got conflicts in:

  drivers/gpu/drm/sti/sti_dvo.c
  drivers/gpu/drm/sti/sti_hqvdp.c
  drivers/gpu/drm/sti/sti_mixer.c

between commits:

  bdfd36ef8e64 ("drm/sti: Fix sparse warnings")
  b4bba92dfbe2 ("drm/sti: remove stih415-416 platform support")

from the drm tree and commit:

  bd233af436ba ("drm/sti: mark symbols static where possible")

from the drm-misc tree.

I fixed it up (I just used the drm-misc tree versions and removed the
comflicting function in the sti_mixer.c case) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH trival -resend 1/2] bpf: clean up put_cpu_var usage

[David Miller]

From: Shaohua Li 
Date: Tue, 27 Sep 2016 08:42:41 -0700

> put_cpu_var takes the percpu data, not the data returned from
> get_cpu_var.
> 
> This doesn't change the behavior.
> 
> Cc: Tejun Heo 
> Cc: Alexei Starovoitov 
> Signed-off-by: Shaohua Li 

Applied.

Re: [PATCH trival -resend 2/2] lib: clean up put_cpu_var usage

[David Miller]

From: Shaohua Li 
Date: Tue, 27 Sep 2016 08:42:42 -0700

> put_cpu_var takes the percpu data, not the data returned from
> get_cpu_var.
> 
> This doesn't change the behavior.
> 
> Cc: Tejun Heo 
> Signed-off-by: Shaohua Li 

Applied.

Re: [PATCH v5 1/4] mfd: mxs-lradc: Add support for mxs-lradc MFD

[Dmitry Torokhov]

On September 27, 2016 11:50:00 AM PDT, Lee Jones  wrote:
>On Sat, 17 Sep 2016, Ksenija Stanojević wrote:
>> On Wed, Aug 31, 2016 at 2:05 PM, Lee Jones 
>wrote:
>> > On Thu, 18 Aug 2016, Ksenija Stanojevic wrote:
>> >
>> > > Add core files for mxs-lradc MFD driver.
>> > >
>> > > Note:  this patch won't compile in iio/testing without this
>patch:
>> > > a8f447be8056 ("mfd: Add resource managed APIs for
>mfd_add_devices")
>> > >
>> > > Signed-off-by: Ksenija Stanojevic 
>> > > ---
>> > > Changes in v5:
>> > >  - use DEFINE_RES_MEM
>> > >  - don't pass ioreammaped adress to platform cells
>> > >  - move comment outside of struct mxs_lradc
>> > >  - change type of argument in mxs_lradc_reg_set,
>mxs_lradc_reg_clear,
>> > >mxs_lradc_reg_wrt (struct mxs_lradc * -> void __iomem *)
>> > >
>> > > Changes in v4:
>> > >  - update copyright
>> > >  - use DEFINE_RES_IRQ_NAMED
>> > >  - remove mxs_lradc_add_device function
>> > >  - use struct mfd_cell in static form
>> > >  - improve spacing
>> > >  - remove unnecessary comment
>> > >  - remove platform_get_irq
>> > >  - remove touch_ret and use ret instead
>> > >  - rename use_touchscreen to touchscreen_wire
>> > >  - use goto statements
>> > >  - remove irq[13], irq_count and irq_name from struct mxs_lradc
>> > >  - remove all defines from inside the struct definition
>> > >
>> > > Changes in v3:
>> > >  - add note to commit message
>> > >  - move switch statement into if(touch_ret == 0) branch
>> > >  - add MODULE_AUTHOR
>> > >
>> > > Changes in v2:
>> > >  - do not change spacing in Kconfig
>> > >  - make struct mfd_cell part of struct mxs_lradc
>> > >  - use switch instead of if in mxs_lradc_irq_mask
>> > >  - use only necessary header files in mxs_lradc.h
>> > >  - use devm_mfd_add_device
>> > >  - use separate function to register mfd device
>> > >  - change licence to GPL
>> > >  - add copyright
>> > >
>> > >  drivers/mfd/Kconfig   |  17 +++
>> > >  drivers/mfd/Makefile  |   1 +
>> > >  drivers/mfd/mxs-lradc.c   | 255
>++
>> > >  include/linux/mfd/mxs-lradc.h | 194
>
>> > >  4 files changed, 467 insertions(+)
>> > >  create mode 100644 drivers/mfd/mxs-lradc.c
>> > >  create mode 100644 include/linux/mfd/mxs-lradc.h
>
>[...]
>
>> > > +static int mxs_lradc_probe(struct platform_device *pdev)
>> > > +{
>> > > + const struct of_device_id *of_id;
>> > > + struct device *dev = &pdev->dev;
>> > > + struct device_node *node = dev->of_node;
>> > > + struct mxs_lradc *lradc;
>> > > + struct mfd_cell *cells = NULL;
>> > > + int ret = 0;
>> > > + u32 ts_wires = 0;
>> > > +
>> > > + lradc = devm_kzalloc(&pdev->dev, sizeof(*lradc),
>GFP_KERNEL);
>> > > + if (!lradc)
>> > > + return -ENOMEM;
>> > > +
>> > > + of_id = of_match_device(mxs_lradc_dt_ids, &pdev->dev);
>> > > + lradc->soc = (enum mxs_lradc_id)of_id->data;
>> >
>> > Unnecessary cast.
>> 
>> If I remove the cast I get this error:
>> drivers/mfd/mxs-lradc.c:148:13: error: incompatible types when
>> assigning to type ‘enum mxs_lradc_id’ from type ‘const void * const’
>
>Ah, because it's a const.  Fair enough.

No, it's because void * has to be cast to a non-pointer data type explicitly.


Thanks.

-- 
Dmitry

Re: kernel BUG at net/unix/garbage.c:149!"

[David Miller]

From: Nikolay Borisov 
Date: Tue, 27 Sep 2016 17:16:27 +0300

> What's the status of https://patchwork.ozlabs.org/patch/664062/ , is
> this going to be picked up ?

Why would I apply a patch that's an RFC, doesn't have a proper commit
message, lacks a proper signoff, and also lacks ACK's and feedback
from other knowledgable developers?

Re: [PATCH v3 00/11] re-enable DAX PMD support

[Christoph Hellwig]

On Tue, Sep 27, 2016 at 02:47:51PM -0600, Ross Zwisler wrote:
> DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
> locking.  This series allows DAX PMDs to participate in the DAX radix tree
> based locking scheme so that they can be re-enabled.
> 
> Jan and Christoph, can you please help review these changes?

About to get on a plane, so it might take a bit to do a real review.
In general this looks fine, but I guess the first two ext4 patches
should just go straight to Ted independent of the rest?

Also Jan just posted a giant DAX patchbomb, we'll need to find a way
to integrate all that work, and maybe prioritize things if we want
to get bits into 4.9 still.

Re: [PATCH] pinctrl: freescale: avoid overwriting pin config when freeing GPIO

[Viresh Kumar]

On 27-09-16, 12:34, Stefan Agner wrote:
> Added Viresh Kumar to the discussion, he implemented the I2C recovery
> functions.
> 
> Yes, reordering the pinctrl/gpio_free calls would fix the problem too.
> 
> However, I guess there is no explicit rule to that ("request/free GPIOs
> only when they are muxed as GPIO"), so I think of it that the issue is
> actually in the pinctrl driver.
> 
> On top of that it is not entirely trivial to reorder the calls the way
> i2c_generic_gpio_recovery and i2c_generic_recovery are set up right now.

AFAICT, these routines don't touch the muxing part at all. Perhaps it is done
internally by the GPIO calls. Can you please elaborate the exact change you are
hinting towards here ?

-- 
viresh

linux-next: manual merge of the drm tree with Linus' tree

[Stephen Rothwell]

Hi Dave,

Today's linux-next merge of the drm tree got a conflict in:

  drivers/gpu/drm/drm_crtc.c

between commit:

  6f00975c6190 ("drm: Reject page_flip for !DRIVER_MODESET")

from Linus' tree and commit:

  43968d7b806d ("drm: Extract drm_plane.[hc]")

from the drm tree.

I fixed it up (the latter takes the former into account, so I just used
the drm tree version) and can carry the fix as necessary. This is now
fixed as far as linux-next is concerned, but any non trivial conflicts
should be mentioned to your upstream maintainer when your tree is
submitted for merging.  You may also want to consider cooperating with
the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build failure after merge of the rdma tree

[Stephen Rothwell]

Hi Stephen,

On Tue, 27 Sep 2016 11:23:34 +1000 Stephen Rothwell  
wrote:
>
> Hi Doug,
> 
> After merging the rdma tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c: In function 
> 'kiblnd_hdev_setup_mrs':
> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:2317:7: error: implicit 
> declaration of function 'ib_get_dma_mr' 
> [-Werror=implicit-function-declaration]
>   mr = ib_get_dma_mr(hdev->ibh_pd, acflags);
>^
> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:2317:5: warning: 
> assignment makes pointer from integer without a cast [-Wint-conversion]
>   mr = ib_get_dma_mr(hdev->ibh_pd, acflags);
>  ^
> 
> Caused by commit
> 
>   5ef990f06bd7 ("IB/core: remove ib_get_dma_mr")
> 
> I have used the rdma tree from next-20160923 for today.

As pointed out by Christoph, I should have just disabled the driver in
staging, so today I just applied the patch below.  Doug, that should
probably be applied to the rdma tree so that you don't break Linus'
tree when it gets merged.

From: Stephen Rothwell 
Date: Wed, 28 Sep 2016 11:35:28 +1000
Subject: [PATCH] starging/lustre: disable LNET infiniband support

Commit 5ef990f06bd7 ("IB/core: remove ib_get_dma_mr") broke the
lustre LNET infiniband support.  Since this is in drivers/staging,
lets just disable it for now until ti can be fixed properly.

Signed-off-by: Stephen Rothwell 
---
 drivers/staging/lustre/lnet/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/lustre/lnet/Kconfig 
b/drivers/staging/lustre/lnet/Kconfig
index 2b5930150cda..13b43278a38d 100644
--- a/drivers/staging/lustre/lnet/Kconfig
+++ b/drivers/staging/lustre/lnet/Kconfig
@@ -35,6 +35,7 @@ config LNET_SELFTEST
 config LNET_XPRT_IB
tristate "LNET infiniband support"
depends on LNET && INFINIBAND && INFINIBAND_ADDR_TRANS
+   depends on BROKEN
default LNET && INFINIBAND
help
  This option allows the LNET users to use infiniband as an
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

Re: [PATCH v5] powerpc: Do not make the entire heap executable

[Michael Ellerman]

Denys Vlasenko  writes:

> On 32-bit powerpc the ELF PLT sections of binaries (built with --bss-plt,
> or with a toolchain which defaults to it) look like this:

Or (it seems), for all programs built with -pg (profiling).

>   [17] .sbss NOBITS  0002aff8 01aff8 14 00  WA  0   0 
>  4
>   [18] .plt  NOBITS  0002b00c 01aff8 84 00 WAX  0   0 
>  4
>   [19] .bss  NOBITS  0002b090 01aff8 a4 00  WA  0   0 
>  4
>
> Which results in an ELF load header:
>
>   Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>   LOAD   0x019c70 0x00029c70 0x00029c70 0x01388 0x014c4 RWE 0x1
>
> This is all correct, the load region containing the PLT is marked as
> executable. Note that the PLT starts at 0002b00c but the file mapping ends at
> 0002aff8, so the PLT falls in the 0 fill section described by the load header,
> and after a page boundary.
>
> Unfortunately the generic ELF loader ignores the X bit in the load headers
> when it creates the 0 filled non-file backed mappings. It assumes all of these
> mappings are RW BSS sections, which is not the case for PPC.
>
> gcc/ld has an option (--secure-plt) to not do this, this is said to incur
> a small performance penalty.
>
> Currently, to support 32-bit binaries with PLT in BSS kernel maps *entire
> brk area* with executable rights for all binaries, even --secure-plt ones.
>
> Stop doing that.
>
> Teach the ELF loader to check the X bit in the relevant load header
> and create 0 filled anonymous mappings that are executable
> if the load header requests that.
...
>
> Signed-off-by: Jason Gunthorpe 
> Signed-off-by: Denys Vlasenko 
> Reviewed-by: Kees Cook 
> CC: Michael Ellerman 

This looks OK to me, I've tested it with --bss-plt and --secure-plt and
also -pg.

So for the powerpc part I'll give you an:

Acked-by: Michael Ellerman 

But this is not really a powerpc patch, and I'm not an ELF expert. So
I'm not comfortable merging it via the powerpc tree. It doesn't look
like we really have a maintainer for binfmt_elf.c, so I'm not sure who
should be acking that part.

I've added Al Viro to Cc, he maintains fs/ and might be interested.

I've also added Andrew Morton who might be happy to put this in his
tree, and see if anyone complains?

Also here: https://patchwork.ozlabs.org/patch/661595/

cheers

> ---
> Changes since v4:
> * if (current->personality & READ_IMPLIES_EXEC), still use VM_EXEC
>   for 32-bit executables.
>
> Changes since v3:
> * typo fix in commit message
> * rebased to current Linus tree
>
> Changes since v2:
> * moved capability to map with VM_EXEC into vm_brk_flags()
>
> Changes since v1:
> * wrapped lines to not exceed 79 chars
> * improved comment
> * expanded CC list
>
>  arch/powerpc/include/asm/page.h |  3 ++-
>  fs/binfmt_elf.c | 30 ++
>  include/linux/mm.h  |  1 +
>  mm/mmap.c   | 21 -
>  4 files changed, 41 insertions(+), 14 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
> index 56398e7..d188f51 100644
> --- a/arch/powerpc/include/asm/page.h
> +++ b/arch/powerpc/include/asm/page.h
> @@ -230,7 +230,9 @@ extern long long virt_phys_offset;
>   * and needs to be executable.  This means the whole heap ends
>   * up being executable.
>   */
> -#define VM_DATA_DEFAULT_FLAGS32  (VM_READ | VM_WRITE | VM_EXEC | \
> +#define VM_DATA_DEFAULT_FLAGS32 \
> + (((current->personality & READ_IMPLIES_EXEC) ? VM_EXEC : 0) | \
> +  VM_READ | VM_WRITE | \
>VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)
>  
>  #define VM_DATA_DEFAULT_FLAGS64  (VM_READ | VM_WRITE | \
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index 7f6aff3f..2b57b5a 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -91,12 +91,18 @@ static struct linux_binfmt elf_format = {
>  
>  #define BAD_ADDR(x) ((unsigned long)(x) >= TASK_SIZE)
>  
> -static int set_brk(unsigned long start, unsigned long end)
> +static int set_brk(unsigned long start, unsigned long end, int prot)
>  {
>   start = ELF_PAGEALIGN(start);
>   end = ELF_PAGEALIGN(end);
>   if (end > start) {
> - int error = vm_brk(start, end - start);
> + /*
> +  * Map the last of the bss segment.
> +  * If the header is requesting these pages to be
> +  * executable, honour that (ppc32 needs this).
> +  */
> + int error = vm_brk_flags(start, end - start,
> + prot & PROT_EXEC ? VM_EXEC : 0);
>   if (error)
>   return error;
>   }
> @@ -524,6 +530,7 @@ static unsigned long load_elf_interp(struct elfhdr 
> *interp_elf_ex,
>   unsigned long load_addr = 0;
>   int load_addr_set = 0;
>   unsigned long last_bss = 0, elf_bss = 0;
> + int bss_prot = 0;
>   unsigne

Regression in mobility grouping?

[Johannes Weiner]

Hi guys,

we noticed what looks like a regression in page mobility grouping
during an upgrade from 3.10 to 4.0. Identical machines, workloads, and
uptime, but /proc/pagetypeinfo on 3.10 looks like this:

Number of blocks type Unmovable  Reclaimable  Movable  Reserve  
Isolate 
Node 1, zone   Normal  815  433315182   
 0 

and on 4.0 like this:

Number of blocks type Unmovable  Reclaimable  Movable  Reserve  
CMA  Isolate 
Node 1, zone   Normal 3880 3530253562   
 00 

4.0 is either polluting pageblocks more aggressively at allocation, or
is not able to make pageblocks movable again when the reclaimable and
unmovable allocations are released. Invoking compaction manually
(/proc/sys/vm/compact_memory) is not bringing them back, either.

The problem we are debugging is that these machines have a very high
rate of order-3 allocations (fdtable during fork, network rx), and
after the upgrade allocstalls have increased dramatically. I'm not
entirely sure this is the same issue, since even order-0 allocations
are struggling, but the mobility grouping in itself looks problematic.

I'm still going through the changes relevant to mobility grouping in
that timeframe, but if this rings a bell for anyone, it would help. I
hate blaming random patches, but these caught my eye:

9c0415e mm: more aggressive page stealing for UNMOVABLE allocations
3a1086f mm: always steal split buddies in fallback allocations
99592d5 mm: when stealing freepages, also take pages created by splitting buddy 
page

The changelog states that by aggressively stealing split buddy pages
during a fallback allocation we avoid subsequent stealing. But since
there are generally more movable/reclaimable pages available, and so
less falling back and stealing freepages on behalf of movable, won't
this mean that we could expect exactly that result - growing numbers
of unmovable blocks, while rarely stealing them back in movable alloc
fallbacks? And the expansion of !MOVABLE blocks would over time make
compaction less and less effective too, seeing as it doesn't consider
anything !MOVABLE suitable migration targets?

Attached are the full /proc/pagetypeinfo and /proc/buddyinfo from both
kernels on machines with similar uptimes and directly after invoking
compaction. As you can see, the buddy lists are much more fragmented
on 4.0, with unmovable/reclaimable allocations polluting more blocks.

Any thoughts on this would be greatly appreciated. I can test patches.

Thanks!
Node 0, zone  DMA  0  0  0  1  2  1  1  0   
   1  1  3 
Node 0, zoneDMA32   1062   1491   1641   1725478 77  5  1   
   0  0  0 
Node 0, zone   Normal  10436  16239   5903696130729   1298550   
 109  0  0 
Node 1, zone   Normal   5956 15  5 28 11  8  2  0   
   0  0  0 
Node 0, zone  DMA  1  1  0  1  1  1  1  0   
   0  1  3 
Node 0, zoneDMA32   9462   6148   2297 27  0  0  0  0   
   0  0  0 
Node 0, zone   Normal 130376  36589   3777 94  1  0  0  0   
   0  0  0 
Node 1, zone   Normal 190988  77269   3896332  6  0  0  0   
   0  0  0 
Page block order: 9
Pages per block:  512

Free pages count per migrate type at order   0  1  2  3  4  
5  6  7  8  9 10 
Node0, zone  DMA, typeUnmovable  0  0  0  1  2  
1  1  0  1  0  0 
Node0, zone  DMA, type  Reclaimable  0  0  0  0  0  
0  0  0  0  0  0 
Node0, zone  DMA, type  Movable  0  0  0  0  0  
0  0  0  0  0  3 
Node0, zone  DMA, type  Reserve  0  0  0  0  0  
0  0  0  0  1  0 
Node0, zone  DMA, type  Isolate  0  0  0  0  0  
0  0  0  0  0  0 
Node0, zoneDMA32, typeUnmovable488221286  0  0  
0  0  0  0  0  0 
Node0, zoneDMA32, type  Reclaimable  1725741  0  0  
0  0  0  0  0  0 
Node0, zoneDMA32, type  Movable431   1735   1073105  0  
0  0  0  0  0  0 
Node0, zoneDMA32, type  Reserve  0  0  0 17  1  
0  0  0  0  0  0 
Node0, zoneDMA32, type  Isolate  0  0  0  0  0  
0  0  0  0  0  0 
Node0, zone   Normal, typeUnmovable   1922 16  1 19  0  
0  0  0  0  0  0 
Node0, zone   Normal, type  Reclaimable   4549  0  0  

Re: [PATCH v5 5/8] iommu/amd: copy old trans table from old kernel

[Baoquan He]

Hi Joerg,

On 09/20/16 at 02:40pm, Joerg Roedel wrote:
> > +   if ( !is_pre_enabled) {
> > +   for_each_iommu(iommu)
> > +   early_enable_iommu(iommu);
> > +   } else {
> > +   if (copy_dev_tables()) {
> > +   pr_err("Failed to copy DEV table from previous 
> > kernel.\n");
> > +   /*
> > +* If failed to copy dev tables from old kernel, 
> > continue to proceed
> > +* as it does in normal kernel.
> > +*/
> > +   for_each_iommu(iommu) {
> > +   clear_translation_pre_enabled(iommu);
> > +   early_enable_iommu(iommu);
> > +   }
> > +   } else {
> > +   pr_info("Copied DEV table from previous kernel.\n");
> > +   for_each_iommu(iommu) {
> > +   iommu_feature_disable(iommu, CONTROL_CMDBUF_EN);
> > +   iommu_feature_disable(iommu, 
> > CONTROL_EVT_LOG_EN);
> 
> Could you move that into new helpers (iommu_disable_command_buffer...)?

Did you mean wraping iommu_feature_disable(iommu, CONTROL_CMDBUF_EN) into a
helper function like iommu_disable_command_buffer(), and wraping
iommu_feature_disable(iommu, CONTROL_EVT_LOG_EN) into
iommu_disable_event_buffer()?

I retest with not disabling command buffer and event log here, it works
on amd iommu v1 and v2 systems. So if I understand your comment
correctly, there's no need to add "iommu_feature_disable(iommu,
CONTROL_CMDBUF_EN)"  and "iommu_feature_disable(iommu,
CONTROL_EVT_LOG_EN)" here. I remember I added them here because more
IO_PAGE_FAULT messages are printed without them. But now it seems not to
related to them. So I will remove above two lines of code.

> 
> > +   iommu_enable_command_buffer(iommu);
> > +   iommu_enable_event_buffer(iommu);
> > +   iommu_set_device_table(iommu);
> > +   iommu_flush_all_caches(iommu);
> > +   }
> > +   }
> > +   }
> >  }
> >  
> >  static void enable_iommus_v2(void)
> > -- 
> > 2.5.5
> > 

Re: [PATCH] of: thermal: Fixed governor at each thermal zone

[Zhang Rui]

Hi, Javi, Lukasz and Eduardo,

thanks for your input.

thanks,
rui

On 二, 2016-09-27 at 06:22 -0700, Eduardo Valentin wrote:
> Hello, Lukasz, Inhyuk, Javi,
> 
> On Tue, Sep 27, 2016 at 12:52:04PM +0100, Lukasz Luba wrote:
> > 
> > 
> > On 27/09/16 02:46, Zhang Rui wrote:
> > > 
> > > On 一, 2016-09-19 at 10:18 +0900, Inhyuk Kang wrote:
> > > > 
> > > > It is necessary to be added governor at each thermal_zone.
> > > > Because some governors should be operated in the during the
> > > > kernel
> > > > booting
> > > > in order to avoid heating problem.
> > > > 
> > > > Default governor cannot be covered all thermal zones policy
> > > > because
> > > > some thermal zones want to apply different one.
> > > > For example, the power allocator governor operates differently
> > > > with
> > > > step wise governor.
> > > > Hence, it is better to parse governor parameter from the device
> > > > tree.
> > > > 
> > > > Signed-off-by: Inhyuk Kang 
> > > > 
> > > The patch looks okay to me.
> > > Eduardo, what do you think of this patch?
> > Hi Rui,
> > 
> > Beside the fact which Javi pointed out in his email, there is an
> > issue in
> > the patch itself.
> > The idea behind the patch is good, but the patch should have some
> > improvements, i.e:
> > - strncpy instead of strcpy,
> > - if the governor name is not found in the registered governor's
> > list by
> > __find_governor (and then null is set) we should probably switch to
> > default
> > governor,
> > - add DT documentation,
> Also, the idea of the patch is good, almost tempting to do it, but
> unfortunately, not acceptable from DT perspective. The patch
> infringes
> two of the DT conceptual and design decision of:
> (a) DT should describe hardware, not policy;
> (b) DT should describe hardware, not OS specific implementations.
> 
> As already pointed by Javi, this patch has already been proposed
> (more
> than one time by different people), but, it still continues to be
> unacceptable.
> 
> Cheers,
> 
> 
> > 
> > 
> > Regards,
> > Lukasz
> > 

Re: [RFC 0/5] printk: Implement WARN_*DEFERRED()

[Sergey Senozhatsky]

On (09/27/16 18:02), Petr Mladek wrote:
> The main trick is that we replace the per-CPU function pointer
> by a preempt_count-like variable that could track the printk context.
> 
> I know that Sergey has another ideas in this area. But I wanted to see
> how this approach would look like.

well, yes. I was looking at WARN_*_DEFERRED [1] for some time, and, I
think, the maintenance cost of that solution is just too high:

a) every existing WARN_* in sched/timekeeping/who knows where else
   must be evaluated to ensure that in can't be called from printk()
   path. if `false' - then the corresponding macro must be replaced
   with _DEFERRED flavor.

b) any patch that adds new WARN_* usages must be additionally checked
   to ensure that each of new WARN_* macros cannot be called from printk
   path. if `false' -- the corresponding macro must be replaced with
   _DEFERRED flavor.

c) any patch that refactors the code or moves some function calls around
   etc. must be additionally checked for any accidental WARN_* from printk
   path. even though if none of the patches added any new WARN_* to the code.

b) apart from WARN_* there can be `accidental' pr_err/pr_debug/etc. not
   necessarily newly added (see 'c').


that's too much.
for example [not blaming anyone], a recent patch [2] that added a reasonable
WARN_ON_ONCE to assert_clock_updated() which, however, can result in a
possible printk() deadlock scenario that you, Petr, outlined [3]:

:+ printk()
:  + vprintk_func -> vprintk_default()
:+ vprinkt_emit()
:  + console_unlock()
:+ up_console_sem()
:  + up()# takes &sem->lock
:+ __up()
:  + wake_up_process()
:+ try_to_wake_up()
:  + ttwu_queue()
:+ ttwu_do_activate()
:  + ttwu_do_wakeup()
:+ rq_clock()
:  + lockdep_assert_held()
:+ WARN_ON_ONCE()
:  + printk()
:+ vprintk_func -> vprintk_default()
:  + vprintk_emit()
:+ console_try_lock()
:  + down_trylock_console_sem()
:+ __down_trylock_console_sem()
:  + down_trylock()


it takes a lot of additional effort, because both reviewer and contributor
must consider printk() internals. and, what's worse, if something goes
unnoticed we end up having a printk() deadlock again.

so I decided to address some of printk() issues in printk.c, not in
kernel/time/timekeeping.c or kernel/sched/core.c or anywhere else.


> Mid-air collision:
>
> I have just realized that Sergey sent another patchset that was
> more generic, complicated, and had some similarities, see
> https://lkml.kernel.org/r/20160927142237.5539-1-sergey.senozhat...@gmail.com

yeah, I should have Cc-ed a wider audience. do I need to resend the
patch set with the `extended' Cc list?


[1] https://marc.info/?l=linux-kernel&m=147158843319944
[2] https://marc.info/?l=linux-kernel&m=147446511924573
[3] https://marc.info/?l=linux-kernel&m=147447352127741

-ss

Re: [PATCH] clocksource: arm_arch_timer: Don't assume clock runs in suspend

[Brian Norris]

Hi Marc,

Thanks again for the help. I was checking with Rockchip on the details.

On Tue, Sep 20, 2016 at 08:47:07AM +0100, Marc Zyngier wrote:
> The counter is allowed to be clocked at a different rate, as long as it
> is incremented by the frequency ratio on each tick of the new frequency.
> In your case, the counter should increment by 750 on each tick of the
> 32kHz clock. If the rk3399 implementation doesn't do this, then this is
> a bug, and we need a quirk to work around it.

I had hope that we could find a switch that would do the above for
rk3399, since other parts of the system (e.g., the PMU itself) support
switching from the 24MHz to 32KHz clock, but Rockchip confirmed that it
is indeed a HW quirk that the arch timer's counter does not support
clocking out ticks based on the 32KHz clock. So I'm planning to send a
v2 that adds a "arm,no-tick-in-suspend" property.


rk3288 (ARMv7 system widely used for our Chromebooks) has the same
issue, except the kernel we're using for production (based on v3.14)
doesn't have the following commit, which stopped utilizing the RTC:

commit 0fa88cb4b82b5cf7429bc1cef9db006ca035754e
Author: Xunlei Pang 
Date:   Wed Apr 1 20:34:38 2015 -0700

time, drivers/rtc: Don't bother with rtc_resume() for the nonstop 
clocksource

And any mainline testing on rk3288 doesn't see the problem, because
mainline doesn't support its lowest-power sleep modes well enough (see
ROCKCHIP_ARM_OFF_LOGIC_DEEP in arch/arm/mach-rockchip/pm.c).


> Note that such a quirk will have some other impacts, such as the
> gettimeofday implementation in the VDSO (which relies on the counter
> making forward progress). There could be other issues in the timer
> subsystem as well... This doesn't look like a pleasant thing to fix.

How sure are you of these problems? I'm a bit new to the kernel
timekeeping subsystem, but doesn't this kind of code already have to
handle time adjustments like this when reprogramming the system time
(settimeofday())? And might we be covered for the suspend/resume case
when we allow the kernel to fall back to the RTC instead, which adjusts
the sleep delta with timekeeping_inject_sleeptime64()? And (weaker
evidence here) we haven't seen problems on rk3288 so far, at least
without the above referenced rtc commit 0fa88cb4b82. But admittedly
there are some differences between arch/{arm,arm64}/.

Regards,
Brian

Re: [PATCH v2 2/4] mfd: lpc_ich: Do not create iTCO watchdog when WDAT table exists

[Rafael J. Wysocki]

On Wednesday, September 28, 2016 02:09:41 AM Lee Jones wrote:
> On Wed, 28 Sep 2016, Rafael J. Wysocki wrote:
> 
> > On Tuesday, September 27, 2016 08:41:14 PM Lee Jones wrote:
> > > On Tue, 20 Sep 2016, Mika Westerberg wrote:
> > > 
> > > > ACPI WDAT table is the preferred way to use hardware watchdog over the
> > > > native iTCO_wdt. Windows only uses this table for its hardware watchdog
> > > > implementation so we should be relatively safe to trust it has been
> > > > validated by OEMs
> > > > 
> > > > Prevent iTCO watchdog creation if we detect that there is ACPI WDAT 
> > > > table.
> > > > 
> > > > Signed-off-by: Mika Westerberg 
> > > > Reviewed-by: Guenter Roeck 
> > > > ---
> > > >  drivers/mfd/lpc_ich.c | 4 
> > > >  1 file changed, 4 insertions(+)
> > > 
> > > Applied, thanks.
> > 
> > Well, I applied this too.
> 
> How can you apply this without an MFD Ack?

First, Guenter has reviewed it.

Second, there was no response to this:

http://marc.info/?l=linux-acpi&m=147467687316117&w=4

> > And it depends on the [1/4], doesn't it?
> 
> Yes, I just found that out myself. :)
> 
> Well I only have 4 lines of changes in drivers/mfd/lpc_ich.c, so I
> guess it'll be okay to apply this without the fear of conflicts.
> 
> Do that end, please apply my:
> 
> Acked-by: Lee Jones 

Thanks!

Best,
Rafael

Re: [PATCH v2 2/4] mfd: lpc_ich: Do not create iTCO watchdog when WDAT table exists

[Lee Jones]

On Wed, 28 Sep 2016, Rafael J. Wysocki wrote:

> On Tuesday, September 27, 2016 08:41:14 PM Lee Jones wrote:
> > On Tue, 20 Sep 2016, Mika Westerberg wrote:
> > 
> > > ACPI WDAT table is the preferred way to use hardware watchdog over the
> > > native iTCO_wdt. Windows only uses this table for its hardware watchdog
> > > implementation so we should be relatively safe to trust it has been
> > > validated by OEMs
> > > 
> > > Prevent iTCO watchdog creation if we detect that there is ACPI WDAT table.
> > > 
> > > Signed-off-by: Mika Westerberg 
> > > Reviewed-by: Guenter Roeck 
> > > ---
> > >  drivers/mfd/lpc_ich.c | 4 
> > >  1 file changed, 4 insertions(+)
> > 
> > Applied, thanks.
> 
> Well, I applied this too.

How can you apply this without an MFD Ack?

> And it depends on the [1/4], doesn't it?

Yes, I just found that out myself. :)

Well I only have 4 lines of changes in drivers/mfd/lpc_ich.c, so I
guess it'll be okay to apply this without the fear of conflicts.

Do that end, please apply my:

Acked-by: Lee Jones 
  
> > > diff --git a/drivers/mfd/lpc_ich.c b/drivers/mfd/lpc_ich.c
> > > index bd3aa4578346..c8dee47b45d9 100644
> > > --- a/drivers/mfd/lpc_ich.c
> > > +++ b/drivers/mfd/lpc_ich.c
> > > @@ -984,6 +984,10 @@ static int lpc_ich_init_wdt(struct pci_dev *dev)
> > >   int ret;
> > >   struct resource *res;
> > >  
> > > + /* If we have ACPI based watchdog use that instead */
> > > + if (acpi_has_watchdog())
> > > + return -ENODEV;
> > > +
> > >   /* Setup power management base register */
> > >   pci_read_config_dword(dev, priv->abase, &base_addr_cfg);
> > >   base_addr = base_addr_cfg & 0xff80;
> > 
> > 
> 
> Thanks,
> Rafael
> 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v6 1/4] mfd: mxs-lradc: Add support for mxs-lradc MFD

[Lee Jones]

On Sat, 17 Sep 2016, Ksenija Stanojevic wrote:

> Add core files for mxs-lradc MFD driver.
> 
> Note:  this patch won't compile in iio/testing without this patch:
> a8f447be8056 ("mfd: Add resource managed APIs for mfd_add_devices")
> 
> Signed-off-by: Ksenija Stanojevic 
> ---
> Changes in v6:
>  - update copyright
>  - add kernel-doc header for struct mxs-lradc
>  - add error message
>  - change EINVAL to ENODEV
>  - use PLATFORM_DEVID_NONE instead -1
>  - cosmetic fixes
> 
> Changes in v5:
>  - use DEFINE_RES_MEM
>  - don't pass ioreammaped adress to platform cells
>  - move comment outside of struct mxs_lradc
>  - change type of argument in mxs_lradc_reg_set, mxs_lradc_reg_clear,
>mxs_lradc_reg_wrt (struct mxs_lradc * -> void __iomem *)
> 
> Changes in v4:
>  - update copyright
>  - use DEFINE_RES_IRQ_NAMED
>  - remove mxs_lradc_add_device function
>  - use struct mfd_cell in static form
>  - improve spacing
>  - remove unnecessary comment
>  - remove platform_get_irq
>  - remove touch_ret and use ret instead
>  - rename use_touchscreen to touchscreen_wire
>  - use goto statements
>  - remove irq[13], irq_count and irq_name from struct mxs_lradc
>  - remove all defines from inside the struct definition
> 
> Changes in v3:
>  - add note to commit message
>  - move switch statement into if(touch_ret == 0) branch
>  - add MODULE_AUTHOR
> 
> Changes in v2:
>  - do not change spacing in Kconfig
>  - make struct mfd_cell part of struct mxs_lradc
>  - use switch instead of if in mxs_lradc_irq_mask
>  - use only necessary header files in mxs_lradc.h
>  - use devm_mfd_add_device
>  - use separate function to register mfd device
>  - change licence to GPL
>  - add copyright
> 
>  drivers/mfd/Kconfig   |  17 +++
>  drivers/mfd/Makefile  |   1 +
>  drivers/mfd/mxs-lradc.c   | 259 
> ++
>  include/linux/mfd/mxs-lradc.h | 203 +
>  4 files changed, 480 insertions(+)
>  create mode 100644 drivers/mfd/mxs-lradc.c
>  create mode 100644 include/linux/mfd/mxs-lradc.h
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 9ca66de..ffe14ef 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -271,6 +271,23 @@ config MFD_MC13XXX_I2C
>   help
> Select this if your MC13xxx is connected via an I2C bus.
>  
> +config MFD_MXS_LRADC
> + tristate "Freescale i.MX23/i.MX28 LRADC"
> + depends on ARCH_MXS || COMPILE_TEST
> + select MFD_CORE
> + select STMP_DEVICE
> + help
> +   Say yes here to build support for the Low Resolution
> +   Analog-to-Digital Converter (LRADC) found on the i.MX23 and i.MX28
> +   processors. This driver provides common support for accessing the
> +   device, additional drivers must be enabled in order to use the
> +   functionality of the device:
> + mxs-lradc-adc for ADC readings
> + mxs-lradc-ts  for touchscreen support
> +
> +   This driver can also be built as a module. If so, the module will be
> +   called mxs-lradc.
> +
>  config MFD_HI6421_PMIC
>   tristate "HiSilicon Hi6421 PMU/Codec IC"
>   depends on OF
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 0f230a6..ecf6399 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -198,3 +198,4 @@ intel-soc-pmic-objs   := 
> intel_soc_pmic_core.o intel_soc_pmic_crc.o
>  intel-soc-pmic-$(CONFIG_INTEL_PMC_IPC)   += intel_soc_pmic_bxtwc.o
>  obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
>  obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
> +obj-$(CONFIG_MFD_MXS_LRADC)  += mxs-lradc.o
> diff --git a/drivers/mfd/mxs-lradc.c b/drivers/mfd/mxs-lradc.c
> new file mode 100644
> index 000..05ae894
> --- /dev/null
> +++ b/drivers/mfd/mxs-lradc.c
> @@ -0,0 +1,259 @@
> +/*
> + * Freescale MXS LRADC driver

Please use the full name here.  It's helpful if people are trying to
figure out what LRADC actually means.

> + * Copyright (c) 2012 DENX Software Engineering, GmbH.
> + * Copyright (c) 2016 Ksenija Stanojevic 
> + *
> + * Authors:
> + *  Marek Vasut 
> + *  Ksenija Stanojevic 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MXS_LRADC_BASE   0x8005
> +
> +enum mx23_lradc_irqs {
> + MX23_LRADC_TS_IRQ = 0,
> + MX23_LRADC_CH0_IRQ,
> + MX23_LRADC_CH1_IRQ,
> + 

Re: [PATCH 4/3] g_NCR5380: Merge g_NCR5380 and g_NCR5380_mmio

[Finn Thain]

On Sun, 25 Sep 2016, Ondrej Zary wrote:

> Merge the PIO and MMIO code (with the help of ioport_map) in g_NCR5380 and
> delete g_NCR5380_mmio.
> 
> Signed-off-by: Ondrej Zary 
> ---
>  drivers/scsi/Kconfig  |   32 ++---
>  drivers/scsi/g_NCR5380.c  |  257 
> +++--
>  drivers/scsi/g_NCR5380.h  |   33 ++
>  drivers/scsi/g_NCR5380_mmio.c |   10 --
>  4 files changed, 135 insertions(+), 197 deletions(-)
>  delete mode 100644 drivers/scsi/g_NCR5380_mmio.c
> 
> diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
> index 7d1b431..fd1bca1 100644
> --- a/drivers/scsi/Kconfig
> +++ b/drivers/scsi/Kconfig
> @@ -780,40 +780,22 @@ config SCSI_ISCI
> control unit found in the Intel(R) C600 series chipset.
>  
>  config SCSI_GENERIC_NCR5380
> - tristate "Generic NCR5380/53c400 SCSI PIO support"
> + tristate "Generic NCR5380/53c400 SCSI"
>   depends on ISA && SCSI
>   select SCSI_SPI_ATTRS
>   ---help---
> -   This is a driver for the old NCR 53c80 series of SCSI controllers
> -   on boards using PIO. Most boards such as the Trantor T130 fit this
> -   category, along with a large number of ISA 8bit controllers shipped
> -   for free with SCSI scanners. If you have a PAS16, T128 or DMX3191
> -   you should select the specific driver for that card rather than
> -   generic 5380 support.
> +   This is a driver for the old NCR 53c80 series of SCSI controllers.
> +   Most boards such as the Trantor T130 fit this category, along with
> +   a large number of ISA 8bit controllers shipped for free with SCSI
> +   scanners. If you have a PAS16, T128 or DMX3191 you should select the
> +   specific driver for that card rather than generic 5380 support.

The pas16 and t128 drivers were removed (see 4.9/scsi-queue). The DMX3191 
isn't an ISA card, so it isn't relevant.

>  
> It is explained in section 3.8 of the SCSI-HOWTO, available from
> -   .  If it doesn't work out
> -   of the box, you may have to change some settings in
> -   .
> +   .

I didn't find anything useful at that url.

Therefore, please change the help text as follows:

diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 98e5d51..928d937 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -780,21 +780,14 @@ config SCSI_ISCI
  control unit found in the Intel(R) C600 series chipset.
 
 config SCSI_GENERIC_NCR5380
-   tristate "Generic NCR5380/53c400 SCSI PIO support"
+   tristate "Generic NCR5380/53C400 ISA card SCSI controller support"
depends on ISA && SCSI
select SCSI_SPI_ATTRS
---help---
- This is a driver for the old NCR 53c80 series of SCSI controllers
- on boards using PIO. Most boards such as the Trantor T130 fit this
- category, along with a large number of ISA 8bit controllers shipped
- for free with SCSI scanners. If you have a PAS16, T128 or DMX3191
- you should select the specific driver for that card rather than
- generic 5380 support.
-
- It is explained in section 3.8 of the SCSI-HOWTO, available from
- .  If it doesn't work out
- of the box, you may have to change some settings in
- .
+ This is a driver for old ISA card SCSI controllers based on the
+ NCR 5380, 53C80, 53C400 and 53C400A, and compatible DTC devices.
+ Most boards such as the Trantor T130 fit this category, along
+ with various 8-bit and 16-bit ISA cards bundled with SCSI scanners.
 
  To compile this driver as a module, choose M here: the
  module will be called g_NCR5380.


The rest of the patch looks good (aside from the missing module alias that 
Chrisoph mentioned).

Thanks.

-- 

Re: [RFC/RFT][PATCH v3 0/5] Functional dependencies between devices

[Rafael J. Wysocki]

On Tuesday, September 27, 2016 02:34:29 PM Lukas Wunner wrote:
> [+cc corbet]
> 
> To whom it may concern,
> 
> I made some notes while reviewing the state machine in patch 2 of this
> series and thought, why not rework it into something that could eventually
> go into the Documentation/ tree?
> 
> So here's an initial draft.  There's some introductory text plus
> a description of the state machine.  Just putting this out there now
> to ease reviewers' lives, despite the obvious WIP status.  I'll try to
> amend it as the series converges.
> 
> This is already rst-formatted but I haven't actually run it through
> sphinx yet.

Thanks a lot for doing this!

It looks good to me in general.  I think it would be good to add it to the
series at one point (if you don't mind).

I'm only a bit reluctant about advertising the usage of links between children
and parents, because that doesn't look like the right tool for the purpose
(as I said before, I'd prefer to add a device flag causing the parent driver
to be probed before the child one if needed).

Thanks,
Rafael


> -- >8 --
> 
> Subject: [PATCH] Documentation: device links: Add initial documentation
> 
> Signed-off-by: Lukas Wunner 
> ---
>  Documentation/driver-model/device_link.rst | 95 
> ++
>  1 file changed, 95 insertions(+)
>  create mode 100644 Documentation/driver-model/device_link.rst
> 
> diff --git a/Documentation/driver-model/device_link.rst 
> b/Documentation/driver-model/device_link.rst
> new file mode 100644
> index 000..ba911b4
> --- /dev/null
> +++ b/Documentation/driver-model/device_link.rst
> @@ -0,0 +1,95 @@
> +
> +Device links
> +
> +
> +By default, the driver core only enforces dependencies between devices
> +that are borne out of a parent/child relationship within the device
> +hierarchy: When suspending, resuming or shutting down the system, devices
> +are ordered based on this relationship, i.e. children are always suspended
> +before their parent, and the parent is always resumed before its children.
> +
> +Sometimes there is a need to represent device dependencies beyond the
> +mere parent/child relationship, e.g. between siblings, and have the
> +driver core automatically take care of them.
> +
> +Secondly, the driver core by default does not enforce any driver presence
> +dependencies, i.e. that one device must be bound to a driver before
> +another one can probe or function correctly.
> +
> +Often these two dependency types come together, so a device depends on
> +another one both with regards to driver presence *and* with regards to
> +suspend/resume and shutdown ordering.
> +
> +Device links allow representation of such dependencies in the driver core.
> +
> +In its standard form, a device link combines *both* dependency types:
> +It guarantees correct suspend/resume and shutdown ordering between a
> +"supplier" device and its "consumer" devices, and it guarantees driver
> +presence on the supplier:  The consumer devices are not probed before the
> +supplier is bound to a driver, and they're unbound before the supplier
> +is unbound.
> +
> +When driver presence on the supplier is irrelevant and only correct
> +suspend/resume and shutdown ordering is needed, the device link may
> +simply be set up with the DEVICE_LINK_STATELESS flag.
> +
> +A driver presence dependency between parent and child, i.e. within the
> +regular device hierarchy, could in principle also be represented in the
> +driver core using a device link.
> +
> +If a device link is set up with the DEVICE_LINK_AUTOREMOVE flag, it is
> +automatically purged when the consumer fails to probe or later unbinds.
> +This is handy when adding a device link from the consumer's ->probe hook,
> +as it obviates the need to delete the link in the ->remove hook or in
> +the error path of the ->probe hook.
> +
> +
> +State machine
> +=
> +
> +"""
> +.=.
> +| |
> +v |
> +DORMANT <=> AVAILABLE <=> CONSUMER_PROBE => ACTIVE
> +   ^  |
> +   |  |
> +   ' SUPPLIER_UNBIND <'
> +"""
> +
> +* The initial state of a device link is passed in to device_link_add().
> +  If the link is created before any devices are probed, it must be set to
> +  DEVICE_LINK_DORMANT.
> +
> +* When a supplier device is bound to a driver, links to its consumers
> +  progress to DEVICE_LINK_AVAILABLE.
> +  (Call to device_links_driver_bound() from driver_bound().)
> +
> +* Before a consumer device is probed, presence of supplier drivers is
> +  verified by checking that links to suppliers are in DEVICE_LINK_AVAILABLE
> +  state.  The state of the links is updated to DEVICE_LINK_CONSUMER_PROBE.
> +  (Call to device_links_check_suppliers() from driver_probe_device().)
> +  This prevents the supplier from unbinding.
> + 

Re: NMI for ARC

[Vineet Gupta]

Hi Peter,

On 11/17/2015 05:15 AM, Peter Zijlstra wrote:
> On Tue, Nov 17, 2015 at 06:23:21PM +0530, Vineet Gupta wrote:
>> On Tuesday 17 November 2015 05:55 PM, Peter Zijlstra wrote:
>>
>>> This is assuming you now have these NMIs we talked about earlier. If all
>>> you have are regular IRQs this is not possible, for we should be calling
>>> ->read() with IRQs disabled.
>>>
>>
>> No we don't yet. The first stab at it fell flat on floor.
>>
>> The NMI support from hardware is that is it provides different priorities, 
>> higher
>> one obviously able to interrupt lower one. However instructions like CLRI 
>> (disable
>> interrupts) will still lock out all interrupts.
>>
>> Thus local_irq_save()/restore() and local_irq_enable()/disable() now need to 
>> be
>> contextual.
>>
>>   - When running in prio 0 mode, they only need to enable 0
>>   - In prio 1, they need to enable both 0 and 1
>>
>> For irq_save()/restore() this is achievable by doing an additional STATUS32 
>> read
>> at the time of save and passing that value to restore - so there's an 
>> additional
>> overhead - but ignoring that for now.
>>
>> Bummer is irq_disable()/enable() case: there's need to pass old prio state 
>> from
>> enable to disabled, so we need some sort of global state tracking - which in 
>> case
>> of SMP needs to be per cpu either keep something hot in a reg or pay the 
>> cost
>> of additional mem/cache line miss.
>>
>> I've not investigated how other arches do that. PPC seems to be using some 
>> sort of
>> soft irq state anyways.
> 
> Yeah, Sparc64 might be a better example, it more closely matches your
> hardware. See
> arch/sparc/include/asm/irqflags_64.h:arch_local_irq_save().

So I finally got around to doing this and as expected has turned out to be quite
some fun. I have a couple of questions and would really appreciate your inputs 
there.

1. Is it OK in general to short-circuit preemption off irq checks for NMI style
interrupts. The issue is we can get nested interrupts (timer followed by perf)
and one of them can cause resched_curr() to a user task - but we can't return to
user mode from inner interrupt. So it becomes easy if we don't even bother
checking for TIF_NEED_RESCHED in perf intr path. This also has slight advantage
that perf intr returns quickly. Implementation wise this requires a hack to bump
preemption count in the low level nmi handler - and revert that in nmi return 
path.

2. The low level return code, resume_user_mode_begin and/or resume_kernel_mode
require interrupt safety, does that need to be NMI safe as well. We ofcourse 
want
the very late register restore parts to be non-interruptible, but is this 
required
before we call prrempt_schedule_irq() off of asm code.

Thx,
-Vineet

Re: [PATCH 3/4] autofs - make mountpoint checks namespace aware

[Ian Kent]

On Tue, 2016-09-27 at 08:14 -0500, Eric W. Biederman wrote:
> Ian Kent  writes:
> 
> > On Mon, 2016-09-26 at 11:05 -0500, Eric W. Biederman wrote:
> > > Ian Kent  writes:
> > > 
> > > > On Fri, 2016-09-23 at 14:15 -0500, Eric W. Biederman wrote:
> > > > > Ian Kent  writes:
> > > > > 
> > > > > 2> On Thu, 2016-09-22 at 20:37 -0500, Eric W. Biederman wrote:
> > > > > > > Ian Kent  writes:
> > > > > > > 
> > > > > > > > On Thu, 2016-09-22 at 10:43 -0500, Eric W. Biederman wrote:
> > > > > > > > > Ian Kent  writes:
> > > > > > > > > 
> > > > > > > > > > Eric, Mateusz, I appreciate your spending time on this and
> > > > > > > > > > particularly
> > > > > > > > > > pointing
> > > > > > > > > > out my embarrassingly stupid is_local_mountpoint() usage
> > > > > > > > > > mistake.
> > > > > > > > > > 
> > > > > > > > > > Please accept my apology for the inconvenience.
> > > > > > > > > > 
> > > > > > > > > > If all goes well (in testing) I'll have follow up patches to
> > > > > > > > > > correct
> > > > > > > > > > this
> > > > > > > > > > fairly
> > > > > > > > > > soon.
> > > > > > > > > 
> > > > > > > > > Related question.  Do you happen to know how many mounts per
> > > > > > > > > mount
> > > > > > > > > namespace tend to be used?  It looks like it is going to be
> > > > > > > > > wise
> > > > > > > > > to
> > > > > > > > > put
> > > > > > > > > a configurable limit on that number.  And I would like the
> > > > > > > > > default
> > > > > > > > > to
> > > > > > > > > be
> > > > > > > > > something high enough most people don't care.  I believe
> > > > > > > > > autofs is
> > > > > > > > > likely where people tend to use the most mounts.
> > > > > > 
> > > > > > Yes, I agree, I did want to try and avoid changing the parameters to
> > > > > > ->d_mamange() but passing a struct path pointer might be better in
> > > > > > the
> > > > > > long
> > > > > > run
> > > > > > anyway.
> > > > > 
> > > > > Given that there is exactly one implementation of d_manage in the tree
> > > > > I
> > > > > don't imagine it will be disruptive to change that.
> > > > 
> > > > Yes, but it could be used by external modules.
> > > > 
> > > > And there's also have_submounts().
> > > 
> > > Good point about have_submounts.
> > > 
> > > > I can update that using the existing d_walk() infrastructure or take it
> > > > (mostly)
> > > > into the autofs module and get rid of have_submounts().
> > > > 
> > > > I'll go with the former to start with and see what people think.
> > > 
> > > That will be interesting to so.  It is not clear to me that if d_walk
> > > needs to be updated, and if d_walk doesn't need to be updated I would
> > > be surprised to see it take into autofs.  But I am happy to look at the
> > > end result and see what you come up with.
> > 
> > I didn't mean d_walk() itself, just the have_submounts() function that's
> > used
> > only by autofs these days. That's all I'll be changing.
> > 
> > To take this functionality into the autofs module shouldn't be a big deal as
> > it
> > amounts to a directory traversal with a check at each node.
> > 
> > But I vaguely remember talk of wanting to get rid of have_submounts() and
> > autofs
> > being the only remaining user.
> > 
> > So I mentioned it to try and elicit a comment, ;)
> 
> From my perspective the key detail is that d_walk is private to dcache.c
> 
> That said you want to look at may_umount_tree, or may_umount that
> are already exported from fs/namespace.c, and already used by autofs.
> One of those may already do the job you are trying to do.

Right, I'm aware of them, autofs uses may_umount() when asking if an autofs
mount can be umounted, and it uses may_umount_tree() to check busyness in its
expire.

may_umount_tree() (and may_umount()) won't tell you if there are any mounts
within the directory tree, only that there is an elevated reference count, for
example an open file or working directory etc., ie. busy.

OTOH, have_submounts() will return true as soon as it encounters a
d_mountpoint() dentry in the directory tree which is what's needed where it's
used and why it can return a false positive for the problem case.

I get that a function, say, path_has_submounts() probably shouldn't be placed in
dcache.c and that's another reason to take the traversal into autofs. 

But if there's no word from Al on that I'd prefer to use d_walk() and put it
there.

Ian

RE: [PATCH 1/2 v2] pci-hyperv: properly handle pci bus remove

[Long Li]

> -Original Message-
> From: Bjorn Helgaas [mailto:helg...@kernel.org]
> Sent: Tuesday, September 27, 2016 12:30 PM
> To: Long Li 
> Cc: KY Srinivasan ; Haiyang Zhang
> ; Bjorn Helgaas ;
> de...@linuxdriverproject.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Long Li 
> Subject: Re: [PATCH 1/2 v2] pci-hyperv: properly handle pci bus remove
> 
> On Wed, Sep 14, 2016 at 07:10:01PM -0700, Long Li wrote:
> > From: Long Li 
> >
> > hv_pci_devices_present is called in hv_pci_remove when we remove a PCI
> device from host (e.g. by disabling SRIOV on a device). In hv_pci_remove,
> the bus is already removed before the call, so we don't need to rescan the
> bus in the workqueue scheduled from hv_pci_devices_present. By
> introducing status hv_pcibus_removed, we can avoid this situation.
> >
> > The patch fixes the following kernel panic.
> >
> > [  383.853124] Workqueue: events pci_devices_present_work [pci_hyperv]
> > [  383.853124] task: 88007f5f8000 ti: 88007f60 task.ti:
> > 88007f60
> > [  383.853124] RIP: 0010:[]  []
> > pci_is_pcie+0x6/0x20
> > [  383.853124] RSP: 0018:88007f603d38  EFLAGS: 00010206 [
> > 383.853124] RAX: 88007f5f8000 RBX: 642f3d4854415056 RCX:
> > 88007f603fd8
> > [  383.853124] RDX:  RSI:  RDI:
> > 642f3d4854415056
> > [  383.853124] RBP: 88007f603d68 R08: 0246 R09:
> > a045eb9e
> > [  383.853124] R10: 88007b419a80 R11: ea0001c0ef40 R12:
> > 880003ee1c00
> > [  383.853124] R13: 63702f30303a3137 R14:  R15:
> > 0246
> > [  383.853124] FS:  () GS:88007b40()
> > knlGS:
> > [  383.853124] CS:  0010 DS:  ES:  CR0: 80050033 [
> > 383.853124] CR2: 7f68b3f52350 CR3: 03546000 CR4:
> > 000406f0
> > [  383.853124] DR0:  DR1:  DR2:
> > 
> > [  383.853124] DR3:  DR6: 0ff0 DR7:
> > 0400
> > [  383.853124] Stack:
> > [  383.853124]  88007f603d68 8134db17 0008
> > 880003ee1c00
> > [  383.853124]  63702f30303a3137 880003d8edb8 88007f603da0
> > 8134ee2d [  383.853124]  880003d8ed00 88007f603dd8
> > 880075fec320
> > 880003d8edb8
> > [  383.853124] Call Trace:
> > [  383.853124]  [] ? pci_scan_slot+0x27/0x140 [
> > 383.853124]  [] pci_scan_child_bus+0x3d/0x150 [
> > 383.853124]  []
> > pci_devices_present_work+0x3ea/0x400 [pci_hyperv] [  383.853124]
> > [] process_one_work+0x17b/0x470 [  383.853124]
> > [] worker_thread+0x126/0x410 [  383.853124]
> > [] ? rescuer_thread+0x460/0x460 [  383.853124]
> > [] kthread+0xcf/0xe0 [  383.853124]
> > [] ?
> > kthread_create_on_node+0x140/0x140
> > [  383.853124]  [] ret_from_fork+0x58/0x90 [
> > 383.853124]  [] ?
> > kthread_create_on_node+0x140/0x140
> > [  383.853124] Code: 89 e5 5d 25 f0 00 00 00 c1 f8 04 c3 66 0f 1f 84
> > 00
> > 00 00 00 00 66 66 66 66 90 55 0f b6 47 4a 48 89 e5 5d c3 90 66 66 66
> > 66
> > 90 55 <80> 7f 4a 00 48 89 e5 5d 0f 95 c0 c3 0f 1f 40 00 66 2e 0f 1f 84
> > [  383.853124] RIP  [] pci_is_pcie+0x6/0x20 [
> > 383.853124]  RSP 
> 
> Personally, I would remove the timestamps and addresses from this trace
> because I don't think they contribute to diagnosing the problem.

Thanks Bjorn. I will remove those kernel traces and send a v3 patch.

> 
> > Signed-off-by: Long Li 
> 
> I'm ready to apply these but am waiting for an ack from the maintainers listed
> in MAINTAINERS (feel free to update that if it's out of date).
> 
> > ---
> >  drivers/pci/host/pci-hyperv.c | 20 +---
> >  1 file changed, 17 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/pci/host/pci-hyperv.c
> > b/drivers/pci/host/pci-hyperv.c index a8deeca..4a37598 100644
> > --- a/drivers/pci/host/pci-hyperv.c
> > +++ b/drivers/pci/host/pci-hyperv.c
> > @@ -348,6 +348,7 @@ enum hv_pcibus_state {
> > hv_pcibus_init = 0,
> > hv_pcibus_probed,
> > hv_pcibus_installed,
> > +   hv_pcibus_removed,
> > hv_pcibus_maximum
> >  };
> >
> > @@ -1481,13 +1482,24 @@ static void pci_devices_present_work(struct
> work_struct *work)
> > put_pcichild(hpdev, hv_pcidev_ref_initial);
> > }
> >
> > -   /* Tell the core to rescan bus because there may have been changes.
> */
> > -   if (hbus->state == hv_pcibus_installed) {
> > +   switch (hbus->state) {
> > +   case hv_pcibus_installed:
> > +   /*
> > +* Tell the core to rescan bus
> > +* because there may have been changes.
> > +*/
> > pci_lock_rescan_remove();
> > pci_scan_child_bus(hbus->pci_bus);
> > pci_unlock_rescan_remove();
> > -   } else {
> > +   break;
> > +
> > +   case hv_pcibus_init:
> > +   case hv_pcibus_probed:
> > survey_child_resources(hbus);
> > +   break;
> > +
> > +   default:
> > +   bre

Re: [PATCH 3/3] g_NCR5380: Stop using scsi_module.c

[Finn Thain]

On Tue, 27 Sep 2016, Ondrej Zary wrote:

> On Monday 26 September 2016, Finn Thain wrote:
> 
> [...]
> 
> > > @@ -364,7 +304,7 @@ static int generic_NCR5380_release_resources(struct
> > > Scsi_Host *instance) release_mem_region(instance->base,
> > > hostdata->iomem_size);
> > >   }
> > >  #endif
> > > - return 0;
> > > + scsi_host_put(instance);
> >
> > The sequence of operations here should be the same as the error path
> > above.
> 
> I put scsi_host_put() call at the end because the release_mem_region 
> code (in the MMIO case) dereferences the hostdata pointer. I don't think 
> it's safe to do after scsi_host_put().

It's funny you say that, I already fixed a few of those use-after-free 
bugs in the other 5380 drivers. To avoid the bug, you'd need to use a 
temporary variable, like the fixes I did elsewhere.

Don't worry about changing it, this part of the driver gets revisited in 
my existing patch queue anyway.

> 
> [...]
> 
> > > +static int pnp_registered;
> > > +#endif /* !defined(SCSI_G_NCR5380_MEM) && defined(CONFIG_PNP) */
> > > +
> > > +static int __init generic_NCR5380_init(void)
> > > +{
> > > + int ret = 0;
> > > +
> > > +#if !defined(SCSI_G_NCR5380_MEM) && defined(CONFIG_PNP)
> > > + ret = pnp_register_driver(&generic_NCR5380_pnp_driver);
> > > + if (!ret)
> > > + pnp_registered = 1;
> > >  #endif
> > > + ret = isa_register_driver(&generic_NCR5380_isa_driver, MAX_CARDS);
> > > + if (!ret)
> > > + isa_registered = 1;
> > > +
> > > +#if !defined(SCSI_G_NCR5380_MEM) && defined(CONFIG_PNP)
> > > + if (pnp_registered)
> > > + ret = 0;
> > > +#endif
> > > + if (isa_registered)
> > > + ret = 0;
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +static void __exit generic_NCR5380_exit(void)
> > > +{
> > > +#if !defined(SCSI_G_NCR5380_MEM) && defined(CONFIG_PNP)
> > > + if (pnp_registered)
> > > + pnp_unregister_driver(&generic_NCR5380_pnp_driver);
> > > +#endif
> > > + if (isa_registered)
> > > + isa_unregister_driver(&generic_NCR5380_isa_driver);
> > > +}
> > > +
> >
> > I find that hard to follow. This should be equivalent and simpler:
> >
> > static int __init generic_NCR5380_init(void)
> > {
> > isa_ret = isa_register_driver(&generic_NCR5380_isa_driver, MAX_CARDS);
> > #if !defined(SCSI_G_NCR5380_MEM) && defined(CONFIG_PNP)
> > pnp_ret = pnp_register_driver(&generic_NCR5380_pnp_driver);
> > return pnp_ret ? isa_ret : 0;
> > #endif
> > return isa_ret;
> > }
> >
> > static void __exit generic_NCR5380_exit(void)
> > {
> > if (!isa_ret)
> > isa_unregister_driver(&generic_NCR5380_isa_driver);
> > #if !defined(SCSI_G_NCR5380_MEM) && defined(CONFIG_PNP)
> > if (!pnp_ret)
> > pnp_unregister_driver(&generic_NCR5380_pnp_driver);
> > #endif
> > }
> 
> Doesn't make it any better, IMHO. Good that it's shorter but not cleaner - 
> especially this:
> > return pnp_ret ? isa_ret : 0;

The problem with that line is that pnp_ret is always discarded, same as in 
your version. I think my version makes that clear, which is what matters 
to me.

> 
> Also looking at the _exit function, meaning of isa_ret and pnp_ret is not 
> obvious there.
> 
> Maybe we should have a module_isa_pnp_driver() macro.
> 
> 

FWIW I would hope that the hypothetical definition of this 
`module_isa_pnp_driver' macro would have the same properties as my 
version: shorter, uses no temporaries and uses one less #ifdef, and is 
generally easier for me to read.

-- 

Re: [PATCH 1/3] arm: dts: imx7: Update #pwm-cells for PWM polarity control

[Bhuvanchandra DV]

On 09/23/16 23:22, Rob Herring wrote:


On Mon, Sep 19, 2016 at 07:53:45PM +0530, Bhuvanchandra DV wrote:

Update #pwm-cells to 3 in order to support PWM signal polarity control.

Signed-off-by: Bhuvanchandra DV 
---
  Documentation/devicetree/bindings/pwm/imx-pwm.txt | 6 +++---
  arch/arm/boot/dts/imx7s.dtsi  | 8 
  2 files changed, 7 insertions(+), 7 deletions(-)

The driver will still work with old DTs, right? If so,


This patchset actually depends on the v6 patchset[1] from Lothar.
Some how that patchset got stalled in ML. I will re-spin the v6
patchset with the suggestions/changes from Lukasz in this patch[2]
after testing.

[1]http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/294027.html
[2]https://www.spinics.net/lists/arm-kernel/msg530818.html



Acked-by: Rob Herring 

[PATCH 1/2] Input: introduce ABS_MAX2/CNT2 and friends

[Roderick Colenbrander]

From: Roderick Colenbrander 

David Herrmann's original patch was ported over to a modern Linux kernel.
In the process, we went over all the feedback to the original patch series
and added various improvements:

- evdev_handle_get_abs2 returns valid_cnt instead of 0 when succesfull
- Updated documentation of EVIOCGABS2/EVIOCSABS2 ioctls based.
- Clarified language around ABS_MAX2 definition, to state the *ABS2 ioctls
  should be used for the full range.

[PATCH 2/4] Input: introduce ABS_MAX2/CNT2 and friends

David Herrmann 
Tue Dec 17 07:48:52 PST 2013
Previous message: [PATCH 1/4] Input: uinput: add full absinfo support
Next message: [PATCH 2/4] Input: introduce ABS_MAX2/CNT2 and friends
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
As we painfully noticed during the 3.12 merge-window our
EVIOCGABS/EVIOCSABS API is limited to ABS_MAX<=0x3f. We tried several
hacks to work around it but if we ever decide to increase ABS_MAX, the
EVIOCSABS ioctl ABI might overflow into the next byte causing horrible
misinterpretations in the kernel that we cannot catch.

Therefore, we decided to go with ABS_MAX2/CNT2 and introduce two new
ioctls to get/set abs-params. They no longer encode the ABS code in the
ioctl number and thus allow up to 4 billion ABS codes.

The new API also allows to query multiple ABS values with one call. To
allow EVIOCSABS2(code = 0, cnt = ABS_CNT2) we need to silently ignore
writes to ABS_MT_SLOT. Furthermore, for better compatibility with
newer user-space, we ignore writes to unknown codes. Hence, if we ever
increase ABS_MAX2, new user-space will work with code=0,cnt=ABS_CNT2 just
fine even on old kernels.

Note that we also need to increase EV_VERSION so user-space can reliably
know whether ABS2 is supported. Unfortunately, we return EINVAL instead of
ENOSYS for unknown evdev ioctls so it's nearly impossible to catch
reliably without EVIOCGVERSION.

Signed-off-by: David Herrmann 
Signed-off-by: Roderick Colenbrander 
---
 drivers/hid/hid-debug.c  |  2 +-
 drivers/hid/hid-input.c  |  2 +-
 drivers/input/evdev.c| 95 +++-
 drivers/input/input.c| 14 ++---
 drivers/input/keyboard/goldfish_events.c |  6 +-
 drivers/input/keyboard/hil_kbd.c |  2 +-
 drivers/input/misc/uinput.c  |  8 +--
 include/linux/hid.h  |  2 +-
 include/linux/input.h|  6 +-
 include/linux/mod_devicetable.h  |  2 +-
 include/uapi/linux/input-event-codes.h   | 14 -
 include/uapi/linux/input.h   | 37 -
 12 files changed, 165 insertions(+), 25 deletions(-)

diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c
index acfb522..7205d4a 100644
--- a/drivers/hid/hid-debug.c
+++ b/drivers/hid/hid-debug.c
@@ -963,7 +963,7 @@ static const char *relatives[REL_MAX + 1] = {
[REL_WHEEL] = "Wheel",  [REL_MISC] = "Misc",
 };
 
-static const char *absolutes[ABS_CNT] = {
+static const char *absolutes[ABS_CNT2] = {
[ABS_X] = "X",  [ABS_Y] = "Y",
[ABS_Z] = "Z",  [ABS_RX] = "Rx",
[ABS_RY] = "Ry",[ABS_RZ] = "Rz",
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index bcfaf32..26b161d 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -1411,7 +1411,7 @@ static bool hidinput_has_been_populated(struct hid_input 
*hidinput)
for (i = 0; i < BITS_TO_LONGS(REL_CNT); i++)
r |= hidinput->input->relbit[i];
 
-   for (i = 0; i < BITS_TO_LONGS(ABS_CNT); i++)
+   for (i = 0; i < BITS_TO_LONGS(ABS_CNT2); i++)
r |= hidinput->input->absbit[i];
 
for (i = 0; i < BITS_TO_LONGS(MSC_CNT); i++)
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index e9ae3d5..569e425 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -815,7 +815,7 @@ static int handle_eviocgbit(struct input_dev *dev,
case  0: bits = dev->evbit;  len = EV_MAX;  break;
case EV_KEY: bits = dev->keybit; len = KEY_MAX; break;
case EV_REL: bits = dev->relbit; len = REL_MAX; break;
-   case EV_ABS: bits = dev->absbit; len = ABS_MAX; break;
+   case EV_ABS: bits = dev->absbit; len = ABS_MAX2; break;
case EV_MSC: bits = dev->mscbit; len = MSC_MAX; break;
case EV_LED: bits = dev->ledbit; len = LED_MAX; break;
case EV_SND: bits = dev->sndbit; len = SND_MAX; break;
@@ -827,6 +827,93 @@ static int handle_eviocgbit(struct input_dev *dev,
return bits_to_user(bits, len, size, p, compat_mode);
 }
 
+static int evdev_handle_get_abs2(struct input_dev *dev, void __user *p)
+{
+   u32 code, cnt, valid_cnt, i;
+   struct input_absinfo2 __user *pinfo = p;
+   struct input_absinfo abs;
+
+   if (copy_from_user(&code, &pinfo->code, sizeof(code)))
+   return -EFAULT;
+   if (copy_from_user(&cnt, &pinfo->cnt, sizeof(cnt))

[PATCH 2/2] Input: add motion-tracking ABS_* bits and docs

[Roderick Colenbrander]

From: Roderick Colenbrander 

This patch introduces new axes for acceleration and angular velocity.
David Herrmann's work served as a base, but we extended the specification
with various changes inspired by real devices and challenges we see
when doing motion tracking.

- Changed unit of acceleration to G instead of m/s^2. We felt that m/s^2
  is not the appropriate unit to return, because accelerometers are most
  often calibrated based on gravity. They return values in multiples of
  G and since we don't know the device location on earth, we should not
  blindly multiply by '9.8' for accuracy reasons. Such conversion is left
  to userspace.
- Resolution field is used for acceleration and gyro to report precision.
  The previous spec, specified to map 1 unit to e.g. 0.001 deg/s or 0.001 m/s^2.
  This is of course simpler for applications, but unit definition is a bit
  arbitrary. Previous axes definitions used the resolution field, which
  felt more consistent.
- Added section on timestamps, which are important for accurate motion
  tracking purposes. The use of MSC_TIMESTAMP was recommended in this
  situation to get access to the hardware timestamp if available.
- Changed motion axes to be defined as a right-handed coordinate system.
  Due to this change the gyro vectors are now defined as counter-clockwise.
  The overall changes makes the definitions consistent with computer graphics.

[PATCH 4/4] Input: add motion-tracking ABS_* bits and docs
David Herrmann 
Tue Dec 17 07:48:54 PST 2013

Motion sensors are getting quite common in mobile devices. To avoid
returning accelerometer data via ABS_X/Y/Z and irritating the Xorg
mouse-driver, this adds separate ABS_* bits for that.

This is needed if gaming devices want to report their normal data plus
accelerometer/gyro data. Usually, ABS_X/Y are already used by analog
sticks, so need separate definitions, anyway.

Signed-off-by: David Herrmann 
Signed-off-by: Roderick Colenbrander 
---
 Documentation/input/gamepad.txt |   9 +-
 Documentation/input/motion-tracking.txt | 176 
 include/uapi/linux/input-event-codes.h  |   7 ++
 3 files changed, 190 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/input/motion-tracking.txt

diff --git a/Documentation/input/gamepad.txt b/Documentation/input/gamepad.txt
index 3f6d8a5..ed13782 100644
--- a/Documentation/input/gamepad.txt
+++ b/Documentation/input/gamepad.txt
@@ -57,6 +57,9 @@ Most gamepads have the following features:
   - Rumble
 Many devices provide force-feedback features. But are mostly just
 simple rumble motors.
+  - Motion-tracking
+Gamepads may include motion-tracking sensors like accelerometers and
+gyroscopes.
 
 3. Detection
 
@@ -138,8 +141,6 @@ Triggers:
   Upper trigger buttons are reported as BTN_TR or ABS_HAT1X (right) and BTN_TL
   or ABS_HAT1Y (left). Lower trigger buttons are reported as BTN_TR2 or
   ABS_HAT2X (right/ZR) and BTN_TL2 or ABS_HAT2Y (left/ZL).
-  If only one trigger-button combination is present (upper+lower), they are
-  reported as "right" triggers (BTN_TR/ABS_HAT1X).
 (ABS trigger values start at 0, pressure is reported as positive values)
 
 Menu-Pad:
@@ -155,5 +156,9 @@ Menu-Pad:
 Rumble:
   Rumble is advertised as FF_RUMBLE.
 
+Motion-tracking:
+  Motion-tracking is defined in ./Documentation/input/motion-tracking.txt and
+  gamepads shall comply to the rules defined there.
+
 
   Written 2013 by David Herrmann 
diff --git a/Documentation/input/motion-tracking.txt 
b/Documentation/input/motion-tracking.txt
new file mode 100644
index 000..d34a290
--- /dev/null
+++ b/Documentation/input/motion-tracking.txt
@@ -0,0 +1,176 @@
+   Motion Tracking API
+
+
+1. Intro
+
+Motion tracking devices produce device motion events generated from an
+accelerometer, gyroscope or compass. These data can be returned to user-space
+via input events. This document defines how these data are reported.
+
+2. Devices
+~~
+In this document, a "device" is one of:
+ - accelerometer
+ - gyroscope
+ - compass
+
+These devices returned their information via different APIs in the past. To
+unify them and define a common API, a set of input evdev codes was created. Old
+drivers might continue using their API, but developers are encouraged to use
+the input evdev API for new drivers.
+
+2.1 Axes
+
+Movement data is usually returned as absolute data for the 3 axes of a device.
+In this context, the three axes are defined in a right-handed coordinate
+system as:
+ - X: Axis goes from the left to the right side of the device
+ - Y: Axis goes from the bottom to the top of the device
+ - Z: Axis goes from the back to the front of the device
+
+The front of a device is the side faced to the user. For a mobile-phone it
+would be the 

Re: [PATCH 2/2] mfd: arizona: Handle probe deferral for reset GPIO

[Lee Jones]

On Tue, 20 Sep 2016, Charles Keepax wrote:

> The Arizona CODECs will generally function correctly without a reset line
> although it is strongly advised to have one, as such we do allow the system
> to boot if the reset gpio is missing or incorrectly specified.  However
> we should fail probe if we get a probe deferral request, this patch adds
> handling for this case.
> 
> Reported-by: Richard Fitzgerald 
> Signed-off-by: Charles Keepax 
> ---
>  drivers/mfd/arizona-core.c | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
> index f466f29..d18f3b1 100644
> --- a/drivers/mfd/arizona-core.c
> +++ b/drivers/mfd/arizona-core.c
> @@ -813,7 +813,9 @@ static int arizona_of_get_core_pdata(struct arizona 
> *arizona)
>   int count = 0;
>  
>   pdata->reset = of_get_named_gpio(arizona->dev->of_node, "wlf,reset", 0);
> - if (pdata->reset < 0) {
> + if (pdata->reset == -EPROBE_DEFER) {
> + return pdata->reset;
> + } else if (pdata->reset < 0) {
>   dev_err(arizona->dev, "Reset gpio missing/malformed: %d\n",
>   pdata->reset);
>  
> @@ -1011,11 +1013,14 @@ int arizona_dev_init(struct arizona *arizona)
>   dev_set_drvdata(arizona->dev, arizona);
>   mutex_init(&arizona->clk_lock);
>  
> - if (dev_get_platdata(arizona->dev))
> + if (dev_get_platdata(arizona->dev)) {
>   memcpy(&arizona->pdata, dev_get_platdata(arizona->dev),
>  sizeof(arizona->pdata));
> - else
> - arizona_of_get_core_pdata(arizona);
> + } else {
> + ret = arizona_of_get_core_pdata(arizona);
> + if (ret < 0)
> + return ret;
> + }
>  
>   BUILD_BUG_ON(ARRAY_SIZE(arizona->mclk) != ARRAY_SIZE(mclk_name));
>   for (i = 0; i < ARRAY_SIZE(arizona->mclk); i++) {

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 1/2] mfd: arizona: Remove arizona_of_get_named_gpio helper function

[Lee Jones]

On Tue, 20 Sep 2016, Charles Keepax wrote:

> This function is only used in a single place and no new users will be
> added as all the devices other required GPIOs are already handled. As
> such just merge the code back into the calling function.
> 
> Signed-off-by: Charles Keepax 
> ---
>  drivers/mfd/arizona-core.c   | 27 +++
>  include/linux/mfd/arizona/core.h |  3 ---
>  2 files changed, 7 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
> index 4c18c8e..f466f29 100644
> --- a/drivers/mfd/arizona-core.c
> +++ b/drivers/mfd/arizona-core.c
> @@ -803,25 +803,6 @@ unsigned long arizona_of_get_type(struct device *dev)
>  }
>  EXPORT_SYMBOL_GPL(arizona_of_get_type);
>  
> -int arizona_of_get_named_gpio(struct arizona *arizona, const char *prop,
> -   bool mandatory)
> -{
> - int gpio;
> -
> - gpio = of_get_named_gpio(arizona->dev->of_node, prop, 0);
> - if (gpio < 0) {
> - if (mandatory)
> - dev_err(arizona->dev,
> - "Mandatory DT gpio %s missing/malformed: %d\n",
> - prop, gpio);
> -
> - gpio = 0;
> - }
> -
> - return gpio;
> -}
> -EXPORT_SYMBOL_GPL(arizona_of_get_named_gpio);
> -
>  static int arizona_of_get_core_pdata(struct arizona *arizona)
>  {
>   struct arizona_pdata *pdata = &arizona->pdata;
> @@ -831,7 +812,13 @@ static int arizona_of_get_core_pdata(struct arizona 
> *arizona)
>   int ret, i;
>   int count = 0;
>  
> - pdata->reset = arizona_of_get_named_gpio(arizona, "wlf,reset", true);
> + pdata->reset = of_get_named_gpio(arizona->dev->of_node, "wlf,reset", 0);
> + if (pdata->reset < 0) {
> + dev_err(arizona->dev, "Reset gpio missing/malformed: %d\n",

gpio should be GPIO.

I'll probably just fix this up myself though.

Applied, thanks.

> + pdata->reset);
> +
> + pdata->reset = 0;
> + }
>  
>   ret = of_property_read_u32_array(arizona->dev->of_node,
>"wlf,gpio-defaults",
> diff --git a/include/linux/mfd/arizona/core.h 
> b/include/linux/mfd/arizona/core.h
> index b9909bb..b31b3be 100644
> --- a/include/linux/mfd/arizona/core.h
> +++ b/include/linux/mfd/arizona/core.h
> @@ -191,7 +191,4 @@ int cs47l24_patch(struct arizona *arizona);
>  int wm8997_patch(struct arizona *arizona);
>  int wm8998_patch(struct arizona *arizona);
>  
> -extern int arizona_of_get_named_gpio(struct arizona *arizona, const char 
> *prop,
> -  bool mandatory);
> -
>  #endif

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [RFC 1/2] power: power_supply: add new property POWER_SUPPLY_PROP_POLL_INTERVAL

[Matt Ranostay]

On Wed, Sep 21, 2016 at 10:52 PM, Matt Ranostay  wrote:
> Add new POWER_SUPPLY_PROP_POLL_INTERVAL property to display/set update
> interval in milliseconds of the device.

Should be seconds.
>
> Signed-off-by: Matt Ranostay 
> ---
>  Documentation/power/power_supply_class.txt | 1 +
>  drivers/power/power_supply_sysfs.c | 1 +
>  include/linux/power_supply.h   | 1 +
>  3 files changed, 3 insertions(+)
>
> diff --git a/Documentation/power/power_supply_class.txt 
> b/Documentation/power/power_supply_class.txt
> index 82dacc06e355..c2e97872374a 100644
> --- a/Documentation/power/power_supply_class.txt
> +++ b/Documentation/power/power_supply_class.txt
> @@ -158,6 +158,7 @@ while battery powers a load)
>  TIME_TO_FULL - seconds left for battery to be considered full (i.e.
>  while battery is charging)
>
> +POLL_INTERVAL - seconds between battery stats querying
>
>  Battery <-> external power supply interaction
>  ~
> diff --git a/drivers/power/power_supply_sysfs.c 
> b/drivers/power/power_supply_sysfs.c
> index 80fed98832f9..df66fad322c2 100644
> --- a/drivers/power/power_supply_sysfs.c
> +++ b/drivers/power/power_supply_sysfs.c
> @@ -198,6 +198,7 @@ static struct device_attribute power_supply_attrs[] = {
> POWER_SUPPLY_ATTR(scope),
> POWER_SUPPLY_ATTR(charge_term_current),
> POWER_SUPPLY_ATTR(calibrate),
> +   POWER_SUPPLY_ATTR(poll_interval),
> /* Properties of type `const char *' */
> POWER_SUPPLY_ATTR(model_name),
> POWER_SUPPLY_ATTR(manufacturer),
> diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
> index 751061790626..5d45ac511a64 100644
> --- a/include/linux/power_supply.h
> +++ b/include/linux/power_supply.h
> @@ -148,6 +148,7 @@ enum power_supply_property {
> POWER_SUPPLY_PROP_SCOPE,
> POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT,
> POWER_SUPPLY_PROP_CALIBRATE,
> +   POWER_SUPPLY_PROP_POLL_INTERVAL, /* in seconds! */
> /* Properties of type `const char *' */
> POWER_SUPPLY_PROP_MODEL_NAME,
> POWER_SUPPLY_PROP_MANUFACTURER,
> --
> 2.7.4
>

Re: [PATCH v7 0/8] power: add power sequence library

[Peter Chen]

On Wed, Sep 28, 2016 at 01:30:17AM +0200, Maciej S. Szmigiero wrote:
> On 20.09.2016 05:36, Peter Chen wrote:
> > Hi all,
> > 
> > This is a follow-up for my last power sequence framework patch set [1].
> > According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
> > power sequence instances will be added at postcore_initcall, the match
> > criteria is compatible string first, if the compatible string is not
> > matched between dts and library, it will try to use generic power sequence.
> >  
> > The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> > if only one power sequence instance is needed, for more power sequences
> > are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub 
> > driver).
> > 
> > In future, if there are special power sequence requirements, the special
> > power sequence library can be created.
> > 
> > This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> > two hot-plug devices to simulate this use case, the related binding
> > change is updated at patch [1/6], The udoo board changes were tested
> > using my last power sequence patch set.[3]
> > 
> > Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> > need to power on itself before it can be found by ULPI bus.
> > 
> > [1] http://www.spinics.net/lists/linux-usb/msg142755.html
> > [2] http://www.spinics.net/lists/linux-usb/msg143106.html
> > [3] http://www.spinics.net/lists/linux-usb/msg142815.html
> 
> Just tested this patch set on UDOO board again to make sure that it still
> works after all changes done since it was last tested there and can confirm
> that it does work correctly.
> 

Thanks, Maciej.

-- 

Best Regards,
Peter Chen

[PATCH 0/2] Input: ABS2 and motion tracking

[Roderick Colenbrander]

From: Roderick Colenbrander 

For some input driver work we have been doing, we were limited by not
having a wide enough ABS range in evdev. The current ABS range is mostly
full and due to limitations on the ioctl design, it can't be extended.

About 3 years ago, David Herrmann did work in this area to address this
problem for similar reasons as us. However his patches at the time didn't
make it in.

Since we have a need for this kind of functionality, we took over his
patches and are submitting them again with various improvements based
on feedback to the original patches and some new functionality for motion
tracking we are interested in ourselves. The patchset is simpler than before,
because at the time a uinput overhaul was needed, before uinput could even
support ABS_MAX2, which has happened since then.

The patches have been tested with some David's libevdev branch which
supports the new APIs. In addition we verified the new APIs in some
of internal software.

Thanks,
Roderick Colenbrander
Gaikai Inc, a Sony Interactive Entertainment Company

Roderick Colenbrander (2):
  Input: introduce ABS_MAX2/CNT2 and friends
  Input: add motion-tracking ABS_* bits and docs

 Documentation/input/gamepad.txt  |   9 +-
 Documentation/input/motion-tracking.txt  | 176 +++
 drivers/hid/hid-debug.c  |   2 +-
 drivers/hid/hid-input.c  |   2 +-
 drivers/input/evdev.c|  95 -
 drivers/input/input.c|  14 +--
 drivers/input/keyboard/goldfish_events.c |   6 +-
 drivers/input/keyboard/hil_kbd.c |   2 +-
 drivers/input/misc/uinput.c  |   8 +-
 include/linux/hid.h  |   2 +-
 include/linux/input.h|   6 +-
 include/linux/mod_devicetable.h  |   2 +-
 include/uapi/linux/input-event-codes.h   |  21 +++-
 include/uapi/linux/input.h   |  37 ++-
 14 files changed, 355 insertions(+), 27 deletions(-)
 create mode 100644 Documentation/input/motion-tracking.txt

-- 
2.7.4

[GIT PULL] cgroup fixes for v4.8-rc8

[Tejun Heo]

Hello, Linus.

Three late fixes for cgroup.  Two cpuset ones, one trivial and the
other pretty obscure, and a cgroup core fix for a bug which impacts
cgroup v2 namespace users.

Thanks.

The following changes since commit 568ac888215c7fb2fabe8ea739b00ec3c1f5d440:

  cgroup: reduce read locked section of cgroup_threadgroup_rwsem during fork 
(2016-08-17 09:54:52 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git for-4.8-fixes

for you to fetch changes up to 9157056da8f8c4a6305f15619e269f164b63a6de:

  cgroup: fix invalid controller enable rejections with cgroup namespace 
(2016-09-23 16:55:49 -0400)


Joonwoo Park (1):
  cpuset: handle race between CPU hotplug and cpuset_hotplug_work

Tejun Heo (1):
  cgroup: fix invalid controller enable rejections with cgroup namespace

Wei Yongjun (1):
  cpuset: fix non static symbol warning

 kernel/cgroup.c | 29 +
 kernel/cpuset.c | 19 +++
 2 files changed, 40 insertions(+), 8 deletions(-)

-- 
tejun

Re: [PATCH v7 0/8] power: add power sequence library

[Maciej S. Szmigiero]

On 20.09.2016 05:36, Peter Chen wrote:
> Hi all,
> 
> This is a follow-up for my last power sequence framework patch set [1].
> According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
> power sequence instances will be added at postcore_initcall, the match
> criteria is compatible string first, if the compatible string is not
> matched between dts and library, it will try to use generic power sequence.
>
> The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> if only one power sequence instance is needed, for more power sequences
> are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub 
> driver).
> 
> In future, if there are special power sequence requirements, the special
> power sequence library can be created.
> 
> This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> two hot-plug devices to simulate this use case, the related binding
> change is updated at patch [1/6], The udoo board changes were tested
> using my last power sequence patch set.[3]
> 
> Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> need to power on itself before it can be found by ULPI bus.
> 
> [1] http://www.spinics.net/lists/linux-usb/msg142755.html
> [2] http://www.spinics.net/lists/linux-usb/msg143106.html
> [3] http://www.spinics.net/lists/linux-usb/msg142815.html

Just tested this patch set on UDOO board again to make sure that it still
works after all changes done since it was last tested there and can confirm
that it does work correctly.

Maciej

Re: [PATCH trival -resend 2/2] lib: clean up put_cpu_var usage

[Tejun Heo]

On Tue, Sep 27, 2016 at 08:42:42AM -0700, Shaohua Li wrote:
> put_cpu_var takes the percpu data, not the data returned from
> get_cpu_var.
> 
> This doesn't change the behavior.
> 
> Cc: Tejun Heo 
> Signed-off-by: Shaohua Li 

Acked-by: Tejun Heo 

Thanks.

-- 
tejun

Re: [PATCH trival -resend 1/2] bpf: clean up put_cpu_var usage

[Tejun Heo]

On Tue, Sep 27, 2016 at 08:42:41AM -0700, Shaohua Li wrote:
> put_cpu_var takes the percpu data, not the data returned from
> get_cpu_var.
> 
> This doesn't change the behavior.
> 
> Cc: Tejun Heo 
> Cc: Alexei Starovoitov 
> Signed-off-by: Shaohua Li 

Acked-by: Tejun Heo 

Thanks.

-- 
tejun

mmotm 2016-09-27-16-08 uploaded

[akpm]

The mm-of-the-moment snapshot 2016-09-27-16-08 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (4.x
or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.

A git tree which contains the memory management portion of this tree is
maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
by Michal Hocko.  It contains the patches which are between the
"#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
file, http://www.ozlabs.org/~akpm/mmotm/series.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/

To develop on top of mmotm git:

  $ git remote add mmotm 
git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
  $ git remote update mmotm
  $ git checkout -b topic mmotm/master
  
  $ git send-email mmotm/master.. [...]

To rebase a branch with older patches to a new mmotm release:

  $ git remote update mmotm
  $ git rebase --onto mmotm/master  topic




The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is available at

http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/

and use of this tree is similar to
http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.


This mmotm tree contains the following patches against 4.8-rc8:
(patches marked "*" will be included in linux-next)

  i-need-old-gcc.patch
* mmksm-fix-endless-looping-in-allocating-memory-when-ksm-enable.patch
* dma-mappingh-preserve-unmap-info-for-config_dma_api_debug.patch
* scripts-recordmcountc-account-for-softirqentrytext.patch
* mem-hotplug-use-nodes-that-contain-memory-as-mask-in-new_node_page.patch
* 
mm-workingset-fix-crash-in-shadow-node-shrinker-caused-by-replace_page_cache_page.patch
* ocfs2-fix-deadlock-on-mmapped-page-in-ocfs2_write_begin_nolock.patch
* arm-arch-arm-include-asm-pageh-needs-personalityh.patch
* fsnotify-drop-notification_mutex-before-destroying-event.patch
* fsnotify-convert-notification_mutex-to-a-spinlock.patch
* fsnotify-convert-notification_mutex-to-a-spinlock-fix.patch
* fanotify-use-notification_lock-instead-of-access_lock.patch
* fanotify-fix-possible-false-warning-when-freeing-events.patch
* fsnotify-cleanup-spinlock-assertions.patch
* kbuild-simpler-generation-of-assembly-constants.patch
* fs-ocfs2-dlmfs-remove-deprecated-create_singlethread_workqueue.patch
* fs-ocfs2-cluster-remove-deprecated-create_singlethread_workqueue.patch
* fs-ocfs2-super-remove-deprecated-create_singlethread_workqueue.patch
* fs-ocfs2-dlm-remove-deprecated-create_singlethread_workqueue.patch
* ocfs2-fix-undefined-struct-variable-in-inodeh.patch
* ocfs2-free-the-mle-while-the-res-had-one-to-avoid-mle-memory-leak.patch
* 
block-restore-proc-partitions-to-not-display-non-partitionable-removable-devices.patch
* fs-select-add-vmalloc-fallback-for-select2.patch
* kernel-watchdog-use-nmi-registers-snapshot-in-hardlockup-handler.patch
  mm.patch
* mm-oom-deduplicate-victim-selection-code-for-memcg-and-global-oom.patch
* mm-zsmalloc-add-trace-events-for-zs_compact.patch
* mm-zsmalloc-add-per-class-compact-trace-event.patch
* mm-vmalloc-fix-align-value-calculation-error.patch
* mm-vmalloc-fix-align-value-calculation-error-fix.patch
* mm-vmalloc-fix-align-value-calculation-error-v2.patch
* mm-vmalloc-fix-align-value-calculation-error-v2-fix.patch
* mm-vmalloc-fix-align-value-calculation-error-v2-fix-fix.patch
* mm-vmalloc-fix-align-value-calculation-error-v2-fix-fix-fix.patch
* mm-memcontrol-add-sanity-checks-for-memcg-idref-on-get-put.patch
* mm-oom_killc-fix-task_will_free_mem-comment.patch
* mm-compaction-make-whole_zone-flag-ignore-cached-scanner-positions.patch
* 
mm-compaction-make-whole_zone-flag-ignore-cached-scanner-positions-checkpatch-fixes.patch
* mm-compaction-cleanup-unused-functions.patch
* mm-compaction-rename-compact_partial-to-compact_success.patch
* mm-compaction-dont-recheck-watermarks-afte

Re: UFS API in the kernel

[subhashj]

Hi Joao,


On 2016-09-26 18:10, Kiwoong Kim wrote:

Hi.

If you want to declare some things for user interface,
is it be better to put those thing include/uapi/linux/ than 
include/linux?


Agreed with Mr. Pinto's opinion with respect to implementing additional 
ioctls.


Yes, "scsi_host_template" allows the LLD's to export their ioctl 
callback and then you can use the sg interface to issue UFS specific 
ioctls. We had implemented similar ioctl for our use, here is the 
reference code: 
https://source.codeaurora.org/quic/la/kernel/msm-3.18/tree/drivers/scsi/ufs/ufshcd.c?h=LA.HB.1.1.1.c2#n6791. 
This was mainly done to  export the UFS query request interface to user 
space. Declarations where exported under include/uapi/scsi/ufs/ . If you 
want to build upon this already existing functionality, i can post the 
formal patch on mailing list.


Regards,
Subhash




Regards.


-Original Message-
From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
ow...@vger.kernel.org] On Behalf Of Shaun Tancheff
Sent: Tuesday, September 27, 2016 4:23 AM
To: Joao Pinto
Cc: linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: UFS API in the kernel

On Thu, Sep 22, 2016 at 10:21 AM, Joao Pinto 
wrote:
> Hi!
>
> I am designing an application that has the goal to be an utility for
> Unipro and UFS testing purposes. This application is going to run on
> top of a recent Linux Kernel containing the new UFS stack (including the
new DWC drivers).
>
> I am considering doing the following:
> a) Create a new config item called CONFIG_UFS_CHARDEV which is going
> to create a char device responsible to make some IOCTL available for
> user-space applications
> b) Create a linux/ufs.h header file that contains data structures
> declarations that will be needed in user-space applications

I am not very familiar with UFS devices, that said you should have an 
sgX

chardev being created already so you can handle SG_IO requests.
There also appear to be some sysfs entries being created.

So between sg and sysfs you should be able to handle any user-space 
out of

band requests without resorting to making a new chardev.

Adding more sysfs entries, if you need them, should be fine.

You may find it easier to expand on the existing interfaces than to 
get

consensus on a new driver and ioctls.

Hope this helps,
Shaun

> Could you please advise me about what the correct approach should be
> to make it as standard as possible and usable in the future?
>
> Thank you very much for your help!
>
> regards,
> Joao
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi"
> in the body of a message to majord...@vger.kernel.org More majordomo
> info at
> https://urldefense.proofpoint.com/v2/url?u=http-3A__vger.kernel.org_ma
> jordomo-2Dinfo.html&d=DQICaQ&c=IGDlg0lD0b-nebmJJ0Kp8A&r=Wg5NqlNlVTT7Ug
> l8V50qIHLe856QW0qfG3WVYGOrWzA&m=vJFB6pCywWtdvkgHz9Vc0jQz0xzeyZlr-7eCWY
> u88nM&s=yiQLPFpqmMrbqLZz1Jb3aNqOje2dRMLJHEzUDobwcXc&e=



--
Shaun Tancheff
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" 
in
the body of a message to majord...@vger.kernel.org More majordomo info 
at

http://vger.kernel.org/majordomo-info.html



--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" 
in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 4.7 regression: ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off

[Sinan Kaya]

On 9/27/2016 6:58 PM, Rafael J. Wysocki wrote:
>> :04 04 9bf16c388d23bb66e087809f069eafed18e46a8c 
>> bcac95fb33ee834aec7d23eab9eb0dc5e330c68c M  drivers
> OK
> 
> Sinan, can you help, please?
> 
> 

Sure, let's see what's going on. I was writing an email. 

Can we apply this and collect the kernel log? It also helps to see the kernel 
log from a working
combination.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.
From 9181f4b9ab405bc6c9412133aefef7676899733c Mon Sep 17 00:00:00 2001
From: Sinan Kaya 
Date: Tue, 27 Sep 2016 18:35:15 -0400
Subject: [PATCH] acpi: pci_link: debug aids

Change-Id: I6c459cb5888d95f5f1ef7c0e2f138fb9c65f40e5
---
 drivers/acpi/pci_link.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
index c983bf7..44937f93 100644
--- a/drivers/acpi/pci_link.c
+++ b/drivers/acpi/pci_link.c
@@ -508,6 +508,8 @@ static int acpi_irq_get_penalty(int irq)
penalty += PIRQ_PENALTY_ISA_ALWAYS;
else
penalty += PIRQ_PENALTY_PCI_USING;
+
+   pr_info("%s:%d adding SCI penalty: %d\n", __func__, __LINE__, 
penalty);
}
 
if (irq < ACPI_MAX_ISA_IRQS)
@@ -604,6 +606,12 @@ static int acpi_pci_link_allocate(struct acpi_pci_link 
*link)
}
}
if (acpi_irq_get_penalty(irq) >= PIRQ_PENALTY_ISA_ALWAYS) {
+   for (i = (link->irq.possible_count - 1); i >= 0; i--) {
+   pr_info("penalty[%d] = 0x%x\n",
+   link->irq.possible[i],
+   acpi_irq_get_penalty(link->irq.possible[i]));
+   }
+
printk(KERN_ERR PREFIX "No IRQ available for %s [%s]. "
"Try pci=noacpi or acpi=off\n",
acpi_device_name(link->device),
@@ -870,9 +878,12 @@ static int __init acpi_irq_penalty_update(char *str, int 
used)
  */
 void acpi_penalize_isa_irq(int irq, int active)
 {
-   if ((irq >= 0) && (irq < ARRAY_SIZE(acpi_isa_irq_penalty)))
+   if ((irq >= 0) && (irq < ARRAY_SIZE(acpi_isa_irq_penalty))) {
acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
  (active ? PIRQ_PENALTY_ISA_USED : PIRQ_PENALTY_PCI_USING);
+   pr_info("%s:%d acpi_isa_irq_penalty[%d]=0x%x active = %d\n", 
__func__,
+   __LINE__, irq,  acpi_irq_get_penalty(irq), 
active);
+   }
 }
 
 bool acpi_isa_irq_available(int irq)
-- 
1.9.1

Re: [PATCH 2/3] kvm: x86: do not use KVM_REQ_EVENT for APICv interrupt injection

[Michael S. Tsirkin]

On Tue, Sep 27, 2016 at 11:20:12PM +0200, Paolo Bonzini wrote:
> Since bf9f6ac8d749 ("KVM: Update Posted-Interrupts Descriptor when vCPU
> is blocked", 2015-09-18) the posted interrupt descriptor is checked
> unconditionally for PIR.ON.  Therefore we don't need KVM_REQ_EVENT to
> trigger the scan and, if NMIs or SMIs are not involved, we can avoid
> the complicated event injection path.
> 
> However, there is a race between vmx_deliver_posted_interrupt and
> vcpu_enter_guest.  Fix it by disabling interrupts before vcpu->mode is
> set to IN_GUEST_MODE.

Could you describe the race a bit more please?
I'm surprised that locally disabling irqs
fixes a race with a different CPUs.

> 
> Calling kvm_vcpu_kick if PIR.ON=1 is also useless, though it has been
> there since APICv was introduced.
> 
> Signed-off-by: Paolo Bonzini 
> ---
>  arch/x86/kvm/lapic.c | 2 --
>  arch/x86/kvm/vmx.c   | 8 +---
>  arch/x86/kvm/x86.c   | 9 +++--
>  3 files changed, 12 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 63a442aefc12..be8b7ad56dd1 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -356,8 +356,6 @@ void kvm_apic_update_irr(struct kvm_vcpu *vcpu, u32 *pir)
>   struct kvm_lapic *apic = vcpu->arch.apic;
>  
>   __kvm_apic_update_irr(pir, apic->regs);
> -
> - kvm_make_request(KVM_REQ_EVENT, vcpu);
>  }
>  EXPORT_SYMBOL_GPL(kvm_apic_update_irr);
>  
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index b33eee395b00..207b9aa32915 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -4844,9 +4844,11 @@ static void vmx_deliver_posted_interrupt(struct 
> kvm_vcpu *vcpu, int vector)
>   if (pi_test_and_set_pir(vector, &vmx->pi_desc))
>   return;
>  
> - r = pi_test_and_set_on(&vmx->pi_desc);
> - kvm_make_request(KVM_REQ_EVENT, vcpu);
> - if (r || !kvm_vcpu_trigger_posted_interrupt(vcpu))

so the logic here was reversed - kick was not called
when PIR=OFF previously. It's a bug but what was it's effect?
I'm guessing - extra latency where VCPU won't get
woken up correctly?

> + /* If a previous notification has sent the IPI, nothing to do.  */
> + if (pi_test_and_set_on(&vmx->pi_desc))
> + return;
> +
> + if (!kvm_vcpu_trigger_posted_interrupt(vcpu))
>   kvm_vcpu_kick(vcpu);
>  }
>  
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 3ee8a91a78c3..604cfbfc5bee 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -6658,6 +6658,13 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
>   kvm_x86_ops->prepare_guest_switch(vcpu);
>   if (vcpu->fpu_active)
>   kvm_load_guest_fpu(vcpu);
> +
> + /*
> +  * Disable IRQs before setting IN_GUEST_MODE, so that
> +  * posted interrupts with vcpu->mode == IN_GUEST_MODE
> +  * always result in virtual interrupt delivery.
> +  */
> + local_irq_disable();
>   vcpu->mode = IN_GUEST_MODE;
>  
>   srcu_read_unlock(&vcpu->kvm->srcu, vcpu->srcu_idx);
> @@ -6671,8 +6678,6 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
>*/
>   smp_mb__after_srcu_read_unlock();
>  
> - local_irq_disable();
> -
>   if (vcpu->mode == EXITING_GUEST_MODE || vcpu->requests
>   || need_resched() || signal_pending(current)) {
>   vcpu->mode = OUTSIDE_GUEST_MODE;
> -- 
> 1.8.3.1
> 

Question on kzalloc and GFP_DMA32

[Ben Greear]

I have been running this patch for a while:

ath10k:  Use GPF_DMA32 for firmware swap memory.

This fixes OS crash when using QCA 9984 NIC on x86-64 system
without vt-d enabled.

Also tested on ea8500 with 9980, and x86-64 with 9980 and 9880.

All tests were with CT firmware.

Signed-off-by: Ben Greear 

 drivers/net/wireless/ath/ath10k/wmi.c 
index e20aa39..727b3aa 100644
@@ -4491,7 +4491,7 @@ static int ath10k_wmi_alloc_chunk(struct ath10k *ar, u32 
req_id,
 if (!pool_size)
 return -EINVAL;

-vaddr = kzalloc(pool_size, GFP_KERNEL | __GFP_NOWARN);
+vaddr = kzalloc(pool_size, GFP_KERNEL | __GFP_NOWARN | GFP_DMA32);
 if (!vaddr)
 num_units /= 2;
 }


It sometimes works, on some systems, but then it also often fails with the splat
below, especially with several NICs in the system.

pool_size is relatively large (maybe 256k or so).

Any idea for a more proper way to do this?


gfp: 4
[ cut here ]
kernel BUG at /home/greearb/git/linux-4.7.dev.y/mm/slub.c:1508!
invalid opcode:  [#1] PREEMPT SMP
Modules linked in: coretemp hwmon ath9k intel_rapl ath10k_pci x86_pkg_temp_thermal ath9k_common ath10k_core intel_powerclamp ath9k_hw ath kvm iTCO_wdt mac80211 
iTCO_vendor_support irqbypass snd_hda_codec_hdmi 6

CPU: 2 PID: 268 Comm: kworker/u8:5 Not tainted 4.7.2+ #16
Hardware name: To be filled by O.E.M. To be filled by O.E.M./ChiefRiver, BIOS 
4.6.5 06/07/2013
Workqueue: ath10k_aux_wq ath10k_wmi_event_service_ready_work [ath10k_core]
task: 880036433a00 ti: 88003644 task.ti: 88003644
RIP: 0010:[]  [] new_slab+0x39a/0x410
RSP: 0018:880036443b58  EFLAGS: 00010092
RAX: 0006 RBX: 024082c4 RCX: 
RDX: 0006 RSI: 88021e30dd08 RDI: 88021e30dd08
RBP: 880036443b90 R08:  R09: 
R10:  R11: 0372 R12: 88021dc01200
R13: 88021dc00cc0 R14: 88021dc01200 R15: 0001
FS:  () GS:88021e30() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f3e65c1c730 CR3: 01e06000 CR4: 001406e0
Stack:
 8127a4fc 0a01ff10 024082c4 88021dc01200
 88021dc00cc0 88021dc01200 0001 880036443c58
 81247ac6 88021e31b360 880036433a00 880036433a00
Call Trace:
 [] ? __d_lookup+0x9c/0x160
 [] ___slab_alloc+0x396/0x4a0
 [] ? ath10k_wmi_event_service_ready_work+0x5ad/0x800 
[ath10k_core]
 [] ? alloc_kmem_pages+0x9/0x10
 [] ? kmalloc_order+0x13/0x40
 [] ? ath10k_wmi_event_service_ready_work+0x5ad/0x800 
[ath10k_core]
 [] __slab_alloc.isra.72+0x26/0x40
 [] __kmalloc+0x147/0x1b0
 [] ath10k_wmi_event_service_ready_work+0x5ad/0x800 
[ath10k_core]
 [] ? dequeue_entity+0x261/0xac0
 [] process_one_work+0x148/0x420
 [] worker_thread+0x49/0x480
 [] ? rescuer_thread+0x330/0x330
 [] kthread+0xc4/0xe0
 [] ret_from_fork+0x1f/0x40
 [] ? kthread_create_on_node+0x170/0x170
Code: e9 65 fd ff ff 49 8b 57 20 48 8d 42 ff 83 e2 01 49 0f 44 c7 f0 80 08 40 e9 6f fd ff ff 89 c6 48 c7 c7 01 36 c7 81 e8 e8 40 fa ff <0f> 0b ba 00 10 00 00 be 
5a 00 00 00 48 89 c7 48 d3 e2 e8 bf 18

RIP  [] new_slab+0x39a/0x410
 RSP 
---[ end trace ea3b0043b2911d93 ]---


static struct page *new_slab(struct kmem_cache *s, gfp_t flags, int node)
{
if (unlikely(flags & GFP_SLAB_BUG_MASK)) {
pr_emerg("gfp: %u\n", flags & GFP_SLAB_BUG_MASK);
BUG();
}

return allocate_slab(s,
flags & (GFP_RECLAIM_MASK | GFP_CONSTRAINT_MASK), node);
}


Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH trival -resend 1/2] bpf: clean up put_cpu_var usage

[Alexei Starovoitov]

On Tue, Sep 27, 2016 at 08:42:41AM -0700, Shaohua Li wrote:
> put_cpu_var takes the percpu data, not the data returned from
> get_cpu_var.
> 
> This doesn't change the behavior.
> 
> Cc: Tejun Heo 
> Cc: Alexei Starovoitov 
> Signed-off-by: Shaohua Li 

Acked-by: Alexei Starovoitov 

Re: 4.7 regression: ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off

[Rafael J. Wysocki]

On Wednesday, September 28, 2016 12:23:31 AM Ondrej Zary wrote:
> On Tuesday 27 September 2016 23:32:26 Rafael J. Wysocki wrote:
> > On Tuesday, September 27, 2016 11:02:22 PM Ondrej Zary wrote:
> > > On Monday 26 September 2016 14:23:01 Rafael J. Wysocki wrote:
> > > > On Sunday, September 25, 2016 03:12:05 PM Ondrej Zary wrote:
> > > > > Hello,
> > > > > I've upgraded kernel (Debian Squeeze - backports) from 4.6
> > > > > (4.6.4-1~bpo8+1) to 4.7 (4.7.2-1~bpo8+1) and IRQs stopped working
> > > > > with error messages like this:
> > > > >
> > > > > ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi
> > > > > or acpi=off
> > > > >
> > > > > The same thing appeared on two different machines. Is it a
> > > > > known/fixed bug?
> > > >
> > > > Well, maybe.
> > > >
> > > > Can you try 4.8-rc8, please?
> > >
> > > Just tested 4.8-rc8 on another (3rd) machine with the same problem. The
> > > bug is still present in 4.8-rc8.
> >
> > The problem wasn't known then.
> >
> > > All machines are Pentium 3 PCI/ISA systems.
> >
> > This probably is related to the way the ISA IRQs are handled.
> >
> > Here's a list of commits to revert, in this order:
> >
> > f7eca374f000 ACPI,PCI,IRQ: separate ISA penalty calculation
> > 487cf917ed0d Revert "ACPI, PCI, IRQ: remove redundant code in
> > acpi_irq_penalty_init()" 4a6e68bf96c1 ACPI,PCI,IRQ: factor in PCI possible
> > 54794580f594 ACPI,PCI,IRQ: correct operator precedence
> > 9e5ed6d1fb87 ACPI,PCI,IRQ: remove SCI penalize function
> > 1fcb6a813c4f ACPI,PCI,IRQ: remove redundant code in acpi_irq_penalty_init()
> > 5c5087a55390 ACPI,PCI,IRQ: reduce static IRQ array size to 16
> > 103544d86976 ACPI,PCI,IRQ: reduce resource requirements
> >
> > Please try to revert the first 5 first and see if that helps.
> 
> Bisected it to this:
> 
> 103544d86976338057d6a91f721b49d3acc7df7f is the first bad commit
> commit 103544d86976338057d6a91f721b49d3acc7df7f
> Author: Sinan Kaya 
> Date:   Sun Apr 17 13:36:53 2016 -0400
> 
> ACPI,PCI,IRQ: reduce resource requirements
> 
> Code has been redesigned to calculate penalty requirements on the fly. 
> This
> significantly simplifies the implementation and removes some of the init
> calls from x86 architecture.
> 
> Signed-off-by: Sinan Kaya 
> Acked-by: Bjorn Helgaas 
> Signed-off-by: Rafael J. Wysocki 
> 
> :04 04 9bf16c388d23bb66e087809f069eafed18e46a8c 
> bcac95fb33ee834aec7d23eab9eb0dc5e330c68c M  drivers

OK

Sinan, can you help, please?


> > > [0.00] Linux version 4.8.0-rc8+ (zary@gsql) (gcc version 4.7.2
> > > (Debian 4.7.2-5) ) #84 SMP Tue Sep 27 22:37:05 CEST 2016 [0.00]
> > > x86/fpu: Legacy x87 FPU detected.
> > > [0.00] x86/fpu: Using 'eager' FPU context switches.
> > > [0.00] e820: BIOS-provided physical RAM map:
> > > [0.00] BIOS-e820: [mem 0x-0x0009fbff]
> > > usable [0.00] BIOS-e820: [mem
> > > 0x0009fc00-0x0009] reserved [0.00] BIOS-e820:
> > > [mem 0x000f-0x000f] reserved [0.00]
> > > BIOS-e820: [mem 0x0010-0x1ffe] usable [   
> > > 0.00] BIOS-e820: [mem 0x1fff-0x1fff2fff] ACPI NVS
> > > [0.00] BIOS-e820: [mem 0x1fff3000-0x1fff]
> > > ACPI data [0.00] BIOS-e820: [mem
> > > 0x-0x] reserved [0.00] Notice: NX
> > > (Execute Disable) protection missing in CPU! [0.00] SMBIOS 2.2
> > > present.
> > > [0.00] DMI: VIA Technologies, Inc. VT82C694X/694X, BIOS 6.00 PG
> > > 02/19/2002 [0.00] e820: update [mem 0x-0x0fff] usable
> > > ==> reserved [0.00] e820: remove [mem 0x000a-0x000f]
> > > usable
> > > [0.00] e820: last_pfn = 0x1fff0 max_arch_pfn = 0x10
> > > [0.00] MTRR default type: uncachable
> > > [0.00] MTRR fixed ranges enabled:
> > > [0.00]   0-9 write-back
> > > [0.00]   A-A uncachable
> > > [0.00]   B-B write-combining
> > > [0.00]   C-C9FFF write-protect
> > > [0.00]   CA000-E uncachable
> > > [0.00]   F-F7FFF write-through
> > > [0.00]   F8000-F8FFF uncachable
> > > [0.00]   F9000-F write-through
> > > [0.00] MTRR variable ranges enabled:
> > > [0.00]   0 base 0 mask FE000 write-back
> > > [0.00]   1 base 0E000 mask FFC00 write-combining
> > > [0.00]   2 disabled
> > > [0.00]   3 disabled
> > > [0.00]   4 disabled
> > > [0.00]   5 disabled
> > > [0.00]   6 disabled
> > > [0.00]   7 disabled
> > > [0.00] x86/PAT: PAT not supported by CPU.
> > > [0.00] x86/PAT: Configuration [0-7]: WB  WT  UC- UC  WB  WT  UC-
> > > UC [0.00] initial memory mapped: [mem 0x-0x01bf] [   
> > > 0.00] Base memory trampoline at [c009b