From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751088AbdEaXYZ (ORCPT ); Wed, 31 May 2017 19:24:25 -0400 Received: from mga02.intel.com ([134.134.136.20]:40279 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750898AbdEaXYY (ORCPT ); Wed, 31 May 2017 19:24:24 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,276,1493708400"; d="scan'208";a="268719083" Reply-To: sathyanarayanan.kuppuswamy@linux.intel.com Subject: Re: [PATCH v1 1/1] mux: mux-intel-usb: Add Intel USB Multiplexer driver References: <84e3fdaf979c070a5c39c7635910fee30c3a8b06.1496104447.git.sathyanarayanan.kuppuswamy@linux.intel.com> <0e2a3df8-e3b4-28d3-eea9-5ec6a684bf53@linux.intel.com> <2ca23e5a-af13-f6f5-7c94-0af36acff6a3@axentia.se> <1c57c881-3885-dca5-b202-07f71a7dc936@redhat.com> <47f64eaa-9985-542c-1845-c7b8aaf81f70@axentia.se> To: Peter Rosin , Hans de Goede , Andy Shevchenko Cc: "Krogerus, Heikki" , "linux-kernel@vger.kernel.org" , Sathyanarayanan Kuppuswamy Natarajan From: sathyanarayanan kuppuswamy Organization: Intel Message-ID: Date: Wed, 31 May 2017 16:21:00 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <47f64eaa-9985-542c-1845-c7b8aaf81f70@axentia.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/31/2017 08:30 AM, Peter Rosin wrote: > On 2017-05-31 16:18, Hans de Goede wrote: >> Hi, >> >> On 31-05-17 15:05, Peter Rosin wrote: >>> On 2017-05-31 14:21, Hans de Goede wrote: >>>> actually this is the first time I hear about a mux framework >>>> at all. Is there a git tree with the patches for this somewhere ? >>> https://gitlab.com/peda-linux/mux.git in the "mux" branch. >>> >>> Series posted here: >>> https://lkml.org/lkml/2017/5/14/160 >> Thank you. >> >> I see that mux_control_get() currently relies on devicetree describing >> the mux, that is not going to work on non devicetree platforms like >> x86 where the relation typically is not described ad all (*) ? > Yes, I'm aware of this. I wanted to keep things simple. Also, see > my reply on the other branch of this discussion. > > https://lkml.org/lkml/2017/5/31/58 > >> Typically there would be a global list of mux_controls maintained >> by mux_[de]register and then mux_control_get() would walk this list >> until it finds a matching name. The names to register would then be >> passed in by platform data/code when registering and likewise the >> consumer would be passed a unique name to pass into mux_control_get() >> through platform data / code, would that work for you ? >> >> Note one option would be to set the names to use when registering >> a mux chip through device_properties, this is what the power-supply >> subsys is currently doing more or less. > I had this lose plan to match by the struct device name, but if that > is not working the above seems fine too... By device name do you mean mux chip device name or the mux platform device name ? If you mean former, since you are using ID framework, mux chip device name changes dynamically. So we can't use a static name to identify this device from other drivers. > > Cheers, > peda > -- Sathyanarayanan Kuppuswamy Linux kernel developer