[i2c] [PATCH 2/2] I2C: ISP1301_OMAP: New-style i2c driver updates, part 2

[Felipe Balbi]

On Sun, Feb 24, 2008 at 1:05 PM,  <felipebalbi at users.sourceforge.net> wrote:
> sorry im topostig, but im using gmail through gprs and it sucks. Jean,
>  thanks for explaining everything and applying the first part to your
>  i2c tree. I'll try to address the issues today or tomorrow and send
>  you a better patch.
>
>  Thanks again for your time ;)
>
>
>
>  On 2/24/08, Jean Delvare <khali at linux-fr.org> wrote:
>  > On Sat, 23 Feb 2008 11:53:03 -0800, David Brownell wrote:
>  > > On Saturday 23 February 2008, Jean Delvare wrote:
>  > > > On Sat, 23 Feb 2008 10:10:39 -0800, David Brownell wrote:
>  > > > > On Saturday 23 February 2008, Felipe Balbi wrote:
>  > > > > > Thanks Dave, the patch is attached. patch 1 is acked by Jean, right
>  > Jean?
>  > > >
>  > > > Yes, except that my copy has "isp->irq_type = 0;" removed.
>  > >
>  > > From a bzeroed structure?  Then I won't worry about that difference...
>  >
>  > I removed this statement exactly because the structure is kzalloc'd.
>  > You don't have to worry as a tester. I do worry as the i2c subsystem
>  > maintainer, because I'd like Felipe to base his second patch on the
>  > "right" first patch, so that it applies properly to my tree.
>  >
>  > Felipe, my version of the first patch is available here:
>  > http://khali.linux-fr.org/devel/linux-2.6/jdelvare-i2c/i2c-isp1301_omap-convert-to-new-style-1.patch
>  >
>  > Please make sure that the next update to the second part applies
>  > properly on top of it.
>  >
>  > > > > But not yet in the I2C merge queue??
>  > > >
>  > > > I was waiting for the second part. The first part doesn't make much
>  > > > sense alone. I could add the first part to my i2c tree, but I can't
>  > > > merge it upstream without the second part.
>  > >
>  > > That makes no sense to me.  If the first part is OK, it's OK to
>  > > merge without the second part.
>  >
>  > And if the second part never makes it, we end up with garbage in the
>  > upstream kernel. Thanks but no thanks.
>  >
>  > > Even if you don't _plan_ to merge it soon, it'd be less confusing
>  > > to have that in your queue ... say, towards the end, below a line
>  > > that indicates a scheduled merge point.  (FWIW that's not unlike
>  > > Andrew does with MM.)
>  >
>  > Indeed, the first patch in question has even been in -mm for quite some
>  > time now, and Andrew keeps sending it to me so that I take it in my i2c
>  > tree. So I've now included the first part in my public i2c patch queue
>  > to make everyone happy. But then again, there is no "scheduled merge
>  > point" for a patchset that is not yet complete.
>  >
>  > --
>  > Jean Delvare
>  >
>
>
>
>
> --
>  Best Regards,
>
>  Felipe Balbi
>  felipebalbi at users.sourceforge.net
>

Another version here.
Jean, I'm thinking about introducing include/asm/arch/isp1301.h so I
can introduce struct isp1301_platform_data to pass irq_flags to the
driver.
What do you think ?

Dave, any comments ?

-- 
Best Regards,

Felipe Balbi
felipebalbi at users.sourceforge.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-I2C-ISP1301_OMAP-New-style-i2c-driver-updates-part.diff
Type: text/x-patch
Size: 9581 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/i2c/attachments/20080225/561040c8/attachment-0001.bin