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

[felipebalbi at users.sourceforge.net]

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