Re: [RFC PATCH 2/2] USB: Set usb port's DevicerRemovable according acpi information in EHCI
On 2012年08月27日 03:18, Alan Stern wrote: > On Sun, 26 Aug 2012, Lan Tianyu wrote: > >> �� 2012/8/24 22:45, Alan Stern д��: >>> On Fri, 24 Aug 2012, Lan Tianyu wrote: >>> >> But if other places got hub descriptor, they can't get DeviceRemovable >> value since we only set DeviceRemovable in the hub_configure().(e.g >> lsusb). >>> >>> Note: This isn't true. You now set desc->u.hs.DeviceRemovable in >>> ehci_hub_descriptor(). >> Oh. Sorry. I maybe confuse you or make you misunderstand due to my broken >> descriptor. Do you agree set desc->u.hs.DeviceRemovable in >> ehci_hub_descriptor()? > > Yes. Ideally, those bits should be set even if the hub driver isn't > bound to the root hub device. > >> At the first time, the hub->maxchild is not set and port's device was not >> created so usb port has not been bound with acpi. usb port's ACPI >> information is >> not accessible at that time. The usb_get_hub_port_connect_type will return >> type_unkown. >> The value returned by first time of call get_hub_descriptor() will not be >> correct. > > Now I see the problem. The code you're adding to ehci-hub.c relies on > the hub driver knowing about the root hub's ports beforehand. So > you've got a circular dependency: > > ehci-hub.c depends on the hub driver knowing about the > root hub's ports; > > The hub driver learns the root-hub port connectivity > information by asking ehci-hub.c. > > The way to break this circle is to make ehci-hub.c use the ACPI > information directly rather than going through the hub driver's data > structures. But it's necessary to bind usb port with ACPI before using ACPI information. Otherwise there is no bright between usb port and it's ACPI information. Binding will be done during port's devices creating. Creating port's devices need port number of the root hub. So this must happen after first time of calling get_hub_descriptor. In short, there is a sequence of following steps. call get_hub_descriptor() || get port number, create port's device || bind usb ports with acpi and get ACPI information || set desc->u.hs.DeviceRemovable > > Alan Stern > -- Best regards Tianyu Lan -- 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
Hi, On Sat, Aug 25, 2012 at 3:33 PM, Marc Kleine-Budde wrote: > 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? IMHO, USB_PHY_TYPE_DT does not qualify to be a phy type. USB_PHY_TYPE_USB2 makes more sense to me. Thanks Kishon -- 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
Hi,
On Sat, Aug 25, 2012 at 11:43 PM, Marc Kleine-Budde wrote:
> 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
Re: USB sound card device complains about "error -28: not enough bandwidth" only on specific PC hardware, seems not kernel specific
On Sun, 26 Aug 2012, David Ranch wrote: > Hello Alan, > > > 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. > Geee... I feel honored! (g) That's usually my luck with Linux but > I've always been a glutton for punishment, I mean, up for the challenge > so I'll keep at it. ;-) Of course, the nice thing about Linux is that you have a decent chance of actually improving the situation. :-) > > 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 > > Something is a miss here as that path ( /sys/kernel/debug/usb/ehci ) > doesn't exist and I'm also getting new hourly errors complaining about > missing proc entries like: > > /sys/devices/system/cpu/sched_mc_power_savings > > I imagine it might be a specific issue with this modern kernel running > on "old.. centos6 kernel) so I've posted my kernel config here: > > > http://www.trinityos.com/SCRATCH/3.5.2-1.ax25.el6.x86_64 > . . . > -rw-r--r-- 1 dranch dranch 130080 Aug 26 12:24 kernel-ml-3.5.2-config.txt > -rw-r--r-- 1 dranch dranch 353212 Aug 26 12:24 usbdebug-sys-dir.txt > > If you can help me figure out why the EHCI debug interface isn't showing > up (maybe the /proc line is a hint), I'll recompile and get the results > you asked for. I don't know about those error messages. As for the missing USB debug directories, what you show is typical for a system where CONFIG_USB_DEBUG is not enabled. Are you sure that you are really running the new kernel and modules? Getting it to work right may require creating a new initramfs image; some systems load the USB drivers from there. 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 v2] block: remove the deprecated ub driver
On Sun, Aug 26, 2012 at 09:36:23PM +0200, Sebastian Andrzej Siewior wrote: > On Sun, Aug 26, 2012 at 02:40:07PM +0800, Cong Wang wrote: > > From: Cong Wang > > > > It is scheduled to be removed in 3.6. > > Greg, I haven't look at it yet but I assume this is a simple file removal. > Unless you have other plans, I would take this and send it you together with > the > removal of libusual as you asked. Why not just send a follow-on patch to do the libusual fixups instead? greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch v2] block: remove the deprecated ub driver
On Sun, Aug 26, 2012 at 02:40:07PM +0800, Cong Wang wrote: > From: Cong Wang > > It is scheduled to be removed in 3.6. Greg, I haven't look at it yet but I assume this is a simple file removal. Unless you have other plans, I would take this and send it you together with the removal of libusual as you asked. 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
[PATCH] usb: dwc3: memory ordering fix in close
From: Oliver Neukum As a bitmap is used for free/used. As a device freed all memory operations must be scheduled before the bitmap is manipulated. Signed-off-by: Oliver Neukum --- drivers/usb/dwc3/core.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index c34452a..dcc10ac 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -99,6 +99,7 @@ void dwc3_put_device_id(int id) ret = test_bit(id, dwc3_devs); WARN(!ret, "dwc3: ID %d not in use\n", id); + smp_mb__before_clear_bit(); clear_bit(id, dwc3_devs); } EXPORT_SYMBOL_GPL(dwc3_put_device_id); -- 1.7.7 -- 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, 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. Geee... I feel honored! (g) That's usually my luck with Linux but I've always been a glutton for punishment, I mean, up for the challenge so I'll keep at it. ;-) 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 Something is a miss here as that path ( /sys/kernel/debug/usb/ehci ) doesn't exist and I'm also getting new hourly errors complaining about missing proc entries like: /sys/devices/system/cpu/sched_mc_power_savings I imagine it might be a specific issue with this modern kernel running on "old.. centos6 kernel) so I've posted my kernel config here: http://www.trinityos.com/SCRATCH/3.5.2-1.ax25.el6.x86_64 . . . -rw-r--r-- 1 dranch dranch 130080 Aug 26 12:24 kernel-ml-3.5.2-config.txt -rw-r--r-- 1 dranch dranch 353212 Aug 26 12:24 usbdebug-sys-dir.txt If you can help me figure out why the EHCI debug interface isn't showing up (maybe the /proc line is a hint), I'll recompile and get the results you asked for. --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 V2] usb: gadget: bcm63xx UDC driver
On Tue, Aug 21, 2012 at 06:30:19PM -0700, Kevin Cernekee wrote: > use_fullspeed=1 just tells the core not to negotiate USB 2.0 PHY > rates. It should be roughly equivalent to plugging the device into a > full speed hub. Okay, understood. 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 V3] usb: gadget: bcm63xx UDC driver
On Sat, Aug 25, 2012 at 12:44:19PM -0700, Kevin Cernekee wrote: > 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. Okay. Then it works as requested :) > > - 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 exactly > 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 Okay. This sounds good. > 11) Data/status phases are handled as usual Please tell you HW vendor that this auto ack feature is complete non sense unless you already have :) 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: [RFC PATCH 2/2] USB: Set usb port's DevicerRemovable according acpi information in EHCI
On Sun, 26 Aug 2012, Lan Tianyu wrote: > �� 2012/8/24 22:45, Alan Stern �: > > On Fri, 24 Aug 2012, Lan Tianyu wrote: > > > But if other places got hub descriptor, they can't get DeviceRemovable > value since we only set DeviceRemovable in the hub_configure().(e.g > lsusb). > > > > Note: This isn't true. You now set desc->u.hs.DeviceRemovable in > > ehci_hub_descriptor(). > Oh. Sorry. I maybe confuse you or make you misunderstand due to my broken > descriptor. Do you agree set desc->u.hs.DeviceRemovable in > ehci_hub_descriptor()? Yes. Ideally, those bits should be set even if the hub driver isn't bound to the root hub device. > At the first time, the hub->maxchild is not set and port's device was not > created so usb port has not been bound with acpi. usb port's ACPI information > is > not accessible at that time. The usb_get_hub_port_connect_type will return > type_unkown. > The value returned by first time of call get_hub_descriptor() will not be > correct. Now I see the problem. The code you're adding to ehci-hub.c relies on the hub driver knowing about the root hub's ports beforehand. So you've got a circular dependency: ehci-hub.c depends on the hub driver knowing about the root hub's ports; The hub driver learns the root-hub port connectivity information by asking ehci-hub.c. The way to break this circle is to make ehci-hub.c use the ACPI information directly rather than going through the hub driver's data structures. 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: [RFC PATCH 2/2] USB: Set usb port's DevicerRemovable according acpi information in EHCI
于 2012/8/24 22:45, Alan Stern 写道:
> On Fri, 24 Aug 2012, Lan Tianyu wrote:
>
But if other places got hub descriptor, they can't get DeviceRemovable
value since we only set DeviceRemovable in the hub_configure().(e.g lsusb).
>
> Note: This isn't true. You now set desc->u.hs.DeviceRemovable in
> ehci_hub_descriptor().
Oh. Sorry. I maybe confuse you or make you misunderstand due to my broken
descriptor. Do you agree set desc->u.hs.DeviceRemovable in
ehci_hub_descriptor()?
>
>>> I don't understand. lsusb will be able to see the DeviceRemovable
>>> values in sysfs, won't it?
>> lsusb will issue get hub descriptor request in the usr space and print
>> DeviceRemovable.
>
> Sure, that's right. But that's not what I was complaining about -- I
> was complaining about the fact the you want to call
> get_hub_descriptor() twice.
>
>> So if we put setting DeviceRemovable in the hcd's hub descriptor request
>> routine, usr space could also get acpi information via getting hub
>> descriptor and we don't need to expose DeviceRemovable sysfs file.
>
> Userspace doesn't use get_hub_descriptor() (it calls usb_control_msg()
> directly). Therefore you don't need to set any DeviceRemovable
> information in that routine.
Yeah. If we set desc->u.hs.DeviceRemovable in ehci_hub_descriptor(), this
will be no problem.
>
Another problem is that some hcds will set DeviceRemovable themselves.
There will be a conflict between hcd and acpi information. Different
hcds may have different processes.
>>>
>>> There is always the possibility of a conflict. This remains true
>>> whether you get the hub descriptor once or twice.
>> Yeah. how to deal with conflict
>> First time of getting the hub descriptor is to initialize hub and create
>> port devices. The second time is to update DeviceRemovable after
>> port devices create.
>
> Look, I can't tell exactly what's going on here because I can't see
> your code. It isn't present in any trees that I have access to, and I
> can't see what's going on by trying to read multiple patches spread
> over several email threads.
Yeah. That is the problem since my previous patchset still is not
merged in the usb-next. But I also want to make this some progress. Do
you have some suggestiones? I have thought of sending these patches with
my previous patch. But it will make the whole patchset's version number
increase quickly which may be nice. Since previous patches maybe relative
stable.
> Furthermore, I don't see why you need to update
> hub->descriptor->u.hs.DeviceRemovable at all. The value returned by
> hub_configure() the first time will be correct; there's no reason to
> call get_hub_descriptor() a second time.
At the first time, the hub->maxchild is not set and port's device was not
created so usb port has not been bound with acpi. usb port's ACPI information is
not accessible at that time. The usb_get_hub_port_connect_type will return
type_unkown.
The value returned by first time of call get_hub_descriptor() will not be
correct.
You can see follow link to find related code.
http://marc.info/?l=linux-usb&m=134517695107183&w=2
@@ -181,7 +182,7 @@ static inline char *portspeed(struct usb_hub *hub, int
portstatus)
/* Note that hdev or one of its children must be locked! */
static struct usb_hub *hdev_to_hub(struct usb_device *hdev)
{
- if (!hdev || !hdev->actconfig)
+ if (!hdev || !hdev->actconfig || !hdev->maxchild)
return NULL;
return usb_get_intfdata(hdev->actconfig->interface[0]);
}
http://marc.info/?l=linux-usb&m=134553867601771&w=2
@@ -5254,6 +5258,9 @@ usb_get_hub_port_connect_type(struct usb_device *hdev, int
port1)
{
struct usb_hub *hub = hdev_to_hub(hdev);
+ if (!hub)
+ return USB_PORT_CONNECT_TYPE_UNKNOWN;
+
return hub->ports[port1 - 1]->connect_type;
}
My original thought of calling get_hub_descriptor() a second time is that after
the port's device created and hub->maxchild has been set, the
usb_get_hub_port_connect_type()
will work. So call again to set desc->u.hs.DeviceRemovable in
ehci_hub_descriptor().
--
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.
Please use Reply-To-All so that your messages go to the mailing list as
well as to me.
On Sun, 26 Aug 2012, adam ? wrote:
> I am sending to you three attachments.
> Thanks for help!
>
> Dnia 26-08-2012 o godz. 4:15 Alan Stern napisa�(a):
> > 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
The usbmon log shows that your device is buggy. The patch below should
work around the bug. I have no idea why it works okay under VirtualBox
or VMWare.
Alan Stern
Index: usb-3.5/drivers/usb/core/quirks.c
===
--- usb-3.5.orig/drivers/usb/core/quirks.c
+++ usb-3.5/drivers/usb/core/quirks.c
@@ -71,6 +71,10 @@ static const struct usb_device_id usb_qu
{ USB_DEVICE(0x04b4, 0x0526), .driver_info =
USB_QUIRK_CONFIG_INTF_STRINGS },
+ /* Microchip Joss Optical device */
+ { USB_DEVICE(0x04d8, 0x000c), .driver_info =
+ USB_QUIRK_CONFIG_INTF_STRINGS },
+
/* Samsung Android phone modem - ID conflict with SPH-I500 */
{ USB_DEVICE(0x04e8, 0x6601), .driver_info =
USB_QUIRK_CONFIG_INTF_STRINGS },
--
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 08/26/2012 10:01 AM, Sarah Sharp wrote: > 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. Thanks for your response, and pick up this small patch. I am sorry, if you thought I want press you on a such small issue. Actually, I just went to have a kindly reminder. Thanks again for your consideration and maintain job! > > Sarah Sharp -- Thanks Alex -- 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
