Re: [PATCH net-next v2] net: wwan: Add WWAN sahara port type

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



+Jiri

Hi Loic,

On 21.11.2024 11:08, Loic Poulain wrote:
On Wed, 20 Nov 2024 at 22:48, Jeffrey Hugo <quic_jhugo@xxxxxxxxxxx> wrote:
On 11/20/2024 1:36 PM, Sergey Ryazanov wrote:
+Manivannan

Hello Jerry,

this version looks a way better, still there is one minor thing to
improve. See below.

Manivannan, Loic, could you advice is it Ok to export that SAHARA port
as is?

I'm against this.

There is an in-kernel Sahara implementation, which is going to be used
by QDU100.  If WWAN is going to own the "SAHARA" MHI channel name, then
no one else can use it which will conflict with QDU100.

I expect the in-kernel implementation can be leveraged for this.

Fair enough, actually the same change has already been discussed two
years ago, and we agreed that it should not be exposed as a WWAN
control port:
https://lore.kernel.org/netdev/CAMZdPi_7KGx69s5tFumkswVXiQSdxXZjDXT5f9njRnBNz1k-VA@xxxxxxxxxxxxxx/#t

Thank you for reminding us about that conversation. There you have shared a good thought, that the WWAN framework suppose to export mostly management ports. And all other debug/dump/reflash features should be implemented using corresponding kernel APIs.

Last year, more port types were merged. As part of the T7xx driver development. Specifically it were Fastboot, ADB, and MIPC. See:
- 495e7c8e9601 wwan: core: Add WWAN ADB and MIPC port type
- e3caf184107a wwan: core: Add WWAN fastboot port type

If ADB somehow could be considered a management interface. MIPC and Fastboot are firmware management interfaces. And I recall a discussion regarding the Fastboot implementation and there was a NACK from someone from devlink subsystem.

Personally, I prefer the firmware management/debugging operations being implemented using a generic kernel API like it was done in IOSM. And we are suggesting contributors to use the existing kernel API instead of exposing RAW interfaces. On another hand, devlink developers are not happy to see this kind of devlink usage.

Loic, do you have any idea how to solve this puzzle? And how do you think, shall we do something regarding the already introduced Fastboot/ADB/MIPC port types?

--
Sergey




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux