Re: [PATCH v2] usb: dwc2: reset dwc2 core before dwc2_get_hwparams()

[John Youn]

On 10/7/2015 5:50 PM, Doug Anderson wrote:
> John,
> 
> On Mon, Oct 5, 2015 at 3:02 PM, John Youn  wrote:
>> On 10/1/2015 1:50 PM, Doug Anderson wrote:
>>> John,
>>>
>>> On Tue, Aug 18, 2015 at 5:19 PM, John Youn  wrote:
 Hi Yunzhi,

 My concern is with the delays due to calling the dwc2_core_reset
 during probe. You could factor out the assertion of the core
 soft reset from the dwc2_core_reset and just use that before
 calling dwc2_get_hwparams().

 You had previously addressed the lengthy probe time issue here:
 http://marc.info/?l=linux-usb=142357721304377

 This reducing delays patch looks reasonable to me and I think it
 should get merged also. I'll do some testing with it later this
 week.
>>>
>>> Note: you can also avoid the extra reset during probe with something
>>> like .  I'm
>>> happy to post that up if you want, though it depends on lyz's patch.
>>>
>>> ...in Chrome OS we've also just landed lyz's patch to reduce delays.
>>> If there's any fallout I'll report on the list.
>>>
>>> -Doug
>>>
>>
>>
>> Yes, I appreciate if you could submit that. I'd like to merge lyz's
>> reduce delays, lyz's bug fix for hwparams, and your fix for double
>> reset.
> 
> OK, I've posted things up.  Let me know what you think.  Note that I
> took v2 of lyz's patch (not v3) since I liked it better.
> 
> 
>> The gadget side will also need something similar which I can do if
>> needed. Do you guys run gadget mode?
> 
> I don't personally run in gadget mode.  I think it's possible to get
> rk3288 to do it on one of the two ports, but I don't have it setup.
> 

No problem. I can make the gadget changes.

Thanks for submitting this.

Regards,
John

--
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: [RESEND PATCH v4 0/8] i2c: Relax mandatory I2C ID table passing

[Wolfram Sang]

As said to Kieran personally in Dublin, I want a verification that all
binding methods still work, especially runtime instantiation for drivers
without i2c_device_ids. Also, for the last patch, a verification should
be done if the drivers i2c_device_id hasn't been used meanwhile. I'd
also like to see 'probe_new' instead of 'probe2' for the new function
name. That should be it.

Thanks,

   Wolfram



signature.asc
Description: Digital signature

Re: [PATCH 0/7][v4] Add OTG support for FSL socs

[Felipe Balbi]

Hi,

Ramneek Mehresh  writes:
> Add support for otg for all freescale socs having internal
> usb phy.
>
> Ramneek Mehresh (7):
>   usb:fsl:otg: Make fsl otg driver as tristate
>   usb:fsl:otg: Add controller version based ULPI and UTMI phy
>   usb:fsl:otg: Add support to add/remove usb host driver
>   usb:fsl:otg: Signal host drv when host is otg
>   usb:fsl:otg: Modify otg_event to start host drv
>   usb:fsl:otg: Combine host/gadget start/resume for ID change
>   usb:fsl:otg: Add host-gadget drv sync delay

Unless Alan's okay with the host side changes, I can't accept any of
these. However, I must say some of the flags you add here already exist
in some way, shape or form. For example, look at is_b_host flag.

-- 
balbi


signature.asc
Description: PGP signature

[PATCH v3 3/7] drm/vc4: Add KMS support for Raspberry Pi.

[Eric Anholt]

This is enough for fbcon and bringing up X using
xf86-video-modesetting.  It doesn't support the 3D accelerator or
power management yet.

Signed-off-by: Eric Anholt 
Acked-by: Daniel Vetter 
---

v2: Drop FB_HELPER select thanks to Archit's patches.  Do manual init
ordering instead of using the .load hook.  Structure registration
more like tegra's, but still using the typical "component" code.
Drop no-op hooks for atomic_begin and mode_fixup() now that
they're optional.  Drop sentinel in Makefile.  Fix minor style
nits I noticed on another reread.

v3: Use the new bcm2835 clk driver to manage pixel/HSM clocks instead
of having a fixed video mode.  Use exynos-style component driver
matching instead of devicetree nodes to list the component driver
instances.  Rename compatibility strings to say bcm2835, and
distinguish pv0/1/2.  Clean up some h/vsync code, and add in
interlaced mode setup.  Fix up probe/bind error paths.  Use
bitops.h macros for vc4_regs.h

 drivers/gpu/drm/Kconfig   |   2 +
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/vc4/Kconfig   |  13 +
 drivers/gpu/drm/vc4/Makefile  |  17 +
 drivers/gpu/drm/vc4/vc4_bo.c  |  52 +++
 drivers/gpu/drm/vc4/vc4_crtc.c| 675 ++
 drivers/gpu/drm/vc4/vc4_debugfs.c |  39 +++
 drivers/gpu/drm/vc4/vc4_drv.c | 284 
 drivers/gpu/drm/vc4/vc4_drv.h | 115 +++
 drivers/gpu/drm/vc4/vc4_hdmi.c| 588 +
 drivers/gpu/drm/vc4/vc4_hvs.c | 163 +
 drivers/gpu/drm/vc4/vc4_kms.c |  54 +++
 drivers/gpu/drm/vc4/vc4_plane.c   | 320 ++
 drivers/gpu/drm/vc4/vc4_regs.h| 570 
 14 files changed, 2893 insertions(+)
 create mode 100644 drivers/gpu/drm/vc4/Kconfig
 create mode 100644 drivers/gpu/drm/vc4/Makefile
 create mode 100644 drivers/gpu/drm/vc4/vc4_bo.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_crtc.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_debugfs.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_drv.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_drv.h
 create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_hvs.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_kms.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_plane.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_regs.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 1a0a8df..c4bf9a1 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -264,3 +264,5 @@ source "drivers/gpu/drm/sti/Kconfig"
 source "drivers/gpu/drm/amd/amdkfd/Kconfig"
 
 source "drivers/gpu/drm/imx/Kconfig"
+
+source "drivers/gpu/drm/vc4/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 45e7719..0edc9e2 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_DRM_MGA) += mga/
 obj-$(CONFIG_DRM_I810) += i810/
 obj-$(CONFIG_DRM_I915)  += i915/
 obj-$(CONFIG_DRM_MGAG200) += mgag200/
+obj-$(CONFIG_DRM_VC4)  += vc4/
 obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
 obj-$(CONFIG_DRM_SIS)   += sis/
 obj-$(CONFIG_DRM_SAVAGE)+= savage/
diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
new file mode 100644
index 000..e810ef7
--- /dev/null
+++ b/drivers/gpu/drm/vc4/Kconfig
@@ -0,0 +1,13 @@
+config DRM_VC4
+   tristate "Broadcom VC4 Graphics"
+   depends on ARCH_BCM2835
+   depends on DRM
+   select DRM_KMS_HELPER
+   select DRM_KMS_CMA_HELPER
+   help
+ Choose this option if you have a system that has a Broadcom
+ VC4 GPU, such as the Raspberry Pi or other BCM2708/BCM2835.
+
+ This driver requires that "avoid_warnings=2" be present in
+ the config.txt for the firmware, to keep it from smashing
+ our display setup.
diff --git a/drivers/gpu/drm/vc4/Makefile b/drivers/gpu/drm/vc4/Makefile
new file mode 100644
index 000..32b4f9c
--- /dev/null
+++ b/drivers/gpu/drm/vc4/Makefile
@@ -0,0 +1,17 @@
+ccflags-y := -Iinclude/drm
+
+# Please keep these build lists sorted!
+
+# core driver code
+vc4-y := \
+   vc4_bo.o \
+   vc4_crtc.o \
+   vc4_drv.o \
+   vc4_kms.o \
+   vc4_hdmi.o \
+   vc4_hvs.o \
+   vc4_plane.o
+
+vc4-$(CONFIG_DEBUG_FS) += vc4_debugfs.o
+
+obj-$(CONFIG_DRM_VC4)  += vc4.o
diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
new file mode 100644
index 000..ab9f510
--- /dev/null
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -0,0 +1,52 @@
+/*
+ *  Copyright © 2015 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/* DOC: VC4 GEM BO management support.
+ *
+ * The VC4 GPU architecture (both scanout and rendering) has direct
+ * access to system memory with no MMU 

[PATCH v3 7/7] ARM: bcm2835: Add VC4 to the device tree.

[Eric Anholt]

VC4 is the GPU (display and 3D) present on the 2835.

Signed-off-by: Eric Anholt 
---

v2: Sort by register address, mark HDMI as disabled by default in the
SoC file and enable it from -rpi.

v3: Add references to the pixel/HSM clocks for HDMI.  Rename
compatibility strings and clean up node names.

 arch/arm/boot/dts/bcm2835-rpi.dtsi |  4 
 arch/arm/boot/dts/bcm2835.dtsi | 42 ++
 2 files changed, 46 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi 
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index 3572f03..dcaaee2 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -56,6 +56,10 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
status = "okay";
bus-width = <4>;
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index 1e61eb7..21e354a9 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -1,4 +1,5 @@
 #include 
+#include 
 #include 
 #include "skeleton.dtsi"
 
@@ -149,6 +150,18 @@
status = "disabled";
};
 
+   pixelvalve@7e206000 {
+   compatible = "brcm,bcm2835-pixelvalve0";
+   reg = <0x7e206000 0x100>;
+   interrupts = <2 13>; /* pwa2 */
+   };
+
+   pixelvalve@7e207000 {
+   compatible = "brcm,bcm2835-pixelvalve1";
+   reg = <0x7e207000 0x100>;
+   interrupts = <2 14>; /* pwa1 */
+   };
+
sdhci: sdhci@7e30 {
compatible = "brcm,bcm2835-sdhci";
reg = <0x7e30 0x100>;
@@ -157,6 +170,12 @@
status = "disabled";
};
 
+   hvs@7e40 {
+   compatible = "brcm,bcm2835-hvs";
+   reg = <0x7e40 0x6000>;
+   interrupts = <2 1>;
+   };
+
i2c1: i2c@7e804000 {
compatible = "brcm,bcm2835-i2c";
reg = <0x7e804000 0x1000>;
@@ -177,6 +196,25 @@
status = "disabled";
};
 
+   pixelvalve@7e807000 {
+   compatible = "brcm,bcm2835-pixelvalve2";
+   reg = <0x7e807000 0x100>;
+   interrupts = <2 10>; /* pixelvalve */
+   };
+
+   hdmi: hdmi@7e902000 {
+   compatible = "brcm,bcm2835-hdmi";
+   reg = <0x7e902000 0x600>,
+ <0x7e808000 0x100>;
+   interrupts = <2 8>, <2 9>;
+   ddc = <>;
+   hpd-gpio = < 46 GPIO_ACTIVE_HIGH>;
+   clocks = < BCM2835_PLLH_PIX>,
+< BCM2835_CLOCK_HSM>;
+   clock-names = "pixel", "hdmi";
+   status = "disabled";
+   };
+
usb@7e98 {
compatible = "brcm,bcm2835-usb";
reg = <0x7e98 0x1>;
@@ -186,6 +224,10 @@
arm-pmu {
compatible = "arm,arm1176-pmu";
};
+
+   vc4: gpu@7e4c {
+   compatible = "brcm,bcm2835-vc4";
+   };
};
 
clocks {
-- 
2.1.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/

[PATCH v3 5/7] drm/vc4: Allow vblank to be disabled

[Eric Anholt]

From: Derek Foreman 

Signed-off-by: Derek Foreman 
Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_kms.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index ee3e004..2e5597d 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -51,6 +51,7 @@ int vc4_kms_load(struct drm_device *dev)
dev->mode_config.max_height = 2048;
dev->mode_config.funcs = _mode_funcs;
dev->mode_config.preferred_depth = 24;
+   dev->vblank_disable_allowed = true;
 
drm_mode_config_reset(dev);
 
-- 
2.1.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 v2 1/1] i2c: acpi: scan ACPI enumerated I2C mux channels

[Wolfram Sang]

> I'm working on a revision that incorporates Mika's suggested patch I
> think you'll want to wait just a bit for that.

I'll happily do. Thanks!



signature.asc
Description: Digital signature

[PATCH 0/2] Add updated DAX locking to ext2

[Ross Zwisler]

The first patch in this series is a somewhat related bug fix.  The second patch
adds new locking to ext2 to isolate DAX faults (page faults, PMD faults, page
mkwrite and pfn mkwrite) from ext2 operations that modify a given inode's data
block allocations.

In my first attempt at this fix I attempted to expand the protection offered by
ext2_inode_info->truncate_mutex so that we took truncate_mutex before our DAX
fault paths were entered.  The DAX fault handlers would then call a version of
ext2_get_block() that assumed truncate_mutex was already held.

This *almost* works, but it turns out that it introduces a lock ordering
inversion between truncate_mutex and a given page's page_lock.  With my series
as it is, the lock ordering looks like this:

mmap_sem (MM)
  ext2_inode_info->dax_sem
sb_start_pagefault (vfs, freeze - taken in DAX)
  address_space->i_mmap_rwsem or page_lock (mutually exclusive in DAX)
ext2_inode_info->truncate_mutex

With truncate_mutex being taken before the page fault handler, as in my initial
attempt, our lock ordering is instead:

mmap_sem (MM)
  ext2_inode_info->truncate_mutex
sb_start_pagefault (vfs, freeze - taken in DAX)
  address_space->i_mmap_rwsem or page_lock (mutually exclusive in DAX)

This is fine for DAX, but it turns out that you can't actually take
truncate_mutex before a page_lock because some operations call ext2_get_block()
while already holding page_lock from calls higher in the stack.  This means
that whatever locks are taken in ext2_get_block() must be below page_lock in
the locking order, else you can deadlock.  To solve this I had to introduce a
new lock that would sit above page_lock in the locking order.  This is the new
"dax_sem" semaphore.

Folks with ext2 experience, have I missed any other cases that need to be
protected by dax_sem?  I took a hard look at all the cases in XFS that are
protected by i_mmaplock and convinced myself that truncate was the only one of
them present in ext2.

I've tested this series using xfstests with DAX both enabled and disabled.
Lockdep was on and working, and didn't have any complaints.

Ross Zwisler (2):
  dax: dax_pfn_mkwrite() truncate race check
  ext2: Add locking for DAX faults

 fs/dax.c| 13 +++--
 fs/ext2/ext2.h  |  1 +
 fs/ext2/file.c  | 51 +++
 fs/ext2/inode.c |  9 +
 fs/ext2/super.c |  1 +
 5 files changed, 69 insertions(+), 6 deletions(-)

-- 
2.1.0

--
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 2/2] ext2: Add locking for DAX faults

[Ross Zwisler]

Add locking to ensure that DAX faults are isolated from ext2 operations
that modify the data blocks allocation for an inode.  This is intended to
be analogous to the work being done in XFS by Dave Chinner:

http://www.spinics.net/lists/linux-fsdevel/msg90260.html

Compared with XFS the ext2 case is greatly simplified by the fact that ext2
already allocates and zeros new blocks before they are returned as part of
ext2_get_block(), so DAX doesn't need to worry about getting unmapped or
unwritten buffer heads.

This means that the only work we need to do in ext2 is to isolate the DAX
faults from inode block allocation changes.  I believe this just means that
we need to isolate the DAX faults from truncate operations.

The newly introduced dax_sem is intended to replicate the protection
offered by i_mmaplock in XFS.  In addition to truncate the i_mmaplock also
protects XFS operations like hole punching, fallocate down, extent
manipulation IOCTLS like xfs_ioc_space() and extent swapping.  Truncate is
the only one of these operations supported by ext2.

Signed-off-by: Ross Zwisler 
---
 fs/ext2/ext2.h  |  1 +
 fs/ext2/file.c  | 51 +++
 fs/ext2/inode.c |  9 +
 fs/ext2/super.c |  1 +
 4 files changed, 58 insertions(+), 4 deletions(-)

diff --git a/fs/ext2/ext2.h b/fs/ext2/ext2.h
index 8d15feb..ec3cd02 100644
--- a/fs/ext2/ext2.h
+++ b/fs/ext2/ext2.h
@@ -684,6 +684,7 @@ struct ext2_inode_info {
struct rw_semaphore xattr_sem;
 #endif
rwlock_t i_meta_lock;
+   struct rw_semaphore dax_sem;
 
/*
 * truncate_mutex is for serialising ext2_truncate() against
diff --git a/fs/ext2/file.c b/fs/ext2/file.c
index 1982c3f..389c5d5 100644
--- a/fs/ext2/file.c
+++ b/fs/ext2/file.c
@@ -27,27 +27,70 @@
 #include "acl.h"
 
 #ifdef CONFIG_FS_DAX
+/*
+ * The lock ordering for ext2 DAX fault paths is:
+ *
+ * mmap_sem (MM)
+ *   ext2_inode_info->dax_sem
+ * sb_start_pagefault (vfs, freeze - taken in DAX)
+ *   address_space->i_mmap_rwsem or page_lock (mutually exclusive in DAX)
+ * ext2_inode_info->truncate_mutex
+ */
 static int ext2_dax_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
-   return dax_fault(vma, vmf, ext2_get_block, NULL);
+   struct inode *inode = file_inode(vma->vm_file);
+   struct ext2_inode_info *ei = EXT2_I(inode);
+   int ret;
+
+   down_read(>dax_sem);
+   ret = dax_fault(vma, vmf, ext2_get_block, NULL);
+   up_read(>dax_sem);
+   return ret;
 }
 
 static int ext2_dax_pmd_fault(struct vm_area_struct *vma, unsigned long addr,
pmd_t *pmd, unsigned int flags)
 {
-   return dax_pmd_fault(vma, addr, pmd, flags, ext2_get_block, NULL);
+   struct inode *inode = file_inode(vma->vm_file);
+   struct ext2_inode_info *ei = EXT2_I(inode);
+   int ret;
+
+   down_read(>dax_sem);
+   ret = dax_pmd_fault(vma, addr, pmd, flags, ext2_get_block, NULL);
+   up_read(>dax_sem);
+   return ret;
 }
 
 static int ext2_dax_mkwrite(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
-   return dax_mkwrite(vma, vmf, ext2_get_block, NULL);
+   struct inode *inode = file_inode(vma->vm_file);
+   struct ext2_inode_info *ei = EXT2_I(inode);
+   int ret;
+
+   down_read(>dax_sem);
+   ret = dax_mkwrite(vma, vmf, ext2_get_block, NULL);
+   up_read(>dax_sem);
+   return ret;
+}
+
+static int ext2_dax_pfn_mkwrite(struct vm_area_struct *vma,
+   struct vm_fault *vmf)
+{
+   struct inode *inode = file_inode(vma->vm_file);
+   struct ext2_inode_info *ei = EXT2_I(inode);
+   int ret;
+
+   down_read(>dax_sem);
+   ret = dax_pfn_mkwrite(vma, vmf);
+   up_read(>dax_sem);
+   return ret;
 }
 
 static const struct vm_operations_struct ext2_dax_vm_ops = {
.fault  = ext2_dax_fault,
.pmd_fault  = ext2_dax_pmd_fault,
.page_mkwrite   = ext2_dax_mkwrite,
-   .pfn_mkwrite= dax_pfn_mkwrite,
+   .pfn_mkwrite= ext2_dax_pfn_mkwrite,
 };
 
 static int ext2_file_mmap(struct file *file, struct vm_area_struct *vma)
diff --git a/fs/ext2/inode.c b/fs/ext2/inode.c
index c60a248..2b974fc 100644
--- a/fs/ext2/inode.c
+++ b/fs/ext2/inode.c
@@ -1085,6 +1085,7 @@ static void ext2_free_branches(struct inode *inode, 
__le32 *p, __le32 *q, int de
ext2_free_data(inode, p, q);
 }
 
+/* dax_sem must be held when calling this function */
 static void __ext2_truncate_blocks(struct inode *inode, loff_t offset)
 {
__le32 *i_data = EXT2_I(inode)->i_data;
@@ -1170,6 +1171,8 @@ do_indirects:
 
 static void ext2_truncate_blocks(struct inode *inode, loff_t offset)
 {
+   struct ext2_inode_info *ei = EXT2_I(inode);
+
/*
 * XXX: it seems like a bug here that we don't allow
 * IS_APPEND inode to have blocks-past-i_size trimmed off.
@@ -1185,11 +1188,15 @@ static 

[PATCH 1/2] dax: dax_pfn_mkwrite() truncate race check

[Ross Zwisler]

Update dax_pfn_mkwrite() so that it validates i_size before returning.
This is necessary to ensure that the page fault has not raced with truncate
and is now pointing to a region beyond the end of the current file.

This change is based on a similar outstanding patch for XFS from Dave
Chinner entitled "xfs: add ->pfn_mkwrite support for DAX".

Signed-off-by: Ross Zwisler 
---
 fs/dax.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/fs/dax.c b/fs/dax.c
index 131fd35a..82be6e4 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -693,12 +693,21 @@ EXPORT_SYMBOL_GPL(dax_pmd_fault);
  */
 int dax_pfn_mkwrite(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
-   struct super_block *sb = file_inode(vma->vm_file)->i_sb;
+   struct inode *inode = file_inode(vma->vm_file);
+   struct super_block *sb = inode->i_sb;
+   int ret = VM_FAULT_NOPAGE;
+   loff_t size;
 
sb_start_pagefault(sb);
file_update_time(vma->vm_file);
+
+   /* check that the faulting page hasn't raced with truncate */
+   size = (i_size_read(inode) + PAGE_SIZE - 1) >> PAGE_SHIFT;
+   if (vmf->pgoff >= size)
+   ret = VM_FAULT_SIGBUS;
+
sb_end_pagefault(sb);
-   return VM_FAULT_NOPAGE;
+   return ret;
 }
 EXPORT_SYMBOL_GPL(dax_pfn_mkwrite);
 
-- 
2.1.0

--
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 0/2] arm: mvebu: disable unused rtc + cosmetic patch for ReadyNAS devices

[Arnaud Ebalard]

Hi,

Here are two simple patches for Armada-based ReadyNAS devices.

The first one disables Armada 370/XP rtc in the .dts files of ReadyNAS
102, 104 and 2120 devices. Those use an Intersil ISL12057 I2C RTC chip
and do not use the internal Armada RTC. Because it is enabled in
included armada-370-xp.dtsi, it just pollutes logs during boot.

While writing the patches, I noticed RN2120 .dts file has nodes that
are badly ordered under internal-regs. This second patch fixes
that. Note that it depends on first patch. 

Arnaud Ebalard (2):
  arm: mvebu: disable unused Armada RTC on ReadyNAS 102, 104 and 2120
  arm: mvebu: reorder internal-regs nodes by address in RN2120 .dts file

 arch/arm/boot/dts/armada-370-netgear-rn102.dts |  6 ++
 arch/arm/boot/dts/armada-370-netgear-rn104.dts |  6 ++
 arch/arm/boot/dts/armada-xp-netgear-rn2120.dts | 86 ++
 3 files changed, 58 insertions(+), 40 deletions(-)

-- 
2.5.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: [PATCH 2/2] ext2: Add locking for DAX faults

[Dan Williams]

On Fri, Oct 9, 2015 at 3:02 PM, Ross Zwisler
 wrote:
> Add locking to ensure that DAX faults are isolated from ext2 operations
> that modify the data blocks allocation for an inode.  This is intended to
> be analogous to the work being done in XFS by Dave Chinner:
>
> http://www.spinics.net/lists/linux-fsdevel/msg90260.html
>
> Compared with XFS the ext2 case is greatly simplified by the fact that ext2
> already allocates and zeros new blocks before they are returned as part of
> ext2_get_block(), so DAX doesn't need to worry about getting unmapped or
> unwritten buffer heads.
>
> This means that the only work we need to do in ext2 is to isolate the DAX
> faults from inode block allocation changes.  I believe this just means that
> we need to isolate the DAX faults from truncate operations.
>
> The newly introduced dax_sem is intended to replicate the protection
> offered by i_mmaplock in XFS.  In addition to truncate the i_mmaplock also
> protects XFS operations like hole punching, fallocate down, extent
> manipulation IOCTLS like xfs_ioc_space() and extent swapping.  Truncate is
> the only one of these operations supported by ext2.
>
> Signed-off-by: Ross Zwisler 
[..]

...not a review of the ext2 changes.

> diff --git a/fs/ext2/inode.c b/fs/ext2/inode.c
> index c60a248..2b974fc 100644
> --- a/fs/ext2/inode.c
> +++ b/fs/ext2/inode.c
> @@ -1085,6 +1085,7 @@ static void ext2_free_branches(struct inode *inode, 
> __le32 *p, __le32 *q, int de
> ext2_free_data(inode, p, q);
>  }
>
> +/* dax_sem must be held when calling this function */
>  static void __ext2_truncate_blocks(struct inode *inode, loff_t offset)
>  {

How about  a "WARN_ON(!rwsem_is_locked(>dax_sem));" to backstop
this assumption?
--
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] Smack: fix a NULL dereference in wrong smack_import_entry() usage

[Casey Schaufler]

On 8/25/2015 3:39 AM, Lukasz Pawelczyk wrote:
> The e774ad683f425a51f87711164ea166d9dcc41477 commit made this function
> return proper error codes instead of NULL. Reflect that.
>
> This is a fix for a NULL dereference introduced in
> 21abb1ec414c75abe32c3854848ff30e2b4a6113:
>
> echo "$SOME_IPV6_ADDR \"test" > /smack/ipv6host
>   (this should return EINVAL, it doesn't)
> cat /smack/ipv6host
>   (derefences 0x000a)
>
> Signed-off-by: Lukasz Pawelczyk 

Acked-by: Casey Schaufler 
Applied to https://github.com/cschaufler/smack-next.git#smack-for-4.4

> ---
>  security/smack/smackfs.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/security/smack/smackfs.c b/security/smack/smackfs.c
> index c20b154..103a619 100644
> --- a/security/smack/smackfs.c
> +++ b/security/smack/smackfs.c
> @@ -1501,8 +1501,8 @@ static ssize_t smk_write_net6addr(struct file *file, 
> const char __user *buf,
>*/
>   if (smack[0] != '-') {
>   skp = smk_import_entry(smack, 0);
> - if (skp == NULL) {
> - rc = -EINVAL;
> + if (IS_ERR(skp)) {
> + rc = PTR_ERR(skp);
>   goto free_out;
>   }
>   } else {

--
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: arm/arm64: GICv2 driver does not have irq_disable implemented

[Duc Dang]

On Fri, Oct 9, 2015 at 2:52 PM, Thomas Gleixner  wrote:
> On Fri, 9 Oct 2015, Duc Dang wrote:
>> On Fri, Oct 9, 2015 at 10:52 AM, Thomas Gleixner  wrote:
>> > On Fri, 9 Oct 2015, Duc Dang wrote:
>> >> In APM ARM64 X-Gene Enet controller driver, we use disable_irq_nosync to
>> >> disable interrupt before calling __napi_schedule to schedule packet 
>> >> handler
>> >> to process the Tx/Rx packets.
>> >
>> > Which is wrong to begin with. Disable the interrupt at the device
>> > level not at the interrupt line level.
>> >
>> We could not disable the interrupt at Enet controller level due to the
>> controller limitation. As you said, using  disable_irq_nosync is wrong
>> but it looks like that the only option that we have.
>
> Oh well.
>
>> Do you have any suggestion about different approach that we could try?
>
> Try the patch below and add
>
> irq_set_status_flags(irq, IRQ_DISABLE_UNLAZY);
>
> to your driver before requesting the interrupt. Unset it when freeing
> the interrupt.

Thanks, Thomas!

We will try and let you know soon.

>
> Thanks,
>
> tglx
>
> 8<--
>
> Subject: genirq: Add flag to force mask in disable_irq[_nosync]()
> From: Thomas Gleixner 
> Date: Fri, 09 Oct 2015 23:28:58 +0200
>
> If an irq chip does not implement the irq_disable callback, then we
> use a lazy approach for disabling the interrupt. That means that the
> interrupt is marked disabled, but the interrupt line is not
> immediately masked in the interrupt chip. It only becomes masked if
> the interrupt is raised while it's marked disabled. We use this to avoid
> possibly expensive mask/unmask operations for common case operations.
>
> Unfortunately there are devices which do not allow the interrupt to be
> disabled easily at the device level. They are forced to use
> disable_irq_nosync(). This can result in taking each interrupt twice.
>
> Instead of enforcing the non lazy mode on all interrupts of a irq
> chip, provide a settings flag, which can be set by the driver for that
> particular interrupt line.
>
> Signed-off-by: Thomas Gleixner 
> ---
>  include/linux/irq.h   |4 +++-
>  kernel/irq/chip.c |9 +
>  kernel/irq/settings.h |7 +++
>  3 files changed, 19 insertions(+), 1 deletion(-)
>
> Index: tip/include/linux/irq.h
> ===
> --- tip.orig/include/linux/irq.h
> +++ tip/include/linux/irq.h
> @@ -72,6 +72,7 @@ enum irqchip_irq_state;
>   * IRQ_IS_POLLED   - Always polled by another interrupt. Exclude
>   *   it from the spurious interrupt detection
>   *   mechanism and from core side polling.
> + * IRQ_DISABLE_UNLAZY  - Disable lazy irq disable
>   */
>  enum {
> IRQ_TYPE_NONE   = 0x,
> @@ -97,13 +98,14 @@ enum {
> IRQ_NOTHREAD= (1 << 16),
> IRQ_PER_CPU_DEVID   = (1 << 17),
> IRQ_IS_POLLED   = (1 << 18),
> +   IRQ_DISABLE_UNLAZY  = (1 << 19),
>  };
>
>  #define IRQF_MODIFY_MASK   \
> (IRQ_TYPE_SENSE_MASK | IRQ_NOPROBE | IRQ_NOREQUEST | \
>  IRQ_NOAUTOEN | IRQ_MOVE_PCNTXT | IRQ_LEVEL | IRQ_NO_BALANCING | \
>  IRQ_PER_CPU | IRQ_NESTED_THREAD | IRQ_NOTHREAD | IRQ_PER_CPU_DEVID | 
> \
> -IRQ_IS_POLLED)
> +IRQ_IS_POLLED | IRQ_DISABLE_UNLAZY)
>
>  #define IRQ_NO_BALANCING_MASK  (IRQ_PER_CPU | IRQ_NO_BALANCING)
>
> Index: tip/kernel/irq/chip.c
> ===
> --- tip.orig/kernel/irq/chip.c
> +++ tip/kernel/irq/chip.c
> @@ -241,6 +241,13 @@ void irq_enable(struct irq_desc *desc)
>   * disabled. If an interrupt happens, then the interrupt flow
>   * handler masks the line at the hardware level and marks it
>   * pending.
> + *
> + * If the interrupt chip does not implement the irq_disable callback,
> + * a driver can disable the lazy approach for a particular irq line by
> + * calling 'irq_set_status_flags(irq, IRQ_DISABLE_UNLAZY)'. This can be
> + * used for devices which cannot disable the interrupt at the device
> + * level under certain circumstances and have to use
> + * disable_irq[_nosync] instead.
>   */
>  void irq_disable(struct irq_desc *desc)
>  {
> @@ -248,6 +255,8 @@ void irq_disable(struct irq_desc *desc)
> if (desc->irq_data.chip->irq_disable) {
> desc->irq_data.chip->irq_disable(>irq_data);
> irq_state_set_masked(desc);
> +   } else if (irq_settings_disable_unlazy(desc)) {
> +   mask_irq(desc);
> }
>  }
>
> Index: tip/kernel/irq/settings.h
> ===
> --- tip.orig/kernel/irq/settings.h
> +++ tip/kernel/irq/settings.h
> @@ -15,6 +15,7 @@ enum {
> _IRQ_NESTED_THREAD  = IRQ_NESTED_THREAD,
> _IRQ_PER_CPU_DEVID  = IRQ_PER_CPU_DEVID,
>   

[PATCH 07/20] x86: switch from ioremap_cache to memremap

[Dan Williams]

In preparation for deprecating ioremap_cache() convert its usage in
arch/x86/ to memremap.

Cc: Thomas Gleixner 
Cc: H. Peter Anvin 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Signed-off-by: Dan Williams 
---
 arch/x86/include/asm/efi.h  |3 ++-
 arch/x86/kernel/crash_dump_64.c |6 +++---
 arch/x86/kernel/kdebugfs.c  |8 
 arch/x86/kernel/ksysfs.c|   28 ++--
 arch/x86/mm/ioremap.c   |   10 --
 5 files changed, 27 insertions(+), 28 deletions(-)

diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index ae68be92f755..322dde9e0c3c 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -54,7 +54,8 @@ extern unsigned long asmlinkage efi_call_phys(void *, ...);
kernel_fpu_end();   \
 })
 
-#define efi_ioremap(addr, size, type, attr)ioremap_cache(addr, size)
+#define efi_ioremap(addr, size, type, attr)\
+   memremap(addr, size, MEMREMAP_WB)
 
 #else /* !CONFIG_X86_32 */
 
diff --git a/arch/x86/kernel/crash_dump_64.c b/arch/x86/kernel/crash_dump_64.c
index afa64adb75ee..941609ab9aa9 100644
--- a/arch/x86/kernel/crash_dump_64.c
+++ b/arch/x86/kernel/crash_dump_64.c
@@ -31,19 +31,19 @@ ssize_t copy_oldmem_page(unsigned long pfn, char *buf,
if (!csize)
return 0;
 
-   vaddr = ioremap_cache(pfn << PAGE_SHIFT, PAGE_SIZE);
+   vaddr = memremap(pfn << PAGE_SHIFT, PAGE_SIZE, MEMREMAP_WB);
if (!vaddr)
return -ENOMEM;
 
if (userbuf) {
if (copy_to_user(buf, vaddr + offset, csize)) {
-   iounmap(vaddr);
+   memunmap(vaddr);
return -EFAULT;
}
} else
memcpy(buf, vaddr + offset, csize);
 
set_iounmap_nonlazy();
-   iounmap(vaddr);
+   memunmap(vaddr);
return csize;
 }
diff --git a/arch/x86/kernel/kdebugfs.c b/arch/x86/kernel/kdebugfs.c
index dc1404bf8e4b..fa30f85b4333 100644
--- a/arch/x86/kernel/kdebugfs.c
+++ b/arch/x86/kernel/kdebugfs.c
@@ -49,7 +49,7 @@ static ssize_t setup_data_read(struct file *file, char __user 
*user_buf,
pa = node->paddr + sizeof(struct setup_data) + pos;
pg = pfn_to_page((pa + count - 1) >> PAGE_SHIFT);
if (PageHighMem(pg)) {
-   p = ioremap_cache(pa, count);
+   p = memremap(pa, count, MEMREMAP_WB);
if (!p)
return -ENXIO;
} else
@@ -58,7 +58,7 @@ static ssize_t setup_data_read(struct file *file, char __user 
*user_buf,
remain = copy_to_user(user_buf, p, count);
 
if (PageHighMem(pg))
-   iounmap(p);
+   memunmap(p);
 
if (remain)
return -EFAULT;
@@ -128,7 +128,7 @@ static int __init create_setup_data_nodes(struct dentry 
*parent)
 
pg = pfn_to_page((pa_data+sizeof(*data)-1) >> PAGE_SHIFT);
if (PageHighMem(pg)) {
-   data = ioremap_cache(pa_data, sizeof(*data));
+   data = memremap(pa_data, sizeof(*data), MEMREMAP_WB);
if (!data) {
kfree(node);
error = -ENXIO;
@@ -144,7 +144,7 @@ static int __init create_setup_data_nodes(struct dentry 
*parent)
pa_data = data->next;
 
if (PageHighMem(pg))
-   iounmap(data);
+   memunmap(data);
if (error)
goto err_dir;
no++;
diff --git a/arch/x86/kernel/ksysfs.c b/arch/x86/kernel/ksysfs.c
index c2bedaea11f7..2d6ae3baafb8 100644
--- a/arch/x86/kernel/ksysfs.c
+++ b/arch/x86/kernel/ksysfs.c
@@ -16,8 +16,8 @@
 #include 
 #include 
 #include 
+#include 
 
-#include 
 #include 
 
 static ssize_t version_show(struct kobject *kobj,
@@ -79,12 +79,12 @@ static int get_setup_data_paddr(int nr, u64 *paddr)
*paddr = pa_data;
return 0;
}
-   data = ioremap_cache(pa_data, sizeof(*data));
+   data = memremap(pa_data, sizeof(*data), MEMREMAP_WB);
if (!data)
return -ENOMEM;
 
pa_data = data->next;
-   iounmap(data);
+   memunmap(data);
i++;
}
return -EINVAL;
@@ -97,17 +97,17 @@ static int __init get_setup_data_size(int nr, size_t *size)
u64 pa_data = boot_params.hdr.setup_data;
 
while (pa_data) {
-   data = ioremap_cache(pa_data, sizeof(*data));
+   data = memremap(pa_data, sizeof(*data), MEMREMAP_WB);
if (!data)
return -ENOMEM;
if (nr == i) {

[PATCH 12/20] memconsole: fix __iomem mishandling, switch to memremap

[Dan Williams]

The memconsole driver is not using proper accessors for __iomem.  Switch
to memremap to fix this issue, and this also prepares the driver for the
removal of ioremap_cache.

Cc: Mike Waychison 
Signed-off-by: Dan Williams 
---
 drivers/firmware/google/memconsole.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/firmware/google/memconsole.c 
b/drivers/firmware/google/memconsole.c
index 2f569aaed4c7..fd5041716860 100644
--- a/drivers/firmware/google/memconsole.c
+++ b/drivers/firmware/google/memconsole.c
@@ -52,14 +52,15 @@ static ssize_t memconsole_read(struct file *filp, struct 
kobject *kobp,
char *memconsole;
ssize_t ret;
 
-   memconsole = ioremap_cache(memconsole_baseaddr, memconsole_length);
+   memconsole = memremap(memconsole_baseaddr, memconsole_length,
+   MEMREMAP_WB);
if (!memconsole) {
-   pr_err("memconsole: ioremap_cache failed\n");
+   pr_err("memconsole: memremap failed\n");
return -ENOMEM;
}
ret = memory_read_from_buffer(buf, count, , memconsole,
  memconsole_length);
-   iounmap(memconsole);
+   memunmap(memconsole);
return ret;
 }
 

--
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 10/20] acpi: switch from ioremap_cache to memremap

[Dan Williams]

In preparation for deprecating ioremap_cache() convert its usage in
drivers/acpi and include/acpi/ to memremap.  This includes dropping the
__iomem annotation throughout ACPI since the memremap can be treated as
a normal memory pointer.

Finally, memremap automatically handles requests to map normal memory
pages, so this also drops the calls to "should_use_kmap()".

It seems ARM had a local definition of acpi_os_ioremap() to handle RAM
addresses, but it can be deleted now that memremap() handles this
generically.

Cc: Bob Moore 
Cc: Lv Zheng 
Cc: Russell King 
Acked-by: Rafael J. Wysocki 
Signed-off-by: Dan Williams 
---
 arch/arm64/include/asm/acpi.h |8 -
 drivers/acpi/apei/einj.c  |9 +++--
 drivers/acpi/apei/erst.c  |6 ++--
 drivers/acpi/nvs.c|6 ++--
 drivers/acpi/osl.c|   70 +++--
 include/acpi/acpi_io.h|6 +---
 6 files changed, 32 insertions(+), 73 deletions(-)

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index a24a9b1cc91d..197d02047d00 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -29,14 +29,6 @@
 
 /* Basic configuration for ACPI */
 #ifdef CONFIG_ACPI
-/* ACPI table mapping after acpi_gbl_permanent_mmap is set */
-static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
-   acpi_size size)
-{
-   return memremap(phys, size, MEMREMAP_WB);
-}
-#define acpi_os_ioremap acpi_os_ioremap
-
 typedef u64 phys_cpuid_t;
 #define PHYS_CPUID_INVALID INVALID_HWID
 
diff --git a/drivers/acpi/apei/einj.c b/drivers/acpi/apei/einj.c
index 0431883653be..9f71010f6339 100644
--- a/drivers/acpi/apei/einj.c
+++ b/drivers/acpi/apei/einj.c
@@ -314,7 +314,8 @@ static int __einj_error_trigger(u64 trigger_paddr, u32 type,
sizeof(*trigger_tab) - 1);
goto out;
}
-   trigger_tab = ioremap_cache(trigger_paddr, sizeof(*trigger_tab));
+   trigger_tab = memremap(trigger_paddr, sizeof(*trigger_tab),
+   MEMREMAP_WB);
if (!trigger_tab) {
pr_err(EINJ_PFX "Failed to map trigger table!\n");
goto out_rel_header;
@@ -342,8 +343,8 @@ static int __einj_error_trigger(u64 trigger_paddr, u32 type,
   (unsigned long long)trigger_paddr + table_size - 1);
goto out_rel_header;
}
-   iounmap(trigger_tab);
-   trigger_tab = ioremap_cache(trigger_paddr, table_size);
+   memunmap(trigger_tab);
+   trigger_tab = memremap(trigger_paddr, table_size, MEMREMAP_WB);
if (!trigger_tab) {
pr_err(EINJ_PFX "Failed to map trigger table!\n");
goto out_rel_entry;
@@ -405,7 +406,7 @@ out_rel_header:
release_mem_region(trigger_paddr, sizeof(*trigger_tab));
 out:
if (trigger_tab)
-   iounmap(trigger_tab);
+   memunmap(trigger_tab);
 
return rc;
 }
diff --git a/drivers/acpi/apei/erst.c b/drivers/acpi/apei/erst.c
index 6682c5daf742..4ef62b54fabf 100644
--- a/drivers/acpi/apei/erst.c
+++ b/drivers/acpi/apei/erst.c
@@ -73,7 +73,7 @@ static struct acpi_table_erst *erst_tab;
 static struct erst_erange {
u64 base;
u64 size;
-   void __iomem *vaddr;
+   void *vaddr;
u32 attr;
 } erst_erange;
 
@@ -1181,8 +1181,8 @@ static int __init erst_init(void)
goto err_unmap_reg;
}
rc = -ENOMEM;
-   erst_erange.vaddr = ioremap_cache(erst_erange.base,
- erst_erange.size);
+   erst_erange.vaddr = memremap(erst_erange.base, erst_erange.size,
+   MEMREMAP_WB);
if (!erst_erange.vaddr)
goto err_release_erange;
 
diff --git a/drivers/acpi/nvs.c b/drivers/acpi/nvs.c
index 85287b8fe3aa..e0e15af93b22 100644
--- a/drivers/acpi/nvs.c
+++ b/drivers/acpi/nvs.c
@@ -136,7 +136,7 @@ void suspend_nvs_free(void)
entry->data = NULL;
if (entry->kaddr) {
if (entry->unmap) {
-   iounmap(entry->kaddr);
+   memunmap(entry->kaddr);
entry->unmap = false;
} else {
acpi_os_unmap_iomem(entry->kaddr,
@@ -180,7 +180,7 @@ int suspend_nvs_save(void)
 
entry->kaddr = acpi_os_get_iomem(phys, size);
if (!entry->kaddr) {
-   entry->kaddr = acpi_os_ioremap(phys, size);
+   entry->kaddr = acpi_os_memremap(phys, size);
entry->unmap = !!entry->kaddr;

Re: linux-next: build warning after merge of the driver-core tree

[Rafael J. Wysocki]

On Friday, October 09, 2015 12:01:55 PM Viresh Kumar wrote:
> On 09-10-15, 16:36, Stephen Rothwell wrote:
> > Hi Rafael,
> > 
> > On Thu, 08 Oct 2015 22:30:45 +0200 "Rafael J. Wysocki"  
> > wrote:
> > >
> > > On Thursday, October 08, 2015 12:39:54 PM Viresh Kumar wrote:
> > > > 1840995c52d4 PM / OPP: reuse of_parse_phandle()
> > > > f0489a5ef4d0 PM / OPP: Rename opp init/free table routines
> > > > 8f8d37b2537a PM / OPP: Prefix exported opp routines with dev_pm_opp_
> > > > 33692dc381f9 PM / OPP: Move opp core to its own directory
> > > > f59d3ee8480d PM / OPP: Move cpu specific code to opp/cpu.c
> > > > 5cb5fdbf3877 PM / OPP: Add debugfs support
> > > > 
> > > > I though you just dropped the last commit, but no.
> > > 
> > > My bad, I rebased the pm-opp branch, but then have forgotten to merge it.
> > > 
> > > Sorry about that, should be fixed now.
> > 
> > And the warnings are back :-)
> 
> Rafael did it incorrectly once again :)
> 
> He picked the faulty patch once again, which he should have dropped.

Right, sorry about that.

It should be gone now for real.

Thanks,
Rafael

--
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] x86/apic: Use smaller array for __apicid_to_node[] mapping

[Thomas Gleixner]

On Fri, 9 Oct 2015, Jiang Liu wrote:
> On 2015/10/9 22:15, Thomas Gleixner wrote:
> > On Mon, 5 Oct 2015, Daniel J Blueman wrote:
> >> +struct apicid_to_node {
> >> +  int apicid;
> >> +  s16 node;
> >> +};
> > 
> > Instead of having this array, why don't you use a radix tree and be
> > done with it?
> Hi Thomas,
>   It's in early booting stage and memory allocator isn't ready
> yet.

Why do we need that information so early?

Thanks,

tglx


--
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 1/7] soc: qcom: smd: Introduce callback setter

[Bjorn Andersson]

Introduce a setter for the callback function pointer to clarify the
locking around the operation and to reduce some duplication.

Signed-off-by: Bjorn Andersson 
---

Changes since v1:
- New patch

 drivers/soc/qcom/smd.c   | 25 +
 include/linux/soc/qcom/smd.h |  4 +++-
 2 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c
index 18964f154383..8b401d89b0d0 100644
--- a/drivers/soc/qcom/smd.c
+++ b/drivers/soc/qcom/smd.c
@@ -186,7 +186,7 @@ struct qcom_smd_channel {
int fifo_size;
 
void *bounce_buffer;
-   int (*cb)(struct qcom_smd_device *, const void *, size_t);
+   qcom_smd_cb_t cb;
 
spinlock_t recv_lock;
 
@@ -378,6 +378,19 @@ static void qcom_smd_channel_reset(struct qcom_smd_channel 
*channel)
 }
 
 /*
+ * Set the callback for a channel, with appropriate locking
+ */
+static void qcom_smd_channel_set_callback(struct qcom_smd_channel *channel,
+ qcom_smd_cb_t cb)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(>recv_lock, flags);
+   channel->cb = cb;
+   spin_unlock_irqrestore(>recv_lock, flags);
+};
+
+/*
  * Calculate the amount of data available in the rx fifo
  */
 static size_t qcom_smd_channel_get_rx_avail(struct qcom_smd_channel *channel)
@@ -815,8 +828,7 @@ static int qcom_smd_dev_probe(struct device *dev)
if (!channel->bounce_buffer)
return -ENOMEM;
 
-   channel->cb = qsdrv->callback;
-
+   qcom_smd_channel_set_callback(channel, qsdrv->callback);
qcom_smd_channel_set_state(channel, SMD_CHANNEL_OPENING);
 
qcom_smd_channel_set_state(channel, SMD_CHANNEL_OPENED);
@@ -832,7 +844,7 @@ static int qcom_smd_dev_probe(struct device *dev)
 err:
dev_err(>dev, "probe failed\n");
 
-   channel->cb = NULL;
+   qcom_smd_channel_set_callback(channel, NULL);
kfree(channel->bounce_buffer);
channel->bounce_buffer = NULL;
 
@@ -851,16 +863,13 @@ static int qcom_smd_dev_remove(struct device *dev)
struct qcom_smd_device *qsdev = to_smd_device(dev);
struct qcom_smd_driver *qsdrv = to_smd_driver(dev);
struct qcom_smd_channel *channel = qsdev->channel;
-   unsigned long flags;
 
qcom_smd_channel_set_state(channel, SMD_CHANNEL_CLOSING);
 
/*
 * Make sure we don't race with the code receiving data.
 */
-   spin_lock_irqsave(>recv_lock, flags);
-   channel->cb = NULL;
-   spin_unlock_irqrestore(>recv_lock, flags);
+   qcom_smd_channel_set_callback(channel, NULL);
 
/* Wake up any sleepers in qcom_smd_send() */
wake_up_interruptible(>fblockread_event);
diff --git a/include/linux/soc/qcom/smd.h b/include/linux/soc/qcom/smd.h
index d0cb6d189a0a..65a64fcdb1aa 100644
--- a/include/linux/soc/qcom/smd.h
+++ b/include/linux/soc/qcom/smd.h
@@ -26,6 +26,8 @@ struct qcom_smd_device {
struct qcom_smd_channel *channel;
 };
 
+typedef int (*qcom_smd_cb_t)(struct qcom_smd_device *, const void *, size_t);
+
 /**
  * struct qcom_smd_driver - smd driver struct
  * @driver:underlying device driver
@@ -42,7 +44,7 @@ struct qcom_smd_driver {
 
int (*probe)(struct qcom_smd_device *dev);
void (*remove)(struct qcom_smd_device *dev);
-   int (*callback)(struct qcom_smd_device *, const void *, size_t);
+   qcom_smd_cb_t callback;
 };
 
 int qcom_smd_driver_register(struct qcom_smd_driver *drv);
-- 
2.4.2

--
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: [PULL] GIC changes for Linux 4.4

[Thomas Gleixner]

On Fri, 9 Oct 2015, Marc Zyngier wrote:
> The following changes since commit 049e6dde7e57f0054fdc49102e7ef4830c698b46:
> 
>   Linux 4.3-rc4 (2015-10-04 16:57:17 +0100)

That's not the best base. tip irq/core already has gic modifications
which conflict. Can you please rebase to tip irq/core?

Thanks,

tglx
--
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 00/12] pwm: add support for atomic update

[Boris Brezillon]

Hi Thierry,

On Mon, 21 Sep 2015 11:33:17 +0200
Boris Brezillon  wrote:

> Hello,
> 
> This series adds support for atomic PWM update, or IOW, the capability
> to update all the parameters of a PWM device (enabled/disabled, period,
> duty and polarity) in one go.

Anything preventing this series from being applied (AKA ping)?

> 
> Best Regards,
> 
> Boris
> 
> Changes since v2:
> - rebased on top of 4.3-rc2
> - reintroduced pwm-regulator patches
> 
> Changes since v1:
> - dropped applied patches
> - squashed Heiko's fixes into the rockchip driver changes
> - made a few cosmetic changes
> - added kerneldoc comments
> - added Heiko's patch to display more information in debugfs
> - dropped pwm-regulator patches (should be submitted separately)
> 
> Boris Brezillon (11):
>   pwm: introduce default period and polarity concepts
>   pwm: define a new pwm_state struct
>   pwm: move the enabled/disabled info to pwm_state struct
>   backlight: pwm_bl: remove useless call to pwm_set_period
>   pwm: declare a default PWM state
>   pwm: add the PWM initial state retrieval infra
>   pwm: add the core infrastructure to allow atomic update
>   pwm: rockchip: add initial state retrieval
>   pwm: rockchip: add support for atomic update
>   regulator: pwm: implement ->enable(), ->disable() and ->is_enabled
> methods
>   regulator: pwm: properly initialize the ->state field
> 
> Heiko Stübner (1):
>   pwm: add information about polarity, duty cycle and period to debugfs
> 
>  drivers/leds/leds-pwm.c  |   2 +-
>  drivers/pwm/core.c   | 169 
> +++
>  drivers/pwm/pwm-pxa.c|   2 +-
>  drivers/pwm/pwm-rockchip.c   | 119 +++-
>  drivers/pwm/pwm-sun4i.c  |   3 +-
>  drivers/regulator/pwm-regulator.c|  65 --
>  drivers/video/backlight/lm3630a_bl.c |   4 +-
>  drivers/video/backlight/pwm_bl.c |  10 ++-
>  drivers/video/fbdev/ssd1307fb.c  |   2 +-
>  include/linux/pwm.h  |  89 +++---
>  10 files changed, 392 insertions(+), 73 deletions(-)
> 



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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: [PULL] GIC changes for Linux 4.4

[Marc Zyngier]

On Fri, 9 Oct 2015 22:52:48 +0200
Thomas Gleixner  wrote:

> On Fri, 9 Oct 2015, Marc Zyngier wrote:
> > The following changes since commit 049e6dde7e57f0054fdc49102e7ef4830c698b46:
> > 
> >   Linux 4.3-rc4 (2015-10-04 16:57:17 +0100)
> 
> That's not the best base. tip irq/core already has gic modifications
> which conflict. Can you please rebase to tip irq/core?

Damn, completely forgot about the Cavium stuff. Sorry. I'll rebase and
resend.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.
--
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 7/7] Bluetooth: btqcomsmd: Qualcomm WCNSS HCI driver

[Marcel Holtmann]

Hi Bjorn,

> The Qualcomm WCNSS chip provides two SMD channels to the BT core; one
> for command and one for event packets. This driver exposes the two
> channels as a hci device.
> 
> Signed-off-by: Bjorn Andersson 
> ---
> 
> Changes since v1:
> - With the introduction of qcom_smd_open_channel() the two drivers are now one
> - No more global state
> - Corrected memory management of sk_buffs
> - Reverted to __hci_cmd_sync_ev() for set_bdaddr
> - Renamed the driver to btqcomsmd
> - Split out the addition of HCI_SMD to separate patch
> 
> drivers/bluetooth/Kconfig |  11 +++
> drivers/bluetooth/Makefile|   1 +
> drivers/bluetooth/btqcomsmd.c | 198 ++
> 3 files changed, 210 insertions(+)
> create mode 100644 drivers/bluetooth/btqcomsmd.c
> 
> diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
> index 62999546a301..1652997e59cc 100644
> --- a/drivers/bluetooth/Kconfig
> +++ b/drivers/bluetooth/Kconfig
> @@ -169,6 +169,17 @@ config BT_HCIUART_QCA
> 
> Say Y here to compile support for QCA protocol.
> 
> +config BT_QCOMSMD
> + tristate "Qualcomm SMD based HCI support"
> + depends on QCOM_SMD
> + help
> +   Qualcomm SMD based HCI driver.
> +   This driver is used to bridge HCI data onto the shared memory
> +   channels to the WCNSS core.
> +
> +   Say Y here to compile support for HCI over Qualcomm SMD into the
> +   kernelor say M to compile as a module.
> +
> config BT_HCIBCM203X
>   tristate "HCI BCM203x USB driver"
>   depends on USB
> diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
> index 07c9cf381e5a..19e313bf8c39 100644
> --- a/drivers/bluetooth/Makefile
> +++ b/drivers/bluetooth/Makefile
> @@ -23,6 +23,7 @@ obj-$(CONFIG_BT_WILINK) += btwilink.o
> obj-$(CONFIG_BT_BCM)  += btbcm.o
> obj-$(CONFIG_BT_RTL)  += btrtl.o
> obj-$(CONFIG_BT_QCA)  += btqca.o
> +obj-$(CONFIG_BT_QCOMSMD) += btqcomsmd.o
> 
> btmrvl-y  := btmrvl_main.o
> btmrvl-$(CONFIG_DEBUG_FS) += btmrvl_debugfs.o
> diff --git a/drivers/bluetooth/btqcomsmd.c b/drivers/bluetooth/btqcomsmd.c
> new file mode 100644
> index ..4b91c830531e
> --- /dev/null
> +++ b/drivers/bluetooth/btqcomsmd.c
> @@ -0,0 +1,198 @@
> +/*
> + * Copyright (c) 2015, Sony Mobile Communications Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define EDL_NVM_ACCESS_SET_REQ_CMD   0x01
> +#define EDL_NVM_ACCESS_OPCODE0xfc0b
> +
> +struct btqcomsmd {
> + struct qcom_smd_channel *acl_channel;
> + struct qcom_smd_channel *cmd_channel;
> +};
> +
> +static int btqcomsmd_recv(struct hci_dev *hdev,
> +   unsigned type,
> +   const void *data,
> +   size_t count)

you are overdoing it here. Place as many parameters in one line as long as they 
are below 80 chars. Only then put them on the next line. One param per line is 
too much.

> +{
> + struct sk_buff *skb;
> + void *buf;
> +
> + /* Use GFP_ATOMIC as we're in IRQ context */
> + skb = bt_skb_alloc(count, GFP_ATOMIC);
> + if (!skb)
> + return -ENOMEM;
> +
> + bt_cb(skb)->pkt_type = type;
> +
> + /* Use io accessor as data might be ioremapped */
> + buf = skb_put(skb, count);
> + memcpy_fromio(buf, data, count);

memcpy_fromio(skb_put(skb, count), data, count);

Avoid the extra buf variable.

> +
> + return hci_recv_frame(hdev, skb);
> +}
> +
> +static int btqcomsmd_acl_callback(struct qcom_smd_device *qsdev,
> +   const void *data,
> +   size_t count)
> +{
> + struct hci_dev *hdev = dev_get_drvdata(>dev);
> +
> + return btqcomsmd_recv(hdev, HCI_ACLDATA_PKT, data, count);
> +}
> +
> +static int btqcomsmd_cmd_callback(struct qcom_smd_device *qsdev,
> +   const void *data,
> +   size_t count)
> +{
> + struct hci_dev *hdev = dev_get_drvdata(>dev);
> +
> + return btqcomsmd_recv(hdev, HCI_EVENT_PKT, data, count);
> +}
> +
> +static int btqcomsmd_send(struct hci_dev *hdev, struct sk_buff *skb)
> +{
> + struct btqcomsmd *btq = hci_get_drvdata(hdev);
> + int ret;
> +
> + switch (bt_cb(skb)->pkt_type) {
> + case HCI_ACLDATA_PKT:
> + case HCI_SCODATA_PKT:
> + ret = 

Re: [RFC v2 1/1] i2c: acpi: scan ACPI enumerated I2C mux channels

[Wolfram Sang]

On Fri, Aug 14, 2015 at 12:31:33PM -0700, Dustin Byford wrote:
> 
> Set an ACPI companion for I2C mux channels enumerated through ACPI and
> ensure they are scanned for devices.
> 
> Signed-off-by: Dustin Byford 

Mika, is this one okay with you?

> ---
>  drivers/i2c/i2c-core.c | 10 ++
>  drivers/i2c/i2c-mux.c  |  8 
>  2 files changed, 18 insertions(+)
> 
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index c83e4d1..23cc8e9 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -171,8 +171,18 @@ static void acpi_i2c_register_devices(struct i2c_adapter 
> *adap)
>   if (!adap->dev.parent)
>   return;
>  
> + /*
> +  * Determine where to start walking the ACPI namespace.  The common
> +  * case is to start at the adapter's parent device.  However, in
> +  * the case of a "virtual" I2C adapter created to represent a mux
> +  * channel the parent dev (pointing to the mux device) does not
> +  * have an ACPI handle.  Walk starting at the adapter instead.
> +  */
>   handle = ACPI_HANDLE(adap->dev.parent);
>   if (!handle)
> + handle = ACPI_HANDLE(>dev);
> +
> + if (!handle)
>   return;
>  
>   status = acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, 1,
> diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
> index 2ba7c0f..2731b99 100644
> --- a/drivers/i2c/i2c-mux.c
> +++ b/drivers/i2c/i2c-mux.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /* multiplexer per channel data */
>  struct i2c_mux_priv {
> @@ -173,6 +174,13 @@ struct i2c_adapter *i2c_add_mux_adapter(struct 
> i2c_adapter *parent,
>   }
>   }
>  
> + /*
> +  * Now try to populate the mux adapter's ACPI node.
> +  */
> + if (has_acpi_companion(mux_dev))
> + acpi_preset_companion(>adap.dev, ACPI_COMPANION(mux_dev),
> +   chan_id);
> +
>   if (force_nr) {
>   priv->adap.nr = force_nr;
>   ret = i2c_add_numbered_adapter(>adap);
> -- 
> 2.1.4
> 


signature.asc
Description: Digital signature

Re: [PATCH 2/2] smack: smk_ipv6_port_list should be static

[Casey Schaufler]

On 9/27/2015 8:10 AM, Geliang Tang wrote:
> Fixes the following sparse warning:
>
>  security/smack/smack_lsm.c:55:1: warning: symbol 'smk_ipv6_port_list'
>  was not declared. Should it be static?
>
> Signed-off-by: Geliang Tang 

Acked-by: Casey Schaufler 
Applied to https://github.com/cschaufler/smack-next.git#smack-for-4.4

> ---
>  security/smack/smack_lsm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index 996c889..f02438c 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -52,7 +52,7 @@
>  #define SMK_SENDING  2
>  
>  #ifdef SMACK_IPV6_PORT_LABELING
> -LIST_HEAD(smk_ipv6_port_list);
> +static LIST_HEAD(smk_ipv6_port_list);
>  #endif
>  static struct kmem_cache *smack_inode_cache;
>  int smack_enabled;

--
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/2] arm: mvebu: disable unused Armada RTC on ReadyNAS 102, 104 and 2120

[Arnaud Ebalard]

By default, armada-370-xp.dtsi file has internal RTC enabled.
NETGEAR ReadyNAS 102, 104 and 2120 all use an Intersil ISL12057
I2C RTC chip. The internal RTC not being disabled in the .dts
files of those devices result in the following useless first
line during boot:

[4.500056] rtc-mv d0010300.rtc: internal RTC not ticking
[4.505684] i2c /dev entries driver
[4.513246] rtc-isl12057 0-0068: rtc core: registered rtc-isl12057 as rtc0

This patch marks Armada internal RTC as disabled in individual .dts
files of those devices.

Reported-by: TuxOholic 
Signed-off-by: Arnaud Ebalard 
---
 arch/arm/boot/dts/armada-370-netgear-rn102.dts | 6 ++
 arch/arm/boot/dts/armada-370-netgear-rn104.dts | 6 ++
 arch/arm/boot/dts/armada-xp-netgear-rn2120.dts | 6 ++
 3 files changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/armada-370-netgear-rn102.dts 
b/arch/arm/boot/dts/armada-370-netgear-rn102.dts
index a31207860f34..5851964196bd 100644
--- a/arch/arm/boot/dts/armada-370-netgear-rn102.dts
+++ b/arch/arm/boot/dts/armada-370-netgear-rn102.dts
@@ -82,6 +82,12 @@
};
 
internal-regs {
+
+   /* RTC is provided by Intersil ISL12057 I2C RTC chip */
+   rtc@10300 {
+   status = "disabled";
+   };
+
serial@12000 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/armada-370-netgear-rn104.dts 
b/arch/arm/boot/dts/armada-370-netgear-rn104.dts
index 00540f292979..b0b07ba677b9 100644
--- a/arch/arm/boot/dts/armada-370-netgear-rn104.dts
+++ b/arch/arm/boot/dts/armada-370-netgear-rn104.dts
@@ -82,6 +82,12 @@
};
 
internal-regs {
+
+   /* RTC is provided by Intersil ISL12057 I2C RTC chip */
+   rtc@10300 {
+   status = "disabled";
+   };
+
serial@12000 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts 
b/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
index 1516fc2627f9..85b2f87c0b8a 100644
--- a/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
+++ b/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
@@ -88,6 +88,12 @@
};
 
internal-regs {
+
+   /* RTC is provided by Intersil ISL12057 I2C RTC chip */
+   rtc@10300 {
+   status = "disabled";
+   };
+
/* Two rear eSATA ports */
sata@a {
nr-ports = <2>;
-- 
2.5.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 2/2] arm: mvebu: reorder nodes under internal-regs by address in RN2120 .dts file

[Arnaud Ebalard]

This cosmetic patch reorder nodes under internal-regs by increasing
address order, as epxected.

Signed-off-by: Arnaud Ebalard 
---
 arch/arm/boot/dts/armada-xp-netgear-rn2120.dts | 86 +-
 1 file changed, 43 insertions(+), 43 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts 
b/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
index 85b2f87c0b8a..d72a69d97ba2 100644
--- a/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
+++ b/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
@@ -94,54 +94,11 @@
status = "disabled";
};
 
-   /* Two rear eSATA ports */
-   sata@a {
-   nr-ports = <2>;
-   status = "okay";
-   };
-
-   serial@12000 {
-   status = "okay";
-   };
-
-   mdio {
-   phy0: ethernet-phy@0 { /* Marvell 88E1318 */
-   reg = <0>;
-   };
-
-   phy1: ethernet-phy@1 { /* Marvell 88E1318 */
-   reg = <1>;
-   };
-   };
-
-   ethernet@7 {
-   status = "okay";
-   phy = <>;
-   phy-mode = "rgmii-id";
-   };
-
-   ethernet@74000 {
-   status = "okay";
-   phy = <>;
-   phy-mode = "rgmii-id";
-   };
-
-   /* Front USB 2.0 port */
-   usb@5 {
-   status = "okay";
-   };
-
i2c@11000 {
compatible = "marvell,mv64xxx-i2c";
clock-frequency = <40>;
status = "okay";
 
-   isl12057: isl12057@68 {
-   compatible = "isil,isl12057";
-   reg = <0x68>;
-   isil,irq2-can-wakeup-machine;
-   };
-
/* Controller for rear fan #1 of 3 (Protechnic
 * MGT4012XB-O20, 8000RPM) near eSATA port */
g762_fan1: g762@3e {
@@ -178,6 +135,49 @@
compatible = "gmt,g751";
reg = <0x4c>;
};
+
+   isl12057: isl12057@68 {
+   compatible = "isil,isl12057";
+   reg = <0x68>;
+   isil,irq2-can-wakeup-machine;
+   };
+   };
+
+   serial@12000 {
+   status = "okay";
+   };
+
+   /* Front USB 2.0 port */
+   usb@5 {
+   status = "okay";
+   };
+
+   mdio {
+   phy0: ethernet-phy@0 { /* Marvell 88E1318 */
+   reg = <0>;
+   };
+
+   phy1: ethernet-phy@1 { /* Marvell 88E1318 */
+   reg = <1>;
+   };
+   };
+
+   ethernet@7 {
+   status = "okay";
+   phy = <>;
+   phy-mode = "rgmii-id";
+   };
+
+   ethernet@74000 {
+   status = "okay";
+   phy = <>;
+   phy-mode = "rgmii-id";
+   };
+
+   /* Two rear eSATA ports */
+   sata@a {
+   nr-ports = <2>;
+   status = "okay";
};
 
nand@d {
-- 
2.5.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] staging: r8188eu: Add _enter_critical_mutex() error handling

[Alexey Khoroshilov]

_enter_critical_mutex() is a simple call to mutex_lock_interruptible(),
but there is no error handling code for it.

The patch removes wrapper _enter_critical_mutex() and
adds error handling for mutex_lock_interruptible().

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
---
 drivers/staging/rtl8188eu/core/rtw_mlme_ext.c | 5 +++--
 drivers/staging/rtl8188eu/include/osdep_service.h | 9 -
 drivers/staging/rtl8188eu/os_dep/os_intfs.c   | 3 ++-
 drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c  | 5 -
 4 files changed, 9 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
index 935b48eef8b1..4e9312f0e902 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
@@ -271,7 +271,8 @@ static s32 dump_mgntframe_and_wait_ack(struct adapter 
*padapter,
if (padapter->bSurpriseRemoved || padapter->bDriverStopped)
return -1;
 
-   _enter_critical_mutex(>ack_tx_mutex, NULL);
+   if (!mutex_lock_interruptible(>ack_tx_mutex))
+   return _FAIL;
pxmitpriv->ack_tx = true;
 
pmgntframe->ack_report = 1;
@@ -282,7 +283,7 @@ static s32 dump_mgntframe_and_wait_ack(struct adapter 
*padapter,
pxmitpriv->ack_tx = false;
mutex_unlock(>ack_tx_mutex);
 
-return ret;
+   return ret;
 }
 
 static int update_hidden_ssid(u8 *ies, u32 ies_len, u8 hidden_ssid_mode)
diff --git a/drivers/staging/rtl8188eu/include/osdep_service.h 
b/drivers/staging/rtl8188eu/include/osdep_service.h
index cf9ca685eb77..96505a6dbe2c 100644
--- a/drivers/staging/rtl8188eu/include/osdep_service.h
+++ b/drivers/staging/rtl8188eu/include/osdep_service.h
@@ -67,15 +67,6 @@ static inline struct list_head *get_list_head(struct __queue 
*queue)
return &(queue->queue);
 }
 
-static inline int _enter_critical_mutex(struct mutex *pmutex,
-   unsigned long *pirqL)
-{
-   int ret;
-
-   ret = mutex_lock_interruptible(pmutex);
-   return ret;
-}
-
 static inline int rtw_netif_queue_stopped(struct net_device *pnetdev)
 {
return  netif_tx_queue_stopped(netdev_get_tx_queue(pnetdev, 0)) &&
diff --git a/drivers/staging/rtl8188eu/os_dep/os_intfs.c 
b/drivers/staging/rtl8188eu/os_dep/os_intfs.c
index 2361bce480c3..9a3425a7110d 100644
--- a/drivers/staging/rtl8188eu/os_dep/os_intfs.c
+++ b/drivers/staging/rtl8188eu/os_dep/os_intfs.c
@@ -1053,7 +1053,8 @@ static int netdev_open(struct net_device *pnetdev)
int ret;
struct adapter *padapter = (struct adapter *)rtw_netdev_priv(pnetdev);
 
-   _enter_critical_mutex(>hw_init_mutex, NULL);
+   if (mutex_lock_interruptible(>hw_init_mutex))
+   return -ERESTARTSYS;
ret = _netdev_open(pnetdev);
mutex_unlock(>hw_init_mutex);
return ret;
diff --git a/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c 
b/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
index 7e599bc5b2d3..0fea338d7313 100644
--- a/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
@@ -249,7 +249,10 @@ static int usbctrl_vendorreq(struct adapter *adapt, u8 
request, u16 value, u16 i
goto exit;
}
 
-   _enter_critical_mutex(>usb_vendor_req_mutex, NULL);
+   if (mutex_lock_interruptible(>usb_vendor_req_mutex)) {
+   status = -ERESTARTSYS;
+   goto exit;
+   }
 
/*  Acquire IO memory for vendorreq */
pIo_buf = dvobjpriv->usb_vendor_req_buf;
-- 
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/

[PATCH v9] gpio: Add GPIO support for the ACCES 104-IDIO-16

[William Breathitt Gray]

The ACCES 104-IDIO-16 family of PC/104 utility boards feature 16
optically isolated inputs and 16 optically isolated FET solid state
outputs. This driver provides GPIO support for these 32 channels of
digital I/O. Change-of-State detection interrupts are not supported.

GPIO 0-15 correspond to digital outputs 0-15, while GPIO 16-31
correspond to digital inputs 0-15. The base port address for the device
may be set via the a_104_idio_16_base module parameter.

Signed-off-by: William Breathitt Gray 
---
Changes in v9:
  - Initialize GPIO device private data structure to 0 to prevent
garbage data pollution

 drivers/gpio/Kconfig|  10 ++
 drivers/gpio/Makefile   |   1 +
 drivers/gpio/gpio-104-idio-16.c | 219 
 3 files changed, 230 insertions(+)
 create mode 100644 drivers/gpio/gpio-104-idio-16.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 8949b3f..dc843e0 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -684,6 +684,16 @@ config GPIO_SX150X
 
 endmenu
 
+menu "ISA GPIO drivers"
+
+config GPIO_104_IDIO_16
+   tristate "ACCES 104-IDIO-16 GPIO support"
+   depends on X86
+   help
+ Enables GPIO support for the ACCES 104-IDIO-16 family.
+
+endmenu
+
 menu "MFD GPIO expanders"
 
 config GPIO_ADP5520
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index f79a7c4..6f2fea5 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_GPIO_ACPI)   += gpiolib-acpi.o
 # Device drivers. Generally keep list sorted alphabetically
 obj-$(CONFIG_GPIO_GENERIC) += gpio-generic.o
 
+obj-$(CONFIG_GPIO_104_IDIO_16) += gpio-104-idio-16.o
 obj-$(CONFIG_GPIO_74X164)  += gpio-74x164.o
 obj-$(CONFIG_GPIO_74XX_MMIO)   += gpio-74xx-mmio.o
 obj-$(CONFIG_GPIO_ADNP)+= gpio-adnp.o
diff --git a/drivers/gpio/gpio-104-idio-16.c b/drivers/gpio/gpio-104-idio-16.c
new file mode 100644
index 000..a85ae05
--- /dev/null
+++ b/drivers/gpio/gpio-104-idio-16.c
@@ -0,0 +1,219 @@
+/*
+ * GPIO driver for the ACCES 104-IDIO-16 family
+ * Copyright (C) 2015 William Breathitt Gray
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static unsigned a_104_idio_16_base;
+module_param(a_104_idio_16_base, uint, 0);
+MODULE_PARM_DESC(a_104_idio_16_base, "ACCES 104-IDIO-16 base address");
+
+/**
+ * struct a_104_idio_16_gpio - GPIO device private data structure
+ * @chip:  instance of the gpio_chip
+ * @lock:  synchronization lock to prevent gpio_set race conditions
+ * @base:  base port address of the GPIO device
+ * @extent:extent of port address region of the GPIO device
+ * @out_state: output bits state
+ */
+struct a_104_idio_16_gpio {
+   struct gpio_chip chip;
+   spinlock_t lock;
+   unsigned base;
+   unsigned extent;
+   unsigned out_state;
+};
+
+static int a_104_idio_16_gpio_get_direction(struct gpio_chip *chip,
+   unsigned offset)
+{
+   if (offset > 15)
+   return 1;
+
+   return 0;
+}
+
+static int a_104_idio_16_gpio_direction_input(struct gpio_chip *chip,
+   unsigned offset)
+{
+   return 0;
+}
+
+static int a_104_idio_16_gpio_direction_output(struct gpio_chip *chip,
+   unsigned offset, int value)
+{
+   chip->set(chip, offset, value);
+   return 0;
+}
+
+static struct a_104_idio_16_gpio *to_a104idio16gp(struct gpio_chip *gc)
+{
+   return container_of(gc, struct a_104_idio_16_gpio, chip);
+}
+
+static int a_104_idio_16_gpio_get(struct gpio_chip *chip, unsigned offset)
+{
+   struct a_104_idio_16_gpio *const a104idio16gp = to_a104idio16gp(chip);
+   const unsigned BIT_MASK = 1U << (offset-16);
+
+   if (offset < 16)
+   return -EINVAL;
+
+   if (offset < 24)
+   return !!(inb(a104idio16gp->base + 1) & BIT_MASK);
+
+   return !!(inb(a104idio16gp->base + 5) & (BIT_MASK>>8));
+}
+
+static void a_104_idio_16_gpio_set(struct gpio_chip *chip, unsigned offset,
+   int value)
+{
+   struct a_104_idio_16_gpio *const a104idio16gp = to_a104idio16gp(chip);
+   const unsigned BIT_MASK = 1U << offset;
+   unsigned long flags;
+
+   if (offset > 15)
+   return;
+
+   spin_lock_irqsave(>lock, flags);
+
+   if (value)
+   a104idio16gp->out_state |= BIT_MASK;
+   else
+   a104idio16gp->out_state &= ~BIT_MASK;
+
+   if (offset > 7)
+ 

[PATCH] f2fs: set GFP_NOFS for grab_cache_page

[Jaegeuk Kim]

For normal inodes, their pages are allocated with __GFP_FS, which can cause
filesystem calls when reclaiming memory.
This can incur a dead lock condition accordingly.

So, this patch addresses this problem by introducing
f2fs_grab_cache_page(.., bool for_write), which calls
grab_cache_page_write_begin() with AOP_FLAG_NOFS.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/data.c | 16 +---
 fs/f2fs/dir.c  |  6 +++---
 fs/f2fs/f2fs.h | 12 ++--
 fs/f2fs/file.c |  6 +++---
 fs/f2fs/gc.c   |  6 +++---
 5 files changed, 28 insertions(+), 18 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index bc04e92..d4f1c74 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -275,7 +275,8 @@ int f2fs_get_block(struct dnode_of_data *dn, pgoff_t index)
return f2fs_reserve_block(dn, index);
 }
 
-struct page *get_read_data_page(struct inode *inode, pgoff_t index, int rw)
+struct page *get_read_data_page(struct inode *inode, pgoff_t index,
+   int rw, bool for_write)
 {
struct address_space *mapping = inode->i_mapping;
struct dnode_of_data dn;
@@ -292,7 +293,7 @@ struct page *get_read_data_page(struct inode *inode, 
pgoff_t index, int rw)
if (f2fs_encrypted_inode(inode) && S_ISREG(inode->i_mode))
return read_mapping_page(mapping, index, NULL);
 
-   page = grab_cache_page(mapping, index);
+   page = f2fs_grab_cache_page(mapping, index, for_write);
if (!page)
return ERR_PTR(-ENOMEM);
 
@@ -352,7 +353,7 @@ struct page *find_data_page(struct inode *inode, pgoff_t 
index)
return page;
f2fs_put_page(page, 0);
 
-   page = get_read_data_page(inode, index, READ_SYNC);
+   page = get_read_data_page(inode, index, READ_SYNC, false);
if (IS_ERR(page))
return page;
 
@@ -372,12 +373,13 @@ struct page *find_data_page(struct inode *inode, pgoff_t 
index)
  * Because, the callers, functions in dir.c and GC, should be able to know
  * whether this page exists or not.
  */
-struct page *get_lock_data_page(struct inode *inode, pgoff_t index)
+struct page *get_lock_data_page(struct inode *inode, pgoff_t index,
+   bool for_write)
 {
struct address_space *mapping = inode->i_mapping;
struct page *page;
 repeat:
-   page = get_read_data_page(inode, index, READ_SYNC);
+   page = get_read_data_page(inode, index, READ_SYNC, for_write);
if (IS_ERR(page))
return page;
 
@@ -411,7 +413,7 @@ struct page *get_new_data_page(struct inode *inode,
struct dnode_of_data dn;
int err;
 repeat:
-   page = grab_cache_page(mapping, index);
+   page = f2fs_grab_cache_page(mapping, index, true);
if (!page) {
/*
 * before exiting, we should make sure ipage will be released
@@ -439,7 +441,7 @@ repeat:
} else {
f2fs_put_page(page, 1);
 
-   page = get_read_data_page(inode, index, READ_SYNC);
+   page = get_read_data_page(inode, index, READ_SYNC, true);
if (IS_ERR(page))
goto repeat;
 
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index 6726c4a..7c1678b 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -258,7 +258,7 @@ struct f2fs_dir_entry *f2fs_parent_dir(struct inode *dir, 
struct page **p)
if (f2fs_has_inline_dentry(dir))
return f2fs_parent_inline_dir(dir, p);
 
-   page = get_lock_data_page(dir, 0);
+   page = get_lock_data_page(dir, 0, false);
if (IS_ERR(page))
return NULL;
 
@@ -740,7 +740,7 @@ bool f2fs_empty_dir(struct inode *dir)
return f2fs_empty_inline_dir(dir);
 
for (bidx = 0; bidx < nblock; bidx++) {
-   dentry_page = get_lock_data_page(dir, bidx);
+   dentry_page = get_lock_data_page(dir, bidx, false);
if (IS_ERR(dentry_page)) {
if (PTR_ERR(dentry_page) == -ENOENT)
continue;
@@ -854,7 +854,7 @@ static int f2fs_readdir(struct file *file, struct 
dir_context *ctx)
min(npages - n, (pgoff_t)MAX_DIR_RA_PAGES));
 
for (; n < npages; n++) {
-   dentry_page = get_lock_data_page(inode, n);
+   dentry_page = get_lock_data_page(inode, n, false);
if (IS_ERR(dentry_page))
continue;
 
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 6f2310c..6ba5a59 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1233,6 +1233,14 @@ static inline unsigned int valid_inode_count(struct 
f2fs_sb_info *sbi)
return sbi->total_valid_inode_count;
 }
 
+static inline struct page *f2fs_grab_cache_page(struct address_space *mapping,
+   pgoff_t index, bool for_write)
+{
+   if (!for_write)
+   

randconfig build error with next-20151009, in lib/zlib_deflate/deftree.c

[Jim Davis]

Building with the attached random configuration file,

lib/built-in.o: In function `__bitrev32':
deftree.c:(.text+0x1e799): undefined reference to `byte_rev_table'
deftree.c:(.text+0x1e7a0): undefined reference to `byte_rev_table'
deftree.c:(.text+0x1e7b4): undefined reference to `byte_rev_table'
deftree.c:(.text+0x1e7c1): undefined reference to `byte_rev_table'

-- 
Jim
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.3.0-rc4 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SYSVIPC=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
# CONFIG_USELIB is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
CONFIG_RCU_EXPERT=y
CONFIG_SRCU=y
# CONFIG_TASKS_RCU is not set
# CONFIG_RCU_STALL_COMMON is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_RCU_KTHREAD_PRIO=0
# CONFIG_RCU_EXPEDITE_BOOT is not set
CONFIG_BUILD_BIN2C=y
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_SUPPORTS_INT128=y
# CONFIG_CGROUPS is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_IPC_NS is not set
CONFIG_USER_NS=y
CONFIG_PID_NS=y
# CONFIG_SCHED_AUTOGROUP is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_LTO_MENU=y
# CONFIG_LTO_DISABLE is not set
CONFIG_LTO=y
CONFIG_LTO_DEBUG=y
CONFIG_LTO_CP_CLONE=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_EXPERT=y
CONFIG_UID16=y
CONFIG_MULTIUSER=y
# CONFIG_SGETMASK_SYSCALL is not set
CONFIG_SYSFS_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_PRINTK=y
CONFIG_BUG=y
# CONFIG_ELF_CORE is not set
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
# CONFIG_FUTEX is not set
# CONFIG_EPOLL is not set
# CONFIG_SIGNALFD is not set
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
# CONFIG_BPF_SYSCALL is not set
# CONFIG_SHMEM is not set
CONFIG_AIO=y
# CONFIG_ADVISE_SYSCALLS is not set
# CONFIG_USERFAULTFD is not set
CONFIG_MEMBARRIER=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
# 

[PATCH v2 3/7] soc: qcom: smd: Refactor channel open and close handling

[Bjorn Andersson]

Refactor opening and closing of channels into two separate functions
instead of open coding this in the various places.

Signed-off-by: Bjorn Andersson 
---

Changes since v1:
- New patch

 drivers/soc/qcom/smd.c | 62 --
 1 file changed, 40 insertions(+), 22 deletions(-)

diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c
index fb5f91efd0da..669bda585dad 100644
--- a/drivers/soc/qcom/smd.c
+++ b/drivers/soc/qcom/smd.c
@@ -806,18 +806,12 @@ static int qcom_smd_dev_match(struct device *dev, struct 
device_driver *drv)
 }
 
 /*
- * Probe the smd client.
- *
- * The remote side have indicated that it want the channel to be opened, so
- * complete the state handshake and probe our client driver.
+ * Helper for opening a channel
  */
-static int qcom_smd_dev_probe(struct device *dev)
+static int qcom_smd_channel_open(struct qcom_smd_channel *channel,
+qcom_smd_cb_t cb)
 {
-   struct qcom_smd_device *qsdev = to_smd_device(dev);
-   struct qcom_smd_driver *qsdrv = to_smd_driver(dev);
-   struct qcom_smd_channel *channel = qsdev->channel;
size_t bb_size;
-   int ret;
 
/*
 * Packets are maximum 4k, but reduce if the fifo is smaller
@@ -827,11 +821,44 @@ static int qcom_smd_dev_probe(struct device *dev)
if (!channel->bounce_buffer)
return -ENOMEM;
 
-   qcom_smd_channel_set_callback(channel, qsdrv->callback);
+   qcom_smd_channel_set_callback(channel, cb);
qcom_smd_channel_set_state(channel, SMD_CHANNEL_OPENING);
-
qcom_smd_channel_set_state(channel, SMD_CHANNEL_OPENED);
 
+   return 0;
+}
+
+/*
+ * Helper for closing and resetting a channel
+ */
+static void qcom_smd_channel_close(struct qcom_smd_channel *channel)
+{
+   qcom_smd_channel_set_callback(channel, NULL);
+
+   kfree(channel->bounce_buffer);
+   channel->bounce_buffer = NULL;
+
+   qcom_smd_channel_set_state(channel, SMD_CHANNEL_CLOSED);
+   qcom_smd_channel_reset(channel);
+}
+
+/*
+ * Probe the smd client.
+ *
+ * The remote side have indicated that it want the channel to be opened, so
+ * complete the state handshake and probe our client driver.
+ */
+static int qcom_smd_dev_probe(struct device *dev)
+{
+   struct qcom_smd_device *qsdev = to_smd_device(dev);
+   struct qcom_smd_driver *qsdrv = to_smd_driver(dev);
+   struct qcom_smd_channel *channel = qsdev->channel;
+   int ret;
+
+   ret = qcom_smd_channel_open(channel, qsdrv->callback);
+   if (ret)
+   return ret;
+
ret = qsdrv->probe(qsdev);
if (ret)
goto err;
@@ -843,11 +870,7 @@ static int qcom_smd_dev_probe(struct device *dev)
 err:
dev_err(>dev, "probe failed\n");
 
-   qcom_smd_channel_set_callback(channel, NULL);
-   kfree(channel->bounce_buffer);
-   channel->bounce_buffer = NULL;
-
-   qcom_smd_channel_set_state(channel, SMD_CHANNEL_CLOSED);
+   qcom_smd_channel_close(channel);
return ret;
 }
 
@@ -884,12 +907,7 @@ static int qcom_smd_dev_remove(struct device *dev)
 * The client is now gone, cleanup and reset the channel state.
 */
channel->qsdev = NULL;
-   kfree(channel->bounce_buffer);
-   channel->bounce_buffer = NULL;
-
-   qcom_smd_channel_set_state(channel, SMD_CHANNEL_CLOSED);
-
-   qcom_smd_channel_reset(channel);
+   qcom_smd_channel_close(channel);
 
return 0;
 }
-- 
2.4.2

--
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 7/7] Bluetooth: btqcomsmd: Qualcomm WCNSS HCI driver

[Bjorn Andersson]

The Qualcomm WCNSS chip provides two SMD channels to the BT core; one
for command and one for event packets. This driver exposes the two
channels as a hci device.

Signed-off-by: Bjorn Andersson 
---

Changes since v1:
- With the introduction of qcom_smd_open_channel() the two drivers are now one
- No more global state
- Corrected memory management of sk_buffs
- Reverted to __hci_cmd_sync_ev() for set_bdaddr
- Renamed the driver to btqcomsmd
- Split out the addition of HCI_SMD to separate patch

 drivers/bluetooth/Kconfig |  11 +++
 drivers/bluetooth/Makefile|   1 +
 drivers/bluetooth/btqcomsmd.c | 198 ++
 3 files changed, 210 insertions(+)
 create mode 100644 drivers/bluetooth/btqcomsmd.c

diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index 62999546a301..1652997e59cc 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -169,6 +169,17 @@ config BT_HCIUART_QCA
 
  Say Y here to compile support for QCA protocol.
 
+config BT_QCOMSMD
+   tristate "Qualcomm SMD based HCI support"
+   depends on QCOM_SMD
+   help
+ Qualcomm SMD based HCI driver.
+ This driver is used to bridge HCI data onto the shared memory
+ channels to the WCNSS core.
+
+ Say Y here to compile support for HCI over Qualcomm SMD into the
+ kernelor say M to compile as a module.
+
 config BT_HCIBCM203X
tristate "HCI BCM203x USB driver"
depends on USB
diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
index 07c9cf381e5a..19e313bf8c39 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_BT_WILINK)   += btwilink.o
 obj-$(CONFIG_BT_BCM)   += btbcm.o
 obj-$(CONFIG_BT_RTL)   += btrtl.o
 obj-$(CONFIG_BT_QCA)   += btqca.o
+obj-$(CONFIG_BT_QCOMSMD)   += btqcomsmd.o
 
 btmrvl-y   := btmrvl_main.o
 btmrvl-$(CONFIG_DEBUG_FS)  += btmrvl_debugfs.o
diff --git a/drivers/bluetooth/btqcomsmd.c b/drivers/bluetooth/btqcomsmd.c
new file mode 100644
index ..4b91c830531e
--- /dev/null
+++ b/drivers/bluetooth/btqcomsmd.c
@@ -0,0 +1,198 @@
+/*
+ * Copyright (c) 2015, Sony Mobile Communications Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define EDL_NVM_ACCESS_SET_REQ_CMD 0x01
+#define EDL_NVM_ACCESS_OPCODE  0xfc0b
+
+struct btqcomsmd {
+   struct qcom_smd_channel *acl_channel;
+   struct qcom_smd_channel *cmd_channel;
+};
+
+static int btqcomsmd_recv(struct hci_dev *hdev,
+ unsigned type,
+ const void *data,
+ size_t count)
+{
+   struct sk_buff *skb;
+   void *buf;
+
+   /* Use GFP_ATOMIC as we're in IRQ context */
+   skb = bt_skb_alloc(count, GFP_ATOMIC);
+   if (!skb)
+   return -ENOMEM;
+
+   bt_cb(skb)->pkt_type = type;
+
+   /* Use io accessor as data might be ioremapped */
+   buf = skb_put(skb, count);
+   memcpy_fromio(buf, data, count);
+
+   return hci_recv_frame(hdev, skb);
+}
+
+static int btqcomsmd_acl_callback(struct qcom_smd_device *qsdev,
+ const void *data,
+ size_t count)
+{
+   struct hci_dev *hdev = dev_get_drvdata(>dev);
+
+   return btqcomsmd_recv(hdev, HCI_ACLDATA_PKT, data, count);
+}
+
+static int btqcomsmd_cmd_callback(struct qcom_smd_device *qsdev,
+ const void *data,
+ size_t count)
+{
+   struct hci_dev *hdev = dev_get_drvdata(>dev);
+
+   return btqcomsmd_recv(hdev, HCI_EVENT_PKT, data, count);
+}
+
+static int btqcomsmd_send(struct hci_dev *hdev, struct sk_buff *skb)
+{
+   struct btqcomsmd *btq = hci_get_drvdata(hdev);
+   int ret;
+
+   switch (bt_cb(skb)->pkt_type) {
+   case HCI_ACLDATA_PKT:
+   case HCI_SCODATA_PKT:
+   ret = qcom_smd_send(btq->acl_channel, skb->data, skb->len);
+   break;
+   case HCI_COMMAND_PKT:
+   ret = qcom_smd_send(btq->cmd_channel, skb->data, skb->len);
+   break;
+   default:
+   ret = -ENODEV;
+   break;
+   }
+
+   return ret;
+}
+
+static int btqcomsmd_open(struct hci_dev *hdev)
+{
+   set_bit(HCI_RUNNING, >flags);
+   return 0;
+}
+
+static int btqcomsmd_close(struct hci_dev 

[PATCH v2 4/7] soc: qcom: smd: Support multiple channels per sdev

[Bjorn Andersson]

This patch allows chaining additional channels to a SMD device, enabling
implementation of multi-channel SMD devies - like Bluetooth.

Signed-off-by: Bjorn Andersson 
---

Changes since v1:
- New patch

 drivers/soc/qcom/smd.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c
index 669bda585dad..4c55708aac50 100644
--- a/drivers/soc/qcom/smd.c
+++ b/drivers/soc/qcom/smd.c
@@ -193,6 +193,7 @@ struct qcom_smd_channel {
int pkt_size;
 
struct list_head list;
+   struct list_head dev_list;
 };
 
 /**
@@ -885,6 +886,8 @@ static int qcom_smd_dev_remove(struct device *dev)
struct qcom_smd_device *qsdev = to_smd_device(dev);
struct qcom_smd_driver *qsdrv = to_smd_driver(dev);
struct qcom_smd_channel *channel = qsdev->channel;
+   struct qcom_smd_channel *tmp;
+   struct qcom_smd_channel *ch;
 
qcom_smd_channel_set_state(channel, SMD_CHANNEL_CLOSING);
 
@@ -904,10 +907,14 @@ static int qcom_smd_dev_remove(struct device *dev)
qsdrv->remove(qsdev);
 
/*
-* The client is now gone, cleanup and reset the channel state.
+* The client is now gone, close and release all channels associated
+* with this sdev
 */
-   channel->qsdev = NULL;
-   qcom_smd_channel_close(channel);
+   list_for_each_entry_safe(ch, tmp, >dev_list, dev_list) {
+   qcom_smd_channel_close(ch);
+   list_del(>dev_list);
+   ch->qsdev = NULL;
+   }
 
return 0;
 }
@@ -1056,6 +1063,7 @@ static struct qcom_smd_channel 
*qcom_smd_create_channel(struct qcom_smd_edge *ed
if (!channel)
return ERR_PTR(-ENOMEM);
 
+   INIT_LIST_HEAD(>dev_list);
channel->edge = edge;
channel->name = devm_kstrdup(smd->dev, name, GFP_KERNEL);
if (!channel->name)
-- 
2.4.2

--
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 2/7] soc: qcom: smd: Split discovery and state change work

[Bjorn Andersson]

Split the two steps of channel discovery and state change handling into
two different workers. This allows for new channels to be found while
we're are probing, which is required as we introduce multi-channel
support.

Signed-off-by: Bjorn Andersson 
---

Changes since v1:
- New patch

 drivers/soc/qcom/smd.c | 58 +-
 1 file changed, 29 insertions(+), 29 deletions(-)

diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c
index 8b401d89b0d0..fb5f91efd0da 100644
--- a/drivers/soc/qcom/smd.c
+++ b/drivers/soc/qcom/smd.c
@@ -106,9 +106,9 @@ static const struct {
  * @channels:  list of all channels detected on this edge
  * @channels_lock: guard for modifications of @channels
  * @allocated: array of bitmaps representing already allocated channels
- * @need_rescan:   flag that the @work needs to scan smem for new channels
  * @smem_available:last available amount of smem triggering a channel scan
- * @work:  work item for edge house keeping
+ * @scan_work: work item for discovering new channels
+ * @state_work:work item for edge state changes
  */
 struct qcom_smd_edge {
struct qcom_smd *smd;
@@ -123,14 +123,14 @@ struct qcom_smd_edge {
int ipc_bit;
 
struct list_head channels;
-   spinlock_t channels_lock;
+   rwlock_t channels_lock;
 
DECLARE_BITMAP(allocated[SMD_ALLOC_TBL_COUNT], SMD_ALLOC_TBL_SIZE);
 
-   bool need_rescan;
unsigned smem_available;
 
-   struct work_struct work;
+   struct work_struct scan_work;
+   struct work_struct state_work;
 };
 
 /*
@@ -624,13 +624,13 @@ static irqreturn_t qcom_smd_edge_intr(int irq, void *data)
/*
 * Handle state changes or data on each of the channels on this edge
 */
-   spin_lock(>channels_lock);
+   read_lock(>channels_lock);
list_for_each_entry(channel, >channels, list) {
spin_lock(>recv_lock);
kick_worker |= qcom_smd_channel_intr(channel);
spin_unlock(>recv_lock);
}
-   spin_unlock(>channels_lock);
+   read_unlock(>channels_lock);
 
/*
 * Creating a new channel requires allocating an smem entry, so we only
@@ -640,12 +640,11 @@ static irqreturn_t qcom_smd_edge_intr(int irq, void *data)
available = qcom_smem_get_free_space(edge->remote_pid);
if (available != edge->smem_available) {
edge->smem_available = available;
-   edge->need_rescan = true;
kick_worker = true;
}
 
if (kick_worker)
-   schedule_work(>work);
+   schedule_work(>scan_work);
 
return IRQ_HANDLED;
 }
@@ -1101,8 +1100,9 @@ free_name_and_channel:
  * qcom_smd_create_channel() to create representations of these and add
  * them to the edge's list of channels.
  */
-static void qcom_discover_channels(struct qcom_smd_edge *edge)
+static void qcom_channel_scan_worker(struct work_struct *work)
 {
+   struct qcom_smd_edge *edge = container_of(work, struct qcom_smd_edge, 
scan_work);
struct qcom_smd_alloc_entry *alloc_tbl;
struct qcom_smd_alloc_entry *entry;
struct qcom_smd_channel *channel;
@@ -1146,16 +1146,16 @@ static void qcom_discover_channels(struct qcom_smd_edge 
*edge)
if (IS_ERR(channel))
continue;
 
-   spin_lock_irqsave(>channels_lock, flags);
+   write_lock_irqsave(>channels_lock, flags);
list_add(>list, >channels);
-   spin_unlock_irqrestore(>channels_lock, flags);
+   write_unlock_irqrestore(>channels_lock, flags);
 
dev_dbg(smd->dev, "new channel found: '%s'\n", 
channel->name);
set_bit(i, edge->allocated[tbl]);
}
}
 
-   schedule_work(>work);
+   schedule_work(>state_work);
 }
 
 /*
@@ -1163,29 +1163,22 @@ static void qcom_discover_channels(struct qcom_smd_edge 
*edge)
  * then scans all registered channels for state changes that should be handled
  * by creating or destroying smd client devices for the registered channels.
  *
- * LOCKING: edge->channels_lock is not needed to be held during the traversal
- * of the channels list as it's done synchronously with the only writer.
+ * LOCKING: edge->channels_lock only needs to cover the list operations, as the
+ * worker is killed before any channels are deallocated
  */
 static void qcom_channel_state_worker(struct work_struct *work)
 {
struct qcom_smd_channel *channel;
struct qcom_smd_edge *edge = container_of(work,
  struct qcom_smd_edge,
- work);
+ state_work);
unsigned 

Re: [PATCH 10/15] block, dax: fix lifetime of in-kernel dax mappings

[Dan Williams]

On Wed, Oct 7, 2015 at 3:56 PM, Logan Gunthorpe  wrote:
> Hi Dan,
>
> We've uncovered another issue during testing with these patches. We get a
> kernel panic sometimes just while using a DAX filesystem. I've traced the
> issue back to this patch. (There's a stack trace at the end of this email.)
>
> On 22/09/15 10:42 PM, Dan Williams wrote:
>>
>> +static void dax_unmap_bh(const struct buffer_head *bh, void __pmem *addr)
>> +{
>> +   struct block_device *bdev = bh->b_bdev;
>> +   struct request_queue *q = bdev->bd_queue;
>> +
>> +   if (IS_ERR(addr))
>> +   return;
>> +   blk_dax_put(q);
>>   }
>>
>> @@ -127,9 +159,8 @@ static ssize_t dax_io(struct inode *inode, struct
>> iov_iter *iter,
>> if (pos == bh_max) {
>> bh->b_size = PAGE_ALIGN(end - pos);
>> bh->b_state = 0;
>> -   retval = get_block(inode, block, bh,
>> -  iov_iter_rw(iter) ==
>> WRITE);
>> -   if (retval)
>> +   rc = get_block(inode, block, bh, rw ==
>> WRITE);
>> +   if (rc)
>> break;
>> if (!buffer_size_valid(bh))
>> bh->b_size = 1 << blkbits;
>> @@ -178,8 +213,9 @@ static ssize_t dax_io(struct inode *inode, struct
>> iov_iter *iter,
>>
>> if (need_wmb)
>> wmb_pmem();
>> +   dax_unmap_bh(bh, kmap);
>>
>> -   return (pos == start) ? retval : pos - start;
>> +   return (pos == start) ? rc : pos - start;
>>   }
>
>
> The problem is if get_block fails and returns an error code, it will still
> call dax_unmap_bh which tries to dereference bh->b_bdev. However, seeing
> get_block failed, that pointer is NULL. Maybe a null check in dax_unmap_bh
> would be sufficient?

Thanks for the report, I have this fixed up in v2.  Will post shortly.
--
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] x86, suspend: Save/restore extra MSR registers for suspend

[Rafael J. Wysocki]

On Thursday, August 27, 2015 11:18:27 AM Chen Yu wrote:
> A bug is reported(https://bugzilla.redhat.com/show_bug.cgi?id=1227208)
> that, after resumed from S3, CPU is running at a low speed.
> After investigation, it is found that, BIOS has modified the value
> of THERM_CONTROL register during S3, and changes it from 0 to 0x10,
> since value of 0x10 means CPU can only get 25% of the Duty Cycle,
> this triggers the problem.
> 
> Here is a simple scenario to reproduce the issue:
> 1.Boot up the system
> 2.Get MSR with address 0x19a, it should be 0
> 3.Put the system into sleep, then wake it up
> 4.Get MSR with address 0x19a, it should be 0(actually it shows 0x10)
> 
> Although this is a BIOS issue, it would be more robust for linux to deal
> with this situation. This patch fixes this issue by introducing a framework
> to save/restore specified MSR registers(THERM_CONTROL in this case)
> for suspend/resume.
> 
> When user encounters a problematic platform and needs to protect the
> MSRs during suspending, he can simply add a quirk entry in
> msr_save_dmi_table, and customizes MSR registers inside the quirk
> callback, for example:
> 
> u32 msr_id_need_to_save[] = {MSR_ID0, MSR_ID1, MSR_ID2...};
> 
> and the quirk mechanism ensures that, once resumed from suspended,
> the MSRs indicated by these IDs will be restored to their original values
> before suspended.
> 
> Since both 64/32-bit kernels are affected, this patch covers 64/32-bit
> common code path. And because the MSRs specified by the user might not
> be available or readable in any situation, we use rdmsrl_safe to safely
> save these MSRs.
> 
> Tested-by: Marcin Kaszewski 
> Signed-off-by: Chen Yu 
> ---
> v4:
>  - Revert v3 to v2, and fix some typos in changelog/comments. 
>Use msr_info structure instead of msr_id + msr_value.
>Adjust some codes for better readability.
> v3:
>  - Simplify the patch to only focus on THERM_CONTROL register.
>This will make things 'just work'.
> v2:
>  - Cover both 64/32-bit common code path.
>Use rdmsrl_safe to safely read MSR.
>Introduce a quirk framework for save/restore specified MSR on different
>platforms.
> ---
>  arch/x86/include/asm/suspend_32.h | 11 +
>  arch/x86/include/asm/suspend_64.h | 11 +
>  arch/x86/power/cpu.c  | 99 
> +++
>  3 files changed, 121 insertions(+)
> 
> diff --git a/arch/x86/include/asm/suspend_32.h 
> b/arch/x86/include/asm/suspend_32.h
> index d1793f0..240aaa8 100644
> --- a/arch/x86/include/asm/suspend_32.h
> +++ b/arch/x86/include/asm/suspend_32.h
> @@ -9,12 +9,23 @@
>  #include 
>  #include 
>  
> +struct msr_type {

I'd call this msr_data.

> + bool msr_saved;
> + struct msr_info rv;
> +};
> +
> +struct saved_msr {

And this msr_context.

> + unsigned short num;
> + struct msr_type *msr_array;
> +};
> +
>  /* image of the saved processor state */
>  struct saved_context {
>   u16 es, fs, gs, ss;
>   unsigned long cr0, cr2, cr3, cr4;
>   u64 misc_enable;
>   bool misc_enable_saved;
> + struct saved_msr msr_for_save;

"msr_to_save"?

>   struct desc_ptr gdt_desc;
>   struct desc_ptr idt;
>   u16 ldt;
> diff --git a/arch/x86/include/asm/suspend_64.h 
> b/arch/x86/include/asm/suspend_64.h
> index 7ebf0eb..40a7a00 100644
> --- a/arch/x86/include/asm/suspend_64.h
> +++ b/arch/x86/include/asm/suspend_64.h
> @@ -9,6 +9,16 @@
>  #include 
>  #include 
>  
> +struct msr_type {
> + bool msr_saved;
> + struct msr_info rv;
> +};
> +
> +struct saved_msr {
> + unsigned short num;
> + struct msr_type *msr_array;
> +};

The definitions look the same as the previous ones.

Can we share them somehow?

> +
>  /*
>   * Image of the saved processor state, used by the low level ACPI suspend to
>   * RAM code and by the low level hibernation code.
> @@ -24,6 +34,7 @@ struct saved_context {
>   unsigned long cr0, cr2, cr3, cr4, cr8;
>   u64 misc_enable;
>   bool misc_enable_saved;
> + struct saved_msr msr_for_save;
>   unsigned long efer;
>   u16 gdt_pad; /* Unused */
>   struct desc_ptr gdt_desc;
> diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c
> index 9ab5279..8442473 100644
> --- a/arch/x86/power/cpu.c
> +++ b/arch/x86/power/cpu.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #ifdef CONFIG_X86_32
>  __visible unsigned long saved_context_ebx;
> @@ -32,6 +33,30 @@ __visible unsigned long saved_context_eflags;
>  #endif
>  struct saved_context saved_context;
>  
> +static void msr_save_context(struct saved_context *ctxt)
> +{
> + int i = 0;
> +
> + for (i = 0; i < ctxt->msr_for_save.num; i++) {
> + struct msr_type *msr = >msr_for_save.msr_array[i];
> +
> + msr->msr_saved = !rdmsrl_safe(msr->rv.msr_no,
> + >rv.reg.q);
> + }

If you did something like

struct msr_type *msr = 

Re: [PATCH v2] sunrpc: fix waitqueue_active without memory barrier in sunrpc

[Trond Myklebust]

On Fri, Oct 9, 2015 at 5:18 PM, J. Bruce Fields  wrote:
>
> On Fri, Oct 09, 2015 at 06:29:44AM +, Kosuke Tatsukawa wrote:
> > Neil Brown wrote:
> > > Kosuke Tatsukawa  writes:
> > >
> > >> There are several places in net/sunrpc/svcsock.c which calls
> > >> waitqueue_active() without calling a memory barrier.  Add a memory
> > >> barrier just as in wq_has_sleeper().
> > >>
> > >> I found this issue when I was looking through the linux source code
> > >> for places calling waitqueue_active() before wake_up*(), but without
> > >> preceding memory barriers, after sending a patch to fix a similar
> > >> issue in drivers/tty/n_tty.c  (Details about the original issue can be
> > >> found here: https://lkml.org/lkml/2015/9/28/849).
> > >
> > > hi,
> > > this feels like the wrong approach to the problem.  It requires extra
> > > 'smb_mb's to be spread around which are hard to understand as easy to
> > > forget.
> > >
> > > A quick look seems to suggest that (nearly) every waitqueue_active()
> > > will need an smb_mb.  Could we just put the smb_mb() inside
> > > waitqueue_active()??
> > 
> >
> > There are around 200 occurrences of waitqueue_active() in the kernel
> > source, and most of the places which use it before wake_up are either
> > protected by some spin lock, or already has a memory barrier or some
> > kind of atomic operation before it.
> >
> > Simply adding smp_mb() to waitqueue_active() would incur extra cost in
> > many cases and won't be a good idea.
> >
> > Another way to solve this problem is to remove the waitqueue_active(),
> > making the code look like this;
> >   if (wq)
> >   wake_up_interruptible(wq);
> > This also fixes the problem because the spinlock in the wake_up*() acts
> > as a memory barrier and prevents the code from being reordered by the
> > CPU (and it also makes the resulting code is much simpler).
>
> I might not care which we did, except I don't have the means to test
> this quickly, and I guess this is some of our most frequently called
> code.
>
> I suppose your patch is the most conservative approach, as the
> alternative is a spinlock/unlock in wake_up_interruptible, which I
> assume is necessarily more expensive than an smp_mb().
>
> As far as I can tell it's been this way since forever.  (Well, since a
> 2002 patch "NFSD: TCP: rationalise locking in RPC server routines" which
> removed some spinlocks from the data_ready routines.)
>
> I don't understand what the actual race is yet (which code exactly is
> missing the wakeup in this case?  nfsd threads seem to instead get
> woken up by the wake_up_process() in svc_xprt_do_enqueue().)
>

Those threads still use blocking calls for sendpage() and sendmsg(),
so presumably they may be affected.
--
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 2/7] MAINTAINERS: Add myself for the new VC4 (RPi GPU) graphics driver.

[Eric Anholt]

Signed-off-by: Eric Anholt 
---

v2: Mark it Supported, not Maintained.

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

diff --git a/MAINTAINERS b/MAINTAINERS
index 7ba7ab7..e331e46 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3653,6 +3653,12 @@ S:   Maintained
 F: drivers/gpu/drm/sti
 F: Documentation/devicetree/bindings/gpu/st,stih4xx.txt
 
+DRM DRIVERS FOR VC4
+M: Eric Anholt 
+T: git git://github.com/anholt/linux
+S: Supported
+F: drivers/gpu/drm/vc4/*
+
 DSBR100 USB FM RADIO DRIVER
 M: Alexey Klimov 
 L: linux-me...@vger.kernel.org
-- 
2.1.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: arm/arm64: GICv2 driver does not have irq_disable implemented

[Thomas Gleixner]

On Fri, 9 Oct 2015, Duc Dang wrote:
> On Fri, Oct 9, 2015 at 10:52 AM, Thomas Gleixner  wrote:
> > On Fri, 9 Oct 2015, Duc Dang wrote:
> >> In APM ARM64 X-Gene Enet controller driver, we use disable_irq_nosync to
> >> disable interrupt before calling __napi_schedule to schedule packet handler
> >> to process the Tx/Rx packets.
> >
> > Which is wrong to begin with. Disable the interrupt at the device
> > level not at the interrupt line level.
> >
> We could not disable the interrupt at Enet controller level due to the
> controller limitation. As you said, using  disable_irq_nosync is wrong
> but it looks like that the only option that we have.

Oh well.
 
> Do you have any suggestion about different approach that we could try?

Try the patch below and add 

irq_set_status_flags(irq, IRQ_DISABLE_UNLAZY);

to your driver before requesting the interrupt. Unset it when freeing
the interrupt.

Thanks,

tglx

8<--

Subject: genirq: Add flag to force mask in disable_irq[_nosync]()
From: Thomas Gleixner 
Date: Fri, 09 Oct 2015 23:28:58 +0200

If an irq chip does not implement the irq_disable callback, then we
use a lazy approach for disabling the interrupt. That means that the
interrupt is marked disabled, but the interrupt line is not
immediately masked in the interrupt chip. It only becomes masked if
the interrupt is raised while it's marked disabled. We use this to avoid
possibly expensive mask/unmask operations for common case operations.

Unfortunately there are devices which do not allow the interrupt to be
disabled easily at the device level. They are forced to use
disable_irq_nosync(). This can result in taking each interrupt twice.

Instead of enforcing the non lazy mode on all interrupts of a irq
chip, provide a settings flag, which can be set by the driver for that
particular interrupt line.

Signed-off-by: Thomas Gleixner 
---
 include/linux/irq.h   |4 +++-
 kernel/irq/chip.c |9 +
 kernel/irq/settings.h |7 +++
 3 files changed, 19 insertions(+), 1 deletion(-)

Index: tip/include/linux/irq.h
===
--- tip.orig/include/linux/irq.h
+++ tip/include/linux/irq.h
@@ -72,6 +72,7 @@ enum irqchip_irq_state;
  * IRQ_IS_POLLED   - Always polled by another interrupt. Exclude
  *   it from the spurious interrupt detection
  *   mechanism and from core side polling.
+ * IRQ_DISABLE_UNLAZY  - Disable lazy irq disable
  */
 enum {
IRQ_TYPE_NONE   = 0x,
@@ -97,13 +98,14 @@ enum {
IRQ_NOTHREAD= (1 << 16),
IRQ_PER_CPU_DEVID   = (1 << 17),
IRQ_IS_POLLED   = (1 << 18),
+   IRQ_DISABLE_UNLAZY  = (1 << 19),
 };
 
 #define IRQF_MODIFY_MASK   \
(IRQ_TYPE_SENSE_MASK | IRQ_NOPROBE | IRQ_NOREQUEST | \
 IRQ_NOAUTOEN | IRQ_MOVE_PCNTXT | IRQ_LEVEL | IRQ_NO_BALANCING | \
 IRQ_PER_CPU | IRQ_NESTED_THREAD | IRQ_NOTHREAD | IRQ_PER_CPU_DEVID | \
-IRQ_IS_POLLED)
+IRQ_IS_POLLED | IRQ_DISABLE_UNLAZY)
 
 #define IRQ_NO_BALANCING_MASK  (IRQ_PER_CPU | IRQ_NO_BALANCING)
 
Index: tip/kernel/irq/chip.c
===
--- tip.orig/kernel/irq/chip.c
+++ tip/kernel/irq/chip.c
@@ -241,6 +241,13 @@ void irq_enable(struct irq_desc *desc)
  * disabled. If an interrupt happens, then the interrupt flow
  * handler masks the line at the hardware level and marks it
  * pending.
+ *
+ * If the interrupt chip does not implement the irq_disable callback,
+ * a driver can disable the lazy approach for a particular irq line by
+ * calling 'irq_set_status_flags(irq, IRQ_DISABLE_UNLAZY)'. This can be
+ * used for devices which cannot disable the interrupt at the device
+ * level under certain circumstances and have to use
+ * disable_irq[_nosync] instead.
  */
 void irq_disable(struct irq_desc *desc)
 {
@@ -248,6 +255,8 @@ void irq_disable(struct irq_desc *desc)
if (desc->irq_data.chip->irq_disable) {
desc->irq_data.chip->irq_disable(>irq_data);
irq_state_set_masked(desc);
+   } else if (irq_settings_disable_unlazy(desc)) {
+   mask_irq(desc);
}
 }
 
Index: tip/kernel/irq/settings.h
===
--- tip.orig/kernel/irq/settings.h
+++ tip/kernel/irq/settings.h
@@ -15,6 +15,7 @@ enum {
_IRQ_NESTED_THREAD  = IRQ_NESTED_THREAD,
_IRQ_PER_CPU_DEVID  = IRQ_PER_CPU_DEVID,
_IRQ_IS_POLLED  = IRQ_IS_POLLED,
+   _IRQ_DISABLE_UNLAZY = IRQ_DISABLE_UNLAZY,
_IRQF_MODIFY_MASK   = IRQF_MODIFY_MASK,
 };
 
@@ -28,6 +29,7 @@ enum {
 #define IRQ_NESTED_THREAD  GOT_YOU_MORON
 #define IRQ_PER_CPU_DEVID  GOT_YOU_MORON
 #define IRQ_IS_POLLED  GOT_YOU_MORON
+#define 

Re: [PATCH v3 2/7] MAINTAINERS: Add myself for the new VC4 (RPi GPU) graphics driver.

[Emil Velikov]

Hi Eric,

On 9 October 2015 at 22:27, Eric Anholt  wrote:
> Signed-off-by: Eric Anholt 
> ---
>
> v2: Mark it Supported, not Maintained.
>
>  MAINTAINERS | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7ba7ab7..e331e46 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3653,6 +3653,12 @@ S:   Maintained
>  F: drivers/gpu/drm/sti
>  F: Documentation/devicetree/bindings/gpu/st,stih4xx.txt
>
> +DRM DRIVERS FOR VC4
> +M: Eric Anholt 
> +T: git git://github.com/anholt/linux
You might want to add dri-devel as mailing list, at least initially.

> +S: Supported
> +F: drivers/gpu/drm/vc4/*
Imho, the binding documentation should also be listed here.

Regards,
Emil
--
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 00/20] tree-wide convert to memremap()

[Dan Williams]

The memremap() api [1] was merged in 4.3 [2] with an initial
implementation for x86 and a conversion of the pmem driver. Complete the
conversion for the rest of the kernel.

Feel free to either ack or directly apply a conversion-patch as I will
defer the final removal patches until all the conversions have landed.

[1]: https://lwn.net/Articles/653585/
[2]: commit 92281dee825f arch: introduce memremap()

---

Dan Williams (20):
  x86: introduce arch_memremap()
  arm: introduce arch_memremap()
  ia64: introduce arch_memremap()
  sh: introduce arch_memremap()
  m68k: introduce arch_memremap()
  arm: switch from ioremap_cache to memremap
  x86: switch from ioremap_cache to memremap
  gma500: switch from acpi_os_ioremap to memremap
  i915: switch from acpi_os_ioremap to memremap
  acpi: switch from ioremap_cache to memremap
  sound, skylake: switch from ioremap_cache to memremap
  memconsole: fix __iomem mishandling, switch to memremap
  intel-iommu: switch from ioremap_cache to memremap
  pxa2xx-flash: switch from ioremap_cache to memremap
  sfi: switch from ioremap_cache to memremap
  fbdev: switch from ioremap_wt to memremap
  arch: kill ioremap_cached()
  arch: kill ioremap_fullcache()
  arch: remove ioremap_cache, replace with arch_memremap
  arch: remove ioremap_wt, optionally replace with arch_memremap


 Documentation/x86/pat.txt |6 +--
 arch/arc/include/asm/io.h |1 
 arch/arm/Kconfig  |1 
 arch/arm/include/asm/io.h |7 ---
 arch/arm/include/asm/xen/page.h   |4 +-
 arch/arm/mm/ioremap.c |   12 -
 arch/arm/mm/mmu.c |2 -
 arch/arm/mm/nommu.c   |   11 +++--
 arch/arm64/Kconfig|1 
 arch/arm64/include/asm/acpi.h |   11 -
 arch/arm64/include/asm/dmi.h  |8 ++--
 arch/arm64/include/asm/io.h   |2 -
 arch/arm64/kernel/efi.c   |9 ++--
 arch/arm64/kernel/smp_spin_table.c|   19 -
 arch/arm64/mm/ioremap.c   |   20 +++--
 arch/avr32/include/asm/io.h   |1 
 arch/frv/include/asm/io.h |   12 -
 arch/ia64/Kconfig |1 
 arch/ia64/include/asm/io.h|6 ---
 arch/ia64/mm/ioremap.c|   10 +
 arch/m32r/include/asm/io.h|1 
 arch/m68k/Kconfig |1 
 arch/m68k/include/asm/io_mm.h |   13 --
 arch/m68k/include/asm/io_no.h |   11 -
 arch/m68k/include/asm/raw_io.h|1 
 arch/m68k/mm/kmap.c   |   17 +++-
 arch/m68k/mm/sun3kmap.c   |7 +++
 arch/metag/include/asm/io.h   |6 ---
 arch/microblaze/include/asm/io.h  |2 -
 arch/mn10300/include/asm/io.h |1 
 arch/nios2/include/asm/io.h   |1 
 arch/s390/include/asm/io.h|1 
 arch/sh/Kconfig   |1 
 arch/sh/include/asm/io.h  |7 ---
 arch/sh/mm/ioremap.c  |9 
 arch/sparc/include/asm/io_32.h|1 
 arch/sparc/include/asm/io_64.h|1 
 arch/tile/include/asm/io.h|2 -
 arch/unicore32/include/asm/io.h   |4 --
 arch/unicore32/mm/ioremap.c   |8 
 arch/x86/Kconfig  |1 
 arch/x86/include/asm/efi.h|3 +
 arch/x86/include/asm/io.h |4 --
 arch/x86/kernel/crash_dump_64.c   |6 +--
 arch/x86/kernel/kdebugfs.c|8 ++--
 arch/x86/kernel/ksysfs.c  |   28 ++---
 arch/x86/mm/ioremap.c |   43 ---
 arch/xtensa/include/asm/io.h  |   12 -
 drivers/acpi/apei/einj.c  |9 ++--
 drivers/acpi/apei/erst.c  |6 +--
 drivers/acpi/nvs.c|6 +--
 drivers/acpi/osl.c|   70 +---
 drivers/firmware/google/memconsole.c  |7 ++-
 drivers/gpu/drm/gma500/opregion.c |8 ++--
 drivers/gpu/drm/gma500/psb_drv.h  |2 -
 drivers/gpu/drm/gma500/psb_lid.c  |8 ++--
 drivers/gpu/drm/i915/i915_debugfs.c   |2 -
 drivers/gpu/drm/i915/i915_drv.h   |   12 +++--
 drivers/gpu/drm/i915/intel_bios.c |7 +--
 drivers/gpu/drm/i915/intel_opregion.c |   73 -
 drivers/gpu/drm/i915/intel_panel.c|2 -
 drivers/iommu/intel-iommu.c   |   20 +
 drivers/iommu/intel_irq_remapping.c   |8 ++--
 drivers/mtd/maps/pxa2xx-flash.c   |6 +--
 drivers/nvdimm/Kconfig|2 -
 drivers/sfi/sfi_core.c|4 +-
 drivers/video/fbdev/Kconfig   |2 -
 drivers/video/fbdev/amifb.c   |5 +-
 drivers/video/fbdev/atafb.c   |5 +-
 drivers/video/fbdev/hpfb.c|6 +--
 include/acpi/acpi_io.h  

[PATCH 01/20] x86: introduce arch_memremap()

[Dan Williams]

In preparation for removing ioremap_cache() introduce arch_memremap()
for x86.  For now, arch_memremap(..., MEMREMAP_WB) and
arch_memremap(..., MEMREMAP_WT) are aliases for ioremap_cache() and
ioremap_wt() respectively.  While the memremap() conversion patches are
filtering through the other sub-systems further development of the
memremap interface may proceed.

This also initiates the guarantee that a successful call to
memremap(..., MEMREMAP_WB) has indeed established a cached mapping and
has not silently fallen back to uncached.

Cc: Arnd Bergmann 
Cc: Thomas Gleixner 
Cc: H. Peter Anvin 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: Ross Zwisler 
Signed-off-by: Dan Williams 
---
 Documentation/x86/pat.txt |2 ++
 arch/x86/Kconfig  |1 +
 arch/x86/mm/ioremap.c |   17 +
 drivers/nvdimm/Kconfig|2 +-
 include/linux/io.h|1 +
 kernel/memremap.c |   25 +
 lib/Kconfig   |5 -
 7 files changed, 39 insertions(+), 14 deletions(-)

diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt
index 54944c71b819..8c908fa5ea26 100644
--- a/Documentation/x86/pat.txt
+++ b/Documentation/x86/pat.txt
@@ -40,6 +40,8 @@ ioremap_nocache|--|UC- |   UC-
|
|  ||  |
 ioremap_wc |--|--  |   WC |
|  ||  |
+memremap(MEMREMAP_WB)  |WB|WB  |   WB |
+   |  ||  |
 ioremap_wt |--|--  |   WT |
|  ||  |
 set_memory_uc  |UC-   |--  |   -- |
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 328c8352480c..488cb210d055 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -27,6 +27,7 @@ config X86
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FAST_MULTIPLIER
select ARCH_HAS_GCOV_PROFILE_ALL
+   select ARCH_HAS_MEMREMAP
select ARCH_HAS_PMEM_APIif X86_64
select ARCH_HAS_MMIO_FLUSH
select ARCH_HAS_SG_CHAIN
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index b9c78f3bcd67..123431ae702f 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -317,6 +317,23 @@ void __iomem *ioremap_cache(resource_size_t phys_addr, 
unsigned long size)
 }
 EXPORT_SYMBOL(ioremap_cache);
 
+void *arch_memremap(resource_size_t phys_addr, size_t size,
+   unsigned long flags)
+{
+   int prot;
+
+   if (flags & MEMREMAP_WB)
+   prot = _PAGE_CACHE_MODE_WB;
+   else if (flags & MEMREMAP_WT)
+   prot = _PAGE_CACHE_MODE_WT;
+   else
+   return NULL;
+
+   return (void __force *) __ioremap_caller(phys_addr, size, prot,
+   __builtin_return_address(0));
+}
+EXPORT_SYMBOL(arch_memremap);
+
 void __iomem *ioremap_prot(resource_size_t phys_addr, unsigned long size,
unsigned long prot_val)
 {
diff --git a/drivers/nvdimm/Kconfig b/drivers/nvdimm/Kconfig
index 53c11621d5b1..b8e9d8b46f33 100644
--- a/drivers/nvdimm/Kconfig
+++ b/drivers/nvdimm/Kconfig
@@ -1,5 +1,6 @@
 menuconfig LIBNVDIMM
tristate "NVDIMM (Non-Volatile Memory Device) Support"
+   depends on ARCH_HAS_MEMREMAP
depends on PHYS_ADDR_T_64BIT
depends on BLK_DEV
help
@@ -19,7 +20,6 @@ if LIBNVDIMM
 config BLK_DEV_PMEM
tristate "PMEM: Persistent memory block device support"
default LIBNVDIMM
-   depends on HAS_IOMEM
select ND_BTT if BTT
select ND_PFN if NVDIMM_PFN
help
diff --git a/include/linux/io.h b/include/linux/io.h
index de64c1e53612..4f150781735d 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -153,5 +153,6 @@ enum {
 
 void *memremap(resource_size_t offset, size_t size, unsigned long flags);
 void memunmap(void *addr);
+void *arch_memremap(resource_size_t offset, size_t size, unsigned long flags);
 
 #endif /* _LINUX_IO_H */
diff --git a/kernel/memremap.c b/kernel/memremap.c
index 72b0c66628b6..8bd5fe05d4a4 100644
--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@ -24,6 +24,16 @@ __weak void __iomem *ioremap_cache(resource_size_t offset, 
unsigned long size)
 }
 #endif
 
+/* temporary while we convert arch implementations to arch_memremap */
+__weak void *arch_memremap(resource_size_t offset, size_t size,
+   unsigned long flags)
+{
+   if (flags & MEMREMAP_WB)
+   return (void __force *) ioremap_cache(offset, size);
+   else if (flags & MEMREMAP_WT)
+   return (void __force *) ioremap_wt(offset, size);
+}
+
 /**
  * 

[PATCH 03/20] ia64: introduce arch_memremap()

[Dan Williams]

In preparation for removing ioremap_cache() introduce arch_memremap()
for ia64.  Given that ia64 does not allow external control for caching
types, this simply aliases arch_memremap() with the ia64 ioremap()
implementation.

Cc: Arnd Bergmann 
Cc: Tony Luck 
Cc: Ross Zwisler 
Signed-off-by: Dan Williams 
---
 arch/ia64/Kconfig  |1 +
 arch/ia64/mm/ioremap.c |   10 ++
 2 files changed, 11 insertions(+)

diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index eb0249e37981..b39bab1da7dd 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -52,6 +52,7 @@ config IA64
select HAVE_MOD_ARCH_SPECIFIC
select MODULES_USE_ELF_RELA
select ARCH_USE_CMPXCHG_LOCKREF
+   select ARCH_HAS_MEMREMAP
select HAVE_ARCH_AUDITSYSCALL
default y
help
diff --git a/arch/ia64/mm/ioremap.c b/arch/ia64/mm/ioremap.c
index 43964cde6214..53a1faa0e5da 100644
--- a/arch/ia64/mm/ioremap.c
+++ b/arch/ia64/mm/ioremap.c
@@ -101,6 +101,16 @@ ioremap (unsigned long phys_addr, unsigned long size)
 }
 EXPORT_SYMBOL(ioremap);
 
+/*
+ * Cache mapping-type is determined internal to ioremap and can't be
+ * externally specified
+ */
+void *arch_memremap(resource_size_t offset, size_t size, unsigned long flags)
+{
+   return (void __force *) ioremap(offset, size);
+}
+EXPORT_SYMBOL(arch_memremap);
+
 void __iomem *
 ioremap_nocache (unsigned long phys_addr, unsigned long size)
 {

--
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 02/20] arm: introduce arch_memremap()

[Dan Williams]

In preparation for removing ioremap_cache() introduce arch_memremap()
for arm.  For now, arch_memremap(..., MEMREMAP_WB) is an alias for
ioremap_cache().  Note that arch_memremap() is relying on memremap() to
handle remap requests to "System RAM".

Cc: Arnd Bergmann 
Cc: Russell King 
Cc: Ross Zwisler 
Signed-off-by: Dan Williams 
---
 arch/arm/Kconfig  |1 +
 arch/arm/include/asm/io.h |1 +
 arch/arm/mm/ioremap.c |   11 +++
 arch/arm/mm/nommu.c   |   10 ++
 arch/arm64/Kconfig|1 +
 arch/arm64/mm/ioremap.c   |   10 ++
 6 files changed, 34 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 72ad724c67ae..882771cfc63c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -3,6 +3,7 @@ config ARM
default y
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_ELF_RANDOMIZE
+   select ARCH_HAS_MEMREMAP
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAVE_CUSTOM_GPIO_H
select ARCH_HAS_GCOV_PROFILE_ALL
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 485982084fe9..ca76d59cb6f3 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -356,6 +356,7 @@ static inline void memcpy_toio(volatile void __iomem *to, 
const void *from,
  * ioremap()   Device  n/a n/a
  * ioremap_nocache()   Device  n/a n/a
  * ioremap_cache() Normal  Writeback   Read allocate
+ * memremap(WB)Normal  Writeback   Read allocate
  * ioremap_wc()Normal  Non-cacheable   n/a
  * ioremap_wt()Normal  Non-cacheable   n/a
  *
diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index 0c81056c1dd7..f6249b98ed16 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -385,6 +385,17 @@ void __iomem *ioremap_cache(resource_size_t res_cookie, 
size_t size)
 }
 EXPORT_SYMBOL(ioremap_cache);
 
+void *arch_memremap(resource_size_t res_cookie, size_t size,
+   unsigned long flags)
+{
+   if ((flags & MEMREMAP_WB) == 0)
+   return NULL;
+
+   return (void __force *) arch_ioremap_caller(res_cookie, size,
+   MT_DEVICE_CACHED, __builtin_return_address(0));
+}
+EXPORT_SYMBOL(arch_memremap);
+
 void __iomem *ioremap_wc(resource_size_t res_cookie, size_t size)
 {
return arch_ioremap_caller(res_cookie, size, MT_DEVICE_WC,
diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index 1dd10936d68d..d88353e1fe80 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -373,6 +373,16 @@ void __iomem *ioremap_cache(resource_size_t res_cookie, 
size_t size)
 }
 EXPORT_SYMBOL(ioremap_cache);
 
+void *arch_memremap(resource_size_t res_cookie, size_t size, unsigned long 
flags)
+{
+   if ((flags & MEMREMAP_WB) == 0)
+   return NULL;
+
+   return (void __force *) __arm_ioremap_caller(res_cookie, size,
+   MT_DEVICE_CACHED, __builtin_return_address(0));
+}
+EXPORT_SYMBOL(arch_memremap);
+
 void __iomem *ioremap_wc(resource_size_t res_cookie, size_t size)
 {
return __arm_ioremap_caller(res_cookie, size, MT_DEVICE_WC,
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 07d1811aa03f..54ea0688586f 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -6,6 +6,7 @@ config ARM64
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_GCOV_PROFILE_ALL
+   select ARCH_HAS_MEMREMAP
select ARCH_HAS_SG_CHAIN
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_USE_CMPXCHG_LOCKREF
diff --git a/arch/arm64/mm/ioremap.c b/arch/arm64/mm/ioremap.c
index 01e88c8bcab0..9db5a12654a0 100644
--- a/arch/arm64/mm/ioremap.c
+++ b/arch/arm64/mm/ioremap.c
@@ -104,6 +104,16 @@ void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t 
size)
 }
 EXPORT_SYMBOL(ioremap_cache);
 
+void *arch_memremap(phys_addr_t phys_addr, size_t size, unsigned long flags)
+{
+   if ((flags & MEMREMAP_WB) == 0)
+   return NULL;
+
+   return (void __force *) __ioremap_caller(phys_addr, size,
+   __pgprot(PROT_NORMAL), __builtin_return_address(0));
+}
+EXPORT_SYMBOL(arch_memremap);
+
 /*
  * Must be called after early_fixmap_init
  */

--
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] PCI/MSI: Export all remapped MSIs to sysfs attributes

[Bjorn Helgaas]

[+cc Neil, Thomas, linux-kernel]

Hi Romain,

On Thu, Sep 24, 2015 at 01:31:16AM +0200, Romain Bezut wrote:
> irqbalance uses these attributes to populate its internal database, which is
> then used to bind the irq on the appropriate NUMA node.
> 
> On a device accepting multiple MSIs and with interrupt remapping enabled,
> only the first irq entry is exported to msi_irqs directory.
> This results in irqbalance having no clue of the NUMA affinity for the extra
> irqs and starting to bind them on random nodes.
> 
> This patch exports all MSI interrupts as sysfs attributes when relevant.
> 
> Signed-off-by: Romain Bezut 

This seems like it makes sense to me.  Do you have any bug reports
related to this problem?  If so, I'll mention them in the changelog.

Added Neil, Thomas, and linux-kernel since this is of interest to folks
beyond the usual linux-pci audience.

> ---
>  drivers/pci/msi.c | 31 +--
>  1 file changed, 17 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index d449714..324a164 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -475,10 +475,11 @@ static int populate_msi_sysfs(struct pci_dev *pdev)
>   int ret = -ENOMEM;
>   int num_msi = 0;
>   int count = 0;
> + int i;
>  
>   /* Determine how many msi entries we have */
>   for_each_pci_msi_entry(entry, pdev)
> - ++num_msi;
> + num_msi += entry->nvec_used;
>   if (!num_msi)
>   return 0;
>  
> @@ -487,19 +488,21 @@ static int populate_msi_sysfs(struct pci_dev *pdev)
>   if (!msi_attrs)
>   return -ENOMEM;
>   for_each_pci_msi_entry(entry, pdev) {
> - msi_dev_attr = kzalloc(sizeof(*msi_dev_attr), GFP_KERNEL);
> - if (!msi_dev_attr)
> - goto error_attrs;
> - msi_attrs[count] = _dev_attr->attr;
> -
> - sysfs_attr_init(_dev_attr->attr);
> - msi_dev_attr->attr.name = kasprintf(GFP_KERNEL, "%d",
> - entry->irq);
> - if (!msi_dev_attr->attr.name)
> - goto error_attrs;
> - msi_dev_attr->attr.mode = S_IRUGO;
> - msi_dev_attr->show = msi_mode_show;
> - ++count;
> + for (i = 0; i < entry->nvec_used; i++) {
> + msi_dev_attr = kzalloc(sizeof(*msi_dev_attr), 
> GFP_KERNEL);
> + if (!msi_dev_attr)
> + goto error_attrs;
> + msi_attrs[count] = _dev_attr->attr;
> +
> + sysfs_attr_init(_dev_attr->attr);
> + msi_dev_attr->attr.name = kasprintf(GFP_KERNEL, "%d",
> + entry->irq + i);
> + if (!msi_dev_attr->attr.name)
> + goto error_attrs;
> + msi_dev_attr->attr.mode = S_IRUGO;
> + msi_dev_attr->show = msi_mode_show;
> + ++count;
> + }
>   }
>  
>   msi_irq_group = kzalloc(sizeof(*msi_irq_group), GFP_KERNEL);
> -- 
> 2.4.9
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" 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 2/2] ext2: Add locking for DAX faults

[Ross Zwisler]

On Fri, Oct 09, 2015 at 03:18:11PM -0700, Dan Williams wrote:
> On Fri, Oct 9, 2015 at 3:02 PM, Ross Zwisler
>  wrote:
> > Add locking to ensure that DAX faults are isolated from ext2 operations
> > that modify the data blocks allocation for an inode.  This is intended to
> > be analogous to the work being done in XFS by Dave Chinner:
> >
> > http://www.spinics.net/lists/linux-fsdevel/msg90260.html
> >
> > Compared with XFS the ext2 case is greatly simplified by the fact that ext2
> > already allocates and zeros new blocks before they are returned as part of
> > ext2_get_block(), so DAX doesn't need to worry about getting unmapped or
> > unwritten buffer heads.
> >
> > This means that the only work we need to do in ext2 is to isolate the DAX
> > faults from inode block allocation changes.  I believe this just means that
> > we need to isolate the DAX faults from truncate operations.
> >
> > The newly introduced dax_sem is intended to replicate the protection
> > offered by i_mmaplock in XFS.  In addition to truncate the i_mmaplock also
> > protects XFS operations like hole punching, fallocate down, extent
> > manipulation IOCTLS like xfs_ioc_space() and extent swapping.  Truncate is
> > the only one of these operations supported by ext2.
> >
> > Signed-off-by: Ross Zwisler 
> [..]
> 
> ...not a review of the ext2 changes.
> 
> > diff --git a/fs/ext2/inode.c b/fs/ext2/inode.c
> > index c60a248..2b974fc 100644
> > --- a/fs/ext2/inode.c
> > +++ b/fs/ext2/inode.c
> > @@ -1085,6 +1085,7 @@ static void ext2_free_branches(struct inode *inode, 
> > __le32 *p, __le32 *q, int de
> > ext2_free_data(inode, p, q);
> >  }
> >
> > +/* dax_sem must be held when calling this function */
> >  static void __ext2_truncate_blocks(struct inode *inode, loff_t offset)
> >  {
> 
> How about  a "WARN_ON(!rwsem_is_locked(>dax_sem));" to backstop
> this assumption?

Yep, sounds like a good idea.  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: [lkp] [ACPI] 7494b07eba: Kernel panic - not syncing: Watchdog detected hard LOCKUP on cpu 0

[Rafael J. Wysocki]

On Thursday, October 08, 2015 05:05:00 PM Al Stone wrote:
> On 10/08/2015 04:50 PM, Rafael J. Wysocki wrote:
> > On Thursday, October 08, 2015 02:32:15 PM Al Stone wrote:
> >> On 10/08/2015 02:41 PM, Rafael J. Wysocki wrote:
> >>> On Thursday, October 08, 2015 10:37:55 PM Rafael J. Wysocki wrote:
>  On Thursday, October 08, 2015 10:36:40 AM Al Stone wrote:
> > On 10/08/2015 05:44 AM, Hanjun Guo wrote:
> >> On 10/08/2015 11:21 AM, kernel test robot wrote:
> >>> FYI, we noticed the below changes on
> >>>
> >>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git 
> >>> master
> >>> commit 7494b07ebaae2117629024369365f7be7adc16c3 ("ACPI: add in a
> >>> bad_madt_entry() function to eventually replace the macro")
> >>>
> >>> [0.00] ACPI: undefined MADT subtable type for FADT 4.0: 127 
> >>> (length 12)
> >>
> >> Seems that the MADT table contains reserved subtable type (0x7F),
> >> so this is traded as a wrong type in our patch.
> >>
> >>> [0.00] ACPI: Error parsing LAPIC address override entry
> >>
> >> This was called by early_acpi_parse_madt_lapic_addr_ovr() in
> >> arch/x86/kernel/acpi/boot.c, which is scanning MADT for the first
> >> time when booting, so it will fail the boot process when finding
> >> the reserved MADT subtable type.
> >>
> >>> [0.00] ACPI: Invalid BIOS MADT, disabling ACPI
> >>
> >> As the spec said in Table 5-46 (ACPI 6.0):
> >>
> >> 0x10-0x7F Reserved. OSPM skips structures of the reserved type.
> >>
> >> Should we just ignore those reserved type when scanning the MADT
> >> table? In the patch "ACPI: add in a bad_madt_entry() function to
> >> eventually replace the macro", we just trade it as wrong, that's
> >> why we failed to boot the system.
> >>
> >> Thanks
> >> Hanjun
> >
> > Arrgh.  This is why people get frustrated with ACPI.  The spec is
> > saying that those sub-table types are reserved -- implying they can
> > and probably will be used for something else in the future -- but
> > then vendors are shipping firmware that uses those reserved values,
> > and an OS *expects* them to be used, and there is *no* documentation
> > of it other than a kernel workaround.
> >
> > So yet again, technically this MADT subtable *is* wrong, and someone
> > should slap the vendor for doing this.  But, the practical side of
> > this is that we now have to workaround what is now a known violation
> > of the spec.
> >
> > The more ACPI allows this kind of nonsense, the less usable it will
> > become.
> 
>  Linux Kernel Developer's First Rule: You shall not break setups that
>  worked previously, even if they worked by accident.
> 
>  IOW, if something booted and your commit made it not boot any more, it 
>  counts
>  as a regression and needs to be modified or reverted.
> >>>
> >>> Moreover, if the firmware in question shipped in a product, we have no 
> >>> choice
> >>> but to work around bugs in it.  Doing otherwise would be refusing to 
> >>> support
> >>> our users and not the vendor of the systems they were unfortunate enough 
> >>> to
> >>> acquire.
> >>>
> >>> Thanks,
> >>> Rafael
> >>>
> >>
> >> Yup, understood and agreed.  I have no issue at all with the First Rule.
> >>
> >> What I have an issue with is all the exceptions to the standards -- and
> >> primarily the unknown ones -- that exist with ACPI (or any other standard,
> >> mind you), independent of any OS.
> > 
> > Well, one can argue that stadards are not what is written in specifications,
> > but what is done in practice by everybody.  If a specification does not 
> > agree
> > with the common practice, there is a problem with it, not with the practice.
> 
> True.  That is the other side of it.  How rampant is this particular problem,
> though?  Does everyone and their uncle use some reserved MADT subtable ID 
> value
> in their firmware?  This is the first time I've personally seen this, but then
> I haven't been looking for it until now.

Well, that depends on whether or not the OS the firmware was tested against
contained checks that would catch the problem and make it complain.  We don't
have them without your patch, but do other OSes have them?  If they don't
either, quite a lot of stuff like that may be expected to have gone to users.

It only takes one reference firmware containing bugs like those to make them
quite widespread.

> >> It's just like driving a car.  I will (and do) grumble at people when they
> >> break the rules.  On the other hand, I'm not going to crash into them even
> >> if they are at fault.  When the ACPI spec gets twisted around, I'm going
> >> to say something about it; just the same, I am not going to break their
> >> system if it already works.
> > 
> > OK
> > 
> > So IMO there are two things we can do.  First, try to update the 

Re: [PATCH v7 0/4] perf: add support for profiling jitted code

[Brendan Gregg]

On Sun, Oct 4, 2015 at 1:05 PM, Stephane Eranian  wrote:
>
> Brendan,
>
> On Thu, Oct 1, 2015 at 3:45 PM, Brendan Gregg  
> wrote:
> > G'Day,
> >
> > On Wed, Sep 30, 2015 at 11:45 PM, Stephane Eranian  
> > wrote:
> >>
> >> This patch series extends perf record/report/annotate to enable
> >> profiling of jitted (just-in-time compiled) code. The current
> >> perf tool provides very limited support for profiling jitted
> >> code for some runtime environments. But the support is experimental
> >> and cannot be used in complex environments. It relies on files
> >> in /tmp, for instance. It does not support annotate mode or
> >> rejitted code.
> >>
> >> This patch series adds a better way of profiling jitted code
> >> with the following advantages:
> >>- support any jitted code environment (some with modifications)
> >>- support Java runtime with JVMTI interface with no modifications
> >>- provides a portable JVMTI agent library
> >>- known to support V8 runtime
> >>- known to support DART runtime
> >>- supports code rejitting and code movements
> >>- no files in /tmp
> >>- meta-data file is unique to each run
> >>- no changes to perf report/annotate
> >>- support per-thread and system-wide profiling
> >>- support monitoring of multiple simultaneous Jit runtimes
> >>- source level view in perf annotate
> >>
> >> The support is based on cooperation with the runtime. For Java runtimes,
> >> supporting the JVMTI interface, there is no change necessary. For other
> >> runtimes, modifications are necessary to emit the meta-data to support
> >> symbolization, annotation, source lines correlation of the samples.
> >> Those modifications are relatively straighforward, some have been
> >> implemented in V8 and DART.
> >>
> >> The jit environment emits a binary dump file which contains the jitted
> >> code (in raw format) and meta-data describing the mapping of functions.
> >> The binary format is documented in the jitdump.h header file. It is
> >> adapted from the OProfile jitdump format.
> >
> > While this is impressive work, I don't think I'd use it very much, and
> > I wouldn't encourage others too either. Is it right that this approach
> > needs to be turned on from runtime start, and will constantly emit
> > timestamped JIT records? I'd use that as a backup for existing
> > techniques for perf_events and jitted runtimes.
> >
> This boils down that when does the JIT runtime emit the jitdump data?
> In the case of openJDK and given how I wrote the agent, it needs to
> run from start to finish.  In order for perf to have full visibility, it needs
> to get info about all the code that has been jitted so far. This could be
> done after start if there was somehow a protocol to handle this in the
> runtime, like a signal. It would just need to dump the current status, 
> including
> all the code. The rest of the  support would work. In other words, if there 
> was
> a way to signal to the runtime that it is being monitored and that it needs to
> dump its state, then everything would work. To avoid generating more dumps,
> the runtime would also have to be informed that monitoring has stopped.


Ok, so it's possible that an on-demand approach could work, if the
agent can be modified. And since perf-map-agent made this transition
(https://github.com/jrudolph/perf-map-agent), examples of how to do
this are probably in its git history. :) The outcome could well be
something like:

perf record -F 99 -a -g -- perf_java_agent --sleep 10

Where a perf_java_agent tool attached to all Javas, dumped initial
symbols, and then logged timestamped symbols during the run (--sleep
10), then detached at the end. That would be ideal. Which just means
changing the Java agent, not the perf implementation.

Brendan
--
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/7][v4] Add OTG support for FSL socs

[Felipe Balbi]

Felipe Balbi  writes:

> Hi,
>
> Ramneek Mehresh  writes:
>> Add support for otg for all freescale socs having internal
>> usb phy.
>>
>> Ramneek Mehresh (7):
>>   usb:fsl:otg: Make fsl otg driver as tristate
>>   usb:fsl:otg: Add controller version based ULPI and UTMI phy
>>   usb:fsl:otg: Add support to add/remove usb host driver
>>   usb:fsl:otg: Signal host drv when host is otg
>>   usb:fsl:otg: Modify otg_event to start host drv
>>   usb:fsl:otg: Combine host/gadget start/resume for ID change
>>   usb:fsl:otg: Add host-gadget drv sync delay
>
> Unless Alan's okay with the host side changes, I can't accept any of
> these. However, I must say some of the flags you add here already exist
> in some way, shape or form. For example, look at is_b_host flag.

Just saw Alan's reply, still, please have a look at these other flags
which already exist in usbcore today.

-- 
balbi


signature.asc
Description: PGP signature

RE: [PATCH][RFC] mm: Introduce kernelcore=reliable option

[Luck, Tony]

> I remember Kame has already suggested this idea. In my opinion,
> I still think it's better to add a new migratetype or a new zone,
> so both user and kernel could use mirrored memory.

A new zone would be more flexible ... and probably the right long
term solution.  But this looks like a very clever was to try out the
feature with a minimally invasive patch.

-Tony
--
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 13/16] perf callchain: Switch default to 'graph,0.5,caller'

[Arnaldo Carvalho de Melo]

Em Fri, Oct 09, 2015 at 01:34:33PM -0700, Brendan Gregg escreveu:
> On Mon, Oct 5, 2015 at 2:03 PM, Arnaldo Carvalho de Melo
>  wrote:
> >
> > From: Arnaldo Carvalho de Melo 
> >
> > Which is the most common default found in other similar tools.
> 
> Interactive tools, sure, like the perf report TUI.
 
> But this also changes the ordering of the non-interactive tools which
> dump stacks: "perf report -n --stdio" and "perf script". The most
> common default for dumping stacks is caller. Eg:

And you use that for scripting?
 
> # perf report -n --stdio
> [...]
> 16.87%334   iperf  [kernel.kallsyms] [k] 
> copy_user_enhanced_fast_string
>  |
>  --- 0x7f0683ba1ccd
>  system_call_fastpath
>  sys_write
>  vfs_write
>  do_sync_write
>  sock_aio_write
>  do_sock_write.isra.10
>  inet_sendmsg
>  copy_user_enhanced_fast_string
> [...]
> 
> That's upside down. The current default preserves ordering from the
> informational line onwards:
> 
> # perf report -n --stdio -g fractal,0.5,callee
> [...]
> 16.87%334   iperf  [kernel.kallsyms] [k] 
> copy_user_enhanced_fast_string
>  |
>  --- copy_user_enhanced_fast_string
> |
> |--64.37%-- inet_sendmsg
> |  do_sock_write.isra.10
> |  sock_aio_write
> |  do_sync_write
> |  vfs_write
> |  sys_write
> |  system_call_fastpath
> |  0x7f0683ba1ccd
> 
> ... Those are just short examples. Another profile I'm working on now
> gets really messy on "perf report -n --stdio"; eg:
> 
> perf report -n --stdio -g graph,0.5,caller
> 94.80% 0.10% 2  iperf [kernel.vmlinux][k]
> entry_SYSCALL_64_fastpath
>|
>|--94.70%-- entry_SYSCALL_64_fastpath
>|  |

> 
> The current default never gets beyond 5 levels deep. The new default
> goes to 25 levels. At least with perf report I can override the
> default using "-g". perf script doesn't support that.

Ok, so changing defaults is not nice, but in this case looked sensible,
ends up not being for you...
 
> Can this patch please preserve the callee ordering for non-interactive
> output? (perf script, perf report -n --stdio). Thanks,

If this is because you do scripting on it? Wouldn't it be better to not
depend on defaults, always specify what you want and then the bug would
be constrained to 'perf script' where we need to provide a way to change
the default?

- Arnaldo
--
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 2/7] MAINTAINERS: Add myself for the new VC4 (RPi GPU) graphics driver.

[Eric Anholt]

Emil Velikov  writes:

> Hi Eric,
>
> On 9 October 2015 at 22:27, Eric Anholt  wrote:
>> Signed-off-by: Eric Anholt 
>> ---
>>
>> v2: Mark it Supported, not Maintained.
>>
>>  MAINTAINERS | 6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 7ba7ab7..e331e46 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -3653,6 +3653,12 @@ S:   Maintained
>>  F: drivers/gpu/drm/sti
>>  F: Documentation/devicetree/bindings/gpu/st,stih4xx.txt
>>
>> +DRM DRIVERS FOR VC4
>> +M: Eric Anholt 
>> +T: git git://github.com/anholt/linux
> You might want to add dri-devel as mailing list, at least initially.

I believe that's already implied by the general entry for dri-devel:

./scripts/get_maintainer.pl -f drivers/gpu/drm/vc4/vc4_drv.c
Eric Anholt  (supporter:DRM DRIVERS FOR VC4)
David Airlie  (maintainer:DRM DRIVERS)
dri-de...@lists.freedesktop.org (open list:DRM DRIVERS)


signature.asc
Description: PGP signature

[PATCH 01/14] cgroup: remove an unused parameter from cgroup_task_migrate()

[Tejun Heo]

cgroup_task_migrate() no longer uses @old_cgrp.  Remove it.

Signed-off-by: Tejun Heo 
---
 kernel/cgroup.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index ae23814..49f30f1 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2235,14 +2235,12 @@ struct task_struct *cgroup_taskset_next(struct 
cgroup_taskset *tset)
 
 /**
  * cgroup_task_migrate - move a task from one cgroup to another.
- * @old_cgrp: the cgroup @tsk is being migrated from
  * @tsk: the task being migrated
  * @new_cset: the new css_set @tsk is being attached to
  *
  * Must be called with cgroup_mutex, threadgroup and css_set_rwsem locked.
  */
-static void cgroup_task_migrate(struct cgroup *old_cgrp,
-   struct task_struct *tsk,
+static void cgroup_task_migrate(struct task_struct *tsk,
struct css_set *new_cset)
 {
struct css_set *old_cset;
@@ -2311,8 +2309,7 @@ static int cgroup_taskset_migrate(struct cgroup_taskset 
*tset,
down_write(_set_rwsem);
list_for_each_entry(cset, >src_csets, mg_node) {
list_for_each_entry_safe(task, tmp_task, >mg_tasks, 
cg_list)
-   cgroup_task_migrate(cset->mg_src_cgrp, task,
-   cset->mg_dst_cset);
+   cgroup_task_migrate(task, cset->mg_dst_cset);
}
up_write(_set_rwsem);
 
-- 
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/

[PATCHSET cgroup/for-4.4] cgroup: make zombies retain cgroup membership and fix pids controller

[Tejun Heo]

Hello,

cgroup currently disassociates a task from its cgroups on exit and
reassigns it to the root cgroup.  This behavior turns out to be
problematic for several reasons.

* Resources can't be tracked for zombies.  This breaks pids controller
  as zombies escape resource restriction.  A cgroup can easily go way
  above its limits by creating a bunch of zombies.

* It's difficult to tell where zombies came from.  /proc/PID/cgroup
  gets reset to / on exit so given a zombie it's difficult to tell
  from which cgroup the zombie came from.

* It creates an extra work for controllers for no reason.  cpu and
  perf_events controllers implement exit callbacks to switch the
  exiting task's membership to root when just leaving it as-is is
  enough.

Unfortunately, fixing this involves opening a few cans of worms.

* Decoupling tasks being on a css_set from its reference counting so
  that css_set can be pinned w/o tasks being on it and decoupling
  css_set existence from whether a cgroup is populated so that pinning
  a css_set doesn't confuse populated state tracking and populated
  state can be used to decide whether certain operations are allowed.

* Making css task iteration drop css_set_rwsem between iteration steps
  so that internal locking is not exposed to iterator users and
  css_set_rwsem can be converted to a spinlock which can be grabbed
  from task free path.

After this patchset, besides pids controller being fixed, the visible
behavior isn't changed on traditional hierarchies but on the default
hierarchy a zombie reports its cgroup at the time of exit in
/proc/PID/cgroup.  If the cgroup gets removed before the task is
reaped, " (deleted)" is appended to the reported path.

This patchset contains the following 14 patches.

 0001-cgroup-remove-an-unused-parameter-from-cgroup_task_m.patch
 0002-cgroup-make-cgroup-nr_populated-count-the-number-of-.patch
 0003-cgroup-replace-cgroup_has_tasks-with-cgroup_is_popul.patch
 0004-cgroup-move-check_for_release-invocation.patch
 0005-cgroup-relocate-cgroup_-try-get-put.patch
 0006-cgroup-make-css_sets-pin-the-associated-cgroups.patch
 0007-cgroup-make-cgroup_destroy_locked-test-cgroup_is_pop.patch
 0008-cgroup-keep-css_set-and-task-lists-in-chronological-.patch
 0009-cgroup-factor-out-css_set_move_task.patch
 0010-cgroup-reorganize-css_task_iter-functions.patch
 0011-cgroup-don-t-hold-css_set_rwsem-across-css-task-iter.patch
 0012-cgroup-make-css_set_rwsem-a-spinlock-and-rename-it-t.patch
 0013-cgroup-keep-zombies-associated-with-their-original-c.patch
 0014-cgroup-add-cgroup_subsys-free-method-and-use-it-to-f.patch

0001-0007 decouple populated state tracking from css_set existence and
allows css_sets to be pinned without tasks on them.

0008-0012 update css_set task iterator to not hold lock across
iteration steps and replace css_set_rwsem with a spinlock.

0013 makes zombies keep their cgroup associations.  0014 introduces
->exit() method and fixes pids controller.

The patchset is pretty lightly tested and I need to verify that the
corner cases behave as expected.

This patchset is on top of cgroup/for-4.4 a3e72739b7a7 ("cgroup: fix
too early usage of static_branch_disable()") and available in the
following git branch.

 git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git review-zombies

diffstat follows.  Thanks.

 Documentation/cgroups/cgroups.txt   |4 
 Documentation/cgroups/unified-hierarchy.txt |4 
 include/linux/cgroup-defs.h |   16 
 include/linux/cgroup.h  |   14 
 kernel/cgroup.c |  522 +---
 kernel/cgroup_pids.c|8 
 kernel/cpuset.c |2 
 kernel/events/core.c|   16 
 kernel/fork.c   |1 
 kernel/sched/core.c |   16 
 mm/memcontrol.c |2 
 11 files changed, 354 insertions(+), 251 deletions(-)

--
tejun
--
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 02/14] cgroup: make cgroup->nr_populated count the number of populated css_sets

[Tejun Heo]

Currently, cgroup->nr_populated counts whether the cgroup has any
css_sets linked to it and the number of children which has non-zero
->nr_populated.  This works because a css_set's refcnt converges with
the number of tasks linked to it and thus there's no css_set linked to
a cgroup if it doesn't have any live tasks.

To help tracking resource usage of zombie tasks, putting the ref of
css_set will be separated from disassociating the task from the
css_set which means that a cgroup may have css_sets linked to it even
when it doesn't have any live tasks.

This patch updates cgroup->nr_populated so that for the cgroup itself
it counts the number of css_sets which have tasks associated with them
so that empty css_sets don't skew the populated test.

Signed-off-by: Tejun Heo 
---
 include/linux/cgroup-defs.h |  8 +++---
 kernel/cgroup.c | 65 -
 2 files changed, 56 insertions(+), 17 deletions(-)

diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h
index df589a0..1744450 100644
--- a/include/linux/cgroup-defs.h
+++ b/include/linux/cgroup-defs.h
@@ -232,10 +232,10 @@ struct cgroup {
int id;
 
/*
-* If this cgroup contains any tasks, it contributes one to
-* populated_cnt.  All children with non-zero popuplated_cnt of
-* their own contribute one.  The count is zero iff there's no task
-* in this cgroup or its subtree.
+* Each non-empty css_set associated with this cgroup contributes
+* one to populated_cnt.  All children with non-zero popuplated_cnt
+* of their own contribute one.  The count is zero iff there's no
+* task in this cgroup or its subtree.
 */
int populated_cnt;
 
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 49f30f1..e5231d0 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -582,14 +582,25 @@ struct css_set init_css_set = {
 static int css_set_count   = 1;/* 1 for init_css_set */
 
 /**
+ * css_set_populated - does a css_set contain any tasks?
+ * @cset: target css_set
+ */
+static bool css_set_populated(struct css_set *cset)
+{
+   lockdep_assert_held(_set_rwsem);
+
+   return !list_empty(>tasks) || !list_empty(>mg_tasks);
+}
+
+/**
  * cgroup_update_populated - updated populated count of a cgroup
  * @cgrp: the target cgroup
  * @populated: inc or dec populated count
  *
- * @cgrp is either getting the first task (css_set) or losing the last.
- * Update @cgrp->populated_cnt accordingly.  The count is propagated
- * towards root so that a given cgroup's populated_cnt is zero iff the
- * cgroup and all its descendants are empty.
+ * One of the css_sets associated with @cgrp is either getting its first
+ * task or losing the last.  Update @cgrp->populated_cnt accordingly.  The
+ * count is propagated towards root so that a given cgroup's populated_cnt
+ * is zero iff the cgroup and all its descendants don't contain any tasks.
  *
  * @cgrp's interface file "cgroup.populated" is zero if
  * @cgrp->populated_cnt is zero and 1 otherwise.  When @cgrp->populated_cnt
@@ -618,6 +629,24 @@ static void cgroup_update_populated(struct cgroup *cgrp, 
bool populated)
} while (cgrp);
 }
 
+/**
+ * css_set_update_populated - update populated state of a css_set
+ * @cset: target css_set
+ * @populated: whether @cset is populated or depopulated
+ *
+ * @cset is either getting the first task or losing the last.  Update the
+ * ->populated_cnt of all associated cgroups accordingly.
+ */
+static void css_set_update_populated(struct css_set *cset, bool populated)
+{
+   struct cgrp_cset_link *link;
+
+   lockdep_assert_held(_set_rwsem);
+
+   list_for_each_entry(link, >cgrp_links, cgrp_link)
+   cgroup_update_populated(link->cgrp, populated);
+}
+
 /*
  * hash table for cgroup groups. This improves the performance to find
  * an existing css_set. This hash doesn't (currently) take into
@@ -663,10 +692,8 @@ static void put_css_set_locked(struct css_set *cset)
list_del(>cgrp_link);
 
/* @cgrp can't go away while we're holding css_set_rwsem */
-   if (list_empty(>cset_links)) {
-   cgroup_update_populated(cgrp, false);
+   if (list_empty(>cset_links))
check_for_release(cgrp);
-   }
 
kfree(link);
}
@@ -875,8 +902,6 @@ static void link_css_set(struct list_head *tmp_links, 
struct css_set *cset,
link->cset = cset;
link->cgrp = cgrp;
 
-   if (list_empty(>cset_links))
-   cgroup_update_populated(cgrp, true);
list_move(>cset_link, >cset_links);
 
/*
@@ -1754,6 +1779,8 @@ static void cgroup_enable_task_cg_lists(void)
if (!(p->flags & PF_EXITING)) {
struct css_set *cset = task_css_set(p);
 
+   if (!css_set_populated(cset))
+ 

[PATCH 04/14] cgroup: move check_for_release() invocation

[Tejun Heo]

To trigger release agent when the last task leaves the cgroup,
check_for_release() is called from put_css_set_locked(); however,
css_set being unlinked is being decoupled from task leaving the cgroup
and the correct condition to test is cgroup->nr_populated dropping to
zero which check_for_release() is already updated to test.

This patch moves check_for_release() invocation from
put_css_set_locked() to cgroup_update_populated().

Signed-off-by: Tejun Heo 
---
 kernel/cgroup.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 435aa68..855313d 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -623,6 +623,7 @@ static void cgroup_update_populated(struct cgroup *cgrp, 
bool populated)
if (!trigger)
break;
 
+   check_for_release(cgrp);
cgroup_file_notify(>events_file);
 
cgrp = cgroup_parent(cgrp);
@@ -686,15 +687,8 @@ static void put_css_set_locked(struct css_set *cset)
css_set_count--;
 
list_for_each_entry_safe(link, tmp_link, >cgrp_links, cgrp_link) {
-   struct cgroup *cgrp = link->cgrp;
-
list_del(>cset_link);
list_del(>cgrp_link);
-
-   /* @cgrp can't go away while we're holding css_set_rwsem */
-   if (list_empty(>cset_links))
-   check_for_release(cgrp);
-
kfree(link);
}
 
-- 
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: pidns: Make pid accounting and pid_max per namespace

[Zhang Haoyu]

On 10/10/15 11:35, Zefan Li wrote:
> On 2015/10/9 18:29, Zhang Haoyu wrote:
>> I started multiple docker containers in centos6.6(linux-2.6.32-504.16.2),
>> and there's one bad program was running in one container.
>> This program produced many child threads continuously without free, so more 
>> and
>> more pid numbers were consumed by this program, until hitting the pix_max 
>> limit (32768
>> default in my system ).
>>
>> What's worse is that containers and host share the pid numbers resource, so 
>> new program
>> cannot be produced any more in host and other containers.
>>
>> And, I clone the upstream kernel source from
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>> This problem is still there, I'm not sure.
>>
>> IMO, we should isolate the pid accounting and pid_max between pid namespaces,
>> and make them per pidns.
>> Below post had request for making pid_max per pidns.
>> http://thread.gmane.org/gmane.linux.kernel/1108167/focus=210
>>
>
> Mainline kernel already supports per-cgroup pid limit, which should solve
> your problem.
>
What about pid accounting?
If one pidns consume too many pids, dose it influence the other pid namespaces?

Thanks,
Zhang Haoyu

--
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] Linux PID algorithm is BRAINDEAD!

[yalin wang]

> On Oct 10, 2015, at 10:00, Dave Goel  wrote:
> 
> Pardon the subject line!  I think the PID algo. is actually pretty
> good and cheap.
> 
> 
> I just think that a very minor tweak could actually make it *actually* do
> what it always intended to do (that is, satisfy the PID-AIM listed below)!
> No expanded PID renumbering, no incompatibility introduction, nothing, just
> a relatively *minor tweak*.
> 
> 
> *** QUICK SUMMARY:
> 
> 
> PROBLEM:  PID gets re-used immediately as soon as it is freed.
> 
> EXAMPLE: My program with PID 1323 uses temporary files that are of the form
> PID-. It finishes in two days By this time, linux has circled
> PIDs back around five times. And, the counter happens to be right at 1323
> right as the program finishes. As soon as the PID is freed, Linux thus
> re-uses the PID 1323. A trash-cleaner program (I know, I know) gets
> confused. 1323 exited uncleanly. The cleaner sees no 1323 running. It then
> proceeds to delete the temp files. But, by that time, the kernel started
> another 1323 which happens to use the very files. The cleaner ends up
> deleting files for the wrong, running program!
> 
> This is just one example. There are many more examples of race conditions.
> 
> 
> 
> A TINY TWEAK AS SOLUTION:
> 
> The kernel already tries to do the right thing. The only minor tweak needed
> is that:
> 
> ***When Linux Re-Uses A Pid, It Uses The Pid That Has Been Free For
> The Longest.***
> 
> That's it!
> 
> 
> RESULT:
> 
> All PID-related race conditions are eliminated, period. No "good enough"
> hacks needed any more by utilities trying to avoid race conditions. A
> freshly freed PID will never get re-used immediately any more . No more race
> conditions. (The only time you will ever see an immediate re-use any more is
> when your machine actually has 32767(!)  or (2^22-1) processes!  And, by
> that time, you have FAR bigger problems.)
> 
> 
> 
> 
> 
>  DETAILS:
> 
> 
> You don't have to google very much to see the 1000 algos and other bashisms
> that exist to avoid the very race condition. For example, when you want to
> read a PID list and deleting temporary files based on a PID. The concern
> is that Linux might have created a new process with the same PID by the
> time you read the file-list.  We could argue endlessly that these bashisms
> are stupid and there are better ways. But, it seems to me that these better
> ways are not foolproof either; they are themselves hacks. And, a very simple
> tweak could alleviate 100% of these problems.
> 
> Now, 32768, or even 2^22 are actually very small numbers. OTOH, 2^200 is
> not. In an ideal world, the PID would just sample from the 2^200 space and
> declare that there will never be PID re-use or conflicts, period. If there's
> a 32-bit limit, it could use multiple bytes and still use a 2^200 space,
> etc.  But, all that would be a drastic change, which is why we are stuck
> with the 2^15 space.
> 
> Is there a way to continue using the 2^15 (or 2^22) space, but more
> reasonably?
> 
> I argue that the kernel already tries to satisfy a "PID-AIM" and already
> tries to Do The Right Thing, but there's just a tiny thinko in its current
> implementation that's easily corrected.
> 
> 
> PID-AIM:
> "No immediate re-use." The aim is to NOT immediately re-use a PID right
> after it's been freed.  I argue that this aim can easily be satisfied, even
> within the limited 2^15 space.
> 
> 
> CURRENT IMPLEMENTATION:
> The creators had the right idea. Linux indeed tries to satisfy the PID-AIM
> condition. This is why it increments the counter even if the PID is actually
> available.
> 
> But, looping happens (within a few hours for me). And, as soon as looping
> happens, satisfying the PID-AIM goes out the window.
> 
> This tweak would ensure that immediate re-use never happens, period.
> 
> COMPLEXITY, ETC:
> 
> All that the entire system needs is one queue of free PIDs. Any time you
> need a PID, take it from the head. Any time a PID is newly freed, push it at
> the back of the queue.  That's it! The overhead seems minimal to me.
> 
> The queue is initially populated by 2-32768, of course.
> 
> In fact, we could even use a smaller queue and not even activate the
> queue-mode till it is actually necessary; we could use various optimizing
> conditions and shortcuts, say, to push PIDs in the queue in batches. After
> all, it's not STRICTLY necessary to maintain exactly the correct order. The
> ONLY aim we really want to satisfy is that the latest-freed PID NOT go near
> the *head* of the queue; that's all.  Also, the queue is only even needed in
> the first place until you've actually looped around.  So, tiny rescue disk
> bootups would not even need to go the queue-mode.. (unless they've been
> running many days.)
> 
> 
> (Thanks to jd_1 and _mjg on for humoring and discussing this idea when I
> presented it on ##kernel.)
> 
> 
> Dave Goel (Please CC responses.)
> --
> To unsubscribe from this list: send the line 

Re: pidns: Make pid accounting and pid_max per namespace

[Zefan Li]

On 2015/10/9 18:29, Zhang Haoyu wrote:

I started multiple docker containers in centos6.6(linux-2.6.32-504.16.2),
and there's one bad program was running in one container.
This program produced many child threads continuously without free, so more and
more pid numbers were consumed by this program, until hitting the pix_max limit 
(32768
default in my system ).

What's worse is that containers and host share the pid numbers resource, so new 
program
cannot be produced any more in host and other containers.

And, I clone the upstream kernel source from
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
This problem is still there, I'm not sure.

IMO, we should isolate the pid accounting and pid_max between pid namespaces,
and make them per pidns.
Below post had request for making pid_max per pidns.
http://thread.gmane.org/gmane.linux.kernel/1108167/focus=210



Mainline kernel already supports per-cgroup pid limit, which should solve
your problem.

--
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: CFS scheduler unfairly prefers pinned tasks

[Wanpeng Li]

Hi Paul,
On 10/8/15 4:19 PM, Mike Galbraith wrote:

On Tue, 2015-10-06 at 04:45 +0200, Mike Galbraith wrote:

On Tue, 2015-10-06 at 08:48 +1100, paul.sz...@sydney.edu.au wrote:

The Linux CFS scheduler prefers pinned tasks and unfairly
gives more CPU time to tasks that have set CPU affinity.
This effect is observed with or without CGROUP controls.

To demonstrate: on an otherwise idle machine, as some user
run several processes pinned to each CPU, one for each CPU
(as many as CPUs present in the system) e.g. for a quad-core
non-HyperThreaded machine:

   taskset -c 0 perl -e 'while(1){1}' &
   taskset -c 1 perl -e 'while(1){1}' &
   taskset -c 2 perl -e 'while(1){1}' &
   taskset -c 3 perl -e 'while(1){1}' &

and (as that same or some other user) run some without
pinning:

   perl -e 'while(1){1}' &
   perl -e 'while(1){1}' &

and use e.g.   top   to observe that the pinned processes get
more CPU time than "fair".


Interesting, I can reproduce it w/ your simple script. However, they are 
fair when the number of pinned perl tasks is equal to unpinned perl 
tasks. I will dig into it more deeply.


Regards,
Wanpeng Li
--
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] thermal: exynos: fix register read in TMU

[Krzysztof Kozlowski]

W dniu 09.10.2015 o 21:07, Lukasz Majewski pisze:
> Hi Krzysztof,
> 
>> 2015-10-08 23:21 GMT+09:00 Sudip Mukherjee
>> :
>>> On Fri, Oct 02, 2015 at 08:43:52AM +0900, Krzysztof Kozlowski wrote:
 2015-10-01 23:12 GMT+09:00 Sudip Mukherjee
 :
> On Thu, Oct 01, 2015 at 10:18:57PM +0900, Krzysztof Kozlowski
> wrote:
>> 2015-10-01 20:39 GMT+09:00 Sudip Mukherjee
>> :
>>> The value of emul_con was getting overwritten if the selected
>>> soc is SOC_ARCH_EXYNOS5260. And so as a result we were
>>> reading from the wrong register in the case of
>>> SOC_ARCH_EXYNOS5260.
>>
>> How the value is overwritten if the soc is Exynos5260? I can't
>> see it (although the "else if" is still more obvious than "if"
>> but how does the description match the code?).
> The code here is:
> if (data->soc == SOC_ARCH_EXYNOS5260)
> emul_con = EXYNOS5260_EMUL_CON;
> if (data->soc == SOC_ARCH_EXYNOS5433)
> emul_con = EXYNOS5433_TMU_EMUL_CON;
> else if (data->soc == SOC_ARCH_EXYNOS7)
> emul_con = EXYNOS7_TMU_REG_EMUL_CON;
> else
> emul_con = EXYNOS_EMUL_CON;
>
> So if data->soc is SOC_ARCH_EXYNOS5260 , then emul_con becomes
> EXYNOS5260_EMUL_CON. But again for the else part it will become
> EXYNOS_EMUL_CON.

 Indeed!

 Fixes: 488c7455d74c ("thermal: exynos: Add the support for
 Exynos5433 TMU")

 Reviewed-by: Krzysztof Kozlowski 
>>>
>>> Hi Krzysztof,
>>> Who will pick this one up? I still do not see it in linux-next.
>>
>> Hi!
>>
>> I guess it is a patch for Lukasz.
>>
>> Lukasz,
>> Do you plan to pick it up or maybe this should go through samsung-soc
>> tree?
> 
> This is the only one patch, which is waiting in my queue. Since no more
> fixes available, please feel free to grab this patch to samsung-soc.
> 
> Acked-by: Lukasz Majewski 

Okay, thanks! Applied to fixes for current cycle. I'll it send later to
Kukjin (unless he picks it as well).

Best regards,
Krzysztof

--
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] soc: qcom: smd: Correct SMEM items for upper channels

[Bjorn Andersson]

Update the SMEM items for the second set of SMD channels, as these where
incorrect.

Signed-off-by: Bjorn Andersson 
---
 drivers/soc/qcom/smd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c
index 18964f1..e7fb8fa 100644
--- a/drivers/soc/qcom/smd.c
+++ b/drivers/soc/qcom/smd.c
@@ -87,8 +87,8 @@ static const struct {
.fifo_base_id = 338
},
{
-   .alloc_tbl_id = 14,
-   .info_base_id = 266,
+   .alloc_tbl_id = 266,
+   .info_base_id = 138,
.fifo_base_id = 202,
},
 };
-- 
2.3.2 (Apple Git-55)

--
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] blk-mq: fix waitqueue_active without memory barrier in block/blk-mq-tag.c

[Kosuke Tatsukawa]

Jens Axboe wrote:
> On 10/08/2015 06:35 PM, Kosuke Tatsukawa wrote:
>> blk_mq_tag_update_depth() seems to be missing a memory barrier which
>> might cause the waker to not notice the waiter and fail to send a
>> wake_up as in the following figure.
>> 
>>  blk_mq_tag_update_depth bt_get
>> 
>> if (waitqueue_active(>wait))
>> /* The CPU might reorder the test for
>> the waitqueue up here, before
>> prior writes complete */
>>  prepare_to_wait(>wait, ,
>>TASK_UNINTERRUPTIBLE);
>>  tag = __bt_get(hctx, bt, last_tag,
>>tags);
>>  /* Value set in bt_update_count not
>> visible yet */
>> bt_update_count(>bitmap_tags, tdepth);
>> /* blk_mq_tag_wakeup_all(tags, false); */
>>   bt = >bitmap_tags;
>>   wake_index = atomic_read(>wake_index);
>>  ...
>>  io_schedule();
>> 
>> 
>> This patch adds the missing memory barrier.
>> 
>> I found this issue when I was looking through the linux source code
>> for places calling waitqueue_active() before wake_up*(), but without
>> preceding memory barriers, after sending a patch to fix a similar
>> issue in drivers/tty/n_tty.c  (Details about the original issue can be
>> found here: https://lkml.org/lkml/2015/9/28/849).
>> 
>> Signed-off-by: Kosuke Tatsukawa 
>> ---
>>   block/blk-mq-tag.c |4 
>>   1 files changed, 4 insertions(+), 0 deletions(-)
>> 
>> diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
>> index ed96474..7a6b6e2 100644
>> --- a/block/blk-mq-tag.c
>> +++ b/block/blk-mq-tag.c
>> @@ -75,6 +75,10 @@ void blk_mq_tag_wakeup_all(struct blk_mq_tags *tags, bool 
>> include_reserve)
>>  struct blk_mq_bitmap_tags *bt;
>>  int i, wake_index;
>>   
>> +/*
>> + * Make sure all changes prior to this are visible from other CPUs.
>> + */
>> +smp_mb();
>>  bt = >bitmap_tags;
>>  wake_index = atomic_read(>wake_index);
>>  for (i = 0; i < BT_WAIT_QUEUES; i++) {
>> 
> 
> Thanks, after looking at this, I think this patch is fine. It's not a
> super hot path, so not worth it to further optimize this or look into
> ways to avoid the barrier. I do wonder if there are archs where
> atomic_read() is a memory barrier, in that case we need not do it at
> all. And perhaps we have some weird smp_before_bla variant that could be
> used here instead fo improve upon that case.

Roughly looking at include/asm/atomic.h in various architecures, it
seems atomic_read is defined as a macro or an inline function calling
  ACCESS_ONCE((v)->counter)
in many architectures which doesn't imply a memory barrier.

blackfin seems to be calling an assembler function which does "flush
core internal write buffer".

I'm not sure about the memory ordering of the assembler instructions for
metag, powerpc and s390 though.
---
Kosuke TATSUKAWA  | 3rd IT Platform Department
  | IT Platform Division, NEC Corporation
  | ta...@ab.jp.nec.com
--
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] tty: fix stall caused by missing memory barrier in drivers/tty/n_tty.c

[Kosuke Tatsukawa]

Peter Hurley wrote:
> On 10/09/2015 01:28 PM, Peter Hurley wrote:
>> Tatsukawa-san,
>> 
>> I would still like to root-cause the reported stall; is the reported
>> stall resolved if smp_mb() is added before the waitqueue_active()
>> in __receive_buf()?
>
> Nevermind, I see it now.
>
> The store to commit_head is deferred until after the load of read_wait->next;
> a full memory barrier would properly order the store before the load but,
> since that is roughly equivalent to taking the spin lock for the wake up 
> anyway,
> it makes sense to just always do the wakeup.

The stall problem is resolved if smp_mb() is added both before the
waitqueue_active() in __receive_buf(), and before the line containing
input_available_p() in n_tty_read().
---
Kosuke TATSUKAWA  | 3rd IT Platform Department
  | IT Platform Division, NEC Corporation
  | ta...@ab.jp.nec.com
--
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] btrfs: fix waitqueue_active without memory barrier in btrfs

[Kosuke Tatsukawa]

David Sterba wrote:
> On Fri, Oct 09, 2015 at 12:35:48AM +, Kosuke Tatsukawa wrote:
>> This patch removes the call to waitqueue_active() leaving just wake_up()
>> behind.  This fixes the problem because the call to spin_lock_irqsave()
>> in wake_up() will be an ACQUIRE operation.
>
> Either we can switch it to wake_up or put the barrier before the check.
> Not all instances of waitqueue_active need the barrier though.
>
>> I found this issue when I was looking through the linux source code
>> for places calling waitqueue_active() before wake_up*(), but without
>> preceding memory barriers, after sending a patch to fix a similar
>> issue in drivers/tty/n_tty.c  (Details about the original issue can be
>> found here: https://lkml.org/lkml/2015/9/28/849).
>
> There are more in btrfs:
>
> https://www.mail-archive.com/linux-btrfs%40vger.kernel.org/msg41914.html

Thank you for the pointer.
Your patch seems better than mine.

I think the other places in btrfs that use waitqueue_active() before
wake_up are preceded by either a smp_mb or some kind of atomic
operation.

The latter still needs smp_mb__after_atomic() but it's light-weight
compared to smp_mb().


>> @@ -918,9 +918,7 @@ void btrfs_bio_counter_inc_noblocked(struct 
>> btrfs_fs_info *fs_info)
>>  void btrfs_bio_counter_sub(struct btrfs_fs_info *fs_info, s64 amount)
>>  {
>>  percpu_counter_sub(_info->bio_counter, amount);
>> -
>> -if (waitqueue_active(_info->replace_wait))
>> -wake_up(_info->replace_wait);
>> +wake_up(_info->replace_wait);
>
> Chris had a comment on that one in
> https://www.mail-archive.com/linux-btrfs%40vger.kernel.org/msg42551.html
> it's in performance critial context and the explicit wake_up is even
> worse than the barrier.
---
Kosuke TATSUKAWA  | 3rd IT Platform Department
  | IT Platform Division, NEC Corporation
  | ta...@ab.jp.nec.com
--
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 7/9] xen/blkback: separate ring information out of struct xen_blkif

[Bob Liu]

On 10/05/2015 10:55 PM, Roger Pau Monné wrote:
> El 05/09/15 a les 14.39, Bob Liu ha escrit:
>> Split per ring information to an new structure:xen_blkif_ring, so that one 
>> vbd
>> device can associate with one or more rings/hardware queues.
>>
>> This patch is a preparation for supporting multi hardware queues/rings.
>>
>> Signed-off-by: Arianna Avanzini 
>> Signed-off-by: Bob Liu 
>> ---
>>  drivers/block/xen-blkback/blkback.c |  365 
>> ++-
>>  drivers/block/xen-blkback/common.h  |   52 +++--
>>  drivers/block/xen-blkback/xenbus.c  |  130 +++--
>>  3 files changed, 295 insertions(+), 252 deletions(-)
>>
>> diff --git a/drivers/block/xen-blkback/blkback.c 
>> b/drivers/block/xen-blkback/blkback.c
>> index 954c002..fd02240 100644
>> --- a/drivers/block/xen-blkback/blkback.c
>> +++ b/drivers/block/xen-blkback/blkback.c
>> @@ -113,71 +113,71 @@ module_param(log_stats, int, 0644);
>>  /* Number of free pages to remove on each call to gnttab_free_pages */
>>  #define NUM_BATCH_FREE_PAGES 10
>>  
>> -static inline int get_free_page(struct xen_blkif *blkif, struct page **page)
>> +static inline int get_free_page(struct xen_blkif_ring *ring, struct page 
>> **page)
>>  {
>>  unsigned long flags;
>>  
>> -spin_lock_irqsave(>free_pages_lock, flags);
>> -if (list_empty(>free_pages)) {
>> -BUG_ON(blkif->free_pages_num != 0);
>> -spin_unlock_irqrestore(>free_pages_lock, flags);
>> +spin_lock_irqsave(>free_pages_lock, flags);
>> +if (list_empty(>free_pages)) {
> 
> I'm afraid the pool of free pages should be per-device, not per-ring.
> 
>> +BUG_ON(ring->free_pages_num != 0);
>> +spin_unlock_irqrestore(>free_pages_lock, flags);
>>  return gnttab_alloc_pages(1, page);
>>  }
>> -BUG_ON(blkif->free_pages_num == 0);
>> -page[0] = list_first_entry(>free_pages, struct page, lru);
>> +BUG_ON(ring->free_pages_num == 0);
>> +page[0] = list_first_entry(>free_pages, struct page, lru);
>>  list_del([0]->lru);
>> -blkif->free_pages_num--;
>> -spin_unlock_irqrestore(>free_pages_lock, flags);
>> +ring->free_pages_num--;
>> +spin_unlock_irqrestore(>free_pages_lock, flags);
>>  
>>  return 0;
>>  }
>>  
>> -static inline void put_free_pages(struct xen_blkif *blkif, struct page 
>> **page,
>> +static inline void put_free_pages(struct xen_blkif_ring *ring, struct page 
>> **page,
>>int num)
>>  {
>>  unsigned long flags;
>>  int i;
>>  
>> -spin_lock_irqsave(>free_pages_lock, flags);
>> +spin_lock_irqsave(>free_pages_lock, flags);
>>  for (i = 0; i < num; i++)
>> -list_add([i]->lru, >free_pages);
>> -blkif->free_pages_num += num;
>> -spin_unlock_irqrestore(>free_pages_lock, flags);
>> +list_add([i]->lru, >free_pages);
>> +ring->free_pages_num += num;
>> +spin_unlock_irqrestore(>free_pages_lock, flags);
>>  }
>>  
>> -static inline void shrink_free_pagepool(struct xen_blkif *blkif, int num)
>> +static inline void shrink_free_pagepool(struct xen_blkif_ring *ring, int 
>> num)
>>  {
>>  /* Remove requested pages in batches of NUM_BATCH_FREE_PAGES */
>>  struct page *page[NUM_BATCH_FREE_PAGES];
>>  unsigned int num_pages = 0;
>>  unsigned long flags;
>>  
>> -spin_lock_irqsave(>free_pages_lock, flags);
>> -while (blkif->free_pages_num > num) {
>> -BUG_ON(list_empty(>free_pages));
>> -page[num_pages] = list_first_entry(>free_pages,
>> +spin_lock_irqsave(>free_pages_lock, flags);
>> +while (ring->free_pages_num > num) {
>> +BUG_ON(list_empty(>free_pages));
>> +page[num_pages] = list_first_entry(>free_pages,
>> struct page, lru);
>>  list_del([num_pages]->lru);
>> -blkif->free_pages_num--;
>> +ring->free_pages_num--;
>>  if (++num_pages == NUM_BATCH_FREE_PAGES) {
>> -spin_unlock_irqrestore(>free_pages_lock, flags);
>> +spin_unlock_irqrestore(>free_pages_lock, flags);
>>  gnttab_free_pages(num_pages, page);
>> -spin_lock_irqsave(>free_pages_lock, flags);
>> +spin_lock_irqsave(>free_pages_lock, flags);
>>  num_pages = 0;
>>  }
>>  }
>> -spin_unlock_irqrestore(>free_pages_lock, flags);
>> +spin_unlock_irqrestore(>free_pages_lock, flags);
>>  if (num_pages != 0)
>>  gnttab_free_pages(num_pages, page);
>>  }
>>  
>>  #define vaddr(page) ((unsigned long)pfn_to_kaddr(page_to_pfn(page)))
>>  
>> -static int do_block_io_op(struct xen_blkif *blkif);
>> -static int dispatch_rw_block_io(struct xen_blkif *blkif,
>> +static int do_block_io_op(struct xen_blkif_ring *ring);
>> +static int dispatch_rw_block_io(struct 

[PATCH] Staging: most: Fix typo in staging/most

[Masanari Iida]

This patch fix spelling typo found in most

Signed-off-by: Masanari Iida 
---
 drivers/staging/most/Documentation/ABI/sysfs-class-most.txt | 2 +-
 drivers/staging/most/hdm-dim2/Kconfig   | 2 +-
 drivers/staging/most/hdm-usb/hdm_usb.c  | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/most/Documentation/ABI/sysfs-class-most.txt 
b/drivers/staging/most/Documentation/ABI/sysfs-class-most.txt
index 380c137..42ff0d8 100644
--- a/drivers/staging/most/Documentation/ABI/sysfs-class-most.txt
+++ b/drivers/staging/most/Documentation/ABI/sysfs-class-most.txt
@@ -47,7 +47,7 @@ Date: June 2015
 KernelVersion: 4.3
 Contact:   Christian Gromm 
 Description:
-   Indicates the type of peripherial interface the current device
+   Indicates the type of peripheral interface the current device
uses.
 Users:
 
diff --git a/drivers/staging/most/hdm-dim2/Kconfig 
b/drivers/staging/most/hdm-dim2/Kconfig
index fc54876..28a0e17 100644
--- a/drivers/staging/most/hdm-dim2/Kconfig
+++ b/drivers/staging/most/hdm-dim2/Kconfig
@@ -9,7 +9,7 @@ config HDM_DIM2
 
---help---
  Say Y here if you want to connect via MediaLB to network transceiver.
- This device driver is platform dependent and needs an addtional
+ This device driver is platform dependent and needs an additional
  platform driver to be installed. For more information contact
  maintainer of this driver.
 
diff --git a/drivers/staging/most/hdm-usb/hdm_usb.c 
b/drivers/staging/most/hdm-usb/hdm_usb.c
index fcd7559..a73eb5f 100644
--- a/drivers/staging/most/hdm-usb/hdm_usb.c
+++ b/drivers/staging/most/hdm-usb/hdm_usb.c
@@ -431,7 +431,7 @@ static void hdm_write_completion(struct urb *urb)
 }
 
 /**
- * hdm_read_completion - completion funciton for submitted Rx URBs
+ * hdm_read_completion - completion function for submitted Rx URBs
  * @urb: the URB that has been completed
  *
  * This checks the status of the completed URB. In case the URB has been
@@ -767,7 +767,7 @@ static int hdm_configure_channel(struct most_interface 
*iface, int channel,
tmp_val = conf->buffer_size / frame_size;
conf->buffer_size = tmp_val * frame_size;
dev_notice(dev,
-  "Channel %d - rouding buffer size to %d bytes, "
+  "Channel %d - rounding buffer size to %d bytes, "
   "channel config says %d bytes\n",
   channel,
   conf->buffer_size,
-- 
2.6.1.133.gf5b6079

--
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/

[RESEND PATCH] soc: qcom: smd: Correct SMEM items for upper channels

[bjorn]

From: Bjorn Andersson 

Update the SMEM items for the second set of SMD channels, as these where
incorrect.

Signed-off-by: Bjorn Andersson 
---

Corrected .gitconfig mishap which gave wrong author.

 drivers/soc/qcom/smd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c
index 18964f1..e7fb8fa 100644
--- a/drivers/soc/qcom/smd.c
+++ b/drivers/soc/qcom/smd.c
@@ -87,8 +87,8 @@ static const struct {
.fifo_base_id = 338
},
{
-   .alloc_tbl_id = 14,
-   .info_base_id = 266,
+   .alloc_tbl_id = 266,
+   .info_base_id = 138,
.fifo_base_id = 202,
},
 };
-- 
2.3.2 (Apple Git-55)

--
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] ASoc: sh: Fit typo in Kconfig

[Masanari Iida]

s/SUR/SRU/g

Signed-off-by: Masanari Iida 
---
 sound/soc/sh/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/sh/Kconfig b/sound/soc/sh/Kconfig
index 6ca90aa..206d1ed 100644
--- a/sound/soc/sh/Kconfig
+++ b/sound/soc/sh/Kconfig
@@ -41,7 +41,7 @@ config SND_SOC_RCAR
select SND_SIMPLE_CARD
select REGMAP_MMIO
help
- This option enables R-Car SUR/SCU/SSIU/SSI sound support
+ This option enables R-Car SRU/SCU/SSIU/SSI sound support
 
 config SND_SOC_RSRC_CARD
tristate "Renesas Sampling Rate Convert Sound Card"
-- 
2.6.1.133.gf5b6079

--
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 03/14] cgroup: replace cgroup_has_tasks() with cgroup_is_populated()

[Tejun Heo]

Currently, cgroup_has_tasks() tests whether the target cgroup has any
css_set linked to it.  This works because a css_set's refcnt converges
with the number of tasks linked to it and thus there's no css_set
linked to a cgroup if it doesn't have any live tasks.

To help tracking resource usage of zombie tasks, putting the ref of
css_set will be separated from disassociating the task from the
css_set which means that a cgroup may have css_sets linked to it even
when it doesn't have any live tasks.

This patch replaces cgroup_has_tasks() with cgroup_is_populated()
which tests cgroup->nr_populated instead which locally counts the
number of populated css_sets.  Unlike cgroup_has_tasks(),
cgroup_is_populated() is recursive - if any of the descendants is
populated, the cgroup is populated too.  While this changes the
meaning of the test, all the existing users are okay with the change.

While at it, replace the open-coded ->populated_cnt test in
cgroup_events_show() with cgroup_is_populated().

Signed-off-by: Tejun Heo 
Cc: Li Zefan 
Cc: Johannes Weiner 
Cc: Michal Hocko 
---
 include/linux/cgroup.h | 4 ++--
 kernel/cgroup.c| 6 +++---
 kernel/cpuset.c| 2 +-
 mm/memcontrol.c| 2 +-
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index e9c3eac..bdfdb3a 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -456,9 +456,9 @@ static inline struct cgroup *task_cgroup(struct task_struct 
*task,
 }
 
 /* no synchronization, the result can only be used as a hint */
-static inline bool cgroup_has_tasks(struct cgroup *cgrp)
+static inline bool cgroup_is_populated(struct cgroup *cgrp)
 {
-   return !list_empty(>cset_links);
+   return cgrp->populated_cnt;
 }
 
 /* returns ino associated with a cgroup */
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index e5231d0..435aa68 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -3121,7 +3121,7 @@ static ssize_t cgroup_subtree_control_write(struct 
kernfs_open_file *of,
 static int cgroup_events_show(struct seq_file *seq, void *v)
 {
seq_printf(seq, "populated %d\n",
-  (bool)seq_css(seq)->cgroup->populated_cnt);
+  cgroup_is_populated(seq_css(seq)->cgroup));
return 0;
 }
 
@@ -5558,7 +5558,7 @@ void cgroup_exit(struct task_struct *tsk)
 
 static void check_for_release(struct cgroup *cgrp)
 {
-   if (notify_on_release(cgrp) && !cgroup_has_tasks(cgrp) &&
+   if (notify_on_release(cgrp) && !cgroup_is_populated(cgrp) &&
!css_has_online_children(>self) && !cgroup_is_dead(cgrp))
schedule_work(>release_agent_work);
 }
@@ -5806,7 +5806,7 @@ static int cgroup_css_links_read(struct seq_file *seq, 
void *v)
 
 static u64 releasable_read(struct cgroup_subsys_state *css, struct cftype *cft)
 {
-   return (!cgroup_has_tasks(css->cgroup) &&
+   return (!cgroup_is_populated(css->cgroup) &&
!css_has_online_children(>cgroup->self));
 }
 
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index e4d..d7ccb87 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -498,7 +498,7 @@ static int validate_change(struct cpuset *cur, struct 
cpuset *trial)
 * be changed to have empty cpus_allowed or mems_allowed.
 */
ret = -ENOSPC;
-   if ((cgroup_has_tasks(cur->css.cgroup) || cur->attach_in_progress)) {
+   if ((cgroup_is_populated(cur->css.cgroup) || cur->attach_in_progress)) {
if (!cpumask_empty(cur->cpus_allowed) &&
cpumask_empty(trial->cpus_allowed))
goto out;
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 33c8dad..0ddd0ff 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2920,7 +2920,7 @@ static int memcg_activate_kmem(struct mem_cgroup *memcg,
 * of course permitted.
 */
mutex_lock(_create_mutex);
-   if (cgroup_has_tasks(memcg->css.cgroup) ||
+   if (cgroup_is_populated(memcg->css.cgroup) ||
(memcg->use_hierarchy && memcg_has_children(memcg)))
err = -EBUSY;
mutex_unlock(_create_mutex);
-- 
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 09/14] cgroup: factor out css_set_move_task()

[Tejun Heo]

A task is associated and disassociated with its css_set in three
places - during migration, after a new task is created and when a task
exits.  The first is handled by cgroup_task_migrate() and the latter
two are open-coded.

These are similar operations and spreading them over multiple places
makes it harder to follow and update.  This patch collects all task
css_set [dis]association operations into css_set_move_task().

While css_set_move_task() may check whether populated state needs to
be updated when not strictly necessary, the behavior is essentially
equivalent before and after this patch.

Signed-off-by: Tejun Heo 
---
 kernel/cgroup.c | 104 ++--
 1 file changed, 56 insertions(+), 48 deletions(-)

diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 5cb28d2..4e239e4 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -664,6 +664,52 @@ static void css_set_update_populated(struct css_set *cset, 
bool populated)
cgroup_update_populated(link->cgrp, populated);
 }
 
+/**
+ * css_set_move_task - move a task from one css_set to another
+ * @task: task being moved
+ * @from_cset: css_set @task currently belongs to (may be NULL)
+ * @to_cset: new css_set @task is being moved to (may be NULL)
+ * @use_mg_tasks: move to @to_cset->mg_tasks instead of ->tasks
+ *
+ * Move @task from @from_cset to @to_cset.  If @task didn't belong to any
+ * css_set, @from_cset can be NULL.  If @task is being disassociated
+ * instead of moved, @to_cset can be NULL.
+ *
+ * This function automatically handles populated_cnt updates but the caller
+ * is responsible for managing @from_cset and @to_cset's reference counts.
+ */
+static void css_set_move_task(struct task_struct *task,
+ struct css_set *from_cset, struct css_set 
*to_cset,
+ bool use_mg_tasks)
+{
+   lockdep_assert_held(_set_rwsem);
+
+   if (from_cset) {
+   WARN_ON_ONCE(list_empty(>cg_list));
+   list_del_init(>cg_list);
+   if (!css_set_populated(from_cset))
+   css_set_update_populated(from_cset, false);
+   } else {
+   WARN_ON_ONCE(!list_empty(>cg_list));
+   }
+
+   if (to_cset) {
+   /*
+* We are synchronized through cgroup_threadgroup_rwsem
+* against PF_EXITING setting such that we can't race
+* against cgroup_exit() changing the css_set to
+* init_css_set and dropping the old one.
+*/
+   WARN_ON_ONCE(task->flags & PF_EXITING);
+
+   if (!css_set_populated(to_cset))
+   css_set_update_populated(to_cset, true);
+   rcu_assign_pointer(task->cgroups, to_cset);
+   list_add_tail(>cg_list, use_mg_tasks ? _cset->mg_tasks 
:
+_cset->tasks);
+   }
+}
+
 /*
  * hash table for cgroup groups. This improves the performance to find
  * an existing css_set. This hash doesn't (currently) take into
@@ -2260,47 +2306,6 @@ struct task_struct *cgroup_taskset_next(struct 
cgroup_taskset *tset)
 }
 
 /**
- * cgroup_task_migrate - move a task from one cgroup to another.
- * @tsk: the task being migrated
- * @new_cset: the new css_set @tsk is being attached to
- *
- * Must be called with cgroup_mutex, threadgroup and css_set_rwsem locked.
- */
-static void cgroup_task_migrate(struct task_struct *tsk,
-   struct css_set *new_cset)
-{
-   struct css_set *old_cset;
-
-   lockdep_assert_held(_mutex);
-   lockdep_assert_held(_set_rwsem);
-
-   /*
-* We are synchronized through cgroup_threadgroup_rwsem against
-* PF_EXITING setting such that we can't race against cgroup_exit()
-* changing the css_set to init_css_set and dropping the old one.
-*/
-   WARN_ON_ONCE(tsk->flags & PF_EXITING);
-   old_cset = task_css_set(tsk);
-
-   if (!css_set_populated(new_cset))
-   css_set_update_populated(new_cset, true);
-
-   get_css_set(new_cset);
-   rcu_assign_pointer(tsk->cgroups, new_cset);
-   list_move_tail(>cg_list, _cset->mg_tasks);
-
-   if (!css_set_populated(old_cset))
-   css_set_update_populated(old_cset, false);
-
-   /*
-* We just gained a reference on old_cset by taking it from the
-* task. As trading it for new_cset is protected by cgroup_mutex,
-* we're safe to drop it here; it will be freed under RCU.
-*/
-   put_css_set_locked(old_cset);
-}
-
-/**
  * cgroup_taskset_migrate - migrate a taskset to a cgroup
  * @tset: taget taskset
  * @dst_cgrp: destination cgroup
@@ -2340,8 +2345,14 @@ static int cgroup_taskset_migrate(struct cgroup_taskset 
*tset,
 */
down_write(_set_rwsem);
list_for_each_entry(cset, >src_csets, mg_node) {
-   

[PATCH 08/14] cgroup: keep css_set and task lists in chronological order

[Tejun Heo]

css task iteration will be updated to not leak cgroup internal locking
to iterator users.  In preparation, update css_set and task lists to
be in chronological order.

For tasks, as migration path is already using list_splice_tail_init(),
only cgroup_enable_task_cg_lists() and cgroup_post_fork() need
updating.  For css_sets, link_css_set() is the only place which needs
to be updated.

Signed-off-by: Tejun Heo 
---
 kernel/cgroup.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index b8da97a..5cb28d2 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -913,12 +913,11 @@ static void link_css_set(struct list_head *tmp_links, 
struct css_set *cset,
link->cset = cset;
link->cgrp = cgrp;
 
-   list_move(>cset_link, >cset_links);
-
/*
-* Always add links to the tail of the list so that the list
-* is sorted by order of hierarchy creation
+* Always add links to the tail of the lists so that the lists are
+* in choronological order.
 */
+   list_move_tail(>cset_link, >cset_links);
list_add_tail(>cgrp_link, >cgrp_links);
 
cgroup_get(cgrp);
@@ -1778,7 +1777,7 @@ static void cgroup_enable_task_cg_lists(void)
 
if (!css_set_populated(cset))
css_set_update_populated(cset, true);
-   list_add(>cg_list, >tasks);
+   list_add_tail(>cg_list, >tasks);
get_css_set(cset);
}
spin_unlock_irq(>sighand->siglock);
@@ -5478,7 +5477,7 @@ void cgroup_post_fork(struct task_struct *child,
cset = task_css_set(current);
if (list_empty(>cg_list)) {
rcu_assign_pointer(child->cgroups, cset);
-   list_add(>cg_list, >tasks);
+   list_add_tail(>cg_list, >tasks);
get_css_set(cset);
}
up_write(_set_rwsem);
-- 
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 10/14] cgroup: reorganize css_task_iter functions

[Tejun Heo]

* Rename css_advance_task_iter() to css_task_iter_advance_css_set()
  and make it clear it->task_pos too at the end of the iteration.

* Factor out css_task_iter_advance() from css_task_iter_next().  The
  new function whines if called on a terminated iterator.

Except for the termination check, this is pure reorganization and
doesn't introduce any behavior changes.  This will help the planned
locking update for css_task_iter.

Signed-off-by: Tejun Heo 
---
 kernel/cgroup.c | 49 -
 1 file changed, 28 insertions(+), 21 deletions(-)

diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 4e239e4..0a58445 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -3791,12 +3791,12 @@ bool css_has_online_children(struct cgroup_subsys_state 
*css)
 }
 
 /**
- * css_advance_task_iter - advance a task itererator to the next css_set
+ * css_task_iter_advance_css_set - advance a task itererator to the next 
css_set
  * @it: the iterator to advance
  *
  * Advance @it to the next css_set to walk.
  */
-static void css_advance_task_iter(struct css_task_iter *it)
+static void css_task_iter_advance_css_set(struct css_task_iter *it)
 {
struct list_head *l = it->cset_pos;
struct cgrp_cset_link *link;
@@ -3807,6 +3807,7 @@ static void css_advance_task_iter(struct css_task_iter 
*it)
l = l->next;
if (l == it->cset_head) {
it->cset_pos = NULL;
+   it->task_pos = NULL;
return;
}
 
@@ -3830,6 +3831,28 @@ static void css_advance_task_iter(struct css_task_iter 
*it)
it->mg_tasks_head = >mg_tasks;
 }
 
+static void css_task_iter_advance(struct css_task_iter *it)
+{
+   struct list_head *l = it->task_pos;
+
+   WARN_ON_ONCE(!l);
+
+   /*
+* Advance iterator to find next entry.  cset->tasks is consumed
+* first and then ->mg_tasks.  After ->mg_tasks, we move onto the
+* next cset.
+*/
+   l = l->next;
+
+   if (l == it->tasks_head)
+   l = it->mg_tasks_head->next;
+
+   if (l == it->mg_tasks_head)
+   css_task_iter_advance_css_set(it);
+   else
+   it->task_pos = l;
+}
+
 /**
  * css_task_iter_start - initiate task iteration
  * @css: the css to walk tasks of
@@ -3862,7 +3885,7 @@ void css_task_iter_start(struct cgroup_subsys_state *css,
 
it->cset_head = it->cset_pos;
 
-   css_advance_task_iter(it);
+   css_task_iter_advance_css_set(it);
 }
 
 /**
@@ -3876,28 +3899,12 @@ void css_task_iter_start(struct cgroup_subsys_state 
*css,
 struct task_struct *css_task_iter_next(struct css_task_iter *it)
 {
struct task_struct *res;
-   struct list_head *l = it->task_pos;
 
-   /* If the iterator cg is NULL, we have no tasks */
if (!it->cset_pos)
return NULL;
-   res = list_entry(l, struct task_struct, cg_list);
-
-   /*
-* Advance iterator to find next entry.  cset->tasks is consumed
-* first and then ->mg_tasks.  After ->mg_tasks, we move onto the
-* next cset.
-*/
-   l = l->next;
-
-   if (l == it->tasks_head)
-   l = it->mg_tasks_head->next;
-
-   if (l == it->mg_tasks_head)
-   css_advance_task_iter(it);
-   else
-   it->task_pos = l;
 
+   res = list_entry(it->task_pos, struct task_struct, cg_list);
+   css_task_iter_advance(it);
return res;
 }
 
-- 
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 05/14] cgroup: relocate cgroup_[try]get/put()

[Tejun Heo]

Relocate cgroup_get(), cgroup_tryget() and cgroup_put() upwards.  This
is pure code reorganization to prepare for future changes.

Signed-off-by: Tejun Heo 
---
 kernel/cgroup.c | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 855313d..ab5c9a5 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -428,6 +428,22 @@ static inline bool cgroup_is_dead(const struct cgroup 
*cgrp)
return !(cgrp->self.flags & CSS_ONLINE);
 }
 
+static void cgroup_get(struct cgroup *cgrp)
+{
+   WARN_ON_ONCE(cgroup_is_dead(cgrp));
+   css_get(>self);
+}
+
+static bool cgroup_tryget(struct cgroup *cgrp)
+{
+   return css_tryget(>self);
+}
+
+static void cgroup_put(struct cgroup *cgrp)
+{
+   css_put(>self);
+}
+
 struct cgroup_subsys_state *of_css(struct kernfs_open_file *of)
 {
struct cgroup *cgrp = of->kn->parent->priv;
@@ -1177,22 +1193,6 @@ static umode_t cgroup_file_mode(const struct cftype *cft)
return mode;
 }
 
-static void cgroup_get(struct cgroup *cgrp)
-{
-   WARN_ON_ONCE(cgroup_is_dead(cgrp));
-   css_get(>self);
-}
-
-static bool cgroup_tryget(struct cgroup *cgrp)
-{
-   return css_tryget(>self);
-}
-
-static void cgroup_put(struct cgroup *cgrp)
-{
-   css_put(>self);
-}
-
 /**
  * cgroup_calc_child_subsys_mask - calculate child_subsys_mask
  * @cgrp: the target cgroup
-- 
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 07/14] cgroup: make cgroup_destroy_locked() test cgroup_is_populated()

[Tejun Heo]

cgroup_destroy_locked() currently tests whether any css_sets are
associated to reject removal if the cgroup contains tasks.  This works
because a css_set's refcnt converges with the number of tasks linked
to it and thus there's no css_set linked to a cgroup if it doesn't
have any live tasks.

To help tracking resource usage of zombie tasks, putting the ref of
css_set will be separated from disassociating the task from the
css_set which means that a cgroup may have css_sets linked to it even
when it doesn't have any live tasks.

This patch updates cgroup_destroy_locked() so that it tests
cgroup_is_populated(), which counts the number of populated css_sets,
instead of whether cgrp->cset_links is empty to determine whether the
cgroup is populated or not.  This ensures that rmdirs won't be
incorrectly rejected for cgroups which only contain zombie tasks.

Signed-off-by: Tejun Heo 
---
 kernel/cgroup.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index ba11496..b8da97a 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -4996,16 +4996,15 @@ static int cgroup_destroy_locked(struct cgroup *cgrp)
__releases(_mutex) __acquires(_mutex)
 {
struct cgroup_subsys_state *css;
-   bool empty;
int ssid;
 
lockdep_assert_held(_mutex);
 
-   /* css_set_rwsem synchronizes access to ->cset_links */
-   down_read(_set_rwsem);
-   empty = list_empty(>cset_links);
-   up_read(_set_rwsem);
-   if (!empty)
+   /*
+* Only migration can raise populated from zero and we're already
+* holding cgroup_mutex.
+*/
+   if (cgroup_is_populated(cgrp))
return -EBUSY;
 
/*
-- 
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 06/14] cgroup: make css_sets pin the associated cgroups

[Tejun Heo]

Currently, css_sets don't pin the associated cgroups.  This is okay as
a cgroup with css_sets associated are not allowed to be removed;
however, to help resource tracking for zombie tasks, this is scheduled
to change such that a cgroup can be removed even when it has css_sets
associated as long as none of them are populated.

To ensure that a cgroup doesn't go away while css_sets are still
associated with it, make each associated css_set hold a reference on
the cgroup.

Signed-off-by: Tejun Heo 
---
 kernel/cgroup.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index ab5c9a5..ba11496 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -705,6 +705,7 @@ static void put_css_set_locked(struct css_set *cset)
list_for_each_entry_safe(link, tmp_link, >cgrp_links, cgrp_link) {
list_del(>cset_link);
list_del(>cgrp_link);
+   cgroup_put(link->cgrp);
kfree(link);
}
 
@@ -919,6 +920,8 @@ static void link_css_set(struct list_head *tmp_links, 
struct css_set *cset,
 * is sorted by order of hierarchy creation
 */
list_add_tail(>cgrp_link, >cgrp_links);
+
+   cgroup_get(cgrp);
 }
 
 /**
@@ -4998,10 +5001,7 @@ static int cgroup_destroy_locked(struct cgroup *cgrp)
 
lockdep_assert_held(_mutex);
 
-   /*
-* css_set_rwsem synchronizes access to ->cset_links and prevents
-* @cgrp from being removed while put_css_set() is in progress.
-*/
+   /* css_set_rwsem synchronizes access to ->cset_links */
down_read(_set_rwsem);
empty = list_empty(>cset_links);
up_read(_set_rwsem);
-- 
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: pidns: Make pid accounting and pid_max per namespace

[Zhang Haoyu]

On 10/10/15 12:40, Zhang Haoyu wrote:
> On 10/10/15 11:35, Zefan Li wrote:
>> On 2015/10/9 18:29, Zhang Haoyu wrote:
>>> I started multiple docker containers in centos6.6(linux-2.6.32-504.16.2),
>>> and there's one bad program was running in one container.
>>> This program produced many child threads continuously without free, so more 
>>> and
>>> more pid numbers were consumed by this program, until hitting the pix_max 
>>> limit (32768
>>> default in my system ).
>>>
>>> What's worse is that containers and host share the pid numbers resource, so 
>>> new program
>>> cannot be produced any more in host and other containers.
>>>
>>> And, I clone the upstream kernel source from
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>>> This problem is still there, I'm not sure.
>>>
>>> IMO, we should isolate the pid accounting and pid_max between pid 
>>> namespaces,
>>> and make them per pidns.
>>> Below post had request for making pid_max per pidns.
>>> http://thread.gmane.org/gmane.linux.kernel/1108167/focus=210
>>>
>> Mainline kernel already supports per-cgroup pid limit, which should solve
>> your problem.
>>
> What about pid accounting?
> If one pidns consume too many pids, dose it influence the other pid 
> namespaces?
I found it, thanks very much.
>
> Thanks,
> Zhang Haoyu


--
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] tty: fix stall caused by missing memory barrier in drivers/tty/n_tty.c

[Peter Hurley]

On 10/09/2015 01:28 PM, Peter Hurley wrote:
> Tatsukawa-san,
> 
> I would still like to root-cause the reported stall; is the reported
> stall resolved if smp_mb() is added before the waitqueue_active()
> in __receive_buf()?

Nevermind, I see it now.

The store to commit_head is deferred until after the load of read_wait->next;
a full memory barrier would properly order the store before the load but,
since that is roughly equivalent to taking the spin lock for the wake up anyway,
it makes sense to just always do the wakeup.

Thanks again.

Regards,
Peter Hurley
--
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/1] perf,tools: fix core dump caused by per-socket/core system-wide stat

[Jiri Olsa]

On Fri, Oct 09, 2015 at 06:59:23AM -0400, kan.li...@intel.com wrote:
> From: Kan Liang 
> 
> Perf will core dump if --per-socket/core -a are applied for perf stat.
> 
> The root cause is that cpu_map__build_map set refcnt of evlist's cpu_map
> to 1.
> It should set refcnt for the newly created cpu_map, not evlist's
> cpu_map.
> 
> Here is the example:
> 
> perf stat -e cycles --per-socket -a sleep 1
> 
>  Performance counter stats for 'system wide':
> 
> S0   36 30,196,257  cycles
> S1   28 15,823,536  cycles
> 
>1.001126828 seconds time elapsed
> 
> *** Error in `./perf': corrupted double-linked list: 0x021f9090
> ***
> === Backtrace: =
> /lib64/libc.so.6[0x3002e7bbe7]
> /lib64/libc.so.6[0x3002e7d2b5]
> ./perf(perf_evsel__delete+0x28)[0x485bdd]
> ./perf[0x4800e8]
> ./perf(perf_evlist__delete+0x5e)[0x482cd5]
> ./perf(cmd_stat+0xf25)[0x432328]
> ./perf[0x4768e0]
> ./perf[0x476ad6]
> ./perf[0x476b41]
> ./perf(main+0x1d0)[0x476db2]
> /lib64/libc.so.6(__libc_start_main+0xf5)[0x3002e21b45]
> ./perf[0x4202c5]
> 
> Signed-off-by: Kan Liang 
> ---
>  tools/perf/util/cpumap.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/perf/util/cpumap.c b/tools/perf/util/cpumap.c
> index c51c29f..dfc1f0b 100644
> --- a/tools/perf/util/cpumap.c
> +++ b/tools/perf/util/cpumap.c
> @@ -284,7 +284,7 @@ static int cpu_map__build_map(struct cpu_map *cpus, 
> struct cpu_map **res,
>   /* ensure we process id in increasing order */
>   qsort(c->map, c->nr, sizeof(int), cmp_ids);
>  
> - atomic_set(>refcnt, 1);
> + atomic_set(>refcnt, 1);

ouch ;-) 

Acked-by: Jiri Olsa 

thanks,
jirka
--
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] sunrpc: fix waitqueue_active without memory barrier in sunrpc

[J. Bruce Fields]

On Fri, Oct 09, 2015 at 06:29:44AM +, Kosuke Tatsukawa wrote:
> Neil Brown wrote:
> > Kosuke Tatsukawa  writes:
> > 
> >> There are several places in net/sunrpc/svcsock.c which calls
> >> waitqueue_active() without calling a memory barrier.  Add a memory
> >> barrier just as in wq_has_sleeper().
> >>
> >> I found this issue when I was looking through the linux source code
> >> for places calling waitqueue_active() before wake_up*(), but without
> >> preceding memory barriers, after sending a patch to fix a similar
> >> issue in drivers/tty/n_tty.c  (Details about the original issue can be
> >> found here: https://lkml.org/lkml/2015/9/28/849).
> > 
> > hi,
> > this feels like the wrong approach to the problem.  It requires extra
> > 'smb_mb's to be spread around which are hard to understand as easy to
> > forget.
> > 
> > A quick look seems to suggest that (nearly) every waitqueue_active()
> > will need an smb_mb.  Could we just put the smb_mb() inside
> > waitqueue_active()??
> 
> 
> There are around 200 occurrences of waitqueue_active() in the kernel
> source, and most of the places which use it before wake_up are either
> protected by some spin lock, or already has a memory barrier or some
> kind of atomic operation before it.
> 
> Simply adding smp_mb() to waitqueue_active() would incur extra cost in
> many cases and won't be a good idea.
> 
> Another way to solve this problem is to remove the waitqueue_active(),
> making the code look like this;
>   if (wq)
>   wake_up_interruptible(wq);
> This also fixes the problem because the spinlock in the wake_up*() acts
> as a memory barrier and prevents the code from being reordered by the
> CPU (and it also makes the resulting code is much simpler).

I might not care which we did, except I don't have the means to test
this quickly, and I guess this is some of our most frequently called
code.

I suppose your patch is the most conservative approach, as the
alternative is a spinlock/unlock in wake_up_interruptible, which I
assume is necessarily more expensive than an smp_mb().

As far as I can tell it's been this way since forever.  (Well, since a
2002 patch "NFSD: TCP: rationalise locking in RPC server routines" which
removed some spinlocks from the data_ready routines.)

I don't understand what the actual race is yet (which code exactly is
missing the wakeup in this case?  nfsd threads seem to instead get
woken up by the wake_up_process() in svc_xprt_do_enqueue().)

--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 v2 19/25] pxa2xx-flash: switch from ioremap_cache to memremap

[Dan Williams]

On Fri, Oct 2, 2015 at 10:51 AM, Brian Norris
 wrote:
> + linux-mtd
>
> On Fri, Jul 24, 2015 at 10:39:45PM -0400, Dan Williams wrote:
>> In preparation for deprecating ioremap_cache() convert its usage in
>> pxa2xx-flash to memremap.
>>
>> Cc: David Woodhouse 
>> Cc: Brian Norris 
>> Signed-off-by: Dan Williams 
>> ---
>>  drivers/mtd/maps/pxa2xx-flash.c |4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mtd/maps/pxa2xx-flash.c 
>> b/drivers/mtd/maps/pxa2xx-flash.c
>> index 12fa75df5008..758a8a7f86d9 100644
>> --- a/drivers/mtd/maps/pxa2xx-flash.c
>> +++ b/drivers/mtd/maps/pxa2xx-flash.c
>> @@ -71,8 +71,8 @@ static int pxa2xx_flash_probe(struct platform_device *pdev)
>>  info->map.name);
>>   return -ENOMEM;
>>   }
>> - info->map.cached =
>> - ioremap_cache(info->map.phys, info->map.size);
>> + info->map.cached = memremap(info->map.phys, info->map.size,
>> + MEMREMAP_CACHE);
>
> Should the corresponding iounmap() be changed too? Looks like a pretty
> thin wrapper right now, but it seems like the API would suggest we do
> this anyway.
>

Yes, thanks for that catch, addressed in the next rev.
--
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: [Bugfix v4 1/2] iommu/amd: Prevent binding other PCI drivers to IOMMU PCI devices

[Joerg Roedel]

On Fri, Oct 09, 2015 at 10:07:31PM +0800, Jiang Liu wrote:
> AMD IOMMU driver makes use of IOMMU PCI devices, so prevent binding other
> PCI drivers to IOMMU PCI devices.
> 
> This fixes a bug reported by Boris that system suspend/resume gets broken
> on AMD platforms. For more information, please refer to:
>   https://lkml.org/lkml/2015/9/26/89
> 
> Fixes: 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and 
> pcibios_free_irq()")
> Signed-off-by: Jiang Liu 
> Cc: Borislav Petkov 

Applied to iommu/fixes, thanks Jiang.

--
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 3/3] sched: start stopper early

[Oleg Nesterov]

From: Peter Zijlstra 

Ensure the stopper thread is active 'early', because the load balancer
pretty much assumes that its available. And when 'online && active' the
load-balancer is fully available.

Not only the numa balancing stop_two_cpus() caller relies on it, but
also the self migration stuff does, and at CPU_ONLINE time the cpu
really is 'free' to run anything.

Signed-off-by: Oleg Nesterov 
---
 kernel/cpu.c|1 -
 kernel/sched/core.c |5 -
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/kernel/cpu.c b/kernel/cpu.c
index ef52b3b..8a7225a 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -464,7 +464,6 @@ static int smpboot_thread_call(struct notifier_block *nfb,
switch (action & ~CPU_TASKS_FROZEN) {
 
case CPU_ONLINE:
-   stop_machine_unpark(cpu);
smpboot_unpark_threads(cpu);
break;
 
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index e691052..955c181 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5324,11 +5324,14 @@ static void __cpuinit set_cpu_rq_start_time(void)
 static int sched_cpu_active(struct notifier_block *nfb,
  unsigned long action, void *hcpu)
 {
+   int cpu = (long)hcpu;
+
switch (action & ~CPU_TASKS_FROZEN) {
case CPU_STARTING:
set_cpu_rq_start_time();
return NOTIFY_OK;
case CPU_ONLINE:
+   stop_machine_unpark(cpu);
/*
 * At this point a starting CPU has marked itself as online via
 * set_cpu_online(). But it might not yet have marked itself
@@ -5337,7 +5340,7 @@ static int sched_cpu_active(struct notifier_block *nfb,
 * Thus, fall-through and help the starting CPU along.
 */
case CPU_DOWN_FAILED:
-   set_cpu_active((long)hcpu, true);
+   set_cpu_active(cpu, true);
return NOTIFY_OK;
default:
return NOTIFY_DONE;
-- 
1.5.5.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/

[PATCH 1/3] stop_machine: kill smp_hotplug_thread->pre_unpark, introduce stop_machine_unpark()

[Oleg Nesterov]

1. Change smpboot_unpark_thread() to check ->selfparking, just
   like smpboot_park_thread() does.

2. Introduce stop_machine_unpark() which sets ->enabled and calls
   kthread_unpark().

3. Change smpboot_thread_call() and cpu_stop_init() to call
   stop_machine_unpark() by hand.

This way:

- IMO the ->selfparking logic becomes more consistent.

- We can kill the smp_hotplug_thread->pre_unpark() method.

- We can easily unpark the stopper thread earlier. Say, we
  can move stop_machine_unpark() from smpboot_thread_call()
  to sched_cpu_active() as Peter suggests.

Signed-off-by: Oleg Nesterov 
---
 include/linux/smpboot.h  |4 
 include/linux/stop_machine.h |1 +
 kernel/cpu.c |1 +
 kernel/smpboot.c |5 ++---
 kernel/stop_machine.c|   10 +-
 5 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/include/linux/smpboot.h b/include/linux/smpboot.h
index da3c593..255661e 100644
--- a/include/linux/smpboot.h
+++ b/include/linux/smpboot.h
@@ -24,9 +24,6 @@ struct smpboot_thread_data;
  * parked (cpu offline)
  * @unpark:Optional unpark function, called when the thread is
  * unparked (cpu online)
- * @pre_unpark:Optional unpark function, called before the 
thread is
- * unparked (cpu online). This is not guaranteed to be
- * called on the target cpu of the thread. Careful!
  * @cpumask:   Internal state.  To update which threads are unparked,
  * call smpboot_update_cpumask_percpu_thread().
  * @selfparking:   Thread is not parked by the park function.
@@ -42,7 +39,6 @@ struct smp_hotplug_thread {
void(*cleanup)(unsigned int cpu, bool 
online);
void(*park)(unsigned int cpu);
void(*unpark)(unsigned int cpu);
-   void(*pre_unpark)(unsigned int cpu);
cpumask_var_t   cpumask;
boolselfparking;
const char  *thread_comm;
diff --git a/include/linux/stop_machine.h b/include/linux/stop_machine.h
index 7b76362..0adedca 100644
--- a/include/linux/stop_machine.h
+++ b/include/linux/stop_machine.h
@@ -34,6 +34,7 @@ void stop_one_cpu_nowait(unsigned int cpu, cpu_stop_fn_t fn, 
void *arg,
 int stop_cpus(const struct cpumask *cpumask, cpu_stop_fn_t fn, void *arg);
 int try_stop_cpus(const struct cpumask *cpumask, cpu_stop_fn_t fn, void *arg);
 void stop_machine_park(int cpu);
+void stop_machine_unpark(int cpu);
 
 #else  /* CONFIG_SMP */
 
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 8a7225a..ef52b3b 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -464,6 +464,7 @@ static int smpboot_thread_call(struct notifier_block *nfb,
switch (action & ~CPU_TASKS_FROZEN) {
 
case CPU_ONLINE:
+   stop_machine_unpark(cpu);
smpboot_unpark_threads(cpu);
break;
 
diff --git a/kernel/smpboot.c b/kernel/smpboot.c
index c697f73..cfd29cb 100644
--- a/kernel/smpboot.c
+++ b/kernel/smpboot.c
@@ -221,9 +221,8 @@ static void smpboot_unpark_thread(struct smp_hotplug_thread 
*ht, unsigned int cp
 {
struct task_struct *tsk = *per_cpu_ptr(ht->store, cpu);
 
-   if (ht->pre_unpark)
-   ht->pre_unpark(cpu);
-   kthread_unpark(tsk);
+   if (!ht->selfparking)
+   kthread_unpark(tsk);
 }
 
 void smpboot_unpark_threads(unsigned int cpu)
diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index 91fbb10..59096a5 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -513,6 +513,14 @@ static void cpu_stop_unpark(unsigned int cpu)
spin_unlock_irq(>lock);
 }
 
+void stop_machine_unpark(int cpu)
+{
+   struct cpu_stopper *stopper = _cpu(cpu_stopper, cpu);
+
+   cpu_stop_unpark(cpu);
+   kthread_unpark(stopper->thread);
+}
+
 static struct smp_hotplug_thread cpu_stop_threads = {
.store  = _stopper.thread,
.thread_should_run  = cpu_stop_should_run,
@@ -521,7 +529,6 @@ static struct smp_hotplug_thread cpu_stop_threads = {
.create = cpu_stop_create,
.setup  = cpu_stop_unpark,
.park   = cpu_stop_park,
-   .pre_unpark = cpu_stop_unpark,
.selfparking= true,
 };
 
@@ -537,6 +544,7 @@ static int __init cpu_stop_init(void)
}
 
BUG_ON(smpboot_register_percpu_thread(_stop_threads));
+   stop_machine_unpark(raw_smp_processor_id());
stop_machine_initialized = true;
return 0;
 }
-- 
1.5.5.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 

[PATCH 2/3] stop_machine: kill cpu_stop_threads->setup() and cpu_stop_unpark()

[Oleg Nesterov]

Now that we always use stop_machine_unpark() to wake the stopper
threas up, we can kill ->setup() and fold cpu_stop_unpark() into
stop_machine_unpark().

And we do not need stopper->lock to set stopper->enabled = true.

Signed-off-by: Oleg Nesterov 
---
 kernel/stop_machine.c |   12 +---
 1 files changed, 1 insertions(+), 11 deletions(-)

diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index 59096a5..e5a09d2 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -504,20 +504,11 @@ static void cpu_stop_park(unsigned int cpu)
WARN_ON(!list_empty(>works));
 }
 
-static void cpu_stop_unpark(unsigned int cpu)
-{
-   struct cpu_stopper *stopper = _cpu(cpu_stopper, cpu);
-
-   spin_lock_irq(>lock);
-   stopper->enabled = true;
-   spin_unlock_irq(>lock);
-}
-
 void stop_machine_unpark(int cpu)
 {
struct cpu_stopper *stopper = _cpu(cpu_stopper, cpu);
 
-   cpu_stop_unpark(cpu);
+   stopper->enabled = true;
kthread_unpark(stopper->thread);
 }
 
@@ -527,7 +518,6 @@ static struct smp_hotplug_thread cpu_stop_threads = {
.thread_fn  = cpu_stopper_thread,
.thread_comm= "migration/%u",
.create = cpu_stop_create,
-   .setup  = cpu_stop_unpark,
.park   = cpu_stop_park,
.selfparking= true,
 };
-- 
1.5.5.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: [RFC] arm: add relocate initrd support

[Russell King - ARM Linux]

On Fri, Oct 09, 2015 at 11:55:09PM +0800, yalin wang wrote:
> Add support for initrd on ARM arch, in case
> mem= boot option change the memory size or the initrd are
> not placed in low memory region, we need copy the initrd
> to low memory region.
> 
> Signed-off-by: yalin wang 
> ---
>  arch/arm/include/asm/fixmap.h |  1 +
>  arch/arm/kernel/setup.c   | 72 
> +++
>  2 files changed, 73 insertions(+)
> 
> diff --git a/arch/arm/include/asm/fixmap.h b/arch/arm/include/asm/fixmap.h
> index 58cfe9f..18ad90f 100644
> --- a/arch/arm/include/asm/fixmap.h
> +++ b/arch/arm/include/asm/fixmap.h
> @@ -10,6 +10,7 @@
>  
>  enum fixed_addresses {
>   FIX_EARLYCON_MEM_BASE,
> + FIX_RELOCATE_INITRD,
>   __end_of_permanent_fixed_addresses,
>  
>   FIX_KMAP_BEGIN = __end_of_permanent_fixed_addresses,
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 20edd34..4260d59 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -811,6 +811,77 @@ static void __init request_standard_resources(const 
> struct machine_desc *mdesc)
>   request_resource(_resource, );
>  }
>  
> +#if defined(CONFIG_BLK_DEV_INITRD) && defined(CONFIG_MMU)
> +/*
> + * Relocate initrd if it is not completely within the linear mapping.
> + * This would be the case if mem= cuts out all or part of it
> + * or the initrd are not in low mem region place.
> + */
> +static void __init relocate_initrd(void)
> +{
> + phys_addr_t orig_start = __virt_to_phys(initrd_start);
> + phys_addr_t orig_end = __virt_to_phys(initrd_end);

If initrd_start or initrd_end are outside of the lowmem region, it's
quite possible for these to return incorrect physical addresses.
The generic kernel's idea of using virtual addresses for the initrd
stuff is painfully wrong IMHO.

The unfortunate thing is that the DT code propagates this stuff:

initrd_start = (unsigned long)__va(start);
initrd_end = (unsigned long)__va(end);

and even this can give wrong results for the virtual address when the
physical is outside of lowmem.  For addresses outside of lowmem,
__virt_to_phys(__va(start)) is not guaranteed to return 'start'.

This is why I've said that if we want to support ramdisks outside of
the lowmem mapping, we need to get rid of the initrd_start/initrd_end
virtual addresses.

I'm sorry, but we need much wider code changes before we can cope with
this.

> + phys_addr_t ram_end = memblock_end_of_DRAM();
> + phys_addr_t new_start;
> + phys_addr_t src;
> + unsigned long size, to_free = 0;
> + unsigned long slop, clen, p;
> + void *dest;
> +
> + if (orig_end <= memblock_get_current_limit())
> + return;
> +
> + /*
> +  * Any of the original initrd which overlaps the linear map should
> +  * be freed after relocating.

How does this work?  The code in arm_memblock_init() will have already
reserved the physical addresses for the ramdisk:

memblock_reserve(phys_initrd_start, phys_initrd_size);

So any new allocation shouldn't overlap the existing ramdisk - unless
this is wrong.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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] ARM: hisilicon: DT: Drop console= and earlyprintk bootargs parameter

[Wei Xu]

Replace console with stdout-path so that we don't have to put the
console on the kernel command line.

Remove earlyprintk to allow the kernel to boot on a system even
if DEBUG_LL is configured for another system.

Signed-off-by: Wei Xu 
Tested-by: Zhangfei Gao 
---
 arch/arm/boot/dts/hi3620-hi4511.dts  | 3 ++-
 arch/arm/boot/dts/hisi-x5hd2-dkb.dts | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/hi3620-hi4511.dts 
b/arch/arm/boot/dts/hi3620-hi4511.dts
index fe62392..a579fbf 100644
--- a/arch/arm/boot/dts/hi3620-hi4511.dts
+++ b/arch/arm/boot/dts/hi3620-hi4511.dts
@@ -16,7 +16,8 @@
 compatible = "hisilicon,hi3620-hi4511";

 chosen {
-bootargs = "console=ttyAMA0,115200 root=/dev/ram0 earlyprintk";
+bootargs = "root=/dev/ram0";
+stdout-path = "serial0:115200n8";
 };

 memory {
diff --git a/arch/arm/boot/dts/hisi-x5hd2-dkb.dts 
b/arch/arm/boot/dts/hisi-x5hd2-dkb.dts
index 721b092..d13af84 100644
--- a/arch/arm/boot/dts/hisi-x5hd2-dkb.dts
+++ b/arch/arm/boot/dts/hisi-x5hd2-dkb.dts
@@ -15,7 +15,7 @@
 compatible = "hisilicon,hix5hd2";

 chosen {
-bootargs = "console=ttyAMA0,115200 earlyprintk";
+stdout-path = "serial0:115200n8";
 };

 cpus {
-- 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 3/3] fpga manager: Adding FPGA Manager support for Xilinx Zynq 7000

[Josh Cartwright]

Hey Moritz-

On Fri, Oct 09, 2015 at 12:45:07AM +0200, Moritz Fischer wrote:
> This commit adds FPGA Manager support for the Xilinx Zynq chip.
> The code heavily borrows from the xdevcfg driver in Xilinx'
> vendor tree.
> 
> Signed-off-by: Moritz Fischer 
[..]
> +++ b/drivers/fpga/zynq-fpga.c
[..]
> +static irqreturn_t zynq_fpga_isr(int irq, void *data)
> +{
> + u32 intr_status;
> + struct zynq_fpga_priv *priv = data;
> +
> + spin_lock(>lock);

I'm confused about the locking here.  You have this lock, but it's only
used in the isr.  It's claimed purpose is to protect 'error', but that
clearly isn't happening.

> + intr_status = zynq_fpga_read(priv, INT_STS_OFFSET);
> +
> + if (!intr_status) {
> + spin_unlock(>lock);
> + return IRQ_NONE;
> + }
> +
> + zynq_fpga_write(priv, INT_STS_OFFSET, intr_status);
> +
> + if ((intr_status & IXR_D_P_DONE_MASK) == IXR_D_P_DONE_MASK)
> + complete(>dma_done);

Just so I understand, wouldn't you also want to complete() in the error
case, too?

> + if ((intr_status & IXR_ERROR_FLAGS_MASK) ==
> + IXR_ERROR_FLAGS_MASK) {
> + priv->error = true;
> + dev_err(priv->dev, "%s dma error\n", __func__);
> + }
> + spin_unlock(>lock);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int zynq_fpga_ops_write_init(struct fpga_manager *mgr, u32 flags,
> + const char *buf, size_t count)
> +{
> + struct zynq_fpga_priv *priv;
> + u32 ctrl, status;
> + int err;
> +
> + priv = mgr->priv;
> +
> + err = clk_enable(priv->clk);
> + if (err)
> + return err;
> +
> + /* only reset if we're not doing partial reconfig */
> + if (!(flags & FPGA_MGR_PARTIAL_RECONFIG)) {
> + /* assert AXI interface resets */
> + regmap_write(priv->slcr, SLCR_FPGA_RST_CTRL_OFFSET,
> +  FPGA_RST_ALL_MASK);
> +
> + /* disable level shifters */
> + regmap_write(priv->slcr, SLCR_LVL_SHFTR_EN_OFFSET,
> +  LVL_SHFTR_DISABLE_ALL_MASK);
> + /* enable output level shifters */
> + regmap_write(priv->slcr, SLCR_LVL_SHFTR_EN_OFFSET,
> +  LVL_SHFTR_ENABLE_PS_TO_PL);
> +
> + /* create a rising edge on PCFG_INIT. PCFG_INIT follows
> +  * PCFG_PROG_B, so we need to poll it after setting PCFG_PROG_B
> +  * to make sure the rising edge actually happens
> +  */
> + ctrl = zynq_fpga_read(priv, CTRL_OFFSET);
> + ctrl |= CTRL_PCFG_PROG_B_MASK;
> +
> + zynq_fpga_write(priv, CTRL_OFFSET, ctrl);
> +
> + zynq_fpga_poll_timeout(priv, STATUS_OFFSET, status, status &
> +STATUS_PCFG_INIT_MASK, 20, 0);

And if we timeout?

> +
> + ctrl = zynq_fpga_read(priv, CTRL_OFFSET);
> + ctrl &= ~CTRL_PCFG_PROG_B_MASK;
> +
> + zynq_fpga_write(priv, CTRL_OFFSET, ctrl);
> +
> + zynq_fpga_poll_timeout(priv, STATUS_OFFSET, status, !(status &
> +STATUS_PCFG_INIT_MASK), 20, 0);

And if we timeout?

> +
> + ctrl = zynq_fpga_read(priv, CTRL_OFFSET);
> + ctrl |= CTRL_PCFG_PROG_B_MASK;
> +
> + zynq_fpga_write(priv, CTRL_OFFSET, ctrl);
> +
> + zynq_fpga_poll_timeout(priv, STATUS_OFFSET, status, status &
> +STATUS_PCFG_INIT_MASK, 20, 0);

And if we timeout?

> + }
> +
> + clk_disable(priv->clk);
> +
> + return 0;
> +}
> +
> +static int zynq_fpga_ops_write(struct fpga_manager *mgr,
> +const char *buf, size_t count)
> +{
> + struct zynq_fpga_priv *priv;
> + int err;
> + char *kbuf;
> + size_t i, in_count;
> + dma_addr_t dma_addr;
> + u32 transfer_length = 0;
> + bool endian_swap = false;
> +
> + in_count = count;
> + priv = mgr->priv;
> +
> + kbuf = dma_alloc_coherent(priv->dev, count, _addr, GFP_KERNEL);
> + if (!kbuf)
> + return -ENOMEM;
> +
> + memcpy(kbuf, buf, count);
> +
> + /* look for the sync word */
> + for (i = 0; i < count - 4; i++) {
> + if (memcmp(kbuf + i, "\x66\x55\x99\xAA", 4) == 0) {
> + dev_dbg(priv->dev, "Found normal sync word\n");
> + endian_swap = false;
> + break;
> + }
> + if (memcmp(kbuf + i, "\xAA\x99\x55\x66", 4) == 0) {
> + dev_dbg(priv->dev, "Found swapped sync word\n");
> + endian_swap = true;
> + break;
> + }
> + }

How much control do we have over mandating the format of firmware at
this point?  It'd be swell if we could just mandate a specific
endianness, and leave this munging to usermode.

> + /* remove the 

Re: [PATCH] trace: stop critical timings before idle loop on idle=poll

[Steven Rostedt]

On Thu,  8 Oct 2015 15:36:06 -0300
Daniel Bristot de Oliveira  wrote:

> When using idle=poll, the preemptoff tracer is always showing the idle
> task as the culprit for long latencies. That happens because critical
> timings are not stopped before idle loop. This patch stops critical
> timings before entering the idle loop, starting it again after the
> idle loop.
> 
> This problem does not affect the irqsoff tracer because interruptions
> are enabled before entering the idle loop.
> 
> Signed-off-by: Daniel Bristot de Oliveira 
> Reviewed-by: Luis Claudio R. Goncalves 

Acked-by: Steven Rostedt 

-- Steve

> ---
>  kernel/sched/idle.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
> index 8f177c7..4a2ef5a 100644
> --- a/kernel/sched/idle.c
> +++ b/kernel/sched/idle.c
> @@ -57,9 +57,11 @@ static inline int cpu_idle_poll(void)
>   rcu_idle_enter();
>   trace_cpu_idle_rcuidle(0, smp_processor_id());
>   local_irq_enable();
> + stop_critical_timings();
>   while (!tif_need_resched() &&
>   (cpu_idle_force_poll || tick_check_broadcast_expired()))
>   cpu_relax();
> + start_critical_timings();
>   trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, smp_processor_id());
>   rcu_idle_exit();
>   return 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] locktorture: fix wrong parameter handling

[Paul E. McKenney]

On Fri, Oct 09, 2015 at 04:53:49PM +0200, Christian Borntraeger wrote:
> Am 09.10.2015 um 16:46 schrieb Paul E. McKenney:
> > On Fri, Oct 09, 2015 at 02:14:45PM +0200, Christian Borntraeger wrote:
> >> Calling locktorture with a wrong parameter makes it
> >> unusable:
> >>
> >> $ modprobe locktorture torture_type=help
> >> modprobe: ERROR: could not insert 'locktorture': Invalid argument
> >>
> >> $ modprobe locktorture torture_type=spin_lock
> >> modprobe: ERROR: could not insert 'locktorture': Device or resource busy
> >>
> >> $ dmesg
> >> [...]
> >> torture_init_begin: refusing spin_lock init: help running
> >>
> >> We can easily do the checking before call into the torture framework.
> >>
> >> Signed-off-by: Christian Borntraeger 
> > 
> > Good catch, thank you!
> > 
> > Could you please port this to rcu/next in the -rcu tree?  Also, please
> > capitalize the word following the ":" in the subject line, as in "[PATCH]
> > locktorture: Fix wrong parameter handling".
> 
> Hmmm, seems that this is already fixed in rcu/next with
> 
> commit a36a99618b1adb2d6ca0b7e08e3a656a04e477fe
> Author: Paul E. McKenney 
> AuthorDate: Sun Aug 30 20:01:48 2015 -0700
> Commit: Paul E. McKenney 
> CommitDate: Tue Oct 6 11:28:44 2015 -0700
> 
> locktorture: Fix module unwind when bad torture_type specified
> 
> 
> No need to respin a patch it seems :-)

Works for me!  ;-)

Thanx, Paul

--
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/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

[Mark Rutland]

On Fri, Oct 09, 2015 at 03:11:07PM +0100, Liviu Dudau wrote:
> On Fri, Oct 09, 2015 at 08:54:33AM -0500, Rob Herring wrote:
> > On Fri, Oct 9, 2015 at 8:45 AM, Liviu Dudau  wrote:
> > > Juno R1 board sports a functional PCIe host bridge that is
> > > compliant with the SBSA standard found here[1]. With the right
> > > firmware that initialises the XpressRICH3 controller one can
> > > use the generic Host Bridge driver to use the PCIe hardware.
> > >
> > > Signed-off-by: Liviu Dudau 
> > >
> > > [1] http://infocenter.arm.com/help/topic/com.arm.doc.den0029a/
> > > ---
> > >  arch/arm64/boot/dts/arm/juno-r1.dts | 20 
> > >  1 file changed, 20 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts 
> > > b/arch/arm64/boot/dts/arm/juno-r1.dts
> > > index c627511..a702a6b 100644
> > > --- a/arch/arm64/boot/dts/arm/juno-r1.dts
> > > +++ b/arch/arm64/boot/dts/arm/juno-r1.dts
> > > @@ -109,6 +109,26 @@
> > >
> > > #include "juno-base.dtsi"
> > >
> > > +   pcie-controller@4000 {
> > > +   compatible = "pci-host-ecam-generic";
> > 
> > I think this is the first case of real h/w using this. We should have
> > a specific compatible here additionally.
> 
> Or maybe I can claim the use of the string on account on being the first on 
> arm64 ;)
> 
> I can add a vendor prefix if you want, but pci-host-generic is going to 
> ignore it 
> *because* it is trying to be a generic driver.

The point here is to have the string ready if we need it later, so it's
fine that it's not used currently.

Rob's suggestion is that the compatible list should look something like:

compatible = "arm,juno-r1-pcie", "plda,xpressrich3", "pci-host-ecam-generic";

We can match on "pci-host-ecam-generic" for now (and hopefully forever),
but if for some reason we need to special-case this host controller (or
Juno's integration thereof), we can do that based on the compatible
string.

Thanks,
Mark.
--
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] arm: add relocate initrd support

[yalin wang]

Add support for initrd on ARM arch, in case
mem= boot option change the memory size or the initrd are
not placed in low memory region, we need copy the initrd
to low memory region.

Signed-off-by: yalin wang 
---
 arch/arm/include/asm/fixmap.h |  1 +
 arch/arm/kernel/setup.c   | 72 +++
 2 files changed, 73 insertions(+)

diff --git a/arch/arm/include/asm/fixmap.h b/arch/arm/include/asm/fixmap.h
index 58cfe9f..18ad90f 100644
--- a/arch/arm/include/asm/fixmap.h
+++ b/arch/arm/include/asm/fixmap.h
@@ -10,6 +10,7 @@
 
 enum fixed_addresses {
FIX_EARLYCON_MEM_BASE,
+   FIX_RELOCATE_INITRD,
__end_of_permanent_fixed_addresses,
 
FIX_KMAP_BEGIN = __end_of_permanent_fixed_addresses,
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 20edd34..4260d59 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -811,6 +811,77 @@ static void __init request_standard_resources(const struct 
machine_desc *mdesc)
request_resource(_resource, );
 }
 
+#if defined(CONFIG_BLK_DEV_INITRD) && defined(CONFIG_MMU)
+/*
+ * Relocate initrd if it is not completely within the linear mapping.
+ * This would be the case if mem= cuts out all or part of it
+ * or the initrd are not in low mem region place.
+ */
+static void __init relocate_initrd(void)
+{
+   phys_addr_t orig_start = __virt_to_phys(initrd_start);
+   phys_addr_t orig_end = __virt_to_phys(initrd_end);
+   phys_addr_t ram_end = memblock_end_of_DRAM();
+   phys_addr_t new_start;
+   phys_addr_t src;
+   unsigned long size, to_free = 0;
+   unsigned long slop, clen, p;
+   void *dest;
+
+   if (orig_end <= memblock_get_current_limit())
+   return;
+
+   /*
+* Any of the original initrd which overlaps the linear map should
+* be freed after relocating.
+*/
+   if (orig_start < ram_end)
+   to_free = min(ram_end, orig_end) - orig_start;
+
+   size = orig_end - orig_start;
+
+   /* initrd needs to be relocated completely inside linear mapping */
+   new_start = memblock_find_in_range(0, 0, size, PAGE_SIZE);
+   if (!new_start)
+   panic("Cannot relocate initrd of size %ld\n", size);
+   memblock_reserve(new_start, size);
+
+   initrd_start = __phys_to_virt(new_start);
+   initrd_end   = initrd_start + size;
+
+   pr_info("Moving initrd from [%llx-%llx] to [%llx-%llx]\n",
+   (unsigned long long)orig_start,
+   (unsigned long long)(orig_start + size - 1),
+   (unsigned long long)new_start,
+   (unsigned long long)(new_start + size - 1));
+
+   dest = (void *)initrd_start;
+
+   src = orig_start;
+   while (size) {
+   slop = src & ~PAGE_MASK;
+   clen = min(PAGE_SIZE - slop, size);
+   p = set_fixmap_offset(FIX_RELOCATE_INITRD, src);
+   memcpy(dest, (void *)p, clen);
+   clear_fixmap(FIX_RELOCATE_INITRD);
+   dest += clen;
+   src += clen;
+   size -= clen;
+   }
+
+   if (to_free) {
+   pr_info("Freeing original RAMDISK from [%llx-%llx]\n",
+   (unsigned long long)orig_start,
+   (unsigned long long)(orig_start + to_free - 1));
+   memblock_free(orig_start, to_free);
+   }
+}
+#else
+static inline void __init relocate_initrd(void)
+{
+}
+#endif
+
 #if defined(CONFIG_VGA_CONSOLE) || defined(CONFIG_DUMMY_CONSOLE)
 struct screen_info screen_info = {
  .orig_video_lines = 30,
@@ -969,6 +1040,7 @@ void __init setup_arch(char **cmdline_p)
arm_memblock_init(mdesc);
 
paging_init(mdesc);
+   relocate_initrd();
request_standard_resources(mdesc);
 
if (mdesc->restart)
-- 
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 1/9] drm: bridge/dw_hdmi-ahb-audio: add audio driver

[Russell King - ARM Linux]

On Tue, Oct 06, 2015 at 05:25:16PM -0300, Fabio Estevam wrote:
> On Tue, Oct 6, 2015 at 3:54 PM, Russell King - ARM Linux
>  wrote:
> 
> > Make sure you have the ALSA config file, as alsalib won't get on
> > with dw-hdmi only accepting 24-bit audio without this.  A copy is
> > attached.  It also tells ALSA how to deal with multi-channel audio
> > as well.
> 
> Thanks, Russell!
> 
> Got audio to play on my HDMI TV :-)
> 
> For the entire series:
> 
> Tested-by: Fabio Estevam 

Just to confirm - that's for _all_ of these 8 patches, including the
changes to the ACR code in the last four patches, and you're happy that
I send all of these:

drm: bridge/dw_hdmi-ahb-audio: add audio driver
drm: bridge/dw_hdmi-ahb-audio: parse ELD from HDMI driver
drm: bridge/dw_hdmi-ahb-audio: basic support for multi-channel PCM audio
drm: bridge/dw_hdmi-ahb-audio: allow larger buffer sizes
drm: bridge/dw_hdmi: avoid being recursive in N calculation
drm: bridge/dw_hdmi: adjust pixel clock values in N calculation
drm: bridge/dw_hdmi: remove ratio support from ACR code
drm: bridge/dw_hdmi: replace CTS calculation for the ACR

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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] clocksource/drivers/tango_xtal: Add new timer for Tango SoCs

[Måns Rullgård]

Marc Gonzalez  writes:

> Måns Rullgård wrote:
>
>> Marc Gonzalez wrote:
>> 
>>> Sigma Designs Tango platforms provide a 27 MHz crystal oscillator.
>>> Use it for clocksource, sched_clock, and delay_timer.
>> 
>> Given the nature of this hardware, I think it would make much more sense
>> to support it in a generic fashion.  Otherwise the next chip that comes
>> along with a similar counter will result in near duplicate of this
>> "driver", and so on.
>
> I didn't /want/ to write this driver, or rather this "driver" as you put it
> (implying that it is so trivial that I am lame even to submit it). It was
> living happily in arch/arm/clock-tango.c, but Arnd pointed out that such
> code must migrate to drivers/clocksource.
>
> I find your claim that this minimal device (a single register really) should
> be supported in a generic fashion questionable. No one seems to have ever
> needed this, yet it has suddenly become urgent to have it right now?

Apparently, nobody has needed it before (I can't say for sure that no
existing drivers could be simplified).  That doesn't mean that nobody
will need it again.  When something can be supported in a generic way,
it is usually a good idea to do that.  It saves work in the long term.

> I'm sorry if my mainlining effort is not compatible with your schedule, but
> I've been working on this port for 6 months, and I can't wait a few more
> weeks just because you're not quite ready. (Have you mainstreamed the eth
> and intc driver? I would actually need those.)

You (Sigma) had the chance to contract me to help out with this work and
strongly indicated ("we will send you a contract for review by the end
of the week") that you would.  Then you backtracked in a rather ugly
manner.  Forgive me if I'm less than motivated to suddenly spend hours
of unpaid time helping you get things in shape.  If you don't want to
pay me, you also don't get to set my schedule.  Besides, you've never
shown any interest whatsoever in upstreaming before, so I really don't
see why it is so urgent for you now.

-- 
Måns Rullgård
m...@mansr.com
--
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/9] drm: bridge/dw_hdmi-ahb-audio: add audio driver

[Fabio Estevam]

On Fri, Oct 9, 2015 at 1:00 PM, Russell King - ARM Linux
 wrote:

>> Thanks, Russell!
>>
>> Got audio to play on my HDMI TV :-)
>>
>> For the entire series:
>>
>> Tested-by: Fabio Estevam 
>
> Just to confirm - that's for _all_ of these 8 patches, including the
> changes to the ACR code in the last four patches, and you're happy that
> I send all of these:
>
> drm: bridge/dw_hdmi-ahb-audio: add audio driver
> drm: bridge/dw_hdmi-ahb-audio: parse ELD from HDMI driver
> drm: bridge/dw_hdmi-ahb-audio: basic support for multi-channel PCM audio
> drm: bridge/dw_hdmi-ahb-audio: allow larger buffer sizes
> drm: bridge/dw_hdmi: avoid being recursive in N calculation
> drm: bridge/dw_hdmi: adjust pixel clock values in N calculation
> drm: bridge/dw_hdmi: remove ratio support from ACR code
> drm: bridge/dw_hdmi: replace CTS calculation for the ACR

That's correct. Thanks, Russell
--
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 0/3] make stopper threads more "selfparking"

[Oleg Nesterov]

On top of "[PATCH 0/3]" I sent yesterday, although it doesn't
really depend on that series.

Peter, note that 3/3 is from you ;) I hope you won't object.

Thomas, could you please comment? 1/3 looks like a cleanup to me
(if correct), but cleanups are always subjective, so please nack
if you don't like it for any reason.

Oleg.

 include/linux/smpboot.h  |4 
 include/linux/stop_machine.h |1 +
 kernel/sched/core.c  |5 -
 kernel/smpboot.c |5 ++---
 kernel/stop_machine.c|8 +++-
 5 files changed, 10 insertions(+), 13 deletions(-)

--
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/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

[Liviu Dudau]

On Fri, Oct 09, 2015 at 05:49:18PM +0200, Arnd Bergmann wrote:
> On Friday 09 October 2015 16:44:08 Mark Rutland wrote:
> > On Fri, Oct 09, 2015 at 03:11:07PM +0100, Liviu Dudau wrote:
> > > On Fri, Oct 09, 2015 at 08:54:33AM -0500, Rob Herring wrote:
> > > Or maybe I can claim the use of the string on account on being the first 
> > > on arm64 
> > > 
> > > I can add a vendor prefix if you want, but pci-host-generic is going to 
> > > ignore it 
> > > *because* it is trying to be a generic driver.
> > 
> > The point here is to have the string ready if we need it later, so it's
> > fine that it's not used currently.
> > 
> > Rob's suggestion is that the compatible list should look something like:
> > 
> > compatible = "arm,juno-r1-pcie", "plda,xpressrich3", 
> > "pci-host-ecam-generic";
> > 
> > We can match on "pci-host-ecam-generic" for now (and hopefully forever),
> > but if for some reason we need to special-case this host controller (or
> > Juno's integration thereof), we can do that based on the compatible
> > string.
> 
> Sounds good to me, it certainly can't hurt.
> 
>   Arnd

Hmm, I'm sorry, but this time I'm going to disagree.

I understand the principle that the DTS is a description of the hardware and it 
should
not have any built in knowledge of how a driver works but describe the physical 
properties
of the device (where such description makes sense, in this case it does).

However, when ARM has created the Juno platform it has also created a standard 
called
SBSA and has claimed that Juno is compliant with that standard. My current 
position (and
it used to be MarkR's as well when we have argued internally the pros and cons 
of having
a bespoke driver for PLDA's XpressRICH3) is that SBSA compliant behaviour *is* 
the expected
behaviour and if the device doesn't conform it needs to be fixed in firmware.

Otherwise, I could've posted months ago the other public driver[1] that I've 
wrote that
doesn't depend on firmware and could have been done with this long time ago.

Best regards,
Liviu

1. 
https://github.com/ARM-software/linux/commit/ca9d82679916c3b6bdb846319e343a43a6bbb31c


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

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
--
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 v7 03/60] sparc/PCI: Unify pci_register_region()

[Khalid Aziz]

On Thu, 2015-10-08 at 14:38 -0700, Yinghai Lu wrote:
> We register regions for legacy and iommu and all have open code.
> 
> Unify them to pci_register_region() and call it accordingly.
> 
> Signed-off-by: Yinghai Lu 


Tested on sparc platforms

Tested-by: Khalid Aziz  




--
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/