Re: Disable bus's drivers_autoprobe before rootfs has mounted
On Wed, Jun 11, 2014 at 03:27:13PM -0400, Alan Stern wrote: On Wed, 11 Jun 2014, Greg KH wrote: We can't break existing systems, so I don't understand the issue here. Just don't configure your kernel for a system you don't have / want, right? From what I read code, we can't implement above feature, but I may be wrong, if you have some solutions, give me some hints please. If there is no solution for above feature, do we agree with exporting .drivers_autoprobe for bus driver or something similar? I don't understand what you mean by this, care to show me with code? I mean the individual bus driver can't change bus-p-drivers_autoprobe? bus-p-drivers_autoprobe is handled at drivers/base/bus.c. If the individual bus driver can change bus-p-drivers_autoprobe, we can disable autoprobe (auto-binding) during booting. No, that's a core only thing. Peter, correct me if this is wrong. It sounds like you want to have a way for the user to control which gadget driver gets bound to which UDC driver when everything is compiled into the kernel, nothing is built as a separate module. Is that the basic idea? Yes, I know it can be done by gadget-configfs, but how about the user chooses other gadgets, eg: g_webcam, g_audio? I forget to introduce the background of this topic, I have this issue when I implement gadget bus patch set. (http://www.spinics.net/lists/linux-usb/msg107797.html) The current behaviour for other gadgets is auto-binding, so I want to keep auto-binding at my gadget bus implementation, but manual-binding is also a feature we need to support for other gadgets, so I want auto-binding is the default binding way, and the user can switch the two binding ways, eg, module parameters or sys entry. But if both udc driver and gadget driver are built in, the user can't let manual-binding work during the boot since the device-model will do probe, and do auto-binding. My v1 patch set [3/4] do a tricky way to work around it, I would like to know if it can be supported by device model framework? This shouldn't be a problem if you use configfs or libusbg. Alan Stern -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disable bus's drivers_autoprobe before rootfs has mounted
On Wed, Jun 11, 2014 at 02:36:27PM -0500, Felipe Balbi wrote: On Wed, Jun 11, 2014 at 11:29:57AM +0800, Peter Chen wrote: On Tue, Jun 10, 2014 at 11:35:07PM -0500, Felipe Balbi wrote: Hi, On Tue, Jun 10, 2014 at 09:10:00PM -0700, Greg KH wrote: Let's take USB peripheral as an example, there is a device for udc, and a device driver for usb gadget driver, at default, we want the device to be bound to driver automatically, this is what we have done now. But if there are more than one udcs and gadget drivers (eg one B port for mass storage, another B port for usb ethernet), the user may want to have specific binding (eg, udc-0 - mass storage, udc-1 - usb ethernet), so the binding will be established after rootfs has mounted. (This feature is implementing) Then there better be a way to describe this on the kernel command line (i.e. module paramaters), right? Which is a total mess, why not just not bind anything in this case and let the user pick what they want? you can also blacklist all gadget drivers and manually probe them or - get this - you can refrain from using gadget drivers and use libusbg to build the gadget drivers out of raw usb functions, then bind them to the UDC of your liking. I am just worried if we change the behaviour of using gadget driver, can it be accepted by user? If you think it can be accepted if we can have some docs, we can implement manually binding for gadget driver from now on. user shouldn't have to deal with direct module insertion/removal (unless he's a developer and actually *wants* to do that). Docs are already in tree. The entire configfs interface has been documented, it's based on those documents that Matt started writing libusbg. -- balbi Yes, gadget-configfs is a good direction. I would like to know your plan for other gadget drivers (g_mass_storage, g_webcam, etc) All functions will be supported by configfs in future, and current driver will be deleted? - If yes, how to cover the user who still use the old file system? - If no, which binding way for udc and gadget driver will be used? Current binding way for non-configfs gadgets is auto-binding, if we don't want break user's current system, we need to keep auto-binding as the default binding way. With more, we can support manual binding with udc core. I am implementing gadget bus[1], it may not be benefit for gadget-configfs, but is benefit for other gadgets, eg, support loading gadget driver before udc driver, manual-binding between udc and gadget drivers, etc. So, I would like to know if you agree to keep auto-binding for current non-configfs gadget driver as default way (in that way, we can keep current system with no change), and manual-binding can be used by user with module parameters and /sys entry. [1] http://www.spinics.net/lists/linux-usb/msg109015.html -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] leds: USB: HID: Add support for MSI GT683R led panels
On Thu, Jun 12, 2014 at 01:48:41AM +0300, Janne Kanniainen wrote:
This driver adds support for USB controlled led panels that exists in MSI
GT683R laptop
You forgot to break this line.
Signed-off-by: Janne Kanniainen janne.kanniai...@gmail.com
---
Changes in v2:
- sorted headers to alphabetic order
- using devm_kzalloc
- using BIT(n)
- using usb_control_msg instead of usb_submit_urb
- removing unneeded code
Changes in v3:
- implemented as HID device
- some cleanups and bug fixes
Changes in v4:
- more cleanups
- support for selecting leds
- support for selecting status
That was fast. :)
drivers/hid/Kconfig | 11 ++
drivers/hid/Makefile| 1 +
drivers/hid/hid-core.c | 1 +
drivers/hid/hid-gt683r.c| 320
drivers/hid/hid-ids.h | 2 +-
drivers/hid/usbhid/hid-quirks.c | 2 +-
6 files changed, 335 insertions(+), 2 deletions(-)
create mode 100644 drivers/hid/hid-gt683r.c
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 7af9d0b..d93e0ae 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -261,6 +261,17 @@ config HOLTEK_FF
Say Y here if you have a Holtek On Line Grip based game controller
and want to have force feedback support for it.
+config HID_GT683R
+ tristate MSI GT68xR LED support
+ depends on LEDS_CLASS USB_HID
+ ---help---
+ Say Y here if you want to enable support for the MSI GT68xR LEDS
+
+ This driver support following states normal, breathing and audio.
+ You can also select which leds you want to enable.
+ Currently the following devices are know to be supported:
+ - MSI GT683R
+
config HID_HUION
tristate Huion tablets
depends on USB_HID
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index fc712dd..7129311 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_HID_EMS_FF)+= hid-emsff.o
obj-$(CONFIG_HID_ELECOM) += hid-elecom.o
obj-$(CONFIG_HID_ELO)+= hid-elo.o
obj-$(CONFIG_HID_EZKEY) += hid-ezkey.o
+obj-$(CONFIG_HID_GT683R) += hid-gt683r.o
obj-$(CONFIG_HID_GYRATION) += hid-gyration.o
obj-$(CONFIG_HID_HOLTEK) += hid-holtek-kbd.o
obj-$(CONFIG_HID_HOLTEK) += hid-holtek-mouse.o
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index da52279..ec88fdb 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1827,6 +1827,7 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_WIRELESS_OPTICAL_DESKTOP_3_0) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_OFFICE_KB) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MONTEREY, USB_DEVICE_ID_GENIUS_KB29E) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG, USB_DEVICE_ID_NTRIG_TOUCH_SCREEN)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG,
USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_1) },
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG,
USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_2) },
diff --git a/drivers/hid/hid-gt683r.c b/drivers/hid/hid-gt683r.c
new file mode 100644
index 000..04e4cc2
--- /dev/null
+++ b/drivers/hid/hid-gt683r.c
@@ -0,0 +1,320 @@
+/*
+ * MSI GT683R led driver
+ *
+ * Copyright (c) 2014 Janne Kanniainen janne.kanniai...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/device.h
+#include linux/hid.h
+#include linux/kernel.h
+#include linux/leds.h
+#include linux/module.h
+
+#include hid-ids.h
+
+#define GT683R_LED_BACK BIT(0)
+#define GT683R_LED_SIDE BIT(1)
+#define GT683R_LED_FRONT BIT(2)
+
+#define GT683R_BUFFER_SIZE 8
+
+/*
+ * GT683R_LED_OFF: all LEDs are off
+ * GT683R_LED_AUDIO: the status of LEDs depends
+ * on sound level
+ * GT683R_LED_BREATHING: LEDs brightness varies
+ * at human breathing rate
+ * GT683R_LED_NORMAL: LEDs are on
+ */
+enum gt683r_led_state {
+ GT683R_LED_OFF = 0,
+ GT683R_LED_AUDIO = 2,
+ GT683R_LED_BREATHING = 3,
+ GT683R_LED_NORMAL = 5
+};
+
+struct gt683r_led {
+ struct hid_device *hdev;
+ struct led_classdev led_dev_back;
+
Re: [PATCH v1 3/3] usb: gadget: NCM: Stop RX TCP Bursts getting dropped.
On 30/05/14 12:25, Jim Baxter wrote: On 29/05/14 20:04, Eric Dumazet wrote: On Thu, 2014-05-29 at 18:12 +0100, Jim Baxter wrote: Note the patch is OK, but changelog a bit misleading ;) Kernel was not running out of memory, because truesize was correct. The problem here is that a frame was consuming more kernel memory than really needed, so chances of hitting socket sk_rcvbuf limit was high. BTW : #define NTB_OUT_SIZE 16384 alloc_skb(size) - kmalloc(16384 + sizeof(struct skb_shared_info)) - roundup() = 32768 So truesize of the skb was infact ~32KB, which is really insane indeed. After your patch, its back to ~2KB Acked-by: Eric Dumazet eduma...@google.com Thank you, I will clarify the description. Jim Hi Eric, Is this commit log more correct? This fixes a problem with dropped packets over 16k CDC-NCM when the connection is being heavily used. The issue was that the extracted frames cloned from the received frame were consuming more memory than necessary due to the truesize being ~32KB instead of ~2KB, this meant there was a high chance of reaching the sk_rcvbuf limit. Acked-by: Eric Dumazet eduma...@google.com Signed-off-by: Jim Baxter jim_bax...@mentor.com Thank you, Jim -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v1 3/3] usb: gadget: NCM: Stop RX TCP Bursts getting dropped.
From: Jim Baxter On 30/05/14 12:25, Jim Baxter wrote: On 29/05/14 20:04, Eric Dumazet wrote: On Thu, 2014-05-29 at 18:12 +0100, Jim Baxter wrote: Note the patch is OK, but changelog a bit misleading ;) Kernel was not running out of memory, because truesize was correct. The problem here is that a frame was consuming more kernel memory than really needed, so chances of hitting socket sk_rcvbuf limit was high. BTW : #define NTB_OUT_SIZE 16384 alloc_skb(size) - kmalloc(16384 + sizeof(struct skb_shared_info)) - roundup() = 32768 So truesize of the skb was infact ~32KB, which is really insane indeed. After your patch, its back to ~2KB Acked-by: Eric Dumazet eduma...@google.com Thank you, I will clarify the description. Jim Hi Eric, Is this commit log more correct? This fixes a problem with dropped packets over 16k CDC-NCM when the connection is being heavily used. The issue was that the extracted frames cloned from the received frame were consuming more memory than necessary due to the truesize being ~32KB instead of ~2KB, this meant there was a high chance of reaching the sk_rcvbuf limit. s/due to/resulting in/ David Acked-by: Eric Dumazet eduma...@google.com Signed-off-by: Jim Baxter jim_bax...@mentor.com Thank you, Jim
Eudyptula Challenge (Task 10)
Greetings Linux Kernel Developers! This is Task 10 of the Eudyptula Challenge. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c: fix coding style
Fix coding style issues detected by checkpatch.pl:
1. do not use assignment in if condition
2. line over 80 characters
Signed-off-by: Wahib Faizi wahibfa...@gmail.com
---
.../usbip/userspace/libsrc/usbip_host_driver.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
index 92caef7..bef08d5 100644
--- a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
+++ b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
@@ -47,7 +47,8 @@ static int32_t read_attr_usbip_status(struct usbip_usb_device
*udev)
snprintf(status_attr_path, SYSFS_PATH_MAX, %s/usbip_status,
udev-path);
- if ((fd = open(status_attr_path, O_RDONLY)) 0) {
+ fd = open(status_attr_path, O_RDONLY);
+ if (fd 0) {
err(error opening attribute %s, status_attr_path);
return -1;
}
@@ -87,8 +88,8 @@ struct usbip_exported_device *usbip_exported_device_new(const
char *sdevpath)
goto err;
/* reallocate buffer to include usb interface data */
- size = sizeof(struct usbip_exported_device) + edev-udev.bNumInterfaces
*
- sizeof(struct usbip_usb_interface);
+ size = sizeof(struct usbip_exported_device) +
+ edev-udev.bNumInterfaces * sizeof(struct usbip_usb_interface);
edev_old = edev;
edev = realloc(edev, size);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c: fix coding style
On Thu, Jun 12, 2014 at 02:35:38PM +0400, Wahib Faizi wrote: Fix coding style issues detected by checkpatch.pl: 1. do not use assignment in if condition 2. line over 80 characters You are doing two different things here, so please break it up into two different patches. Can you please do this and resend? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disable bus's drivers_autoprobe before rootfs has mounted
On Thu, 12 Jun 2014, Peter Chen wrote: Peter, correct me if this is wrong. It sounds like you want to have a way for the user to control which gadget driver gets bound to which UDC driver when everything is compiled into the kernel, nothing is built as a separate module. Is that the basic idea? Yes, I know it can be done by gadget-configfs, but how about the user chooses other gadgets, eg: g_webcam, g_audio? I forget to introduce the background of this topic, I have this issue when I implement gadget bus patch set. (http://www.spinics.net/lists/linux-usb/msg107797.html) The current behaviour for other gadgets is auto-binding, so I want to keep auto-binding at my gadget bus implementation, but manual-binding is also a feature we need to support for other gadgets, so I want auto-binding is the default binding way, and the user can switch the two binding ways, eg, module parameters or sys entry. But if both udc driver and gadget driver are built in, the user can't let manual-binding work during the boot since the device-model will do probe, and do auto-binding. My v1 patch set [3/4] do a tricky way to work around it, I would like to know if it can be supported by device model framework? I think we can keep everything a lot simpler. Let's agree that the old non-composite gadget drivers (like g_ether, g_mass_storage, and so on) should only be used one at a time. That is, there should never be more than one of them compiled into the kernel or loaded as a module, and they shouldn't be used if there is more than one unbound UDC. If a user wants to work with more than one UDC or more than one gadget driver then he should use function drivers with the configfs interface (or functionfs or gadgetfs or whatever). Does that seem reasonable? It doesn't solve your problem so much as declare it an unsupported case, but I don't think there is any reasonable way to solve the problem without using something like configfs. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch net-next 3/5] ipv6: consider net.ipv6.conf.all sysctls when making decisions
David, my words may have been poorly chosen. Last thing I want is to break things... What I meant to say is that this changes the behavior of conf.all.* sysctls from no-op to be part of decision along with interface specific ones. Default settings still work the same way unless conf.all.* was manually modified by user (for example setting conf.all.accept_ra_defrtr=0 did not stop kernel from setting default router before but it would with this change). If this is not desired functionality I'm fine with it not being applied. However if that's the case I suggest removing conf.all.* altogether since it's no-op and pretty confusing for users (myself included). Milos On Wed, Jun 11, 2014 at 6:32 PM, David Miller da...@davemloft.net wrote: From: Milos Vyletel milos.vyle...@gmail.com Date: Tue, 10 Jun 2014 13:49:35 -0400 On Tue, Jun 10, 2014 at 1:13 PM, Stephen Hemminger step...@networkplumber.org wrote: On Tue, 10 Jun 2014 12:19:11 -0400 Milos Vyletel milos.vyle...@gmail.com wrote: As it is right now net.ipv6.conf.all.* are mostly ignored and instead we're only making decisions based on interface specific settings. These settings are coppied from net.ipv6.conf.default and changing either all or default settings have no effect. Although this is the right idea conceptually, it risks creating unhappy users because it changes the semantics of the API. This will probably break somebody's configuration. You're right but in this case I feel we are moving in the right direction. While the behavior will change in some cases this change is only adding well known ipv4 behavior for ipv6 sysctls. In fact documentation briefly mentioned that net.ipv6.conf.all.* should change all the interface-specific settings but that was not the case until now. You can't just break things on people, no matter how much you think the current behavior is poorly designed, inconsistent with other areas of the networking, etc. None of those things matter if you have to break things on people to fix it. I'm not applying this series, sorry. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disable bus's drivers_autoprobe before rootfs has mounted
On Thu, Jun 12, 2014 at 03:02:12PM +0800, Peter Chen wrote: On Wed, Jun 11, 2014 at 02:36:27PM -0500, Felipe Balbi wrote: On Wed, Jun 11, 2014 at 11:29:57AM +0800, Peter Chen wrote: On Tue, Jun 10, 2014 at 11:35:07PM -0500, Felipe Balbi wrote: Hi, On Tue, Jun 10, 2014 at 09:10:00PM -0700, Greg KH wrote: Let's take USB peripheral as an example, there is a device for udc, and a device driver for usb gadget driver, at default, we want the device to be bound to driver automatically, this is what we have done now. But if there are more than one udcs and gadget drivers (eg one B port for mass storage, another B port for usb ethernet), the user may want to have specific binding (eg, udc-0 - mass storage, udc-1 - usb ethernet), so the binding will be established after rootfs has mounted. (This feature is implementing) Then there better be a way to describe this on the kernel command line (i.e. module paramaters), right? Which is a total mess, why not just not bind anything in this case and let the user pick what they want? you can also blacklist all gadget drivers and manually probe them or - get this - you can refrain from using gadget drivers and use libusbg to build the gadget drivers out of raw usb functions, then bind them to the UDC of your liking. I am just worried if we change the behaviour of using gadget driver, can it be accepted by user? If you think it can be accepted if we can have some docs, we can implement manually binding for gadget driver from now on. user shouldn't have to deal with direct module insertion/removal (unless he's a developer and actually *wants* to do that). Docs are already in tree. The entire configfs interface has been documented, it's based on those documents that Matt started writing libusbg. -- balbi Yes, gadget-configfs is a good direction. I would like to know your plan for other gadget drivers (g_mass_storage, g_webcam, etc) they can be built dynamically too. We only provided a version of g_mass_storage in order to avoid regressions. We can't simply remove that driver from the kernel. All functions will be supported by configfs in future, and current driver will be deleted? I don't think we will be able to delete legacy drivers, but they're all supported through configfs. I guess only webcam is missing. - If yes, how to cover the user who still use the old file system? - If no, which binding way for udc and gadget driver will be used? going forward, we want to stick with configfs. -- balbi signature.asc Description: Digital signature
Split patch into 2 logical chunks
Fix coding style issues detected by checkpatch.pl in usbip_host_driver.c. v2: Split patch into logical chunks, as suggested by Greg Kroah-Hartman gre...@linuxfoundation.org [PATCH v2 1/2] Fix coding style issue do not use assignment in if condition detected by checkpatch.pl in usbip_host_driver.c. [PATCH v2 2/2] Fix coding style issue line over 80 characters detected by checkpatch.pl in usbip_host_driver.c. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c: fix coding style
Fix coding style issue do not use assignment in if condition
detected by checkpatch.pl in usbip_host_driver.c.
Signed-off-by: Wahib Faizi wahibfa...@gmail.com
---
.../usbip/userspace/libsrc/usbip_host_driver.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
index 92caef7..32b8f52 100644
--- a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
+++ b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
@@ -47,7 +47,8 @@ static int32_t read_attr_usbip_status(struct usbip_usb_device
*udev)
snprintf(status_attr_path, SYSFS_PATH_MAX, %s/usbip_status,
udev-path);
- if ((fd = open(status_attr_path, O_RDONLY)) 0) {
+ fd = open(status_attr_path, O_RDONLY);
+ if (fd 0) {
err(error opening attribute %s, status_attr_path);
return -1;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c: fix coding style
Fix coding style issue line over 80 characters detected by checkpatch.pl in usbip_host_driver.c. Signed-off-by: Wahib Faizi wahibfa...@gmail.com --- .../usbip/userspace/libsrc/usbip_host_driver.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c index 32b8f52..bef08d5 100644 --- a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c +++ b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c @@ -88,8 +88,8 @@ struct usbip_exported_device *usbip_exported_device_new(const char *sdevpath) goto err; /* reallocate buffer to include usb interface data */ - size = sizeof(struct usbip_exported_device) + edev-udev.bNumInterfaces * - sizeof(struct usbip_usb_interface); + size = sizeof(struct usbip_exported_device) + + edev-udev.bNumInterfaces * sizeof(struct usbip_usb_interface); edev_old = edev; edev = realloc(edev, size); -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c: fix coding style
On Thu, Jun 12, 2014 at 09:32:19PM +0400, Wahib Faizi wrote: Fix coding style issue do not use assignment in if condition detected by checkpatch.pl in usbip_host_driver.c. Signed-off-by: Wahib Faizi wahibfa...@gmail.com Both of these patches have the same Subject: line, which isn't good as it doesn't make much sense. You can also shorten it a lot, for example, this one should be: Subject: staging: usbip: usbip_host_driver.c: fix if assignment style issue Care to redo both of these that way? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c: fix coding style
On Thu, 2014-06-12 at 10:54 -0700, Greg Kroah-Hartman wrote: On Thu, Jun 12, 2014 at 09:32:19PM +0400, Wahib Faizi wrote: Fix coding style issue do not use assignment in if condition detected by checkpatch.pl in usbip_host_driver.c. Signed-off-by: Wahib Faizi wahibfa...@gmail.com Both of these patches have the same Subject: line, which isn't good as it doesn't make much sense. You can also shorten it a lot, for example, this one should be: Subject: staging: usbip: usbip_host_driver.c: fix if assignment style issue True. usbip_host_driver.c doesn't add much though. It could even be something like: staging: usbip: avoid assignment in if -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hardware bug in Intel USB-2 hub?
On Wed, 11 Jun 2014, Oliver Neukum wrote:
Alan,
I don't like this, but it might be enough to simply
revert 0aa2832dd0d9d8609fd8f15139bc7572541a1215.
I am afraid we have to deal with real hardware, not specs.
Toralf and Adam:
Does this patch (for 3.14 or 3.15) fix the problems you observed?
Alan Stern
Index: usb-3.15/drivers/usb/core/hub.c
===
--- usb-3.15.orig/drivers/usb/core/hub.c
+++ usb-3.15/drivers/usb/core/hub.c
@@ -2922,15 +2922,6 @@ static int usb_disable_remote_wakeup(str
USB_CTRL_SET_TIMEOUT);
}
-/* Count of wakeup-enabled devices at or below udev */
-static unsigned wakeup_enabled_descendants(struct usb_device *udev)
-{
- struct usb_hub *hub = usb_hub_to_struct_hub(udev);
-
- return udev-do_remote_wakeup +
- (hub ? hub-wakeup_enabled_descendants : 0);
-}
-
/*
* usb_port_suspend - suspend a usb device's upstream port
* @udev: device that's no longer in active use, not a root hub
@@ -2971,12 +2962,6 @@ static unsigned wakeup_enabled_descendan
* Linux (2.6) currently has NO mechanisms to initiate that: no khubd
* timer, no SRP, no requests through sysfs.
*
- * If Runtime PM isn't enabled or used, non-SuperSpeed devices may not get
- * suspended until their bus goes into global suspend (i.e., the root
- * hub is suspended). Nevertheless, we change @udev-state to
- * USB_STATE_SUSPENDED as this is the device's logical state. The actual
- * upstream port setting is stored in @udev-port_is_suspended.
- *
* Returns 0 on success, else negative errno.
*/
int usb_port_suspend(struct usb_device *udev, pm_message_t msg)
@@ -2985,7 +2970,6 @@ int usb_port_suspend(struct usb_device *
struct usb_port *port_dev = hub-ports[udev-portnum - 1];
int port1 = udev-portnum;
int status;
- boolreally_suspend = true;
/* enable remote wakeup when appropriate; this lets the device
* wake up the upstream hub (including maybe the root hub).
@@ -3024,25 +3008,9 @@ int usb_port_suspend(struct usb_device *
/* see 7.1.7.6 */
if (hub_is_superspeed(hub-hdev))
status = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_U3);
-
- /*
-* For system suspend, we do not need to enable the suspend feature
-* on individual USB-2 ports. The devices will automatically go
-* into suspend a few ms after the root hub stops sending packets.
-* The USB 2.0 spec calls this global suspend.
-*
-* However, many USB hubs have a bug: They don't relay wakeup requests
-* from a downstream port if the port's suspend feature isn't on.
-* Therefore we will turn on the suspend feature if udev or any of its
-* descendants is enabled for remote wakeup.
-*/
- else if (PMSG_IS_AUTO(msg) || wakeup_enabled_descendants(udev) 0)
+ else
status = set_port_feature(hub-hdev, port1,
- USB_PORT_FEAT_SUSPEND);
- else {
- really_suspend = false;
- status = 0;
- }
+ USB_PORT_FEAT_SUSPEND);
if (status) {
dev_dbg(hub-intfdev, can't suspend port %d, status %d\n,
port1, status);
@@ -3067,12 +3035,10 @@ int usb_port_suspend(struct usb_device *
dev_dbg(udev-dev, usb %ssuspend, wakeup %d\n,
(PMSG_IS_AUTO(msg) ? auto- : ),
udev-do_remote_wakeup);
- if (really_suspend) {
- udev-port_is_suspended = 1;
+ udev-port_is_suspended = 1;
- /* device has up to 10 msec to fully suspend */
- msleep(10);
- }
+ /* device has up to 10 msec to fully suspend */
+ msleep(10);
usb_set_device_state(udev, USB_STATE_SUSPENDED);
}
@@ -3343,11 +3309,7 @@ static int hub_suspend(struct usb_interf
unsignedport1;
int status;
- /*
-* Warn if children aren't already suspended.
-* Also, add up the number of wakeup-enabled descendants.
-*/
- hub-wakeup_enabled_descendants = 0;
+ /* Warn if children aren't already suspended */
for (port1 = 1; port1 = hdev-maxchild; port1++) {
struct usb_device *udev;
@@ -3358,9 +3320,6 @@ static int hub_suspend(struct usb_interf
if (PMSG_IS_AUTO(msg))
return -EBUSY;
}
- if (udev)
- hub-wakeup_enabled_descendants +=
- wakeup_enabled_descendants(udev);
}
if (hdev-do_remote_wakeup
Fix subject line
Fix coding style issues detected by checkpatch.pl in usbip_host_driver.c. v3: Shorten subject line, as suggested by Greg Kroah-Hartman gre...@linuxfoundation.org, Joe Perches j...@perches.com v2: Split patch into logical chunks, as suggested by Greg Kroah-Hartman gre...@linuxfoundation.org -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] staging: usbip: usbip_host_driver.c: fix line over 80 characters
Fix coding style issue line over 80 characters detected by checkpatch.pl in usbip_host_driver.c. Signed-off-by: Wahib Faizi wahibfa...@gmail.com --- .../usbip/userspace/libsrc/usbip_host_driver.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c index 32b8f52..bef08d5 100644 --- a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c +++ b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c @@ -88,8 +88,8 @@ struct usbip_exported_device *usbip_exported_device_new(const char *sdevpath) goto err; /* reallocate buffer to include usb interface data */ - size = sizeof(struct usbip_exported_device) + edev-udev.bNumInterfaces * - sizeof(struct usbip_usb_interface); + size = sizeof(struct usbip_exported_device) + + edev-udev.bNumInterfaces * sizeof(struct usbip_usb_interface); edev_old = edev; edev = realloc(edev, size); -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] staging: usbip: usbip_host_driver.c: avoid assignment in if
Fix coding style issue do not use assignment in if condition
detected by checkpatch.pl in usbip_host_driver.c.
Signed-off-by: Wahib Faizi wahibfa...@gmail.com
---
.../usbip/userspace/libsrc/usbip_host_driver.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
index 92caef7..32b8f52 100644
--- a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
+++ b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
@@ -47,7 +47,8 @@ static int32_t read_attr_usbip_status(struct usbip_usb_device
*udev)
snprintf(status_attr_path, SYSFS_PATH_MAX, %s/usbip_status,
udev-path);
- if ((fd = open(status_attr_path, O_RDONLY)) 0) {
+ fd = open(status_attr_path, O_RDONLY);
+ if (fd 0) {
err(error opening attribute %s, status_attr_path);
return -1;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hardware bug in Intel USB-2 hub?
On 06/12/2014 08:11 PM, Alan Stern wrote:
On Wed, 11 Jun 2014, Oliver Neukum wrote:
Alan,
I don't like this, but it might be enough to simply
revert 0aa2832dd0d9d8609fd8f15139bc7572541a1215.
I am afraid we have to deal with real hardware, not specs.
Toralf and Adam:
Does this patch (for 3.14 or 3.15) fix the problems you observed?
At my system (32 bit stable Gentoo at a ThinkkPad T420) it is not fixed
- tested against 3.14.7 and 3.15.0.
Alan Stern
Index: usb-3.15/drivers/usb/core/hub.c
===
--- usb-3.15.orig/drivers/usb/core/hub.c
+++ usb-3.15/drivers/usb/core/hub.c
@@ -2922,15 +2922,6 @@ static int usb_disable_remote_wakeup(str
USB_CTRL_SET_TIMEOUT);
}
-/* Count of wakeup-enabled devices at or below udev */
-static unsigned wakeup_enabled_descendants(struct usb_device *udev)
-{
- struct usb_hub *hub = usb_hub_to_struct_hub(udev);
-
- return udev-do_remote_wakeup +
- (hub ? hub-wakeup_enabled_descendants : 0);
-}
-
/*
* usb_port_suspend - suspend a usb device's upstream port
* @udev: device that's no longer in active use, not a root hub
@@ -2971,12 +2962,6 @@ static unsigned wakeup_enabled_descendan
* Linux (2.6) currently has NO mechanisms to initiate that: no khubd
* timer, no SRP, no requests through sysfs.
*
- * If Runtime PM isn't enabled or used, non-SuperSpeed devices may not get
- * suspended until their bus goes into global suspend (i.e., the root
- * hub is suspended). Nevertheless, we change @udev-state to
- * USB_STATE_SUSPENDED as this is the device's logical state. The actual
- * upstream port setting is stored in @udev-port_is_suspended.
- *
* Returns 0 on success, else negative errno.
*/
int usb_port_suspend(struct usb_device *udev, pm_message_t msg)
@@ -2985,7 +2970,6 @@ int usb_port_suspend(struct usb_device *
struct usb_port *port_dev = hub-ports[udev-portnum - 1];
int port1 = udev-portnum;
int status;
- boolreally_suspend = true;
/* enable remote wakeup when appropriate; this lets the device
* wake up the upstream hub (including maybe the root hub).
@@ -3024,25 +3008,9 @@ int usb_port_suspend(struct usb_device *
/* see 7.1.7.6 */
if (hub_is_superspeed(hub-hdev))
status = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_U3);
-
- /*
- * For system suspend, we do not need to enable the suspend feature
- * on individual USB-2 ports. The devices will automatically go
- * into suspend a few ms after the root hub stops sending packets.
- * The USB 2.0 spec calls this global suspend.
- *
- * However, many USB hubs have a bug: They don't relay wakeup requests
- * from a downstream port if the port's suspend feature isn't on.
- * Therefore we will turn on the suspend feature if udev or any of its
- * descendants is enabled for remote wakeup.
- */
- else if (PMSG_IS_AUTO(msg) || wakeup_enabled_descendants(udev) 0)
+ else
status = set_port_feature(hub-hdev, port1,
- USB_PORT_FEAT_SUSPEND);
- else {
- really_suspend = false;
- status = 0;
- }
+ USB_PORT_FEAT_SUSPEND);
if (status) {
dev_dbg(hub-intfdev, can't suspend port %d, status %d\n,
port1, status);
@@ -3067,12 +3035,10 @@ int usb_port_suspend(struct usb_device *
dev_dbg(udev-dev, usb %ssuspend, wakeup %d\n,
(PMSG_IS_AUTO(msg) ? auto- : ),
udev-do_remote_wakeup);
- if (really_suspend) {
- udev-port_is_suspended = 1;
+ udev-port_is_suspended = 1;
- /* device has up to 10 msec to fully suspend */
- msleep(10);
- }
+ /* device has up to 10 msec to fully suspend */
+ msleep(10);
usb_set_device_state(udev, USB_STATE_SUSPENDED);
}
@@ -3343,11 +3309,7 @@ static int hub_suspend(struct usb_interf
unsignedport1;
int status;
- /*
- * Warn if children aren't already suspended.
- * Also, add up the number of wakeup-enabled descendants.
- */
- hub-wakeup_enabled_descendants = 0;
+ /* Warn if children aren't already suspended */
for (port1 = 1; port1 = hdev-maxchild; port1++) {
struct usb_device *udev;
@@ -3358,9 +3320,6 @@ static int hub_suspend(struct usb_interf
if (PMSG_IS_AUTO(msg))
return -EBUSY;
}
- if (udev)
- hub-wakeup_enabled_descendants +=
-
[PATCH v3 0/2] Fix subject line
Fix coding style issues detected by checkpatch.pl in usbip_host_driver.c. v3: Shorten subject line, as suggested by Greg Kroah-Hartman gre...@linuxfoundation.org, Joe Perches j...@perches.com v2: Split patch into logical chunks, as suggested by Greg Kroah-Hartman gre...@linuxfoundation.org -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/2] staging: usbip: usbip_host_driver.c: fix line over 80 characters
Fix coding style issue line over 80 characters detected by checkpatch.pl in usbip_host_driver.c. Signed-off-by: Wahib Faizi wahibfa...@gmail.com --- .../usbip/userspace/libsrc/usbip_host_driver.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c index 32b8f52..bef08d5 100644 --- a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c +++ b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c @@ -88,8 +88,8 @@ struct usbip_exported_device *usbip_exported_device_new(const char *sdevpath) goto err; /* reallocate buffer to include usb interface data */ - size = sizeof(struct usbip_exported_device) + edev-udev.bNumInterfaces * - sizeof(struct usbip_usb_interface); + size = sizeof(struct usbip_exported_device) + + edev-udev.bNumInterfaces * sizeof(struct usbip_usb_interface); edev_old = edev; edev = realloc(edev, size); -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] staging: usbip: usbip_host_driver.c: avoid assignment in if
Fix coding style issue do not use assignment in if condition
detected by checkpatch.pl in usbip_host_driver.c.
Signed-off-by: Wahib Faizi wahibfa...@gmail.com
---
.../usbip/userspace/libsrc/usbip_host_driver.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
index 92caef7..32b8f52 100644
--- a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
+++ b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
@@ -47,7 +47,8 @@ static int32_t read_attr_usbip_status(struct usbip_usb_device
*udev)
snprintf(status_attr_path, SYSFS_PATH_MAX, %s/usbip_status,
udev-path);
- if ((fd = open(status_attr_path, O_RDONLY)) 0) {
+ fd = open(status_attr_path, O_RDONLY);
+ if (fd 0) {
err(error opening attribute %s, status_attr_path);
return -1;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hardware bug in Intel USB-2 hub?
On Thu, 12 Jun 2014, Toralf Förster wrote: On 06/12/2014 08:11 PM, Alan Stern wrote: On Wed, 11 Jun 2014, Oliver Neukum wrote: Alan, I don't like this, but it might be enough to simply revert 0aa2832dd0d9d8609fd8f15139bc7572541a1215. I am afraid we have to deal with real hardware, not specs. Toralf and Adam: Does this patch (for 3.14 or 3.15) fix the problems you observed? At my system (32 bit stable Gentoo at a ThinkkPad T420) it is not fixed - tested against 3.14.7 and 3.15.0. Strange. In the bugzilla report, you said that reverting commit 0aa2832dd0d9 fixed the problem. Well, that's what this patch does. What does a usbmon trace reveal? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hardware bug in Intel USB-2 hub?
On Thu, Jun 12, 2014 at 02:11:58PM -0400, Alan Stern wrote: On Wed, 11 Jun 2014, Oliver Neukum wrote: Alan, I don't like this, but it might be enough to simply revert 0aa2832dd0d9d8609fd8f15139bc7572541a1215. I am afraid we have to deal with real hardware, not specs. Toralf and Adam: Does this patch (for 3.14 or 3.15) fix the problems you observed? No, neither for 3.14.7 nor for 3.15. USB wakeup signals from hibernation don't work, the power button does. Wakeup from suspend still works (unlike the situation before c1db30a2a79eb59997b13b8cabf2a50bea9f04e1, the commit I bisected the hibernation problem to). -- Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis. WTF is going on with replacing usable interfaces with tabletized ones? -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/2] Fix subject line
On Thu, 2014-06-12 at 23:40 +0400, Wahib Faizi wrote: Fix coding style issues detected by checkpatch.pl in usbip_host_driver.c. Sorry but unless bundled with something more meaningful, I really don't see the value in these changes. I certainly don't want to discourage folks or anything, but just testing other patches is a lot more helpful than this. I haven't followed much about the Eudyptula Challenge, but I hope other assignments are more involved than this. Thanks, Davidlohr -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/2] Fix subject line
On Thu, Jun 12, 2014 at 01:25:34PM -0700, Davidlohr Bueso wrote: On Thu, 2014-06-12 at 23:40 +0400, Wahib Faizi wrote: Fix coding style issues detected by checkpatch.pl in usbip_host_driver.c. Sorry but unless bundled with something more meaningful, I really don't see the value in these changes. I certainly don't want to discourage folks or anything, but just testing other patches is a lot more helpful than this. When the staging code is still needing basic fixes like this, it is meaningful to do patches that clean up stuff like this. That's what the staging tree is for. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5] leds: USB: HID: Add support for MSI GT683R led panels
This driver adds support for USB controlled led panels that exists in
MSI GT683R laptop
Signed-off-by: Janne Kanniainen janne.kanniai...@gmail.com
---
Changes in v2:
- sorted headers to alphabetic order
- using devm_kzalloc
- using BIT(n)
- using usb_control_msg instead of usb_submit_urb
- removing unneeded code
Changes in v3:
- implemented as HID device
- some cleanups and bug fixes
Changes in v4:
- more cleanups
- support for selecting leds
- suppport for selecting status
Changes in v5:
- mode attribute documented under Documentation/ABI
- made array for led_classdev
- led devices uses now recommended naming scheme
.../ABI/testing/sysfs-class-hid-driver-gt683r | 10 +
drivers/hid/Kconfig| 11 +
drivers/hid/Makefile | 1 +
drivers/hid/hid-core.c | 1 +
drivers/hid/hid-gt683r.c | 294 +
drivers/hid/hid-ids.h | 2 +-
drivers/hid/usbhid/hid-quirks.c| 2 +-
7 files changed, 319 insertions(+), 2 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
create mode 100644 drivers/hid/hid-gt683r.c
diff --git a/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
b/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
new file mode 100644
index 000..c4d604e
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
@@ -0,0 +1,10 @@
+What: /sys/class/hidraw/hidraw/device/state
+Date: Jun 2014
+KernelVersion: 3.15
+Contact: Janne Kanniainen janne.kanniai...@gmail.com
+Description:
+ Set the mode of LEDs
+
+ 0 - normal
+ 1 - audio
+ 2 - breathing
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 7af9d0b..d93e0ae 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -261,6 +261,17 @@ config HOLTEK_FF
Say Y here if you have a Holtek On Line Grip based game controller
and want to have force feedback support for it.
+config HID_GT683R
+ tristate MSI GT68xR LED support
+ depends on LEDS_CLASS USB_HID
+ ---help---
+ Say Y here if you want to enable support for the MSI GT68xR LEDS
+
+ This driver support following states normal, breathing and audio.
+ You can also select which leds you want to enable.
+ Currently the following devices are know to be supported:
+ - MSI GT683R
+
config HID_HUION
tristate Huion tablets
depends on USB_HID
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index fc712dd..7129311 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_HID_EMS_FF) += hid-emsff.o
obj-$(CONFIG_HID_ELECOM) += hid-elecom.o
obj-$(CONFIG_HID_ELO) += hid-elo.o
obj-$(CONFIG_HID_EZKEY)+= hid-ezkey.o
+obj-$(CONFIG_HID_GT683R) += hid-gt683r.o
obj-$(CONFIG_HID_GYRATION) += hid-gyration.o
obj-$(CONFIG_HID_HOLTEK) += hid-holtek-kbd.o
obj-$(CONFIG_HID_HOLTEK) += hid-holtek-mouse.o
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index da52279..ec88fdb 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1827,6 +1827,7 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_WIRELESS_OPTICAL_DESKTOP_3_0) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_OFFICE_KB) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MONTEREY, USB_DEVICE_ID_GENIUS_KB29E) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG, USB_DEVICE_ID_NTRIG_TOUCH_SCREEN)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG,
USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_1) },
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG,
USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_2) },
diff --git a/drivers/hid/hid-gt683r.c b/drivers/hid/hid-gt683r.c
new file mode 100644
index 000..6dffb76
--- /dev/null
+++ b/drivers/hid/hid-gt683r.c
@@ -0,0 +1,294 @@
+/*
+ * MSI GT683R led driver
+ *
+ * Copyright (c) 2014 Janne Kanniainen janne.kanniai...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/device.h
+#include linux/hid.h
+#include linux/kernel.h
+#include linux/leds.h
Re: [PATCH v3 0/2] Fix subject line
On Thu, 2014-06-12 at 13:35 -0700, Greg Kroah-Hartman wrote: On Thu, Jun 12, 2014 at 01:25:34PM -0700, Davidlohr Bueso wrote: On Thu, 2014-06-12 at 23:40 +0400, Wahib Faizi wrote: Fix coding style issues detected by checkpatch.pl in usbip_host_driver.c. Sorry but unless bundled with something more meaningful, I really don't see the value in these changes. I certainly don't want to discourage folks or anything, but just testing other patches is a lot more helpful than this. When the staging code is still needing basic fixes like this, it is meaningful to do patches that clean up stuff like this. That's what the staging tree is for. Sure, but making checkpatch happy just to make checkpatch happy isn't a good justification, even for staging. Patch 1 does have value in that it helps avoid silly bugs, but take patch 2/2, we end-up saving just a few spaces... Anyways, just my 2 cents. Thanks, Davidlohr -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: usbip: stub_main.c: Cleaning up missing null-terminate after strncpy call
2014-06-11 7:45 GMT+02:00 Dan Carpenter dan.carpen...@oracle.com: On Tue, Jun 10, 2014 at 10:48:35PM +0200, Rickard Strandqvist wrote: Hi True! Sorry :-( But then one would either operate strcpy outright. Or use strlcpy then the code would be: /* strlcpy() handles not include \0 */ len = strlcpy(busid, buf + 4, BUSID_SIZE); /* busid needs to include \0 termination */ if (!(len BUSID_SIZE)) I don't like this condition. Just say (len = BUSID_SIZE). The comments here are obvious and could be left out. return -EINVAL; I don't have strong feelings about a cleanup patch. But I think that cppcheck is not being very sofisticated here with the NUL termination warning so we should not go out of our way to try to silence the warning. regards, dan carpenter Hi Dan I agree that you should not do patches just to silence a static control program. Concerning (len = BUSID_SIZE) I agree! But I usually try to change as little as possible in the patches I do. But perhaps I should not think that way. Kind regards Rickard Strandqvist -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/2] Fix subject line
On Thu, Jun 12, 2014 at 01:48:38PM -0700, Davidlohr Bueso wrote: On Thu, 2014-06-12 at 13:35 -0700, Greg Kroah-Hartman wrote: On Thu, Jun 12, 2014 at 01:25:34PM -0700, Davidlohr Bueso wrote: On Thu, 2014-06-12 at 23:40 +0400, Wahib Faizi wrote: Fix coding style issues detected by checkpatch.pl in usbip_host_driver.c. Sorry but unless bundled with something more meaningful, I really don't see the value in these changes. I certainly don't want to discourage folks or anything, but just testing other patches is a lot more helpful than this. When the staging code is still needing basic fixes like this, it is meaningful to do patches that clean up stuff like this. That's what the staging tree is for. Sure, but making checkpatch happy just to make checkpatch happy isn't a good justification, even for staging. It actually is. Fighting against checkpatch is a losers battle. Our way more efficient. 1) We do need to fix this checkpatch warning before it moves out of staging. 2) NAKing patches is actually a lot of stress for everyone. It stresses out submitters and drives them away. It stresses out the maintainers because we feel bad. That stress is bad when it is pointless. 3) This patch is ok. 4) If we don't apply this patch then someone else will send the exact same patch or something worse until we apply something. 5) The v3 of this patch takes under 30 seconds to review and apply. 6) Newbies feel happy when their patch gets merged and that is good. The other thing is that if you start asking Is this patch meaningful then it makes applying any patch into a big question about meaning and it tires you out. In staging we have clear rules for when a patch is going to be applied and everyone understands the rules. It means that if Greg is traveling then you know which patches he is going to apply in what order and life is easier because it is more predictable. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: usbip: stub_main.c: Cleaning up missing null-terminate after strncpy call
On Thu, Jun 12, 2014 at 11:09:20PM +0200, Rickard Strandqvist wrote: I agree that you should not do patches just to silence a static control program. Concerning (len = BUSID_SIZE) I agree! But I usually try to change as little as possible in the patches I do. But perhaps I should not think that way. The one thing per patch rule is tricky for a lot of people when they start upstream kernel programming. 1) If you are going to need to backport a patch then write the simplest version you can and do any cleanup in a later patch. 2) Most of these patches will not need to back ported. The one thing is about how you describe the patch. You're allowed to make minor closely related changes. In this case the one thing would be, Clean up string handling in xxx(). The commit message would say: cppcheck has a false positive here. I looked at the code and it's ok, but a bit messy. I have cleaned it up by doing: 1) use strclpy() or whatever 2) cleanup a condition 3) remove obvious comments 4) blah blah blah The new code is simpler and doesn't generate a cppcheck warning. Where checkpatch.pl get into trouble is that they say I am doing one thing and it is to fix everything in filename.c. That's everything and not one thing. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/1] xhci: clear root port wake on bits if controller isn't wake-up capable
When xHCI PCI host is suspended, if do_wakeup is false in xhci_pci_suspend,
xhci_bus_suspend needs to clear all root port wake on bits. Otherwise some Intel
platforms may get a spurious wakeup, even if PCI PME# is disabled.
This patch should be back-ported to kernels as old as 2.6.37, that
contains the commit 9777e3ce907d4cb5a513902a87ecd03b52499569
USB: xHCI: bus power management implementation.
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/host/xhci-hub.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 6231ce6..fb771bd 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -22,6 +22,7 @@
#include linux/slab.h
+#include linux/device.h
#include asm/unaligned.h
#include xhci.h
@@ -1139,7 +1140,9 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
* including the USB 3.0 roothub, but only if CONFIG_PM_RUNTIME
* is enabled, so also enable remote wake here.
*/
- if (hcd-self.root_hub-do_remote_wakeup) {
+ if (hcd-self.root_hub-do_remote_wakeup
+device_may_wakeup(hcd-self.controller)) {
+
if (t1 PORT_CONNECT) {
t2 |= PORT_WKOC_E | PORT_WKDISC_E;
t2 = ~PORT_WKCONN_E;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] xhci-rcar: add firmware for R-Car H2/M2 USB 3.0 host controller
This patch adds a firmware for the USB 3.0 host controller of Renesas
R-Car H2 and M2 SoCs.
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
---
However, the xhci-rcar driver is not merged yet:
http://marc.info/?l=linux-usbm=140187017816231w=2
LICENCE.r8a779x_usb3 | 26 ++
WHENCE|8
r8a779x_usb3_v1.dlmem | Bin 0 - 9452 bytes
3 files changed, 34 insertions(+)
create mode 100644 LICENCE.r8a779x_usb3
create mode 100644 r8a779x_usb3_v1.dlmem
diff --git a/LICENCE.r8a779x_usb3 b/LICENCE.r8a779x_usb3
new file mode 100644
index 000..e2afcc9
--- /dev/null
+++ b/LICENCE.r8a779x_usb3
@@ -0,0 +1,26 @@
+Copyright (c) 2014, Renesas Electronics Corporation
+All rights reserved.
+
+Redistribution and use in binary form, without modification, are permitted
+provided that the following conditions are met:
+
+1. Redistribution in binary form must reproduce the above copyright notice,
+ this list of conditions and the following disclaimer in the documentation
+ and/or other materials provided with the distribution.
+2. The name of Renesas Electronics Corporation may not be used to endorse or
+ promote products derived from this software without specific prior written
+ permission.
+3. Reverse engineering, decompilation, or disassembly of this software is
+ not permitted.
+
+THIS SOFTWARE IS PROVIDED AS IS AND RENESAS ELECTRONICS CORPORATION DISCLAIMS
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, AND
+NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL RENESAS ELECTRONICS
+CORPORATION BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
+OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGE.
diff --git a/WHENCE b/WHENCE
index 6a64fc2..a179448 100644
--- a/WHENCE
+++ b/WHENCE
@@ -2480,3 +2480,11 @@ Licence:
* provided this copyright notice is accompanying it.
--
+
+Driver: xhci-rcar -- Renesas R-Car H2/M2 USB 3.0 host controller driver
+
+File: r8a779x_usb3_v1.dlmem
+
+Licence: Redistributable. See LICENCE.r8a779x_usb3 for details.
+
+--
diff --git a/r8a779x_usb3_v1.dlmem b/r8a779x_usb3_v1.dlmem
new file mode 100644
index
..d094157084173b3c741d3d3d214bdd83f2c48d6b
GIT binary patch
literal 9452
zcmai44O~=J+J9z-JD0DEGZ$tq5~HKdn7P^_tEi-cgshqM3Mwd?%7iTW^K8tsf%}
zN@k|M6%}e4VGlBlDK6#(FA717NCr1io*zgj4mLntf_S0|G5L=zU}*4e!u@c=bn4c
zbDrlpw0*so}qZ!Zx2LJEwR7LL5+Z=2=lWvWjeSA9@gFa?}dyZt$RTWow5S+!gH
zsEK=o5*e%=WE-U2aF*zWX@j8=ZFF%(ftS1eFma=8Fd9NV;iZp9@%HINYt|#nYVG
zNV;6qEt0|gu6WR7ZMCjW=!)KRI$s5Vx96PjVIO1v04*qMtBmY4G@1ic8o*w~%o
z=bTesCzMMOZp$voePRTWQ?8zN=wwPpjQqL)o$xWl%UNGBU(ZEjQ6*C+bk_anwSLb
z4N!WKtZNLm0orOdcYK02P^G5DWNPC$6*p#iAZeB*8p)N2!eorGq+yxW1ysVEv=X
z_TUH=^$~L={j3D-Sd3akNtl!AM|;^RhYHIwRKP^1*_|XqEPX@{?tIy^8Nowsi
z`E|k4VU|?GHC(w8$AK%#z9ioV3e+SSv7buO`7pPev73O1@pW3XgAEO}GE;BtAZ
z1U-UY3;vWo8ABxh%V2TJ@`IjR`B$d;z7Z4Ws_i$IB4oL=PzqILnbr6hHBl9_UPu
zzd403o0LsuAq1HA0rJk#h+-z8axjC^gvR6vFzLZ1RqXn}SU?sw(h|SC?`d9KDL
zJ0dDL71mBI*%NAnQa~`fEvFTy0TI-EBlg=YPN%#TszVxZoyl8v{PPvujMSP
zab$o^-V@L__AB|zU!3xSd*8~SFTtHJUNJc3ACj;(ZZeqD?9pmDg%?0*_maR%6(!D
z3|#u$oh!8kI^{w4#@onmPj}URt8a_rB#~UUvYj!lDLGmrb73cFfYE?dVPYwSpk
z-xfV=Bk)vuNqWo$r;sxU%JK^#s}5DDeePDjMo}v4GP5f1j{aRpOBcf1}EEOFV#Ko
zl%pnCq${WFVog`?jhJlAB`NZ-t$gf2DRadfOovY%(Ahb$|bToT}C@@kXpQo98s=
zsX2n3ai)*8^aL2wgGy9mBru8}6y`4QCozDgJD=OaBP;=#N-cJ}c~8-B3-22;#x
z@U^!dD=Z9xl|On(g+0_iKut@rXlsin$O%t!Z;tZGIiQY5%Z_{uAFLS*79;`CFlG
zPt6(3o@utp2Q-OVIYzNAWsffa6}HEn@=K7e!O(374%k_ic*J0rW;A*9?SfNoPqMZ?
zZ%fc_!wB%ctC#ykU!r8bMzQAt@d{V|PI_nZ=$;K*4EDWx3MRlj_3UeIkp-U_UiM
z7XtGl4dK?-uhHkS(udi0(Gd2%Q1Kv`!mnxBE{)YmF?x5X*nQe;-e9+jW^g^gGV
zihgd-z`p!kmA@MbP6jCZy+_t`Tkz~IUBMrGBQ~eAJp0#a=nbNnwVumXv?5?eJX
zK4fIx#oB6O^5YBBmqqgXmqx536TBFsjKeevLi1fhxLma9ru_*TLGz10;sb%TA
zMcvw}UzMP}ru1=0|70tV(Q#~tsqJ{r7W1wC_DYjeUN}D3CMn^wYD~bMt?2i!`gZs
z^+%MtQ+_Sh)7TDeCyi%5+9}@{jMctR#_8zSBV!)k*xJLQeeg|OIZr;=sFCg64wB~
z9R=%WKvPjtkMvu+X8pJzLF?$MGwqdhQFh8t-Pik=(xclC_Z2~T77x!I0{@MACue{k
z?Vu~1foG+gGiVL@;zpq_{5a=kr=b7O+N#1F5xiewc0OE#hgai#7}(X;58sC=b-xAo
zqoZ=w9ka2Tw{(2g%NAivm*tgH^QW$gFdL)E(h(VWAUq)L;1rEm68qpD)Z3H(kUxv
znbVI`{#5hq4XRbM%(HXJKC58rVP!?=JeZCi1xv%*JrIo89{HLZ%J@R4#4XliZr
z**kKA7VLa(*UWdP?4IoPH^U)ndaF#dVi)m(=oGX=HBoR!aoe(H?w%=N8$U!KMwz7
z%3o$CY7@FVt~rwJ9Bb7u!UQS3{Lq-iA{80cR)2mC{pxE3cj=iVWHXMpDkRCFbF
zxyWc_8!v)8FGDm(2eIem2Sq8-xulvi7WHE@-mV=iG_uq?xF9VXa3-;k`3oZ0y?A
