lkml.org 
[lkml]   [2008]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [git pull] IDE updates #4
Hello, I wrote:

>>>> and number of new submitted patches is < 10 (I'll take
>>>> care of fixing them up, ditto for all other new stuff that will be
>>>> using old
>>>> naming scheme).

>>> Thanks for clarifying this.
>>> This rename only added more uncertainty for my pending patchset
>>> (which had been already dependant on at least TX4939 driver which
>>> keeps being recast by Atsushi and being stale in pata-2.6 series) as
>>> I can't predict when you and Linus will merge the changes and this is
>>> getting on my nerves, as I don't have time on any extra rework and
>>> I'm running out of time with the submission. I know I should have
>>> done this earlier and

>> Maybe some parts could be submitted separately?
>> (so keeping them up-to-date in pata-2.6 would be my task)

> 2 (maybe even 3) out of 4 can be but that doesn't make much sense
> already (and would incur the patch reordering for me) -- the best thing
> you can do is to merge ASAP the last verison of TX4939 which has my ACK.
> I'm not sure about TX4938 driver yet -- will look at it after some sleep...

Still haven't looked at it... too little sleep and incuring headache. :-/

>> Also I didn't know anything about your patchset and its
>> dependency on TX4939, otherwise I'll be pushing things in

> The patchset consists of a large patch moving read_sff_dma_status() to
> its porper place, one small preparatory patch, and 2 followup patches,
> so unfortunately it's dependent on TX4939 in its main patch (worse, the
> relevant part of this driver has changed after your last merged driver
> version)...

>> different order or even skip this pull request if needed
>> (TX493x drivers are new stuff and were still under review,
>> such things can be also submitted after the merge window
>> closes so they were given the lowest priority).

> Unfortunately, that driver has been submitted first back 9/09, long
> before my patchset was even created, so the dependence was just natural.

I could also rip out TX4939 part from the patch and leave Atsushi to deal
with the fallout (though I could give him the ripped out part to simply be
merged to the driver) if you would queue my patchset ahead of the driver.
Though I feel it's too late now for my patchset to get into 2.6.28 the way
things have been happening... :-/

MBR, Sergei



\
 
 \ /
  Last update: 2008-10-23 17:59    [W:0.121 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site