linux-kernel - Re: [PATCH] parport: parport_pc: PCI SIO access should also depend on SIO option

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

Message-ID: <57265D11.8000801@gmail.com>
Date:	Sun, 01 May 2016 20:46:25 +0100
From:	Sudip Mukherjee <sudipm.mukherjee@...il.com>
To:	"Maciej S. Szmigiero" <mail@...iej.szmigiero.name>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:	linux-kernel@...r.kernel.org, linux-parport@...ts.infradead.org
Subject: Re: [PATCH] parport: parport_pc: PCI SIO access should also depend
 on SIO option

On Sunday 01 May 2016 03:07 PM, Maciej S. Szmigiero wrote:
> Hi Greg,
> Hi Sudip,
>
> On 01.05.2016 09:45, Sudip Mukherjee wrote:
>> On Sat, Apr 30, 2016 at 01:56:40PM -0700, Greg Kroah-Hartman wrote:
>>> On Wed, Apr 20, 2016 at 01:09:51PM +0530, Sudip Mukherjee wrote:
>>>> From: "Maciej S. Szmigiero" <mail@...iej.szmigiero.name>
>>>>
>>>> CONFIG_PARPORT_PC_SUPERIO toggles Super IO chip support in parport_pc
>>>> code, however only code accessing SIO chip via ISA (or LPC) bus was
>>>> conditional on it.
>>>>
>>>> This patch makes SIO chip accesses via PCI bus also dependent on this
>>>> config option.
>>>>
>>>> It should be noted that Super IO support in parport_pc is needed only when
>>>> firmware has failed to make parallel port available either via PNP or
>>>> on standard I/O ranges and user has one of a few supported SIOs.
>>>>
>>>> Signed-off-by: Maciej S. Szmigiero <mail@...iej.szmigiero.name>
>>>> ---
>>>>
>>>> Hi Greg,
>>>> This patch is not tested on any superio chip based hardware. (I also
>>>> don't have one).
>>>> http://www.spinics.net/lists/kernel/msg2227051.html
>>>>
>>>> I know you dislike adding #ifdef so its upto you.
>>>
>>> It's really a messy patch, surely there is a better solution.
>>
>> yes, might be. But without hardware, should i dare?

<snip>

> Other possibility that comes to my mind would be to split out all such
> probing code to separate file and then either compile it or not
> depending on CONFIG_PARPORT_PC_SUPERIO.

I thought of this one, but the lack of hardware to test is the only 
reason I am hesitating.

regards
sudip