| Message ID | 20260407223447.4956-2-andre.przywara@arm.com (mailing list archive) |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-sunxi+bounces-22799-sunxi=pue.re@lists.linux.dev> X-Original-To: noreply@patchwork.local Delivered-To: noreply@patchwork.local Received: from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10]) by mxe881.netcup.net (Postfix) with ESMTPS id 8B2D91C0093 for <noreply@patchwork.local>; Wed, 8 Apr 2026 00:35:05 +0200 (CEST) Authentication-Results: mxe881; dkim=pass header.d=arm.com; spf=pass (sender IP is 172.234.253.10) smtp.mailfrom=linux-sunxi+bounces-22799-noreply=patchwork.local@lists.linux.dev smtp.helo=sea.lore.kernel.org Received-SPF: pass (mxe881: domain of lists.linux.dev designates 172.234.253.10 as permitted sender) client-ip=172.234.253.10; envelope-from=linux-sunxi+bounces-22799-noreply=patchwork.local@lists.linux.dev; helo=sea.lore.kernel.org; Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sea.lore.kernel.org (Postfix) with ESMTP id D8C0A301F30F for <noreply@patchwork.local>; Tue, 7 Apr 2026 22:35:02 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A473D38644B; Tue, 7 Apr 2026 22:35:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="krm/eiVa" X-Original-To: linux-sunxi@lists.linux.dev Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 9F1BA3859D0 for <linux-sunxi@lists.linux.dev>; Tue, 7 Apr 2026 22:35:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775601302; cv=none; b=IUOjsSPOSKVQ715rAq1uaBrX51dFdQxIIaH3GFd53Wd1LXpHHxHoIs8NlfClbWoSJkD9FrUu/IXj03uS+cJ4ADYY4KQk7e5SJ0HpkNWurtfhtgrLl0HYb5pUaci/NS5nqjCh3LpR2uY1BJ6uUp0dwuUJzpv81d1mO2YP3t/mB2M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775601302; c=relaxed/simple; bh=c9zy5O2WPAHs1EpAo/D3JPndFAwUuQbakGizB9QGLl4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=n13o4yPxnYcufclWGTVT1rtZ2fW4RpuA4B9Tmo8iu3PSq9IYbQmvSTbeNLuJumyQHr4M3i3LW1FmxMXBq2eCcLQPuUcaacEvxyfeO6KvUltYDdzxHqTCooploB1sWJyYNml1KiyXmiHX0hRwsCrKYzFJ0buGFHg359GBT36YdRw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=krm/eiVa; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 44E0A3549; Tue, 7 Apr 2026 15:34:54 -0700 (PDT) Received: from ryzen.fritz.box (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C5D8C3F632; Tue, 7 Apr 2026 15:34:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1775601300; bh=c9zy5O2WPAHs1EpAo/D3JPndFAwUuQbakGizB9QGLl4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=krm/eiVarYpXPye+fKTVhe5K0LKbcMAqZ76HQNoQV1YUQFZBfBdp/Wvx1vPzEILLE Sf0scpcN0RRR6qx8NCdDCZyideKe/+CPBXEvansDZdwMSj7sWCdV6HBfMnuvR0aj+V r3MfmLe85rZs/MTzPOuvZ/GiQ8KMTrcn39Ljhshg= From: Andre Przywara <andre.przywara@arm.com> To: u-boot@lists.denx.de Cc: Tom Rini <trini@konsulko.com>, Quentin Schulz <quentin.schulz@cherry.de>, Jernej Skrabec <jernej.skrabec@gmail.com>, Paul Kocialkowski <contact@paulk.fr>, linux-sunxi@lists.linux.dev Subject: [PATCH 1/3] sunxi: spl: fix SPL_SUNXI_LED active low configuration Date: Wed, 8 Apr 2026 00:34:45 +0200 Message-ID: <20260407223447.4956-2-andre.przywara@arm.com> X-Mailer: git-send-email 2.46.4 In-Reply-To: <20260407223447.4956-1-andre.przywara@arm.com> References: <20260407223447.4956-1-andre.przywara@arm.com> Precedence: bulk X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: <linux-sunxi.lists.linux.dev> List-Subscribe: <mailto:linux-sunxi+subscribe@lists.linux.dev> List-Unsubscribe: <mailto:linux-sunxi+unsubscribe@lists.linux.dev> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspamd-worker-8404 X-Spamd-Result: default: False [-0.66 / 15.00]; BAYES_HAM(-5.50)[100.00%]; RBL_SENDERSCORE(2.00)[172.234.253.10:from]; SUSPICIOUS_RECIPS(1.50)[]; MID_CONTAINS_FROM(1.00)[]; R_MISSING_CHARSET(0.50)[]; MAILLIST(-0.15)[generic]; MIME_GOOD(-0.10)[text/plain]; BAD_REP_POLICIES(0.10)[]; HAS_LIST_UNSUB(-0.01)[]; FROM_HAS_DN(0.00)[]; PRECEDENCE_BULK(0.00)[]; TAGGED_RCPT(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FUZZY_BLOCKED(0.00)[rspamd.com]; DBL_BLOCKED_OPENRESOLVER(0.00)[sea.lore.kernel.org:rdns,sea.lore.kernel.org:helo,arm.com:email,arm.com:dkim]; FORGED_SENDER_MAILLIST(0.00)[]; FREEMAIL_CC(0.00)[konsulko.com,cherry.de,gmail.com,paulk.fr,lists.linux.dev]; R_DKIM_ALLOW(0.00)[arm.com:s=foss]; RCVD_COUNT_FIVE(0.00)[6]; ARC_ALLOW(0.00)[subspace.kernel.org:s=arc-20240116:i=1]; RCPT_COUNT_FIVE(0.00)[6]; DKIM_TRACE(0.00)[arm.com:+]; R_SPF_ALLOW(0.00)[+ip4:172.234.253.10]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[100.90.174.1:received]; TO_DN_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[andre.przywara@arm.com,linux-sunxi@lists.linux.dev]; DMARC_POLICY_ALLOW(0.00)[arm.com,none]; MIME_TRACE(0.00)[0:+]; TAGGED_FROM(0.00)[bounces-22799-noreply=patchwork.local]; FORGED_RECIPIENTS_MAILLIST(0.00)[]; ASN(0.00)[asn:63949, ipnet:172.234.224.0/19, country:SG]; RCVD_TLS_LAST(0.00)[]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[172.234.253.10:from] X-Rspamd-Queue-Id: 8B2D91C0093 X-MORS-Enabled: yes X-MORS-DOMAIN: patchwork.local X-MORS-HOSTING: hosting172546 X-MORS-USER: hosting172546 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= |
| Series |
sunxi: Fix and extend SPL power LED support
|
|
Commit Message
Andre Przywara
April 7, 2026, 10:34 p.m. UTC
The newly introduced Allwinner SPL LED "framework" defined a
SPL_SUNXI_LED_STATUS_STATE Kconfig symbol, that was supposed to denote
the active-low vs. active-high polarity of the LED. However this is
a bool symbol, so it will simply vanish if not defined, and we cannot use
it directly inside a C statement.
Filter the symbol through the IS_ENABLED() macro, which will return 0 if
the symbol is not defined, which is the intended value here.
This fixes configuring LEDs with active-low polarity.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
board/sunxi/board.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
Hi Andre, On 4/8/26 12:34 AM, Andre Przywara wrote: > The newly introduced Allwinner SPL LED "framework" defined a > SPL_SUNXI_LED_STATUS_STATE Kconfig symbol, that was supposed to denote > the active-low vs. active-high polarity of the LED. However this is > a bool symbol, so it will simply vanish if not defined, and we cannot use > it directly inside a C statement. > Ugh, thanks for catching that! > Filter the symbol through the IS_ENABLED() macro, which will return 0 if > the symbol is not defined, which is the intended value here. > > This fixes configuring LEDs with active-low polarity. > Fixes: 256557dd9aae ("sunxi: remove usage of legacy LED API") Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Thanks! Quentin
Hi, On Wed 08 Apr 26, 00:34, Andre Przywara wrote: > The newly introduced Allwinner SPL LED "framework" defined a > SPL_SUNXI_LED_STATUS_STATE Kconfig symbol, that was supposed to denote > the active-low vs. active-high polarity of the LED. However this is > a bool symbol, so it will simply vanish if not defined, and we cannot use > it directly inside a C statement. > > Filter the symbol through the IS_ENABLED() macro, which will return 0 if > the symbol is not defined, which is the intended value here. > > This fixes configuring LEDs with active-low polarity. > > Signed-off-by: Andre Przywara <andre.przywara@arm.com> > --- > board/sunxi/board.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/board/sunxi/board.c b/board/sunxi/board.c > index d7722d1858a..80dcae9c1a4 100644 > --- a/board/sunxi/board.c > +++ b/board/sunxi/board.c > @@ -563,7 +563,7 @@ static void sunxi_spl_store_dram_size(phys_addr_t dram_size) > static void status_led_init(void) > { > #if CONFIG_IS_ENABLED(SUNXI_LED_STATUS) > - unsigned int state = CONFIG_SPL_SUNXI_LED_STATUS_STATE; > + unsigned int state = IS_ENABLED(CONFIG_SPL_SUNXI_LED_STATUS_STATE); Sorry I didn't react to the initial submission, but it feels like the CONFIG_SPL_SUNXI_LED_STATUS_STATE symbol really means active-high if enabled and active-low if disabled. The name would suggest that it's an int with a value of either 0 or 1 instead. I think it would be less confusing to call the symbol CONFIG_SPL_SUNXI_LED_STATUS_ACTIVE_LOW and reverse its meaning, so that we can spare defining it in most configs (that will be active-high). Also the description currently mentions "initial state" which may be confusing as it could refer to the state inherited after reset (e.g. due to some pull resistor) or the state we do set in the SPL. > unsigned int gpio = CONFIG_SPL_SUNXI_LED_STATUS_BIT; And while at it I would rename this to something like: CONFIG_SPL_SUNXI_LED_STATUS_GPIO since it indicates the GPIO number, not a specific bit in a sunxi-specific kind of register. What do you think? All the best, Paul > > gpio_request(gpio, "gpio_led"); > -- > 2.46.4 >
diff --git a/board/sunxi/board.c b/board/sunxi/board.c index d7722d1858a..80dcae9c1a4 100644 --- a/board/sunxi/board.c +++ b/board/sunxi/board.c @@ -563,7 +563,7 @@ static void sunxi_spl_store_dram_size(phys_addr_t dram_size) static void status_led_init(void) { #if CONFIG_IS_ENABLED(SUNXI_LED_STATUS) - unsigned int state = CONFIG_SPL_SUNXI_LED_STATUS_STATE; + unsigned int state = IS_ENABLED(CONFIG_SPL_SUNXI_LED_STATUS_STATE); unsigned int gpio = CONFIG_SPL_SUNXI_LED_STATUS_BIT; gpio_request(gpio, "gpio_led");