2012/7/10 Hauke Mehrtens <hauke@xxxxxxxxxx>: > On 07/08/2012 02:51 PM, Rafał Miłecki wrote: >> GMAC COMMON core is present on BCM4706 and is used for example to access >> board PHYs (PHYs can not be accessed directly using GBIT MAC core). > > I think this is the cleanest way of doing this. I thought about handling > this in the Ethernet driver, but as we need locking, an extra driver > would be needed, just for this stupid locking. Yeah... I really wonder why Broadcom didn't just connect GMAC core with the proper PHY. At the beginning I implemented chipphyrd in driver_gmac_cmn.c and cared for the mutex internally. It would be much cleaner and easier for GMAC driver to just use such a complete function and don't care for mutex. Then I started writing chipphywr and... I noticed that after writing to BCMA_GMAC_CMN_PHY_ACCESS in GMAC CMN, this chipphywr have to touch intstatus register in GMAC core. Just before accessing BCMA_GMAC_CMN_PHY_CTL. So I decided to keep PHY ops in GMAC core driver. We need to take care of this mutex, but we don't need to handle callbacks (touching intstatus) or passing GMAC core reference to the GMAC CMN (to let it touch intstatus). > You should not register an external device for this core in > bcma_register_cores(). Ouch, thanks! -- Rafał -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
