Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 8 Jan 2020 15:46:00 +0100
From:   Johan Hovold <johan@kernel.org>
To:     "Ji-Ze Hong (Peter Hong)" <hpeter@gmail.com>
Cc:     Johan Hovold <johan@kernel.org>, gregkh@linuxfoundation.org,
        linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
        peter_hong@fintek.com.tw,
        "Ji-Ze Hong (Peter Hong)" <hpeter+linux_kernel@gmail.com>
Subject: Re: [PATCH V2 7/7] USB: serial: f81232: Add gpiolib to GPIO device
Message-ID: <20200108144600.GK30908@localhost>
References: <20190923022449.10952-1-hpeter+linux_kernel@gmail.com>
 <20190923022449.10952-8-hpeter+linux_kernel@gmail.com>
 <20191023122208.GW24768@localhost>
 <ef91b42d-e81d-ecdd-c688-0cb3f0b94906@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <ef91b42d-e81d-ecdd-c688-0cb3f0b94906@gmail.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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