R: R: [PATCH net] net: dsa: mv88e6xxx: continue without PTP if the TAI period is invalid

[Nicolò Giuliani - nicolo.giuliani6@studio.unibo.it]

Hi Andrew,

Thanks, that is what I needed. I checked it on the board (chip ID 0x1930, so the driver entry is the 88E6193X, family 6393, which uses mv88e6390_avb_ops and mv88e6352_ptp_ops):

- TAI register 0x1e reads 0x0000, so bit 14 is 0: the internal clock is selected. Register 0x01 should then hold 0x0FA0, but it reads 0x0000.
- The whole TAI global block reads zero through the driver's accessor: all 32 registers of the TAI global, of the PTP global and of one port PTP block. Writing 8000 to register 0x01 and 0x8000 to register 0x00 reads back 0x0000.
- To see whether the block is somewhere else, I scanned the whole indirect space of the Global 2 AVB command/data registers (0x16/0x17): every port field 0-31, block 0-7 and address 0-31 with the 6390 command encoding, and every port field 0-15 with the 6352 encoding. Every read returns 0x0000. The only exceptions were a few reads of 0xc801, at a different place on every run, which looks like an access by the driver interleaving with my raw scan, not a register.
- The commands complete (the busy bit clears and there is no MDIO error), but writing a pattern to Global 2 register 0x17 or 0x16 reads back 0, while other Global 2 registers hold non-zero values.

So the indirect AVB interface used by the 6390 ops does not answer on this chip: this is not only a TAI period register that is not programmed. Either the PTP unit is not reachable this way on the 6393X family, or it is not present or gated on the 88E6193X. The 6393X entries in the driver reuse the 6390 ops, and I cannot tell from the driver whether PTP was ever verified on them.

I do not have the datasheet, but you said you have others: does the 88E6393X family datasheet put the PTP/TAI access somewhere other than Global 2 0x16/0x17, or say that the 88E6193X and 88E6191X have no PTP unit? If the access is different, I will write a patch that fixes the ops for the family; if the 88E6193X has no PTP, I will write a patch that clears ptp_support for it. I will not send the patch that only skips PTP.

Thanks,
Nicolo Giuliani

________________________________________
Da: Andrew Lunn <andrew@xxxxxxx>
Inviato: domenica 20 settembre 2026 20:58
A: Nicolò Giuliani - nicolo.giuliani6@xxxxxxxxxxxxxxx
Cc: Vladimir Oltean; David S. Miller; Eric Dumazet; Jakub Kicinski; Paolo Abeni; Richard Cochran; netdev@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
Oggetto: Re: R: [PATCH net] net: dsa: mv88e6xxx: continue without PTP if the TAI period is invalid

On Sun, Sep 20, 2026 at 05:34:01PM +0000, Nicolò Giuliani - nicolo.giuliani6@xxxxxxxxxxxxxxx wrote:
>
> Hi Andrew,
>
> > The point of the failure is to indicate an assumption in the driver is
> > not valid, and we need to examine the assumption.
>
> You are right, and my patch only works around it.
>
> > What does the datasheet for the 88E6193X say about this register? Has
> > its meaning changed? Marvell like moving registers around, is it
> > somewhere else?
>
> I do not have the datasheet for this chip, so I cannot answer that from documentation.

I don't have the 88E6193X either. But i do have some other datasheets.

If the device is using the internal 250MHz clock, the register is
expected to contain 0x0FA0, 4000picoseconds. If i remember correctly,
the patch which changed things was because different devices have
different internal clocks, hence the need to read it.

There is however the option to use an external clock. This is
controlled via TAI register 0x1e. If bit 14 is 0, the internal clock
is used. If 1, the external clock is used. With the external clock,
you need to write to register 0x01 what the external clock period is,
in picoseconds.

So you probably want to check what register 0x1e contains.

        Andrew