On 2017-07-08 23:22, Andy Shevchenko wrote: > On Sat, Jul 8, 2017 at 9:12 PM, > <[email protected]> wrote: >> From: Kuppuswamy Sathyanarayanan <[email protected]> >> >> Add dummy functions to avoid compile time issues when CONFIG_MULTIPLEXER >> is not enabled. >> > > I don't think the error return code is okay to all of them. The return > value should be choosen carefully (for some functions it's okay IMO to > return 0).
BTW, is ENODEV correct for this situation? I have this nagging feeling that ENODEV is over-used? And again, all these stubs should all be inlines, or things will break it this file is included more than once. >> Signed-off-by: Kuppuswamy Sathyanarayanan >> <[email protected]> >> --- >> include/linux/mux/consumer.h | 38 ++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 38 insertions(+) >> >> Changes since v1: >> * Changed #ifdef to #if IS_ENABLED. >> >> diff --git a/include/linux/mux/consumer.h b/include/linux/mux/consumer.h >> index 5577e1b..df78988 100644 >> --- a/include/linux/mux/consumer.h >> +++ b/include/linux/mux/consumer.h >> @@ -16,6 +16,7 @@ >> struct device; >> struct mux_control; >> >> +#if IS_ENABLED(CONFIG_MULTIPLEXER) >> unsigned int mux_control_states(struct mux_control *mux); >> int __must_check mux_control_select(struct mux_control *mux, >> unsigned int state); >> @@ -29,4 +30,41 @@ void mux_control_put(struct mux_control *mux); >> struct mux_control *devm_mux_control_get(struct device *dev, >> const char *mux_name); >> >> +#else >> +unsigned int mux_control_states(struct mux_control *mux) >> +{ >> + return -ENODEV; > > Peter, is here we are obliged to return error code in such case? Since it will presumably be difficult to obtain a mux_control w/o the mux-core being present, it doesn't matter much what most of these stubs return. For this stub, 0 is perhaps best, since the kernel-doc for mux_control_states mentions nothing about any error possibility. >> +} >> + >> +int __must_check mux_control_select(struct mux_control *mux, >> + unsigned int state) >> +{ >> + return -ENODEV; > > return 0; ? Maybe. But it doesn't matter much, but in this case the consumer must handle errors. See above. >> +} >> + >> +int __must_check mux_control_try_select(struct mux_control *mux, >> + unsigned int state) >> +{ >> + return -ENODEV; >> +} > > return 0; ? Maybe. But it doesn't matter much, but in this case the consumer must handle errors. See above. >> + >> +int mux_control_deselect(struct mux_control *mux) >> +{ >> + return -ENODEV; >> +} > > return 0; ? Probably. See above. Cheers, peda >> + >> +struct mux_control *mux_control_get(struct device *dev, const char >> *mux_name) >> +{ >> + return ERR_PTR(-ENODEV); >> +} >> + >> +void mux_control_put(struct mux_control *mux) {} >> + >> +struct mux_control *devm_mux_control_get(struct device *dev, >> + const char *mux_name) >> +{ >> + return ERR_PTR(-ENODEV); >> +} >> +#endif >> + >> #endif /* _LINUX_MUX_CONSUMER_H */ >> -- >> 2.7.4 >> > > >
