From owner-freebsd-arm@FreeBSD.ORG Sun Feb 2 17:13:32 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2BDB9F17 for ; Sun, 2 Feb 2014 17:13:32 +0000 (UTC) Received: from smtpauth2.wiscmail.wisc.edu (wmauth2.doit.wisc.edu [144.92.197.222]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EC6451D3F for ; Sun, 2 Feb 2014 17:13:31 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0N0D00B00M8GPI00@smtpauth2.wiscmail.wisc.edu> for freebsd-arm@FreeBSD.org; Sun, 02 Feb 2014 10:13:23 -0600 (CST) X-Spam-PmxInfo: Server=avs-2, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.2.160615, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from comporellon.tachypleus.net (adsl-76-208-68-77.dsl.mdsnwi.sbcglobal.net [76.208.68.77]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0N0D00A5OME9PC20@smtpauth2.wiscmail.wisc.edu>; Sun, 02 Feb 2014 10:13:22 -0600 (CST) Message-id: <52EE6EA1.90707@freebsd.org> Date: Sun, 02 Feb 2014 10:13:21 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: =?ISO-8859-1?Q?=22Wei=DF=2C_J=FCrgen=22?= , "'freebsd-arm@freebsd.org'" Subject: Re: status = "disabled" References: <726dc97ccd1f44b3ba9d7bee3eeff08a@e15be-01.zdv.Uni-Mainz.DE> <52EE622C.9010004@freebsd.org> <06235e983f8142fcb7f6f6c329a84b90@e15be-01.zdv.Uni-Mainz.DE> In-reply-to: <06235e983f8142fcb7f6f6c329a84b90@e15be-01.zdv.Uni-Mainz.DE> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 17:13:32 -0000 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