netdev - Re: [RFC PATCH v2 2/8] net: sparx5: add the basic sparx5 driver

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 23 Dec 2020 10:03:11 +0100
From:   Lars Povlsen <lars.povlsen@...rochip.com>
To:     Alexandre Belloni <alexandre.belloni@...tlin.com>
CC:     Andrew Lunn <andrew@...n.ch>,
        Steen Hegelund <steen.hegelund@...rochip.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Russell King <linux@...linux.org.uk>,
        "Lars Povlsen" <lars.povlsen@...rochip.com>,
        Bjarni Jonasson <bjarni.jonasson@...rochip.com>,
        Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>,
        Madalin Bucur <madalin.bucur@....nxp.com>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>,
        Mark Einon <mark.einon@...il.com>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Arnd Bergmann <arnd@...db.de>, <netdev@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC PATCH v2 2/8] net: sparx5: add the basic sparx5 driver


Alexandre Belloni writes:

> On 22/12/2020 16:01:22+0100, Andrew Lunn wrote:
>> > The problem is that the switch core reset also affects (reset) the
>> > SGPIO controller.
>> >
>> > We tried to put this in the reset driver, but it was rejected. If the
>> > reset is done at probe time, the SGPIO driver may already have
>> > initialized state.
>> >
>> > The switch core reset will then reset all SGPIO registers.
>>
>> Ah, O.K. Dumb question. Why is the SGPIO driver a separate driver? It
>> sounds like it should be embedded inside this driver if it is sharing
>> hardware.
>>
>> Another option would be to look at the reset subsystem, and have this
>> driver export a reset controller, which the SGPIO driver can bind to.
>> Given that the GPIO driver has been merged, if this will work, it is
>> probably a better solution.
>>
>
> That was my suggestion. Then you can ensure from the reset controller
> driver that this is done exactly once, either from the sgpio driver or
> from the switchdev driver. IIRC, the sgpio from the other SoCs are not
> affected by the reset.

I will take a look to see if we can change the implementation to use a
reset controller.

---Lars

--
Lars Povlsen,
Microchip