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 1D29EC77B61 for ; Mon, 10 Apr 2023 21:25:28 +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=sFUgOIlFR3q8th3uAYETEDipIFnkoWtHagcTn4fkzh4=; b=OGDOa9ijz9w3lF iwgRTzpvdVgCf6/nTnQmhnnaVAAfHJQn0o4bvOLEaPJVvZj2+3K7C18bGOxJkvB5xWlFrn6mEu8/+ MEU9Su7eZlqLDP+lahBWdg6e9hnWOTO6dS61Cy6sO43V/gxoJ9B934VIiysX+q/q0siLsG6OFqBHC YaDAIq2d2T6QULmfg6Qql6zxiq/gKPIURvxTTPA/UxiY0SESlgl2p97s3fy4zcU28hwDByeszEkED Pr2fBi+42IUDXWOJJ7OeyMYwQ+I4jYn7qbBpgeunrWkeUwBbHsHKnOemyWqHxZACH2VR8xoy4dGtX cCfmRRtlQIH4Oah6Zffw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1plz06-00Fxp4-0j; Mon, 10 Apr 2023 21:24:34 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1plz03-00Fxob-0E for linux-arm-kernel@lists.infradead.org; Mon, 10 Apr 2023 21:24:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1681161868; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=guIPUS4b/KI5jRIGt0RS4kaJQ4UcCDM9VQ9qZvewB+Q=; b=BfqpFF2zXOWyGwNcj8ooUjwRs1YtJGoVJRsmdR3oArqUOoZz9gXgiLZsMPbDuRA4/em/Lt OfBPnS7pCc1m9XcUG0bJgNKaj53zlQQ9Jvn8GOMfTdpOLWxFWhwySoPBYX9zzdf7m/xGKF Dp2QcdawAbR4X9ssld+7e+4nkHa2dK0= Received: from mail-oa1-f70.google.com (mail-oa1-f70.google.com [209.85.160.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-654-qycjQ8aFPhyTdh-2ZY56zQ-1; Mon, 10 Apr 2023 17:24:26 -0400 X-MC-Unique: qycjQ8aFPhyTdh-2ZY56zQ-1 Received: by mail-oa1-f70.google.com with SMTP id 586e51a60fabf-1842d4a3112so3716963fac.13 for ; Mon, 10 Apr 2023 14:24:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681161866; 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=guIPUS4b/KI5jRIGt0RS4kaJQ4UcCDM9VQ9qZvewB+Q=; b=tHk6tSC4zUv+FnHoIqLBmZlus6+eqjRGVSKHSTZfnz7abOkVOV2hAVJJKy1LPtUIjL +18pd9cIFpzjCmQwsjgs0x8oQLUrjTIXtWCs5+x/klfIalt4/hTqiqwNKomm1D/3wTmp hOnxDZDexTBE4MdzuosReVB/3v21yi4rY2Fq7JGMsdXTabqIo0YC7dcts7evQY7QvO1g eJcZuBtZpvrI5YEuB9UzjiqLqYaE2SEcgNYMB5IhV/SUmX6npJNHB4YY+99OcjSTDkiH HxRNH1HqaOsb9RlKQ+/w7nNdUXXUdFsxDcz0J1UCkXgWxnYnPKHy6czqYkisK67Aqaoh 8zZA== X-Gm-Message-State: AAQBX9eX0n2nzMo+35q1/ahuOhhcN8GLFaABeh2402VHmTt+jYcIl9GM LFpQCMp/zMZGZt/W9l8/nR9tvR9o3wMxidnDcAAGJU6/LA8MH0/jevLSkfQufEjv1O0mh+Ez2qG /JP2HDx/JMPDmW6HxhssJPugzdMWuVT9X4gs= X-Received: by 2002:a05:6808:1a27:b0:38b:c1b4:6af9 with SMTP id bk39-20020a0568081a2700b0038bc1b46af9mr2735752oib.4.1681161866118; Mon, 10 Apr 2023 14:24:26 -0700 (PDT) X-Google-Smtp-Source: AKy350bgc7ZX4XjpSwPu1lYDObg75z6mEqgIGHBCnCkz1NdyheSPE+5IoVPpSan2LLi+1tqeOtiR4Q== X-Received: by 2002:a05:6808:1a27:b0:38b:c1b4:6af9 with SMTP id bk39-20020a0568081a2700b0038bc1b46af9mr2735718oib.4.1681161865851; Mon, 10 Apr 2023 14:24:25 -0700 (PDT) Received: from halaney-x13s (104-53-165-62.lightspeed.stlsmo.sbcglobal.net. [104.53.165.62]) by smtp.gmail.com with ESMTPSA id w127-20020a4a5d85000000b00525398a1144sm5117502ooa.32.2023.04.10.14.24.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Apr 2023 14:24:25 -0700 (PDT) Date: Mon, 10 Apr 2023 16:24:22 -0500 From: Andrew Halaney To: Simon Horman Cc: linux-kernel@vger.kernel.org, agross@kernel.org, andersson@kernel.org, konrad.dybcio@linaro.org, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, vkoul@kernel.org, bhupesh.sharma@linaro.org, wens@csie.org, jernej.skrabec@gmail.com, samuel@sholland.org, mturquette@baylibre.com, peppe.cavallaro@st.com, alexandre.torgue@foss.st.com, joabreu@synopsys.com, mcoquelin.stm32@gmail.com, richardcochran@gmail.com, linux@armlinux.org.uk, veekhee@apple.com, tee.min.tan@linux.intel.com, mohammad.athari.ismail@intel.com, jonathanh@nvidia.com, ruppala@nvidia.com, bmasney@redhat.com, andrey.konovalov@linaro.org, linux-arm-msm@vger.kernel.org, netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, ncai@quicinc.com, jsuraj@qti.qualcomm.com, hisunil@quicinc.com, echanude@redhat.com Subject: Re: [PATCH net-next v3 08/12] net: stmmac: Pass stmmac_priv in some callbacks Message-ID: <20230410212422.2rztlqspw5vjtb4d@halaney-x13s> References: <20230331214549.756660-1-ahalaney@redhat.com> <20230331214549.756660-9-ahalaney@redhat.com> <20230407173453.hsfhbr66254z57ym@halaney-x13s> MIME-Version: 1.0 In-Reply-To: <20230407173453.hsfhbr66254z57ym@halaney-x13s> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230410_142431_206998_D91DED36 X-CRM114-Status: GOOD ( 24.02 ) 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 On Fri, Apr 07, 2023 at 12:34:53PM -0500, Andrew Halaney wrote: > On Sat, Apr 01, 2023 at 05:06:21PM +0200, Simon Horman wrote: > > On Fri, Mar 31, 2023 at 04:45:45PM -0500, Andrew Halaney wrote: > > > Passing stmmac_priv to some of the callbacks allows hwif implementations > > > to grab some data that platforms can customize. Adjust the callbacks > > > accordingly in preparation of such a platform customization. > > > > > > Signed-off-by: Andrew Halaney > > > > ... > > > > > #define stmmac_reset(__priv, __args...) \ > > > @@ -223,59 +240,59 @@ struct stmmac_dma_ops { > > > #define stmmac_dma_init(__priv, __args...) \ > > > stmmac_do_void_callback(__priv, dma, init, __args) > > > #define stmmac_init_chan(__priv, __args...) \ > > > - stmmac_do_void_callback(__priv, dma, init_chan, __args) > > > + stmmac_do_void_callback(__priv, dma, init_chan, __priv, __args) > > > > Hi Andrew, > > > > Rather than maintaining these macros can we just get rid of them? > > I'd be surprised if things aren't nicer with functions in their place [1]. > > > > f.e., we now have (__priv, ..., __priv, ...) due to a generalisation > > that seems to take a lot more than it gives. > > > > [1] https://lore.kernel.org/linux-arm-kernel/ZBst1SzcIS4j+t46@corigine.com/ > > > > Thanks for the pointer. I think that makes sense, I'll take that > approach for these functions (and maybe in a follow-up series I'll > tackle all of them just because the lack of consistency will eat me up). > I tried taking this approach for a spin, and I'm not so sure about it now! 1. Implementing the functions as static inline requires us to know about stmmac_priv, but that's getting into circular dependency land 2. You could define them in hwif.c, but then they're not inlined 3. There's still a good bit of boilerplate that's repeated all over with the approach. Ignoring 1 above, you get something like this: static inline int stmmac_init_chan(struct stmmac_priv *priv, void __iomem *ioaddr, struct stmmac_dma_cfg *dma_cfg, u32 chan) { if (priv->hw->dma && priv->hw->dma->init_chan) { priv->hw->dma->init_chan(priv, ioaddr, dma_cfg, chan); return 0; } return -EINVAL; } that is then repeated for every function... which is making me actually appreciate the macros some for reducing boilerplate. Am I suffering from a case of holiday brain, and 1-3 above are silly points with obvious answers, or do they make you reconsider continuing with the current approach in hwif.h? Thanks, Andrew _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel