Re: [PATCH] acpi_i2c: set MODULE_LICENSE, MODULE_AUTHOR, and MODULE_DESCRIPTION

[Jerry Snitselaar]

Sorry for the double send. This one was apparently blocked by the
greylisting on vger.kernel.org and it was hours before I received
notification of that. I forgot to bcc myself and had no record of the
git send-email successfully completing. Just ignore this patch.

Jerry
--
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/3] ixgbe: request_firmware for configuration parameters

[Greg KH]

On Fri, Aug 16, 2013 at 05:18:12PM -0700, Ali Ayoub wrote:
> On 8/16/2013 3:39 PM, Greg KH wrote:
> > On Fri, Aug 16, 2013 at 03:14:31PM -0700, Ali Ayoub wrote:
> >> On 1/11/2013 11:41 AM, Greg KH wrote:
> > 
> > Seriously?  Restarting a thread from over 6 months ago?
> 
> Yes, it's an old thread, but still relevant for current code.

Which specific code are you referring to?

> > Why?
> 
> Because currently there is no good alternative for module params for
> device drivers that need to have low level configs in init time.

I disagree, see below for why module params are broken for this.

> >> Other device drivers of other vendors (not only netdevs) need such a
> >> mechanism as well,
> > 
> > Specifics please.
> >
> >> I think it's a general requirement for many drivers that normally need
> >> low level configurations for device initialization in the very first
> >> stage of the driver load.
> > 
> > I do not, but feel free to prove me otherwise.
> 
> A driver that claims the PCI device needs some configuration in init
> time such as: amount of resources to be allocated in the cache,
> interrupt mode, maximum allowed resources to be created for a specific
> type, number of event queues, etc. See for example:
> /drivers/net/ethernet/mellanox/mlx4/main.c
> 
> This driver doesn't necessary register a logical device, it may claim
> the PCI device only (e.g. for an HCA), and provide an infrastructure for
> upper layer protocols to register a logical device (nic, hba, etc.) on
> top of it.

And how do you handle hundreds of the same card in the same machine?
You can't do that with module paramaters at all, it doesn't scale, or
make any sense.

What about hotplug of new devices after the module is loaded?  That will
not work at all for module parameters either.

That is why we created sysfs, and configfs.

> The type of configuration needed varies between vendors, and they are
> normally passed in HW initialization stage. So even if we have a tool to
> configure the device (such as ethtool for netdevs) it wouldn't be a
> replacement for the module param, because some systems requires
> non-default (init) configurations, and if we load the driver with the
> default, and then use a user-space tool to "adjust" the configuration
> we'll have a "glitch" where the driver was loaded with unsuitable
> configs for the system.

No, just remain in a "unusable" state until you are initialized from
userspace.  No "glitch" at all.

> >>> All of the above issues you seem to have with sysfs and configfs can be
> >>> resolved with userspace code, and having your driver not do anything to
> >>> the hardware until it is told to by userspace.
> >>
> >> To tell the driver not to do anything until it's configured by a
> >> userspace code will require a module param for non-default-configs
> >> (which brings us back to the original argument of avoiding module params).
> > 
> > No, never use a module paramater for configuring a driver or a device.
> > That's not what they are there for.
> >
> >> By having userspace code to feed configfs/sysfs nodes, and making it
> >> available in initrd; we will end up having similar mechanism to
> >> request_firmware().
> > 
> > Close, but not the same.  That's why we created configfs, please use it.
> 
> configfs requires from the driver to provide the hooks before the HW is
> initialized, while module params allow passing information to the driver
> in init time before any driver hooks are ready.

And module params don't work at all for the common usage of hotplug
devices, and multiple numbers of devices that show up _after_ the module
is loaded.

> The proposal of changing the driver not to configure the HW until it's
> triggered by userspace service through configfs, means that we need:
> 
> a. To have driver config to toggle between the mode where the driver
> "waits" for configfs, and the "auto" mode where the driver loads with
> the default-configs (when using mod params for example, the driver
> simply loads with the defaults when there is modprobe config files).
> 
> b. To have the userspace mechanism to feed the configs nodes, to store
> the configs in a file to keep them persistent between reboots, and make
> these userspace services available in initrd.

Does this really need to be in the initrd?  That's only needed for your
boot device, and if you need it there, great, put it there, that's what
dracut is there for, it's a full Linux system in the initrd.

configfs, for complex initializations like you are proposing, works,
that is why it was created, and what it is used for.  Yes, it's "rough"
in places, and a bit complex.  Patches to fix that are always gladly
appreciated.

> I don't see how this is better than module params, or
> request_firmware_config().

request_firmware is for just that, firmware, not configuration values,
sorry.  Use configfs for configuration, that's what it is there for.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe 

[PATCH] s390: Fix broken build

[Guenter Roeck]

Fix:

In file included from fs/exec.c:61:0:
arch/s390/include/asm/tlb.h:35:23: error: expected identifier or '(' before 
'unsigned'
arch/s390/include/asm/tlb.h:36:1: warning: no semicolon at end of struct or 
union [enabled by default]
arch/s390/include/asm/tlb.h: In function 'tlb_gather_mmu':
arch/s390/include/asm/tlb.h:57:5: error: 'struct mmu_gather' has no member 
named 'end'
make[1]: *** [fs/exec.o] Error 1

Broken due to commit 2b047252d0 (Fix TLB gather virtual address range
invalidation corner cases).

Cc: Linus Torvalds 
Cc: Greg Kroah-Hartman 
Cc: sta...@vger.kernel.org
Signed-off-by: Guenter Roeck 
---
 arch/s390/include/asm/tlb.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/s390/include/asm/tlb.h b/arch/s390/include/asm/tlb.h
index 23a64d2..6d6d92b 100644
--- a/arch/s390/include/asm/tlb.h
+++ b/arch/s390/include/asm/tlb.h
@@ -32,7 +32,7 @@ struct mmu_gather {
struct mm_struct *mm;
struct mmu_table_batch *batch;
unsigned int fullmm;
-   unsigned long start, unsigned long end;
+   unsigned long start, end;
 };
 
 struct mmu_table_batch {
-- 
1.7.9.7

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

[PATCH] acpi_i2c: set MODULE_LICENSE, MODULE_AUTHOR, and MODULE_DESCRIPTION

[Jerry Snitselaar]

Without MODULE_LICENSE get, I get the following with modprobe:

acpi_i2c: module license 'unspecified' taints kernel.
acpi_i2c: Unknown symbol i2c_new_device (err 0)
acpi_i2c: Unknown symbol acpi_dev_get_resources (err 0)
acpi_i2c: Unknown symbol acpi_dev_resource_interrupt (err 0)
acpi_i2c: Unknown symbol acpi_dev_free_resource_list (err 0)

Signed-off-by: Jerry Snitselaar 
---
 drivers/acpi/acpi_i2c.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/acpi/acpi_i2c.c b/drivers/acpi/acpi_i2c.c
index 82045e3..2c5c65d 100644
--- a/drivers/acpi/acpi_i2c.c
+++ b/drivers/acpi/acpi_i2c.c
@@ -14,9 +14,14 @@
 #include 
 #include 
 #include 
+#include 
 
 ACPI_MODULE_NAME("i2c");
 
+MODULE_DESCRIPTION("ACPI I2C enumeration support");
+MODULE_AUTHOR("Mika Westerberg");
+MODULE_LICENSE("GPL");
+
 static int acpi_i2c_add_resource(struct acpi_resource *ares, void *data)
 {
struct i2c_board_info *info = data;
-- 
1.8.4.rc3.2.g2c2b664

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

[ANNOUNCE] 3.0.89-rt117

[Steven Rostedt]

Dear RT Folks,

I'm pleased to announce the 3.0.89-rt117 stable release.


This release is just an update to the new stable 3.0.89 version
and no RT specific changes have been made.


You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  branch: v3.0-rt
  Head SHA1: 714ab80b94ce6bcd33d9c3320bec3556b54be361


Or to build 3.0.89-rt117 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.0/patch-3.0.89.xz

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.0/patch-3.0.89-rt117.patch.xz




Enjoy,

-- Steve

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

[ANNOUNCE] 3.2.50-rt70

[Steven Rostedt]

Dear RT Folks,

I'm pleased to announce the 3.2.50-rt70 stable release.


This release is just an update to the new stable 3.2.50 version
and no RT specific changes have been made.


You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  branch: v3.2-rt
  Head SHA1: 0bf3e8489c9b5a215e8169ee8466556a7af414d2


Or to build 3.2.50-rt70 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.2.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.2.50.xz

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/patch-3.2.50-rt70.patch.xz




Enjoy,

-- Steve

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

[ANNOUNCE] 3.4.57-rt72

[Steven Rostedt]

Dear RT Folks,

I'm pleased to announce the 3.4.57-rt72 stable release.


This release is just an update to the new stable 3.4.57 version
and no RT specific changes have been made.


You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  branch: v3.4-rt
  Head SHA1: a7e9bc3835e61436f8fb845e8ac1c3a42aef78d1


Or to build 3.4.57-rt72 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.4.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.4.57.xz

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.4/patch-3.4.57-rt72.patch.xz




Enjoy,

-- Steve

--
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] x86, apic: Enable x2APIC physical when cpu < 256 native

[Youquan Song]

> No problem - you might want to send another patch adding some comments to 
> the code, explaining why we don't switch to physical mode, quoting from 
> the SDM and so.

Here is the revert patch.

Subject: [PATCH] Revert "x86/apic: Enable x2APIC physical mode on native 
hardware too, when there are fewer than 256 CPUs"

x2APIC without interrupt remapping is not architecture and no guarantee it 
will work in future.
There are some words in SDM3, 10.12.7 Initialization by System
Software Routing of device interrupts to local APIC units operating in 
x2APIC mode requires use of the interrupt-remapping architecture 
specified in the Intel Virtualization Technology for Directed I/O, 
Revision 1.3. Because of this, BIOS must enumerate support for and 
software must enable this interrupt remapping with Extended Interrupt 
Mode Enabled before it enabling x2APIC mode in the local APIC units.

This reverts commit 3d1acb49d22fbbae96524040e9e2d4cbbb3adbef, do not use
x2apic_pysical mode if interrupt remapping is not enabled even at CPU
number fewer than 256.

Signed-off-by: Youquan Song 
---
 arch/x86/kernel/apic/apic.c |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index d9dd5a6..eca89c5 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1622,8 +1622,11 @@ void __init enable_IR_x2apic(void)
goto skip_x2apic;
 
if (ret < 0) {
-   /* IR is required if there is APIC ID > 255 */
-   if (max_physical_apicid > 255) {
+   /* IR is required if there is APIC ID > 255 even when running
+* under KVM
+*/
+   if (max_physical_apicid > 255 ||
+   !hypervisor_x2apic_available()) {
if (x2apic_preenabled)
disable_x2apic();
goto skip_x2apic;
-- 
1.6.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: Non-enumerable devices on USB and other enumerable buses

[Alan Stern]

On Fri, 16 Aug 2013, Mark Brown wrote:

> > Besides, you need to get the platform information to the driver in any 
> > case, no matter how you decide to solve the chicken-and-egg problem.  
> > It shouldn't be a factor in deciding which solution to use.
> 
> It's not that this is hard, it's that I don't see how if you already
> have some concept of the device in the kernel data structures (which you
> must have in order to be able to provide platform data when it's needed)
> anything is gained by not using that when dealing with bootstrapping
> issues.

I agree.  In fact, there's no choice but to use this device concept
during startup.  Otherwise there's no way to get the platform data to
the driver when it is needed, because there's no way to tell which
device the data applies to.  The question is how elaborate the concept
needs to be and how it gets used.

Aong those lines, I would like to point out that the device concept
embodied in the kernel's data structures can be pretty thin.  For
example, it might be little more than a port number or bus address.

> Anyway, I think it's time to try to implement something rather than talk
> about it.

Hopefully this discussion has given you some ideas for alternative 
approachs, or at least helped to solidify your ideas.

Alan Stern

--
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] input: misc: New USB eBeam input driver

[Yann Cantin]

Signed-off-by: Yann Cantin 
---
 Documentation/ABI/testing/sysfs-driver-ebeam |  53 ++
 drivers/input/misc/Kconfig   |  22 +
 drivers/input/misc/Makefile  |   1 +
 drivers/input/misc/ebeam.c   | 763 +++
 4 files changed, 839 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-ebeam
 create mode 100644 drivers/input/misc/ebeam.c

diff --git a/Documentation/ABI/testing/sysfs-driver-ebeam 
b/Documentation/ABI/testing/sysfs-driver-ebeam
new file mode 100644
index 000..552a428
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-ebeam
@@ -0,0 +1,53 @@
+What:  /sys/class/input/inputXX/device/min_x
+   /sys/class/input/inputXX/device/min_y
+   /sys/class/input/inputXX/device/max_x
+   /sys/class/input/inputXX/device/max_y
+Date:  Jul 2013
+Kernel Version:3.11
+Contact:   yann.can...@laposte.net
+   linux-...@vger.kernel.org
+Description:
+   Reading from these files return the actually used range values 
of
+   the reported coordinates.
+   Writing to these files preset these range values.
+   See below for the calibration procedure.
+
+What:  /sys/class/input/inputXX/device/h[1..9]
+Date:  Jul 2013
+Kernel Version:3.11
+Contact:   yann.can...@laposte.net
+   linux-...@vger.kernel.org
+Description:
+   Reading from these files return the 3x3 transformation matrix 
elements
+   actually used, in row-major.
+   Writing to these files preset these elements values.
+   See below for the calibration procedure.
+
+What:  /sys/class/input/inputXX/device/calibrated
+Date:  Jul 2013
+Kernel Version:3.11
+Contact:   yann.can...@laposte.net
+   linux-...@vger.kernel.org
+Description:
+   Reading from this file :
+   - Return 0 if the driver is in "un-calibrated" mode : it 
actually send
+ raw coordinates in the device's internal coordinates system.
+   - Return 1 if the driver is in "calibrated" mode : it send 
computed coordinates
+ that (hopefully) matches the screen's coordinates system.
+   Writing 1 to this file enable the "calibrated" mode, 0 reset 
the driver in
+   "un-calibrated" mode.
+
+Calibration procedure :
+
+When loaded, the driver is in "un-calibrated" mode : it send device's raw 
coordinates
+in the [0..65535]x[0..65535] range, the transformation matrix is the identity.
+
+A calibration program have to compute a homography transformation matrix that 
convert
+the device's raw coordinates to the matching screen's ones.
+It then write to the appropriate sysfs files the computed values, pre-setting 
the
+driver's parameters : xy range, and the matrix's elements.
+When all values are passed, it write 1 to the calibrated sysfs file to enable 
the "calibrated" mode.
+
+Warning : The parameters aren't used until 1 is writen to the calibrated sysfs 
file.
+
+Writing 0 to the calibrated sysfs file reset the driver in "un-calibrated" 
mode.
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 0b541cd..454df2d 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -93,6 +93,28 @@ config INPUT_BMA150
  To compile this driver as a module, choose M here: the
  module will be called bma150.
 
+config INPUT_EBEAM_USB
+   tristate "USB eBeam driver"
+   depends on USB_ARCH_HAS_HCD
+   select USB
+   help
+ Say Y here if you have a USB eBeam pointing device and want to
+ use it without any proprietary user space tools.
+
+ Have a look at  for
+ a usage description and the required user-space tools.
+
+ Supported devices :
+   - Luidia eBeam Classic Projection and eBeam Edge Projection
+   - Nec NP01Wi1 & NP01Wi2 interactive solution
+
+ Supposed working devices, need test, may lack functionnality :
+   - Luidia eBeam Edge Whiteboard and eBeam Engage
+   - Hitachi Starboard FX-63, FX-77, FX-82, FX-77GII
+
+ To compile this driver as a module, choose M here: the
+ module will be called ebeam.
+
 config INPUT_PCSPKR
tristate "PC Speaker support"
depends on PCSPKR_PLATFORM
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 829de43..dd2fe33 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_INPUT_COBALT_BTNS)   += cobalt_btns.o
 obj-$(CONFIG_INPUT_DA9052_ONKEY)   += da9052_onkey.o
 obj-$(CONFIG_INPUT_DA9055_ONKEY)   += da9055_onkey.o
 obj-$(CONFIG_INPUT_DM355EVM)   += dm355evm_keys.o
+obj-$(CONFIG_INPUT_EBEAM_USB)  += ebeam.o
 obj-$(CONFIG_INPUT_GP2A) 

[PATCH 0/2] new USB eBeam input driver

[Yann Cantin]

Hi,

New USB input driver for eBeam devices.

Currently supported (tested) :
- Luidia eBeam classic projection and edge projection models
- Nec "interactive solution" NP01Wi1 & NP01Wi2 accessories.

>From basic usb point of view, all these devices are
indistinguishable : they have the same usb ids and (blank) hid
report descriptors. There's other re-branded hardware that need to be
test, but i bet on same ids.

Patch 1 to blacklist the devices for hid generic-usb.

Patch 2 is the actual driver.

Notable stuff :
- use div64_s64 for portable 64/64-bits divisions.
- 13 sysfs custom files : 9 values for the transformation matrix,
  4 for xy ranges and a calibration trigger.

The module run fine since 3.3.6 kernel, both x86_32 and 64, actually
run in production on a 3.8.13 and compile without errors on
today's linus tree.

Side note :
- This driver was first submit and discuss last year.

Thanks for your help.

--
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] hid: Blacklist eBeam devices

[Yann Cantin]

Signed-off-by: Yann Cantin 
---
 drivers/hid/hid-core.c | 3 +++
 drivers/hid/hid-ids.h  | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 36668d1..da5dfa0 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1985,6 +1985,9 @@ static const struct hid_device_id hid_ignore_list[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_DELORME, USB_DEVICE_ID_DELORME_EM_LT20) 
},
{ HID_USB_DEVICE(USB_VENDOR_ID_DREAM_CHEEKY, 0x0004) },
{ HID_USB_DEVICE(USB_VENDOR_ID_DREAM_CHEEKY, 0x000a) },
+#if defined(CONFIG_INPUT_EBEAM_USB)
+   { HID_USB_DEVICE(USB_VENDOR_ID_EFI, USB_DEVICE_ID_EFI_EBEAM) },
+#endif
{ HID_USB_DEVICE(USB_VENDOR_ID_ESSENTIAL_REALITY, 
USB_DEVICE_ID_ESSENTIAL_REALITY_P5) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ETT, USB_DEVICE_ID_TC5UH) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ETT, USB_DEVICE_ID_TC4UM) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index ffe4c7a..abd1c53 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -288,6 +288,9 @@
 #define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_73F7  0x73f7
 #define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_A001  0xa001
 
+#define USB_VENDOR_ID_EFI  0x2650
+#define USB_DEVICE_ID_EFI_EBEAM0x1311
+
 #define USB_VENDOR_ID_ELECOM   0x056e
 #define USB_DEVICE_ID_ELECOM_BM084 0x0061
 
-- 
1.8.1.5

--
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] acpi_i2c: set MODULE_LICENSE, MODULE_AUTHOR, and MODULE_DESCRIPTION

[Jerry Snitselaar]

Without MODULE_LICENSE set, I get the following with modprobe:

acpi_i2c: module license 'unspecified' taints kernel.
acpi_i2c: Unknown symbol i2c_new_device (err 0)
acpi_i2c: Unknown symbol acpi_dev_get_resources (err 0)
acpi_i2c: Unknown symbol acpi_dev_resource_interrupt (err 0)
acpi_i2c: Unknown symbol acpi_dev_free_resource_list (err 0)

Signed-off-by: Jerry Snitselaar 
---
 drivers/acpi/acpi_i2c.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/acpi/acpi_i2c.c b/drivers/acpi/acpi_i2c.c
index 82045e3..2c5c65d 100644
--- a/drivers/acpi/acpi_i2c.c
+++ b/drivers/acpi/acpi_i2c.c
@@ -14,9 +14,14 @@
 #include 
 #include 
 #include 
+#include 
 
 ACPI_MODULE_NAME("i2c");
 
+MODULE_DESCRIPTION("ACPI I2C enumeration support");
+MODULE_AUTHOR("Mika Westerberg");
+MODULE_LICENSE("GPL");
+
 static int acpi_i2c_add_resource(struct acpi_resource *ares, void *data)
 {
struct i2c_board_info *info = data;
-- 
1.8.4.rc3.2.g2c2b664

--
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] Correct the LZ4 license

[Kyungsik Lee]

On Fri, Aug 16, 2013 at 04:45:29PM -0500, Richard Laager wrote:
> The LZ4 code is listed as using the "BSD 2-Clause License".
> 
> Signed-off-by: Richard Laager 
> ---
>  lib/lz4/lz4_compress.c   |4 ++--
>  lib/lz4/lz4_decompress.c |6 +++---
>  lib/lz4/lz4hc_compress.c |4 ++--
>  3 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/lib/lz4/lz4_compress.c b/lib/lz4/lz4_compress.c
> index fd94058..28321d8 100644
> --- a/lib/lz4/lz4_compress.c
> +++ b/lib/lz4/lz4_compress.c
> @@ -437,7 +437,7 @@ int lz4_compress(const unsigned char *src, size_t src_len,
>  exit:
>   return ret;
>  }
> -EXPORT_SYMBOL_GPL(lz4_compress);
> +EXPORT_SYMBOL(lz4_compress);
>  
> -MODULE_LICENSE("GPL");
> +MODULE_LICENSE("Dual BSD/GPL");
>  MODULE_DESCRIPTION("LZ4 compressor");
> diff --git a/lib/lz4/lz4_decompress.c b/lib/lz4/lz4_decompress.c
> index d3414ea..411be80 100644
> --- a/lib/lz4/lz4_decompress.c
> +++ b/lib/lz4/lz4_decompress.c
> @@ -299,7 +299,7 @@ exit_0:
>   return ret;
>  }
>  #ifndef STATIC
> -EXPORT_SYMBOL_GPL(lz4_decompress);
> +EXPORT_SYMBOL(lz4_decompress);
>  #endif
>  
>  int lz4_decompress_unknownoutputsize(const char *src, size_t src_len,
> @@ -319,8 +319,8 @@ exit_0:
>   return ret;
>  }
>  #ifndef STATIC
> -EXPORT_SYMBOL_GPL(lz4_decompress_unknownoutputsize);
> +EXPORT_SYMBOL(lz4_decompress_unknownoutputsize);
>  
> -MODULE_LICENSE("GPL");
> +MODULE_LICENSE("Dual BSD/GPL");
>  MODULE_DESCRIPTION("LZ4 Decompressor");
>  #endif
> diff --git a/lib/lz4/lz4hc_compress.c b/lib/lz4/lz4hc_compress.c
> index eb1a74f..f344f76 100644
> --- a/lib/lz4/lz4hc_compress.c
> +++ b/lib/lz4/lz4hc_compress.c
> @@ -533,7 +533,7 @@ int lz4hc_compress(const unsigned char *src, size_t 
> src_len,
>  exit:
>   return ret;
>  }
> -EXPORT_SYMBOL_GPL(lz4hc_compress);
> +EXPORT_SYMBOL(lz4hc_compress);
>  
> -MODULE_LICENSE("GPL");
> +MODULE_LICENSE("Dual BSD/GPL");
>  MODULE_DESCRIPTION("LZ4HC compressor");

Acked-by: Kyungsik Lee 

Thanks,
Kyungsik
--
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 v1 4/5] ARM: mvebu: add Armada 1500 and Sony NSZ-GS7 device tree files

[Jason Cooper]

On Fri, Aug 16, 2013 at 09:41:37PM +0200, Sebastian Hesselbarth wrote:
> This adds very basic device tree files for the Marvell Armada 1500 SoC
> and the Sony NSZ-GS7 GoogleTV board. Currently, SoC only has nodes for
> cpus, some clocks, l2 cache controller, local timer, apb timers, uart,
> and interrupt controllers.
> 
> The clocks are fixed-clock placeholders until a real DT clock provider
> is available. Cache controller node may be wrong and was just guessed
> out of Armada 370 and GPL'd 1500 source. Timers except clocksource have
> not really been tested.
> 
> The separation into soc/apb and soc/sm-apb may be removed, but it looks
> like Armada 1500 has a separate peripheral bus for the System Manager
> core that can also been accessed by CPUs. (If you look closely on GTV
> boot logs, you can see SM and CPU fighting for UART ;) )
> 
> The Sony NSZ-GS7 is a GoogleTV consumer device comprising the SoC above.
> Since last week or so, there is a way to install a custom u-boot and
> boot stock, unsigned kernels easily. Just ask Google about it, if you
> are willing to void your warranty.
> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> Cc: Rob Herring 
> Cc: Pawel Moll 
> Cc: Mark Rutland 
> Cc: Stephen Warren 
> Cc: Ian Campbell 
> Cc: Russell King 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Gregory Clement 
> Cc: Thomas Petazzoni 
> Cc: Arnd Bergmann 
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/arm/boot/dts/Makefile |3 +-
>  arch/arm/boot/dts/armada-1500-sony-nsz-gs7.dts |   29 +++
>  arch/arm/boot/dts/armada-1500.dtsi |  225 
> 
>  3 files changed, 256 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/boot/dts/armada-1500-sony-nsz-gs7.dts
>  create mode 100644 arch/arm/boot/dts/armada-1500.dtsi

Also, binding docs?

thx,

Jason.
--
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 v1 3/5] ARM: mvebu: add Armada 150 uart to lowlevel debug

[Jason Cooper]

On Fri, Aug 16, 2013 at 09:41:36PM +0200, Sebastian Hesselbarth wrote:
> This adds UART0 as found on the Armada 1500 to the lowlevel debug of
> mach-mvebu. Unfortunately, default register base addresses for Armada
> 370/XP switched from 0xd00 to 0xf10. So, we finally end up
> in three different lowlevel setups:
> 
>  (a) Armada 1500 (possibly also Armada 1000, or MV88DE3xxx in general)
>  (b) Armada 370/XP with new bootloader mapping at 0xf100 and
>  the other Orion SoCs (Dove, Kirkwood, Orion5x, MV78xx0)
>  (c) Armada 370/XP with old bootloader mapping at 0xd000
> 
> Now, mach-mvebu has been a Armada 370/XP-only playground for a while
> but with great work of Thomas, Gregory, and the others we have moved
> almost all drivers to DT. I suggest to clean-up a little and find
> some meaningful names for the DEBUG_ Kconfigs.
> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> Cc: Russell King 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Gregory Clement 
> Cc: Thomas Petazzoni 
> Cc: Arnd Bergmann 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/arm/include/debug/mvebu.S |   26 --
>  1 file changed, 16 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/include/debug/mvebu.S b/arch/arm/include/debug/mvebu.S
> index 6517311..ca41c02 100644
> --- a/arch/arm/include/debug/mvebu.S
> +++ b/arch/arm/include/debug/mvebu.S
> @@ -11,19 +11,25 @@
>   * published by the Free Software Foundation.
>  */
>  
> -#ifdef CONFIG_DEBUG_MVEBU_UART_ALTERNATE
> -#define ARMADA_370_XP_REGS_PHYS_BASE 0xf100
> -#else
> -#define ARMADA_370_XP_REGS_PHYS_BASE 0xd000
> +#if defined(CONFIG_MACH_ARMADA_1500)
> +#define MVEBU_REGS_PHYS_BASE 0xf7f8
> +#define MVEBU_REGS_VIRT_BASE 0xf7f8
> +#define MVEBU_UART0_OFFSET   0x00049000


> +#elif defined(CONFIG_DEBUG_MVEBU_UART)
> +#define MVEBU_REGS_PHYS_BASE 0xd000
> +#define MVEBU_REGS_VIRT_BASE 0xfec0
> +#define MVEBU_UART0_OFFSET   0x00012000
> +#else /* CONFIG_DEBUG_MVEBU_UART_ALTERNATE */
> +#define MVEBU_REGS_PHYS_BASE 0xf100
> +#define MVEBU_REGS_VIRT_BASE 0xfec0
> +#define MVEBU_UART0_OFFSET   0x00012000
>  #endif

We should preserve the default like so:

+#elif defined(CONFIG_DEBUG_MVEBU_UART_ALTERNATE)
+#define MVEBU_REGS_PHYS_BASE   0xf100
+#define MVEBU_REGS_VIRT_BASE   0xfec0
+#define MVEBU_UART0_OFFSET 0x00012000
+#else /* CONFIG_DEBUG_MVEBU_UART */
+#define MVEBU_REGS_PHYS_BASE   0xd000
+#define MVEBU_REGS_VIRT_BASE   0xfec0
+#define MVEBU_UART0_OFFSET 0x00012000
 #endif

thx,

Jason.
--
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/8] THP: Use real address for NUMA policy

[Peter Zijlstra]

On Fri, Aug 16, 2013 at 01:17:28PM -0500, Alex Thorlton wrote:
> I actually didn't write these patches (made a few tweaks to get them
> running on the latest kernel though).  They were submitted last July by 
> Peter Zijlstra. 

By Kirill, I don't think I've ever touched them.

> The messages from the original submission can be found here:
> https://lkml.org/lkml/2012/7/20/165

As can be seen by this posting you reference ;-)
--
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] memblock, numa: Binary search node id

[Yinghai Lu]

On Fri, Aug 16, 2013 at 12:01 PM, Russ Anderson  wrote:
> On Thu, Aug 15, 2013 at 01:43:48PM -0700, Andrew Morton wrote:
>> On Wed, 14 Aug 2013 22:46:29 -0700 Yinghai Lu  wrote:
>>
>> > Current early_pfn_to_nid() on arch that support memblock go
>> > over memblock.memory one by one, so will take too many try
>> > near the end.
>> >
>> > We can use existing memblock_search to find the node id for
>> > given pfn, that could save some time on bigger system that
>> > have many entries memblock.memory array.
>>
>> Looks nice.  I wonder how much difference it makes.
>
> Here are the timing differences for several machines.
> In each case with the patch less time was spent in __early_pfn_to_nid().
>
>
> 3.11-rc5with patch  difference (%)
> --  --
> UV1: 256 nodes  9TB: 411.66  402.47 -9.19 (2.23%)
> UV2: 255 nodes 16TB:1141.02 1138.12 -2.90 (0.25%)
> UV2:  64 nodes  2TB: 128.15  126.53 -1.62 (1.26%)
> UV2:  32 nodes  2TB: 121.87  121.07 -0.80 (0.66%)
> Time in seconds.
>

Thanks.

9T one have more entries in memblock.memory?

Yinghai
--
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: UEFI Plugfest 2013 -- New Orleans

[James Bottomley]

On Fri, 2013-08-16 at 11:20 -0400, John W. Linville wrote:
> Participants in this event must join the UEFI at the Adopter level or
> above (gratis):
> 
>   http://www.uefi.org/join

Just a note on doing this.  I did it today using the three page form on
the uefi web page: you can fill it in on your computer using gimp and
then just email the completed form to ad...@uefi.org.  They had mine
turned around in a few hours (but I wouldn't rely on that for a last
minute registration).

James


--
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/3] ixgbe: request_firmware for configuration parameters

[Greg KH]

On Fri, Aug 16, 2013 at 03:14:31PM -0700, Ali Ayoub wrote:
> On 1/11/2013 11:41 AM, Greg KH wrote:

Seriously?  Restarting a thread from over 6 months ago?  Why?

> > On Fri, Jan 11, 2013 at 11:30:54AM -0800, Shannon Nelson wrote:
> >> On Fri, Jan 11, 2013 at 10:25 AM, Greg KH  
> >> wrote:
> >>> On Thu, Jan 10, 2013 at 06:02:20PM -0800, Shannon Nelson wrote:
>  Most networking dials and knobs can be set using ethtool, ifconfig, ip 
>  link
>  commands, or sysfs entries, all of which can be driven by startup scripts
>  and other configuration tools.  However, they all depend on having a 
>  netdev
>  already set up, and we have some low-level device functionality that 
>  needs
>  to be sorted out before we start setting up MSI-x and memory allocations.
> >>
> >>> Ick, please don't abuse request_firmware() for this type of thing.
> >>
> >> Yeah, it seemed ugly to me at first as well, but it grew on me as I
> >> realized that it does solve a problem in a rather elegant way.  While
> >> working this up I discussed this with Mr. Woodhouse thinking that as a
> >> firmware tree maintainer he'd have a similar reaction, but he actually
> >> wasn't opposed to it (David, please speak up if I'm misrepresenting
> >> your comments).
> > 
> > David maintains the external firmware tree repo, not the in-kernel
> > firmware core code (which I used to maintain.)
> > 
> >>> What's wrong with configfs?  It sounds like it will fit your need, and
> >>> that is what is created for.
> >>
> >> configfs has similar problems as sysfs - the driver needs to create
> >> the hooks before it has all the info it might need for some hooks,
> >> there is no persistence across reboots, and I don't think it will help
> >> for initrd images.  Additionally, there would need to be some userland
> >> mechanism to notice that the hooks were there and to feed it the
> >> startup info.  Using a file in the firmware path gives us persistence
> >> and a way for the driver to get info before having to set up
> >> filesystem hooks.  It also gives us a way to get special config info
> >> into the boot image.  And the whole mechanism already exists,
> >> including UDEV hooks that can do more fancy stuff if needed.
> > 
> > Yes, but you are now starting to use "configuration files" for kernel
> > drivers, which we have resisted for 20+ years for a variety of good
> > reasons. You can't just ignore all of the arguments to not do this all
> > of a sudden because you feel your driver is somehow "special" here.
> 
> Other device drivers of other vendors (not only netdevs) need such a
> mechanism as well,

Specifics please.

> I think it's a general requirement for many drivers that normally need
> low level configurations for device initialization in the very first
> stage of the driver load.

I do not, but feel free to prove me otherwise.

> > All of the above issues you seem to have with sysfs and configfs can be
> > resolved with userspace code, and having your driver not do anything to
> > the hardware until it is told to by userspace.
> 
> To tell the driver not to do anything until it's configured by a
> userspace code will require a module param for non-default-configs
> (which brings us back to the original argument of avoiding module params).

No, never use a module paramater for configuring a driver or a device.
That's not what they are there for.

> By having userspace code to feed configfs/sysfs nodes, and making it
> available in initrd; we will end up having similar mechanism to
> request_firmware().

Close, but not the same.  That's why we created configfs, please use it.

> I think this kind of "low level init configuration" can be seen as a
> firmware configuration, we can put some limitation on fetching the
> config file, or propose a new function such as request_firmware_config()
> that uses the same uevent hooks, and leverages the available userspace
> tools that already supported in initrd and meant to serve the same
> purpose - of feeding the driver the suitable firmware and configuration
> to get started.

Nope, I do not, please don't abuse the interface like this, it's not
going to be allowed at this point in time.

Wait, what "point in time", this was a 6 month old conversation...

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

Re: [RFC 2/4] driver core: Allow early registration of devices

[Greg Kroah-Hartman]

On Fri, Aug 16, 2013 at 11:20:55PM +0100, Grant Likely wrote:
> Also, for the devices that are created early, is it really appropriate
> to use APIs that require a struct device? I could easily argue that
> anything done at early boot should only be the bare minimum to allow
> the kernel to get to initcalls, and so mucking about with devices is
> inappropriate because it really messes with the assumptions made in
> the design of the driver model.

I agree, this could get really messy, really fast, and be a place that
people abuse quite easily.

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

Re: [RFC 2/4] driver core: Allow early registration of devices

[Greg Kroah-Hartman]

On Fri, Aug 16, 2013 at 11:55:31PM +0200, Thierry Reding wrote:
> > > + list_for_each_entry(private, _early_list, early) {
> > > + struct device *dev = private->device;
> > > + int err;
> > > +
> > > + if (dev->bus == _bus_type) {
> > 
> > Why special case the platform bus?  We are trying to move things off of
> > the platform bus, don't make it harder to do that :)
> 
> I heard about that, but I must have missed the thread where this was
> discussed. Can you point me to it?

I thought it was on lkml, but it might have been limited to linux-arm
and the ksummit-discuss mailing list on one of the threads there.
Sorry, I can't recall it at the moment.

> > > + struct platform_device *pdev = to_platform_device(dev);
> > > +
> > > + err = platform_device_early_fixup(pdev);
> > > + if (err < 0)
> > > + dev_err(>dev,
> > > + "failed to fixup device %s: %d\n",
> > > + dev_name(>dev), err);
> > > + }
> > 
> > You should just have a bus callback that can be made here that, if
> > present, can be called.  That way any bus can handle this type of thing,
> > not just the platform one.
> 
> You mean something like an .early_fixup() in struct bus_type?

Yes.

> That would indeed be much cleaner. As I mentioned this is a very early
> prototype and this particular hunk exists specifically to fixup the
> platform devices created by the device tree helpers so that the kernel
> actually boots to the login prompt.

That's fine, I was giving you feedback on why I wouldn't take this as-is :)

> > Not that I really like the whole idea anyway, but I doubt there's much I
> > can do about it...
> 
> Well, getting feedback from you and others is precisely the reason why I
> wanted to post this early. There must be a reason why you don't like it,
> so perhaps you can share your thoughts and we can mould this into
> something that you'd be more comfortable with.

Ideally we would have the rest of the system up and running (i.e. sysfs)
before having to deal with devices and drivers.  As it is, you are
"special casing" a number of special devices on special platforms to
work around architectural issues on those platforms.  Stuff that ideally
would never need to be done, except for crazy hardware designers :)

So I understand that it is needed, in some special cases, but that
doesn't mean I have to like it...

> To be honest I don't particularly like it either. It's very hackish for
> core code. But on the other hand there are a few device/driver ordering
> problems that this (or something similar) would help solve. I'm
> certainly open to discuss alternatives and perhaps there's a much
> cleaner way to solve the problem.

As this usually is needed on a case-by-case basis, I'm hoping that your
case really does need this, right?  If so, there's not much the kernel
can do except add hooks like this to make it work properly.

thanks,

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

[PATCH 001/133] Input: elantech - fix for newer hardware versions (v7)

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Matteo Delfino 

commit 9eebed7de660c0b5ab129a9de4f89d20b60de68c upstream.

* Fix version recognition in elantech_set_properties

  The new hardware reports itself as v7 but the packets'
  structure is unaltered.

* Fix packet type recognition in elantech_packet_check_v4

  The bitmask used for v6 is too wide, only the last three bits of
  the third byte in a packet (packet[3] & 0x03) are actually used to
  distinguish between packet types.
  Starting from v7, additional information (to be interpreted) is
  stored in the remaining bits (packets[3] & 0x1c).
  In addition, the value stored in (packet[0] & 0x0c) is no longer
  a constant but contains additional information yet to be deciphered.
  This change should be backwards compatible with v6 hardware.

Additional-author: Giovanni Frigione 
Signed-off-by: Matteo Delfino 
Signed-off-by: Dmitry Torokhov 
Cc: Joseph Salisbury 
Signed-off-by: Kamal Mostafa 
---
 drivers/input/mouse/elantech.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index 1e8e42f..57b2637 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -694,18 +694,18 @@ static int elantech_packet_check_v3(struct psmouse 
*psmouse)
 static int elantech_packet_check_v4(struct psmouse *psmouse)
 {
unsigned char *packet = psmouse->packet;
+   unsigned char packet_type = packet[3] & 0x03;
 
-   if ((packet[0] & 0x0c) == 0x04 &&
-   (packet[3] & 0x1f) == 0x11)
+   switch (packet_type) {
+   case 0:
+   return PACKET_V4_STATUS;
+
+   case 1:
return PACKET_V4_HEAD;
 
-   if ((packet[0] & 0x0c) == 0x04 &&
-   (packet[3] & 0x1f) == 0x12)
+   case 2:
return PACKET_V4_MOTION;
-
-   if ((packet[0] & 0x0c) == 0x04 &&
-   (packet[3] & 0x1f) == 0x10)
-   return PACKET_V4_STATUS;
+   }
 
return PACKET_UNKNOWN;
 }
@@ -1282,6 +1282,7 @@ static int elantech_set_properties(struct elantech_data 
*etd)
etd->hw_version = 3;
break;
case 6:
+   case 7:
etd->hw_version = 4;
break;
default:
-- 
1.8.1.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 020/133] [SCSI] isci: Fix a race condition in the SSP task management path

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Jeff Skirvin 

commit 96f15f29038e58e1b0a96483e2b369ff446becf1 upstream.

This commit fixes a race condition in the isci driver abort task and SSP
device task management path.  The race is caused when an I/O termination
in the SCU hardware is necessary because of an SSP target timeout condition,
and the check of the I/O end state races against the HW-termination-driven
end state.  The failure of the race meant that no TMF was sent to the device
to clean-up the pending I/O.

Signed-off-by: Jeff Skirvin 
Reviewed-by: Lukasz Dorau 
Signed-off-by: James Bottomley 
Signed-off-by: Kamal Mostafa 
---
 drivers/scsi/isci/task.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/isci/task.c b/drivers/scsi/isci/task.c
index b6f19a1..572ab51 100644
--- a/drivers/scsi/isci/task.c
+++ b/drivers/scsi/isci/task.c
@@ -491,6 +491,7 @@ int isci_task_abort_task(struct sas_task *task)
struct isci_tmf   tmf;
int   ret = TMF_RESP_FUNC_FAILED;
unsigned long flags;
+   int   target_done_already = 0;
 
/* Get the isci_request reference from the task.  Note that
 * this check does not depend on the pending request list
@@ -505,9 +506,11 @@ int isci_task_abort_task(struct sas_task *task)
/* If task is already done, the request isn't valid */
if (!(task->task_state_flags & SAS_TASK_STATE_DONE) &&
(task->task_state_flags & SAS_TASK_AT_INITIATOR) &&
-   old_request)
+   old_request) {
idev = isci_get_device(task->dev->lldd_dev);
-
+   target_done_already = test_bit(IREQ_COMPLETE_IN_TARGET,
+  _request->flags);
+   }
spin_unlock(>task_state_lock);
spin_unlock_irqrestore(>scic_lock, flags);
 
@@ -561,7 +564,7 @@ int isci_task_abort_task(struct sas_task *task)
 
if (task->task_proto == SAS_PROTOCOL_SMP ||
sas_protocol_ata(task->task_proto) ||
-   test_bit(IREQ_COMPLETE_IN_TARGET, _request->flags) ||
+   target_done_already ||
test_bit(IDEV_GONE, >flags)) {
 
spin_unlock_irqrestore(>scic_lock, flags);
-- 
1.8.1.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 004/133] ASoC: max98088 - fix element type of the register cache.

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Chih-Chung Chang 

commit cb6f66a2d278e57a6c9d8fb59bd9ebd8ab3965c2 upstream.

The registers of max98088 are 8 bits, not 16 bits. This bug causes the
contents of registers to be overwritten with bad values when the codec
is suspended and then resumed.

Signed-off-by: Chih-Chung Chang 
Signed-off-by: Dylan Reid 
Signed-off-by: Mark Brown 
Signed-off-by: Kamal Mostafa 
---
 sound/soc/codecs/max98088.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/max98088.c b/sound/soc/codecs/max98088.c
index 5d36319..6c9e662 100644
--- a/sound/soc/codecs/max98088.c
+++ b/sound/soc/codecs/max98088.c
@@ -1594,7 +1594,7 @@ static int max98088_dai2_digital_mute(struct snd_soc_dai 
*codec_dai, int mute)
 
 static void max98088_sync_cache(struct snd_soc_codec *codec)
 {
-   u16 *reg_cache = codec->reg_cache;
+   u8 *reg_cache = codec->reg_cache;
int i;
 
if (!codec->cache_sync)
-- 
1.8.1.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 018/133] drm/radeon: fix combios tables on older cards

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Mark Kettenis 

commit cef1d00cd56f600121ad121875655ad410a001b8 upstream.

Noticed that my old Radeon 7500 hung after printing

   drm: GPU not posted. posting now...

when it wasn't selected as the primary card the BIOS.  Some digging
revealed that it was hanging in combios_parse_mmio_table() while
parsing the ASIC INIT 3 table.  Looking at the BIOS ROM for the card,
it becomes obvious that there is no ASIC INIT 3 table in the BIOS.
The code is just processing random garbage.  No surprise it hangs!

Why do I say that there is no ASIC INIT 3 table is the BIOS?  This
table is found through the MISC INFO table.  The MISC INFO table can
be found at offset 0x5e in the COMBIOS header.  But the header is
smaller than that.  The COMBIOS header starts at offset 0x126.  The
standard PCI Data Structure (the bit that starts with 'PCIR') lives at
offset 0x180.  That means that the COMBIOS header can not be larger
than 0x5a bytes and therefore cannot contain a MISC INFO table.

I looked at a dozen or so BIOS images, some my own, some downloaded from:



It is fairly obvious that the size of the COMBIOS header can be found
at offset 0x6 of the header.  Not sure if it is a 16-bit number or
just an 8-bit number, but that doesn't really matter since the tables
seems to be always smaller than 256 bytes.

So I think combios_get_table_offset() should check if the requested
table is present.  This can be done by checking the offset against the
size of the header.  See the diff below.  The diff is against the WIP
OpenBSD codebase that roughly corresponds to Linux 3.8.13 at this
point.  But I don't think this bit of the code changed much since
then.

For what it is worth:

Signed-off-by: Mark Kettenis 
Signed-off-by: Alex Deucher 
Signed-off-by: Kamal Mostafa 
---
 drivers/gpu/drm/radeon/radeon_combios.c | 145 +---
 1 file changed, 41 insertions(+), 104 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
b/drivers/gpu/drm/radeon/radeon_combios.c
index 485f82c..68ce360 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -147,7 +147,7 @@ static uint16_t combios_get_table_offset(struct drm_device 
*dev,
 enum radeon_combios_table_offset table)
 {
struct radeon_device *rdev = dev->dev_private;
-   int rev;
+   int rev, size;
uint16_t offset = 0, check_offset;
 
if (!rdev->bios)
@@ -156,174 +156,106 @@ static uint16_t combios_get_table_offset(struct 
drm_device *dev,
switch (table) {
/* absolute offset tables */
case COMBIOS_ASIC_INIT_1_TABLE:
-   check_offset = RBIOS16(rdev->bios_header_start + 0xc);
-   if (check_offset)
-   offset = check_offset;
+   check_offset = 0xc;
break;
case COMBIOS_BIOS_SUPPORT_TABLE:
-   check_offset = RBIOS16(rdev->bios_header_start + 0x14);
-   if (check_offset)
-   offset = check_offset;
+   check_offset = 0x14;
break;
case COMBIOS_DAC_PROGRAMMING_TABLE:
-   check_offset = RBIOS16(rdev->bios_header_start + 0x2a);
-   if (check_offset)
-   offset = check_offset;
+   check_offset = 0x2a;
break;
case COMBIOS_MAX_COLOR_DEPTH_TABLE:
-   check_offset = RBIOS16(rdev->bios_header_start + 0x2c);
-   if (check_offset)
-   offset = check_offset;
+   check_offset = 0x2c;
break;
case COMBIOS_CRTC_INFO_TABLE:
-   check_offset = RBIOS16(rdev->bios_header_start + 0x2e);
-   if (check_offset)
-   offset = check_offset;
+   check_offset = 0x2e;
break;
case COMBIOS_PLL_INFO_TABLE:
-   check_offset = RBIOS16(rdev->bios_header_start + 0x30);
-   if (check_offset)
-   offset = check_offset;
+   check_offset = 0x30;
break;
case COMBIOS_TV_INFO_TABLE:
-   check_offset = RBIOS16(rdev->bios_header_start + 0x32);
-   if (check_offset)
-   offset = check_offset;
+   check_offset = 0x32;
break;
case COMBIOS_DFP_INFO_TABLE:
-   check_offset = RBIOS16(rdev->bios_header_start + 0x34);
-   if (check_offset)
-   offset = check_offset;
+   check_offset = 0x34;
break;
case COMBIOS_HW_CONFIG_INFO_TABLE:
-   check_offset = RBIOS16(rdev->bios_header_start + 0x36);
-   if (check_offset)
-   offset = 

Hello dear

[blessingzamba...@adinet.com.uy]

Hello dear
How are you today I hope all is well with you, my name is 
miss blessing zamba 24 years old girl is my pleasure to contact you after
 viewing your profile  which really interest me to communicating with 
you please if you have the desire with me so we can get to know each 
other better and see what happens in the future?. I'll be very glad if 
you could send me mail back to my personal e-mail for more easy 
communication and to know more about each other.i will tell you why i 
make this contact with you in my next email and i will send you my 
picture when I receive your response, i am waiting to hear from you, and
 I wish you all the best on your life. thank you and have a nice day
miss blessing
--
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 005/133] ata: Fix DVD not dectected at some platform with Wellsburg PCH

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Youquan Song 

commit eac27f04a71e1f39f196f7e520d16dcefc955d77 upstream.

There is a patch b55f84e2d527182e7c611d466cd0bb6ddce201de "ata_piix: Fix DVD
 not dectected at some Haswell platforms" to fix an issue of DVD not
recognized on Haswell Desktop platform with Lynx Point.
Recently, it is also found the same issue at some platformas with Wellsburg PCH.

So deliver a similar patch to fix it by disables 32bit PIO in IDE mode.

Signed-off-by: Youquan Song 
Signed-off-by: Tejun Heo 
Signed-off-by: Kamal Mostafa 
---
 drivers/ata/ata_piix.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index c70942f..2ae9efc 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -330,7 +330,7 @@ static const struct pci_device_id piix_pci_tbl[] = {
/* SATA Controller IDE (Wellsburg) */
{ 0x8086, 0x8d00, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_snb },
/* SATA Controller IDE (Wellsburg) */
-   { 0x8086, 0x8d08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
+   { 0x8086, 0x8d08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata_snb },
/* SATA Controller IDE (Wellsburg) */
{ 0x8086, 0x8d60, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_snb },
/* SATA Controller IDE (Wellsburg) */
-- 
1.8.1.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: [ 00/17] 3.4.58-stable review

[Guenter Roeck]

On Fri, Aug 16, 2013 at 05:41:40AM -0700, Greg Kroah-Hartman wrote:
> On Fri, Aug 16, 2013 at 01:26:05AM -0700, Guenter Roeck wrote:
> > On 08/15/2013 10:10 PM, Greg Kroah-Hartman wrote:
> > [ .. ]
> > 
> > >> three to go (arm:allmodconfig, sparc32:defconfig, and 
> > >> sparc64:allmodconfig).
> > >
> > 
> > Please add (in this order) the following patches to 3.4.
> > 
> > de36e66d5f sparc32: add ucmpdi2
> > 74c7b28953 sparc32: Add ucmpdi2.o to obj-y instead of lib-y.
> > 
> > This fixes the sparc32:defconfig build error.
> 
> Now applied, thanks.
> 
Down to three failures now, out of 69 builds.

Still failing:
arm:allmodconfig
sparc64:allmodconfig
xtensa:defconfig

None of those appear simple to fix.

In case someone wants to have a look, here is the latest log:

http://server.roeck-us.net:8010/builders/stable-queue-3.4/builds/45/steps/shell/logs/stdio

Guenter
--
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 kernel cross-compilers

[Guenter Roeck]

On Fri, Aug 16, 2013 at 09:26:51PM +0200, Sam Ravnborg wrote:
> On Fri, Aug 16, 2013 at 08:43:35AM -0700, Guenter Roeck wrote:
> > On 08/16/2013 02:45 AM, Max Filippov wrote:
>  Guenter,
>  can you share a complete build log with V=1?
> 
> >>>
> >>> http://roeck-us.net/linux/logs/make.xtensa.log.bad
> >>> http://roeck-us.net/linux/logs/make.xtensa.log.ok
> >>>
> >>> Key difference: the failing command in the bad case is
> >>>  xtensa-linux-objcopy -O elf32-xtensa-le
> >>> and in the good case
> >>>  xtensa-linux-objcopy -O elf32-xtensa-be
> >>>
> >>> Same compiler (4.6.3 from kernel.org), same configuration file, same 
> >>> command
> >>> line.
> >>> Configuration file is generated from defconfig, and the resulting .config
> >>> file
> >>> is the same in both cases.
> >>>
> >>> If I execute make and expicitly set BIG_ENDIAN=1 on the failing system as
> >>> parameter to it,
> >>> it works fine. If I set BIG_ENDIAN=0 on the passing system, it fails.
> >>>
> >>> I am puzzled. Guess there must be something different, but I have no idea
> >>> what it might be.
> >>
> >> What is the output of
> >>
> >> echo -e __XTENSA_EB__ | xtensa-linux-gcc -E -
> >>
> >> on the failing system?
> >>
> > It is "1", but that let me pinpoint the problem.
> >
> > On the failing system, the version of echo executed by make does
> > not understand the "-e" option. Thus, when running 
> > arch/xtensa/boot/Makefile,
> > "echo -e __XTENSA_EB__" returns "-e __XTENSA_EB__", which doesn't compile,
> > and BIG_ENDIAN ends up being 0. So the compiler is completely innocent.
> >
> > I found out the root source: SHELL is set the /bin/sh, which on the failing
> > system points to /bin/dash (default in Ubuntu, or at least it used to be).
> > dash apparently has a built-in version of echo which does not understand 
> > '-e'.
> 
> Could you try to replace "echo -e bla" with "printf "bla".
> Kbuild.include uses some similar tricks but here printf is used.
> Maybe this can be dash compatible then
> 
"echo" would do perfectly fine in this case. Besides, there are more
"echo -e" in arch/xtensa/Makefile. Those only cause unpredictable build
results (because neither big endian not little endian is set because of it),
but no errors.

Problem is that "echo -e" is used elsewhere in various kernel makefiles,
not just for xtensa. Those don't cause odd errors like the one I observed,
but may result in unpredictable behavior. I am not sure if I should try
to fix that.

Maybe we should just put "don't try to compile the linux kernel with dash
as default shell" as a note somewhere.

Guenter
--
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 010/133] USB: misc: Add Manhattan Hi-Speed USB DVI Converter to sisusbvga

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: =?UTF-8?q?J=C3=B3hann=20B=2E=20Gu=C3=B0mundsson?= 

commit 58fc90db8261b571c026bb8bf23aad48a7233118 upstream.

Signed-off-by: Jóhann B. Guðmundsson 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/misc/sisusbvga/sisusb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/misc/sisusbvga/sisusb.c 
b/drivers/usb/misc/sisusbvga/sisusb.c
index dd573ab..7af163d 100644
--- a/drivers/usb/misc/sisusbvga/sisusb.c
+++ b/drivers/usb/misc/sisusbvga/sisusb.c
@@ -3247,6 +3247,7 @@ static const struct usb_device_id sisusb_table[] = {
{ USB_DEVICE(0x0711, 0x0903) },
{ USB_DEVICE(0x0711, 0x0918) },
{ USB_DEVICE(0x0711, 0x0920) },
+   { USB_DEVICE(0x0711, 0x0950) },
{ USB_DEVICE(0x182d, 0x021c) },
{ USB_DEVICE(0x182d, 0x0269) },
{ }
-- 
1.8.1.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 012/133] usb: cp210x support SEL C662 Vendor/Device

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Barry Grussling 

commit b579fa52f6be0b4157ca9cc5e94d44a2c89a7e95 upstream.

This patch adds support for the Schweitzer Engineering Laboratories
C662 USB cable based off the CP210x driver.

Signed-off-by: Barry Grussling 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/serial/cp210x.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index 8585c6e..d0e9f5d 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -149,6 +149,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x17F4, 0x) }, /* Wavesense Jazz blood glucose meter */
{ USB_DEVICE(0x1843, 0x0200) }, /* Vaisala USB Instrument Cable */
{ USB_DEVICE(0x18EF, 0xE00F) }, /* ELV USB-I2C-Interface */
+   { USB_DEVICE(0x1ADB, 0x0001) }, /* Schweitzer Engineering C662 Cable */
{ USB_DEVICE(0x1BE3, 0x07A6) }, /* WAGO 750-923 USB Service Cable */
{ USB_DEVICE(0x1E29, 0x0102) }, /* Festo CPX-USB */
{ USB_DEVICE(0x1E29, 0x0501) }, /* Festo CMSP */
-- 
1.8.1.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: [PATCH v3] hwspinlock/msm: Add support for Qualcomm MSM HW Mutex block

[Stephen Warren]

On 08/15/2013 07:35 AM, Pawel Moll wrote:
> On Wed, 2013-08-14 at 20:09 +0100, Kumar Gala wrote:
>> +Required properties:
>> +- compatible: should be "qcom,tcsr-mutex"
>> +- reg: Should contain registers location and length of mutex registers
>> +- reg-names:
>> +"mutex-base"  - string to identify mutex registers
> 
> Just out of curiosity, why is reg-names required? Especially if there
> seem to be only one set of registers?

Indeed, I tend to think that reg-names is a bad idea.

IIRC, the rule for "reg" is that entries must always have a defined
order, so that it can always be accessed by integer index. And given
that's true, allowing for reg-names just creates confusion since it
implies you can look up the index in reg-names and then read reg at that
index.

Now the same isn't true for clocks/clock-names for example, where it's
defined that there is no order, so you must search clock-names first.

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

Re: [PATCH RFC 3/3] spmi: document the PMIC arbiter SPMI bindings

[Stephen Warren]

On 08/16/2013 01:48 PM, Kumar Gala wrote:
> 
> On Aug 16, 2013, at 2:25 PM, Josh Cartwright wrote:
> 
>> Hey Kumar-
>>
>> Thanks for the review.
>>
>> On Fri, Aug 16, 2013 at 01:53:27PM -0500, Kumar Gala wrote:
>>> On Aug 9, 2013, at 3:37 PM, Josh Cartwright wrote:
>>>
 Signed-off-by: Josh Cartwright 
 ---
 .../devicetree/bindings/spmi/spmi-pmic-arb.txt | 26 
 ++
 1 file changed, 26 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/spmi/spmi-pmic-arb.txt
>>>
>>> As this is a qcom specific binding, I think the file name should be 
>>> msm-spmi-pmic-arb.txt or something like that.
>>
>> Agreed.  It might be nice to use a vendor prefix in the name too.  How's 
>> qcom,msm-pmic-arb.txt sound?
> 
> Sounds good, as I see we have other examples of having a comma in file names 
> for bindings.

The rule I've applied for bindings I created is use the complete
compatible value for the file name. Where multiple are supported (e.g.
SoC versions), just use the first one. Then, the filename is pretty
unambiguous, both from a point of view of `ls` and from choosing a name.
--
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 014/133] USB: EHCI: Fix resume signalling on remote wakeup

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Roger Quadros 

commit 47a64a13d54f6c669b00542848d5550be3d3310e upstream.

Set the ehci->resuming flag for the port we receive a remote
wakeup on so that resume signalling can be completed.

Without this, the root hub timer will not fire again to check
if the resume was completed and there will be a never-ending wait on
on the port.

This effect is only observed if the HUB IRQ IN does not come after we
have initiated the port resume.

Signed-off-by: Roger Quadros 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/host/ehci-hub.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index 7d06e77..f578493 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -856,6 +856,7 @@ static int ehci_hub_control (
ehci->reset_done[wIndex] = jiffies
+ msecs_to_jiffies(20);
usb_hcd_start_port_resume(>self, wIndex);
+   set_bit(wIndex, >resuming_ports);
/* check the port again */
mod_timer(_to_hcd(ehci)->rh_timer,
ehci->reset_done[wIndex]);
-- 
1.8.1.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 016/133] drm/radeon: Another card with wrong primary dac adj

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Ondrej Zary 

commit f7929f34fa0e0bb6736a2484fdc07d77a1653081 upstream.

Hello,
got another card with "too bright" problem:
Sapphire Radeon VE 7000 DDR (VGA+S-Video)

lspci -vnn:
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI 
RV100 QY [Radeon 7000/VE] [1002:5159] (prog-if 00 [VGA controller])
Subsystem: PC Partner Limited Sapphire Radeon VE 7000 DDR [174b:7c28]

The patch below fixes the problem for this card.
But I don't like the blacklist, couldn't some heuristic be used instead?
The interesting thing is that the manufacturer is the same as the other card
needing the same quirk. I wonder how many different types are broken this way.

The "wrong" ps2_pdac_adj value that comes from BIOS on this card is 0x300.


drm/radeon: Add primary dac adj quirk for Sapphire Radeon VE 7000 DDR

Values from BIOS are wrong, causing too bright colors.
Use default values instead.

Signed-off-by: Ondrej Zary 
Signed-off-by: Alex Deucher 
Signed-off-by: Kamal Mostafa 
---
 drivers/gpu/drm/radeon/radeon_combios.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
b/drivers/gpu/drm/radeon/radeon_combios.c
index 78edadc..8528b81 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -971,10 +971,14 @@ struct radeon_encoder_primary_dac 
*radeon_combios_get_primary_dac_info(struct
}
 
/* quirks */
+   /* Radeon 7000 (RV100) */
+   if (((dev->pdev->device == 0x5159) &&
+   (dev->pdev->subsystem_vendor == 0x174B) &&
+   (dev->pdev->subsystem_device == 0x7c28)) ||
/* Radeon 9100 (R200) */
-   if ((dev->pdev->device == 0x514D) &&
+  ((dev->pdev->device == 0x514D) &&
(dev->pdev->subsystem_vendor == 0x174B) &&
-   (dev->pdev->subsystem_device == 0x7149)) {
+   (dev->pdev->subsystem_device == 0x7149))) {
/* vbios value is bad, use the default */
found = 0;
}
-- 
1.8.1.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 003/133] usb: dwc3: fix wrong bit mask in dwc3_event_type

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Huang Rui 

commit 1974d494dea05ea227cb42f5e918828801e237aa upstream.

Per dwc3 2.50a spec, the is_devspec bit is used to distinguish the
Device Endpoint-Specific Event or Device-Specific Event (DEVT). If the
bit is 1, the event is represented Device-Specific Event, then use
[7:1] bits as Device Specific Event to marked the type. It has 7 bits,
and we can see the reserved8_31 variable name which means from 8 to 31
bits marked reserved, actually there are 24 bits not 25 bits between
that. And 1 + 7 + 24 = 32, the event size is 4 byes.

So in dwc3_event_type, the bit mask should be:
is_devspec  [0] 1  bit
type[7:1]   7  bits
reserved8_31[31:8]  24 bits

This patch should be backported to kernels as old as 3.2, that contain
the commit 72246da40f3719af3bfd104a2365b32537c27d83 "usb: Introduce
DesignWare USB3 DRD Driver".

Signed-off-by: Huang Rui 
Signed-off-by: Felipe Balbi 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/dwc3/core.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 1dae91d..17dcd98 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -730,8 +730,8 @@ struct dwc3 {
 
 struct dwc3_event_type {
u32 is_devspec:1;
-   u32 type:6;
-   u32 reserved8_31:25;
+   u32 type:7;
+   u32 reserved8_31:24;
 } __packed;
 
 #define DWC3_DEPEVT_XFERCOMPLETE   0x01
-- 
1.8.1.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 019/133] ARM: footbridge: fix overlapping PCI mappings

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Mike Frysinger 

commit 6287e7319870ec949fb809e4eb4154c2b05b221f upstream.

Commit 8ef6e6201b26cb9fde79c1baa08145af6aca2815 (ARM: footbridge: use
fixed PCI i/o mapping) broke booting on my netwinder.  Before that,
everything boots fine.  Since then, it crashes on boot.

With earlyprintk, I see it BUG-ing like so:
kernel BUG at lib/ioremap.c:27!
Internal error: Oops - BUG: 0 [#1] ARM
...
[] (ioremap_page_range+0x128/0x154) from [] 
(dc21285_setup+0xd0/0x114)
[] (dc21285_setup+0xd0/0x114) from [] 
(pci_common_init+0xa0/0x298)
[] (pci_common_init+0xa0/0x298) from [] 
(netwinder_pci_init+0xc/0x18)
[] (netwinder_pci_init+0xc/0x18) from [] 
(do_one_initcall+0xb4/0x180)
...

Russell points out it's because of overlapping PCI mappings that was
added with the aforementioned commit.  Rob thought the code would re-use
the static mapping, but that turns out to not be the case and instead
hits the BUG further down.

After deleting this hunk as suggested by Russel, the system boots up fine
again and all my PCI devices work (IDE, ethernet, the DC21285).

Signed-off-by: Mike Frysinger 
Acked-by: Rob Herring 
Signed-off-by: Olof Johansson 
Signed-off-by: Kamal Mostafa 
---
 arch/arm/mach-footbridge/dc21285.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-footbridge/dc21285.c 
b/arch/arm/mach-footbridge/dc21285.c
index a7cd2cf..3490a24 100644
--- a/arch/arm/mach-footbridge/dc21285.c
+++ b/arch/arm/mach-footbridge/dc21285.c
@@ -276,8 +276,6 @@ int __init dc21285_setup(int nr, struct pci_sys_data *sys)
 
sys->mem_offset  = DC21285_PCI_MEM;
 
-   pci_ioremap_io(0, DC21285_PCI_IO);
-
pci_add_resource_offset(>resources, [0], sys->mem_offset);
pci_add_resource_offset(>resources, [1], sys->mem_offset);
 
-- 
1.8.1.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 006/133] Tools: hv: KVP: Fix a bug in IPV6 subnet enumeration

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: "K. Y. Srinivasan" 

commit ed4bb9744b41d39ba35080c2390e201575121dc7 upstream.

Each subnet string needs to be separated with a semicolon. Fix this bug.

Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Kamal Mostafa 
---
 tools/hv/hv_kvp_daemon.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index d25a469..f0e1810 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -1012,9 +1012,10 @@ kvp_get_ip_info(int family, char *if_name, int op,
 
if (sn_offset == 0)
strcpy(sn_str, cidr_mask);
-   else
+   else {
+   strcat((char *)ip_buffer->sub_net, ";");
strcat(sn_str, cidr_mask);
-   strcat((char *)ip_buffer->sub_net, ";");
+   }
sn_offset += strlen(sn_str) + 1;
}
 
-- 
1.8.1.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 002/133] usb: dwc3: gadget: don't prevent gadget from being probed if we fail

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Felipe Balbi 

commit cdcedd6981194e511cc206887db661d016069d68 upstream.

In case we fail our ->udc_start() callback, we
should be ready to accept another modprobe following
the failed one.

We had forgotten to clear dwc->gadget_driver back
to NULL and, because of that, we were preventing
gadget driver modprobe from being retried.

Signed-off-by: Felipe Balbi 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/dwc3/gadget.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index be13492..1656800 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1535,6 +1535,7 @@ err1:
__dwc3_gadget_ep_disable(dwc->eps[0]);
 
 err0:
+   dwc->gadget_driver = NULL;
spin_unlock_irqrestore(>lock, flags);
 
return ret;
-- 
1.8.1.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 017/133] drm/radeon: improve dac adjust heuristics for legacy pdac

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Alex Deucher 

commit 03ed8cf9b28d886c64c7e705c7bb1a365fd8fb95 upstream.

Hopefully avoid more quirks in the future due to bogus
vbios dac data.

Signed-off-by: Alex Deucher 
Signed-off-by: Kamal Mostafa 
---
 drivers/gpu/drm/radeon/radeon_combios.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
b/drivers/gpu/drm/radeon/radeon_combios.c
index 8528b81..485f82c 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -965,8 +965,10 @@ struct radeon_encoder_primary_dac 
*radeon_combios_get_primary_dac_info(struct
dac = RBIOS8(dac_info + 0x3) & 0xf;
p_dac->ps2_pdac_adj = (bg << 8) | (dac);
}
-   /* if the values are all zeros, use the table */
-   if (p_dac->ps2_pdac_adj)
+   /* if the values are zeros, use the table */
+   if ((dac == 0) || (bg == 0))
+   found = 0;
+   else
found = 1;
}
 
-- 
1.8.1.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 015/133] drm/radeon: fix endian issues with DP handling (v3)

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Alex Deucher 

commit 34be8c9af7b8728465963740fc11136ae90dfc36 upstream.

The atom interpreter expects data in LE format, so
swap the message buffer as apprioriate.

v2: properly handle non-dw aligned byte counts.
v3: properly handle remainder

Signed-off-by: Alex Deucher 
Cc: Dong He 
Signed-off-by: Kamal Mostafa 
---
 drivers/gpu/drm/radeon/atombios_dp.c | 43 
 1 file changed, 39 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index 064023b..32501f6 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -44,6 +44,41 @@ static char *pre_emph_names[] = {
 };
 
 /* radeon AUX functions */
+
+/* Atom needs data in little endian format
+ * so swap as appropriate when copying data to
+ * or from atom. Note that atom operates on
+ * dw units.
+ */
+static void radeon_copy_swap(u8 *dst, u8 *src, u8 num_bytes, bool to_le)
+{
+#ifdef __BIG_ENDIAN
+   u8 src_tmp[20], dst_tmp[20]; /* used for byteswapping */
+   u32 *dst32, *src32;
+   int i;
+
+   memcpy(src_tmp, src, num_bytes);
+   src32 = (u32 *)src_tmp;
+   dst32 = (u32 *)dst_tmp;
+   if (to_le) {
+   for (i = 0; i < ((num_bytes + 3) / 4); i++)
+   dst32[i] = cpu_to_le32(src32[i]);
+   memcpy(dst, dst_tmp, num_bytes);
+   } else {
+   u8 dws = num_bytes & ~3;
+   for (i = 0; i < ((num_bytes + 3) / 4); i++)
+   dst32[i] = le32_to_cpu(src32[i]);
+   memcpy(dst, dst_tmp, dws);
+   if (num_bytes % 4) {
+   for (i = 0; i < (num_bytes % 4); i++)
+   dst[dws+i] = dst_tmp[dws+i];
+   }
+   }
+#else
+   memcpy(dst, src, num_bytes);
+#endif
+}
+
 union aux_channel_transaction {
PROCESS_AUX_CHANNEL_TRANSACTION_PS_ALLOCATION v1;
PROCESS_AUX_CHANNEL_TRANSACTION_PARAMETERS_V2 v2;
@@ -65,10 +100,10 @@ static int radeon_process_aux_ch(struct radeon_i2c_chan 
*chan,
 
base = (unsigned char *)(rdev->mode_info.atom_context->scratch + 1);
 
-   memcpy(base, send, send_bytes);
+   radeon_copy_swap(base, send, send_bytes, true);
 
-   args.v1.lpAuxRequest = 0 + 4;
-   args.v1.lpDataOut = 16 + 4;
+   args.v1.lpAuxRequest = cpu_to_le16((u16)(0 + 4));
+   args.v1.lpDataOut = cpu_to_le16((u16)(16 + 4));
args.v1.ucDataOutLen = 0;
args.v1.ucChannelID = chan->rec.i2c_id;
args.v1.ucDelay = delay / 10;
@@ -102,7 +137,7 @@ static int radeon_process_aux_ch(struct radeon_i2c_chan 
*chan,
recv_bytes = recv_size;
 
if (recv && recv_size)
-   memcpy(recv, base + 16, recv_bytes);
+   radeon_copy_swap(recv, base + 16, recv_bytes, false);
 
return recv_bytes;
 }
-- 
1.8.1.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 009/133] USB: storage: Add MicroVault Flash Drive to unusual_devs

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Ren Bigcren 

commit e7a6121f4929c17215f0cdca3726f4bf3e4e9529 upstream.

The device report an error capacity when read_capacity_16().
Using read_capacity_10() can get the correct capacity.

Signed-off-by: Ren Bigcren 
Cc: Matthew Dharm 
Signed-off-by: Oskar Andero 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/storage/unusual_devs.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/storage/unusual_devs.h 
b/drivers/usb/storage/unusual_devs.h
index b75e90b..f828c76 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -657,6 +657,13 @@ UNUSUAL_DEV(  0x054c, 0x016a, 0x, 0x,
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_FIX_INQUIRY ),
 
+/* Submitted by Ren Bigcren  */
+UNUSUAL_DEV(  0x054c, 0x02a5, 0x0100, 0x0100,
+   "Sony Corp.",
+   "MicroVault Flash Drive",
+   USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+   US_FL_NO_READ_CAPACITY_16 ),
+
 /* floppy reports multiple luns */
 UNUSUAL_DEV(  0x055d, 0x2020, 0x, 0x0210,
"SAMSUNG",
-- 
1.8.1.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 008/133] usb: serial: cp210x: Add USB ID for Netgear Switches embedded serial adapter

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Luiz Angelo Daros de Luca 

commit 90625070c4253377025878c4e82feed8b35c7116 upstream.

This adds NetGear Managed Switch M4100 series, M5300 series, M7100 series
USB ID (0846:0110) to the cp210x driver. Without this, the serial
adapter is not recognized in Linux. Description was obtained from
an Netgear Eng.

Signed-off-by: Luiz Angelo Daros de Luca 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/serial/cp210x.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index 4747d1c..8585c6e 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -53,6 +53,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x0489, 0xE000) }, /* Pirelli Broadband S.p.A, DP-L10 
SIP/GSM Mobile */
{ USB_DEVICE(0x0489, 0xE003) }, /* Pirelli Broadband S.p.A, DP-L10 
SIP/GSM Mobile */
{ USB_DEVICE(0x0745, 0x1000) }, /* CipherLab USB CCD Barcode Scanner 
1000 */
+   { USB_DEVICE(0x0846, 0x1100) }, /* NetGear Managed Switch M4100 series, 
M5300 series, M7100 series */
{ USB_DEVICE(0x08e6, 0x5501) }, /* Gemalto Prox-PU/CU contactless 
smartcard reader */
{ USB_DEVICE(0x08FD, 0x000A) }, /* Digianswer A/S , ZigBee/802.15.4 MAC 
Device */
{ USB_DEVICE(0x0BED, 0x1100) }, /* MEI (TM) Cashflow-SC Bill/Voucher 
Acceptor */
-- 
1.8.1.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 075/133] ARM: use linker magic for vectors and vector stubs

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Russell King 

commit b9b32bf70f2fb710b07c94e13afbc729afe221da upstream.

Use linker magic to create the vectors and vector stubs: we can tell the
linker to place them at an appropriate VMA, but keep the LMA within the
kernel.  This gets rid of some unnecessary symbol manipulation, and
have the linker calculate the relocations appropriately.

Acked-by: Nicolas Pitre 
Signed-off-by: Russell King 
Signed-off-by: Kamal Mostafa 
---
 arch/arm/kernel/entry-armv.S  | 28 ++--
 arch/arm/kernel/vmlinux.lds.S | 17 +
 2 files changed, 27 insertions(+), 18 deletions(-)

diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index a4af8e8..c19779f 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -1035,7 +1035,7 @@ ENDPROC(vector_\name)
 1:
.endm
 
-   .globl  __stubs_start
+   .section .stubs, "ax", %progbits
 __stubs_start:
@ This must be the first word
.word   vector_swi
@@ -1162,24 +1162,16 @@ vector_addrexcptn:
 vector_fiq:
subspc, lr, #4
 
-   .globl  __stubs_end
-__stubs_end:
-
-   .equstubs_offset, __vectors_start + 0x1000 - __stubs_start
-
-   .globl  __vectors_start
+   .section .vectors, "ax", %progbits
 __vectors_start:
-   W(b)vector_rst + stubs_offset
-   W(b)vector_und + stubs_offset
-   W(ldr)  pc, .LCvswi + stubs_offset
-   W(b)vector_pabt + stubs_offset
-   W(b)vector_dabt + stubs_offset
-   W(b)vector_addrexcptn + stubs_offset
-   W(b)vector_irq + stubs_offset
-   W(b)vector_fiq + stubs_offset
-
-   .globl  __vectors_end
-__vectors_end:
+   W(b)vector_rst
+   W(b)vector_und
+   W(ldr)  pc, __vectors_start + 0x1000
+   W(b)vector_pabt
+   W(b)vector_dabt
+   W(b)vector_addrexcptn
+   W(b)vector_irq
+   W(b)vector_fiq
 
.data
 
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 11c1785..f9036ac 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -148,6 +148,23 @@ SECTIONS
. = ALIGN(PAGE_SIZE);
__init_begin = .;
 #endif
+   /*
+* The vectors and stubs are relocatable code, and the
+* only thing that matters is their relative offsets
+*/
+   __vectors_start = .;
+   .vectors 0 : AT(__vectors_start) {
+   *(.vectors)
+   }
+   . = __vectors_start + SIZEOF(.vectors);
+   __vectors_end = .;
+
+   __stubs_start = .;
+   .stubs 0x1000 : AT(__stubs_start) {
+   *(.stubs)
+   }
+   . = __stubs_start + SIZEOF(.stubs);
+   __stubs_end = .;
 
INIT_TEXT_SECTION(8)
.exit.text : {
-- 
1.8.1.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 011/133] USB: option: append Petatel NP10T device to GSM modems list

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Daniil Bolsun 

commit c38e83b6cc2adf80e3f091fd92cfbeacc9748347 upstream.

This patch was tested on 3.10.1 kernel.

Same models of Petatel NP10T modems have different device IDs.
Unfortunately they have no additional revision information on a board
which may treat them as different devices. Currently I've seen only
two NP10T devices with various IDs. Possibly Petatel NP10T list will
be appended upon devices with new IDs will appear.

Signed-off-by: Daniil Bolsun 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/serial/option.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index c94fe3e..604d8e7 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -444,7 +444,8 @@ static void option_instat_callback(struct urb *urb);
 
 /* Hyundai Petatel Inc. products */
 #define PETATEL_VENDOR_ID  0x1ff4
-#define PETATEL_PRODUCT_NP10T  0x600e
+#define PETATEL_PRODUCT_NP10T_600A 0x600a
+#define PETATEL_PRODUCT_NP10T_600E 0x600e
 
 /* TP-LINK Incorporated products */
 #define TPLINK_VENDOR_ID   0x2357
@@ -1329,7 +1330,8 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(MEDIATEK_VENDOR_ID, 
MEDIATEK_PRODUCT_DC_4COM2, 0xff, 0x02, 0x01) },
{ USB_DEVICE_AND_INTERFACE_INFO(MEDIATEK_VENDOR_ID, 
MEDIATEK_PRODUCT_DC_4COM2, 0xff, 0x00, 0x00) },
{ USB_DEVICE(CELLIENT_VENDOR_ID, CELLIENT_PRODUCT_MEN200) },
-   { USB_DEVICE(PETATEL_VENDOR_ID, PETATEL_PRODUCT_NP10T) },
+   { USB_DEVICE(PETATEL_VENDOR_ID, PETATEL_PRODUCT_NP10T_600A) },
+   { USB_DEVICE(PETATEL_VENDOR_ID, PETATEL_PRODUCT_NP10T_600E) },
{ USB_DEVICE(TPLINK_VENDOR_ID, TPLINK_PRODUCT_MA180),
  .driver_info = (kernel_ulong_t)_intf4_blacklist },
{ USB_DEVICE(CHANGHONG_VENDOR_ID, CHANGHONG_PRODUCT_CH690) },
-- 
1.8.1.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 013/133] USB: cp210x: add MMB and PI ZigBee USB Device Support

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Sami Rahman 

commit 7681156982026ebf7eafd7301eb0374d7648d068 upstream.

Added support for MMB Networks and Planet Innovation Ingeni ZigBee USB
devices using customized Silicon Labs' CP210x.c USB to UART bridge
drivers with PIDs: 88A4, 88A5.

Signed-off-by: Sami Rahman 
Tested-by: Sami Rahman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/serial/cp210x.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index d0e9f5d..3850e92 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -119,6 +119,8 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x10C4, 0x85F8) }, /* Virtenio Preon32 */
{ USB_DEVICE(0x10C4, 0x8664) }, /* AC-Services CAN-IF */
{ USB_DEVICE(0x10C4, 0x8665) }, /* AC-Services OBD-IF */
+   { USB_DEVICE(0x10C4, 0x88A4) }, /* MMB Networks ZigBee USB Device */
+   { USB_DEVICE(0x10C4, 0x88A5) }, /* Planet Innovation Ingeni ZigBee USB 
Device */
{ USB_DEVICE(0x10C4, 0xEA60) }, /* Silicon Labs factory default */
{ USB_DEVICE(0x10C4, 0xEA61) }, /* Silicon Labs factory default */
{ USB_DEVICE(0x10C4, 0xEA70) }, /* Silicon Labs factory default */
-- 
1.8.1.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 077/133] ARM: allow kuser helpers to be removed from the vector page

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Russell King 

commit f6f91b0d9fd971c630cef908dde8fe8795aefbf8 upstream.

Provide a kernel configuration option to allow the kernel user helpers
to be removed from the vector page, thereby preventing their use with
ROP (return orientated programming) attacks.  This option is only
visible for CPU architectures which natively support all the operations
which kernel user helpers would normally provide, and must be enabled
with caution.

Acked-by: Nicolas Pitre 
Signed-off-by: Russell King 
Signed-off-by: Kamal Mostafa 
---
 arch/arm/kernel/entry-armv.S |  3 +++
 arch/arm/kernel/traps.c  | 23 ++-
 arch/arm/mm/Kconfig  | 34 ++
 3 files changed, 51 insertions(+), 9 deletions(-)

diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 4c28aff..5492d72 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -795,6 +795,7 @@ ENDPROC(__switch_to)
.endr
.endm
 
+#ifdef CONFIG_KUSER_HELPERS
.align  5
.globl  __kuser_helper_start
 __kuser_helper_start:
@@ -981,6 +982,8 @@ __kuser_helper_version: @ 
0x0ffc
.globl  __kuser_helper_end
 __kuser_helper_end:
 
+#endif
+
  THUMB(.thumb  )
 
 /*
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 366aa93..1392beb 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -807,23 +807,32 @@ void __init trap_init(void)
return;
 }
 
-static void __init kuser_get_tls_init(unsigned long vectors)
+#ifdef CONFIG_KUSER_HELPERS
+static void __init kuser_init(void *vectors)
 {
+   extern char __kuser_helper_start[], __kuser_helper_end[];
+   int kuser_sz = __kuser_helper_end - __kuser_helper_start;
+
+   memcpy(vectors + 0x1000 - kuser_sz, __kuser_helper_start, kuser_sz);
+
/*
 * vectors + 0xfe0 = __kuser_get_tls
 * vectors + 0xfe8 = hardware TLS instruction at 0x0fe8
 */
if (tls_emu || has_tls_reg)
-   memcpy((void *)vectors + 0xfe0, (void *)vectors + 0xfe8, 4);
+   memcpy(vectors + 0xfe0, vectors + 0xfe8, 4);
+}
+#else
+static void __init kuser_init(void *vectors)
+{
 }
+#endif
 
 void __init early_trap_init(void *vectors_base)
 {
unsigned long vectors = (unsigned long)vectors_base;
extern char __stubs_start[], __stubs_end[];
extern char __vectors_start[], __vectors_end[];
-   extern char __kuser_helper_start[], __kuser_helper_end[];
-   int kuser_sz = __kuser_helper_end - __kuser_helper_start;
unsigned i;
 
vectors_page = vectors_base;
@@ -844,12 +853,8 @@ void __init early_trap_init(void *vectors_base)
 */
memcpy((void *)vectors, __vectors_start, __vectors_end - 
__vectors_start);
memcpy((void *)vectors + 0x1000, __stubs_start, __stubs_end - 
__stubs_start);
-   memcpy((void *)vectors + 0x1000 - kuser_sz, __kuser_helper_start, 
kuser_sz);
 
-   /*
-* Do processor specific fixups for the kuser helpers
-*/
-   kuser_get_tls_init(vectors);
+   kuser_init(vectors_base);
 
/*
 * Copy signal return handlers into the vector page, and
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 3fd629d..1d5ee0a 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -404,24 +404,28 @@ config CPU_32v3
select CPU_USE_DOMAINS if MMU
select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
select TLS_REG_EMUL if SMP || !MMU
+   select NEED_KUSER_HELPERS
 
 config CPU_32v4
bool
select CPU_USE_DOMAINS if MMU
select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
select TLS_REG_EMUL if SMP || !MMU
+   select NEED_KUSER_HELPERS
 
 config CPU_32v4T
bool
select CPU_USE_DOMAINS if MMU
select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
select TLS_REG_EMUL if SMP || !MMU
+   select NEED_KUSER_HELPERS
 
 config CPU_32v5
bool
select CPU_USE_DOMAINS if MMU
select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
select TLS_REG_EMUL if SMP || !MMU
+   select NEED_KUSER_HELPERS
 
 config CPU_32v6
bool
@@ -756,6 +760,7 @@ config CPU_BPREDICT_DISABLE
 
 config TLS_REG_EMUL
bool
+   select NEED_KUSER_HELPERS
help
  An SMP system using a pre-ARMv6 processor (there are apparently
  a few prototypes like that in existence) and therefore access to
@@ -763,11 +768,40 @@ config TLS_REG_EMUL
 
 config NEEDS_SYSCALL_FOR_CMPXCHG
bool
+   select NEED_KUSER_HELPERS
help
  SMP on a pre-ARMv6 processor?  Well OK then.
  Forget about fast user space cmpxchg support.
  It is just not possible.
 
+config NEED_KUSER_HELPERS
+   bool
+
+config KUSER_HELPERS
+   bool "Enable kuser helpers in vector page" if !NEED_KUSER_HELPERS

[PATCH 071/133] drm/i915: fix missed hunk after GT access breakage

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Ben Widawsky 

commit e1b4d3036c07ff137955fb1c0197ab62534f46ec upstream.

Upon some code refactoring, a hunk was missed. This was fixed for
next, but missed the current trees, and hasn't yet been merged by Dave
Airlie. It is fixed in:
commit 907b28c56ea40629aa6595ddfa414ec2fc7da41c
Author: Chris Wilson 
Date:   Fri Jul 19 20:36:52 2013 +0100

drm/i915: Colocate all GT access routines in the same file

It is introduced by:
commit 181d1b9e31c668259d3798c521672afb8edd355c
Author: Daniel Vetter 
Date:   Sun Jul 21 13:16:24 2013 +0200

drm/i915: fix up gt init sequence fallout

Reported-by: Dave Jones 
Signed-off-by: Ben Widawsky 
Signed-off-by: Dave Airlie 
[ kamal: backport to 3.8 (context) ]
Signed-off-by: Kamal Mostafa 
---
 drivers/gpu/drm/i915/i915_dma.c | 1 +
 drivers/gpu/drm/i915/i915_drv.h | 1 +
 drivers/gpu/drm/i915/intel_pm.c | 6 ++
 3 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 565a889..7e5f232 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1561,6 +1561,7 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
intel_detect_pch(dev);
 
intel_irq_init(dev);
+   intel_pm_init(dev);
intel_gt_sanitize(dev);
intel_gt_init(dev);
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8c661512..d47283d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1328,6 +1328,7 @@ void i915_hangcheck_elapsed(unsigned long data);
 void i915_handle_error(struct drm_device *dev, bool wedged);
 
 extern void intel_irq_init(struct drm_device *dev);
+extern void intel_pm_init(struct drm_device *dev);
 extern void intel_gt_init(struct drm_device *dev);
 extern void intel_gt_sanitize(struct drm_device *dev);
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6538d3f..b035d41 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4447,6 +4447,12 @@ void intel_gt_init(struct drm_device *dev)
dev_priv->gt.force_wake_get = __gen6_gt_force_wake_get;
dev_priv->gt.force_wake_put = __gen6_gt_force_wake_put;
}
+}
+
+void intel_pm_init(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+
INIT_DELAYED_WORK(_priv->rps.delayed_resume_work,
  intel_gen6_powersave_work);
 }
-- 
1.8.1.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 082/133] virtio/console: Add pipe_lock/unlock for splice_write

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Yoshihiro YUNOMAE 

commit 2b4fbf029dff5a28d9bf646346dea891ec43398a upstream.

Add pipe_lock/unlock for splice_write to avoid oops by following competition:

(1) An application gets fds of a trace buffer, virtio-serial, pipe.
(2) The application does fork()
(3) The processes execute splice_read(trace buffer) and
splice_write(virtio-serial) via same pipe.

   
  get fds of a trace buffer,
 virtio-serial, pipe
  |
fork()--create+
  |   |
  splice(read)|   ---+
  splice(write)   |  +-- no competition
  |   splice(read)   |
  |   splice(write)   ---+
  |   |
  splice(read)|
  splice(write)   splice(read)-- competition
  |   splice(write)

Two processes share a pipe_inode_info structure. If the child execute
splice(read) when the parent tries to execute splice(write), the
structure can be broken. Existing virtio-serial driver does not get
lock for the structure in splice_write, so this competition will induce
oops.


 BUG: unable to handle kernel NULL pointer dereference at 0018
 IP: [] splice_from_pipe_feed+0x6f/0x130
 PGD 7223e067 PUD 72391067 PMD 0
 Oops:  [#1] SMP
 Modules linked in: lockd bnep bluetooth rfkill sunrpc ip6t_REJECT 
nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter 
ip6_tables snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc 
snd_timer snd soundcore pcspkr virtio_net virtio_balloon i2c_piix4 i2c_core 
microcode uinput floppy
 CPU: 0 PID: 1072 Comm: compete-test Not tainted 3.10.0ws+ #55
 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
 task: 880071b98000 ti: 88007b55e000 task.ti: 88007b55e000
 RIP: 0010:[]  [] 
splice_from_pipe_feed+0x6f/0x130
 RSP: 0018:88007b55fd78  EFLAGS: 00010287
 RAX:  RBX: 88007b55fe20 RCX: 
 RDX: 1000 RSI: 88007a95ba30 RDI: 880036f9e6c0
 RBP: 88007b55fda8 R08: 06ec R09: 880077626708
 R10: 0003 R11: 8139ca59 R12: 88007a95ba30
 R13:  R14: 8139dd00 R15: 880036f9e6c0
 FS:  7f2e2e3a0740() GS:88007fc0() knlGS:
 CS:  0010 DS:  ES:  CR0: 8005003b
 CR2: 0018 CR3: 71bd1000 CR4: 06f0
 DR0:  DR1:  DR2: 
 DR3:  DR6: 0ff0 DR7: 0400
 Stack:
  8139ca59 88007b55fe20 880036f9e6c0 8139dd00
  8800776266c0 880077626708 88007b55fde8 811a6e8e
  88007b55fde8 8139ca59 880036f9e6c0 88007b55fe20
 Call Trace:
  [] ? alloc_buf.isra.13+0x39/0xb0
  [] ? virtcons_restore+0x100/0x100
  [] __splice_from_pipe+0x7e/0x90
  [] ? alloc_buf.isra.13+0x39/0xb0
  [] port_fops_splice_write+0xe9/0x140
  [] ? selinux_file_permission+0xc4/0x120
  [] ? wait_port_writable+0x1b0/0x1b0
  [] do_splice_from+0xa0/0x110
  [] SyS_splice+0x5ff/0x6b0
  [] tracesys+0xdd/0xe2
 Code: 49 8b 87 80 00 00 00 4c 8d 24 d0 8b 53 04 41 8b 44 24 0c 4d 8b 6c 24 10 
39 d0 89 03 76 02 89 13 49 8b 44 24 10 4c 89 e6 4c 89 ff  50 18 85 c0 0f 85 
aa 00 00 00 48 89 da 4c 89 e6 4c 89 ff 41
 RIP  [] splice_from_pipe_feed+0x6f/0x130
  RSP 
 CR2: 0018
 ---[ end trace 24572beb7764de59 ]---

V2: Fix a locking problem for error
V3: Add Reviewed-by lines and stable@ line in sign-off area

Signed-off-by: Yoshihiro YUNOMAE 
Reviewed-by: Amit Shah 
Reviewed-by: Masami Hiramatsu 
Cc: Amit Shah 
Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Signed-off-by: Rusty Russell 
Signed-off-by: Kamal Mostafa 
---
 drivers/char/virtio_console.c | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index 0dfd175..3e338a7 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -942,16 +942,21 @@ static ssize_t port_fops_splice_write(struct 
pipe_inode_info *pipe,
 * pipe->nrbufs == 0 means there are no data to transfer,
 * so this returns just 0 for no data.
 */
-   if (!pipe->nrbufs)
-   return 0;
+   pipe_lock(pipe);
+   if (!pipe->nrbufs) {
+   ret = 0;
+   goto error_out;
+   }
 
ret = wait_port_writable(port, filp->f_flags & O_NONBLOCK);
if (ret < 0)
-   return ret;
+   goto error_out;
 
buf = alloc_buf(port->out_vq, 0, pipe->nrbufs);
-   if (!buf)
-   return -ENOMEM;
+   if (!buf) {
+   ret = -ENOMEM;
+   goto 

[PATCH 127/133] net_sched: Fix stack info leak in cbq_dump_wrr().

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: "David S. Miller" 

[ Upstream commit a0db856a95a29efb1c23db55c02d9f0ff4f0db48 ]

Make sure the reserved fields, and padding (if any), are
fully initialized.

Based upon a patch by Dan Carpenter and feedback from
Joe Perches.

Signed-off-by: David S. Miller 
Signed-off-by: Kamal Mostafa 
---
 net/sched/sch_cbq.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/sched/sch_cbq.c b/net/sched/sch_cbq.c
index ced81a1..27cedc1 100644
--- a/net/sched/sch_cbq.c
+++ b/net/sched/sch_cbq.c
@@ -1468,6 +1468,7 @@ static int cbq_dump_wrr(struct sk_buff *skb, struct 
cbq_class *cl)
unsigned char *b = skb_tail_pointer(skb);
struct tc_cbq_wrropt opt;
 
+   memset(, 0, sizeof(opt));
opt.flags = 0;
opt.allot = cl->allot;
opt.priority = cl->priority + 1;
-- 
1.8.1.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 v3 1/5] mm: Track mappings that have been written via ptes

[Andy Lutomirski]

This will allow filesystems to identify when their mappings have
been modified using a pte.  The idea is that, ideally, filesystems will update 
ctime and mtime sometime after any mmaped write.

This is handled in core mm code for two reasons:

1. Performance.  Setting a bit directly is faster than an indirect
   call to a vma op.

2. Simplicity.  The cmtime bit is set with lots of mm locks held.
   Rather than making filesystems add a new vm operation that needs
   to be aware of locking, it's easier to just get it right in core
   code.

For filesystems that don't use the deferred cmtime update mechanism,
setting the AS_CMTIME bit has no effect.

Signed-off-by: Andy Lutomirski 
---
 include/linux/pagemap.h | 11 +++
 mm/memory.c |  7 ++-
 mm/rmap.c   | 27 +--
 3 files changed, 42 insertions(+), 3 deletions(-)

diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index e3dea75..f98fe2d 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -25,6 +25,7 @@ enum mapping_flags {
AS_MM_ALL_LOCKS = __GFP_BITS_SHIFT + 2, /* under mm_take_all_locks() */
AS_UNEVICTABLE  = __GFP_BITS_SHIFT + 3, /* e.g., ramdisk, SHM_LOCK */
AS_BALLOON_MAP  = __GFP_BITS_SHIFT + 4, /* balloon page special map */
+   AS_CMTIME   = __GFP_BITS_SHIFT + 5, /* cmtime update deferred */
 };
 
 static inline void mapping_set_error(struct address_space *mapping, int error)
@@ -74,6 +75,16 @@ static inline gfp_t mapping_gfp_mask(struct address_space * 
mapping)
return (__force gfp_t)mapping->flags & __GFP_BITS_MASK;
 }
 
+static inline void mapping_set_cmtime(struct address_space * mapping)
+{
+   set_bit(AS_CMTIME, >flags);
+}
+
+static inline bool mapping_test_clear_cmtime(struct address_space * mapping)
+{
+   return test_and_clear_bit(AS_CMTIME, >flags);
+}
+
 /*
  * This is non-atomic.  Only to be used before the mapping is activated.
  * Probably needs a barrier...
diff --git a/mm/memory.c b/mm/memory.c
index 4026841..1737a90 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1150,8 +1150,13 @@ again:
if (PageAnon(page))
rss[MM_ANONPAGES]--;
else {
-   if (pte_dirty(ptent))
+   if (pte_dirty(ptent)) {
+   struct address_space *mapping =
+   page_mapping(page);
+   if (mapping)
+   mapping_set_cmtime(mapping);
set_page_dirty(page);
+   }
if (pte_young(ptent) &&
likely(!(vma->vm_flags & VM_SEQ_READ)))
mark_page_accessed(page);
diff --git a/mm/rmap.c b/mm/rmap.c
index b2e29ac..2e3fb27 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -928,6 +928,10 @@ static int page_mkclean_file(struct address_space 
*mapping, struct page *page)
}
}
mutex_unlock(>i_mmap_mutex);
+
+   if (ret)
+   mapping_set_cmtime(mapping);
+
return ret;
 }
 
@@ -1179,6 +1183,19 @@ out:
 }
 
 /*
+ * Mark a page's mapping for future cmtime update.  It's safe to call this
+ * on any page, but it only has any effect if the page is backed by a mapping
+ * that uses mapping_test_clear_cmtime to handle file time updates.  This means
+ * that there's no need to call this on for non-VM_SHARED vmas.
+ */
+static void page_set_cmtime(struct page *page)
+{
+   struct address_space *mapping = page_mapping(page);
+   if (mapping)
+   mapping_set_cmtime(mapping);
+}
+
+/*
  * Subfunctions of try_to_unmap: try_to_unmap_one called
  * repeatedly from try_to_unmap_ksm, try_to_unmap_anon or try_to_unmap_file.
  */
@@ -1219,8 +1236,11 @@ int try_to_unmap_one(struct page *page, struct 
vm_area_struct *vma,
pteval = ptep_clear_flush(vma, address, pte);
 
/* Move the dirty bit to the physical page now the pte is gone. */
-   if (pte_dirty(pteval))
+   if (pte_dirty(pteval)) {
set_page_dirty(page);
+   if (vma->vm_flags & VM_SHARED)
+   page_set_cmtime(page);
+   }
 
/* Update high watermark before we lower rss */
update_hiwater_rss(mm);
@@ -1413,8 +1433,11 @@ static int try_to_unmap_cluster(unsigned long cursor, 
unsigned int *mapcount,
}
 
/* Move the dirty bit to the physical page now the pte is gone. 
*/
-   if (pte_dirty(pteval))
+   if (pte_dirty(pteval)) {
set_page_dirty(page);
+   if (vma->vm_flags & VM_SHARED)
+   page_set_cmtime(page);
+   }
 
page_remove_rmap(page);

[PATCH 085/133] x86, fpu: correct the asm constraints for fxsave, unbreak mxcsr.daz

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: "H.J. Lu" 

commit eaa5a990191d204ba0f9d35dbe5505ec2cdd1460 upstream.

GCC will optimize mxcsr_feature_mask_init in arch/x86/kernel/i387.c:

memset(_scratch, 0, sizeof(struct i387_fxsave_struct));
asm volatile("fxsave %0" : : "m" (fx_scratch));
mask = fx_scratch.mxcsr_mask;
if (mask == 0)
mask = 0xffbf;

to

memset(_scratch, 0, sizeof(struct i387_fxsave_struct));
asm volatile("fxsave %0" : : "m" (fx_scratch));
mask = 0xffbf;

since asm statement doesn’t say it will update fx_scratch.  As the
result, the DAZ bit will be cleared.  This patch fixes it. This bug
dates back to at least kernel 2.6.12.

Signed-off-by: H. Peter Anvin 
Signed-off-by: Kamal Mostafa 
---
 arch/x86/kernel/i387.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
index cb33909..f7ea30d 100644
--- a/arch/x86/kernel/i387.c
+++ b/arch/x86/kernel/i387.c
@@ -116,7 +116,7 @@ static void __cpuinit mxcsr_feature_mask_init(void)
 
if (cpu_has_fxsr) {
memset(_scratch, 0, sizeof(struct i387_fxsave_struct));
-   asm volatile("fxsave %0" : : "m" (fx_scratch));
+   asm volatile("fxsave %0" : "+m" (fx_scratch));
mask = fx_scratch.mxcsr_mask;
if (mask == 0)
mask = 0xffbf;
-- 
1.8.1.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: [PATCH v2] RFC: interrupt consistency check for OF GPIO IRQs

[Linus Walleij]

On Thu, Aug 15, 2013 at 2:31 PM, Tomasz Figa  wrote:
> On Thursday 15 of August 2013 14:12:43 Lars Poeschel wrote:

> Well, there are basically no restrictions over the format of GPIO and
> interrupt specifiers. Any driver is free to define its own and provide
> private .xlate() callback to parse it. No assumptions should be made about
> the format, other than each GPIO/interrupt is specified by numer of cells
> specified in #interrupt- or #gpio-cells property of the controller.

Surely we can assume that the binding documents can be trusted?
And for this we only need this:
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt

Yours,
Linus Walleij
--
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 0/5] Rework mtime and ctime updates on mmaped

[Andy Lutomirski]

Writes via mmap currently update mtime and ctime in ->page_mkwrite.
This hurts both throughput and latency.  In workloads that dirty a
large number of mmapped pages, ->page_mkwrite can be hot and
file_update_time is slow and scales poorly.  Updating timestamps can
also sleep, which hurts latency for real-time workloads.

This is also a correctness issue.  SuS says:

The st_ctime and st_mtime fields of a file that is mapped with
MAP_SHARED and PROT_WRITE, will be marked for update at some point
in the interval between a write reference to the mapped region and
the next call to msync() with MS_ASYNC or MS_SYNC for that portion
of the file by any process. If there is no such call, these fields
may be marked for update at any time after a write reference if
the underlying file is modified as a result.

Currently, if the same mmapped page is written twice, the timestamp
may not be update at all after the second write, whereas SuS (and
anything using timestamps to invalidate caches, backup data, etc.)
would expect the timestamp to eventually be updated.

This patchset attempts to fix both issues at once.  It adds a new
address_space flag AS_CMTIME that is set atomically whenever the
system transfers a pte dirty bit to a struct page backed by the
address_space.  This can happen with various locks held and when low
on memory.

Later on, a new address_space op ->flush_cmtime is called at various
points at which a filesystem should update timestamps if the file was
previously modified through mmap.

The core changes have no effect on unmodified filesystems.  To opt in, a 
filesystem should implement ->flush_ctime (most likely by using 
generic_flush_cmtime) and should avoid updating timestamps in ->page_mkwrite.

I've converted ext4.  If it works well, it will be easy to convert all
the other filesystems.

Changes from v2:
 - The core code now interacts with filesystems only through
   address_space ops, so there should be fewer layering issues.
 - MS_ASYNC is handled correctly.

Changes from v1:
 - inode_update_time_writable now locks against the fs freezer.
 - Minor cleanups.
 - Major changelog improvements.

Andy Lutomirski (5):
  mm: Track mappings that have been written via ptes
  fs: Add inode_update_time_writable
  mm: Notify filesystems when it's time to apply a deferred cmtime
update
  mm: Scan for dirty ptes and update cmtime on MS_ASYNC
  ext4: Defer mmap cmtime update until writeback

 fs/ext4/inode.c   |  4 ++-
 fs/inode.c| 72 +++-
 include/linux/fs.h| 10 ++
 include/linux/pagemap.h   | 11 +++
 include/linux/writeback.h |  1 +
 mm/memory.c   |  7 +++-
 mm/mmap.c |  9 -
 mm/msync.c| 83 ---
 mm/page-writeback.c   | 26 +++
 mm/rmap.c | 27 +--
 10 files changed, 219 insertions(+), 31 deletions(-)

-- 
1.8.3.1

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

[PATCH 126/133] usbnet: do not pretend to support SG/TSO

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Eric Dumazet 

[ Upstream commit 20f0170377264e8449b6987041f0bcc4d746d3ed ]

usbnet doesn't support yet SG, so drivers should not advertise SG or TSO
capabilities, as they allow TCP stack to build large TSO packets that
need to be linearized and might use order-5 pages.

This adds an extra copy overhead and possible allocation failures.

Current code ignore skb_linearize() return code so crashes are even
possible.

Best is to not pretend SG/TSO is supported, and add this again when/if
usbnet really supports SG for devices who could get a performance gain.

Based on a prior patch from Freddy Xin 

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Kamal Mostafa 
---
 drivers/net/usb/smsc75xx.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
index 937c09d..506a024 100644
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -45,7 +45,6 @@
 #define EEPROM_MAC_OFFSET  (0x01)
 #define DEFAULT_TX_CSUM_ENABLE (true)
 #define DEFAULT_RX_CSUM_ENABLE (true)
-#define DEFAULT_TSO_ENABLE (true)
 #define SMSC75XX_INTERNAL_PHY_ID   (1)
 #define SMSC75XX_TX_OVERHEAD   (8)
 #define MAX_RX_FIFO_SIZE   (20 * 1024)
@@ -1412,17 +1411,14 @@ static int smsc75xx_bind(struct usbnet *dev, struct 
usb_interface *intf)
 
INIT_WORK(>set_multicast, smsc75xx_deferred_multicast_write);
 
-   if (DEFAULT_TX_CSUM_ENABLE) {
+   if (DEFAULT_TX_CSUM_ENABLE)
dev->net->features |= NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM;
-   if (DEFAULT_TSO_ENABLE)
-   dev->net->features |= NETIF_F_SG |
-   NETIF_F_TSO | NETIF_F_TSO6;
-   }
+
if (DEFAULT_RX_CSUM_ENABLE)
dev->net->features |= NETIF_F_RXCSUM;
 
dev->net->hw_features = NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
-   NETIF_F_SG | NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_RXCSUM;
+   NETIF_F_RXCSUM;
 
ret = smsc75xx_wait_ready(dev, 0);
if (ret < 0) {
@@ -2198,8 +2194,6 @@ static struct sk_buff *smsc75xx_tx_fixup(struct usbnet 
*dev,
 {
u32 tx_cmd_a, tx_cmd_b;
 
-   skb_linearize(skb);
-
if (skb_headroom(skb) < SMSC75XX_TX_OVERHEAD) {
struct sk_buff *skb2 =
skb_copy_expand(skb, SMSC75XX_TX_OVERHEAD, 0, flags);
-- 
1.8.1.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 131/133] ndisc: Add missing inline to ndisc_addr_option_pad

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Joe Perches 

[ Upstream commit d9d10a30964504af834d8d250a0c76d4ae91eb1e ]

Signed-off-by: Joe Perches 
Signed-off-by: David S. Miller 
Signed-off-by: Kamal Mostafa 
---
 include/net/ndisc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/net/ndisc.h b/include/net/ndisc.h
index 23b3a7c..c9db93d 100644
--- a/include/net/ndisc.h
+++ b/include/net/ndisc.h
@@ -119,7 +119,7 @@ extern struct ndisc_options *ndisc_parse_options(u8 *opt, 
int opt_len,
  * if RFC 3831 IPv6-over-Fibre Channel is ever implemented it may
  * also need a pad of 2.
  */
-static int ndisc_addr_option_pad(unsigned short type)
+static inline int ndisc_addr_option_pad(unsigned short type)
 {
switch (type) {
case ARPHRD_INFINIBAND: return 2;
-- 
1.8.1.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 124/133] sysctl net: Keep tcp_syn_retries inside the boundary

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Michal Tesar 

[ Upstream commit 651e92716aaae60fc41b9652f54cb6803896e0da ]

Limit the min/max value passed to the
/proc/sys/net/ipv4/tcp_syn_retries.

Signed-off-by: Michal Tesar 
Signed-off-by: David S. Miller 
Signed-off-by: Kamal Mostafa 
---
 net/ipv4/sysctl_net_ipv4.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index d84400b..63632ea 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -35,6 +35,8 @@ static int tcp_adv_win_scale_min = -31;
 static int tcp_adv_win_scale_max = 31;
 static int ip_ttl_min = 1;
 static int ip_ttl_max = 255;
+static int tcp_syn_retries_min = 1;
+static int tcp_syn_retries_max = MAX_TCP_SYNCNT;
 static int ip_ping_group_range_min[] = { 0, 0 };
 static int ip_ping_group_range_max[] = { GID_T_MAX, GID_T_MAX };
 
@@ -330,7 +332,9 @@ static struct ctl_table ipv4_table[] = {
.data   = _tcp_syn_retries,
.maxlen = sizeof(int),
.mode   = 0644,
-   .proc_handler   = proc_dointvec
+   .proc_handler   = proc_dointvec_minmax,
+   .extra1 = _syn_retries_min,
+   .extra2 = _syn_retries_max
},
{
.procname   = "tcp_synack_retries",
-- 
1.8.1.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 110/133] hwmon: (adt7470) Fix incorrect return code check

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Curt Brune 

commit 93d783bcca69bfacc8dc739d8a050498402587b5 upstream.

In adt7470_write_word_data(), which writes two bytes using
i2c_smbus_write_byte_data(), the return codes are incorrectly AND-ed
together when they should be OR-ed together.

The return code of i2c_smbus_write_byte_data() is zero for success.

The upshot is only the first byte was ever written to the hardware.
The 2nd byte was never written out.

I noticed that trying to set the fan speed limits was not working
correctly on my system.  Setting the fan speed limits is the only
code that uses adt7470_write_word_data().  After making the change
the limit settings work and the alarms work also.

Signed-off-by: Curt Brune 
Signed-off-by: Guenter Roeck 
Signed-off-by: Kamal Mostafa 
---
 drivers/hwmon/adt7470.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwmon/adt7470.c b/drivers/hwmon/adt7470.c
index 39ecb1a..aa63420 100644
--- a/drivers/hwmon/adt7470.c
+++ b/drivers/hwmon/adt7470.c
@@ -215,7 +215,7 @@ static inline int adt7470_write_word_data(struct i2c_client 
*client, u8 reg,
  u16 value)
 {
return i2c_smbus_write_byte_data(client, reg, value & 0xFF)
-  && i2c_smbus_write_byte_data(client, reg + 1, value >> 8);
+  || i2c_smbus_write_byte_data(client, reg + 1, value >> 8);
 }
 
 static void adt7470_init_client(struct i2c_client *client)
-- 
1.8.1.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 122/133] fs/proc/task_mmu.c: fix buffer overflow in add_page_map()

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: yonghua zheng 

commit 8c8296223f3abb142be8fc31711b18a704c0e7d8 upstream.

Recently we met quite a lot of random kernel panic issues after enabling
CONFIG_PROC_PAGE_MONITOR.  After debuggind we found this has something
to do with following bug in pagemap:

In struct pagemapread:

  struct pagemapread {
  int pos, len;
  pagemap_entry_t *buffer;
  bool v2;
  };

pos is number of PM_ENTRY_BYTES in buffer, but len is the size of
buffer, it is a mistake to compare pos and len in add_page_map() for
checking buffer is full or not, and this can lead to buffer overflow and
random kernel panic issue.

Correct len to be total number of PM_ENTRY_BYTES in buffer.

[a...@linux-foundation.org: document pagemapread.pos and .len units, fix 
PM_ENTRY_BYTES definition]
Signed-off-by: Yonghua Zheng 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Kamal Mostafa 
---
 fs/proc/task_mmu.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index ca5ce7f..f31d90f 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -792,14 +792,14 @@ typedef struct {
 } pagemap_entry_t;
 
 struct pagemapread {
-   int pos, len;
+   int pos, len;   /* units: PM_ENTRY_BYTES, not bytes */
pagemap_entry_t *buffer;
 };
 
 #define PAGEMAP_WALK_SIZE  (PMD_SIZE)
 #define PAGEMAP_WALK_MASK  (PMD_MASK)
 
-#define PM_ENTRY_BYTES  sizeof(u64)
+#define PM_ENTRY_BYTES  sizeof(pagemap_entry_t)
 #define PM_STATUS_BITS  3
 #define PM_STATUS_OFFSET(64 - PM_STATUS_BITS)
 #define PM_STATUS_MASK  (((1LL << PM_STATUS_BITS) - 1) << PM_STATUS_OFFSET)
@@ -1038,8 +1038,8 @@ static ssize_t pagemap_read(struct file *file, char 
__user *buf,
if (!count)
goto out_task;
 
-   pm.len = PM_ENTRY_BYTES * (PAGEMAP_WALK_SIZE >> PAGE_SHIFT);
-   pm.buffer = kmalloc(pm.len, GFP_TEMPORARY);
+   pm.len = (PAGEMAP_WALK_SIZE >> PAGE_SHIFT);
+   pm.buffer = kmalloc(pm.len * PM_ENTRY_BYTES, GFP_TEMPORARY);
ret = -ENOMEM;
if (!pm.buffer)
goto out_task;
-- 
1.8.1.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 112/133] Btrfs: release both paths before logging dir/changed extents

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Josef Bacik 

commit f3b15ccdbb9a79781578249a63318805e55a6c34 upstream.

The ceph guys tripped over this bug where we were still holding onto the
original path that we used to copy the inode with when logging.  This is based
on Chris's fix which was reported to fix the problem.  We need to drop the paths
in two cases anyway so just move the drop up so that we don't have duplicate
code.  Thanks,

Signed-off-by: Josef Bacik 
Signed-off-by: Chris Mason 
Signed-off-by: Kamal Mostafa 
---
 fs/btrfs/tree-log.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 8a00e2f..372a7d4 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -3684,8 +3684,9 @@ next_slot:
}
 
 log_extents:
+   btrfs_release_path(path);
+   btrfs_release_path(dst_path);
if (fast_search) {
-   btrfs_release_path(dst_path);
ret = btrfs_log_changed_extents(trans, root, inode, dst_path);
if (ret) {
err = ret;
@@ -3702,8 +3703,6 @@ log_extents:
}
 
if (inode_only == LOG_INODE_ALL && S_ISDIR(inode->i_mode)) {
-   btrfs_release_path(path);
-   btrfs_release_path(dst_path);
ret = log_directory_changes(trans, root, inode, path, dst_path);
if (ret) {
err = ret;
-- 
1.8.1.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 116/133] cifs: don't instantiate new dentries in readdir for inodes that need to be revalidated immediately

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Jeff Layton 

commit 757c4f6260febff982276818bb946df89c1105aa upstream.

David reported that commit c2b93e06 (cifs: only set ops for inodes in
I_NEW state) caused a regression with mfsymlinks. Prior to that patch,
if a mfsymlink dentry was instantiated at readdir time, the inode would
get a new set of ops when it was revalidated. After that patch, this
did not occur.

This patch addresses this by simply skipping instantiating dentries in
the readdir codepath when we know that they will need to be immediately
revalidated. The next attempt to use that dentry will cause a new lookup
to occur (which is basically what we want to happen anyway).

Cc: "Stefan (metze) Metzmacher" 
Cc: Sachin Prabhu 
Reported-and-Tested-by: David McBride 
Signed-off-by: Jeff Layton 
Signed-off-by: Steve French 
Signed-off-by: Kamal Mostafa 
---
 fs/cifs/readdir.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/fs/cifs/readdir.c b/fs/cifs/readdir.c
index cdd6ff4..5e636a8 100644
--- a/fs/cifs/readdir.c
+++ b/fs/cifs/readdir.c
@@ -113,6 +113,14 @@ cifs_prime_dcache(struct dentry *parent, struct qstr *name,
return;
}
 
+   /*
+* If we know that the inode will need to be revalidated immediately,
+* then don't create a new dentry for it. We'll end up doing an on
+* the wire call either way and this spares us an invalidation.
+*/
+   if (fattr->cf_flags & CIFS_FATTR_NEED_REVAL)
+   return;
+
dentry = d_alloc(parent, name);
if (!dentry)
return;
-- 
1.8.1.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 125/133] ipv6: take rtnl_lock and mark mrt6 table as freed on namespace cleanup

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Hannes Frederic Sowa 

[ Upstream commit 905a6f96a1b18e490a75f810d733ced93c39b0e5 ]

Otherwise we end up dereferencing the already freed net->ipv6.mrt pointer
which leads to a panic (from Srivatsa S. Bhat):

BUG: unable to handle kernel paging request at 882018552020
IP: [] ip6mr_sk_done+0x32/0xb0 [ipv6]
PGD 290a067 PUD 207ffe0067 PMD 207ff1d067 PTE 802018552060
Oops:  [#1] SMP DEBUG_PAGEALLOC
Modules linked in: ebtable_nat ebtables nfs fscache nf_conntrack_ipv4 
nf_defrag_ipv4 ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter ip_tables 
nfsd lockd nfs_acl exportfs auth_rpcgss autofs4 sunrpc 8021q garp bridge stp 
llc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack 
ip6table_filter
+ip6_tables ipv6 vfat fat vhost_net macvtap macvlan vhost tun kvm_intel kvm 
uinput iTCO_wdt iTCO_vendor_support cdc_ether usbnet mii microcode i2c_i801 
i2c_core lpc_ich mfd_core shpchp ioatdma dca mlx4_core be2net wmi acpi_cpufreq 
mperf ext4 jbd2 mbcache dm_mirror dm_region_hash dm_log dm_mod
CPU: 0 PID: 7 Comm: kworker/u33:0 Not tainted 3.11.0-rc1-ea45e-a #4
Hardware name: IBM  -[8737R2A]-/00Y2738, BIOS -[B2E120RUS-1.20]- 11/30/2012
Workqueue: netns cleanup_net
task: 8810393641c0 ti: 881039366000 task.ti: 881039366000
RIP: 0010:[]  [] ip6mr_sk_done+0x32/0xb0 
[ipv6]
RSP: 0018:881039367bd8  EFLAGS: 00010286
RAX: 881039367fd8 RBX: 882018552000 RCX: dead00200200
RDX:  RSI: 881039367b68 RDI: 881039367b68
RBP: 881039367bf8 R08: 881039367b68 R09: 
R10:  R11:  R12: 882015a7a040
R13: 882014eb89c0 R14: 8820289e2800 R15: 
FS:  () GS:88103fc0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 882018552020 CR3: 01c0b000 CR4: 000407f0
Stack:
 881039367c18 882014eb89c0 882015e28c00 
 881039367c18 a034d9d1 8820289e2800 882014eb89c0
 881039367c58 815bdecb 815bddf2 882014eb89c0
Call Trace:
 [] rawv6_close+0x21/0x40 [ipv6]
 [] inet_release+0xfb/0x220
 [] ? inet_release+0x22/0x220
 [] inet6_release+0x3f/0x50 [ipv6]
 [] sock_release+0x29/0xa0
 [] sk_release_kernel+0x30/0x70
 [] icmpv6_sk_exit+0x3b/0x80 [ipv6]
 [] ops_exit_list+0x39/0x60
 [] cleanup_net+0xfb/0x1a0
 [] process_one_work+0x1da/0x610
 [] ? process_one_work+0x169/0x610
 [] worker_thread+0x120/0x3a0
 [] ? process_one_work+0x610/0x610
 [] kthread+0xee/0x100
 [] ? __init_kthread_worker+0x70/0x70
 [] ret_from_fork+0x7c/0xb0
 [] ? __init_kthread_worker+0x70/0x70
Code: 20 48 89 5d e8 4c 89 65 f0 4c 89 6d f8 66 66 66 66 90 4c 8b 67 30 49 89 
fd e8 db 3c 1e e1 49 8b 9c 24 90 08 00 00 48 85 db 74 06 <4c> 39 6b 20 74 20 bb 
f3 ff ff ff e8 8e 3c 1e e1 89 d8 4c 8b 65
RIP  [] ip6mr_sk_done+0x32/0xb0 [ipv6]
 RSP 
CR2: 882018552020

Reported-by: Srivatsa S. Bhat 
Tested-by: Srivatsa S. Bhat 
Signed-off-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller 
Signed-off-by: Kamal Mostafa 
---
 net/ipv6/ip6mr.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index 8fd154e..1535096 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -259,10 +259,12 @@ static void __net_exit ip6mr_rules_exit(struct net *net)
 {
struct mr6_table *mrt, *next;
 
+   rtnl_lock();
list_for_each_entry_safe(mrt, next, >ipv6.mr6_tables, list) {
list_del(>list);
ip6mr_free_table(mrt);
}
+   rtnl_unlock();
fib_rules_unregister(net->ipv6.mr6_rules_ops);
 }
 #else
@@ -289,7 +291,10 @@ static int __net_init ip6mr_rules_init(struct net *net)
 
 static void __net_exit ip6mr_rules_exit(struct net *net)
 {
+   rtnl_lock();
ip6mr_free_table(net->ipv6.mrt6);
+   net->ipv6.mrt6 = NULL;
+   rtnl_unlock();
 }
 #endif
 
-- 
1.8.1.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 v3 2/5] fs: Add inode_update_time_writable

[Andy Lutomirski]

This is like file_update_time, except that it acts on a struct inode *
instead of a struct file *.

Signed-off-by: Andy Lutomirski 
---
 fs/inode.c | 72 ++
 include/linux/fs.h |  1 +
 2 files changed, 58 insertions(+), 15 deletions(-)

diff --git a/fs/inode.c b/fs/inode.c
index d6dfb09..bc90c12 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -1637,6 +1637,34 @@ int file_remove_suid(struct file *file)
 }
 EXPORT_SYMBOL(file_remove_suid);
 
+/*
+ * This does the work that's common to file_update_time and
+ * inode_update_time.
+ */
+static int prepare_update_cmtime(struct inode *inode, struct timespec *now)
+{
+   int sync_it;
+
+   /* First try to exhaust all avenues to not sync */
+   if (IS_NOCMTIME(inode))
+   return 0;
+
+   *now = current_fs_time(inode->i_sb);
+   if (!timespec_equal(>i_mtime, now))
+   sync_it = S_MTIME;
+
+   if (!timespec_equal(>i_ctime, now))
+   sync_it |= S_CTIME;
+
+   if (IS_I_VERSION(inode))
+   sync_it |= S_VERSION;
+
+   if (!sync_it)
+   return 0;
+
+   return sync_it;
+}
+
 /**
  * file_update_time-   update mtime and ctime time
  * @file: file accessed
@@ -1654,23 +1682,9 @@ int file_update_time(struct file *file)
 {
struct inode *inode = file_inode(file);
struct timespec now;
-   int sync_it = 0;
+   int sync_it = prepare_update_cmtime(inode, );
int ret;
 
-   /* First try to exhaust all avenues to not sync */
-   if (IS_NOCMTIME(inode))
-   return 0;
-
-   now = current_fs_time(inode->i_sb);
-   if (!timespec_equal(>i_mtime, ))
-   sync_it = S_MTIME;
-
-   if (!timespec_equal(>i_ctime, ))
-   sync_it |= S_CTIME;
-
-   if (IS_I_VERSION(inode))
-   sync_it |= S_VERSION;
-
if (!sync_it)
return 0;
 
@@ -1685,6 +1699,34 @@ int file_update_time(struct file *file)
 }
 EXPORT_SYMBOL(file_update_time);
 
+/**
+ * inode_update_time_writable  -   update mtime and ctime time
+ * @inode: inode accessed
+ *
+ * This is like file_update_time, but it assumes the mnt is writable
+ * and takes an inode parameter instead.  (We need to assume the mnt
+ * was writable because inodes aren't associated with any particular
+ * mnt.
+ */
+
+int inode_update_time_writable(struct inode *inode)
+{
+   struct timespec now;
+   int sync_it = prepare_update_cmtime(inode, );
+   int ret;
+
+   if (!sync_it)
+   return 0;
+
+   /* sb_start_pagefault and update_time can both sleep. */
+   sb_start_pagefault(inode->i_sb);
+   ret = update_time(inode, , sync_it);
+   sb_end_pagefault(inode->i_sb);
+
+   return ret;
+}
+EXPORT_SYMBOL(inode_update_time_writable);
+
 int inode_needs_sync(struct inode *inode)
 {
if (IS_SYNC(inode))
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 9818747..86cf0a4 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2590,6 +2590,7 @@ extern int inode_newsize_ok(const struct inode *, loff_t 
offset);
 extern void setattr_copy(struct inode *inode, const struct iattr *attr);
 
 extern int file_update_time(struct file *file);
+extern int inode_update_time_writable(struct inode *inode);
 
 extern int generic_show_options(struct seq_file *m, struct dentry *root);
 extern void save_mount_options(struct super_block *sb, char *options);
-- 
1.8.3.1

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

[PATCH 107/133] ALSA: 6fire: fix DMA issues with URB transfer_buffer usage

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Jussi Kivilinna 

commit ddb6b5a964371e8e52e696b2b258bda144c8bd3f upstream.

Patch fixes 6fire not to use stack as URB transfer_buffer. URB buffers need to
be DMA-able, which stack is not. Furthermore, transfer_buffer should not be
allocated as part of larger device structure because DMA coherency issues and
patch fixes this issue too.

Signed-off-by: Jussi Kivilinna 
Tested-by: Torsten Schenk 
Signed-off-by: Takashi Iwai 
Signed-off-by: Kamal Mostafa 
---
 sound/usb/6fire/comm.c | 38 +-
 sound/usb/6fire/comm.h |  2 +-
 2 files changed, 34 insertions(+), 6 deletions(-)

diff --git a/sound/usb/6fire/comm.c b/sound/usb/6fire/comm.c
index 9e6e3ff..23452ee 100644
--- a/sound/usb/6fire/comm.c
+++ b/sound/usb/6fire/comm.c
@@ -110,19 +110,37 @@ static int usb6fire_comm_send_buffer(u8 *buffer, struct 
usb_device *dev)
 static int usb6fire_comm_write8(struct comm_runtime *rt, u8 request,
u8 reg, u8 value)
 {
-   u8 buffer[13]; /* 13: maximum length of message */
+   u8 *buffer;
+   int ret;
+
+   /* 13: maximum length of message */
+   buffer = kmalloc(13, GFP_KERNEL);
+   if (!buffer)
+   return -ENOMEM;
 
usb6fire_comm_init_buffer(buffer, 0x00, request, reg, value, 0x00);
-   return usb6fire_comm_send_buffer(buffer, rt->chip->dev);
+   ret = usb6fire_comm_send_buffer(buffer, rt->chip->dev);
+
+   kfree(buffer);
+   return ret;
 }
 
 static int usb6fire_comm_write16(struct comm_runtime *rt, u8 request,
u8 reg, u8 vl, u8 vh)
 {
-   u8 buffer[13]; /* 13: maximum length of message */
+   u8 *buffer;
+   int ret;
+
+   /* 13: maximum length of message */
+   buffer = kmalloc(13, GFP_KERNEL);
+   if (!buffer)
+   return -ENOMEM;
 
usb6fire_comm_init_buffer(buffer, 0x00, request, reg, vl, vh);
-   return usb6fire_comm_send_buffer(buffer, rt->chip->dev);
+   ret = usb6fire_comm_send_buffer(buffer, rt->chip->dev);
+
+   kfree(buffer);
+   return ret;
 }
 
 int usb6fire_comm_init(struct sfire_chip *chip)
@@ -135,6 +153,12 @@ int usb6fire_comm_init(struct sfire_chip *chip)
if (!rt)
return -ENOMEM;
 
+   rt->receiver_buffer = kzalloc(COMM_RECEIVER_BUFSIZE, GFP_KERNEL);
+   if (!rt->receiver_buffer) {
+   kfree(rt);
+   return -ENOMEM;
+   }
+
urb = >receiver;
rt->serial = 1;
rt->chip = chip;
@@ -153,6 +177,7 @@ int usb6fire_comm_init(struct sfire_chip *chip)
urb->interval = 1;
ret = usb_submit_urb(urb, GFP_KERNEL);
if (ret < 0) {
+   kfree(rt->receiver_buffer);
kfree(rt);
snd_printk(KERN_ERR PREFIX "cannot create comm data receiver.");
return ret;
@@ -171,6 +196,9 @@ void usb6fire_comm_abort(struct sfire_chip *chip)
 
 void usb6fire_comm_destroy(struct sfire_chip *chip)
 {
-   kfree(chip->comm);
+   struct comm_runtime *rt = chip->comm;
+
+   kfree(rt->receiver_buffer);
+   kfree(rt);
chip->comm = NULL;
 }
diff --git a/sound/usb/6fire/comm.h b/sound/usb/6fire/comm.h
index 6a0840b..780d5ed 100644
--- a/sound/usb/6fire/comm.h
+++ b/sound/usb/6fire/comm.h
@@ -24,7 +24,7 @@ struct comm_runtime {
struct sfire_chip *chip;
 
struct urb receiver;
-   u8 receiver_buffer[COMM_RECEIVER_BUFSIZE];
+   u8 *receiver_buffer;
 
u8 serial; /* urb serial */
 
-- 
1.8.1.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-v3 4/4] vhost/scsi: Add pre-allocation for tv_cmd SGL + upages memory

[Nicholas A. Bellinger]

From: Nicholas Bellinger 

This patch adds support for pre-allocation of per tv_cmd descriptor
scatterlist + user-space page pointer memory using se_sess->sess_cmd_map
within tcm_vhost_make_nexus() code.

This includes sanity checks within vhost_scsi_map_to_sgl()
to reject I/O that exceeds these initial hardcoded values, and
the necessary cleanup in tcm_vhost_make_nexus() failure path +
tcm_vhost_drop_nexus().

v3 changes:
  - Rebase to v3.11-rc5 code

Cc: Michael S. Tsirkin 
Cc: Asias He 
Cc: Kent Overstreet 
Signed-off-by: Nicholas Bellinger 
---
 drivers/vhost/scsi.c |   99 --
 1 file changed, 80 insertions(+), 19 deletions(-)

diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index af178b7..8e8788e 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -56,6 +56,8 @@
 #define TCM_VHOST_NAMELEN 256
 #define TCM_VHOST_MAX_CDB_SIZE 32
 #define TCM_VHOST_DEFAULT_TAGS 256
+#define TCM_VHOST_PREALLOC_SGLS 2048
+#define TCM_VHOST_PREALLOC_PAGES 2048
 
 struct vhost_scsi_inflight {
/* Wait for the flush operation to finish */
@@ -81,6 +83,7 @@ struct tcm_vhost_cmd {
u32 tvc_lun;
/* Pointer to the SGL formatted memory from virtio-scsi */
struct scatterlist *tvc_sgl;
+   struct page **tvc_upages;
/* Pointer to response */
struct virtio_scsi_cmd_resp __user *tvc_resp;
/* Pointer to vhost_scsi for our device */
@@ -458,8 +461,6 @@ static void tcm_vhost_release_cmd(struct se_cmd *se_cmd)
u32 i;
for (i = 0; i < tv_cmd->tvc_sgl_count; i++)
put_page(sg_page(_cmd->tvc_sgl[i]));
-
-   kfree(tv_cmd->tvc_sgl);
 }
 
tcm_vhost_put_inflight(tv_cmd->inflight);
@@ -716,6 +717,8 @@ vhost_scsi_get_tag(struct vhost_virtqueue *vq,
struct tcm_vhost_cmd *cmd;
struct tcm_vhost_nexus *tv_nexus;
struct se_session *se_sess;
+   struct scatterlist *sg;
+   struct page **pages;
int tag;
 
tv_nexus = tpg->tpg_nexus;
@@ -727,8 +730,12 @@ vhost_scsi_get_tag(struct vhost_virtqueue *vq,
 
tag = percpu_ida_alloc(_sess->sess_tag_pool, GFP_KERNEL);
cmd = &((struct tcm_vhost_cmd *)se_sess->sess_cmd_map)[tag];
+   sg = cmd->tvc_sgl;
+   pages = cmd->tvc_upages;
memset(cmd, 0, sizeof(struct tcm_vhost_cmd));
 
+   cmd->tvc_sgl = sg;
+   cmd->tvc_upages = pages;
cmd->tvc_se_cmd.map_tag = tag;
cmd->tvc_tag = v_req->tag;
cmd->tvc_task_attr = v_req->task_attr;
@@ -746,7 +753,8 @@ vhost_scsi_get_tag(struct vhost_virtqueue *vq,
  * Returns the number of scatterlist entries used or -errno on error.
  */
 static int
-vhost_scsi_map_to_sgl(struct scatterlist *sgl,
+vhost_scsi_map_to_sgl(struct tcm_vhost_cmd *tv_cmd,
+ struct scatterlist *sgl,
  unsigned int sgl_count,
  struct iovec *iov,
  int write)
@@ -758,13 +766,25 @@ vhost_scsi_map_to_sgl(struct scatterlist *sgl,
struct page **pages;
int ret, i;
 
+   if (sgl_count > TCM_VHOST_PREALLOC_SGLS) {
+   pr_err("vhost_scsi_map_to_sgl() psgl_count: %u greater than"
+  " preallocated TCM_VHOST_PREALLOC_SGLS: %u\n",
+   sgl_count, TCM_VHOST_PREALLOC_SGLS);
+   return -ENOBUFS;
+   }
+
pages_nr = iov_num_pages(iov);
if (pages_nr > sgl_count)
return -ENOBUFS;
 
-   pages = kmalloc(pages_nr * sizeof(struct page *), GFP_KERNEL);
-   if (!pages)
-   return -ENOMEM;
+   if (pages_nr > TCM_VHOST_PREALLOC_PAGES) {
+   pr_err("vhost_scsi_map_to_sgl() pages_nr: %u greater than"
+  " preallocated TCM_VHOST_PREALLOC_PAGES: %u\n",
+   pages_nr, TCM_VHOST_PREALLOC_PAGES);
+   return -ENOBUFS;
+   }
+
+   pages = tv_cmd->tvc_upages;
 
ret = get_user_pages_fast((unsigned long)ptr, pages_nr, write, pages);
/* No pages were pinned */
@@ -789,7 +809,6 @@ vhost_scsi_map_to_sgl(struct scatterlist *sgl,
}
 
 out:
-   kfree(pages);
return ret;
 }
 
@@ -813,24 +832,20 @@ vhost_scsi_map_iov_to_sgl(struct tcm_vhost_cmd *cmd,
 
/* TODO overflow checking */
 
-   sg = kmalloc(sizeof(cmd->tvc_sgl[0]) * sgl_count, GFP_ATOMIC);
-   if (!sg)
-   return -ENOMEM;
-   pr_debug("%s sg %p sgl_count %u is_err %d\n", __func__,
-  sg, sgl_count, !sg);
+   sg = cmd->tvc_sgl;
+   pr_debug("%s sg %p sgl_count %u\n", __func__, sg, sgl_count);
sg_init_table(sg, sgl_count);
 
-   cmd->tvc_sgl = sg;
cmd->tvc_sgl_count = sgl_count;
 
pr_debug("Mapping %u iovecs for %u pages\n", niov, sgl_count);
for (i = 0; i < niov; i++) {
-   ret = vhost_scsi_map_to_sgl(sg, sgl_count, [i], write);
+   ret = 

[PATCH 113/133] sched: Ensure update_cfs_shares() is called for parents of continuously-running tasks

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Peter Zijlstra 

commit bf0bd948d1682e3996adc093b43021ed391983e6 upstream.

We typically update a task_group's shares within the dequeue/enqueue
path.  However, continuously running tasks sharing a CPU are not
subject to these updates as they are only put/picked.  Unfortunately,
when we reverted f269ae046 (in 17bc14b7), we lost the augmenting
periodic update that was supposed to account for this; resulting in a
potential loss of fairness.

To fix this, re-introduce the explicit update in
update_cfs_rq_blocked_load() [called via entity_tick()].

Reported-by: Max Hailperin 
Signed-off-by: Peter Zijlstra 
Reviewed-by: Paul Turner 
Link: http://lkml.kernel.org/n/tip-9545m3apw5d93ubyrotrj...@git.kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Kamal Mostafa 
---
 kernel/sched/fair.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 81fa536..7d0374f 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1964,6 +1964,7 @@ entity_tick(struct cfs_rq *cfs_rq, struct sched_entity 
*curr, int queued)
 */
update_entity_load_avg(curr, 1);
update_cfs_rq_blocked_load(cfs_rq, 1);
+   update_cfs_shares(cfs_rq);
 
 #ifdef CONFIG_SCHED_HRTICK
/*
-- 
1.8.1.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 121/133] x86 get_unmapped_area(): use proper mmap base for bottom-up direction

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Radu Caragea 

commit df54d6fa54275ce59660453e29d1228c2b45a826 upstream.

When the stack is set to unlimited, the bottomup direction is used for
mmap-ings but the mmap_base is not used and thus effectively renders
ASLR for mmapings along with PIE useless.

Cc: Michel Lespinasse 
Cc: Oleg Nesterov 
Reviewed-by: Rik van Riel 
Acked-by: Ingo Molnar 
Cc: Adrian Sendroiu 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Kamal Mostafa 
---
 arch/x86/kernel/sys_x86_64.c | 2 +-
 arch/x86/mm/mmap.c   | 2 +-
 include/linux/sched.h| 1 +
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/sys_x86_64.c b/arch/x86/kernel/sys_x86_64.c
index 97ef74b..af46e18 100644
--- a/arch/x86/kernel/sys_x86_64.c
+++ b/arch/x86/kernel/sys_x86_64.c
@@ -101,7 +101,7 @@ static void find_start_end(unsigned long flags, unsigned 
long *begin,
*begin = new_begin;
}
} else {
-   *begin = TASK_UNMAPPED_BASE;
+   *begin = mmap_legacy_base();
*end = TASK_SIZE;
}
 }
diff --git a/arch/x86/mm/mmap.c b/arch/x86/mm/mmap.c
index 845df68..c1af323 100644
--- a/arch/x86/mm/mmap.c
+++ b/arch/x86/mm/mmap.c
@@ -98,7 +98,7 @@ static unsigned long mmap_base(void)
  * Bottom-up (legacy) layout on X86_32 did not support randomization, X86_64
  * does, but not when emulating X86_32
  */
-static unsigned long mmap_legacy_base(void)
+unsigned long mmap_legacy_base(void)
 {
if (mmap_is_ia32())
return TASK_UNMAPPED_BASE;
diff --git a/include/linux/sched.h b/include/linux/sched.h
index caa76ae..9d96429 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -360,6 +360,7 @@ extern int sysctl_max_map_count;
 #include 
 
 #ifdef CONFIG_MMU
+extern unsigned long mmap_legacy_base(void);
 extern void arch_pick_mmap_layout(struct mm_struct *mm);
 extern unsigned long
 arch_get_unmapped_area(struct file *, unsigned long, unsigned long,
-- 
1.8.1.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: page fault scalability (ext3, ext4, xfs)

[Andy Lutomirski]

On Fri, Aug 16, 2013 at 3:02 PM, J. Bruce Fields  wrote:
> On Fri, Aug 16, 2013 at 07:37:25AM +1000, Dave Chinner wrote:
>> On Thu, Aug 15, 2013 at 08:17:18AM -0700, Andy Lutomirski wrote:
>> > On Thu, Aug 15, 2013 at 12:11 AM, Dave Chinner  wrote:
>> > > On Wed, Aug 14, 2013 at 11:14:37PM -0700, Andy Lutomirski wrote:
>> > >> On Wed, Aug 14, 2013 at 11:01 PM, Dave Chinner  
>> > >> wrote:
>> > >> > On Wed, Aug 14, 2013 at 09:32:13PM -0700, Andy Lutomirski wrote:
>> > >> >> On Wed, Aug 14, 2013 at 7:10 PM, Dave Chinner  
>> > >> >> wrote:
>> > >> >> > On Wed, Aug 14, 2013 at 09:11:01PM -0400, Theodore Ts'o wrote:
>> > >> >> >> On Wed, Aug 14, 2013 at 04:38:12PM -0700, Andy Lutomirski wrote:
>> > >> >> >> > > It would be better to write zeros to it, so we aren't 
>> > >> >> >> > > measuring the
>> > >> >> >> > > cost of the unwritten->written conversion.
>> > >> >> >> >
>> > >> >> >> > At the risk of beating a dead horse, how hard would it be to 
>> > >> >> >> > defer
>> > >> >> >> > this part until writeback?
>> > >> >> >>
>> > >> >> >> Part of the work has to be done at write time because we need to
>> > >> >> >> update allocation statistics (i.e., so that we don't have ENOSPC
>> > >> >> >> problems).  The unwritten->written conversion does happen at 
>> > >> >> >> writeback
>> > >> >> >> (as does the actual block allocation if we are doing delayed
>> > >> >> >> allocation).
>> > >> >> >>
>> > >> >> >> The point is that if the goal is to measure page fault 
>> > >> >> >> scalability, we
>> > >> >> >> shouldn't have this other stuff happening as the same time as the 
>> > >> >> >> page
>> > >> >> >> fault workload.
>> > >> >> >
>> > >> >> > Sure, but the real problem is not the block mapping or allocation
>> > >> >> > path - even if the test is changed to take that out of the picture,
>> > >> >> > we still have timestamp updates being done on every single page
>> > >> >> > fault. ext4, XFS and btrfs all do transactional timestamp updates
>> > >> >> > and have nanosecond granularity, so every page fault is resulting 
>> > >> >> > in
>> > >> >> > a transaction to update the timestamp of the file being modified.
>> > >> >>
>> > >> >> I have (unmergeable) patches to fix this:
>> > >> >>
>> > >> >> http://comments.gmane.org/gmane.linux.kernel.mm/92476
>> > >> >
>> > >> > The big problem with this approach is that not doing the
>> > >> > timestamp update on page faults is going to break the inode change
>> > >> > version counting because for ext4, btrfs and XFS it takes a
>> > >> > transaction to bump that counter. NFS needs to know the moment a
>> > >> > file is changed in memory, not when it is written to disk. Also, NFS
>> > >> > requires the change to the counter to be persistent over server
>> > >> > failures, so it needs to be changed as part of a transaction
>> > >>
>> > >> I've been running a kernel that has the file_update_time call
>> > >> commented out for over a year now, and the only problem I've seen is
>> > >> that the timestamp doesn't get updated :)
>> > >>
>> >
>> > [...]
>> >
>> > > If a filesystem is providing an i_version value, then NFS uses it to
>> > > determine whether client side caches are still consistent with the
>> > > server state. If the filesystem does not provide an i_version, then
>> > > NFS falls back to checking c/mtime for changes. If files on the
>> > > server are being modified without either the tiemstamps or i_version
>> > > changing, then it's likely that there will be problems with client
>> > > side cache consistency
>> >
>> > I didn't think of that at all.
>> >
>> > If userspace does:
>> >
>> > ptr = mmap(...);
>> > ptr[0] = 1;
>> > sleep(1);
>> > ptr[0] = 2;
>> > sleep(1);
>> > munmap();
>> >
>> > Then current kernels will mark the inode changed on (only) the ptr[0]
>> > = 1 line.  My patches will instead mark the inode changed when munmap
>> > is called (or after ptr[0] = 2 if writepages gets called for any
>> > reason).
>> >
>> > I'm not sure which is better.  POSIX actually requires my behavior
>> > (which is most irrelevant).
>>
>> Not by my reading of it. Posix states that c/mtime needs to be
>> updated between the first access and the next msync() call. We
>> update mtime on the first access, and so therefore we conform to the
>> posix requirement
>>
>> > My behavior also means that, if an NFS
>> > client reads and caches the file between the two writes, then it will
>> > eventually find out that the data is stale.
>>
>> "eventually" is very different behaviour to the current behaviour.
>>
>> My understanding is that NFS v4 delegations require the underlying
>> filesystem to bump the version count on *any* modification made to
>> the file so that delegations can be recalled appropriately.
>
> Delegations at least shouldn't be an issue here: they're recalled on the
> open.

Can you translate that into clueless-non-NFS-expert? :)

Anyway, I'm sending patches in a sec.  Dave (Hansen), want to test?  I
played with will-it-scale a bit, but I don't 

Hello dear

[blessingzamba...@adinet.com.uy]

Hello dear
How are you today I hope all is well with you, my name is 
miss blessing zamba 24 years old girl is my pleasure to contact you after
 viewing your profile  which really interest me to communicating with 
you please if you have the desire with me so we can get to know each 
other better and see what happens in the future?. I'll be very glad if 
you could send me mail back to my personal e-mail for more easy 
communication and to know more about each other.i will tell you why i 
make this contact with you in my next email and i will send you my 
picture when I receive your response, i am waiting to hear from you, and
 I wish you all the best on your life. thank you and have a nice day
miss blessing
--
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 0/4] target/vhost-scsi: Add per-cpu ida tag pre-allocation for v3.12

[Nicholas A. Bellinger]

From: Nicholas Bellinger 

Hi folks,

This is an updated series for adding tag pre-allocation support of
target fabric descriptor memory, utilizing Kent's latest per-cpu ida
bits here, along with Christoph Lameter's latest comments:

   [PATCH 04/10] idr: Percpu ida
   http://marc.info/?l=linux-kernel=137160026006974=2

The first patch is a standalone version of per-cpu-ida, seperate from
the full idr rewrite from Kent that is still being discussed.  Given
that I have a number of other target items aside from this series that
depend on this code, I'd like to go ahead and include this standalone
version into target-pending/for-next as a v3.12 item.

Jens has also expressed interest in a blk-mq conversion to use these
per-cpu-ida primatives, so getting this piece merged for v3.12 would
make life easier for both of us.  ;)

The second patch includes target-core setup of se_sess->sess_cmd_map +
se_sess->sess_tag_pool resources at session creation time, using
fabric independent code in transport_init_session_tags().

The third patch is the initial conversion of vhost-scsi fabric code
to use per-cpu ida logic for obtaining a new tcm_vhost_cmd descriptor
via vhost_scsi_get_tag() during vhost_work_fn_t->handle_kick() ->
vhost_scsi_handle_vq() callback execution.

And the forth patch is a vhost-scsi change that adds pre-allocation of
per tcm_vhost_cmd descriptor scatterlist + user-space page pointer
memory, that allows the last two fast-path allocations to be dropped
from tcm_vhost_submission_work() -> vhost_scsi_map_to_sgl() fast-path
execution.

Please review as v3.12 material.

Thanks!

--nab

Kent Overstreet (1):
  idr: Percpu ida

Nicholas Bellinger (3):
  target: Add transport_init_session_tags using per-cpu ida
  vhost/scsi: Convert to per-cpu ida_alloc + ida_free command map
  vhost/scsi: Add pre-allocation for tv_cmd SGL + upages memory

 drivers/target/target_core_transport.c |   33 
 drivers/vhost/scsi.c   |  132 +
 include/linux/idr.h|   53 ++
 include/target/target_core_base.h  |5 +
 include/target/target_core_fabric.h|1 +
 lib/idr.c  |  316 +++-
 6 files changed, 501 insertions(+), 39 deletions(-)

-- 
1.7.10.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 1/4] idr: Percpu ida

[Nicholas A. Bellinger]

From: Kent Overstreet 

Percpu frontend for allocating ids. With percpu allocation (that works),
it's impossible to guarantee it will always be possible to allocate all
nr_tags - typically, some will be stuck on a remote percpu freelist
where the current job can't get to them.

We do guarantee that it will always be possible to allocate at least
(nr_tags / 2) tags - this is done by keeping track of which and how many
cpus have tags on their percpu freelists. On allocation failure if
enough cpus have tags that there could potentially be (nr_tags / 2) tags
stuck on remote percpu freelists, we then pick a remote cpu at random to
steal from.

Note that there's no cpu hotplug notifier - we don't care, because
steal_tags() will eventually get the down cpu's tags. We _could_ satisfy
more allocations if we had a notifier - but we'll still meet our
guarantees and it's absolutely not a correctness issue, so I don't think
it's worth the extra code.

Signed-off-by: Kent Overstreet 
Cc: Tejun Heo 
Cc: Oleg Nesterov 
Cc: Christoph Lameter 
Cc: Ingo Molnar 
Cc: Andi Kleen 
Cc: Jens Axboe 
Cc: "Nicholas A. Bellinger" 
Signed-off-by: Nicholas Bellinger 
---
 include/linux/idr.h |   53 +
 lib/idr.c   |  316 +--
 2 files changed, 361 insertions(+), 8 deletions(-)

diff --git a/include/linux/idr.h b/include/linux/idr.h
index 871a213..f0db12b 100644
--- a/include/linux/idr.h
+++ b/include/linux/idr.h
@@ -16,6 +16,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 /*
  * We want shallower trees and thus more bits covered at each layer.  8
@@ -243,4 +245,55 @@ static inline int ida_get_new(struct ida *ida, int *p_id)
 
 void __init idr_init_cache(void);
 
+/* Percpu IDA/tag allocator */
+
+struct percpu_ida_cpu;
+
+struct percpu_ida {
+   /*
+* number of tags available to be allocated, as passed to
+* percpu_ida_init()
+*/
+   unsignednr_tags;
+
+   struct percpu_ida_cpu __percpu  *tag_cpu;
+
+   /*
+* Bitmap of cpus that (may) have tags on their percpu freelists:
+* steal_tags() uses this to decide when to steal tags, and which cpus
+* to try stealing from.
+*
+* It's ok for a freelist to be empty when its bit is set - steal_tags()
+* will just keep looking - but the bitmap _must_ be set whenever a
+* percpu freelist does have tags.
+*/
+   unsigned long   *cpus_have_tags;
+
+   struct {
+   spinlock_t  lock;
+   /*
+* When we go to steal tags from another cpu (see steal_tags()),
+* we want to pick a cpu at random. Cycling through them every
+* time we steal is a bit easier and more or less equivalent:
+*/
+   unsignedcpu_last_stolen;
+
+   /* For sleeping on allocation failure */
+   wait_queue_head_t   wait;
+
+   /*
+* Global freelist - it's a stack where nr_free points to the
+* top
+*/
+   unsignednr_free;
+   unsigned*freelist;
+   } cacheline_aligned_in_smp;
+};
+
+int percpu_ida_alloc(struct percpu_ida *pool, gfp_t gfp);
+void percpu_ida_free(struct percpu_ida *pool, unsigned tag);
+
+void percpu_ida_destroy(struct percpu_ida *pool);
+int percpu_ida_init(struct percpu_ida *pool, unsigned long nr_tags);
+
 #endif /* __IDR_H__ */
diff --git a/lib/idr.c b/lib/idr.c
index bfe4db4..57bfabe 100644
--- a/lib/idr.c
+++ b/lib/idr.c
@@ -26,17 +26,20 @@
  * with the slab allocator.
  */
 
-#ifndef TEST// to test in user space...
-#include 
-#include 
-#include 
-#endif
+#include 
+#include 
+#include 
 #include 
-#include 
+#include 
+#include 
 #include 
-#include 
+#include 
+#include 
 #include 
-#include 
+#include 
+#include 
+#include 
+#include 
 
 #define MAX_IDR_SHIFT  (sizeof(int) * 8 - 1)
 #define MAX_IDR_BIT(1U << MAX_IDR_SHIFT)
@@ -1159,3 +1162,300 @@ void ida_init(struct ida *ida)
 
 }
 EXPORT_SYMBOL(ida_init);
+
+/* Percpu IDA */
+
+/*
+ * Number of tags we move between the percpu freelist and the global freelist 
at
+ * a time
+ */
+#define IDA_PCPU_BATCH_MOVE32U
+
+/* Max size of percpu freelist, */
+#define IDA_PCPU_SIZE  ((IDA_PCPU_BATCH_MOVE * 3) / 2)
+
+struct percpu_ida_cpu {
+   spinlock_t  lock;
+   unsignednr_free;
+   unsignedfreelist[];
+};
+
+static inline void move_tags(unsigned *dst, unsigned *dst_nr,
+unsigned *src, unsigned *src_nr,
+unsigned nr)
+{
+   *src_nr -= nr;
+   memcpy(dst + *dst_nr, src + *src_nr, sizeof(unsigned) * nr);
+   *dst_nr += nr;
+}
+
+/*
+ * Try to steal tags from a remote cpu's 

[PATCH-v3 2/4] target: Add transport_init_session_tags using per-cpu ida

[Nicholas A. Bellinger]

From: Nicholas Bellinger 

This patch adds lib/idr.c based transport_init_session_tags() logic
that allows fabric drivers to setup a per-cpu se_sess->sess_tag_pool
and associated se_sess->sess_cmd_map for basic tagged pre-allocation
of fabric descriptor sized memory.

v3: Update to percpu-ida usage

Cc: Kent Overstreet 
Cc: Asias He 
Cc: Michael S. Tsirkin 
Signed-off-by: Nicholas Bellinger 
---
 drivers/target/target_core_transport.c |   33 
 include/target/target_core_base.h  |5 +
 include/target/target_core_fabric.h|1 +
 3 files changed, 39 insertions(+)

diff --git a/drivers/target/target_core_transport.c 
b/drivers/target/target_core_transport.c
index 7172d00..64ceb51 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -232,6 +232,35 @@ struct se_session *transport_init_session(void)
 }
 EXPORT_SYMBOL(transport_init_session);
 
+struct se_session *transport_init_session_tags(unsigned int tag_num,
+  unsigned int tag_size)
+{
+   struct se_session *se_sess;
+   int rc;
+
+   se_sess = transport_init_session();
+   if (IS_ERR(se_sess))
+   return se_sess;
+
+   se_sess->sess_cmd_map = kzalloc(tag_num * tag_size, GFP_KERNEL);
+   if (!se_sess->sess_cmd_map) {
+   pr_err("Unable to allocate se_sess->sess_cmd_map\n");
+   transport_free_session(se_sess);
+   return ERR_PTR(-ENOMEM);
+   }
+
+   rc = percpu_ida_init(_sess->sess_tag_pool, tag_num);
+   if (rc < 0) {
+   pr_err("Unable to init se_sess->sess_tag_pool,"
+   " tag_num: %u\n", tag_num);
+   transport_free_session(se_sess);
+   return ERR_PTR(-ENOMEM);
+   }
+
+   return se_sess;
+}
+EXPORT_SYMBOL(transport_init_session_tags);
+
 /*
  * Called with spin_lock_irqsave( se_portal_group->session_lock called.
  */
@@ -367,6 +396,10 @@ EXPORT_SYMBOL(transport_deregister_session_configfs);
 
 void transport_free_session(struct se_session *se_sess)
 {
+   if (se_sess->sess_cmd_map) {
+   percpu_ida_destroy(_sess->sess_tag_pool);
+   kfree(se_sess->sess_cmd_map);
+   }
kmem_cache_free(se_sess_cache, se_sess);
 }
 EXPORT_SYMBOL(transport_free_session);
diff --git a/include/target/target_core_base.h 
b/include/target/target_core_base.h
index e34fc90..360e4a3 100644
--- a/include/target/target_core_base.h
+++ b/include/target/target_core_base.h
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -415,6 +416,8 @@ struct se_cmd {
enum dma_data_direction data_direction;
/* For SAM Task Attribute */
int sam_task_attr;
+   /* Used for se_sess->sess_tag_pool */
+   unsigned intmap_tag;
/* Transport protocol dependent state, see transport_state_table */
enum transport_state_table t_state;
unsignedcmd_wait_set:1;
@@ -536,6 +539,8 @@ struct se_session {
struct list_headsess_wait_list;
spinlock_t  sess_cmd_lock;
struct kref sess_kref;
+   void*sess_cmd_map;
+   struct percpu_ida   sess_tag_pool;
 };
 
 struct se_device;
diff --git a/include/target/target_core_fabric.h 
b/include/target/target_core_fabric.h
index 7a16178..b13afb6 100644
--- a/include/target/target_core_fabric.h
+++ b/include/target/target_core_fabric.h
@@ -84,6 +84,7 @@ struct target_core_fabric_ops {
 };
 
 struct se_session *transport_init_session(void);
+struct se_session *transport_init_session_tags(unsigned int, unsigned int);
 void   __transport_register_session(struct se_portal_group *,
struct se_node_acl *, struct se_session *, void *);
 void   transport_register_session(struct se_portal_group *,
-- 
1.7.10.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 3/4] vhost/scsi: Convert to per-cpu ida_alloc + ida_free command map

[Nicholas A. Bellinger]

From: Nicholas Bellinger 

This patch changes vhost/scsi to use transport_init_session_tags()
pre-allocation logic for per-cpu session tag pooling with internal
ida_alloc() + ida_free() calls based upon the saved se_cmd->map_tag id.

FIXME: Make transport_init_session_tags() number of tags setup
configurable per vring client setting via configfs

v3 changes:
 - Update to percpu-ida usage
 - Rebase to v3.11-rc5 code

Cc: Michael S. Tsirkin 
Cc: Asias He 
Cc: Kent Overstreet 
Signed-off-by: Nicholas Bellinger 
---
 drivers/vhost/scsi.c |   33 +
 1 file changed, 21 insertions(+), 12 deletions(-)

diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 0c27c7d..af178b7 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -48,12 +48,14 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "vhost.h"
 
 #define TCM_VHOST_VERSION  "v0.1"
 #define TCM_VHOST_NAMELEN 256
 #define TCM_VHOST_MAX_CDB_SIZE 32
+#define TCM_VHOST_DEFAULT_TAGS 256
 
 struct vhost_scsi_inflight {
/* Wait for the flush operation to finish */
@@ -450,6 +452,7 @@ static void tcm_vhost_release_cmd(struct se_cmd *se_cmd)
 {
struct tcm_vhost_cmd *tv_cmd = container_of(se_cmd,
struct tcm_vhost_cmd, tvc_se_cmd);
+   struct se_session *se_sess = se_cmd->se_sess;
 
if (tv_cmd->tvc_sgl_count) {
u32 i;
@@ -460,7 +463,7 @@ static void tcm_vhost_release_cmd(struct se_cmd *se_cmd)
 }
 
tcm_vhost_put_inflight(tv_cmd->inflight);
-   kfree(tv_cmd);
+   percpu_ida_free(_sess->sess_tag_pool, se_cmd->map_tag);
 }
 
 static int tcm_vhost_shutdown_session(struct se_session *se_sess)
@@ -704,7 +707,7 @@ static void vhost_scsi_complete_cmd_work(struct vhost_work 
*work)
 }
 
 static struct tcm_vhost_cmd *
-vhost_scsi_allocate_cmd(struct vhost_virtqueue *vq,
+vhost_scsi_get_tag(struct vhost_virtqueue *vq,
struct tcm_vhost_tpg *tpg,
struct virtio_scsi_cmd_req *v_req,
u32 exp_data_len,
@@ -712,18 +715,21 @@ vhost_scsi_allocate_cmd(struct vhost_virtqueue *vq,
 {
struct tcm_vhost_cmd *cmd;
struct tcm_vhost_nexus *tv_nexus;
+   struct se_session *se_sess;
+   int tag;
 
tv_nexus = tpg->tpg_nexus;
if (!tv_nexus) {
pr_err("Unable to locate active struct tcm_vhost_nexus\n");
return ERR_PTR(-EIO);
}
+   se_sess = tv_nexus->tvn_se_sess;
 
-   cmd = kzalloc(sizeof(struct tcm_vhost_cmd), GFP_ATOMIC);
-   if (!cmd) {
-   pr_err("Unable to allocate struct tcm_vhost_cmd\n");
-   return ERR_PTR(-ENOMEM);
-   }
+   tag = percpu_ida_alloc(_sess->sess_tag_pool, GFP_KERNEL);
+   cmd = &((struct tcm_vhost_cmd *)se_sess->sess_cmd_map)[tag];
+   memset(cmd, 0, sizeof(struct tcm_vhost_cmd));
+
+   cmd->tvc_se_cmd.map_tag = tag;
cmd->tvc_tag = v_req->tag;
cmd->tvc_task_attr = v_req->task_attr;
cmd->tvc_exp_data_len = exp_data_len;
@@ -989,10 +995,10 @@ vhost_scsi_handle_vq(struct vhost_scsi *vs, struct 
vhost_virtqueue *vq)
for (i = 0; i < data_num; i++)
exp_data_len += vq->iov[data_first + i].iov_len;
 
-   cmd = vhost_scsi_allocate_cmd(vq, tpg, _req,
-   exp_data_len, data_direction);
+   cmd = vhost_scsi_get_tag(vq, tpg, _req,
+exp_data_len, data_direction);
if (IS_ERR(cmd)) {
-   vq_err(vq, "vhost_scsi_allocate_cmd failed %ld\n",
+   vq_err(vq, "vhost_scsi_get_tag failed %ld\n",
PTR_ERR(cmd));
goto err_cmd;
}
@@ -1675,9 +1681,12 @@ static int tcm_vhost_make_nexus(struct tcm_vhost_tpg 
*tpg,
return -ENOMEM;
}
/*
-*  Initialize the struct se_session pointer
+*  Initialize the struct se_session pointer and setup tagpool
+*  for struct tcm_vhost_cmd descriptors
 */
-   tv_nexus->tvn_se_sess = transport_init_session();
+   tv_nexus->tvn_se_sess = transport_init_session_tags(
+   TCM_VHOST_DEFAULT_TAGS,
+   sizeof(struct tcm_vhost_cmd));
if (IS_ERR(tv_nexus->tvn_se_sess)) {
mutex_unlock(>tv_tpg_mutex);
kfree(tv_nexus);
-- 
1.7.10.4

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

Re: [RFC][PATCH] drivers: base: dynamic memory block creation

[Seth Jennings]

On Wed, Aug 14, 2013 at 12:40:43PM -0700, Greg Kroah-Hartman wrote:
> On Wed, Aug 14, 2013 at 02:31:45PM -0500, Seth Jennings wrote:
> > Large memory systems (~1TB or more) experience boot delays on the order
> > of minutes due to the initializing the memory configuration part of
> > sysfs at /sys/devices/system/memory/.
> > 
> > ppc64 has a normal memory block size of 256M (however sometimes as low
> > as 16M depending on the system LMB size), and (I think) x86 is 128M.  With
> > 1TB of RAM and a 256M block size, that's 4k memory blocks with 20 sysfs
> > entries per block that's around 80k items that need be created at boot
> > time in sysfs.  Some systems go up to 16TB where the issue is even more
> > severe.
> > 
> > This patch provides a means by which users can prevent the creation of
> > the memory block attributes at boot time, yet still dynamically create
> > them if they are needed.
> > 
> > This patch creates a new boot parameter, "largememory" that will prevent
> > memory_dev_init() from creating all of the memory block sysfs attributes
> > at boot time.  Instead, a new root attribute "show" will allow
> > the dynamic creation of the memory block devices.
> > Another new root attribute "present" shows the memory blocks present in
> > the system; the valid inputs for the "show" attribute.
> 
> Ick, no new boot parameters please, that's just a mess for distros and
> users.

Yes, I agreed it isn't the best.  The reason for it is backward
compatibility; or rather the user saying "I knowingly forfeit backward
compatibility in favor of fast boot time and all my userspace tools are
aware of the new requirement to show memory blocks before trying to use
them".

The only suggestion I heard that would make full backward compatibility
possible is one from Dave to create a new filesystem for memory blocks
(not sysfs) where the memory block directories would be dynamically
created as programs tried to access/open them. But you'd still have the
issue of requiring user intervention to mount that "memoryfs" at
/sys/devices/system/memory (or whatever your sysfs mount point was).

So it's tricky.

> 
> How about tying this into the work that has been happening on lkml with
> booting large-memory systems faster?  The work there should solve the
> problems you are seeing here (i.e. add memory after booting).  It looks
> like this is the same issue you are having here, just in a different
> part of the kernel.

I assume you are referring to the "[RFC v3 0/5] Transparent on-demand
struct page initialization embedded in the buddy allocator" thread.  I
think that trying to solve a different problem than I am trying to solve
though.  IIUC, that patch series is deferring the initialization of the
actually memory pages.

I'm working on breaking out just the refactoring patches (no functional
change) into a reviewable patch series.  Thanks for your time looking at
this!

Seth

--
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/3] ixgbe: request_firmware for configuration parameters

[Ali Ayoub]

On 8/16/2013 3:39 PM, Greg KH wrote:
> On Fri, Aug 16, 2013 at 03:14:31PM -0700, Ali Ayoub wrote:
>> On 1/11/2013 11:41 AM, Greg KH wrote:
> 
> Seriously?  Restarting a thread from over 6 months ago?

Yes, it's an old thread, but still relevant for current code.

> Why?

Because currently there is no good alternative for module params for
device drivers that need to have low level configs in init time.
I found Shannon proposal in this thread the closest to what I am looking
for to configure the device driver and yet not to use module params.
Thus, pinged this thread.

>> Other device drivers of other vendors (not only netdevs) need such a
>> mechanism as well,
> 
> Specifics please.
>
>> I think it's a general requirement for many drivers that normally need
>> low level configurations for device initialization in the very first
>> stage of the driver load.
> 
> I do not, but feel free to prove me otherwise.

A driver that claims the PCI device needs some configuration in init
time such as: amount of resources to be allocated in the cache,
interrupt mode, maximum allowed resources to be created for a specific
type, number of event queues, etc. See for example:
/drivers/net/ethernet/mellanox/mlx4/main.c

This driver doesn't necessary register a logical device, it may claim
the PCI device only (e.g. for an HCA), and provide an infrastructure for
upper layer protocols to register a logical device (nic, hba, etc.) on
top of it.

The type of configuration needed varies between vendors, and they are
normally passed in HW initialization stage. So even if we have a tool to
configure the device (such as ethtool for netdevs) it wouldn't be a
replacement for the module param, because some systems requires
non-default (init) configurations, and if we load the driver with the
default, and then use a user-space tool to "adjust" the configuration
we'll have a "glitch" where the driver was loaded with unsuitable
configs for the system.

>>> All of the above issues you seem to have with sysfs and configfs can be
>>> resolved with userspace code, and having your driver not do anything to
>>> the hardware until it is told to by userspace.
>>
>> To tell the driver not to do anything until it's configured by a
>> userspace code will require a module param for non-default-configs
>> (which brings us back to the original argument of avoiding module params).
> 
> No, never use a module paramater for configuring a driver or a device.
> That's not what they are there for.
>
>> By having userspace code to feed configfs/sysfs nodes, and making it
>> available in initrd; we will end up having similar mechanism to
>> request_firmware().
> 
> Close, but not the same.  That's why we created configfs, please use it.

configfs requires from the driver to provide the hooks before the HW is
initialized, while module params allow passing information to the driver
in init time before any driver hooks are ready.

The proposal of changing the driver not to configure the HW until it's
triggered by userspace service through configfs, means that we need:

a. To have driver config to toggle between the mode where the driver
"waits" for configfs, and the "auto" mode where the driver loads with
the default-configs (when using mod params for example, the driver
simply loads with the defaults when there is modprobe config files).

b. To have the userspace mechanism to feed the configs nodes, to store
the configs in a file to keep them persistent between reboots, and make
these userspace services available in initrd.

I don't see how this is better than module params, or
request_firmware_config().

--
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: Very Urgent!!!

[Doris Omar]

Greetings from BURKINA FASO:
Let me start by introduce myself,I am Mrs Doris Omar, BILL AND EXCHANGE MANAGER 
(Bank of Africa) Ouagadougou, Burkina Faso.I am writting you this letter based 
on the latest development at our bank which I will like to bring to your 
personal edification. $12,250million transfer claims. this is a legitimate 
transaction and I agreed to offer you 40% of this money as my foreign partner 
after confirmation of the fund in your bank account,If you are interested, 
please get back to me.

Yours faithful,
Mrs Doris Omar.
--
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/5] ext4: Defer mmap cmtime update until writeback

[Andy Lutomirski]

A fancier implementation could probably avoid an extra journal
transaction by adding a mapping_test_clear_cmtime call in
ext4_writepages, but this should already be a considerable
improvement -- we'll start one transaction per writepages call
instead of one per page.

Signed-off-by: Andy Lutomirski 
---
 fs/ext4/inode.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index dd32a2e..cee6b45 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -3236,6 +3236,7 @@ static const struct address_space_operations ext4_aops = {
.readpages  = ext4_readpages,
.writepage  = ext4_writepage,
.writepages = ext4_writepages,
+   .flush_cmtime   = generic_flush_cmtime,
.write_begin= ext4_write_begin,
.write_end  = ext4_write_end,
.bmap   = ext4_bmap,
@@ -3252,6 +3253,7 @@ static const struct address_space_operations 
ext4_journalled_aops = {
.readpages  = ext4_readpages,
.writepage  = ext4_writepage,
.writepages = ext4_writepages,
+   .flush_cmtime   = generic_flush_cmtime,
.write_begin= ext4_write_begin,
.write_end  = ext4_journalled_write_end,
.set_page_dirty = ext4_journalled_set_page_dirty,
@@ -3268,6 +3270,7 @@ static const struct address_space_operations ext4_da_aops 
= {
.readpages  = ext4_readpages,
.writepage  = ext4_writepage,
.writepages = ext4_writepages,
+   .flush_cmtime   = generic_flush_cmtime,
.write_begin= ext4_da_write_begin,
.write_end  = ext4_da_write_end,
.bmap   = ext4_bmap,
@@ -5025,7 +5028,6 @@ int ext4_page_mkwrite(struct vm_area_struct *vma, struct 
vm_fault *vmf)
int retries = 0;
 
sb_start_pagefault(inode->i_sb);
-   file_update_time(vma->vm_file);
/* Delalloc case is easy... */
if (test_opt(inode->i_sb, DELALLOC) &&
!ext4_should_journal_data(inode) &&
-- 
1.8.3.1

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

Re: [PATCH v2] RFC: interrupt consistency check for OF GPIO IRQs

[Linus Walleij]

On Thu, Aug 15, 2013 at 11:53 AM, Tomasz Figa  wrote:

>> + /* Check if we have an IRQ parent, else continue */
>> + irq_parent = of_irq_find_parent(child);
>> + if (!irq_parent)
>> + continue;
>
> You can probably put the irq_parent node here to not duplicate calls in
> both code paths below.

But...

>> + /* Is it so that this very GPIO chip is the parent? */
>> + if (irq_parent != gcn) {

I am using it here in this comparison.

>> + of_node_put(irq_parent);
>> + continue;
>> + }
>> + of_node_put(irq_parent);

Then here I put it.

>> + num_irq = of_irq_count(gcn);
>> + for (i = 0; i < num_irq; i++) {
>> + /*
>> +  * The first cell is always the local IRQ number,
> and
>> +  * this corresponds to the GPIO line offset for a
> GPIO
>> +  * chip.
>> +  *
>> +  * FIXME: take interrupt-cells into account here.
>
> This is the biggest problem of this patch. It assumes that there is only a
> single and shared GPIO/interrupt specification scheme, which might not be
> true.
>
> First of all, almost all interrupt bindings have an extra, semi-generic
> flags field as last cell in the specifier. Now there can be more than one
> cell used to index GPIOs and interrupts, for example:
>
> interrupts = <1 3 8>
>
> which could mean: bank 1, pin 3, low level triggered.

You are right, but:
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
Specifies how to handle the one-celled and two-celled versions.

And nothing else is specified. So it's not overly complex.

But we have to read out the #interrupt-cells specifier from the
controller I guess, but since we the gcn pointer we can do this
easily. (I'll fix...)

> I think you may need to reuse a lot of the code that normally parses the
> interrupts property, i.e. the irq_of_parse_and_map() path, which will then
> give you the hwirq index inside your irq chip, which may (or may not) be
> the same as the GPIO offset inside your GPIO chip.

We don't need to map it, and that's the hard part of that code.
We just need to add some code to check the number of
cells.

> If you're unlucky enough to spot a controller that uses completely
> different numbering schemes for GPIOs and interrupts, then you're probably
> screwed, because only the driver for this controller can know the mapping
> between them.

But the binding documents state how this shall be done, as illustrated.
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
Documentation/devicetree/bindings/gpio/gpio.txt

>> + if (ret)
>> + pr_err("gpiolib OF: could not
> request IRQ GPIO %d (%d)\n",
>> +gc->base + offset, offset);
>
> Would some kind of error handling be a bad idea here? Like, for example,
> marking this IRQ as invalid or something among these lines.

Sorry I'm not following. The GPIO core has no clue of how the
driver implements its irqchip and no handle on it so it cannot
go in and mark any interrupts.

>> + ret = gpio_direction_input(gc->base +
> offset);
>> + if (ret)
>> + pr_err("gpiolib OF: could not set
> IRQ GPIO %d (%d) as input\n",
>> +gc->base + offset, offset);
>
> I'm not sure if this is the correct action if someone already requested
> the GPIO before and probably already set it up with their own set of
> parameters (not necessarily the same as enforced by calling
> gpio_direction_input()).

What do you mean with " someone already requested the GPIO
before" here?

This code is run right after the gpiochip is added, noone has a
chance of requesting anything before this happens. This is the
general idea: steal all GPIOs marked to be used as interrupts
so no other consumer can get at them.

>> + } else {
>> + gpio_free(gc->base + offset);
>
> What if the request failed? This would mean calling gpio_free() on a GPIO
> previously requested by someone else.

Noone can request before us, as stated.


>> +#define of_gpiochip_request_irq_lines(np, gc) \
>> + of_gpiochip_x_irq_lines(np, gc, 1)
>> +
>> +#define of_gpiochip_free_irq_lines(np, gc) \
>> + of_gpiochip_x_irq_lines(np, gc, 0)
>
> Aha, so the x is a wildcard. Fine, although it makes the code slightly
> less reader-friendly IMHO.

I renamed it a bit.

Yours,
Linus Walleij
--
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 118/133] ext4: fix mount/remount error messages for incompatible mount options

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Piotr Sarna 

commit 6ae6514b33f941d3386da0dfbe2942766eab1577 upstream.

Commit 5688978 ("ext4: improve handling of conflicting mount options")
introduced incorrect messages shown while choosing wrong mount options.

First of all, both cases of incorrect mount options,
"data=journal,delalloc" and "data=journal,dioread_nolock" result in
the same error message.

Secondly, the problem above isn't solved for remount option: the
mismatched parameter is simply ignored.  Moreover, ext4_msg states
that remount with options "data=journal,delalloc" succeeded, which is
not true.

To fix it up, I added a simple check after parse_options() call to
ensure that data=journal and delalloc/dioread_nolock parameters are
not present at the same time.

Signed-off-by: Piotr Sarna 
Acked-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Kyungmin Park 
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Kamal Mostafa 
---
 fs/ext4/super.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 1e4b5926..b83f75d 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -3440,7 +3440,7 @@ static int ext4_fill_super(struct super_block *sb, void 
*data, int silent)
}
if (test_opt(sb, DIOREAD_NOLOCK)) {
ext4_msg(sb, KERN_ERR, "can't mount with "
-"both data=journal and delalloc");
+"both data=journal and dioread_nolock");
goto failed_mount;
}
if (test_opt(sb, DELALLOC))
@@ -4618,6 +4618,21 @@ static int ext4_remount(struct super_block *sb, int 
*flags, char *data)
goto restore_opts;
}
 
+   if (test_opt(sb, DATA_FLAGS) == EXT4_MOUNT_JOURNAL_DATA) {
+   if (test_opt2(sb, EXPLICIT_DELALLOC)) {
+   ext4_msg(sb, KERN_ERR, "can't mount with "
+"both data=journal and delalloc");
+   err = -EINVAL;
+   goto restore_opts;
+   }
+   if (test_opt(sb, DIOREAD_NOLOCK)) {
+   ext4_msg(sb, KERN_ERR, "can't mount with "
+"both data=journal and dioread_nolock");
+   err = -EINVAL;
+   goto restore_opts;
+   }
+   }
+
if (sbi->s_mount_flags & EXT4_MF_FS_ABORTED)
ext4_abort(sb, "Abort forced by user");
 
-- 
1.8.1.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: [PATCH] mm/hotplug: Remove stop_machine() from try_offline_node()

[KOSAKI Motohiro]

This patch removes the use of stop_machine() in try_offline_node() and
adds comments to try_offline_node() and remove_memory() that
lock_device_hotplug() is required.


This patch need more verbose explanation. check_cpu_on_node() traverse cpus
and cpu hotplug seems to use cpu_hotplug_driver_lock() instead of 
lock_device_hotplug().


As described:

| lock_device_hotplug() serializes hotplug & online/offline operations.
| The lock is held in common sysfs online/offline interfaces and ACPI
| hotplug code paths.

And here are their code paths.

- CPU & Mem online/offline via sysfs online
store_online()->lock_device_hotplug()

- Mem online via sysfs state:
store_mem_state()->lock_device_hotplug()

- ACPI CPU & Mem hot-add:
acpi_scan_bus_device_check()->lock_device_hotplug()

- ACPI CPU & Mem hot-delete:
acpi_scan_hot_remove()->lock_device_hotplug()


O.K.


--
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 0/5] PCA9633: Add support to PCA9634 and fix some problems

[Bryan Wu]

On Wed, Aug 14, 2013 at 2:23 PM, Ricardo Ribalda Delgado
 wrote:
> Add Support for the PCA9634 chip. Simimart to the 9633, but with 8 outputs 
> instead of 4.
> Fix bug when 2 chips where present on the system, the ledclass will fail and 
> the chip wont probe.
> Protect ledout register with a mutex to support updates of more than leds at 
> the same time
> Fix device tree parsing
>
> v5: Contains feedback from Bryan Wu
> Bryan: Fix device tree bindings documentation
>

Thanks, I've already merged this new patchset into my tree.

-Bryan

> v4: Rebase to latest leds-next and new patch to Fix the dt parsing
>
> v3: Contains feedback from Bryan Wu
> Bryan: Rename pca9633 to pca963x
>
> v2: Contains feedback from Peter Meerwald
> Peter: Fix typo on commit message. Add bus number to name
>
> Ricardo Ribalda Delgado (5):
>   leds-pca9633: Add support for PCA9634
>   leds-pca9633: Unique naming of the LEDs
>   leds-pca9633: Add mutex to the ledout register
>   leds-pca9633: Rename to leds-pca963x
>   leds-pca963x: Fix device tree parsing
>
>  Documentation/devicetree/bindings/leds/pca9633.txt |   46 --
>  Documentation/devicetree/bindings/leds/pca963x.txt |   47 ++
>  drivers/leds/Kconfig   |9 +-
>  drivers/leds/Makefile  |2 +-
>  drivers/leds/leds-pca9633.c|  393 -
>  drivers/leds/leds-pca963x.c|  461 
> 
>  include/linux/platform_data/leds-pca9633.h |   41 --
>  include/linux/platform_data/leds-pca963x.h |   42 ++
>  8 files changed, 556 insertions(+), 485 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/leds/pca9633.txt
>  create mode 100644 Documentation/devicetree/bindings/leds/pca963x.txt
>  delete mode 100644 drivers/leds/leds-pca9633.c
>  create mode 100644 drivers/leds/leds-pca963x.c
>  delete mode 100644 include/linux/platform_data/leds-pca9633.h
>  create mode 100644 include/linux/platform_data/leds-pca963x.h
>
> --
> 1.7.10.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: [PATCH V3 RFC 00/16] EFI stub for ARM

[Roy Franz]

On Tue, Aug 13, 2013 at 10:58 AM, Roy Franz  wrote:
> On Fri, Aug 9, 2013 at 4:26 PM, Roy Franz  wrote:
>>
>> This patch series adds EFI stub support for the ARM architecture.
>> Some code that was previously only used by x86/x86_64 is now shared
>> and has been made more general.  The stub for ARM is implemented in
>> a similar manner to x86 in that it is a shim layer between EFI and
>> the normal zImage/bzImage boot process, and that an image with the
>> stub configured is bootable as both a zImage and EFI application.
>>
>> This patch now (new for v3) series depends on the
>> "arm: Add [U]EFI runtime services support" patches by 
>> leif.lindh...@linaro.org.
>> The Kconfig option now depends on the "CONFIG_EFI" option that his series
>> adds, and this option will ensure a little endian configuration.  Also, the
>> EFI support is used to handle the EFI memory map the stub passes to the 
>> kernel.
>> There are some minor changes to be coordinated with the EFI runtime services
>> patch series, so I have put this back to RFC status.  These changes should be
>> minor and relate to final device tree bindings.
>>
>> Changes since v2:
>> * EFI bugfix "correct call to free_pages" that patch series
>>   depends on now in mainline
>> * remove "-fno-stack-protector" from decompressor Makefile.  The current 
>> code doesn't
>>   trigger the stack protection, so the decompressor now compiles with it 
>> still
>>   on.  Note that there has never been any stack protection in the 
>> decompressor
>>   since the stack usage doesn't trigger the heuristic in GCC, so right now
>>   the "-fno-stack-protector" is a noop.
>> * Changed EFI command line handling to not have a fixed limit.
>> * Change FDT memory allocation to retry with a larger allocation if
>>   first educated guess is inadequate.
>> * Correctly set 'SizeOfCode' in PE/COFF header.
>> * Reviewed ".setup" section that is in x86 PE/COFF header.  This is used for 
>> x86
>>   to account for code that is not in the .text section.  We don't need this
>>   for ARM, as all of our code is in the .text section, or in the PE/COFF 
>> header
>>   itself.
>> * Moved EFI_STUB_ERROR #define to header file to share between stub C and 
>> ASM.
>> * Variety of cleanups and fixes in head.S.
>> * Changed update_fdt_and_exit_boot() to just update the device tree, and
>>   renamed appropriately.  Memory allocations moved out of this function as
>>   well, which enables the retries if the initial FDT size is too small.
>>   Note that in order to do the retried allocations, the original FDT and
>>   command line memory regions are left allocated.  This is OK since the 
>> kernel
>>   has the memory map and will free these allocations along with the initrd
>>   and new fdt allocations.
>> * Added prefix to all prints, reduced number of prints, and reviewed all
>>   messages.
>> * Change mixed usage of dtb/fdt to all be fdt or "device tree" in efi-stub.c
>> * remove unnecessary zimage_size variable from relocate_kernel()
>> * correct return types on EFI functions - should be efi_status_t, not int.
>>
>>
>>
>> Changes since V1:
>> * Updated head.S based on feedback from Dave Martin.  ARM/THUMB
>>   switches now much cleaner.
>> * Broke up changes to x86 and common code into more patches.
>>   10 more patches in this series.
>>
>> Roy Franz (16):
>>   Move common EFI stub code from x86 arch code to common location
>>   Add system pointer argument to shared EFI stub related functions
>> so they no longer use global system table pointer as they did
>> when part of eboot.c. This code is now shared, so using a
>> global variable as part of the interface is not that nice.
>> Also, by avoiding any global variables in the ARM EFI stub,
>> this allows the code to be position independent without
>> requiring GOT fixups.
>>   Rename memory allocation/free functions
>>   Add minimum address parameter to efi_low_alloc()
>>   rename __get_map() to efi_get_memory_map(), add parameter to
>> optionally return mmap key. The mmap key is required to exit
>> EFI boot services, and allows efi_get_memory_map() to be used
>> for getting final memory map.
>>   Enforce minimum alignment of 1 page on allocations. The
>> efi_high_alloc() and efi_low_alloc() functions use the
>> EFI_ALLOCATE_ADDRESS option to the EFI function
>> allocate_pages(), which requires a minimum of page alignment,
>> and rejects all other requests.
>>   Allow efi_free() to be called with size of 0, and do nothing in that
>> case.
>>   Generalize handle_ramdisks() and rename to handle_cmdline_files().
>>   Renames in handle_cmdline_files() to complete generalization.
>>   Move EFI_READ_CHUNK_SIZE define to shared location.
>>   Add proper definitions for some EFI function pointers.
>>   Fix types in EFI calls to match EFI function definitions.
>>   resolve warnings found on ARM compile
>>   Add strstr to compressed string.c for ARM.
>>   

[PATCH v3 3/5] mm: Notify filesystems when it's time to apply a deferred cmtime update

[Andy Lutomirski]

Filesystems that defer cmtime updates should update cmtime when any
of these events happen after a write via a mapping:

 - The mapping is written back to disk.  This happens from all kinds
   of places, all of which eventually call ->writepages.

 - munmap is called or the mapping is removed when the process exits

 - msync(MS_ASYNC) is called.  Linux currently does nothing for
   msync(MS_ASYNC), but POSIX says that cmtime should be updated some
   time between an mmaped write and the subsequent msync call.
   MS_SYNC calls ->writepages, but MS_ASYNC needs special handling.

Filesystmes that defer cmtime updates should flush them on munmap or
exit.  Finding out that this happened through vm_ops is messy, so
add a new address space op for this.

It's not strictly necessary to call ->flush_cmtime after ->writepages,
but it simplifies the fs code.  As an optional optimization,
filesystems can call mapping_test_clear_cmtime themselves in
->writepages (as long as they're careful to scan all the pages first
-- the cmtime bit may not be set when ->writepages is entered).

This patch does not implement the MS_ASYNC case; that's in the next
patch.

Signed-off-by: Andy Lutomirski 
---
 include/linux/fs.h|  9 +
 include/linux/writeback.h |  1 +
 mm/mmap.c |  9 -
 mm/page-writeback.c   | 26 ++
 4 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/include/linux/fs.h b/include/linux/fs.h
index 86cf0a4..f224155 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -350,6 +350,15 @@ struct address_space_operations {
/* Write back some dirty pages from this mapping. */
int (*writepages)(struct address_space *, struct writeback_control *);
 
+   /*
+* Userspace expects certain system calls to update cmtime if
+* a file has been recently written using a shared vma.  In
+* cases where cmtime may need to be updated but writepages is
+* not called, this is called instead.  (Implementations
+* should call mapping_test_clear_cmtime.)
+*/
+   void (*flush_cmtime)(struct address_space *);
+
/* Set a page dirty.  Return true if this dirtied it */
int (*set_page_dirty)(struct page *page);
 
diff --git a/include/linux/writeback.h b/include/linux/writeback.h
index 4e198ca..f6e8261 100644
--- a/include/linux/writeback.h
+++ b/include/linux/writeback.h
@@ -174,6 +174,7 @@ typedef int (*writepage_t)(struct page *page, struct 
writeback_control *wbc,
 
 int generic_writepages(struct address_space *mapping,
   struct writeback_control *wbc);
+void generic_flush_cmtime(struct address_space *mapping);
 void tag_pages_for_writeback(struct address_space *mapping,
 pgoff_t start, pgoff_t end);
 int write_cache_pages(struct address_space *mapping,
diff --git a/mm/mmap.c b/mm/mmap.c
index 1edbaa3..7ed7700 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1,3 +1,4 @@
+
 /*
  * mm/mmap.c
  *
@@ -249,8 +250,14 @@ static struct vm_area_struct *remove_vma(struct 
vm_area_struct *vma)
might_sleep();
if (vma->vm_ops && vma->vm_ops->close)
vma->vm_ops->close(vma);
-   if (vma->vm_file)
+   if (vma->vm_file) {
+   if ((vma->vm_flags & VM_SHARED) && vma->vm_file->f_mapping) {
+   struct address_space *mapping = vma->vm_file->f_mapping;
+   if (mapping->a_ops && mapping->a_ops->flush_cmtime)
+   mapping->a_ops->flush_cmtime(mapping);
+   }
fput(vma->vm_file);
+   }
mpol_put(vma_policy(vma));
kmem_cache_free(vm_area_cachep, vma);
return next;
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 3f0c895..9ab8c9e 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -1928,6 +1928,18 @@ int do_writepages(struct address_space *mapping, struct 
writeback_control *wbc)
ret = mapping->a_ops->writepages(mapping, wbc);
else
ret = generic_writepages(mapping, wbc);
+
+   /*
+* ->writepages will call clear_page_dirty_for_io, which may, in turn,
+* mark the mapping for deferred cmtime update.  As an optimization,
+* a filesystem can flush the update at the end of ->writepages
+* (possibly avoiding a journal transaction, for example), but,
+* for simplicity, let filesystems skip that part and just implement
+* ->flush_cmtime.
+*/
+   if (mapping->a_ops->flush_cmtime)
+   mapping->a_ops->flush_cmtime(mapping);
+
return ret;
 }
 
@@ -1970,6 +1982,20 @@ int write_one_page(struct page *page, int wait)
 }
 EXPORT_SYMBOL(write_one_page);
 
+/**
+ * generic_flush_cmtime - perform a deferred cmtime update if needed
+ * @mapping: address space structure
+ *
+ * This is a library function, which implements the flush_cmtime()
+ * address_space_operation.
+ */

Re: Linux kernel cross-compilers

[Max Filippov]

On Fri, Aug 16, 2013 at 7:43 PM, Guenter Roeck  wrote:
> On 08/16/2013 02:45 AM, Max Filippov wrote:

 Guenter,
 can you share a complete build log with V=1?

>>>
>>> http://roeck-us.net/linux/logs/make.xtensa.log.bad
>>> http://roeck-us.net/linux/logs/make.xtensa.log.ok
>>>
>>> Key difference: the failing command in the bad case is
>>>  xtensa-linux-objcopy -O elf32-xtensa-le
>>> and in the good case
>>>  xtensa-linux-objcopy -O elf32-xtensa-be
>>>
>>> Same compiler (4.6.3 from kernel.org), same configuration file, same
>>> command
>>> line.
>>> Configuration file is generated from defconfig, and the resulting .config
>>> file
>>> is the same in both cases.
>>>
>>> If I execute make and expicitly set BIG_ENDIAN=1 on the failing system as
>>> parameter to it,
>>> it works fine. If I set BIG_ENDIAN=0 on the passing system, it fails.
>>>
>>> I am puzzled. Guess there must be something different, but I have no idea
>>> what it might be.
>>
>>
>> What is the output of
>>
>> echo -e __XTENSA_EB__ | xtensa-linux-gcc -E -
>>
>> on the failing system?
>>
> It is "1", but that let me pinpoint the problem.
>
> On the failing system, the version of echo executed by make does
> not understand the "-e" option. Thus, when running
> arch/xtensa/boot/Makefile,
> "echo -e __XTENSA_EB__" returns "-e __XTENSA_EB__", which doesn't compile,
> and BIG_ENDIAN ends up being 0. So the compiler is completely innocent.
>
> I found out the root source: SHELL is set the /bin/sh, which on the failing
> system points to /bin/dash (default in Ubuntu, or at least it used to be).
> dash apparently has a built-in version of echo which does not understand
> '-e'.
> Oh well.

Cool. OTOH I don't think that we need to -e to output __XTENSA_EB__.
Will send a patch for that.

-- 
Thanks.
-- Max
--
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 093/133] KVM: s390: move kvm_guest_enter,exit closer to sie

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Dominik Dingel 

commit 2b29a9fdcb92bfc6b6f4c412d71505869de61a56 upstream.

Any uaccess between guest_enter and guest_exit could trigger a page fault,
the page fault handler would handle it as a guest fault and translate a
user address as guest address.

Signed-off-by: Dominik Dingel 
Signed-off-by: Christian Borntraeger 
Signed-off-by: Paolo Bonzini 
[ kamal: backport to 3.8 (context) ]
Signed-off-by: Kamal Mostafa 
---
 arch/s390/kvm/kvm-s390.c | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 8bafa4f..74e64f8 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -613,14 +613,25 @@ static int __vcpu_run(struct kvm_vcpu *vcpu)
kvm_s390_deliver_pending_interrupts(vcpu);
 
vcpu->arch.sie_block->icptcode = 0;
-   preempt_disable();
-   kvm_guest_enter();
-   preempt_enable();
VCPU_EVENT(vcpu, 6, "entering sie flags %x",
   atomic_read(>arch.sie_block->cpuflags));
trace_kvm_s390_sie_enter(vcpu,
 atomic_read(>arch.sie_block->cpuflags));
+
+   /*
+* As PF_VCPU will be used in fault handler, between guest_enter
+* and guest_exit should be no uaccess.
+*/
+   preempt_disable();
+   kvm_guest_enter();
+   preempt_enable();
rc = sie64a(vcpu->arch.sie_block, vcpu->run->s.regs.gprs);
+   kvm_guest_exit();
+
+   VCPU_EVENT(vcpu, 6, "exit sie icptcode %d",
+  vcpu->arch.sie_block->icptcode);
+   trace_kvm_s390_sie_exit(vcpu, vcpu->arch.sie_block->icptcode);
+
if (rc) {
if (kvm_is_ucontrol(vcpu->kvm)) {
rc = SIE_INTERCEPT_UCONTROL;
@@ -631,10 +642,6 @@ static int __vcpu_run(struct kvm_vcpu *vcpu)
rc = 0;
}
}
-   VCPU_EVENT(vcpu, 6, "exit sie icptcode %d",
-  vcpu->arch.sie_block->icptcode);
-   trace_kvm_s390_sie_exit(vcpu, vcpu->arch.sie_block->icptcode);
-   kvm_guest_exit();
 
memcpy(>run->s.regs.gprs[14], >arch.sie_block->gg14, 16);
return rc;
-- 
1.8.1.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 088/133] virtio: console: fix race with port unplug and open/close

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Amit Shah 

commit 057b82be3ca3d066478e43b162fc082930a746c9 upstream.

There's a window between find_port_by_devt() returning a port and us
taking a kref on the port, where the port could get unplugged.  Fix it
by taking the reference in find_port_by_devt() itself.

Problem reported and analyzed by Mateusz Guzik.

Reported-by: Mateusz Guzik 
Signed-off-by: Amit Shah 
Signed-off-by: Rusty Russell 
Signed-off-by: Kamal Mostafa 
---
 drivers/char/virtio_console.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index 3e338a7..ff015e7 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -278,9 +278,12 @@ static struct port *find_port_by_devt_in_portdev(struct 
ports_device *portdev,
unsigned long flags;
 
spin_lock_irqsave(>ports_lock, flags);
-   list_for_each_entry(port, >ports, list)
-   if (port->cdev->dev == dev)
+   list_for_each_entry(port, >ports, list) {
+   if (port->cdev->dev == dev) {
+   kref_get(>kref);
goto out;
+   }
+   }
port = NULL;
 out:
spin_unlock_irqrestore(>ports_lock, flags);
@@ -1042,14 +1045,10 @@ static int port_fops_open(struct inode *inode, struct 
file *filp)
struct port *port;
int ret;
 
+   /* We get the port with a kref here */
port = find_port_by_devt(cdev->dev);
filp->private_data = port;
 
-   /* Prevent against a port getting hot-unplugged at the same time */
-   spin_lock_irq(>portdev->ports_lock);
-   kref_get(>kref);
-   spin_unlock_irq(>portdev->ports_lock);
-
/*
 * Don't allow opening of console port devices -- that's done
 * via /dev/hvc
-- 
1.8.1.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 v3 4/5] mm: Scan for dirty ptes and update cmtime on MS_ASYNC

[Andy Lutomirski]

This is probably unimportant but improves POSIX compliance.

Signed-off-by: Andy Lutomirski 
---
 mm/msync.c | 83 +-
 1 file changed, 72 insertions(+), 11 deletions(-)

diff --git a/mm/msync.c b/mm/msync.c
index 632df45..9e41acd 100644
--- a/mm/msync.c
+++ b/mm/msync.c
@@ -13,13 +13,16 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 /*
  * MS_SYNC syncs the entire file - including mappings.
  *
  * MS_ASYNC does not start I/O (it used to, up to 2.5.67).
  * Nor does it marks the relevant pages dirty (it used to up to 2.6.17).
- * Now it doesn't do anything, since dirty pages are properly tracked.
+ * Now all it does is ensure that file timestamps get updated, since POSIX
+ * requires it.  We track dirty pages correct without MS_ASYNC.
  *
  * The application may now run fsync() to
  * write out the dirty pages and wait on the writeout and check the result.
@@ -28,6 +31,57 @@
  * So by _not_ starting I/O in MS_ASYNC we provide complete flexibility to
  * applications.
  */
+
+static int msync_async_range(struct vm_area_struct *vma,
+ unsigned long *start, unsigned long end)
+{
+   struct mm_struct *mm;
+   struct address_space *mapping;
+   int iters = 0;
+
+   while (*start < end && *start < vma->vm_end && iters < 128) {
+   unsigned int page_mask, page_increm;
+
+   /*
+* Require that the pte writable (because otherwise it can't
+* be dirty, so there's nothing to clean).
+*
+* In theory we could check the pte dirty bit, but this is
+* awkward and barely worth it.
+*/
+   struct page *page = follow_page_mask(vma, *start,
+FOLL_GET | FOLL_WRITE,
+_mask);
+
+   if (page && !IS_ERR(page)) {
+   if (lock_page_killable(page) == 0) {
+   page_mkclean(page);
+   unlock_page(page);
+   }
+   put_page(page);
+   }
+
+   if (IS_ERR(page))
+   return PTR_ERR(page);
+
+   page_increm = 1 + (~(*start >> PAGE_SHIFT) & page_mask);
+   *start += page_increm * PAGE_SIZE;
+   cond_resched();
+   iters++;
+   }
+
+   /* XXX: try to do this only once? */
+   mapping = vma->vm_file->f_mapping;
+   if (mapping->a_ops->flush_cmtime)
+   mapping->a_ops->flush_cmtime(mapping);
+
+   /* Give mmap_sem writers a chance. */
+   mm = current->mm;
+   up_read(>mmap_sem);
+   down_read(>mmap_sem);
+   return 0;
+}
+
 SYSCALL_DEFINE3(msync, unsigned long, start, size_t, len, int, flags)
 {
unsigned long end;
@@ -77,18 +131,25 @@ SYSCALL_DEFINE3(msync, unsigned long, start, size_t, len, 
int, flags)
goto out_unlock;
}
file = vma->vm_file;
-   start = vma->vm_end;
-   if ((flags & MS_SYNC) && file &&
-   (vma->vm_flags & VM_SHARED)) {
-   get_file(file);
-   up_read(>mmap_sem);
-   error = vfs_fsync(file, 0);
-   fput(file);
-   if (error || start >= end)
-   goto out;
-   down_read(>mmap_sem);
+   if (file && vma->vm_flags & VM_SHARED) {
+   if (flags & MS_SYNC) {
+   start = vma->vm_end;
+   get_file(file);
+   up_read(>mmap_sem);
+   error = vfs_fsync(file, 0);
+   fput(file);
+   if (error || start >= end)
+   goto out;
+   down_read(>mmap_sem);
+   } else if ((vma->vm_flags & VM_WRITE) &&
+  file->f_mapping) {
+   error = msync_async_range(vma, , end);
+   } else {
+   start = vma->vm_end;
+   }
vma = find_vma(mm, start);
} else {
+   start = vma->vm_end;
if (start >= end) {
error = 0;
goto out_unlock;
-- 
1.8.3.1

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

Re: [PATCH v3] hwspinlock/msm: Add support for Qualcomm MSM HW Mutex block

[Stephen Warren]

On 08/14/2013 01:09 PM, Kumar Gala wrote:
> Add driver for Qualcomm MSM Hardware Mutex block that exists on newer MSM
> SoC (MSM8974, etc).

> diff --git a/Documentation/devicetree/bindings/hwlock/msm-tcsr-mutex.txt 
> b/Documentation/devicetree/bindings/hwlock/msm-tcsr-mutex.txt

> +Required properties:
> +- compatible: should be "qcom,tcsr-mutex"
> +- reg: Should contain registers location and length of mutex registers
> +- reg-names:
> + "mutex-base"  - string to identify mutex registers
> +- qcom,num-locks: the number of locks/mutexes supported

Doesn't the block support any interrupts? I suppose the interrupts
property can be optional though even if it does.

Aside from the comments re: reg-names, this binding seems fine.
--
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 kernel cross-compilers

[Sam Ravnborg]

On Fri, Aug 16, 2013 at 08:43:35AM -0700, Guenter Roeck wrote:
> On 08/16/2013 02:45 AM, Max Filippov wrote:
 Guenter,
 can you share a complete build log with V=1?

>>>
>>> http://roeck-us.net/linux/logs/make.xtensa.log.bad
>>> http://roeck-us.net/linux/logs/make.xtensa.log.ok
>>>
>>> Key difference: the failing command in the bad case is
>>>  xtensa-linux-objcopy -O elf32-xtensa-le
>>> and in the good case
>>>  xtensa-linux-objcopy -O elf32-xtensa-be
>>>
>>> Same compiler (4.6.3 from kernel.org), same configuration file, same command
>>> line.
>>> Configuration file is generated from defconfig, and the resulting .config
>>> file
>>> is the same in both cases.
>>>
>>> If I execute make and expicitly set BIG_ENDIAN=1 on the failing system as
>>> parameter to it,
>>> it works fine. If I set BIG_ENDIAN=0 on the passing system, it fails.
>>>
>>> I am puzzled. Guess there must be something different, but I have no idea
>>> what it might be.
>>
>> What is the output of
>>
>> echo -e __XTENSA_EB__ | xtensa-linux-gcc -E -
>>
>> on the failing system?
>>
> It is "1", but that let me pinpoint the problem.
>
> On the failing system, the version of echo executed by make does
> not understand the "-e" option. Thus, when running arch/xtensa/boot/Makefile,
> "echo -e __XTENSA_EB__" returns "-e __XTENSA_EB__", which doesn't compile,
> and BIG_ENDIAN ends up being 0. So the compiler is completely innocent.
>
> I found out the root source: SHELL is set the /bin/sh, which on the failing
> system points to /bin/dash (default in Ubuntu, or at least it used to be).
> dash apparently has a built-in version of echo which does not understand '-e'.

Could you try to replace "echo -e bla" with "printf "bla".
Kbuild.include uses some similar tricks but here printf is used.
Maybe this can be dash compatible then

Sam
--
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] Miscellaneous trivialities

[Michael Witten]

On Fri, 16 Aug 2013 10:48:16 -0500, Rob Landley wrote:

> On 08/15/2013 04:44:01 AM, Michael Witten wrote:
>
>> I've been sitting on some trivial patches for a while, and I'd just
>> like to get them out of the way.
>>
>> Here is the series:
>>
>> ...
>>
>>   [5] Docs: Replace `hotplug' with `udev'
>>
>> ...
>>
>> diff --git a/Documentation/networking/README.ipw2200 
>> b/Documentation/networking/README.ipw2200
>> index b7658be..aeb6494 100644
>> --- a/Documentation/networking/README.ipw2200
>> +++ b/Documentation/networking/README.ipw2200
>> @@ -256,7 +256,7 @@ You can set the debug level via:
>> 
>>  Where $VALUE would be a number in the case of this sysfs entry.  The
>>  input to sysfs files does not have to be a number.  For example, the
>> -firmware loader used by hotplug utilizes sysfs entries for transferring
>> +firmware loader used by udev utilizes sysfs entries for transferring
>>  the firmware image from user space into the driver.
>
> Hotplug is the name of the kernel subsystem, udev was one implementation
> of a userspace agent for it. A different implementation would be mdev
> (in busybox), some linux from scratch types are still using variants of
> diethotplug, there's a fork of udev called eudev that avoids systemd...
>
> And these days, firmware loading is mostly done directly by the kernel.
>
>>  The Intel(R) PRO/Wireless 2915ABG Driver for Linux exposes sysfs entries
>> @@ -425,8 +425,7 @@ are made to the driver.  Currently, there are no major 
>> changes planned.
>>  --
>>
>>  The driver requires a firmware image, download it and extract the
>> -files under /lib/firmware (or wherever your hotplug's firmware.agent
>> -will look for firmware files)
>> +files under /lib/firmware (or wherever udev will look for firmware files)
>
> Again, hotplug is correct.

Thanks for catching my error. I removed that patch from the series; the
remaining commits can be pulled from here:

  https://github.com/mfwitten/linux.git trivial/misc/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 090/133] virtio: console: clean up port data immediately at time of unplug

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Amit Shah 

commit ea3768b4386a8d1790f4cc9a35de4f55b92d6442 upstream.

We used to keep the port's char device structs and the /sys entries
around till the last reference to the port was dropped.  This is
actually unnecessary, and resulted in buggy behaviour:

1. Open port in guest
2. Hot-unplug port
3. Hot-plug a port with the same 'name' property as the unplugged one

This resulted in hot-plug being unsuccessful, as a port with the same
name already exists (even though it was unplugged).

This behaviour resulted in a warning message like this one:

---8<---
WARNING: at fs/sysfs/dir.c:512 sysfs_add_one+0xc9/0x130() (Not tainted)
Hardware name: KVM
sysfs: cannot create duplicate filename
'/devices/pci:00/:00:04.0/virtio0/virtio-ports/vport0p1'

Call Trace:
 [] ? warn_slowpath_common+0x87/0xc0
 [] ? warn_slowpath_fmt+0x46/0x50
 [] ? sysfs_add_one+0xc9/0x130
 [] ? create_dir+0x68/0xb0
 [] ? sysfs_create_dir+0x39/0x50
 [] ? kobject_add_internal+0xb9/0x260
 [] ? kobject_add_varg+0x38/0x60
 [] ? kobject_add+0x44/0x70
 [] ? get_device_parent+0xf4/0x1d0
 [] ? device_add+0xc9/0x650

---8<---

Instead of relying on guest applications to release all references to
the ports, we should go ahead and unregister the port from all the core
layers.  Any open/read calls on the port will then just return errors,
and an unplug/plug operation on the host will succeed as expected.

This also caused buggy behaviour in case of the device removal (not just
a port): when the device was removed (which means all ports on that
device are removed automatically as well), the ports with active
users would clean up only when the last references were dropped -- and
it would be too late then to be referencing char device pointers,
resulting in oopses:

---8<---
PID: 6162   TASK: 8801147ad500  CPU: 0   COMMAND: "cat"
 #0 [88011b9d5a90] machine_kexec at 8103232b
 #1 [88011b9d5af0] crash_kexec at 810b9322
 #2 [88011b9d5bc0] oops_end at 814f4a50
 #3 [88011b9d5bf0] die at 8100f26b
 #4 [88011b9d5c20] do_general_protection at 814f45e2
 #5 [88011b9d5c50] general_protection at 814f3db5
[exception RIP: strlen+2]
RIP: 81272ae2  RSP: 88011b9d5d00  RFLAGS: 00010246
RAX:   RBX: 880118901c18  RCX: 
RDX: 88011799982c  RSI: 00d0  RDI: 3a303030302f3030
RBP: 88011b9d5d38   R8: 0006   R9: a0134500
R10: 1000  R11: 1000  R12: 880117a1cc10
R13: 00d0  R14: 0017  R15: 81aff700
ORIG_RAX:   CS: 0010  SS: 0018
 #6 [88011b9d5d00] kobject_get_path at 8126dc5d
 #7 [88011b9d5d40] kobject_uevent_env at 8126e551
 #8 [88011b9d5dd0] kobject_uevent at 8126e9eb
 #9 [88011b9d5de0] device_del at 813440c7

---8<---

So clean up when we have all the context, and all that's left to do when
the references to the port have dropped is to free up the port struct
itself.

Reported-by: chayang 
Reported-by: YOGANANTH SUBRAMANIAN 
Reported-by: FuXiangChun 
Reported-by: Qunfang Zhang 
Reported-by: Sibiao Luo 
Signed-off-by: Amit Shah 
Signed-off-by: Rusty Russell 
Signed-off-by: Kamal Mostafa 
---
 drivers/char/virtio_console.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index 4e848c8..615804c 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -1524,14 +1524,6 @@ static void remove_port(struct kref *kref)
 
port = container_of(kref, struct port, kref);
 
-   sysfs_remove_group(>dev->kobj, _attribute_group);
-   device_destroy(pdrvdata.class, port->dev->devt);
-   cdev_del(port->cdev);
-
-   kfree(port->name);
-
-   debugfs_remove(port->debugfs_file);
-
kfree(port);
 }
 
@@ -1589,6 +1581,14 @@ static void unplug_port(struct port *port)
 */
port->portdev = NULL;
 
+   sysfs_remove_group(>dev->kobj, _attribute_group);
+   device_destroy(pdrvdata.class, port->dev->devt);
+   cdev_del(port->cdev);
+
+   kfree(port->name);
+
+   debugfs_remove(port->debugfs_file);
+
/*
 * Locks around here are not necessary - a port can't be
 * opened after we removed the port struct from ports_list
-- 
1.8.1.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 045/133] iwlwifi: mvm: refuse connection to APs with BI < 16

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Johannes Berg 

commit 48bc13072109ea58465542aa1ee31b4e1065468a upstream.

Due to a firmware bug, it crashes when the beacon interval
is smaller than 16. Avoid this by refusing the station state
change creating the AP station, causing mac80211 to abandon
the attempt to connect to the AP, and eventually wpa_s to
blacklist it.

Reviewed-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg 
[ luis: backported to 3.5:
  - file renamed: drivers/net/wireless/iwlwifi/mvm/mac80211.c ->
drivers/net/wireless/iwlwifi/iwl-mac80211.c
  - adjusted context
  - changed IWL_ERR 1st argument to 'priv'
  - removed redundant condition in 'if' statement ]
Signed-off-by: Luis Henriques 
Signed-off-by: Kamal Mostafa 
---
 drivers/net/wireless/iwlwifi/dvm/mac80211.c | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/dvm/mac80211.c 
b/drivers/net/wireless/iwlwifi/dvm/mac80211.c
index 3163e0f..c784f69 100644
--- a/drivers/net/wireless/iwlwifi/dvm/mac80211.c
+++ b/drivers/net/wireless/iwlwifi/dvm/mac80211.c
@@ -786,9 +786,23 @@ static int iwlagn_mac_sta_state(struct ieee80211_hw *hw,
mutex_lock(>mutex);
if (vif->type == NL80211_IFTYPE_STATION) {
if (old_state == IEEE80211_STA_NOTEXIST &&
-   new_state == IEEE80211_STA_NONE)
+   new_state == IEEE80211_STA_NONE) {
+   /*
+* Firmware bug - it'll crash if the beacon interval is 
less
+* than 16. We can't avoid connecting at all, so refuse 
the
+* station state change, this will cause mac80211 to 
abandon
+* attempts to connect to this AP, and eventually wpa_s 
will
+* blacklist the AP...
+*/
+   if (vif->bss_conf.beacon_int < 16) {
+   IWL_ERR(priv,
+   "AP %pM beacon interval is %d, refusing 
due to firmware bug!\n",
+   sta->addr, vif->bss_conf.beacon_int);
+   ret = -EINVAL;
+   goto out_unlock;
+   }
op = ADD;
-   else if (old_state == IEEE80211_STA_NONE &&
+   } else if (old_state == IEEE80211_STA_NONE &&
 new_state == IEEE80211_STA_NOTEXIST)
op = REMOVE;
else if (old_state == IEEE80211_STA_AUTH &&
@@ -856,6 +870,7 @@ static int iwlagn_mac_sta_state(struct ieee80211_hw *hw,
if (iwl_is_rfkill(priv))
ret = 0;
 
+out_unlock:
mutex_unlock(>mutex);
IWL_DEBUG_MAC80211(priv, "leave\n");
 
-- 
1.8.1.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 081/133] virtio/console: Quit from splice_write if pipe->nrbufs is 0

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Yoshihiro YUNOMAE 

commit 68c034fefe20eaf7d5569aae84584b07987ce50a upstream.

Quit from splice_write if pipe->nrbufs is 0 for avoiding oops in virtio-serial.

When an application was doing splice from a kernel buffer to virtio-serial on
a guest, the application received signal(SIGINT). This situation will normally
happen, but the kernel executed a kernel panic by oops as follows:

 BUG: unable to handle kernel paging request at 882071c8ef28
 IP: [] sg_init_table+0x2f/0x50
 PGD 1fac067 PUD 0
 Oops:  [#1] SMP
 Modules linked in: lockd sunrpc bnep bluetooth rfkill ip6t_REJECT 
nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter 
ip6_tables snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc 
snd_timer snd microcode virtio_balloon virtio_net pcspkr soundcore i2c_piix4 
i2c_core uinput floppy
 CPU: 1 PID: 908 Comm: trace-cmd Not tainted 3.10.0+ #49
 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
 task: 880071c64650 ti: 88007bf24000 task.ti: 88007bf24000
 RIP: 0010:[]  [] sg_init_table+0x2f/0x50
 RSP: 0018:88007bf25dd8  EFLAGS: 00010286
 RAX: 001fffe0 RBX: 882071c8ef28 RCX: 
 RDX:  RSI:  RDI: 880071c8ef48
 RBP: 88007bf25de8 R08: 88007fd15d40 R09: 880071c8ef48
 R10: ea0001c71040 R11: 8139c555 R12: 
 R13: 88007506a3c0 R14: 88007c862500 R15: 880071c8ef00
 FS:  7f0a3646c740() GS:88007fd0() knlGS:
 CS:  0010 DS:  ES:  CR0: 80050033
 CR2: 882071c8ef28 CR3: 7acbb000 CR4: 06e0
 DR0:  DR1:  DR2: 
 DR3:  DR6: 0ff0 DR7: 0400
 Stack:
  880071c8ef48 88007bf25e20 88007bf25e88 8139d6fa
  88007bf25e28 8127a3f4  
  880071c8ef48 1000 0003 88007bf25e08
 Call Trace:
  [] port_fops_splice_write+0xaa/0x130
  [] ? selinux_file_permission+0xc4/0x120
  [] ? wait_port_writable+0x1b0/0x1b0
  [] do_splice_from+0xa0/0x110
  [] SyS_splice+0x5ff/0x6b0
  [] system_call_fastpath+0x16/0x1b
 Code: c1 e2 05 48 89 e5 48 83 ec 10 4c 89 65 f8 41 89 f4 31 f6 48 89 5d f0 48 
89 fb e8 8d ce ff ff 41 8d 44 24 ff 48 c1 e0 05 48 01 c3 <48> 8b 03 48 83 e0 fe 
48 83 c8 02 48 89 03 48 8b 5d f0 4c 8b 65
 RIP  [] sg_init_table+0x2f/0x50
  RSP 
 CR2: 882071c8ef28
 ---[ end trace 86323505eb42ea8f ]---

It seems to induce pagefault in sg_init_tabel() when pipe->nrbufs is equal to
zero. This may happen in a following situation:

(1) The application normally does splice(read) from a kernel buffer, then does
splice(write) to virtio-serial.
(2) The application receives SIGINT when is doing splice(read), so splice(read)
is failed by EINTR. However, the application does not finish the operation.
(3) The application tries to do splice(write) without pipe->nrbufs.
(4) The virtio-console driver tries to touch scatterlist structure sgl in
sg_init_table(), but the region is out of bound.

To avoid the case, a kernel should check whether pipe->nrbufs is empty or not
when splice_write is executed in the virtio-console driver.

V3: Add Reviewed-by lines and stable@ line in sign-off area.

Signed-off-by: Yoshihiro YUNOMAE 
Reviewed-by: Amit Shah 
Reviewed-by: Masami Hiramatsu 
Cc: Amit Shah 
Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Signed-off-by: Rusty Russell 
Signed-off-by: Kamal Mostafa 
---
 drivers/char/virtio_console.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index a4b7aa0..0dfd175 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -938,6 +938,13 @@ static ssize_t port_fops_splice_write(struct 
pipe_inode_info *pipe,
if (is_rproc_serial(port->out_vq->vdev))
return -EINVAL;
 
+   /*
+* pipe->nrbufs == 0 means there are no data to transfer,
+* so this returns just 0 for no data.
+*/
+   if (!pipe->nrbufs)
+   return 0;
+
ret = wait_port_writable(port, filp->f_flags & O_NONBLOCK);
if (ret < 0)
return ret;
-- 
1.8.1.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 092/133] virtio: console: return -ENODEV on all read operations after unplug

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Amit Shah 

commit 96f97a83910cdb9d89d127c5ee523f8fc040a804 upstream.

If a port gets unplugged while a user is blocked on read(), -ENODEV is
returned.  However, subsequent read()s returned 0, indicating there's no
host-side connection (but not indicating the device went away).

This also happened when a port was unplugged and the user didn't have
any blocking operation pending.  If the user didn't monitor the SIGIO
signal, they won't have a chance to find out if the port went away.

Fix by returning -ENODEV on all read()s after the port gets unplugged.
write() already behaves this way.

Signed-off-by: Amit Shah 
Signed-off-by: Rusty Russell 
Signed-off-by: Kamal Mostafa 
---
 drivers/char/virtio_console.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index 62834bc..12829ae 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -755,6 +755,10 @@ static ssize_t port_fops_read(struct file *filp, char 
__user *ubuf,
 
port = filp->private_data;
 
+   /* Port is hot-unplugged. */
+   if (!port->guest_connected)
+   return -ENODEV;
+
if (!port_has_data(port)) {
/*
 * If nothing's connected on the host just return 0 in
@@ -771,7 +775,7 @@ static ssize_t port_fops_read(struct file *filp, char 
__user *ubuf,
if (ret < 0)
return ret;
}
-   /* Port got hot-unplugged. */
+   /* Port got hot-unplugged while we were waiting above. */
if (!port->guest_connected)
return -ENODEV;
/*
-- 
1.8.1.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 043/133] mac80211: fix ethtool stats for non-station interfaces

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Johannes Berg 

commit e13bae4f807401729b3f27c7e882a96b8b292809 upstream.

As reported in https://bugzilla.kernel.org/show_bug.cgi?id=60514,
the station loop never initialises 'sinfo' and therefore adds up
a stack values, leaking stack information (the number of times it
adds values is easily obtained another way.)

Fix this by initialising the sinfo for each station to add.

Signed-off-by: Johannes Berg 
Signed-off-by: Kamal Mostafa 
---
 net/mac80211/cfg.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 49c48c6..40732e3 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -638,6 +638,8 @@ static void ieee80211_get_et_stats(struct wiphy *wiphy,
if (sta->sdata->dev != dev)
continue;
 
+   sinfo.filled = 0;
+   sta_set_sinfo(sta, );
i = 0;
ADD_STA_STATS(sta);
}
-- 
1.8.1.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: [PATCH] memblock, numa: Binary search node id

[Russ Anderson]

On Thu, Aug 15, 2013 at 01:43:48PM -0700, Andrew Morton wrote:
> On Wed, 14 Aug 2013 22:46:29 -0700 Yinghai Lu  wrote:
> 
> > Current early_pfn_to_nid() on arch that support memblock go
> > over memblock.memory one by one, so will take too many try
> > near the end.
> > 
> > We can use existing memblock_search to find the node id for
> > given pfn, that could save some time on bigger system that
> > have many entries memblock.memory array.
> 
> Looks nice.  I wonder how much difference it makes.

Here are the timing differences for several machines.
In each case with the patch less time was spent in __early_pfn_to_nid().


3.11-rc5with patch  difference (%)
--  --
UV1: 256 nodes  9TB: 411.66  402.47 -9.19 (2.23%)
UV2: 255 nodes 16TB:1141.02 1138.12 -2.90 (0.25%)
UV2:  64 nodes  2TB: 128.15  126.53 -1.62 (1.26%)
UV2:  32 nodes  2TB: 121.87  121.07 -0.80 (0.66%)
Time in seconds.

Acked-by: Russ Anderson 
 
> > ...
> >
> > --- linux-2.6.orig/include/linux/memblock.h
> > +++ linux-2.6/include/linux/memblock.h
> > @@ -60,6 +60,8 @@ int memblock_reserve(phys_addr_t base, p
> >  void memblock_trim_memory(phys_addr_t align);
> >  
> >  #ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
> > +int memblock_search_pfn_nid(unsigned long pfn, unsigned long *start_pfn,
> > +   unsigned long  *end_pfn);
> >  void __next_mem_pfn_range(int *idx, int nid, unsigned long *out_start_pfn,
> >   unsigned long *out_end_pfn, int *out_nid);
> >  
> > Index: linux-2.6/mm/memblock.c
> > ===
> > --- linux-2.6.orig/mm/memblock.c
> > +++ linux-2.6/mm/memblock.c
> > @@ -914,6 +914,24 @@ int __init_memblock memblock_is_memory(p
> > return memblock_search(, addr) != -1;
> >  }
> >  
> > +#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
> > +int __init_memblock memblock_search_pfn_nid(unsigned long pfn,
> > +unsigned long *start_pfn, unsigned long *end_pfn)
> > +{
> > +   struct memblock_type *type = 
> > +   int mid = memblock_search(type, (phys_addr_t)pfn << PAGE_SHIFT);
> > +
> > +   if (mid == -1)
> > +   return -1;
> > +
> > +   *start_pfn = type->regions[mid].base >> PAGE_SHIFT;
> > +   *end_pfn = (type->regions[mid].base + type->regions[mid].size)
> > +   >> PAGE_SHIFT;
> > +
> > +   return type->regions[mid].nid;
> > +}
> > +#endif
> 
> This function will have no callers if
> CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y.  That's not too bad as the
> function is __init_memblock.  But this depends on
> CONFIG_ARCH_DISCARD_MEMBLOCK.  Messy :(
> 

-- 
Russ Anderson, OS RAS/Partitioning Project Lead  
SGI - Silicon Graphics Inc  r...@sgi.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: [RFC 2/4] driver core: Allow early registration of devices

[Greg Kroah-Hartman]

On Fri, Aug 16, 2013 at 10:39:21PM +0200, Thierry Reding wrote:
> +static DEFINE_MUTEX(device_early_mutex);
> +static LIST_HEAD(device_early_list);
> +static bool device_is_early = true;
> +
> +/*
> + * Keep a list of early registered devices so that they can be fully
> + * registered at a later point in time.
> + */
> +static void device_early_add(struct device *dev)

__init?

> +{
> + mutex_lock(_early_mutex);
> + list_add_tail(>p->early, _early_list);
> + mutex_unlock(_early_mutex);
> +}
> +
> +/*
> + * Mark the early device registration phase as completed.
> + */
> +int __init device_early_init(void)
> +{
> + device_is_early = false;
> +
> + return 0;
> +}
> +
> +/*
> + * Fixup platform devices instantiated from device tree. The problem is
> + * that since early registration happens before interrupt controllers
> + * have been setup, the OF core code won't know how to map interrupts.
> + */
> +int __init platform_device_early_fixup(struct platform_device *pdev)

This shouldn't be in this file, because:

> +/*
> + * Fully register early devices.
> + */
> +int __init device_early_done(void)
> +{
> + struct device_private *private;
> +
> + list_for_each_entry(private, _early_list, early) {
> + struct device *dev = private->device;
> + int err;
> +
> + if (dev->bus == _bus_type) {

Why special case the platform bus?  We are trying to move things off of
the platform bus, don't make it harder to do that :)

> + struct platform_device *pdev = to_platform_device(dev);
> +
> + err = platform_device_early_fixup(pdev);
> + if (err < 0)
> + dev_err(>dev,
> + "failed to fixup device %s: %d\n",
> + dev_name(>dev), err);
> + }

You should just have a bus callback that can be made here that, if
present, can be called.  That way any bus can handle this type of thing,
not just the platform one.


Not that I really like the whole idea anyway, but I doubt there's much I
can do about it...

thanks,

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

Re: [PATCH RFC 1/3] spmi: Linux driver framework for SPMI

[Greg Kroah-Hartman]

On Fri, Aug 16, 2013 at 02:47:15PM -0500, Josh Cartwright wrote:
> > > +#ifdef CONFIG_DEBUG_FS
> > 
> > Why?  If debugfs isn't enabled, the functions should just compile away
> > with the debugfs_() calls, so no need to do this type of thing here,
> > right?
> 
> Not sure I follow you, but it may be because this is a bit misleading.
> 
> Currently CONFIG_DEBUG_FS is being extended to also mean "do you want
> the SPMI core to create device entries?".  It would probably make more
> sense to have a CONFIG_SPMI_DEBUG option which is def_bool DEBUG_FS, as
> other busses have.
> 
> The #ifdef here would then be #ifdef CONFIG_SPMI_DEBUG, as well as in
> the Makefile:
> 
>   spmi-core-$(CONFIG_SPMI_DEBUG) += spmi-dbgfs.o

If debugfs is enabled why wouldn't you want debugfs entries for your
devices?  Don't assume a user is going to be able to rebuild their
kernel just for debugging stuff (hint, they usually aren't), so having
these present, if they don't cause any performance issues, is usually
best to always have around.

thanks,

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

[PATCH 037/133] usb: serial: option: blacklist ONDA MT689DC QMI interface

[Kamal Mostafa]

3.8.13.7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Enrico Mioso 

commit 3d1a69e726406ab662ab88fa30a3a05ed404334d upstream.

Prevent the option driver from binding itself to the QMI/WWAN interface, making
it unusable by the proper driver.

Signed-off-by: enrico Mioso 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/serial/option.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 9736e9b..1c8733a 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -819,7 +819,8 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0017, 0xff, 0xff, 
0xff),
.driver_info = (kernel_ulong_t)_intf3_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0018, 0xff, 0xff, 
0xff) },
-   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0019, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0019, 0xff, 0xff, 
0xff),
+   .driver_info = (kernel_ulong_t)_intf3_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0020, 0xff, 0xff, 
0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0021, 0xff, 0xff, 
0xff),
.driver_info = (kernel_ulong_t)_intf4_blacklist },
-- 
1.8.1.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/