[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221208163949.3833fe7b@kernel.org>
Date: Thu, 8 Dec 2022 16:39:49 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Jiri Pirko <jiri@...nulli.us>
Cc: netdev.dump@...il.com,
"'Kubalewski, Arkadiusz'" <arkadiusz.kubalewski@...el.com>,
'Vadim Fedorenko' <vfedorenko@...ek.ru>,
'Jonathan Lemon' <jonathan.lemon@...il.com>,
'Paolo Abeni' <pabeni@...hat.com>, netdev@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-clk@...r.kernel.org
Subject: Re: [RFC PATCH v4 0/4] Create common DPLL/clock configuration API
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!
> >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.
Powered by blists - more mailing lists