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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 13 Oct 2022 08:17:25 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     Vadim Fedorenko <vfedorenko@...ek.ru>,
        Arkadiusz Kubalewski <arkadiusz.kubalewski@...el.com>,
        netdev@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-clk@...r.kernel.org, Vadim Fedorenko <vadfed@...com>
Subject: Re: [RFC PATCH v3 1/6] dpll: Add DPLL framework base functions

On Thu, 13 Oct 2022 08:55:34 +0200 Jiri Pirko wrote:
>> AFAIU, some mux devices are not smart enough to make a decision suitable for
>> autoselect for the pins they have. In this case the autoselect process is
>> done in the DPLL device, which selects mux and not the pin directly. At the
>> same time there could be muxes that are smart enough to make a decision, and
>> it will be autoselect on top of autoselect (and several more layers) and it
>> doesn't sound great to me. I believe Arkadiusz will explain the mux a bit
>> better.  
> 
> From what you write in this reply, I have a feeling that these details
> are not really interesting for user to see. So I tend to lean forward to
> abstract this out and leave the details to HW/FW/driver.

Are you saying we don't need to model MUXes?  Topology of the signals
imposes restrictions on the supported configuration, it's not something
you can "abstract out in the FW".

My thinking was we can let the user ignore it and have the core figure
out the configuration of the muxes if users asks for a pin behind a mux.
But it's better if the mux is visible so that it's clear which signals
can't be selected simultaneously. (IIRC Arkadiusz may have even had
muxes shared between DPLLs :S)

Anyway, I may just be confused about the state of the series because
most of the points you brought up were already discussed. I guess you
were right that off-list reviews are a bad idea :(

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ