From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755435AbdJIVKh (ORCPT ); Mon, 9 Oct 2017 17:10:37 -0400 Received: from mail-it0-f52.google.com ([209.85.214.52]:52245 "EHLO mail-it0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751676AbdJIVKf (ORCPT ); Mon, 9 Oct 2017 17:10:35 -0400 X-Google-Smtp-Source: AOwi7QCdYoXa1zmLmamtGjzt9VTUQkP0PCyTezwJBZh3g5zGV41nEy6j0G4oIwtgOyeveK+gvtG4bmCyg4tvDSnRifk= MIME-Version: 1.0 In-Reply-To: <20170929101503.6769-1-ckeepax@opensource.cirrus.com> References: <20170929101503.6769-1-ckeepax@opensource.cirrus.com> From: Linus Walleij Date: Mon, 9 Oct 2017 23:10:34 +0200 Message-ID: Subject: Re: [PATCH 0/4] Add support for muxing individual pins To: Charles Keepax , ext Tony Lindgren Cc: "linux-gpio@vger.kernel.org" , "linux-kernel@vger.kernel.org" , patches@opensource.cirrus.com, Bjorn Andersson , Stephen Warren 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, Sep 29, 2017 at 12:14 PM, Charles Keepax wrote: > This series add support for muxing individual pins within > pin mux, rather than just whole groups. Mainly, I had two > motivations here, one to avoid the need to add loads of groups > containing individual pins and hardware that actually has some > internal concept of groups of pins, and disambiguating that from > individual pin muxing. I have marked it as RFC to just get > peoples opinions at this stage, although it should be pretty well > tested. Sorry about the amount of files touched in patch 2 it > would be possible to drop it from the chain although it leaves > the field rather inaccurately named. > > Also I have left all the existing code paths parsing all mux > options as groups from DT, and added a new helper to unlock the > pin based functionality this should ease the transition across. There is currently a driver in the pin control subsystem that handles individual pins and that is pinctrl-single.c. The driver is deployed for single pins muxed by a single register, and if this infrastructure is to be deployed it must be applied also in pinctrl-single. We cannot have several ways of doing the same thing, that way lies madness. So you need Tony Lindgren's review and direction on this patch series. I see the problem you are setting out to solve. I too have ran into the situation (on systems such as Qualcomm's) where single-pin groups are more rule than exception. It would be good to alleviate this and handle it in the core somehow. Yours, Linus Walleij