linux-kernel - Re: [PATCH v5] wifi: cfg80211: move away from using a fake platform device

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] [day] [month] [year] [list]

Message-ID: <2025070125-spent-glowworm-7405@gregkh>
Date: Tue, 1 Jul 2025 14:38:27 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Johannes Berg <johannes@...solutions.net>
Cc: linux-kernel@...r.kernel.org, linux-wireless@...r.kernel.org
Subject: Re: [PATCH v5] wifi: cfg80211: move away from using a fake platform
 device

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@...solutions.net>
> > Cc: <linux-wireless@...r.kernel.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > ---
> > 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