Netdev Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Luiz Angelo Daros de Luca <luizluca@gmail.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: "open list:NETWORKING DRIVERS" <netdev@vger.kernel.org>,
"Linus Walleij" <linus.walleij@linaro.org>,
"Andrew Lunn" <andrew@lunn.ch>,
"Vivien Didelot" <vivien.didelot@gmail.com>,
"Vladimir Oltean" <olteanv@gmail.com>,
"Alvin Šipraga" <alsi@bang-olufsen.dk>,
"Arınç ÜNAL" <arinc.unal@arinc9.com>,
"Frank Wunderlich" <frank-w@public-files.de>
Subject: Re: [PATCH net-next v4 05/11] net: dsa: realtek: use phy_read in ds->ops
Date: Mon, 17 Jan 2022 23:55:50 -0300 [thread overview]
Message-ID: <CAJq09z4U5qmBuPUqBnGpT+qcG-vmtFwNMg5Uau3q3F53W-0YDA@mail.gmail.com> (raw)
In-Reply-To: <79a9c7c2-9bd0-d5d1-6d5a-d505cdc564be@gmail.com>
> On 1/4/2022 7:15 PM, Luiz Angelo Daros de Luca wrote:
> > The ds->ops->phy_read will only be used if the ds->slave_mii_bus
> > was not initialized. Calling realtek_smi_setup_mdio will create a
> > ds->slave_mii_bus, making ds->ops->phy_read dormant.
> >
> > Using ds->ops->phy_read will allow switches connected through non-SMI
> > interfaces (like mdio) to let ds allocate slave_mii_bus and reuse the
> > same code.
> >
> > Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
> > Tested-by: Arınç ÜNAL <arinc.unal@arinc9.com>
> > Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>
> Humm assigning dsa_switch_ops::phy_read will force DSA into tearing down
> the MDIO bus in dsa_switch_teardown() instead of letting your driver do
> it and since realtek-smi-core.c uses devm_mdiobus_unregister(), it is
> not clear to me what is going to happen but it sounds like a double free
> might happen?
Thanks, Florian. You should be correct. It might call
mdiobus_unregister() and mdiobus_free() twice, once inside the dsa
code and another one by the devm (if I understood how devm functions
work).
The issue is that the dsa switch is assuming that if slave_mii is
allocated and ds->ops->phy_read is defined, it has allocated the
slave_mii by itself and it should clean up the slave_mii during
teardown.
That assumption came from commit
5135e96a3dd2f4555ae6981c3155a62bcf3227f6 "So I can only guess that no
driver that implements ds->ops->phy_read also allocates and registers
ds->slave_mii_bus itself.". If that is true, the condition during
dsa_switch_setup() is not correct.
During dsa_switch_setup(), if it does not fail, I know that
ds->slave_mii_bus will be allocated, either by ds->ops->setup() or by
itself.
dsa_switch_setup() {
....
ds->ops->setup()
....
if (!ds->slave_mii_bus && ds->ops->phy_read) {
...allocate and register ds->slave_mii_bus...
}
}
During the teardown, ds->slave_mii_bus will always be true (if not
cleaning from an error before it was allocated). So, the test is
really about having ds->ops->phy_read.
dsa_switch_teardown() {
...
if (ds->slave_mii_bus && ds->ops->phy_read) {
...unregister and free ds->slave_mii_bus...
}
...
ds->ops->teardown();
...
}
As ds->ops->teardown() is called after slave_mii_bus is gone, there is
no opportunity for ds->ops to clean the mii_slave_bus it might have
allocated.
It does not make sense for me to have those two "if" conditions
working together. It should be either:
dsa_switch_setup() {
....
ds->ops->setup()
....
if (ds->ops->phy_read) {
if (ds->slave_mii_bus)
error("ds->ops->phy_read is set, I should be the
one allocating ds->slave_mii_bus!")
...allocate and register ds->slave_mii_bus...
}
}
if "no driver that implements ds->ops->phy_read also allocates and
registers ds->slave_mii_bus itself" or:
dsa_switch_teardown() {
...
if (ds->slave_mii_bus && "slave_mii_bus was allocated by myself") {
...unregister and free ds->slave_mii_bus...
}
ds->ops->teardown();
...
}
if ds->ops->phy_read value should not tell if ds->slave_mii_bus should
be cleaned by the DSA switch.
I would selfishly hope the correct one was the second option because
it would make my code much cleaner. If not, that's a complex issue to
solve without lots of duplications: realtek-smi drivers should not
have ds->ops->phy_read defined while realtek-mdio requires it. I'll
need to duplicate dsa_switch_ops for each subdriver only to unset
phy_read and also duplicate realtek_variant for each interface only to
reference that different dsa_switch_ops.
BTW, the realtek-smi calls
of_node_put(priv->slave_mii_bus->dev.of_node) during shutdown while
other dsa drivers do not seem to care. Wouldn't devm controls be
enough for cleaning that mii_bus?
Even if not, wouldn't the ds->ops->teardown be the correct place for
that cleanup and not realtek_smi_remove()?
> It seems more prudent to me to leave existing code.
As I mentioned, It would require a good amount of duplications. But
I'll do what needs to be done.
Regards,
Luiz
next prev parent reply other threads:[~2022-01-18 3:53 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-05 3:15 [PATCH net-next v4 00/11] net: dsa: realtek: MDIO interface and RTL8367S Luiz Angelo Daros de Luca
2022-01-05 3:15 ` [PATCH net-next v4 01/11] net: dsa: realtek-smi: move to subdirectory Luiz Angelo Daros de Luca
2022-01-05 3:15 ` [PATCH net-next v4 02/11] net: dsa: realtek: rename realtek_smi to realtek_priv Luiz Angelo Daros de Luca
2022-01-07 3:42 ` Jakub Kicinski
2022-01-10 12:33 ` Alvin Šipraga
2022-01-16 0:04 ` Linus Walleij
2022-01-20 14:37 ` Vladimir Oltean
2022-01-05 3:15 ` [PATCH net-next v4 03/11] net: dsa: realtek: remove direct calls to realtek-smi Luiz Angelo Daros de Luca
2022-01-10 12:38 ` Alvin Šipraga
2022-01-16 0:05 ` Linus Walleij
2022-01-17 3:46 ` Florian Fainelli
2022-01-05 3:15 ` [PATCH net-next v4 04/11] net: dsa: realtek: convert subdrivers into modules Luiz Angelo Daros de Luca
2022-01-10 12:43 ` Alvin Šipraga
2022-01-17 4:02 ` Florian Fainelli
2022-01-05 3:15 ` [PATCH net-next v4 05/11] net: dsa: realtek: use phy_read in ds->ops Luiz Angelo Daros de Luca
2022-01-10 13:09 ` Alvin Šipraga
2022-01-17 4:15 ` Florian Fainelli
2022-01-18 2:55 ` Luiz Angelo Daros de Luca [this message]
2022-01-18 13:16 ` Andrew Lunn
2022-01-21 22:13 ` Luiz Angelo Daros de Luca
2022-01-21 23:48 ` Andrew Lunn
2022-01-05 3:15 ` [PATCH net-next v4 06/11] net: dsa: realtek: add new mdio interface for drivers Luiz Angelo Daros de Luca
2022-01-10 13:09 ` Alvin Šipraga
2022-01-17 4:22 ` Florian Fainelli
2022-01-18 4:38 ` Luiz Angelo Daros de Luca
2022-01-05 3:15 ` [PATCH net-next v4 07/11] net: dsa: realtek: rtl8365mb: rename extport to extint, add "realtek,ext-int" Luiz Angelo Daros de Luca
2022-01-10 13:15 ` Alvin Šipraga
2022-01-17 4:25 ` Florian Fainelli
2022-01-05 3:15 ` [PATCH net-next v4 08/11] net: dsa: realtek: rtl8365mb: use GENMASK(n-1,0) instead of BIT(n)-1 Luiz Angelo Daros de Luca
2022-01-10 13:18 ` Alvin Šipraga
2022-01-17 4:25 ` Florian Fainelli
2022-01-05 3:15 ` [PATCH net-next v4 09/11] net: dsa: realtek: rtl8365mb: use DSA CPU port Luiz Angelo Daros de Luca
2022-01-07 3:37 ` Jakub Kicinski
2022-01-10 13:22 ` Alvin Šipraga
2022-01-17 4:26 ` Florian Fainelli
2022-01-05 3:15 ` [PATCH net-next v4 10/11] net: dsa: realtek: rtl8365mb: add RTL8367S support Luiz Angelo Daros de Luca
2022-01-10 13:26 ` Alvin Šipraga
2022-01-17 4:26 ` Florian Fainelli
2022-01-05 3:15 ` [PATCH net-next v4 11/11] net: dsa: realtek: rtl8365mb: multiple cpu ports, non cpu extint Luiz Angelo Daros de Luca
2022-01-10 13:39 ` Alvin Šipraga
2022-01-10 13:53 ` Aw: " Frank Wunderlich
2022-01-11 18:17 ` Alvin Šipraga
2022-01-11 18:45 ` Aw: " Frank Wunderlich
2022-01-13 12:37 ` Alvin Šipraga
2022-01-13 15:56 ` Aw: " Frank Wunderlich
2022-01-18 4:58 ` Luiz Angelo Daros de Luca
2022-01-18 10:13 ` Alvin Šipraga
2022-01-18 13:20 ` Re: Re: " Andrew Lunn
2022-01-20 15:12 ` Vladimir Oltean
2022-01-20 23:35 ` Luiz Angelo Daros de Luca
2022-01-21 2:06 ` Vladimir Oltean
2022-01-21 3:13 ` Luiz Angelo Daros de Luca
2022-01-21 3:22 ` Florian Fainelli
2022-01-21 3:42 ` Luiz Angelo Daros de Luca
2022-01-21 3:50 ` Florian Fainelli
2022-01-21 4:37 ` Luiz Angelo Daros de Luca
2022-01-21 9:07 ` Arınç ÜNAL
2022-01-21 18:50 ` Vladimir Oltean
2022-01-21 21:51 ` Luiz Angelo Daros de Luca
2022-01-21 22:49 ` Vladimir Oltean
2022-01-22 20:12 ` Luiz Angelo Daros de Luca
2022-01-24 15:31 ` Vladimir Oltean
2022-01-24 16:46 ` Jakub Kicinski
2022-01-24 16:55 ` Vladimir Oltean
2022-01-24 17:01 ` Florian Fainelli
2022-01-24 17:21 ` Vladimir Oltean
2022-01-24 17:30 ` Florian Fainelli
2022-01-24 17:35 ` Jakub Kicinski
2022-01-24 18:20 ` Jakub Kicinski
2022-01-24 19:08 ` Vladimir Oltean
2022-01-24 19:38 ` Jakub Kicinski
2022-01-24 20:56 ` Vladimir Oltean
2022-01-24 21:42 ` Jakub Kicinski
2022-01-24 22:30 ` Vladimir Oltean
2022-01-25 7:15 ` Luiz Angelo Daros de Luca
2022-01-25 9:47 ` Vladimir Oltean
2022-01-25 22:29 ` Luiz Angelo Daros de Luca
2022-01-25 23:56 ` Florian Fainelli
2022-01-26 22:49 ` Luiz Angelo Daros de Luca
2022-01-25 9:44 ` Arınç ÜNAL
2022-01-22 15:51 ` Andrew Lunn
2022-01-30 1:54 ` Re: Re: " Luiz Angelo Daros de Luca
2022-01-30 4:42 ` Luiz Angelo Daros de Luca
2022-01-30 17:24 ` Florian Fainelli
2022-01-31 17:26 ` Luiz Angelo Daros de Luca
2022-02-01 14:46 ` Vladimir Oltean
2022-01-20 14:36 ` [PATCH net-next v4 00/11] net: dsa: realtek: MDIO interface and RTL8367S Vladimir Oltean
2022-01-20 17:46 ` 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=CAJq09z4U5qmBuPUqBnGpT+qcG-vmtFwNMg5Uau3q3F53W-0YDA@mail.gmail.com \
--to=luizluca@gmail.com \
--cc=alsi@bang-olufsen.dk \
--cc=andrew@lunn.ch \
--cc=arinc.unal@arinc9.com \
--cc=f.fainelli@gmail.com \
--cc=frank-w@public-files.de \
--cc=linus.walleij@linaro.org \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=vivien.didelot@gmail.com \
--subject='Re: [PATCH net-next v4 05/11] net: dsa: realtek: use phy_read in ds->ops' \
/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
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).