netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Ansuel Smith <ansuelsmth@gmail.com>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [net-next RFC PATCH 0/6] Add support for qca8k mdio rw in Ethernet packet
Date: Wed, 8 Dec 2021 02:35:34 +0100	[thread overview]
Message-ID: <YbAL5pP6IrN1ey5e@lunn.ch> (raw)
In-Reply-To: <20211207231449.bk5mxg3z2o7mmtzg@skbuf>

On Wed, Dec 08, 2021 at 01:14:49AM +0200, Vladimir Oltean wrote:
> On Tue, Dec 07, 2021 at 11:54:07PM +0100, Andrew Lunn wrote:
> > > I considered a simplified form like this, but I think the tagger private
> > > data will still stay in dp->priv, only its ownership will change.
> > 
> > Isn't dp a port structure. So there is one per port?
> 
> Yes, but dp->priv is a pointer. The thing it points to may not
> necessarily be per port.
> 
> > This is where i think we need to separate shared state from tagger
> > private data. Probably tagger private data is not per port. Shared
> > state between the switch driver and the tagger maybe is per port?
> 
> I don't know whether there's such a big difference between
> "shared state" vs "private data"?

The difference is to do with stopping the kernel exploding when the
switch driver is not using the tagger it expects.

Anything which is private to the tagger is not a problem. Only the
tagger uses it, so it cannot be wrong.

Anything which is shared between the tagger and the switch driver we
have to be careful about. We are just passing void * pointers
about. There is no type checking. If i'm correct about the 1:N
relationship, we can store shared state in the tagger. The tagger
should be O.K, because it only ever needs to deal with one format of
shared state. The switch driver needs to handle N different formats of
shared state, depending on which of the N different taggers are in
operation. Ideally, when it asks for the void * pointer for shared
information, some sort of checking is performed to ensure the void *
is what the switch driver actually expects. Maybe it needs to pass the
tag driver it thinks it is talking to, or as well as getting the void
* back, it also gets the tag enum and it verifies it actually knows
about that tag driver.

     Andrew

  reply	other threads:[~2021-12-08  1:35 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-07 14:59 [net-next RFC PATCH 0/6] Add support for qca8k mdio rw in Ethernet packet Ansuel Smith
2021-12-07 14:59 ` [net-next RFC PATCH 1/6] net: dsa: tag_qca: convert to FIELD macro Ansuel Smith
2021-12-07 14:59 ` [net-next RFC PATCH 2/6] net: dsa: tag_qca: move define to include linux/dsa Ansuel Smith
2021-12-07 14:59 ` [net-next RFC PATCH 3/6] net: dsa: tag_qca: add define for mdio read/write in ethernet packet Ansuel Smith
2021-12-07 14:59 ` [net-next RFC PATCH 4/6] net: dsa: qca8k: Add support for mdio read/write in Ethernet packet Ansuel Smith
2021-12-07 14:59 ` [net-next RFC PATCH 5/6] net: dsa: tag_qca: Add support for handling mdio read/write packet Ansuel Smith
2021-12-07 14:59 ` [net-next RFC PATCH 6/6] net: dsa: qca8k: cache lo and hi for mdio write Ansuel Smith
2021-12-07 15:15 ` [net-next RFC PATCH 0/6] Add support for qca8k mdio rw in Ethernet packet Andrew Lunn
2021-12-07 15:33   ` Ansuel Smith
2021-12-07 18:49   ` Florian Fainelli
2021-12-07 19:44     ` Ansuel Smith
2021-12-07 21:10     ` Vladimir Oltean
2021-12-07 22:01       ` Ansuel Smith
2021-12-07 22:37       ` Andrew Lunn
2021-12-07 18:41 ` Andrew Lunn
2021-12-07 18:53   ` Ansuel Smith
2021-12-07 19:15     ` Andrew Lunn
2021-12-07 19:21       ` Ansuel Smith
2021-12-07 20:52         ` Vladimir Oltean
2021-12-07 21:47           ` Ansuel Smith
2021-12-07 22:22             ` Andrew Lunn
2021-12-07 22:30               ` Ansuel Smith
2021-12-07 22:46                 ` Andrew Lunn
2021-12-07 23:47               ` Vladimir Oltean
2021-12-08  0:04                 ` Vladimir Oltean
2021-12-08  0:40                   ` Vladimir Oltean
2021-12-08  0:42                     ` Ansuel Smith
2021-12-08  1:09                       ` Vladimir Oltean
2021-12-08  3:32                         ` Ansuel Smith
2021-12-08 11:54                           ` Vladimir Oltean
2021-12-08  1:15                 ` Andrew Lunn
2021-12-07 22:45             ` Vladimir Oltean
2021-12-07 22:54               ` Andrew Lunn
2021-12-07 23:14                 ` Vladimir Oltean
2021-12-08  1:35                   ` Andrew Lunn [this message]
2021-12-08  3:39                     ` Ansuel Smith
2021-12-08 11:51                     ` Vladimir Oltean
2021-12-07 23:05               ` Ansuel Smith
2021-12-07 23:20                 ` Vladimir Oltean
2021-12-07 23:24                   ` Ansuel Smith

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=YbAL5pP6IrN1ey5e@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=ansuelsmth@gmail.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=vivien.didelot@gmail.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;
as well as URLs for NNTP newsgroup(s).