mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nishanth Menon <nm@ti.com>
To: Rob Herring <robh+dt@kernel.org>,
	Tony Lindgren <tony@atomide.com>,
	Frank Rowand <frowand.list@gmail.com>
Cc: Grant Likely <grant.likely@linaro.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-omap <linux-omap@vger.kernel.org>,
	Tero Kristo <t-kristo@ti.com>, Tom Rini <trini@konsulko.com>
Subject: Re: [PATCHv2] of: Add generic handling for ePAPR 1.1 fail-sss states
Date: Thu, 8 Sep 2016 09:20:28 -0500	[thread overview]
Message-ID: <7a5e1cd7-1dbf-0288-066e-5cd3b108f092@ti.com> (raw)
In-Reply-To: <CAL_Jsq+dm5HMkX8DNNZNB2QF-VPg96Esb+Capv88zys9nAPksw@mail.gmail.com>

On 09/08/2016 08:38 AM, Rob Herring wrote:
> On Wed, Aug 31, 2016 at 4:41 PM, Tony Lindgren <tony@atomide.com> wrote:
[...]
>>> It is unfortunate that Linux has adopted the practice of overloading status
>>> to determine whether a piece of hardware exists or does not exist.  This
>>> is extremely useful for the way we structure the .dts and .dtsi files but
>>> should have used a new property name.  We are stuck with that choice of
>>> using the status property for two purposes, first the state of a device,
>>> and secondly the hardware description of existing or not existing.
>
> I don't agree. Generally, disabled means the h/w is there, but don't
> use it. There may be some cases where the hardware doesn't exist for
> the convenience of having a single dts, but that's the exception.
>

Minor point here: when SoCs are manufactured, even though the silicon 
die may have a hardware block, it is completely efused out based on 
paper spin. in effect such a hardware block "does not exist". The 
number of such paper spins are not exception cases, but rather 
standard for SoC vendors - maintaining dts per paper spin is just too 
impossible to maintain (DRA7 as an example maintains a single 
dra7.dtsi as the root for all paper spins.. the variations if 
maintained as seperate dts might infact end up being larger in number 
than all the dts we have in arch/arm/boot/dts) - typically as an soc 
vendor pushes a specific SoC to multiple markets, this tends to be a norm.

-- 
Regards,
Nishanth Menon

  reply	other threads:[~2016-09-08 14:20 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-29 22:35 Tony Lindgren
2016-08-30  0:23 ` Rob Herring
2016-08-30  0:39   ` Tony Lindgren
2016-08-31 17:47     ` Tony Lindgren
2016-08-31 20:50 ` Frank Rowand
2016-08-31 21:41   ` Tony Lindgren
2016-09-08 13:38     ` Rob Herring
2016-09-08 14:20       ` Nishanth Menon [this message]
2016-09-08 15:58       ` Tony Lindgren
2016-09-08 19:09         ` Frank Rowand
2016-09-08 19:17           ` Frank Rowand
2016-09-08 20:19             ` Tony Lindgren
2016-09-08 19:05       ` Frank Rowand
2016-09-09  2:43         ` Rob Herring
2016-09-09 14:10           ` Tom Rini
2016-09-10  1:11             ` Matthijs van Duin
2016-09-12 13:35               ` Tom Rini
2016-09-12 13:46                 ` Matthijs van Duin
2016-09-12 13:49                   ` Tom Rini
2016-09-12 13:38               ` Tom Rini

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=7a5e1cd7-1dbf-0288-066e-5cd3b108f092@ti.com \
    --to=nm@ti.com \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=grant.likely@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=t-kristo@ti.com \
    --cc=tony@atomide.com \
    --cc=trini@konsulko.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

all inboxes | Powered by JetHome®