netdev - Re: [PATCH 1/2] net: stmmac: added Baikal-T1/M SoCs glue layer

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]

Message-ID: <20220128122718.686912e9@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Fri, 28 Jan 2022 12:27:18 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Serge Semin <Sergey.Semin@...kalelectronics.ru>
Cc:     Alexey Sheplyakov <asheplyakov@...ealt.ru>, netdev@...r.kernel.org,
        Giuseppe Cavallaro <peppe.cavallaro@...com>,
        Alexandre Torgue <alexandre.torgue@...s.st.com>,
        Jose Abreu <joabreu@...opsys.com>,
        Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>,
        Pavel Parkhomenko <Pavel.Parkhomenko@...kalelectronics.ru>,
        Serge Semin <fancer.lancer@...il.com>,
        Evgeny Sinelnikov <sin@...ealt.ru>
Subject: Re: [PATCH 1/2] net: stmmac: added Baikal-T1/M SoCs glue layer

On Fri, 28 Jan 2022 22:55:09 +0400 Alexey Sheplyakov wrote:
> On Fri, Jan 28, 2022 at 06:06:42PM +0300, Serge Semin wrote:
> > Hello Alexey and network folks
> > 
> > First of all thanks for sharing this patchset with the community. The
> > changes indeed provide a limited support for the DW GMAC embedded into
> > the Baikal-T1/M1 SoCs. But the problem is that they don't cover all
> > the IP-blocks/Platform-setup peculiarities  
> 
> In general quite a number of Linux drivers (GPUs, WiFi chips, foreign
> filesystems, you name it) provide a limited support for the corresponding
> hardware (filesystem, protocol, etc) and don't cover all peculiarities.
> Yet having such a limited support in the mainline kernel is much more
> useful than no support at all (or having to use out-of-tree drivers,
> obosolete vendor kernels, binary blobs, etc).
> 
> Therefore "does not cover all peculiarities" does not sound like a valid
> reason for rejecting this driver. That said it's definitely up to stmmac
> maintainers to decide if the code meets the quality standards, does not
> cause excessive maintanence burden, etc.

Sounds sensible, Serge please take a look at the v2 and let us know if
there are any bugs in there. Or any differences in DT bindings or user
visible behaviors with what you're planning to do. If the driver is
functional and useful it can evolve and gain support for features and
platforms over time.