Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751866AbdHBWum (ORCPT ); Wed, 2 Aug 2017 18:50:42 -0400 Received: from avon.wwwdotorg.org ([104.237.132.123]:41264 "EHLO avon.wwwdotorg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751750AbdHBWul (ORCPT ); Wed, 2 Aug 2017 18:50:41 -0400 Subject: Re: [PATCH 2/2] i2c: mux: pinctrl: drop the idle_state member To: Peter Rosin Cc: linux-kernel@vger.kernel.org, Wolfram Sang , Stephen Warren , linux-i2c@vger.kernel.org References: <20170802072728.24586-1-peda@axentia.se> <20170802072728.24586-3-peda@axentia.se> <15488723-e0ef-62b3-e62f-e74d12d8328d@wwwdotorg.org> From: Stephen Warren Message-ID: Date: Wed, 2 Aug 2017 16:50:35 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1067 Lines: 29 On 08/02/2017 03:25 PM, Peter Rosin wrote: > On 2017-08-02 21:06, Stephen Warren wrote: >> On 08/02/2017 01:27 AM, Peter Rosin wrote: >>> The information is available elsewhere. >> >>> diff --git a/drivers/i2c/muxes/i2c-mux-pinctrl.c b/drivers/i2c/muxes/i2c-mux-pinctrl.c >> >>> static int i2c_mux_pinctrl_deselect(struct i2c_mux_core *muxc, u32 chan) >>> { >>> + return i2c_mux_pinctrl_select(muxc, muxc->num_adapters); >>> } >> >>> @@ -166,7 +162,7 @@ static int i2c_mux_pinctrl_probe(struct platform_device *pdev) >> >>> /* Do not add any adapter for the idle state (if it's there at all). */ >>> - for (i = 0; i < num_names - !!mux->state_idle; i++) { >>> + for (i = 0; i < num_names - !!muxc->deselect; i++) { >> >> I think that "num_names - !!muxc->deselect" could just be >> muxc->num_adapters? > > Not really, it's the i2c_mux_add_adapter call in the loop that bumps > muxc->num_adapters, so the loop would not be entered. Not desirable :-) Ok, that makes sense. > (and muxc->max_adapters == num_names) Well, unless muxc->deselect is true...