[PATCH 2/2] drivers: usb: gadget: udc: remove logically dead code

[Gustavo A. R. Silva]

Remove unnecesary code because zlt never evaluates to zero.

Addresses-Coverity-ID: 1226747
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/usb/gadget/udc/mv_udc_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/mv_udc_core.c 
b/drivers/usb/gadget/udc/mv_udc_core.c
index 56b3574..9ca6d92 100644
--- a/drivers/usb/gadget/udc/mv_udc_core.c
+++ b/drivers/usb/gadget/udc/mv_udc_core.c
@@ -509,7 +509,7 @@ static int mv_ep_enable(struct usb_ep *_ep,
dqh = ep->dqh;
dqh->max_packet_length = (max << EP_QUEUE_HEAD_MAX_PKT_LEN_POS)
| (mult << EP_QUEUE_HEAD_MULT_POS)
-   | (zlt ? EP_QUEUE_HEAD_ZLT_SEL : 0)
+   | EP_QUEUE_HEAD_ZLT_SEL
| (ios ? EP_QUEUE_HEAD_IOS : 0);
dqh->next_dtd_ptr = 1;
dqh->size_ioc_int_sts = 0;
-- 
2.5.0

linux-next: Tree for Feb 8

[Stephen Rothwell]

Hi all,

Changes since 20170207:

The kspp tree gained conflicts against Linus' and the arm-soc, net-next
and s390 trees.

The kvm tree gained a build failure so I used the version from
next-20170207.

The gpio tree gained a build failure from an interaction with the tty
tree. I applied a merge fix patch.

Non-merge commits (relative to Linus' tree): 7995
 8969 files changed, 342051 insertions(+), 169189 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
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (926af6273fc6 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (c7858bf16c0b asm-prototypes: Clear any CPP 
defines before declaring the functions)
Merging arc-current/for-curr (8ba605b607b7 ARC: [plat-*] ARC_HAS_COH_CACHES no 
longer relevant)
Merging arm-current/fixes (228dbbfb5d77 ARM: 8643/3: arm/ptrace: Preserve 
previous registers for short regset write)
Merging m68k-current/for-linus (ad595b77c4a8 m68k/atari: Use seq_puts() in 
atari_get_hardware_list())
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (a0615a16f7d0 powerpc/mm: Use the correct pointer 
when setting a 2MB pte)
Merging sparc/master (f9a42e0d58cf Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (926af6273fc6 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging ipsec/master (4e5da369df64 Documentation/networking: fix typo in 
mpls-sysctl)
Merging netfilter/master (f95d7a46bc57 netfilter: ctnetlink: Fix regression in 
CTA_HELP processing)
Merging ipvs/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging wireless-drivers/master (52f5631a4c05 rtlwifi: rtl8192ce: Fix loading 
of incorrect firmware)
Merging mac80211/master (fd551bac4795 nl80211: Fix mesh HT operation check)
Merging sound-current/for-linus (f3d83317a69e Revert "ALSA: line6: Only 
determine control port properties if needed")
Merging pci-current/for-linus (77fbffc2aa09 Revert "PCI: pciehp: Add runtime PM 
support for PCIe hotplug ports")
Merging driver-core.current/driver-core-linus (49def1853334 Linux 4.10-rc4)
Merging tty.current/tty-linus (49def1853334 Linux 4.10-rc4)
Merging usb.current/usb-linus (d5adbfcd5f7b Linux 4.10-rc7)
Merging usb-gadget-fixes/fixes (efe357f4633a usb: dwc2: host: fix 
Wmaybe-uninitialized warning)
Merging usb-serial-fixes/usb-linus (d07830db1bdb USB: serial: pl2303: add ATEN 
device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (7ce7d89f4883 Linux 4.10-rc1)
Merging staging.current/staging-linus (d5adbfcd5f7b Linux 4.10-rc7)
Merging char-misc.current/char-misc-linus (d5adbfcd5f7b Linux 4.10-rc7)
Merging input-current/for-linus (601bbbe05173 Input: uinput - fix crash when 
mixing old and new init style)
Merging crypto-current/master (7c2cf1c4615c crypto: chcr - Fix key 

Re: [PATCH v4] drivers/misc: Add Aspeed LPC control driver

[Benjamin Herrenschmidt]

On Wed, 2017-02-08 at 02:06 +0200, Andy Shevchenko wrote:
> > On Wed, Feb 8, 2017 at 1:42 AM, Cyril Bur  wrote:
> > In order to manage server systems, there is typically another processor
> > known as a BMC (Baseboard Management Controller) which is responsible
> > for powering the server and other various elements, sometimes fans,
> > often the system flash.
> > 
> > The Aspeed BMC family which is what is used on OpenPOWER machines and a
> > number of x86 as well is typically connected to the host via an LPC
> > (Low Pin Count) bus (among others).
> 
> Perhaps I missed the discussion on previous versions, but here my
> question. If it's available on x86, how you access it there? This
> driver seems too OF oriented which is not a case on most of x86
> platforms.

This is the BMC (ie salve) side of the LPC bus which is an Aspeed
ARM chip whose kernel is device-tree based.

What happens on the "host" side (x86, powerpc, arm64, ...) is not
directly relevant here.

 .../...

> > It is important to note that due to the way the Aspeed chip lets the
> > kernel configure the mapping between host LPC addresses and BMC ram
> > addresses the offset within the window must be a multiple of size.
> > Not doing so will fragment the accessible space rather than simply
> > moving 'zero' upwards. This is caused by the nature of HICR8 being a
> > mask and the way host LPC addresses are translated.
> >  drivers/misc/Kconfig |   8 ++
> >  drivers/misc/Makefile|   1 +
> >  drivers/misc/aspeed-lpc-ctrl.c   | 263 
> > +++
> >  include/uapi/linux/aspeed-lpc-ctrl.h |  36 +
> 
> Since it's UAPI can it be more generic in case there will be other LPC
> implementations / devices?

Not really. As I wrote above, this isn't exposing an LPC bus the way
you seem to think of it, it's about the *BMC* side of the LPC bus (the
slave side) where some fairly chip/board configuration is needed to
do things like control the mapping of part of the LPC FW space to the
SPI flash or control which LPC devices are made visible to the host etc...

This is meant to be used by OpenBMC to configure the LPC bus properly
on the BMC side so the host can boot.

> > --- a/drivers/misc/Makefile
> > +++ b/drivers/misc/Makefile
> > @@ -53,6 +53,7 @@ obj-$(CONFIG_ECHO)+= echo/
> >  obj-$(CONFIG_VEXPRESS_SYSCFG)  += vexpress-syscfg.o
> >  obj-$(CONFIG_CXL_BASE) += cxl/
> >  obj-$(CONFIG_PANEL) += panel.o
> > +obj-$(CONFIG_ASPEED_LPC_CTRL)  += aspeed-lpc-ctrl.o
> 
> Does it suit best under misc?

Yes. It's basically a chardev giving access to a few very specific
registers. I've already explained all of this in series of emails...

It could *almost* be UIO except for the fact that one thing that
needs to be configured is the mapping between the LPC bus FW space
and some region of the SoC address space, either the SPI controller
or some reserved memory used for flash operations, and there is
benefit in doing so in the kernel for security purposes as doing
so incorrectly would expose the BMC internal physical address space
to the host.

> > +static long aspeed_lpc_ctrl_ioctl(struct file *file, unsigned int cmd,
> > +   unsigned long param)
> > +{
> > +   long rc;
> > +   struct aspeed_lpc_ctrl_mapping map;
> > +   struct aspeed_lpc_ctrl *lpc_ctrl = file_aspeed_lpc_ctrl(file);
> > +   void __user *p = (void __user *)param;
> > +   u32 addr;
> > +   u32 size;
> 
> Reversed tree?

Ugh ? One of those new ridiculous coding style rules ?

> > +   rc = regmap_write(lpc_ctrl->regmap, HICR7,
> > +   (addr | (map.addr >> 16)));
> > +   if (rc)
> > +   return rc;
> > +
> > +   return regmap_write(lpc_ctrl->regmap, HICR8,
> > +   (~(map.size - 1)) | ((map.size >> 16) - 1));
> 
> Magic stuff above and here. Perhaps some helpers?

A helper might be warranted but it's not *that* magic ... pretty
obvious what that does ;-)

> > +   }
> > +
> > +   return -EINVAL;
> > +}
> > +
> > +static const struct file_operations aspeed_lpc_ctrl_fops = {
> > +   .owner  = THIS_MODULE,
> 
> Do we still need this?
> > +   .mmap   = aspeed_lpc_ctrl_mmap,
> > +   .unlocked_ioctl = aspeed_lpc_ctrl_ioctl,
> > +};
> > +static int aspeed_lpc_ctrl_probe(struct platform_device *pdev)
> > +{
> > +   struct aspeed_lpc_ctrl *lpc_ctrl;
> > +   struct device *dev;
> > +   struct device_node *node;
> > +   struct resource resm;
> > +   int rc;
> > +
> > +   dev = &pdev->dev;
> 
> You can do this in the definition block.
> 
> 
> > +   node = of_parse_phandle(dev->of_node, "flash", 0);
> > +   if (!node) {
> > +   dev_err(dev, "Didn't find host pnor flash node\n");
> > +   return -ENODEV;
> > +   }
> > +
> > +   rc = of_property_read_u32_index(node, "reg", 3,
> > + 

Re: [PATCH v2] staging: rtl8712: rtl8712: fix sparse warnings

[Dan Carpenter]

On Wed, Feb 08, 2017 at 01:23:15AM +, Carlos Palminha wrote:
> Fixed sparse warnings
> * No need to convert from le32, pointers for structure with same endianness 
> (cast from restricted __le32)
> * Need to convert bitwise operation for le32 structure (invalid assignment 
> from int to __le32)
> 
> Signed-off-by: Carlos Palminha 
> ---
> Changes v1->v2:
> * Clarify patch description to ensure confidence
> 
>  drivers/staging/rtl8712/rtl8712_xmit.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/rtl8712/rtl8712_xmit.c 
> b/drivers/staging/rtl8712/rtl8712_xmit.c
> index c4f03a602a2e..67713643c923 100644
> --- a/drivers/staging/rtl8712/rtl8712_xmit.c
> +++ b/drivers/staging/rtl8712/rtl8712_xmit.c
> @@ -561,19 +561,19 @@ static void update_txdesc(struct xmit_frame 
> *pxmitframe, uint *pmem, int sz)
> 
>   ptxdesc_mp = &txdesc_mp;
>   /* offset 8 */
> - ptxdesc->txdw2 = cpu_to_le32(ptxdesc_mp->txdw2);
> + ptxdesc->txdw2 = ptxdesc_mp->txdw2;

Nah...  The original is done deliberately.  When I'm reviewing this
patch I can see that now.

Just leave this as-is.

regards,
dan carpenter

[GIT PULL][SECURITY] selinux: fix off-by-one in setprocattr

[James Morris]

Please pull this fix for a bug in SELinux, which fixes CVE-2017-2618.

The following changes since commit 926af6273fc683cd98cd0ce7bf0d04a02eed6742:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-02-07 
12:10:57 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git 
for-linus

Stephen Smalley (1):
  selinux: fix off-by-one in setprocattr

 security/selinux/hooks.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

---
commit 0c461cb727d146c9ef2d3e86214f498b78b7d125
Author: Stephen Smalley 
Date:   Tue Jan 31 11:54:04 2017 -0500

selinux: fix off-by-one in setprocattr

SELinux tries to support setting/clearing of /proc/pid/attr attributes
from the shell by ignoring terminating newlines and treating an
attribute value that begins with a NUL or newline as an attempt to
clear the attribute.  However, the test for clearing attributes has
always been wrong; it has an off-by-one error, and this could further
lead to reading past the end of the allocated buffer since commit
bb646cdb12e75d82258c2f2e7746d5952d3e321a ("proc_pid_attr_write():
switch to memdup_user()").  Fix the off-by-one error.

Even with this fix, setting and clearing /proc/pid/attr attributes
from the shell is not straightforward since the interface does not
support multiple write() calls (so shells that write the value and
newline separately will set and then immediately clear the attribute,
requiring use of echo -n to set the attribute), whereas trying to use
echo -n "" to clear the attribute causes the shell to skip the
write() call altogether since POSIX says that a zero-length write
causes no side effects. Thus, one must use echo -n to set and echo
without -n to clear, as in the following example:
$ echo -n unconfined_u:object_r:user_home_t:s0 > /proc/$$/attr/fscreate
$ cat /proc/$$/attr/fscreate
unconfined_u:object_r:user_home_t:s0
$ echo "" > /proc/$$/attr/fscreate
$ cat /proc/$$/attr/fscreate

Note the use of /proc/$$ rather than /proc/self, as otherwise
the cat command will read its own attribute value, not that of the shell.

There are no users of this facility to my knowledge; possibly we
should just get rid of it.

UPDATE: Upon further investigation it appears that a local process
with the process:setfscreate permission can cause a kernel panic as a
result of this bug.  This patch fixes CVE-2017-2618.

Signed-off-by: Stephen Smalley 
[PM: added the update about CVE-2017-2618 to the commit description]
Cc: sta...@vger.kernel.org # 3.5: d6ea83ec6864e
Signed-off-by: Paul Moore 

Signed-off-by: James Morris 

diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index c7c6619..d98550a 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -5887,7 +5887,7 @@ static int selinux_setprocattr(struct task_struct *p,
return error;
 
/* Obtain a SID for the context, if one was specified. */
-   if (size && str[1] && str[1] != '\n') {
+   if (size && str[0] && str[0] != '\n') {
if (str[size-1] == '\n') {
str[size-1] = 0;
size--;

Re: mm: deadlock between get_online_cpus/pcpu_alloc

[Michal Hocko]

On Tue 07-02-17 23:25:17, Thomas Gleixner wrote:
> On Tue, 7 Feb 2017, Christoph Lameter wrote:
> > On Tue, 7 Feb 2017, Michal Hocko wrote:
> > 
> > > I am always nervous when seeing hotplug locks being used in low level
> > > code. It has bitten us several times already and those deadlocks are
> > > quite hard to spot when reviewing the code and very rare to hit so they
> > > tend to live for a long time.
> > 
> > Yep. Hotplug events are pretty significant. Using stop_machine_() etc
> > would be advisable and that would avoid the taking of locks and get rid of 
> > all the
> > ocmplexity, reduce the code size and make the overall system much more
> > reliable.
> 
> Huch? stop_machine() is horrible and heavy weight. Don't go there, there
> must be simpler solutions than that.

Absolutely agreed. We are in the page allocator path so using the
stop_machine* is just ridiculous. And, in fact, there is a much simpler
solution [1]

[1] http://lkml.kernel.org/r/20170207201950.20482-1-mho...@kernel.org
-- 
Michal Hocko
SUSE Labs

Re: [PATCH 1/2] drm/rockchip: support mode_valid for crtc

[Daniel Vetter]

On Wed, Feb 8, 2017 at 1:45 AM, Mark yao  wrote:
> On 2017年02月08日 00:14, Sean Paul wrote:
>>
>> On Sun, Feb 05, 2017 at 03:36:36PM +0800, Mark Yao wrote:
>>>
>>> drm crtc already has mode_fixup callback to can do mode check, but
>>> We actually want to valid display mode on connector getmode time,
>>> mode_fixup can't do it.
>>>
>>> So add a private mode_valid callback to rockchip crtc, connectors can
>>> check mode with this mode_valid callback.
>>>
>> There are some nasty layer violations happening in this set. You should
>> use
>> mode_fixup if the crtc has limitations on the mode being set.
>>
>> Sean
>
> Mode_fixup can also check crtc limitations, but it's secondly time to check
> display mode.
>
> mode_fixup only works on drm_setcrtc or atomic_commit check, when userspace
> get a series of display modes,
> They don't know which display mode is bad before drm_setcrtc or
> atomic_commit check, they need try,
> but drm_setcrtc or atomic_commit check not only for display mode check,
> means that userspace didn't have a sure
> method to verify display mode.
>
> So I try to add the mode_valid callback to connector getmodes time, verify
> display mode before send mode list to userspace.
> then userspace would get a good display mode list.

You need both, the kerneldoc of these hooks explains in detail why.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 1/2 v2] cpufreq: qoriq: added arm64 socs support

[yuantian.tang]

From: Tang Yuantian 

Add arm64 config to Kconfig to enable cpu frequency feature on
nxp arm64 socs.

Signed-off-by: Tang Yuantian 
---
v2:
  - no change

 drivers/cpufreq/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 15adef4..3964383 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -324,7 +324,7 @@ endif
 
 config QORIQ_CPUFREQ
tristate "CPU frequency scaling driver for Freescale QorIQ SoCs"
-   depends on OF && COMMON_CLK && (PPC_E500MC || ARM)
+   depends on OF && COMMON_CLK && (PPC_E500MC || ARM || ARM64)
depends on !CPU_THERMAL || THERMAL
select CLK_QORIQ
help
-- 
2.1.0.27.g96db324

Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt

[Gilad Ben-Yossef]

On Tue, Feb 7, 2017 at 12:35 PM, Binoy Jayan  wrote:
> ===
> dm-crypt optimization for larger block sizes
> ===
>
> Currently, the iv generation algorithms are implemented in dm-crypt.c. The 
> goal
> is to move these algorithms from the dm layer to the kernel crypto layer by
> implementing them as template ciphers so they can be used in relation with
> algorithms like aes, and with multiple modes like cbc, ecb etc. As part of 
> this
> patchset, the iv-generation code is moved from the dm layer to the crypto 
> layer
> and adapt the dm-layer to send a whole 'bio' (as defined in the block layer)
> at a time. Each bio contains the in memory representation of physically
> contiguous disk blocks. Since the bio itself may not be contiguous in main
> memory, the dm layer sets up a chained scatterlist of these blocks split into
> physically contiguous segments in memory so that DMA can be performed.
...
> Binoy Jayan (1):
>   crypto: Add IV generation algorithms
>
>  drivers/md/dm-crypt.c  | 1894 
> ++--
>  include/crypto/geniv.h |   47 ++
>  2 files changed, 1402 insertions(+), 539 deletions(-)
>  create mode 100644 include/crypto/geniv.h

Ran Bonnie++ on it last night  (Luks mode, plain64, Qemu Virt platform
Arm64) and it works just fine.

Tested-by: Gilad Ben-Yossef 

Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

[PATCH 2/2 v2] cpufreq: qoriq: Don't look at clock implementation details

[yuantian.tang]

From: Tang Yuantian 

Get the CPU clock's potential parent clocks from the clock interface
itself, rather than manually parsing the clocks property to find a
phandle, looking at the clock-names property of that, and assuming that
those are valid parent clocks for the cpu clock.

This is necessary now that the clocks are generated based on the clock
driver's knowledge of the chip rather than a fragile device-tree
description of the mux options.

We can now rely on the clock driver to ensure that the mux only exposes
options that are valid.  The cpufreq driver was currently being overly
conservative in some cases -- for example, the "min_cpufreq =
get_bus_freq()" restriction only applies to chips with erratum
A-004510, and whether the freq_mask used on p5020 is needed depends on
the actual frequencies of the PLLs (FWIW, p5040 has a similar
limitation but its .freq_mask was zero) -- and the frequency mask
mechanism made assumptions about particular parent clock indices that
are no longer valid.

Signed-off-by: Scott Wood 
Signed-off-by: Tang Yuantian 
Acked-by: Viresh Kumar 
---
v2:
  - added more soc compatible strings

 drivers/cpufreq/qoriq-cpufreq.c | 145 +---
 1 file changed, 48 insertions(+), 97 deletions(-)

diff --git a/drivers/cpufreq/qoriq-cpufreq.c b/drivers/cpufreq/qoriq-cpufreq.c
index 53d8c3f..eee83c1 100644
--- a/drivers/cpufreq/qoriq-cpufreq.c
+++ b/drivers/cpufreq/qoriq-cpufreq.c
@@ -11,6 +11,7 @@
 #define pr_fmt(fmt)KBUILD_MODNAME ": " fmt
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -37,53 +38,20 @@ struct cpu_data {
struct thermal_cooling_device *cdev;
 };
 
+/*
+ * Don't use cpufreq on this SoC -- used when the SoC would have otherwise
+ * matched a more generic compatible.
+ */
+#define SOC_BLACKLIST  1
+
 /**
  * struct soc_data - SoC specific data
- * @freq_mask: mask the disallowed frequencies
- * @flag: unique flags
+ * @flags: SOC_xxx
  */
 struct soc_data {
-   u32 freq_mask[4];
-   u32 flag;
-};
-
-#define FREQ_MASK  1
-/* see hardware specification for the allowed frqeuencies */
-static const struct soc_data sdata[] = {
-   { /* used by p2041 and p3041 */
-   .freq_mask = {0x8, 0x8, 0x2, 0x2},
-   .flag = FREQ_MASK,
-   },
-   { /* used by p5020 */
-   .freq_mask = {0x8, 0x2},
-   .flag = FREQ_MASK,
-   },
-   { /* used by p4080, p5040 */
-   .freq_mask = {0},
-   .flag = 0,
-   },
+   u32 flags;
 };
 
-/*
- * the minimum allowed core frequency, in Hz
- * for chassis v1.0, >= platform frequency
- * for chassis v2.0, >= platform frequency / 2
- */
-static u32 min_cpufreq;
-static const u32 *fmask;
-
-#if defined(CONFIG_ARM)
-static int get_cpu_physical_id(int cpu)
-{
-   return topology_core_id(cpu);
-}
-#else
-static int get_cpu_physical_id(int cpu)
-{
-   return get_hard_smp_processor_id(cpu);
-}
-#endif
-
 static u32 get_bus_freq(void)
 {
struct device_node *soc;
@@ -101,9 +69,10 @@ static u32 get_bus_freq(void)
return sysfreq;
 }
 
-static struct device_node *cpu_to_clk_node(int cpu)
+static struct clk *cpu_to_clk(int cpu)
 {
-   struct device_node *np, *clk_np;
+   struct device_node *np;
+   struct clk *clk;
 
if (!cpu_present(cpu))
return NULL;
@@ -112,37 +81,28 @@ static struct device_node *cpu_to_clk_node(int cpu)
if (!np)
return NULL;
 
-   clk_np = of_parse_phandle(np, "clocks", 0);
-   if (!clk_np)
-   return NULL;
-
+   clk = of_clk_get(np, 0);
of_node_put(np);
-
-   return clk_np;
+   return clk;
 }
 
 /* traverse cpu nodes to get cpu mask of sharing clock wire */
 static void set_affected_cpus(struct cpufreq_policy *policy)
 {
-   struct device_node *np, *clk_np;
struct cpumask *dstp = policy->cpus;
+   struct clk *clk;
int i;
 
-   np = cpu_to_clk_node(policy->cpu);
-   if (!np)
-   return;
-
for_each_present_cpu(i) {
-   clk_np = cpu_to_clk_node(i);
-   if (!clk_np)
+   clk = cpu_to_clk(i);
+   if (IS_ERR(clk)) {
+   pr_err("%s: no clock for cpu %d\n", __func__, i);
continue;
+   }
 
-   if (clk_np == np)
+   if (clk_is_match(policy->clk, clk))
cpumask_set_cpu(i, dstp);
-
-   of_node_put(clk_np);
}
-   of_node_put(np);
 }
 
 /* reduce the duplicated frequencies in frequency table */
@@ -200,8 +160,9 @@ static int qoriq_cpufreq_cpu_init(struct cpufreq_policy 
*policy)
 {
struct device_node *np, *pnode;
int i, count, ret;
-   u32 freq, mask;
+   u32 freq;
struct clk *clk;
+   const struct clk_hw *hwclk;
struct cpufreq_frequency_table *table;
struct cpu_data *data;
unsigned int cpu =

Re: [RFC][PATCH] treewide: Move set_memory_* functions away from cacheflush.h

[Ingo Molnar]

* Laura Abbott  wrote:

> The set_memory_* APIs came out of a desire to have a better way to
> change memory attributes. Many of these attributes were linked to cache
> functionality so the prototypes were put in cacheflush.h. These days,
> the APIs have grown and have a much wider use than just cache APIs. To
> support this growth, split off set_memory_* and friends into a separate
> header file to avoid growing cacheflush.h for APIs that have nothing to
> do with caches.
> 
> Signed-off-by: Laura Abbott 
> ---
> This came out of a comment Russell made while reviewing RODATA test cases
> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-January/480855.html
> While the final result of that series was the rodata code was refactored into
> its own header file, the set_memory_* APIs are still out of place.
> 
> This is a simple attempt at moving all the API stubs to their own file.
> Another idea I had was throwing set_memory_{x,nx,ro,rw} in an asm-generic
> file since those are commonly used for module setting across all arches.
> 
> This is an RFC to see if this is actually beneficial. The diffstat is not
> negative unfortunately due to header guards in newer files.
> I have patches to convert call sites over to set_memory.h instead of
> cacheflush.h if there is sufficient interest.
> ---
>  arch/arm/include/asm/cacheflush.h   |  21 +---
>  arch/arm/include/asm/set_memory.h   |  32 
>  arch/arm64/include/asm/cacheflush.h |   6 +--
>  arch/arm64/include/asm/set_memory.h |  26 ++
>  arch/s390/include/asm/cacheflush.h  |   6 +--
>  arch/s390/include/asm/set_memory.h  |   9 
>  arch/x86/include/asm/cacheflush.h   |  96 +-
>  arch/x86/include/asm/set_memory.h   | 100 
> 
>  8 files changed, 171 insertions(+), 125 deletions(-)
>  create mode 100644 arch/arm/include/asm/set_memory.h
>  create mode 100644 arch/arm64/include/asm/set_memory.h
>  create mode 100644 arch/s390/include/asm/set_memory.h
>  create mode 100644 arch/x86/include/asm/set_memory.h

LGTM:

Acked-by: Ingo Molnar 

Thanks,

Ingo

[tip:locking/urgent] stacktrace, lockdep: Fix address, newline ugliness

[tip-bot for Omar Sandoval]

Commit-ID:  bfeda41d06d85ad9d52f2413cfc2b77be5022f75
Gitweb: http://git.kernel.org/tip/bfeda41d06d85ad9d52f2413cfc2b77be5022f75
Author: Omar Sandoval 
AuthorDate: Tue, 7 Feb 2017 15:33:20 -0800
Committer:  Ingo Molnar 
CommitDate: Wed, 8 Feb 2017 08:21:31 +0100

stacktrace, lockdep: Fix address, newline ugliness

Since KERN_CONT became meaningful again, lockdep stack traces have had
annoying extra newlines, like this:

[5.561122] -> #1 (B){+.+...}:
[5.561528]
[5.561532] [] lock_acquire+0xc3/0x210
[5.562178]
[5.562181] [] mutex_lock_nested+0x74/0x6d0
[5.562861]
[5.562880] [] init_btrfs_fs+0x21/0x196 [btrfs]
[5.563717]
[5.563721] [] do_one_initcall+0x52/0x1b0
[5.564554]
[5.564559] [] do_init_module+0x5f/0x209
[5.565357]
[5.565361] [] load_module+0x218d/0x2b80
[5.566020]
[5.566021] [] SyS_finit_module+0xeb/0x120
[5.566694]
[5.566696] [] entry_SYSCALL_64_fastpath+0x1f/0xc2

That's happening because each printk() call now gets printed on its own
line, and we do a separate call to print the spaces before the symbol.
Fix it by doing the printk() directly instead of using the
print_ip_sym() helper.

Additionally, the symbol address isn't very helpful, so let's get rid of
that, too. The final result looks like this:

[5.194518] -> #1 (B){+.+...}:
[5.195002]lock_acquire+0xc3/0x210
[5.195439]mutex_lock_nested+0x74/0x6d0
[5.196491]do_one_initcall+0x52/0x1b0
[5.196939]do_init_module+0x5f/0x209
[5.197355]load_module+0x218d/0x2b80
[5.197792]SyS_finit_module+0xeb/0x120
[5.198251]entry_SYSCALL_64_fastpath+0x1f/0xc2

Suggested-by: Linus Torvalds 
Signed-off-by: Omar Sandoval 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: kernel-t...@fb.com
Fixes: 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing continuation 
lines")
Link: 
http://lkml.kernel.org/r/43b4e114724b2bdb0308fa86cb33aa07d3d67fad.1486510315.git.osan...@fb.com
Signed-off-by: Ingo Molnar 
---
 kernel/stacktrace.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/kernel/stacktrace.c b/kernel/stacktrace.c
index b6e4c16..9c15a91 100644
--- a/kernel/stacktrace.c
+++ b/kernel/stacktrace.c
@@ -18,10 +18,8 @@ void print_stack_trace(struct stack_trace *trace, int spaces)
if (WARN_ON(!trace->entries))
return;
 
-   for (i = 0; i < trace->nr_entries; i++) {
-   printk("%*c", 1 + spaces, ' ');
-   print_ip_sym(trace->entries[i]);
-   }
+   for (i = 0; i < trace->nr_entries; i++)
+   printk("%*c%pS\n", 1 + spaces, ' ', (void *)trace->entries[i]);
 }
 EXPORT_SYMBOL_GPL(print_stack_trace);
 
@@ -29,7 +27,6 @@ int snprint_stack_trace(char *buf, size_t size,
struct stack_trace *trace, int spaces)
 {
int i;
-   unsigned long ip;
int generated;
int total = 0;
 
@@ -37,9 +34,8 @@ int snprint_stack_trace(char *buf, size_t size,
return 0;
 
for (i = 0; i < trace->nr_entries; i++) {
-   ip = trace->entries[i];
-   generated = snprintf(buf, size, "%*c[<%p>] %pS\n",
-   1 + spaces, ' ', (void *) ip, (void *) ip);
+   generated = snprintf(buf, size, "%*c%pS\n", 1 + spaces, ' ',
+(void *)trace->entries[i]);
 
total += generated;
 

Re: [PATCH v2] drm/mxsfb: fix pixel clock polarity

[Daniel Vetter]

On Wed, Feb 8, 2017 at 6:19 AM, Stefan Agner  wrote:
> On 2016-12-14 13:25, Marek Vasut wrote:
>> On 12/14/2016 09:48 PM, Stefan Agner wrote:
>>> The DRM subsystem specifies the pixel clock polarity from a
>>> controllers perspective: DRM_BUS_FLAG_PIXDATA_NEGEDGE means
>>> the controller drives the data on pixel clocks falling edge.
>>> That is the controllers DOTCLK_POL=0 (Default is data launched
>>> at negative edge).
>>>
>>> Also change the data enable logic to be high active by default
>>> and only change if explicitly requested via bus_flags. With
>>> that defaults are:
>>> - Data enable: high active
>>> - Pixel clock polarity: controller drives data on negative edge
>>>
>>> Signed-off-by: Stefan Agner 
>>
>> Acked-by: Marek Vasut 
>>
>
> This seems not have made into drm-next yet. Not sure what the plan is
> here, who will pick this up? There is also another fix on ML for the
> same driver ("drm: mxsfb: Fix crash when provided invalid DT bindings").

By default, driver maintainers are expected to pick up driver patches.
Exception is trivial patches by newcomers, to get them on board fast
(and avoid frustration when a maintainer isn't around). drm-misc and
Dave by default don't pick up anything.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH v2] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs

[Boqun Feng]

On Wed, Feb 08, 2017 at 03:09:33PM +0800, Pan Xinhui wrote:
> 
> 
> 在 2017/2/8 14:09, Boqun Feng 写道:
> > On Wed, Feb 08, 2017 at 12:05:40PM +0800, Boqun Feng wrote:
> > > On Wed, Feb 08, 2017 at 11:39:10AM +0800, Xinhui Pan wrote:
> > > > 2016-12-26 4:26 GMT+08:00 Waiman Long :
> > > > 
> > > > > A number of cmpxchg calls in qspinlock_paravirt.h were replaced by 
> > > > > more
> > > > > relaxed versions to improve performance on architectures that use 
> > > > > LL/SC.
> > > > > 
> > > > > All the locking related cmpxchg's are replaced with the _acquire
> > > > > variants:
> > > > >  - pv_queued_spin_steal_lock()
> > > > >  - trylock_clear_pending()
> > > > > 
> > > > > The cmpxchg's related to hashing are replaced by either by the 
> > > > > _release
> > > > > or the _relaxed variants. See the inline comment for details.
> > > > > 
> > > > > Signed-off-by: Waiman Long 
> > > > > 
> > > > >  v1->v2:
> > > > >   - Add comments in changelog and code for the rationale of the 
> > > > > change.
> > > > > 
> > > > > ---
> > > > >  kernel/locking/qspinlock_paravirt.h | 50 
> > > > > --
> > > > > ---
> > > > >  1 file changed, 33 insertions(+), 17 deletions(-)
> > > > > 
> > > > > 
> > > > > @@ -323,8 +329,14 @@ static void pv_wait_node(struct mcs_spinlock 
> > > > > *node,
> > > > > struct mcs_spinlock *prev)
> > > > >  * If pv_kick_node() changed us to vcpu_hashed, 
> > > > > retain that
> > > > >  * value so that pv_wait_head_or_lock() knows to not 
> > > > > also
> > > > > try
> > > > >  * to hash this lock.
> > > > > +*
> > > > > +* The smp_store_mb() and control dependency above 
> > > > > will
> > > > > ensure
> > > > > +* that state change won't happen before that.
> > > > > Synchronizing
> > > > > +* with pv_kick_node() wrt hashing by this waiter or 
> > > > > by the
> > > > > +* lock holder is done solely by the state variable. 
> > > > > There
> > > > > is
> > > > > +* no other ordering requirement.
> > > > >  */
> > > > > -   cmpxchg(&pn->state, vcpu_halted, vcpu_running);
> > > > > +   cmpxchg_relaxed(&pn->state, vcpu_halted, 
> > > > > vcpu_running);
> > > > > 
> > > > > /*
> > > > >  * If the locked flag is still not set after wakeup, 
> > > > > it is
> > > > > a
> > > > > @@ -360,9 +372,12 @@ static void pv_kick_node(struct qspinlock *lock,
> > > > > struct mcs_spinlock *node)
> > > > >  * pv_wait_node(). If OTOH this fails, the vCPU was running 
> > > > > and
> > > > > will
> > > > >  * observe its next->locked value and advance itself.
> > > > >  *
> > > > > -* Matches with smp_store_mb() and cmpxchg() in pv_wait_node()
> > > > > +* Matches with smp_store_mb() and cmpxchg_relaxed() in
> > > > > pv_wait_node().
> > > > > +* A release barrier is used here to ensure that node->locked 
> > > > > is
> > > > > +* always set before changing the state. See comment in
> > > > > pv_wait_node().
> > > > >  */
> > > > > -   if (cmpxchg(&pn->state, vcpu_halted, vcpu_hashed) != 
> > > > > vcpu_halted)
> > > > > +   if (cmpxchg_release(&pn->state, vcpu_halted, vcpu_hashed)
> > > > > +   != vcpu_halted)
> > > > > return;
> > > > > 
> > > > > hi, Waiman
> > > > We can't use _release here, a full barrier is needed.
> > > > 
> > > > There is pv_kick_node vs pv_wait_head_or_lock
> > > > 
> > > > [w] l->locked = _Q_SLOW_VAL  //reordered here
> > > > 
> > > > if (READ_ONCE(pn->state) == vcpu_hashed) //False.
> > > > 
> > > >lp = (struct qspinlock **)1;
> > > > 
> > > > [STORE] pn->state = vcpu_hashedlp = 
> > > > pv_hash(lock,
> > > > pn);
> > > > pv_hash()   
> > > >  if
> > > > (xchg(&l->locked, _Q_SLOW_VAL) == 0) // fasle, not unhashed.
> > > > 
> > > 
> > > This analysis is correct, but..
> > > 
> > 
> > Hmm.. look at this again, I don't think this analysis is meaningful,
> > let's say the reordering didn't happen, we still got(similar to your
> > case):
> > 
> but there is
>   cmpxchg_relaxed(&pn->state, 
> vcpu_halted, vcpu_running);
> 
> > if (READ_ONCE(pn->state) == 
> > vcpu_hashed) // false.
> >   lp = (struct qspinlock **)1;
> > 
> > cmpxchg(pn->state, vcpu_halted, vcpu_hashed);
> this cmpxchg will observe the cmpxchg_relaxed above, so this cmpxchg will 
> fail as pn->state is vcpu_running.
> No bug here..
> 

And we got the same guarantee if we use cmpxchg_release(), no?

Regards,
Boqun


signature.asc
Description: PGP signature

Re: [PATCH v2] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs

[Pan Xinhui]

在 2017/2/8 14:09, Boqun Feng 写道:

On Wed, Feb 08, 2017 at 12:05:40PM +0800, Boqun Feng wrote:

On Wed, Feb 08, 2017 at 11:39:10AM +0800, Xinhui Pan wrote:

2016-12-26 4:26 GMT+08:00 Waiman Long :


A number of cmpxchg calls in qspinlock_paravirt.h were replaced by more
relaxed versions to improve performance on architectures that use LL/SC.

All the locking related cmpxchg's are replaced with the _acquire
variants:
 - pv_queued_spin_steal_lock()
 - trylock_clear_pending()

The cmpxchg's related to hashing are replaced by either by the _release
or the _relaxed variants. See the inline comment for details.

Signed-off-by: Waiman Long 

 v1->v2:
  - Add comments in changelog and code for the rationale of the change.

---
 kernel/locking/qspinlock_paravirt.h | 50 --
---
 1 file changed, 33 insertions(+), 17 deletions(-)


@@ -323,8 +329,14 @@ static void pv_wait_node(struct mcs_spinlock *node,
struct mcs_spinlock *prev)
 * If pv_kick_node() changed us to vcpu_hashed, retain that
 * value so that pv_wait_head_or_lock() knows to not also
try
 * to hash this lock.
+*
+* The smp_store_mb() and control dependency above will
ensure
+* that state change won't happen before that.
Synchronizing
+* with pv_kick_node() wrt hashing by this waiter or by the
+* lock holder is done solely by the state variable. There
is
+* no other ordering requirement.
 */
-   cmpxchg(&pn->state, vcpu_halted, vcpu_running);
+   cmpxchg_relaxed(&pn->state, vcpu_halted, vcpu_running);

/*
 * If the locked flag is still not set after wakeup, it is
a
@@ -360,9 +372,12 @@ static void pv_kick_node(struct qspinlock *lock,
struct mcs_spinlock *node)
 * pv_wait_node(). If OTOH this fails, the vCPU was running and
will
 * observe its next->locked value and advance itself.
 *
-* Matches with smp_store_mb() and cmpxchg() in pv_wait_node()
+* Matches with smp_store_mb() and cmpxchg_relaxed() in
pv_wait_node().
+* A release barrier is used here to ensure that node->locked is
+* always set before changing the state. See comment in
pv_wait_node().
 */
-   if (cmpxchg(&pn->state, vcpu_halted, vcpu_hashed) != vcpu_halted)
+   if (cmpxchg_release(&pn->state, vcpu_halted, vcpu_hashed)
+   != vcpu_halted)
return;

hi, Waiman

We can't use _release here, a full barrier is needed.

There is pv_kick_node vs pv_wait_head_or_lock

[w] l->locked = _Q_SLOW_VAL  //reordered here

if (READ_ONCE(pn->state) == vcpu_hashed) //False.

   lp = (struct qspinlock **)1;

[STORE] pn->state = vcpu_hashedlp = pv_hash(lock,
pn);
pv_hash()if
(xchg(&l->locked, _Q_SLOW_VAL) == 0) // fasle, not unhashed.



This analysis is correct, but..



Hmm.. look at this again, I don't think this analysis is meaningful,
let's say the reordering didn't happen, we still got(similar to your
case):


but there is
cmpxchg_relaxed(&pn->state, 
vcpu_halted, vcpu_running);


if (READ_ONCE(pn->state) == 
vcpu_hashed) // false.
  lp = (struct qspinlock **)1;

cmpxchg(pn->state, vcpu_halted, vcpu_hashed);

this cmpxchg will observe the cmpxchg_relaxed above, so this cmpxchg will fail as 
pn->state is vcpu_running.
No bug here..


  if(!lp) {
lp = pv_hash(lock, pn);
WRITE_ONCE(l->locked, _Q_SLOW_VAL);
pv_hash();
if (xchg(&l->locked, 
_Q_SLOW_VAL) == 0) // fasle, not unhashed.

, right?




Actually, I think this or your case could not happen because we have

cmpxchg(pn->state, vcpu_halted, vcpu_running);

in pv_wait_node(), which makes us either observe vcpu_hashed or set
pn->state to vcpu_running before pv_kick_node() trying to do the hash.

I may miss something subtle, but does switching back to cmpxchg() could
fix the RCU stall you observed?

Regards,
Boqun


Then the same lock has hashed twice but only unhashed once. So at last as
the hash table grows big, we hit RCU stall.

I hit RCU stall when I run netperf benchmark



how will a big hash table hit RCU stall? Do you have the call trace for
your RCU stall?

Regards,
Boqun


thanks
xinhui



--
1.8.3.1

Re: [PATCH 4/7] serial: exar: Move Commtech adapters to 8250_exar as well

[Jan Kiszka]

On 2017-02-08 00:23, Andy Shevchenko wrote:
> On Tue, Feb 7, 2017 at 6:10 PM, Jan Kiszka  wrote:
>> Those are exar-based, too.
> 
> Exar-based
> 
>> With the required refactoring of the code to fit into 8250_exar, we
>> automatically fix the same issue pci_xr17v35x_setup had before: 8XMODE,
>> FCTL, TXTRG and RXTRG were always only set for port 0. Now they are
>> initialized for the correct target port by using port.membase.
> 
> My comments below.
> 
>> --- a/drivers/tty/serial/8250/8250_exar.c
>> +++ b/drivers/tty/serial/8250/8250_exar.c
>> @@ -24,11 +24,15 @@
>>
>>  #include "8250.h"
>>
>> -#define PCI_DEVICE_ID_COMMTECH_4224PCIE0x0020
>> -#define PCI_DEVICE_ID_COMMTECH_4228PCIE0x0021
>> -#define PCI_DEVICE_ID_COMMTECH_4222PCIE0x0022
>> -#define PCI_DEVICE_ID_EXAR_XR17V4358   0x4358
>> -#define PCI_DEVICE_ID_EXAR_XR17V8358   0x8358
> 
>> +#define PCI_DEVICE_ID_COMMTECH_4222PCI335  0x0004
>> +#define PCI_DEVICE_ID_COMMTECH_4224PCI335  0x0002
> 
> I think you assumed ID ordered list?

Yeah, will reorder at this chance.

> 
>> +#define PCI_DEVICE_ID_COMMTECH_2324PCI335  0x000a
>> +#define PCI_DEVICE_ID_COMMTECH_2328PCI335  0x000b
>> +#define PCI_DEVICE_ID_COMMTECH_4224PCIE0x0020
>> +#define PCI_DEVICE_ID_COMMTECH_4228PCIE0x0021
>> +#define PCI_DEVICE_ID_COMMTECH_4222PCIE0x0022
>> +#define PCI_DEVICE_ID_EXAR_XR17V4358   0x4358
>> +#define PCI_DEVICE_ID_EXAR_XR17V8358   0x8358
> 
>> @@ -292,6 +345,21 @@ static int __maybe_unused exar_resume(struct device 
>> *dev)
> 
>> +static const struct exar8250_board pbn_fastcom335_2 = {
>> +   .num_ports  = 2,
>> +   .setup  = pci_fastcom335_setup,
>> +};
>> +
>> +static const struct exar8250_board pbn_fastcom335_4 = {
>> +   .num_ports  = 4,
>> +   .setup  = pci_fastcom335_setup,
>> +};
>> +
>> +static const struct exar8250_board pbn_fastcom335_8 = {
>> +   .num_ports  = 8,
>> +   .setup  = pci_fastcom335_setup,
>> +};
> 
>> --- a/drivers/tty/serial/8250/8250_pci.c
>> +++ b/drivers/tty/serial/8250/8250_pci.c
>> @@ -1622,54 +1622,6 @@ static int pci_eg20t_init(struct pci_dev *dev)
>>  #define UART_EXAR_MPIOINV_15_8 0x98/* MPIOINV[15:8] */
>>  #define UART_EXAR_MPIOSEL_15_8 0x99/* MPIOSEL[15:8] */
>>  #define UART_EXAR_MPIOOD_15_8  0x9a/* MPIOOD[15:8] */
> 
> And why not to remove above constants?

Forgotten, will remove.

> 
>> -   /*
>> -* Commtech, Inc. Fastcom adapters
>> -*/
>> -   {   PCI_VENDOR_ID_COMMTECH, PCI_DEVICE_ID_COMMTECH_4222PCI335,
>> -   PCI_ANY_ID, PCI_ANY_ID,
>> -   0,
>> -   0, pbn_b0_2_1152000_200 },
>> -   {   PCI_VENDOR_ID_COMMTECH, PCI_DEVICE_ID_COMMTECH_4224PCI335,
>> -   PCI_ANY_ID, PCI_ANY_ID,
>> -   0,
>> -   0, pbn_b0_4_1152000_200 },
>> -   {   PCI_VENDOR_ID_COMMTECH, PCI_DEVICE_ID_COMMTECH_2324PCI335,
>> -   PCI_ANY_ID, PCI_ANY_ID,
>> -   0,
>> -   0, pbn_b0_4_1152000_200 },
>> -   {   PCI_VENDOR_ID_COMMTECH, PCI_DEVICE_ID_COMMTECH_2328PCI335,
>> -   PCI_ANY_ID, PCI_ANY_ID,
>> -   0,
>> -   0, pbn_b0_8_1152000_200 },
>> -
> 
> Check black list as well. I suppose now there is a bug and it's left
> even after this patch.
> 

Yeah, it lacks PCI_VENDOR_ID_COMMTECH... will send an update.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Re: v4.9, 4.4-final: 28 bioset threads on small notebook, 36 threads on cellphone

[Mike Galbraith]

On Tue, 2017-02-07 at 19:58 -0900, Kent Overstreet wrote:
> On Tue, Feb 07, 2017 at 09:39:11PM +0100, Pavel Machek wrote:
> > On Mon 2017-02-06 17:49:06, Kent Overstreet wrote:
> > > On Mon, Feb 06, 2017 at 04:47:24PM -0900, Kent Overstreet wrote:
> > > > On Mon, Feb 06, 2017 at 01:53:09PM +0100, Pavel Machek wrote:
> > > > > Still there on v4.9, 36 threads on nokia n900 cellphone.
> > > > > 
> > > > > So.. what needs to be done there?
> > > 
> > > > But, I just got an idea for how to handle this that might be halfway 
> > > > sane, maybe
> > > > I'll try and come up with a patch...
> > > 
> > > Ok, here's such a patch, only lightly tested:
> > 
> > I guess it would be nice for me to test it... but what it is against?
> > I tried after v4.10-rc5 and linux-next, but got rejects in both cases.
> 
> Sorry, I forgot I had a few other patches in my branch that touch
> mempool/biosets code.
> 
> Also, after thinking about it more and looking at the relevant code, I'm 
> pretty
> sure we don't need rescuer threads for block devices that just split bios - 
> i.e.
> most of them, so I changed my patch to do that.
> 
> Tested it by ripping out the current->bio_list checks/workarounds from the
> bcache code, appears to work:

Patch killed every last one of them, but..

homer:/root # dmesg|grep WARNING
[   11.701447] WARNING: CPU: 4 PID: 801 at block/bio.c:388 
bio_alloc_bioset+0x1a7/0x240
[   11.711027] WARNING: CPU: 4 PID: 801 at block/blk-core.c:2013 
generic_make_request+0x191/0x1f0
[   19.728989] WARNING: CPU: 0 PID: 717 at block/bio.c:388 
bio_alloc_bioset+0x1a7/0x240
[   19.737020] WARNING: CPU: 0 PID: 717 at block/blk-core.c:2013 
generic_make_request+0x191/0x1f0
[   19.746173] WARNING: CPU: 0 PID: 717 at block/bio.c:388 
bio_alloc_bioset+0x1a7/0x240
[   19.755260] WARNING: CPU: 0 PID: 717 at block/blk-core.c:2013 
generic_make_request+0x191/0x1f0
[   19.763837] WARNING: CPU: 0 PID: 717 at block/bio.c:388 
bio_alloc_bioset+0x1a7/0x240
[   19.772526] WARNING: CPU: 0 PID: 717 at block/blk-core.c:2013 
generic_make_request+0x191/0x1f0

Re: [PATCH 3.10 141/319] scsi: mpt3sas: Fix secure erase premature termination

[Willy Tarreau]

On Tue, Feb 07, 2017 at 06:12:34PM +0100, Willy Tarreau wrote:
> On Tue, Feb 07, 2017 at 09:02:51AM -0800, James Bottomley wrote:
> > On Tue, 2017-02-07 at 07:59 +0100, Willy Tarreau wrote:
> > > Hi James,
> > > 
> > > On Mon, Feb 06, 2017 at 10:38:48PM -0800, James Bottomley wrote:
> > > > On Mon, 2017-02-06 at 23:26 +0100, Willy Tarreau wrote:
> > > (...)
> > > > > We don't have the referenced commit above in 3.10 so we should be
> > > > > safe. Additionally I checked that neither 4.4 nor 3.12 have them 
> > > > > either, so that makes me feel confident that we can skip it in 
> > > > > 3.10 as well.
> > > > 
> > > > The original was also racy with respect to multiple commands, so 
> > > > the above fixed the race as well.
> > > 
> > > OK so I tried to backport it to 3.10. I dropped a few parts which 
> > > were addressing this one marked for stable 4.4+ :
> > > 7ff723a ("scsi: mpt3sas: Unblock device after controller reset")
> > > 
> > > And I got the attached patch. All I know is that it builds. I'd 
> > > appreciate it if someone could confirm its validity, in which case
> > > I'll add it.
> > 
> > The two patches apply without fuzz to your tree and the combination is
> > a far better bug fix than the original regardless of whether 7ff723a
> > exists in your tree or not.  By messing with the patches all you do is
> > add the potential for introducing new bugs for no benefit, so why take
> > risk for no upside?
> 
> Just because I'm suggested to apply this fix which is supposed to fix
> a regression brought by 7ff723a which itself is marked to fix 4.4+ only
> and which doesn't apply to 3.10. So now I'm getting confused because
> you say that these patches apply without fuzz but one part definitely
> is rejected and the other one has to be applied by hand. I want not
> to take a risk but I'm faced with these options :
>   - drop all these patches and stay as 3.10.104 is
>   - merge the "secure erase premature" + the the part of the patch
> that supposedly fixes the regression it introduced
>   - merge this fix + 7ff723a + whatever it depends on (not fond of
> it)
> 
> In all cases I don't even have the hardware to validate anything. I'd
> be more tempted with the first two options. If you think I'm taking
> risks by backporting the relevant part of the fix, I'll simply drop
> them all and leave the code as it is now.

So I could backport the fix marked for 4.4+ (7ff723a) and the one
suggested by Sathya (ffb5845). The context was slightly different
but the changes obvious enough to look good. If everyone is OK, I'll
add these two commits. Here are the backports.

Willy
>From acd34b89fe261c88398e26bd305552eb7808 Mon Sep 17 00:00:00 2001
From: Suganath Prabu S 
Date: Thu, 17 Nov 2016 16:15:58 +0530
Subject: scsi: mpt3sas: Unblock device after controller reset

commit 7ff723ad0f87feba43dda45fdae71206063dd7d4 upstream.

While issuing any ATA passthrough command to firmware the driver will
block the device. But it will unblock the device only if the I/O
completes through the ISR path. If a controller reset occurs before
command completion the device will remain in blocked state.

Make sure we unblock the device following a controller reset if an ATA
passthrough command was queued.

[mkp: clarified patch description]

Cc:  # v4.4+
Fixes: ac6c2a93bd07 ("mpt3sas: Fix for SATA drive in blocked state, after diag 
reset")
Signed-off-by: Suganath Prabu S 
Signed-off-by: Martin K. Petersen 
[wt: adjust context]
Signed-off-by: Willy Tarreau 
---
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index e414b71..8979403 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -3390,6 +3390,11 @@ _scsih_check_volume_delete_events(struct MPT3SAS_ADAPTER 
*ioc,
le16_to_cpu(event_data->VolDevHandle));
 }
 
+static inline bool ata_12_16_cmd(struct scsi_cmnd *scmd)
+{
+   return (scmd->cmnd[0] == ATA_12 || scmd->cmnd[0] == ATA_16);
+}
+
 /**
  * _scsih_flush_running_cmds - completing outstanding commands.
  * @ioc: per adapter object
@@ -3411,6 +3416,9 @@ _scsih_flush_running_cmds(struct MPT3SAS_ADAPTER *ioc)
if (!scmd)
continue;
count++;
+   if (ata_12_16_cmd(scmd))
+   scsi_internal_device_unblock(scmd->device,
+   SDEV_RUNNING);
mpt3sas_base_free_smid(ioc, smid);
scsi_dma_unmap(scmd);
if (ioc->pci_error_recovery)
@@ -3515,11 +3523,6 @@ _scsih_eedp_error_handling(struct scsi_cmnd *scmd, u16 
ioc_status)
SAM_STAT_CHECK_CONDITION;
 }
 
-static inline bool ata_12_16_cmd(struct scsi_cmnd *scmd)
-{
-   return (scmd->cmnd[0] == ATA_12 || scmd->cmnd[0] == ATA_16);
-}
-
 /**
  * _scsih_qcmd_lck - main scsi requ

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

[Amir Goldstein]

On Wed, Feb 8, 2017 at 1:42 AM, James Bottomley
 wrote:
> On Tue, 2017-02-07 at 14:25 -0800, Christoph Hellwig wrote:
>> On Tue, Feb 07, 2017 at 11:01:29PM +0200, Amir Goldstein wrote:
>> > Project id's are not exactly "subtree" semantic, but inheritance
>> > semantics,
>> > which is not the same when non empty directories get their project
>> > id changed.
>> > Here is a recap:
>> > https://lwn.net/Articles/623835/
>>
>> Yes - but if we abuse them for containers we could refine the
>> semantics to simply not allow change of project ids from inside
>> containers based on say capabilities.
>

You mean something like this:
https://lwn.net/Articles/632917/

With the suggested protected_projects, projid 0 (also inside container)
gets a special meaning, much like user 0, so we may do interesting
things with the projid that is mapped to 0.

> We can't really abuse projectid, it's part of the user namespace
> mapping (for project quota).  What we can do is have a new id that
> behaves like it.
>

Perhaps we *can* use projid without abusing it.
userns already maps projids, but there is no concept of "owning project"
for a userns, nor does it make a lot of sense, because projid is not
part of the credentials.
But if we re-brand it as "container root projid", we can try to use it
for defining semantics to grant unprivileged access to a subtree.

The functionality you are trying to get with shiftfs mark does
sounds a bit like "container root projid":
- inodes with mapped projid MAY be uid/gid shifted
- inodes with unmapped projid MAY NOT

I realize this may be very raw, but its a start. If you like this
direction we can try to develop it.

> But like I said, we don't really need a ful ID, it would basically just
> be a single bit mark to say remap or not when doing permission checks
> against this inode.  It would follow some of the project id semantics
> (like inheritance from parent dir)
>

But a single bit would only work for single level of userns nesting won't it?


>> > I guess we should define the semantics for the required sub-tree
>> > marking, before we can talk about solutions.
>>
>> Good plan.
>
> So I've been thinking about how to do this without subtree marking and
> yet retain the subtree properties similar to project id.  The advantage
> would be that if it can be done using only inode properties, then none
> of the permission prototypes need change.  The only real subtree
> property we need is ability to bind into an unprivileged mount
> namespace, but we already have that.  The gotcha about marking inodes
> is that they're all or nothing, so every subtree that gets access to
> the inode inherits the mark.  This means that we cannot allow a user
> access to a marked inode without the cover of an unprivileged user
> namespace, but I think that's fixable in the permission check
> (basically if the inode is marked you *only* get access if you have a
> user_ns != init_user_ns and we do the permission shifts or you have
> user_ns == init_user_ns and you are admin capable).
>

I didn't follow, but it sounds like your proposed solutions is only
good for single level of userns nesting.
Do you think you can redefine it in terms of "container root projid".

Re: [PATCH v2] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs

[Pan Xinhui]

在 2017/2/8 14:09, Boqun Feng 写道:

On Wed, Feb 08, 2017 at 12:05:40PM +0800, Boqun Feng wrote:

On Wed, Feb 08, 2017 at 11:39:10AM +0800, Xinhui Pan wrote:

2016-12-26 4:26 GMT+08:00 Waiman Long :


A number of cmpxchg calls in qspinlock_paravirt.h were replaced by more
relaxed versions to improve performance on architectures that use LL/SC.

All the locking related cmpxchg's are replaced with the _acquire
variants:
 - pv_queued_spin_steal_lock()
 - trylock_clear_pending()

The cmpxchg's related to hashing are replaced by either by the _release
or the _relaxed variants. See the inline comment for details.

Signed-off-by: Waiman Long 

 v1->v2:
  - Add comments in changelog and code for the rationale of the change.

---
 kernel/locking/qspinlock_paravirt.h | 50 --
---
 1 file changed, 33 insertions(+), 17 deletions(-)


@@ -323,8 +329,14 @@ static void pv_wait_node(struct mcs_spinlock *node,
struct mcs_spinlock *prev)
 * If pv_kick_node() changed us to vcpu_hashed, retain that
 * value so that pv_wait_head_or_lock() knows to not also
try
 * to hash this lock.
+*
+* The smp_store_mb() and control dependency above will
ensure
+* that state change won't happen before that.
Synchronizing
+* with pv_kick_node() wrt hashing by this waiter or by the
+* lock holder is done solely by the state variable. There
is
+* no other ordering requirement.
 */
-   cmpxchg(&pn->state, vcpu_halted, vcpu_running);
+   cmpxchg_relaxed(&pn->state, vcpu_halted, vcpu_running);

/*
 * If the locked flag is still not set after wakeup, it is
a
@@ -360,9 +372,12 @@ static void pv_kick_node(struct qspinlock *lock,
struct mcs_spinlock *node)
 * pv_wait_node(). If OTOH this fails, the vCPU was running and
will
 * observe its next->locked value and advance itself.
 *
-* Matches with smp_store_mb() and cmpxchg() in pv_wait_node()
+* Matches with smp_store_mb() and cmpxchg_relaxed() in
pv_wait_node().
+* A release barrier is used here to ensure that node->locked is
+* always set before changing the state. See comment in
pv_wait_node().
 */
-   if (cmpxchg(&pn->state, vcpu_halted, vcpu_hashed) != vcpu_halted)
+   if (cmpxchg_release(&pn->state, vcpu_halted, vcpu_hashed)
+   != vcpu_halted)
return;

hi, Waiman

We can't use _release here, a full barrier is needed.

There is pv_kick_node vs pv_wait_head_or_lock

[w] l->locked = _Q_SLOW_VAL  //reordered here

if (READ_ONCE(pn->state) == vcpu_hashed) //False.

   lp = (struct qspinlock **)1;

[STORE] pn->state = vcpu_hashedlp = pv_hash(lock,
pn);
pv_hash()if
(xchg(&l->locked, _Q_SLOW_VAL) == 0) // fasle, not unhashed.



This analysis is correct, but..



Hmm.. look at this again, I don't think this analysis is meaningful,
let's say the reordering didn't happen, we still got(similar to your
case):

if (READ_ONCE(pn->state) == 
vcpu_hashed) // false.
  lp = (struct qspinlock **)1;

cmpxchg(pn->state, vcpu_halted, vcpu_hashed);
  if(!lp) {
lp = pv_hash(lock, pn);
WRITE_ONCE(l->locked, _Q_SLOW_VAL);
pv_hash();
if (xchg(&l->locked, 
_Q_SLOW_VAL) == 0) // fasle, not unhashed.

, right?

Actually, I think this or your case could not happen because we have

cmpxchg(pn->state, vcpu_halted, vcpu_running);

in pv_wait_node(), which makes us either observe vcpu_hashed or set
pn->state to vcpu_running before pv_kick_node() trying to do the hash.


yep, there is still a race. We have to fix it.
so I think
we must check old = xchg(&l->locked, _Q_SLOW_VAL)
if (old  == 0)
do something
else if (old  == _Q_SLOW_VAL)
do something else


I may miss something subtle, but does switching back to cmpxchg() could
fix the RCU stall you observed?


yes, just fix this cmpxchg and then no RCU stall.


Regards,
Boqun


Then the same lock has hashed twice but only unhashed once. So at last as
the hash table grows big, we hit RCU stall.

I hit RCU stall when I run netperf benchmark



how will a big hash table hit RCU stall? Do you have the call trace for
your RCU stall?


maybe too many time on hashing? I am not sure.


Regards,
Boqun


thanks
xinhui



--
1.8.3.1

Re: [PATCH v2] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs

[Pan Xinhui]

在 2017/2/8 14:09, Boqun Feng 写道:

On Wed, Feb 08, 2017 at 12:05:40PM +0800, Boqun Feng wrote:

On Wed, Feb 08, 2017 at 11:39:10AM +0800, Xinhui Pan wrote:

2016-12-26 4:26 GMT+08:00 Waiman Long :


A number of cmpxchg calls in qspinlock_paravirt.h were replaced by more
relaxed versions to improve performance on architectures that use LL/SC.

All the locking related cmpxchg's are replaced with the _acquire
variants:
 - pv_queued_spin_steal_lock()
 - trylock_clear_pending()

The cmpxchg's related to hashing are replaced by either by the _release
or the _relaxed variants. See the inline comment for details.

Signed-off-by: Waiman Long 

 v1->v2:
  - Add comments in changelog and code for the rationale of the change.

---
 kernel/locking/qspinlock_paravirt.h | 50 --
---
 1 file changed, 33 insertions(+), 17 deletions(-)


@@ -323,8 +329,14 @@ static void pv_wait_node(struct mcs_spinlock *node,
struct mcs_spinlock *prev)
 * If pv_kick_node() changed us to vcpu_hashed, retain that
 * value so that pv_wait_head_or_lock() knows to not also
try
 * to hash this lock.
+*
+* The smp_store_mb() and control dependency above will
ensure
+* that state change won't happen before that.
Synchronizing
+* with pv_kick_node() wrt hashing by this waiter or by the
+* lock holder is done solely by the state variable. There
is
+* no other ordering requirement.
 */
-   cmpxchg(&pn->state, vcpu_halted, vcpu_running);
+   cmpxchg_relaxed(&pn->state, vcpu_halted, vcpu_running);

/*
 * If the locked flag is still not set after wakeup, it is
a
@@ -360,9 +372,12 @@ static void pv_kick_node(struct qspinlock *lock,
struct mcs_spinlock *node)
 * pv_wait_node(). If OTOH this fails, the vCPU was running and
will
 * observe its next->locked value and advance itself.
 *
-* Matches with smp_store_mb() and cmpxchg() in pv_wait_node()
+* Matches with smp_store_mb() and cmpxchg_relaxed() in
pv_wait_node().
+* A release barrier is used here to ensure that node->locked is
+* always set before changing the state. See comment in
pv_wait_node().
 */
-   if (cmpxchg(&pn->state, vcpu_halted, vcpu_hashed) != vcpu_halted)
+   if (cmpxchg_release(&pn->state, vcpu_halted, vcpu_hashed)
+   != vcpu_halted)
return;

hi, Waiman

We can't use _release here, a full barrier is needed.

There is pv_kick_node vs pv_wait_head_or_lock

[w] l->locked = _Q_SLOW_VAL  //reordered here

if (READ_ONCE(pn->state) == vcpu_hashed) //False.

   lp = (struct qspinlock **)1;

[STORE] pn->state = vcpu_hashedlp = pv_hash(lock,
pn);
pv_hash()if
(xchg(&l->locked, _Q_SLOW_VAL) == 0) // fasle, not unhashed.



This analysis is correct, but..



Hmm.. look at this again, I don't think this analysis is meaningful,
let's say the reordering didn't happen, we still got(similar to your
case):

if (READ_ONCE(pn->state) == 
vcpu_hashed) // false.
  lp = (struct qspinlock **)1;

cmpxchg(pn->state, vcpu_halted, vcpu_hashed);
  if(!lp) {
lp = pv_hash(lock, pn);
WRITE_ONCE(l->locked, _Q_SLOW_VAL);
pv_hash();
if (xchg(&l->locked, 
_Q_SLOW_VAL) == 0) // fasle, not unhashed.

, right?

Actually, I think this or your case could not happen because we have

cmpxchg(pn->state, vcpu_halted, vcpu_running);

in pv_wait_node(), which makes us either observe vcpu_hashed or set
pn->state to vcpu_running before pv_kick_node() trying to do the hash.


yep, there is still a race. We have to fix it.
so I think
we must check old = xchg(&l->locked, _Q_SLOW_VAL)
if (old  == 0)
do something
else if (old  == _Q_SLOW_VAL)
do something else


I may miss something subtle, but does switching back to cmpxchg() could
fix the RCU stall you observed?


yes, just fix this cmpxchg and then no RCU stall.


Regards,
Boqun


Then the same lock has hashed twice but only unhashed once. So at last as
the hash table grows big, we hit RCU stall.

I hit RCU stall when I run netperf benchmark



how will a big hash table hit RCU stall? Do you have the call trace for
your RCU stall?

Regards,
Boqun


thanks
xinhui



--
1.8.3.1

[PATCH] drivers: usb: early: remove unused code

[Gustavo A. R. Silva]

Remove this line of code because devnum is overwritten before it can be used.
This could happen if line of code 609 (goto try_again;) is executed. Otherwise,
devnum is never used again.

Addresses-Coverity-ID: 1226870
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/usb/early/ehci-dbgp.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/early/ehci-dbgp.c b/drivers/usb/early/ehci-dbgp.c
index ea73afb..e265444 100644
--- a/drivers/usb/early/ehci-dbgp.c
+++ b/drivers/usb/early/ehci-dbgp.c
@@ -580,7 +580,6 @@ static int _dbgp_external_startup(void)
USB_DEBUG_DEVNUM);
goto err;
}
-   devnum = USB_DEBUG_DEVNUM;
dbgp_printk("debug device renamed to 127\n");
}
 
-- 
2.5.0

Re: [PATCH v2 2/5] async_tx: Handle DMA devices having support for fewer PQ coefficients

[Anup Patel]

On Tue, Feb 7, 2017 at 10:12 PM, Vinod Koul  wrote:
> On Tue, Feb 07, 2017 at 02:32:15PM +0530, Anup Patel wrote:
>> On Tue, Feb 7, 2017 at 1:57 PM, Dan Williams  
>> wrote:
>> > On Tue, Feb 7, 2017 at 12:16 AM, Anup Patel  
>> > wrote:
>> >> The DMAENGINE framework assumes that if PQ offload is supported by a
>> >> DMA device then all 256 PQ coefficients are supported. This assumption
>> >> does not hold anymore because we now have BCM-SBA-RAID offload engine
>> >> which supports PQ offload with limited number of PQ coefficients.
>> >>
>> >> This patch extends async_tx APIs to handle DMA devices with support
>> >> for fewer PQ coefficients.
>> >>
>> >> Signed-off-by: Anup Patel 
>> >> Reviewed-by: Scott Branden 
>> >
>> > I don't like this approach. Define an interface for md to query the
>> > offload engine once at the beginning of time. We should not be adding
>> > any new extensions to async_tx.
>>
>> Even if we do capability checks in Linux MD, we still need a way
>> for DMAENGINE drivers to advertise number of PQ coefficients
>> handled by the HW.
>
> If the question is only for advertising caps, then why not do as done
> for dma_get_slave_caps(). you can add dma_get_pq_caps() so that clients (md)
> in this case would know the HW capability.

We have large number of possible capabilities for
DMA slave such as src_addr_widths, dst_addr_widths,
directions, max_burst, residue_granularity, and
descriptor_resue.

The possible capabilities of PQ offload are:
1. Number of PQ sources handled by PQ offload
(Represented by "max_pq" member of "struct dma_device")
2. Number of PQ coefficients handled by PQ offload

The above two PQ capabilities are good enough for
current PQ HW and future PQ HW so we just need a
way to specify number of PQ coefficients.

Till now all of the PQ HW always supported all 256
PQ coefficients so we never felt the need of capability
to specify PQ coefficients. The BCM-SBA-RAID is the
only HW (as far as I know) which does not support all
256 PQ coefficients.

Currently, DMAENGINE drivers use dma_set_maxpq() to
specify number of PQ sources handled by PQ HW and
Linux Async Tx uses dma_maxpq() to get number of
PQ sources.

On similar lines, we added dma_set_maxpqcoef() to
specify number of PQ coefficients and Linux Async Tx
uses dma_maxpqcoef() to get number of PQ coefficients.
If DMAENGINE driver does not specify PQ coefficients
then dma_maxpqcoef() will return 256 assuming all
PQ coefficients are supported. This approach is
backward compatible to existing DMAENGINE APIs
and will not break existing DMAENGINE drivers.

If we add dma_get_pq_caps() similar to the
dma_get_slave_caps() for PQ capabilities then we
will have to use this new method for both of the above
PQ capabilities and we have to change all DMAENGINE
drivers to use new method of specifying PQ capabilities.
I think this is too intrusive and bit overkill because its
very very unlikely to see anymore additions to
PQ capabilities.

Regards,
Anup

Re: [PATCH 4.9 00/66] 4.9.9-stable review

[Greg Kroah-Hartman]

On Tue, Feb 07, 2017 at 04:27:32PM -0800, kernelci.org bot wrote:
> stable-rc boot: 217 boots: 0 failed, 207 passed with 10 offline 
> (v4.9.8-67-gf1cb727f439b)

0 failed!  Wow, either you all fixed the build system, or something went
right here :)

thanks for the report.

greg k-h

Re: [PATCH 4.9 00/66] 4.9.9-stable review

[Greg Kroah-Hartman]

On Tue, Feb 07, 2017 at 01:44:41PM -0800, Guenter Roeck wrote:
> On Tue, Feb 07, 2017 at 01:58:34PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.9.9 release.
> > There are 66 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Thu Feb  9 12:45:13 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 149 pass: 149 fail: 0
> Qemu test results:
>   total: 122 pass: 122 fail: 0
> 
> Details are available at http://kerneltests.org/builders.

Thanks for testing both of these and letting me know.

greg k-h

Re: [PATCH 4.4 00/29] 4.4.48-stable review

[Greg Kroah-Hartman]

On Tue, Feb 07, 2017 at 05:27:32PM -0800, kernelci.org bot wrote:
> stable-rc boot: 517 boots: 0 failed, 498 passed with 19 offline 
> (v4.4.47-30-gcd13c41318b2)

Why is there almost double the number of "passed" systems here compared
to 4.9?

thanks,

greg k-h

Re: [lustre-devel] [PATCH 10/60] staging: lustre: obdclass: add more info to sysfs version string

[Greg Kroah-Hartman]

On Wed, Feb 08, 2017 at 01:04:52AM +, Dilger, Andreas wrote:
> 
> > On Feb 3, 2017, at 03:33, Greg Kroah-Hartman  
> > wrote:
> > 
> > On Sat, Jan 28, 2017 at 07:04:38PM -0500, James Simmons wrote:
> >> From: Andreas Dilger 
> >> 
> >> Update the sysfs "version" file to print "lustre: " with
> >> the version number.
> >> 
> >> Signed-off-by: Andreas Dilger 
> >> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5969
> >> Reviewed-on: http://review.whamcloud.com/16721
> >> Reviewed-by: James Simmons 
> >> Reviewed-by: Dmitry Eremin 
> >> Reviewed-by: Oleg Drokin 
> >> Signed-off-by: James Simmons 
> >> ---
> >> drivers/staging/lustre/lustre/obdclass/linux/linux-module.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >> 
> >> diff --git a/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c 
> >> b/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
> >> index 9f5e829..22e6d1f 100644
> >> --- a/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
> >> +++ b/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
> >> @@ -208,7 +208,7 @@ struct miscdevice obd_psdev = {
> >> static ssize_t version_show(struct kobject *kobj, struct attribute *attr,
> >>char *buf)
> >> {
> >> -  return sprintf(buf, "%s\n", LUSTRE_VERSION_STRING);
> >> +  return sprintf(buf, "lustre: %s\n", LUSTRE_VERSION_STRING);
> >> }
> > 
> > Why?  You "know" this is lustre, why say it again?  Doesn't this affect
> > userspace tools?
> 
> It included "lustre: " as a prefix until commit 8b8284450569 when the code
> moved from /proc to /sys, and is what the userspace tools expect.  Formerly
> there were multiple strings printed in this file, each with a different 
> prefix,
> but the "lustre: " prefix was dropped in the move to sysfs.
> 
> That didn't matter until a userspace patch to stop using 
> ioctl(IOC_GET_VERSION)
> and instead get the version from the existing /proc or /sys files, so that we
> can deprecate and eventually drop the IOC_GET_VERSION ioctl completely.
> 
> So this patch is returning to the previous format of the /proc file, but if
> there is a big objection to this patch we can also change the userspace tools
> to live with or without this prefix now that there is only a single value 
> here.

Think about it, it's a sysfs file, which should only have one value to
start with, and you are opening it from userspace knowing exactly where
it is (somewhere in the lustre subtree), so of course you know it is
"lustre"...

greg k-h

Re: [PATCH] block: Make rescuer threads per request_queue, not per bioset

[kbuild test robot]

Hi Kent,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.10-rc7]
[cannot apply to next-20170207]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Kent-Overstreet/block-Make-rescuer-threads-per-request_queue-not-per-bioset/20170208-130414
config: x86_64-randconfig-x017-201706 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/uapi/linux/capability.h:16,
from include/linux/capability.h:15,
from include/linux/sched.h:15,
from include/linux/kasan.h:4,
from kernel/sched/core.c:29:
   kernel/sched/core.c: In function 'sched_submit_work':
   kernel/sched/core.c:3445:7: error: implicit declaration of function 
'bio_list_empty' [-Werror=implicit-function-declaration]
 !bio_list_empty(&tsk->bio_list->bios) &&
  ^
   include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> kernel/sched/core.c:3444:2: note: in expansion of macro 'if'
 if (tsk->bio_list &&
 ^~
   kernel/sched/core.c:3445:36: error: dereferencing pointer to incomplete type 
'struct bio_plug_list'
 !bio_list_empty(&tsk->bio_list->bios) &&
   ^
   include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> kernel/sched/core.c:3444:2: note: in expansion of macro 'if'
 if (tsk->bio_list &&
 ^~
   kernel/sched/core.c:3447:3: error: implicit declaration of function 
'blk_punt_blocked_bios' [-Werror=implicit-function-declaration]
  blk_punt_blocked_bios(tsk->bio_list);
  ^
   cc1: some warnings being treated as errors

vim +/if +3444 kernel/sched/core.c

  3428  
  3429  /* causes final put_task_struct in finish_task_switch(). */
  3430  __set_current_state(TASK_DEAD);
  3431  current->flags |= PF_NOFREEZE;  /* tell freezer to ignore us */
  3432  __schedule(false);
  3433  BUG();
  3434  /* Avoid "noreturn function does return".  */
  3435  for (;;)
  3436  cpu_relax();/* For when BUG is null */
  3437  }
  3438  
  3439  static inline void sched_submit_work(struct task_struct *tsk)
  3440  {
  3441  if (!tsk->state || tsk_is_pi_blocked(tsk))
  3442  return;
  3443  
> 3444  if (tsk->bio_list &&
  3445  !bio_list_empty(&tsk->bio_list->bios) &&
  3446  tsk->bio_list->q->rescue_workqueue)
  3447  blk_punt_blocked_bios(tsk->bio_list);
  3448  
  3449  /*
  3450   * If we are going to sleep and we have plugged IO queued,
  3451   * make sure to submit it to avoid deadlocks.
  3452   */

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH] block: Make rescuer threads per request_queue, not per bioset

[kbuild test robot]

Hi Kent,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc7]
[cannot apply to next-20170207]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Kent-Overstreet/block-Make-rescuer-threads-per-request_queue-not-per-bioset/20170208-130414
config: x86_64-randconfig-x014-201706 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   kernel/sched/core.c: In function 'sched_submit_work':
>> kernel/sched/core.c:3445:7: error: implicit declaration of function 
>> 'bio_list_empty' [-Werror=implicit-function-declaration]
 !bio_list_empty(&tsk->bio_list->bios) &&
  ^~
>> kernel/sched/core.c:3445:36: error: dereferencing pointer to incomplete type 
>> 'struct bio_plug_list'
 !bio_list_empty(&tsk->bio_list->bios) &&
   ^~
>> kernel/sched/core.c:3447:3: error: implicit declaration of function 
>> 'blk_punt_blocked_bios' [-Werror=implicit-function-declaration]
  blk_punt_blocked_bios(tsk->bio_list);
  ^
   cc1: some warnings being treated as errors

vim +/bio_list_empty +3445 kernel/sched/core.c

  3439  static inline void sched_submit_work(struct task_struct *tsk)
  3440  {
  3441  if (!tsk->state || tsk_is_pi_blocked(tsk))
  3442  return;
  3443  
  3444  if (tsk->bio_list &&
> 3445  !bio_list_empty(&tsk->bio_list->bios) &&
  3446  tsk->bio_list->q->rescue_workqueue)
> 3447  blk_punt_blocked_bios(tsk->bio_list);
  3448  
  3449  /*
  3450   * If we are going to sleep and we have plugged IO queued,

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v3 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses

[Juergen Gross]

On 07/02/17 23:39, Boris Ostrovsky wrote:
> On 02/07/2017 12:51 PM, Boris Ostrovsky wrote:
>> On 01/24/2017 11:23 AM, Juergen Gross wrote:
>>> On 24/01/17 14:47, Boris Ostrovsky wrote:
 On 01/23/2017 01:59 PM, Boris Ostrovsky wrote:
> On 01/23/2017 05:09 AM, Juergen Gross wrote:
>> Handling of multiple concurrent Xenstore accesses through xenbus driver
>> either from the kernel or user land is rather lame today: xenbus is
>> capable to have one access active only at one point of time.
>>
>>
 This patch appears to break save/restore:
>>> Hmm, tried multiple times, but I can't reproduce this issue.
>>>
>>> Anything special in the setup? I tried a 64 bit pv guest and did
>>> "xl save".
>>>
>>> Do I have to run some load in parallel?
>> Any luck reproducing this? I am still failing the test on dumpdata but I
>> couldn't reproduce it on another system.
> 
> 
> The problem appears to be xs_state_users being non-zero when we call
> xs_suspend_enter().
> 
> From what I understand this is caused by xs_request_exit() not
> decrementing it when closing a transaction. This seems to be happening
> when XS_TRANSACTION_END transaction returns XS_ERROR (I haven't traced
> what causes this error but it doesn't appear to cause any visible harm).

Aah, of course: this will happen for a transaction failing due to a
conflict (EAGAIN case).

> Does the patch below make sense?

As the xenbus driver is checking for the transaction id to be valid this
is okay, I think.

I have noticed another problem, though: a user client mixing Xenstore
accesses with and without transactions could be blocked when doing a
non-transactional access hindering it from completing the transaction.

I'll send an updated version including your fix.

> 
> diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
> index e62cb09..ffd5fac 100644
> --- a/drivers/xen/xenbus/xenbus_xs.c
> +++ b/drivers/xen/xenbus/xenbus_xs.c
> @@ -140,7 +140,7 @@ void xs_request_exit(struct xb_req_data *req)
> spin_lock(&xs_state_lock);
> xs_state_users--;
> if ((req->type == XS_TRANSACTION_START && req->msg.type ==
> XS_ERROR) ||
> -   req->msg.type == XS_TRANSACTION_END)
> +   req->type == XS_TRANSACTION_END)
> xs_state_users--;
> spin_unlock(&xs_state_lock);
> 
> 
> I ran a few tests on dumpdata and they completed successfully. I'll keep
> this for the overnight runs too, with a different Xen version.

Thanks.


Juergen

[PATCH 1/2] spi: imx: dynamic burst length adjust for PIO mode

[Jiada Wang]

previously burst length (BURST_LENGTH) is always set to equal
to bits_per_word, causes a 10us gap between each word in
transfer, which significantly affects performance.

This patch uses 32 bits transfer to simulate lower bits transfer,
and adjusts burst length runtimely to use biggeest burst length
as possible to reduce the gaps in transfer for PIO mode.

Signed-off-by: Jiada Wang 
---
 drivers/spi/spi-imx.c | 151 +++---
 1 file changed, 143 insertions(+), 8 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 9a7c62f..04b4ea8 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -56,9 +56,11 @@
 
 /* The maximum  bytes that a sdma BD can transfer.*/
 #define MAX_SDMA_BD_BYTES  (1 << 15)
+#define MX51_ECSPI_CTRL_MAX_BURST  512
 struct spi_imx_config {
unsigned int speed_hz;
unsigned int bpw;
+   unsigned int len;
 };
 
 enum spi_imx_devtype {
@@ -96,12 +98,14 @@ struct spi_imx_data {
 
unsigned int bytes_per_word;
 
-   unsigned int count;
+   unsigned int count, count_index;
void (*tx)(struct spi_imx_data *);
void (*rx)(struct spi_imx_data *);
void *rx_buf;
const void *tx_buf;
unsigned int txfifo; /* number of words pushed in tx FIFO */
+   unsigned int dynamic_burst, bpw_rx;
+   unsigned int bpw_w;
 
/* DMA */
bool usedma;
@@ -250,6 +254,7 @@ static bool spi_imx_can_dma(struct spi_master *master, 
struct spi_device *spi,
 #define MX51_ECSPI_CTRL_PREDIV_OFFSET  12
 #define MX51_ECSPI_CTRL_CS(cs) ((cs) << 18)
 #define MX51_ECSPI_CTRL_BL_OFFSET  20
+#define MX51_ECSPI_CTRL_BL_MASK(0xfff << 20)
 
 #define MX51_ECSPI_CONFIG  0x0c
 #define MX51_ECSPI_CONFIG_SCLKPHA(cs)  (1 << ((cs) +  0))
@@ -277,6 +282,79 @@ static bool spi_imx_can_dma(struct spi_master *master, 
struct spi_device *spi,
 #define MX51_ECSPI_TESTREG 0x20
 #define MX51_ECSPI_TESTREG_LBC BIT(31)
 
+static void spi_imx_u32_swap_u8(struct spi_transfer *transfer, u8 *buf)
+{
+   int i;
+
+   for (i = 0; i < transfer->len / 4; i++) {
+   u8 temp;
+
+   temp = *(buf + i * 4);
+   *(buf + i * 4) = *(buf + i * 4 + 3);
+   *(buf + i * 4 + 3) = temp;
+
+   temp = *(buf + i * 4 + 1);
+   *(u8 *)(buf + i * 4 + 1) = *(buf + i * 4 + 2);
+   *(buf + i * 4 + 2) = temp;
+   }
+}
+
+static void spi_imx_u32_swap_u16(struct spi_transfer *transfer, u16 *buf)
+{
+   int i;
+
+   for (i = 0; i < transfer->len / 4; i++) {
+   u16 temp;
+
+   temp = *(buf + i * 2);
+   *(buf + i * 2) = *(buf + i * 2 + 1);
+   *(buf + i * 2 + 1) = temp;
+   }
+}
+
+static void spi_imx_buf_rx_swap(struct spi_imx_data *spi_imx)
+{
+   if (!spi_imx->bpw_rx) {
+   spi_imx_buf_rx_u32(spi_imx);
+   return;
+   }
+
+   if (spi_imx->bpw_w == 1)
+   spi_imx_buf_rx_u8(spi_imx);
+   else if (spi_imx->bpw_w == 2)
+   spi_imx_buf_rx_u16(spi_imx);
+}
+
+static void spi_imx_buf_tx_swap(struct spi_imx_data *spi_imx)
+{
+   u32 ctrl, val;
+
+   if (spi_imx->count == spi_imx->count_index) {
+   spi_imx->count_index = spi_imx->count > sizeof(u32) ?
+   spi_imx->count % sizeof(u32) : 0;
+   ctrl = readl(spi_imx->base + MX51_ECSPI_CTRL);
+   ctrl &= ~MX51_ECSPI_CTRL_BL_MASK;
+   if (spi_imx->count >= sizeof(u32))
+   val = spi_imx->count - spi_imx->count_index;
+   else {
+   val = spi_imx->bpw_w;
+   spi_imx->bpw_rx = 1;
+   }
+   ctrl |= ((val * 8 - 1) << MX51_ECSPI_CTRL_BL_OFFSET);
+   writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
+   }
+
+   if (spi_imx->count >= sizeof(u32)) {
+   spi_imx_buf_tx_u32(spi_imx);
+   return;
+   }
+
+   if (spi_imx->bpw_w == 1)
+   spi_imx_buf_tx_u8(spi_imx);
+   else if (spi_imx->bpw_w == 2)
+   spi_imx_buf_tx_u16(spi_imx);
+}
+
 /* MX51 eCSPI */
 static unsigned int mx51_ecspi_clkdiv(struct spi_imx_data *spi_imx,
  unsigned int fspi, unsigned int *fres)
@@ -362,7 +440,14 @@ static int mx51_ecspi_config(struct spi_device *spi,
/* set chip select to use */
ctrl |= MX51_ECSPI_CTRL_CS(spi->chip_select);
 
-   ctrl |= (config->bpw - 1) << MX51_ECSPI_CTRL_BL_OFFSET;
+   if (spi_imx->dynamic_burst) {
+   if (config->len > MX51_ECSPI_CTRL_MAX_BURST)
+   ctrl |= MX51_ECSPI_CTRL_BL_MASK;
+   else
+   ctrl |= (((config->len - config->len % 4) * 8 - 1) <<
+   MX51_ECSPI_CTRL_BL_OFFSET);
+   } else
+   ctrl |= (config->bp

[PATCH linux-next v1 0/2] improve imx spi performance

[Jiada Wang]

previously burst length (BURST_LENGTH) is always set to equal
to bits_per_word, causes a 10us gap between each word in transfer,
which significantly affects performance.

This patch set uses 32 bits tranfser to simulate lowers bits transfer,
and by set burst length to maximum possible value to reduce number of gaps
in both PIO & DMA transfers.

* This patch set is against linux-next tree

Jiada Wang (2):
  spi: imx: dynamic burst length adjust for PIO mode
  spi: imx: dynamic burst length adjust for DMA mode

 drivers/spi/spi-imx.c | 293 +-
 1 file changed, 267 insertions(+), 26 deletions(-)

-- 
2.9.3

[PATCH 2/2] spi: imx: dynamic burst length adjust for DMA mode

[Jiada Wang]

previously burst length (BURST_LENGTH) is always set to equal
to bits_per_word, causes a 10us gap between each word in
transfer, which significantly affects performance.

This patch uses 32 bits transfer to simulate lower bits transfer,
and adjusts burst length to reduce the number of gaps in DMA
transfer.

Signed-off-by: Jiada Wang 
---
 drivers/spi/spi-imx.c | 154 ++
 1 file changed, 130 insertions(+), 24 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 04b4ea8..68ff781 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -39,6 +39,8 @@
 #include 
 #include 
 
+#include 
+
 #include 
 #include 
 
@@ -216,6 +218,7 @@ static bool spi_imx_can_dma(struct spi_master *master, 
struct spi_device *spi,
 {
struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
unsigned int bpw, i;
+   u32 length, div;
 
if (!master->dma_rx)
return false;
@@ -232,8 +235,18 @@ static bool spi_imx_can_dma(struct spi_master *master, 
struct spi_device *spi,
if (bpw != 1 && bpw != 2 && bpw != 4)
return false;
 
+   length = transfer->len;
+
+   if (spi_imx->dynamic_burst) {
+   bpw = sizeof(u32);
+   length = transfer->len - transfer->len % sizeof(u32);
+   div = length / MX51_ECSPI_CTRL_MAX_BURST  + 1;
+   length = (length / div) - (length / div) % sizeof(u32);
+   spi_imx->count_index = transfer->len - length * div;
+   }
+
for (i = spi_imx_get_fifosize(spi_imx) / 2; i > 0; i--) {
-   if (!(transfer->len % (i * bpw)))
+   if (!(length % (i * bpw)))
break;
}
 
@@ -423,6 +436,7 @@ static int mx51_ecspi_config(struct spi_device *spi,
u32 ctrl = MX51_ECSPI_CTRL_ENABLE;
u32 clk = config->speed_hz, delay, reg;
u32 cfg = readl(spi_imx->base + MX51_ECSPI_CONFIG);
+   u32 div, length;
 
/*
 * The hardware seems to have a race condition when changing modes. The
@@ -441,9 +455,18 @@ static int mx51_ecspi_config(struct spi_device *spi,
ctrl |= MX51_ECSPI_CTRL_CS(spi->chip_select);
 
if (spi_imx->dynamic_burst) {
-   if (config->len > MX51_ECSPI_CTRL_MAX_BURST)
-   ctrl |= MX51_ECSPI_CTRL_BL_MASK;
-   else
+   if (config->len > MX51_ECSPI_CTRL_MAX_BURST) {
+   if (spi_imx->usedma) {
+   length = config->len -
+config->len % sizeof(u32);
+   div = length / MX51_ECSPI_CTRL_MAX_BURST  + 1;
+   length = (length / div) -
+(length / div) % sizeof(u32);
+   ctrl |= ((length * 8 - 1) <<
+   MX51_ECSPI_CTRL_BL_OFFSET);
+   } else
+   ctrl |= MX51_ECSPI_CTRL_BL_MASK;
+   } else
ctrl |= (((config->len - config->len % 4) * 8 - 1) <<
MX51_ECSPI_CTRL_BL_OFFSET);
} else
@@ -933,10 +956,16 @@ static int spi_imx_dma_configure(struct spi_master 
*master,
buswidth = DMA_SLAVE_BUSWIDTH_4_BYTES;
break;
case 2:
-   buswidth = DMA_SLAVE_BUSWIDTH_2_BYTES;
+   if (spi_imx->dynamic_burst)
+   buswidth = DMA_SLAVE_BUSWIDTH_4_BYTES;
+   else
+   buswidth = DMA_SLAVE_BUSWIDTH_2_BYTES;
break;
case 1:
-   buswidth = DMA_SLAVE_BUSWIDTH_1_BYTE;
+   if (spi_imx->dynamic_burst)
+   buswidth = DMA_SLAVE_BUSWIDTH_4_BYTES;
+   else
+   buswidth = DMA_SLAVE_BUSWIDTH_1_BYTE;
break;
default:
return -EINVAL;
@@ -1122,6 +1151,32 @@ static int spi_imx_calculate_timeout(struct spi_imx_data 
*spi_imx, int size)
return msecs_to_jiffies(2 * timeout * MSEC_PER_SEC);
 }
 
+static int spi_imx_pio_txrx(struct spi_imx_data *spi_imx)
+{
+   unsigned long transfer_timeout;
+   unsigned long timeout;
+
+   spi_imx->txfifo = 0;
+
+   reinit_completion(&spi_imx->xfer_done);
+
+   spi_imx_push(spi_imx);
+
+   spi_imx->devtype_data->intctrl(spi_imx, MXC_INT_TE);
+
+   transfer_timeout = spi_imx_calculate_timeout(spi_imx, spi_imx->count);
+
+   timeout = wait_for_completion_timeout(&spi_imx->xfer_done,
+ transfer_timeout);
+   if (!timeout) {
+   dev_err(spi_imx->dev, "I/O Error in PIO\n");
+   spi_imx->devtype_data->reset(spi_imx);
+   return -ETIMEDOUT;
+   }
+
+   return 0;
+}
+
 static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 

Re: [PATCH] staging: rtl8712: rtl8712: fix sparse warnings

[Dan Carpenter]

On Wed, Feb 08, 2017 at 01:19:39AM +, Carlos Palminha wrote:
> 
> 
> On 08-02-2017 00:58, Dan Carpenter wrote:
> >On Wed, Feb 08, 2017 at 12:47:22AM +, Carlos Palminha wrote:
> >>Fixed the following sparse warnings:
> >>* cast from restricted __le32
> >>* invalid assignment from int to __le32
> >>
> >
> >The changelog doesn't give me any confidence that you understand the
> >implications of this patch.  You silenced the warning but I think you
> >may be introducing bugs (I haven't done a thourough review).
> >
> >regards,
> >dan carpenter
> >
> true... i was short on words.
> will resend v2 with better description.

I'm pretty sure the original code is correct and just the sparse
annotations are wrong.

regards,
dan carpenter

Re: [PATCH v2] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs

[Boqun Feng]

On Wed, Feb 08, 2017 at 12:05:40PM +0800, Boqun Feng wrote:
> On Wed, Feb 08, 2017 at 11:39:10AM +0800, Xinhui Pan wrote:
> > 2016-12-26 4:26 GMT+08:00 Waiman Long :
> > 
> > > A number of cmpxchg calls in qspinlock_paravirt.h were replaced by more
> > > relaxed versions to improve performance on architectures that use LL/SC.
> > >
> > > All the locking related cmpxchg's are replaced with the _acquire
> > > variants:
> > >  - pv_queued_spin_steal_lock()
> > >  - trylock_clear_pending()
> > >
> > > The cmpxchg's related to hashing are replaced by either by the _release
> > > or the _relaxed variants. See the inline comment for details.
> > >
> > > Signed-off-by: Waiman Long 
> > >
> > >  v1->v2:
> > >   - Add comments in changelog and code for the rationale of the change.
> > >
> > > ---
> > >  kernel/locking/qspinlock_paravirt.h | 50 --
> > > ---
> > >  1 file changed, 33 insertions(+), 17 deletions(-)
> > >
> > >
> > > @@ -323,8 +329,14 @@ static void pv_wait_node(struct mcs_spinlock *node,
> > > struct mcs_spinlock *prev)
> > >  * If pv_kick_node() changed us to vcpu_hashed, retain 
> > > that
> > >  * value so that pv_wait_head_or_lock() knows to not also
> > > try
> > >  * to hash this lock.
> > > +*
> > > +* The smp_store_mb() and control dependency above will
> > > ensure
> > > +* that state change won't happen before that.
> > > Synchronizing
> > > +* with pv_kick_node() wrt hashing by this waiter or by 
> > > the
> > > +* lock holder is done solely by the state variable. There
> > > is
> > > +* no other ordering requirement.
> > >  */
> > > -   cmpxchg(&pn->state, vcpu_halted, vcpu_running);
> > > +   cmpxchg_relaxed(&pn->state, vcpu_halted, vcpu_running);
> > >
> > > /*
> > >  * If the locked flag is still not set after wakeup, it is
> > > a
> > > @@ -360,9 +372,12 @@ static void pv_kick_node(struct qspinlock *lock,
> > > struct mcs_spinlock *node)
> > >  * pv_wait_node(). If OTOH this fails, the vCPU was running and
> > > will
> > >  * observe its next->locked value and advance itself.
> > >  *
> > > -* Matches with smp_store_mb() and cmpxchg() in pv_wait_node()
> > > +* Matches with smp_store_mb() and cmpxchg_relaxed() in
> > > pv_wait_node().
> > > +* A release barrier is used here to ensure that node->locked is
> > > +* always set before changing the state. See comment in
> > > pv_wait_node().
> > >  */
> > > -   if (cmpxchg(&pn->state, vcpu_halted, vcpu_hashed) != vcpu_halted)
> > > +   if (cmpxchg_release(&pn->state, vcpu_halted, vcpu_hashed)
> > > +   != vcpu_halted)
> > > return;
> > >
> > > hi, Waiman
> > We can't use _release here, a full barrier is needed.
> > 
> > There is pv_kick_node vs pv_wait_head_or_lock
> > 
> > [w] l->locked = _Q_SLOW_VAL  //reordered here
> > 
> > if (READ_ONCE(pn->state) == vcpu_hashed) //False.
> > 
> >lp = (struct qspinlock **)1;
> > 
> > [STORE] pn->state = vcpu_hashedlp = pv_hash(lock,
> > pn);
> > pv_hash()if
> > (xchg(&l->locked, _Q_SLOW_VAL) == 0) // fasle, not unhashed.
> > 
> 
> This analysis is correct, but..
> 

Hmm.. look at this again, I don't think this analysis is meaningful,
let's say the reordering didn't happen, we still got(similar to your
case):

if (READ_ONCE(pn->state) == 
vcpu_hashed) // false.
  lp = (struct qspinlock **)1;

cmpxchg(pn->state, vcpu_halted, vcpu_hashed);
  if(!lp) {
lp = pv_hash(lock, pn);
WRITE_ONCE(l->locked, _Q_SLOW_VAL);
pv_hash();
if (xchg(&l->locked, 
_Q_SLOW_VAL) == 0) // fasle, not unhashed.

, right?

Actually, I think this or your case could not happen because we have

cmpxchg(pn->state, vcpu_halted, vcpu_running);

in pv_wait_node(), which makes us either observe vcpu_hashed or set
pn->state to vcpu_running before pv_kick_node() trying to do the hash.

I may miss something subtle, but does switching back to cmpxchg() could
fix the RCU stall you observed?

Regards,
Boqun

> > Then the same lock has hashed twice but only unhashed once. So at last as
> > the hash table grows big, we hit RCU stall.
> > 
> > I hit RCU stall when I run netperf benchmark
> > 
> 
> how will a big hash table hit RCU stall? Do you have the call trace for
> your RCU stall?
> 
> Regards,
> Boqun
> 
> > thanks
> > xinhui
> > 
> > 
> > > --
> > > 1.8.3.1
> > >
> > >




signature.asc
Description: PGP signature

Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

[Al Viro]

On Tue, Feb 07, 2017 at 12:35:54PM +0100, Miklos Szeredi wrote:
> > Another thing: what guarantees that places in writepages-related paths
> > where we store a reference into req->ff won't hit a request with already
> > non-NULL ->ff?
> 
> Well, it is set before being sent (queued onto queued_writes or queued on the
> fuse device), but not when queued as secondary request onto an already 
> in-flight
> one.  It looks okay to me.

>  void fuse_sync_release(struct fuse_file *ff, int flags)
>  {
> - WARN_ON(atomic_read(&ff->count) > 1);
> + WARN_ON(atomic_read(&ff->count) != 1);
>   fuse_prepare_release(ff, flags, FUSE_RELEASE);
> - __set_bit(FR_FORCE, &ff->reserved_req->flags);
> - __clear_bit(FR_BACKGROUND, &ff->reserved_req->flags);
> - fuse_request_send(ff->fc, ff->reserved_req);
> - fuse_put_request(ff->fc, ff->reserved_req);
> - kfree(ff);
> + fuse_file_put(ff, true);

Umm...  At the very least, that deserves a comment re "iput(NULL) is a no-op
and since the refcount is 1 and everything's synchronous, we are fine with
not doing igrab/iput here".  There's enough mysteries in that code as it is...

Speaking of mysteries - how can ->private_data ever be NULL in
fuse_release_common()?  AFAICS, it's only called from ->release() instances
and those are only called after ->open() or ->atomic_open() on that struct file
has returned 0.  On the ->open() side, it means fuse_do_open() having returned
0; on ->atomic_open() one - fuse_create_open() having done the same.  Neither
is possible with ->private_data remaining NULL, and I don't see any places
that would modify it afterwards...

Another thing: am I right assuming that ff->nodeid will be the same
for all ff over given inode (== get_node_id(inode))?  What about ff->fh?
Is that a per-open thing, or will it be identical for all opens of the same
inode?

Re: [PATCH V3 3/4] arch/powerpc: Implement Optprobes

[Anju T Sudhakar]

Hi Michael,


Thank you so much for the review.

On Wednesday 01 February 2017 04:23 PM, Michael Ellerman wrote:

Anju T Sudhakar  writes:


Detour buffer contains instructions to create an in memory pt_regs.
After the execution of the pre-handler, a call is made for instruction 
emulation.
The NIP is determined in advanced through dummy instruction emulation and a 
branch
instruction is created to the NIP at the end of the trampoline.

That's good detail, but it's hard to follow for someone who isn't
familiar with with kprobes/optprobes etc. You don't even tell us what an
optprobe is :)

So can you provide a bit more background before diving into the specific
details.




Sure. I will provide sufficient details here.



Instruction slot for detour buffer is allocated from the reserved area.
For the time being, 64KB is reserved in memory for this purpose.

Instructions which can be emulated using analyse_instr() are suppliants

^
candidates ?





:-) yes 'candidates' will be more appropriate here.





diff --git a/Documentation/features/debug/optprobes/arch-support.txt 
b/Documentation/features/debug/optprobes/arch-support.txt
index b8999d8..45bc99d 100644
--- a/Documentation/features/debug/optprobes/arch-support.txt
+++ b/Documentation/features/debug/optprobes/arch-support.txt
@@ -27,7 +27,7 @@
  |   nios2: | TODO |
  |openrisc: | TODO |
  |  parisc: | TODO |
-| powerpc: | TODO |
+| powerpc: |  ok  |

We don't support them for modules yet, so maybe it's premature to flip
that?



ok.



diff --git a/arch/powerpc/kernel/optprobes.c b/arch/powerpc/kernel/optprobes.c
new file mode 100644
index 000..fb5e62d
--- /dev/null
+++ b/arch/powerpc/kernel/optprobes.c
@@ -0,0 +1,331 @@
+/*
+ * Code for Kernel probes Jump optimization.
+ *
+ * Copyright 2016, Anju T, IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define TMPL_CALL_HDLR_IDX \
+   (optprobe_template_call_handler - optprobe_template_entry)
+#define TMPL_EMULATE_IDX   \
+   (optprobe_template_call_emulate - optprobe_template_entry)
+#define TMPL_RET_IDX   \
+   (optprobe_template_ret - optprobe_template_entry)
+#define TMPL_OP_IDX\
+   (optprobe_template_op_address - optprobe_template_entry)
+#define TMPL_INSN_IDX  \
+   (optprobe_template_insn - optprobe_template_entry)
+#define TMPL_END_IDX   \
+   (optprobe_template_end - optprobe_template_entry)
+
+DEFINE_INSN_CACHE_OPS(ppc_optinsn);
+
+static bool insn_page_in_use;
+
+static void *__ppc_alloc_insn_page(void)
+{
+   if (insn_page_in_use)
+   return NULL;
+   insn_page_in_use = true;

This sets off my "no-locking-visible" detector. I assume there's some
locking somewhere else that makes this work?




Actually we don't need a lock here, since this function is invoked by 
__get_insn_slot() (in kernel/kprobes.c).

__get_insn_slot()  already  have lock on kprobe_insn_cache.





+   return &optinsn_slot;
+}
+
+static void __ppc_free_insn_page(void *page __maybe_unused)
+{
+   insn_page_in_use = false;
+}
+
+struct kprobe_insn_cache kprobe_ppc_optinsn_slots = {
+   .mutex = __MUTEX_INITIALIZER(kprobe_ppc_optinsn_slots.mutex),
+   .pages = LIST_HEAD_INIT(kprobe_ppc_optinsn_slots.pages),
+   /* insn_size initialized later */
+   .alloc = __ppc_alloc_insn_page,
+   .free = __ppc_free_insn_page,
+   .nr_garbage = 0,
+};
+
+/*
+ * Check if we can optimize this probe. Returns NIP post-emulation if this can
+ * be optimized and 0 otherwise.
+ */
+static unsigned long can_optimize(struct kprobe *p)
+{
+   struct pt_regs regs;
+   struct instruction_op op;
+   unsigned long nip = 0;
+
+   /*
+* kprobe placed for kretprobe during boot time
+* is not optimizing now.
+*
+* TODO: Optimize kprobe in kretprobe_trampoline
+*/
+   if (p->addr == (kprobe_opcode_t *)&kretprobe_trampoline)
+   return 0;
+
+   /*
+* We only support optimizing kernel addresses, but not
+* module addresses.

That probably warrants a TODO or FIXME.





sure.





+*/
+   if (!is_kernel_addr((unsigned long)p->addr))
+   return 0;
+
+   regs.nip = (unsigned long)p->addr;
+   regs.trap = 0x0;
+   regs.msr = MSR_KERNEL;

It may not matter in practice, but leaving most of regs uninitialised
seems a bit fishy. I'd prefer if we z

[-mm PATCH] mm: fix get_user_pages() vs device-dax pud mappings

[Dan Williams]

A new unit test for the device-dax 1GB enabling currently fails with
this warning before hanging the test thread:

 WARNING: CPU: 0 PID: 21 at lib/percpu-refcount.c:155 
percpu_ref_switch_to_atomic_rcu+0x1e3/0x1f0
 percpu ref (dax_pmem_percpu_release [dax_pmem]) <= 0 (0) after switching to 
atomic
 [..]
 CPU: 0 PID: 21 Comm: rcuos/1 Tainted: G   O
4.10.0-rc7-next-20170207+ #944
 [..]
 Call Trace:
  dump_stack+0x86/0xc3
  __warn+0xcb/0xf0
  warn_slowpath_fmt+0x5f/0x80
  ? rcu_nocb_kthread+0x27a/0x510
  ? dax_pmem_percpu_exit+0x50/0x50 [dax_pmem]
  percpu_ref_switch_to_atomic_rcu+0x1e3/0x1f0
  ? percpu_ref_exit+0x60/0x60
  rcu_nocb_kthread+0x339/0x510
  ? rcu_nocb_kthread+0x27a/0x510
  kthread+0x101/0x140

The get_user_pages() path needs to arrange for references to be taken
against the dev_pagemap instance backing the pud mapping. Refactor the
existing __gup_device_huge_pmd() to also account for the pud case.

Cc: Dave Jiang 
Cc: Matthew Wilcox 
Cc: Ross Zwisler 
Cc: Kirill A. Shutemov 
Cc: Nilesh Choudhury 
Signed-off-by: Dan Williams 
---
 arch/x86/mm/gup.c |   28 
 1 file changed, 24 insertions(+), 4 deletions(-)

diff --git a/arch/x86/mm/gup.c b/arch/x86/mm/gup.c
index 0d4fb3ebbbac..99c7805a9693 100644
--- a/arch/x86/mm/gup.c
+++ b/arch/x86/mm/gup.c
@@ -154,14 +154,12 @@ static inline void get_head_page_multiple(struct page 
*page, int nr)
SetPageReferenced(page);
 }
 
-static int __gup_device_huge_pmd(pmd_t pmd, unsigned long addr,
+static int __gup_device_huge(unsigned long pfn, unsigned long addr,
unsigned long end, struct page **pages, int *nr)
 {
int nr_start = *nr;
-   unsigned long pfn = pmd_pfn(pmd);
struct dev_pagemap *pgmap = NULL;
 
-   pfn += (addr & ~PMD_MASK) >> PAGE_SHIFT;
do {
struct page *page = pfn_to_page(pfn);
 
@@ -180,6 +178,24 @@ static int __gup_device_huge_pmd(pmd_t pmd, unsigned long 
addr,
return 1;
 }
 
+static int __gup_device_huge_pmd(pmd_t pmd, unsigned long addr,
+   unsigned long end, struct page **pages, int *nr)
+{
+   unsigned long fault_pfn;
+
+   fault_pfn = pmd_pfn(pmd) + ((addr & ~PMD_MASK) >> PAGE_SHIFT);
+   return __gup_device_huge(fault_pfn, addr, end, pages, nr);
+}
+
+static int __gup_device_huge_pud(pud_t pud, unsigned long addr,
+   unsigned long end, struct page **pages, int *nr)
+{
+   unsigned long fault_pfn;
+
+   fault_pfn = pud_pfn(pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
+   return __gup_device_huge(fault_pfn, addr, end, pages, nr);
+}
+
 static noinline int gup_huge_pmd(pmd_t pmd, unsigned long addr,
unsigned long end, int write, struct page **pages, int *nr)
 {
@@ -251,9 +267,13 @@ static noinline int gup_huge_pud(pud_t pud, unsigned long 
addr,
 
if (!pte_allows_gup(pud_val(pud), write))
return 0;
+
+   VM_BUG_ON(!pfn_valid(pud_pfn(pud)));
+   if (pud_devmap(pud))
+   return __gup_device_huge_pud(pud, addr, end, pages, nr);
+
/* hugepages are never "special" */
VM_BUG_ON(pud_flags(pud) & _PAGE_SPECIAL);
-   VM_BUG_ON(!pfn_valid(pud_pfn(pud)));
 
refs = 0;
head = pud_page(pud);

[PATCH] thermal: mt8173: minor mtk_thermal.c cleanups

[Dawei Chien]

Thermal driver should read TEMP_MSR3 if thermal bank with 4 sensors.
However, Currently thermal driver don't need read TEMP_MSR3 since
thermal controller only use 3 sensors for each thermal bank.

Signed-off-by: Dawei Chien 
---
 drivers/thermal/mtk_thermal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
index 34169c3..c124151 100644
--- a/drivers/thermal/mtk_thermal.c
+++ b/drivers/thermal/mtk_thermal.c
@@ -191,7 +191,7 @@ struct mtk_thermal {
 };
 
 const int mt8173_msr[MT8173_NUM_SENSORS_PER_ZONE] = {
-   TEMP_MSR0, TEMP_MSR1, TEMP_MSR2, TEMP_MSR2
+   TEMP_MSR0, TEMP_MSR1, TEMP_MSR2, TEMP_MSR3
 };
 
 const int mt8173_adcpnp[MT8173_NUM_SENSORS_PER_ZONE] = {
-- 
1.9.1

Re: [PATCH 2/2] spi: s3c64xx: fix potential division by zero

[Andi Shyti]

> > This patch fixes '1397922 Division or modulo by zero' from
> > scan.coverity.com
> 
> It is a false positive.

Yes... sorry for these two spam/patches... they are just fast
after holiday "fixes"... please ignore them.

Andi

[PATCH v2] tools lib traceevent: Robustify do_generate_dynamic_list_file

[David Carrillo-Cisneros]

v2: Accept "W" and "w" symbol options.

The dynamic-list-file used to export dynamic symbols introduced in

commit e3d09ec8126f ("tools lib traceevent: Export dynamic symbols
used by traceevent plugins")

is generated without any sort of error checking.

I experienced problems due to an old version of nm (v 0.158) that outputs
in a format distinct from the assumed by the script.

Robustify the built of dynamic symbol list  by enforcing that the second
column of $(NM) -u  is either "U" (Undefined), "W" or "w" (undefined
weak), which are the possible outputs from non-ancient $(NM) versions.
Print an error if format is unexpected.

Signed-off-by: David Carrillo-Cisneros 
---
 tools/lib/traceevent/Makefile | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/tools/lib/traceevent/Makefile b/tools/lib/traceevent/Makefile
index 2616c66e10c1..a7046ec01a5b 100644
--- a/tools/lib/traceevent/Makefile
+++ b/tools/lib/traceevent/Makefile
@@ -257,10 +257,16 @@ define do_install_plugins
 endef
 
 define do_generate_dynamic_list_file
-   (echo '{';  \
-   $(NM) -u -D $1 | awk 'NF>1 {print "\t"$$2";"}' | sort -u;   \
-   echo '};';  \
-   ) > $2
+   symbol_type=`$(NM) -u -D $1 | awk 'NF>1 {print $$1}' | \
+   xargs echo "U W w" | tr ' ' '\n' | sort -u | xargs echo`;\
+   if [ "$$symbol_type" == "U W w" ];then  \
+   (echo '{';  \
+   $(NM) -u -D $1 | awk 'NF>1 {print "\t"$$2";"}' | sort -u;\
+   echo '};';  \
+   ) > $2; \
+   else\
+   (echo Either missing one of [$1] or bad version of $(NM)) 1>&2;\
+   fi
 endef
 
 install_lib: all_cmd install_plugins
-- 
2.11.0.483.g087da7b7c-goog

[PATCH] mm balloon: umount balloon_mnt when remove vb device

[Yisheng Xie]

With CONFIG_BALLOON_COMPACTION=y, it will mount balloon_mnt for
balloon page migration when probe a virtio_balloon device, however
do not unmount it when remove the device, fix it.

Fixes: b1123ea6d3b3 ("mm: balloon: use general non-lru movable page feature")
Signed-off-by: Yisheng Xie 
---
 drivers/virtio/virtio_balloon.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 181793f..9d2738e 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -615,8 +615,12 @@ static void virtballoon_remove(struct virtio_device *vdev)
cancel_work_sync(&vb->update_balloon_stats_work);
 
remove_common(vb);
+#ifdef CONFIG_BALLOON_COMPACTION
if (vb->vb_dev_info.inode)
iput(vb->vb_dev_info.inode);
+
+   kern_unmount(balloon_mnt);
+#endif
kfree(vb);
 }
 
-- 
1.7.12.4

Re: [PATCH v2] drm/mxsfb: fix pixel clock polarity

[Stefan Agner]

Dave, Marek,

On 2016-12-14 13:25, Marek Vasut wrote:
> On 12/14/2016 09:48 PM, Stefan Agner wrote:
>> The DRM subsystem specifies the pixel clock polarity from a
>> controllers perspective: DRM_BUS_FLAG_PIXDATA_NEGEDGE means
>> the controller drives the data on pixel clocks falling edge.
>> That is the controllers DOTCLK_POL=0 (Default is data launched
>> at negative edge).
>>
>> Also change the data enable logic to be high active by default
>> and only change if explicitly requested via bus_flags. With
>> that defaults are:
>> - Data enable: high active
>> - Pixel clock polarity: controller drives data on negative edge
>>
>> Signed-off-by: Stefan Agner 
> 
> Acked-by: Marek Vasut 
> 

This seems not have made into drm-next yet. Not sure what the plan is
here, who will pick this up? There is also another fix on ML for the
same driver ("drm: mxsfb: Fix crash when provided invalid DT bindings").

--
Stefan

>> ---
>> Changes since v1:
>> - Improved comments/fixed typo
>>
>>  drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 11 +--
>>  1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c 
>> b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
>> index 3770dd2..5556e53 100644
>> --- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
>> +++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
>> @@ -195,9 +195,16 @@ static void mxsfb_crtc_mode_set_nofb(struct 
>> mxsfb_drm_private *mxsfb)
>>  vdctrl0 |= VDCTRL0_HSYNC_ACT_HIGH;
>>  if (m->flags & DRM_MODE_FLAG_PVSYNC)
>>  vdctrl0 |= VDCTRL0_VSYNC_ACT_HIGH;
>> -if (bus_flags & DRM_BUS_FLAG_DE_HIGH)
>> +/* Make sure Data Enable is high active by default */
>> +if (!(bus_flags & DRM_BUS_FLAG_DE_LOW))
>>  vdctrl0 |= VDCTRL0_ENABLE_ACT_HIGH;
>> -if (bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE)
>> +/*
>> + * DRM_BUS_FLAG_PIXDATA_ defines are controller centric,
>> + * controllers VDCTRL0_DOTCLK is display centric.
>> + * Drive on positive edge   -> display samples on falling edge
>> + * DRM_BUS_FLAG_PIXDATA_POSEDGE -> VDCTRL0_DOTCLK_ACT_FALLING
>> + */
>> +if (bus_flags & DRM_BUS_FLAG_PIXDATA_POSEDGE)
>>  vdctrl0 |= VDCTRL0_DOTCLK_ACT_FALLING;
>>
>>  writel(vdctrl0, mxsfb->base + LCDC_VDCTRL0);
>>

linux-next: build failure after merge of the gpio tree

[Stephen Rothwell]

Hi Linus,

After merging the gpio tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

drivers/tty/serial/st-asc.c: In function 'asc_set_termios':
drivers/tty/serial/st-asc.c:578:12: error: implicit declaration of function 
'devm_get_gpiod_from_child' [-Werror=implicit-function-declaration]
gpiod = devm_get_gpiod_from_child(port->dev, "rts",
^
drivers/tty/serial/st-asc.c:578:10: warning: assignment makes pointer from 
integer without a cast [-Wint-conversion]
gpiod = devm_get_gpiod_from_child(port->dev, "rts",
  ^

Caused by commits

  a264d10ff45c ("gpiolib: Convert fwnode_get_named_gpiod() to configure GPIO")
  b2987d7438e0 ("gpio: Pass GPIO label down to gpiod_request")
  4b0947974e59 ("gpio: Rename devm_get_gpiod_from_child()")

interacting with commit

  d7356256488c ("serial: st-asc: (De)Register GPIOD and swap Pinctrl profiles")

from the tty tree.

I applied the following merge fix patch (I guessed about the new arguments):

From: Stephen Rothwell 
Date: Wed, 8 Feb 2017 15:50:22 +1100
Subject: [PATCH] serial: st-asc: merge fix for devm_get_gpiod_from_child rename

Signed-off-by: Stephen Rothwell 
---
 drivers/tty/serial/st-asc.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/st-asc.c b/drivers/tty/serial/st-asc.c
index bcf1d33e6ffe..c02e6b089364 100644
--- a/drivers/tty/serial/st-asc.c
+++ b/drivers/tty/serial/st-asc.c
@@ -575,8 +575,11 @@ static void asc_set_termios(struct uart_port *port, struct 
ktermios *termios,
pinctrl_select_state(ascport->pinctrl,
 ascport->states[NO_HW_FLOWCTRL]);
 
-   gpiod = devm_get_gpiod_from_child(port->dev, "rts",
- &np->fwnode);
+   gpiod = devm_fwnode_get_gpiod_from_child(port->dev,
+"rts",
+&np->fwnode,
+GPIOD_IN,
+np->name);
if (!IS_ERR(gpiod)) {
gpiod_direction_output(gpiod, 0);
ascport->rts = gpiod;
-- 
2.10.2

-- 
Cheers,
Stephen Rothwell

Re: [PATCH v9 2/3] MAINTAINERS: add zx2967 thermal drivers to ARM ZTE architecture

[Shawn Guo]

Hi Eduardo,

On Tue, Feb 07, 2017 at 08:45:39PM -0800, Eduardo Valentin wrote:
> 
> On Tue, Feb 07, 2017 at 08:56:40AM +0800, Baoyou Xie wrote:
> > Add the zx2967 thermal drivers as maintained by ARM ZTE
> > architecture maintainers, as they're parts of the core IP.
> 
> What kernel version is this based off? I could not apply this one
> cleanly.

I think you can skip this one.  We will update MAINTAINERS separately
through arm-soc tree, after the patch lands on mainline.

Shawn

Re: v4.9, 4.4-final: 28 bioset threads on small notebook, 36 threads on cellphone

[Kent Overstreet]

On Tue, Feb 07, 2017 at 09:39:11PM +0100, Pavel Machek wrote:
> On Mon 2017-02-06 17:49:06, Kent Overstreet wrote:
> > On Mon, Feb 06, 2017 at 04:47:24PM -0900, Kent Overstreet wrote:
> > > On Mon, Feb 06, 2017 at 01:53:09PM +0100, Pavel Machek wrote:
> > > > Still there on v4.9, 36 threads on nokia n900 cellphone.
> > > > 
> > > > So.. what needs to be done there?
> > 
> > > But, I just got an idea for how to handle this that might be halfway 
> > > sane, maybe
> > > I'll try and come up with a patch...
> > 
> > Ok, here's such a patch, only lightly tested:
> 
> I guess it would be nice for me to test it... but what it is against?
> I tried after v4.10-rc5 and linux-next, but got rejects in both cases.

Sorry, I forgot I had a few other patches in my branch that touch
mempool/biosets code.

Also, after thinking about it more and looking at the relevant code, I'm pretty
sure we don't need rescuer threads for block devices that just split bios - i.e.
most of them, so I changed my patch to do that.

Tested it by ripping out the current->bio_list checks/workarounds from the
bcache code, appears to work:

-- >8 --
Subject: [PATCH] block: Make rescuer threads per request_queue, not per bioset

Also, trigger rescuing whenever with bios on current->bio_list, instead
of only when we block in bio_alloc_bioset(). This is more correct, and
should result in fewer rescuer threads.

XXX: The current->bio_list plugging needs to be unified with the
blk_plug mechanism.

Signed-off-by: Kent Overstreet 
---
 block/bio.c| 105 +++--
 block/blk-core.c   |  69 +++
 block/blk-mq.c |   3 +-
 block/blk-sysfs.c  |   2 +
 drivers/block/brd.c|   2 +-
 drivers/block/drbd/drbd_main.c |   2 +-
 drivers/block/null_blk.c   |   3 +-
 drivers/block/pktcdvd.c|   2 +-
 drivers/block/ps3vram.c|   2 +-
 drivers/block/rsxx/dev.c   |   2 +-
 drivers/block/umem.c   |   2 +-
 drivers/block/zram/zram_drv.c  |   2 +-
 drivers/lightnvm/gennvm.c  |   2 +-
 drivers/md/bcache/super.c  |   2 +-
 drivers/md/dm.c|   2 +-
 drivers/md/md.c|   2 +-
 drivers/nvdimm/blk.c   |   2 +-
 drivers/nvdimm/btt.c   |   2 +-
 drivers/nvdimm/pmem.c  |   3 +-
 drivers/s390/block/dcssblk.c   |   2 +-
 drivers/s390/block/xpram.c |   2 +-
 include/linux/bio.h|  16 +++
 include/linux/blkdev.h |  16 ++-
 include/linux/sched.h  |   2 +-
 kernel/sched/core.c|   6 +++
 25 files changed, 117 insertions(+), 138 deletions(-)

diff --git a/block/bio.c b/block/bio.c
index 2b375020fc..9b89be1719 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -340,54 +340,6 @@ void bio_chain(struct bio *bio, struct bio *parent)
 }
 EXPORT_SYMBOL(bio_chain);
 
-static void bio_alloc_rescue(struct work_struct *work)
-{
-   struct bio_set *bs = container_of(work, struct bio_set, rescue_work);
-   struct bio *bio;
-
-   while (1) {
-   spin_lock(&bs->rescue_lock);
-   bio = bio_list_pop(&bs->rescue_list);
-   spin_unlock(&bs->rescue_lock);
-
-   if (!bio)
-   break;
-
-   generic_make_request(bio);
-   }
-}
-
-static void punt_bios_to_rescuer(struct bio_set *bs)
-{
-   struct bio_list punt, nopunt;
-   struct bio *bio;
-
-   /*
-* In order to guarantee forward progress we must punt only bios that
-* were allocated from this bio_set; otherwise, if there was a bio on
-* there for a stacking driver higher up in the stack, processing it
-* could require allocating bios from this bio_set, and doing that from
-* our own rescuer would be bad.
-*
-* Since bio lists are singly linked, pop them all instead of trying to
-* remove from the middle of the list:
-*/
-
-   bio_list_init(&punt);
-   bio_list_init(&nopunt);
-
-   while ((bio = bio_list_pop(current->bio_list)))
-   bio_list_add(bio->bi_pool == bs ? &punt : &nopunt, bio);
-
-   *current->bio_list = nopunt;
-
-   spin_lock(&bs->rescue_lock);
-   bio_list_merge(&bs->rescue_list, &punt);
-   spin_unlock(&bs->rescue_lock);
-
-   queue_work(bs->rescue_workqueue, &bs->rescue_work);
-}
-
 /**
  * bio_alloc_bioset - allocate a bio for I/O
  * @gfp_mask:   the GFP_ mask given to the slab allocator
@@ -425,17 +377,20 @@ static void punt_bios_to_rescuer(struct bio_set *bs)
  */
 struct bio *bio_alloc_bioset(gfp_t gfp_mask, int nr_iovecs, struct bio_set *bs)
 {
-   gfp_t saved_gfp = gfp_mask;
unsigned front_pad;
unsigned inline_vecs;
struct bio_vec *bvl = NULL;
struct bio *bio;
void *p;
 
-   if (!bs) {
-   if (nr_iovecs > UIO_MAXIOV)
-   return NULL;
+   WARN(current->bio_list &&
+!curr

[PATCH] drivers: usb-misc: sisusbvga: remove dead code

[Gustavo A. R. Silva]

The condition modex % 16 cannot be true when modex value is equal to 640
The condition du & 0xff cannot be true when du value is equal to 0x1400

Addresses-Coverity-Id: 101163
Addresses-Coverity-Id: 744373
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/usb/misc/sisusbvga/sisusb.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/usb/misc/sisusbvga/sisusb.c 
b/drivers/usb/misc/sisusbvga/sisusb.c
index 05bd39d..440d7fe 100644
--- a/drivers/usb/misc/sisusbvga/sisusb.c
+++ b/drivers/usb/misc/sisusbvga/sisusb.c
@@ -1831,16 +1831,10 @@ static int sisusb_set_default_mode(struct 
sisusb_usb_data *sisusb,
SETIREGANDOR(SISCR, 0x09, 0x5f, ((crtcdata[16] & 0x01) << 5));
SETIREG(SISCR, 0x14, 0x4f);
du = (modex / 16) * (bpp * 2);  /* offset/pitch */
-   if (modex % 16)
-   du += bpp;
-
SETIREGANDOR(SISSR, 0x0e, 0xf0, ((du >> 8) & 0x0f));
SETIREG(SISCR, 0x13, (du & 0xff));
du <<= 5;
tmp8 = du >> 8;
-   if (du & 0xff)
-   tmp8++;
-
SETIREG(SISSR, 0x10, tmp8);
SETIREG(SISSR, 0x31, 0x00); /* VCLK */
SETIREG(SISSR, 0x2b, 0x1b);
-- 
2.5.0

Re: [PATCH v9 2/3] MAINTAINERS: add zx2967 thermal drivers to ARM ZTE architecture

[Eduardo Valentin]

On Tue, Feb 07, 2017 at 08:56:40AM +0800, Baoyou Xie wrote:
> Add the zx2967 thermal drivers as maintained by ARM ZTE
> architecture maintainers, as they're parts of the core IP.

What kernel version is this based off? I could not apply this one
cleanly.

> 

Re: [PATCH] time: Remove CONFIG_TIMER_STATS

[kbuild test robot]

Hi Kees,

[auto build test WARNING on tip/timers/core]
[also build test WARNING on v4.10-rc7 next-20170207]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Kees-Cook/time-Remove-CONFIG_TIMER_STATS/20170208-080916
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   make[3]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
rule.
   include/linux/init.h:1: warning: no structured comments found
>> include/linux/hrtimer.h:108: warning: Excess struct/union/enum/typedef 
>> member 'start_pid' description in 'hrtimer'
>> include/linux/hrtimer.h:108: warning: Excess struct/union/enum/typedef 
>> member 'start_site' description in 'hrtimer'
>> include/linux/hrtimer.h:108: warning: Excess struct/union/enum/typedef 
>> member 'start_comm' description in 'hrtimer'
   include/linux/kthread.h:26: warning: Excess function parameter '...' 
description in 'kthread_create'
   kernel/sys.c:1: warning: no structured comments found
   drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found
   include/drm/drm_drv.h:409: warning: No description found for parameter 'load'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'firstopen'
   include/drm/drm_drv.h:409: warning: No description found for parameter 'open'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'preclose'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'postclose'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'lastclose'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'unload'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'dma_ioctl'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'dma_quiescent'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'context_dtor'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'set_busid'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'irq_handler'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'irq_preinstall'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'irq_postinstall'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'irq_uninstall'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'debugfs_init'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'debugfs_cleanup'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'gem_open_object'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'gem_close_object'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'prime_handle_to_fd'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'prime_fd_to_handle'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'gem_prime_export'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'gem_prime_import'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'gem_prime_pin'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'gem_prime_unpin'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'gem_prime_res_obj'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'gem_prime_get_sg_table'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'gem_prime_import_sg_table'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'gem_prime_vmap'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'gem_prime_vunmap'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'gem_prime_mmap'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'vgaarb_irq'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'gem_vm_ops'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'major'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'minor'
   include/drm/drm_drv.h:409: warning: No description found for parameter 
'patchlevel'
   include/drm/drm_drv.h:409: warning: No description found for parameter 'name'
   include/drm

Re: [PATCH 2/2] tty: pl011: Work around QDF2400 E44 for earlycon

[Shanker Donthineni]

Hi Cov,

The same PL011 driver will be used in virtutal machine, make sure your 
changes have no side effects in VM.




On 02/07/2017 10:07 PM, Timur Tabi wrote:

Christopher Covington wrote:

The previous change worked around QDF2432v1 and QDF2400v1 SoC erratum 44
for the full-fledged console, when UART AMBA Port (UAP) data is 
available.
Additionally provide a workaround the earlycon case, again checking 
TXFE ==

0 instead of BUSY == 1. As earlycon is operating before UAP data is
available, the implementation is different than in the preceding patch.

Signed-off-by: Christopher Covington 
---
  drivers/tty/serial/amba-pl011.c | 28 +++-
  1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/amba-pl011.c 
b/drivers/tty/serial/amba-pl011.c

index 41e51901d6ef..f25e7c994f8e 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -2411,6 +2411,29 @@ static bool qdf2400_e44(void) {
  cpu_var_model == MIDR_QCOM_FALKOR_V1);
  }
  +#ifdef CONFIG_QCOM_QDF2400_ERRATUM_44
+static void qdf2400_e44_putc(struct uart_port *port, int c)
+{
+while (readl(port->membase + UART01x_FR) & UART01x_FR_TXFF)
+cpu_relax();
+if (port->iotype == UPIO_MEM32)
+writel(c, port->membase + UART01x_DR);
+else
+writeb(c, port->membase + UART01x_DR);
I believe 32-bit writes are safe on QDF2400v1, so I think you 
technically don't need the UPIO_MEM32 check.  Just always call writel.

+while (!(readl(port->membase + UART01x_FR) & UART011_FR_TXFE))
+cpu_relax();
+}
+
+static void qdf2400_e44_early_write(struct console *con, const char 
*s, unsigned n)

+{
+struct earlycon_device *dev = con->data;
+
+uart_console_write(&dev->port, s, n, qdf2400_e44_putc);
+}
+#else
+#define qdf2400_e44_early_write pl011_early_write
+#endif
Same with patch 1/2.  If you change qdf2400_e44(), you don't need the 
#else block.

+
  static void pl011_putc(struct uart_port *port, int c)
  {
  while (readl(port->membase + UART01x_FR) & UART01x_FR_TXFF)
@@ -2436,7 +2459,10 @@ static int __init 
pl011_early_console_setup(struct earlycon_device *device,

  if (!device->port.membase)
  return -ENODEV;
  -device->con->write = pl011_early_write;
+if (qdf2400_e44())
+device->con->write = qdf2400_e44_early_write;
+else
+device->con->write = pl011_early_write;
  return 0;
  }
  OF_EARLYCON_DECLARE(pl011, "arm,pl011", pl011_early_console_setup);





--
Shanker Donthineni
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.

Re: [PATCH] time: Remove CONFIG_TIMER_STATS

[John Stultz]

On Tue, Feb 7, 2017 at 3:40 PM, Kees Cook  wrote:
> Currently CONFIG_TIMER_STATS exposes process information across namespaces:
>
> kernel/time/timer_list.c print_timer():
>
> SEQ_printf(m, ", %s/%d", tmp, timer->start_pid);
>
> /proc/timer_list:
>
>  #11: <>, hrtimer_wakeup, S:01, do_nanosleep, cron/2570
>
> Given that the tracer can give the same information, this patch entirely
> removes CONFIG_TIMER_STATS.
>
> Suggested-by: Thomas Gleixner 
> Signed-off-by: Kees Cook 

I don't have an issue with this, but I worry this would break some
tooling out there. Should it be marked as deprecated first?

Or maybe just pulling the band-aid off is the best way?

thanks
-john

Re: [PATCH v2] PCI: pciehp: Don't enable PME on runtime suspend

[Lukas Wunner]

On Tue, Feb 07, 2017 at 05:04:45PM +0100, Rafael J. Wysocki wrote:
> On Tuesday, February 07, 2017 07:21:01 AM Lukas Wunner wrote:
> > On Mon, Feb 06, 2017 at 04:15:02PM -0600, Bjorn Helgaas wrote:
> > > On Mon, Feb 06, 2017 at 10:20:41PM +0100, Lukas Wunner wrote:
> > > > On Mon, Feb 06, 2017 at 11:54:05AM -0600, Bjorn Helgaas wrote:
> > > > > What is the hotplug event that causes generation of this wakeup event?
> > > > 
> > > > If you had read all e-mails in this thread or looked at the bugzilla
> > > > entry I've created, you wouldn't have to ask this question.
> > > 
> > > I'm sorry, I don't necessarily have time to sort through all the
> > > emails.  My idea is that the changelog should be a self-contained
> > > justification for the patch.  The bugzilla is for supporting details
> > > and future archaeologists.
> > > 
> > > > I think it's disappointing that you're asking me to jump through
> > > > various hoops like creating a bugzilla entry, as well as threatening
> > > > to revert my patch, but are unwilling to even look at the bugzilla
> > > > entry or read the entire thread.  It is equally disappointing that
> > > > the reporter of the regression was unwilling or unable to provide
> > > > dmesg output for both machines so that we've got no real idea what
> > > > we're dealing with.
> > > 
> > > I beg your pardon?  I don't think it's fair to malign Yinghai.  He's
> > > tested at least two machines and at least two patches, and it's only
> > > been two working days since he reported the problem.
> > 
> > I think the commercialization of Linux kernel development has put this
> > open source project in a sorry state if an unpaid volunteer is told off
> > because he expresses disappointment that a paid contributor is asking
> > him to debug an issue on secret hardware using secret patches and not
> > providing secret dmesg output.
> 
> That's not like a lot has changed in that respect for the last 10 years and
> I was in your spot at that time.

Thank you Rafael, means a lot.


> The bottom line, in any case, is that the current code causes problems to
> happen somewhere and as a rule we don't release code that is known to
> cause problems to happen to anyone.  This means something needs to be done
> about that and the choice at this point is pretty much between reverting and
> quirking the affected system(s).

Quirking is not an option in this case because the PCI device IDs of the
affected hotplug ports as well as DMI data are unknown.  Yinghai Lu is
refusing to publish that, for both affected systems.

To be honest I only care about runtime suspending *Thunderbolt* hotplug
ports.  I enabled it for *all* hotplug ports in 68db9bc81436 because it
seemed like the right thing to do.  However given the murkiness of the
spec and the odd quirks Yinghai Lu reported it's probably not worth the
effort.  One must bear in mind that we've only heard of systems with
2015+ BIOSes so far.  More problem reports may pile up once we push the
BIOS limit further back.

I have submitted a patch to recognize Thunderbolt ports, so what I have
in mind is to resubmit 68db9bc81436 with an additional is_thunderbolt
condition in pci_bridge_d3_possible().  The number of Thunderbolt chips
is small and I know them fairly well, so it's easy for me to judge the
potential for regressions and deal with them.

Alternatively Bjorn could apply the patch to recognize Thunderbolt
devices now and then I can submit a one-line fix which adds the
is_thunderbolt condition to pci_bridge_d3_possible().  This would
obviate the need to revert 68db9bc81436.


> You seem to be disappointed that Yinghai has reported the problem at all,
> given that the hardware is unreleased and so on, but problem reports,
> even for systems like that, are what allows us to create code that works
> for everybody, so we (the maintainers) appreciate them very much.

No problem with reporting regressions, but with denying information
required to provide a fix.  I had asked for full dmesg output for
both machines so that the PCI device IDs and DMI data are available,
but Yinghai Lu continues to withhold that.  I am thus denied the means
to provide a fix and am forced to watch reversion of 68db9bc81436
without being able to respond.

Thanks,

Lukas

Re: [PATCH v2] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs

[Boqun Feng]

On Wed, Feb 08, 2017 at 11:39:10AM +0800, Xinhui Pan wrote:
> 2016-12-26 4:26 GMT+08:00 Waiman Long :
> 
> > A number of cmpxchg calls in qspinlock_paravirt.h were replaced by more
> > relaxed versions to improve performance on architectures that use LL/SC.
> >
> > All the locking related cmpxchg's are replaced with the _acquire
> > variants:
> >  - pv_queued_spin_steal_lock()
> >  - trylock_clear_pending()
> >
> > The cmpxchg's related to hashing are replaced by either by the _release
> > or the _relaxed variants. See the inline comment for details.
> >
> > Signed-off-by: Waiman Long 
> >
> >  v1->v2:
> >   - Add comments in changelog and code for the rationale of the change.
> >
> > ---
> >  kernel/locking/qspinlock_paravirt.h | 50 --
> > ---
> >  1 file changed, 33 insertions(+), 17 deletions(-)
> >
> >
> > @@ -323,8 +329,14 @@ static void pv_wait_node(struct mcs_spinlock *node,
> > struct mcs_spinlock *prev)
> >  * If pv_kick_node() changed us to vcpu_hashed, retain that
> >  * value so that pv_wait_head_or_lock() knows to not also
> > try
> >  * to hash this lock.
> > +*
> > +* The smp_store_mb() and control dependency above will
> > ensure
> > +* that state change won't happen before that.
> > Synchronizing
> > +* with pv_kick_node() wrt hashing by this waiter or by the
> > +* lock holder is done solely by the state variable. There
> > is
> > +* no other ordering requirement.
> >  */
> > -   cmpxchg(&pn->state, vcpu_halted, vcpu_running);
> > +   cmpxchg_relaxed(&pn->state, vcpu_halted, vcpu_running);
> >
> > /*
> >  * If the locked flag is still not set after wakeup, it is
> > a
> > @@ -360,9 +372,12 @@ static void pv_kick_node(struct qspinlock *lock,
> > struct mcs_spinlock *node)
> >  * pv_wait_node(). If OTOH this fails, the vCPU was running and
> > will
> >  * observe its next->locked value and advance itself.
> >  *
> > -* Matches with smp_store_mb() and cmpxchg() in pv_wait_node()
> > +* Matches with smp_store_mb() and cmpxchg_relaxed() in
> > pv_wait_node().
> > +* A release barrier is used here to ensure that node->locked is
> > +* always set before changing the state. See comment in
> > pv_wait_node().
> >  */
> > -   if (cmpxchg(&pn->state, vcpu_halted, vcpu_hashed) != vcpu_halted)
> > +   if (cmpxchg_release(&pn->state, vcpu_halted, vcpu_hashed)
> > +   != vcpu_halted)
> > return;
> >
> > hi, Waiman
> We can't use _release here, a full barrier is needed.
> 
> There is pv_kick_node vs pv_wait_head_or_lock
> 
> [w] l->locked = _Q_SLOW_VAL  //reordered here
> 
> if (READ_ONCE(pn->state) == vcpu_hashed) //False.
> 
>lp = (struct qspinlock **)1;
> 
> [STORE] pn->state = vcpu_hashedlp = pv_hash(lock,
> pn);
> pv_hash()if
> (xchg(&l->locked, _Q_SLOW_VAL) == 0) // fasle, not unhashed.
> 

This analysis is correct, but..

> Then the same lock has hashed twice but only unhashed once. So at last as
> the hash table grows big, we hit RCU stall.
> 
> I hit RCU stall when I run netperf benchmark
> 

how will a big hash table hit RCU stall? Do you have the call trace for
your RCU stall?

Regards,
Boqun

> thanks
> xinhui
> 
> 
> > --
> > 1.8.3.1
> >
> >


signature.asc
Description: PGP signature

Re: [PATCH 2/2] tty: pl011: Work around QDF2400 E44 for earlycon

[Timur Tabi]

Christopher Covington wrote:

The previous change worked around QDF2432v1 and QDF2400v1 SoC erratum 44
for the full-fledged console, when UART AMBA Port (UAP) data is available.
Additionally provide a workaround the earlycon case, again checking TXFE ==
0 instead of BUSY == 1. As earlycon is operating before UAP data is
available, the implementation is different than in the preceding patch.

Signed-off-by: Christopher Covington 
---
  drivers/tty/serial/amba-pl011.c | 28 +++-
  1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 41e51901d6ef..f25e7c994f8e 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -2411,6 +2411,29 @@ static bool qdf2400_e44(void) {
cpu_var_model == MIDR_QCOM_FALKOR_V1);
  }
  
+#ifdef CONFIG_QCOM_QDF2400_ERRATUM_44

+static void qdf2400_e44_putc(struct uart_port *port, int c)
+{
+   while (readl(port->membase + UART01x_FR) & UART01x_FR_TXFF)
+   cpu_relax();
+   if (port->iotype == UPIO_MEM32)
+   writel(c, port->membase + UART01x_DR);
+   else
+   writeb(c, port->membase + UART01x_DR);
I believe 32-bit writes are safe on QDF2400v1, so I think you technically don't 
need the UPIO_MEM32 check.  Just always call writel.

+   while (!(readl(port->membase + UART01x_FR) & UART011_FR_TXFE))
+   cpu_relax();
+}
+
+static void qdf2400_e44_early_write(struct console *con, const char *s, 
unsigned n)
+{
+   struct earlycon_device *dev = con->data;
+
+   uart_console_write(&dev->port, s, n, qdf2400_e44_putc);
+}
+#else
+#define qdf2400_e44_early_write pl011_early_write
+#endif

Same with patch 1/2.  If you change qdf2400_e44(), you don't need the #else 
block.

+
  static void pl011_putc(struct uart_port *port, int c)
  {
while (readl(port->membase + UART01x_FR) & UART01x_FR_TXFF)
@@ -2436,7 +2459,10 @@ static int __init pl011_early_console_setup(struct 
earlycon_device *device,
if (!device->port.membase)
return -ENODEV;
  
-	device->con->write = pl011_early_write;

+   if (qdf2400_e44())
+   device->con->write = qdf2400_e44_early_write;
+   else
+   device->con->write = pl011_early_write;
return 0;
  }
  OF_EARLYCON_DECLARE(pl011, "arm,pl011", pl011_early_console_setup);



--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.

Re: [PATCH 1/2] tty: pl011: Work around QDF2400 E44 stuck BUSY bit

[Timur Tabi]

Christopher Covington wrote:

The Qualcomm Datacenter Technologies QDF2400 family of SoCs contains a
custom (non-PrimeCell) implementation of the SBSA UART. Occasionally the
BUSY bit in the Flag Register gets stuck as 1, erratum 44 for both 2432v1
and 2400v1 SoCs. Checking that the Transmit FIFO Empty (TXFE) bit is 0,
instead of checking that the BUSY bit is 1, works around the issue. To
facilitate this substitution when UART AMBA Port (UAP) data is available,
introduce vendor-specific inversion of Feature Register bits. To keep the
change small, this patch only works around the full console case, where UAP
data is available, and does not handle the erratum for earlycon, as the UAP
data is not available then.

Signed-off-by: Christopher Covington 
Acked-by: Russell King 
---
Changes between the previous RFC [1] and this PATCH:
* don't use arch/arm64/kernel/cpu_errata.c at Will's request
* separate out earlycon case to separate patch
* rework earlycon case to not depend on UAP as suggested by Timur

Because they need a newly-defined MIDR values, the patches are currently
based on:
https://git.kernel.org/cgit/linux/kernel/git/arm64/linux.git/log/?h=for-next/core

I'm not confident that I know the best route for these two patches. Should
I request Catalin and Will to take them via arm64 as the essential MIDR
additions are their purview?

Thanks Russell for the ack. Compared to the RFC, I've made minor changes to
what is now patch 1/2 and am making an educated guess that the ack sticks
(but if not please let me know). Patch 2/2 is significantly revised from
the RFC so I've not included the ack on it.

1. https://patchwork.codeaurora.org/patch/163281/
---
 Documentation/arm64/silicon-errata.txt |  2 ++
 arch/arm64/include/asm/cputype.h   |  2 ++
 drivers/tty/serial/Kconfig | 12 ++
 drivers/tty/serial/amba-pl011.c| 40 +++---
 4 files changed, 53 insertions(+), 3 deletions(-)

diff --git a/Documentation/arm64/silicon-errata.txt 
b/Documentation/arm64/silicon-errata.txt
index 50da8391e9dd..0993ebb3e86b 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -65,3 +65,5 @@ stable kernels.
 | Freescale/NXP  | LS2080A/LS1043A | A-008585| FSL_ERRATUM_A008585 
|
 | Qualcomm Tech. | Falkor v1   | E1003   | 
QCOM_FALKOR_ERRATUM_1003|
 | Qualcomm Tech. | Falkor v1   | E1009   | 
QCOM_FALKOR_ERRATUM_1009|
+| Qualcomm Tech. | QDF2432v1 UART  | SoC E44 | QCOM_QDF2400_ERRATUM_44 
|
+| Qualcomm Tech. | QDF2400v1 UART  | SoC E44 | QCOM_QDF2400_ERRATUM_44 
|
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index fc502713ab37..cb399c7fe6ec 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -88,12 +88,14 @@

 #define BRCM_CPU_PART_VULCAN   0x516

+#define QCOM_CPU_PART_KRYO_V1  0x281
 #define QCOM_CPU_PART_FALKOR_V10x800

 #define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A53)
 #define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A57)
 #define MIDR_THUNDERX  MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, 
CAVIUM_CPU_PART_THUNDERX)
 #define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, 
CAVIUM_CPU_PART_THUNDERX_81XX)
+#define MIDR_QCOM_KRYO_V1 MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, 
QCOM_CPU_PART_KRYO_V1)
 #define MIDR_QCOM_FALKOR_V1 MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, 
QCOM_CPU_PART_FALKOR_V1)

 #ifndef __ASSEMBLY__
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index e9cf5b67f1b7..4cde8f48a540 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -73,6 +73,18 @@ config SERIAL_AMBA_PL011_CONSOLE
  your boot loader (lilo or loadlin) about how to pass options to the
  kernel at boot time.)

+config QCOM_QDF2400_ERRATUM_44
+   bool "Work around QDF2400 SoC E44 stuck BUSY bit"
+   depends on SERIAL_AMBA_PL011_CONSOLE=y
+   default y
+   help
+ The BUSY bit in the Flag Register of the UART on the QDF2432v1 and
+ QDF2400v1 SoCs may get stuck as 1, resulting in a hung serial console.
+ Say Y here to work around the issue by checking TXFE == 0 instead of
+ BUSY == 1 on affected systems.
+
+ If unsure, say Y.
+
 config SERIAL_EARLYCON_ARM_SEMIHOST
bool "Early console using ARM semihosting"
depends on ARM64 || ARM
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index d4171d71a258..41e51901d6ef 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -97,6 +97,7 @@ struct vendor_data {
unsigned intfr_dsr;
unsigned intfr_cts;
unsigned intfr_ri;
+   unsigned intinv_fr;
boolaccess_32b;
booloversampling;
boold

Re: [PATCH 4/5] target: Fix multi-session dynamic se_node_acl double free OOPs

[Nicholas A. Bellinger]

On Tue, 2017-02-07 at 15:12 -0800, Christoph Hellwig wrote:
> And the real patch after compile fixing it is here of course:
> 

Getting rid of the extra se_node_acl->acl_free_comp seems to make sense
here..

The only potential issue is if returning from configfs syscall
rmdir /sys/kernel/config/target/$FABRIC/$WWN/$TPGT/acls/$INITIATOR/
before se_node_acl memory is released has implications when the
underlying ../$WWN/$TPGT/ is removed immediately after.

In any event, I'll verify this patch with the original test case and use
it instead if everything looks OK.

> diff --git a/drivers/target/target_core_internal.h 
> b/drivers/target/target_core_internal.h
> index 9ab7090f7c83..96c38f30069d 100644
> --- a/drivers/target/target_core_internal.h
> +++ b/drivers/target/target_core_internal.h
> @@ -152,6 +152,7 @@ void  target_qf_do_work(struct work_struct *work);
>  bool target_check_wce(struct se_device *dev);
>  bool target_check_fua(struct se_device *dev);
>  void __target_execute_cmd(struct se_cmd *, bool);
> +void target_put_nacl(struct se_node_acl *);
>  
>  /* target_core_stat.c */
>  void target_stat_setup_dev_default_groups(struct se_device *);
> diff --git a/drivers/target/target_core_tpg.c 
> b/drivers/target/target_core_tpg.c
> index d99752c6cd60..08738c87e5b0 100644
> --- a/drivers/target/target_core_tpg.c
> +++ b/drivers/target/target_core_tpg.c
> @@ -197,7 +197,6 @@ static struct se_node_acl *target_alloc_node_acl(struct 
> se_portal_group *tpg,
>   INIT_LIST_HEAD(&acl->acl_sess_list);
>   INIT_HLIST_HEAD(&acl->lun_entry_hlist);
>   kref_init(&acl->acl_kref);
> - init_completion(&acl->acl_free_comp);
>   spin_lock_init(&acl->nacl_sess_lock);
>   mutex_init(&acl->lun_entry_mutex);
>   atomic_set(&acl->acl_pr_ref_count, 0);
> @@ -370,21 +369,6 @@ void core_tpg_del_initiator_node_acl(struct se_node_acl 
> *acl)
>   target_shutdown_sessions(acl);
>  
>   target_put_nacl(acl);
> - /*
> -  * Wait for last target_put_nacl() to complete in target_complete_nacl()
> -  * for active fabric session transport_deregister_session() callbacks.
> -  */
> - wait_for_completion(&acl->acl_free_comp);
> -
> - core_tpg_wait_for_nacl_pr_ref(acl);
> - core_free_device_list_for_node(acl, tpg);
> -
> - pr_debug("%s_TPG[%hu] - Deleted ACL with TCQ Depth: %d for %s"
> - " Initiator Node: %s\n", tpg->se_tpg_tfo->get_fabric_name(),
> - tpg->se_tpg_tfo->tpg_get_tag(tpg), acl->queue_depth,
> - tpg->se_tpg_tfo->get_fabric_name(), acl->initiatorname);
> -
> - kfree(acl);
>  }
>  
>  /*   core_tpg_set_initiator_node_queue_depth():
> diff --git a/drivers/target/target_core_transport.c 
> b/drivers/target/target_core_transport.c
> index 1cadc9eefa21..9ebd86a8ef41 100644
> --- a/drivers/target/target_core_transport.c
> +++ b/drivers/target/target_core_transport.c
> @@ -453,19 +453,25 @@ ssize_t target_show_dynamic_sessions(struct 
> se_portal_group *se_tpg, char *page)
>  }
>  EXPORT_SYMBOL(target_show_dynamic_sessions);
>  
> -static void target_complete_nacl(struct kref *kref)
> +static void target_destroy_nacl(struct kref *kref)
>  {
>   struct se_node_acl *nacl = container_of(kref,
>   struct se_node_acl, acl_kref);
> + struct se_portal_group *se_tpg = nacl->se_tpg;
>  
> - complete(&nacl->acl_free_comp);
> + mutex_lock(&se_tpg->acl_node_mutex);
> + list_del(&nacl->acl_list);
> + mutex_unlock(&se_tpg->acl_node_mutex);
> +
> + core_tpg_wait_for_nacl_pr_ref(nacl);
> + core_free_device_list_for_node(nacl, se_tpg);
> + kfree(nacl);
>  }
>  
>  void target_put_nacl(struct se_node_acl *nacl)
>  {
> - kref_put(&nacl->acl_kref, target_complete_nacl);
> + kref_put(&nacl->acl_kref, target_destroy_nacl);
>  }
> -EXPORT_SYMBOL(target_put_nacl);
>  
>  void transport_deregister_session_configfs(struct se_session *se_sess)
>  {
> @@ -499,12 +505,40 @@ EXPORT_SYMBOL(transport_deregister_session_configfs);
>  void transport_free_session(struct se_session *se_sess)
>  {
>   struct se_node_acl *se_nacl = se_sess->se_node_acl;
> +
>   /*
>* Drop the se_node_acl->nacl_kref obtained from within
>* core_tpg_get_initiator_node_acl().
>*/
>   if (se_nacl) {
> + struct se_portal_group *se_tpg = se_nacl->se_tpg;
> + const struct target_core_fabric_ops *se_tfo = 
> se_tpg->se_tpg_tfo;
> + unsigned long flags;
> + bool stop = false;
> +
>   se_sess->se_node_acl = NULL;
> +
> + /*
> +  * Also determine if we need to drop the extra ->cmd_kref if
> +  * it had been previously dynamically generated, and
> +  * the endpoint is not caching dynamic ACLs.
> +  */
> + mutex_lock(&se_tpg->acl_node_mutex);
> + if (se_nacl->dynamic_node_acl &&
> + !se_tfo->tpg_check_demo_mode_cache(se_tpg)) {
> 

Re: [PATCH v2 1/2] sierra_net: Add support for IPv6 and Dual-Stack Link Sense Indications

[kbuild test robot]

Hi Stefan,

[auto build test WARNING on net-next/master]
[also build test WARNING on v4.10-rc7]
[cannot apply to next-20170207]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Stefan-Br-ns/sierra_net-Add-support-for-IPv6-and-Dual-Stack-Link-Sense-Indications/20170207-105111
config: x86_64-randconfig-b0-02081035 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/net/usb/sierra_net.c: In function 'sierra_net_bind':
>> drivers/net/usb/sierra_net.c:687: warning: unused variable 'eth'

vim +/eth +687 drivers/net/usb/sierra_net.c

f7385ec9 Ming Lei  2012-10-24  671  if (result < 0)
eb4fd8cd Elina Pasheva 2010-04-27  672  return -EIO;
eb4fd8cd Elina Pasheva 2010-04-27  673  
f7385ec9 Ming Lei  2012-10-24  674  *datap = le16_to_cpu(attrdata);
eb4fd8cd Elina Pasheva 2010-04-27  675  return result;
eb4fd8cd Elina Pasheva 2010-04-27  676  }
eb4fd8cd Elina Pasheva 2010-04-27  677  
eb4fd8cd Elina Pasheva 2010-04-27  678  /*
eb4fd8cd Elina Pasheva 2010-04-27  679   * collects the bulk endpoints, the 
status endpoint.
eb4fd8cd Elina Pasheva 2010-04-27  680   */
eb4fd8cd Elina Pasheva 2010-04-27  681  static int sierra_net_bind(struct 
usbnet *dev, struct usb_interface *intf)
eb4fd8cd Elina Pasheva 2010-04-27  682  {
eb4fd8cd Elina Pasheva 2010-04-27  683  u8  ifacenum;
eb4fd8cd Elina Pasheva 2010-04-27  684  u8  numendpoints;
eb4fd8cd Elina Pasheva 2010-04-27  685  u16 fwattr = 0;
eb4fd8cd Elina Pasheva 2010-04-27  686  int status;
eb4fd8cd Elina Pasheva 2010-04-27 @687  struct ethhdr *eth;
eb4fd8cd Elina Pasheva 2010-04-27  688  struct sierra_net_data *priv;
eb4fd8cd Elina Pasheva 2010-04-27  689  static const u8 
sync_tmplate[sizeof(priv->sync_msg)] = {
eb4fd8cd Elina Pasheva 2010-04-27  690  0x00, 0x00, 
SIERRA_NET_HIP_MSYNC_ID, 0x00};
eb4fd8cd Elina Pasheva 2010-04-27  691  static const u8 
shdwn_tmplate[sizeof(priv->shdwn_msg)] = {
eb4fd8cd Elina Pasheva 2010-04-27  692  0x00, 0x00, 
SIERRA_NET_HIP_SHUTD_ID, 0x00};
eb4fd8cd Elina Pasheva 2010-04-27  693  
eb4fd8cd Elina Pasheva 2010-04-27  694  dev_dbg(&dev->udev->dev, "%s", 
__func__);
eb4fd8cd Elina Pasheva 2010-04-27  695  

:: The code at line 687 was first introduced by commit
:: eb4fd8cd355c8ec425a12ec6cbdac614e8a4819d net/usb: add sierra_net.c driver

:: TO: Elina Pasheva 
:: CC: David S. Miller 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH v3 2/3] ASoC: zx-i2s: introduce pclk for zx2967 family

[Baoyou Xie]

ZTE's zx2967 I2S controller driver introduces pclk, this
patch documents this fact.

Signed-off-by: Baoyou Xie 
---
 Documentation/devicetree/bindings/sound/zte,zx-i2s.txt | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/zte,zx-i2s.txt 
b/Documentation/devicetree/bindings/sound/zte,zx-i2s.txt
index 7e5aa6f..77390c0 100644
--- a/Documentation/devicetree/bindings/sound/zte,zx-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/zte,zx-i2s.txt
@@ -4,7 +4,7 @@ Required properties:
  - compatible : Must be "zte,zx296702-i2s"
  - reg : Must contain I2S core's registers location and length
  - clocks : Pairs of phandle and specifier referencing the controller's clocks.
- - clock-names: "tx" for the clock to the I2S interface.
+ - clock-names: "wclk" for the wclk, "pclk" for the pclk to the I2S interface.
  - dmas: Pairs of phandle and specifier for the DMA channel that is used by
the core. The core expects two dma channels for transmit.
  - dma-names : Must be "tx" and "rx"
@@ -15,13 +15,17 @@ please check:
* clock/clock-bindings.txt
* dma/dma.txt
 
+Please note that ZTE ZX296702 I2S controller driver is compatible for zx296702
+and zx296718, so compatible string might be set as follow:
+   "zte,zx296718-i2s", "zte,zx296702-i2s"
+
 Example:
i2s0: i2s0@0b005000 {
#sound-dai-cells = <0>;
-   compatible = "zte,zx296702-i2s";
+   compatible = "zte,zx296718-i2s", "zte,zx296702-i2s";
reg = <0x0b005000 0x1000>;
-   clocks = <&lsp0clk ZX296702_I2S0_DIV>;
-   clock-names = "tx";
+   clocks = <&audiocrm AUDIO_I2S0_WCLK>, <&audiocrm 
AUDIO_I2S0_PCLK>;
+   clock-names = "wclk", "pclk";
interrupts = ;
dmas = <&dma 5>, <&dma 6>;
dma-names = "tx", "rx";
-- 
2.7.4

[PATCH v3 3/3] ASoC: zx-i2s: introduce pclk for zx2967 family

[Baoyou Xie]

The pclk is necessary for zx2967 I2S controller. the driver
currently doesn't handle it. This is something we need to fix.

In turn, the driver supports zx296718's I2S controller.

By the way, this patch also change the clock name from tx to wclk
to make it clear.

Signed-off-by: Baoyou Xie 
---
 sound/soc/zte/zx-i2s.c | 37 -
 1 file changed, 28 insertions(+), 9 deletions(-)

diff --git a/sound/soc/zte/zx-i2s.c b/sound/soc/zte/zx-i2s.c
index ed7a56d..2d486ea 100644
--- a/sound/soc/zte/zx-i2s.c
+++ b/sound/soc/zte/zx-i2s.c
@@ -95,7 +95,7 @@
 struct zx_i2s_info {
struct snd_dmaengine_dai_dma_data   dma_playback;
struct snd_dmaengine_dai_dma_data   dma_capture;
-   struct clk  *dai_clk;
+   struct clk  *dai_wclk, *dai_pclk;
void __iomem*reg_base;
int master;
resource_size_t mapbase;
@@ -275,8 +275,9 @@ static int zx_i2s_hw_params(struct snd_pcm_substream 
*substream,
writel_relaxed(val, i2s->reg_base + ZX_I2S_TIMING_CTRL);
 
if (i2s->master)
-   ret = clk_set_rate(i2s->dai_clk,
-  params_rate(params) * ch_num * CLK_RAT);
+   ret = clk_set_rate(i2s->dai_wclk,
+   params_rate(params) * ch_num * CLK_RAT);
+
return ret;
 }
 
@@ -328,8 +329,19 @@ static int zx_i2s_startup(struct snd_pcm_substream 
*substream,
  struct snd_soc_dai *dai)
 {
struct zx_i2s_info *zx_i2s = dev_get_drvdata(dai->dev);
+   int ret;
+
+   ret = clk_prepare_enable(zx_i2s->dai_wclk);
+   if (ret)
+   return ret;
+
+   ret = clk_prepare_enable(zx_i2s->dai_pclk);
+   if (ret) {
+   clk_disable_unprepare(zx_i2s->dai_wclk);
+   return ret;
+   }
 
-   return clk_prepare_enable(zx_i2s->dai_clk);
+   return ret;
 }
 
 static void zx_i2s_shutdown(struct snd_pcm_substream *substream,
@@ -337,7 +349,8 @@ static void zx_i2s_shutdown(struct snd_pcm_substream 
*substream,
 {
struct zx_i2s_info *zx_i2s = dev_get_drvdata(dai->dev);
 
-   clk_disable_unprepare(zx_i2s->dai_clk);
+   clk_disable_unprepare(zx_i2s->dai_wclk);
+   clk_disable_unprepare(zx_i2s->dai_pclk);
 }
 
 static struct snd_soc_dai_ops zx_i2s_dai_ops = {
@@ -381,10 +394,16 @@ static int zx_i2s_probe(struct platform_device *pdev)
if (!zx_i2s)
return -ENOMEM;
 
-   zx_i2s->dai_clk = devm_clk_get(&pdev->dev, "tx");
-   if (IS_ERR(zx_i2s->dai_clk)) {
-   dev_err(&pdev->dev, "Fail to get clk\n");
-   return PTR_ERR(zx_i2s->dai_clk);
+   zx_i2s->dai_wclk = devm_clk_get(&pdev->dev, "wclk");
+   if (IS_ERR(zx_i2s->dai_wclk)) {
+   dev_err(&pdev->dev, "Fail to get wclk\n");
+   return PTR_ERR(zx_i2s->dai_wclk);
+   }
+
+   zx_i2s->dai_pclk = devm_clk_get(&pdev->dev, "pclk");
+   if (IS_ERR(zx_i2s->dai_pclk)) {
+   dev_info(&pdev->dev, "have no pclk\n");
+   zx_i2s->dai_pclk = NULL;
}
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-- 
2.7.4

Re: [PATCH v3 3/4] cpufreq: bmips-cpufreq: CPUfreq driver for Broadcom's BMIPS SoCs

[Viresh Kumar]

On 07-02-17, 13:58, Markus Mayer wrote:
> From: Markus Mayer 
> 
> Add the MIPS CPUfreq driver. This driver currently supports CPUfreq on
> BMIPS5xxx-based SoCs.
> 
> Signed-off-by: Markus Mayer 
> ---
>  drivers/cpufreq/Kconfig |  10 +++
>  drivers/cpufreq/Makefile|   1 +
>  drivers/cpufreq/bmips-cpufreq.c | 188 
> 
>  3 files changed, 199 insertions(+)
>  create mode 100644 drivers/cpufreq/bmips-cpufreq.c

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v2] security: selinux: allow changing labels for cgroupfs

[Paul Moore]

On Thu, Feb 2, 2017 at 10:22 AM, Antonio Murdaca  wrote:
> This patch allows changing labels for cgroup mounts. Previously, running
> chcon on cgroupfs would throw an "Operation not supported". This patch
> specifically whitelist cgroupfs.
>
> The patch could also allow containers to write only to the systemd cgroup
> for instance, while the other cgroups are kept with cgroup_t label.
>
> Signed-off-by: Antonio Murdaca 
> ---
> Changes in v2:
>   - whitelist cgroup2 fs type
>
>  security/selinux/hooks.c | 2 ++
>  1 file changed, 2 insertions(+)

Merged into selinux/next, thanks.

> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 3b955c6..2789f0a 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -480,6 +480,8 @@ static int selinux_is_sblabel_mnt(struct super_block *sb)
> sbsec->behavior == SECURITY_FS_USE_NATIVE ||
> /* Special handling. Genfs but also in-core setxattr handler 
> */
> !strcmp(sb->s_type->name, "sysfs") ||
> +   !strcmp(sb->s_type->name, "cgroup") ||
> +   !strcmp(sb->s_type->name, "cgroup2") ||
> !strcmp(sb->s_type->name, "pstore") ||
> !strcmp(sb->s_type->name, "debugfs") ||
> !strcmp(sb->s_type->name, "tracefs") ||
> --
> 2.9.3

-- 
paul moore
www.paul-moore.com

linux-next: build failure after merge of the kvm tree

[Stephen Rothwell]

Hi all,

After merging the kvm tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

arch/x86/kvm/x86.c: In function 'kvm_pv_clock_pairing':
arch/x86/kvm/x86.c:6157:2: error: unknown type name 'cycle_t'
  cycle_t cycle;
  ^
arch/x86/kvm/x86.c:6163:42: error: passing argument 2 of 
'kvm_get_walltime_and_clockread' from incompatible pointer type 
[-Werror=incompatible-pointer-types]
  if (kvm_get_walltime_and_clockread(&ts, &cycle) == false)
  ^
arch/x86/kvm/x86.c:1665:13: note: expected 'u64 * {aka long long unsigned int 
*}' but argument is of type 'int *'
 static bool kvm_get_walltime_and_clockread(struct timespec *ts,
 ^

Caused by commit

  55dd00a73a51 ("KVM: x86: add KVM_HC_CLOCK_PAIRING hypercall")

I have used the version fo the kvm tree from next-20170207 for today.

-- 
Cheers,
Stephen Rothwell

Re: v4.9, 4.4-final: 28 bioset threads on small notebook, 36 threads on cellphone

[Mike Galbraith]

On Tue, 2017-02-07 at 21:39 +0100, Pavel Machek wrote:
> On Mon 2017-02-06 17:49:06, Kent Overstreet wrote:
> > On Mon, Feb 06, 2017 at 04:47:24PM -0900, Kent Overstreet wrote:
> > > On Mon, Feb 06, 2017 at 01:53:09PM +0100, Pavel Machek wrote:
> > > > Still there on v4.9, 36 threads on nokia n900 cellphone.
> > > > 
> > > > So.. what needs to be done there?
> > 
> > > But, I just got an idea for how to handle this that might be halfway 
> > > sane, maybe
> > > I'll try and come up with a patch...
> > 
> > Ok, here's such a patch, only lightly tested:
> 
> I guess it would be nice for me to test it... but what it is against?
> I tried after v4.10-rc5 and linux-next, but got rejects in both cases.

It wedged into master easily enough (box still seems to work.. but I'll
be rebooting in a very few seconds just in case:), but threads on my
desktop box only dropped from 73 to 71.  Poo.

-Mike

Re: [PATCH 1/4] perf tools: pass PYTHON config to feature detection

[David Carrillo-Cisneros]

On Tue, Feb 7, 2017 at 11:47 AM, Arnaldo Carvalho de Melo
 wrote:
> Em Wed, Feb 01, 2017 at 10:38:01PM -0800, David Carrillo-Cisneros escreveu:
>> Python's CC and link Makefile variables were not passed to feature
>> detection, causing feature detection to use system's Python rather than
>> PYTHON_CONFIG's one. This created a mismatch between the detected Python
>> support and the one actually used by perf when PYTHON_CONFIG is specified.
>>
>> Fix it by moving Python's variable initialization to before feature
>> detection and pass FLAGS_PYTHON_EMBED to Python's feature detection's
>> build target.
>
> So, all builds on Ubuntu with the devel files for perf end up with:
>
> ubuntu:12.04.5, 14.04.4, 16.04, 16.10 (cross builds, native ones)
>
>   GEN  /tmp/build/perf/libtraceevent-dynamic-list
> /bin/sh: 1: [: U: unexpected operator
> Either missing one of [ /tmp/build/perf/plugin_jbd2.so 
> /tmp/build/perf/plugin_hrtimer.so /tmp/build/perf/plugin_kmem.so 
> /tmp/build/perf/plugin_kvm.so /tmp/build/perf/plugin_mac80211.so 
> /tmp/build/perf/plugin_sched_switch.so /tmp/build/perf/plugin_function.so 
> /tmp/build/perf/plugin_xen.so /tmp/build/perf/plugin_scsi.so 
> /tmp/build/perf/plugin_cfg80211.so] or bad version of nm
>
> Details:
>
> perfbuilder@341e71da5019:/git/linux$ cat /etc/os-release
> NAME="Ubuntu"
> VERSION="16.10 (Yakkety Yak)"
> ID=ubuntu
> ID_LIKE=debian
> PRETTY_NAME="Ubuntu 16.10"
> VERSION_ID="16.10"
> HOME_URL="http://www.ubuntu.com/";
> SUPPORT_URL="http://help.ubuntu.com/";
> BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/";
> PRIVACY_POLICY_URL="http://www.ubuntu.com/legal/terms-and-policies/privacy-policy";
> VERSION_CODENAME=yakkety
> UBUNTU_CODENAME=yakkety
> perfbuilder@341e71da5019:/git/linux$ ls -la /tmp/build/perf/plugin_jbd2.so 
> /tmp/build/perf/plugin_hrtimer.so /tmp/build/perf/plugin_kmem.so 
> /tmp/build/perf/plugin_kvm.so /tmp/build/perf/plugin_mac80211.so 
> /tmp/build/perf/plugin_sched_switch.so /tmp/build/perf/plugin_function.so 
> /tmp/build/perf/plugin_xen.so /tmp/build/perf/plugin_scsi.so 
> /tmp/build/perf/plugin_cfg80211.so
> -rwxr-xr-x. 1 perfbuilder perfbuilder 13576 Feb  7 19:38 
> /tmp/build/perf/plugin_cfg80211.so
> -rwxr-xr-x. 1 perfbuilder perfbuilder 20256 Feb  7 19:38 
> /tmp/build/perf/plugin_function.so
> -rwxr-xr-x. 1 perfbuilder perfbuilder 13680 Feb  7 19:38 
> /tmp/build/perf/plugin_hrtimer.so
> -rwxr-xr-x. 1 perfbuilder perfbuilder 13760 Feb  7 19:38 
> /tmp/build/perf/plugin_jbd2.so
> -rwxr-xr-x. 1 perfbuilder perfbuilder 13976 Feb  7 19:38 
> /tmp/build/perf/plugin_kmem.so
> -rwxr-xr-x. 1 perfbuilder perfbuilder 28680 Feb  7 19:38 
> /tmp/build/perf/plugin_kvm.so
> -rwxr-xr-x. 1 perfbuilder perfbuilder 14248 Feb  7 19:38 
> /tmp/build/perf/plugin_mac80211.so
> -rwxr-xr-x. 1 perfbuilder perfbuilder 18800 Feb  7 19:38 
> /tmp/build/perf/plugin_sched_switch.so
> -rwxr-xr-x. 1 perfbuilder perfbuilder 20136 Feb  7 19:38 
> /tmp/build/perf/plugin_scsi.so
> -rwxr-xr-x. 1 perfbuilder perfbuilder 14504 Feb  7 19:38 
> /tmp/build/perf/plugin_xen.so
> perfbuilder@341e71da5019:/git/linux$
>
> perfbuilder@341e71da5019:/git/linux$ file=/tmp/build/perf/plugin_jbd2.so ; nm 
> -u -D $file | awk 'NF>1 {print $$file}' | sort -u
>  U pevent_register_print_function
>  U pevent_unregister_print_function
>  U trace_seq_printf
> perfbuilder@341e71da5019:/git/linux$
>
>

Thanks for testing it.

I found that some *.so files in Ubuntu have the "w" value in nm's
otput symbol type. From man nm:

   "W"
   "w" The symbol is a weak symbol that has not been
specifically tagged as a weak object symbol.  When a
   weak defined symbol is linked with a normal defined
symbol, the normal defined symbol is used with
   no error.  When a weak undefined symbol is linked and
the symbol is not defined, the value of the
   symbol is determined in a system-specific manner
without error.  On some systems, uppercase
   indicates that a default value has been specified.


I'll send an updated patch that expects and includes undefined weak symbols.

Thanks,
David

[PATCH v2 2/2] Documentation/kconfig: add search jump feature description

[changbin . du]

From: Changbin Du 

Kernel menuconfig support direct jumping function from the search
result. This is a very convenient feature but not documented. So
add a short description to the kconfig documentation to let more
developers know it.

v2: correct spell (Jim)

Signed-off-by: Changbin Du 
Reviewed-by: Jim Davis 
---
 Documentation/kbuild/kconfig.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/kbuild/kconfig.txt b/Documentation/kbuild/kconfig.txt
index bbc99c0..fdac2cd 100644
--- a/Documentation/kbuild/kconfig.txt
+++ b/Documentation/kbuild/kconfig.txt
@@ -178,6 +178,10 @@ Searching in menuconfig:
first (and in alphabetical order), then come all other symbols,
sorted in alphabetical order.
 
+   In the search result textbox, each symbol has a jump number on
+   left side if the symbol is visible. You can type the number
+   to jump to target menu to configure that symbol.
+
 __
 User interface options for 'menuconfig'
 
-- 
2.7.4

[PATCH v2 1/2] kconfig/mconf: add jumping tip in title of search result textbox

[changbin . du]

From: Changbin Du 

Prompt user how to quickly jump to the item he/she is interested in.

Signed-off-by: Changbin Du 
Reviewed-by: Jani Nikula 
---
 scripts/kconfig/mconf.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
index 315ce2c..23d5681 100644
--- a/scripts/kconfig/mconf.c
+++ b/scripts/kconfig/mconf.c
@@ -443,10 +443,10 @@ static void search_conf(void)
 
res = get_relations_str(sym_arr, &head);
set_subtitle();
-   dres = show_textbox_ext(_("Search Results"), (char *)
-   str_get(&res), 0, 0, keys, &vscroll,
-   &hscroll, &update_text, (void *)
-   &data);
+   dres = show_textbox_ext(
+   _("Search Results (type the number to jump)"),
+   (char *)str_get(&res), 0, 0, keys, &vscroll,
+   &hscroll, &update_text, (void *)&data);
again = false;
for (i = 0; i < JUMP_NB && keys[i]; i++)
if (dres == keys[i]) {
-- 
2.7.4

[PATCH v2 0/2] kconfig/mconf: propagate jumping function in search result view

[changbin . du]

From: Changbin Du 

While I am searching something in menuconfig, I hope if I can jump to interested
items directly. I even try to add this feature. When I check the code just 
found 
it has already been there but not documented. So why let more developers know 
it?

v2: correct spell (Jim)
   
Changbin Du (2):
  kconfig/mconf: add jumping tip in title of search result textbox
  Documentation/kconfig: add search jump feature description

 Documentation/kbuild/kconfig.txt | 4 
 scripts/kconfig/mconf.c  | 8 
 2 files changed, 8 insertions(+), 4 deletions(-)

-- 
2.7.4

[PATCH v3 1/3] clk: zte: add i2s clocks for zx296718

[Baoyou Xie]

The i2s related clock support is missing from the existing zx296718
clock driver. This patch adds it, so that the upstream ZX I2S driver
can work out.

Signed-off-by: Baoyou Xie 
---
 drivers/clk/zte/clk-zx296718.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/clk/zte/clk-zx296718.c b/drivers/clk/zte/clk-zx296718.c
index ad5d1df..f106d40 100644
--- a/drivers/clk/zte/clk-zx296718.c
+++ b/drivers/clk/zte/clk-zx296718.c
@@ -941,6 +941,10 @@ static struct zx_clk_gate audio_gate_clk[] = {
GATE(AUDIO_SPDIF1_WCLK, "spdif1_wclk", "spdif1_wclk_div", 
AUDIO_SPDIF1_CLK, 9, CLK_SET_RATE_PARENT, 0),
GATE(AUDIO_TDM_WCLK, "tdm_wclk", "tdm_wclk_div", AUDIO_TDM_CLK, 17, 
CLK_SET_RATE_PARENT, 0),
GATE(AUDIO_TS_PCLK, "tempsensor_pclk", "clk49m5", AUDIO_TS_CLK, 1, 0, 
0),
+   GATE(AUDIO_I2S0_PCLK, "i2s0_pclk", "clk49m5", AUDIO_I2S0_CLK, 8, 0, 0),
+   GATE(AUDIO_I2S1_PCLK, "i2s1_pclk", "clk49m5", AUDIO_I2S1_CLK, 8, 0, 0),
+   GATE(AUDIO_I2S2_PCLK, "i2s2_pclk", "clk49m5", AUDIO_I2S2_CLK, 8, 0, 0),
+   GATE(AUDIO_I2S3_PCLK, "i2s3_pclk", "clk49m5", AUDIO_I2S3_CLK, 8, 0, 0),
 };
 
 static struct clk_hw_onecell_data audio_hw_onecell_data = {
-- 
2.7.4

[PATCH 1/4] ACPICA: Linuxize: Restore and fix intel compiler build

[Lv Zheng]

ACPICA commit b59347d0b8b676cb555fe8da5cad08fcd4eeb0d3

The following commit cleans up compiler specific inclusions:
  Commit: 9fa1cebdbfff3db8953cebca8ee327d75edefc40
  Subject: ACPICA: OSL: Cleanup the inclusion order of the
   compiler-specific headers
But breaks one thing due to the following old issue:
 Buidling Linux kernel with Intel compiler originally depends on acgcc.h
 not acintel.h.
So after making Intel compiler build working in ACPICA upstream by
correctly using acintel.h, it becomes unable to build Linux kernel using
Intel compiler as there is no acintel.h in the kernel source tree.

This patch releases acintel.h to Linux kernel and fixes its inclusion in
acenv.h.

Fixes: 9fa1cebdbfff ("ACPICA: OSL: Cleanup the inclusion order of the 
compiler-specific headers")
Cc: sta...@vger.kernel.org # 4.9+
Link: https://github.com/acpica/acpica/commit/b59347d0
Tested-by: Stepan M Mishura 
Signed-off-by: Lv Zheng 
---
 include/acpi/platform/acenv.h   |  2 +-
 include/acpi/platform/acintel.h | 87 +
 2 files changed, 88 insertions(+), 1 deletion(-)
 create mode 100644 include/acpi/platform/acintel.h

diff --git a/include/acpi/platform/acenv.h b/include/acpi/platform/acenv.h
index 926efe9..6fa9c52 100644
--- a/include/acpi/platform/acenv.h
+++ b/include/acpi/platform/acenv.h
@@ -178,7 +178,7 @@
 #include "acmsvc.h"
 
 #elif defined(__INTEL_COMPILER)
-#include "acintel.h"
+#include 
 
 #endif
 
diff --git a/include/acpi/platform/acintel.h b/include/acpi/platform/acintel.h
new file mode 100644
index 000..17bd3b7
--- /dev/null
+++ b/include/acpi/platform/acintel.h
@@ -0,0 +1,87 @@
+/**
+ *
+ * Name: acintel.h - VC specific defines, etc.
+ *
+ */
+
+/*
+ * Copyright (C) 2000 - 2017, Intel Corp.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions, and the following disclaimer,
+ *without modification.
+ * 2. Redistributions in binary form must reproduce at minimum a disclaimer
+ *substantially similar to the "NO WARRANTY" disclaimer below
+ *("Disclaimer") and any redistribution must be conditioned upon
+ *including a substantially similar Disclaimer requirement for further
+ *binary redistribution.
+ * 3. Neither the names of the above-listed copyright holders nor the names
+ *of any contributors may be used to endorse or promote products derived
+ *from this software without specific prior written permission.
+ *
+ * Alternatively, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") version 2 as published by the Free
+ * Software Foundation.
+ *
+ * NO WARRANTY
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * HOLDERS OR CONTRIBUTORS BE LIABLE FOR SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
+ * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGES.
+ */
+
+#ifndef __ACINTEL_H__
+#define __ACINTEL_H__
+
+/*
+ * Use compiler specific  is a good practice for even when
+ * -nostdinc is specified (i.e., ACPI_USE_STANDARD_HEADERS undefined.
+ */
+#include 
+
+/* Configuration specific to Intel 64-bit C compiler */
+
+#define COMPILER_DEPENDENT_INT64__int64
+#define COMPILER_DEPENDENT_UINT64   unsigned __int64
+#define ACPI_INLINE __inline
+
+/*
+ * Calling conventions:
+ *
+ * ACPI_SYSTEM_XFACE- Interfaces to host OS (handlers, threads)
+ * ACPI_EXTERNAL_XFACE  - External ACPI interfaces
+ * ACPI_INTERNAL_XFACE  - Internal ACPI interfaces
+ * ACPI_INTERNAL_VAR_XFACE  - Internal variable-parameter list interfaces
+ */
+#define ACPI_SYSTEM_XFACE
+#define ACPI_EXTERNAL_XFACE
+#define ACPI_INTERNAL_XFACE
+#define ACPI_INTERNAL_VAR_XFACE
+
+/* remark 981 - operands evaluated in no particular order */
+#pragma warning(disable:981)
+
+/* warn C4100: unreferenced formal parameter */
+#pragma warning(disable:4100)
+
+/* warn C4127: conditional expression is constant */
+#pragma warning(disable:4127)
+
+/* warn C4706: assignment within conditional expression */
+#pragma warning(disable:4706)
+
+/* warn C4214: bit fiel

[PATCH 4/4] ACPICA: Update version to 20170119

[Lv Zheng]

From: Bob Moore 

ACPICA commit 711a8c19d3c646fdc069c38912d9037c7fa5e718

Version 20170119.

Link: https://github.com/acpica/acpica/commit/711a8c19
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 include/acpi/acpixf.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h
index bb23cf7..3795386 100644
--- a/include/acpi/acpixf.h
+++ b/include/acpi/acpixf.h
@@ -46,7 +46,7 @@
 
 /* Current ACPICA subsystem version in MMDD format */
 
-#define ACPI_CA_VERSION 0x20161222
+#define ACPI_CA_VERSION 0x20170119
 
 #include 
 #include 
-- 
2.7.4

[PATCH_v4.1_3_3] Make core_pattern support namespace

[Cao Shufeng]

From: Zhao Lei 

Currently, each container shared one copy of coredump setting
with the host system, if host system changed the setting, each
running containers will be affected.
Same story happened when container changed core_pattern, both
host and other container will be affected.

For container based on namespace design, it is good to allow
each container keeping their own coredump setting.

It will bring us following benefit:
1: Each container can change their own coredump setting
   based on operation on /proc/sys/kernel/core_pattern
2: Coredump setting changed in host will not affect
   running containers.
3: Support both case of "putting coredump in guest" and
   "putting curedump in host".

Each namespace-based software(lxc, docker, ..) can use this function
to custom their dump setting.

And this function makes each continer working as separate system,
it fit for design goal of namespace.

Test(in lxc):
 # In the host
 # 
 # echo host_core >/proc/sys/kernel/core_pattern
 # cat /proc/sys/kernel/core_pattern
 host_core
 # ulimit -c 1024000
 # ./make_dump
 Segmentation fault (core dumped)
 # ls -l
 -rw--- 1 root root 331776 Feb  4 18:02 host_core.2175
 -rwxr-xr-x 1 root root 759731 Feb  4 18:01 make_dump
 #

 # In the container
 # 
 # cat /proc/sys/kernel/core_pattern
 host_core
 # echo container_core >/proc/sys/kernel/core_pattern
 # ./make_dump
 Segmentation fault (core dumped)
 # ls -l
 -rwxr-xr-x1 root root   759731 Feb  4 10:45 make_dump
 -rw---1 root root   331776 Feb  4 10:45 container_core.16
 #

 # Return to host
 # 
 # cat /proc/sys/kernel/core_pattern
 host_core
 # ls
 host_core.2175  make_dump  make_dump.c
 # rm -f host_core.2175
 # ./make_dump
 Segmentation fault (core dumped)
 # ls -l
 -rw--- 1 root root 331776 Feb  4 18:49 host_core.2351
 -rwxr-xr-x 1 root root 759731 Feb  4 18:01 make_dump
 #

Signed-off-by: Zhao Lei 
---
 fs/coredump.c | 25 --
 include/linux/pid_namespace.h |  3 +++
 kernel/pid.c  |  2 ++
 kernel/pid_namespace.c|  2 ++
 kernel/sysctl.c   | 50 ++-
 5 files changed, 70 insertions(+), 12 deletions(-)

diff --git a/fs/coredump.c b/fs/coredump.c
index 83282d7..4bab7bf 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -50,7 +50,6 @@
 
 int core_uses_pid;
 unsigned int core_pipe_limit;
-char core_pattern[CORENAME_MAX_SIZE] = "core";
 static int core_name_size = CORENAME_MAX_SIZE;
 
 struct core_name {
@@ -58,8 +57,6 @@ struct core_name {
int used, size;
 };
 
-/* The maximal length of core_pattern is also specified in sysctl.c */
-
 static int expand_corename(struct core_name *cn, int size)
 {
char *corename = krealloc(cn->corename, size, GFP_KERNEL);
@@ -184,10 +181,10 @@ static int cn_print_exe_file(struct core_name *cn)
  * name into corename, which must have space for at least
  * CORENAME_MAX_SIZE bytes plus one byte for the zero terminator.
  */
-static int format_corename(struct core_name *cn, struct coredump_params *cprm)
+static int format_corename(struct core_name *cn, const char *pat_ptr,
+  struct coredump_params *cprm)
 {
const struct cred *cred = current_cred();
-   const char *pat_ptr = core_pattern;
int ispipe = (*pat_ptr == '|');
int pid_in_pattern = 0;
int err = 0;
@@ -666,6 +663,8 @@ void do_coredump(const siginfo_t *siginfo)
 */
.mm_flags = mm->flags,
};
+   struct pid_namespace *pid_ns;
+   char core_pattern[CORENAME_MAX_SIZE];
 
audit_core_dumps(siginfo->si_signo);
 
@@ -675,6 +674,18 @@ void do_coredump(const siginfo_t *siginfo)
if (!__get_dumpable(cprm.mm_flags))
goto fail;
 
+   pid_ns = task_active_pid_ns(current);
+   spin_lock(&pid_ns->core_pattern_lock);
+   while (pid_ns != &init_pid_ns) {
+   if (pid_ns->core_pattern[0])
+   break;
+   spin_unlock(&pid_ns->core_pattern_lock);
+   pid_ns = pid_ns->parent,
+   spin_lock(&pid_ns->core_pattern_lock);
+   }
+   strcpy(core_pattern, pid_ns->core_pattern);
+   spin_unlock(&pid_ns->core_pattern_lock);
+
cred = prepare_creds();
if (!cred)
goto fail;
@@ -696,7 +707,7 @@ void do_coredump(const siginfo_t *siginfo)
 
old_cred = override_creds(cred);
 
-   ispipe = format_corename(&cn, &cprm);
+   ispipe = format_corename(&cn, core_pattern, &cprm);
 
if (ispipe) {
int dump_count;
@@ -743,7 +754,7 @@ void do_coredump(const siginfo_t *siginfo)
}
 
rcu_read_lock();
-   vinit_task = find_task_by_vpid(1);
+   vinit_task = find_task_by_pid_ns(1, pid_ns);
rcu_read_unlock();
if (!vinit_task) {
print

[PATCH_v4.1_0_3] Make core_pattern support namespace

[Cao Shufeng]

This patchset includes following function points:
1: Let usermodehelper function possible to set pid namespace
   done by: [PATCH v4 1/3] Make call_usermodehelper_exec possible
   to set pid namespace.
2: Let pipe_type core_pattern write dump into container's rootfs
   done by: [PATCH v4 2/3] Limit dump_pipe program's permission to
   init for container.
2: Make separate core_pattern setting for each container
   done by: [PATCH v4 3/3] Make core_pattern support namespace
3: Compatibility with current system
   also included in: [PATCH v4 3/3] Make core_pattern support namespace
   If container hadn't change core_pattern setting, it will keep
   same setting with host.

Test:
1: Pass a test script for each function of this patchset
   ## TEST IN HOST ##
   [root@kerneldev dumptest]# ./test_host
   Set file core_pattern: OK
   ./test_host: line 41:  2366 Segmentation fault  (core dumped) "$SCRI=
PT_BASE_DIR"/make_dump
   Checking dumpfile: OK
   Set file core_pattern: OK
   ./test_host: line 41:  2369 Segmentation fault  (core dumped) "$SCRI=
PT_BASE_DIR"/make_dump
   Checking dump_pipe triggered: OK
   Checking rootfs: OK
   Checking dumpfile: OK
   Checking namespace: OK
   Checking process list: OK
   Checking capabilities: OK

   ## TEST IN GUEST ##
   # ./test
   Segmentation fault (core dumped)
   Checking dump_pipe triggered: OK
   Checking rootfs: OK
   Checking dumpfile: OK
   Checking namespace: OK
   Checking process list: OK
   Checking cg pids: OK
   Checking capabilities: OK
   [   64.940734] make_dump[2432]: segfault at 0 ip 0040049d sp 000=
07ffc4af025f0 error 6 in make_dump[40+a6000]
   #
2: Pass other test(which is not easy to do in script) by hand.

Changelog v4-v4.1:
1. Fix kernel panic pointed out by:
   xiaolong...@intel.com

Changelog v3.1-v4:
1. remove extra fork pointed out by:
   Andrei Vagin 

Changelog v3-v3.1:
1. Switch "pwd" of pipe program to container's root fs.
2. Rebase on top of v4.9-rc1

Changelog v2->v3:
1: Fix problem of setting pid namespace, pointed out by:
   Andrei Vagin 

Changelog v1(RFC)->v2:
1: Add [PATCH 2/2] which was todo in [RFC v1].
2: Pass a test script for each function.
3: Rebase on top of v4.7.

Suggested-by: Eric W. Biederman 
Suggested-by: KOSAKI Motohiro 
Signed-off-by: Zhao Lei 
Signed-off-by: Cao Shufeng 

Cao Shufeng (2):
  Make call_usermodehelper_exec possible to set namespaces
  Limit dump_pipe program's permission to init for container

Zhao Lei (1):
  Make core_pattern support namespace

 fs/coredump.c | 150 +++---
 include/linux/binfmts.h   |   2 +
 include/linux/kmod.h  |   5 ++
 include/linux/pid_namespace.h |   3 +
 init/do_mounts_initrd.c   |   3 +-
 kernel/kmod.c |  55 +---
 kernel/pid.c  |   2 +
 kernel/pid_namespace.c|   2 +
 kernel/sysctl.c   |  50 --
 lib/kobject_uevent.c  |   3 +-
 security/keys/request_key.c   |   4 +-
 11 files changed, 253 insertions(+), 26 deletions(-)

-- 
2.9.3

[PATCH_v4.1_1_3] Make call_usermodehelper_exec possible to set namespaces

[Cao Shufeng]

Current call_usermodehelper_work() can not set namespaces for
the executed program.

This patch add above function for call_usermodehelper_work().
The init_intermediate is introduced for init works which should
be done before fork(). So that we get a method to set namespaces
for children. The cleanup_intermediate is introduced for cleaning
up what we have done in init_intermediate, like switching back
the namespace.

This function is helpful for coredump to run pipe_program in
specific container environment.

Signed-off-by: Cao Shufeng 
Co-author-by: Zhao Lei 
---
 fs/coredump.c   |  3 ++-
 include/linux/kmod.h|  5 +
 init/do_mounts_initrd.c |  3 ++-
 kernel/kmod.c   | 55 +
 lib/kobject_uevent.c|  3 ++-
 security/keys/request_key.c |  4 ++--
 6 files changed, 59 insertions(+), 14 deletions(-)

diff --git a/fs/coredump.c b/fs/coredump.c
index eb9c92c..9abf4e5 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -644,7 +644,8 @@ void do_coredump(const siginfo_t *siginfo)
retval = -ENOMEM;
sub_info = call_usermodehelper_setup(helper_argv[0],
helper_argv, NULL, GFP_KERNEL,
-   umh_pipe_setup, NULL, &cprm);
+   NULL, NULL, umh_pipe_setup,
+   NULL, &cprm);
if (sub_info)
retval = call_usermodehelper_exec(sub_info,
  UMH_WAIT_EXEC);
diff --git a/include/linux/kmod.h b/include/linux/kmod.h
index fcfd2bf..0e474d4 100644
--- a/include/linux/kmod.h
+++ b/include/linux/kmod.h
@@ -61,6 +61,9 @@ struct subprocess_info {
char **envp;
int wait;
int retval;
+   bool cleaned;
+   void (*init_intermediate)(struct subprocess_info *info);
+   void (*cleanup_intermediate)(struct subprocess_info *info);
int (*init)(struct subprocess_info *info, struct cred *new);
void (*cleanup)(struct subprocess_info *info);
void *data;
@@ -71,6 +74,8 @@ call_usermodehelper(char *path, char **argv, char **envp, int 
wait);
 
 extern struct subprocess_info *
 call_usermodehelper_setup(char *path, char **argv, char **envp, gfp_t gfp_mask,
+ void (*init_intermediate)(struct subprocess_info 
*info),
+ void (*cleanup_intermediate)(struct subprocess_info 
*info),
  int (*init)(struct subprocess_info *info, struct cred 
*new),
  void (*cleanup)(struct subprocess_info *), void 
*data);
 
diff --git a/init/do_mounts_initrd.c b/init/do_mounts_initrd.c
index a1000ca..59d11c9 100644
--- a/init/do_mounts_initrd.c
+++ b/init/do_mounts_initrd.c
@@ -72,7 +72,8 @@ static void __init handle_initrd(void)
current->flags |= PF_FREEZER_SKIP;
 
info = call_usermodehelper_setup("/linuxrc", argv, envp_init,
-GFP_KERNEL, init_linuxrc, NULL, NULL);
+GFP_KERNEL, NULL, NULL, init_linuxrc,
+NULL, NULL);
if (!info)
return;
call_usermodehelper_exec(info, UMH_WAIT_PROC);
diff --git a/kernel/kmod.c b/kernel/kmod.c
index 0277d12..dcaa17d 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -91,7 +92,8 @@ static int call_modprobe(char *module_name, int wait)
argv[4] = NULL;
 
info = call_usermodehelper_setup(modprobe_path, argv, envp, GFP_KERNEL,
-NULL, free_modprobe_argv, NULL);
+NULL, NULL, NULL, free_modprobe_argv,
+ NULL);
if (!info)
goto free_module_name;
 
@@ -205,8 +207,15 @@ static void umh_complete(struct subprocess_info *sub_info)
 */
if (comp)
complete(comp);
-   else
+   else {
+   for(;;) {
+   if (sub_info->cleaned == false)
+   udelay(20);
+   else
+   break;
+   }
call_usermodehelper_freeinfo(sub_info);
+   }
 }
 
 /*
@@ -301,6 +310,10 @@ static void call_usermodehelper_exec_sync(struct 
subprocess_info *sub_info)
/* Restore default kernel sig handler */
kernel_sigaction(SIGCHLD, SIG_IGN);
 
+   if(sub_info->cleanup_intermediate) {
+   sub_info->cleanup_intermediate(sub_info);
+   }
+   sub_info->cleaned = true;
umh_complete(sub_info);
 }
 
@@ -322,6 +335,9 @@ static void call_usermodehelper_exec_work(struct 
work_struct *work)
 {
struct subprocess_info *sub_info =
contai

[PATCH_v4.1_2_3] Limit dump_pipe program's permission to init for container

[Cao Shufeng]

Currently when we set core_pattern to a pipe, the pipe program is
forked by kthread running with root's permission, and write dumpfile
into host's filesystem.
Same thing happened for container, the dumper and dumpfile are also
in host(not in container).

It have following program:
1: Not consistent with file_type core_pattern
   When we set core_pattern to a file, the container will write dump
   into container's filesystem instead of host.
2: Not safe for privileged container
   In a privileged container, user can destroy host system by following
   command:
   # # In a container
   # echo "|/bin/dd of=/boot/vmlinuz" >/proc/sys/kernel/core_pattern
   # make_dump

This patch switch dumper program's environment to init task, so, for
container, dumper program have same environment with init task in
container, which make dumper program put in container's filesystem, and
write coredump into container's filesystem.
The dumper's permission is also limited into subset of container's init
process.

Suggested-by: Eric W. Biederman 
Suggested-by: KOSAKI Motohiro 

Signed-off-by: Cao ShuFeng
---
 fs/coredump.c   | 126 +++-
 include/linux/binfmts.h |   2 +
 2 files changed, 126 insertions(+), 2 deletions(-)

diff --git a/fs/coredump.c b/fs/coredump.c
index 9abf4e5..83282d7 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -505,6 +505,45 @@ static void wait_for_dump_helpers(struct file *file)
 }
 
 /*
+ * umh_ns_setup
+ * set the namesapces to the bask task of a container.
+ * we need to switch back to the original namespaces
+ * so that the thread of workqueue is not influlenced.
+ *
+ * this method runs in workqueue kernel thread.
+ */
+static void umh_ns_setup(struct subprocess_info *info)
+{
+   struct coredump_params *cp = (struct coredump_params *)info->data;
+   struct task_struct *base_task = cp->base_task;
+
+   if (base_task) {
+   cp->current_task_nsproxy = current->nsproxy;
+   //prevent current namespace from being freed
+   get_nsproxy(current->nsproxy);
+   /* Set namespaces to base_task */
+   get_nsproxy(base_task->nsproxy);
+   switch_task_namespaces(current, base_task->nsproxy);
+   }
+}
+
+/*
+ * umh_ns_cleanup
+ * cleanup what we have done in umh_ns_setup.
+ *
+ * this method runs in workqueue kernel thread.
+ */
+static void umh_ns_cleanup(struct subprocess_info *info)
+{
+   struct coredump_params *cp = (struct coredump_params *)info->data;
+   struct nsproxy *current_task_nsproxy = cp->current_task_nsproxy;
+   if (current_task_nsproxy) {
+   /* switch workqueue's original namespace back */
+   switch_task_namespaces(current, current_task_nsproxy);
+   }
+}
+
+/*
  * umh_pipe_setup
  * helper function to customize the process used
  * to collect the core in userspace.  Specifically
@@ -519,6 +558,8 @@ static int umh_pipe_setup(struct subprocess_info *info, 
struct cred *new)
 {
struct file *files[2];
struct coredump_params *cp = (struct coredump_params *)info->data;
+   struct task_struct *base_task;
+
int err = create_pipe_files(files, 0);
if (err)
return err;
@@ -527,10 +568,76 @@ static int umh_pipe_setup(struct subprocess_info *info, 
struct cred *new)
 
err = replace_fd(0, files[0], 0);
fput(files[0]);
+   if (err)
+   return err;
+
/* and disallow core files too */
current->signal->rlim[RLIMIT_CORE] = (struct rlimit){1, 1};
 
-   return err;
+   base_task = cp->base_task;
+   if (base_task) {
+   const struct cred *base_cred;
+
+   /* Set fs_root to base_task */
+   spin_lock(&base_task->fs->lock);
+   set_fs_root(current->fs, &base_task->fs->root);
+   set_fs_pwd(current->fs, &base_task->fs->pwd);
+   spin_unlock(&base_task->fs->lock);
+
+   /* Set cgroup to base_task */
+   current->flags &= ~PF_NO_SETAFFINITY;
+   err = cgroup_attach_task_all(base_task, current);
+   if (err < 0)
+   return err;
+
+   /* Set cred to base_task */
+   base_cred = get_task_cred(base_task);
+
+   new->uid   = base_cred->uid;
+   new->gid   = base_cred->gid;
+   new->suid  = base_cred->suid;
+   new->sgid  = base_cred->sgid;
+   new->euid  = base_cred->euid;
+   new->egid  = base_cred->egid;
+   new->fsuid = base_cred->fsuid;
+   new->fsgid = base_cred->fsgid;
+
+   new->securebits = base_cred->securebits;
+
+   new->cap_inheritable = base_cred->cap_inheritable;
+   new->cap_permitted   = base_cred->cap_permitted;
+   new->cap_effective   = base_cred->cap_effective;
+   new->cap_bset= base_cred->cap_

[PATCH 3/4] ACPICA: Tools: Update common signon, remove compilation bit width

[Lv Zheng]

From: Bob Moore 

ACPICA commit 43e04e75a9849072a1557b674004d8093bddb9ef

Remove the bit width of the compiler that generated the tool
from the tool signon. This was confusing and unnecessary.

Changed the iASL signon to add "disassembler" to the name.

Link: https://github.com/acpica/acpica/commit/43e04e75
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/acapps.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/acpica/acapps.h b/drivers/acpi/acpica/acapps.h
index c32bbe4..b65f273 100644
--- a/drivers/acpi/acpica/acapps.h
+++ b/drivers/acpi/acpica/acapps.h
@@ -54,23 +54,23 @@
 #define ACPICA_COPYRIGHT"Copyright (c) 2000 - 2017 Intel 
Corporation"
 
 #if ACPI_MACHINE_WIDTH == 64
-#define ACPI_WIDTH  "-64"
+#define ACPI_WIDTH  " (64-bit version)"
 
 #elif ACPI_MACHINE_WIDTH == 32
-#define ACPI_WIDTH  "-32"
+#define ACPI_WIDTH  " (32-bit version)"
 
 #else
 #error unknown ACPI_MACHINE_WIDTH
-#define ACPI_WIDTH  "-??"
+#define ACPI_WIDTH  " (unknown bit width, not 32 or 64)"
 
 #endif
 
 /* Macros for signons and file headers */
 
 #define ACPI_COMMON_SIGNON(utility_name) \
-   "\n%s\n%s version %8.8X%s\n%s\n\n", \
+   "\n%s\n%s version %8.8X\n%s\n\n", \
ACPICA_NAME, \
-   utility_name, ((u32) ACPI_CA_VERSION), ACPI_WIDTH, \
+   utility_name, ((u32) ACPI_CA_VERSION), \
ACPICA_COPYRIGHT
 
 #define ACPI_COMMON_HEADER(utility_name, prefix) \
-- 
2.7.4

[PATCH 2/4] ACPICA: Source tree: Update copyright notices to 2017

[Lv Zheng]

From: Bob Moore 

ACPICA commit 16577e5265923f4999b4d2c0addb2343b18135e1

Affects all files.

Link: https://github.com/acpica/acpica/commit/16577e52
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/acapps.h | 4 ++--
 drivers/acpi/acpica/accommon.h   | 2 +-
 drivers/acpi/acpica/acdebug.h| 2 +-
 drivers/acpi/acpica/acdispat.h   | 2 +-
 drivers/acpi/acpica/acevents.h   | 2 +-
 drivers/acpi/acpica/acglobal.h   | 2 +-
 drivers/acpi/acpica/achware.h| 2 +-
 drivers/acpi/acpica/acinterp.h   | 2 +-
 drivers/acpi/acpica/aclocal.h| 2 +-
 drivers/acpi/acpica/acmacros.h   | 2 +-
 drivers/acpi/acpica/acnamesp.h   | 2 +-
 drivers/acpi/acpica/acobject.h   | 2 +-
 drivers/acpi/acpica/acopcode.h   | 2 +-
 drivers/acpi/acpica/acparser.h   | 2 +-
 drivers/acpi/acpica/acpredef.h   | 2 +-
 drivers/acpi/acpica/acresrc.h| 2 +-
 drivers/acpi/acpica/acstruct.h   | 2 +-
 drivers/acpi/acpica/actables.h   | 2 +-
 drivers/acpi/acpica/acutils.h| 2 +-
 drivers/acpi/acpica/amlcode.h| 2 +-
 drivers/acpi/acpica/amlresrc.h   | 2 +-
 drivers/acpi/acpica/dbcmds.c | 2 +-
 drivers/acpi/acpica/dbconvert.c  | 2 +-
 drivers/acpi/acpica/dbdisply.c   | 2 +-
 drivers/acpi/acpica/dbexec.c | 2 +-
 drivers/acpi/acpica/dbfileio.c   | 2 +-
 drivers/acpi/acpica/dbhistry.c   | 2 +-
 drivers/acpi/acpica/dbinput.c| 2 +-
 drivers/acpi/acpica/dbmethod.c   | 2 +-
 drivers/acpi/acpica/dbnames.c| 2 +-
 drivers/acpi/acpica/dbobject.c   | 2 +-
 drivers/acpi/acpica/dbstats.c| 2 +-
 drivers/acpi/acpica/dbtest.c | 2 +-
 drivers/acpi/acpica/dbutils.c| 2 +-
 drivers/acpi/acpica/dbxface.c| 2 +-
 drivers/acpi/acpica/dsargs.c | 2 +-
 drivers/acpi/acpica/dscontrol.c  | 2 +-
 drivers/acpi/acpica/dsdebug.c| 2 +-
 drivers/acpi/acpica/dsfield.c| 2 +-
 drivers/acpi/acpica/dsinit.c | 2 +-
 drivers/acpi/acpica/dsmethod.c   | 2 +-
 drivers/acpi/acpica/dsmthdat.c   | 2 +-
 drivers/acpi/acpica/dsobject.c   | 2 +-
 drivers/acpi/acpica/dsopcode.c   | 2 +-
 drivers/acpi/acpica/dsutils.c| 2 +-
 drivers/acpi/acpica/dswexec.c| 2 +-
 drivers/acpi/acpica/dswload.c| 2 +-
 drivers/acpi/acpica/dswload2.c   | 2 +-
 drivers/acpi/acpica/dswscope.c   | 2 +-
 drivers/acpi/acpica/dswstate.c   | 2 +-
 drivers/acpi/acpica/evevent.c| 2 +-
 drivers/acpi/acpica/evglock.c| 2 +-
 drivers/acpi/acpica/evgpe.c  | 2 +-
 drivers/acpi/acpica/evgpeblk.c   | 2 +-
 drivers/acpi/acpica/evgpeinit.c  | 2 +-
 drivers/acpi/acpica/evgpeutil.c  | 2 +-
 drivers/acpi/acpica/evhandler.c  | 2 +-
 drivers/acpi/acpica/evmisc.c | 2 +-
 drivers/acpi/acpica/evregion.c   | 2 +-
 drivers/acpi/acpica/evrgnini.c   | 2 +-
 drivers/acpi/acpica/evsci.c  | 2 +-
 drivers/acpi/acpica/evxface.c| 2 +-
 drivers/acpi/acpica/evxfevnt.c   | 2 +-
 drivers/acpi/acpica/evxfgpe.c| 2 +-
 drivers/acpi/acpica/evxfregn.c   | 2 +-
 drivers/acpi/acpica/exconcat.c   | 2 +-
 drivers/acpi/acpica/exconfig.c   | 2 +-
 drivers/acpi/acpica/exconvrt.c   | 2 +-
 drivers/acpi/acpica/excreate.c   | 2 +-
 drivers/acpi/acpica/exdebug.c| 2 +-
 drivers/acpi/acpica/exdump.c | 2 +-
 drivers/acpi/acpica/exfield.c| 2 +-
 drivers/acpi/acpica/exfldio.c| 2 +-
 drivers/acpi/acpica/exmisc.c   

[PATCH 0/4] ACPICA 20170119 Release

[Lv Zheng]

The 20170119 ACPICA kernel-resident subsystem updates are linuxized based
on the linux-pm/linux-next branch.

The patchset has passed the following build/boot tests.
Build tests are performed as follows:
1. i386 + allyes
2. i386 + allno
3. i386 + default + ACPI_DEBUGGER=y
4. i386 + default + ACPI_DEBUGGER=n + ACPI_DEBUG=y
5. i386 + default + ACPI_DEBUG=n + ACPI=y
6. i386 + default + ACPI=n
7. x86_64 + allyes
8. x86_64 + allno
9. x86_64 + default + ACPI_DEBUGGER=y
10.x86_64 + default + ACPI_DEBUGGER=n + ACPI_DEBUG=y
11.x86_64 + default + ACPI_DEBUG=n + ACPI=y
12.x86_64 + default + ACPI=n
Boot tests are performed as follows:
1. x86_64 + default + ACPI_DEBUGGER=y
Where:
1. i386: machine named as "Dell Inspiron Mini 1010"
2. x86_64: machine named as "Microsoft Surface Pro 3"
3. default: kernel configuration with following items enabled:
   All hardware drivers related to the machines of i386/x86_64
   All "drivers/acpi" configurations
   All "drivers/platform" drivers
   All other drivers that link the APIs provided by ACPICA subsystem

The divergences checking result:
Before applying (20161222 Release):
  369 lines
After applying (20170119 Release):
  369 lines

Bob Moore (3):
  ACPICA: Source tree: Update copyright notices to 2017
  ACPICA: Tools: Update common signon, remove compilation bit width
  ACPICA: Update version to 20170119

Lv Zheng (1):
  ACPICA: Linuxize: Restore and fix intel compiler build

 drivers/acpi/acpica/acapps.h   | 14 ++--
 drivers/acpi/acpica/accommon.h |  2 +-
 drivers/acpi/acpica/acdebug.h  |  2 +-
 drivers/acpi/acpica/acdispat.h |  2 +-
 drivers/acpi/acpica/acevents.h |  2 +-
 drivers/acpi/acpica/acglobal.h |  2 +-
 drivers/acpi/acpica/achware.h  |  2 +-
 drivers/acpi/acpica/acinterp.h |  2 +-
 drivers/acpi/acpica/aclocal.h  |  2 +-
 drivers/acpi/acpica/acmacros.h |  2 +-
 drivers/acpi/acpica/acnamesp.h |  2 +-
 drivers/acpi/acpica/acobject.h |  2 +-
 drivers/acpi/acpica/acopcode.h |  2 +-
 drivers/acpi/acpica/acparser.h |  2 +-
 drivers/acpi/acpica/acpredef.h |  2 +-
 drivers/acpi/acpica/acresrc.h  |  2 +-
 drivers/acpi/acpica/acstruct.h |  2 +-
 drivers/acpi/acpica/actables.h |  2 +-
 drivers/acpi/acpica/acutils.h  |  2 +-
 drivers/acpi/acpica/amlcode.h  |  2 +-
 drivers/acpi/acpica/amlresrc.h |  2 +-
 drivers/acpi/acpica/dbcmds.c   |  2 +-
 drivers/acpi/acpica/dbconvert.c|  2 +-
 drivers/acpi/acpica/dbdisply.c |  2 +-
 drivers/acpi/acpica/dbexec.c   |  2 +-
 drivers/acpi/acpica/dbfileio.c |  2 +-
 drivers/acpi/acpica/dbhistry.c |  2 +-
 drivers/acpi/acpica/dbinput.c  |  2 +-
 drivers/acpi/acpica/dbmethod.c |  2 +-
 drivers/acpi/acpica/dbnames.c  |  2 +-
 drivers/acpi/acpica/dbobject.c |  2 +-
 drivers/acpi/acpica/dbstats.c  |  2 +-
 drivers/acpi/acpica/dbtest.c   |  2 +-
 drivers/acpi/acpica/dbutils.c  |  2 +-
 drivers/acpi/acpica/dbxface.c  |  2 +-
 drivers/acpi/acpica/dsargs.c   |  2 +-
 drivers/acpi/acpica/dscontrol.c|  2 +-
 drivers/acpi/acpica/dsdebug.c  |  2 +-
 drivers/acpi/acpica/dsfield.c  |  2 +-
 drivers/acpi/acpica/dsinit.c   |  2 +-
 drivers/acpi/acpica/dsmethod.c |  2 +-
 drivers/acpi/acpica/dsmthdat.c |  2 +-
 drivers/acpi/acpica/dsobject.c |  2 +-
 drivers/acpi/acpica/dsopcode.c |  2 +-
 drivers/acpi/acpica/dsutils.c  |  2 +-
 drivers/acpi/acpica/dswexec.c  |  2 +-
 drivers/acpi/acpica/dswload.c  |  2 +-
 drivers/acpi/acpica/dswload2.c |  2 +-
 drivers/acpi/acpica/dswscope.c |  2 +-
 drivers/acpi/acpica/dswstate.c |  2 +-
 drivers/acpi/acpica/evevent.c  |  2 +-
 drivers/acpi/acpica/evglock.c  |  2 +-
 drivers/acpi/acpica/evgpe.c|  2 +-
 drivers/acpi/acpica/evgpeblk.c |  2 +-
 drivers/acpi/acpica/evgpeinit.c|  2 +-
 drivers/acpi/acpica/evgpeutil.c|  2 +-
 drivers/acpi/acpica/evhandler.c|  2 +-
 drivers/acpi/acpica/evmisc.c   |  2 +-
 drivers/acpi/acpica/evregion.c |  2 +-
 drivers/acpi/acpica/evrgnini.

Re: [PATCH v2 1/5] bpf: Add missing header to the library

[Wangnan (F)]

Please add me into the cc list of all of the 5 patches.

Thank you.

On 2017/2/7 4:40, Mickaël Salaün wrote:

Include stddef.h to define size_t.

Signed-off-by: Mickaël Salaün 
Cc: Alexei Starovoitov 
Cc: Arnaldo Carvalho de Melo 
Cc: Daniel Borkmann 
Cc: Wang Nan 
---
  tools/lib/bpf/bpf.h | 1 +
  1 file changed, 1 insertion(+)

diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
index a2f9853dd882..df6e186da788 100644
--- a/tools/lib/bpf/bpf.h
+++ b/tools/lib/bpf/bpf.h
@@ -22,6 +22,7 @@
  #define __BPF_BPF_H
  
  #include 

+#include 
  
  int bpf_create_map(enum bpf_map_type map_type, int key_size, int value_size,

   int max_entries, __u32 map_flags);

Re: [PATCH 1/9] virtio_pci: remove struct virtio_pci_vq_info

[Jason Wang]

On 2017年02月07日 17:38, Christoph Hellwig wrote:

On Tue, Feb 07, 2017 at 03:17:02PM +0800, Jason Wang wrote:

The check is still there.

Meh, I could swear I fixed it up.  Here is an updated version:

---
 From bf5e3b7fd272aea32388570503f00d0ab592fc2a Mon Sep 17 00:00:00 2001
From: Christoph Hellwig 
Date: Wed, 25 Jan 2017 13:40:21 +0100
Subject: virtio_pci: remove struct virtio_pci_vq_info

We don't really need struct virtio_pci_vq_info, as most field in there
are redundant:

  - the vq backpointer is not strictly neede to start with
  - the entry in the vqs list is not needed - the generic virtqueue already
has list, we only need to check if it has a callback to get the same
semantics
  - we can use a simple array to look up the MSI-X vec if needed.
  - That simple array now also duoble serves to replace the per_vq_vectors
flag

Signed-off-by: Christoph Hellwig 


Reviewed-by: Jason Wang 


---
  drivers/virtio/virtio_pci_common.c | 117 +++--
  drivers/virtio/virtio_pci_common.h |  25 +---
  drivers/virtio/virtio_pci_legacy.c |   6 +-
  drivers/virtio/virtio_pci_modern.c |   6 +-
  4 files changed, 39 insertions(+), 115 deletions(-)

diff --git a/drivers/virtio/virtio_pci_common.c 
b/drivers/virtio/virtio_pci_common.c
index 186cbab327b8..1f9fac7dad61 100644
--- a/drivers/virtio/virtio_pci_common.c
+++ b/drivers/virtio/virtio_pci_common.c
@@ -62,16 +62,13 @@ static irqreturn_t vp_config_changed(int irq, void *opaque)
  static irqreturn_t vp_vring_interrupt(int irq, void *opaque)
  {
struct virtio_pci_device *vp_dev = opaque;
-   struct virtio_pci_vq_info *info;
irqreturn_t ret = IRQ_NONE;
-   unsigned long flags;
+   struct virtqueue *vq;
  
-	spin_lock_irqsave(&vp_dev->lock, flags);

-   list_for_each_entry(info, &vp_dev->virtqueues, node) {
-   if (vring_interrupt(irq, info->vq) == IRQ_HANDLED)
+   list_for_each_entry(vq, &vp_dev->vdev.vqs, list) {
+   if (vring_interrupt(irq, vq) == IRQ_HANDLED)
ret = IRQ_HANDLED;
}
-   spin_unlock_irqrestore(&vp_dev->lock, flags);
  
  	return ret;

  }
@@ -167,55 +164,6 @@ static int vp_request_msix_vectors(struct virtio_device 
*vdev, int nvectors,
return err;
  }
  
-static struct virtqueue *vp_setup_vq(struct virtio_device *vdev, unsigned index,

-void (*callback)(struct virtqueue *vq),
-const char *name,
-u16 msix_vec)
-{
-   struct virtio_pci_device *vp_dev = to_vp_device(vdev);
-   struct virtio_pci_vq_info *info = kmalloc(sizeof *info, GFP_KERNEL);
-   struct virtqueue *vq;
-   unsigned long flags;
-
-   /* fill out our structure that represents an active queue */
-   if (!info)
-   return ERR_PTR(-ENOMEM);
-
-   vq = vp_dev->setup_vq(vp_dev, info, index, callback, name, msix_vec);
-   if (IS_ERR(vq))
-   goto out_info;
-
-   info->vq = vq;
-   if (callback) {
-   spin_lock_irqsave(&vp_dev->lock, flags);
-   list_add(&info->node, &vp_dev->virtqueues);
-   spin_unlock_irqrestore(&vp_dev->lock, flags);
-   } else {
-   INIT_LIST_HEAD(&info->node);
-   }
-
-   vp_dev->vqs[index] = info;
-   return vq;
-
-out_info:
-   kfree(info);
-   return vq;
-}
-
-static void vp_del_vq(struct virtqueue *vq)
-{
-   struct virtio_pci_device *vp_dev = to_vp_device(vq->vdev);
-   struct virtio_pci_vq_info *info = vp_dev->vqs[vq->index];
-   unsigned long flags;
-
-   spin_lock_irqsave(&vp_dev->lock, flags);
-   list_del(&info->node);
-   spin_unlock_irqrestore(&vp_dev->lock, flags);
-
-   vp_dev->del_vq(info);
-   kfree(info);
-}
-
  /* the config->del_vqs() implementation */
  void vp_del_vqs(struct virtio_device *vdev)
  {
@@ -224,16 +172,15 @@ void vp_del_vqs(struct virtio_device *vdev)
int i;
  
  	list_for_each_entry_safe(vq, n, &vdev->vqs, list) {

-   if (vp_dev->per_vq_vectors) {
-   int v = vp_dev->vqs[vq->index]->msix_vector;
+   if (vp_dev->msix_vector_map) {
+   int v = vp_dev->msix_vector_map[vq->index];
  
  			if (v != VIRTIO_MSI_NO_VECTOR)

free_irq(pci_irq_vector(vp_dev->pci_dev, v),
vq);
}
-   vp_del_vq(vq);
+   vp_dev->del_vq(vq);
}
-   vp_dev->per_vq_vectors = false;
  
  	if (vp_dev->intx_enabled) {

free_irq(vp_dev->pci_dev->irq, vp_dev);
@@ -261,8 +208,8 @@ void vp_del_vqs(struct virtio_device *vdev)
vp_dev->msix_names = NULL;
kfree(vp_dev->msix_affinity_masks);
vp_dev->msix_affinity_masks = NULL;
-   kfree(vp_dev->vqs);
-   vp_dev->vqs = NULL;
+   kfree(vp_dev->msix_vector_map);
+   vp_d

Re: [PATCH v3 1/5] bpf: Add missing header to the library

[Wangnan (F)]

On 2017/2/8 4:56, Mickaël Salaün wrote:

Include stddef.h to define size_t.

Signed-off-by: Mickaël Salaün 
Cc: Alexei Starovoitov 
Cc: Arnaldo Carvalho de Melo 
Cc: Daniel Borkmann 
Cc: Wang Nan 
---
  tools/lib/bpf/bpf.h | 1 +
  1 file changed, 1 insertion(+)

diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
index a2f9853dd882..df6e186da788 100644
--- a/tools/lib/bpf/bpf.h
+++ b/tools/lib/bpf/bpf.h
@@ -22,6 +22,7 @@
  #define __BPF_BPF_H
  
  #include 

+#include 
  
  int bpf_create_map(enum bpf_map_type map_type, int key_size, int value_size,

   int max_entries, __u32 map_flags);

Looks good to me.

Thank you.

Re: [PATCH v2 1/4] Documentation: devicetree: Add document bindings for leds-mt6323

[Andrew Lunn]

> + led0: isink0 {
> + lebel = "LED0"

label, not lebel.

   Andrew

Re: v4.9, 4.4-final: 28 bioset threads on small notebook, 36 threads on cellphone

[Ming Lei]

On Tue, Feb 7, 2017 at 10:49 AM, Kent Overstreet
 wrote:
> On Mon, Feb 06, 2017 at 04:47:24PM -0900, Kent Overstreet wrote:
>> On Mon, Feb 06, 2017 at 01:53:09PM +0100, Pavel Machek wrote:
>> > Still there on v4.9, 36 threads on nokia n900 cellphone.
>> >
>> > So.. what needs to be done there?
>
>> But, I just got an idea for how to handle this that might be halfway sane, 
>> maybe
>> I'll try and come up with a patch...
>
> Ok, here's such a patch, only lightly tested:
>
> -- >8 --
> Subject: [PATCH] block: Make rescuer threads per request_queue, not per bioset
>
> Note: this patch is very lightly tested.
>
> Also, trigger rescuing whenever with bios on current->bio_list, instead
> of only when we block in bio_alloc_bioset(). This is more correct, and
> should result in fewer rescuer threads.

Looks the rescuer stuff gets simplified much with this patch.

>
> XXX: The current->bio_list plugging needs to be unified with the
> blk_plug mechanism.

Yeah, that can be another benefit, :-)

>
> TODO: If we change normal request_queue drivers to handle arbitrary size
> bios by processing requests incrementally, instead of splitting bios,
> then we can get rid of rescuer threads from those devices.

Also the rescue threads are often from some reserved block devices, such as
loop/nbd, and we should have allowed these drivers to delay allocating
the thread
just before the disk is activated. Then the thread number can get descreased
a lot.

> ---
>  block/bio.c| 107 
> -
>  block/blk-core.c   |  58 ---
>  block/blk-sysfs.c  |   2 +
>  include/linux/bio.h|  16 
>  include/linux/blkdev.h |  10 +
>  include/linux/sched.h  |   2 +-
>  kernel/sched/core.c|   4 ++
>  7 files changed, 83 insertions(+), 116 deletions(-)
>
> diff --git a/block/bio.c b/block/bio.c
> index f3b5786202..9ad54a9b12 100644
> --- a/block/bio.c
> +++ b/block/bio.c
> @@ -336,54 +336,6 @@ void bio_chain(struct bio *bio, struct bio *parent)
>  }
>  EXPORT_SYMBOL(bio_chain);
>
> -static void bio_alloc_rescue(struct work_struct *work)
> -{
> -   struct bio_set *bs = container_of(work, struct bio_set, rescue_work);
> -   struct bio *bio;
> -
> -   while (1) {
> -   spin_lock(&bs->rescue_lock);
> -   bio = bio_list_pop(&bs->rescue_list);
> -   spin_unlock(&bs->rescue_lock);
> -
> -   if (!bio)
> -   break;
> -
> -   generic_make_request(bio);
> -   }
> -}
> -
> -static void punt_bios_to_rescuer(struct bio_set *bs)
> -{
> -   struct bio_list punt, nopunt;
> -   struct bio *bio;
> -
> -   /*
> -* In order to guarantee forward progress we must punt only bios that
> -* were allocated from this bio_set; otherwise, if there was a bio on
> -* there for a stacking driver higher up in the stack, processing it
> -* could require allocating bios from this bio_set, and doing that 
> from
> -* our own rescuer would be bad.
> -*
> -* Since bio lists are singly linked, pop them all instead of trying 
> to
> -* remove from the middle of the list:
> -*/
> -
> -   bio_list_init(&punt);
> -   bio_list_init(&nopunt);
> -
> -   while ((bio = bio_list_pop(current->bio_list)))
> -   bio_list_add(bio->bi_pool == bs ? &punt : &nopunt, bio);
> -
> -   *current->bio_list = nopunt;
> -
> -   spin_lock(&bs->rescue_lock);
> -   bio_list_merge(&bs->rescue_list, &punt);
> -   spin_unlock(&bs->rescue_lock);
> -
> -   queue_work(bs->rescue_workqueue, &bs->rescue_work);
> -}
> -
>  /**
>   * bio_alloc_bioset - allocate a bio for I/O
>   * @gfp_mask:   the GFP_ mask given to the slab allocator
> @@ -421,54 +373,27 @@ static void punt_bios_to_rescuer(struct bio_set *bs)
>   */
>  struct bio *bio_alloc_bioset(gfp_t gfp_mask, int nr_iovecs, struct bio_set 
> *bs)
>  {
> -   gfp_t saved_gfp = gfp_mask;
> unsigned front_pad;
> unsigned inline_vecs;
> struct bio_vec *bvl = NULL;
> struct bio *bio;
> void *p;
>
> -   if (!bs) {
> -   if (nr_iovecs > UIO_MAXIOV)
> -   return NULL;
> +   WARN(current->bio_list &&
> +!current->bio_list->q->rescue_workqueue,
> +"allocating bio beneath generic_make_request() without rescuer");
>
> +   if (nr_iovecs > UIO_MAXIOV)
> +   return NULL;
> +
> +   if (!bs) {
> p = kmalloc(sizeof(struct bio) +
> nr_iovecs * sizeof(struct bio_vec),
> gfp_mask);
> front_pad = 0;
> inline_vecs = nr_iovecs;
> } else {
> -   /*
> -* generic_make_request() converts recursion to iteration; 
> this
> -* means if we're running beneath it, any bios we allocate and
> -

Re: [PATCH v3 2/5] bpf: Simplify bpf_load_program() error handling in the library

[Wangnan (F)]

On 2017/2/8 4:56, Mickaël Salaün wrote:

Do not call a second time bpf(2) when a program load failed.


BPF_PROG_LOAD should success most of the time. Setting log_level to
0 by default and require log buffer when failure can make it faster
in normal case.

Thank you.


Signed-off-by: Mickaël Salaün 
Cc: Alexei Starovoitov 
Cc: Arnaldo Carvalho de Melo 
Cc: Daniel Borkmann 
Cc: Wang Nan 
---
  tools/lib/bpf/bpf.c | 18 ++
  1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
index 3ddb58a36d3c..fda3f494f1cd 100644
--- a/tools/lib/bpf/bpf.c
+++ b/tools/lib/bpf/bpf.c
@@ -73,7 +73,6 @@ int bpf_load_program(enum bpf_prog_type type, struct bpf_insn 
*insns,
 size_t insns_cnt, char *license,
 __u32 kern_version, char *log_buf, size_t log_buf_sz)
  {
-   int fd;
union bpf_attr attr;
  
  	bzero(&attr, sizeof(attr));

@@ -81,20 +80,15 @@ int bpf_load_program(enum bpf_prog_type type, struct 
bpf_insn *insns,
attr.insn_cnt = (__u32)insns_cnt;
attr.insns = ptr_to_u64(insns);
attr.license = ptr_to_u64(license);
-   attr.log_buf = ptr_to_u64(NULL);
-   attr.log_size = 0;
-   attr.log_level = 0;
+   attr.log_buf = ptr_to_u64(log_buf);
+   attr.log_size = log_buf_sz;
attr.kern_version = kern_version;
  
-	fd = sys_bpf(BPF_PROG_LOAD, &attr, sizeof(attr));

-   if (fd >= 0 || !log_buf || !log_buf_sz)
-   return fd;
+   if (log_buf && log_buf_sz > 0) {
+   attr.log_level = 1;
+   log_buf[0] = 0;
+   }
  
-	/* Try again with log */

-   attr.log_buf = ptr_to_u64(log_buf);
-   attr.log_size = log_buf_sz;
-   attr.log_level = 1;
-   log_buf[0] = 0;
return sys_bpf(BPF_PROG_LOAD, &attr, sizeof(attr));
  }
  

[PATCH v6 3/6] drm/rockchip/dsi: dw-mipi: correct the coding style

[Chris Zhong]

correct the coding style, according the checkpatch scripts

Signed-off-by: Chris Zhong 
Reviewed-by: Sean Paul 
---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None

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

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 8f60b89..6795190 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -157,7 +157,6 @@
 #define LPRX_TO_CNT(p) ((p) & 0x)
 
 #define DSI_BTA_TO_CNT 0x8c
-
 #define DSI_LPCLK_CTRL 0x94
 #define AUTO_CLKLANE_CTRL  BIT(1)
 #define PHY_TXREQUESTCLKHS BIT(0)
@@ -223,11 +222,11 @@
 
 #define HSFREQRANGE_SEL(val)   (((val) & 0x3f) << 1)
 
-#define INPUT_DIVIDER(val) ((val - 1) & 0x7f)
+#define INPUT_DIVIDER(val) (((val) - 1) & 0x7f)
 #define LOW_PROGRAM_EN 0
 #define HIGH_PROGRAM_ENBIT(7)
-#define LOOP_DIV_LOW_SEL(val)  ((val - 1) & 0x1f)
-#define LOOP_DIV_HIGH_SEL(val) (((val - 1) >> 5) & 0x1f)
+#define LOOP_DIV_LOW_SEL(val)  (((val) - 1) & 0x1f)
+#define LOOP_DIV_HIGH_SEL(val) val) - 1) >> 5) & 0x1f)
 #define PLL_LOOP_DIV_ENBIT(5)
 #define PLL_INPUT_DIV_EN   BIT(4)
 
@@ -369,6 +368,7 @@ static inline struct dw_mipi_dsi *encoder_to_dsi(struct 
drm_encoder *encoder)
 {
return container_of(encoder, struct dw_mipi_dsi, encoder);
 }
+
 static inline void dsi_write(struct dw_mipi_dsi *dsi, u32 reg, u32 val)
 {
writel(val, dsi->base + reg);
@@ -380,7 +380,7 @@ static inline u32 dsi_read(struct dw_mipi_dsi *dsi, u32 reg)
 }
 
 static void dw_mipi_dsi_phy_write(struct dw_mipi_dsi *dsi, u8 test_code,
-u8 test_data)
+ u8 test_data)
 {
/*
 * With the falling edge on TESTCLK, the TESTDIN[7:0] signal content
@@ -496,7 +496,6 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
dsi_write(dsi, DSI_PHY_RSTZ, PHY_ENFORCEPLL | PHY_ENABLECLK |
 PHY_UNRSTZ | PHY_UNSHUTDOWNZ);
 
-
ret = readl_poll_timeout(dsi->base + DSI_PHY_STATUS,
 val, val & LOCK, 1000, PHY_STATUS_TIMEOUT_US);
if (ret < 0) {
@@ -571,7 +570,7 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host 
*host,
 
if (device->lanes > dsi->pdata->max_data_lanes) {
dev_err(dsi->dev, "the number of data lanes(%u) is too many\n",
-   device->lanes);
+   device->lanes);
return -EINVAL;
}
 
@@ -1060,14 +1059,14 @@ dw_mipi_dsi_encoder_atomic_check(struct drm_encoder 
*encoder,
return 0;
 }
 
-static struct drm_encoder_helper_funcs
+static const struct drm_encoder_helper_funcs
 dw_mipi_dsi_encoder_helper_funcs = {
.enable = dw_mipi_dsi_encoder_enable,
.disable = dw_mipi_dsi_encoder_disable,
.atomic_check = dw_mipi_dsi_encoder_atomic_check,
 };
 
-static struct drm_encoder_funcs dw_mipi_dsi_encoder_funcs = {
+static const struct drm_encoder_funcs dw_mipi_dsi_encoder_funcs = {
.destroy = drm_encoder_cleanup,
 };
 
@@ -1103,7 +1102,7 @@ static void dw_mipi_dsi_drm_connector_destroy(struct 
drm_connector *connector)
drm_connector_cleanup(connector);
 }
 
-static struct drm_connector_funcs dw_mipi_dsi_atomic_connector_funcs = {
+static const struct drm_connector_funcs dw_mipi_dsi_atomic_connector_funcs = {
.dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = dw_mipi_dsi_drm_connector_destroy,
@@ -1113,7 +1112,7 @@ static struct drm_connector_funcs 
dw_mipi_dsi_atomic_connector_funcs = {
 };
 
 static int dw_mipi_dsi_register(struct drm_device *drm,
- struct dw_mipi_dsi *dsi)
+   struct dw_mipi_dsi *dsi)
 {
struct drm_encoder *encoder = &dsi->encoder;
struct drm_connector *connector = &dsi->connector;
@@ -1134,14 +1133,14 @@ static int dw_mipi_dsi_register(struct drm_device *drm,
drm_encoder_helper_add(&dsi->encoder,
   &dw_mipi_dsi_encoder_helper_funcs);
ret = drm_encoder_init(drm, &dsi->encoder, &dw_mipi_dsi_encoder_funcs,
-DRM_MODE_ENCODER_DSI, NULL);
+  DRM_MODE_ENCODER_DSI, NULL);
if (ret) {
dev_err(dev, "Failed to initialize encoder with drm\n");
return ret;
}
 
drm_connector_helper_add(connector,
-   &dw_mipi_dsi_connector_helper_funcs);
+&dw_mipi_dsi_connector_helper_funcs);
 
drm_connector_init(drm, &dsi->connector,
   &dw_mipi_dsi_atomic_connector_funcs,
@@ -1

[PATCH v6 5/6] dt-bindings: add power domain node for dw-mipi-rockchip

[Chris Zhong]

Signed-off-by: Chris Zhong 
Acked-by: Rob Herring 
---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None

 .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt  | 3 +++
 1 file changed, 3 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
index 0f82568..188f6f7 100644
--- 
a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
+++ 
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
@@ -15,6 +15,9 @@ Required properties:
 - ports: contain a port node with endpoint definitions as defined in [2].
   For vopb,set the reg = <0> and set the reg = <1> for vopl.
 
+Optional properties:
+- power-domains: a phandle to mipi dsi power domain node.
+
 [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
 [2] Documentation/devicetree/bindings/media/video-interfaces.txt
 
-- 
2.6.3

[PATCH v6 6/6] drm/rockchip/dsi: add dw-mipi power domain support

[Chris Zhong]

Reference the power domain incase dw-mipi power down when
in use.

Signed-off-by: Chris Zhong 
Reviewed-by: Sean Paul 
---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None

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

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index a2b4ec4..2ee2317 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -293,6 +294,7 @@ struct dw_mipi_dsi {
struct clk *pclk;
struct clk *phy_cfg_clk;
 
+   int dpms_mode;
unsigned int lane_mbps; /* per lane */
u32 channel;
u32 lanes;
@@ -960,6 +962,9 @@ static void dw_mipi_dsi_encoder_disable(struct drm_encoder 
*encoder)
 {
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
 
+   if (dsi->dpms_mode != DRM_MODE_DPMS_ON)
+   return;
+
if (clk_prepare_enable(dsi->pclk)) {
dev_err(dsi->dev, "%s: Failed to enable pclk\n", __func__);
return;
@@ -971,7 +976,9 @@ static void dw_mipi_dsi_encoder_disable(struct drm_encoder 
*encoder)
drm_panel_unprepare(dsi->panel);
 
dw_mipi_dsi_disable(dsi);
+   pm_runtime_put(dsi->dev);
clk_disable_unprepare(dsi->pclk);
+   dsi->dpms_mode = DRM_MODE_DPMS_OFF;
 }
 
 static void dw_mipi_dsi_encoder_enable(struct drm_encoder *encoder)
@@ -987,11 +994,15 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder 
*encoder)
if (ret < 0)
return;
 
+   if (dsi->dpms_mode == DRM_MODE_DPMS_ON)
+   return;
+
if (clk_prepare_enable(dsi->pclk)) {
dev_err(dsi->dev, "%s: Failed to enable pclk\n", __func__);
return;
}
 
+   pm_runtime_get_sync(dsi->dev);
dw_mipi_dsi_init(dsi);
dw_mipi_dsi_dpi_config(dsi, mode);
dw_mipi_dsi_packet_handler_config(dsi);
@@ -1027,6 +1038,7 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder 
*encoder)
 
regmap_write(dsi->grf_regmap, pdata->grf_switch_reg, val);
dev_dbg(dsi->dev, "vop %s output to dsi0\n", (mux) ? "LIT" : "BIG");
+   dsi->dpms_mode = DRM_MODE_DPMS_ON;
 }
 
 static int
@@ -1194,6 +1206,7 @@ static int dw_mipi_dsi_bind(struct device *dev, struct 
device *master,
 
dsi->dev = dev;
dsi->pdata = pdata;
+   dsi->dpms_mode = DRM_MODE_DPMS_OFF;
 
ret = rockchip_mipi_parse_dt(dsi);
if (ret)
@@ -1274,6 +1287,8 @@ static int dw_mipi_dsi_bind(struct device *dev, struct 
device *master,
 
dev_set_drvdata(dev, dsi);
 
+   pm_runtime_enable(dev);
+
dsi->dsi_host.ops = &dw_mipi_dsi_host_ops;
dsi->dsi_host.dev = dev;
ret = mipi_dsi_host_register(&dsi->dsi_host);
@@ -1296,6 +1311,7 @@ static void dw_mipi_dsi_unbind(struct device *dev, struct 
device *master,
struct dw_mipi_dsi *dsi = dev_get_drvdata(dev);
 
mipi_dsi_host_unregister(&dsi->dsi_host);
+   pm_runtime_disable(dev);
clk_disable_unprepare(dsi->pllref_clk);
 }
 
-- 
2.6.3

[PATCH v6 1/6] dt-bindings: add rk3399 support for dw-mipi-rockchip

[Chris Zhong]

The dw-mipi-dsi of rk3399 is almost the same as rk3288, the rk3399 has
additional phy config clock.

Signed-off-by: Chris Zhong 
Acked-by: Rob Herring 
---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None

 .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
index 1753f0c..0f82568 100644
--- 
a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
+++ 
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
@@ -5,10 +5,12 @@ Required properties:
 - #address-cells: Should be <1>.
 - #size-cells: Should be <0>.
 - compatible: "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi".
+ "rockchip,rk3399-mipi-dsi", "snps,dw-mipi-dsi".
 - reg: Represent the physical address range of the controller.
 - interrupts: Represent the controller's interrupt to the CPU(s).
 - clocks, clock-names: Phandles to the controller's pll reference
-  clock(ref) and APB clock(pclk), as described in [1].
+  clock(ref) and APB clock(pclk). For RK3399, a phy config clock
+  (phy_cfg) is additional required. As described in [1].
 - rockchip,grf: this soc should set GRF regs to mux vopl/vopb.
 - ports: contain a port node with endpoint definitions as defined in [2].
   For vopb,set the reg = <0> and set the reg = <1> for vopl.
-- 
2.6.3

[PATCH v6 2/6] drm/rockchip/dsi: dw-mipi: support RK3399 mipi dsi

[Chris Zhong]

The vopb/vopl switch register of RK3399 mipi is different from RK3288,
the default setting for mipi dsi mode is different too, so add a
of_device_id structure to distinguish them, and make sure set the
correct mode before mipi phy init.

Signed-off-by: Chris Zhong 
Signed-off-by: Mark Yao 

---

Changes in v6:
- no need check phy_cfg_clk before enable/disable

Changes in v5:
- check the error of phy_cfg_clk in dw_mipi_dsi_bind

Changes in v4:
- remove the unrelated change

Changes in v3:
- base on John Keeping's patch series

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

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 3f24333..8f60b89 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -29,9 +29,17 @@
 
 #define DRIVER_NAME"dw-mipi-dsi"
 
-#define GRF_SOC_CON60x025c
-#define DSI0_SEL_VOP_LIT(1 << 6)
-#define DSI1_SEL_VOP_LIT(1 << 9)
+#define RK3288_GRF_SOC_CON60x025c
+#define RK3288_DSI0_SEL_VOP_LITBIT(6)
+#define RK3288_DSI1_SEL_VOP_LITBIT(9)
+
+#define RK3399_GRF_SOC_CON19   0x6250
+#define RK3399_DSI0_SEL_VOP_LITBIT(0)
+#define RK3399_DSI1_SEL_VOP_LITBIT(4)
+
+/* disable turnrequest, turndisable, forcetxstopmode, forcerxmode */
+#define RK3399_GRF_SOC_CON22   0x6258
+#define RK3399_GRF_DSI_MODE0x
 
 #define DSI_VERSION0x00
 #define DSI_PWR_UP 0x04
@@ -265,6 +273,11 @@ enum {
 };
 
 struct dw_mipi_dsi_plat_data {
+   u32 dsi0_en_bit;
+   u32 dsi1_en_bit;
+   u32 grf_switch_reg;
+   u32 grf_dsi0_mode;
+   u32 grf_dsi0_mode_reg;
unsigned int max_data_lanes;
enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
   struct drm_display_mode *mode);
@@ -281,6 +294,7 @@ struct dw_mipi_dsi {
 
struct clk *pllref_clk;
struct clk *pclk;
+   struct clk *phy_cfg_clk;
 
unsigned int lane_mbps; /* per lane */
u32 channel;
@@ -425,6 +439,12 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
dsi_write(dsi, DSI_PHY_TST_CTRL0, PHY_TESTCLR);
dsi_write(dsi, DSI_PHY_TST_CTRL0, PHY_UNTESTCLR);
 
+   ret = clk_prepare_enable(dsi->phy_cfg_clk);
+   if (ret) {
+   dev_err(dsi->dev, "Failed to enable phy_cfg_clk\n");
+   return ret;
+   }
+
dw_mipi_dsi_phy_write(dsi, 0x10, BYPASS_VCO_RANGE |
 VCO_RANGE_CON_SEL(vco) |
 VCO_IN_CAP_CON_LOW |
@@ -481,17 +501,18 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
 val, val & LOCK, 1000, PHY_STATUS_TIMEOUT_US);
if (ret < 0) {
dev_err(dsi->dev, "failed to wait for phy lock state\n");
-   return ret;
+   goto phy_init_end;
}
 
ret = readl_poll_timeout(dsi->base + DSI_PHY_STATUS,
 val, val & STOP_STATE_CLK_LANE, 1000,
 PHY_STATUS_TIMEOUT_US);
-   if (ret < 0) {
+   if (ret < 0)
dev_err(dsi->dev,
"failed to wait for phy clk lane stop state\n");
-   return ret;
-   }
+
+phy_init_end:
+   clk_disable_unprepare(dsi->phy_cfg_clk);
 
return ret;
 }
@@ -960,6 +981,7 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder 
*encoder)
 {
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
+   const struct dw_mipi_dsi_plat_data *pdata = dsi->pdata;
int mux = drm_of_encoder_active_endpoint_id(dsi->dev->of_node, encoder);
u32 val;
int ret;
@@ -985,6 +1007,10 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder 
*encoder)
dw_mipi_dsi_dphy_interface_config(dsi);
dw_mipi_dsi_clear_err(dsi);
 
+   if (pdata->grf_dsi0_mode_reg)
+   regmap_write(dsi->grf_regmap, pdata->grf_dsi0_mode_reg,
+pdata->grf_dsi0_mode);
+
dw_mipi_dsi_phy_init(dsi);
dw_mipi_dsi_wait_for_two_frames(mode);
 
@@ -998,11 +1024,11 @@ static void dw_mipi_dsi_encoder_enable(struct 
drm_encoder *encoder)
clk_disable_unprepare(dsi->pclk);
 
if (mux)
-   val = DSI0_SEL_VOP_LIT | (DSI0_SEL_VOP_LIT << 16);
+   val = pdata->dsi0_en_bit | (pdata->dsi0_en_bit << 16);
else
-   val = DSI0_SEL_VOP_LIT << 16;
+   val = pdata->dsi0_en_bit << 16;
 
-   regmap_write(dsi->grf_regmap, GRF_SOC_CON6, val);
+   regmap_write(dsi->grf_regmap, pdata->grf_switch_reg, val);
dev_dbg(dsi-

[PATCH v2 2/4] Documentation: devicetree: Add LED subnode binding for MT6323 PMIC

[sean.wang]

From: Sean Wang 

This patch adds documentation for devicetree bindings
for LED support as the subnode of MT6323 PMIC

Signed-off-by: Sean Wang 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/mfd/mt6397.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt 
b/Documentation/devicetree/bindings/mfd/mt6397.txt
index 949c85f..c568d52 100644
--- a/Documentation/devicetree/bindings/mfd/mt6397.txt
+++ b/Documentation/devicetree/bindings/mfd/mt6397.txt
@@ -34,6 +34,10 @@ Optional subnodes:
 - clk
Required properties:
- compatible: "mediatek,mt6397-clk"
+- led
+   Required properties:
+   - compatible: "mediatek,mt6323-led"
+   see Documentation/devicetree/bindings/leds/leds-mt6323.txt
 
 Example:
pwrap: pwrap@1000f000 {
-- 
1.9.1

[PATCH v2 1/4] Documentation: devicetree: Add document bindings for leds-mt6323

[sean.wang]

From: Sean Wang 

This patch adds documentation for devicetree bindings
for LED support on MT6323 PMIC

Signed-off-by: Sean Wang 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/leds/leds-mt6323.txt   | 60 ++
 1 file changed, 60 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/leds/leds-mt6323.txt

diff --git a/Documentation/devicetree/bindings/leds/leds-mt6323.txt 
b/Documentation/devicetree/bindings/leds/leds-mt6323.txt
new file mode 100644
index 000..82bbf0c
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-mt6323.txt
@@ -0,0 +1,60 @@
+Device Tree Bindings for LED support on MT6323 PMIC
+
+MT6323 LED controller is subfunction provided by
+MT6323 PMIC, so the LED controller are defined as
+the subnode of the function node provided by MT6323
+PMIC controller that is being defined as one kind of
+Muti-Function Device (MFD) using shared bus called
+PMIC wrapper for each subfunction to access remote
+MT6323 PMIC hardware.
+
+For MT6323 MFD bindings see:
+Documentation/devicetree/bindings/mfd/mt6397.txt
+For MediaTek PMIC wrapper bindings see:
+Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
+
+There's sub-node for the LED controller that describes
+the initial behavior for each LED physcially and currently
+only four LED sub-nodes could be supported.
+
+Required properties:
+- compatible : must be "mediatek,mt6323-led"
+
+Optional properties:
+- label : (optional)
+  see Documentation/devicetree/bindings/leds/common.txt
+- linux,default-trigger : (optional)
+  see Documentation/devicetree/bindings/leds/common.txt
+- default-state: (optional) The initial state of the LED
+  see Documentation/devicetree/bindings/leds/common.txt
+
+Example:
+
+&pwrap {
+   pmic: mt6323 {
+   compatible = "mediatek,mt6323";
+   interrupt-parent = <&pio>;
+   interrupts = <150 IRQ_TYPE_LEVEL_HIGH>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+
+   mt6323led: mt6323led{
+   compatible = "mediatek,mt6323-led";
+
+   led0: isink0 {
+   lebel = "LED0"
+   linux,default-trigger = "timer";
+   default-state = "on";
+   };
+   led1: isink1 {
+   label = "LED1";
+   default-state = "on";
+   };
+   led2: isink2 {
+   label = "LED2";
+   linux,default-trigger = "timer";
+   default-state = "off";
+   };
+   };
+   };
+};
-- 
1.9.1

[PATCH v2 4/4] mfd: mt6397: Add MT6323 LED support into MT6397 driver

[sean.wang]

From: Sean Wang 

Add compatible string as "mt6323-led" that will make
the OF core spawn child devices for the LED subnode
of that MT6323 MFD device.

Signed-off-by: Sean Wang 
---
 drivers/mfd/mt6397-core.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
index e14d8b0..8e601c8 100644
--- a/drivers/mfd/mt6397-core.c
+++ b/drivers/mfd/mt6397-core.c
@@ -48,6 +48,10 @@
.name = "mt6323-regulator",
.of_compatible = "mediatek,mt6323-regulator"
},
+   {
+   .name = "mt6323-led",
+   .of_compatible = "mediatek,mt6323-led"
+   },
 };
 
 static const struct mfd_cell mt6397_devs[] = {
-- 
1.9.1

[PATCH v6 0/6] Rockchip dw-mipi-dsi driver

[Chris Zhong]

Hi all

This patch serial is for RK3399 MIPI DSI. The MIPI DSI controller of
RK3399 is almost the same as RK3288, except a little bit of difference
in phy clock controlling and port id selection register. These patches
add RK3399 support and the power domain support.

And these patches base on John Keeping's v3 patches[0], it fixes many bugs,
they have been tested on rk3288 evb board.

[0]:
[01/24] https://patchwork.kernel.org/patch/9544089
[02/24] https://patchwork.kernel.org/patch/9544061
[03/24] https://patchwork.kernel.org/patch/9544065
[04/24] https://patchwork.kernel.org/patch/9544077
[05/24] https://patchwork.kernel.org/patch/9544033
[06/24] https://patchwork.kernel.org/patch/9544037
[07/24] https://patchwork.kernel.org/patch/9544029
[08/24] https://patchwork.kernel.org/patch/9544031
[09/24] https://patchwork.kernel.org/patch/9544083
[10/24] https://patchwork.kernel.org/patch/9544063
[11/24] https://patchwork.kernel.org/patch/9544085
[12/24] https://patchwork.kernel.org/patch/9544093
[13/24] https://patchwork.kernel.org/patch/9544081
[14/24] https://patchwork.kernel.org/patch/9544057
[15/24] https://patchwork.kernel.org/patch/9544079
[16/24] https://patchwork.kernel.org/patch/9544035
[17/24] https://patchwork.kernel.org/patch/9544105
[18/24] https://patchwork.kernel.org/patch/9544059
[21/24] https://patchwork.kernel.org/patch/9544009
[22/24] https://patchwork.kernel.org/patch/9544049
[23/24] https://patchwork.kernel.org/patch/9544055
[24/24] https://patchwork.kernel.org/patch/9544109


Changes in v6:
- no need check phy_cfg_clk before enable/disable

Changes in v5:
- check the error of phy_cfg_clk in dw_mipi_dsi_bind

Changes in v4:
- remove the unrelated change

Changes in v3:
- base on John Keeping's patch series

Chris Zhong (6):
  dt-bindings: add rk3399 support for dw-mipi-rockchip
  drm/rockchip/dsi: dw-mipi: support RK3399 mipi dsi
  drm/rockchip/dsi: dw-mipi: correct the coding style
  drm/rockchip/dsi: remove mode_valid function
  dt-bindings: add power domain node for dw-mipi-rockchip
  drm/rockchip/dsi: add dw-mipi power domain support

 .../display/rockchip/dw_mipi_dsi_rockchip.txt  |   7 +-
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 156 -
 2 files changed, 98 insertions(+), 65 deletions(-)

-- 
2.6.3

[PATCH v6 4/6] drm/rockchip/dsi: remove mode_valid function

[Chris Zhong]

The MIPI DSI do not need check the validity of resolution, the max
resolution should depend VOP. Hence, remove rk3288_mipi_dsi_mode_valid
here.

Signed-off-by: Chris Zhong 
---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None

 drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 39 --
 1 file changed, 39 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 6795190..a2b4ec4 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -278,8 +278,6 @@ struct dw_mipi_dsi_plat_data {
u32 grf_dsi0_mode;
u32 grf_dsi0_mode_reg;
unsigned int max_data_lanes;
-   enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
-  struct drm_display_mode *mode);
 };
 
 struct dw_mipi_dsi {
@@ -1077,23 +1075,8 @@ static int dw_mipi_dsi_connector_get_modes(struct 
drm_connector *connector)
return drm_panel_get_modes(dsi->panel);
 }
 
-static enum drm_mode_status dw_mipi_dsi_mode_valid(
-   struct drm_connector *connector,
-   struct drm_display_mode *mode)
-{
-   struct dw_mipi_dsi *dsi = con_to_dsi(connector);
-
-   enum drm_mode_status mode_status = MODE_OK;
-
-   if (dsi->pdata->mode_valid)
-   mode_status = dsi->pdata->mode_valid(connector, mode);
-
-   return mode_status;
-}
-
 static struct drm_connector_helper_funcs dw_mipi_dsi_connector_helper_funcs = {
.get_modes = dw_mipi_dsi_connector_get_modes,
-   .mode_valid = dw_mipi_dsi_mode_valid,
 };
 
 static void dw_mipi_dsi_drm_connector_destroy(struct drm_connector *connector)
@@ -1164,33 +1147,11 @@ static int rockchip_mipi_parse_dt(struct dw_mipi_dsi 
*dsi)
return 0;
 }
 
-static enum drm_mode_status rk3288_mipi_dsi_mode_valid(
-   struct drm_connector *connector,
-   struct drm_display_mode *mode)
-{
-   /*
-* The VID_PKT_SIZE field in the DSI_VID_PKT_CFG
-* register is 11-bit.
-*/
-   if (mode->hdisplay > 0x7ff)
-   return MODE_BAD_HVALUE;
-
-   /*
-* The V_ACTIVE_LINES field in the DSI_VTIMING_CFG
-* register is 11-bit.
-*/
-   if (mode->vdisplay > 0x7ff)
-   return MODE_BAD_VVALUE;
-
-   return MODE_OK;
-}
-
 static struct dw_mipi_dsi_plat_data rk3288_mipi_dsi_drv_data = {
.dsi0_en_bit = RK3288_DSI0_SEL_VOP_LIT,
.dsi1_en_bit = RK3288_DSI1_SEL_VOP_LIT,
.grf_switch_reg = RK3288_GRF_SOC_CON6,
.max_data_lanes = 4,
-   .mode_valid = rk3288_mipi_dsi_mode_valid,
 };
 
 static struct dw_mipi_dsi_plat_data rk3399_mipi_dsi_drv_data = {
-- 
2.6.3

[PATCH v2 3/4] leds: Add LED support for MT6323 PMIC

[sean.wang]

From: Sean Wang 

MT6323 PMIC is a multi-function device that includes
LED function. It allows attaching upto 4 LEDs which can
either be on, off or dimmed and/or blinked with the the
controller.

Signed-off-by: Sean Wang 
---
 drivers/leds/Kconfig   |   8 +
 drivers/leds/Makefile  |   1 +
 drivers/leds/leds-mt6323.c | 464 +
 3 files changed, 473 insertions(+)
 create mode 100644 drivers/leds/leds-mt6323.c

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index c621cbb..30095fc 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -117,6 +117,14 @@ config LEDS_MIKROTIK_RB532
  This option enables support for the so called "User LED" of
  Mikrotik's Routerboard 532.
 
+config LEDS_MT6323
+   tristate "LED Support for Mediatek MT6323 PMIC"
+   depends on LEDS_CLASS
+   depends on MFD_MT6397
+   help
+ This option enables support for on-chip LED drivers found on
+ Mediatek MT6323 PMIC.
+
 config LEDS_S3C24XX
tristate "LED Support for Samsung S3C24XX GPIO LEDs"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 6b82737..4feb332 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -72,6 +72,7 @@ obj-$(CONFIG_LEDS_IS31FL32XX) += leds-is31fl32xx.o
 obj-$(CONFIG_LEDS_PM8058)  += leds-pm8058.o
 obj-$(CONFIG_LEDS_MLXCPLD) += leds-mlxcpld.o
 obj-$(CONFIG_LEDS_NIC78BX) += leds-nic78bx.o
+obj-$(CONFIG_LEDS_MT6323)  += leds-mt6323.o
 
 # LED SPI Drivers
 obj-$(CONFIG_LEDS_DAC124S085)  += leds-dac124s085.o
diff --git a/drivers/leds/leds-mt6323.c b/drivers/leds/leds-mt6323.c
new file mode 100644
index 000..f6eeb6c
--- /dev/null
+++ b/drivers/leds/leds-mt6323.c
@@ -0,0 +1,464 @@
+/*
+ * LED driver for Mediatek MT6323 PMIC
+ *
+ * Copyright (C) 2017 Sean Wang 
+ *
+ * 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 
+
+/*
+ * Register field for MT6323_TOP_CKPDN0 to enable
+ * 32K clock common for LED device
+ */
+#define MT6323_RG_DRV_32K_CK_PDN   BIT(11)
+#define MT6323_RG_DRV_32K_CK_PDN_MASK  BIT(11)
+
+/*
+ * Register field for MT6323_TOP_CKPDN2 to enable
+ * individual clock for LED device
+ */
+#define MT6323_RG_ISINK_CK_PDN(i)  BIT(i)
+#define MT6323_RG_ISINK_CK_PDN_MASK(i) BIT(i)
+
+/*
+ * Register field for MT6323_TOP_CKCON1 to select
+ * clock source
+ */
+#define MT6323_RG_ISINK_CK_SEL_MASK(i) (BIT(10) << (i))
+
+/*
+ * Register for MT6323_ISINK_CON0 to setup the
+ * duty cycle of the blink
+ */
+#define MT6323_ISINK_CON0(i)   (MT6323_ISINK0_CON0 + 0x8 * (i))
+#define MT6323_ISINK_DIM_DUTY_MASK (0x1f << 8)
+#define MT6323_ISINK_DIM_DUTY(i)   (((i) << 8) & \
+   MT6323_ISINK_DIM_DUTY_MASK)
+
+/*
+ * Register to setup the period of the blink
+ */
+#define MT6323_ISINK_CON1(i)   (MT6323_ISINK0_CON1 + 0x8 * (i))
+#define MT6323_ISINK_DIM_FSEL_MASK (0x)
+#define MT6323_ISINK_DIM_FSEL(i)   ((i) & MT6323_ISINK_DIM_FSEL_MASK)
+
+/*
+ * Register to control the brightness
+ */
+#define MT6323_ISINK_CON2(i)   (MT6323_ISINK0_CON2 + 0x8 * (i))
+#define MT6323_ISINK_CH_STEP_SHIFT 12
+#define MT6323_ISINK_CH_STEP_MASK  (0x7 << 12)
+#define MT6323_ISINK_CH_STEP(i)(((i) << 12) & \
+   MT6323_ISINK_CH_STEP_MASK)
+#define MT6323_ISINK_SFSTR0_TC_MASK(0x3 << 1)
+#define MT6323_ISINK_SFSTR0_TC(i)  (((i) << 1) & \
+   MT6323_ISINK_SFSTR0_TC_MASK)
+#define MT6323_ISINK_SFSTR0_EN_MASKBIT(0)
+#define MT6323_ISINK_SFSTR0_EN BIT(0)
+
+/*
+ * Register to LED channel enablement
+ */
+#define MT6323_ISINK_CH_EN_MASK(i) BIT(i)
+#define MT6323_ISINK_CH_EN(i)  BIT(i)
+
+#define MTK_MAX_PERIOD   1
+#define MTK_MAX_DEVICES  4
+#define MTK_MAX_BRIGHTNESS   6
+#define MTK_UNIT_DUTY 3125
+
+struct mtk_leds;
+
+/**
+ * struct mtk_led - state container for the LED device
+ * @id: the identifier in MT6323 LED device
+ * @parent: the pointer to MT6323 LED controller
+ * @cdev: LED class device for this LED device
+ * @current_brightness: current state of the LED device
+ */
+struct mtk_led {
+   intid;
+   struct mtk_leds *parent;
+   struct led_classdev cdev;
+   u8 current

[PATCH v2 0/4] leds: add leds-mt6323 support on MT7623 SoC

[sean.wang]

From: Sean Wang 

MT7623 SoC uses MT6323 PMIC as the default power supply
which has LED function insides. The patchset introduces
the LED support for MT6323 with on, off and hardware
dimmed and blinked and it should work on other similar
SoCs if also using MT6323.

Changes since v1:
All changes only within 0003-leds-Add-LED-support-for-MT6323-PMIC.patch, 
including below items
- fixed typo in the comments
- sorted include directives alphabetically
- applied all register definitions with MT6323 prefix
- removed the redundant structure declaration
- fixed coding style defined in kernel doc format consistently
- added error handling into all the occurrences where regmap APIs
  are used
- removed loudly debug message
- made magic constant into meaningful macro
- added missing mutex_destroy when module removed called
- updated module license with GPL
- fixed sparse warnings


Sean Wang (4):
  Documentation: devicetree: Add document bindings for leds-mt6323
  Documentation: devicetree: Add LED subnode binding for MT6323 PMIC
  leds: Add LED support for MT6323 PMIC
  mfd: mt6397: Add MT6323 LED support into MT6397 driver

 .../devicetree/bindings/leds/leds-mt6323.txt   |  60 +++
 Documentation/devicetree/bindings/mfd/mt6397.txt   |   4 +
 drivers/leds/Kconfig   |   8 +
 drivers/leds/Makefile  |   1 +
 drivers/leds/leds-mt6323.c | 464 +
 drivers/mfd/mt6397-core.c  |   4 +
 6 files changed, 541 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/leds/leds-mt6323.txt
 create mode 100644 drivers/leds/leds-mt6323.c

-- 
1.9.1

Re: [PATCH v3 2/4] BMIPS: Enable prerequisites for CPUfreq in MIPS Kconfig.

[Florian Fainelli]

On 02/07/2017 01:58 PM, Markus Mayer wrote:
> From: Markus Mayer 
> 
> Turn on CPU_SUPPORTS_CPUFREQ and MIPS_EXTERNAL_TIMER for BMIPS.
> 
> Signed-off-by: Markus Mayer 

Acked-by: Florian Fainelli 
-- 
Florian

Re: [PATCH v3 3/4] cpufreq: bmips-cpufreq: CPUfreq driver for Broadcom's BMIPS SoCs

[Florian Fainelli]

On 02/07/2017 01:58 PM, Markus Mayer wrote:
> From: Markus Mayer 
> 
> Add the MIPS CPUfreq driver. This driver currently supports CPUfreq on
> BMIPS5xxx-based SoCs.
> 
> Signed-off-by: Markus Mayer 

Acked-by: Florian Fainelli 
-- 
Florian

[PATCH v2] [media] mtk-vcodec: fix build errors without DEBUG

[Minghsiu Tsai]

After removing DEBUG from mtk_vcodec_util.h, some build errors are
generated as the following:
.../drivers/media/platform/mtk-vcodec/vdec_vpu_if.c: In function 
'vcodec_vpu_send_msg':
.../drivers/media/platform/mtk-vcodec/vdec_vpu_if.c:73:11: warning: unused 
variable 'msg_id' [-Wunused-variable]
  uint32_t msg_id = *(uint32_t *)msg;
   ^
.../drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c: In function 
'vb2ops_vdec_buf_queue':
.../drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c:1129:7: warning: unused 
variable 'log_level' [-Wunused-variable]
   int log_level = ret ? 0 : 1;
   ^
.../drivers/media/platform/mtk-vcodec/venc_vpu_if.c: In function 
'vpu_enc_send_msg':
.../drivers/media/platform/mtk-vcodec/venc_vpu_if.c:82:12: warning: unused 
variable 'msg_id' [-Wunused-variable]
   uint32_t msg_id = *(uint32_t *)msg;
^

It is because mtk_vcodec_debug() and mtk_vcodec_err() are defined as empty
macros. Without DEBUG definition, the variable for debugging is not used
anymore. Fixing build errors is just by moving the assignment of the
variable to the argument of mtk_vcodec_debug() and mtk_vcodec_err().
Within the patch, build pass with/without DEBUG definition, and functions
still work fine.

Signed-off-by: Minghsiu Tsai 
Reviewed-by: Daniel Kurtz 
---
Changes in v2:
. Update commit message
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 9 -
 drivers/media/platform/mtk-vcodec/vdec_vpu_if.c| 5 ++---
 drivers/media/platform/mtk-vcodec/venc_vpu_if.c| 4 +---
 3 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index 0746592..6219c7d 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -1126,15 +1126,14 @@ static void vb2ops_vdec_buf_queue(struct vb2_buffer *vb)
 * if there is no SPS header or picture info
 * in bs
 */
-   int log_level = ret ? 0 : 1;
 
src_buf = v4l2_m2m_src_buf_remove(ctx->m2m_ctx);
v4l2_m2m_buf_done(to_vb2_v4l2_buffer(src_buf),
VB2_BUF_STATE_DONE);
-   mtk_v4l2_debug(log_level,
-   "[%d] vdec_if_decode() src_buf=%d, size=%zu, 
fail=%d, res_chg=%d",
-   ctx->id, src_buf->index,
-   src_mem.size, ret, res_chg);
+   mtk_v4l2_debug(ret ? 0 : 1,
+  "[%d] vdec_if_decode() src_buf=%d, size=%zu, 
fail=%d, res_chg=%d",
+  ctx->id, src_buf->index,
+  src_mem.size, ret, res_chg);
return;
}
 
diff --git a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c 
b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
index 5a24c51..1abd14e 100644
--- a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
+++ b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
@@ -70,9 +70,8 @@ void vpu_dec_ipi_handler(void *data, unsigned int len, void 
*priv)
 static int vcodec_vpu_send_msg(struct vdec_vpu_inst *vpu, void *msg, int len)
 {
int err;
-   uint32_t msg_id = *(uint32_t *)msg;
 
-   mtk_vcodec_debug(vpu, "id=%X", msg_id);
+   mtk_vcodec_debug(vpu, "id=%X", *(uint32_t *)msg);
 
vpu->failure = 0;
vpu->signaled = 0;
@@ -80,7 +79,7 @@ static int vcodec_vpu_send_msg(struct vdec_vpu_inst *vpu, 
void *msg, int len)
err = vpu_ipi_send(vpu->dev, vpu->id, msg, len);
if (err) {
mtk_vcodec_err(vpu, "send fail vpu_id=%d msg_id=%X status=%d",
-  vpu->id, msg_id, err);
+  vpu->id, *(uint32_t *)msg, err);
return err;
}
 
diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c 
b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
index a01c759..0d882ac 100644
--- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
+++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
@@ -79,10 +79,8 @@ static int vpu_enc_send_msg(struct venc_vpu_inst *vpu, void 
*msg,
 
status = vpu_ipi_send(vpu->dev, vpu->id, msg, len);
if (status) {
-   uint32_t msg_id = *(uint32_t *)msg;
-
mtk_vcodec_err(vpu, "vpu_ipi_send msg_id %x len %d fail %d",
-  msg_id, len, status);
+  *(uint32_t *)msg, len, status);
return -EINVAL;
}
if (vpu->failure)
-- 
1.9.1

[PATCH v3 2/2] sierra_net: Skip validating irrelevant fields for IDLE LSIs

[Stefan Brüns]

When the context is deactivated, the link_type is set to 0xff, which
triggers a warning message, and results in a wrong link status, as
the LSI is ignored.

Signed-off-by: Stefan Brüns 
---
 drivers/net/usb/sierra_net.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/usb/sierra_net.c b/drivers/net/usb/sierra_net.c
index 6300a4454ae5..0b5a84c9022c 100644
--- a/drivers/net/usb/sierra_net.c
+++ b/drivers/net/usb/sierra_net.c
@@ -385,6 +385,13 @@ static int sierra_net_parse_lsi(struct usbnet *dev, char 
*data, int datalen)
return -1;
}
 
+   /* Validate the session state */
+   if (lsi->session_state == SIERRA_NET_SESSION_IDLE) {
+   netdev_err(dev->net, "Session idle, 0x%02x\n",
+  lsi->session_state);
+   return 0;
+   }
+
/* Validate the protocol  - only support UMTS for now */
if (lsi->protocol == SIERRA_NET_PROTOCOL_UMTS) {
struct lsi_umts_single *single = (struct lsi_umts_single *)lsi;
@@ -418,13 +425,6 @@ static int sierra_net_parse_lsi(struct usbnet *dev, char 
*data, int datalen)
return 0;
}
 
-   /* Validate the session state */
-   if (lsi->session_state == SIERRA_NET_SESSION_IDLE) {
-   netdev_err(dev->net, "Session idle, 0x%02x\n",
-   lsi->session_state);
-   return 0;
-   }
-
/* Set link_sense true */
return 1;
 }
-- 
2.11.0

[PATCH v3 0/2] Fixes for sierra_net driver

[Stefan Brüns]

When trying to initiate a dual-stack (ipv4v6) connection, a MC7710, FW
version SWI9200X_03.05.24.00ap answers with an unsupported LSI. Add support
for this LSI.
Also the link_type should be ignored when going idle, otherwise the modem
is stuck in a bad link state.
Tested on MC7710, T-Mobile DE, APN internet.telekom, IPv4v6 PDP type. Both
IPv4 and IPv6 connections work.

v2: Do not overwrite protocol field in rx_fixup
v3: Remove leftover struct ethhdr *eth declaration

Stefan Brüns (2):
  sierra_net: Add support for IPv6 and Dual-Stack Link Sense Indications
  sierra_net: Skip validating irrelevant fields for IDLE LSIs

 drivers/net/usb/sierra_net.c | 111 +++
 1 file changed, 71 insertions(+), 40 deletions(-)

-- 
2.11.0