| 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
| ||
|
Message-ID: <20221209083104.2469ebd6@kernel.org>
Date: Fri, 9 Dec 2022 08:31:04 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Maciek Machnikowski <maciek@...hnikowski.net>
Cc: Jiri Pirko <jiri@...nulli.us>,
"'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 Fri, 9 Dec 2022 15:09:08 +0100 Maciek Machnikowski wrote:
> On 12/9/2022 12:07 PM, Jiri Pirko wrote:
> > Looking at the documentation of the chips, they all have mupltiple DPLLs
> > on a die. Arkadiusz, in your proposed implementation, do you model each
> > DPLL separatelly? If yes, then I understand the urgency of need of a
> > shared pin. So all DPLLs sharing the pin are part of the same chip?
> >
> > Question: can we have an entity, that would be 1:1 mapped to the actual
> > device/chip here? Let's call is "a synchronizer". It would contain
> > multiple DPLLs, user-facing-sources(input_connector),
> > user-facing-outputs(output_connector), i/o pins.
> >
> > An example:
> > SYNCHRONIZER
> >
> > ┌───────────────────────────────────────┐
> > │ │
> > │ │
> > SyncE in connector │ ┌─────────┐ │ SyncE out connector
> > ┌───┐ │in pin 1 │DPLL_1 │ out pin 1│ ┌───┐
> > │ ├─────────┼──────────────┤ ├──────────────┼────┤ │
> > │ │ │ │ │ │ │ │
> > └───┘ │ │ │ │ └───┘
> > │ │ │ │
> > │ ┌──┤ │ │
> > GNSS in connector │ │ └─────────┘ │
> > ┌───┐ │in pin 2 │ out pin 2│ EXT SMA connector
> > │ ├─────────┼───────────┘ │ ┌───┐
> > │ │ │ ┌───────────┼────┤ │
> > └───┘ │ │ │ │ │
> > │ │ │ └───┘
> > │ │ │
> > EXT SMA connector │ │ │
> > ┌───┐ mux │in pin 3 ┌─────────┐ │ │
> > │ ├────┬────┼───────────┐ │ │ │ │
> > │ │ │ │ │ │DPLL_2 │ │ │
> > └───┘ │ │ │ │ │ │ │
> > │ │ └──┤ ├──┘ │
> > │ │ │ │ │
> > EXT SMA connector │ │ │ │ │
> > ┌───┐ │ │ │ │ │
> > │ ├────┘ │ └─────────┘ │
> > │ │ │ │
> > └───┘ └───────────────────────────────────────┘
> >
> > Do I get that remotelly correct?
>
> It looks goot, hence two corrections are needed:
> - all inputs can go to all DPLLs, and a single source can drive more
> than one DPLL
> - The external mux for SMA connector should not be a part of the
> Synchronizer subsystem - I believe there's already a separate MUX
> subsystem in the kernel and all external connections should be handled
> by a devtree or a similar concept.
>
> The only "muxing" thing that could potentially be modeled is a
> synchronizer output to synchronizer input relation. Some synchronizers
> does that internally and can use the output of one DPLL as a source for
> another.
My experience with DT and muxes is rapidly aging, have you worked with
those recently? From what I remember the muxes were really.. "embedded"
and static compared to what we want here.
Using DT may work nicely for defining the topology, but for config we
still need a different mechanism.
> > synch
> > synchronizer_register(synch)
> > dpll_1
> > synchronizer_dpll_register(synch, dpll_1)
> > dpll_2
> > synchronizer_dpll_register(synch, dpll_2)
> > source_pin_1
> > synchronizer_pin_register(synch, source_pin_1)
> > output_pin_1
> > synchronizer_pin_register(synch, output_pin_1)
> > output_pin_2
> > synchronizer_pin_register(synch, output_pin_2)
> >
> > synch_board
> > synchronizer_board_register(synch_board)
> > synch
> > synchronizer_board_sync_register(synch_board, synch)
> > source_connector_1
> > synchronizer_board_connector_register(synch_board, source_connector_1, source_pin_1)
> > output_connector_1
> > synchronizer_board_connector_register(synch_board, output_connector_1, output_pin_1)
> > output_connector_2
> > synchronizer_board_connector_register(synch_board, output_connector_2, output_pin_2)
>
> I'd rather not use pins at all - just stick to sources and outputs. Both
> can use some labels to be identifiable.
TBH I can't comprehend your suggestion.
IIUC you want an object for a source, but my brain can't handle
modeling an external object. For instance the source could be GNSS,
but this is not the GNSS subsystem. We have a pin connected to GNSS,
not the GNSS itself.
Maybe a diagram would help?
Powered by blists - more mailing lists