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>] [day] [month] [year] [list]
Message-ID: <20181018134251.bvfesjlhzj2yxzqe@zorba>
Date:   Thu, 18 Oct 2018 06:42:51 -0700
From:   Daniel Walker <danielwa@...co.com>
To:     Claudiu Manoil <claudiu.manoil@....com>
Cc:     Hemant Ramdasi <hramdasi@...co.com>, netdev@...r.kernel.org
Subject: Re: [danielwa@...co.com: Re: gianfar: Implement MAC reset and
 reconfig procedure]

On Thu, Oct 18, 2018 at 12:16:06PM +0000, Claudiu Manoil wrote:
> Hi,
> 
> Sorry but I never heard about the phy you're quoting, this m88e1101, what is it?
> Link mode? (SGMII, RGMII, ?)
> Our boards (the ones I know) have Vitesse or Atheros phys.
> If the maccfg2 setting you're mentioning really makes the difference, then it looks
> like your phy enters in 10/100 Mbit or half duplex operation mode after MAC reset,
> aka lower speed MII mode, whereas the INIT_SETTINGS set up the MAC to operate
> in 1000 full duplex mode (GMII mode) by default.
> Link speed settings for the MACCFG2 register should be later adjusted via adjust_link() callback,
> so that if the initial maccfg2 settings don't match with the phy settings they will be adjusted
> by phylib's adjust_link().  For some reason this doesn't seem to happen on your setup either.
> So, could you please confirm whether after MAC reset your phy enters lower speed mode (MII),
> and whether the adjust_link() callback is getting invoked after ifconfig up?
> 


It's a Marvell phy, this is not an eval board from NXP it's custom hardware. The link on this board
is setup to run at 100Mps. Here's a snippet of the logs during a test run.

IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready

fsl-gianfar ff725000.ethernet eth1: Link is Up - 100Mbps/Full - flow control off
IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
PING 10.126.154.1 (10.126.154.1): 56 data bytes
64 bytes from 10.126.154.1: seq=0 ttl=255 time=2.101 ms

--- 10.126.154.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss


I can check if adjust_link() is running. This kernel has only very few changes to allow the hardware to work
allos isolated under arch/powerpc/ , certainly no changes under drivers/. So if it's suppose to be running
there is no reason why it wouldn't be.

Daniel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ