netdev - Re: [PATCH iwl-next v1 2/3] ice: refactor ice_sbq_msg

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: <20250225150807.GB1615191@kernel.org>
Date: Tue, 25 Feb 2025 15:08:07 +0000
From: Simon Horman <horms@...nel.org>
To: Grzegorz Nitka <grzegorz.nitka@...el.com>
Cc: intel-wired-lan@...ts.osuosl.org, netdev@...r.kernel.org,
	Karol Kolacinski <karol.kolacinski@...el.com>,
	Przemek Kitszel <przemyslaw.kitszel@...el.com>
Subject: Re: [PATCH iwl-next v1 2/3] ice: refactor ice_sbq_msg_dev enum

On Fri, Feb 21, 2025 at 01:31:22PM +0100, Grzegorz Nitka wrote:
> From: Karol Kolacinski <karol.kolacinski@...el.com>
> 
> Rename ice_sbq_msg_dev to ice_sbq_dev_id to reflect the meaning of this
> type more precisely. This enum type describes RDA (Remote Device Access)
> client ids, accessible over SB (Side Band) interface.
> Rename enum elements to make a driver namespace more cleaner and
> consistent with other definitions within SB
> Remove unused 'rmn_x' entries, specific to unsupported E824 device.
> Adjust clients '2' and '13' names (phy_0 and phy_0_peer respectively) to
> be compliant with EAS doc. According to the specification, regardless of
> the complex entity (single or dual), when accessing its own ports,
> they're accessed always as 'phy_0' client. And referred as 'phy_0_peer'
> when handling ports conneced to the other complex.
> 
> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@...el.com>
> Signed-off-by: Karol Kolacinski <karol.kolacinski@...el.com>
> Co-developed-by: Grzegorz Nitka <grzegorz.nitka@...el.com>
> Signed-off-by: Grzegorz Nitka <grzegorz.nitka@...el.com>

Reviewed-by: Simon Horman <horms@...nel.org>