From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout02.posteo.de (mout02.posteo.de [185.67.36.66]) (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 8B4E816426 for ; Fri, 10 Jan 2025 00:29:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.67.36.66 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736468980; cv=none; b=YW8HZWFhIpfiHyI1dCB2O9u2hKurRM+dSHEv5YWe6Nls3nvU65oZeGInT+xvXg6QbMULH0PjN7a6VhoNW0K+O9jnBteQpDHrZosWYny+jF0BsxvbkXqvp2FWTqk+BgFi2sSMwL/f9CHfQyRbmnJvZE7RNCnwoqoNSYYORUPS6Mg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736468980; c=relaxed/simple; bh=NmF9OpBmOlyhdjWseD2lyW2G8XKj6Wz2ZngKw21hv48=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=kUi2fmIeUK0IfWkJ+ZfyzP2a0bdI+TI2YFVFOQP7soTpPwKojADuw3lFgJg4PaGwZdP0aLRVAS7J0No4AW5wWyGfdoZPZpXoaGHMfJFfKm8WtW8PDdGLy7T68nppvU2XkSGfLZY4tRL4jEtIuINJk24rF28TxtT97Nigj1iYIy0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=posteo.net; spf=pass smtp.mailfrom=posteo.net; dkim=pass (2048-bit key) header.d=posteo.net header.i=@posteo.net header.b=FcPo409J; arc=none smtp.client-ip=185.67.36.66 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=posteo.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=posteo.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=posteo.net header.i=@posteo.net header.b="FcPo409J" Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 04E8C240103 for ; Fri, 10 Jan 2025 01:29:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1736468976; bh=NmF9OpBmOlyhdjWseD2lyW2G8XKj6Wz2ZngKw21hv48=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition:Content-Transfer-Encoding:From; b=FcPo409J66WIu73Ng0FSXXEddwXGcFmmK2NzKQ6SSIC+/HMZM9Dmd3zw09LP326Mv GtLS6WO6ymQzJdB1UKeFd+x+9llhZRaRva+zWuy+m6LjtbUNysjuYhGL1h7mgMnsDn aiEb2k87+isixL9j1WioTcC9ndzzSmi60Erj3EQP7O0T4JdUYu4rsFC5U1GfZooNsV JYJEl3MOEIC1jbK2x7IR1orbzY0Me9KKwvtMAzzpNcFdWeVAfVtPGY5cGZ5gPX2Lm9 wk/rC6RyocusQB+FWYTx6O2W9RaZ6rQKWIHqi8OWDOgQ5f45tQ0XZTBg2lPgidQNFB b2c9UcICTaxcA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4YTjG60LNbz9rxK; Fri, 10 Jan 2025 01:29:33 +0100 (CET) Date: Fri, 10 Jan 2025 00:29:33 +0000 From: =?utf-8?Q?J=2E_Neusch=C3=A4fer?= To: Bartosz Golaszewski Cc: =?utf-8?B?Q3PDs2vDoXM=?= Bence , =?utf-8?Q?J=2E_Neusch=C3=A4fer?= , Geert Uytterhoeven , Linus Walleij , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Maxime Ripard , Bartosz Golaszewski , linux-gpio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Mark Brown , linux-spi Subject: Re: [PATCH v2 0/3] gpio: 74HC595 / 74x164 shift register improvements Message-ID: References: <20241224-gpio74-v2-0-bbcf14183191@posteo.net> <173593634037.257292.1488097273042214180.b4-ty@linaro.org> <192e97dd-698a-4434-bd32-c1181ec85ba3@prolan.hu> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Wed, Jan 08, 2025 at 01:08:37PM +0100, Bartosz Golaszewski wrote: > On Wed, Jan 8, 2025 at 11:26 AM Csókás Bence wrote: > > > > Hi all, Hi, > > > > On 2025. 01. 06. 21:16, Bartosz Golaszewski wrote: > > > On Mon, Jan 6, 2025 at 10:19 AM Geert Uytterhoeven wrote: > > >> Do we really need to document and add driver support for all variants? > > >> I can easily come up with a list of tens or perhaps even hundreds > > >> of xx74yy595z parts that are all compatible, as far as software is > > >> concerned. As SPI was invented by Motorola, the original part is > > >> probably named MC74595 or MC74LS595 (yes, ON Semiconductor bought the > > >> logic division of Motorola). > > > > I second this, no point of having a new compatible which is a guaranteed > > 1:1 equivalent of an already existing one. Especially true if the only > > change was that a different company bought the IP. By the same logic, I > > could start to sumbit patches to change all `fsl,` compatible-s to > > `nxp,`; `atmel,`, `maxim,`, `smsc,` etc. to `microchip,`; `ralink,` to > > `mediatek,` and so on. There would be no end. > > > > >> Perhaps we need a separate vendor prefix for the 74xx-series[1]? > > > > I don't think that is the case. Rather, we should document that the > > existing binding/compatible should be used for all such simple cases (it > > is called _compatible_ for a reason, after all, and not > > `exact-part-number`). > > > > >> The xx-prefix and z-suffix don't matter; the yy-infix for semiconductor > > >> technology rarely matters (there are a few exceptions, though, mostly > > >> pinout, which doesn't matter for software). > > >> > > > > > > I missed the fact that Rob actually responded to patch 1/3 with a > > > similar suggestion (fallback, instead of a full compatible). > > > > > > I can drop this series from my queue if it needs more rework. > > > > I think you can keep 3/3 (the one commenting the use of `latch` as CS). > > The rest can be replaced by another commit commenting on what it means > > to be `fairchild,74hc595`: > > > > J. Neuschäfer: do you want to send a follow-up for this? I'm fine with this outcome, but I'd prefer not to prepare this proposed patch (for reasons of time management on my end, mostly). So if anyone else would take it up, I'd greatly appreciate that. Best regards, jn