Re: [PATCH RFC 1/4] phy: Add provision for tuning phy.
Hi, On Wed, Dec 11, 2013 at 12:08:04PM +0530, Vivek Gautam wrote: On Tue, Dec 10, 2013 at 7:31 PM, Heikki Krogerus I think setup instead of tune is much more clear and reusable. I think setup will look more like first time setting up the phy, which is rather served by init callback. This i thought would serve the purpose of over-riding certain PHY parameters, which would not have been possible at init time. Please correct my thinking if i am unable to understand your point here. OK, sorry I was not clear on this. I'm thinking the same, that this is something that is called later, for example when the controller is ready. Some ULPI phys need to be initialized, but since the controller provides the interface, it's usually not possible during init time. This hook could be used in that case as well. All I'm saying is that tune is a poor expression. You will need to add a comment explaining what the hook does in any case, so you'll have something like this is something that is called when the controller is ready or something similar. That will make it clear what it's meant for. Thanks, -- heikki -- 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 05/12] USB: ohci-at91: Use devm_*() functions
On 11/12/2013 08:31, Jingoo Han :
Use devm_*() functions to make cleanup paths simpler.
Signed-off-by: Jingoo Han jg1@samsung.com
Jingoo,
Well, these modifications are already addressed by a series written by
Boris.
[PATCH v5 0/3] usb: ohci-at91: various improvements
Thanks for your patch anyway.
Best regards.
---
drivers/usb/host/ohci-at91.c | 52 +-
1 file changed, 11 insertions(+), 41 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 29d2093..8fb80b2 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -154,43 +154,36 @@ static int usb_hcd_at91_probe(const struct hc_driver
*driver,
hcd-rsrc_start = pdev-resource[0].start;
hcd-rsrc_len = resource_size(pdev-resource[0]);
- if (!request_mem_region(hcd-rsrc_start, hcd-rsrc_len, hcd_name)) {
- pr_debug(request_mem_region failed\n);
- retval = -EBUSY;
+ hcd-regs = devm_ioremap_resource(pdev-dev, pdev-resource[0]);
+ if (IS_ERR(hcd-regs)) {
+ retval = PTR_ERR(hcd-regs);
goto err1;
}
- hcd-regs = ioremap(hcd-rsrc_start, hcd-rsrc_len);
- if (!hcd-regs) {
- pr_debug(ioremap failed\n);
- retval = -EIO;
- goto err2;
- }
-
- iclk = clk_get(pdev-dev, ohci_clk);
+ iclk = devm_clk_get(pdev-dev, ohci_clk);
if (IS_ERR(iclk)) {
dev_err(pdev-dev, failed to get ohci_clk\n);
retval = PTR_ERR(iclk);
- goto err3;
+ goto err1;
}
- fclk = clk_get(pdev-dev, uhpck);
+ fclk = devm_clk_get(pdev-dev, uhpck);
if (IS_ERR(fclk)) {
dev_err(pdev-dev, failed to get uhpck\n);
retval = PTR_ERR(fclk);
- goto err4;
+ goto err1;
}
- hclk = clk_get(pdev-dev, hclk);
+ hclk = devm_clk_get(pdev-dev, hclk);
if (IS_ERR(hclk)) {
dev_err(pdev-dev, failed to get hclk\n);
retval = PTR_ERR(hclk);
- goto err5;
+ goto err1;
}
if (IS_ENABLED(CONFIG_COMMON_CLK)) {
- uclk = clk_get(pdev-dev, usb_clk);
+ uclk = devm_clk_get(pdev-dev, usb_clk);
if (IS_ERR(uclk)) {
dev_err(pdev-dev, failed to get uclk\n);
retval = PTR_ERR(uclk);
- goto err6;
+ goto err1;
}
}
@@ -208,21 +201,6 @@ static int usb_hcd_at91_probe(const struct hc_driver
*driver,
/* Error handling */
at91_stop_hc(pdev);
- if (IS_ENABLED(CONFIG_COMMON_CLK))
- clk_put(uclk);
- err6:
- clk_put(hclk);
- err5:
- clk_put(fclk);
- err4:
- clk_put(iclk);
-
- err3:
- iounmap(hcd-regs);
-
- err2:
- release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
-
err1:
usb_put_hcd(hcd);
return retval;
@@ -246,15 +224,7 @@ static void usb_hcd_at91_remove(struct usb_hcd *hcd,
{
usb_remove_hcd(hcd);
at91_stop_hc(pdev);
- iounmap(hcd-regs);
- release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
usb_put_hcd(hcd);
-
- if (IS_ENABLED(CONFIG_COMMON_CLK))
- clk_put(uclk);
- clk_put(hclk);
- clk_put(fclk);
- clk_put(iclk);
fclk = iclk = hclk = NULL;
}
--
Nicolas Ferre
--
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 1/4] phy: Add provision for tuning phy.
On Wednesday 11 December 2013 12:08 PM, Vivek Gautam wrote:
Hi,
On Tue, Dec 10, 2013 at 7:31 PM, Heikki Krogerus
heikki.kroge...@linux.intel.com wrote:
Hi,
Thanks for reviewing this.
On Tue, Dec 10, 2013 at 04:25:23PM +0530, Vivek Gautam wrote:
Some PHY controllers may need to tune PHY post-initialization,
so that the PHY consumers can call phy-tuning at appropriate
point of time.
Signed-off-by: vivek Gautam gautam.vi...@samsung.com
---
drivers/phy/phy-core.c | 20
include/linux/phy/phy.h |7 +++
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 03cf8fb..68dbb90 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -239,6 +239,26 @@ out:
}
EXPORT_SYMBOL_GPL(phy_power_off);
+int phy_tune(struct phy *phy)
+{
+ int ret = -ENOTSUPP;
+
+ mutex_lock(phy-mutex);
+ if (phy-ops-tune) {
+ ret = phy-ops-tune(phy);
+ if (ret 0) {
+ dev_err(phy-dev, phy tuning failed -- %d\n, ret);
+ goto out;
+ }
+ }
+
+out:
+ mutex_unlock(phy-mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(phy_tune);
I think setup instead of tune is much more clear and reusable.
I think setup will look more like first time setting up the phy,
which is rather served by init callback.
This i thought would serve the purpose of over-riding certain PHY
parameters, which would not have been
possible at init time.
Please correct my thinking if i am unable to understand your point here.
how about 'calibrate'?
Thanks
Kishon
Thanks,
--
heikki
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 12/15] usb: phy: msm: Add support for secondary PHY control
Hi, On Thu, 2013-12-05 at 10:42 +, Mark Rutland wrote: On Mon, Nov 18, 2013 at 12:57:42PM +, Ivan T. Ivanov wrote: Hi Mark, On Fri, 2013-11-15 at 16:42 +, Mark Rutland wrote: On Tue, Nov 12, 2013 at 02:51:47PM +, Ivan T. Ivanov wrote: From: Ivan T. Ivanov iiva...@mm-sol.com Allow support to use 2nd HSPHY with USB2 Core. Some platforms may have configuration to allow USB controller work with any of the two HSPHYs present. By default driver configures USB core to use primary HSPHY. Add support to allow user select 2nd HSPHY using DT parameter. Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com Cc: Manu Gautam mgau...@codeaurora.org Cc: devicet...@vger.kernel.org --- .../devicetree/bindings/usb/msm-hsusb.txt |6 + drivers/usb/phy/phy-msm-usb.c | 24 ++-- include/linux/usb/msm_hsusb.h |1 + include/linux/usb/msm_hsusb_hw.h |1 + 4 files changed, 30 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/msm-hsusb.txt b/Documentation/devicetree/bindings/usb/msm-hsusb.txt index 3f21204..d105ba9 100644 --- a/Documentation/devicetree/bindings/usb/msm-hsusb.txt +++ b/Documentation/devicetree/bindings/usb/msm-hsusb.txt @@ -72,6 +72,12 @@ Optional properties: - qcom,phy-init-sequence: PHY configuration sequence. val, reg pairs terminate with -1 +- qcom,phy-num:Select number of pyco-phy to use, can be one of + 0 - PHY one, default + 1 - Second PHY + Some platforms may have configuration to allow USB + controller work with any of the two HSPHYs present. + Only one can be used at a time? Yes only one of them. Selected at driver init time. Ok. For a given platform, is it likely that both are wired up and _possibly_ usable? My guess is that this is possible :-) Regards. Ivan Thanks Mark. -- 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 1/4] phy: Add provision for tuning phy.
Hi, On Wed, Dec 11, 2013 at 1:39 PM, Heikki Krogerus heikki.kroge...@linux.intel.com wrote: Hi, On Wed, Dec 11, 2013 at 12:08:04PM +0530, Vivek Gautam wrote: On Tue, Dec 10, 2013 at 7:31 PM, Heikki Krogerus I think setup instead of tune is much more clear and reusable. I think setup will look more like first time setting up the phy, which is rather served by init callback. This i thought would serve the purpose of over-riding certain PHY parameters, which would not have been possible at init time. Please correct my thinking if i am unable to understand your point here. OK, sorry I was not clear on this. I'm thinking the same, that this is something that is called later, for example when the controller is ready. Some ULPI phys need to be initialized, but since the controller provides the interface, it's usually not possible during init time. This hook could be used in that case as well. All I'm saying is that tune is a poor expression. You will need to add a comment explaining what the hook does in any case, so you'll have something like this is something that is called when the controller is ready or something similar. That will make it clear what it's meant for. Ok, i think i should have kept a comment atleast :-( I will add proper comments above, and as suggested in the mail by Kishon, may be name it calibrate ? What do you think ? Thanks, -- heikki -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- 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 1/4] phy: Add provision for tuning phy.
Hi Kishon,
On Wed, Dec 11, 2013 at 1:47 PM, Kishon Vijay Abraham I kis...@ti.com wrote:
On Wednesday 11 December 2013 12:08 PM, Vivek Gautam wrote:
Hi,
On Tue, Dec 10, 2013 at 7:31 PM, Heikki Krogerus
heikki.kroge...@linux.intel.com wrote:
Hi,
Thanks for reviewing this.
On Tue, Dec 10, 2013 at 04:25:23PM +0530, Vivek Gautam wrote:
Some PHY controllers may need to tune PHY post-initialization,
so that the PHY consumers can call phy-tuning at appropriate
point of time.
Signed-off-by: vivek Gautam gautam.vi...@samsung.com
---
drivers/phy/phy-core.c | 20
include/linux/phy/phy.h |7 +++
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 03cf8fb..68dbb90 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -239,6 +239,26 @@ out:
}
EXPORT_SYMBOL_GPL(phy_power_off);
+int phy_tune(struct phy *phy)
+{
+ int ret = -ENOTSUPP;
+
+ mutex_lock(phy-mutex);
+ if (phy-ops-tune) {
+ ret = phy-ops-tune(phy);
+ if (ret 0) {
+ dev_err(phy-dev, phy tuning failed -- %d\n,
ret);
+ goto out;
+ }
+ }
+
+out:
+ mutex_unlock(phy-mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(phy_tune);
I think setup instead of tune is much more clear and reusable.
I think setup will look more like first time setting up the phy,
which is rather served by init callback.
This i thought would serve the purpose of over-riding certain PHY
parameters, which would not have been
possible at init time.
Please correct my thinking if i am unable to understand your point here.
how about 'calibrate'?
Hmm, seems like a better name :-)
Thanks
Kishon
Thanks,
--
heikki
--
To unsubscribe from this list: send the line unsubscribe
linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
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 04/10] usb: dwc3: use quirks to know if a particualr platform doesn't have PHY
Hi, On Mon, Dec 09, 2013 at 11:26:04AM +0200, Heikki Krogerus wrote: Can you guys explain why is something like this needed? Like with clocks and gpios, the device drivers shouldn't need to care any more if the platform has the phys or not. -ENODEV tells you your platform Shouldn't we report if a particular platform needs a PHY and not able to get it. How will a user know if a particular controller is not working because it's not able to get and initialize the PHYs? Don't you think in such cases it's better to fail (and return from probe) because the controller will not work anyway without the PHY? My point is that you do not need to separately tell this to the driver like you do with the quirks (if you did, then you would need to fix your framework and not hack the drivers). Like I said, ENODEV tells you that there is no phy on this platform for you, allowing you to safely continue. If your phy driver is not loaded, the framework already returns EPROBE_DEFER, right. Any other right. but that doesn't consider broken dt data. With quirks we'll able to tell if a controller in a particular platform has PHY or not without depending on the dt data. Broken dt data? What kind of scenario are you thinking here? Do you mean case where the dt does not describe the phy on a platform that depends on it? Shouldn't that problem be fixed in the dt and not hacked in the drivers? Or are you thinking about something else? Is there a case where something like that is actually happening? I'm guessing I'm not getting an answer to this one. Look, this patch will not work with ACPI enumerated devices. We will have a platform providing a single ACPI id, but there is a whole bunch of boards based on it and we have no way of telling which of them need/have phys to deal with and which ones don't. Thanks, -- heikki -- 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 04/10] usb: dwc3: use quirks to know if a particualr platform doesn't have PHY
On Wednesday 11 December 2013 02:23 PM, Heikki Krogerus wrote: Hi, On Mon, Dec 09, 2013 at 11:26:04AM +0200, Heikki Krogerus wrote: Can you guys explain why is something like this needed? Like with clocks and gpios, the device drivers shouldn't need to care any more if the platform has the phys or not. -ENODEV tells you your platform Shouldn't we report if a particular platform needs a PHY and not able to get it. How will a user know if a particular controller is not working because it's not able to get and initialize the PHYs? Don't you think in such cases it's better to fail (and return from probe) because the controller will not work anyway without the PHY? My point is that you do not need to separately tell this to the driver like you do with the quirks (if you did, then you would need to fix your framework and not hack the drivers). Like I said, ENODEV tells you that there is no phy on this platform for you, allowing you to safely continue. If your phy driver is not loaded, the framework already returns EPROBE_DEFER, right. Any other right. but that doesn't consider broken dt data. With quirks we'll able to tell if a controller in a particular platform has PHY or not without depending on the dt data. Broken dt data? What kind of scenario are you thinking here? Do you mean case where the dt does not describe the phy on a platform that depends on it? Shouldn't that problem be fixed in the dt and not hacked in the drivers? Or are you thinking about something else? Is there a case where something like that is actually happening? I'm guessing I'm not getting an answer to this one. Look, this patch will not work with ACPI enumerated devices. We will have a platform providing a single ACPI id, but there is a whole bunch of boards based on it and we have no way of telling which of them need/have phys to deal with and which ones don't. Alright.. I'll drop this patch then. 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 v4 10/15] usb: phy: msm: Add device tree support and binding information
Hi, On Thu, 2013-12-05 at 10:41 +, Mark Rutland wrote: On Mon, Nov 18, 2013 at 12:54:37PM +, Ivan T. Ivanov wrote: Hi Mark, On Fri, 2013-11-15 at 16:38 +, Mark Rutland wrote: On Tue, Nov 12, 2013 at 02:51:45PM +, Ivan T. Ivanov wrote: From: Ivan T. Ivanov iiva...@mm-sol.com Allows MSM OTG controller to be specified via device tree. Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com Cc: devicet...@vger.kernel.org --- .../devicetree/bindings/usb/msm-hsusb.txt | 57 +- drivers/usb/phy/phy-msm-usb.c | 79 +--- 2 files changed, 124 insertions(+), 12 deletions(-) [...] + +- dr_mode: One of host, peripheral or otg. Defaults to otg If this has a default and thus isn't required, it should be listed as optional. This is part of the standard USB bindings, Perhaps I could just refer to: Documentation/devicetree/bindings/usb/generic.txt That would be fine, but it should also be moved to the optional properties section. Ok. + +- vdccx-supply:phandle to the regulator for the vdd supply for + digital circuit operation. +- v1p8-supply: phandle to the regulator for the 1.8V supply +- v3p3-supply: phandle to the regulator for the 3.3V supply + +- qcom,otg-control: OTG control (VBUS and ID notifications) can be one of + 1 - PHY control + 2 - PMIC control + 3 - User control (via debugfs) NAK. This does not seem like a description of the hardware, and given the debugfs comment is fundamentally tied to the way Linux functions today. I will remove option 3, but rest are really property of the chipset. Can you elaborate on the diffence please? Difference is how VBUS, ID changes, Accessory and Charger detection is handled. In older chips-sets they are handled by PHY controller, while now they are handled by external PMIC logic. + +Optional properties: +- qcom,phy-init-sequence: PHY configuration sequence. val, reg pairs + terminate with -1 What is this? I'm really not keen on having arbitrary register/memory poking sequences in the dt. This is related Device Mode Eye Diagram test and values used could be different between chipsets. Ok. Then we should encode the tuning data rather than adding a mechanism to allow for writes to arbitrary addresses. Currently: for msm8226 sequence is 0x44 0x80 0x68 0x81 0x24 0x82 0x13 0x83 for msm8974 sequence is 0x63 0x81 I could reserve -1 as do not program value and document that values in this array will be written to ULPI interface with ULPI_EXT_VENDOR_SPECIFIC as base address. for msm8974 sequence will be -1 0x63 Why does it need to be terminated? Surely the size of the property tells you that it's terminated. Yes. -1 termination could be done in driver. Please do. There's no need for it to be in the DT. Thanks. Ivan Cheers, Mark. -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] usb: chipidea: msm: Use USB PHY API to control PHY state
Hi,
On Wed, 2013-12-04 at 21:38 +0800, Peter Chen wrote:
On Wed, Dec 04, 2013 at 11:35:54AM +0200, Ivan T. Ivanov wrote:
Hi Peter,
On Wed, 2013-12-04 at 13:37 +0800, Peter Chen wrote:
On Mon, Nov 11, 2013 at 04:36:09PM +0200, Ivan T. Ivanov wrote:
Hi Peter,
On Mon, 2013-11-11 at 21:59 +0800, Peter Chen wrote:
On Mon, Nov 11, 2013 at 03:35:37PM +0200, Ivan T. Ivanov wrote:
From: Ivan T. Ivanov iiva...@mm-sol.com
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 iiva...@mm-sol.com
---
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 e9624f3..338b209 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);
It will reset the PHY, but your comment is don't change PHY
settings under it
:-). This function is exported by PHY drivers, so they will know how
to handle this change.
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);
Where you have implemented .notify_disconnect?
I have not found it at your phy driver.
Yep, I will post PHY driver changes shortly. Meanwhile this should
not break existing board file based platforms, because not of them
could be compiled (HTC Dream, Halibut Board) and DT based platforms
are sill work in progress.
Hi Ivan, I am going to apply this msm chipidea patchset, but the change
in this file is different with its original meaning.
What did you mean?
CI_HDRC_CONTROLLER_RESET_EVENT - usb_phy_init()
Take wherever actions are needed to put device in known state. ?
At current code, it only sets two AHB parameters which should be only related
to controller but your patch init the whole PHY, look at msm_otg_reset,
it does many other things, like phy reset, controller reset, etc.
Does the partial otg fsm at msm_otg_sm_work will be called or not? If it is
not called, then, it is OK you just use msm_otg_reset here.
CI_HDRC_CONTROLLER_STOPPED_EVENT - usb_phy_notify_disconnect()
Emitted after ci-driver-disconnect(ci-gadget);
I just see your [PATCH v4 14/15] usb: phy: msm: Handle disconnect events,
then, it is ok now. By the way, do I need to wait your phy patches are queued,
otherwise, it may not work?
This driver is not working on MSM platforms more than year now,
since usb: gadget: ci13xxx: convert to platform device
Lets postpone this patch after changes to phy-drivers are ready.
I will post rest of the patches with fixes for your comments
shortly.
Probably I am missing something.
Have you
tested at existing platforms?
I have 8074 based DragonBoard which I used for testing.
CV Test Suite engine Chapter 9 tests are passing except
Halt Endpoint Test.
I mean with your patch, the old non-dt platform can work or not?
Regards,
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 1/1] AX88179_178A: Enable the hardware pseudo header in case of the NET_IP_ALIGN equals 0
From: Freddy Xin
On 2013年12月10日 09:01, David Miller wrote:
From: fre...@asix.com.tw
Date: Fri, 6 Dec 2013 17:58:18 +0800
From: Freddy Xin fre...@asix.com.tw
The AX88179_178A has a hardware feature that it can insert a 2-bytes pseudo
header in front of each received frame by setting the AX_RX_CTL_IPE bit.
This feature is used to let the IP header be aligned on a
doubleword-aligned address,
but the NET_IP_ALIGN may equals to 2 and the __netdev_alloc_skb_ip_align
in USBNET will
reserve 2 bytes also, so in this case the driver shouldn't enable this bit.
This patch modifies the driver to set AX_RX_CTL_IPE just in case of the
NET_IP_ALIGN equals 0.
Signed-off-by: Freddy Xin fre...@asix.com.tw
Please avoid larger than 80 column lines in your commit messages,
people use text-only tools to viee these.
Next, it makes no sense to restrict your change to NET_IP_ALIGN==0
Simply handle any case, by undoing the reservation if it's getting
in the way. If there isn't an appropriate helper for this, add one.
I think there is no way of undoing the reservation in the driver.
Can I add a flag of the driver_info, and use it to determine
whether undoing the reservation in rx_submit of usbnet?
You probably want to arrange to have save the appropriate offset in
one of the structures - so avoiding any conditionals during the allocate.
I've noticed that the RX URB are 20k bytes long.
Allocating that much physically and virtually contiguous memory for
every rx frame seems sub-optimal to say the least!
What does the skb's 'realsize' end up as?
I don't remember seeing a copy for short frames either.
ISTR there is code to debatch multiple ethernet frames from a single
URB. I think that means that an ethernet frame might end up in two URB.
I'm not sure there is code to handle that either - but I've not looked
that closely at that part of the code.
David
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h��� �G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�
[PATCH] USB: gadget: add maxpacket_limit field to struct usb_ep
This patch adds maxpacket_limit to struct usb_ep. This field contains
maximum value of maxpacket supported by driver, and is set in driver probe.
This value should be used by autoconfig() function, because value of field
maxpacket is set to value from endpoint descriptor when endpoint becomes
enabled. So when autoconfig() function will be called again for this endpoint,
maxpacket value will contain wMaxPacketSize from descriptior instead of
maximum packet size for this endpoint.
For this reason this patch adds new field maxpacket_limit which contains
value of maximum packet size (which defines maximum endpoint capabilities).
This value is used in ep_matches() function used by autoconfig().
Value of maxpacket_limit should be set in UDC driver probe function, using
usb_ep_set_maxpacket_limit() function, defined in gadget.h. This function
set choosen value to both maxpacket_limit and maxpacket fields.
This patch modifies UDC drivers by adding support for maxpacket_limit.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/amd5536udc.c | 15 +--
drivers/usb/gadget/at91_udc.c | 16
drivers/usb/gadget/atmel_usba_udc.c |5 +++--
drivers/usb/gadget/bcm63xx_udc.c|4 ++--
drivers/usb/gadget/epautoconf.c |6 +++---
drivers/usb/gadget/fotg210-udc.c|3 ++-
drivers/usb/gadget/fsl_udc_core.c |5 +++--
drivers/usb/gadget/fusb300_udc.c|4 ++--
drivers/usb/gadget/goku_udc.c |4 ++--
drivers/usb/gadget/lpc32xx_udc.c|2 +-
drivers/usb/gadget/m66592-udc.c |4 ++--
drivers/usb/gadget/mv_udc_core.c|4 ++--
drivers/usb/gadget/omap_udc.c |3 ++-
drivers/usb/gadget/pch_udc.c|6 +++---
drivers/usb/gadget/pxa25x_udc.c |1 +
drivers/usb/gadget/pxa27x_udc.c |5 -
drivers/usb/gadget/r8a66597-udc.c |4 ++--
drivers/usb/gadget/s3c-hsotg.c |2 +-
drivers/usb/gadget/s3c-hsudc.c |2 +-
drivers/usb/gadget/s3c2410_udc.c|1 +
include/linux/usb/gadget.h |8
21 files changed, 62 insertions(+), 42 deletions(-)
diff --git a/drivers/usb/gadget/amd5536udc.c b/drivers/usb/gadget/amd5536udc.c
index 54a1e29..f487e0e 100644
--- a/drivers/usb/gadget/amd5536udc.c
+++ b/drivers/usb/gadget/amd5536udc.c
@@ -446,7 +446,7 @@ static void ep_init(struct udc_regs __iomem *regs, struct
udc_ep *ep)
ep-ep.ops = udc_ep_ops;
INIT_LIST_HEAD(ep-queue);
- ep-ep.maxpacket = (u16) ~0;
+ usb_ep_set_maxpacket_limit(ep-ep,(u16) ~0);
/* set NAK */
tmp = readl(ep-regs-ctl);
tmp |= AMD_BIT(UDC_EPCTL_SNAK);
@@ -1564,12 +1564,15 @@ static void udc_setup_endpoints(struct udc *dev)
}
/* EP0 max packet */
if (dev-gadget.speed == USB_SPEED_FULL) {
- dev-ep[UDC_EP0IN_IX].ep.maxpacket = UDC_FS_EP0IN_MAX_PKT_SIZE;
- dev-ep[UDC_EP0OUT_IX].ep.maxpacket =
- UDC_FS_EP0OUT_MAX_PKT_SIZE;
+ usb_ep_set_maxpacket_limit(dev-ep[UDC_EP0IN_IX].ep,
+ UDC_FS_EP0IN_MAX_PKT_SIZE);
+ usb_ep_set_maxpacket_limit(dev-ep[UDC_EP0OUT_IX].ep,
+ UDC_FS_EP0OUT_MAX_PKT_SIZE);
} else if (dev-gadget.speed == USB_SPEED_HIGH) {
- dev-ep[UDC_EP0IN_IX].ep.maxpacket = UDC_EP0IN_MAX_PKT_SIZE;
- dev-ep[UDC_EP0OUT_IX].ep.maxpacket = UDC_EP0OUT_MAX_PKT_SIZE;
+ usb_ep_set_maxpacket_limit(dev-ep[UDC_EP0IN_IX].ep,
+ UDC_EP0IN_MAX_PKT_SIZE);
+ usb_ep_set_maxpacket_limit(dev-ep[UDC_EP0OUT_IX].ep,
+ UDC_EP0OUT_MAX_PKT_SIZE);
}
/*
diff --git a/drivers/usb/gadget/at91_udc.c b/drivers/usb/gadget/at91_udc.c
index 4cc4fd6..0353b64 100644
--- a/drivers/usb/gadget/at91_udc.c
+++ b/drivers/usb/gadget/at91_udc.c
@@ -834,7 +834,7 @@ static void udc_reinit(struct at91_udc *udc)
ep-ep.desc = NULL;
ep-stopped = 0;
ep-fifo_bank = 0;
- ep-ep.maxpacket = ep-maxpacket;
+ usb_ep_set_maxpacket_limit(ep-ep, ep-maxpacket);
ep-creg = (void __iomem *) udc-udp_baseaddr + AT91_UDP_CSR(i);
/* initialize one queue per endpoint */
INIT_LIST_HEAD(ep-queue);
@@ -1759,15 +1759,15 @@ static int at91udc_probe(struct platform_device *pdev)
/* newer chips have more FIFO memory than rm9200 */
if (cpu_is_at91sam9260() || cpu_is_at91sam9g20()) {
- udc-ep[0].maxpacket = 64;
- udc-ep[3].maxpacket = 64;
- udc-ep[4].maxpacket = 512;
- udc-ep[5].maxpacket = 512;
+ usb_ep_set_maxpacket_limit(udc-ep[0], 64);
+
uhci_hcd: Possible corruption of DMA pool uhci-td_pool
Hi, On ROSA Linux with kernel 3.10.21 with DMA debug options enabled, the kernel sometimes issues a warning about DMA pool corruption (see the log below). That happens sometimes, when the system boots or resumes from hibernation with Samson C01U USB microphone attached. The affected DMA pool is 'uhci-td_pool', uhci_alloc_td() from drivers/usb/host/uhci-hcd.c makes the relevant dma_pool_alloc() calls. Any ideas about how to find what causes this and how to fix it? Here is the relevant part of the system log: [ 22.264332] usb 2-1: new full-speed USB device number 2 using uhci_hcd [ 22.450609] usb 2-1: New USB device found, idVendor=17a0, idProduct=0001 [ 22.450626] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 22.450639] usb 2-1: Product: Samson C01U [ 22.450649] usb 2-1: Manufacturer: Samson Technologies ... [ 280.703483] retire_capture_urb: 4494 callbacks suppressed [ 284.961087] uhci_hcd :00:1d.1: dma_pool_alloc uhci_td, efb7b060 (corruped) [ 284.961087] : 00 06 00 00 af 00 00 03 a7 a7 a7 a7 a7 a7 a7 a7 [ 284.961087] 0010: a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 [ 284.961087] 0020: a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 [ 284.961087] retire_capture_urb: 4343 callbacks suppressed [ 284.961087] uhci_hcd :00:1d.1: dma_pool_alloc uhci_td, efb7b5d0 (corruped) [ 284.961087] : 00 06 00 00 af 00 00 03 a7 a7 a7 a7 a7 a7 a7 a7 [ 284.961087] 0010: a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 [ 284.961087] 0020: a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 [ 284.961087] cannot submit urb (err = -27) [ 284.961087] cannot submit urb (err = -27) [ 284.961087] cannot submit urb (err = -27) [ 284.961087] cannot submit urb (err = -27) [ 284.961087] cannot submit urb (err = -27) [ 284.961087] cannot submit urb (err = -27) [ 284.961087] cannot submit urb (err = -27) [ 284.961087] cannot submit urb (err = -27) 0xa7 is POOL_POISON_FREED. The memory pages to be allocated from the pool should be filled with such bytes. Each time I observed this problem, the first 8 bytes of the listed memory area were overwritten, with different data each time. Regards, Eugene -- Eugene Shatokhin, ROSA Laboratory. www.rosalab.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
Re: [PATCH v4 5/9] usb: s3c-hsotg: Use the new Exynos USB phy driver with the generic phy framework
On Thu, Dec 05, 2013 at 01:29:35PM +0100, Kamil Debski wrote: Change the used phy driver to the new Exynos USB phy driver that uses the generic phy framework. Signed-off-by: Kamil Debski k.deb...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- .../devicetree/bindings/usb/samsung-hsotg.txt |4 drivers/usb/gadget/s3c-hsotg.c | 11 ++- 2 files changed, 10 insertions(+), 5 deletions(-) This is only applying with fuzz against -rc3, needs an update. It's otherwise still working fine on my BCM Capri board. -Matt -- 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: BTRFS doesn't handle USB device disconnect
On Tue, 10 Dec 2013, Sarah Sharp wrote: In order to stress test the uas driver (next-gen USB storage driver), I decided to run some tests with a USB 3.0 storage device with four 10GB partitions: BTRFS, ext3, ext4, and fat32. It seems that BTRFS doesn't handle unexpected USB disconnect very well. Is that expected behavior? The BTRFS partition was created on an Ubuntu 13.10 system, with btrfs-tools version 0.19+20130705-1. On 3.12-rc6, if all partitions are mounted, and I yank the USB cable, the BTRFS filesystem still shows up as mounted. If I yank it multiple times, sometimes it's listed twice when the device is disconnected: /dev/sdb3 on /media/sarah/9f21ef28-0eac-4736-9964-db5378b877e4 type btrfs (rw,nosuid,nodev,uhelper=udisks2) /dev/sdc3 on /media/sarah/9f21ef28-0eac-4736-9964-db5378b877e41 type btrfs (rw,nosuid,nodev,uhelper=udisks2) Sometimes (but not always) when I plug it back in, I can get /dev/sdc3 listed twice: /dev/sdb3 on /media/sarah/9f21ef28-0eac-4736-9964-db5378b877e4 type btrfs (rw,nosuid,nodev,uhelper=udisks2) /dev/sdc3 on /media/sarah/9f21ef28-0eac-4736-9964-db5378b877e42 type btrfs (rw,nosuid,nodev,uhelper=udisks2) /dev/sdc1 on /media/sarah/ext3-part type ext3 (rw,nosuid,nodev,uhelper=udisks2) /dev/sdc2 on /media/sarah/ext4-part type ext4 (rw,nosuid,nodev,uhelper=udisks2) /dev/sdc4 on /media/sarah/fat32-part type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks2) /dev/sdc3 on /media/sarah/9f21ef28-0eac-4736-9964-db5378b877e41 type btrfs (rw,nosuid,nodev,uhelper=udisks2) On 3.13-rc1, the btrfs partion from the disconnected USB device continues to be listed as mounted. Yanking the cable produces some additional oops messages. It also produced a couple hard-hangs. Unfortunately, I didn't capture the dmesg during the hard-hangs, so I can't tell for sure which driver is to blame (uas, btrfs, or xhci). Does this happen with usb-storage instead of uas? What about with ehci-hcd instead of xhci-hcd? And just to be exotic, what about with dummy-hcd and the uas or g_mass_storage gadget driver? 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: gadget: add maxpacket_limit field to struct usb_ep
On Wed, 11 Dec 2013, Robert Baldyga wrote: This patch adds maxpacket_limit to struct usb_ep. This field contains maximum value of maxpacket supported by driver, and is set in driver probe. This value should be used by autoconfig() function, because value of field maxpacket is set to value from endpoint descriptor when endpoint becomes enabled. So when autoconfig() function will be called again for this endpoint, maxpacket value will contain wMaxPacketSize from descriptior instead of maximum packet size for this endpoint. For this reason this patch adds new field maxpacket_limit which contains value of maximum packet size (which defines maximum endpoint capabilities). This value is used in ep_matches() function used by autoconfig(). Value of maxpacket_limit should be set in UDC driver probe function, using usb_ep_set_maxpacket_limit() function, defined in gadget.h. This function set choosen value to both maxpacket_limit and maxpacket fields. This patch modifies UDC drivers by adding support for maxpacket_limit. Why doesn't the patch modify the dummy-hcd UDC driver? 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: uhci_hcd: Possible corruption of DMA pool uhci-td_pool
On Wed, 11 Dec 2013, Eugene Shatokhin wrote: Hi, On ROSA Linux with kernel 3.10.21 with DMA debug options enabled, the kernel sometimes issues a warning about DMA pool corruption (see the log below). That happens sometimes, when the system boots or resumes from hibernation with Samson C01U USB microphone attached. The affected DMA pool is 'uhci-td_pool', uhci_alloc_td() from drivers/usb/host/uhci-hcd.c makes the relevant dma_pool_alloc() calls. Any ideas about how to find what causes this and how to fix it? This is not an easy sort of thing to track down... Here is the relevant part of the system log: [ 22.264332] usb 2-1: new full-speed USB device number 2 using uhci_hcd [ 22.450609] usb 2-1: New USB device found, idVendor=17a0, idProduct=0001 [ 22.450626] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 22.450639] usb 2-1: Product: Samson C01U [ 22.450649] usb 2-1: Manufacturer: Samson Technologies ... [ 280.703483] retire_capture_urb: 4494 callbacks suppressed [ 284.961087] uhci_hcd :00:1d.1: dma_pool_alloc uhci_td, efb7b060 (corruped) [ 284.961087] : 00 06 00 00 af 00 00 03 a7 a7 a7 a7 a7 a7 a7 a7 [ 284.961087] 0010: a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 [ 284.961087] 0020: a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 [ 284.961087] retire_capture_urb: 4343 callbacks suppressed [ 284.961087] uhci_hcd :00:1d.1: dma_pool_alloc uhci_td, efb7b5d0 (corruped) [ 284.961087] : 00 06 00 00 af 00 00 03 a7 a7 a7 a7 a7 a7 a7 a7 [ 284.961087] 0010: a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 [ 284.961087] 0020: a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 [ 284.961087] cannot submit urb (err = -27) [ 284.961087] cannot submit urb (err = -27) [ 284.961087] cannot submit urb (err = -27) [ 284.961087] cannot submit urb (err = -27) [ 284.961087] cannot submit urb (err = -27) [ 284.961087] cannot submit urb (err = -27) [ 284.961087] cannot submit urb (err = -27) [ 284.961087] cannot submit urb (err = -27) 0xa7 is POOL_POISON_FREED. The memory pages to be allocated from the pool should be filled with such bytes. Each time I observed this problem, the first 8 bytes of the listed memory area were overwritten, with different data each time. It kind of looks like a hardware bug. Still, it's hard to say. Can you test the current 3.13-rc kernel? There have been a few recent changes in this area that might have an effect. 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: BTRFS doesn't handle USB device disconnect
On Wed, Dec 11, 2013 at 11:03:09AM -0500, Alan Stern wrote: On Tue, 10 Dec 2013, Sarah Sharp wrote: In order to stress test the uas driver (next-gen USB storage driver), I decided to run some tests with a USB 3.0 storage device with four 10GB partitions: BTRFS, ext3, ext4, and fat32. It seems that BTRFS doesn't handle unexpected USB disconnect very well. Is that expected behavior? It's something that's been known about for a while, but is clearly undesirable behaviour. I don't think anyone with the detailed knowledge of the FS code has investigated in enough depth to get to the point of proposing patches. I suspect it's just not shown up with enough disastrous consequences to bubble to the top of the stack of things to fix yet. I think we're still at the point of you can use USB if you like, but don't be surprised if, sometimes, Bad Things happen when the bus disconnects briefly. The problems you show below do look quite like the kind of things we've seen btrfs doing on USB disconnects, so on only this evidence I wouldn't be quick to point any fingers at the USB layer (unless other filesystems corroborate the behaviour). Hugo. (I'm not a btrfs developer, but I do a reasonable amount of first-line support for it on IRC and linux-btrfs; we see these things every week or two). The BTRFS partition was created on an Ubuntu 13.10 system, with btrfs-tools version 0.19+20130705-1. On 3.12-rc6, if all partitions are mounted, and I yank the USB cable, the BTRFS filesystem still shows up as mounted. If I yank it multiple times, sometimes it's listed twice when the device is disconnected: /dev/sdb3 on /media/sarah/9f21ef28-0eac-4736-9964-db5378b877e4 type btrfs (rw,nosuid,nodev,uhelper=udisks2) /dev/sdc3 on /media/sarah/9f21ef28-0eac-4736-9964-db5378b877e41 type btrfs (rw,nosuid,nodev,uhelper=udisks2) Sometimes (but not always) when I plug it back in, I can get /dev/sdc3 listed twice: /dev/sdb3 on /media/sarah/9f21ef28-0eac-4736-9964-db5378b877e4 type btrfs (rw,nosuid,nodev,uhelper=udisks2) /dev/sdc3 on /media/sarah/9f21ef28-0eac-4736-9964-db5378b877e42 type btrfs (rw,nosuid,nodev,uhelper=udisks2) /dev/sdc1 on /media/sarah/ext3-part type ext3 (rw,nosuid,nodev,uhelper=udisks2) /dev/sdc2 on /media/sarah/ext4-part type ext4 (rw,nosuid,nodev,uhelper=udisks2) /dev/sdc4 on /media/sarah/fat32-part type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks2) /dev/sdc3 on /media/sarah/9f21ef28-0eac-4736-9964-db5378b877e41 type btrfs (rw,nosuid,nodev,uhelper=udisks2) On 3.13-rc1, the btrfs partion from the disconnected USB device continues to be listed as mounted. Yanking the cable produces some additional oops messages. It also produced a couple hard-hangs. Unfortunately, I didn't capture the dmesg during the hard-hangs, so I can't tell for sure which driver is to blame (uas, btrfs, or xhci). Does this happen with usb-storage instead of uas? What about with ehci-hcd instead of xhci-hcd? And just to be exotic, what about with dummy-hcd and the uas or g_mass_storage gadget driver? -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- UNIX: British manufacturer of modular shelving units. --- signature.asc Description: Digital signature
Re: [PATCH v2] usb: core: Make sure usb_set_configuration(-1) cannot fail
On Thu, 5 Dec 2013, Julius Werner wrote: usb_deauthorize_device() tries to unset the configuration of a USB device and then unconditionally blows away the configuration descriptors with usb_destroy_configuration(). This is bad if the usb_set_configuration() call failed before the configuration could be correctly unset, since pointers like udev-actconfig can keep pointing to the now invalid memory. We have encountered hard to reproduce crashes from devices disconnected during suspend due to this, where khubd's disconnect handling races with userspace tools that change authorization on resume. It seems desirable that a USB device can always be marked as unconfigured (reclaiming its bandwidth) in the kernel, regardless of communication problems. This patch changes usb_set_configuration() to ignore all failures in the case where no new configuration is being set. Signed-off-by: Julius Werner jwer...@chromium.org Sorry for not getting back to this sooner. Ironically, it looks like this change isn't needed any more, thanks to Thomas Pugliese's patch: http://marc.info/?l=linux-usbm=13866180520w=2 --- a/drivers/usb/core/message.c +++ b/drivers/usb/core/message.c @@ -1774,7 +1775,7 @@ free_interfaces: /* Wake up the device so we can send it the Set-Config request */ ret = usb_autoresume_device(dev); - if (ret) + if (ret cp) goto free_interfaces; That isn't quite right. If the autoresume fails then we have to skip the autosuspend call later on. 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 1/1] AX88179_178A: Enable the hardware pseudo header in case of the NET_IP_ALIGN equals 0
From: Freddy Xin fre...@asix.com.tw Date: Wed, 11 Dec 2013 14:17:59 +0800 I think there is no way of undoing the reservation in the driver. Then you should add a flag that, indeed, tells usbnet not to do the reservation in the first place. -- 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: core: Add warm reset while reset-resuming SuperSpeed HUBs
On Tue, 10 Dec 2013, Vikas Sajjan wrote: Finally, I don't see why you put this in hub_activate(). Isn't it more closely connected with the reset-resume procedure for the child device? I was trying to add a FIX in usb_port_resume(), but in our case we have CONFIG_USB_DEFAULT_PERSIST disabled. Interestingly, if I disable the CONFIG_USB_DEFAULT_PERSIST, then the function usb_port_resume() will never be called and transcend Jetflash device Suspend-to-RAM fails. I don't know what you mean by fails. The system goes to sleep and then later on wakes up, doesn't it? Do you mean that the Jetflash device gets disconnected when the system wakes up? That's _supposed_ to happen under those circumstances. When hub_activate() sees HUB_RESET_RESUME, all child devices get disconnected except those where udev-persist_enabled is set. In normal scenario (ie., CONFIG_USB_DEFAULT_PERSIST=y) the sequence is: === Step 1: For Root HUB : usb_resume_both() --- usb_resume_device() - generic_resume() -- hcd_bus_resume() -- xhci_bus_resume(). | |--usb_resume_interface() --- hub_reset_resume() -- xhci_update_hub_device() Step 2: For the Device connected usb_resume_both() --- usb_resume_device() - generic_resume()--usb_port_resume()--hub_port_logical_disconnect() You lost me there. Why does usb_port_resume call hub_port_logical_disconnect? Does this happen because check_port_resume_type returns an error code? What are the values of the portchange and portstatus arguments to check_port_resume_type? -- hub_port_disable() -- hub_usb3_port_disable(). In our scenario (ie., CONFIG_USB_DEFAULT_PERSIST=N) the sequence is: === Step 1: For Root HUB usb_resume_both() --- usb_resume_device() - generic_resume() -- hcd_bus_resume() -- xhci_bus_resume(). | |--usb_resume_interface() --- hub_reset_resume() -- xhci_update_hub_device() Step 2 : Never occurs That's exactly right. So Suspend-to-RAM fails. No, it succeeds in behaving the way it is intended to behave. Hence i added a FIX in hub_reset_resume(). Let me know if I am wrong. I can't tell at this point. It depends on the reason why hub_port_logical_disconnect got called. 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 01/12] USB: ehci-orion: Use devm_*() functions
On Wed, Dec 11, 2013 at 04:16:33PM +0900, Jingoo Han wrote: Use devm_*() functions to make cleanup paths simpler. Signed-off-by: Jingoo Han jg1@samsung.com --- drivers/usb/host/ehci-orion.c | 43 - 1 file changed, 12 insertions(+), 31 deletions(-) Acked-by: Jason Cooper ja...@lakedaemon.net thx, Jason. -- 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: core: Add warm reset while reset-resuming SuperSpeed HUBs
I don't know what you mean by fails. The system goes to sleep and then later on wakes up, doesn't it? Do you mean that the Jetflash device gets disconnected when the system wakes up? That's _supposed_ to happen under those circumstances. When hub_activate() sees HUB_RESET_RESUME, all child devices get disconnected except those where udev-persist_enabled is set. This patch was written in response to the same bug as my usb: hub: Use correct reset for wedged USB3 devices that are NOTATTACHED submission. My patch only helps when the port gets stuck in Compliance Mode, but Vikas reports that he can sometimes see it stuck in Polling or Recovery states as well. The underlying issue is a deadlock in the USB 3.0 link training state machine when the host controller is unilaterally reset on resume (without driving a reset on the bus). The host port starts out back in Rx.Detect without remembering anything about its previous state, but the device is still in U3. The host detects Rx terminations, moves to Polling and starts sending LFPS link training packets, but the device doesn't expect those and interprets them as link problems (moving to Recovery). What happens next seems to be device specific, but apparently the device can end up in SS.Inactive while the host port gets stuck in Polling or Recovery (or some kind of livelock between those). This patch tries to warm reset all USB 3.0 ports on reset-resume (after xhci_reset() was called) that had devices connected to them before suspend. This seems to be the only way to ensure the devices' state machines get back to a well-defined state that the host can work with. I don't think this is a specific hardware bug, it's just an unfortunate design flaw that the USB 3.0 spec doesn't account for a root hub port being reset independently of its connected device. I think Sarah is correct that it could be limited to root hubs, though. -- 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: core: Make sure usb_set_configuration(-1) cannot fail
Sorry for not getting back to this sooner. Ironically, it looks like this change isn't needed any more, thanks to Thomas Pugliese's patch: http://marc.info/?l=linux-usbm=13866180520w=2 Yes... thanks for pointing it out, that would make this patch obsolete. I'll wait a few days with this to see if that patch gets accepted as it is. -- 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: core: Add warm reset while reset-resuming SuperSpeed HUBs
On Wed, Dec 11, 2013 at 11:00:13AM -0800, Julius Werner wrote: I don't know what you mean by fails. The system goes to sleep and then later on wakes up, doesn't it? Do you mean that the Jetflash device gets disconnected when the system wakes up? That's _supposed_ to happen under those circumstances. When hub_activate() sees HUB_RESET_RESUME, all child devices get disconnected except those where udev-persist_enabled is set. This patch was written in response to the same bug as my usb: hub: Use correct reset for wedged USB3 devices that are NOTATTACHED submission. My patch only helps when the port gets stuck in Compliance Mode, but Vikas reports that he can sometimes see it stuck in Polling or Recovery states as well. The underlying issue is a deadlock in the USB 3.0 link training state machine when the host controller is unilaterally reset on resume (without driving a reset on the bus). The xHCI spec requires that when the xHCI host is reset, a USB reset is driven down the USB 3.0 ports. If hot reset fails, the port may migrate to warm reset. See table 32 in the xHCI spec, in the definition of HCRST. It sounds like this host doesn't drive a USB reset down USB 3.0 ports at all on host controller reset? The host port starts out back in Rx.Detect without remembering anything about its previous state, but the device is still in U3. The host detects Rx terminations, moves to Polling and starts sending LFPS link training packets, but the device doesn't expect those and interprets them as link problems (moving to Recovery). What happens next seems to be device specific, but apparently the device can end up in SS.Inactive while the host port gets stuck in Polling or Recovery (or some kind of livelock between those). This patch tries to warm reset all USB 3.0 ports on reset-resume (after xhci_reset() was called) that had devices connected to them before suspend. This seems to be the only way to ensure the devices' state machines get back to a well-defined state that the host can work with. I don't think this is a specific hardware bug, it's just an unfortunate design flaw that the USB 3.0 spec doesn't account for a root hub port being reset independently of its connected device. I think Sarah is correct that it could be limited to root hubs, though. 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
Generic phy framework
Hi Kishon, I see you have added this new generic phy framework. The usb phy framework contains a struct notifier_block to send usb specific events like USB_EVENT_ID. Will this new generic phy support notifications like the usb phy? Also will set_power() and set_vbus() ops get added? Or should we continue to use the usb_phy as well as the generic phy? Thanks, Graham -- 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: core: Add warm reset while reset-resuming SuperSpeed HUBs
On Wed, Dec 11, 2013 at 11:36 AM, Sarah Sharp
sarah.a.sh...@linux.intel.com wrote:
On Wed, Dec 11, 2013 at 11:00:13AM -0800, Julius Werner wrote:
I don't know what you mean by fails. The system goes to sleep and
then later on wakes up, doesn't it?
Do you mean that the Jetflash device gets disconnected when the system
wakes up? That's _supposed_ to happen under those circumstances.
When hub_activate() sees HUB_RESET_RESUME, all child devices get
disconnected except those where udev-persist_enabled is set.
This patch was written in response to the same bug as my usb: hub:
Use correct reset for wedged USB3 devices that are NOTATTACHED
submission. My patch only helps when the port gets stuck in Compliance
Mode, but Vikas reports that he can sometimes see it stuck in Polling
or Recovery states as well.
The underlying issue is a deadlock in the USB 3.0 link training state
machine when the host controller is unilaterally reset on resume
(without driving a reset on the bus).
The xHCI spec requires that when the xHCI host is reset, a USB reset is
driven down the USB 3.0 ports. If hot reset fails, the port may migrate
to warm reset. See table 32 in the xHCI spec, in the definition of
HCRST. It sounds like this host doesn't drive a USB reset down USB 3.0
ports at all on host controller reset?
...although, the spec says that it does not wait for the port resets
to complete. As far as I can see re-issuing a warm reset and waiting
is the only way to guarantee the core times the recovery. Presumably
the portstatus debounce in hub_activate() mitigates this, but that
100ms is less than a full reset timeout. I have something similar in
the port power rework patches [1], but I think something like the
following (untested) is more generic, it arranges for reset_resume to
start with a warm reset if necessary.
(also attached)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index a7c04e24ca48..30ce237569dd 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2783,8 +2783,14 @@ static int check_port_resume_type(struct
usb_device *udev,
struct usb_hub *hub, int port1,
int status, unsigned portchange, unsigned portstatus)
{
+ /* Did the port go SS.Inactive? Even if -persist_enabled is
cleared the
+* device won't come back until a warm reset completes
+*/
+ if (hub_port_warm_reset_required(hub, portstatus)) {
+ udev-reset_resume = 1;
+ udev-reset_resume_warm = 1;
/* Is the device still present? */
- if (status || port_is_suspended(hub, portstatus) ||
+ } else if (status || port_is_suspended(hub, portstatus) ||
!port_is_power_on(hub, portstatus) ||
!(portstatus USB_PORT_STAT_CONNECTION)) {
if (status = 0)
@@ -4022,7 +4028,8 @@ hub_port_init (struct usb_hub *hub, struct
usb_device *udev, int port1,
/* Reset the device; full speed may morph to high speed */
/* FIXME a USB 2.0 device may morph into SuperSpeed on reset. */
- retval = hub_port_reset(hub, port1, udev, delay, false);
+ retval = hub_port_reset(hub, port1, udev, delay,
+ udev-reset_resume_warm);
if (retval 0) /* error or disconnect */
goto fail;
/* success, speed is known */
@@ -4730,7 +4737,8 @@ static void hub_events(void)
/* deal with port status changes */
for (i = 1; i = hdev-maxchild; i++) {
- if (test_bit(i, hub-busy_bits))
+ if (test_bit(i, hub-busy_bits) ||
+ test_bit(i, hub-delayed_change_bits))
continue;
connect_change = test_bit(i, hub-change_bits);
wakeup_change = test_and_clear_bit(i, hub-wakeup_bits);
diff --git a/include/linux/usb.h b/include/linux/usb.h
index 7454865ad148..ff1b6fe4a0ff 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -572,6 +572,7 @@ struct usb_device {
unsigned do_remote_wakeup:1;
unsigned reset_resume:1;
+ unsigned reset_resume_warm:1;
unsigned port_is_suspended:1;
#endif
struct wusb_dev *wusb_dev;
The host port starts out back in
Rx.Detect without remembering anything about its previous state, but
the device is still in U3. The host detects Rx terminations, moves to
Polling and starts sending LFPS link training packets, but the device
doesn't expect those and interprets them as link problems (moving to
Recovery). What happens next seems to be device specific, but
apparently the device can end up in SS.Inactive while the host port
gets stuck in Polling or Recovery (or some kind of livelock between
those).
In testing the port power patches I see this particular device give up
on its superspeed connection if it sees too many link failures and
fallsback to
Re: [PATCH 05/12] USB: ohci-at91: Use devm_*() functions
On Wednesday, December 11, 2013 5:13 PM, Nicolas Ferre wrote: On 11/12/2013 08:31, Jingoo Han : Use devm_*() functions to make cleanup paths simpler. Signed-off-by: Jingoo Han jg1@samsung.com Jingoo, Well, these modifications are already addressed by a series written by Boris. [PATCH v5 0/3] usb: ohci-at91: various improvements OK, I see. Please ignore this patch. Thank you for your comment. :-) Best regards, Jingoo Han Thanks for your patch anyway. Best regards. --- drivers/usb/host/ohci-at91.c | 52 +- 1 file changed, 11 insertions(+), 41 deletions(-) -- 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: BTRFS doesn't handle USB device disconnect
On Wed, Dec 11, 2013 at 11:03:09AM -0500, Alan Stern wrote: On Tue, 10 Dec 2013, Sarah Sharp wrote: On 3.13-rc1, the btrfs partion from the disconnected USB device continues to be listed as mounted. Yanking the cable produces some additional oops messages. It also produced a couple hard-hangs. Unfortunately, I didn't capture the dmesg during the hard-hangs, so I can't tell for sure which driver is to blame (uas, btrfs, or xhci). Does this happen with usb-storage instead of uas? What about with ehci-hcd instead of xhci-hcd? And just to be exotic, what about with dummy-hcd and the uas or g_mass_storage gadget driver? I can't reproduce the hard-hangs (with xhci and uas), but I did manage to reproduce a bug in uas where the disconnect function hangs, and hangs the khubd thread as well. This happens even with the btrfs partition wiped from the drive, so it's not a btrfs issue. I'll send a separate bug report to Hans. Sarah Sharp -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: core: Add warm reset while reset-resuming SuperSpeed HUBs
On Wed, Dec 11, 2013 at 2:51 PM, Dan Williams dan.j.willi...@gmail.com wrote:
On Wed, Dec 11, 2013 at 11:36 AM, Sarah Sharp
sarah.a.sh...@linux.intel.com wrote:
On Wed, Dec 11, 2013 at 11:00:13AM -0800, Julius Werner wrote:
I don't know what you mean by fails. The system goes to sleep and
then later on wakes up, doesn't it?
Do you mean that the Jetflash device gets disconnected when the system
wakes up? That's _supposed_ to happen under those circumstances.
When hub_activate() sees HUB_RESET_RESUME, all child devices get
disconnected except those where udev-persist_enabled is set.
This patch was written in response to the same bug as my usb: hub:
Use correct reset for wedged USB3 devices that are NOTATTACHED
submission. My patch only helps when the port gets stuck in Compliance
Mode, but Vikas reports that he can sometimes see it stuck in Polling
or Recovery states as well.
The underlying issue is a deadlock in the USB 3.0 link training state
machine when the host controller is unilaterally reset on resume
(without driving a reset on the bus).
The xHCI spec requires that when the xHCI host is reset, a USB reset is
driven down the USB 3.0 ports. If hot reset fails, the port may migrate
to warm reset. See table 32 in the xHCI spec, in the definition of
HCRST. It sounds like this host doesn't drive a USB reset down USB 3.0
ports at all on host controller reset?
...although, the spec says that it does not wait for the port resets
to complete. As far as I can see re-issuing a warm reset and waiting
is the only way to guarantee the core times the recovery. Presumably
the portstatus debounce in hub_activate() mitigates this, but that
100ms is less than a full reset timeout. I have something similar in
the port power rework patches [1], but I think something like the
following (untested) is more generic, it arranges for reset_resume to
start with a warm reset if necessary.
(also attached)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index a7c04e24ca48..30ce237569dd 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2783,8 +2783,14 @@ static int check_port_resume_type(struct
usb_device *udev,
struct usb_hub *hub, int port1,
int status, unsigned portchange, unsigned portstatus)
{
+ /* Did the port go SS.Inactive? Even if -persist_enabled is
cleared the
+* device won't come back until a warm reset completes
+*/
+ if (hub_port_warm_reset_required(hub, portstatus)) {
+ udev-reset_resume = 1;
+ udev-reset_resume_warm = 1;
Also need to set 'status' to 0 here.
If it's truly just a case of waiting for port warm resets to complete
it might be better to inject additional debounce delay here, but the
spec seems to indicate that there is no way to know that escalated
warm resets are in progress. 4.19.5.1 says The Port Reset (PR) flag
shall be ‘1’ while Hot or Warm Reset is being executed. The Port Reset
Change (PRC) flag shall be set (‘1’) when the reset execution is
complete and PR transitions to ‘0’ but that is only if software
initiated the warm reset. When the warm reset was the result of an
HCRST we hit Note, the completion of the xHC reset process is not
gated by the Root Hub port reset process.
--
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: musb: omap2430: fix occasional musb breakage on boot
This is a hard to reproduce problem which leads to non-functional
USB-OTG port in 0.1%-1% of all boots. Tracked it down to commit
e25bec160158abe86c omap2+: save and restore OTG_INTERFSEL,
which introduces save/restore of OTG_INTERFSEL over suspend.
Since the resume function is also called early in driver init, it uses a
non-initialized value (which is 0 and a non-supported setting in DM37xx
for INTERFSEL). Shortly after the correct value is set. Apparently this
works most time, but not always.
Fix it by not writing the value on runtime resume if it is 0
(0 should never be saved in the context as it's invalid value,
so we use it as an indicator that context hasn't been saved yet).
This issue was originally found by Andreas Naumann:
http://marc.info/?l=linux-usbm=138562574719654w=2
Reported-and-bisected-by: Andreas Naumann anaum...@ultratronik.de
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
Cc: sta...@vger.kernel.org
---
This is a regression from 3.2, so should go to -rc and stable, IMO.
It's really annoying issue if you want to have a stable OTG behavior,
I've burned quite a lot of time on it myself over a year ago and gave up
eventually. Good thing Andreas finally found it, many thanks to him!
drivers/usb/musb/omap2430.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 2a408cd..737b3da 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -672,7 +672,8 @@ static int omap2430_runtime_resume(struct device *dev)
if (musb) {
omap2430_low_level_init(musb);
- musb_writel(musb-mregs, OTG_INTERFSEL,
+ if (musb-context.otg_interfsel != 0)
+ musb_writel(musb-mregs, OTG_INTERFSEL,
musb-context.otg_interfsel);
phy_power_on(musb-phy);
}
--
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: [PATCH] usb: musb: omap2430: fix occasional musb breakage on boot
On Thu, Dec 12, 2013 at 02:20:59AM +0200, Grazvydas Ignotas wrote:
This is a hard to reproduce problem which leads to non-functional
USB-OTG port in 0.1%-1% of all boots. Tracked it down to commit
e25bec160158abe86c omap2+: save and restore OTG_INTERFSEL,
which introduces save/restore of OTG_INTERFSEL over suspend.
Since the resume function is also called early in driver init, it uses a
non-initialized value (which is 0 and a non-supported setting in DM37xx
for INTERFSEL). Shortly after the correct value is set. Apparently this
works most time, but not always.
Fix it by not writing the value on runtime resume if it is 0
(0 should never be saved in the context as it's invalid value,
so we use it as an indicator that context hasn't been saved yet).
This issue was originally found by Andreas Naumann:
http://marc.info/?l=linux-usbm=138562574719654w=2
Reported-and-bisected-by: Andreas Naumann anaum...@ultratronik.de
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
Cc: sta...@vger.kernel.org
---
This is a regression from 3.2, so should go to -rc and stable, IMO.
It's really annoying issue if you want to have a stable OTG behavior,
I've burned quite a lot of time on it myself over a year ago and gave up
eventually. Good thing Andreas finally found it, many thanks to him!
drivers/usb/musb/omap2430.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 2a408cd..737b3da 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -672,7 +672,8 @@ static int omap2430_runtime_resume(struct device *dev)
if (musb) {
omap2430_low_level_init(musb);
- musb_writel(musb-mregs, OTG_INTERFSEL,
+ if (musb-context.otg_interfsel != 0)
You might want to write an inline comment explaining why you're checking
otg_interfsel for 0 here (as you explained 0 is not a valid value to be
found).
Br, David
+ musb_writel(musb-mregs, OTG_INTERFSEL,
musb-context.otg_interfsel);
phy_power_on(musb-phy);
}
--
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
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Bugfixes for UVC gadget test application
Hi Robert, On Tuesday 10 December 2013 12:40:33 Robert Baldyga wrote: Hello, This patchset fixes UVC gadget test application, created by Laurent Pinchart (git tree available here: git://git.ideasonboard.org/uvc-gadget.git), with applied patches created by Bhupesh Sharma (which can be found here: http://www.spinics.net/lists/linux-usb/msg84376.html). It improves video-capture device handling, and adds few other fixes. More details can be found in commit messages. Thank you for the patches. This is a nice reminder that I still haven't reviewed Bhupesh's patches. I've tried to get back to them, but the size of the first patch makes it too complex to review for the limited time I have now. Unless the UVC gadget: Add support for integration with a video-capture device and other fixes patch gets split in smaller chunks I won't have time to handle it before February at the earliest. Best regards Robert Baldyga Samsung RD Institute Poland Robert Baldyga (4): closing uvc file when init fails remove set_format from uvc_events_process_data fix v4l2 stream handling remove flooding debugs uvc-gadget.c | 68 +- 1 file changed, 10 insertions(+), 58 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Bugfixes for UVC gadget test application
Hi Robert, [Repost with Bhupesh's hopefully correct e-mail address] On Tuesday 10 December 2013 12:40:33 Robert Baldyga wrote: Hello, This patchset fixes UVC gadget test application, created by Laurent Pinchart (git tree available here: git://git.ideasonboard.org/uvc-gadget.git), with applied patches created by Bhupesh Sharma (which can be found here: http://www.spinics.net/lists/linux-usb/msg84376.html). It improves video-capture device handling, and adds few other fixes. More details can be found in commit messages. Thank you for the patches. This is a nice reminder that I still haven't reviewed Bhupesh's patches. I've tried to get back to them, but the size of the first patch makes it too complex to review for the limited time I have now. Unless the UVC gadget: Add support for integration with a video-capture device and other fixes patch gets split in smaller chunks I won't have time to handle it before February at the earliest. Best regards Robert Baldyga Samsung RD Institute Poland Robert Baldyga (4): closing uvc file when init fails remove set_format from uvc_events_process_data fix v4l2 stream handling remove flooding debugs uvc-gadget.c | 68 +- 1 file changed, 10 insertions(+), 58 deletions(-) -- Regards, Laurent Pinchart -- 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: Generic phy framework
Hi, On Thursday 12 December 2013 03:27 AM, Graham Williams wrote: Hi Kishon, I see you have added this new generic phy framework. The usb phy framework contains a struct notifier_block to send usb specific events like USB_EVENT_ID. Will this new generic phy support notifications like the usb phy? Also will set_power() and set_vbus() ops get added? Or should we continue to use the usb_phy as well as the generic phy? For events, ideally you should be using the extcon framework. For any new drivers you should be using the generic PHY. If you can tell us how those ops are used, we can think of adding it in Generic PHY. 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] USB: core: Add warm reset while reset-resuming SuperSpeed HUBs
...although, the spec says that it does not wait for the port resets to complete. As far as I can see re-issuing a warm reset and waiting is the only way to guarantee the core times the recovery. Presumably the portstatus debounce in hub_activate() mitigates this, but that 100ms is less than a full reset timeout. It's definitely not just a timing issue for us. I can't reproduce all the same cases as Vikas, but when I attach a USB analyzer to the ones I do see the host controller doesn't even start sending a reset. The xHCI spec requires that when the xHCI host is reset, a USB reset is driven down the USB 3.0 ports. If hot reset fails, the port may migrate to warm reset. See table 32 in the xHCI spec, in the definition of HCRST. It sounds like this host doesn't drive a USB reset down USB 3.0 ports at all on host controller reset? Oh, interesting, I hadn't seen that yet. So I guess the spec itself is fine if it were followed to the letter. I did some more tests about this on my Exynos machine: when I put a device to autosuspend (U3) and manually poke the xHC reset bit, I do see an automatic warm reset on the analyzer and the ports manage to retrain to U0. But after a system suspend/resume which calls xhci_reset() in the process, there is no reset on the wire. I also noticed that it doesn't drive a reset (even after manual poking) when there is no device connected on the other end of the analyzer. So this might be our problem: maybe these host controllers (Synopsys DesignWare) issue the spec-mandated warm reset only on ports where they think there is a device attached. But after a system suspend/resume (where the whole IP block on the SoC was powered down), the host controller cannot know that there is still a device with an active power session attached, and therefore doesn't drive the reset on its own. Even though this is a host controller bug, we still have to deal with it somehow. I guess we could move the code into xhci_plat_resume() and hide it behind a quirk to lessen the impact. But since reset_resume is not a common case for most host controllers, it's hard to say if this is DesignWare specific or a more widespread implementation mistake. -- 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
