Re: IIO driver merge plans (for next merge window)

[Jonathan Cameron <jic23@cam.ac.uk>]

On 05/17/10 09:08, Hennerich, Michael wrote:
> Zhang, Sonic wrote on 2010-05-17:
>>
>>
>>> -----Original Message-----
>>> From: Hennerich, Michael
>>> Sent: Monday, May 17, 2010 3:48 PM
>>> To: Zhang, Sonic; Jonathan Cameron; Barry Song
>>> Cc: Song, Barry; linux-iio@vger.kernel.org; Manuel Stahl; Frysinger,
>>> Michael
>>> Subject: RE: IIO driver merge plans (for next merge window)
>>>
>>> Zhang, Sonic wrote on 2010-05-17:
>>>> Hi Jonathan,
>>>>
>>>> Yes, we can send the driver patches to linux-iio after it passes
>>>> debugging in local SVN. But, since the kernel version and iio tree
>>>> base in our SVN are different from yours, we have to port the patches
>>>> before posting. And we don't ensure the new patches still run without
>>>> problem in your tree, until your tree is merged into mainline and
>>>> updated to our local SVN.
>>>
>>> Sonic,
>>>
>>> How about we merge Greg's staging iio folder into our svn right now?
>>> This way we can do the API fixes to our drivers and send them also to
>>> Greg for inclusion without greater delays.
>>>
>>
>> It is OK to merge the IIO patches if they don't care about kernel
>> version difference between Greg's tree and our SVN tree. Our's is
>> 2.6.33.4, while Greg's is 2.6.34-rc6
> 
> staging-iio is pretty much self contained.
> As far I can tell it doesn't depend on anything that has been changed
> between 2.6.33 and 2.6.34.
There might be a few header issues outside IIO. These are just additional
required headers (due to some general clean up) that shouldn't effect
the merge from mainline to your tree, but may cause issues the other way
around by requiring a few more includes in some of your drivers. A simple
build test should throw up any of these.

I don't know what Greg's policy is on taking patches at this stage in the
merge cycle (merge window just opened).  I'd imagine anything he doesn't
get in the next couple of days will have to work for the next window
(in about three months).  They'll sit in linux next until then.  I don't
think operates the normal kernel rule of allowing new self contained drivers
to merge later in the cycle.  This would become hard to manage for staging
where the majority of code fits in that category.

Jonathan