netdev - Re: [PATCH net-next 2/4] net: mvpp2: add mvpp2_phylink_to

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]

Date:   Thu, 10 Dec 2020 19:22:25 +0100
From:   Marcin Wojtas <mw@...ihalf.com>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Sasha Levin <sashal@...nel.org>, stable@...r.kernel.org,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        netdev <netdev@...r.kernel.org>,
        Gabor Samu <samu_gabor@...oo.ca>,
        Jon Nettleton <jon@...id-run.com>,
        Andrew Elwell <andrew.elwell@...il.com>
Subject: Re: [PATCH net-next 2/4] net: mvpp2: add mvpp2_phylink_to_port() helper

czw., 10 gru 2020 o 18:56 Russell King - ARM Linux admin
<linux@...linux.org.uk> napisał(a):
>
> On Thu, Dec 10, 2020 at 06:43:50PM +0100, Marcin Wojtas wrote:
> > I must admit that due to other duties I did not follow the mainline
> > mvpp2 for a couple revisions (and I am not maintainer of it). However
> > recently I got reached-out directly by different developers - the
> > trigger was different distros upgrading the kernel above v5.4+ and for
> > some reasons the DT path is not chosen there (and the ACPI will be
> > chosen more and more in the SystemReady world).
>
> Please note that there is no active maintainer for mvpp2.
>

Right. I think I can volunteer to be one (my name is in the driver
code anyway :) ) and spend some time on reviewing/testing the patches,
unless there are no objections. In such case, are the drivers/net
Mainteners who decide/accept it?

> It will be good to get rid of the ACPI hack here, as that means we'll
> be using the same code paths for both ACPI and DT, meaning hopefully
> less bugs like this go unnoticed.
>

+1. As soon as the MDIO+ACPI lands, I plan to do the rework.

Best regards,
Marcin