From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.bootlin.com ([62.4.15.54]:58812 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753489AbeB0Pmb (ORCPT ); Tue, 27 Feb 2018 10:42:31 -0500 From: Gregory CLEMENT To: Andrew Lunn Cc: David Miller , netdev , Vivien Didelot , Gregory Clement Subject: Re: [PATCH 0/2] mv88e6xxx: Poll when no interrupt defined References: <1519336713-5417-1-git-send-email-andrew@lunn.ch> <87lgfelohp.fsf@bootlin.com> <20180227140707.GA31805@lunn.ch> Date: Tue, 27 Feb 2018 16:42:20 +0100 In-Reply-To: <20180227140707.GA31805@lunn.ch> (Andrew Lunn's message of "Tue, 27 Feb 2018 15:07:07 +0100") Message-ID: <87r2p6jv6r.fsf@bootlin.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: netdev-owner@vger.kernel.org List-ID: Hi Andrew, On mar., févr. 27 2018, Andrew Lunn wrote: > On Tue, Feb 27, 2018 at 11:24:02AM +0100, Gregory CLEMENT wrote: >> Hi Andrew, >> >> On jeu., févr. 22 2018, Andrew Lunn wrote: >> >> > Not all boards using the mv88e6xxx switches have the interrupt output >> > connected to a GPIO. On these boards phylib has to poll the PHYs, >> > rather than use interrupts. Have the driver poll the interrupt status >> > register, which is more efficient than having phylib do it. And it >> > enables other switch interrupts to be services. >> > >> > The Armada 370RD is such a board without a interrupt GPIO. Now that >> > interrupts work, wire up the PHYs to make use if them. >> > >> > Gregory: Are you O.K. for the second patch to go through netdev? >> >> Why do you need that the second patch to go through netdev. Is there any >> dependency between the 2 patches? >> >> If it is the case does it means that an new kernel won't work with an >> old device tree? > > Hi Gregory > > There is a runtime dependency between the two. A new device tree blob > will not run on an old kernel. So if you take the second patch alone > via mvebu, the PHYs will stop working, no link up reported. > > But an old blob will run on a new kernel. Backwards compatibility is > maintained. Ok so you wanted to keep the kernel bisctable. So I'm fine with having this patch in netdev (and I think it is alrdeay the case). Gregory > > Andrew -- Gregory Clement, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering http://bootlin.com