public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Alex Williamson <alex.williamson@hp.com>,
	akpm@osdl.org, linux-kernel <linux-kernel@vger.kernel.org>,
	sensors@Stimpy.netroedge.com
Subject: Re: [BK PATCH] I2C update for 2.6.8-rc1
Date: Tue, 24 Aug 2004 23:14:45 -0700	[thread overview]
Message-ID: <20040825061445.GA16938@kroah.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0408241847460.17766@ppc970.osdl.org>

On Tue, Aug 24, 2004 at 07:02:47PM -0700, Linus Torvalds wrote:
> On Tue, 24 Aug 2004, Alex Williamson wrote:
> > > How about this _trivial_ change? Does that fix things for you guys? Can 
> > > you send the /proc/ioport output if this works out for you, just so that 
> > > we can see?
> > 
> >    Yes, this works.  Please commit.
> 
> Greg? Opinions? I'll happily commit it, since it's almost certainly bound
> to be better than what we have now, but I have to admit that I could also 
> see it causing confusion if two devices are set up by the BIOS to be on 
> top of each other (since insert_resource() would indeed allow that).
> 
> Now, admittedly, that would be a VERY broken BIOS, and likely such a 
> situation wouldn't have worked _anyway_, but you're the PCI maintainer, so 
> you get to sit in the hot seat and say aye or nay.

It looks correct to me, please apply it.  If it breaks people's boxes
that used to work, I'm sure I'll hear about it :)

> > 1200-121f : motherboard
> >   1200-121f : 0000:00:1f.3
> 
> This is apparently the one that used to cause trouble, and you can see it 
> from the nesting level: the device nests inside the description, rather 
> than the other way around.
> 
> This does bring up an alternate fix: namely to do the PCI quirks 
> _earlier_.
> 
> If we had done the PCI quirk handling and probing for this device _before_
> ACPI populated the IO stuff, and we'd never have seen this problem. Why 
> did we let ACPI come in first in the first place? Greg? Len?

I don't really know, I think that happened before both Len and I took
over this code base.  I don't have a problem with doing it in this
order, but I'm sure there's some ACPI issue that I'm not aware of that
needs to be run first.

> The right order (I think) should be:
>  - walk the existing PCI setup, do the header quirks, populate the device 
>    and resource trees..
>  - _than_ do the ACPI resources

For a box such as this one, it would make sense to do it in this order,
I agree.

thanks,

greg k-h

  reply	other threads:[~2004-08-25  6:15 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-15  0:05 [BK PATCH] I2C update for 2.6.8-rc1 Greg KH
2004-07-15  0:07 ` [PATCH] " Greg KH
2004-07-15  0:07   ` Greg KH
2004-07-15  0:07     ` Greg KH
2004-07-15  0:07       ` Greg KH
2004-07-15  0:07         ` Greg KH
2004-07-15  0:07           ` Greg KH
2004-07-15  0:07             ` Greg KH
2004-07-15  0:07               ` Greg KH
2004-07-15  0:07                 ` Greg KH
2004-07-15  0:07                   ` Greg KH
2004-07-15  0:07                     ` Greg KH
2004-07-15  0:07                       ` Greg KH
2004-07-15  0:07                         ` Greg KH
2004-07-15  0:07                           ` Greg KH
2004-07-15  0:07                             ` Greg KH
2004-07-16 17:07                         ` Pavel Machek
2004-07-16 17:17                           ` Greg KH
2004-07-16 17:39                             ` Bob Riegelmann
2004-07-16 18:19                             ` Adam Kropelin
2004-07-17 14:30 ` Greg (or anyone else) one small i2c question Reinder
2004-07-30  5:40   ` --- " Reinder
2004-07-30  6:30     ` Denis Vlasenko
2004-08-25  6:44   ` Greg " Greg KH
2004-08-24 21:58 ` [BK PATCH] I2C update for 2.6.8-rc1 Alex Williamson
2004-08-24 22:04   ` Greg KH
2004-08-25  0:37     ` Linus Torvalds
2004-08-25  1:38       ` Alex Williamson
2004-08-25  1:42         ` Alex Williamson
2004-08-25  2:02         ` Linus Torvalds
2004-08-25  6:14           ` Greg KH [this message]
2004-08-25  6:36             ` Greg KH

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=20040825061445.GA16938@kroah.com \
    --to=greg@kroah.com \
    --cc=akpm@osdl.org \
    --cc=alex.williamson@hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sensors@Stimpy.netroedge.com \
    --cc=torvalds@osdl.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox