On Mon, Oct 08, 2018 at 05:07:22PM +0200, Andrew Lunn wrote: > So as you said, the phylib API has not changed much, which is common > for mature code. I meant that phy-LINK hasn't changed much. > But i think long term, it will become less important. > It will share the space with phylink. And any code which wants to be > generically usable, should not depend on phydev. Thanks for your view of the big picture. > Architecturally, it > seems wrong for you to hang what should be a generic time stamping > framework on phydev. It is not future proof. net_device is future > proof. You still haven't said how net_device is going to work. Today there are exactly zero phylink devices needing time stamping support, but there are new phylib devices. We don't have a net_device->phylink connection, and it isn't needed yet. Adding that is way out of scope for this series. Let's stick to phylib for now. We can cross the other bridge when we come to it. Maybe the net_device->phylink will emerge for purposes other that time stamping. Let's not guess about how it should look. We are only talking about kernel interfaces here, and so nothing is set in stone. Thanks, Richard
