[PATCH] arm-soc: Add Sigma Designs Tango4 port
Mason
slash.tmp at free.fr
Fri Oct 2 11:09:39 PDT 2015
On 02/10/2015 19:13, Russell King - ARM Linux wrote:
> On Fri, Oct 02, 2015 at 06:33:48PM +0200, Mason wrote:
>> On 02/10/2015 18:10, Måns Rullgård wrote:
>>
>>> Mason writes:
>>>
>>>> + intc: intc at e000 {
>>>> + compatible = "sigma,tango-intc";
>>>
>>> Why do you insist on using other names than the ones I've been using for
>>> months? Just want to leave your own mark on the code?
>>
>> You're using "sigma,smp8640-intc".
>> The SMP8640 is a Tango3 (MIPS-based) platform.
>
> If it's the same device, then there's nothing wrong with re-using the
> compatible. The compatible property actually accepts multiple values,
> so you can do:
>
> compatible = "sigma,tango4-intc", "sigma,smp8640-intc";
I have access to resources unavailable to Mans. Since I know the
interrupt controller is the same on Tango2, Tango3 and Tango4,
doesn't it make sense to use the string "sigma,tango-intc"
given that the driver is not even upstream yet?
(If worse comes to worst, I suppose I can always write my own
driver from scratch; I just find it silly to duplicate work.)
> See the ePAPR spec - I'll include the relevant bit:
>
> Property: compatible
> Value type: <stringlist>
> Description: The compatible property value consists of one or more strings
> that define the specific programming model for the device. This list of
> strings should be used by a client program for device driver selection.
> The property value consists of a concatenated list of null terminated
> strings, from most specific to most general. They allow a device to
> express its compatibility with a family of similar devices, potentially
> allowing a single device driver to match against several devices. ...
> Example: compatible = "fsl,mpc8641-uart", "ns16550";
> In this example, an operating system would first try to locate a device
> driver that supported fsl,mpc8641-uart. If a driver was not found, it
> would then try to locate a driver that supported the more general
> ns16550 device type.
>
> Note also that vendor prefixes should be listed in
> Documentation/devicetree/bindings/vendor-prefixes.txt. If it's not there,
> you need to propose a separate patch (to the devicetree mailing list) to
> add it, which must be done with their agreement. Right now, the use of
> "sigma" as a prefix is entirely non-standard and not acceptable in DT
> files until this is done.
As far as the upstreaming process is concerned, I speak for Sigma.
Regards.
More information about the linux-arm-kernel
mailing list