Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp1997926imm; Thu, 11 Oct 2018 03:28:46 -0700 (PDT) X-Google-Smtp-Source: ACcGV60/2wy4ZAj8LODKVJwd7+MLuyOH9tfWUfThTPxpNB5IiPb2ZH5bS4OJPd7I03YwmzWYDNJJ X-Received: by 2002:a62:7604:: with SMTP id r4-v6mr986888pfc.230.1539253726421; Thu, 11 Oct 2018 03:28:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539253726; cv=none; d=google.com; s=arc-20160816; b=E759GIovQgwebnICsE6kvPCxm2yiuWIn80JVJjevXlk9jXpOLUS30y0Fc7QamKz7j7 3zrTqXZeO45uVxOcll0wlMuHZvIVUNrxpZjacIFPEKD9xmmXaUzSq0JD2tYPRl86vouR KY2HskhSOlmPd5lfcyvd5xQVb9ocno5s7WYKhsjqKY/tp1mMVrjQF3InZO+bifqhhete p3oTq6/QoxKju21074rKk2XrtQXFo6zNEiTfT0t5FyZbA1CVBwewSPizA5r+zb+kZFTo NxqxChQMOSSUlol8NTa8aSaB1qEXr/+sLm/N6sdS1Yz1lsdhNCcm1GgqiDVW28klB6v2 EpnA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Bu+dNDN+pi7r9sR32FybTjRP1hAfyAp8sD32JdpROJo=; b=Zi2Nlr08M5owVy45DxoZwIdlKJj8PLqA3fwg/Ib9cU6bCkNpPyjeAvEUSS3tt1Qqvk k4Yfm7ACxcEbgvz2S+8jSsqD1hgs+sXT5hQ+PTtD0Z38QewvSwkRe+Qvhi25D04GqLcw AEdzt2plMBbCUCUMELGPqxaX3gNjC2bzlDifgkpsmVlkjf2Q01wiFcFHZ/pwDf9leGpJ GFTG/ui1j6Fx6Gd1AJYQbxtK6XP9lK0f95nYQUg+4PqAIPTmu2K/zhtKIh90B1HVYqk6 TbGSuWgi/+JeG8FZz4eO29xJew3ghEmGZM7QdxoPcOBJlp2siUYeAdJa+u9Mx84eM5iz voYg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=APsNtlpd; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b13-v6si26584261pgj.154.2018.10.11.03.28.32; Thu, 11 Oct 2018 03:28:46 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=APsNtlpd; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728333AbeJKQ4D (ORCPT + 99 others); Thu, 11 Oct 2018 12:56:03 -0400 Received: from mail-io1-f65.google.com ([209.85.166.65]:37213 "EHLO mail-io1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726047AbeJKQ4C (ORCPT ); Thu, 11 Oct 2018 12:56:02 -0400 Received: by mail-io1-f65.google.com with SMTP id m16-v6so6078531ioj.4 for ; Thu, 11 Oct 2018 02:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Bu+dNDN+pi7r9sR32FybTjRP1hAfyAp8sD32JdpROJo=; b=APsNtlpdRxThic+ZmwyxRL02xy6xZIRKREcL5NojTmUvZf39HcNN69h+DWwW+9kNA5 YqdNvDJjvLVU07JRUkAk3jET5ZWRIZpYa5pv3B9/5M+sytCsH+Y8x4mGZf9b1vREOFiO hbOh1zCutjOLm/cSZVV2s6hG4RNppn1p3hFOk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Bu+dNDN+pi7r9sR32FybTjRP1hAfyAp8sD32JdpROJo=; b=saHU+h11L8XnK/XMfB/j9J55JXkrceeTiR9dRCAvxZkU13Yt3VgeW842fmYur42ohk Nw/NVel2RyrTnnqDJH6bZh59sfZZICSF+hwiieorcRS6jeQQxjI4xjeR46WCJExRa5sR 6ebXXrbJ3FOlS54rdOktKIej+cdKPFChu7HkYUHyp0WJa6jNk65dTLBe6tbIMjA84moh gkdbAMSsnjH5BtuS9l/LPSJGGxcJIog5EHDPQj85FBYUkNeRFVfsRDNHK5jsfOIIPXEX MLnJpJT3PLFNja20wv1tfS7YX9NN6jE0/BgRT8SCFl2MiBKp6gKqnxK8127/i5w0HnYV +p3Q== X-Gm-Message-State: ABuFfogyU46qOIcJNJYX6bmIVTXeuw6kL7jpOnmHUxpUTnKsKBGjGtEq AKShfkpGHKAy7QhUhh4fhssma0H0G9lbcDTZXVa/yzdS X-Received: by 2002:a6b:6302:: with SMTP id p2-v6mr226065iog.175.1539250175617; Thu, 11 Oct 2018 02:29:35 -0700 (PDT) MIME-Version: 1.0 References: <20180906122436.25610-1-linus.walleij@linaro.org> <20181011090112eucas1p286d8c1edfc1a2a207d8a11c5ad7eb20e~cglSx9qcr2394623946eucas1p2y@eucas1p2.samsung.com> In-Reply-To: <20181011090112eucas1p286d8c1edfc1a2a207d8a11c5ad7eb20e~cglSx9qcr2394623946eucas1p2y@eucas1p2.samsung.com> From: Linus Walleij Date: Thu, 11 Oct 2018 11:29:22 +0200 Message-ID: Subject: Re: [PATCH v7] regulator: fixed: Convert to use GPIO descriptor only To: Marek Szyprowski Cc: Liam Girdwood , Mark Brown , "linux-kernel@vger.kernel.org" , Janusz Krzysztofik , Alexander Shiyan , Haojian Zhuang , Aaro Koskinen , Mike Rapoport , Robert Jarzmik , Philipp Zabel , Daniel Mack , Marc Zyngier , jacopo , Geert Uytterhoeven , Russell King Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 11, 2018 at 11:01 AM Marek Szyprowski wrote: > I've just noticed that this patch causes regression on Samsung > Exynos4412-based Trats2 board. Conversion to GPIO descriptor breaks > operation when regulators used shared GPIO: sii9234 i2c driver > is not able to get vcc33mhl regulator (it uses shared GPIO enable > line with vsil12 regulator). So I guess this means that this physical GPIO line will enable the vcc33mhl and the vsil12 regulators at the same time? > This issue has been already pointed in case of commits: > 37fa23dbccbd97663acc085bd79246f427e603a1 > d1dae72fab2c377ff463742eefd8ac0f9e99b7b9 > ab4d11e2c2329cf7cb7be31ff22489aae4dee5dc A big sorry for my ignorance, I guess the information overload on the mailing list just makes me miss the important points. I'll try to be better, sadly I constantly fail to keep everything in mind and constantly break things like this. > Maybe it would be better to first solve the handling of shared enable > GPIO in the descriptor-based interface before converting more regulators > and stepping into this issue again? I am trying to solve it, but I just don't have systems to reproduce all kinds of things. It's a bit stressful since this is one of those runtime things that is hard to test when devising a patch for systems I don't have. I am kind of relying on system maintainers to test things. I was aware of the usecase "several consumers takes the same GPIO line" (Mark told me several times...) so it was in the back of my mind, but it's just hard to see when we were gonna run into it. So it is the fixed regulators, on Samsung boards, I see. Anyways. Let's try to fix it now then instead of me constantly hitting this and breaking it. It happens because it is just unintuitive so I share your frustration. I don't want to generally make it possible for a gpio line to be retrieved nonexclusively. We need the semantics to help people do the right thing. So I was thinking to introduce gpiod_get_nonexclusive() to explicitly handle this case for the few systems that use shared GPIO lines, let me see what I can do. Yours, Linus Walleij