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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 17 Feb 2017 22:35:18 +0100 From: Andrew Lunn <andrew@...n.ch> To: Vivien Didelot <vivien.didelot@...oirfairelinux.com> Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org, kernel@...oirfairelinux.com, "David S. Miller" <davem@...emloft.net>, Florian Fainelli <f.fainelli@...il.com> Subject: Re: [PATCH net-next v2 2/6] net: dsa: mv88e6xxx: move ATU code in its own file On Fri, Feb 17, 2017 at 10:05:27AM -0500, Vivien Didelot wrote: > Move the Global (1) ATU related code in its own file, and export the > necessary primitives. > > Use that opportunity to provide a cleaner API for the ATU, by renaming a > few underscore prefixed functions, and members of the > mv88e6xxx_atu_entry structures. > static int mv88e6xxx_port_db_load_purge(struct mv88e6xxx_chip *chip, int port, > const unsigned char *addr, u16 vid, > u8 state) > { > + struct mv88e6xxx_atu_entry entry = { 0 }; > struct mv88e6xxx_vtu_entry vlan; > - struct mv88e6xxx_atu_entry entry; > int err; > > /* Null VLAN ID corresponds to the port private database */ > @@ -2107,21 +1918,32 @@ static int mv88e6xxx_port_db_load_purge(struct mv88e6xxx_chip *chip, int port, > if (err) > return err; > > - err = mv88e6xxx_atu_get(chip, vlan.fid, addr, &entry); > + entry.fid = vlan.fid; > + ether_addr_copy(entry.mac, addr); > + eth_addr_dec(entry.mac); > + err = mv88e6xxx_atu_getnext(chip, &entry); > if (err) > return err; > > + /* Initialize a fresh ATU entry if it isn't found */ > + if (entry.state == GLOBAL_ATU_DATA_STATE_UNUSED || > + !ether_addr_equal(entry.mac, addr)) { > + memset(&entry, 0, sizeof(entry)); > + ether_addr_copy(entry.mac, addr); > + entry.fid = vlan.fid; > + } > + This seems to be more than renaming a few functions. There looks to be real changes here. I think these changes should be split out into a separate patch with an explanation what is being changed. Keep this patch for plain renames. It would also be easier to review if the patch just moved the code, no changes. Then have patches which clean up the API. It is hard to see what is move and what is cleanup. Plain move needs little review, cleanup needs more review. With the current patch, it is hard to see which is which. Andrew
Powered by blists - more mailing lists