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

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7c3e2575-24ea-4294-a877-59be65e4af5d@gmail.com>
Date: Fri, 22 Nov 2024 00:48:05 +0200
From: Sergey Ryazanov <ryazanov.s.a@...il.com>
To: Loic Poulain <loic.poulain@...aro.org>
Cc: Jiri Pirko <jiri@...nulli.us>, Jeffrey Hugo <quic_jhugo@...cinc.com>,
 Jerry Meng <jerry.meng.lk@...ctel.com>,
 Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH net-next v2] net: wwan: Add WWAN sahara port type

+Jiri

Hi Loic,

On 21.11.2024 11:08, Loic Poulain wrote:
> On Wed, 20 Nov 2024 at 22:48, Jeffrey Hugo <quic_jhugo@...cinc.com> 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@mail.gmail.com/#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