All of lore.kernel.org
 help / color / mirror / Atom feed
From: Don Dutile <ddutile@redhat.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Matthew Wilcox <matthew@wil.cx>,
	"Hao, Xudong" <xudong.hao@intel.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: [PATCH V4] Quirk for IVB graphics FLR errata
Date: Fri, 13 Apr 2012 09:48:04 -0400	[thread overview]
Message-ID: <4F882E94.1070504@redhat.com> (raw)
In-Reply-To: <CAErSpo4pAGnQm=5=1kEeLmUBZi2wLWXCpw7s-+JFJbz4LVp3fQ@mail.gmail.com>

On 04/12/2012 09:48 PM, Bjorn Helgaas wrote:
> On Thu, Apr 12, 2012 at 9:19 AM, Don Dutile<ddutile@redhat.com>  wrote:
>> On 04/12/2012 12:06 AM, Matthew Wilcox wrote:
>
>>>> -->    other arch compile problem source???
>>>
>>>
>>> Well, this device is part of the x86 CPU.  It's never going to be found
>>> as part of any other architecture.  Why force other architectures to
>>> carry this quirk around?
>>
>> Well, the trend to include more IO into chipsets tied to an arch
>> will probably increase over time, so such conditional quirks will
>> increase as well.
>> Sounds like the quirk tables need an arch-hook (linked list) to check
>> &  traverse.  Then such code can go into arch/<arch>/pci/quirks.c .
>
> We do have arch/x86/pci/fixup.c already.  I agree it'd be nice if it
> had the same name as the generic quirks.c.  Other than that, do you
> think there's an advantage to adding some sort of explicit arch hook,
> or is it sufficient that DECLARE_PCI_FIXUP...() uses the linker to
> collect all the quirks (both generic and arch-specific)?
>
> Bjorn
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

I didn't understand that DECLARE_PCI_FIXUP...() uses the linker to
collect all the quirks.  if so, that WFM.
I do think the arch/<>/pci/fixup.c module should be renamed to quirks.c
so it's association with drivers/pci/quirks.c is (more) obvious.
fixup.c gives the impression it may be more like bios-related fixup,
and not quirk-related fixups.


  reply	other threads:[~2012-04-13 13:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-11  6:03 [PATCH V4] Quirk for IVB graphics FLR errata Hao, Xudong
2012-04-11 12:22 ` Matthew Wilcox
2012-04-12  2:26   ` Hao, Xudong
2012-04-11 14:28 ` Don Dutile
2012-04-12  2:12   ` Hao, Xudong
2012-04-12  4:06   ` Matthew Wilcox
2012-04-12 15:19     ` Don Dutile
2012-04-13  1:40       ` Hao, Xudong
2012-04-13  1:48       ` Bjorn Helgaas
2012-04-13 13:48         ` Don Dutile [this message]
2012-04-13  1:56       ` Hao, Xudong
  -- strict thread matches above, loose matches on Subject: below --
2012-03-01  9:37 Hao, Xudong

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=4F882E94.1070504@redhat.com \
    --to=ddutile@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=matthew@wil.cx \
    --cc=xudong.hao@intel.com \
    /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.