On Tue, May 19, 2015 at 12:12:17AM +0000, Taylor R Campbell wrote: > Date: Tue, 19 May 2015 06:57:44 +0800 (PHT) > From: Paul Goyette <paul%vps1.whooppee.com@localhost> > > On Mon, 18 May 2015, Masao Uebayashi wrote: > > > How about: > > > > - making pcppi(4) provide the new pcppibus(4), and > > - making attimer(4) and pckbd(4) attach at pcppibus(4) > > A couple of issues with this approach: > > * pckbd already attaches at an unrelated parent, pckbc > * attimer can attach currently at acpi, as well as at isa > > The real problem here is that these other drivers, whether they're > children of pcppi or of something else, are optional. And their very > presence, whether or not any instance is actually configured, (and > without regard to where they are attached) changes the behavior of > pcppi. > > Can you explain how the devices are actually related, both in the > hardware and in the kernel representations of it, irrespective of how > it is currently manifested in autoconf? IIRC, for attimer(4) and pcppi(4), they share register space. They appear as distinct devices in ACPI trees though so it makes things interesting. > Sometimes there is a non-tree relation between two devices in a piece > of physical hardware which both hang off a generic bus that ought not > to have device-specific hacks to make the two talk. E.g., the HD > audio and graphics devices on current Intel PCI buses exhibit this. It's even worse in the eval board world where some devices depend on muxes or clocks being set up correctly, and those appear in very different area of the device tree. > But I'm not sure a generic autoconf mechanism is warranted for such > glue. Better to identify working solutions for specific cases and > then generalize, rather than start with a super-generic mechanism > before it has been demonstrated to work well in any specific case. I think a generic autoconf mechanism would be welcome to be able to discover devices and walk down a firmware-provided device tree at the same time. That would save a lot of the register_device(9) (or whatever that API is called) magic where every time the arch-specific code has to enumerate the device tree to find the matching device and get information. It's a rather difficult problem though. -- Quentin Garnier - cube%cubidou.net@localhost "See the look on my face from staying too long in one place [...] every time the morning breaks I know I'm closer to falling" KT Tunstall, Saving My Face, Drastic Fantastic, 2007.
Attachment:
pgptHfnt7ZGJ7.pgp
Description: PGP signature