All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Ungerer <gregungerer@westnet.com.au>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Guenter Roeck <linux@roeck-us.net>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Alexandre Courbot <gnurou@gmail.com>,
	Greg Ungerer <gerg@uclinux.org>
Subject: Re: [PATCH 2/2] gpiolib: Defer gpio device setup until after gpiolib initialization
Date: Tue, 5 Apr 2016 09:50:17 +1000	[thread overview]
Message-ID: <5702FDB9.9010806@westnet.com.au> (raw)
In-Reply-To: <CACRpkdacra5WnWtH7qyuxix3fGBoa+6WZJCU5vusQoAaJGZrfw@mail.gmail.com>

Hi Linus,

On 01/04/16 18:16, Linus Walleij wrote:
> On Fri, Apr 1, 2016 at 3:33 AM, Greg Ungerer <gregungerer@westnet.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 don't see any reason we can't just kill it.
It never had any real links to anything under it, only
the usual set of bus sysfs nodes. So the new "/sys/bus/gpio"
has all that and more. So no need for a shim.


> I'm trying to pull all needed functionality into the proper gpiolib
> so we can get some order around the place...

Yep :-)
I'll prepare a patch to remove the coldfire gpio sys bus device.
It is pretty simple in this case.

Regards
Greg

  reply	other threads:[~2016-04-04 23:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-31 15:11 [PATCH 1/2] gpiolib: Do not use devm functions when registering gpio chip Guenter Roeck
2016-03-31 15:11 ` [PATCH 2/2] gpiolib: Defer gpio device setup until after gpiolib initialization Guenter Roeck
2016-04-01  0:29   ` Greg Ungerer
2016-04-01  0:53     ` Guenter Roeck
2016-04-01  1:33       ` Greg Ungerer
2016-04-01  3:31         ` Guenter Roeck
2016-04-01  8:16         ` Linus Walleij
2016-04-04 23:50           ` Greg Ungerer [this message]
2016-04-01  8:14   ` Linus Walleij

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=5702FDB9.9010806@westnet.com.au \
    --to=gregungerer@westnet.com.au \
    --cc=gerg@uclinux.org \
    --cc=gnurou@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    /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.