Re: right place for CDMA / GSM modem IDs for usbserial autoloading?
On Sun, 2008-02-24 at 21:18 -0800, Greg KH wrote: > I have no problem exporting a simple sysfs attribute showing if the > device is either CDMA or GSDM. I would think with that, HAL would not > need to keep any kind of tables at all, and then the device info only > has to stay in one place. This would be ideal. IIRC the only reason for keeping the tables was that there was no such attribute. Sounds about right Dan? Thanks, David - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: right place for CDMA / GSM modem IDs for usbserial autoloading?
On Mon, Feb 25, 2008 at 03:07:05AM -0500, David Zeuthen wrote: > > On Sun, 2008-02-24 at 21:18 -0800, Greg KH wrote: > > I have no problem exporting a simple sysfs attribute showing if the > > device is either CDMA or GSDM. I would think with that, HAL would not > > need to keep any kind of tables at all, and then the device info only > > has to stay in one place. > > This would be ideal. IIRC the only reason for keeping the tables was > that there was no such attribute. Sounds about right Dan? Ok, tell me what attribute, and which device is which (or point me at a table to get this from), and I'll be glad to add it to the drivers (sierra and option). thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB OOPS 2.6.25-rc2-git1
On Thursday 21 February 2008, Alan Stern wrote: > > = CUT HERE > > Modify EHCI irq handling on the theory that at least some of the > > "lost" IRQs are caused by goofage between multiple lowlevel IRQ > > acking mechanisms: try rescanning before we exit the handler, in > > case the EHCI-internal ack (by clearing the irq status) doesn't > > always suffice for IRQs triggered nearly back-to-back. > > > > --- > > drivers/usb/host/ehci-hcd.c | 8 > > 1 file changed, 8 insertions(+) > > > > --- g26.orig/drivers/usb/host/ehci-hcd.c 2008-02-20 13:26:00.0 > > -0800 > > +++ g26/drivers/usb/host/ehci-hcd.c 2008-02-20 13:54:37.0 -0800 > > @@ -638,6 +638,8 @@ static irqreturn_t ehci_irq (struct usb_ > > return IRQ_NONE; > > } > > > > +retrigger: > > + > > /* clear (just) interrupts */ > > ehci_writel(ehci, status, &ehci->regs->status); > > cmd = ehci_readl(ehci, &ehci->regs->command); > > @@ -725,6 +727,12 @@ dead: > > > > if (bh) > > ehci_work (ehci); > > + > > + status = ehci_readl(ehci, &ehci->regs->status); > > + status &= INTR_MASK; > > + if (status) > > + goto retrigger; > > + > > spin_unlock (&ehci->lock); > > if (pcd_status & STS_PCD) > > usb_hcd_poll_rh_status(hcd); > > There's one little problem here. As a result of this change, the line > where pcd_status gets set (not shown in this patch) needs to be changed > to: > > pcd_status |= (status & STS_PCD); Actually, no change is needed. It's initialized to zero, then set to "status" given "if (status & STS_PCD)", and never cleared. So if it's ever set, it stays set... > > Then the test shown above can be simplified to: > > if (pcd_status) True with the current code too ... - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: fix comment of struct usb_interface
From: Lei Ming <[EMAIL PROTECTED]>
update the comment for the removed "driver" field and being
out-of-order of @cur_altsetting and @num_altsetting.
Signed-off-by: Lei Ming <[EMAIL PROTECTED]>
---
include/linux/usb.h |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
mode change 100644 => 100755 include/linux/usb.h
diff --git a/include/linux/usb.h b/include/linux/usb.h
old mode 100644
new mode 100755
index 2372e2e..8a864f8
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -94,10 +94,9 @@ enum usb_interface_condition {
* @altsetting: array of interface structures, one for each alternate
* setting that may be selected. Each one includes a set of
* endpoint configurations. They will be in no particular order.
- * @num_altsetting: number of altsettings defined.
* @cur_altsetting: the current altsetting.
+ * @num_altsetting: number of altsettings defined.
* @intf_assoc: interface association descriptor
- * @driver: the USB driver that is bound to this interface.
* @minor: the minor number assigned to this interface, if this
* interface is bound to a driver that uses the USB major number.
* If this interface does not use the USB major, this field should
--
1.5.4.rc4.338.g923d4
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Advice about USB-serial adapters
> Well, if your devices are quite "accepting" and use standard "serial" > lines, anything should do. > But some special uses (for example microcontroller programmers) might > take a LONG time (in my case, more than 3 minutes to program a PIC) to > do the same thing a real serial port did in a really shorter time (about > 15 seconds to program the same PIC...). > > I decided to buy a PCMCIA to serial card (found in a fair a 2-port for 5 > EUR, had just to fix a broken wire). If you need many, maybe IC Intracom > is for you... but what they sell is QUITE expensive! > Thank you all for your answers. @Diego: In the past we've used pcmcia cards, but the laptops we just bought have expresscard slots @David and Alan: At least now I know what to look for for minimizing troubles. jorges - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB Persist issue
Em Friday 22 February 2008 17:33:10 Alan Stern escreveu: > On Thu, 21 Feb 2008, Herton Ronaldo Krzesinski wrote: > > > So the child branch is taken and USB_PERSIST && child->persist_enabled > > evaluates as true. Also udev->reset_resume is enabled. The problem here > > is inside usb_reset_device. The devices are redetected because a > > reenumeration is forced, see that usb_reset_device return -ENOTCONN because: > > > > - usb_reset_device call chain is hub_port_init -> hub_port_reset -> > > hub_port_wait_reset. In hub_port_wait_reset, the call to hub_port_status > > doesn't fail, but portstatus or portchange are respectively > > USB_PORT_STAT_CONNECTION or USB_PORT_STAT_C_CONNECTION > > (Look that no one of the printks in hub_port_wait_reset are printed), > > and -ENOTCONN then from one of the two returns go back until > > usb_reset_device that then takes the re_enumeration label that causes the > > logical disconnect, so the redetection happens. > > > > I don't know why ehci is returning this portchange/portstatus, but this is > > triggering the redetection. > > Yes, the problem is the USB_PORT_STAT_C_CONNECTION. (Although I'm not > sure why udev->reset_resume was enabled...) > > Anyway, try this patch; it ought to help. > > Alan Stern > Hi Alan, I had some delay as only could access the hardware today. Your patch helped without a doubt, thanks a lot, s2ram is working ok now, here is the complete log: [ 89.412854] PM: Syncing filesystems ... done. [ 89.427257] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 89.446375] Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. [ 89.446739] ACPI: Preparing to enter system sleep state S3 [ 89.447454] Suspending console(s) [ 89.955861] uhci_hcd :00:1d.1: release dev 2 ep81-INT, period 8, phase 4, 118 us [ 89.956788] uhci_hcd :00:1d.1: release dev 2 ep82-INT, period 8, phase 4, 118 us [ 89.958834] usb 3-1: usb suspend [ 89.969786] usb 1-6: usb suspend [ 89.980745] usb 1-5: usb suspend [ 89.991715] usb 1-1: usb suspend [ 90.002680] hub 3-0:1.0: hub_suspend [ 90.002691] usb usb3: bus suspend [ 90.002695] usb usb3: suspend_rh [ 90.002719] hub 1-0:1.0: hub_suspend [ 90.002723] usb usb1: bus suspend [ 90.002727] ehci_hcd :00:1d.7: suspend root hub [ 90.002761] drm_sysfs_suspend [ 90.003321] ACPI: PCI interrupt for device :00:02.0 disabled [ 90.013911] ACPI handle has no context! [ 90.013936] ACPI handle has no context! [ 90.024912] ACPI: PCI interrupt for device :00:1e.2 disabled [ 90.025032] ACPI: PCI interrupt for device :00:1d.7 disabled [ 90.035579] ehci_hcd :00:1d.7: --> PCI D3/wakeup [ 90.035609] uhci_hcd :00:1d.3: uhci_suspend [ 90.035643] ACPI: PCI interrupt for device :00:1d.3 disabled [ 90.035646] uhci_hcd :00:1d.3: --> PCI D0/legacy [ 90.035650] uhci_hcd :00:1d.2: uhci_suspend [ 90.035684] ACPI: PCI interrupt for device :00:1d.2 disabled [ 90.035687] uhci_hcd :00:1d.2: --> PCI D0/legacy [ 90.035691] uhci_hcd :00:1d.1: uhci_suspend [ 90.035723] ACPI: PCI interrupt for device :00:1d.1 disabled [ 90.035727] uhci_hcd :00:1d.1: --> PCI D0/legacy [ 90.035730] uhci_hcd :00:1d.0: uhci_suspend [ 90.035762] ACPI: PCI interrupt for device :00:1d.0 disabled [ 90.035766] uhci_hcd :00:1d.0: --> PCI D0/legacy [ 90.035766] Intel machine check architecture supported. [ 90.035779] Intel machine check reporting enabled on CPU#0. [ 90.035833] Back to C! [ 90.062187] PM: Writing back config space on device :00:02.0 at offset 1 (was 97, writing 93) [ 90.081040] PM: Writing back config space on device :00:1c.0 at offset f (was 20100, writing 2010a) [ 90.08] ACPI: PCI Interrupt :00:1c.0[A] -> GSI 16 (level, low) -> IRQ 16 [ 90.081121] PCI: Setting latency timer of device :00:1c.0 to 64 [ 90.081128] uhci_hcd :00:1d.0: PCI legacy resume [ 90.081135] ACPI: PCI Interrupt :00:1d.0[A] -> GSI 23 (level, low) -> IRQ 23 [ 90.081143] PCI: Setting latency timer of device :00:1d.0 to 64 [ 90.081171] uhci_hcd :00:1d.0: uhci_resume [ 90.081178] uhci_hcd :00:1d.0: uhci_check_and_reset_hc: legsup = 0x0f30 [ 90.081182] uhci_hcd :00:1d.0: Performing full reset [ 90.081184] usb usb2: root hub lost power or was reset [ 90.081184] usb usb2: suspend_rh [ 90.081195] uhci_hcd :00:1d.1: PCI legacy resume [ 90.081204] ACPI: PCI Interrupt :00:1d.1[B] -> GSI 19 (level, low) -> IRQ 19 [ 90.081212] PCI: Setting latency timer of device :00:1d.1 to 64 [ 90.081240] uhci_hcd :00:1d.1: uhci_resume [ 90.081245] uhci_hcd :00:1d.1: uhci_check_and_reset_hc: legsup = 0x0030 [ 90.081249] uhci_hcd :00:1d.1: Performing full reset [ 90.081269] usb usb3: root hub lost power or was reset [ 90.081273] usb usb3: suspend_rh [ 90.081323] uhci_hcd :00:1d.2: PCI legacy resume [ 90.081333] ACPI: PCI Interrupt 000
Re: USB Persist issue
On Mon, 25 Feb 2008, Herton Ronaldo Krzesinski wrote:
> Hi Alan, I had some delay as only could access the hardware today. Your patch
> helped without a doubt, thanks a lot, s2ram is working ok now, here is the
> complete log:
Thanks for testing. Here is an updated version of that patch. This is
probably the version that I will end up submitting for 2.6.25.
Raymano, this patch is intended to solve the problem you were having
with USB-Persist not working after a suspend. Other people began
having the same problem (including Linus Torvalds!), so the fix will go
into the official kernel. I'd appreciate it if you could test it
first. Be sure to remove the two-line special patch from last November
when you do.
The patch is meant to apply to 2.6.24, but it may work okay with
slightly different kernel versions.
Alan Stern
Index: 2.6.24/drivers/usb/core/hub.c
===
--- 2.6.24.orig/drivers/usb/core/hub.c
+++ 2.6.24/drivers/usb/core/hub.c
@@ -1987,51 +1987,76 @@ static int hub_suspend(struct usb_interf
return 0;
}
-static int hub_resume(struct usb_interface *intf)
-{
- struct usb_hub *hub = usb_get_intfdata (intf);
-
- dev_dbg(&intf->dev, "%s\n", __FUNCTION__);
-
- /* tell khubd to look for changes on this hub */
- hub_activate(hub);
- return 0;
-}
-
-static int hub_reset_resume(struct usb_interface *intf)
+static void hub_resume_common(struct usb_hub *hub, bool reset_resume)
{
- struct usb_hub *hub = usb_get_intfdata(intf);
struct usb_device *hdev = hub->hdev;
int port1;
- hub_power_on(hub);
-
+ /* Check each of the children to see if they require
+* USB_PERSIST handling or disconnection.
+*/
for (port1 = 1; port1 <= hdev->maxchild; ++port1) {
- struct usb_device *child = hdev->children[port1-1];
+ struct usb_device *udev = hdev->children[port1-1];
+ int status;
+ u16 portstatus, portchange;
+
+ if (!udev)
+ continue;
- if (child) {
+ /* Was the power session lost while we were suspended? */
+ if (reset_resume) {
+ status = 0;
+ portstatus = 0;
+ portchange = USB_PORT_STAT_C_CONNECTION;
+ } else {
+ status = hub_port_status(hub, port1,
+ &portstatus, &portchange);
+ }
- /* For "USB_PERSIST"-enabled children we must
-* mark the child device for reset-resume and
-* turn off the connect-change status to prevent
-* khubd from disconnecting it later.
-*/
- if (USB_PERSIST && child->persist_enabled) {
- child->reset_resume = 1;
- clear_port_feature(hdev, port1,
+ /* For "USB_PERSIST"-enabled children we must
+* mark the child device for reset-resume and
+* turn off the various status changes to prevent
+* khubd from disconnecting it later.
+*/
+ if (USB_PERSIST && udev->persist_enabled && status == 0 &&
+ !(portstatus & USB_PORT_STAT_ENABLE)) {
+ if (portchange & USB_PORT_STAT_C_ENABLE)
+ clear_port_feature(hub->hdev, port1,
+ USB_PORT_FEAT_C_ENABLE);
+ if (portchange & USB_PORT_STAT_C_CONNECTION)
+ clear_port_feature(hub->hdev, port1,
USB_PORT_FEAT_C_CONNECTION);
+ udev->reset_resume = 1;
+ }
- /* Otherwise we must disconnect the child,
-* but as we may not lock the child device here
-* we have to do a "logical" disconnect.
-*/
- } else {
- hub_port_logical_disconnect(hub, port1);
- }
+ /* Otherwise for a reset_resume we must disconnect the child,
+* but as we may not lock the child device here
+* we have to do a "logical" disconnect.
+*/
+ else if (reset_resume) {
+ hub_port_logical_disconnect(hub, port1);
}
}
hub_activate(hub);
+}
+
+static int hub_resume(struct usb_interface *intf)
+{
+ struct usb_hub *hub = usb_get_intfdata(intf);
+
+ dev_dbg(&intf->dev, "%s\n", __func__);
+ hub_resume_common(hub, false);
+ return 0;
+}
+
+static int hub_reset_resume(struct usb_interface *intf)
Re: USB Persist issue
Em Monday 25 February 2008 12:10:13 Alan Stern escreveu: > On Mon, 25 Feb 2008, Herton Ronaldo Krzesinski wrote: > > > Hi Alan, I had some delay as only could access the hardware today. Your > > patch > > helped without a doubt, thanks a lot, s2ram is working ok now, here is the > > complete log: > > Thanks for testing. Here is an updated version of that patch. This is > probably the version that I will end up submitting for 2.6.25. This version also works ok here, I'm testing on the same kernel as previously (2.6.25-rc2 git 5d9c4a7de64d398604a978d267a6987f1f4025b7) > > Raymano, this patch is intended to solve the problem you were having > with USB-Persist not working after a suspend. Other people began > having the same problem (including Linus Torvalds!), so the fix will go > into the official kernel. I'd appreciate it if you could test it > first. Be sure to remove the two-line special patch from last November > when you do. > > The patch is meant to apply to 2.6.24, but it may work okay with > slightly different kernel versions. > > Alan Stern -- []'s Herton - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB urb->lock removal breaks X-Craft timing...
On Mon, 25 Feb 2008, Jan Gutter wrote:
> Hi, I have a Cooler Master X-Craft hard drive enclosure with
> USB ID ed06:8000. (Manufacturer ID according to lsusb is DATAST0R)
>
> I've had no problems in using the drive on 2.6.23, but on vanilla 2.6.24
> I get a "device not accepting address" error in dmesg. I've done a
> bisect, and found out that if I revert the patch series, (from
> linus-git)
>
> 4d2f110c51eec853c50f68cf06a77551c8d3 to
> e015268d2fcfcaef70a1ec535e6381f75aafbf81
>
> (i.e. the "get rid of urb->lock" and "urb->status" series)
>
> it works again in 2.6.24. (A more verbose description is listed in the
> bug report below.)
>
> At first glance, it *looks* like a timing issue. Since a lot of
> spinlocks have been eliminated, the device might just go a little funny
> if it gets responses too fast on init.
Actually the spinlocks weren't eliminated; they were just moved around.
Any difference in speed should be minuscule.
> I've found a similar bug at:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=8639
>
> I'm NOT sure that the enclosure has the same chipsets, but it seems very
> likely. I get the exact same kernel messages, tough. I've logged all my
> experiences there, if you need anything else, I would be happy to
> provide!
>
> My question now is: what would be the best way to add a quirk for this
> to the kernel, and who would best be able to help me with this? Does the
> kernel even know the USB id at the stage that this error occurs?
Last question first: The kernel does not know the USB IDs at the
"device descriptor read/64" or "device not accepting address" stage.
You can try adding an explicit delay to see if it helps. In
drivers/usb/core/hub.c:hub_port_init(), add a call to msleep just
before the line:
for (i = 0; i < GET_DESCRIPTOR_TRIES; (++i, msleep(100))) {
I don't know how large an argument to msleep you'll need. 100? 5000?
Note that there's already a 50-ms delay before the loop begins.
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: update Kconfig entry for USB_SUSPEND
This patch (as1039) updates the Kconfig entry for USB_SUSPEND. The out-of-date reference to "power/state" is fixed, autosuspend is mentioned, and the dependency on EXPERIMENTAL is removed. Signed-off-by: Alan Stern <[EMAIL PROTECTED]> --- This is just a documentation change; it should be applied to 2.6.25. After another kernel release or two, we should change the default to Y. Alan Stern Index: usb-2.6/drivers/usb/core/Kconfig === --- usb-2.6.orig/drivers/usb/core/Kconfig +++ usb-2.6/drivers/usb/core/Kconfig @@ -87,12 +87,13 @@ config USB_DYNAMIC_MINORS If you are unsure about this, say N here. config USB_SUSPEND - bool "USB selective suspend/resume and wakeup (EXPERIMENTAL)" - depends on USB && PM && EXPERIMENTAL + bool "USB selective suspend/resume and wakeup" + depends on USB && PM help If you say Y here, you can use driver calls or the sysfs - "power/state" file to suspend or resume individual USB - peripherals. + "power/level" file to suspend or resume individual USB + peripherals and to enable or disable autosuspend (see + Documentation/usb/power-management.txt for more details). Also, USB "remote wakeup" signaling is supported, whereby some USB devices (like keyboards and network adapters) can wake up - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question regarding usb-serial based driver.
On 22/02/2008, Greg KH <[EMAIL PROTECTED]> wrote: > On Fri, Feb 22, 2008 at 05:30:22PM -0800, Chetan Karia wrote: > > On 22/02/2008, Greg KH <[EMAIL PROTECTED]> wrote: > > > On Wed, Feb 20, 2008 at 10:35:48AM -0800, Chetan Karia wrote: > > > > Hello, > > > > > > > > I am kernel newbie and I have a question about usb serial driver. I > > > > have a usb to serial driver which exposes 3 virtual serial ports > > > > ttyUSB0, ttyUSB1 and ttyUSB2. The endpoint to virtual serial port > > > > mapping is like this > > > > ep0 ==> ttyUSB0 > > > > ep1 ==> ttyUSB1 > > > > ep2 ==> ttyUSB2. > > > > > > > > > Which device is this? I think you are talking about the endpoint > > > "pairs" one IN and one OUT per tty, right? > > > > > Yes I am talking about endpoint per one IN and one OUT per tty. > > > But what physical device is this? > This is the sierra wireless device. > > > > > All I want to do is create another virtual serial port ttyUSB3 (easy) > > > > and setup its endpoint address (bulk in and bulk out) to same as > > > > ttyUSB1 that is ep1. I do this in attach function of the driver and I > > > > want to know will there be any race condition if ttyUSB1 and ttyUSB3 > > > > are used simultaneously? Is there any way to overcome that race > > > > condition or its simply not correct way to go. > > > > > > > > > Does the device really support another serial endpoint? You can't just > > > make a new one if the hardware can't handle it. > > > > > My intention was not to create new endpoint but two tty's (virtual > > serial ports) that talk to a single pair of IN and OUT endpoint. > > (ep1) > > > Again, why not just do this from userspace by writing to the same port? > > > > > > My sole intention for doing that is ttyUSB1 and ttyUSB3 should be able > > > > to read/write from/to same endpoint (ep1) concurrently. Is that > > > > possible? > > > > > > > > > Hm, why? Some devices might get very confused, depending on the > > > protocol used by the device. It all depends on the hardware. > > > > > > What's wrong with just having 2 programs write to the same tty node at > > > the same time? > > > > > I was under the impression that 2 user-level programs can't read/write > > to single tty node concurrently. Am I wrong? I need both read and > > write capability. > > > You can easily write to a single port from 2 programs. But note, your > device might get confused, depending on the format of the data it is > expecting to receive. We can write to a single port concurrently from 2 programs but can two programs READ the same stream simultaneously? Thanks, Chetan K > > thanks, > > greg k-h > - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question regarding usb-serial based driver.
On Mon, Feb 25, 2008 at 09:18:12AM -0800, Chetan Karia wrote: > On 22/02/2008, Greg KH <[EMAIL PROTECTED]> wrote: > > On Fri, Feb 22, 2008 at 05:30:22PM -0800, Chetan Karia wrote: > > > On 22/02/2008, Greg KH <[EMAIL PROTECTED]> wrote: > > > > On Wed, Feb 20, 2008 at 10:35:48AM -0800, Chetan Karia wrote: > > > > > Hello, > > > > > > > > > > I am kernel newbie and I have a question about usb serial driver. I > > > > > have a usb to serial driver which exposes 3 virtual serial ports > > > > > ttyUSB0, ttyUSB1 and ttyUSB2. The endpoint to virtual serial port > > > > > mapping is like this > > > > > ep0 ==> ttyUSB0 > > > > > ep1 ==> ttyUSB1 > > > > > ep2 ==> ttyUSB2. > > > > > > > > > > > > Which device is this? I think you are talking about the endpoint > > > > "pairs" one IN and one OUT per tty, right? > > > > > > > Yes I am talking about endpoint per one IN and one OUT per tty. > > > > > > But what physical device is this? > > > This is the sierra wireless device. Usually you use PPP over this kind of connection, by providing two read/write ports to it, you have the very large chance of messing up the ppp protocol, correct? What specifically are you trying to do in userspace that you need two reads or writes to do that is not working today? > We can write to a single port concurrently from 2 programs but can two > programs READ the same stream simultaneously? They can try, but things get very confusing very quickly :) thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: right place for CDMA / GSM modem IDs for usbserial autoloading?
On Mon, 2008-02-25 at 03:07 -0500, David Zeuthen wrote: > On Sun, 2008-02-24 at 21:18 -0800, Greg KH wrote: > > I have no problem exporting a simple sysfs attribute showing if the > > device is either CDMA or GSDM. I would think with that, HAL would not > > need to keep any kind of tables at all, and then the device info only > > has to stay in one place. > > This would be ideal. IIRC the only reason for keeping the tables was > that there was no such attribute. Sounds about right Dan? Yes, that was correct. However, we should keep the current HAL specification addition for a few reasons: 1) devices that are only supported by usb-serial; which includes things that are not CDMA/GSM modems 2) devices that are PCMCIA serial cards (which are matched only on class, not the manf IDs necessarily) 3) previous kernel versions that wouldn't have the magic sysfs attribute It would be worth exploring how to do this; but the problem is that since there are devices that support both GSM and CDMA, we'd need to figure out how to deal with that vs. sysfs-one-value-per-file. We shouldn't really call them "GSM" and "CDMA" but use the standards names as Marcel correctly pointed out on the HAL list. Thoughts greg? It would save us a huge .fdi file because then we could simply match on the linux driver name, and do some other magic in HAL itself to pull out the supported standards. Dan - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Huawei E220 and usb storage
On Wed, 20 Feb 2008 07:57:23 +0100, Norbert Preining <[EMAIL PROTECTED]> wrote: > > that you did, after taking care of detection and initialization. > > Look at his dmesg in comment #44 in this: > > Yes, that looks very similar. Someone reported on the bug that a firmware update exists to resolve the issue (version 11.117.07.00.67). Probably they started to comply with the spec and return 12 bytes of sense according to the allocation length in the SCSI command. https://bugzilla.redhat.com/show_bug.cgi?id=253096#c51 -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question regarding usb-serial based driver.
On 25/02/2008, Greg KH <[EMAIL PROTECTED]> wrote: > On Mon, Feb 25, 2008 at 09:18:12AM -0800, Chetan Karia wrote: > > On 22/02/2008, Greg KH <[EMAIL PROTECTED]> wrote: > > > On Fri, Feb 22, 2008 at 05:30:22PM -0800, Chetan Karia wrote: > > > > On 22/02/2008, Greg KH <[EMAIL PROTECTED]> wrote: > > > > > On Wed, Feb 20, 2008 at 10:35:48AM -0800, Chetan Karia wrote: > > > > > > Hello, > > > > > > > > > > > > I am kernel newbie and I have a question about usb serial > driver. I > > > > > > have a usb to serial driver which exposes 3 virtual serial ports > > > > > > ttyUSB0, ttyUSB1 and ttyUSB2. The endpoint to virtual serial port > > > > > > mapping is like this > > > > > > ep0 ==> ttyUSB0 > > > > > > ep1 ==> ttyUSB1 > > > > > > ep2 ==> ttyUSB2. > > > > > > > > > > > > > > > Which device is this? I think you are talking about the endpoint > > > > > "pairs" one IN and one OUT per tty, right? > > > > > > > > > Yes I am talking about endpoint per one IN and one OUT per tty. > > > > > > > > > But what physical device is this? > > > > > This is the sierra wireless device. > > > Usually you use PPP over this kind of connection, by providing two > read/write ports to it, you have the very large chance of messing up the > ppp protocol, correct? > > What specifically are you trying to do in userspace that you need two > reads or writes to do that is not working today? Alright, here is the entire situation. The sierra device has pair of endpoints (bulk in and bulk out) that sends the multiplexed protocols data packets ( two protocols data packets encapsulated in one). Lets call that endpoint pair as EP1. The one of the multiplexed protocol is DM and other is command and status. EP1 is attached to ttyUSB1. Our application reads from ttyUSB1 and ignores DM packets and considers only command and status packets. However to get DM stream working another application has to read/write to ttyUSB1 concurrently which is as tricky. Thus, I am trying to setup another virtual serial port called ttyUSB3 that can read/write to EP1 concurrently so that we get two duplicate streams. One of the stream (ttyUSB1) can be used by our existing application and another stream (ttyUSB3) can be used to set up DM logging.Internally however they will talk to same endpoint pair EP1. Is it doable? Hopefully I was able to explain the situation clearly. Thanks, Chetan Karia > > > > We can write to a single port concurrently from 2 programs but can two > > programs READ the same stream simultaneously? > > > They can try, but things get very confusing very quickly :) > > thanks, > > greg k-h > - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question regarding usb-serial based driver.
On Mon, 25 Feb 2008, Chetan Karia wrote: > Alright, here is the entire situation. The sierra device has pair of > endpoints (bulk in and bulk out) that sends the multiplexed protocols > data packets ( two protocols data packets encapsulated in one). Lets > call that endpoint pair as EP1. The one of the multiplexed protocol is > DM and other is command and status. EP1 is attached to ttyUSB1. Our > application reads from ttyUSB1 and ignores DM packets and considers > only command and status packets. However to get DM stream working > another application has to read/write to ttyUSB1 concurrently which is > as tricky. Thus, I am trying to setup another virtual serial port > called ttyUSB3 that can read/write to EP1 concurrently so that we get > two duplicate streams. One of the stream (ttyUSB1) can be used by our > existing application and another stream (ttyUSB3) can be used to set > up DM logging.Internally however they will talk to same endpoint pair > EP1. Is it doable? You should attack this problem in userspace, not in the kernel. Write a program that will communicate with ttyUSB1 and demultiplex the two protocol streams. Then have your applications each read one of the output streams from this new program. Or to make it even simpler: Write a program that will make two copies of the data stream and feed one copy to each of your applications. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question regarding usb-serial based driver.
On Mon, Feb 25, 2008 at 11:16:24AM -0800, Chetan Karia wrote: > On 25/02/2008, Greg KH <[EMAIL PROTECTED]> wrote: > > On Mon, Feb 25, 2008 at 09:18:12AM -0800, Chetan Karia wrote: > > > On 22/02/2008, Greg KH <[EMAIL PROTECTED]> wrote: > > > > On Fri, Feb 22, 2008 at 05:30:22PM -0800, Chetan Karia wrote: > > > > > On 22/02/2008, Greg KH <[EMAIL PROTECTED]> wrote: > > > > > > On Wed, Feb 20, 2008 at 10:35:48AM -0800, Chetan Karia wrote: > > > > > > > Hello, > > > > > > > > > > > > > > I am kernel newbie and I have a question about usb serial > > driver. I > > > > > > > have a usb to serial driver which exposes 3 virtual serial > > ports > > > > > > > ttyUSB0, ttyUSB1 and ttyUSB2. The endpoint to virtual serial > > port > > > > > > > mapping is like this > > > > > > > ep0 ==> ttyUSB0 > > > > > > > ep1 ==> ttyUSB1 > > > > > > > ep2 ==> ttyUSB2. > > > > > > > > > > > > > > > > > > Which device is this? I think you are talking about the endpoint > > > > > > "pairs" one IN and one OUT per tty, right? > > > > > > > > > > > Yes I am talking about endpoint per one IN and one OUT per tty. > > > > > > > > > > > > But what physical device is this? > > > > > > > This is the sierra wireless device. > > > > > > Usually you use PPP over this kind of connection, by providing two > > read/write ports to it, you have the very large chance of messing up the > > ppp protocol, correct? > > > > What specifically are you trying to do in userspace that you need two > > reads or writes to do that is not working today? > > Alright, here is the entire situation. Please next time let's not wait for 7 emails to transpire before this comes out, it wastes everyone's time involved... > The sierra device has pair of endpoints (bulk in and bulk out) that > sends the multiplexed protocols data packets ( two protocols data > packets encapsulated in one). Lets call that endpoint pair as EP1. The > one of the multiplexed protocol is DM and other is command and status. > EP1 is attached to ttyUSB1. Our application reads from ttyUSB1 and > ignores DM packets and considers only command and status packets. > However to get DM stream working another application has to read/write > to ttyUSB1 concurrently which is as tricky. Thus, I am trying to setup > another virtual serial port called ttyUSB3 that can read/write to EP1 > concurrently so that we get two duplicate streams. One of the stream > (ttyUSB1) can be used by our existing application and another stream > (ttyUSB3) can be used to set up DM logging.Internally however they > will talk to same endpoint pair EP1. Is it doable? Yes, for something like this, a modification of the sierra driver would be needed to allow for two buffers like this. But, you might want to work with the current developers of the sierra driver, as I'm pretty sure they are working to add this kind of functionality (alternate ways to control the card) to the driver for this very reason. Is there a reason you have not just contacted them already? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: right place for CDMA / GSM modem IDs for usbserial autoloading?
On Mon, Feb 25, 2008 at 01:32:04PM -0500, Dan Williams wrote: > On Mon, 2008-02-25 at 03:07 -0500, David Zeuthen wrote: > > On Sun, 2008-02-24 at 21:18 -0800, Greg KH wrote: > > > I have no problem exporting a simple sysfs attribute showing if the > > > device is either CDMA or GSDM. I would think with that, HAL would not > > > need to keep any kind of tables at all, and then the device info only > > > has to stay in one place. > > > > This would be ideal. IIRC the only reason for keeping the tables was > > that there was no such attribute. Sounds about right Dan? > > Yes, that was correct. It's not like the kernel is immutable people. If you need to work around something you find strange in the kernel, or the kernel is not exporting something that you need for userspace to work easier, please ask the kernel developers! Otherwise we don't know there's an issue at all. It's not like it is hard to find and get ahold of us... > However, we should keep the current HAL > specification addition for a few reasons: > > 1) devices that are only supported by usb-serial; which includes things > that are not CDMA/GSM modems Like what? NO DEVICES THAT ARE MODEMS SHOULD BE USING THE GENERIC USB-SERIAL DRIVER!!! Do I need to say this again somewhere else? They should ALL have a "real" usb-serial child driver to allow for proper flow control, auto-loading of drivers, and the ability to actually send data at a speed that isn't comparible to RFC 1149. > 2) devices that are PCMCIA serial cards (which are matched only on > class, not the manf IDs necessarily) These devices are no longer being manufactured from what I can tell. So that list should be fixed. > 3) previous kernel versions that wouldn't have the magic sysfs attribute Sure, but don't go adding new devices to the table, as that would be wrong. > It would be worth exploring how to do this; but the problem is that > since there are devices that support both GSM and CDMA, we'd need to > figure out how to deal with that vs. sysfs-one-value-per-file. We > shouldn't really call them "GSM" and "CDMA" but use the standards names > as Marcel correctly pointed out on the HAL list. Why not have two files, one that shows up if GSM is supported, one if CDMA is. Modems that support both would export both. It's up to userspace to pick which to use, the kernel sure doesn't care. Sound reasonable? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: right place for CDMA / GSM modem IDs for usbserial autoloading?
On Mon, Feb 25, 2008 at 08:18:57PM +0100, Marcel Holtmann wrote: > Hi Dan, > > > > > I have no problem exporting a simple sysfs attribute showing if the > > > > device is either CDMA or GSDM. I would think with that, HAL would not > > > > need to keep any kind of tables at all, and then the device info only > > > > has to stay in one place. > > > > > > This would be ideal. IIRC the only reason for keeping the tables was > > > that there was no such attribute. Sounds about right Dan? > > > > Yes, that was correct. However, we should keep the current HAL > > specification addition for a few reasons: > > > > 1) devices that are only supported by usb-serial; which includes things > > that are not CDMA/GSM modems > > > > 2) devices that are PCMCIA serial cards (which are matched only on > > class, not the manf IDs necessarily) > > > > 3) previous kernel versions that wouldn't have the magic sysfs attribute > > > > It would be worth exploring how to do this; but the problem is that > > since there are devices that support both GSM and CDMA, we'd need to > > figure out how to deal with that vs. sysfs-one-value-per-file. We > > shouldn't really call them "GSM" and "CDMA" but use the standards names > > as Marcel correctly pointed out on the HAL list. > > > > Thoughts greg? It would save us a huge .fdi file because then we could > > simply match on the linux driver name, and do some other magic in HAL > > itself to pull out the supported standards. > > what we could do is exporting a bitmap from the kernel. However this > should be done within a subsystem and not in a per driver approach. Only > fixing this for USB serial devices is the wrong approach in my eyes. It would be trivial to add this as a tty attribute, which would be the correct place, right? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: right place for CDMA / GSM modem IDs for usbserial autoloading?
Hi Dan, > > > I have no problem exporting a simple sysfs attribute showing if the > > > device is either CDMA or GSDM. I would think with that, HAL would not > > > need to keep any kind of tables at all, and then the device info only > > > has to stay in one place. > > > > This would be ideal. IIRC the only reason for keeping the tables was > > that there was no such attribute. Sounds about right Dan? > > Yes, that was correct. However, we should keep the current HAL > specification addition for a few reasons: > > 1) devices that are only supported by usb-serial; which includes things > that are not CDMA/GSM modems > > 2) devices that are PCMCIA serial cards (which are matched only on > class, not the manf IDs necessarily) > > 3) previous kernel versions that wouldn't have the magic sysfs attribute > > It would be worth exploring how to do this; but the problem is that > since there are devices that support both GSM and CDMA, we'd need to > figure out how to deal with that vs. sysfs-one-value-per-file. We > shouldn't really call them "GSM" and "CDMA" but use the standards names > as Marcel correctly pointed out on the HAL list. > > Thoughts greg? It would save us a huge .fdi file because then we could > simply match on the linux driver name, and do some other magic in HAL > itself to pull out the supported standards. what we could do is exporting a bitmap from the kernel. However this should be done within a subsystem and not in a per driver approach. Only fixing this for USB serial devices is the wrong approach in my eyes. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: right place for CDMA / GSM modem IDs for usbserial autoloading?
Hi Greg, > > > > > I have no problem exporting a simple sysfs attribute showing if the > > > > > device is either CDMA or GSDM. I would think with that, HAL would not > > > > > need to keep any kind of tables at all, and then the device info only > > > > > has to stay in one place. > > > > > > > > This would be ideal. IIRC the only reason for keeping the tables was > > > > that there was no such attribute. Sounds about right Dan? > > > > > > Yes, that was correct. However, we should keep the current HAL > > > specification addition for a few reasons: > > > > > > 1) devices that are only supported by usb-serial; which includes things > > > that are not CDMA/GSM modems > > > > > > 2) devices that are PCMCIA serial cards (which are matched only on > > > class, not the manf IDs necessarily) > > > > > > 3) previous kernel versions that wouldn't have the magic sysfs attribute > > > > > > It would be worth exploring how to do this; but the problem is that > > > since there are devices that support both GSM and CDMA, we'd need to > > > figure out how to deal with that vs. sysfs-one-value-per-file. We > > > shouldn't really call them "GSM" and "CDMA" but use the standards names > > > as Marcel correctly pointed out on the HAL list. > > > > > > Thoughts greg? It would save us a huge .fdi file because then we could > > > simply match on the linux driver name, and do some other magic in HAL > > > itself to pull out the supported standards. > > > > what we could do is exporting a bitmap from the kernel. However this > > should be done within a subsystem and not in a per driver approach. Only > > fixing this for USB serial devices is the wrong approach in my eyes. > > It would be trivial to add this as a tty attribute, which would be the > correct place, right? for now, yes. However if we wanna handle binary/vendor protocols that encapsulate AT commands etc., then it might be not a good idea. Exporting everything as TTY devices seems to bad. However that is what we currently doing for everything in this area. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: right place for CDMA / GSM modem IDs for usbserial autoloading?
Hi Greg, > > > > I have no problem exporting a simple sysfs attribute showing if the > > > > device is either CDMA or GSDM. I would think with that, HAL would not > > > > need to keep any kind of tables at all, and then the device info only > > > > has to stay in one place. > > > > > > This would be ideal. IIRC the only reason for keeping the tables was > > > that there was no such attribute. Sounds about right Dan? > > > > Yes, that was correct. > > > > It's not like the kernel is immutable people. If you need to work > around something you find strange in the kernel, or the kernel is not > exporting something that you need for userspace to work easier, please > ask the kernel developers! Otherwise we don't know there's an issue at > all. It's not like it is hard to find and get ahold of us... > > > However, we should keep the current HAL > > specification addition for a few reasons: > > > > 1) devices that are only supported by usb-serial; which includes things > > that are not CDMA/GSM modems > > Like what? NO DEVICES THAT ARE MODEMS SHOULD BE USING THE GENERIC > USB-SERIAL DRIVER!!! Do I need to say this again somewhere else? They > should ALL have a "real" usb-serial child driver to allow for proper > flow control, auto-loading of drivers, and the ability to actually send > data at a speed that isn't comparible to RFC 1149. > > > 2) devices that are PCMCIA serial cards (which are matched only on > > class, not the manf IDs necessarily) > > These devices are no longer being manufactured from what I can tell. So > that list should be fixed. > > > 3) previous kernel versions that wouldn't have the magic sysfs attribute > > Sure, but don't go adding new devices to the table, as that would be > wrong. > > > It would be worth exploring how to do this; but the problem is that > > since there are devices that support both GSM and CDMA, we'd need to > > figure out how to deal with that vs. sysfs-one-value-per-file. We > > shouldn't really call them "GSM" and "CDMA" but use the standards names > > as Marcel correctly pointed out on the HAL list. > > Why not have two files, one that shows up if GSM is supported, one if > CDMA is. Modems that support both would export both. It's up to > userspace to pick which to use, the kernel sure doesn't care. please see Dan's and my comments. We are not interested in the radio technology. We care about the "command set". If we wanna do it inside the kernel, then I would simply export a bitmap and then let HAL map this properly into HAL properties/lists. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: right place for CDMA / GSM modem IDs for usbserial autoloading?
On Mon, 2008-02-25 at 11:38 -0800, Greg KH wrote: > On Mon, Feb 25, 2008 at 01:32:04PM -0500, Dan Williams wrote: > > On Mon, 2008-02-25 at 03:07 -0500, David Zeuthen wrote: > > > On Sun, 2008-02-24 at 21:18 -0800, Greg KH wrote: > > > > I have no problem exporting a simple sysfs attribute showing if the > > > > device is either CDMA or GSDM. I would think with that, HAL would not > > > > need to keep any kind of tables at all, and then the device info only > > > > has to stay in one place. > > > > > > This would be ideal. IIRC the only reason for keeping the tables was > > > that there was no such attribute. Sounds about right Dan? > > > > Yes, that was correct. > > > > It's not like the kernel is immutable people. If you need to work > around something you find strange in the kernel, or the kernel is not > exporting something that you need for userspace to work easier, please > ask the kernel developers! Otherwise we don't know there's an issue at > all. It's not like it is hard to find and get ahold of us... > > > However, we should keep the current HAL > > specification addition for a few reasons: > > > > 1) devices that are only supported by usb-serial; which includes things > > that are not CDMA/GSM modems > > Like what? NO DEVICES THAT ARE MODEMS SHOULD BE USING THE GENERIC > USB-SERIAL DRIVER!!! Do I need to say this again somewhere else? They > should ALL have a "real" usb-serial child driver to allow for proper > flow control, auto-loading of drivers, and the ability to actually send > data at a speed that isn't comparible to RFC 1149. > > > 2) devices that are PCMCIA serial cards (which are matched only on > > class, not the manf IDs necessarily) > > These devices are no longer being manufactured from what I can tell. So > that list should be fixed. Yeah, that should be fixed. > > 3) previous kernel versions that wouldn't have the magic sysfs attribute > > Sure, but don't go adding new devices to the table, as that would be > wrong. Right; but I want to preserve the ability for distros to ship .fdi files that tag the devices correctly even if the distro isn't using a kernel that contains the new sysfs stuff. > > It would be worth exploring how to do this; but the problem is that > > since there are devices that support both GSM and CDMA, we'd need to > > figure out how to deal with that vs. sysfs-one-value-per-file. We > > shouldn't really call them "GSM" and "CDMA" but use the standards names > > as Marcel correctly pointed out on the HAL list. > > Why not have two files, one that shows up if GSM is supported, one if > CDMA is. Modems that support both would export both. It's up to > userspace to pick which to use, the kernel sure doesn't care. I'd caution against calling them "gsm" and "cdma", hence why we picked the actual standards name for the HAL spec. It's not really about the PHY modulation (since UMTS/HSPA uses 5MHz WCDMA) but it's about what commands the chipset supports through the serial interface, which is defined by the standards the card supports. Should there be another directory for the standards supported under which can be "is-707-a" and "gsm-07.07"/"gsm-07.05"? That seems kind of odd. Dan > Sound reasonable? > > thanks, > > greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] pxa2xx_udc: fix clock setup
Currently pxa2xx_udc spits this warning:
WARNING: at arch/arm/mach-pxa/clock.c:86 clk_disable+0x48/0xb0()
Modules linked in:
[] (dump_stack+0x0/0x14) from []
(warn_on_slowpath+0x4c/0x60)
[] (warn_on_slowpath+0x0/0x60) from []
(clk_disable+0x48/0xb0)
r6:c02162fc r5:c02178f0 r4:f260
[] (clk_disable+0x0/0xb0) from [] (udc_disable+0x54/0x68)
r5:c0222e08 r4:f260
[] (udc_disable+0x0/0x68) from []
(pxa2xx_udc_probe+0x194/0x2c0)
r5:c0216304 r4:c0222e08
[] (pxa2xx_udc_probe+0x0/0x2c0) from []
(platform_drv_probe+0x20/0x24)
...
This happens because udc_probe tries to disable clock that isn't
yet enabled (udc_probe() calls udc_disable() to reinit hardware).
That warning isn't a fluffy one. That is, on ARCH_PXA, pxa2xx_udc
isn't functional without the patch below, because when clk_disable()
called on the already disabled clock, this will turn clk->enabled to
-1, and then clk_enable() will blank shot, see arch/arm/mach-pxa/clock.c:
int clk_enable(struct clk *clk)
{
...
if (clk->enabled++ == 0)
clk->ops->enable(clk);
...
}
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
drivers/usb/gadget/pxa2xx_udc.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/pxa2xx_udc.c b/drivers/usb/gadget/pxa2xx_udc.c
index 4402d6f..f2ba235 100644
--- a/drivers/usb/gadget/pxa2xx_udc.c
+++ b/drivers/usb/gadget/pxa2xx_udc.c
@@ -929,7 +929,7 @@ static int pxa2xx_udc_wakeup(struct usb_gadget *_gadget)
static void stop_activity(struct pxa2xx_udc *, struct usb_gadget_driver *);
static void udc_enable (struct pxa2xx_udc *);
-static void udc_disable(struct pxa2xx_udc *);
+static void udc_disable(struct pxa2xx_udc *, bool);
/* We disable the UDC -- and its 48 MHz clock -- whenever it's not
* in active use.
@@ -947,7 +947,7 @@ static int pullup(struct pxa2xx_udc *udc, int is_active)
: "(no driver)");
stop_activity(udc, udc->driver);
}
- udc_disable(udc);
+ udc_disable(udc, true);
}
return 0;
}
@@ -1134,7 +1134,7 @@ static const struct file_operations debug_fops = {
/*
* udc_disable - disable USB device controller
*/
-static void udc_disable(struct pxa2xx_udc *dev)
+static void udc_disable(struct pxa2xx_udc *dev, bool enabled)
{
/* block all irqs */
udc_set_mask_UDCCR(UDCCR_SRM|UDCCR_REM);
@@ -1148,7 +1148,8 @@ static void udc_disable(struct pxa2xx_udc *dev)
#ifdef CONFIG_ARCH_PXA
/* Disable clock for USB device */
- clk_disable(dev->clk);
+ if (enabled)
+ clk_disable(dev->clk);
#endif
ep0_idle (dev);
@@ -2183,7 +2184,7 @@ static int __init pxa2xx_udc_probe(struct platform_device
*pdev)
the_controller = dev;
platform_set_drvdata(pdev, dev);
- udc_disable(dev);
+ udc_disable(dev, false);
udc_reinit(dev);
dev->vbus = is_vbus_present();
@@ -2269,7 +2270,7 @@ static int __exit pxa2xx_udc_remove(struct
platform_device *pdev)
if (dev->driver)
return -EBUSY;
- udc_disable(dev);
+ udc_disable(dev, true);
remove_debug_files(dev);
if (dev->got_irq) {
--
1.5.4.3
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OHCI resume broken since 2.6.24
On Sat, Feb 23, 2008 at 07:54:36PM -0800, David Brownell wrote: > > When I suspend-to-RAM my HP nx6325 laptop with no device connected to > > the OHCI port, the port will not be active after resuming. > > So I'd think any problem is related to the EHCI linkage, and > maybe even something that's specific to your system. You could > verify that by "rmmod ehci-hcd" before suspending. I've done two things: [connect USB mouse] [disconnect USB mouse] chopin:/home/adi# rmmod ehci_hcd [suspend] [resume] [connect USB mouse, nothing happens] chopin:/home/adi# modprobe ehci_hcd [nothing happens] chopin:/home/adi# rmmod ohci_hcd chopin:/home/adi# modprobe ohci_hcd [USB mouse is getting detected] On the other hand, when I use a USB2.0 device instead of the mouse, suspend/resume works without unloading/reloading any module. The port is handled by ehci_hcd. So as mentioned earlier: the problem only exists with ohci_hcd controlled devices being physically disconnected before suspend. > Does this failure happen in 2.6.25-rc2 as well? (You might > wait what I suspect will be a couple days for RC3 to appear.) I've checked with 2.6.25-rc3, no cure. Here are the 2.6.24.1-logs *after* resume and with the USB mouse plugged in, but only being detected after rmmod ohci_hcd ; modprobe ohci_hcd: [rmmod ohci_hcd] Feb 25 22:19:32 chopin kernel: ohci_hcd :00:13.1: remove, state 1 Feb 25 22:19:32 chopin kernel: usb usb3: USB disconnect, address 1 Feb 25 22:19:32 chopin kernel: usb 3-1: USB disconnect, address 6 Feb 25 22:19:32 chopin kernel: ohci_hcd :00:13.1: USB bus 3 deregistered Feb 25 22:19:32 chopin kernel: ACPI: PCI interrupt for device :00:13.1 disabled Feb 25 22:19:32 chopin kernel: ohci_hcd :00:13.0: remove, state 4 Feb 25 22:19:32 chopin kernel: usb usb2: USB disconnect, address 1 Feb 25 22:19:32 chopin kernel: ohci_hcd :00:13.0: USB bus 2 deregistered Feb 25 22:19:32 chopin kernel: ACPI: PCI interrupt for device :00:13.0 disabled [modprobe ohci_hcd] Feb 25 22:21:14 chopin kernel: ACPI: PCI Interrupt :00:13.0[A] -> GSI 19 (level, low) -> IRQ 19 Feb 25 22:21:14 chopin kernel: ohci_hcd :00:13.0: OHCI Host Controller Feb 25 22:21:14 chopin kernel: ohci_hcd :00:13.0: new USB bus registered, assigned bus number 2 Feb 25 22:21:14 chopin kernel: ohci_hcd :00:13.0: irq 19, io mem 0xd4401000 Feb 25 22:21:14 chopin kernel: usb usb2: configuration #1 chosen from 1 choice Feb 25 22:21:14 chopin kernel: hub 2-0:1.0: USB hub found Feb 25 22:21:14 chopin kernel: hub 2-0:1.0: 4 ports detected Feb 25 22:21:15 chopin kernel: ACPI: PCI Interrupt :00:13.1[A] -> GSI 19 (level, low) -> IRQ 19 Feb 25 22:21:15 chopin kernel: ohci_hcd :00:13.1: OHCI Host Controller Feb 25 22:21:15 chopin kernel: ohci_hcd :00:13.1: new USB bus registered, assigned bus number 3 Feb 25 22:21:15 chopin kernel: ohci_hcd :00:13.1: irq 19, io mem 0xd4402000 Feb 25 22:21:15 chopin kernel: usb usb3: configuration #1 chosen from 1 choice Feb 25 22:21:15 chopin kernel: hub 3-0:1.0: USB hub found Feb 25 22:21:15 chopin kernel: hub 3-0:1.0: 4 ports detected Feb 25 22:21:15 chopin kernel: usb 2-3: new low speed USB device using ohci_hcd and address 2 Feb 25 22:21:15 chopin kernel: usb 2-3: configuration #1 chosen from 1 choice Feb 25 22:21:15 chopin kernel: input: Logitech USB-PS/2 Optical Mouse as /class/input/input16 Feb 25 22:21:15 chopin kernel: input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-:00:13.0-3 Feb 25 22:21:16 chopin kernel: usb 3-1: new full speed USB device using ohci_hcd and address 2 Feb 25 22:21:16 chopin kernel: usb 3-1: configuration #1 chosen from 1 choice HTH -- mail: [EMAIL PROTECTED] http://adi.thur.de PGP/GPG: key via keyserver Warum gräbst du ein vier Wochen altes posting aus? Geh einfach sterben. Das wäre für dich doch ein schöner Vorsatz fürs neue Jahr. (Felix Deutsch) - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] mass storage : emulation of sat scsi_pass_thru with ATACB
Hi,
I have got a cypress usb-ide bridge and I would like to tune or monitor
my disk with tools like hdparm, hddtemp or smartctl.
My controller support a way to send raw ATA command to the disk with
something call atacb (see
http://download.cypress.com.edgesuite.net/design_resources/datasheets/contents/cy7c68300c_8.pdf).
First I start to add support for atacb in applications like smartctl.
But there is some disadvantages :
- I need to patch all application
- A race is possible if there other accesses, because the emulation can
be split in 2 atacb scsi transactions. One for sending the command, one
for reading the register (if ck_cond is set).
So the idea to implement a SAT emulation for such device came to my mind.
First I want to ask, are there usb mass storage device that support SAT ?
After some reading it seems impossible. Mass storage transparent scsi
requires spc2 that only support fixed sense (starting with 0x70 or 0x71).
But SAT need a sense with descriptor defined in spc3 (starting with 0x72
or 0x73).
So SAT is not compatible with the sense format of mass storage ?
For doing the emulation, I want to provide a special proto_handler.
But I don't know what the best way to send command in my emulation layer :
should I use usb_stor_invoke_transport or directly use us->transport.
using usb_stor_invoke_transport save me lot's trouble of implementing
error handling, but I can't control what I do.
What should I do if I got an error after sending the first command and
ck_cond is set ? Should I still try to read the register ?
Is it safe to try to read the register if the first command did
autosense ? Or should I only send the command, and read the register and
compute the sense key, asc and ascq from registers ?
For the moment, my "draft" code look something like [1].
Any comments ?
Matthieu
[1]
void usb_stor_transparent_scsi_command_atacb(struct scsi_cmnd *srb,
struct us_data *us)
{
if (srb->cmnd[0] != ATA_16) {
usb_stor_invoke_transport(srb, us);
return;
}
if (srb->cmnd[0] == ATA_16) {
unsigned char save_cmnd[MAX_COMMAND_SIZE];
memcpy(save_cmnd, srb->cmnd, sizeof(save_cmnd));
memset(srb->cmnd, 0, sizeof(srb->cmnd));
/* first rebuild the command */
srb->cmnd[0] = 0x24;
srb->cmnd[1] = 0x24;
srb->cmnd[2] = 0;
/* realy needed ? isd200 don't do that */
if (save_cmnd[14] == WIN_PIDENTIFY || save_cmnd[14] ==
WIN_IDENTIFY)
srb->cmnd[2] |= (1<<7);
srb->cmnd[3] = 0xff - 1;
srb->cmnd[4] = 1;
srb->cmnd[6] = save_cmnd[4];
srb->cmnd[7] = save_cmnd[6];
srb->cmnd[8] = save_cmnd[8];
srb->cmnd[9] = save_cmnd[10];
srb->cmnd[10] = save_cmnd[12];
srb->cmnd[11] = save_cmnd[13];
srb->cmnd[12] = save_cmnd[14];
/* XXX check of lba48 flied are set */
if (save_cmnd[1] & 0x01) {/* extended bit set */
if (save_cmnd[3] || save_cmnd[5] || save_cmnd[7] ||
save_cmnd[9]
|| save_cmnd[11])
printk("unsupported LBA48\n");
}
usb_stor_invoke_transport(srb, us);
if ((srb->result != (DID_ERROR << 16) &&
srb->result != (DID_ABORT << 16)) &&
save_cmnd[2] & 0x20) { /* ck_cond */
/* read regs and put them in sense */
int temp_result;
struct scsi_eh_save ses;
unsigned char sk, asc, ascq;
unsigned char regs[8];
unsigned char *sb = srb->sense_buffer;
unsigned char *desc = sb + 8;
/* usb_stor_invoke_transport should do that when
clearing sense */
if (sb[0] == 0)
memset(sb, 0, sizeof(srb->sense_buffer));
/* save sense info */
sk = sb[2];
asc = sb[12];
ascq = sb[13];
/* read registers */
srb->cmnd[2] = 1;
scsi_eh_prep_cmnd(srb, &ses, NULL, 0, 0);
srb->request_buffer = regs;
srb->request_bufflen = sizeof(regs);
srb->sc_data_direction = DMA_FROM_DEVICE;
usb_stor_invoke_transport(srb, us);
/* XXX check error here */
scsi_eh_restore_cmnd(srb, &ses);
/* build the sense */
sb[1] = sk;
[PATCH 001/001] usb: Add support for the mos7820/7840-based B&B USB/RS485 converter to mos7840.c
From: David Ludlow <[EMAIL PROTECTED]>
Add support for the mos7820/7840-based B&B USOPTL4_2/USOPTL4_4 USB/RS485
converter to mos7840.c
Signed-off-by: Dave Ludlow <[EMAIL PROTECTED]>
---
DTR needs to be set/raised to receive and clear/lowered to send, as per the
mos7840 datasheet.
--- linux-2.6.25-rc2/drivers/usb/serial/mos7840.c.orig 2008-02-25
15:13:42.0 -0500
+++ linux-2.6.25-rc2/drivers/usb/serial/mos7840.c 2008-02-25
15:20:54.0 -0500
@@ -110,11 +110,20 @@
/* vendor id and device id defines */
+/* The native mos7840/7820 component */
#define USB_VENDOR_ID_MOSCHIP 0x9710
#define MOSCHIP_DEVICE_ID_7840 0x7840
#define MOSCHIP_DEVICE_ID_7820 0x7820
+/* The native component can have its vendor/device id's overridden
+ * in vendor-specific implementations. Such devices can be handled
+ * by making a change here, in moschip_port_id_table, and in
+ * moschip_id_table_combined
+ */
+#define USB_VENDOR_ID_BANDB 0x0856
+#define BANDB_DEVICE_ID_USOPTL4_4 0xAC44
+#define BANDB_DEVICE_ID_USOPTL4_2 0xAC42
-/* Interrupt Rotinue Defines*/
+/* Interrupt Routine Defines*/
#define SERIAL_IIR_RLS 0x06
#define SERIAL_IIR_MS 0x00
@@ -159,12 +168,16 @@
static struct usb_device_id moschip_port_id_table[] = {
{USB_DEVICE(USB_VENDOR_ID_MOSCHIP, MOSCHIP_DEVICE_ID_7840)},
{USB_DEVICE(USB_VENDOR_ID_MOSCHIP, MOSCHIP_DEVICE_ID_7820)},
+ {USB_DEVICE(USB_VENDOR_ID_BANDB, BANDB_DEVICE_ID_USOPTL4_4)},
+ {USB_DEVICE(USB_VENDOR_ID_BANDB, BANDB_DEVICE_ID_USOPTL4_2)},
{} /* terminating entry */
};
static __devinitdata struct usb_device_id moschip_id_table_combined[] = {
{USB_DEVICE(USB_VENDOR_ID_MOSCHIP, MOSCHIP_DEVICE_ID_7840)},
{USB_DEVICE(USB_VENDOR_ID_MOSCHIP, MOSCHIP_DEVICE_ID_7820)},
+ {USB_DEVICE(USB_VENDOR_ID_BANDB, BANDB_DEVICE_ID_USOPTL4_4)},
+ {USB_DEVICE(USB_VENDOR_ID_BANDB, BANDB_DEVICE_ID_USOPTL4_2)},
{} /* terminating entry */
};
begin:vcard
fn:David Ludlow
n:Ludlow;David
org:Bay;Research & Development
email;internet:[EMAIL PROTECTED]
title:Software Engineer
x-mozilla-html:FALSE
version:2.1
end:vcard
RE: Question regarding usb-serial based driver.
> > The sierra device has pair of endpoints (bulk in and bulk out) that > > sends the multiplexed protocols data packets ( two protocols data > > packets encapsulated in one). Lets call that endpoint pair as EP1. The > > one of the multiplexed protocol is DM and other is command and status. > > EP1 is attached to ttyUSB1. Our application reads from ttyUSB1 and > > ignores DM packets and considers only command and status packets. > > However to get DM stream working another application has to read/write > > to ttyUSB1 concurrently which is as tricky. Thus, I am trying to setup > > another virtual serial port called ttyUSB3 that can read/write to EP1 > > concurrently so that we get two duplicate streams. One of the stream > > (ttyUSB1) can be used by our existing application and another stream > > (ttyUSB3) can be used to set up DM logging.Internally however they > > will talk to same endpoint pair EP1. Is it doable? > > Yes, for something like this, a modification of the sierra driver would > be needed to allow for two buffers like this. > > But, you might want to work with the current developers of the sierra > driver, as I'm pretty sure they are working to add this kind of > functionality (alternate ways to control the card) to the driver for > this very reason. > > Is there a reason you have not just contacted them already? Hi Greg et al., Chetan is actually helping Sierra out with this feature and I was not able to be of much help regarding finding a solution in the kernel space. I saw that the network driver framework has the ability to register packet handlers to devices data streams via the dev_add_pack command, I was hoping that the usb_serial drivers might have similar functionality (I couldn't find any). -Kevin - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question regarding usb-serial based driver.
On Mon, Feb 25, 2008 at 03:44:19PM -0800, Kevin Lloyd wrote: > > > The sierra device has pair of endpoints (bulk in and bulk out) that > > > sends the multiplexed protocols data packets ( two protocols data > > > packets encapsulated in one). Lets call that endpoint pair as EP1. > The > > > one of the multiplexed protocol is DM and other is command and > status. > > > EP1 is attached to ttyUSB1. Our application reads from ttyUSB1 and > > > ignores DM packets and considers only command and status packets. > > > However to get DM stream working another application has to > read/write > > > to ttyUSB1 concurrently which is as tricky. Thus, I am trying to > setup > > > another virtual serial port called ttyUSB3 that can read/write to > EP1 > > > concurrently so that we get two duplicate streams. One of the stream > > > (ttyUSB1) can be used by our existing application and another stream > > > (ttyUSB3) can be used to set up DM logging.Internally however they > > > will talk to same endpoint pair EP1. Is it doable? > > > > Yes, for something like this, a modification of the sierra driver > would > > be needed to allow for two buffers like this. > > > > But, you might want to work with the current developers of the sierra > > driver, as I'm pretty sure they are working to add this kind of > > functionality (alternate ways to control the card) to the driver for > > this very reason. > > > > Is there a reason you have not just contacted them already? > Hi Greg et al., > > Chetan is actually helping Sierra out with this feature and I was not > able to be of much help regarding finding a solution in the kernel > space. Then please, let us know this kind of information in the beginning, without me having to drag it out of you all over the course of a week and 9 email exchanges. Don't be vague, it doesn't help anyone out, and wastes people's time. > I saw that the network driver framework has the ability to register > packet handlers to devices data streams via the dev_add_pack command, I > was hoping that the usb_serial drivers might have similar functionality > (I couldn't find any). No, the tty layer doesn't let you do this. Well, it could, if you create a new line discipline, but I really think you don't want to do that, it's quite difficult. Why not just use what Alan suggested? Do all of this logic in a userspace program? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question regarding usb-serial based driver.
> Then please, let us know this kind of information in the beginning, > without me having to drag it out of you all over the course of a week > and 9 email exchanges. Don't be vague, it doesn't help anyone out, and > wastes people's time. Right, miscommunication on our part. > > I saw that the network driver framework has the ability to register > > packet handlers to devices data streams via the dev_add_pack command, I > > was hoping that the usb_serial drivers might have similar functionality > > (I couldn't find any). > > No, the tty layer doesn't let you do this. Well, it could, if you > create a new line discipline, but I really think you don't want to do > that, it's quite difficult. > > Why not just use what Alan suggested? Do all of this logic in a > userspace program? We were hoping to have the DM stream output from a virtual serial port for easy & direct access for 3rd party developers (file handles are simple and straightforward to read/write from). My thought is that implementing this in a userspace daemon/program requires cross-process communication which I feel is a bit more complex (or is there a standard way for a userspace program to output to a virtual serial port to obtain the same net effect). Thanks, -Kevin - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question regarding usb-serial based driver.
On Mon, Feb 25, 2008 at 04:56:39PM -0800, Kevin Lloyd wrote: > > > I saw that the network driver framework has the ability to register > > > packet handlers to devices data streams via the dev_add_pack > command, I > > > was hoping that the usb_serial drivers might have similar > functionality > > > (I couldn't find any). > > > > No, the tty layer doesn't let you do this. Well, it could, if you > > create a new line discipline, but I really think you don't want to do > > that, it's quite difficult. > > > > Why not just use what Alan suggested? Do all of this logic in a > > userspace program? > We were hoping to have the DM stream output from a virtual serial port > for easy & direct access for 3rd party developers (file handles are > simple and straightforward to read/write from). My thought is that > implementing this in a userspace daemon/program requires cross-process > communication which I feel is a bit more complex (or is there a standard > way for a userspace program to output to a virtual serial port to obtain > the same net effect). But is the "DM stream output" really a tty port at all? If not, shouldn't you create a new character device node that can have this data exported to it? Then have the driver siphon off the data and put it in the buffer for that "pipe". However, I really don't know the protocol you all are using here, and what it would take to parse this kind of information in the kernel, so I can't easily judge which would be the easiest way to do this. Try it and see :) good luck, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pxa2xx_udc: fix clock setup
On Monday 25 February 2008, Anton Vorontsov wrote: > > pxa2xx_udc isn't functional without the patch below, ... Is this not already fixed by http://marc.info/?l=linux-usb&m=120372945519098&w=2 ? Agreed this is a must-merge for 2.6.25. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question regarding usb-serial based driver.
Kevin Lloyd wrote: > My thought is that > implementing this in a userspace daemon/program requires cross-process > communication which I feel is a bit more complex (or is there a standard > way for a userspace program to output to a virtual serial port to obtain > the same net effect). Perhaps pty's might help? One pty for each virtual port, and a single daemon to control them. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
USB Host to Host Communication
Hi , I am new to Device driver. I am developing a USB device driver in LInux Platform for a host to host communication. Do you have any documents which tells how to do USB host to host commmunication or a driver code for the same. Please help me in this issue. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: USB Host to Host Communication
Hi: Do you mean host to hub or really host to host? According usb spec, no matter ehci or usb2.0, if one plays the role as host, another one have the responsibility to receive different schedules, Asynchronous and period, and this will make this one plays the role as device. It seems unreasonable if you designed two hosts that only send the schedules without receiving anything. Sincerely Yours, vichy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of krishna prasath Sent: Tuesday, February 26, 2008 1:57 PM To: linux-usb@vger.kernel.org Subject: USB Host to Host Communication Hi , I am new to Device driver. I am developing a USB device driver in LInux Platform for a host to host communication. Do you have any documents which tells how to do USB host to host commmunication or a driver code for the same. Please help me in this issue. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB Host to Host Communication
On Monday 25 February 2008, krishna prasath wrote: > Hi , > > I am new to Device driver. I am developing a USB device driver > in LInux Platform for a host to host communication. Do you have any > documents which tells how to do USB host to host commmunication or a > driver code for the same. Please help me in this issue. For network oriented communication: http://www.linux-usb.org/usbnet/ That uses specialized host-to-host cables. If Linux is running inside the USB peripheral, one wouldn't call it a "host" in USB terms (even though it would be a host in the TCP/IP sense). - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
