From nobody Tue Oct 15 15:32:40 2024 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4XSdQL0vnbz5Yb9k; Tue, 15 Oct 2024 15:32:42 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XSdQL0L71z4Hpw; Tue, 15 Oct 2024 15:32:42 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1729006362; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dYTQExoz/rC+yLOBtIX5D/ViLVY+CxCc3Gap3TaPPp0=; b=tyRjIp334apVTGEBlGZbOt5+oNN1lmXTbUV+IG8fRXCvIBB37+SRO2xfoi6vOJAs9V1H+/ qwDzx7MNWMMYzHzrI5LccQMHg3D0y13T8H51naalEBc9mVzeVqhxGuLBKSsTJ+PBfAS/m8 /pFprFu+RCpNL/r7oG+qEE6HOZYImR6a3MKGE2JDlqf72z8BO/Po/BiTGMS5+ddkVP9xdd Tjg9bbjx8UEJnQ9bvDd3Q0FyQ029eipEg/YN+auC3G/CenrflOy+rtA6PuFKwNNYSp9wMZ aTVPYc6KaXyPdvVkDFFSHjJ4CtDU+9z5M6dybg1E1OjS08pYtW6vXTxUMqHuwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1729006362; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dYTQExoz/rC+yLOBtIX5D/ViLVY+CxCc3Gap3TaPPp0=; b=SVDKSXNmgFiqXEGcCnr9fBxNuM1mmKN9jp5xJabQBCFChzxKCT3by3YGgzL6taWfL4Vx3E KplN0bWfJQQQfTMT61B+tl291CEhp7hq2ZpJm+NscZ99/esqlnruQIg4oI+b0ba8l4GSPP o2lGhLODclkELPdrEhdTXzHjkxxJ7qgT9juAKd+/s6fWM3GV4b4jVi0Wap0QKham3WMDln wM/56EdMdK5krTFwJb9tIUIJbxg+mg3Do/055BXm0s6/VBVCrYF4b9SXRkofuQl5xsX1e+ 7e/QgQQ7KyUKxz16hH2kawwnZtnEzmPh0gbzTW0gCrBMhjUWzIIPA5hsw1rpTg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1729006362; a=rsa-sha256; cv=none; b=jpz81x+Dht1G4gu0/HOvblD5Af+l6U6qgJmWcj5Nw9vK8+g8IfqOJGwFNWB0AdDROzeMJO heLrQVoeNSA11MsjF08gSd+oKhHMRI4OoBS45gktClT3XxJ1V5EbTX67o9ZGbS/UTjA3q8 Mta2quvKMg2rL4aHNoD6aYwikGt28oq/wQ5sqz3XocQWtAIM9N5PjF/SPI8erS213QjmqY XdPD0VTwsKfP/28nMdTLEr8bMfRZ3nwZgv2zAUt2sR1r+nDgOgd0maqpppGXM1rVYB1isI M2bI0UPi2BgkOUo65KOfJVpFgebsqU0ZDxAPfHbTDQCFMsw6QcscXjcZo7MYqw== Received: from [IPV6:2601:5c0:4200:b830:6065:7bd2:5db8:bc5f] (unknown [IPv6:2601:5c0:4200:b830:6065:7bd2:5db8:bc5f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XSdQK5fftzhLG; Tue, 15 Oct 2024 15:32:41 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Tue, 15 Oct 2024 11:32:40 -0400 List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: git: 76bfa33f2598 - main - uart: Go back to returning '0' when we've probed the device. Content-Language: en-US To: Warner Losh , src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org References: <202410151101.49FB1HA5077421@gitrepo.freebsd.org> From: John Baldwin In-Reply-To: <202410151101.49FB1HA5077421@gitrepo.freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 10/15/24 04:01, Warner Losh wrote: > The branch main has been updated by imp: > > URL: https://cgit.FreeBSD.org/src/commit/?id=76bfa33f259891a8b9108e20141bd18e2c8d312f > > commit 76bfa33f259891a8b9108e20141bd18e2c8d312f > Author: Warner Losh > AuthorDate: 2024-10-15 10:59:29 +0000 > Commit: Warner Losh > CommitDate: 2024-10-15 10:59:29 +0000 > > uart: Go back to returning '0' when we've probed the device. > > Two reasons for this: we know it's a uart after we call probe and it > returns successfully. Second, uart passes data between probe and attach > with softc. As it is now, we call probe twice, once in the bidding > process and once after bidding id done. However, the probe process for > uart isn't completely idempotent (we change state of the uart > sometimes). The second call can result in odd behavior (though so far > only in buggy version of other code I've not committed). The bigger > problem is the softc: newbus creates it, we populate it, then frees it > when we don't return 0 to claim the device. It then calls us again, we > repopulate it, and this time it doesn't free it before calling attach. > Returning 0 avoids both of these issues. The justification for doing it > in the commit that changed it was 'while I'm here', so there doesn't > seem to be a use case for it. Hmm, I think it was changed in this commit which wasn't a "while I'm here": commit b923a71020ae338f723d9aa01b5365c90aae2fec Author: Marcel Moolenaar Date: Fri Oct 28 06:30:39 2005 +0000 In uart_bus_probe() return BUS_PROBE_DEFAULT when the probe is successful. Notes: svn path=/head/; revision=151792 diff --git a/sys/dev/uart/uart_core.c b/sys/dev/uart/uart_core.c index 7b068187e565..b2ff203d0b2a 100644 --- a/sys/dev/uart/uart_core.c +++ b/sys/dev/uart/uart_core.c @@ -282,7 +282,7 @@ uart_bus_probe(device_t dev, int regshft, int rclk, int rid, int chan) error = UART_PROBE(sc); bus_release_resource(dev, sc->sc_rtype, sc->sc_rrid, sc->sc_rres); - return (error); + return ((error) ? error : BUS_PROBE_DEFAULT); } int It really is a bug to be depending on passing softc state from probe to attach and it would be ideal to fix that, but going back to returning 0 is ok for now. Maybe instead of '0' though use BUS_PROBE_SPECIFIC? -- John Baldwin