linux-kernel - Re: [PATCH V2 5/7] USB: serial: f81232: Set F81534A serial port with RS232 mode

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:   Mon, 13 Jan 2020 16:17:32 +0100
From:   Johan Hovold <johan@...nel.org>
To:     "Ji-Ze Hong (Peter Hong)" <hpeter@...il.com>
Cc:     Johan Hovold <johan@...nel.org>, gregkh@...uxfoundation.org,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
        peter_hong@...tek.com.tw,
        "Ji-Ze Hong (Peter Hong)" <hpeter+linux_kernel@...il.com>
Subject: Re: [PATCH V2 5/7] USB: serial: f81232: Set F81534A serial port with
 RS232 mode

On Thu, Jan 09, 2020 at 10:37:09AM +0800, Ji-Ze Hong (Peter Hong) wrote:
> Hi Johan,
> 
> Johan Hovold 於 2020/1/8 下午 10:35 寫道:
> >> Yes, when 1 F81534A connect to Host, it'll report device as following.
> >> 	virtual HUB
> >> 		GPIO Device.
> >> 		serial port 1
> >> 		...
> >> 		serial port n
> > 
> > Could you post lsusb -v output for this with a couple of UARTs enabled?
> 
> The following lsusb log is F81536 informations
> 2c42:1608 => HUB
> 2c42:16f8 => GPIO device
> 2c42:163x => UART (need driver enable)

> *after insmod driver and wait for complete

> Bus 001 Device 053: ID 2c42:1636
> Bus 001 Device 044: ID 2c42:16f8
> Bus 001 Device 043: ID 2c42:1608

Can you post verbose ("lsusb -v") output for the three device types for
completeness?

> >> The link are F81534A pin-out:
> >> 	https://imgur.com/a/AZHqQ1N
> > 
> > Do you have a datasheet for the device?
> > 
> > I think I'm starting to get an idea of how this work, but I really don't
> > like having to spend this much time on detective work just to understand
> > how the hw works.
> 
> The following link is F81536 spec:
> https://drive.google.com/drive/folders/1oA8DvpevFXoTLCDfPZHzaBWKr32ch5xc?usp=sharing

Thanks!

> >> So we can control F81534A series all GPIO pins via GPIO Device.
> >> Serial ports are also control MODE0_x,  MODE1_x,  MODE2_x
> >> (e.g. UART1 MODE0_1,  MODE1_1,  MODE2_1), but when Serial ports
> >> is h/w disabled (DTR pull low), the mode pin will change to GPIO pin.
> > 
> > So you tie a ports DTR pin, even though it's normally an output, and use
> > that at boot to determine whether the UART should be enabled or not?
> > 
> > And the GPIO device can only control a pin if the corresponding port is
> > disabled?
> > 
> > Can you read back the enable state of each port?
> 
> DTR pin of the F81534A series are strap pin on power on, when IC detect
> it pulled to low, the UART device can't enable and DTR change to input
> mode.

Can you read back the state of the DTR pin when pulled low? So that you
can determine which UARTs have been disabled in hardware?

> I can read the UART enable state from GPIO Device, so I can do when the
> GPIO is associated with UART enabled, change it as output only otherwise
> can be set to input/output. Is this OK ??

I'm leaning more towards not exporting this as a gpio device at all.
It's clear from the datasheet (and your implementation) that these pins
are supposed to be used with your own tranceivers. You can start with
only supporting RS232, and then we can discuss an interface for
switching modes later.

> > What about devices using a different tranceiver? Should the state of the
> > mode pins ultimately be tied to VID/PID (can your customers change
> > VID/PID)?
> > 
> 
> Our device VID/PID is changeable, but we assume don't change it.

Ok, then I guess we must assume that the MODE pins are only connected to
your tranceivers and hardcoding the various configurations is fine.

Johan