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:   Mon, 25 Apr 2022 16:55:40 -0700
From:   Jonathan Lemon <jonathan.lemon@...il.com>
To:     Richard Cochran <richardcochran@...il.com>
Cc:     f.fainelli@...il.com, bcm-kernel-feedback-list@...adcom.com,
        andrew@...n.ch, hkallweit1@...il.com, linux@...linux.org.uk,
        netdev@...r.kernel.org, kernel-team@...com
Subject: Re: [PATCH net-next v1 1/4] net: phy: broadcom: Add PTP support for
 some Broadcom PHYs.

On Sun, Apr 24, 2022 at 06:38:00PM -0700, Richard Cochran wrote:
> On Sat, Apr 23, 2022 at 07:23:53PM -0700, Jonathan Lemon wrote:
> 
> > +static bool bcm_ptp_get_tstamp(struct bcm_ptp_private *priv,
> > +			       struct bcm_ptp_capture *capts)
> > +{
> > +	struct phy_device *phydev = priv->phydev;
> > +	u16 ts[4], reg;
> > +	u32 sec, nsec;
> > +
> > +	mutex_lock(&priv->mutex);
> > +
> > +	reg = bcm_phy_read_exp(phydev, INTR_STATUS);
> > +	if ((reg & INTC_SOP) == 0) {
> > +		mutex_unlock(&priv->mutex);
> > +		return false;
> > +	}
> > +
> > +	bcm_phy_write_exp(phydev, TS_READ_CTRL, TS_READ_START);
> > +
> > +	ts[0] = bcm_phy_read_exp(phydev, TS_REG_0);
> > +	ts[1] = bcm_phy_read_exp(phydev, TS_REG_1);
> > +	ts[2] = bcm_phy_read_exp(phydev, TS_REG_2);
> > +	ts[3] = bcm_phy_read_exp(phydev, TS_REG_3);
> > +
> > +	/* not in be32 format for some reason */
> > +	capts->seq_id = bcm_phy_read_exp(priv->phydev, TS_INFO_0);
> > +
> > +	reg = bcm_phy_read_exp(phydev, TS_INFO_1);
> > +	capts->msgtype = reg >> 12;
> > +	capts->tx_dir = !!(reg & BIT(11));
> 
> Okay, so now I am sad.  The 541xx has:
> 
>   TIMESTAMP_INFO_1 0xA8C  bit 0 DIR, bits 1-2 msg_type, etc
>   TIMESTAMP_INFO_2 0xA8D  sequence ID
> 
> It is the same info, but randomly shuffled among the two registers in
> a different way.
> 
> So much for supporting multiple devices with a common code base.  :(

We could just have a chip-specific version of this function.  The
recovered timestamp is passed back in a structure, so the rest of the
code would be unchanged.
-- 
Jonathan    (no, not volunteering to do this...)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ