Re: [PATCH 00/86] PATA fixes

Jeff Garzik
2009-12-03T21:51:08Z

On 12/03/2009 04:42 PM, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 03 December 2009 10:16:15 pm Jeff Garzik wrote:
>
>>> pata_efar: MWDMA0 is unsupported
>>
>> skipped, pending discussion (just sent email)
>
> The discussion was there, you were not especially interested
> (http://lkml.org/lkml/2009/11/26/343).

I reviewed the discussion before adding an email to that thread.

>>> pata_hpt3x2n: fix overclocked MWDMA0 timing
>>
>> skipped, pending discussion (just sent email)
>
> ditto (http://lkml.org/lkml/2009/11/27/257).

I reviewed the discussion before adding an email to that thread.

> There were no complains so I'm pretty sure Sergei was fine with it.

It was unclear, hence I sent email for clarification.

>>> pata_hpt3x3: Power Management fix
>>
>> applied, on a hope and a prayer (did not see this posted to mailing
>> list?). It looks correct to me.
>
> I prefer sticking to technical facts. ;)
>
> Patch was posted to both mailing lists: http://lkml.org/lkml/2009/11/25/321

Whoops, I indeed missed this one.

>>> pata_via: clear UDMA transfer mode bit for PIO and MWDMA
>>
>> applied -- even though Alan's comment was correct. It is standard
>> kernel practice to place cosmetic changes into their own patches,
>> because it is standard kernel practice to break up logically distinct
>> changes.
>
> We are talking about:
>
> pata_via.c | 19 +++++++++++++------
> 1 file changed, 13 insertions(+), 6 deletions(-)
>
> patch here (http://lkml.org/lkml/2009/11/25/380) and cosmetic change
> is clearly documented in the patch description.
>
>
> Do people really wonder why I find upstream to be too much hassle to
> deal with?

The thousand other kernel developers seem to be able to split up their
patches, separating out cosmetic changes from functional ones. It has
clear engineering benefits, and has been standard practice for a decade
or more.

Why is it such an imposition for your patches to look like everyone
else's? And by "everyone", I mean all other kernel developers, not just
other ATA developers.

You seem to consider standard kernel practice a hassle. Separating out
cosmetic changes is not only a libata practice, it is the norm for the
entire kernel.

Jeff