From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751129AbdEaXc5 (ORCPT ); Wed, 31 May 2017 19:32:57 -0400 Received: from mga06.intel.com ([134.134.136.31]:13321 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750954AbdEaXc4 (ORCPT ); Wed, 31 May 2017 19:32:56 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,276,1493708400"; d="scan'208";a="93407383" 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> <703e0320-46ef-a2e2-6c15-ef090d1e843a@redhat.com> To: Hans de Goede , Peter Rosin , 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:29:32 -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: <703e0320-46ef-a2e2-6c15-ef090d1e843a@redhat.com> 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 Hi, On 05/31/2017 11:27 AM, Hans de Goede wrote: > Hi, > > On 31-05-17 17:30, 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. > > Ok, good. > >> 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... > > There are 2 problems with using dev_name() : > > 1) dev_name() will be coupled to the mux_chip and one mux_chip may > have multiple controllers (you could add a number postfix to work > around this) I think maintaining unique mux control names across all mux devices will be bit difficult to maintain. Unless its auto created as Hans mentioned using device name + chip index + control index. or , we can have unique names for mux-chips and get mux-control handles based on index numbers. This should at least reduce some of the search time. mux_control_get("mux chip name", index) > > > 2) The caller of mux_control_get() wants a fixed name, where as > dev_name is not always fixed, e.g. with mux-chips which communicate > via i2c it is something like 7-0064 where 7 is the i2c bus-number > which depends on probe ordering and thus may not even be the same > every boot. > > Regards, > > Hans > > > -- Sathyanarayanan Kuppuswamy Linux kernel developer