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 D0340CDB47E for ; Fri, 13 Oct 2023 15:40:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232439AbjJMPk6 (ORCPT ); Fri, 13 Oct 2023 11:40:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47644 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232270AbjJMPk4 (ORCPT ); Fri, 13 Oct 2023 11:40:56 -0400 Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EBA7BB7; Fri, 13 Oct 2023 08:40:53 -0700 (PDT) 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=AfBFoBaUMyUga0dX/cinZPk6S2n8duwEaG/WLcvim9s=; b=51 TazhTgjAYk9QxOl2q//WchftDn7G9zs/Aw6T9S6HyofI/H6dnmz2lkFOQYo3xq0VMKxpDKQBeFMBS 8yh6vhKZqp/9UU8NcRuVD4ATjUuXiEqUoB7iOTrfXkhdGucviCJYYf7ehzFXfce4BviInU9nn/G+C 7BZCI5ODGUDWvHk=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1qrKHB-0026de-TM; Fri, 13 Oct 2023 17:40:33 +0200 Date: Fri, 13 Oct 2023 17:40:33 +0200 From: Andrew Lunn To: Linus Walleij Cc: Gregory Clement , Sebastian Hesselbarth , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Russell King , Florian Fainelli , Vladimir Oltean , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Christian Marangi , linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH 2/3] RFC: dt-bindings: marvell: Rewrite in schema Message-ID: <7dd3839a-73da-4fa2-8f0f-e9384a2f0541@lunn.ch> References: <20231013-marvell-88e6152-wan-led-v1-0-0712ba99857c@linaro.org> <20231013-marvell-88e6152-wan-led-v1-2-0712ba99857c@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 13, 2023 at 03:04:10PM +0200, Linus Walleij wrote: > Hi Andrew, > > thanks for reviewing! > > On Fri, Oct 13, 2023 at 2:43 PM Andrew Lunn wrote: > > > > +properties: > > > + compatible: > > > + oneOf: > > > + - enum: > > > + - marvell,mv88e6060 > > > > The 6060 is a separate driver. Its not part of mv88e6xxx. So it should > > have a binding document of its own. > > It really doesn't matter to the DT bindings. > It is not the job of DT to reflect the state of Linux. > > In another operating system they might all be the same driver. > Or all four variants have their own driver. > > If the hardware is distinctly different so a lot of the properties > are unique then it may be warranted with a separate DT > binding, for the sake of keeping bindings simpler and > coherent. What i want to avoid is giving the impression that the mv88e6060 implements something when in fact it does not. That device does not have the interrupt controller, so all the interrupt properties are invalid for it. The hardware does not allow access to the EEPROM, so the EEPROM length property is not valid, etc. If you do want to make it part of the binding, it would be good to add constraints based on the compatible to indicate which properties are actually valid for the hardware. The 88e6060 actually has an open datasheet. https://www.insidegadgets.com/wp-content/uploads/2014/07/88E6060.pdf Andrew