[PATCH net v2] net: qmi_wwan: call subdriver with control intf only
This fixes a hang on suspend due to calling wdm_suspend on the unregistered data interface. The hang should have been a NULL pointer reference had it not been for a logic error in the cdc_wdm code. commit 230718bd net: qmi_wwan: bind to both control and data interface changed qmi_wwan to use cdc_wdm as a subdriver for devices with a two-interface QMI/wwan function. The commit failed to update qmi_wwan_suspend and qmi_wwan_resume, which were written to handle either a single combined interface function, or no subdriver at all. The result was that we called into the subdriver both when the control interface was suspended and when the data interface was suspended. Calling the subdriver suspend function with an unregistered interface is not supported and will make the subdriver bug out. Signed-off-by: Bjørn Mork --- v2: fix resume error path as well drivers/net/usb/qmi_wwan.c |7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c index 17b8f3e..b1ba68f 100644 --- a/drivers/net/usb/qmi_wwan.c +++ b/drivers/net/usb/qmi_wwan.c @@ -297,7 +297,7 @@ static int qmi_wwan_suspend(struct usb_interface *intf, pm_message_t message) if (ret < 0) goto err; - if (info->subdriver && info->subdriver->suspend) + if (intf == info->control && info->subdriver && info->subdriver->suspend) ret = info->subdriver->suspend(intf, message); if (ret < 0) usbnet_resume(intf); @@ -310,13 +310,14 @@ static int qmi_wwan_resume(struct usb_interface *intf) struct usbnet *dev = usb_get_intfdata(intf); struct qmi_wwan_state *info = (void *)&dev->data; int ret = 0; + bool callsub = (intf == info->control && info->subdriver && info->subdriver->resume); - if (info->subdriver && info->subdriver->resume) + if (callsub) ret = info->subdriver->resume(intf); if (ret < 0) goto err; ret = usbnet_resume(intf); - if (ret < 0 && info->subdriver && info->subdriver->resume && info->subdriver->suspend) + if (ret < 0 && callsub && info->subdriver->suspend) info->subdriver->suspend(intf, PMSG_SUSPEND); err: return ret; -- 1.7.10.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: Samsung SCX-3205 scanner does not work with Toshiba Satellite L855
On 09/12/2012 10:51 PM, Alan Stern wrote: > On Wed, 12 Sep 2012, Michal Nowak wrote: > >> From https://bugzilla.kernel.org/show_bug.cgi?id=47421: >> >> I have problems with Samsung SCX-3205 scanner on Toshiba Satellite L855. >> When is scanner connected to the notebook (via USB) I can see it via >> `scanimage -L` on first attempt but on any other attempt I can't see it >> any more, unless I turn the scanner off and on. >> >> Currently using 3.5.3-1.fc17.x86_64 kernel (but it also happens with >> 3.6.0-0.rc4.git2.1.fc18). The latest working kernel is 2.6.39-1.fc16 on >> that hardware (2.6.40 which was in fact 3.0, I guess, does not work). >> >> That scanner with identical OS - Fedora 17 - worked well on Lenovo T510 >> (Sandy Bridge -- USB 2.0 only), the new Toshiba L855 (Ivy Bridge with >> USB 3.0 -- xHCI) fails here. >> >> I somehow think it's related to the xhci driver, hence Cc-ing Sarah. Is >> there a way how to disable xhci driver in favor of ehci (xhci and ehci >> are both compiled-in), so I can try with ehci? > > I can't help with the xHCI problem, but here's how you can disable the > xhci-hcd driver: > > echo :00:14.0 >/sys/bus/pci/drivers/xhci_hcd/unbind > > Alan Stern > Thanks but it did not help with 3.5.3. It turned all my USB peripheries off and did not notice the Samsung scanner (just an integrated camera which works anyway). After I bound it again I saw the scanner for a moment but then it went "offline" again. I'll try what Sarah suggested and get back to you. -- 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 00/12] usb: chipidea updates for v3.7
Greg Kroah-Hartman writes: > On Wed, Sep 12, 2012 at 02:57:59PM +0300, Alexander Shishkin wrote: >> Hi, >> >> This bunch of patches contains fixes in the core driver and updates >> for chipidea integrated in imx chips. > > As your first few patches were marked for the stable tree, I also pulled > them into the usb-linus branch. Next time, please warn me about this so > I know to do it (and that you are expecting that to happen.) Okay, I'll keep that in mind. > All now applied, thanks. Thanks! Regards, -- Alex -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: host: tegra: code clean up
On 09/12/2012 09:42 PM, Venu Byravarasu wrote: > Stephen Warren wrote at Wednesday, September 12, 2012 11:41 PM: >> On 09/12/2012 01:02 AM, Venu Byravarasu wrote: >>> As part of code clean up, used devm counterparts for the APIs >>> possible. >> >> Almost all of this patch has already been applied as: > > Agree. > Currently Balbi's tree has bit old ehci-tegra.c. Quite possibly. That would happen if patches to ehci-tegra.c were checked into other branches, which have not yet been merged to Linus's tree, and hence have not made it into the baseline for Felipe's tree. This is especially likely as ehci-tegra.c isn't something that Felipe's xceiv branch would usually take patches for IIRC. > Because of this the patches prepared with linux-next need to be rebased onto > this tree and prepare a new patch. > My main intention behind pushing this patch was to get all changes of > ehci-tegra.c from linux-next into balbi's code base so that I can push the > same patch against either balbi's tree or linux-next. That's not the way the Linux branching model works. The primary way for Felipe's branch to pick up changes from another branch is for the other branch to be merged by Linus, and then Felipe to either merge Linus's branch into his, or start a new branch based on a more recent tag from Linus's tree. If you send patches to Felipe that duplicate work that's already happened in another branch, you'll most likely end up causing merge conflicts when Felipe's branch is merged with the other branch containing the same work in linux-next, Greg's USB tree, and Linus's tree. Of course, you might get lucky and avoid conflicts if the patches are identical, but duplicate patches are still not a good idea. It's best if you send patches that apply and operate correctly on one particular branch, e.g. just Felipe's or some other USB (sub-)maintainer's branch. If your patches actually rely on changes from multiple different branches, then that is problematic. The simplest answer is to simply wait for the (end of the) next kernel merge window when everything has been merged together, and then start sending patches based on the merged result. In some cases, branches can be merged together other than by Linus, although you do have to be quite careful to avoid pain when doing this. It's best to plan out what patches you'll send, where you expect they will be applied, and point out any such dependencies to the maintainers ahead of time. Developing all your big patches first and then sending them, rather than developing them piecemeal, may help you plan this out better, at least at first. -- 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: phy: re-organize tegra phy driver
On 09/12/2012 09:49 PM, Venu Byravarasu wrote: > Stephen Warren wrote at Thursday, September 13, 2012 12:06 AM: >> On 09/12/2012 04:58 AM, Venu Byravarasu wrote: >>> Nvidia produces several Tegra SOCs viz Tegra2, Tegra3 etc. >>> In order to support USB phy drivers on these SOCs, existing >>> phy driver is split into SOC agnostic common USB phy driver and >>> tegra2 specific USB phy driver. >>> This will facilitate easy addition & deletion of phy drivers for >>> Tegra SOCs. >> >> For capitalization/related reasons, I would re-write the commit >> description as: >> >> NVIDIA produces several Tegra SoCs viz Tegra20, Tegra30 etc. >> In order to support USB PHY drivers on these SoCs, existing > > Will change tegra2 to Tegra20 and similar for Tegra30 & NVIDIA. > However as phy is not an acronym, should we still have it in Caps? I'd certainly expect to see PHY in all-caps, yes. As entirely arbitrary justification, see the precedent at: https://en.wikipedia.org/wiki/PHY_(chip) Sorry for bike-shedding, but I'm picky about that kind of thing, at least sometimes. -- 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: phy: re-organize tegra phy driver
On 09/12/2012 10:16 PM, Venu Byravarasu wrote:
> Forgot to address some of the comments made by stephen, in my previous update.
> Hence addressing them now.
> Thanks a lot Stephen, for detailed review.
OK, so since this patch is basically just splitting the file into
multiple parts, you can ignore most of my review comments for this patch
and consider them as input for things in future cleanup patches.
One comment below:
> Stephen Warren wrote at Thursday, September 13, 2012 12:06 AM:
>> On 09/12/2012 04:58 AM, Venu Byravarasu wrote:
...
>>> +static int tegra2_usb_phy_open(struct tegra_usb_phy *phy)
>>> +{
>>> + struct tegra_ulpi_config *ulpi_config;
>>> + int err;
>>> +
>>> + if (phy_is_ulpi(phy)) {
>>
>> Similarly, this seems like it'd be better as two separate functions,
>> since there's already an op defined for open.
>
> tegra2_usb_phy_open is called via open of ops only.
> Plz let me know if you still have any concern here.
What I meant was the body of this function is:
tegra2_usb_phy_open:
if (ulpi)
do a bunch of ULPI stuff
else
do a bunch of UTMI stuff
It's seems it'd be simpler to split this into two functions:
tegra2_usb_ulpi_phy_open:
do a bunch of ULPI stuff
tegra2_usb_utmi_phy_open:
do a bunch of UTMI stuff
... and have the code that initializes the ops assign the appropriate
one of those two functions into the open op, just like it does for
all/most other ops.
Still, this may come under the same argument as above; fuel for future
cleanup since the existing code already works this way?
--
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: phy: re-organize tegra phy driver
Forgot to address some of the comments made by stephen, in my previous update.
Hence addressing them now.
Thanks a lot Stephen, for detailed review.
> -Original Message-
> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> Sent: Thursday, September 13, 2012 12:06 AM
> To: Venu Byravarasu
> Cc: ba...@ti.com; linux-ker...@vger.kernel.org; linux-usb@vger.kernel.org;
> linux-te...@vger.kernel.org
> Subject: Re: [PATCH] USB: phy: re-organize tegra phy driver
>
> On 09/12/2012 04:58 AM, Venu Byravarasu wrote:
> > Nvidia produces several Tegra SOCs viz Tegra2, Tegra3 etc.
> > In order to support USB phy drivers on these SOCs, existing
> > phy driver is split into SOC agnostic common USB phy driver and
> > tegra2 specific USB phy driver.
> > This will facilitate easy addition & deletion of phy drivers for
> > Tegra SOCs.
>
> For capitalization/related reasons, I would re-write the commit
> description as:
>
> NVIDIA produces several Tegra SoCs viz Tegra20, Tegra30 etc.
> In order to support USB PHY drivers on these SoCs, existing
> PHY driver is split into SoC agnostic common USB PHY driver and
> Tegra20-specific USB phy driver. This will facilitate easy addition
> and deletion of phy drivers for Tegra SoCs.
>
> ... and s/tegra/Tegra/ in the patch subject.
>
> Tested-by: Stephen Warren
>
> (On Harmony, both the USB Ethernet on USB3/UTMI and USB2's ULPI to a
> breakout board)
>
> > diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
>
> > @@ -706,9 +709,22 @@ static int tegra_ehci_probe(struct platform_device
> *pdev)
> > }
> > }
> >
> > + phy_type = of_property_match_string(np, "phy_type", "utmi");
> > + if (phy_type >= 0)
> > + params.type = TEGRA_USB_PHY_TYPE_UTMI;
> > + else {
> > + phy_type = of_property_match_string(np, "phy_type",
> "ulpi");
> > + if (phy_type >= 0)
> > + params.type = TEGRA_USB_PHY_TYPE_ULPI;
> > + else
> > + params.type = TEGRA_USB_PHY_TYPE_INVALID;
> > + }
> > +
> > + params.mode = TEGRA_USB_PHY_MODE_HOST;
>
> Do we not support device mode yet? There's a dr_mode property in the DT
> that's supposed to indicate host/device/otg.
>
Device & otg support will be added soon.
> > diff --git a/drivers/usb/phy/tegra2_usb_phy.c
> b/drivers/usb/phy/tegra2_usb_phy.c
>
> > +#include
>
> Please remove that #include statement; the heaer is not needed, and will
> be deleted in the kernel 3.7 merge window.
Sure, will remove it.
>
> > +static int tegra2_utmip_pad_open(struct tegra_usb_phy *phy)
> > +{
> > + phy->pad_clk = clk_get_sys("utmip-pad", NULL);
> > + if (IS_ERR(phy->pad_clk)) {
> > + pr_err("%s: can't get utmip pad clock\n", __func__);
> > + return PTR_ERR(phy->pad_clk);
> > + }
> > +
> > + if (phy->instance == 0) {
> > + phy->pad_regs = phy->regs;
> > + } else {
>
> Can we use something other than phy->instance here? I see lots of usage
> of this field, but we should really be deleting the following code from
> ehci-tegra.c, rather the propagating the use of that field.
I too feel the same way.
Planning to address it in next patches.
>
> /* This is pretty ugly and needs to be fixed when we do only
> * device-tree probing. Old code relies on the platform_device
> * numbering that we lack for device-tree-instantiated devices.
> */
> if (instance < 0) {
> switch (res->start) {
> case TEGRA_USB_BASE:
> instance = 0;
> break;
> case TEGRA_USB2_BASE:
> instance = 1;
> break;
> case TEGRA_USB3_BASE:
> instance = 2;
> break;
> default:
> err = -ENODEV;
> dev_err(&pdev->dev, "unknown usb instance\n");
> goto fail_io;
> }
> }
>
> Still, I suppose the cleanup not to use the instance value could be a
> later patch as long as you're aware of the issue and planning to solve it.
Yes, planning to address it in next patches.
>
> > + phy->pad_regs = ioremap(TEGRA_USB_BASE,
> TEGRA_USB_SIZE);
>
> Hmmm. Why do we need to remap the registers again? Didn't the EHCI
> controller already map them? I'm a little confused what in HW causes the
> need for this whole if statement.
>
In order to have very minimal changes in the patch, I did not clean this up.
This was taken from old code, which is yet to be cleaned up.
This patch just moves tegra2 specific code from single phy driver to
tegra2_usb_phy.c
Will address all clean up stuff in next patches.
> > + if (!phy->pad_regs) {
> > + pr_err("%s: can't remap usb registers\n", __func__);
> > + clk_put(phy->pad_clk);
> > + return -ENOMEM;
> >
RE: [PATCH] USB: phy: re-organize tegra phy driver
> -Original Message-
> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> Sent: Thursday, September 13, 2012 12:06 AM
> To: Venu Byravarasu
> Cc: ba...@ti.com; linux-ker...@vger.kernel.org; linux-usb@vger.kernel.org;
> linux-te...@vger.kernel.org
> Subject: Re: [PATCH] USB: phy: re-organize tegra phy driver
>
> On 09/12/2012 04:58 AM, Venu Byravarasu wrote:
> > Nvidia produces several Tegra SOCs viz Tegra2, Tegra3 etc.
> > In order to support USB phy drivers on these SOCs, existing
> > phy driver is split into SOC agnostic common USB phy driver and
> > tegra2 specific USB phy driver.
> > This will facilitate easy addition & deletion of phy drivers for
> > Tegra SOCs.
>
> For capitalization/related reasons, I would re-write the commit
> description as:
>
> NVIDIA produces several Tegra SoCs viz Tegra20, Tegra30 etc.
> In order to support USB PHY drivers on these SoCs, existing
Will change tegra2 to Tegra20 and similar for Tegra30 & NVIDIA.
However as phy is not an acronym, should we still have it in Caps?
> PHY driver is split into SoC agnostic common USB PHY driver and
> Tegra20-specific USB phy driver. This will facilitate easy addition
> and deletion of phy drivers for Tegra SoCs.
>
> ... and s/tegra/Tegra/ in the patch subject.
>
> Tested-by: Stephen Warren
>
> (On Harmony, both the USB Ethernet on USB3/UTMI and USB2's ULPI to a
> breakout board)
>
> > diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
>
> > @@ -706,9 +709,22 @@ static int tegra_ehci_probe(struct platform_device
> *pdev)
> > }
> > }
> >
> > + phy_type = of_property_match_string(np, "phy_type", "utmi");
> > + if (phy_type >= 0)
> > + params.type = TEGRA_USB_PHY_TYPE_UTMI;
> > + else {
> > + phy_type = of_property_match_string(np, "phy_type",
> "ulpi");
> > + if (phy_type >= 0)
> > + params.type = TEGRA_USB_PHY_TYPE_ULPI;
> > + else
> > + params.type = TEGRA_USB_PHY_TYPE_INVALID;
> > + }
> > +
> > + params.mode = TEGRA_USB_PHY_MODE_HOST;
>
> Do we not support device mode yet? There's a dr_mode property in the DT
> that's supposed to indicate host/device/otg.
>
> > diff --git a/drivers/usb/phy/tegra2_usb_phy.c
> b/drivers/usb/phy/tegra2_usb_phy.c
>
> > +#include
>
> Please remove that #include statement; the heaer is not needed, and will
> be deleted in the kernel 3.7 merge window.
>
> > +static int tegra2_utmip_pad_open(struct tegra_usb_phy *phy)
> > +{
> > + phy->pad_clk = clk_get_sys("utmip-pad", NULL);
> > + if (IS_ERR(phy->pad_clk)) {
> > + pr_err("%s: can't get utmip pad clock\n", __func__);
> > + return PTR_ERR(phy->pad_clk);
> > + }
> > +
> > + if (phy->instance == 0) {
> > + phy->pad_regs = phy->regs;
> > + } else {
>
> Can we use something other than phy->instance here? I see lots of usage
> of this field, but we should really be deleting the following code from
> ehci-tegra.c, rather the propagating the use of that field.
>
> /* This is pretty ugly and needs to be fixed when we do only
> * device-tree probing. Old code relies on the platform_device
> * numbering that we lack for device-tree-instantiated devices.
> */
> if (instance < 0) {
> switch (res->start) {
> case TEGRA_USB_BASE:
> instance = 0;
> break;
> case TEGRA_USB2_BASE:
> instance = 1;
> break;
> case TEGRA_USB3_BASE:
> instance = 2;
> break;
> default:
> err = -ENODEV;
> dev_err(&pdev->dev, "unknown usb instance\n");
> goto fail_io;
> }
> }
>
> Still, I suppose the cleanup not to use the instance value could be a
> later patch as long as you're aware of the issue and planning to solve it.
>
> > + phy->pad_regs = ioremap(TEGRA_USB_BASE,
> TEGRA_USB_SIZE);
>
> Hmmm. Why do we need to remap the registers again? Didn't the EHCI
> controller already map them? I'm a little confused what in HW causes the
> need for this whole if statement.
>
> > + if (!phy->pad_regs) {
> > + pr_err("%s: can't remap usb registers\n", __func__);
> > + clk_put(phy->pad_clk);
> > + return -ENOMEM;
> > + }
> > + }
>
> > +static void tegra2_utmi_phy_clk_disable(struct tegra_usb_phy *phy)
> > +{
> > + unsigned long val;
> > + void __iomem *base = phy->regs;
> > +
> > + if (phy->instance == 0) {
>
> Hmmm. There sure are a lot of places where the code is conditional based
> on instance. This seems to be crying out to be split into more ops
> functions that get set up once at probe() time and then just used.
>
> > +static int tegra2_utmi_phy_power_off(s
RE: [PATCH] usb: host: tegra: code clean up
> -Original Message-
> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> Sent: Wednesday, September 12, 2012 11:41 PM
> To: Venu Byravarasu
> Cc: ba...@ti.com; linux-ker...@vger.kernel.org; linux-usb@vger.kernel.org
> Subject: Re: [PATCH] usb: host: tegra: code clean up
>
> On 09/12/2012 01:02 AM, Venu Byravarasu wrote:
> > As part of code clean up, used devm counterparts for the APIs
> > possible.
>
> Almost all of this patch has already been applied as:
Agree.
Currently Balbi's tree has bit old ehci-tegra.c.
Because of this the patches prepared with linux-next need to be rebased onto
this tree and prepare a new patch.
My main intention behind pushing this patch was to get all changes of
ehci-tegra.c from linux-next into balbi's code base so that I can push the same
patch against either balbi's tree or linux-next.
> bc2ff98 drivers/usb/host/ehci-tegra.c: use devm_ functions
>
> (btw, that patch has a much better patch subject than this one)
>
> The only additions in your patch are shown below, and those changes
> should indeed be a separate patch.
>
> > diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
> > index 6223d17..dba9f07 100644
> > --- a/drivers/usb/host/ehci-tegra.c
> > +++ b/drivers/usb/host/ehci-tegra.c
> > @@ -701,7 +701,7 @@ static int tegra_ehci_probe(struct platform_device
> *pdev)
> > break;
> > default:
> > err = -ENODEV;
> > - dev_err(&pdev->dev, "unknown usb instance\n");
> > + dev_err(&pdev->dev, "unknown usb inst:%d\n",
> > instance);
> > goto fail_io;
> > }
> > }
> > @@ -744,7 +744,7 @@ static int tegra_ehci_probe(struct platform_device
> *pdev)
> >
> > err = usb_add_hcd(hcd, irq, IRQF_SHARED);
> > if (err) {
> > - dev_err(&pdev->dev, "Failed to add USB HCD\n");
> > + dev_err(&pdev->dev, "usb_add_hcd failed with err 0x%x\n",
> > err);
> > goto fail;
> > }
> >
> > @@ -753,7 +753,7 @@ static int tegra_ehci_probe(struct platform_device
> *pdev)
> >
> > /* Don't skip the pm_runtime_forbid call if wakeup isn't working */
> > /* if (!pdata->power_down_on_bus_suspend) */
> > - pm_runtime_forbid(&pdev->dev);
> > + pm_runtime_forbid(&pdev->dev);
> > pm_runtime_enable(&pdev->dev);
> > pm_runtime_put_sync(&pdev->dev);
> > return err;
>
> I'm not sure that last change is worth making; hopefully, you'll fix the
> bug the causes the "if" to be commented out, and we can re-enabled it
> again. Removing the indent makes it much less obvious which lines of
> code the "if" was intended to cover.
--
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: Samsung SCX-3205 scanner does not work with Toshiba Satellite L855
On Wed, Sep 12, 2012 at 04:51:40PM -0400, Alan Stern wrote: > On Wed, 12 Sep 2012, Michal Nowak wrote: > > > From https://bugzilla.kernel.org/show_bug.cgi?id=47421: > > > > I have problems with Samsung SCX-3205 scanner on Toshiba Satellite L855. > > When is scanner connected to the notebook (via USB) I can see it via > > `scanimage -L` on first attempt but on any other attempt I can't see it > > any more, unless I turn the scanner off and on. > > > > Currently using 3.5.3-1.fc17.x86_64 kernel (but it also happens with > > 3.6.0-0.rc4.git2.1.fc18). The latest working kernel is 2.6.39-1.fc16 on > > that hardware (2.6.40 which was in fact 3.0, I guess, does not work). > > > > That scanner with identical OS - Fedora 17 - worked well on Lenovo T510 > > (Sandy Bridge -- USB 2.0 only), the new Toshiba L855 (Ivy Bridge with > > USB 3.0 -- xHCI) fails here. > > > > I somehow think it's related to the xhci driver, hence Cc-ing Sarah. Is > > there a way how to disable xhci driver in favor of ehci (xhci and ehci > > are both compiled-in), so I can try with ehci? > > I can't help with the xHCI problem, but here's how you can disable the > xhci-hcd driver: > > echo :00:14.0 >/sys/bus/pci/drivers/xhci_hcd/unbind I don't think unbinding the xHCI driver will switch the ports back to EHCI, unless xhci_shutdown is called when the driver is unbound, and Michal has the recent bug fix commit e95829f474f0db3a4d940cae1423783edd966027 "xhci: Switch PPT ports to EHCI on shutdown." Maybe a better way to test would be to blacklist the xHCI driver via a boot option. Then the EHCI driver won't switch over the Ivy Bridge USB ports to the xHCI host. However, I'm already aware that we have issues with scanners under Ivy Bridge xHCI, because I've gotten reports from other folks. I bought a scanner to try to reproduce it, but the scanner worked fine, so the issue might be related to a particular type of scanner. In all honesty, other bugs causing kernel crashes and failed suspends have taken higher priority than tracking down this bug. Still, it would be good to have more information. Would you be willing to run some tests for me? In particular, I need the dmesg with CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING turned on, along with a usbmon trace of the scanner running twice under one of your EHCI-only systems, and a trace of two scans under xHCI. The documentation for how to capture a usbmon trace is in the kernel source directory in Documentation/usb/usbmon.txt. 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: XHCI: URB not cancelled during disconnect of a MSC device
On Wed, Sep 12, 2012 at 03:36:39PM +0530, Ajay Gupta wrote: > Hi, > > I am using v3.5 kernel and running a test where I disconnect a SS MSC > device while a big file is being written to it. I am also watching the > lsusb output in parallel. Expectation is that SS MSC device should > immediately disappear from lsusb output but sometime I see that SS MSC > is listed for 30 seconds and then only disappears. Log is copied > below. > > Looking further into the issue shows that in failing case an URB is > not given back by XHCI driver and so SCSI layer unlinks it after > 30second of timeout. This URB was actually given to XHCI host > controller and a disconnect happens while packet transfer was in > progress. I looked at XHCI driver and could not find request being > aborted by driver (in xhci_free_dev() fn) before issuing disable slot > or reset device command. What is expectation in this scenario? The expectation is that the mass storage driver should have aborted any URBs in its disconnect function before xhci_free_dev() is called. I believe all USB drivers are required to do this. If that assumption isn't true, then, yes, I need to revisit any place that xHCI rings get freed. > Is it > XHCI driver responsibility to abort and giveback all the request (as > in EHCI using endpoint_disable()) > Why XHCI > driver doesn't have an endpoint_disable() implemented as done for > other controller? The xHCI driver just works differently than EHCI. It's not a requirement to implement the endpoint disable function, AFAIK. From what I remember, the endpoint disable function was supposed to be used before switching alternate interface settings, but it was called too late to be of much use to the xHCI bandwidth functions. So I created new bandwidth functions and ignored the endpoint disable functions. Maybe Alan can explain what the requirements about the endpoint disable function are? > OR host controller hardware should > abort and post an error completion event for each request? If the host controller hardware was in the middle of a transfer when the device was disconnected, and that caused the transfer to timeout, then, yes, the host should return an event with a transfer error and halt the event ring, as described in the xHCI 1.0 spec, section 4.10.2.3. Even if the host wasn't strictly speaking in the middle of a transfer during the disconnect, the endpoint ring should remain on the host's schedule as long as the xHCI driver didn't issue a stop endpoint command. I would expect that the transfer would timeout the next time it was executed from the schedule. Basically, the host controller has to play dumb and hand back events with error statuses for all TDs that continue to be schedulable after a device disconnect. Eventually the USB core will notice the disconnect, notify the driver, and it will cancel any outstanding URBs. > === Working case > [ 3406.676989] Port Status Change Event for port 2 > [ 3406.711530] get port status, actual port 1 status = 0x4202c0 > [ 3406.711531] Get port status returned 0x4102c0 > [ 3406.711629] clear port connect change, actual port 1 status = 0x4002c0 > [ 3406.711664] clear port link state change, actual port 1 status = 0x2c0 > [ 3406.721606] [E.f2e0b980.Transfer error on endpoint <=== URB > submitted here but gets transfer error > [ 3406.721742] Cleaning up stalled endpoint ring > [ 3406.721744] Finding segment containing stopped TRB. > [ 3406.721746] Finding endpoint context > [ 3406.721747] Finding segment containing last TRB in TD. > [ 3406.721749] Cycle state = 0x1 > [ 3406.721750] New dequeue segment = f2073880 (virtual) > [ 3406.721752] New dequeue pointer = 0x337be380 (DMA) > [ 3406.721754] Queueing new dequeue state > [ 3406.721756] Set TR Deq Ptr cmd, new deq seg = f2073880 (0x337be000 > dma), new deq ptr = f37be380 (0x337be380 dma), new cycle = 1 > [ 3406.721758]// Ding dong! > [ 3406.721855] Giveback URB f2e0b980, len = 0, expected = 31, status = > -71 <=== URB given back by XHCI driver > = > > > === Non Working case > [ 2971.576389] Port Status Change Event for port 2 > [ 2971.576487] [E.f2d0c480. <=== URB submitted but no error. > [ 2971.585007] get port status, actual port 1 status = 0x4202c0 > [ 2971.585079] Get port status returned 0x4102c0 > [ 2971.585178] clear port connect change, actual port 1 status = 0x4002c0 > [ 2971.585213] clear port link state change, actual port 1 status = 0x2c0 > [ 2971.640030] get port status, actual port 1 status = 0x2d1 > [ 2971.640031] Get port status returned 0x2d1 > [ 2971.696029] get port status, actual port 1 status = 0x2d1 > [ 2971.696031] Get port status returned 0x2d1 > [ 2971.900031] get port status, actual port 1 status = 0x2d1 > [ 2971.900034] Get port status returned 0x2d1 > [ 2972.060480] Port Status Change Event for port 2 > [ 2972.104039] get port status, actual port 1 status = 0x2802a0 > [ 2972.
Re: Samsung SCX-3205 scanner does not work with Toshiba Satellite L855
On Wed, 12 Sep 2012, Michal Nowak wrote: > From https://bugzilla.kernel.org/show_bug.cgi?id=47421: > > I have problems with Samsung SCX-3205 scanner on Toshiba Satellite L855. > When is scanner connected to the notebook (via USB) I can see it via > `scanimage -L` on first attempt but on any other attempt I can't see it > any more, unless I turn the scanner off and on. > > Currently using 3.5.3-1.fc17.x86_64 kernel (but it also happens with > 3.6.0-0.rc4.git2.1.fc18). The latest working kernel is 2.6.39-1.fc16 on > that hardware (2.6.40 which was in fact 3.0, I guess, does not work). > > That scanner with identical OS - Fedora 17 - worked well on Lenovo T510 > (Sandy Bridge -- USB 2.0 only), the new Toshiba L855 (Ivy Bridge with > USB 3.0 -- xHCI) fails here. > > I somehow think it's related to the xhci driver, hence Cc-ing Sarah. Is > there a way how to disable xhci driver in favor of ehci (xhci and ehci > are both compiled-in), so I can try with ehci? I can't help with the xHCI problem, but here's how you can disable the xhci-hcd driver: echo :00:14.0 >/sys/bus/pci/drivers/xhci_hcd/unbind 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: EHCI: iaa_watchdog_start() warning followed by NULL ptr dereference in start_unlink_async()
On Wed, 12 Sep 2012, Hemant Kumar wrote: > Hi Alen, > > if we add check for ehci->reclaim->qh_state == QH_STATE_UNLINK in > ehci_irq() and ehci_iaa_watchdog() i still see a race : > what if end_unlink_async for QH1 called start_unlink_async(QH2) and IAAD > interrupt fired after QH2->qh_state is set to QH_STATE_UNLINK. You're right; that's still a problem. Unfortunately, there's nothing we can do about it. It is the unavoidable result of using flawed hardware. I suppose you could increase the IAA Watchdog timeout to 20 ms. But that wouldn't solve the problem; the race could still occur. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: gadget: lpc32xx_udc: Disable setup request error message
This message is an debugging message. It's useful for finding protocol
details but it's not necessarily an error.
Signed-off-by: Alexandre Pereira da Silva
---
drivers/usb/gadget/lpc32xx_udc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/lpc32xx_udc.c b/drivers/usb/gadget/lpc32xx_udc.c
index 21a9861..d1cf1f4 100644
--- a/drivers/usb/gadget/lpc32xx_udc.c
+++ b/drivers/usb/gadget/lpc32xx_udc.c
@@ -2399,7 +2399,7 @@ static void udc_handle_ep0_setup(struct lpc32xx_udc *udc)
if (i < 0) {
/* setup processing failed, force stall */
- dev_err(udc->dev,
+ dev_dbg(udc->dev,
"req %02x.%02x protocol STALL; stat %d\n",
reqtype, req, i);
udc->ep0state = WAIT_FOR_SETUP;
--
1.7.10
--
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: gadget: lpc32xx_udc: Fix compatibility with STOTG04
The STOTG04 is an replacement for ISP1301. Most of the registers on STOTG04 are the same as on ISP1301, but the register ISP1301_I2C_OTG_CONTROL_2 (address 0x10) doesn't exist on the ST part. This is a work around for this by using the interrupt source register that should behave the same on both parts and has the needed information. Signed-off-by: Alexandre Pereira da Silva --- drivers/usb/gadget/lpc32xx_udc.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/lpc32xx_udc.c b/drivers/usb/gadget/lpc32xx_udc.c index f696fb9..21a9861 100644 --- a/drivers/usb/gadget/lpc32xx_udc.c +++ b/drivers/usb/gadget/lpc32xx_udc.c @@ -2930,10 +2930,10 @@ static void vbus_work(struct work_struct *work) /* Get the VBUS status from the transceiver */ value = i2c_smbus_read_byte_data(udc->isp1301_i2c_client, -ISP1301_I2C_OTG_CONTROL_2); +ISP1301_I2C_INTERRUPT_SOURCE); /* VBUS on or off? */ - if (value & OTG_B_SESS_VLD) + if (value & INT_SESS_VLD) udc->vbus = 1; else udc->vbus = 0; -- 1.7.10 -- 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: EHCI: iaa_watchdog_start() warning followed by NULL ptr dereference in start_unlink_async()
> On Wed, 12 Sep 2012, Pavan Kondeti wrote: > >> Thanks for your response. I and Hemant work together. We are thinking a >> scenario where this NULL dereference could happen. Please let us know if >> our understanding is correct or not. we are assuming that async doorbell >> interrupt can not be stopped by software as mentioned at >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=6feff1b92bedab133c5835e510d11f62e843b257 > > ... > > Your analysis looks right. Good work. By the way, if the IAA > interrupt doesn't fire within 10 ms of the IAA doorbell, your EHCI > controller has a serious design flaw. > >> If at all the above scenario is possible, we have to fix the race >> between watchdog timer function and IAAD interrupt handler. In other >> words, we should not call end_unlink_async() prematurely. can we simply >> return from end_unlink_async if QH state != QH_STATE_UNLINK to avoid >> this scenario? > > It would be better to change ehci_iaa_watchdog() and ehci_irq(). > Where they test that ehci->reclaim is non-NULL, they should also test > that ehci->reclaim->qh_state == QH_STATE_UNLINK. That way the driver > doesn't end up doing a bunch of extra work and incrementing the > statistics counter incorrectly. > > 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 > Hi Alen, if we add check for ehci->reclaim->qh_state == QH_STATE_UNLINK in ehci_irq() and ehci_iaa_watchdog() i still see a race : what if end_unlink_async for QH1 called start_unlink_async(QH2) and IAAD interrupt fired after QH2->qh_state is set to QH_STATE_UNLINK. Thanks, Hemant -- 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: phy: re-organize tegra phy driver
On 09/12/2012 04:58 AM, Venu Byravarasu wrote:
> Nvidia produces several Tegra SOCs viz Tegra2, Tegra3 etc.
> In order to support USB phy drivers on these SOCs, existing
> phy driver is split into SOC agnostic common USB phy driver and
> tegra2 specific USB phy driver.
> This will facilitate easy addition & deletion of phy drivers for
> Tegra SOCs.
For capitalization/related reasons, I would re-write the commit
description as:
NVIDIA produces several Tegra SoCs viz Tegra20, Tegra30 etc.
In order to support USB PHY drivers on these SoCs, existing
PHY driver is split into SoC agnostic common USB PHY driver and
Tegra20-specific USB phy driver. This will facilitate easy addition
and deletion of phy drivers for Tegra SoCs.
... and s/tegra/Tegra/ in the patch subject.
Tested-by: Stephen Warren
(On Harmony, both the USB Ethernet on USB3/UTMI and USB2's ULPI to a
breakout board)
> diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
> @@ -706,9 +709,22 @@ static int tegra_ehci_probe(struct platform_device *pdev)
> }
> }
>
> + phy_type = of_property_match_string(np, "phy_type", "utmi");
> + if (phy_type >= 0)
> + params.type = TEGRA_USB_PHY_TYPE_UTMI;
> + else {
> + phy_type = of_property_match_string(np, "phy_type", "ulpi");
> + if (phy_type >= 0)
> + params.type = TEGRA_USB_PHY_TYPE_ULPI;
> + else
> + params.type = TEGRA_USB_PHY_TYPE_INVALID;
> + }
> +
> + params.mode = TEGRA_USB_PHY_MODE_HOST;
Do we not support device mode yet? There's a dr_mode property in the DT
that's supposed to indicate host/device/otg.
> diff --git a/drivers/usb/phy/tegra2_usb_phy.c
> b/drivers/usb/phy/tegra2_usb_phy.c
> +#include
Please remove that #include statement; the heaer is not needed, and will
be deleted in the kernel 3.7 merge window.
> +static int tegra2_utmip_pad_open(struct tegra_usb_phy *phy)
> +{
> + phy->pad_clk = clk_get_sys("utmip-pad", NULL);
> + if (IS_ERR(phy->pad_clk)) {
> + pr_err("%s: can't get utmip pad clock\n", __func__);
> + return PTR_ERR(phy->pad_clk);
> + }
> +
> + if (phy->instance == 0) {
> + phy->pad_regs = phy->regs;
> + } else {
Can we use something other than phy->instance here? I see lots of usage
of this field, but we should really be deleting the following code from
ehci-tegra.c, rather the propagating the use of that field.
/* This is pretty ugly and needs to be fixed when we do only
* device-tree probing. Old code relies on the platform_device
* numbering that we lack for device-tree-instantiated devices.
*/
if (instance < 0) {
switch (res->start) {
case TEGRA_USB_BASE:
instance = 0;
break;
case TEGRA_USB2_BASE:
instance = 1;
break;
case TEGRA_USB3_BASE:
instance = 2;
break;
default:
err = -ENODEV;
dev_err(&pdev->dev, "unknown usb instance\n");
goto fail_io;
}
}
Still, I suppose the cleanup not to use the instance value could be a
later patch as long as you're aware of the issue and planning to solve it.
> + phy->pad_regs = ioremap(TEGRA_USB_BASE, TEGRA_USB_SIZE);
Hmmm. Why do we need to remap the registers again? Didn't the EHCI
controller already map them? I'm a little confused what in HW causes the
need for this whole if statement.
> + if (!phy->pad_regs) {
> + pr_err("%s: can't remap usb registers\n", __func__);
> + clk_put(phy->pad_clk);
> + return -ENOMEM;
> + }
> + }
> +static void tegra2_utmi_phy_clk_disable(struct tegra_usb_phy *phy)
> +{
> + unsigned long val;
> + void __iomem *base = phy->regs;
> +
> + if (phy->instance == 0) {
Hmmm. There sure are a lot of places where the code is conditional based
on instance. This seems to be crying out to be split into more ops
functions that get set up once at probe() time and then just used.
> +static int tegra2_utmi_phy_power_off(struct tegra_usb_phy *phy)
> +{
> + unsigned long val;
> + void __iomem *base = phy->regs;
> +
> + tegra2_utmi_phy_clk_disable(phy);
> +
> + if (phy->mode == TEGRA_USB_PHY_MODE_DEVICE) {
Hmm. Yet here, we have some support for device-mode.
> +static int tegra2_usb_phy_open(struct tegra_usb_phy *phy)
> +{
> + struct tegra_ulpi_config *ulpi_config;
> + int err;
> +
> + if (phy_is_ulpi(phy)) {
Similarly, this seems like it'd be better as two separate functions,
since there's already an op defined for open.
> + ulpi_config = phy->config;
> + phy->clk = clk_get_sys(NULL, ulpi_
Re: xhci: Fix bug after deq ptr set to link TRB.
On Wed, Sep 12, 2012 at 11:19:42AM -0700, Oleg Rombakh wrote: > Hi, > > I am working on the project that involves USB3, 3.0 kernel, and WebCams. > > One of our h/w platforms utilizes NEC uPD720200 USB3 chipset. > > The image we run is based on SUSE 11SP2 (kernel 3.0.38) and on this > kernel we experience problem with web cameras attached to USB3. The > same cameras work on USB2. > Sometimes dmesg contains a message such as: Transfer event TRB DMA ptr > not part of current TD > But most of the time, cameras silently fail to communicate with Cheese > application (curiously enough a built-in mic on these cameras always > work). > On the other hand we do have a platform that uses essentially the > same H/W (PCB and BIOS are different, but from components perspective > both platforms are very close). On this second platform with the > exactly same image all USB web cams work. > > While looking around I found patch > http://git.kernel.org/?p=linux/kernel/git/sarah/xhci.git;a=commit;h=50d0206fcaea3e736f912fd5b00ec6233fb4ce44 > The e-mail says that this patch should be backported to older kernels. > Is there a patch for 3.0.y kernel, that I can try? > Unfortunately > http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=tree;h=refs/heads/linux-3.0.y;hb=refs/heads/linux-3.0.y > does not have it. Yes, a known issue, I have asked Sarah for a backported version for 3.0, but she was on vacation at the time. If you could create it, and test that it works properly for your systems, that would be a wonderful help. Can you? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] usb: chipidea updates for v3.7
On Wed, Sep 12, 2012 at 02:57:59PM +0300, Alexander Shishkin wrote: > Hi, > > This bunch of patches contains fixes in the core driver and updates > for chipidea integrated in imx chips. As your first few patches were marked for the stable tree, I also pulled them into the usb-linus branch. Next time, please warn me about this so I know to do it (and that you are expecting that to happen.) All now applied, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
xhci: Fix bug after deq ptr set to link TRB.
Hi, I am working on the project that involves USB3, 3.0 kernel, and WebCams. One of our h/w platforms utilizes NEC uPD720200 USB3 chipset. The image we run is based on SUSE 11SP2 (kernel 3.0.38) and on this kernel we experience problem with web cameras attached to USB3. The same cameras work on USB2. Sometimes dmesg contains a message such as: Transfer event TRB DMA ptr not part of current TD But most of the time, cameras silently fail to communicate with Cheese application (curiously enough a built-in mic on these cameras always work). On the other hand we do have a platform that uses essentially the same H/W (PCB and BIOS are different, but from components perspective both platforms are very close). On this second platform with the exactly same image all USB web cams work. While looking around I found patch http://git.kernel.org/?p=linux/kernel/git/sarah/xhci.git;a=commit;h=50d0206fcaea3e736f912fd5b00ec6233fb4ce44 The e-mail says that this patch should be backported to older kernels. Is there a patch for 3.0.y kernel, that I can try? Unfortunately http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=tree;h=refs/heads/linux-3.0.y;hb=refs/heads/linux-3.0.y does not have it. Any help will be appreciated. Oleg -- 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: host: tegra: code clean up
On 09/12/2012 01:02 AM, Venu Byravarasu wrote:
> As part of code clean up, used devm counterparts for the APIs
> possible.
Almost all of this patch has already been applied as:
bc2ff98 drivers/usb/host/ehci-tegra.c: use devm_ functions
(btw, that patch has a much better patch subject than this one)
The only additions in your patch are shown below, and those changes
should indeed be a separate patch.
> diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
> index 6223d17..dba9f07 100644
> --- a/drivers/usb/host/ehci-tegra.c
> +++ b/drivers/usb/host/ehci-tegra.c
> @@ -701,7 +701,7 @@ static int tegra_ehci_probe(struct platform_device *pdev)
> break;
> default:
> err = -ENODEV;
> - dev_err(&pdev->dev, "unknown usb instance\n");
> + dev_err(&pdev->dev, "unknown usb inst:%d\n",
> instance);
> goto fail_io;
> }
> }
> @@ -744,7 +744,7 @@ static int tegra_ehci_probe(struct platform_device *pdev)
>
> err = usb_add_hcd(hcd, irq, IRQF_SHARED);
> if (err) {
> - dev_err(&pdev->dev, "Failed to add USB HCD\n");
> + dev_err(&pdev->dev, "usb_add_hcd failed with err 0x%x\n",
> err);
> goto fail;
> }
>
> @@ -753,7 +753,7 @@ static int tegra_ehci_probe(struct platform_device *pdev)
>
> /* Don't skip the pm_runtime_forbid call if wakeup isn't working */
> /* if (!pdata->power_down_on_bus_suspend) */
> - pm_runtime_forbid(&pdev->dev);
> + pm_runtime_forbid(&pdev->dev);
> pm_runtime_enable(&pdev->dev);
> pm_runtime_put_sync(&pdev->dev);
> return err;
I'm not sure that last change is worth making; hopefully, you'll fix the
bug the causes the "if" to be commented out, and we can re-enabled it
again. Removing the indent makes it much less obvious which lines of
code the "if" was intended to cover.
--
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
Samsung SCX-3205 scanner does not work with Toshiba Satellite L855
>From https://bugzilla.kernel.org/show_bug.cgi?id=47421: I have problems with Samsung SCX-3205 scanner on Toshiba Satellite L855. When is scanner connected to the notebook (via USB) I can see it via `scanimage -L` on first attempt but on any other attempt I can't see it any more, unless I turn the scanner off and on. Currently using 3.5.3-1.fc17.x86_64 kernel (but it also happens with 3.6.0-0.rc4.git2.1.fc18). The latest working kernel is 2.6.39-1.fc16 on that hardware (2.6.40 which was in fact 3.0, I guess, does not work). That scanner with identical OS - Fedora 17 - worked well on Lenovo T510 (Sandy Bridge -- USB 2.0 only), the new Toshiba L855 (Ivy Bridge with USB 3.0 -- xHCI) fails here. I somehow think it's related to the xhci driver, hence Cc-ing Sarah. Is there a way how to disable xhci driver in favor of ehci (xhci and ehci are both compiled-in), so I can try with ehci? lspci & lsusb logs in the kernel.org Bugzilla. Keep me Cc-ed, I am not in the m-l. Thanks, Michal -- 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 10/15] drivers/usb/host/xhci-ring.c: removes unnecessary semicolon
From: Peter Senna Tschudin
removes unnecessary semicolon
Found by Coccinelle: http://coccinelle.lip6.fr/
Signed-off-by: Peter Senna Tschudin
---
drivers/usb/host/xhci-ring.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 643c2f3..ecd6946 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2580,7 +2580,7 @@ static int prepare_ring(struct xhci_hcd *xhci, struct
xhci_ring *ep_ring,
xhci_err(xhci, "Ring expansion failed\n");
return -ENOMEM;
}
- };
+ }
if (enqueue_is_link_trb(ep_ring)) {
struct xhci_ring *ring = ep_ring;
--
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 13/15] drivers/usb/misc/rio500.c: removes unnecessary semicolon
From: Peter Senna Tschudin
removes unnecessary semicolon
Found by Coccinelle: http://coccinelle.lip6.fr/
Signed-off-by: Peter Senna Tschudin
---
drivers/usb/misc/rio500.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/misc/rio500.c b/drivers/usb/misc/rio500.c
index 1084124..b9b356a 100644
--- a/drivers/usb/misc/rio500.c
+++ b/drivers/usb/misc/rio500.c
@@ -338,7 +338,7 @@ write_rio(struct file *file, const char __user *buffer,
thistime -= partial;
} else
break;
- };
+ }
if (result) {
dev_err(&rio->rio_dev->dev, "Write Whoops - %x\n",
result);
--
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 15/15] drivers/usb/host/sl811-hcd.c: removes unnecessary semicolon
From: Peter Senna Tschudin removes unnecessary semicolon Found by Coccinelle: http://coccinelle.lip6.fr/ Signed-off-by: Peter Senna Tschudin --- drivers/usb/host/sl811-hcd.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/sl811-hcd.c b/drivers/usb/host/sl811-hcd.c index 91ce1c0..619b05f 100644 --- a/drivers/usb/host/sl811-hcd.c +++ b/drivers/usb/host/sl811-hcd.c @@ -156,7 +156,7 @@ static void setup_packet( writeb(SL_SETUP /* | ep->epnum */, data_reg); writeb(usb_pipedevice(urb->pipe), data_reg); - /* always OUT/data0 */ ; + /* always OUT/data0 */ sl811_write(sl811, bank + SL11H_HOSTCTLREG, control | SL11H_HCTLMASK_OUT); ep->length = 0; -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/5] usb: phy: samsung: Introducing usb phy driver for hsotg
Hi Praveen, Marc,
On Wednesday 12 of September 2012 13:08:26 Marc Kleine-Budde wrote:
> > +static const struct of_device_id samsung_usbphy_dt_match[];
> > +
> > +static inline int samsung_usbphy_get_driver_data(struct
> > platform_device *pdev) +{
> > +#ifdef CONFIG_OF
>
> if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node)
Is this check needed at all?
In case of CONFIG_OF disabled, of_node should always be NULL and there is a
dummy macro provided for of_match_node, so it should compile and work just
fine.
--
Best regards,
Tomasz Figa
--
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: [balbi-usb:merge-result-for-greg 66/99] drivers/usb/core/hub.c:2654 usb_get_hub_port_power_state() error: doing dma on the stack ((null))
On 2012/9/12 21:11, Alan Stern wrote:
On Wed, 12 Sep 2012, Fengguang Wu wrote:
Hi Felipe,
FYI, there are new smatch warnings show up in
tree: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
merge-result-for-greg
head: 23953bde3e4d6aa8780dc054f6ad9882ac63f4f4
commit: e918fa161f510136fce45a524e934fe20e62c8b1 [66/99] Merge tag
'gadget-for-v3.7' into merge-result-for-greg
drivers/usb/core/hub.c:2654 usb_get_hub_port_power_state() error: doing dma on
the stack ((null))
drivers/usb/core/hub.c:4733 store_port_power_control() info: why not propagate
'ret' from set_port_feature() instead of -5?
drivers/usb/core/hub.c:4744 store_port_power_control() info: why not propagate
'ret' from clear_port_feature() instead of -5?
vim +2654 drivers/usb/core/hub.c
2644 return ret;
2645 }
2646
2647 static int usb_get_hub_port_power_state(struct usb_device *hdev, int
port1)
2648 {
2649 struct usb_hub *hub = hdev_to_hub(hdev);
2650 struct usb_port_status data;
2651 u16 portstatus;
2652 int ret;
2653
2654ret = get_port_status(hub->hdev, port1, &data);
2655 if (ret < 4) {
2656 dev_err(hub->intfdev,
2657 "%s failed (err = %d)\n", __func__, ret);
2658 if (ret >= 0)
2659 ret = -EIO;
2660 return ret;
2661 } else
2662 portstatus = le16_to_cpu(data.wPortStatus);
2663 return port_is_power_on(hub, portstatus);
2664 }
This is a real problem. It looks like it really is necessary to call
hub_port_status() here, not get_port_status(). Would you like to fix
this?
Yeah. I'd like to fix it.
The reason for changing the return codes from clear_port_feature() and
set_port_feature() is simple. The values they return are meant for
internal use within the kernel, whereas the return code from
store_port_power_control() will be passed back to userspace.
Alan Stern
--
Best Regards
Tianyu Lan
linux kernel enabling team
--
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
[no subject]
Hello, I am from the company "Code Mercenaries GmbH" from Germany. We have some USB HID devices wich work with Linux. Since kernel version 2.6 our default products will be included in the kernel. Devicedetails VendorID: 0x07C0 ProductIDs: 0x1500, 0x1501, 0x1511, 0x1512, 0x1503 Devicename: iowarrior Now we have some new custom product IDs but this two new devices get no node in dev/usb/ , but I can find the with "lsusb". If I run "modinfo iowarrior" there will be 5 alias (with the default pIDs) . The two new pIDs are: 0x158A, 0x158B I have not much experiance with linux (I work with Ubuntu 12.04). What have be done to get the device nodes to work with them? Have I add some rules? Or have I edit the iowarrior.ko? Regards Christoph Jung -- 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: host: tegra: code clean up
Hi,
On Wed, Sep 12, 2012 at 12:32:42PM +0530, Venu Byravarasu wrote:
> As part of code clean up, used devm counterparts for the APIs
> possible.
>
> Signed-off-by: Venu Byravarasu
EHCI is Alan's domain.
> ---
> drivers/usb/host/ehci-tegra.c | 46 ++--
> 1 files changed, 16 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
> index c0d4732..532db04 100644
> --- a/drivers/usb/host/ehci-tegra.c
> +++ b/drivers/usb/host/ehci-tegra.c
> @@ -634,7 +634,8 @@ static int tegra_ehci_probe(struct platform_device *pdev)
>
> setup_vbus_gpio(pdev, pdata);
>
> - tegra = kzalloc(sizeof(struct tegra_ehci_hcd), GFP_KERNEL);
> + tegra = devm_kzalloc(&pdev->dev, sizeof(struct tegra_ehci_hcd),
> + GFP_KERNEL);
> if (!tegra)
> return -ENOMEM;
>
> @@ -642,13 +643,12 @@ static int tegra_ehci_probe(struct platform_device
> *pdev)
> dev_name(&pdev->dev));
> if (!hcd) {
> dev_err(&pdev->dev, "Unable to create HCD\n");
> - err = -ENOMEM;
> - goto fail_hcd;
> + return -ENOMEM;
> }
>
> platform_set_drvdata(pdev, tegra);
>
> - tegra->clk = clk_get(&pdev->dev, NULL);
> + tegra->clk = devm_clk_get(&pdev->dev, NULL);
> if (IS_ERR(tegra->clk)) {
> dev_err(&pdev->dev, "Can't get ehci clock\n");
> err = PTR_ERR(tegra->clk);
> @@ -657,9 +657,9 @@ static int tegra_ehci_probe(struct platform_device *pdev)
>
> err = clk_prepare_enable(tegra->clk);
> if (err)
> - goto fail_clken;
> + goto fail_clk;
>
> - tegra->emc_clk = clk_get(&pdev->dev, "emc");
> + tegra->emc_clk = devm_clk_get(&pdev->dev, "emc");
> if (IS_ERR(tegra->emc_clk)) {
> dev_err(&pdev->dev, "Can't get emc clock\n");
> err = PTR_ERR(tegra->emc_clk);
> @@ -677,7 +677,7 @@ static int tegra_ehci_probe(struct platform_device *pdev)
> }
> hcd->rsrc_start = res->start;
> hcd->rsrc_len = resource_size(res);
> - hcd->regs = ioremap(res->start, resource_size(res));
> + hcd->regs = devm_ioremap(&pdev->dev, res->start, resource_size(res));
> if (!hcd->regs) {
> dev_err(&pdev->dev, "Failed to remap I/O memory\n");
> err = -ENOMEM;
> @@ -701,8 +701,8 @@ static int tegra_ehci_probe(struct platform_device *pdev)
> break;
> default:
> err = -ENODEV;
> - dev_err(&pdev->dev, "unknown usb instance\n");
> - goto fail_phy;
> + dev_err(&pdev->dev, "unknown usb inst:%d\n", instance);
> + goto fail_io;
> }
> }
>
> @@ -712,7 +712,7 @@ static int tegra_ehci_probe(struct platform_device *pdev)
> if (IS_ERR(tegra->phy)) {
> dev_err(&pdev->dev, "Failed to open USB phy\n");
> err = -ENXIO;
> - goto fail_phy;
> + goto fail_io;
> }
>
> usb_phy_init(&tegra->phy->u_phy);
> @@ -735,7 +735,8 @@ static int tegra_ehci_probe(struct platform_device *pdev)
>
> #ifdef CONFIG_USB_OTG_UTILS
> if (pdata->operating_mode == TEGRA_USB_OTG) {
> - tegra->transceiver = usb_get_phy(USB_PHY_TYPE_USB2);
> + tegra->transceiver =
> + devm_usb_get_phy(&pdev->dev, USB_PHY_TYPE_USB2);
> if (!IS_ERR_OR_NULL(tegra->transceiver))
> otg_set_host(tegra->transceiver->otg, &hcd->self);
> }
> @@ -743,7 +744,7 @@ static int tegra_ehci_probe(struct platform_device *pdev)
>
> err = usb_add_hcd(hcd, irq, IRQF_SHARED);
> if (err) {
> - dev_err(&pdev->dev, "Failed to add USB HCD\n");
> + dev_err(&pdev->dev, "usb_add_hcd failed with err 0x%x\n", err);
> goto fail;
> }
>
> @@ -752,32 +753,23 @@ static int tegra_ehci_probe(struct platform_device
> *pdev)
>
> /* Don't skip the pm_runtime_forbid call if wakeup isn't working */
> /* if (!pdata->power_down_on_bus_suspend) */
> - pm_runtime_forbid(&pdev->dev);
> + pm_runtime_forbid(&pdev->dev);
> pm_runtime_enable(&pdev->dev);
> pm_runtime_put_sync(&pdev->dev);
> return err;
>
> fail:
> #ifdef CONFIG_USB_OTG_UTILS
> - if (!IS_ERR_OR_NULL(tegra->transceiver)) {
> + if (!IS_ERR_OR_NULL(tegra->transceiver))
> otg_set_host(tegra->transceiver->otg, NULL);
> - usb_put_phy(tegra->transceiver);
> - }
> #endif
> usb_phy_shutdown(&tegra->phy->u_phy);
> -fail_phy:
> - iounmap(hcd->regs);
> fail_io:
> clk_disable_unprepare(tegra->emc_clk);
> - clk_put(tegra->emc_clk);
> fail_emc_clk:
> clk_disable_unprepare(tegra->clk);
> -fail_clken:
> - clk_put(tegra->clk);
> fail_clk
Re: EHCI: iaa_watchdog_start() warning followed by NULL ptr dereference in start_unlink_async()
On 9/12/2012 6:29 PM, Alan Stern wrote: > On Wed, 12 Sep 2012, Pavan Kondeti wrote: > >> Thanks for your response. I and Hemant work together. We are thinking a >> scenario where this NULL dereference could happen. Please let us know if >> our understanding is correct or not. we are assuming that async doorbell >> interrupt can not be stopped by software as mentioned at >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=6feff1b92bedab133c5835e510d11f62e843b257 > > ... > > Your analysis looks right. Good work. By the way, if the IAA > interrupt doesn't fire within 10 ms of the IAA doorbell, your EHCI > controller has a serious design flaw. > Thanks. I have seen watchdog timer getting expired occasionally in my testing. I will check this with our hardware designers. Another possibility could be CPU being in idle (C) state when controller generates IAAD interrupt. I will check this. >> If at all the above scenario is possible, we have to fix the race >> between watchdog timer function and IAAD interrupt handler. In other >> words, we should not call end_unlink_async() prematurely. can we simply >> return from end_unlink_async if QH state != QH_STATE_UNLINK to avoid >> this scenario? > > It would be better to change ehci_iaa_watchdog() and ehci_irq(). > Where they test that ehci->reclaim is non-NULL, they should also test > that ehci->reclaim->qh_state == QH_STATE_UNLINK. That way the driver > doesn't end up doing a bunch of extra work and incrementing the > statistics counter incorrectly. > Agreed. Thanks, Pavan -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] usb: otg: add device tree support to otg library
On 09/06/2012 05:27 PM, Marc Kleine-Budde wrote: >> We can use something like "-phy" as the phandle name. And the >> users can get the phy by using >> devm_usb_get_phy_by_phandle(dev, ""). >> (So the frwrk appends *-phy* to the name and searches). Or we don't >> have any restriction on the phandle naming conventions and search for >> the phandle by the name the user passes in devm_usb_get_phy_by_phandle >> directly. > > Maintainer, I need a Maintainer. Can someone please decide what we want > to have here. I can code all that, but please someone has to make a > decision. Now, please. Like I said on another reply: phyN (phy1, phy2, ... phyN) is better since eventually we want to turn this into a kernel-wide PHY layer. >>> I think Marc is wondering how to handle the below two case in such way. >>> - how to get the port number the phy is attached to >>> - how to describe it if a port has two phys. >> >> Would something like below work ? >> >> phy = <&phy1 0 &phy2 1>; >> >> where the first attribute is a phandle to the phy and the second is a >> port number ? > > We have two (and some brain damaged) use cases: > a) USB2/USB3: >One USB controller has two phys, one for USB2 the other for USB3. >The hardware has only one USB jack. > > b) IMHO "poorly abstracted" USB devices, where there are actually two >USB ports per "device", there are two USB jacks on the hardware. > > c) mixture of a)+b) > > My current code (patch not yet published) implements: > > struct usb_phy *devm_usb_get_phy_by_phandle(struct device *dev, > int index) > > With a hard coded "phy" phandle string and a index to that phandle. Your > above example looks like this (taking 0 as base): > > DT: > phy = <&phy0 &phy1>; > > c-code: > phy0 = *devm_usb_get_phy_by_phandle(struct device *dev, 0) > phy1 = *devm_usb_get_phy_by_phandle(struct device *dev, 1) > > This solves use case: > a) The driver must know index 0 -> USB2 phy, index 1 -> USB3 phy > b) The driver must know index 0 -> phy of 1st usb port, >index 1 -> phy of 2nd USB port > > But c) is not so easy: > c) driver must know how many combined USB2/USB3 jacks and USB2 only >jack the hardware has. > > My solution fails for b) and thus c) if one of the ports (e.g. the first > one is/should not be used). In my ideal world of proper abstracted > devices each USB port would have its own device entry in the DT and > would just stay "disabled". Your solution is superior here. But > struggles at c), too. > > Both solutions lack to describe what kind of phy it is. > > I'm now off for holidays, and back in the office on the 12th of September. I'm back in the office ;) Comments? Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH] usb: move children deallocation after quiescing the hub
On Wed, 12 Sep 2012, Alexander Shishkin wrote:
> Commit ff823c79a5c33194c2e5594f7c4686ea3547910c ("usb: move children
> to struct usb_port") forgot to consider the hub_disconnect sequence,
> which releases ports before quiescing the hub, which will lead to a
> use-after-free, since hub_quiesce() will try to disconnect ports'
> children, which are already deallocated. Simple modprobe dummy_hcd &&
> rmmod dummy_hcd will illustrate the problem.
>
> This patch moves deallocation of hub's ports after hub_quiesce() call
> in hub_disconnect().
>
> Cc: Lan Tianyu
> Signed-off-by: Alexander Shishkin
Good fix, thank you.
Acked-by: Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [balbi-usb:merge-result-for-greg 66/99] drivers/usb/core/hub.c:2654 usb_get_hub_port_power_state() error: doing dma on the stack ((null))
On Wed, 12 Sep 2012, Fengguang Wu wrote:
> Hi Felipe,
>
> FYI, there are new smatch warnings show up in
>
> tree: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
> merge-result-for-greg
> head: 23953bde3e4d6aa8780dc054f6ad9882ac63f4f4
> commit: e918fa161f510136fce45a524e934fe20e62c8b1 [66/99] Merge tag
> 'gadget-for-v3.7' into merge-result-for-greg
>
> drivers/usb/core/hub.c:2654 usb_get_hub_port_power_state() error: doing dma
> on the stack ((null))
> drivers/usb/core/hub.c:4733 store_port_power_control() info: why not
> propagate 'ret' from set_port_feature() instead of -5?
> drivers/usb/core/hub.c:4744 store_port_power_control() info: why not
> propagate 'ret' from clear_port_feature() instead of -5?
>
> vim +2654 drivers/usb/core/hub.c
> 2644return ret;
> 2645}
> 2646
> 2647static int usb_get_hub_port_power_state(struct usb_device
> *hdev, int port1)
> 2648{
> 2649struct usb_hub *hub = hdev_to_hub(hdev);
> 2650struct usb_port_status data;
> 2651u16 portstatus;
> 2652int ret;
> 2653
> > 2654ret = get_port_status(hub->hdev, port1, &data);
> 2655if (ret < 4) {
> 2656dev_err(hub->intfdev,
> 2657"%s failed (err = %d)\n", __func__,
> ret);
> 2658if (ret >= 0)
> 2659ret = -EIO;
> 2660return ret;
> 2661} else
> 2662portstatus = le16_to_cpu(data.wPortStatus);
> 2663return port_is_power_on(hub, portstatus);
> 2664}
This is a real problem. It looks like it really is necessary to call
hub_port_status() here, not get_port_status(). Would you like to fix
this?
The reason for changing the return codes from clear_port_feature() and
set_port_feature() is simple. The values they return are meant for
internal use within the kernel, whereas the return code from
store_port_power_control() will be passed back to userspace.
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: EHCI: iaa_watchdog_start() warning followed by NULL ptr dereference in start_unlink_async()
On Wed, 12 Sep 2012, Pavan Kondeti wrote: > Thanks for your response. I and Hemant work together. We are thinking a > scenario where this NULL dereference could happen. Please let us know if > our understanding is correct or not. we are assuming that async doorbell > interrupt can not be stopped by software as mentioned at > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=6feff1b92bedab133c5835e510d11f62e843b257 ... Your analysis looks right. Good work. By the way, if the IAA interrupt doesn't fire within 10 ms of the IAA doorbell, your EHCI controller has a serious design flaw. > If at all the above scenario is possible, we have to fix the race > between watchdog timer function and IAAD interrupt handler. In other > words, we should not call end_unlink_async() prematurely. can we simply > return from end_unlink_async if QH state != QH_STATE_UNLINK to avoid > this scenario? It would be better to change ehci_iaa_watchdog() and ehci_irq(). Where they test that ehci->reclaim is non-NULL, they should also test that ehci->reclaim->qh_state == QH_STATE_UNLINK. That way the driver doesn't end up doing a bunch of extra work and incrementing the statistics counter incorrectly. 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 v4] usb: phy: add R-Car USB phy driver
On 09/11/2012 04:06 AM, Kuninori Morimoto wrote:
> This patch adds Renesas R-Car USB phy driver.
> It supports R8A7779 chip at this point.
>
> R-Car has some USB controllers, but has only one phy-initializer.
> So, this driver is counting users.
>
> Signed-off-by: Kuninori Morimoto
> ---
> v3 -> v4
>
> - rcar_usb_phy_shutdown() became static
> - used priv->counter == x
> - removed dev_info()
> - MODULE_LICENSE("GPL v2")
>
> drivers/usb/phy/Kconfig| 12 +++
> drivers/usb/phy/Makefile |1 +
> drivers/usb/phy/rcar-phy.c | 225
>
> 3 files changed, 238 insertions(+)
> create mode 100644 drivers/usb/phy/rcar-phy.c
>
> diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
> index 63c339b..7eb73c5 100644
> --- a/drivers/usb/phy/Kconfig
> +++ b/drivers/usb/phy/Kconfig
> @@ -32,3 +32,15 @@ config MV_U3D_PHY
> help
> Enable this to support Marvell USB 3.0 phy controller for Marvell
> SoC.
> +
> +config USB_RCAR_PHY
> + tristate "Renesas R-Car USB phy support"
> + depends on USB || USB_GADGET
> + select USB_OTG_UTILS
> + help
> + Say Y here to add support for the Renesas R-Car USB phy driver.
> + This chip is typically used as USB phy for USB host, gadget.
> + This driver supports: R8A7779
> +
> + To compile this driver as a module, choose M here: the
> + module will be called rcar-phy.
> diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
> index b069f29..1a579a8 100644
> --- a/drivers/usb/phy/Makefile
> +++ b/drivers/usb/phy/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_OMAP_USB2) += omap-usb2.o
> obj-$(CONFIG_USB_ISP1301)+= isp1301.o
> obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o
> obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o
> +obj-$(CONFIG_USB_RCAR_PHY) += rcar-phy.o
> diff --git a/drivers/usb/phy/rcar-phy.c b/drivers/usb/phy/rcar-phy.c
> new file mode 100644
> index 000..3fce889
> --- /dev/null
> +++ b/drivers/usb/phy/rcar-phy.c
> @@ -0,0 +1,225 @@
> +/*
> + * Renesas R-Car USB phy driver
> + *
> + * Copyright (C) 2012 Renesas Solutions Corp.
> + * Kuninori Morimoto
> + *
> +
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* USBH common register */
> +#define USBPCTRL00x0800
> +#define USBPCTRL10x0804
> +#define USBST0x0808
> +#define USBEH0 0x080C
> +#define USBOH0 0x081C
> +#define USBCTL0 0x0858
> +#define EIIBC1 0x0094
> +#define EIIBC2 0x009C
> +
> +#ifdef CONFIG_ARCH_SUPPORTS_BIG_ENDIAN
That symbol is only defined on ARM's mach-ixp4xx. If you want to support
big endian hosts in general, you have to use a different symbol.
> +# define PHY_ENDIAN "BIG"
^^
It this used?
> +# define PHY_NO_SWAP 0x0003
> +#else
> +# define PHY_ENDIAN "LITTLE"
> +# define PHY_NO_SWAP 0x
> +#endif
> +
> +/* USBPCTRL1 */
> +#define PHY_RST (1 << 2)
> +#define PLL_ENB (1 << 1)
> +#define PHY_ENB (1 << 0)
> +
> +/* USBST */
> +#define ACT (1 << 31)
> +#define PLL (1 << 30)
> +
> +struct rcar_usb_phy_priv {
> + struct usb_phy phy;
> + spinlock_t lock;
> +
> + void __iomem *reg0;
> + void __iomem *reg1;
> + int counter;
> +};
> +
> +#define usb_phy_to_priv(p) container_of(p, struct rcar_usb_phy_priv, phy)
> +
> +
> +/*
> + * USB initial/install operation.
> + *
> + * This function setup USB phy.
> + * The used value and setting order came from
> + * [USB :: Initial setting] on datasheet.
> + */
> +static int rcar_usb_phy_init(struct usb_phy *phy)
> +{
> + struct rcar_usb_phy_priv *priv = usb_phy_to_priv(phy);
> + struct device *dev = phy->dev;
> + void __iomem *reg0 = priv->reg0;
> + void __iomem *reg1 = priv->reg1;
> + int i;
> + u32 val;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&priv->lock, flags);
> + if (priv->counter == 0) {
> +
> + /*
> + * USB phy start-up
> + */
> +
> + /* (1) USB-PHY standby release */
> + iowrite32(PHY_ENB, (reg0 + USBPCTRL1));
> +
> + /* (2) start USB-PHY internal PLL */
> + iowrite32(PHY_ENB | PLL_ENB, (reg0 + USBPCTRL1));
> +
> + /* (3) USB module status check */
> + for (i = 0; i < 1024; i++) {
> + udelay(10);
> + val = ioread32(reg0 + USBST);
> + if ((ACT | PLL) == val)
nitpick:
It' more common to write the comparison the other way round:
if (val == (ACT | PLL))
The compiler will warn you, if you do an assignment instead of
Re: [PATCH 2/2] usb: chipidea: usbmisc: prepare driver to handle more than one soc
On 09/07/2012 10:20 AM, Richard Zhao wrote: > On Thu, Sep 06, 2012 at 05:18:29PM +0200, Marc Kleine-Budde wrote: >> On 09/06/2012 05:15 PM, Richard Zhao wrote: >>> Hi Marc, >>> >>> usbmisc_imx6q.c is only for imx6x. And for a certain running kernel, >>> there will be always one driver instance. >> >> It's currently only for imx6q, but I've patches[1] in queue for mx53. >> And mx35 is about to be written. > It's per-SoC file. mx53 and mx35 should have their specific driver, > because the register layout is SoC specific. Have you had a look at our patch[1]? It adds support for mx53 in a very clean way. What do you suggest? Create a mx53 driver that is about 90% identical with the imx6q driver? Marc >> [1] >> http://git.pengutronix.de/?p=mkl/linux.git;a=commit;h=bdeff138ba8bb40856c9946b67df2604fdb4416b -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [balbi-usb:merge-result-for-greg 66/99] drivers/usb/core/hub.c:2654 usb_get_hub_port_power_state() error: doing dma on the stack ((null))
On Wed, Sep 12, 2012 at 03:02:13PM +0300, Felipe Balbi wrote: > Hi, > > On Wed, Sep 12, 2012 at 11:50:57AM +0300, Dan Carpenter wrote: > > On Wed, Sep 12, 2012 at 04:26:22PM +0800, Fengguang Wu wrote: > > > Hi Felipe, > > > > > > FYI, there are new smatch warnings show up in > > > > > > tree: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git > > > merge-result-for-greg > > > head: 23953bde3e4d6aa8780dc054f6ad9882ac63f4f4 > > > commit: e918fa161f510136fce45a524e934fe20e62c8b1 [66/99] Merge tag > > > 'gadget-for-v3.7' into merge-result-for-greg > > > > > > drivers/usb/core/hub.c:2654 usb_get_hub_port_power_state() error: doing > > > dma on the stack ((null)) > > that's not part of what I handle :-( > > And merge-result-for-greg was really a temporary branch, btw :-) No problem. I'll stop testing this branch :) Thanks, Fengguang -- 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: [balbi-usb:merge-result-for-greg 66/99] drivers/usb/core/hub.c:2654 usb_get_hub_port_power_state() error: doing dma on the stack ((null))
Hi, On Wed, Sep 12, 2012 at 11:50:57AM +0300, Dan Carpenter wrote: > On Wed, Sep 12, 2012 at 04:26:22PM +0800, Fengguang Wu wrote: > > Hi Felipe, > > > > FYI, there are new smatch warnings show up in > > > > tree: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git > > merge-result-for-greg > > head: 23953bde3e4d6aa8780dc054f6ad9882ac63f4f4 > > commit: e918fa161f510136fce45a524e934fe20e62c8b1 [66/99] Merge tag > > 'gadget-for-v3.7' into merge-result-for-greg > > > > drivers/usb/core/hub.c:2654 usb_get_hub_port_power_state() error: doing dma > > on the stack ((null)) that's not part of what I handle :-( And merge-result-for-greg was really a temporary branch, btw :-) -- balbi signature.asc Description: Digital signature
[PATCH 12/12] USB: chipidea: re-order irq handling to avoid unhandled irqs
From: Richard Zhao
- let role driver handle irq before ID change check; this gives the
role driver a chance to handle disconnect;
- disable irq during switch role; no role driver to handle irq in
the period.
Tested-by: Michael Grzeschik
Tested-by: Marc Kleine-Budde
Signed-off-by: Richard Zhao
Signed-off-by: Alexander Shishkin
---
drivers/usb/chipidea/core.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 19ef324..f69d029 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -279,6 +279,7 @@ static void ci_role_work(struct work_struct *work)
ci_role_stop(ci);
ci_role_start(ci, role);
+ enable_irq(ci->irq);
}
}
@@ -318,18 +319,22 @@ static irqreturn_t ci_irq(int irq, void *data)
{
struct ci13xxx *ci = data;
irqreturn_t ret = IRQ_NONE;
+ u32 otgsc = 0;
- if (ci->is_otg) {
- u32 sts = hw_read(ci, OP_OTGSC, ~0);
+ if (ci->is_otg)
+ otgsc = hw_read(ci, OP_OTGSC, ~0);
+
+ if (ci->role != CI_ROLE_END)
+ ret = ci_role(ci)->irq(ci);
- if (sts & OTGSC_IDIS) {
- hw_write(ci, OP_OTGSC, OTGSC_IDIS, OTGSC_IDIS);
- queue_work(ci->wq, &ci->work);
- ret = IRQ_HANDLED;
- }
+ if (ci->is_otg && (otgsc & OTGSC_IDIS)) {
+ hw_write(ci, OP_OTGSC, OTGSC_IDIS, OTGSC_IDIS);
+ disable_irq_nosync(ci->irq);
+ queue_work(ci->wq, &ci->work);
+ ret = IRQ_HANDLED;
}
- return ci->role == CI_ROLE_END ? ret : ci_role(ci)->irq(ci);
+ return ret;
}
static DEFINE_IDA(ci_ida);
--
1.7.10.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
[PATCH 11/12] USB: chipidea: add -DDEBUG if debugging is enabled
From: Richard Zhao This patch turns on debugging output if CONFIG_USB_CHIPIDEA_DEBUG is enabled. Signed-off-by: Richard Zhao Tested-by: Michael Grzeschik Tested-by: Marc Kleine-Budde Signed-off-by: Alexander Shishkin --- drivers/usb/chipidea/Makefile |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile index 57e510f..d92ca32 100644 --- a/drivers/usb/chipidea/Makefile +++ b/drivers/usb/chipidea/Makefile @@ -1,3 +1,5 @@ +ccflags-$(CONFIG_USB_CHIPIDEA_DEBUG) := -DDEBUG + obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc.o ci_hdrc-y := core.o -- 1.7.10.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
[PATCH 10/12] USB: chipidea: add vbus detect for udc
From: Richard Zhao
Using vbus valid interrupt to detect vbus.
Tested-by: Michael Grzeschik
Tested-by: Marc Kleine-Budde
Signed-off-by: Richard Zhao
Signed-off-by: Alexander Shishkin
---
drivers/usb/chipidea/ci.h |1 +
drivers/usb/chipidea/udc.c | 39 ++-
2 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index d738603..e25d126 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -139,6 +139,7 @@ struct ci13xxx {
enum ci_rolerole;
boolis_otg;
struct work_struct work;
+ struct work_struct vbus_work;
struct workqueue_struct *wq;
struct dma_pool *qh_pool;
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index d214448..2f45bba 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -305,6 +305,18 @@ static u32 hw_test_and_clear_intr_active(struct ci13xxx
*ci)
return reg;
}
+static void hw_enable_vbus_intr(struct ci13xxx *ci)
+{
+ hw_write(ci, OP_OTGSC, OTGSC_AVVIS, OTGSC_AVVIS);
+ hw_write(ci, OP_OTGSC, OTGSC_AVVIE, OTGSC_AVVIE);
+ queue_work(ci->wq, &ci->vbus_work);
+}
+
+static void hw_disable_vbus_intr(struct ci13xxx *ci)
+{
+ hw_write(ci, OP_OTGSC, OTGSC_AVVIE, 0);
+}
+
/**
* hw_test_and_clear_setup_guard: test & clear setup guard (execute without
*interruption)
@@ -371,6 +383,16 @@ static int hw_usb_reset(struct ci13xxx *ci)
return 0;
}
+static void vbus_work(struct work_struct *work)
+{
+ struct ci13xxx *ci = container_of(work, struct ci13xxx, vbus_work);
+
+ if (hw_read(ci, OP_OTGSC, OTGSC_AVV))
+ usb_gadget_vbus_connect(&ci->gadget);
+ else
+ usb_gadget_vbus_disconnect(&ci->gadget);
+}
+
/**
* UTIL block
*/
@@ -1370,6 +1392,7 @@ static int ci13xxx_vbus_session(struct usb_gadget
*_gadget, int is_active)
if (is_active) {
pm_runtime_get_sync(&_gadget->dev);
hw_device_reset(ci, USBMODE_CM_DC);
+ hw_enable_vbus_intr(ci);
hw_device_state(ci, ci->ep0out->qh.dma);
} else {
hw_device_state(ci, 0);
@@ -1544,8 +1567,10 @@ static int ci13xxx_start(struct usb_gadget *gadget,
pm_runtime_get_sync(&ci->gadget.dev);
if (ci->platdata->flags & CI13XXX_PULLUP_ON_VBUS) {
if (ci->vbus_active) {
- if (ci->platdata->flags & CI13XXX_REGS_SHARED)
+ if (ci->platdata->flags & CI13XXX_REGS_SHARED) {
hw_device_reset(ci, USBMODE_CM_DC);
+ hw_enable_vbus_intr(ci);
+ }
} else {
pm_runtime_put_sync(&ci->gadget.dev);
goto done;
@@ -1651,6 +1676,13 @@ static irqreturn_t udc_irq(struct ci13xxx *ci)
} else {
retval = IRQ_NONE;
}
+
+ intr = hw_read(ci, OP_OTGSC, ~0);
+ hw_write(ci, OP_OTGSC, ~0, intr);
+
+ if (intr & (OTGSC_AVVIE & OTGSC_AVVIS))
+ queue_work(ci->wq, &ci->vbus_work);
+
spin_unlock(&ci->lock);
return retval;
@@ -1726,6 +1758,7 @@ static int udc_start(struct ci13xxx *ci)
retval = hw_device_reset(ci, USBMODE_CM_DC);
if (retval)
goto put_transceiver;
+ hw_enable_vbus_intr(ci);
}
retval = device_register(&ci->gadget.dev);
@@ -1788,6 +1821,9 @@ static void udc_stop(struct ci13xxx *ci)
if (ci == NULL)
return;
+ hw_disable_vbus_intr(ci);
+ cancel_work_sync(&ci->vbus_work);
+
usb_del_gadget_udc(&ci->gadget);
destroy_eps(ci);
@@ -1828,6 +1864,7 @@ int ci_hdrc_gadget_init(struct ci13xxx *ci)
rdrv->irq = udc_irq;
rdrv->name = "gadget";
ci->roles[CI_ROLE_GADGET] = rdrv;
+ INIT_WORK(&ci->vbus_work, vbus_work);
return 0;
}
--
1.7.10.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
[PATCH 09/12] USB: chipidea: acknowledge ID change interrupt in irq handler
From: Richard Zhao
In order to avoid re-queueing of the role changing work, we need to clear
the ID change interrupt bit right in the irq handler.
Tested-by: Michael Grzeschik
Tested-by: Marc Kleine-Budde
Signed-off-by: Richard Zhao
Signed-off-by: Alexander Shishkin
---
drivers/usb/chipidea/core.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 3c3ed77..19ef324 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -273,8 +273,6 @@ static void ci_role_work(struct work_struct *work)
struct ci13xxx *ci = container_of(work, struct ci13xxx, work);
enum ci_role role = ci_otg_role(ci);
- hw_write(ci, OP_OTGSC, OTGSC_IDIS, OTGSC_IDIS);
-
if (role != ci->role) {
dev_dbg(ci->dev, "switching from %s to %s\n",
ci_role(ci)->name, ci->roles[role]->name);
@@ -325,6 +323,7 @@ static irqreturn_t ci_irq(int irq, void *data)
u32 sts = hw_read(ci, OP_OTGSC, ~0);
if (sts & OTGSC_IDIS) {
+ hw_write(ci, OP_OTGSC, OTGSC_IDIS, OTGSC_IDIS);
queue_work(ci->wq, &ci->work);
ret = IRQ_HANDLED;
}
--
1.7.10.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
[PATCH 06/12] USB: chipidea: add imx usbmisc support
From: Richard Zhao
i.MX usb controllers share non-core registers, which may include
SoC specific controls. We turn it into a usbmisc device and usbmisc
driver set operations needed by ci13xxx_imx driver.
For example, Sabrelite board has bad over-current design, we can
usbmisc to disable over-current detection.
Acked-by: Sascha Hauer
Signed-off-by: Richard Zhao
Signed-off-by: Alexander Shishkin
---
.../devicetree/bindings/usb/ci13xxx-imx.txt|5 +
.../devicetree/bindings/usb/usbmisc-imx.txt| 14 ++
drivers/usb/chipidea/Makefile |2 +-
drivers/usb/chipidea/ci13xxx_imx.c | 64
drivers/usb/chipidea/ci13xxx_imx.h | 28
drivers/usb/chipidea/usbmisc_imx6q.c | 162
6 files changed, 274 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/usb/usbmisc-imx.txt
create mode 100644 drivers/usb/chipidea/ci13xxx_imx.h
create mode 100644 drivers/usb/chipidea/usbmisc_imx6q.c
diff --git a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
index 2c29041..5778b9c 100644
--- a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
+++ b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
@@ -7,7 +7,10 @@ Required properties:
Optional properties:
- fsl,usbphy: phandler of usb phy that connects to the only one port
+- fsl,usbmisc: phandler of non-core register device, with one argument
+ that indicate usb controller index
- vbus-supply: regulator for vbus
+- disable-over-current: disable over current detect
Examples:
usb@02184000 { /* USB OTG */
@@ -15,4 +18,6 @@ usb@02184000 { /* USB OTG */
reg = <0x02184000 0x200>;
interrupts = <0 43 0x04>;
fsl,usbphy = <&usbphy1>;
+ fsl,usbmisc = <&usbmisc 0>;
+ disable-over-current;
};
diff --git a/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
b/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
new file mode 100644
index 000..97ce94e
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
@@ -0,0 +1,14 @@
+* Freescale i.MX non-core registers
+
+Required properties:
+- #index-cells: Cells used to descibe usb controller index. Should be <1>
+- compatible: Should be one of below:
+ "fsl,imx6q-usbmisc" for imx6q
+- reg: Should contain registers location and length
+
+Examples:
+usbmisc@02184800 {
+ #index-cells = <1>;
+ compatible = "fsl,imx6q-usbmisc";
+ reg = <0x02184800 0x200>;
+};
diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
index 5c66d9c..57e510f 100644
--- a/drivers/usb/chipidea/Makefile
+++ b/drivers/usb/chipidea/Makefile
@@ -15,5 +15,5 @@ ifneq ($(CONFIG_PCI),)
endif
ifneq ($(CONFIG_OF_DEVICE),)
- obj-$(CONFIG_USB_CHIPIDEA) += ci13xxx_imx.o
+ obj-$(CONFIG_USB_CHIPIDEA) += ci13xxx_imx.o usbmisc_imx6q.o
endif
diff --git a/drivers/usb/chipidea/ci13xxx_imx.c
b/drivers/usb/chipidea/ci13xxx_imx.c
index ef60d06..96ac67b 100644
--- a/drivers/usb/chipidea/ci13xxx_imx.c
+++ b/drivers/usb/chipidea/ci13xxx_imx.c
@@ -22,6 +22,7 @@
#include
#include "ci.h"
+#include "ci13xxx_imx.h"
#define pdev_to_phy(pdev) \
((struct usb_phy *)platform_get_drvdata(pdev))
@@ -34,6 +35,55 @@ struct ci13xxx_imx_data {
struct regulator *reg_vbus;
};
+static const struct usbmisc_ops *usbmisc_ops;
+
+/* Common functions shared by usbmisc drivers */
+
+int usbmisc_set_ops(const struct usbmisc_ops *ops)
+{
+ if (usbmisc_ops)
+ return -EBUSY;
+
+ usbmisc_ops = ops;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(usbmisc_set_ops);
+
+void usbmisc_unset_ops(const struct usbmisc_ops *ops)
+{
+ usbmisc_ops = NULL;
+}
+EXPORT_SYMBOL_GPL(usbmisc_unset_ops);
+
+int usbmisc_get_init_data(struct device *dev, struct usbmisc_usb_device
*usbdev)
+{
+ struct device_node *np = dev->of_node;
+ struct of_phandle_args args;
+ int ret;
+
+ usbdev->dev = dev;
+
+ ret = of_parse_phandle_with_args(np, "fsl,usbmisc", "#index-cells",
+ 0, &args);
+ if (ret) {
+ dev_err(dev, "Failed to parse property fsl,usbmisc, errno %d\n",
+ ret);
+ memset(usbdev, 0, sizeof(*usbdev));
+ return ret;
+ }
+ usbdev->index = args.args[0];
+ of_node_put(args.np);
+
+ if (of_find_property(np, "disable-over-current", NULL))
+ usbdev->disable_oc = 1;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(usbmisc_get_init_data);
+
+/* End of common functions shared by usbmisc drivers*/
+
static struct ci13xxx_platform_data ci13xxx_imx_platdata __devinitdata = {
.name = "ci13xxx_imx",
.flags = CI13XXX_REQUIRE_TRANSCEIVER |
@@ -51,6 +101,10 @@ static int __devinit ci13xxx_imx_probe(struct
platform_device *pdev)
[PATCH 08/12] USB: chipidea: delay 2ms before read ID status at probe time
From: Richard Zhao
The ID pin needs 1ms debounce time, even at probe time. We delay 2ms
to be on the safe side.
Tested-by: Michael Grzeschik
Tested-by: Marc Kleine-Budde
Signed-off-by: Richard Zhao
Signed-off-by: Alexander Shishkin
---
drivers/usb/chipidea/core.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 1083585..3c3ed77 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -462,6 +462,8 @@ static int __devinit ci_hdrc_probe(struct platform_device
*pdev)
if (ci->roles[CI_ROLE_HOST] && ci->roles[CI_ROLE_GADGET]) {
ci->is_otg = true;
+ /* ID pin needs 1ms debouce time, we delay 2ms for safe */
+ mdelay(2);
ci->role = ci_otg_role(ci);
} else {
ci->role = ci->roles[CI_ROLE_HOST]
--
1.7.10.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
[PATCH 04/12] usb: chipidea: cleanup dma_pool if udc_start() fails
From: Marc Kleine-Budde
If udc_start() fails the qh_pool dma-pool cannot be closed because
it's still in use. This patch factors out the dma_pool_free() loop
into destroy_eps() and calls it in the error path of udc_start(),
too.
Cc:
Reviewed-by: Richard Zhao
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Alexander Shishkin
---
drivers/usb/chipidea/udc.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 3a755e5..2d8b609 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1503,6 +1503,17 @@ static int init_eps(struct ci13xxx *ci)
return retval;
}
+static void destroy_eps(struct ci13xxx *ci)
+{
+ int i;
+
+ for (i = 0; i < ci->hw_ep_max; i++) {
+ struct ci13xxx_ep *mEp = &ci->ci13xxx_ep[i];
+
+ dma_pool_free(ci->qh_pool, mEp->qh.ptr, mEp->qh.dma);
+ }
+}
+
/**
* ci13xxx_start: register a gadget driver
* @gadget: our gadget
@@ -1710,7 +1721,7 @@ static int udc_start(struct ci13xxx *ci)
if (ci->platdata->flags & CI13XXX_REQUIRE_TRANSCEIVER) {
if (ci->transceiver == NULL) {
retval = -ENODEV;
- goto free_pools;
+ goto destroy_eps;
}
}
@@ -1761,6 +1772,8 @@ unreg_device:
put_transceiver:
if (!IS_ERR_OR_NULL(ci->transceiver) && ci->global_phy)
usb_put_phy(ci->transceiver);
+destroy_eps:
+ destroy_eps(ci);
free_pools:
dma_pool_destroy(ci->td_pool);
free_qh_pool:
@@ -1775,18 +1788,12 @@ free_qh_pool:
*/
static void udc_stop(struct ci13xxx *ci)
{
- int i;
-
if (ci == NULL)
return;
usb_del_gadget_udc(&ci->gadget);
- for (i = 0; i < ci->hw_ep_max; i++) {
- struct ci13xxx_ep *mEp = &ci->ci13xxx_ep[i];
-
- dma_pool_free(ci->qh_pool, mEp->qh.ptr, mEp->qh.dma);
- }
+ destroy_eps(ci);
dma_pool_destroy(ci->td_pool);
dma_pool_destroy(ci->qh_pool);
--
1.7.10.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
[PATCH 07/12] USB: chipidea: imx: add pinctrl support
From: Richard Zhao
Some controllers may not need to setup pinctrl, so we don't fail the
probe if pinctrl get/select failed.
Tested-by: Michael Grzeschik
Tested-by: Marc Kleine-Budde
Signed-off-by: Richard Zhao
Signed-off-by: Alexander Shishkin
---
drivers/usb/chipidea/ci13xxx_imx.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/usb/chipidea/ci13xxx_imx.c
b/drivers/usb/chipidea/ci13xxx_imx.c
index 96ac67b..0f5ca4b 100644
--- a/drivers/usb/chipidea/ci13xxx_imx.c
+++ b/drivers/usb/chipidea/ci13xxx_imx.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include "ci.h"
#include "ci13xxx_imx.h"
@@ -99,6 +100,7 @@ static int __devinit ci13xxx_imx_probe(struct
platform_device *pdev)
struct device_node *phy_np;
struct resource *res;
struct regulator *reg_vbus;
+ struct pinctrl *pinctrl;
int ret;
if (of_find_property(pdev->dev.of_node, "fsl,usbmisc", NULL)
@@ -117,6 +119,11 @@ static int __devinit ci13xxx_imx_probe(struct
platform_device *pdev)
return -ENOENT;
}
+ pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
+ if (IS_ERR(pinctrl))
+ dev_warn(&pdev->dev, "pinctrl get/select failed, err=%ld\n",
+ PTR_ERR(pinctrl));
+
data->clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(data->clk)) {
dev_err(&pdev->dev,
--
1.7.10.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
[PATCH 05/12] usb: chipidea: udc: don't stall endpoint if request list is empty in isr_tr_complete_low
From: Michael Grzeschik
When attaching an imx28 or imx53 in USB gadget mode to a Windows host and
starting a rndis connection we see this message every 4-10 seconds:
g_ether gadget: high speed config #2: RNDIS
Analysis shows that each time this message is printed, the rndis connection is
re-establish due to a reset because of a stalled endpoint (ep 0, dir 1). The
endpoint is stalled because the reqeust complete bit on that endpoint is set,
but in isr_tr_complete_low() the endpoint request list (mEp->qh.queue) is
empty.
This patch removed this check, because the code doesn't take the following
situation into account:
The loop over all endpoints in isr_tr_complete_handler() will call ep_nuke() on
both ep0/dir0 and ep/dir1 in the first loop. Pending reqeusts will be flushed
and completed here. There seems to be a race condition, the request is nuked,
but the request complete bit will be set, too. The subsequent check (in
ep0/dir1's loop cycle) for endpoint request list (mEp->qh.queue) empty will
fail.
Both other mainline chipidea drivers (mv_udc_core.c and fsl_udc_core.c) don't
have this check.
Cc:
Signed-off-by: Michael Grzeschik
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Alexander Shishkin
---
drivers/usb/chipidea/udc.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 2d8b609..d214448 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -771,10 +771,7 @@ __acquires(mEp->lock)
{
struct ci13xxx_req *mReq, *mReqTemp;
struct ci13xxx_ep *mEpTemp = mEp;
- int uninitialized_var(retval);
-
- if (list_empty(&mEp->qh.queue))
- return -EINVAL;
+ int retval = 0;
list_for_each_entry_safe(mReq, mReqTemp, &mEp->qh.queue,
queue) {
--
1.7.10.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
[PATCH 03/12] usb: chipidea: udc: fix error path in udc_start()
From: Marc Kleine-Budde
This patch fixes the error path of udc_start(). Now NULL is used to
unset the peripheral with otg_set_peripheral().
Cc:
Reviewed-by: Richard Zhao
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Alexander Shishkin
---
drivers/usb/chipidea/udc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 32ee870..3a755e5 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1748,7 +1748,7 @@ static int udc_start(struct ci13xxx *ci)
remove_trans:
if (!IS_ERR_OR_NULL(ci->transceiver)) {
- otg_set_peripheral(ci->transceiver->otg, &ci->gadget);
+ otg_set_peripheral(ci->transceiver->otg, NULL);
if (ci->global_phy)
usb_put_phy(ci->transceiver);
}
--
1.7.10.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: XHCI: URB not cancelled during disconnect of a MSC device
Hi, >> I am using v3.5 kernel and running a test where I disconnect >> a SS MSC device while a big file is being written to it. I am >> also watching the lsusb output in parallel. Expectation is >> that SS MSC device should immediately disappear from lsusb >> output but sometime I see that SS MSC is listed for 30 >> seconds and then only disappears. Log is copied below. >> >> Looking further into the issue shows that in failing case an >> URB is not given back by XHCI driver and so SCSI layer >> unlinks it after 30second of timeout. This URB was actually >> given to XHCI host controller and a disconnect happens while >> packet transfer was in progress. I looked at XHCI driver and >> could not find request being aborted by driver (in >> xhci_free_dev() fn) before issuing disable slot or reset >> device command. What is expectation in this scenario? Is it >> XHCI driver responsibility to abort and giveback all the >> request (as in EHCI using endpoint_disable()) OR host >> controller hardware should abort and post an error completion >> event for each request? Why XHCI driver doesn't have an >> endpoint_disable() implemented as done for other controller? >> > > I have faced similar scenario, check whether patch > http://marc.info/?l=linux-usb&m=134382746009339&w=2could could help, > Alan suggesting that hcd controller should release all URBs when device got > disconnected. It didn't help. Thanks, Ajay > > -RaviBabu > >> === Working case [ >> 3406.676989] Port Status Change Event for port 2 [ >> 3406.711530] get port status, actual port 1 status = 0x4202c0 >> [ 3406.711531] Get port status returned 0x4102c0 [ >> 3406.711629] clear port connect change, actual port 1 status >> = 0x4002c0 [ 3406.711664] clear port link state change, >> actual port 1 status = 0x2c0 [ 3406.721606] >> [E.f2e0b980.Transfer error on endpoint <=== URB submitted >> here but gets transfer error [ 3406.721742] Cleaning up >> stalled endpoint ring [ 3406.721744] Finding segment >> containing stopped TRB. >> [ 3406.721746] Finding endpoint context >> [ 3406.721747] Finding segment containing last TRB in TD. >> [ 3406.721749] Cycle state = 0x1 >> [ 3406.721750] New dequeue segment = f2073880 (virtual) [ >> 3406.721752] New dequeue pointer = 0x337be380 (DMA) [ >> 3406.721754] Queueing new dequeue state [ 3406.721756] Set TR >> Deq Ptr cmd, new deq seg = f2073880 (0x337be000 dma), new deq >> ptr = f37be380 (0x337be380 dma), new cycle = 1 [ >> 3406.721758]// Ding dong! >> [ 3406.721855] Giveback URB f2e0b980, len = 0, expected = 31, status = >> -71 <=== URB given back by XHCI driver >> = >> >> >> === Non Working case [ >> 2971.576389] Port Status Change Event for port 2 >> [ 2971.576487] [E.f2d0c480. <=== URB submitted but no error. >> [ 2971.585007] get port status, actual port 1 status = >> 0x4202c0 [ 2971.585079] Get port status returned 0x4102c0 [ >> 2971.585178] clear port connect change, actual port 1 status >> = 0x4002c0 [ 2971.585213] clear port link state change, >> actual port 1 status = 0x2c0 [ 2971.640030] get port status, >> actual port 1 status = 0x2d1 [ 2971.640031] Get port status >> returned 0x2d1 [ 2971.696029] get port status, actual port 1 >> status = 0x2d1 [ 2971.696031] Get port status returned 0x2d1 >> [ 2971.900031] get port status, actual port 1 status = 0x2d1 >> [ 2971.900034] Get port status returned 0x2d1 [ 2972.060480] >> Port Status Change Event for port 2 [ 2972.104039] get port >> status, actual port 1 status = 0x2802a0 [ 2972.104041] Get >> port status returned 0x3002a0 [ 2972.104079] clear port reset >> change, actual port 1 status = 0x802a0 [ 2972.104108] clear >> port warm(BH) reset change, actual port 1 status = 0x2a0 [ >> 2972.104138] clear port link state change, actual port 1 >> status = 0x2a0 [ 2972.104144] usb 6-2: USB disconnect, device number 6 >> >> <=== 30 seconds gap > >> >> [ 3002.080058] Cancel URB f2d0c480, dev 2, ep 0x81, starting at offset >> 0x337ad060 <== SCSI layer cancelling URB after 30 seconds >> [ 3002.080063]// Ding dong! >> [ 2972.060569] Stopped on Transfer TRB >> [ 3002.080817] Removing canceled TD starting at 0x337ad060 (dma). >> [ 3002.080820] Finding segment containing stopped TRB. >> [ 3002.080822] Finding endpoint context >> [ 3002.080823] Finding segment containing last TRB in TD. >> [ 3002.080825] Cycle state = 0x0 >> [ 3002.080827] New dequeue segment = f71628f0 (virtual) [ >> 3002.080828] New dequeue pointer = 0x337ad070 (DMA) [ >> 3002.080831] Set TR Deq Ptr cmd, new deq seg = f71628f0 >> (0x337ad000 dma), new deq ptr = f37ad070 (0x337ad070 dma), >> new cycle = 0 >> >> = >> >> Thanks >> Ajay >> -- >> 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 >> -- T
[PATCH 02/12] usb: chipidea: udc: add pullup fuction, needed by the uvc gadget
From: Michael Grzeschik
Add function to physicaly enable or disable of pullup connection on the USB-D+
line. The uvc gaget will fail, if this function is not implemented.
Cc:
Signed-off-by: Michael Grzeschik
Acked-by: Felipe Balbi
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Alexander Shishkin
---
drivers/usb/chipidea/udc.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 7801a3f..32ee870 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -78,8 +78,7 @@ static inline int ep_to_bit(struct ci13xxx *ci, int n)
}
/**
- * hw_device_state: enables/disables interrupts & starts/stops device (execute
- * without interruption)
+ * hw_device_state: enables/disables interrupts (execute without interruption)
* @dma: 0 => disable, !0 => enable and set dma engine
*
* This function returns an error code
@@ -91,9 +90,7 @@ static int hw_device_state(struct ci13xxx *ci, u32 dma)
/* interrupt, error, port change, reset, sleep/suspend */
hw_write(ci, OP_USBINTR, ~0,
USBi_UI|USBi_UEI|USBi_PCI|USBi_URI|USBi_SLI);
- hw_write(ci, OP_USBCMD, USBCMD_RS, USBCMD_RS);
} else {
- hw_write(ci, OP_USBCMD, USBCMD_RS, 0);
hw_write(ci, OP_USBINTR, ~0, 0);
}
return 0;
@@ -1420,6 +1417,21 @@ static int ci13xxx_vbus_draw(struct usb_gadget *_gadget,
unsigned mA)
return -ENOTSUPP;
}
+/* Change Data+ pullup status
+ * this func is used by usb_gadget_connect/disconnet
+ */
+static int ci13xxx_pullup(struct usb_gadget *_gadget, int is_on)
+{
+ struct ci13xxx *ci = container_of(_gadget, struct ci13xxx, gadget);
+
+ if (is_on)
+ hw_write(ci, OP_USBCMD, USBCMD_RS, USBCMD_RS);
+ else
+ hw_write(ci, OP_USBCMD, USBCMD_RS, 0);
+
+ return 0;
+}
+
static int ci13xxx_start(struct usb_gadget *gadget,
struct usb_gadget_driver *driver);
static int ci13xxx_stop(struct usb_gadget *gadget,
@@ -1432,6 +1444,7 @@ static int ci13xxx_stop(struct usb_gadget *gadget,
static const struct usb_gadget_ops usb_gadget_ops = {
.vbus_session = ci13xxx_vbus_session,
.wakeup = ci13xxx_wakeup,
+ .pullup = ci13xxx_pullup,
.vbus_draw = ci13xxx_vbus_draw,
.udc_start = ci13xxx_start,
.udc_stop = ci13xxx_stop,
--
1.7.10.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
[PATCH 01/12] usb: chipidea: udc: fix setup of endpoint maxpacket size
From: Michael Grzeschik This patch changes the setup of the endpoint maxpacket size. All non control endpoints are initialized with an undefined ((unsigned short)~0) maxpacket size. The maxpacket size of Endpoint 0 will be kept at CTRL_PAYLOAD_MAX. Some gadget drivers check for the maxpacket size before they enable the endpoint, which leads to a wrong state in these drivers. Cc: Signed-off-by: Michael Grzeschik Acked-by: Felipe Balbi Signed-off-by: Marc Kleine-Budde Signed-off-by: Alexander Shishkin --- drivers/usb/chipidea/udc.c |8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c index c7a032a..7801a3f 100644 --- a/drivers/usb/chipidea/udc.c +++ b/drivers/usb/chipidea/udc.c @@ -1455,7 +1455,12 @@ static int init_eps(struct ci13xxx *ci) mEp->ep.name = mEp->name; mEp->ep.ops = &usb_ep_ops; - mEp->ep.maxpacket = CTRL_PAYLOAD_MAX; + /* +* for ep0: maxP defined in desc, for other +* eps, maxP is set by epautoconfig() called +* by gadget layer +*/ + mEp->ep.maxpacket = (unsigned short)~0; INIT_LIST_HEAD(&mEp->qh.queue); mEp->qh.ptr = dma_pool_alloc(ci->qh_pool, GFP_KERNEL, @@ -1475,6 +1480,7 @@ static int init_eps(struct ci13xxx *ci) else ci->ep0in = mEp; + mEp->ep.maxpacket = CTRL_PAYLOAD_MAX; continue; } -- 1.7.10.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
[PATCH 00/12] usb: chipidea updates for v3.7
Hi, This bunch of patches contains fixes in the core driver and updates for chipidea integrated in imx chips. Marc Kleine-Budde (2): usb: chipidea: udc: fix error path in udc_start() usb: chipidea: cleanup dma_pool if udc_start() fails Michael Grzeschik (3): usb: chipidea: udc: fix setup of endpoint maxpacket size usb: chipidea: udc: add pullup fuction, needed by the uvc gadget usb: chipidea: udc: don't stall endpoint if request list is empty in isr_tr_complete_low Richard Zhao (7): USB: chipidea: add imx usbmisc support USB: chipidea: imx: add pinctrl support USB: chipidea: delay 2ms before read ID status at probe time USB: chipidea: acknowledge ID change interrupt in irq handler USB: chipidea: add vbus detect for udc USB: chipidea: add -DDEBUG if debugging is enabled USB: chipidea: re-order irq handling to avoid unhandled irqs .../devicetree/bindings/usb/ci13xxx-imx.txt|5 + .../devicetree/bindings/usb/usbmisc-imx.txt| 14 ++ drivers/usb/chipidea/Makefile |4 +- drivers/usb/chipidea/ci.h |1 + drivers/usb/chipidea/ci13xxx_imx.c | 71 + drivers/usb/chipidea/ci13xxx_imx.h | 28 drivers/usb/chipidea/core.c| 24 +-- drivers/usb/chipidea/udc.c | 98 +--- drivers/usb/chipidea/usbmisc_imx6q.c | 162 9 files changed, 378 insertions(+), 29 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/usbmisc-imx.txt create mode 100644 drivers/usb/chipidea/ci13xxx_imx.h create mode 100644 drivers/usb/chipidea/usbmisc_imx6q.c -- 1.7.10.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: XHCI: URB not cancelled during disconnect of a MSC device
> > I am using v3.5 kernel and running a test where I disconnect > a SS MSC device while a big file is being written to it. I am > also watching the lsusb output in parallel. Expectation is > that SS MSC device should immediately disappear from lsusb > output but sometime I see that SS MSC is listed for 30 > seconds and then only disappears. Log is copied below. > > Looking further into the issue shows that in failing case an > URB is not given back by XHCI driver and so SCSI layer > unlinks it after 30second of timeout. This URB was actually > given to XHCI host controller and a disconnect happens while > packet transfer was in progress. I looked at XHCI driver and > could not find request being aborted by driver (in > xhci_free_dev() fn) before issuing disable slot or reset > device command. What is expectation in this scenario? Is it > XHCI driver responsibility to abort and giveback all the > request (as in EHCI using endpoint_disable()) OR host > controller hardware should abort and post an error completion > event for each request? Why XHCI driver doesn't have an > endpoint_disable() implemented as done for other controller? > I have faced similar scenario, check whether patch http://marc.info/?l=linux-usb&m=134382746009339&w=2could could help, Alan suggesting that hcd controller should release all URBs when device got disconnected. -RaviBabu > === Working case [ > 3406.676989] Port Status Change Event for port 2 [ > 3406.711530] get port status, actual port 1 status = 0x4202c0 > [ 3406.711531] Get port status returned 0x4102c0 [ > 3406.711629] clear port connect change, actual port 1 status > = 0x4002c0 [ 3406.711664] clear port link state change, > actual port 1 status = 0x2c0 [ 3406.721606] > [E.f2e0b980.Transfer error on endpoint <=== URB submitted > here but gets transfer error [ 3406.721742] Cleaning up > stalled endpoint ring [ 3406.721744] Finding segment > containing stopped TRB. > [ 3406.721746] Finding endpoint context > [ 3406.721747] Finding segment containing last TRB in TD. > [ 3406.721749] Cycle state = 0x1 > [ 3406.721750] New dequeue segment = f2073880 (virtual) [ > 3406.721752] New dequeue pointer = 0x337be380 (DMA) [ > 3406.721754] Queueing new dequeue state [ 3406.721756] Set TR > Deq Ptr cmd, new deq seg = f2073880 (0x337be000 dma), new deq > ptr = f37be380 (0x337be380 dma), new cycle = 1 [ > 3406.721758]// Ding dong! > [ 3406.721855] Giveback URB f2e0b980, len = 0, expected = 31, status = > -71 <=== URB given back by XHCI driver > = > > > === Non Working case [ > 2971.576389] Port Status Change Event for port 2 > [ 2971.576487] [E.f2d0c480. <=== URB submitted but no error. > [ 2971.585007] get port status, actual port 1 status = > 0x4202c0 [ 2971.585079] Get port status returned 0x4102c0 [ > 2971.585178] clear port connect change, actual port 1 status > = 0x4002c0 [ 2971.585213] clear port link state change, > actual port 1 status = 0x2c0 [ 2971.640030] get port status, > actual port 1 status = 0x2d1 [ 2971.640031] Get port status > returned 0x2d1 [ 2971.696029] get port status, actual port 1 > status = 0x2d1 [ 2971.696031] Get port status returned 0x2d1 > [ 2971.900031] get port status, actual port 1 status = 0x2d1 > [ 2971.900034] Get port status returned 0x2d1 [ 2972.060480] > Port Status Change Event for port 2 [ 2972.104039] get port > status, actual port 1 status = 0x2802a0 [ 2972.104041] Get > port status returned 0x3002a0 [ 2972.104079] clear port reset > change, actual port 1 status = 0x802a0 [ 2972.104108] clear > port warm(BH) reset change, actual port 1 status = 0x2a0 [ > 2972.104138] clear port link state change, actual port 1 > status = 0x2a0 [ 2972.104144] usb 6-2: USB disconnect, device number 6 > > <=== 30 seconds gap > > > [ 3002.080058] Cancel URB f2d0c480, dev 2, ep 0x81, starting at offset > 0x337ad060 <== SCSI layer cancelling URB after 30 seconds > [ 3002.080063]// Ding dong! > [ 2972.060569] Stopped on Transfer TRB > [ 3002.080817] Removing canceled TD starting at 0x337ad060 (dma). > [ 3002.080820] Finding segment containing stopped TRB. > [ 3002.080822] Finding endpoint context > [ 3002.080823] Finding segment containing last TRB in TD. > [ 3002.080825] Cycle state = 0x0 > [ 3002.080827] New dequeue segment = f71628f0 (virtual) [ > 3002.080828] New dequeue pointer = 0x337ad070 (DMA) [ > 3002.080831] Set TR Deq Ptr cmd, new deq seg = f71628f0 > (0x337ad000 dma), new deq ptr = f37ad070 (0x337ad070 dma), > new cycle = 0 > > = > > Thanks > Ajay > -- > 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 th
[PATCH] usb: move children deallocation after quiescing the hub
Commit ff823c79a5c33194c2e5594f7c4686ea3547910c ("usb: move children
to struct usb_port") forgot to consider the hub_disconnect sequence,
which releases ports before quiescing the hub, which will lead to a
use-after-free, since hub_quiesce() will try to disconnect ports'
children, which are already deallocated. Simple modprobe dummy_hcd &&
rmmod dummy_hcd will illustrate the problem.
This patch moves deallocation of hub's ports after hub_quiesce() call
in hub_disconnect().
Cc: Lan Tianyu
Signed-off-by: Alexander Shishkin
---
drivers/usb/core/hub.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index aa45e43..6dc41c6 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1584,9 +1584,6 @@ static void hub_disconnect(struct usb_interface *intf)
struct usb_device *hdev = interface_to_usbdev(intf);
int i;
- for (i = 0; i < hdev->maxchild; i++)
- usb_hub_remove_port_device(hub, i + 1);
-
/* Take the hub off the event list and don't let it be added again */
spin_lock_irq(&hub_event_lock);
if (!list_empty(&hub->event_list)) {
@@ -1601,6 +1598,9 @@ static void hub_disconnect(struct usb_interface *intf)
hub_quiesce(hub, HUB_DISCONNECT);
usb_set_intfdata (intf, NULL);
+
+ for (i = 0; i < hdev->maxchild; i++)
+ usb_hub_remove_port_device(hub, i + 1);
hub->hdev->maxchild = 0;
if (hub->hdev->speed == USB_SPEED_HIGH)
--
1.7.10.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] usb: gadget: fsl_udc_core: do not immediatly prime STATUS for IN xfer
> -Original Message- > From: Felipe Balbi [mailto:ba...@ti.com] > Sent: Thursday, September 06, 2012 10:28 PM > To: Enrico Scholz > Cc: ba...@ti.com; Chen Peter-B29397; linux-usb@vger.kernel.org; linuxppc- > d...@lists.ozlabs.org; Li Yang-R58472; gre...@linuxfoundation.org > Subject: Re: [PATCH] usb: gadget: fsl_udc_core: do not immediatly prime > STATUS for IN xfer > > Hi, > > On Thu, Sep 06, 2012 at 04:27:12PM +0200, Enrico Scholz wrote: > > Felipe Balbi writes: > > > > >> > Because the fsl_udc_core driver shares one 'status_req' object > > >> > for the complete ep0 control transfer, it is not possible to > > >> > prime the final STATUS phase immediately after the IN > > >> > transaction. E.g. ch9getstatus() > > >> > executed: > > >> > > > >> > | req = udc->status_req; > > >> > | ... > > >> > | list_add_tail(&req->queue, &ep->queue); if > > >> > | (ep0_prime_status(udc, EP_DIR_OUT)) > > >> > | > > >> > | struct fsl_req *req = udc->status_req; > > >> > | list_add_tail(&req->queue, &ep->queue); > > >> > > > >> > which corrupts the ep->queue list by inserting 'status_req' > > >> > twice. This causes a kernel oops e.g. when 'lsusb -v' is executed > on the host. > > >> > > > >> > Patch delays the final 'ep0_prime_status(udc, EP_DIR_OUT))' by > > >> > moving it into the ep0 completion handler. > > >> > > > >> Enrico, thanks for pointing this problem. > > >> > > >> As "prime STATUS phase immediately after the IN transaction" is > > >> followed USB 2.0 spec, to fix this problem, it is better to add > data_req for ep0. > > >> In fact, it is already at FSL i.mx internal code, just still not > mainlined. > > > > > > so, do I get an Acked-by to this patch ? Does it need to go on > > > v3.6-rc or can it wait until v3.7 merge window ? > > > > Without this (or the mentioned data_req patch), I can crash a g_multi > > gadget by executing 'lsusb -v' as root on the host. Should not be > > exploitable (only a BUG_ON() is triggered) but issue should be fixed > > asap. > > cool, so I'll apply to my fixes branch as soon as I get Acked-by or > Tested-by from someone. This seems to revert the error handling for USB2.0 spec 8.5.3.3. But the problem is a serious one to be fixed right away. So Acked-by: Li Yang We need to revisit the error handling issue later and find a proper way to address it. Regards, Leo -- 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: phy: re-organize tegra phy driver
Nvidia produces several Tegra SOCs viz Tegra2, Tegra3 etc.
In order to support USB phy drivers on these SOCs, existing
phy driver is split into SOC agnostic common USB phy driver and
tegra2 specific USB phy driver.
This will facilitate easy addition & deletion of phy drivers for
Tegra SOCs.
Signed-off-by: Venu Byravarasu
---
drivers/usb/host/ehci-tegra.c | 20 +-
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/tegra2_usb_phy.c | 561
drivers/usb/phy/tegra2_usb_phy.h | 175 +
drivers/usb/phy/tegra_usb_phy.c | 722 ++---
include/linux/usb/tegra_usb_phy.h | 34 ++-
6 files changed, 816 insertions(+), 697 deletions(-)
create mode 100644 drivers/usb/phy/tegra2_usb_phy.c
create mode 100644 drivers/usb/phy/tegra2_usb_phy.h
diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index 532db04..98d5e47 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -618,6 +618,9 @@ static int tegra_ehci_probe(struct platform_device *pdev)
int err = 0;
int irq;
int instance = pdev->id;
+ struct device_node *np = pdev->dev.of_node;
+ struct phy_params params;
+ int phy_type;
pdata = pdev->dev.platform_data;
if (!pdata) {
@@ -706,9 +709,22 @@ static int tegra_ehci_probe(struct platform_device *pdev)
}
}
+ phy_type = of_property_match_string(np, "phy_type", "utmi");
+ if (phy_type >= 0)
+ params.type = TEGRA_USB_PHY_TYPE_UTMI;
+ else {
+ phy_type = of_property_match_string(np, "phy_type", "ulpi");
+ if (phy_type >= 0)
+ params.type = TEGRA_USB_PHY_TYPE_ULPI;
+ else
+ params.type = TEGRA_USB_PHY_TYPE_INVALID;
+ }
+
+ params.mode = TEGRA_USB_PHY_MODE_HOST;
+ params.config = pdata->phy_config;
+
tegra->phy = tegra_usb_phy_open(&pdev->dev, instance, hcd->regs,
- pdata->phy_config,
- TEGRA_USB_PHY_MODE_HOST);
+ ¶ms);
if (IS_ERR(tegra->phy)) {
dev_err(&pdev->dev, "Failed to open USB phy\n");
err = -ENXIO;
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index bb948fb..45511e4 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -7,3 +7,4 @@ ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG
obj-$(CONFIG_USB_ISP1301) += isp1301.o
obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o
obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o
+obj-$(CONFIG_USB_EHCI_TEGRA) += tegra2_usb_phy.o
diff --git a/drivers/usb/phy/tegra2_usb_phy.c b/drivers/usb/phy/tegra2_usb_phy.c
new file mode 100644
index 000..629f146
--- /dev/null
+++ b/drivers/usb/phy/tegra2_usb_phy.c
@@ -0,0 +1,561 @@
+/*
+ * Copyright (C) 2010 Google, Inc.
+ * Copyright (c) 2012, NVIDIA CORPORATION. All rights reserved.
+ *
+ * Author:
+ * Erik Gilling
+ * Benoit Goby
+ * Venu Byravarasu
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "tegra2_usb_phy.h"
+
+static DEFINE_SPINLOCK(utmip_pad_lock);
+static int utmip_pad_count;
+
+static inline bool phy_is_ulpi(struct tegra_usb_phy *phy)
+{
+ return (phy->type == TEGRA_USB_PHY_TYPE_ULPI);
+}
+
+
+static int tegra2_utmip_pad_open(struct tegra_usb_phy *phy)
+{
+ phy->pad_clk = clk_get_sys("utmip-pad", NULL);
+ if (IS_ERR(phy->pad_clk)) {
+ pr_err("%s: can't get utmip pad clock\n", __func__);
+ return PTR_ERR(phy->pad_clk);
+ }
+
+ if (phy->instance == 0) {
+ phy->pad_regs = phy->regs;
+ } else {
+ phy->pad_regs = ioremap(TEGRA_USB_BASE, TEGRA_USB_SIZE);
+ if (!phy->pad_regs) {
+ pr_err("%s: can't remap usb registers\n", __func__);
+ clk_put(phy->pad_clk);
+ return -ENOMEM;
+ }
+ }
+ return 0;
+}
+
+static void tegra2_utmip_pad_close(struct tegra_usb_phy *phy)
+{
+ if (phy->instance != 0)
+ iounmap(phy->pad_regs);
+ clk_put(phy->pad_clk);
+}
+
+static void tegra2_utmip_pad_power_on(struct tegra_usb_phy *phy)
+{
+ unsigned long val, flags;
+ void __iomem *ba
Re: [PATCH v5 1/5] usb: phy: samsung: Introducing usb phy driver for hsotg
On 09/12/2012 12:45 PM, Praveen Paneri wrote: > This driver uses usb_phy interface to interact with s3c-hsotg. Supports > phy_init and phy_shutdown functions to enable/disable phy. Tested with > smdk6410 and smdkv310. More SoCs can be brought under later. > > Signed-off-by: Praveen Paneri > Acked-by: Heiko Stuebner > --- > .../devicetree/bindings/usb/samsung-usbphy.txt |9 + > drivers/usb/phy/Kconfig|8 + > drivers/usb/phy/Makefile |1 + > drivers/usb/phy/samsung-usbphy.c | 371 > > include/linux/platform_data/samsung-usbphy.h | 27 ++ > 5 files changed, 416 insertions(+), 0 deletions(-) > create mode 100644 Documentation/devicetree/bindings/usb/samsung-usbphy.txt > create mode 100644 drivers/usb/phy/samsung-usbphy.c > create mode 100644 include/linux/platform_data/samsung-usbphy.h > > diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt > b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt > new file mode 100644 > index 000..fefd9c8 > --- /dev/null > +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt > @@ -0,0 +1,9 @@ > +* Samsung's usb phy transceiver > + > +The Samsung's phy transceiver is used for controlling usb otg phy for > +s3c-hsotg usb device controller. > + > +Required properties: > +- compatible : should be "samsung,exynos4210-usbphy" > +- reg : base physical address of the phy registers and length of memory > mapped > + region. > diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig > index 63c339b..313685f 100644 > --- a/drivers/usb/phy/Kconfig > +++ b/drivers/usb/phy/Kconfig > @@ -32,3 +32,11 @@ config MV_U3D_PHY > help > Enable this to support Marvell USB 3.0 phy controller for Marvell > SoC. > + > +config SAMSUNG_USBPHY > + bool "Samsung USB PHY controller Driver" > + depends on USB_S3C_HSOTG > + select USB_OTG_UTILS > + help > + Enable this to support Samsung USB phy controller for samsung > + SoCs. > diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile > index b069f29..55dcfc1 100644 > --- a/drivers/usb/phy/Makefile > +++ b/drivers/usb/phy/Makefile > @@ -8,3 +8,4 @@ obj-$(CONFIG_OMAP_USB2) += omap-usb2.o > obj-$(CONFIG_USB_ISP1301)+= isp1301.o > obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o > obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o > +obj-$(CONFIG_SAMSUNG_USBPHY) += samsung-usbphy.o > diff --git a/drivers/usb/phy/samsung-usbphy.c > b/drivers/usb/phy/samsung-usbphy.c > new file mode 100644 > index 000..b00d01b > --- /dev/null > +++ b/drivers/usb/phy/samsung-usbphy.c > @@ -0,0 +1,371 @@ > +/* linux/drivers/usb/phy/samsung-usbphy.c > + * > + * Copyright (c) 2012 Samsung Electronics Co., Ltd. > + * http://www.samsung.com > + * > + * Author: Praveen Paneri > + * > + * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG controller > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* Register definitions */ > + > +#define S3C_PHYPWR (0x00) > + > +#define S3C_PHYPWR_NORMAL_MASK (0x19 << 0) > +#define S3C_PHYPWR_OTG_DISABLE (1 << 4) > +#define S3C_PHYPWR_ANALOG_POWERDOWN (1 << 3) > +#define S3C_PHYPWR_FORCE_SUSPEND (1 << 1) > +/* For Exynos4 */ > +#define EXYNOS4_PHYPWR_NORMAL_MASK (0x39 << 0) > +#define EXYNOS4_PHYPWR_SLEEP (1 << 5) > + > +#define S3C_PHYCLK (0x04) > + > +#define S3C_PHYCLK_MODE_SERIAL (1 << 6) > +#define S3C_PHYCLK_EXT_OSC (1 << 5) > +#define S3C_PHYCLK_COMMON_ON_N (1 << 4) > +#define S3C_PHYCLK_ID_PULL (1 << 2) > +#define S3C_PHYCLK_CLKSEL_MASK (0x3 << 0) > +#define S3C_PHYCLK_CLKSEL_SHIFT (0) > +#define S3C_PHYCLK_CLKSEL_48M(0x0 << 0) > +#define S3C_PHYCLK_CLKSEL_12M(0x2 << 0) > +#define S3C_PHYCLK_CLKSEL_24M(0x3 << 0) > + > +#define S3C_RSTCON (0x08) > + > +#define S3C_RSTCON_PHYCLK(1 << 2) > +#define S3C_RSTCON_HCLK (1 << 1) > +#define S3C_RSTCON_PHY (1 << 0) > + > +#ifnd
Re: usb3 writes fail with transcend rdf8 + ASMedia ASM1042 woes
On Sat, Aug 25, 2012 at 12:31:46 +0300, Sami Farin wrote: >... Did you get the email (360 kB), it did not show up at marc.info but I did not get delivery status notifications..? I uploaded the xhci debug log here: https://docs.google.com/open?id=0B_EMXtsx7o56eUw5dC10RDhTcmc these with git/torvalds/linux-2.6.git 2d809dcd88f590 I plugged rdf8 reader into usb3 port, mounted it (vfat), cat garbage > out.bin , at the end ls showed a bit over 25200 byte file, then empty dir listing (df showed input/output error). When mounted with rdf8 reader plugged into usb2 port the dir listing was intact, like it did not manage to write anything when in usb3.. -- Do what you love because life is too short for anything else. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] How to handle delays in isochronous transfers?
Jassi Brar wrote: > On Tue, Sep 11, 2012 at 11:46 PM, Clemens Ladisch wrote: >> When URB submission fails, the stream should be stopped. > > Since ISOCH transfers are not expected to be lossless (i.e, not > retried), perhaps we should simply lump all kinds of failures together > and ignore them and simply keep moving on? URB submission errors cannot be ignored -- when this happens, the USB stream _is_ already stopped; stopping the PCM device just informs the application about this. Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] How to handle delays in isochronous transfers?
On Tue, Sep 11, 2012 at 11:46 PM, Clemens Ladisch wrote: > Alan Stern wrote: >> I have tried some initial testing of my updates, using data-OUT >> transfers with URB_ISO_ASAP turned off for the data URBs in >> sound/usb/endpoint.c. When interrupts are delayed so long that >> synchronization is lost and a data URB submission fails, the sound >> stops playing and doesn't restart. But the synch URBs continue to be >> submitted and ogg123 doesn't end for quite some time. > > When URB submission fails, the stream should be stopped. In theory. > Since ISOCH transfers are not expected to be lossless (i.e, not retried), perhaps we should simply lump all kinds of failures together and ignore them and simply keep moving on? Stream stopping should only be done in response to standard USB state changes that warrant it (ex switching to AltSetting-0) ? -- 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 05/11] USB: chipidea: don't let probe fail if otg controller start one role failed
Richard Zhao writes:
> On Tue, Sep 11, 2012 at 10:23:55AM +0300, Alexander Shishkin wrote:
>> Richard Zhao writes:
>>
>> > On Wed, Aug 29, 2012 at 12:48:15PM +0300, Alexander Shishkin wrote:
>> >> Richard Zhao writes:
>> >>
>> >> > On Wed, Aug 29, 2012 at 11:10:33AM +0300, Alexander Shishkin wrote:
>> >> >> Richard Zhao writes:
>> >> >>
>> >> >> > On Tue, Aug 28, 2012 at 11:38:23AM +0300, Alexander Shishkin wrote:
>> >> >> >> Richard Zhao writes:
>> >> >> >>
>> >> >> >> > One role failed, but the other role will possiblly still work.
>> >> >> >> > For example, when udc start failed, if plug in a host device,
>> >> >> >> > it works.
>> >> >> >>
>> >> >> >> If you're a host device, ci->role should be HOST at this point and
>> >> >> >> ci_role_start() shouldn't fail. If ci->role is detected wrongly, the
>> >> >> >> role detection must be fixed. If ci_role_start() fails for host,
>> >> >> >> but it
>> >> >> >> still works when it's called again after the id pin change is
>> >> >> >> detected,
>> >> >> >> again, the problem is elsewhere.
>> >> >> > The check is only for OTG device. For single role device, it just
>> >> >> > fail
>> >> >> > if it start the role failed.
>> >> >>
>> >> >> Sorry, can you rephrase?
>> >> >>
>> >> >> >>
>> >> >> >> >
>> >> >> >> > Signed-off-by: Richard Zhao
>> >> >> >> > ---
>> >> >> >> > drivers/usb/chipidea/core.c |7 +--
>> >> >> >> > 1 file changed, 5 insertions(+), 2 deletions(-)
>> >> >> >> >
>> >> >> >> > diff --git a/drivers/usb/chipidea/core.c
>> >> >> >> > b/drivers/usb/chipidea/core.c
>> >> >> >> > index 19ef324..8fd390a 100644
>> >> >> >> > --- a/drivers/usb/chipidea/core.c
>> >> >> >> > +++ b/drivers/usb/chipidea/core.c
>> >> >> >> > @@ -473,8 +473,11 @@ static int __devinit ci_hdrc_probe(struct
>> >> >> >> > platform_device *pdev)
>> >> >> >> > ret = ci_role_start(ci, ci->role);
>> >> >> >> > if (ret) {
>> >> >> >> > dev_err(dev, "can't start %s role\n",
>> >> >> >> > ci_role(ci)->name);
>> >> >> >> > - ret = -ENODEV;
>> >> >> >> > - goto rm_wq;
>> >> >> >> > + ci->role = CI_ROLE_END;
>> >> >> >>
>> >> >> >> So are you relying on id pin interrupt for initializing the role
>> >> >> >> after
>> >> >> >> this? Can you provide more details?
>> >> >> > Yes. The ID pin detect still works. My case is, gadget role failed,
>> >> >> > host role works. I was trying not to ruin host function.
>> >> >>
>> >> >> But it shouldn't even try to start the gadget, because ci_otg_role()
>> >> >> should set ci->role to HOST before ci_role_start() happens.
>> >> > It depends on ID pin. If ID pin is gadget and gadget is not support
>> >> > well,
>> >> > ci_role_start will fail. See below example.
>> >> >>
>> >> >> Another question is, why does gadget start fail?
>> >> > There's one example:
>> >> > If usb phy don't support otg yet, otg_set_peripheral will fail, and
>> >> > then cause udc_start fail.
>> >>
>> >> So you should drop the CI13XXX_REQUIRE_TRANSCEIVER flag from imx
>> >> platform data till the phy is fully implemented.
>> > It's just an example. We can not assume udc_start always success. If it
>> > fails, isn't it better to continue support of host than say game over?
>>
>> Ok, I think what we need here is to rework error handling around role
>> switching, so that we can allow certain things to fail and retry at a
>> later point (say at id pin change), while being careful about the other
>> failures.
>>
>> If this patch is not crucial for imx right now, I'd prefer to leave it
>> out.
> That's OK. but I hope other function related patch can be merged for
> 3.7 :)
Also 6/11 seems quite pointless to me. Otherwise, I'll send them to Greg
today.
Regards,
--
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 06/11] USB: mxs-phy: add basic otg support
Hi,
On Tue, Aug 28, 2012 at 03:03:12PM +0800, Richard Zhao wrote:
> +static int mxs_phy_set_host(struct usb_otg *otg, struct usb_bus *host)
> +{
Shouldn't you at least save the host pointer?
otg->host = host;
> + return 0;
> +}
> +
> +static int mxs_phy_set_peripheral(struct usb_otg *otg,
> + struct usb_gadget *gadget)
> +{
And the same with the gadget?
> + return 0;
> +}
--
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 v4] usb: phy: add R-Car USB phy driver
Hello. On 12-09-2012 10:55, Simon Horman wrote: below is an incremental patch to add some workarounds that were made available to me. I wonder if you have some documentation available to replace the hex values with #defines? From: Kouei Abe arm: mach-rcar: Add USB-PHY workaround Signed-off-by: Kouei Abe Signed-off-by: Simon Horman [...] diff --git a/drivers/usb/phy/rcar-phy.c b/drivers/usb/phy/rcar-phy.c index 3fce889..5bf1634 100644 --- a/drivers/usb/phy/rcar-phy.c +++ b/drivers/usb/phy/rcar-phy.c @@ -86,6 +86,15 @@ static int rcar_usb_phy_init(struct usb_phy *phy) /* (2) start USB-PHY internal PLL */ iowrite32(PHY_ENB | PLL_ENB, (reg0 + USBPCTRL1)); + /* work around of USB-PHY */ +#ifdef CONFIG_USB_PHY_MARZEN_010S + writel(0x10700040, (reg0 + 0x0850)); + writel(0x7700, (reg0 + 0x085C)); +#elif CONFIG_USB_PHY_MARZEN_110S Shouldn't it be: #elif defined(CONFIG_USB_PHY_MARZEN_110S) WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 5/5] ARM: Exynos4210: Enabling samsung-usbphy driver
Adding usbphy node for Exynos4210 along with the platform data.
Signed-off-by: Praveen Paneri
---
arch/arm/boot/dts/exynos4210.dtsi |5 +
arch/arm/mach-exynos/include/mach/map.h |1 +
arch/arm/mach-exynos/mach-exynos4-dt.c |8
arch/arm/mach-exynos/setup-usb-phy.c| 13 +
4 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index 02891fe..e28cf10 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -62,6 +62,11 @@
interrupts = <0 44 0>, <0 45 0>;
};
+ usbphy@125B {
+ compatible = "samsung,exynos4210-usbphy";
+ reg = <0x125B 0x100>;
+ };
+
keypad@100A {
compatible = "samsung,s5pv210-keypad";
reg = <0x100A 0x100>;
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index c72b675..0625c0a 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -234,6 +234,7 @@
#define S3C_PA_SPI1EXYNOS4_PA_SPI1
#define S3C_PA_SPI2EXYNOS4_PA_SPI2
#define S3C_PA_USB_HSOTG EXYNOS4_PA_HSOTG
+#define S3C_PA_USB_PHY EXYNOS4_PA_HSPHY
#define S5P_PA_EHCIEXYNOS4_PA_EHCI
#define S5P_PA_FIMC0 EXYNOS4_PA_FIMC0
diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c
b/arch/arm/mach-exynos/mach-exynos4-dt.c
index b2b5d5f..0739be8 100644
--- a/arch/arm/mach-exynos/mach-exynos4-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
@@ -13,6 +13,7 @@
#include
#include
+#include
#include
#include
@@ -20,9 +21,14 @@
#include
#include
+#include
#include "common.h"
+static struct samsung_usbphy_data exynos4_usbphy_pdata = {
+ .pmu_isolation = s5p_usb_phy_pmu_isolation,
+};
+
/*
* The following lookup table is used to override device names when devices
* are registered from device tree. This is temporarily added to enable
@@ -63,6 +69,8 @@ static const struct of_dev_auxdata
exynos4210_auxdata_lookup[] __initconst = {
"exynos4210-spi.2", NULL),
OF_DEV_AUXDATA("arm,pl330", EXYNOS4_PA_PDMA0, "dma-pl330.0", NULL),
OF_DEV_AUXDATA("arm,pl330", EXYNOS4_PA_PDMA1, "dma-pl330.1", NULL),
+ OF_DEV_AUXDATA("samsung,exynos4210-usbphy", EXYNOS4_PA_HSPHY,
+ "s3c-usbphy", &exynos4_usbphy_pdata),
{},
};
diff --git a/arch/arm/mach-exynos/setup-usb-phy.c
b/arch/arm/mach-exynos/setup-usb-phy.c
index b81cc56..1c62d20 100644
--- a/arch/arm/mach-exynos/setup-usb-phy.c
+++ b/arch/arm/mach-exynos/setup-usb-phy.c
@@ -221,3 +221,16 @@ int s5p_usb_phy_exit(struct platform_device *pdev, int
type)
return -EINVAL;
}
+
+void s5p_usb_phy_pmu_isolation(int on)
+{
+ if (on) {
+ writel(readl(S5P_USBDEVICE_PHY_CONTROL)
+ & ~S5P_USBDEVICE_PHY_ENABLE,
+ S5P_USBDEVICE_PHY_CONTROL);
+ } else {
+ writel(readl(S5P_USBDEVICE_PHY_CONTROL)
+ | S5P_USBDEVICE_PHY_ENABLE,
+ S5P_USBDEVICE_PHY_CONTROL);
+ }
+}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 4/5] ARM: S3C64XX: Enabling samsung-usbphy driver
Adding platform device for samsung-usbphy driver. Enabling it for
s3c64xx based machines using s3c-hsotg.
Signed-off-by: Praveen Paneri
---
arch/arm/mach-s3c64xx/include/mach/map.h |2 +
arch/arm/mach-s3c64xx/mach-crag6410.c|7 ++
arch/arm/mach-s3c64xx/mach-smartq.c |8 +++
arch/arm/mach-s3c64xx/mach-smdk6410.c|7 ++
arch/arm/mach-s3c64xx/setup-usb-phy.c| 14 +
arch/arm/plat-samsung/devs.c | 28 ++
arch/arm/plat-samsung/include/plat/devs.h|1 +
arch/arm/plat-samsung/include/plat/usb-phy.h |1 +
8 files changed, 68 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/include/mach/map.h
b/arch/arm/mach-s3c64xx/include/mach/map.h
index 8e2097b..dc482bb 100644
--- a/arch/arm/mach-s3c64xx/include/mach/map.h
+++ b/arch/arm/mach-s3c64xx/include/mach/map.h
@@ -65,6 +65,7 @@
#define S3C64XX_PA_NAND(0x7020)
#define S3C64XX_PA_FB (0x7710)
+#define S3C64XX_PA_USB_HSPHY (0x7C10)
#define S3C64XX_PA_USB_HSOTG (0x7C00)
#define S3C64XX_PA_WATCHDOG(0x7E004000)
#define S3C64XX_PA_RTC (0x7E005000)
@@ -113,6 +114,7 @@
#define S3C_PA_FB S3C64XX_PA_FB
#define S3C_PA_USBHOST S3C64XX_PA_USBHOST
#define S3C_PA_USB_HSOTG S3C64XX_PA_USB_HSOTG
+#define S3C_PA_USB_PHY S3C64XX_PA_USB_HSPHY
#define S3C_PA_RTC S3C64XX_PA_RTC
#define S3C_PA_WDT S3C64XX_PA_WATCHDOG
#define S3C_PA_SPI0S3C64XX_PA_SPI0
diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c
b/arch/arm/mach-s3c64xx/mach-crag6410.c
index b0f5baf..adc2e15 100644
--- a/arch/arm/mach-s3c64xx/mach-crag6410.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
@@ -31,6 +31,7 @@
#include
#include
+#include
#include
@@ -69,6 +70,7 @@
#include
#include
#include
+#include
#include "common.h"
@@ -336,6 +338,7 @@ static struct platform_device wallvdd_device = {
};
static struct platform_device *crag6410_devices[] __initdata = {
+ &samsung_device_usbphy,
&s3c_device_hsmmc0,
&s3c_device_hsmmc2,
&s3c_device_i2c0,
@@ -765,6 +768,9 @@ static const struct gpio_led_platform_data gpio_leds_pdata
= {
.num_leds = ARRAY_SIZE(gpio_leds),
};
+static struct samsung_usbphy_data crag6410_usbphy_pdata __initdata = {
+ .pmu_isolation = s5p_usb_phy_pmu_isolation,
+};
static void __init crag6410_machine_init(void)
{
@@ -790,6 +796,7 @@ static void __init crag6410_machine_init(void)
s3c_i2c0_set_platdata(&i2c0_pdata);
s3c_i2c1_set_platdata(&i2c1_pdata);
s3c_fb_set_platdata(&crag6410_lcd_pdata);
+ samsung_usbphy_set_pdata(&crag6410_usbphy_pdata);
i2c_register_board_info(0, i2c_devs0, ARRAY_SIZE(i2c_devs0));
i2c_register_board_info(1, i2c_devs1, ARRAY_SIZE(i2c_devs1));
diff --git a/arch/arm/mach-s3c64xx/mach-smartq.c
b/arch/arm/mach-s3c64xx/mach-smartq.c
index 7400da1..90dc821 100644
--- a/arch/arm/mach-s3c64xx/mach-smartq.c
+++ b/arch/arm/mach-s3c64xx/mach-smartq.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
@@ -36,6 +37,7 @@
#include
#include
#include
+#include
#include
@@ -234,6 +236,7 @@ static struct i2c_board_info smartq_i2c_devs[] __initdata =
{
};
static struct platform_device *smartq_devices[] __initdata = {
+ &samsung_device_usbphy,
&s3c_device_hsmmc1, /* Init iNAND first, ... */
&s3c_device_hsmmc0, /* ... then the external SD card */
&s3c_device_hsmmc2,
@@ -380,9 +383,14 @@ void __init smartq_map_io(void)
smartq_lcd_mode_set();
}
+static struct samsung_usbphy_data smartq_usbphy_pdata __initdata = {
+ .pmu_isolation = s5p_usb_phy_pmu_isolation,
+};
+
void __init smartq_machine_init(void)
{
s3c_i2c0_set_platdata(NULL);
+ samsung_usbphy_set_pdata(&smartq_usbphy_pdata);
s3c_hwmon_set_platdata(&smartq_hwmon_pdata);
s3c_sdhci1_set_platdata(&smartq_internal_hsmmc_pdata);
s3c_sdhci2_set_platdata(&smartq_internal_hsmmc_pdata);
diff --git a/arch/arm/mach-s3c64xx/mach-smdk6410.c
b/arch/arm/mach-s3c64xx/mach-smdk6410.c
index cbdc91b..4cf1252 100644
--- a/arch/arm/mach-s3c64xx/mach-smdk6410.c
+++ b/arch/arm/mach-s3c64xx/mach-smdk6410.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_SMDK6410_WM1190_EV1
#include
@@ -72,6 +73,7 @@
#include
#include
#include
+#include
#include "common.h"
@@ -263,6 +265,7 @@ static struct samsung_keypad_platdata smdk6410_keypad_data
__initdata = {
static struct map_desc smdk6410_iodesc[] = {};
static struct platform_device *smdk6410_devices[] __initdata = {
+ &samsung_device_usbphy,
#ifdef CONFIG_SMDK6410_SD_CH0
&s3c_device_hsmmc0,
#endif
@@ -626,6 +629,9 @@ static struct platform_pwm_backlight_data smdk6410_bl_data
= {
.pwm_id = 1,
};
+static struct sam
[PATCH v5 3/5] ARM: S3C64XX: Removing old phy setup code
This patch removes old phy code from platform side. 'setup-usb-phy.c'
will be used for providing transceiver platform data in next
patch. Not all of the platform data code is removed as there are others
making use of platform_data defined for hsotg. That can be removed once
all the SoCs start using the new transceiver for usb phy setup.
Signed-off-by: Praveen Paneri
---
arch/arm/mach-s3c64xx/mach-crag6410.c |3 -
arch/arm/mach-s3c64xx/mach-smartq.c |3 -
arch/arm/mach-s3c64xx/mach-smdk6410.c |3 -
arch/arm/mach-s3c64xx/setup-usb-phy.c | 79 -
4 files changed, 0 insertions(+), 88 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c
b/arch/arm/mach-s3c64xx/mach-crag6410.c
index 09cd812..b0f5baf 100644
--- a/arch/arm/mach-s3c64xx/mach-crag6410.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
@@ -31,7 +31,6 @@
#include
#include
-#include
#include
@@ -766,7 +765,6 @@ static const struct gpio_led_platform_data gpio_leds_pdata
= {
.num_leds = ARRAY_SIZE(gpio_leds),
};
-static struct s3c_hsotg_plat crag6410_hsotg_pdata;
static void __init crag6410_machine_init(void)
{
@@ -792,7 +790,6 @@ static void __init crag6410_machine_init(void)
s3c_i2c0_set_platdata(&i2c0_pdata);
s3c_i2c1_set_platdata(&i2c1_pdata);
s3c_fb_set_platdata(&crag6410_lcd_pdata);
- s3c_hsotg_set_platdata(&crag6410_hsotg_pdata);
i2c_register_board_info(0, i2c_devs0, ARRAY_SIZE(i2c_devs0));
i2c_register_board_info(1, i2c_devs1, ARRAY_SIZE(i2c_devs1));
diff --git a/arch/arm/mach-s3c64xx/mach-smartq.c
b/arch/arm/mach-s3c64xx/mach-smartq.c
index ceeb1de..7400da1 100644
--- a/arch/arm/mach-s3c64xx/mach-smartq.c
+++ b/arch/arm/mach-s3c64xx/mach-smartq.c
@@ -18,7 +18,6 @@
#include
#include
#include
-#include
#include
#include
@@ -187,7 +186,6 @@ static struct s3c_hwmon_pdata smartq_hwmon_pdata __initdata
= {
},
};
-static struct s3c_hsotg_plat smartq_hsotg_pdata;
static int __init smartq_lcd_setup_gpio(void)
{
@@ -385,7 +383,6 @@ void __init smartq_map_io(void)
void __init smartq_machine_init(void)
{
s3c_i2c0_set_platdata(NULL);
- s3c_hsotg_set_platdata(&smartq_hsotg_pdata);
s3c_hwmon_set_platdata(&smartq_hwmon_pdata);
s3c_sdhci1_set_platdata(&smartq_internal_hsmmc_pdata);
s3c_sdhci2_set_platdata(&smartq_internal_hsmmc_pdata);
diff --git a/arch/arm/mach-s3c64xx/mach-smdk6410.c
b/arch/arm/mach-s3c64xx/mach-smdk6410.c
index 0fe4f15..cbdc91b 100644
--- a/arch/arm/mach-s3c64xx/mach-smdk6410.c
+++ b/arch/arm/mach-s3c64xx/mach-smdk6410.c
@@ -30,7 +30,6 @@
#include
#include
#include
-#include
#ifdef CONFIG_SMDK6410_WM1190_EV1
#include
@@ -627,7 +626,6 @@ static struct platform_pwm_backlight_data smdk6410_bl_data
= {
.pwm_id = 1,
};
-static struct s3c_hsotg_plat smdk6410_hsotg_pdata;
static void __init smdk6410_map_io(void)
{
@@ -657,7 +655,6 @@ static void __init smdk6410_machine_init(void)
s3c_i2c0_set_platdata(NULL);
s3c_i2c1_set_platdata(NULL);
s3c_fb_set_platdata(&smdk6410_lcd_pdata);
- s3c_hsotg_set_platdata(&smdk6410_hsotg_pdata);
samsung_keypad_set_platdata(&smdk6410_keypad_data);
diff --git a/arch/arm/mach-s3c64xx/setup-usb-phy.c
b/arch/arm/mach-s3c64xx/setup-usb-phy.c
index f6757e0..7a09553 100644
--- a/arch/arm/mach-s3c64xx/setup-usb-phy.c
+++ b/arch/arm/mach-s3c64xx/setup-usb-phy.c
@@ -9,82 +9,3 @@
*
*/
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-static int s3c_usb_otgphy_init(struct platform_device *pdev)
-{
- struct clk *xusbxti;
- u32 phyclk;
-
- writel(readl(S3C64XX_OTHERS) | S3C64XX_OTHERS_USBMASK, S3C64XX_OTHERS);
-
- /* set clock frequency for PLL */
- phyclk = readl(S3C_PHYCLK) & ~S3C_PHYCLK_CLKSEL_MASK;
-
- xusbxti = clk_get(&pdev->dev, "xusbxti");
- if (xusbxti && !IS_ERR(xusbxti)) {
- switch (clk_get_rate(xusbxti)) {
- case 12 * MHZ:
- phyclk |= S3C_PHYCLK_CLKSEL_12M;
- break;
- case 24 * MHZ:
- phyclk |= S3C_PHYCLK_CLKSEL_24M;
- break;
- default:
- case 48 * MHZ:
- /* default reference clock */
- break;
- }
- clk_put(xusbxti);
- }
-
- /* TODO: select external clock/oscillator */
- writel(phyclk | S3C_PHYCLK_CLK_FORCE, S3C_PHYCLK);
-
- /* set to normal OTG PHY */
- writel((readl(S3C_PHYPWR) & ~S3C_PHYPWR_NORMAL_MASK), S3C_PHYPWR);
- mdelay(1);
-
- /* reset OTG PHY and Link */
- writel(S3C_RSTCON_PHY | S3C_RSTCON_HCLK | S3C_RSTCON_PHYCLK,
- S3C_RSTCON);
- udelay(20); /* at-least 10uS */
- writel(0, S3C_RSTCON);
-
- return 0;
-}
-
-static
[PATCH v5 2/5] usb: s3c-hsotg: Adding phy driver support
Adding the transceiver to hsotg driver. Keeping the platform data
for continuing the smooth operation for boards which still uses it
Signed-off-by: Praveen Paneri
---
drivers/usb/gadget/s3c-hsotg.c | 37 +++--
1 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index 6f696ee..29815b9 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -32,6 +32,7 @@
#include
#include
+#include
#include
#include
@@ -133,7 +134,9 @@ struct s3c_hsotg_ep {
* struct s3c_hsotg - driver state.
* @dev: The parent device supplied to the probe function
* @driver: USB gadget driver
- * @plat: The platform specific configuration data.
+ * @phy: The otg phy transceiver structure for phy control.
+ * @plat: The platform specific configuration data. This can be removed once
+ * all SoCs support usb transceiver.
* @regs: The memory area mapped for accessing registers.
* @irq: The IRQ number we are using
* @supplies: Definition of USB power supplies
@@ -153,6 +156,7 @@ struct s3c_hsotg_ep {
struct s3c_hsotg {
struct device*dev;
struct usb_gadget_driver *driver;
+ struct usb_phy *phy;
struct s3c_hsotg_plat*plat;
spinlock_t lock;
@@ -2854,7 +2858,10 @@ static void s3c_hsotg_phy_enable(struct s3c_hsotg *hsotg)
struct platform_device *pdev = to_platform_device(hsotg->dev);
dev_dbg(hsotg->dev, "pdev 0x%p\n", pdev);
- if (hsotg->plat->phy_init)
+
+ if (hsotg->phy)
+ usb_phy_init(hsotg->phy);
+ else if (hsotg->plat->phy_init)
hsotg->plat->phy_init(pdev, hsotg->plat->phy_type);
}
@@ -2869,7 +2876,9 @@ static void s3c_hsotg_phy_disable(struct s3c_hsotg *hsotg)
{
struct platform_device *pdev = to_platform_device(hsotg->dev);
- if (hsotg->plat->phy_exit)
+ if (hsotg->phy)
+ usb_phy_shutdown(hsotg->phy);
+ else if (hsotg->plat->phy_exit)
hsotg->plat->phy_exit(pdev, hsotg->plat->phy_type);
}
@@ -3493,6 +3502,7 @@ static void s3c_hsotg_release(struct device *dev)
static int __devinit s3c_hsotg_probe(struct platform_device *pdev)
{
struct s3c_hsotg_plat *plat = pdev->dev.platform_data;
+ struct usb_phy *phy;
struct device *dev = &pdev->dev;
struct s3c_hsotg_ep *eps;
struct s3c_hsotg *hsotg;
@@ -3501,20 +3511,27 @@ static int __devinit s3c_hsotg_probe(struct
platform_device *pdev)
int ret;
int i;
- plat = pdev->dev.platform_data;
- if (!plat) {
- dev_err(&pdev->dev, "no platform data defined\n");
- return -EINVAL;
- }
-
hsotg = devm_kzalloc(&pdev->dev, sizeof(struct s3c_hsotg), GFP_KERNEL);
if (!hsotg) {
dev_err(dev, "cannot get memory\n");
return -ENOMEM;
}
+ plat = pdev->dev.platform_data;
+ if (!plat) {
+ /* Fallback for transceiver */
+ phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
+ if (IS_ERR_OR_NULL(phy)) {
+ dev_err(&pdev->dev, "no platform data or transceiver
defined\n");
+ return -EPROBE_DEFER;
+ } else {
+ hsotg->phy = phy;
+ }
+ } else {
+ hsotg->plat = plat;
+ }
+
hsotg->dev = dev;
- hsotg->plat = plat;
hsotg->clk = devm_clk_get(&pdev->dev, "otg");
if (IS_ERR(hsotg->clk)) {
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/5] usb: phy: samsung: Introducing usb phy driver for hsotg
This driver uses usb_phy interface to interact with s3c-hsotg. Supports
phy_init and phy_shutdown functions to enable/disable phy. Tested with
smdk6410 and smdkv310. More SoCs can be brought under later.
Signed-off-by: Praveen Paneri
Acked-by: Heiko Stuebner
---
.../devicetree/bindings/usb/samsung-usbphy.txt |9 +
drivers/usb/phy/Kconfig|8 +
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/samsung-usbphy.c | 371
include/linux/platform_data/samsung-usbphy.h | 27 ++
5 files changed, 416 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/samsung-usbphy.txt
create mode 100644 drivers/usb/phy/samsung-usbphy.c
create mode 100644 include/linux/platform_data/samsung-usbphy.h
diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
new file mode 100644
index 000..fefd9c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
@@ -0,0 +1,9 @@
+* Samsung's usb phy transceiver
+
+The Samsung's phy transceiver is used for controlling usb otg phy for
+s3c-hsotg usb device controller.
+
+Required properties:
+- compatible : should be "samsung,exynos4210-usbphy"
+- reg : base physical address of the phy registers and length of memory mapped
+ region.
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 63c339b..313685f 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -32,3 +32,11 @@ config MV_U3D_PHY
help
Enable this to support Marvell USB 3.0 phy controller for Marvell
SoC.
+
+config SAMSUNG_USBPHY
+ bool "Samsung USB PHY controller Driver"
+ depends on USB_S3C_HSOTG
+ select USB_OTG_UTILS
+ help
+ Enable this to support Samsung USB phy controller for samsung
+ SoCs.
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index b069f29..55dcfc1 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_OMAP_USB2) += omap-usb2.o
obj-$(CONFIG_USB_ISP1301) += isp1301.o
obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o
obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o
+obj-$(CONFIG_SAMSUNG_USBPHY) += samsung-usbphy.o
diff --git a/drivers/usb/phy/samsung-usbphy.c b/drivers/usb/phy/samsung-usbphy.c
new file mode 100644
index 000..b00d01b
--- /dev/null
+++ b/drivers/usb/phy/samsung-usbphy.c
@@ -0,0 +1,371 @@
+/* linux/drivers/usb/phy/samsung-usbphy.c
+ *
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Author: Praveen Paneri
+ *
+ * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG controller
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Register definitions */
+
+#define S3C_PHYPWR (0x00)
+
+#define S3C_PHYPWR_NORMAL_MASK (0x19 << 0)
+#define S3C_PHYPWR_OTG_DISABLE (1 << 4)
+#define S3C_PHYPWR_ANALOG_POWERDOWN(1 << 3)
+#define S3C_PHYPWR_FORCE_SUSPEND (1 << 1)
+/* For Exynos4 */
+#define EXYNOS4_PHYPWR_NORMAL_MASK (0x39 << 0)
+#define EXYNOS4_PHYPWR_SLEEP (1 << 5)
+
+#define S3C_PHYCLK (0x04)
+
+#define S3C_PHYCLK_MODE_SERIAL (1 << 6)
+#define S3C_PHYCLK_EXT_OSC (1 << 5)
+#define S3C_PHYCLK_COMMON_ON_N (1 << 4)
+#define S3C_PHYCLK_ID_PULL (1 << 2)
+#define S3C_PHYCLK_CLKSEL_MASK (0x3 << 0)
+#define S3C_PHYCLK_CLKSEL_SHIFT(0)
+#define S3C_PHYCLK_CLKSEL_48M (0x0 << 0)
+#define S3C_PHYCLK_CLKSEL_12M (0x2 << 0)
+#define S3C_PHYCLK_CLKSEL_24M (0x3 << 0)
+
+#define S3C_RSTCON (0x08)
+
+#define S3C_RSTCON_PHYCLK (1 << 2)
+#define S3C_RSTCON_HCLK(1 << 1)
+#define S3C_RSTCON_PHY (1 << 0)
+
+#ifndef MHZ
+#define MHZ (1000*1000)
+#endif
+
+enum samsung_cpu_type {
+ TYPE_S3C64XX,
+ TYPE_EXYNOS4210,
+};
+
+/*
+ * struct samsung_usbphy - transceiver driver state
+ * @phy: transceiver structure
+ * @plat: platform data
+ * @dev: The parent device supplied to the probe function
+ * @clk: usb phy
[PATCH v5 0/5] usb: phy: samsung: Introducing usb phy driver for samsung SoCs
Changes from v4: Moved header file contents to driver's source file Removed unnecessary print message from driver's probe function Dropped the Free Software Foundation address from the header Changed the platform data code to use __initdata Changes from v3: Replaced susbsys_initcall()/module_exit() by module_platform_driver(). Accordingly in the hsotg driver returned -EPROBE_DEFER until phy driver is registered Removed unnecessary devm_usb_put_phy() call from the hsotg driver remove. Changes from v2: Changed the driver filenames to samsung-usbphy Changed 's3c' to 'samsung' for platform device as well as platform data Moved platform data structure to a separate file Rectified coding style related errors Changes from v1: Rebased patches to latest usb-next branch Changed the name 'sec_usbphy' to 'samsung_usbphy' This patch set introduces a phy driver for samsung SoCs. It uses the existing transceiver infrastructure to provide phy control functions. Use of this driver can be extended for usb host phy as well. Over the period of time all the phy related code for most of the samsung SoCs can be integrated here. Removing the existing phy code from mach-s3c64xx. Same can be done for other SoCs when they start supporting this phy driver. This driver is tested with smdk6410 and Exynos4210(with DT). Praveen Paneri (5): usb: phy: samsung: Introducing usb phy driver for hsotg usb: s3c-hsotg: Adding phy driver support ARM: S3C64XX: Removing old phy setup code ARM: S3C64XX: Enabling samsung-usbphy driver ARM: Exynos4210: Enabling samsung-usbphy driver .../devicetree/bindings/usb/samsung-usbphy.txt |9 + arch/arm/boot/dts/exynos4210.dtsi |5 + arch/arm/mach-exynos/include/mach/map.h|1 + arch/arm/mach-exynos/mach-exynos4-dt.c |8 + arch/arm/mach-exynos/setup-usb-phy.c | 13 + arch/arm/mach-s3c64xx/include/mach/map.h |2 + arch/arm/mach-s3c64xx/mach-crag6410.c | 10 +- arch/arm/mach-s3c64xx/mach-smartq.c| 11 +- arch/arm/mach-s3c64xx/mach-smdk6410.c | 10 +- arch/arm/mach-s3c64xx/setup-usb-phy.c | 79 + arch/arm/plat-samsung/devs.c | 28 ++ arch/arm/plat-samsung/include/plat/devs.h |1 + arch/arm/plat-samsung/include/plat/usb-phy.h |1 + drivers/usb/gadget/s3c-hsotg.c | 37 ++- drivers/usb/phy/Kconfig|8 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/samsung-usbphy.c | 371 include/linux/platform_data/samsung-usbphy.h | 27 ++ 18 files changed, 531 insertions(+), 91 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/samsung-usbphy.txt create mode 100644 drivers/usb/phy/samsung-usbphy.c create mode 100644 include/linux/platform_data/samsung-usbphy.h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
XHCI: URB not cancelled during disconnect of a MSC device
Hi, I am using v3.5 kernel and running a test where I disconnect a SS MSC device while a big file is being written to it. I am also watching the lsusb output in parallel. Expectation is that SS MSC device should immediately disappear from lsusb output but sometime I see that SS MSC is listed for 30 seconds and then only disappears. Log is copied below. Looking further into the issue shows that in failing case an URB is not given back by XHCI driver and so SCSI layer unlinks it after 30second of timeout. This URB was actually given to XHCI host controller and a disconnect happens while packet transfer was in progress. I looked at XHCI driver and could not find request being aborted by driver (in xhci_free_dev() fn) before issuing disable slot or reset device command. What is expectation in this scenario? Is it XHCI driver responsibility to abort and giveback all the request (as in EHCI using endpoint_disable()) OR host controller hardware should abort and post an error completion event for each request? Why XHCI driver doesn't have an endpoint_disable() implemented as done for other controller? === Working case [ 3406.676989] Port Status Change Event for port 2 [ 3406.711530] get port status, actual port 1 status = 0x4202c0 [ 3406.711531] Get port status returned 0x4102c0 [ 3406.711629] clear port connect change, actual port 1 status = 0x4002c0 [ 3406.711664] clear port link state change, actual port 1 status = 0x2c0 [ 3406.721606] [E.f2e0b980.Transfer error on endpoint <=== URB submitted here but gets transfer error [ 3406.721742] Cleaning up stalled endpoint ring [ 3406.721744] Finding segment containing stopped TRB. [ 3406.721746] Finding endpoint context [ 3406.721747] Finding segment containing last TRB in TD. [ 3406.721749] Cycle state = 0x1 [ 3406.721750] New dequeue segment = f2073880 (virtual) [ 3406.721752] New dequeue pointer = 0x337be380 (DMA) [ 3406.721754] Queueing new dequeue state [ 3406.721756] Set TR Deq Ptr cmd, new deq seg = f2073880 (0x337be000 dma), new deq ptr = f37be380 (0x337be380 dma), new cycle = 1 [ 3406.721758]// Ding dong! [ 3406.721855] Giveback URB f2e0b980, len = 0, expected = 31, status = -71 <=== URB given back by XHCI driver = === Non Working case [ 2971.576389] Port Status Change Event for port 2 [ 2971.576487] [E.f2d0c480. <=== URB submitted but no error. [ 2971.585007] get port status, actual port 1 status = 0x4202c0 [ 2971.585079] Get port status returned 0x4102c0 [ 2971.585178] clear port connect change, actual port 1 status = 0x4002c0 [ 2971.585213] clear port link state change, actual port 1 status = 0x2c0 [ 2971.640030] get port status, actual port 1 status = 0x2d1 [ 2971.640031] Get port status returned 0x2d1 [ 2971.696029] get port status, actual port 1 status = 0x2d1 [ 2971.696031] Get port status returned 0x2d1 [ 2971.900031] get port status, actual port 1 status = 0x2d1 [ 2971.900034] Get port status returned 0x2d1 [ 2972.060480] Port Status Change Event for port 2 [ 2972.104039] get port status, actual port 1 status = 0x2802a0 [ 2972.104041] Get port status returned 0x3002a0 [ 2972.104079] clear port reset change, actual port 1 status = 0x802a0 [ 2972.104108] clear port warm(BH) reset change, actual port 1 status = 0x2a0 [ 2972.104138] clear port link state change, actual port 1 status = 0x2a0 [ 2972.104144] usb 6-2: USB disconnect, device number 6 <=== 30 seconds gap > [ 3002.080058] Cancel URB f2d0c480, dev 2, ep 0x81, starting at offset 0x337ad060 <== SCSI layer cancelling URB after 30 seconds [ 3002.080063]// Ding dong! [ 2972.060569] Stopped on Transfer TRB [ 3002.080817] Removing canceled TD starting at 0x337ad060 (dma). [ 3002.080820] Finding segment containing stopped TRB. [ 3002.080822] Finding endpoint context [ 3002.080823] Finding segment containing last TRB in TD. [ 3002.080825] Cycle state = 0x0 [ 3002.080827] New dequeue segment = f71628f0 (virtual) [ 3002.080828] New dequeue pointer = 0x337ad070 (DMA) [ 3002.080831] Set TR Deq Ptr cmd, new deq seg = f71628f0 (0x337ad000 dma), new deq ptr = f37ad070 (0x337ad070 dma), new cycle = 0 = Thanks Ajay -- 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: [balbi-usb:merge-result-for-greg 66/99] drivers/usb/core/hub.c:2654 usb_get_hub_port_power_state() error: doing dma on the stack ((null))
On Wed, Sep 12, 2012 at 04:26:22PM +0800, Fengguang Wu wrote: > Hi Felipe, > > FYI, there are new smatch warnings show up in > > tree: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git > merge-result-for-greg > head: 23953bde3e4d6aa8780dc054f6ad9882ac63f4f4 > commit: e918fa161f510136fce45a524e934fe20e62c8b1 [66/99] Merge tag > 'gadget-for-v3.7' into merge-result-for-greg > > drivers/usb/core/hub.c:2654 usb_get_hub_port_power_state() error: doing dma > on the stack ((null)) Smatch prints out a lot of these warnings. I haven't looked at the rules in a while, so maybe there is a bounce buffer somewhere where it detects stack memory and allocates a DMA'able buffer? It would be better if the function documentation for usb_control_msg() said that the *data pointer had to be kmalloc()ed. Also I wonder if Documentation/DMA-API-HOWTO.txt is out of data. Are we allowed to DMA to vmalloc()ed memory yet? regards, dan carpenter -- 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
[balbi-usb:merge-result-for-greg 66/99] drivers/usb/core/hub.c:2654 usb_get_hub_port_power_state() error: doing dma on the stack ((null))
Hi Felipe,
FYI, there are new smatch warnings show up in
tree: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
merge-result-for-greg
head: 23953bde3e4d6aa8780dc054f6ad9882ac63f4f4
commit: e918fa161f510136fce45a524e934fe20e62c8b1 [66/99] Merge tag
'gadget-for-v3.7' into merge-result-for-greg
drivers/usb/core/hub.c:2654 usb_get_hub_port_power_state() error: doing dma on
the stack ((null))
drivers/usb/core/hub.c:4733 store_port_power_control() info: why not propagate
'ret' from set_port_feature() instead of -5?
drivers/usb/core/hub.c:4744 store_port_power_control() info: why not propagate
'ret' from clear_port_feature() instead of -5?
vim +2654 drivers/usb/core/hub.c
2644 return ret;
2645 }
2646
2647 static int usb_get_hub_port_power_state(struct usb_device *hdev, int
port1)
2648 {
2649 struct usb_hub *hub = hdev_to_hub(hdev);
2650 struct usb_port_status data;
2651 u16 portstatus;
2652 int ret;
2653
> 2654 ret = get_port_status(hub->hdev, port1, &data);
2655 if (ret < 4) {
2656 dev_err(hub->intfdev,
2657 "%s failed (err = %d)\n", __func__, ret);
2658 if (ret >= 0)
2659 ret = -EIO;
2660 return ret;
2661 } else
2662 portstatus = le16_to_cpu(data.wPortStatus);
2663 return port_is_power_on(hub, portstatus);
2664 }
---
0-DAY kernel build testing backend Open Source Technology Centre
Fengguang Wu Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: gadget: at91_udc: dt: fix platform_data check
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/12/2012 08:14 AM, Felipe Balbi :
> Hi,
>
> On Tue, Sep 11, 2012 at 02:20:19PM +0200, Nicolas Ferre wrote:
>> On 09/11/2012 02:07 PM, Fabio Porcedda :
>>> Don't fail the initialization check for the platform_data if
>>> there is avaiable an associated device tree node.
>>>
>>> This patch fix the dt support introduced in 3.4-rc1 by commit
>>> ("d1494a3 USB: at91: Device udc add dt support").
>>>
>>> Tested on a at91sam9260 based board (PRO3-EVK).
>>>
>>> Signed-off-by: Fabio Porcedda Cc:
>>> Stable [v3.4+] Cc: Jean-Christophe
>>> PLAGNIOL-VILLARD
>>
>> Acked-by: Nicolas Ferre
>>
>> Felipe, Greg, can we queue this one for 3.6-final ?
>
> I had already taken the other version before Fabio sent this v2...
> it's now merged in greg/usb-next branch. I suggest doing a
> cherry-pick for stable tree and resending the patch once v3.7-rc1
> is tagged.
Sure! No need to move to this v2.
We will do as you suggest for the stable branch inclusion.
Thanks, best regards,
- --
Nicolas Ferre
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQEcBAEBAgAGBQJQUDrVAAoJEAf03oE53VmQ8egH/2FTpGw98GJ47MzNKFaZvbGV
2ZrQTHsO2xOKenG+Chf/0oDkKROzQYgxGjfogDQmfhYPHkdqTdSRL5CD6hZSnhDo
Qvusw9XmOdikhBcTQKrrSxOyfoo1BcKFH07TunWfM2LXWrHUptk3jMb7Un62QGVa
wFYeHdkI+gwCbzcN+b9iV/qKYmkpfv71y0uved//OVBxXuBqoKOHTNlAZ1p5OT4r
GRj0zgq4tes8W1QeXDKOCu1oMqbH1qNqnklFWu0JzoiqhX809t9rYurZTep7YzWO
5+n1zV80qpMbXeClw/GgHKvt9WmA1afMTyMNryS5PTijEauc6ifidUrikIL+NuQ=
=w2cu
-END PGP SIGNATURE-
--
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: host: tegra: code clean up
As part of code clean up, used devm counterparts for the APIs
possible.
Signed-off-by: Venu Byravarasu
---
drivers/usb/host/ehci-tegra.c | 46 ++--
1 files changed, 16 insertions(+), 30 deletions(-)
diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index c0d4732..532db04 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -634,7 +634,8 @@ static int tegra_ehci_probe(struct platform_device *pdev)
setup_vbus_gpio(pdev, pdata);
- tegra = kzalloc(sizeof(struct tegra_ehci_hcd), GFP_KERNEL);
+ tegra = devm_kzalloc(&pdev->dev, sizeof(struct tegra_ehci_hcd),
+GFP_KERNEL);
if (!tegra)
return -ENOMEM;
@@ -642,13 +643,12 @@ static int tegra_ehci_probe(struct platform_device *pdev)
dev_name(&pdev->dev));
if (!hcd) {
dev_err(&pdev->dev, "Unable to create HCD\n");
- err = -ENOMEM;
- goto fail_hcd;
+ return -ENOMEM;
}
platform_set_drvdata(pdev, tegra);
- tegra->clk = clk_get(&pdev->dev, NULL);
+ tegra->clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(tegra->clk)) {
dev_err(&pdev->dev, "Can't get ehci clock\n");
err = PTR_ERR(tegra->clk);
@@ -657,9 +657,9 @@ static int tegra_ehci_probe(struct platform_device *pdev)
err = clk_prepare_enable(tegra->clk);
if (err)
- goto fail_clken;
+ goto fail_clk;
- tegra->emc_clk = clk_get(&pdev->dev, "emc");
+ tegra->emc_clk = devm_clk_get(&pdev->dev, "emc");
if (IS_ERR(tegra->emc_clk)) {
dev_err(&pdev->dev, "Can't get emc clock\n");
err = PTR_ERR(tegra->emc_clk);
@@ -677,7 +677,7 @@ static int tegra_ehci_probe(struct platform_device *pdev)
}
hcd->rsrc_start = res->start;
hcd->rsrc_len = resource_size(res);
- hcd->regs = ioremap(res->start, resource_size(res));
+ hcd->regs = devm_ioremap(&pdev->dev, res->start, resource_size(res));
if (!hcd->regs) {
dev_err(&pdev->dev, "Failed to remap I/O memory\n");
err = -ENOMEM;
@@ -701,8 +701,8 @@ static int tegra_ehci_probe(struct platform_device *pdev)
break;
default:
err = -ENODEV;
- dev_err(&pdev->dev, "unknown usb instance\n");
- goto fail_phy;
+ dev_err(&pdev->dev, "unknown usb inst:%d\n", instance);
+ goto fail_io;
}
}
@@ -712,7 +712,7 @@ static int tegra_ehci_probe(struct platform_device *pdev)
if (IS_ERR(tegra->phy)) {
dev_err(&pdev->dev, "Failed to open USB phy\n");
err = -ENXIO;
- goto fail_phy;
+ goto fail_io;
}
usb_phy_init(&tegra->phy->u_phy);
@@ -735,7 +735,8 @@ static int tegra_ehci_probe(struct platform_device *pdev)
#ifdef CONFIG_USB_OTG_UTILS
if (pdata->operating_mode == TEGRA_USB_OTG) {
- tegra->transceiver = usb_get_phy(USB_PHY_TYPE_USB2);
+ tegra->transceiver =
+ devm_usb_get_phy(&pdev->dev, USB_PHY_TYPE_USB2);
if (!IS_ERR_OR_NULL(tegra->transceiver))
otg_set_host(tegra->transceiver->otg, &hcd->self);
}
@@ -743,7 +744,7 @@ static int tegra_ehci_probe(struct platform_device *pdev)
err = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (err) {
- dev_err(&pdev->dev, "Failed to add USB HCD\n");
+ dev_err(&pdev->dev, "usb_add_hcd failed with err 0x%x\n", err);
goto fail;
}
@@ -752,32 +753,23 @@ static int tegra_ehci_probe(struct platform_device *pdev)
/* Don't skip the pm_runtime_forbid call if wakeup isn't working */
/* if (!pdata->power_down_on_bus_suspend) */
- pm_runtime_forbid(&pdev->dev);
+ pm_runtime_forbid(&pdev->dev);
pm_runtime_enable(&pdev->dev);
pm_runtime_put_sync(&pdev->dev);
return err;
fail:
#ifdef CONFIG_USB_OTG_UTILS
- if (!IS_ERR_OR_NULL(tegra->transceiver)) {
+ if (!IS_ERR_OR_NULL(tegra->transceiver))
otg_set_host(tegra->transceiver->otg, NULL);
- usb_put_phy(tegra->transceiver);
- }
#endif
usb_phy_shutdown(&tegra->phy->u_phy);
-fail_phy:
- iounmap(hcd->regs);
fail_io:
clk_disable_unprepare(tegra->emc_clk);
- clk_put(tegra->emc_clk);
fail_emc_clk:
clk_disable_unprepare(tegra->clk);
-fail_clken:
- clk_put(tegra->clk);
fail_clk:
usb_put_hcd(hcd);
-fail_hcd:
- kfree(tegra);
return err;
}
@@ -794,26 +786,20 @@ static int tegra_ehci_remove(struct platform_device *pdev)
pm_runtime_put
Re: [PATCH v4] usb: phy: add R-Car USB phy driver
Dear Simon > On Mon, Sep 10, 2012 at 07:06:48PM -0700, Kuninori Morimoto wrote: > > This patch adds Renesas R-Car USB phy driver. > > It supports R8A7779 chip at this point. > > > > R-Car has some USB controllers, but has only one phy-initializer. > > So, this driver is counting users. > > > > Hi Morimoto-san, > > below is an incremental patch to add some workarounds that > were made available to me. I wonder if you have some documentation > available to replace the hex values with #defines? I didn't know this workarounds. Sorry, my documentation doesn't have enough information. Best regards -- Kuninori Morimoto -- 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
