All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Cochran <richardcochran@gmail.com>
To: Kurt Kanzenbach <kurt@linutronix.de>
Cc: Vladimir Oltean <olteanv@gmail.com>, Andrew Lunn <andrew@lunn.ch>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	netdev@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
	devicetree@vger.kernel.org,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Kamil Alkhouri <kamil.alkhouri@hs-offenburg.de>,
	ilias.apalodimas@linaro.org
Subject: Re: [PATCH v1 4/8] net: dsa: hellcreek: Add support for hardware timestamping
Date: Mon, 13 Jul 2020 07:01:12 -0700	[thread overview]
Message-ID: <20200713140112.GB27934@hoboy> (raw)
In-Reply-To: <87k0z7n0m9.fsf@kurt>

On Mon, Jul 13, 2020 at 12:57:34PM +0200, Kurt Kanzenbach wrote:
> Hi Vladimir,
> 
> On Mon Jul 13 2020, Vladimir Oltean wrote:
> >> +/* Get a pointer to the PTP header in this skb */
> >> +static u8 *parse_ptp_header(struct sk_buff *skb, unsigned int type)
> >
> > Maybe this and the function from mv88e6xxx could share the same
> > implementation somehow.
> 
> Actually both functions are identical. Should it be moved to the ptp
> core, maybe? Then, all drivers could use that. I guess we should also
> define a PTP offset for the reserved field which is accessed in
> hellcreek_get_reserved_field() just with 16 instead of a proper macro
> constant.

I support re-factoring the code that parses the PTP header.  Last time
I looked, each driver needed slightly different fields, and I didn't
see an easy way to accommodate them all.

> > I would like to get some clarification on whether "SKBTX_IN_PROGRESS"
> > should be set in shtx->tx_flags or not. On one hand, it's asking for
> > trouble, on the other hand, it's kind of required for proper compliance
> > to API pre-SO_TIMESTAMPING...
> 
> Hm. We actually oriented our code on the mv88e6xxx time stamping code base.

Where in mv88e6xxx does the driver set SKBTX_IN_PROGRESS?

I don't think it makes sense for DSA drivers to set this bit, as it
serves no purpose in the DSA context.

Thanks,
Richard

  reply	other threads:[~2020-07-13 14:01 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-10 11:36 [PATCH v1 0/8] Hirschmann Hellcreek DSA driver Kurt Kanzenbach
2020-07-10 11:36 ` [PATCH v1 1/8] net: dsa: Add tag handling for Hirschmann Hellcreek switches Kurt Kanzenbach
2020-07-12  2:57   ` Florian Fainelli
2020-07-10 11:36 ` [PATCH v1 2/8] net: dsa: Add DSA driver " Kurt Kanzenbach
2020-07-11 20:33   ` Florian Fainelli
2020-07-13  6:30     ` Kurt Kanzenbach
2020-07-16  8:29       ` Vladimir Oltean
2020-07-16  9:23         ` Kurt Kanzenbach
2020-07-16  9:39           ` Vladimir Oltean
2020-07-16 10:06             ` Kurt Kanzenbach
2020-07-10 11:36 ` [PATCH v1 3/8] net: dsa: hellcreek: Add PTP clock support Kurt Kanzenbach
2020-07-11 20:30   ` Richard Cochran
2020-07-11 20:38   ` Florian Fainelli
2020-07-13  6:34     ` Kurt Kanzenbach
2020-07-10 11:36 ` [PATCH v1 4/8] net: dsa: hellcreek: Add support for hardware timestamping Kurt Kanzenbach
2020-07-11 20:38   ` Richard Cochran
2020-07-13  6:35     ` Kurt Kanzenbach
2020-07-13  9:57   ` Vladimir Oltean
2020-07-13 10:57     ` Kurt Kanzenbach
2020-07-13 14:01       ` Richard Cochran [this message]
2020-07-13 14:12         ` Vladimir Oltean
2020-07-13 15:38           ` Richard Cochran
2020-07-10 11:36 ` [PATCH v1 5/8] net: dsa: hellcreek: Add TAPRIO offloading support Kurt Kanzenbach
2020-07-10 11:36 ` [PATCH v1 6/8] net: dsa: hellcreek: Add PTP status LEDs Kurt Kanzenbach
2020-07-10 11:36 ` [PATCH v1 7/8] dt-bindings: Add vendor prefix for Hirschmann Kurt Kanzenbach
2020-07-11 20:11   ` Florian Fainelli
2020-07-20 22:49   ` Rob Herring
2020-07-10 11:36 ` [PATCH v1 8/8] dt-bindings: net: dsa: Add documentation for Hellcreek switches Kurt Kanzenbach
2020-07-11 20:18   ` Florian Fainelli
2020-07-13  6:45     ` Kurt Kanzenbach
2020-07-13 14:44       ` Rob Herring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200713140112.GB27934@hoboy \
    --to=richardcochran@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=bigeasy@linutronix.de \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=kamil.alkhouri@hs-offenburg.de \
    --cc=kuba@kernel.org \
    --cc=kurt@linutronix.de \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=vivien.didelot@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.