Message-ID: <20220201155439.hv42mqed2n7wekuo@mobilestation>
Date:   Tue, 1 Feb 2022 18:54:39 +0300
From:   Serge Semin <Sergey.Semin@...kalelectronics.ru>
To:     Jakub Kicinski <kuba@...nel.org>
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>,
        Evgeny Sinelnikov <sin@...ealt.ru>,
        Serge Semin <fancer.lancer@...il.com>
Subject: Re: [PATCH 1/2] net: stmmac: added Baikal-T1/M SoCs glue layer

Hello Jakub,

On Fri, Jan 28, 2022 at 12:27:18PM -0800, Jakub Kicinski wrote:
> 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.

I've already posted my comments in this thread regarding the main
problematic issues of the driver, but Alexey for some reason ignored
them (dropped from his reply). Do you want me to copy my comments to
v2 and to proceed with review there?

Regarding the DT-bindings and the user-visible behavior. Right, I'll
add my comments in this matter. Thanks for suggesting. This was one of
the problems why I was against the driver integrating into the kernel.
One of our patchset brings a better organization to the current
DT-bindings of the Synopsys DW *MAC devices. In particular it splits
up the generic bindings for the vendor-specific MACs to use and the
bindings for the pure DW MAC compatible devices. In addition the
patchset will add the generic Tx/Rx clocks DT-bindings and the
DT-bindings for the AXI/MTL nodes. All of that and the rest of our
work will be posted a bit later as a set of the incremental patchsets
with small changes, one by one, for an easier review. We just need
some more time to finish the left of the work. The reason why the
already developed patches hasn't been delivered yet is that the rest
of the work may cause adding changes into the previous patches. In
order to decrease a number of the patches to review and present a
complete work for the community, we decided to post the patchsets
after the work is fully done.

-Sergey

Powered by blists - more mailing lists