lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <66d080f1-e989-451f-9d5e-34460e5eb1b0@kernel.org>
Date: Thu, 4 Dec 2025 17:48:07 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Daniel Golle <daniel@...rotopia.org>, Frank Wunderlich <frankwu@....de>,
 Andrew Lunn <andrew@...n.ch>, Chen Minqiang <ptpt52@...il.com>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Matthias Brugger
 <matthias.bgg@...il.com>,
 AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 "Chester A. Unal" <chester.a.unal@...nc9.com>,
 DENG Qingfang <dqfext@...il.com>, Sean Wang <sean.wang@...iatek.com>,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-mediatek@...ts.infradead.org, netdev@...r.kernel.org
Subject: Re: [PATCH v3 2/2] net: dsa: mt7530: Use GPIO polarity to generate
 correct reset sequence

On 04/12/2025 17:02, Vladimir Oltean wrote:
> On Thu, Dec 04, 2025 at 03:49:52PM +0100, Krzysztof Kozlowski wrote:
>> On 04/12/2025 14:16, Vladimir Oltean wrote:
>>> I get the feeling that we're complicating a simple solution because of a
>>> theoretical "what if" scenario. The "NOT" gate is somewhat contrived
>>
>> You downplay this case and suggest (if I get it right) that NOT gate is
>> something unusual.
>>
>>  I mentioned "line inverter" but it's not about NOT gate. There is no
>> need for NOT gate at all, like some magical component which no one puts
>> to the board. The only thing needed is just to pull the GPIO up or down,
>> that's it. It's completely normal design thus it CAN happen.
>>
>> Of course "can" does not mean it actually does, because certain
>> configurations like powerdown-fail-safe are more likely and I am not an
>> electric circuit designer to tell which one is better, but that
>> downplaying does not help here.
> 
> I don't want to dismiss this comment, but I don't really understand it.
> What do you mean by "line inverter", is it the component inside the GPIO
> pin which makes it active low?

I mentioned much earlier "line inverter" and here the "NOT gate"
appeared and both suggest you need some dedicated component.

What I want to say that it is not true. You do not need dedicated
component to have different polarity, because it is as simple as
connecting the wire to ground or to voltage and moving a resistor from
one place to another.

> 
> I thought that the premise of this patch set is that old device trees
> are all (incorrectly) defined as GPIO_ACTIVE_HIGH, but someone familiar
> with the matter needs to fact-check this statement.

Yes, that's most likely true.

> 
> Anyway, you and Andrew are talking about different things, you haven't
> made it clear (or at least it wasn't clear to me) that the inverter you
> are talking about isn't his NOT gate (that isn't described in the device
> tree at all, as opposed to your inverter which would make the GPIO line
> GPIO_ACTIVE_LOW - that's something verifiable).

Both are the same - inverter or NOT gate, same stuff. It is just
connecting wire to pull up, not actual component on the board (although
one could make and buy such component as well...). We never describe
these inverters in the DTS, these are just too trivial circuits, thus
the final GPIO_ACTIVE_XXX should already include whatever is on the wire
between SoC and device.

> 
>> Just to clarify: I expect clear communication that some users will be
>> broken with as good as you can provide analysis of the impact (which
>> users). I only object the clame here "no one can ever pull down a GPIO
>> line thus I handled all possible cases and made it backward compatible".
>>
>> And that claim to quote was:
>> "Therefore, regardless of whether a DTS is old or new, correct or
>> incorrect, the driver now generates the correct electrical reset pulse."
>>
>> which is 100% false and I am surprised how one could claim that.
> 
> Agree, the communication should be better.


Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ