netdev - Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56DDA3D5.3090209@st.com>
Date:	Mon, 7 Mar 2016 16:52:53 +0100
From:	Giuseppe CAVALLARO <peppe.cavallaro@...com>
To:	Andreas Färber <afaerber@...e.de>
CC:	Gabriel Fernandez <gabriel.fernandez@...aro.org>,
	Heiko Stübner <heiko@...ech.de>,
	<linux-rockchip@...ts.infradead.org>, <netdev@...r.kernel.org>,
	<devicetree@...r.kernel.org>,
	LAKML <linux-arm-kernel@...ts.infradead.org>,
	Alexandre TORGUE <alexandre.torgue@...com>,
	Fabrice GASNIER <fabrice.gasnier@...com>
Subject: Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement

On 3/7/2016 4:46 PM, Andreas Färber wrote:
> Hi Peppe,
>
> Am 07.03.2016 um 16:09 schrieb Giuseppe CAVALLARO:
>> On 3/7/2016 3:27 PM, Andreas Färber wrote:
>>> Indeed, reverting Gabriel's commit fixes the observed error messages
> [...]
>>> However, I am unable to ping any hosts on the network now.
>>
>> hmm, this could be another problem. I wonder if you can
>> check which recent patch is introducing the problem on ARM64.
>> For example if this depends on Oct_2015 update.
>
> I've had success reverting drivers/net/ethernet/stmicro/ up to and
> including "stmmac: first frame prep at the end of xmit routine", i.e.
> top 7 commits.

Andreas, I will check it and let you know asap.

>
> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/net/ethernet/stmicro?id=0e80bdc9a72df3b31a9fc2012102a6cc8d664e93
>
>> If you share some logs to me I can take a look at them.
>> Then we can try to check if the problem in on rx or tx path.
>> I also ask you yo check the axi settings.
>
> On the reverted (good) branch I see in dmesg:
>
> [  +0.001100] rk_gmac-dwmac ff290000.ethernet: Looking up phy-supply
> from device tree
> [  +0.000030] rk808 0-001b: Looking up vcc12-supply from device tree
> [  +0.000013] vcc_lan: supplied by vcc_io
> [  +0.000120] rk_gmac-dwmac ff290000.ethernet: clock input or output?
> (input).
> [  +0.000010] rk_gmac-dwmac ff290000.ethernet: TX delay(0x30).
> [  +0.000007] rk_gmac-dwmac ff290000.ethernet: RX delay(0x10).
> [  +0.000014] rk_gmac-dwmac ff290000.ethernet: init for RGMII
> [  +0.000104] rk_gmac-dwmac ff290000.ethernet: clock input from PHY
> [  +0.005099] rk_gmac-dwmac ff290000.ethernet: no reset control found
> [  +0.000007] stmmac - user ID: 0x10, Synopsys ID: 0x35
> [  +0.000002]  Ring mode enabled
> [  +0.000006]  DMA HW capability register supported
> [  +0.000000]  Normal descriptors
> [  +0.000004]  RX Checksum Offload Engine supported (type 2)
> [  +0.000002]  TX Checksum insertion supported
> [  +0.000002]  Wake-Up On Lan supported
> [  +0.000052]  Enable RX Mitigation via HW Watchdog Timer
> [  +0.000683] rk_gmac-dwmac ff290000.ethernet eth0: No MDIO subnode found
> [  +0.000124] of_get_named_gpiod_flags: can't parse 'snps,reset-gpio'
> property of node '/ethernet@...90000[0]'
> [  +0.004219] libphy: stmmac: probed
> [  +0.000010] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active
> [  +0.000005] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01)
>
> [  +0.881011] eth0: device MAC address 4a:78:dd:10:b3:17
> [  +4.003065] rk_gmac-dwmac ff290000.ethernet eth0: Link is Up -
> 1Gbps/Full - flow control rx/tx
>
> The MAC address is random, changing each time. Otherwise there's no log
> difference I spot to the pre-Gabriel broken state.

ok
>
> If you need more info, let me know where to find it.

no it's ok at this stage.

>
> Thanks,

welcome

> Andreas

Regards
peppe