ikAG1WXVF39j5Zr5Mxc3CeCO+wduh3dwdbP3F86taHah4w0mR7xHNt0i7w IU3QMn+TgPepKEmTLXHgPQEqXhJYgfM1/3e4hpwcvgLMj2csMscbPIfMESU4LNGtnmT3fB zgLhk/XK0plPkUAJzxJNEUTE5EjpiN1vQHFHN69dyQsYUnfcoJ8bDBzhWIbiIU5ykyj9J3 peUncesTuXvq+uz6tbNBn39q3cbwPjBF06HiudcOio3gEOgyr8KArFEEG3St6Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [IPV6:2601:5c0:4202:5670:44e0:6039:a461:36a5] (unknown [IPv6:2601:5c0:4202:5670:44e0:6039:a461:36a5]) (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 4dQww96XB0zs9g; Wed, 10 Dec 2025 00:05:29 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <8b52aeca-46cd-49b3-9a11-7c487fe62cb8@FreeBSD.org> Date: Tue, 9 Dec 2025 19:05:29 -0500 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: 575639548cef - main - bus_alloc_resource: Pass rid by value to BUS_ALLOC_RESOURCE DEVMETHOD Content-Language: en-US To: "Bjoern A. Zeeb" Cc: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org References: <693882af.2fecd.1848e0d9@gitrepo.freebsd.org> <2f83e5f9-74f0-4cc5-aebd-a89be8ed4464@FreeBSD.org> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12/9/25 17:45, Bjoern A. Zeeb wrote: > On Tue, 9 Dec 2025, John Baldwin wrote: > > Hi, > > upfront: while talking about this very specific change as well, I really just > want to point out the general problem. > >> On 12/9/25 15:12, John Baldwin wrote: >>> The branch main has been updated by jhb: >>> >>> URL: >>> https://cgit.FreeBSD.org/src/commit/?id=575639548cef58590a1d70c29e47aae0e8d44153 >>> >>> commit 575639548cef58590a1d70c29e47aae0e8d44153 >>> Author: John Baldwin >>> AuthorDate: 2025-12-09 19:59:21 +0000 >>> Commit: John Baldwin >>> CommitDate: 2025-12-09 20:00:06 +0000 >>> >>> bus_alloc_resource: Pass rid by value to BUS_ALLOC_RESOURCE DEVMETHOD >>> The wrapper functions such as bus_alloc_resource_any() still >>> support >>> passing the rid by value or pointer, but the underlying implementation >>> now passes by value. >>> Reviewed by: imp >>> Differential Revision: https://reviews.freebsd.org/D53402 >> >> FYI, this breaks the build of drm-kmod (hence the __FreeBSD_version bump). >> I will open a PR against drm-kmod shortly, but it will still take some time >> for the patch to make its way into ports. There's not really a great way >> to stage changes that depend on __FreeBSD_version bumps. :( > > Yes, it is a pain. > > The version check needs to go in for multiple different branches but likely also > needs to be applied to ports via patch file as at least one is based on a tag and > not on a branch currently for as much as I remember. Just saying as I ran into > all the tiny details with my previous PCI cleanup there, which cost me a delay of > more than 2 months to get things in (and then still broke nvidia graphics and > networking). Even if not a graphics person, I'll be happy to review this. > > > That said, I believe, what I had said before, the proper solution [for this > specific case] would have been to implement pci_bus_alloc_resource() in LinuxKPI > and get rid of the FreeBSD specific native code. Eh, even the Linux code is special in this case as it is allocating a non-standard BAR. We do support non-standard BARs (and don't require manually dinking with the register the way Linux does), and I have a patch to vga_pci to permit allocating those, but that needs a larger patch and more testing by someone with old enough hardware to test this case, and in general none of the drm-kmod folks ever replied on any of those reviews despite multiple pings, so I just went with the simpler approach. -- John Baldwin