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 9CF7BC2BD09 for ; Thu, 20 Jun 2024 11:11:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To: Content-Type:MIME-Version:References:Message-ID:Subject: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=6ux2DD2jNnhpn1h9NAq73VaL+4p3Q9GTOtWopclsukY=; b=dD8tYaH0njXWRuAnkkgUQYtSgQ WccwJkHmxZvJqDEef4dXsDHVCysX4NePbN8J55hJqiDHeQaoPMIoGgVSNKbABuoG5O9CFsJ6U6aCb RVTN5471onwyj7QifvaI4Yu7+1PUTc0ueG0s2ldCGiJ+ilt+6nNw3j6vCsEUYLfU2BlhnmBMD3Qo0 Wqqo3v9gc8L4mwIEma9sK/1tFkOMKktuKd752dPQMjePn2gR5p9xGO0nYUs3UkAKX/wstjhqGo7G7 IeE63oEpkZDfIIGJewMqnvAfkQbw5gcJqLqETjOzotctcCHXm18R6ixsQ3VVKSAQWpQs48eHXNt+2 MzMhgmtg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sKFhO-00000004hP7-0wMN; Thu, 20 Jun 2024 11:11:26 +0000 Received: from esa.microchip.iphmx.com ([68.232.154.123]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sKFhK-00000004hNh-2hg6 for linux-arm-kernel@lists.infradead.org; Thu, 20 Jun 2024 11:11:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1718881882; x=1750417882; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=95Ij0vKrYrGH00SkqoNbXKVDvTZtqsyiEyaQ1r0dl68=; b=UOWDPAmVDUdy+FM3Vu0ODpHapXQ6+t6QiWdcHD02UM14/lPEUkIGIEM8 xAa8eRF9UOaE6kq5XsImybYx7WMOdEtzkTJO5cQ94wmkaUhTxrl+P564h ssJXYHQQQBUhqm2C+DoPT+SrWxuygoYfS93v6DFwZ2ifp0RkxhKy0cdNc Yv4HJEhCxyeugVRvN0WQ55CxesvByLMIx3POIOktkeyl13634TadJb4Vj kHA5Tw8UxqjpcZivmAnSdjgs1mHyCBwaLKwRnjpJejgEuskcXortYFDZU CKtUan+Ve9V0P06m6xLgGuD/D4dEsA75NRNuH5EyHz/6pc85fkwEsYAuw w==; X-CSE-ConnectionGUID: gqLzAYtPQQ2L5OyNG4B4Sw== X-CSE-MsgGUID: vm2+jEyqQ6GzAavsNlO9Ng== X-IronPort-AV: E=Sophos;i="6.08,252,1712646000"; d="asc'?scan'208";a="28263518" X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN Received: from unknown (HELO email.microchip.com) ([170.129.1.10]) by esa4.microchip.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 20 Jun 2024 04:11:19 -0700 Received: from chn-vm-ex04.mchp-main.com (10.10.85.152) by chn-vm-ex04.mchp-main.com (10.10.85.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 20 Jun 2024 04:10:53 -0700 Received: from wendy (10.10.85.11) by chn-vm-ex04.mchp-main.com (10.10.85.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend Transport; Thu, 20 Jun 2024 04:10:51 -0700 Date: Thu, 20 Jun 2024 12:10:32 +0100 From: Conor Dooley To: Subject: Re: [PATCH 3/3] dt-bindings: eeprom: at24: Add at24,mac02e4 and at24,mac02e6 Message-ID: <20240620-bulge-sturdy-cd0f92f05de2@wendy> References: <20240619072231.6876-1-andrei.simion@microchip.com> <20240619072231.6876-4-andrei.simion@microchip.com> <20240619-thee-herald-82725e1526e2@spud> <0d57b14b-48d1-4629-92f4-74934c6ecdeb@microchip.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="YJZ0paq/YzbEpWyV" Content-Disposition: inline In-Reply-To: <0d57b14b-48d1-4629-92f4-74934c6ecdeb@microchip.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240620_041122_846596_BE450E89 X-CRM114-Status: GOOD ( 22.46 ) 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: , Cc: linux-arm-kernel@lists.infradead.org, robh@kernel.org, conor+dt@kernel.org, arnd@arndb.de, alexandre.belloni@bootlin.com, devicetree@vger.kernel.org, gregkh@linuxfoundation.org, brgl@bgdev.pl, conor@kernel.org, claudiu.beznea@tuxon.dev, linux-i2c@vger.kernel.org, krzk+dt@kernel.org, linux-kernel@vger.kernel.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --YJZ0paq/YzbEpWyV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 20, 2024 at 10:45:58AM +0000, Andrei.Simion@microchip.com wrote: > On 19.06.2024 20:53, Conor Dooley wrote: > >> Update regex check and add pattern to match both EEPROMs. > >> > >> Signed-off-by: Andrei Simion > >> --- > >> Documentation/devicetree/bindings/eeprom/at24.yaml | 10 +++++++--- > >> 1 file changed, 7 insertions(+), 3 deletions(-) > >> > >> diff --git a/Documentation/devicetree/bindings/eeprom/at24.yaml b/Docu= mentation/devicetree/bindings/eeprom/at24.yaml > >> index 3c36cd0510de..46daa662f6e7 100644 > >> --- a/Documentation/devicetree/bindings/eeprom/at24.yaml > >> +++ b/Documentation/devicetree/bindings/eeprom/at24.yaml > >> @@ -18,7 +18,7 @@ select: > >> properties: > >> compatible: > >> contains: > >> - pattern: "^atmel,(24(c|cs|mac)[0-9]+|spd)$" > >> + pattern: "^atmel,(24(c|cs|mac)[0-9]+[a-z0-9]*|spd)$" >=20 > > Could we relax the pattern instead to make this bloat less? Would it be > > problematic to just allow "^atmel,(24(c|cs|mac)[a-z0-9]+|spd)$"? >=20 > I) "^atmel,(24(c|cs|mac)[a-z0-9]+|spd)$" : > The first pattern does not specify where the digits must occur within > the alphanumeric sequence that follows 24c, 24cs, or 24mac. It allows > the sequence to be all letters, all digits, or any mix thereof. >=20 > II) "^atmel,(24(c|cs|mac)[0-9]+[a-z0-9]*|spd)$" : > The second pattern specifically requires that at least one digit appears > immediately after 24c, 24cs, or 24mac, and only after this digit can > letters appear. > As hypothetical example : > atmel,24cabc would match the first pattern but not the second because > there are no digits immediately following 24c. > atmel,24c123 would match both patterns because there are digits > immediately following 24c, and the first pattern doesn't care about > the position of the digits within the alphanumeric sequence. >=20 > In case of at24,mac02e4 and at24,mac02e6 match both patterns. >=20 > Let me know your thoughts. Basically my reasoning here is that both patterns are very permissive (although one clearly more than the other) and do not stop people from creating compatibles that do not correspond to a real device, so I felt that the more complex regex didn't really provide enough benefit compared to keeping the regex simpler. > I agree to change the pattern as you suggest. :+1: --YJZ0paq/YzbEpWyV Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZnQOKAAKCRB4tDGHoIJi 0lggAQCYXfW9bQInGc1FKpTgtaCJ+HWNt14cEZjcpipzDaoOhgEAjLO9TIQb3XLn 9ifpQlSmibEvLdi8Nfjj7sqeoIJrqQs= =CrCj -----END PGP SIGNATURE----- --YJZ0paq/YzbEpWyV--