public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Luiz Angelo Daros de Luca <luizluca@gmail.com>,
	netdev@vger.kernel.org, linus.walleij@linaro.org,
	alsi@bang-olufsen.dk, andrew@lunn.ch, davem@davemloft.net,
	edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
	arinc.unal@arinc9.com, ansuelsmth@gmail.com
Subject: Re: [PATCH net-next v4 08/11] net: dsa: realtek: clean user_mii_bus setup
Date: Mon, 29 Jan 2024 18:43:49 +0200	[thread overview]
Message-ID: <20240129164349.rcuj5hvmoqtzsuxr@skbuf> (raw)
In-Reply-To: <95752e6d-82da-4cd3-b162-4fb88d7ffd13@gmail.com>

On Mon, Jan 29, 2024 at 08:22:47AM -0800, Florian Fainelli wrote:
> It does seem however universally acceptable to stop any DMAs and
> packets from flowing as a default and safe implementation to the
> upstream kernel.

DMA I can understand, because you wouldn't want the hardware to notify
you of a buffer you have no idea about. But DSA doesn't assume that
switches have DMA, and generally speaking, stopping the offloaded
traffic path seems unnecessary. It will be stopped when the new kernel
sets up the interfaces as standalone, renegotiates the link, etc.

  reply	other threads:[~2024-01-29 16:43 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-23 21:55 [PATCH net-next v4 00/11] net: dsa: realtek: variants to drivers, interfaces to a common module Luiz Angelo Daros de Luca
2024-01-23 21:55 ` [PATCH net-next v4 01/11] net: dsa: realtek: drop cleanup from realtek_ops Luiz Angelo Daros de Luca
2024-01-23 21:55 ` [PATCH net-next v4 02/11] net: dsa: realtek: introduce REALTEK_DSA namespace Luiz Angelo Daros de Luca
2024-01-25 10:02   ` Vladimir Oltean
2024-01-29 16:09   ` Florian Fainelli
2024-01-23 21:55 ` [PATCH net-next v4 03/11] net: dsa: realtek: convert variants into real drivers Luiz Angelo Daros de Luca
2024-01-24 19:19   ` Jakub Kicinski
2024-01-25 10:25   ` Vladimir Oltean
2024-01-28 23:34     ` Luiz Angelo Daros de Luca
2024-01-29 16:21       ` Vladimir Oltean
2024-01-23 21:55 ` [PATCH net-next v4 04/11] net: dsa: realtek: keep variant reference in realtek_priv Luiz Angelo Daros de Luca
2024-01-25 10:26   ` Vladimir Oltean
2024-01-29 16:10   ` Florian Fainelli
2024-01-29 17:36     ` Luiz Angelo Daros de Luca
2024-01-23 21:55 ` [PATCH net-next v4 05/11] net: dsa: realtek: common rtl83xx module Luiz Angelo Daros de Luca
2024-01-25 10:45   ` Vladimir Oltean
2024-01-29  0:09     ` Luiz Angelo Daros de Luca
2024-01-29 16:18       ` Vladimir Oltean
2024-01-26 23:19   ` kernel test robot
2024-01-23 21:55 ` [PATCH net-next v4 06/11] net: dsa: realtek: merge rtl83xx and interface modules into realtek-dsa Luiz Angelo Daros de Luca
2024-01-25 11:00   ` Vladimir Oltean
2024-01-29 16:13   ` Florian Fainelli
2024-01-23 21:55 ` [PATCH net-next v4 07/11] net: dsa: realtek: get internal MDIO node by name Luiz Angelo Daros de Luca
2024-01-29 16:11   ` Florian Fainelli
2024-01-23 21:56 ` [PATCH net-next v4 08/11] net: dsa: realtek: clean user_mii_bus setup Luiz Angelo Daros de Luca
2024-01-25 11:17   ` Vladimir Oltean
2024-01-29  2:12     ` Luiz Angelo Daros de Luca
2024-01-29 16:15       ` Vladimir Oltean
2024-01-29 16:22         ` Florian Fainelli
2024-01-29 16:43           ` Vladimir Oltean [this message]
2024-01-29 16:54             ` Florian Fainelli
2024-01-30 14:40           ` Arınç ÜNAL
2024-01-30 15:02             ` Andrew Lunn
2024-01-30 18:17               ` Luiz Angelo Daros de Luca
2024-01-23 21:56 ` [PATCH net-next v4 09/11] net: dsa: realtek: migrate user_mii_bus setup to realtek-dsa Luiz Angelo Daros de Luca
2024-01-25 16:05   ` Vladimir Oltean
2024-01-29  2:49     ` Luiz Angelo Daros de Luca
2024-01-29 15:19       ` Vladimir Oltean
2024-01-23 21:56 ` [PATCH net-next v4 10/11] net: dsa: realtek: use the same mii bus driver for both interfaces Luiz Angelo Daros de Luca
2024-01-23 21:56 ` [PATCH net-next v4 11/11] net: dsa: realtek: embed dsa_switch into realtek_priv Luiz Angelo Daros de Luca

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=20240129164349.rcuj5hvmoqtzsuxr@skbuf \
    --to=olteanv@gmail.com \
    --cc=alsi@bang-olufsen.dk \
    --cc=andrew@lunn.ch \
    --cc=ansuelsmth@gmail.com \
    --cc=arinc.unal@arinc9.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=luizluca@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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