Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Clause 33 comments




It seems to me that the only way to stay sane will be to
have an address register for each device. You only perform
the post increment in the device which is addressed.  The
other devices on the MDIO bus don't increment their address.
In fact, they must fully decode the start, opcode, and address
fields in order to qualify the transaction.

I agree that this should be carefully documented.  People have
made all kinds of wild assumptions about the way MDIO/MDC work
in the past.  Some people actually believe that PHYADD <00000>
is a broadcast address.

Howard Frazier
DomiNet Systems

pat_thaler@xxxxxxxxxxx wrote:
> 
> Ed,
> 
> In discussing clause 33 implementation with a colleague, we realized another
> item
> that needs to be clarified in connection with the stored address and
> components that
> implement multiple devices sharing one MDIO interface.
> 
> If each device (using device in the sense of "device address" from clause
> 33) had
> its own MDIO interface, each would have the register address stored
> so that multiple reads, writes, and write-increments would operate using the
> 
> stored address even if there were intervening operations executed to other
> devices.
> 
> If devices share an MDIO interface, are they to have a register address
> stored
> per device or can they have just one register address register shared
> between
> all? If the latter is allowed then the manager will need to write an address
> any time it changes devices.
> 
> If there is only one address register per MDIO interface, what happens if
> an MDIO interface with multiple devices gets accessed for different devices
> without an intervening address operation? Should it remember that the
> address
> was for a different device and not execute the read or write or does it
> just use the stored address anyway?
> 
> If we don't pin some of these details down, people may get clever and use
> undocumented features causing later interoperability problems.
> 
> Pat