netdev - RE: [Intel-wired-lan] [PATCH iwl-net 04/10] idpf: negotiate PTP capabilies and get PTP clock

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]

Message-ID: <673b5b8ec78aa_1d050f29498@willemb.c.googlers.com.notmuch>
Date: Mon, 18 Nov 2024 10:21:50 -0500
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: "Olech, Milena" <milena.olech@...el.com>, 
 Willem de Bruijn <willemdebruijn.kernel@...il.com>, 
 "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>, 
 "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>, 
 "Kitszel, Przemyslaw" <przemyslaw.kitszel@...el.com>, 
 "Lobakin, Aleksander" <aleksander.lobakin@...el.com>
Subject: RE: [Intel-wired-lan] [PATCH iwl-net 04/10] idpf: negotiate PTP
 capabilies and get PTP clock

Olech, Milena wrote:
> On 11/14/2024 9:20 PM, Willem de Bruijn wrote:
> 
> > Milena Olech wrote:
> > > PTP capabilities are negotiated using virtchnl command. Add get
> > > capabilities function, direct access to read the PTP clock time and
> > > direct access to read the cross timestamp - system time and PTP clock
> > > time. Set initial PTP capabilities exposed to the stack.
> > >
> > > Reviewed-by: Alexander Lobakin <aleksander.lobakin@...el.com>
> > > Signed-off-by: Milena Olech <milena.olech@...el.com>
> >
> > Tested-by: Willem de Bruijn <willemb@...gle.com>
> >
> > >  /**
> > >   * struct idpf_ptp - PTP parameters
> > >   * @info: structure defining PTP hardware capabilities
> > >   * @clock: pointer to registered PTP clock device
> > >   * @adapter: back pointer to the adapter
> > > + * @cmd: HW specific command masks
> > > + * @dev_clk_regs: the set of registers to access the device clock
> > > + * @caps: PTP capabilities negotiated with the Control Plane
> > > + * @get_dev_clk_time_access: access type for getting the device clock time
> > > + * @get_cross_tstamp_access: access type for the cross timestamping
> > >   */
> > >  struct idpf_ptp {
> > >  	struct ptp_clock_info info;
> > >  	struct ptp_clock *clock;
> > >  	struct idpf_adapter *adapter;
> > > +	struct idpf_ptp_cmd cmd;
> > > +	struct idpf_ptp_dev_clk_regs dev_clk_regs;
> > > +	u32 caps;
> > > +	enum idpf_ptp_access get_dev_clk_time_access:16;
> > > +	enum idpf_ptp_access get_cross_tstamp_access:16;
> >
> > why are these 16 bit fields, when they are only ternary options?
> 
> Willem, I was trying to avoid holes in the struct and this is the best
> shape I was able to obtain. I'll try to reorder it in v2 and limit the
> 16 bit.

Does it work to reserve the number of bits needed for these enums
and add an explicit padding field for the remainder? Say

    u32 get_dev_clk_time_access:2;
    u32 get_cross_tstamp_access:2;
    u32 reserved:28;

No need to use the explicit enum type with fixed size allocation.
Though using that and/or leaving any padding implicit is fine too.