linux-kernel - Re: [PATCH 0/18] net: dsa: HW bridging, EEE support

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:	Sat, 21 Mar 2015 16:12:30 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	David Miller <davem@...emloft.net>
CC:	netdev@...r.kernel.org, andrew@...n.ch, f.fainelli@...il.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/18] net: dsa: HW bridging, EEE support

On 03/21/2015 03:48 PM, David Miller wrote:
> From: Guenter Roeck <linux@...ck-us.net>
> Date: Sat, 21 Mar 2015 08:46:37 -0700
>
>> Patch 1 to 7 of this series prepare the drivers using the mv88e6xxx code
>> for HW bridging support, without adding the code itself. For the most part
>> this factors out common port initialization code. There is no functional
>> change except for patch 3, which disables the message port bit for the
>> CPU port to prevent packet duplication if HW bridging is configured.
>>
>> Patch 8 adds the infrastructure for hardware bridging support to the
>> mv88e6xxx code.
>>
>> Patch 9 wires the MV88E6352 driver to support hardware bridging.
>>
>> Patches 10 to 12 add support for ndo_fdb functions to the dsa subsystem, and
>> wire up the MV88E6352 driver to support those functions.
>>
>> Patches 13 to 16 add EEE support and HW bridging support to the mv88e6171
>> driver. This set of patches is from Andrew, applied on top of the first
>> set of patches.
>>
>> Patch 17 and 18 add HW bridging support to the mv88e6131 driver. This code
>> is untested and therefore marked RFT.
>>
>> The series applies to net-next as of 3/20/2015.
>>
>> Thanks a lot to Andrew Lunn for testing and valuable feedback.
>
> Generally this series looks good.
>
> But this driver would be so much easier to read and understand if it
> used mnemonics instead of constants for the register offsets.
>

Yes, agreed. It is on the to-do list. Should we be more aggressive ?
Since I'll have to resubmit anyway, we could start by adding defines
for all constants used in this patch set, not just some of them.

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/