On Fri, Jan 22, 2016 at 03:44:16PM +0200, Andy Shevchenko wrote:

On Fri, Jan 22, 2016 at 12:53 PM, Sudip Mukherjee
[off-list ref] wrote:

quoted

On Wed, Jan 20, 2016 at 04:24:36PM +0800, Peter Hung wrote:

quoted

Hi Sudip,

Sudip Mukherjee 於 2016/1/20 下午 02:22 寫道:

quoted

On Wed, Jan 20, 2016 at 10:59:28AM +0800, Peter Hung wrote:

quoted

But my personal opinion, if we move out the serial port related code
into a new driver (a new Kconfig symbol) userspace of many system will
break if this new symbol is not enabled by the distributions. But in the
way I have done the new symbol needs to be enabled only if the user
wants to use the GPIO capability. If that is not enabled GPIO cannot be
used but it will never break the serial port related code for them.
I think we should give a thought to that before splitting out the codes
from 8250_pci.

I agree with your opinion. I'm trying to implement GPIO with 2 ways,
One is like yours, add platform_device with in 8250_pci.c and implement
GPIOLIB platform driver with in 'driver/gpio", and the other is trying
split out from 8250_pci.c to MFD.

In my personal opinion, the first method is less impact with compatible
old system.

Looks like no one else is in support of our opinion. Fair enough, I will
split out the related code from 8250_pci and create the MFD driver this
weekend for my hardware.

Yeah, MFD looks preferable.

Btw, don't forget to backlist your devices in 8250_pci since they
quite possible provide a PCI class which is used by 8250_pci driver
for default enumeration.

One doubt. If I have understood correctly the main reason you have asked
me to split the code out of 8250_pci so that the size reduces. But
pci_xr17v35x_setup() is also used by another card which has
PCI_VENDOR_ID_COMMTECH. So even if I create a separate file for exar cards,
almost identical function will still remain in 8250_pci.

regards
sudip