All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Cooper <jason@lakedaemon.net>
To: Sebastian Frias <sf84@laposte.net>
Cc: Mason <slash.tmp@free.fr>, LKML <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marc Zyngier <marc.zyngier@arm.com>
Subject: Re: [RFC PATCH v1] irqchip: add support for SMP irq router
Date: Wed, 20 Jul 2016 13:56:47 +0000	[thread overview]
Message-ID: <20160720135647.GH5814@io.lakedaemon.net> (raw)
In-Reply-To: <578F63B5.3080409@laposte.net>

Hey Sebastian,

On Wed, Jul 20, 2016 at 01:42:45PM +0200, Sebastian Frias wrote:
> On 07/06/2016 06:28 PM, Jason Cooper wrote:
> > On Wed, Jul 06, 2016 at 01:37:21PM +0200, Sebastian Frias wrote:
> >> On 07/05/2016 06:16 PM, Jason Cooper wrote:
> >>>> Come to think of it, I'm not sure the *name* of the file documenting
> >>>> a binding is as important to DT maintainers as the compatible string.
> >>>
> >>> Correct.  devicetee compatible strings need to be as specific as
> >>> possible.  
> >>
> >> Specific with respect to what thing? To the HW module they are describing
> >> (USB, IRQ controller, etc.) or to the chip the HW module it is embedded
> >> into?
> > 
> > The compatible string uniquely identifies an interface between an IP
> > block and the software (the devicetree binding).  We use the most
> > specific model number or name we can for that IP block when we create
> > the binding and the compatible string.
> 
> Ok, so we agree that the string identifies the HW block itself, and not the
> chip in which it is embedded into.

If *possible*.  When we converted kirkwood and the other legacy Marvell
ARMv5 SoCs to devicetree, the most specific way we could identify the
irq controller was 'marvell,orion-intc'.  Orion being the name of the
first platform it was seen on.

When that was chosen, mv68xx0, orion5x, kirkwood, and I think dove were
already deployed to market.  So we had a *lot* more latent information
to look at.

Now that SoC manufacturers are doing a much better job mainlining code,
the situation is reversed.  There's little information on what is
actually delivered to the market (because code is getting posted *prior*
to SoC deployment), but we have better access to specifications and
software devs.

So, if we have access to specific IP block identifiers, we'll use them.
If we don't, we're not going to let that hold up the train waiting for
the 'perfect' binding.

> >> A SoC is composed of several HW modules, some are shared among different
> >> manufacturers (i.e.: "generic-xhci"), and some are shared among different
> >> product lines of the same manufacturer (i.e.: "sigma,smp,irqrouter").
> > 
> > Yes, that's why it's critical to be specific.  We want to reuse drivers
> > where it makes sense.  We can if the interface is the same.
> 
> Ok, so is "sigma,smp,irqrouter" good or not?

If you have a unique identifier for the irqchip, use it.  If not, the
convention is to use the identifier of the SoC.

thx,

Jason.

  reply	other threads:[~2016-07-20 13:56 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-30 16:03 [RFC PATCH v1] irqchip: add support for SMP irq router Sebastian Frias
2016-07-04 12:11 ` Mason
2016-07-05 12:30   ` Sebastian Frias
2016-07-05 14:41     ` Jason Cooper
2016-07-05 15:07       ` Mason
2016-07-05 16:16         ` Jason Cooper
2016-07-06 11:37           ` Sebastian Frias
2016-07-06 16:28             ` Jason Cooper
2016-07-20 11:42               ` Sebastian Frias
2016-07-20 13:56                 ` Jason Cooper [this message]
2016-07-05 15:18       ` Sebastian Frias
2016-07-05 15:53         ` Jason Cooper
2016-07-05 16:38           ` Sebastian Frias
2016-07-05 16:48             ` Marc Zyngier
2016-07-05 16:59               ` Sebastian Frias
2016-07-05 17:13                 ` Marc Zyngier
2016-07-05 19:24                   ` Thomas Gleixner
2016-07-06  8:58                     ` Marc Zyngier
2016-07-06  9:30                       ` Thomas Gleixner
2016-07-06 10:49                         ` Sebastian Frias
2016-07-06 13:54                           ` Marc Zyngier
2016-07-06 16:49                         ` Jason Cooper
2016-07-06 10:47                   ` Sebastian Frias
2016-07-06 13:50                     ` Marc Zyngier
2016-07-07 12:16                       ` Sebastian Frias
2016-07-07 12:42                         ` Marc Zyngier
2016-07-19 14:23                           ` [RFC PATCH v2] " Sebastian Frias
2016-07-19 16:49                             ` Thomas Gleixner
2016-07-20 11:06                               ` Sebastian Frias
2016-07-20 13:19                                 ` Marc Zyngier
2016-07-20 14:38                                 ` Thomas Gleixner
2016-07-20  9:35                             ` Marc Gonzalez

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=20160720135647.GH5814@io.lakedaemon.net \
    --to=jason@lakedaemon.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=sf84@laposte.net \
    --cc=slash.tmp@free.fr \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.