From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
Giel van Schijndel <me@mortis.eu>,
Hans de Goede <hdegoede@redhat.com>,
Jean Delvare <khali@linux-fr.org>,
Jonathan Cameron <jic23@cam.ac.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Bjorn Helgaas <bjorn.helgaas@hp.com>,
Dominik Brodowski <linux@dominikbrodowski.net>,
Laurens Leemans <laurens@signips.com>,
lm-sensors@lm-sensors.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] resource: shared I/O region support
Date: Mon, 29 Mar 2010 19:29:57 +0100 [thread overview]
Message-ID: <20100329192957.0aa66eaa@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <20100329110633.702e3874@jbarnes-piketon>
> Well that does keep it simple, and with just one user that's probably
> best.
>
> But why not use the common bus driver method? Muxing at the resource
> level only seems to solve part of the problem... It doesn't guarantee
> for example that driver A does something to a shared region that breaks
> driver B; it just makes sure they don't access the same region at the
> same time.
The obvious reason for not doing that kind of grand over-engineering is
that you are assuming the devices involved are remotely related. On quite
a few systems we have a collection of superio config interfaces on random
low ports all with their own lock/unlock rituals. They range from
parallel devices to watchdogs and god knows what else. Right now we have
various bits of driver code (parport is a good one) that exist on a cross
fingers, pray and poke model. It would be nice to fix that.
For most super I/O devices the muxing is basically a glorified chip select
line. There isn't any structure to impose over it. Where you have
structure there are better ways to do it, but one does not exclude the
other.
Alan
next prev parent reply other threads:[~2010-03-29 18:28 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-23 14:12 [PATCH] hwmon: f71882fg: properly acquire I/O regions while probing Giel van Schijndel
2010-03-23 14:17 ` Giel van Schijndel
2010-03-23 23:12 ` [PATCH 1/4] [RFC] hwmon: f71882fg: Add support for the Fintek F71808E Giel van Schijndel
2010-03-23 23:12 ` [PATCH 2/4] hwmon: f71882fg: prepare for addition of watchdog support Giel van Schijndel
2010-03-23 23:12 ` [PATCH 3/4] hwmon: f71882fg: add watchdog detection code Giel van Schijndel
2010-03-23 23:12 ` [PATCH 4/4] [RFC] hwmon: f71882fg: Add watchdog API for F71808E and F71889 Giel van Schijndel
2010-03-23 23:26 ` Giel van Schijndel
2010-03-24 8:37 ` Hans de Goede
2010-03-24 9:36 ` Giel van Schijndel
2010-03-24 10:33 ` Hans de Goede
2010-03-24 15:35 ` Giel van Schijndel
2010-03-24 15:51 ` Alan Cox
2010-03-24 16:20 ` Hans de Goede
2010-03-24 20:35 ` Giel van Schijndel
2010-04-25 21:20 ` [lm-sensors] " Jim Cromie
2010-03-25 8:54 ` Giel van Schijndel
2010-03-25 10:40 ` Giel van Schijndel
2010-03-25 12:50 ` Alan Cox
2010-03-25 13:06 ` Hans de Goede
2010-03-25 13:17 ` [PATCH 1/3] resource: shared I/O region support Giel van Schijndel
2010-03-25 13:17 ` [PATCH 2/3] hwmon: f71882fg: use a muxed resource lock for the Super I/O port Giel van Schijndel
2010-03-25 13:17 ` [PATCH 3/3] [RFC] watchdog: f71808e_wdt: new watchdog driver for Fintek F71808E Giel van Schijndel
2010-03-30 9:06 ` Giel van Schijndel
2010-05-20 7:52 ` Wim Van Sebroeck
2010-05-25 21:08 ` Giel van Schijndel
2010-05-26 7:38 ` Wim Van Sebroeck
2010-07-31 21:36 ` Giel van Schijndel
2010-03-25 21:10 ` [PATCH 2/3] hwmon: f71882fg: use a muxed resource lock for the Super I/O port Hans de Goede
2010-04-25 10:35 ` Giel van Schijndel
2010-07-31 21:21 ` Giel van Schijndel
2010-03-25 15:57 ` [PATCH 1/3] resource: shared I/O region support Alan Cox
2010-03-25 18:03 ` Giel van Schijndel
2010-03-25 18:16 ` Alan Cox
2010-03-29 8:18 ` Giel van Schijndel
2010-03-29 16:07 ` Jesse Barnes
2010-03-29 17:38 ` Giel van Schijndel
2010-03-29 17:44 ` Giel van Schijndel
2010-03-29 17:45 ` H. Peter Anvin
2010-03-29 18:06 ` Jesse Barnes
2010-03-29 18:17 ` H. Peter Anvin
2010-03-29 18:29 ` Alan Cox [this message]
2010-04-02 20:29 ` Jesse Barnes
2010-03-29 18:39 ` Alan Cox
2010-03-29 18:56 ` H. Peter Anvin
2010-03-29 17:59 ` Jesse Barnes
2010-03-29 17:59 ` Jesse Barnes
2010-03-24 8:26 ` [PATCH 2/4] hwmon: f71882fg: prepare for addition of watchdog support Hans de Goede
2010-03-24 8:36 ` Hans de Goede
2010-03-24 8:25 ` [PATCH 1/4] [RFC] hwmon: f71882fg: Add support for the Fintek F71808E Hans de Goede
2010-03-24 9:23 ` [PATCH 1/4] " Giel van Schijndel
2010-03-24 10:31 ` Hans de Goede
2010-07-31 23:31 ` Giel van Schijndel
2010-08-01 6:12 ` Hans de Goede
2010-08-01 13:22 ` Giel van Schijndel
2010-08-01 13:30 ` [PATCH] " Giel van Schijndel
2010-08-04 11:36 ` Hans de Goede
2010-08-04 15:44 ` Giel van Schijndel
2010-08-13 10:56 ` Hans de Goede
2010-08-10 19:11 ` Giel van Schijndel
2010-08-13 10:01 ` Hans de Goede
2010-08-18 18:24 ` Andrew Morton
2010-08-22 18:04 ` Hans de Goede
2010-08-22 18:28 ` Giel van Schijndel
2010-08-01 13:30 ` [PATCH 1/2] hwmon: f71882fg: use a muxed resource lock for the Super I/O port Giel van Schijndel
2010-08-01 13:30 ` [PATCH 2/2] watchdog: f71808e_wdt: new watchdog driver for Fintek F71808E and F71882FG Giel van Schijndel
2010-08-04 11:38 ` [PATCH 1/2] hwmon: f71882fg: use a muxed resource lock for the Super I/O port Hans de Goede
2010-10-02 22:59 ` Giel van Schijndel
2010-10-03 1:06 ` Guenter Roeck
2010-10-03 9:01 ` Jean Delvare
2010-10-03 12:09 ` [PATCH] " Giel van Schijndel
2010-10-03 13:31 ` Guenter Roeck
2010-03-23 23:01 ` [PATCH] hwmon: f71882fg: properly acquire I/O regions while probing Giel van Schijndel
2010-03-24 8:14 ` Hans de Goede
2010-03-24 8:46 ` Giel van Schijndel
2010-03-24 9:09 ` [PATCH] hwmon: f71882fg: code cleanup Giel van Schijndel
2010-03-24 12:54 ` Jean Delvare
2010-03-24 9:09 ` [PATCH] hwmon: f71882fg: acquire I/O regions while we're working with them Giel van Schijndel
2010-03-24 9:28 ` [PATCH] hwmon: f71882fg: properly acquire I/O regions while probing Jean Delvare
2010-03-24 9:29 ` Jean Delvare
2010-03-24 9:34 ` Giel van Schijndel
2010-03-24 12:54 ` 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=20100329192957.0aa66eaa@lxorguk.ukuu.org.uk \
--to=alan@lxorguk.ukuu.org.uk \
--cc=akpm@linux-foundation.org \
--cc=bjorn.helgaas@hp.com \
--cc=hdegoede@redhat.com \
--cc=hpa@zytor.com \
--cc=jbarnes@virtuousgeek.org \
--cc=jic23@cam.ac.uk \
--cc=khali@linux-fr.org \
--cc=laurens@signips.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@dominikbrodowski.net \
--cc=lm-sensors@lm-sensors.org \
--cc=me@mortis.eu \
/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
all inboxes | Powered by JetHome®