On Wed, Oct 30, 2019 at 10:00:12AM +0800, Ji-Ze Hong (Peter Hong) wrote: > Hi Johan, > > Johan Hovold 於 2019/10/23 下午 08:22 寫道: > > On Mon, Sep 23, 2019 at 10:24:49AM +0800, Ji-Ze Hong (Peter Hong) wrote: > >> The Fintek F81534A series contains 3 GPIOs per UART and The max GPIOs > >> is 12x3 = 36 GPIOs and this patch will implements GPIO device as a > >> gpiochip to control all GPIO pins even transforms to transceiver pins. > > > > Depending to your answer to my question whether these pins are truly > > general purpose or not, this may not be the right interface. > > Our F81534A series contains F81532A/534A/535/536. For the following link > of F81534A pin-out: > https://imgur.com/a/AZHqQ1N > > We had 2 type about GPIO pins, MODEx_y & GPIOxx. All MODEx_y & GPIOxx > are GPIOs and can be controlled by GPIO device, but they had some > difference about usage. > MODEx_y: > 1. 3 pins(x: 0/1/2) can be access by UART port y. > 2. Used to control UART's transceiver normally, but it > also can be configure as GPIO when UART disabled by > H/W (DTR strap to GND). > GPIOxx: > 1. Access only by GPIO device. > > The series patch only support RS233 mode for all serial port, So we'll > direct set all MODEx_y to (0/0/1) for our demo board for default. If > user really want to use the pin, we had provide the gpiolib with GPIO > device, but we'll recommend user to use GPIOxy first. Do you mean that you'd need to register a separate gpio chip per port in order to expose an interface for changing the MODEx_y pins for an enabled UART? Or can you do that through the "global" gpio device? > Is any suggest about this ? Could I maintain this for this series patch? I understood from your other mail that the gpio device would not be able to control the pins of an enabled port. In either case, I think you need to refuse a request for a pin that's already in use by the corresponding port. Also is there a way to determine the number of available pins by detecting the chip/package type? I'm assuming not all 36 pins are always accessible? > >> + status = devm_gpiochip_add_data(&intf->dev, &priv->chip, priv); > >> + if (status) { > >> + dev_err(&intf->dev, "failed to register gpiochip: %d\n", > >> + status); > >> + return status; > >> + } > > > > Have you tried disconnecting the device with gpios requested? This used > > to break gpiolib, but was fixed. Just want to make sure it hasn't > > regressed. > > I had try export GPIOs and detach the F81534A in kernel 5.0.0, it seems > no problem. Is any link about this issue for me to do more test ? Then it's hopefully fine. Thanks for verifying. Johan
