Subject: [PATCH 1/4 v4] drivers: create a pin control subsystem

From: [email-masked] (Greg KH)
Date: Fri, 19 Aug 2011 09:52:52 -0700

On Fri, Aug 19, 2011 at 04:36:28PM +0200, Arnd Bergmann wrote:
> On Friday 19 August 2011, Linus Walleij wrote:
> > On Fri, Aug 19, 2011 at 12:48 PM, Jamie Iles <[email-masked]> wrote:
> > 
> > >> +static struct class pinctrl_class = {
> > >> +     .name = "pinctrl",
> > >> +     .dev_release = pinctrl_dev_release,
> > >> +     .dev_attrs = pinctrl_dev_attrs,
> > >> +};
> > >
> > > Greg K-H has mentioned in the past that class is now deprecated for new
> > > use and that a bus_type should be used instead.
> > 
> > Can you provide a reference with some detail?
> > The pin control devices are usually aleady on a bus like the
> > platform_bus or amba_bus or i2c_bus, then they register a
> > class device in this case.
> > 
> > The kerneldoc documentation says
> > "A bus is a channel between the processor and one or more devices."
> > 
> > This isn't the case here.
> > 
> > Anyhthing that help me understand this is appreciated, Arnd?
> 
> Taking Greg on Cc as well.
> 
> The main difference between a normal device and a class device is
> that one is linked from /sys/bus/*/devices/* and the other is linked
> from /sys/class/*/*. However, they both live in /sys/devices/.../*
> as directories.
> 
> I always liked the separation between the two, although there are
> a few cases where there is a grey area (e.g. /sys/bus/hid or
> /sys/class/mmc_host) and the abstraction doesn't really fit.
> 
> IIRC Greg would prefer now to never have had the distinction
> and wants to make all future uses use a bus_type.

Yes, that is totally correct.  Kay has also written much more about this
and why this is the way forward many times in the past, see lkml
archives for the details if anyone is interested.

thanks,

greg k-h