lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL_Jsq+tkXAAVK2D_AtENuXJZOF2eK=sUnjv3=7PM8nAyAB7Xw@mail.gmail.com>
Date: Fri, 28 Feb 2025 10:59:06 -0600
From: Rob Herring <robh@...nel.org>
To: Matti Vaittinen <mazziesaccount@...il.com>
Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, 
	Heikki Krogerus <heikki.krogerus@...ux.intel.com>, 
	Matti Vaittinen <matti.vaittinen@...rohmeurope.com>, Jonathan Cameron <jic23@...nel.org>, 
	Lars-Peter Clausen <lars@...afoo.de>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Daniel Scally <djrscally@...il.com>, Sakari Ailus <sakari.ailus@...ux.intel.com>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, "Rafael J. Wysocki" <rafael@...nel.org>, 
	Danilo Krummrich <dakr@...nel.org>, Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>, 
	Chen-Yu Tsai <wens@...e.org>, Jernej Skrabec <jernej.skrabec@...il.com>, 
	Samuel Holland <samuel@...lland.org>, Hugo Villeneuve <hvilleneuve@...onoff.com>, 
	Nuno Sa <nuno.sa@...log.com>, David Lechner <dlechner@...libre.com>, 
	Javier Carrasco <javier.carrasco.cruz@...il.com>, Guillaume Stols <gstols@...libre.com>, 
	Olivier Moysan <olivier.moysan@...s.st.com>, Dumitru Ceclan <mitrutzceclan@...il.com>, 
	Trevor Gamblin <tgamblin@...libre.com>, Matteo Martelli <matteomartelli3@...il.com>, 
	Alisa-Dariana Roman <alisadariana@...il.com>, 
	Ramona Alexandra Nechita <ramona.nechita@...log.com>, 
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>, linux-iio@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-acpi@...r.kernel.org, linux-renesas-soc@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linux-sunxi@...ts.linux.dev
Subject: Re: [PATCH v4 02/10] property: Add device_get_child_node_count_named()

On Thu, Feb 27, 2025 at 9:06 AM Matti Vaittinen
<mazziesaccount@...il.com> wrote:
>
> On 27/02/2025 16:49, Andy Shevchenko wrote:
> > On Thu, Feb 27, 2025 at 10:01:49AM +0200, Matti Vaittinen wrote:
> >> On 26/02/2025 16:11, Andy Shevchenko wrote:
> >>> On Wed, Feb 26, 2025 at 04:04:02PM +0200, Matti Vaittinen wrote:
> >>>> On 25/02/2025 15:59, Andy Shevchenko wrote:
> >>>>> On Tue, Feb 25, 2025 at 03:29:17PM +0200, Matti Vaittinen wrote:
> >>>>>> On 25/02/2025 12:39, Andy Shevchenko wrote:
> >>>>>>> On Tue, Feb 25, 2025 at 12:29:31PM +0200, Matti Vaittinen wrote:
> >>>>>>>> On 25/02/2025 12:21, Andy Shevchenko wrote:
> >>>>>>>>> On Tue, Feb 25, 2025 at 11:40:16AM +0200, Heikki Krogerus wrote:
> >
> > ...
> >
> >>>>>>>>>>
> >>>>>>>>>> I did not check how many users are you proposing for this, but if
> >>>>>>>>>> there's only one, then IMO this should not be a global function yet.
> >>>>>>>>>> It just feels to special case to me. But let's see what the others
> >>>>>>>>>> think.
> >>>>>>>>>
> >>>>>>>>> The problem is that if somebody hides it, we might potentially see
> >>>>>>>>> a duplication in the future. So I _slightly_ prefer to publish and
> >>>>>>>>> then drop that after a few cycles if no users appear.
> >>>>>>>>
> >>>>>>>> After taking a very quick grep I spotted one other existing place where we
> >>>>>>>> might be able to do direct conversion to use this function.
> >>>>>>>>
> >>>>>>>> drivers/net/ethernet/freescale/gianfar.c
> >>>>>>>>
> >>>>>>>> That'd be 2 users.
> >>>>>>>
> >>>>>>> I haven't checked myself, I believe your judgement,
> >>>>>>
> >>>>>> I took a better look and you obviously shouldn't believe :) The gianfar used
> >>>>>> of_node instead of the fwnode. So, it'd be a single caller at starters.
> >>>>>
> >>>>> ...which is the same as dev_of_node(), which means that you can use your
> >>>>> function there.
> >>>>
> >>>> I'm unsure what you mean. The proposed function
> >>>> device_get_child_node_count_named() takes device pointer. I don't see how
> >>>> dev_of_node() helps converting node to device?
> >>>
> >>> dev_of_node() takes the device pointer and dev_fwnode() takes that as well,
> >>> it means that there is no difference which one to use OF-centric or fwnode
> >>
> >> The proposed device_get_child_node_count_named() takes a device pointer. I
> >> don't see how dev_of_node() helps if there is just of_node and no device
> >> pointer available in the calling code.
> >
> > ???
> >
> > The loops are working on
> >
> >       struct device_node *np = pdev->dev.np;
> >
> > which is the equivalent to
> >
> >       struct device_node *np = dev_of_node(&pdev->dev);
> >
> > which takes device pointer.
> >
> >> (Well, as I wrote below, I could
> >> alter the gianfar code by dropping the gfar_of_group_count(), so that I have
> >> the device pointer in caller). Anyways, I don't see how dev_of_node() should
> >> help unless you're proposing I add a of_get_child_node_count_named() or
> >> somesuch - which I don't think makes sense.
> >
> > Are you forbidding yourself to change the function prototype to take a device
> > pointer instead of device_node one? :-)
> >
>
> This is our point of misunderstanding. As I wrote, and as you can see
> from the prototype, the function _is_ taking the device pointer. Hence I
> didn't understand how dev_of_node() should help us.
>
> >>> API in this particular case. Just make sure that the function (and there
> >>> is also a second loop AFAICS) takes struct device *dev instead of struct
> >>> device_node *np as a parameter.
> >>
> >> I think I lost the track here :)
> >
> > Make gfar_of_group_count() to take device pointer. As simple as that.
>
> that'd just make the gfar_of_group_count() a wrapper of the
> of_get_child_node_count_named(). I prefer killing whole
> gfar_of_group_count().

Sigh. This is not that hard.

- unsigned int num_grps = gfar_of_group_count(np);
+ unsigned int num_grps =
device_get_child_node_count_named(&ofdev->dev, "queue-groups");

And remove gfar_of_group_count() of course.

Rob

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ