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 46D7DC77B7F for ; Tue, 16 May 2023 06:27:02 +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=ApNTJpmb+U0zM/34gaEZb/OAbHr5LMAOvgbgnqGJCC0=; b=nCAucgAw9Ma+7r yORB/6b0dsRmHbgG5n+Jv+vOiZVmrY15bFjOAUb50b2Lo9jDM4QQadY28v/juOwVjkIoXV/8oLaqd HftNf11WCW5k6GhZaiYsTeKm7prA1HyY229kpVb1Pbs3cyJzG94KJL1jdNObeNisnzMs3gEkAHlZI lEYaBDhLgdERYIQVVmZGVaZhoui06aOF/Y/6ugu5SuGjHgtK2e2ojxq3xTHD7vfIAZ8rOh4eFFfgJ 8KfYjwtYI6i1uuah6Enfozh1PMC4+HmKMZ55Hm8sYXs7aslktprqckgLhFPM4C0LfIPOroKW+ppBB PSxeOI9SYvvH/IrHGYmg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pyo8s-004Vhk-1t; Tue, 16 May 2023 06:26:38 +0000 Received: from mail-ed1-x530.google.com ([2a00:1450:4864:20::530]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pyo8n-004Vh1-30 for linux-arm-kernel@lists.infradead.org; Tue, 16 May 2023 06:26:36 +0000 Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-50bc2feb320so20907995a12.3 for ; Mon, 15 May 2023 23:26:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20221208.gappssmtp.com; s=20221208; t=1684218389; x=1686810389; 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=Ncnk5u25n1gKhMi5UjBgWgY2AR5TG5mfySIQXV43uLs=; b=Kpf7UzvzzxHh5bvV+R50ESbrX1kVXjvfxkNVibVXDJtGAxWpS101Rz44PC3CFQKUee MbPbEX4/cAq1acTDSZnM3k911WeRpfekjBt62onyIfjBgtuSZcHwvzbyHSfn91Y2Wyyg rIWlPvtCtFF/z0fggAO2rPmfJKLHnVTcfNJ1+1PvZx+YRNndB1J26YQ/yHXWXdcb77LU tUo8ACRChqXD9dCbKGlVKdrSVj7Wi8QgYGW5Y1ER1OB76eO+I+CLXfbm+zHo3+Esc9tE L2X6Hoa3CCIIzFbRe3A9odykqRsD2CpOfkoIDkb9RjscYGgLLf2um9ZbJm38ka50TBD2 mnqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684218389; x=1686810389; 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=Ncnk5u25n1gKhMi5UjBgWgY2AR5TG5mfySIQXV43uLs=; b=jWXj264OAbuqZLfwdbWO0MwhhZzJhlxFbaniOBX5X6nwgLjCxNqOdGIooQPUckp3RD DE803ZSd1c43hyqgrv55Qkksl/lD+rs4xfuYr+bDWcXwfEwmyxS5Gqirl6oIiPsZc175 661qkHzogyWIEjJQFzMa5W+gFvXK5SH6i0i1/QS6B7+juROAJHc9eVfeCsCWSVCq+/x4 PHy+bxMiuKyj4pgL+W93s8ID/epLlJBJ2JqHJKT4xMiKXEB5ruUnb5m4ATGocXkesBM5 yn2PEut6gE8OeT4U1S7kqW/29PKVy5ALk1l7Zj6TnTkjO64NbqOC8Gf7zTy1ZB6MnhsX oYJg== X-Gm-Message-State: AC+VfDxcUicEsgEpeldBB/nHgv5YW6FHDMEzustla6S7VTZrrEM8Szgt TmBDeyAPHYvpWJX62KX3cxnTxA== X-Google-Smtp-Source: ACHHUZ4T0YNJLV13EFOWH4PksgAdo38fAvy+qD8boms/O8jp2/miH61xuB9s88pWcSdObsm+kMYFZQ== X-Received: by 2002:a17:907:60d6:b0:957:1df0:9cbf with SMTP id hv22-20020a17090760d600b009571df09cbfmr37389568ejc.19.1684218389369; Mon, 15 May 2023 23:26:29 -0700 (PDT) Received: from localhost (host-213-179-129-39.customer.m-online.net. [213.179.129.39]) by smtp.gmail.com with ESMTPSA id a23-20020a1709065f9700b0096a3d346d6asm8170826eju.211.2023.05.15.23.26.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 May 2023 23:26:28 -0700 (PDT) Date: Tue, 16 May 2023 08:26:27 +0200 From: Jiri Pirko To: "Kubalewski, Arkadiusz" Cc: Vadim Fedorenko , Jakub Kicinski , Jonathan Lemon , Paolo Abeni , "Olech, Milena" , "Michalik, Michal" , "linux-arm-kernel@lists.infradead.org" , poros , mschmidt , "netdev@vger.kernel.org" , "linux-clk@vger.kernel.org" Subject: Re: [RFC PATCH v7 5/8] ice: implement dpll interface to control cgu Message-ID: References: <20230428002009.2948020-1-vadfed@meta.com> <20230428002009.2948020-6-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-20230515_232634_191913_7AA1C8C6 X-CRM114-Status: GOOD ( 23.10 ) 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 Tue, May 16, 2023 at 12:07:57AM CEST, arkadiusz.kubalewski@intel.com wrote: >>From: Jiri Pirko >>Sent: Wednesday, May 3, 2023 2:19 PM >> >>Fri, Apr 28, 2023 at 02:20:06AM CEST, vadfed@meta.com wrote: >>>From: Arkadiusz Kubalewski [...] >>>+ * ice_dpll_frequency_set - wrapper for pin callback for set frequency >>>+ * @pin: pointer to a pin >>>+ * @pin_priv: private data pointer passed on pin registration >>>+ * @dpll: pointer to dpll >>>+ * @frequency: frequency to be set >>>+ * @extack: error reporting >>>+ * @pin_type: type of pin being configured >>>+ * >>>+ * Wraps internal set frequency command on a pin. >>>+ * >>>+ * Return: >>>+ * * 0 - success >>>+ * * negative - error pin not found or couldn't set in hw */ static >>>+int ice_dpll_frequency_set(const struct dpll_pin *pin, void *pin_priv, >>>+ const struct dpll_device *dpll, >>>+ const u32 frequency, >>>+ struct netlink_ext_ack *extack, >>>+ const enum ice_dpll_pin_type pin_type) { >>>+ struct ice_pf *pf = pin_priv; >>>+ struct ice_dpll_pin *p; >>>+ int ret = -EINVAL; >>>+ >>>+ if (!pf) >>>+ return ret; >>>+ if (ice_dpll_cb_lock(pf)) >>>+ return -EBUSY; >>>+ p = ice_find_pin(pf, pin, pin_type); >> >>This does not make any sense to me. You should avoid the lookups and remove >>ice_find_pin() function entirely. The purpose of having pin_priv is to >>carry the struct ice_dpll_pin * directly. You should pass it down during >>pin register. >> >>pf pointer is stored in dpll_priv. >> > >In this case dpll_priv is not passed, so cannot use it. It should be passed. In general to every op where *dpll is passed, the dpll_priv pointer should be passed along. Please, fix this. >But in general it makes sense I will hold pf inside of ice_dpll_pin >and fix this. Nope, just use dpll_priv. That's why we have it. [...] >>>+/** >>>+ * ice_dpll_pin_state_set - set pin's state on dpll >>>+ * @dpll: dpll being configured >>>+ * @pin: pointer to a pin >>>+ * @pin_priv: private data pointer passed on pin registration >>>+ * @state: state of pin to be set >>>+ * @extack: error reporting >>>+ * @pin_type: type of a pin >>>+ * >>>+ * Set pin state on a pin. >>>+ * >>>+ * Return: >>>+ * * 0 - OK or no change required >>>+ * * negative - error >>>+ */ >>>+static int >>>+ice_dpll_pin_state_set(const struct dpll_device *dpll, >>>+ const struct dpll_pin *pin, void *pin_priv, >>>+ const enum dpll_pin_state state, >> >>Why you use const with enums? >> > >Just show usage intention explicitly. Does not make any sense what so ever. Please avoid it. >>>+static int ice_dpll_rclk_state_on_pin_get(const struct dpll_pin *pin, >>>+ void *pin_priv, >>>+ const struct dpll_pin *parent_pin, >>>+ enum dpll_pin_state *state, >>>+ struct netlink_ext_ack *extack) { >>>+ struct ice_pf *pf = pin_priv; >>>+ u32 parent_idx, hw_idx = ICE_DPLL_PIN_IDX_INVALID, i; >> >>Reverse christmas tree ordering please. > >Fixed. > >> >> >>>+ struct ice_dpll_pin *p; >>>+ int ret = -EFAULT; >>>+ >>>+ if (!pf) >> >>How exacly this can happen. My wild guess is it can't. Don't do such >>pointless checks please, confuses the reader. >> > >>From driver perspective the pf pointer value is given by external entity, >why shouldn't it be valdiated? What? You pass it during register, you get it back here. Nothing to check. Please drop it. Non-sense checks like this have no place in kernel, they only confuse reader as he/she assumes it is a valid case. [...] >> >> >>>+ pins[i].pin = NULL; >>>+ return -ENOMEM; >>>+ } >>>+ if (cgu) { >>>+ ret = dpll_pin_register(pf->dplls.eec.dpll, >>>+ pins[i].pin, >>>+ ops, pf, NULL); >>>+ if (ret) >>>+ return ret; >>>+ ret = dpll_pin_register(pf->dplls.pps.dpll, >>>+ pins[i].pin, >>>+ ops, pf, NULL); >>>+ if (ret) >>>+ return ret; >> >>You have to call dpll_pin_unregister(pf->dplls.eec.dpll, pins[i].pin, ..) >>here. >> > >No, in case of error, the caller releases everything ice_dpll_release_all(..). How does ice_dpll_release_all() where you failed? If you need to unregister one or both or none? I know that in ice you have odd ways to handle error paths in general, but this one clearly seems to be broken. > >> >>>+ } >>>+ } >>>+ if (cgu) { >>>+ ops = &ice_dpll_output_ops; >>>+ pins = pf->dplls.outputs; >>>+ for (i = 0; i < pf->dplls.num_outputs; i++) { >>>+ pins[i].pin = dpll_pin_get(pf->dplls.clock_id, >>>+ i + pf->dplls.num_inputs, >>>+ THIS_MODULE, &pins[i].prop); >>>+ if (IS_ERR_OR_NULL(pins[i].pin)) { >>>+ pins[i].pin = NULL; >>>+ return -ENOMEM; >> >>Don't make up error values when you get them from the function you call: >> return PTR_ERR(pins[i].pin); > >Fixed. > >> >>>+ } >>>+ ret = dpll_pin_register(pf->dplls.eec.dpll, pins[i].pin, >>>+ ops, pf, NULL); >>>+ if (ret) >>>+ return ret; >>>+ ret = dpll_pin_register(pf->dplls.pps.dpll, pins[i].pin, >>>+ ops, pf, NULL); >>>+ if (ret) >>>+ return ret; >> >>You have to call dpll_pin_unregister(pf->dplls.eec.dpll, pins[i].pin, ..) >>here. >> > >As above, in case of error, the caller releases everything. As above, I don't think it works. [...] >>>+ } >>>+ >>>+ if (cgu) { >>>+ ret = dpll_device_register(pf->dplls.eec.dpll, DPLL_TYPE_EEC, >>>+ &ice_dpll_ops, pf, dev); >>>+ if (ret) >>>+ goto put_pps; >>>+ ret = dpll_device_register(pf->dplls.pps.dpll, DPLL_TYPE_PPS, >>>+ &ice_dpll_ops, pf, dev); >>>+ if (ret) >> >>You are missing call to dpll_device_unregister(pf->dplls.eec.dpll, >>DPLL_TYPE_EEC here. Fix the error path. >> > >The caller shall do the clean up, but yeah will fix this as here clean up >is not expected. :) Just make your error paths obvious and easy to follow to not to confuse anybody, you included. > >> >>>+ goto put_pps; >>>+ } >>>+ >>>+ return 0; >>>+ >>>+put_pps: >>>+ dpll_device_put(pf->dplls.pps.dpll); >>>+ pf->dplls.pps.dpll = NULL; >>>+put_eec: >>>+ dpll_device_put(pf->dplls.eec.dpll); >>>+ pf->dplls.eec.dpll = NULL; >>>+ >>>+ return ret; >>>+} [...] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel