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

Date:   Mon, 22 May 2017 18:24:33 +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-22 17:17, Technical Support wrote:
> Hello,
> 
> The Exar MPIO pins are used by our device driver to control features of
> the line driver and can't be used as GPIO pins.  I agree, the condition
> can be moved to 8250_exar prior to a platform device being created for
> the gpio_exar driver.
> 

Thanks a lot for the feedback! I will send a refactoring patch.

Jan

> Regards,
> Landon Unruh       
> 
> Commtech, Inc.
> Voice: 316-636-1131
> http://www.fastcomproducts.com
> 
> 
> 
> 
> On Mon, May 22, 2017 at 12:51 AM, Jan Kiszka <jan.kiszka@...mens.com
> <mailto:jan.kiszka@...mens.com>> wrote:
> 
>     On 2017-05-22 07:48, Jan Kiszka wrote:
>     > On 2017-05-21 22:08, Sudip Mukherjee wrote:
>     >> Hi Jan,
>     >>
>     >> On 21/05/17 12:46, Jan Kiszka wrote:
>     >>> Hi Sudip,
>     >>>
>     >>> why do we carry
>     >>>
>     >>>     if (pcidev->vendor != PCI_VENDOR_ID_EXAR)
>     >>>         return -ENODEV;
>     >>>
>     >>> in gpio_exar_probe? This effectively prevents that
>     >>>
>     >>>     EXAR_DEVICE(COMMTECH, COMMTECH_4222PCIE, pbn_exar_XR17V35x),
>     >>>     EXAR_DEVICE(COMMTECH, COMMTECH_4224PCIE, pbn_exar_XR17V35x),
>     >>>     EXAR_DEVICE(COMMTECH, COMMTECH_4228PCIE, pbn_exar_XR17V35x),
>     >>>
>     >>> gain GPIO support. Do those devices lack access to the pins? Or can we
>     >>> drop the filter. I don't have access to those devices, just wondering
>     >>> because the code is not explaining the reason.
>     >>
>     >> Same here. I do not have these devices and have no idea if they support
>     >> the gpio pins or not.
>     >>
>     >> Adding Matt Schulte in the Cc list, maybe he can comment.
>     >>
>     >>
>     >
>     > If we need to keep the condition, it should be moved over to 8250_exar:
>     > there is no point in creating the platform device at all then. But let's
>     > wait for Matt's comment.
> 
>     Unfortunately, his account is no longer existing. Is there anyone else
>     we can ask?
> 
>     Jan
> 
>     --
>     Siemens AG, Corporate Technology, CT RDA ITP SES-DE
>     Corporate Competence Center Embedded Linux
>     --
>     To unsubscribe from this list: send the line "unsubscribe
>     linux-serial" in
>     the body of a message to majordomo@...r.kernel.org
>     <mailto:majordomo@...r.kernel.org>
>     More majordomo info at  http://vger.kernel.org/majordomo-info.html
>     <http://vger.kernel.org/majordomo-info.html>
> 
>