Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_I2C driver to 2.6.35

[Wolfram Sang <w.sang@pengutronix.de>]

[-- Attachment #1: Type: text/plain, Size: 1733 bytes --]

On Fri, Sep 03, 2010 at 01:36:13PM +0100, Alan Cox wrote:
> > +config PCH_I2C_CH_COUNT
> > +	int "PCH I2C the number of channel count"
> > +	range 1 2
> > +	depends on PCH_I2C
> > +	help
> > +	  This driver is for PCH(Platform controller Hub) I2C of Topcliff which
> > +	  is an IOH(Input/Output Hub) for x86 embedded processor.
> > +	  The number of I2C buses/channels supported by the PCH I2C controller.
> > +	  PCH I2C of Topcliff supports only one channel.
> 
> These sort of settings need to be runtime so one kernel can be built for
> many platform variants. In this case if I understand correctly the
> current device only has one channel so the define could just be moved
> into the driver for now and made a variable later as/when/if new hardware
> with more channels appears.
> 
> 
> 
> > +static s32 pch_wait_for_xfer_complete(struct i2c_algo_pch_data *adap)
> > +{
> > +	s32 ret;
> > +	ret = wait_event_interruptible_timeout(pch_event,
> > +			(adap->pch_event_flag != 0), msecs_to_jiffies(50));
> > +	if (ret < 0) {
> > +		pch_err(adap, "timeout: %x\n", adap->pch_event_flag);
> > +		return ret;
> > +	}
> 
> You are reporting a timeout when _interruptible can also be woken by a
> signal to the process (eg the user hitting ^C)

Sidenote: a number of embedded drivers decided to switch to
wait_event_timeout() recently because reacting to a signal may have
subtle issues and must be carefully implemented and tested. Stalled
busses were often the consequence. I don't know if this applies here but
better keep it in mind.

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]