status = "disabled"

[Ian Lepore]

On Sun, 2014-02-02 at 10:13 -0600, 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...
> -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 at 021e8000> mem 0x21e8000-0x21ebfff irq 59 type unknown (no driver attached)
simplebus1: <serial at 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