linux-kernel - Re: [PATCH] MIPS: pci: lantiq: restore reset gpio polarity

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]

Date: Thu, 13 Jun 2024 22:06:06 +0200
From: Hauke Mehrtens <hauke@...ke-m.de>
To: Martin Schiller <ms@....tdt.de>,
 Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc: tsbogend@...ha.franken.de, rdunlap@...radead.org, robh@...nel.org,
 bhelgaas@...gle.com, linux-mips@...r.kernel.org,
 linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] MIPS: pci: lantiq: restore reset gpio polarity

On 6/12/24 21:47, Martin Schiller wrote:
> On 2024-06-12 20:39, Martin Schiller wrote:
>> On 2024-06-12 19:47, Dmitry Torokhov wrote:
>>> Hi Marton,
>>
>> Hi Dmitry,
>>
>>>
>>> On Fri, Jun 07, 2024 at 11:04:00AM +0200, Martin Schiller wrote:
>>>> Commit 90c2d2eb7ab5 ("MIPS: pci: lantiq: switch to using gpiod API") 
>>>> not
>>>> only switched to the gpiod API, but also inverted / changed the 
>>>> polarity
>>>> of the GPIO.
>>>>
>>>> According to the PCI specification, the RST# pin is an active-low
>>>> signal. However, most of the device trees that have been widely used 
>>>> for
>>>> a long time (mainly in the openWrt project) define this GPIO as
>>>> active-high and the old driver code inverted the signal internally.
>>>>
>>>> Apparently there are actually boards where the reset gpio must be
>>>> operated inverted. For this reason, we cannot use the 
>>>> GPIOD_OUT_LOW/HIGH
>>>> flag for initialization. Instead, we must explicitly set the gpio to
>>>> value 1 in order to take into account any "GPIO_ACTIVE_LOW" flag that
>>>> may have been set.
>>>
>>> Do you have example of such boards? They could not have worked before
>>> 90c2d2eb7ab5 because it was actively setting the reset line to physical
>>> high, which should leave the device in reset state if there is an
>>> inverter between the AP and the device.
>>
>> Oh, you're right. I totally missed that '__gpio_set_value' was used in
>> the original code and that raw accesses took place without paying
>> attention to the GPIO_ACTIVE_* flags.
>>
>> You can find the device trees I am talking about in [1].
>>
>> @Thomas Bogendoerfer:
>> Would it be possible to stop the merging of this patch?
>> I think We have to do do some further/other changes.
>>
>>>
>>>>
>>>> In order to remain compatible with all these existing device trees, we
>>>> should therefore keep the logic as it was before the commit.
>>>
>>> With gpiod API operating with logical states there's still difference in
>>> logic:
>>>
>>>     gpiod_set_value_cansleep(reset_gpio, 1);
>>>
>>> will leave GPIO at 1 if it is described as GPIO_ACTIVE_HIGH (which is
>>> apparently what you want for boards with broken DTS) but for boards
>>> that accurately describe GPIO as GPIO_ACTIVE_LOW it well drive GPIO to
>>> 0, leaving the card in reset state.
>>>
>>> You should either use gpiod_set_raw_value_calsleep() or we can try and
>>> quirk it in gpiolib (like we do for many other cases of incorrect GPIO
>>> polarity descriptions and which is my preference).
> 
> So you mean we should add an entry for "lantiq,pci-xway" to the
> of_gpio_try_fixup_polarity()?
> Do you know any dts / device outside the openWrt universe which is using
> this driver.
> 
> For the lantiq targets in openWrt, the devicetree blob is appended to
> the kernel image and therefore also updated when doing a firmware
> upgrade. So, maybe it would also be an option to fix the driver (using
> GPIO_ACTIVE_* flag for the initial level and set it to 0 -> 1 -> 0) and
> rework all the dts files to use GPIO_ACTIVE_LOW.
> 
> Then we won't need any quirks.

I am not aware that anyone is using a recent kernel on the VRX200 
outside of OpenWrt. I am also not aware that anyone is *not* appending 
the DTB to the kernel. The SoC is pretty old now, the successor of this 
SoC was released about 10 years ago.

For me it would be fine if you fix the broken device device trees 
shipped with the upstream kernel and with OpenWrt to make them work with 
the PCI driver instead of investing too much time into handling old DTBs.

The PCI reset is inverted on some boards to handle a dying gasp. If the 
power breaks down the reset should get triggered and the PCIe device can 
send a dying gasp signal to the other side. This is done on the 
reference designs of some Lantiq PCIe DSL card for the VRX318 and 
probably also some other components.

Hauke