For example, we had MDIO drivers using mdio_phy_id_is_c45() to test whether the access being requested was C45 - mdio_phy_id_is_c45() is for the _userspace_ MII API encoding (struct mii_ioctl_data), not the kernel space. Kernel space used: -#define MII_ADDR_C45 (1<<30) -#define MII_DEVADDR_C45_SHIFT 16 -#define MII_REGADDR_C45_MASK GENMASK(15, 0) to encode into the register number argument vs the userspace encoding into the phy_id member of struct mii_ioctl_data: #define MDIO_PHY_ID_C45 0x8000 #define MDIO_PHY_ID_PRTAD 0x03e0 #define MDIO_PHY_ID_DEVAD 0x001f which is what the mdio_phy_id_*() accessors are using. The two approaches are incompatible, and using the userspace one in a MDIO driver wasn't going to work correctly - but people did it. This is one of the reasons I hated the old MDIO API, and why we now have separate C22 and C45 interfaces in the driver code. This is exactly why I don't like reintroducing a new set of "massage the package, mmd and address into some single integer representation" and "decode a single integer into their respective parts" - we've been here before, it's lead to problems because driver authors can't grasp what the right approach is, and it results in bugs. Given the history here, my personal opinion would be... if regmap can't cope with MDIO devices having a three-part address without requiring callers to flatten it first, and then have various regmap drivers unflatten it, then regmap is unsuitable to be used with MDIO and ought not be used. So, this encoding/decoding is a problem that should be solved entirely within regmap, and not spread out into users of regmap and drivers behind regmap. Anything else is, IMHO, insane. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
