Re: [RFC v2 2/2] usb: phy: Temporarily hold wakeupsource on charger connect and disconnect events
On Tue, Sep 2, 2014 at 7:54 AM, Felipe Balbi ba...@ti.com wrote: Hi, On Tue, Sep 02, 2014 at 05:19:18PM +0530, Kiran Kumar Raparthy wrote: ... diff --git a/drivers/usb/phy/otg-wakeupsource.c b/drivers/usb/phy/otg-wakeupsource.c index fca2010..70fa05e 100644 --- a/drivers/usb/phy/otg-wakeupsource.c +++ b/drivers/usb/phy/otg-wakeupsource.c @@ -48,7 +48,7 @@ static void otgws_handle_event(struct usb_phy *otgws_xceiv, unsigned long event) case USB_EVENT_NONE: case USB_EVENT_ID: case USB_EVENT_CHARGER: - usb_drop_wsource(otgws_xceiv); + usb_temporary_hold_wsource(otgws_xceiv); looks like this won't work. You're holding the lock even on USB_EVEN_NONE. Why ? It temporarily holds a timed wakeup source on USB disconnect events, to allow the rest of the system time to react to the USB disconnection (dropping host sessions, updating charger status, etc.) prior to re-allowing suspend. Todd -- 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 v8] usb:serial:pl2303: add GPIOs interface on PL2303
On Thu, Sep 4, 2014 at 11:57 PM, Benjamin Henrion zoo...@gmail.com wrote: On Thu, Sep 4, 2014 at 7:35 PM, Wang YanQing udkni...@gmail.com wrote: On Sun, Aug 31, 2014 at 11:24:56PM +0800, Wang YanQing wrote: PL2303 USB Serial devices may has GPIOs, this patch add basic PL2303 gpio support. Known issue: If gpios are in use(export to userspace through sysfs interface, etc), then call pl2303_release(unplug usb-serial convertor, modprobe -r, etc), will cause trouble, so we need to make sure there is no gpio user before call pl2303_release. Signed-off-by: Wang YanQing udkni...@gmail.com --- Note: I sniffed office HXD gpio test program to get gpios control protocol with PL2303 RA, so I only test it with PL2303 RA and HXA, I don't have HXD, but because it is *office* HXD gpio test program, so if it doesn't work with HXD, I will feel surprise. I can confirm your patch is working fine on the HXD: http://www.zoobab.com/pl2303hxd-gpio I am still hunting for a simple C program to test the speed of the GPIOs and sysfs, if you have a good reference. The exercise of the GPIO sysfs interface should be discouraged. I would put emphasis on in-kernel tests and working on a better userspace GPIO interface than the sysfs thing. Yours, Linus Walleij -- 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: ax88179_178a hang over xhci
On Wed, Aug 20, 2014 at 04:12:49PM +0200, Andrea Arcangeli wrote: Hi Sarah, just a short followup on this. I still had 1gbps hangs with the 0b95:1790 ASIX Electronics Corp device using xhci. But it seems now stable for the last 12 hours under heavy load after I removed all powersaving features. ... Unless the hardware is broken there's something wrong in xhci or the usbnet driver that makes it hang with my usual stress test I do to check if the networks is reliable. The device driver is ax88179_178a.c There are still some bugs in the xhci ring handling that can affect the ax88179_178a driver+hardware. I needs the fix to ensure that the ring boundaries are aligned with usb packets, otherwise packets can get lost and the tx side can lock up. It also doesn't work at all with the asmedia xhci silicon. David -- 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: [rfc]your patch to deal with devices that need continous data traffic
On Thu, 2014-09-04 at 13:36 +0200, Johan Hovold wrote:
I got side-tracked with other stuff, but I should be able to submit the
patch this week (just want to look through it once more first).
Not sure the mark-last-busy needs to be moved, though. The device has
already been woken up, and might as well stay unsuspended for a while
longer should further events occur.
Hi,
on second thought I think that your moving of remote_wakeup is not good.
If we'd discard input anyway, we don't need to wake up devices for them.
So here's a version that does it that way.
Regards
Oliver
From 46f2bba084c543922d6c67782d5ba47e663dbc37 Mon Sep 17 00:00:00 2001
From: Oliver Neukum oneu...@suse.de
Date: Wed, 3 Sep 2014 15:26:39 +0200
Subject: [PATCH] usbhid: Johan's patch for devices that need constant polling
Some devices need constant polling or they crash.
So move the start of IO from open() to start()
Signed-off-by: Oliver Neukum oneu...@suse.de
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/usbhid/hid-core.c | 33 +++--
drivers/hid/usbhid/hid-quirks.c | 1 +
include/linux/hid.h | 1 +
4 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 25cd674..b303a62 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -733,6 +733,7 @@
#define USB_DEVICE_ID_PI_ENGINEERING_VEC_USB_FOOTPEDAL 0xff
#define USB_VENDOR_ID_PIXART 0x093a
+#define USB_DEVICE_ID_PIXART_USB_OPTICAL_MOUSE 0x2510
#define USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN 0x8001
#define USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN1 0x8002
#define USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN2 0x8003
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index 79cf503..b214d1e 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -82,7 +82,7 @@ static int hid_start_in(struct hid_device *hid)
struct usbhid_device *usbhid = hid-driver_data;
spin_lock_irqsave(usbhid-lock, flags);
- if (hid-open 0
+ if ((hid-open 0 || hid-quirks HID_QUIRK_ALWAYS_POLL)
!test_bit(HID_DISCONNECTED, usbhid-iofl)
!test_bit(HID_SUSPENDED, usbhid-iofl)
!test_and_set_bit(HID_IN_RUNNING, usbhid-iofl)) {
@@ -290,11 +290,17 @@ static void hid_irq_in(struct urb *urb)
switch (urb-status) {
case 0: /* success */
- usbhid_mark_busy(usbhid);
usbhid-retry_delay = 0;
- hid_input_report(urb-context, HID_INPUT_REPORT,
-urb-transfer_buffer,
-urb-actual_length, 1);
+ /*
+* do not not report unrequested data
+* neither should it count for autosuspend
+*/
+ if (hid-open) {
+ usbhid_mark_busy(usbhid);
+ hid_input_report(urb-context, HID_INPUT_REPORT,
+urb-transfer_buffer,
+urb-actual_length, 1);
+ }
/*
* autosuspend refused while keys are pressed
* because most keyboards don't wake up when
@@ -735,7 +741,8 @@ void usbhid_close(struct hid_device *hid)
if (!--hid-open) {
spin_unlock_irq(usbhid-lock);
hid_cancel_delayed_stuff(usbhid);
- usb_kill_urb(usbhid-urbin);
+ if (!(hid-quirks HID_QUIRK_ALWAYS_POLL))
+ usb_kill_urb(usbhid-urbin);
usbhid-intf-needs_remote_wakeup = 0;
} else {
spin_unlock_irq(usbhid-lock);
@@ -1134,6 +1141,18 @@ static int usbhid_start(struct hid_device *hid)
set_bit(HID_STARTED, usbhid-iofl);
+ if (hid-quirks HID_QUIRK_ALWAYS_POLL) {
+ ret = usb_autopm_get_interface(usbhid-intf);
+ if (ret)
+ goto fail;
+ ret = hid_start_in(hid);
+ if (ret) {
+ dev_err(hid-dev,
+ failed to start in urb: %d\n, ret);
+ }
+ usb_autopm_put_interface(usbhid-intf);
+ }
+
/* Some keyboards don't work until their LEDs have been set.
* Since BIOSes do set the LEDs, it must be safe for any device
* that supports the keyboard boot protocol.
@@ -1166,6 +1185,8 @@ static void usbhid_stop(struct hid_device *hid)
if (WARN_ON(!usbhid))
return;
+ usbhid-intf-needs_remote_wakeup = 0;
+
clear_bit(HID_STARTED, usbhid-iofl);
spin_lock_irq(usbhid-lock); /* Sync with error and led handlers */
set_bit(HID_DISCONNECTED, usbhid-iofl);
diff --git a/drivers/hid/usbhid/hid-quirks.c
Re: [rfc]your patch to deal with devices that need continous data traffic
On Fri, Sep 05, 2014 at 11:05:46AM +0200, Oliver Neukum wrote: On Thu, 2014-09-04 at 13:36 +0200, Johan Hovold wrote: I got side-tracked with other stuff, but I should be able to submit the patch this week (just want to look through it once more first). Not sure the mark-last-busy needs to be moved, though. The device has already been woken up, and might as well stay unsuspended for a while longer should further events occur. Hi, on second thought I think that your moving of remote_wakeup is not good. If we'd discard input anyway, we don't need to wake up devices for them. I'm afraid we have to. The ELAN touchscreen disconnects when an input event occurs while suspended unless remote wakeup is enabled. Johan -- 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: [rfc]your patch to deal with devices that need continous data traffic
On Thu, Sep 04, 2014 at 03:40:03PM +0200, Oliver Neukum wrote: On Thu, 2014-09-04 at 13:36 +0200, Johan Hovold wrote: On Thu, Sep 04, 2014 at 12:44:37PM +0200, Oliver Neukum wrote: Hi, I also got a problem with such a device and I took your patch and applied it to this device. What do you think? The only substantial change I made was not counting unrequested input for autosuspend. Ah, good to know there are more devices that need this quirk. Actually, I'd prefer you to be the only one. ;-) But shared misery is better than single misery. Indeed. :) I got side-tracked with other stuff, but I should be able to submit the patch this week (just want to look through it once more first). Good. Not sure the mark-last-busy needs to be moved, though. The device has already been woken up, and might as well stay unsuspended for a while longer should further events occur. Why? Remote wakeup will be disabled. It would be a waste of power. No, remote wake up is (and has to be) enabled. So we'd only suspend slightly sooner in case there are multiple events, and sometimes only to be immediately woken up again (e.g. if someone is holding a finger against the touch screen). Johan -- 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: [rfc]your patch to deal with devices that need continous data traffic
On Fri, 2014-09-05 at 12:15 +0200, Johan Hovold wrote: On Fri, Sep 05, 2014 at 11:05:46AM +0200, Oliver Neukum wrote: on second thought I think that your moving of remote_wakeup is not good. If we'd discard input anyway, we don't need to wake up devices for them. I'm afraid we have to. The ELAN touchscreen disconnects when an input event occurs while suspended unless remote wakeup is enabled. I see. This device sucks in a terrible way. In principle we'd now need a special flag for port power off. Otherwise we can never send the HC in your laptop to D3cold. Is the small class of devices worth it? Regards Oliver -- 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: gadget serial driver - configuration value
On Thu, Sep 4, 2014 at 7:38 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 4 Sep 2014, Anjana V Kumar wrote:
We see that, the three configurations listed in serial driver (CDC
ACM, CDC OBEX, generic serial) cannot be present together as per the
current implementation. Is there a specific reason why the
configuration values were set as 1, 2 and 3 instead of setting all to
1?
well, setting configuration 0 means that you're not selecting any
configuration. Basically you go back to Addressed state, so you can't
use configuration 0 for anything, really.
Sorry for not being clear, I am not setting the configuration to 0.
The question was, can we set all the three configuration values of CDC
ACM, CDC OBEX, and generic serial to 1?
Was there any specific reason as to why the configuration values were
set as 1,2 and 3. We cannot have all three at the same time according
to the current if, elseif, else implementation,
No two configurations can have the same bConfigurationValue. If the
gadget has three different configs then it must have three different
config values.
I agree that no two configurations can have same bConfigurationValue,
but in this case, the implementation is (drivers/usb/gadget/serial.c)
247 if (use_acm) {
248 serial_config_driver.label = CDC ACM config;
249 serial_config_driver.bConfigurationValue = 2;
250 ...
253 } else if (use_obex) {
254 serial_config_driver.label = CDC OBEX config;
255 serial_config_driver.bConfigurationValue = 3;
256 ...
259 } else {
260 serial_config_driver.label = Generic Serial config;
261 serial_config_driver.bConfigurationValue = 1;
262...
265 }
In this case we cannot have the three configurations together.
Hence I wanted to confirm if there was any other reason as to why
different numbers were assigned.
Alan Stern
--
Anjana
--
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
usb_acpi_set_power_state() and usb_queue_reset_device()
Hi, looking at your patch for resetting HID devices it occurred to me that there's a race between a queued reset and a port power switch. Switching a port's power state implies to a reset for for all interfaces of the device connected to that port. As a reset is quite disruptive it seems to me that no calling off a queued reset is a bug. What do you think? Regards Oliver -- 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 v5 1/2] usb: rename phy to usb_phy in HCD
On Fri, Sep 05, 2014 at 01:42:09AM +0400, Sergei Shtylyov wrote:
From: Antoine Tenart antoine.ten...@free-electrons.com
The USB PHY member of the HCD structure is renamed to 'usb_phy' and
modifications are done in all drivers accessing it.
This is in preparation to adding the generic PHY support.
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
[Sergei: added missing 'drivers/usb/misc/lvstest.c' file, resolved rejects
caused by patch reordering, updated changelog.]
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Alan Stern st...@rowland.harvard.edu
Acked-by: Felipe Balbi ba...@ti.com
---
Changes in version 5:
- imported the patch from Antoine Tenart's series;
- added missing 'drivers/usb/misc/lvstest.c' file;
- resolved rejects caused by patch reordering;
- refreshed patch;
- updated changelog.
drivers/usb/chipidea/host.c |2 +-
drivers/usb/core/hcd.c| 20 ++--
drivers/usb/core/hub.c|8
drivers/usb/host/ehci-fsl.c | 16
drivers/usb/host/ehci-hub.c |2 +-
drivers/usb/host/ehci-msm.c |4 ++--
drivers/usb/host/ehci-tegra.c | 16
drivers/usb/host/ohci-omap.c | 20 ++--
drivers/usb/misc/lvstest.c|8
include/linux/usb/hcd.h |2 +-
10 files changed, 49 insertions(+), 49 deletions(-)
Index: usb/drivers/usb/chipidea/host.c
===
--- usb.orig/drivers/usb/chipidea/host.c
+++ usb/drivers/usb/chipidea/host.c
@@ -59,7 +59,7 @@ static int host_start(struct ci_hdrc *ci
hcd-has_tt = 1;
hcd-power_budget = ci-platdata-power_budget;
- hcd-phy = ci-transceiver;
+ hcd-usb_phy = ci-transceiver;
ehci = hcd_to_ehci(hcd);
ehci-caps = ci-hw_bank.cap;
Index: usb/drivers/usb/core/hcd.c
===
--- usb.orig/drivers/usb/core/hcd.c
+++ usb/drivers/usb/core/hcd.c
@@ -2627,7 +2627,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
int retval;
struct usb_device *rhdev;
- if (IS_ENABLED(CONFIG_USB_PHY) !hcd-phy) {
+ if (IS_ENABLED(CONFIG_USB_PHY) !hcd-usb_phy) {
struct usb_phy *phy = usb_get_phy_dev(hcd-self.controller, 0);
if (IS_ERR(phy)) {
@@ -2640,7 +2640,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
usb_put_phy(phy);
return retval;
}
- hcd-phy = phy;
+ hcd-usb_phy = phy;
hcd-remove_phy = 1;
}
}
@@ -2788,10 +2788,10 @@ err_allocate_root_hub:
err_register_bus:
hcd_buffer_destroy(hcd);
err_remove_phy:
- if (hcd-remove_phy hcd-phy) {
- usb_phy_shutdown(hcd-phy);
- usb_put_phy(hcd-phy);
- hcd-phy = NULL;
+ if (hcd-remove_phy hcd-usb_phy) {
+ usb_phy_shutdown(hcd-usb_phy);
+ usb_put_phy(hcd-usb_phy);
+ hcd-usb_phy = NULL;
}
return retval;
}
@@ -2864,10 +2864,10 @@ void usb_remove_hcd(struct usb_hcd *hcd)
usb_deregister_bus(hcd-self);
hcd_buffer_destroy(hcd);
- if (hcd-remove_phy hcd-phy) {
- usb_phy_shutdown(hcd-phy);
- usb_put_phy(hcd-phy);
- hcd-phy = NULL;
+ if (hcd-remove_phy hcd-usb_phy) {
+ usb_phy_shutdown(hcd-usb_phy);
+ usb_put_phy(hcd-usb_phy);
+ hcd-usb_phy = NULL;
}
usb_put_invalidate_rhdev(hcd);
Index: usb/drivers/usb/core/hub.c
===
--- usb.orig/drivers/usb/core/hub.c
+++ usb/drivers/usb/core/hub.c
@@ -4461,8 +4461,8 @@ hub_port_init (struct usb_hub *hub, stru
if (retval)
goto fail;
- if (hcd-phy !hdev-parent)
- usb_phy_notify_connect(hcd-phy, udev-speed);
+ if (hcd-usb_phy !hdev-parent)
+ usb_phy_notify_connect(hcd-usb_phy, udev-speed);
/*
* Some superspeed devices have finished the link training process
@@ -4617,9 +4617,9 @@ static void hub_port_connect(struct usb_
/* Disconnect any existing devices under this port */
if (udev) {
- if (hcd-phy !hdev-parent
+ if (hcd-usb_phy !hdev-parent
!(portstatus USB_PORT_STAT_CONNECTION))
- usb_phy_notify_disconnect(hcd-phy, udev-speed);
+ usb_phy_notify_disconnect(hcd-usb_phy, udev-speed);
usb_disconnect(port_dev-child);
}
Index: usb/drivers/usb/host/ehci-fsl.c
===
--- usb.orig/drivers/usb/host/ehci-fsl.c
+++ usb/drivers/usb/host/ehci-fsl.c
@@ -136,15 +136,15 @@ static int
Re: [PATCH v3 0/6] usb: host: change TPL support behaviour
On Fri, 5 Sep 2014, Peter Chen wrote: On Thu, Sep 04, 2014 at 11:12:42AM -0400, Alan Stern wrote: On Thu, 4 Sep 2014, Peter Chen wrote: On Wed, Sep 03, 2014 at 09:48:15PM -0400, Alan Stern wrote: On Thu, 4 Sep 2014, Peter Chen wrote: Hi Greg Alan, any comments for this patchset? In patch 2/6, why did you move the !is_targeted(udev) code from usb_enumerate_device_otg() to usb_enumerate_device()? Why not leave the code where it is? TPL support is also needed for embedded host, not only otg host. But usb_enumerate_device_otg() gets called for all types of host, right? At least, it gets called whenever usb_enumerate_device() runs. Yes, it contains #ifdef CONFIG_USB_OTG. But your patch has if (... IS_ENABLED(CONFIG_USB_OTG)), so the behavior is the same. Why move the code if there's no change in behavior? At former code, the tpl support judgement (in function is_targeted) will only be called if CONFIG_USB_OTG is defined, but now, we need tpl support for all targeted hosts. Why we need IS_ENABLED(CONFIG_USB_OTG) as last conditions at if conditions, the reason is the operation which the B-device may want switch to host even if it is not at A's TPL is only for OTG host. The only side effect in is_targeted() is the dev_err() message. Are you saying that this dev_err() message needs to appear even when CONFIG_USB_OTG is disabled? Yes, both embedded host and otg host CAN support TPL, if the embedded host SHOULD support TPL, it should show an err message if the unsupported device is on the port. At OTG EH compliance test plan, (http://www.usb.org/developers/onthego/otgeh_compliance_plan_1_2.pdf) page 124, the chapter 7.3.6 A-UUT Unsupported device Message test, it needs host prints Unsupported Device if the attaching device is not supported (without at Targeted Peripheral List). Okay, then I have no objections to this patch series. 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: usb_acpi_set_power_state() and usb_queue_reset_device()
On Fri, 5 Sep 2014, Oliver Neukum wrote: Hi, looking at your patch for resetting HID devices it occurred to me that there's a race between a queued reset and a port power switch. Switching a port's power state implies to a reset for for all interfaces of the device connected to that port. As a reset is quite disruptive it seems to me that no calling off a queued reset is a bug. What do you think? There shouldn't be a race. We never power-off a port unless the attached device is already runtime suspended. A runtime-suspended device shouldn't have any pending resets. And even if there is a pending reset, all that will happen is the reset will cause the port to power up again, and then the reset will occur. If you think it would help, the runtime suspend code could be changed to prevent suspends if any queued resets are pending. 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
[PATCH 1/1] for HID core dot c
See attachment. Thank you! --HPS commit 862e8673263b82652b5738ccda4f8367959fa234 Author: Hans Petter Selasky h...@selasky.org Date: Fri Sep 5 11:07:15 2014 +0200 Correct argument for Module parameter description. Signed-off-by: Hans Petter Selasky h...@selasky.org diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c index 12b6e67..1956c72 100644 --- a/drivers/hid/hid-core.c +++ b/drivers/hid/hid-core.c @@ -52,7 +52,7 @@ EXPORT_SYMBOL_GPL(hid_debug); static int hid_ignore_special_drivers = 0; module_param_named(ignore_special_drivers, hid_ignore_special_drivers, int, 0600); -MODULE_PARM_DESC(debug, Ignore any special drivers and handle all devices by generic driver); +MODULE_PARM_DESC(ignore_special_drivers, Ignore any special drivers and handle all devices by generic driver); /* * Register a new report for a device.
[PATCH] usb: dwc3: fix TRB completion when multiple TRBs are started
After commit 2ec2a8be (usb: dwc3: gadget:
always enable IOC on bulk/interrupt transfers)
we created a situation where it was possible to
hang a bulk/interrupt endpoint if we had more
than one pending request in our queue and they
were both started with a single Start Transfer
command.
The problems triggers because we had not enabled
Transfer In Progress event for those endpoints
and we were not able to process early giveback
of requests completed without LST bit set.
Fix the problem by finally enabling Xfer In Progress
event for all endpoint types, except control.
Fixes: 2ec2a8be (usb: dwc3: gadget: always
enable IOC on bulk/interrupt transfers)
Cc: sta...@vger.kernel.org # v3.14+
Reported-by: Pratyush Anand pratyush.an...@st.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/gadget.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index e8fb231..490a6ca 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -527,7 +527,7 @@ static int dwc3_gadget_set_ep_config(struct dwc3 *dwc,
struct dwc3_ep *dep,
dep-stream_capable = true;
}
- if (usb_endpoint_xfer_isoc(desc))
+ if (!usb_endpoint_xfer_control(desc))
params.param1 |= DWC3_DEPCFG_XFER_IN_PROGRESS_EN;
/*
@@ -2042,12 +2042,6 @@ static void dwc3_endpoint_interrupt(struct dwc3 *dwc,
dwc3_endpoint_transfer_complete(dwc, dep, event);
break;
case DWC3_DEPEVT_XFERINPROGRESS:
- if (!usb_endpoint_xfer_isoc(dep-endpoint.desc)) {
- dev_dbg(dwc-dev, %s is not an Isochronous endpoint\n,
- dep-name);
- return;
- }
-
dwc3_endpoint_transfer_complete(dwc, dep, event);
break;
case DWC3_DEPEVT_XFERNOTREADY:
--
2.0.1.563.g66f467c
--
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: [RFC v2 2/2] usb: phy: Temporarily hold wakeupsource on charger connect and disconnect events
On Fri, Sep 05, 2014 at 12:40:22AM -0700, Todd Poynor wrote: On Tue, Sep 2, 2014 at 7:54 AM, Felipe Balbi ba...@ti.com wrote: Hi, On Tue, Sep 02, 2014 at 05:19:18PM +0530, Kiran Kumar Raparthy wrote: ... diff --git a/drivers/usb/phy/otg-wakeupsource.c b/drivers/usb/phy/otg-wakeupsource.c index fca2010..70fa05e 100644 --- a/drivers/usb/phy/otg-wakeupsource.c +++ b/drivers/usb/phy/otg-wakeupsource.c @@ -48,7 +48,7 @@ static void otgws_handle_event(struct usb_phy *otgws_xceiv, unsigned long event) case USB_EVENT_NONE: case USB_EVENT_ID: case USB_EVENT_CHARGER: - usb_drop_wsource(otgws_xceiv); + usb_temporary_hold_wsource(otgws_xceiv); looks like this won't work. You're holding the lock even on USB_EVEN_NONE. Why ? It temporarily holds a timed wakeup source on USB disconnect events, to allow the rest of the system time to react to the USB disconnection (dropping host sessions, updating charger status, etc.) prior to re-allowing suspend. alright, please add a note like this to commit log. -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/1] for HID core dot c
Hi, On Fri, Sep 5, 2014 at 4:07 PM, Hans Petter Selasky h...@selasky.org wrote: See attachment. It's preferred that you send your patches in the body of the email. Please read Documentation/SubmittingPatches. Frans -- 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 0/1] for HID core dot c
Hi, Looks like the first argument for MODULE_PARAM_DESC() is incorrect. --HPS commit 862e8673263b82652b5738ccda4f8367959fa234 Author: Hans Petter Selasky h...@selasky.org Date: Fri Sep 5 11:07:15 2014 +0200 Correct argument for Module parameter description. Signed-off-by: Hans Petter Selasky h...@selasky.org diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c index 12b6e67..1956c72 100644 --- a/drivers/hid/hid-core.c +++ b/drivers/hid/hid-core.c @@ -52,7 +52,7 @@ EXPORT_SYMBOL_GPL(hid_debug); static int hid_ignore_special_drivers = 0; module_param_named(ignore_special_drivers, hid_ignore_special_drivers, int, 0600); -MODULE_PARM_DESC(debug, Ignore any special drivers and handle all devices by generic driver); +MODULE_PARM_DESC(ignore_special_drivers, Ignore any special drivers and handle all devices by generic driver); /* * Register a new report for a device. -- 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 1/1] for HID core dot c
On 09/05/14 16:20, Frans Klaver wrote: Hi, On Fri, Sep 5, 2014 at 4:07 PM, Hans Petter Selasky h...@selasky.org wrote: See attachment. It's preferred that you send your patches in the body of the email. Please read Documentation/SubmittingPatches. Frans -- 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 Hi, I'll re-send it. Not sending patches that frequently. Thank you! --HPS -- 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/4] usb: dwc3: move all string helper functions to debug.h
Those functions are only using within debugging
messages, grouping them into debug.h makes sense.
While at that, also add missing multiple inclusion
guard.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/debug.h | 164 +-
drivers/usb/dwc3/ep0.c| 1 +
drivers/usb/dwc3/gadget.c | 89 +
drivers/usb/dwc3/gadget.h | 56
4 files changed, 165 insertions(+), 145 deletions(-)
diff --git a/drivers/usb/dwc3/debug.h b/drivers/usb/dwc3/debug.h
index fceb39d..e35a3d1 100644
--- a/drivers/usb/dwc3/debug.h
+++ b/drivers/usb/dwc3/debug.h
@@ -16,8 +16,170 @@
* GNU General Public License for more details.
*/
+#ifndef __DWC3_DEBUG_H
+#define __DWC3_DEBUG_H
+
#include core.h
+/**
+ * dwc3_gadget_ep_cmd_string - returns endpoint command string
+ * @cmd: command code
+ */
+static inline const char *
+dwc3_gadget_ep_cmd_string(u8 cmd)
+{
+ switch (cmd) {
+ case DWC3_DEPCMD_DEPSTARTCFG:
+ return Start New Configuration;
+ case DWC3_DEPCMD_ENDTRANSFER:
+ return End Transfer;
+ case DWC3_DEPCMD_UPDATETRANSFER:
+ return Update Transfer;
+ case DWC3_DEPCMD_STARTTRANSFER:
+ return Start Transfer;
+ case DWC3_DEPCMD_CLEARSTALL:
+ return Clear Stall;
+ case DWC3_DEPCMD_SETSTALL:
+ return Set Stall;
+ case DWC3_DEPCMD_GETEPSTATE:
+ return Get Endpoint State;
+ case DWC3_DEPCMD_SETTRANSFRESOURCE:
+ return Set Endpoint Transfer Resource;
+ case DWC3_DEPCMD_SETEPCONFIG:
+ return Set Endpoint Configuration;
+ default:
+ return UNKNOWN command;
+ }
+}
+
+/**
+ * dwc3_gadget_generic_cmd_string - returns generic command string
+ * @cmd: command code
+ */
+static inline const char *
+dwc3_gadget_generic_cmd_string(u8 cmd)
+{
+ switch (cmd) {
+ case DWC3_DGCMD_SET_LMP:
+ return Set LMP;
+ case DWC3_DGCMD_SET_PERIODIC_PAR:
+ return Set Periodic Parameters;
+ case DWC3_DGCMD_XMIT_FUNCTION:
+ return Transmit Function Wake Device Notification;
+ case DWC3_DGCMD_SET_SCRATCHPAD_ADDR_LO:
+ return Set Scratchpad Buffer Array Address Lo;
+ case DWC3_DGCMD_SET_SCRATCHPAD_ADDR_HI:
+ return Set Scratchpad Buffer Array Address Hi;
+ case DWC3_DGCMD_SELECTED_FIFO_FLUSH:
+ return Selected FIFO Flush;
+ case DWC3_DGCMD_ALL_FIFO_FLUSH:
+ return All FIFO Flush;
+ case DWC3_DGCMD_SET_ENDPOINT_NRDY:
+ return Set Endpoint NRDY;
+ case DWC3_DGCMD_RUN_SOC_BUS_LOOPBACK:
+ return Run SoC Bus Loopback Test;
+ default:
+ return UNKNOWN;
+ }
+}
+
+/**
+ * dwc3_gadget_link_string - returns link name
+ * @link_state: link state code
+ */
+static inline const char *
+dwc3_gadget_link_string(enum dwc3_link_state link_state)
+{
+ switch (link_state) {
+ case DWC3_LINK_STATE_U0:
+ return U0;
+ case DWC3_LINK_STATE_U1:
+ return U1;
+ case DWC3_LINK_STATE_U2:
+ return U2;
+ case DWC3_LINK_STATE_U3:
+ return U3;
+ case DWC3_LINK_STATE_SS_DIS:
+ return SS.Disabled;
+ case DWC3_LINK_STATE_RX_DET:
+ return RX.Detect;
+ case DWC3_LINK_STATE_SS_INACT:
+ return SS.Inactive;
+ case DWC3_LINK_STATE_POLL:
+ return Polling;
+ case DWC3_LINK_STATE_RECOV:
+ return Recovery;
+ case DWC3_LINK_STATE_HRESET:
+ return Hot Reset;
+ case DWC3_LINK_STATE_CMPLY:
+ return Compliance;
+ case DWC3_LINK_STATE_LPBK:
+ return Loopback;
+ case DWC3_LINK_STATE_RESET:
+ return Reset;
+ case DWC3_LINK_STATE_RESUME:
+ return Resume;
+ default:
+ return UNKNOWN link state\n;
+ }
+}
+
+/**
+ * dwc3_gadget_event_string - returns event name
+ * @event: the event code
+ */
+static inline const char *dwc3_gadget_event_string(u8 event)
+{
+ switch (event) {
+ case DWC3_DEVICE_EVENT_DISCONNECT:
+ return Disconnect;
+ case DWC3_DEVICE_EVENT_RESET:
+ return Reset;
+ case DWC3_DEVICE_EVENT_CONNECT_DONE:
+ return Connection Done;
+ case DWC3_DEVICE_EVENT_LINK_STATUS_CHANGE:
+ return Link Status Change;
+ case DWC3_DEVICE_EVENT_WAKEUP:
+ return WakeUp;
+ case DWC3_DEVICE_EVENT_EOPF:
+ return End-Of-Frame;
+ case DWC3_DEVICE_EVENT_SOF:
+ return Start-Of-Frame;
+ case DWC3_DEVICE_EVENT_ERRATIC_ERROR:
+ return Erratic Error;
+ case DWC3_DEVICE_EVENT_CMD_CMPL:
+ return Command Complete;
+ case
Re: [PATCH v2] usb: dwc3: add tracepoints to aid debugging
On Wed, Sep 03, 2014 at 11:58:26AM +0530, Pratyush Anand wrote: On Wed, Aug 27, 2014 at 05:26:37AM +0800, Felipe Balbi wrote: Hi Felipe, Hi, On Tue, Aug 26, 2014 at 09:21:55PM +, Paul Zimmerman wrote: From: Felipe Balbi [mailto:ba...@ti.com] Sent: Tuesday, August 26, 2014 1:42 PM On Fri, Aug 22, 2014 at 04:56:46PM -0500, Felipe Balbi wrote: ... yeah, it took longer than expected (been busy lately), but here's an example trace with all trace points enabled: # tracer: nop # # entries-in-buffer/entries-written: 1038/1038 #P:1 # # _-= irqs-off # / _= need-resched #| / _---= hardirq/softirq #|| / _--= preempt-depth #||| / delay # TASK-PID CPU# TIMESTAMP FUNCTION # | | | | | idle-0 [000] d.h. 155.653881: dwc3_readl: add fa39c40c value 0004 idle-0 [000] d.h. 155.653903: dwc3_readl: add fa39c408 value 0100 idle-0 [000] d.h. 155.653908: dwc3_writel: addr fa39c408 value 8100 Looks like there is an inconsistency between readl/writel (add vs. addr). eagle eyes :-) Other than that, I really like this. Reviewed-by: Paul Zimmerman pa...@synopsys.com thanks, pushed to my dwc3-tracepoints branch with your Reviewed-by, if nobody makes any other comments until Friday, I'll promote it to testing/next and later to next. If we can also add following two items: -- depcmd: trace depcmd params and cmd in dwc3_send_gadget_ep_cmd -- TRB: trace trb fields, trb address and ep number for which trb has been prepared in dwc3_prepare_one_trb These items were pretty helpful in debugging isoc issues. here's a diff adding those, I'll combine into original patch and resend full series here: diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 0642ff9..f2dbaca 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -279,8 +279,7 @@ int dwc3_send_gadget_generic_command(struct dwc3 *dwc, unsigned cmd, u32 param) u32 timeout = 500; u32 reg; - dev_vdbg(dwc-dev, generic cmd '%s' [%d] param %08x\n, - dwc3_gadget_generic_cmd_string(cmd), cmd, param); + trace_dwc3_gadget_generic_cmd(cmd, param); dwc3_writel(dwc-regs, DWC3_DGCMDPAR, param); dwc3_writel(dwc-regs, DWC3_DGCMD, cmd | DWC3_DGCMD_CMDACT); @@ -311,10 +310,7 @@ int dwc3_send_gadget_ep_cmd(struct dwc3 *dwc, unsigned ep, u32 timeout = 500; u32 reg; - dev_vdbg(dwc-dev, %s: cmd '%s' [%d] params %08x %08x %08x\n, - dep-name, - dwc3_gadget_ep_cmd_string(cmd), cmd, params-param0, - params-param1, params-param2); + trace_dwc3_gadget_ep_cmd(dep, cmd, params); dwc3_writel(dwc-regs, DWC3_DEPCMDPAR0(ep), params-param0); dwc3_writel(dwc-regs, DWC3_DEPCMDPAR1(ep), params-param1); @@ -803,6 +799,8 @@ static void dwc3_prepare_one_trb(struct dwc3_ep *dep, trb-ctrl |= DWC3_TRB_CTRL_SID_SOFN(req-request.stream_id); trb-ctrl |= DWC3_TRB_CTRL_HWO; + + trace_dwc3_prepare_trb(dep, trb); } /* @@ -1760,6 +1758,8 @@ static int __dwc3_cleanup_done_trbs(struct dwc3 *dwc, struct dwc3_ep *dep, unsigned ints_pkt = 0; unsigned inttrb_status; + trace_dwc3_complete_trb(dep, trb); + if ((trb-ctrl DWC3_TRB_CTRL_HWO) status != -ESHUTDOWN) /* * We continue despite the error. There is not much we diff --git a/drivers/usb/dwc3/trace.h b/drivers/usb/dwc3/trace.h index 992cc38..78aff1d 100644 --- a/drivers/usb/dwc3/trace.h +++ b/drivers/usb/dwc3/trace.h @@ -25,6 +25,7 @@ #include linux/tracepoint.h #include asm/byteorder.h #include core.h +#include debug.h DECLARE_EVENT_CLASS(dwc3_log_msg, TP_PROTO(struct va_format *vaf), @@ -130,6 +131,82 @@ DEFINE_EVENT(dwc3_log_request, dwc3_gadget_giveback, TP_ARGS(req) ); +DECLARE_EVENT_CLASS(dwc3_log_generic_cmd, + TP_PROTO(unsigned int cmd, u32 param), + TP_ARGS(cmd, param), + TP_STRUCT__entry( + __field(unsigned int, cmd) + __field(u32, param) + ), + TP_fast_assign( + __entry-cmd = cmd; + __entry-param = param; + ), + TP_printk(cmd '%s' [%d] param %08x\n, + dwc3_gadget_generic_cmd_string(__entry-cmd), + __entry-cmd, __entry-param + ) +); + +DEFINE_EVENT(dwc3_log_generic_cmd, dwc3_gadget_generic_cmd, + TP_PROTO(unsigned int cmd, u32 param), + TP_ARGS(cmd, param) +); +
[PATCH 2/4] usb: dwc3: debug: add dwc3_gadget_event_type_string
this new helper will return a pretty string for
DWC3 Gadget Events.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/debug.h | 34 ++
1 file changed, 34 insertions(+)
diff --git a/drivers/usb/dwc3/debug.h b/drivers/usb/dwc3/debug.h
index e35a3d1..12ff4c9 100644
--- a/drivers/usb/dwc3/debug.h
+++ b/drivers/usb/dwc3/debug.h
@@ -180,6 +180,40 @@ static inline const char *dwc3_ep_event_string(u8 event)
return UNKNOWN;
}
+/**
+ * dwc3_gadget_event_type_string - return event name
+ * @event: the event code
+ */
+static inline const char *dwc3_gadget_event_type_string(u8 event)
+{
+ switch (event) {
+ case DWC3_DEVICE_EVENT_DISCONNECT:
+ return Disconnect;
+ case DWC3_DEVICE_EVENT_RESET:
+ return Reset;
+ case DWC3_DEVICE_EVENT_CONNECT_DONE:
+ return Connect Done;
+ case DWC3_DEVICE_EVENT_LINK_STATUS_CHANGE:
+ return Link Status Change;
+ case DWC3_DEVICE_EVENT_WAKEUP:
+ return Wake-Up;
+ case DWC3_DEVICE_EVENT_HIBER_REQ:
+ return Hibernation;
+ case DWC3_DEVICE_EVENT_EOPF:
+ return End of Periodic Frame;
+ case DWC3_DEVICE_EVENT_SOF:
+ return Start of Frame;
+ case DWC3_DEVICE_EVENT_ERRATIC_ERROR:
+ return Erratic Error;
+ case DWC3_DEVICE_EVENT_CMD_CMPL:
+ return Command Complete;
+ case DWC3_DEVICE_EVENT_OVERFLOW:
+ return Overflow;
+ default:
+ return UNKNOWN;
+ }
+}
+
#ifdef CONFIG_DEBUG_FS
extern int dwc3_debugfs_init(struct dwc3 *);
extern void dwc3_debugfs_exit(struct dwc3 *);
--
2.0.1.563.g66f467c
--
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] USB: storage: use %*ph specifier to dump small buffers
Instead of dereference each byte let's use %*ph specifier in the printk()
calls.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/usb/storage/alauda.c | 11 ---
drivers/usb/storage/sddr09.c | 3 +--
2 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/storage/alauda.c b/drivers/usb/storage/alauda.c
index 6636a58..62c2d9d 100644
--- a/drivers/usb/storage/alauda.c
+++ b/drivers/usb/storage/alauda.c
@@ -415,14 +415,11 @@ static int alauda_init_media(struct us_data *us)
if (alauda_get_media_signature(us, data) != USB_STOR_XFER_GOOD)
return USB_STOR_TRANSPORT_ERROR;
- usb_stor_dbg(us, Media signature: %02X %02X %02X %02X\n,
-data[0], data[1], data[2], data[3]);
+ usb_stor_dbg(us, Media signature: %4ph\n, data);
media_info = alauda_card_find_id(data[1]);
if (media_info == NULL) {
- printk(KERN_WARNING
- alauda_init_media: Unrecognised media signature:
- %02X %02X %02X %02X\n,
- data[0], data[1], data[2], data[3]);
+ pr_warn(alauda_init_media: Unrecognised media signature:
%4ph\n,
+ data);
return USB_STOR_TRANSPORT_ERROR;
}
@@ -513,7 +510,7 @@ static int alauda_check_status2(struct us_data *us)
if (rc != USB_STOR_XFER_GOOD)
return rc;
- usb_stor_dbg(us, %02X %02X %02X\n, data[0], data[1], data[2]);
+ usb_stor_dbg(us, %3ph\n, data);
if (data[0] ALAUDA_STATUS_ERROR)
return USB_STOR_XFER_ERROR;
diff --git a/drivers/usb/storage/sddr09.c b/drivers/usb/storage/sddr09.c
index 38a4504..3847053 100644
--- a/drivers/usb/storage/sddr09.c
+++ b/drivers/usb/storage/sddr09.c
@@ -1155,8 +1155,7 @@ sddr09_get_cardinfo(struct us_data *us, unsigned char
flags) {
return NULL;
}
- sprintf(blurbtxt, sddr09: Found Flash card, ID = %02X %02X %02X %02X,
- deviceID[0], deviceID[1], deviceID[2], deviceID[3]);
+ sprintf(blurbtxt, sddr09: Found Flash card, ID = %4ph, deviceID);
/* Byte 0 is the manufacturer */
sprintf(blurbtxt + strlen(blurbtxt),
--
2.1.0
--
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 3/4] usb: dwc3: gadget: cmd argument should always be unsigned
No functional changes, just making sure we're dealing
with unsigned ints.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/core.h | 2 +-
drivers/usb/dwc3/gadget.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 48fb264..c123745 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -938,7 +938,7 @@ int dwc3_gadget_get_link_state(struct dwc3 *dwc);
int dwc3_gadget_set_link_state(struct dwc3 *dwc, enum dwc3_link_state state);
int dwc3_send_gadget_ep_cmd(struct dwc3 *dwc, unsigned ep,
unsigned cmd, struct dwc3_gadget_ep_cmd_params *params);
-int dwc3_send_gadget_generic_command(struct dwc3 *dwc, int cmd, u32 param);
+int dwc3_send_gadget_generic_command(struct dwc3 *dwc, unsigned cmd, u32
param);
#else
static inline int dwc3_gadget_init(struct dwc3 *dwc)
{ return 0; }
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 77c49a6..096b638 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -273,7 +273,7 @@ void dwc3_gadget_giveback(struct dwc3_ep *dep, struct
dwc3_request *req,
spin_lock(dwc-lock);
}
-int dwc3_send_gadget_generic_command(struct dwc3 *dwc, int cmd, u32 param)
+int dwc3_send_gadget_generic_command(struct dwc3 *dwc, unsigned cmd, u32 param)
{
u32 timeout = 500;
u32 reg;
--
2.0.1.563.g66f467c
--
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 4/4] usb: dwc3: add tracepoints to aid debugging
When we're debugging hard-to-reproduce and time-sensitive
use cases, printk() poses too much overhead. That's when
the kernel's tracing infrastructure comes into play.
This patch implements a few initial tracepoints for the
dwc3 driver. More traces can be added as necessary in order
to ease the task of debugging dwc3.
Reviewed-by: Paul Zimmerman pa...@synopsys.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/Makefile | 5 +-
drivers/usb/dwc3/core.h | 2 +
drivers/usb/dwc3/debug.c | 32 +++
drivers/usb/dwc3/debug.h | 2 +
drivers/usb/dwc3/ep0.c| 64 --
drivers/usb/dwc3/gadget.c | 36
drivers/usb/dwc3/io.h | 30 ++-
drivers/usb/dwc3/trace.c | 19
drivers/usb/dwc3/trace.h | 220 ++
9 files changed, 357 insertions(+), 53 deletions(-)
create mode 100644 drivers/usb/dwc3/debug.c
create mode 100644 drivers/usb/dwc3/trace.c
create mode 100644 drivers/usb/dwc3/trace.h
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 10ac3e7..7793e6c 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -1,9 +1,12 @@
+# define_trace.h needs to know how to find our header
+CFLAGS_trace.o := -I$(src)
+
ccflags-$(CONFIG_USB_DWC3_DEBUG) := -DDEBUG
ccflags-$(CONFIG_USB_DWC3_VERBOSE) += -DVERBOSE_DEBUG
obj-$(CONFIG_USB_DWC3) += dwc3.o
-dwc3-y := core.o
+dwc3-y := core.o debug.o trace.o
ifneq ($(filter y,$(CONFIG_USB_DWC3_HOST) $(CONFIG_USB_DWC3_DUAL_ROLE)),)
dwc3-y += host.o
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index c123745..66f6256 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -33,6 +33,8 @@
#include linux/phy/phy.h
+#define DWC3_MSG_MAX 500
+
/* Global constants */
#define DWC3_EP0_BOUNCE_SIZE 512
#define DWC3_ENDPOINTS_NUM 32
diff --git a/drivers/usb/dwc3/debug.c b/drivers/usb/dwc3/debug.c
new file mode 100644
index 000..0be6885
--- /dev/null
+++ b/drivers/usb/dwc3/debug.c
@@ -0,0 +1,32 @@
+/**
+ * debug.c - DesignWare USB3 DRD Controller Debug/Trace Support
+ *
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Author: Felipe Balbi ba...@ti.com
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include debug.h
+
+void dwc3_trace(void (*trace)(struct va_format *), const char *fmt, ...)
+{
+ struct va_format vaf;
+ va_list args;
+
+ va_start(args, fmt);
+ vaf.fmt = fmt;
+ vaf.va = args;
+
+ trace(vaf);
+
+ va_end(args);
+}
diff --git a/drivers/usb/dwc3/debug.h b/drivers/usb/dwc3/debug.h
index 12ff4c9..07fbc2d 100644
--- a/drivers/usb/dwc3/debug.h
+++ b/drivers/usb/dwc3/debug.h
@@ -214,6 +214,8 @@ static inline const char *dwc3_gadget_event_type_string(u8
event)
}
}
+void dwc3_trace(void (*trace)(struct va_format *), const char *fmt, ...);
+
#ifdef CONFIG_DEBUG_FS
extern int dwc3_debugfs_init(struct dwc3 *);
extern void dwc3_debugfs_exit(struct dwc3 *);
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 994e1d8..b359387 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -66,7 +66,7 @@ static int dwc3_ep0_start_trans(struct dwc3 *dwc, u8 epnum,
dma_addr_t buf_dma,
dep = dwc-eps[epnum];
if (dep-flags DWC3_EP_BUSY) {
- dev_vdbg(dwc-dev, %s: still busy\n, dep-name);
+ dwc3_trace(trace_dwc3_ep0, %s still busy, dep-name);
return 0;
}
@@ -89,7 +89,8 @@ static int dwc3_ep0_start_trans(struct dwc3 *dwc, u8 epnum,
dma_addr_t buf_dma,
ret = dwc3_send_gadget_ep_cmd(dwc, dep-number,
DWC3_DEPCMD_STARTTRANSFER, params);
if (ret 0) {
- dev_dbg(dwc-dev, failed to send STARTTRANSFER command\n);
+ dwc3_trace(trace_dwc3_ep0, %s STARTTRANSFER failed,
+ dep-name);
return ret;
}
@@ -154,7 +155,8 @@ static int __dwc3_gadget_ep0_queue(struct dwc3_ep *dep,
if (dwc-ep0state == EP0_STATUS_PHASE)
__dwc3_ep0_do_control_status(dwc, dwc-eps[direction]);
else
- dev_dbg(dwc-dev, too early for delayed status\n);
+ dwc3_trace(trace_dwc3_ep0,
+ too early for delayed status);
return 0;
}
@@
[PATCH v3 1/3] mfd: add support for Diolan DLN-2 devices
This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO
Master Adapter DLN-2. Details about the device can be found here:
https://www.diolan.com/i2c/i2c_interface.html.
Information about the USB protocol can be found in the Programmer's
Reference Manual [1], see section 1.7.
Because the hardware has a single transmit endpoint and a single
receive endpoint the communication between the various DLN2 drivers
and the hardware will be muxed/demuxed by this driver.
Each DLN2 module will be identified by the handle field within the DLN2
message header. If a DLN2 module issues multiple commands in parallel
they will be identified by the echo counter field in the message header.
The DLN2 modules can use the dln2_transfer() function to issue a
command and wait for its response. They can also register a callback
that is going to be called when a specific event id is generated by
the device (e.g. GPIO interrupts). The device uses handle 0 for
sending events.
[1] https://www.diolan.com/downloads/dln-api-manual.pdf
Signed-off-by: Octavian Purdila octavian.purd...@intel.com
---
drivers/mfd/Kconfig | 9 +
drivers/mfd/Makefile | 1 +
drivers/mfd/dln2.c | 653 +++
include/linux/mfd/dln2.h | 61 +
4 files changed, 724 insertions(+)
create mode 100644 drivers/mfd/dln2.c
create mode 100644 include/linux/mfd/dln2.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index de5abf2..7bcf895 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -183,6 +183,15 @@ config MFD_DA9063
Additional drivers must be enabled in order to use the functionality
of the device.
+config MFD_DLN2
+ tristate Diolan DLN2 support
+ select MFD_CORE
+ depends on USB
+ help
+ This adds support for Diolan USB-I2C/SPI/GPIO Master Adapter DLN-2.
+ Additional drivers must be enabled in order to use the functionality
+ of the device.
+
config MFD_MC13XXX
tristate
depends on (SPI_MASTER || I2C)
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index f001487..591988d 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -169,6 +169,7 @@ obj-$(CONFIG_MFD_AS3711)+= as3711.o
obj-$(CONFIG_MFD_AS3722) += as3722.o
obj-$(CONFIG_MFD_STW481X) += stw481x.o
obj-$(CONFIG_MFD_IPAQ_MICRO) += ipaq-micro.o
+obj-$(CONFIG_MFD_DLN2) += dln2.o
intel-soc-pmic-objs:= intel_soc_pmic_core.o intel_soc_pmic_crc.o
obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
diff --git a/drivers/mfd/dln2.c b/drivers/mfd/dln2.c
new file mode 100644
index 000..81ff58e
--- /dev/null
+++ b/drivers/mfd/dln2.c
@@ -0,0 +1,653 @@
+/*
+ * Driver for the Diolan DLN-2 USB adapter
+ *
+ * Copyright (c) 2014 Intel Corporation
+ *
+ * Derived from:
+ * i2c-diolan-u2c.c
+ * Copyright (c) 2010-2011 Ericsson AB
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2.
+ */
+
+#include linux/kernel.h
+#include linux/errno.h
+#include linux/module.h
+#include linux/types.h
+#include linux/slab.h
+#include linux/usb.h
+#include linux/i2c.h
+#include linux/mutex.h
+#include linux/platform_device.h
+#include linux/mfd/core.h
+#include linux/mfd/dln2.h
+
+#define DRIVER_NAMEusb-dln2
+
+struct dln2_header {
+ __le16 size;
+ __le16 id;
+ __le16 echo;
+ __le16 handle;
+} __packed;
+
+struct dln2_response {
+ struct dln2_header hdr;
+ __le16 result;
+} __packed;
+
+#define DLN2_GENERIC_MODULE_ID 0x00
+#define DLN2_GENERIC_CMD(cmd) DLN2_CMD(cmd, DLN2_GENERIC_MODULE_ID)
+#define CMD_GET_DEVICE_VER DLN2_GENERIC_CMD(0x30)
+#define CMD_GET_DEVICE_SN DLN2_GENERIC_CMD(0x31)
+
+#define DLN2_HW_ID 0x200
+#define DLN2_USB_TIMEOUT 200 /* in ms */
+#define DLN2_MAX_RX_SLOTS 16
+#define DLN2_MAX_MODULES 5
+#define DLN2_MAX_URBS 16
+
+#define DLN2_HANDLE_GPIO_EVENT 0
+#define DLN2_HANDLE_CTRL 1
+#define DLN2_HANDLE_GPIO 2
+#define DLN2_HANDLE_I2C3
+
+/* Receive context used between the receive demultiplexer and the
+ * transfer routine. While sending a request the transfer routine
+ * will look for a free receive context and use it to wait for a
+ * response and to receive the URB and thus the response data. */
+struct dln2_rx_context {
+ struct completion done;
+ struct urb *urb;
+ bool connected;
+};
+
+/* Receive contexts for a particular DLN2 module (i2c, gpio, etc.). We
+ * use the handle header field to indentify the module in
+ * dln2_dev.mod_rx_slots and then the echo header field to index the
+ * slots field and find the receive context for a particular
+ * request. */
+struct
[PATCH v3 0/3] mfd: add support for Diolan DLN-2
This patch series adds support for Diolan USB-I2C/GPIO Master Adapter DLN-2. Details about device can be found here: https://www.diolan.com/i2c/i2c_interface.html. Changes since v2: * MFD driver: fix a few obsolete comments for the DLN2 I/O API * GPIO driver: retry the chip remove call if -EBUSY is returned, see the comments in dln2_do_remove for more details; also removed a redundant !dln2-pdev check from dln2_irq_event - we do it in dln2_transfer already * I2C driver: add I2C_FUNC_SMBUS_I2C_BLOCK support Changes since v1: * rewrite the drivers as an MFD * rewrite the irq part of the gpio driver to use GPIOLIB_IRQCHIP * cleanup the I/O interface * various fixes and cleanps: check received message sizes before parsing, error handling for usb_submit_urb, check URB status, use single bit manipulation functions instead of bitmap_*, move GFP_KERNEL URB submit away from under lock Daniel Baluta (1): gpio: add support for the Diolan DLN-2 USB GPIO driver Laurentiu Palcu (1): i2c: add support for Diolan DLN-2 USB-I2C adapter Octavian Purdila (1): mfd: add support for Diolan DLN-2 devices drivers/gpio/Kconfig | 12 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-dln2.c | 537 ++ drivers/i2c/busses/Kconfig| 10 + drivers/i2c/busses/Makefile | 1 + drivers/i2c/busses/i2c-dln2.c | 301 +++ drivers/mfd/Kconfig | 9 + drivers/mfd/Makefile | 1 + drivers/mfd/dln2.c| 653 ++ include/linux/mfd/dln2.h | 61 10 files changed, 1586 insertions(+) create mode 100644 drivers/gpio/gpio-dln2.c create mode 100644 drivers/i2c/busses/i2c-dln2.c create mode 100644 drivers/mfd/dln2.c create mode 100644 include/linux/mfd/dln2.h -- 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 v3 3/3] gpio: add support for the Diolan DLN-2 USB GPIO driver
From: Daniel Baluta daniel.bal...@intel.com
This patch adds GPIO and IRQ support for the Diolan DLN-2 GPIO module.
Information about the USB protocol interface can be found in the
Programmer's Reference Manual [1], see section 2.9 for the GPIO
module commands and responses.
[1] https://www.diolan.com/downloads/dln-api-manual.pdf
Signed-off-by: Daniel Baluta daniel.bal...@intel.com
Signed-off-by: Octavian Purdila octavian.purd...@intel.com
---
drivers/gpio/Kconfig | 12 ++
drivers/gpio/Makefile| 1 +
drivers/gpio/gpio-dln2.c | 537 +++
3 files changed, 550 insertions(+)
create mode 100644 drivers/gpio/gpio-dln2.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 9de1515..6a9e352 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -897,4 +897,16 @@ config GPIO_VIPERBOARD
River Tech's viperboard.h for detailed meaning
of the module parameters.
+config GPIO_DLN2
+ tristate Diolan DLN2 GPIO support
+ depends on USB MFD_DLN2
+ select GPIOLIB_IRQCHIP
+
+ help
+ Select this option to enable GPIO driver for the Diolan DLN2
+ board.
+
+ This driver can also be built as a module. If so, the module
+ will be called gpio-dln2.
+
endif
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 5d024e3..eaa97a0 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_GPIO_CRYSTAL_COVE) += gpio-crystalcove.o
obj-$(CONFIG_GPIO_DA9052) += gpio-da9052.o
obj-$(CONFIG_GPIO_DA9055) += gpio-da9055.o
obj-$(CONFIG_GPIO_DAVINCI) += gpio-davinci.o
+obj-$(CONFIG_GPIO_DLN2)+= gpio-dln2.o
obj-$(CONFIG_GPIO_DWAPB) += gpio-dwapb.o
obj-$(CONFIG_GPIO_EM) += gpio-em.o
obj-$(CONFIG_GPIO_EP93XX) += gpio-ep93xx.o
diff --git a/drivers/gpio/gpio-dln2.c b/drivers/gpio/gpio-dln2.c
new file mode 100644
index 000..f8c0bcb
--- /dev/null
+++ b/drivers/gpio/gpio-dln2.c
@@ -0,0 +1,537 @@
+/*
+ * Driver for the Diolan DLN-2 USB-GPIO adapter
+ *
+ * Copyright (c) 2014 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2.
+ */
+
+#include linux/kernel.h
+#include linux/errno.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/types.h
+#include linux/mutex.h
+#include linux/irqdomain.h
+#include linux/irq.h
+#include linux/irqchip/chained_irq.h
+#include linux/usb.h
+#include linux/gpio.h
+#include linux/gpio/driver.h
+#include linux/ptrace.h
+#include linux/wait.h
+#include linux/platform_device.h
+#include linux/mfd/dln2.h
+
+#define DRIVER_NAME dln2-gpio
+
+#define DLN2_GPIO_ID 0x01
+
+#define DLN2_GPIO_GET_PORT_COUNT DLN2_CMD(0x00, DLN2_GPIO_ID)
+#define DLN2_GPIO_GET_PIN_COUNTDLN2_CMD(0x01, DLN2_GPIO_ID)
+#define DLN2_GPIO_SET_DEBOUNCE DLN2_CMD(0x04, DLN2_GPIO_ID)
+#define DLN2_GPIO_GET_DEBOUNCE DLN2_CMD(0x05, DLN2_GPIO_ID)
+#define DLN2_GPIO_PORT_GET_VAL DLN2_CMD(0x06, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_GET_VAL DLN2_CMD(0x0B, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_SET_OUT_VAL DLN2_CMD(0x0C, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_GET_OUT_VAL DLN2_CMD(0x0D, DLN2_GPIO_ID)
+#define DLN2_GPIO_CONDITION_MET_EV DLN2_CMD(0x0F, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_ENABLE DLN2_CMD(0x10, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_DISABLE DLN2_CMD(0x11, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_SET_DIRECTIONDLN2_CMD(0x13, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_GET_DIRECTIONDLN2_CMD(0x14, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_SET_EVENT_CFGDLN2_CMD(0x1E, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_GET_EVENT_CFGDLN2_CMD(0x1F, DLN2_GPIO_ID)
+
+#define DLN2_GPIO_EVENT_NONE 0
+#define DLN2_GPIO_EVENT_CHANGE 1
+#define DLN2_GPIO_EVENT_LVL_HIGH 2
+#define DLN2_GPIO_EVENT_LVL_LOW3
+#define DLN2_GPIO_EVENT_CHANGE_RISING 0x11
+#define DLN2_GPIO_EVENT_CHANGE_FALLING 0x21
+#define DLN2_GPIO_EVENT_MASK 0x0F
+
+#define DLN2_GPIO_MAX_PINS 32
+
+struct dln2_irq_work {
+ struct work_struct work;
+ struct dln2_gpio *dln2;
+ int pin, type;
+};
+
+struct dln2_remove_work {
+ struct delayed_work work;
+ struct dln2_gpio *dln2;
+};
+
+struct dln2_gpio {
+ struct platform_device *pdev;
+ struct gpio_chip gpio;
+
+ DECLARE_BITMAP(irqs_masked, DLN2_GPIO_MAX_PINS);
+ DECLARE_BITMAP(irqs_enabled, DLN2_GPIO_MAX_PINS);
+ DECLARE_BITMAP(irqs_pending, DLN2_GPIO_MAX_PINS);
+ struct dln2_irq_work irq_work[DLN2_GPIO_MAX_PINS];
+ struct dln2_remove_work remove_work;
+};
+
+struct dln2_gpio_pin {
+ __le16 pin;
+} __packed;
+
+struct dln2_gpio_pin_val {
+ __le16 pin;
+ u8 value;
+} __packed;
+
+static int
[PATCH v3 2/3] i2c: add support for Diolan DLN-2 USB-I2C adapter
From: Laurentiu Palcu laurentiu.pa...@intel.com
This patch adds support for the Diolan DLN-2 I2C master module. Due
to hardware limitations it does not support SMBUS quick commands.
Information about the USB protocol interface can be found in the
Programmer's Reference Manual [1], see section 6.2.2 for the I2C
master module commands and responses.
[1] https://www.diolan.com/downloads/dln-api-manual.pdf
Signed-off-by: Laurentiu Palcu laurentiu.pa...@intel.com
Signed-off-by: Octavian Purdila octavian.purd...@intel.com
---
drivers/i2c/busses/Kconfig| 10 ++
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-dln2.c | 301 ++
3 files changed, 312 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-dln2.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 2ac87fa..4873161 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -1021,4 +1021,14 @@ config SCx200_ACB
This support is also available as a module. If so, the module
will be called scx200_acb.
+config I2C_DLN2
+ tristate Diolan DLN-2 USB I2C adapter
+ depends on USB MFD_DLN2
+ help
+ If you say yes to this option, support will be included for Diolan
+ DLN2, a USB to I2C interface.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-dln2.
+
endmenu
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 49bf07e..3118fea 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -100,5 +100,6 @@ obj-$(CONFIG_I2C_ELEKTOR) += i2c-elektor.o
obj-$(CONFIG_I2C_PCA_ISA) += i2c-pca-isa.o
obj-$(CONFIG_I2C_SIBYTE) += i2c-sibyte.o
obj-$(CONFIG_SCx200_ACB) += scx200_acb.o
+obj-$(CONFIG_I2C_DLN2) += i2c-dln2.o
ccflags-$(CONFIG_I2C_DEBUG_BUS) := -DDEBUG
diff --git a/drivers/i2c/busses/i2c-dln2.c b/drivers/i2c/busses/i2c-dln2.c
new file mode 100644
index 000..93e85ff
--- /dev/null
+++ b/drivers/i2c/busses/i2c-dln2.c
@@ -0,0 +1,301 @@
+/*
+ * Driver for the Diolan DLN-2 USB-I2C adapter
+ *
+ * Copyright (c) 2014 Intel Corporation
+ *
+ * Derived from:
+ * i2c-diolan-u2c.c
+ * Copyright (c) 2010-2011 Ericsson AB
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2.
+ */
+
+#include linux/kernel.h
+#include linux/errno.h
+#include linux/module.h
+#include linux/types.h
+#include linux/slab.h
+#include linux/i2c.h
+
+#include linux/platform_device.h
+#include linux/mfd/dln2.h
+
+#define DRIVER_NAMEdln2-i2c
+
+#define DLN2_I2C_MODULE_ID 0x03
+#define DLN2_I2C_CMD(cmd) DLN2_CMD(cmd, DLN2_I2C_MODULE_ID)
+
+/* I2C commands */
+#define DLN2_I2C_GET_PORT_COUNTDLN2_I2C_CMD(0x00)
+#define DLN2_I2C_ENABLEDLN2_I2C_CMD(0x01)
+#define DLN2_I2C_DISABLE DLN2_I2C_CMD(0x02)
+#define DLN2_I2C_IS_ENABLEDDLN2_I2C_CMD(0x03)
+#define DLN2_I2C_SET_FREQUENCY DLN2_I2C_CMD(0x04)
+#define DLN2_I2C_GET_FREQUENCY DLN2_I2C_CMD(0x05)
+#define DLN2_I2C_WRITE DLN2_I2C_CMD(0x06)
+#define DLN2_I2C_READ DLN2_I2C_CMD(0x07)
+#define DLN2_I2C_SCAN_DEVICES DLN2_I2C_CMD(0x08)
+#define DLN2_I2C_PULLUP_ENABLE DLN2_I2C_CMD(0x09)
+#define DLN2_I2C_PULLUP_DISABLEDLN2_I2C_CMD(0x0A)
+#define DLN2_I2C_PULLUP_IS_ENABLED DLN2_I2C_CMD(0x0B)
+#define DLN2_I2C_TRANSFER DLN2_I2C_CMD(0x0C)
+#define DLN2_I2C_SET_MAX_REPLY_COUNT DLN2_I2C_CMD(0x0D)
+#define DLN2_I2C_GET_MAX_REPLY_COUNT DLN2_I2C_CMD(0x0E)
+#define DLN2_I2C_GET_MIN_FREQUENCY DLN2_I2C_CMD(0x40)
+#define DLN2_I2C_GET_MAX_FREQUENCY DLN2_I2C_CMD(0x41)
+
+#define DLN2_I2C_FREQ_FAST 40
+#define DLN2_I2C_FREQ_STD 10
+
+#define DLN2_I2C_MAX_XFER_SIZE 256
+
+struct dln2_i2c {
+ struct platform_device *pdev;
+ struct i2c_adapter adapter;
+};
+
+static uint frequency = DLN2_I2C_FREQ_STD; /* I2C clock frequency in Hz */
+
+module_param(frequency, uint, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(frequency, I2C clock frequency in hertz);
+
+static int dln2_i2c_set_state(struct dln2_i2c *dln2, u8 state)
+{
+ int ret;
+ u8 port = 0;
+
+ ret = dln2_transfer(dln2-pdev,
+ state ? DLN2_I2C_ENABLE : DLN2_I2C_DISABLE,
+ port, sizeof(port), NULL, NULL);
+
+ if (ret 0)
+ return ret;
+
+ return 0;
+}
+
+#define dln2_i2c_enable(dln2) dln2_i2c_set_state(dln2, 1)
+#define dln2_i2c_disable(dln2) dln2_i2c_set_state(dln2, 0)
+
+static int dln2_i2c_set_frequency(struct dln2_i2c *dln2, u32 freq)
+{
+ int ret;
+ struct tx_data {
+ u8 port;
+ __le32 freq;
[PATCH v6 3/3] MAINTAINERS: Add dwc3-st.c file to ARCH/STI architecture
This patch adds the new dwc3-st.c glue driver found on STMicroelectronics stih407 consumer electronics SoC's into the STI arch section of the maintainers file. Signed-off-by: Peter Griffin peter.grif...@linaro.org Acked-by: Lee Jones lee.jo...@linaro.org --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index cf24bb5..55381955 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1398,6 +1398,7 @@ F:drivers/media/rc/st_rc.c F: drivers/i2c/busses/i2c-st.c F: drivers/tty/serial/st-asc.c F: drivers/mmc/host/sdhci-st.c +F: drivers/usb/dwc3/dwc3-st.c ARM/TECHNOLOGIC SYSTEMS TS7250 MACHINE SUPPORT M: Lennert Buytenhek ker...@wantstofly.org -- 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 v6 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
This patch adds the ST glue logic to manage the DWC3 HC
on STiH407 SoC family. It manages the powerdown signal,
and configures the internal glue logic and syscfg registers.
Signed-off-by: Giuseppe Cavallaro peppe.cavall...@st.com
Signed-off-by: Peter Griffin peter.grif...@linaro.org
Acked-by: Lee Jones lee.jo...@linaro.org
---
drivers/usb/dwc3/Kconfig | 9 ++
drivers/usb/dwc3/Makefile | 1 +
drivers/usb/dwc3/dwc3-st.c | 377 +
3 files changed, 387 insertions(+)
create mode 100644 drivers/usb/dwc3/dwc3-st.c
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 785510a..5238251 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -80,6 +80,15 @@ config USB_DWC3_KEYSTONE
Support of USB2/3 functionality in TI Keystone2 platforms.
Say 'Y' or 'M' here if you have one such device
+config USB_DWC3_ST
+ tristate STMicroelectronics Platforms
+ depends on ARCH_STI OF
+ default USB_DWC3
+ help
+ STMicroelectronics SoCs with one DesignWare Core USB3 IP
+ inside (i.e. STiH407).
+ Say 'Y' or 'M' if you have one such device.
+
comment Debugging features
config USB_DWC3_DEBUG
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 10ac3e7..11c9f54 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -33,3 +33,4 @@ obj-$(CONFIG_USB_DWC3_OMAP) += dwc3-omap.o
obj-$(CONFIG_USB_DWC3_EXYNOS) += dwc3-exynos.o
obj-$(CONFIG_USB_DWC3_PCI) += dwc3-pci.o
obj-$(CONFIG_USB_DWC3_KEYSTONE)+= dwc3-keystone.o
+obj-$(CONFIG_USB_DWC3_ST) += dwc3-st.o
diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c
new file mode 100644
index 000..c4c1717
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-st.c
@@ -0,0 +1,377 @@
+/**
+ * dwc3-st.c Support for dwc3 platform devices on ST Microelectronics platforms
+ *
+ * This is a small driver for the dwc3 to provide the glue logic
+ * to configure the controller. Tested on STi platforms.
+ *
+ * Copyright (C) 2014 Stmicroelectronics
+ *
+ * Author: Giuseppe Cavallaro peppe.cavall...@st.com
+ * Contributors: Aymen Bouattay aymen.bouat...@st.com
+ * Peter Griffin peter.grif...@linaro.org
+ *
+ * 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.
+ *
+ * Inspired by dwc3-omap.c and dwc3-exynos.c.
+ */
+
+#include linux/delay.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/ioport.h
+#include linux/kernel.h
+#include linux/mfd/syscon.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/regmap.h
+#include linux/reset.h
+#include linux/usb/of.h
+
+#include core.h
+#include io.h
+
+/* glue registers */
+#define CLKRST_CTRL0x00
+#define AUX_CLK_EN BIT(0)
+#define SW_PIPEW_RESET_N BIT(4)
+#define EXT_CFG_RESET_NBIT(8)
+/*
+ * 1'b0 : The host controller complies with the xHCI revision 0.96
+ * 1'b1 : The host controller complies with the xHCI revision 1.0
+ */
+#define XHCI_REVISION BIT(12)
+
+#define USB2_VBUS_MNGMNT_SEL1 0x2C
+/*
+ * For all fields in USB2_VBUS_MNGMNT_SEL1
+ * 2’b00 : Override value from Reg 0x30 is selected
+ * 2’b01 : utmiotg_signal_name from usb3_top is selected
+ * 2’b10 : pipew_signal_name from PIPEW instance is selected
+ * 2’b11 : value is 1'b0
+ */
+#define USB2_VBUS_REG300x0
+#define USB2_VBUS_UTMIOTG 0x1
+#define USB2_VBUS_PIPEW0x2
+#define USB2_VBUS_ZERO 0x3
+
+#define SEL_OVERRIDE_VBUSVALID(n) (n 0)
+#define SEL_OVERRIDE_POWERPRESENT(n) (n 4)
+#define SEL_OVERRIDE_BVALID(n) (n 8)
+
+/* Static DRD configuration */
+#define USB3_CONTROL_MASK 0xf77
+
+#define USB3_DEVICE_NOT_HOST BIT(0)
+#define USB3_FORCE_VBUSVALID BIT(1)
+#define USB3_DELAY_VBUSVALID BIT(2)
+#define USB3_SEL_FORCE_OPMODE BIT(4)
+#define USB3_FORCE_OPMODE(n) (n 5)
+#define USB3_SEL_FORCE_DPPULLDOWN2 BIT(8)
+#define USB3_FORCE_DPPULLDOWN2 BIT(9)
+#define USB3_SEL_FORCE_DMPULLDOWN2 BIT(10)
+#define USB3_FORCE_DMPULLDOWN2 BIT(11)
+
+/**
+ * struct st_dwc3 - dwc3-st driver private structure
+ * @dev: device pointer
+ * @glue_base: ioaddr for the glue registers
+ * @regmap:regmap pointer for getting syscfg
+ * @syscfg_reg_off:usb syscfg control offset
+ * @dr_mode: drd static host/device config
+ * @rstc_pwrdn:rest controller for powerdown signal
+ * @rstc_rst: reset controller for softreset signal
+ */
+
+struct st_dwc3 {
+ struct device *dev;
+
[PATCH v6 0/3] Add ST dwc3 glue layer driver
This series adds support for the ST glue logic which wraps the DWC3 controller on STiH407 SoC family chipsets. Changes since v5 - Use of_platform_depopulate Changes since v4 - Fix bug with setting bits in usb control register - Remove superflous '\n' - Change default Kconfig to make default same as other platforms - Update dt doc example so that both usb2 and usb3 phys are using generic drivers/phy instead of drivers/usb/phy - Reconfigure ST glue logic regs in resume callback Changes since v3 - Various formating nits Changes since v2 - Use dr_mode for host/device static configuration - Manage shared reset signal to usbss to avoid hang if probing before usb3 phy - Remove DT checks and make driver depend on OF - Change some #define to use BIT macro - Make some comments clearer - Use kerneldoc for struct documentation - Remove udelay - Let DT create platform_devices, and remove legacy alloc - Change some logging levels to dev_dbg - Various whitespace and formatting cleanup - Use SIMPLE_DEV_PM_OPS() - Add const to of_device struct - Reorder header files alphabetically - Use devm_ioremap_resource instead of devm_request_and_ioremap - Remove of_match_ptr() Changes since v1 - Fix Kconfig mistake Peter Griffin (3): usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC usb: dwc3: dwc3-st: Add st-dwc3 devicetree bindings documentation MAINTAINERS: Add dwc3-st.c file to ARCH/STI architecture Documentation/devicetree/bindings/usb/dwc3-st.txt | 68 MAINTAINERS | 1 + drivers/usb/dwc3/Kconfig | 9 + drivers/usb/dwc3/Makefile | 1 + drivers/usb/dwc3/dwc3-st.c| 377 ++ 5 files changed, 456 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/dwc3-st.txt create mode 100644 drivers/usb/dwc3/dwc3-st.c -- 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 v6 2/3] usb: dwc3: dwc3-st: Add st-dwc3 devicetree bindings documentation
This patch documents the device tree documentation required for
the ST usb3 controller glue layer found in STiH407 devices.
Signed-off-by: Giuseppe Cavallaro peppe.cavall...@st.com
Signed-off-by: Peter Griffin peter.grif...@linaro.org
Acked-by: Lee Jones lee.jo...@linaro.org
---
Documentation/devicetree/bindings/usb/dwc3-st.txt | 68 +++
1 file changed, 68 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/dwc3-st.txt
diff --git a/Documentation/devicetree/bindings/usb/dwc3-st.txt
b/Documentation/devicetree/bindings/usb/dwc3-st.txt
new file mode 100644
index 000..f9d7025
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/dwc3-st.txt
@@ -0,0 +1,68 @@
+ST DWC3 glue logic
+
+This file documents the parameters for the dwc3-st driver.
+This driver controls the glue logic used to configure the dwc3 core on
+STiH407 based platforms.
+
+Required properties:
+ - compatible : must be st,stih407-dwc3
+ - reg : glue logic base address and USB syscfg ctrl register offset
+ - reg-names : should be reg-glue and syscfg-reg
+ - st,syscon : should be phandle to system configuration node which
+ encompasses the glue registers
+ - resets : list of phandle and reset specifier pairs. There should be
two entries, one
+ for the powerdown and softreset lines of the usb3 IP
+ - reset-names : list of reset signal names. Names should be powerdown and
softreset
+See: Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
+See: Documentation/devicetree/bindings/reset/reset.txt
+
+ - #address-cells, #size-cells : should be '1' if the device has sub-nodes
+ with 'reg' property
+
+ - pinctl-names: A pinctrl state named default must be defined
+See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+
+ - pinctrl-0 : Pin control group
+See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+
+ - ranges : allows valid 1:1 translation between child's address space and
+ parent's address space
+
+Sub-nodes:
+The dwc3 core should be added as subnode to ST DWC3 glue as shown in the
+example below. The DT binding details of dwc3 can be found in:
+Documentation/devicetree/bindings/usb/dwc3.txt
+
+NB: The dr_mode property described in [1] is NOT optional for this driver, as
the default value
+is otg, which isn't supported by this SoC. Valid dr_mode values for dwc3-st
are either host
+or device.
+
+[1] Documentation/devicetree/bindings/usb/generic.txt
+
+Example:
+
+st_dwc3: dwc3@8f94000 {
+ status = disabled;
+ compatible = st,stih407-dwc3;
+ reg = 0x08f94000 0x1000, 0x110 0x4;
+ reg-names = reg-glue, syscfg-reg;
+ st,syscfg = syscfg_core;
+ resets = powerdown STIH407_USB3_POWERDOWN,
+ softreset STIH407_MIPHY2_SOFTRESET;
+ reset-names = powerdown,
+ softreset;
+ #address-cells = 1;
+ #size-cells = 1;
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_usb3;
+ ranges;
+
+ dwc3: dwc3@990 {
+ compatible = snps,dwc3;
+ reg = 0x0990 0x10;
+ interrupts = GIC_SPI 155 IRQ_TYPE_NONE;
+ dr_mode = host;
+ phys-names = usb2-phy, usb3-phy;
+ phys= usb2_picophy2, phy_port2 MIPHY_TYPE_USB;
+ };
+};
--
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
Re: [PATCH v3 3/3] gpio: add support for the Diolan DLN-2 USB GPIO driver
On Fri, Sep 05, 2014 at 06:17:59PM +0300, Octavian Purdila wrote:
+static int dln2_do_remove(struct dln2_gpio *dln2)
+{
+ /* When removing the DLN2 USB device, gpiochip_remove may fail
+ * due to i2c drivers holding a GPIO pin. However, the i2c bus
+ * will eventually be removed triggering an i2c driver remove
+ * which will release the GPIO pin. So retrying the operation
+ * later should succeed. */
+ int ret = gpiochip_remove(dln2-gpio);
+ struct device *dev = dln2-gpio.dev;
+
+ if (ret 0) {
+ if (ret == -EBUSY)
+ schedule_delayed_work(dln2-remove_work.work, HZ/10);
+ else
+ dev_warn(dev, error removing gpio chip: %d\n, ret);
+ } else {
+ kfree(dln2);
+ }
+
+ return ret;
+}
Apparently, the return value from gpiochip_remove is going away:
Start to kill off the return value from gpiochip_remove() by
removing the __must_check attribute and removing all checks
inside the drivers/gpio directory. The rationale is: well what
were we supposed to do if there is an error code? Not much:
print an error message. And gpiolib already does that. So make
this function return void eventually.
https://www.mail-archive.com/linux-gpio@vger.kernel.org/msg03468.html
Also, have you considered what happens if there are gpios exported
through sysfs? These may never be released.
In general, how well have these patches been tested with disconnect
events? At least gpiolib is known to blow up (sooner or later) when a
gpiochip is removed when having requested gpios.
Johan
--
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 v6 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
Hi,
On Fri, Sep 05, 2014 at 04:36:30PM +0100, Peter Griffin wrote:
+static int st_dwc3_remove_child(struct device *dev, void *c)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+
+ of_device_unregister(pdev);
+
+ return 0;
+}
+
+static int st_dwc3_remove(struct platform_device *pdev)
+{
+ struct st_dwc3 *dwc3_data = platform_get_drvdata(pdev);
+
+ device_for_each_child(pdev-dev, NULL, st_dwc3_remove_child);
same as before, of_platform_depopulate(). I can fix this one myself this
time.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v6 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
On Fri, Sep 05, 2014 at 10:47:01AM -0500, Felipe Balbi wrote:
Hi,
On Fri, Sep 05, 2014 at 04:36:30PM +0100, Peter Griffin wrote:
+static int st_dwc3_remove_child(struct device *dev, void *c)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+
+ of_device_unregister(pdev);
+
+ return 0;
+}
+
+static int st_dwc3_remove(struct platform_device *pdev)
+{
+ struct st_dwc3 *dwc3_data = platform_get_drvdata(pdev);
+
+ device_for_each_child(pdev-dev, NULL, st_dwc3_remove_child);
same as before, of_platform_depopulate(). I can fix this one myself this
time.
it's in my testign/next branch, please make sure it looks alright.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v5 1/4] usb: gadget: pxa27x_udc: add devicetree support
Hi, On Sun, Aug 31, 2014 at 09:02:09PM +0200, Robert Jarzmik wrote: Add support for device-tree device discovery. If devicetree is not provided, fallback to legacy platform data discovery. Signed-off-by: Robert Jarzmik robert.jarz...@free.fr Cc: devicet...@vger.kernel.org please split this patch. First add udc-gpio and fix all the gpio details, then add devicetree. -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH 0/7] usb: gadget: add reset API at usb_gadget_driver
On Fri, Sep 05, 2014 at 08:44:08AM +0800, Peter Chen wrote: On Thu, Sep 04, 2014 at 11:04:38AM -0400, Alan Stern wrote: On Thu, 4 Sep 2014, Peter Chen wrote: Hi Felipe Alan, how about using below steps for this reset/vbus/pullup changes? It mainly uses Alan's suggestion. Step 1: The initial implementation in the four gadget drivers can be very simple: It calls the disconnect handler. the -reset is mandatory for all gadget drivers (currently, only four, they are composite, configfs, gadgetfs , dbgp. Step 2: Add routines to udc-core to handle Vbus changes, function activation changes, and resets. It will include three sub-steps, from easy to hard: reset handler, vbus handler, and activation handler. Perhaps the activation handler can be delayed until step 4. It won't get used until composite.c is modified to call it. Step 3: Modify all UDCs to call udc-core's reset and vbus handler, delete usb_gadget_connect/usb_gadget_disconnect operation at all UDC drivers, and delete invoking usb_gadget_connect unconditional at udc_bind_to_driver Step 4: Modify the composite.c to disable pullup for adding every function, and enable pullup when necessary. Actually, composite.c should be modified to call the activation handler in udc-core, and then _that_ routine would adjust the pullup as necessary. This plan is okay with me. OK, let's put the function activation change to the last. If the Felipe has no other comments, I will send the patch for step one next Monday. Please do, the thread already has too much information and we better put all that in code. Keep in mind that me and Alan have resurected an old patchset adding -reset() callback to the gadget framework. If you want to take a look it's at [1] https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/log/?h=gadget-add-reset-method -- balbi signature.asc Description: Digital signature
Re: ax88179_178a hang over xhci
On Fri, Sep 05, 2014 at 08:53:59AM +, David Laight wrote: On Wed, Aug 20, 2014 at 04:12:49PM +0200, Andrea Arcangeli wrote: Hi Sarah, just a short followup on this. I still had 1gbps hangs with the 0b95:1790 ASIX Electronics Corp device using xhci. But it seems now stable for the last 12 hours under heavy load after I removed all powersaving features. ... Unless the hardware is broken there's something wrong in xhci or the usbnet driver that makes it hang with my usual stress test I do to check if the networks is reliable. The device driver is ax88179_178a.c There are still some bugs in the xhci ring handling that can affect the ax88179_178a driver+hardware. I needs the fix to ensure that the ring boundaries are aligned with usb packets, otherwise packets can get lost and the tx side can lock up. Ok once fixed feel free to CC me so I can test it. I'm running ax88179_178a in two places without apparent problems, interestingly I didn't reproduce more lockups after turning off the powersave feature. The only catch is that the xhci hang is not easily reproducible... One more thing worth mentioning, I had to disable tx/rx checksum in hardware (enabled by default) with ethtool or it wouldn't resume from RAM but that was a black and white issue, the only real annoyance was the occasional xhci hang that requires rmmod xhci_hcd to recover from. Thanks, Andrea -- 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 3/3] gpio: add support for the Diolan DLN-2 USB GPIO driver
On Fri, Sep 5, 2014 at 6:38 PM, Johan Hovold jo...@kernel.org wrote:
On Fri, Sep 05, 2014 at 06:17:59PM +0300, Octavian Purdila wrote:
+static int dln2_do_remove(struct dln2_gpio *dln2)
+{
+ /* When removing the DLN2 USB device, gpiochip_remove may fail
+ * due to i2c drivers holding a GPIO pin. However, the i2c bus
+ * will eventually be removed triggering an i2c driver remove
+ * which will release the GPIO pin. So retrying the operation
+ * later should succeed. */
+ int ret = gpiochip_remove(dln2-gpio);
+ struct device *dev = dln2-gpio.dev;
+
+ if (ret 0) {
+ if (ret == -EBUSY)
+ schedule_delayed_work(dln2-remove_work.work, HZ/10);
+ else
+ dev_warn(dev, error removing gpio chip: %d\n, ret);
+ } else {
+ kfree(dln2);
+ }
+
+ return ret;
+}
Apparently, the return value from gpiochip_remove is going away:
Start to kill off the return value from gpiochip_remove() by
removing the __must_check attribute and removing all checks
inside the drivers/gpio directory. The rationale is: well what
were we supposed to do if there is an error code? Not much:
print an error message. And gpiolib already does that. So make
this function return void eventually.
https://www.mail-archive.com/linux-gpio@vger.kernel.org/msg03468.html
Oh, I missed this, thanks for pointing it out.
Also, have you considered what happens if there are gpios exported
through sysfs? These may never be released.
In general, how well have these patches been tested with disconnect
events? At least gpiolib is known to blow up (sooner or later) when a
gpiochip is removed when having requested gpios.
I do disconnect tests regularly. Since switching to the new irq
interface the following patch is needed:
https://lkml.org/lkml/2014/9/5/408
With it and the current patch sets things seems to work well.
--
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] HID: usbhid: add always-poll quirk
Add quirk to make sure that a device is always polled for input events
even if it hasn't been opened.
This is needed for devices that disconnects from the bus unless the
interrupt endpoint has been polled at least once or when not responding
to an input event (e.g. after having shut down X).
Signed-off-by: Johan Hovold jo...@kernel.org
---
drivers/hid/usbhid/hid-core.c | 26 +++---
include/linux/hid.h | 1 +
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index 7b88f4c..d8b6976 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -82,7 +82,7 @@ static int hid_start_in(struct hid_device *hid)
struct usbhid_device *usbhid = hid-driver_data;
spin_lock_irqsave(usbhid-lock, flags);
- if (hid-open 0
+ if ((hid-open 0 || hid-quirks HID_QUIRK_ALWAYS_POLL)
!test_bit(HID_DISCONNECTED, usbhid-iofl)
!test_bit(HID_SUSPENDED, usbhid-iofl)
!test_and_set_bit(HID_IN_RUNNING, usbhid-iofl)) {
@@ -292,6 +292,8 @@ static void hid_irq_in(struct urb *urb)
case 0: /* success */
usbhid_mark_busy(usbhid);
usbhid-retry_delay = 0;
+ if ((hid-quirks HID_QUIRK_ALWAYS_POLL) !hid-open)
+ break;
hid_input_report(urb-context, HID_INPUT_REPORT,
urb-transfer_buffer,
urb-actual_length, 1);
@@ -734,8 +736,10 @@ void usbhid_close(struct hid_device *hid)
if (!--hid-open) {
spin_unlock_irq(usbhid-lock);
hid_cancel_delayed_stuff(usbhid);
- usb_kill_urb(usbhid-urbin);
- usbhid-intf-needs_remote_wakeup = 0;
+ if (!(hid-quirks HID_QUIRK_ALWAYS_POLL)) {
+ usb_kill_urb(usbhid-urbin);
+ usbhid-intf-needs_remote_wakeup = 0;
+ }
} else {
spin_unlock_irq(usbhid-lock);
}
@@ -1133,6 +1137,19 @@ static int usbhid_start(struct hid_device *hid)
set_bit(HID_STARTED, usbhid-iofl);
+ if (hid-quirks HID_QUIRK_ALWAYS_POLL) {
+ ret = usb_autopm_get_interface(usbhid-intf);
+ if (ret)
+ goto fail;
+ usbhid-intf-needs_remote_wakeup = 1;
+ ret = hid_start_in(hid);
+ if (ret) {
+ dev_err(hid-dev,
+ failed to start in urb: %d\n, ret);
+ }
+ usb_autopm_put_interface(usbhid-intf);
+ }
+
/* Some keyboards don't work until their LEDs have been set.
* Since BIOSes do set the LEDs, it must be safe for any device
* that supports the keyboard boot protocol.
@@ -1165,6 +1182,9 @@ static void usbhid_stop(struct hid_device *hid)
if (WARN_ON(!usbhid))
return;
+ if (hid-quirks HID_QUIRK_ALWAYS_POLL)
+ usbhid-intf-needs_remote_wakeup = 0;
+
clear_bit(HID_STARTED, usbhid-iofl);
spin_lock_irq(usbhid-lock); /* Sync with error and led handlers */
set_bit(HID_DISCONNECTED, usbhid-iofl);
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 77632cf..05eb710 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -286,6 +286,7 @@ struct hid_item {
#define HID_QUIRK_HIDINPUT_FORCE 0x0080
#define HID_QUIRK_NO_EMPTY_INPUT 0x0100
#define HID_QUIRK_NO_INIT_INPUT_REPORTS0x0200
+#define HID_QUIRK_ALWAYS_POLL 0x0400
#define HID_QUIRK_SKIP_OUTPUT_REPORTS 0x0001
#define HID_QUIRK_SKIP_OUTPUT_REPORT_ID0x0002
#define HID_QUIRK_NO_OUTPUT_REPORTS_ON_INTR_EP 0x0004
--
1.8.5.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 0/2] HID: usbhid: fix Elan touchscreen disconnects
Here's the always-poll quirk that is needed to prevent the Elan touchscreen from disconnecting itself from the bus. These patches are against v3.16.1, but applies fine to hid-next. Note that this series is not dependent on the device-qualifier quirk [1], which is needed to get the same device to enumerate reliably, so these two quirks could in through the USB and HID tree, respectively. Johan [1] http://marc.info/?l=linux-usbm=140898201107571w=2 Johan Hovold (2): HID: usbhid: add always-poll quirk HID: usbhid: enable always-poll quirk for Elan Touchscreen drivers/hid/hid-ids.h | 3 +++ drivers/hid/usbhid/hid-core.c | 26 +++--- drivers/hid/usbhid/hid-quirks.c | 1 + include/linux/hid.h | 1 + 4 files changed, 28 insertions(+), 3 deletions(-) -- 1.8.5.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 2/2] HID: usbhid: enable always-poll quirk for Elan Touchscreen
Enable the always-poll quirk for Elan Touchscreens found on some recent
Samsung laptops.
Without this quirk the device keeps disconnecting from the bus (and is
re-enumerated) unless opened (and kept open, should an input event
occur).
Note that while the device can be run-time suspended, the autosuspend
timeout must be high enough to allow the device to be polled at least
once before being suspended. Specifically, using autosuspend_delay_ms=0
will still cause the device to disconnect on input events.
Signed-off-by: Johan Hovold jo...@kernel.org
---
drivers/hid/hid-ids.h | 3 +++
drivers/hid/usbhid/hid-quirks.c | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 48b66bb..79b966d 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -296,6 +296,9 @@
#define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_73F7 0x73f7
#define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_A001 0xa001
+#define USB_VENDOR_ID_ELAN 0x04f3
+#define USB_DEVICE_ID_ELAN_TOUCHSCREEN 0x0089
+
#define USB_VENDOR_ID_ELECOM 0x056e
#define USB_DEVICE_ID_ELECOM_BM084 0x0061
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 31e6727..72da083 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -70,6 +70,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_3AXIS_5BUTTON_STICK,
HID_QUIRK_NOGET },
{ USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_AXIS_295, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_DMI, USB_DEVICE_ID_DMI_ENC, HID_QUIRK_NOGET },
+ { USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_ELO, USB_DEVICE_ID_ELO_TS2700, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_FORMOSA, USB_DEVICE_ID_FORMOSA_IR_RECEIVER,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_FREESCALE, USB_DEVICE_ID_FREESCALE_MX28,
HID_QUIRK_NOGET },
--
1.8.5.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: Similar Elan Touchscreen reset behaviour
On Thu, Sep 04, 2014 at 02:54:23PM -0700, Greg KH wrote: On Thu, Sep 04, 2014 at 02:30:40PM -0700, Sarah Sharp wrote: On Sat, Aug 16, 2014 at 12:37:19AM -0700, Eric Decker wrote: Hi Sarah, I talked to you a while back about the ELAN touchscreen in my ASUS laptop doing a repeated disconnect. It just came back. So you are probably right about it being flakey h/w. Returning it at this point probably isn't an option. Now if the ELAN touchscreen is a problem, is there a way to blacklist it so it doesn't get turned on? I don't even use the touchscreen. You could blacklist the driver, e.g. put the module name in /etc/modprobe.d/blacklist-whatever.conf That will at least stop the module from being loaded, but won't stop it from being enumerated. I think there's a way for userspace to claim a particular port so that the kernel doesn't even do enumeration, but I can't remember the interface. Maybe Mathias or Alan knows? You might want to look at Johan's patches on the list, they address a known problem with ELAN touchscreens of being flakey that solves the issue with my laptop, and should be merged soon. The problem is the hardware goes crazy if it doesn't see USB traffic very quickly after booting, and constantly. So switching to console mode, or booting to console mode can cause problems. I'd be interested to see if those patches solve your issue as well. Eric, the new always-poll quirk can be found here if you want to give it a try: http://marc.info/?l=linux-usbm=140993344211315w=2 My Elan touchscreen also needs the following quirk to enumerate reliably: http://marc.info/?l=linux-usbm=140898201107571w=2 Johan -- 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 0/2] USB: core: add add device-qualifier quirk
On Mon, Aug 25, 2014 at 05:51:25PM +0200, Johan Hovold wrote: This is quirk is indeed needed to get the Elan Touchscreen found on some Samsung laptops to enumerate reliably. I'm still looking into the disconnects I've been experiencing. For some reason I cannot reproduce the repeated disconnects any longer, although the device still disconnects at least once if an input event occurs after wake up (when the device is not open) or close. For the record, that was just a udev rule enabling autosuspend that got in the way. Johan -- 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 v6 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
Hi Felipe, On Fri, 05 Sep 2014, Felipe Balbi wrote: + + device_for_each_child(pdev-dev, NULL, st_dwc3_remove_child); same as before, of_platform_depopulate(). I can fix this one myself this time. Oh sorry, not sure what happened there, thanks for fixing it up:-) it's in my testign/next branch, please make sure it looks alright. Just checked and it looks good. regards, Peter. -- 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 v6 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
On Fri, Sep 05, 2014 at 05:55:20PM +0100, Peter Griffin wrote: Hi Felipe, On Fri, 05 Sep 2014, Felipe Balbi wrote: + + device_for_each_child(pdev-dev, NULL, st_dwc3_remove_child); same as before, of_platform_depopulate(). I can fix this one myself this time. Oh sorry, not sure what happened there, thanks for fixing it up:-) no problem, it was small enough it's in my testign/next branch, please make sure it looks alright. Just checked and it looks good. cool thanks, I'll run some extra build testing and move it to next soonish. -- balbi signature.asc Description: Digital signature
[PATCH RESEND v5 5/5] MAINTAINERS: Add ehci-st.c and ohci-st.c to ARCH/STI architecture
This patch adds the ehci-st.c and ohci-st.c files for the usb 2.0 usb1.1 host controller drivers found on stih41x and stih4xx STMicroelectronics SoC's into the STI arch section of the maintainers file. Signed-off-by: Peter Griffin peter.grif...@linaro.org --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index cf24bb5..5abd281 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1398,6 +1398,8 @@ F:drivers/media/rc/st_rc.c F: drivers/i2c/busses/i2c-st.c F: drivers/tty/serial/st-asc.c F: drivers/mmc/host/sdhci-st.c +F: drivers/usb/host/ehci-st.c +F: drivers/usb/host/ohci-st.c ARM/TECHNOLOGIC SYSTEMS TS7250 MACHINE SUPPORT M: Lennert Buytenhek ker...@wantstofly.org -- 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 RESEND v5 3/5] usb: host: ehci-st: Add ehci-st devicetree bindings documentation
This patch documents the device tree bindings required for the
ehci on-chip controller found in ST consumer electronics SoC's.
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
Documentation/devicetree/bindings/usb/ehci-st.txt | 39 +++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/ehci-st.txt
diff --git a/Documentation/devicetree/bindings/usb/ehci-st.txt
b/Documentation/devicetree/bindings/usb/ehci-st.txt
new file mode 100644
index 000..fb45fa5
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ehci-st.txt
@@ -0,0 +1,39 @@
+ST USB EHCI controller
+
+Required properties:
+ - compatible : must be st,st-ehci-300x
+ - reg : physical base addresses of the controller and length
of memory mapped
+ region
+ - interrupts : one EHCI interrupt should be described here
+ - pinctrl-names : a pinctrl state named default must be defined
+ - pinctrl-0 : phandle referencing pin configuration of the USB
controller
+See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+ - clocks : phandle list of usb clocks
+ - clock-names : should be ic for interconnect clock and clk48
+See: Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+ - phys: phandle for the PHY device
+ - phy-names : should be usb
+ - resets : phandle + reset specifier pairs to the powerdown and
softreset lines
+ of the USB IP
+ - reset-names : should be power and softreset
+See: Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
+See: Documentation/devicetree/bindings/reset/reset.txt
+
+Example:
+
+ ehci1: usb@0xfe203e00 {
+ compatible = st,st-ehci-300x;
+ reg = 0xfe203e00 0x100;
+ interrupts = GIC_SPI 148 IRQ_TYPE_NONE;
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_usb1;
+ clocks = clk_s_a1_ls 0;
+ phys = usb2_phy;
+ phy-names = usb;
+ status = okay;
+
+ resets = powerdown STIH416_USB1_POWERDOWN,
+softreset STIH416_USB1_SOFTRESET;
+ reset-names = power, softreset;
+ };
--
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 RESEND v5 4/5] usb: host: ohci-st: Add ohci-st devicetree bindings documentation
This patch documents the device tree bindings required for
the ohci on-chip controller found in ST consumer electronics SoC's.
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
Documentation/devicetree/bindings/usb/ohci-st.txt | 37 +++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/ohci-st.txt
diff --git a/Documentation/devicetree/bindings/usb/ohci-st.txt
b/Documentation/devicetree/bindings/usb/ohci-st.txt
new file mode 100644
index 000..6d83937
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ohci-st.txt
@@ -0,0 +1,37 @@
+ST USB OHCI controller
+
+Required properties:
+
+ - compatible : must be st,st-ohci-300x
+ - reg : physical base addresses of the controller and length
of memory mapped
+ region
+ - interrupts : one OHCI controller interrupt should be described here
+ - clocks : phandle list of usb clocks
+ - clock-names : should be ic for interconnect clock and clk48
+See: Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+ - phys: phandle for the PHY device
+ - phy-names : should be usb
+
+ - resets : phandle to the powerdown and reset controller for the
USB IP
+ - reset-names : should be power and softreset.
+See: Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
+See: Documentation/devicetree/bindings/reset/reset.txt
+
+Example:
+
+ ohci0: usb@0xfe1ffc00 {
+ compatible = st,st-ohci-300x;
+ reg = 0xfe1ffc00 0x100;
+ interrupts = GIC_SPI 149 IRQ_TYPE_NONE;
+ clocks = clk_s_a1_ls 0,
+clockgen_b0 0;
+ clock-names = ic, clk48;
+ phys = usb2_phy;
+ phy-names = usb;
+ status = okay;
+
+ resets = powerdown STIH416_USB0_POWERDOWN,
+softreset STIH416_USB0_SOFTRESET;
+ reset-names = power, softreset;
+ };
--
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 RESEND v5 1/5] usb: host: ehci-st: Add EHCI support for ST STB devices
This patch adds the glue code required to ensure the on-chip EHCI
controller works on STi consumer electronics SoC's from STMicroelectronics.
It mainly manages the setting and enabling of the relevant clocks and manages
the reset / power signals to the IP block.
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
drivers/usb/host/ehci-st.c | 365 +++
drivers/usb/host/usb-st-common.h | 31
2 files changed, 396 insertions(+)
create mode 100644 drivers/usb/host/ehci-st.c
create mode 100644 drivers/usb/host/usb-st-common.h
diff --git a/drivers/usb/host/ehci-st.c b/drivers/usb/host/ehci-st.c
new file mode 100644
index 000..c363807
--- /dev/null
+++ b/drivers/usb/host/ehci-st.c
@@ -0,0 +1,365 @@
+/*
+ * ST EHCI driver
+ *
+ * Copyright (C) 2014 STMicroelectronics – All Rights Reserved
+ *
+ * Author: Peter Griffin peter.grif...@linaro.org
+ *
+ * Derived from ehci-platform.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/clk.h
+#include linux/dma-mapping.h
+#include linux/err.h
+#include linux/kernel.h
+#include linux/hrtimer.h
+#include linux/io.h
+#include linux/module.h
+#include linux/of.h
+#include linux/phy/phy.h
+#include linux/platform_device.h
+#include linux/reset.h
+#include linux/usb.h
+#include linux/usb/hcd.h
+#include linux/usb/ehci_pdriver.h
+
+#include ehci.h
+#include usb-st-common.h
+
+#define DRIVER_DESC EHCI STMicroelectronics driver
+
+#define hcd_to_ehci_priv(h) ((struct st_platform_priv *)hcd_to_ehci(h)-priv)
+
+static const char hcd_name[] = ehci-st;
+
+#define EHCI_CAPS_SIZE 0x10
+#define AHB2STBUS_INSREG01 (EHCI_CAPS_SIZE + 0x84)
+
+static int st_ehci_platform_reset(struct usb_hcd *hcd)
+{
+ struct platform_device *pdev = to_platform_device(hcd-self.controller);
+ struct usb_ehci_pdata *pdata = dev_get_platdata(pdev-dev);
+ struct ehci_hcd *ehci = hcd_to_ehci(hcd);
+ int retval;
+ u32 threshold;
+
+ /* Set EHCI packet buffer IN/OUT threshold to 128 bytes */
+ threshold = 128 | (128 16);
+ writel(threshold, hcd-regs + AHB2STBUS_INSREG01);
+
+ ehci-caps = hcd-regs + pdata-caps_offset;
+ retval = ehci_setup(hcd);
+ if (retval)
+ return retval;
+
+ return 0;
+}
+
+static int st_ehci_platform_power_on(struct platform_device *dev)
+{
+ struct usb_hcd *hcd = platform_get_drvdata(dev);
+ struct st_platform_priv *priv = hcd_to_ehci_priv(hcd);
+ int clk, ret;
+
+ ret = reset_control_deassert(priv-pwr);
+ if (ret)
+ return ret;
+
+ ret = reset_control_deassert(priv-rst);
+ if (ret)
+ goto err_assert_power;
+
+ /* some SoCs don't have a dedicated 48Mhz clock, but those that do
+ need the rate to be explicitly set */
+ if (priv-clk48) {
+ ret = clk_set_rate(priv-clk48, 4800);
+ if (ret)
+ goto err_assert_reset;
+ }
+
+ for (clk = 0; clk USB_MAX_CLKS priv-clks[clk]; clk++) {
+ ret = clk_prepare_enable(priv-clks[clk]);
+ if (ret)
+ goto err_disable_clks;
+ }
+
+ ret = phy_init(priv-phy);
+ if (ret)
+ goto err_disable_clks;
+
+ ret = phy_power_on(priv-phy);
+ if (ret)
+ goto err_exit_phy;
+
+ return 0;
+
+err_exit_phy:
+ phy_exit(priv-phy);
+err_disable_clks:
+ while (--clk = 0)
+ clk_disable_unprepare(priv-clks[clk]);
+err_assert_reset:
+ reset_control_assert(priv-rst);
+err_assert_power:
+ reset_control_assert(priv-pwr);
+
+ return ret;
+}
+
+static void st_ehci_platform_power_off(struct platform_device *dev)
+{
+ struct usb_hcd *hcd = platform_get_drvdata(dev);
+ struct st_platform_priv *priv = hcd_to_ehci_priv(hcd);
+ int clk;
+
+ reset_control_assert(priv-pwr);
+
+ reset_control_assert(priv-rst);
+
+ phy_power_off(priv-phy);
+
+ phy_exit(priv-phy);
+
+ for (clk = USB_MAX_CLKS - 1; clk = 0; clk--)
+ if (priv-clks[clk])
+ clk_disable_unprepare(priv-clks[clk]);
+
+}
+
+static struct hc_driver __read_mostly ehci_platform_hc_driver;
+
+static const struct ehci_driver_overrides platform_overrides __initconst = {
+ .reset =st_ehci_platform_reset,
+ .extra_priv_size = sizeof(struct st_platform_priv),
+};
+
+static struct usb_ehci_pdata ehci_platform_defaults = {
+ .power_on = st_ehci_platform_power_on,
+ .power_suspend =st_ehci_platform_power_off,
+ .power_off =st_ehci_platform_power_off,
+};
+
+static int st_ehci_platform_probe(struct platform_device *dev)
+{
+ struct usb_hcd *hcd;
+ struct resource
[PATCH RESEND v5 2/5] usb: host: ohci-st: Add OHCI driver support for ST STB devices
This patch adds the glue code required to ensure the on-chip OHCI
controller works on STi consumer electronics SoC's from STMicroelectronics.
It mainly manages the setting and enabling of the relevant clocks and manages
the reset / power signals to the IP block.
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
drivers/usb/host/Kconfig | 8 ++
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ohci-st.c | 339 +
3 files changed, 348 insertions(+)
create mode 100644 drivers/usb/host/ohci-st.c
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 82800a7..609efe2 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -761,6 +761,14 @@ config USB_HCD_SSB
If unsure, say N.
+config USB_HCD_ST
+ tristate ST USB driver for ST SoC Series
+ depends on ARCH_STI OF
+ select GENERIC_PHY
+ help
+ Enable support for the on-chip OHCI EHCI controller found on
+ STMicroelectronics consumer electronics SoC's.
+
config USB_HCD_TEST_MODE
bool HCD test mode support
---help---
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 144c038..ae2db0b 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -77,3 +77,4 @@ obj-$(CONFIG_USB_HCD_SSB) += ssb-hcd.o
obj-$(CONFIG_USB_FUSBH200_HCD) += fusbh200-hcd.o
obj-$(CONFIG_USB_FOTG210_HCD) += fotg210-hcd.o
obj-$(CONFIG_USB_MAX3421_HCD) += max3421-hcd.o
+obj-$(CONFIG_USB_HCD_ST) += ehci-st.o ohci-st.o
diff --git a/drivers/usb/host/ohci-st.c b/drivers/usb/host/ohci-st.c
new file mode 100644
index 000..738d6c6
--- /dev/null
+++ b/drivers/usb/host/ohci-st.c
@@ -0,0 +1,339 @@
+/*
+ * ST OHCI driver
+ *
+ * Copyright (C) 2014 STMicroelectronics – All Rights Reserved
+ *
+ * Author: Peter Griffin peter.grif...@linaro.org
+ *
+ * Derived from ohci-platform.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/clk.h
+#include linux/dma-mapping.h
+#include linux/hrtimer.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/err.h
+#include linux/phy/phy.h
+#include linux/platform_device.h
+#include linux/reset.h
+#include linux/usb/ohci_pdriver.h
+#include linux/usb.h
+#include linux/usb/hcd.h
+
+#include ohci.h
+#include usb-st-common.h
+
+#define DRIVER_DESC OHCI STMicroelectronics driver
+
+#define hcd_to_ohci_priv(h) ((struct st_platform_priv *)hcd_to_ohci(h)-priv)
+
+static const char hcd_name[] = ohci-st;
+
+static int st_ohci_platform_power_on(struct platform_device *dev)
+{
+ struct usb_hcd *hcd = platform_get_drvdata(dev);
+ struct st_platform_priv *priv = hcd_to_ohci_priv(hcd);
+ int clk, ret;
+
+ ret = reset_control_deassert(priv-pwr);
+ if (ret)
+ return ret;
+
+ ret = reset_control_deassert(priv-rst);
+ if (ret)
+ goto err_assert_power;
+
+ /* some SoCs don't have a dedicated 48Mhz clock, but those that do
+ need the rate to be explicitly set */
+ if (priv-clk48) {
+ ret = clk_set_rate(priv-clk48, 4800);
+ if (ret)
+ goto err_assert_reset;
+ }
+
+ for (clk = 0; clk USB_MAX_CLKS priv-clks[clk]; clk++) {
+ ret = clk_prepare_enable(priv-clks[clk]);
+ if (ret)
+ goto err_disable_clks;
+ }
+
+ ret = phy_init(priv-phy);
+ if (ret)
+ goto err_disable_clks;
+
+ ret = phy_power_on(priv-phy);
+ if (ret)
+ goto err_exit_phy;
+
+ return 0;
+
+err_exit_phy:
+ phy_exit(priv-phy);
+err_disable_clks:
+ while (--clk = 0)
+ clk_disable_unprepare(priv-clks[clk]);
+err_assert_reset:
+ reset_control_assert(priv-rst);
+err_assert_power:
+ reset_control_assert(priv-pwr);
+
+ return ret;
+}
+
+static void st_ohci_platform_power_off(struct platform_device *dev)
+{
+ struct usb_hcd *hcd = platform_get_drvdata(dev);
+ struct st_platform_priv *priv = hcd_to_ohci_priv(hcd);
+
+ int clk;
+
+ reset_control_assert(priv-pwr);
+
+ reset_control_assert(priv-rst);
+
+ phy_power_off(priv-phy);
+
+ phy_exit(priv-phy);
+
+ for (clk = USB_MAX_CLKS - 1; clk = 0; clk--)
+ if (priv-clks[clk])
+ clk_disable_unprepare(priv-clks[clk]);
+}
+
+static struct hc_driver __read_mostly ohci_platform_hc_driver;
+
+static const struct ohci_driver_overrides platform_overrides __initconst = {
+ .product_desc = ST OHCI controller,
+ .extra_priv_size = sizeof(struct st_platform_priv),
+};
+
+static struct usb_ohci_pdata ohci_platform_defaults = {
+ .power_on = st_ohci_platform_power_on,
[PATCH RESEND v5 0/5] Add EHCI and OHCI drivers for STi SoC's
Hi, As part of the RESEND I've rebased this series on top of 3.17-rc3. I believe all feedback has been addressed. The series was re-worked from v2 onwards to split out the ehci and ohci parts into their own drivers / devices like most other ARM platforms based on feedback from Arnd Bergmann (see here http://www.spinics.net/lists/linux-usb/msg24.html. The ehci-platform ohci-platform have been used as a basis for this in case we wish to merge the drivers again in the future. Changes since v4: - Ensure suspend / resume callbacks are wrapped in #ifdef CONFIG_PM_SLEEP as otherwise we will get linker 'unused function' warnings when this option is disabled. - Only declare and reference pm_ops struct if CONFIG_PM_SLEEP is enabled, this saves a few bytes Changes since v3: - Make reset / power, clocks etc non optional dt options to simplify code - Get rid of non DT boot code left over from *hci-platform drivers - Remove DMA mask code - Remove pre_setup func ptr and configure ahb2st bus convertor in ehci_platform_reset - Unabstract and remove usb-st-common.c - Have one kconfig which enables both ehci-st ohci-st drivers Changes since v2: - Based on Arnd Berghman feedback, split out into 2 devices / drivers - Base drivers oh ehci-platform.c ohci-platform.c with required extensions to allow possible re-merge in the furture. Changes since v1: - Correct s/OCHI/OHCI/ spelling - Improve kconfig help message - Various formating / spelling nits identified by Lee Jones - Make driver depend on OF remove node checks in code - Use devm_ioremap_resource - Remove unnecessary header files Peter Griffin (5): usb: host: ehci-st: Add EHCI support for ST STB devices usb: host: ohci-st: Add OHCI driver support for ST STB devices usb: host: ehci-st: Add ehci-st devicetree bindings documentation usb: host: ohci-st: Add ohci-st devicetree bindings documentation MAINTAINERS: Add ehci-st.c and ohci-st.c to ARCH/STI architecture Documentation/devicetree/bindings/usb/ehci-st.txt | 39 +++ Documentation/devicetree/bindings/usb/ohci-st.txt | 37 +++ MAINTAINERS | 2 + drivers/usb/host/Kconfig | 8 + drivers/usb/host/Makefile | 1 + drivers/usb/host/ehci-st.c| 365 ++ drivers/usb/host/ohci-st.c| 339 drivers/usb/host/usb-st-common.h | 31 ++ 8 files changed, 822 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/ehci-st.txt create mode 100644 Documentation/devicetree/bindings/usb/ohci-st.txt create mode 100644 drivers/usb/host/ehci-st.c create mode 100644 drivers/usb/host/ohci-st.c create mode 100644 drivers/usb/host/usb-st-common.h -- 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
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with 2TB HDDs)
On Wed, 3 Sep 2014, James Bottomley wrote:
On Wed, 2014-09-03 at 16:30 -0400, Alan Stern wrote:
On Wed, 3 Sep 2014, James Bottomley wrote:
Before we embark on elaborate hacks, why don't we just make the capacity
writeable (by root) in sysfs from userspace (will require block change)?
We can then encode all the nasty heuristics (including gpt reading) in
userspace as a udev rule.
That's what I'm working on. Except that I don't know where to do it in
the block layer, so for now I'm adding the attribute to sd.c.
Where in the block layer would the right place be? We want this to
apply only to entire devices, not to individual partitions.
The bottom layer for this is part0.nr_sects which is the size attribute
you see in the block sysfs. However, it looks like we keep a separate
value in sdkp, but we don't ever seem to use it (except to see if the
capacity has changed).
So this could be done in two ways: add a writeable capacity attribute in
sd.c, as you were originally thinking (it would call set_capacity() on
write and that would update the block layer) or make the size parameter
writeable.
Here's my patch to the sd driver. It seems to work -- writing to the
capacity_override attribute does change the device size. But then you
have to force the kernel to re-read the partition table manually, for
example by running
blockdev --rereadpt /dev/sdX
because I couldn't see any reasonable way to make this happen
automatically.
Alan Stern
Index: usb-3.17/drivers/scsi/sd.h
===
--- usb-3.17.orig/drivers/scsi/sd.h
+++ usb-3.17/drivers/scsi/sd.h
@@ -66,6 +66,7 @@ struct scsi_disk {
struct gendisk *disk;
atomic_topeners;
sector_tcapacity; /* size in 512-byte sectors */
+ sector_tcapacity_override; /* in native-size blocks */
u32 max_xfer_blocks;
u32 max_ws_blocks;
u32 max_unmap_blocks;
Index: usb-3.17/drivers/scsi/sd.c
===
--- usb-3.17.orig/drivers/scsi/sd.c
+++ usb-3.17/drivers/scsi/sd.c
@@ -477,6 +477,38 @@ max_write_same_blocks_store(struct devic
}
static DEVICE_ATTR_RW(max_write_same_blocks);
+static ssize_t
+capacity_override_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct scsi_disk *sdkp = to_scsi_disk(dev);
+
+ return sprintf(buf, %llu\n,
+ (unsigned long long) sdkp-capacity_override);
+}
+
+static ssize_t
+capacity_override_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct scsi_disk *sdkp = to_scsi_disk(dev);
+ unsigned long long cap;
+ int err;
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EACCES;
+
+ err = kstrtoull(buf, 10, cap);
+ if (err)
+ return err;
+
+ sdkp-capacity_override = cap;
+ revalidate_disk(sdkp-disk);
+
+ return count;
+}
+static DEVICE_ATTR_RW(capacity_override);
+
static struct attribute *sd_disk_attrs[] = {
dev_attr_cache_type.attr,
dev_attr_FUA.attr,
@@ -489,6 +521,7 @@ static struct attribute *sd_disk_attrs[]
dev_attr_provisioning_mode.attr,
dev_attr_max_write_same_blocks.attr,
dev_attr_max_medium_access_timeouts.attr,
+ dev_attr_capacity_override.attr,
NULL,
};
ATTRIBUTE_GROUPS(sd_disk);
@@ -2158,6 +2191,13 @@ sd_read_capacity(struct scsi_disk *sdkp,
struct scsi_device *sdp = sdkp-device;
sector_t old_capacity = sdkp-capacity;
+ /* Did the user override the reported capacity? */
+ if (!sdkp-first_scan sdkp-capacity_override) {
+ sector_size = sdkp-device-sector_size;
+ sdkp-capacity = sdkp-capacity_override;
+ goto got_data;
+ }
+
if (sd_try_rc16_first(sdp)) {
sector_size = read_capacity_16(sdkp, sdp, buffer);
if (sector_size == -EOVERFLOW)
--
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 v7 2/2] usb: gadget: f_fs: virtual endpoint address mapping
On Thu, Sep 04, 2014 at 08:32:18AM +0200, Robert Baldyga wrote: This patch introduces virtual endpoint address mapping. It separates function logic form physical endpoint addresses making it more hardware independent. Following modifications changes user space API, so to enable them user have to switch on the FUNCTIONFS_VIRTUAL_ADDR flag in descriptors. Endpoints are now refered using virtual endpoint addresses chosen by user in endpoint descpriptors. This applies to each context when endpoint address can be used: - when accessing endpoint files in FunctionFS filesystemi (in file name), - in setup requests directed to specific endpoint (in wIndex field), - in descriptors returned by FUNCTIONFS_ENDPOINT_DESC ioctl. In endpoint file names the endpoint address number is formatted as double-digit hexadecimal value (ep%02x) which has few advantages - it is easy to parse, allows to easly recognize endpoint direction basing on its name (IN endpoint number starts with digit 8, and OUT with 0) which can be useful for debugging purpose, and it makes easier to introduce further features allowing to use each endpoint number in both directions to have more endpoints available for function if hardware supports this (for example we could have ep01 which is endpoint 1 with OUT direction, and ep81 which is endpoint 1 with IN direction). Physical endpoint address can be still obtained using ioctl named FUNCTIONFS_ENDPOINT_REVMAP, but now it's not neccesary to handle USB transactions properly. Signed-off-by: Robert Baldyga r.bald...@samsung.com Acked-by: Michal Nazarewicz min...@mina86.com this one does't apply to my testing/next. Can you please rebase ? -- balbi signature.asc Description: Digital signature
Re: [PATCH RESEND v5 1/5] usb: host: ehci-st: Add EHCI support for ST STB devices
On Friday 05 September 2014 18:23:45 Peter Griffin wrote:
+struct st_platform_priv {
+ struct clk *clks[USB_MAX_CLKS];
+ struct clk *clk48;
+ struct reset_control *rst;
+ struct reset_control *pwr;
+ struct phy *phy;
+};
Any reason why this is in a shared header file? It looks like
duplicating the structure under two different names would
actually be shorter and keep the drivers more readable as they'd
be self-contained, even when they have the exact same structure.
Do both drivers use all fields?
Arnd
--
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 v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
On Thu, Sep 04, 2014 at 12:01:19PM +0530, Vivek Gautam wrote: Don't we have phy_power_on() for that ? It looks like you could just as well do this from phy_power_on() ? No, unfortunately keeping these calibration settings in phy_power_on() doesn't help, since we need to do this after XHCI reset has happened. teach xHCI about PHYs ? -- balbi signature.asc Description: Digital signature
Re: [PATCH RESEND v5 1/5] usb: host: ehci-st: Add EHCI support for ST STB devices
Hi Arnd,
On Fri, 05 Sep 2014, Arnd Bergmann wrote:
On Friday 05 September 2014 18:23:45 Peter Griffin wrote:
+struct st_platform_priv {
+ struct clk *clks[USB_MAX_CLKS];
+ struct clk *clk48;
+ struct reset_control *rst;
+ struct reset_control *pwr;
+ struct phy *phy;
+};
Any reason why this is in a shared header file? It looks like
duplicating the structure under two different names would
actually be shorter and keep the drivers more readable as they'd
be self-contained, even when they have the exact same structure.
The only reason was it was a identical structure so I put it in a shared
header file. I can unabstract it if you want?
Do both drivers use all fields?
Yes they are. I thought the 48Mhz clock would only be used by ohci, but
annoyingly it also
clocks the reset logic of the ehci block as well.
regards,
Peter.
--
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 1/4] usb: dwc3: move all string helper functions to debug.h
From: Felipe Balbi [mailto:ba...@ti.com]
Sent: Friday, September 05, 2014 7:56 AM
Those functions are only using within debugging
messages, grouping them into debug.h makes sense.
While at that, also add missing multiple inclusion
guard.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/debug.h | 164
+-
drivers/usb/dwc3/ep0.c| 1 +
drivers/usb/dwc3/gadget.c | 89 +
drivers/usb/dwc3/gadget.h | 56
4 files changed, 165 insertions(+), 145 deletions(-)
diff --git a/drivers/usb/dwc3/debug.h b/drivers/usb/dwc3/debug.h
index fceb39d..e35a3d1 100644
--- a/drivers/usb/dwc3/debug.h
+++ b/drivers/usb/dwc3/debug.h
@@ -16,8 +16,170 @@
* GNU General Public License for more details.
*/
+#ifndef __DWC3_DEBUG_H
+#define __DWC3_DEBUG_H
+
#include core.h
+/**
+ * dwc3_gadget_ep_cmd_string - returns endpoint command string
+ * @cmd: command code
+ */
+static inline const char *
+dwc3_gadget_ep_cmd_string(u8 cmd)
+{
+ switch (cmd) {
+ case DWC3_DEPCMD_DEPSTARTCFG:
+ return Start New Configuration;
+ case DWC3_DEPCMD_ENDTRANSFER:
+ return End Transfer;
+ case DWC3_DEPCMD_UPDATETRANSFER:
+ return Update Transfer;
+ case DWC3_DEPCMD_STARTTRANSFER:
+ return Start Transfer;
+ case DWC3_DEPCMD_CLEARSTALL:
+ return Clear Stall;
+ case DWC3_DEPCMD_SETSTALL:
+ return Set Stall;
+ case DWC3_DEPCMD_GETEPSTATE:
+ return Get Endpoint State;
+ case DWC3_DEPCMD_SETTRANSFRESOURCE:
+ return Set Endpoint Transfer Resource;
+ case DWC3_DEPCMD_SETEPCONFIG:
+ return Set Endpoint Configuration;
+ default:
+ return UNKNOWN command;
+ }
+}
+
+/**
+ * dwc3_gadget_generic_cmd_string - returns generic command string
+ * @cmd: command code
+ */
+static inline const char *
+dwc3_gadget_generic_cmd_string(u8 cmd)
+{
+ switch (cmd) {
+ case DWC3_DGCMD_SET_LMP:
+ return Set LMP;
+ case DWC3_DGCMD_SET_PERIODIC_PAR:
+ return Set Periodic Parameters;
+ case DWC3_DGCMD_XMIT_FUNCTION:
+ return Transmit Function Wake Device Notification;
+ case DWC3_DGCMD_SET_SCRATCHPAD_ADDR_LO:
+ return Set Scratchpad Buffer Array Address Lo;
+ case DWC3_DGCMD_SET_SCRATCHPAD_ADDR_HI:
+ return Set Scratchpad Buffer Array Address Hi;
+ case DWC3_DGCMD_SELECTED_FIFO_FLUSH:
+ return Selected FIFO Flush;
+ case DWC3_DGCMD_ALL_FIFO_FLUSH:
+ return All FIFO Flush;
+ case DWC3_DGCMD_SET_ENDPOINT_NRDY:
+ return Set Endpoint NRDY;
+ case DWC3_DGCMD_RUN_SOC_BUS_LOOPBACK:
+ return Run SoC Bus Loopback Test;
+ default:
+ return UNKNOWN;
+ }
+}
+
+/**
+ * dwc3_gadget_link_string - returns link name
+ * @link_state: link state code
+ */
+static inline const char *
+dwc3_gadget_link_string(enum dwc3_link_state link_state)
+{
+ switch (link_state) {
+ case DWC3_LINK_STATE_U0:
+ return U0;
+ case DWC3_LINK_STATE_U1:
+ return U1;
+ case DWC3_LINK_STATE_U2:
+ return U2;
+ case DWC3_LINK_STATE_U3:
+ return U3;
+ case DWC3_LINK_STATE_SS_DIS:
+ return SS.Disabled;
+ case DWC3_LINK_STATE_RX_DET:
+ return RX.Detect;
+ case DWC3_LINK_STATE_SS_INACT:
+ return SS.Inactive;
+ case DWC3_LINK_STATE_POLL:
+ return Polling;
+ case DWC3_LINK_STATE_RECOV:
+ return Recovery;
+ case DWC3_LINK_STATE_HRESET:
+ return Hot Reset;
+ case DWC3_LINK_STATE_CMPLY:
+ return Compliance;
+ case DWC3_LINK_STATE_LPBK:
+ return Loopback;
+ case DWC3_LINK_STATE_RESET:
+ return Reset;
+ case DWC3_LINK_STATE_RESUME:
+ return Resume;
+ default:
+ return UNKNOWN link state\n;
+ }
+}
+
+/**
+ * dwc3_gadget_event_string - returns event name
+ * @event: the event code
+ */
+static inline const char *dwc3_gadget_event_string(u8 event)
+{
+ switch (event) {
+ case DWC3_DEVICE_EVENT_DISCONNECT:
+ return Disconnect;
+ case DWC3_DEVICE_EVENT_RESET:
+ return Reset;
+ case DWC3_DEVICE_EVENT_CONNECT_DONE:
+ return Connection Done;
+ case DWC3_DEVICE_EVENT_LINK_STATUS_CHANGE:
+ return Link Status Change;
+ case DWC3_DEVICE_EVENT_WAKEUP:
+ return WakeUp;
+ case DWC3_DEVICE_EVENT_EOPF:
+ return End-Of-Frame;
+ case DWC3_DEVICE_EVENT_SOF:
+ return Start-Of-Frame;
+ case DWC3_DEVICE_EVENT_ERRATIC_ERROR:
+ return Erratic Error;
+ case DWC3_DEVICE_EVENT_CMD_CMPL:
+
Re: [PATCH RESEND v5 1/5] usb: host: ehci-st: Add EHCI support for ST STB devices
On Friday 05 September 2014 19:16:36 Peter Griffin wrote:
On Fri, 05 Sep 2014, Arnd Bergmann wrote:
On Friday 05 September 2014 18:23:45 Peter Griffin wrote:
+struct st_platform_priv {
+ struct clk *clks[USB_MAX_CLKS];
+ struct clk *clk48;
+ struct reset_control *rst;
+ struct reset_control *pwr;
+ struct phy *phy;
+};
Any reason why this is in a shared header file? It looks like
duplicating the structure under two different names would
actually be shorter and keep the drivers more readable as they'd
be self-contained, even when they have the exact same structure.
The only reason was it was a identical structure so I put it in a shared
header file. I can unabstract it if you want?
Yes, I think that would be an improvement. Everything looks great to me
otherwise, at least after a brief look.
Arnd
--
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 1/4] usb: dwc3: move all string helper functions to debug.h
Hi,
On Fri, Sep 05, 2014 at 06:23:24PM +, Paul Zimmerman wrote:
+static inline const char *dwc3_ep_event_string(u8 event)
+{
+ switch (event) {
+ case DWC3_DEPEVT_XFERCOMPLETE:
+ return Transfer Complete;
+ case DWC3_DEPEVT_XFERINPROGRESS:
+ return Transfer In-Progress;
+ case DWC3_DEPEVT_XFERNOTREADY:
+ return Transfer Not Ready;
+ case DWC3_DEPEVT_RXTXFIFOEVT:
+ return FIFO;
+ case DWC3_DEPEVT_STREAMEVT:
+ return Stream;
+ case DWC3_DEPEVT_EPCMDCMPLT:
+ return Endpoint Command Complete;
+ }
+
+ return UNKNOWN;
+}
Just curious - did you check the size of the compiled code after this
change? Since these functions are all inline now, it seems like the
compiler would be within its rights to duplicate the strings at each
of the call sites. Hopefully GCC is smarter than that, but you never
know...
Before:
textdata bss dec hex filename
7559 160 877271e2f drivers/usb/dwc3/core.o
9875 0 098752693 drivers/usb/dwc3/debugfs.o
467852051 8 48844becc drivers/usb/dwc3/dwc3.o
7329 722 080511f73 drivers/usb/dwc3/ep0.o
214881169 0 226575881 drivers/usb/dwc3/gadget.o
534 0 0 534 216 drivers/usb/dwc3/host.o
After:
textdata bss dec hex filename
7559 160 877271e2f drivers/usb/dwc3/core.o
9875 0 098752693 drivers/usb/dwc3/debugfs.o
467852051 8 48844becc drivers/usb/dwc3/dwc3.o
7329 722 080511f73 drivers/usb/dwc3/ep0.o
214881169 0 226575881 drivers/usb/dwc3/gadget.o
534 0 0 534 216 drivers/usb/dwc3/host.o
Even if there was a difference, these little guys are only used when
you have either debug or trace enabled, so you're already dealing with a
development environment and the concerns which minimal there.
cheers
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v5] phy: Renesas R-Car Gen2 PHY driver
Hello.
On 08/20/2014 06:42 PM, Kishon Vijay Abraham I wrote:
Sorry for the delayed reply, I was busy in other kernel areas. Should have
replied yesterday though...
[...]
Index: linux-phy/drivers/phy/phy-rcar-gen2.c
===
--- /dev/null
+++ linux-phy/drivers/phy/phy-rcar-gen2.c
@@ -0,0 +1,341 @@
+/*
+ * Renesas R-Car Gen2 PHY driver
+ *
+ * Copyright (C) 2014 Renesas Solutions Corp.
+ * Copyright (C) 2014 Cogent Embedded, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/io.h
+#include linux/module.h
+#include linux/of.h
+#include linux/phy/phy.h
+#include linux/platform_device.h
+#include linux/spinlock.h
+
+#include asm/cmpxchg.h
+
+#define USBHS_LPSTS0x02
+#define USBHS_UGCTRL 0x80
+#define USBHS_UGCTRL2 0x84
+#define USBHS_UGSTS0x88/* The manuals have 0x90 */
+
+/* Low Power Status register (LPSTS) */
+#define USBHS_LPSTS_SUSPM 0x4000
+
+/* USB General control register (UGCTRL) */
+#define USBHS_UGCTRL_CONNECT 0x0004
+#define USBHS_UGCTRL_PLLRESET 0x0001
+
+/* USB General control register 2 (UGCTRL2) */
+#define USBHS_UGCTRL2_USB2SEL 0x8000
+#define USBHS_UGCTRL2_USB2SEL_PCI 0x
+#define USBHS_UGCTRL2_USB2SEL_USB300x8000
+#define USBHS_UGCTRL2_USB0SEL 0x0030
+#define USBHS_UGCTRL2_USB0SEL_PCI 0x0010
+#define USBHS_UGCTRL2_USB0SEL_HS_USB 0x0030
+
+/* USB General status register (UGSTS) */
+#define USBHS_UGSTS_LOCK 0x0300 /* The manuals have 0x3 */
+
+#define PHYS_PER_CHANNEL 2
+
+struct rcar_gen2_phy {
+ struct phy *phy;
+ struct rcar_gen2_channel *channel;
+ int number;
+ u32 select_value;
+};
+
+struct rcar_gen2_channel {
+ struct device_node *of_node;
+ struct rcar_gen2_phy_driver *drv;
+ struct rcar_gen2_phy phys[PHYS_PER_CHANNEL];
+ int selected_phy;
+ u32 select_mask;
+};
+
+struct rcar_gen2_phy_driver {
+ void __iomem *base;
+ struct clk *clk;
+ spinlock_t lock;
+ int num_channels;
+ struct rcar_gen2_channel *channels;
+};
+
+static int rcar_gen2_phy_init(struct phy *p)
+{
+ struct rcar_gen2_phy *phy = phy_get_drvdata(p);
+ struct rcar_gen2_channel *channel = phy-channel;
+ struct rcar_gen2_phy_driver *drv = channel-drv;
+ unsigned long flags;
+ u32 ugctrl2;
+
+ /*
+* Try to acquire exclusive access to PHY. The first driver calling
+* phy_init() on a given channel wins, and all attempts to use another
+* PHY on this channel will fail until phy_exit() is called by the first
+* driver. Achieving this with cmpxcgh() should be SMP-safe.
+*/
+ if (cmpxchg(channel-selected_phy, -1, phy-number) != -1)
+ return -EBUSY;
This should be done in phy_get no?
No, if you mean the of_xlate() method: I need a place to release the lock
which I wouldn't have in this case.
If you mean modifying _of_phy_get(), it has no notion of channels and
probably shouldn't have since the channels are a special case for this driver
(and maybe some others) ...
Can we add this in phy-core? There might be other users who want to have
exclusive access within the same phy provider.
The exclusive access is not within the provider in my case, it's within a
channel (each of which has a corresponding DT subnode), so I don't think it's
well representable in the phy-core. I'm not using your suggested
subnode-per-PHY representation since it doesn't really fit my case well...
Rest of it looks fine to me.
Thanks.
Thanks
Kishon
WBR, Sergei
--
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 v3 0/2] r8152: random MAC address
From: Hayes Wang hayesw...@realtek.com Date: Thu, 4 Sep 2014 16:15:40 +0800 If the interface has invalid MAC address, it couldn't be used. In order to let it work normally, give a random one. v3: Remove ether_addr_copy(dev-perm_addr, dev-dev_addr); v2: Use %pM format specifier for printing a MAC address. Series applied, thanks. -- 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 0/1] for HID core dot c
Hi, You're almost there. You may specifically want to read section 1.15. Also have a look at how other people submit their patches. Using git send-email[1] may also help. It's also the custom to reply to all, instead of just to the mailing list. Thanks, Frans [1] http://git-scm.com/docs/git-send-email On Fri, Sep 5, 2014 at 4:30 PM, Hans Petter Selasky h...@selasky.org wrote: Hi, Looks like the first argument for MODULE_PARAM_DESC() is incorrect. --HPS commit 862e8673263b82652b5738ccda4f8367959fa234 Author: Hans Petter Selasky h...@selasky.org Date: Fri Sep 5 11:07:15 2014 +0200 Correct argument for Module parameter description. Signed-off-by: Hans Petter Selasky h...@selasky.org diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c index 12b6e67..1956c72 100644 --- a/drivers/hid/hid-core.c +++ b/drivers/hid/hid-core.c @@ -52,7 +52,7 @@ EXPORT_SYMBOL_GPL(hid_debug); static int hid_ignore_special_drivers = 0; module_param_named(ignore_special_drivers, hid_ignore_special_drivers, int, 0600); -MODULE_PARM_DESC(debug, Ignore any special drivers and handle all devices by generic driver); +MODULE_PARM_DESC(ignore_special_drivers, Ignore any special drivers and handle all devices by generic driver); /* * Register a new report for a device. -- 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 -- 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: [rfc]your patch to deal with devices that need continous data traffic
On Fri, Sep 05, 2014 at 01:07:11PM +0200, Oliver Neukum wrote:
On Fri, 2014-09-05 at 12:15 +0200, Johan Hovold wrote:
On Fri, Sep 05, 2014 at 11:05:46AM +0200, Oliver Neukum wrote:
on second thought I think that your moving of remote_wakeup is not good.
If we'd discard input anyway, we don't need to wake up devices for them.
I'm afraid we have to. The ELAN touchscreen disconnects when an input
event occurs while suspended unless remote wakeup is enabled.
I see. This device sucks in a terrible way. In principle we'd now need
a special flag for port power off. Otherwise we can never send the HC
in your laptop to D3cold. Is the small class of devices worth it?
Good point. I personally don't care about the touchscreen and could
live with a disconnect if anyone tries to put fingerprints on my screen.
In fact, when debugging this I did find a less intrusive way to solve
only the major problem with the device, which is the repeated
disconnects. Simply polling the interrupt endpoint for a short time
during start seems to make the device happy. But any input thereafter,
whether suspended or not, would then cause a disconnect.
Out of curiosity, how does your quirky device work with something like
the below? (Patch is generated on top of the always-poll quirk patch.)
This adds a 500ms timeout during probe, and I believe I couldn't reduce
that much further for this particular device if I remember correctly.
Johan
From 5ea1eab0fa0c57075afb09d428f76a0aba478630 Mon Sep 17 00:00:00 2001
From: Johan Hovold jo...@kernel.org
Date: Fri, 5 Sep 2014 21:48:03 +0200
Subject: [PATCH] HID: usbhid: add hard-coded poll-once quirk
Make sure to poll the interrupt endpoint during start.
This is needed for devices that disconnects from the bus unless the
interrupt endpoint is polled shortly after enumeration.
Note that such a quirky device could still disconnect on any later input
events, but this at least prevents repeated disconnects and
re-enumerations.
Signed-off-by: Johan Hovold jo...@kernel.org
---
drivers/hid/usbhid/hid-core.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index d8b6976..47bf378 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -1045,6 +1045,21 @@ err:
return ret;
}
+static void usbhid_poll_once(struct usbhid_device *uhid)
+{
+ struct device *dev = uhid-urbin-dev-dev;
+ struct urb *urb = uhid-urbin;
+ int len = -1;
+ int ret = -1;
+
+ dev_info(dev, %s\n, __func__);
+
+ ret = usb_interrupt_msg(urb-dev, urb-pipe, urb-transfer_buffer,
+ urb-transfer_buffer_length, len, 500);
+
+ dev_info(dev, %s - ret = %d, len = %d\n, __func__, ret, len);
+}
+
static int usbhid_start(struct hid_device *hid)
{
struct usb_interface *intf = to_usb_interface(hid-dev.parent);
@@ -1150,6 +1165,9 @@ static int usbhid_start(struct hid_device *hid)
usb_autopm_put_interface(usbhid-intf);
}
+ if (usbhid-urbin)
+ usbhid_poll_once(usbhid);
+
/* Some keyboards don't work until their LEDs have been set.
* Since BIOSes do set the LEDs, it must be safe for any device
* that supports the keyboard boot protocol.
--
1.8.5.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] Correct argument for Module parameter description.
Signed-off-by: Hans Petter Selasky h...@selasky.org --- drivers/hid/hid-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c index 12b6e67..1956c72 100644 --- a/drivers/hid/hid-core.c +++ b/drivers/hid/hid-core.c @@ -52,7 +52,7 @@ EXPORT_SYMBOL_GPL(hid_debug); static int hid_ignore_special_drivers = 0; module_param_named(ignore_special_drivers, hid_ignore_special_drivers, int, 0600); -MODULE_PARM_DESC(debug, Ignore any special drivers and handle all devices by generic driver); +MODULE_PARM_DESC(ignore_special_drivers, Ignore any special drivers and handle all devices by generic driver); /* * Register a new report for a device. -- 1.8.2.3 -- 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 0/1] for HID core dot c
On Fri, Sep 05, 2014 at 04:30:27PM +0200, Hans Petter Selasky wrote: Hi, Looks like the first argument for MODULE_PARAM_DESC() is incorrect. --HPS commit 862e8673263b82652b5738ccda4f8367959fa234 Author: Hans Petter Selasky h...@selasky.org Date: Fri Sep 5 11:07:15 2014 +0200 Correct argument for Module parameter description. Signed-off-by: Hans Petter Selasky h...@selasky.org diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c index 12b6e67..1956c72 100644 --- a/drivers/hid/hid-core.c Please use scripts/get_maintainer.pl to determine who and what mailing lists to send a patch to so that the right maintainer(s) get the patch. 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: RCU bug with v3.17-rc3 ?
On Thu, Sep 04, 2014 at 03:04:03PM -0500, Felipe Balbi wrote: Hi, On Thu, Sep 04, 2014 at 02:25:35PM -0500, Felipe Balbi wrote: On Thu, Sep 04, 2014 at 12:16:42PM -0700, Paul E. McKenney wrote: On Thu, Sep 04, 2014 at 01:40:21PM -0500, Felipe Balbi wrote: Hi, I keep triggering the following Oops with -rc3 when writing to the mass storage gadget driver: v3.17-rc3, correct? yup, as in subject ;-) I take it that the test passes on some earlier version? about to test v3.14.17. coudln't get v3.14 working on this board but at least v3.16 is also affected except that on now it happened during boot, I didn't even need to run my test: [ 17.438195] Unable to handle kernel paging request at virtual address [ 17.446109] pgd = ec36 [ 17.448947] [] *pgd=ae7f6821, *pte=, *ppte= [ 17.455639] Internal error: Oops: 17 [#1] SMP ARM [ 17.460578] Modules linked in: dwc3(+) udc_core lis3lv02d_i2c lis3lv02d input_polldev dwc3_omap matrix_keypad [ 17.471060] CPU: 0 PID: 1381 Comm: accounts-daemon Tainted: G W 3.16.0-5-g8a6cdb4 #811 [ 17.480735] task: ed716040 ti: ec026000 task.ti: ec026000 [ 17.486405] PC is at find_get_entry+0x7c/0x128 [ 17.491070] LR is at 0xfffa [ 17.494364] pc : [c0110b4c]lr : [fffa]psr: a013 [ 17.494364] sp : ec027dc8 ip : fp : ec027dfc [ 17.506384] r10: c0c6f6bc r9 : 0005 r8 : ecdf22f8 [ 17.511860] r7 : ec026008 r6 : 0001 r5 : r4 : [ 17.518705] r3 : ec027db4 r2 : r1 : 0005 r0 : [ 17.525526] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 17.533007] Control: 10c5387d Table: ac360059 DAC: 0015 [ 17.539020] Process accounts-daemon (pid: 1381, stack limit = 0xec026248) [ 17.546151] Stack: (0xec027dc8 to 0xec028000) [ 17.550710] 7dc0: c0110ad0 ecdf0b80 ecdf22f4 [ 17.559259] 7de0: ecdf22f4 0005 ec027e34 ec027e00 c0111874 c0110adc [ 17.567824] 7e00: ecdf0b80 c03565b4 ed7165f8 ec3dddf0 ecdf22f4 0005 ec3ddd00 0001 [ 17.576385] 7e20: ecdf21a0 ec027ebc ec027e38 c0112978 c0111844 c06af938 [ 17.584950] 7e40: ecdf0b70 ecdf0b70 ec027e6c ec027e58 0005 0006 0b80 ecdf0b70 [ 17.593514] 7e60: c0163264 ec3dddf0 ec027ee8 ec027ed4 0b80 ec027eac ec027e88 [ 17.602087] 7e80: c0178d98 c0356590 0002 5b80 ec027f78 [ 17.610653] 7ea0: ec3ddd00 ed716040 b6cab018 ec027f44 ec027ec0 c0163264 c0112780 [ 17.619202] 7ec0: 0180 0180 ec027efc b6cab018 0180 0180 [ 17.627772] 7ee0: ec027ecc 0001 ec3ddd00 ed716040 [ 17.636371] 7f00: 5b80 0180 [ 17.644946] 7f20: b6cab018 ec3ddd00 b6cab018 ec027f78 ec3ddd00 0180 ec027f74 ec027f48 [ 17.653524] 7f40: c0163a6c c01631cc b6cab018 5b80 ec3ddd03 ec3ddd00 [ 17.662085] 7f60: 0180 b6cab018 ec027fa4 ec027f78 c0164198 c01639e0 5b80 [ 17.670658] 7f80: be91badc be91ba50 00044a00 0003 c000f044 ec026000 ec027fa8 [ 17.679222] 7fa0: c000edc0 c0164158 be91badc be91ba50 0008 b6cab018 0180 be91ba38 [ 17.687794] 7fc0: be91badc be91ba50 00044a00 0003 be91bbac b6cab008 [ 17.696370] 7fe0: 0020 be91ba40 b6c78e8c b6c78ea8 6010 0008 ae7f6821 ae7f6c21 [ 17.704956] [c0110b4c] (find_get_entry) from [c0111874] (pagecache_get_page+0x3c/0x1f4) [ 17.713687] [c0111874] (pagecache_get_page) from [c0112978] (generic_file_read_iter+0x204/0x794) [ 17.723259] [c0112978] (generic_file_read_iter) from [c0163264] (new_sync_read+0xa4/0xcc) [ 17.732185] [c0163264] (new_sync_read) from [c0163a6c] (vfs_read+0x98/0x158) [ 17.739945] [c0163a6c] (vfs_read) from [c0164198] (SyS_read+0x4c/0xa0) [ 17.747149] [c0164198] (SyS_read) from [c000edc0] (ret_fast_syscall+0x0/0x48) [ 17.754994] Code: e1a01009 eb08ffa9 e350 0a1f (e5904000) [ 17.761476] ---[ end trace 49c4ed35a1c01157 ]--- It seems to be a difficult-to-reproduce race though. On a second boot it didn't die during boot, but died with my USB test case. Unfortunately, the platform I'm using is pretty new and only goes as far back as v3.16 (which I had to backport 11 patches to get it to boot good enough for this test). I wonder if a corrupt file system could cause such problems... I keep seeing EXT4 errors every now and again; considering that this dies in a path through VFS, I wonder... I recall hearing of similar things in the past, but must defer to the FS/VFS experts on this one. Thanx, Paul -- To unsubscribe from this list: send the line
Re: Linux xHCI compartmentalization
On Wed, Sep 03, 2014 at 09:20:28PM +, Gary Cordelli wrote: Sarah: Thank you for all the great work you put into providing the xHCI driver for USB 3.0 host hardware support in Linux. Alas, I am stuck with an installed base of platforms that run a 2.6.29.6 kernel that has just absorbed a whole mess of hardware using a different SBC that has a combination of USB 3.0 and USB 2.0 interfaces (where the installed base has all USB 2.0 interfaces). Ach! After several tweaks to support the different chipset (GPIO driver, SATA driver, HDA audio driver, and USB2.0-to-serial), I discovered that we could not do without using at least one of the USB 3.0 interfaces. In looking at the xHCI driver, however, it appears that its tentacles may reach deep into the bowels of Linux - at least looking at recent kernels. Do you know if there is a kernel release close to the 2.6.29.6 architecture that you would also consider to include a reasonably stable xHCI implementation? I have looked at 2.6.32.5 briefly, but was given information that this experimental xHCI support is not recommended for use. Frankly, it does not have to be a full-featured implementation (since we are only trying to reproduce/replace a USB 2.0 capability), but it would hopefully be a stable implementation (no unexpected crashes). Can you advise? The xHCI driver wasn't really stable for xHCI 1.0 host controllers (integrated hosts like Intel) until the 3.0 kernel. I would recommend installing one of the supported long-term stable kernels like 3.2. But I really can't help you or support you through backporting those drivers from the stable kernel to your ancient 2.6.29.6 kernel. There are far too many changes in the USB core to just do a straight backport of the xHCI driver -- and many of those changes are necessary for full xHCI driver support. If you're on a vanilla stable kernel, the kernel community will happily help you debug it. If not, you're on your own. Gary Cordelli Embedded Computer Engineer Mentor Computer Consulting LLC the embedded computer company Sarah Sharp -- 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: ax88179_178a hang over xhci
On Fri, Sep 05, 2014 at 06:04:19PM +0200, Andrea Arcangeli wrote: On Fri, Sep 05, 2014 at 08:53:59AM +, David Laight wrote: On Wed, Aug 20, 2014 at 04:12:49PM +0200, Andrea Arcangeli wrote: Hi Sarah, just a short followup on this. I still had 1gbps hangs with the 0b95:1790 ASIX Electronics Corp device using xhci. But it seems now stable for the last 12 hours under heavy load after I removed all powersaving features. ... Unless the hardware is broken there's something wrong in xhci or the usbnet driver that makes it hang with my usual stress test I do to check if the networks is reliable. The device driver is ax88179_178a.c There are still some bugs in the xhci ring handling that can affect the ax88179_178a driver+hardware. I needs the fix to ensure that the ring boundaries are aligned with usb packets, otherwise packets can get lost and the tx side can lock up. Ok once fixed feel free to CC me so I can test it. Andrea, Dan Williams has a set of patches that should resolve this issue, please test these: http://marc.info/?l=linux-usbm=140872773111261w=2 I'm running ax88179_178a in two places without apparent problems, interestingly I didn't reproduce more lockups after turning off the powersave feature. The only catch is that the xhci hang is not easily reproducible... Which powersave feature? One more thing worth mentioning, I had to disable tx/rx checksum in hardware (enabled by default) with ethtool or it wouldn't resume from RAM but that was a black and white issue, the only real annoyance was the occasional xhci hang that requires rmmod xhci_hcd to recover from. What do you mean by hang? Do other USB devices work under xhci (e.g. mouse and keyboard) but the ethernet stops working? Or all USB devices under xHCI stop working? Or the xHCI driver causes a kernel oops? What's the failure mode? Sarah Sharp -- 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: [RFC PATCH 0/7] usb: gadget: add reset API at usb_gadget_driver
On Fri, Sep 05, 2014 at 08:44:08AM +0800, Peter Chen wrote: On Thu, Sep 04, 2014 at 11:04:38AM -0400, Alan Stern wrote: On Thu, 4 Sep 2014, Peter Chen wrote: Hi Felipe Alan, how about using below steps for this reset/vbus/pullup changes? It mainly uses Alan's suggestion. Step 1: The initial implementation in the four gadget drivers can be very simple: It calls the disconnect handler. the -reset is mandatory for all gadget drivers (currently, only four, they are composite, configfs, gadgetfs , dbgp. Step 2: Add routines to udc-core to handle Vbus changes, function activation changes, and resets. It will include three sub-steps, from easy to hard: reset handler, vbus handler, and activation handler. Perhaps the activation handler can be delayed until step 4. It won't get used until composite.c is modified to call it. Step 3: Modify all UDCs to call udc-core's reset and vbus handler, delete usb_gadget_connect/usb_gadget_disconnect operation at all UDC drivers, and delete invoking usb_gadget_connect unconditional at udc_bind_to_driver Step 4: Modify the composite.c to disable pullup for adding every function, and enable pullup when necessary. Actually, composite.c should be modified to call the activation handler in udc-core, and then _that_ routine would adjust the pullup as necessary. This plan is okay with me. OK, let's put the function activation change to the last. If the Felipe has no other comments, I will send the patch for step one next Monday. Please do, the thread already has too much information and we better put all that in code. Keep in mind that me and Alan have resurected an old patchset adding -reset() callback to the gadget framework. If you want to take a look it's at [1] https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/log/?h=gadget-add- reset-method Thanks, Felipe. It still takes gadget driver's -reset as optional, but we want to take it as mandatory per our discussion. Peter -- 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
