public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Serge Semin <fancer.lancer@gmail.com>
To: Peter Rosin <peda@axentia.se>
Cc: Peter Korsgaard <peter.korsgaard@barco.com>,
	Serge Semin <Sergey.Semin@t-platforms.ru>,
	"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/5] i2c-mux-gpio: Save initial channel number to the idle data field
Date: Thu, 25 Apr 2019 18:53:26 +0300	[thread overview]
Message-ID: <20190425155325.voqlrmbdblo7xhtx@mobilestation> (raw)
In-Reply-To: <7c8d4751-f5f7-ee2a-c411-a985b81d61a3@axentia.se>

On Wed, Apr 24, 2019 at 09:26:22PM +0000, Peter Rosin wrote:
> On 2019-04-24 14:34, Serge Semin wrote:
> > In case if the idle state has been specified in the data structure,
> > the idle variable is left untouched as before, so to keep a default
> > channel number enabled in the mux idle state. But if a platform doesn't
> > specify which channel is going to be enabled by default, we as before
> > don't setup the deselect callback, but the initial state is saved in the
> > idle variable for further initialization. We can safely do this here
> > since that variable is used for initial state setting only, when no
> > idling lane is specified.
> 
> While this subtlety is *maybe* ok, a comment about it belongs in the
> *code* where it will be seen when the next person makes changes.
> 
> But why not extend the struct with the initial state? How many of
> these muxes do you expect to exist in a system? Multiplied by a
> couple of bytes. Who cares?
> 

I actually thought about this when started working on the patchset.
That time saving the initial value in the idle variable seemed like a
good idea. I even put a small comment in the code about this.

Anyway lets add a new field to "struct gpiomux" structure and use
it as a container for initial value. It is also a good alternative.
I'll do this in a v2 patchset.

-Sergey

> Cheers,
> Peter
> 
> > 
> > The reason of this change is to prepare the code for future GPIOs request
> > path being split up into of- and plat- based methods. The idle variable
> > here is used as a container of the initial state for both of the paths in
> > case of idle-channel isn't specified.
> > 
> > Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
> > ---
> >  drivers/i2c/muxes/i2c-mux-gpio.c | 15 ++++++++-------
> >  1 file changed, 8 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/i2c/muxes/i2c-mux-gpio.c b/drivers/i2c/muxes/i2c-mux-gpio.c
> > index a14fe132b0c3..535c83c43371 100644
> > --- a/drivers/i2c/muxes/i2c-mux-gpio.c
> > +++ b/drivers/i2c/muxes/i2c-mux-gpio.c
> > @@ -171,7 +171,6 @@ static int i2c_mux_gpio_probe(struct platform_device *pdev)
> >  	struct gpiomux *mux;
> >  	struct i2c_adapter *parent;
> >  	struct i2c_adapter *root;
> > -	unsigned initial_state;
> >  	int i, ret;
> >  
> >  	mux = devm_kzalloc(&pdev->dev, sizeof(*mux), GFP_KERNEL);
> > @@ -204,12 +203,14 @@ static int i2c_mux_gpio_probe(struct platform_device *pdev)
> >  
> >  	muxc->mux_locked = true;
> >  
> > -	if (mux->data.idle != I2C_MUX_GPIO_NO_IDLE) {
> > -		initial_state = mux->data.idle;
> > +	/*
> > +	 * Set descelect callback if idle state has been setup otherwise just
> > +	 * use the idle variable to store the initial muxer value.
> > +	 */
> > +	if (mux->data.idle != I2C_MUX_GPIO_NO_IDLE)
> >  		muxc->deselect = i2c_mux_gpio_deselect;
> > -	} else {
> > -		initial_state = mux->data.values[0];
> > -	}
> > +	else
> > +		mux->data.idle = mux->data.values[0];
> >  
> >  	for (i = 0; i < mux->data.n_gpios; i++) {
> >  		struct device *gpio_dev;
> > @@ -224,7 +225,7 @@ static int i2c_mux_gpio_probe(struct platform_device *pdev)
> >  		}
> >  
> >  		ret = gpio_direction_output(mux->gpio_base + mux->data.gpios[i],
> > -					    initial_state & (1 << i));
> > +					    mux->data.idle & (1 << i));
> >  		if (ret) {
> >  			dev_err(&pdev->dev,
> >  				"Failed to set direction of GPIO %d to output\n",
> > 
> 

  reply	other threads:[~2019-04-25 15:53 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-24 12:34 [PATCH 0/5] i2c-mux-gpio: Split plat- and dt-specific code up Serge Semin
2019-04-24 12:34 ` [PATCH 1/5] i2c-mux-gpio: Unpin a platform-based device initialization Serge Semin
2019-04-24 12:34 ` [PATCH 2/5] i2c-mux-gpio: Return an error if no config data found Serge Semin
2019-04-24 21:25   ` Peter Rosin
2019-04-25 15:47     ` Serge Semin
2019-04-25 19:28       ` Peter Rosin
2019-04-25 20:09         ` Serge Semin
2019-04-24 12:34 ` [PATCH 3/5] i2c-mux-gpio: Save initial channel number to the idle data field Serge Semin
2019-04-24 21:26   ` Peter Rosin
2019-04-25 15:53     ` Serge Semin [this message]
2019-04-25 19:32       ` Peter Rosin
2019-04-24 12:34 ` [PATCH 4/5] i2c-mux-gpio: Unpin the platform-specific GPIOs request code Serge Semin
2019-04-24 12:34 ` [PATCH 5/5] i2c-mux-gpio: Create of-based GPIOs request method Serge Semin
2019-04-24 21:27   ` Peter Rosin
2019-04-24 21:25 ` [PATCH 0/5] i2c-mux-gpio: Split plat- and dt-specific code up Peter Rosin
2019-04-25 14:37   ` Serge Semin
2019-04-25 19:21     ` Peter Rosin
2019-04-25 20:03       ` Serge Semin
2019-04-25 23:20 ` [PATCH v2 0/3] " Serge Semin
2019-04-25 23:20   ` [PATCH v2 1/3] i2c-mux-gpio: Unpin a platform-based device initialization Serge Semin
2019-06-09 20:51     ` Peter Rosin
2019-04-25 23:20   ` [PATCH v2 2/3] i2c-mux-gpio: Unpin the platform-specific GPIOs request code Serge Semin
2019-06-09 21:34     ` Peter Rosin
2019-06-14 16:31       ` Serge Semin
2019-06-14 18:04         ` Peter Rosin
2019-06-14 21:58           ` Serge Semin
2019-04-25 23:20   ` [PATCH v2 3/3] i2c-mux-gpio: Create of-based GPIOs request method Serge Semin
2019-05-07  9:02   ` [PATCH v2 0/3] i2c-mux-gpio: Split plat- and dt-specific code up Serge Semin
2019-05-07  9:17     ` Peter Rosin
2019-05-07  9:46       ` Serge Semin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190425155325.voqlrmbdblo7xhtx@mobilestation \
    --to=fancer.lancer@gmail.com \
    --cc=Sergey.Semin@t-platforms.ru \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peda@axentia.se \
    --cc=peter.korsgaard@barco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox