On Fri, Nov 17, 2023 at 04:26:38PM -0800, Jakub Kicinski wrote: > On Fri, 17 Nov 2023 12:36:02 +0530 Manivannan Sadhasivam wrote: > > Sorry to revive this old thread, this discussion seems to have fell through the > > cracks... > > It did not fall thru the cracks, you got a nack. Here it is in a more > official form: > > Nacked-by: Jakub Kicinski <kuba@xxxxxxxxxx> > > Please make sure you keep this tag and CC me if you ever post any form > of these patches again. Thanks for the NACK. Could you please respond to my reply justifying this driver (the part you just snipped)? I'm posting it below: > As I explained above, other interfaces also expose this kind of functionality > between host and the device. One of the credible usecase with this driver is > sharing the network connectivity available in either host or the device with the > other end. > > To make it clear, we have 2 kind of channels exposed by MHI for networking. > > 1. IP_SW0 > 2. IP_HW0 > > IP_SW0 is useful in scenarios I explained above and IP_HW0 is purely used to > provide data connectivity to the host machines with the help of modem IP in the > device. And the host side stack is already well supported in mainline. With the > proposed driver, Linux can run on the device itself and it will give Qcom a > chance to get rid of their proprietary firmware used on the PCIe endpoint > devices like modems, etc... I think you made up your mind that this driver is exposing the network interface to the firmware on the device. I ought to clearify that the device running this driver doesn't necessarily be a modem but a PCIe endpoint instance that uses the netdev exposed by this driver to share data connectivity with another device. This concept is not new and being supported by other protocols such as Virtio etc... - Mani -- மணிவண்ணன் சதாசிவம்
