On Fri, Jun 06, 2025 at 03:58:11PM +0100, Igor Korotin wrote: > On Fri, Jun 6, 2025 at 3:32 PM Danilo Krummrich <dakr@xxxxxxxxxx> wrote: > > > > On Fri, Jun 06, 2025 at 03:26:13PM +0100, Igor Korotin wrote: > > > On Fri, Jun 6, 2025 at 2:50 PM Danilo Krummrich <dakr@xxxxxxxxxx> wrote: > > > > However, I don't understand why we need this and the subsequent > > > > is_acpi_device_node() and is_of_node() checks. > > > > > > The idea is to avoid unnecessary table lookups when both OF and ACPI > > > match tables are present. > > > > Ok, that's fair -- let's build it on top of the FwNode abstractions though. > > I'm ok with the FwNode abstractions. Just to make sure I understood > you correctly: > I'll need to wait until these FwNode abstractions are pushed to the > rust-next branch, reimplement what is necessary and send v3. Is this > the course of actions? Not all Rust code goes through the Rust-for-Linux tree, it depends on who maintains the code. For the FwNode and device property series I pointed you to, the code is maintained by the driver-core maintainers and hence will go through the driver-core tree [1]. (You can always check the corresponding entries in the MAINTAINERS file, they document, who maintains a file and which tree changes go through. For instance, if you want to know this for a specific file, you can run ./scripts/get_maintainer.pl path/to/file and the script tells you everything you need to know. In general, before submitting patches you should run this script on your patches to find out who you should send them to.) However, there is no need to wait until the FwNode and device property series lands in driver-core-next, you can just fetch the patch series from the mailing list and build your patches on top of that. If you do this, you should make sure to mention the exact series you build on top of in the cover letter, ideally with a lore link to the specific version of the series. [1] https://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core.git/
