linux-kernel - Re: [PATCH] pci/pciehp: Allow polling/irq mode to be decided on a per-port basis

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: <CAErSpo4ymkPOx5Evi=nctWr5f7OY6vkQTzwGnvi1ck7t-OTAWg@mail.gmail.com>
Date:	Fri, 25 Apr 2014 10:43:54 -0600
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Guenter Roeck <groeck@...iper.net>
Cc:	Rajat Jain <rajatxjain@...il.com>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Rajat Jain <rajatjain@...iper.net>
Subject: Re: [PATCH] pci/pciehp: Allow polling/irq mode to be decided on a
 per-port basis

On Fri, Apr 25, 2014 at 10:34 AM, Guenter Roeck <groeck@...iper.net> wrote:
>
>
>> -----Original Message-----
>> From: Bjorn Helgaas [mailto:bhelgaas@...gle.com]
>> Sent: Thursday, April 24, 2014 2:31 PM
>> To: Rajat Jain
>> Cc: linux-pci@...r.kernel.org; linux-kernel@...r.kernel.org; Rajat
>> Jain; Guenter Roeck
>> Subject: Re: [PATCH] pci/pciehp: Allow polling/irq mode to be decided
>> on a per-port basis
>>
>> On Mon, Mar 31, 2014 at 04:51:53PM -0700, Rajat Jain wrote:
>> > Today, there is a global pciehp_poll_mode module parameter using
>> which
>> > either _all_ the hot-pluggable ports are to use polling, or _all_ the
>> > ports are to use interrupts.
>> >
>> > In a system where a certain port has IRQ issues, today the only
>> option
>> > is to use the parameter that converts ALL the ports to use polling
>> mode.
>> > This is not good, and hence this patch intruduces a bit field that
>> can
>> > be set using a PCI quirk that indicates that polling should always be
>> > used for this particular PCIe port. The remaining ports can still
>> > hoose to continue to operate in whatever mode they wish to.
>> >
>> > Signed-off-by: Rajat Jain <rajatxjain@...il.com>
>> > Signed-off-by: Rajat Jain <rajatjain@...iper.net>
>> > Signed-off-by: Guenter Roeck <groeck@...iper.net>
>>
>> I'm willing to merge this, but I'd prefer to merge it along with a
>> quirk that actually sets dev->hotplug_polling.  Otherwise it's dead
>> code and I'll have no way to tell whether we need to keep it.
>>
> Bjorn,
>
> what would be the proper location for such a quirk ?
> We use it to help simulating hotplug support on an IDT PES12NT3.
> The code is a bit more invasive than just the quirk itself,
> since it also needs to touch link and slot status registers,
> so quirks.c doesn't seem appropriate.
>
> drivers/pci/pes12nt3.c, maybe, with a separate configuration
> option ? Or in the hotplug directory ?

If this is only for debug, i.e., you don't intend to ship a product
using this simulated hotplug, maybe you should just keep both the
quirk and this patch out of tree.

If you do want to eventually ship this code for some product, I think
it'd be fine to put the quirk in drivers/pci/quirks.c, maybe with a
config option to enable it.  But without seeing the quirk, I can't
really tell.  A new file seems overkill unless it's something really
huge -- I don't think we really have examples of dedicated files for
other chip idiosyncrasies.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/