On 5/18/19 4:14 PM, Andrew Lunn wrote: > On Sat, May 18, 2019 at 01:51:23AM +0200, Marek Vasut wrote: >> Add driver for the NXP TJA1100 and TJA1101 PHYs. These PHYs are special >> BroadRReach 100BaseT1 PHYs used in automotive. > > Hi Marek Hello Andrew, >> + }, { >> + PHY_ID_MATCH_MODEL(PHY_ID_TJA1101), >> + .name = "NXP TJA1101", >> + .features = PHY_BASIC_T1_FEATURES, > > One thing i would like to do before this patch goes in is define > ETHTOOL_LINK_MODE_100baseT1_Full_BIT in ethtool.h, and use it here. > We could not do it earlier because were ran out of bits. But with > PHYLIB now using bitmaps, rather than u32, we can. > > Once net-next reopens i will submit a patch adding it. I can understand blocking patches from being applied if they have review problems or need to be updated on some existing or even posted feature. But blocking a patch because some future yet-to-be-developed patch is a bit odd. Besides, this sounds more like a cleanup which can very well be done later. It will surely be done for the other PHY drivers too. > I also see in the data sheet we should be able to correct detect its > features using register 15. So we should extend > genphy_read_abilities(). Which bits do you refer to ? Anyway, this is something which can be done in a subsequent patch, I don't see a reason for blocking hardware enablement because of this. > That will allow us to avoid changing > PHY_BASIC_T1_FEATURES and possibly breaking backwards compatibility of > other T1 PHY which currently say they are plain 100BaseT. What sort of backward compatibility ? -- Best regards, Marek Vasut