netdev - Re: [PATCH 0/2] mv88e6xxx: Poll when no interrupt defined

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] [day] [month] [year] [list]

Message-ID: <87r2p6jv6r.fsf@bootlin.com>
Date:   Tue, 27 Feb 2018 16:42:20 +0100
From:   Gregory CLEMENT <gregory.clement@...tlin.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     David Miller <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
        Gregory Clement <gregory.clement@...e-electrons.com>
Subject: Re: [PATCH 0/2] mv88e6xxx: Poll when no interrupt defined

Hi Andrew,
 
 On mar., févr. 27 2018, Andrew Lunn <andrew@...n.ch> wrote:

> On Tue, Feb 27, 2018 at 11:24:02AM +0100, Gregory CLEMENT wrote:
>> Hi Andrew,
>>  
>>  On jeu., févr. 22 2018, Andrew Lunn <andrew@...n.ch> 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