[PATCH] arm-soc: Add Sigma Designs Tango4 port

[slash.tmp@free.fr (Mason)]

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.