linux-kernel - Re: Platform device id

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:	Mon, 10 Sep 2007 19:52:05 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Jean Delvare <khali@...ux-fr.org>
Cc:	David Brownell <david-b@...bell.net>, linux-kernel@...r.kernel.org,
	gregkh@...e.de, dmitry.torokhov@...il.com
Subject: Re: Platform device id

On Sat, 08 Sep 2007, Jean Delvare wrote:
> This more general than just the platform bus. It's how the Linux 2.6
> device driver model is designed.

No issues about that.  It is just that the platform bus sucks a bit if you
need to "abuse it" (no wonder!) to hang various different devices that are
provided *or* driven by the same module.

> There are alternatives to the way hdaps and thinkpad_acpi instantiate
> their devices:
> 

> * These drivers use DMI to find out whether they run on supported
> hardware. The same detection code could be moved to a separate driver

Actually, DMI is a hint for autoloading, only.  They do probe the
hardware/firmware for the needed functionality to know for sure.

> (possibly the same one for all DMI-detected devices) and that separate
> driver would instantiate the devices as needed. Then the usual
> hotplug/coldplug rules apply.

That could work, yes.

> * Detection could be moved to user-space entirely, then we would only
> need a way to instantiate these specific devices from user-space. This
> exists in other areas (scsi, network) for quite some times already so
> it shouldn't be too difficult.

Don't like that one, sorry.  Detection often needs the kind of access to
hardware that is better off contained in the kernel.

> > 2. The fact that a module that has a number of different devices has to
> >    register itself a number of times as a driver, if it wants to name the
> >    devices something different...
> 
> Sounds like you have a design issue here to start with. Supporting
> several significantly different devices in the same module is not
> something that we do usually.

I will see what I can do about breaking it up in various modules.  But this
can be unoptimal. If I took it too seriously, thinkpad-acpi would break into
at least five different modules, if not more, and at least one or two
modules would need to be there for the common code.  There has to be a
middle ground somewhere, I think.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
-
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/