[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdacra5WnWtH7qyuxix3fGBoa+6WZJCU5vusQoAaJGZrfw@mail.gmail.com>
Date: Fri, 1 Apr 2016 10:16:29 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Greg Ungerer <gregungerer@...tnet.com.au>
Cc: Guenter Roeck <linux@...ck-us.net>,
"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Alexandre Courbot <gnurou@...il.com>,
Greg Ungerer <gerg@...inux.org>
Subject: Re: [PATCH 2/2] gpiolib: Defer gpio device setup until after gpiolib initialization
On Fri, Apr 1, 2016 at 3:33 AM, Greg Ungerer <gregungerer@...tnet.com.au> wrote:
> On 01/04/16 10:53, Guenter Roeck wrote:
>> Probably coldfire ?
>>
>> arch/m68k/coldfire/gpio.c:
>
> Yes, that is the one.
>
>> static struct bus_type mcfgpio_subsys = {
>> .name = "gpio",
>> .dev_name = "gpio",
>> };
>>
>> No idea what to do about that. Can that bus be renamed ?
>
> Yeah, it could. But is it even necessary at all now?
>
> I am thinking I could remove the subsys_system_register(&mcfgpio_subsys, NULL)
> call from that coldfire/gpio.c. Doing that certainly cleans up the
> boot. There was nothing much under the old coldfire /sys/gpio other than
> the standard devices/drivers/etc. And the new gpio api ofcourse has all
> that as well.
Please kill it if you can. Or are there userspaces for
coldfire that use this? In that case we need some compatibility
shim for them.
I'm trying to pull all needed functionality into the proper gpiolib
so we can get some order around the place...
Yours,
Linus Walleij
Powered by blists - more mailing lists