linux-kernel - Re: [PATCH 1/3] resource: shared I/O region support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100329192957.0aa66eaa@lxorguk.ukuu.org.uk>
Date:	Mon, 29 Mar 2010 19:29:57 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Giel van Schijndel <me@...tis.eu>,
	Hans de Goede <hdegoede@...hat.com>,
	Jean Delvare <khali@...ux-fr.org>,
	Jonathan Cameron <jic23@....ac.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Bjorn Helgaas <bjorn.helgaas@...com>,
	Dominik Brodowski <linux@...inikbrodowski.net>,
	Laurens Leemans <laurens@...nips.com>,
	lm-sensors@...sensors.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] resource: shared I/O region support

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