Kernel Firmware - Adding Right way??
I've been the maintainer of the g4l project since about 2004, and have had issues with a few users that have hardware that requires firmware that isn't included in the kernel.org kernel. I want to do this the right way, since this is what it shows in the kernel firmware directory. DO NOT ADD FIRMWARE TO THIS DIRECTORY. == This directory is only here to contain firmware images extracted from old device drivers which predate the common use of request_firmware(). Problem is that when I manually add the missing firmware to the firmware directory, and add it to the list in the Makefile it works just fine, but I then tried to add the new firmware file directory to the cd it doesn't find the firmware. User reports this in dmesg. firmware :04:00.0: firmware: requesting bnx2x/bnx2x-e2-7.2.51.0.fw PM: Removing info for No Bus::04:00.0 bnx2x: bnx2x_init_firmware:11647(eth0)Can't load firmware file bnx2x/bnx2x-e2-7.2.51.0.fw bnx2x: bnx2x_func_hw_init:5477(eth0)Error loading firmware bnx2x: bnx2x_nic_load:2136(eth0)HW init failed, aborting The firmware is download using git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware. git and files and subdirectories are placed in the /lib/firmware directory except for the .git directory. So, not sure why it isn't finding the the kernel files. The options involving FIRMWARE are currently CONFIG_PREVENT_FIRMWARE_BUILD=y # CONFIG_FIRMWARE_IN_KERNEL is not set CONFIG_EXTRA_FIRMWARE="" # CONFIG_HOSTAP_FIRMWARE is not set CONFIG_FIRMWARE_MEMMAP=y # CONFIG_GOOGLE_FIRMWARE is not set The project builds all options in the kernel instead of using moduals since it includes a number of kernels to support various hardware and has most nics and disk adapters selected. link to the latest config file. ftp://amd64gcc.dyndns.org/bz3x6.6.config I've search over the web, and have even been communicating with the maintainer of the bnx2x firmware that is the issue. I'm hoping it is just some simple setting or option that needs to be set. Adding the 40M of firmware required increasing the ramdisk size for 64M to 128M to make room, but would like to have the firmware available for users that might need it to have the project work on there hardware. Thanks. +--+ Michael D. Setzer II - Computer Science Instructor Guam Community College Computer Center mailto:mi...@kuentos.guam.net mailto:msetze...@gmail.com http://www.guam.net/home/mikes Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +--+ http://setiathome.berkeley.edu (Original) Number of Seti Units Returned: 19,471 Processing time: 32 years, 290 days, 12 hours, 58 minutes (Total Hours: 287,489) BOINC@HOME CREDITS SETI13233290.532525 | EINSTEIN 9012033.029852 ROSETTA 5329761.808862 | ABC 15417521.047462 -- 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 8/7] pppoatm: fix missing wakeup in pppoatm_send()
On Sat, 2012-11-10 at 21:23 +0100, Krzysztof Mazur wrote: > With this tasklet_schedule() we implement a "spin_lock" here, but in > this case both conditions (vcc not ready and socket locked) can be > true for a long time and we can spin here for a long time. Reading this more carefully this morning... I hadn't realised it was these conditions, and not the sock_owned_by_user(), which had triggered. Yes, perhaps we should just return zero in that case and find another wakeup trigger... if indeed a wakeup is ever required in the VF_RELEASED and VF_CLOSE case. And if we've fixed things so that !VF_READY can never happen (have we?) perhaps this one doesn't matter at all? It was the sock_owned_by_user() case I was most interested in, and I was expecting that lock would generally be held briefly enough that the tasklet would be fine. Was that not so? -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] ALSA: line6: move staging driver to sound/usb/
On Sat, Nov 10, 2012 at 07:44:52AM +0100, Stefan Hajnoczi wrote: > The line6 driver supports devices from the Line6 PODxt, POD HD, > TonePort, and Variax product families. This USB sound driver has been > in staging since 2009 and is ready for wider review and users. > > These devices provide both PCM and MIDI. Depending on the model the PCM > supports capture and playback - there may be multiple capture sources. > MIDI is used to control the device including changing effect or > amplifier model settings, dumping presets, and changing between patches. > > There are userspace tools and a manual available at: > > http://www.tanzband-scream.at/line6/ > http://line6linux.sourceforge.net/ > > Cc: Markus Grabner > Signed-off-by: Stefan Hajnoczi Please fix all of the coding style issues, and the huge number of undocumented sysfs files before asking to move this out of staging. 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 1/7] HID: roccat: Cleanup of kovaplus module
Partially removed unneeded informations and data caching. Moved code nearer to format of newer drivers. Added "info" sysfs attribute to support device reset and deprecate other attributes. Signed-off-by: Stefan Achatz --- .../ABI/obsolete/sysfs-driver-hid-roccat-kovaplus | 41 .../ABI/testing/sysfs-driver-hid-roccat-kovaplus | 40 +--- drivers/hid/hid-roccat-kovaplus.c | 235 ++-- drivers/hid/hid-roccat-kovaplus.h | 14 +- 4 files changed, 167 insertions(+), 163 deletions(-) create mode 100644 Documentation/ABI/obsolete/sysfs-driver-hid-roccat-kovaplus diff --git a/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-kovaplus b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-kovaplus new file mode 100644 index 000..4d9fb262 --- /dev/null +++ b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-kovaplus @@ -0,0 +1,41 @@ +What: /sys/bus/usb/devices/-:./::./kovaplus/roccatkovaplus/actual_cpi +Date: January 2011 +Contact: Stefan Achatz +Description: The integer value of this attribute ranges from 1-4. + When read, this attribute returns the number of the active + cpi level. + This file is readonly. + Has never been used. If bookkeeping is done, it's done in userland tools. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./kovaplus/roccatkovaplus/actual_sensitivity_x +Date: January 2011 +Contact: Stefan Achatz +Description: The integer value of this attribute ranges from 1-10. + When read, this attribute returns the number of the actual + sensitivity in x direction. + This file is readonly. + Has never been used. If bookkeeping is done, it's done in userland tools. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./kovaplus/roccatkovaplus/actual_sensitivity_y +Date: January 2011 +Contact: Stefan Achatz +Description: The integer value of this attribute ranges from 1-10. + When read, this attribute returns the number of the actual + sensitivity in y direction. + This file is readonly. + Has never been used. If bookkeeping is done, it's done in userland tools. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./kovaplus/roccatkovaplus/firmware_version +Date: January 2011 +Contact: Stefan Achatz +Description: When read, this file returns the raw integer version number of the + firmware reported by the mouse. Using the integer value eases + further usage in other programs. To receive the real version + number the decimal point has to be shifted 2 positions to the + left. E.g. a returned value of 121 means 1.21 + This file is readonly. + Obsoleted by binary sysfs attribute "info". +Users: http://roccat.sourceforge.net diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus b/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus index 20f937c..507f2c7 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus @@ -1,12 +1,3 @@ -What: /sys/bus/usb/devices/-:./::./kovaplus/roccatkovaplus/actual_cpi -Date: January 2011 -Contact: Stefan Achatz -Description: The integer value of this attribute ranges from 1-4. - When read, this attribute returns the number of the active - cpi level. - This file is readonly. -Users: http://roccat.sourceforge.net - What: /sys/bus/usb/devices/-:./::./kovaplus/roccatkovaplus/actual_profile Date: January 2011 Contact: Stefan Achatz @@ -18,33 +9,12 @@ Description: The integer value of this attribute ranges from 0-4. active when the mouse is powered on. Users: http://roccat.sourceforge.net -What: /sys/bus/usb/devices/-:./::./kovaplus/roccatkovaplus/actual_sensitivity_x -Date: January 2011 -Contact: Stefan Achatz -Description: The integer value of this attribute ranges from 1-10. - When read, this attribute returns the number of the actual - sensitivity in x direction. - This file is readonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./kovaplus/roccatkovaplus/actual_sensitivity_y -Date: January 2011 +What: /sys/bus/usb/devices/-:./::./kovaplus/roccatkovaplus/info +Date: November 2012 Contact: Stefan Achatz -Description: The integer value of this attribute ranges from 1-10. - When read, this attribute returns the number of the actual - sensitivity in y
[PATCH 7/7] HID: roccat: Deprecated some Kovaplus sysfs attributes
Introduced attribute "control" and made profile_settings and profile_buttons readable, which makes profile[1-5]_settings and profile[1-5]_buttons obsolete. Signed-off-by: Stefan Achatz --- .../ABI/obsolete/sysfs-driver-hid-roccat-kovaplus | 25 + .../ABI/testing/sysfs-driver-hid-roccat-kovaplus | 29 +++- drivers/hid/hid-roccat-kovaplus.c | 10 --- drivers/hid/hid-roccat-kovaplus.h |2 + 4 files changed, 37 insertions(+), 29 deletions(-) diff --git a/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-kovaplus b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-kovaplus index 4d9fb262..4a98e02 100644 --- a/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-kovaplus +++ b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-kovaplus @@ -39,3 +39,28 @@ Description: When read, this file returns the raw integer version number of the This file is readonly. Obsoleted by binary sysfs attribute "info". Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./kovaplus/roccatkovaplus/profile[1-5]_buttons +Date: January 2011 +Contact: Stefan Achatz +Description: The mouse can store 5 profiles which can be switched by the + press of a button. A profile is split in settings and buttons. + profile_buttons holds information about button layout. + When read, these files return the respective profile buttons. + The returned data is 23 bytes in size. + This file is readonly. + Write control to select profile and read profile_buttons instead. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./kovaplus/roccatkovaplus/profile[1-5]_settings +Date: January 2011 +Contact: Stefan Achatz +Description: The mouse can store 5 profiles which can be switched by the + press of a button. A profile is split in settings and buttons. + profile_settings holds information like resolution, sensitivity + and light effects. + When read, these files return the respective profile settings. + The returned data is 16 bytes in size. + This file is readonly. + Write control to select profile and read profile_settings instead. +Users: http://roccat.sourceforge.net diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus b/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus index 507f2c7..e8a04f2 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus @@ -28,18 +28,8 @@ Description: The mouse can store 5 profiles which can be switched by the The mouse will reject invalid data. Which profile to write is determined by the profile number contained in the data. - This file is writeonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./kovaplus/roccatkovaplus/profile[1-5]_buttons -Date: January 2011 -Contact: Stefan Achatz -Description: The mouse can store 5 profiles which can be switched by the - press of a button. A profile is split in settings and buttons. - profile_buttons holds information about button layout. - When read, these files return the respective profile buttons. - The returned data is 23 bytes in size. - This file is readonly. + Before reading this file, control has to be written to select + which profile to read. Users: http://roccat.sourceforge.net What: /sys/bus/usb/devices/-:./::./kovaplus/roccatkovaplus/profile_settings @@ -54,17 +44,6 @@ Description: The mouse can store 5 profiles which can be switched by the The mouse will reject invalid data. Which profile to write is determined by the profile number contained in the data. - This file is writeonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./kovaplus/roccatkovaplus/profile[1-5]_settings -Date: January 2011 -Contact: Stefan Achatz -Description: The mouse can store 5 profiles which can be switched by the - press of a button. A profile is split in settings and buttons. - profile_settings holds information like resolution, sensitivity - and light effects. - When read, these files return the respective profile settings. - The returned data is 16 bytes in size. - This file is readonly. + Before reading this file, control has to be written to select + which profile to read. Users:
[PATCH 5/7] HID: roccat: Deprecated some Pyra sysfs attributes
Introduced attribute "control" and made profile_settings and profile_buttons readable, which makes profile[1-5]_settings and profile[1-5]_buttons obsolete. Signed-off-by: Stefan Achatz --- .../ABI/obsolete/sysfs-driver-hid-roccat-pyra | 27 ++- .../ABI/testing/sysfs-driver-hid-roccat-pyra | 37 ++- drivers/hid/hid-roccat-pyra.c | 10 +++-- drivers/hid/hid-roccat-pyra.h |2 + 4 files changed, 46 insertions(+), 30 deletions(-) diff --git a/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-pyra b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-pyra index 0a661b3..87ac87e 100644 --- a/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-pyra +++ b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-pyra @@ -37,6 +37,31 @@ Description: When read, this file returns the raw integer version number of the Please use binary attribute "info" which provides this information. Users: http://roccat.sourceforge.net +What: /sys/bus/usb/devices/-:./::./pyra/roccatpyra/profile[1-5]_buttons +Date: August 2010 +Contact: Stefan Achatz +Description: The mouse can store 5 profiles which can be switched by the + press of a button. A profile is split in settings and buttons. + profile_buttons holds information about button layout. + When read, these files return the respective profile buttons. + The returned data is 19 bytes in size. + This file is readonly. + Write control to select profile and read profile_buttons instead. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./pyra/roccatpyra/profile[1-5]_settings +Date: August 2010 +Contact: Stefan Achatz +Description: The mouse can store 5 profiles which can be switched by the + press of a button. A profile is split in settings and buttons. + profile_settings holds information like resolution, sensitivity + and light effects. + When read, these files return the respective profile settings. + The returned data is 13 bytes in size. + This file is readonly. + Write control to select profile and read profile_settings instead. +Users: http://roccat.sourceforge.net + What: /sys/bus/usb/devices/-:./::./pyra/roccatpyra/startup_profile Date: August 2010 Contact: Stefan Achatz @@ -45,4 +70,4 @@ Description: The integer value of this attribute ranges from 0-4. that's active when the mouse is powered on. This file is readonly. Please use binary attribute "settings" which provides this information. -Users: http://roccat.sourceforge.net \ No newline at end of file +Users: http://roccat.sourceforge.net diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra b/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra index b0fab8b..6571d8e 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra @@ -1,3 +1,11 @@ +What: /sys/bus/usb/devices/-:./::./pyra/roccatpyra/info +Date: November 2012 +Contact: Stefan Achatz +Description: When read, this file returns general data like firmware version. + When written, the device can be reset. + The data is 6 bytes long. +Users: http://roccat.sourceforge.net + What: /sys/bus/usb/devices/-:./::./pyra/roccatpyra/profile_settings Date: August 2010 Contact: Stefan Achatz @@ -10,19 +18,8 @@ Description: The mouse can store 5 profiles which can be switched by the The mouse will reject invalid data. Which profile to write is determined by the profile number contained in the data. - This file is writeonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./pyra/roccatpyra/profile[1-5]_settings -Date: August 2010 -Contact: Stefan Achatz -Description: The mouse can store 5 profiles which can be switched by the - press of a button. A profile is split in settings and buttons. - profile_settings holds information like resolution, sensitivity - and light effects. - When read, these files return the respective profile settings. - The returned data is 13 bytes in size. - This file is readonly. + Before reading this file, control has to be written to select + which profile to read. Users: http://roccat.sourceforge.net What: /sys/bus/usb/devices/-:./::./pyra/roccatpyra/profile_buttons @@ -36,18 +33,8 @@ Description: The mouse can store 5 profiles which can be
Re: [RFC PATCH 1/6] driver core: add a bus notification to temporarily reject driver binding
On Sat, Nov 10, 2012 at 09:57:14PM +0800, Jiang Liu wrote: > From: Jiang Liu > > There are several requirements to temporarily reject device driver > binding. Possible usage cases as below: > 1) We should avoid binding an unsafe driver to a device belonging to >an active VFIO group, otherwise it will break the DMA isolation >property of VFIO. > 2) When hot-removing a PCI hierachy, we should avoid binding device >drivers to PCI devices going to be removed during the window >between unbinding of device driver and destroying of device nodes. > 3) When hot-adding a PCI host bridge, we should temporarily disable >driver binding before setting up corresponding IOMMU and IOAPIC. > > We may add a flag into struct device to temporarily disable driver > binding as in this thread https://patchwork.kernel.org/patch/1535721/. I totally do not understand. The bus controls this, if it does not want to bind a device to a driver, then don't do it. It's really quite simple to just block the probe callback the bus gets, right? Why create all of this extra, and confusing, interface instead? > This patch proposes another solution to temporarily disable driver > binding by using bus notification mechanisms. It adds an notification > event to solicit if anybody has objections when binding a driver to a > device. Sorry, but no, don't do this, it's way more confusing. 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 4/7] HID: roccat: Added bin sysfs attr "reset" for Isku
Isku needs an extra sysfs attr to support device reset.
Signed-off-by: Stefan Achatz
---
.../ABI/testing/sysfs-driver-hid-roccat-isku |8
drivers/hid/hid-roccat-isku.c |2 ++
drivers/hid/hid-roccat-isku.h |2 ++
3 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-isku
b/Documentation/ABI/testing/sysfs-driver-hid-roccat-isku
index 189dc43..9eca5a1 100644
--- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-isku
+++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-isku
@@ -117,6 +117,14 @@ Description: When written, this file lets one store
macros with max 500
which profile and key to read.
Users: http://roccat.sourceforge.net
+What: /sys/bus/usb/devices/-:./::./isku/roccatisku/reset
+Date: November 2012
+Contact: Stefan Achatz
+Description: When written, this file lets one reset the device.
+ The data has to be 3 bytes long.
+ This file is writeonly.
+Users: http://roccat.sourceforge.net
+
What: /sys/bus/usb/devices/-:./::./isku/roccatisku/control
Date: June 2011
Contact: Stefan Achatz
diff --git a/drivers/hid/hid-roccat-isku.c b/drivers/hid/hid-roccat-isku.c
index 020d6cd..1219998 100644
--- a/drivers/hid/hid-roccat-isku.c
+++ b/drivers/hid/hid-roccat-isku.c
@@ -218,6 +218,7 @@ ISKU_SYSFS_RW(last_set, LAST_SET)
ISKU_SYSFS_W(talk, TALK)
ISKU_SYSFS_R(info, INFO)
ISKU_SYSFS_W(control, CONTROL)
+ISKU_SYSFS_W(reset, RESET)
static struct bin_attribute isku_bin_attributes[] = {
ISKU_BIN_ATTR_RW(macro, MACRO),
@@ -233,6 +234,7 @@ static struct bin_attribute isku_bin_attributes[] = {
ISKU_BIN_ATTR_W(talk, TALK),
ISKU_BIN_ATTR_R(info, INFO),
ISKU_BIN_ATTR_W(control, CONTROL),
+ ISKU_BIN_ATTR_W(reset, RESET),
__ATTR_NULL
};
diff --git a/drivers/hid/hid-roccat-isku.h b/drivers/hid/hid-roccat-isku.h
index 0062ab5..cf6896c 100644
--- a/drivers/hid/hid-roccat-isku.h
+++ b/drivers/hid/hid-roccat-isku.h
@@ -27,6 +27,7 @@ enum {
ISKU_SIZE_LAST_SET = 0x14,
ISKU_SIZE_LIGHT = 0x0a,
ISKU_SIZE_MACRO = 0x823,
+ ISKU_SIZE_RESET = 0x03,
ISKU_SIZE_TALK = 0x10,
};
@@ -53,6 +54,7 @@ enum isku_commands {
ISKU_COMMAND_MACRO = 0xe,
ISKU_COMMAND_INFO = 0xf,
ISKU_COMMAND_LIGHT = 0x10,
+ ISKU_COMMAND_RESET = 0x11,
ISKU_COMMAND_KEYS_CAPSLOCK = 0x13,
ISKU_COMMAND_LAST_SET = 0x14,
ISKU_COMMAND_15 = 0x15,
--
1.7.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/7] HID: roccat: Deprecated some Koneplus sysfs attributes
Introduced attribute "control" and made profile_settings and profile_buttons readable, which makes profile[1-5]_settings and profile[1-5]_buttons obsolete. Signed-off-by: Stefan Achatz --- .../ABI/obsolete/sysfs-driver-hid-roccat-koneplus | 27 ++ .../ABI/testing/sysfs-driver-hid-roccat-koneplus | 29 +++- drivers/hid/hid-roccat-koneplus.c | 10 --- drivers/hid/hid-roccat-koneplus.h |2 + 4 files changed, 39 insertions(+), 29 deletions(-) diff --git a/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus index 22568b4..833fd59 100644 --- a/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus +++ b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus @@ -8,6 +8,7 @@ Description:The integer value of this attribute ranges from 0-4. When written, this file sets the number of the startup profile and the mouse activates this profile immediately. Please use actual_profile, it does the same thing. +Users: http://roccat.sourceforge.net What: /sys/bus/usb/devices/-:./::./koneplus/roccatkoneplus/firmware_version Date: October 2010 @@ -19,3 +20,29 @@ Description: When read, this file returns the raw integer version number of the left. E.g. a returned value of 121 means 1.21 This file is readonly. Please read binary attribute info which contains firmware version. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./koneplus/roccatkoneplus/profile[1-5]_buttons +Date: August 2010 +Contact: Stefan Achatz +Description: The mouse can store 5 profiles which can be switched by the + press of a button. A profile is split in settings and buttons. + profile_buttons holds information about button layout. + When read, these files return the respective profile buttons. + The returned data is 77 bytes in size. + This file is readonly. + Write control to select profile and read profile_buttons instead. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./koneplus/roccatkoneplus/profile[1-5]_settings +Date: August 2010 +Contact: Stefan Achatz +Description: The mouse can store 5 profiles which can be switched by the + press of a button. A profile is split in settings and buttons. + profile_settings holds information like resolution, sensitivity + and light effects. + When read, these files return the respective profile settings. + The returned data is 43 bytes in size. + This file is readonly. + Write control to select profile and read profile_settings instead. +Users: http://roccat.sourceforge.net \ No newline at end of file diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus b/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus index ed1213d..1a126ed 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus @@ -39,18 +39,8 @@ Description: The mouse can store 5 profiles which can be switched by the The mouse will reject invalid data. Which profile to write is determined by the profile number contained in the data. - This file is writeonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./koneplus/roccatkoneplus/profile[1-5]_buttons -Date: August 2010 -Contact: Stefan Achatz -Description: The mouse can store 5 profiles which can be switched by the - press of a button. A profile is split in settings and buttons. - profile_buttons holds information about button layout. - When read, these files return the respective profile buttons. - The returned data is 77 bytes in size. - This file is readonly. + Before reading this file, control has to be written to select + which profile to read. Users: http://roccat.sourceforge.net What: /sys/bus/usb/devices/-:./::./koneplus/roccatkoneplus/profile_settings @@ -65,19 +55,8 @@ Description: The mouse can store 5 profiles which can be switched by the The mouse will reject invalid data. Which profile to write is determined by the profile number contained in the data. - This file is writeonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./koneplus/roccatkoneplus/profile[1-5]_settings -Date: August 2010 -Contact: Stefan Achatz
[PATCH 2/7] HID: roccat: Cleanup of pyra module
Partially removed unneeded informations and data caching. Moved code nearer to format of newer drivers. Added "info" sysfs attribute to support device reset and deprecate "firmware_version" attribute. Signed-off-by: Stefan Achatz --- .../ABI/obsolete/sysfs-driver-hid-roccat-pyra | 48 +++ .../ABI/testing/sysfs-driver-hid-roccat-pyra | 45 --- drivers/hid/hid-roccat-pyra.c | 340 +--- drivers/hid/hid-roccat-pyra.h | 22 +- 4 files changed, 198 insertions(+), 257 deletions(-) create mode 100644 Documentation/ABI/obsolete/sysfs-driver-hid-roccat-pyra diff --git a/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-pyra b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-pyra new file mode 100644 index 000..0a661b3 --- /dev/null +++ b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-pyra @@ -0,0 +1,48 @@ +What: /sys/bus/usb/devices/-:./::./pyra/roccatpyra/actual_cpi +Date: August 2010 +Contact: Stefan Achatz +Description: It is possible to switch the cpi setting of the mouse with the + press of a button. + When read, this file returns the raw number of the actual cpi + setting reported by the mouse. This number has to be further + processed to receive the real dpi value. + + VALUE DPI + 1 400 + 2 800 + 4 1600 + + This file is readonly. + Has never been used. If bookkeeping is done, it's done in userland tools. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./pyra/roccatpyra/actual_profile +Date: August 2010 +Contact: Stefan Achatz +Description: When read, this file returns the number of the actual profile in + range 0-4. + This file is readonly. + Please use binary attribute "settings" which provides this information. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./pyra/roccatpyra/firmware_version +Date: August 2010 +Contact: Stefan Achatz +Description: When read, this file returns the raw integer version number of the + firmware reported by the mouse. Using the integer value eases + further usage in other programs. To receive the real version + number the decimal point has to be shifted 2 positions to the + left. E.g. a returned value of 138 means 1.38 + This file is readonly. + Please use binary attribute "info" which provides this information. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./pyra/roccatpyra/startup_profile +Date: August 2010 +Contact: Stefan Achatz +Description: The integer value of this attribute ranges from 0-4. +When read, this attribute returns the number of the profile +that's active when the mouse is powered on. + This file is readonly. + Please use binary attribute "settings" which provides this information. +Users: http://roccat.sourceforge.net \ No newline at end of file diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra b/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra index 3f8de50..b0fab8b 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra @@ -1,39 +1,3 @@ -What: /sys/bus/usb/devices/-:./::./pyra/roccatpyra/actual_cpi -Date: August 2010 -Contact: Stefan Achatz -Description: It is possible to switch the cpi setting of the mouse with the - press of a button. - When read, this file returns the raw number of the actual cpi - setting reported by the mouse. This number has to be further - processed to receive the real dpi value. - - VALUE DPI - 1 400 - 2 800 - 4 1600 - - This file is readonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./pyra/roccatpyra/actual_profile -Date: August 2010 -Contact: Stefan Achatz -Description: When read, this file returns the number of the actual profile in - range 0-4. - This file is readonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./pyra/roccatpyra/firmware_version -Date: August 2010 -Contact: Stefan Achatz -Description: When read, this file returns the raw integer version number of the - firmware reported by the mouse. Using the integer value eases - further usage in other programs. To receive the real version - number the decimal point has to
[PATCH 3/7] HID: roccat: Cleaned up isku driver
Removed unneeded structures from header.
Using enums instead of sizeof(struct) to unify drivers.
Signed-off-by: Stefan Achatz
---
drivers/hid/hid-roccat-isku.c | 42 +++---
drivers/hid/hid-roccat-isku.h | 76 +
2 files changed, 37 insertions(+), 81 deletions(-)
diff --git a/drivers/hid/hid-roccat-isku.c b/drivers/hid/hid-roccat-isku.c
index 5669916..020d6cd 100644
--- a/drivers/hid/hid-roccat-isku.c
+++ b/drivers/hid/hid-roccat-isku.c
@@ -167,7 +167,7 @@ static ssize_t isku_sysfs_write_ ## thingy(struct file *fp,
struct kobject *kobj
loff_t off, size_t count) \
{ \
return isku_sysfs_write(fp, kobj, buf, off, count, \
- sizeof(struct isku_ ## thingy), ISKU_COMMAND_ ##
THINGY); \
+ ISKU_SIZE_ ## THINGY, ISKU_COMMAND_ ## THINGY); \
}
#define ISKU_SYSFS_R(thingy, THINGY) \
@@ -176,32 +176,32 @@ static ssize_t isku_sysfs_read_ ## thingy(struct file
*fp, struct kobject *kobj,
loff_t off, size_t count) \
{ \
return isku_sysfs_read(fp, kobj, buf, off, count, \
- sizeof(struct isku_ ## thingy), ISKU_COMMAND_ ##
THINGY); \
+ ISKU_SIZE_ ## THINGY, ISKU_COMMAND_ ## THINGY); \
}
#define ISKU_SYSFS_RW(thingy, THINGY) \
ISKU_SYSFS_R(thingy, THINGY) \
ISKU_SYSFS_W(thingy, THINGY)
-#define ISKU_BIN_ATTR_RW(thingy) \
+#define ISKU_BIN_ATTR_RW(thingy, THINGY) \
{ \
.attr = { .name = #thingy, .mode = 0660 }, \
- .size = sizeof(struct isku_ ## thingy), \
+ .size = ISKU_SIZE_ ## THINGY, \
.read = isku_sysfs_read_ ## thingy, \
.write = isku_sysfs_write_ ## thingy \
}
-#define ISKU_BIN_ATTR_R(thingy) \
+#define ISKU_BIN_ATTR_R(thingy, THINGY) \
{ \
.attr = { .name = #thingy, .mode = 0440 }, \
- .size = sizeof(struct isku_ ## thingy), \
+ .size = ISKU_SIZE_ ## THINGY, \
.read = isku_sysfs_read_ ## thingy, \
}
-#define ISKU_BIN_ATTR_W(thingy) \
+#define ISKU_BIN_ATTR_W(thingy, THINGY) \
{ \
.attr = { .name = #thingy, .mode = 0220 }, \
- .size = sizeof(struct isku_ ## thingy), \
+ .size = ISKU_SIZE_ ## THINGY, \
.write = isku_sysfs_write_ ## thingy \
}
@@ -220,19 +220,19 @@ ISKU_SYSFS_R(info, INFO)
ISKU_SYSFS_W(control, CONTROL)
static struct bin_attribute isku_bin_attributes[] = {
- ISKU_BIN_ATTR_RW(macro),
- ISKU_BIN_ATTR_RW(keys_function),
- ISKU_BIN_ATTR_RW(keys_easyzone),
- ISKU_BIN_ATTR_RW(keys_media),
- ISKU_BIN_ATTR_RW(keys_thumbster),
- ISKU_BIN_ATTR_RW(keys_macro),
- ISKU_BIN_ATTR_RW(keys_capslock),
- ISKU_BIN_ATTR_RW(light),
- ISKU_BIN_ATTR_RW(key_mask),
- ISKU_BIN_ATTR_RW(last_set),
- ISKU_BIN_ATTR_W(talk),
- ISKU_BIN_ATTR_R(info),
- ISKU_BIN_ATTR_W(control),
+ ISKU_BIN_ATTR_RW(macro, MACRO),
+ ISKU_BIN_ATTR_RW(keys_function, KEYS_FUNCTION),
+ ISKU_BIN_ATTR_RW(keys_easyzone, KEYS_EASYZONE),
+ ISKU_BIN_ATTR_RW(keys_media, KEYS_MEDIA),
+ ISKU_BIN_ATTR_RW(keys_thumbster, KEYS_THUMBSTER),
+ ISKU_BIN_ATTR_RW(keys_macro, KEYS_MACRO),
+ ISKU_BIN_ATTR_RW(keys_capslock, KEYS_CAPSLOCK),
+ ISKU_BIN_ATTR_RW(light, LIGHT),
+ ISKU_BIN_ATTR_RW(key_mask, KEY_MASK),
+ ISKU_BIN_ATTR_RW(last_set, LAST_SET),
+ ISKU_BIN_ATTR_W(talk, TALK),
+ ISKU_BIN_ATTR_R(info, INFO),
+ ISKU_BIN_ATTR_W(control, CONTROL),
__ATTR_NULL
};
diff --git a/drivers/hid/hid-roccat-isku.h b/drivers/hid/hid-roccat-isku.h
index 605b3ce..0062ab5 100644
--- a/drivers/hid/hid-roccat-isku.h
+++ b/drivers/hid/hid-roccat-isku.h
@@ -15,76 +15,32 @@
#include
enum {
+ ISKU_SIZE_CONTROL = 0x03,
+ ISKU_SIZE_INFO = 0x06,
+ ISKU_SIZE_KEY_MASK = 0x06,
+ ISKU_SIZE_KEYS_FUNCTION = 0x29,
+ ISKU_SIZE_KEYS_EASYZONE = 0x41,
+ ISKU_SIZE_KEYS_MEDIA = 0x1d,
+ ISKU_SIZE_KEYS_THUMBSTER = 0x17,
+ ISKU_SIZE_KEYS_MACRO = 0x23,
+ ISKU_SIZE_KEYS_CAPSLOCK = 0x06,
+ ISKU_SIZE_LAST_SET = 0x14,
+ ISKU_SIZE_LIGHT = 0x0a,
+ ISKU_SIZE_MACRO = 0x823,
+ ISKU_SIZE_TALK = 0x10,
+};
+
+enum {
ISKU_PROFILE_NUM = 5,
ISKU_USB_INTERFACE_PROTOCOL = 0,
};
-struct isku_control {
- uint8_t command; /* ISKU_COMMAND_CONTROL */
- uint8_t value;
- uint8_t request;
-} __packed;
-
struct isku_actual_profile {
uint8_t command; /* ISKU_COMMAND_ACTUAL_PROFILE */
uint8_t size; /* always 3 */
uint8_t actual_profile;
} __packed;
-struct isku_key_mask {
- uint8_t command; /* ISKU_COMMAND_KEY_MASK */
- uint8_t size; /* 6 */
- uint8_t profile_number; /* 0-4 */
- uint8_t mask;
- uint16_t checksum;
-} __packed;
-
-struct isku_keys_function {
- uint8_t data[0x29];
-} __packed;
-
-struct isku_keys_easyzone {
- uint8_t data[0x41];
-} __packed;
-
-struct
[PATCH 0/7] HID: roccat: Finishing cleanup and reset support
This patchset finishes current cleanups and unifications. Device reset is now implemented for all devices that support that feature. A couple sysfs attributes have been deprecated and got replaced to unify the ABI as good as it gets with design decisions made in the past. The next release of userland tools will only use these obsolete attributes as fallback. When that version is out, I will add all actual sysfs attributes from ABI/obsolete/sysfs-driver-hid-roccat-* to feature-removal-schedule.txt. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH Resend V2] dt: add helper function to read u8 & u16 variables & arrays
Ping!!
On 7 November 2012 09:52, viresh kumar wrote:
> On Tue, Nov 6, 2012 at 7:48 PM, Rob Herring wrote:
>>> +#define of_property_read_array(_np, _pname, _out, _sz)
>>> \
>
>>> + while (_sz--) \
>>> + *_out++ = (typeof(*_out))be32_to_cpup(_val++); \
>
>> This will not work. You are incrementing _out by 1, 2, or 4 bytes, but
>> _val is always incremented by 4 bytes.
>>
>> According to the dtc commit adding this feature, the values are packed:
>>
>> With this patch the following property assignment:
>>
>> property = /bits/ 16 <0x1234 0x5678 0x0 0x>;
>>
>> is equivalent to:
>>
>> property = <0x12345678 0x>;
>
> I thought of it a bit more and wasn't actually aligned with your explanation
> :(
>
> If that is the case, how will current implementation of u32 array will work
> if we pass something like: 0x88 0x8400 0x5890 from DT?
>
> So, i did a dummy test of my current implementation, with following changes
> in one of my drivers:
>
> dts changes:
>
> cluster0: cluster@0 {
> + data1 = <0x50 0x60 0x70>;
> + data2 = <0x5000 0x6000 0x7000>;
> + data3 = <0x5000 0x6000 0x7000>;
>}
>
> driver changes:
>
> +void test(struct device_node *cluster)
> +{
> + u8 data1[3];
> + u16 data2[3];
> + u32 data3[3], i;
> +
> + of_property_read_u8_array(cluster, "data1", data1, 3);
> + of_property_read_u16_array(cluster, "data2", data2, 3);
> + of_property_read_u32_array(cluster, "data3", data3, 3);
> +
> + for (i = 0; i < 3; i++) {
> + printk(KERN_INFO "u8 %d: %x\n", i, data1[i]);
> + printk(KERN_INFO "u16 %d: %x\n", i, data2[i]);
> + printk(KERN_INFO "u32 %d: %x\n", i, data3[i]);
> + }
> +}
>
> And following is the output
>
> [4.087205] u8 0: 50
> [4.093746] u16 0: 5000
> [4.101067] u32 0: 5000
> [4.109512] u8 1: 60
> [4.116036] u16 1: 6000
> [4.123357] u32 1: 6000
> [4.131718] u8 2: 70
> [4.138241] u16 2: 7000
> [4.145573] u32 2: 7000
>
> which looks to be what we were looking for, isn't it?
>
> Following is fixup for the doc comment missing:
>
> commit 00803aed0781de451048df0d15a3e8c814a343c8
> Author: Viresh Kumar
> Date: Wed Nov 7 09:48:46 2012 +0530
>
> fixup! dt: add helper function to read u8 & u16 variables & arrays
> ---
> drivers/of/base.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index fbb634b..4a6632e 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -669,6 +669,7 @@ EXPORT_SYMBOL(of_find_node_by_phandle);
> * @np:device node from which the property value is to be
> read.
> * @propname: name of the property to be searched.
> * @out_value: pointer to return value, modified only if return value is 0.
> + * @sz:number of array elements to read
> *
> * Search for a property in a device node and read 8-bit value(s) from
> * it. Returns 0 on success, -EINVAL if the property does not exist,
> @@ -690,6 +691,7 @@ EXPORT_SYMBOL_GPL(of_property_read_u8_array);
> * @np:device node from which the property value is to be
> read.
> * @propname: name of the property to be searched.
> * @out_value: pointer to return value, modified only if return value is 0.
> + * @sz:number of array elements to read
> *
> * Search for a property in a device node and read 16-bit value(s) from
> * it. Returns 0 on success, -EINVAL if the property does not exist,
> @@ -712,6 +714,7 @@ EXPORT_SYMBOL_GPL(of_property_read_u16_array);
> * @np:device node from which the property value is to be
> read.
> * @propname: name of the property to be searched.
> * @out_value: pointer to return value, modified only if return value is 0.
> + * @sz:number of array elements to read
> *
> * Search for a property in a device node and read 32-bit value(s) from
> * it. Returns 0 on success, -EINVAL if the property does not exist,
>
> ___
> linaro-dev mailing list
> linaro-...@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
--
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] target: Update copyright ownership to 2012
On Sat, 2012-11-10 at 16:18 -0800, Kyle Moffett wrote: > On Fri, Nov 9, 2012 at 3:00 PM, Nicholas A. Bellinger > wrote: > > This patch to update copyright year to current for principal target core > > ownership is now being pushed into target-pending/for-next. > > Pardon me, but you were just publicly accused of violating the GPL, so > your response is to send a patch removing the copyright notices of all > other organizations from the SCSI-target code? Have you obtained > ownership of all the relevant copyrights for Linux-iSCSI.org, PyX > Technologies, Inc, and SBE, Inc? I understand and appreciate your concerns. To answer your question, we have rightfully obtained ownership of all relevant copyrights to the target code for PyX Technologies LLC, and SBEi, Inc. I co-founded PyX in 2002, where we started the development of the target code. PyX was subsequently acquired by SBEi in 2005. In 2007, I purchased (at significant personal cost) all rights, title and interest (incl. the copyright) in the target code. I then co-founded RisingTide with this code in 2009. Linux-iSCSI.org is only a URL and website that is owned by RisingTide Systems, and not a legal entity or person, so listing it as a copyright holder is meaningless. > If not, then this patch is an > attempted violation of those organizations copyrights and of the GPL > (which requires that you preserve copyright notices). > > Further, while these notices are the only ones listed in those files, > they are not the only individuals outside of RisingTide Systems which > have significant copyright interest in this code. > > If your goal is to > obtain exclusive copyright ownership over this code then there are a > great many other people you must contact and convince first. > The goal is to update the copyright to the current year, and to remove legal entities that no longer exist or were meaningless. I hope this clarifies your concerns. Thank you, --nab -- 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] pinctrl: spear: Staticize non-exported symbols
On Sun, Nov 11, 2012 at 7:59 AM, Axel Lin wrote:
> They are not referenced outside of this file, make them static.
>
> Signed-off-by: Axel Lin
> ---
> drivers/pinctrl/spear/pinctrl-spear.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pinctrl/spear/pinctrl-spear.c
> b/drivers/pinctrl/spear/pinctrl-spear.c
> index b1fd6ee..9a4dd4e 100644
> --- a/drivers/pinctrl/spear/pinctrl-spear.c
> +++ b/drivers/pinctrl/spear/pinctrl-spear.c
> @@ -121,9 +121,10 @@ static void spear_pinctrl_pin_dbg_show(struct
> pinctrl_dev *pctldev,
> seq_printf(s, " " DRIVER_NAME);
> }
>
> -int spear_pinctrl_dt_node_to_map(struct pinctrl_dev *pctldev,
> -struct device_node *np_config,
> -struct pinctrl_map **map, unsigned *num_maps)
> +static int spear_pinctrl_dt_node_to_map(struct pinctrl_dev *pctldev,
> + struct device_node *np_config,
> + struct pinctrl_map **map,
> + unsigned *num_maps)
> {
> struct spear_pmx *pmx = pinctrl_dev_get_drvdata(pctldev);
> struct device_node *np;
> @@ -168,8 +169,9 @@ int spear_pinctrl_dt_node_to_map(struct pinctrl_dev
> *pctldev,
> return 0;
> }
>
> -void spear_pinctrl_dt_free_map(struct pinctrl_dev *pctldev,
> - struct pinctrl_map *map, unsigned num_maps)
> +static void spear_pinctrl_dt_free_map(struct pinctrl_dev *pctldev,
> + struct pinctrl_map *map,
> + unsigned num_maps)
> {
> kfree(map);
> }
Acked-by: Viresh Kumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] mm: Export a function to read vm_committed_as
On Sat, 10 Nov 2012, K. Y. Srinivasan wrote:
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 2d94235..e527239 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -89,6 +89,17 @@ int sysctl_max_map_count __read_mostly =
> DEFAULT_MAX_MAP_COUNT;
> struct percpu_counter vm_committed_as cacheline_aligned_in_smp;
>
> /*
> + * A wrapper to read vm_committed_as that can be used by external modules.
> + */
> +
> +unsigned long read_vm_committed_as(void)
> +{
> + return percpu_counter_read_positive(_committed_as);
> +}
> +
> +EXPORT_SYMBOL_GPL(read_vm_committed_as);
> +
> +/*
> * Check that a process has enough memory to allocate a new virtual
> * mapping. 0 means there is enough memory for the allocation to
> * succeed and -ENOMEM implies there is not.
This is precisely what I didn't want to see; I was expecting that this
function was going to have some name that would describe what a hypervisor
would use it for, regardless of its implementation and current use of
vm_committed_as. read_vm_committed_as() misses the entire point of the
suggestion and a few people have mentioned that they think this
implementation will evolve over time.
Please think of what you're trying to determine in the code that will
depend on this and then convert the existing user in
drivers/xen/xen-selfballoon.c.
--
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] dt/platform: Use cell-index for device naming if available
On 11/09/2012 06:48 PM, Stepan Moskovchenko wrote:
> Use the cell-index property to construct names for platform
> devices, falling back on the existing scheme of using the
> device register address if cell-index is not specified.
>
> The cell-index property is a more useful device identifier,
> especially in systems containing several numbered instances
> of a particular hardware block, since it more easily
> illustrates how devices relate to each other.
>
> Additionally, userspace software may rely on the classic
> . naming scheme to access device attributes in
> sysfs, without having to know the physical addresses of
> that device on every platform the userspace software may
> support. Using cell-index for device naming allows the
> device addresses to be hidden from userspace and to be
> exposed by logical device number without having to rely on
> auxdata to perform name overrides. This allows userspace to
> make assumptions about which sysfs nodes map to which
> logical instance of a specific hardware block.
>
> Signed-off-by: Stepan Moskovchenko
> ---
> I had also considered using something like the linux,label property to allow
> custom names for platform devices without resorting to auxdata, but the
> cell-index approach seems more in line with what cell-index was intended for
> and with what the pre-DT platform device naming scheme used to be. Please let
> me know if you think there is a better way to accomplish this.
>
> This is just being sent out as an RFC for now. If there are no objections, I
> will send this out as an official patch, along with (or combined with) a patch
> to fix up the device names in things like clock tables of any affected
> platforms.
cell-index is basically deprecated. This has been discussed multiple
times in the past. You can use auxdata if you really need to have the
old name.
Rob
>
> drivers/of/platform.c | 13 -
> 1 files changed, 12 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index 343ad29..472e374 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -77,8 +77,9 @@ void of_device_make_bus_id(struct device *dev)
> static atomic_t bus_no_reg_magic;
> struct device_node *node = dev->of_node;
> const u32 *reg;
> + u32 cell_index;
> u64 addr;
> - int magic;
> + int magic, ret;
>
> #ifdef CONFIG_PPC_DCR
> /*
> @@ -101,6 +102,16 @@ void of_device_make_bus_id(struct device *dev)
> #endif /* CONFIG_PPC_DCR */
>
> /*
> + * For devices with a specified cell-index, use the traditional
> + * naming scheme of .
> + */
> + ret = of_property_read_u32(node, "cell-index", _index);
> + if (ret == 0) {
> + dev_set_name(dev, "%s.%d", node->name, cell_index);
> + return;
> + }
> +
> + /*
>* For MMIO, get the physical address
>*/
> reg = of_get_property(node, "reg", NULL);
> --
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
>
--
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] pinctrl: tegra: Staticize non-exported symbols
They are not referenced outside of this file, make them static.
Signed-off-by: Axel Lin
---
drivers/pinctrl/pinctrl-tegra.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-tegra.c b/drivers/pinctrl/pinctrl-tegra.c
index 7da0b37..4dfa902 100644
--- a/drivers/pinctrl/pinctrl-tegra.c
+++ b/drivers/pinctrl/pinctrl-tegra.c
@@ -178,8 +178,9 @@ static int add_config(struct device *dev, unsigned long
**configs,
return 0;
}
-void tegra_pinctrl_dt_free_map(struct pinctrl_dev *pctldev,
- struct pinctrl_map *map, unsigned num_maps)
+static void tegra_pinctrl_dt_free_map(struct pinctrl_dev *pctldev,
+ struct pinctrl_map *map,
+ unsigned num_maps)
{
int i;
@@ -209,11 +210,11 @@ static const struct cfg_param {
{"nvidia,slew-rate-rising", TEGRA_PINCONF_PARAM_SLEW_RATE_RISING},
};
-int tegra_pinctrl_dt_subnode_to_map(struct device *dev,
- struct device_node *np,
- struct pinctrl_map **map,
- unsigned *reserved_maps,
- unsigned *num_maps)
+static int tegra_pinctrl_dt_subnode_to_map(struct device *dev,
+ struct device_node *np,
+ struct pinctrl_map **map,
+ unsigned *reserved_maps,
+ unsigned *num_maps)
{
int ret, i;
const char *function;
@@ -288,9 +289,10 @@ exit:
return ret;
}
-int tegra_pinctrl_dt_node_to_map(struct pinctrl_dev *pctldev,
-struct device_node *np_config,
-struct pinctrl_map **map, unsigned *num_maps)
+static int tegra_pinctrl_dt_node_to_map(struct pinctrl_dev *pctldev,
+ struct device_node *np_config,
+ struct pinctrl_map **map,
+ unsigned *num_maps)
{
unsigned reserved_maps;
struct device_node *np;
--
1.7.9.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] pinctrl: spear: Staticize non-exported symbols
They are not referenced outside of this file, make them static.
Signed-off-by: Axel Lin
---
drivers/pinctrl/spear/pinctrl-spear.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/pinctrl/spear/pinctrl-spear.c
b/drivers/pinctrl/spear/pinctrl-spear.c
index b1fd6ee..9a4dd4e 100644
--- a/drivers/pinctrl/spear/pinctrl-spear.c
+++ b/drivers/pinctrl/spear/pinctrl-spear.c
@@ -121,9 +121,10 @@ static void spear_pinctrl_pin_dbg_show(struct pinctrl_dev
*pctldev,
seq_printf(s, " " DRIVER_NAME);
}
-int spear_pinctrl_dt_node_to_map(struct pinctrl_dev *pctldev,
-struct device_node *np_config,
-struct pinctrl_map **map, unsigned *num_maps)
+static int spear_pinctrl_dt_node_to_map(struct pinctrl_dev *pctldev,
+ struct device_node *np_config,
+ struct pinctrl_map **map,
+ unsigned *num_maps)
{
struct spear_pmx *pmx = pinctrl_dev_get_drvdata(pctldev);
struct device_node *np;
@@ -168,8 +169,9 @@ int spear_pinctrl_dt_node_to_map(struct pinctrl_dev
*pctldev,
return 0;
}
-void spear_pinctrl_dt_free_map(struct pinctrl_dev *pctldev,
- struct pinctrl_map *map, unsigned num_maps)
+static void spear_pinctrl_dt_free_map(struct pinctrl_dev *pctldev,
+ struct pinctrl_map *map,
+ unsigned num_maps)
{
kfree(map);
}
--
1.7.9.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 2/2] pinctrl: mxs: Make PINCTRL_MXS select PINMUX && PINCONF
Then we can remove "select PINMUX && PINCONF" from PINCTRL_IMX{23,28}.
This simplifies the dependency.
Signed-off-by: Axel Lin
---
drivers/pinctrl/Kconfig |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index fc0f49a..d5c9431 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -99,18 +99,16 @@ config PINCTRL_MMP2
select PINCONF
config PINCTRL_MXS
+ select PINMUX
+ select PINCONF
bool
config PINCTRL_IMX23
bool
- select PINMUX
- select PINCONF
select PINCTRL_MXS
config PINCTRL_IMX28
bool
- select PINMUX
- select PINCONF
select PINCTRL_MXS
config PINCTRL_NOMADIK
--
1.7.9.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 1/2] pinctrl: tegra: Make PINCTRL_TEGRA select PINMUX && PINCONF
Then we can remove "select PINMUX && PINCONF" from PINCTRL_TEGRA{20,30}.
This simplifies the dependency.
Signed-off-by: Axel Lin
---
drivers/pinctrl/Kconfig |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 6d5a50b..fc0f49a 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -157,18 +157,16 @@ config PINCTRL_SIRF
select PINMUX
config PINCTRL_TEGRA
+ select PINMUX
+ select PINCONF
bool
config PINCTRL_TEGRA20
bool
- select PINMUX
- select PINCONF
select PINCTRL_TEGRA
config PINCTRL_TEGRA30
bool
- select PINMUX
- select PINCONF
select PINCTRL_TEGRA
config PINCTRL_U300
--
1.7.9.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 1/1] mm: Export a function to read vm_committed_as
It may be useful to be able to access vm_committed_as from device
drivers. On the Hyper-V platform, the host has a policy engine to balance
the available physical memory amongst all competing virtual machines
hosted on a given node. This policy engine is driven by a number of metrics
including the memory pressure reported by the guests. The balloon driver
for Linux on Hyper-V uses this function to report memory pressure back to
the host.
Signed-off-by: K. Y. Srinivasan
---
include/linux/mman.h |2 ++
mm/mmap.c| 11 +++
mm/nommu.c | 11 +++
3 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/include/linux/mman.h b/include/linux/mman.h
index d09dde1..d53dc3d 100644
--- a/include/linux/mman.h
+++ b/include/linux/mman.h
@@ -11,6 +11,8 @@ extern int sysctl_overcommit_memory;
extern int sysctl_overcommit_ratio;
extern struct percpu_counter vm_committed_as;
+unsigned long read_vm_committed_as(void);
+
static inline void vm_acct_memory(long pages)
{
percpu_counter_add(_committed_as, pages);
diff --git a/mm/mmap.c b/mm/mmap.c
index 2d94235..e527239 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -89,6 +89,17 @@ int sysctl_max_map_count __read_mostly =
DEFAULT_MAX_MAP_COUNT;
struct percpu_counter vm_committed_as cacheline_aligned_in_smp;
/*
+ * A wrapper to read vm_committed_as that can be used by external modules.
+ */
+
+unsigned long read_vm_committed_as(void)
+{
+ return percpu_counter_read_positive(_committed_as);
+}
+
+EXPORT_SYMBOL_GPL(read_vm_committed_as);
+
+/*
* Check that a process has enough memory to allocate a new virtual
* mapping. 0 means there is enough memory for the allocation to
* succeed and -ENOMEM implies there is not.
diff --git a/mm/nommu.c b/mm/nommu.c
index 45131b4..dbbd0aa 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -66,6 +66,17 @@ int heap_stack_gap = 0;
atomic_long_t mmap_pages_allocated;
+/*
+ * A wrapper to read vm_committed_as that can be used by external modules.
+ */
+
+unsigned long read_vm_committed_as(void)
+{
+ return percpu_counter_read_positive(_committed_as);
+}
+
+EXPORT_SYMBOL_GPL(read_vm_committed_as);
+
EXPORT_SYMBOL(mem_map);
EXPORT_SYMBOL(num_physpages);
--
1.7.4.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 usb-linus] USB: keyspan: fix typo causing GPF on open
Bjørn:
I patched keyspan.c using your below supplied diff in 3.6.6 (I'm not
using git.) The patch WORKS for me. (I tested using minicom and the
two programs that usually access the Keyspan serial device.)
Thank you for the quick fix.
Will this show up in 3.6.7?
Richard
richj...@pacbell.net
On 11/10/2012 01:13 AM, Bjørn Mork wrote:
> Commit f79b2d0f (USB: keyspan: fix NULL-pointer dereferences and
> memory leaks) had a small typo which made the driver use wrong
> offsets when mapping serial port private data. This results in
> in a GPF when the port is opened.
>
> Reported-by: Richard
> Cc:
> Cc: Johan Hovold
> Signed-off-by: Bjørn Mork
> ---
> Hello Richard,
>
> I wonder if you are able to test and verify this? I do not guarantee
> that there aren't other issues around, but this small typo looked like
> an obvious killer...
>
> Bjørn
>
> drivers/usb/serial/keyspan.c |3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/usb/serial/keyspan.c b/drivers/usb/serial/keyspan.c
> index 7179b0c..cff8dd5 100644
> --- a/drivers/usb/serial/keyspan.c
> +++ b/drivers/usb/serial/keyspan.c
> @@ -2430,7 +2430,7 @@ static void keyspan_release(struct usb_serial *serial)
> static int keyspan_port_probe(struct usb_serial_port *port)
> {
> struct usb_serial *serial = port->serial;
> - struct keyspan_port_private *s_priv;
> + struct keyspan_serial_private *s_priv;
> struct keyspan_port_private *p_priv;
> const struct keyspan_device_details *d_details;
> struct callbacks *cback;
> @@ -2445,7 +2445,6 @@ static int keyspan_port_probe(struct usb_serial_port
> *port)
> if (!p_priv)
> return -ENOMEM;
>
> - s_priv = usb_get_serial_data(port->serial);
> p_priv->device_details = d_details;
>
> /* Setup values for the various callback routines */
>
--
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: [REGRESSION] 3.7-rc3+git hard lockup on CPU after inserting/removing USB stick
> The first bad commit is:
>
> commit 73d4066055e0e2830533041f4b91df8e6e5976ff
> Author: Chuansheng Liu
> Date: Tue Sep 11 16:00:30 2012 +0800
>
> USB/host: Cleanup unneccessary irq disable code
>
> Because the IRQF_DISABLED as the flag is now a NOOP and has been
> deprecated and in hardirq context the interrupt is disabled.
>
> so in usb/host code:
> Removing the usage of flag IRQF_DISABLED;
> Removing the calling local_irq save/restore actions in irq
> handler usb_hcd_irq();
>
> Signed-off-by: liu chuansheng
> Acked-by: Alan Stern
> Signed-off-by: Greg Kroah-Hartman
>
>
> But:
>
> This ony happens with threadirqs option!
>
> When I remove threadirqs from kernel command line and reboot with this
> last bisect kernel USB sticks work.
>
> That may explain why nobody else has seen this.
>
> So I will try a 3.7-rc4 now, but without threadirqs enabled.
>
Thanks your pointing out, the USB HCD irq handler is designed to execute in irq
handler with irq disabled.
When threadirqs is in commandline, it will be executed in thread context with
local irq enabling, which causes
this hardlockup.
I prepared one patch, could you have time to test it? Thanks. Sorry for missing
threadirqs case.
From: liu chuansheng
Subject: [PATCH] USB/host: Mark USB HCD irq as non-threaded
Mark USB HCD irq as non-threaded. This prevent one crash/hard lockup
when "threadirqs" is on the kernel commandline.
And this interrupt handle is handling critial events which should not
be in thread context.
Signed-off-by: liu chuansheng
---
drivers/usb/core/hcd.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 1e741bc..b1cd46e 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2349,7 +2349,7 @@ static int usb_hcd_request_irqs(struct usb_hcd *hcd,
if (hcd->driver->irq) {
snprintf(hcd->irq_descr, sizeof(hcd->irq_descr), "%s:usb%d",
hcd->driver->description, hcd->self.busnum);
- retval = request_irq(irqnum, _hcd_irq, irqflags,
+ retval = request_irq(irqnum, _hcd_irq,
irqflags|IRQF_NO_THREAD,
hcd->irq_descr, hcd);
if (retval != 0) {
dev_err(hcd->self.controller,
--
1.7.0.4
Re: [PATCH] target: Update copyright ownership to 2012
On Fri, Nov 9, 2012 at 3:00 PM, Nicholas A. Bellinger wrote: > This patch to update copyright year to current for principal target core > ownership is now being pushed into target-pending/for-next. Pardon me, but you were just publicly accused of violating the GPL, so your response is to send a patch removing the copyright notices of all other organizations from the SCSI-target code? Have you obtained ownership of all the relevant copyrights for Linux-iSCSI.org, PyX Technologies, Inc, and SBE, Inc? If not, then this patch is an attempted violation of those organizations copyrights and of the GPL (which requires that you preserve copyright notices). Further, while these notices are the only ones listed in those files, they are not the only individuals outside of RisingTide Systems which have significant copyright interest in this code. If your goal is to obtain exclusive copyright ownership over this code then there are a great many other people you must contact and convince first. I would encourage you to talk privately with the Software Freedom Conservancy before sending more patches of this nature. Cheers, Kyle Moffett > diff --git a/drivers/target/target_core_alua.c > b/drivers/target/target_core_alua.c > - * Copyright (c) 2009-2010 Linux-iSCSI.org > diff --git a/drivers/target/target_core_configfs.c > b/drivers/target/target_core_configfs.c > - * Copyright (c) 2008-2011 Linux-iSCSI.org > diff --git a/drivers/target/target_core_device.c > b/drivers/target/target_core_device.c > - * Copyright (c) 2003, 2004, 2005 PyX Technologies, Inc. > - * Copyright (c) 2005-2006 SBE, Inc. All Rights Reserved. > - * Copyright (c) 2008-2010 Linux-iSCSI.org > diff --git a/drivers/target/target_core_fabric_configfs.c > b/drivers/target/target_core_fabric_configfs.c > - * Copyright (c) 2010,2011 Linux-iSCSI.org > diff --git a/drivers/target/target_core_fabric_lib.c > b/drivers/target/target_core_fabric_lib.c > - * Copyright (c) 2010 Linux-iSCSI.org > diff --git a/drivers/target/target_core_file.c > b/drivers/target/target_core_file.c > - * Copyright (c) 2005 PyX Technologies, Inc. > - * Copyright (c) 2005-2006 SBE, Inc. All Rights Reserved. > - * Copyright (c) 2008-2010 Linux-iSCSI.org > diff --git a/drivers/target/target_core_hba.c > b/drivers/target/target_core_hba.c > - * Copyright (c) 2003, 2004, 2005 PyX Technologies, Inc. > - * Copyright (c) 2005, 2006, 2007 SBE, Inc. > - * Copyright (c) 2008-2010 Linux-iSCSI.org > diff --git a/drivers/target/target_core_iblock.c > b/drivers/target/target_core_iblock.c > - * Copyright (c) 2003, 2004, 2005 PyX Technologies, Inc. > - * Copyright (c) 2005, 2006, 2007 SBE, Inc. > - * Copyright (c) 2008-2010 Linux-iSCSI.org > diff --git a/drivers/target/target_core_pr.c b/drivers/target/target_core_pr.c > - * Copyright (c) 2009, 2010 Linux-iSCSI.org > diff --git a/drivers/target/target_core_pscsi.c > b/drivers/target/target_core_pscsi.c > - * Copyright (c) 2003, 2004, 2005 PyX Technologies, Inc. > - * Copyright (c) 2005, 2006, 2007 SBE, Inc. > - * Copyright (c) 2008-2010 Linux-iSCSI.org > diff --git a/drivers/target/target_core_rd.c b/drivers/target/target_core_rd.c > - * Copyright (c) 2003, 2004, 2005 PyX Technologies, Inc. > - * Copyright (c) 2005, 2006, 2007 SBE, Inc. > - * Copyright (c) 2008-2010 Linux-iSCSI.org > diff --git a/drivers/target/target_core_sbc.c > b/drivers/target/target_core_sbc.c > - * Copyright (c) 2002, 2003, 2004, 2005 PyX Technologies, Inc. > - * Copyright (c) 2005, 2006, 2007 SBE, Inc. > - * Copyright (c) 2008-2010 Linux-iSCSI.org > diff --git a/drivers/target/target_core_spc.c > b/drivers/target/target_core_spc.c > - * Copyright (c) 2002, 2003, 2004, 2005 PyX Technologies, Inc. > - * Copyright (c) 2005, 2006, 2007 SBE, Inc. > - * Copyright (c) 2008-2010 Linux-iSCSI.org > diff --git a/drivers/target/target_core_stat.c > b/drivers/target/target_core_stat.c > - * Copyright (c) 2011 Linux-iSCSI.org > - * Copyright (c) 2006-2007 SBE, Inc. All Rights Reserved. > diff --git a/drivers/target/target_core_tmr.c > b/drivers/target/target_core_tmr.c > - * Copyright (c) 2009,2010 Linux-iSCSI.org > diff --git a/drivers/target/target_core_tpg.c > b/drivers/target/target_core_tpg.c > - * Copyright (c) 2002, 2003, 2004, 2005 PyX Technologies, Inc. > - * Copyright (c) 2005, 2006, 2007 SBE, Inc. > - * Copyright (c) 2008-2010 Linux-iSCSI.org > diff --git a/drivers/target/target_core_transport.c > b/drivers/target/target_core_transport.c > - * Copyright (c) 2002, 2003, 2004, 2005 PyX Technologies, Inc. > - * Copyright (c) 2005, 2006, 2007 SBE, Inc. > - * Copyright (c) 2008-2010 Linux-iSCSI.org > diff --git a/drivers/target/target_core_ua.c b/drivers/target/target_core_ua.c > - * Copyright (c) 2009,2010 Linux-iSCSI.org -- 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
Re: scsi target, likely GPL violation
This thread is certainly fascinating. As someone who has enforced the GPL for over a decade, and who coordinates a coalition of Linux developers who do GPL enforcement, I am very concerned about any accusation of GPL violation, and I hope that this situation can be resolved reasonably and swiftly. While I usually encourage private discussion about GPL violations -- at least to start -- I've also often found it's nearly impossible to maintain perfect secrecy about alleged GPL violations; openness and public discussions are the standard manner of group communication in the Free Software community. I hope that Rising Tide Systems and its agents are cognizant of this nature of the Free Software community. Furthermore, now that the discussion is public anyway, I hope Rising Tide Systems and its agents will welcome it and avoid any further actions to squelch such discussion. I suggest, though, that perhaps one of the mailing lists that Harlad Welte runs for his GPL Violations Project (such as http://lists.gpl-violations.org/mailman/listinfo/legal/ ) might be a better forum for this thread, rather than the technical discussion mailing lists for Linux and the subsystems in question. Meanwhile, I don't have too much to comment on in detail on this thread publicly at this time, but I do have a few points below: Nicholas Bellinger wrote at 21:08 (EST) on Thursday: > A substantial fraction of the code of which we own the sole copyright > was certified by BlackDuck Software as early as in 2007. Often in my work enforcing the GPL, companies have unsuccessfully proposed a Blackduck review as a defense of copyright infringement. I don't think Blackduck's system does anything to determine whether or not something is a derivative work under copyright law and/or whether a violation of GPL has occurred. Indeed, I know of no algorithmic way to make such determinations, and I'm quite sure they're undecidable problems (in the computability theory sense). To my knowledge, Blackduck's proprietary tool is merely an scanning tool examining source code for copyright header information and to pattern-match against other codebases in Blackduck's private database. (Although, since Blackduck's software is proprietary, trade-secret software, it's impossible to know for sure what it actually does, but we can be sure it doesn't solve any problems that are known to be unsolvable.) Thus, citing a Blackduck certification is simply off-point in refuting an accusation of any form of copyright infringement. Blackduck's software might be able to tell you if you *have* plagiarized someone's source code that appears in their databases, but they can't possibly tell you that you haven't infringed any copyrights. I'm quite sure Blackduck doesn't give away certification on the latter point. > So..., Andy, please start behaving properly ... [you aren't] be[ing] > ... professional in ... communications about licensing compliance > matters, I don't think it's reasonable to chastise Andy for raising these questions. While I personally (and Conservancy as an organization) don't usually raise accusations of GPL violations publicly until other methods of private communication are attempted, I believe public discussion is an important component of GPL compliance. Thus, Andy's strategy of discussing it publicly early in the process -- while not my preferred strategy -- is still a reasonable one. His attempt to raise these serious and legitimate concerns and questions is in no way unprofessional, nor should it be squelched. -- Bradley M. Kuhn, Executive Director, Software Freedom Conservancy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the net-next tree with Linus' tree
From: Stephen Rothwell
Date: Fri, 9 Nov 2012 10:53:18 +1100
> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c between commit
> 477864ddd365 ("bnx2x: Disable FCoE for 57840 since not yet supported by
> FW") from Linus' tree and commit 55c11941e382 ("bnx2x: Support loading
> cnic resources at run-time") from the net-next tree.
>
> I fixed it up (I think - see below) and can carry the fix as necessary
> (no action is required).
I'm pulling 'net' into 'net-next' and this is exactly how I will resolve
this conflict. Thanks Stephen.
--
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 RFT 2/2] pinctrl: dove: Checking valid config in dove_audio1_ctrl_set
Move the code checking valid config to dove_audio1_ctrl_set(), this ensures we always set valid config. And then dove_audio1_ctrl_get() always returns correct config. Signed-off-by: Axel Lin --- drivers/pinctrl/mvebu/pinctrl-dove.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/pinctrl/mvebu/pinctrl-dove.c b/drivers/pinctrl/mvebu/pinctrl-dove.c index e5cc694..a393790 100644 --- a/drivers/pinctrl/mvebu/pinctrl-dove.c +++ b/drivers/pinctrl/mvebu/pinctrl-dove.c @@ -217,12 +217,6 @@ static int dove_audio1_ctrl_get(struct mvebu_mpp_ctrl *ctrl, if (gcfg2 & DOVE_TWSI_OPTION3_GPIO) *config |= BIT(0); - /* SSP/TWSI only if I2S1 not set*/ - if ((*config & BIT(3)) == 0) - *config &= ~(BIT(2) | BIT(0)); - /* TWSI only if SPDIFO not set*/ - if ((*config & BIT(1)) == 0) - *config &= ~BIT(0); return 0; } @@ -234,6 +228,13 @@ static int dove_audio1_ctrl_set(struct mvebu_mpp_ctrl *ctrl, unsigned long gmpp = readl(DOVE_MPP_GENERAL_VIRT_BASE); unsigned long gcfg2 = readl(DOVE_GLOBAL_CONFIG_2); + /* SSP/TWSI only if I2S1 not set*/ + if ((config & BIT(3)) == 0) + config &= ~(BIT(2) | BIT(0)); + /* TWSI only if SPDIFO not set*/ + if ((config & BIT(1)) == 0) + config &= ~BIT(0); + if (config & BIT(0)) gcfg2 |= DOVE_TWSI_OPTION3_GPIO; else -- 1.7.9.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 RFT 1/2] pinctrl: dove: Fix dove_audio1_ctrl_set when BIT(0|1|2|3) of config is clear
Current implementation in dove_audio1_ctrl_set() does not clear corresponding register bit if BIT(0|1|2|3) of config is clear. Fix it. Signed-off-by: Axel Lin --- Hi, I don't have this hardware. I'd appreciate if someone can review and test this patch. Thanks, Axel drivers/pinctrl/mvebu/pinctrl-dove.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/pinctrl/mvebu/pinctrl-dove.c b/drivers/pinctrl/mvebu/pinctrl-dove.c index ffe74b2..e5cc694 100644 --- a/drivers/pinctrl/mvebu/pinctrl-dove.c +++ b/drivers/pinctrl/mvebu/pinctrl-dove.c @@ -236,12 +236,23 @@ static int dove_audio1_ctrl_set(struct mvebu_mpp_ctrl *ctrl, if (config & BIT(0)) gcfg2 |= DOVE_TWSI_OPTION3_GPIO; + else + gcfg2 &= ~DOVE_TWSI_OPTION3_GPIO; + if (config & BIT(1)) gmpp |= DOVE_AU1_SPDIFO_GPIO_EN; + else + gmpp &= ~DOVE_AU1_SPDIFO_GPIO_EN; + if (config & BIT(2)) sspc1 |= DOVE_SSP_ON_AU1; + else + sspc1 &= ~DOVE_SSP_ON_AU1; + if (config & BIT(3)) mpp4 |= DOVE_AU1_GPIO_SEL; + else + mpp4 &= ~DOVE_AU1_GPIO_SEL; writel(mpp4, DOVE_MPP_CTRL4_VIRT_BASE); writel(sspc1, DOVE_SSP_CTRL_STATUS_1); -- 1.7.9.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 1/4] arch/arm: add syscall_get_arch
From: Will Drewry
Provide an ARM implementation of syscall_get_arch. This is a pre-requisite
for CONFIG_HAVE_ARCH_SECCOMP_FILTER.
Signed-off-by: Will Drewry
Signed-off-by: Kees Cook
---
arch/arm/include/asm/syscall.h |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/include/asm/syscall.h b/arch/arm/include/asm/syscall.h
index 9fdded6..f1d96d4 100644
--- a/arch/arm/include/asm/syscall.h
+++ b/arch/arm/include/asm/syscall.h
@@ -7,6 +7,8 @@
#ifndef _ASM_ARM_SYSCALL_H
#define _ASM_ARM_SYSCALL_H
+#include /* for AUDIT_ARCH_* */
+#include /* for ELF_EM */
#include
#include
@@ -95,4 +97,11 @@ static inline void syscall_set_arguments(struct task_struct
*task,
memcpy(>ARM_r0 + i, args, n * sizeof(args[0]));
}
+static inline int syscall_get_arch(struct task_struct *task,
+ struct pt_regs *regs)
+{
+ /* ARM tasks don't change audit architectures on the fly. */
+ return AUDIT_ARCH_ARM;
+}
+
#endif /* _ASM_ARM_SYSCALL_H */
--
1.7.9.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 3/4] arch/arm: allow a scno of -1 to not cause a SIGILL
On tracehook-friendly platforms, a system call number of -1 falls
through without running much code or taking much action.
ARM is different. This adds a short-circuit check in the trace path to
avoid any additional work, as suggested by Russell King, to make sure
that ARM behaves the same way as other platforms.
Signed-off-by: Kees Cook
---
arch/arm/kernel/entry-common.S |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
index 8355d4b..0bef977 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -448,7 +448,10 @@ __sys_trace:
ldmccia r1, {r0 - r6} @ have to reload r0 - r6
stmccia sp, {r4, r5}@ and update the stack args
ldrcc pc, [tbl, scno, lsl #2] @ call sys_* routine
- b 2b
+ cmp scno, #-1 @ skip the syscall?
+ bne 2b
+ add sp, sp, #S_OFF @ restore stack
+ b ret_slow_syscall
__sys_trace_return:
str r0, [sp, #S_R0 + S_OFF]!@ save returned r0
--
1.7.9.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 2/4] arch/arm: move secure_computing into trace
There is very little difference in the TIF_SECCOMP and TIF_SYSCALL_WORK
path in entry-common.S, so merge TIF_SECCOMP into TIF_SYSCALL_WORK and
move seccomp into the syscall_trace_enter() handler.
Expanded some of the tracehook logic into the callers to make this code
more readable. Since tracehook needs to do register changing, this portion
is best left in its own function instead of copy/pasting into the callers.
Additionally, the return value for secure_computing() is now checked
and a -1 value will result in the system call being skipped.
Signed-off-by: Kees Cook
---
arch/arm/include/asm/thread_info.h |7 ---
arch/arm/kernel/entry-common.S | 10 --
arch/arm/kernel/ptrace.c | 29 -
3 files changed, 24 insertions(+), 22 deletions(-)
diff --git a/arch/arm/include/asm/thread_info.h
b/arch/arm/include/asm/thread_info.h
index 8477b4c..cddda1f 100644
--- a/arch/arm/include/asm/thread_info.h
+++ b/arch/arm/include/asm/thread_info.h
@@ -151,10 +151,10 @@ extern int vfp_restore_user_hwstate(struct user_vfp
__user *,
#define TIF_SYSCALL_TRACE 8
#define TIF_SYSCALL_AUDIT 9
#define TIF_SYSCALL_TRACEPOINT 10
+#define TIF_SECCOMP11 /* seccomp syscall filtering active */
#define TIF_USING_IWMMXT 17
#define TIF_MEMDIE 18 /* is terminating due to OOM killer */
#define TIF_RESTORE_SIGMASK20
-#define TIF_SECCOMP21
#define TIF_SWITCH_MM 22 /* deferred switch_mm */
#define _TIF_SIGPENDING(1 << TIF_SIGPENDING)
@@ -163,11 +163,12 @@ extern int vfp_restore_user_hwstate(struct user_vfp
__user *,
#define _TIF_SYSCALL_TRACE (1 << TIF_SYSCALL_TRACE)
#define _TIF_SYSCALL_AUDIT (1 << TIF_SYSCALL_AUDIT)
#define _TIF_SYSCALL_TRACEPOINT(1 << TIF_SYSCALL_TRACEPOINT)
-#define _TIF_USING_IWMMXT (1 << TIF_USING_IWMMXT)
#define _TIF_SECCOMP (1 << TIF_SECCOMP)
+#define _TIF_USING_IWMMXT (1 << TIF_USING_IWMMXT)
/* Checks for any syscall work in entry-common.S */
-#define _TIF_SYSCALL_WORK (_TIF_SYSCALL_TRACE | _TIF_SYSCALL_AUDIT |
_TIF_SYSCALL_TRACEPOINT)
+#define _TIF_SYSCALL_WORK (_TIF_SYSCALL_TRACE | _TIF_SYSCALL_AUDIT | \
+ _TIF_SYSCALL_TRACEPOINT | _TIF_SECCOMP)
/*
* Change these and you break ASM code in entry-common.S
diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
index 3471175..8355d4b 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -417,16 +417,6 @@ local_restart:
ldr r10, [tsk, #TI_FLAGS] @ check for syscall tracing
stmdb sp!, {r4, r5} @ push fifth and sixth args
-#ifdef CONFIG_SECCOMP
- tst r10, #_TIF_SECCOMP
- beq 1f
- mov r0, scno
- bl __secure_computing
- add r0, sp, #S_R0 + S_OFF @ pointer to regs
- ldmia r0, {r0 - r3} @ have to reload r0 - r3
-1:
-#endif
-
tst r10, #_TIF_SYSCALL_WORK @ are we tracing syscalls?
bne __sys_trace
diff --git a/arch/arm/kernel/ptrace.c b/arch/arm/kernel/ptrace.c
index 739db3a..518536d 100644
--- a/arch/arm/kernel/ptrace.c
+++ b/arch/arm/kernel/ptrace.c
@@ -916,16 +916,11 @@ enum ptrace_syscall_dir {
PTRACE_SYSCALL_EXIT,
};
-static int ptrace_syscall_trace(struct pt_regs *regs, int scno,
- enum ptrace_syscall_dir dir)
+static int tracehook_report_syscall(struct pt_regs *regs,
+ enum ptrace_syscall_dir dir)
{
unsigned long ip;
- current_thread_info()->syscall = scno;
-
- if (!test_thread_flag(TIF_SYSCALL_TRACE))
- return scno;
-
/*
* IP is used to denote syscall entry/exit:
* IP = 0 -> entry, =1 -> exit
@@ -944,19 +939,35 @@ static int ptrace_syscall_trace(struct pt_regs *regs, int
scno,
asmlinkage int syscall_trace_enter(struct pt_regs *regs, int scno)
{
- scno = ptrace_syscall_trace(regs, scno, PTRACE_SYSCALL_ENTER);
+ current_thread_info()->syscall = scno;
+
+ /* Do the secure computing check first; failures should be fast. */
+ if (secure_computing(scno) == -1)
+ return -1;
+
+ if (test_thread_flag(TIF_SYSCALL_TRACE))
+ scno = tracehook_report_syscall(regs, PTRACE_SYSCALL_ENTER);
+
if (test_thread_flag(TIF_SYSCALL_TRACEPOINT))
trace_sys_enter(regs, scno);
+
audit_syscall_entry(AUDIT_ARCH_ARM, scno, regs->ARM_r0, regs->ARM_r1,
regs->ARM_r2, regs->ARM_r3);
+
return scno;
}
asmlinkage int syscall_trace_exit(struct pt_regs *regs, int scno)
{
- scno = ptrace_syscall_trace(regs, scno, PTRACE_SYSCALL_EXIT);
+ current_thread_info()->syscall = scno;
+
+ if (test_thread_flag(TIF_SYSCALL_TRACE))
+ scno =
[PATCH v5 0/4] arch/arm: support seccomp
This adds support for seccomp BPF to ARM. When built with the seccomp
improvement patch waiting in linux-next ("seccomp: Make syscall skipping
and nr changes more consistent"), this passes the seccomp regression
test suite: https://github.com/redpig/seccomp
Thanks,
-Kees
---
v5:
- clean up seccomp failure path, as requested by Will Deacon.
v4:
- fixed syscall_get_arch, thanks to Will Deacon.
v3:
- updates suggested by Russell King:
- reduced scope of expansion
- leveraged TIF_SYSCALL_WORK bit mask
- fixed syscall==-1 short-circuit logic
v2:
- expanded ptrace_syscall_trace() into both callers and do
secure_computing() hookup there, as requested by Al Viro.
--
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 4/4] arch/arm: select HAVE_ARCH_SECCOMP_FILTER
From: Will Drewry Reflect architectural support for seccomp filter. Signed-off-by: Will Drewry Signed-off-by: Kees Cook --- arch/arm/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index ade7e92..0e8d490 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -21,6 +21,7 @@ config ARM select HAVE_AOUT select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL select HAVE_ARCH_KGDB + select HAVE_ARCH_SECCOMP_FILTER select HAVE_ARCH_TRACEHOOK select HAVE_BPF_JIT select HAVE_C_RECORDMCOUNT -- 1.7.9.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/
Re: [PATCH v3 8/7] pppoatm: fix missing wakeup in pppoatm_send()
On Sat, Nov 10, 2012 at 09:02:02PM +, David Woodhouse wrote:
> On Sat, 2012-11-10 at 21:23 +0100, Krzysztof Mazur wrote:
> > With this tasklet_schedule() we implement a "spin_lock" here, but in
> > this case both conditions (vcc not ready and socket locked) can be
> > true for a long time and we can spin here for a long time. I confirmed
> > it by reverting patch 1 (atm: detach protocol before closing vcc) and
> > now I have 50% of CPU used by ksoftirqd and 50% by pppd (UP system).
>
> Ah, thanks.
>
> Can we take the lock in the tasklet, so we wait for it instead of
> spinning?
>
I don't think so, we cannot sleep in tasklet.
I think we should use sk_add_backlog() or release_cb (introduced by:
46d3ceabd8d98ed0ad10f20c595ca784e34786c5 tcp: TCP Small Queues).
The release_cb callback is almost exactly what we need except that
it works on protocol level, not on socket. The same race with
vcc_sendmsg() exists also in other ATM protocols, so maybe we should
add wrapper in ATM layer that calls vcc->sock_release_cb().
But what about socket flags? Maybe we should just drop that frame?
When ppp is used on serial links "not-ready link" usually does that.
I'm sending an updated patch 6.
Krzysiek
-- >8 --
Subject: [PATCH] pppoatm: drop frames to not-ready vcc
Patches "atm: detach protocol before closing vcc"
and "pppoatm: allow assign only on a connected socket" fixed
common cases where the pppoatm_send() crashes while sending
frame to not-ready vcc. However there are still some other cases
where we can send frames to vcc, which is flagged as ATM_VF_CLOSE
(for instance after vcc_release_async()) or it's opened but not
ready yet.
Now pppoatm_send(), like vcc_sendmsg(), checks for vcc flags that
indicate that vcc is not ready. If the vcc is not ready we just
drop frame. Queueing frames is much more complicated because we
don't have callbacks that inform us about vcc flags changes.
Signed-off-by: Krzysztof Mazur
---
net/atm/pppoatm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/net/atm/pppoatm.c b/net/atm/pppoatm.c
index c4a57bc..63541a3 100644
--- a/net/atm/pppoatm.c
+++ b/net/atm/pppoatm.c
@@ -284,6 +284,13 @@ static int pppoatm_send(struct ppp_channel *chan, struct
sk_buff *skb)
bh_lock_sock(sk_atm(vcc));
if (sock_owned_by_user(sk_atm(vcc)))
goto nospace;
+ if (test_bit(ATM_VF_RELEASED, >flags)
+ || test_bit(ATM_VF_CLOSE, >flags)
+ || !test_bit(ATM_VF_READY, >flags)) {
+ bh_unlock_sock(sk_atm(vcc));
+ kfree_skb(skb);
+ return DROP_PACKET;
+ }
switch (pvcc->encaps) { /* LLC encapsulation needed */
case e_llc:
--
1.8.0.268.g9d5ca2e
--
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] USB: mos7840: remove unused variable
On 11/08/2012 06:28 PM, Johan Hovold wrote:
> Fix warning about unused variable introduced by commit e681b66f2e19fa
> ("USB: mos7840: remove invalid disconnect handling") upstream.
>
> A subsequent fix which removed the disconnect function got rid of the
> warning but that one was only backported to v3.6.
>
> Reported-by: Jiri Slaby
FWIW Looks good to me.
> Cc: stable
> Signed-off-by: Johan Hovold
> ---
>
> This patch against v3.4 also applies to v3.0 (and v3.2).
>
> Thanks,
> Johan
>
> drivers/usb/serial/mos7840.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/usb/serial/mos7840.c b/drivers/usb/serial/mos7840.c
> index 0179d34..c854235 100644
> --- a/drivers/usb/serial/mos7840.c
> +++ b/drivers/usb/serial/mos7840.c
> @@ -2581,7 +2581,6 @@ error:
> static void mos7840_disconnect(struct usb_serial *serial)
> {
> int i;
> - unsigned long flags;
> struct moschip_port *mos7840_port;
> dbg("%s", " disconnect :entering..");
>
thanks,
--
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI / platform: use ACPI device name instead of _HID._UID
On Tuesday, November 06, 2012 02:12:51 PM Mika Westerberg wrote:
> Using _UID makes the ACPI platform bus code to depend on BIOS to get it
> right. If it doesn't we fail to create the platform device as the name
> should be unique.
>
> The ACPI core already makes an unique name when it first creates the ACPI
> device so we can use that same name as the platform device name instead of
> trusting that the BIOS sets the _UIDs correctly.
>
> Signed-off-by: Mika Westerberg
> Cc: Bjorn Helgaas
Applied to linux-pm.git/linux-next.
Thanks,
Rafael
> ---
> This was suggested by Bjorn Helgaas in another thread. The patch applies on
> top of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
> linux-next.
>
> drivers/acpi/acpi_platform.c | 62
> +++---
> 1 file changed, 22 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
> index a5a2346..dbb31d6 100644
> --- a/drivers/acpi/acpi_platform.c
> +++ b/drivers/acpi/acpi_platform.c
> @@ -120,25 +120,6 @@ static acpi_status acpi_platform_add_resources(struct
> acpi_resource *res,
> return AE_OK;
> }
>
> -static acpi_status acpi_platform_get_device_uid(struct acpi_device *adev,
> - int *uid)
> -{
> - struct acpi_device_info *info;
> - acpi_status status;
> -
> - status = acpi_get_object_info(adev->handle, );
> - if (ACPI_FAILURE(status))
> - return status;
> -
> - status = AE_NOT_EXIST;
> - if ((info->valid & ACPI_VALID_UID) &&
> - !kstrtoint(info->unique_id.string, 0, uid))
> - status = AE_OK;
> -
> - kfree(info);
> - return status;
> -}
> -
> /**
> * acpi_create_platform_device - Create platform device for ACPI device node
> * @adev: ACPI device node to create a platform device for.
> @@ -156,19 +137,12 @@ struct platform_device
> *acpi_create_platform_device(struct acpi_device *adev)
> struct device *parent = NULL;
> struct resource_info ri;
> acpi_status status;
> - int devid;
>
> /* If the ACPI node already has a physical device attached, skip it. */
> if (adev->physical_node_count)
> return NULL;
>
> - /* Use the UID of the device as the new platform device id if found. */
> - status = acpi_platform_get_device_uid(adev, );
> - if (ACPI_FAILURE(status))
> - devid = -1;
> -
> memset(, 0, sizeof(ri));
> -
> /* First, count the resources. */
> status = acpi_walk_resources(adev->handle, METHOD_NAME__CRS,
>acpi_platform_count_resources, );
> @@ -214,8 +188,8 @@ struct platform_device
> *acpi_create_platform_device(struct acpi_device *adev)
> }
> mutex_unlock(_parent->physical_node_lock);
> }
> - pdev = platform_device_register_resndata(parent, acpi_device_hid(adev),
> - devid, ri.res, ri.n, NULL, 0);
> + pdev = platform_device_register_resndata(parent, dev_name(>dev),
> + -1, ri.res, ri.n, NULL, 0);
> if (IS_ERR(pdev)) {
> dev_err(>dev, "platform device creation failed: %ld\n",
> PTR_ERR(pdev));
> @@ -245,17 +219,7 @@ static acpi_status acpi_platform_match(acpi_handle
> handle, u32 depth,
> if (adev->physical_node_count)
> return AE_OK;
>
> - if (!strcmp(pdev->name, acpi_device_hid(adev))) {
> - int devid;
> -
> - /* Check that both name and UID match if it exists */
> - status = acpi_platform_get_device_uid(adev, );
> - if (ACPI_FAILURE(status))
> - devid = -1;
> -
> - if (pdev->id != devid)
> - return AE_OK;
> -
> + if (!strcmp(dev_name(>dev), dev_name(>dev))) {
> *(acpi_handle *)return_value = handle;
> return AE_CTRL_TERMINATE;
> }
> @@ -266,10 +230,28 @@ static acpi_status acpi_platform_match(acpi_handle
> handle, u32 depth,
> static int acpi_platform_find_device(struct device *dev, acpi_handle *handle)
> {
> struct platform_device *pdev = to_platform_device(dev);
> + char *name, *tmp, *hid;
> +
> + /*
> + * The platform device is named using the ACPI device name
> + * _HID:INSTANCE so we strip the INSTANCE out in order to find the
> + * correct device using its _HID.
> + */
> + name = kstrdup(dev_name(dev), GFP_KERNEL);
> + if (!name)
> + return -ENOMEM;
> +
> + tmp = name;
> + hid = strsep(, ":");
> + if (!hid) {
> + kfree(name);
> + return -ENODEV;
> + }
>
> *handle = NULL;
> - acpi_get_devices(pdev->name, acpi_platform_match, pdev, handle);
> + acpi_get_devices(hid, acpi_platform_match, pdev, handle);
>
> + kfree(name);
> return *handle ? 0
Re: [PATCH 4/5] x86: acpi: Print warning for malformed host bridge resources
On Wed, Nov 7, 2012 at 7:55 PM, Peter Hurley wrote:
> An incorrectly specified host bridge window may prevent
> other devices from claiming assigned resources. For example,
> this flawed _CRS resource descriptor from a Dell T5400:
> DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed,
> NonCacheable, ReadWrite,
> 0x, // Granularity
> 0xF000, // Range Minimum
> 0xFE00, // Range Maximum
> 0x, // Translation Offset
> 0x0E00, // Length
> ,, , AddressRangeMemory, TypeStatic)
I think the problem here is that the Range Maximum should be
0xFDFF, not 0xFE00, right?
> prevents the adjacent device from claiming [mem 0xfe000-0xfe01]
>
> Sanity check that the resource at least conforms to a valid
> PCI BAR; if not, emit a diagnostic warning.
>
> Cc: Bjorn Helgaas
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: H. Peter Anvin
> Cc: x...@kernel.org
> Signed-off-by: Peter Hurley
> ---
> arch/x86/pci/acpi.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> index 192397c..3468d16 100644
> --- a/arch/x86/pci/acpi.c
> +++ b/arch/x86/pci/acpi.c
> @@ -298,6 +298,10 @@ setup_resource(struct acpi_resource *acpi_res, void
> *data)
> "host bridge window [%#llx-%#llx] "
> "([%#llx-%#llx] ignored, not CPU addressable)\n",
> start, orig_end, end + 1, orig_end);
> + } else if (flags & IORESOURCE_MEM && (start & 0x0f || ~end & 0x0f)) {
> + dev_warn(>bridge->dev,
> +"invalid host bridge window [%#llx-%#llx]\n",
> +start, end);
We didn't actually *fix* anything here, so I guess we're just pointing
out the reason for a subsequent failure to claim the adjacent
resource.
As far as I know, the spec doesn't actually require resources of ACPI
devices to be non-overlapping. Windows accepts overlapping resources,
and I think Linux probably should, too, but right now we trip over
this.
In the meantime (until we figure out how to handle overlapping
resources better), can we do something to actually fix this? Maybe we
should truncate the end of the range to 0xFDFF like we do for
non-addressable parts of the range?
Is there a bugzilla or a complete dmesg log to look at?
Bjorn
> }
>
> res = >res[info->res_num];
> --
> 1.7.12.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/16 v3] f2fs: introduce flash-friendly file system
On Saturday 10 November 2012, Martin Steigerwald wrote:
> Command (m for help): n
> Partition type:
>p primary (0 primary, 0 extended, 4 free)
>e extended
> Select (default p): p
> Partition number (1-4, default 1): 1
> First sector (2048-4095998, default 2048):
> Using default value 2048
> Last sector, +sectors or +size{K,M,G} (2048-4095998, default 4095998):
> Using default value 4095998
This is almost certainly not the right setting for f2fs, which only works
at its design point if the segments are aligned to erase blocks. All modern
flash devices have erase blocks larger than 1 MB, so starting the partition
at a 1 MB offset will cause it to be misaligned. Also, some USB sticks
have an area optimized for random writes in the beginning of the drive
where both FAT32 and f2fs store their metadata. It may be worth testing
again without a partition table, using just the raw device.
I would also recommend using flashbench to find out the optimum parameters
for your device. You can download it from
git://git.linaro.org/people/arnd/flashbench.git
In the long run, we should automate those tests and make them part of
mkfs.f2fs, but for now, try to find out the erase block size and the number
of concurrently used erase blocks on your device using a timing attack
in flashbench. The README file in there explains how to interpret the
results from "./flashbench -a /dev/sdb --blocksize=1024" to guess
the erase block size, although that sometimes doesn't work.
With the correct guess, compare the performance you get using
$ ERASESIZE=$[2*1024*1024] # replace with guess from flashbench -a
$ ./flashbench /dev/sdb --open-au --open-au-nr=1 --blocksize=4096
--erasesize=${ERASESIZE}
$ ./flashbench /dev/sdb --open-au --open-au-nr=3 --blocksize=4096
--erasesize=${ERASESIZE}
$ ./flashbench /dev/sdb --open-au --open-au-nr=5 --blocksize=4096
--erasesize=${ERASESIZE}
$ ./flashbench /dev/sdb --open-au --open-au-nr=7 --blocksize=4096
--erasesize=${ERASESIZE}
$ ./flashbench /dev/sdb --open-au --open-au-nr=13 --blocksize=4096
--erasesize=${ERASESIZE}
The first one of those should always be the fastest, hopefully followed by
some that are equally fast and then some much slower ones (especially for the
smaller block sizes). The "active_logs=N" mount option should be one less
than the highest number above that is still "fast", and only "2", "4" and "6"
are valid at the moment. If you are lucky, your device is still fast with
"--open-au-nr=7" and slow only for higher numbers, then the default of "6"
is ok.
If the erase size is larger than 2 MB, then you have to "-s" option in
mkfs.f2fs to configure how many 2 MB segments there are in one erase block.
For a 2 GB USB stick, I would guess that the erase block size is 1, 2 or
4 MB. Newer (larger) sticks will have larger erase blocks that may also
be a multiple of 3 MB (3, 6, 12, or 24).
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] drm: tegra: Add HDMI support
On Sat, Nov 10, 2012 at 10:01:18PM +0100, Thierry Reding wrote:
> On Fri, Nov 09, 2012 at 05:00:54PM +0100, Christian König wrote:
> > On 09.11.2012 16:45, Rafał Miłecki wrote:
> > >2012/11/9 Thierry Reding :
> > >>+/* all fields little endian */
> > >>+struct hdmi_audio_infoframe {
> > >>+ /* PB0 */
> > >>+ u8 csum;
> > >>+
> > >>+ /* PB1 */
> > >>+ unsigned cc:3; /* channel count */
> > >>+ unsigned res1:1;
> > >>+ unsigned ct:4; /* coding type */
> > >>+
> > >>+ /* PB2 */
> > >>+ unsigned ss:2; /* sample size */
> > >>+ unsigned sf:3; /* sample frequency */
> > >>+ unsigned res2:3;
> > >>+
> > >>+ /* PB3 */
> > >>+ unsigned cxt:5; /* coding extention type */
> > >>+ unsigned res3:3;
> > >>+
> > >>+ /* PB4 */
> > >>+ u8 ca; /* channel/speaker allocation */
> > >>+
> > >>+ /* PB5 */
> > >>+ unsigned res5:3;
> > >>+ unsigned lsv:4; /* level shift value */
> > >>+ unsigned dm_inh:1; /* downmix inhibit */
> > >>+
> > >>+ /* PB6-10 reserved */
> > >>+ u8 res6;
> > >>+ u8 res7;
> > >>+ u8 res8;
> > >>+ u8 res9;
> > >>+ u8 res10;
> > >>+} __packed;
> > >I was told it won't work on different endian devices. See
> > >[RFC][PATCH] drm/radeon/hdmi: define struct for AVI infoframe
> > >http://lists.freedesktop.org/archives/dri-devel/2012-May/022544.html
> >
> > Yeah, that's indeed true. And honestly adding just another
> > implementation of the HDMI info frames sounds like somebody should
> > finally sit down and implement it in a common drm_hdmi.c
>
> So I've been looking at what most other implementations do and it seems
> a lot just fill the AVI infoframe with zeroes while only a few actually
> try to put useful information in them. Still in order to plan for a
> generic solution, I thought maybe something like the below set of
> structures and functions could work:
>
> /*
> * Structure that contains the infoframe fields in a form that allows them to
> * be easily accessed from C code.
> */
> struct hdmi_avi_infoframe;
>
> /*
> * DRM helper to fill a struct hdmi_avi_infoframe with information taken from
> * a struct drm_display_mode. Fields that cannot automatically be derived by
> * looking at a struct drm_display_mode are set to the default values.
> */
> int drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe *frame,
>struct drm_display_mode *mode);
>
> /*
> * Packs the struct hdmi_avi_infoframe into a binary buffer that can be
> * programmed to the hardware-specific registers.
> */
> ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe *frame,
> void *buffer, size_t size);
>
> Such a scheme would allow DRM drivers to call the helper and tweak the
> fields in the structure if the want or need to and call the packing
> function to obtain a buffer that they can write to the controller.
>
> Does that sound at all reasonable?
And I forgot, maybe this shouldn't be included in the drivers/gpu/drm
subdirectory, but rather in a more generic location such as
drivers/video since other subsystems (V4L2) may want to use the same
code.
Thierry
pgp7lI0pI2G5V.pgp
Description: PGP signature
Re: [PATCH v3 8/7] pppoatm: fix missing wakeup in pppoatm_send()
On Sat, 2012-11-10 at 21:23 +0100, Krzysztof Mazur wrote: > With this tasklet_schedule() we implement a "spin_lock" here, but in > this case both conditions (vcc not ready and socket locked) can be > true for a long time and we can spin here for a long time. I confirmed > it by reverting patch 1 (atm: detach protocol before closing vcc) and > now I have 50% of CPU used by ksoftirqd and 50% by pppd (UP system). Ah, thanks. Can we take the lock in the tasklet, so we wait for it instead of spinning? -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH 2/2] drm: tegra: Add HDMI support
On Fri, Nov 09, 2012 at 05:00:54PM +0100, Christian König wrote:
> On 09.11.2012 16:45, Rafał Miłecki wrote:
> >2012/11/9 Thierry Reding :
> >>+/* all fields little endian */
> >>+struct hdmi_audio_infoframe {
> >>+ /* PB0 */
> >>+ u8 csum;
> >>+
> >>+ /* PB1 */
> >>+ unsigned cc:3; /* channel count */
> >>+ unsigned res1:1;
> >>+ unsigned ct:4; /* coding type */
> >>+
> >>+ /* PB2 */
> >>+ unsigned ss:2; /* sample size */
> >>+ unsigned sf:3; /* sample frequency */
> >>+ unsigned res2:3;
> >>+
> >>+ /* PB3 */
> >>+ unsigned cxt:5; /* coding extention type */
> >>+ unsigned res3:3;
> >>+
> >>+ /* PB4 */
> >>+ u8 ca; /* channel/speaker allocation */
> >>+
> >>+ /* PB5 */
> >>+ unsigned res5:3;
> >>+ unsigned lsv:4; /* level shift value */
> >>+ unsigned dm_inh:1; /* downmix inhibit */
> >>+
> >>+ /* PB6-10 reserved */
> >>+ u8 res6;
> >>+ u8 res7;
> >>+ u8 res8;
> >>+ u8 res9;
> >>+ u8 res10;
> >>+} __packed;
> >I was told it won't work on different endian devices. See
> >[RFC][PATCH] drm/radeon/hdmi: define struct for AVI infoframe
> >http://lists.freedesktop.org/archives/dri-devel/2012-May/022544.html
>
> Yeah, that's indeed true. And honestly adding just another
> implementation of the HDMI info frames sounds like somebody should
> finally sit down and implement it in a common drm_hdmi.c
So I've been looking at what most other implementations do and it seems
a lot just fill the AVI infoframe with zeroes while only a few actually
try to put useful information in them. Still in order to plan for a
generic solution, I thought maybe something like the below set of
structures and functions could work:
/*
* Structure that contains the infoframe fields in a form that allows them to
* be easily accessed from C code.
*/
struct hdmi_avi_infoframe;
/*
* DRM helper to fill a struct hdmi_avi_infoframe with information taken from
* a struct drm_display_mode. Fields that cannot automatically be derived by
* looking at a struct drm_display_mode are set to the default values.
*/
int drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe *frame,
struct drm_display_mode *mode);
/*
* Packs the struct hdmi_avi_infoframe into a binary buffer that can be
* programmed to the hardware-specific registers.
*/
ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe *frame,
void *buffer, size_t size);
Such a scheme would allow DRM drivers to call the helper and tweak the
fields in the structure if the want or need to and call the packing
function to obtain a buffer that they can write to the controller.
Does that sound at all reasonable?
Thierry
pgp7Y0STgA32F.pgp
Description: PGP signature
Re: [PATCH 00/16 v3] f2fs: introduce flash-friendly file system
Hi, On Nov 10, 2012, at 9:33 PM, Martin Steigerwald wrote: [snip] > > merkaba:~> mkfs.f2fs /dev/sdb1 > Info: sector size = 512 > Info: total sectors = 4093951 (in 512bytes) > Info: zone aligned segment0 blkaddr: 256 > Info: This device doesn't support TRIM > Info: format successful > merkaba:~> mount /dev/sdb1 /mnt/zeit > mount: you must specify the filesystem type > merkaba:~#32> mount -t f2fs /dev/sdb1 /mnt/zeit > merkaba:~> df -hT /mnt/zeit > DateisystemTyp Größe Benutzt Verf. Verw% Eingehängt auf > /dev/sdb1 f2fs 2,0G147M 1,8G8% /mnt/zeit > Do you really have trouble with f2fs mount without definition of filesystem type? If so, it is a bug. Moreover, I think that it is really inconvenient that mkfs.f2fs doesn't output its version. I suggest to output version of f2fs utilities. With the best regards, Vyacheslav Dubeyko. -- 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 8/7] pppoatm: fix missing wakeup in pppoatm_send()
On Wed, Nov 07, 2012 at 12:52:14PM +, David Woodhouse wrote:
>
> diff --git a/net/atm/pppoatm.c b/net/atm/pppoatm.c
> index 7507c20..56ad541 100644
> --- a/net/atm/pppoatm.c
> +++ b/net/atm/pppoatm.c
> @@ -283,11 +283,11 @@ static int pppoatm_send(struct ppp_channel *chan,
> struct sk_buff *skb)
> vcc = ATM_SKB(skb)->vcc;
> bh_lock_sock(sk_atm(vcc));
> if (sock_owned_by_user(sk_atm(vcc)))
> - goto nospace;
> + goto nospace_sched_wakeup;
> if (test_bit(ATM_VF_RELEASED, >flags)
> - || test_bit(ATM_VF_CLOSE, >flags)
> - || !test_bit(ATM_VF_READY, >flags))
> - goto nospace;
> + || test_bit(ATM_VF_CLOSE, >flags)
> + || !test_bit(ATM_VF_READY, >flags))
> + goto nospace_sched_wakeup;
>
> switch (pvcc->encaps) { /* LLC encapsulation needed */
> case e_llc:
> @@ -328,7 +328,17 @@ static int pppoatm_send(struct ppp_channel *chan, struct
> sk_buff *skb)
> ? DROP_PACKET : 1;
> bh_unlock_sock(sk_atm(vcc));
> return ret;
> -nospace:
> + nospace_sched_wakeup:
> + /* If we're returning zero for reasons *other* than the queue
> + * being full, then we need to ensure that a wakeup will
> + * happen and not just leave the channel stalled for ever.
> + * Just schedule the wakeup tasklet directly. As observed in
> + * pppoatm_pop(), it'll take the channel's ->downl lock which
> + * is also held by our caller, so it can't happen "too soon"
> + * and cause us to effectively miss a wakeup.
> + */
> + tasklet_schedule(>wakeup_tasklet);
With this tasklet_schedule() we implement a "spin_lock" here, but in
this case both conditions (vcc not ready and socket locked) can be true
for a long time and we can spin here for a long time. I confirmed it by
reverting patch 1 (atm: detach protocol before closing vcc) and now
I have 50% of CPU used by ksoftirqd and 50% by pppd (UP system).
Krzysiek
--
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/
[GIT] Networking
Bug fixes galore, mostly in drivers as is often the case: 1) USB gadget and cdc_eem drivers need adjustments to their frame size lengths in order to handle VLANs correctly. From Ian Coolidge. 2) TIPC and several network drivers erroneously call tasklet_disable before tasklet_kill, fix from Xiaotian Feng. 3) r8169 driver needs to apply the WOL suspend quirk to more chipsets, fix from Cyril Brulebois. 4) Fix multicast filters on RTL_GIGA_MAC_VER_35 r8169 chips, from Nathan Walp. 5) FDB netlink dumps should use RTM_NEWNEIGH as the message type, not zero. From John Fastabend. 6) Fix smsc95xx tx checksum offload on big-endian, from Steve Glendinning. 7) __inet_diag_dump() needs to repsect and report the error value returned from inet_diag_lock_handler() rather than ignore it. Otherwise if an inet diag handler is not available for a particular protocol, we essentially report success instead of giving an error indication. Fix from Cyrill Gorcunov. 8) When the QFQ packet scheduler sees TSO/GSO packets it does not handle things properly, and in fact ends up corrupting it's datastructures as well as mis-schedule packets. Fix from Paolo Valente. 9) Fix oopser in skb_loop_sk(), from Eric Leblond. 10) CXGB4 passes partially uninitialized datastructures in to FW commands, fix from Vipul Pandya. 11) When we send unsolicited ipv6 neighbour advertisements, we should send them to the link-local allnodes multicast address, as per RFC4861. Fix from Hannes Frederic Sowa. 12) There is some kind of bug in the usbnet's kevent deferral mechanism, but more immediately when it triggers an uncontrolled stream of kernel messages spam the log. Rate limit the error log message triggered when this problem occurs, as sending thousands of error messages into the kernel log doesn't help matters at all, and in fact makes further diagnosis more difficult. From Steve Glendinning. 13) Fix gianfar restore from hibernation, from Wang Dongsheng. 14) The netlink message attribute sizes are wrong in the ipv6 GRE driver, it was using the size of ipv4 addresses instead of ipv6 ones :-) Fix from Nicolas Dichtel. Please pull, thanks a lot! The following changes since commit 0f89a5733a8d28174c7adeb1fdc20ac11439e766: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2012-11-02 20:48:41 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net master for you to fetch changes up to a375413311b39005ef281bfd71ae8f4e3df22e97: gre6: fix rtnl dump messages (2012-11-09 17:11:17 -0500) Cyril Brulebois (1): r8169: Fix WoL on RTL8168d/8111d. Cyrill Gorcunov (1): net: inet_diag -- Return error code if protocol handler is missed Eric Leblond (1): af-packet: fix oops when socket is not present Hannes Frederic Sowa (1): ipv6: send unsolicited neighbour advertisements to all-nodes Ian Coolidge (2): usb: gadget: g_ether: fix frame size check for 802.1Q net: usb: cdc_eem: Fix rx skb allocation for 802.1Q VLANs Jacob Keller (1): ptp: update adjfreq callback description John Fastabend (1): rtnetlink: Use nlmsg type RTM_NEWNEIGH from dflt fdb dump Lee Jones (1): isdn: Make CONFIG_ISDN depend on CONFIG_NETDEVICES Masanari Iida (1): net: bnx2x: Fix typo in bnx2x driver Nathan Walp (1): r8169: allow multicast packets on sub-8168f chipset. Nicolas Dichtel (1): gre6: fix rtnl dump messages Paolo Valente (1): pkt_sched: enable QFQ to support TSO/GSO Steve Glendinning (2): smsc95xx: fix tx checksum offload for big endian usbnet: ratelimit kevent may have been dropped warnings Vipul Pandya (2): cxgb4: Initialize data structures before using. cxgb4: Fix initialization of SGE_CONTROL register Wang Dongsheng (1): gianfar: ethernet vanishes after restoring from hibernation Xiaotian Feng (2): tipc: do not use tasklet_disable before tasklet_kill drivers/net: use tasklet_kill in device remove/close process drivers/isdn/Kconfig| 2 +- drivers/isdn/i4l/Kconfig| 2 +- drivers/isdn/i4l/isdn_common.c | 4 --- drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c | 2 +- drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c| 4 +-- drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 6 +++- drivers/net/ethernet/freescale/gianfar.c| 5 ++- drivers/net/ethernet/jme.c | 8 ++--- drivers/net/ethernet/marvell/skge.c | 2 +- drivers/net/ethernet/micrel/ksz884x.c | 4 +-- drivers/net/ethernet/realtek/r8169.c| 5 +++ drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 2 +- drivers/net/usb/cdc_eem.c | 3 +-
Re: [PATCH 2/3] spi / ACPI: add ACPI enumeration support
On Saturday, November 10, 2012 10:14:47 AM Bjorn Helgaas wrote: > On Sat, Nov 10, 2012 at 4:10 AM, Rafael J. Wysocki wrote: > > On Friday, November 09, 2012 09:53:26 AM Bjorn Helgaas wrote: > >> On Fri, Nov 9, 2012 at 9:43 AM, Grant Likely > >> wrote: > >> > On Fri, Nov 9, 2012 at 4:35 PM, Bjorn Helgaas > >> > wrote: > >> >> On Fri, Nov 9, 2012 at 8:45 AM, Grant Likely > >> >> wrote: > >> >>> On Fri, Nov 9, 2012 at 3:11 PM, Bjorn Helgaas > >> >>> wrote: > >> [+cc Greg, Peter, Tony since they acked the original patch [1]] > >> > >> On Thu, Nov 8, 2012 at 1:04 PM, Mika Westerberg > >> wrote: > >> > On Thu, Nov 08, 2012 at 12:32:25PM -0700, Bjorn Helgaas wrote: > >> >> Struct device_driver is a generic structure, so it seems strange to > >> >> have to include non-generic things like of_device_id and now > >> >> acpi_match_table there. > >> > > >> > Yes, but in a sense the DT and ACPI are "generic". So that they are > >> > used to > >> > describe the configuration of a machine. > >> > >> What I meant by "generic" was "useful across all architectures." The > >> new acpi_match_table and acpi_handle fields [1] are not generic in > >> that sense because they're present on all architectures but used only > >> on x86 and ia64. The existing of_match_table and of_node are > >> similarly unused on many architectures. This doesn't seem like a > >> scalable strategy to me. Are we going to add a pnpbios_node for x86 > >> PNPBIOS machines without ACPI, a pdc_hpa for parisc machines with PDC, > >> etc.? > >> > >> [1] https://patchwork.kernel.org/patch/1677221/ > >> >>> > >> >>> Ultimately yes, I think that is what we want to do, > >> >> > >> >> Just to be clear, you think we *should* add things like pnpbios_node, > >> >> pdc_hpa, etc., to struct device, one field for every scheme of telling > >> >> the OS about non-enumerable devices, where only one of the N fields is > >> >> used on any given machine? That seems surprising to me, but maybe I > >> >> just need to be educated :) > >> > > >> > Ah, I see what you're asking. > >> > > >> > In the short term, yes but only because we don't have any other > >> > alternative. What I'd really rather have is a safe way to attach datum > >> > (ie. acpi_device or device_node) to a struct device and get it back > >> > later in a type safe way. > >> > >> Yep, *that* makes perfect sense to me. Something along these lines, maybe: > >> > >> #define dev_is_acpi(d)((d)->bus == _bus_type) > > > > No, that's not right. It won't work for things like SPI and I2C with a > > "backing" ACPI device node anyway (and for PCI too, by the way :-)). > > > >> #define dev_acpi_handle(d)(dev_is_acpi(d) ? (acpi_handle) > >> d->datum : NULL) > > > > The problem basically is how we can tell that the given struct device has > > a "backing" object containing device information (e.g. resources) and what > > that "backing" object is. For device trees that would be a struct > > device_node > > and for ACPI that would be an acpi_handle or a struct acpi_device etc. And > > by > > the way, they _can_ be used simultaneously, in principle. > > > > So we need something like of_node(dev) or acpi_node(dev), but that can't be > > something following two pointers or calling a function just in order to > > check > > if the pointer _is_ _there_ in either case. > > > > And since we added of_node to struct device at one point, it is only > > logical to > > treat ACPI in the same way. If we come up with a better idea _later_, then > > we > > can convert _all_ things to this new idea, whatever it is. > > > > Are you seriously expecting us to come up with such an idea on the fly just > > so > > that we can use ACPI support, which already is there in the form of > > archdata.acpi_handle anyway, on equal footing with Device Trees? > > Of course not. I'm just trying to understand where we're headed. > That was not obvious from the patches I've seen so far. No, it wasn't, fair enough. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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/
[GIT] Sparc
Several build/bug fixes for sparc, including: 1) Configuring a mix of static vs. modular sparc64 crypto modules didn't work, remove an ill-conceived attempt to only have to build the device match table for these drivers once to fix the problem. Reported by Meelis Roos. 2) Make the montgomery multiple/square and mpmul instructions actually usable in 32-bit tasks. Essentially this involves providing 32-bit userspace with a way to use a 64-bit stack when it needs to. 3) Our sparc64 atomic backoffs don't yield cpu strands properly on Niagara chips. Use pause instruction when available to achieve this, otherwise use a benign instruction we know blocks the strand for some time. 4) Wire up kcmp 5) Fix the build of various drivers by removing the unnecessary blocking of OF_GPIO when SPARC. 6) Fix unintended regression wherein of_address_to_resource stopped being provided. Fix from Andreas Larsson. 7) Fix NULL dereference in leon_handle_ext_irq(), also from Andreas Larsson. Please pull, thanks a lot. The following changes since commit 1d47091ac6bf1286d708ebcd3f2b69d7c682916b: Merge tag 'usb-3.7-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb (2012-10-26 10:26:36 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc master for you to fetch changes up to 226f7cea949303a3e1911999a9a2c71b0a708e73: sparc64: Fix build with mix of modular vs. non-modular crypto drivers. (2012-11-09 20:55:16 -0800) Andreas Larsson (3): sparc: Add sparc support for platform_get_irq() sparc32, leon: Check for existent irq_map entry in leon_handle_ext_irq of/address: sparc: Declare of_address_to_resource() as an extern function for sparc again David S. Miller (9): sparc64: Make montmul/montsqr/mpmul usable in 32-bit threads. sparc64: Fix cpu strand yielding. sparc64: Use pause instruction when available. sparc64: Improvde documentation and readability of atomic backoff code. sparc: Wire up sys_kcmp. qlogicpti: Fix build warning. sparc: Allow OF_GPIO on sparc. sparc: Support atomic64_dec_if_positive properly. sparc64: Fix build with mix of modular vs. non-modular crypto drivers. arch/sparc/Kconfig | 1 + arch/sparc/crypto/Makefile | 16 arch/sparc/crypto/aes_glue.c| 2 ++ arch/sparc/crypto/camellia_glue.c | 2 ++ arch/sparc/crypto/crc32c_glue.c | 2 ++ arch/sparc/crypto/des_glue.c| 2 ++ arch/sparc/crypto/md5_glue.c| 2 ++ arch/sparc/crypto/sha1_glue.c | 2 ++ arch/sparc/crypto/sha256_glue.c | 2 ++ arch/sparc/crypto/sha512_glue.c | 2 ++ arch/sparc/include/asm/atomic_64.h | 4 +++- arch/sparc/include/asm/backoff.h| 69 +++-- arch/sparc/include/asm/compat.h | 5 +++-- arch/sparc/include/asm/processor_64.h | 17 - arch/sparc/include/asm/prom.h | 5 + arch/sparc/include/asm/thread_info_64.h | 5 + arch/sparc/include/asm/ttable.h | 24 arch/sparc/include/uapi/asm/unistd.h| 7 ++- arch/sparc/kernel/entry.h | 7 +++ arch/sparc/kernel/leon_kernel.c | 6 -- arch/sparc/kernel/perf_event.c | 22 -- arch/sparc/kernel/process_64.c | 42 +++--- arch/sparc/kernel/ptrace_64.c | 4 ++-- arch/sparc/kernel/setup_64.c| 21 + arch/sparc/kernel/sys_sparc_64.c| 5 + arch/sparc/kernel/systbls_32.S | 1 + arch/sparc/kernel/systbls_64.S | 2 ++ arch/sparc/kernel/unaligned_64.c| 36 +++- arch/sparc/kernel/visemul.c | 23 ++- arch/sparc/kernel/vmlinux.lds.S | 5 + arch/sparc/kernel/winfixup.S| 2 ++ arch/sparc/lib/atomic_64.S | 16 +++- arch/sparc/lib/ksyms.c | 1 + arch/sparc/math-emu/math_64.c | 2 +- drivers/base/platform.c | 7 +++ drivers/gpio/Kconfig| 2 +- drivers/scsi/qlogicpti.c| 13 + include/linux/of_address.h | 2 ++ 38 files changed, 291 insertions(+), 97 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] target: Update copyright ownership to 2012
On Sat, Nov 10, 2012 at 12:15:21PM +0200, Kirill A. Shutemov wrote: > On Fri, Nov 09, 2012 at 11:00:14PM +, Nicholas A. Bellinger wrote: > > From: Nicholas Bellinger > > > > Hello everyone, > > > > This patch to update copyright year to current for principal target core > > ownership is now being pushed into target-pending/for-next. > > > > Signed-off-by: Nicholas Bellinger > > --- > > drivers/target/target_core_alua.c|5 +++-- > > drivers/target/target_core_configfs.c|5 +++-- > > drivers/target/target_core_device.c |7 +++ > > drivers/target/target_core_fabric_configfs.c |7 --- > > drivers/target/target_core_fabric_lib.c |5 +++-- > > drivers/target/target_core_file.c|7 +++ > > drivers/target/target_core_hba.c |7 +++ > > drivers/target/target_core_iblock.c |7 +++ > > drivers/target/target_core_pr.c |5 +++-- > > drivers/target/target_core_pscsi.c |7 +++ > > drivers/target/target_core_rd.c |7 +++ > > drivers/target/target_core_sbc.c |7 +++ > > drivers/target/target_core_spc.c |7 +++ > > drivers/target/target_core_stat.c|7 +++ > > drivers/target/target_core_tmr.c |5 +++-- > > drivers/target/target_core_tpg.c |7 +++ > > drivers/target/target_core_transport.c |7 +++ > > drivers/target/target_core_ua.c |5 +++-- > > 18 files changed, 55 insertions(+), 59 deletions(-) > > > > diff --git a/drivers/target/target_core_alua.c > > b/drivers/target/target_core_alua.c > > index 4c8eea2..035c606 100644 > > --- a/drivers/target/target_core_alua.c > > +++ b/drivers/target/target_core_alua.c > > @@ -3,8 +3,9 @@ > > * > > * This file contains SPC-3 compliant asymmetric logical unit assigntment > > (ALUA) > > * > > - * Copyright (c) 2009-2010 Rising Tide Systems > > - * Copyright (c) 2009-2010 Linux-iSCSI.org > > + * (c) Copyright 2009-2012 RisingTide Systems LLC. > > + * > > + * Licensed to the Linux Foundation under the General Public License (GPL) > > version 2. > > * > > * Nicholas A. Bellinger > > * > > Why do you remove Linux-iSCSI.org copyright? > And: - * Copyright (c) 2005 PyX Technologies, Inc. - * Copyright (c) 2005-2006 SBE, Inc. All Rights Reserved. on some other files. -- Pasi -- 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] Fix perf mmap limitations on 32-bit.
This is a suggested patch to fix the bug I reported at:
http://marc.info/?l=linux-kernel=135033028924652=2
Essentially, there is a hard requirement that when perf analyzes a
trace, it must have the entire thing mmap()'d.
Therefore the scheme used on 32-bit where we have a fixed (8) number
of 32MB mmaps, and cycle through them, simply does not work.
One of the reasons this requirement exists is because the iterators
maintain references to perf entry objects and those references don't
just simply go away when this mmap code decides to cycle an old mmap
area out and reuse it. At this point, those entry pointers now point
to garbage resulting in unpredictable behavior and crashes.
It is better to try to mmap() as much as we can and if we do actually
run into address space limitations, the failure of the mmap() call
will indicate that and stop processing.
I noticed that perf_session->mmap_window is set to a constant in one
location, and only used in one other location. So I got rid of it
altogether.
So we adjust the size of the mmaps[] array to the maximum we could
need. On 64-bit we only need one slot. On 32-bit we could need
up to 128 (128 * 32MB == 4GB).
I've verified that this allows a large (~600MB) perf.data file to
be analyzed properly with a 32-bit perf binary, which previously
was not possible.
Signed-off-by: David S. Miller
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 8cdd232..2cd3cc3 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -128,15 +128,6 @@ struct perf_session *perf_session__new(const char
*filename, int mode,
goto out;
memcpy(self->filename, filename, len);
- /*
-* On 64bit we can mmap the data file in one go. No need for tiny mmap
-* slices. On 32bit we use 32MB.
-*/
-#if BITS_PER_LONG == 64
- self->mmap_window = ULLONG_MAX;
-#else
- self->mmap_window = 32 * 1024 * 1024ULL;
-#endif
self->machines = RB_ROOT;
self->repipe = repipe;
INIT_LIST_HEAD(>ordered_samples.samples);
@@ -1369,6 +1360,18 @@ fetch_mmaped_event(struct perf_session *session,
return event;
}
+/*
+ * On 64bit we can mmap the data file in one go. No need for tiny mmap
+ * slices. On 32bit we use 32MB.
+ */
+#if BITS_PER_LONG == 64
+#define MMAP_SIZE ULLONG_MAX
+#define NUM_MMAPS 1
+#else
+#define MMAP_SIZE (32 * 1024 * 1024ULL)
+#define NUM_MMAPS 128
+#endif
+
int __perf_session__process_events(struct perf_session *session,
u64 data_offset, u64 data_size,
u64 file_size, struct perf_tool *tool)
@@ -1376,7 +1379,7 @@ int __perf_session__process_events(struct perf_session
*session,
u64 head, page_offset, file_offset, file_pos, progress_next;
int err, mmap_prot, mmap_flags, map_idx = 0;
size_t page_size, mmap_size;
- char *buf, *mmaps[8];
+ char *buf, *mmaps[NUM_MMAPS];
union perf_event *event;
uint32_t size;
@@ -1393,7 +1396,7 @@ int __perf_session__process_events(struct perf_session
*session,
progress_next = file_size / 16;
- mmap_size = session->mmap_window;
+ mmap_size = MMAP_SIZE;
if (mmap_size > file_size)
mmap_size = file_size;
diff --git a/tools/perf/util/session.h b/tools/perf/util/session.h
index dd64261..903966b 100644
--- a/tools/perf/util/session.h
+++ b/tools/perf/util/session.h
@@ -29,7 +29,6 @@ struct ordered_samples {
struct perf_session {
struct perf_header header;
unsigned long size;
- unsigned long mmap_window;
struct machine host_machine;
struct rb_root machines;
struct perf_evlist *evlist;
--
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: Issues with "x86, um: switch to generic fork/vfork/clone" commit
On Sat, Nov 10, 2012 at 07:33:39AM +, Al Viro wrote: > I think I see what's going on there. It's PTREGSCALL blindly used for > clone wrapper in ia32entry.S. FWIW, it's wrong for all of those > suckers, anyway: > * fork/clone/vfork need to save extra registers, but don't need > to restore them; after unification we don't need pt_regs argument for any > of those - for fork/vfork it's useless, for clone it breaks things. > * execve doesn't need pt_regs argument; harmless, but useless. > * for sigaltstack() we simply need to get rid of stupid pt_regs > argument, along with the wrapper; current_pt_regs()->sp is all it needs. > * for sigreturn/rt_sigreturn we need to restore extra registers, > but we do *not* need to save them; just leave the space on stack. And > no need to pass pt_regs either - it'll be current_pt_regs() anyway. > * iopl() doesn't need to save/restore extras and it doesn't need > pt_regs argument - it's going to be current_pt_regs(). Alas, sigaltack() and iopl() do need a bit of a wrapper; they don't care about extras, but they wants ->sp and ->flags resp., which means needing to go through FIXUP_TOP_OF_STACK on amd64 ;-/ > On top of all that, there's an extra piece of crap - different order of > arguments for native and compat clone. ... and the same commit slightly buggers clone(2) on amd64 as well. Grr... Anyway, fixed and pushed; please, test for-next when it propagates, head should be at fae45353de587ae6a949dbf21ee06d5dd652248c -- 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 resend] printk: drop ambiguous LOG_CONT flag
Hi Greg.
This still needs a small fix, see below.
Am 03.11.2012 22:12, schrieb Jan H. Schönherr:
> From: Jan H. Schönherr
>
> The meaning of LOG_CONT is unclear, i. e., whether a message is a starting,
> ending, or middle fragment. Unfortunately, this cannot be inferred from
> the LOG_PREFIX and LOG_NEWLINE flags, as they are not always kept.
> Furthermore, in some cases LOG_CONT is set, although it is unknown if
> there will be a continuation. This leads to wrongly concatenated output.
>
> Fix this by dropping LOG_CONT and rely on LOG_PREFIX and LOG_NEWLINE to
> distinguish the type of fragment. That is, if LOG_PREFIX is set, this
> fragment does not continue the previous fragment. And if LOG_NEWLINE is
> set, this fragment is not continued by the next fragment.
>
> (Unfortunately, we still have to look at the previous fragment to catch the
> case of an unset LOG_PREFIX on this fragment, but a set LOG_NEWLINE on
> the previous fragment.)
>
> Tested-By: Kay Sievers
> Signed-off-by: Jan H. Schönherr
> ---
> Against linux-next from 20121102, added Kay's tested-by.
> ---
> kernel/printk.c | 57
> +
> 1 file changed, 33 insertions(+), 24 deletions(-)
>
> diff --git a/kernel/printk.c b/kernel/printk.c
> index 22e070f..e8e4e67 100644
> --- a/kernel/printk.c
> +++ b/kernel/printk.c
[...]
> @@ -1581,12 +1585,16 @@ asmlinkage int vprintk_emit(int facility, int level,
>* Flush the conflicting buffer. An earlier newline was missing,
>* or another task also prints continuation lines.
>*/
> - if (cont.len && (lflags & LOG_PREFIX || cont.owner != current))
> - cont_flush(LOG_NEWLINE);
> + if (cont.len) {
This line should have been:
+ if (cont.len && !cont.flushed) {
The effect of this is that we now avoid to add a superfluous newline
over and over (due to setting LOG_PREFIX), when the cont buffer has been
flushed but not yet printed.
> + if (cont.owner != current)
> + lflags |= LOG_PREFIX;
> + if (lflags & LOG_PREFIX)
> + cont_flush(LOG_NEWLINE);
> + }
>
> /* buffer line if possible, otherwise store it right away */
> - if (!cont_add(facility, level, text, text_len))
> - log_store(facility, level, lflags | LOG_CONT, 0,
> + if (!cont_add(facility, level, lflags, text, text_len))
> + log_store(facility, level, lflags, 0,
> dict, dictlen, text, text_len);
> } else {
> bool stored = false;
> @@ -1599,7 +1607,8 @@ asmlinkage int vprintk_emit(int facility, int level,
>*/
> if (cont.len && cont.owner == current) {
For symmetry reasons, the "if" here could use the same change. But here it
does not really matter as currently cont_add() and cont_flush() are NOPs when
cont.flushed is set.
> if (!(lflags & LOG_PREFIX))
> - stored = cont_add(facility, level, text,
> text_len);
> + stored = cont_add(facility, level, lflags,
> + text, text_len);
> cont_flush(LOG_NEWLINE);
> }
As I've not yet seen this patch turn up anywhere, I'm preparing a v2 of this
together with a couple of other patches that are now more or less ready.
Regards
Jan
--
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 00/16 v3] f2fs: introduce flash-friendly file system
Am Samstag, 10. November 2012 schrieb Martin Steigerwald: > merkaba:~> mkfs.f2fs /dev/sdb1 > Info: sector size = 512 > Info: total sectors = 4093951 (in 512bytes) > Info: zone aligned segment0 blkaddr: 256 > Info: This device doesn't support TRIM > Info: format successful > merkaba:~> mount -t f2fs /dev/sdb1 /mnt/zeit > merkaba:~> fio /tmp/usb-stick.job > seq-read: (g=0): rw=read, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=4 > rand-read: (g=1): rw=randread, bs=4K-4K/4K-4K, ioengine=libaio, > iodepth=4 seq-write: (g=2): rw=write, bs=4K-4K/4K-4K, ioengine=libaio, > iodepth=4 rand-write: (g=3): rw=randwrite, bs=4K-4K/4K-4K, > ioengine=libaio, iodepth=4 2.0.8 > Starting 4 processes > seq-read: Laying out IO file(s) (1 file(s) / 512MB) > Jobs: 1 (f=1): [___w] [57.2% done] [0K/703K /s] [0 /175 iops] [eta > 03m:00s] seq-read: (groupid=0, jobs=1): err= 0: pid=7819 > read : io=470600KB, bw=7843.8KB/s, iops=1960 , runt= 60002msec I forgot the job file I used: merkaba:~> cat /tmp/usb-stick.job [global] bs=4k ioengine=libaio size=512m direct=1 iodepth=4 runtime=60 directory=/mnt/zeit filename=test.file [seq-read] rw=read stonewall [rand-read] rw=randread stonewall [seq-write] rw=write stonewall [rand-write] rw=randwrite stonewall Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- 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 8/7] pppoatm: fix missing wakeup in pppoatm_send()
From: David Woodhouse Date: Sat, 10 Nov 2012 07:36:13 + > I was hoping for an ack from Chas and/or Krzysztof, especially as I > hadn't tested my patch. So hopefully there'll be a v4 series of 8 > patches, including this one... and all from the same person, which > makes it slightly easier to follow :) Ok, great. -- 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 00/16 v3] f2fs: introduce flash-friendly file system
Am Freitag, 2. November 2012 schrieb Kim Jaegeuk:
> 2012/11/2 Martin Steigerwald
>
> > Am Mittwoch, 31. Oktober 2012 schrieb Jaegeuk Kim:
> > > Change log from v2:
> > > o Fix compilation error for arm [Max]
> > > o Move proc entries to debugfs [Greg]
> > > o Add i_atime, i_generation, etc [Neil]
> > > o Support NFS export [Changman]
> > > o Move the f2fs magic number [Marco]
> > > o Add s_time_gran [Marco]
> > > o Fix f2fs_truncate [Marco]
> > > o Enhance f2fs document [Vyacheslav]
> > > o Support uuid and add additional comments [Vyacheslav]
> > > o Change superblock offset [Vyacheslav]
> > > o Fix some bugs and return values [Vyacheslav]
> > > o Improve initial mount time [Jaegeuk]
> > > o Fix f2fs-tools environment [Mike]
> > >
> > > I've set up a git tree in sf.net for f2fs-tools.
> > > Please download f2fs-tools by tag: for_patch_set_v3.
> >
> > I like to try this out.
> >
> > Do you have kernel code available in some git repo? I didn´t find
> > anything on git.kernel.org? Otherwise I take the patches from your
> > mails.
>
> At this moment, there is no f2fs-repo yet in public.
> If f2fs is merged, I'd like to make a dev tree somewhere.
> I really want to make the dev tree in kernel.org later, but it totally
> depends on the maintainers' decision.
> Before then, I apologize to retrieve f2fs sources from LKML.
After getting behind an USB blocks a CPU on my laptop problem I tried f2fs.
Some first tests on a 2GB extrememory USB 2.0 stick:
[ 239.731162] usb 1-1.1: new high-speed USB device number 8 using ehci_hcd
[ 239.818325] usb 1-1.1: New USB device found, idVendor=1307, idProduct=0163
[ 239.818339] usb 1-1.1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 239.818346] usb 1-1.1: Product: USB Mass Storage Device
[ 239.818352] usb 1-1.1: Manufacturer: USBest Technology
[ 239.818357] usb 1-1.1: SerialNumber: […]
[ 239.820595] scsi9 : usb-storage 1-1.1:1.0
[ 240.821487] scsi 9:0:0:0: Direct-Access TinyDisk 2007-05-12 0.00
PQ: 0 ANSI: 2
[ 240.825217] sd 9:0:0:0: Attached scsi generic sg2 type 0
[ 240.826318] sd 9:0:0:0: [sdb] 4095999 512-byte logical blocks: (2.09 GB/1.95
GiB)
[ 240.827126] sd 9:0:0:0: [sdb] Write Protect is off
[ 240.827143] sd 9:0:0:0: [sdb] Mode Sense: 00 00 00 00
[ 240.828161] sd 9:0:0:0: [sdb] Asking for cache data failed
[ 240.828174] sd 9:0:0:0: [sdb] Assuming drive cache: write through
[ 240.833414] sd 9:0:0:0: [sdb] Asking for cache data failed
[ 240.833428] sd 9:0:0:0: [sdb] Assuming drive cache: write through
[ 240.894728] sdb: unknown partition table
[ 240.899104] sd 9:0:0:0: [sdb] Asking for cache data failed
[ 240.899109] sd 9:0:0:0: [sdb] Assuming drive cache: write through
[ 240.899113] sd 9:0:0:0: [sdb] Attached SCSI removable disk
merkaba:~> fdisk /dev/sdb
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF
disklabel
Building a new DOS disklabel with disk identifier 0x7babe038.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.
Warning: invalid flag 0x of partition table 4 will be corrected by w(rite)
Command (m for help): n
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-4095998, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-4095998, default 4095998):
Using default value 4095998
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
merkaba:~> dmesg | tail -1
[ 276.342638] sdb: sdb1
merkaba:~> mkfs.f2fs /dev/sdb1
Info: sector size = 512
Info: total sectors = 4093951 (in 512bytes)
Info: zone aligned segment0 blkaddr: 256
Info: This device doesn't support TRIM
Info: format successful
merkaba:~> mount /dev/sdb1 /mnt/zeit
mount: you must specify the filesystem type
merkaba:~#32> mount -t f2fs /dev/sdb1 /mnt/zeit
merkaba:~> df -hT /mnt/zeit
DateisystemTyp Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sdb1 f2fs 2,0G147M 1,8G8% /mnt/zeit
merkaba:~> dd if=/dev/zero of=/mnt/zeit/zeros bs=1M count=200 conv=fsync
200+0 Datensätze ein
200+0 Datensätze aus
209715200 Bytes (210 MB) kopiert, 14,4896 s, 14,5 MB/s
merkaba:~> echo 3 > /proc/sys/vm/drop_caches; dd if=/mnt/zeit/zeros
of=/dev/null bs=1M count=200
200+0 Datensätze ein
200+0 Datensätze aus
209715200 Bytes (210 MB) kopiert, 8,7358 s, 24,0 MB/s
merkaba:~> umount /mnt/zeit
merkaba:~> mkfs.ext4 /dev/sdb1
mke2fs 1.42.5 (29-Jul-2012)
Dateisystem-Label=
OS-Typ: Linux
Blockgröße=4096 (log=2)
Fragmentgröße=4096 (log=2)
Stride=0 Blöcke, Stripebreite=0 Blöcke
128000 Inodes, 511743 Blöcke
25587 Blöcke (5.00%) reserviert für den Superuser
Erster Datenblock=0
Maximale Dateisystem-Blöcke=524288000
16 Blockgruppen
32768 Blöcke pro Gruppe, 32768 Fragmente pro Gruppe
8000 Inodes pro Gruppe
Re: [PATCH] usb: gadget: ncm: correct endianess conversion
Hi, On Fri, Nov 9, 2012 at 12:53 PM, Felipe Balbi wrote: > Hi, > > On Fri, Nov 09, 2012 at 10:31:47AM +0100, Dmytro Milinevskyy wrote: >> Hi Felipe, >> >> On Thu, Nov 8, 2012 at 8:30 PM, Felipe Balbi wrote: >> > Hi, >> > >> > On Thu, Nov 08, 2012 at 08:07:57PM +0100, Dmytro Milinevskyy wrote: >> >> > On Wed, Nov 07, 2012 at 02:14:00PM +0100, Dmytro Milinevskyy wrote: >> >> >> Unfortunately I have some issues with git send-email. >> >> >> I've attached the patch itself .. >> >> > >> >> > I'll apply it like that this time, but try to figure out how to send >> >> > patches properly. We have some very helpful hints on >> >> > Documentation/email-clients.txt which are hugely underused ;-) >> >> > >> >> well, I try to follow the rules as much as possible as long as tools >> >> work ... =) >> > >> > git send-email has thousands of users and it works fine for them >> > (including myself). Maybe you just misconfigured it ?!? ;-) >> > >> No, I was using it in the past w/o any issue. >> In fact initial versions of the patch were sent exactly with git-send-email. >> >> However I lost my internet connection at home(some issues with ISP) >> and at work place network environment somehow blocks >> git-send-email(though thunderbird still can connect to the smtp server >> ..). > > I don't think smtp server can make that distinction. Except for the > message-id, there's nothing there which would help smtp server to figure > out you're using git send-email. On top of that, it would be just extra > work to maintain rules to block a tool which is essentially just sending > an email. > > Make sure you're not missing some authentication with the mail server on > your git send-email configuration. > > my 2 cents. Thanks a lot, I very appreciate your help. I even tried to use same laptop with same version of git I used to send the patch for the first time but it didn't help. Likely there's a network configuration that is blocking git-send-email. I will try to figure it out with our system administrators. cheers, -- dmytro > -- > balbi -- 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/
pull request: bluetooth 2012-11-09
Hi John, A few important fixes to go into 3.7. There is a new hw support by Marcos Chaparro. Johan added a memory leak fix and hci device index list fix. Also Marcel fixed a race condition in the device set up that was prevent the bt monitor to work properly. Last, Paulo Sérgio added a fix to the error status when pairing for LE fails. This was prevent userspace to work to handle the failure properly. Please pull! or let me know of any issues. Thanks. Gustavo --- The following changes since commit 6fe7cc71bbf3a0bc28c9cec3c00bc11e81344412: ath9k: Test for TID only in BlockAcks while checking tx status (2012-10-30 15:58:54 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth master for you to fetch changes up to 482049f75750d73358e65236b933417b69f9cc25: Bluetooth: Fix memory leak when removing a UUID (2012-11-09 16:45:37 +0100) Johan Hedberg (2): Bluetooth: Fix having bogus entries in mgmt_read_index_list reply Bluetooth: Fix memory leak when removing a UUID Marcel Holtmann (1): Bluetooth: Notify about device registration before power on Marcos Chaparro (1): Bluetooth: ath3k: Add support for VAIO VPCEH [0489:e027] Paulo Sérgio (1): Bluetooth: Fix error status when pairing fails drivers/bluetooth/ath3k.c | 1 + drivers/bluetooth/btusb.c | 1 + net/bluetooth/hci_core.c | 4 ++-- net/bluetooth/mgmt.c | 12 +++- net/bluetooth/smp.c | 2 +- 5 files changed, 12 insertions(+), 8 deletions(-) pgptuPdxdMnWD.pgp Description: PGP signature
Re: [PATCH 1/2] drm: Add NVIDIA Tegra20 support
On 09.11.2012 23:03, Thierry Reding wrote: On Fri, Nov 09, 2012 at 10:26:27AM -0600, Rob Clark wrote: hmm, are these values defined by the hw? They look like register offsets into the DC block? I don't think they are defined by the hardware. From what I gather these can arbitrarily be assigned by software. If things actually work the way I think they do, then eventually these values could be allocated by the host1x_register_client() function and stored within the host1x_client structure, so that each HW block can program them into the corresponding register. These are host1x sync points. Sync points are used to synchronize work between host1x, host1x client units (like DC, 2D, EPP, etc), and CPU. Tegra2 TRM now contains chapters for HOST1X, 2D and EPP, so it has some more details. The assignment of sync points is a software policy. Depending on programming model of client unit, one or more sync points are used for each. For example, for each DC we have one sync point assigned to vblank, and one for each DC window. For 2D, we'd have one sync point, and a choice of using the same of different sync point for EPP. We could either assign sync point registers by hard coding, or assign them dynamically one per client unit, and possibly an additional one depending on the programming model. Sync points are a scarce resource, so we've so far preferred to do static assignment to catch overallocation as early as possible. Terje -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] spi / ACPI: add ACPI enumeration support
On Sat, Nov 10, 2012 at 4:10 AM, Rafael J. Wysocki wrote: > On Friday, November 09, 2012 09:53:26 AM Bjorn Helgaas wrote: >> On Fri, Nov 9, 2012 at 9:43 AM, Grant Likely >> wrote: >> > On Fri, Nov 9, 2012 at 4:35 PM, Bjorn Helgaas wrote: >> >> On Fri, Nov 9, 2012 at 8:45 AM, Grant Likely >> >> wrote: >> >>> On Fri, Nov 9, 2012 at 3:11 PM, Bjorn Helgaas >> >>> wrote: >> [+cc Greg, Peter, Tony since they acked the original patch [1]] >> >> On Thu, Nov 8, 2012 at 1:04 PM, Mika Westerberg >> wrote: >> > On Thu, Nov 08, 2012 at 12:32:25PM -0700, Bjorn Helgaas wrote: >> >> Struct device_driver is a generic structure, so it seems strange to >> >> have to include non-generic things like of_device_id and now >> >> acpi_match_table there. >> > >> > Yes, but in a sense the DT and ACPI are "generic". So that they are >> > used to >> > describe the configuration of a machine. >> >> What I meant by "generic" was "useful across all architectures." The >> new acpi_match_table and acpi_handle fields [1] are not generic in >> that sense because they're present on all architectures but used only >> on x86 and ia64. The existing of_match_table and of_node are >> similarly unused on many architectures. This doesn't seem like a >> scalable strategy to me. Are we going to add a pnpbios_node for x86 >> PNPBIOS machines without ACPI, a pdc_hpa for parisc machines with PDC, >> etc.? >> >> [1] https://patchwork.kernel.org/patch/1677221/ >> >>> >> >>> Ultimately yes, I think that is what we want to do, >> >> >> >> Just to be clear, you think we *should* add things like pnpbios_node, >> >> pdc_hpa, etc., to struct device, one field for every scheme of telling >> >> the OS about non-enumerable devices, where only one of the N fields is >> >> used on any given machine? That seems surprising to me, but maybe I >> >> just need to be educated :) >> > >> > Ah, I see what you're asking. >> > >> > In the short term, yes but only because we don't have any other >> > alternative. What I'd really rather have is a safe way to attach datum >> > (ie. acpi_device or device_node) to a struct device and get it back >> > later in a type safe way. >> >> Yep, *that* makes perfect sense to me. Something along these lines, maybe: >> >> #define dev_is_acpi(d)((d)->bus == _bus_type) > > No, that's not right. It won't work for things like SPI and I2C with a > "backing" ACPI device node anyway (and for PCI too, by the way :-)). > >> #define dev_acpi_handle(d)(dev_is_acpi(d) ? (acpi_handle) >> d->datum : NULL) > > The problem basically is how we can tell that the given struct device has > a "backing" object containing device information (e.g. resources) and what > that "backing" object is. For device trees that would be a struct device_node > and for ACPI that would be an acpi_handle or a struct acpi_device etc. And by > the way, they _can_ be used simultaneously, in principle. > > So we need something like of_node(dev) or acpi_node(dev), but that can't be > something following two pointers or calling a function just in order to check > if the pointer _is_ _there_ in either case. > > And since we added of_node to struct device at one point, it is only logical > to > treat ACPI in the same way. If we come up with a better idea _later_, then we > can convert _all_ things to this new idea, whatever it is. > > Are you seriously expecting us to come up with such an idea on the fly just so > that we can use ACPI support, which already is there in the form of > archdata.acpi_handle anyway, on equal footing with Device Trees? Of course not. I'm just trying to understand where we're headed. That was not obvious from the patches I've seen so far. -- 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] spi: tegra: sequence compatible strings as per preference
On Fri, Nov 09, 2012 at 10:28:38AM -0700, Stephen Warren wrote: > On 11/09/2012 10:10 AM, Mark Brown wrote: > > On Fri, Nov 09, 2012 at 10:04:56AM -0700, Stephen Warren wrote: > > > >> However just FYI, it should not be necessary for correctness; The > >> DT matching order is supposed to be driven purely by the order of > >> the compatible values in the DT now, and not affected by the > >> order of values in the table. (This wasn't always the case, but > >> was a bug that was fixed IIRC by Thierry Reding). > > > > I guess the driver is being used backported in older kernels which > > don't have that fix? > > That sounds likely. Laxman, it'd be a good idea to track down the fix > to the DT matching code and backport it, so that hard-to debug issues > aren't caused by the lack of that patch! Unfortunately the patch that was supposed to fixed this caused a regression and was therefore reverted. Rob (Cc'ed) said there was a patch to fix it properly and was supposed to go into 3.6 but it seems that never happened. Rob, what's the status on this? The revert is here: bc51b0c22cebf5c311a6f1895fcca9f78efd0478 Thierry pgpksoHuxEsub.pgp Description: PGP signature
Re: Better support for (desktop) file search / indexing applications
Am Donnerstag, 1. November 2012 schrieb Tvrtko Ursulin: > On Thursday 01 November 2012 13:52:42 Martin Steigerwald wrote: > ... > > > The following two main issues led to the discussion about adding > > notification about user inotify watch limit or even having it raised > > automatically via some policy kit mechanism: > > > > 1) Watches are not working recursively. Thus one has to add a watch > > to each sub directory. > > > > 2) There are inotify file move events. But one has to watch source > > and destination directory to get notified of a file move between > > these. Thus one has to watch each directory again. File moves > > outside the watched home directory will go unnotified unless every > > other accessible directory is watched as well. > > > > > > What would be nice to have for file indexers would be: > > > > 1) Recursive notifications. I.e. one watch for /home/martin can > > notify about everything what happens in sub directories of that > > directory. > > > > 2) File move events that work from the source directory. I.e. if > > watching a directory like /home/martin recursively it would be nice > > to be notified about: > > > > a) A file is moved from one sub directory inside /home/martin to > > another one inside it. > > > > b) A file is moved outside /home/martin > > > > While these enhancement would likely fix the issues desktop file > > search applications have with the kernel notification APIs, there > > might be other approaches I did not yet thought off... so feel free > > to comment with your thoughts on it. > > I will only comment on the real time indexing part since I had some > part in the inception of fanotify and still remember a thing or two > about it. > > Perhaps you should look into how hard would it be to add directory or > rename, and unlink events to fanotify. It may not be too hard. > > In that case, even though it does not support recursive directory > watches (I tried to implement this some time around 2009. but found it > impossible to wedge into the fanotify locking model), it does support > mount point watches. Which for the desktop use might be sufficient, > assuming /home is typically a separate filesystem. > > Downside with this approach is that you have to filter out the events > you do not care about like /home/some-other-user, or even more if > /home is not a separate filesystem. Which with the current fanotify > state can be done using paths, but that includes resolving a link in > procfs which may be a too expensive thing to do. > > Or perhaps it is acceptable, if you for example only cared about > CLOSE_WRITE events (closure of file which were open for writing). > > So I think for this part you have two options, have a go of extending > directory watches to be recursive, or live with the mount watches > giving you too much traffic. Thanks for your suggestions. Still fanotify needs root access and thus this would need a daemon running as root and some policy kit stuff to access it and in case of mount point watches robust and secure code so that each user may only see his/her own results. Any other ideas from anyone? Thanks. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- 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/4] mfd: ab8500: add devicetree support for fuelgauge
On 11/07/2012 07:45 PM, Rajanikanth H V wrote:
> On Thu, 1 Nov 2012, Francesco Lavra wrote:
> [...]
>>> +btech = of_get_property(np_bat_supply,
>>> +"stericsson,battery-type", NULL);
>>> +if (!btech) {
>>> +dev_warn(dev, "missing property battery-name/type\n");
>>> +strcpy(bat_tech, "UNKNOWN");
>>> +} else {
>>> +strcpy(bat_tech, btech);
>>> +}
>>
>> I don't get the point of declaring the char array and copying the string
>> in it, when you could simply use just the pointer returned by
>> of_get_property().
>
> I am considering a corner case where in 'battery-type' property is not
> present and battery is connected.In this case i promote battery to
> UNKNOWN from null.
You could achieve the same result without using the char array, with
this assignment:
btech = "UNKNOWN";
> FYI: Further, btemp driver will identify the connected battery based on
> resistance value and decide to use.
> Ref: ab8500_btemp_id(...) ab8500_btemp.c
>
>> Anyway, if the string property is longer than 8 characters, you are
>> writing past the size of the destination array.
>
> i believe it is safe as power_supply.h comprises defines having battery
> technology type in 4 characters length which is normally the case and
> 7 chars length being "UNKNOWN" seldom referred
You should be able to handle whatever the device tree contains, and if
it contains unexpected data this is not a good excuse for locking up the
system.
--
Francesco
--
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: [REGRESSION] 3.7-rc3+git hard lockup on CPU after inserting/removing USB stick
Am Samstag, 10. November 2012 schrieb Martin Steigerwald: > CC´d bad patch author Chuansheng as well as Ingo and Thomas as the > issue seems to be thread irqs related. > > Am Mittwoch, 7. November 2012 schrieb Martin Steigerwald: > > Am Mittwoch, 7. November 2012 schrieb Greg Kroah-Hartman: > > > On Wed, Nov 07, 2012 at 03:01:38PM +0100, Martin Steigerwald wrote: > > > > Hi! > > > > > > > > I had this with something in between 3.7-rc3 und 3.7-rc4 after > > > > inserting and removing an USB stick. This example is with a > > > > kernel + f2fs patches v3, but I had this with 3.7-rc3 as well. > > > > > > Ok, so it's not a new thing introduced in 3.7-rc4 (which is good, > > > as there wasn't any USB patches added between -rc3 and -rc4.) > > > > > > Does it also happen on -rc2? Anything older? Can you run 'git > > > bisect' to try to track it down? > > > > It appears to be worse with 3.7-rc1. The machine basically locked up > > a few moments after inserting the stick. > > > > First time I was on some tty and I saw lots of backtraces flowing by > > the process of which the BTRFS on /, which resides on an unrelated > > internal Intel SSD 320, was switched to read only. There have been > > pauses between backtraces. Second I was in KDE session which > > basically locked up soon as well. No mouse pointer movements where > > possible, no switching to tty1. > > > > I only have the last part of the backtrace of the first occurence as > > photo. > > > > Nothing was saved on SSD. > > > > I do not want to go an earlier 3.7 version than rc1 on this > > production machine. > > I bisected this after having made a backup: [… bisect log and some explainations …] > The first bad commit is: > > commit 73d4066055e0e2830533041f4b91df8e6e5976ff > Author: Chuansheng Liu > Date: Tue Sep 11 16:00:30 2012 +0800 > > USB/host: Cleanup unneccessary irq disable code > > Because the IRQF_DISABLED as the flag is now a NOOP and has been > deprecated and in hardirq context the interrupt is disabled. > > so in usb/host code: > Removing the usage of flag IRQF_DISABLED; > Removing the calling local_irq save/restore actions in irq > handler usb_hcd_irq(); > > Signed-off-by: liu chuansheng > Acked-by: Alan Stern > Signed-off-by: Greg Kroah-Hartman > > > But: > > This ony happens with threadirqs option! Just another note: irq/16-ehci_hcd was taking >99% CPU. It had PR -51 in top and I think this was the task that made the CPU core stuck. I have a short dmesg piece from the bad commit kernel. Attached. Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 dmesg-on-bad-commit-kernel.txt.xz Description: application/xz
Re: [REGRESSION] 3.7-rc3+git hard lockup on CPU after inserting/removing USB stick
CC´d bad patch author Chuansheng as well as Ingo and Thomas as the issue seems to be thread irqs related. Am Mittwoch, 7. November 2012 schrieb Martin Steigerwald: > Am Mittwoch, 7. November 2012 schrieb Greg Kroah-Hartman: > > On Wed, Nov 07, 2012 at 03:01:38PM +0100, Martin Steigerwald wrote: > > > Hi! > > > > > > I had this with something in between 3.7-rc3 und 3.7-rc4 after > > > inserting and removing an USB stick. This example is with a kernel > > > + f2fs patches v3, but I had this with 3.7-rc3 as well. > > > > Ok, so it's not a new thing introduced in 3.7-rc4 (which is good, as > > there wasn't any USB patches added between -rc3 and -rc4.) > > > > Does it also happen on -rc2? Anything older? Can you run 'git > > bisect' to try to track it down? > > It appears to be worse with 3.7-rc1. The machine basically locked up a > few moments after inserting the stick. > > First time I was on some tty and I saw lots of backtraces flowing by > the process of which the BTRFS on /, which resides on an unrelated > internal Intel SSD 320, was switched to read only. There have been > pauses between backtraces. Second I was in KDE session which basically > locked up soon as well. No mouse pointer movements where possible, no > switching to tty1. > > I only have the last part of the backtrace of the first occurence as > photo. > > Nothing was saved on SSD. > > I do not want to go an earlier 3.7 version than rc1 on this production > machine. I bisected this after having made a backup: martin@merkaba:~[…]/linux-2.6> git bisect log # bad: [ddffeb8c4d0331609ef2581d84de4d763607bd37] Linux 3.7-rc1 # good: [a0d271cbfed1dd50278c6b06bead3d00ba0a88f9] Linux 3.6 git bisect start 'v3.7-rc1' 'v3.6' # bad: [24d7b40a60cf19008334bcbcbd98da374d4d9c64] ARM: OMAP2+: PM: MPU DVFS: use generic CPU device for MPU-SS git bisect bad 24d7b40a60cf19008334bcbcbd98da374d4d9c64 # skip: [d9a807461fc8cc0d6ba589ea0730d139122af012] Merge tag 'usb-3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb git bisect skip d9a807461fc8cc0d6ba589ea0730d139122af012 # good: [832defbb58061fedb7a5c43aab7d762afaac2cc9] staging: comedi: s626: remove boardinfo git bisect good 832defbb58061fedb7a5c43aab7d762afaac2cc9 # skip: [6d55d5968a8622f3ea20ec40737aea1cfba6438c] Merge branch 'next/soc' into HEAD git bisect skip 6d55d5968a8622f3ea20ec40737aea1cfba6438c # good: [b64365a52625e6ec5cf05dd984fba0fa69b24623] drivers/misc/ti-st: chip_disable on timeout git bisect good b64365a52625e6ec5cf05dd984fba0fa69b24623 # bad: [186f3812f5005d3d5435f69f672971afdae3e732] USB: serial: ssu100.c: remove debug module parameter git bisect bad 186f3812f5005d3d5435f69f672971afdae3e732 # bad: [7135f08e47de094f8748507806efa8d7ba27a964] Merge tag 'gadget-for-v3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next git bisect bad 7135f08e47de094f8748507806efa8d7ba27a964 # good: [3a22b872e923954853cabd5a18f41da1846bccdb] usb: Fail a get config when the port is powered off. git bisect good 3a22b872e923954853cabd5a18f41da1846bccdb # good: [c2ec75c25112c9e0d9053f55ba8cf0a358d4a354] usb: gadget: push all usb_composite_driver structs into __refdata git bisect good c2ec75c25112c9e0d9053f55ba8cf0a358d4a354 # good: [7d16e8d3eb704f5f6eb5a271d5758b495634e8e6] usb: gadget: push VID/PID/USB BCD module option into gadgets git bisect good 7d16e8d3eb704f5f6eb5a271d5758b495634e8e6 # good: [162ca3ca613e02e115ec9c5273f94bd22dad0af2] usb: gadget: at91_udc: move the dereference below the NULL test git bisect good 162ca3ca613e02e115ec9c5273f94bd22dad0af2 # good: [5c4d46eb89fe99011a02048533857345d9e8b506] usb: gadget serial: don't shift bcd version left by 16 git bisect good 5c4d46eb89fe99011a02048533857345d9e8b506 # good: [ca3c1539adfe9c1b86f16faf314b3bf54c3b5389] usb: add little-endian transform for DeviceRemovable of usb3.0 hub git bisect good ca3c1539adfe9c1b86f16faf314b3bf54c3b5389 # bad: [73d4066055e0e2830533041f4b91df8e6e5976ff] USB/host: Cleanup unneccessary irq disable code git bisect bad 73d4066055e0e2830533041f4b91df8e6e5976ff The first one I skipped was having these issues on boot already. The second one I skipped was just a few commits after the first one, I didn´t test the second skip. I removed USB mouse in order to avoid having any removable USB devices attached during testing. The first bad commit is: commit 73d4066055e0e2830533041f4b91df8e6e5976ff Author: Chuansheng Liu Date: Tue Sep 11 16:00:30 2012 +0800 USB/host: Cleanup unneccessary irq disable code Because the IRQF_DISABLED as the flag is now a NOOP and has been deprecated and in hardirq context the interrupt is disabled. so in usb/host code: Removing the usage of flag IRQF_DISABLED; Removing the calling local_irq save/restore actions in irq handler usb_hcd_irq(); Signed-off-by: liu chuansheng Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman But: This ony happens with threadirqs option! When I remove
[RFC/PATCH] mtd_blkdevs: Replace request handler kthread with a workqueue
By replacing a kthread with a workqueue, the code is now a bit clearer.
There's also a slight reduction of code size (numbers apply for x86):
Before:
textdata bss dec hex filename
3248 36 03284 cd4 drivers/mtd/mtd_blkdevs.o
After:
textdata bss dec hex filename
3150 36 03186 c72 drivers/mtd/mtd_blkdevs.o
Due to lack of real hardware, tests have been performed on an emulated
environment with mtdswap and mtdblock over nandsim devices.
Some real testing should be done, before merging this patch.
Cc: David Woodhouse
Cc: Artem Bityutskiy
Signed-off-by: Ezequiel Garcia
---
drivers/mtd/mtd_blkdevs.c| 47 +
include/linux/mtd/blktrans.h |4 ++-
2 files changed, 18 insertions(+), 33 deletions(-)
diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c
index f1f0671..ba375ba 100644
--- a/drivers/mtd/mtd_blkdevs.c
+++ b/drivers/mtd/mtd_blkdevs.c
@@ -32,7 +32,6 @@
#include
#include
#include
-#include
#include
#include "mtdcore.h"
@@ -121,16 +120,14 @@ static int do_blktrans_request(struct mtd_blktrans_ops
*tr,
int mtd_blktrans_cease_background(struct mtd_blktrans_dev *dev)
{
- if (kthread_should_stop())
- return 1;
-
return dev->bg_stop;
}
EXPORT_SYMBOL_GPL(mtd_blktrans_cease_background);
-static int mtd_blktrans_thread(void *arg)
+static void mtd_blktrans_work(struct work_struct *work)
{
- struct mtd_blktrans_dev *dev = arg;
+ struct mtd_blktrans_dev *dev =
+ container_of(work, struct mtd_blktrans_dev, work);
struct mtd_blktrans_ops *tr = dev->tr;
struct request_queue *rq = dev->rq;
struct request *req = NULL;
@@ -138,7 +135,7 @@ static int mtd_blktrans_thread(void *arg)
spin_lock_irq(rq->queue_lock);
- while (!kthread_should_stop()) {
+ while (1) {
int res;
dev->bg_stop = false;
@@ -156,15 +153,7 @@ static int mtd_blktrans_thread(void *arg)
background_done = !dev->bg_stop;
continue;
}
- set_current_state(TASK_INTERRUPTIBLE);
-
- if (kthread_should_stop())
- set_current_state(TASK_RUNNING);
-
- spin_unlock_irq(rq->queue_lock);
- schedule();
- spin_lock_irq(rq->queue_lock);
- continue;
+ break;
}
spin_unlock_irq(rq->queue_lock);
@@ -185,8 +174,6 @@ static int mtd_blktrans_thread(void *arg)
__blk_end_request_all(req, -EIO);
spin_unlock_irq(rq->queue_lock);
-
- return 0;
}
static void mtd_blktrans_request(struct request_queue *rq)
@@ -199,10 +186,8 @@ static void mtd_blktrans_request(struct request_queue *rq)
if (!dev)
while ((req = blk_fetch_request(rq)) != NULL)
__blk_end_request_all(req, -ENODEV);
- else {
- dev->bg_stop = true;
- wake_up_process(dev->thread);
- }
+ else
+ queue_work(dev->wq, >work);
}
static int blktrans_open(struct block_device *bdev, fmode_t mode)
@@ -437,14 +422,13 @@ int add_mtd_blktrans_dev(struct mtd_blktrans_dev *new)
gd->queue = new->rq;
- /* Create processing thread */
- /* TODO: workqueue ? */
- new->thread = kthread_run(mtd_blktrans_thread, new,
- "%s%d", tr->name, new->mtd->index);
- if (IS_ERR(new->thread)) {
- ret = PTR_ERR(new->thread);
+ /* Create processing workqueue */
+ new->wq = alloc_workqueue("%s%d", 0, 0,
+ tr->name, new->mtd->index);
+ if (!new->wq)
goto error4;
- }
+ INIT_WORK(>work, mtd_blktrans_work);
+
gd->driverfs_dev = >mtd->dev;
if (new->readonly)
@@ -484,9 +468,8 @@ int del_mtd_blktrans_dev(struct mtd_blktrans_dev *old)
/* Stop new requests to arrive */
del_gendisk(old->disk);
-
- /* Stop the thread */
- kthread_stop(old->thread);
+ /* Stop workqueue. This will perform any pending request. */
+ destroy_workqueue(old->wq);
/* Kill current requests */
spin_lock_irqsave(>queue_lock, flags);
diff --git a/include/linux/mtd/blktrans.h b/include/linux/mtd/blktrans.h
index ed270bd..4eb0a50 100644
--- a/include/linux/mtd/blktrans.h
+++ b/include/linux/mtd/blktrans.h
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
struct hd_geometry;
struct mtd_info;
@@ -43,7 +44,8 @@ struct mtd_blktrans_dev {
struct kref ref;
struct gendisk *disk;
struct attribute_group *disk_attributes;
- struct task_struct *thread;
+ struct workqueue_struct *wq;
+ struct
Re: [PATCH] fuse: remove unused variable in fuse_try_move_page()
Wei Yongjun writes: > From: Wei Yongjun > > The variables mapping,index are initialized but never used > otherwise, so remove the unused variables. > > dpatch engine is used to auto generate this patch. > (https://github.com/weiyj/dpatch) Thanks, applied. Miklos > > Signed-off-by: Wei Yongjun > --- > fs/fuse/dev.c | 5 - > 1 file changed, 5 deletions(-) > > diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c > index 8c23fa7..53c294c 100644 > --- a/fs/fuse/dev.c > +++ b/fs/fuse/dev.c > @@ -692,8 +692,6 @@ static int fuse_try_move_page(struct fuse_copy_state *cs, > struct page **pagep) > struct page *oldpage = *pagep; > struct page *newpage; > struct pipe_buffer *buf = cs->pipebufs; > - struct address_space *mapping; > - pgoff_t index; > > unlock_request(cs->fc, cs->req); > fuse_copy_finish(cs); > @@ -724,9 +722,6 @@ static int fuse_try_move_page(struct fuse_copy_state *cs, > struct page **pagep) > if (fuse_check_page(newpage) != 0) > goto out_fallback_unlock; > > - mapping = oldpage->mapping; > - index = oldpage->index; > - > /* >* This is a new and locked page, it shouldn't be mapped or >* have any special flags on it -- 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 v11 7/7] mm: add vm event counters for balloon pages compaction
On Wed, Nov 07, 2012 at 01:05:54AM -0200, Rafael Aquini wrote:
> This patch introduces a new set of vm event counters to keep track of
> ballooned pages compaction activity.
>
> Signed-off-by: Rafael Aquini
> ---
> drivers/virtio/virtio_balloon.c | 1 +
> include/linux/vm_event_item.h | 8 +++-
> mm/balloon_compaction.c | 2 ++
> mm/migrate.c| 1 +
> mm/vmstat.c | 10 +-
> 5 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index 69eede7..3756fc1 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -411,6 +411,7 @@ int virtballoon_migratepage(struct address_space *mapping,
> tell_host(vb, vb->deflate_vq);
>
> mutex_unlock(>balloon_lock);
> + balloon_event_count(COMPACTBALLOONMIGRATED);
>
> return MIGRATEPAGE_BALLOON_SUCCESS;
> }
Looks like any ballon would need to do this.
Can this chunk go into caller instead?
> diff --git a/include/linux/vm_event_item.h b/include/linux/vm_event_item.h
> index 3d31145..cbd72fc 100644
> --- a/include/linux/vm_event_item.h
> +++ b/include/linux/vm_event_item.h
> @@ -41,7 +41,13 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
> #ifdef CONFIG_COMPACTION
> COMPACTBLOCKS, COMPACTPAGES, COMPACTPAGEFAILED,
> COMPACTSTALL, COMPACTFAIL, COMPACTSUCCESS,
> -#endif
> +#ifdef CONFIG_BALLOON_COMPACTION
> + COMPACTBALLOONISOLATED, /* isolated from balloon pagelist */
> + COMPACTBALLOONMIGRATED, /* balloon page sucessfully migrated */
> + COMPACTBALLOONRELEASED, /* old-page released after migration */
> + COMPACTBALLOONRETURNED, /* putback to pagelist, not-migrated */
> +#endif /* CONFIG_BALLOON_COMPACTION */
> +#endif /* CONFIG_COMPACTION */
> #ifdef CONFIG_HUGETLB_PAGE
> HTLB_BUDDY_PGALLOC, HTLB_BUDDY_PGALLOC_FAIL,
> #endif
> diff --git a/mm/balloon_compaction.c b/mm/balloon_compaction.c
> index 90935aa..32927eb 100644
> --- a/mm/balloon_compaction.c
> +++ b/mm/balloon_compaction.c
> @@ -215,6 +215,7 @@ bool balloon_page_isolate(struct page *page)
> if (__is_movable_balloon_page(page) &&
> page_count(page) == 2) {
> __isolate_balloon_page(page);
> + balloon_event_count(COMPACTBALLOONISOLATED);
> unlock_page(page);
> return true;
> }
> @@ -237,6 +238,7 @@ void balloon_page_putback(struct page *page)
> if (__is_movable_balloon_page(page)) {
> __putback_balloon_page(page);
> put_page(page);
> + balloon_event_count(COMPACTBALLOONRETURNED);
> } else {
> __WARN();
> dump_page(page);
> diff --git a/mm/migrate.c b/mm/migrate.c
> index adb3d44..ee3037d 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -896,6 +896,7 @@ static int unmap_and_move(new_page_t get_new_page,
> unsigned long private,
> page_is_file_cache(page));
> put_page(page);
> __free_page(page);
> + balloon_event_count(COMPACTBALLOONRELEASED);
> return 0;
> }
> out:
> diff --git a/mm/vmstat.c b/mm/vmstat.c
> index c737057..1363edc 100644
> --- a/mm/vmstat.c
> +++ b/mm/vmstat.c
> @@ -781,7 +781,15 @@ const char * const vmstat_text[] = {
> "compact_stall",
> "compact_fail",
> "compact_success",
> -#endif
> +
> +#ifdef CONFIG_BALLOON_COMPACTION
> + "compact_balloon_isolated",
> + "compact_balloon_migrated",
> + "compact_balloon_released",
> + "compact_balloon_returned",
> +#endif /* CONFIG_BALLOON_COMPACTION */
> +
> +#endif /* CONFIG_COMPACTION */
>
> #ifdef CONFIG_HUGETLB_PAGE
> "htlb_buddy_alloc_success",
> --
> 1.7.11.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/
Re: [PATCH v11 5/7] virtio_balloon: introduce migration primitives to balloon pages
On Wed, Nov 07, 2012 at 01:05:52AM -0200, Rafael Aquini wrote:
> Memory fragmentation introduced by ballooning might reduce significantly
> the number of 2MB contiguous memory blocks that can be used within a guest,
> thus imposing performance penalties associated with the reduced number of
> transparent huge pages that could be used by the guest workload.
>
> Besides making balloon pages movable at allocation time and introducing
> the necessary primitives to perform balloon page migration/compaction,
> this patch also introduces the following locking scheme, in order to
> enhance the syncronization methods for accessing elements of struct
> virtio_balloon, thus providing protection against concurrent access
> introduced by parallel memory migration threads.
>
> - balloon_lock (mutex) : synchronizes the access demand to elements of
> struct virtio_balloon and its queue operations;
>
> Signed-off-by: Rafael Aquini
Acked-by: Michael S. Tsirkin
> ---
> drivers/virtio/virtio_balloon.c | 135
>
> 1 file changed, 123 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index 0908e60..69eede7 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * Balloon device works in 4K page units. So each page is pointed to by
> @@ -34,6 +35,7 @@
> * page units.
> */
> #define VIRTIO_BALLOON_PAGES_PER_PAGE (PAGE_SIZE >> VIRTIO_BALLOON_PFN_SHIFT)
> +#define VIRTIO_BALLOON_ARRAY_PFNS_MAX 256
>
> struct virtio_balloon
> {
> @@ -52,15 +54,19 @@ struct virtio_balloon
> /* Number of balloon pages we've told the Host we're not using. */
> unsigned int num_pages;
> /*
> - * The pages we've told the Host we're not using.
> + * The pages we've told the Host we're not using are enqueued
> + * at vb_dev_info->pages list.
>* Each page on this list adds VIRTIO_BALLOON_PAGES_PER_PAGE
>* to num_pages above.
>*/
> - struct list_head pages;
> + struct balloon_dev_info *vb_dev_info;
> +
> + /* Synchronize access/update to this struct virtio_balloon elements */
> + struct mutex balloon_lock;
>
> /* The array of pfns we tell the Host about. */
> unsigned int num_pfns;
> - u32 pfns[256];
> + u32 pfns[VIRTIO_BALLOON_ARRAY_PFNS_MAX];
>
> /* Memory statistics */
> int need_stats_update;
> @@ -122,18 +128,25 @@ static void set_page_pfns(u32 pfns[], struct page *page)
>
> static void fill_balloon(struct virtio_balloon *vb, size_t num)
> {
> + struct balloon_dev_info *vb_dev_info = vb->vb_dev_info;
> +
> + static DEFINE_RATELIMIT_STATE(fill_balloon_rs,
> + DEFAULT_RATELIMIT_INTERVAL,
> + DEFAULT_RATELIMIT_BURST);
> +
> /* We can only do one array worth at a time. */
> num = min(num, ARRAY_SIZE(vb->pfns));
>
> + mutex_lock(>balloon_lock);
> for (vb->num_pfns = 0; vb->num_pfns < num;
>vb->num_pfns += VIRTIO_BALLOON_PAGES_PER_PAGE) {
> - struct page *page = alloc_page(GFP_HIGHUSER | __GFP_NORETRY |
> - __GFP_NOMEMALLOC | __GFP_NOWARN);
> + struct page *page = balloon_page_enqueue(vb_dev_info);
> +
> if (!page) {
> - if (printk_ratelimit())
> + if (__ratelimit(_balloon_rs))
> dev_printk(KERN_INFO, >vdev->dev,
> "Out of puff! Can't get %zu pages\n",
> -num);
> +VIRTIO_BALLOON_PAGES_PER_PAGE);
> /* Sleep for at least 1/5 of a second before retry. */
> msleep(200);
> break;
> @@ -141,7 +154,6 @@ static void fill_balloon(struct virtio_balloon *vb,
> size_t num)
> set_page_pfns(vb->pfns + vb->num_pfns, page);
> vb->num_pages += VIRTIO_BALLOON_PAGES_PER_PAGE;
> totalram_pages--;
> - list_add(>lru, >pages);
> }
>
> /* Didn't get any? Oh well. */
> @@ -149,6 +161,7 @@ static void fill_balloon(struct virtio_balloon *vb,
> size_t num)
> return;
>
> tell_host(vb, vb->inflate_vq);
> + mutex_unlock(>balloon_lock);
> }
>
> static void release_pages_by_pfn(const u32 pfns[], unsigned int num)
> @@ -165,14 +178,17 @@ static void release_pages_by_pfn(const u32 pfns[],
> unsigned int num)
> static void leak_balloon(struct virtio_balloon *vb, size_t num)
> {
> struct page *page;
> + struct balloon_dev_info *vb_dev_info = vb->vb_dev_info;
>
> /* We can only do one array worth at a time. */
> num = min(num, ARRAY_SIZE(vb->pfns));
>
> +
Re: [PATCH v11 5/7] virtio_balloon: introduce migration primitives to balloon pages
On Wed, Nov 07, 2012 at 04:11:46PM -0800, Andrew Morton wrote: > On Thu, 08 Nov 2012 09:32:18 +1030 > Rusty Russell wrote: > > > Rafael Aquini writes: > > > + * virtballoon_migratepage - perform the balloon page migration on > > > behalf of > > > + *a compation thread. (called under page > > > lock) > > > > > + if (!mutex_trylock(>balloon_lock)) > > > + return -EAGAIN; > > > > Erk, OK... > > Not really. As is almost always the case with a trylock, it needs a > comment explaining why we couldn't use the far superior mutex_lock(). > Data: this reader doesn't know! > > > > + /* balloon's page migration 1st step -- inflate "newpage" */ > > > + spin_lock_irqsave(_dev_info->pages_lock, flags); > > > + balloon_page_insert(newpage, mapping, _dev_info->pages); > > > + vb_dev_info->isolated_pages--; > > > + spin_unlock_irqrestore(_dev_info->pages_lock, flags); > > > + vb->num_pfns = VIRTIO_BALLOON_PAGES_PER_PAGE; > > > + set_page_pfns(vb->pfns, newpage); > > > + tell_host(vb, vb->inflate_vq); > > > > tell_host does wait_event(), so you can't call it under the page_lock. > > Right? > > Sleeping inside lock_page() is OK. More problematic is that GFP_KERNEL > allocation. Do you mean this one: if (virtqueue_add_buf(vq, , 1, 0, vb, GFP_KERNEL) < 0) ? In practice it never triggers an allocation, we can pass in GFP_ATOMIC just as well. -- MST -- 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] bq27x00_battery: Do not report nominal available capaciy if battery is not calibrated
Signed-off-by: Pali Rohár
---
drivers/power/bq27x00_battery.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/power/bq27x00_battery.c b/drivers/power/bq27x00_battery.c
index 5860d4d..41b3328 100644
--- a/drivers/power/bq27x00_battery.c
+++ b/drivers/power/bq27x00_battery.c
@@ -230,6 +230,14 @@ static int bq27x00_battery_read_charge(struct
bq27x00_device_info *di, u8 reg)
*/
static inline int bq27x00_battery_read_nac(struct bq27x00_device_info *di)
{
+ int flags;
+ bool is_bq27500 = di->chip == BQ27500;
+ bool is_higher = bq27xxx_is_chip_version_higher(di);
+
+ flags = bq27x00_read(di, BQ27x00_REG_FLAGS, !is_bq27500);
+ if (flags >= 0 && !is_higher && (flags & BQ27000_FLAG_CI))
+ return -ENODATA;
+
return bq27x00_battery_read_charge(di, BQ27x00_REG_NAC);
}
--
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: kmemleak report on isp1763 and sierra MC8705
On Fri, Nov 9, 2012 at 11:14 PM, Richard Retanubun
wrote:
> On 29/10/12 06:14 PM, Alan Stern wrote:
>>
>> On Mon, 29 Oct 2012, Richard Retanubun wrote:
>>>
>>> Focusing down on one of the dumps:
>>>
>>> unreferenced object 0xd3849740 (size 8):
>>> comm "khubd", pid 1026, jiffies 232553037 (age 506.597s)
>>> hex dump (first 8 bytes):
>>> 4d 43 38 37 30 35 00 00 MC8705..
>>> backtrace:
>>> [] usb_cache_string+0x74/0xac [usbcore]
>>> [] usb_enumerate_device+0x44/0xf8 [usbcore]
>>> [] usb_new_device+0x3c/0x13c [usbcore]
>>> [] hub_thread+0xc8c/0x1544 [usbcore]
>>> [] kthread+0x7c/0x80
>>> [] kernel_thread+0x4c/0x68
>>>
>>> I have a small question. How does the memory kmalloc-ed() in
>>> usb_cache_string is supposed to be released?
>>> (during usb_serial_disconnect()?)
>>
>>
>> It doesn't get released during usb_serial_disconnect(). It gets
>> released during usb_release_dev() in drivers/usb/core/usb.c.
>>
>>> Is the sierra driver is supposed to participate
>>> in the tear down process (in sierra_release() maybe) and not doing
>>> something that is expected?
>>
>>
>> Probably not.
>>
>>> I am still missing the link between the actions done by the hub_thread()
>>> for the caching the stings
>>> and the sierra driver code.
>>
>>
>> They aren't all that closely related.
>>
>> usb_release_dev() won't be called until all references to the USB
>> device have been dropped. Maybe there's an extra reference hanging
>> around.
>>
>> Alan Stern
>>
> Thanks a lot for the hint Alan.
>
> I added a dev_dbg print in usb_release_dev() and saw that in the builds
> where there is a leak, this was simply never called!
> the last line printed in a trace with all dev_dbg on is this
> "usb_disable_device nuking all URBs"
> When the sierra modem is unplugged, the cleanup sequence never calls
> usb_release_dev() (on PL2303 it always calls usb_release_dev()
>
> This is the current state of versions from linux-stable
>
> 3.0.y (3.0.51) - Have the issue
> 3.2.y (3.2.33) - Have the issue
> 3.4.y (3.4.18) - Have the issue
> 3.5.y (3.5.7) - Does not have the issue (but leaks because the portdata
> patches is not backported yet)
> 3.6.y (3.6.6) - Does not have the issue
>
> So a diff between 3.4.y and 3.5.y ought to narrow it down further.
>
> I am posting just in case someone recalls a particular patch I should be
> trying out first...
There was a reference-count fix for the probe error path that went in to
v3.5. Haven't read all the details on how you trigger your leak, but at
the face of it, it could be related.
Have a look at 0658a3366db7e27fa ("usb: use usb_serial_put in
usb_serial_probe errors). If related, you should be seeing "Ignoring
blacklisted interface #n" messages when you enable debug (e.g. #define
DEBUG) in the sierra driver.
Greg, it seems to me that the fix referred to above should be backported
to the earlier stable trees either way.
Thanks,
Johan
--
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] wanrouter: Remove it and the drivers that depend on it
Remove wanrouter as it's obsolete and has not been updated by sangoma since 2.4.3 or so and it's not used anymore. Remove obsolete cyclomx drivers. Update defconfig files that enable wanrouter. Update files that include now deleted wanrouter bits. Signed-off-by: Joe Perches --- Documentation/ioctl/ioctl-number.txt |1 - Documentation/magic-number.txt |1 - Documentation/zh_CN/magic-number.txt |1 - arch/arm/configs/ixp4xx_defconfig |2 - arch/mips/configs/gpr_defconfig|3 - arch/mips/configs/mtx1_defconfig |3 - arch/mips/configs/nlm_xlp_defconfig|1 - arch/mips/configs/nlm_xlr_defconfig|1 - arch/powerpc/configs/86xx/gef_sbc610_defconfig |1 - arch/powerpc/configs/86xx/sbc8641d_defconfig |1 - arch/powerpc/configs/ppc6xx_defconfig |1 - arch/um/defconfig |1 - arch/xtensa/configs/common_defconfig |1 - arch/xtensa/configs/iss_defconfig |1 - arch/xtensa/configs/s6105_defconfig|1 - drivers/isdn/i4l/isdn_x25iface.c |1 - drivers/isdn/i4l/isdn_x25iface.h |1 - drivers/net/wan/Kconfig| 54 - drivers/net/wan/Makefile |5 - drivers/net/wan/cycx_drv.c | 569 - drivers/net/wan/cycx_main.c| 346 - drivers/net/wan/cycx_x25.c | 1602 include/linux/cyclomx.h| 77 -- include/linux/cycx_drv.h | 64 - include/linux/wanrouter.h | 129 -- include/uapi/linux/Kbuild |1 - include/uapi/linux/wanrouter.h | 452 --- net/Kconfig|1 - net/Makefile |1 - net/socket.c |1 - net/wanrouter/Kconfig | 27 - net/wanrouter/Makefile |7 - net/wanrouter/patchlevel |1 - net/wanrouter/wanmain.c| 782 net/wanrouter/wanproc.c| 380 -- 35 files changed, 0 insertions(+), 4521 deletions(-) delete mode 100644 drivers/net/wan/cycx_drv.c delete mode 100644 drivers/net/wan/cycx_main.c delete mode 100644 drivers/net/wan/cycx_x25.c delete mode 100644 include/linux/cyclomx.h delete mode 100644 include/linux/cycx_drv.h delete mode 100644 include/linux/wanrouter.h delete mode 100644 include/uapi/linux/wanrouter.h delete mode 100644 net/wanrouter/Kconfig delete mode 100644 net/wanrouter/Makefile delete mode 100644 net/wanrouter/patchlevel delete mode 100644 net/wanrouter/wanmain.c delete mode 100644 net/wanrouter/wanproc.c diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index 2152b0e..028a034 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -179,7 +179,6 @@ Code Seq#(hex) Include FileComments 'V'C0 media/davinci/vpfe_capture.hconflict! 'V'C0 media/si4713.h conflict! 'W'00-1F linux/watchdog.hconflict! -'W'00-1F linux/wanrouter.h conflict! 'W'00-3F sound/asound.h conflict! 'X'all fs/xfs/xfs_fs.h conflict! and fs/xfs/linux-2.6/xfs_ioctl32.h diff --git a/Documentation/magic-number.txt b/Documentation/magic-number.txt index 82761a3..0c39e72 100644 --- a/Documentation/magic-number.txt +++ b/Documentation/magic-number.txt @@ -122,7 +122,6 @@ SLAB_C_MAGIC 0x4f17a36d kmem_cache mm/slab.c COW_MAGIC 0x4f4f4f4d cow_header_v1 arch/um/drivers/ubd_user.c I810_CARD_MAGIC 0x5072696E i810_card sound/oss/i810_audio.c TRIDENT_CARD_MAGIC0x5072696E trident_card sound/oss/trident.c -ROUTER_MAGIC 0x524d4157 wan_deviceinclude/linux/wanrouter.h SCC_MAGIC 0x52696368 gs_port drivers/char/scc.h SAVEKMSG_MAGIC1 0x53415645 savekmsg arch/*/amiga/config.c GDA_MAGIC 0x58464552 gda arch/mips/include/asm/sn/gda.h diff --git a/Documentation/zh_CN/magic-number.txt b/Documentation/zh_CN/magic-number.txt index 4263022..51b7e15 100644 --- a/Documentation/zh_CN/magic-number.txt +++ b/Documentation/zh_CN/magic-number.txt @@ -122,7 +122,6 @@ SLAB_C_MAGIC 0x4f17a36d kmem_cache mm/slab.c COW_MAGIC 0x4f4f4f4d cow_header_v1 arch/um/drivers/ubd_user.c I810_CARD_MAGIC 0x5072696E i810_card sound/oss/i810_audio.c TRIDENT_CARD_MAGIC0x5072696E trident_card sound/oss/trident.c -ROUTER_MAGIC 0x524d4157 wan_deviceinclude/linux/wanrouter.h SCC_MAGIC
[RFC PATCH 6/6] VFIO: use ACCESS_ONCE() to guard access to dev->driver
From: Jiang Liu
Comments from dev_driver_string(),
/* dev->driver can change to NULL underneath us because of unbinding,
* so be careful about accessing it.
*/
So use ACCESS_ONCE() to guard access to dev->driver field.
Signed-off-by: Jiang Liu
---
drivers/vfio/vfio.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 18714b9..f158e42 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -520,8 +520,9 @@ static bool vfio_whitelisted_driver(struct device_driver
*drv)
static int vfio_dev_viable(struct device *dev, void *data)
{
struct vfio_device_driver *driver;
+ struct device_driver *drv = ACCESS_ONCE(dev->driver);
- if (!dev->driver || vfio_whitelisted_driver(dev->driver))
+ if (!drv || vfio_whitelisted_driver(drv))
return 0;
mutex_lock(_drivers_lock);
--
1.7.9.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/
[RFC PATCH 4/6] VFIO: reject binding driver to devices belonging to active VFIO groups
From: Jiang Liu
VFIO driver should reject binding unsafe drivers to devices belonging to
active VFIO groups, otherwise it will break the DMA isolation property
of VFIO groups. So hook IOMMU_GROUP_NOTIFY_QUERY_BINDING event to reject
unsafe device driver binding for active VFIO groups.
Signed-off-by: Jiang Liu
---
drivers/vfio/pci/vfio_pci.c | 11 -
drivers/vfio/vfio.c | 106 ---
include/linux/vfio.h|3 ++
3 files changed, 102 insertions(+), 18 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 6968b72..e380fc1 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -538,6 +538,7 @@ static struct pci_driver vfio_pci_driver = {
static void __exit vfio_pci_cleanup(void)
{
pci_unregister_driver(_pci_driver);
+ vfio_unregister_device_driver(_pci_driver.driver);
vfio_pci_virqfd_exit();
vfio_pci_uninit_perm_bits();
}
@@ -556,6 +557,10 @@ static int __init vfio_pci_init(void)
if (ret)
goto out_virqfd;
+ ret = vfio_register_device_driver(_pci_driver.driver);
+ if (ret)
+ goto out_vfio_drv;
+
/* Register and scan for devices */
ret = pci_register_driver(_pci_driver);
if (ret)
@@ -563,9 +568,11 @@ static int __init vfio_pci_init(void)
return 0;
-out_virqfd:
- vfio_pci_virqfd_exit();
out_driver:
+ vfio_unregister_device_driver(_pci_driver.driver);
+out_vfio_drv:
+ vfio_pci_virqfd_exit();
+out_virqfd:
vfio_pci_uninit_perm_bits();
return ret;
}
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 3359ec2..02da980 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -39,6 +39,8 @@ static struct vfio {
struct class*class;
struct list_headiommu_drivers_list;
struct mutexiommu_drivers_lock;
+ struct list_headdevice_drivers_list;
+ struct mutexdevice_drivers_lock;
struct list_headgroup_list;
struct idr group_idr;
struct mutexgroup_lock;
@@ -54,6 +56,11 @@ struct vfio_iommu_driver {
struct list_headvfio_next;
};
+struct vfio_device_driver {
+ const struct device_driver *drv;
+ struct list_headvfio_next;
+};
+
struct vfio_container {
struct kref kref;
struct list_headgroup_list;
@@ -135,6 +142,55 @@ void vfio_unregister_iommu_driver(const struct
vfio_iommu_driver_ops *ops)
EXPORT_SYMBOL_GPL(vfio_unregister_iommu_driver);
/**
+ * VFIO device driver registration
+ */
+int vfio_register_device_driver(const struct device_driver *drv)
+{
+ struct vfio_device_driver *driver, *tmp;
+
+ driver = kzalloc(sizeof(*driver), GFP_KERNEL);
+ if (!driver)
+ return -ENOMEM;
+
+ driver->drv = drv;
+
+ mutex_lock(_drivers_lock);
+
+ /* Check for duplicates */
+ list_for_each_entry(tmp, _drivers_list, vfio_next) {
+ if (tmp->drv == drv) {
+ mutex_unlock(_drivers_lock);
+ kfree(driver);
+ return -EINVAL;
+ }
+ }
+
+ list_add(>vfio_next, _drivers_list);
+
+ mutex_unlock(_drivers_lock);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(vfio_register_device_driver);
+
+void vfio_unregister_device_driver(const struct device_driver *drv)
+{
+ struct vfio_device_driver *driver;
+
+ mutex_lock(_drivers_lock);
+ list_for_each_entry(driver, _drivers_list, vfio_next) {
+ if (driver->drv == drv) {
+ list_del(>vfio_next);
+ mutex_unlock(_drivers_lock);
+ kfree(driver);
+ return;
+ }
+ }
+ mutex_unlock(_drivers_lock);
+}
+EXPORT_SYMBOL_GPL(vfio_unregister_device_driver);
+
+/**
* Group minor allocation/free - both called with vfio.group_lock held
*/
static int vfio_alloc_group_minor(struct vfio_group *group)
@@ -463,17 +519,18 @@ static bool vfio_whitelisted_driver(struct device_driver
*drv)
*/
static int vfio_dev_viable(struct device *dev, void *data)
{
- struct vfio_group *group = data;
- struct vfio_device *device;
+ struct vfio_device_driver *driver;
if (!dev->driver || vfio_whitelisted_driver(dev->driver))
return 0;
- device = vfio_group_get_device(group, dev);
- if (device) {
- vfio_device_put(device);
- return 0;
- }
+ mutex_lock(_drivers_lock);
+ list_for_each_entry(driver, _drivers_list, vfio_next)
+ if (driver->drv == dev->driver) {
+
[RFC PATCH 5/6] VFIO: simplify IOMMU group notification handler
From: Jiang Liu
Now we have a way to reject binding unsafe drivers to devices belonging
to active VFIO groups, so we could simplify IOMMU group notification
handler to only handle IOMMU_GROUP_NOTIFY_SOLICIT_BINDING event.
Signed-off-by: Jiang Liu
---
drivers/vfio/vfio.c | 90 ---
1 file changed, 6 insertions(+), 84 deletions(-)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 02da980..18714b9 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -538,57 +538,6 @@ static int vfio_dev_viable(struct device *dev, void *data)
/**
* Async device support
*/
-static int vfio_group_nb_add_dev(struct vfio_group *group, struct device *dev)
-{
- struct vfio_device *device;
-
- /* Do we already know about it? We shouldn't */
- device = vfio_group_get_device(group, dev);
- if (WARN_ON_ONCE(device)) {
- vfio_device_put(device);
- return 0;
- }
-
- /* Nothing to do for idle groups */
- if (!atomic_read(>container_users))
- return 0;
-
- WARN("Device %s added to live group %d!\n", dev_name(dev),
-iommu_group_id(group->iommu_group));
-
- return 0;
-}
-
-static int vfio_group_nb_del_dev(struct vfio_group *group, struct device *dev)
-{
- struct vfio_device *device;
-
- /*
-* Expect to fall out here. If a device was in use, it would
-* have been bound to a vfio sub-driver, which would have blocked
-* in .remove at vfio_del_group_dev. Sanity check that we no
-* longer track the device, so it's safe to remove.
-*/
- device = vfio_group_get_device(group, dev);
- if (likely(!device))
- return 0;
-
- WARN("Device %s removed from live group %d!\n", dev_name(dev),
-iommu_group_id(group->iommu_group));
-
- vfio_device_put(device);
- return 0;
-}
-
-static int vfio_group_nb_verify(struct vfio_group *group, struct device *dev)
-{
- /* We don't care what happens when the group isn't in use */
- if (!atomic_read(>container_users))
- return 0;
-
- return vfio_dev_viable(dev, group);
-}
-
static int vfio_group_nb_solicit_binding(struct vfio_group *group,
struct device *dev)
{
@@ -614,6 +563,9 @@ static int vfio_iommu_group_notifier(struct notifier_block
*nb,
struct vfio_group *group = container_of(nb, struct vfio_group, nb);
struct device *dev = data;
+ if (action != IOMMU_GROUP_NOTIFY_SOLICIT_BINDING)
+ return NOTIFY_DONE;
+
/*
* Need to go through a group_lock lookup to get a reference or
* we risk racing a group being removed. Leave a WARN_ON for
@@ -624,41 +576,11 @@ static int vfio_iommu_group_notifier(struct
notifier_block *nb,
if (WARN_ON(!group))
return NOTIFY_OK;
- switch (action) {
- case IOMMU_GROUP_NOTIFY_ADD_DEVICE:
- vfio_group_nb_add_dev(group, dev);
- break;
- case IOMMU_GROUP_NOTIFY_DEL_DEVICE:
- vfio_group_nb_del_dev(group, dev);
- break;
- case IOMMU_GROUP_NOTIFY_SOLICIT_BINDING:
- if (vfio_group_nb_solicit_binding(group, dev))
- ret = notifier_from_errno(-EBUSY);
- break;
- case IOMMU_GROUP_NOTIFY_BIND_DRIVER:
- pr_debug("%s: Device %s, group %d binding to driver\n",
-__func__, dev_name(dev),
-iommu_group_id(group->iommu_group));
- break;
- case IOMMU_GROUP_NOTIFY_BOUND_DRIVER:
- pr_debug("%s: Device %s, group %d bound to driver %s\n",
-__func__, dev_name(dev),
-iommu_group_id(group->iommu_group), dev->driver->name);
- BUG_ON(vfio_group_nb_verify(group, dev));
- break;
- case IOMMU_GROUP_NOTIFY_UNBIND_DRIVER:
- pr_debug("%s: Device %s, group %d unbinding from driver %s\n",
-__func__, dev_name(dev),
-iommu_group_id(group->iommu_group), dev->driver->name);
- break;
- case IOMMU_GROUP_NOTIFY_UNBOUND_DRIVER:
- pr_debug("%s: Device %s, group %d unbound from driver\n",
-__func__, dev_name(dev),
-iommu_group_id(group->iommu_group));
- break;
- }
+ if (vfio_group_nb_solicit_binding(group, dev))
+ ret = notifier_from_errno(-EBUSY);
vfio_group_put(group);
+
return ret;
}
--
1.7.9.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/
[RFC PATCH 3/6] VFIO: unregister IOMMU notifier on error recovery path
From: Jiang Liu
On error recovery path in function vfio_create_group(), it should
unregister the IOMMU notifier for the new VFIO group. Otherwise it may
cause invalid memory access later when handling bus notifications.
Signed-off-by: Jiang Liu
---
drivers/vfio/vfio.c | 31 +++
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 17830c9..3359ec2 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -191,6 +191,17 @@ static void vfio_container_put(struct vfio_container
*container)
kref_put(>kref, vfio_container_release);
}
+static void vfio_group_unlock_and_free(struct vfio_group *group)
+{
+ mutex_unlock(_lock);
+ /*
+* Unregister outside of lock. A spurious callback is harmless now
+* that the group is no longer in vfio.group_list.
+*/
+ iommu_group_unregister_notifier(group->iommu_group, >nb);
+ kfree(group);
+}
+
/**
* Group objects - create, release, get, put, search
*/
@@ -229,8 +240,7 @@ static struct vfio_group *vfio_create_group(struct
iommu_group *iommu_group)
minor = vfio_alloc_group_minor(group);
if (minor < 0) {
- mutex_unlock(_lock);
- kfree(group);
+ vfio_group_unlock_and_free(group);
return ERR_PTR(minor);
}
@@ -239,8 +249,7 @@ static struct vfio_group *vfio_create_group(struct
iommu_group *iommu_group)
if (tmp->iommu_group == iommu_group) {
vfio_group_get(tmp);
vfio_free_group_minor(minor);
- mutex_unlock(_lock);
- kfree(group);
+ vfio_group_unlock_and_free(group);
return tmp;
}
}
@@ -249,8 +258,7 @@ static struct vfio_group *vfio_create_group(struct
iommu_group *iommu_group)
group, "%d", iommu_group_id(iommu_group));
if (IS_ERR(dev)) {
vfio_free_group_minor(minor);
- mutex_unlock(_lock);
- kfree(group);
+ vfio_group_unlock_and_free(group);
return (struct vfio_group *)dev; /* ERR_PTR */
}
@@ -274,16 +282,7 @@ static void vfio_group_release(struct kref *kref)
device_destroy(vfio.class, MKDEV(MAJOR(vfio.devt), group->minor));
list_del(>vfio_next);
vfio_free_group_minor(group->minor);
-
- mutex_unlock(_lock);
-
- /*
-* Unregister outside of lock. A spurious callback is harmless now
-* that the group is no longer in vfio.group_list.
-*/
- iommu_group_unregister_notifier(group->iommu_group, >nb);
-
- kfree(group);
+ vfio_group_unlock_and_free(group);
}
static void vfio_group_put(struct vfio_group *group)
--
1.7.9.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/
[RFC PATCH 2/6] iommu: pass on BUS_NOTIFY_QUERY_BINDING to iommu group notifier clients
From: Jiang Liu
Pass on BUS_NOTIFY_QUERY_BINDING event to iommu group notifier clients,
so notifier clients have a chance to reject device driver binding.
Signed-off-by: Jiang Liu
---
drivers/iommu/iommu.c | 14 +-
include/linux/iommu.h |1 +
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index ddbdaca..7fbe055 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -497,6 +497,7 @@ static int add_iommu_group(struct device *dev, void *data)
static int iommu_bus_notifier(struct notifier_block *nb,
unsigned long action, void *data)
{
+ int ret = NOTIFY_DONE;
struct device *dev = data;
struct iommu_ops *ops = dev->bus->iommu_ops;
struct iommu_group *group;
@@ -512,7 +513,7 @@ static int iommu_bus_notifier(struct notifier_block *nb,
} else if (action == BUS_NOTIFY_DEL_DEVICE) {
if (ops->remove_device && dev->iommu_group) {
ops->remove_device(dev);
- return 0;
+ return NOTIFY_DONE;
}
}
@@ -522,9 +523,12 @@ static int iommu_bus_notifier(struct notifier_block *nb,
*/
group = iommu_group_get(dev);
if (!group)
- return 0;
+ return NOTIFY_DONE;
switch (action) {
+ case BUS_NOTIFY_SOLICIT_BINDING:
+ group_action = IOMMU_GROUP_NOTIFY_SOLICIT_BINDING;
+ break;
case BUS_NOTIFY_BIND_DRIVER:
group_action = IOMMU_GROUP_NOTIFY_BIND_DRIVER;
break;
@@ -540,11 +544,11 @@ static int iommu_bus_notifier(struct notifier_block *nb,
}
if (group_action)
- blocking_notifier_call_chain(>notifier,
-group_action, dev);
+ ret = blocking_notifier_call_chain(>notifier,
+ group_action, dev);
iommu_group_put(group);
- return 0;
+ return ret;
}
static struct notifier_block iommu_bus_nb = {
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 7e83370..366435b 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -109,6 +109,7 @@ struct iommu_ops {
#define IOMMU_GROUP_NOTIFY_BOUND_DRIVER4 /* Post Driver bind */
#define IOMMU_GROUP_NOTIFY_UNBIND_DRIVER 5 /* Pre Driver unbind */
#define IOMMU_GROUP_NOTIFY_UNBOUND_DRIVER 6 /* Post Driver unbind */
+#define IOMMU_GROUP_NOTIFY_SOLICIT_BINDING 7 /* Check for objections */
extern int bus_set_iommu(struct bus_type *bus, struct iommu_ops *ops);
extern bool iommu_present(struct bus_type *bus);
--
1.7.9.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/
[RFC PATCH 1/6] driver core: add a bus notification to temporarily reject driver binding
From: Jiang Liu
There are several requirements to temporarily reject device driver
binding. Possible usage cases as below:
1) We should avoid binding an unsafe driver to a device belonging to
an active VFIO group, otherwise it will break the DMA isolation
property of VFIO.
2) When hot-removing a PCI hierachy, we should avoid binding device
drivers to PCI devices going to be removed during the window
between unbinding of device driver and destroying of device nodes.
3) When hot-adding a PCI host bridge, we should temporarily disable
driver binding before setting up corresponding IOMMU and IOAPIC.
We may add a flag into struct device to temporarily disable driver
binding as in this thread https://patchwork.kernel.org/patch/1535721/.
This patch proposes another solution to temporarily disable driver
binding by using bus notification mechanisms. It adds an notification
event to solicit if anybody has objections when binding a driver to a
device.
Signed-off-by: Jiang Liu
---
drivers/base/dd.c | 11 ++-
include/linux/device.h |8 +++-
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index e3bbed8..43c8034 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -205,9 +205,18 @@ static int driver_sysfs_add(struct device *dev)
{
int ret;
- if (dev->bus)
+ if (dev->bus) {
+ /* Does anybody have objections to the driver binding? */
+ ret = blocking_notifier_call_chain(>bus->p->bus_notifier,
+ BUS_NOTIFY_SOLICIT_BINDING, dev);
+ if ((ret & NOTIFY_STOP_MASK) == NOTIFY_STOP_MASK) {
+ dev_dbg(dev, "driver binding has been rejected by bus
notification handler.\n");
+ return notifier_to_errno(ret);
+ }
+
blocking_notifier_call_chain(>bus->p->bus_notifier,
BUS_NOTIFY_BIND_DRIVER, dev);
+ }
ret = sysfs_create_link(>driver->p->kobj, >kobj,
kobject_name(>kobj));
diff --git a/include/linux/device.h b/include/linux/device.h
index 52a5f15..2cfe8f9 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -165,9 +165,13 @@ extern int bus_register_notifier(struct bus_type *bus,
extern int bus_unregister_notifier(struct bus_type *bus,
struct notifier_block *nb);
-/* All 4 notifers below get called with the target struct device *
+/* All 7 notifers below get called with the target struct device *
* as an argument. Note that those functions are likely to be called
* with the device lock held in the core, so be careful.
+ *
+ * Note: return values of notification handler are ignored by the driver core
+ * except for BUS_SOLICIT_BINDING, so notication handler shouldn't return
+ * error code except for BUS_SOLICIT_BINDING.
*/
#define BUS_NOTIFY_ADD_DEVICE 0x0001 /* device added */
#define BUS_NOTIFY_DEL_DEVICE 0x0002 /* device removed */
@@ -178,6 +182,8 @@ extern int bus_unregister_notifier(struct bus_type *bus,
unbound */
#define BUS_NOTIFY_UNBOUND_DRIVER 0x0006 /* driver is unbound
from the device */
+#define BUS_NOTIFY_SOLICIT_BINDING 0x0007 /* Any objections to the
+ driver binding? */
extern struct kset *bus_get_kset(struct bus_type *bus);
extern struct klist *bus_get_device_klist(struct bus_type *bus);
--
1.7.9.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] pinctrl: pinmux: Release all taken pins in pinmux_enable_setting error paths
Currently pinmux_enable_setting does not release all taken pins if
ops->enable() returns error. This patch ensures all taken pins are
released in any error paths.
Signed-off-by: Axel Lin
---
drivers/pinctrl/pinmux.c | 28 +---
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index 0ef01ee..1a00658 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -409,11 +409,7 @@ int pinmux_enable_setting(struct pinctrl_setting const
*setting)
dev_err(pctldev->dev,
"could not request pin %d on device %s\n",
pins[i], pinctrl_dev_get_name(pctldev));
- /* On error release all taken pins */
- i--; /* this pin just failed */
- for (; i >= 0; i--)
- pin_free(pctldev, pins[i], NULL);
- return -ENODEV;
+ goto err_pin_request;
}
}
@@ -429,8 +425,26 @@ int pinmux_enable_setting(struct pinctrl_setting const
*setting)
desc->mux_setting = &(setting->data.mux);
}
- return ops->enable(pctldev, setting->data.mux.func,
- setting->data.mux.group);
+ ret = ops->enable(pctldev, setting->data.mux.func,
+ setting->data.mux.group);
+
+ if (ret)
+ goto err_enable;
+
+ return 0;
+
+err_enable:
+ for (i = 0; i < num_pins; i++) {
+ desc = pin_desc_get(pctldev, pins[i]);
+ if (desc)
+ desc->mux_setting = NULL;
+ }
+err_pin_request:
+ /* On error release all taken pins */
+ while (--i >= 0)
+ pin_free(pctldev, pins[i], NULL);
+
+ return ret;
}
void pinmux_disable_setting(struct pinctrl_setting const *setting)
--
1.7.9.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 update 3/3] fs: Fix crash caused by write to dummy debugfs interface like HW_latency exposed
[ 141.311906] BUG: unable to handle kernel NULL pointer dereference at 0008 [ 141.314071] IP: [] simple_attr_write+0x2c/0x100 [ 141.316195] PGD c3bd7067 PUD cb41d067 PMD 0 [ 141.318287] Oops: [#1] SMP [ 141.320338] Modules linked in: hw_latency_test lockd sunrpc iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack rfcomm bnep coretemp kvm arc4 iwldvm mac80211 snd_hda_codec_hdmi snd_hda_codec_realtek option usb_wwan snd_hda_intel snd_hda_codec btusb bluetooth snd_hwdep snd_seq snd_seq_device snd_pcm iwlwifi thinkpad_acpi cfg80211 snd_page_alloc snd_timer crc32c_intel snd e1000e tpm_tis ghash_clmulni_intel tpm tpm_bios soundcore iTCO_wdt rfkill joydev microcode i2c_i801 wmi iTCO_vendor_support mei lpc_ich mfd_core pcspkr uinput i915 usb_storage i2c_algo_bit uas drm_kms_helper sdhci_pci sdhci drm mmc_core i2c_core video [ 141.329446] CPU 2 [ 141.329467] Pid: 804, comm: bash Not tainted 3.7.0-rc2+ #5 LENOVO 232045C/232045C [ 141.333922] RIP: 0010:[] [] simple_attr_write+0x2c/0x100 [ 141.336173] RSP: 0018:8800cb6c3eb8 EFLAGS: 00010286 [ 141.338377] RAX: 811f8f10 RBX: 8800c4549600 RCX: 8800cb6c3f50 [ 141.340573] RDX: 0002 RSI: 7fcbf9ef RDI: 8800c4549600 [ 141.342744] RBP: 8800cb6c3ef8 R08: 000a R09: 7fcbf9edd740 [ 141.344896] R10: 0001 R11: 0246 R12: 0002 [ 141.347017] R13: 7fcbf9ef R14: 8800cb6c3f50 R15: [ 141.349115] FS: 7fcbf9edd740() GS:88011920() knlGS: [ 141.351209] CS: 0010 DS: ES: CR0: 80050033 [ 141.353314] CR2: 0008 CR3: c696c000 CR4: 001407e0 [ 141.355457] DR0: DR1: DR2: [ 141.357590] DR3: DR6: 0ff0 DR7: 0400 [ 141.359685] Process bash (pid: 804, threadinfo 8800cb6c2000, task 8800cb7ccd20) [ 141.361767] Stack: [ 141.363793] 8800c4549600 7fcbf9ef 8800cb6c3ef8 8800c4549600 [ 141.365864] 0002 7fcbf9ef 8800cb6c3f50 [ 141.367905] 8800cb6c3f28 811cf27f 8800c4549600 7fcbf9ef [ 141.369924] Call Trace: [ 141.371882] [] vfs_write+0xaf/0x190 [ 141.373827] [] sys_write+0x55/0xa0 [ 141.375745] [] system_call_fastpath+0x16/0x1b [ 141.377661] Code: 1f 44 00 00 55 48 89 e5 48 83 ec 40 48 89 5d d8 4c 89 65 e0 4c 89 6d e8 4c 89 75 f0 4c 89 7d f8 4c 8b bf 28 01 00 00 48 89 75 c8 <49> 83 7f 08 00 0f 84 b1 00 00 00 4d 8d 67 50 31 f6 49 89 d5 4c [ 141.382206] RIP [] simple_attr_write+0x2c/0x100 [ 141.384326] RSP [ 141.386401] CR2: 0008 [ 141.388548] ---[ end trace 9c28eee46fcb7871 ]--- Signed-off-by: Luming Yu --- fs/libfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/libfs.c b/fs/libfs.c index 7cc37ca..bc51574 100644 --- a/fs/libfs.c +++ b/fs/libfs.c @@ -819,7 +819,7 @@ ssize_t simple_attr_write(struct file *file, const char __user *buf, ssize_t ret; attr = file->private_data; - if (!attr->set) + if (!attr || !attr->set) return -EACCES; ret = mutex_lock_interruptible(>mutex); -- 1.7.12.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 update 2/3] x86: Delete too many "Fast TSC .." in dmesg from HW_latency cyclic sampling
"Fast TSC calibration using PIT" should be a devel info.
Signed-off-by: Luming Yu
---
arch/x86/kernel/tsc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index cfa5d4f..7765546 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -393,7 +393,7 @@ success:
*/
delta *= PIT_TICK_RATE;
do_div(delta, i*256*1000);
- pr_info("Fast TSC calibration using PIT\n");
+ pr_devel("Fast TSC calibration using PIT\n");
return delta;
}
--
1.7.12.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 update 1/3] HW-latency: hardware latency test 0.10
This patch is the first step to test some basic hardware functions like
TSC to help people understand if there is any hardware latency as well
as throughput problem exposed on bare metal or left behind by BIOS or
interfered by SMI. Currently the patch tests TSC, CPU Frequency and
RDRAND which is a new CPU instruction to get random number introduced in
new CPU like Intel Ivy Bridge in stop_machine context,which is choosen to
make sure testers fully control their system under test to rule out some
level of unwanted noise.
Signed-off-by: Jon Masters
Signed-off-by: Luming Yu
---
drivers/misc/Kconfig | 6 +
drivers/misc/Makefile | 1 +
drivers/misc/hw_latency_test.c | 939 +
3 files changed, 946 insertions(+)
create mode 100644 drivers/misc/hw_latency_test.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index b151b7c..a00b039 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -114,6 +114,12 @@ config IBM_ASM
for information on the specific driver level and support statement
for your IBM server.
+config HW_LATENCY_TEST
+ tristate "Testing module to detect hardware lattency and throughput"
+ depends on DEBUG_FS
+ depends on RING_BUFFER
+ default m
+
config PHANTOM
tristate "Sensable PHANToM (PCI)"
depends on PCI
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 2129377..c195cce 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -49,3 +49,4 @@ obj-y += carma/
obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o
obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/
obj-$(CONFIG_INTEL_MEI)+= mei/
+obj-$(CONFIG_HW_LATENCY_TEST) += hw_latency_test.o
diff --git a/drivers/misc/hw_latency_test.c b/drivers/misc/hw_latency_test.c
new file mode 100644
index 000..0a4d23b
--- /dev/null
+++ b/drivers/misc/hw_latency_test.c
@@ -0,0 +1,939 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define BUF_SIZE_DEFAULT 262144UL
+#define BUF_FLAGS (RB_FL_OVERWRITE)
+#defineU64STR_SIZE 22
+#define DEBUGFS_BUF_SIZE 1024
+#define DEBUGFS_NAME_SIZE 32
+
+#defineVERSION "0.1.0"
+#define BANNER "hardware latency test"
+#define DRVNAME"hw_latency_test"
+
+#define DEFAULT_SAMPLE_WINDOW 100
+#defineDEFAULT_SAMPLE_WIDTH50
+#defineDEFAULT_LAT_THRESHOLD 10
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Luming Yu ");
+MODULE_DESCRIPTION("A simple hardware latency test");
+MODULE_VERSION(VERSION);
+
+static int debug;
+static int enabled;
+static int threshold;
+
+module_param(debug, int, 0);
+module_param(enabled, int, 0);
+module_param(threshold, int, 0);
+
+static struct ring_buffer *ring_buffer;
+static DEFINE_MUTEX(ring_buffer_mutex);
+static unsigned long buf_size = 262144UL;
+static struct task_struct *kthread;
+
+#ifdef CONFIG_X86_64
+static u8 *__start = (u8 *)0x8800;
+static u8 *__end = (u8 *)0xc7ff;
+#else
+static u8 *__start = (u8 *)0xc000;
+static u8 *__end = (u8 *)0x;
+#endif
+
+struct sample {
+ unsigned int cpu;
+ u64 seqnum;
+ u64 duration;
+ struct timespec timestamp;
+ u64 addr;
+ u8 unit; /*0: ns 1:us*/
+ unsigned long lost;
+};
+
+static struct data {
+ struct mutex lock;
+ u64 count;
+ u64 max_sample;
+ u64 threshold;
+
+ u64 sample_window;
+ u64 sample_width;
+
+ atomic_t sample_open;
+
+ wait_queue_head_t wq;
+} data;
+
+static ktime_t now;
+struct sample_function {
+ const char *name;
+ u8 type; /* 0=all parallel, 1=anyone, 2=all sequential*/
+ struct list_head list;
+ int (*get_sample)(void *unused);
+};
+static struct sample_function *current_sample_func = NULL;
+static LIST_HEAD(sample_function_list);
+static DEFINE_MUTEX(sample_function_mutex);
+static int sample_function_register(struct sample_function *sf);
+static struct dentry *debug_dir;
+
+static int sample_function_register(struct sample_function *sf)
+{
+ struct list_head *entry = _function_list;
+ mutex_lock(_function_mutex);
+ list_add(>list, entry);
+ current_sample_func = sf;
+ mutex_unlock(_function_mutex);
+ return 0;
+}
+
+static int __buffer_add_sample(struct sample *sample)
+{
+ return ring_buffer_write(ring_buffer,
+ sizeof(struct sample), sample);
+}
+
+static struct sample *buffer_get_sample(struct sample *sample)
+{
+ struct ring_buffer_event *e = NULL;
+ struct sample *s = NULL;
+ unsigned int cpu = 0;
+
+ if (!sample)
+ return NULL;
+
+ mutex_lock(_buffer_mutex);
+ for_each_online_cpu(cpu) {
+
[PATCH update 0/3] HW-latency: hardware latency test 0.10
Update the previous patch series to ACK all comments I've recevied so far for the tool: e.g. 1.Acked Jon Masters in source code as many code are from jcm, thanks very much Jon. 2. squashed all changes against new file I added into one. 3. Make it useful on non-x86. Please review and commit to misc tree. I will update the patch series if anyone has anymore comments. Thanks very much!!! Luming Yu (3): HW-latency: hardware latency test 0.10 x86: Delete too many "Fast TSC .." in dmesg from HW_latency cyclic sampling fs: Fix crash caused by write to dummy debugfs interface like HW_latency exposed arch/x86/kernel/tsc.c | 2 +- drivers/misc/Kconfig | 6 + drivers/misc/Makefile | 1 + drivers/misc/hw_latency_test.c | 939 + fs/libfs.c | 2 +- 5 files changed, 948 insertions(+), 2 deletions(-) create mode 100644 drivers/misc/hw_latency_test.c -- 1.7.12.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 usb-linus] USB: keyspan: fix typo causing GPF on open
On Sat, Nov 10, 2012 at 10:13 AM, Bjørn Mork wrote:
> Commit f79b2d0f (USB: keyspan: fix NULL-pointer dereferences and
> memory leaks) had a small typo which made the driver use wrong
> offsets when mapping serial port private data. This results in
> in a GPF when the port is opened.
>
> Reported-by: Richard
> Cc:
> Cc: Johan Hovold
> Signed-off-by: Bjørn Mork
Acked-by: Johan Hovold
> ---
> Hello Richard,
>
> I wonder if you are able to test and verify this? I do not guarantee
> that there aren't other issues around, but this small typo looked like
> an obvious killer...
Good catch, Bjørn.
Greg, this one needs to be backported to v3.6.x.
Note that the usb_get_serial_data call below was simply redundant,
so that part is really a clean up rather than part of the fix.
Thanks,
Johan
> Bjørn
>
> drivers/usb/serial/keyspan.c |3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/usb/serial/keyspan.c b/drivers/usb/serial/keyspan.c
> index 7179b0c..cff8dd5 100644
> --- a/drivers/usb/serial/keyspan.c
> +++ b/drivers/usb/serial/keyspan.c
> @@ -2430,7 +2430,7 @@ static void keyspan_release(struct usb_serial *serial)
> static int keyspan_port_probe(struct usb_serial_port *port)
> {
> struct usb_serial *serial = port->serial;
> - struct keyspan_port_private *s_priv;
> + struct keyspan_serial_private *s_priv;
> struct keyspan_port_private *p_priv;
> const struct keyspan_device_details *d_details;
> struct callbacks *cback;
> @@ -2445,7 +2445,6 @@ static int keyspan_port_probe(struct usb_serial_port
> *port)
> if (!p_priv)
> return -ENOMEM;
>
> - s_priv = usb_get_serial_data(port->serial);
> p_priv->device_details = d_details;
>
> /* Setup values for the various callback routines */
> --
> 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: macbook pro 9.2 stat/ata bus error
Yeah, I'm guessed about this.
Thanks for reply.
On Fri, Nov 9, 2012 at 7:48 AM, Robert Hancock wrote:
> On 11/06/2012 09:41 PM, Azat Khuzhin wrote:
>>
>> Anybody?
>>
>> On Mon, Nov 5, 2012 at 7:28 PM, Azat Khuzhin
>> wrote:
>>>
>>> After installing linux on macbook 9.2 (mid 2012), I have next errors
>>> in dmesg log:
>>>
>>> [ 389.623828] EXT4-fs (sda4): re-mounted. Opts:
>>> errors=remount-ro,data=ordered,commit=600
>>> [ 410.038465] NMI watchdog: enabled on all CPUs, permanently consumes
>>> one hw-PMU counter.
>>> [ 410.075042] ehci_hcd :00:1a.0: setting latency timer to 64
>>> [ 410.483526] EXT4-fs (sda4): re-mounted. Opts:
>>> errors=remount-ro,data=ordered,commit=0
>>> [ 1401.834509] EXT4-fs (sda4): re-mounted. Opts:
>>> errors=remount-ro,data=ordered,commit=1800
>>> [ 1406.467268] NMI watchdog: enabled on all CPUs, permanently consumes
>>> one hw-PMU counter.
>>> [ 1406.506769] ehci_hcd :00:1a.0: setting latency timer to 64
>>> [ 1406.590122] EXT4-fs (sda4): re-mounted. Opts:
>>> errors=remount-ro,data=ordered,commit=0
>>> [ 1407.492260] ata2.00: exception Emask 0x10 SAct 0x0 SErr 0x5
>>> action 0xe frozen
>>> [ 1407.494441] ata2.00: irq_stat 0x0040, PHY RDY changed
>>> [ 1407.495238] ata2: SError: { PHYRdyChg CommWake }
>>> [ 1407.496035] sr 1:0:0:0: CDB:
>>> [ 1407.497333] Get event status notification: 4a 01 00 00 10 00 00 00 08
>>> 00
>>> [ 1407.498285] ata2.00: cmd a0/00:00:00:08:00/00:00:00:00:00/a0 tag 0
>>> pio 16392 in
>>> [ 1407.498285] res 50/00:03:00:00:00/00:00:00:00:00/a0 Emask
>>> 0x10 (ATA bus error)
>>> [ 1407.501987] ata2.00: status: { DRDY }
>>> [ 1407.502882] ata2: hard resetting link
>>> [ 1408.230302] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>> [ 1408.233279] ata2.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES)
>>> filtered out
>>> [ 1408.237467] ata2.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES)
>>> filtered out
>>> [ 1408.239084] ata2.00: configured for UDMA/100
>>> [ 1408.262238] ata2: EH complete
>
>
> Is this after a resume? It could be that for some reason the SATA link is a
> little bit unstable right after the machine powers up again. There may not
> be much the kernel can do about this..
>
>
>>> [ 3565.785609] EXT4-fs (sda4): re-mounted. Opts:
>>> errors=remount-ro,data=ordered,commit=1800
>>> [ 3576.921499] NMI watchdog: enabled on all CPUs, permanently consumes
>>> one hw-PMU counter.
>>> [ 3576.958624] ehci_hcd :00:1a.0: setting latency timer to 64
>>> [ 3577.114612] EXT4-fs (sda4): re-mounted. Opts:
>>> errors=remount-ro,data=ordered,commit=0
>>> [ 3577.923688] ata2.00: exception Emask 0x10 SAct 0x0 SErr 0x5
>>> action 0xe frozen
>>> [ 3577.925852] ata2.00: irq_stat 0x0040, PHY RDY changed
>>> [ 3577.926746] ata2: SError: { PHYRdyChg CommWake }
>>> [ 3577.927544] sr 1:0:0:0: CDB:
>>> [ 3577.928345] Get event status notification: 4a 01 00 00 10 00 00 00 08
>>> 00
>>> [ 3577.929642] ata2.00: cmd a0/00:00:00:08:00/00:00:00:00:00/a0 tag 0
>>> pio 16392 in
>>> [ 3577.929642] res 50/00:03:00:00:00/00:00:00:00:00/a0 Emask
>>> 0x10 (ATA bus error)
>>> [ 3577.932954] ata2.00: status: { DRDY }
>>> [ 3577.934264] ata2: hard resetting link
>>> [ 3578.662228] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>> [ 3578.665211] ata2.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES)
>>> filtered out
>>> [ 3578.669355] ata2.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES)
>>> filtered out
>>> [ 3578.670969] ata2.00: configured for UDMA/100
>>> [ 3578.694145] ata2: EH complete
>>>
>>> Is it linux driver, or maybe
>>>
>>> $ lspci # sata information only
>>> 00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family
>>> 6-port SATA Controller [AHCI mode] (rev 04) (prog-if 01 [AHCI 1.0])
>>> Subsystem: Intel Corporation Device 7270
>>> Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 20
>>> I/O ports at 2098 [size=8]
>>> I/O ports at 20bc [size=4]
>>> I/O ports at 2090 [size=8]
>>> I/O ports at 20b8 [size=4]
>>> I/O ports at 2060 [size=32]
>>> Memory at a0816000 (32-bit, non-prefetchable) [size=2K]
>>> Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
>>> Capabilities: [70] Power Management version 3
>>> Capabilities: [a8] SATA HBA v1.0
>>> Capabilities: [b0] PCI Advanced Features
>>> Kernel driver in use: ahci
>>>
>>> $ uname -a
>>> Linux macbook-pro 3.6.5macbook-pro-custom-v0.1 #4 SMP Sun Nov 4
>>> 12:39:03 UTC 2012 x86_64 GNU/Linux
>>> $ cat /etc/debian_version
>>> wheezy/sid
>>>
>>> In OSX there is no errors with hard drive.
>>>
>>> What else can I do investigate this situation next?
>>>
>>> --
>>> Azat Khuzhin
>>
>>
>>
>>
>
--
Azat Khuzhin
--
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
Re: [PATCH] kbuild: Do not remove vmlinux when cleaning external module
Pawel Moll writes: > Since commit 1f2bfbd00e466ff3489b2ca5cc75b1cccd14c123 "kbuild: > link of vmlinux moved to a script" make clean with M= > argument (so cleaning external module) removes vmlinux, > System.map and couple of other files from the *main* kernel > build directory! This not what was happening before and almost > certainly not what one would expect. > This patch moves makes the clean target of the script called > only when !KBUILD_EXTMOD. Thanks, I have the same problem and this patch fixes it. Michal, can you pick it up? It's not yet in kbuild.git, it seems. -- 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/4] perf, amd: Enable AMD family 15h northbridge counters
On 09.11.12 19:01:34, Jacob Shin wrote: > The following patchset enables 4 additional performance counters in > AMD family 15h processors that counts northbridge events -- such as > DRAM accesses. > > This patchset is based on previous work done by Robert Richter > : > > https://lkml.org/lkml/2012/6/19/324 The original patch set of this is here (a rebased version): http://git.kernel.org/?p=linux/kernel/git/rric/oprofile.git;a=shortlog;h=refs/heads/perf-nb This code was tested in detail. > The main differences are: > > - The northbridge counters are indexed contiguously right above the > core performance counters. > > - MSR address offset calculations are moved to architecture specific > files. > > - Interrups are set up to be delivered only to a single core. So I rather suggest to make delta patches on top of my patches. Peter's main concerns were that my patch set is not in the Intel-uncore style. I started reworking this but was not able to finish my work. This concerns still exist. Due to the current situation I would rather prefer to create a tip:perf/amd-nb branch that includes my patches and then add all further necessary steps for mainline acceptance on top of it. Thanks, -Robert -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] spi / ACPI: add ACPI enumeration support
On Sat, Nov 10, 2012 at 11:10 AM, Rafael J. Wysocki wrote: > On Friday, November 09, 2012 09:53:26 AM Bjorn Helgaas wrote: >> On Fri, Nov 9, 2012 at 9:43 AM, Grant Likely >> wrote: >> > On Fri, Nov 9, 2012 at 4:35 PM, Bjorn Helgaas wrote: >> >> On Fri, Nov 9, 2012 at 8:45 AM, Grant Likely >> >> wrote: >> >>> On Fri, Nov 9, 2012 at 3:11 PM, Bjorn Helgaas >> >>> wrote: >> [+cc Greg, Peter, Tony since they acked the original patch [1]] >> >> On Thu, Nov 8, 2012 at 1:04 PM, Mika Westerberg >> wrote: >> > On Thu, Nov 08, 2012 at 12:32:25PM -0700, Bjorn Helgaas wrote: >> >> Struct device_driver is a generic structure, so it seems strange to >> >> have to include non-generic things like of_device_id and now >> >> acpi_match_table there. >> > >> > Yes, but in a sense the DT and ACPI are "generic". So that they are >> > used to >> > describe the configuration of a machine. >> >> What I meant by "generic" was "useful across all architectures." The >> new acpi_match_table and acpi_handle fields [1] are not generic in >> that sense because they're present on all architectures but used only >> on x86 and ia64. The existing of_match_table and of_node are >> similarly unused on many architectures. This doesn't seem like a >> scalable strategy to me. Are we going to add a pnpbios_node for x86 >> PNPBIOS machines without ACPI, a pdc_hpa for parisc machines with PDC, >> etc.? >> >> [1] https://patchwork.kernel.org/patch/1677221/ >> >>> >> >>> Ultimately yes, I think that is what we want to do, >> >> >> >> Just to be clear, you think we *should* add things like pnpbios_node, >> >> pdc_hpa, etc., to struct device, one field for every scheme of telling >> >> the OS about non-enumerable devices, where only one of the N fields is >> >> used on any given machine? That seems surprising to me, but maybe I >> >> just need to be educated :) >> > >> > Ah, I see what you're asking. >> > >> > In the short term, yes but only because we don't have any other >> > alternative. What I'd really rather have is a safe way to attach datum >> > (ie. acpi_device or device_node) to a struct device and get it back >> > later in a type safe way. >> >> Yep, *that* makes perfect sense to me. Something along these lines, maybe: >> >> #define dev_is_acpi(d)((d)->bus == _bus_type) > > No, that's not right. It won't work for things like SPI and I2C with a > "backing" ACPI device node anyway (and for PCI too, by the way :-)). > >> #define dev_acpi_handle(d)(dev_is_acpi(d) ? (acpi_handle) >> d->datum : NULL) > > The problem basically is how we can tell that the given struct device has > a "backing" object containing device information (e.g. resources) and what > that "backing" object is. For device trees that would be a struct device_node > and for ACPI that would be an acpi_handle or a struct acpi_device etc. And by > the way, they _can_ be used simultaneously, in principle. > > So we need something like of_node(dev) or acpi_node(dev), but that can't be > something following two pointers or calling a function just in order to check > if the pointer _is_ _there_ in either case. > > And since we added of_node to struct device at one point, it is only logical > to > treat ACPI in the same way. If we come up with a better idea _later_, then we > can convert _all_ things to this new idea, whatever it is. > > Are you seriously expecting us to come up with such an idea on the fly just so > that we can use ACPI support, which already is there in the form of > archdata.acpi_handle anyway, on equal footing with Device Trees? I'm certainly not. I agree with adding it to struct device now and replace it later if someone designs something better. I also agree with using a dev_acpi_node() macro as you described above. I went the opposite way with device tree, and I absolutely regret it. g. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] spi / ACPI: add ACPI enumeration support
On Friday, November 09, 2012 09:53:26 AM Bjorn Helgaas wrote: > On Fri, Nov 9, 2012 at 9:43 AM, Grant Likely > wrote: > > On Fri, Nov 9, 2012 at 4:35 PM, Bjorn Helgaas wrote: > >> On Fri, Nov 9, 2012 at 8:45 AM, Grant Likely > >> wrote: > >>> On Fri, Nov 9, 2012 at 3:11 PM, Bjorn Helgaas wrote: > [+cc Greg, Peter, Tony since they acked the original patch [1]] > > On Thu, Nov 8, 2012 at 1:04 PM, Mika Westerberg > wrote: > > On Thu, Nov 08, 2012 at 12:32:25PM -0700, Bjorn Helgaas wrote: > >> Struct device_driver is a generic structure, so it seems strange to > >> have to include non-generic things like of_device_id and now > >> acpi_match_table there. > > > > Yes, but in a sense the DT and ACPI are "generic". So that they are > > used to > > describe the configuration of a machine. > > What I meant by "generic" was "useful across all architectures." The > new acpi_match_table and acpi_handle fields [1] are not generic in > that sense because they're present on all architectures but used only > on x86 and ia64. The existing of_match_table and of_node are > similarly unused on many architectures. This doesn't seem like a > scalable strategy to me. Are we going to add a pnpbios_node for x86 > PNPBIOS machines without ACPI, a pdc_hpa for parisc machines with PDC, > etc.? > > [1] https://patchwork.kernel.org/patch/1677221/ > >>> > >>> Ultimately yes, I think that is what we want to do, > >> > >> Just to be clear, you think we *should* add things like pnpbios_node, > >> pdc_hpa, etc., to struct device, one field for every scheme of telling > >> the OS about non-enumerable devices, where only one of the N fields is > >> used on any given machine? That seems surprising to me, but maybe I > >> just need to be educated :) > > > > Ah, I see what you're asking. > > > > In the short term, yes but only because we don't have any other > > alternative. What I'd really rather have is a safe way to attach datum > > (ie. acpi_device or device_node) to a struct device and get it back > > later in a type safe way. > > Yep, *that* makes perfect sense to me. Something along these lines, maybe: > > #define dev_is_acpi(d)((d)->bus == _bus_type) No, that's not right. It won't work for things like SPI and I2C with a "backing" ACPI device node anyway (and for PCI too, by the way :-)). > #define dev_acpi_handle(d)(dev_is_acpi(d) ? (acpi_handle) > d->datum : NULL) The problem basically is how we can tell that the given struct device has a "backing" object containing device information (e.g. resources) and what that "backing" object is. For device trees that would be a struct device_node and for ACPI that would be an acpi_handle or a struct acpi_device etc. And by the way, they _can_ be used simultaneously, in principle. So we need something like of_node(dev) or acpi_node(dev), but that can't be something following two pointers or calling a function just in order to check if the pointer _is_ _there_ in either case. And since we added of_node to struct device at one point, it is only logical to treat ACPI in the same way. If we come up with a better idea _later_, then we can convert _all_ things to this new idea, whatever it is. Are you seriously expecting us to come up with such an idea on the fly just so that we can use ACPI support, which already is there in the form of archdata.acpi_handle anyway, on equal footing with Device Trees? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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] target: Update copyright ownership to 2012
On Fri, Nov 09, 2012 at 11:00:14PM +, Nicholas A. Bellinger wrote: > From: Nicholas Bellinger > > Hello everyone, > > This patch to update copyright year to current for principal target core > ownership is now being pushed into target-pending/for-next. > > Signed-off-by: Nicholas Bellinger > --- > drivers/target/target_core_alua.c|5 +++-- > drivers/target/target_core_configfs.c|5 +++-- > drivers/target/target_core_device.c |7 +++ > drivers/target/target_core_fabric_configfs.c |7 --- > drivers/target/target_core_fabric_lib.c |5 +++-- > drivers/target/target_core_file.c|7 +++ > drivers/target/target_core_hba.c |7 +++ > drivers/target/target_core_iblock.c |7 +++ > drivers/target/target_core_pr.c |5 +++-- > drivers/target/target_core_pscsi.c |7 +++ > drivers/target/target_core_rd.c |7 +++ > drivers/target/target_core_sbc.c |7 +++ > drivers/target/target_core_spc.c |7 +++ > drivers/target/target_core_stat.c|7 +++ > drivers/target/target_core_tmr.c |5 +++-- > drivers/target/target_core_tpg.c |7 +++ > drivers/target/target_core_transport.c |7 +++ > drivers/target/target_core_ua.c |5 +++-- > 18 files changed, 55 insertions(+), 59 deletions(-) > > diff --git a/drivers/target/target_core_alua.c > b/drivers/target/target_core_alua.c > index 4c8eea2..035c606 100644 > --- a/drivers/target/target_core_alua.c > +++ b/drivers/target/target_core_alua.c > @@ -3,8 +3,9 @@ > * > * This file contains SPC-3 compliant asymmetric logical unit assigntment > (ALUA) > * > - * Copyright (c) 2009-2010 Rising Tide Systems > - * Copyright (c) 2009-2010 Linux-iSCSI.org > + * (c) Copyright 2009-2012 RisingTide Systems LLC. > + * > + * Licensed to the Linux Foundation under the General Public License (GPL) > version 2. > * > * Nicholas A. Bellinger > * Why do you remove Linux-iSCSI.org copyright? -- Kirill A. Shutemov -- 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/1] staging: usbip: make the code consistent using the variable name 'vhci' instead of 'dum'.
Signed-off-by: Harvey Yang
---
drivers/staging/usbip/vhci_hcd.c | 80 +++---
1 files changed, 40 insertions(+), 40 deletions(-)
diff --git a/drivers/staging/usbip/vhci_hcd.c b/drivers/staging/usbip/vhci_hcd.c
index 620d1be..6771668 100644
--- a/drivers/staging/usbip/vhci_hcd.c
+++ b/drivers/staging/usbip/vhci_hcd.c
@@ -244,7 +244,7 @@ static inline void hub_descriptor(struct usb_hub_descriptor
*desc)
static int vhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
u16 wIndex, char *buf, u16 wLength)
{
- struct vhci_hcd *dum;
+ struct vhci_hcd *vhci;
int retval = 0;
unsigned long flags;
int rhport;
@@ -264,13 +264,13 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16
typeReq, u16 wValue,
pr_err("invalid port number %d\n", wIndex);
rhport = ((__u8)(wIndex & 0x00ff)) - 1;
- dum = hcd_to_vhci(hcd);
+ vhci = hcd_to_vhci(hcd);
- spin_lock_irqsave(>lock, flags);
+ spin_lock_irqsave(>lock, flags);
/* store old status and compare now and old later */
if (usbip_dbg_flag_vhci_rh) {
- memcpy(prev_port_status, dum->port_status,
+ memcpy(prev_port_status, vhci->port_status,
sizeof(prev_port_status));
}
@@ -281,31 +281,31 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16
typeReq, u16 wValue,
case ClearPortFeature:
switch (wValue) {
case USB_PORT_FEAT_SUSPEND:
- if (dum->port_status[rhport] & USB_PORT_STAT_SUSPEND) {
+ if (vhci->port_status[rhport] & USB_PORT_STAT_SUSPEND) {
/* 20msec signaling */
- dum->resuming = 1;
- dum->re_timeout =
+ vhci->resuming = 1;
+ vhci->re_timeout =
jiffies + msecs_to_jiffies(20);
}
break;
case USB_PORT_FEAT_POWER:
usbip_dbg_vhci_rh(" ClearPortFeature: "
"USB_PORT_FEAT_POWER\n");
- dum->port_status[rhport] = 0;
- /* dum->address = 0; */
- /* dum->hdev = 0; */
- dum->resuming = 0;
+ vhci->port_status[rhport] = 0;
+ /* vhci->address = 0; */
+ /* vhci->hdev = 0; */
+ vhci->resuming = 0;
break;
case USB_PORT_FEAT_C_RESET:
usbip_dbg_vhci_rh(" ClearPortFeature: "
"USB_PORT_FEAT_C_RESET\n");
- switch (dum->vdev[rhport].speed) {
+ switch (vhci->vdev[rhport].speed) {
case USB_SPEED_HIGH:
- dum->port_status[rhport] |=
+ vhci->port_status[rhport] |=
USB_PORT_STAT_HIGH_SPEED;
break;
case USB_SPEED_LOW:
- dum->port_status[rhport] |=
+ vhci->port_status[rhport] |=
USB_PORT_STAT_LOW_SPEED;
break;
default:
@@ -314,7 +314,7 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16
typeReq, u16 wValue,
default:
usbip_dbg_vhci_rh(" ClearPortFeature: default %x\n",
wValue);
- dum->port_status[rhport] &= ~(1 << wValue);
+ vhci->port_status[rhport] &= ~(1 << wValue);
break;
}
break;
@@ -338,40 +338,40 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16
typeReq, u16 wValue,
/* whoever resets or resumes must GetPortStatus to
* complete it!!
* */
- if (dum->resuming && time_after(jiffies, dum->re_timeout)) {
- dum->port_status[rhport] |=
+ if (vhci->resuming && time_after(jiffies, vhci->re_timeout)) {
+ vhci->port_status[rhport] |=
(1 << USB_PORT_FEAT_C_SUSPEND);
- dum->port_status[rhport] &=
+ vhci->port_status[rhport] &=
~(1 << USB_PORT_FEAT_SUSPEND);
- dum->resuming = 0;
- dum->re_timeout = 0;
- /* if (dum->driver && dum->driver->resume) {
-*
Re: [PATCH] block: Use NUMA_NO_NODE instead of -1
On 2012-11-10 10:38, Jens Axboe wrote: > On 2012-11-09 16:37, Ezequiel Garcia wrote: >> Cc: Jens Axboe >> Signed-off-by: Ezequiel Garcia > > Thanks, applied. BTW, you missed blk_init_queue(), I fixed up that one too. -- Jens Axboe -- 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] block: Use NUMA_NO_NODE instead of -1
On 2012-11-09 16:37, Ezequiel Garcia wrote: > Cc: Jens Axboe > Signed-off-by: Ezequiel Garcia Thanks, applied. -- Jens Axboe -- 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 usb-linus] USB: keyspan: fix typo causing GPF on open
Commit f79b2d0f (USB: keyspan: fix NULL-pointer dereferences and
memory leaks) had a small typo which made the driver use wrong
offsets when mapping serial port private data. This results in
in a GPF when the port is opened.
Reported-by: Richard
Cc:
Cc: Johan Hovold
Signed-off-by: Bjørn Mork
---
Hello Richard,
I wonder if you are able to test and verify this? I do not guarantee
that there aren't other issues around, but this small typo looked like
an obvious killer...
Bjørn
drivers/usb/serial/keyspan.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/serial/keyspan.c b/drivers/usb/serial/keyspan.c
index 7179b0c..cff8dd5 100644
--- a/drivers/usb/serial/keyspan.c
+++ b/drivers/usb/serial/keyspan.c
@@ -2430,7 +2430,7 @@ static void keyspan_release(struct usb_serial *serial)
static int keyspan_port_probe(struct usb_serial_port *port)
{
struct usb_serial *serial = port->serial;
- struct keyspan_port_private *s_priv;
+ struct keyspan_serial_private *s_priv;
struct keyspan_port_private *p_priv;
const struct keyspan_device_details *d_details;
struct callbacks *cback;
@@ -2445,7 +2445,6 @@ static int keyspan_port_probe(struct usb_serial_port
*port)
if (!p_priv)
return -ENOMEM;
- s_priv = usb_get_serial_data(port->serial);
p_priv->device_details = d_details;
/* Setup values for the various callback routines */
--
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 1/2] drm: Add NVIDIA Tegra20 support
On Fri, Nov 09, 2012 at 05:09:51PM -0700, Stephen Warren wrote: > On 11/09/2012 06:59 AM, Thierry Reding wrote: > > This commit adds a KMS driver for the Tegra20 SoC. This includes basic > > support for host1x and the two display controllers found on the Tegra20 > > SoC. Each display controller can drive a separate RGB/LVDS output. > > I applied these two patches and the two arch/arm/mach-tegra patches you > posted, directly on top of next-20121109, and I see the following build > failure: > > > drivers/gpu/drm/tegra/output.c: In function 'tegra_output_init': > > drivers/gpu/drm/tegra/output.c:166:9: error: 'struct tegra_output' has no > > member named 'display' > > drivers/gpu/drm/tegra/output.c:166:3: error: implicit declaration of > > function 'of_get_display' > > drivers/gpu/drm/tegra/output.c:167:20: error: 'struct tegra_output' has no > > member named 'display' > > drivers/gpu/drm/tegra/output.c:168:25: error: 'struct tegra_output' has no > > member named 'display' > > drivers/gpu/drm/tegra/output.c:179:13: error: 'struct tegra_output' has no > > member named 'display' > > drivers/gpu/drm/tegra/output.c:180:3: error: implicit declaration of > > function 'display_put' > > drivers/gpu/drm/tegra/output.c:180:21: error: 'struct tegra_output' has no > > member named 'display' > > drivers/gpu/drm/tegra/output.c:257:20: error: 'struct tegra_output' has no > > member named 'display' > > drivers/gpu/drm/tegra/output.c: In function 'tegra_output_exit': > > drivers/gpu/drm/tegra/output.c:272:20: error: 'struct tegra_output' has no > > member named 'display' > > Does this depend on something not in linux-next? It looks like I missed some changes when I split the patches up and then forgot to check that the patches actually still build. I'll make sure to fix that in the next round. Sorry for the inconvenience. Thierry pgpniIGD4wMGz.pgp Description: PGP signature
Re: [patch,v3 04/10] scsi: allocate scsi_cmnd-s from the device's local numa node
On 11/09/12 20:18, Jeff Moyer wrote: - cmd = kmem_cache_zalloc(pool->cmd_slab, gfp_mask | pool->gfp_mask); + cmd = kmem_cache_alloc_node(pool->cmd_slab, + gfp_mask | pool->gfp_mask | __GFP_ZERO, + node); Hello Jeff, Is it necessary to add __GFP_ZERO here ? And if so, why ? Thanks, Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] input: stmpe-ts: Use devm_*() routines
On Sat, Nov 10, 2012 at 01:34:33PM +0530, Viresh Kumar wrote: > wrapped again.. Don't know how to disable it. :( To quote Documentation/email-clients.txt: ~ Gmail (Web GUI) Does not work for sending patches. Gmail web client converts tabs to spaces automatically. At the same time it wraps lines every 78 chars with CRLF style line breaks although tab2space problem can be solved with external editor. Another problem is that Gmail will base64-encode any message that has a non-ASCII character. That includes things like European names. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] input: stmpe-ts: Use devm_*() routines
On Sat, Nov 10, 2012 at 01:34:33PM +0530, Viresh Kumar wrote: > On 10 November 2012 13:33, Viresh Kumar wrote: > > On 10 November 2012 13:30, Dmitry Torokhov > > wrote: > >> Sometimes your mailer does wrap long lines, please make sure to turn it > >> off for patches. > > > > I am using gmail for replying on mails and this fixup was done using that. > > Don't > > know why it happened. > > > > I am doing the same step again to verify what's playing with patches. > > On this copy > > i can see that this issue isn't there till now. > > > > diff --git a/drivers/input/touchscreen/stmpe-ts.c > > > @@ -344,8 +344,6 @@ static int __devexit stmpe_ts_remove(struct > > platform_device *pdev) > > wrapped again.. Don't know how to disable it. :( I just use mutt... -- Dmitry -- 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: Issues with "x86, um: switch to generic fork/vfork/clone" commit
On Fri, Nov 9, 2012 at 11:33 PM, Al Viro wrote: > Could you verify that this on top of for-next gets the things working again? > It's a very lazy way to deal with that (we don't want to bother with > restoring extras, at the very least), but the rest can go separately (and > is shared with mainline, unlike that one). It seems to be working here, > but I'd like to see your ACK as well. If everything works, it'll get > folded into the offending commit... > > diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S > index 633649e..32e6f05 100644 > --- a/arch/x86/ia32/ia32entry.S > +++ b/arch/x86/ia32/ia32entry.S > @@ -467,11 +467,16 @@ GLOBAL(\label) > PTREGSCALL stub32_sigaltstack, sys32_sigaltstack, %rdx > PTREGSCALL stub32_execve, compat_sys_execve, %rcx > PTREGSCALL stub32_fork, sys_fork, %rdi > - PTREGSCALL stub32_clone, sys_clone, %rdx > PTREGSCALL stub32_vfork, sys_vfork, %rdi > PTREGSCALL stub32_iopl, sys_iopl, %rsi > > ALIGN > +GLOBAL(stub32_clone) > + leaq sys_clone(%rip),%rax > + mov %r8, %rcx > + jmp ia32_ptregs_common > + > + ALIGN > ia32_ptregs_common: > popq %r11 > CFI_ENDPROC Yes, I tested the above by applying it on top of mmotm and it did solve the issue. Thanks, -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] input: stmpe-ts: Use devm_*() routines
On 10 November 2012 13:33, Viresh Kumar wrote: > On 10 November 2012 13:30, Dmitry Torokhov wrote: >> Sometimes your mailer does wrap long lines, please make sure to turn it >> off for patches. > > I am using gmail for replying on mails and this fixup was done using that. > Don't > know why it happened. > > I am doing the same step again to verify what's playing with patches. > On this copy > i can see that this issue isn't there till now. > > diff --git a/drivers/input/touchscreen/stmpe-ts.c > @@ -344,8 +344,6 @@ static int __devexit stmpe_ts_remove(struct > platform_device *pdev) wrapped again.. Don't know how to disable it. :( -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] input: stmpe-ts: Use devm_*() routines
On 10 November 2012 13:30, Dmitry Torokhov wrote: > Sometimes your mailer does wrap long lines, please make sure to turn it > off for patches. I am using gmail for replying on mails and this fixup was done using that. Don't know why it happened. I am doing the same step again to verify what's playing with patches. On this copy i can see that this issue isn't there till now. commit dda6d45808d65aaf8b0d4153e7a418b255365818 Author: Viresh Kumar Date: Fri Nov 9 22:28:26 2012 +0530 fixup! input: stmpe-ts: Use devm_*() routines --- drivers/input/touchscreen/stmpe-ts.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/input/touchscreen/stmpe-ts.c b/drivers/input/touchscreen/stmpe-ts.c index 9896095..f2cb15d 100644 --- a/drivers/input/touchscreen/stmpe-ts.c +++ b/drivers/input/touchscreen/stmpe-ts.c @@ -344,8 +344,6 @@ static int __devexit stmpe_ts_remove(struct platform_device *pdev) stmpe_disable(ts->stmpe, STMPE_BLOCK_TOUCHSCREEN); - input_unregister_device(ts->idev); - return 0; } -- viresh -- 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/
