netdev - Re: [PATCH v2 net-next 11/12] net: aquantia: add support for PIN funcs

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:   Tue, 15 Oct 2019 14:35:39 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Igor Russkikh <Igor.Russkikh@...antia.com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "richardcochran@...il.com" <richardcochran@...il.com>,
        Egor Pomozov <Egor.Pomozov@...antia.com>,
        Dmitry Bezrukov <Dmitry.Bezrukov@...antia.com>,
        Simon Edelhaus <sedelhaus@...vell.com>,
        Pavel Belous <Pavel.Belous@...antia.com>
Subject: Re: [PATCH v2 net-next 11/12] net: aquantia: add support for PIN
 funcs

On Tue, Oct 08, 2019 at 10:56:59AM +0000, Igor Russkikh wrote:
> From: Dmitry Bezrukov <dmitry.bezrukov@...antia.com>
> 
> Depending on FW configuration we can manage from 0 to 3 PINs for periodic output
> and from 0 to 1 ext ts PIN for getting TS for external event.
> 
> Ext TS PIN functionality is implemented via periodic timestamps polling
> directly from PHY, because right now there is now way to received
> PIN trigger interrupt from phy.

Hi Igor

Is that a hardware limitation? Is the PHY interrupt not connected at
all? Could future cards have the interrupt connected?

> +static int aq_ptp_hw_pin_conf(struct aq_nic_s *aq_nic, u32 pin_index, u64 start,
> +			      u64 period)
> +{
> +	if (period)
> +		netdev_info(aq_nic->ndev,
> +			    "Enable GPIO %d pulsing, start time %llu, period %u\n",
> +			    pin_index, start, (u32)period);
> +	else
> +		netdev_info(aq_nic->ndev,
> +			    "Disable GPIO %d pulsing, start time %llu, period %u\n",
> +			    pin_index, start, (u32)period);

_info is too high a log level. _dbg would be better..


> +
> +	/* Notify hardware of request to being sending pulses.
> +	 * If period is ZERO then pulsen is disabled.
> +	 */
> +	mutex_lock(&aq_nic->fwreq_mutex);
> +	aq_nic->aq_hw_ops->hw_gpio_pulse(aq_nic->aq_hw, pin_index,
> +					 start, (u32)period);
> +	mutex_unlock(&aq_nic->fwreq_mutex);
> +
> +	return 0;
> +}
> +
> +static int aq_ptp_perout_pin_configure(struct ptp_clock_info *ptp,
> +				       struct ptp_clock_request *rq, int on)
> +{
> +	struct aq_ptp_s *aq_ptp = container_of(ptp, struct aq_ptp_s, ptp_info);
> +	struct ptp_clock_time *t = &rq->perout.period;
> +	struct ptp_clock_time *s = &rq->perout.start;
> +	struct aq_nic_s *aq_nic = aq_ptp->aq_nic;
> +	u64 start, period;
> +	u32 pin_index = rq->perout.index;
> +
> +	/* verify the request channel is there */
> +	if (pin_index >= ptp->n_per_out)
> +		return -EINVAL;
> +
> +	/* we cannot support periods greater
> +	 * than 4 seconds due to reg limit
> +	 */
> +	if (t->sec > 4 || t->sec < 0)
> +		return -ERANGE;
> +
> +	/* convert to unsigned 64b ns,
> +	 * verify we can put it in a 32b register
> +	 */
> +	period = on ? t->sec * NSEC_PER_SEC + t->nsec : 0;
> +
> +	/* verify the value is in range supported by hardware */
> +	if (period > U32_MAX)
> +		return -ERANGE;

What is U32_MAX ns? Is it greater than 4 seconds?

     Andrew