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: <1jv7tczytk.fsf@starbuckisacylon.baylibre.com>
Date: Fri, 14 Feb 2025 09:59:35 +0100
From: Jerome Brunet <jbrunet@...libre.com>
To: Conor Dooley <conor@...nel.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,  Dave Ertman
 <david.m.ertman@...el.com>,  Ira Weiny <ira.weiny@...el.com>,  "Rafael J.
 Wysocki" <rafael@...nel.org>,  Stephen Boyd <sboyd@...nel.org>,  Arnd
 Bergmann <arnd@...db.de>,  Danilo Krummrich <dakr@...nel.org>,  Conor
 Dooley <conor.dooley@...rochip.com>,  Daire McNamara
 <daire.mcnamara@...rochip.com>,  Philipp Zabel <p.zabel@...gutronix.de>,
  Douglas Anderson <dianders@...omium.org>,  Andrzej Hajda
 <andrzej.hajda@...el.com>,  Neil Armstrong <neil.armstrong@...aro.org>,
  Robert Foss <rfoss@...nel.org>,  Laurent Pinchart
 <Laurent.pinchart@...asonboard.com>,  Jonas Karlman <jonas@...boo.se>,
  Jernej Skrabec <jernej.skrabec@...il.com>,  Maarten Lankhorst
 <maarten.lankhorst@...ux.intel.com>,  Maxime Ripard <mripard@...nel.org>,
  Thomas Zimmermann <tzimmermann@...e.de>,  David Airlie
 <airlied@...il.com>,  Simona Vetter <simona@...ll.ch>,  Hans de Goede
 <hdegoede@...hat.com>,  Ilpo Järvinen
 <ilpo.jarvinen@...ux.intel.com>,
  Bryan O'Donoghue <bryan.odonoghue@...aro.org>,  Vladimir Kondratiev
 <vladimir.kondratiev@...ileye.com>,  Gregory CLEMENT
 <gregory.clement@...tlin.com>,  Théo Lebrun
 <theo.lebrun@...tlin.com>,
  Michael Turquette <mturquette@...libre.com>,  Abel Vesa
 <abelvesa@...nel.org>,  Peng Fan <peng.fan@....com>,  Shawn Guo
 <shawnguo@...nel.org>,  Sascha Hauer <s.hauer@...gutronix.de>,
  Pengutronix Kernel Team <kernel@...gutronix.de>,  Fabio Estevam
 <festevam@...il.com>,  Kevin Hilman <khilman@...libre.com>,  Martin
 Blumenstingl <martin.blumenstingl@...glemail.com>,
  linux-kernel@...r.kernel.org,  linux-riscv@...ts.infradead.org,
  dri-devel@...ts.freedesktop.org,  platform-driver-x86@...r.kernel.org,
  linux-mips@...r.kernel.org,  linux-clk@...r.kernel.org,
  imx@...ts.linux.dev,  linux-arm-kernel@...ts.infradead.org,
  linux-amlogic@...ts.infradead.org
Subject: Re: [PATCH v3 2/7] reset: mpfs: use the auxiliary device creation
 helper

On Thu 13 Feb 2025 at 17:59, Conor Dooley <conor@...nel.org> wrote:

> On Tue, Feb 11, 2025 at 06:27:59PM +0100, Jerome Brunet wrote:
>> The auxiliary device creation of this driver is simple enough to
>> use the available auxiliary device creation helper.
>> 
>> Use it and remove some boilerplate code.
>> 
>> Signed-off-by: Jerome Brunet <jbrunet@...libre.com>
>> ---
>>  drivers/reset/reset-mpfs.c | 52 +++-------------------------------------------
>>  1 file changed, 3 insertions(+), 49 deletions(-)
>> 
>> diff --git a/drivers/reset/reset-mpfs.c b/drivers/reset/reset-mpfs.c
>> index 574e59db83a4fcf30b60cb5f638607a2ec7b0580..bbea64862181877eb7ae51fdaa9e50ffac17c908 100644
>> --- a/drivers/reset/reset-mpfs.c
>> +++ b/drivers/reset/reset-mpfs.c
>> @@ -155,62 +155,16 @@ static int mpfs_reset_probe(struct auxiliary_device *adev,
>>  	return devm_reset_controller_register(dev, rcdev);
>>  }
>>  
>> -static void mpfs_reset_unregister_adev(void *_adev)
>> -{
>> -	struct auxiliary_device *adev = _adev;
>> -
>> -	auxiliary_device_delete(adev);
>> -	auxiliary_device_uninit(adev);
>> -}
>> -
>> -static void mpfs_reset_adev_release(struct device *dev)
>> -{
>> -	struct auxiliary_device *adev = to_auxiliary_dev(dev);
>> -
>> -	kfree(adev);
>> -}
>> -
>> -static struct auxiliary_device *mpfs_reset_adev_alloc(struct device *clk_dev)
>> -{
>> -	struct auxiliary_device *adev;
>> -	int ret;
>> -
>> -	adev = kzalloc(sizeof(*adev), GFP_KERNEL);
>> -	if (!adev)
>> -		return ERR_PTR(-ENOMEM);
>> -
>> -	adev->name = "reset-mpfs";
>> -	adev->dev.parent = clk_dev;
>> -	adev->dev.release = mpfs_reset_adev_release;
>> -	adev->id = 666u;
>> -
>> -	ret = auxiliary_device_init(adev);
>> -	if (ret) {
>> -		kfree(adev);
>> -		return ERR_PTR(ret);
>> -	}
>> -
>> -	return adev;
>> -}
>> -
>>  int mpfs_reset_controller_register(struct device *clk_dev, void __iomem *base)
>>  {
>>  	struct auxiliary_device *adev;
>> -	int ret;
>>  
>> -	adev = mpfs_reset_adev_alloc(clk_dev);
>> +	adev = devm_auxiliary_device_create(clk_dev, "reset-mpfs",
>> +					    (__force void *)base, 666u);
>
> Moving the boilerplate into a helper makes sense:
> Acked-by: Conor Dooley <conor.dooley@...rochip.com>
>
> One think that's always felt a bit meh to me is this id number stuff,
> I just threw in 666 for meme value.

:)

> The whole thing seems super
> arbitrary, do any of the users of this helper actually put meaningful
> values into the id parameter?

In example changes I've sent, no.

In other simple usages (those using container_of()) of the auxiliary
bus, I think there are a few that uses 0 and 1 for 2 instances.

I guess your question is "do we really need this parameter here ?"

We could remove it and still address 90% of the original target.

Keeping it leaves the door open in case the figure above does not hold
and it is pretty cheap to do. It could also enable drivers requiring an
IDA to use the helper, possibly.

>
>>  	if (IS_ERR(adev))
>>  		return PTR_ERR(adev);
>>  
>> -	ret = auxiliary_device_add(adev);
>> -	if (ret) {
>> -		auxiliary_device_uninit(adev);
>> -		return ret;
>> -	}
>> -
>> -	adev->dev.platform_data = (__force void *)base;
>> -
>> -	return devm_add_action_or_reset(clk_dev, mpfs_reset_unregister_adev, adev);
>> +	return 0;
>>  }
>>  EXPORT_SYMBOL_NS_GPL(mpfs_reset_controller_register, "MCHP_CLK_MPFS");
>>  
>> 
>> -- 
>> 2.45.2
>> 

-- 
Jerome

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ