public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Jiri Pirko <jiri@resnulli.us>
To: Jinjian Song <songjinjian@hotmail.com>
Cc: chandrashekar.devegowda@intel.com,
	chiranjeevi.rapolu@linux.intel.com, danielwinkler@google.com,
	davem@davemloft.net, edumazet@google.com,
	haijun.liu@mediatek.com, ilpo.jarvinen@linux.intel.com,
	jesse.brandeburg@intel.com, jinjian.song@fibocom.com,
	johannes@sipsolutions.net, kuba@kernel.org, linuxwwan@intel.com,
	linuxwwan_5g@intel.com, loic.poulain@linaro.org,
	m.chetan.kumar@linux.intel.com, netdev@vger.kernel.org,
	pabeni@redhat.com, ricardo.martinez@linux.intel.com,
	ryazanov.s.a@gmail.com, soumya.prakash.mishra@intel.com
Subject: Re: [net-next 3/6] net: wwan: t7xx: Implements devlink ops of firmware flashing
Date: Mon, 7 Aug 2023 09:35:31 +0200	[thread overview]
Message-ID: <ZNCew+BPDITsZdY1@nanopsycho> (raw)
In-Reply-To: <MEYP282MB269742CBB438E43607FA3BC4BB0EA@MEYP282MB2697.AUSP282.PROD.OUTLOOK.COM>

Sat, Aug 05, 2023 at 02:05:35PM CEST, songjinjian@hotmail.com wrote:
>Thu, Aug 03, 2023 at 04:18:09AM CEST, songjinjian@hotmail.com wrote:
>>>From: Jinjian Song <jinjian.song@fibocom.com>
>>>
>>>Adds support for t7xx wwan device firmware flashing using devlink.
>>>
>>>On user space application issuing command for firmware update the driver
>>>sends fastboot flash command & firmware to program NAND.
>>>
>>>In flashing procedure the fastboot command & response are exchanged between
>>>driver and device.
>>>
>>>Below is the devlink command usage for firmware flashing
>>>
>>>$devlink dev flash pci/$BDF file ABC.img component ABC
>>>
>>>Note: ABC.img is the firmware to be programmed to "ABC" partition.
>>>
>>>Base on the v5 patch version of follow series:
>>>'net: wwan: t7xx: fw flashing & coredump support'
>>>(https://patchwork.kernel.org/project/netdevbpf/patch/fc8bbb0b66a5ff3a489ea9857d79b374508090ef.1674307425.git.m.chetan.kumar@linux.intel.com/)
>>>
>>>Signed-off-by: Jinjian Song <jinjian.song@fibocom.com>
>>
>>Overall, this patch/patchset is very ugly and does some wrong or
>>questionable things that make my head hurt. Ugh.
>
>Thanks for your review, this is my first time to do this and when I git send-email,
>my email account locked so the patchset break at 3/6 and I resend the remaining 3 patches again.
>
>I will reorganize and prepare v2 version, sorry for that.
>
>>> #include "t7xx_port_devlink.h"
>>> 
>>>+static int t7xx_devlink_port_read(struct t7xx_port *port, char *buf, size_t count)
>>
>>You have "devlink" in lot of the function and struct field names. Does
>>not make sense to me as for example this function does not have anything
>>to do with devlink. Could you please rename them all?
>
>Thanks for your review, I think I can rename them all to flash_dump port read, this functions used
>to send or recieve data(firmware/coredump/command) with modem
>
>>>+	set_bit(T7XX_FLASH_STATUS, &dl->status);
>>>+	port = dl->port;
>>>+	dev_dbg(port->dev, "flash partition name:%s binary size:%zu\n", component, fw->size);
>>>+	ret = t7xx_devlink_fb_flash_partition(port, component, fw->data, fw->size);
>>>+
>>>+	sprintf(flash_status, "%s %s", "flashing", !ret ? "success" : "failure");
>>
>>Don't put return status in to the flash_status. Function returns error
>>value which is propagated to the user.
>>
>>In fact, in your case, usage of devlink_flash_update_status_notify()
>>does not make much sense as you don't have multiple flash stages.
>
>Thanks for your review, yes 'success' and 'failure', Function can returns error I will remove 
>status notify and flash_status
> 
>>>+	devlink_flash_update_status_notify(devlink, flash_status, params->component, 0, 0);
>>>+	clear_bit(T7XX_FLASH_STATUS, &dl->status);
>>>+
>>>+err_out:
>>>+	return ret;
>>> 	return 0;
>>> }
>
>>> static int t7xx_devlink_reload_up(struct devlink *devlink,
>>>@@ -50,13 +266,114 @@ static int t7xx_devlink_reload_up(struct devlink *devlink,
>>> 				  u32 *actions_performed,
>>> 				  struct netlink_ext_ack *extack)
>>> {
>>>-	return 0;
>>>+	*actions_performed = BIT(action);
>>>+	switch (action) {
>>>+	case DEVLINK_RELOAD_ACTION_DRIVER_REINIT:
>>
>>Your driver reinit does not do anything. Please remove it from supported
>>actions.
>
>I want to register reinit action and fastboot param with it, so it work like follow:
>1.devlink param set fastboot 1 driver_reinit
>2.devlink driver_reinit
>3.use space command remove driver, then driver remove function get the fastboot param 
>true, then send message to modem to let modem reboot to fastboot download mode.

What do you mean by this? I don't follow. What's "command remove
driver"?


>4.use space command rescan device, driver probe and export flash port.

Again, what's "command rescan device" ?

Could you perhaps rather use command line examples?


>5.devlink flash firmware image.
>
>if don't suggest use devlink param fastboot driver_reinit, I think set 
>fastboot flag during this action, but Intel colleague Kumar have drop that way in the old 
>v2 patch version.
>https://patchwork.kernel.org/project/netdevbpf/patch/20230105154300.198873-1-m.chetan.kumar@linux.intel.com/ 
>
>>>+	case DEVLINK_RELOAD_ACTION_FW_ACTIVATE:
>>>+		return 0;
>>>+	default:
>>>+		/* Unsupported action should not get to this function */
>>>+		return -EOPNOTSUPP;
>>>+	}
>>>+}
>
>>>+struct devlink_info_req {
>>>+	struct sk_buff *msg;
>>>+	void (*version_cb)(const char *version_name,
>>>+			   enum devlink_info_version_type version_type,
>>>+			   void *version_cb_priv);
>>>+	void *version_cb_priv;
>>>+};
>>
>>Ah! No. Remove this. If you need to touch internal of the struct, this
>>is definitelly not the way to do it.
>
>Thanks for your review, got it.
>
>>>+
>>>+struct devlink_flash_component_lookup_ctx {
>>>+	const char *lookup_name;
>>>+	bool lookup_name_found;
>>>+};
>>
>>Same here.
>
>Thanks for your review, got it.
>
>>>+
>>>+static int t7xx_devlink_info_get_loopback(struct devlink *devlink, struct devlink_info_req *req,
>>>+					  struct netlink_ext_ack *extack)
>>>+{
>>>+	struct devlink_flash_component_lookup_ctx *lookup_ctx = req->version_cb_priv;
>>>+	int ret;
>>>+
>>>+	if (!req)
>>>+		return t7xx_devlink_info_get(devlink, req, extack);
>>>+
>>>+	ret = devlink_info_version_running_put_ext(req, lookup_ctx->lookup_name,
>>
>>It actually took me a while why you are doing this. You try to overcome
>>the limitation for drivers to expose version for all components that are
>>valid for flashing. That is not nice
>>
>>Please don't do things like this!
>>
>>Expose the versions for all valid components, or don't flash them.
>
>For the old modem firmware, it don't support the info_get function, so add the logic here to 
>compatible with old modem firmware update during devlink flash.

No! Don't do this. I don't care about your firmware. We enforce info_get
and flash component parity, obey it. Either provide the version info for
all components you want to flash with proper versions, or don't
implement the flash.


>
>>>+						   "1.0", DEVLINK_INFO_VERSION_TYPE_COMPONENT);
>>>+
>>>+	return ret;
>>> }
>>> 

  reply	other threads:[~2023-08-07  7:35 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20230803021812.6126-1-songjinjian@hotmail.com>
2023-08-03  2:18 ` [net-next 1/6] net: wwan: t7xx: Infrastructure for early port configuration Jinjian Song
2023-08-03  2:18 ` [net-next 2/6] net: wwan: t7xx: Driver registers with Devlink framework Jinjian Song
2023-08-03  9:31   ` Jiri Pirko
2023-08-03  9:59   ` Jiri Pirko
2023-08-05 10:25   ` Jinjian Song
2023-08-05 12:12   ` Jinjian Song
2023-08-07  7:22     ` Jiri Pirko
2023-08-07 12:44     ` Jinjian Song
2023-08-07 12:58       ` Jiri Pirko
2023-08-10 15:19       ` Jinjian Song
2023-08-03  2:18 ` [net-next 3/6] net: wwan: t7xx: Implements devlink ops of firmware flashing Jinjian Song
2023-08-03  9:52   ` Jiri Pirko
2023-08-05 12:05   ` Jinjian Song
2023-08-07  7:35     ` Jiri Pirko [this message]
2023-08-07 12:26     ` Jinjian Song
2023-08-07 13:01       ` Jiri Pirko
2023-08-10 15:32       ` Jinjian Song

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZNCew+BPDITsZdY1@nanopsycho \
    --to=jiri@resnulli.us \
    --cc=chandrashekar.devegowda@intel.com \
    --cc=chiranjeevi.rapolu@linux.intel.com \
    --cc=danielwinkler@google.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=haijun.liu@mediatek.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=jinjian.song@fibocom.com \
    --cc=johannes@sipsolutions.net \
    --cc=kuba@kernel.org \
    --cc=linuxwwan@intel.com \
    --cc=linuxwwan_5g@intel.com \
    --cc=loic.poulain@linaro.org \
    --cc=m.chetan.kumar@linux.intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=ricardo.martinez@linux.intel.com \
    --cc=ryazanov.s.a@gmail.com \
    --cc=songjinjian@hotmail.com \
    --cc=soumya.prakash.mishra@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox