From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Fainelli Subject: Re: [RFC PATCH 0/1] net: phy: skip autoneg of ethernet(fec) on network boot Date: Fri, 6 Jul 2018 11:41:23 -0700 Message-ID: <8a437ead-5ded-57c4-c44f-95986442d626@gmail.com> References: <1530857230-31124-1-git-send-email-masahiko.kimoto@cybertrust.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit To: Masahiko Kimoto , Fugang Duan , Andrew Lunn , netdev@vger.kernel.org, Linux Kernel Mailing List , Hiraku Toyooka Return-path: In-Reply-To: <1530857230-31124-1-git-send-email-masahiko.kimoto@cybertrust.co.jp> Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On 07/05/2018 11:07 PM, Masahiko Kimoto wrote: > Hello, > > This patch introduces auto negotiation skipping for Ethernet. > It is useful to shorten boot time on network boot like the following > environment; > > - target board is NXP i.MX6. > - NIC is fec. > - using u-boot as boot loader. > - boot from kernel and initramfs obtained via TFTP. > - mount remote file system and switch root to that. > - thus all file system is on network. > > In this case, u-boot and kernel initialize NIC three times, > once in boot loader, once in device attach and once more in phy attach. > Each causes link auto negotiation and wait several seconds. > However link state is stable after reset by boot loader, therefore we > can skip hardware re-initialization of NIC in kernel. > > The patch skips link down in Ethernet(i.MX's fec) driver and initialization > in PHY layer if kernel option 'anegskip' is supplied. > > By this patch boot time becomes 3secs shorter. > > I think current patch is dirty hack, because; > - modification is split into PHY and Ethernet driver. > - in the case of two or more Ethernet I/F exist, currently there is > no way to specify whith I/F skips autonego. > > I would like to implement such skpping auto negotiation feature in generic > framework. How should we implement these requirements? I completely acknowledge and support the use case, but your implementation is definitively not the way to go. In my experience the problem is usually that there may be a disagreement on the Pause/Asym_Pause advertisement bits and that alone is responsible for triggering a re-negotiation. Can yo check if that is the case here? Thank you -- Florian