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: <DM6PR11MB4657E51AD937BBA5DC2B1FF19BFF9@DM6PR11MB4657.namprd11.prod.outlook.com> Date: Tue, 10 Jan 2023 10:54:20 +0000 From: "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@...el.com> To: Jiri Pirko <jiri@...nulli.us> CC: Jakub Kicinski <kuba@...nel.org>, Maciek Machnikowski <maciek@...hnikowski.net>, 'Vadim Fedorenko' <vfedorenko@...ek.ru>, 'Jonathan Lemon' <jonathan.lemon@...il.com>, 'Paolo Abeni' <pabeni@...hat.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org> Subject: RE: [RFC PATCH v4 0/4] Create common DPLL/clock configuration API >From: Jiri Pirko <jiri@...nulli.us> >Sent: Monday, January 9, 2023 5:30 PM > >Mon, Jan 09, 2023 at 03:43:01PM CET, arkadiusz.kubalewski@...el.com wrote: >>>From: Jiri Pirko <jiri@...nulli.us> >>>Sent: Monday, December 12, 2022 2:59 PM >>> >>>Fri, Dec 09, 2022 at 05:31:04PM CET, kuba@...nel.org wrote: >>>>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. >>> >>>Why do you think we need something "non-static"? The mux is part of the >>>board, isn't it? That sounds quite static to me. >>> >>> >>>> >>>>Using DT may work nicely for defining the topology, but for config we >>>>still need a different mechanism. >>> >>>"config" of what? Each item in topology would be configure according to >>>the item type, won't it? >>> >>>[...] >> >> >>Hi guys, >> >>We have been trying to figure out feasibility of new approach proposed on >our >>latest meeting - to have a single object which encapsulates multiple >DPLLs. >> >>Please consider following example: >> >>Shared common inputs: >>i0 - GPS / external >>i1 - SMA1 / external >>i2 - SMA2 / external >>i3 - MUX0 / clk recovered from PHY0.X driven by MAC0 >>i4 - MUX1 / clk recovered from PHY1.X driven by MAC1 >> >>+---------------------------------------------------------+ >>| Channel A / FW0 +---+ | >>| i0--| | | >>| +---+ | | | >>| PHY0.0--| | i1--| D | | >>| | | | P | | >>| PHY0.1--| M | i2--| L | +---+ +--------+ | >>| | U | | L |---| |---| PHY0.0 |--| >>| PHY0.2--| X |-+---------i3--| 0 | | | +--------+ | >>| | 0 | |+------+ | |---| M |---| PHY0.1 |--| >>| ... --| | || MUX1 |-i4--| | | A | +--------+ | >>| | | |+------+ +---+ | C |---| PHY0.2 |--| >>| PHY0.7--| | | i0--| | | 0 | +--------+ | >>| +---+ | | |---| |---| ... |--| >>| | i1--| D | | | +--------+ | >>| | | P |---| |---| PHY0.7 |--| >>| | i2--| L | +---+ +--------+ | >>| | | L | | >>| \---------i3--| 1 | | >>| +------+ | | | >>| | MUX1 |-i4--| | | >>| +------+ +---+ | >>+---------------------------------------------------------+ >>| Channel B / FW1 +---+ | >>| i0--| | | >>| | | | >>| i1--| D | | >>| +---+ | P | | >>| PHY1.0--| | i2--| L | +---+ +--------+ | >>| | | +------+ | L |---| |---| PHY1.0 |--| >>| PHY1.1--| M | | MUX0 |-i3--| 0 | | | +--------+ | >>| | U | +------+ | |---| M |---| PHY1.1 |--| >>| PHY1.2--| X |-+---------i4--| | | A | +--------+ | >>| | 1 | | +---+ | C |---| PHY1.2 |--| >>| ... --| | | i0--| | | 1 | +--------+ | >>| | | | | |---| |---| ... |--| >>| PHY1.7--| | | i1--| D | | | +--------+ | >>| +---+ | | P |---| |---| PHY1.7 |--| >>| | i2--| L | +---+ +--------+ | >>| |+------+ | L | | >>| || MUX0 |-i3--| 1 | | >>| |+------+ | | | >>| \---------i4--| | | >>| +---+ | >>+---------------------------------------------------------+ > >What is "a channel" here? Are these 2 channels part of the same physival >chip? Could you add the synchronizer chip/device entities to your drawing? > No. A "Synchronization Channel" on a switch would allow to separate groups of physical ports. Each channel/group has own "Synchronizer Chip", which is used to drive PHY clocks of that group. "Synchronizer chip" would be the 2 DPLLs on old draw, something like this: +--------------------------------------------------------------+ | Channel A / FW0 +-------------+ +---+ +--------+ | | i0--|Synchronizer0|---| |---| PHY0.0 |--| | +---+ | | | | +--------+ | | PHY0.0--| | i1--| |---| M |---| PHY0.1 |--| | | | | +-----+ | | A | +--------+ | | PHY0.1--| M | i2--| |DPLL0| | | C |---| PHY0.2 |--| | | U | | +-----+ | | 0 | +--------+ | | PHY0.2--| X |--+---i3--| +-----+ |---| |---| ... |--| | | 0 | | | |DPLL1| | | | +--------+ | | ... --| | | /-i4--| +-----+ |---| |---| PHY0.7 |--| | | | | | +-------------+ +---+ +--------+ | | PHY0.7--| | | | | | +---+ | | | +----------------|-|-------------------------------------------+ | Channel B / FW1| | +-------------+ +---+ +--------+ | | | | i0--|Synchronizer1|---| |---| PHY1.0 |--| | +---+ | | | | | | +--------+ | | PHY1.0--| | | | i1--| |---| M |---| PHY1.1 |--| | | | | | | +-----+ | | A | +--------+ | | PHY1.1--| M | | | i2--| |DPLL0| | | C |---| PHY1.2 |--| | | U | | | | +-----+ | | 1 | +--------+ | | PHY1.2--| X | \-|-i3--| +-----+ |---| |---| ... |--| | | 1 | | | |DPLL1| | | | +--------+ | | ... --| |----+-i4--| +-----+ |---| |---| PHY1.7 |--| | | | +-------------+ +---+ +--------+ | | PHY1.7--| | | | +---+ | +--------------------------------------------------------------+ Also, please keep in mind that is an example, there could be easily 4 (or more) channels wired similarly. > >> >>This is a simplified network switch board example. >>It has 2 synchronization channels, where each channel: >>- provides clk to 8 PHYs driven by separated MAC chips, >>- controls 2 DPLLs. >> >>Basically only given FW has control over its PHYs, so also a control over >it's >>MUX inputs. >>All external sources are shared between the channels. >> >>This is why we believe it is not best idea to enclose multiple DPLLs with >one >>object: >>- sources are shared even if DPLLs are not a single synchronizer chip, >>- control over specific MUX type input shall be controllable from >different >>driver/firmware instances. >> >>As we know the proposal of having multiple DPLLs in one object was a try >to >>simplify currently implemented shared pins. We fully support idea of >having >>interfaces as simple as possible, but at the same time they shall be >flexible >>enough to serve many use cases. >> >>Right now the use case of single "synchronizer chip" is possible (2 DPLLs >with >>shared inputs), as well as multiple synchronizer chips with shared inputs. >> >>If we would entirely get rid of sharing pins idea and instead allowed only >to >>have multiple DPLLs in one object, we would fall back to the problem where >>change on one input is braking another "synchronizer chip" input. >>I.e. considering above scheme, user configured both channels to use SMA1 >1MHz. >>If SMA1 input is changed to 10MHz, all DPLLs are affected, thus all using >that > >You say "SMA1 input *is changed*". Could you add to your drawing: >1) Who is the one triggering the change. >2) Entity that manages the SMA input and applies the configuration. > A user or some tool, this change requires to switch a frequency on a signal generator connected to that SMA1. Whatever would make the change is an external entity here. The draw show connections on board, don't see a point on having a external signal generator or user connected to the board :) If something is not clear, we could prepare some different draw, please just let me know what exactly we want to see. It sound like a sequence diagram? Thanks! Arkadiusz > >>input shall be notified, as long as that input is shared. >>For the drivers that have single point of control over dpll, they might >just >>skip those requests. But if there are multiple firmware instances >controlling >>multiple DPLLs, they would process it independently. >> >>Current implementation is the most flexible and least complex for the >level of >>flexibility it provides. >> >>BR, Happy new year! >>Arkadiusz
Powered by blists - more mailing lists