From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 47F771F19A; Thu, 20 Feb 2025 01:45:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740015951; cv=none; b=Cp9jqUdh/HN9HFPeVWgj6TPAxZYK3YI/UegJnqg82Gk3bhb50G7bzK5oOQ66hE/I6A1Rn1JrH2kn44V2DhdvwEugssCqGAk00N6IurBaWTGh3zbG2nnpJ8Pq1dlx/BUVjVKSP4Fw5SiY1AZOy/+JV4cuT8fhdspwpFNUJeuT1H4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740015951; c=relaxed/simple; bh=9irbtGVWQj8eLhc5O42ch0DohPLL2OQmuJNb1bG37ZM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XG3goz6Dczz6OqgjkiTKpCB54PM5tjRukSlxuKVJrsBVZT3TFqD4UEBjjdg805/5mQbiRxovGoAsQQPbkPNDW/yWyuYh0+ZEdnOeTyS5yL97M1uus3fqy4O71eEB9eXC/NmaUaUSBdG5/8n+OecQtUrjUuCHw3a7l/CHvJAqJS0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TQR0o9Gv; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TQR0o9Gv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 17646C4CED1; Thu, 20 Feb 2025 01:45:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1740015950; bh=9irbtGVWQj8eLhc5O42ch0DohPLL2OQmuJNb1bG37ZM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TQR0o9GvMeGIOLknSOOAuwSnE1/m4pSPPZmKSQFEqHVDzAh6g1XNFC82sWuK3BXzh JP8AuxUjse5a6Vx4dcXyuhwZodZD68zz0TmzuGULFHVn5iYzRbdk5eGFaqkYgwCI5r 1Ikrzi6cyBWFU13D2fOHcPZtv5tGiLKjj+VawXSoAOXSRCTOMtCHDbDegTVQpY1LGr l8+EzcCb9dk6k6XIDrpEx4RM2PftUlva7qfRs29WTsjW0ThOtT/HY9IouUPUjLGG5F 7cg1brC8uiyKa2hM27hfBc0v9jqFPcY0/LqMHSBSwfdzxJYfUX+AdOo88/mf4P+mCo X2aytNNmfzdvw== Date: Thu, 20 Feb 2025 01:45:47 +0000 From: Mark Brown To: James Calligeros Cc: Liam Girdwood , Jaroslav Kysela , Takashi Iwai , Shenghao Ding , Kevin Lu , Baojun Xu , Dan Murphy , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Shi Fu , Jean Delvare , Guenter Roeck , Alyssa Rosenzweig , Martin =?utf-8?Q?Povi=C5=A1er?= , Hector Martin , linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, asahi@lists.linux.dev, linux-hwmon@vger.kernel.org, Neal Gompa Subject: Re: [PATCH v2 20/29] ASoC: tas2764: Add SDZ regulator Message-ID: References: <20250218-apple-codec-changes-v2-0-932760fd7e07@gmail.com> <20250218-apple-codec-changes-v2-20-932760fd7e07@gmail.com> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="L0ausYZ/FTrIXK1l" Content-Disposition: inline In-Reply-To: X-Cookie: Editing is a rewording activity. --L0ausYZ/FTrIXK1l Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 19, 2025 at 02:47:04PM +1000, James Calligeros wrote: > On Wed, Feb 19, 2025 at 1:33=E2=80=AFAM Mark Brown w= rote: > > On Tue, Feb 18, 2025 at 06:35:54PM +1000, James Calligeros wrote: > > I get that the reference counting that the regulator API does is useful > > here but this isn't a regulator so shouldn't be exposed as such, > > particularly since this winds up being visible in the DT ABI. I > > could've sworn that someone did some helpers for this case but now I go > > looking I can't find them, we certainly don't use any in the regulator > > core. > From what I recall, no attempt at shared GPIO infrastructure has actually > landed. The multiple {de}assertions of SDZ put each chip on the same line Yeah, I can't find anything. Perhaps I was thinking of the reset API, most of the other users were reset lines so it's plausible someone started and then just ended up with the reset API instead. > into an unusable state that requires a full power cycle to clear, so > we can't live without > handling the shared GPIO somewhat sensibly. > One alternative off the top of my head is adding a dummy reset controller > to the DTs and integrating it into the ASoC machine driver (which we have > downstream). We could then put the GPIO behind a shared reset line, and h= it > that instead of the GPIO. This does seem a little complex/odd, and IIRC we > considered this at some point and decided against it. I'm not sure that's particularly better than the regulator version TBH, it's still got the problem of showing up in the device ABI. > Is there any other option that may work here? I'm open to ideas. Perhaps it's time to bite the bullet and do the shared GPIO API? regulator could certainly use it (and has a bunch of code, we could probably just pull that out and wrap an API around it?) and now there's this too. You could possibly also open code, but that does beg the question about the shared API. --L0ausYZ/FTrIXK1l Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAme2iUoACgkQJNaLcl1U h9CBlwf/Ub4h2DWpJglm2UVUSMy1p+jAgsQRt9EndRI/Ud+eqYFTizBKQyKwah4/ 4BDSMQ0dIjhPBrArdfTm5Vsdj3TqgOyxaVQarJ18XKXoq9TM2JMpNr4xydKb43bl FvYaraHXdTwE/yx/gWaM5/lfx5JXf4yngatnf1Qz3vec5QeapYywRoWMVtBW1fBB rkKKv25XTHzG8D6DWK32PQnk1saKSdn6Uwx5f2qcS0OTwxCvK6mTq1/4cWE6JUGl tmY5wtcVMTSCxcCB3Kmp8y//HbNM+vHVTlm7KUQMg+jhf/Ydkq9CaYVX7A/QV/b2 C1aD3TtPwl5KxBweUygcLU86e2qRQg== =z1+I -----END PGP SIGNATURE----- --L0ausYZ/FTrIXK1l--