All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Pirko <jiri@resnulli.us>
To: Michal Kubecek <mkubecek@suse.cz>
Cc: netdev@vger.kernel.org,
	Jakub Kicinski <jakub.kicinski@netronome.com>,
	davem@davemloft.net, oss-drivers@netronome.com, andrew@lunn.ch
Subject: Re: [PATCH net-next 2/3] ethtool: add compat for flash update
Date: Fri, 15 Feb 2019 11:17:13 +0100	[thread overview]
Message-ID: <20190215101713.GE2343@nanopsycho> (raw)
In-Reply-To: <20190215085315.GL25518@unicorn.suse.cz>

Fri, Feb 15, 2019 at 09:53:15AM CET, mkubecek@suse.cz wrote:
>On Thu, Feb 14, 2019 at 01:40:45PM -0800, Jakub Kicinski wrote:
>> If driver does not support ethtool flash update operation
>> call into devlink.
>> 
>> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>> ---
>...
>> diff --git a/net/core/devlink.c b/net/core/devlink.c
>> index bd507e13bb7b..d169b5426d3d 100644
>> --- a/net/core/devlink.c
>> +++ b/net/core/devlink.c
>> @@ -6435,6 +6435,36 @@ void devlink_compat_running_version(struct net_device *dev,
>>  	mutex_unlock(&devlink_mutex);
>>  }
>>  
>> +int devlink_compat_flash_update(struct net_device *dev, const char *file_name)
>> +{
>> +	struct devlink_port *devlink_port;
>> +	struct devlink *devlink;
>> +
>> +	mutex_lock(&devlink_mutex);
>> +	list_for_each_entry(devlink, &devlink_list, list) {
>> +		mutex_lock(&devlink->lock);
>> +		list_for_each_entry(devlink_port, &devlink->port_list, list) {
>> +			int ret = -EOPNOTSUPP;
>> +
>> +			if (devlink_port->type != DEVLINK_PORT_TYPE_ETH ||
>> +			    devlink_port->type_dev != dev)
>> +				continue;
>> +
>> +			mutex_unlock(&devlink_mutex);
>> +			if (devlink->ops->flash_update)
>> +				ret = devlink->ops->flash_update(devlink,
>> +								 file_name,
>> +								 NULL, NULL);
>> +			mutex_unlock(&devlink->lock);
>> +			return ret;
>> +		}
>> +		mutex_unlock(&devlink->lock);
>> +	}
>> +	mutex_unlock(&devlink_mutex);
>> +
>> +	return -EOPNOTSUPP;
>> +}
>> +
>>  static int __init devlink_module_init(void)
>>  {
>>  	return genl_register_family(&devlink_nl_family);
>
>We already have similar lookup in devlink_compat_running_version() (the
>only difference seems to be that we keep holding devlink_mutex until the
>end there) and it's likely the net_device -> devlink lookup will be
>needed in more places in the future. How about having a helper for it?
>
>I also wonder how does the lookup scale. But I don't have clear idea
>how long the lists can become in real life and the ethtool operations
>are not really time critical.

Another thing is, that you don't really have to do the lookup. If you
have struct net_device *dev inside the driver, you can get the devlink
instance according to that. So it is just a matter of another ndo I
guess.


>
>Michal Kubecek

  reply	other threads:[~2019-02-15 10:26 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-14 21:40 [PATCH net-next 0/3] devlink: add the ability to update device flash Jakub Kicinski
2019-02-14 21:40 ` [PATCH net-next 1/3] devlink: add flash update command Jakub Kicinski
2019-02-15 10:10   ` Jiri Pirko
2019-02-14 21:40 ` [PATCH net-next 2/3] ethtool: add compat for flash update Jakub Kicinski
2019-02-15  8:53   ` Michal Kubecek
2019-02-15 10:17     ` Jiri Pirko [this message]
2019-02-15 15:51       ` Jakub Kicinski
2019-02-15 10:12   ` Jiri Pirko
2019-02-14 21:40 ` [PATCH net-next 3/3] nfp: devlink: allow flashing the device via devlink Jakub Kicinski
2019-02-15 10:15   ` Jiri Pirko
2019-02-15 15:44     ` Jakub Kicinski
2019-02-19  9:19       ` Jiri Pirko
2019-02-20  0:49         ` Jakub Kicinski
2019-02-20  8:37           ` Jiri Pirko
2019-02-21  2:59           ` Florian Fainelli
2019-02-21  3:20             ` Jakub Kicinski
2019-02-21  7:00             ` Jiri Pirko
2019-02-21  7:17             ` Michal Kubecek
2019-02-15 10:26   ` Michal Kubecek
2019-02-17 23:28 ` [PATCH net-next 0/3] devlink: add the ability to update device flash David Miller

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=20190215101713.GE2343@nanopsycho \
    --to=jiri@resnulli.us \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=jakub.kicinski@netronome.com \
    --cc=mkubecek@suse.cz \
    --cc=netdev@vger.kernel.org \
    --cc=oss-drivers@netronome.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.