From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
netdev@vger.kernel.org, Paolo Abeni <pabeni@redhat.com>,
Richard Cochran <richardcochran@gmail.com>
Subject: Re: [PATCH net-next 1/5] net: dsa: mv88e6xxx: rename TAI definitions according to core
Date: Tue, 16 Sep 2025 17:14:59 +0100 [thread overview]
Message-ID: <aMmNA-JIisiV0z2z@shell.armlinux.org.uk> (raw)
In-Reply-To: <20250916143533.3jqqlpyp62gjwhh7@skbuf>
On Tue, Sep 16, 2025 at 05:35:33PM +0300, Vladimir Oltean wrote:
> On Tue, Sep 16, 2025 at 02:36:00PM +0100, Russell King (Oracle) wrote:
> > On Tue, Sep 16, 2025 at 11:46:45AM +0300, Vladimir Oltean wrote:
> > > On Mon, Sep 15, 2025 at 02:06:15PM +0100, Russell King (Oracle) wrote:
> > > > /* Offset 0x09: Event Status */
> > > > -#define MV88E6XXX_TAI_EVENT_STATUS 0x09
> > > > -#define MV88E6XXX_TAI_EVENT_STATUS_ERROR 0x0200
> > > > -#define MV88E6XXX_TAI_EVENT_STATUS_VALID 0x0100
> > > > -#define MV88E6XXX_TAI_EVENT_STATUS_CTR_MASK 0x00ff
> > > > -
> > > > /* Offset 0x0A/0x0B: Event Time */
> > >
> > > Was it intentional to keep the comment for a register with removed
> > > definitions, and this placement for it? It looks like this (confusing
> > > to me):
> > >
> > > /* Offset 0x09: Event Status */
> > > /* Offset 0x0A/0x0B: Event Time */
> > > #define MV88E6352_TAI_EVENT_STATUS 0x09
> >
> > Yes, totally intentional.
> >
> > All three registers are read by the code - as a single block, rather
> > than individually. While the definitions for the event time are not
> > referenced, I wanted to keep their comment, and that seemed to be
> > the most logical way.
>
> What I don't find so logical is that the bit fields of MV88E6352_TAI_EVENT_STATUS
> follow a comment which refers to "Event Time".
>
> Do we read the registers in a single mv88e6xxx_tai_read() call because
> the hardware requires us, or because of convenience?
For the packet timestamp registers that follow basically the same
format and layout, they're defined as a block that can be accessed
atomically. Nothing is stated with respect to these registers.
As the status register contains bits to say whether the timestamp was
overwritten, if reading them were not atomic, there would be no way to
be certain that the timestamp is remotely correct, especially when the
hardware is allowed to overwrite events.
Consider this scenario, where overwriting is permitted, if not atomic:
- event happens
- read status register
- read time lo register (first event time lo value)
- event happens
- read time high register (second event's time high value)
If it isn't atomic, there's no way to be certain that the time high
value corresponds with the time lo value.
If overwriting is not permitted then:
- event happens
- read status register
- read time lo register (first event time lo value)
- event happens
- read time high register (documented in this scenario to be invalid)
which is worse - and we wouldn't have read the status register to
know that the second event happened (which will flag an "Error" bit
in the status register in this case.)
So, the only sensible thing is to assume that, just like the other
timestamp capture registers, these behave the same. IOW, they are
atomic when read consecutively.
(The format of the timestamp registers have the same status + time lo
+ time high format, but with an additional PTP sequence number
register.)
> For writes, we
> write only a single u16 corresponding to the Event Status, so I suspect
> they are not completely indivisible, but I don't have documentation to
> confirm.
The write is required to clear the status bits, (a) so that we know
when a new event occurs, (b) clears any interrupt(s) that were raised
for it, and (c) if overwriting is not permitted, allows the next event
to be logged.
There's two modes for this register. DSA uses the "allow overwrite"
mode, so reading this better be atomic like the similar PTP
timestamping registers.
I suspect, however, that the answer is "we just don't know". Is there
any Marvell hardware out there where the PTP pins are used? Not that
I'm aware of, none of the ZII boards use it. Maybe Andrew has more
information on that.
> This is more of what I was expecting.
>
> /* Offset 0x09: Event Status */
> #define MV88E6352_TAI_EVENT_STATUS 0x09
> #define MV88E6352_TAI_EVENT_STATUS_CAP_TRIG 0x4000
> #define MV88E6352_TAI_EVENT_STATUS_ERROR 0x0200
> #define MV88E6352_TAI_EVENT_STATUS_VALID 0x0100
> #define MV88E6352_TAI_EVENT_STATUS_CTR_MASK 0x00ff
> /* Offset 0x0A/0x0B: Event Time Lo/Hi. Always read together with Event Status */
Okay, I'll change it to that.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2025-09-16 16:15 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-15 13:05 [PATCH net-next 0/5] net: dsa: mv88e6xxx: further PTP-related cleanups Russell King (Oracle)
2025-09-15 13:06 ` [PATCH net-next 1/5] net: dsa: mv88e6xxx: rename TAI definitions according to core Russell King (Oracle)
2025-09-16 8:46 ` Vladimir Oltean
2025-09-16 13:36 ` Russell King (Oracle)
2025-09-16 14:35 ` Vladimir Oltean
2025-09-16 16:14 ` Russell King (Oracle) [this message]
2025-09-15 13:06 ` [PATCH net-next 2/5] net: dsa: mv88e6xxx: remove unused TAI definitions Russell King (Oracle)
2025-09-16 9:23 ` Vladimir Oltean
2025-09-15 13:06 ` [PATCH net-next 3/5] net: dsa: mv88e6xxx: remove duplicated register definition Russell King (Oracle)
2025-09-16 9:22 ` Vladimir Oltean
2025-09-15 13:06 ` [PATCH net-next 4/5] net: dsa: mv88e6xxx: remove unused 88E6165 register definitions Russell King (Oracle)
2025-09-15 13:06 ` [PATCH net-next 5/5] net: dsa: mv88e6xxx: move mv88e6xxx_hwtstamp_work() prototype Russell King (Oracle)
2025-09-16 8:09 ` Vladimir Oltean
2025-09-16 8:36 ` Russell King (Oracle)
2025-09-16 9:03 ` Vladimir Oltean
2025-09-16 12:46 ` Andrew Lunn
2025-09-16 15:31 ` Russell King (Oracle)
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=aMmNA-JIisiV0z2z@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=richardcochran@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).