Linux-Renesas-SoC Archive on lore.kernel.org
 help / color / Atom feed
From: David Miller <davem@davemloft.net>
To: uli+renesas@fpond.eu
Cc: linux-renesas-soc@vger.kernel.org, netdev@vger.kernel.org,
	sergei.shtylyov@cogentembedded.com,
	niklas.soderlund@ragnatech.se, wsa@the-dreams.de,
	horms@verge.net.au, magnus.damm@gmail.com
Subject: Re: [PATCH v2] ravb: implement MTU change while device is up
Date: Wed, 05 Jun 2019 19:08:25 -0700 (PDT)
Message-ID: <20190605.190825.2245741686094611389.davem@davemloft.net> (raw)
In-Reply-To: <1559747660-17875-1-git-send-email-uli+renesas@fpond.eu>

From: Ulrich Hecht <uli+renesas@fpond.eu>
Date: Wed,  5 Jun 2019 17:14:20 +0200

> @@ -1811,11 +1811,14 @@ static int ravb_do_ioctl(struct net_device *ndev, struct ifreq *req, int cmd)
>  static int ravb_change_mtu(struct net_device *ndev, int new_mtu)
>  {
>  	if (netif_running(ndev))
> -		return -EBUSY;
> +		ravb_close(ndev);
>  
>  	ndev->mtu = new_mtu;
>  	netdev_update_features(ndev);
>  
> +	if (netif_running(ndev))
> +		return ravb_open(ndev);
> +

And if ravb_open() fails?  The user sees a failure, but to the user the failure
means the MTU change can't be done, yet the device has the new MTU set still.

This really is terrible behavior.

If you must do a prepare/commit kind of sequence for this to work properly if
you are going to go down the road of taking the device down to change the MTU
when the device is UP.

  parent reply index

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-05 15:14 Ulrich Hecht
2019-06-05 15:16 ` Geert Uytterhoeven
2019-06-05 17:27 ` Sergei Shtylyov
2019-06-06  2:08 ` David Miller [this message]
2019-06-14 15:28   ` Ulrich Hecht

Reply instructions:

You may reply publically 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=20190605.190825.2245741686094611389.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=horms@verge.net.au \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=niklas.soderlund@ragnatech.se \
    --cc=sergei.shtylyov@cogentembedded.com \
    --cc=uli+renesas@fpond.eu \
    --cc=wsa@the-dreams.de \
    /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

Linux-Renesas-SoC Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-renesas-soc/0 linux-renesas-soc/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-renesas-soc linux-renesas-soc/ https://lore.kernel.org/linux-renesas-soc \
		linux-renesas-soc@vger.kernel.org linux-renesas-soc@archiver.kernel.org
	public-inbox-index linux-renesas-soc


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-renesas-soc


AGPL code for this site: git clone https://public-inbox.org/ public-inbox