netdev - Re: [PATCH 09/11] ice: implement dpll interface to control cgu

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: Mon, 31 Jul 2023 14:08:03 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Paolo Abeni <pabeni@...hat.com>
Cc: Jakub Kicinski <kuba@...nel.org>,
	"Kubalewski, Arkadiusz" <arkadiusz.kubalewski@...el.com>,
	Vadim Fedorenko <vadim.fedorenko@...ux.dev>,
	Jonathan Lemon <jonathan.lemon@...il.com>,
	"Olech, Milena" <milena.olech@...el.com>,
	"Michalik, Michal" <michal.michalik@...el.com>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	poros <poros@...hat.com>, mschmidt <mschmidt@...hat.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
	Bart Van Assche <bvanassche@....org>
Subject: Re: [PATCH 09/11] ice: implement dpll interface to control cgu

Wed, Jul 26, 2023 at 05:20:12PM CEST, pabeni@...hat.com wrote:
>On Tue, 2023-07-25 at 15:49 -0700, Jakub Kicinski wrote:
>> On Fri, 21 Jul 2023 14:02:08 +0200 Jiri Pirko wrote:
>> > So it is not a mode! Mode is either "automatic" or "manual". Then we
>> > have a state to indicate the state of the state machine (unlocked, locked,
>> > holdover, holdover-acq). So what you seek is a way for the user to
>> > expliticly set the state to "unlocked" and reset of the state machine.
>> 
>> +1 for mixing the state machine and config.
>> Maybe a compromise would be to rename the config mode?
>> Detached? Standalone?
>
>For the records, I don't know the H/W details to any extents, but
>generally speaking it sounds reasonable to me that a mode change could
>cause a state change.

The thing is, you don't need an extra mode just to "reset state". There
could be a command for it, staying under the same mode. That way, things
would be cleaner and obvious for the user.
case a)
AUTOMATIC MODE
user changes to FREERUN to reset state
user changes back to AUTOMATIC to continue

case b)
AUTOMATIC MODE
user submits state reset command


>
>e.g. switching an ethernet device autoneg mode could cause the link
>state to flip.
>
>So I'm ok with the existence of the freerun mode.
>
>I think it should be clarified what happens if pins are manually
>enabled in such mode. I expect ~nothing will change, but stating it

That is another very good point you touched. In the "freerun"
mode, the pins does not have any meaning.
The same you achieve with automatic mode, setting all pins to
disconnect.

If we have freerun mode, the core should sanitize all pins are
disconnect and stay disconnect. But do you see how ridiculous this is
becoming? :)


>clearly would help.
>
>Cheers,
>
>Paolo
>