[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121016212533.GC21041@kroah.com>
Date: Tue, 16 Oct 2012 14:25:33 -0700
From: Greg KH <gregkh@...uxfoundation.org>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Roland Stigge <stigge@...com.de>, grant.likely@...retlab.ca,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
w.sang@...gutronix.de, jbe@...gutronix.de, plagnioj@...osoft.com,
highguy@...il.com, broonie@...nsource.wolfsonmicro.com,
daniel-gl@....net, rmallon@...il.com
Subject: Re: [PATCH RFC 02/11 v4] gpio: Add sysfs support to block GPIO API
On Tue, Oct 16, 2012 at 11:08:51PM +0200, Linus Walleij wrote:
> On Tue, Oct 16, 2012 at 7:40 PM, Greg KH <gregkh@...uxfoundation.org> wrote:
> > On Tue, Oct 16, 2012 at 07:27:15PM +0200, Linus Walleij wrote:
> >> The thing is, as I've tried to explain but maybe didn't get across,
> >> that these devices don't *have* a parent, and are not part of any
> >> tree.
> >
> > You are passing in a parent device to the device_create() call, where
> > did that pointer come from?
>
> You mean this:
>
> dev = device_create(&gpio_class, desc->chip->dev, MKDEV(0, 0),
> desc, ioname ? ioname : "gpio%u", gpio);
Yes.
> desc->chip->dev is an *optional* pointer to a parent device of
> the GPIO chip (not the GPIO chip itself). It is usually NULL.
Ah, I didn't realize that.
Well, then they turn into "virtual" devices, which are still fine, they
show up in the device tree properly, so all is ok.
> >> They are parentless mock devices, created on-the-fly just to get
> >> sysfs entries.
> >
> > That's fine, well, not the "parentless" part, but that should be trivial
> > to fix, just pass in the correct pointer and you should be fine.
>
> Hm, yeah well, they are orphans mostly.
>
> >> What is needed it to get the device model right in the first
> >> place.
> >
> > I thought it was in the device model already?
>
> GPIO chips are not devices. :-(
Point to the device that the GPIO pins are located on. Be it the cpu,
or platform, or something else. If not, making them "virtual" is fine,
that's what it is there for.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists