netdev - Re: b53 tags on bpi-r1 (bcm53125)

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: <08f78158-3072-6929-995f-eda622833256@gmail.com>
Date:   Wed, 3 Jan 2018 20:49:26 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Jochen Friedrich <jochen@...am.de>
Cc:     netdev@...r.kernel.org
Subject: Re: b53 tags on bpi-r1 (bcm53125)

On 12/29/2017 07:22 PM, Florian Fainelli wrote:
> Le 12/29/17 à 13:56, Florian Fainelli a écrit :
>> Le 12/29/17 à 12:21, Florian Fainelli a écrit :
>>> Hi Jochen,
>>>
>>> Le 12/18/17 à 02:44, Jochen Friedrich a écrit :
>>>> Hi Florian,
>>>>
>>>> unfortunately, this doesn't make any difference.
>>>>
>>>> Just out of curiosity, BPI-R1 has pull-down resistors on LED6 and 7
>>>> (MII_MODE0/1). However, the public available 53125U sheet doesn't
>>>> document these pins:
>>>>
>>>> LED[6] IMP_MODE[0] Pull-up Active low (since IMP Mode is not used)
>>>> LED[7] IMP_MODE[1] Pull-up Active low (since IMP Mode is not used)
>>>>
>>>> Is this MII mode maybe incompatible with Broadcom tags?
>>>
>>> AFAICT, it should not, this is largely independent from enabling
>>> Broadcom tags.
>>>
>>> I have now reproduced this on my BPI-R1 as well and am looking at what
>>> might be going wrong.
>>
>> OK, so I have been able to find out what was going on. On BCM53125 and
>> earlier switches, we need to do a couple of things for Broadcom tags to
>> be usable:
>>
>> - turn on managed mode (SM_SW_FWD_MODE)
>> - configure Port 8 for IMP mode (B53_GLOBAL_CONFIG, setting bit
>> GC_FRM_MGMT_PORT_MII)
>>
>> After doing that, I can now see the correct outgoing packets on my host,
>> however, the replies don't seem to be delivered to the per-port DSA
>> network devices, and I suspect it's because of stmmac, so I am
>> investigating this now.
>>
> 
> So stmmac was indeed part of the problem. I had to clear the
> GMAC_CONTROL_ACS bit in GMAC_CORE_INIT in order to allow stmmac to
> properly receive packets, otherwise, packets were truncated to 8 bytes
> on reception which I assume is because the Broadcom tags may look like
> some sort of weird LLC/SNAP packet which was confusing the hardware.
> This is all working correctly now after a bunch of changes that I will
> submit in the next few days.
> 
> Preliminary patches available here:
> 
> https://github.com/ffainelli/linux/commits/stmmac-fixes
> 
> Thank you very much for your patience!

Turning on managed mode has some other effects, like how multicast
traffic needs to be handled and how to resolve ARL misses, which means
that the changes are too invasive for the upcoming release since we
would be essentially adding multicast support through a number of code
paths (including core DSA).

I will submit a simple change for now which does not turn on Broadcom
tags on switches that require managed mode (5395, 97, 98, 53125 and
friends) and target enabling Broadcom tags for these models for net-next.

Thanks
-- 
Florian