linux-kernel - RE: [net-next v4 0/5] net: wwan: t7xx: fw flashing & coredump support

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>] [day] [month] [year] [list]
Message-ID: <MEYP282MB2697C5005B872DB5277E531ABBA5A@MEYP282MB2697.AUSP282.PROD.OUTLOOK.COM>
Date:   Fri, 3 Nov 2023 06:32:14 +0000
From:   Jinjian Song <SongJinJian@...mail.com>
To:     Loic Poulain <loic.poulain@...aro.org>,
        Jiri Pirko <jiri@...nulli.us>
CC:     "davem@...emloft.net" <davem@...emloft.net>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "corbet@....net" <corbet@....net>,
        "ryazanov.s.a@...il.com" <ryazanov.s.a@...il.com>,
        "johannes@...solutions.net" <johannes@...solutions.net>,
        "chandrashekar.devegowda@...el.com" 
        <chandrashekar.devegowda@...el.com>,
        "linuxwwan@...el.com" <linuxwwan@...el.com>,
        "chiranjeevi.rapolu@...ux.intel.com" 
        <chiranjeevi.rapolu@...ux.intel.com>,
        "haijun.liu@...iatek.com" <haijun.liu@...iatek.com>,
        "m.chetan.kumar@...ux.intel.com" <m.chetan.kumar@...ux.intel.com>,
        "ricardo.martinez@...ux.intel.com" <ricardo.martinez@...ux.intel.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "nmarupaka@...gle.com" <nmarupaka@...gle.com>,
        "vsankar@...ovo.com" <vsankar@...ovo.com>,
        "danielwinkler@...gle.com" <danielwinkler@...gle.com>,
        "Lei Zhang(Terence)" <zhangl@...ocom.com>,
        "Qifeng Liu(Qifeng)" <liuqf@...ocom.com>,
        "Fuqiang Yan(Felix)" <felix.yan@...ocom.com>
Subject: RE: [net-next v4 0/5] net: wwan: t7xx: fw flashing & coredump support

>>On Wed, 13 Sept 2023 at 11:17, Jiri Pirko <jiri@...nulli.us> wrote:
>>>
>>> Tue, Sep 12, 2023 at 11:48:40AM CEST, songjinjian@...mail.com wrote:
>>> >Adds support for t7xx wwan device firmware flashing & coredump 
>>> >collection using devlink.
>>>
>>> I don't believe that use of devlink is correct here. It seems like a 
>>> misfit. IIUC, what you need is to communicate with the modem.
>>> Basically a communication channel to modem. The other wwan drivers 
>>> implement these channels in _ctrl.c files, using multiple protocols.
>>> Why can't you do something similar and let devlink out of this please?
>>>
>>> Until you put in arguments why you really need devlink and why is it 
>>> a good fit, I'm against this. Please don't send any other versions of 
>>> this patchset that use devlink.

>The t7xx driver already has regular wwan data and control interfaces registered with the wwan framework, making it functional. Here the exposed low level resources are not really wwan/class specific as it is for firmware upgrade >and coredump, so I think that is why Jinjian chose the 'feature agnostic' devlink framework. IMHO I think it makes sense to rely on such a framework, or maybe on the devcoredump class.

>That said, I see the protocol for flashing and doing the coreboot is fastboot, which is already supported on the user side with the fastboot tool, so I'm not sure abstracting it here makes sense. If the protocol is really fasboot compliant, Wouldn't it be simpler to directly expose it as a new device/channel? and rely on a userspace tool for regular fastboot operations (flash, boot, dump). This may require slightly modifying the fastboot tool to detect and support that new transport (in addition to the existing usb and ethernet support).

>I think this is the advantages of using devlink to implement flash and dump collect:
>1.Devlink framework provide the interface of flash and dump, and no need to develop corresponding tools anymore. From another perspective, using devlnik can directly reduce the complexity of PC manufacturer's customer production lines, helping to reduce their costs(time/production).
>2.Currently, the platform architecture of each WWAN module manufacturer is not compatible, Qualcomm implement communicate channels in host driver and using fastboot tool to flash, using their coredump tool to collect dump. Intel implement their host driver in devlink framework, using devlink tool to flash and collect dump. MTK design to use devlink doing flash and dump collection. Devlink can ignore difference in platform architecture, abstracting these commonly used interfaces, I understand that Intel and MTK are preparing to use this plan in the future.
>3.Fastboot tool relies on manual installation by user and it does not have the advantages of the above two features(currently, seemed can't support collect core dump directly). It seems that devlink does not need to be installed separately, _ctrl.c files used for QualComm, but Intel and MTK don't use the same design in module, so cannot directly reference.
>4.It seemed that Intel WWAN product using iosm driver withing devlink framework has be allowned in upstream, it provides some guidance and direction.

>So hope to get your help about the suggestions for the next steps, thanks.


Hope to get your help about the suggestion, if devlink framework here is not suitable, I hope to discuss other alternative solutions.


Thanks.
Regards,
Jinjian