netdev - Re: [PATCH net-next] sh_eth: TSU_QTAG0/1 registers the same as TSU

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: <6de5c988-df74-2ca5-c3bb-b2979943b85d@cogentembedded.com>
Date:   Sun, 25 Feb 2018 17:27:36 +0300
From:   Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>
Subject: Re: [PATCH net-next] sh_eth: TSU_QTAG0/1 registers the same as
 TSU_QTAGM0/1

On 02/25/2018 04:14 PM, Geert Uytterhoeven wrote:

>> The TSU_QTAG0/1 registers found in the Gigabit Ether controllers actually
>> have the same long name  as the TSU_QTAGM0/1 registers in the early Ether
>> controllers:  Qtag Addition/Deletion Set Register (Port 0/1 to 1/0); thus
>> there's no need to make a difference in sh_eth_tsu_init() between those
>> controllers. Unfortunately, we can't just remove TSU_QTAG0/1 from the
>> register *enum* because that would break the ethtool register dump...
>>
>> Fixes: b0ca2a21f769 ("sh_eth: Add support of SH7763 to sh_eth")
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
> 
> Thanks for your patch!
> 
>> --- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
>> +++ net-next/drivers/net/ethernet/renesas/sh_eth.c
> 
>> @@ -2097,8 +2097,6 @@ static size_t __sh_eth_get_regs(struct n
>>                 add_tsu_reg(TSU_FWSL0);
>>                 add_tsu_reg(TSU_FWSL1);
>>                 add_tsu_reg(TSU_FWSLC);
>> -               add_tsu_reg(TSU_QTAG0);
>> -               add_tsu_reg(TSU_QTAG1);
> 
> Shouldn't you keep the above for ethtool register dump?

   Why dump the same registers twice? These are no longer marked as valid in the dump
buffer and a dump user's only source of info about the valid registers is the bitmap
at the start of the buffer...
   Note that the dump is only done for the registers actually used by the driver, and
these 2 regs are no longer used anywhere...

>>                 add_tsu_reg(TSU_QTAGM0);
>>                 add_tsu_reg(TSU_QTAGM1);
>>                 add_tsu_reg(TSU_FWSR);

MBR, Sergei