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

[Greg KH]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/