Kernel Ooops upon USB disconnect of a Western Digital My Passport 1TB drive
Hello all. On my Thunkpad T420i with 3.18.2 and 3.18.3 kernels, I can reproduce the following behaviour 100% of the time: 1. Connect one of my (NTFS-formatted) WD 1TB 'My Passport' drives via USB. 2. Disconnect the cable. 3. Kernel Ooops. For last entries of the journal (it actually caught the kernel oops one time, I'm amazed) see the photo here: https://dl.dropboxusercontent.com/u/63420/journal.jpg Please note that the drive need not be mounted at all. In fact, this even happens if I stop all graphical and automount services and plug-in and then disconnect the cable. Also, other USB drives and USB flash disks do not exhibit this behaviour... Go figure! If I'm on a console, I can only see the last 45 or so lines of the stack trace (using KVM 1600x900 resolution console). The first lines (along with the initial oops message (caught in the journal) get scrolled off so I cannot post anything). What can I do to further debug this? I'm uncomfortable having any plug-in utility writing to my disk after the crash since I'm using this laptop for work and have crucial data on it. I have also opened a bug here: https://bugzilla.kernel.org/show_bug.cgi?id=92091 Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] usb: phy: generic: migrate to gpio_desc
Robert Jarzmik writes:
> I'm not convinced of the "so many issues". So far I see the
> "gpiod_get_optional()" requirement, which is a one liner patch.
Would you try the following patch to see if it fixes all your concerns please ?
Cheers.
--
Robert
---<8---
>From 7b34a3aa2a0717b53cd458611048f50edde53d0c Mon Sep 17 00:00:00 2001
From: Robert Jarzmik
Date: Tue, 27 Jan 2015 06:27:03 +0100
Subject: [PATCH] usb: phy: generic: fix the gpios to be optional
All the gpios, ie. reset-gpios and vbus-detect-gpio, should be optional
and not prevent the driver from working. Fix the regression in the
behavior introduced by commit "usb: phy: generic: migrate to gpio_desc".
Signed-off-by: Robert Jarzmik
---
drivers/usb/phy/phy-generic.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
index dd05254..c767bf0 100644
--- a/drivers/usb/phy/phy-generic.c
+++ b/drivers/usb/phy/phy-generic.c
@@ -218,10 +218,10 @@ int usb_phy_gen_create_phy(struct device *dev, struct
usb_phy_generic *nop,
clk_rate = 0;
needs_vcc = of_property_read_bool(node, "vcc-supply");
- nop->gpiod_reset = devm_gpiod_get(dev, "reset-gpios");
+ nop->gpiod_reset = devm_gpiod_get_optional(dev, "reset-gpios");
err = PTR_ERR(nop->gpiod_reset);
if (!err) {
- nop->gpiod_vbus = devm_gpiod_get(dev,
+ nop->gpiod_vbus = devm_gpiod_get_optional(dev,
"vbus-detect-gpio");
err = PTR_ERR(nop->gpiod_vbus);
}
@@ -242,7 +242,7 @@ int usb_phy_gen_create_phy(struct device *dev, struct
usb_phy_generic *nop,
if (err == -EPROBE_DEFER)
return -EPROBE_DEFER;
if (err) {
- dev_err(dev, "Error requesting RESET GPIO\n");
+ dev_err(dev, "Error requesting RESET or VBUS GPIO\n");
return err;
}
--
2.1.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 1/3] usb: phy: generic: migrate to gpio_desc
Fabio Estevam writes: > On Sat, Dec 6, 2014 at 7:05 PM, Robert Jarzmik wrote: >> Change internal gpio handling from integer gpios into gpio >> descriptors. This change only addresses the internal API and >> device-tree/ACPI, while the legacy platform data remains integer space >> based. >> >> This change is only build compile tested, and very prone to error. I >> leave this comment for now in the commit message so that this patch gets >> some testing as I'm pretty sure it's buggy. > > I can confirm it is buggy. It makes the property 'reset-gpios' to be > mandatory now and causes regression. >> - gpio_set_value_cansleep(nop->gpio_reset, value); >> + if (nop->gpiod_reset) >> + gpiod_set_value(nop->gpiod_reset, asserted); > > Previously we had the active_low or active_high flag taken into > account. Now we don't. Is it something you're seing by testing of by code review ? Because the active high/active low is taken into account by gpiod_set_value(). >> - nop->gpio_reset = of_get_named_gpio_flags(node, >> "reset-gpios", >> - 0, &flags); >> - if (nop->gpio_reset == -EPROBE_DEFER) >> - return -EPROBE_DEFER; >> - >> - nop->reset_active_low = flags & OF_GPIO_ACTIVE_LOW; >> - >> + nop->gpiod_reset = devm_gpiod_get(dev, "reset-gpios"); > > We should do 'devm_gpiod_get(dev, "reset");' instead. Why ? The previous call was of_get_named_gpio_flags(node, "reset-gpios", ...). Why this name change into "reset" ? Now if you say we should do a "gpiod_get_optional()" instead of "devm_gpiod_get()", and if you're not willing to make that patch, I can make it. > This commit is now in linux-next as e9f2cefb0cdc2aea. > Should we revert it as it has so many issues? I'm not convinced of the "so many issues". So far I see the "gpiod_get_optional()" requirement, which is a one liner patch. Cheers. -- Robert -- 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
[RFC PATCH 2/4] usb: chipidea: udc: add set_selfpowered gaget ops
The gadget power property will be used at get_status request.
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/udc.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 540db0e..45914ba 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -841,6 +841,7 @@ __acquires(hwep->lock)
if ((setup->bRequestType & USB_RECIP_MASK) == USB_RECIP_DEVICE) {
/* Assume that device is bus powered for now. */
*(u16 *)req->buf = ci->remote_wakeup << 1;
+ *(u16 *)req->buf |= ci->gadget.is_selfpowered << 1;
} else if ((setup->bRequestType & USB_RECIP_MASK) \
== USB_RECIP_ENDPOINT) {
dir = (le16_to_cpu(setup->wIndex) & USB_ENDPOINT_DIR_MASK) ?
@@ -1543,6 +1544,18 @@ static int ci_udc_vbus_draw(struct usb_gadget *_gadget,
unsigned ma)
return -ENOTSUPP;
}
+static int ci_udc_selfpowered(struct usb_gadget *_gadget, int is_on)
+{
+ struct ci_hdrc *ci = container_of(_gadget, struct ci_hdrc, gadget);
+ struct ci_hw_ep *hwep = ci->ep0in;
+
+ spin_lock(hwep->lock);
+ _gadget->is_selfpowered = (is_on != 0);
+ spin_unlock(hwep->lock);
+
+ return 0;
+}
+
/* Change Data+ pullup status
* this func is used by usb_gadget_connect/disconnet
*/
@@ -1572,6 +1585,7 @@ static int ci_udc_stop(struct usb_gadget *gadget);
static const struct usb_gadget_ops usb_gadget_ops = {
.vbus_session = ci_udc_vbus_session,
.wakeup = ci_udc_wakeup,
+ .set_selfpowered= ci_udc_selfpowered,
.pullup = ci_udc_pullup,
.vbus_draw = ci_udc_vbus_draw,
.udc_start = ci_udc_start,
--
1.9.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
[RFC PATCH 4/4] usb: udc-core: add is_selfpowered sys entry
The user can read it through sys entry.
Signed-off-by: Peter Chen
---
drivers/usb/gadget/udc/udc-core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/gadget/udc/udc-core.c
b/drivers/usb/gadget/udc/udc-core.c
index 86d4d19..4f1aed4 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -623,6 +623,7 @@ static USB_UDC_ATTR(is_a_peripheral);
static USB_UDC_ATTR(b_hnp_enable);
static USB_UDC_ATTR(a_hnp_support);
static USB_UDC_ATTR(a_alt_hnp_support);
+static USB_UDC_ATTR(is_selfpowered);
static struct attribute *usb_udc_attrs[] = {
&dev_attr_srp.attr,
@@ -636,6 +637,7 @@ static struct attribute *usb_udc_attrs[] = {
&dev_attr_b_hnp_enable.attr,
&dev_attr_a_hnp_support.attr,
&dev_attr_a_alt_hnp_support.attr,
+ &dev_attr_is_selfpowered.attr,
NULL,
};
--
1.9.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
[RFC PATCH 1/4] usb: gadget: introduce is_selfpowered for usb_gadget
Whether the gadget is selfpowerwed or not can be determined by composite
core, so we can use a common entry to indicate if the self-powered
is supported by gadget, and the related private variable at individual
udc driver can be deleted.
Signed-off-by: Peter Chen
---
include/linux/usb/gadget.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 4d1adea..a93e4e1 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -523,6 +523,7 @@ struct usb_gadget_ops {
* enabled HNP support.
* @quirk_ep_out_aligned_size: epout requires buffer size to be aligned to
* MaxPacketSize.
+ * @is_selfpowered: if the gadget is self-powered.
*
* Gadgets have a mostly-portable "gadget driver" implementing device
* functions, handling all usb configurations and interfaces. Gadget
@@ -563,6 +564,7 @@ struct usb_gadget {
unsigneda_hnp_support:1;
unsigneda_alt_hnp_support:1;
unsignedquirk_ep_out_aligned_size:1;
+ unsignedis_selfpowered:1;
};
#define work_to_gadget(w) (container_of((w), struct usb_gadget, work))
--
1.9.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
[RFC PATCH 3/4] usb: gadget: at91_udc: use common is_selfpowered
Delete private selfpowered variable, and use common one.
Signed-off-by: Peter Chen
---
drivers/usb/gadget/udc/at91_udc.c | 8
drivers/usb/gadget/udc/at91_udc.h | 1 -
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/udc/at91_udc.c
b/drivers/usb/gadget/udc/at91_udc.c
index c862656..c0ec5f7 100644
--- a/drivers/usb/gadget/udc/at91_udc.c
+++ b/drivers/usb/gadget/udc/at91_udc.c
@@ -176,7 +176,7 @@ static int proc_udc_show(struct seq_file *s, void *unused)
udc->enabled
? (udc->vbus ? "active" : "enabled")
: "disabled",
- udc->selfpowered ? "self" : "VBUS",
+ udc->gadget.is_selfpowered ? "self" : "VBUS",
udc->suspended ? ", suspended" : "",
udc->driver ? udc->driver->driver.name : "(none)");
@@ -1000,7 +1000,7 @@ static int at91_set_selfpowered(struct usb_gadget
*gadget, int is_on)
unsigned long flags;
spin_lock_irqsave(&udc->lock, flags);
- udc->selfpowered = (is_on != 0);
+ gadget->is_selfpowered = (is_on != 0);
spin_unlock_irqrestore(&udc->lock, flags);
return 0;
}
@@ -1149,7 +1149,7 @@ static void handle_setup(struct at91_udc *udc, struct
at91_ep *ep, u32 csr)
*/
case ((USB_DIR_IN|USB_TYPE_STANDARD|USB_RECIP_DEVICE) << 8)
| USB_REQ_GET_STATUS:
- tmp = (udc->selfpowered << USB_DEVICE_SELF_POWERED);
+ tmp = (udc->gadget.is_selfpowered << USB_DEVICE_SELF_POWERED);
if (at91_udp_read(udc, AT91_UDP_GLB_STAT) & AT91_UDP_ESR)
tmp |= (1 << USB_DEVICE_REMOTE_WAKEUP);
PACKET("get device status\n");
@@ -1653,7 +1653,7 @@ static int at91_start(struct usb_gadget *gadget,
udc->driver = driver;
udc->gadget.dev.of_node = udc->pdev->dev.of_node;
udc->enabled = 1;
- udc->selfpowered = 1;
+ udc->gadget.is_selfpowered = 1;
return 0;
}
diff --git a/drivers/usb/gadget/udc/at91_udc.h
b/drivers/usb/gadget/udc/at91_udc.h
index 0175246..467dcfb 100644
--- a/drivers/usb/gadget/udc/at91_udc.h
+++ b/drivers/usb/gadget/udc/at91_udc.h
@@ -122,7 +122,6 @@ struct at91_udc {
unsignedreq_pending:1;
unsignedwait_for_addr_ack:1;
unsignedwait_for_config_ack:1;
- unsignedselfpowered:1;
unsignedactive_suspend:1;
u8 addr;
struct at91_udc_databoard;
--
1.9.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
[RFC PATCH 0/4] usb: gadget: add is_selfpowered
Hi Felipe, We can use a common is_selfpowered flag at usb_gadget to indicate whether the gadget is self-powered or bus-powered, it can avoid every udc driver defining a similar flag, and the user can read it through udc core sys entry. In the 1st patch, I introduce is_selfpowered for usb_gadget. In the 2nd patch, I take chipidea driver as an example to show how udc driver uses this flag. In the 3rd patch, I clean up at91 udc driver for this flag. In the 4th patch, I add this entry to sys through udc core. If you agree with this change, I will submit a formal patch set after cleaning up other udc drivers. Peter Chen (4): usb: gadget: introduce is_selfpowered for usb_gadget usb: chipidea: udc: add set_selfpowered gaget ops usb: gadget: at91_udc: use common is_selfpowered usb: udc-core: add is_selfpowered sys entry drivers/usb/chipidea/udc.c| 14 ++ drivers/usb/gadget/udc/at91_udc.c | 8 drivers/usb/gadget/udc/at91_udc.h | 1 - drivers/usb/gadget/udc/udc-core.c | 2 ++ include/linux/usb/gadget.h| 2 ++ 5 files changed, 22 insertions(+), 5 deletions(-) -- 1.9.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
Re: [GIT PULL] USB fixes for v3.19-rc
On Thu, Jan 22, 2015 at 01:36:33PM -0600, Felipe Balbi wrote: > Hi Greg, > > two more fixes needed from my side. Let me know if you prefer > to handle them differently. > > cheers > > The following changes since commit ec6f34e5b552fb0a52e6aae1a5afbbb1605cc6cc: > > Linux 3.19-rc5 (2015-01-18 18:02:20 +1200) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git > tags/fixes-for-v3.19-rc6 Pulled and pushed out, 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: [RFC PATCH] usb: dwc2: Use platform endianness when accessing registers
> From: Vincent Pelletier [mailto:plr.vinc...@gmail.com]
> Sent: Friday, January 23, 2015 12:19 AM
>
> On Fri, 23 Jan 2015 02:38:37 +, John Youn
> wrote:
> > Having the __raw functions everywhere is not pretty and probably not a
> > good idea either.
> >
> > I would rather have a dwc2_writel/dwc2_readl (like in dwc3), and we
> > can figure out what needs to happen in there to support your platform.
> >
> > As for readl/writel or the __raw equivalents, I am not sure. I haven't
> > run the in-kernel driver on a big endian system so I don't know what
> > the issue is. But I suspect there may be consequences to other
> > platforms if we simply change this to __raw_readl/__raw_writel.
>
> (focussing on readl, but the following also applies to writel)
>
> readl is defined as __le32_to_cpu(__raw_readl(...)), so using readl on
> little endian is equivalent to __raw_readl, as __le32_to_cpu is a no-op.
>
> On big endian, it causes problems because __le32_to_cpu swaps bytes
> around, causing GSNPSID to be read as 0xnn2n544f instead of expected
> 0x4f542nnn - and likewise for all other registers.
>
> An earlier version (sent to linux-usb a week ago with not enough CC,
> but I cannot find it in archives now) defined dwc2_readl as
> le32_to_cpu(readl(...))
> which is equivalent to
> le32_to_cpu(le32_to_cpu(__raw_readl(...)))
> and which, on big-endian, makes le32_to_cpu(le32_to_cpu()) a no-op and
> (ignoring possible compiler optimisation) swaps bytes twice per call.
> On little endian, it is still equivalent to __raw_readl(...).
>
> As for the prettiness of calling double-underscore functions,
> speaking for myself I'm not used to Linux development enough to tell.
> My python developer reflex tell me it's not how it should be.
> OTOH there is no "raw_readl" or so alias, and other USB drivers
> reference __raw_readl (example as of v3.14.28):
> linux/drivers/usb$ git grep -l __raw_readl
> gadget/at91_udc.c
> gadget/atmel_usba_udc.c
> gadget/atmel_usba_udc.h
> gadget/fsl_udc_core.c
> gadget/pxa27x_udc.h
> host/ehci-omap.c
> host/ehci-orion.c
> host/ehci-w90x900.c
> host/ehci.h
> host/isp1760-hcd.c
> host/ohci-da8xx.c
> host/ohci-nxp.c
> host/ohci-pxa27x.c
> musb/da8xx.c
> musb/davinci.c
> musb/musb_dsps.c
> musb/musb_io.h
> phy/phy-fsl-usb.c
>
> Would it be better to wrap __raw_readl in a macro and call that
> everywhere rather than calling __raw_readl itself ?
I was thinking more along the lines of what dwc3 does. See
drivers/usb/dwc3/io.h.
One solution would be to do as above, and put in a compile-time check
for your platform and call the appropriate access function.
I believe writel/readl also preserves memory ordering so it might
affect other platforms to just use the __raw equivalent in its place.
John
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
Re: [PATCH v1] ehci-pci: disable for Intel MID platforms
On Mon, Jan 26, 2015 at 01:23:47PM -0500, Alan Stern wrote: > On Mon, 26 Jan 2015, Andy Shevchenko wrote: > > > On Mon, 2015-01-26 at 09:21 -0800, Greg KH wrote: > > > On Mon, Jan 26, 2015 at 07:10:42PM +0200, Andy Shevchenko wrote: > > > > On some Intel MID platforms the ChipIdea USB controller is used. The > > > > EHCI PCI > > > > is in conflict with the proper driver. The patch makes a quick fix to > > > > get Intel > > > > Medfield platforms work back. > > > > > > > > One would make a proper patch to address the issue. > > > > > > Who is "one"? You? Someone else? > > > > Not me. > > > > > > > > > Fixes: adfa79d1c06a (USB: EHCI: make ehci-pci a separate driver) > > > > Signed-off-by: Andy Shevchenko > > > > --- > > > > drivers/usb/host/Kconfig | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig > > > > index fafc628..32d735a 100644 > > > > --- a/drivers/usb/host/Kconfig > > > > +++ b/drivers/usb/host/Kconfig > > > > @@ -112,7 +112,7 @@ if USB_EHCI_HCD > > > > > > > > config USB_EHCI_PCI > > > > tristate > > > > - depends on PCI > > > > + depends on PCI && !X86_INTEL_MID > > > > > > You just broke making a universal kernel build for your platform > > > possible, making distro developers very upset with you. > > > > I agree, though current kernel build doesn't work on the Intel MID > > anyway (I mean USB support). The mentioned commit broke it and seems > > no-one cared until now. > > > > > Please fix this properly. > > > > I don't know the right way to fix this. Alan, has you any suggestion? > > It depends. How did the code before the adfa79d1c06a commit avoid this > problem? By simply not enabling CONFIG_USB_EHCI_HCD? > Hi Andy, Would you define pci_id at ci_hdrc_pci.c (instead of ehci-pci.c) at your platform code/table to fix this problem? I am not familiar with pci, but it works at other platforms, like ARM. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7] extcon: usb-gpio: Introduce gpio usb extcon driver
Hi Roger,
On 01/27/2015 01:27 AM, Roger Quadros wrote:
> Hi Chanwoo,
>
> All your comments are valid. Need some clarification on one comment.
>
> On 26/01/15 15:56, Chanwoo Choi wrote:
>> Hi Roger,
>>
>> This patch looks good to me. But I add some comment.
>> If you modify some comment, I'll apply this patch on 3.21 queue.
>>
>> On Mon, Jan 26, 2015 at 9:15 PM, Roger Quadros wrote:
>>> This driver observes the USB ID pin connected over a GPIO and
>>> updates the USB cable extcon states accordingly.
>>>
>>> The existing GPIO extcon driver is not suitable for this purpose
>>> as it needs to be taught to understand USB cable states and it
>>> can't handle more than one cable per instance.
>>>
>>> For the USB case we need to handle 2 cable states.
>>> 1) USB (attach/detach)
>>> 2) USB-Host (attach/detach)
>>>
>>> This driver can be easily updated in the future to handle VBUS
>>> events in case it happens to be available on GPIO for any platform.
>>>
>>> Signed-off-by: Roger Quadros
>>> ---
>>> .../devicetree/bindings/extcon/extcon-usb-gpio.txt | 20 ++
>>> drivers/extcon/Kconfig | 7 +
>>> drivers/extcon/Makefile| 1 +
>>> drivers/extcon/extcon-usb-gpio.c | 214
>>> +
>>> 4 files changed, 242 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
>>> create mode 100644 drivers/extcon/extcon-usb-gpio.c
>>>
>
>
>
>>> +
>>> +static int usb_extcon_probe(struct platform_device *pdev)
>>> +{
>>> + struct device *dev = &pdev->dev;
>>> + struct device_node *np = dev->of_node;
>>> + struct usb_extcon_info *info;
>>> + int ret;
>>> +
>>> + if (!np)
>>> + return -EINVAL;
>>> +
>>> + info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL);
>>> + if (!info)
>>> + return -ENOMEM;
>>> +
>>> + info->dev = dev;
>>> + info->id_gpiod = devm_gpiod_get(&pdev->dev, "id");
>>> + if (IS_ERR(info->id_gpiod)) {
>>> + dev_err(dev, "failed to get ID GPIO\n");
>>> + return PTR_ERR(info->id_gpiod);
>>> + }
>>> +
>>> + ret = gpiod_set_debounce(info->id_gpiod,
>>> +USB_GPIO_DEBOUNCE_MS * 1000);
>>> + if (ret < 0)
>>> + info->debounce_jiffies =
>>> msecs_to_jiffies(USB_GPIO_DEBOUNCE_MS);
>>> +
>>> + INIT_DELAYED_WORK(&info->wq_detcable, usb_extcon_detect_cable);
>>> +
>>> + info->id_irq = gpiod_to_irq(info->id_gpiod);
>>> + if (info->id_irq < 0) {
>>> + dev_err(dev, "failed to get ID IRQ\n");
>>> + return info->id_irq;
>>> + }
>>> +
>>> + ret = devm_request_threaded_irq(dev, info->id_irq, NULL,
>>> + usb_irq_handler,
>>> + IRQF_SHARED | IRQF_ONESHOT |
>>> + IRQF_NO_SUSPEND,
>>> + pdev->name, info);
>
> use of IRQF_NO_SUSPEND is not recommended to be used together with
> IRQF_SHARED so
> I'll remove IRQF_SHARED from here if we decide to stick with IRQF_NO_SUSPEND.
> More on this below.
>
>>> + if (ret < 0) {
>>> + dev_err(dev, "failed to request handler for ID IRQ\n");
>>> + return ret;
>>> + }
>>> +
>>> + info->edev = devm_extcon_dev_allocate(dev, usb_extcon_cable);
>>> + if (IS_ERR(info->edev)) {
>>> + dev_err(dev, "failed to allocate extcon device\n");
>>> + return -ENOMEM;
>>> + }
>>> +
>>> + ret = devm_extcon_dev_register(dev, info->edev);
>>> + if (ret < 0) {
>>> + dev_err(dev, "failed to register extcon device\n");
>>> + return ret;
>>> + }
>>> +
>>> + platform_set_drvdata(pdev, info);
>>
>> I prefer to execute the device_init_wakeup() function as following
>> for suspend/resume function:
>> device_init_wakeup(&pdev->dev, 1);
>>
>>> +
>>> + /* Perform initial detection */
>>> + usb_extcon_detect_cable(&info->wq_detcable.work);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int usb_extcon_remove(struct platform_device *pdev)
>>> +{
>>> + struct usb_extcon_info *info = platform_get_drvdata(pdev);
>>> +
>>> + cancel_delayed_work_sync(&info->wq_detcable);
>>
>> Need to add blank line.
>>
>>> + return 0;
>>> +}
>>> +
>>> +#ifdef CONFIG_PM_SLEEP
>>> +static int usb_extcon_suspend(struct device *dev)
>>> +{
>>> + struct usb_extcon_info *info = dev_get_drvdata(dev);
>>> +
>>> + enable_irq_wake(info->id_irq);
>>
>> I prefer to use device_may_wakeup() function for whether
>> executing enable_irq_wake() or not. Also, The disable_irq()
>> in the suspend function would prevent us from discarding interrupt
>> before wakeup from suspend completely.
>>
>
> I need more clarification here.
>
> If we are going to
Re: [PATCH v3] ARM: zynq: DT: Add USB to device tree
On Tue, 2015-01-27 at 02:14AM +0100, Andreas Färber wrote:
> + linux-gpio, linux-usb, Felipe Balbi
>
> Am 26.01.2015 um 19:44 schrieb Sören Brinkmann:
> > On Mon, 2015-01-26 at 08:23AM -0800, Sören Brinkmann wrote:
> >> On Mon, 2015-01-26 at 05:21PM +0100, Andreas Färber wrote:
> >>> Am 26.01.2015 um 16:50 schrieb Sören Brinkmann:
> On Mon, 2015-01-26 at 10:35AM +0100, Andreas Färber wrote:
> > Am 26.01.2015 um 09:33 schrieb Andreas Färber:
> >> Am 26.01.2015 um 09:23 schrieb Michal Simek:
> >>> On 01/26/2015 09:19 AM, Andreas Färber wrote:
> And if I apply it to my -next based tree, adding corresponding nodes
> to
> zynq-parallella.dts, I get repeatedly:
>
> [ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT
> [ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap:
> f090e100 op: f090e140
> [ +0,81] platform ci_hdrc.0: Driver ci_hdrc requests probe
> deferral
> [ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT
> [ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap:
> f0910100 op: f0910140
> [ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe
> deferral
>
> Am I missing any other patches or config options?
> [...]
> >>> Why is it deferred? Is it because of pinmuxing stuff?
> >>
> >> No, happened without as well.
> >>
> >> Looking at a different place in dmesg, I spot this:
> >>
> >> [ +0,003988] usb_phy_generic phy0: GPIO lookup for consumer
> >> reset-gpios
> >> [ +0,12] usb_phy_generic phy0: using device tree for GPIO lookup
> >> [ +0,15] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios'
> >> property
> >> of node '/phy0[0]'
> >> [ +0,13] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio'
> >> property
> >> of node '/phy0[0]'
> >> [ +0,10] usb_phy_generic phy0: using lookup tables for GPIO lookup
> >> [ +0,000153] usb_phy_generic phy0: lookup for GPIO reset-gpios failed
> >> [ +0,12] usb_phy_generic phy0: Error requesting RESET GPIO
> >> [ +0,004360] usb_phy_generic: probe of phy0 failed with error -2
> >> [ +0,004991] usb_phy_generic phy1: GPIO lookup for consumer
> >> reset-gpios
> >> [ +0,12] usb_phy_generic phy1: using device tree for GPIO lookup
> >> [ +0,13] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios'
> >> property
> >> of node '/phy1[0]'
> >> [ +0,13] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio'
> >> property of node '/phy1[0]'
> >> [ +0,10] usb_phy_generic phy1: using lookup tables for GPIO lookup
> >> [ +0,12] usb_phy_generic phy1: lookup for GPIO reset-gpios failed
> >> [ +0,11] usb_phy_generic phy1: Error requesting RESET GPIO
> >> [ +0,004337] usb_phy_generic: probe of phy1 failed with error -2
> >>
> >> So, I guess the chipidea driver is deferring because the phys want a
> >> property that neither me nor you are specifying? [...]
> [...]
> > In my manuals and notes I can't find any GPIO being used as reset for
> > the USB PHYs. Any thoughts appreciated.
>
> Such a connection is optional. The platform might rely on its reset
> circuit, though it might not work for warm reboots.
> I haven't looked at parallela docs, but if there is a schematic
> available, that should tell you if/what is connected to the PHY reset
> pin.
> >>>
> >>> I do have the schematic, and the way I read it, only the on-board reset
> >>> button resets the PHYs.
> >>>
> >>> Yet it looks as if usb-nop-xceiv insists on a reset-gpios above, no?
> >>> Does it work on your boards with linux-next?
> >>
> >> I haven't re-tested it since I submitted the patches, but at that time
> >> it worked. But I also didn't test USB with the pinctrl patches together.
> >> I'll do some testing later today.
> >
> > So, just did a test. I took all the pinctrl stuff and this patch and ran
> > it on a zc702. I plugged in a thumb drive and that worked just fine. So,
> > basically this patch could go in, despite missing pinctrl properties.
>
> For my board I needed the following workaround:
>
> diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
> index dd05254241fb..96c7c36e22a6 100644
> --- a/drivers/usb/phy/phy-generic.c
> +++ b/drivers/usb/phy/phy-generic.c
> @@ -218,13 +218,13 @@ int usb_phy_gen_create_phy(struct device *dev,
> struct usb_phy_generic *nop,
> clk_rate = 0;
>
> needs_vcc = of_property_read_bool(node, "vcc-supply");
> - nop->gpiod_reset = devm_gpiod_get(dev, "reset-gpios");
> + /*nop->gpiod_reset = devm_gpiod_get(dev, "reset-gpios");
> err = PTR_ERR(nop->gpiod_reset);
> if (!err) {
>
[PATCH] usb: phy-generic: Don't fail on missing gpio reset
A reset through a GPIO is optional. Don't fail probing when it is
missing.
Reported-by: Andreas Färber
Signed-off-by: Soren Brinkmann
---
Hi Andreas,
does this do the trick?
Thanks,
Sören
drivers/usb/phy/phy-generic.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
index dd05254241fb..a73d4c738f0b 100644
--- a/drivers/usb/phy/phy-generic.c
+++ b/drivers/usb/phy/phy-generic.c
@@ -241,10 +241,8 @@ int usb_phy_gen_create_phy(struct device *dev, struct
usb_phy_generic *nop,
if (err == -EPROBE_DEFER)
return -EPROBE_DEFER;
- if (err) {
- dev_err(dev, "Error requesting RESET GPIO\n");
- return err;
- }
+ if (err)
+ nop->gpiod_reset = NULL;
nop->phy.otg = devm_kzalloc(dev, sizeof(*nop->phy.otg),
GFP_KERNEL);
--
2.2.2.1.g63c5777
--
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 v1] chipidea: pci: register nop PHY
On Mon, Jan 26, 2015 at 05:38:25PM +, Shevchenko, Andriy wrote: > On Fri, 2014-11-28 at 14:42 +0200, Andy Shevchenko wrote: > > On Mon, 2014-11-17 at 09:46 +0800, Peter Chen wrote: > > [] > > > > Rebase my next tree where antoine's generic phy support for chipidea > > > driver in it, and for usb phy, the "phy" changes to "usb_phy". > > > > Okay, I'm going to change the name in this structure, otherwise how the > > new patches in your tree helps me (PCI driver)? > > So, I tried the recent linux-next and we still get the same issue (like > I suspected Antoine's patches are not related to the PCI case anyhow). > > How should we proceed to get an issue fixed? > I could resend v2 of my patch with addressed previously commented stuff. > Just do your patch based on usb-next (or linux-next), and fix the comments if it is reasonable. Peter > -- > Andy Shevchenko > Intel Finland Oy > - > Intel Finland Oy > Registered Address: PL 281, 00181 Helsinki > Business Identity Code: 0357606 - 4 > Domiciled in Helsinki > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] usb: phy: generic: migrate to gpio_desc
On Sat, Dec 6, 2014 at 7:05 PM, Robert Jarzmik wrote:
> Change internal gpio handling from integer gpios into gpio
> descriptors. This change only addresses the internal API and
> device-tree/ACPI, while the legacy platform data remains integer space
> based.
>
> This change is only build compile tested, and very prone to error. I
> leave this comment for now in the commit message so that this patch gets
> some testing as I'm pretty sure it's buggy.
I can confirm it is buggy. It makes the property 'reset-gpios' to be
mandatory now and causes regression.
>
> Signed-off-by: Robert Jarzmik
> Acked-by: Linus Walleij
> ---
> Since v1: added Linus's ack
> ---
> drivers/usb/phy/phy-generic.c | 61
> ++-
> drivers/usb/phy/phy-generic.h | 4 +--
> 2 files changed, 21 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
> index 7594e50..71e061d 100644
> --- a/drivers/usb/phy/phy-generic.c
> +++ b/drivers/usb/phy/phy-generic.c
> @@ -61,16 +61,8 @@ static int nop_set_suspend(struct usb_phy *x, int suspend)
>
> static void nop_reset_set(struct usb_phy_generic *nop, int asserted)
> {
> - int value;
> -
> - if (!gpio_is_valid(nop->gpio_reset))
> - return;
> -
> - value = asserted;
> - if (nop->reset_active_low)
> - value = !value;
> -
> - gpio_set_value_cansleep(nop->gpio_reset, value);
> + if (nop->gpiod_reset)
> + gpiod_set_value(nop->gpiod_reset, asserted);
Previously we had the active_low or active_high flag taken into
account. Now we don't.
>
> if (!asserted)
> usleep_range(1, 2);
> @@ -145,35 +137,38 @@ int usb_phy_gen_create_phy(struct device *dev, struct
> usb_phy_generic *nop,
> struct usb_phy_generic_platform_data *pdata)
> {
> enum usb_phy_type type = USB_PHY_TYPE_USB2;
> - int err;
> + int err = 0;
>
> u32 clk_rate = 0;
> bool needs_vcc = false;
>
> - nop->reset_active_low = true; /* default behaviour */
> -
> if (dev->of_node) {
> struct device_node *node = dev->of_node;
> - enum of_gpio_flags flags = 0;
>
> if (of_property_read_u32(node, "clock-frequency", &clk_rate))
> clk_rate = 0;
>
> needs_vcc = of_property_read_bool(node, "vcc-supply");
> - nop->gpio_reset = of_get_named_gpio_flags(node, "reset-gpios",
> - 0, &flags);
> - if (nop->gpio_reset == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> -
> - nop->reset_active_low = flags & OF_GPIO_ACTIVE_LOW;
> -
> + nop->gpiod_reset = devm_gpiod_get(dev, "reset-gpios");
We should do 'devm_gpiod_get(dev, "reset");' instead.
This commit is now in linux-next as e9f2cefb0cdc2aea.
Should we revert it as it has so many issues?
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: zynq: DT: Add USB to device tree
+ linux-gpio, linux-usb, Felipe Balbi
Am 26.01.2015 um 19:44 schrieb Sören Brinkmann:
> On Mon, 2015-01-26 at 08:23AM -0800, Sören Brinkmann wrote:
>> On Mon, 2015-01-26 at 05:21PM +0100, Andreas Färber wrote:
>>> Am 26.01.2015 um 16:50 schrieb Sören Brinkmann:
On Mon, 2015-01-26 at 10:35AM +0100, Andreas Färber wrote:
> Am 26.01.2015 um 09:33 schrieb Andreas Färber:
>> Am 26.01.2015 um 09:23 schrieb Michal Simek:
>>> On 01/26/2015 09:19 AM, Andreas Färber wrote:
And if I apply it to my -next based tree, adding corresponding nodes to
zynq-parallella.dts, I get repeatedly:
[ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT
[ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap:
f090e100 op: f090e140
[ +0,81] platform ci_hdrc.0: Driver ci_hdrc requests probe
deferral
[ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT
[ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap:
f0910100 op: f0910140
[ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe
deferral
Am I missing any other patches or config options?
[...]
>>> Why is it deferred? Is it because of pinmuxing stuff?
>>
>> No, happened without as well.
>>
>> Looking at a different place in dmesg, I spot this:
>>
>> [ +0,003988] usb_phy_generic phy0: GPIO lookup for consumer reset-gpios
>> [ +0,12] usb_phy_generic phy0: using device tree for GPIO lookup
>> [ +0,15] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios'
>> property
>> of node '/phy0[0]'
>> [ +0,13] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio'
>> property
>> of node '/phy0[0]'
>> [ +0,10] usb_phy_generic phy0: using lookup tables for GPIO lookup
>> [ +0,000153] usb_phy_generic phy0: lookup for GPIO reset-gpios failed
>> [ +0,12] usb_phy_generic phy0: Error requesting RESET GPIO
>> [ +0,004360] usb_phy_generic: probe of phy0 failed with error -2
>> [ +0,004991] usb_phy_generic phy1: GPIO lookup for consumer reset-gpios
>> [ +0,12] usb_phy_generic phy1: using device tree for GPIO lookup
>> [ +0,13] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios'
>> property
>> of node '/phy1[0]'
>> [ +0,13] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio'
>> property of node '/phy1[0]'
>> [ +0,10] usb_phy_generic phy1: using lookup tables for GPIO lookup
>> [ +0,12] usb_phy_generic phy1: lookup for GPIO reset-gpios failed
>> [ +0,11] usb_phy_generic phy1: Error requesting RESET GPIO
>> [ +0,004337] usb_phy_generic: probe of phy1 failed with error -2
>>
>> So, I guess the chipidea driver is deferring because the phys want a
>> property that neither me nor you are specifying? [...]
[...]
> In my manuals and notes I can't find any GPIO being used as reset for
> the USB PHYs. Any thoughts appreciated.
Such a connection is optional. The platform might rely on its reset
circuit, though it might not work for warm reboots.
I haven't looked at parallela docs, but if there is a schematic
available, that should tell you if/what is connected to the PHY reset
pin.
>>>
>>> I do have the schematic, and the way I read it, only the on-board reset
>>> button resets the PHYs.
>>>
>>> Yet it looks as if usb-nop-xceiv insists on a reset-gpios above, no?
>>> Does it work on your boards with linux-next?
>>
>> I haven't re-tested it since I submitted the patches, but at that time
>> it worked. But I also didn't test USB with the pinctrl patches together.
>> I'll do some testing later today.
>
> So, just did a test. I took all the pinctrl stuff and this patch and ran
> it on a zc702. I plugged in a thumb drive and that worked just fine. So,
> basically this patch could go in, despite missing pinctrl properties.
For my board I needed the following workaround:
diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
index dd05254241fb..96c7c36e22a6 100644
--- a/drivers/usb/phy/phy-generic.c
+++ b/drivers/usb/phy/phy-generic.c
@@ -218,13 +218,13 @@ int usb_phy_gen_create_phy(struct device *dev,
struct usb_phy_generic *nop,
clk_rate = 0;
needs_vcc = of_property_read_bool(node, "vcc-supply");
- nop->gpiod_reset = devm_gpiod_get(dev, "reset-gpios");
+ /*nop->gpiod_reset = devm_gpiod_get(dev, "reset-gpios");
err = PTR_ERR(nop->gpiod_reset);
if (!err) {
nop->gpiod_vbus = devm_gpiod_get(dev,
"vbus-detect-gpio");
err = PTR_ERR(nop->gpiod_vbus);
- }
+ }*/
} else if (pdata) {
type = pdata->type;
clk_rate = pdata->clk_rate;
[ +0,004738]
Re: Fatal Exception on device when Hotsyncing Palm in linux
On Mon, 2015-01-26 at 23:33 +0100, Henri Manson wrote: > From lsusb: > > Bus 008 Device 013: ID 0830:0002 Palm, Inc. m505 I've blacklisted anything driven by 'visor' upstream in ModemManager, since most of those appear to be non-phone devices. Yes, 3 are phones (Samsung and Acer) but they are so old (2002 - 2005) that I hope nobody is using them anymore for dialup WWAN access... Dan -- 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: Fatal Exception on device when Hotsyncing Palm in linux
>From lsusb: Bus 008 Device 013: ID 0830:0002 Palm, Inc. m505 -- 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: Fatal Exception on device when Hotsyncing Palm in linux
On Mon, 2015-01-26 at 22:49 +0100, Henri Manson wrote: > Indeed /usr/sbin/ModemManager (Ubuntu 14.04) or > /usr/sbin/modem-manager (Ubuntu 10.04) is the program that is started > when a Palm is connected and is causing the 'Fatal Exception' on the > Palm m505. Moving it out of the way is the solution. How can I update > the blacklist myself? It's based on udev rules, so look at /usr/lib/udev/rules.d/77-mm-usb-device-blacklist.rules. You can copy the file to /etc/udev/rules.d, remove the existing devices, and add your device there by USB VID and PID. When you plug it in again, ModemManager will then ignore it. What is the VID/PID again so that we can add it to the upstream blacklist? Dan > On Mon, Jan 26, 2015 at 10:20 PM, Dan Williams wrote: > > On Mon, 2015-01-26 at 19:17 +0100, Johan Hovold wrote: > >> On Mon, Jan 26, 2015 at 04:00:26PM +0100, Henri Manson wrote: > >> > Hello, > >> > > >> > I performed the test using VirtualBox and live cd iso images, so > >> > mixing different version of kernel and user-space programs does not > >> > happen. > >> > >> You'd probably need to compile your own kernel (e.g. test an old kernel > >> on your recent userspace) if you really want to rule out that this is > >> kernel related (which it doesn't seem to be). > >> > >> > In 9.04 there is no usb communication until pilot-xfer is > >> > started (a user-space program), in 10.04 usb communication happens > >> > directly after hotsyncing. Does anyone know which, if at all, > >> > user-space program is auto-started in 10.04 after a Palm is detected? > >> > Do I need to check udev rules? > >> > >> No idea, sorry. Perhaps you should file a bug report with your distro. > > > > It might be ModemManager; try moving /usr/sbin/ModemManager out of the > > way. If so, we'll update the USB device blacklist for various Palm > > devices upstream, so that it ignores them. > > > > Dan > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] usb: musb: cppi41: correct the macro name EP_MODE_AUTOREG_*
The macro EP_MODE_AUTOREG_* should be called EP_MODE_AUTOREQ_*, as they
are used for register AUTOREQ.
Signed-off-by: Bin Liu
---
drivers/usb/musb/musb_cppi41.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
index bbc958a..c06c459 100644
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c
@@ -9,9 +9,9 @@
#define RNDIS_REG(x) (0x80 + ((x - 1) * 4))
-#define EP_MODE_AUTOREG_NONE 0
-#define EP_MODE_AUTOREG_ALL_NEOP 1
-#define EP_MODE_AUTOREG_ALWAYS 3
+#define EP_MODE_AUTOREQ_NONE 0
+#define EP_MODE_AUTOREQ_ALL_NEOP 1
+#define EP_MODE_AUTOREQ_ALWAYS 3
#define EP_MODE_DMA_TRANSPARENT0
#define EP_MODE_DMA_RNDIS 1
@@ -403,19 +403,19 @@ static bool cppi41_configure_channel(struct dma_channel
*channel,
/* auto req */
cppi41_set_autoreq_mode(cppi41_channel,
- EP_MODE_AUTOREG_ALL_NEOP);
+ EP_MODE_AUTOREQ_ALL_NEOP);
} else {
musb_writel(musb->ctrl_base,
RNDIS_REG(cppi41_channel->port_num), 0);
cppi41_set_dma_mode(cppi41_channel,
EP_MODE_DMA_TRANSPARENT);
cppi41_set_autoreq_mode(cppi41_channel,
- EP_MODE_AUTOREG_NONE);
+ EP_MODE_AUTOREQ_NONE);
}
} else {
/* fallback mode */
cppi41_set_dma_mode(cppi41_channel, EP_MODE_DMA_TRANSPARENT);
- cppi41_set_autoreq_mode(cppi41_channel, EP_MODE_AUTOREG_NONE);
+ cppi41_set_autoreq_mode(cppi41_channel, EP_MODE_AUTOREQ_NONE);
len = min_t(u32, packet_sz, len);
}
cppi41_channel->prog_len = len;
--
1.8.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 2/2] usb: musb: cppi41: improve rx channel abort routine
1. set AUTOREQ to NONE at the beginning of teardown;
2. add delay for dma pipeline to drain;
3. Do not set USB_TDOWN bit for RX teardown.
The CPPI hw has an issue that when tearing down a RX channel, if
another RX channel is receiving data, the CPPI will lockup.
To workaround the issue, do not set the CPPI TD bit. The steps before
this point ensures the CPPI channel will be torn down properly.
Signed-off-by: Bin Liu
---
drivers/usb/musb/musb_cppi41.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
index c06c459..8abd201 100644
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c
@@ -548,10 +548,15 @@ static int cppi41_dma_channel_abort(struct dma_channel
*channel)
csr &= ~MUSB_TXCSR_DMAENAB;
musb_writew(epio, MUSB_TXCSR, csr);
} else {
+ cppi41_set_autoreq_mode(cppi41_channel, EP_MODE_AUTOREQ_NONE);
+
csr = musb_readw(epio, MUSB_RXCSR);
csr &= ~(MUSB_RXCSR_H_REQPKT | MUSB_RXCSR_DMAENAB);
musb_writew(epio, MUSB_RXCSR, csr);
+ /* wait to drain cppi dma pipe line */
+ udelay(50);
+
csr = musb_readw(epio, MUSB_RXCSR);
if (csr & MUSB_RXCSR_RXPKTRDY) {
csr |= MUSB_RXCSR_FLUSHFIFO;
@@ -565,13 +570,14 @@ static int cppi41_dma_channel_abort(struct dma_channel
*channel)
tdbit <<= 16;
do {
- musb_writel(musb->ctrl_base, USB_TDOWN, tdbit);
+ if (is_tx)
+ musb_writel(musb->ctrl_base, USB_TDOWN, tdbit);
ret = dmaengine_terminate_all(cppi41_channel->dc);
} while (ret == -EAGAIN);
- musb_writel(musb->ctrl_base, USB_TDOWN, tdbit);
-
if (is_tx) {
+ musb_writel(musb->ctrl_base, USB_TDOWN, tdbit);
+
csr = musb_readw(epio, MUSB_TXCSR);
if (csr & MUSB_TXCSR_TXPKTRDY) {
csr |= MUSB_TXCSR_FLUSHFIFO;
--
1.8.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: Control message failures kill entire XHCI stack
I've come across what appears to be another xHCI issue - attempting to format a disk with gparted is causing a kernel Oops. This may not be related to the issue you're currently investigating, but wanted to pass it on in case it is (if it isn't let me know and I'll either keep quiet or raise it separately, whatever you prefer). I can easily reproduce the crash running 3.19rc6 with Mathias additional error and debugging messages (debugging switched off). I wasn't able to reproduce the issue with xhci debugging enabled, i.e.: echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control Just enabling debugging for xhci-ring.c, i.e.: echo -n 'file drivers/usb/host/xhci-ring.c =p' > /sys/kernel/debug/dynamic_debug/control allowed me to catch the crash with a bit more info. I've attached the full log at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1412121/+attachment/4306068/+files/syslog-3.19rc6-m0.1-gparted.log The end of the log is: Jan 26 22:33:27 alistair-XPS13 kernel: [ 908.402917] xhci_hcd :00:14.0: Stalled endpoint Jan 26 22:33:27 alistair-XPS13 kernel: [ 908.402933] xhci_hcd :00:14.0: cmdring ctrl reg before ringing 0x8 Jan 26 22:33:27 alistair-XPS13 kernel: [ 908.402937] xhci_hcd :00:14.0: // Ding dong! Jan 26 22:33:27 alistair-XPS13 kernel: [ 908.402943] xhci_hcd :00:14.0: cmdring ctrl reg after ringing 0x8 Jan 26 22:33:27 alistair-XPS13 kernel: [ 908.402949] xhci_hcd :00:14.0: Giveback URB 88020554dcc0, len = 0, expected = 512, status = -32 Jan 26 22:33:28 alistair-XPS13 kernel: [ 909.450041] xhci_hcd :00:14.0: Stalled endpoint Jan 26 22:33:28 alistair-XPS13 kernel: [ 909.450049] xhci_hcd :00:14.0: cmdring ctrl reg before ringing 0x8 Jan 26 22:33:28 alistair-XPS13 kernel: [ 909.450050] xhci_hcd :00:14.0: // Ding dong! Jan 26 22:33:28 alistair-XPS13 kernel: [ 909.450053] xhci_hcd :00:14.0: cmdring ctrl reg after ringing 0x8 Jan 26 22:33:28 alistair-XPS13 kernel: [ 909.450055] xhci_hcd :00:14.0: Giveback URB 88020554d3c0, len = 0, expected = 512, status = -32 Jan 26 22:33:28 alistair-XPS13 kernel: [ 909.450256] xhci_hcd :00:14.0: Stalled endpoint Jan 26 22:33:28 alistair-XPS13 kernel: [ 909.450258] xhci_hcd :00:14.0: cmdring ctrl reg before ringing 0x8 Jan 26 22:33:28 alistair-XPS13 kernel: [ 909.450259] xhci_hcd :00:14.0: // Ding dong! Jan 26 22:33:28 alistair-XPS13 kernel: [ 909.450261] xhci_hcd :00:14.0: cmdring ctrl reg after ringing 0x8 Jan 26 22:33:28 alistair-XPS13 kernel: [ 909.450263] xhci_hcd :00:14.0: Giveback URB 880203f6f000, len = 0, expected = 13, status = -32 Jan 26 22:33:59 alistair-XPS13 kernel: [ 940.174704] xhci_hcd :00:14.0: Starting stop cmd watchdog timer for slot 6 ep index 2. Jan 26 22:33:59 alistair-XPS13 kernel: [ 940.174713] xhci_hcd :00:14.0: cmdring ctrl reg before ringing 0x8 Jan 26 22:33:59 alistair-XPS13 kernel: [ 940.174716] xhci_hcd :00:14.0: // Ding dong! Jan 26 22:33:59 alistair-XPS13 kernel: [ 940.174721] xhci_hcd :00:14.0: cmdring ctrl reg after ringing 0x8 Jan 26 22:33:59 alistair-XPS13 kernel: [ 940.174728] xhci_hcd :00:14.0: Stopped on Transfer TRB Jan 26 22:33:59 alistair-XPS13 kernel: [ 940.174738] xhci_hcd :00:14.0: cmdring ctrl reg before ringing 0x8 Jan 26 22:33:59 alistair-XPS13 kernel: [ 940.174739] xhci_hcd :00:14.0: // Ding dong! Jan 26 22:33:59 alistair-XPS13 kernel: [ 940.174743] xhci_hcd :00:14.0: cmdring ctrl reg after ringing 0x8 Jan 26 22:33:59 alistair-XPS13 kernel: [ 940.229892] xhci_hcd :00:14.0: Port Status Change Event for port 2 Jan 26 22:33:59 alistair-XPS13 kernel: [ 940.229901] xhci_hcd :00:14.0: handle_port_status: starting port polling. Jan 26 22:33:59 alistair-XPS13 kernel: [ 940.286659] xhci_hcd :00:14.0: cmdring ctrl reg before ringing 0x8 Jan 26 22:33:59 alistair-XPS13 kernel: [ 940.28] xhci_hcd :00:14.0: // Ding dong! Jan 26 22:33:59 alistair-XPS13 kernel: [ 940.286672] xhci_hcd :00:14.0: cmdring ctrl reg after ringing 0x8 Jan 26 22:33:59 alistair-XPS13 kernel: [ 940.286817] xhci_hcd :00:14.0: Completed reset device command. Jan 26 22:33:59 alistair-XPS13 kernel: [ 940.286871] BUG: unable to handle kernel NULL pointer dereference at 0040 Jan 26 22:33:59 alistair-XPS13 kernel: [ 940.286955] IP: [] xhci_discover_or_reset_device+0x33d/0x520 Jan 26 22:33:59 alistair-XPS13 kernel: [ 940.287030] PGD 0 Jan 26 22:33:59 alistair-XPS13 kernel: [ 940.287054] Oops: [#1] SMP Jan 26 22:33:59 alistair-XPS13 kernel: [ 940.287090] Modules linked in: nls_iso8859_1 uas usb_storage ctr ccm pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) xt_CHECKSUM iptable_mangle xt_tcpudp bridge stp llc iptable_filter ip_tables x_tables arc4 iwlmvm mac80211 dm_crypt rpcsec_gss_krb5 nfsv4 intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm iwlwifi uvcvideo videobuf2_vmalloc videobuf2_memops snd_hda_codec_realtek snd_hda_cod
Re: Fatal Exception on device when Hotsyncing Palm in linux
Indeed /usr/sbin/ModemManager (Ubuntu 14.04) or /usr/sbin/modem-manager (Ubuntu 10.04) is the program that is started when a Palm is connected and is causing the 'Fatal Exception' on the Palm m505. Moving it out of the way is the solution. How can I update the blacklist myself? On Mon, Jan 26, 2015 at 10:20 PM, Dan Williams wrote: > On Mon, 2015-01-26 at 19:17 +0100, Johan Hovold wrote: >> On Mon, Jan 26, 2015 at 04:00:26PM +0100, Henri Manson wrote: >> > Hello, >> > >> > I performed the test using VirtualBox and live cd iso images, so >> > mixing different version of kernel and user-space programs does not >> > happen. >> >> You'd probably need to compile your own kernel (e.g. test an old kernel >> on your recent userspace) if you really want to rule out that this is >> kernel related (which it doesn't seem to be). >> >> > In 9.04 there is no usb communication until pilot-xfer is >> > started (a user-space program), in 10.04 usb communication happens >> > directly after hotsyncing. Does anyone know which, if at all, >> > user-space program is auto-started in 10.04 after a Palm is detected? >> > Do I need to check udev rules? >> >> No idea, sorry. Perhaps you should file a bug report with your distro. > > It might be ModemManager; try moving /usr/sbin/ModemManager out of the > way. If so, we'll update the USB device blacklist for various Palm > devices upstream, so that it ignores them. > > Dan > -- 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 v2] usb: Retry port status check on resume to work around RH bugs
The EHCI controller on the RK3288 SoC is violating basic parts of the
USB spec and thereby unable to properly resume a suspended port. It does
not start SOF generation within 3ms of finishing resume signaling, so
the attached device will drop off the bus again. This is a particular
problem with runtime PM, where accessing the device will trigger a
resume that immediately makes it unavailabe (and reenumerate with a new
handle).
Thankfully, the persist feature is generally able to work around stuff
like that. Unfortunately, it doesn't quite work in this particular case
because the controller will turn off the CurrentConnectStatus bit for an
instant while the device is reconnecting, which causes the kernel to
conclude that it permanently disappeared. This patch adds a tiny retry
mechanism to the core port resume code which will catch this case and
shouldn't have any notable impact on other controllers.
Signed-off-by: Julius Werner
---
drivers/usb/core/hub.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index aeb50bb..d1d0a66 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2896,10 +2896,12 @@ static int port_is_suspended(struct usb_hub *hub,
unsigned portstatus)
*/
static int check_port_resume_type(struct usb_device *udev,
struct usb_hub *hub, int port1,
- int status, unsigned portchange, unsigned portstatus)
+ int status, u16 portchange, u16 portstatus)
{
struct usb_port *port_dev = hub->ports[port1 - 1];
+ int retries = 3;
+retry:
/* Is a warm reset needed to recover the connection? */
if (status == 0 && udev->reset_resume
&& hub_port_warm_reset_required(hub, port1, portstatus)) {
@@ -2909,8 +2911,15 @@ static int check_port_resume_type(struct usb_device
*udev,
else if (status || port_is_suspended(hub, portstatus) ||
!port_is_power_on(hub, portstatus) ||
!(portstatus & USB_PORT_STAT_CONNECTION)) {
- if (status >= 0)
+ if (status >= 0) {
+ if (retries--) {
+ usleep_range(200, 300);
+ status = hub_port_status(hub, port1,
+ &portstatus, &portchange);
+ goto retry;
+ }
status = -ENODEV;
+ }
}
/* Can't do a normal resume if the port isn't enabled,
--
2.1.2
--
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: Retry port status check on resume to work around RH bugs
> You should use a sleeping function call, not a delay. Whoops... yes, of course. Guess too much firmware work made me forget what multithreading is there for a moment. Will send a v2. -- 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: Fatal Exception on device when Hotsyncing Palm in linux
On Mon, 2015-01-26 at 19:17 +0100, Johan Hovold wrote: > On Mon, Jan 26, 2015 at 04:00:26PM +0100, Henri Manson wrote: > > Hello, > > > > I performed the test using VirtualBox and live cd iso images, so > > mixing different version of kernel and user-space programs does not > > happen. > > You'd probably need to compile your own kernel (e.g. test an old kernel > on your recent userspace) if you really want to rule out that this is > kernel related (which it doesn't seem to be). > > > In 9.04 there is no usb communication until pilot-xfer is > > started (a user-space program), in 10.04 usb communication happens > > directly after hotsyncing. Does anyone know which, if at all, > > user-space program is auto-started in 10.04 after a Palm is detected? > > Do I need to check udev rules? > > No idea, sorry. Perhaps you should file a bug report with your distro. It might be ModemManager; try moving /usr/sbin/ModemManager out of the way. If so, we'll update the USB device blacklist for various Palm devices upstream, so that it ignores them. Dan -- 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/2] Fix force effect modifications for the Microsoft Sidewinder Force Feedback Pro 2 joystick
On Sat, 24 Jan 2015, Jim Keir wrote: > Yes, confirmed. The description below still holds. Could you please therefore fix this patch so that it contains proper changelog on proper place, and resubmit? Also, the Subject line looks rather strange to me ... to my understanding, this isn't really specific for MS sidewinder hardware, right? -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Fix initialisation for the Microsoft Sidewinder Force Feedback Pro 2 joystick
On Fri, 23 Jan 2015, Benjamin Tissoires wrote: > With the changes above (or if you fix my typos), the patch is > Reviewed-by: Benjamin.tissoires > > Jiri, could you amend the commit with the above so that Jim won't be > desperate by submitting a patch? Done and applied this one. Jim, please make sure you fix your workflow for the next submission. Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8] usb: dwc3: add ULPI interface support
On Mon, Jan 26, 2015 at 01:46:10PM +0200, Heikki Krogerus wrote:
> On Fri, Jan 23, 2015 at 10:24:43AM -0600, Felipe Balbi wrote:
> > On Fri, Jan 23, 2015 at 05:12:56PM +0200, Heikki Krogerus wrote:
> > > +int dwc3_ulpi_init(struct dwc3 *dwc)
> > > +{
> > > + u32 reg;
> > > +
> > > + /* First check USB2 PHY interface type */
> > > + switch (DWC3_GHWPARAMS3_HSPHY_IFC(dwc->hwparams.hwparams3)) {
> > > + case DWC3_GHWPARAMS3_HSPHY_IFC_UTMI_ULPI:
> > > + /* Select ULPI Interface */
> > > + reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
> > > + reg |= DWC3_GUSB2PHYCFG_ULPI_UTMI;
> > > + dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
> > > + /* FALLTHROUGH */
> > > + case DWC3_GHWPARAMS3_HSPHY_IFC_ULPI:
> > > + break;
> > > + default:
> > > + return 0;
> > > + }
> > > +
> > > + /* Register the interface */
> > > + dwc->ulpi = ulpi_register_interface(dwc->dev, &dwc3_ulpi);
> > > + if (IS_ERR(dwc->ulpi)) {
> >
> > so, this will only build and link if DWC3_ULPI is enabled, in case of
> > error you return early...
> >
> > > + dev_err(dwc->dev, "failed to register ULPI interface");
> > > + return PTR_ERR(dwc->ulpi);
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +void dwc3_ulpi_exit(struct dwc3 *dwc)
> > > +{
> > > + if (dwc->ulpi) {
> >
> > ... looks like this branch is unnecessary.
>
> We can't do that, or distros that select DWC3_ULPI option can only use
> dwc3 with hardware that really has ULPI PHY. So I guess we'll drop the
> DWC3_ULPI option and build the dwc3 ulpi support always if ULPI bus is
> enabled. OK?
look at your patch again. In case DWC3_ULPI isn't enabled, this file
won't be linked at all. You're using stubs, so taht's fine.
In case it _is_ enabled, you're breaking out early if you can't register
ulpi interface, meaning you're exitting probe() (which, in fact, seems
wrong as I want to be able to run dwc3 with ULPI enabled on a platform
that was configured with ULPI+UTMI, but uses UTMI PHY).
I still think this patch won't work in all cases.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 8/8] phy: add driver for TI TUSB1210 ULPI PHY
Hi Heikki,
On Mon, Jan 26, 2015 at 02:55:03PM +0200, Heikki Krogerus wrote:
> Hi David,
>
> On Sat, Jan 24, 2015 at 03:58:11PM -0800, David Cohen wrote:
> > > +static int tusb1210_power_on(struct phy *phy)
> > > +{
> > > + struct tusb1210 *tusb = phy_get_drvdata(phy);
> > > +
> > > + gpiod_set_value_cansleep(tusb->gpio_reset, 1);
> > > + gpiod_set_value_cansleep(tusb->gpio_cs, 1);
> > > +
> > > + /* Restore eye diagram optimisation value */
> > > + ulpi_write(tusb->ulpi, TUSB1210_VENDOR_SPECIFIC2,
> > > +tusb->eye_diagram_tuning);
> >
> > After you power on phy, ulpi bus may not be available right away. In
> > intel case, phy power on happens during dwc3 power on. ULPI bus is not
> > available until OTG controller and phy are in sync.
> >
> > In resume, you can't restore eye diagram from here.
>
> I'm sorry but I don't think I understand? Where do we power on the phy
> before dwc3 is powered on? Or is this a Baytrail-CR specific problem?
> I can't see any problems with the hardware I have.
You can't see in single accesses. But you may see when running stability
tests overnight.
Anyway, look for dwc3_core_soft_reset() function:
- dwc3 goes to reset state
- phy is initialized (or at least gets ready to sync clocks)
- dwc3 goes out or reset state
During tusb1210 phy init from dwc3, you shouldn't access ulpi bus.
>
> In any case, this sounds like purely dwc3 issue and not tusb1210
> issue.
That's neither purely dwc3's not tusb1210's, that's your problem :)
Since it's a potential bug introduced by your patch set here.
>
> > > +static int tusb1210_probe(struct ulpi *ulpi)
> > > +{
> > > + struct gpio_desc *gpio;
> > > + struct tusb1210 *tusb;
> > > + int ret;
> > > +
> > > + tusb = devm_kzalloc(&ulpi->dev, sizeof(*tusb), GFP_KERNEL);
> > > + if (!tusb)
> > > + return -ENOMEM;
> > > +
> > > + gpio = devm_gpiod_get(&ulpi->dev, "reset");
> > > + if (!IS_ERR(gpio)) {
> > > + ret = gpiod_direction_output(gpio, 0);
> > > + if (ret)
> > > + return ret;
> > > + tusb->gpio_reset = gpio;
> > > + }
> >
> > You cannot proceed with probe if gpio reset is not available. Different
> > from CS, it's a mandatory pin to toggle in order to power on/off phy and
> > get it in sync with OTG controller.
>
> Well, let's check -ENOENT and -ENODEV return values separately. The
> reset pin is not used on all platforms so getting this gpio is
> optional. This is the case even with some Intel's platforms using
> TUSB1210.
I doublechecked the tusb1210 datasheet. Despite the power on sequence
mentions RESET toggling as required, it has a comment later on that it
can be tied to VDDIO.
So as you mentioned, it'd be better to ignore -ENOENT and -ENODEV and
raise error otherwise.
>
> > > +
> > > + gpio = devm_gpiod_get(&ulpi->dev, "cs");
> > > + if (!IS_ERR(gpio)) {
> > > + ret = gpiod_direction_output(gpio, 0);
> > > + if (ret)
> > > + return ret;
> > > + tusb->gpio_cs = gpio;
> > > + }
> > > +
> > > + /* Store initial eye diagram optimisation value */
> > > + ret = ulpi_read(ulpi, TUSB1210_VENDOR_SPECIFIC2);
> >
> > It's unclear if ulpi is accessible at this point. You can't read it at
> > this point.
>
> We wouldn't have reached this point if ulpi wasn't accessible.
> Registering the ulpi interface would have already failed so no driver
> would have been probed.
You have a chicken/egg problem here:
- dwc3 needs phy to complete soft reset during probe
- tusb1210 needs dwc3 soft reset completed to be accessible via ULPI
Can you share how tusb1210 is connected on the platform you're using as
test for this patch? I don't think this driver would work reliably with
this device:
http://liliputing.com/2014/11/trekstor-launches-first-android-tablet-based-intels-irda-reference-design.html
Br, David
>
>
> Thanks!
>
> --
> heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: f_fs: Fix loop variable
On Mon, Jan 26, 2015 at 07:46:42AM +0100, Robert Baldyga wrote:
> On 01/23/2015 10:18 PM, Mario Schuknecht wrote:
> > Use if-loop variable 'epfile' instead of start variable 'epfiles'. Now the
> > correct endpoint file name is stored.
> >
> > Signed-off-by: Mario Schuknecht
> > ---
> > drivers/usb/gadget/function/f_fs.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/usb/gadget/function/f_fs.c
> > b/drivers/usb/gadget/function/f_fs.c
> > index 63314ed..8832a46 100644
> > --- a/drivers/usb/gadget/function/f_fs.c
> > +++ b/drivers/usb/gadget/function/f_fs.c
> > @@ -1581,10 +1581,10 @@ static int ffs_epfiles_create(struct ffs_data *ffs)
> > mutex_init(&epfile->mutex);
> > init_waitqueue_head(&epfile->wait);
> > if (ffs->user_flags & FUNCTIONFS_VIRTUAL_ADDR)
> > - sprintf(epfiles->name, "ep%02x", ffs->eps_addrmap[i]);
> > + sprintf(epfile->name, "ep%02x", ffs->eps_addrmap[i]);
> > else
> > - sprintf(epfiles->name, "ep%u", i);
> > - epfile->dentry = ffs_sb_create_file(ffs->sb, epfiles->name,
> > + sprintf(epfile->name, "ep%u", i);
> > + epfile->dentry = ffs_sb_create_file(ffs->sb, epfile->name,
> > epfile,
> > &ffs_epfile_operations);
> > if (unlikely(!epfile->dentry)) {
> >
>
> Acked-by: Robert Baldyga
I don't have original patch and I was never in Cc, please resend.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] usb: gadget: Fix os desc test
On Mon, Jan 26, 2015 at 01:26:19PM +0100, Andrzej Pietrasiewicz wrote: > W dniu 26.01.2015 o 12:47, Mario Schuknecht pisze: > >USB vendor type is encoded in field bmRequestType. Make test USB_TYPE_VENDOR > >with bRequestType instead of bRequest. > > > >Signed-off-by: Mario Schuknecht > > Acked-by: Andrzej Pietrasiewicz I don't have the patch and I was never Cced to this. Please resend -- balbi signature.asc Description: Digital signature
Re: [PATCH v1] ehci-pci: disable for Intel MID platforms
On Mon, 26 Jan 2015, Andy Shevchenko wrote: > On Mon, 2015-01-26 at 09:21 -0800, Greg KH wrote: > > On Mon, Jan 26, 2015 at 07:10:42PM +0200, Andy Shevchenko wrote: > > > On some Intel MID platforms the ChipIdea USB controller is used. The EHCI > > > PCI > > > is in conflict with the proper driver. The patch makes a quick fix to get > > > Intel > > > Medfield platforms work back. > > > > > > One would make a proper patch to address the issue. > > > > Who is "one"? You? Someone else? > > Not me. > > > > > > Fixes: adfa79d1c06a (USB: EHCI: make ehci-pci a separate driver) > > > Signed-off-by: Andy Shevchenko > > > --- > > > drivers/usb/host/Kconfig | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig > > > index fafc628..32d735a 100644 > > > --- a/drivers/usb/host/Kconfig > > > +++ b/drivers/usb/host/Kconfig > > > @@ -112,7 +112,7 @@ if USB_EHCI_HCD > > > > > > config USB_EHCI_PCI > > > tristate > > > - depends on PCI > > > + depends on PCI && !X86_INTEL_MID > > > > You just broke making a universal kernel build for your platform > > possible, making distro developers very upset with you. > > I agree, though current kernel build doesn't work on the Intel MID > anyway (I mean USB support). The mentioned commit broke it and seems > no-one cared until now. > > > Please fix this properly. > > I don't know the right way to fix this. Alan, has you any suggestion? It depends. How did the code before the adfa79d1c06a commit avoid this problem? By simply not enabling CONFIG_USB_EHCI_HCD? 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: Fatal Exception on device when Hotsyncing Palm in linux
On Mon, Jan 26, 2015 at 04:00:26PM +0100, Henri Manson wrote: > Hello, > > I performed the test using VirtualBox and live cd iso images, so > mixing different version of kernel and user-space programs does not > happen. You'd probably need to compile your own kernel (e.g. test an old kernel on your recent userspace) if you really want to rule out that this is kernel related (which it doesn't seem to be). > In 9.04 there is no usb communication until pilot-xfer is > started (a user-space program), in 10.04 usb communication happens > directly after hotsyncing. Does anyone know which, if at all, > user-space program is auto-started in 10.04 after a Palm is detected? > Do I need to check udev rules? No idea, sorry. Perhaps you should file a bug report with your distro. Johan -- 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 v1] ehci-pci: disable for Intel MID platforms
On Mon, 2015-01-26 at 09:21 -0800, Greg KH wrote: > On Mon, Jan 26, 2015 at 07:10:42PM +0200, Andy Shevchenko wrote: > > On some Intel MID platforms the ChipIdea USB controller is used. The EHCI > > PCI > > is in conflict with the proper driver. The patch makes a quick fix to get > > Intel > > Medfield platforms work back. > > > > One would make a proper patch to address the issue. > > Who is "one"? You? Someone else? Not me. > > > Fixes: adfa79d1c06a (USB: EHCI: make ehci-pci a separate driver) > > Signed-off-by: Andy Shevchenko > > --- > > drivers/usb/host/Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig > > index fafc628..32d735a 100644 > > --- a/drivers/usb/host/Kconfig > > +++ b/drivers/usb/host/Kconfig > > @@ -112,7 +112,7 @@ if USB_EHCI_HCD > > > > config USB_EHCI_PCI > > tristate > > - depends on PCI > > + depends on PCI && !X86_INTEL_MID > > You just broke making a universal kernel build for your platform > possible, making distro developers very upset with you. I agree, though current kernel build doesn't work on the Intel MID anyway (I mean USB support). The mentioned commit broke it and seems no-one cared until now. > Please fix this properly. I don't know the right way to fix this. Alan, has you any suggestion? -- Andy Shevchenko Intel Finland Oy -- 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 v1] chipidea: pci: register nop PHY
On Fri, 2014-11-28 at 14:42 +0200, Andy Shevchenko wrote: > On Mon, 2014-11-17 at 09:46 +0800, Peter Chen wrote: [] > > Rebase my next tree where antoine's generic phy support for chipidea > > driver in it, and for usb phy, the "phy" changes to "usb_phy". > > Okay, I'm going to change the name in this structure, otherwise how the > new patches in your tree helps me (PCI driver)? So, I tried the recent linux-next and we still get the same issue (like I suspected Antoine's patches are not related to the PCI case anyhow). How should we proceed to get an issue fixed? I could resend v2 of my patch with addressed previously commented stuff. -- Andy Shevchenko Intel Finland Oy - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Re: [PATCH v1] ehci-pci: disable for Intel MID platforms
On Mon, Jan 26, 2015 at 07:10:42PM +0200, Andy Shevchenko wrote: > On some Intel MID platforms the ChipIdea USB controller is used. The EHCI PCI > is in conflict with the proper driver. The patch makes a quick fix to get > Intel > Medfield platforms work back. > > One would make a proper patch to address the issue. Who is "one"? You? Someone else? > Fixes: adfa79d1c06a (USB: EHCI: make ehci-pci a separate driver) > Signed-off-by: Andy Shevchenko > --- > drivers/usb/host/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig > index fafc628..32d735a 100644 > --- a/drivers/usb/host/Kconfig > +++ b/drivers/usb/host/Kconfig > @@ -112,7 +112,7 @@ if USB_EHCI_HCD > > config USB_EHCI_PCI > tristate > - depends on PCI > + depends on PCI && !X86_INTEL_MID You just broke making a universal kernel build for your platform possible, making distro developers very upset with you. Please fix this properly. 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
[PATCH v1] ehci-pci: disable for Intel MID platforms
On some Intel MID platforms the ChipIdea USB controller is used. The EHCI PCI is in conflict with the proper driver. The patch makes a quick fix to get Intel Medfield platforms work back. One would make a proper patch to address the issue. Fixes: adfa79d1c06a (USB: EHCI: make ehci-pci a separate driver) Signed-off-by: Andy Shevchenko --- drivers/usb/host/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index fafc628..32d735a 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -112,7 +112,7 @@ if USB_EHCI_HCD config USB_EHCI_PCI tristate - depends on PCI + depends on PCI && !X86_INTEL_MID default y config USB_EHCI_HCD_PMC_MSP -- 2.1.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: USB autosuspend causing trouble with bluetooth
Things just got way worse with this hotplug thing. When the host power/control is set to `auto`, as soon as I insert the Unifying receiver one of kworkers starts eating 100% of one of the cores, according to `htop`. As soon as I `echo on` to power/control of the relevant USB hub the kworker stops doing this. This also happens with that other USB1.1 BT-dongle, so I assume any USB1.1 device would do. Also just unplugging the device is not enough, the kworker keeps eating CPU until I `echo on` to power/control. Should I start a separate thread? Right now I'm on 3.18.2-gentoo. -- 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 1/7] extcon: usb-gpio: Introduce gpio usb extcon driver
Hi Chanwoo,
All your comments are valid. Need some clarification on one comment.
On 26/01/15 15:56, Chanwoo Choi wrote:
> Hi Roger,
>
> This patch looks good to me. But I add some comment.
> If you modify some comment, I'll apply this patch on 3.21 queue.
>
> On Mon, Jan 26, 2015 at 9:15 PM, Roger Quadros wrote:
>> This driver observes the USB ID pin connected over a GPIO and
>> updates the USB cable extcon states accordingly.
>>
>> The existing GPIO extcon driver is not suitable for this purpose
>> as it needs to be taught to understand USB cable states and it
>> can't handle more than one cable per instance.
>>
>> For the USB case we need to handle 2 cable states.
>> 1) USB (attach/detach)
>> 2) USB-Host (attach/detach)
>>
>> This driver can be easily updated in the future to handle VBUS
>> events in case it happens to be available on GPIO for any platform.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> .../devicetree/bindings/extcon/extcon-usb-gpio.txt | 20 ++
>> drivers/extcon/Kconfig | 7 +
>> drivers/extcon/Makefile| 1 +
>> drivers/extcon/extcon-usb-gpio.c | 214
>> +
>> 4 files changed, 242 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
>> create mode 100644 drivers/extcon/extcon-usb-gpio.c
>>
>> +
>> +static int usb_extcon_probe(struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> + struct device_node *np = dev->of_node;
>> + struct usb_extcon_info *info;
>> + int ret;
>> +
>> + if (!np)
>> + return -EINVAL;
>> +
>> + info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL);
>> + if (!info)
>> + return -ENOMEM;
>> +
>> + info->dev = dev;
>> + info->id_gpiod = devm_gpiod_get(&pdev->dev, "id");
>> + if (IS_ERR(info->id_gpiod)) {
>> + dev_err(dev, "failed to get ID GPIO\n");
>> + return PTR_ERR(info->id_gpiod);
>> + }
>> +
>> + ret = gpiod_set_debounce(info->id_gpiod,
>> +USB_GPIO_DEBOUNCE_MS * 1000);
>> + if (ret < 0)
>> + info->debounce_jiffies =
>> msecs_to_jiffies(USB_GPIO_DEBOUNCE_MS);
>> +
>> + INIT_DELAYED_WORK(&info->wq_detcable, usb_extcon_detect_cable);
>> +
>> + info->id_irq = gpiod_to_irq(info->id_gpiod);
>> + if (info->id_irq < 0) {
>> + dev_err(dev, "failed to get ID IRQ\n");
>> + return info->id_irq;
>> + }
>> +
>> + ret = devm_request_threaded_irq(dev, info->id_irq, NULL,
>> + usb_irq_handler,
>> + IRQF_SHARED | IRQF_ONESHOT |
>> + IRQF_NO_SUSPEND,
>> + pdev->name, info);
use of IRQF_NO_SUSPEND is not recommended to be used together with IRQF_SHARED
so
I'll remove IRQF_SHARED from here if we decide to stick with IRQF_NO_SUSPEND.
More on this below.
>> + if (ret < 0) {
>> + dev_err(dev, "failed to request handler for ID IRQ\n");
>> + return ret;
>> + }
>> +
>> + info->edev = devm_extcon_dev_allocate(dev, usb_extcon_cable);
>> + if (IS_ERR(info->edev)) {
>> + dev_err(dev, "failed to allocate extcon device\n");
>> + return -ENOMEM;
>> + }
>> +
>> + ret = devm_extcon_dev_register(dev, info->edev);
>> + if (ret < 0) {
>> + dev_err(dev, "failed to register extcon device\n");
>> + return ret;
>> + }
>> +
>> + platform_set_drvdata(pdev, info);
>
> I prefer to execute the device_init_wakeup() function as following
> for suspend/resume function:
> device_init_wakeup(&pdev->dev, 1);
>
>> +
>> + /* Perform initial detection */
>> + usb_extcon_detect_cable(&info->wq_detcable.work);
>> +
>> + return 0;
>> +}
>> +
>> +static int usb_extcon_remove(struct platform_device *pdev)
>> +{
>> + struct usb_extcon_info *info = platform_get_drvdata(pdev);
>> +
>> + cancel_delayed_work_sync(&info->wq_detcable);
>
> Need to add blank line.
>
>> + return 0;
>> +}
>> +
>> +#ifdef CONFIG_PM_SLEEP
>> +static int usb_extcon_suspend(struct device *dev)
>> +{
>> + struct usb_extcon_info *info = dev_get_drvdata(dev);
>> +
>> + enable_irq_wake(info->id_irq);
>
> I prefer to use device_may_wakeup() function for whether
> executing enable_irq_wake() or not. Also, The disable_irq()
> in the suspend function would prevent us from discarding interrupt
> before wakeup from suspend completely.
>
I need more clarification here.
If we are going to use enable_irq_wake() here then what is the point of
IRQF_NO_SUSPEND?
>From Documentation/power/suspend-and-interrupts.txt I see that interrupts
>marked
as IRQF_NO_SUSPEND should not be configured for system
Re: [PATCH 2/2] usb: musb: try a race-free wakeup
Hi Sebastian, On Mon, Jan 26, 2015 at 2:57 AM, Sebastian Andrzej Siewior wrote: > On 01/21/2015 06:06 PM, Bin Liu wrote: >> Hi Sebastian, > > Hi Bin, > >> With this patch, hubs stop working on TI AM335x EVMs when autosuspend >> is enabled. >> >> I booted the board, connected a hub to the USB1 host port, it got >> enumerated properly, then connected a thumb drive to the hub, but the >> drive was not enumerated, no any log from kernel. Removing the drive, >> no any kernel message either. Finally removed the hub, no disconnect >> for the hub. Now check MUSB1 DEVCTL register, it value is 0x5D. >> >> Reverted this patch, the issue disappeared. Or disable usbcore >> autosuspend, the issue did not happen. >> >> I tested 7+ hubs, all have the same issue. >> >> I tested on git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git, tag >> ti2014.10.01. have not tested with mainline kernel yet. >> >> Have you validated this test case? > > No, I had no USB-hub attached. It would be nice if you could figure out > which part is responsible for the missing detection because otherwise > suspend/resume is broken. But I most likely will not have time for this in next few weeks. Thanks, -Bin. > >> Thanks, >> -Bin. > > Sebastian > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
usb_debug serial driver protocol
Hi, I want to use the usb_debug serial driver as a UART shell on my (embedded) device, because I just want to use it as a console(without a complex protocol so I can easily use putchar and getchar functions). This seems to work pretty good except for two things. Once upon establishing a connection I receive these data(send in 4-word chunks, that's why the address is always the same): 0x893d2600: 0041 |A...| 0x893d2600: 0054 |T...| 0x893d2600: 000d || 0x893d2600: 0041 |A...| 0x893d2600: 0054 |T...| 0x893d2600: 000d || 0x893d2600: 0041 |A...| 0x893d2600: 0054 |T...| 0x893d2600: 000d || 0x893d2600: f078007e 007e |~.x.~...| 0x893d2600: f078007e 007e |~.x.~...| Is that some kind of initialization protocol I have to handle? If yes, where do I find information about it? Another problem is that once the device got closed(by the screen command i.e.). I can't communicate with the device anymore. Thx in regards Michael -- 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: cp210x: add ID for RUGGEDCOM USB Serial Console
On Mon, Jan 26, 2015 at 01:40:34PM +0100, Johan Hovold wrote:
> On Wed, Jan 21, 2015 at 03:24:27PM -0500, Lennart Sorensen wrote:
> > Added the USB serial console device ID for Siemens Ruggedcom devices
> > which have a USB port for their serial console.
> >
> > Signed-off-by: Len Sorensen
> > ---
> > drivers/usb/serial/cp210x.c |1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
> > index f4c56fc..f34e6ba 100644
> > --- a/drivers/usb/serial/cp210x.c
> > +++ b/drivers/usb/serial/cp210x.c
> > @@ -55,6 +55,7 @@ static const struct usb_device_id id_table[] = {
> > { USB_DEVICE(0x0745, 0x1000) }, /* CipherLab USB CCD Barcode Scanner
> > 1000 */
> > { USB_DEVICE(0x0846, 0x1100) }, /* NetGear Managed Switch M4100 series,
> > M5300 series, M7100 series */
> > { USB_DEVICE(0x08e6, 0x5501) }, /* Gemalto Prox-PU/CU contactless
> > smartcard reader */
> > + { USB_DEVICE(0x0908, 0x01FF) }, /* RUGGEDCOM USB Serial Console */
> > { USB_DEVICE(0x08FD, 0x000A) }, /* Digianswer A/S , ZigBee/802.15.4 MAC
> > Device */
>
> Please try to keep the entries sorted by VID/PID. I fixed it up here and
> applied.
Oh crap, I thought I did. How ever did I mess that up? Sorry about that.
--
Len Sorensen
--
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: Seagate Expansion external drive, still problems
On Fri, 23 Jan 2015 pras...@anche.no wrote: > Hi. The device in question is the external usb hdd Seagate Expansion 1TB. > It claims to be usb 3.0 and also to be usable on usb 2.0 systems. > Vendor and device ids are 0bc2 and 2312. > > I have tested it on the fresh 3.18.3 from kernel.org, on a laptop with usb 2.0 > (I guess). > > According to [1] and [2], I simply plugged in the device without stating > any quirk or (as suggested in [3]) delay_use option for usb-storage under > /etc/modprobe.d/. The result is that the disk gets never recognized by the > system, > as better showed in the (bottom part of the) attached dmesg output. > > I also tried by stating 'quirks' and 'delay_use' as suggested in [2] and [3], > in every combination, also on older kernels, obtaining the same result. Please post a usbmon trace showing what happens when you plug in the drive. 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: Fatal Exception on device when Hotsyncing Palm in linux
Hello, I performed the test using VirtualBox and live cd iso images, so mixing different version of kernel and user-space programs does not happen. In 9.04 there is no usb communication until pilot-xfer is started (a user-space program), in 10.04 usb communication happens directly after hotsyncing. Does anyone know which, if at all, user-space program is auto-started in 10.04 after a Palm is detected? Do I need to check udev rules? On Mon, Jan 26, 2015 at 1:55 PM, Johan Hovold wrote: > On Mon, Jan 19, 2015 at 05:08:07PM +0100, Henri Manson wrote: >> Apparently on 9.04 USB communications happen after invoking pilot-link >> while in 10.04 it happens directly when Hotsync is activated on the >> device. Enclosed the 9.04 syslog file and MenuExample.prc which is >> sent using: >> >> pilot-xfer -p /dev/ttyUSB1 -i MenuExample.prc > > I don't see anything in the logs that's pointing towards the driver. I > think you need to rule out that this isn't a user-space bug (e.g. by > using 10.04 userspace with the older kernel from 9.04 or vice versa). > > Good luck, > Johan -- 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] Revert "usb: Reset USB-3 devices on USB-3 link bounce"
Hi,
On 26-01-15 16:30, Zhuang Jin Can wrote:
This revert a82b76f7fa6154e8ab2d8071842a3e38b9c0d0ff.
The commit causes an extra reset in remote wakeup as described in:
http://www.spinics.net/lists/linux-usb/msg119080.html
Signed-off-by: Zhuang Jin Can
No objection from me (*) against reverting this, as it was fixing a
rather obscure (but non the less real) issue, and the issue it
causes seems to be a bigger one.
Regards,
Hans
*) I'm the author of the original patch
---
drivers/usb/core/hub.c | 34 +-
1 file changed, 9 insertions(+), 25 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index aeb50bb..89d009a 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4882,7 +4882,7 @@ static void hub_port_connect_change(struct usb_hub *hub,
int port1,
static void port_event(struct usb_hub *hub, int port1)
__must_hold(&port_dev->status_lock)
{
- int connect_change, reset_device = 0;
+ int connect_change;
struct usb_port *port_dev = hub->ports[port1 - 1];
struct usb_device *udev = port_dev->child;
struct usb_device *hdev = hub->hdev;
@@ -4970,30 +4970,14 @@ static void port_event(struct usb_hub *hub, int port1)
if (hub_port_reset(hub, port1, NULL,
HUB_BH_RESET_TIME, true) < 0)
hub_port_disable(hub, port1, 1);
- } else
- reset_device = 1;
- }
-
- /*
-* On disconnect USB3 protocol ports transit from U0 to
-* SS.Inactive to Rx.Detect. If this happens a warm-
-* reset is not needed, but a (re)connect may happen
-* before hub_wq runs and sees the disconnect, and the
-* device may be an unknown state.
-*
-* If the port went through SS.Inactive without hub_wq
-* seeing it the C_LINK_STATE change flag will be set,
-* and we reset the dev to put it in a known state.
-*/
- if (reset_device || (udev && hub_is_superspeed(hub->hdev)
- && (portchange & USB_PORT_STAT_C_LINK_STATE)
- && (portstatus & USB_PORT_STAT_CONNECTION))) {
- usb_unlock_port(port_dev);
- usb_lock_device(udev);
- usb_reset_device(udev);
- usb_unlock_device(udev);
- usb_lock_port(port_dev);
- connect_change = 0;
+ } else {
+ usb_unlock_port(port_dev);
+ usb_lock_device(udev);
+ usb_reset_device(udev);
+ usb_unlock_device(udev);
+ usb_lock_port(port_dev);
+ connect_change = 0;
+ }
}
if (connect_change)
--
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] Revert "usb: Reset USB-3 devices on USB-3 link bounce"
This revert a82b76f7fa6154e8ab2d8071842a3e38b9c0d0ff.
The commit causes an extra reset in remote wakeup as described in:
http://www.spinics.net/lists/linux-usb/msg119080.html
Signed-off-by: Zhuang Jin Can
---
drivers/usb/core/hub.c | 34 +-
1 file changed, 9 insertions(+), 25 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index aeb50bb..89d009a 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4882,7 +4882,7 @@ static void hub_port_connect_change(struct usb_hub *hub,
int port1,
static void port_event(struct usb_hub *hub, int port1)
__must_hold(&port_dev->status_lock)
{
- int connect_change, reset_device = 0;
+ int connect_change;
struct usb_port *port_dev = hub->ports[port1 - 1];
struct usb_device *udev = port_dev->child;
struct usb_device *hdev = hub->hdev;
@@ -4970,30 +4970,14 @@ static void port_event(struct usb_hub *hub, int port1)
if (hub_port_reset(hub, port1, NULL,
HUB_BH_RESET_TIME, true) < 0)
hub_port_disable(hub, port1, 1);
- } else
- reset_device = 1;
- }
-
- /*
-* On disconnect USB3 protocol ports transit from U0 to
-* SS.Inactive to Rx.Detect. If this happens a warm-
-* reset is not needed, but a (re)connect may happen
-* before hub_wq runs and sees the disconnect, and the
-* device may be an unknown state.
-*
-* If the port went through SS.Inactive without hub_wq
-* seeing it the C_LINK_STATE change flag will be set,
-* and we reset the dev to put it in a known state.
-*/
- if (reset_device || (udev && hub_is_superspeed(hub->hdev)
- && (portchange & USB_PORT_STAT_C_LINK_STATE)
- && (portstatus & USB_PORT_STAT_CONNECTION))) {
- usb_unlock_port(port_dev);
- usb_lock_device(udev);
- usb_reset_device(udev);
- usb_unlock_device(udev);
- usb_lock_port(port_dev);
- connect_change = 0;
+ } else {
+ usb_unlock_port(port_dev);
+ usb_lock_device(udev);
+ usb_reset_device(udev);
+ usb_unlock_device(udev);
+ usb_lock_port(port_dev);
+ connect_change = 0;
+ }
}
if (connect_change)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7] extcon: usb-gpio: Introduce gpio usb extcon driver
Hi Roger,
This patch looks good to me. But I add some comment.
If you modify some comment, I'll apply this patch on 3.21 queue.
On Mon, Jan 26, 2015 at 9:15 PM, Roger Quadros wrote:
> This driver observes the USB ID pin connected over a GPIO and
> updates the USB cable extcon states accordingly.
>
> The existing GPIO extcon driver is not suitable for this purpose
> as it needs to be taught to understand USB cable states and it
> can't handle more than one cable per instance.
>
> For the USB case we need to handle 2 cable states.
> 1) USB (attach/detach)
> 2) USB-Host (attach/detach)
>
> This driver can be easily updated in the future to handle VBUS
> events in case it happens to be available on GPIO for any platform.
>
> Signed-off-by: Roger Quadros
> ---
> .../devicetree/bindings/extcon/extcon-usb-gpio.txt | 20 ++
> drivers/extcon/Kconfig | 7 +
> drivers/extcon/Makefile| 1 +
> drivers/extcon/extcon-usb-gpio.c | 214
> +
> 4 files changed, 242 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
> create mode 100644 drivers/extcon/extcon-usb-gpio.c
>
> diff --git a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
> b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
> new file mode 100644
> index 000..ab52a85
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
> @@ -0,0 +1,20 @@
> +USB GPIO Extcon device
> +
> +This is a virtual device used to generate USB cable states from the USB ID
> pin
> +connected to a GPIO pin.
> +
> +Required properties:
> +- compatible: Should be "linux,extcon-usb-gpio"
> +- id-gpio: gpio for USB ID pin. See gpio binding.
> +
> +Example:
> + extcon_usb1 {
> + compatible = "linux,extcon-usb-gpio";
> + id-gpio = <&gpio6 1 GPIO_ACTIVE_HIGH>;
> + }
> +
> + usb@1 {
> + ...
> + extcon = <&extcon_usb1>;
> + ...
I don' want to use '...' for example.
How about using omap usecase in your patch4[1] as following?
[1] ARM: dts: dra72-evm: Add extcon nodes for USB
&omap_dwc3_1 {
extcon = <&extcon_usb1>;
};
> + };
> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> index 6a1f7de..e4c01ab 100644
> --- a/drivers/extcon/Kconfig
> +++ b/drivers/extcon/Kconfig
> @@ -93,4 +93,11 @@ config EXTCON_SM5502
> Silicon Mitus SM5502. The SM5502 is a USB port accessory
> detector and switch.
>
> +config EXTCON_USB_GPIO
> + tristate "USB GPIO extcon support"
> + depends on GPIOLIB
How about use 'select' keyword instead of 'depends on'?
- depends on GPIOLIB -> select GPIOLIB
> + help
> + Say Y here to enable GPIO based USB cable detection extcon support.
> + Used typically if GPIO is used for USB ID pin detection.
> +
> endif # MULTISTATE_SWITCH
> diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
> index 0370b42..6a08a98 100644
> --- a/drivers/extcon/Makefile
> +++ b/drivers/extcon/Makefile
> @@ -12,3 +12,4 @@ obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
> obj-$(CONFIG_EXTCON_PALMAS)+= extcon-palmas.o
> obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o
> obj-$(CONFIG_EXTCON_SM5502)+= extcon-sm5502.o
> +obj-$(CONFIG_EXTCON_USB_GPIO) += extcon-usb-gpio.o
> diff --git a/drivers/extcon/extcon-usb-gpio.c
> b/drivers/extcon/extcon-usb-gpio.c
> new file mode 100644
> index 000..a20aa39
> --- /dev/null
> +++ b/drivers/extcon/extcon-usb-gpio.c
> @@ -0,0 +1,214 @@
> +/**
> + * drivers/extcon/extcon_usb_gpio.c - USB GPIO extcon driver
You should use the '-' instead of '_'.
- s/extcon_usb_gpio.c/extcon-usb-gpio.c
> + *
> + * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
> + * Author: Roger Quadros
> + *
> + * 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
> +#include
> +
> +#define USB_GPIO_DEBOUNCE_MS 20 /* ms */
> +
> +struct usb_extcon_info {
> + struct device *dev;
> + struct extcon_dev *edev;
> +
> + struct gpio_desc *id_gpiod;
> + int id_irq;
> +
> + unsigned long debounce_jiffies;
> + struct delayed_work wq_detcable;
> +};
> +
> +/* List of detectable cables */
> +enum {
> + EXTCON_CABLE_USB = 0,
> + EXTCON_CABLE_USB_HOST,
> +
> + EXTCON_CABLE_E
Re: Fatal Exception on device when Hotsyncing Palm in linux
On Mon, Jan 19, 2015 at 05:08:07PM +0100, Henri Manson wrote: > Apparently on 9.04 USB communications happen after invoking pilot-link > while in 10.04 it happens directly when Hotsync is activated on the > device. Enclosed the 9.04 syslog file and MenuExample.prc which is > sent using: > > pilot-xfer -p /dev/ttyUSB1 -i MenuExample.prc I don't see anything in the logs that's pointing towards the driver. I think you need to rule out that this isn't a user-space bug (e.g. by using 10.04 userspace with the older kernel from 9.04 or vice versa). Good luck, Johan -- 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 8/8] phy: add driver for TI TUSB1210 ULPI PHY
Hi David,
On Sat, Jan 24, 2015 at 03:58:11PM -0800, David Cohen wrote:
> > +static int tusb1210_power_on(struct phy *phy)
> > +{
> > + struct tusb1210 *tusb = phy_get_drvdata(phy);
> > +
> > + gpiod_set_value_cansleep(tusb->gpio_reset, 1);
> > + gpiod_set_value_cansleep(tusb->gpio_cs, 1);
> > +
> > + /* Restore eye diagram optimisation value */
> > + ulpi_write(tusb->ulpi, TUSB1210_VENDOR_SPECIFIC2,
> > + tusb->eye_diagram_tuning);
>
> After you power on phy, ulpi bus may not be available right away. In
> intel case, phy power on happens during dwc3 power on. ULPI bus is not
> available until OTG controller and phy are in sync.
>
> In resume, you can't restore eye diagram from here.
I'm sorry but I don't think I understand? Where do we power on the phy
before dwc3 is powered on? Or is this a Baytrail-CR specific problem?
I can't see any problems with the hardware I have.
In any case, this sounds like purely dwc3 issue and not tusb1210
issue.
> > +static int tusb1210_probe(struct ulpi *ulpi)
> > +{
> > + struct gpio_desc *gpio;
> > + struct tusb1210 *tusb;
> > + int ret;
> > +
> > + tusb = devm_kzalloc(&ulpi->dev, sizeof(*tusb), GFP_KERNEL);
> > + if (!tusb)
> > + return -ENOMEM;
> > +
> > + gpio = devm_gpiod_get(&ulpi->dev, "reset");
> > + if (!IS_ERR(gpio)) {
> > + ret = gpiod_direction_output(gpio, 0);
> > + if (ret)
> > + return ret;
> > + tusb->gpio_reset = gpio;
> > + }
>
> You cannot proceed with probe if gpio reset is not available. Different
> from CS, it's a mandatory pin to toggle in order to power on/off phy and
> get it in sync with OTG controller.
Well, let's check -ENOENT and -ENODEV return values separately. The
reset pin is not used on all platforms so getting this gpio is
optional. This is the case even with some Intel's platforms using
TUSB1210.
> > +
> > + gpio = devm_gpiod_get(&ulpi->dev, "cs");
> > + if (!IS_ERR(gpio)) {
> > + ret = gpiod_direction_output(gpio, 0);
> > + if (ret)
> > + return ret;
> > + tusb->gpio_cs = gpio;
> > + }
> > +
> > + /* Store initial eye diagram optimisation value */
> > + ret = ulpi_read(ulpi, TUSB1210_VENDOR_SPECIFIC2);
>
> It's unclear if ulpi is accessible at this point. You can't read it at
> this point.
We wouldn't have reached this point if ulpi wasn't accessible.
Registering the ulpi interface would have already failed so no driver
would have been probed.
Thanks!
--
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: f_fs: Fix loop variable
On 01/23/2015 10:18 PM, Mario Schuknecht wrote:
> Use if-loop variable 'epfile' instead of start variable 'epfiles'. Now the
> correct endpoint file name is stored.
>
> Signed-off-by: Mario Schuknecht
> ---
> drivers/usb/gadget/function/f_fs.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/f_fs.c
> b/drivers/usb/gadget/function/f_fs.c
> index 63314ed..8832a46 100644
> --- a/drivers/usb/gadget/function/f_fs.c
> +++ b/drivers/usb/gadget/function/f_fs.c
> @@ -1581,10 +1581,10 @@ static int ffs_epfiles_create(struct ffs_data *ffs)
> mutex_init(&epfile->mutex);
> init_waitqueue_head(&epfile->wait);
> if (ffs->user_flags & FUNCTIONFS_VIRTUAL_ADDR)
> - sprintf(epfiles->name, "ep%02x", ffs->eps_addrmap[i]);
> + sprintf(epfile->name, "ep%02x", ffs->eps_addrmap[i]);
> else
> - sprintf(epfiles->name, "ep%u", i);
> - epfile->dentry = ffs_sb_create_file(ffs->sb, epfiles->name,
> + sprintf(epfile->name, "ep%u", i);
> + epfile->dentry = ffs_sb_create_file(ffs->sb, epfile->name,
>epfile,
>&ffs_epfile_operations);
> if (unlikely(!epfile->dentry)) {
>
Acked-by: Michal Nazarewicz
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--
--
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: cp210x: add ID for RUGGEDCOM USB Serial Console
On Wed, Jan 21, 2015 at 03:24:27PM -0500, Lennart Sorensen wrote:
> Added the USB serial console device ID for Siemens Ruggedcom devices
> which have a USB port for their serial console.
>
> Signed-off-by: Len Sorensen
> ---
> drivers/usb/serial/cp210x.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
> index f4c56fc..f34e6ba 100644
> --- a/drivers/usb/serial/cp210x.c
> +++ b/drivers/usb/serial/cp210x.c
> @@ -55,6 +55,7 @@ static const struct usb_device_id id_table[] = {
> { USB_DEVICE(0x0745, 0x1000) }, /* CipherLab USB CCD Barcode Scanner
> 1000 */
> { USB_DEVICE(0x0846, 0x1100) }, /* NetGear Managed Switch M4100 series,
> M5300 series, M7100 series */
> { USB_DEVICE(0x08e6, 0x5501) }, /* Gemalto Prox-PU/CU contactless
> smartcard reader */
> + { USB_DEVICE(0x0908, 0x01FF) }, /* RUGGEDCOM USB Serial Console */
> { USB_DEVICE(0x08FD, 0x000A) }, /* Digianswer A/S , ZigBee/802.15.4 MAC
> Device */
Please try to keep the entries sorted by VID/PID. I fixed it up here and
applied.
Thanks,
Johan
--
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: Fix os desc test
W dniu 26.01.2015 o 12:47, Mario Schuknecht pisze:
USB vendor type is encoded in field bmRequestType. Make test USB_TYPE_VENDOR
with bRequestType instead of bRequest.
Signed-off-by: Mario Schuknecht
Acked-by: Andrzej Pietrasiewicz
---
drivers/usb/gadget/composite.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 6178353..13adfd1 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1655,7 +1655,7 @@ unknown:
* OS descriptors handling
*/
if (cdev->use_os_string && cdev->os_desc_config &&
- (ctrl->bRequest & USB_TYPE_VENDOR) &&
+ (ctrl->bRequestType & USB_TYPE_VENDOR) &&
ctrl->bRequest == cdev->b_vendor_code) {
struct usb_request *req;
struct usb_configuration*os_desc_cfg;
--
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 v2 2/7] usb: extcon: Fix USB-Host cable name
The recommended name for USB-Host cable state is "USB-Host" and not
"USB-HOST" as per drivers/extcon/extcon-class.c extcon_cable_name.
Change all instances of "USB-HOST" to "USB-Host".
Signed-off-by: Roger Quadros
Reviewed-by: Felipe Balbi
Acked-by: Felipe Balbi
---
drivers/extcon/extcon-palmas.c | 18 +-
drivers/usb/dwc3/dwc3-omap.c | 6 +++---
drivers/usb/phy/phy-omap-otg.c | 4 ++--
drivers/usb/phy/phy-tahvo.c| 8
4 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
index 11c6757..6d002c3 100644
--- a/drivers/extcon/extcon-palmas.c
+++ b/drivers/extcon/extcon-palmas.c
@@ -31,7 +31,7 @@
static const char *palmas_extcon_cable[] = {
[0] = "USB",
- [1] = "USB-HOST",
+ [1] = "USB-Host",
NULL,
};
@@ -93,26 +93,26 @@ static irqreturn_t palmas_id_irq_handler(int irq, void
*_palmas_usb)
PALMAS_USB_ID_INT_LATCH_CLR,
PALMAS_USB_ID_INT_EN_HI_CLR_ID_GND);
palmas_usb->linkstat = PALMAS_USB_STATE_ID;
- extcon_set_cable_state(palmas_usb->edev, "USB-HOST", true);
- dev_info(palmas_usb->dev, "USB-HOST cable is attached\n");
+ extcon_set_cable_state(palmas_usb->edev, "USB-Host", true);
+ dev_info(palmas_usb->dev, "USB-Host cable is attached\n");
} else if ((set & PALMAS_USB_ID_INT_SRC_ID_FLOAT) &&
(id_src & PALMAS_USB_ID_INT_SRC_ID_FLOAT)) {
palmas_write(palmas_usb->palmas, PALMAS_USB_OTG_BASE,
PALMAS_USB_ID_INT_LATCH_CLR,
PALMAS_USB_ID_INT_EN_HI_CLR_ID_FLOAT);
palmas_usb->linkstat = PALMAS_USB_STATE_DISCONNECT;
- extcon_set_cable_state(palmas_usb->edev, "USB-HOST", false);
- dev_info(palmas_usb->dev, "USB-HOST cable is detached\n");
+ extcon_set_cable_state(palmas_usb->edev, "USB-Host", false);
+ dev_info(palmas_usb->dev, "USB-Host cable is detached\n");
} else if ((palmas_usb->linkstat == PALMAS_USB_STATE_ID) &&
(!(set & PALMAS_USB_ID_INT_SRC_ID_GND))) {
palmas_usb->linkstat = PALMAS_USB_STATE_DISCONNECT;
- extcon_set_cable_state(palmas_usb->edev, "USB-HOST", false);
- dev_info(palmas_usb->dev, "USB-HOST cable is detached\n");
+ extcon_set_cable_state(palmas_usb->edev, "USB-Host", false);
+ dev_info(palmas_usb->dev, "USB-Host cable is detached\n");
} else if ((palmas_usb->linkstat == PALMAS_USB_STATE_DISCONNECT) &&
(id_src & PALMAS_USB_ID_INT_SRC_ID_GND)) {
palmas_usb->linkstat = PALMAS_USB_STATE_ID;
- extcon_set_cable_state(palmas_usb->edev, "USB-HOST", true);
- dev_info(palmas_usb->dev, " USB-HOST cable is attached\n");
+ extcon_set_cable_state(palmas_usb->edev, "USB-Host", true);
+ dev_info(palmas_usb->dev, " USB-Host cable is attached\n");
}
return IRQ_HANDLED;
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 172d64e..6713ad9 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -445,14 +445,14 @@ static int dwc3_omap_extcon_register(struct dwc3_omap
*omap)
omap->id_nb.notifier_call = dwc3_omap_id_notifier;
ret = extcon_register_interest(&omap->extcon_id_dev,
- edev->name, "USB-HOST",
+ edev->name, "USB-Host",
&omap->id_nb);
if (ret < 0)
- dev_vdbg(omap->dev, "failed to register notifier for
USB-HOST\n");
+ dev_vdbg(omap->dev, "failed to register notifier for
USB-Host\n");
if (extcon_get_cable_state(edev, "USB") == true)
dwc3_omap_set_mailbox(omap, OMAP_DWC3_VBUS_VALID);
- if (extcon_get_cable_state(edev, "USB-HOST") == true)
+ if (extcon_get_cable_state(edev, "USB-Host") == true)
dwc3_omap_set_mailbox(omap, OMAP_DWC3_ID_GROUND);
}
diff --git a/drivers/usb/phy/phy-omap-otg.c b/drivers/usb/phy/phy-omap-otg.c
index 56ee760..53cba3f 100644
--- a/drivers/usb/phy/phy-omap-otg.c
+++ b/drivers/usb/phy/phy-omap-otg.c
@@ -119,7 +119,7 @@ static int omap_otg_probe(struct platform_device *pdev)
otg_dev->vbus_nb.notifier_call = omap_otg_vbus_notifier;
ret = extcon_register_interest(&otg_dev->id_dev, config->extcon,
- "USB-HOST", &otg_dev->id_nb);
+ "USB-Host", &otg_dev->id_nb);
if (ret)
return ret;
@@ -130,7 +130,7 @@ static int omap_otg_probe(struct
[PATCH v2 6/7] ARM: dts: am57xx-beagle-x15: Fix USB2 mode
On this board USB2 is meant to be used as peripheral only.
The ID pin for USB2 is hardwired HIGH.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/am57xx-beagle-x15.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index ad1833b..2115dda 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -436,3 +436,7 @@
&omap_dwc3_2 {
extcon = <&extcon_usb2>;
};
+
+&usb2 {
+ dr_mode = "peripheral";
+};
--
2.1.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
[PATCH v2 0/7] extcon: usb: Introduce USB GPIO extcon driver. Fix DRA7 & AM57xx USB.
Hi, Still hoping this can make into 3.20 else we have USB peripheral mode broken on DRA7-evm, DRA72-evm and AM57xx-beagle-x15. On DRA7 and AM57xx EVMs the USB ID pin is connected to a GPIO line. The USB drivers (dwc3 + dwc3-omap) depend on extcon framework to get the USB cable state (USB or USB-Host) to put the controller in the right mode. There were earlier attempts [1] to get this working by trying to patch up the existing GPIO extcon driver. This series attemts to take a different approach by introducing a new USB specific extcon driver to handle the USB ID GPIO pin and interpret a right USB cable state. The reasoning to introduce this new driver is: 1) The existing GPIO extcon driver doesn't understand USB cable states and it can't handle more than one cable per instance. For the USB case we need to handle at least 2 cable states. a) USB (attach/detach) b) USB-Host (attach/detach) and could possible include more states like c) Fast-charger (attach/detach) d) Slow-charger (attach/detach) 2) This USB specific driver can be easily updated in the future to handle VBUS events, or charger detect events, in case it happens to be available on GPIO for any platform. 3) The DT implementation is very easy. You just need one extcon node per USB instead of one extcon node per cable state as in case of [1]. 4) The cable state string doesn't need to be encoded in the device tree as in case of [1]. 5) With only ID event available, you can simulate a USB-peripheral attach when USB-Host is detacted instead of hacking the USB driver to do the same. Tested on DRA7-evm, DRA72-evm and AM57xx-beagle-x15 Changelog: v2 - Addressed review comments. - Fixed auto load of extcon-usb-gpio driver when used as module. - Fixed up AM57xx USB. -- cheers, -roger [1] - https://lkml.org/lkml/2014/11/3/513 Roger Quadros (7): extcon: usb-gpio: Introduce gpio usb extcon driver usb: extcon: Fix USB-Host cable name ARM: dts: dra7-evm: Add extcon nodes for USB ARM: dts: dra72-evm: Add extcon nodes for USB ARM: dts: am57xx-beagle-x15: Add extcon nodes for USB ARM: dts: am57xx-beagle-x15: Fix USB2 mode ARM: omap2plus_defconfig: Enable EXTCON_GPIO_USB .../devicetree/bindings/extcon/extcon-usb-gpio.txt | 20 ++ arch/arm/boot/dts/am57xx-beagle-x15.dts| 37 arch/arm/boot/dts/dra7-evm.dts | 31 +++ arch/arm/boot/dts/dra72-evm.dts| 31 +++ arch/arm/configs/omap2plus_defconfig | 1 + drivers/extcon/Kconfig | 7 + drivers/extcon/Makefile| 1 + drivers/extcon/extcon-palmas.c | 18 +- drivers/extcon/extcon-usb-gpio.c | 214 + drivers/usb/dwc3/dwc3-omap.c | 6 +- drivers/usb/phy/phy-omap-otg.c | 4 +- drivers/usb/phy/phy-tahvo.c| 8 +- 12 files changed, 360 insertions(+), 18 deletions(-) create mode 100644 Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt create mode 100644 drivers/extcon/extcon-usb-gpio.c -- 2.1.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
[PATCH v2 4/7] ARM: dts: dra72-evm: Add extcon nodes for USB
On this EVM, the USB cable state has to be determined via the
ID pin tied to a GPIO line. We use the gpio-usb-extcon driver
to read the ID pin and the extcon framework to forward
the USB cable state information to the USB driver so the
controller can be configured in the right mode (host/peripheral).
Gets USB peripheral mode to work on this EVM.
Signed-off-by: Roger Quadros
Reviewed-by: Felipe Balbi
Acked-by: Felipe Balbi
---
arch/arm/boot/dts/dra72-evm.dts | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 89085d0..ce8e243 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -8,6 +8,7 @@
/dts-v1/;
#include "dra72x.dtsi"
+#include
/ {
model = "TI DRA722";
@@ -24,6 +25,16 @@
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
};
+
+ extcon_usb1: extcon_usb1 {
+ compatible = "linux,extcon-usb-gpio";
+ id-gpio = <&pcf_gpio_21 1 GPIO_ACTIVE_HIGH>;
+ };
+
+ extcon_usb2: extcon_usb2 {
+ compatible = "linux,extcon-usb-gpio";
+ id-gpio = <&pcf_gpio_21 2 GPIO_ACTIVE_HIGH>;
+ };
};
&dra7_pmx_core {
@@ -243,6 +254,18 @@
ti,palmas-long-press-seconds = <6>;
};
};
+
+ pcf_gpio_21: gpio@21 {
+ compatible = "ti,pcf8575";
+ reg = <0x21>;
+ lines-initial-states = <0x1408>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
};
&uart1 {
@@ -345,6 +368,14 @@
phy-supply = <&ldo4_reg>;
};
+&omap_dwc3_1 {
+ extcon = <&extcon_usb1>;
+};
+
+&omap_dwc3_2 {
+ extcon = <&extcon_usb2>;
+};
+
&usb1 {
dr_mode = "peripheral";
pinctrl-names = "default";
--
2.1.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
[PATCH v2 3/7] ARM: dts: dra7-evm: Add extcon nodes for USB
On this EVM, the USB cable state has to be determined via the
ID pin tied to a GPIO line. We use the gpio-usb-extcon driver
to read the ID pin and the extcon framework to forward
the USB cable state information to the USB driver so the
controller can be configured in the right mode (host/peripheral).
Gets USB peripheral mode to work on this EVM.
Signed-off-by: Roger Quadros
Reviewed-by: Felipe Balbi
Acked-by: Felipe Balbi
---
arch/arm/boot/dts/dra7-evm.dts | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index ad4118f..746cddb 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -26,6 +26,16 @@
regulator-max-microvolt = <330>;
};
+ extcon_usb1: extcon_usb1 {
+ compatible = "linux,extcon-usb-gpio";
+ id-gpio = <&pcf_gpio_21 1 GPIO_ACTIVE_HIGH>;
+ };
+
+ extcon_usb2: extcon_usb2 {
+ compatible = "linux,extcon-usb-gpio";
+ id-gpio = <&pcf_gpio_21 2 GPIO_ACTIVE_HIGH>;
+ };
+
vtt_fixed: fixedregulator-vtt {
compatible = "regulator-fixed";
regulator-name = "vtt_fixed";
@@ -391,6 +401,19 @@
};
};
};
+
+ pcf_gpio_21: gpio@21 {
+ compatible = "ti,pcf8575";
+ reg = <0x21>;
+ lines-initial-states = <0x1408>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
};
&i2c2 {
@@ -520,6 +543,14 @@
};
};
+&omap_dwc3_1 {
+ extcon = <&extcon_usb1>;
+};
+
+&omap_dwc3_2 {
+ extcon = <&extcon_usb2>;
+};
+
&usb1 {
dr_mode = "peripheral";
pinctrl-names = "default";
--
2.1.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
[PATCH v2 5/7] ARM: dts: am57xx-beagle-x15: Add extcon nodes for USB
On this EVM, the USB cable state has to be determined via the
ID pin tied to a GPIO line. We use the gpio-usb-extcon driver
to read the ID pin and the extcon framework to forward
the USB cable state information to the USB driver so the
controller can be configured in the right mode (host/peripheral).
NOTE: the ports on this board cannot switch roles. They are
configured either host or peripheral by hardwiring the
respective ID pins.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/am57xx-beagle-x15.dts | 33 +
1 file changed, 33 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 49edbda..ad1833b 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -80,6 +80,20 @@
default-state = "off";
};
};
+
+ extcon_usb1: extcon_usb1 {
+ compatible = "linux,extcon-usb-gpio";
+ id-gpio = <&gpio7 25 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&extcon_usb1_pins>;
+ };
+
+ extcon_usb2: extcon_usb2 {
+ compatible = "linux,extcon-usb-gpio";
+ id-gpio = <&gpio7 24 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&extcon_usb2_pins>;
+ };
};
&dra7_pmx_core {
@@ -164,6 +178,17 @@
>;
};
+ extcon_usb1_pins: extcon_usb1_pins {
+ pinctrl-single,pins = <
+ 0x3ec (PIN_INPUT_PULLUP | MUX_MODE14) /*
uart1_rtsn.gpio7_25 */
+ >;
+ };
+
+ extcon_usb2_pins: extcon_usb2_pins {
+ pinctrl-single,pins = <
+ 0x3e8 (PIN_INPUT_PULLUP | MUX_MODE14) /*
uart1_ctsn.gpio7_24 */
+ >;
+ };
};
&i2c1 {
@@ -403,3 +428,11 @@
pinctrl-names = "default";
pinctrl-0 = <&usb1_pins>;
};
+
+&omap_dwc3_1 {
+ extcon = <&extcon_usb1>;
+};
+
+&omap_dwc3_2 {
+ extcon = <&extcon_usb2>;
+};
--
2.1.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
[PATCH v2 7/7] ARM: omap2plus_defconfig: Enable EXTCON_GPIO_USB
This driver is needed for USB cable type detection on dra7-evm, dra72-evm and am57xx-beagle-x15. Signed-off-by: Roger Quadros --- arch/arm/configs/omap2plus_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 667d9d5..7e10e58 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -326,6 +326,7 @@ CONFIG_DMADEVICES=y CONFIG_TI_EDMA=y CONFIG_DMA_OMAP=y CONFIG_EXTCON=y +CONFIG_EXTCON_USB_GPIO=m CONFIG_EXTCON_PALMAS=y CONFIG_PWM=y CONFIG_PWM_TIECAP=y -- 2.1.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
[PATCH v2 1/7] extcon: usb-gpio: Introduce gpio usb extcon driver
This driver observes the USB ID pin connected over a GPIO and
updates the USB cable extcon states accordingly.
The existing GPIO extcon driver is not suitable for this purpose
as it needs to be taught to understand USB cable states and it
can't handle more than one cable per instance.
For the USB case we need to handle 2 cable states.
1) USB (attach/detach)
2) USB-Host (attach/detach)
This driver can be easily updated in the future to handle VBUS
events in case it happens to be available on GPIO for any platform.
Signed-off-by: Roger Quadros
---
.../devicetree/bindings/extcon/extcon-usb-gpio.txt | 20 ++
drivers/extcon/Kconfig | 7 +
drivers/extcon/Makefile| 1 +
drivers/extcon/extcon-usb-gpio.c | 214 +
4 files changed, 242 insertions(+)
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
create mode 100644 drivers/extcon/extcon-usb-gpio.c
diff --git a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
new file mode 100644
index 000..ab52a85
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
@@ -0,0 +1,20 @@
+USB GPIO Extcon device
+
+This is a virtual device used to generate USB cable states from the USB ID pin
+connected to a GPIO pin.
+
+Required properties:
+- compatible: Should be "linux,extcon-usb-gpio"
+- id-gpio: gpio for USB ID pin. See gpio binding.
+
+Example:
+ extcon_usb1 {
+ compatible = "linux,extcon-usb-gpio";
+ id-gpio = <&gpio6 1 GPIO_ACTIVE_HIGH>;
+ }
+
+ usb@1 {
+ ...
+ extcon = <&extcon_usb1>;
+ ...
+ };
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index 6a1f7de..e4c01ab 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -93,4 +93,11 @@ config EXTCON_SM5502
Silicon Mitus SM5502. The SM5502 is a USB port accessory
detector and switch.
+config EXTCON_USB_GPIO
+ tristate "USB GPIO extcon support"
+ depends on GPIOLIB
+ help
+ Say Y here to enable GPIO based USB cable detection extcon support.
+ Used typically if GPIO is used for USB ID pin detection.
+
endif # MULTISTATE_SWITCH
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 0370b42..6a08a98 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
obj-$(CONFIG_EXTCON_PALMAS)+= extcon-palmas.o
obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o
obj-$(CONFIG_EXTCON_SM5502)+= extcon-sm5502.o
+obj-$(CONFIG_EXTCON_USB_GPIO) += extcon-usb-gpio.o
diff --git a/drivers/extcon/extcon-usb-gpio.c b/drivers/extcon/extcon-usb-gpio.c
new file mode 100644
index 000..a20aa39
--- /dev/null
+++ b/drivers/extcon/extcon-usb-gpio.c
@@ -0,0 +1,214 @@
+/**
+ * drivers/extcon/extcon_usb_gpio.c - USB GPIO extcon driver
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Roger Quadros
+ *
+ * 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
+#include
+
+#define USB_GPIO_DEBOUNCE_MS 20 /* ms */
+
+struct usb_extcon_info {
+ struct device *dev;
+ struct extcon_dev *edev;
+
+ struct gpio_desc *id_gpiod;
+ int id_irq;
+
+ unsigned long debounce_jiffies;
+ struct delayed_work wq_detcable;
+};
+
+/* List of detectable cables */
+enum {
+ EXTCON_CABLE_USB = 0,
+ EXTCON_CABLE_USB_HOST,
+
+ EXTCON_CABLE_END,
+};
+
+static const char *usb_extcon_cable[] = {
+ [EXTCON_CABLE_USB] = "USB",
+ [EXTCON_CABLE_USB_HOST] = "USB-Host",
+ NULL,
+};
+
+static void usb_extcon_detect_cable(struct work_struct *work)
+{
+ int id;
+ struct usb_extcon_info *info;
+
+ info = container_of(to_delayed_work(work), struct usb_extcon_info,
+wq_detcable);
+
+ /* check ID and update cable state */
+ id = gpiod_get_value_cansleep(info->id_gpiod);
+ if (id) {
+ /*
+* ID = 1 means USB HOST cable detached.
+* As we don't have event for USB peripheral cable attached,
+* we simulate USB peripheral attach here.
+*/
+ extcon_set_cable_state(info->edev,
+ usb_extcon_cable[EXTCON_CABL
Re: Control message failures kill entire XHCI stack
On 26.01.2015 05:37, Devin Heitmueller wrote: > Hi Mathias, > > Here's an interesting development: as a result of a related thread on > linux-media, I came across a patch they are distributing in openelec: > > https://github.com/OpenELEC/OpenELEC.tv/commit/b636927dec20652ff020e54ed7838a2e9be51e03 > > Now I'm not saying that reverting the commit in question is the > "right" thing to do, but I applied this patch and for the first time > in 100+ tests it started to work (i.e. I'm not seeing the XHCI hcd > tear down all the attached devices). > > Given what I've seen of the bug I cannot really explain why the > scatter gather list sizes would have any bearing on TRBs for USB > control messages to be added to the queue. Perhaps we're hitting the > upper bound of the list? Any further speculation on my part would > just make me look clueless... > > It would be great if you could offer any insight as to why the patch > in question could be responsible for the behavior we're seeing. I > would really rather not just blindly check this patch into my local > tree and declare "victory" without understanding the underlying issue > and whether it's likely to cause other problems. > Hi Thanks for digging this info out. I'm starting to think maybe there could be something wrong in the ring expansion, or ring memory management in general. The failed control endpoint stopping was preceeded by a ring expansion, (in all the logs I got) If the ring expansion already kills xhci it would explain why we never see the control message on the bus. The patch you show increases the TRB_PER_SEGMENT size from 64 to 256, this again reduces the need for ring expansion as each segment is already four times bigger initially. Another thing pointing to ring memory management is the additional checks I added printing: "Cancelled TD not on stopped ring" "Cancel URB NOT on current ring" Hitting these means that the the urb we want to cancel points to a segment that is no longer part of that endpoints ring. But we still alter the memory of that segment. We cache, free, and re-use segments as endpoints are dropped and added, or rings expanded. We might have randomly altered a segment that just got used by another ring after a ring expansion. Atleast thats a new theory. I need to do more hacking -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8] usb: dwc3: add ULPI interface support
On Fri, Jan 23, 2015 at 10:24:43AM -0600, Felipe Balbi wrote:
> On Fri, Jan 23, 2015 at 05:12:56PM +0200, Heikki Krogerus wrote:
> > +int dwc3_ulpi_init(struct dwc3 *dwc)
> > +{
> > + u32 reg;
> > +
> > + /* First check USB2 PHY interface type */
> > + switch (DWC3_GHWPARAMS3_HSPHY_IFC(dwc->hwparams.hwparams3)) {
> > + case DWC3_GHWPARAMS3_HSPHY_IFC_UTMI_ULPI:
> > + /* Select ULPI Interface */
> > + reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
> > + reg |= DWC3_GUSB2PHYCFG_ULPI_UTMI;
> > + dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
> > + /* FALLTHROUGH */
> > + case DWC3_GHWPARAMS3_HSPHY_IFC_ULPI:
> > + break;
> > + default:
> > + return 0;
> > + }
> > +
> > + /* Register the interface */
> > + dwc->ulpi = ulpi_register_interface(dwc->dev, &dwc3_ulpi);
> > + if (IS_ERR(dwc->ulpi)) {
>
> so, this will only build and link if DWC3_ULPI is enabled, in case of
> error you return early...
>
> > + dev_err(dwc->dev, "failed to register ULPI interface");
> > + return PTR_ERR(dwc->ulpi);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +void dwc3_ulpi_exit(struct dwc3 *dwc)
> > +{
> > + if (dwc->ulpi) {
>
> ... looks like this branch is unnecessary.
We can't do that, or distros that select DWC3_ULPI option can only use
dwc3 with hardware that really has ULPI PHY. So I guess we'll drop the
DWC3_ULPI option and build the dwc3 ulpi support always if ULPI bus is
enabled. OK?
Thanks,
--
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: os desc fix
Hi Mario, W dniu 23.01.2015 o 21:52, Mario Schuknecht pisze: Add missing case USB_EXT_PROP_UNICODE_MULTI to fill_ext_prop. Type vendor is coded in bRequestType. Compare USB_TYPE_VENDOR with bRequestType instead of bRequest. The above seem to be unrelated changes. Please split into two separate patches, but see below. Signed-off-by: Mario Schuknecht --- drivers/usb/gadget/composite.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c index 6178353..3f7227b 100644 --- a/drivers/usb/gadget/composite.c +++ b/drivers/usb/gadget/composite.c @@ -1418,6 +1418,7 @@ static int fill_ext_prop(struct usb_configuration *c, int interface, u8 *buf) case USB_EXT_PROP_UNICODE: case USB_EXT_PROP_UNICODE_ENV: case USB_EXT_PROP_UNICODE_LINK: + case USB_EXT_PROP_UNICODE_MULTI: usb_ext_prop_put_unicode(buf, ret, ext_prop->data, ext_prop->data_len); While USB_EXT_PROP_UNICODE, USB_EXT_PROP_UNICODE_ENV and USB_EXT_PROP_UNICODE_LINK are defined as "A NULL-terminated Unicode string", USB_EXT_PROP_UNICODE_MULTI is defined as "Multiple NULL-terminated Unicode strings" - note the plural here. usb_ext_prop_put_unicode() internally calls utf8s_to_utf16s() and it seems that the latter is not designed to handle multiple strings in sequence. So I guess that either you should add a separate case or modify usb_ext_prop_unicode(). I'd prefer the first option and there perhaps usb_ext_prop_put_unicode() should be called in a loop. AP -- 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: Control message failures kill entire XHCI stack
On Mon, Jan 26, 2015 at 4:37 AM, Devin Heitmueller wrote: > Hi Mathias, > > Here's an interesting development: as a result of a related thread on > linux-media, I came across a patch they are distributing in openelec: > > https://github.com/OpenELEC/OpenELEC.tv/commit/b636927dec20652ff020e54ed7838a2e9be51e03 > > Now I'm not saying that reverting the commit in question is the > "right" thing to do, but I applied this patch and for the first time > in 100+ tests it started to work (i.e. I'm not seeing the XHCI hcd > tear down all the attached devices). > > Given what I've seen of the bug I cannot really explain why the > scatter gather list sizes would have any bearing on TRBs for USB > control messages to be added to the queue. Perhaps we're hitting the > upper bound of the list? Any further speculation on my part would > just make me look clueless... > > It would be great if you could offer any insight as to why the patch > in question could be responsible for the behavior we're seeing. I > would really rather not just blindly check this patch into my local > tree and declare "victory" without understanding the underlying issue > and whether it's likely to cause other problems. Just as another point of data... I applied the patch to Mathias for-usb-next-test branch and was able to record video and audio through the Live2 for the first time using the xhci stack. Attempting to record a second video resulted in mythffmpeg returning: [alsa @ 0xbf6560] cannot open audio device plughw:CARD=Cx231xxAudio,DEV=0 (Device or resource busy) plughw:CARD=Cx231xxAudio,DEV=0: Input/output error I also get this error on the older hardware running ehci, although it can be recovered by removing and re-inserting the Live2. Attempting to do this under xhci resulted in usb locking up somehow, lsusb never returned. syslog file at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1412121/+attachment/4305645/+files/2015-01-26-syslog-14.10-3.19rc5akg0.1.log Thanks again to you both, Alistair -- 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 net-next 1/7] r8152: adjust rx_bottom
On Mon, Jan 19, 2015 at 6:48 PM, Hayes Wang wrote:
> David Miller [mailto:da...@davemloft.net]
>> Sent: Tuesday, January 20, 2015 5:14 AM
> [...]
>> >> - r8152_submit_rx(tp, agg, GFP_ATOMIC);
>> >> + if (!ret) {
>> >> + ret = r8152_submit_rx(tp, agg, GFP_ATOMIC);
>> >> + } else {
>> >> + urb->actual_length = 0;
>> >> + list_add_tail(&agg->list, next);
>> >
>> > Do you need a spin_lock_irqsave(&tp->rx_lock, flags) around this?
>>
>> Indeed, and rtl_start_rx() seems to also access agg->list without
>> proper locking.
>
> It is unnecessary because I deal with them in a local list_head. My steps are
>1. Move the whole list from tp->rx_done to local rx_queue. (with spin lock)
>2. dequeue/enqueue the lists in rx_queue.
>3. Move the lists in rx_queue to tp->rx_done if it is necessary. (spin
> lock)
> For step 2, it wouldn't have race, because the list_head is local and no other
> function would change it. Therefore, I don't think it needs the spin lock.
Sorry guys, I think I made a mistake in my review and caused some
confusion/grief.
My mistake was getting the params to list_add_tail() backwards. It's
list_add_tail(entry, head). I saw list_add_tail(&agg->list, next) and
was fooled into thinking agg->list was the list getting appended with
the entry 'next'. It's the opposite. Duh. So locking isn't needed
because the list is indeed local.
-scott
--
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/2] usb: musb: try a race-free wakeup
On 01/21/2015 06:06 PM, Bin Liu wrote: > Hi Sebastian, Hi Bin, > With this patch, hubs stop working on TI AM335x EVMs when autosuspend > is enabled. > > I booted the board, connected a hub to the USB1 host port, it got > enumerated properly, then connected a thumb drive to the hub, but the > drive was not enumerated, no any log from kernel. Removing the drive, > no any kernel message either. Finally removed the hub, no disconnect > for the hub. Now check MUSB1 DEVCTL register, it value is 0x5D. > > Reverted this patch, the issue disappeared. Or disable usbcore > autosuspend, the issue did not happen. > > I tested 7+ hubs, all have the same issue. > > I tested on git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git, tag > ti2014.10.01. have not tested with mainline kernel yet. > > Have you validated this test case? No, I had no USB-hub attached. It would be nice if you could figure out which part is responsible for the missing detection because otherwise suspend/resume is broken. > Thanks, > -Bin. Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
