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

[Rob Herring <robherring2@gmail.com>]

On Mon, May 5, 2014 at 3:43 AM, Benjamin Herrenschmidt <benh@au1.ibm.com> wrote:
> On Sun, 2014-05-04 at 23:33 +0200, Rafael J. Wysocki wrote:
>>
>>
>> But we have such quirks for some bus types already, like PCI and PNP.
>
> And they suck big time. They duplicate definitions from the driver,
> they get missed at grep time, they bit rot, etc...
>
> There are a few cases where that's justified simply because the driver
> can be a module but the quirk needs to run early and always, but mostly
> these quirks are about working around HW bugs that would otherwise cause
> the system to misbehave even in absence of the driver.
>
> For example, bad class code in bridges, BAR issues, etc...
>
> Generally speaking though, quirks like that are a bad idea and in this
> case, totally unjustified since the code performing whatever translation
> is necessary (or interpretation) is entirely specific to the driver
> anyway.

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?

Rob