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
next prev parent 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