linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "David Hubbard" <david.c.hubbard@gmail.com>
To: "Hans de Goede" <j.w.r.degoede@hhs.nl>
Cc: "Milton Miller" <miltonm@bga.com>,
	linuxppc-dev@ozlabs.org, "Samuel Ortiz" <samuel@sortiz.org>,
	linux-kernel@vger.kernel.org, lm-sensors@lm-sensors.org
Subject: Re: [lm-sensors] [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
Date: Mon, 14 Jul 2008 11:55:01 -0600	[thread overview]
Message-ID: <4dfa50520807141055l532caaaai700255936600e5ae@mail.gmail.com> (raw)
In-Reply-To: <487B8D2C.1090208@hhs.nl>

Hi Hans,

On Mon, Jul 14, 2008 at 11:30 AM, Hans de Goede <j.w.r.degoede@hhs.nl> wrote:
> Milton Miller wrote:
>> I haven't done the research, but it might be keep superio as
>> a platform driver, and keep the clients as platform drivers.  Only
>> have the superio driver probe and discover the subcomponent
>> addresses and then create the platform devices as children
>> instead of having each driver create its own platform device.
>> (This all assumes they are all platform devices in sysfs, I have
>> not looked).
>>
>> This is all because in the platform bus the bus driver does not
>> discover the addresses but relies on drivers or platform setup code.
>>
>
> This sounds like a good plan, rather then add a new bus type add a superio
> platform driver which does superio probing and registering of platform devices
> for discovered logical devices.
>
> This superio platform driver then needs to also export some functions of those
> few logical devices which need access to the superio registers for more then
> just finding out their own base address.
>
> I guess that it then would be best to load this superio driver by default on
> most systems.
>
> How does this all mix and match with isapnp, it feels to me we're doing
> somewhat the same as isapnp here.

Is there any way to use lspci and start at the LPC bridge, then find
the SuperIO chip's IO address? What about ACPI tables? Perhaps probing
logic could look for an LPC bridge before probing certain IO addresses
even if the addresses are not in the LPC bridge config.

A superio platform driver is a good way to go -- it fits with the way
the platform bus does things. Also, Jim's patches are almost there
already.

Thanks,
David

  reply	other threads:[~2008-07-14 17:55 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-10 21:12 [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region Milton Miller
2008-07-10 21:14 ` mtd: remove __PPC__ hardcoded address from nand/diskonchip and devices/docprobe Milton Miller
2008-07-10 21:33 ` [lm-sensors] [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region Hans de Goede
2008-07-10 21:51   ` Milton Miller
2008-07-11  6:52     ` Jean Delvare
2008-07-11  7:27       ` Hans de Goede
2008-07-11  7:36         ` Jean Delvare
2008-07-13  6:31           ` Hans de Goede
2008-07-13 21:11             ` [lm-sensors] " David Hubbard
2008-07-13 21:22               ` Hans de Goede
2008-07-13 21:26                 ` David Hubbard
2008-07-14  7:59                   ` Jean Delvare
2008-07-14 17:09                     ` Milton Miller
2008-07-14 17:30                       ` [lm-sensors] " Hans de Goede
2008-07-14 17:55                         ` David Hubbard [this message]
2008-07-15  8:36                           ` Jean Delvare
2008-07-15 15:31                             ` David Hubbard
2008-07-16  7:46                               ` Jean Delvare
2008-07-16  8:09                                 ` Rene Herman
2008-07-15  8:28                       ` Jean Delvare
     [not found] ` <for-27-patch9@bga.com>
2008-07-12 20:02   ` [PATCH/RESEND] pci: dynids.use_driver_data considered harmful Milton Miller
2008-07-12 20:17     ` Greg KH
2008-07-12 20:58       ` Jean Delvare
2008-07-12 21:17       ` Milton Miller
2008-07-12 21:29         ` Milton Miller
     [not found]   ` <20080712041137.GA5933@kroah.com>
2008-07-12 21:08     ` [PATCH/RFC] " Milton Miller
2008-07-12 22:48       ` Milton Miller
2008-07-16 10:18         ` Milton Miller
2008-07-17  7:07           ` Greg KH
2008-07-17 14:36             ` Milton Miller
2008-08-06  7:31             ` Jean Delvare
2008-08-14 22:12               ` Greg KH
2008-08-15 14:50                 ` Milton Miller
2008-08-15 15:50                 ` Jean Delvare
2008-08-15 17:46                   ` Jesse Barnes
2008-08-15 18:55                     ` Jean Delvare
2008-08-15 19:15                       ` Jesse Barnes
2008-08-16  6:22                         ` Greg KH
2008-08-17 19:06                           ` Jean Delvare
2008-08-18  3:50                             ` Greg KH
2008-08-18 17:13                             ` Jesse Barnes
2008-08-18 20:41                             ` Jesse Barnes
2008-08-19 18:01                             ` Milton Miller
2008-08-06  7:22           ` Jean Delvare

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=4dfa50520807141055l532caaaai700255936600e5ae@mail.gmail.com \
    --to=david.c.hubbard@gmail.com \
    --cc=j.w.r.degoede@hhs.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=lm-sensors@lm-sensors.org \
    --cc=miltonm@bga.com \
    --cc=samuel@sortiz.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;
as well as URLs for NNTP newsgroup(s).