From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BC7E52F290E for ; Wed, 18 Mar 2026 17:26:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773854809; cv=none; b=J61cvw9tUAuYyaI63XzygCjYnF1t4buyMDely5efbs3HcCgnEpwRNqDvOCHb5WYic/sg3ziaNBBKHoTbGym9FbenV2JzF3fqPZYtmxylhUNWlfESDjrgrrB9yBCh/ZDI2x9ua5yebqfjRXYbJFdaTnUHUgmyzbAa6ZAzGWpK/qI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773854809; c=relaxed/simple; bh=W7ybQORcMKJdkf3BWpImd7y/jVljsB/C0BVysNSKorw=; h=Message-ID:Date:From:To:Cc:Subject:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=m6OfNWb499QliiHQB17LWKZVqcrtjgvvzCfpf+ucUhv8JTDbGVxraamPrd1azfhBfakoeBIb8zf4pQGvhla47IbVzWQtgGGmI1EKwnnV24DXG4DUveFfbLmUGmelSXNObpHmnKe9QK3eWveb7QaEWqkQspvR/bKNtGAKcqCfT9o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=W4KeVKxG; arc=none smtp.client-ip=209.85.128.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="W4KeVKxG" Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-48540d21f7dso1046965e9.0 for ; Wed, 18 Mar 2026 10:26:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773854806; x=1774459606; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:subject:cc :to:from:date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=5EKjOvd8tsoDAzL2NTfko88oUtO7N2mQq0+WyC0PbRc=; b=W4KeVKxG4tII1s7aQw0Jv0GkSiKCwRZCRTCuUq2kO7Mu8krmc+aFOp8tQOAv52faVq OkE0IuRipgx1KER0lATSbnNYSK5TEnct+sFnXQN1Yk92p9PRflzF3NFyDdIMr4aHXBHw bbksQOD01GgOI8qCKDKW6rILlRFSjWYu30i0FU1ByNaalW9jbuW0wcGItXBE0OE+AQW0 EBO12oaY35MHqV4AD3hUUVREyvwmc9NFA8MoOBbTMls2EjXKtscYx4wWCDTBknNpk97A WYzHftWKzZItMkrr2puesclWa51a5piysgCTEXTHZ6RSoVEp9l1QV+LFdjOJ5pdCaIIw w4Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773854806; x=1774459606; h=in-reply-to:content-disposition:mime-version:references:subject:cc :to:from:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5EKjOvd8tsoDAzL2NTfko88oUtO7N2mQq0+WyC0PbRc=; b=WHWRroJVD6azwBQzEh7ctlHiRXka8Efta1UfxOHdX1R6m+3VVveq5h2c0keWnQTiwX sIn3yUqTPFQTeEwCGl0O+2FDY60sM7/CK1tOpPT9zYrwiYtJRkteJLz20tKZfe3pOWUN P860Pzz43UciVYIdLm8KLAKKcz98LILjM3zZiXijfFg7QqvEHP7BMvOKNuaBVMpavk+/ D7ZEWxJ7+D7Pd4OFe+pSNh6elLyg4dYEE6IU8mHTh2CZ8rVNdtxIA+U0ZbwRFktdOe69 682ZFcUEB4CNpC7H/2uhRVDAgc9C7XAGgAA+XY3HVJXCzyy96X7D+6UR9HRjfcgvtS3R O9fQ== X-Forwarded-Encrypted: i=1; AJvYcCUqmYieBwh6GA6/ipsEMJqxjd3htGWDpX9nf2J9KsnJOdnAKRdK9obcGahCzwr3kVYIHts8B8AVZ+0s+EM=@vger.kernel.org X-Gm-Message-State: AOJu0YwVGkvllcocvim7DXe9gzNM0TaBXR+I/dQmtDGv4578PcGEdItD W0EtJ3GIaz8vdwRCujCiugKeXBwnd8iR8sbZPpQPz9KeMboHymSDz1MV X-Gm-Gg: ATEYQzzgaqT6R6uee5FPY4irtcSQI+7asvNRdReQgE5yxEGfFGZlqlntHZ1dbakPZkO GxHLs/60gd2Bliwem8yqXcrZ91sqr7n1+TJOYjC8MuVUeMm0NsHsBlnpSfSnjPLM/T6035JYpD7 r9eORDhk39UlvYWIOIhUDID7hY6fusgrYJtEiiofbionmZS2CzvgHbfIFAXhZCpdvjX672+iOLy GcxLOPyO//6RMbd9i7H/I2zF4W55d91dQj+AWVW9kCl0tSsPzz7W/wG0vbWn8UnfXtmB5xaAPZr HV2dehaW6QYyQyixeKPntSbqyYj3OUS40NFl+RmldCLTeBYZST4PRmAiGEOenuH21AzRzg2eV8z 9tdndRlmbC2q1JdKg6k9wgdbMFGC76GhndkjO7NqOH/xfpoOlrXAz0qsDD8w3Sfed/THcsSI6H4 dl8tXPPzmWHOwPCoBuUCs/SofJwcMfpDMGByovcy9gREUKrW+fz7rlyA== X-Received: by 2002:a05:600c:8683:b0:485:f1d1:8f3d with SMTP id 5b1f17b1804b1-486f442e6e5mr52764705e9.6.1773854805737; Wed, 18 Mar 2026 10:26:45 -0700 (PDT) Received: from Ansuel-XPS. (93-34-88-122.ip49.fastwebnet.it. [93.34.88.122]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-486f4e48ad5sm113684005e9.1.2026.03.18.10.26.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Mar 2026 10:26:45 -0700 (PDT) Message-ID: <69bae055.050a0220.3719be.bf31@mx.google.com> X-Google-Original-Message-ID: Date: Wed, 18 Mar 2026 18:26:42 +0100 From: Christian Marangi To: Conor Dooley Cc: Jens Emil Schulz Ostergaard , Andrew Lunn , UNGLinuxDriver@microchip.com, Vladimir Oltean , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Woojung Huh , Russell King , Steen Hegelund , Daniel Machon , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH net-next 2/8] dt-bindings: net: lan9645x: add LAN9645X switch bindings References: <20260303-dsa_lan9645x_switch_driver_base-v1-2-bff8ca1396f5@microchip.com> <4088b0ff-b718-4137-8518-4c9b9764d56d@lunn.ch> <20260303-mosaic-debate-90cf8c8bbb33@spud> <1db45715a3a12b76b838d20c0e5904c3222053e7.camel@microchip.com> <20260305-reliant-parchment-0ff685a9c78e@spud> <7b62ace495084794336b19a9685d6b14ea3981a0.camel@microchip.com> <20260306-pointless-purr-210540d4dc64@spud> <207c7a47e0802dd4c34ba90f2532dc2e0c3f7f05.camel@microchip.com> <20260318-visiting-tanning-7d1d6acff081@spud> <20260318-placidly-domain-3ea82d265517@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=us-ascii Content-Disposition: inline In-Reply-To: <20260318-placidly-domain-3ea82d265517@spud> On Wed, Mar 18, 2026 at 05:20:03PM +0000, Conor Dooley wrote: > On Wed, Mar 18, 2026 at 05:18:42PM +0000, Conor Dooley wrote: > > Christian, > > > > On Wed, Mar 18, 2026 at 03:19:20PM +0100, Jens Emil Schulz Ostergaard wrote: > > > Hi Conor, > > > > > > On Fri, 2026-03-06 at 15:20 +0000, Conor Dooley wrote: > > > > On Fri, Mar 06, 2026 at 04:08:01PM +0100, Jens Emil Schulz Ostergaard wrote: > > > > > On Thu, 2026-03-05 at 18:31 +0000, Conor Dooley wrote: > > > > > > On Thu, Mar 05, 2026 at 01:57:37PM +0100, Jens Emil Schulz Ostergaard wrote: > > > > > > > On Tue, 2026-03-03 at 19:04 +0000, Conor Dooley wrote: > > > > > > > > On Tue, Mar 03, 2026 at 03:18:45PM +0100, Andrew Lunn wrote: > > > > > > > > > > + properties: > > > > > > > > > > + microchip,led-drive-mode: > > > > > > > > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > > > > > > > > + description: | > > > > > > > > > > + Set the LED drive mode for the copper PHY associated with > > > > > > > > > > + this port. > > > > > > > > > > + > > > > > > > > > > + 0 - LED1 and LED2 in open-drain mode > > > > > > > > > > + 1 - LED1 in active drive mode (can be used for single-LED > > > > > > > > > > + configurations requiring active drive) > > > > > > > > > > + 2 - Reserved > > > > > > > > > > + 3 - LED1 and LED2 in active drive mode > > > > > > > > > > + minimum: 0 > > > > > > > > > > + maximum: 3 > > > > > > > > > > > > > > > > > > I doubt the DT Maintainers will accept that. This looks a lot like a > > > > > > > > > value you write into a register. How are active drive and open-drain > > > > > > > > > described in other DT bindings? Is there something you can reuse? > > > > > > > > > > > > > > > > I had a quick look and I didn't see anything really that stood out to me > > > > > > > > that would be a drop-in replacement. > > > > > > > > I also tried looking in the datasheet for more information on these > > > > > > > > modes, but I couldn't see anything obvious. For example, there were zero > > > > > > > > hits for "drain" in either LAN9645xS or LAN9645xF datasheets. > > > > > > > > > > > > > > > > That said, yea you're right about DT maintainer feelings about it. > > > > > > > > There's a couple things I could suggest, but I'd like to know about what > > > > > > > > mode 1 means for LED2 first. If there's actually nothing similar, what > > > > > > > > about representing each led with a child node and having open-drain be > > > > > > > > the default with a property in the child for active-drive? > > > > > > > > > > > > > > > > > > > > > > > > > > For 1, what happens to LED2? Not used at all? > > > > > > > > > > > > > > In mode 1 LED2 will be open-drain. This mode only makes sense if you have > > > > > > > just 1 LED. With two LEDs mode 0 or mode 3 should be used. > > > > > > > > > > > > Could we then have child nodes for each led, and have a property in each > > > > > > that sets the mode to either open-drain or active-drive? Or am I just > > > > > > inserting complexity by asking for that? > > > > > > > > > > I think it sounds sensible, I will add this. > > > > > > > > > > > > You don't need a property for each, just make one mode the default (prob > > > > open-drain given it's the 0 setting, but whatever is default out of > > > > reset for the part) and have the property for the other mode. Just > > > > some bool property like "microchip,active-drive" or whatever. > > > > > > > > > Based on your feedback I went with this under port properties: > > > > > > leds: > > > patternProperties: > > > '^led@[a-f0-9]+$': > > > $ref: /schemas/leds/common.yaml# > > > > > > properties: > > > reg: > > > maxItems: 1 > > > > > > microchip,active-drive: > > > type: boolean > > > description: > > > Set the LED output to active drive mode. The default > > > is open-drain. > > > > > > required: > > > - reg > > > > > > unevaluatedProperties: false > > > > > > and then the example has > > > > > > port@1 { > > > reg = <1>; > > > phy-mode = "gmii"; > > > phy-handle = <&cuphy1>; > > > > > > leds { > > > #address-cells = <1>; > > > #size-cells = <0>; > > > > > > led@0 { > > > reg = <0>; > > > microchip,active-drive; > > > }; > > > > > > led@1 { > > > reg = <1>; > > > microchip,active-drive; > > > }; > > > }; > > > } > > > > > > However, this does not pass dt_binding_check because we pull in $ref: dsa-port.yaml, > > > which pulls in ethernet-controller.yaml. > > > > > > I believe the 'unevaluatedProperties: false' on LED nodes in ethernet-controller.yaml > > > prevents downstream bindings from adding vendor-specific LED properties. > > > > > > Is the right move removing unevaluatedProperties: false from the LED node in > > > ethernet-controller.yaml, or is there a preferred way to extend per-port LEDs? > > > > The addition looks recent enough, should probably ask Christian why it > > was done this way and if removing it makes sense. Christian? > > > > Ah shit, I autopiloted into sending. Actually +CC Christian this time. Hi, give me some time to experiment... AFAIK with my limited info on DT, unevaluatedProperties permits to add vendor property as long as they are well defined. If the dt_binding_check is failing, then it's probably because unevaluatedProperties is finding that in the expected LED node there is extra stuff in the SCHEMA example. But give me some time to experiment with some other SCHEMA. -- Ansuel