netdev - Re: [RFC PATCH v1 3/3] ptp_ocp: implement DPLL ops

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, 27 Jun 2022 23:06:38 +0100
From:   Vadim Fedorenko <vfedorenko@...ek.ru>
To:     Jonathan Lemon <jonathan.lemon@...il.com>
Cc:     Jakub Kicinski <kuba@...nel.org>, Vadim Fedorenko <vadfed@...com>,
        Aya Levin <ayal@...dia.com>,
        Arkadiusz Kubalewski <arkadiusz.kubalewski@...el.com>,
        netdev@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC PATCH v1 3/3] ptp_ocp: implement DPLL ops

On 27.06.2022 20:27, Jonathan Lemon wrote:
> On Sun, Jun 26, 2022 at 08:28:34PM +0100, Vadim Fedorenko wrote:
>> On 24.06.2022 00:36, Jonathan Lemon wrote:
>>> On Fri, Jun 24, 2022 at 12:11:43AM +0100, Vadim Fedorenko wrote:
>>>> On 23.06.2022 19:28, Jonathan Lemon wrote:
>>>>> On Thu, Jun 23, 2022 at 03:57:17AM +0300, Vadim Fedorenko wrote:
>>>>>> From: Vadim Fedorenko <vadfed@...com>
>>>>>> +static int ptp_ocp_dpll_get_source_type(struct dpll_device *dpll, int sma)
>>>>>> +{
>>>>>> +	struct ptp_ocp *bp = (struct ptp_ocp *)dpll_priv(dpll);
>>>>>> +	int ret;
>>>>>> +
>>>>>> +	if (bp->sma[sma].mode != SMA_MODE_IN)
>>>>>> +		return -1;
>>>>>> +
>>>>>> +	switch (ptp_ocp_sma_get(bp, sma)) {
>>>>>> +	case 0:
>>>>>> +		ret = DPLL_TYPE_EXT_10MHZ;
>>>>>> +		break;
>>>>>> +	case 1:
>>>>>> +	case 2:
>>>>>> +		ret = DPLL_TYPE_EXT_1PPS;
>>>>>> +		break;
>>>>>> +	default:
>>>>>> +		ret = DPLL_TYPE_INT_OSCILLATOR;
>>>>>> +	}
>>>>>> +
>>>>>> +	return ret;
>>>>>> +}
>>>>>
>>>>> These case statements switch on private bits.  This needs to match
>>>>> on the selector name instead.
>>>>>
>>>>
>>>> Not sure that string comparison is a good idea. Maybe it's better to extend
>>>> struct ocp_selector with netlink type id and fill it according to hardware?
>>>
>>> Sure, that could be an option.  But, as this is DPLL only, how does it
>>> handle things when a pin is used for non-clock IO?  In the timecard,
>>> for example, we have the frequency counters for input, and the frequency
>>> generators/VCC/GND for output.
>>>
>>> Actually our HW has a multi-level input, where the DPLL selects its
>>> source from an internal mux - this isn't reflected here.  The external
>>> pins feed into some complex HW logic, which performs its own priority
>>> calculations before presenting the end result as an available selection
>>> for the DPLL.
>>
>> I don't really know how to deal with such configuration. For now I simply added
>> CUSTOM type but I'm not sure how to deal it 'set' functions. Do you have any
>> suggestions?
> 
> No suggestions other than the API should be able to handle things?

Ok, I will try to combine this with Arkadiusz's suggestion with priorities.
> 
> Also, should there be a notifier if the source changes?

Definitely. I'm working on *set operations and will add notifiers at the same time.