From: David S. Miller Date: Mon, 9 Mar 2020 05:07:10 +0000 (-0700) Subject: Merge branch 'net-introduce-Qualcomm-IPA-driver' X-Git-Tag: v5.7-rc1~146^2~223 X-Git-Url: http://git.osdn.net/view?a=commitdiff_plain;h=fbd436029c48e2c01fa789e3e137b76dc14d65f4;p=tomoyo%2Ftomoyo-test1.git Merge branch 'net-introduce-Qualcomm-IPA-driver' Alex Elder says: ==================== net: introduce Qualcomm IPA driver (UPDATED) This series presents the driver for the Qualcomm IP Accelerator (IPA). This is version 2 of this updated series. It includes the following small changes since the previous version: - Now based on net-next instead of v5.6-rc - Config option now named CONFIG_QCOM_IPA - Some minor cleanup in the GSI code - Small change to replenish logic - No longer depends on remoteproc bug fixes What follows is the basically same explanation as was posted previously. -Alex I have posted earlier versions of this code previously, but it has undergone quite a bit of development since the last time, so rather than calling it "version 3" I'm just treating it as a new series (indicating it's been updated in this message). The fast/data path is the same as before. But the driver now (nearly) supports a second platform, its transaction handling has been generalized and improved, and modem activities are now handled in a more unified way. This series is available (based on net-next in branch "ipa_updated-v2" in this git repository: https://git.linaro.org/people/alex.elder/linux.git The branch depends on other one other small patch that I sent out for review earlier. https://lore.kernel.org/lkml/20200306042302.17602-1-elder@linaro.org/ I want to address some of the discussion that arose last time. First, there was the WWAN discussion. Here's the history: - This was last posted nine months ago. - Reviewers at that time favored developing a new WWAN subsystem that would be used for managing devices like this. And the suggestion was to not accept this driver until that could be developed. - Along the way, Apple acquired much of Intel's modem business. And as a result, the generic framework became less pressing. - I did participate in the WWAN subsystem design however, and although it went dormant for a while it's been resurrected: https://lore.kernel.org/netdev/20200225100053.16385-1-johannes@sipsolutions.net/ - Unfortunately the proposed WWAN design was not an easy fit with Qualcomm's integrated modem interfaces. Given that rmnet is a supported link type for in the upstream "iproute2" package (more on this below), I have opted not to integrate with any WWAN subsystem. So in summary, this driver does not integrate with a generic WWAN framework. And I'd like it to be accepted upstream despite that. Next, Arnd Bergmann had some concerns about flow control. (Note: some of my discussions with Arnd about this were offline.) The overall architecture here also involves the "rmnet" driver: drivers/net/ethernet/qualcomm/rmnet The rmnet driver presents a network device for use. It connects with another network device presented, by the IPA driver. The rmnet driver wraps (and unwraps) packets transferred to (and from) the IPA driver with QMAP headers. --------------- | rmnet_data0 | <-- "real" netdev --------------- || }- QMAP spoken here -------------- | rmnet_ipa0 | <-- also netdev, transporting QMAP packets -------------- || -------------- ( IPA hardware ) -------------- Arnd's concern was that the rmnet_data0 network device does not have the benefit of information about the state of the underlying IPA hardware in order to be effective in controlling TX flow. The feared result is over-buffering of TX packets (bufferbloat). I began working on some simple experiments to see whether (or how much) his concern was warranted. But it turned out that completing these experiments was much more work than had been hoped. The rmnet driver is present in the upstream kernel. There is also support for the rmnet link type in the upstream "ip" user space command in the "iproute2" package. Changing the layering of rmnet over IPA likely involves deprecating the rmnet driver and its support in "iproute2". I would really rather not go down that path. There is precedent for this sort of layering of network devices (L2TP, VLAN). And any architecture like this would suffer the issues Arnd mentioned; the problem is not limited to rmnet and IPA. I do think this is a problem worth solving, but the prudent thing to do might be to try to solve it more generally. So to summarize on this issue, this driver does not attempt to change the way the rmnet and IPA drivers work together. And even though I think Arnd's concerns warrant more investigation, I'd like this driver to to be accepted upstream without any change to this architecture. Finally, a more technical description for the series, and some acknowledgements to some people who contributed to it. The IPA is a component present in some Qualcomm SoCs that allows network functions such as aggregation, filtering, routing, and NAT to be performed without active involvement of the main application processor (AP). In this initial patch series these advanced features are not implemented. The IPA driver simply provides a network interface that makes the modem's LTE network available in Linux. This initial series supports only the Qualcomm SDM845 SoC. The Qualcomm SC7180 SoC is partially supported, and support for other platforms will follow. This code is derived from a driver developed by Qualcomm. A version of the original source can be seen here: https://source.codeaurora.org/quic/la/kernel/msm-4.9/tree in the "drivers/platform/msm/ipa" directory. Many were involved in developing this, but the following individuals deserve explicit acknowledgement for their substantial contributions: Abhishek Choubey Ady Abraham Chaitanya Pratapa David Arinzon Ghanim Fodi Gidon Studinski Ravi Gummadidala Shihuan Liu Skylar Chang ==================== Signed-off-by: David S. Miller --- fbd436029c48e2c01fa789e3e137b76dc14d65f4