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:   Wed, 30 Oct 2019 10:00:12 +0800
From:   "Ji-Ze Hong (Peter Hong)" <hpeter@...il.com>
To:     Johan Hovold <johan@...nel.org>
Cc:     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 7/7] USB: serial: f81232: Add gpiolib to GPIO device

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.

Is any suggest about this ? Could I maintain this for this series patch?

>> +
>> +	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 ?

Thanks

-- 
With Best Regards,
Peter Hong

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ