lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 28 Jun 2017 16:40:51 +0200 From: Giuseppe CAVALLARO <peppe.cavallaro@...com> To: Thomas Petazzoni <thomas.petazzoni@...e-electrons.com> CC: Corentin Labbe <clabbe.montjoie@...il.com>, Alexandre Torgue <alexandre.torgue@...com>, <netdev@...r.kernel.org>, <stable@...r.kernel.org> Subject: Re: [PATCH] net: ethernet: stmmac: properly set PS bit in MII configurations during reset 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?
Powered by blists - more mailing lists