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:	Fri, 07 Sep 2007 14:41:15 -0700
From:	David Brownell <david-b@...bell.net>
To:	hmh@....eng.br
Cc:	linux-kernel@...r.kernel.org, khali@...ux-fr.org, gregkh@...e.de,
	dmitry.torokhov@...il.com
Subject: Re: Platform device id

> > For that matter, a *driver* should never create its own device node(s)
> > in the first place.  Device creation belongs elsewhere, like as part of
> > platform setup or, for busses with integral enumeration support like
> > PCI or USB, bus glue.  Linux is moving away from that legacy model.
>
> This assumes that we have a better bus than "platform" to dump drivers like
> thinkpad-acpi, hdaps, and a host of other host-specific stuff.

I don't follow.  If it's host-specific, then it's easy enough to
have a host-specific routine creating those platform devices.
A different host wouldn't call that routine.

Embedded Linux platforms do that *ALL* the time.  ARM keys on a
board ID provided early in boot (e.g. by U-Boot).  PowerPC uses
a device tree, which ISTR evolved from the OpenBoot as first used
on SPARC.  Worst comes to worst, the kernel command line can say
which board is involved, and thus which setup code to run.

(Also, note that "platform", "host", and "board" are ambiguous.
In some contexts each is synonymous; in others, not.  I avoid
using "host" except in the protocol sense.  Usually "board" is
pretty specific -- this cpu, those peripherals -- although it
gets messy when the system is really a board stack, or when the
CPU may be socketed or be in a customizable FPGA etc.)

> > I realize that may be more easily said than done in some cases,
> > like i8042 on non-PNP systems.
>
> Yes, and there is a LOT of non-PNP stuff involved, since platform became the
> dumping ground for host-specific devices (as opposed to platform-specific
> devices).

See above ... most embedded systems aren't x86, so lack of PNP is
less of an issue than plain old legacy system designs -- designed
in ways that complicate or prevent probe/discovery schemes, which
gets to be a mess (like the one preceding PNP with DOS/x86/ISA).

Less clear cases include orphaned drivers, especially ones for
hardware that's on its way out or already obsolete.  Most folk
don't want to touch those, for fear of getting stuck to them.  :)

- Dave

-
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/