Re: [PATCH net-next 3/3] net: ethernet: ti: cpsw_ale: Remove unused accessor functions

[Simon Horman <horms@kernel.org>]

On Thu, Sep 12, 2024 at 04:29:29PM +0300, Roger Quadros wrote:
> 
> 
> On 12/09/2024 14:27, Simon Horman wrote:
> > On Thu, Sep 12, 2024 at 01:54:45PM +0300, Roger Quadros wrote:
> >>
> >>
> >> On 12/09/2024 11:59, Simon Horman wrote:
> >>> On Thu, Sep 12, 2024 at 10:07:27AM +0300, Roger Quadros wrote:
> >>>> Hi Simon,
> >>>>
> >>>> On 10/09/2024 10:17, Simon Horman wrote:
> > 
> > ...
> > 
> >>>>>  	ALE_ENT_VID_MEMBER_LIST = 0,
> >>>>>  	ALE_ENT_VID_UNREG_MCAST_MSK,
> >>>>> @@ -217,14 +229,14 @@ static const struct ale_entry_fld vlan_entry_k3_cpswxg[] = {
> >>>>>  
> >>>>>  DEFINE_ALE_FIELD(entry_type,		60,	2)
> >>>>>  DEFINE_ALE_FIELD(vlan_id,		48,	12)
> >>>>> -DEFINE_ALE_FIELD(mcast_state,		62,	2)
> >>>>> +DEFINE_ALE_FIELD_SET(mcast_state,	62,	2)
> >>>>
> >>>> I don't understand why we need separate macros for GET and SET.
> >>>> The original intent was to use one macro for both.
> >>>>
> >>>> Otherwise we will have to add DEFINE_ALE_FIELD/1_SET to all the fields.
> >>>
> >>> Hi Roger,
> >>>
> >>> Sorry for not being clearer.
> >>>
> >>> My intent was to avoid declaring functions that are never used.
> >>> Perhaps it is best explained by some examples.
> >>>
> >>> In the case of mcast_state, the compiler flags that the get accessor is
> >>> never used. The intent is of this patch addresses that by declaring the set
> >>> accessor for mcast_state. Likewise for other similar cases.
> >>>
> >>> OTOH, in the case of, f.e. vlan_id, the set and get accessor functions are
> >>> both used, and DEFINE_ALE_FIELD continues to be used to define them both.
> >>> DEFINE_ALE_FIELD is implemented as the combination of _SET and _GET.
> >>>
> >>
> >> Thanks for the explanation Simon. I understand now.
> >>
> >> Would using __maybe_unused__ be preferable to get rid of the warnings?
> >> That way we don't need to care if both set/get helpers are used or not
> >> and don't have to touch the below code ever again except to add new fields.
> > 
> > Thanks Roger,
> > 
> > IMHO, it is nicer to not declare them at all.  But I do get your point and
> > I'm happy to try that approach if you prefer it.
> > 
> > ...
> 
> Simon,
> 
> I don't have any preference. I'll leave it to you to decide on your next spin. Thanks.

Thanks, let me think about it.

I'll probably hold off on v2 until the next the development cycle as
the patch queue seems busy enough this week.