From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-03.galae.net (smtpout-03.galae.net [185.246.85.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D50F7345CAB for ; Fri, 16 Jan 2026 07:08:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.85.4 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768547340; cv=none; b=h+cwzHTtQ4BVzToR8x46/yMgP7mZacK0V2uoVzo1MgTALzvN/das/g8VV9T7hZoMN+0p2T8dXsv6cMeQMmZGnwtiUosYpx9SrPA+K4kh+A6OJg+RGgT1ZyvhnUzxuKZceTMZl9D/WO+RF5BcvfgFKoWp+7W5IfX+3GGurE8WpgY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768547340; c=relaxed/simple; bh=GUgRfny8ILBolkzrIObt84Gwn9WtU+PYmdPIsybZBPc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=d3P8a5db16oiq6+6hHoBn2hUgeDa0+jmk8/6zA3N2wSPcFtpb8QF9hgTA5qHIkuRcYuiv1TBBjE5M2jdItsdMv5+h5csxEYl7knJtdiMC0OnSazEI2CuV7RSBE7Da/Vt4owyY7OKJp0z9zBjHIcYW5BEc7Jaq6cOGYY01DDRH1A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=eRCQvuAf; arc=none smtp.client-ip=185.246.85.4 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="eRCQvuAf" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-03.galae.net (Postfix) with ESMTPS id 348984E4210D; Fri, 16 Jan 2026 07:08:56 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id CE63960732; Fri, 16 Jan 2026 07:08:55 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 7B91610B68919; Fri, 16 Jan 2026 08:08:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1768547334; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:content-language:in-reply-to:references; bh=7X4iGHOpoO4GX15j7st3JUnO9pqAPsNSvmrMO+kwytg=; b=eRCQvuAfVs4WgEaFm98M6B6lq46VFaDSSJV93xTdctTsEeTEKzvxP2UinsUVkZKDKWs+wH fjIe/w+h6WEA8T7Yg2tREEIN03yJ7sXapAmCVfo27raDDNUgbAQxnV/b+GViSo5o+k2Vy/ fwCHOEFlg6y70bDYVx1TgDx3jeIO7VFa+bpzJVNxa/0rQ3gxFAAThYaxiKPv8FlacIJgnp TILGIDsqzC4Kgo2UahLjpFZ+7Nc8Fq0C49A1lwR17zPhezrSz97KjCpZ4eY3AZ1UwEHehl QhwgEWviJ14cOMTdtW2F5AWCUusiTroT/iNGz1nBx5R303qDbkKRVdjPYErTPQ== Message-ID: Date: Fri, 16 Jan 2026 08:08:48 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next 5/8] net: dsa: microchip: Add KSZ8463 tail tag handling To: Maxime Chevallier , Woojung Huh , UNGLinuxDriver@microchip.com, Andrew Lunn , Vladimir Oltean , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Richard Cochran , Simon Horman Cc: Pascal Eberhard , =?UTF-8?Q?Miqu=C3=A8l_Raynal?= , Thomas Petazzoni , netdev@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260115-ksz8463-ptp-v1-0-bcfe2830cf50@bootlin.com> <20260115-ksz8463-ptp-v1-5-bcfe2830cf50@bootlin.com> <722dcba9-d9ae-43ba-b1bf-1d577a882bef@bootlin.com> From: Bastien Curutchet Content-Language: en-US In-Reply-To: <722dcba9-d9ae-43ba-b1bf-1d577a882bef@bootlin.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Last-TLS-Session-Version: TLSv1.3 Hi Maxime, On 1/15/26 6:05 PM, Maxime Chevallier wrote: > Hi Bastien, > > On 15/01/2026 16:57, Bastien Curutchet (Schneider Electric) wrote: >> KSZ8463 uses the KSZ9893 DSA TAG driver. However, the KSZ8463 doesn't >> use the tail tag to convey timestamps to the host as KSZ9893 does. It >> uses the reserved fields in the PTP header instead. > > [ ... ] > >> +static struct sk_buff *ksz8463_rcv(struct sk_buff *skb, struct net_device *dev) >> +{ >> + unsigned int len = KSZ_EGRESS_TAG_LEN; >> + struct ptp_header *ptp_hdr; >> + unsigned int ptp_class; >> + unsigned int port; >> + ktime_t tstamp; >> + u8 *tag; >> + >> + if (skb_linearize(skb)) >> + return NULL; >> + >> + /* Tag decoding */ >> + tag = skb_tail_pointer(skb) - KSZ_EGRESS_TAG_LEN; >> + port = tag[0] & KSZ8463_TAIL_TAG_EG_PORT_M; >> + >> + __skb_push(skb, ETH_HLEN); >> + ptp_class = ptp_classify_raw(skb); >> + __skb_pull(skb, ETH_HLEN); >> + if (ptp_class == PTP_CLASS_NONE) >> + goto common_rcv; >> + >> + ptp_hdr = ptp_parse_header(skb, ptp_class); >> + if (ptp_hdr) { >> + tstamp = ksz_decode_tstamp(get_unaligned_be32(&ptp_hdr->reserved2)); >> + KSZ_SKB_CB(skb)->tstamp = tstamp; > > As it is using a reserved field, is it OK to leave this field as-is when forwarding > this skb to userspace, or should it be zeroed first ? > It doesn't seem to hurt, at least on my test setup (I'm using ptp4l in userspace btw), but I agree with you: it feels safer to zero it first. I'll do it in next iteration. Best regards, Bastien