Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp3835748pxb; Mon, 4 Oct 2021 10:37:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx3Gy6nSu6C7oSSMt7DYhq9TychKTN6q8s/GL540ejbTFakn5IxK9cXEtuULv5UWbYoL4Pk X-Received: by 2002:a05:6a00:10cc:b0:44c:852:41d8 with SMTP id d12-20020a056a0010cc00b0044c085241d8mr22498936pfu.54.1633369056739; Mon, 04 Oct 2021 10:37:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633369056; cv=none; d=google.com; s=arc-20160816; b=vHcByAEaaJmQFo9jhfC5qwg5UYLdFnX9XwW2EbZa2LbSN85zzf7WaRMJs20obt+vrS fZOL83O30C5KTzkVGfrnYgS8lgkGg6xKQCz6gjTHKk+X29FSGmzSuENHjCccZPRAXoLE T60QXAhDINaNCpH2bIVJtBYhsq7+2c73inp9oELNqYrdxTEeLJpQaZ2VSiG31ZiJhKbp jxIm5MEyLFicMOxD8bhHZA8nCZPOjhdfTpb6h7EWODhqv/h+7IRI91oKiGUgBjF3euVT 38zyKLDQOou235Ki7GCmaH3iixtGhzC8wxfUXWRUbNFUoiTfjM0UM/wWQ5yAbTtvudH3 zE4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=wOZTTETwQj+aeizjny2ZCg9H4PeRjV/em09E5T3i7eE=; b=BfkCpxle0s8nh8oIMbIx3oPGgx2f33y8y/MlapDiP+1q3QaAI7brJTHPfPWwdM3KNE LSSRIF39A0ZBbn1onH/1+CFBF7nTtubkXjsHJUs5xx4tmRIU5lUUWCQHg1NWwujBKFDi +XAF58lQqqvemNDQJ+ui6ArLWzYLbVSXyA3/tqaOxj3X++gz+pv1LXMpKwATnzW3UQsw Ybi+IRBlo8iKI/UmilxGL4lQrRjjCqhV9xmQYIRO09vR96U/54VwJGf+QOL5Y2kBrPzG +GEbzBXW+b7tNi9epRNW662q4jKezWqU6Ak4cLa32mU1o0BxI+3i2Y+gzdj3zANuy/hr 3SmA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=Uk2eAfNz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 26si5551303pgk.191.2021.10.04.10.37.21; Mon, 04 Oct 2021 10:37:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=Uk2eAfNz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235228AbhJDOwD (ORCPT + 99 others); Mon, 4 Oct 2021 10:52:03 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:47742 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234608AbhJDOwC (ORCPT ); Mon, 4 Oct 2021 10:52:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To: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=wOZTTETwQj+aeizjny2ZCg9H4PeRjV/em09E5T3i7eE=; b=Uk2eAfNzdCk2uC7qWfID3JcISm toY6VyR9oZSXNSBVujC/1L1b2mn2Dpzpe+df7kwFE4glcMeHhtIkyQy4KxpvgqfY/KshbsVE/uBUM NT4FapRTC2Q48JIfiRpsyubM5Gg6+mX30L+T6YEc5aJTGqfNWSLnatmcoSQ/LW61vvOU=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1mXPI9-009YcN-2b; Mon, 04 Oct 2021 16:50:09 +0200 Date: Mon, 4 Oct 2021 16:50:09 +0200 From: Andrew Lunn To: Marek =?iso-8859-1?Q?Beh=FAn?= Cc: Rob Herring , Pavel Machek , Jacek Anaszewski , "linux-leds@vger.kernel.org" , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: lets settle the LED `function` property regarding the netdev trigger Message-ID: References: <20211001143601.5f57eb1a@thinkpad> <20211003212654.30fa43f5@thinkpad> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211003212654.30fa43f5@thinkpad> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Hello Andrew, > > I am aware of this, and in fact am working on a proposal for an > extension of netdev LED extension, to support the different link > modes. (And also to support for multi-color LEDs.) > > But I am not entirely sure whether these different link modes should be > also definable via device-tree. Are there devices with ethernet LEDs > dedicated for a specific speed? (i.e. the manufacturer says in the > documentation of the device, or perhaps on the device's case, that this > LED shows 100M/1000M link, and that other LED is shows 10M link?) > If so, that this should be specified in the devicetree, IMO. But are > such devices common? I have a dumb 5 port switch next to me. One port is running at 1G. Its left green LED is on and blinks with traffic. Another port of the switch is running at 100Mbps and its right orange LED is on, blinks for traffic. And there is text on the case saying 10/100 orange, 1G green. I think this is pretty common. You generally do want to know if 10/100 is being used, it can indicate problems. Same for a 10G port running at 1G, etc. > And what about multi-color LEDs? There are ethernet ports where one LED > is red-green, and so can generate red, green, and yellow color. Should > device tree also define which color indicates which mode? There are two different ways this can be implemented. There can be two independent LEDs within the same package. So you can generate three colours. Or there can be two cross connected LEDs within the package. Apply +ve you get one colour, apply -ve you get a different colour. Since you cannot apply both -ve and +ve at the same time, you cannot get both colours at once. If you have two independent LEDs, I would define two LEDs in DT. Things get tricky for the two dependency LEDs. Does the LED core have support for such LEDs? This is where we need to strike a balance between too simple and too complex. Implement most of the common features, but don't support exotic stuff, like two dependency LEDs? Andrew