Re: Inter-driver #if dependencies

[Paul Goyette <paul%vps1.whooppee.com@localhost>]

On Tue, 19 May 2015, Quentin Garnier wrote:

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

Yes, this is correct.  Additionally, even though we allow for the 
attimer device to attach via acpi, the bell code in pcppi.c still 
manipulates the timer's isabus registers directly.  :(  Wholesale 
violation of the device-tree paradigm.

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

register_device(9) == config_found_ia() perhaps

> It's a rather difficult problem though.

Yup.


-------------------------------------------------------------------------
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:       |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com    |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org  |
-------------------------------------------------------------------------