Message ID | 20231213232455.2248056-1-robh@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:3b04:b0:fb:cd0c:d3e with SMTP id c4csp8159746dys; Wed, 13 Dec 2023 15:25:26 -0800 (PST) X-Google-Smtp-Source: AGHT+IHrwH3LIioBCtAGIuKfx6IJrEEnpxVf8fl0ui4wj9sPHxyxjVMwYT1po84SYbM8CFDiuI/C X-Received: by 2002:a17:902:ab05:b0:1d3:62aa:512 with SMTP id ik5-20020a170902ab0500b001d362aa0512mr477301plb.49.1702509926134; Wed, 13 Dec 2023 15:25:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702509926; cv=none; d=google.com; s=arc-20160816; b=qeINDqtfsr9USrREeLueV3WB1J9659rN3QEeWYsrIdfvRqPUn7P1ihADxCY1ubExO3 FsvAyDr7RPqpvJCTht+XN/UNT4WPAjqrlOxlXtnXI7vrDtQEtd1iHaKpRaam0CBbaOYa t+nl06PegHSSml+em98qc1m9/HZQ1DFj24hbWN6JN0ig3W+aIxUlj6cTLiSukcWXBWuZ ztJN34aqvwh+bsxQdKMiJQp8SFHJy1UJOFXOYSignriKWRj2lKWCi2TzSMEIHfWZSfsi eN8IsXZfeug2z/CvOJoXpMsxW3u1Mj1v3i3XyQ2h9eBfA6YBwZZ/kpRTZWaFApyFs0jC EHpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=c+ujX2KdbWl+FCDRkPG1EwpBH+yzRnhRj9laF4akgZg=; fh=15yxrHkVJhWYw0in6j9iHi/J095Ibx8wruomWnLgCCE=; b=DMzonAFdMOz4rDSEZGx/pdmB7TZzsCa9iUVc9/GP1DjrjljZhw4iozxjmvOMF1AeqL S3lZnIq7Gmx4aCvQJShSEsPAAzUNRVNlYFmRQg5o9L6Wby9USBZsoRHufM4LB8/reNWD RUaSC3DfV4D6xKeA+5vAtU9iKJm0sUY6vThjzCb76Z2iuG4JFfl3tjVeM1cieh5b6Pcl rMNv1iPH+1pc24EdJdCQDjmvk0xI0ZvTxPIh+ZVQGI07049haTZ9cIgzz6qj3X1AYRz7 v4wRU4N/PaV8WfJR4eSZQdf+cKYPrM1qdOOJ1x0znVUZhm1lfDL/LhPW9rS9yOFalQiD /7Ug== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from fry.vger.email (fry.vger.email. [23.128.96.38]) by mx.google.com with ESMTPS id jw15-20020a170903278f00b001ca96a6eefesi10188735plb.577.2023.12.13.15.25.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Dec 2023 15:25:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 6DCDC80C8439; Wed, 13 Dec 2023 15:25:22 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230507AbjLMXZN (ORCPT <rfc822;dexuan.linux@gmail.com> + 99 others); Wed, 13 Dec 2023 18:25:13 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47746 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229896AbjLMXZM (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 13 Dec 2023 18:25:12 -0500 Received: from mail-oo1-f52.google.com (mail-oo1-f52.google.com [209.85.161.52]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EC094EA; Wed, 13 Dec 2023 15:25:18 -0800 (PST) Received: by mail-oo1-f52.google.com with SMTP id 006d021491bc7-5910b21896eso2343275eaf.0; Wed, 13 Dec 2023 15:25:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702509918; x=1703114718; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=c+ujX2KdbWl+FCDRkPG1EwpBH+yzRnhRj9laF4akgZg=; b=J8AuLG1oFZynBjB+2IRB6TgTuHbv4IxN4N6LHeUVSeyMy+86xMUaJLEfqqrNvR3urT Bovv2Q16Bgu4QtjKCcFlJMRV/utKHS728bgpvLJ1dlyX9kg0WkTdjzaE57SEd8MO/8Jo 9/+uZJFTuLe2GmnZsSukM9H4OxWOCP2mZnz5mdwQS26yrEqnlipKfDXW11ITQj58uo/v qKFPbAhaHs7OkkPDzcgkwGf7b0kUQaMU3EH7arpDgD0aKjyyXefQbNWC+qoZ2FrlF6Ta HJIuTTnYDCfurGeC0/C1QQXH4YmVwXdzgHW/27fZWujrPIgLpPhPr6RdmsI0V6TOTH54 zsCw== X-Gm-Message-State: AOJu0Yw2BrD8qLg+ccSaEdcFGWdqJGGMn3DFVl1PQShW/IsfE2g3zzdH lfUyz3Jl4UbRaXq9Es7AGVwK/xjytg== X-Received: by 2002:a4a:55ca:0:b0:590:67db:1dcb with SMTP id e193-20020a4a55ca000000b0059067db1dcbmr5555100oob.4.1702509918208; Wed, 13 Dec 2023 15:25:18 -0800 (PST) Received: from herring.priv (66-90-144-107.dyn.grandenetworks.net. [66.90.144.107]) by smtp.gmail.com with ESMTPSA id r124-20020a4a4e82000000b0058cbbf9b4e4sm3251624ooa.48.2023.12.13.15.25.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Dec 2023 15:25:17 -0800 (PST) Received: (nullmailer pid 2248461 invoked by uid 1000); Wed, 13 Dec 2023 23:25:16 -0000 From: Rob Herring <robh@kernel.org> To: "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Andrew Lunn <andrew@lunn.ch> Cc: netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH net-next] dt-bindings: net: marvell,orion-mdio: Drop "reg" sizes schema Date: Wed, 13 Dec 2023 17:24:55 -0600 Message-ID: <20231213232455.2248056-1-robh@kernel.org> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Wed, 13 Dec 2023 15:25:22 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785211048454442482 X-GMAIL-MSGID: 1785211048454442482 |
Series |
[net-next] dt-bindings: net: marvell,orion-mdio: Drop "reg" sizes schema
|
|
Commit Message
Rob Herring
Dec. 13, 2023, 11:24 p.m. UTC
Defining the size of register regions is not really in scope of what
bindings need to cover. The schema for this is also not completely correct
as a reg entry can be variable number of cells for the address and size,
but the schema assumes 1 cell.
Signed-off-by: Rob Herring <robh@kernel.org>
---
.../bindings/net/marvell,orion-mdio.yaml | 22 -------------------
1 file changed, 22 deletions(-)
Comments
On Wed, Dec 13, 2023 at 05:24:55PM -0600, Rob Herring wrote: > Defining the size of register regions is not really in scope of what > bindings need to cover. The schema for this is also not completely correct > as a reg entry can be variable number of cells for the address and size, > but the schema assumes 1 cell. > > Signed-off-by: Rob Herring <robh@kernel.org> Does this not also remove restrictions on what the number in the reg entry is actually allowed to be? > --- > .../bindings/net/marvell,orion-mdio.yaml | 22 ------------------- > 1 file changed, 22 deletions(-) > > diff --git a/Documentation/devicetree/bindings/net/marvell,orion-mdio.yaml b/Documentation/devicetree/bindings/net/marvell,orion-mdio.yaml > index e35da8b01dc2..73429855d584 100644 > --- a/Documentation/devicetree/bindings/net/marvell,orion-mdio.yaml > +++ b/Documentation/devicetree/bindings/net/marvell,orion-mdio.yaml > @@ -39,28 +39,6 @@ required: > allOf: > - $ref: mdio.yaml# > > - - if: > - required: > - - interrupts > - > - then: > - properties: > - reg: > - items: > - - items: > - - $ref: /schemas/types.yaml#/definitions/cell > - - const: 0x84 > - > - else: > - properties: > - reg: > - items: > - - items: > - - $ref: /schemas/types.yaml#/definitions/cell > - - enum: > - - 0x4 > - - 0x10 > - > unevaluatedProperties: false > > examples: > -- > 2.43.0 >
On Thu, Dec 14, 2023 at 10:23 AM Conor Dooley <conor@kernel.org> wrote: > > On Wed, Dec 13, 2023 at 05:24:55PM -0600, Rob Herring wrote: > > Defining the size of register regions is not really in scope of what > > bindings need to cover. The schema for this is also not completely correct > > as a reg entry can be variable number of cells for the address and size, > > but the schema assumes 1 cell. > > > > Signed-off-by: Rob Herring <robh@kernel.org> > > Does this not also remove restrictions on what the number in the reg > entry is actually allowed to be? Yes, that's what I mean with the first sentence. We don't do this anywhere else with the exception of some I2C devices with fixed addresses. Keying off of the interrupt property also seems questionable. If the register size is different, that should be a different compatible. I only noticed this when I happened to remove "definitions/cell" and this broke. That wasn't really intended to be public. Rob
On Thu, Dec 14, 2023 at 12:12:42PM -0600, Rob Herring wrote: > On Thu, Dec 14, 2023 at 10:23 AM Conor Dooley <conor@kernel.org> wrote: > > > > On Wed, Dec 13, 2023 at 05:24:55PM -0600, Rob Herring wrote: > > > Defining the size of register regions is not really in scope of what > > > bindings need to cover. The schema for this is also not completely correct > > > as a reg entry can be variable number of cells for the address and size, > > > but the schema assumes 1 cell. > > > > > > Signed-off-by: Rob Herring <robh@kernel.org> > > > > Does this not also remove restrictions on what the number in the reg > > entry is actually allowed to be? > > Yes, that's what I mean with the first sentence. We don't do this > anywhere else with the exception of some I2C devices with fixed > addresses. Keying off of the interrupt property also seems > questionable. If the register size is different, that should be a > different compatible. Reading the code, it appears the hardware always supported interrupts, however the first version of the driver never used them. It seems like some DT blobs had the register space cover just the needed registers for polling, and excluded the interrupt control register. When interrupt support was added, all in-tree DT files were updated with the extended register space, but to allow backwards compatibility, the driver checks the length of the register space and will not enable interrupts if its too small. I'm guessing that since the hardware did not change, a new compatible was not used when adding interrupt support. And the yaml is there to help when old out of tree .dts files are merged into the tree and have the old register space. This is and old driver, and its usage of DT is from long before many of the current best practices where determined, or yaml was even an idea. So i'm not surprised it has a few odd quirks. I don't see a reason not to remove these constraints, as i said, the driver should do the right thing if the register space it too small and YAML does not warn about it. Andrew
On Fri, Dec 15, 2023 at 4:18 AM Andrew Lunn <andrew@lunn.ch> wrote: > > On Thu, Dec 14, 2023 at 12:12:42PM -0600, Rob Herring wrote: > > On Thu, Dec 14, 2023 at 10:23 AM Conor Dooley <conor@kernel.org> wrote: > > > > > > On Wed, Dec 13, 2023 at 05:24:55PM -0600, Rob Herring wrote: > > > > Defining the size of register regions is not really in scope of what > > > > bindings need to cover. The schema for this is also not completely correct > > > > as a reg entry can be variable number of cells for the address and size, > > > > but the schema assumes 1 cell. > > > > > > > > Signed-off-by: Rob Herring <robh@kernel.org> > > > > > > Does this not also remove restrictions on what the number in the reg > > > entry is actually allowed to be? > > > > Yes, that's what I mean with the first sentence. We don't do this > > anywhere else with the exception of some I2C devices with fixed > > addresses. Keying off of the interrupt property also seems > > questionable. If the register size is different, that should be a > > different compatible. > > Reading the code, it appears the hardware always supported interrupts, > however the first version of the driver never used them. It seems like > some DT blobs had the register space cover just the needed registers > for polling, and excluded the interrupt control register. When > interrupt support was added, all in-tree DT files were updated with > the extended register space, but to allow backwards compatibility, the > driver checks the length of the register space and will not enable > interrupts if its too small. > > I'm guessing that since the hardware did not change, a new compatible > was not used when adding interrupt support. And the yaml is there to > help when old out of tree .dts files are merged into the tree and have > the old register space. > > This is and old driver, and its usage of DT is from long before many > of the current best practices where determined, or yaml was even an > idea. So i'm not surprised it has a few odd quirks. > > I don't see a reason not to remove these constraints, as i said, the > driver should do the right thing if the register space it too small > and YAML does not warn about it. Is that an Ack? I almost read your double negative as a Nak and that's what the maintainers read because it is now "Rejected" in PW. Rob
On Wed, Dec 13, 2023 at 05:24:55PM -0600, Rob Herring wrote: > Defining the size of register regions is not really in scope of what > bindings need to cover. The schema for this is also not completely correct > as a reg entry can be variable number of cells for the address and size, > but the schema assumes 1 cell. > > Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Andrew
> Is that an Ack? I almost read your double negative as a Nak and that's > what the maintainers read because it is now "Rejected" in PW. I don't know if this will work, but we can give it a try. pw-bot: new Andrew
Hello: This patch was applied to netdev/net-next.git (main) by Jakub Kicinski <kuba@kernel.org>: On Wed, 13 Dec 2023 17:24:55 -0600 you wrote: > Defining the size of register regions is not really in scope of what > bindings need to cover. The schema for this is also not completely correct > as a reg entry can be variable number of cells for the address and size, > but the schema assumes 1 cell. > > Signed-off-by: Rob Herring <robh@kernel.org> > > [...] Here is the summary with links: - [net-next] dt-bindings: net: marvell,orion-mdio: Drop "reg" sizes schema https://git.kernel.org/netdev/net-next/c/758a8d5b6a64 You are awesome, thank you!
diff --git a/Documentation/devicetree/bindings/net/marvell,orion-mdio.yaml b/Documentation/devicetree/bindings/net/marvell,orion-mdio.yaml index e35da8b01dc2..73429855d584 100644 --- a/Documentation/devicetree/bindings/net/marvell,orion-mdio.yaml +++ b/Documentation/devicetree/bindings/net/marvell,orion-mdio.yaml @@ -39,28 +39,6 @@ required: allOf: - $ref: mdio.yaml# - - if: - required: - - interrupts - - then: - properties: - reg: - items: - - items: - - $ref: /schemas/types.yaml#/definitions/cell - - const: 0x84 - - else: - properties: - reg: - items: - - items: - - $ref: /schemas/types.yaml#/definitions/cell - - enum: - - 0x4 - - 0x10 - unevaluatedProperties: false examples: