linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm-soc: Add Sigma Designs Tango4 port
Date: Fri, 2 Oct 2015 19:53:37 +0100	[thread overview]
Message-ID: <20151002185337.GC21513@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <560EC863.8030600@free.fr>

On Fri, Oct 02, 2015 at 08:09:39PM +0200, Mason wrote:
> 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?

You could do:
			compatible = "sigma,tango4-intc",
				     "sigma,tango-intc",
				     "sigma,smp8640-intc";

The advantage of using the most specific first is that if you then find
the hardware contains bugs, you can _just_ modify the device driver to
match on the specific ID, and implement workarounds based on that.  Older
device trees will then pick up those same workarounds without needing to
be modified.

Remember, device trees are supposed to describe the hardware.

> (If worse comes to worst, I suppose I can always write my own
> driver from scratch; I just find it silly to duplicate work.)

It's not about writing a separate driver.  What the above says is that
this device is first and foremost a "sigma,tango4-intc" device, but if
we don't have such a driver, it can be driven by a driver for
"sigma,tango-intc", but if we don't have one of those, then it can
be driven by a "sigma,smp8640-intc" driver.

Please read the quoted bit of the spec on this to get a proper
understanding of how these compatible strings are supposed to 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.

It doesn't matter who you speak for.  Your first patch should be to
_only_ add the vendor ID to that file above, and to get it acked by
the device tree maintainers.  That makes it "official" in the eyes of
the developers responsible for maintaining the sanity of device tree.

However, that has an impact on the above: you should therefore have
access to the folk who know the origins of the interrupt controller,
and whether it is a derivative of "sigma,smp8640-intc" or something
else.  If "sigma,smp8640-intc" and "sigma,tango-intc" are jointly
derived from a common ancestor, then you should not mention
"sigma,smp8640-intc" at all.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

  reply	other threads:[~2015-10-02 18:53 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-02 16:02 [PATCH] arm-soc: Add Sigma Designs Tango4 port Mason
2015-10-02 16:10 ` Måns Rullgård
2015-10-02 16:33   ` Mason
2015-10-02 16:55     ` Måns Rullgård
2015-10-02 18:00       ` Mason
2015-10-02 17:13     ` Russell King - ARM Linux
2015-10-02 18:09       ` Mason
2015-10-02 18:53         ` Russell King - ARM Linux [this message]
2015-10-02 19:25           ` Mason
2015-10-02 19:56 ` Arnd Bergmann
2015-10-02 20:53   ` Mason
2015-10-02 21:11     ` Arnd Bergmann
2015-10-02 21:57       ` Mason
2015-10-02 22:12         ` Arnd Bergmann
2015-10-05 16:25           ` [PATCH v2] arm-soc: Add support for Sigma Designs Tango4 Marc Gonzalez
2015-10-06 15:57             ` [PATCH v3] " Marc Gonzalez
2015-10-09 13:18               ` Arnd Bergmann
2015-10-09 13:30                 ` Marc Gonzalez
2015-10-09 14:40                 ` Måns Rullgård
2015-10-09 19:01                 ` Mason
2015-10-09 20:24                   ` Måns Rullgård
2015-10-09 21:12                     ` Mason
2015-10-09 14:08               ` Rob Herring
2015-10-09 14:16                 ` Marc Gonzalez
2015-10-09 14:48                   ` Rob Herring
2015-10-13 15:54                 ` Marc Gonzalez
2015-10-13 17:55                   ` Rob Herring
2015-10-19 11:09                     ` Marc Gonzalez
2015-10-19 16:39                       ` Rob Herring
2015-10-19 17:32                         ` Mark Rutland
2015-10-20  9:20                           ` Marc Gonzalez
2015-10-20  9:50                         ` Marc Gonzalez
2015-10-20 10:04                           ` Russell King - ARM Linux
2015-10-20 10:54                             ` Marc Gonzalez
2015-10-09 14:12             ` [PATCH v2] " Rob Herring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151002185337.GC21513@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).