qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/3] net/bitbang_mdio: Generalize etraxfs MDIO b


From: Edgar E. Iglesias
Subject: Re: [Qemu-devel] [PATCH 1/3] net/bitbang_mdio: Generalize etraxfs MDIO bitbanging emulation
Date: Mon, 21 Jan 2013 16:08:02 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Jan 21, 2013 at 09:21:43AM -0400, Grant Likely wrote:
> On Mon, 21 Jan 2013 13:51:02 +0100, "Edgar E. Iglesias" <address@hidden> 
> wrote:
> > On Sat, Jan 19, 2013 at 06:28:10PM -0400, Grant Likely wrote:
> > > The etraxfs Ethernet model implements quite a nice bitbanging core. The
> > > change splits it out into a separate .c file. There are no functional
> > > changes here, just movement of code and reformatting to match qemu
> > > coding standards.
> > 
> > Hi Grant!
> > 
> > It makes sense to move it out.
> > 
> > A few comments:
> > * Maybe we could separate the phy models from the bus model/infrastructure.
> > I.e, the qemu_mdio parts into one file and the qemu_phy into another one.
> > That way we can add other phy models and keep things separated.
> 
> That makes sense too, but it should be done as a follow on patch. That
> keeps the factoring out as a single logical block of code.
> 
> > * Not sure bitbang_ makes sense in the naming, the abstraction supports
> > both the bit twiddeling model with MDIO cycles but also a higher level
> > transactional version (mdio_write_req etc) that bypass the cycle accuracy.
> > The latter is useful for modeling NICs that have MDIO support in hw, e.g
> > like the hw/xilinx_axienet.c while beeing able to reuse the PHY models.
> 
> axienet and etraxfs implementations are subtely different (as you know).
> I originally was going to do both, but I didn't want to mix
> functionality changes in with the factoring out. Doing both at the same
> time would have required (slight) behavour changes in one of the models,
> so instead I decided to do only one to keep it simple with the other
> being a follow-on.
> 
> > I realize I should have done this split when doing the axienet model, 
> > sorry..
> 
> Can you help me out with a patch that migrates axienet to the new common
> code?

Yes, I can do that part once the new common code is in place.

Cheers,
Edgar



reply via email to

[Prev in Thread] Current Thread [Next in Thread]