linux-kernel - Re: Resend Re: [PATCH v6] usb:serial:pl2303: add GPIOs interface on PL2303

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 12 Aug 2014 16:02:59 +0200
From:	Johan Hovold <johan@...nel.org>
To:	Wang YanQing <udknight@...il.com>
Cc:	Johan Hovold <johan@...nel.org>, gregkh@...uxfoundation.org,
	linus.walleij@...aro.org, jhovold@...il.com, andi@...as.de,
	dforsi@...il.com, gnomes@...rguk.ukuu.org.uk,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Resend Re: [PATCH v6] usb:serial:pl2303: add GPIOs interface on
 PL2303

On Sat, Aug 09, 2014 at 02:46:56AM +0800, Wang YanQing wrote:
> On Fri, Aug 08, 2014 at 09:54:42AM +0200, Johan Hovold wrote:
> > On Fri, Aug 08, 2014 at 03:10:34AM +0800, Wang YanQing wrote:
> > > On Tue, Aug 05, 2014 at 03:54:08PM +0200, Johan Hovold wrote:
> > > > > > I noticed that setting direction to output and setting the gpio high has
> > > > > > no effect on the read-back value (i.e. I still read back 0) for my
> > > > > > pl2303hx (note that my device has no easily accessible gpios so I
> > > > > > haven't verified the actual state of the output pin).
> > > > > > 
> > > > > > What happens on your system? Is the read-back value still 0, even when
> > > > > > the GPIO output is actually high? Should we return the cached value in
> > > > > > this case?
> > > > > 
> > > > > If i set direction to output, then I could control gpio high and low
> > > > > by set 1 or 0, and the read-back value is 1 or 0 according to high and
> > > > > low(I test high and low by oscillscope)
> > > > > 
> > > > > I test it with my pl2303hx with only two gpios.
> > > > >
> > > > > Could you use usbmon to see whether the traffic is right according
> > > > > to comment in struct pl2303_gpio?
> > > > 
> > > > The traffic appears correct judging from the debug output (which I
> > > > trust). Output-enable is reflected in register 0x81, but the value
> > > > isn't.
> > > > 
> > > > What is the lsusb -v output for your device?
> > > 
> > > Bus 001 Device 005: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port.
> > 
> > You forgot the verbose flag (-v).
> Sorry, below is output with -v:
> Bus 002 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
> Device Descriptor:
>   bLength                18
>   bDescriptorType         1
>   bcdUSB               1.10
>   bDeviceClass            0 (Defined at Interface level)
>   bDeviceSubClass         0 
>   bDeviceProtocol         0 
>   bMaxPacketSize0        64
>   idVendor           0x067b Prolific Technology, Inc.
>   idProduct          0x2303 PL2303 Serial Port
>   bcdDevice            3.00

You seem to have an HX device, whereas mine is an HXD (rev D) with
bcdDevice 4.00. That could account for the different behaviour of the
GPIO state/value register.

How did you figure out which registers to use? Were you sniffing the
traffic of some driver for some other OS? And does your device only have
two GPIOs and not four like the HX rev D?

<snip>

> > > It is strange your device doesn't work, I verify the control method by
> > > analyze usbmon output from linux host which has VirtualBox running 
> > > gpio test program, but I don't have right to distribute the gpio test
> > > program I think, so I can't help you to figure out why it doesn't work 
> > > for your device.
> > 
> > What do you use the gpio test program for? I thought you verified the
> > gpios with a scope?
> 
> Yes, I verified gpios with a scope.
> 
> "
> You must allocate the buffer dynamically as some platforms cannot do
> DMA to the stack.
> "
> Thanks very much for point out it, could you clarify it? 
> I want to know the reason.

The memory where the stack resides might not be available for DMA, and
even if it is, there could still be problems with cache coherency.

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/