Le 19/05/2016 20:37, Peter Maydell a écrit :
On 19 May 2016 at 19:14, Jean-Christophe DUBOIS <j...@tribudubois.net> wrote:
Le 19/05/2016 05:48, Jason Wang a écrit :
On 2016年05月19日 06:23, Jean-Christophe Dubois wrote:
It's ok to decide with "is-fec", but is it better to use a new type for
that?
Well, there is a lot of common code between FEC and ENET because ENET is
basically backward compatible with FEC. So most/all of the FEC code needs to
go in the ENET device.
I thought this way of doing thing was the best way to avoid duplicating
things.
Right, but usually we have different device types, even if under
the hood it's the same code using a bool to decide what to do
(see for instance hw/display/pl110.c, which provides 3 devices
which are all pretty similar). This means that the users of your
device don't need to care that the FEC is an ENET device with
a flag to say "be like an FEC device", they just instantiate
the kind of device they want.
OK, I'll do that.
The above renaming seems cause lots of unnecessary changes above which may
brings issue when backporint patches to -stable. Can we just keep this, and
all ENET_*** should be used after we're sure we are ENET?
What do you mean by "after we're sure we are ENET"?
ENET is the evolution of FEC to support Gb interface. FEC is more like a
legacy device these days (for ARM9 family). So it seems we are better
supporting ENET as default going forward.
I don't mind if we rename the functions, #defines, etc, but if
we do can we have a patch which does that renaming and only that
renaming, so it's easy to review?
OK, I'll add a patch for renaming.
thanks
-- PMM
