From nobody Sun Jun 02 21:37:18 2024 X-Original-To: dev-commits-src-all@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 4VsqvM36kBz5LHKB for ; Sun, 02 Jun 2024 21:37:19 +0000 (UTC) (envelope-from 0100018fdae2a7e7-470d6248-71a4-4116-817f-056f2194046d-000000@amazonses.com) Received: from a8-13.smtp-out.amazonses.com (a8-13.smtp-out.amazonses.com [54.240.8.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4VsqvM1BrPz4vVr for ; Sun, 2 Jun 2024 21:37:19 +0000 (UTC) (envelope-from 0100018fdae2a7e7-470d6248-71a4-4116-817f-056f2194046d-000000@amazonses.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=dqtolf56kk3wpt62c3jnwboqvr7iedax; d=tarsnap.com; t=1717364238; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=To3Iie604R9NsQ88VjkQ9/7VdErqT1vCkSAJNuvrkhU=; b=cV+TtJuRu1xWVh1RCW1R/EOIpWtr+if+T+HxqPePCgTPbEcFAt1t9HiKvssNU9jY 1WP9mm+//VFegzNoXBQVivlHFXxIzrHsVWcqUd7go50NVLMfcxBzX1ju4FKwVD6c4Dh Ic8RYx7H0tREq0I5dgbBcrUjQ/Jf3oOZtpRe9Bus= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1717364238; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=To3Iie604R9NsQ88VjkQ9/7VdErqT1vCkSAJNuvrkhU=; b=hlXcVeFByKsJizf3SINONBncFoUQe3CX9WcsnvdZLe2EYAlA2+hFogGrc/wA+20s zqbBsDgEFNtFZNAsDxSk0vfo8QQMuocpkPI0/QAGH/o9GIGkZwqgTQcEhZCJ2PlsKrc r2DoQYE1i2dnUBqVBJpCuTF7ja8ibuURh0M2CXOc= Message-ID: <0100018fdae2a7e7-470d6248-71a4-4116-817f-056f2194046d-000000@email.amazonses.com> Date: Sun, 2 Jun 2024 21:37:18 +0000 List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: git: 28aaa58fa64e - main - fu740_pci_dw: Fix PERST delay and keep asserted for rest of reset sequence To: Jessica Clarke Cc: "src-committers@freebsd.org" , "dev-commits-src-all@freebsd.org" , "dev-commits-src-main@freebsd.org" References: <202406022043.452Khmjb050139@gitrepo.freebsd.org> <0100018fdac22280-97d0bb7c-c35e-4017-aeb8-9c9f2413094c-000000@email.amazonses.com> <6489FC3C-5B0E-4B07-A6EF-92EA3B353423@freebsd.org> Content-Language: en-US From: Colin Percival Autocrypt: addr=cperciva@tarsnap.com; keydata= xsFNBGWMSrYBEACdWRqDn3B3SKO7IG0/fGHYtfs26f3Q5QeAcasy1fQLniwGQWn5rlILhbCD K/jdNoDm5Zxq20eqyffoDNObCjnHgg4tGANdi+RmDy+7CDpE789H8dss9y7Pt5DlGGAXQQnt hxush3EYS/Ctprd9UUL/lzOOLOU1aNtzB84tNrJBtcJmL7OYHfyTSNFxvedqJrrasejIQOLI t/DQ89BPzz+vsKHz7FJPXh3fsVkzLA00DJYcfkgxyABfJNA7U6yMwd4DVSdx/SsvfIDMVXnu UXCXswo106WPZbYGlZPpq0wW6iibtTerJix+8AeuwXvl9O1p8yESK4ErkIxCnmghTSz+pdzj z/6xBRkdDM9VdZ0r+CzsaNXMpDOzFuKyjaiYBdgCLljbDnXIHFcqXenrZ7Xwkm09g/M4uVSh pIUG2RYa6tsHSQoGCp3f2RZv1znfViKQFbbL83QjtPA20AhseZSYbHp1FPhXyy9J0wkGL16L e99g6gdGeIRE82BZjBjKGDkoyDPq+oDRSFl8NtzmIKy+cfz00nViqcTF4bREXEawFGhlpO0X O9q8mijI9iFB6zaPBiSdJGBL5ML5qLTNCl8Zlf4m1TBvmRTqF/lzMHVXHidDoUhpSh/y3AFZ 1KrYc27ztJQywDJPJPWPbtY8YhFLFs377gfP8WldsZjzp8nvoQARAQABzSVDb2xpbiBQZXJj aXZhbCA8Y3BlcmNpdmFAdGFyc25hcC5jb20+wsGRBBMBCAA7FiEEglY7hNBiDtwN+4ZBOJfy 4i5lrT8FAmWMSyYCGwMICwkNCAwHCwMFFQoJCAsFFgMCAQACHgUCF4AACgkQOJfy4i5lrT+i Yg/+PYyJNoFuygtV5t/skcjYmvEC93mnazEvh+x99vGYZnGKeJ8NDOF4QCUzeHquOWxDi8Zl reXyswKcrIquPxxX6+YyGe97VbvLnez3ksfzOYRj1F4qV0Rq8ZNK51+bvIrbcS3SfDaRioAk D7WWwFor8y/hSwxYkfsKbtP5PRcem20JUxuC085zqWLaKv5t5n2CBzAGMjwJaQ3tM3AXVwWJ uJaHA6ot/6fntJlmkfcyCYyyr0D6b0guRj3STbZ2hNn5o2AI+f6LJJ31s2sPFjl6rs7fORf3 hFSNOHDd2HxfVBXFdQy24ROkC4orBBz2xh9GScjxxT/hbXkfufkubFubw7n0HkvHzA3UF+Qq A8JiI3n+d7ocsP0/5BQ2sZdeqPGJgHx6RkAMuW1tJ29wSvCN1qMgFwhYkpQdfvHlociQrimU fvlRfSrBEe8o7tvIuEdpvwvCZSTJqQbVoMw8UHFE7nzyCXUSab5h6PbjakCqim13ekVO2KFF TTPcz5o5jEeUY75tzbIwcDfFbT5KqNjWy06TVdM9VEJDHSfOfxHR3kSEwZ+tT2aTvL3grsUn gFwSNcj4Cl4CRFfUw8zVZY+7O7RiMlhBqykikvUurrdGKc1Scwa0yuppdA6eVvylyTWSQGrQ +uLWtV1LUKN7ZqKJWBkLPt9nS4XZWGyBvxOHYqjOwU0EZYxKtgEQANYfgbtUMVnhjxDHhWLp g5kLHK3YW0TfJKzpXqDB7NiqxHofn4OcbZnVC3MKggcbs9o1/UtsjnlsG8550PfiYkDXvPiO RJwgbGs6MGIDK797C6cnBLQ8xwBa9SL4cl5iQFnhWmt6vwnJ+an/cm5JpYves3wL7jV09qU9 57hkHXEUcl38r4FssZzVcLKPUVTa3Un+QGRTGDGe/f4ctjMaqv0ZCM+l2ixPhf/vqESrfSLv V/+T3dmtUfXjazO3SABvsHwxgGuTTYOlKoPCaebr+BRdqm0xeIShoIlhvTI8y4clchqx/Uxg UG5X2kvU13k3DS3Q8uLE4Et9x1CcZT6WGgBZSR6R0WfD0SDnzufNnRWJ0dEPA2MtJHE7+85R Vi9j/IgZV+y5Ur+bnPkjDG1s2SVciX5v9HQ0oilcBhvx0j5lGE9hhurD9F+fCvkr4KdbCknE 6Y8ce8pCNBUoB/DqibJivOzTk9K9MGB5x0De5TerIrFiaw3/mQC9nGeO9dtE7wvDJetWeoTq 4BEaCzpufNqbkpOaTQILr4V6Gp7M6v97g83TVAwZntz/q8ptwuKQPZ2JaSFLZn7oWUpYXA5s +SIODFHLn6iMoYpBQskHQjnj4lEPJadl4qj+ZKA89iDAKsniyoFXsbJe2CPbMS1yzBxKZq6K D/jpt7BOnuHr/JrXABEBAAHCwXYEGAEIACAWIQSCVjuE0GIO3A37hkE4l/LiLmWtPwUCZYxK tgIbDAAKCRA4l/LiLmWtP3jmEACQrh9gWe8F1Tkw3m6VoHKwLc5he4tX3WpQa//soPO6iGG3 S3WPruQ46NrAaAojoOcKI9UONDO5rxG0ZTX53S+lu2EO47jbcLwOCjaEpjKpDRt9ZXBQE8Xl mtBE9Bp3W9gpjB1nE3KNM1mJYgsK0QdRpwwfh4pVgGpOj8j23I6MCK+v99zEBnpgCn2GX8W/ kctRXHqWwndHysOJtRP/zrl7dDaABF1f9efUl0LL3TD3GJ9VDz+DNOin/uK2a1hiJo8QzTRk PpfUQ2ebzDsrd1i/pOWkMSkdH+rEu4AGrXWtaBwrMyrGkL6Icb6yO+P9/z0W2wlgBf3P1YRt JPgQt/Dj3yvA/UnaV/QmuVQPjl13o24UnJGsZM8XGnNdfWBKkC1Q6VXC4QT+dyBHYH9MuE9d 6oGl8pFM1+cTfEfbM62/rRoPkF1yHMsI/903VxEvuUIKfhEZAVLFyHldooNxuchntHQP9y8J 8Ou9bWYQP7MnEn+kwSwrZkjurfPkan+xQvp6dDYnj3V0GwA5pprBMaB928VIDVOv+1PNQI3t Cvk5VPv/skq+TJRMHW7bFSt8PRa91cUf1FOLIz9APDiJOzXkwxUEHGV3zPSaUhs1JYjyBeGT wDAvtLUdjOnRhEUOwlnIrztmvyciutjJoVzKEEjj5WXnHk9L9kQ1bpAjkjTONw== In-Reply-To: <6489FC3C-5B0E-4B07-A6EF-92EA3B353423@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Feedback-ID: ::1.us-east-1.Lv9FVjaNvvR5llaqfLoOVbo2VxOELl7cjN0AOyXnPlk=:AmazonSES X-SES-Outgoing: 2024.06.02-54.240.8.13 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:14618, ipnet:54.240.8.0/21, country:US] X-Rspamd-Queue-Id: 4VsqvM1BrPz4vVr On 6/2/24 14:15, Jessica Clarke wrote: > On 2 Jun 2024, at 22:01, Colin Percival wrote: >> On 6/2/24 13:43, Jessica Clarke wrote: >>> fu740_pci_dw: Fix PERST delay and keep asserted for rest of reset sequence >>> DELAY takes microseconds not milliseconds, so 100 was too low. Moreover, >>> when enabling hw.pci.clear_pcib, PCI emeration would still stop at one >>> of the first bridges, but by asserting PERST for the rest of the reset >>> sequence that appears to be reliably addressed. >> >> Does this need to be a DELAY as opposed to something asynchronous? We try to >> avoid lengthy DELAYs in the boot process. > > It’s in the middle of device_attach, so you’d need to break it up into > two stages. I don’t know if we have a good way of doing that for > delays; I’ve seen other glue code drivers do things like this, but > there may well be a better way, and if so I’m all ears. I don't think there's any good mechanism for doing that, unfortunately. Part of the problem is that our device probing scheme is designed around the idea that by the time you return from device_attach, you know if the device has successfully attached; if you discover that the device is broken at a later time it's too late to assign the unit number to a different device. I remember talking to Warner about this a while back in the context of nvme, but the problem of "the spec says we have to wait a long time and we don't want to do that serially for every disk" was resolved by our driver learning to be opportunistic and ask the disks if they were ready yet instead of simply waiting the time stipulated by the spec. Maybe something to consider when someone decides to write newnewbus. ;-) > Though given > you won’t have working PCI (so no USB nor NVMe) until this is done > there’s probably not much more you can do during boot whilst you wait, > so it may not be worth pursuing. Also, given the performance of the SoC > in question, 100ms isn’t something you’d be close to noticing... Fair enough, I wasn't sure what sort of hardware this was. Sounds like we're fine here; it just caught my eye so I thought I'd ask. -- Colin Percival FreeBSD Release Engineering Lead & EC2 platform maintainer Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid