From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4F802C001DC for ; Mon, 31 Jul 2023 12:08:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=5qDTFDaYsHwyLbdIoctxkPPbLCHFmxwJvSMbkhQsJQg=; b=fV0PfHHSPaEuK3 jVnldfFlatg88BhmDfVdt3xh7V+y+5Ls7H3v4Zg8ibNg/nqM6s8HAJLtVJ99t4RAsTNJryZuQX5LT COBbxU6nLokaNRCc/Tts83gWBywU+WchYQcNA5I3DjVB87KJMZILc9IC8Vt/7clPHK2R2DpQGjzgp PDi/8T++KJhdJMVYZG/syQofI5pQgLh8NWoIKhIbMsgj91iKaI45vUWGsPranRoR6utLEp68hZQAf hP8+3QwcAc3+OYuWsn5LHAQfL0LkmiiDUNS2E2DrMybiu6ZPIbgCC9n6I2SYZG3h4iyL0zaJE/Trg 1Ifm8Wd9C0+7/RvQfXPw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qQRhK-00FVi0-2N; Mon, 31 Jul 2023 12:08:26 +0000 Received: from mail-lf1-x134.google.com ([2a00:1450:4864:20::134]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qQRhG-00FVf1-1l for linux-arm-kernel@lists.infradead.org; Mon, 31 Jul 2023 12:08:24 +0000 Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-4fe0eb0ca75so7020623e87.2 for ; Mon, 31 Jul 2023 05:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20221208.gappssmtp.com; s=20221208; t=1690805286; x=1691410086; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=f+FNabLCPagoiMZfcH6abH6GfhwY3UwM4ct9KVUS0DI=; b=jpaoni1Vhyj7nVBeKlDzQa+jBMD8ppPsMoBs/c/Qi3krQa7eOwdoin1I0tzyUwG6Pd 84BbqhQ6RHQ3i+lrr0HDP6Nxs8oNRKIwGZ/09HASOTDyfnIu8fcXXR18+ex+ox3+sshu FJdC1XbIJCL7VjwYdAyEZlHi+jWHYWzUOLWjXqysOwMrbmPfmTY8fmoSgJFW5l36kUPY 3j43TWrPvZ25+UM3bloq7peFyzsZlGTizivoooiD3SabxDG/YNiECiCKyNVrv/4VUUto ZQ/M+9fiG0Upp1yr5E0YXl4PMVjEjSYVKpL7LZjVsV3mDNZu+8AaeipZhx5pohPErppJ r8LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690805286; x=1691410086; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=f+FNabLCPagoiMZfcH6abH6GfhwY3UwM4ct9KVUS0DI=; b=Jj9iW6YsEyNHfrWx3/DxcosqQ1pxK9VYdQHSsto7wHnFw9krM3V6GC2f3JbeGjuSjV 2Hk9pVn6B8bgTIOTvv0hKFPSXDkonlEYVqt8be9uMwFcQKUpKDvwclUWfx/st7/FcTR7 VM4pwhbR9QZofse4S2ZIjsUQ8haeD4068qaFmaIIguD5VBea037e0Xm/KlJahzDRE+Mg QZ01EzrU7Sqz+WXH/eZTdlTqKzv7mtf+tZUcRZU1mVXQuGmtzWvyqvSeUPKOX2dMFD0s g03Eq1RS9BxSuwz898Nvg1ef8PVA4iWWcZduc1LCayV3xUTT72UQ+BjpGzjZHthS5LgO PB1w== X-Gm-Message-State: ABy/qLbgXVt28UhOd//Q7ro2utKNVeJTFX/6EsSZ9/fABOp0lPGZNHYR oSibzsWLehcYIdfHGVEpk0BSQA== X-Google-Smtp-Source: APBJJlEus2CGrr2Q272FyfIIVE+Hs+kMt+44Yxs/jka8ImX2tluGcJSiyLjXJsvxV5HlwBSJvHtAYQ== X-Received: by 2002:a2e:9e46:0:b0:2b6:d0fc:ee18 with SMTP id g6-20020a2e9e46000000b002b6d0fcee18mr6254947ljk.19.1690805285743; Mon, 31 Jul 2023 05:08:05 -0700 (PDT) Received: from localhost ([212.23.236.67]) by smtp.gmail.com with ESMTPSA id u7-20020a170906408700b0098de7d28c34sm6052607ejj.193.2023.07.31.05.08.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 31 Jul 2023 05:08:04 -0700 (PDT) Date: Mon, 31 Jul 2023 14:08:03 +0200 From: Jiri Pirko To: Paolo Abeni Cc: Jakub Kicinski , "Kubalewski, Arkadiusz" , Vadim Fedorenko , Jonathan Lemon , "Olech, Milena" , "Michalik, Michal" , "linux-arm-kernel@lists.infradead.org" , poros , mschmidt , "netdev@vger.kernel.org" , "linux-clk@vger.kernel.org" , Bart Van Assche Subject: Re: [PATCH 09/11] ice: implement dpll interface to control cgu Message-ID: References: <20230720091903.297066-1-vadim.fedorenko@linux.dev> <20230720091903.297066-10-vadim.fedorenko@linux.dev> <20230725154958.46b44456@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230731_050822_582976_DEF3DC22 X-CRM114-Status: GOOD ( 19.43 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Wed, Jul 26, 2023 at 05:20:12PM CEST, pabeni@redhat.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 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel