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 D12E0C76196 for ; Sat, 1 Apr 2023 12:54:33 +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=ToPvsFg3ASqcjVThcH0WrhSMxPOLC+Bawz12lm/fPNI=; b=wgfKwG/9e5c2mc 94dVpCg+NIpr8njqW/hFrX2hVXTYU179rzIE121dK+BAl3H7tOBvD9T/up9i194BImtZduyZkVwJL FDXZ7KnG+r+kxmB5jt4bTzAKHxm0yw+AM5CvyrAYLBgTM0ob8PqxDfc3sS47dhXMoYJKBQDx09QAS SU6+tQM0kh6t/20j1vS96hebcfe89GmOA4vTbQFj/HvzbrxfFZR3s/J/anhdCTNgIUl5lbkfhdX3m GumiLipV7jaBx1u6aFuEe4xm5xNbMDygDOsKKDkkaxuTOUg9NwVUrSPpUcyOq/z3p1ZEGfx3t+Tka TymMMSpeqYDHM35KZVjg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1piajn-00AY0g-0O; Sat, 01 Apr 2023 12:53:43 +0000 Received: from mail-ed1-x535.google.com ([2a00:1450:4864:20::535]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1piajj-00AXzg-01 for linux-arm-kernel@lists.infradead.org; Sat, 01 Apr 2023 12:53:41 +0000 Received: by mail-ed1-x535.google.com with SMTP id b20so100159547edd.1 for ; Sat, 01 Apr 2023 05:53:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20210112.gappssmtp.com; s=20210112; t=1680353617; 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=IsXudeJf7ex/KMkd9XKZrKSgXi5k8V6Ttiz3EATGpHg=; b=aEyF2EFqPsdk0bwXMo5zmj7q77sIpNvMQ0J1s5h/QDOyoI7rPgOkDNb4mSO3rxJKhO R1nwP1io/pqkC4+gLFnMxczK7arE13+14mgfLVoLH9AEZQLwBeFkDZtk7XLWdtlrwvFz 2w39nql083wFUEvKtzSjMTLwLj761DinO2OLxcyp28m2+UzozNw5ZOMgSjJVBsGxmdx2 nnTiget7yOpQ3qydH/FzPx9nLPtDLnM7SGm+nyuYw4d+ht+8D1HJpRTZeTT2VSqvVFAO RkqOmX2eZXIncAVKWCk/CLb4k4Y/DFqCr0TEd4wBfZcKZG9UT6UNnTx4VCTnSic86xn1 27+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680353617; 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=IsXudeJf7ex/KMkd9XKZrKSgXi5k8V6Ttiz3EATGpHg=; b=oiiKHpCLhp+nz2XCMg2llHrV+nWeAfzcUSoXE/mb1HezBy5xLiOfHcbtjXBTI5PkvE AKFfB3h0aCgFBAC/7tVT/txglOvISfUac5hgsXBOu7l3CWbWTQU/7fSTX4hNEZPdNXmq V71nagqLXi79pUczu0uuYFKAkj35olFZp0lIzl9oi2HI6XSdkni81318Px/YJFMeFUxP IuanW1aGVxDt85YbqMA/2MQIXDqBUwJtC45Jj2wnCBSgwZ2uvPvAUm8DK9gOGYiysgQz 7StlF4fruYwLLripnakDsYz3GTYYMtJfn1rIP5C+hX0LjeQqcfuK6h7T38Y0ma1G4d5o 1xAw== X-Gm-Message-State: AAQBX9ehK0rfU+SpxRCPoRaPQlWINSvAKxyIruezGB0LjyIn4gdRJOtU gW3xQ30kgtBaDwcNAc/gVPk08g== X-Google-Smtp-Source: AKy350av/v61Im2E/iRFPy8cHyBemO9SfGylTKdV/Xz+fFW+bDVWlyYIfaz89gnHfK5k4p/j/jRthw== X-Received: by 2002:aa7:da82:0:b0:502:100c:53a with SMTP id q2-20020aa7da82000000b00502100c053amr30460055eds.41.1680353616865; Sat, 01 Apr 2023 05:53:36 -0700 (PDT) Received: from localhost ([86.61.181.4]) by smtp.gmail.com with ESMTPSA id b17-20020a50b411000000b004bf7905559asm2093952edh.44.2023.04.01.05.53.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 01 Apr 2023 05:53:36 -0700 (PDT) Date: Sat, 1 Apr 2023 14:53:35 +0200 From: Jiri Pirko To: Vadim Fedorenko Cc: Vadim Fedorenko , Jakub Kicinski , Arkadiusz Kubalewski , Jonathan Lemon , Paolo Abeni , poros@redhat.com, mschmidt@redhat.com, netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org Subject: Re: [PATCH RFC v6 6/6] ptp_ocp: implement DPLL ops Message-ID: References: <20230312022807.278528-1-vadfed@meta.com> <20230312022807.278528-7-vadfed@meta.com> 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-20230401_055340_262329_0A179FDB X-CRM114-Status: GOOD ( 23.11 ) 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 Sat, Apr 01, 2023 at 01:28:29AM CEST, vadim.fedorenko@linux.dev wrote: >On 15.03.2023 12:24, Jiri Pirko wrote: >> Wed, Mar 15, 2023 at 01:10:33AM CET, vadim.fedorenko@linux.dev wrote: >> > On 14/03/2023 10:05, Jiri Pirko wrote: >> > > Sun, Mar 12, 2023 at 03:28:07AM CET, vadfed@meta.com wrote: [...] >> > > > +static int ptp_ocp_dpll_pin_to_sma(const struct ptp_ocp *bp, const struct dpll_pin *pin) >> > > > +{ >> > > > + int i; >> > > > + >> > > > + for (i = 0; i < 4; i++) { >> > > > + if (bp->sma[i].dpll_pin == pin) >> > > > + return i; >> > > >> > > Just pass &bp->sma[i] as a priv to dpll_pin_register(). >> > > and get that pointer directly in pin ops. No need for lookup and use of >> > > sma_nr at all. >> > >> > I'm still thinking about the change that you proposed to remove these >> > _priv() helpers. I have to look into ice code to be sure we won't break >> > any assumptions in it with moving to additional (void *) parameter. >> >> There are basically 2 ways: >> someop(struct subsystemobj *x, void *priv) >> { >> struct *mine = priv; >> } >> or: >> someop(struct subsystemobj *x) >> { >> struct *mine = subsystem_get_priv(x); >> } >> >> Both are more or less equal. The first has benefit that the caller most >> usually has direct access to the priv, so it can just easily pass it on. >> Also, you as the driver write see right away there is a priv arg and >> makes you want to use it and not figure out odd lookups to get to the >> same priv. > >Thinking about this part. We have tons of parameters for some ops already. >Adding void *priv to every one of them (and actually two for pins) makes them >even more ugly. Let's stay with helpers if you don't have strong opinion >against. Well, with the patches I sent when 1 device/pin can be registered multiple times with multiple privs, I believe it is much more feasable to just pass the priv along in the arg list, because otherwise you would have to do some odd lookup. Please pass priv, would be nicer and easier and more simple for the driver to implement. The arg list can handle that easily. [...] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel