All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Johannes Berg <johannes@sipsolutions.net>,
	"David S. Miller" <davem@davemloft.net>,
	linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
	netdev@vger.kernel.org
Subject: Re: [PATCH] rfkill: allocate static minor
Date: Tue, 5 Nov 2019 18:25:25 +0100	[thread overview]
Message-ID: <20191105172525.GA2851576@kroah.com> (raw)
In-Reply-To: <B457050C-18F5-4171-A8A1-4CE95D908FAA@holtmann.org>

On Thu, Oct 24, 2019 at 10:23:57PM +0200, Marcel Holtmann wrote:
> Hi Greg,
> 
> >> udev has a feature of creating /dev/<node> device-nodes if it finds
> >> a devnode:<node> modalias. This allows for auto-loading of modules that
> >> provide the node. This requires to use a statically allocated minor
> >> number for misc character devices.
> >> 
> >> However, rfkill uses dynamic minor numbers and prevents auto-loading
> >> of the module. So allocate the next static misc minor number and use
> >> it for rfkill.
> > 
> > As rfkill has been around for a long time, what new use case is needing
> > to auto-load this based on a major number?
> 
> we have bug reports from iwd users where it fails opening /dev/rfkill. Since iwd can be actually started before the WiFi hardware is fully probed and all its drivers are loaded, we have a race-condition here if rfkill is not capable of auto-loading.
> 
> The difference is really that iwd is a fully self-contained WiFi daemon compared to wpa_supplicant which is just some sort of helper. iwd is fully hot plug capable as well compared to wpa_supplicant. It looks like this is exposing the race condition for our users. Frankly, we should have fixed rfkill a long time ago when we fixed uinput, uhid etc, but seems we forgot it. I assume mainly because it magically got loaded in time by some module dependencies.

You need a better email client, one with \n characters...

Anyway, this sounds reasonable, I'll go queue this up for 5.5.

thanks,

greg k-h

      reply	other threads:[~2019-11-05 17:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-24 17:40 [PATCH] rfkill: allocate static minor Marcel Holtmann
2019-10-24 18:44 ` Greg KH
2019-10-24 20:23   ` Marcel Holtmann
2019-11-05 17:25     ` Greg KH [this message]

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=20191105172525.GA2851576@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=arnd@arndb.de \
    --cc=davem@davemloft.net \
    --cc=johannes@sipsolutions.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=marcel@holtmann.org \
    --cc=netdev@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.