From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) (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 D4577271A71 for ; Thu, 4 Dec 2025 18:21:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764872498; cv=none; b=Hqwu7p0gmOqPOwKbfx2n0fUiXqsMECcdPTU7nDgronr1xt6Y5mLMoZfVZDDl4HWWhpPwHIi68Tg8gB8sevvgnbNHucwDdg+mFPtidvjtkp9pTVrwaf459QqEsZ149jAIm7a/lL12zXteOhKmEARB/xQW4447ML3QV6Muwmjwg6A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764872498; c=relaxed/simple; bh=qXK4lVZdMwCgMQa59PFr2Cz3cQJN74HoY3VDwQdfNlA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lQBaNDThwRRoZloLpcd3XSDf+fd8T8NHXUed6N5FYDKNF/hasx71cfoj+WChutbeJOU97T6ISDBYVcdBmaVCB1xkNWrXYj9G5gmFS1VBrH+yzbLKF8kdZ+Nx0/qNUcgQOCtf7W7rXeyisoNdlzuGV1sLkrMWteszSKCg12LnS6E= 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=kKJDvS7u; arc=none smtp.client-ip=209.85.221.50 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="kKJDvS7u" Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-42b2de74838so79925f8f.2 for ; Thu, 04 Dec 2025 10:21:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764872495; x=1765477295; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=fv8P+6IVWvIL0bC+f9n0QNbXSqmfD+me3uZoZ0RY/2g=; b=kKJDvS7uEgx0mulgRjPSlFmNt5psY8+La9zRSAcibC4/PyUrswchIo7kXLy0YqtXK5 Zl5Ix3XShzqnkBCtNf9GjAomS37L5EFnReN4AyGaEEJMt4CQq4H/TX8HmHHFzJQdxpX4 0dLhZiwuYXb8aEEqRS/k2m711jS2s3l7IOzugbgS9Luv/xv+2YBWzArvzdR6Pn0YvIcU KT5ch44suXiGKHjhetNGIwE0AGijF1srnb/Ztl8Ko4+snDZn03qkItieuWKvQQreT+Zm IsTy6fHabrRKWt54xy09MR62Wum+b21gjxWKL28rx7C6O+Mmrw+6L4VwMJtXucuot1Pr AzwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764872495; x=1765477295; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fv8P+6IVWvIL0bC+f9n0QNbXSqmfD+me3uZoZ0RY/2g=; b=WAOJZZzamYy/Ntb80v8yjYCQbowJXrJ7MA4a4spngWOhxiO9Ah2gfckLmKpeEbIVrW 38WyHJhcYTKv4qvxg04qUxlvekHredxeSUw+VlPF2OBLxqcPU3xWDg894muuROQTy1+4 MpRwlPGE9rp7fua6M84cfhFMTouHffPZFuc2Fb8KKpSLM0opj+n6h79FvgSPjqIzjbbI NOat4Qxjg/z2xZOaZ9N/Ht+BFSmO5D2fnfBX4fgO04EKgOboCJkLGLiGzIObKUJkE8Mu txRh3XDal3gmjilsV7yOb+rhVGi0D9w0KOjnP1E3UV+7CCzV2vqhj0D4XDbiTq91DUxt vyOQ== X-Forwarded-Encrypted: i=1; AJvYcCV7GPDakiS1/Wcf4EaoppVHz4u/rRW3g4TUwnUMS2wvMCDOKQL/WZlCZhGRUi2d6N1JFDa1J85NYFxTt44=@vger.kernel.org X-Gm-Message-State: AOJu0Yx78+s1OlCBsFYE/OpPHzwMYvZLN/+UyAThfh4Os0XiehZxC4cE IHZhe0LFuM/FPq+SehBoF5sKFtZIFafrPdw1E3ld89chkl6AZb5x9RZL X-Gm-Gg: ASbGncuX6bQzY2TzHlUVpeZULsxwT78S3YxCTMmijYd/SkLZy2LHxyuzQIEbE3HVo3S FoOXu6IT0EwwAS/IJq15wx3DnHw86zL6YqDEQ6Qs2HOej4kEFBVJBc4mvnkKs4Gbg0UdPakl7ch Wtau+IgWf13f2QJUUbaTQ6e716t1rGe4xP+2gf7Kw6EsPWH0BT+DAi5jxjyxJELNdfJrPlovP7+ BZghN6VfFDWv/adB6vrDu1a2nFxrpnROaC8C/jJ/d0swdBprbustZcuaWMs0DZ6zqJDs6HPwZY7 cewbEOCfB2EAtuezUzQQjTAM/yanV0HPrUUoA3BfkmIIEEgLdqy1HyUjQ6IM78rdgbbjCAWZezS +S9r5kEOaU299naYHr7OYWdRFrfpH4h5vIm7drOBznun5fodrwx/QzusjCcKObOFiobAhmyG/M/ AWqSs= X-Google-Smtp-Source: AGHT+IEzgG4TzCJXxABGuutxcIrI+o/G6IuaOtE2bigp/vNM2WwpcI6tNhb5bLyGJf4XeLf7rYmrFA== X-Received: by 2002:a05:600c:8b42:b0:46f:ab96:58e9 with SMTP id 5b1f17b1804b1-4792ae634e8mr38393335e9.0.1764872494836; Thu, 04 Dec 2025 10:21:34 -0800 (PST) Received: from skbuf ([2a02:2f04:d106:d600:dbb2:245d:2cf5:21d3]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-479308cd87csm45669115e9.0.2025.12.04.10.21.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Dec 2025 10:21:34 -0800 (PST) Date: Thu, 4 Dec 2025 20:21:31 +0200 From: Vladimir Oltean To: "Russell King (Oracle)" Cc: Krzysztof Kozlowski , Daniel Golle , Frank Wunderlich , Andrew Lunn , Chen Minqiang , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Matthias Brugger , AngeloGioacchino Del Regno , "Chester A. Unal" , DENG Qingfang , Sean Wang , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, netdev@vger.kernel.org Subject: Re: [PATCH v3 2/2] net: dsa: mt7530: Use GPIO polarity to generate correct reset sequence Message-ID: <20251204182131.gfqwy566gjzd7dbx@skbuf> References: <0d85e1e6-ea75-4f20-aef1-90d446b4bfa1@kernel.org> <00f308a1-a4b1-4f20-8d8e-459ddf4c39b1@gmx.de> <20251204131626.upw77jncqfwxydww@skbuf> <4170c560-1edd-4ff8-96af-a479063be4a5@kernel.org> <20251204160247.yz42mnxvzhxas5jc@skbuf> <66d080f1-e989-451f-9d5e-34460e5eb1b0@kernel.org> <20251204171159.yy3nkvzttxecmhfo@skbuf> <178afbeb-168f-4765-bb0b-fad0bcd29382@kernel.org> 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: On Thu, Dec 04, 2025 at 05:45:30PM +0000, Russell King (Oracle) wrote: > It would make sense if a single GPIO pin is used for resetting > several devices, some of them with an active-high reset input and > others with active-low. > > What matters for a GPIO pin used to source a reset signal is "what > is the active level at the GPIO pin for the reset to be asserted to > the connected device(s)." > > If we have a device that requires an active-low reset input, but there > is some form of inversion in the path to that input from a GPIO, then > the GPIO _should_ be marked active-high. If the same active-low reset > input is connected directly to a GPIO, the GPIO _should_ be marked as > active-low. Thus, to assert reset, writing '1' through > gpiod_set_value() _should_ assert the reset input on the target device > in both cases. > > This is why gpiolib supports software inversion - so software engineers > can think in terms of positive non-inverted logic when programming > GPIOs. Thanks for this message, to me it brought new info which I didn't consider before, which is that if there are *future* boards where some sort of inversion on the reset signal (likely due to it being shared as you say), they should be described as GPIO_ACTIVE_HIGH, but this patch locks us out of that possibility. If I may bring one more data point into the discussion: the switch binding specifically requests not to describe shared reset lines (because unrelated drivers might reset the switch after it probed): reset-gpios: description: | GPIO to reset the switch. Use this if mediatek,mcm is not used. This property is optional because some boards share the reset line with other components which makes it impossible to probe the switch if the reset line is used. so I guess that the probability for a reset signal inversion, even if it exists, to cause problems in the GPIO_ACTIVE_HIGH reinterpretation, is still low, albeit for a completely different reason than the one I initially claimed (which is bogus and Krzysztof was right to challenge it). > Sadly, we keep having people mark active-low signals as "active high" > in DT, and then have to write '0' to assert the signal. These people > basically don't understand electronics and/or our GPIO model. This is the case we seem to be in. On a scale of safety, having quirks for the affected device trees still ranks a bit higher, though.