From: Peter Rosin <peda@axentia.se>
To: "Kuppuswamy, Sathyanarayanan" <sathyaosid@gmail.com>,
sathyanarayanan.kuppuswamy@linux.intel.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 1/1] mux: consumer: Add dummy functions for !CONFIG_MULTIPLEXER case
Date: Mon, 10 Jul 2017 07:32:13 +0200 [thread overview]
Message-ID: <c94b90f2-2b56-8209-df55-3bd7ca30f90d@axentia.se> (raw)
In-Reply-To: <1bd098de-312e-d75e-0089-93848c12481c@gmail.com>
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
prev parent reply other threads:[~2017-07-10 5:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-07 21:41 sathyanarayanan.kuppuswamy
2017-07-08 15:32 ` kbuild test robot
2017-07-08 20:55 ` Peter Rosin
2017-07-08 23:04 ` Kuppuswamy, Sathyanarayanan
2017-07-10 5:32 ` Peter Rosin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c94b90f2-2b56-8209-df55-3bd7ca30f90d@axentia.se \
--to=peda@axentia.se \
--cc=linux-kernel@vger.kernel.org \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=sathyaosid@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®