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
| ||
|
Date: Sun, 17 Jan 2021 10:03:41 -0600 From: Alex Elder <elder@...aro.org> To: Jakub Kicinski <kuba@...nel.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 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
Powered by blists - more mailing lists