Re: [Ksummit-discuss] [TECH TOPIC] Driver model/resources, ACPI, DT, etc (sigh)

[Thomas Petazzoni <thomas.petazzoni@free-electrons.com>]

Dear Jason Cooper,

On Mon, 5 May 2014 12:02:37 -0400, Jason Cooper wrote:

> > On the flip side, DT entirely lacks any sort of infrastructure for
> > quirks other than match table data, and it handles various quirks
> > inline mostly. It's not so much of a problem now as much of PPC is
> > pretty stable and ARM is still a newcomer to DT, but I worry that we
> > have an impending problem as ARM DTs start to mature. So what is the
> > direction we want to go with quirks which can't be self-contained
> > within drivers?
> 
> regrettably, soc code.  We (mvebu) have the good fortune to be
> integrating mainline support for brand new SoCs from Marvell, as they
> ship.  Unfortunately, this means that the free-electron's guys
> (contracted by Marvell to mainline the code) are having to work with
> pre-release SoCs (Z1 stepping).

On the other hand, Rob was asking about "quirks which can't be
self-contained within drivers". And the two quirks below:

> static void __init mvebu_dt_init(void)
> {
>         if (of_machine_is_compatible("plathome,openblocks-ax3-4"))
>                 i2c_quirk();
>         if (of_machine_is_compatible("marvell,a375-db"))
>                 thermal_quirk();

could perfectly be fine be self-contained into the respective device
drivers. Actually, for the I2C quirk, it was even the original
implementation that my colleague Gregory Clement proposed. But this
approach was rejected, and we were asked to replace that by the current
approach: a quirk in the mach-mvebu SoC code that changes the
compatible string.

I continue to have the feeling that the strategy we have been asked to
use is going against the principle of having less stuff in mach-<foo>
directories.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com