All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-iio@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	Fabio Estevam <fabio.estevam@freescale.com>,
	Jonathan Cameron <jic23@kernel.org>,
	Shawn Guo <shawn.guo@linaro.org>
Subject: Re: [PATCH 2/3 V2] iio: mxs: Implement support for touchscreen
Date: Thu, 10 Jan 2013 10:48:37 +0100	[thread overview]
Message-ID: <201301101048.38036.marex@denx.de> (raw)
In-Reply-To: <20130110005748.GA947@core.coreip.homeip.net>

Dear Dmitry Torokhov,

[...]
> > > +	enum mxs_lradc_ts	use_touchscreen;
> > > +	unsigned int		stop_touchscreen:1;
> > > +	unsigned int		use_touchbutton:1;
> 
> Can we make them bools instead of bit fields?

Sure.
[...]

> > > +static void mxs_lradc_ts_close(struct input_dev *dev)
> > > +{
> > > +	struct mxs_lradc *lradc = input_get_drvdata(dev);
> > > +
> > > +	/* Indicate the touchscreen is stopping. */
> > > +	lradc->stop_touchscreen = 1;
> > > +
> > > +	/* Disable touchscreen touch-detect IRQ. */
> > > +	writel(LRADC_CTRL1_TOUCH_DETECT_IRQ_EN,
> > > +		lradc->base + LRADC_CTRL1 + STMP_OFFSET_REG_CLR);
> > > +
> > > +	/* Power-down touchscreen touch-detect circuitry. */
> > > +	writel(LRADC_CTRL0_TOUCH_DETECT_ENABLE,
> > > +		lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_CLR);
> 
> These 2 writes are racing with writes in mxs_lradc_ts_work(). I think
> you need to:
> 
> 	lradc->stop_touchscreen = true;
> 	mb();

Nice catch, do we need the memory barrier here though, is it not enough to 
reorder the cancel_work_sync() just before the register writes?

> 	cancel_work_sync(&lradc->ts_work);
> 	writel(LRADC_CTRL1_TOUCH_DETECT_IRQ_EN,
> 		lradc->base + LRADC_CTRL1 + STMP_OFFSET_REG_CLR);
> 	...

[...]

> > > +	lradc->ts_input = input;
> > > +	input_set_drvdata(input, lradc);
> > > +	ret = input_register_device(input);
> > > +	if (ret)
> > > +		input_free_device(lradc->ts_input);
> > > +
> > > +	return ret;
> 
> So why is allocation failure is not fatal bur registration is? I'd make
> both fatal.

Since it's still possible to operate the block even if touchscreen fails to 
probe. If that happens, certainly something is already weird. I'd say both 
should be fatal.

> > > +}
> > > +
> > > +static void mxs_lradc_ts_unregister(struct mxs_lradc *lradc)
> > > +{
> > > +	if (!lradc->use_touchscreen)
> > > +		return;
> > > +
> > > +	if (!lradc->ts_input)
> > > +		return;
> 
> Do we really need to check both conditions?

Better safe than sorry, but lradc->ts_input should be non-NULL in case lradc-
>use_touchscreen is set, so I'll remove it.

[...]


WARNING: multiple messages have this Message-ID (diff)
From: marex@denx.de (Marek Vasut)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3 V2] iio: mxs: Implement support for touchscreen
Date: Thu, 10 Jan 2013 10:48:37 +0100	[thread overview]
Message-ID: <201301101048.38036.marex@denx.de> (raw)
In-Reply-To: <20130110005748.GA947@core.coreip.homeip.net>

Dear Dmitry Torokhov,

[...]
> > > +	enum mxs_lradc_ts	use_touchscreen;
> > > +	unsigned int		stop_touchscreen:1;
> > > +	unsigned int		use_touchbutton:1;
> 
> Can we make them bools instead of bit fields?

Sure.
[...]

> > > +static void mxs_lradc_ts_close(struct input_dev *dev)
> > > +{
> > > +	struct mxs_lradc *lradc = input_get_drvdata(dev);
> > > +
> > > +	/* Indicate the touchscreen is stopping. */
> > > +	lradc->stop_touchscreen = 1;
> > > +
> > > +	/* Disable touchscreen touch-detect IRQ. */
> > > +	writel(LRADC_CTRL1_TOUCH_DETECT_IRQ_EN,
> > > +		lradc->base + LRADC_CTRL1 + STMP_OFFSET_REG_CLR);
> > > +
> > > +	/* Power-down touchscreen touch-detect circuitry. */
> > > +	writel(LRADC_CTRL0_TOUCH_DETECT_ENABLE,
> > > +		lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_CLR);
> 
> These 2 writes are racing with writes in mxs_lradc_ts_work(). I think
> you need to:
> 
> 	lradc->stop_touchscreen = true;
> 	mb();

Nice catch, do we need the memory barrier here though, is it not enough to 
reorder the cancel_work_sync() just before the register writes?

> 	cancel_work_sync(&lradc->ts_work);
> 	writel(LRADC_CTRL1_TOUCH_DETECT_IRQ_EN,
> 		lradc->base + LRADC_CTRL1 + STMP_OFFSET_REG_CLR);
> 	...

[...]

> > > +	lradc->ts_input = input;
> > > +	input_set_drvdata(input, lradc);
> > > +	ret = input_register_device(input);
> > > +	if (ret)
> > > +		input_free_device(lradc->ts_input);
> > > +
> > > +	return ret;
> 
> So why is allocation failure is not fatal bur registration is? I'd make
> both fatal.

Since it's still possible to operate the block even if touchscreen fails to 
probe. If that happens, certainly something is already weird. I'd say both 
should be fatal.

> > > +}
> > > +
> > > +static void mxs_lradc_ts_unregister(struct mxs_lradc *lradc)
> > > +{
> > > +	if (!lradc->use_touchscreen)
> > > +		return;
> > > +
> > > +	if (!lradc->ts_input)
> > > +		return;
> 
> Do we really need to check both conditions?

Better safe than sorry, but lradc->ts_input should be non-NULL in case lradc-
>use_touchscreen is set, so I'll remove it.

[...]

  reply	other threads:[~2013-01-10 10:09 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-14  1:46 [PATCH 1/3 V2] iio: mxs: Remove unused struct mxs_lradc_chan Marek Vasut
2012-12-14  1:46 ` Marek Vasut
2012-12-14  1:46 ` [PATCH 2/3 V2] iio: mxs: Implement support for touchscreen Marek Vasut
2012-12-14  1:46   ` Marek Vasut
2012-12-14  1:58   ` Fabio Estevam
2012-12-14  1:58     ` Fabio Estevam
2012-12-14  2:04     ` Marek Vasut
2012-12-14  2:04       ` Marek Vasut
2012-12-19 17:01   ` Marek Vasut
2012-12-19 17:01     ` Marek Vasut
2012-12-27 12:16     ` Jonathan Cameron
2012-12-27 12:16       ` Jonathan Cameron
2013-01-08 19:28       ` Marek Vasut
2013-01-08 19:28         ` Marek Vasut
2013-01-09 20:01         ` Jonathan Cameron
2013-01-09 20:01           ` Jonathan Cameron
2013-01-09 20:17           ` Marek Vasut
2013-01-09 20:17             ` Marek Vasut
2013-01-09 21:38             ` Jonathan Cameron
2013-01-09 21:38               ` Jonathan Cameron
2013-01-09 21:54               ` Marek Vasut
2013-01-09 21:54                 ` Marek Vasut
2013-01-10  0:57     ` Dmitry Torokhov
2013-01-10  0:57       ` Dmitry Torokhov
2013-01-10  9:48       ` Marek Vasut [this message]
2013-01-10  9:48         ` Marek Vasut
2013-01-10 17:46         ` Dmitry Torokhov
2013-01-10 17:46           ` Dmitry Torokhov
2013-01-10 18:19           ` Lars-Peter Clausen
2013-01-10 18:19             ` Lars-Peter Clausen
2013-01-10 18:44             ` Dmitry Torokhov
2013-01-10 18:44               ` Dmitry Torokhov
2012-12-27 11:31   ` Jonathan Cameron
2012-12-27 11:31     ` Jonathan Cameron
     [not found]     ` <50DC319B.1050607-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2012-12-27 18:19       ` Marek Vasut
2012-12-27 18:19         ` Marek Vasut
2012-12-27 18:19         ` Marek Vasut
2012-12-14  1:46 ` [PATCH 3/3] iio: mxs: Enable touchscreen on m28evk Marek Vasut
2012-12-14  1:46   ` Marek Vasut
2012-12-27 11:25 ` [PATCH 1/3 V2] iio: mxs: Remove unused struct mxs_lradc_chan Jonathan Cameron
2012-12-27 11:25   ` Jonathan Cameron

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=201301101048.38036.marex@denx.de \
    --to=marex@denx.de \
    --cc=dmitry.torokhov@gmail.com \
    --cc=fabio.estevam@freescale.com \
    --cc=jic23@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=shawn.guo@linaro.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.