From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752175AbeERPOA (ORCPT ); Fri, 18 May 2018 11:14:00 -0400 Received: from mx07-00178001.pphosted.com ([62.209.51.94]:38368 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751363AbeERPN5 (ORCPT ); Fri, 18 May 2018 11:13:57 -0400 From: Amelie DELAUNAY To: Lee Jones , Linus Walleij CC: Rob Herring , Mark Rutland , Russell King , Alexandre TORGUE , Maxime Coquelin , "open list:GPIO SUBSYSTEM" , "linux-kernel@vger.kernel.org" , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Linux ARM Subject: Re: [PATCH 1/5] dt-bindings: pinctrl: document the STMFX pinctrl bindings Thread-Topic: [PATCH 1/5] dt-bindings: pinctrl: document the STMFX pinctrl bindings Thread-Index: AQHT0XoURhB9br3sCUChmBQl/h9UpqQDmnwAgA9bIgCAFBx/gIALa4OAgAALVoCAAQVhAIABoPiAgABrK4CAABaTgA== Date: Fri, 18 May 2018 15:13:26 +0000 Message-ID: References: <1523440025-18077-1-git-send-email-amelie.delaunay@st.com> <1523440025-18077-2-git-send-email-amelie.delaunay@st.com> <20180416181940.4b5z4svbde3ompij@rob-hp-laptop> <55392fe7-20d2-9447-60f9-4bd226b60195@st.com> <20180517063640.GK5130@dell> <28c374e6-b440-f785-b371-03fe15c8bc4b@st.com> <20180518135237.GQ5130@dell> In-Reply-To: <20180518135237.GQ5130@dell> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.75.127.46] Content-Type: text/plain; charset="utf-8" Content-ID: <764FFDF114BFA64E9115C4C84910CFB7@st.com> MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-05-18_06:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id w4IFE4Bu029432 On 05/18/2018 03:52 PM, Lee Jones wrote: > On Fri, 18 May 2018, Amelie DELAUNAY wrote: > >> On 05/17/2018 08:36 AM, Lee Jones wrote: >>> On Wed, 16 May 2018, Amelie DELAUNAY wrote: >>> >>>> >>>> >>>> On 05/16/2018 04:20 PM, Linus Walleij wrote: >>>>> On Wed, May 9, 2018 at 9:56 AM, Amelie DELAUNAY wrote: >>>>> >>>>>> Indeed, stmfx has other functions than GPIO. But, after comments done >>>>>> here: [1] and there: [2], it has been decided to move MFD parent/GPIO >>>>>> child drivers into a single PINCTRL/GPIO driver because of the following >>>>>> reasons: >>>>>> - Other stmfx functions (IDD measurement and TouchScreen controller) are >>>>>> not used on any of the boards using an stmfx and supported by Linux, so >>>>>> no way to test these functions, and no need to maintain them while they >>>>>> are not being used. >>>>>> - But, in the case a new board will use more than GPIO function on >>>>>> stmfx, the actual implementation allow to easily extract common init >>>>>> part of stmfx and put it in an MFD driver. >>>>>> >>>>>> So I could remove gpio sub-node and put its contents in stmfx node and >>>>>> keep single PINCTRL/GPIO driver for the time being. >>>>>> Please advise, >>>>> >>>>> I would normally advice to use the right modeling from the start, create >>>>> the MFD driver and spawn the devices from there. It is confusing >>>>> if the layout of the driver(s) doesn't really match the layout of the >>>>> hardware. >>>>> >>>>> I understand that it is a pain to write new MFD drivers to get your >>>>> things going and it would be "nice to get this working really quick >>>>> now" but in my experience it is better to do it right from the start. >>>>> >>>> >>>> Hi Linus, >>>> >>>> Thanks for your advice. I understand the point. >>>> So, the right modeling would be to: >>>> - create an MFD driver with the common init part of stmfx >>>> - remove all common init part of stmfx-pinctrl driver and keep only all >>>> gpio/pinctrl functions. >>>> >>>> I will not develop the other stmfx functions (IDD measurement driver and >>>> TouchScreen controller driver) because, as explained ealier, they are >>>> not used on any of the boards using an stmfx and supported by Linux, so >>>> no way to test these functions, and no need to maintain them while they >>>> are not being used. >>>> >>>> Lee, are you OK with that ? >>> >>> I missed a lot of this conversation I think, but from what I've read, >>> it sounds fine. >>> >> >> I summarize the situation: >> - I still don't have an official datasheet for STMFX device which could >> justify the use of an MFD driver; >> - the MFD driver will contain the STMFX chip initialization stuff such >> as regmap initialization (regmap structure will be shared with the >> child), chip initialization, global interrupt management; >> - there will be only one child (GPIO/PINCTRL node) for the time being. >> >> So, is "MFD driver + GPIO/PINCTRL driver" the right modeling, and does >> it still sound fine after this summary ? :) > > It is starting to sound like there will only ever be one child device, > which starts to cross the line into "this is not an MFD" (M = Multi) > territory. > ... for the time being. So, Linus, Lee, is it possible to find common ground ?