Date: Sun, 2 Feb 2014 12:35:38 -0700 From: Warner Losh <imp@bsdimp.com> To: Nathan Whitehorn <nwhitehorn@freebsd.org> Cc: "'freebsd-arm@freebsd.org'" <freebsd-arm@FreeBSD.org> Subject: Re: status = "disabled" Message-ID: <4F893AE1-6B64-469D-AF3C-8AB2EB9D0ED9@bsdimp.com> In-Reply-To: <52EE6EA1.90707@freebsd.org> References: <726dc97ccd1f44b3ba9d7bee3eeff08a@e15be-01.zdv.Uni-Mainz.DE> <52EE622C.9010004@freebsd.org> <06235e983f8142fcb7f6f6c329a84b90@e15be-01.zdv.Uni-Mainz.DE> <52EE6EA1.90707@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 2, 2014, at 9:13 AM, Nathan Whitehorn wrote:
> On 02/02/14 09:59, Wei=DF, J=FCrgen wrote:
>>=20
>>> -----Original Message-----
>>> From: Nathan Whitehorn [mailto:nwhitehorn@freebsd.org]
>>> Sent: Sunday, February 02, 2014 4:20 PM
>>> To: Wei=DF, J=FCrgen; freebsd-arm@freebsd.org
>>> Subject: Re: status =3D "disabled"
>>>=20
>>> On 02/02/14 05:55, Wei=DF, J=FCrgen wrote:
>>>> Hi,
>>>>=20
>>>> it seems your recent changes (261351) discarded a call to =
fdt_is_enabled
>>>> for devices on simplebus. So 'status =3D "disabled" ' does not work
>>>> anymore in arm dts.
>>>>=20
>>>> Regards
>>>>=20
>>>> Juergen Weiss
>>>>=20
>>>> Juergen Weiss |Universitaet Mainz, Zentrum fuer =
Datenverarbeitung,
>>>> weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: =
+49(6131)39-26407
>>>>=20
>>>>=20
>>> 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
>>=20
>> 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.
>>=20
>=20
> That's disappointing. I think I'll probably add a hack while we repair =
any drivers like this.
>=20
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F893AE1-6B64-469D-AF3C-8AB2EB9D0ED9>