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:   Fri, 7 Apr 2023 12:34:53 -0500
From:   Andrew Halaney <ahalaney@...hat.com>
To:     Simon Horman <simon.horman@...igine.com>
Cc:     linux-kernel@...r.kernel.org, agross@...nel.org,
        andersson@...nel.org, konrad.dybcio@...aro.org,
        davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
        pabeni@...hat.com, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, vkoul@...nel.org,
        bhupesh.sharma@...aro.org, wens@...e.org, jernej.skrabec@...il.com,
        samuel@...lland.org, mturquette@...libre.com,
        peppe.cavallaro@...com, alexandre.torgue@...s.st.com,
        joabreu@...opsys.com, mcoquelin.stm32@...il.com,
        richardcochran@...il.com, linux@...linux.org.uk, veekhee@...le.com,
        tee.min.tan@...ux.intel.com, mohammad.athari.ismail@...el.com,
        jonathanh@...dia.com, ruppala@...dia.com, bmasney@...hat.com,
        andrey.konovalov@...aro.org, linux-arm-msm@...r.kernel.org,
        netdev@...r.kernel.org, devicetree@...r.kernel.org,
        linux-stm32@...md-mailman.stormreply.com,
        linux-arm-kernel@...ts.infradead.org, ncai@...cinc.com,
        jsuraj@....qualcomm.com, hisunil@...cinc.com, echanude@...hat.com
Subject: Re: [PATCH net-next v3 08/12] net: stmmac: Pass stmmac_priv in some
 callbacks

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 <ahalaney@...hat.com>
> 
> ...
> 
> >  #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).

Sorry for the delay, had some issues around the house that became
urgent.

Thanks,
Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ