Date: Sun, 2 Feb 2014 12:31:44 -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: <D8EF87BF-F09B-4FA0-8460-2249D21CA430@bsdimp.com> In-Reply-To: <52EE622C.9010004@freebsd.org> References: <726dc97ccd1f44b3ba9d7bee3eeff08a@e15be-01.zdv.Uni-Mainz.DE> <52EE622C.9010004@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 2, 2014, at 8:20 AM, Nathan Whitehorn wrote:
> On 02/02/14 05:55, Wei=DF, J=FCrgen wrote:
>>=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
> 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.
I suspect that it is going to be a cooperation between the bus and the =
driver. Eg, we want them probed, and their resources allocated, but we =
otherwise don't want the driver to interact with the hardware. So a =
serial driver wouldn't create /dev/ttyUx nodes, a network driver =
wouldn't try to attach an if_net, etc. Also, we need an interface, =
eventually, that will allow us to turn them back on, but that can be =
problematic since one of the resources the drivers use is hardware pins, =
which are multiplexed with other drivers...
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D8EF87BF-F09B-4FA0-8460-2249D21CA430>