Re: Fwd: Status of chipidea msm USB reset patch
On Fri, 2014-08-15 at 08:23 +0800, Peter Chen wrote: > On Thu, Aug 14, 2014 at 11:54:02AM -0500, Felipe Balbi wrote: > > Hi, > > > > On Thu, Aug 14, 2014 at 09:53:10AM -0700, Tim Bird wrote: > > > Ping. Anybody know the status of this patch? Is it queued in someone's > > > tree? > > > Without it the USB driver for the Qualcomm 8974 (hsusb phy) doesn't > > > work (at least for me). > > > It looks like it got dropped from Ivan's original patch series, back in > > > May. > > > > I don't maintain chipidea, Peter's the guy you want > > Below patch was not at msm chipidea patchset Ivan sent me. > > http://markmail.org/search/?q=%5BPATCH+v4+0%2F3%5D+usb%3A+chipidea%3A+msm%3A+Clean+and+fix+#query:%5BPATCH%20v4%200%2F3%5D%20usb%3A%20chipidea%3A%20msm%3A%20Clean%20and%20fix%20from%3A%22Ivan%20T.%20Ivanov%22+page:1+mid:mt7hgr7yamyzegg3+state:results > My fault. I have waiting PHY patches to be accepted to send this one. Will rebase and resend. Ivan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] kconfig/symbol.c: handle choice_values that depend on 'm' symbols
Bin Liu writes:
> Dirk,
>
> On Thu, Aug 14, 2014 at 1:52 AM, Dirk Gouders wrote:
>> Bin Liu writes:
>>
>>> All,
>>>
>>> On Mon, Nov 18, 2013 at 12:08 PM, Yann E. MORIN
>>> wrote:
Dirk, All,
On 2013-11-07 15:05 +0100, Dirk Gouders spake thusly:
> If choices consist of choice_values that depend on symbols set to 'm',
> those choice_values are not set to 'n' if the choice is changed from
> 'm' to 'y' (in which case only one active choice_value is allowed).
> Those values are also written to the config file causing modules to be
> built when they should not.
>
> The following config can be used to reproduce and examine the problem;
> with the frontend of your choice set "Choice 0" and "Choice 1" to 'm',
> then set "Tristate Choice" to 'y' and save the configuration:
>
> config modules
> boolean modules
> default y
> option modules
>
> config dependency
> tristate "Dependency"
> default m
>
> choice
> prompt "Tristate Choice"
> default choice0
>
> config choice0
> tristate "Choice 0"
>
> config choice1
> tristate "Choice 1"
> depends on dependency
>
> endchoice
>
> This patch sets choice_values' visibility that depend on symbols set
> to 'm' to 'n' if the corresponding choice is set to 'y'. This makes
> them disappear from the choice list and will also cause the
> choice_values' value set to 'n' in sym_calc_value() and as a result
> they are written as "not set" to the resulting .config file.
>
> Reported-by: Sebastian Andrzej Siewior
> Signed-off-by: Dirk Gouders
> Tested-by: Sebastian Andrzej Siewior
Acked-by: "Yann E. MORIN"
It will be in my tree soon. Thanks!
>>>
>>> I don't see this patch in 3.16 but 3.16 does not have the issue any
>>> more. Anyone has an idea how the issue got fixed? I am trying to find
>>> the right patch to backport.
>>
>> With the above sample kconfig I still see the issue. How did you
>> notice the issue got fixed?
>
> I did not pay much attention on the above sample kconfig, but just
> focused on the USB gadget driver kconfig issue initially reported by
> Sebastian. I saw the issue exists in 3.14, but does not in 3.16,
> unless I messed up with my test. I will test 3.16 again some time next
> week.
Hi Bin,
I now also re-tested the initially reported steps to reproduce the
issue:
> in USB gadget menu (that is Device Drivers ---> USB support ---> USB
> Gadget Support ---> USB Gadget Drivers) I can create a configuration
> which is "lost". Here is how to reproduce it:
>
> - first config two gadgets as M:
> USB Gadget Drivers
> Audio Gadget
> Ethernet Gadget
> MIDI Gadget
>
> save config & leave
>
> - now start menu config again and go to the same menu, now select
> built-in:
> <*> USB Gadget Drivers (Ethernet Gadget
> the ethernet gadget is chosen automatically because we can have only
> one gadget selected.
> save config & leave
>
> - step three, go back to the menu and you will see that everything is
> as it was (the <*> is ignored).
Here, I still see the problem (I was wondering if the issue has been
solved/gone by a kconfig-file modification).
Perhaps, Sebastian could check if the problem, he reported still exists...
Dirk
>
> Regards,
> -Bin.
>
>>
>> Dirk
>>
>>>
>>> Thanks,
>>> -Bin.
>>>
Regards,
Yann E. MORIN.
> ---
> scripts/kconfig/symbol.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
> index c9a6775..06d96c9 100644
> --- a/scripts/kconfig/symbol.c
> +++ b/scripts/kconfig/symbol.c
> @@ -189,12 +189,23 @@ static void sym_validate_range(struct symbol *sym)
> static void sym_calc_visibility(struct symbol *sym)
> {
> struct property *prop;
> + struct symbol *choice_sym = NULL;
> tristate tri;
>
> /* any prompt visible? */
> tri = no;
> +
> + if (sym_is_choice_value(sym))
> + choice_sym = prop_get_symbol(sym_get_choice_prop(sym));
> +
> for_all_prompts(sym, prop) {
> prop->visible.tri = expr_calc_value(prop->visible.expr);
> + /*
> + * choice_values with visibility 'mod' are not visible if
> the
> + * corresponding choice's value is 'yes'.
> + */
> + if (prop->visible.tri == mod && (choice_sym &&
> choice_sym->curr.tri == yes))
> + prop->visible.tri = no;
> tri = EXPR_OR(tri, prop->visible.tri);
> }
> if (tri == mod && (sym
Re: [PATCH v4] kconfig/symbol.c: handle choice_values that depend on 'm' symbols
On 08/15/2014 09:37 AM, Dirk Gouders wrote: > Here, I still see the problem (I was wondering if the issue has been > solved/gone by a kconfig-file modification). > > Perhaps, Sebastian could check if the problem, he reported still exists... I will re-test tonight and report. I don't see the patch in this thread (and I remeber that it fixed the issue) so I doubt that anything will change but lets see. > > Dirk Sebastian -- 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: Kernel 3.16.0 USB crash
> On Thu, Aug 14, 2014 at 11:46:33AM +0200, Hans de Goede wrote: >> Hi, ... >> >> Can you collect "lsusb -v" output for the drive in question when connected >> through an usb-3 port (the uas module does not need to be loaded). Here lsusb output, full text as attachment Bus 003 Device 003: ID 152d:0567 JMicron Technology Corp. / JMicron USA Technology Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 3.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x152d JMicron Technology Corp. / JMicron USA Technology Corp. idProduct 0x0567 bcdDevice0.00 iManufacturer 10 JMicron iProduct 11 USB to ATA/ATAPI Bridge iSerial 5 152D00539000 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 121 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 1 bNumEndpoints 4 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 98 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Command pipe (0x01) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 MaxStreams 32 Status pipe (0x02) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 MaxStreams 32 Data-in pipe (0x03) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 MaxStreams 32 Data-out pipe (0x04) Binary Object Store Descriptor: bLength 5 bDescriptorType15 wTotalLength 22 bNumDeviceCaps 2 USB 2.0 Extension Device Capability: bLength 7 bDescriptorType16 bDevCapabilityType 2 bmAttributes 0x0002 Link Power Management (LPM) Supported SuperSpeed USB Device Capability: bLength10 bDescriptorType16 bDevCapabilityTy
[PATCH RESEND] usb: chipidea: msm: Use USB PHY API to control PHY state
From: "Ivan T. Ivanov"
PHY drivers keep track of the current state of the hardware,
so don't change PHY settings under it.
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/chipidea/ci_hdrc_msm.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
b/drivers/usb/chipidea/ci_hdrc_msm.c
index d72b9d2..81de834 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -20,13 +20,11 @@
static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
{
struct device *dev = ci->gadget.dev.parent;
- int val;
switch (event) {
case CI_HDRC_CONTROLLER_RESET_EVENT:
dev_dbg(dev, "CI_HDRC_CONTROLLER_RESET_EVENT received\n");
- writel(0, USB_AHBBURST);
- writel(0, USB_AHBMODE);
+ usb_phy_init(ci->transceiver);
break;
case CI_HDRC_CONTROLLER_STOPPED_EVENT:
dev_dbg(dev, "CI_HDRC_CONTROLLER_STOPPED_EVENT received\n");
@@ -34,10 +32,7 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci,
unsigned event)
* Put the transceiver in non-driving mode. Otherwise host
* may not detect soft-disconnection.
*/
- val = usb_phy_io_read(ci->transceiver, ULPI_FUNC_CTRL);
- val &= ~ULPI_FUNC_CTRL_OPMODE_MASK;
- val |= ULPI_FUNC_CTRL_OPMODE_NONDRIVING;
- usb_phy_io_write(ci->transceiver, val, ULPI_FUNC_CTRL);
+ usb_phy_notify_disconnect(ci->transceiver, USB_SPEED_UNKNOWN);
break;
default:
dev_dbg(dev, "unknown ci_hdrc event\n");
--
1.8.3.2
--
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: [Alsa-user] linux does not recognize my midi controller samson carbon 61
On 08/15/2014 12:21 AM, Lion Bino wrote: > I have a problem a midi controller, a Samson Carbon 61. When I connect > via usb, dmesg tells me the following. > > > [ 1480.097123] usb 2-1.1: new full-speed USB device number 9 > using ehci_hcd > [ 1480.118082] usb 2-1.1: no configurations > [ 1480.118087] usb 2-1.1: can't read configurations, error -22 > [ 1480.118206] hub 2-1:1.0: unable to enumerate USB device on > port 1 That's not an ALSA problem, but most probably a firmware bug. A device with bNumConfigurations == 0 is invalid. Copied the linux-usb list. > I use ubuntu 12.04 and 14.04 and nothing, I have tested in windows > and works well. Could you follow the instructions in this document and generate a usbmon trace when connecting the device? I'd like to know whether the entire device descriptor is garbled. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/usb/usbmon.txt Thanks, Daniel -- 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: Transient USB disconnects
> > Have you used a bus analyzer on the wire connected to the parent hub's > > upstream port? If you do, you should be able to see the events leading > > up to a reset. My guess is that they will all look normal until at some > > point the HID device stops responding to packets. Probably the hub > > disconnects from the bus first and that's the reason the responses stop. I've tried to use our USB monitor before, but it is almost impossible to persuade it to trigger on events - the interface is over-complicated and the hardware support probably minimal. Even if you define a correct trigger, getting a 'centered' trace isn't easy. Whoever wrote the monitor software has clearly never tried to debug anything! > > Why does the hub disconnect? I have no idea. > > > > We are checking a similar problem, in our case, change another hub can fix > problem, > add bus analyzer between hub and devices can decrease the failure rate. Yes, I don't think we saw any failures with the USB monitor in the circuit. But the failure rates are so low it is difficult to tell. > You can have some usb devices (eg, usb-serial) at usb-hub, and write some > application to > increase usb bus loading, and try to speed up the reproduce. I've been saturating a 10M ethernet interface (with multiple 60k flood pings). Doesn't really make much difference. I've not tried saturating one of the low speed devices (for which the hub needs to perform split transfers). With all the usb dynamic-debug enabled the first errors I see are 'detected XactErr' len 0/1522 and len 2048/18944 (all 32 retries). Then some '3strikes' messages (75 in total split between the endpoints). I've not yet looked at what those errors actually mean. I'll try connecting the usb analyser but I don't have much hope of capturing anything. 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 PATCH] Revert "usb: chipidea: udc: .pullup is valid only when vbus is there"
> > > This thread seems to have wandered pretty far off-topic. I just wanted > > to make the point that if you create another API function for this > > issue, please be aware that not all controllers/phys will need it or > > be able to support it. In fact, I think this issue is specific to the > > chipidea core, so maybe it just needs a quirk or something? > > I don't think any special treatment will be needed. If a controller/PHY > combination is unable to detect Vbus changes in software then it simply > won't invoke the callback. Things will still work correctly provided the > hardware disables the pullup whenever Vbus is off. All the UDC driver > will need to do is invoke the gadget driver's connect callback once at > the start, and it must be doing that already. > > Peter simply has to do is fix up composite.c and udc-core.c. > udc_bind_to_driver() shouldn't call usb_gadget_connect() automatically, > and composite_driver_template needs to have a .connect callback. Then > composite.c can enable or disable the pullup at appropriate times, based > on function activations and the current connection status. > Thanks, Alan. I will have a patchset for this issue. > (I'm not sure how well this will work with the soft_connect sysfs > attribute in udc-core, though. And that attribute doesn't seem to be > mentioned anywhere under Documentation/ABI.) > I think it may be used to disable gadget function at runtime, Felipe may know it well. 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
test program to check usb hid devices
hi all: Is there any test program we can use to capture input data send from usb keyboard/mouse? I don't need to parsing the binary sent by keyboard/mouse. Just raw data is fine. I checked the Kernel sample, hid-example.c, but it seems only get report and print it out. appreciate your help in advance, -- 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: test program to check usb hid devices
From: loody > Is there any test program we can use to capture input data send from > usb keyboard/mouse? google usbmon David
ftdi_sio: Adding new device by ekey
Hi! I'm working on a student project and have come across a serial converter that works with the ftdi_sio module after feeding it the PID: [ 6606.959890] usb 6-2: new full-speed USB device number 3 using uhci_hcd [ 6607.143722] usb 6-2: New USB device found, idVendor=0403, idProduct=cb08 [ 6607.143727] usb 6-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 6607.143730] usb 6-2: Product: ekey CONVERTER [ 6607.143733] usb 6-2: Manufacturer: ekey biometric systems [ 6607.143735] usb 6-2: SerialNumber: 28090014 echo 0403 cb08 > /sys/bus/usb-serial/drivers/ftdi_sio/new_id [ 7037.231245] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 7037.231316] usb 6-2: Detected FT232BM [ 7037.231320] usb 6-2: Number of endpoints 2 [ 7037.231324] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 7037.231328] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 7037.231331] usb 6-2: Setting MaxPacketSize 64 [ 7037.234688] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 I'll be sending a patch shortly. The module compiles but fingers crossed - it is my first shared patch. :) -- Jaša Bartelj -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 0/5] Add EHCI and OHCI drivers for STi SoC's
The series has been 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
[PATCH 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
---
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 = ;
+ 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 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
---
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 03314f8..4b577f6 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -753,6 +753,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 af89a90..df7e5ac 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -74,3 +74,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
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#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,
+ .power_suspend =st_ohci_platform_power_off,
+ .power_off =st_ohci_platform_power_off,
+};
+
+static int st_ohci_platform_probe(struct platform_device *dev)
+{
+ st
[PATCH v5 5/5] MAINTAINERS: Add ehci-st.c and ohci-st.c to ARCH/STI architecture
Signed-off-by: Peter Griffin --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index c2066f4..89aef87 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1356,6 +1356,8 @@ F:drivers/pinctrl/pinctrl-st.c F: drivers/media/rc/st_rc.c F: drivers/i2c/busses/i2c-st.c F: drivers/tty/serial/st-asc.c +F: drivers/usb/host/ehci-st.c +F: drivers/usb/host/ohci-st.c ARM/TECHNOLOGIC SYSTEMS TS7250 MACHINE SUPPORT M: Lennert Buytenhek -- 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 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
---
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 = ;
+ 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 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
---
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
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#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 *res_mem;
+ struct usb_ehci_pdata *pdata = &ehci_platform_defaults;
+ struct st_platform_priv *priv;
+ struct ehci_hcd *ehci;
+ int err, irq, clk = 0;
+
+ if (usb_disabled())
+
Re: [BUG] usb_dev_resume returns -113 due to work items queued by usb on pm_wq is not executed before suspending.
On Fri, 15 Aug 2014, Du, ChangbinX wrote: > Hi, All, > As described in runtime_pm.txt for pm_wq: > The power management work queue pm_wq in which bus types and device > drivers can put their PM-related work items. It is strongly recommended that > pm_wq be used for queuing all work items related to runtime PM, because > this allows them to be synchronized with system-wide power transitions > (suspend to RAM, hibernation and resume from system sleep states). > > Per my understanding, all runtime PM related works items queued on pm_wq > should be completed before suspend to RAM. So to ensure device state is > runtime active before suspending. Having checked the pm code, I found this is > not true for work items queued by drivers. > > Now usb driver has used this pm_wq to run a work item that resumes root hub > (see function xhci_resume()->usb_hcd_resume_root_hub()). But sometimes > this work is not completed before usb device suspend. That is to say root hub > device may still in runtime suspend state before suspending. And this can > result > in problem. One case is that as below error log shows, > > [ 108.046248] PM: Entering mem sleep > [ 108.050487] Suspending console(s) (use no_console_suspend to debug) > [ 108.426510] active wakeup source: event5-576 > [ 108.426529] PM: Some devices failed to suspend > [ 108.426887] dpm_run_callback(): usb_dev_resume+0x0/0x20 returns -113 > [ 108.426918] PM: Device 1-2 failed to resume async: error -113 > [ 108.428299] PM: resume of devices complete after 1.755 msecs > > The usb_dev_resume() return error -113, which mean host is in suspend state > when resuming a device. The scenario is: > 1) Just before system suspending, pm core will run hcd runtime resume > routine if host is in runtime suspend state. > 2) Hcd runtime resume function xhci_resume() returns, and roothub resume > worker was queued by usb_hcd_resume_root_hub(). > 3) system suspend continue going before roothub resume worker starts > executing. > Thus host is still in runtime suspend state. > 4) One event make suspending process aborted before hcd suspended. Then pm > core will call resume routines for just suspended device. But when resuming > a usb device it find the host is in suspended. Then return error -113. > > If my analysis is correct, could you share your ideas for this issue? Hasn't this already been fixed? See commit d6236f6d1d88 (xhci: Fix runtime suspended xhci from blocking system suspend). 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] USB: ftdi_sio: Added PID for new ekey device and some coding
Added support for ekey Converter USB which uses an FT232BM chip.
Also cleaned up some code style warnings, mostly whitespace and some
braces.
* ftdi_sio.c: checkpatch.pl 11E and 27W down to 11E and 21W
* ftdi_sio_ids.h: checkpatch.pl 60W down to 58W, only long lines left
Signed-off-by: Jaša Bartelj
---
drivers/usb/serial/ftdi_sio.c | 21 +
drivers/usb/serial/ftdi_sio_ids.h | 9 +++--
2 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c
b/drivers/usb/serial/ftdi_sio.c
index 216ce30..d85616f 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -58,7 +58,7 @@ struct ftdi_private {
int custom_divisor;/* custom_divisor kludge, this is for
baud_base (different from what goes to the
chip!) */
- __u16 last_set_data_urb_value ;
+ __u16 last_set_data_urb_value;
/* the last data state set - needed for doing
* a break
*/
@@ -934,6 +934,8 @@ static const struct usb_device_id
id_table_combined[] = {
{ USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_842_2_PID) },
{ USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_842_3_PID) },
{ USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_842_4_PID) },
+ /* ekey Devices */
+ { USB_DEVICE(FTDI_VID, FTDI_EKEY_CONV_USB_PID) },
/* Infineon Devices */
{ USB_DEVICE_INTERFACE_NUMBER(INFINEON_VID,
INFINEON_TRIBOARD_PID, 1) },
{ } /* Terminating entry */
@@ -1036,6 +1038,7 @@ static unsigned short int
ftdi_232am_baud_base_to_divisor(int baud, int base)
unsigned short int divisor;
/* divisor shifted 3 bits to the left */
int divisor3 = base / 2 / baud;
+
if ((divisor3 & 0x7) == 7)
divisor3++; /* round x.7/8 up to x+1 */
divisor = divisor3 >> 3;
@@ -1062,6 +1065,7 @@ static __u32 ftdi_232bm_baud_base_to_divisor(int
baud, int base)
__u32 divisor;
/* divisor shifted 3 bits to the left */
int divisor3 = base / 2 / baud;
+
divisor = divisor3 >> 3;
divisor |= (__u32)divfrac[divisor3 & 0x7] << 14;
/* Deal with special cases for highest baud rates. */
@@ -1448,8 +1452,7 @@ check_and_exit:
(old_priv.custom_divisor != priv->custom_divisor))) {
change_speed(tty, port);
mutex_unlock(&priv->cfg_lock);
- }
- else
+ } else
mutex_unlock(&priv->cfg_lock);
return 0;
}
@@ -1505,15 +1508,15 @@ static void ftdi_determine_type(struct
usb_serial_port *port)
/* Determine interface code. */
inter = serial->interface->altsetting->desc.bInterfaceNumber;
- if (inter == 0) {
+ if (inter == 0)
priv->interface = INTERFACE_A;
- } else if (inter == 1) {
+ else if (inter == 1)
priv->interface = INTERFACE_B;
- } else if (inter == 2) {
+ else if (inter == 2)
priv->interface = INTERFACE_C;
- } else if (inter == 3) {
+ else if (inter == 3)
priv->interface = INTERFACE_D;
- }
+
/* BM-type devices have a bug where bcdDevice gets set
* to 0x200 when iSerialNumber is 0. */
if (version < 0x500) {
@@ -1596,6 +1599,7 @@ static ssize_t latency_timer_show(struct device
*dev,
{
struct usb_serial_port *port = to_usb_serial_port(dev);
struct ftdi_private *priv = usb_get_serial_port_data(port);
+
if (priv->flags & ASYNC_LOW_LATENCY)
return sprintf(buf, "1\n");
else
@@ -1708,6 +1712,7 @@ static int ftdi_sio_probe(struct usb_serial
*serial,
if (quirk && quirk->probe) {
int ret = quirk->probe(serial);
+
if (ret != 0)
return ret;
}
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serial/ftdi_sio_ids.h
index 1e58d90..c16d330 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -897,7 +897,7 @@
* Kondo Kagaku Co.Ltd.
* http://www.kondo-robot.com/EN
*/
-#define KONDO_VID 0x165c
+#define KONDO_VID 0x165c
#define KONDO_USB_SERIAL_PID 0x0002
/*
@@ -1284,7 +1284,7 @@
/*
* Accesio USB Data Acquisition products (http://www.accesio.com/)
*/
-#define ACCESIO_COM4SM_PID 0xD578
+#define ACCESIO_COM4SM_PID 0xD578
/* www.sciencescope.co.uk educational dataloggers */
#define FTDI_SCIENCESCOPE_LOGBOOKML_PID0xFF18
@@ -1378,3 +1378,8 @@
#define BRAINBOXES_US_160_6_PID0x9006 /* US-160 16xRS232
1Mbaud Port 11 and 12 */
#define BRAINBOXES_US_160_7_PID0x9007 /* US-160 16xRS232
1Mbaud Port 13 and 14 */
#define BRAINBOXES_US_160_8_PID0x9008 /* US-160 16xRS232
1Mbaud Port 15 and 16 */
+
+/*
+ * ekey biometric systems GmbH (http://ekey.net/)
+ */
+#define FTDI_EKEY_CONV_USB_PID 0xCB08 /* Converter USB */
--
2.0.4
--
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.kern
Re: test program to check usb hid devices
hi David:
2014-08-15 20:54 GMT+08:00 David Laight :
> From: loody
>> Is there any test program we can use to capture input data send from
>> usb keyboard/mouse?
>
> google usbmon
Sorry for making you confused.
What I need is not monitor usb bus data.
What I need is some user mode program, and when I execute it, it will
driver usb HID keyboard/mouse to work.
And I can print out the hex value those device send once user press
any key on keyboard or moving mouse around.
It should be like I think
hid_device=hid_open(xxx);
while(1){
data = get input data(hid_device);
printf("0x%x\n",data);
}
Appreciate your kind help,
--
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: [Alsa-user] linux does not recognize my midi controller samson carbon 61
Hi, On 08/15/2014 04:00 PM, Lionel wrote: > Hi Daniel. This is trace when i connect the midi controller. Thanks. This one here is the setup packet followed by the answer, which is the device descriptor: > 8801cbae2a80 1534946150 S Ci:2:000:0 s 80 06 0100 0040 64 < > 8801cbae2a80 1534946409 C Ci:2:000:0 0 18 = 12010002 0040 > a0174b34 01020301 Which decodes to (some fields omitted): bcdUSB = 0x0200 idVendor = 0x17a0 idProduct = 0x344b bcdDevice = 0x0201 bNumConfigurations = 0 So this is clearly a bug in the firmware of your device, as bNumConfigurations = 0 doesn't make any sense. You basically have two options: ask the vendor to fix the bug, and send you instructions on how to update the firmware. Or we add a quirk to the USB layer in the kernel which sets bNumConfigurations to 1 for your device, hoping that that's the only bug in the firmware, which is not certain. If you want to go for the latter, you'd first need to build a kernel from the sources. As you said earlier you're on Ubuntu, some guidance is provided here: https://wiki.ubuntu.com/KernelTeam/GitKernelBuild Let me know when you managed to boot your own kernel. I'll send you a patch to test then. Best regards, Daniel -- 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: Transient USB disconnects
On Fri, 15 Aug 2014, David Laight wrote: > With all the usb dynamic-debug enabled the first errors I see are 'detected > XactErr' > len 0/1522 and len 2048/18944 (all 32 retries). > Then some '3strikes' messages (75 in total split between the endpoints). > > I've not yet looked at what those errors actually mean. "Detected XactErr" means a transaction error occurred (the Transaction Error (XactErr) bit was set in the qTD's status field). The len values are the number of bytes transferred and the number of bytes requested. Usually this occurs because the host doesn't receive a handshake or data packet from the device. The "3strikes" messages mean an URB was aborted because there were too many errors. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: ftdi_sio: Added PID for new ekey device and some coding
Please ignore this patch. Somewhere in the pipeline all tabs got converted to spaces. I'll repost soon. -- 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 3/5] usb: host: ehci-st: Add ehci-st devicetree bindings documentation
Hello.
On 08/15/2014 06:03 PM, Peter Griffin wrote:
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
---
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"
This sentence seems unfinished?
+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 = ;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb1>;
+ clocks = <&clk_s_a1_ls 0>;
You said that "clock-names" is a required prop but you didn't specify it.
+ phys = <&usb2_phy>;
+ phy-names = "usb";
+ status = "okay";
Not necessary.
+
+ resets = <&powerdown STIH416_USB1_POWERDOWN>,
+<&softreset STIH416_USB1_SOFTRESET>;
+ reset-names = "power", "softreset";
+ };
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 RFC 7/7] usb: host: ohci-exynos: Remove unnecessary usb-phy support
On Thu, 14 Aug 2014, Vivek Gautam wrote: > Now that we have completely moved from older USB-PHY drivers > to newer GENERIC-PHY drivers for PHYs available with USB controllers > on Exynos series of SoCs, we can remove the support for the same > in our host drivers too. > This should fix the issue on ohci-exynos, wherein in the absence of > SAMSUNG_USB2PHY config symbol, we ended up getting the NOP_USB_XCEIV phy > when the same is enabled. And thus the PHYs are not configured properly. > > Reported-by: Sachin Kamat > Signed-off-by: Vivek Gautam Acked-by: Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 6/7] usb: host: ehci-exynos: Remove unnecessary usb-phy support
On Thu, 14 Aug 2014, Vivek Gautam wrote: > Now that we have completely moved from older USB-PHY drivers > to newer GENERIC-PHY drivers for PHYs available with USB controllers > on Exynos series of SoCs, we can remove the support for the same > in our host drivers too. > This should fix the issue on ehci-exynos, wherein in the absence of > SAMSUNG_USB2PHY config symbol, we ended up getting the NOP_USB_XCEIV phy > when the same is enabled. And thus the PHYs are not configured properly. > > Reported-by: Sachin Kamat > Signed-off-by: Vivek Gautam Acked-by: 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: test program to check usb hid devices
If I understood correctly, you just want to dump the hid output.
You can just cat /sys/kernel/debug/hid/*/events if debugfs is mounted.
Or you may want to have a look at these 2 projects:
hid-recorder -> http://bentiss.github.io/hid-replay-docs/
usbhid-dump-> https://github.com/DIGImend/usbhid-dump (part of the
DIGImend project)
Cheers,
Benjamin
On Fri, Aug 15, 2014 at 10:31 AM, loody wrote:
> hi David:
>
> 2014-08-15 20:54 GMT+08:00 David Laight :
>> From: loody
>>> Is there any test program we can use to capture input data send from
>>> usb keyboard/mouse?
>>
>> google usbmon
> Sorry for making you confused.
> What I need is not monitor usb bus data.
> What I need is some user mode program, and when I execute it, it will
> driver usb HID keyboard/mouse to work.
> And I can print out the hex value those device send once user press
> any key on keyboard or moving mouse around.
>
> It should be like I think
> hid_device=hid_open(xxx);
> while(1){
> data = get input data(hid_device);
> printf("0x%x\n",data);
> }
>
> Appreciate your kind help,
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" 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
[PATCH] USB: serial: pl2303: add device id for ztek device
This adds a new device id to the pl2303 driver for the ZTEK device.
Reported-by: Mike Chu
Cc: stable
Signed-off-by: Greg Kroah-Hartman
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index b3d5a35c0d4b..e9bad928039f 100644
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -45,6 +45,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_GPRS) },
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_HCR331) },
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_MOTOROLA) },
+ { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_ZTEK) },
{ USB_DEVICE(IODATA_VENDOR_ID, IODATA_PRODUCT_ID) },
{ USB_DEVICE(IODATA_VENDOR_ID, IODATA_PRODUCT_ID_RSAQ5) },
{ USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_ID) },
diff --git a/drivers/usb/serial/pl2303.h b/drivers/usb/serial/pl2303.h
index 42bc082896ac..71fd9da1d6e7 100644
--- a/drivers/usb/serial/pl2303.h
+++ b/drivers/usb/serial/pl2303.h
@@ -22,6 +22,7 @@
#define PL2303_PRODUCT_ID_GPRS 0x0609
#define PL2303_PRODUCT_ID_HCR331 0x331a
#define PL2303_PRODUCT_ID_MOTOROLA 0x0307
+#define PL2303_PRODUCT_ID_ZTEK 0xe1f1
#define ATEN_VENDOR_ID 0x0557
#define ATEN_VENDOR_ID20x0547
--
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: [Alsa-user] linux does not recognize my midi controller samson carbon 61
On 08/15/2014 05:25 PM, Lionel wrote: > Thanks Daniel! You're welcome! > I decided to ask the vendor to fix the bug in the firmware. Do I have > any expectation of success? Probably not. Most audio hardware vendors don't care about Linux. > What should be the best way to request > support for linux? Well, I already offered to provide a patch to at least make the device be recognized by the USB subsystem layer. After that has happened, we can look at the other decriptors and see what they yield. It's likely, however, that the device is not compatible to any class compliant driver. I'd even assume the vendor set bNumConfigurations to 1 on purpose so that Windows doesn't look at the device. But that's just guessing. Let me know if you want to give such a patch a try. Daniel -- 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] USB: ftdi_sio: Added PID for new ekey device and some coding
On Fri, Aug 15, 2014 at 04:20:14PM +0200, Jaša Bartelj wrote: > Added support for ekey Converter USB which uses an FT232BM chip. > Also cleaned up some code style warnings, mostly whitespace and some > braces. > * ftdi_sio.c: checkpatch.pl 11E and 27W down to 11E and 21W > * ftdi_sio_ids.h: checkpatch.pl 60W down to 58W, only long lines left For your retry, don't mix a checkpatch cleanup with a "add a new device" change in the same patch. Make it two different patches, the "add a new device" patch first, so it does not depend on the cleanup patch, so that it can be backported to older kernels easier. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Newer Technology uSCSI SCSI-USB converter
The uSCSI from Newer Technology is a SCSI-USB converter with USB ID 06ca:2003. Like several other SCSI-USB products, it's a Shuttle Technology OEM device. Copying the unusual-devs.h entry for device 04e6:0002 allows it to work with Linux There are currently six entries for Shuttle-developed SCSI-USB devices in unusual-devs.h (grep for euscsi): 04e6:0002 Shuttle eUSCSI BridgeUSB_SC_DEVICE, USB_PR_DEVICE 04e6:000b Shuttle eUSCSI BridgeUSB_SC_SCSI, USB_PR_BULK 04e6:000c Shuttle eUSCSI BridgeUSB_SC_SCSI, USB_PR_BULK 050d:0115 Belkin USB SCSI Adaptor USB_SC_SCSI, USB_PR_BULK 07af:0004 Microtech USB-SCSI-DB25 USB_SC_DEVICE, USB_PR_DEVICE 07af:0005 Microtech USB-SCSI-HD50 USB_SC_DEVICE, USB_PR_DEVICE lsusb -v output for the uSCSI lists bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk (Zip) This patch adds an entry for the uSCSI to unusual_devs.h. diff -up linux-3.16/drivers/usb/storage/unusual_devs.h.orig linux-3.16/drivers/usb/storage/unusual_devs.h --- linux-3.16/drivers/usb/storage/unusual_devs.h.orig 2014-08-03 23:25:02.0 +0100 +++ linux-3.16/drivers/usb/storage/unusual_devs.h 2014-08-15 19:48:54.0 +0100 @@ -922,6 +922,12 @@ UNUSUAL_DEV( 0x069b, 0x3004, 0x0001, 0x USB_SC_DEVICE, USB_PR_DEVICE, NULL, US_FL_FIX_CAPACITY ), +UNUSUAL_DEV( 0x06ca, 0x2003, 0x0100, 0x0100, + "Newer Technology", + "uSCSI", + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_euscsi_init, + US_FL_SCM_MULT_TARG ), + /* Reported by Adrian Pilchowiec */ UNUSUAL_DEV( 0x071b, 0x3203, 0x, 0x, "RockChip", -- 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
