[RFC PATCH v4 0/4] Create common DPLL/clock configuration API

[Kubalewski, Arkadiusz]

>From: Jakub Kicinski <kuba at kernel.org>
>Sent: Friday, December 9, 2022 1:40 AM
>On Thu, 8 Dec 2022 12:28:51 +0100 Jiri Pirko wrote:
>> >I think we discussed using serial numbers.
>>
>> Can you remind it? Do you mean serial number of pin?
>
>Serial number of the ASIC, board or device.
>Something will have a serno, append to that your pin id of choice - et
>voila!

Right now, driver can find dpll with:
struct dpll_device *dpll_device_get_by_cookie(u8 cookie[DPLL_COOKIE_LEN],
                                              enum dpll_type type, u8 idx); 

Where arguments would be the same as given when first instance have allocated
dpll with:
struct dpll_device
*dpll_device_alloc(struct dpll_device_ops *ops, enum dpll_type type,
                   const u8 cookie[DPLL_COOKIE_LEN], u8 dev_driver_idx,
                   void *priv, struct device *parent);

Which means all driver instances must know those values if they need to share
dpll or pins.

Thanks,
Arkadiusz

>
>> >Are you saying within the driver it's somehow easier? The driver
>> >state is mostly per bus device, so I don't see how.
>>
>> You can have some shared data for multiple instances in the driver
>> code, why not?
>
>The question is whether it's easier.
>Easier to ensure quality of n implementations in random drivers.
>Or one implementation in the core, with a lot of clever people paying
>attention and reviewing the code.
>
>> >> There are many problems with that approach, and the submitted patch
>> >> is not explaining any of them. E.g. it contains the
>> >> dpll_muxed_pin_register but no free counterpart + no flows.
>> >
>> >SMOC.
>>
>> Care to spell this out. I guess you didn't mean "South Middlesex
>> Opportunity Council" :D
>
>Simple matter of coding.