From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751125AbdEaS1f (ORCPT ); Wed, 31 May 2017 14:27:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58772 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751004AbdEaS1e (ORCPT ); Wed, 31 May 2017 14:27:34 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 640C43DA3EE Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hdegoede@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 640C43DA3EE Subject: Re: [PATCH v1 1/1] mux: mux-intel-usb: Add Intel USB Multiplexer driver To: Peter Rosin , Andy Shevchenko , Kuppuswamy Sathyanarayanan Cc: "Krogerus, Heikki" , "linux-kernel@vger.kernel.org" , Sathyanarayanan Kuppuswamy Natarajan 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> From: Hans de Goede Message-ID: <703e0320-46ef-a2e2-6c15-ef090d1e843a@redhat.com> Date: Wed, 31 May 2017 20:27:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.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-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 31 May 2017 18:27:33 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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) 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