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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BBEACC4332F for ; Wed, 30 Mar 2022 15:56:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245591AbiC3P6H (ORCPT ); Wed, 30 Mar 2022 11:58:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43304 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348497AbiC3P4R (ORCPT ); Wed, 30 Mar 2022 11:56:17 -0400 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5395BF22; Wed, 30 Mar 2022 08:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: 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-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=wgfuOXqIBPEAyPh7DtBsA+rKmH2Jc2/fR90kcqXnCog=; b=dx6sqnQc/pZMXMPRCqob/GykAE hyG1CoAGCaxBbzeM331REjymFP+8IUk2ZdhBA3ep/kZuPj4nvnfYLodcmvOeu8JGaV63gDce370lp 48DXOxakKlv/cmIQBcolh0ix3v+WGwe/jyeeE4NIQyIoSPPVcAOWNUmn2G2PNQzRNZZ52hyx6CtZn /Gz2zyYyHdW/7sdp7BBIxKORWQRd+PErl7LycKrIUZgJzGfYayB8DHCGt7R6SWfShlh/L0+7tyCYk E3zkLk6jdAHTB6yG1ZrQvlFlqX4Eu1Y431d7JICOb8Du7H/TKPQr/OAmozgesFtlXqDtZUFHpRCOb 4qmfSZng==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:58006) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nZaeT-0003OX-8D; Wed, 30 Mar 2022 16:54:28 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1nZaeS-0006jI-8v; Wed, 30 Mar 2022 16:54:28 +0100 Date: Wed, 30 Mar 2022 16:54:28 +0100 From: "Russell King (Oracle)" To: Krzysztof Kozlowski Cc: Ioana Ciornei , "davem@davemloft.net" , "kuba@kernel.org" , "netdev@vger.kernel.org" , "robh+dt@kernel.org" , "devicetree@vger.kernel.org" Subject: Re: [PATCH net-next] dt-bindings: net: convert sff,sfp to dtschema Message-ID: References: <20220315123315.233963-1-ioana.ciornei@nxp.com> <6f4f2e6f-3aee-3424-43bc-c60ef7c0218c@canonical.com> <20220315190733.lal7c2xkaez6fz2v@skbuf> <20220316101854.imevzoqk6oashrgg@skbuf> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Russell King (Oracle) Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, Mar 16, 2022 at 01:04:21PM +0100, Krzysztof Kozlowski wrote: > On 16/03/2022 11:18, Ioana Ciornei wrote: > >>> > >>> It's related since it shows a generic usage pattern of the sfp node. > >>> I wouldn't just remove it since it's just adds context to the example > >>> not doing any harm. > >> > >> Usage (consumer) is not related to these bindings. The bindings for this > >> phy/mac should show the usage of sfp, but not the provider bindings. > >> > >> The bindings of each clock provider do not contain examples for clock > >> consumer. Same for regulator, pinctrl, power domains, interconnect and > >> every other component. It would be a lot of code duplication to include > >> consumers in each provider. Instead, we out the example of consumer in > >> the consumer bindings. > >> > >> The harm is - duplicated code and one more example which can be done > >> wrong (like here node name not conforming to DT spec). > > > > I suppose you refer to "sfp-eth3" which you suggested here to be just > > "sfp". > > I refer now to "cps_emac3" which uses specific name instead of generic > and underscore instead of hyphen (although underscore is actually listed > as allowed in DT spec, dtc will complain about it). > > >In an example, that's totally acceptable but on boards there can > > be multiple SFPs which would mean that there would be multiple sfp > > nodes. We have to discern somehow between them. Adding a unit name would > > not be optimal since there is no "reg" property to go with it. > > The common practice is adding a numbering suffix. > > > > > So "sfp-eth3" or variants I think are necessary even though not > > conforming to the DT spec. > > > >> > >> If you insist to keep it, please share why these bindings are special, > >> different than all other bindings I mentioned above. > > > > If it's that unheard of to have a somewhat complete example why are > > there multiple dtschema files submitted even by yourself with this same > > setup? > > I am also learning and I wished many of my mistakes of early DT bindings > conversion were spotted. Especially my early bindings... but even now I > keep making mistakes. Human thing. :) > > I converted quite a lot of bindings, so can you point to such examples > of my schema which includes consumer example in a provider bindings? If > you find such, please send a patch removing trivial code. > > > > As an example for a consumer device being listed in the provider yaml > > file is 'gpio-pca95xx.yaml' > > Indeed, this is trivial and useless code which I kept from conversion, > should be removed. > > > > and for the reverse (provider described in > > the consumer) I can list 'samsung,s5pv210-clock.yaml', > > 'samsung,exynos5260-clock.yaml' etc. > > These are different. This is an example how to model the input clock to > the device being described in the bindings. This is not an example how > to use the clock provider, like you created here. The input clock > sometimes is defined in Exynos clock controller, sometimes outside. The > example there shows the second case - when it has to come outside. It's > not showing the usage of clocks provided by this device, but I agree > that it also might be trivial and obvious. If you think it is obvious, > feel free to comment/send a patch. Why is whether something is an input or output relevant? One can quite rightly argue that SFPs are both input and output. :) -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!