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

Message-ID: <7a25751e-931f-b713-dcdd-7a7483aae115@codethink.co.uk>
Date:   Sun, 21 May 2017 21:08:41 +0100
From:   Sudip Mukherjee <sudip.mukherjee@...ethink.co.uk>
To:     Jan Kiszka <jan.kiszka@...mens.com>,
        Matt Schulte <matts@...mtech-fastcom.com>
Cc:     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?

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.


-- 
Regards
Sudip