Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965143AbcCOMhs (ORCPT ); Tue, 15 Mar 2016 08:37:48 -0400 Received: from mx07-00178001.pphosted.com ([62.209.51.94]:44106 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754826AbcCOMhn (ORCPT ); Tue, 15 Mar 2016 08:37:43 -0400 Message-ID: <56E801EB.6030107@st.com> Date: Tue, 15 Mar 2016 13:36:59 +0100 From: Giuseppe CAVALLARO User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Tomeu Vizoso CC: Dinh Nguyen , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , Fabrice GASNIER , "devicetree@vger.kernel.org" , =?UTF-8?B?SGVpa28gU3TDvGJuZXI=?= , , "open list:ARM/Rockchip SoC..." , LAKML , Gabriel Fernandez , Alexandre TORGUE , =?UTF-8?B?RnJhbmsgU2Now6RmZXI=?= , LKML Subject: Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement References: <1457294038-14243-1-git-send-email-afaerber@suse.de> <56DDA3D5.3090209@st.com> <56DDB749.1020808@suse.de> <56DE7E1D.5070508@st.com> <56DFE55B.2090806@st.com> <56DFE64B.8060606@st.com> <56DFF253.9050208@st.com> <56DFFA9E.7060602@st.com> <56E033C8.40506@st.com> <56E038CE.606@st.com> <56E13AAB.2080900@st.com> <56E28B5D.6000708@st.com> <56E6E4B0.8060408@st.com> In-Reply-To: Content-Type: multipart/mixed; boundary="------------000706010800070300010608" X-Originating-IP: [10.52.139.48] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-03-15_04:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2209 Lines: 69 --------------000706010800070300010608 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Hello Tomeu On 3/15/2016 8:23 AM, Tomeu Vizoso wrote: > Thanks. > > Btw, I have rebased on top of 4.5 this morning and I have noticed that > 88f8b1bb41c6 ("stmmac: Fix 'eth0: No PHY found' regression") got in > there, so I guess we have now a bunch of boards with broken network on > that release:( This is the status on my side: I am testing on an HW that has the Enhanced descriptors and all works fine. On this HW, if I force the driver to use the normal descriptor layout, I meet problems but using both net.git and net-next. So I suspect I cannot ply with this HW forcing the normal descriptors. But! That is helping me to check if, on net-next, the stmmac is actually programming fine the normal desc case. I have just found another fix so I kindly ask you to apply the temp patch attached and let me know. In details, I have noticed that the OWN bit was not set in the right TDES0. I also ask you to give me a log of the kernel where the stmmac was running fine. I would like to see which configuration it is selected at runtime by the driver on your box. From your previous logs (where the stmmac failed), it seems that the problem is on normal desc but, to be honest, this is the first case I see a 3.50a with HW capability register and w/o Enhanced descriptors. Best Regards Peppe > Regards, > > Tomeu --------------000706010800070300010608 Content-Type: text/x-patch; name="tmp.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="tmp.patch" diff --git a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c index e13228f..44c052f 100644 --- a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c +++ b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c @@ -217,10 +217,10 @@ static void ndesc_prepare_tx_desc(struct dma_desc *p, int is_fs, int len, if (ls) tdes1 |= TDES1_LAST_SEGMENT; - if (tx_own) - tdes1 |= TDES0_OWN; - p->des1 = tdes1; + + if (tx_own) + p->des0 |= TDES0_OWN; } static void ndesc_set_tx_ic(struct dma_desc *p) --------------000706010800070300010608--