devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robh+dt@kernel.org>
To: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Cc: Marek Vasut <marex@denx.de>,
	Jaehoon Chung <jh80.chung@samsung.com>,
	Alexey Brodkin <Alexey.Brodkin@synopsys.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: ARC dw-mshc binding compat string
Date: Mon, 28 Mar 2016 14:00:55 -0500	[thread overview]
Message-ID: <CAL_JsqL1asMFVFX_p3P+ov_+9prmcQ0PZJOiAX7D5iJ7GEssgQ@mail.gmail.com> (raw)
In-Reply-To: <56F958DC.5010203@mentor.com>

On Mon, Mar 28, 2016 at 11:16 AM, Vladimir Zapolskiy
<vladimir_zapolskiy@mentor.com> wrote:
> Hi,
>
> On 28.03.2016 15:50, Marek Vasut wrote:
>> On 03/28/2016 12:34 PM, Jaehoon Chung wrote:
>>> Hi,
>>
>> Hi,
>>
>> [...]
>>
>>>>>>>>>> That said, I would rather prefer to see "snps,dw-mshc" prefix on description
>>>>>>>>>> of an MMC controller found on SoCFPGA series, "altr,socfpga-dw-mshc" seems
>>>>>>>>>> to be redundant.
>>>
>>> Yes..it's redundant..i should be combined to "snps,dw-mshc".
>>
>> Should the compat string be
>>   compatible = "altr,socfpga-dw-mshc", "snps,dw-mshc";
>> or just
>>   compatible = "snps,dw-mshc";
>> ?
>>
>> I am under the impression that a soc-specific identifier in addition to
>> a generic one (used by the driver compat table) is a good idea, because
>> it can help discerning the IP block from a generic one if needed at some
>> future point in time. It will also not break the DT for systems
>> which may depend on the non-generic compat, like *BSDs and such.
>>
>> What do you think ? (btw this is very much my question in this thread)
>
> IMO just 'compatible = "snps,dw-mshc"' is good enough, if it completely
> describes the IP block on SoCFGPA --- and from what I get it is the case.
> You can add a SoC-specific compatible if it is needed later on, and to my
> taste only if SoC specific features can not be covered by properties.

You can add the SoC-specific compatible string to the kernel later on.
You may not be able to update your DTB later on. So the specific
compatible strings need to be in the DT from the start.

There's no set rule on properties vs. implied by a compatible string,
but generally if it is fixed in the SoC, get the information based on
the compatible string. If it is a board level decision or has to be
tuned, then use a property.

> The same sole "snps,dw-mshc" compatible is specified for NXP LPC18xx/43xx,
> ZTE ZX and HiSilicon ARM SoCs.

They should be fixed.

> Another similar example is ARM PrimeCell PLxxx IP blocks, as far as
> I know there is no SoC-specific compatibles/aliases for PrimeCell IP blocks.

There are some for ST variants I think. PrimeCell blocks are a bit
different in that they generally pretty simple blocks, have not
changed much, and they
have a standard ID register that has been sufficient for determining
differences. And we have a standard way to override the ID register
when it is wrong. Look at recent patches for Denali NAND controller if
you want an example of why IP version registers (or compatible
strings) can't be trusted.

Once you get into IP blocks with lots of configuration options,
complicated clocking, power domains, and with phys on the front end,
then you hit all the integration differences.

Rob

      reply	other threads:[~2016-03-28 19:00 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-26 10:14 ARC dw-mshc binding compat string Marek Vasut
2016-03-26 17:26 ` Vladimir Zapolskiy
     [not found]   ` <56F6C639.5000301-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
2016-03-26 17:30     ` Marek Vasut
2016-03-26 17:46       ` Alexey Brodkin
2016-03-26 17:52       ` Vladimir Zapolskiy
     [not found]         ` <56F6CC68.5040408-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
2016-03-26 18:10           ` Marek Vasut
2016-03-26 18:16             ` Vladimir Zapolskiy
     [not found]               ` <56F6D1E9.3050606-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
2016-03-26 19:52                 ` Marek Vasut
     [not found]                   ` <56F6E860.8070207-ynQEQJNshbs@public.gmane.org>
2016-03-26 20:12                     ` Vladimir Zapolskiy
     [not found]                       ` <56F6ED41.5020908-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
2016-03-26 20:24                         ` Marek Vasut
2016-03-28  9:37                           ` Alexey Brodkin
     [not found]                             ` <1459157818.4785.5.camel-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
2016-03-28 10:34                               ` Jaehoon Chung
2016-03-28 10:55                                 ` Alexey Brodkin
2016-03-28 11:44                                   ` Jaehoon Chung
2016-03-28 12:43                                 ` Rob Herring
2016-03-28 12:52                                   ` Marek Vasut
2016-03-28 12:50                                 ` Marek Vasut
2016-03-28 16:16                                   ` Vladimir Zapolskiy
2016-03-28 19:00                                     ` Rob Herring [this message]

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=CAL_JsqL1asMFVFX_p3P+ov_+9prmcQ0PZJOiAX7D5iJ7GEssgQ@mail.gmail.com \
    --to=robh+dt@kernel.org \
    --cc=Alexey.Brodkin@synopsys.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jh80.chung@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=marex@denx.de \
    --cc=vladimir_zapolskiy@mentor.com \
    /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).