On Tue, Jul 01, 2025 at 01:06:46PM +0200, Johannes Berg wrote:
> On Tue, 2025-07-01 at 12:56 +0200, Greg Kroah-Hartman wrote:
> > Downloading regulatory "firmware" needs a device to hang off of, and so
> > a platform device seemed like the simplest way to do this. Now that we
> > have a faux device interface, use that instead as this "regulatory
> > device" is not anything resembling a platform device at all.
> >
> > Cc: Johannes Berg <johannes@xxxxxxxxxxxxxxxx>
> > Cc: <linux-wireless@xxxxxxxxxxxxxxx>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> > ---
> > v5: - rebase against 6.16-rc4 and actually cc: the relevant maintainers
> > and mailing lists this time, doh!
>
> I did wonder for a second why it's v5 and I never saw it ;-)
>
> > int __init regulatory_init(void)
> > {
> > - reg_pdev = platform_device_register_simple("regulatory", 0, NULL, 0);
> > - if (IS_ERR(reg_pdev))
> > - return PTR_ERR(reg_pdev);
> > + reg_fdev = faux_device_create("regulatory", NULL, NULL);
> > + if (!reg_fdev)
> > + return -ENODEV;
>
> Is that really -ENODEV rather than say -ENOMEM? Having a hard time
> imagining how a faux device creation would end up failing in any other
> case, there's no underlying device to bind to, after all? :)
There are some low-level functions that could fail, but the error that
I thought should be told to init would be "no device" as the device was
not created which is what really matters :)
> Anyway, that's not really all that relevant. I assume you want me to
> merge it through wireless-next, since we have faux.h in the tree now?
Please do, thanks!
greg k-h
