On Fri, Dec 14, 2007 at 11:02:52AM -0800, Sarah Sharp wrote:
> On Thu, Dec 13, 2007 at 09:33:36PM -0800, Greg KH wrote:
> > On Thu, Dec 13, 2007 at 06:22:20PM -0800, Sarah Sharp wrote:
> > > Without this fix, the pl2303 usb-serial adapter with chip type_1
> > > would not suspend properly unless it had been opened first.
> > >
> > > A pl2303 type_1 chip will still break if the system is hibernated while
> > > the
> > > RS-232 connector is powered by another system. This was broken before,
> > > and a
> > > reset resume quirk does not fix it. All other suspend, hibernate, and
> > > autosuspend scenarios work with ATEN pl2303 adaptors with HX and type_1
> > > chips.
> > >
> > > Signed-off-by: Sarah Sharp <[EMAIL PROTECTED]>
> > > ---
> > > drivers/usb/serial/pl2303.c | 37 ++++++++++++++++++-------------------
> > > 1 files changed, 18 insertions(+), 19 deletions(-)
> > >
> > > diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
> > > index 15097a4..ab7f2b0 100644
> > > --- a/drivers/usb/serial/pl2303.c
> > > +++ b/drivers/usb/serial/pl2303.c
> > > @@ -336,6 +336,7 @@ static int pl2303_startup(struct usb_serial *serial)
> > > {
> > > struct pl2303_private *priv;
> > > enum pl2303_type type = type_0;
> > > + unsigned char buf;
> >
> > Sorry, but you can't send usb data on the stack, that is why we
> > dynamically allocate those tiny buffers.
> >
> On Fri, Dec 14, 2007 at 09:38:43AM +0100, Oliver Neukum wrote:
> > I am sorry, you can't do this. This is DMA on the stack. You must kmalloc
> > buf.
>
> So you can't pass a buffer on the stack, even when we know the stack is going
> to
> stick around because we're calling usb_control_msg() ? Is this because the
> URB
> completes in interrupt context?
No, it's because the usb host controller expects the memory to be
DMAable, and on some architectures, stack memory is not. x86 is fine,
that's why it worked for you.
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