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

[Alex Elder]

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..."

					-Alex