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 4FAE1C761A6 for ; Fri, 31 Mar 2023 20:09:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232696AbjCaUJa (ORCPT ); Fri, 31 Mar 2023 16:09:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54634 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231812AbjCaUJa (ORCPT ); Fri, 31 Mar 2023 16:09:30 -0400 Received: from mail-oi1-f175.google.com (mail-oi1-f175.google.com [209.85.167.175]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CBA6821A8E; Fri, 31 Mar 2023 13:09:24 -0700 (PDT) Received: by mail-oi1-f175.google.com with SMTP id w13so6173891oik.2; Fri, 31 Mar 2023 13:09:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680293364; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=uPkpKFxk7BcOpgUzJha9+qhAMS2yt0UsXgxPanJmeeY=; b=t3/ZYXkRBRznCSyV2h7lSIl9/GFG0cskiooUOZlzkDUalq7T6tDwYov1wwIDnvaSbo zqHDrVllyBVLj2+IatjCnzz61aEsGGNIwqC3lcwbuq0OIXdqaGt0Fehw3uNiVix619Co pwL99kFu+VdXa55ML+pKG2/yl72wk339YuXM5LBqhYyo+dXdVqrNBsRSIbaMnRT1AJvl oWVYMwyMsjAODn8G1YLWSr2IvHiN/TV3WWYzcXtNe6bJLdOoBCHU9KK7Q2VoAZkhA/ch cM4UGAMX2EF0EkCIk74XnFcoNG1CNDrH9gJYq/rHrqsEz/eXJiOUQD/BR173h1TNzhmV 7Sqg== X-Gm-Message-State: AAQBX9eLd92E7Dwtm8+G11mhX48CW2aJIcN1q+AQxhv8K3dDy42UdLTP UNtToaeOy6mtLKsINeCvpA== X-Google-Smtp-Source: AKy350ZNGbtu+wZO9GEFh09+Q8jTGjD4N+L1g95Cjk+YUOMacEt1LSoNV3wAfsJboJEXfnqNLSWQmw== X-Received: by 2002:a05:6808:208a:b0:389:8075:4c0b with SMTP id s10-20020a056808208a00b0038980754c0bmr1936699oiw.1.1680293363988; Fri, 31 Mar 2023 13:09:23 -0700 (PDT) Received: from robh_at_kernel.org (66-90-144-107.dyn.grandenetworks.net. [66.90.144.107]) by smtp.gmail.com with ESMTPSA id c5-20020a4aacc5000000b00524f381f681sm1203954oon.27.2023.03.31.13.09.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 Mar 2023 13:09:23 -0700 (PDT) Received: (nullmailer pid 2156389 invoked by uid 1000); Fri, 31 Mar 2023 20:09:22 -0000 Date: Fri, 31 Mar 2023 15:09:22 -0500 From: Rob Herring To: Christian Marangi Cc: Pavel Machek , Lee Jones , Krzysztof Kozlowski , Andrew Lunn , Florian Fainelli , Vladimir Oltean , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Heiner Kallweit , Russell King , Gregory Clement , Sebastian Hesselbarth , Andy Gross , Bjorn Andersson , Konrad Dybcio , John Crispin , linux-leds@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org Subject: Re: [net-next PATCH v6 10/16] dt-bindings: leds: Document support for generic ethernet LEDs Message-ID: <20230331200922.GA2123749-robh@kernel.org> References: <20230327141031.11904-1-ansuelsmth@gmail.com> <20230327141031.11904-11-ansuelsmth@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230327141031.11904-11-ansuelsmth@gmail.com> Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Mon, Mar 27, 2023 at 04:10:25PM +0200, Christian Marangi wrote: > Add documentation for support of generic ethernet LEDs. > These LEDs are ethernet port LED and are controllable by the ethernet > controller or the ethernet PHY. > > A port may expose multiple LEDs and reg is used to provide an index to > differentiate them. > Ethernet port LEDs follow generic LED implementation. > > Signed-off-by: Christian Marangi > --- > .../bindings/leds/leds-ethernet.yaml | 76 +++++++++++++++++++ > 1 file changed, 76 insertions(+) > create mode 100644 Documentation/devicetree/bindings/leds/leds-ethernet.yaml > > diff --git a/Documentation/devicetree/bindings/leds/leds-ethernet.yaml b/Documentation/devicetree/bindings/leds/leds-ethernet.yaml > new file mode 100644 > index 000000000000..0a03d65beea0 > --- /dev/null > +++ b/Documentation/devicetree/bindings/leds/leds-ethernet.yaml > @@ -0,0 +1,76 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/leds/leds-ethernet.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Common properties for the ethernet port LED. > + > +maintainers: > + - Christian Marangi > + > +description: > + Bindings for the LEDs present in ethernet port and controllable by > + the ethernet controller or the ethernet PHY regs. > + > + These LEDs provide the same feature of a normal LED and follow > + the same LED definitions. > + > + An ethernet port may expose multiple LEDs, reg binding is used to > + differentiate them. > + > +properties: > + '#address-cells': > + const: 1 > + > + '#size-cells': > + const: 0 > + > +patternProperties: > + '^led@[a-f0-9]+$': > + $ref: /schemas/leds/common.yaml# > + > + properties: > + reg: > + maxItems: 1 > + description: > + This define the LED index in the PHY or the MAC. It's really > + driver dependent and required for ports that define multiple > + LED for the same port. > + > + required: > + - reg > + > + unevaluatedProperties: false This does nothing to help the issues I raised. If the 'led' nodes have custom properties, then you need a schema for the 'led' nodes and just the 'led' nodes. Not a schema for the 'leds' container node. If your not going to allow extending, then this can all be 1 file like you had (with unevaluatedProperties added of course). Rob 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 87574C761A6 for ; Fri, 31 Mar 2023 20:10:28 +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-Transfer-Encoding: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-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=1CeTJJFSBsMp5Vy4j6/XYpUzMuDdMAZ6t8L7zVnietA=; b=Q2DSQQwzhmm0gp Y1S9DtuyfhNLZ+PtYyVjrmLJBotoBZvEzSNqU3VM5vf8XASU7aOpGyx4WNM7pi7L5Rc9V49mBRCXt 2ZlG6bOo4LUwox0GIbUrH/bCUX6HuYdjyOCRZS/NCBIrFLwqqViZHGydXhQE8i+auU0IVKWSmxpKp DwNcK47MU09PjoGkMjbyZjwp7Zzh1oFR7dyxSeBfa++0XR77mbc493KIlcWDX0dkHL2o4RhuRTyqm eYa0MHwFKDowgYOCHsw6RGfz0J28p8jbU0L5IihI0uP2gMS8QX/TxBd7kky51Vg1uWGtra6MpzXoa PfA5LWvKdkGYwFNrunHg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1piL41-008iWm-1N; Fri, 31 Mar 2023 20:09:33 +0000 Received: from mail-oi1-f178.google.com ([209.85.167.178]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1piL3u-008iVP-3A for linux-arm-kernel@lists.infradead.org; Fri, 31 Mar 2023 20:09:31 +0000 Received: by mail-oi1-f178.google.com with SMTP id f14so4001930oiw.10 for ; Fri, 31 Mar 2023 13:09:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680293364; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=uPkpKFxk7BcOpgUzJha9+qhAMS2yt0UsXgxPanJmeeY=; b=XarUkTK8vtXFzpITXxzGvjOFFVKXAPzV+je7cJLyYQ0ant6oIxERnjCL6kU55jvFpA hdsHZ3dENQN3NUVra4CblDD+YZFUfdRFY99yF3SFacJHSNHVss/VeXmv5bEWvVeOWtAF F63nfHZHSmKIhzZHKPOl/zCvE9RJfgjxitoc7RoPbhAZwMs8N0MGWnLQw2RnpStXfI2+ okyJVbflTnKpbXeODJCzdhMitreoVsGe0xCWEZlIsyC1itiQ4XaT6FRuvOzNPZJaDSaB 15BQqd7sRN0/ApdZdwQjjehiEramRGstRq0iLNNv6Aj0S/xPaYofT29kjCaJ523s7qgp xxOQ== X-Gm-Message-State: AAQBX9fF2gDhM7h7WIbAlLh2XvVTQDpHe0pPfZU+yYM/xcYvOAul17Rb UGk7q7hAKs4ZOvXI05jFTQ== X-Google-Smtp-Source: AKy350ZNGbtu+wZO9GEFh09+Q8jTGjD4N+L1g95Cjk+YUOMacEt1LSoNV3wAfsJboJEXfnqNLSWQmw== X-Received: by 2002:a05:6808:208a:b0:389:8075:4c0b with SMTP id s10-20020a056808208a00b0038980754c0bmr1936699oiw.1.1680293363988; Fri, 31 Mar 2023 13:09:23 -0700 (PDT) Received: from robh_at_kernel.org (66-90-144-107.dyn.grandenetworks.net. [66.90.144.107]) by smtp.gmail.com with ESMTPSA id c5-20020a4aacc5000000b00524f381f681sm1203954oon.27.2023.03.31.13.09.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 Mar 2023 13:09:23 -0700 (PDT) Received: (nullmailer pid 2156389 invoked by uid 1000); Fri, 31 Mar 2023 20:09:22 -0000 Date: Fri, 31 Mar 2023 15:09:22 -0500 From: Rob Herring To: Christian Marangi Cc: Pavel Machek , Lee Jones , Krzysztof Kozlowski , Andrew Lunn , Florian Fainelli , Vladimir Oltean , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Heiner Kallweit , Russell King , Gregory Clement , Sebastian Hesselbarth , Andy Gross , Bjorn Andersson , Konrad Dybcio , John Crispin , linux-leds@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org Subject: Re: [net-next PATCH v6 10/16] dt-bindings: leds: Document support for generic ethernet LEDs Message-ID: <20230331200922.GA2123749-robh@kernel.org> References: <20230327141031.11904-1-ansuelsmth@gmail.com> <20230327141031.11904-11-ansuelsmth@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230327141031.11904-11-ansuelsmth@gmail.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230331_130930_170024_AA81EF72 X-CRM114-Status: GOOD ( 23.37 ) 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Mar 27, 2023 at 04:10:25PM +0200, Christian Marangi wrote: > Add documentation for support of generic ethernet LEDs. > These LEDs are ethernet port LED and are controllable by the ethernet > controller or the ethernet PHY. > > A port may expose multiple LEDs and reg is used to provide an index to > differentiate them. > Ethernet port LEDs follow generic LED implementation. > > Signed-off-by: Christian Marangi > --- > .../bindings/leds/leds-ethernet.yaml | 76 +++++++++++++++++++ > 1 file changed, 76 insertions(+) > create mode 100644 Documentation/devicetree/bindings/leds/leds-ethernet.yaml > > diff --git a/Documentation/devicetree/bindings/leds/leds-ethernet.yaml b/Documentation/devicetree/bindings/leds/leds-ethernet.yaml > new file mode 100644 > index 000000000000..0a03d65beea0 > --- /dev/null > +++ b/Documentation/devicetree/bindings/leds/leds-ethernet.yaml > @@ -0,0 +1,76 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/leds/leds-ethernet.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Common properties for the ethernet port LED. > + > +maintainers: > + - Christian Marangi > + > +description: > + Bindings for the LEDs present in ethernet port and controllable by > + the ethernet controller or the ethernet PHY regs. > + > + These LEDs provide the same feature of a normal LED and follow > + the same LED definitions. > + > + An ethernet port may expose multiple LEDs, reg binding is used to > + differentiate them. > + > +properties: > + '#address-cells': > + const: 1 > + > + '#size-cells': > + const: 0 > + > +patternProperties: > + '^led@[a-f0-9]+$': > + $ref: /schemas/leds/common.yaml# > + > + properties: > + reg: > + maxItems: 1 > + description: > + This define the LED index in the PHY or the MAC. It's really > + driver dependent and required for ports that define multiple > + LED for the same port. > + > + required: > + - reg > + > + unevaluatedProperties: false This does nothing to help the issues I raised. If the 'led' nodes have custom properties, then you need a schema for the 'led' nodes and just the 'led' nodes. Not a schema for the 'leds' container node. If your not going to allow extending, then this can all be 1 file like you had (with unevaluatedProperties added of course). Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel