Re: [Patch] block: remove the deprecated ub driver
On Sun, Aug 26, 2012 at 1:37 AM, Sebastian Andrzej Siewior wrote: > On Sat, Aug 25, 2012 at 11:51:23PM +0800, Cong Wang wrote: >> From: Cong Wang >> >> It is scheduled to be removed in 3.6. > > This should go via Greg and linux-usb and you should put Pete Zaitcev on Cc. Will do. > I have a patch in my try doing this and removing the libusual which is > obsolete > since there is only one driver for USB storage. > I would not remove the config option from all these defconfigs. Once this > symbol is gone, it will vanish from defconfigs all by itself once they update > their defconfigs and this patch does not clash with them. > Makes sense. I will send an updated patch. 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: Virtualbox/Vmware usb device is working but on installed linux not.
On Sat, 25 Aug 2012, adam ? wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=46411 Please post a usbmon trace showing what happens when your device is plugged into a real linux system (not a virtual machine). Instructions are in the kernel source file Documentation/usb/usbmon.txt. 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/xhci: unify parameter of xhci_msi_irq
On Mon, Aug 13, 2012 at 01:59:00PM +0800, Alex Shi wrote: > On 06/12/2012 05:14 AM, gregkh wrote: > > > On Mon, Jun 11, 2012 at 01:47:09PM -0700, Sarah Sharp wrote: > >> Hi Alex, > >> > >> This got lost in the 3.5 push, but I think it's a good candidate for > >> 3.6. I think Greg is accepting 3.6 patches now, and I'll send this off > >> to him. > > > > Yes, I am taking 3.6 stuff now. In the future, once -rc1 is out, I can > > take patches for the next release at that point in time. > > > > greg k-h > > > > > Didn't find the patch in upstream 3.6-rc, but it is still workable for > upstream kernel. > So, was you just going to apply it on 3.7 kernel? or just forget it? Hi Alex, I am human, and trying my human best to keep up as a maintainer. Bug fixes and big features take priority over the small improvements, and I'm sorry that your patch (and other patches) have fallen by the wayside. It is not personal, I simply cannot be perfect. I will be returning to full maintainership duties after the various Linux conferences next week, and I will do my best to get your patch merged. 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
usb: cdc-acm: remove duplicated include from cdc-acm.c
From: Wei Yongjun Remove duplicated include. Signed-off-by: Wei Yongjun --- drivers/usb/class/cdc-acm.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c index 56d6bf6..9e16f51 100644 --- a/drivers/usb/class/cdc-acm.c +++ b/drivers/usb/class/cdc-acm.c @@ -39,7 +39,6 @@ #include #include #include -#include #include #include #include -- 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 sound card device complains about "error -28: not enough bandwidth" only on specific PC hardware, seems not kernel specific
On Sat, 25 Aug 2012, David Ranch wrote:
> Hello Alan,
>
> Ok... I've uploaded the DEBUG enabled 3.5.2 kernel logs as requested and
> I'm working on getting the USB snooping going on the old Athlon 1.1Ghz
> Windows XP machine (yuk!).
>
> http://www.trinityos.com/SCRATCH/
>
>
> Regardless of getting this possible high-speed hack working, could you
> explain a bit by what you meant by:
>
> "The problem is caused by the ehci-hcd driver's not-so-great support
> for scheduling periodic transfers to full-speed devices. That's why the
> HP and Dell systems have no trouble but your Gateway laptop can't handle
> it. "
>
> To me if I'm doing the math right, 2 (two stereo channels) * 24 (bit) *
> 96,000 (sampling) == 4.6Mb/s which is only a third of the USB port's
> speed when even running in FULL speed mode! Why would it be complaining
> when there isn't anything else on this bus?
Well, for one thing the available full-speed bandwidth is less than 15
Mb/s. Periodic transfers (such as audio data) are not allowed to
consume more than 90% of the total bandwidth. In addition, USB uses
bit stuffing to prevent more than six 1's appearing consecutively on
the bus; this means everything has to be assessed 7/6 more bandwidth
than the nominal value. And then there's protocol overhead. But even
so, a full-speed bus can handle something like 1100 bytes of periodic
data per ms, and your device only needs 585 (3 bytes of interrupt data
and 582 bytes of isochronous audio data).
However this isn't a question of bandwidth; it's a question of
limitations in the driver. ehci-hcd's support for periodic split
transactions (which includes full-speed isochronous and interrupt
transfers, which includes what's going on with your audio device) is
really very poor. The best that can be said is that it sort of works
most of the time. But there are plenty of cases where it doesn't work,
and you are facing one of them.
> What are the chances
> when/if this EHCI driver will get some fixes for this issue?
A real fix will not come quickly because doing this right is very
difficult. The patch below is sort of a band-aid; I'm not promising
anything but it might help.
By the way, now that you've got CONFIG_USB_DEBUG enabled, there's
something I'd like to see. I'm assuming you've got a debugfs
filesystem mounted on /sys/kernel/debug. Go into
/sys/kernel/debug/usb/ehci/:00:1d.0/ (that's the directory
corresponding to the controller your device is plugged into, bus 2) and
post a copy of the "periodic" file in that directory -- this is with
your test program running, of course (using a smaller sampling rate so
that it doesn't fail immediately).
In fact, do the same thing both with and without the patch below. I'd
like to verify that it does make a difference.
Alan Stern
Index: usb-3.5/drivers/usb/host/ehci-sched.c
===
--- usb-3.5.orig/drivers/usb/host/ehci-sched.c
+++ usb-3.5/drivers/usb/host/ehci-sched.c
@@ -840,7 +840,7 @@ static int qh_schedule(struct ehci_hcd *
for (i = qh->period; status && i > 0; --i) {
frame = ++ehci->random_frame % qh->period;
- for (uframe = 0; uframe < 8; uframe++) {
+ for (uframe = 8; uframe-- > 0; ) {
status = check_intr_schedule (ehci,
frame, uframe, qh,
&c_mask);
--
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] usb: gadget: bcm63xx UDC driver
On Sat, 25 Aug 2012, Kevin Cernekee wrote: > I am hoping that these invalid SET_CONFIGURATION / SET_INTERFACE > requests are uncommon. In what sorts of situations will a host > request a configuration that isn't advertised in the device's > descriptors? I had trouble just convincing usb_set_interface() / > usb_driver_set_configuration() to send such a request because they > honor bInterfaceNumber / bConfigurationValue from the descriptors. A request doesn't have to be invalid to fail. Valid requests can fail for all sorts of reasons. -ENOMEM is the prototypical example. 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 4/6] drivers/usb/host/ohci-nxp.c: adjust inconsistent IS_ERR and PTR_ERR
From: Julia Lawall
Change the call to PTR_ERR to access the value just tested by IS_ERR.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
//
@@
expression e,e1;
@@
(
if (IS_ERR(e)) { ... PTR_ERR(e) ... }
|
if (IS_ERR(e=e1)) { ... PTR_ERR(e) ... }
|
*if (IS_ERR(e))
{ ...
* PTR_ERR(e1)
... }
)
//
Signed-off-by: Julia Lawall
---
drivers/usb/host/ohci-nxp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/ohci-nxp.c b/drivers/usb/host/ohci-nxp.c
index a446386..c60066a 100644
--- a/drivers/usb/host/ohci-nxp.c
+++ b/drivers/usb/host/ohci-nxp.c
@@ -355,7 +355,7 @@ static int __devinit usb_hcd_nxp_probe(struct
platform_device *pdev)
usb_otg_clk = clk_get(&pdev->dev, "ck_usb_otg");
if (IS_ERR(usb_otg_clk)) {
dev_err(&pdev->dev, "failed to acquire USB DEV Clock\n");
- ret = PTR_ERR(usb_dev_clk);
+ ret = PTR_ERR(usb_otg_clk);
goto out6;
}
--
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/6] drivers/usb/gadget/lpc32xx_udc.c: adjust inconsistent IS_ERR and PTR_ERR
From: Julia Lawall
Change the call to PTR_ERR to access the value just tested by IS_ERR.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
//
@@
expression e,e1;
@@
(
if (IS_ERR(e)) { ... PTR_ERR(e) ... }
|
if (IS_ERR(e=e1)) { ... PTR_ERR(e) ... }
|
*if (IS_ERR(e))
{ ...
* PTR_ERR(e1)
... }
)
//
Signed-off-by: Julia Lawall
---
drivers/usb/gadget/lpc32xx_udc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/lpc32xx_udc.c b/drivers/usb/gadget/lpc32xx_udc.c
index f1ec99e..3a6cdd0 100644
--- a/drivers/usb/gadget/lpc32xx_udc.c
+++ b/drivers/usb/gadget/lpc32xx_udc.c
@@ -3208,7 +3208,7 @@ static int __init lpc32xx_udc_probe(struct
platform_device *pdev)
udc->usb_otg_clk = clk_get(&pdev->dev, "ck_usb_otg");
if (IS_ERR(udc->usb_otg_clk)) {
dev_err(udc->dev, "failed to acquire USB otg clock\n");
- retval = PTR_ERR(udc->usb_slv_clk);
+ retval = PTR_ERR(udc->usb_otg_clk);
goto usb_otg_clk_get_fail;
}
--
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 sound card device complains about "error -28: not enough bandwidth" only on specific PC hardware, seems not kernel specific
Hello Alan, Ok... I've uploaded the DEBUG enabled 3.5.2 kernel logs as requested and I'm working on getting the USB snooping going on the old Athlon 1.1Ghz Windows XP machine (yuk!). http://www.trinityos.com/SCRATCH/ Regardless of getting this possible high-speed hack working, could you explain a bit by what you meant by: "The problem is caused by the ehci-hcd driver's not-so-great support for scheduling periodic transfers to full-speed devices. That's why the HP and Dell systems have no trouble but your Gateway laptop can't handle it. " To me if I'm doing the math right, 2 (two stereo channels) * 24 (bit) * 96,000 (sampling) == 4.6Mb/s which is only a third of the USB port's speed when even running in FULL speed mode! Why would it be complaining when there isn't anything else on this bus? What are the chances when/if this EHCI driver will get some fixes for this issue? Btw, this might be helpful but the "quisk" program I'm using has a portaudio (not PulseAudio) script to show devices and their abilities. The onboard soundcard works all the way up to 192Khz but it's horribly noisy and ironically, it's lowpass/highpass filtering seems to only support ~70Khz worth of bandwidth though the chip can do far better! Lame. Guess that's what one gets for a $400 laptop these days. $ python portaudio.py ALSA lib pcm.c:2209:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear ALSA lib pcm.c:2209:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe ALSA lib pcm.c:2209:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side Open 0 Version 1899 Version Text PortAudio V19-devel (built Jan 17 2012 04:03:50) NumDev 12 Device 0, host api ALSA Name HDA Intel PCH: ALC269VB Analog (hw:0,0) Max inputs 2, Max outputs 2 Speeds for 2-channel paInt32: 44100 48000 96000 192000 Device 1, host api ALSA Name HDA Intel PCH: HDMI 0 (hw:0,3) Max inputs 0, Max outputs 8 Speeds for 2-channel paInt32: 44100 48000 96000 192000 Device 2, host api ALSA Name SB X-Fi Surround 5.1 Pro: USB Audio (hw:1,0) Max inputs 2, Max outputs 6 Speeds for 2-channel paInt32: 48000 96000 Device 3, host api ALSA Name SB X-Fi Surround 5.1 Pro: USB Audio #1 (hw:1,1) Max inputs 0, Max outputs 2 Speeds for 2-channel paInt32: 44100 48000 Device 4, host api ALSA Name front Max inputs 0, Max outputs 2 Speeds for 2-channel paInt32: 44100 48000 96000 192000 Device 5, host api ALSA Name surround40 Max inputs 0, Max outputs 2 Speeds for 2-channel paInt32: 44100 48000 96000 192000 Device 6, host api ALSA Name surround51 Max inputs 0, Max outputs 2 Speeds for 2-channel paInt32: 44100 48000 96000 192000 Device 7, host api ALSA Name surround71 Max inputs 0, Max outputs 2 Speeds for 2-channel paInt32: 44100 48000 96000 192000 Device 8, host api ALSA Name hdmi Max inputs 0, Max outputs 8 Speeds for 2-channel paInt32: 44100 48000 96000 192000 Device 9, host api ALSA Name pulse Max inputs 32, Max outputs 32 Speeds for 2-channel paInt32: 44100 48000 96000 192000 Device 10, host api ALSA Name dmix Max inputs 0, Max outputs 2 lots of the following: ALSA lib pcm_dmix.c:1018:(snd_pcm_dmix_open) unable to open slave ALSA lib pcm_dmix.c:1018:(snd_pcm_dmix_open) unable to open slave Expression 'ret' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1669 Expression 'AlsaOpen( hostApi, parameters, streamDir, &pcm )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1701 ... and then Speeds for 2-channel paInt32: Device 11, host api ALSA Name default Max inputs 32, Max outputs 32 Speeds for 2-channel paInt32: 44100 48000 96000 192000 Close 0 --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: [PATCH V3] usb: gadget: bcm63xx UDC driver
On Wed, Aug 22, 2012 at 12:48 AM, Sebastian Andrzej Siewior wrote: > Just one thing that bit while I was sleeping: > The HW acks SetConfig on its own. Once you notice this, you set > ->ep0_req_set_cfg and set state in bcm63xx_ep0_do_idle() to > EP0_IN_FAKE_STATUS_PHASE. This is I guess the workaround for mass_storage's > hold with DELAYED_STATUS and continues with a zero packet. EP0_IN_FAKE_STATUS_PHASE is there for the general case of: setup() callback returned >= 0 after a spoofed setup packet, and we're waiting for the gadget driver to send the 0-byte status reply so we can silently discard it and move on. When bcm63xx_udc is in EP0_IN_FAKE_STATUS_PHASE, it won't issue any more setup() callbacks until the 0-byte reply arrives from the gadget driver. If the host sends a setup request, the callback will be held off until after the (unused) status reply. This keeps the gadget driver from getting confused by out-of-sequence events. > Now two questions: > - If a gadget descides not NAK / stall the SetConfig requests. What happens > here? If the return value from the setup() callback was negative, bcm63xx_udc should just return to EP0_IDLE as the gadget driver will never send a 0-byte reply. I have added a new check for this condition, verified that it works as intended, and posted V4. I am hoping that these invalid SET_CONFIGURATION / SET_INTERFACE requests are uncommon. In what sorts of situations will a host request a configuration that isn't advertised in the device's descriptors? I had trouble just convincing usb_set_interface() / usb_driver_set_configuration() to send such a request because they honor bInterfaceNumber / bConfigurationValue from the descriptors. > - What happens if the host is faster than the UDC. SetConfig returns in > usb-storage with "DELAYED_STATUS". HW Acks this. Could the Host send another > request before the gadget queues the ep0 request? Could you please clarify if this is the sequence of events you are describing: 1) Host sends a valid SET_CONFIGURATION request to a mass storage gadget 2) Hardware instantly auto-acks the request, completing the status phase and allowing the host to proceed with another ep0 request 3) bcm63xx_udc sends a spoofed SET_CONFIGURATION setup packet to the gadget driver 4) setup() callback returns USB_GADGET_DELAYED_STATUS (0x7fff) but doesn't queue up a reply 5) Host sends another setup packet before usb_composite_setup_continue() is called to send the 0-byte status reply If so, the next steps should look like: 6) bcm63xx_udc takes a data IRQ, and sets ep0_req_completed 7) bcm63xx_udc stays in EP0_IN_FAKE_STATUS_PHASE until the 0-byte reply is received from usb_composite_setup_continue() 8) usb_composite_setup_continue() eventually sends the 0-byte reply 9) bcm63xx_udc returns to EP0_IDLE and notices that ep0_req_completed is now set 10) bcm63xx_ep0_do_setup() looks at the new request, and performs the setup() callback for the new setup request 11) Data/status phases are handled as usual -- 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 2/3] usb: otg: add device tree support to otg library
On 08/24/2012 08:46 AM, Richard Zhao wrote:
> Did you try both enableing and disabing DT pass build?
Impossible on mx28 :) The platform always selects USE_DT, but on imx it
builds without DT support.
> On Thu, Aug 23, 2012 at 07:22:53PM +0200, Marc Kleine-Budde wrote:
>> From: Kishon Vijay Abraham I
>>
>> This patch adds an API to get usb phy by passing a device node phandle value.
>> The new added devm_usb_get_phy_by_phandle() function will return a pointer to
>> the phy on success, -EPROBE_DEFER if there is a device_node for the phandle,
>> but the phy has not been added, or a ERR_PTR() otherwise.
>>
>> Since it's possible to obtain a phy by phandle, the checks in usb_add_phy()
>> for
>> a valid phy type is removed (now it's just a debug message if a user tries to
>> add a phy with undefined type). This also allows to add multiple phys of same
>> type.
>>
>> Cc: Richard Zhao
>> Cc: Marek Vasut
>> Signed-off-by: Kishon Vijay Abraham I
>> Signed-off-by: Marc Kleine-Budde
>> ---
>> drivers/usb/otg/otg.c | 96
>> ---
>> include/linux/usb/otg.h |8
>> 2 files changed, 90 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
>> index 98c430e..23618de 100644
>> --- a/drivers/usb/otg/otg.c
>> +++ b/drivers/usb/otg/otg.c
>> @@ -15,6 +15,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>>
>> @@ -36,6 +37,21 @@ static struct usb_phy *__usb_find_phy(struct list_head
>> *list,
>> return ERR_PTR(-ENODEV);
>> }
>>
>> +static struct usb_phy *__of_usb_find_phy(struct list_head *list,
>> +struct device_node *node)
>> +{
>> +struct usb_phy *phy;
>> +
>> +list_for_each_entry(phy, list, head) {
>> +if (node != phy->dev->of_node)
>> +continue;
>> +
>> +return phy;
>> +}
>> +
>> +return ERR_PTR(-ENODEV);
>> +}
>> +
>> static void devm_usb_phy_release(struct device *dev, void *res)
>> {
>> struct usb_phy *phy = *(struct usb_phy **)res;
>> @@ -112,6 +128,66 @@ err0:
>> EXPORT_SYMBOL(usb_get_phy);
>>
>> /**
>> + * devm_usb_get_phy_by_phandle - find the USB PHY by phandle
>> + * @dev - device that requests this phy
>> + * @phandle - name of the property holding the phy phandle value
>> + *
>> + * Returns the phy driver associated with the given phandle value,
>> + * after getting a refcount to it, -ENODEV if there is no such phy or
>> + * -EPROBE_DEFER if there is a phandle to the phy, but the device is
>> + * not yet loaded. While at that, it also associates the device with
>> + * the phy using devres. On driver detach, release function is invoked
>> + * on the devres data, then, devres data is freed.
>> + *
>> + * For use by USB host and peripheral drivers.
>> + */
>> +struct usb_phy *devm_usb_get_phy_by_phandle(struct device *dev,
>> +const char *phandle)
> Since it's already a common function, we may give phandler property
> a common name too. So we will not need phandle argument.
> Please also don't forget to document the devm_xxx and dt binding.
Good point. This is the device tree snippet from imx28.dtsi:
> usb0: usb@8008 {
> compatible = "fsl,imx28-usb", "fsl,imx27-usb";
> reg = <0x8008 0x1>;
> interrupts = <93>;
> fsl,usbphy = <&usbphy0>;
What about removing the "fsl,", so it just would be "usbphy".
> status = "disabled";
> };
>> +{
>> +struct usb_phy *phy = NULL, **ptr;
>> +unsigned long flags;
>> +struct device_node *node;
>> +
>> +if (!dev->of_node) {
>> +dev_dbg(dev, "device does not have a device node entry\n");
>> +return ERR_PTR(-EINVAL);
>> +}
>> +
>> +node = of_parse_phandle(dev->of_node, phandle, 0);
>> +if (!node) {
>> +dev_dbg(dev, "failed to get %s phandle in %s node\n", phandle,
>> +dev->of_node->full_name);
>> +return ERR_PTR(-ENODEV);
>> +}
>> +
>> +ptr = devres_alloc(devm_usb_phy_release, sizeof(*ptr), GFP_KERNEL);
>> +if (!ptr) {
>> +dev_dbg(dev, "failed to allocate memory for devres\n");
>> +return ERR_PTR(-ENOMEM);
>> +}
>> +
>> +spin_lock_irqsave(&phy_lock, flags);
>> +
>> +phy = __of_usb_find_phy(&phy_list, node);
>> +if (IS_ERR(phy) || !try_module_get(phy->dev->driver->owner)) {
>> +phy = ERR_PTR(-EPROBE_DEFER);
>> +devres_free(ptr);
>> +goto err0;
>> +}
>> +
>> +*ptr = phy;
>> +devres_add(dev, ptr);
>> +
>> +get_device(phy->dev);
>> +
>> +err0:
>> +spin_unlock_irqrestore(&phy_lock, flags);
>> +
>> +return phy;
>> +}
>> +EXPORT_SYMBOL(devm_usb_get_phy_by_phandle);
>> +
>> +/**
>> * devm_usb_put_phy - release the USB PHY
>> * @dev - device that wants to release this phy
>> * @phy - the phy returned by devm_usb_get_phy()
>> @@ -
Re: Potential fsg->state problem at file_storage.c
On Sat, Aug 25, 2012 at 10:35:34AM -0400, Alan Stern wrote: > For safety's sake, it would be a good idea to flush the dirty pages > when a disconnect occurs. It does not look like there is an API for this (yet). > > Nothing happens on US_BULK_RESET_REQUEST or on function.disable callback. > > I don't know about function.disable -- does this mean your function is > getting removed from the device's configuration? If it does then the > backing storage should be closed. Yes, function.disable should be called on disconnect. Another thing I don't have power over :) Let think about this later. > > If there's an ongoing I/O operation, US_BULK_RESET_REQUEST should abort > it. After processing the class-specific reset, the gadget is supposed > to be ready to accept and carry out new commands. Oustanding requests... that sounds like something I should check. > Alan Stern 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: [Patch] block: remove the deprecated ub driver
On Sat, Aug 25, 2012 at 11:51:23PM +0800, Cong Wang wrote: > From: Cong Wang > > It is scheduled to be removed in 3.6. This should go via Greg and linux-usb and you should put Pete Zaitcev on Cc. I have a patch in my try doing this and removing the libusual which is obsolete since there is only one driver for USB storage. I would not remove the config option from all these defconfigs. Once this symbol is gone, it will vanish from defconfigs all by itself once they update their defconfigs and this patch does not clash with them. 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: Potential fsg->state problem at file_storage.c
On Sat, 25 Aug 2012, Sebastian Andrzej Siewior wrote: > On Fri, Aug 24, 2012 at 10:50:54AM -0400, Alan Stern wrote: > > Sebastian, you might be able to check this yourself. What does > > tcm_usb_gadget do when it gets a USB port reset? Does it tell the > > storage layer to sync all the dirty pages? > No, it leavs the storage layer alone. Then your gadget isn't subject to the problem that Peter reported. > > Also, does it sync the dirty pages when it gets a USB disconnect? > > As far as I can see, a sync happens on > - SYNCHRONIZE_CACHE CDB > - on write CDBs with FUA=1 (WCE is ignored here) > > which means it has to be requested by the initiator. For safety's sake, it would be a good idea to flush the dirty pages when a disconnect occurs. > Nothing happens on US_BULK_RESET_REQUEST or on function.disable callback. I don't know about function.disable -- does this mean your function is getting removed from the device's configuration? If it does then the backing storage should be closed. If there's an ongoing I/O operation, US_BULK_RESET_REQUEST should abort it. After processing the class-specific reset, the gadget is supposed to be ready to accept and carry out new commands. 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 3/3] usb: mxs-phy: register phy as USB_PHY_TYPE_USB2
On 08/24/2012 08:51 AM, Richard Zhao wrote:
> On Thu, Aug 23, 2012 at 07:22:54PM +0200, Marc Kleine-Budde wrote:
>> This patch registers the msx-phy as an USB_PHY_TYPE_USB2. This is needed to
>> get
>> reference to the phy with devm_usb_get_phy_by_phandle(), which will be added
>> in
>> a later patch.
>>
>> Signed-off-by: Marc Kleine-Budde
>> ---
>> drivers/usb/otg/mxs-phy.c |5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/otg/mxs-phy.c b/drivers/usb/otg/mxs-phy.c
>> index c1a67cb..240b945 100644
>> --- a/drivers/usb/otg/mxs-phy.c
>> +++ b/drivers/usb/otg/mxs-phy.c
>> @@ -141,11 +141,14 @@ static int mxs_phy_probe(struct platform_device *pdev)
>>
>> platform_set_drvdata(pdev, &mxs_phy->phy);
>>
>> -return 0;
>> +return usb_add_phy(&mxs_phy->phy, USB_PHY_TYPE_USB2);
> Why is it usb2? It's kind of USB_PHY_TYPE_DT.
For now there is USB_PHY_TYPE_USB2, USB_PHY_TYPE_USB3 and undefined. On
the one hand it's an USB2 type phy on the other the type is not relevant
if you get the phy by a phandle. I think it should be USB2. Kishon, what
do you think?
>> }
>>
>> static int __devexit mxs_phy_remove(struct platform_device *pdev)
>> {
>> +struct mxs_phy *mxs_phy = platform_get_drvdata(pdev);
> drvdata is usb_phy.
Right, will fix.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 1/3] usb: otg: Improve phy handling
On 08/24/2012 03:59 AM, Richard Zhao wrote: > On Thu, Aug 23, 2012 at 07:22:51PM +0200, Marc Kleine-Budde wrote: >> This patch series improves the phy handling. >> >> The first patch fixes the problem that the phy driver, when build as module, >> can be unloaded when the phy is in use. > ci13xxx_imx also have a try_module_get. Yes, I took the idea of try_module_get from the ci13xxx_imx driver. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: Potential fsg->state problem at file_storage.c
On Fri, Aug 24, 2012 at 10:50:54AM -0400, Alan Stern wrote: > Sebastian, you might be able to check this yourself. What does > tcm_usb_gadget do when it gets a USB port reset? Does it tell the > storage layer to sync all the dirty pages? No, it leavs the storage layer alone. > Also, does it sync the dirty pages when it gets a USB disconnect? As far as I can see, a sync happens on - SYNCHRONIZE_CACHE CDB - on write CDBs with FUA=1 (WCE is ignored here) which means it has to be requested by the initiator. Nothing happens on US_BULK_RESET_REQUEST or on function.disable callback. > Alan Stern 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: [PATCH 1/1] xhci: Recognize USB 3.0 devices as superspeed at powerup
On Thu, Aug 23, 2012 at 12:53 AM, wrote: > From: Manoj Iyer > > On Intel Panther Point chipset USB 3.0 devices show up as > high-speed devices on powerup, but after an s3 cycle they are > correctly recognized as SuperSpeed. At powerup switch the port > to xHCI so that USB 3.0 devices are correctly recognized. > > BugLink: http://bugs.launchpad.net/bugs/1000424 > > Signed-off-by: Manoj Iyer This one looks OK to me. Thanks, Andiry > --- > drivers/usb/host/pci-quirks.c |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c > index c5e9e4a..486e812 100644 > --- a/drivers/usb/host/pci-quirks.c > +++ b/drivers/usb/host/pci-quirks.c > @@ -870,9 +870,10 @@ static void __devinit quirk_usb_handoff_xhci(struct > pci_dev *pdev) > /* Disable any BIOS SMIs and clear all SMI events*/ > writel(val, base + ext_cap_offset + XHCI_LEGACY_CONTROL_OFFSET); > > +hc_init: > if (usb_is_intel_switchable_xhci(pdev)) > usb_enable_xhci_ports(pdev); > -hc_init: > + > op_reg_base = base + XHCI_HC_LENGTH(readl(base)); > > /* Wait for the host controller to be ready before writing any > -- > 1.7.9.5 > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb3 writes fail with transcend rdf8 + ASMedia ASM1042 woes
On Fri, Aug 24, 2012 at 7:16 PM, Sami Farin wrote: > On Sun, Jul 15, 2012 at 11:14:13 -0400, Alan Stern wrote: > ... >> In past years I have found that Genesys's devices tend to be rather >> buggy. This card reader continues the tradition. Basically, although >> the firmware works reasonably well at high speed, the SuperSpeed >> support is too buggy to be usable. >> >> My advice is to exchange the card reader for one of a different brand. > > I got £6 reader from eBay, sanXi usb3 sdcx reader.. > It reset itself to usb2 speed when I tried it in usb3 port > and in usb2 port it is quite slow (14 MB/s). > There are benchmarks done by other people with sanXi where they get good > speed (90 MB/s) but presumably they do not have any ASMedia near their > computers. > Also, (after first use) the usb3 port I used sanXi in was DEAD till I rebooted > the machine; also, other devices were not detected in the port, either. > >> Alan Stern >> >> P.S.: Sarah, the lspci information shows this xHCI controller to be an >> ASM1042 controller from ASMedia. Is this one of those known to have >> the short-packet bug? The usbmon trace shows a cancelled transfer, for >> which 0 bytes must have been received, but with actual_length equal to >> the transfer_buffer_length. > > 3.6.0-rc2-g6dab7ede has some funny printk's , but it panics on network use > so I am back to 3.5.0-rc7-g84a1caf: > > <5>[5.163846] scsi 10:0:0:0: bad extra_isize (%u != %u)Direct-Access > Generic STORAGE DEVICE TS07 PQ: 0 ANSI: 0 > <3>[ 2277.412255] sd 10:0:0:1: 6mpf: %llx > > >> This would seem to indicate another type of bug in the host controller. >> Apparently it reported normal completion for a transfer that was >> cancelled. > > Can these be worked around in kernel, or is firmware update needed > for asmedia? I have latest BIOS from Asus... A dmesg with CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING would be helpful. Thanks, Andiry > > -- > Do what you love because life is too short for anything else. > > -- > 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
