Re: [PATCH v2 01/02] ARM: shmobile: Add SDHI devices to r8a7791 DTSI

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Wed, Feb 12, 2014 at 9:51 AM, Magnus Damm <magnus.damm@xxxxxxxxx> wrote:
>>>>>  - add r8a7790 suffix as fall back in case r8a7791 is missing from the driver

>>>>> +       sdhi0: sd@ee100000 {
>>>>> +               compatible = "renesas,sdhi-r8a7791", "renesas,sdhi-r8a7790";

>>>> I'm afraid that's not such a good idea: what if r8a7791 SDHI turns out to have a
>>>> slight incompatibility with r8a7790 SDHI later?
>>>
>>> It's a fallback so later we will simply use r8a7791 instead. r8a7790
>>> is currently used with the v3.14-rc version of the SDHI driver. Future
>>> ones always include r8a7791. How does that introduce any issues?
>>
>> Bummer, yes, it prefers the first compatible entry.
>>
>> Will refrain from sending more emails until my coffee has been digested ;-)
>
> Heheh. But I think you raise a valid point:
>
> Using the wrong SoC in the compatible string is pretty darn ugly.
>
> What is the best practise here?

(adding devicetree)

It should be a reference to the hardware block.

Before the advent of SoCs, a hardware block was an IC, with a part number
(e.g. de21040), and sometimes a name (e.g. tulip). Further evolutions of the
hardware block got (usually, but not always) different part numbers.

With SoCs, the part numbers of the hardware blocks were lost. Only the SoC
still carries a part number. The hardware blocks (now called "IP cores") still
have names (e.g. RSPI), but they're more abstract, and it's difficult to know
what exact version of the hardware block they're referring to[*].

Using "<manufacturer>,<name>-<soc>" is future-proof, but cumbersome.
Having a more generic fallback name to group SoCs with the same IP core
is convenient.

So we have to "invent" generic fallback names with versioning ourselves?

  - SoC family name? But there's no guarantee a new SoC from the same
    family will be 100% compatible.
  - "-v1", "-v2" suffixes? The new SoC may have something in between
    v1 and v2
  - ???

[*] With OpenRISC it's easier, as we have the hardware source files, but
    it's still cumbersome to find good version naming.
    The OpenCores-mandated "<name>-rtlsvn<version>" is not such a good
    match for todays distributed development, with IP cores being imported
    into git repositories and modified there.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux