lkml.org 
[lkml]   [2016]   [Apr]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] of: Add generic handling for hardware incomplete fail state
* Rob Herring <robh+dt@kernel.org> [160412 15:22]:
> On Tue, Apr 12, 2016 at 4:41 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> >>> Status of "fail-sss" is meant to indicate an error was detected in
> >>> the device, and that the error might (or might not) be repairable.
> >>>
> >>> So the difference I see is state vs hardware description.
>
> The question to ask is are we indicating the "operational status of a
> device"? If yes, that is the definition of status and using it would
> be appropriate.
>
> IMO, I think we are.
>
> >> OK thanks for the clarification. I don't see why "fail-hw-incomplete"
> >> could not be set dynamically during the probe in some cases based
> >> on the SoC revision detection for example. So from that point of
> >> view using status with the "fail-sss" logic would make more sense.
> >
> > If the probe detects that the device should only be power managed
> > based on the SoC revision, then it would simply be one more
> > test added at the top of probe. The patch would change from:
> >
> > if (of_device_is_incomplete(pdev->dev.of_node)) {
> >
> > to:
> >
> > if (of_device_is_incomplete(pdev->dev.of_node) || socrev == XXX) {
>
> I think Tony meant the bootloader or platform code would do this and
> tweak the DT. We don't have much of a standard API for revision
> checking, so drivers don't check SoC revisions generally.

Yes bootloader may need to set these based on the SoC revision.
There are already many boards with multiple SoC variants
available. Would like to hear Tom's comments on this one as
well from the u-boot point of view.

Regards,

Tony

\
 
 \ /
  Last update: 2016-04-13 00:41    [W:0.048 / U:0.376 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site