From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0F631C64EC4 for ; Thu, 9 Mar 2023 13:05:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229835AbjCINFb (ORCPT ); Thu, 9 Mar 2023 08:05:31 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49060 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230333AbjCINF2 (ORCPT ); Thu, 9 Mar 2023 08:05:28 -0500 Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CC711943BD for ; Thu, 9 Mar 2023 05:05:25 -0800 (PST) Received: by mail-yb1-xb2e.google.com with SMTP id t4so1777229ybg.11 for ; Thu, 09 Mar 2023 05:05:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1678367125; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=bnrANUjQ+Lrk34FiPIjYMi1eTOEaz1NM5RutVNwfpUA=; b=qQQA9vbSXGASTDa7L5itFUoKijRQMaQXHC+Tb184QLgGEu/WECKXsVuu31At3goYiU 6TOsM6CDZN0NTXtfa1qwowt39JcLnz2e1kIFYU8wS9hN5aOv+je3AWUZ0tDdmqkXjjTd RuGEPIXiD1c/kF7NrYdcsz50PIdMlMvhnFV+CzLAD1K5MiWm7FaXg+DifUDBXhPazuOb XNF9UDbBxOqg2FJSOjgPgezyhWEhSkyuUv5D2Fpihu3/h1Fe/OBW4/ZHoLVBv3Sr+95b Hujy2sd663h8k2z23GEuD4X0GWB+qGSOls202Wmk7MW4t+06uU6HavrmiOSXGNkxOXAs tohg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678367125; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=bnrANUjQ+Lrk34FiPIjYMi1eTOEaz1NM5RutVNwfpUA=; b=fCUOj4fdTYbbHipPOSKpQNg4tA0AMZbp6lQvtmPDe2zh95oXkAALF3ZGzmDAVPGpXy vbbk6QSX3n3IKCNz0XBwz3YYKy/CDZnN3EAB7PojGSQ19wf1rV6h3SEpjgNaxpQmZOHb 7NlXZNict1AjYHAFM4Ydy1d/KWWllFOY/3hOHuo4ZS+5IUn7G1ajBCkq3zoCDAYZXITD viN3xqT9K56ikFIE/zeytvoLs28h8W2LdItHt+/vDfXNeh7tZw3mxEjDpGL7ZFIJGRh4 A2naCujZpuE06VQfoa9mDhI4kj67XPSNb7zJnVWi+uLZVoRmlajXlAqTr2hDwukKn3bl aRHg== X-Gm-Message-State: AO0yUKUcQZUjch7nnfE4x7djyIJxi28UHV77x/2pTIkNDe77jZWZyUSI YbQz9xf9sVeSbY8rftzubjgctQQkyyP0XfF1rNEpGQ== X-Google-Smtp-Source: AK7set/5Ta1ixeaI4lHltLEUpPHdNMmHGWIe1dSlPNgQRXkT0BZkj8fP0sy+IfcYvb8w777c9icInkovPtAqq5v+Y5s= X-Received: by 2002:a5b:1cb:0:b0:9f5:af8a:3b61 with SMTP id f11-20020a5b01cb000000b009f5af8a3b61mr13349059ybp.4.1678367125084; Thu, 09 Mar 2023 05:05:25 -0800 (PST) MIME-Version: 1.0 References: <20230306090014.128732-1-biju.das.jz@bp.renesas.com> <20230306090014.128732-2-biju.das.jz@bp.renesas.com> In-Reply-To: From: Linus Walleij Date: Thu, 9 Mar 2023 14:05:13 +0100 Message-ID: Subject: Re: [PATCH v6 01/13] pinctrl: core: Add pinctrl_get_device() To: Biju Das Cc: "andy.shevchenko@gmail.com" , "linux-gpio@vger.kernel.org" , Geert Uytterhoeven , Thierry Reding , =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= , Prabhakar Mahadev Lad , "linux-renesas-soc@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Tue, Mar 7, 2023 at 9:13 AM Biju Das wrote: > > Mon, Mar 06, 2023 at 09:00:02AM +0000, Biju Das kirjoitti: > > > Add pinctrl_get_device() to find a device handle associated with a > > > pincontrol group(i.e. by matching function name and group name for a > > > device). This device handle can then be used for finding match for the > > > pin output disable device that protects device against short circuits > > > on the pins. > > > > Not sure I understand the use case. Please, create a better commit message. > > OK, Basically pinmux_enable_setting allows exclusive access of pin to a device. > It won't allow multiple devices to claim a pin. So what is the use case? Which two devices need to use the same pin at the same time? You can already: 1) Use the same pin with different devices at different times, because pin configs can be changed arbitrarily at runtime, see for example: drivers/i2c/muxes/i2c-demux-pinctrl.c 2) Mux a pin to a certain device *and* use it for GPIO at the same time, all that is needed is to set .strict to false in struct pinmux_ops. This should be false if e.g. the GPIO can be used to "sample" the output of a I2C block connected to the same pins, so the two functions (I2C and GPIO) are not electrically decoupled. So do you really have a use case where two devices need to use the same pin at the same time? I've seen much but I haven't seen this before! Which two devices are that? Yours, Linus Walleij