Re: [PATCH] net: ethernet: stmmac: properly set PS bit in MII configurations during reset

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

 



Hello Thomas

I do not want to change a critical reset function shared among different platforms where this problem has never met but you are right that we have to find a way to proceed in order to finalize your work. Let me elaborate your initial patch and I try to give you a proposal asap. In my mind, we should have a dedicated spear_dma_reset for your case that should be used on
SPEAr platform driver (or by using st,spear600-gmac compatibility).
Also your patch did not consider the RMII and (R)GMII cases.

Regards
Peppe

On 6/25/2017 2:32 PM, Thomas Petazzoni wrote:
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?





[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]