Hi Andy,
On 7/8/2017 2:26 PM, Andy Shevchenko wrote:
On Sun, Jul 9, 2017 at 12:12 AM, Peter Rosin <[email protected]> wrote:
On 2017-07-08 00:03, [email protected] wrote:
From: Kuppuswamy Sathyanarayanan <[email protected]>
Currently this driver only provides a single API, mux_control_get() to
get mux_control reference based on mux_name, and also this API has tight
dependency on device tree node. For devices, that does not use device
tree, it makes it difficult to use this API. This patch adds new
API to access mux_control reference based on device name, chip index and
controller index value.
I assume this is for the Intel USB Multiplexer that you sent a driver for
a month or so ago? If so, you still have not answered these questions:
Is any other consumer in the charts at all? Can this existing consumer
ever make use of some other mux? If the answer to both those questions
are 'no', then I do not see much point in involving the mux subsystem at
all. The Broxton USB PHY driver could just as well write to the register
all by itself, no?
that I asked in https://lkml.org/lkml/2017/5/31/58
What is the point of that driver?
Without Heikki's blessing, NAK for this activity.
I dropped the idea of Intel USB MUX driver after my last discussion with
Hans. He is currently working on a solution for this issue. Once its
merged, May be I can try improving it handle my use cases.
But I submitted these changes because it can be useful if any one wants
to use MUX framework for non-dt case.
