On Sun, Apr 25, 2021 at 01:59:19PM +0200, Ansuel Smith wrote: > On Sun, Apr 25, 2021 at 12:45:54PM +0800, DENG Qingfang wrote: > > Hi Ansuel, > > > > On Sat, Apr 24, 2021 at 11:18:20PM +0200, Ansuel Smith wrote: > > > > > > I'm starting to do some work with this and a problem arised. Since these > > > value are based on the switch revision, how can I access these kind of > > > data from the phy driver? It's allowed to declare a phy driver in the > > > dsa directory? (The idea would be to create a qca8k dir with the dsa > > > driver and the dedicated internal phy driver.) This would facilitate the > > > use of normal qca8k_read/write (to access the switch revision from the > > > phy driver) using common function? > > > > In case of different switch revision, the PHY ID should also be different. > > I think you can reuse the current at803x.c PHY driver, as they seem to > > share similar registers. > > > > Is this really necessary? Every PHY has the same ID linked to the switch > id but the revision can change across the same switch id. Isn't the phy > dev flag enought to differiante one id from another? Just as general background information: A PHY ID generally consists of three parts. 1) OUI - Identifies the manufacture - 22 bits 2) device - Generally 6 bits 3) revision - Generally 4 bits The 22 bits of OUI is standardized. But the last 10 bits the vendor can use as they wish. But generally, this is how it is used. Loading the PHY driver is generally based on matching the OUI and device ID. The revision is ignored. But it is available to the driver if needed. It could be, the switch revision is also reflected in the PHY revision. Andrew