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. >> 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? thanks -- PMM
