RE: [PATCH v8 net-next 4/5] net: ena: PHC stats through sysfs

["Arinzon, David" <darinzon@amazon.com>]

> > > > > > I've not been following previous versions of this patch, so i could 
> > > > > > be repeating questions already asked....
> > > > > >
> > > > > > ena_adapter represents a netdev?
> > > > > >

Yes, ena_adapter represents a netdev.

> > > > > > /* adapter specific private data structure */ struct ena_adapter {
> > > > > >     struct ena_com_dev *ena_dev;
> > > > > >     /* OS defined structs */
> > > > > >     struct net_device *netdev;
> > > > > >
> > > > > > So why are you not using the usual statistics interface for a netdev?
> > > > >
> > > > > I asked them to do this.
> > > > > They are using a PTP device as a pure clock. The netdev doesn't
> > > > > support any HW timestamping, so none of the stats are related to packets.
> > > >
> > > > So how intertwined is the PHC with the network device? Can it be
> > > > separated into a different driver? Moved into drivers/ptp?
> > > >

The PHC device is not a HW timestamping device but rather a PTP clock
that is integrated with the networking device under the same PCI device.
Enabling or disabling the ENA PHC requires reconfiguring the ENA network device.

> > > > We have already been asked if this means network drivers can be
> > > > configured via sysfs. Clearly we don't want that, so we want to
> > > > get this code out of drivers/net if possible.
> > >
> > > Is it good enough to move the relevant code to a ptp/ or phc/ dir
> > > under ...thernet/amazon/ena/ ? Moving it to ptp/ proper would
> > > require some weird abstractions, not sure if it's warranted?

We agree that relocating the PHC code to drivers/ptp would introduce unnecessary
abstractions and require synchronization mechanisms between drivers.

As with other ENA features, the PHC-related code is contained within
a dedicated file in the ethernet/amazon/ena/ directory.
Would this be an acceptable approach?

Thanks,
David

> > mtd devices have been doing this for decades. And the auxiliary bus
> > seems to be a reinvention of the mtd concepts.
> 
> No, it is not. MTD concepts are no different from standard
> register_to_other_subsystem practice, where driver stays in one subsystem
> to be used by another.
> 
> Auxillary bus is different in that it splits drivers to their logical parts and places
> them in right subsystems.
> 
> Thanks