From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 0CBF52CA7 for ; Wed, 12 Jan 2022 09:34:18 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 37BCF5C01D9; Wed, 12 Jan 2022 04:34:18 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Wed, 12 Jan 2022 04:34:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=nSi69K8gaCgxD8PERPpX2MbEXfG odendEfrDj5aR6zg=; b=PXInPjp7CShsxgmDyZXuJmRtSJ1aWAcINblm17yKHuG uN2NBTHcY8rrYLGDBkvgd05VYrkZCHQs5tN0WD4xerEXEOLtsvkj1ycnb04EUktI LdlmehsTJoO4V+ARTc9CGCaXAtfncVIxCGYtUOpvxoQF3oaQ63VqRRTyVn8ZzMGV y0ztAZEs5GI0ySqaBULEruxJ9Lxn18130OmWrFqoLVc4cL2FmelYUZo0ifYjeKr1 cKJ5z2koX2PHtW3W5UfscBwuBKe/eu94uwf8Swa7LIejkxC9HwtRpj4u0/DtChAH LYFUmVmOZ07p/mvuOby4qd3DBFg6jC/a7NhXR2gdGGQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=nSi69K 8gaCgxD8PERPpX2MbEXfGodendEfrDj5aR6zg=; b=CyIrNRVubvEw5KPJEY2iNX +Qhxie9sFBuV9CKDJNM94M+t3ZRTOnsL/xPQb8WDXZLke4bgtvRwr1qR1AGrEakp sbn120YNRZo2AcvKA8plNiF5g8tyreaNligFMvNDpY/GrtqbD4CSA/oFn2m644n5 ymNY0jQ9Lm85m1xCoug6NwMPcizZmwyurGt/r7M4BPDR/yqNmCCTSD83KRd0DxJI F3hq+jJDVMg1bDbJxLBpv/momrKHbgvhP1NBdnGgngkdSNtdUUt2R2OgGgb03fCw MgjD0oE9nplYsaHXzyM82ffLNHL+UY2tjm4r03OPM0DuN4TMfGbZUkBm95x5vCFQ == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudehhedgtdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpeforgigihhm vgcutfhiphgrrhguuceomhgrgihimhgvsegtvghrnhhordhtvggthheqnecuggftrfgrth htvghrnhepleekgeehhfdutdeljefgleejffehfffgieejhffgueefhfdtveetgeehieeh gedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmh grgihimhgvsegtvghrnhhordhtvggthh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 12 Jan 2022 04:34:17 -0500 (EST) Date: Wed, 12 Jan 2022 10:34:15 +0100 From: Maxime Ripard To: Michael Wu Cc: ulf.hansson@linaro.org, wens@csie.org, samuel@sholland.org, andre.przywara@arm.com, jernej.skrabec@gmail.com, linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mmc: sunxi-mmc: check ocr_avail on resource request Message-ID: <20220112093415.wdy3ht5yizw5lffl@houat> References: <20220104060325.3957-1-michael@allwinnertech.com> Precedence: bulk X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pow7a6h6ea2halol" Content-Disposition: inline In-Reply-To: <20220104060325.3957-1-michael@allwinnertech.com> --pow7a6h6ea2halol Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Jan 04, 2022 at 02:03:25PM +0800, Michael Wu wrote: > Some platforms have no regulator, discrete power devices are used instead. Is it really the case? vmmc at least should be mandatory so a platform not having a regulator would violate the binding itself. > However, sunxi_mmc_probe does not catch this exception when regulator is > absent in DTS. This leads to sd or eMMC init failure. This will still happen with your patch though? > To solve this, a fixed vmmc regulator must be hooked up in DTS, like this: > reg_dummy_vmmc: dummy_vmmc { > compatible =3D "regulator-fixed"; > regulator-name =3D "dummy-vmmc"; > regulator-min-microvolt =3D <3300000>; > regulator-max-microvolt =3D <3300000>; > }; >=20 > mmc0:mmc@4020000 { > compatible =3D "allwinner,sun50i-a100-emmc"; > device_type =3D "mmc0"; > vmmc-supply =3D <®_dummy_vmmc>; > } >=20 > In this patch, we print an error message and abort the probe process if > the regulator is not specified in DTS. I'm fine with the patch itself, but it's really not clear to me what situation is being fixed or improved here. You're first mentioning that this is fixing the driver probing even if a regulator is absent, but then states (rightfully) that in such a case we should use a fixed regulator. So we should always have a regulator then? I assume that you want the driver to properly error out instead of going on if either a regulator is missing or if its voltages are out of range? If the former, then we should probably check if host->mmc->supply.vmmc returned an error. If the latter, then yes, checking ocr_avail is probably fine but we should make it clearer in the error message that it's what it's about. Maxime --pow7a6h6ea2halol Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYd6glwAKCRDj7w1vZxhR xYMDAQDOvoByLoNbucD0rg09oRxg0ac/oM8XXvRnOEoOgNtc6AD7B4fNMTPoPSrt SOyuoXTJa0OcH67vLGECca6JGG6L/gg= =5+yC -----END PGP SIGNATURE----- --pow7a6h6ea2halol-- 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 035B7C433F5 for ; Wed, 12 Jan 2022 09:35:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=LHQmI89LjDJRRpsuqe8oM16En9pv+3dkMwXxbncNv9c=; b=GseEfIwxBA3CXGf5OZx+cxu9Tu gzedruNb+AL3FoMqB2oeZ5BmXhhvs2PlwsferrA/F8aRiwfb8qrPGjVjzL7oTP0878GwzBk6qBn0T 61INqcgiNBKafUEjfZEXEY/B1of0b6ONuUvr24dlEQGVVJ5ZrZp1ZlBcaAJNxRNBeDw2Kzm4YSXFQ +UXcMEXzE1dGXOo6RPbWerLuCeKIMCMPFpci7I2VFRnXyGeywPkPzjvbxpIukJEd2QrszoDPjlJiC IgMGPMGwYTETdC/AAtfvjSXcSFf9CHXTZD7pOkBCmnzuT+pIYNhYcKoYw1EFcMclIfx9KYxtKHjyF dgq4MJhw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n7a1N-001mba-TI; Wed, 12 Jan 2022 09:34:22 +0000 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n7a1L-001mao-55 for linux-arm-kernel@lists.infradead.org; Wed, 12 Jan 2022 09:34:20 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 37BCF5C01D9; Wed, 12 Jan 2022 04:34:18 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Wed, 12 Jan 2022 04:34:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=nSi69K8gaCgxD8PERPpX2MbEXfG odendEfrDj5aR6zg=; b=PXInPjp7CShsxgmDyZXuJmRtSJ1aWAcINblm17yKHuG uN2NBTHcY8rrYLGDBkvgd05VYrkZCHQs5tN0WD4xerEXEOLtsvkj1ycnb04EUktI LdlmehsTJoO4V+ARTc9CGCaXAtfncVIxCGYtUOpvxoQF3oaQ63VqRRTyVn8ZzMGV y0ztAZEs5GI0ySqaBULEruxJ9Lxn18130OmWrFqoLVc4cL2FmelYUZo0ifYjeKr1 cKJ5z2koX2PHtW3W5UfscBwuBKe/eu94uwf8Swa7LIejkxC9HwtRpj4u0/DtChAH LYFUmVmOZ07p/mvuOby4qd3DBFg6jC/a7NhXR2gdGGQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=nSi69K 8gaCgxD8PERPpX2MbEXfGodendEfrDj5aR6zg=; b=CyIrNRVubvEw5KPJEY2iNX +Qhxie9sFBuV9CKDJNM94M+t3ZRTOnsL/xPQb8WDXZLke4bgtvRwr1qR1AGrEakp sbn120YNRZo2AcvKA8plNiF5g8tyreaNligFMvNDpY/GrtqbD4CSA/oFn2m644n5 ymNY0jQ9Lm85m1xCoug6NwMPcizZmwyurGt/r7M4BPDR/yqNmCCTSD83KRd0DxJI F3hq+jJDVMg1bDbJxLBpv/momrKHbgvhP1NBdnGgngkdSNtdUUt2R2OgGgb03fCw MgjD0oE9nplYsaHXzyM82ffLNHL+UY2tjm4r03OPM0DuN4TMfGbZUkBm95x5vCFQ == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudehhedgtdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpeforgigihhm vgcutfhiphgrrhguuceomhgrgihimhgvsegtvghrnhhordhtvggthheqnecuggftrfgrth htvghrnhepleekgeehhfdutdeljefgleejffehfffgieejhffgueefhfdtveetgeehieeh gedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmh grgihimhgvsegtvghrnhhordhtvggthh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 12 Jan 2022 04:34:17 -0500 (EST) Date: Wed, 12 Jan 2022 10:34:15 +0100 From: Maxime Ripard To: Michael Wu Cc: ulf.hansson@linaro.org, wens@csie.org, samuel@sholland.org, andre.przywara@arm.com, jernej.skrabec@gmail.com, linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mmc: sunxi-mmc: check ocr_avail on resource request Message-ID: <20220112093415.wdy3ht5yizw5lffl@houat> References: <20220104060325.3957-1-michael@allwinnertech.com> MIME-Version: 1.0 In-Reply-To: <20220104060325.3957-1-michael@allwinnertech.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220112_013419_301212_3C65B9CB X-CRM114-Status: GOOD ( 21.07 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8866492664122565088==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============8866492664122565088== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pow7a6h6ea2halol" Content-Disposition: inline --pow7a6h6ea2halol Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Jan 04, 2022 at 02:03:25PM +0800, Michael Wu wrote: > Some platforms have no regulator, discrete power devices are used instead. Is it really the case? vmmc at least should be mandatory so a platform not having a regulator would violate the binding itself. > However, sunxi_mmc_probe does not catch this exception when regulator is > absent in DTS. This leads to sd or eMMC init failure. This will still happen with your patch though? > To solve this, a fixed vmmc regulator must be hooked up in DTS, like this: > reg_dummy_vmmc: dummy_vmmc { > compatible =3D "regulator-fixed"; > regulator-name =3D "dummy-vmmc"; > regulator-min-microvolt =3D <3300000>; > regulator-max-microvolt =3D <3300000>; > }; >=20 > mmc0:mmc@4020000 { > compatible =3D "allwinner,sun50i-a100-emmc"; > device_type =3D "mmc0"; > vmmc-supply =3D <®_dummy_vmmc>; > } >=20 > In this patch, we print an error message and abort the probe process if > the regulator is not specified in DTS. I'm fine with the patch itself, but it's really not clear to me what situation is being fixed or improved here. You're first mentioning that this is fixing the driver probing even if a regulator is absent, but then states (rightfully) that in such a case we should use a fixed regulator. So we should always have a regulator then? I assume that you want the driver to properly error out instead of going on if either a regulator is missing or if its voltages are out of range? If the former, then we should probably check if host->mmc->supply.vmmc returned an error. If the latter, then yes, checking ocr_avail is probably fine but we should make it clearer in the error message that it's what it's about. Maxime --pow7a6h6ea2halol Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYd6glwAKCRDj7w1vZxhR xYMDAQDOvoByLoNbucD0rg09oRxg0ac/oM8XXvRnOEoOgNtc6AD7B4fNMTPoPSrt SOyuoXTJa0OcH67vLGECca6JGG6L/gg= =5+yC -----END PGP SIGNATURE----- --pow7a6h6ea2halol-- --===============8866492664122565088== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============8866492664122565088==--