From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751192AbdEaOSW (ORCPT ); Wed, 31 May 2017 10:18:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:21655 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751131AbdEaOSN (ORCPT ); Wed, 31 May 2017 10:18:13 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com CE5F33B71C Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hdegoede@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com CE5F33B71C 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> From: Hans de Goede Message-ID: <1c57c881-3885-dca5-b202-07f71a7dc936@redhat.com> Date: Wed, 31 May 2017 16:18:10 +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: <2ca23e5a-af13-f6f5-7c94-0af36acff6a3@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.30]); Wed, 31 May 2017 14:18:13 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 (*) ? 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. Regards, Hans *) Work is under way to allow describing topologies in ACPI but it is not in the standard yet, and we also need to deal with already existing devices. > > Cheers, > peda >