From: "Russell King (Oracle)" <linux@armlinux•org.uk>
To: Andy Shevchenko <andriy.shevchenko@linux•intel.com>
Cc: "Vladimir Oltean" <olteanv@gmail•com>,
"Andrew Lunn" <andrew@lunn•ch>,
"Heiner Kallweit" <hkallweit1@gmail•com>,
"Alexandre Belloni" <alexandre.belloni@bootlin•com>,
"Alvin __ipraga" <alsi@bang-olufsen•dk>,
"Claudiu Manoil" <claudiu.manoil@nxp•com>,
"Daniel Scally" <djrscally@gmail•com>,
"David S. Miller" <davem@davemloft•net>,
"DENG Qingfang" <dqfext@gmail•com>,
"Eric Dumazet" <edumazet@google•com>,
"Florian Fainelli" <f.fainelli@gmail•com>,
"George McCollister" <george.mccollister@gmail•com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation•org>,
"Hauke Mehrtens" <hauke@hauke-m•de>,
"Heikki Krogerus" <heikki.krogerus@linux•intel.com>,
"Jakub Kicinski" <kuba@kernel•org>,
"Kurt Kanzenbach" <kurt@linutronix•de>,
"Landen Chao" <Landen.Chao@mediatek•com>,
"Linus Walleij" <linus.walleij@linaro•org>,
linux-acpi@vger•kernel.org, linux-arm-kernel@lists•infradead.org,
linux-mediatek@lists•infradead.org,
"Matthias Brugger" <matthias.bgg@gmail•com>,
netdev@vger•kernel.org, "Paolo Abeni" <pabeni@redhat•com>,
"Rafael J. Wysocki" <rafael@kernel•org>,
"Sakari Ailus" <sakari.ailus@linux•intel.com>,
"Sean Wang" <sean.wang@mediatek•com>,
UNGLinuxDriver@microchip•com,
"Vivien Didelot" <vivien.didelot@gmail•com>,
"Woojung Huh" <woojung.huh@microchip•com>,
"Marek Behún" <kabel@kernel•org>
Subject: Re: [PATCH net-next 2/6] software node: allow named software node to be created
Date: Mon, 18 Jul 2022 20:14:58 +0100 [thread overview]
Message-ID: <YtWxMrz3LcVQa43I@shell.armlinux.org.uk> (raw)
In-Reply-To: <YtWsM1nr2GZWDiEN@smile.fi.intel.com>
On Mon, Jul 18, 2022 at 09:53:39PM +0300, Andy Shevchenko wrote:
> On Mon, Jul 18, 2022 at 09:43:42PM +0300, Andy Shevchenko wrote:
> > On Mon, Jul 18, 2022 at 02:27:02PM +0100, Russell King (Oracle) wrote:
> > > On Mon, Jul 18, 2022 at 03:29:52PM +0300, Andy Shevchenko wrote:
> > > > On Fri, Jul 15, 2022 at 11:48:41PM +0300, Vladimir Oltean wrote:
> > > > > So won't kobject_init_and_add() fail on namespace collision? Is it the
> > > > > problem that it's going to fail, or that it's not trivial to statically
> > > > > determine whether it'll fail?
> > > > >
> > > > > Sorry, but I don't see something actionable about this.
> > > >
> > > > I'm talking about validation before a runtime. But if you think that is fine,
> > > > let's fail it at runtime, okay, and consume more backtraces in the future.
> > >
> > > Is there any sane way to do validation of this namespace before
> > > runtime?
> >
> > For statically compiled, I think we can do it (to some extent).
> > Currently only three drivers, if I'm not mistaken, define software nodes with
> > names. It's easy to check that their node names are unique.
> >
> > When you allow such an API then we might have tracebacks (from sysfs) bout name
> > collisions. Not that is something new to kernel (we have seen many of a kind),
> > but I prefer, if possible, to validate this before sysfs issues a traceback.
> >
> > > The problem in this instance is we need a node named "fixed-link" that
> > > is attached to the parent node as that is defined in the binding doc,
> > > and we're creating swnodes to provide software generated nodes for
> > > this binding.
> >
> > And how you guarantee that it will be only a single one with unique pathname?
> >
> > For example, you have two DSA cards (or whatever it's called) in the SMP system,
> > it mean that there is non-zero probability of coexisting swnodes for them.
> >
> > > There could be several such nodes scattered around, but in this
> > > instance they are very short-lived before they are destroyed, they
> > > don't even need to be published to userspace (and its probably a waste
> > > of CPU cycles for them to be published there.)
> > >
> > > So, for this specific case, is this the best approach, or is there
> > > some better way to achieve what we need here?
> >
> > Honestly, I don't know.
> >
> > The "workaround" (but it looks to me rather a hack) is to create unique swnode
> > and make fixed-link as a child of it.
> >
> > Or entire concept of the root swnodes (when name is provided) should be
> > reconsidered, so somehow we will have a uniqueness so that the entire
> > path(s) behind it will be caller-dependent. But this I also don't like.
> >
> > Maybe Heikki, Sakari, Rafael can share their thoughts...
> >
> > Just for my learning, why PHY uses "fixed-link" instead of relying on a
> > (firmware) graph? It might be the actual solution to your problem.
> >
> > How graphs are used with swnodes, you may look into IPU3 (Intel Camera)
> > glue driver to support devices before MIPI standardisation of the
> > respective properties.
>
> Forgot to say (yes, it maybe obvious) that this API will be exported,
> anyone can use it and trap into the similar issue, because, for example,
> of testing in environment with a single instance of the caller.
I think we're coming to the conclusion that using swnodes is not the
correct approach for this problem, correct?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2022-07-18 19:15 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-15 16:00 [PATCH net-next 0/6] net: dsa: always use phylink Russell King (Oracle)
2022-07-15 16:01 ` [PATCH net-next 1/6] net: phylink: split out and export interface to caps translation Russell King (Oracle)
2022-07-15 16:01 ` [PATCH net-next 2/6] software node: allow named software node to be created Russell King
2022-07-15 19:57 ` Andy Shevchenko
2022-07-15 20:17 ` Vladimir Oltean
2022-07-15 20:33 ` Andy Shevchenko
2022-07-15 20:48 ` Vladimir Oltean
2022-07-18 12:29 ` Andy Shevchenko
2022-07-18 13:27 ` Russell King (Oracle)
2022-07-18 18:43 ` Andy Shevchenko
2022-07-18 18:53 ` Andy Shevchenko
2022-07-18 19:14 ` Russell King (Oracle) [this message]
2022-07-18 19:24 ` Andy Shevchenko
2022-07-18 20:39 ` Marek Behún
2022-07-18 20:48 ` Andy Shevchenko
2022-07-19 7:18 ` Marek Behún
2022-07-29 12:08 ` Andy Shevchenko
2022-07-18 19:11 ` Russell King (Oracle)
2022-07-18 20:07 ` Andy Shevchenko
2022-07-18 20:38 ` Russell King (Oracle)
2022-07-19 8:50 ` Sakari Ailus
2022-07-20 22:56 ` Vladimir Oltean
2022-07-22 6:21 ` Sakari Ailus
2022-07-18 20:42 ` Andrew Lunn
2022-07-15 16:01 ` [PATCH net-next 3/6] net: dsa: add support for retrieving the interface mode Russell King (Oracle)
2022-07-15 17:24 ` Vladimir Oltean
2022-07-15 21:31 ` Russell King (Oracle)
2022-07-15 22:23 ` Vladimir Oltean
2022-07-15 22:57 ` Russell King (Oracle)
2022-07-16 10:57 ` Vladimir Oltean
2022-07-16 11:13 ` Russell King (Oracle)
2022-07-16 12:36 ` Vladimir Oltean
2022-07-18 8:48 ` Russell King (Oracle)
2022-07-20 22:44 ` Vladimir Oltean
2022-07-21 13:46 ` Vladimir Oltean
2022-07-21 14:46 ` Andrew Lunn
2022-07-21 14:54 ` Russell King (Oracle)
2022-07-21 15:15 ` Vladimir Oltean
2022-07-21 17:21 ` Marek Behún
2022-07-21 18:15 ` Russell King (Oracle)
2022-07-21 18:22 ` Vladimir Oltean
2022-07-21 21:14 ` Russell King (Oracle)
2022-07-21 21:36 ` Vladimir Oltean
2022-07-22 8:28 ` Russell King (Oracle)
2022-07-22 10:52 ` Vladimir Oltean
2022-07-22 11:44 ` Russell King (Oracle)
2022-07-22 12:14 ` Russell King (Oracle)
2022-07-22 12:46 ` Vladimir Oltean
2022-07-22 13:16 ` Russell King (Oracle)
2022-07-22 16:56 ` Vladimir Oltean
2022-07-22 21:20 ` Russell King (Oracle)
2022-07-22 21:53 ` Andrew Lunn
2022-07-22 22:35 ` Andrew Lunn
2022-07-22 22:39 ` Vladimir Oltean
2022-07-23 7:12 ` Russell King (Oracle)
2022-07-23 13:44 ` Vladimir Oltean
2022-07-25 10:11 ` Russell King (Oracle)
2022-07-23 17:26 ` Marek Behún
2022-07-24 17:39 ` Vladimir Oltean
2022-07-22 13:20 ` Andrew Lunn
2022-07-22 12:59 ` Marek Behún
2022-07-22 13:23 ` Russell King (Oracle)
2022-07-22 14:19 ` Marek Behún
2022-07-15 16:01 ` [PATCH net-next 4/6] net: dsa: mv88e6xxx: report the default interface mode for the port Russell King (Oracle)
2022-07-15 16:01 ` [PATCH net-next 5/6] net: dsa: use swnode fixed-link if using default params Russell King (Oracle)
2022-07-15 20:11 ` Andy Shevchenko
2022-07-15 21:36 ` Russell King (Oracle)
2022-07-18 18:59 ` Andy Shevchenko
2022-07-18 19:13 ` Russell King (Oracle)
2022-07-18 20:08 ` Andy Shevchenko
2022-07-15 16:01 ` [PATCH net-next 6/6] net: dsa: mv88e6xxx: remove handling for DSA and CPU ports Russell King (Oracle)
2022-07-15 17:17 ` [PATCH net-next 0/6] net: dsa: always use phylink Vladimir Oltean
2022-07-15 20:59 ` Russell King (Oracle)
2022-07-15 23:03 ` Jakub Kicinski
2022-07-16 11:15 ` Vladimir Oltean
2022-07-16 11:43 ` Russell King (Oracle)
2022-07-16 13:13 ` Vladimir Oltean
2022-07-18 8:53 ` Russell King (Oracle)
2022-07-18 12:45 ` Vladimir Oltean
2022-07-18 13:02 ` Russell King (Oracle)
2022-07-18 14:25 ` Vladimir Oltean
2022-07-16 23:44 ` Jakub Kicinski
2022-07-27 9:00 ` Marek Behún
2022-07-27 13:38 ` Vladimir Oltean
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=YtWxMrz3LcVQa43I@shell.armlinux.org.uk \
--to=linux@armlinux$(echo .)org.uk \
--cc=Landen.Chao@mediatek$(echo .)com \
--cc=UNGLinuxDriver@microchip$(echo .)com \
--cc=alexandre.belloni@bootlin$(echo .)com \
--cc=alsi@bang-olufsen$(echo .)dk \
--cc=andrew@lunn$(echo .)ch \
--cc=andriy.shevchenko@linux$(echo .)intel.com \
--cc=claudiu.manoil@nxp$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=djrscally@gmail$(echo .)com \
--cc=dqfext@gmail$(echo .)com \
--cc=edumazet@google$(echo .)com \
--cc=f.fainelli@gmail$(echo .)com \
--cc=george.mccollister@gmail$(echo .)com \
--cc=gregkh@linuxfoundation$(echo .)org \
--cc=hauke@hauke-m$(echo .)de \
--cc=heikki.krogerus@linux$(echo .)intel.com \
--cc=hkallweit1@gmail$(echo .)com \
--cc=kabel@kernel$(echo .)org \
--cc=kuba@kernel$(echo .)org \
--cc=kurt@linutronix$(echo .)de \
--cc=linus.walleij@linaro$(echo .)org \
--cc=linux-acpi@vger$(echo .)kernel.org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-mediatek@lists$(echo .)infradead.org \
--cc=matthias.bgg@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=olteanv@gmail$(echo .)com \
--cc=pabeni@redhat$(echo .)com \
--cc=rafael@kernel$(echo .)org \
--cc=sakari.ailus@linux$(echo .)intel.com \
--cc=sean.wang@mediatek$(echo .)com \
--cc=vivien.didelot@gmail$(echo .)com \
--cc=woojung.huh@microchip$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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