From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from wnew1-smtp.messagingengine.com (wnew1-smtp.messagingengine.com [64.147.123.26]) (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 7A411259D for ; Wed, 7 Sep 2022 08:39:53 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.west.internal (Postfix) with ESMTP id 320A72B058ED; Wed, 7 Sep 2022 04:39:50 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 07 Sep 2022 04:39:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1662539989; x=1662547189; bh=rHnQqoPJFb fCoyXvlScJxF/2TX4ozlRbjwh/s/ZcTXY=; b=rlqCba81GDVgmFo9BLO/+vxElt 00saXH5K4+1wgARPrortKc3X6tNhaIagHxtFq9FX3QmW3eYm/dcZ/Xd4W+DrIVIq q0ZxCwyGbK8ynlgCZPdKYsO6989NICVWzfThhQB+swIE/SocQxL0blVkHOFtYt2a +2+eIDIfs+YcNgfST8S5UY09pFJI0qh1RWs4gmUb3i2JerXi6IRhUpSQtzv5IYsh 1R00Oxsydc4sydZCByQlMfEFKKC8TlhHoFWg6uhtxDCJ6cXS1GbN/TN7SCCOMP3q 4NhkrIyfgxjadagzbyrTdMplcJk1ooyf72O8s6MEfTM5H43N/6TUUkM/iTMg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1662539989; x=1662547189; bh=rHnQqoPJFbfCoyXvlScJxF/2TX4o zlRbjwh/s/ZcTXY=; b=Ft2HiBtALvBCzHSoyFouoM2RlHha3pW36vRYiiF/Aj9p jgB1+hT9SxJN781aapotSR/nkYu/nTdv1O9qZsnJ5VQJfDsXDF2E1tN+Vf4mRiWm G3SR4pPvfJAXEDu2a05LRJ6/2dgvjxxBVBsk9pwViUxDpoVGiuqZtFXraPe+syba nVKdja+C+91rr9ysqLwQhbdr720KzsCw9Fz/J/VUWbcfg/4nkWZiYcuLP+R0Pc0C HA3z5f5hC4bLUng7cKExSmOjYAXPw/PxIhiALmfh/1nzPMTG1+X572MR4zmCPVA9 ibD0tPdUx+IXQ3o/2bEzZzCONQqNRDoUM4Iv38uutA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfedttddgtdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtvdenucfhrhhomhepofgrgihi mhgvucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtffrrg htthgvrhhnpeetfefffefgkedtfefgledugfdtjeefjedvtddtkeetieffjedvgfehheff hfevudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmrgigihhmvgestggvrhhnohdrthgvtghh X-ME-Proxy: Feedback-ID: i8771445c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 7 Sep 2022 04:39:48 -0400 (EDT) Date: Wed, 7 Sep 2022 10:39:45 +0200 From: Maxime Ripard To: Jani Nikula Cc: Geert Uytterhoeven , Ben Skeggs , David Airlie , Chen-Yu Tsai , Thomas Zimmermann , Lyude Paul , Philipp Zabel , Maarten Lankhorst , Rodrigo Vivi , Tvrtko Ursulin , Jernej Skrabec , Samuel Holland , Karol Herbst , Noralf =?utf-8?Q?Tr=C3=B8nnes?= , Emma Anholt , Daniel Vetter , Joonas Lahtinen , Hans de Goede , Linux ARM , Phil Elwell , Intel Graphics Development , Dave Stevenson , DRI Development , Dom Cobley , Linux Kernel Mailing List , Nouveau Dev , linux-sunxi@lists.linux.dev, Mateusz Kwiatkowski Subject: Re: [PATCH v2 14/41] drm/modes: Move named modes parsing to a separate function Message-ID: <20220907083945.3cqmz765vmnjt3ol@houat> References: <20220728-rpi-analog-tv-properties-v2-0-459522d653a7@cerno.tech> <20220728-rpi-analog-tv-properties-v2-14-459522d653a7@cerno.tech> <87czcidnb8.fsf@intel.com> <20220830120330.6f5f22d35gu7cbr3@houat> <875yi9etuw.fsf@intel.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="qxovco4c3ldtue3z" Content-Disposition: inline In-Reply-To: <875yi9etuw.fsf@intel.com> --qxovco4c3ldtue3z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Aug 30, 2022 at 04:36:23PM +0300, Jani Nikula wrote: > On Tue, 30 Aug 2022, Maxime Ripard wrote: > > Hi, > > > > On Tue, Aug 30, 2022 at 01:43:07PM +0300, Jani Nikula wrote: > >> On Tue, 30 Aug 2022, Geert Uytterhoeven wrote: > >> > On Mon, Aug 29, 2022 at 3:13 PM Maxime Ripard wr= ote: > >> >> +#define STR_STRICT_EQ(str, len, cmp) \ > >> >> + ((strlen(cmp) =3D=3D len) && !strncmp(str, cmp, len)) > >> > > >> > This is not part of the move, but newly added. > >>=20 > >> The same construct is also duplicated elsewhere in the series, and I > >> kept being confused by it. > > > > I'm not sure what is confusing, but I can add a comment if needed. >=20 > STR_STRICT_EQ() is what's confusing. I have to look at the > implementation to understand what it means. What does "strict" string > equality mean? Same length, same sequence of characters > > > >> The above is precisely the same as: > >>=20 > >> str_has_prefix(str, cmp) =3D=3D len > > > > Here, it's used to make sure we don't have a named mode starting with > > either e, d, or D. > > > > If I understood str_has_prefix() right, str_has_prefix("DUMB-MODE", "D") > > =3D=3D strlen("DUMB-MODE") would return true, while it's actually what = we > > want to avoid. >=20 > That's not true, str_has_prefix("DUMB-MODE", "D") =3D=3D strlen("D") is. >=20 > > It's also used indeed in drm_get_tv_mode_from_name(), where we try to > > match a list of names with one passed as argument. > > > > With drm_get_tv_mode_from_name("NSTC", strlen("NTSC")), we would end up > > calling str_has_prefix("NTSC-J", "NTSC") =3D=3D strlen("NTSC-J") which = would > > work. However, we end up calling prefix not a prefix, but an entire > > string we want to match against, which is very confusing to me too. >=20 > If I get this right, you have a string and you want to check if that has > a certain prefix. Additionally, you want to check the prefix is a > certain length. >=20 > Sure, that the prefix is a certain length is more of a property of the > string, which is NUL terminated later than at length, but that's doesn't > really matter. >=20 > That condition is simply str_has_prefix(string, prefix) =3D=3D length. Ack. I'm ok with the implementation being done that way, but I'd really prefer to still have some macro to make the name less confusing. Would that work for you? What name would be better in your opinion? Thanks! Maxime --qxovco4c3ldtue3z Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYxhY0QAKCRDj7w1vZxhR xa5XAP9sWfv5tHnxQJpN3hRmX3ErZIQ33tjnxBrnbPX7t8NAjwD/emsxhT5EFzpt Y/lLUUTztSaE0qu2ofT3EG9ZeOf9fw8= =dNn8 -----END PGP SIGNATURE----- --qxovco4c3ldtue3z--