netdev - Re: [PATCH v2 1/2] net: ethernet: bgmac: init sequence bug

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]

Date:   Fri, 3 Feb 2017 17:34:48 -0500
From:   Jon Mason <jon.mason@...adcom.com>
To:     Rafał Miłecki <rafal@...ecki.pl>
Cc:     David Miller <davem@...emloft.net>,
        BCM Kernel Feedback <bcm-kernel-feedback-list@...adcom.com>,
        Network Development <netdev@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        Zac Schroff <zschroff@...adcom.com>
Subject: Re: [PATCH v2 1/2] net: ethernet: bgmac: init sequence bug

On Fri, Feb 3, 2017 at 4:41 PM, Rafał Miłecki <rafal@...ecki.pl> wrote:
> On 02/03/2017 10:08 PM, Jon Mason wrote:
>>
>> @@ -61,15 +60,20 @@ static bool platform_bgmac_clk_enabled(struct bgmac
>> *bgmac)
>>
>>  static void platform_bgmac_clk_enable(struct bgmac *bgmac, u32 flags)
>>  {
>> -       bgmac_idm_write(bgmac, BCMA_IOCTL,
>> -                       (BCMA_IOCTL_CLK | BCMA_IOCTL_FGC | flags));
>> +       u32 val;
>> +
>> +       val = bgmac_idm_read(bgmac, BCMA_IOCTL);
>> +       /* Some bits of BCMA_IOCTL set by HW/ATF and should not change */
>> +       val |= flags & ~(BGMAC_AWCACHE | BGMAC_ARCACHE | BGMAC_AWUSER |
>> +                        BGMAC_ARUSER);
>> +       val |= BGMAC_CLK_EN;
>>         bgmac_idm_read(bgmac, BCMA_IOCTL);
>
>
> This read was previously following write op most likely to flush it or
> something. I don't think it makes any sense to read after read.

Actually, that is sloppy coding on my part.  It should have a write
prior to the read to match what was there before.

I find it odd that it worked when I tested this patch.  It makes me
wonder if this "modify, reset, modify" series is really necessary
after all.  The docs indicate that writing a 0 to the reset brings it
out of reset.  I do not see any code that puts the HW in reset.  So,
unless the bootloader puts the HW in reset or it is in the reset state
by default, this seems like unnecessary code.  I can add some CYA
logic to read and see if it is in reset, toggle the bit, and then just
do the CLK enable.  Thoughts?

Thanks,
Jon