Re: gpio-exar: Why filtering out Commtech devices?

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2017-05-23 22:05, Technical Support wrote:
> ​Our kernel module handles card specific MPIO setup, ensuring the pins
> are set correctly for our hardware regardless of what exar_8250
> initializes them as.   
> 
> https://github.com/commtech/serialfc-linux/blob/784e1321e00d4f72c93dae8da11cdc7f99c15dee/src/utils.c#L1463-L1491

OK, that code shows what we need to do in the official driver: handle
the commtech devices like before, i.e. keep the GPIOs as output for
them. I'll update my patch.


But now some good advice: you should rather work on the upstream code
and schedule your special driver for retirement. This will ensure that
your users have the best experience when they plug in any of your cards
and boot a standard Linux disto: it will just work.

Right now, your out-of-tree driver competes with the official one for
the same resources, apparently comes with own userspace interfaces to
configure special features instead of building on existing APIs (you
don't support TIOCSRS485 e.g., do you?), and seems to contain support
for a number of cards that are still missing in upstream. This is very
unhandy for your users.

For the same reason, we are currently upstreaming the code for our
Exar-based design (and that's why I came across all this): We want to
get rid of special board support to improve user experience and
long-term availability.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux