Re: CPU revision IDs

[Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]

On Fri, Jun 13, 2014 at 09:14:45AM -0400, jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> On Fri, Jun 13, 2014 at 9:08 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> > On Friday 13 June 2014 09:05:14 jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> >> I was adding the CPU revision ID to the top level compatible string,
> >> nothing specific to the device.  By knowing the CPU revision I know
> >> which errata to apply.
> >>
> >> If you patch the device strings, then you have to maintain knowledge
> >> of which devices are broken in two places -- the device driver and the
> >> machine file where you are patching the strings.
> >
> > IMHO, the driver only has to know what device versions exist, it
> > shouldn't need to know which soc has which version of the device.
> >
> > Can you describe which kind of quirk you are looking at in the driver,
> > and how common it is?
> 
> Allwinner wired the volume control for their on-chip codec up
> backwards on the A revsion of the the A10 chip. In later revisions is
> it fixed to work in the right direction.
> 
> I was wanting to add code like this to the device driver...
> 
> if (of_machine_is_compatible("allwinner,sun7i-a20a")) {
>       fix bug
> }
> 
> Another solution would be for me to detect the chip revision in the
> init code of the driver and remember it.

The point is that you don't have that kind of constructs. You can
associate any number of compatibles to your driver, and data to each
of these compatibles. So, with different compatibles, you will be
probed and retrieved these data directly, without even having this in
your driver.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]