All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Jiri Slaby <jslaby@suse.cz>
Cc: Baruch Siach <baruch@tkos.co.il>,
	linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Indan Zupancic <indan@nul.nu>, "H. Peter Anvin" <hpa@zytor.com>,
	Alex Gershgorin <agersh@rambler.ru>
Subject: Re: [PATCHv3] drivers/misc: Altera active serial implementation
Date: Mon, 15 Nov 2010 08:19:28 -0800	[thread overview]
Message-ID: <20101115161928.GC5981@kroah.com> (raw)
In-Reply-To: <4CE142B8.4090602@suse.cz>

On Mon, Nov 15, 2010 at 03:24:56PM +0100, Jiri Slaby wrote:
> On 11/15/2010 02:40 PM, Baruch Siach wrote:
> > On Mon, Nov 15, 2010 at 11:28:02AM +0100, Jiri Slaby wrote:
> >> On 11/15/2010 11:08 AM, Baruch Siach wrote:
> >>> Thanks for reviewing. See my response to your comments below.
> >>>
> >>> On Mon, Nov 15, 2010 at 10:33:37AM +0100, Jiri Slaby wrote:
> >>>> On 11/15/2010 09:23 AM, Baruch Siach wrote:
> >>>>> --- /dev/null
> >>>>> +++ b/drivers/misc/altera_as.c
> >>>>> @@ -0,0 +1,349 @@
> >>>> ...
> >>>>> +struct altera_as_device {
> >>>>> +	unsigned id;
> >>>>> +	struct device *dev;
> >>>>> +	struct miscdevice miscdev;
> >>>>> +	struct mutex open_lock;
> >>>>> +	struct gpio gpios[AS_GPIO_NUM];
> >>>>> +};
> >>>>> +
> >>>>> +/*
> >>>>> + * The only functions updating this array are .probe/.remove, which are
> >>>>> + * serialized. Hence, no locking is needed here.
> >>>>> + */
> >>>>> +static struct {
> >>>>> +	int minor;
> >>>>
> >>>> Why you need minor here? It's in drvdata->miscdev.minor.
> >>>
> >>> I use the minor field to lookup the drvdata pointer in get_as_dev(), which I 
> >>> use is altera_as_open().  I do this because I have no access to the 'struct 
> >>> device' pointer from the .open method. Do you know a better way?
> >>>
> >>>>> +	struct altera_as_device *drvdata;
> >>>>> +} altera_as_devs[AS_MAX_DEVS];
> >>>>
> >>>> You don't need the struct at all.
> >>>> static struct altera_as_device *drvdata[AS_MAX_DEVS];
> >>>> should be enough.
> >>>
> >>> See above.
> >>
> >> The answer to you previous question is here. You can just have a global
> >> array of struct altera_as_device.
> > 
> > This static array would occupy sizeof(struct altera_as_device) * AS_MAX_DEVS 
> > == 128 (for 32bit) * 16 == 2KB unconditionally.
> 
> No, it is an array of pointers.
> 
> >>>>> +static int __init altera_as_probe(struct platform_device *pdev)
> >>>>> +{
> >>>> ...
> >>>>> +	drvdata->miscdev.minor = MISC_DYNAMIC_MINOR;
> >>>>> +	drvdata->miscdev.name = kasprintf(GFP_KERNEL, "altera_as%d",
> >>>>> +			pdata->id);
> >>>>> +	if (drvdata->miscdev.name == NULL)
> >>>>> +		return -ENOMEM;
> >>>>> +	drvdata->miscdev.fops = &altera_as_fops;
> >>>>> +	if (misc_register(&drvdata->miscdev) < 0) {
> >>>>
> >>>> Hmm, how many devices can be in the system?
> >>>
> >>> Up to AS_MAX_DEVS, currently 16.
> >>>
> >>>> This doesn't look like the right way.
> >>>
> >>> What is the right way then?
> >>
> >> Ok, so for that count it definitely deserves its own major to not eat up
> >> misc device space.
> > 
> > A previous version of this driver[1] did just that. It was Greg KH who 
> > suggested[2] to use the misc class.
> > 
> > [1] http://article.gmane.org/gmane.linux.kernel/1057434
> > [2] http://article.gmane.org/gmane.linux.kernel/1058627
> 
> Ok, citing in-place:
> <cite1>
> Please don't create your own class just for a single driver.  Just use
> the misc class interface instead, as all you really want/need here is a
> character device node, right?
> </cite1>
> 
> The "miscdevice" is intended for people who want only a single device
> per system (singleton) and it is designed that way. There can be only up
> to 64 dynamic minors. Here you allow up to 16 devices out of box...

I thought this driver only allocated one single minor number.  If it is
doing this for 16 all the time, then it should get its own major, sorry
my fault.

> <cite2>
> And as discussed at the Plumbers conference this past week, we don't
> want to add any new 'struct class' implementations to the kernel from
> now on, as it's the overall wrong thing to do.
> </cite2>
> 
> Well, how do people notify udev about their character devices then? Any
> pointers to the discussion?

Use a struct bus_type instead.

thanks,

greg k-h

  reply	other threads:[~2010-11-15 16:40 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-15  8:23 [PATCHv3] drivers/misc: Altera active serial implementation Baruch Siach
2010-11-15  9:33 ` Jiri Slaby
2010-11-15 10:08   ` Baruch Siach
2010-11-15 10:28     ` Jiri Slaby
2010-11-15 13:40       ` Baruch Siach
2010-11-15 14:24         ` Jiri Slaby
2010-11-15 16:19           ` Greg KH [this message]
2010-11-16  0:47       ` Indan Zupancic
2010-11-16  5:56         ` Baruch Siach
2010-11-16  7:42           ` H. Peter Anvin
2010-11-16 11:04         ` Alan Cox
2010-11-16 13:09           ` Jiri Slaby
2010-11-17  5:32             ` Baruch Siach
2010-11-17  5:43               ` H. Peter Anvin
2010-11-17  5:48                 ` Baruch Siach
2010-11-17  8:31                   ` Jiri Slaby
2010-11-17 11:08               ` Alan Cox
2010-11-16 11:05         ` Alan Cox
2010-11-17  6:18 ` Thomas Chou
2010-11-17 13:28   ` Baruch Siach
     [not found]   ` <4CE42457.8090001@zytor.com>
2010-11-18  2:15     ` Thomas Chou
2010-11-18  2:15       ` H. Peter Anvin
2010-11-22  5:57   ` Baruch Siach

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=20101115161928.GC5981@kroah.com \
    --to=greg@kroah.com \
    --cc=agersh@rambler.ru \
    --cc=akpm@linux-foundation.org \
    --cc=baruch@tkos.co.il \
    --cc=hpa@zytor.com \
    --cc=indan@nul.nu \
    --cc=jslaby@suse.cz \
    --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 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.