gadgetfs regression: module refcount bug since 3.10
gadgetfs has had a module refcount bug in all recent kernels, from v3.10 up through present. I realize that gadgetfs is deprecated in favor of functionfs nowadays, but probably you will want to fix it anyways since gadgetfs is still in the tree. The refcount bug can be reproduced with the following test case (tried on both ARM and x86-64): * build gadgetfs as module, build gadgetfs example app from http://www.linux-usb.org/gadget/usb.c * run test script modprobe dummy_hcd modprobe gadgetfs mkdir -p /dev/gadget mount -t gadgetfs none /dev/gadget lsmod | grep gadgetfs # this will show usage 1, as expected ./usb lsmod | grep gadgetfs # still shows usage 1 * now when example app is killed, gadgetfs usage count goes from 1 down to 0 (despite still being mounted) * in fact, the usage count is decremented every time a process exits after using gadgetfs (meaning it goes negative on the 2nd exit) Some poking around showed fops_put() in __fput() being the guilty party for decrementing the refcount on process exit, which was an unbalanced module put because running the process didn't do a module get. More time spent with git-bisect showed that commit 3273097ee9c077 "gadgetfs: don't bother with fops->owner" was the one that caused the regression. Simply reverting that commit restores old behavior with balanced gets and puts: opening gadgetfs files increments the module refcount, closing them decrements it. -- 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 v2] r8152: reduce the number of Tx
From: Hayes Wang Date: Mon, 1 Sep 2014 02:46:38 + > From: David Miller [mailto:da...@davemloft.net] > [...] >> This driver has a loop that iterates MAX_TX times to initialize both >> the RX and TX buffers. >> >> So if they are not equal, it can't possibly work. > > Excuse me. I don't find that the "RTL8152_MAX_TX" is used by > rx buffer. The rx buffer only use "RTL8152_MAX_RX". Although > the tx buffer size is determined by "rx_buf_sz", the tx buffers > are independent of rx buffers. Ok, but that is really confusing code. -- 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 v2] r8152: reduce the number of Tx
From: David Miller [mailto:da...@davemloft.net] [...] > This driver has a loop that iterates MAX_TX times to initialize both > the RX and TX buffers. > > So if they are not equal, it can't possibly work. Excuse me. I don't find that the "RTL8152_MAX_TX" is used by rx buffer. The rx buffer only use "RTL8152_MAX_RX". Although the tx buffer size is determined by "rx_buf_sz", the tx buffers are independent of rx buffers. Best Regards, Hayes -- 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 1/2] USB: OTG: Hold wakeupsource when VBUS present
On Fri, Aug 22, 2014 at 03:19:32PM +0530, Kiran Kumar Raparthy wrote:
> From: Todd Poynor
>
> USB: OTG: Hold wakeupsource when VBUS present
>
It is not related to OTG, would you change a name?
> Enabled by default, can disable with:
>echo N > /sys/module/otg_wakeupsource/parameters/enabled
>
> This is one of the number of patches from the Android AOSP common.git tree,
> which is used on almost all Android devices. so I wanted to submit it for
> review to see if it should go upstream.
>
> Cc: Felipe Balbi
> Cc: Greg Kroah-Hartman
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-usb@vger.kernel.org
> Cc: Android Kernel Team
> Cc: John Stultz
> Cc: Arve Hj�nnev�g
> Cc: Benoit Goby
> Signed-off-by: Todd Poynor
> Signed-off-by: Kiran Raparthy
> [kiran: Added context to commit message
> Included build fix from Benoit Goby and Arve Arve Hj�nnev�g
> Removed lock->held field in driver as this mechanism is provided in
> wakeup.c
> wakelock(wl) terminology replaced with wakeup_source(ws)
> sys entry(module param) field modified to otg_wakeupsource
> __pm_stay_awake and __pm_relax called directly from the main
> code instead of calling them via otgws_grab,otgws_drop]
> ---
> drivers/usb/phy/Kconfig| 8 ++
> drivers/usb/phy/Makefile | 1 +
> drivers/usb/phy/otg-wakeupsource.c | 171
> +
> 3 files changed, 180 insertions(+)
> create mode 100644 drivers/usb/phy/otg-wakeupsource.c
>
> diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
> index e253fa0..9c747b2 100644
> --- a/drivers/usb/phy/Kconfig
> +++ b/drivers/usb/phy/Kconfig
> @@ -6,6 +6,14 @@ menu "USB Physical Layer drivers"
> config USB_PHY
> def_bool n
>
> +config USB_OTG_WAKEUPSOURCE
> + bool "Hold a wakeupsource when USB connected"
> + depends on PM_SLEEP
> + select USB_PHY
> + help
> + Select this to automatically hold a wakeupsource when USB is
> + connected, preventing suspend.
> +
I think it is a common driver, the UDC drivers are its best user, we
may only want to prevent the system entering suspend after UDC get
enumerated, not only just vbus is present, the PHY driver should not know
the UDC get enumerated or not, the state of enumeration belongs to
chapter 9 at USB 2.0 spec.
Peter
> #
> # USB Transceiver Drivers
> #
> diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
> index 24a9133..ca2fbaf 100644
> --- a/drivers/usb/phy/Makefile
> +++ b/drivers/usb/phy/Makefile
> @@ -3,6 +3,7 @@
> #
> obj-$(CONFIG_USB_PHY)+= phy.o
> obj-$(CONFIG_OF) += of.o
> +obj-$(CONFIG_USB_OTG_WAKEUPSOURCE) += otg-wakeupsource.o
>
> # transceiver drivers, keep the list sorted
>
> diff --git a/drivers/usb/phy/otg-wakeupsource.c
> b/drivers/usb/phy/otg-wakeupsource.c
> new file mode 100644
> index 000..fa44e11
> --- /dev/null
> +++ b/drivers/usb/phy/otg-wakeupsource.c
> @@ -0,0 +1,171 @@
> +/*
> + * otg-wakeupsource.c
> + *
> + * Copyright (C) 2011 Google, Inc.
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static bool enabled = true;
> +static struct usb_phy *otgws_xceiv;
> +static struct notifier_block otgws_nb;
> +
> +
> +static DEFINE_SPINLOCK(otgws_spinlock);
> +
> +/*
> + * Only one lock, but since these 2 fields are associated with each other...
> + */
> +
> +struct otgws_lock {
> + char name[40];
> + struct wakeup_source wsource;
> +};
> +
> +/*
> + * VBUS present lock.
> + */
> +
> +static struct otgws_lock vbus_lock;
> +
> +static int otgws_otg_notifications(struct notifier_block *nb,
> +unsigned long event, void *unused)
> +{
> + unsigned long irqflags;
> +
> + if (!enabled)
> + return NOTIFY_OK;
> +
> + spin_lock_irqsave(&otgws_spinlock, irqflags);
> +
> + switch (event) {
> + case USB_EVENT_VBUS:
> + case USB_EVENT_ENUMERATED:
> + __pm_stay_awake(&vbus_lock.wsource);
> + break;
> +
> + case USB_EVENT_NONE:
> + case USB_EVENT_ID:
> + case USB_EVENT_CHARGER:
> + __pm_relax(&vbus_lock.wsource);
> + break;
> +
> + default:
> + break;
> + }
> +
> + spin_unlock_irqrestore(&otgws_spinlock, irqflags);
> + return NOTIFY_OK;
> +}
> +
> +static void sync_with_xceiv_state(void)
> +{
> + if ((otgws_xceiv->last_event == USB_
Re: [PATCH v3 8/9] usb: chipidea: move usb_otg into struct ci_hdrc
On Fri, Aug 29, 2014 at 04:25:35PM +0200, Antoine Tenart wrote:
> Hi,
>
> On Tue, Aug 26, 2014 at 06:22:40PM +0800, Peter Chen wrote:
> > On Fri, Aug 22, 2014 at 05:50:19PM +0200, Antoine Ténart wrote:
> >
> > If the common usb_otg and usb_phy struct still has another's pointer, you
> > may not need to add this patch.
>
> Except if we want to access the OTG member when not using an USB PHY.
If there is no USB PHY, the probe at core.c will turn error.
>
> > > diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
> > > index 0b67d78dd953..0952d4adfa4c 100644
> > > --- a/drivers/usb/chipidea/host.c
> > > +++ b/drivers/usb/chipidea/host.c
> > > @@ -85,13 +85,11 @@ static int host_start(struct ci_hdrc *ci)
> > > if (ret) {
> > > goto disable_reg;
> > > } else {
> > > - struct usb_otg *otg = ci->usb_phy->otg;
> > > + struct usb_otg *otg = &ci->otg;
> > >
> > > ci->hcd = hcd;
> > > - if (otg) {
> > > - otg->host = &hcd->self;
> > > - hcd->self.otg_port = 1;
> > > - }
> > > + otg->host = &hcd->self;
> > > + hcd->self.otg_port = 1;
> > > }
> >
> > You may need use other way to identify if otg is supported or not
>
> How would you do that?
ci_otg_is_fsm_mode(ci)
>
> > > - otg->usb_phy = ci->usb_phy;
> > > - otg->gadget = &ci->gadget;
> > > - ci->fsm.otg = otg;
> > > - ci->usb_phy->otg = ci->fsm.otg;
> > > + ci->otg.usb_phy = ci->usb_phy;
> > > + ci->fsm.otg = &ci->otg;
> > > ci->fsm.power_up = 1;
> > > ci->fsm.id = hw_read_otgsc(ci, OTGSC_ID) ? 1 : 0;
> > > ci->fsm.otg->state = OTG_STATE_UNDEFINED;
> >
> > Why otg->gadget and ci->usb_phy->otg initialization are deleted?
> > At least, the parameters of usb_otg_state_string at your 7th patch uses it.
>
> Sure, I'll fix this
>
> Antoine
>
> --
> Antoine Ténart, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
--
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
[PATCH v2 1/1] USB: Add device quirk for ASUS T100 Base Station keyboard
This full-speed USB device generates spurious remote wakeup event
as soon as USB_DEVICE_REMOTE_WAKEUP feature is set. As the result,
Linux can't enter system suspend and S0ix power saving modes once
this keyboard is used.
This patch tries to introduce USB_QUIRK_IGNORE_REMOTE_WAKEUP quirk.
With this quirk set, wakeup capability will be ignored during
device configure.
This patch could be back-ported to kernels as old as 2.6.39.
Signed-off-by: Lu Baolu
---
drivers/usb/core/hub.c | 6 --
drivers/usb/core/quirks.c | 4
include/linux/usb/quirks.h | 3 +++
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 8a4dcbc..5df1457 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1977,8 +1977,10 @@ void usb_set_device_state(struct usb_device *udev,
|| new_state == USB_STATE_SUSPENDED)
; /* No change to wakeup settings */
else if (new_state == USB_STATE_CONFIGURED)
- wakeup = udev->actconfig->desc.bmAttributes
-& USB_CONFIG_ATT_WAKEUP;
+ wakeup = (udev->quirks &
+ USB_QUIRK_IGNORE_REMOTE_WAKEUP) ? 0 :
+ udev->actconfig->desc.bmAttributes &
+ USB_CONFIG_ATT_WAKEUP;
else
wakeup = 0;
}
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index bae636e..e7d1e3c 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -159,6 +159,10 @@ static const struct usb_device_id usb_quirk_list[] = {
/* USB3503 */
{ USB_DEVICE(0x0424, 0x3503), .driver_info = USB_QUIRK_RESET_RESUME },
+ /* ASUS Base Station(T100) */
+ { USB_DEVICE(0x0b05, 0x17e0), .driver_info =
+ USB_QUIRK_IGNORE_REMOTE_WAKEUP },
+
{ } /* terminating entry must be last */
};
diff --git a/include/linux/usb/quirks.h b/include/linux/usb/quirks.h
index 55a17b1..0f784c3 100644
--- a/include/linux/usb/quirks.h
+++ b/include/linux/usb/quirks.h
@@ -41,4 +41,7 @@
*/
#define USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL 0x0080
+/* device generates spurious wakeup, ignore remote wakeup capability */
+#define USB_QUIRK_IGNORE_REMOTE_WAKEUP 0x0100
+
#endif /* __LINUX_USB_QUIRKS_H */
--
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: [RFC PATCH 0/7] usb: gadget: add reset API at usb_gadget_driver
On Fri, Aug 29, 2014 at 04:20:20PM -0500, Felipe Balbi wrote: > On Fri, Aug 29, 2014 at 05:08:13PM -0400, Alan Stern wrote: > > On Fri, 29 Aug 2014, Felipe Balbi wrote: > > > > > > First, change the API so that the disconnect API _does_ call > > > > usb_gadget_disconnect. > > > > > > that's not what the API was intended for, however. If we're going down > > > that path, we need another of telling the gadget driver to reset all its > > > buffers and teardown all its requests without disconnecting pullups, > > > maybe that's what ->reset() would be for. > > > > Just so. The disconnect handler should basically do the same thing as > > the reset handler, plus turn off the pullup. > > > > I still have some old patch files lying around, adding reset callback > > support to dummy-hcd, net2280, and net2272. Would you like me to post > > them? > > Please do :-) let's get all of that sorted out soon. > Felipe, would you agree with we have a reset API at usb_gadget_driver, and call usb_gadget_disconnet at .disconnect if the flag pullup_on_vbus is set? -- 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: [RFC PATCH 0/7] usb: gadget: add reset API at usb_gadget_driver
On Fri, Aug 29, 2014 at 11:14:23AM -0400, Alan Stern wrote: > On Fri, 29 Aug 2014, Peter Chen wrote: > > > Felipe & Alan, thanks for your comments for these patches, I think I may > > need > > to list these issues again to make things clearer. > > > > The purpose of these patchsets are to fix two issues: > > - Some udcs failures at USB-IF certification Back-Voltage test, it needs > > the dp is not pulled up when the vbus is not there, usb 2.0 spec 7.2.1 > > and 7.1.5 require it. > > - Some function drivers (f_uvc, f_obex, and android functions later) do > > not want to pull up dp at the udc_start, they want it on demand, like app > > has run. > > > > So, we can't pull up dp unconditionally at udc-core, I proposal the strategy > > for pulling up dp after below two conditions are satisfied [1]: > > - If the udc is ready to pull up dp > > - all functions at gadget driver want to pullup dp, it will pull up dp. > > > > The first condition depends on UDCs, Some UDCs(UDC-A) doesn't need to > > clear software pull up(run/stop) bit after vbus has disconnected, > > the possible reason may these kinds of UDC have hardware logic to disable > > pullup at dp when the vbus is not there, then it can pass back-voltage test, > > so for these kinds of UDCs, they are always ready to pull up dp. > > But for other UDCs(UDC-B, like chipidea), it needs to clear pullup bit after > > vbus has disconnected to pass back-voltage test, for these kinds of UDCs, > > they > > are only ready to pull up dp when the vbus is there. > > The second condition are the same for all UDCs, the function/gadget driver > > determine it. > > > > The patchset[1] has implemented above idea, UDC-A is always ready to pull up > > dp, it will set ready (connect) bit at the end of udc_start, and UDC-B will > > be ready when the vbus is there.[2], and the dp control strategy is decided > > by > > two conditions[3]. > > > > Alan concerns why the .connect API has **connect** argument, the reason > > is we need to call it at vbus handler to disable pullup bit when the vbus > > is not there. It is indeed strange we have **connect** argument at .connect, > > but current .disconnect API does not call usb_gadget_disconnect, so we have > > no way to pull down dp when the vbus is not there, that is the story > > we have this patchset and discussion. > > > > What's the next step for me? > > First, change the API so that the disconnect API _does_ call > usb_gadget_disconnect. > > Then change the gadget drivers so that they tell the UDC driver when to > turn the pullup on or off. This should happen whenever a function is > activated or deactivated or whenever a connect or disconnect occurs. > > (In theory the gadget driver does not need to tell the UDC driver to > turn off the pullup when a disconnect occurs; the UDC driver will turn > it off anyway. But the gadget driver still needs to know that there > was a disconnect. Otherwise it might tell the UDC driver to turn on > the pullup at a time when the device isn't connected.) > It is better gadget driver tells the UDC driver (with vbus handler) to turn off the pullup when a disconnect occurs, in that case, we can remove all pull up/down dp code from UDC drivers. -- 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 6/9] usb: xhci: Add NVIDIA Tegra xHCI host-controller driver
On Sat, Aug 30, 2014 at 2:15 PM, Greg Kroah-Hartman
wrote:
> On Mon, Aug 18, 2014 at 10:08:22AM -0700, Andrew Bresticker wrote:
>> Add support for the on-chip xHCI host controller present on Tegra SoCs.
>>
>> The driver is currently very basic: it loads the controller with its
>> firmware, starts the controller, and is able to service messages sent
>> by the controller's firmware. The hardware supports device mode as
>> well as lower-power operating modes, but support for these is not yet
>> implemented here.
>
> So you are saying the device doesn't really work? Can it handle USB
> transactions properly?
Huh? It's just as functional as any other xHCI platform host.
Perhaps I should have been more clear about "lower-power operating
modes": this refers to the runtime powergating of the controller's
SuperSpeed and host-controller logic and has nothing to do with USB
link/hub/device power management.
> I have a jetson board here, is this the controller for that hardware?
> Can I test this series on that platform, or is it for something else?
Yup, that's the platform I primarily used for testing this series.
>> +static const struct tegra_xhci_soc_config tegra124_soc_config = {
>> + .firmware_file = "nvidia/tegra124/xusb.bin",
>> +};
>> +MODULE_FIRMWARE("nvidia/tegra124/xusb.bin");
>
> Has this file been submitted to the linux-firmware tree?
It has been posted, see https://patchwork.ozlabs.org/patch/384013/
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 3/4] usb: gadget: pxa27x_udc: use devm_* helpers
Use devm_* helpers in the probe function to simplify the error path and
the remove path.
Signed-off-by: Robert Jarzmik
Cc: Sergei Shtylyov
---
Since V1: Addressed Sergei's comments
Since V2: Addressed Sergei's comments on includes
Since V4: Addressed Sergei's comment on clk_uprepare in probe() function
---
drivers/usb/gadget/udc/pxa27x_udc.c | 53 +++--
1 file changed, 15 insertions(+), 38 deletions(-)
diff --git a/drivers/usb/gadget/udc/pxa27x_udc.c
b/drivers/usb/gadget/udc/pxa27x_udc.c
index 42f4929..3c1ba78 100644
--- a/drivers/usb/gadget/udc/pxa27x_udc.c
+++ b/drivers/usb/gadget/udc/pxa27x_udc.c
@@ -2477,8 +2477,9 @@ static int pxa_udc_probe(struct platform_device *pdev)
pxa_udc_probe_pdata(pdev, udc);
regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!regs)
- return -ENXIO;
+ udc->regs = devm_ioremap_resource(&pdev->dev, regs);
+ if (IS_ERR(udc->regs))
+ return PTR_ERR(udc->regs);
udc->irq = platform_get_irq(pdev, 0);
if (udc->irq < 0)
return udc->irq;
@@ -2487,7 +2488,8 @@ static int pxa_udc_probe(struct platform_device *pdev)
udc->transceiver = usb_get_phy(USB_PHY_TYPE_USB2);
if (gpio_is_valid(udc->gpio_pullup)) {
- retval = gpio_request(udc->gpio_pullup, "USB D+ pullup");
+ retval = devm_gpio_request(&pdev->dev,
+ udc->gpio_pullup, "USB D+ pullup");
if (retval == 0)
gpio_direction_output(udc->gpio_pullup,
udc->gpio_pullup_inverted);
@@ -2498,21 +2500,13 @@ static int pxa_udc_probe(struct platform_device *pdev)
return retval;
}
- udc->clk = clk_get(&pdev->dev, NULL);
- if (IS_ERR(udc->clk)) {
- retval = PTR_ERR(udc->clk);
- goto err_clk;
- }
+ udc->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(udc->clk))
+ return PTR_ERR(udc->clk);
+
retval = clk_prepare(udc->clk);
if (retval)
- goto err_clk_prepare;
-
- retval = -ENOMEM;
- udc->regs = ioremap(regs->start, resource_size(regs));
- if (!udc->regs) {
- dev_err(&pdev->dev, "Unable to map UDC I/O memory\n");
- goto err_map;
- }
+ return retval;
udc->vbus_sensed = 0;
@@ -2522,34 +2516,23 @@ static int pxa_udc_probe(struct platform_device *pdev)
pxa_eps_setup(udc);
/* irq setup after old hardware state is cleaned up */
- retval = request_irq(udc->irq, pxa_udc_irq,
- IRQF_SHARED, driver_name, udc);
+ retval = devm_request_irq(&pdev->dev, udc->irq, pxa_udc_irq,
+ IRQF_SHARED, driver_name, udc);
if (retval != 0) {
dev_err(udc->dev, "%s: can't get irq %i, err %d\n",
driver_name, udc->irq, retval);
- goto err_irq;
+ goto err;
}
retval = usb_add_gadget_udc(&pdev->dev, &udc->gadget);
if (retval)
- goto err_add_udc;
+ goto err;
pxa_init_debugfs(udc);
return 0;
-
-err_add_udc:
- free_irq(udc->irq, udc);
-err_irq:
- iounmap(udc->regs);
-err_map:
+err:
clk_unprepare(udc->clk);
-err_clk_prepare:
- clk_put(udc->clk);
- udc->clk = NULL;
-err_clk:
- if (gpio_is_valid(udc->gpio_pullup))
- gpio_free(udc->gpio_pullup);
return retval;
}
@@ -2560,22 +2543,16 @@ err_clk:
static int pxa_udc_remove(struct platform_device *_dev)
{
struct pxa_udc *udc = platform_get_drvdata(_dev);
- int gpio = udc->mach->gpio_pullup;
usb_del_gadget_udc(&udc->gadget);
usb_gadget_unregister_driver(udc->driver);
- free_irq(udc->irq, udc);
pxa_cleanup_debugfs(udc);
- if (gpio_is_valid(gpio))
- gpio_free(gpio);
usb_put_phy(udc->transceiver);
udc->transceiver = NULL;
the_controller = NULL;
clk_unprepare(udc->clk);
- clk_put(udc->clk);
- iounmap(udc->regs);
return 0;
}
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 2/4] usb: gadget: pxa27x_udc device-tree documentation
Add documentation for device-tree binding of arm PXA 27x udc (usb
device) driver.
Signed-off-by: Robert Jarzmik
Cc: devicet...@vger.kernel.org
---
Since V1: change OF id mrvl,pxa27x_udc -> marvell,pxa27x-udc
This is a consequence of other DT reviews on the marvell
namings.
Since V2: Mark's review
- described standard properties
- use standard gpio bindings for pullup gpio
Since V3: Arnd's review
- removed clock-names
---
Documentation/devicetree/bindings/usb/pxa-usb.txt | 22 ++
1 file changed, 22 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/pxa-usb.txt
b/Documentation/devicetree/bindings/usb/pxa-usb.txt
index 79729a9..9c33179 100644
--- a/Documentation/devicetree/bindings/usb/pxa-usb.txt
+++ b/Documentation/devicetree/bindings/usb/pxa-usb.txt
@@ -29,3 +29,25 @@ Example:
marvell,port-mode = <2>; /* PMM_GLOBAL_MODE */
};
+UDC
+
+Required properties:
+ - compatible: Should be "marvell,pxa270-udc" for USB controllers
+ used in device mode.
+ - reg: usb device MMIO address space
+ - interrupts: single interrupt generated by the UDC IP
+ - clocks: input clock of the UDC IP (see clock-bindings.txt)
+
+Optional properties:
+ - gpios:
+ - gpio activated to control the USB D+ pullup (see gpio.txt)
+
+Example:
+
+ pxa27x_udc: udc@4060 {
+ compatible = "marvell,pxa270-udc";
+ reg = <0x4060 0x1>;
+ interrupts = <11>;
+ clocks = <&pxa2xx_clks 11>;
+ gpios = <&gpio 22 GPIO_ACTIVE_LOW>;
+ };
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 4/4] usb: gadget: pxa27x_udc: fix clock prepare and enable
As the udc clock controls both the output signals and the internal IP,
it must be enabled before any UDC register is touched.
The bug is revealed when the clock framework disables the clock for a
couple of milliseconds during the boot sequence, and the endpoint
configuration is lost. The bug is hidden when clock framework is not
used, because no "unused clocks disable" occurs.
This patch fixes the wrong behaviour by ensuring that :
- whenever a UDC register is read or written, the clock is enabled
- reworks the endpoints programming to have it done under running clock
- reworks suspend/resume to ensure the same thing
Signed-off-by: Robert Jarzmik
---
drivers/usb/gadget/udc/pxa27x_udc.c | 26 +-
1 file changed, 5 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/gadget/udc/pxa27x_udc.c
b/drivers/usb/gadget/udc/pxa27x_udc.c
index 3c1ba78..9506da8 100644
--- a/drivers/usb/gadget/udc/pxa27x_udc.c
+++ b/drivers/usb/gadget/udc/pxa27x_udc.c
@@ -1704,10 +1704,10 @@ static void udc_disable(struct pxa_udc *udc)
udc_writel(udc, UDCICR1, 0);
udc_clear_mask_UDCCR(udc, UDCCR_UDE);
- clk_disable(udc->clk);
ep0_idle(udc);
udc->gadget.speed = USB_SPEED_UNKNOWN;
+ clk_disable(udc->clk);
udc->enabled = 0;
}
@@ -1760,16 +1760,16 @@ static void udc_enable(struct pxa_udc *udc)
if (udc->enabled)
return;
+ clk_enable(udc->clk);
udc_writel(udc, UDCICR0, 0);
udc_writel(udc, UDCICR1, 0);
udc_clear_mask_UDCCR(udc, UDCCR_UDE);
- clk_enable(udc->clk);
-
ep0_idle(udc);
udc->gadget.speed = USB_SPEED_FULL;
memset(&udc->stats, 0, sizeof(udc->stats));
+ pxa_eps_setup(udc);
udc_set_mask_UDCCR(udc, UDCCR_UDE);
ep_write_UDCCSR(&udc->pxa_ep[0], UDCCSR0_ACM);
udelay(2);
@@ -2513,7 +2513,6 @@ static int pxa_udc_probe(struct platform_device *pdev)
the_controller = udc;
platform_set_drvdata(pdev, udc);
udc_init_data(udc);
- pxa_eps_setup(udc);
/* irq setup after old hardware state is cleaned up */
retval = devm_request_irq(&pdev->dev, udc->irq, pxa_udc_irq,
@@ -2529,7 +2528,8 @@ static int pxa_udc_probe(struct platform_device *pdev)
goto err;
pxa_init_debugfs(udc);
-
+ if (should_enable_udc(udc))
+ udc_enable(udc);
return 0;
err:
clk_unprepare(udc->clk);
@@ -2582,19 +2582,11 @@ extern void pxa27x_clear_otgph(void);
*/
static int pxa_udc_suspend(struct platform_device *_dev, pm_message_t state)
{
- int i;
struct pxa_udc *udc = platform_get_drvdata(_dev);
struct pxa_ep *ep;
ep = &udc->pxa_ep[0];
udc->udccsr0 = udc_ep_readl(ep, UDCCSR);
- for (i = 1; i < NR_PXA_ENDPOINTS; i++) {
- ep = &udc->pxa_ep[i];
- ep->udccsr_value = udc_ep_readl(ep, UDCCSR);
- ep->udccr_value = udc_ep_readl(ep, UDCCR);
- ep_dbg(ep, "udccsr:0x%03x, udccr:0x%x\n",
- ep->udccsr_value, ep->udccr_value);
- }
udc_disable(udc);
udc->pullup_resume = udc->pullup_on;
@@ -2612,19 +2604,11 @@ static int pxa_udc_suspend(struct platform_device
*_dev, pm_message_t state)
*/
static int pxa_udc_resume(struct platform_device *_dev)
{
- int i;
struct pxa_udc *udc = platform_get_drvdata(_dev);
struct pxa_ep *ep;
ep = &udc->pxa_ep[0];
udc_ep_writel(ep, UDCCSR, udc->udccsr0 & (UDCCSR0_FST | UDCCSR0_DME));
- for (i = 1; i < NR_PXA_ENDPOINTS; i++) {
- ep = &udc->pxa_ep[i];
- udc_ep_writel(ep, UDCCSR, ep->udccsr_value);
- udc_ep_writel(ep, UDCCR, ep->udccr_value);
- ep_dbg(ep, "udccsr:0x%03x, udccr:0x%x\n",
- ep->udccsr_value, ep->udccr_value);
- }
dplus_pullup(udc, udc->pullup_resume);
if (should_enable_udc(udc))
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/4] usb: gadget: pxa27x_udc: add devicetree support
Add support for device-tree device discovery. If devicetree is not
provided, fallback to legacy platform data "discovery".
Signed-off-by: Robert Jarzmik
Cc: devicet...@vger.kernel.org
---
Since V1: change OF id mrvl,pxa27x_udc -> marvell,pxa27x-udc
This is a consequence of other DT reviews on the marvell
namings.
Since V2: address Mark's comments:
- wildcard pxa27x becomes pxa270
- pullup gpio is described as standard dt gpio
- bool XXX_probe_dt becomes int XXX_probe_dt
---
drivers/usb/gadget/udc/pxa27x_udc.c | 94 ++---
drivers/usb/gadget/udc/pxa27x_udc.h | 4 ++
2 files changed, 81 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/gadget/udc/pxa27x_udc.c
b/drivers/usb/gadget/udc/pxa27x_udc.c
index 597d39f..42f4929 100644
--- a/drivers/usb/gadget/udc/pxa27x_udc.c
+++ b/drivers/usb/gadget/udc/pxa27x_udc.c
@@ -26,6 +26,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -1508,16 +1510,16 @@ static struct usb_ep_ops pxa_ep_ops = {
static void dplus_pullup(struct pxa_udc *udc, int on)
{
if (on) {
- if (gpio_is_valid(udc->mach->gpio_pullup))
- gpio_set_value(udc->mach->gpio_pullup,
- !udc->mach->gpio_pullup_inverted);
- if (udc->mach->udc_command)
+ if (gpio_is_valid(udc->gpio_pullup))
+ gpio_set_value(udc->gpio_pullup,
+ !udc->gpio_pullup_inverted);
+ if (udc->mach && udc->mach->udc_command)
udc->mach->udc_command(PXA2XX_UDC_CMD_CONNECT);
} else {
- if (gpio_is_valid(udc->mach->gpio_pullup))
- gpio_set_value(udc->mach->gpio_pullup,
- udc->mach->gpio_pullup_inverted);
- if (udc->mach->udc_command)
+ if (gpio_is_valid(udc->gpio_pullup))
+ gpio_set_value(udc->gpio_pullup,
+ udc->gpio_pullup_inverted);
+ if (udc->mach && udc->mach->udc_command)
udc->mach->udc_command(PXA2XX_UDC_CMD_DISCONNECT);
}
udc->pullup_on = on;
@@ -1609,7 +1611,8 @@ static int pxa_udc_pullup(struct usb_gadget *_gadget, int
is_active)
{
struct pxa_udc *udc = to_gadget_udc(_gadget);
- if (!gpio_is_valid(udc->mach->gpio_pullup) && !udc->mach->udc_command)
+ if (!gpio_is_valid(udc->gpio_pullup)
+ && !(udc->mach && udc->mach->udc_command))
return -EOPNOTSUPP;
dplus_pullup(udc, is_active);
@@ -2404,6 +2407,56 @@ static struct pxa_udc memory = {
}
};
+static struct of_device_id udc_pxa_dt_ids[] = {
+ { .compatible = "marvell,pxa270-udc" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, udc_pxa_dt_ids);
+
+/**
+ * pxa_udc_probe_dt - device tree specific probe
+ * @pdev: platform data
+ * @udc: pxa_udc structure to fill
+ *
+ * Fills udc from platform data out of device tree.
+ *
+ * Returns 0 if DT found, 1 if DT not found, and <0 on error
+ */
+static int pxa_udc_probe_dt(struct platform_device *pdev, struct pxa_udc *udc)
+{
+ struct device_node *np = pdev->dev.of_node;
+ const struct of_device_id *of_id =
+ of_match_device(udc_pxa_dt_ids, &pdev->dev);
+ u32 gpio_pullup;
+ enum of_gpio_flags flags;
+
+ if (!np || !of_id)
+ return 1;
+ pdev->id = -1;
+
+ gpio_pullup = of_get_gpio_flags(np, 0, &flags);
+ if (gpio_pullup >= 0) {
+ udc->gpio_pullup = gpio_pullup;
+ udc->gpio_pullup_inverted = (flags & OF_GPIO_ACTIVE_LOW);
+ }
+ return 0;
+}
+
+/**
+ * pxa_udc_probe_pdata - legacy platform data probe
+ * @pdev: platform device
+ * @udc: pxa_udc structure to fill
+ *
+ * Simple copy of data from platform_data to udc control structure
+ */
+static void pxa_udc_probe_pdata(struct platform_device *pdev,
+ struct pxa_udc *udc)
+{
+ udc->mach = dev_get_platdata(&pdev->dev);
+ udc->gpio_pullup = udc->mach->gpio_pullup;
+ udc->gpio_pullup_inverted = udc->mach->gpio_pullup_inverted;
+}
+
/**
* pxa_udc_probe - probes the udc device
* @_dev: platform device
@@ -2415,7 +2468,13 @@ static int pxa_udc_probe(struct platform_device *pdev)
{
struct resource *regs;
struct pxa_udc *udc = &memory;
- int retval = 0, gpio;
+ int retval = 0;
+
+ retval = pxa_udc_probe_dt(pdev, udc);
+ if (retval < 0)
+ return retval;
+ if (retval > 0)
+ pxa_udc_probe_pdata(pdev, udc);
regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!regs)
@@ -2425,19 +2484,17 @@ static int pxa_udc_probe(struct platform_device *pdev)
return udc->irq;
udc->dev = &pdev->dev;
- udc-
Re: [Bug 83551] Kernel OOPses on access to address 0x8 when cdc-acm device is inserted with invalid descriptor.
On Sun, Aug 31, 2014 at 06:58:34PM +0200, Simon Schubert wrote: > On 08/31/2014 06:44 PM, Greg KH wrote: > > On Sun, Aug 31, 2014 at 05:57:51PM +0200, Simon Schubert wrote: > >> On 08/31/2014 05:54 PM, bugzilla-dae...@bugzilla.kernel.org wrote: > >>> https://bugzilla.kernel.org/show_bug.cgi?id=83551 > >>> > >>> --- Comment #1 from Greg Kroah-Hartman --- > >>> On Sun, Aug 31, 2014 at 10:15:37AM +, > >>> bugzilla-dae...@bugzilla.kernel.org > >>> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=83551 > > Bug ID: 83551 > Summary: Kernel OOPses on access to address 0x8 when cdc-acm > device is inserted with invalid descriptor. > >>> Can you please send this to the linux-usb@vger.kernel.org mailing list? > >> Sure, there you are. > > Um, the whole thing, including the patch, in a format we can apply it in > > (Documentation/SubmittingPatches has all of the details, I can't take > > patches from bugzilla directly, sorry.) > > > > thanks, > > > > greg k-h > > What's the bugzilla then good for, anyways? Some kernel subsystems use it (like ACPI), while others (like USB and networking), don't use it at all as it does not scale at all so that all developers of the subsystem can help out with reported issues. > I don't want to invest more time into this, sorry. The patch is > trivial anyways. trivial is not always so... 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: [Bug 83551] Kernel OOPses on access to address 0x8 when cdc-acm device is inserted with invalid descriptor.
On 08/31/2014 06:44 PM, Greg KH wrote: > On Sun, Aug 31, 2014 at 05:57:51PM +0200, Simon Schubert wrote: >> On 08/31/2014 05:54 PM, bugzilla-dae...@bugzilla.kernel.org wrote: >>> https://bugzilla.kernel.org/show_bug.cgi?id=83551 >>> >>> --- Comment #1 from Greg Kroah-Hartman --- >>> On Sun, Aug 31, 2014 at 10:15:37AM +, >>> bugzilla-dae...@bugzilla.kernel.org >>> wrote: https://bugzilla.kernel.org/show_bug.cgi?id=83551 Bug ID: 83551 Summary: Kernel OOPses on access to address 0x8 when cdc-acm device is inserted with invalid descriptor. >>> Can you please send this to the linux-usb@vger.kernel.org mailing list? >> Sure, there you are. > Um, the whole thing, including the patch, in a format we can apply it in > (Documentation/SubmittingPatches has all of the details, I can't take > patches from bugzilla directly, sorry.) > > thanks, > > greg k-h What's the bugzilla then good for, anyways? I don't want to invest more time into this, sorry. The patch is trivial anyways. cheers simon signature.asc Description: OpenPGP digital signature
Re: [Bug 83551] Kernel OOPses on access to address 0x8 when cdc-acm device is inserted with invalid descriptor.
On Sun, Aug 31, 2014 at 05:57:51PM +0200, Simon Schubert wrote: > On 08/31/2014 05:54 PM, bugzilla-dae...@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=83551 > > > > --- Comment #1 from Greg Kroah-Hartman --- > > On Sun, Aug 31, 2014 at 10:15:37AM +, > > bugzilla-dae...@bugzilla.kernel.org > > wrote: > >> https://bugzilla.kernel.org/show_bug.cgi?id=83551 > >> > >> Bug ID: 83551 > >>Summary: Kernel OOPses on access to address 0x8 when cdc-acm > >> device is inserted with invalid descriptor. > > Can you please send this to the linux-usb@vger.kernel.org mailing list? > Sure, there you are. Um, the whole thing, including the patch, in a format we can apply it in (Documentation/SubmittingPatches has all of the details, I can't take patches from bugzilla directly, sorry.) 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: [Bug 83551] Kernel OOPses on access to address 0x8 when cdc-acm device is inserted with invalid descriptor.
On 08/31/2014 05:54 PM, bugzilla-dae...@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=83551 > > --- Comment #1 from Greg Kroah-Hartman --- > On Sun, Aug 31, 2014 at 10:15:37AM +, bugzilla-dae...@bugzilla.kernel.org > wrote: >> https://bugzilla.kernel.org/show_bug.cgi?id=83551 >> >> Bug ID: 83551 >>Summary: Kernel OOPses on access to address 0x8 when cdc-acm >> device is inserted with invalid descriptor. > Can you please send this to the linux-usb@vger.kernel.org mailing list? Sure, there you are. -- 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 v8] usb:serial:pl2303: add GPIOs interface on PL2303
PL2303 USB Serial devices may has GPIOs, this patch add
basic PL2303 gpio support.
Known issue:
If gpios are in use(export to userspace through sysfs interface, etc),
then call pl2303_release(unplug usb-serial convertor, modprobe -r, etc),
will cause trouble, so we need to make sure there is no gpio user before
call pl2303_release.
Signed-off-by: Wang YanQing
---
Note: I sniffed office HXD gpio test program to get
gpios control protocol with PL2303 RA, so I only
test it with PL2303 RA and HXA, I don't have HXD,
but because it is *office* HXD gpio test program,
so if it doesn't work with HXD, I will feel surprise.
Changes
v7-v8:
1: add support for four dedicated gpios on HXD and RA
2: fix problem reported by Johan Hovold in v7
3: fix checkpatch.pl's warning
v6-v7:
1: add generic gpio support interfaces for pl2303 USB Serial devices
in pl2303_type_data and pl2303_serial_private suggested by Andreas Mohr.
2: drop different label names for different pl2303 instance suggested by Johan
Hovold.
3: fix missing lock corrected by Johan Hovold.
4: use prefix pl2303hx_gpio instead pl2303_gpio, pl2303_gpio is over generic
for current code,
and now we move gpio_startup|gpio_release into type-specified data
structure, so pl2303hx_gpio
is a better prefix.
5: make words in Kconfig a little more useful and clarified.
6: many misc code quality enhancement suggested by Johan Hovold.
v5-v6:
1: fix typo error in Kconfig reported by Andreas Mohr
2: add const qulification to gpio_dir_mask and gpio_value_mask suggested by
Andreas Mohr
v4-v5:
1: fix gpio_chip.lable been overwrited by template_chip.
2: use idr to manage minor instead of crude monotonous atomic increment.
v3-v4:
1: fix missing static for gpio_dir_mask and gpio_value_mask
2: reduce unneeded compile macro defined suggested by
gno...@lxorguk.ukuu.org.uk
3: use true instead of 1 corrected by Linus Walleij
4: ignore return value of gpiochip_remove suggested by Linus Walleij
5: fix multi gpio_chips registered by pl2303 can't be distinguished in kernel
space.
v2-v3:
1: fix errors and warnings reported by Daniele Forsi checked with
checkpatch.pl
2: fix missing GPIOLIB dependence in Kconfig
3: fix pl2303_gpio_get can't work
v1-v2:
1:drop gpio-pl2303.c and relation stuff
2:hang gpio stuff off of pl2303.c
drivers/usb/serial/Kconfig | 11 ++
drivers/usb/serial/pl2303.c | 250
2 files changed, 261 insertions(+)
diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig
index 3ce5c74..b4e0cf9 100644
--- a/drivers/usb/serial/Kconfig
+++ b/drivers/usb/serial/Kconfig
@@ -516,6 +516,17 @@ config USB_SERIAL_PL2303
To compile this driver as a module, choose M here: the
module will be called pl2303.
+config USB_SERIAL_PL2303_GPIO
+ bool "USB Prolific 2303 Single Port GPIOs support"
+ depends on USB_SERIAL_PL2303 && GPIOLIB
+ ---help---
+ Say Y here if you want to use GPIOs on PL2303 USB Serial single port
+ adapter from Prolific.
+
+ It supports 2 dedicated GPIOs on PL2303HXA, 4 dedicated GPIOs on
+ PL2303HXD and PL2303RA currently.
+ If unsure, say N.
+
config USB_SERIAL_OTI6858
tristate "USB Ours Technology Inc. OTi-6858 USB To RS232 Bridge
Controller"
help
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index e9bad92..a3f8411 100644
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -28,6 +28,8 @@
#include
#include
#include
+#include
+#include
#include "pl2303.h"
@@ -132,6 +134,22 @@ MODULE_DEVICE_TABLE(usb, id_table);
#define UART_OVERRUN_ERROR 0x40
#define UART_CTS 0x80
+#define HXD_GPIO_01_CTRL 0x0001
+#define HXD_GPIO_01_VALUE 0x0081
+#define HXD_GPIO_23_DIR_CTRL 0x0c0c
+#define HXD_GPIO_23_VALUE_CTRL 0x0d0d
+#define HXD_GPIO_23_VALUE 0x8d8d
+
+#define HXD_GPIO0_DIR_MASK 0x10
+#define HXD_GPIO1_DIR_MASK 0x20
+#define HXD_GPIO2_DIR_MASK 0x03
+#define HXD_GPIO3_DIR_MASK 0x0c
+
+#define HXD_GPIO0_VALUE_MASK 0x40
+#define HXD_GPIO1_VALUE_MASK 0x80
+#define HXD_GPIO2_VALUE_MASK 0x01
+#define HXD_GPIO3_VALUE_MASK 0x02
+
enum pl2303_type {
TYPE_01,/* Type 0 and 1 (difference unknown) */
@@ -144,9 +162,12 @@ struct pl2303_type_data {
unsigned long quirks;
};
+struct pl2303_gpio;
struct pl2303_serial_private {
const struct pl2303_type_data *type;
unsigned long quirks;
+ u8 ngpio;
+ struct pl2303_gpio *gpio;
};
struct pl2303_private {
@@ -157,6 +178,14 @@ struct pl2303_private {
u8 line_settings[7];
};
+#ifdef CONFIG_USB_SERIAL_PL2303_GPIO
+static int pl2303_gpio_startup(struct usb_serial *serial);
+static void pl2303_gpio_re
Re: Bind usb device to another class driver
On Sun, 31 Aug 2014, vichy wrote: > >> My questions: > >> 1. is there anything I need to do, such as PCI driver, before bind to > >> usb-storage driver? > > > > Normally, if uas will bind to a device then usb-storage won't. You can > > change this by using a module paramter for usb-storage: > > > > modprobe usb-storage quirks=1759:5002:u > > > > (1759 and 5002 are the vendor and product IDs for this device.) > Is there any interface priority written in driver to let uas instead > of usb-storage bind the device? Yes. If a device supports both transports then the kernel will use uas instead of usb-storage, because it is more efficient. The quirk overrides this behavior. > BTW, if we try not let uas bind the device, why don't we add the quirk > in uas but usb-storage? What is the "u" at the end of command mean? In fact, uas uses usb-storage for quirk handling. So if you add the quirk to usb-storage then it will apply to both drivers. The 'u' means: Don't use the uas driver. This is supposed to be explained in Documentation/kernel-parameters.txt, but it got left out. I will have to add it. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
On Sat, 30 Aug 2014, Douglas Gilbert wrote: > On 14-08-30 05:15 PM, Alan Stern wrote: > > On Fri, 29 Aug 2014, Matthew Dharm wrote: > > > >> Is there an 'easy' way to override the detected size of a storage > >> device from userspace? If we had that, someone could write a helper > >> application which looked for this particular fubar and try to Do The > >> Right Thing(tm), or at least offer the user some options. > > > > You mean, force a Media Change event and override the capacity reported > > by the hardware? I'm not aware of any API for doing that, although it > > probably wouldn't be too hard to add one. > > > > How would the user know what value to put in for the capacity? Unless > > the drive had been hooked up to a different computer and the user > > manually noted the correct capacity and typed it in, it would have to > > be guesswork. > > Might another possibility be using the SAT layer to issue > the appropriate ATA command via the SCSI ATA PASS-THROUGH > (12 or 16) command to find out the disk's size. That might work. Not all USB mass-storage devices support ATA pass-through but some of them do. > This might > be a possible strategy if READ CAPACITY(10) yields 0x > for the last sector's LBA and the follow-up READ CAPACITY(16) > fails or yields a truncated value. Yes. The problem in this case is that READ CAPACITY(10) yields a reasonable value (not 0x), so READ CAPACITY(16) never gets sent. And if it was sent, the device wouldn't handle it anyway. > BTW Been looking at a USB-to-SATA adapter that uses the > UAS(P) transport. I thought nothing could have worse > SCSI compliance than USB mass storage devices. I was > wrong ... Well, a USB-to-SATA adapter _is_ a USB mass-storage device. What vendor and product? 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: Bind usb device to another class driver
hi Greg: 2014-08-30 2:31 GMT+08:00 Greg KH : > On Fri, Aug 29, 2014 at 11:18:39AM +0800, vichy wrote: >> hi all: >> I have read the article below and try to do the same operation on my device. >> http://lwn.net/Articles/143397/ >> >> My environment: >> 1. my kernel is 3.16 >> 2. device descriptor is attached. >> 3. below are my operation logs: >># echo -n "4-2:1.0" > /sys/bus/usb/drivers/uas/unbind >># echo -n "4-2:1.0" > /sys/bus/usb/drivers/usb-storage/unbind >>bash: echo: write error: No such device > > You unbound your device from two different drivers? Of course the > second one doesn't work, it's not bound there :) sorry for my typo ^^ BTW, is bind/unbind a part of bus driver call backs, since I only find them in /sys/bus. If so, # pwd /sys # find ./ -name 'unbind' ./bus/cpu/drivers/processor/unbind ./bus/i2c/drivers/rc5t583/unbind ./bus/i2c/drivers/smsc/unbind ./bus/i2c/drivers/88PM860x/unbind ./bus/i2c/drivers/dummy/unbind .. appreciate all your kind help, -- 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: Bind usb device to another class driver
hi alan: 2014-08-29 22:54 GMT+08:00 Alan Stern : > On Fri, 29 Aug 2014, vichy wrote: > >> hi all: >> I have read the article below and try to do the same operation on my device. >> http://lwn.net/Articles/143397/ >> >> My environment: >> 1. my kernel is 3.16 >> 2. device descriptor is attached. >> 3. below are my operation logs: >># echo -n "4-2:1.0" > /sys/bus/usb/drivers/uas/unbind >># echo -n "4-2:1.0" > /sys/bus/usb/drivers/usb-storage/unbind >>bash: echo: write error: No such device >># > > Why do you want to bind your drive to usb-storage instead of uas? I read the article from the web but have no real test case to try on my pc until I found there are both usb-storage and uas interface on my external hard disk. > >> My questions: >> 1. is there anything I need to do, such as PCI driver, before bind to >> usb-storage driver? > > Normally, if uas will bind to a device then usb-storage won't. You can > change this by using a module paramter for usb-storage: > > modprobe usb-storage quirks=1759:5002:u > > (1759 and 5002 are the vendor and product IDs for this device.) Is there any interface priority written in driver to let uas instead of usb-storage bind the device? BTW, if we try not let uas bind the device, why don't we add the quirk in uas but usb-storage? What is the "u" at the end of command mean? > >> 2. I can check whether the usb device is bound to specific driver >> through "cat /sys/kernel/debug/usb/devices". >>is there any alternative way to do so? how about other drivers, >> except usb, to let user know whether the binding/unbinding >> successfully and which device is bound to which driver? > > ls -l /sys/bus/usb/devices/.../driver > > where you fill in the "..." with the path for the interface you are > interested in, such as 1-4:1.0. Alternatively, > > ls /sys/bus/usb/drivers/.../ > > where you fill in the "..." with the name of the driver you are > interested in. > I found what you mentioned ^^ appreciate your help, -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
auth 9af38645 subscribe linux-usb tschae...@t-online.de -- 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
