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] [day] [month] [year] [list]

Date:   Mon, 8 Jan 2018 17:51:46 +0100
From:   Jochen Friedrich <jochen@...am.de>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     netdev@...r.kernel.org
Subject: Re: b53 tags on bpi-r1 (bcm53125)

Hi Florian,

Am 04.01.2018 um 05:49 schrieb Florian Fainelli:
> 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

Thanks. That's the best approach for now :-)