From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752191AbcAAR3W (ORCPT ); Fri, 1 Jan 2016 12:29:22 -0500 Received: from mail-ob0-f180.google.com ([209.85.214.180]:32854 "EHLO mail-ob0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752163AbcAAR3Q (ORCPT ); Fri, 1 Jan 2016 12:29:16 -0500 MIME-Version: 1.0 In-Reply-To: References: <1450792017-7120-1-git-send-email-djkurtz@chromium.org> <20151230172212.GZ16023@sirena.org.uk> <20151231220712.GD16023@sirena.org.uk> Date: Fri, 1 Jan 2016 18:29:15 +0100 Message-ID: Subject: Re: [PATCH] pinctrl: mediatek: convert to arch_initcall From: Linus Walleij To: Matthias Brugger Cc: Daniel Kurtz , Mark Brown , Grant Likely , "linux-arm-kernel@lists.infradead.org" , Yingjoe Chen , Hongzhou Yang , Fabio Estevam , Fabian Frederick , Maoguang Meng , Axel Lin , "open list:PIN CONTROL SUBSYSTEM" , open list , "moderated list:ARM/Mediatek SoC support" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 1, 2016 at 3:27 PM, Matthias Brugger wrote: > On January 1, 2016 3:56:01 AM EET, Daniel Kurtz wrote: >>> It's fairly clear that there's at least a case for simplifying the >>> existing practice here, for example by moving everything into a >>single >>> (perhaps aliased) initcall rather than by randomly picking a level >>per >>> system or by actually fiddling with the link ordering if the case is >>> sufficiently clear that pinctrl in general ought to load earlier than >>it >>> does. >> >>Nothing above sounds like a reason not to merge this patch, however. >>Why should we block useful patches that use existing tools to fix real >>architecture-specific issues until new infrastructure is merged that >>solves general problems? > > I think what Mark means is, that we define some pinctrl_initcall which > is a macro to subsys_initcall (or arch_initcall or similar). We apply this > to all pinctrl drivers including the one from Mediatek. This way at least > we have a common method and changing the behaviour in the future is > easier to handle. That would be pinctrl_soc_initcall() in that case. Just pinctrl_initcall() would assume it's for all drivers and there is a bunch of them that are just fine with simple device_initcall()s. Yours, Linus Walleij