Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in

Greg KH
2008-01-28T22:56:01Z

On Mon, Jan 28, 2008 at 03:31:42PM -0700, Matthew Wilcox wrote:
> On Mon, Jan 28, 2008 at 12:44:31PM -0800, Greg KH wrote:
> > On Mon, Jan 28, 2008 at 01:32:06PM -0500, Tony Camuso wrote:
> > > Greg,
> > >
> > > Have you given Grant's suggestion any further consideration?
> > >
> > > I'd like to know how the MMCONFIG issues discussed in this thread are going
> > > to be handled upstream. I have a patch implemented in RHEL 5.2, but I would
> > > rather have the upstream patch implemented, whatever it is.
> >
> > Well, everyone still doesn't seem to agree on the proper way forward
> > here, so for me to just "pick one" isn't very appropriate.
> >
> > So, can we try again?
> >
> > Can people submit, what they think the change should be? Right now I
> > have Arjan's patch in my kernel tree, but will not send it to Linus for
> > .25 for now, unless everyone thinks that is the best solution at the
> > moment (which, for me, I'm leaning toward right now...)
>
> My opinion is that Ivan's patch followed by my patch is the best way
> forward. I see Arjan's patch as a good prototype, but it introduces a lot
> of unnecessary infrastructure (and a userspace interface that I dislike).
>
> I would like to see Ivan's patch merged ASAP as it does fix one of
> my machines. akpm has the patch from me to disable io decoding, and
> intends to send it to Linus during this merge window ... that patch
> becomes unnecessary if we merge Ivan's patch.
>
> My patch is an incremental improvement that adds some of the features
> of Arjan's patch without the extra infrastructure. I don't think it's
> urgent, but it does make some of our internal interfaces cleaner.

Please send me patches, in a form that can be merged, along with a
proper changelog entry, in the order in which you wish them to be
applied, so I know exactly what changes you are referring to.

thanks,

greg k-h