qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH V2 2/6] hw/mdio: Generalize etraxfs MDIO bitbang


From: Grant Likely
Subject: Re: [Qemu-devel] [PATCH V2 2/6] hw/mdio: Generalize etraxfs MDIO bitbanging emulation
Date: Thu, 24 Jan 2013 10:32:12 +0000

On Wed, 23 Jan 2013 23:45:13 +0000, Paul Brook <address@hidden> wrote:
> > +#ifdef USE_THIS_DEAD_CODE
> > +void mdio_detach(struct qemu_mdio *bus, struct qemu_phy *phy, unsigned int
> > addr) +{
> > +    bus->devs[addr & 0x1f] = NULL;
> > +}
> > +#endif
> 
> This is clearly wrong.

It's in both versions of the original code. I didn't add this. I
included it when moving a code block because it appears to be there as a
point of completeness if it ever should be needed.

Edgar, do you want to keep this block around?

> It also worries me that there isn't a clean separation between the MDIO bus 
> and the bitbang interface.  IMO the bitbang interface should be a separate 
> device, and if we're wiring up bitbang interfaces then it really should be 
> via 
> standard GPIO pins (aka qemu_irq). 

Only the bitbang state machine is in the mdio layer. It says nothing
about where those signals come from, gpio or otherwise. Not all cases
will actually be GPIOs. For instance, the smc91c111 has dedicated pins
for MDIO operations which are not GPIOs, even though the driver has to
manage the bigbanging.

That said, I'm not opposed to changing the model if that is the design
direction. However, I hope that the series won't be blocked on this
point. This series moves and enhances existing code. A move to qemu_irq
should be done as a follow-on patch.

g.



reply via email to

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