[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231121183114.727fb6d7@kmaincent-XPS-13-7390>
Date: Tue, 21 Nov 2023 18:31:14 +0100
From: Köry Maincent <kory.maincent@...tlin.com>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: Jakub Kicinski <kuba@...nel.org>,
Florian Fainelli <florian.fainelli@...adcom.com>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@...adcom.com>,
Andrew Lunn <andrew@...n.ch>,
Heiner Kallweit <hkallweit1@...il.com>,
Russell King <linux@...linux.org.uk>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Paolo Abeni <pabeni@...hat.com>,
Richard Cochran <richardcochran@...il.com>,
Radu Pirea <radu-nicolae.pirea@....nxp.com>,
Jay Vosburgh <j.vosburgh@...il.com>,
Andy Gospodarek <andy@...yhouse.net>,
Nicolas Ferre <nicolas.ferre@...rochip.com>,
Claudiu Beznea <claudiu.beznea@...on.dev>,
Willem de Bruijn <willemdebruijn.kernel@...il.com>,
Jonathan Corbet <corbet@....net>,
Horatiu Vultur <horatiu.vultur@...rochip.com>,
UNGLinuxDriver@...rochip.com, Simon Horman <horms@...nel.org>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-doc@...r.kernel.org,
Maxime Chevallier <maxime.chevallier@...tlin.com>
Subject: Re: [PATCH net-next v7 15/16] net: ethtool: ts: Let the active time
stamping layer be selectable
On Tue, 21 Nov 2023 00:05:49 +0200
Vladimir Oltean <vladimir.oltean@....com> wrote:
> On Mon, Nov 20, 2023 at 01:37:37PM -0800, Jakub Kicinski wrote:
> > > Is it an accurate summary?
> >
> > Yes.
> >
> > For now we can impose the requirement that only one can be active
> > easily at the kernel level. But the uAPI should allow expressing more.
>
> I see. That's quite something to think about for Köry. In its defense,
> I also agree that this idea seems the most orthogonal to everything else
> that we have or may want to add in the future, and is not likely to
> become obsoleted by some other mechanism that can achieve the same
> thing, but in a more flexible way. It's just that it's quite the task.
>
> I sense it may be time to dust off and submit the rest of my
> ndo_hwtstamp_get()/ ndo_hwtstamp_set() conversions before a netlink
> conversion of SIOCGHWTSTAMP/SIOCSHWTSTAMP could even take place...
> https://github.com/vladimiroltean/linux/commits/ndo-hwtstamp-v9
Ok I kind of got an idea of what is your prerequisites.
If I summarize, a solution could be this:
- Expand struct hwtstamp_config with a phc_index member for the SIOCG/SHWTSTAMP
commands.
To keep backward compatibility if phc_index is not set in the hwtstamp_config
data from userspace use the default hwtstamp (the default being selected as
done in my patch series).
Is this possible, would it breaks things?
- In netlink part, send one netlink tsinfo skb for each phc_index.
Could be done in a later patch series:
- Expand netlink TSINFO with ETHTOOL_A_TSINFO_HWSTAMP_PROVIDER_QUALIFIER.
Describing this struct:
enum ethtool_hwstamp_provider_qualifier {
ETHTOOL_HWSTAMP_PROVIDER_QUALIFIER_PRECISE,
ETHTOOL_HWSTAMP_PROVIDER_QUALIFIER_APPROX,
};
Set the desired qualifier through TSINFO_SET or through SIOCSHWTSTAMP by
expanding again the struct hwtstamp_config.
Do you think this is feasible?
I might miss some core stuff.
Regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
Powered by blists - more mailing lists