netdev - Re: [PATCH net-next 7/9] mlxsw: spectrum_ptp: Add implementation for physical hardware clock operations

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: <87muiwxv8o.fsf@mellanox.com>
Date:   Wed, 5 Jun 2019 09:00:09 +0000
From:   Petr Machata <petrm@...lanox.com>
To:     Richard Cochran <richardcochran@...il.com>
CC:     Ido Schimmel <idosch@...sch.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        Jiri Pirko <jiri@...lanox.com>,
        Shalom Toledo <shalomt@...lanox.com>,
        mlxsw <mlxsw@...lanox.com>, Ido Schimmel <idosch@...lanox.com>
Subject: Re: [PATCH net-next 7/9] mlxsw: spectrum_ptp: Add implementation for
 physical hardware clock operations


Richard Cochran <richardcochran@...il.com> writes:

> On Mon, Jun 03, 2019 at 03:12:42PM +0300, Ido Schimmel wrote:
>> +struct mlxsw_sp_ptp_clock *
>> +mlxsw_sp1_ptp_clock_init(struct mlxsw_sp *mlxsw_sp, struct device *dev)

[...]

>> +	clock->ptp_info = mlxsw_sp1_ptp_clock_info;
>> +	clock->ptp = ptp_clock_register(&clock->ptp_info, dev);
>> +	if (IS_ERR(clock->ptp)) {
>> +		err = PTR_ERR(clock->ptp);
>> +		dev_err(dev, "ptp_clock_register failed %d\n", err);
>> +		goto err_ptp_clock_register;
>> +	}
>> +
>> +	return clock;
>
> You need to handle the case where ptp_clock_register() returns NULL...
>
> /**
>  * ptp_clock_register() - register a PTP hardware clock driver
>  *
>  * @info:   Structure describing the new clock.
>  * @parent: Pointer to the parent device of the new clock.
>  *
>  * Returns a valid pointer on success or PTR_ERR on failure.  If PHC
>  * support is missing at the configuration level, this function
>  * returns NULL, and drivers are expected to gracefully handle that
>  * case separately.
>  */

We don't build the PTP module at all unless CONFIG_PTP_1588_CLOCK is
enabled, and fall back to inline stubs unless it IS_REACHABLE. I believe
this should be OK.