[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bbd1b455-a228-4523-a18c-58792925dd85@lunn.ch>
Date: Sat, 21 Oct 2023 17:57:54 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Benno Lossin <benno.lossin@...ton.me>
Cc: FUJITA Tomonori <fujita.tomonori@...il.com>, netdev@...r.kernel.org,
rust-for-linux@...r.kernel.org, miguel.ojeda.sandonis@...il.com,
tmgross@...ch.edu, boqun.feng@...il.com, wedsonaf@...il.com,
greg@...ah.com
Subject: Re: [PATCH net-next v5 1/5] rust: core abstractions for network PHY
drivers
> I see, what exactly is the problem with that? In other words:
> why does PHYLIB need `phy_driver` to stay at the same address?
Again, pretty standard kernel behaviour. The core keeps a linked list
of drivers which have been registered with it. So when the driver
loads, it calls phy_driver_register() and the core adds the passed
structure to a linked list of drivers. Sometime later, the bus is
enumerated and devices found. The core will read a couple of registers
which contain the manufactures ID, model and revision. The linked list
of drivers is walked and a match is performed on the IDs. When a match
is found, phydev->drv is set to the driver structure. Calls into the
driver are then performed through this pointer.
A typically C driver has statically initialised driver structures
which are placed in the data section, or better still the rodata
section. They are not going anywhere until the driver is unloaded. So
there is no problem keeping them on a linked list. Dynamically
creating them is unusual. They are just structures of pointers to
functions, everything is known at link time.
Andrew
Powered by blists - more mailing lists