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: <MEYP282MB26973271CE109D4EF1643C0ABBCFA@MEYP282MB2697.AUSP282.PROD.OUTLOOK.COM>
Date:   Sun, 8 Oct 2023 03:19:37 +0000
From:   萝卜 英雄 <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>,
        "Fuqiang Yan(Felix)" <felix.yan@...ocom.com>,
        "Qifeng Liu(Qifeng)" <liuqf@...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).

As far as I know, these patch set created by Intel colleague. later, it was handed over to me for further follow-up. I remember Intel colleague mentioned that using devlink framework is an open-source suggestion, but I unable to verify temporarily.
After I read the devlink framework, I found that the components of devlink like flash and region can be used to implement the features of firmware flashing and coredump collection without other user space application and wwan iosm driver also use devlink framework.

Yes, it seemed mtk_t7xx driver can use fastboot protocol for flashing with fastboot tool but I think this will result in some other tasks completing these features:
1.Driver export a port to user space for fastboot tool and this port must be scan by fastboot tool for firmware flashing feature.
2.A new tool will be needed for coredump feature and driver will adapter for this tool for modem device use the same channel for fastboot and coredump. 

IF we use devlink framework, it seemed more complete and unified. So I hope it can be allowed and I would like to confirm if the current driver can continue using devlink?
Hope to get your help to make sure whether t7xx can use devlink, if can't , we may need to consider other solutions.

Regards,
JinJian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ