Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752084AbdGHX2T (ORCPT ); Sat, 8 Jul 2017 19:28:19 -0400 Received: from mail-pf0-f195.google.com ([209.85.192.195]:33490 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751817AbdGHX2R (ORCPT ); Sat, 8 Jul 2017 19:28:17 -0400 Subject: Re: [PATCH v1 1/1] mux: Add new API to get mux_control ref by device name. To: Andy Shevchenko , Peter Rosin , "Krogerus, Heikki" Cc: Kuppuswamy Sathyanarayanan , "linux-kernel@vger.kernel.org" References: <08b3c179-6e58-73c7-5221-4b9b12d7ea9c@axentia.se> From: "Kuppuswamy, Sathyanarayanan" Message-ID: Date: Sat, 8 Jul 2017 16:28:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1649 Lines: 34 Hi Andy, On 7/8/2017 2:26 PM, Andy Shevchenko wrote: > On Sun, Jul 9, 2017 at 12:12 AM, Peter Rosin wrote: >> On 2017-07-08 00:03, sathyanarayanan.kuppuswamy@linux.intel.com wrote: >>> From: Kuppuswamy Sathyanarayanan >>> >>> 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. >