[<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