From: Jiri Pirko <jiri@resnulli.us>
To: Jakub Kicinski <kuba@kernel.org>
Cc: netdev.dump@gmail.com, "'Kubalewski,
Arkadiusz'" <arkadiusz.kubalewski@intel.com>,
'Vadim Fedorenko' <vfedorenko@novek.ru>,
'Jonathan Lemon' <jonathan.lemon@gmail.com>,
'Paolo Abeni' <pabeni@redhat.com>,
netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-clk@vger.kernel.org
Subject: Re: [RFC PATCH v4 0/4] Create common DPLL/clock configuration API
Date: Thu, 8 Dec 2022 12:28:51 +0100 [thread overview]
Message-ID: <Y5HKczFwRnfRVtnR@nanopsycho> (raw)
In-Reply-To: <20221207152157.6185b52b@kernel.org>
Thu, Dec 08, 2022 at 12:21:57AM CET, kuba@kernel.org wrote:
>On Wed, 7 Dec 2022 15:09:03 +0100 netdev.dump@gmail.com wrote:
>> > -----Original Message-----
>> > From: Jakub Kicinski <kuba@kernel.org>
>> > Sent: Wednesday, December 7, 2022 3:48 AM
>> > Subject: Re: [RFC PATCH v4 0/4] Create common DPLL/clock configuration API
>> >
>> > On Fri, 2 Dec 2022 17:12:06 +0100 Jiri Pirko wrote:
>> [...]
>> capable
>> [...]
>> require
>> [...]
>
>Please fix line wrapping in your email client.
>And add a name to your account configuration :/
>
>> > > Yep, you have the knowledge of sharing inside the driver, so you should
>> > > do it there. For multiple instances, use in-driver notifier for example.
>> >
>> > No, complexity in the drivers is not a good idea. The core should cover
>> > the complexity and let the drivers be simple.
>>
>> But how does Driver A know where to connect its pin to? It makes sense to
>> share
>
>I think we discussed using serial numbers.
Can you remind it? Do you mean serial number of pin?
>
>> pins between the DPLLs exposed by a single driver, but not really outside of
>> it.
>> And that can be done simply by putting the pin ptr from the DPLLA into the
>> pin
>> list of DPLLB.
>
>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?
>
>> If we want the kitchen-and-sink solution, we need to think about corner
>> cases.
>> Which pin should the API give to the userspace app - original, or
>> muxed/parent?
>
>IDK if I parse but I think both. If selected pin is not directly
>attached the core should configure muxes.
>
>> How would a teardown look like - if Driver A registered DPLLA with Pin1 and
>> Driver B added the muxed pin then how should Driver A properly
>> release its pins? Should it just send a message to driver B and trust that
>> it
>> will receive it in time before we tear everything apart?
>
>Trivial.
>
>> 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
>
>> If we want to get shared pins, we need a good example of how this mechanism
>> can be used.
>
>Agreed.
>
>> > > There are currently 3 drivers for dpll I know of. This in ptp_ocp and
>> > > mlx5 there is no concept of sharing pins. You you are talking about a
>> > > single driver.
>> > >
>> > > What I'm trying to say is, looking at the code, the pin sharing,
>> > > references and locking makes things uncomfortably complex. You are so
>> > > far the only driver to need this, do it internally. If in the future
>> > > other driver appears, this code would be eventually pushed into dpll
>> > > core. No impact on UAPI from what I see. Please keep things as simple as
>> > > possible.
>> >
>> > But the pin is shared for one driver. Who cares if it's not shared in
>> > another. The user space must be able to reason about the constraints.
>> >
>> > You are suggesting drivers to magically flip state in core objects
>> > because of some hidden dependencies?!
>>
>> If we want to go outside the device, we'd need some universal language
>> to describe external connections - such as the devicetree. I don't see how
>> we can reliably implement inter-driver dependency otherwise.
>
>There's plenty examples in the tree. If we can't use serial number
>directly we can compare the driver pointer + whatever you'd compare
>in the driver internal solution.
>
>> I think this would be better served in the userspace with a board-specific
>> config file. Especially since the pins can be externally connected anyway.
>
>Opinions vary, progress is not being made.
next prev parent reply other threads:[~2022-12-08 11:29 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-29 21:37 [RFC PATCH v4 0/4] Create common DPLL/clock configuration API Vadim Fedorenko
2022-11-29 21:37 ` [RFC PATCH v4 1/4] dpll: add dpll_attr/dpll_pin_attr helper classes Vadim Fedorenko
2022-11-29 21:37 ` [RFC PATCH v4 2/4] dpll: Add DPLL framework base functions Vadim Fedorenko
2022-11-30 15:21 ` Jiri Pirko
2022-11-30 16:23 ` Jiri Pirko
2022-12-23 16:45 ` Kubalewski, Arkadiusz
2023-01-02 12:28 ` Jiri Pirko
2022-11-30 16:37 ` Jiri Pirko
2022-12-02 11:27 ` Kubalewski, Arkadiusz
2022-12-02 12:39 ` Jiri Pirko
2022-12-02 14:54 ` Kubalewski, Arkadiusz
2022-12-02 16:15 ` Jiri Pirko
[not found] ` <20221202212206.3619bd5f@kernel.org>
2022-12-05 10:32 ` Jiri Pirko
2022-12-06 0:19 ` Jakub Kicinski
2022-12-06 8:50 ` Jiri Pirko
2022-12-06 17:27 ` Jakub Kicinski
2022-12-07 13:10 ` Jiri Pirko
2022-12-07 16:59 ` Jakub Kicinski
2022-12-08 8:14 ` Jiri Pirko
2022-12-08 16:19 ` Jakub Kicinski
2022-12-08 16:33 ` Jiri Pirko
2022-12-08 17:05 ` Jakub Kicinski
2022-12-09 9:29 ` Jiri Pirko
2022-12-09 16:19 ` Jakub Kicinski
2022-12-12 13:36 ` Jiri Pirko
2022-12-13 18:08 ` Kubalewski, Arkadiusz
2022-12-14 7:32 ` Jiri Pirko
2022-11-29 21:37 ` [RFC PATCH v4 3/4] dpll: documentation on DPLL subsystem interface Vadim Fedorenko
2022-12-19 9:13 ` Paolo Abeni
2023-01-12 13:45 ` Kubalewski, Arkadiusz
2022-11-29 21:37 ` [RFC PATCH v4 4/4] ptp_ocp: implement DPLL ops Vadim Fedorenko
2022-11-30 12:41 ` Jiri Pirko
2022-12-02 11:27 ` Kubalewski, Arkadiusz
2022-12-02 12:48 ` Jiri Pirko
2022-12-02 14:39 ` Kubalewski, Arkadiusz
2022-12-02 16:20 ` Jiri Pirko
2022-12-08 0:35 ` Kubalewski, Arkadiusz
2022-12-08 8:19 ` Jiri Pirko
2022-12-07 2:33 ` Jakub Kicinski
2022-12-07 13:19 ` Jiri Pirko
[not found] ` <20221207090524.3f562eeb@kernel.org>
2022-12-08 11:22 ` Jiri Pirko
2022-12-09 0:36 ` Jakub Kicinski
2022-12-09 9:32 ` Jiri Pirko
2022-11-30 12:32 ` [RFC PATCH v4 0/4] Create common DPLL/clock configuration API Jiri Pirko
2022-12-02 11:27 ` Kubalewski, Arkadiusz
2022-12-02 16:12 ` Jiri Pirko
2022-12-07 2:47 ` Jakub Kicinski
2022-12-07 14:09 ` netdev.dump
2022-12-07 23:21 ` Jakub Kicinski
2022-12-08 11:28 ` Jiri Pirko [this message]
2022-12-09 0:39 ` Jakub Kicinski
2022-12-09 0:56 ` Kubalewski, Arkadiusz
2022-12-08 18:08 ` Maciek Machnikowski
2022-12-09 11:07 ` Jiri Pirko
2022-12-09 14:09 ` Maciek Machnikowski
2022-12-09 16:31 ` Jakub Kicinski
2022-12-09 17:11 ` Maciek Machnikowski
2022-12-12 13:58 ` Jiri Pirko
2023-01-09 14:43 ` Kubalewski, Arkadiusz
2023-01-09 16:30 ` Jiri Pirko
2023-01-10 10:54 ` Kubalewski, Arkadiusz
2023-01-10 14:28 ` Jiri Pirko
[not found] ` <645a5bfd-0092-2f39-0ff2-3ffb27ccf8fe@machnikowski.net>
2023-01-11 14:17 ` Kubalewski, Arkadiusz
2023-01-11 14:40 ` Maciek Machnikowski
2023-01-11 15:30 ` Kubalewski, Arkadiusz
2023-01-11 15:54 ` Maciek Machnikowski
2023-01-11 16:27 ` Kubalewski, Arkadiusz
2023-01-10 20:05 ` Jakub Kicinski
2023-01-11 8:19 ` Jiri Pirko
2023-01-11 14:16 ` Kubalewski, Arkadiusz
2023-01-11 15:04 ` Jiri Pirko
2023-01-11 15:30 ` Kubalewski, Arkadiusz
2023-01-11 16:14 ` Jiri Pirko
2023-01-12 12:15 ` Kubalewski, Arkadiusz
2023-01-12 14:43 ` Jiri Pirko
2022-12-09 0:46 ` Kubalewski, Arkadiusz
2022-12-07 14:51 ` Jiri Pirko
[not found] ` <20221207091946.3115742f@kernel.org>
2022-12-08 12:02 ` Jiri Pirko
2022-12-09 0:54 ` Jakub Kicinski
2022-12-08 18:23 ` Kubalewski, Arkadiusz
2022-12-08 0:27 ` Kubalewski, Arkadiusz
2022-12-08 11:58 ` Jiri Pirko
2022-12-08 23:05 ` Kubalewski, Arkadiusz
2022-12-09 10:01 ` Jiri Pirko
2023-01-12 12:23 ` Kubalewski, Arkadiusz
2023-01-12 14:50 ` Jiri Pirko
2023-01-12 19:09 ` Jakub Kicinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y5HKczFwRnfRVtnR@nanopsycho \
--to=jiri@resnulli.us \
--cc=arkadiusz.kubalewski@intel.com \
--cc=jonathan.lemon@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=netdev.dump@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=vfedorenko@novek.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).