linux-kernel - Re: [PATCH 4/4] [RFC] hwmon: f71882fg: Add watchdog API for F71808E and F71889

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]

Date:	Wed, 24 Mar 2010 21:35:56 +0100
From:	Giel van Schijndel <me@...tis.eu>
To:	Hans de Goede <hdegoede@...hat.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Jean Delvare <khali@...ux-fr.org>,
	Jonathan Cameron <jic23@....ac.uk>,
	Laurens Leemans <laurens@...nips.com>,
	lm-sensors@...sensors.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/4] [RFC] hwmon: f71882fg: Add watchdog API for
 F71808E and F71889

On Wed, Mar 24, 2010 at 05:20:59PM +0100, Hans de Goede wrote:
> On 03/24/2010 04:51 PM, Alan Cox wrote:
>>> hold on the SIO port range. This would thus interfere with the
>>> operation of the f71882fg driver. I.e. it would prevent the device
>>> probing stage from working, thus preventing it from loading *after*
>>> my in-development watchdog driver.
>> 
>> There are two ways to deal with that really
>> 
>> 1. Add a multi-function driver - it finds the chip and claims the
>> port regions and then provides methods for locked access to them as
>> well as creating other device instances that the drivers map to
>> (probably platform devices ?) which in turn trigger the
>> loading/binding of the relevant low level devices.
>> 
>> 2. Fix the kernel request_resource stuff to support a sleeping non
>> exclusive resource so request/free of regions can be used as a
>> resource semaphore by co-operative devices.
>> 
>> #2 is actually not hard but when I did the patch originally it then
>> wasn't needed by the driver I had in mind for other reasons.
>> 
>> See http://groups.google.com/group/linux.kernel/msg/1425fc2aad32e6ea
>> 
>> Maybe its worth resurrecting ?
> 
> Or, a bit more specific solution would be to resurrect the superio
> lock coordinator patches, which were written (but never merged) 2
> years ago to solve exactly this problem:
> http://lists.lm-sensors.org/pipermail/lm-sensors/2008-July/023743.html

When performing some searches I find messages going back to at least
september 2006 [1] [2]. With multiple occurences of these patches being
"dusted off". They never got applied though, and for that (*not*
applying them) I cannot find any reason. Is there any? Or did people
just become uninterested and let the patches "collect dust"?

Then regarding Alan's patch. The fact that it is a *lot* simpler than
Jim Cromie's SuperIO locks coordinator is IMHO a significant advantage
over the latter. Furthermore, "lock coordinator" seems like a bad name
to me, since those patches seem especially concerned with centralising
the way that SuperIO devices are probed for. Thus if the only thing
required is to serialize resource access I think plain-ol' locking
(with the ability to block on the lock, rather than polling for it).

[1] http://lists.lm-sensors.org/pipermail/lm-sensors/2006-June/016476.html
[2] http://lkml.org/lkml/2006/9/14/20

-- 
Met vriendelijke groet,
With kind regards,
Giel van Schijndel

Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)