linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ian Pilcher <arequipeno@gmail.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>
Subject: Re: How to ensure other module/driver is initialized?
Date: Tue, 24 Jan 2017 10:40:59 -0600	[thread overview]
Message-ID: <6a8fe8d3-024b-1cf7-0e2e-1421042036da@gmail.com> (raw)
In-Reply-To: <CACRpkdYjUKimX+R0nZv5v+rhdUxAUtKv4pPu0dtGAYhEP1Ri7Q@mail.gmail.com>

On 01/24/2017 07:02 AM, Linus Walleij wrote:
> On Thu, Dec 15, 2016 at 8:50 PM, Ian Pilcher <arequipeno@gmail.com> wrote:
>
>> I maintain an out-of-tree kernel module that enables the front-panel
>> LEDs on the Thecus N5550 NAS.
>>
>>   https://github.com/ipilcher/n5550/blob/master/modules/n5550_board.c
>
> Generally I'm not very happy about boardfiles and such stuff being
> maintained out-of-tree.
>
> Is there work ongoing to:
>
> (A) work upstream with this stuff
> (B) convert the whole platform to use device tree
>
> Because that is what is needed for long-term maintenance.

In general, I completely agree with you.  In this case, however, I
don't think that moving the module upstream and/or converting to device
tree is realistic.

I say this because the purpose of my module is to enable the LEDs and
GPIOs in the Thecus N5550 NAS for "generic" x86_64 distributions --
CentOS, Fedora, Debian, Ubuntu, etc.  It has nothing to do with the
Linux-based "firmware" provided by Thecus.  To the best of my knowledge,
the worldwide number of users of this module is in the single digits.

So even if the module were to be accepted upstream (which I tend to
doubt), it's extremely unlikely that any of the aforementioned
distributions would include it in their kernel configuration.

Device tree presents even greater problems.  It's not clear to me that
device tree even works with x86_64, and even if it does, I'm almost
positive that none of the "generic" distributions are going to support
it.

If my understanding of device tree is inaccurate, please do let me
know.  I'd definitely like to replace the "board" module with a
device tree description if it's possible.

Thanks!

-- 
========================================================================
Ian Pilcher                                         arequipeno@gmail.com
-------- "I grew up before Mark Zuckerberg invented friendship" --------
========================================================================

  reply	other threads:[~2017-01-24 16:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-15 19:50 How to ensure other module/driver is initialized? Ian Pilcher
2017-01-24 13:02 ` Linus Walleij
2017-01-24 16:40   ` Ian Pilcher [this message]
2017-01-26 14:51     ` 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=6a8fe8d3-024b-1cf7-0e2e-1421042036da@gmail.com \
    --to=arequipeno@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).