From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934559AbdK2RgB (ORCPT ); Wed, 29 Nov 2017 12:36:01 -0500 Received: from mail-qt0-f181.google.com ([209.85.216.181]:38944 "EHLO mail-qt0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932335AbdK2RfU (ORCPT ); Wed, 29 Nov 2017 12:35:20 -0500 X-Google-Smtp-Source: AGs4zMYu/1ZVaculdYIyx02AcddQEeU+K6nVtKmtMeQw7uA0d6P0YzPGVZV+4ywrgSau3VzWRrcGOA== Subject: Re: [PATCH v2 1/2] pinctrl: Allow a device to indicate when to force a state To: Tony Lindgren Cc: linux-gpio@vger.kernel.org, Linus Walleij , Rob Herring , Mark Rutland , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , open list , ckeepax@opensource.cirrus.com, ckeepax@opensource.wolfsonmicro.com, swarren@nvidia.com, andy.shevchenko@gmail.com, alcooperx@gmail.com, bcm-kernel-feedback-list@broadcom.com References: <20171102231551.16220-1-f.fainelli@gmail.com> <20171102231551.16220-2-f.fainelli@gmail.com> <20171129170102.GH28152@atomide.com> From: Florian Fainelli Message-ID: Date: Wed, 29 Nov 2017 09:35:14 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20171129170102.GH28152@atomide.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/29/2017 09:01 AM, Tony Lindgren wrote: > * Florian Fainelli [171102 23:18]: >> It may happen that a device needs to force applying a state, e.g: >> because it only defines one state of pin states (default) but loses >> power/register contents when entering low power modes. Add a >> pinctrl_dev::flags bitmask to help describe future quirks and define >> PINCTRL_FLG_FORCE_STATE as such a settable flag. > > It makes sense to tag the existing state with the context loss > information as otherwise we'll be duplicating the state in the > pinctrl driver potentially for hundreds of pins. > > Maybe this patch description should clarify that it's the > pinctrl device restoring the pin state, not the pinctrl > consumer devices? > > So maybe just "a pinctrl device needs to force apply a state" > instead of just device above? It's a bit more involved than that, the pinctrl consumer device might want to restore a particular state by calling pinctrl_select_state(), however, because of the (p->state == state)check, the pinctrl provider driver has no chance of making that call do the actual HW programming. -- Florian