Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756671AbcCaMsP (ORCPT ); Thu, 31 Mar 2016 08:48:15 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:57585 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752806AbcCaMsN (ORCPT ); Thu, 31 Mar 2016 08:48:13 -0400 Subject: Re: [PATCH] gpio: Do not accept gpio chip additions before gpiolib initialization To: Alexandre Courbot References: <1459275638-11717-1-git-send-email-linux@roeck-us.net> <56FB9952.1030503@roeck-us.net> Cc: Linus Walleij , "linux-gpio@vger.kernel.org" , Linux Kernel Mailing List From: Guenter Roeck Message-ID: <56FD1C8E.60405@roeck-us.net> Date: Thu, 31 Mar 2016 05:48:14 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated_sender: linux@roeck-us.net X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roeck-us.net X-Get-Message-Sender-Via: bh-25.webhostbox.net: authenticated_id: linux@roeck-us.net X-Authenticated-Sender: bh-25.webhostbox.net: linux@roeck-us.net X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2134 Lines: 46 On 03/30/2016 10:57 PM, Alexandre Courbot wrote: > On Wed, Mar 30, 2016 at 6:16 PM, Guenter Roeck wrote: >> On 03/30/2016 01:37 AM, Alexandre Courbot wrote: >>> >>> On Wed, Mar 30, 2016 at 3:20 AM, Guenter Roeck wrote: >>>> >>>> Since commit ff2b13592299 ("gpio: make the gpiochip a real device"), >>>> attempts to add a gpio chip prior to gpiolib initialization cause the >>>> system to crash. Dump a warning to the console and return an error >>>> if the situation is encountered. >>> >>> >>> Mmm I see the problem but this could seriously delay the availability >>> of some GPIOs that are useful for early system boot. >>> >>> I have not followed the GPIO device patches as closely as I should >>> have, but shouldn't you be able to register a GPIO chip without >>> immediately presenting it to user-space, for internal kernel needs? If >>> gpiolib is not initialized, then device-related operations would be >>> skipped, and gpiolib_dev_init() could then parse the list of >>> registered chips and fix them up when it gets called. >>> >>> Again, I'm speaking without real knowledge here, but that pattern >>> seems more resilent to me. >>> >> You are absolutely right, but my knowledge of gpiolib is not good enough >> to make that change. See this as a band-gap; it is better than just >> crashing. > > Actually, the following may be simpler: > > Why not add a check in gpiochip_add_data() that will directly call > gpiolib_dev_init() if required? Then gpiolib_dev_init() could also > check whether it has already been called in that context and become a > no-op for when it is later called from core_initcall. Is there > anything that would prevents this from being a viable fix? > That was my first solution. Unfortunately, it doesn't work. It appears that the calls made by gpiolib_dev_init() have dependencies themselves. Though maybe I messed up - feel free to try yourself. As mentioned in the other thread, I started looking into the solution you suggested above. It should work, but it will take (me) a while to implement it. Until then, guess we'll see more breakage. Guenter