On 2017-07-09 01:04, Kuppuswamy, Sathyanarayanan wrote: > Hi Peter, > > On 7/8/2017 1:55 PM, Peter Rosin wrote: >> On 2017-07-07 23:41, sathyanarayanan.kuppusw...@linux.intel.com wrote: >>> From: Kuppuswamy Sathyanarayanan >>> <sathyanarayanan.kuppusw...@linux.intel.com> >>> >>> Add dummy functions to avoid compile time issues when CONFIG_MULTIPLEXER >>> is not enabled. >> Hi! >> >> Consumers should "select MULTIPLEXER", > If their driver can't work without mux_* calls then you can make it > compulsory. But its not always true. >> so this does not make sense. >> Or do you have a driver that has an optional mux consumer? > I came across this case when I was working on Intel USB MUX driver. I > think you know the history behind it. Although I am not planning to > merge that driver now, but I think the use case is still valid.
Yeah, it's a valid use case. But why add a facility that noone uses? Sure, if there's an actual consumer that needs it. But there isn't... See, I have spent considerable time taking stuff like this out in order to get the thing merged at all. I even think I wrote dummy inlines like this at some point (but I'm not sure if I actually wrote them and I don't think I submitted them. But I did think about it, that's for sure). Anyway, I'm not very happy about ballooning the core with support for non-essentials just yet. Maybe my mind-set will change over time? (And no, I don't *know* the history behind the "Intel USB MUX driver", I e.g. never saw the consumer code. And I have the feeling that stuff were discussed in other threads that I was not part of and some (most?) questions I asked about it was left unanswered.) Cheers, peda