linux-kernel - Re: I/O collisions w/ hwmon/it87.c and watchdog/it8712f

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:	Sun, 10 Feb 2008 18:32:49 -0500
From:	"Andrew Paprocki" <andrew@...iboo.com>
To:	"Alan Cox" <alan@...rguk.ukuu.org.uk>
Cc:	linux-kernel@...r.kernel.org, "Jorge Boncompte" <jorge@...2.net>,
	"Jean Delvare" <khali@...ux-fr.org>
Subject: Re: I/O collisions w/ hwmon/it87.c and watchdog/it8712f_wdt.c? (Super I/O chips in general..)

Does it make sense to use the drivers/mfd directory for Super I/O
chips then? Is there any problem with having other hwmon, watchdog,
etc depend on drivers/mfd? Should this kind of setup for platform
devices be documented in the driver-model?

-Andrew

On Feb 10, 2008 6:05 PM, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
> > Since these chips touch many different parts of traditionally separate
> > driver areas, how should the drivers be structured so that they can
> > all talk to the chip? Should the low level communications routines for
> > the chip live in a library which all the drivers could use?
>
> Probably yes. And that if possible should manage all the locking. Thats
> roughly how the majority of drivers do it. Some export the lock from base
> code and inline the accessors depending how complex it is.
--
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/