Re: [PATCH RFC 08/13] dmaengine: sdxi: Context creation/removal, descriptor submission

[Jonathan Cameron <jonathan.cameron@huawei.com>]

> >> +static const char *cxt_sts_state_str(enum cxt_sts_state state)
> >> +{
> >> +	static const char *const context_states[] = {
> >> +		[CXTV_STOP_SW]  = "stopped (software)",
> >> +		[CXTV_RUN]      = "running",
> >> +		[CXTV_STOPG_SW] = "stopping (software)",
> >> +		[CXTV_STOP_FN]  = "stopped (function)",
> >> +		[CXTV_STOPG_FN] = "stopping (function)",
> >> +		[CXTV_ERR_FN]   = "error",
> >> +	};
> >> +	const char *str = "unknown";
> >> +
> >> +	switch (state) {
> >> +	case CXTV_STOP_SW:
> >> +	case CXTV_RUN:
> >> +	case CXTV_STOPG_SW:
> >> +	case CXTV_STOP_FN:
> >> +	case CXTV_STOPG_FN:
> >> +	case CXTV_ERR_FN:
> >> +		str = context_states[state];  
> >
> > I'd do a default to make it explicit that there are other states. If
> > there aren't then just return here and skip the return below. A
> > compiler should be able to see if you handled them all and complain
> > loudly if a new one is added that you haven't handled.  
> 
> The CXTV_... values are the only valid states that an SDXI device is
> allowed to report for a context, but this function is intended to be
> resilient against unspecified values in case of implementation bugs (in
> the caller, or firmware, whatever). That's why it falls back to
> returning "unknown".
> 
> But it's coded without a default label so that -Wswitch (which is
> enabled by -Wall and so is generally active for kernel code) will warn
> on an unhandled case. The presence of a default label will actually
> defeat this unless the compiler is invoked with -Wswitch-enum, which
> even W=1 doesn't enable.
> 
> I really do want warnings on unhandled cases of this sort, so I suppose
> at the very least this code deserves a comment to deter well-meaning
> people from trying to add a default label. Or I could add the default
> label and see how painful it is to use -Wswitch-enum throughout the
> driver. There are several similar functions in the error reporting code
> so this isn't the only instance of this pattern in the driver.

Thanks for the response. Makes sense.

J