public inbox for linux-crypto@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: linux-kernel@vger.kernel.org,
	Andre Przywara <andre.przywara@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 17:46:46 +0100	[thread overview]
Message-ID: <2025031731-anyhow-askew-5731@gregkh> (raw)
In-Reply-To: <Z9g1CV6jgea8VpW4@bogus>

On Mon, Mar 17, 2025 at 02:43:21PM +0000, Sudeep Holla wrote:
> 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.

It will not show up anywhere if the probe call fails.

> > 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.

Let's see a series that adds the macro and uses it and we can figure it
out from there.  If the macro is sane, I can just take that now for
6.15-rc1 and then you can send the others to the different subsystems
after that shows up.

thanks,

greg k-h

  reply	other threads:[~2025-03-17 16:48 UTC|newest]

Thread overview: 12+ 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 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
2025-03-17 16:46           ` Greg Kroah-Hartman [this message]
2025-03-17 16:53             ` Sudeep Holla
2025-03-17 13:01 ` [PATCH 0/9] drivers: Transition " 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=2025031731-anyhow-askew-5731@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=andre.przywara@arm.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=jeff.johnson@oss.qualcomm.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sudeep.holla@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox