Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <70ce864c-ca13-4fc4-fcb5-9b7f91579a90@enneenne.com>
Date:   Fri, 9 Jun 2023 09:30:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Subject: Re: [RFC PATCH] pps: Increase PPS_MAX_SOURCES value.
To:     Charlie Johnston <charlie.johnston@ni.com>
Cc:     linux-kernel@vger.kernel.org, brenda.streiff@ni.com
References: <20230605203147.694716-1-charlie.johnston@ni.com>
 <fe435e68-8e05-9078-0fe6-63ef7cce2fc9@enneenne.com>
 <b794bccc-0233-4d78-df6f-bf7c688a7d7d@ni.com>
From:   Rodolfo Giometti <giometti@enneenne.com>
Content-Language: en-US
In-Reply-To: <b794bccc-0233-4d78-df6f-bf7c688a7d7d@ni.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 08/06/23 00:07, Charlie Johnston wrote:
> On 6/7/23 02:33, Rodolfo Giometti wrote:
>> On 05/06/23 22:31, Charlie Johnston wrote:
>>> For consistency with what ptp uses for minors, this
>>> change sets PPS_MAX_SOURCES to MINORMASK + 1.
>>>
>>> The PPS_MAX_SOURCES value is currently set to 16. In
>>> some cases this was not sufficient for a system. For
>>> example, a system with multiple (4+) PCIe cards each
>>> with 4 PTP-capable ethernet interfaces could run out
>>> of the available PPS major:minors if each interface
>>> registers a PPS source.
>>>
>>> Signed-off-by: Charlie Johnston <charlie.johnston@ni.com>
>>> ---
>>>    include/uapi/linux/pps.h | 2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/include/uapi/linux/pps.h b/include/uapi/linux/pps.h
>>> index 009ebcd8ced5..85f472330da8 100644
>>> --- a/include/uapi/linux/pps.h
>>> +++ b/include/uapi/linux/pps.h
>>> @@ -26,7 +26,7 @@
>>>    #include <linux/types.h>
>>>      #define PPS_VERSION        "5.3.6"
>>> -#define PPS_MAX_SOURCES        16        /* should be enough... */
>>> +#define PPS_MAX_SOURCES        (MINORMASK + 1)
>>>      /* Implementation note: the logical states ``assert'' and ``clear''
>>>     * are implemented in terms of the chip register, i.e. ``assert''
>>
>> I have just one question: are you sure that it's safe to call idr_alloc(..., 0, (MINORMASK + 1), ...)?
>>
>> Ciao,
>>
>> Rodolfo
>>
> 
> Thanks for taking a look!
> 
> My understanding is that idr_alloc(..., start, end, ...) can take any end value up to INT_MAX. It also handles any values <= 0 by treating them as equal to INT_MAX + 1 since the end value is non-inclusive. I can't think of any reason using MINORMASK + 1 here would be an issue since it's much less than the maximum value idr_alloc() allows.
> 
> A number of drivers (e.g. ptp) just explicitly use a start and end value of 0, but I don't think that change would fit here.

I see and maybe I should replace the usage of idr_*() with ida_*() as PTP does...

However the right-thing(TM) to do here should be dropping PPS_MAX_SOURCES at all!

Let me go deeper in this issue. I'm going to produce a patch set in next days. 
Have you any chances to test it?

Ciao,

Rodolfo

-- 
GNU/Linux Solutions                  e-mail: giometti@enneenne.com
Linux Device Driver                          giometti@linux.it
Embedded Systems                     phone:  +39 349 2432127
UNIX programming                     skype:  rodolfo.giometti