linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Milton Miller <miltonm@bga.com>
To: Hans de Goede <j.w.r.degoede@hhs.nl>
Cc: Samuel Ortiz <samuel@sortiz.org>,
	linuxppc-dev@ozlabs.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: Thu, 10 Jul 2008 16:51:33 -0500	[thread overview]
Message-ID: <acca8e14e769b2feadee19f1f7448438@bga.com> (raw)
In-Reply-To: <48768018.2070704@hhs.nl>


On Jul 10, 2008, at 4:33 PM, Hans de Goede wrote:

> Milton Miller wrote:
>> After the following patch to mark the isa region busy and applying a 
>> few
>> patches[1], I was able to kexec boot into an all-yes-config kernel 
>> from linux-next, with the following KCONFIG_ALLCONFIG file:
...
>> While the first two might not be required, and the third is just
>> selecting the right platform, it would be nice to get the drivers
>> to play as well as the rest of the kernel.
>> The drivers all are for super-io chips, either irda/FIR drivers or 
>> hwmon,
>> and poke at isa ports without checking request_region.
>
> Erm,
>
> The superio sensor drivers only poke the superio chip registers 
> without request region during the probe phase, iow they try to detect 
> the chip, using a widely document and standardized (part of isa pnp 
> AFAIK) procedure on standardized ports.
>
> Let me try to explain a bit about superio chips, they have 2 superio 
> control registers (an index and data register) with which things like 
> a manufacturer and device id can be read, besides these id registers 
> they also have a set of registers with config for different logical 
> devices. Once the id is matched, the driver knows which logical device 
> config to read, reads a (different) isa base address + range from the 
> logical device config, and then does a request_region on the region 
> actually used by the logical device.
>
> The superio control registers are thus a sort of pci configuration 
> space if you want, doing a request_region on these is not such a good 
> idea, as multiple drivers (for different logical devices within the 
> superio device) may use these, so trying to gain exclusive access will 
> lead to troubles.
>
> I hope with this info about the problem space, that you maybe have a 
> suggestion on howto fix this?
>

My point is that they are probing without even knowing that a such a IO 
range exists.

These are the only drivers left in the tree that still do this.  (At 
least that are not
blocked on a powerpc allyesconfig for 64-bit, !CONFIG_VIRT_TO_BUS).

One could make a superio driver, and create sub-devices for the IR, 
I2C, floppy, parallel, etc
nodes.

I would even accept a check_region (horrors!), it would impove the 
situation.

But most other drivers do this by request_region, probe, then release 
the region afterwards.

Besides, one could argue the superio region should be requested while 
probing, to prevent other cpus from poking at the super io chip at the 
same time.   Think of it as missing locking.

milton


  reply	other threads:[~2008-07-10 22:10 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 [this message]
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
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=acca8e14e769b2feadee19f1f7448438@bga.com \
    --to=miltonm@bga.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=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).