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]
Message-ID: <18f4b5cb-cba0-aab4-7958-84a5b8d28935@siemens.com>
Date:   Sun, 21 May 2017 13:46:01 +0200
From:   Jan Kiszka <jan.kiszka@...mens.com>
To:     Sudip Mukherjee <sudip.mukherjee@...ethink.co.uk>
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: gpio-exar: Why filtering out Commtech devices?

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.

Jan

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ