On Sun, Jul 9, 2017 at 12:12 AM, Peter Rosin <peda@xxxxxxxxxx> wrote: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.
On 2017-07-08 00:03, sathyanarayanan.kuppuswamy@xxxxxxxxxxxxxxx wrote:Without Heikki's blessing, NAK for this activity.
From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@xxxxxxxxxxxxxxx>I assume this is for the Intel USB Multiplexer that you sent a driver for
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.
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?