linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sebastian Frias <sf84@laposte.net>
To: Jason Cooper <jason@lakedaemon.net>, Mason <slash.tmp@free.fr>
Cc: 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, 6 Jul 2016 13:37:21 +0200	[thread overview]
Message-ID: <577CED71.4090406@laposte.net> (raw)
In-Reply-To: <20160705161654.GH3348@io.lakedaemon.net>

Hi Jason,

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?

>In a series of compatible IP blocks, the string should refer
> to the first version in the series, e.g. sigma,smp8710 for a series of
> compatible IP blocks like 8710, 8712, 8715, 8724.  If an 8751 came along
> with a different register layout or some other incompatibility, then a
> new string would be sigma,smp8751.  So,
> 
>   8710 uses "sigma,smp8710"
>   8712 uses "sigma,smp8710"
>   8715 uses "sigma,smp8710"
>   8724 uses "sigma,smp8710"
>   8751 uses "sigma,smp8751"
>   8754 uses "sigma,smp8751"
> 

But this is not consistent with the strings for generic drivers, like
"generic-xhci", etc.

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").

And the DT for a given chip should describe the collection of HW modules
that make up the SoC, regardless of what chip introduced them or what
other chip uses it. Why would that be relevant anyway?

By that reasoning, I also think that drivers/net/ethernet/aurora/nb8800.c
should have had a string like "aurora,nb8800,sigma" or something, to
specify that it is a NB8800 from Aurora integrated in a Sigma platform.
That way it can behave as vanilla NB8800 when the string is "aurora,nb8800"
and it can adapt its behaviour to Sigma's platform when a different string
(like "aurora,nb8800,sigma") is used in the DT.

Later if Sigma modified the nb8800 HW, it could be "aurora,nb8800,sigma-v2".
The same way, if later Sigma used a different Aurora HW module, the DT
would say "aurora,nb2000,sigma" (to signal that another driver is required)

Instead, drivers/net/ethernet/aurora/nb8800.c has "sigma,smp8642-ethernet"
string, which ties it to a particular chip, and I don't see how does that
convey version about the module or other relevant information; Plus it is
confusing if the same module is then embedded on a SMP8756 chip.

Would you mind explaining how does that contrasts with the logic used
by DT naming conventions?

Best regards,

Sebastian

  reply	other threads:[~2016-07-06 11:37 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 [this message]
2016-07-06 16:28             ` Jason Cooper
2016-07-20 11:42               ` Sebastian Frias
2016-07-20 13:56                 ` Jason Cooper
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=577CED71.4090406@laposte.net \
    --to=sf84@laposte.net \
    --cc=jason@lakedaemon.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --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 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).