Re: [PATCH v4] netlink: Fix autobind race condition that leads to zero port ID

[David Miller]

From: Herbert Xu 
Date: Mon, 21 Sep 2015 14:06:36 +0800

> On Sun, Sep 20, 2015 at 10:55:21PM -0700, David Miller wrote:
>> From: Herbert Xu 
>> Date: Fri, 18 Sep 2015 19:16:50 +0800
>> 
>> > The commit c0bb07df7d981e4091432754e30c9c720e2c0c78 ("netlink:
>> > Reset portid after netlink_insert failure") introduced a race
>> > condition where if two threads try to autobind the same socket
>> > one of them may end up with a zero port ID.  This led to kernel
>> > deadlocks that were observed by multiple people.
>> > 
>> > This patch reverts that commit and instead fixes it by introducing
>> > a separte rhash_portid variable so that the real portid is only set
>> > after the socket has been successfully hashed.
>> > 
>> > Fixes: c0bb07df7d98 ("netlink: Reset portid after netlink_insert failure")
>> > Reported-by: Tejun Heo 
>> > Reported-by: Linus Torvalds 
>> > Signed-off-by: Herbert Xu 
>> 
>> Applied and queued up for -stable, thanks Herbert.
> 
> Sorry but Dave but there are still races with v4 as Tejun pointed
> out.  I'm still working on it and I could post them as incremental
> patches if that's the easiest.

Oops, sorry about that.

Yeah at this point incremental patches work the best.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: Tree for Sep 21

[Stephen Rothwell]

Hi all,

Changes since 20150918:

I used the h8300 tree from next-20150828 since the current tree has been
rebased onto something very old :-(

The sound-asoc tree gained a build failure so I used the version from
next-20150918.

The bluetooth tree still had its build failure.

The akpm-current tree lost its build failure but gained 2 more for which
I applied fix patches.

Non-merge commits (relative to Linus' tree): 2108
 1767 files changed, 88212 insertions(+), 26185 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 for x86_64,
a multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), it is also built with powerpc allnoconfig
(32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final
link) and i386, sparc, sparc64 and arm defconfig.

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (1f93e4a96c91 Linux 4.3-rc2)
Merging fixes/master (c7e9ad7da219 Merge branch 'perf-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify)
Merging arm-current/fixes (7ae85dc7687c ARM: 8425/1: kgdb: Don't try to stop 
the machine when setting breakpoints)
Merging m68k-current/for-linus (1ecb40643a9a m68k/bootinfo: Use kmemdup rather 
than duplicating its implementation)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-fixes/fixes (400c47d81ca3 powerpc32: memset: only use dcbz once 
cache is enabled)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (73958c651fbf sparc64: use ENTRY/ENDPROC in VISsave)
Merging net/master (c2e7204d180f tcp_cubic: do not set epoch_start in the 
future)
Merging ipsec/master (04a6b8bfee06 xfrm6: Fix ICMPv6 and MH header checks in 
_decode_session6)
Merging sound-current/for-linus (5ee20bc79246 ALSA: usb-audio: Change internal 
PCM order)
Merging pci-current/for-linus (237865f195f6 PCI: Revert "PCI: Call 
pci_read_bridge_bases() from core instead of arch code")
Merging wireless-drivers/master (c2e7204d180f tcp_cubic: do not set epoch_start 
in the future)
Merging driver-core.current/driver-core-linus (2110d70c5e58 cpu/cacheinfo: Fix 
teardown path)
Merging tty.current/tty-linus (6ff33f3902c3 Linux 4.3-rc1)
Merging usb.current/usb-linus (ea9346514e77 Merge tag 'usb-ci-v4.3-rc2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb into usb-linus)
Merging usb-gadget-fixes/fixes (762982db33b2 usb: phy: phy-generic: Fix reset 
behaviour on legacy boot)
Merging usb-serial-fixes/usb-linus (19ab6bc5674a USB: option: add ZTE PIDs)
Merging staging.current/staging-linus (74c600e36455 MAINTAINERS: Update email 
address for Martyn Welch)
Merging char-misc.current/char-misc-linus (a42fb351ca1f thunderbolt: Allow 
loading of module on recent Apple MacBooks with thunderbolt 2 controller)
Merging input-current/for-linus (002801fc5372 Input: imx6ul_tsc - fix 
controller name)
Merging crypto-current/master (84cba178a3b8 crypto: testmgr - don't copy from 
source IV too much)
Merging ide/master (d681f1166919 ide: remove deprecated use of pci api)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_put_addr())
Merging vfio-fixes/for-linus (4bc94d5dc95d vfio: Fix lockdep issue)
Merging kselftest-fixes/fixes (ae7858180510 selftests: exec: revert to default 
emit rule)
Merging 

Re: [PATCH 1/3] avr32: fix build failure

[Hans-Christian Egtvedt]

Around Sat 19 Sep 2015 22:42:57 +0530 or thereabout, Sudip Mukherjee wrote:
> While building avr32 with allmodconfig, the build used to fail with the
> message:
> error: implicit declaration of function 'pci_iomap'
> error: implicit declaration of function 'pci_iounmap'

What has changed recently that start pulling in these? AVR32 does not have
PCI at all, and will never have it either. Is this exposing a bug somewhere
else?

> Create dummy pci_io{map,unmap} functions to fix the build.
> 
> Signed-off-by: Sudip Mukherjee 
> ---
> 
> Tested with defconfig, allmodconfig, allnoconfig and merisc_defconfig.
> Build is at:
> https://travis-ci.org/sudipm-mukherjee/parport/builds/81168845
> 
> Partial idea taken from:
> 78857614104a ("MIPS: Expose missing pci_io{map,unmap} declarations")
> which solved a similar problem with mips.
> 
>  arch/avr32/include/asm/io.h | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/arch/avr32/include/asm/io.h b/arch/avr32/include/asm/io.h
> index f855646..1d8c4e4 100644
> --- a/arch/avr32/include/asm/io.h
> +++ b/arch/avr32/include/asm/io.h
> @@ -276,6 +276,19 @@ extern void __iomem *__ioremap(unsigned long offset, 
> size_t size,
>  unsigned long flags);
>  extern void __iounmap(void __iomem *addr);
>  
> +#ifndef CONFIG_PCI
> +struct pci_dev;
> +static inline void pci_iounmap(struct pci_dev *dev, void __iomem *addr)
> +{
> +}
> +
> +static inline void __iomem *pci_iomap(struct pci_dev *dev, int bar,
> +   unsigned long maxlen)
> +{
> + return NULL;
> +}
> +#endif
> +
>  /*
>   * ioremap   -   map bus memory into CPU space
>   * @offset   bus address of the memory
-- 
mvh
Hans-Christian Egtvedt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] KVM: x86: put vcpu_create under kvm->srcu critical section

[Paolo Bonzini]

This is needed in case vcpu_create wants to access the memslots array.
Fixes this lockdep splat:

[26421.303750] ===
[26421.307952] [ INFO: suspicious RCU usage. ]
[26421.312161] 4.3.0-rc1+ #1 Not tainted
[26421.312161] ---
[26421.312162] include/linux/kvm_host.h:488 suspicious rcu_dereference_check() 
usage!
[26421.312163]
other info that might help us debug this:

[26421.312164]
rcu_scheduler_active = 1, debug_locks = 0
[26421.312165] 1 lock held by qemu-system-i38/17000:
[26421.312189]  #0:  (&(>mmu_lock)->rlock){+.+...}, at: 
[] kvm_zap_gfn_range+0x24/0x1a0 [kvm]
[26421.312189]
stack backtrace:
[26421.312191] CPU: 3 PID: 17000 Comm: qemu-system-i38 Not tainted 4.3.0-rc1+ #1
[26421.312192] Hardware name: To be filled by O.E.M. To be filled by 
O.E.M./M5A97 EVO R2.0, BIOS 1503 01/16/2013
[26421.312195]  0001 880386c0fc90 812c8c2a 
880423f0c740
[26421.312197]  880386c0fcc0 8109e60d 880429ff8000 

[26421.312199]  880386844000 8800 880386c0fd30 
a02d6c18
[26421.312199] Call Trace:
[26421.312205]  [] dump_stack+0x4e/0x84
[26421.312208]  [] lockdep_rcu_suspicious+0xfd/0x130
[26421.312223]  [] kvm_zap_gfn_range+0x188/0x1a0 [kvm]
[26421.312235]  [] kvm_set_cr0+0xde/0x1e0 [kvm]
[26421.312244]  [] init_vmcb+0x760/0xad0 [kvm_amd]
[26421.312246]  [] svm_create_vcpu+0x197/0x250 [kvm_amd]
[26421.312259]  [] kvm_arch_vcpu_create+0x47/0x70 [kvm]
[26421.312268]  [] kvm_vm_ioctl+0x302/0x7e0 [kvm]
[26421.312271]  [] ? __lock_is_held+0x51/0x70
[26421.312273]  [] ? __fget+0x101/0x210
[26421.312276]  [] do_vfs_ioctl+0x2f4/0x560
[26421.312277]  [] ? __fget_light+0x29/0x90
[26421.312279]  [] SyS_ioctl+0x4c/0x90
[26421.312282]  [] entry_SYSCALL_64_fastpath+0x16/0x73

Reported-by: Borislav Petkov 
Signed-off-by: Paolo Bonzini 
---
 arch/x86/kvm/x86.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 991466bf8dee..6107e09fc5b6 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7064,13 +7064,16 @@ struct kvm_vcpu *kvm_arch_vcpu_create(struct kvm *kvm,
unsigned int id)
 {
struct kvm_vcpu *vcpu;
+   int idx;
 
if (check_tsc_unstable() && atomic_read(>online_vcpus) != 0)
printk_once(KERN_WARNING
"kvm: SMP vm created on host with unstable TSC; "
"guest TSC will not be reliable\n");
 
+   idx = srcu_read_lock(>srcu);
vcpu = kvm_x86_ops->vcpu_create(kvm, id);
+   srcu_read_unlock(>srcu, idx);
 
return vcpu;
 }
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 2/2] phy: cygnus: pcie: Add Cygnus PCIe PHY support

[Kishon Vijay Abraham I]

Hi,

On Saturday 19 September 2015 05:46 AM, Ray Jui wrote:
> This patch adds the PCIe PHY support for the Broadcom PCIe RC interface
> on Cygnus
> 
> Signed-off-by: Ray Jui 
> Reviewed-by: Arun Parameswaran 
> Reviewed-by: JD (Jiandong) Zheng 
> Reviewed-by: Scott Branden 
> ---
>  drivers/phy/Kconfig   |   9 ++
>  drivers/phy/Makefile  |   1 +
>  drivers/phy/phy-bcm-cygnus-pcie.c | 209 
> ++
>  3 files changed, 219 insertions(+)
>  create mode 100644 drivers/phy/phy-bcm-cygnus-pcie.c
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 47da573..947bae2 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -371,4 +371,13 @@ config PHY_BRCMSTB_SATA
> Enable this to support the SATA3 PHY on 28nm Broadcom STB SoCs.
> Likely useful only with CONFIG_SATA_BRCMSTB enabled.
>  
> +config PHY_CYGNUS_PCIE
> + tristate "Broadcom Cygnus PCIe PHY driver"
> + depends on OF && (ARCH_BCM_CYGNUS || COMPILE_TEST)
> + select GENERIC_PHY
> + default ARCH_BCM_CYGNUS
> + help
> +   Enable this to support the Broadcom Cygnus PCIe PHY.
> +   If unsure, say N.
> +
>  endmenu
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index a5b18c1..fdce78d 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -46,3 +46,4 @@ obj-$(CONFIG_PHY_QCOM_UFS)  += phy-qcom-ufs-qmp-14nm.o
>  obj-$(CONFIG_PHY_TUSB1210)   += phy-tusb1210.o
>  obj-$(CONFIG_PHY_BRCMSTB_SATA)   += phy-brcmstb-sata.o
>  obj-$(CONFIG_PHY_PISTACHIO_USB)  += phy-pistachio-usb.o
> +obj-$(CONFIG_PHY_CYGNUS_PCIE)+= phy-bcm-cygnus-pcie.o
> diff --git a/drivers/phy/phy-bcm-cygnus-pcie.c 
> b/drivers/phy/phy-bcm-cygnus-pcie.c
> new file mode 100644
> index 000..132ebeb
> --- /dev/null
> +++ b/drivers/phy/phy-bcm-cygnus-pcie.c
> @@ -0,0 +1,209 @@
> +/*
> + * Copyright (C) 2015 Broadcom Corporation
> + *
> + * 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 version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; 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 
> +
> +#define PCIE_CFG_OFFSET 0x00
> +#define PCIE1_PHY_IDDQ_SHIFT10
> +#define PCIE0_PHY_IDDQ_SHIFT2
> +
> +enum cygnus_pcie_phy_id {
> + CYGNUS_PHY_PCIE0 = 0,
> + CYGNUS_PHY_PCIE1,
> + MAX_NUM_PHYS,
> +};
> +
> +struct cygnus_pcie_phy_core;
> +
> +/**
> + * struct cygnus_pcie_phy - Cygnus PCIe PHY device
> + * @core: pointer to the Cygnus PCIe PHY core control
> + * @id: internal ID to identify the Cygnus PCIe PHY
> + * @phy: pointer to the kernel PHY device
> + */
> +struct cygnus_pcie_phy {
> + struct cygnus_pcie_phy_core *core;
> + enum cygnus_pcie_phy_id id;
> + struct phy *phy;
> +};
> +
> +/**
> + * struct cygnus_pcie_phy_core - Cygnus PCIe PHY core control
> + * @dev: pointer to device
> + * @base: base register
> + * @lock: mutex to protect access to individual PHYs
> + * @phys: pointer to Cygnus PHY device
> + */
> +struct cygnus_pcie_phy_core {
> + struct device *dev;
> + void __iomem *base;
> + struct mutex lock;
> + struct cygnus_pcie_phy phys[MAX_NUM_PHYS];
> +};
> +
> +static int cygnus_pcie_power_config(struct cygnus_pcie_phy *phy, bool enable)
> +{
> + struct cygnus_pcie_phy_core *core = phy->core;
> + unsigned shift;
> + u32 val;
> +
> + mutex_lock(>lock);
> +
> + switch (phy->id) {
> + case CYGNUS_PHY_PCIE0:
> + shift = PCIE0_PHY_IDDQ_SHIFT;
> + break;
> +
> + case CYGNUS_PHY_PCIE1:
> + shift = PCIE1_PHY_IDDQ_SHIFT;
> + break;
> +
> + default:
> + mutex_unlock(>lock);
> + dev_err(core->dev, "PCIe PHY %d invalid\n", phy->id);
> + return -EINVAL;
> + }
> +
> + if (enable) {
> + val = readl(core->base + PCIE_CFG_OFFSET);
> + val &= ~BIT(shift);
> + writel(val, core->base + PCIE_CFG_OFFSET);
> + msleep(50);

Document any delays added to code.
> + } else {
> + val = readl(core->base + PCIE_CFG_OFFSET);
> + val |= BIT(shift);
> + writel(val, core->base + PCIE_CFG_OFFSET);
> + }
> +
> + mutex_unlock(>lock);
> + dev_info(core->dev, "PCIe PHY %d %s\n", phy->id,
> +  enable ? "enabled" : "disabled");

dev_dbg?

> + return 0;
> +}
> +
> +static int cygnus_pcie_phy_power_on(struct phy *p)
> +{
> + struct cygnus_pcie_phy *phy = 

Re: [PATCH v4] netlink: Fix autobind race condition that leads to zero port ID

[Herbert Xu]

On Sun, Sep 20, 2015 at 10:55:21PM -0700, David Miller wrote:
> From: Herbert Xu 
> Date: Fri, 18 Sep 2015 19:16:50 +0800
> 
> > The commit c0bb07df7d981e4091432754e30c9c720e2c0c78 ("netlink:
> > Reset portid after netlink_insert failure") introduced a race
> > condition where if two threads try to autobind the same socket
> > one of them may end up with a zero port ID.  This led to kernel
> > deadlocks that were observed by multiple people.
> > 
> > This patch reverts that commit and instead fixes it by introducing
> > a separte rhash_portid variable so that the real portid is only set
> > after the socket has been successfully hashed.
> > 
> > Fixes: c0bb07df7d98 ("netlink: Reset portid after netlink_insert failure")
> > Reported-by: Tejun Heo 
> > Reported-by: Linus Torvalds 
> > Signed-off-by: Herbert Xu 
> 
> Applied and queued up for -stable, thanks Herbert.

Sorry but Dave but there are still races with v4 as Tejun pointed
out.  I'm still working on it and I could post them as incremental
patches if that's the easiest.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] mmc: enable mmc host device to suspend/resume asynchronously

[Fu, Zhonghui]

Now, PM core supports asynchronous suspend/resume mode for devices
during system suspend/resume, and the power state transition of one
device may be completed in separate kernel thread. PM core ensures
all power state transition timing dependency between devices. This
patch enables mmc host device to suspend/resume asynchronously. This
will take advantage of multicore and improve system suspend/resume
speed.

Signed-off-by: Zhonghui Fu 
---
Changes in v2:
- Amend commit message.

 drivers/mmc/core/host.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index abd933b..8dfc011 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -577,6 +577,7 @@ struct mmc_host *mmc_alloc_host(int extra, struct device 
*dev)
host->class_dev.parent = dev;
host->class_dev.class = _host_class;
device_initialize(>class_dev);
+   device_enable_async_suspend(>class_dev);
 
if (mmc_gpio_alloc(host)) {
put_device(>class_dev);
-- 1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 12/14] ARM: dts: qs600: add pwrseq support to WLAN

[Igor Grinberg]

On 09/18/15 15:32, Srinivas Kandagatla wrote:
> Add pwrseq support to sdcc4 which would enable a proper reset of WLAN
> without ugly hacks in the board support file.
> 
> Signed-off-by: Srinivas Kandagatla 

Thanks Srini!

Acked-by: Igor Grinberg 

> ---
>  arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts | 32 
> +
>  1 file changed, 32 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts 
> b/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
> index 8aac3be..cc9d942 100644
> --- a/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
> +++ b/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
> @@ -1,4 +1,6 @@
>  #include "qcom-apq8064-v2.0.dtsi"
> +#include 
> +#include 
>  
>  / {
>   model = "CompuLab CM-QS600";
> @@ -12,6 +14,20 @@
>   stdout-path = "serial0:115200n8";
>   };
>  
> + pwrseq {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + compatible = "simple-bus";
> +
> + sdcc4_pwrseq: sdcc4_pwrseq {
> + pinctrl-names = "default";
> + pinctrl-0 = <_default_gpios>;
> + compatible = "mmc-pwrseq-simple";
> + reset-gpios = <_gpio 43 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
>   soc {
>   rpm@108000 {
>   regulators {
> @@ -154,6 +170,21 @@
>   regulator-always-on;
>   };
>  
> + qcom,ssbi@50 {
> + pmic@0 {
> + gpio@150 {
> + wlan_default_gpios: wlan-gpios {
> + pios {
> + pins = "gpio43";
> + function = "normal";
> + bias-disable;
> + power-source = 
> ;
> + };
> + };
> + };
> + };
> + };
> +
>   amba {
>   /* eMMC */
>   sdcc1: sdcc@1240 {
> @@ -172,6 +203,7 @@
>   status = "okay";
>   vmmc-supply = <_fixed>;
>   vqmmc-supply = <_fixed>;
> + mmc-pwrseq = <_pwrseq>;
>   };
>   };
>   };
> 

-- 
Regards,
Igor.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mmc: enable mmc host device to suspend/resume asynchronously

[Fu, Zhonghui]

On 2015/8/27 21:05, Ulf Hansson wrote:
> On 3 August 2015 at 14:39, Fu, Zhonghui  wrote:
>> Enable mmc host device to suspend/resume asynchronously.
>> This can improve system suspend/resume speed.
> Can or will?
>
> It would be nice to see some statistics of this to justify the change.
> Can you share that?
>
> Moreover we already have the runtime PM support, which enables the
> reinitialization sequence of the mmc/sd card to be postponed from the
> system PM resume path. Instead that's done when the next
> pm_runtime_get_sync() for the card's device gets called. You my tried
> that feature by enabling MMC_CAP_RUNTIME_RESUME for the mmc hosts.
This "will" improve system suspend/resume speed. I have resent this patch with 
updated commit message - "[PATCH v2] mmc: enable mmc host device to 
suspend/resume asynchronously".

The original suspend time is 1645ms and resume time is 940ms on ASUS T100TA 
machine. After enabling "wiphy device", "SDIO device", "mmc host" and 
"sdhci-acpi device" to suspend/resume asynchronously, the suspend time is 
1096ms and resume time is 908ms. The test environment is listed as follows:

OS: Ubuntu 14.04
Kernel: mainline v4.1
Machine: ASUS T100TA(Baytrail-T platform)
Tool: analyze_suspend
“analyze_suspend.py –f –m freeze” to suspend system
Press power button to resume system

System PM is independent from runtime PM. Now, PM core supports asynchronous 
suspend/resume mode for devices during system suspend/resume, and the power 
state transition of one
device may be completed in separate kernel thread. PM core ensures all power 
state transition timing dependency between devices. This patch enables mmc host 
device to suspend/resume asynchronously. This will take advantage of multicore 
and improve system suspend/resume speed.


Thanks,
Zhonghui
> Kind regards
> Uffe
>
>> Signed-off-by: Zhonghui Fu 
>> ---
>>  drivers/mmc/core/host.c |1 +
>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
>> index 99a9c90..85f2bbb 100644
>> --- a/drivers/mmc/core/host.c
>> +++ b/drivers/mmc/core/host.c
>> @@ -577,6 +577,7 @@ struct mmc_host *mmc_alloc_host(int extra, struct device 
>> *dev)
>> host->class_dev.parent = dev;
>> host->class_dev.class = _host_class;
>> device_initialize(>class_dev);
>> +   device_enable_async_suspend(>class_dev);
>>
>> if (mmc_gpio_alloc(host)) {
>> put_device(>class_dev);
>> -- 1.7.1
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] avr32: fix build failure

[Sudip Mukherjee]

On Mon, Sep 21, 2015 at 08:09:42AM +0200, Hans-Christian Egtvedt wrote:
> Around Sat 19 Sep 2015 22:42:57 +0530 or thereabout, Sudip Mukherjee wrote:
> > While building avr32 with allmodconfig, the build used to fail with the
> > message:
> > error: implicit declaration of function 'pci_iomap'
> > error: implicit declaration of function 'pci_iounmap'
> 
> What has changed recently that start pulling in these? AVR32 does not have
> PCI at all, and will never have it either. Is this exposing a bug somewhere
> else?
It looks like pci_iomap and pci_iounmap doesnot depend on CONFIG_PCI.
So drivers/net/ethernet/via/via-rhine.c is calling these functions even
if PCI is disabled. The build log is at:
https://travis-ci.org/sudipm-mukherjee/parport/jobs/81127188

You can find a similar discussion at:
http://www.linux-mips.org/archives/linux-mips/2013-06/msg00510.html

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] mmc/sdhci-acpi: enable sdhci-acpi device to suspend/resume asynchronously

[Fu, Zhonghui]

Now, PM core supports asynchronous suspend/resume mode for devices
during system suspend/resume, and the power state transition of one
device may be completed in separate kernel thread. PM core ensures
all power state transition timing dependency between devices. This
patch enables sdhci-acpi device to suspend/resume asynchronously.
This will take advantage of multicore and improve system
suspend/resume speed.

Signed-off-by: Zhonghui Fu 
---
Changes in v2:
- Amend commit message.

 drivers/mmc/host/sdhci-acpi.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host/sdhci-acpi.c
index 22d929f..67e6263 100644
--- a/drivers/mmc/host/sdhci-acpi.c
+++ b/drivers/mmc/host/sdhci-acpi.c
@@ -379,6 +379,8 @@ static int sdhci_acpi_probe(struct platform_device *pdev)
pm_runtime_enable(dev);
}
 
+   device_enable_async_suspend(dev);
+
return 0;
 
 err_free:
-- 1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mmc/sdhci-acpi: enable sdhci-acpi device to suspend/resume asynchronously

[Fu, Zhonghui]

On 2015/8/24 23:14, Fu, Zhonghui wrote:
>
> On 2015/8/17 14:51, Adrian Hunter wrote:
>> On 17/08/15 06:38, Fu, Zhonghui wrote:
>>> Hi,
>>>
>>> Any comments are welcome.
>> Same comments as here:
>>
>>  http://marc.info/?l=linux-kernel=143979428424353=2
> Now, PM core support asynchronous device suspend/resume mode. If one device 
> has been set to support asynchronous PM mode, it's suspend/resume operation 
> can be performed in a separate kernel thread and take advantage of multicore 
> feature to improve overall system suspend/resume speed. The worst case is 
> that all device suspend/resume threads will be scheduled to the same CPU, it 
> hardly occur.
>
> PM core ensure all the suspend/resume dependency related to one device. 
> Actually, async suspend/resume mode is one feature of PM core, every device 
> subsystem may use it or not use it. Once one device subsystem choose to use 
> this feature, its safety is up to PM core as long as device subsystem has 
> initialized fully this device.

The original suspend time is 1645ms and resume time is 940ms on ASUS T100TA 
machine. After enabling "wiphy device", "SDIO device", "mmc host" and 
"sdhci-acpi device" to suspend/resume asynchronously, the suspend time is 
1096ms and resume time is 908ms. The test environment is listed as follows:

OS: Ubuntu 14.04
Kernel: mainline v4.1
Machine: ASUS T100TA(Baytrail-T platform)
Tool: analyze_suspend
“analyze_suspend.py –f –m freeze” to suspend system
Press power button to resume system

I have resent this patch with updated commit message - "[PATCH v2] 
mmc/sdhci-acpi: enable sdhci-acpi device to suspend/resume asynchronously".


Thanks,
Zhonghui


>
>
> Thanks,
> Zhonghui
>
>
>>> Thanks,
>>> Zhonghui
>>>
>>> On 2015/8/3 21:10, Fu, Zhonghui wrote:
 Enable sdhci-acpi device to suspend/resume asynchronously.
 This can improve system suspend/resume speed.

 Signed-off-by: Zhonghui Fu 
 ---
  drivers/mmc/host/sdhci-acpi.c |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

 diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host/sdhci-acpi.c
 index 22d929f..67e6263 100644
 --- a/drivers/mmc/host/sdhci-acpi.c
 +++ b/drivers/mmc/host/sdhci-acpi.c
 @@ -379,6 +379,8 @@ static int sdhci_acpi_probe(struct platform_device 
 *pdev)
pm_runtime_enable(dev);
}
  
 +  device_enable_async_suspend(dev);
 +
return 0;
  
  err_free:
 -- 1.7.1

>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/5] drivers/misc/sgi-gru: add return on error

[Sudip Mukherjee]

On Sun, Sep 20, 2015 at 10:36:15PM -0700, Greg Kroah-Hartman wrote:
> On Mon, Sep 21, 2015 at 11:04:10AM +0530, Sudip Mukherjee wrote:
> > On Sun, Sep 20, 2015 at 07:26:29PM -0700, Greg Kroah-Hartman wrote:
> > > On Tue, Sep 15, 2015 at 01:20:41PM +0530, Sudip Mukherjee wrote:
> > > > On Thu, Sep 03, 2015 at 01:21:38PM -0500, Dimitri Sivanich wrote:
> > > > > Acked-by: Dimitri Sivanich 
> > > > > 
> > > > > On Thu, Sep 03, 2015 at 08:20:47PM +0530, Sudip Mukherjee wrote:
> > > > > > If the buffer is too small then return the error and in the process
> > > > > > remove the variables which became unused.
> > > > > > 
> > > > > > Signed-off-by: Sudip Mukherjee 
> > > > > > ---
> > > > Hi Greg,
> > > > I know its too early to ping you but just wanted to know that this
> > > > should go through your char-misc tree or through Andrew.
> > > > Looking at all the previous patches, it all went through Andrew but
> > > > being a char/misc I thought it will go through you.
> > > 
> > > I'll take it, thanks.
> > Thanks. But just to let you know that getmaintainer.pl is not showing
> > your and Arnd's name. But MAINTAINER shows drivers/misc/* for you and
> > Arnd. And besides I noticed there are one or two patches still lying
> > around with maintainer ACK but never picked up as they didnot have you
> > or Andrew in the To or CC list.
> 
> That's odd, care to forward them on to me?
OMG... There are quite a few. Even from 2014 and one of them is a bugfix
for a bugzilla.
I am sending them all by the end of the day (IST).

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/fpu] x86/fpu/math-emu, selftests: Add test for FISTTP instructions

[tip-bot for Denys Vlasenko]

Commit-ID:  a58e2ecd019d9ffb9f1813faf6151716fdecbae5
Gitweb: http://git.kernel.org/tip/a58e2ecd019d9ffb9f1813faf6151716fdecbae5
Author: Denys Vlasenko 
AuthorDate: Sun, 20 Sep 2015 16:03:10 +0200
Committer:  Ingo Molnar 
CommitDate: Sun, 20 Sep 2015 16:19:01 +0200

x86/fpu/math-emu, selftests: Add test for FISTTP instructions

  $ ./test_FISTTP_32
  [RUN] Testing fisttp instructions
  [OK]  fisttp

Signed-off-by: Denys Vlasenko 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: H. Peter Anvin 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Shuah Khan 
Cc: Thomas Gleixner 
Cc: linux-kernel@vger.kernel.org
Link: 
http://lkml.kernel.org/r/1442757790-27233-1-git-send-email-dvlas...@redhat.com
Signed-off-by: Ingo Molnar 
---
 tools/testing/selftests/x86/Makefile  |   2 +-
 tools/testing/selftests/x86/test_FISTTP.c | 137 ++
 2 files changed, 138 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/x86/Makefile 
b/tools/testing/selftests/x86/Makefile
index c4c9b90..7145b3d 100644
--- a/tools/testing/selftests/x86/Makefile
+++ b/tools/testing/selftests/x86/Makefile
@@ -6,7 +6,7 @@ include ../lib.mk
 
 TARGETS_C_BOTHBITS := single_step_syscall sysret_ss_attrs ldt_gdt syscall_nt
 TARGETS_C_32BIT_ONLY := entry_from_vm86 syscall_arg_fault sigreturn \
-   test_FCMOV test_FCOMI
+   test_FCMOV test_FCOMI test_FISTTP
 
 TARGETS_C_32BIT_ALL := $(TARGETS_C_BOTHBITS) $(TARGETS_C_32BIT_ONLY)
 BINARIES_32 := $(TARGETS_C_32BIT_ALL:%=%_32)
diff --git a/tools/testing/selftests/x86/test_FISTTP.c 
b/tools/testing/selftests/x86/test_FISTTP.c
new file mode 100644
index 000..b8e61a0
--- /dev/null
+++ b/tools/testing/selftests/x86/test_FISTTP.c
@@ -0,0 +1,137 @@
+#undef _GNU_SOURCE
+#define _GNU_SOURCE 1
+#undef __USE_GNU
+#define __USE_GNU 1
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+unsigned long long res64 = -1;
+unsigned int res32 = -1;
+unsigned short res16 = -1;
+
+int test(void)
+{
+   int ex;
+
+   
feclearexcept(FE_DIVBYZERO|FE_INEXACT|FE_INVALID|FE_OVERFLOW|FE_UNDERFLOW);
+   asm volatile ("\n"
+   "   fld1""\n"
+   "   fisttp  res16""\n"
+   "   fld1""\n"
+   "   fisttpl res32""\n"
+   "   fld1""\n"
+   "   fisttpll res64""\n"
+   : : : "memory"
+   );
+   if (res16 != 1 || res32 != 1 || res64 != 1) {
+   printf("[BAD]\tfisttp 1\n");
+   return 1;
+   }
+   ex = 
fetestexcept(FE_DIVBYZERO|FE_INEXACT|FE_INVALID|FE_OVERFLOW|FE_UNDERFLOW);
+   if (ex != 0) {
+   printf("[BAD]\tfisttp 1: wrong exception state\n");
+   return 1;
+   }
+
+   
feclearexcept(FE_DIVBYZERO|FE_INEXACT|FE_INVALID|FE_OVERFLOW|FE_UNDERFLOW);
+   asm volatile ("\n"
+   "   fldpi""\n"
+   "   fisttp  res16""\n"
+   "   fldpi""\n"
+   "   fisttpl res32""\n"
+   "   fldpi""\n"
+   "   fisttpll res64""\n"
+   : : : "memory"
+   );
+   if (res16 != 3 || res32 != 3 || res64 != 3) {
+   printf("[BAD]\tfisttp pi\n");
+   return 1;
+   }
+   ex = 
fetestexcept(FE_DIVBYZERO|FE_INEXACT|FE_INVALID|FE_OVERFLOW|FE_UNDERFLOW);
+   if (ex != FE_INEXACT) {
+   printf("[BAD]\tfisttp pi: wrong exception state\n");
+   return 1;
+   }
+
+   
feclearexcept(FE_DIVBYZERO|FE_INEXACT|FE_INVALID|FE_OVERFLOW|FE_UNDERFLOW);
+   asm volatile ("\n"
+   "   fldpi""\n"
+   "   fchs""\n"
+   "   fisttp  res16""\n"
+   "   fldpi""\n"
+   "   fchs""\n"
+   "   fisttpl res32""\n"
+   "   fldpi""\n"
+   "   fchs""\n"
+   "   fisttpll res64""\n"
+   : : : "memory"
+   );
+   if (res16 != 0xfffd || res32 != 0xfffd || res64 != 
0xfffdULL) {
+   printf("[BAD]\tfisttp -pi\n");
+   return 1;
+   }
+   ex = 
fetestexcept(FE_DIVBYZERO|FE_INEXACT|FE_INVALID|FE_OVERFLOW|FE_UNDERFLOW);
+   if (ex != FE_INEXACT) {
+   printf("[BAD]\tfisttp -pi: wrong exception state\n");
+   return 1;
+   }
+
+   
feclearexcept(FE_DIVBYZERO|FE_INEXACT|FE_INVALID|FE_OVERFLOW|FE_UNDERFLOW);
+   asm volatile ("\n"
+   "   fldln2""\n"
+   "   fisttp  res16""\n"
+   "   fldln2""\n"
+   "   fisttpl res32""\n"
+   "   fldln2""\n"
+   "   fisttpll res64""\n"
+   : : : "memory"
+   );
+   /* Test truncation to zero (round-to-nearest would give 1 here) */
+   if (res16 != 

[tip:x86/fpu] x86/fpu/math-emu: Add support for FISTTP instructions

[tip-bot for Denys Vlasenko]

Commit-ID:  e4877d64f00964d86a6e4a02301173899018
Gitweb: http://git.kernel.org/tip/e4877d64f00964d86a6e4a02301173899018
Author: Denys Vlasenko 
AuthorDate: Fri, 18 Sep 2015 20:23:34 +0200
Committer:  Ingo Molnar 
CommitDate: Sun, 20 Sep 2015 16:19:02 +0200

x86/fpu/math-emu: Add support for FISTTP instructions

These FPU instructions were added in SSE3-enabled CPUs.

Run-tested by booting with "no387 nofxsr" and running test
program:

[RUN]   Testing fisttp instructions
[OK]fisttp

Signed-off-by: Denys Vlasenko 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: H. Peter Anvin 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Shuah Khan 
Cc: Thomas Gleixner 
Cc: linux-kernel@vger.kernel.org
Link: 
http://lkml.kernel.org/r/1442600614-28428-1-git-send-email-dvlas...@redhat.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/math-emu/load_store.c | 63 ++
 1 file changed, 51 insertions(+), 12 deletions(-)

diff --git a/arch/x86/math-emu/load_store.c b/arch/x86/math-emu/load_store.c
index 2931ff3..95228ff 100644
--- a/arch/x86/math-emu/load_store.c
+++ b/arch/x86/math-emu/load_store.c
@@ -33,11 +33,12 @@
 
 #define pop_0(){ FPU_settag0(TAG_Empty); top++; }
 
+/* index is a 5-bit value: (3-bit FPU_modrm.reg field | opcode[2,1]) */
 static u_char const type_table[32] = {
-   _PUSH_, _PUSH_, _PUSH_, _PUSH_,
-   _null_, _null_, _null_, _null_,
-   _REG0_, _REG0_, _REG0_, _REG0_,
-   _REG0_, _REG0_, _REG0_, _REG0_,
+   _PUSH_, _PUSH_, _PUSH_, _PUSH_, /* /0: d9:fld f32,  db:fild m32,  
dd:fld f64,  df:fild m16 */
+   _null_, _REG0_, _REG0_, _REG0_, /* /1: d9:undef,db,dd,df:fisttp 
m32/64/16 */
+   _REG0_, _REG0_, _REG0_, _REG0_, /* /2: d9:fst f32,  db:fist m32,  
dd:fst f64,  df:fist m16 */
+   _REG0_, _REG0_, _REG0_, _REG0_, /* /3: d9:fstp f32, db:fistp m32, 
dd:fstp f64, df:fistp m16 */
_NONE_, _null_, _NONE_, _PUSH_,
_NONE_, _PUSH_, _null_, _PUSH_,
_NONE_, _null_, _NONE_, _REG0_,
@@ -45,15 +46,19 @@ static u_char const type_table[32] = {
 };
 
 u_char const data_sizes_16[32] = {
-   4, 4, 8, 2, 0, 0, 0, 0,
-   4, 4, 8, 2, 4, 4, 8, 2,
+   4, 4, 8, 2,
+   0, 4, 8, 2, /* /1: d9:undef, db,dd,df:fisttp */
+   4, 4, 8, 2,
+   4, 4, 8, 2,
14, 0, 94, 10, 2, 10, 0, 8,
14, 0, 94, 10, 2, 10, 2, 8
 };
 
 static u_char const data_sizes_32[32] = {
-   4, 4, 8, 2, 0, 0, 0, 0,
-   4, 4, 8, 2, 4, 4, 8, 2,
+   4, 4, 8, 2,
+   0, 4, 8, 2, /* /1: d9:undef, db,dd,df:fisttp */
+   4, 4, 8, 2,
+   4, 4, 8, 2,
28, 0, 108, 10, 2, 10, 0, 8,
28, 0, 108, 10, 2, 10, 2, 8
 };
@@ -65,6 +70,7 @@ int FPU_load_store(u_char type, fpu_addr_modes addr_modes,
FPU_REG *st0_ptr;
u_char st0_tag = TAG_Empty; /* This is just to stop a gcc warning. 
*/
u_char loaded_tag;
+   int sv_cw;
 
st0_ptr = NULL; /* Initialized just to stop compiler warnings. 
*/
 
@@ -111,7 +117,8 @@ int FPU_load_store(u_char type, fpu_addr_modes addr_modes,
}
 
switch (type) {
-   case 000:   /* fld m32real */
+   /* type is a 5-bit value: (3-bit FPU_modrm.reg field | opcode[2,1]) */
+   case 000:   /* fld m32real (d9 /0) */
clear_C1();
loaded_tag =
FPU_load_single((float __user *)data_address, _data);
@@ -123,13 +130,13 @@ int FPU_load_store(u_char type, fpu_addr_modes addr_modes,
}
FPU_copy_to_reg0(_data, loaded_tag);
break;
-   case 001:   /* fild m32int */
+   case 001:   /* fild m32int (db /0) */
clear_C1();
loaded_tag =
FPU_load_int32((long __user *)data_address, _data);
FPU_copy_to_reg0(_data, loaded_tag);
break;
-   case 002:   /* fld m64real */
+   case 002:   /* fld m64real (dd /0) */
clear_C1();
loaded_tag =
FPU_load_double((double __user *)data_address,
@@ -142,12 +149,44 @@ int FPU_load_store(u_char type, fpu_addr_modes addr_modes,
}
FPU_copy_to_reg0(_data, loaded_tag);
break;
-   case 003:   /* fild m16int */
+   case 003:   /* fild m16int (df /0) */
clear_C1();
loaded_tag =
FPU_load_int16((short __user *)data_address, _data);
FPU_copy_to_reg0(_data, loaded_tag);
break;
+   /* case 004: undefined (d9 /1) */
+ 

RE: [PATCH] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Bharat Kumar Gogada]

Ping!

-Original Message-
From: Bharat Kumar Gogada [mailto:bharat.kumar.gog...@xilinx.com]
Sent: Thursday, August 27, 2015 5:14 PM
To: robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com; 
ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; Michal Simek; Soren 
Brinkmann; bhelg...@google.com; a...@arndb.de; tinam...@apm.com; 
tred...@nvidia.com; r...@broadcom.com; minghuan.l...@freescale.com; 
m-kariche...@ti.com; ha...@hauke-m.de
Cc: devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; 
linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; Bharat Kumar Gogada; 
Ravikiran Gummaluri
Subject: [PATCH] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host 
Controller

Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.

Signed-off-by: Bharat Kumar Gogada 
Signed-off-by: Ravi Kiran Gummaluri 
---
 .../devicetree/bindings/pci/xilinx-nwl-pcie.txt|   39 +
 drivers/pci/host/Kconfig   |9 +
 drivers/pci/host/Makefile  |1 +
 drivers/pci/host/pci-xilinx-nwl.c  | 1038 
 4 files changed, 1087 insertions(+), 0 deletions(-)  create mode 100644 
Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
 create mode 100644 drivers/pci/host/pci-xilinx-nwl.c

diff --git a/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt 
b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
new file mode 100644
index 000..c554d6b
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
@@ -0,0 +1,39 @@
+* Xilinx NWL PCIe Root Port Bridge DT description
+
+Required properties:
+- compatible: Should contain "xlnx,nwl-pcie-2.11"
+- #address-cells: Address representation for root ports, set to <3>
+- #size-cells: Size representation for root ports, set to <2>
+- #interrupt-cells: specifies the number of cells needed to encode an
+   interrupt source. The value must be 1.
+- reg: Should contain Bridge, PCIe Controller registers location and
+length
+- device_type: must be "pci"
+- interrupts: Should contain NWL PCIe interrupt
+- ranges: ranges for the PCI memory regions (I/O space region is not
+   supported by hardware)
+   Please refer to the standard PCI bus binding document for a more
+   detailed explanation
+
+Optional properties:
+- xlnx,msi-fifo: To enable MSI FIFO mode
+
+Example:
+
+nwl_pcie: pcie@fd0e {
+   compatible = "xlnx,nwl-pcie-2.11";
+   #address-cells = <3>;
+   #size-cells = <2>;
+   #interrupt-cells = <1>;
+   device_type = "pci";
+   interrupt-parent = <>;
+   interrupts = < 0 118 4
+  0 116 4
+  0 115 4  // MSI_1 [63...32]
+  0 114 4 >;   // MSI_0 [31...0]
+   interrupt-names = "misc", "intx", "msi_1", "msi_0";
+   reg = <0x0 0xfd0e 0x1000
+  0x0 0xfd48 0x1000
+  0x0 0xE000 0x100>;
+   reg-names = "breg", "pcireg", "cfg";
+   ranges = <0x0200 0x 0xE100 0x 0xE100 0
+0x0F00>; };
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig index 
c132bdd..5ff4e7e 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -15,6 +15,15 @@ config PCI_MVEBU
depends on ARCH_MVEBU || ARCH_DOVE
depends on OF

+config PCI_XILINX_NWL
+   bool "NWL PCIe Core"
+   depends on ARCH_ZYNQMP && PCI_MSI
+   help
+Say 'Y' here if you want kernel to support for Xilinx
+NWL PCIe controller.The controller can act as Root Port
+or End Point.The current option selection will only
+support root port enabling.
+
 config PCIE_DW
bool

diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile index 
140d66f..0f3a789 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_PCI_HOST_GENERIC) += pci-host-generic.o
 obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
 obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o pci-keystone.o
 obj-$(CONFIG_PCIE_XILINX) += pcie-xilinx.o
+obj-$(CONFIG_PCI_XILINX_NWL) += pci-xilinx-nwl.o
 obj-$(CONFIG_PCI_XGENE) += pci-xgene.o
 obj-$(CONFIG_PCI_XGENE_MSI) += pci-xgene-msi.o
 obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o diff --git 
a/drivers/pci/host/pci-xilinx-nwl.c b/drivers/pci/host/pci-xilinx-nwl.c
new file mode 100644
index 000..6c2fa80
--- /dev/null
+++ b/drivers/pci/host/pci-xilinx-nwl.c
@@ -0,0 +1,1038 @@
+/*
+ * PCIe host controller driver for NWL PCIe Bridge
+ * Based on pci-xilinx.c, pci-tegra.c
+ *
+ * (C) Copyright 2014 - 2015, Xilinx, Inc.
+ *
+ * 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 

Re: blk_mq_register_disk: kobject (00000000009f2dd8): tried to init an initialized object, something is seriously wrong.

[Meelis Roos]

> On Tue, Sep 15, 2015 at 3:06 AM, Meelis Roos  wrote:
> > This is 4.3.0-rc1 on Sun E220R (dual-CPU sparc64). Sometimes it boots,
> > sometimes it fails to boot with looping errors and finally a watchdog
> > timeout. This console log from a failure. Config is below.
> >
[...]
> > [   90.956986] netconsole: network logging started
> > [   91.011243] rtc-m48t59 rtc-m48t59.0: setting system clock to 2015-09-14 
> > 12:31:56 UTC (1442233916)?   91.636785] scsi 0:0:0:0: Direct-Access 
> > QUANTUM  ATLAS10K3_36_SCA 020W PQ: 0 ANSI: 3
> > [   91.732863] scsi target0:0:0: tagged command queuing enabled, command 
> > queue depth 16.
> > [   91.826592] scsi target0:0:0: Beginning Domain Validation
> > [   91.894554] scsi target0:0:0: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, 
> > offset 16)
> > [   91.983049] scsi target0:0:0: Domain Validation skipping write tests
> > [   92.058187] scsi target0:0:0: Ending Domain Validation
> > [   93.590588] scsi 0:0:6:0: CD-ROMTOSHIBA  XM6201TASUN32XCD 
> > 1103 PQ: 0 ANSI: 2
> > [   93.686649] scsi target0:0:6: Beginning Domain Validation
> > [   93.753328] scsi target0:0:6: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 
> > 16)
> > [   93.836962] scsi target0:0:6: Domain Validation skipping write tests
> > [   93.912162] scsi target0:0:6: Ending Domain Validation
> > [   96.317514] sd 0:0:0:0: [sda] 71833096 512-byte logical blocks: (36.7 
> > GB/34.2 GiB)
> > [   96.408799] sd 0:0:0:0: [sda] Write Protect is off
> > [   96.465258] sd 0:0:0:0: [sda] Mode Sense: e5 00 10 08
> > [   96.527504] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
> > supports DPO and FUA
> > [   96.641946]  sda: sda1 sda2 sda3 sda4
> > [   96.688204] kworker/u4:0 (570) used greatest stack depth: 9104 bytes left
> > [   96.709472] sd 0:0:0:0: [sda] Attached SCSI disk
> > [   98.020598] EXT4-fs (sda2): couldn't mount as ext3 due to feature 
> > incompatibilities
> > [   98.112011] EXT4-fs (sda2): couldn't mount as ext2 due to feature 
> > incompatibilities
> > [   98.227702] EXT4-fs (sda2): mounted filesystem with ordered data mode. 
> > Opts: (null)
> > [   98.318525] VFS: Mounted root (ext4 filesystem) readonly on device 
> > 259:262144.
> > [   98.436651] devtmpfs: mounted
> > Mount failed for selinuxfs on /sys/fs/selinux:  No such file or directory
> > g??ɹ?ѥ???H?   99.248602] stty (586) used greatest stack depth: 8216 
> > bytes left
> > [   99.484619] tput (590) used greatest stack depth: 8088 bytes left
> > [info] Using makefile-style concurrent boot in runlevel S.
> > [  100.116965] ps (660) used greatest stack depth: 7728 bytes left
> > unparseable line (c! /dev/autofs 0600 - - - 10:235)
> > unparseable line (c! /dev/fuse 0600 - - - 10:229)
> > unparseable line (c! /dev/cuse 0600 - - - 10:203)
> > unparse[  100.356492] random: udevd urandom read with 18 bits of entropy 
> > available
> > able line (c! /dev/loop-control 0600 - - - 10:237)
> > unparseable line (c! /dev/net/tun 0600 - - - 10:200)
> > unparseable line (c! /dev/uhid 0600 - - - 10:239)
> > [] Starting the hotplug events dispatcher: udevdstarting version 218
> > [ ok .
> > [] Synthesizing the initial hotplug events...[ ok done.
> > [  101.056708] hwclock (716) used greatest stack depth: 7608 bytes left
> > [] Waiting f[  101.148930] sd 0:0:0:0: Attached scsi generic sg0 type 0
> > [  101.212727] scsi 0:0:6:0: Attached scsi generic sg1 type 5
> > or [  101.281691] PCI: Enabling device: (:00:01.1), cmd 2
> > [  101.289700] sr 0:0:6:0: [sr0] scsi-1 drive
> > [  101.289710] cdrom: Uniform CD-ROM driver Revision: 3.20
> > [  101.348345] sr 0:0:6:0: Attached scsi CD-ROM sr0
> > [  101.393029] cdrom_id (726) used greatest stack depth: 7456 bytes left
> > [  101.587083] sunhme.c:v3.10 August 26, 2008 David S. Miller 
> > (da...@davemloft.net)
> > /d[  101.678086] eth0: HAPPY MEAL (PCI/CheerIO) 10/100BaseT Ethernet 
> > 08:00:20:c7:a3:81
> > ev to be fully populated...[ ok done.
> > [] Setting preliminary keymap...[ ok done.
> > [] Activating swap...[  104.354886] Adding 1582392k swap on /dev/sda4.  
> > Priority:-1 extents:1 across:1582392k
> > [ ok done.
> > [  104.582832] EXT4-fs (sda2): re-mounted. Opts: (null)
> > [] Checking root file system...fsck from util-linux 2.26.2
> > /dev/sda2: clean, 134168/2142112 files, 1452575/8558628 blocks
> > [ ok   104.917474] EXT4-fs (sda2): re-mounted. Opts: errors=remount-ro
> > 25hdone.
> > [] Activating lvm and md swap...[ ok done.
> > [] Checking file systems...fsck from util-linux 2.26.2
> > /dev/sda1: clean, 40/48192 files, 43342/96390 blocks
> > [ ok done.
> > [] Cleaning up temporary files... /tmp[ ok .
> > [  106.370834] kobject (009f2dd8): tried to init an initialized 
> > object, something is seriously wrong.
> 
> Akinobu found there is one race between CPU hotplug and add_disk, maybe
> you can try the patch in the following link to see if it can fix your issue.
> 
>  

Re: blk_mq_register_disk: kobject (00000000009f2dd8): tried to init an initialized object, something is seriously wrong.

[Ming Lei]

On Mon, Sep 21, 2015 at 3:26 PM, Meelis Roos  wrote:
>> On Tue, Sep 15, 2015 at 3:06 AM, Meelis Roos  wrote:
>> > This is 4.3.0-rc1 on Sun E220R (dual-CPU sparc64). Sometimes it boots,
>> > sometimes it fails to boot with looping errors and finally a watchdog
>> > timeout. This console log from a failure. Config is below.
>> >
> [...]
>> > [   90.956986] netconsole: network logging started
>> > [   91.011243] rtc-m48t59 rtc-m48t59.0: setting system clock to 2015-09-14 
>> > 12:31:56 UTC (1442233916)?   91.636785] scsi 0:0:0:0: Direct-Access 
>> > QUANTUM  ATLAS10K3_36_SCA 020W PQ: 0 ANSI: 3
>> > [   91.732863] scsi target0:0:0: tagged command queuing enabled, command 
>> > queue depth 16.
>> > [   91.826592] scsi target0:0:0: Beginning Domain Validation
>> > [   91.894554] scsi target0:0:0: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, 
>> > offset 16)
>> > [   91.983049] scsi target0:0:0: Domain Validation skipping write tests
>> > [   92.058187] scsi target0:0:0: Ending Domain Validation
>> > [   93.590588] scsi 0:0:6:0: CD-ROMTOSHIBA  XM6201TASUN32XCD 
>> > 1103 PQ: 0 ANSI: 2
>> > [   93.686649] scsi target0:0:6: Beginning Domain Validation
>> > [   93.753328] scsi target0:0:6: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 
>> > 16)
>> > [   93.836962] scsi target0:0:6: Domain Validation skipping write tests
>> > [   93.912162] scsi target0:0:6: Ending Domain Validation
>> > [   96.317514] sd 0:0:0:0: [sda] 71833096 512-byte logical blocks: (36.7 
>> > GB/34.2 GiB)
>> > [   96.408799] sd 0:0:0:0: [sda] Write Protect is off
>> > [   96.465258] sd 0:0:0:0: [sda] Mode Sense: e5 00 10 08
>> > [   96.527504] sd 0:0:0:0: [sda] Write cache: enabled, read cache: 
>> > enabled, supports DPO and FUA
>> > [   96.641946]  sda: sda1 sda2 sda3 sda4
>> > [   96.688204] kworker/u4:0 (570) used greatest stack depth: 9104 bytes 
>> > left
>> > [   96.709472] sd 0:0:0:0: [sda] Attached SCSI disk
>> > [   98.020598] EXT4-fs (sda2): couldn't mount as ext3 due to feature 
>> > incompatibilities
>> > [   98.112011] EXT4-fs (sda2): couldn't mount as ext2 due to feature 
>> > incompatibilities
>> > [   98.227702] EXT4-fs (sda2): mounted filesystem with ordered data mode. 
>> > Opts: (null)
>> > [   98.318525] VFS: Mounted root (ext4 filesystem) readonly on device 
>> > 259:262144.
>> > [   98.436651] devtmpfs: mounted
>> > Mount failed for selinuxfs on /sys/fs/selinux:  No such file or directory
>> > g??ɹ?ѥ???H?   99.248602] stty (586) used greatest stack depth: 
>> > 8216 bytes left
>> > [   99.484619] tput (590) used greatest stack depth: 8088 bytes left
>> > [info] Using makefile-style concurrent boot in runlevel S.
>> > [  100.116965] ps (660) used greatest stack depth: 7728 bytes left
>> > unparseable line (c! /dev/autofs 0600 - - - 10:235)
>> > unparseable line (c! /dev/fuse 0600 - - - 10:229)
>> > unparseable line (c! /dev/cuse 0600 - - - 10:203)
>> > unparse[  100.356492] random: udevd urandom read with 18 bits of entropy 
>> > available
>> > able line (c! /dev/loop-control 0600 - - - 10:237)
>> > unparseable line (c! /dev/net/tun 0600 - - - 10:200)
>> > unparseable line (c! /dev/uhid 0600 - - - 10:239)
>> > [] Starting the hotplug events dispatcher: udevdstarting version 218
>> > [ ok .
>> > [] Synthesizing the initial hotplug events...[ ok done.
>> > [  101.056708] hwclock (716) used greatest stack depth: 7608 bytes left
>> > [] Waiting f[  101.148930] sd 0:0:0:0: Attached scsi generic sg0 type 0
>> > [  101.212727] scsi 0:0:6:0: Attached scsi generic sg1 type 5
>> > or [  101.281691] PCI: Enabling device: (:00:01.1), cmd 2
>> > [  101.289700] sr 0:0:6:0: [sr0] scsi-1 drive
>> > [  101.289710] cdrom: Uniform CD-ROM driver Revision: 3.20
>> > [  101.348345] sr 0:0:6:0: Attached scsi CD-ROM sr0
>> > [  101.393029] cdrom_id (726) used greatest stack depth: 7456 bytes left
>> > [  101.587083] sunhme.c:v3.10 August 26, 2008 David S. Miller 
>> > (da...@davemloft.net)
>> > /d[  101.678086] eth0: HAPPY MEAL (PCI/CheerIO) 10/100BaseT Ethernet 
>> > 08:00:20:c7:a3:81
>> > ev to be fully populated...[ ok done.
>> > [] Setting preliminary keymap...[ ok done.
>> > [] Activating swap...[  104.354886] Adding 1582392k swap on /dev/sda4. 
>> >  Priority:-1 extents:1 across:1582392k
>> > [ ok done.
>> > [  104.582832] EXT4-fs (sda2): re-mounted. Opts: (null)
>> > [] Checking root file system...fsck from util-linux 2.26.2
>> > /dev/sda2: clean, 134168/2142112 files, 1452575/8558628 blocks
>> > [ ok   104.917474] EXT4-fs (sda2): re-mounted. Opts: errors=remount-ro
>> > 25hdone.
>> > [] Activating lvm and md swap...[ ok done.
>> > [] Checking file systems...fsck from util-linux 2.26.2
>> > /dev/sda1: clean, 40/48192 files, 43342/96390 blocks
>> > [ ok done.
>> > [] Cleaning up temporary files... /tmp[ ok .
>> > [  106.370834] kobject (009f2dd8): tried to init an initialized 
>> > object, something is seriously wrong.
>>
>> Akinobu found there is 

Re: [char-misc 1/2] mei: Fix debugfs filename in error output

[Greg Kroah-Hartman]

On Mon, Sep 21, 2015 at 01:07:21PM +0600, Alexander Kuleshov wrote:
> Hello Greg,
> 
> On Mon, Sep 21, 2015 at 8:25 AM, Greg Kroah-Hartman
>  wrote:
> > On Mon, Aug 24, 2015 at 03:27:36PM +0300, Tomas Winkler wrote:
> >> From: "Signed-off-by: Alexander Kuleshov" 
> >
> > I kind of doubt that's the real author name :(
> >
> 
> Why? I've definitely sent this patch sometime ago
> (https://lkml.org/lkml/2015/8/14/560)

Look at the line carefully...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] fs: fix data races on inode->i_flctx

[Dmitry Vyukov]

locks_get_lock_context() uses cmpxchg() to install i_flctx.
cmpxchg() is a release operation which is correct. But it uses
a plain load to load i_flctx. This is incorrect. Subsequent loads
from i_flctx can hoist above the load of i_flctx pointer itself
and observe uninitialized garbage there. This in turn can lead
to corruption of ctx->flc_lock and other members.

Documentation/memory-barriers.txt explicitly requires to use
a barrier in such context:
"A load-load control dependency requires a full read memory barrier".

Use smp_load_acquire() in locks_get_lock_context() and in bunch
of other functions that can proceed concurrently with
locks_get_lock_context().

The data race was found with KernelThreadSanitizer (KTSAN).

Signed-off-by: Dmitry Vyukov 
---
For the record, here is the KTSAN report:

ThreadSanitizer: data-race in _raw_spin_lock

Read at 0x8800bae50da0 of size 1 by thread 3060 on CPU 2:
 [< inline >] __raw_spin_lock include/linux/spinlock_api_smp.h:158
 [] _raw_spin_lock+0x50/0x70 kernel/locking/spinlock.c:151
 [< inline >] spin_lock include/linux/spinlock.h:312
 [] flock_lock_inode+0xb7/0x440 fs/locks.c:895
 [] flock_lock_inode_wait+0x46/0x110 fs/locks.c:1871
 [] SyS_flock+0x224/0x23

Previous write at 0x8800bae50da0 of size 8 by thread 3063 on CPU 8:
 [] kmem_cache_alloc+0xd8/0x2f0 mm/slab.c:3420
 [] locks_get_lock_context+0x60/0x140 fs/locks.c:213
 [] flock_lock_inode+0x5a/0x440 fs/locks.c:882
 [] flock_lock_inode_wait+0x46/0x110 fs/locks.c:1871
 [< inline >] flock_lock_file_wait include/linux/fs.h:1219
 [< inline >] SYSC_flock fs/locks.c:1941
 [] SyS_flock+0x224/0x230 fs/locks.c:1904
 [] entry_SYSCALL_64_fastpath+0x31/0x95 
arch/x86/entry/entry_64.S:188
---
 fs/locks.c | 63 +++---
 1 file changed, 36 insertions(+), 27 deletions(-)

diff --git a/fs/locks.c b/fs/locks.c
index 2a54c80..316e474 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -205,28 +205,32 @@ static struct kmem_cache *filelock_cache __read_mostly;
 static struct file_lock_context *
 locks_get_lock_context(struct inode *inode, int type)
 {
-   struct file_lock_context *new;
+   struct file_lock_context *ctx;
 
-   if (likely(inode->i_flctx) || type == F_UNLCK)
+   /* paired with cmpxchg() below */
+   ctx = smp_load_acquire(>i_flctx);
+   if (likely(ctx) || type == F_UNLCK)
goto out;
 
-   new = kmem_cache_alloc(flctx_cache, GFP_KERNEL);
-   if (!new)
+   ctx = kmem_cache_alloc(flctx_cache, GFP_KERNEL);
+   if (!ctx)
goto out;
 
-   spin_lock_init(>flc_lock);
-   INIT_LIST_HEAD(>flc_flock);
-   INIT_LIST_HEAD(>flc_posix);
-   INIT_LIST_HEAD(>flc_lease);
+   spin_lock_init(>flc_lock);
+   INIT_LIST_HEAD(>flc_flock);
+   INIT_LIST_HEAD(>flc_posix);
+   INIT_LIST_HEAD(>flc_lease);
 
/*
 * Assign the pointer if it's not already assigned. If it is, then
 * free the context we just allocated.
 */
-   if (cmpxchg(>i_flctx, NULL, new))
-   kmem_cache_free(flctx_cache, new);
+   if (cmpxchg(>i_flctx, NULL, ctx)) {
+   kmem_cache_free(flctx_cache, ctx);
+   ctx = smp_load_acquire(>i_flctx);
+   }
 out:
-   return inode->i_flctx;
+   return ctx;
 }
 
 void
@@ -762,7 +766,7 @@ posix_test_lock(struct file *filp, struct file_lock *fl)
struct file_lock_context *ctx;
struct inode *inode = file_inode(filp);
 
-   ctx = inode->i_flctx;
+   ctx = smp_load_acquire(>i_flctx);
if (!ctx || list_empty_careful(>flc_posix)) {
fl->fl_type = F_UNLCK;
return;
@@ -1203,7 +1207,7 @@ int locks_mandatory_locked(struct file *file)
struct file_lock_context *ctx;
struct file_lock *fl;
 
-   ctx = inode->i_flctx;
+   ctx = smp_load_acquire(>i_flctx);
if (!ctx || list_empty_careful(>flc_posix))
return 0;
 
@@ -1388,7 +1392,7 @@ any_leases_conflict(struct inode *inode, struct file_lock 
*breaker)
 int __break_lease(struct inode *inode, unsigned int mode, unsigned int type)
 {
int error = 0;
-   struct file_lock_context *ctx = inode->i_flctx;
+   struct file_lock_context *ctx;
struct file_lock *new_fl, *fl, *tmp;
unsigned long break_time;
int want_write = (mode & O_ACCMODE) != O_RDONLY;
@@ -1400,6 +1404,7 @@ int __break_lease(struct inode *inode, unsigned int mode, 
unsigned int type)
new_fl->fl_flags = type;
 
/* typically we will check that ctx is non-NULL before calling */
+   ctx = smp_load_acquire(>i_flctx);
if (!ctx) {
WARN_ON_ONCE(1);
return error;
@@ -1494,9 +1499,10 @@ EXPORT_SYMBOL(__break_lease);
 void lease_get_mtime(struct inode *inode, struct timespec *time)
 {
bool has_lease = false;
-   struct file_lock_context *ctx = 

Re: [PATCH 2/2] usb: gadget: f_midi: check for error on usb_ep_queue

[Peter Chen]

On Fri, Sep 18, 2015 at 06:12:41PM +0100, e...@felipetonello.com wrote:
> From: "Felipe F. Tonello" 
> 
> f_midi is not checking weather the is an error on usb_ep_queue

%s/weather/whether
%s/the/there

> request, ignoring potential problems, such as memory leaks.
> 
> Signed-off-by: Felipe F. Tonello 
> ---
>  drivers/usb/gadget/function/f_midi.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/gadget/function/f_midi.c 
> b/drivers/usb/gadget/function/f_midi.c
> index ad50a67..a5e446d 100644
> --- a/drivers/usb/gadget/function/f_midi.c
> +++ b/drivers/usb/gadget/function/f_midi.c
> @@ -543,8 +543,14 @@ static void f_midi_transmit(struct f_midi *midi, struct 
> usb_request *req)
>   }
>   }
>  
> - if (req->length > 0)
> - usb_ep_queue(ep, req, GFP_ATOMIC);
> + if (req->length > 0) {
> + int err;
> +
> + err = usb_ep_queue(ep, req, GFP_ATOMIC);
> + if (err < 0)
> + ERROR(midi, "%s queue req: %d\n",
> +   midi->out_ep->name, err);
> + }
>   else
>   free_ep_req(ep, req);
>  }
> -- 
> 2.1.4
> 

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] usb: chipidea: udc: improve error handling on ep_queue

[Peter Chen]

On Fri, Sep 18, 2015 at 06:12:40PM +0100, e...@felipetonello.com wrote:
> From: "Felipe F. Tonello" 
> 
> _ep_queue() didn't check for errors when using add_td_to_list()
> which can fail if dma_pool_alloc fails, thus causing a kernel

Would you find the root cause why dma_pool_alloc fails?

> panic when lastnode->ptr is NULL.
> 
> Signed-off-by: Felipe F. Tonello 
> ---
>  drivers/usb/chipidea/udc.c | 26 +++---
>  1 file changed, 19 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> index 764f668..7169113e 100644
> --- a/drivers/usb/chipidea/udc.c
> +++ b/drivers/usb/chipidea/udc.c
> @@ -404,9 +404,9 @@ static inline u8 _usb_addr(struct ci_hw_ep *ep)
>  }
>  
>  /**
> - * _hardware_queue: configures a request at hardware level
> - * @gadget: gadget
> + * _hardware_enqueue: configures a request at hardware level
>   * @hwep:   endpoint
> + * @hwreq:  request
>   *
>   * This function returns an error code
>   */
> @@ -435,19 +435,27 @@ static int _hardware_enqueue(struct ci_hw_ep *hwep, 
> struct ci_hw_req *hwreq)
>   if (hwreq->req.dma % PAGE_SIZE)
>   pages--;
>  
> - if (rest == 0)
> - add_td_to_list(hwep, hwreq, 0);
> + if (rest == 0) {
> + ret = add_td_to_list(hwep, hwreq, 0);
> + if (ret < 0)
> + goto done;
> + }
>  
>   while (rest > 0) {
>   unsigned count = min(hwreq->req.length - hwreq->req.actual,
>   (unsigned)(pages * CI_HDRC_PAGE_SIZE));
> - add_td_to_list(hwep, hwreq, count);
> + ret = add_td_to_list(hwep, hwreq, count);
> + if (ret < 0)
> + goto done;
>   rest -= count;
>   }
>  
>   if (hwreq->req.zero && hwreq->req.length
> - && (hwreq->req.length % hwep->ep.maxpacket == 0))
> - add_td_to_list(hwep, hwreq, 0);
> + && (hwreq->req.length % hwep->ep.maxpacket == 0)) {
> + ret = add_td_to_list(hwep, hwreq, 0);
> + if (ret < 0)
> + goto done;
> + }
>  
>   firstnode = list_first_entry(>tds, struct td_node, td);
>  
> @@ -750,8 +758,12 @@ static void isr_get_status_complete(struct usb_ep *ep, 
> struct usb_request *req)
>  
>  /**
>   * _ep_queue: queues (submits) an I/O request to an endpoint
> + * @ep:endpoint
> + * @req:   request
> + * @gfp_flags: GFP flags (not used)
>   *
>   * Caller must hold lock
> + * This function returns an error code
>   */
>  static int _ep_queue(struct usb_ep *ep, struct usb_request *req,
>   gfp_t __maybe_unused gfp_flags)
> -- 
> 2.1.4
> 

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [tip:x86/asm] x86/entry/vsyscall: Add CONFIG to control default

[Borislav Petkov]

On Sun, Sep 20, 2015 at 04:29:18AM -0700, tip-bot for Kees Cook wrote:
> Commit-ID:  3dc33bd30f3e1c1bcaaafa3482737694debf0f0b
> Gitweb: http://git.kernel.org/tip/3dc33bd30f3e1c1bcaaafa3482737694debf0f0b
> Author: Kees Cook 
> AuthorDate: Wed, 12 Aug 2015 17:55:19 -0700
> Committer:  Ingo Molnar 
> CommitDate: Sun, 20 Sep 2015 10:31:06 +0200
> 
> x86/entry/vsyscall: Add CONFIG to control default
> 
> Most modern systems can run with vsyscall=none. In an effort to
> provide a way for build-time defaults to lack legacy settings,
> this adds a new CONFIG to select the type of vsyscall mapping to
> use, similar to the existing "vsyscall" command line parameter.
> 
> Signed-off-by: Kees Cook 
> Acked-by: Andy Lutomirski 
> Cc: Borislav Petkov 
> Cc: Brian Gerst 
> Cc: Denys Vlasenko 
> Cc: H. Peter Anvin 
> Cc: Josh Triplett 
> Cc: Linus Torvalds 
> Cc: Peter Zijlstra 
> Cc: Thomas Gleixner 
> Link: http://lkml.kernel.org/r/20150813005519.ga11...@www.outflux.net
> Signed-off-by: Ingo Molnar 
> ---
>  arch/x86/Kconfig  | 49 
> +++
>  arch/x86/entry/vsyscall/vsyscall_64.c |  9 ++-
>  2 files changed, 57 insertions(+), 1 deletion(-)

...

> diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c 
> b/arch/x86/entry/vsyscall/vsyscall_64.c
> index b160c0c..76e0fd3 100644
> --- a/arch/x86/entry/vsyscall/vsyscall_64.c
> +++ b/arch/x86/entry/vsyscall/vsyscall_64.c
> @@ -38,7 +38,14 @@
>  #define CREATE_TRACE_POINTS
>  #include "vsyscall_trace.h"
>  
> -static enum { EMULATE, NATIVE, NONE } vsyscall_mode = EMULATE;
> +static enum { EMULATE, NATIVE, NONE } vsyscall_mode =
> +#ifdef CONFIG_LEGACY_VSYSCALL_NATIVE
> + NATIVE;
> +#elif CONFIG_LEGACY_VSYSCALL_NONE

My gcc complains about this. If it hasn't been fixed yet, here's a fix:

---
From: Borislav Petkov 
Date: Mon, 21 Sep 2015 09:34:23 +0200
Subject: [PATCH] x86/entry/vsyscall: Fix undefined symbol warning

3dc33bd30f3e1 ("x86/entry/vsyscall: Add CONFIG to control default") did
the ifdef/elif thing but gcc doesn't like that:

  arch/x86/entry/vsyscall/vsyscall_64.c:44:7: warning: 
"CONFIG_LEGACY_VSYSCALL_NONE" is not defined [-Wundef]
   #elif CONFIG_LEGACY_VSYSCALL_NONE
 ^

Use defined() instead.

Cc: Andy Lutomirski 
Cc: Kees Cook 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Triplett 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20150813005519.ga11...@www.outflux.net
Signed-off-by: Borislav Petkov 
---
 arch/x86/entry/vsyscall/vsyscall_64.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c 
b/arch/x86/entry/vsyscall/vsyscall_64.c
index 76e0fd3ea1fb..174c2549939d 100644
--- a/arch/x86/entry/vsyscall/vsyscall_64.c
+++ b/arch/x86/entry/vsyscall/vsyscall_64.c
@@ -39,9 +39,9 @@
 #include "vsyscall_trace.h"
 
 static enum { EMULATE, NATIVE, NONE } vsyscall_mode =
-#ifdef CONFIG_LEGACY_VSYSCALL_NATIVE
+#if defined(CONFIG_LEGACY_VSYSCALL_NATIVE)
NATIVE;
-#elif CONFIG_LEGACY_VSYSCALL_NONE
+#elif defined(CONFIG_LEGACY_VSYSCALL_NONE)
NONE;
 #else
EMULATE;
-- 
2.1.4

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/asm] x86/entry/vsyscall: Fix undefined symbol warning

[tip-bot for Borislav Petkov]

Commit-ID:  93f13a9f96771a064c716364aebc6e283b186eb8
Gitweb: http://git.kernel.org/tip/93f13a9f96771a064c716364aebc6e283b186eb8
Author: Borislav Petkov 
AuthorDate: Mon, 21 Sep 2015 09:48:29 +0200
Committer:  Ingo Molnar 
CommitDate: Mon, 21 Sep 2015 09:56:59 +0200

x86/entry/vsyscall: Fix undefined symbol warning

Commit:

  3dc33bd30f3e1 ("x86/entry/vsyscall: Add CONFIG to control default")

did the ifdef/elif thing but GCC doesn't like that:

  arch/x86/entry/vsyscall/vsyscall_64.c:44:7: warning: 
"CONFIG_LEGACY_VSYSCALL_NONE" is not defined [-Wundef]
   #elif CONFIG_LEGACY_VSYSCALL_NONE
 ^

Use defined() instead.

Signed-off-by: Borislav Petkov 
Cc: Andy Lutomirski 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Triplett 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20150921074829.ga3...@pd.tnic
Signed-off-by: Ingo Molnar 
---
 arch/x86/entry/vsyscall/vsyscall_64.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c 
b/arch/x86/entry/vsyscall/vsyscall_64.c
index 76e0fd3..174c254 100644
--- a/arch/x86/entry/vsyscall/vsyscall_64.c
+++ b/arch/x86/entry/vsyscall/vsyscall_64.c
@@ -39,9 +39,9 @@
 #include "vsyscall_trace.h"
 
 static enum { EMULATE, NATIVE, NONE } vsyscall_mode =
-#ifdef CONFIG_LEGACY_VSYSCALL_NATIVE
+#if defined(CONFIG_LEGACY_VSYSCALL_NATIVE)
NATIVE;
-#elif CONFIG_LEGACY_VSYSCALL_NONE
+#elif defined(CONFIG_LEGACY_VSYSCALL_NONE)
NONE;
 #else
EMULATE;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] avr32: fix build failure

[Sudip Mukherjee]

On Mon, Sep 21, 2015 at 09:33:00AM +0200, Hans-Christian Egtvedt wrote:
> Around Mon 21 Sep 2015 12:09:01 +0530 or thereabout, Sudip Mukherjee wrote:
> > On Mon, Sep 21, 2015 at 08:09:42AM +0200, Hans-Christian Egtvedt wrote:
> >> Around Sat 19 Sep 2015 22:42:57 +0530 or thereabout, Sudip Mukherjee wrote:
> >> > While building avr32 with allmodconfig, the build used to fail with the
> >> > message:
> >> > error: implicit declaration of function 'pci_iomap'
> >> > error: implicit declaration of function 'pci_iounmap'
> >> 
> >> What has changed recently that start pulling in these? AVR32 does not have
> >> PCI at all, and will never have it either. Is this exposing a bug somewhere
> >> else?
> > It looks like pci_iomap and pci_iounmap doesnot depend on CONFIG_PCI.
> > So drivers/net/ethernet/via/via-rhine.c is calling these functions even
> > if PCI is disabled. The build log is at:
> > https://travis-ci.org/sudipm-mukherjee/parport/jobs/81127188
> > 
> > You can find a similar discussion at:
> > http://www.linux-mips.org/archives/linux-mips/2013-06/msg00510.html
> 
> If multiple architectures have similar problems, then a more global
> definition of these unused functions could be added.
> 
> Just move the implementation for MIPS into include/asm-generic/io.h ?
> 
> That way we do not have to implement and identical stub for every device not
> supporting PCI.

include/asm-generic/io.h is having:
#ifndef CONFIG_GENERIC_IOMAP
struct pci_dev;
extern void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned
long max);

#ifndef pci_iounmap
#define pci_iounmap pci_iounmap
static inline void pci_iounmap(struct pci_dev *dev, void __iomem *p)
{
}
#endif
#endif /* CONFIG_GENERIC_IOMAP */

and CONFIG_GENERIC_IOMAP is not defined when I do allmodconfig with
avr32. I have not seen this earlier, maybe in my patch pci_iounmap() was
not required. But pci_iomap is declared as extern so we need have it
somewhere.

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] lib: fix data race in rhashtable_rehash_one

[Dmitry Vyukov]

rhashtable_rehash_one() uses plain writes to update entry->next,
while it is being concurrently accessed by readers.
Unfortunately, the compiler is within its rights to (for example) use
byte-at-a-time writes to update the pointer, which would fatally confuse
concurrent readers.

Use WRITE_ONCE to update entry->next in rhashtable_rehash_one().

The data race was found with KernelThreadSanitizer (KTSAN).

Signed-off-by: Dmitry Vyukov 
---
KTSAN report for the record:

ThreadSanitizer: data-race in netlink_lookup

Atomic read at 0x880480443bd0 of size 8 by thread 2747 on CPU 11:
 [< inline >] rhashtable_lookup_fast include/linux/rhashtable.h:543
 [< inline >] __netlink_lookup net/netlink/af_netlink.c:1026
 [] netlink_lookup+0x134/0x1c0 net/netlink/af_netlink.c:1046
 [< inline >] netlink_getsockbyportid net/netlink/af_netlink.c:1616
 [] netlink_unicast+0x111/0x300 net/netlink/af_netlink.c:1812
 [] netlink_sendmsg+0x4c9/0x5f0 net/netlink/af_netlink.c:2443
 [< inline >] sock_sendmsg_nosec net/socket.c:610
 [] sock_sendmsg+0x83/0x90 net/socket.c:620
 [] ___sys_sendmsg+0x3cf/0x3e0 net/socket.c:1952
 [] __sys_sendmsg+0x4c/0xb0 net/socket.c:1986
 [< inline >] SYSC_sendmsg net/socket.c:1997
 [] SyS_sendmsg+0x30/0x50 net/socket.c:1993
 [] entry_SYSCALL_64_fastpath+0x31/0x95
arch/x86/entry/entry_64.S:188

Previous write at 0x880480443bd0 of size 8 by thread 213 on CPU 4:
 [< inline >] rhashtable_rehash_one lib/rhashtable.c:193
 [< inline >] rhashtable_rehash_chain lib/rhashtable.c:213
 [< inline >] rhashtable_rehash_table lib/rhashtable.c:257
 [] rht_deferred_worker+0x3b0/0x6d0 lib/rhashtable.c:373
 [] process_one_work+0x47e/0x930 kernel/workqueue.c:2036
 [] worker_thread+0xb0/0x900 kernel/workqueue.c:2170
 [] kthread+0x150/0x170 kernel/kthread.c:209
 [] ret_from_fork+0x3f/0x70 arch/x86/entry/entry_64.S:529

Mutexes locked by thread 213:
Mutex 217217 is locked here:
 [] mutex_lock+0x57/0x70 kernel/locking/mutex.c:108
 [] rht_deferred_worker+0x45/0x6d0 lib/rhashtable.c:363
 [] process_one_work+0x47e/0x930 kernel/workqueue.c:2036
 [] worker_thread+0xb0/0x900 kernel/workqueue.c:2170
 [] kthread+0x150/0x170 kernel/kthread.c:209
 [] ret_from_fork+0x3f/0x70 arch/x86/entry/entry_64.S:529

Mutex 431216 is locked here:
 [< inline >] __raw_spin_lock_bh include/linux/spinlock_api_smp.h:149
 [] _raw_spin_lock_bh+0x65/0x80 kernel/locking/spinlock.c:175
 [< inline >] spin_lock_bh include/linux/spinlock.h:317
 [< inline >] rhashtable_rehash_chain lib/rhashtable.c:212
 [< inline >] rhashtable_rehash_table lib/rhashtable.c:257
 [] rht_deferred_worker+0x1e6/0x6d0 lib/rhashtable.c:373
 [] process_one_work+0x47e/0x930 kernel/workqueue.c:2036
 [] worker_thread+0xb0/0x900 kernel/workqueue.c:2170
 [] kthread+0x150/0x170 kernel/kthread.c:209
 [] ret_from_fork+0x3f/0x70 arch/x86/entry/entry_64.S:529

Mutex 432766 is locked here:
 [< inline >] __raw_spin_lock include/linux/spinlock_api_smp.h:158
 [] _raw_spin_lock+0x50/0x70 kernel/locking/spinlock.c:151
 [< inline >] rhashtable_rehash_one lib/rhashtable.c:186
 [< inline >] rhashtable_rehash_chain lib/rhashtable.c:213
 [< inline >] rhashtable_rehash_table lib/rhashtable.c:257
 [] rht_deferred_worker+0x36b/0x6d0 lib/rhashtable.c:373
 [] process_one_work+0x47e/0x930 kernel/workqueue.c:2036
 [] worker_thread+0xb0/0x900 kernel/workqueue.c:2170
 [] kthread+0x150/0x170 kernel/kthread.c:209
 [] ret_from_fork+0x3f/0x70 arch/x86/entry/entry_64.S:529
---
 lib/rhashtable.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/lib/rhashtable.c b/lib/rhashtable.c
index cc0c697..978624d 100644
--- a/lib/rhashtable.c
+++ b/lib/rhashtable.c
@@ -188,9 +188,12 @@ static int rhashtable_rehash_one(struct rhashtable *ht, 
unsigned int old_hash)
  new_tbl, new_hash);
 
if (rht_is_a_nulls(head))
-   INIT_RHT_NULLS_HEAD(entry->next, ht, new_hash);
-   else
-   RCU_INIT_POINTER(entry->next, head);
+   head = (struct rhash_head *)rht_marker(ht, new_hash);
+   /* We don't insert any new nodes that were not previously accessible
+* to readers, so we don't need to use rcu_assign_pointer().
+* But entry is being concurrently accessed by readers, so we need to
+* use at least WRITE_ONCE. */
+   WRITE_ONCE(entry->next, head);
 
rcu_assign_pointer(new_tbl->buckets[new_hash], entry);
spin_unlock(new_bucket_lock);
-- 
2.6.0.rc0.131.gf624c3d

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] pwm: atmel-hlcdc: Fix module autoload for OF platform driver

[Thierry Reding]

On Fri, Sep 18, 2015 at 06:58:21PM +0200, Luis de Bethencourt wrote:
> This platform driver has a OF device ID table but the OF module
> alias information is not created so module autoloading won't work.
> 
> Signed-off-by: Luis de Bethencourt 
> ---
> 
> 
> Hello,
> 
> This patch adds the missing MODULE_DEVICE_TABLE() for OF to export
> that information so modules have the correct aliases built-in and
> autoloading works correctly.
> 
> A longer explanation by Javier Canillas can be found here:
> https://lkml.org/lkml/2015/7/30/519

This is useful information and belongs in the commit message, so I moved
it into the commit message before applying.

Thanks,
Thierry


signature.asc
Description: PGP signature

Re: [PATCH v6 2/5] Documentation: bindings: document the Berlin PWM driver

[Thierry Reding]

On Thu, Sep 17, 2015 at 12:13:05PM +0200, Antoine Tenart wrote:
> Following the addition of a Berlin PWM driver, this patch adds the
> corresponding documentation.
> 
> Signed-off-by: Antoine Tenart 
> Acked-by: Sebastian Hesselbarth 
> ---
>  Documentation/devicetree/bindings/pwm/pwm-berlin.txt | 19 +++
>  1 file changed, 19 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-berlin.txt

That's the wrong way around. You define the binding, get concensus that
it's okay and then implement the binding in the driver. Of course you'd
always provide both the binding and an implementation in the same patch
series for convenience, but that doesn't change the logical ordering.

> diff --git a/Documentation/devicetree/bindings/pwm/pwm-berlin.txt 
> b/Documentation/devicetree/bindings/pwm/pwm-berlin.txt
> new file mode 100644
> index ..8f9bc11f8c4c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-berlin.txt
> @@ -0,0 +1,19 @@
> +Berlin PWM controller
> +
> +PWM IP found in Marvell Berlin SoCs.

This isn't a proper sentence and doesn't add much useful information. If
you want to say anything here, provide details about the PWM controller.

> +
> +Required properties:
> +- compatible: should be "marvell,berlin-pwm"
> +- reg: physical base address and length of the controller's registers
> +- clocks: phandle to the input clock

You should think about adding a clock-names property here as well.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH v3 1/9] crypto: introduce decompression API that can be called via sharable tfm object

[Sergey Senozhatsky]

On (09/18/15 14:19), Joonsoo Kim wrote:
[..]
>  static int __init lzo_mod_init(void)
> diff --git a/include/linux/crypto.h b/include/linux/crypto.h
> index e71cb70..31152b1 100644
> --- a/include/linux/crypto.h
> +++ b/include/linux/crypto.h
> @@ -355,6 +355,8 @@ struct compress_alg {
>   unsigned int slen, u8 *dst, unsigned int *dlen);
>   int (*coa_decompress)(struct crypto_tfm *tfm, const u8 *src,
> unsigned int slen, u8 *dst, unsigned int *dlen);
> + int (*coa_decompress_noctx)(const u8 *src, unsigned int slen,
> + u8 *dst, unsigned int *dlen);
>  };
>  
>  
> @@ -538,6 +540,9 @@ struct compress_tfm {
>   int (*cot_decompress)(struct crypto_tfm *tfm,
> const u8 *src, unsigned int slen,
> u8 *dst, unsigned int *dlen);
> + int (*cot_decompress_noctx)(struct crypto_tfm *tfm,
> + const u8 *src, unsigned int slen,
> + u8 *dst, unsigned int *dlen);
>  };
>  
>  #define crt_ablkcipher   crt_u.ablkcipher
> @@ -1836,6 +1841,14 @@ static inline void crypto_free_comp(struct crypto_comp 
> *tfm)
>   crypto_free_tfm(crypto_comp_tfm(tfm));
>  }
>  
> +struct crypto_comp *crypto_alloc_comp_noctx(const char *alg_name,
> + u32 type, u32 mask);
> +

this should be EXPORT_SYMBOL_GPL().

-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 0/4] Implement OCOTP driver for Vybrid using NVMEM

[maitysanchayan]

Hello,

Ping?

- Sanchayan.

On 15-09-07 13:51:34, Sanchayan Maity wrote:
> Hello,
> 
> Tested on Greg's tree char-misc-next branch along with Stefan's NAND driver
> patchset.
> 
> Sample output on Colibri VF50
> 
> root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# uname -a
> Linux colibri-vf 4.2.0-rc6-9-g1cec223 #5 SMP Mon Sep 7 12:34:37 IST 2015 
> armv7l GNU/Linux
> 
> root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# hexdump nvmem
> 000        
> *
> 410 72a6 df64      
> 420 11d4 2006      
> 430        
> *
> 450 0280       
> 460        
> *
> 880 8f01       
> 890        
> *
> 8c0  1300      
> 8d0 320a 0800      
> 8e0  e200      
> 8f0        
> *
> c80 bada bada      
> *
> cc0        
> *
> cf0
> 
> Changes since v9:
> 1. Drop clock-names property from DT
> 2. Rebase on top of latest char-misc-next
> 
> Changes since v8:
> 1. Fix three lines over 80 characters
> 2. Rebase on top of Greg's char-misc-next branch
> 
> Changes since v7:
> 1. Add COMPILE_TEST to Kconfig
> 2. Use GENMASK and BIT macros where applicable
> 3. Fix a code alignment issue
> 4. Get the max_register value for regmap config using
> resource_size()
> 5. Also add copyright info as the driver logic is based off
> on ocotp code in barebox
> 6. Add missing info related to clock in DT binding doc
> 
> Changes since v6:
> 1. Use the v9 of NVMEM framework patchset
> 2. Add a few comments
> 3. Initialise buffer address not part of the fuse map to 0
> instead of only handling buffer locations with valid fuse
> addresses.
> 
> Changes since v5:
> Use NVMEM framework by Srinivas and Maxime
> 
> Changes since v4:
> 1. Use devm_* family of functions and use a struct to get rid of
> global variables (suggested by Joachim Eastwood)
> 2. Make Kconfig govern the compilation with tristate, instead of
> earlier bool. Paul Bolle raised a valid point that perhaps this
> should have been built in with the bool, however I had not taken
> into consideration generic distro kernels and it makes sense to
> have this tristated. (comments from Paul Bolle and Andreas Farber)
> 
> Changes since v3:
> Instead of using the syscon_regmap_lookup_by_compatible function
> use a phandle in the device tree along with offsets specified in
> this phandle node and then read the offset along with the device
> node in the driver for reading from the required region.
> 
> Changes since v2:
> Implement the SoC bus code as a driver in drivers/soc
> by registering with fsl,mscm-cpucfg as per Arnd's feedback
> 
> Changes since v1:
> Sort the headers in alphabetical order
> 
> Changes since RFC:
> Use a DT entry for the ROM area while specifying it as syscon.
> 
> Version 9 patches can be found here
> https://lkml.org/lkml/2015/8/12/530
> 
> Version 8 patches can be found here
> https://lkml.org/lkml/2015/8/10/566
> 
> Version 7 patches can be found here
> https://lkml.org/lkml/2015/8/6/440
> 
> Version 6 RFC patches can be found here
> http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05123.html
> 
> Version 5 of the patchset can be found here
> http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03787.html
> 
> Version 4 of the patchset can be found here
> https://lkml.org/lkml/2015/5/26/199
> 
> Version 3 of the patchset can be found here
> http://www.spinics.net/lists/arm-kernel/msg420847.html
> 
> Version 2 of the patchset can be found here
> http://www.spinics.net/lists/devicetree/msg80654.html
> 
> Version 1 of the patchset can be found here
> http://www.spinics.net/lists/devicetree/msg80257.html
> 
> The RFC version can be found here
> https://lkml.org/lkml/2015/5/11/13
> 
> Thanks & Regards,
> Sanchayan Maity.
> 
> Sanchayan Maity (4):
>   clk: clk-vf610: Add clock for Vybrid OCOTP controller
>   ARM: dts: vfxxx: Add OCOTP node
>   drivers: nvmem: Add Vybrid OCOTP support
>   nvmem: Add DT binding documentation for Vybrid OCOTP driver
> 
>  .../devicetree/bindings/nvmem/vf610-ocotp.txt  |  19 ++
>  arch/arm/boot/dts/vfxxx.dtsi   |   8 +
>  drivers/clk/imx/clk-vf610.c|   1 +
>  drivers/nvmem/Kconfig  |  10 +
>  drivers/nvmem/Makefile |   2 +
>  drivers/nvmem/vf610-ocotp.c| 302 
> +
>  include/dt-bindings/clock/vf610-clock.h|   3 +-
>  7 files changed, 344 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
>  create mode 100644 drivers/nvmem/vf610-ocotp.c
> 
> -- 
> 2.5.1
> 
--
To unsubscribe from this list: 

Re: [PATCH 10/14] ARM: dts: qs600: Add missing pinctrl property for gsbi7 uart

[Igor Grinberg]

On 09/18/15 15:31, Srinivas Kandagatla wrote:
> This patch adds missing 2pin uart pinctrl property to gsbi7 uart on
> CM-QS600.
> 
> Signed-off-by: Srinivas Kandagatla 

Acked-by: Igor Grinberg 

> ---
>  arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts 
> b/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
> index bdea747..8aac3be 100644
> --- a/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
> +++ b/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
> @@ -101,6 +101,8 @@
>   qcom,mode = ;
>   serial@1664 {
>   status = "ok";
> + pinctrl-names = "default";
> + pinctrl-0 = <_uart_2pins>;
>   };
>   };
>  
> 

-- 
Regards,
Igor.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 14/14] ARM: dts: qs600: Add SD card detect support.

[Igor Grinberg]

On 09/18/15 15:32, Srinivas Kandagatla wrote:
> This patch adds SD card detect support.
> 
> Signed-off-by: Srinivas Kandagatla 

Acked-by: Igor Grinberg 

> ---
>  arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts 
> b/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
> index cc9d942..03784f1 100644
> --- a/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
> +++ b/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
> @@ -29,6 +29,16 @@
>   };
>  
>   soc {
> + pinctrl@80 {
> + card_detect: card_detect {
> + mux {
> + pins = "gpio26";
> + function = "gpio";
> + bias-disable;
> + };
> + };
> + };
> +
>   rpm@108000 {
>   regulators {
>   vin_lvs1_3_6-supply = <_s4>;
> @@ -197,6 +207,9 @@
>   sdcc3: sdcc@1218 {
>   status = "okay";
>   vmmc-supply = <_fixed>;
> + pinctrl-names   = "default";
> + pinctrl-0   = <_detect>;
> + cd-gpios= <_pinmux 26 
> GPIO_ACTIVE_LOW>;
>   };
>   /* WLAN */
>   sdcc4: sdcc@121c {
> 

-- 
Regards,
Igor.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] perf tools: Use postorder rbtree iteration when removing symbols

[Ingo Molnar]

* Alex Snast  wrote:

> What's the benefit of having that diverge check script as on every commit 
> you'll 
> either add the new stuff to tools/include/linux/rbtree.h or add an exception 
> to 
> that script as in rb_link_node_rcu case.

The benefit is that things do not diverge - diff or md5sum is fast enough.

I don't think exceptions should be added, we should find ways to make the files 
100% identical.

> And are you suggesting to check for divergence for everything under tools/ 
> include/linux recursively?

No, on a case by case basis, for bigger 'facility files' we copied from the 
kernel 
source.

rbtree.h and rbtree.c certainly applies: for example we've got interval rbtree 
additions in -tip that would be nice to merge upstream:

  tools/kvm/include/kvm/rbtree-interval.h
  tools/kvm/util/rbtree-interval.c

... but which have bitrotten meanwhile, making the copy out of sync and harder 
to 
merge. Making sure the files are properly upstreamed during build time makes 
sure 
things don't get out of sync.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: OMAP: Remove duplicated operand in OR operation

[Roger Quadros]

On 17/09/15 16:22, Javier Martinez Canillas wrote:
> Commit b483a4a5a711 ("ARM: OMAP4+: hwmod data: Don't prevent RESET of
> USB Host module") added the SYSC_HAS_RESET_STATUS flag to both OMAP4
> and OMAP5 USB host module hwmon sysconfig but that flag was already
> set for OMAP5. So now the flag appears twice in the expression.
> 
> make coccicheck complains with the following message:
> 
> omap_hwmod_54xx_data.c:1846:37-58: duplicated argument to & or |
> 
> Signed-off-by: Javier Martinez Canillas 

Acked-by: Roger Quadros 

> 
> ---
> 
>  arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c 
> b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> index 7c3fac035e93..8cdfd9b7ab4f 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> @@ -1844,8 +1844,7 @@ static struct omap_hwmod_class_sysconfig 
> omap54xx_usb_host_hs_sysc = {
>   .rev_offs   = 0x,
>   .sysc_offs  = 0x0010,
>   .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_RESET_STATUS |
> -SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
> -SYSC_HAS_RESET_STATUS),
> +SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
>   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
>  SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
>  MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
> 

--
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 9/9] zram: use crypto decompress_noctx API

[Sergey Senozhatsky]

On (09/18/15 14:19), Joonsoo Kim wrote:
[..]
> + /*
> +  * Prepare to use crypto decompress_noctx API. One tfm is required
> +  * to initialize crypto algorithm properly and fetch corresponding
> +  * function pointer. But, it is sharable for multiple concurrent
> +  * decompress users.
> +  */

if comp algorithm require zstrm for both compression and decompression,
then there seems to be no need in allocating sharable ->tfm_noctx, we
will never use it.

-ss

> + tfm = crypto_alloc_comp_noctx(compress, 0, 0);
> + if (!IS_ERR(tfm))
> + comp->tfm_noctx = tfm;
> +
>   return comp;
>  }
> diff --git a/drivers/block/zram/zcomp.h b/drivers/block/zram/zcomp.h
> index 4f9df8e..c76d8e4 100644
> --- a/drivers/block/zram/zcomp.h
> +++ b/drivers/block/zram/zcomp.h
> @@ -26,6 +26,7 @@ struct zcomp_strm {
>  /* dynamic per-device compression frontend */
>  struct zcomp {
>   void *stream;
> + struct crypto_comp *tfm_noctx;
>   const char *backend;
>  
>   struct zcomp_strm *(*strm_find)(struct zcomp *comp);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [char-misc 1/2] mei: Fix debugfs filename in error output

[Winkler, Tomas]

> -Original Message-
> From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> Sent: Monday, September 21, 2015 10:37
> To: Alexander Kuleshov
> Cc: Winkler, Tomas; Arnd Bergmann; Usyskin, Alexander; LKML
> Subject: Re: [char-misc 1/2] mei: Fix debugfs filename in error output
> 
> On Mon, Sep 21, 2015 at 01:07:21PM +0600, Alexander Kuleshov wrote:
> > Hello Greg,
> >
> > On Mon, Sep 21, 2015 at 8:25 AM, Greg Kroah-Hartman
> >  wrote:
> > > On Mon, Aug 24, 2015 at 03:27:36PM +0300, Tomas Winkler wrote:
> > >> From: "Signed-off-by: Alexander Kuleshov" 
> > >
> > > I kind of doubt that's the real author name :(
> > >
> >
> > Why? I've definitely sent this patch sometime ago
> > (https://lkml.org/lkml/2015/8/14/560)
> 
> Look at the line carefully.

I will resend w/o signed off
Tomas

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 4.3-rc1 dirty page count underflow (cgroup-related?)

[Greg Thelen]

Dave Hansen wrote:

> On 09/17/2015 11:09 PM, Greg Thelen wrote:
>> I'm not denying the issue, bug the WARNING splat isn't necessarily
>> catching a problem.  The corresponding code comes from your debug patch:
>> +
>> WARN_ONCE(__this_cpu_read(memcg->stat->count[MEM_CGROUP_STAT_DIRTY]) > 
>> (1UL<<30), "MEM_CGROUP_STAT_DIRTY bogus");
>> 
>> This only checks a single cpu's counter, which can be negative.  The sum
>> of all counters is what matters.
>> Imagine:
>> cpu1) dirty page: inc
>> cpu2) clean page: dec
>> The sum is properly zero, but cpu2 is -1, which will trigger the WARN.
>> 
>> I'll look at the code and also see if I can reproduce the failure using
>> mem_cgroup_read_stat() for all of the new WARNs.
>
> D'oh.  I'll replace those with the proper mem_cgroup_read_stat() and
> test with your patch to see if anything still triggers.

Thanks Dave.

Here's what I think we should use to fix the issue.  I tagged this for
v4.2 stable given the way that unpatched performance falls apart without
warning or workaround (besides deleting and recreating affected memcg).
Feedback welcome.

>From f5c39c2e8471c10fe0464ca7b6e6f743ce6920a6 Mon Sep 17 00:00:00 2001
From: Greg Thelen 
Date: Sat, 19 Sep 2015 16:21:18 -0700
Subject: [PATCH] memcg: fix dirty page migration

The problem starts with a file backed dirty page which is charged to a
memcg.  Then page migration is used to move oldpage to newpage.
Migration:
- copies the oldpage's data to newpage
- clears oldpage.PG_dirty
- sets newpage.PG_dirty
- uncharges oldpage from memcg
- charges newpage to memcg

Clearing oldpage.PG_dirty decrements the charged memcg's dirty page
count.  However, because newpage is not yet charged, setting
newpage.PG_dirty does not increment the memcg's dirty page count.  After
migration completes newpage.PG_dirty is eventually cleared, often in
account_page_cleaned().  At this time newpage is charged to a memcg so
the memcg's dirty page count is decremented which causes underflow
because the count was not previously incremented by migration.  This
underflow causes balance_dirty_pages() to see a very large unsigned
number of dirty memcg pages which leads to aggressive throttling of
buffered writes by processes in non root memcg.

This issue:
- can harm performance of non root memcg buffered writes.
- can report too small (even negative) values in
  memory.stat[(total_)dirty] counters of all memcg, including the root.

To avoid polluting migrate.c with #ifdef CONFIG_MEMCG checks, introduce
page_memcg() and set_page_memcg() helpers.

Test:
0) setup and enter limited memcg
mkdir /sys/fs/cgroup/test
echo 1G > /sys/fs/cgroup/test/memory.limit_in_bytes
echo $$ > /sys/fs/cgroup/test/cgroup.procs

1) buffered writes baseline
dd if=/dev/zero of=/data/tmp/foo bs=1M count=1k
sync
grep ^dirty /sys/fs/cgroup/test/memory.stat

2) buffered writes with compaction antagonist to induce migration
yes 1 > /proc/sys/vm/compact_memory &
rm -rf /data/tmp/foo
dd if=/dev/zero of=/data/tmp/foo bs=1M count=1k
kill %
sync
grep ^dirty /sys/fs/cgroup/test/memory.stat

3) buffered writes without antagonist, should match baseline
rm -rf /data/tmp/foo
dd if=/dev/zero of=/data/tmp/foo bs=1M count=1k
sync
grep ^dirty /sys/fs/cgroup/test/memory.stat

   (speed, dirty residue)
 unpatched   patched
1) 841 MB/s 0 dirty pages  886 MB/s 0 dirty pages
2) 611 MB/s -33427456 dirty pages  793 MB/s 0 dirty pages
3) 114 MB/s -33427456 dirty pages  891 MB/s 0 dirty pages

Notice that unpatched baseline performance (1) fell after
migration (3): 841 -> 114 MB/s.  In the patched kernel, post
migration performance matches baseline.

Fixes: c4843a7593a9 ("memcg: add per cgroup dirty page accounting")
Cc:  # 4.2+
Reported-by: Dave Hansen 
Signed-off-by: Greg Thelen 
---
 include/linux/mm.h | 21 +
 mm/migrate.c   | 12 +++-
 2 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 91c08f6f0dc9..80001de019ba 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -905,6 +905,27 @@ static inline void set_page_links(struct page *page, enum 
zone_type zone,
 #endif
 }
 
+#ifdef CONFIG_MEMCG
+static inline struct mem_cgroup *page_memcg(struct page *page)
+{
+   return page->mem_cgroup;
+}
+
+static inline void set_page_memcg(struct page *page, struct mem_cgroup *memcg)
+{
+   page->mem_cgroup = memcg;
+}
+#else
+static inline struct mem_cgroup *page_memcg(struct page *page)
+{
+   return NULL;
+}
+
+static inline void set_page_memcg(struct page *page, struct mem_cgroup *memcg)
+{
+}
+#endif
+
 /*
  * Some inline functions in vmstat.h depend on page_zone()
  */
diff --git a/mm/migrate.c b/mm/migrate.c
index c3cb566af3e2..6116b8f64d27 100644

RE: [PATCH] mei, make modules.alias UUID information easier to read

[Winkler, Tomas]

> -Original Message-
> From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> Sent: Monday, September 21, 2015 05:25
> To: Prarit Bhargava
> Cc: linux-kernel@vger.kernel.org; Winkler, Tomas; Joe Perches; David S. 
> Miller; Jiri
> Kosina; Sharon Dvir; Suthikulpanit, Suravee; Heikki Krogerus; James Hogan; 
> Daniel
> Thompson; Michael Opdenacker; David Cohen; Felipe Balbi; Ralf Baechle
> Subject: Re: [PATCH] mei, make modules.alias UUID information easier to read
> 
> On Fri, Aug 14, 2015 at 09:05:40AM -0400, Prarit Bhargava wrote:
> > 2nd try on this ...
> 
> What changed from the first patch?  I need some "version information" to
> figure out what is going on.
> 
> Can you resend it with that information?
> 
> thanks,

I saw you've already merged it to the testing branch so I'm not resending, 
Anyhow the original patch was done over Linus'  master branch instead of 
char-misc-next so it needed a rebase. 

Thanks.
Tomas

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: dts: fix usb pin control for imx-rex dts

[Felipe Tonello]

On Wed, Sep 16, 2015 at 6:40 PM,   wrote:
> From: "Felipe F. Tonello" 
>
> This fixes a duplicated pin control causing this error:
>
> imx6q-pinctrl 20e.iomuxc: pin MX6Q_PAD_GPIO_1 already
> requested by regulators:regulator@2; cannot claim for 2184000.usb
> imx6q-pinctrl 20e.iomuxc: pin-137 (2184000.usb) status -22
> imx6q-pinctrl 20e.iomuxc: could not request pin 137
> (MX6Q_PAD_GPIO_1) from group usbotggrp  on device 20e.iomuxc
> imx_usb 2184000.usb: Error applying setting, reverse things
> back
> imx6q-pinctrl 20e.iomuxc: pin MX6Q_PAD_EIM_D31 already
> requested by regulators:regulator@1; cannot claim for 2184200.usb
> imx6q-pinctrl 20e.iomuxc: pin-52 (2184200.usb) status -22
> imx6q-pinctrl 20e.iomuxc: could not request pin 52 (MX6Q_PAD_EIM_D31)
> from group usbh1grp  on device 20e.iomuxc
> imx_usb 2184200.usb: Error applying setting, reverse things
> back
>
> Signed-off-by: Felipe F. Tonello 

Any comments?

Felipe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] iio: gyro: ssp_gyro_sensor: Use devm_iio_device_register

[Karol Wrona]

On 09/20/2015 09:18 PM, Jonathan Cameron wrote:
> On 14/09/15 17:08, Vaishali Thakkar wrote:
>> Use resourced managed function devm_iio_device_register to
>> make error path simpler. To be compatible with the change,
>> the remove function is removed as it is now redundant.
>>
>> Signed-off-by: Vaishali Thakkar 
> This patch is reasonable, but makes me wonder if there is an issue
> in the remove path for this driver.  It relies on the ssp_sensors common
> module.  That in ssp_spi.c uses the fact ssp_register_consumer
> has saved the struct iio_dev into a local array in the core driver.
> I think this means that a remove of this function will leave a possible
> null pointer de reference.
You are right. In this case we need something like
ssp_deregister_consumer(...) in ssp_dev.c. So I think that "remove func"
should stay. Of course we can switch to devm iio register.

Also the same can (rather should) be done for accelerometer sensor
(ssp_accel_sensor.c).

Vaishali, if you want please feel free and send patch.

> 
> Now I suspect that case doesn't actually occur because the relevant
> device elements are disabled whenever this module is removed.  Having
> said that we might expect an ssp_unregister_consumer function that
> sets the relevant pointer back to null on removal so as to avoid
> any possible race conditions around driver removal / reprobing.
> A spot of defensive programming rather than necessarily a bug to be
> fixed!
> 
> One little process thing. This driver was written by Karol so patches
> should probably always cc Karol as well as the more general
> maintainer / reviewers for IIO.  Added cc.
> 
> Jonathan
>> ---
>>  drivers/iio/gyro/ssp_gyro_sensor.c | 12 +---
>>  1 file changed, 1 insertion(+), 11 deletions(-)
>>
>> diff --git a/drivers/iio/gyro/ssp_gyro_sensor.c 
>> b/drivers/iio/gyro/ssp_gyro_sensor.c
>> index 0a8afdd..ac88de7 100644
>> --- a/drivers/iio/gyro/ssp_gyro_sensor.c
>> +++ b/drivers/iio/gyro/ssp_gyro_sensor.c
>> @@ -134,7 +134,7 @@ static int ssp_gyro_probe(struct platform_device *pdev)
>>  
>>  platform_set_drvdata(pdev, indio_dev);
>>  
>> -ret = iio_device_register(indio_dev);
>> +ret = devm_iio_device_register(>dev, indio_dev);
>>  if (ret < 0)
>>  return ret;
>>  
>> @@ -144,21 +144,11 @@ static int ssp_gyro_probe(struct platform_device *pdev)
>>  return 0;
>>  }
>>  
>> -static int ssp_gyro_remove(struct platform_device *pdev)
>> -{
>> -struct iio_dev *indio_dev = platform_get_drvdata(pdev);
>> -
>> -iio_device_unregister(indio_dev);
>> -
>> -return 0;
>> -}
>> -
>>  static struct platform_driver ssp_gyro_driver = {
>>  .driver = {
>>  .name = SSP_GYROSCOPE_NAME,
>>  },
>>  .probe = ssp_gyro_probe,
>> -.remove = ssp_gyro_remove,
>>  };
>>  
>>  module_platform_driver(ssp_gyro_driver);
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC 6/7] ASoC: tlv320aic26: Add support for DSP_B data format

[Peter Ujfalusi]

On 09/18/2015 11:11 PM, Cormier, Jonathan wrote:
> Signed-off-by: Cormier, Jonathan 
> ---
>  sound/soc/codecs/tlv320aic26.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/sound/soc/codecs/tlv320aic26.c b/sound/soc/codecs/tlv320aic26.c
> index c3b0a698ea66..5c5641cd28de 100644
> --- a/sound/soc/codecs/tlv320aic26.c
> +++ b/sound/soc/codecs/tlv320aic26.c
> @@ -211,6 +211,7 @@ static int aic26_set_fmt(struct snd_soc_dai *codec_dai, 
> unsigned int fmt)
>   switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
>   case SND_SOC_DAIFMT_I2S: aic26->datfm = AIC26_DATFM_I2S; break;
>   case SND_SOC_DAIFMT_DSP_A:   aic26->datfm = AIC26_DATFM_DSP; break;
> + case SND_SOC_DAIFMT_DSP_B:   aic26->datfm = AIC26_DATFM_DSP; break;

Are you sure about this? According to the datasheet:
www.ti.com/litv/slas412 page 18 there is no bit to change the data delay and
the format the codec supports is DSP_A.

>   case SND_SOC_DAIFMT_RIGHT_J: aic26->datfm = AIC26_DATFM_RIGHTJ; break;
>   case SND_SOC_DAIFMT_LEFT_J:  aic26->datfm = AIC26_DATFM_LEFTJ; break;
>   default:
> 


-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [char-misc 1/2] mei: Fix debugfs filename in error output

[Alexander Kuleshov]

Hello Greg,

On Mon, Sep 21, 2015 at 8:25 AM, Greg Kroah-Hartman
 wrote:
> On Mon, Aug 24, 2015 at 03:27:36PM +0300, Tomas Winkler wrote:
>> From: "Signed-off-by: Alexander Kuleshov" 
>
> I kind of doubt that's the real author name :(
>

Why? I've definitely sent this patch sometime ago
(https://lkml.org/lkml/2015/8/14/560)

Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.14 00/29] 3.14.53-stable review

[Sudip Mukherjee]

On Sat, Sep 19, 2015 at 10:27:22AM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.14.53 release.
> There are 29 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 Mon Sep 21 17:18:53 UTC 2015.
> Anything received after that time might be too late.
Compiled and booted on x86_32. No errors in dmesg (with the tty patch
applied).

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: blk_mq_register_disk: kobject (00000000009f2dd8): tried to init an initialized object, something is seriously wrong.

[Ming Lei]

On Tue, Sep 15, 2015 at 3:06 AM, Meelis Roos  wrote:
> This is 4.3.0-rc1 on Sun E220R (dual-CPU sparc64). Sometimes it boots,
> sometimes it fails to boot with looping errors and finally a watchdog
> timeout. This console log from a failure. Config is below.
>
> [0.00] PROMLIB: Sun IEEE Boot Prom 'OBP 3.31.0 2001/07/25 20:31'
> [0.00] PROMLIB: Root node compatible:
> [0.00] Linux version 4.3.0-rc1 (mroos@e220r) (gcc version 4.9.2 
> (Debian 4.9.2-20) ) #65 SMP Sun Sep 13 19:53:46 EEST 2015
> [0.00] debug: ignoring loglevel setting.
> [0.00] bootconsole [earlyprom0] enabled
> [0.00] ARCH: SUN4U
> [0.00] Ethernet address: 08:00:20:c7:a3:81
> [0.00] MM: PAGE_OFFSET is 0xf800 (max_phys_bits == 40)
> [0.00] MM: VMALLOC [0x0001 --> 0x0600]
> [0.00] MM: VMEMMAP [0x0600 --> 0x0c00]
> [0.00] Kernel: Using 2 locked TLB entries for main kernel image.
> [0.00] Remapping the kernel... done.
> [0.00] kmemleak: Kernel memory leak detector disabled
> [0.00] OF stdout device is: /pci@1f,4000/ebus@1/se@14,40:a
> [0.00] PROM: Built device tree with 91663 bytes of memory.
> [0.00] Top of RAM: 0xaff18000, Total RAM: 0x3ff06000
> [0.00] Memory hole size: 1792MB
> [0.00] Allocated 16384 bytes for kernel page tables.
> [0.00] Zone ranges:
> [0.00]   Normal   [mem 0x-0xaff17fff]
> [0.00] Movable zone start for each node
> [0.00] Early memory node ranges
> [0.00]   node   0: [mem 0x-0x0fff]
> [0.00]   node   0: [mem 0x2000-0x2fff]
> [0.00]   node   0: [mem 0x8000-0x8fff]
> [0.00]   node   0: [mem 0xa000-0xafeedfff]
> [0.00]   node   0: [mem 0xaff0-0xaff17fff]
> [0.00] Initmem setup node 0 [mem 
> 0x-0xaff17fff]
> [0.00] On node 0 totalpages: 130947
> [0.00]   Normal zone: 1024 pages used for memmap
> [0.00]   Normal zone: 0 pages reserved
> [0.00]   Normal zone: 130947 pages, LIFO batch:15
> [0.00] Booting Linux...
> [0.00] CPU CAPS: [flush,stbar,swap,muldiv,v9,mul32,div32,v8plus]
> [0.00] CPU CAPS: [vis]
> [0.00] PERCPU: Embedded 8 pages/cpu @f800af80 s22976 r8192 
> d34368 u2097152
> [0.00] pcpu-alloc: s22976 r8192 d34368 u2097152 alloc=1*4194304
> [0.00] pcpu-alloc: [0] 0 2
> [0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
> pages: 129923
> [0.00] Kernel command line: root=/dev/sda2 ro ignore_loglevel
> [0.00] PID hash table entries: 4096 (order: 2, 32768 bytes)
> [0.00] Dentry cache hash table entries: 131072 (order: 7, 1048576 
> bytes)
> [0.00] Inode-cache hash table entries: 65536 (order: 6, 524288 bytes)
> [0.00] Sorting __ex_table...
> [0.00] Memory: 1022624K/1047576K available (4205K kernel code, 251K 
> rwdata, 1288K rodata, 264K init, 418K bss, 24952K reserved, 0K cma-reserved)
> [0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=3, Nodes=1
> [0.00] Hierarchical RCU implementation.
> [0.00]  Build-time adjustment of leaf fanout to 64.
> [0.00]  RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=3.
> [0.00] RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=3
> [0.00] NR_IRQS:2048 nr_irqs:2048 1
> [   79.762547] clocksource: tick: mask: 0x max_cycles: 
> 0x530919c4ff, max_idle_ns: 440795210743 ns
> [   79.882019] clocksource: mult[2c709c3] shift[24]
> [   79.937217] clockevent: mult[5c2b61ba] shift[32]
> [   79.992661] Console: colour dummy device 80x25
> [   80.045592] console [tty0] enabled
> [   80.086169] bootconsole [earlyprom0] disabled
> [0.00] PROMLIB: Sun IEEE Boot Prom 'OBP 3.31.0 2001/07/25 20:31'
> [0.00] PROMLIB: Root node compatible:
> [0.00] Linux version 4.3.0-rc1 (mroos@e220r) (gcc version 4.9.2 
> (Debian 4.9.2-20) ) #65 SMP Sun Sep 13 19:53:46 EEST 2015
> [0.00] debug: ignoring loglevel setting.
> [0.00] bootconsole [earlyprom0] enabled
> [0.00] ARCH: SUN4U
> [0.00] Ethernet address: 08:00:20:c7:a3:81
> [0.00] MM: PAGE_OFFSET is 0xf800 (max_phys_bits == 40)
> [0.00] MM: VMALLOC [0x0001 --> 0x0600]
> [0.00] MM: VMEMMAP [0x0600 --> 0x0c00]
> [0.00] Kernel: Using 2 locked TLB entries for main kernel image.
> [0.00] Remapping the kernel... done.
> [0.00] kmemleak: Kernel memory leak detector disabled
> [0.00] OF stdout device is: /pci@1f,4000/ebus@1/se@14,40:a
> [0.00] PROM: Built device tree with 91663 bytes of memory.
> [

Re: [PATCH 1/5] usb: common: of_usb_get_maximum_speed to usb_get_maximum_speed

[Heikki Krogerus]

On Fri, Sep 18, 2015 at 02:42:15PM -0500, Felipe Balbi wrote:
> On Tue, Aug 25, 2015 at 02:04:31PM +0300, Heikki Krogerus wrote:
> > By using the unified device property interface, the function
> > can be made available for all platforms and not just the
> > ones using DT.
> > 
> > Signed-off-by: Heikki Krogerus 
> 
> this breaks compilation of my current testing/next.

OK. I'll rebase these on top of that branch.


Thanks,

-- 
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] avr32: fix build failure

[Hans-Christian Egtvedt]

Around Mon 21 Sep 2015 12:09:01 +0530 or thereabout, Sudip Mukherjee wrote:
> On Mon, Sep 21, 2015 at 08:09:42AM +0200, Hans-Christian Egtvedt wrote:
>> Around Sat 19 Sep 2015 22:42:57 +0530 or thereabout, Sudip Mukherjee wrote:
>> > While building avr32 with allmodconfig, the build used to fail with the
>> > message:
>> > error: implicit declaration of function 'pci_iomap'
>> > error: implicit declaration of function 'pci_iounmap'
>> 
>> What has changed recently that start pulling in these? AVR32 does not have
>> PCI at all, and will never have it either. Is this exposing a bug somewhere
>> else?
> It looks like pci_iomap and pci_iounmap doesnot depend on CONFIG_PCI.
> So drivers/net/ethernet/via/via-rhine.c is calling these functions even
> if PCI is disabled. The build log is at:
> https://travis-ci.org/sudipm-mukherjee/parport/jobs/81127188
> 
> You can find a similar discussion at:
> http://www.linux-mips.org/archives/linux-mips/2013-06/msg00510.html

If multiple architectures have similar problems, then a more global
definition of these unused functions could be added.

Just move the implementation for MIPS into include/asm-generic/io.h ?

That way we do not have to implement and identical stub for every device not
supporting PCI.

-- 
mvh
Hans-Christian Egtvedt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/5] pinctrl: berlin: add the berlin4ct pinctrl driver

[Jisheng Zhang]

Dear Sebastian,

On Sun, 20 Sep 2015 21:32:37 +0200
Sebastian Hesselbarth  wrote:

> On 19.09.2015 12:02, Jisheng Zhang wrote:
> > Add the pin-controller driver for Marvell Berlin BG4CT SoC, with definition
> > of its groups and functions. This uses the core Berlin pinctrl driver.
> >
> > Signed-off-by: Jisheng Zhang 
> > ---
> [...]
> > diff --git a/drivers/pinctrl/berlin/berlin4ct.c 
> > b/drivers/pinctrl/berlin/berlin4ct.c
> > new file mode 100644
> > index 000..2960e16
> > --- /dev/null
> > +++ b/drivers/pinctrl/berlin/berlin4ct.c
> > @@ -0,0 +1,503 @@
> > +/*
> > + * Marvell berlin4ct pinctrl driver
> [...]
> > +static const struct berlin_desc_group berlin4ct_soc_pinctrl_groups[] = {
> > +   BERLIN_PINCTRL_GROUP("EMMC_RSTn", 0x0, 0x3, 0x00,
> > +   BERLIN_PINCTRL_FUNCTION(0x0, "emmc_rstn"),
> > +   BERLIN_PINCTRL_FUNCTION(0x1, "gpio47")),
> 
> Jisheng,
> 
> I am fine with naming the groups after the 0x0 function but
> the functions themselves should be named after a generic
> name, e.g. "emmc" instead of "emmc_rstn".

This seems better. Will change in newer version.

> 
> That will allow to add pinmux nodes like
> 
> uart_pmx {
>   groups = "SM_UART0_TXD", "SM_UART0_RXD";
>   function = "uart0";
> };
> 
> instead of two separate nodes like in patch 5/5.
> 
> You should however keep the actual pin function e.g. in a comment
> after the function define above:
> 
> BERLIN_PINCTRL_GROUP("EMMC_RSTn", 0x0, 0x3, 0x00,
>   BERLIN_PINCTRL_FUNCTION(0x0, "emmc"),   /* RESETn */
>   BERLIN_PINCTRL_FUNCTION(0x1, "gpio")),  /* GPIO47 */
> 
> > +   BERLIN_PINCTRL_GROUP("NAND_IO0", 0x0, 0x3, 0x03,
> > +   BERLIN_PINCTRL_FUNCTION(0x0, "nand_io0"),
> > +   BERLIN_PINCTRL_FUNCTION(0x1, "rgmii_rxd0"),
> > +   BERLIN_PINCTRL_FUNCTION(0x2, "sd1_clk"),
> > +   BERLIN_PINCTRL_FUNCTION(0x3, "gpio0")),
> [...]
> > +   BERLIN_PINCTRL_GROUP("SD0_CLK", 0x4, 0x3, 0x12,
> > +   BERLIN_PINCTRL_FUNCTION(0x0, "gpio29"),
> > +   BERLIN_PINCTRL_FUNCTION(0x1, "sd0_clk"),
> > +   BERLIN_PINCTRL_FUNCTION(0x2, "sts4_clk"),
> 
> Please find a better name for "sts" whatever it is for.

sts is one kind of HW component, and that's what we called it.

> 
> > +   BERLIN_PINCTRL_FUNCTION(0x5, "v4g_dbg8"),
> 
> ditto for "v4g"

v4g is another kind of HW component which is called as "v4g"

> 
> > +   BERLIN_PINCTRL_FUNCTION(0x7, "phy_dbg8")),
> [...]
> > +   BERLIN_PINCTRL_GROUP("SCRD0_RST", 0xc, 0x3, 0x06,
> > +   BERLIN_PINCTRL_FUNCTION(0x0, "gpio15"),
> > +   BERLIN_PINCTRL_FUNCTION(0x1, "scrd0_rst"),
> 
> ditto for "scrd0"

scrd stands for smartcard. But it's what HW/ASIC call them

> 
> > +   BERLIN_PINCTRL_FUNCTION(0x3, "sd1a_clk")),
> > +   BERLIN_PINCTRL_GROUP("SCRD0_DCLK", 0xc, 0x3, 0x09,
> > +   BERLIN_PINCTRL_FUNCTION(0x0, "gpio16"),
> > +   BERLIN_PINCTRL_FUNCTION(0x1, "scrd0_dclk"),
> > +   BERLIN_PINCTRL_FUNCTION(0x3, "sd1a_cmd")),
> 
> What is the "a" for in "sd1a" ? There is a "sd1b" below so I
> guess that there is two pinmux groups that mux sd1?

Yes, correct.

> 
> > +   BERLIN_PINCTRL_GROUP("SCRD0_GPIO0", 0xc, 0x3, 0x0c,
> > +   BERLIN_PINCTRL_FUNCTION(0x0, "gpio17"),
> > +   BERLIN_PINCTRL_FUNCTION(0x1, "scrd0_gpio0"),
> > +   BERLIN_PINCTRL_FUNCTION(0x2, "sif_dio"),
> 
> What kind of interface is "sif" ?

serial interface, ASIC called it as SIF

> 
> > +   BERLIN_PINCTRL_FUNCTION(0x3, "sd1a_dat0")),
> [...]
> > +static const struct berlin_desc_group berlin4ct_soc_aviopinctrl_groups[] = 
> > {
> > +   BERLIN_PINCTRL_GROUP("TX_EDDC_SCL", 0x0, 0x3, 0x00,
> > +   BERLIN_PINCTRL_FUNCTION(0x0, "avio_gpio0"),
> > +   BERLIN_PINCTRL_FUNCTION(0x1, "tx_eddc_scl"),
> > +   BERLIN_PINCTRL_FUNCTION(0x2, "tw1_scl")),
> > +   BERLIN_PINCTRL_GROUP("TX_EDDC_SDA", 0x0, 0x3, 0x03,
> > +   BERLIN_PINCTRL_FUNCTION(0x0, "avio_gpio1"),
> > +   BERLIN_PINCTRL_FUNCTION(0x1, "tx_eddc_sda"),
> > +   BERLIN_PINCTRL_FUNCTION(0x2, "tw1_sda")),
> > +   BERLIN_PINCTRL_GROUP("I2S1_LRCKO", 0x0, 0x3, 0x06,
> > +   BERLIN_PINCTRL_FUNCTION(0x0, "avio_gpio2"),
> > +   BERLIN_PINCTRL_FUNCTION(0x1, "i2s1_lrcko"),
> > +   BERLIN_PINCTRL_FUNCTION(0x3, "sts6_clk"),
> > +   BERLIN_PINCTRL_FUNCTION(0x4, "adac_dbg0"),
> > +   BERLIN_PINCTRL_FUNCTION(0x6, "sd1b_clk"),
> > +   BERLIN_PINCTRL_FUNCTION(0x7, "avio_dbg0")),
> [...]
> > +static const struct berlin_desc_group berlin4ct_sysmgr_pinctrl_groups[] = {
> > +   BERLIN_PINCTRL_GROUP("SM_TW2_SCL", 0x0, 0x3, 0x00,
> > +  

Re: PCIe bus (re-)numbering

[Ruud]

>   /sbin/setpci -s $NAME 0x1a.b=0
>   N=`find /sys/devices/pci:"$BUS"/"$NAME"/remove -name "remove"`
>   echo $N
>   echo -n 1 > "$N"
>   sleep 1s
> done
> done
>

Thanks for the script!

>
>>
>> I will test next monday.
>
> Good. Please check current upstream and my tree for-pci-v4.3-rc1 branch.


Sorry for the rookie question: which version do you mean by "current
upstream", the current main trunk rc?.
I am currently using for-pci-v4.3-rc1 for testing.

>> Are these settings in the binary driver? I do not see that much need
>> for a driver to use the geographical addressing after the BAR's have
>> been set. I thus wondered if it is feasable to hide the geographical
>> addressing from the driver and offer an API for it from the PCIe layer
>> to the drivers...
>
> Card firmware.  Assume those card firmware would trap pci conf read cycle
> and compare something inside.
> The only workaround that I found is reset the link to make firmware rebooting.
> but that will have problem if you are use the disk as root etc.
>

I do not completely understand the remark you make, are you suggesting
the firmware running on the PCIe card (embedded in a CPU on the card
itself) is acting on the content of the busnumber or do you mean x86
extension rom code acting on the busnumber.

Although it is probably irrelevant for the problem I like to solve, I
still like to understand all details.


> Thanks
>
> Yinghai

BR,

Ruud
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -mm] mm/khugepaged: fix scan not aborted on SCAN_EXCEED_SWAP_PTE

[Vladimir Davydov]

On Sat, Sep 19, 2015 at 06:26:23PM +0200, Michal Hocko wrote:
> On Fri 18-09-15 18:43:23, Vladimir Davydov wrote:
> [...]
> > Fixes: acc067d59a1f9 ("mm: make optimistic check for swapin readahead")
> 
> This sha will not exist after the patch gets merged to the Linus tree
> from the Andrew tree. Either reference it just by the subject or simply
> mark it for Andrew to be folded into
> mm-make-optimistic-check-for-swapin-readahead.patch

AFAICS Andrew has already folded the fix into this patch:

  mm-make-optimistic-check-for-swapin-readahead-fix-2.patch

Thanks,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Michal Hocko]

On Mon 21-09-15 14:10:39, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> mm/vmscan.c: In function 'sane_reclaim':
> mm/vmscan.c:178:2: error: implicit declaration of function 'cgroup_on_dfl' 
> [-Werror=implicit-function-declaration]
>   if (cgroup_on_dfl(memcg->css.cgroup))
>   ^
> 
> Caused by commit
> 
>   d08255ab4d66 ("vmscan: fix sane_reclaim helper for legacy memcg")
> 
> interacting with commit
> 
>   9e10a130d9b6 ("cgroup: replace cgroup_on_dfl() tests in controllers with 
> cgroup_subsys_on_dfl()")
> 
> from the cgroup tree.
> 
> I don't know what the correct firx is here (help, please) so I have just
> open coded the cgroup_on_dfl() call for now:

AFAIU your fix is correct but using
cgroup_subsys_on_dfl(memory_cgrp_subsys) is more appropriate:
diff --git a/mm/vmscan.c b/mm/vmscan.c
index d62924ee8022..c3df03add73e 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -176,7 +176,7 @@ static bool sane_reclaim(struct scan_control *sc)
if (!memcg)
return true;
 #ifdef CONFIG_CGROUP_WRITEBACK
-   if (cgroup_on_dfl(memcg->css.cgroup))
+   if (cgroup_subsys_on_dfl(memory_cgrp_subsys))
return true;
 #endif
return false;

-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[char-misc 1/2 4.3 V2] mei: Fix debugfs filename in error output

[Tomas Winkler]

From: Alexander Kuleshov 

Signed-off-by: Alexander Kuleshov 
Signed-off-by: Tomas Winkler 
---
V2: fixed author address

 drivers/misc/mei/debugfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/mei/debugfs.c b/drivers/misc/mei/debugfs.c
index 4b469cf9e60f..c157f0ba575c 100644
--- a/drivers/misc/mei/debugfs.c
+++ b/drivers/misc/mei/debugfs.c
@@ -213,7 +213,7 @@ int mei_dbgfs_register(struct mei_device *dev, const char 
*name)
f = debugfs_create_file("active", S_IRUSR, dir,
dev, _dbgfs_fops_active);
if (!f) {
-   dev_err(dev->dev, "meclients: registration failed\n");
+   dev_err(dev->dev, "active: registration failed\n");
goto err;
}
f = debugfs_create_file("devstate", S_IRUSR, dir,
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Vladimir Davydov]

On Mon, Sep 21, 2015 at 02:10:39PM +1000, Stephen Rothwell wrote:
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> mm/vmscan.c: In function 'sane_reclaim':
> mm/vmscan.c:178:2: error: implicit declaration of function 'cgroup_on_dfl' 
> [-Werror=implicit-function-declaration]
>   if (cgroup_on_dfl(memcg->css.cgroup))
>   ^
> 
> Caused by commit
> 
>   d08255ab4d66 ("vmscan: fix sane_reclaim helper for legacy memcg")
> 
> interacting with commit
> 
>   9e10a130d9b6 ("cgroup: replace cgroup_on_dfl() tests in controllers with 
> cgroup_subsys_on_dfl()")
> 
> from the cgroup tree.
> 
> I don't know what the correct firx is here (help, please) so I have just
> open coded the cgroup_on_dfl() call for now:

Quoting Tejun (http://www.spinics.net/lists/linux-mm/msg94556.html):

: Just a heads-up.  I'm applying a patch which replaces cgroup_on_dfl()
: with cgroup_subsys_on_dfl() to cgroup/for-4.4, so this patch would
: need to be adjusted to do cgroup_subsys_on_dfl(memory_cgrp_subsys)
: instead.

Thanks,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 1/5] pwm: add the Berlin pwm controller driver

[Thierry Reding]

On Sun, Sep 20, 2015 at 08:13:48PM +0200, Sebastian Hesselbarth wrote:
> On 17.09.2015 12:13, Antoine Tenart wrote:
> >Add a PWM controller driver for the Marvell Berlin SoCs. This PWM
> >controller has 4 channels.
> >
> >Signed-off-by: Antoine Tenart 
> >Acked-by: Sebastian Hesselbarth 
> 
> Thierry,
> 
> if you are also fine with the driver, please let me know if you want
> me to take the driver through berlin-tree or if you are taking it.
> 
> I am taking the binding docs and dts changes anyway.

Sorry but no. The binding documentation needs to go into the same tree
as the driver because they need to be kept in sync. We can't have DT
binding documentation go into platform trees if the driver implementing
the binding hasn't been merged.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH 2/2] usb: gadget: f_midi: check for error on usb_ep_queue

[Felipe Tonello]

Hi Chen,

On Mon, Sep 21, 2015 at 7:30 AM, Peter Chen  wrote:
> On Fri, Sep 18, 2015 at 06:12:41PM +0100, e...@felipetonello.com wrote:
>> From: "Felipe F. Tonello" 
>>
>> f_midi is not checking weather the is an error on usb_ep_queue
>
> %s/weather/whether
> %s/the/there

I fixed it on v3. Did you receive it?

Felipe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] overlayfs: Fix dentry reference leak

[Miklos Szeredi]

Hi David,

Applied both patches.

Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] MMC/SDIO: enable SDIO device to suspend/resume asynchronously

[Adrian Hunter]

On 21/09/15 08:29, Fu, Zhonghui wrote:
> 
> 
> On 2015/8/24 15:07, Fu, Zhonghui wrote:
>>
>> On 2015/8/17 14:48, Adrian Hunter wrote:
>>> On 17/08/15 06:26, Fu, Zhonghui wrote:
 Hi,

 Any comments are welcome.


 Thanks,
 Zhonghui

 On 2015/7/30 15:40, Fu, Zhonghui wrote:
> Enable SDIO card and function device to suspend/resume asynchronously.
> This can improve system suspend/resume speed.
>>> For me, it needs more explanation.
>>>
>>> For example, why is this worth doing?  Can you give an example where it does
>>> significantly improve suspend/resume speed?  Are there any cases where it
>>> could be worse?
>>>
>>> Why is it safe?  Presumably it is safe if there are no dependencies on the
>>> device outside the device hierarchy. Is that so?  Are there any other
>>> potential pitfalls to enabling async_suspend?
>> Now, PM core support asynchronous device suspend/resume mode. If one device 
>> has been set to support asynchronous PM mode, it's suspend/resume operation 
>> can be performed in a separate kernel thread and take advantage of multicore 
>> feature to improve overall system suspend/resume speed. The worst case is 
>> that all device suspend/resume threads will be scheduled to the same CPU, it 
>> hardly occur.
>>
>> PM core ensure all the suspend/resume dependency related to one device. 
>> Actually, async suspend/resume mode is one feature of PM core, every device 
>> subsystem may use it or not use it. Once one device subsystem choose to use 
>> this feature, its safety is up to PM core as long as device subsystem has 
>> initialized fully this device.
> 
> The original suspend time is 1645ms and resume time is 940ms on ASUS T100TA
> machine. After enabling "wiphy device", "SDIO device", "mmc host" and
> "sdhci-acpi device" to suspend/resume asynchronously, the suspend time is
> 1096ms and resume time is 908ms. The test environment is listed as follows:
> 
> OS: Ubuntu 14.04
> Kernel: mainline v4.1
> Machine: ASUS T100TA(Baytrail-T platform)
> Tool: analyze_suspend
> “analyze_suspend.py –f –m freeze” to suspend system
> Press power button to resume system
> 
> I have resent this patch with updated commit message - "[PATCH v2] MMC/SDIO:
> enable SDIO device to suspend/resume asynchronously".

It is really cool that you tested this.  Thank you!

I am a bit baffled and bemused that you didn't put a summary of the testing
and results in the commit message.  Can you do that.

As I wrote, we are assuming that there are no dependencies on the device
outside the device hierarchy. That is a reasonable assumption for an SDIO
controller because it doesn't provide resources for other devices to use,
except for the card itself which is a child device, and therefore a
dependency that PM core knows about.

Does that make sense?  If it does then shouldn't that explanation be added
to the commit message too.  i.e. this is why we think it is always going to
work?

> 
> 
> Thanks,
> Zhonghui
>>
>>
>> Thanks,
>> Zhonghui  
> Signed-off-by: Zhonghui Fu 
> ---
>  drivers/mmc/core/sdio.c |4 
>  1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
> index b91abed..6719b77 100644
> --- a/drivers/mmc/core/sdio.c
> +++ b/drivers/mmc/core/sdio.c
> @@ -1106,6 +1106,8 @@ int mmc_attach_sdio(struct mmc_host *host)
>   pm_runtime_enable(>dev);
>   }
>  
> + device_enable_async_suspend(>dev);
> +
>   /*
>* The number of functions on the card is encoded inside
>* the ocr.
> @@ -1126,6 +1128,8 @@ int mmc_attach_sdio(struct mmc_host *host)
>*/
>   if (host->caps & MMC_CAP_POWER_OFF_CARD)
>   pm_runtime_enable(>sdio_func[i]->dev);
> +
> + device_enable_async_suspend(>sdio_func[i]->dev);
>   }
>  
>   /*
> -- 1.7.1
>

>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at  http://www.tux.org/lkml/
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC resend] Perf: Trigger and dump sample info to perf.data from user space ring buffer

[David Ahern]

On 9/21/15 9:16 PM, Yunlong Song wrote:

[Problem Background]

We want to run perf in daemon mode and collect the traces when the exception
(e.g., machine crashes, app performance goes down) appears. Perf may run for a
long time (from days to weeks or even months), since we do not know when the
exception will appear at all, however it will appear at some time (especially
for a beta product). If we simply use “perf record” as usual, here come two
problems as time goes by: 1 there will be large amounts of IOs created for 
writing
perf.data which may affects the performance a lot; 2 the size of perf.data will
be larger and larger as well. Although we can use eBPF to reduce the traces in
normal case, but in our case, the perf runs in daemon mode for a long time and
that will accumulate the traces as time goes by.


This is a perf-based scheduling daemon I wrote a few years ago:

https://github.com/dsahern/linux/blob/perf/full-monty/tools/perf/schedmon.c

It solves a similar problem by holding the last N-seconds or M-bytes of 
events in memory. When something of significance happens it is notified 
to dump events to a file. The events are scheduling tracepoints but 
could easily be anything else.


David


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: blk_mq_register_disk: kobject (00000000009f2dd8): tried to init an initialized object, something is seriously wrong.

[Ming Lei]

On Mon, Sep 21, 2015 at 7:43 PM, Meelis Roos  wrote:
>
>
> Yes, sorry - I applied the last chunk by hand because it was mangled by
> the web UI, and added ti to a wrong struct.
>
> Now I tested it on top of 4.3.0-rc1. COmpiles, rebooted fine 6 times,
> but now it hangs again, seems to be the same message:
>
> [  107.143910] kobject (009f2dd8): tried to init an initialized 
> object, something is seriously wrong.

Looks a bit odd since blk_mq_register_disk is run only once per device,
could you apply the attached debug patch and post the boot log when the
warning is triggered?

Thanks,
diff --git a/block/blk-mq-sysfs.c b/block/blk-mq-sysfs.c
index 279c5d6..d09c511 100644
--- a/block/blk-mq-sysfs.c
+++ b/block/blk-mq-sysfs.c
@@ -403,13 +403,20 @@ static void blk_mq_sysfs_init(struct request_queue *q)
 	struct blk_mq_ctx *ctx;
 	int i;
 
+	printk("%s: init mq_kobj %p\n", __func__, >mq_kobj);
 	kobject_init(>mq_kobj, _mq_ktype);
 
-	queue_for_each_hw_ctx(q, hctx, i)
+	queue_for_each_hw_ctx(q, hctx, i) {
+		printk("%s: init hctx_kobj %p %d\n", __func__,
+>kobj, i);
 		kobject_init(>kobj, _mq_hw_ktype);
+	}
 
-	queue_for_each_ctx(q, ctx, i)
+	queue_for_each_ctx(q, ctx, i) {
+		printk("%s: init ctx_kobj %p %d\n", __func__,
+>kobj, i);
 		kobject_init(>kobj, _mq_ctx_ktype);
+	}
 }
 
 /* see blk_register_queue() */

[PATCH] perf probe: Fix module probing with shortname

[Wang Nan]

After commit 3d39ac538629e4f00a6e1c38d46346f1b8e69505 ("perf machine:
No need to have two DSOs lists"), perf probe with module short name doesn't
work again. For example:

 # lsmod | grep e1000e
 e1000e233472  0

 # cat /proc/modules | grep e1000e
 e1000e 233472 0 - Live 0xa0073000

 # cat /proc/kallsyms | grep '\'
 a0093860 t e1000e_up[e1000e]

 # perf probe -v -m e1000e --add e1000e_up
 probe-definition(0): e1000e_up
 symbol:e1000e_up file:(null) line:0 offset:0 return:0 lazy:(null)
 0 arguments
 Failed to find module e1000e.
 Could not open debuginfo. Try to use symbols.
 Looking at the vmlinux_path (7 entries long)
 Using /lib/modules/4.2.0-rc7+/build/vmlinux for symbols
 e1000e_up is out of .text, skip it.
   Error: Failed to add events. Reason: No such file or directory (Code: -2)

This is caused by a misunderstood of dso->kernel in kernel_get_module_dso()
that, for kernel module, dso->kernel is DSO_TYPE_USER. dso->kernel is 
DSO_TYPE_KERNEL
iff dso is vmlinux.

This patch fix 'perf probe -m' with an ad-hoc way.

After this patch:

 # perf probe -v -m e1000e --add e1000e_up
 probe-definition(0): e1000e_up
 symbol:e1000e_up file:(null) line:0 offset:0 return:0 lazy:(null)
 0 arguments
 Open Debuginfo file: 
/lib/modules/4.2.0-rc7+/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko
 Try to find probe point from debuginfo.
 Matched function: e1000e_up
 Probe point found: e1000e_up+0
 Found 1 probe_trace_events.
 Opening /sys/kernel/debug/tracing//kprobe_events write=1
 Writing event: p:probe/e1000e_up e1000e:e1000e_up+0
 Added new event:
   probe:e1000e_up  (on e1000e_up in e1000e)

 You can now use it in all perf tools, such as:

perf record -e probe:e1000e_up -aR sleep 1

 # perf probe -l
 Failed to find debug information for address a0093860
   probe:e1000e_up  (on e1000e_up in e1000e)

Signed-off-by: Wang Nan 
Cc: Arnaldo Carvalho de Melo 
Cc: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
---

I think there may be other places where dso->kernel is misused.
machine__process_kernel_mmap_event() may be one of them. If I understand
correctly, 'dso->kernel && is_kernel_module(dso->long_name)' should always
false theoretically. However, I don't have enough time to check whether that
code really cause problem.

---
 tools/perf/util/probe-event.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 2b78e8f..c7d6d3d 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -270,7 +270,7 @@ static int kernel_get_module_dso(const char *module, struct 
dso **pdso)
 
if (module) {
list_for_each_entry(dso, _machine->dsos.head, node) {
-   if (!dso->kernel)
+   if (dso->kernel)
continue;
if (strncmp(dso->short_name + 1, module,
dso->short_name_len - 2) == 0)
-- 
1.8.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 2/3] net: macb: Add support for 1588 for Zynq Ultrascale+ MPSoC

[Harini Katakam]

Hi Richard,

On Tue, Sep 22, 2015 at 12:09 AM, Richard Cochran
 wrote:
> On Mon, Sep 21, 2015 at 11:19:32PM +0530, Harini Katakam wrote:
>> Ping
>
> 1) trim your replies
>
> 2) put the PTP maintainer on PTP patches for review
>

I'm sorry I missed that. Will do so in the future.

Regards,
Harini
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/3] ARM: uniphier: add outer cache support

[Masahiro Yamada]

Hi Russell,


2015-09-22 4:38 GMT+09:00 Russell King - ARM Linux :
> On Fri, Sep 18, 2015 at 01:37:32PM +0900, Masahiro Yamada wrote:
>> +/**
>> + * __uniphier_cache_maint_common - run a queue operation for a particular 
>> level
>> + *
>> + * @data: cache controller specific data
>> + * @start: start address of range operation (don't care for "all" operation)
>> + * @size: data size of range operation (don't care for "all" operation)
>> + * @operation: flags to specify the desired cache operation
>> + */
>> +static void __uniphier_cache_maint_common(struct uniphier_cache_data *data,
>> +   unsigned long start,
>> +   unsigned long size,
>> +   u32 operation)
>> +{
>> + unsigned long flags;
>> +
>> + /*
>> +  * The IRQ must be disable during this sequence because the accessor
>> +  * holds the access right of the operation queue registers.  The IRQ
>> +  * should be restored after releasing the register access right.
>> +  */
>> + local_irq_save(flags);
>> +
>> + /* clear the complete notification flag */
>> + writel_relaxed(UNIPHIER_SSCOLPQS_EF, data->op_base + 
>> UNIPHIER_SSCOLPQS);
>> +
>> + /*
>> +  * We do not need a spin lock here because the hardware guarantees
>> +  * this sequence is atomic, i.e. the write access is arbitrated
>> +  * and only the winner's write accesses take effect.
>> +  * After register settings, we need to check the UNIPHIER_SSCOPPQSEF to
>> +  * see if we won the arbitration or not.
>> +  * If the command was not successfully set, just try again.
>> +  */
>> + do {
>> + /* set cache operation */
>> + writel_relaxed(UNIPHIER_SSCOQM_CE | operation,
>> +data->op_base + UNIPHIER_SSCOQM);
>> +
>> + /* set address range if needed */
>> + if (likely(UNIPHIER_SSCOQM_S_IS_RANGE(operation))) {
>> + writel_relaxed(start, data->op_base + 
>> UNIPHIER_SSCOQAD);
>> + writel_relaxed(size, data->op_base + UNIPHIER_SSCOQSZ);
>> + }
>> +
>> + /* set target ways if needed */
>> + if (unlikely(UNIPHIER_SSCOQM_TID_IS_WAY(operation)))
>> + writel_relaxed(data->way_locked_mask,
>> +data->op_base + UNIPHIER_SSCOQWN);
>> + } while (unlikely(readl_relaxed(data->op_base + UNIPHIER_SSCOPPQSEF) &
>> +   (UNIPHIER_SSCOPPQSEF_FE | UNIPHIER_SSCOPPQSEF_OE)));
>> +
>> + /* wait until the operation is completed */
>> + while (likely(readl_relaxed(data->op_base + UNIPHIER_SSCOLPQS) !=
>> +   UNIPHIER_SSCOLPQS_EF))
>> + cpu_relax();
>> +
>> + local_irq_restore(flags);
>
> I'm concerned about this.  We've had caches like this (ARM L220) which
> require only one operation to be performed at a time.  In a SMP system,
> that requires a spinlock to prevent one CPU triggering a L2 maintanence
> operation while another CPU tries to operate on the L2 cache.
>
> From the overall series diffstat, I see that you are adding SMP support
> too.  So I have to ask the obvious question: if you need to disable
> local IRQs around the L2 cache operations, what happens if two CPUs
> both try to perform a L2 cache operation concurrently?


This cache controller is able to accept operations from multiple CPUs
at the same time.

Let's assume the following scenario:

CPU0 issues some operation.
Before the cache controller finishes the operation,
CPU1 issues another operation;  this is OK.
The operation is stored in the queue of the cache controller
until the operation under way is completed.
When the operation from CPU0 is finished, the controller starts
the operation from CPU1.

If the queue is full (this unlikely happens though),
the CPU can know by checking UNIPHIER_SSCOPPQSEF register.
This is checked by the code:

unlikely(readl_relaxed(data->op_base + UNIPHIER_SSCOPPQSEF) &
   (UNIPHIER_SSCOPPQSEF_FE | UNIPHIER_SSCOPPQSEF_OE))


The status register (UNIPHIER_SSCOLPQS) has each instance for each CPU.
That means, CPU0 can know if the operation issued by itself is finished or not.
Likewise for CPU1, CPU2, ...

To sum up, the cache controller can nicely handles cache operations in SMP.



-- 
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 2/2] powerpc:numa Do not allocate bootmem memory for non existing nodes

[Michael Ellerman]

On Tue, 2015-09-15 at 07:38 +0530, Raghavendra K T wrote:
>
> ... nothing

Sure this patch looks obvious, but please give me a changelog that proves
you've thought about it thoroughly.

For example is it OK to use for_each_node() at this point in boot? Is there any
historical reason why we did it with a hard coded loop? If so what has changed.
What systems have you tested on? etc. etc.

cheers

> Signed-off-by: Raghavendra K T 
> ---
>  arch/powerpc/mm/numa.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index 8b9502a..8d8a541 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -80,7 +80,7 @@ static void __init setup_node_to_cpumask_map(void)
>   setup_nr_node_ids();
>  
>   /* allocate the map */
> - for (node = 0; node < nr_node_ids; node++)
> + for_each_node(node)
>   alloc_bootmem_cpumask_var(_to_cpumask_map[node]);
>  
>   /* cpumask_of_node() will now work */




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] USB fixes for v4.3-rc3

[Greg KH]

On Mon, Sep 21, 2015 at 02:51:48PM -0500, Felipe Balbi wrote:
> Hi Greg,
> 
> Here's another pull request for the current -rc cycle. It's based off of
> greg/usb-linus for this cycle because the previous pull request hasn't
> reached v4.3-rc2.
> 
> This time I couldn't boot test all patches (specially the one fix on dwc3)
> because of being at linaro connect right now, but they're all safe enough
> to apply.
> 
> Let me know if want anything to be changed.
> 
> ps: I think you're around too ?? I'll come say hi at some point.
> 
> cheers
> 
> The following changes since commit 762982db33b23029e98c844611e2e8beeb75bc0d:
> 
>   usb: phy: phy-generic: Fix reset behaviour on legacy boot (2015-09-14 
> 10:15:08 -0500)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> tags/fixes-for-v4.3-rc3

Pulled and pushed out, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] net: Fix module autoload for OF platform drivers

[David Miller]

From: Luis de Bethencourt 
Date: Fri, 18 Sep 2015 17:53:32 +0200

> Hi,
> 
> These patches add the missing MODULE_DEVICE_TABLE() for OF to export
> the information so modules have the correct aliases built-in and
> autoloading works correctly.
> 
> A longer explanation by Javier Canillas can be found here:
> https://lkml.org/lkml/2015/7/30/519

ks8851 already has this issue fixed, thus rest of series
applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/9] perf, tools, stat: Move sw clock metrics printout to stat-shadow

[Andi Kleen]

From: Andi Kleen 

The sw clock metrics printing was missed in the earlier move to
stat-shadow of all the other metric printouts. Move it too.

Acked-by: Jiri Olsa 
Signed-off-by: Andi Kleen 
---
 tools/perf/builtin-stat.c | 9 -
 tools/perf/util/stat-shadow.c | 3 +++
 2 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index a96fb5c..77e5781 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -510,15 +510,6 @@ static void nsec_printout(int id, int nr, struct 
perf_evsel *evsel, double avg)
 
if (evsel->cgrp)
fprintf(output, "%s%s", csv_sep, evsel->cgrp->name);
-
-   if (csv_output || stat_config.interval)
-   return;
-
-   if (perf_evsel__match(evsel, SOFTWARE, SW_TASK_CLOCK))
-   fprintf(output, " # %8.3f CPUs utilized  ",
-   avg / avg_stats(_nsecs_stats));
-   else
-   fprintf(output, "   ");
 }
 
 static void abs_printout(int id, int nr, struct perf_evsel *evsel, double avg)
diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c
index 2a5d8d7..625ab3b 100644
--- a/tools/perf/util/stat-shadow.c
+++ b/tools/perf/util/stat-shadow.c
@@ -413,6 +413,9 @@ void perf_stat__print_shadow_stats(FILE *out, struct 
perf_evsel *evsel,
ratio = total / avg;
 
fprintf(out, " # %8.0f cycles / elision   ", ratio);
+   } else if (perf_evsel__match(evsel, SOFTWARE, SW_TASK_CLOCK) &&
+  (ratio = avg_stats(_nsecs_stats)) != 0) {
+   fprintf(out, " # %8.3f CPUs utilized  ", avg / ratio);
} else if (runtime_nsecs_stats[cpu].n != 0) {
char unit = 'M';
 
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 7/9] perf, tools, stat: Move non counting counter printing to printout

[Andi Kleen]

From: Andi Kleen 

Move the special case printing for non-running counters to
printout, so it can be shared by all the output options.

Signed-off-by: Andi Kleen 
---
 tools/perf/builtin-stat.c | 73 ---
 1 file changed, 24 insertions(+), 49 deletions(-)

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index b741ac4..ed93ea7 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -664,6 +664,30 @@ static void printout(int id, int nr, struct perf_evsel 
*counter, double uval,
os.ena = ena;
}
 
+   if (run == 0 || ena == 0) {
+   aggr_printout(counter, id, nr);
+
+   fprintf(stat_config.output, "%*s%s",
+   csv_output ? 0 : 18,
+   counter->supported ? CNTR_NOT_COUNTED : 
CNTR_NOT_SUPPORTED,
+   csv_sep);
+
+   fprintf(stat_config.output, "%-*s%s",
+   csv_output ? 0 : unit_width,
+   counter->unit, csv_sep);
+
+   fprintf(stat_config.output, "%*s",
+   csv_output ? 0 : -25,
+   perf_evsel__name(counter));
+
+   if (counter->cgrp)
+   fprintf(stat_config.output, "%s%s",
+   csv_sep, counter->cgrp->name);
+
+   print_running(run, ena);
+   return;
+   }
+
if (nsec_counter(counter))
nsec_printout(id, nr, counter, uval);
else
@@ -713,30 +737,6 @@ static void print_aggr(char *prefix)
if (prefix)
fprintf(output, "%s", prefix);
 
-   if (run == 0 || ena == 0) {
-   aggr_printout(counter, id, nr);
-
-   fprintf(output, "%*s%s",
-   csv_output ? 0 : 18,
-   counter->supported ? CNTR_NOT_COUNTED : 
CNTR_NOT_SUPPORTED,
-   csv_sep);
-
-   fprintf(output, "%-*s%s",
-   csv_output ? 0 : unit_width,
-   counter->unit, csv_sep);
-
-   fprintf(output, "%*s",
-   csv_output ? 0 : -25,
-   perf_evsel__name(counter));
-
-   if (counter->cgrp)
-   fprintf(output, "%s%s",
-   csv_sep, counter->cgrp->name);
-
-   print_running(run, ena);
-   fputc('\n', output);
-   continue;
-   }
uval = val * counter->scale;
printout(id, nr, counter, uval, prefix, run, ena, 1.0);
fputc('\n', output);
@@ -812,31 +812,6 @@ static void print_counter(struct perf_evsel *counter, char 
*prefix)
if (prefix)
fprintf(output, "%s", prefix);
 
-   if (run == 0 || ena == 0) {
-   fprintf(output, "CPU%*d%s%*s%s",
-   csv_output ? 0 : -4,
-   perf_evsel__cpus(counter)->map[cpu], csv_sep,
-   csv_output ? 0 : 18,
-   counter->supported ? CNTR_NOT_COUNTED : 
CNTR_NOT_SUPPORTED,
-   csv_sep);
-
-   fprintf(output, "%-*s%s",
-   csv_output ? 0 : unit_width,
-   counter->unit, csv_sep);
-
-   fprintf(output, "%*s",
-   csv_output ? 0 : -25,
-   perf_evsel__name(counter));
-
-   if (counter->cgrp)
-   fprintf(output, "%s%s",
-   csv_sep, counter->cgrp->name);
-
-   print_running(run, ena);
-   fputc('\n', output);
-   continue;
-   }
-
uval = val * counter->scale;
printout(cpu, 0, counter, uval, prefix, run, ena, 1.0);
 
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-next] khugepaged inconsistent lock state

[Hugh Dickins]

On Mon, 21 Sep 2015, Kirill A. Shutemov wrote:
> On Mon, Sep 21, 2015 at 01:46:00PM +0900, Sergey Senozhatsky wrote:
> > Hi,
> > 
> > 4.3.0-rc1-next-20150918
> > 
> > [18344.236625] =
> > [18344.236628] [ INFO: inconsistent lock state ]
> > [18344.236633] 4.3.0-rc1-next-20150918-dbg-00014-ge5128d0-dirty #361 Not 
> > tainted
> > [18344.236636] -
> > [18344.236640] inconsistent {IN-RECLAIM_FS-W} -> {RECLAIM_FS-ON-W} usage.
> > [18344.236645] khugepaged/32 [HC0[0]:SC0[0]:HE1:SE1] takes:
> > [18344.236648]  (_vma->rwsem){?.}, at: [] 
> > khugepaged+0x8b0/0x1987
> > [18344.236662] {IN-RECLAIM_FS-W} state was registered at:
> > [18344.23]   [] __lock_acquire+0x8e2/0x1183
> > [18344.236673]   [] lock_acquire+0x10b/0x1a6
> > [18344.236678]   [] down_write+0x3b/0x6a
> > [18344.236686]   [] split_huge_page_to_list+0x5b/0x61f
> > [18344.236689]   [] add_to_swap+0x37/0x78
> > [18344.236691]   [] shrink_page_list+0x4c2/0xb9a
> > [18344.236694]   [] shrink_inactive_list+0x371/0x5d9
> > [18344.236696]   [] shrink_lruvec+0x410/0x5ae
> > [18344.236698]   [] shrink_zone+0x57/0x140
> > [18344.236700]   [] kswapd+0x6a5/0x91b
> > [18344.236702]   [] kthread+0x107/0x10f
> > [18344.236706]   [] ret_from_fork+0x3f/0x70
> > [18344.236708] irq event stamp: 6517947
> > [18344.236709] hardirqs last  enabled at (6517947): [] 
> > get_page_from_freelist+0x362/0x59e
> > [18344.236713] hardirqs last disabled at (6517946): [] 
> > _raw_spin_lock_irqsave+0x18/0x51
> > [18344.236715] softirqs last  enabled at (6507072): [] 
> > __do_softirq+0x2df/0x3f5
> > [18344.236719] softirqs last disabled at (6507055): [] 
> > irq_exit+0x40/0x94
> > [18344.236722] 
> >other info that might help us debug this:
> > [18344.236723]  Possible unsafe locking scenario:
> > 
> > [18344.236724]CPU0
> > [18344.236725]
> > [18344.236726]   lock(_vma->rwsem);
> > [18344.236728]   
> > [18344.236729] lock(_vma->rwsem);
> > [18344.236731] 
> > *** DEADLOCK ***
> > 
> > [18344.236733] 2 locks held by khugepaged/32:
> > [18344.236733]  #0:  (>mmap_sem){++}, at: [] 
> > khugepaged+0x5cf/0x1987
> > [18344.236738]  #1:  (_vma->rwsem){?.}, at: [] 
> > khugepaged+0x8b0/0x1987
> > [18344.236741] 
> >stack backtrace:
> > [18344.236744] CPU: 3 PID: 32 Comm: khugepaged Not tainted 
> > 4.3.0-rc1-next-20150918-dbg-00014-ge5128d0-dirty #361
> > [18344.236747]   880132827a00 81230867 
> > 8237ba90
> > [18344.236750]  880132827a38 810ea9b9 000a 
> > 8801333b52e0
> > [18344.236753]  8801333b4c00 8107b3ce 000a 
> > 880132827a78
> > [18344.236755] Call Trace:
> > [18344.236758]  [] dump_stack+0x4e/0x79
> > [18344.236761]  [] print_usage_bug.part.24+0x259/0x268
> > [18344.236763]  [] ? 
> > print_shortest_lock_dependencies+0x180/0x180
> > [18344.236765]  [] mark_lock+0x381/0x567
> > [18344.236766]  [] mark_held_locks+0x5e/0x74
> > [18344.236768]  [] lockdep_trace_alloc+0xb0/0xb3
> > [18344.236771]  [] __alloc_pages_nodemask+0x99/0x856
> > [18344.236772]  [] ? find_get_entry+0x14b/0x17a
> > [18344.236774]  [] ? find_get_entry+0x168/0x17a
> > [18344.236777]  [] __read_swap_cache_async+0x7b/0x1aa
> > [18344.236778]  [] read_swap_cache_async+0x15/0x2d
> > [18344.236780]  [] swapin_readahead+0x11a/0x16a
> > [18344.236783]  [] do_swap_page+0xa7/0x36b
> > [18344.236784]  [] ? do_swap_page+0xa7/0x36b
> > [18344.236787]  [] khugepaged+0x8f9/0x1987
> > [18344.236790]  [] ? wait_woken+0x88/0x88
> > [18344.236792]  [] ? maybe_pmd_mkwrite+0x1a/0x1a
> > [18344.236794]  [] kthread+0x107/0x10f
> > [18344.236797]  [] ? kthread_create_on_node+0x1ea/0x1ea
> > [18344.236799]  [] ret_from_fork+0x3f/0x70
> > [18344.236801]  [] ? kthread_create_on_node+0x1ea/0x1ea
> 
> Hm. If I read this correctly, we see following scenario:
> 
>  - khugepaged tries to swap in a page under mmap_sem and anon_vma lock;
>  - do_swap_page() calls swapin_readahead() with GFP_HIGHUSER_MOVABLE;
>  - __read_swap_cache_async() tries to allocate the page for swap in;
>  - lockdep_trace_alloc() in __alloc_pages_nodemask() notices that with
>given gfp_mask we could end up in direct relaim.
>  - Lockdep already knows that reclaim sometimes (e.g. in case of
>split_huge_page()) wants to take anon_vma lock on its own.
> 
> Therefore deadlock is possible.

Oh, thank you for working that out.  As usual with a lockdep trace,
I knew it was telling me something important, but in a language I
just couldn't understand without spending much longer to decode it.
Yes, wrong to call do_swap_page() while holding anon_vma lock.

> 
> I see two ways to fix this:
> 
>  - take anon_vma lock *after* __collapse_huge_page_swapin() in
>collapse_huge_page(): I don't really see why we need the lock
>during swapin;

Agreed.

>  - respect FAULT_FLAG_RETRY_NOWAIT in do_swap_page(): add GFP_NOWAIT to
>

Re: [PATCH 05/15] RDS: increase size of hash-table to 8K

[santosh shilimkar]

On 9/21/2015 4:05 PM, David Miller wrote:

From: Santosh Shilimkar 
Date: Sat, 19 Sep 2015 19:04:42 -0400


Even with per bucket locking scheme, in a massive parallel
system with active rds sockets which could be in excess of multiple
of 10K, rds_bin_lookup() workload is siginificant because of smaller
hashtable size.

With some tests, it was found that we get modest but still nice
reduction in rds_bind_lookup with bigger bucket.

Hashtable   Baseline(1k)Delta
2048:   8.28%   -2.45%
4096:   8.28%   -4.60%
8192:   8.28%   -6.46%
16384:  8.28%   -6.75%

Based on the data, we set 8K as the bind hash-table size.

Signed-off-by: Santosh Shilimkar 
Signed-off-by: Santosh Shilimkar 


Like others I would strongly prefer that you use a dynamically sized
hash table.

Eating 8k just because a module just happened to get loaded is really
not appropriate.

And there are many other places that use such a scheme, one example is
the AF_NETLINK socket hash table.


OK. Thanks for AF_NETLINK pointer. I will look it up.

Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] linux-firmware: Add qmss accumulator pdsp firmware for keystone SoCs

[Kyle McMartin]

On Mon, Sep 21, 2015 at 11:07:20AM -0400, Murali Karicheri wrote:
> On 09/19/2015 08:53 AM, Kyle McMartin wrote:
> >On Fri, Sep 18, 2015 at 11:43:02AM -0400, Murali Karicheri wrote:> >>+
> >>Dear firmware maintainer,
> >>
> >>Could you please review this patch and comment if it requires any change? If
> >>looks good, let me know when this will be queued for merge to the mainline
> >>linux-firmware.git repo.
> >>
> >>Thanks
> >
> >I'm travelling this weekend without access to my kernel.org keys, so
> >it'll have to wait until I return.
> >
> >regards, --Kyle
> Thanks Kyle.
> 

Everything looks fine with the submission... the licence text pretty
closely matches the terms of the existing LICENSE.ti-connectivity... any
chance we could get this released under that exact license to save
redundant proliferation of license terms?

regards, --Kyle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC v7 21/41] richacl: Move everyone@ aces down the acl

[J. Bruce Fields]

On Mon, Sep 21, 2015 at 11:43:16PM +0200, Andreas Gruenbacher wrote:
> 2015-09-18 21:35 GMT+02:00 J. Bruce Fields :
> > On Sat, Sep 05, 2015 at 12:27:16PM +0200, Andreas Gruenbacher wrote:
> >> The POSIX standard puts processes which are not the owner or a member in
> >> the owning group or which match any ace other then everyone@ on the
> >> other file class.  We only know if a process is in the other class after
> >> processing the entire acl.
> >>
> >> Move all everyone@ aces in the acl down in the acl so that at most a
> >> single everyone@ allow ace remains at the end.  Permissions which are
> >> not explicitly allowed are implicitly denied, so an everyone@ deny ace
> >> is unneeded.
> >>
> >> The everyone@ aces can be moved down the acl without changing the
> >> permissions that the acl grants.  This transformation simplifies the
> >> following algorithms, and eventually allows us to turn the final
> >> everyone@ allow ace into an entry for the other class.
> >>
> >> Signed-off-by: Andreas Gruenbacher 
> >> ---
> >>  fs/richacl_compat.c | 65 
> >> +
> >>  1 file changed, 65 insertions(+)
> >>
> >> diff --git a/fs/richacl_compat.c b/fs/richacl_compat.c
> >> index 341e429..4f0acf5 100644
> >> --- a/fs/richacl_compat.c
> >> +++ b/fs/richacl_compat.c
> >> @@ -153,3 +153,68 @@ richace_change_mask(struct richacl_alloc *alloc, 
> >> struct richace **ace,
> >>   }
> >>   return 0;
> >>  }
> >> +
> >> +/**
> >> + * richacl_move_everyone_aces_down  -  move everyone@ aces to the end of 
> >> the acl
> >> + * @alloc:   acl and number of allocated entries
> >> + *
> >> + * Move all everyone aces to the end of the acl so that only a single 
> >> everyone@
> >> + * allow ace remains at the end, and update the mask fields of all aces 
> >> on the
> >> + * way.  The last ace of the resulting acl will be an everyone@ allow ace 
> >> only
> >> + * if @acl grants any permissions to @everyone.  No @everyone deny aces 
> >> will
> >> + * remain.
> >> + *
> >> + * This transformation does not alter the permissions that the acl grants.
> >> + * Having at most one everyone@ allow ace at the end of the acl helps us 
> >> in the
> >> + * following algorithms.
> >> + */
> >> +static int
> >> +richacl_move_everyone_aces_down(struct richacl_alloc *alloc)
> >> +{
> >> + struct richace *ace;
> >> + unsigned int allowed = 0, denied = 0;
> >> +
> >> + richacl_for_each_entry(ace, alloc->acl) {
> >> + if (richace_is_inherit_only(ace))
> >> + continue;
> >> + if (richace_is_everyone(ace)) {
> >> + if (richace_is_allow(ace))
> >> + allowed |= (ace->e_mask & ~denied);
> >> + else if (richace_is_deny(ace))
> >> + denied |= (ace->e_mask & ~allowed);
> >> + else
> >> + continue;
> >> + if (richace_change_mask(alloc, , 0))
> >> + return -1;
> >> + } else {
> >> + if (richace_is_allow(ace)) {
> >> + if (richace_change_mask(alloc, , allowed 
> >> |
> >> + (ace->e_mask & ~denied)))
> >> + return -1;
> >> + } else if (richace_is_deny(ace)) {
> >> + if (richace_change_mask(alloc, , denied |
> >> + (ace->e_mask & ~allowed)))
> >> + return -1;
> >> + }
> >> + }
> >> + }
> >> + if (allowed & ~RICHACE_POSIX_ALWAYS_ALLOWED) {
> >> + struct richace *last_ace = ace - 1;
> >> +
> >> + if (alloc->acl->a_entries &&
> >> + richace_is_everyone(last_ace) &&
> >> + richace_is_allow(last_ace) &&
> >> + richace_is_inherit_only(last_ace) &&
> >> + last_ace->e_mask == allowed)
> >> + last_ace->e_flags &= ~RICHACE_INHERIT_ONLY_ACE;
> >
> > That's a funny special case!  Is it even worth it, or could we just live
> > with an extra uninheritable EVERYONE ace in this case?
> 
> Inheritable everyone@ allow entries at the end of the ACL are not
> uncommon. This special case prevents the algorithm from splitting such
> entries into inherit-only and non-inheritable parts.

OK.--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] clk: bcm2835: Add a driver for the auxiliary peripheral clock gates.

[Stephen Warren]

On 09/10/2015 03:22 PM, Eric Anholt wrote:
> There are a pair of SPI masters and a mini UART that were last minute
> additions.  As a result, they didn't get integrated in the same way as
> the other gates off of the VPU clock in CPRMAN.

> diff --git a/drivers/clk/bcm/clk-bcm2835-aux.c 
> b/drivers/clk/bcm/clk-bcm2835-aux.c

> +static int bcm2835_aux_clk_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct clk_onecell_data *onecell;
> + const char *parent;
> + struct clk *parent_clk;
> + void __iomem *reg;
> +
> + parent_clk = of_clk_get(dev->of_node, 0);
> + if (IS_ERR(parent_clk))
> + return PTR_ERR(parent_clk);
> + parent = __clk_get_name(parent_clk);

I think all the comments I made on probe() for the main bcm2835 clock
driver likely apply here too.

Also, is it "legal" for clock drivers to use __clk_get_name()? I thought
that was a clock core internal function, but may be wrong. I would have
expected to be able to pass a clock object when registering clocks
rather than a clock name, but oh well.

BTW, I like how this series shows how useful it is for someone with full
knowledge of the HW to come up with the DT bindings for a HW module;
once you know how the HW is actually designed, the correct binding ends
up being a lot easier to come up with, rather than guessing:-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] ARM: bcm2835: Add the auxiliary clocks to the device tree.

[Stephen Warren]

On 09/10/2015 03:22 PM, Eric Anholt wrote:
> These will be used for enabling UART1, SPI1, and SPI2.

Patches 1, 3,
Acked-by: Stephen Warren 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC resend] Perf: Trigger and dump sample info to perf.data from user space ring buffer

[Yunlong Song]

[Problem Background]

We want to run perf in daemon mode and collect the traces when the exception
(e.g., machine crashes, app performance goes down) appears. Perf may run for a
long time (from days to weeks or even months), since we do not know when the
exception will appear at all, however it will appear at some time (especially
for a beta product). If we simply use “perf record” as usual, here come two
problems as time goes by: 1 there will be large amounts of IOs created for 
writing
perf.data which may affects the performance a lot; 2 the size of perf.data will
be larger and larger as well. Although we can use eBPF to reduce the traces in
normal case, but in our case, the perf runs in daemon mode for a long time and
that will accumulate the traces as time goes by.


[One Solution]

In fact, we only need to collect the sample info which are created for a while
just before the exception appears. We do not care about the other sample info in
other time. So perhaps we have to change the current way how perf makes its
perf.data as follows:
 1 Let perf allocate a user space ring buffer in a reasonable size, which is big
   enough to store all the tracing info we care about (for a while) before the
   exception appears;
 2 Dump the sample info to the user space ring buffer, the size of user space
   ring buffer is a constant value, so the newer sample info will replace the 
older
   sample info;
 3 After some kind of trigger (maybe via eBPF event, signal or socket
   communication) which is caused by the exception situation, the user space 
ring
   buffer should dump all its tracing info to perf.data.sample.TIME#


[Use Style]

We can add an option (such as “-M size” or “--memory size”) to define the
size of the user space ring buffer and active the user space ring buffer mode
described above. For convenience, we can add “--daemon” to make perf run as a
daemon.
# perf record -M size -e ebpf.o -e cycles -g -F 100 -a sleep 100 &
Or
# perf record -M size -e ebpf.o -e cycles -g -F 100 -a --daemon

When the exception appears, it sends a signal (may also use eBPF event or socket
communication) to perf
# kill -SIGUSR1 1234
# ls
perf.data.auxiliary perf.data.sample.TIME1

When the 2nd exception appears
# kill -SIGUSR1 1234
# ls
perf.data.auxiliary perf.data.sample.TIME1 perf.data.sample.TIME2

..

When the Nth exception appears
# kill -SIGUSR1 1234
# ls
perf.data.auxiliary perf.data.sample.TIME1 perf.data.sample.TIME2 … 
perf.data.sample.TIMEN

We can user perf report or perf script to analyze each perf.data.sample.TIME#

Or finally, we can kill perf and combine perf.data.auxiliary with all the
perf.data.sample.TIME# to create all-in-one perf.data
# kill --SIGUSR2 1234
# ls
perf.data


[To Do]

If the idea mentioned above is OK, we want to implement it in the following 
steps:
 1 Develop perf’s user space ring buffer, which can make newer sample info 
replace
   older sample info.
 2 Classify the tracing info into two kinds, one kind is just sample event, and 
we
   only need some of them which are created (for a while) just before the 
exception
   appears, we can call the first kind of tracing info as Optional tracing info,
   and perf should dump this info to the user space ring buffer instead of 
perf.data;
   the second kind is the tracing info which are required to analyze the sample 
events,
   such as mmap_event to show the dso's related info, we can call this second 
kind of
   tracing info as Auxiliary tracing info, and perf should dump this info into
   perf.data.auxiliary or just directly into perf.data as before.
 3 Develop a trigger for perf, which can activate perf to dump its user space 
ring
   buffer to perf.data.sample.TIME#, or just append them into perf.data. The 
trigger
   may include three interfaces, eBPF event, signal and socket communication.
 4 Make perf report or perf script etc, have the ability to analyze the
   perf.data.auxiliary, perf.data.sample.TIME#, or the final synthetic perf.data
   combined from perf.data.auxiliary and all the perf.data.sample.TIME#
 5 For daemon mode, we should also let perf support its running in backend all
   the time and its ending from a trigger.


[Conclusion]

In fact, we realize a mechanism to make perf's tracing more refined and more
efficient. We regard the size of perf.data and the cost of writing perf.data as
an expensive resource, which has batter to be used in a more careful and
just-for-the-exception target way. This mechanism can be used both in daemon 
mode
or in non-daemon mode. This idea can be another way to filter the tracing events
compared to eBPF from different view.


-- 
Thanks,
Yunlong Song

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v10 4/5] QE/CPM: move muram management functions to qe_common

[Zhao Qiang]

On Tue, Sep 22, 2015 at 11:08AM +0800, Wood Scott-B07421 wrote:

> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, September 22, 2015 11:08 AM
> To: Zhao Qiang-B45475
> Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li
> Yang-Leo-R58472; pau...@samba.org
> Subject: Re: [PATCH v10 4/5] QE/CPM: move muram management functions to
> qe_common
> 
> On Mon, 2015-09-21 at 22:06 -0500, Zhao Qiang-B45475 wrote:
> > On Tue, Sep 22, 2015 at 10:26AM +0800, Wood Scott-B07421 wrote:
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Tuesday, September 22, 2015 10:26 AM
> > > To: Zhao Qiang-B45475
> > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org;
> > > Li Yang-Leo-R58472; pau...@samba.org
> > > Subject: Re: [PATCH v10 4/5] QE/CPM: move muram management functions
> > > to qe_common
> > >
> > > On Mon, 2015-09-21 at 21:23 -0500, Zhao Qiang-B45475 wrote:
> > > > On Tue, Sep 22, 2015 at 06:54AM +0800, Wood Scott-B07421 wrote:
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Tuesday, September 22, 2015 6:54 AM
> > > > > To: Zhao Qiang-B45475
> > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > > > lau...@codeaurora.org; Xie Xiaobo-R63061;
> > > > > b...@kernel.crashing.org; Li Yang-Leo-R58472; pau...@samba.org
> > > > > Subject: Re: [PATCH v10 4/5] QE/CPM: move muram management
> > > > > functions to qe_common
> > > > >
> > > > > On Fri, Sep 18, 2015 at 03:15:20PM +0800, Zhao Qiang wrote:
> > > > > > QE and CPM have the same muram, they use the same management
> > > > > > functions. Now QE support both ARM and PowerPC, it is
> > > > > > necessary to move QE to "driver/soc", so move the muram
> > > > > > management functions from cpm_common to qe_common for
> > > > > > preparing to move QE code to
> > > "driver/soc"
> > > > > >
> > > > > > Signed-off-by: Zhao Qiang 
> > > > > > ---
> > > > > > Changes for v2:
> > > > > >   - no changes
> > > > > > Changes for v3:
> > > > > >   - no changes
> > > > > > Changes for v4:
> > > > > >   - no changes
> > > > > > Changes for v5:
> > > > > >   - no changes
> > > > > > Changes for v6:
> > > > > >   - using genalloc instead rheap to manage QE MURAM
> > > > > >   - remove qe_reset from platform file, using
> > > > > >   - subsys_initcall to call qe_init function.
> > > > >
> > > > > Why is the init change in the same patch as moving the muram code?
> > > > >
> > > > > > Changes for v7:
> > > > > >   - move this patch from 3/3 to 2/3
> > > > > >   - convert cpm with genalloc
> > > > > >   - check for gen_pool allocation failure Changes for v8:
> > > > > >   - rebase
> > > > > >   - move BD_SC_* macro instead of copy Changes for v9:
> > > > > >   - doesn't modify CPM, add a new patch to modify.
> > > > > >   - rebase
> > > > > > Changes for v10:
> > > > > >   - rebase
> > > > > >
> > > > > >  arch/powerpc/include/asm/cpm.h|  59 
> > > > > >  arch/powerpc/include/asm/qe.h |  51 ++-
> > > > > >  arch/powerpc/platforms/83xx/km83xx.c  |   2 -
> > > > > >  arch/powerpc/platforms/83xx/mpc832x_mds.c |   2 -
> > > > > >  arch/powerpc/platforms/83xx/mpc832x_rdb.c |   2 -
> > > > > >  arch/powerpc/platforms/83xx/mpc836x_mds.c |   2 -
> > > > > >  arch/powerpc/platforms/83xx/mpc836x_rdk.c |   3 -
> > > > > >  arch/powerpc/platforms/85xx/common.c  |   1 -
> > > > > >  arch/powerpc/sysdev/cpm_common.c  | 206 +-
> 
> > > 
> > > > > ---
> > > > > >  arch/powerpc/sysdev/qe_lib/Makefile   |   2 +-
> > > > > >  arch/powerpc/sysdev/qe_lib/qe.c   |  15 ++
> > > > > >  arch/powerpc/sysdev/qe_lib/qe_common.c| 242
> > > > > ++
> > > > > >  12 files changed, 302 insertions(+), 285 deletions(-)  create
> > > > > > mode
> > > > > > 100644 arch/powerpc/sysdev/qe_lib/qe_common.c
> > > > > >
> > > > > > diff --git a/arch/powerpc/include/asm/cpm.h
> > > > > > b/arch/powerpc/include/asm/cpm.h index 4398a6c..003a736 100644
> > > > > > --- a/arch/powerpc/include/asm/cpm.h
> > > > > > +++ b/arch/powerpc/include/asm/cpm.h
> > > > > > @@ -93,22 +93,6 @@ typedef struct cpm_buf_desc {
> > > > > >   */
> > > > > >
> > > > > >  #define BD_SC_EMPTY  (0x8000)/* Receive is empty
> */
> > > > > > -#define BD_SC_READY  (0x8000)/* Transmit is ready
> */
> > > > > > -#define BD_SC_WRAP   (0x2000)/* Last buffer
> descriptor
> > > */
> > > > > > -#define BD_SC_INTRPT (0x1000)/* Interrupt on
> change */
> > > > > > -#define BD_SC_LAST   (0x0800)/* Last buffer in
> frame
> > > */
> > > > > > -#define BD_SC_TC (0x0400)/* Transmit CRC */
> > > > > > -#define BD_SC_CM (0x0200)/* Continuous mode */
> > > > > > -#define BD_SC_ID (0x0100) 

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

[David Miller]

From: Stephen Rothwell 
Date: Tue, 22 Sep 2015 11:20:15 +1000

> From: Stephen Rothwell 
> Subject: drivers/net/ieee802154/at86rf230.c: seq_printf() now returns NULL
> 
> Signed-off-by: Stephen Rothwell 
> Cc: Alexander Aring 
> Cc: Stefan Schmidt 
> Cc: Marcel Holtmann 
> Signed-off-by: Andrew Morton 
> Signed-off-by: Alexander Aring 

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] usb: gadget: f_midi: check for error on usb_ep_queue

[Felipe Balbi]

Hi,

On Mon, Sep 21, 2015 at 10:21:31AM +0100, Felipe Tonello wrote:
> Hi Balbi,
> 
> On Fri, Sep 18, 2015 at 6:36 PM,   wrote:
> > From: "Felipe F. Tonello" 
> >
> > f_midi is not checking whether there is an error on usb_ep_queue
> > request, ignoring potential problems, such as memory leaks.
> >
> > Signed-off-by: Felipe F. Tonello 
> > ---
> >
> > Changes for v2:
> >   - Update code style.
> >
> > Changes for v3:
> >   - Use ip_ep instead of out_ep. Fixed typo in commit message.
> 
> I forgot to add v3 to the patch subject, so it queued here instead. Do
> you want me to re-send as v3?

you need to ask Peter, he's the chipidea maintainer. Peter ?

-- 
balbi


signature.asc
Description: PGP signature

linux-next: Tree for Sep 22

[Stephen Rothwell]

Hi all,

Changes since 20150921:

I used the h8300 tree from next-20150828 since the current tree has been
rebased onto something very old :-(

The sound-asoc tree lost its build failure.

The net-next tree inherited the bluetooth tree build failure.

Non-merge commits (relative to Linus' tree): 2315
 1957 files changed, 111076 insertions(+), 29406 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 for x86_64,
a multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), it is also built with powerpc allnoconfig
(32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final
link) and i386, sparc, sparc64 and arm defconfig.

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (ac2fc4b9d5b7 Merge tag 'renesas-sh-drivers-for-v4.3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas)
Merging fixes/master (c7e9ad7da219 Merge branch 'perf-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify)
Merging arm-current/fixes (7ae85dc7687c ARM: 8425/1: kgdb: Don't try to stop 
the machine when setting breakpoints)
Merging m68k-current/for-linus (1ecb40643a9a m68k/bootinfo: Use kmemdup rather 
than duplicating its implementation)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-fixes/fixes (400c47d81ca3 powerpc32: memset: only use dcbz once 
cache is enabled)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (73958c651fbf sparc64: use ENTRY/ENDPROC in VISsave)
Merging net/master (5eb8f289ac30 geneve: remove vlan-related feature assignment)
Merging ipsec/master (04a6b8bfee06 xfrm6: Fix ICMPv6 and MH header checks in 
_decode_session6)
Merging sound-current/for-linus (5ee20bc79246 ALSA: usb-audio: Change internal 
PCM order)
Merging pci-current/for-linus (237865f195f6 PCI: Revert "PCI: Call 
pci_read_bridge_bases() from core instead of arch code")
Merging wireless-drivers/master (c2e7204d180f tcp_cubic: do not set epoch_start 
in the future)
Merging driver-core.current/driver-core-linus (2110d70c5e58 cpu/cacheinfo: Fix 
teardown path)
Merging tty.current/tty-linus (1f93e4a96c91 Linux 4.3-rc2)
Merging usb.current/usb-linus (ea9346514e77 Merge tag 'usb-ci-v4.3-rc2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb into usb-linus)
Merging usb-gadget-fixes/fixes (a66c275b3d5d usb: dwc3: gadget: Fix BUG in RT 
config)
Merging usb-serial-fixes/usb-linus (19ab6bc5674a USB: option: add ZTE PIDs)
Merging staging.current/staging-linus (74c600e36455 MAINTAINERS: Update email 
address for Martyn Welch)
Merging char-misc.current/char-misc-linus (ca1c4b745779 Drivers: hv: vmbus: fix 
init_vp_index() for reloading hv_netvsc)
Merging input-current/for-linus (72d4736253af Input: uinput - fix crash when 
using ABS events)
Merging crypto-current/master (09185e2756a8 hwrng: xgene - fix handling 
platform_get_irq)
Merging ide/master (d681f1166919 ide: remove deprecated use of pci api)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_put_addr())
Merging vfio-fixes/for-linus (4bc94d5dc95d vfio: Fix lockdep issue)
Merging kselftest-fixes/fixes (ae7858180510 selftests: exec: revert to default 
emit rule)
Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: p

Re: [PATCH v10 4/5] QE/CPM: move muram management functions to qe_common

[Scott Wood]

On Mon, 2015-09-21 at 22:22 -0500, Zhao Qiang-B45475 wrote:
> On Tue, Sep 22, 2015 at 11:08AM +0800, Wood Scott-B07421 wrote:
> 
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Tuesday, September 22, 2015 11:08 AM
> > To: Zhao Qiang-B45475
> > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li
> > Yang-Leo-R58472; pau...@samba.org
> > Subject: Re: [PATCH v10 4/5] QE/CPM: move muram management functions to
> > qe_common
> > 
> > On Mon, 2015-09-21 at 22:06 -0500, Zhao Qiang-B45475 wrote:
> > > On Tue, Sep 22, 2015 at 10:26AM +0800, Wood Scott-B07421 wrote:
> > > 
> > > > -Original Message-
> > > > From: Wood Scott-B07421
> > > > Sent: Tuesday, September 22, 2015 10:26 AM
> > > > To: Zhao Qiang-B45475
> > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > > lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org;
> > > > Li Yang-Leo-R58472; pau...@samba.org
> > > > Subject: Re: [PATCH v10 4/5] QE/CPM: move muram management functions
> > > > to qe_common
> > > > 
> > > > On Mon, 2015-09-21 at 21:23 -0500, Zhao Qiang-B45475 wrote:
> > > > > On Tue, Sep 22, 2015 at 06:54AM +0800, Wood Scott-B07421 wrote:
> > > > > > -Original Message-
> > > > > > From: Wood Scott-B07421
> > > > > > Sent: Tuesday, September 22, 2015 6:54 AM
> > > > > > To: Zhao Qiang-B45475
> > > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > > > > lau...@codeaurora.org; Xie Xiaobo-R63061;
> > > > > > b...@kernel.crashing.org; Li Yang-Leo-R58472; pau...@samba.org
> > > > > > Subject: Re: [PATCH v10 4/5] QE/CPM: move muram management
> > > > > > functions to qe_common
> > > > > > 
> > > > > > On Fri, Sep 18, 2015 at 03:15:20PM +0800, Zhao Qiang wrote:
> > > > > > > QE and CPM have the same muram, they use the same management
> > > > > > > functions. Now QE support both ARM and PowerPC, it is
> > > > > > > necessary to move QE to "driver/soc", so move the muram
> > > > > > > management functions from cpm_common to qe_common for
> > > > > > > preparing to move QE code to
> > > > "driver/soc"
> > > > > > > 
> > > > > > > Signed-off-by: Zhao Qiang 
> > > > > > > ---
> > > > > > > Changes for v2:
> > > > > > >   - no changes
> > > > > > > Changes for v3:
> > > > > > >   - no changes
> > > > > > > Changes for v4:
> > > > > > >   - no changes
> > > > > > > Changes for v5:
> > > > > > >   - no changes
> > > > > > > Changes for v6:
> > > > > > >   - using genalloc instead rheap to manage QE MURAM
> > > > > > >   - remove qe_reset from platform file, using
> > > > > > >   - subsys_initcall to call qe_init function.
> > > > > > 
> > > > > > Why is the init change in the same patch as moving the muram code?
> > > > > > 
> > > > > > > Changes for v7:
> > > > > > >   - move this patch from 3/3 to 2/3
> > > > > > >   - convert cpm with genalloc
> > > > > > >   - check for gen_pool allocation failure Changes for v8:
> > > > > > >   - rebase
> > > > > > >   - move BD_SC_* macro instead of copy Changes for v9:
> > > > > > >   - doesn't modify CPM, add a new patch to modify.
> > > > > > >   - rebase
> > > > > > > Changes for v10:
> > > > > > >   - rebase
> > > > > > > 
> > > > > > >  arch/powerpc/include/asm/cpm.h|  59 
> > > > > > >  arch/powerpc/include/asm/qe.h |  51 ++-
> > > > > > >  arch/powerpc/platforms/83xx/km83xx.c  |   2 -
> > > > > > >  arch/powerpc/platforms/83xx/mpc832x_mds.c |   2 -
> > > > > > >  arch/powerpc/platforms/83xx/mpc832x_rdb.c |   2 -
> > > > > > >  arch/powerpc/platforms/83xx/mpc836x_mds.c |   2 -
> > > > > > >  arch/powerpc/platforms/83xx/mpc836x_rdk.c |   3 -
> > > > > > >  arch/powerpc/platforms/85xx/common.c  |   1 -
> > > > > > >  arch/powerpc/sysdev/cpm_common.c  | 206 +-
> > 
> > > > 
> > > > > > ---
> > > > > > >  arch/powerpc/sysdev/qe_lib/Makefile   |   2 +-
> > > > > > >  arch/powerpc/sysdev/qe_lib/qe.c   |  15 ++
> > > > > > >  arch/powerpc/sysdev/qe_lib/qe_common.c| 242
> > > > > > ++
> > > > > > >  12 files changed, 302 insertions(+), 285 deletions(-)  create
> > > > > > > mode
> > > > > > > 100644 arch/powerpc/sysdev/qe_lib/qe_common.c
> > > > > > > 
> > > > > > > diff --git a/arch/powerpc/include/asm/cpm.h
> > > > > > > b/arch/powerpc/include/asm/cpm.h index 4398a6c..003a736 100644
> > > > > > > --- a/arch/powerpc/include/asm/cpm.h
> > > > > > > +++ b/arch/powerpc/include/asm/cpm.h
> > > > > > > @@ -93,22 +93,6 @@ typedef struct cpm_buf_desc {
> > > > > > >   */
> > > > > > > 
> > > > > > >  #define BD_SC_EMPTY  (0x8000)/* Receive is empty
> > */
> > > > > > > -#define BD_SC_READY  (0x8000)/* Transmit is ready
> > */
> > > > > > > -#define BD_SC_WRAP   (0x2000)/* Last buffer
> > descriptor
> > > > */
> > > > > > > -#define BD_SC_INTRPT (0x1000)/* 

Re: [Intel-wired-lan] [PATCH] igb: add more checks for disconnected adapter

[Mark Rustad]

On 9/21/15 9:14 PM, Jarod Wilson wrote:
> Just switching to adapter->io_addr everywhere seems to not work as 
> noted above. :\ Note that I'm also chasing this from the other end 
> with the author of the pci patches that seem to have triggered this, 
> so the real bug might be over in pci-land, but hardening against 
> explosions in igb still seems like a worthwhile effort here.

My understanding is that there can be problems if too many writes to a
removed device happen. That is why ixgbe avoids doing that by testing
for removal in some places. The io_addr does get used in the transmit
path simply to avoid adding a test to that hot path. That approach
seems to be working well for ixgbe.



signature.asc
Description: OpenPGP digital signature

[PATCH] maintainers: update staging/rdma

[Sudip Mukherjee]

Doug Ledford will be handling all the patches related to
drivers/staging/rdma/. Patches for those files are not to be sent to
Greg and devel mailing list.

Signed-off-by: Sudip Mukherjee 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index cf1a98d..95b9ecb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9877,6 +9877,7 @@ T:git 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
 L: de...@driverdev.osuosl.org
 S: Supported
 F: drivers/staging/
+X: drivers/staging/rdma
 
 STAGING - COMEDI
 M: Ian Abbott 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

[Tetsuo Handa]

David Rientjes wrote:
> Your proposal, which I mostly agree with, tries to kill additional 
> processes so that they allocate and drop the lock that the original victim 
> depends on.  My approach, from 
> http://marc.info/?l=linux-kernel=144010444913702, is the same, but 
> without the killing.  It's unecessary to kill every process on the system 
> that is depending on the same lock, and we can't know which processes are 
> stalling on that lock and which are not.

Would you try your approach with below program?
(My reproducers are tested on XFS on a VM with 4 CPUs / 2048MB RAM.)

-- oom-depleter3.c start --
#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 
#include 

static int zero_fd = EOF;
static char *buf = NULL;
static unsigned long size = 0;

static int dummy(void *unused)
{
static char buffer[4096] = { };
int fd = open("/tmp/file", O_WRONLY | O_CREAT | O_APPEND, 0600);
while (write(fd, buffer, sizeof(buffer) == sizeof(buffer)) &&
   fsync(fd) == 0);
return 0;
}

static int trigger(void *unused)
{
read(zero_fd, buf, size); /* Will cause OOM due to overcommit */
return 0;
}

int main(int argc, char *argv[])
{
unsigned long i;
zero_fd = open("/dev/zero", O_RDONLY);
for (size = 1048576; size < 512UL * (1 << 30); size <<= 1) {
char *cp = realloc(buf, size);
if (!cp) {
size >>= 1;
break;
}
buf = cp;
}
/*
 * Create many child threads in order to enlarge time lag between
 * the OOM killer sets TIF_MEMDIE to thread group leader and
 * the OOM killer sends SIGKILL to that thread.
 */
for (i = 0; i < 1000; i++) {
clone(dummy, malloc(1024) + 1024, CLONE_SIGHAND | CLONE_VM,
  NULL);
}
/* Let a child thread trigger the OOM killer. */
clone(trigger, malloc(4096)+ 4096, CLONE_SIGHAND | CLONE_VM, NULL);
/* Deplete all memory reserve using the time lag. */
for (i = size; i; i -= 4096)
buf[i - 1] = 1;
return * (char *) NULL; /* Kill all threads. */
}
-- oom-depleter3.c end --

uptime > 350 of http://I-love.SAKURA.ne.jp/tmp/serial-20150922-1.txt.xz
shows that the memory reserves completely depleted and
uptime > 42 of http://I-love.SAKURA.ne.jp/tmp/serial-20150922-2.txt.xz
shows that the memory reserves was not used at all.
Is this result what you expected?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Intel-wired-lan] [PATCH] igb: add more checks for disconnected adapter

[Jarod Wilson]

Alexander Duyck wrote:

On 09/21/2015 10:11 AM, Jarod Wilson wrote:

Some pci changes upcoming in 4.3 seem to cause additional disconnects,
which can happen at unfortuitous times for igb, leading to issues such as
this, where the disconnect happened just before igb_configure_tx_ring():

[ 414.440115] igb :15:00.0: enabling device ( -> 0002)
[ 414.474934] pps pps0: new PPS source ptp1
[ 414.474937] igb :15:00.0: added PHC on eth0
[ 414.474938] igb :15:00.0: Intel(R) Gigabit Ethernet Network
Connection
[ 414.474940] igb :15:00.0: eth0: (PCIe:2.5Gb/s:Width x1)
e8:ea:6a:00:1b:2a
[ 414.475072] igb :15:00.0: eth0: PBA No: 000200-000
[ 414.475073] igb :15:00.0: Using MSI-X interrupts. 4 rx queue(s),
4 tx queue(s)
[ 414.478453] igb :15:00.0 enp21s0: renamed from eth0
[ 414.497747] IPv6: ADDRCONF(NETDEV_UP): enp21s0: link is not ready
[ 414.536745] igb :15:00.0 enp21s0: PCIe link lost, device now
detached
[ 414.854808] BUG: unable to handle kernel paging request at
3818
[ 414.854827] IP: []
igb_configure_tx_ring+0x14c/0x250 [igb]
[ 414.854846] PGD 0
[ 414.854849] Oops: 0002 [#1] SMP
[ 414.854856] Modules linked in: firewire_ohci firewire_core crc_itu_t
igb dca ctr ccm arc4 iwlmvm mac80211 fuse xt_CHECKSUM ipt_MASQUERADE
nf_nat_masquerade_ipv4 tun ip6t_rpfilter ip6t_REJECT nf_reject_ipv6
ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat ebtable_broute
bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6
nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security
ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle
iptable_security iptable_raw iptable_filter bnep dm_mirror
dm_region_hash dm_log dm_mod snd_hda_codec_hdmi coretemp
x86_pkg_temp_thermal intel_powerclamp kvm_intel iTCO_wdt ppdev kvm
iTCO_vendor_support hp_wmi sparse_keymap crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel
[ 414.855073] drbg ansi_cprng snd_hda_codec_realtek
snd_hda_codec_generic aesni_intel aes_x86_64 lrw gf128mul glue_helper
ablk_helper cryptd snd_hda_intel snd_hda_codec microcode snd_hda_core
snd_hwdep snd_seq snd_seq_device snd_pcm iwlwifi uvcvideo btusb
cfg80211 videobuf2_vmalloc videobuf2_memops btrtl btbcm videobuf2_core
btintel bluetooth v4l2_common snd_timer videodev snd parport_pc
rtsx_pci_ms joydev pcspkr input_leds i2c_i801 media sg memstick rfkill
soundcore lpc_ich 8250_fintek parport mei_me hp_accel ie31200_edac
shpchp lis3lv02d mei edac_core input_polldev hp_wireless tpm_infineon
sch_fq_codel nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs
libcrc32c sr_mod sd_mod cdrom rtsx_pci_sdmmc mmc_core crc32c_intel
serio_raw rtsx_pci nouveau mxm_wmi ahci hwmon libahci e1000e
drm_kms_helper
[ 414.855309] ptp xhci_pci pps_core ttm xhci_hcd wmi video ipv6 autofs4
[ 414.855331] CPU: 2 PID: 875 Comm: NetworkManager Not tainted
4.2.0-5.el7_UNSUPPORTED.x86_64 #1
[ 414.855348] Hardware name: Hewlett-Packard HP ZBook 15 G2/2253, BIOS
M70 Ver. 01.07 02/26/2015
[ 414.855365] task: 880484698c00 ti: 88005859c000 task.ti:
88005859c000
[ 414.855380] RIP: 0010:[] []
igb_configure_tx_ring+0x14c/0x250 [igb]
[ 414.855401] RSP: 0018:88005859f608 EFLAGS: 00010246
[ 414.855410] RAX: 3818 RBX:  RCX:
3818
[ 414.855424] RDX:  RSI: 0008 RDI:
002a9fe6
[ 414.855437] RBP: 88005859f638 R08: 03030300 R09:
ffe7
[ 414.855451] R10: 81fa91b4 R11: 07e3 R12:

[ 414.855464] R13: 880471c98840 R14: 8804670a1180 R15:
000483cce000
[ 414.855478] FS: 7f389c6fb8c0() GS:88049dc8()
knlGS:
[ 414.855493] CS: 0010 DS:  ES:  CR0: 80050033
[ 414.855504] CR2: 3818 CR3: 0004875da000 CR4:
001406e0
[ 414.855518] Stack:
[ 414.855520] 88005859f638 880471c98840 880471c98df8
0001
[ 414.855538] 880471c98848 0001 88005859f698
a0b99cb0
[ 414.85] 88005859f678 59ab02179a7fe4d0 f3ce6b27ad46225f
f5454218094e72d1
[ 414.855572] Call Trace:
[ 414.855577] [] igb_configure+0x240/0x400 [igb]
[ 414.855590] [] __igb_open+0xc2/0x560 [igb]
[ 414.855602] [] ? notifier_call_chain+0x4d/0x80
[ 414.855614] [] igb_open+0x10/0x20 [igb]
[ 414.855625] [] __dev_open+0xb1/0x130
[ 414.855636] [] __dev_change_flags+0xa1/0x160
[ 414.855647] [] dev_change_flags+0x29/0x60
[ 414.855658] [] do_setlink+0x5d3/0xaa0
[ 414.855679] [] ? nla_parse+0xa3/0x100
[ 414.855689] [] rtnl_newlink+0x4f0/0x880
[ 414.855700] [] ? rtnl_newlink+0xf3/0x880
[ 414.855721] [] ? netlink_unicast+0x1ae/0x220
[ 414.855734] [] ? security_capable+0x48/0x60
[ 414.855746] [] ? ns_capable+0x2d/0x60
[ 414.855756] [] rtnetlink_rcv_msg+0x95/0x240
[ 414.855768] [] ? sock_has_perm+0x70/0x90
[ 414.855779] [] ? rtnetlink_rcv+0x40/0x40
[ 414.855789] [] netlink_rcv_skb+0xaf/0xc0
[ 414.855800] [] rtnetlink_rcv+0x2c/0x40
[ 

Re: Re: [Xen-devel] [PATCH RFC] xen: if on Xen, "flatten" the scheduling domain hierarchy

[Juergen Gross]

On 09/21/2015 07:49 AM, Juergen Gross wrote:

On 09/15/2015 06:50 PM, Dario Faggioli wrote:

On Thu, 2015-08-20 at 20:16 +0200, Juergen Groß wrote:

On 08/18/2015 05:55 PM, Dario Faggioli wrote:

Hey everyone,

So, as a followup of what we were discussing in this thread:

   [Xen-devel] PV-vNUMA issue: topology is misinterpreted by the guest

http://lists.xenproject.org/archives/html/xen-devel/2015-07/msg03241.html


I started looking in more details at scheduling domains in the Linux
kernel. Now, that thread was about CPUID and vNUMA, and their weird way
of interacting, while this thing I'm proposing here is completely
independent from them both.

In fact, no matter whether vNUMA is supported and enabled, and no
matter
whether CPUID is reporting accurate, random, meaningful or completely
misleading information, I think that we should do something about how
scheduling domains are build.

Fact is, unless we use 1:1, and immutable (across all the guest
lifetime) pinning, scheduling domains should not be constructed, in
Linux, by looking at *any* topology information, because that just does
not make any sense, when vcpus move around.

Let me state this again (hoping to make myself as clear as
possible): no
matter in  how much good shape we put CPUID support, no matter how
beautifully and consistently that will interact with both vNUMA,
licensing requirements and whatever else. It will be always possible
for
vCPU #0 and vCPU #3 to be scheduled on two SMT threads at time t1, and
on two different NUMA nodes at time t2. Hence, the Linux scheduler
should really not skew his load balancing logic toward any of those two
situations, as neither of them could be considered correct (since
nothing is!).

For now, this only covers the PV case. HVM case shouldn't be any
different, but I haven't looked at how to make the same thing happen in
there as well.

OVERALL DESCRIPTION
===
What this RFC patch does is, in the Xen PV case, configure scheduling
domains in such a way that there is only one of them, spanning all the
pCPUs of the guest.

Note that the patch deals directly with scheduling domains, and
there is
no need to alter the masks that will then be used for building and
reporting the topology (via CPUID, /proc/cpuinfo, /sysfs, etc.).
That is
the main difference between it and the patch proposed by Juergen here:
http://lists.xenproject.org/archives/html/xen-devel/2015-07/msg05088.html


This means that when, in future, we will fix CPUID handling and make it
comply with whatever logic or requirements we want, that won't have
any
unexpected side effects on scheduling domains.

Information about how the scheduling domains are being constructed
during boot are available in `dmesg', if the kernel is booted with the
'sched_debug' parameter. It is also possible to look
at /proc/sys/kernel/sched_domain/cpu*, and at /proc/schedstat.

With the patch applied, only one scheduling domain is created, called
the 'VCPU' domain, spanning all the guest's (or Dom0's) vCPUs. You can
tell that from the fact that every cpu* folder
in /proc/sys/kernel/sched_domain/ only have one subdirectory
('domain0'), with all the tweaks and the tunables for our scheduling
domain.

EVALUATION
==
I've tested this with UnixBench, and by looking at Xen build time, on a
16, 24 and 48 pCPUs hosts. I've run the benchmarks in Dom0 only, for
now, but I plan to re-run them in DomUs soon (Juergen may be doing
something similar to this in DomU already, AFAUI).

I've run the benchmarks with and without the patch applied ('patched'
and 'vanilla', respectively, in the tables below), and with different
number of build jobs (in case of the Xen build) or of parallel copy of
the benchmarks (in the case of UnixBench).

What I get from the numbers is that the patch almost always brings
benefits, in some cases even huge ones. There are a couple of cases
where we regress, but always only slightly so, especially if comparing
that to the magnitude of some of the improvement that we get.

Bear also in mind that these results are gathered from Dom0, and
without
any overcommitment at the vCPU level (i.e., nr. vCPUs == nr pCPUs). If
we move things in DomU and do overcommit at the Xen scheduler level, I
am expecting even better results.


...

REQUEST FOR COMMENTS

Basically, the kind of feedback I'd be really glad to hear is:
   - what you guys thing of the approach,


Yesterday at the end of the developer meeting we (Andrew, Elena and
myself) discussed this topic again.


Hey,

Sorry for replying so late, I've been on vacation from right after
XenSummit up until yesterday. :-)


Regarding a possible future scenario with credit2 eventually supporting
gang scheduling on hyperthreads (which is desirable due to security
reasons [side channel attack] and fairness) my patch seems to be more
suited for that direction than yours.


Ok. Just let me mention that 'Credit2 + gang scheduling' might not be
exactly around the corner (although, we can 

Re: [PATCH] staging: dgap: fix returned errno code in dgap_parsefile()

[Sudip Mukherjee]

On Tue, Sep 22, 2015 at 02:39:36AM +0200, Javier Martinez Canillas wrote:
> The driver is using -1 instead of the -ENOMEM defined macro to specify
> that a buffer allocation failed. Since the error number is propagated,
> the caller will get a -EPERM which is the wrong error condition.
Just a little doubt. caller means the function which is calling this
dgap_parsefile() or you meant the user?
The function which is calling this dgap_parsefile() is just checking if
it has received 0 or something else. Something else is error and it
rerturns -EINVAL for all types of error (ofcourse that is also wrong).
So the user will see -EINVAL for all types of error in dgap_parsefile().

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] SH Drivers Updates for v4.3

[Simon Horman]

On Mon, Sep 21, 2015 at 12:19:03PM -0700, Linus Torvalds wrote:
> On Thu, Sep 17, 2015 at 2:00 AM, Simon Horman
>  wrote:
> >
> > Please consider these SH drivers updates for v4.3.
> 
> Hmm. This was caught as spam by google, along with the two patches you
> sent separately.
> 
> I'm not quite sure why. There's nothing obviously bad in the headers,
> which makes me suspect it's that your ISP is known as a spam source,
> so the IP range it comes in from looks bad. Or something similar.
> 
> It might help to do SPF records or similar.

Thanks, I will investigate.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] mm/vmscan: make inactive_anon_is_low_global return directly

[David Rientjes]

On Wed, 16 Sep 2015, Yaowei Bai wrote:

> Delete unnecessary if to let inactive_anon_is_low_global return
> directly.
> 
> No functional changes.
> 
> Signed-off-by: Yaowei Bai 

Acked-by: David Rientjes 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/3] net: irda: pxaficp_ir: use sched_clock() for time management

[David Miller]

From: Robert Jarzmik 
Date: Fri, 18 Sep 2015 18:36:56 +0200

> Which brings me to wonder which is the more correct :
>  (a) replace to reproduce the same calculation
>  Previously mtt was compared to a difference of 76ns steps (as 307ns / 4 =
>  76ns):
>  while ((sched_clock() - si->last_clk) * 76 < mtt)
> 
>  (b) change the calculation assuming mtt is in microseconds :
>  while ((sched_clock() - si->last_clk) * 1000 < mtt)
> 
> I have no IRDA protocol knowledge so unless someone points me to the correct
> calculation I'll try my luck with (b).

"a" would be "safer" and less likely to break anything, although as
you say "b" might be more correct.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 17/17] mfd : ab8500/db8500: fix the abuse of IRQF_NO_SUSPEND

[Lee Jones]

On Mon, 21 Sep 2015, Sudeep Holla wrote:

> The IRQF_NO_SUSPEND flag is used to identify the interrupts that should
> be left enabled so as to allow them to work as expected during the
> suspend-resume cycle, but doesn't guarantee that it will wake the system
> from a suspended state, enable_irq_wake is recommended to be used for
> the wakeup.
> 
> This patch removes the use of IRQF_NO_SUSPEND flags replacing it with
> enable_irq_wake instead.
> 
> Cc: Linus Walleij 
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Sudeep Holla 
> ---
>  drivers/mfd/ab8500-core.c| 11 +--
>  drivers/mfd/ab8500-debugfs.c |  2 +-
>  drivers/mfd/ab8500-gpadc.c   | 15 +++
>  drivers/mfd/db8500-prcmu.c   | 24 +---
>  drivers/power/ab8500_btemp.c |  6 --
>  drivers/power/ab8500_charger.c   |  6 --
>  drivers/power/ab8500_fg.c|  9 ++---
>  drivers/thermal/db8500_thermal.c |  5 ++---
>  drivers/usb/phy/phy-ab8500-usb.c | 10 ++
>  9 files changed, 60 insertions(+), 28 deletions(-)

Is there a reason for bundling the changes in all of these subsystems
together into a single patch?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 07/17] input: tegra-kbc: drop use of IRQF_NO_SUSPEND flag

[Lee Jones]

The $SUBJECT is not correct.

> The driver handles wakeup irq correctly using irq_set_irq_wake. There's
> no need to use IRQF_NO_SUSPEND while registering the interrupt.
> 
> This patch removes the use of IRQF_NO_SUSPEND flag.
> 
> Cc: Samuel Ortiz 
> Cc: Lee Jones 
> Signed-off-by: Sudeep Holla 
> ---
>  drivers/mfd/qcom_rpm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

... code is fine though:

Acked-by: Lee Jones 

Please re-submit with the subject line fixed.

> diff --git a/drivers/mfd/qcom_rpm.c b/drivers/mfd/qcom_rpm.c
> index 6afc9fabd94c..207a3bd68559 100644
> --- a/drivers/mfd/qcom_rpm.c
> +++ b/drivers/mfd/qcom_rpm.c
> @@ -550,7 +550,7 @@ static int qcom_rpm_probe(struct platform_device *pdev)
>   ret = devm_request_irq(>dev,
>  irq_ack,
>  qcom_rpm_ack_interrupt,
> -IRQF_TRIGGER_RISING | IRQF_NO_SUSPEND,
> +IRQF_TRIGGER_RISING,
>  "qcom_rpm_ack",
>  rpm);
>   if (ret) {

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC v7 13/41] richacl: Check if an acl is equivalent to a file mode

[Andreas Gruenbacher]

2015-09-17 20:22 GMT+02:00 J. Bruce Fields :
> On Sat, Sep 05, 2015 at 12:27:08PM +0200, Andreas Gruenbacher wrote:
>> ACLs are considered equivalent to file modes if they only consist of
>> owner@, group@, and everyone@ entries, the owner@ permissions do not
>> depend on whether the owner is a member in the owning group, and no
>> inheritance flags are set.  This test is used to avoid storing richacls
>> if the acl can be computed from the file permission bits.
>
> We're assuming here that it's OK for us to silently rearrange an ACL as
> long as the result is still equivalent (in the sense that the permission
> algorithm would always produce the same result).
>
> I guess that's OK by me, but it might violate user expectations in some
> simple common cases, so may be worth mentioning in documentation
> someplace if we don't already.

I've tried to be clear about that in the man pages.

Thanks,
Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC v2 3/7] powerpc: atomic: Implement atomic{,64}_{add,sub}_return_* variants

[Boqun Feng]

On Tue, Sep 22, 2015 at 07:26:56AM +0800, Boqun Feng wrote:
> On Mon, Sep 21, 2015 at 11:24:27PM +0100, Will Deacon wrote:
> > Hi Boqun,
> > 
> > On Sun, Sep 20, 2015 at 09:23:03AM +0100, Boqun Feng wrote:
> > > On Sat, Sep 19, 2015 at 11:33:10PM +0800, Boqun Feng wrote:
> > > > On Fri, Sep 18, 2015 at 05:59:02PM +0100, Will Deacon wrote:
> > > > > On Wed, Sep 16, 2015 at 04:49:31PM +0100, Boqun Feng wrote:
> > > > > > On powerpc, we don't need a general memory barrier to achieve 
> > > > > > acquire and
> > > > > > release semantics, so __atomic_op_{acquire,release} can be 
> > > > > > implemented
> > > > > > using "lwsync" and "isync".
> > > > > 
> > > > > I'm assuming isync+ctrl isn't transitive, so we need to get to the 
> > > > > bottom
> > > > 
> > > > Actually the transitivity is still guaranteed here, I think ;-)
> > 
> > The litmus test I'm thinking of is:
> > 
> > 
> > {
> > 0:r2=x;
> > 1:r2=x; 1:r5=z;
> > 2:r2=z; 2:r4=x;
> > }
> >  P0   | P1| P2   ;
> >  li r1,1  | lwz r1,0(r2)  | lwz r1,0(r2) ;
> >  stw r1,0(r2) | cmpw r1,r1| cmpw r1,r1   ;
> >   | beq LC00  | beq  LC01;
> >   | LC00: | LC01:;
> >   | isync | isync;
> >   | li r4,1   | lwz r3,0(r4) ;
> >   | stw r4,0(r5)  |  ;
> > exists
> > (1:r1=1 /\ 2:r1=1 /\ 2:r3=0)
> > 
> > 
> > Which appears to be allowed. I don't think you need to worry about backwards
> > branches for the ctrl+isync construction (none of the current example do,
> > afaict).
> > 
> 
> Yes.. my care of backwards branches is not quite related to the topic, I
> concerned that mostly because my test is using atomic operation, and I
> just want to test the exact asm code.
> 
> > Anyway, all the problematic cases seem to arise when we start mixing
> > ACQUIRE/RELEASE accesses with relaxed accesses (i.e. where an access from
> > one group reads from an access in the other group). It would be simplest
> > to say that this doesn't provide any transitivity guarantees, and that
> > an ACQUIRE must always read from a RELEASE if transitivity is required.
> > 
> 
> Agreed. RELEASE alone doesn't provide transitivity and transitivity is
  ^^^
This should be ACQUIRE...

> guaranteed only if an ACQUIRE read from a RELEASE. That's exactly the
> direction which the link (https://lkml.org/lkml/2015/9/15/836) is
> heading to. So I think we are fine here to use ctrl+isync here, right?
> 
> Regards,
> Boqun


signature.asc
Description: PGP signature

[PATCH 2/3] mmc: debugfs: implement ios show for SDR12 and SDR25

[Shawn Lin]

This patch add MMC_TIMING_UHS_SDR12 and MMC_TIMING_UHS_SDR25
for mmc_ios_show to show the ios->timing if mmc card runs under
these two mode.

Signed-off-by: Shawn Lin 
---

 drivers/mmc/core/debugfs.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/mmc/core/debugfs.c b/drivers/mmc/core/debugfs.c
index b2ab936..31155e8 100644
--- a/drivers/mmc/core/debugfs.c
+++ b/drivers/mmc/core/debugfs.c
@@ -126,6 +126,12 @@ static int mmc_ios_show(struct seq_file *s, void *data)
case MMC_TIMING_SD_HS:
str = "sd high-speed";
break;
+   case MMC_TIMING_UHS_SDR12:
+   str = "mmc uhs SDR12";
+   break;
+   case MMC_TIMING_UHS_SDR25:
+   str = "mmc uhs SDR25";
+   break;
case MMC_TIMING_UHS_SDR50:
str = "sd uhs SDR50";
break;
-- 
2.3.7


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH net-next] Driver: Vmxnet3: Extend register dump support

[Shrikrishna Khare]

Signed-off-by: Shrikrishna Khare 
Signed-off-by: Bhavesh Davda 
Acked-by: Srividya Murali 
---
 drivers/net/vmxnet3/vmxnet3_ethtool.c | 118 ++
 drivers/net/vmxnet3/vmxnet3_int.h |   4 +-
 2 files changed, 92 insertions(+), 30 deletions(-)

diff --git a/drivers/net/vmxnet3/vmxnet3_ethtool.c 
b/drivers/net/vmxnet3/vmxnet3_ethtool.c
index c1d0e7a..a681569 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethtool.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethtool.c
@@ -183,16 +183,22 @@ vmxnet3_get_sset_count(struct net_device *netdev, int 
sset)
 }
 
 
-/* Should be multiple of 4 */
-#define NUM_TX_REGS8
-#define NUM_RX_REGS12
-
+/* This is a version 2 of the vmxnet3 ethtool_regs which goes hand in hand with
+ * the version 2 of the vmxnet3 support for ethtool(8) --register-dump.
+ * Therefore, if any registers are added, removed or modified, then a version
+ * bump and a corresponding change in the vmxnet3 support for ethtool(8)
+ * --register-dump would be required.
+ */
 static int
 vmxnet3_get_regs_len(struct net_device *netdev)
 {
struct vmxnet3_adapter *adapter = netdev_priv(netdev);
-   return (adapter->num_tx_queues * NUM_TX_REGS * sizeof(u32) +
-   adapter->num_rx_queues * NUM_RX_REGS * sizeof(u32));
+
+   return ((9 /* BAR1 registers */ +
+   (1 + adapter->intr.num_intrs) +
+   (1 + adapter->num_tx_queues * 17 /* Tx queue registers */) +
+   (1 + adapter->num_rx_queues * 23 /* Rx queue registers */)) *
+   sizeof(u32));
 }
 
 
@@ -342,6 +348,12 @@ vmxnet3_get_ethtool_stats(struct net_device *netdev,
 }
 
 
+/* This is a version 2 of the vmxnet3 ethtool_regs which goes hand in hand with
+ * the version 2 of the vmxnet3 support for ethtool(8) --register-dump.
+ * Therefore, if any registers are added, removed or modified, then a version
+ * bump and a corresponding change in the vmxnet3 support for ethtool(8)
+ * --register-dump would be required.
+ */
 static void
 vmxnet3_get_regs(struct net_device *netdev, struct ethtool_regs *regs, void *p)
 {
@@ -351,40 +363,90 @@ vmxnet3_get_regs(struct net_device *netdev, struct 
ethtool_regs *regs, void *p)
 
memset(p, 0, vmxnet3_get_regs_len(netdev));
 
-   regs->version = 1;
+   regs->version = 2;
 
/* Update vmxnet3_get_regs_len if we want to dump more registers */
 
-   /* make each ring use multiple of 16 bytes */
-   for (i = 0; i < adapter->num_tx_queues; i++) {
-   buf[j++] = adapter->tx_queue[i].tx_ring.next2fill;
-   buf[j++] = adapter->tx_queue[i].tx_ring.next2comp;
-   buf[j++] = adapter->tx_queue[i].tx_ring.gen;
-   buf[j++] = 0;
+   buf[j++] = VMXNET3_READ_BAR1_REG(adapter, VMXNET3_REG_VRRS);
+   buf[j++] = VMXNET3_READ_BAR1_REG(adapter, VMXNET3_REG_UVRS);
+   buf[j++] = VMXNET3_READ_BAR1_REG(adapter, VMXNET3_REG_DSAL);
+   buf[j++] = VMXNET3_READ_BAR1_REG(adapter, VMXNET3_REG_DSAH);
+   buf[j++] = VMXNET3_READ_BAR1_REG(adapter, VMXNET3_REG_CMD);
+   buf[j++] = VMXNET3_READ_BAR1_REG(adapter, VMXNET3_REG_MACL);
+   buf[j++] = VMXNET3_READ_BAR1_REG(adapter, VMXNET3_REG_MACH);
+   buf[j++] = VMXNET3_READ_BAR1_REG(adapter, VMXNET3_REG_ICR);
+   buf[j++] = VMXNET3_READ_BAR1_REG(adapter, VMXNET3_REG_ECR);
+
+   buf[j++] = adapter->intr.num_intrs;
+   for (i = 0; i < adapter->intr.num_intrs; i++) {
+   buf[j++] = VMXNET3_READ_BAR0_REG(adapter, VMXNET3_REG_IMR
++ i * VMXNET3_REG_ALIGN);
+   }
 
-   buf[j++] = adapter->tx_queue[i].comp_ring.next2proc;
-   buf[j++] = adapter->tx_queue[i].comp_ring.gen;
-   buf[j++] = adapter->tx_queue[i].stopped;
-   buf[j++] = 0;
+   buf[j++] = adapter->num_tx_queues;
+   for (i = 0; i < adapter->num_tx_queues; i++) {
+   struct vmxnet3_tx_queue *tq = >tx_queue[i];
+
+   buf[j++] = VMXNET3_READ_BAR0_REG(adapter, VMXNET3_REG_TXPROD +
+i * VMXNET3_REG_ALIGN);
+
+   buf[j++] = VMXNET3_GET_ADDR_LO(tq->tx_ring.basePA);
+   buf[j++] = VMXNET3_GET_ADDR_HI(tq->tx_ring.basePA);
+   buf[j++] = tq->tx_ring.size;
+   buf[j++] = tq->tx_ring.next2fill;
+   buf[j++] = tq->tx_ring.next2comp;
+   buf[j++] = tq->tx_ring.gen;
+
+   buf[j++] = VMXNET3_GET_ADDR_LO(tq->data_ring.basePA);
+   buf[j++] = VMXNET3_GET_ADDR_HI(tq->data_ring.basePA);
+   buf[j++] = tq->data_ring.size;
+   /* transmit data ring buffer size */
+   buf[j++] = VMXNET3_HDR_COPY_SIZE;
+
+   buf[j++] = VMXNET3_GET_ADDR_LO(tq->comp_ring.basePA);
+   buf[j++] = VMXNET3_GET_ADDR_HI(tq->comp_ring.basePA);
+   buf[j++] = tq->comp_ring.size;
+ 

[PATCH] DOC: filesystem: Fix typo in fs/eventfd.c

[Masanari Iida]

This patch fix typos found in Documentation/filesystems.xml,
DocBook/filesystems/API-eventfd-signal.html, and
DocBook/filesystems.aux.xml

These files are generated from comments within the source,
so I had to fix typos in fs/eventfd.c

Signed-off-by: Masanari Iida 
---
 fs/eventfd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/eventfd.c b/fs/eventfd.c
index 8d0c0df..ed70cf9 100644
--- a/fs/eventfd.c
+++ b/fs/eventfd.c
@@ -45,10 +45,10 @@ struct eventfd_ctx {
  *
  * This function is supposed to be called by the kernel in paths that do not
  * allow sleeping. In this function we allow the counter to reach the 
ULLONG_MAX
- * value, and we signal this as overflow condition by returining a POLLERR
+ * value, and we signal this as overflow condition by returning a POLLERR
  * to poll(2).
  *
- * Returns the amount by which the counter was incrememnted.  This will be less
+ * Returns the amount by which the counter was incremented.  This will be less
  * than @n if the counter has overflowed.
  */
 __u64 eventfd_signal(struct eventfd_ctx *ctx, __u64 n)
-- 
2.6.0.rc2.23.g0e57679

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 4/6] virtio-gpu: add 3d/virgl support

[Michael S. Tsirkin]

On Mon, Sep 21, 2015 at 11:40:15AM +0200, Gerd Hoffmann wrote:
> Add the bits needed for opengl rendering support: query
> capabilities, new virtio commands, drm ioctls.
> 
> Signed-off-by: Dave Airlie 
> Signed-off-by: Gerd Hoffmann 


Looks good to me overall.
Some minor comments below.

I had to fix dri-devel mailing list address.
Hope I did it correctly.


> ---
>  drivers/gpu/drm/virtio/Makefile|   3 +-
>  drivers/gpu/drm/virtio/virtgpu_drv.c   |  10 +
>  drivers/gpu/drm/virtio/virtgpu_drv.h   |  60 
>  drivers/gpu/drm/virtio/virtgpu_gem.c   |  41 +++
>  drivers/gpu/drm/virtio/virtgpu_ioctl.c | 572 
> +
>  drivers/gpu/drm/virtio/virtgpu_kms.c   | 135 +++-
>  drivers/gpu/drm/virtio/virtgpu_ttm.c   |   1 +
>  drivers/gpu/drm/virtio/virtgpu_vq.c| 265 +++
>  include/uapi/drm/Kbuild|   1 +
>  include/uapi/drm/virtgpu_drm.h | 167 ++
>  include/uapi/linux/virtio_gpu.h| 112 ++-
>  11 files changed, 1364 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/gpu/drm/virtio/virtgpu_ioctl.c
>  create mode 100644 include/uapi/drm/virtgpu_drm.h
> 
> diff --git a/drivers/gpu/drm/virtio/Makefile b/drivers/gpu/drm/virtio/Makefile
> index 2ee1602..da7bf19 100644
> --- a/drivers/gpu/drm/virtio/Makefile
> +++ b/drivers/gpu/drm/virtio/Makefile
> @@ -6,6 +6,7 @@ ccflags-y := -Iinclude/drm
>  
>  virtio-gpu-y := virtgpu_drv.o virtgpu_kms.o virtgpu_drm_bus.o virtgpu_gem.o \
>   virtgpu_fb.o virtgpu_display.o virtgpu_vq.o virtgpu_ttm.o \
> - virtgpu_fence.o virtgpu_object.o virtgpu_debugfs.o virtgpu_plane.o
> + virtgpu_fence.o virtgpu_object.o virtgpu_debugfs.o virtgpu_plane.o \
> + virtgpu_ioctl.o
>  
>  obj-$(CONFIG_DRM_VIRTIO_GPU) += virtio-gpu.o
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c 
> b/drivers/gpu/drm/virtio/virtgpu_drv.c
> index 7d9610a..957e455 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
> @@ -73,6 +73,9 @@ static struct virtio_device_id id_table[] = {
>  };
>  
>  static unsigned int features[] = {
> +#ifdef __LITTLE_ENDIAN
> + VIRTIO_GPU_FEATURE_VIRGL,
> +#endif
>  };

Why is virgl LE specific? Just curious.

>  static struct virtio_driver virtio_gpu_driver = {
>   .feature_table = features,
> @@ -114,6 +117,8 @@ static struct drm_driver driver = {
>   .set_busid = drm_virtio_set_busid,
>   .load = virtio_gpu_driver_load,
>   .unload = virtio_gpu_driver_unload,
> + .open = virtio_gpu_driver_open,
> + .postclose = virtio_gpu_driver_postclose,
>  
>   .dumb_create = virtio_gpu_mode_dumb_create,
>   .dumb_map_offset = virtio_gpu_mode_dumb_mmap,
> @@ -125,8 +130,13 @@ static struct drm_driver driver = {
>  #endif
>  
>   .gem_free_object = virtio_gpu_gem_free_object,
> + .gem_open_object = virtio_gpu_gem_object_open,
> + .gem_close_object = virtio_gpu_gem_object_close,
>   .fops = _gpu_driver_fops,
>  
> + .ioctls = virtio_gpu_ioctls,
> + .num_ioctls = DRM_VIRTIO_NUM_IOCTLS,
> +
>   .name = DRIVER_NAME,
>   .desc = DRIVER_DESC,
>   .date = DRIVER_DATE,
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index 6d4db2d..2719108 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -146,6 +146,21 @@ struct virtio_gpu_queue {
>   struct work_struct dequeue_work;
>  };
>  
> +struct virtio_gpu_drv_capset {
> + uint32_t id;
> + uint32_t max_version;
> + uint32_t max_size;
> +};
> +
> +struct virtio_gpu_drv_cap_cache {
> + struct list_head head;
> + void *caps_cache;
> + uint32_t id;
> + uint32_t version;
> + uint32_t size;
> + atomic_t is_valid;
> +};
> +
>  struct virtio_gpu_device {
>   struct device *dev;
>   struct drm_device *ddev;
> @@ -179,7 +194,13 @@ struct virtio_gpu_device {
>   struct idr  ctx_id_idr;
>   spinlock_t ctx_id_idr_lock;
>  
> + bool has_virgl_3d;
> +
>   struct work_struct config_changed_work;
> +
> + struct virtio_gpu_drv_capset *capsets;
> + uint32_t num_capsets;
> + struct list_head cap_cache;
>  };
>  
>  struct virtio_gpu_fpriv {
> @@ -193,6 +214,8 @@ extern struct drm_ioctl_desc 
> virtio_gpu_ioctls[DRM_VIRTIO_NUM_IOCTLS];
>  /* virtio_kms.c */
>  int virtio_gpu_driver_load(struct drm_device *dev, unsigned long flags);
>  int virtio_gpu_driver_unload(struct drm_device *dev);
> +int virtio_gpu_driver_open(struct drm_device *dev, struct drm_file *file);
> +void virtio_gpu_driver_postclose(struct drm_device *dev, struct drm_file 
> *file);
>  
>  /* virtio_gem.c */
>  void virtio_gpu_gem_free_object(struct drm_gem_object *gem_obj);
> @@ -203,6 +226,10 @@ int virtio_gpu_gem_create(struct drm_file *file,
> uint64_t size,
> struct drm_gem_object **obj_p,
> 

Re: [PATCH 2/5] hv: add helpers to handle hv_util device state

[Olaf Hering]

On Sun, Sep 20, Greg KH wrote:

> Just use a lock, that's what it is there for.

How would that help? It might help because it enforces ordering. But
that requires that all three utils get refactored to deal with the
introduced locking. I will let KY comment on this.

The issue I see with fcopy is that after or while fcopy_respond_to_host
runs an interrupt triggers which also calls into
hv_fcopy_onchannelcallback.  It was most likely caused by a logic change
in "recent" vmbus updates because this did not happen before. At least,
the fcopy hang was not seen earler. Maybe the bug did just not trigger
up to now for other reasons...

Olaf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] fs: fix data races on inode->i_flctx

[Jeff Layton]

On Mon, 21 Sep 2015 09:43:06 +0200
Dmitry Vyukov  wrote:

> locks_get_lock_context() uses cmpxchg() to install i_flctx.
> cmpxchg() is a release operation which is correct. But it uses
> a plain load to load i_flctx. This is incorrect. Subsequent loads
> from i_flctx can hoist above the load of i_flctx pointer itself
> and observe uninitialized garbage there. This in turn can lead
> to corruption of ctx->flc_lock and other members.
> 

I don't get this bit. The i_flctx field is initialized to zero when the
inode is allocated, and we only assign it with cmpxchg(). How would you
ever see uninitialized garbage in there? It should either be NULL or a
valid pointer, no?

If that'st the case, then most of the places where you're adding
smp_load_acquire are places that can tolerate seeing NULL there. e.g.
you have racing LOCK_EX/LOCK_UN flock() calls in different tasks or
something.

> Documentation/memory-barriers.txt explicitly requires to use
> a barrier in such context:
> "A load-load control dependency requires a full read memory barrier".
> 

The same file also says:

"Any atomic operation that modifies some state in memory and returns information
about the state (old or new) implies an SMP-conditional general memory barrier
(smp_mb()) on each side of the actual operation (with the exception of
explicit lock operations, described later).  These include:

...
/* when succeeds */
cmpxchg();
"

If there is an implied smp_mb() before and after the cmpxchg(), how
could the CPU hoist anything before that point?

Note that I'm not saying that you're wrong, I just want to make sure I
fully understand the problem before we go trying to fix it.

> Use smp_load_acquire() in locks_get_lock_context() and in bunch
> of other functions that can proceed concurrently with
> locks_get_lock_context().
> 
> The data race was found with KernelThreadSanitizer (KTSAN).
> 
> Signed-off-by: Dmitry Vyukov 
> ---
> For the record, here is the KTSAN report:
> 
> ThreadSanitizer: data-race in _raw_spin_lock
> 
> Read at 0x8800bae50da0 of size 1 by thread 3060 on CPU 2:
>  [< inline >] __raw_spin_lock include/linux/spinlock_api_smp.h:158
>  [] _raw_spin_lock+0x50/0x70 kernel/locking/spinlock.c:151
>  [< inline >] spin_lock include/linux/spinlock.h:312
>  [] flock_lock_inode+0xb7/0x440 fs/locks.c:895
>  [] flock_lock_inode_wait+0x46/0x110 fs/locks.c:1871
>  [] SyS_flock+0x224/0x23
> 
> Previous write at 0x8800bae50da0 of size 8 by thread 3063 on CPU 8:
>  [] kmem_cache_alloc+0xd8/0x2f0 mm/slab.c:3420
>  [] locks_get_lock_context+0x60/0x140 fs/locks.c:213
>  [] flock_lock_inode+0x5a/0x440 fs/locks.c:882
>  [] flock_lock_inode_wait+0x46/0x110 fs/locks.c:1871
>  [< inline >] flock_lock_file_wait include/linux/fs.h:1219
>  [< inline >] SYSC_flock fs/locks.c:1941
>  [] SyS_flock+0x224/0x230 fs/locks.c:1904
>  [] entry_SYSCALL_64_fastpath+0x31/0x95 
> arch/x86/entry/entry_64.S:188
> ---
>  fs/locks.c | 63 
> +++---
>  1 file changed, 36 insertions(+), 27 deletions(-)
> 
> diff --git a/fs/locks.c b/fs/locks.c
> index 2a54c80..316e474 100644
> --- a/fs/locks.c
> +++ b/fs/locks.c
> @@ -205,28 +205,32 @@ static struct kmem_cache *filelock_cache __read_mostly;
>  static struct file_lock_context *
>  locks_get_lock_context(struct inode *inode, int type)
>  {
> - struct file_lock_context *new;
> + struct file_lock_context *ctx;
>  
> - if (likely(inode->i_flctx) || type == F_UNLCK)
> + /* paired with cmpxchg() below */
> + ctx = smp_load_acquire(>i_flctx);
> + if (likely(ctx) || type == F_UNLCK)
>   goto out;
>  
> - new = kmem_cache_alloc(flctx_cache, GFP_KERNEL);
> - if (!new)
> + ctx = kmem_cache_alloc(flctx_cache, GFP_KERNEL);
> + if (!ctx)
>   goto out;
>  
> - spin_lock_init(>flc_lock);
> - INIT_LIST_HEAD(>flc_flock);
> - INIT_LIST_HEAD(>flc_posix);
> - INIT_LIST_HEAD(>flc_lease);
> + spin_lock_init(>flc_lock);
> + INIT_LIST_HEAD(>flc_flock);
> + INIT_LIST_HEAD(>flc_posix);
> + INIT_LIST_HEAD(>flc_lease);
>  
>   /*
>* Assign the pointer if it's not already assigned. If it is, then
>* free the context we just allocated.
>*/
> - if (cmpxchg(>i_flctx, NULL, new))
> - kmem_cache_free(flctx_cache, new);
> + if (cmpxchg(>i_flctx, NULL, ctx)) {
> + kmem_cache_free(flctx_cache, ctx);
> + ctx = smp_load_acquire(>i_flctx);
> + }
>  out:
> - return inode->i_flctx;
> + return ctx;
>  }
>  
>  void
> @@ -762,7 +766,7 @@ posix_test_lock(struct file *filp, struct file_lock *fl)
>   struct file_lock_context *ctx;
>   struct inode *inode = file_inode(filp);
>  
> - ctx = inode->i_flctx;
> + ctx = smp_load_acquire(>i_flctx);
>   if (!ctx || list_empty_careful(>flc_posix)) {
>   fl->fl_type = F_UNLCK;
>   

RE: [PATCH v9 12/18] vfio: Register/unregister irq_bypass_producer

[Wu, Feng]

> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Monday, September 21, 2015 5:32 PM
> To: Wu, Feng; alex.william...@redhat.com; j...@8bytes.org;
> mtosa...@redhat.com
> Cc: eric.au...@linaro.org; k...@vger.kernel.org;
> io...@lists.linux-foundation.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v9 12/18] vfio: Register/unregister irq_bypass_producer
> 
> 
> 
> On 21/09/2015 10:56, Wu, Feng wrote:
> > Hi Paolo & Alex,
> >
> > I find that there is a build error in the following two cases:
> > - KVM is configured as 'M' and VFIO as 'Y'
> > The reason is the build of irqbypass manager is triggered in
> > arch/x86/kvm/Makefile, and VFIO is built before KVM, hence
> > it cannot find the symbols in irqbypass manager.
> >
> > - Disable KVM and enable VFIO in .config
> > The reason is similar with the above one, the irqbypass manager
> > is not built since KVM is not configured.
> >
> > I think the point is that we cannot trigger the build of irqbypass
> > manager inside KVM or VFIO, we need trigger the build at a high
> > level and it should be built before VFIO and KVM. Any ideas?
> 
> We can add virt/Makefile and build virt/lib/ directly, not through
> arch/x86/kvm.

Yes, that can solve the build error. Should I send a new version?

Thanks,
Feng

> 
> Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3] arm64: Introduce IRQ stack

[Jungseok Lee]

Currently, kernel context and interrupts are handled using a single
kernel stack navigated by sp_el1. This forces a system to use 16KB
stack, not 8KB one. This restriction makes low memory platforms suffer
from memory pressure accompanied by performance degradation.

This patch addresses the issue as introducing a separate percpu IRQ
stack to handle both hard and soft interrupts with two ground rules:

  - Utilize sp_el0 in EL1 context, which is not used currently
  - Do not complicate current_thread_info calculation

It is a core concept to directly retrieve struct thread_info from
sp_el0. This approach helps to prevent text section size from being
increased largely as removing masking operation using THREAD_SIZE
in tons of places.

[Thanks to James Morse for his valuable feedbacks which greatly help
to figure out a better implementation. - Jungseok]

Tested-by: James Morse 
Signed-off-by: Jungseok Lee 
---
Changes since v2:
- Optmised current_thread_info function as removing masking operation
  and volatile keyword per James and Catalin
- Reworked irq re-enterance check logic using top-bit comparison of
  stacks per James
- Added sp_el0 update in cpu_resume per James
- Selected HAVE_IRQ_EXIT_ON_IRQ_STACK to expose this feature explicitly
- Added a Tested-by tag from James
- Added comments on sp_el0 as a helper messeage

Changes since v1:
- Rebased on top of v4.3-rc1
- Removed Kconfig about IRQ stack, per James
- Used PERCPU for IRQ stack, per James
- Tried to allocate IRQ stack when CPU is about to start up, per James
- Moved sp_el0 update into kernel_entry macro, per James
- Dropped S_SP removal patch, per Mark and James

 arch/arm64/Kconfig   |  1 +
 arch/arm64/include/asm/irq.h |  2 +
 arch/arm64/include/asm/thread_info.h | 10 -
 arch/arm64/kernel/entry.S| 35 +---
 arch/arm64/kernel/head.S |  5 +++
 arch/arm64/kernel/irq.c  | 21 ++
 arch/arm64/kernel/sleep.S|  2 +
 arch/arm64/kernel/smp.c  |  6 +++
 8 files changed, 75 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 7d95663..829de2b 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -67,6 +67,7 @@ config ARM64
select HAVE_FUNCTION_GRAPH_TRACER
select HAVE_GENERIC_DMA_COHERENT
select HAVE_HW_BREAKPOINT if PERF_EVENTS
+   select HAVE_IRQ_EXIT_ON_IRQ_STACK
select HAVE_MEMBLOCK
select HAVE_PATA_PLATFORM
select HAVE_PERF_EVENTS
diff --git a/arch/arm64/include/asm/irq.h b/arch/arm64/include/asm/irq.h
index bbb251b..ba12725 100644
--- a/arch/arm64/include/asm/irq.h
+++ b/arch/arm64/include/asm/irq.h
@@ -10,6 +10,8 @@ struct pt_regs;
 extern void migrate_irqs(void);
 extern void set_handle_irq(void (*handle_irq)(struct pt_regs *));
 
+extern int alloc_irq_stack(unsigned int cpu);
+
 static inline void acpi_irq_init(void)
 {
/*
diff --git a/arch/arm64/include/asm/thread_info.h 
b/arch/arm64/include/asm/thread_info.h
index dcd06d1..fa014df 100644
--- a/arch/arm64/include/asm/thread_info.h
+++ b/arch/arm64/include/asm/thread_info.h
@@ -71,10 +71,16 @@ register unsigned long current_stack_pointer asm ("sp");
  */
 static inline struct thread_info *current_thread_info(void) 
__attribute_const__;
 
+/*
+ * struct thread_info can be accessed directly via sp_el0.
+ */
 static inline struct thread_info *current_thread_info(void)
 {
-   return (struct thread_info *)
-   (current_stack_pointer & ~(THREAD_SIZE - 1));
+   unsigned long sp_el0;
+
+   asm ("mrs %0, sp_el0" : "=r" (sp_el0));
+
+   return (struct thread_info *)sp_el0;
 }
 
 #define thread_saved_pc(tsk)   \
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 4306c93..7b4943b 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -88,7 +88,8 @@
 
.if \el == 0
mrs x21, sp_el0
-   get_thread_info tsk // Ensure MDSCR_EL1.SS is clear,
+   mov tsk, sp
+   and tsk, tsk, #~(THREAD_SIZE - 1)   // Ensure MDSCR_EL1.SS is clear,
ldr x19, [tsk, #TI_FLAGS]   // since we can unmask debug
disable_step_tsk x19, x20   // exceptions when scheduling.
.else
@@ -105,6 +106,7 @@
.if \el == 0
mvn x21, xzr
str x21, [sp, #S_SYSCALLNO]
+   msr sp_el0, tsk
.endif
 
/*
@@ -164,8 +166,28 @@ alternative_endif
.endm
 
.macro  get_thread_info, rd
-   mov \rd, sp
-   and \rd, \rd, #~(THREAD_SIZE - 1)   // top of stack
+   mrs \rd, sp_el0
+   .endm
+
+   .macro  irq_stack_entry
+   adr_l   x21, irq_stack
+   mrs x22, tpidr_el1
+   add x21, x21, x22
+   ldr x22, [x21]
+   and x21, x22, #~(THREAD_SIZE - 1)
+   mov x23, sp
+   and x23, x23, 

Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend

[Pavel Machek]

> > >> In fact, then, what you need seems to be the feature discussed by Alan
> > >> and me some time ago allowing remote wakeup do be disabled for runtime
> > >> PM from user space as that in combination with autosuspend should
> > >> address your use case.
> > >
> > > I'd doubt that. Suppose you put the phone into your pocket while
> > > the device isn't suspended. The continuous stream of spurious events
> > > will keep it awake.
> 
> Why would they be regarded as spurious then?  They are just regular touch 
> panel
> events in that case, aren't they?

>From userspace... they are spurious. Userspace does not known that
your device is commonly placed into the pocket, and the events it sees
are not from user.

I have mainline X/mate running on n900 cellphone. And this means
battery life is in "2 hours" range.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/