All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
To: "Maciej S. Szmigiero" <mail@maciej.szmigiero.name>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org, linux-parport@lists.infradead.org
Subject: Re: [PATCH] parport: parport_pc: PCI SIO access should also depend on SIO option
Date: Sun, 01 May 2016 20:46:25 +0100	[thread overview]
Message-ID: <57265D11.8000801@gmail.com> (raw)
In-Reply-To: <57260D88.8030003@maciej.szmigiero.name>

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@maciej.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@maciej.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

  reply	other threads:[~2016-05-01 19:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-20  7:39 [PATCH] parport: parport_pc: PCI SIO access should also depend on SIO option Sudip Mukherjee
2016-04-30 20:56 ` Greg Kroah-Hartman
2016-05-01  7:45   ` Sudip Mukherjee
2016-05-01 14:07     ` Maciej S. Szmigiero
2016-05-01 19:46       ` Sudip Mukherjee [this message]
  -- strict thread matches above, loose matches on Subject: below --
2016-03-05 17:46 Maciej S. Szmigiero

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57265D11.8000801@gmail.com \
    --to=sudipm.mukherjee@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-parport@lists.infradead.org \
    --cc=mail@maciej.szmigiero.name \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.