From owner-svn-src-all@freebsd.org Mon Jan 22 21:42:18 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A9293ED7247; Mon, 22 Jan 2018 21:42:18 +0000 (UTC) (envelope-from rpokala@mac.com) Received: from mr11p00im-asmtp004.me.com (mr11p00im-asmtp004.me.com [17.110.69.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8A3DE705C9; Mon, 22 Jan 2018 21:42:18 +0000 (UTC) (envelope-from rpokala@mac.com) Received: from process-dkim-sign-daemon.mr11p00im-asmtp004.me.com by mr11p00im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0P2Z00E0054YS900@mr11p00im-asmtp004.me.com>; Mon, 22 Jan 2018 20:41:08 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mac.com; s=04042017; t=1516653668; bh=rBwwA5TBBXISAwewmlXX3GiRK1RiOL2EA9yvMBBX2nk=; h=Date:Subject:From:To:Message-id:MIME-version:Content-type; b=sWPxIOCNjANpVKw0sj56F8tcpUcQvcA1ACb69tnyGa7OoXNZQSZr8PwrT/U2xI5xX YNUcPxXAbmuo8FxSw3cAX+/NBcYmjhS03pS1hJ3Oufst/F+qj4b11SlxcSFKmNWb65 vqUiG5YKWF5MdqAHESBoZp8AxEQHAh+KXsQ4vam06t+dDhAHxqgq6dSk0u7RpDgXA8 w0idghfvH89Mo76cC6/ZXN9FQSL/lO/nTN9sJhG8SS/e67tDJFU02NndUhqVP/GUsz Wz2BjUUDZZ+pb/UOW92BE/ICRFi2dhz4da3TUOpkqeWqy5K6jFHtOnVw7mRvDSor+6 h9BLheOgeR9fA== Received: from icloud.com ([127.0.0.1]) by mr11p00im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0P2Z00H6L5GHP110@mr11p00im-asmtp004.me.com>; Mon, 22 Jan 2018 20:41:07 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-01-22_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1801220282 User-Agent: Microsoft-MacOutlook/10.9.0.180116 Date: Mon, 22 Jan 2018 12:41:05 -0800 Subject: Re: svn commit: r328257 - in head/sys: arm/broadcom/bcm2835 dts/arm modules From: Ravi Pokala To: Warner Losh , Poul-Henning Kamp Cc: John Baldwin , Emmanuel Vadot , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Message-id: <607B50C2-883C-4CAB-8860-483EC4E9A668@mac.com> Thread-topic: svn commit: r328257 - in head/sys: arm/broadcom/bcm2835 dts/arm modules References: <201801220710.w0M7AUm9091853@repo.freebsd.org> <88258.1516630050@critter.freebsd.dk> <20180122153003.664e1613bbf70ab49c5c1541@bidouilliste.com> <52374125.OgxafgljNu@ralph.baldwin.cx> <89102.1516649067@critter.freebsd.dk> In-reply-to: MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: quoted-printable X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 21:42:18 -0000 >> I wonder if it would be too noisy if we allowed ->probe() to run on disa= bled devices and reported something like: >>=20 >> "foobar0: Matched disabled device <...>" >>=20 >> (without calling ->attach()) >>=20 >> That way you would know you loaded the right driver, rather than have to= guess >=20 > I suspect that would be too noisy. It would be better to just run probe, = but then have newbus report it's disabled so we never go onto attach. I think a "Matched disabled device" message under bootverbose would be reas= onable. -Ravi (rpokala@) =EF=BB=BF-----Original Message----- From: on behalf of Warner Losh Date: 2018-01-22, Monday at 11:29 To: Poul-Henning Kamp Cc: John Baldwin , Emmanuel Vadot ,= src-committers , , Subject: Re: svn commit: r328257 - in head/sys: arm/broadcom/bcm2835 dts/ar= m modules On Mon, Jan 22, 2018 at 12:24 PM, Poul-Henning Kamp wr= ote: -------- In message <52374125.OgxafgljNu@ralph.baldwin.cx>, John Baldwin writes: >Create the corresponding device_t but device_disable() it when there >is a disabled property. That also removes a couple of boilerplate lines from all FDT device drivers. That would be useful, but the status bit is so much more than on/off.=20 >A user can then use 'devctl enable ' to enable >it before (or even after) loading a device driver. That would work for me. I wonder if it would be too noisy if we allowed ->probe() to run on disabled devices and reported something like: "foobar0: Matched disabled device <...>" (without calling ->attach()) That way you would know you loaded the right driver, rather than have to guess. I suspect that would be too noisy. It would be better to just run probe, bu= t then have newbus report it's disabled so we never go onto attach. Though, there's more fundamental issues at play since FDT is tricky and a l= ot more interrelated than other enumeration platforms. Warner