From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750865AbdAXQlE (ORCPT ); Tue, 24 Jan 2017 11:41:04 -0500 Received: from mail-ot0-f193.google.com ([74.125.82.193]:33881 "EHLO mail-ot0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750718AbdAXQlB (ORCPT ); Tue, 24 Jan 2017 11:41:01 -0500 Subject: Re: How to ensure other module/driver is initialized? To: Linus Walleij References: <180b9075-7db0-1708-50f4-622333de2049@gmail.com> Cc: "linux-kernel@vger.kernel.org" , "linux-gpio@vger.kernel.org" From: Ian Pilcher Message-ID: <6a8fe8d3-024b-1cf7-0e2e-1421042036da@gmail.com> Date: Tue, 24 Jan 2017 10:40:59 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/24/2017 07:02 AM, Linus Walleij wrote: > On Thu, Dec 15, 2016 at 8:50 PM, Ian Pilcher 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" -------- ========================================================================