status = "disabled"

[Warner Losh]

On Feb 2, 2014, at 9:13 AM, Nathan Whitehorn wrote:

> On 02/02/14 09:59, Weiß, Jürgen wrote:
>> 
>>> -----Original Message-----
>>> From: Nathan Whitehorn [mailto:nwhitehorn at freebsd.org]
>>> Sent: Sunday, February 02, 2014 4:20 PM
>>> To: Weiß, Jürgen; freebsd-arm at freebsd.org
>>> Subject: Re: status = "disabled"
>>> 
>>> On 02/02/14 05:55, Weiß, Jürgen wrote:
>>>> Hi,
>>>> 
>>>> it seems your recent changes (261351) discarded a call to fdt_is_enabled
>>>> for devices on simplebus. So 'status = "disabled" ' does not work
>>>> anymore in arm dts.
>>>> 
>>>> Regards
>>>> 
>>>> Juergen Weiss
>>>> 
>>>> Juergen Weiss      |Universitaet Mainz, Zentrum fuer Datenverarbeitung,
>>>> weiss at uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-26407
>>>> 
>>>> 
>>> That's actually required to make some hardware work ("disabled" may just
>>> mean the clock is turned off and needs to be turned back on, which means
>>> you absolutely do want that device probed). The device drivers
>>> themselves, not the bus, should be checking this property and
>>> interpreting it. If this has actually broken hardware, we could add a
>>> temporary #ifdef __arm__ check to the simplebus tree-walker while the
>>> relevant drivers get fixed up.
>>> -Nathan
>> 
>> Thanks for the quick answer. Right know there seem to be zero device drivers
>> doing this. And there are quite a few fdts going from general (all devices on SOC)
>> to specific (devices usable on specific board), which use the status field
>> to disable a device (for example i.mx in general and wandboard specifically).
>> At least with the i.mx6 the unconnected sdhci devices lead to hangs during
>> boot.
>> 
> 
> That's disappointing. I think I'll probably add a hack while we repair any drivers like this.
> 
> For the (near) future, according to the spec (ePAPR section 2.3.4), "disabled" means:
> "Indicates that the device is not presently operational, but it might become operational in the future (for example, something is not plugged in, or is switched off). Refer to the device binding for details on what 'disabled' means for a given device."
> So dropping them at probe time in the bus layer was clearly wrong and indeed breaks some hardware. It would be nice to have some survey of which drivers encounter this issue...

In the yet-to-be-committed Atmel code, disabled is used to mark those devices that can't work because their pins are not brought out to headers, or they are, but they are internally multiplexed to something else...

The reason no drivers do this is because of the check to see if they were enabled in the bus layer, which is now gone... That check was wrong, but this isn't a surprising turn of events...

Warner