Re: [PATCH 21/22] usbip: vhci_hcd: use USB_DT_HUB
On Sun, Mar 29, 2015 at 12:45 AM, Sergei Shtylyov
sergei.shtyl...@cogentembedded.com wrote:
Fix using the bare number to set the 'bDescriptorType' field of the Hub
Descriptor while the value is #define'd in linux/usb/ch11.h.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
drivers/usb/usbip/vhci_hcd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: usb/drivers/usb/usbip/vhci_hcd.c
===
--- usb.orig/drivers/usb/usbip/vhci_hcd.c
+++ usb/drivers/usb/usbip/vhci_hcd.c
@@ -216,7 +216,7 @@ done:
static inline void hub_descriptor(struct usb_hub_descriptor *desc)
{
memset(desc, 0, sizeof(*desc));
- desc-bDescriptorType = 0x29;
+ desc-bDescriptorType = USB_DT_HUB;
desc-bDescLength = 9;
desc-wHubCharacteristics = __constant_cpu_to_le16(
HUB_CHAR_INDV_PORT_LPSM | HUB_CHAR_COMMON_OCPM);
Acked-by: Valentina Manea valentina.mane...@gmail.com
--
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
bus powered hub reported as self powered
Hi all,
I'm on USB certification of a vendor SoC, and there's a case called
Bus powered hub power exceeded test in the compliance plan defined
by the usb.org. It requires an error message when a device (Max power
descriptor 100mA) is attached to an external bus powered hub.
But when I attached the bus powered hub to Linux (Ubuntu 14.04), I
found that it always reported as self powered
Bus 002 Device 026: ID 1a40:0801 Terminus Technology Inc.
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 1 Single TT
bMaxPacketSize064
idVendor 0x1a40 Terminus Technology Inc.
idProduct 0x0801
bcdDevice1.00
iManufacturer 0
iProduct1 USB 2.0 Hub
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes3
Transfer TypeInterrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 12
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 4
wHubCharacteristic 0x
Ganged power switching
Ganged overcurrent protection
TT think time 8 FS bits
bPwrOn2PwrGood 50 * 2 milli seconds
bHubContrCurrent100 milli Ampere
DeviceRemovable0x00
PortPwrCtrlMask0xff
Hub Port Status:
Port 1: .0100 power
Port 2: .0100 power
Port 3: .0100 power
Port 4: .0100 power
Device Qualifier (for other device speed):
bLength10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize064
bNumConfigurations 1
Device Status: 0x0001
Self Powered
And I've checked the source code in drivers/usb/core/hub.c
1521 if (hdev == hdev-bus-root_hub) {
1522 if (hcd-power_budget 0)
1523 hdev-bus_mA = hcd-power_budget;
1524 else
1525 hdev-bus_mA = full_load * maxchild;
1526 if (hdev-bus_mA = full_load)
1527 hub-mA_per_port = full_load;
1528 else {
1529 hub-mA_per_port = hdev-bus_mA;
1530 hub-limited_power = 1;
1531 }
1532 } else if ((hubstatus (1 USB_DEVICE_SELF_POWERED))
== 0) {
1533 int remaining = hdev-bus_mA -
1534 hub-descriptor-bHubContrCurrent;
1535
1536 dev_dbg(hub_dev, hub controller current
requirement: %dmA\n,
1537 hub-descriptor-bHubContrCurrent);
1538 hub-limited_power = 1;
1539
1540 if (remaining maxchild * unit_load)
1541 dev_warn(hub_dev,
1542 insufficient power
available
1543 to use all downstream
ports\n);
1544 hub-mA_per_port = unit_load; /* 7.2.1 */
1545
1546 } else {/* Self-powered external hub */
1547 /* FIXME: What about battery-powered external
hubs that
1548 * provide less current per port? */
1549 hub-mA_per_port = full_load;
1550 }
The hub-mA_per_port is always set as full_load (500mA for usb 2.0
hub) since reported as self powered hub.
So when I attach a usb device with ( 100mA Max power descriptor =
500mA), linux won't show error messages.
I'm wondering why the bus powered hub reported as self powered? And is
any switch to make it bus powered?
Thanks!
Regards
Rong
--
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: External USB3 HDD: logical sector size incorrectly detected on first connect
(Sorry for the belated response.) Am Mon, 23 Mar 2015 17:14:27 -0400 (EDT) schrieb Alan Stern st...@rowland.harvard.edu: On Mon, 23 Mar 2015, Marc Joliet wrote: OK, so obviously the drive is doing something wrong. I'm just confused about why one way works and not the other: - Boot up the computer with the drive attached: failure. - Boot up the computer without the drive attached, load the required kernel modules, and plug it in: success. I would think that, if it's solely the drive's fault, neither case would work, since in both cases I'm plugging the drive in for the first time and it has not spun up yet, and in both cases the uas and usb-storage modules are loaded beforehand (albeit with a larger delay in the second case). That is: what is the difference from the drive's perspective? Like Matt suggested, the most reasonable possibility is an interaction with the BIOS. Like I said in my replay to Matt, the BIOS doesn't support booting via USB. The only thing I was able to try was to deactivate CD boot, which didn't change anything (except make boot faster, which is a nice side-effect, since I only very rarely boot from CD). I tried hooking it up to a borrowed laptop I have here (that only has USB 2 ports) to see how it behaves at boot. The BIOS was set to boot form its internal drive (followed by USB, but that would only trigger if the internal drive were missing, so it shouldn't have any influence, right?), and it behaved the same. (Also, why does Windows, without any manually installed drivers, work, then?) No way to know unless you can trace the communication between Windows and the drive. There are a few USB sniffer programs available for Windows, but I don't know if you'll be able to get them to start before Windows has detected the drive. If I have the time and motivation to do this, I can certainly try. This, and all the other situations I described where the drive worked fine (such as turning the drive off for several hours), make me wonder whether you or anybody else on this list know of any drives/usb adapters that behave in strange ways when they are connected at boot up like this (for example, I read of older drives that would initially announce themselves as CD-ROM drives). There are plenty of devices which do that. The manufacturers store drivers, manuals, and other information on the emulated CDs. No, I don't know of any devices with other crazy behaviors. But then I don't try to keep track of such things. OK Of course, if the diagnosis is definitely the drive did it, then I'm willing to resign myself to the notion that nothing can be done about it, however disappointing that would be. Well, it may be possible to replace the adapter. Or, if you can find out what Windows does, it may be possible to make Linux do the same thing. I like the latter option better, since I wouldn't be surprised if many (or at least several) external HDDs do things like this. All the more so since the links from my OP are several years old already (2013 and 2010, respectively). Regardless, thanks to you (and also to Matthew) for your help. I'll just have to accept the problem as it is, and maybe revisit it in the future as mentioned above. Of course, if I'm lucky, a developer here will obtain such a drive first and then get Linux to work well with it :) . Thanks again, -- Marc Joliet -- People who think they know everything really annoy those of us who know we don't - Bjarne Stroustrup pgpqXe7meWvfd.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH V9 02/10] USB: f81232: implement RX bulk-in EP
Hello, Thanks for your kindly support and code review. It's my honor to work with you :D Johan Hovold 於 2015/3/28 上午 12:17 寫道: I'll apply the whole series now. Thanks again for fixing up this driver! Johan -- With Best Regards, Peter Hung -- 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: bus powered hub reported as self powered
Hi Alan, Thanks for the confirmative answer, since I suspect it's the bug of the hub first, but all the three hubs at my hand report the same status. I can see why the hubs are reported as self powered, e.g. if there's a device configured with max power equals to 120 mA, if the hub is self powered, the configuration will be rejected by kernel. But if it's reported as self powered, per port power limit is 500 mA, so the device may be configured and maybe work normal. But will it cause a runtime error? Say I have a embeded usb host which can supply 500 mA at most, when the hub reported as self powered and attached with two devices both with max power equals to 250 mA. Both device can be configured, but if they are both working at the most power requirement at the same time, there should be some power problem, right? Regards Rong On Tue, Mar 31, 2015 at 9:48 PM, Alan Stern st...@rowland.harvard.edu wrote: On Tue, 31 Mar 2015, Rong Wang wrote: Hi all, I'm on USB certification of a vendor SoC, and there's a case called Bus powered hub power exceeded test in the compliance plan defined by the usb.org. It requires an error message when a device (Max power descriptor 100mA) is attached to an external bus powered hub. But when I attached the bus powered hub to Linux (Ubuntu 14.04), I found that it always reported as self powered ... The hub-mA_per_port is always set as full_load (500mA for usb 2.0 hub) since reported as self powered hub. So when I attach a usb device with ( 100mA Max power descriptor = 500mA), linux won't show error messages. I'm wondering why the bus powered hub reported as self powered? And is any switch to make it bus powered? The reason is simple: The hub is buggy. It tells the computer that it is self-powered even though it isn't. No, there is no switch to fix it. 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: External USB3 HDD: logical sector size incorrectly detected on first connect
On Tue, 31 Mar 2015, Marc Joliet wrote: Like Matt suggested, the most reasonable possibility is an interaction with the BIOS. Like I said in my replay to Matt, the BIOS doesn't support booting via USB. The If it supports a USB keyboard, it might still go through and initialize all the USB devices. only thing I was able to try was to deactivate CD boot, which didn't change anything (except make boot faster, which is a nice side-effect, since I only very rarely boot from CD). I tried hooking it up to a borrowed laptop I have here (that only has USB 2 ports) to see how it behaves at boot. The BIOS was set to boot form its internal drive (followed by USB, but that would only trigger if the internal drive were missing, so it shouldn't have any influence, right? Impossible to tell. A BIOS can do anything it wants, whether it makes sense or not. You'd have to monitor the USB bus to see what packets were actually exchanged. To find out what the USB adapter is really doing, the best approach is to ask the manufacturer -- since nobody else knows. The odds of getting a useful reply are not high, unfortunately. 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 0/6] Allow UVC devices to remain runtime-suspended when sleeping
Hi, this series contain what I needed to do in order to have my USB webcam to not be resumed when the system resumes, reducing considerably the total time that resuming takes. It makes use of the facility that Rafael Wysocki added in aae4518b3 (PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily), which requires that a devices and all its descendants opt-in by having their dev_pm_ops.prepare callback return 1, to have runtime PM enabled, and to be runtime suspended when the system goes to a sleep state. Thanks, Tomeu Tomeu Vizoso (6): [media] uvcvideo: Enable runtime PM of descendant devices [media] v4l2-core: Implement dev_pm_ops.prepare() Input: Implement dev_pm_ops.prepare() [media] media-devnode: Implement dev_pm_ops.prepare callback Input: evdev - Enable runtime PM of the evdev input handler USB / PM: Allow USB devices to remain runtime-suspended when sleeping drivers/input/evdev.c | 3 +++ drivers/input/input.c | 13 + drivers/media/media-devnode.c | 10 ++ drivers/media/usb/uvc/uvc_driver.c | 4 drivers/media/usb/uvc/uvc_status.c | 3 +++ drivers/media/v4l2-core/v4l2-dev.c | 10 ++ drivers/usb/core/endpoint.c| 17 + drivers/usb/core/message.c | 16 drivers/usb/core/port.c| 6 ++ drivers/usb/core/usb.c | 2 +- 10 files changed, 83 insertions(+), 1 deletion(-) -- 2.3.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.kernel.org/majordomo-info.html
Re: [PATCH 6/6] USB / PM: Allow USB devices to remain runtime-suspended when sleeping
On Tue, 31 Mar 2015, Tomeu Vizoso wrote:
Have dev_pm_ops.prepare return 1 for USB devices, interfaces, endpoints
and ports so that USB devices can remain runtime-suspended when the
system goes to a sleep state.
Also enable runtime PM for endpoints, which is another requirement for
the above to work.
Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
...
diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
index b1fb9ae..1498faa 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -300,7 +300,7 @@ static int usb_dev_uevent(struct device *dev, struct
kobj_uevent_env *env)
static int usb_dev_prepare(struct device *dev)
{
- return 0; /* Implement eventually? */
+ return 1; /* Implement eventually? */
}
The rest of the patch is okay, but this part is wrong. The documented
requirement is that the prepare callback should return 1 if the device
is already in the appropriate state. This means it has to have the
right wakeup setting.
In other words, if the device is currently in runtime suspend with
remote wakeup enabled, but device_may_wakeup() returns 0 (so that the
device should be disabled for wakeup when the system goes into
suspend), then the prepare callback has to return 0.
Therefore what you need to do here is something like this:
struct usb_device *udev = to_usb_device(dev);
/* Return 0 if the current wakeup setting is wrong, otherwise 1 */
if (udev-do_remote_wakeup !device_may_wakeup(dev))
return 0;
return 1;
Aside from this issue, I like the patch set. Do you think you can do
something similar for drivers/scsi/scsi_pm.c? I'm not aware of any
wakeup-capable SCSI devices -- not disk or CD/DVD drives, anyway.
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 6/6] USB / PM: Allow USB devices to remain runtime-suspended when sleeping
Have dev_pm_ops.prepare return 1 for USB devices, interfaces, endpoints
and ports so that USB devices can remain runtime-suspended when the
system goes to a sleep state.
Also enable runtime PM for endpoints, which is another requirement for
the above to work.
Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
---
drivers/usb/core/endpoint.c | 17 +
drivers/usb/core/message.c | 16
drivers/usb/core/port.c | 6 ++
drivers/usb/core/usb.c | 2 +-
4 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/endpoint.c b/drivers/usb/core/endpoint.c
index 39a2402..7c82bb7 100644
--- a/drivers/usb/core/endpoint.c
+++ b/drivers/usb/core/endpoint.c
@@ -160,6 +160,19 @@ static const struct attribute_group *ep_dev_groups[] = {
NULL
};
+#ifdef CONFIG_PM
+
+static int usb_ep_device_prepare(struct device *dev)
+{
+ return 1;
+}
+
+static const struct dev_pm_ops usb_ep_device_pm_ops = {
+ .prepare = usb_ep_device_prepare,
+};
+
+#endif /* CONFIG_PM */
+
static void ep_device_release(struct device *dev)
{
struct ep_device *ep_dev = to_ep_device(dev);
@@ -170,6 +183,9 @@ static void ep_device_release(struct device *dev)
struct device_type usb_ep_device_type = {
.name = usb_endpoint,
.release = ep_device_release,
+#ifdef CONFIG_PM
+ .pm = usb_ep_device_pm_ops,
+#endif
};
int usb_create_ep_devs(struct device *parent,
@@ -197,6 +213,7 @@ int usb_create_ep_devs(struct device *parent,
goto error_register;
device_enable_async_suspend(ep_dev-dev);
+ pm_runtime_enable(ep_dev-dev);
endpoint-ep_dev = ep_dev;
return retval;
diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index f368d20..9041aee 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -1589,10 +1589,26 @@ static int usb_if_uevent(struct device *dev, struct
kobj_uevent_env *env)
return 0;
}
+#ifdef CONFIG_PM
+
+static int usb_if_prepare(struct device *dev)
+{
+ return 1;
+}
+
+static const struct dev_pm_ops usb_if_pm_ops = {
+ .prepare = usb_if_prepare,
+};
+
+#endif /* CONFIG_PM */
+
struct device_type usb_if_device_type = {
.name = usb_interface,
.release = usb_release_interface,
.uevent = usb_if_uevent,
+#ifdef CONFIG_PM
+ .pm = usb_if_pm_ops,
+#endif
};
static struct usb_interface_assoc_descriptor *find_iad(struct usb_device *dev,
diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
index 2106183..f49707d 100644
--- a/drivers/usb/core/port.c
+++ b/drivers/usb/core/port.c
@@ -168,12 +168,18 @@ static int usb_port_runtime_suspend(struct device *dev)
return retval;
}
+
+static int usb_port_prepare(struct device *dev)
+{
+ return 1;
+}
#endif
static const struct dev_pm_ops usb_port_pm_ops = {
#ifdef CONFIG_PM
.runtime_suspend = usb_port_runtime_suspend,
.runtime_resume = usb_port_runtime_resume,
+ .prepare = usb_port_prepare,
#endif
};
diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
index b1fb9ae..1498faa 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -300,7 +300,7 @@ static int usb_dev_uevent(struct device *dev, struct
kobj_uevent_env *env)
static int usb_dev_prepare(struct device *dev)
{
- return 0; /* Implement eventually? */
+ return 1; /* Implement eventually? */
}
static void usb_dev_complete(struct device *dev)
--
2.3.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.kernel.org/majordomo-info.html
Re: [PATCH 1/3] phy: core: Add devm_of_phy_get_by_index to phy-core
On Friday 27 March 2015 04:37 AM, Dmitry Torokhov wrote: On Wed, Mar 25, 2015 at 05:04:32PM -0700, Arun Ramamurthy wrote: On 15-03-25 03:03 PM, Kishon Vijay Abraham I wrote: Hi, On Saturday 21 March 2015 02:59 AM, Arun Ramamurthy wrote: On 15-03-20 02:26 PM, Dmitry Torokhov wrote: Hi Arun, On Fri, Mar 20, 2015 at 02:07:08PM -0700, Arun Ramamurthy wrote: Adding devm_of_phy_get_by_index to get phys by supplying an index and not a phy name when multiple phys are declared I think a bit more explanation on why get_by_index is needed here. Thanks Kison. Can you be more specific? I am unsure of what more I can explain here. We just need to mention that some generic drivers, such as ehci, may use multiple phys, and for such drivers referencing phy(s) by name(s) does not make sense. Instead of inventing elaborate naming schemes and producing custom code to iterate over names, such drivers are better of using nameless phy bindings and using this newly introduced API to iterate through them. +1 -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
usb: gadget: f_fs: O_NONBLOCK waits MAX_SCHEDULE_TIMEOUT
Hi,
I have been looking at an issue where a phone that is the Function FS
host sometimes locks up and causes the function:
static ssize_t ffs_epfile_io(struct file *file, struct ffs_io_data
*io_data) in drivers/usb/gadget/function/f_fs.c to timeout after
MAX_SCHEDULE_TIMEOUT jiffies.
We are opening the ffs connection with the O_NONBLOCK option and this
timeout seems to be far too long.
The code causing the wait is here (line 834):
if (unlikely(ret 0)) {
/* nop */
} else if (unlikely(
wait_for_completion_interruptible(done))) {
ret = -EINTR;
usb_ep_dequeue(ep-ep, req);
} else {
The function call wait_for_completion_interruptible(done) equates to:
wait_for_completion_interruptible_timeout(done, MAX_SCHEDULE_TIMEOUT);
I was wondering what to change to fix this, is it reasonable to use a
very small timeout if it is O_NONBLOCK or is any blocking not allowed?
I would appreciate any thoughts on how this should work?
Thank you,
Jim
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: gadget: f_fs: O_NONBLOCK waits MAX_SCHEDULE_TIMEOUT
Hi,
(it helps if you Cc the maintainer too :-)
On Tue, Mar 31, 2015 at 07:53:39PM +0100, Baxter, Jim wrote:
I have been looking at an issue where a phone that is the Function FS
host sometimes locks up and causes the function:
which USB controller ? which kernel ? which platform ?
static ssize_t ffs_epfile_io(struct file *file, struct ffs_io_data
*io_data) in drivers/usb/gadget/function/f_fs.c to timeout after
MAX_SCHEDULE_TIMEOUT jiffies.
yeah, that's pretty much never timeout :-)
We are opening the ffs connection with the O_NONBLOCK option and this
timeout seems to be far too long.
is this your own application ? How can I make sure it's correct ?
The code causing the wait is here (line 834):
if (unlikely(ret 0)) {
/* nop */
} else if (unlikely(
wait_for_completion_interruptible(done))) {
right, this is waiting for the previous usb_ep_queue() to complete. Why
hasn't it completed yet ? Do you have a USB sniffer to check if data has
passed over the wire ? Did the host shifted any token in the wire trying
to move data around ?
ret = -EINTR;
usb_ep_dequeue(ep-ep, req);
} else {
The function call wait_for_completion_interruptible(done) equates to:
wait_for_completion_interruptible_timeout(done, MAX_SCHEDULE_TIMEOUT);
I was wondering what to change to fix this, is it reasonable to use a
very small timeout if it is O_NONBLOCK or is any blocking not allowed?
I would appreciate any thoughts on how this should work?
sounds like a bug on your USB peripheral controller driver. Which one is
that ? Again, which kernel ? Where are the logs ?
regards
--
balbi
signature.asc
Description: Digital signature
Re: bus powered hub reported as self powered
On Tue, 31 Mar 2015, Rong Wang wrote: Hi all, I'm on USB certification of a vendor SoC, and there's a case called Bus powered hub power exceeded test in the compliance plan defined by the usb.org. It requires an error message when a device (Max power descriptor 100mA) is attached to an external bus powered hub. But when I attached the bus powered hub to Linux (Ubuntu 14.04), I found that it always reported as self powered ... The hub-mA_per_port is always set as full_load (500mA for usb 2.0 hub) since reported as self powered hub. So when I attach a usb device with ( 100mA Max power descriptor = 500mA), linux won't show error messages. I'm wondering why the bus powered hub reported as self powered? And is any switch to make it bus powered? The reason is simple: The hub is buggy. It tells the computer that it is self-powered even though it isn't. No, there is no switch to fix it. 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: Errata for Freescale root-hub TT?
On Tue, 31 Mar 2015, Peter Chen wrote: I reproduced this issue, I can't see the fifth endpoints during the SoFs although the time to SoF boundary is about 800us, see attached. - At transaction 3749, the third UAC2 gadget is ready to send/receive data. - At next SoF periods, the first and the second devices send/receive data. - At transaction 3754, the third device's OUT is on the bus, but the address 11's OUT is disappeared. I reported this problem to IC team, but they are on new SoC validation periods, they said they will simulate it after new project has finished. That's great! I'm happy that you were able to duplicate the problem. Please let me know what the IC team has to say when they look at it. Do you know whether Freescale's root-hub TT implementation was done in-house? Or was it based on the old ARC/TDI IP? It's possible that a lot of different kinds of host controllers suffer from this problem. 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: Errata for Freescale root-hub TT?
On Tue, Mar 31, 2015 at 10:02:52AM -0400, Alan Stern wrote: On Tue, 31 Mar 2015, Peter Chen wrote: I reproduced this issue, I can't see the fifth endpoints during the SoFs although the time to SoF boundary is about 800us, see attached. - At transaction 3749, the third UAC2 gadget is ready to send/receive data. - At next SoF periods, the first and the second devices send/receive data. - At transaction 3754, the third device's OUT is on the bus, but the address 11's OUT is disappeared. I reported this problem to IC team, but they are on new SoC validation periods, they said they will simulate it after new project has finished. That's great! I'm happy that you were able to duplicate the problem. Please let me know what the IC team has to say when they look at it. Sure Do you know whether Freescale's root-hub TT implementation was done in-house? Or was it based on the old ARC/TDI IP? It's possible that a lot of different kinds of host controllers suffer from this problem. Afaik, It is based on chipidea IP, should be the old ARC IP, since chipidea got this IP from ARC. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
