
On 18/08/11 15:03, Andreas Bießmann wrote:
Dear Dave Aldrige,
Am 18.08.2011 15:32, schrieb Dave Aldridge:
The Cadence GEM is based on the MACB Ethernet controller but has a few small changes with regards to register and bitfield placement. This patch detects the presence of a GEM by reading the module ID register and setting a flag appropriately.
This handles the new HW address, USRIO and hash register base register locations in GEM.
Signed-off-by: Dave Aldridge fovsoft@gmail.com
drivers/net/macb.c | 18 +++++++++++----- drivers/net/macb.h | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 67 insertions(+), 6 deletions(-)
diff --git a/drivers/net/macb.c b/drivers/net/macb.c index c63eea9..d52dda0 100644 --- a/drivers/net/macb.c +++ b/drivers/net/macb.c @@ -88,6 +88,7 @@ struct macb_dma_desc {
struct macb_device { void *regs;
int is_gem;
is it required to have a runtime distinction here? I mean is it possible to have a Cadence GEM type and a old style MACB type of HW on the same device? If not I would prefer a compile time differentiation here to avoid the macb_or_gem_(read|write) macros (but lets wait for some comments from the custodians)
regards
Andreas Bießmann
You would either have a macb or a gem implementation (don't think it makes sense to have both types of mac in the same SoC). However at the programmers model level the differences between the two are actually quite small that is the reason for sorting out the differences at run time rather than compile time.
Thanks for adding to the cc list. I did do a trawl before submitting this patch set but was unsure who the most appropriate people were.
Cheers
Dave