Hello Giuseppe, On Mon, 15 May 2017 16:27:34 +0200, Thomas Petazzoni wrote: > On Wed, 10 May 2017 09:18:17 +0200, Thomas Petazzoni wrote: > > > On Wed, 10 May 2017 09:03:12 +0200, Giuseppe CAVALLARO wrote: > > > > > > Please, read again my patch and the description of the problem that I > > > > have sent. But basically, any solution that does not allow to set the > > > > PS bit between asserting the DMA reset bit and polling for it to clear > > > > will not work for MII PHYs. > > > > > > yes your point was clear to me, I was just wondering if we could find an > > > easier way > > > to solve it w/o changing the API, adding the set_ps and propagating the > > > "interface" > > > inside the DMA reset. > > > > > > Maybe this could be fixed in the glue-logic in some way. Let me know > > > what do you think. > > > > Well, it's more up to you to tell me how you would like this be solved. > > We figured out what the problem was, but I don't know well enough the > > architecture of the driver to decide how the solution to this problem > > should be designed. I made an initial simple proposal to show what is > > needed, but I'm definitely open to suggestions. > > Do you have any suggestion on how to move forward with this? Another kind ping on this topic. I really would like to have the SPEAr600 network support work out of the box in mainline, which currently isn't the case with an MII PHY. I posted a patch that fixes the problem, see https://patchwork.ozlabs.org/patch/755926/, but the feedback I got so far does not give any direction on how to rework the patch to make it acceptable. Would it be possible to get some more feedback? Thanks a lot, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com