netdev - Re: [PATCH net-next RFC v4 4/5] net: Let the active time stamping layer be selectable.

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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Thu, 11 May 2023 09:25:39 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: Köry Maincent <kory.maincent@...tlin.com>,
 netdev@...r.kernel.org, glipus@...il.com, maxime.chevallier@...tlin.com,
 vadim.fedorenko@...ux.dev, richardcochran@...il.com,
 gerhard@...leder-embedded.com, thomas.petazzoni@...tlin.com,
 krzysztof.kozlowski+dt@...aro.org, robh+dt@...nel.org,
 linux@...linux.org.uk
Subject: Re: [PATCH net-next RFC v4 4/5] net: Let the active time stamping
 layer be selectable.

On Thu, 11 May 2023 18:56:40 +0300 Vladimir Oltean wrote:
> > More importantly "monolithic" drivers have DMA/MAC/PHY all under 
> > the NDO so assuming that SOF_PHY_TIMESTAMPING implies a phylib PHY
> > is not going to work.
> > 
> > We need a more complex calling convention for the NDO.  
> 
> It's the first time I become aware of the issue of PHY timestamping in
> monolithic drivers that don't use phylib, and it's actually a very good
> point. I guess that input gives a clearer set of constraints for Köry to
> design an API where the selected timestamping layer is maybe passed to
> ndo_hwtstamp_set() and MAC drivers are obliged to look at it.
> 
> OTOH, a complaint about the current ndo_eth_ioctl() -> phy_mii_ioctl()
> code path was that phylib PHY drivers need to have the explicit blessing
> from the MAC driver in order to enable timestamping. This patch set
> attempts to circumvent that, and you're basically saying that it shouldn't.

Yes, we don't want to lose the simplification benefit for the common
cases. I think we should make the "please call me for PHY requests"
an opt in.

Annoyingly the "please call me for PHY/all requests" needs to be
separate from "this MAC driver supports PHY timestamps". Because in
your example the switch driver may not in fact implement PHY stamping,
it just wants to know about the configuration.

So we need a bit somewhere (in ops? in some other struct? in output 
of get_ts?) to let the driver declare that it wants to see all TS
requests. (I've been using bits in ops, IDK if people find that
repulsive or neat :))

Then if bit is not set or NDO returns -EOPNOTSUPP for PHY requests we
still try to call the PHY in the core?

Separately the MAC driver needs to be able to report what stamping 
it supports (DMA, MAC, PHY, as mentioned in reply to patch 2).