From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pidgin.makrotopia.org (pidgin.makrotopia.org [185.142.180.65]) (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 4B0C9101C4; Mon, 7 Oct 2024 11:31:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.142.180.65 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728300681; cv=none; b=Xu6Tll7q8LvyX2VDP5F78ZrjC9d/WBnc/O0xW5G5rU10BW+GaLVJVihV2vTny64V87wJVYhEVe1QmukQDOlFSG1ipjnFBtbEKuV0gghqy4Bj0QvSBM7nDvQ4kSuiPuC/o699wgIygdv/XpSqOwj0gz6N0GMT9V+KgKUWu/a3aWA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728300681; c=relaxed/simple; bh=7tFqPXIR8Oj7mN8Mv3E1ReRdWth6sARj/sqyo2PSm6M=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Pfxri3hzE1l0Qsmnzb7CbOEE8ZR2HTbe5iMOWcBp07Ox43/PObLO4sXCNr1QZGctQaoEa5Ve2vjM0LDMGhK0QQEmC2HmTZBIlTR3ybyC4jz4z+nTfkWWKszWw2DTAAe+V6+zbRUoPwlIf1HvLGFA5JOD4DWB12aCpmSZWBeWIls= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=makrotopia.org; spf=pass smtp.mailfrom=makrotopia.org; arc=none smtp.client-ip=185.142.180.65 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=makrotopia.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=makrotopia.org Received: from local by pidgin.makrotopia.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.98) (envelope-from ) id 1sxlx9-000000002KX-3SEU; Mon, 07 Oct 2024 11:31:03 +0000 Date: Mon, 7 Oct 2024 12:30:53 +0100 From: Daniel Golle To: Krzysztof Kozlowski Cc: Pavel Machek , Lee Jones , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Andrew Lunn , Heiner Kallweit , Russell King , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Xu Liang , Christian Marangi , Bartosz Golaszewski , Robert Marko , Russell King , Abhishek Chauhan , Jacek Anaszewski , linux-leds@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH net-next 1/4] dt-bindings: leds: add 'active-high' property Message-ID: References: <4qk3lpdx47b27ru47avpiygijtu5kkax44t3o4wb2wv5m5djoz@uziseiklyq3d> <6d3hvesqhslk7jaszo44orbaqabl7go6duzpu4beye44sa6lpn@b3c56bp6x3ce> Precedence: bulk X-Mailing-List: linux-leds@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: <6d3hvesqhslk7jaszo44orbaqabl7go6duzpu4beye44sa6lpn@b3c56bp6x3ce> On Mon, Oct 07, 2024 at 08:38:27AM +0200, Krzysztof Kozlowski wrote: > On Sun, Oct 06, 2024 at 02:04:35PM +0100, Daniel Golle wrote: > > On Sun, Oct 06, 2024 at 02:44:44PM +0200, Krzysztof Kozlowski wrote: > > > I think this should be just string enum, see marvell,marvell10g.yaml > > > > I found the vendor-specific 'marvell,polarity' property in > > https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20231214201442.660447-5-tobias@waldekranz.com/ > > > > However, I can't find that file in any Linux tree. > > > > Looking at the suggested patch on patchwork, I got a few questions on > > how to deal with the situation as of today: > > > > So should the existing support for the 'active-low' and > > 'inactive-high-impedance' properties be replaced by that string enum? > > Or should the string property be interpreted in addition to the > > bools defined in leds/common.yaml? > > > > Should the string property be defined for each PHY or should we move > > it into a common file? > > > > If so, should that common file also be leds/common.yaml or should we > > create a new file only for PHY LEDs instead? > > > > Sorry for being confused, I don't mind going down what ever path to have > > LED polarity configurable properly in DT. > > Let's ignore my idea. > > However I still wonder whether your choice for lack of properties is > appropriate. Lack of properties as "bootloader default" means it can > change. Why would anyone prefer to keep bootloader default? The wiring > is fixed - it's never "we design PCB based on bootloader, so with new > bootloader we will change PCB"? > > And if you meant bootstrapping through some hardwired configuration, > then again it is known and defined. I agree, and my original intention was to just always apply polarity settings and force people to correctly declare them in DT. However, that would break DT compatibility on devices not making use of those properties and relying only on strapping or bootloader defaults. See also RFC discussed here: https://patchwork.kernel.org/project/netdevbpf/patch/473d62f268f2a317fd81d0f38f15d2f2f98e2451.1728056697.git.daniel@makrotopia.org/