Date: Sun, 02 Feb 2014 10:13:21 -0600 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: =?ISO-8859-1?Q?=22Wei=DF=2C_J=FCrgen=22?= <weiss@uni-mainz.de>, "'freebsd-arm@freebsd.org'" <freebsd-arm@FreeBSD.org> Subject: Re: status = "disabled" Message-ID: <52EE6EA1.90707@freebsd.org> In-Reply-To: <06235e983f8142fcb7f6f6c329a84b90@e15be-01.zdv.Uni-Mainz.DE> References: <726dc97ccd1f44b3ba9d7bee3eeff08a@e15be-01.zdv.Uni-Mainz.DE> <52EE622C.9010004@freebsd.org> <06235e983f8142fcb7f6f6c329a84b90@e15be-01.zdv.Uni-Mainz.DE>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02/02/14 09:59, Weiß, Jürgen wrote:
>
>> -----Original Message-----
>> From: Nathan Whitehorn [mailto:nwhitehorn@freebsd.org]
>> Sent: Sunday, February 02, 2014 4:20 PM
>> To: Weiß, Jürgen; freebsd-arm@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@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...
-Nathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52EE6EA1.90707>