Date: Sun, 02 Feb 2014 12:29:16 -0700 From: Ian Lepore <ian@FreeBSD.org> To: Nathan Whitehorn <nwhitehorn@FreeBSD.org> Cc: "'freebsd-arm@freebsd.org'" <freebsd-arm@FreeBSD.org> Subject: Re: status = "disabled" Message-ID: <1391369356.13026.27.camel@revolution.hippie.lan> 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 Sun, 2014-02-02 at 10:13 -0600, Nathan Whitehorn wrote:
> On 02/02/14 09:59, Wei=DF, J=FCrgen wrote:
> >
> >> -----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"
> >>
> >> On 02/02/14 05:55, Wei=DF, J=FCrgen wrote:
> >>> Hi,
> >>>
> >>> it seems your recent changes (261351) discarded a call to fdt_is_en=
abled
> >>> for devices on simplebus. So 'status =3D "disabled" ' does not work
> >>> anymore in arm dts.
> >>>
> >>> Regards
> >>>
> >>> Juergen Weiss
> >>>
> >>> Juergen Weiss |Universitaet Mainz, Zentrum fuer Datenverarbeit=
ung,
> >>> weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6=
131)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 m=
eans
> >> 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 th=
e
> >> 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 de=
vices 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 specif=
ically).
> > At least with the i.mx6 the unconnected sdhci devices lead to hangs d=
uring
> > boot.
> >
>=20
> That's disappointing. I think I'll probably add a hack while we repair=20
> any drivers like this.
> For the (near) future, according to the spec (ePAPR section 2.3.4),=20
> "disabled" means:
> "Indicates that the device is not presently operational, but it might=20
> become operational in the future (for example, something is not plugged=
=20
> in, or is switched off). Refer to the device binding for details on wha=
t=20
> 'disabled' means for a given device."
> So dropping them at probe time in the bus layer was clearly wrong and=20
> indeed breaks some hardware. It would be nice to have some survey of=20
> which drivers encounter this issue...
> -Nathan
As of r261410 all the drivers that are children of simplebus now check
their status properties for themselves. I've tested on wandboard, rpi,
beaglebone white, and dreamplug and everything seems to be working.
One side effect of all this is that you may see some new messages at
boot, such as:
simplebus1: <serial@021e8000> mem 0x21e8000-0x21ebfff irq 59 type unknown=
(no driver attached)
simplebus1: <serial@021ec000> mem 0x21ec000-0x21effff irq 60 type unknown=
(no driver attached)
These are not errors, that's just what a disabled device looks like now.
I think they'll only show up if bootverbose is set.
-- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1391369356.13026.27.camel>