From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from services.gcu-squad.org (zone0.gcu-squad.org [212.85.147.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 2A1E9DDF45 for ; Fri, 11 Jul 2008 17:37:03 +1000 (EST) Date: Fri, 11 Jul 2008 09:36:50 +0200 From: Jean Delvare To: Hans de Goede Subject: Re: [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region Message-ID: <20080711093650.4b98e3b7@hyperion.delvare> In-Reply-To: <48770B5E.7000308@hhs.nl> References: <48768018.2070704@hhs.nl> <20080711085246.1ead773b@hyperion.delvare> <48770B5E.7000308@hhs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Cc: linuxppc-dev@ozlabs.org, Samuel Ortiz , linux-kernel@vger.kernel.org, Milton Miller , lm-sensors@lm-sensors.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, 11 Jul 2008 09:27:26 +0200, Hans de Goede wrote: > Jean Delvare wrote: > > Hi Hans, hi Milton, > > > > > > >> One could make a superio driver, and create sub-devices for the IR, > >> I2C, floppy, parallel, etc > >> nodes. > > > > There have been proposals to do this, and this would indeed be a very > > good idea, but unfortunately nobody took the time to implement this > > properly, push it upstream and volunteer to maintain it. The problem is > > that you don't need just a "driver", but a new subsystem, that needs to > > be designed and maintained. > > Well, I believe there have been some lightweight superio locking coordinator > patches been floating around on the lm_sensors list, and I have reviewed them > and then a new version was done with my issues fixed. > > I kinda liked the proposed solution there, it was quite simple, moved all the > generic superio stuff into generic superio code, and added locking for super io > access from multiple drivers, what ever happened to those patches? As far as I know, nothing, and this is the problem. Somebody needs to step up and call him/herself the maintainer of the new code, and push it upstream and convert all the drivers (hwmon, watchdog, parallel port...) to make use of it. And I am not the one to do this, I am busy enough as is with i2c and hwmon. > If were to start using those, we could actually do a request region and then > never release it, as things should be. Yes, if we have a superio access coordinator, it can request the region and not release it. But as long as we don't have that, I agree with Milton that the individual drivers should temporarily request the Super-I/O region before accessing it. -- Jean Delvare