linux-kernel - Re: [PATCH net-next v3 0/3] net: ptp: introduce common defines for PTP message types

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 21 Nov 2020 00:39:10 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Christian Eggers <ceggers@...i.de>
Cc:     Richard Cochran <richardcochran@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Russell King <linux@...linux.org.uk>,
        "David S . Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v3 0/3] net: ptp: introduce common defines for
 PTP message types

On Fri, Nov 20, 2020 at 09:41:03AM +0100, Christian Eggers wrote:
> This series introduces commen defines for PTP event messages. Driver
> internal defines are removed and some uses of magic numbers are replaced
> by the new defines.
> 
> Changes v2 --> v3
> ------------------
> - extend commit description for ptp_ines (Jacob Keller)
> 
> Changes v1 --> v2
> ------------------
> - use defines instead of an enum (Richard Cochran)
> - no changes necessary for dp63640
> - add cover message (Vladimir Oltean)

I understand that you don't want to spend a lifetime on this, but I see
that there are more drivers which you did not touch.

is_sync() in drivers/net/phy/dp83640.c can be made to
	return ptp_get_msgtype(hdr, type) == PTP_MSGTYPE_SYNC;

this can be removed from drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.h:
enum {
	MLXSW_SP_PTP_MESSAGE_TYPE_SYNC,
	MLXSW_SP_PTP_MESSAGE_TYPE_DELAY_REQ,
	MLXSW_SP_PTP_MESSAGE_TYPE_PDELAY_REQ,
	MLXSW_SP_PTP_MESSAGE_TYPE_PDELAY_RESP,
};

Either way, this can also be applied as-is, since there's nothing wrong
with it.