From: Vladimir Oltean <olteanv@gmail.com>
To: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: "Russell King (Oracle)" <linux@armlinux.org.uk>,
"Andy Shevchenko" <andriy.shevchenko@linux.intel.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>,
"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: Thu, 21 Jul 2022 01:56:52 +0300 [thread overview]
Message-ID: <20220720225652.4uo6fcdcunenej3j@skbuf> (raw)
In-Reply-To: <YtZwU9BKAO/WSRmK@paasikivi.fi.intel.com>
Hi Sakari,
On Tue, Jul 19, 2022 at 08:50:27AM +0000, Sakari Ailus wrote:
> Basically what your patch is doing is adding a helper function that creates
> an fwnode with a given name. This functionality was there previously through
> software_node_register_nodes(), with node allocation responsibility residing
> on the caller. It's used e.g. here:
> drivers/media/pci/intel/ipu3/cio2-bridge.c .
>
> The larger question is perhaps when can you safely remove software nodes.
> And which of these two APIs would be preferred. I haven't checked how many
> users each has. There's no refcounting nor locking for software nodes, so
> once made visible to the rest of the kernel, they're always expected to be
> there, unchanged, or at least it needs to be known when they can be removed.
Just for my clarity, are you saying that this printf selftest is
violating the software nodes' expectation to always be there unchanged
and never be removed?
static void __init fwnode_pointer(void)
{
const struct software_node softnodes[] = {
{ .name = "first", },
{ .name = "second", .parent = &softnodes[0], },
{ .name = "third", .parent = &softnodes[1], },
{ NULL /* Guardian */ }
};
const char * const full_name = "first/second/third";
const char * const full_name_second = "first/second";
const char * const second_name = "second";
const char * const third_name = "third";
int rval;
rval = software_node_register_nodes(softnodes);
if (rval) {
pr_warn("cannot register softnodes; rval %d\n", rval);
return;
}
test(full_name_second, "%pfw", software_node_fwnode(&softnodes[1]));
test(full_name, "%pfw", software_node_fwnode(&softnodes[2]));
test(full_name, "%pfwf", software_node_fwnode(&softnodes[2]));
test(second_name, "%pfwP", software_node_fwnode(&softnodes[1]));
test(third_name, "%pfwP", software_node_fwnode(&softnodes[2]));
software_node_unregister_nodes(softnodes);
}
The use case in this patch set is essentially equivalent to what printf
does: exposing the software nodes to the rest of the kernel and to user
space is probably not necessary, it's just that we need to call a
function that parses their structure (essentially an equivalent to
calling "test" above). Could you indicate whether there is a better
alternative of doing this?
WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Oltean <olteanv@gmail.com>
To: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: "Russell King (Oracle)" <linux@armlinux.org.uk>,
"Andy Shevchenko" <andriy.shevchenko@linux.intel.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>,
"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: Thu, 21 Jul 2022 01:56:52 +0300 [thread overview]
Message-ID: <20220720225652.4uo6fcdcunenej3j@skbuf> (raw)
In-Reply-To: <YtZwU9BKAO/WSRmK@paasikivi.fi.intel.com>
Hi Sakari,
On Tue, Jul 19, 2022 at 08:50:27AM +0000, Sakari Ailus wrote:
> Basically what your patch is doing is adding a helper function that creates
> an fwnode with a given name. This functionality was there previously through
> software_node_register_nodes(), with node allocation responsibility residing
> on the caller. It's used e.g. here:
> drivers/media/pci/intel/ipu3/cio2-bridge.c .
>
> The larger question is perhaps when can you safely remove software nodes.
> And which of these two APIs would be preferred. I haven't checked how many
> users each has. There's no refcounting nor locking for software nodes, so
> once made visible to the rest of the kernel, they're always expected to be
> there, unchanged, or at least it needs to be known when they can be removed.
Just for my clarity, are you saying that this printf selftest is
violating the software nodes' expectation to always be there unchanged
and never be removed?
static void __init fwnode_pointer(void)
{
const struct software_node softnodes[] = {
{ .name = "first", },
{ .name = "second", .parent = &softnodes[0], },
{ .name = "third", .parent = &softnodes[1], },
{ NULL /* Guardian */ }
};
const char * const full_name = "first/second/third";
const char * const full_name_second = "first/second";
const char * const second_name = "second";
const char * const third_name = "third";
int rval;
rval = software_node_register_nodes(softnodes);
if (rval) {
pr_warn("cannot register softnodes; rval %d\n", rval);
return;
}
test(full_name_second, "%pfw", software_node_fwnode(&softnodes[1]));
test(full_name, "%pfw", software_node_fwnode(&softnodes[2]));
test(full_name, "%pfwf", software_node_fwnode(&softnodes[2]));
test(second_name, "%pfwP", software_node_fwnode(&softnodes[1]));
test(third_name, "%pfwP", software_node_fwnode(&softnodes[2]));
software_node_unregister_nodes(softnodes);
}
The use case in this patch set is essentially equivalent to what printf
does: exposing the software nodes to the rest of the kernel and to user
space is probably not necessary, it's just that we need to call a
function that parses their structure (essentially an equivalent to
calling "test" above). Could you indicate whether there is a better
alternative of doing this?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-07-20 22:56 UTC|newest]
Thread overview: 168+ 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:00 ` 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 ` 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 16:01 ` Russell King
2022-07-15 19:57 ` Andy Shevchenko
2022-07-15 19:57 ` Andy Shevchenko
2022-07-15 20:17 ` Vladimir Oltean
2022-07-15 20:17 ` Vladimir Oltean
2022-07-15 20:33 ` Andy Shevchenko
2022-07-15 20:33 ` Andy Shevchenko
2022-07-15 20:48 ` Vladimir Oltean
2022-07-15 20:48 ` Vladimir Oltean
2022-07-18 12:29 ` Andy Shevchenko
2022-07-18 12:29 ` Andy Shevchenko
2022-07-18 13:27 ` Russell King (Oracle)
2022-07-18 13:27 ` Russell King (Oracle)
2022-07-18 18:43 ` Andy Shevchenko
2022-07-18 18:43 ` Andy Shevchenko
2022-07-18 18:53 ` Andy Shevchenko
2022-07-18 18:53 ` Andy Shevchenko
2022-07-18 19:14 ` Russell King (Oracle)
2022-07-18 19:14 ` Russell King (Oracle)
2022-07-18 19:24 ` Andy Shevchenko
2022-07-18 19:24 ` Andy Shevchenko
2022-07-18 20:39 ` Marek Behún
2022-07-18 20:39 ` Marek Behún
2022-07-18 20:48 ` Andy Shevchenko
2022-07-18 20:48 ` Andy Shevchenko
2022-07-19 7:18 ` Marek Behún
2022-07-19 7:18 ` Marek Behún
2022-07-29 12:08 ` Andy Shevchenko
2022-07-29 12:08 ` Andy Shevchenko
2022-07-18 19:11 ` Russell King (Oracle)
2022-07-18 19:11 ` Russell King (Oracle)
2022-07-18 20:07 ` Andy Shevchenko
2022-07-18 20:07 ` Andy Shevchenko
2022-07-18 20:38 ` Russell King (Oracle)
2022-07-18 20:38 ` Russell King (Oracle)
2022-07-19 8:50 ` Sakari Ailus
2022-07-19 8:50 ` Sakari Ailus
2022-07-20 22:56 ` Vladimir Oltean [this message]
2022-07-20 22:56 ` Vladimir Oltean
2022-07-22 6:21 ` Sakari Ailus
2022-07-22 6:21 ` Sakari Ailus
2022-07-18 20:42 ` Andrew Lunn
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 16:01 ` Russell King (Oracle)
2022-07-15 17:24 ` Vladimir Oltean
2022-07-15 17:24 ` Vladimir Oltean
2022-07-15 21:31 ` Russell King (Oracle)
2022-07-15 21:31 ` Russell King (Oracle)
2022-07-15 22:23 ` Vladimir Oltean
2022-07-15 22:23 ` Vladimir Oltean
2022-07-15 22:57 ` Russell King (Oracle)
2022-07-15 22:57 ` Russell King (Oracle)
2022-07-16 10:57 ` Vladimir Oltean
2022-07-16 10:57 ` Vladimir Oltean
2022-07-16 11:13 ` Russell King (Oracle)
2022-07-16 11:13 ` Russell King (Oracle)
2022-07-16 12:36 ` Vladimir Oltean
2022-07-16 12:36 ` Vladimir Oltean
2022-07-18 8:48 ` Russell King (Oracle)
2022-07-18 8:48 ` Russell King (Oracle)
2022-07-20 22:44 ` Vladimir Oltean
2022-07-20 22:44 ` Vladimir Oltean
2022-07-21 13:46 ` Vladimir Oltean
2022-07-21 13:46 ` Vladimir Oltean
2022-07-21 14:46 ` Andrew Lunn
2022-07-21 14:46 ` Andrew Lunn
2022-07-21 14:54 ` Russell King (Oracle)
2022-07-21 14:54 ` Russell King (Oracle)
2022-07-21 15:15 ` Vladimir Oltean
2022-07-21 15:15 ` Vladimir Oltean
2022-07-21 17:21 ` Marek Behún
2022-07-21 17:21 ` Marek Behún
2022-07-21 18:15 ` Russell King (Oracle)
2022-07-21 18:15 ` Russell King (Oracle)
2022-07-21 18:22 ` Vladimir Oltean
2022-07-21 18:22 ` Vladimir Oltean
2022-07-21 21:14 ` Russell King (Oracle)
2022-07-21 21:14 ` Russell King (Oracle)
2022-07-21 21:36 ` Vladimir Oltean
2022-07-21 21:36 ` Vladimir Oltean
2022-07-22 8:28 ` Russell King (Oracle)
2022-07-22 8:28 ` Russell King (Oracle)
2022-07-22 10:52 ` Vladimir Oltean
2022-07-22 10:52 ` Vladimir Oltean
2022-07-22 11:44 ` Russell King (Oracle)
2022-07-22 11:44 ` Russell King (Oracle)
2022-07-22 12:14 ` Russell King (Oracle)
2022-07-22 12:14 ` Russell King (Oracle)
2022-07-22 12:46 ` Vladimir Oltean
2022-07-22 12:46 ` Vladimir Oltean
2022-07-22 13:16 ` Russell King (Oracle)
2022-07-22 13:16 ` Russell King (Oracle)
2022-07-22 16:56 ` Vladimir Oltean
2022-07-22 16:56 ` Vladimir Oltean
2022-07-22 21:20 ` Russell King (Oracle)
2022-07-22 21:20 ` Russell King (Oracle)
2022-07-22 21:53 ` Andrew Lunn
2022-07-22 21:53 ` Andrew Lunn
2022-07-22 22:35 ` Andrew Lunn
2022-07-22 22:35 ` Andrew Lunn
2022-07-22 22:39 ` Vladimir Oltean
2022-07-22 22:39 ` Vladimir Oltean
2022-07-23 7:12 ` Russell King (Oracle)
2022-07-23 7:12 ` Russell King (Oracle)
2022-07-23 13:44 ` Vladimir Oltean
2022-07-23 13:44 ` Vladimir Oltean
2022-07-25 10:11 ` Russell King (Oracle)
2022-07-25 10:11 ` Russell King (Oracle)
2022-07-23 17:26 ` Marek Behún
2022-07-23 17:26 ` Marek Behún
2022-07-24 17:39 ` Vladimir Oltean
2022-07-24 17:39 ` Vladimir Oltean
2022-07-22 13:20 ` Andrew Lunn
2022-07-22 13:20 ` Andrew Lunn
2022-07-22 12:59 ` Marek Behún
2022-07-22 12:59 ` Marek Behún
2022-07-22 13:23 ` Russell King (Oracle)
2022-07-22 13:23 ` Russell King (Oracle)
2022-07-22 14:19 ` Marek Behún
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 ` 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 16:01 ` Russell King (Oracle)
2022-07-15 20:11 ` Andy Shevchenko
2022-07-15 20:11 ` Andy Shevchenko
2022-07-15 21:36 ` Russell King (Oracle)
2022-07-15 21:36 ` Russell King (Oracle)
2022-07-18 18:59 ` Andy Shevchenko
2022-07-18 18:59 ` Andy Shevchenko
2022-07-18 19:13 ` Russell King (Oracle)
2022-07-18 19:13 ` Russell King (Oracle)
2022-07-18 20:08 ` Andy Shevchenko
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 16:01 ` Russell King (Oracle)
2022-07-15 17:17 ` [PATCH net-next 0/6] net: dsa: always use phylink Vladimir Oltean
2022-07-15 17:17 ` Vladimir Oltean
2022-07-15 20:59 ` Russell King (Oracle)
2022-07-15 20:59 ` Russell King (Oracle)
2022-07-15 23:03 ` Jakub Kicinski
2022-07-15 23:03 ` Jakub Kicinski
2022-07-16 11:15 ` Vladimir Oltean
2022-07-16 11:15 ` Vladimir Oltean
2022-07-16 11:43 ` Russell King (Oracle)
2022-07-16 11:43 ` Russell King (Oracle)
2022-07-16 13:13 ` Vladimir Oltean
2022-07-16 13:13 ` Vladimir Oltean
2022-07-18 8:53 ` Russell King (Oracle)
2022-07-18 8:53 ` Russell King (Oracle)
2022-07-18 12:45 ` Vladimir Oltean
2022-07-18 12:45 ` Vladimir Oltean
2022-07-18 13:02 ` Russell King (Oracle)
2022-07-18 13:02 ` Russell King (Oracle)
2022-07-18 14:25 ` Vladimir Oltean
2022-07-18 14:25 ` Vladimir Oltean
2022-07-16 23:44 ` Jakub Kicinski
2022-07-16 23:44 ` Jakub Kicinski
2022-07-27 9:00 ` Marek Behún
2022-07-27 9:00 ` Marek Behún
2022-07-27 13:38 ` Vladimir Oltean
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=20220720225652.4uo6fcdcunenej3j@skbuf \
--to=olteanv@gmail.com \
--cc=Landen.Chao@mediatek.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=alexandre.belloni@bootlin.com \
--cc=alsi@bang-olufsen.dk \
--cc=andrew@lunn.ch \
--cc=andriy.shevchenko@linux.intel.com \
--cc=claudiu.manoil@nxp.com \
--cc=davem@davemloft.net \
--cc=djrscally@gmail.com \
--cc=dqfext@gmail.com \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=george.mccollister@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=hauke@hauke-m.de \
--cc=heikki.krogerus@linux.intel.com \
--cc=hkallweit1@gmail.com \
--cc=kabel@kernel.org \
--cc=kuba@kernel.org \
--cc=kurt@linutronix.de \
--cc=linus.walleij@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=matthias.bgg@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rafael@kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=sean.wang@mediatek.com \
--cc=vivien.didelot@gmail.com \
--cc=woojung.huh@microchip.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.