netdev - Re: [PATCH net-next 2/2] dt-bindings: net: dsa: realtek: add reset controller

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: <CAJq09z68_PKisypGjg=TvvNYXY5PhLTQqqoj5gA+GW2H=mKK3A@mail.gmail.com>
Date: Thu, 26 Oct 2023 17:09:12 -0300
From: Luiz Angelo Daros de Luca <luizluca@...il.com>
To: Arınç ÜNAL <arinc.unal@...nc9.com>
Cc: netdev@...r.kernel.org, linus.walleij@...aro.org, alsi@...g-olufsen.dk, 
	andrew@...n.ch, vivien.didelot@...il.com, f.fainelli@...il.com, 
	olteanv@...il.com, davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com, 
	robh+dt@...nel.org, krzk+dt@...nel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH net-next 2/2] dt-bindings: net: dsa: realtek: add reset controller

> On 24.10.2023 23:58, Luiz Angelo Daros de Luca wrote:
> > Realtek switches can now be reset using a reset controller.
>
> The switch could always be reset using a reset controller. The fact that
> the Linux driver lacked the ability to do so is irrelevant here. The
> abilities or the features of the hardware had never changed. You should get
> rid of the "now" above.

Yes, I need to avoid thinking about where it will be used.

> > The 'reset-gpios' were never mandatory for the driver, although they
> > are required for some devices if the switch reset was left asserted by
> > a previous driver, such as the bootloader.
>
> dt-bindings are for documenting hardware. The Linux driver details are
> irrelevant here. Also, from what I read above, I deduce that for the switch
> to be properly controlled in all possible states that it would be found in,
> the switch must be reset.

I don't believe the switch must be reset by the HW. It will only be
necessary if the reset was kept asserted by the previous driver or its
initial state. And even in that case, we would only need to deassert
the reset, not assert it.
The driver will sw reset the switch during setup, leaving it in a
pristine state.

This is the current code flow:

realtek-smi/mdio probe()
   HW reset assert
   sleep
   HW reset deassert
   sleep
   rtl8365mb/rtl8366rb detect()
      SW reset

In fact, if we could make sure the hw reset was actually performed,
like checking a switch uptime register, we could avoid resetting it
again.

If you must not consider how the driver was implemented, I must assume
that an advanced driver might be able to configure every aspect of the
switch without a reset. Reset is the easiest solution but I believe
there is a narrow window between the reset and the switch is properly
configured where the switch might act like a dump switch, forwarding
some packets to all ports and possibly leaking traffic.

> So instead of above I'd say:
>
> Resetting the switch is mandatory. Resetting the switch with reset-gpios is
> not mandatory. Therefore require one of reset-gpios or resets and
> reset-names.
>
> For dt-bindings changes, I'd remove reset-gpios from else of
> if:required:reg as you already do with this patch, and add below to the
> root of the schema.
>
> oneOf:
>    - required:
>      - reset-gpios
>    - required:
>      - resets
>      - reset-names

As I said, I don't believe a way to HW reset is mandatory.

> And, like Vladimir said, this should be a separate patch.

OK. I'm just waiting some days for a v2.

>
> Also, please put the dt-bindings patches first in the patch series order.

OK

>
> Arınç

Regards,

Luiz