On Tue, Apr 12, 2016 at 03:27:32PM -0700, Tony Lindgren wrote:
> * Rob Herring [160412 15:22]:
> > On Tue, Apr 12, 2016 at 4:41 PM, Frank Rowand
> > 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 re
On Tue, Apr 12, 2016 at 03:39:30PM -0700, Frank Rowand wrote:
> On 4/12/2016 1:13 PM, Frank Rowand wrote:
> > Hi Tony,
>
> < snip >
>
> > With that change, the bulk of your patch looks good, with
> > minor changes:
> >
> > __of_device_is_available() would not need to change.
> >
> > __of_de
* Frank Rowand [160412 15:40]:
> On 4/12/2016 1:13 PM, Frank Rowand wrote:
> > Hi Tony,
>
> < snip >
>
> > With that change, the bulk of your patch looks good, with
> > minor changes:
> >
> > __of_device_is_available() would not need to change.
> >
> > __of_device_is_incomplete() would cha
On 4/12/2016 1:13 PM, Frank Rowand wrote:
> Hi Tony,
< snip >
> With that change, the bulk of your patch looks good, with
> minor changes:
>
> __of_device_is_available() would not need to change.
>
> __of_device_is_incomplete() would change to check the new
> boolean property. (And I wou
On 4/12/2016 3:20 PM, Rob Herring wrote:
> On Tue, Apr 12, 2016 at 4:41 PM, Frank Rowand wrote:
>> On 4/12/2016 1:34 PM, Tony Lindgren wrote:
>>> Hi,
>>>
>>> * Frank Rowand [160412 13:15]:
Hi Tony,
I agree with the need for some way of handling the incomplete
hardware issue.
* Rob Herring [160412 15:22]:
> On Tue, Apr 12, 2016 at 4:41 PM, Frank Rowand 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 descripti
On Tue, Apr 12, 2016 at 4:41 PM, Frank Rowand wrote:
> On 4/12/2016 1:34 PM, Tony Lindgren wrote:
>> Hi,
>>
>> * Frank Rowand [160412 13:15]:
>>> Hi Tony,
>>>
>>> I agree with the need for some way of handling the incomplete
>>> hardware issue. I like the idea of having a uniform method for
>>>
* Frank Rowand [160412 14:42]:
> On 4/12/2016 1:34 PM, Tony Lindgren wrote:
> >
> > 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
> >
On 4/12/2016 1:34 PM, Tony Lindgren wrote:
> Hi,
>
> * Frank Rowand [160412 13:15]:
>> Hi Tony,
>>
>> I agree with the need for some way of handling the incomplete
>> hardware issue. I like the idea of having a uniform method for
>> all nodes.
>>
>> I am stumbling over what the status property i
Hi,
* Frank Rowand [160412 13:15]:
> Hi Tony,
>
> I agree with the need for some way of handling the incomplete
> hardware issue. I like the idea of having a uniform method for
> all nodes.
>
> I am stumbling over what the status property is supposed to convey
> and what the "fail-hw-incomplet
Hi Tony,
I agree with the need for some way of handling the incomplete
hardware issue. I like the idea of having a uniform method for
all nodes.
I am stumbling over what the status property is supposed to convey
and what the "fail-hw-incomplete" is meant to convey.
The status property is meant
We have devices that are in incomplete state, but still need to be
probed to allow properly idling them for PM. Some examples are
devices that are not pinned out on certain packages, or otherwise
not enabled for use on some SoCs.
Setting status = "disabled" cannot be used for this case. Setting
"d
12 matches
Mail list logo
