public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org,
	Andre Przywara <andre.przywara@arm.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Jeff Johnson <jeff.johnson@oss.qualcomm.com>,
	linux-crypto@vger.kernel.org
Subject: Re: [PATCH 2/9] hwrng: arm-smccc-trng - transition to the faux device interface
Date: Mon, 17 Mar 2025 14:43:21 +0000	[thread overview]
Message-ID: <Z9g1CV6jgea8VpW4@bogus> (raw)
In-Reply-To: <2025031709-unmoved-carton-c130@gregkh>

On Mon, Mar 17, 2025 at 03:30:15PM +0100, Greg Kroah-Hartman wrote:
> On Mon, Mar 17, 2025 at 02:22:45PM +0000, Sudeep Holla wrote:
> > On Mon, Mar 17, 2025 at 02:04:27PM +0100, Greg Kroah-Hartman wrote:
> > > On Mon, Mar 17, 2025 at 10:13:14AM +0000, Sudeep Holla wrote:
> > > > +MODULE_ALIAS("faux:smccc_trng");
> > > 
> > > Why do you need a branch new alias you just made up?  Please don't add
> > > that for these types of devices, that's not going to work at all (just
> > > like the platform alias really doesn't work well.
> > > 
> > 
> > Sure I will drop all of those alias. One question I have if the idea of
> > creating a macro for this is good or bad ? I need this initial condition
> > flag to make use of such a macro, so I didn't go for it, but it does
> > remove some boiler-plate code.
> > 
> > Let me know what do you think of it ?
> > 
> > Regards,
> > Sudeep
> > 
> > -->8 
> > diff --git i/include/linux/device/faux.h w/include/linux/device/faux.h
> > index 9f43c0e46aa4..8af3eaef281a 100644
> > --- i/include/linux/device/faux.h
> > +++ w/include/linux/device/faux.h
> > @@ -66,4 +66,30 @@ static inline void faux_device_set_drvdata(struct faux_device *faux_dev, void *d
> >  	dev_set_drvdata(&faux_dev->dev, data);
> >  }
> >  
> > +#define module_faux_driver(name, tag, init_cond)			\
> > +static struct faux_device_ops tag##_ops = {				\
> > +	.probe = tag##_probe,						\
> > +	.remove = tag##_remove,						\
> > +};									\
> > +									\
> > +static struct faux_device *tag##_dev;					\
> > +									\
> > +static int __init tag##_init(void)					\
> > +{									\
> > +	if (!(init_cond))						\
> > +		return 0;						\
> > +	tag##_dev = faux_device_create(name, NULL, &tag##_ops);		\
> > +	if (!tag##_dev)							\
> > +		return -ENODEV;						\
> > +									\
> > +	return 0;							\
> > +}									\
> > +module_init(tag##_init);						\
> > +									\
> > +static void __exit tag##_exit(void)					\
> > +{									\
> > +	faux_device_destroy(tag##_dev);					\
> > +}									\
> > +module_exit(tag##_exit);						\
> 
> Yes, I see that some of your changes could be moved to use this, so I
> think it is worth it.
> 
> But why can't you use module_driver() here?  Ah, that init_cond?  And
> the device.  Hm, why not put the init_cond in the probe callback?  That
> should make this macro simpler.
> 

I tried to keep the creation of the device itself conditional the way
it is today. Deferring the check to probe means the device gets created
unconditionally but won't be probed which is fine I guess. I was thinking
that device shouldn't show up on the bus if the condition is not met to
match the current scenario. I might be overthinking there.

> And don't use "tag", that's an odd term here, just copy what
> module_driver() does instead please.
> 

Sure, I will not use it. It was just a name that came to my mind.

Also creating the macro builds the dependency. Do you prefer to push the
changes as is and the macro in one release and make use of the macro later.

-- 
Regards,
Sudeep

  reply	other threads:[~2025-03-17 14:43 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-17 10:13 [PATCH 0/9] drivers: Transition to the faux device interface Sudeep Holla
2025-03-17 10:13 ` [PATCH 1/9] cpuidle: psci: " Sudeep Holla
2025-04-09 18:03   ` Rafael J. Wysocki
2025-04-09 19:17     ` Sudeep Holla
2025-04-09 19:28       ` Rafael J. Wysocki
2025-03-17 10:13 ` [PATCH 2/9] hwrng: arm-smccc-trng - transition " Sudeep Holla
2025-03-17 13:04   ` Greg Kroah-Hartman
2025-03-17 14:22     ` Sudeep Holla
2025-03-17 14:30       ` Greg Kroah-Hartman
2025-03-17 14:43         ` Sudeep Holla [this message]
2025-03-17 16:46           ` Greg Kroah-Hartman
2025-03-17 16:53             ` Sudeep Holla
2025-03-17 10:13 ` [PATCH 3/9] efi: Remove redundant creation of the "efivars" platform device Sudeep Holla
2025-03-17 17:06   ` Ard Biesheuvel
2025-03-17 17:19     ` Sudeep Holla
2025-03-17 10:13 ` [PATCH 4/9] rtc: efi: Transition to the faux device interface Sudeep Holla
2025-03-17 13:07   ` Greg Kroah-Hartman
2025-03-17 14:04     ` Sudeep Holla
2025-03-17 10:13 ` [PATCH 5/9] virt: efi_secret: " Sudeep Holla
2025-03-17 13:06   ` Greg Kroah-Hartman
2025-03-17 10:13 ` [PATCH 6/9] ASoC: soc-utils: " Sudeep Holla
2025-03-17 10:13 ` [PATCH 7/9] net: phy: fixed_phy: transition " Sudeep Holla
2025-03-17 12:29   ` Andrew Lunn
2025-03-17 13:00     ` Greg Kroah-Hartman
2025-03-17 14:17     ` Sudeep Holla
2025-03-17 10:13 ` [PATCH 8/9] ACPI: APEI: EINJ: Transition " Sudeep Holla
2025-06-06  3:35   ` Dan Williams
2025-03-17 10:13 ` [PATCH 9/9] regulator: dummy: convert to use " Sudeep Holla
2025-03-17 10:24   ` Mark Brown
2025-03-17 10:34     ` Sudeep Holla
2025-03-17 13:00   ` Greg Kroah-Hartman
2025-03-17 14:13     ` Sudeep Holla
2025-03-17 14:26       ` Greg Kroah-Hartman
2025-03-17 14:30         ` Sudeep Holla
2025-03-17 13:01 ` [PATCH 0/9] drivers: Transition to " Greg Kroah-Hartman
2025-03-17 14:28   ` Sudeep Holla
2025-03-17 14:20 ` Mark Brown
2025-03-17 18:10 ` (subset) " Mark Brown

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=Z9g1CV6jgea8VpW4@bogus \
    --to=sudeep.holla@arm.com \
    --cc=andre.przywara@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=jeff.johnson@oss.qualcomm.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox