linux-kernel - Re: [RFC PATCH v2 net-next 0/8] Add support for VSC7511-7514 chips over SPI

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: <20210711163231.GA2219684@euler>
Date:   Sun, 11 Jul 2021 09:32:31 -0700
From:   Colin Foster <colin.foster@...advantage.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     andrew@...n.ch, vivien.didelot@...il.com, f.fainelli@...il.com,
        davem@...emloft.net, kuba@...nel.org, robh+dt@...nel.org,
        claudiu.manoil@....com, alexandre.belloni@...tlin.com,
        UNGLinuxDriver@...rochip.com, linux@...linux.org.uk,
        netdev@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v2 net-next 0/8] Add support for VSC7511-7514 chips
 over SPI

On Sat, Jul 10, 2021 at 10:47:55PM +0300, Vladimir Oltean wrote:
> On Sat, Jul 10, 2021 at 12:25:54PM -0700, Colin Foster wrote:
> > 1. The first probe of the internal MDIO bus fails. I suspect this is related to
> > power supplies / grounding issues that would not appear on standard hardware.
> 
> Where and with what error code does it fail exactly? I don't understand
> the concept of "the first probe"? You mean that there is an
> -EPROBE_DEFER and it tries again immediately afterwards? Or you need to
> unbind and rebind the driver to the device, or what?

My hardware I'm using for test / dev is a bit of a hack. Beaglebone
jumped to a VSC7512 dev board SPI lines after some modifications. 

I believe I'm seeing grounding-related issues as a result of this. For
instance, if I power on the dev board before powering on the Beaglebone,
the BB will be held in reset. The same thing will happen if I reset the
BB when the Microsemi dev board has been powered on, but left
unconfigured.

When I run "modprobe mscc_ocelot_spi" the first time the driver fails to
enumerate swp1-3 with "failed to connect to port X: -19" message. But
after doing that, I can reset the BB to my heart's content. Future boots
will be able to successfully find those at initial mod insertion. And
reloading / rebinding the driver successfully registers the ports at
spi0.0-imdio:0X

> 
> > 2. Communication to the CPU bus doesn't seem to function properly. I suspect
> > this is due to the fact that ocelot / felix assumes it is using the built-in CPU
> > / NPI port for forwarding, though I am not positive.
> 
> What is the CPU bus and what doesn't function properly about it?

I'm still learning a lot about how the chip functions, especially now
that I have attained some functionality from the driver. There's a CPU
bus that can be utilized when you're running internally, and I believe
that can be configured as the NPI bus if you're running through PCIe.
When controlling through SPI I'm not convinced we'll have access to that
bus, and if the Ocelot driver relies on that functionality I've got some
more work in front of me.

> 
> > Nonetheless, these two issues likely won't require a large architecture change,
> > and perhaps those who know much more about the ocelot chips than I could chime
> > in.
> 
> I guess you don't know if that's the case or not until you know what the
> problem is...

True