Build PHY device tables by using module_device_table macro.

The PHY abstractions have been generating their own device tables
manually instead of using the module_device_table macro provided by
the device_id crate. However, the format of device tables occasionally
changes [1] [2], requiring updates to both the device_id crate and the custom
format used by the PHY abstractions, which is cumbersome to maintain.

[1]: https://lore.kernel.org/lkml/20241119235705.1576946-14-masahiroy@kernel.org/
[2]: https://lore.kernel.org/lkml/6e2f70b07a710e761eb68d089d96cee7b27bb2d5.1750511018.git.legion@kernel.org/

Danilo, I incorporated your fixes into the first patch and mentioned
them in the commit message. Let me know if you'd rather take a
different approach.

v4:
- Rebased on driver-core-next
- Improve docs based on Trevor's comments
v3: https://lore.kernel.org/lkml/20250704041003.734033-1-fujita.tomonori@gmail.com/
- Fix Safety comments and typo
v2: https://lore.kernel.org/lkml/20250701141252.600113-1-fujita.tomonori@gmail.com/
- Split off index-related parts of RawDeviceId into RawDeviceIdIndex
v1: https://lore.kernel.org/lkml/20250623060951.118564-1-fujita.tomonori@gmail.com/


FUJITA Tomonori (3):
  rust: device_id: split out index support into a separate trait
  rust: net::phy represent DeviceId as transparent wrapper over
    mdio_device_id
  rust: net::phy Change module_phy_driver macro to use
    module_device_table macro

 rust/kernel/acpi.rs      |  15 ++++--
 rust/kernel/auxiliary.rs |  11 ++--
 rust/kernel/device_id.rs |  91 ++++++++++++++++++++++++---------
 rust/kernel/driver.rs    |   8 ++-
 rust/kernel/net/phy.rs   | 106 +++++++++++++++++++--------------------
 rust/kernel/of.rs        |  15 ++++--
 rust/kernel/pci.rs       |  11 ++--
 7 files changed, 156 insertions(+), 101 deletions(-)


base-commit: 3964d07dd821efe9680e90c51c86661a98e60a0f
-- 
2.43.0

On Fri Jul 11, 2025 at 6:09 AM CEST, FUJITA Tomonori wrote:
> Build PHY device tables by using module_device_table macro.
>
> The PHY abstractions have been generating their own device tables
> manually instead of using the module_device_table macro provided by
> the device_id crate. However, the format of device tables occasionally
> changes [1] [2], requiring updates to both the device_id crate and the custom
> format used by the PHY abstractions, which is cumbersome to maintain.

Applied to driver-core-testing, thanks!

On Fri Jul 11, 2025 at 6:09 AM CEST, FUJITA Tomonori wrote:
> Build PHY device tables by using module_device_table macro.

Rafael, Rob: Unless there are any concerns from your end, I'll pick this up
soon.

On 7/11/25 6:09 AM, FUJITA Tomonori wrote:
> Build PHY device tables by using module_device_table macro.
> 
> The PHY abstractions have been generating their own device tables
> manually instead of using the module_device_table macro provided by
> the device_id crate. However, the format of device tables occasionally
> changes [1] [2], requiring updates to both the device_id crate and the custom
> format used by the PHY abstractions, which is cumbersome to maintain.
> 
> [1]: https://lore.kernel.org/lkml/20241119235705.1576946-14-masahiroy@kernel.org/
> [2]: https://lore.kernel.org/lkml/6e2f70b07a710e761eb68d089d96cee7b27bb2d5.1750511018.git.legion@kernel.org/
> 
> Danilo, I incorporated your fixes into the first patch and mentioned
> them in the commit message. Let me know if you'd rather take a
> different approach.

Thanks FUJITA -- no need to mention it though. :)

Did you forget to pick up Jakub's ACK or was this intentional?

- Danilo

On Sat, 12 Jul 2025 00:19:54 +0200
Danilo Krummrich <dakr@kernel.org> wrote:

> On 7/11/25 6:09 AM, FUJITA Tomonori wrote:
>> Build PHY device tables by using module_device_table macro.
>> The PHY abstractions have been generating their own device tables
>> manually instead of using the module_device_table macro provided by
>> the device_id crate. However, the format of device tables occasionally
>> changes [1] [2], requiring updates to both the device_id crate and the
>> custom
>> format used by the PHY abstractions, which is cumbersome to maintain.
>> [1]:
>> https://lore.kernel.org/lkml/20241119235705.1576946-14-masahiroy@kernel.org/
>> [2]:
>> https://lore.kernel.org/lkml/6e2f70b07a710e761eb68d089d96cee7b27bb2d5.1750511018.git.legion@kernel.org/
>> Danilo, I incorporated your fixes into the first patch and mentioned
>> them in the commit message. Let me know if you'd rather take a
>> different approach.
> 
> Thanks FUJITA -- no need to mention it though. :)
> 
> Did you forget to pick up Jakub's ACK or was this intentional?

Oops, please add his ACK when applying.


Thanks,