From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935059AbcKKURr (ORCPT ); Fri, 11 Nov 2016 15:17:47 -0500 Received: from mail-qk0-f169.google.com ([209.85.220.169]:36840 "EHLO mail-qk0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756665AbcKKURo (ORCPT ); Fri, 11 Nov 2016 15:17:44 -0500 MIME-Version: 1.0 In-Reply-To: <20161025210221.9150-2-tony@atomide.com> References: <20161025210221.9150-1-tony@atomide.com> <20161025210221.9150-2-tony@atomide.com> From: Linus Walleij Date: Fri, 11 Nov 2016 21:17:42 +0100 Message-ID: Subject: Re: [PATCH 1/5] pinctrl: core: Use delayed work for hogs To: Tony Lindgren Cc: Haojian Zhuang , Masahiro Yamada , Grygorii Strashko , Nishanth Menon , "linux-gpio@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Linux-OMAP 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 Tue, Oct 25, 2016 at 11:02 PM, Tony Lindgren wrote: > Having the pin control framework call pin controller functions > before it's probe has finished is not nice as the pin controller > device driver does not yet have struct pinctrl_dev handle. > > Let's fix this issue by adding deferred work for hogs. This is > needed to be able to add pinctrl generic helper functions. > > Note that the pinctrl functions already take care of the necessary > locking. > > Signed-off-by: Tony Lindgren I don't see why this is necessary? The hogging was placed inside pinctrl_register() so that any hogs would be taken before it returns, so nothing else can take it before the controller itself has the first chance. This semantic needs to be preserved I think. > + schedule_delayed_work(&pctldev->hog_work, > + msecs_to_jiffies(100)); If we arbitrarily delay, something else can go in and take the pins used by the hogs before the pinctrl core? That is what we want to avoid. Hm, 100ms seems arbitrarily chosen BTW. Can it be 1 ms? 1 ns? I'm pretty sure that whatever it is that needs to happen before the hog work runs can race with this delayed work under some circumstances (such as slow external expanders on i2c). It should be impossible for that to happen and I don't think it is? Yours, Linus Walleij