lkml.org 
[lkml]   [2015]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] ethtool: changes of emac_regs structure accordingly within driver emac_regs structure.
On Mon, 1 June 2015 12:57 +0400
Ben Hutchings <ben@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 <ivan@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!



\
 
 \ /
  Last update: 2015-06-01 16:01    [W:0.094 / U:0.492 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site