linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zhenzhong Duan <zhenzhong.duan@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Question about dynamic minor number of misc device
Date: Mon, 20 Jan 2020 18:25:58 +0800	[thread overview]
Message-ID: <CAFH1YnMDL1gBNT4vr+C=eGGoCYJvkVDnoXUVN8OL9Xs3668Z+Q@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a3DwaZnRff7CCrJoSxP_MeVUn1S6nRd+hb5rHnv9dBgLQ@mail.gmail.com>

On Mon, Jan 20, 2020 at 6:03 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Mon, Jan 20, 2020 at 9:33 AM Zhenzhong Duan <zhenzhong.duan@gmail.com> wrote:
> >
> > Hi Maintainers,
> >
> > I see there are 64 free slots(0-63) used for misc devices with dynamic
> > minor number. But PSMOUSE_MINOR(1) overlaps with that dynamic range.
> >
> > So if the dynamic minor number exhaust, psaux driver will fail with
> > "could not register psaux device, error: -16", is this expected?
> > Should we preserve a slot for psaux and serio_raw which use static
> > minor number PSMOUSE_MINOR?
>
> Is this a theoretical question, or are you actually running out of dynamic
> minor numbers? I would guess that if we change the limit to only allow
> dynamic minors 2 through 63, that would technically be a correct
> change, but the result would be that in the same situation another random
> driver fails, which is not much of an improvement, unless the dynamic
> minor numbers also continue into the range above 255.

It's theoretical question. Thanks for your explanation.

>
> On a  related note, I checked for drivers that call misc_register()
> with a minor number that is not defined in include/linux/misc.h
> and found a bunch, including some that have conflicting numbers,
> conflicting names  or numbers from the dynamic range:
>
> drivers/staging/speakup/devsynth.c:#define SYNTH_MINOR 25
> drivers/staging/speakup/speakup_soft.c:#define SOFTSYNTH_MINOR 26 /*
> might as well give it one more than /dev/synth */
> drivers/staging/speakup/speakup_soft.c:#define SOFTSYNTHU_MINOR 27 /*
> might as well give it one more than /dev/synth */
> drivers/macintosh/via-pmu.c:#define PMU_MINOR           154
> drivers/macintosh/ans-lcd.h:#define ANSLCD_MINOR                156
> drivers/auxdisplay/charlcd.c:#define LCD_MINOR          156
> drivers/char/applicom.c:#define AC_MINOR 157
> drivers/char/nwbutton.h:#define BUTTON_MINOR 158
> arch/arm/include/asm/nwflash.h:#define FLASH_MINOR               160
> drivers/sbus/char/envctrl.c:#define ENVCTRL_MINOR       162
> drivers/sbus/char/flash.c:#define FLASH_MINOR   152
> drivers/sbus/char/uctrl.c:#define UCTRL_MINOR   174
> drivers/char/toshiba.c:#define TOSH_MINOR_DEV 181
> arch/um/drivers/random.c:#define RNG_MISCDEV_MINOR              183 /*
> official */
> drivers/auxdisplay/panel.c:#define KEYPAD_MINOR         185
> drivers/video/fbdev/pxa3xx-gcu.c:#define MISCDEV_MINOR  197
> kernel/power/user.c:#define SNAPSHOT_MINOR      231
> drivers/parisc/eisa_eeprom.c:#define    EISA_EEPROM_MINOR 241
>
> If you would like to help clean that up, you are definitely welcome
> to send patches.

Ok, should that be a patch for all drivers or seperate patch for each driver?

Thanks
Zhenzhong

  reply	other threads:[~2020-01-20 10:26 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-20  8:33 Question about dynamic minor number of misc device Zhenzhong Duan
2020-01-20 10:03 ` Arnd Bergmann
2020-01-20 10:25   ` Zhenzhong Duan [this message]
2020-01-20 10:59     ` Arnd Bergmann
2020-01-20 22:13       ` Theodore Y. Ts'o
2020-01-21  7:56         ` Arnd Bergmann
2020-01-21 16:31           ` Theodore Y. Ts'o
2020-01-21 17:54             ` Sam Hartman
2020-01-21 15:42         ` Greg Kroah-Hartman

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='CAFH1YnMDL1gBNT4vr+C=eGGoCYJvkVDnoXUVN8OL9Xs3668Z+Q@mail.gmail.com' \
    --to=zhenzhong.duan@gmail.com \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).