On Mon, 1 June 2015 12:57 +0400 Ben Hutchings <b...@decadent.org.uk> wrote:
>On Thu, 2015-05-21 at 19:09 +0400, Ivan Mikhaylov wrote: >> In ibm_emac.c in ethtool size of emac structure which passing through >> to driver is nailed down and not correlating with current emac_regs >> structure. >> >> Signed-off-by: Ivan Mikhaylov <i...@ru.ibm.com> >[...] > >This is not backward-compatible. It ought to be possible to mix and >match old and new ethtool and driver, except for the EMAC4SYNC case >which has been broken up until now. > >Using the new definition of struct emac_regs, I think the driver and >ethtool need to agree that the MAC register dump sizes are: > >EMAC: offsetof(struct emac_regs, u1) >EMAC4: offsetof(struct emac_regs, u1.emac4) + sizeof(p->u1.emac4) >EMAC4SYNC: offsetof(struct emac_regs, u1.emac4sync) + >sizeof(p->u1.emac4sync) > >Ben. > >-- >Ben Hutchings >Reality is just a crutch for people who can't handle science fiction. Actually it is backward-compatible because we don't care about size which is coming from driver side, only what we doing is map of driver structure to ethtool structure and results will be same for emac and emac4. struct emac_regs *p = (struct emac_regs *)(hdr + 1); Also size which you mentioned (112 emac, 116 emac4) can be different from what you saying cause this managed by dts files where we can set something like 0x100 or 0x80 for this memory area and we will still have problem in representing MII area if this size wasn't set right in dts. Ethtool will be work in same way even if we have emac or emac4. Thank you for respond! -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
