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

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>] [day] [month] [year] [list]

Message-ID: <e541be56-c61c-358b-91ed-ce1e513c1ccc@siemens.com>
Date:   Tue, 23 May 2017 23:16:42 +0200
From:   Jan Kiszka <jan.kiszka@...mens.com>
To:     Technical Support <techsupport@...mtech-fastcom.com>
Cc:     Sudip Mukherjee <sudip.mukherjee@...ethink.co.uk>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-serial <linux-serial@...r.kernel.org>,
        linux-gpio <linux-gpio@...r.kernel.org>
Subject: Re: gpio-exar: Why filtering out Commtech devices?

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