Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758794AbcC3Ihf (ORCPT ); Wed, 30 Mar 2016 04:37:35 -0400 Received: from mail-ig0-f175.google.com ([209.85.213.175]:37215 "EHLO mail-ig0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752901AbcC3Ihc (ORCPT ); Wed, 30 Mar 2016 04:37:32 -0400 MIME-Version: 1.0 In-Reply-To: <1459275638-11717-1-git-send-email-linux@roeck-us.net> References: <1459275638-11717-1-git-send-email-linux@roeck-us.net> From: Alexandre Courbot Date: Wed, 30 Mar 2016 17:37:12 +0900 Message-ID: Subject: Re: [PATCH] gpio: Do not accept gpio chip additions before gpiolib initialization To: Guenter Roeck Cc: Linus Walleij , "linux-gpio@vger.kernel.org" , Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 926 Lines: 18 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.