[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ee71d80d-840c-a784-7fc7-a72b7cc2f453@wwwdotorg.org>
Date: Wed, 2 Aug 2017 16:50:35 -0600
From: Stephen Warren <swarren@...dotorg.org>
To: Peter Rosin <peda@...ntia.se>
Cc: linux-kernel@...r.kernel.org, Wolfram Sang <wsa@...-dreams.de>,
Stephen Warren <swarren@...dia.com>, linux-i2c@...r.kernel.org
Subject: Re: [PATCH 2/2] i2c: mux: pinctrl: drop the idle_state member
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...
Powered by blists - more mailing lists