From: Christian Marangi <ansuelsmth@gmail.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
Vivien Didelot <vivien.didelot@gmail.com>,
Florian Fainelli <f.fainelli@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Russell King <linux@armlinux.org.uk>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jens Axboe <axboe@kernel.dk>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [net-next RFC PATCH 1/4] net: dsa: qca8k: drop qca8k_read/write/rmw for regmap variant
Date: Tue, 19 Jul 2022 01:32:26 +0200 [thread overview]
Message-ID: <62d5f18e.1c69fb81.35e7.46fe@mx.google.com> (raw)
In-Reply-To: <20220718234358.27zv5ogeuvgmaud4@skbuf>
On Tue, Jul 19, 2022 at 02:43:58AM +0300, Vladimir Oltean wrote:
> On Mon, Jul 18, 2022 at 11:54:44PM +0200, Christian Marangi wrote:
> > On Mon, Jul 18, 2022 at 11:30:42PM +0300, Vladimir Oltean wrote:
> > > On Mon, Jul 18, 2022 at 09:30:58PM +0200, Christian Marangi wrote:
> > > > Tell me if I got this wrong.
> > > >
> > > > The suggestion was to move the struct dsa_switch_ops to qca8k.h and add
> > > > in the specific code probe the needed ops to add to the generic
> > > > struct...
> > >
> > > The declaration yes; the definition to qca8k-common.c. See for example
> > > where felix_switch_ops is, relative to felix_vsc9959.c, seville_vsc9953.c
> > > (users), felix.h (declaration), and felix.c (definition). Or how
> > > mv88e6xxx_switch_ops does things and still supports a gazillion of switches.
> >
> > Mhh I checked the example and they doesn't seems to be useful from my
> > problem. But I think it's better to discuss this to the patch directly
> > so you can better understand whay I intended with having dsa_switch_ops
> > set to const.
>
> So you don't modify the common dsa_switch_ops from the switch-specific
> probe path, but rather, from the common dsa_switch_ops method, you call
> a second function pointer.
>
> static void felix_phylink_validate(struct dsa_switch *ds, int port,
> unsigned long *supported,
> struct phylink_link_state *state)
> {
> struct ocelot *ocelot = ds->priv;
> struct felix *felix = ocelot_to_felix(ocelot);
>
> if (felix->info->phylink_validate)
> felix->info->phylink_validate(ocelot, port, supported, state);
> }
Ohhh ok now it makes sense.
If the ops is not supported should I return -ENOSUPP?
Example some ops won't be supported like the get_phy_flags or
connect_tag_protocol for example.
Anyway the series is ready, I was just pushing it... At the end it's 23
patch big... (I know you will hate me but at least it's reviewable)
My solution currently was this...
ops = devm_kzalloc(&mdiodev->dev, sizeof(*ops), GFP_KERNEL);
if (!ops)
return -ENOMEM;
/* Copy common ops */
memcpy(ops, &qca8k_switch_ops, sizeof(*ops));
/* Setup specific ops */
ops->get_tag_protocol = qca8k_get_tag_protocol;
ops->setup = qca8k_setup;
ops->phylink_get_caps = qca8k_phylink_get_caps;
ops->phylink_mac_select_pcs = qca8k_phylink_mac_select_pcs;
ops->phylink_mac_config = qca8k_phylink_mac_config;
ops->phylink_mac_link_down = qca8k_phylink_mac_link_down;
ops->phylink_mac_link_up = qca8k_phylink_mac_link_up;
ops->get_phy_flags = qca8k_get_phy_flags;
ops->master_state_change = qca8k_master_change;
ops->connect_tag_protocol = qca8k_connect_tag_protocol;
/* Assign the final ops */
priv->ds->ops = ops;
Will wait your response on how to hanle ops that are not supported.
(I assume dsa checks if an ops is declared and not if it does return
ENOSUPP, so this is my concern your example)
--
Ansuel
next prev parent reply other threads:[~2022-07-18 23:49 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-16 17:49 [net-next RFC PATCH 0/4] net: dsa: qca8k: code split for qca8k Christian Marangi
2022-07-16 17:49 ` [net-next RFC PATCH 1/4] net: dsa: qca8k: drop qca8k_read/write/rmw for regmap variant Christian Marangi
2022-07-18 18:04 ` Vladimir Oltean
2022-07-18 17:55 ` Christian Marangi
2022-07-18 18:40 ` Vladimir Oltean
2022-07-18 18:40 ` Christian Marangi
2022-07-18 19:35 ` Vladimir Oltean
2022-07-18 19:30 ` Christian Marangi
2022-07-18 20:30 ` Vladimir Oltean
2022-07-18 21:54 ` Christian Marangi
2022-07-18 23:43 ` Vladimir Oltean
2022-07-18 23:32 ` Christian Marangi [this message]
2022-07-19 0:18 ` Vladimir Oltean
2022-07-19 0:17 ` Christian Marangi
2022-07-19 0:41 ` Vladimir Oltean
2022-07-16 17:49 ` [net-next RFC PATCH 2/4] net: dsa: qca8k: convert to regmap read/write API Christian Marangi
2022-07-16 17:49 ` [net-next RFC PATCH 3/4] net: dsa: qca8k: rework mib autocast handling Christian Marangi
2022-07-18 17:27 ` Vladimir Oltean
2022-07-18 17:20 ` Christian Marangi
2022-07-18 17:58 ` Vladimir Oltean
2022-07-16 17:49 ` [net-next RFC PATCH 4/4] net: dsa: qca8k: split qca8k in common and 8xxx specific code Christian Marangi
2022-07-18 17:21 ` Vladimir Oltean
2022-07-18 17:10 ` Christian Marangi
2022-07-18 17:38 ` Vladimir Oltean
2022-07-18 14:46 ` [net-next RFC PATCH 0/4] net: dsa: qca8k: code split for qca8k Christian Marangi
2022-07-18 17:35 ` Vladimir Oltean
2022-07-18 17:23 ` Christian Marangi
2022-07-18 18:15 ` Vladimir Oltean
2022-07-18 18:02 ` Christian Marangi
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=62d5f18e.1c69fb81.35e7.46fe@mx.google.com \
--to=ansuelsmth@gmail.com \
--cc=andrew@lunn.ch \
--cc=axboe@kernel.dk \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.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