linux-kernel - Re: [PATCH net-next 7/7] net: ipa: allow arbitrary number of interconnects

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: <20210118115816.149d71f6@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Mon, 18 Jan 2021 11:58:16 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Alex Elder <elder@...aro.org>
Cc:     davem@...emloft.net, evgreen@...omium.org,
        bjorn.andersson@...aro.org, cpratapa@...eaurora.org,
        subashab@...eaurora.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 7/7] net: ipa: allow arbitrary number of
 interconnects

On Sun, 17 Jan 2021 10:03:41 -0600 Alex Elder wrote:
> On 1/16/21 9:12 PM, Jakub Kicinski wrote:
> > On Fri, 15 Jan 2021 06:50:50 -0600 Alex Elder wrote:  
> >> Currently we assume that the IPA hardware has exactly three
> >> interconnects.  But that won't be guaranteed for all platforms,
> >> so allow any number of interconnects to be specified in the
> >> configuration data.
> >>
> >> For each platform, define an array of interconnect data entries
> >> (still associated with the IPA clock structure), and record the
> >> number of entries initialized in that array.
> >>
> >> Loop over all entries in this array when initializing, enabling,
> >> disabling, or tearing down the set of interconnects.
> >>
> >> With this change we no longer need the ipa_interconnect_id
> >> enumerated type, so get rid of it.  
> > 
> > Okay, all the platforms supported as of the end of the series
> > still have 3 interconnects, or there is no upstream user of
> > this functionality, if you will. What's the story?  
> 
> The short answer is that there is another version of IPA that
> has four interconnects instead of three.  (A DTS file for it is
> in "sdxprairie.dtsi" in the Qualcomm "downstream" code.)  I hope
> to have that version supported this year, but it's not my top
> priority right now.  Generalizing the interconnect definitions
> as done in this series improves the driver, but you're right, it
> is technically not required at this time.
> 
> And some more background:
> The upstream IPA driver is derived from the Qualcomm downstream
> code published at codeaurora.org.  The downstream driver is huge
> (it's well over 100,000 lines of code) and it supports lots of
> IPA versions and some features that are not present upstream.
> 
> In order to have any hope of getting upstream support for the
> IPA hardware, the downstream driver functionality was reduced,
> removing support for filtering, routing, and NAT.  I spent many
> months refactoring and reworking that code to make it more
> "upstreamable," and eventually posted the result for review.
> 
> Now that there is an upstream driver, a long term goal is to
> add back functionality that got removed, matching the most
> important features and hardware support found in the downstream
> code.  So in cases like this, even though this feature is not
> yet required, adding it now lays groundwork to make later work
> easier.
> 
> Everything I do with the upstream IPA driver is aimed at in-tree
> support for additional IPA features and hardware versions.  So
> even if an improvement isn't required *now*, there is at least
> a general plan to add support "soon" for something that will
> need it.
> 
> Beyond even that, there are some things I intend to do that
> will improve the driver, even if they aren't technically
> required near-term.  For example, I'd like to dynamically
> allocate endpoints based on what's needed, rather than
> having the driver support any number of them up to a maximum
> fixed at build time.
> 
> Probably a longer response than you needed, but I thought it
> would help to provide more background.  Besides, you *did* ask
> for "the story..."

Thanks, I think I get it now.

But it does sound a little too much like aligning with the vendor
driver for the sake of aligning with the vendor driver. This makes 
the review for someone not familiar with the vendor driver hard, 
and raises questions like "is this really needed upstream or just
downstream / out-of-tree". Please try to reorient the work towards
implementing particular pieces of functionality upstream start to end. 

Applied, with a warning :)