netdev - Re: [PATCH net-next 1/5] net: dsa: mv88e6xxx: Provide generic VTU iterator

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: <87y2emnmlj.fsf@waldekranz.com>
Date:   Wed, 17 Mar 2021 10:41:44 +0100
From:   Tobias Waldekranz <tobias@...dekranz.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     davem@...emloft.net, kuba@...nel.org, andrew@...n.ch,
        vivien.didelot@...il.com, f.fainelli@...il.com,
        netdev@...r.kernel.org
Subject: Re: [PATCH net-next 1/5] net: dsa: mv88e6xxx: Provide generic VTU iterator

On Tue, Mar 16, 2021 at 10:42, Vladimir Oltean <olteanv@...il.com> wrote:
> On Mon, Mar 15, 2021 at 10:13:56PM +0100, Tobias Waldekranz wrote:
>> @@ -2184,25 +2230,7 @@ static int mv88e6xxx_port_db_dump(struct mv88e6xxx_chip *chip, int port,
>>  	if (err)
>>  		return err;
>>  
>> -	/* Dump VLANs' Filtering Information Databases */
>> -	vlan.vid = mv88e6xxx_max_vid(chip);
>> -	vlan.valid = false;
>> -
>> -	do {
>> -		err = mv88e6xxx_vtu_getnext(chip, &vlan);
>> -		if (err)
>> -			return err;
>> -
>> -		if (!vlan.valid)
>> -			break;
>> -
>> -		err = mv88e6xxx_port_db_dump_fid(chip, vlan.fid, vlan.vid, port,
>> -						 cb, data);
>> -		if (err)
>> -			return err;
>> -	} while (vlan.vid < mv88e6xxx_max_vid(chip));
>> -
>> -	return err;
>> +	return mv88e6xxx_vtu_walk(chip, mv88e6xxx_port_db_dump_vlan, &ctx);
>>  }
>
> Can the mv88e6xxx_port_db_dump_fid(VLAN 0) located above this call be
> covered by the same mv88e6xxx_vtu_walk?

The port's default default FID does not belong to any VLAN, so it is
never loaded in the VTU. That is why it handled separately. So, no :)