Subject: Re: [PATCH v1 1/1] mux: consumer: Add dummy functions for
 !CONFIG_MULTIPLEXER case
To: "Kuppuswamy, Sathyanarayanan" <sathyaosid@gmail.com>,
        sathyanarayanan.kuppuswamy@linux.intel.com
Cc: linux-kernel@vger.kernel.org
References: <b401a6875042aa54f739403605ecaf30c9997aeb.1499463614.git.sathyanarayanan.kuppuswamy@linux.intel.com>
 <fe9f5e79-a415-e880-feb3-3a4eaa4ae4cb@axentia.se>
 <1bd098de-312e-d75e-0089-93848c12481c@gmail.com>
From: Peter Rosin <peda@axentia.se>
Organization: Axentia Technologies AB
Message-ID: <c94b90f2-2b56-8209-df55-3bd7ca30f90d@axentia.se>
Date: Mon, 10 Jul 2017 07:32:13 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <1bd098de-312e-d75e-0089-93848c12481c@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jul 2017 05:32:16.9885 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0202MB2554
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1684
Lines: 37

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.kuppuswamy@linux.intel.com wrote:
>>> From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@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