linux-kernel - Re: [PATCH v2] Bitbanging i2c bus driver using the GPIO API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 12 Mar 2007 15:34:57 +0100
From:	Haavard Skinnemoen <hskinnemoen@...el.com>
To:	bryan.wu@...log.com
Cc:	David Brownell <david-b@...bell.net>,
	Jean Delvare <khali@...ux-fr.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Deepak Saxena <dsaxena@...xity.net>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] Bitbanging i2c bus driver using the GPIO API

On Mon, 12 Mar 2007 18:07:59 +0800
"Wu, Bryan" <bryan.wu@...log.com> wrote:
> >   static struct i2c_gpio_platform_data i2c_gpio_data = {
> > 	.sda_pin	= GPIO_PIN_FOO,
> > 	.scl_pin	= GPIO_PIN_BAR,
> >   };
> 
> Is this usage right, because 3 flags are added to this structure as
> below:
> 
> struct i2c_gpio_platform_data {
> 	unsigned int sda_pin;
> 	unsigned int scl_pin;
> 	unsigned int sda_is_open_drain:1;
> 	unsigned int scl_is_open_drain:1;
> 	unsigned int scl_is_output_only:1;
> };

Well, it is the simplest possible example. The last 3 fields will be 0,
which is a valid configuration.

> Thanks a lot,  I will drop our GPIO based I2C driver and try this one on
> our platform.

I hope it works for you.

> > +	if (!pdata->scl_is_output_only)
> > +		bit_data->getscl = i2c_gpio_getscl,
> > +
> > +	bit_data->getsda	= i2c_gpio_getsda,
> > +	bit_data->udelay	= 5,			/* 100 kHz */
> > +	bit_data->timeout	= HZ / 10,		/* 100 ms */
> 
> Can we add these udelay/timeout to struct i2c_gpio_platform_data? And
> let customer to choose these according their specific requirement. We
> use Kconfig to do this, but Jean and David don't like the idea, -:(

Yeah, they need to be a bit more configurable than they currently are.
And I think it makes sense to pass them from the board setup code, since
this is where things depending on board-specific details (signal quality
issues, pullup resistor values, etc.) are supposed to go.

Haavard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/