On 15. sep. 2017 07:51, Jiri Pirko wrote: > Thu, Sep 14, 2017 at 11:01:32PM CEST, and...@lunn.ch wrote: >>> Can you clarify what type of registers it is you are wanting to read? >>> We already have ethtool which is meant to allow reading the device >>> registers for a given netdev. As long as the port has a netdev >>> associated it then there is no need to be getting into debugfs since >>> we should probably just be using ethtool. >> >> Not all ports of a DSA switch have a netdev. This is by design. The >> presentation we gave to Netdev 2.1 gives some of the background. >> >> Plus a switch has a lot of registers not associated to port. Often a >> switch has more global registers than port registers. >> >>> Also as Jiri pointed out there is already devlink which would probably >>> be a better way to get the associated information for those pieces >>> that don't have a netdev associated with them. >> >> We have looked at the devlink a few times. The current dpipe code is >> not generic enough. It makes assumptions about the architecture of the >> switch, that it is all match/action based. The niche of top of rack >> switches might be like that, but average switches are not. >> >> If dpipe was to support simple generic two dimensional tables, we >> probably would use it. >> >> David suggested making a class device for DSA. It is not ideal, but we >> are probably going to go that way. > > I believe that is also big mistake. > > Could you put together your requirements so we can work it out to extend > devlink to support them? > > Thanks. >
$ ack -i devlink Documentation/ $ ack -i dpipe Documentation/ $ How you expect new mechanisms to be taken into use with zero documentation? To all: Why does reviewers nitpick about undocumented formatting rules, but not ask about documentation? Egil