Received: by 2002:a05:7412:8d10:b0:f3:1519:9f41 with SMTP id bj16csp6571038rdb; Fri, 15 Dec 2023 02:18:42 -0800 (PST) X-Google-Smtp-Source: AGHT+IFQ79Y74t7zfixR7tBMvO8FgGN8z0kR10j7cG1XxeO6kwhpY6F892vYWOtXn1XFakN+HB7j X-Received: by 2002:ad4:5761:0:b0:67f:161a:1ddf with SMTP id r1-20020ad45761000000b0067f161a1ddfmr1736431qvx.33.1702635522559; Fri, 15 Dec 2023 02:18:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702635522; cv=none; d=google.com; s=arc-20160816; b=XCIis4r3UCvyWZGBi7+/D1h5mHUI3REgkWojUGtEna8iTmwaNVSl+yEn04AjObAstj tz54OxaHPn2zn0/1mFlTSVQzXj0qrJ3Sg0K0NxWmIvXiiFFuKcxmJnEtI4Yi4NR5/ZM8 JX6DPuDdv3p+6cKVRYV6VAfY82dZ/1aym/hIkQm/3BrWFVot6ZtcyHDMegnPc7hoPYqV 4RJGh5jJ+HHrZJxIaSedRNFMMgpqz39g0NGW+KNznkclAj6+13+5wAuSelj8WWFP41jj dqTZjKEXS6dfx7h7pP5ousI0vZSNeb5o6byG9IB77w5wuSh3lElcLGn8aehKi12hUnAq fbLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:message-id:subject:cc:to:from:date:dkim-signature; bh=NaKT5qoM+qCmvzKX65nbLG/srH1WrOorsHKdumObti8=; fh=q3YbbfcNpKAPYrDasoVLlmGQkc9jhmDPDjTIhL0a+2M=; b=Sd5nqPE8PGyzNUmbSWqWURZgY9ov0ssEyfvbGp8uDvg8XnA6Lnzr5wNSSfjgL5iXTN pZ8u6vYGb+bC+7Xj+ycssmt1AT0caH+QBM1o748OBSgwp4L/rU9H2kAKNw1kg2EtvTck NEM4bJtHM3KqegTX7ltwJ8ggwacejVu3i1YW8HmHdFh0IWSZSHKU1mAVgkm1yIdFqFv1 +/gQMV+JFlTckbX71XYGbN+DJ+/szqnHYYdR+rThU92phznXQPjMzNK6+O/IVcQW8BBD NEtI+eNJn2TAoiuwD9/sFHxKHOPHYhmlPrGBFeqEGDkMVoks5WLFjtObzr+wKey4bHL5 zdrw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=NJjjmzbB; spf=pass (google.com: domain of linux-kernel+bounces-732-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-732-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=lunn.ch Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id dl13-20020ad44e0d000000b0067a9e1a97basi17678887qvb.381.2023.12.15.02.18.42 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Dec 2023 02:18:42 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-732-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=NJjjmzbB; spf=pass (google.com: domain of linux-kernel+bounces-732-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-732-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=lunn.ch Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 4A65E1C22FD0 for ; Fri, 15 Dec 2023 10:18:42 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2F21019479; Fri, 15 Dec 2023 10:18:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="NJjjmzbB" X-Original-To: linux-kernel@vger.kernel.org Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) (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 C33F01A596; Fri, 15 Dec 2023 10:18:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lunn.ch Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lunn.ch DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Transfer-Encoding:Content-Disposition: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:From: Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Content-Disposition: In-Reply-To:References; bh=NaKT5qoM+qCmvzKX65nbLG/srH1WrOorsHKdumObti8=; b=NJ jjmzbBpViyMWjd/BWRY6PLwWucmKJSCdLtRqTA97Yfa4MiQnXnMYihg47mshv2m3yCUN7ljv5z3g3 ZO4cgeDx1T9i27CTcOfLNiwoqbmCkND1P/IBljgq0vA3euiwFY9gfzIbPOBJwDL1k8YH7MC4r2baQ tuLD2BL8k9cUB2c=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1rE5Gw-0030Yc-Ry; Fri, 15 Dec 2023 11:18:22 +0100 Date: Fri, 15 Dec 2023 11:18:22 +0100 From: Andrew Lunn To: Rob Herring Cc: Conor Dooley , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Krzysztof Kozlowski , Conor Dooley , netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next] dt-bindings: net: marvell,orion-mdio: Drop "reg" sizes schema Message-ID: References: <20231213232455.2248056-1-robh@kernel.org> <20231214-buzz-playlist-2f75095ef2b0@spud> 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 Thu, Dec 14, 2023 at 12:12:42PM -0600, Rob Herring wrote: > On Thu, Dec 14, 2023 at 10:23 AM Conor Dooley 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 > > > > 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