[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091002104010.GA19862@serverengines.com>
Date: Fri, 2 Oct 2009 16:10:12 +0530
From: Ajit Khaparde <ajitk@...verengines.com>
To: Ben Hutchings <bhutchings@...arflare.com>
Cc: David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
linux-net-drivers@...arflare.com
Subject: Re: [RFC][PATCH] ethtool: Add reset operation
On 01/10/09 20:43 +0100, Ben Hutchings wrote:
> After updating firmware stored in flash, users may wish to reset the
> relevant hardware and start the new firmware immediately. This should
> not be completely automatic as it may be disruptive.
>
> A selective reset may also be useful for debugging or diagnostics.
>
> This adds a separate reset operation which takes flags indicating the
> components to be reset. Drivers are allowed to reset only a subset of
> those requested, and must report the actual subset. This allows the
> use of generic component masks and some future expansion.
> ---
Looks good. But one question.
> +static int ethtool_reset(struct net_device *dev, char __user *useraddr)
> +{
> + struct ethtool_value reset;
> + int ret;
> +
> + if (!dev->ethtool_ops->reset)
> + return -EOPNOTSUPP;
> +
> + if (copy_from_user(&reset, useraddr, sizeof(reset)))
> + return -EFAULT;
> +
> + ret = dev->ethtool_ops->reset(dev, &reset.data);
> + if (ret)
> + return ret;
> +
> + if (copy_to_user(useraddr, &reset, sizeof(reset)))
> + return -EFAULT;
Can you tell the intention behind this copy_to_user?
Do you envision drivers sending back some data to the userland - may be
sometime in future?
Thanks
-Ajit
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists