Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux: Kernel

[PATCH 00/86] PATA fixes

 

 

First page Previous page 1 2 Next page Last page  View All Linux kernel RSS feed   Index | Next | Previous | View Threaded


bzolnier at gmail

Nov 25, 2009, 9:02 AM

Post #1 of 36 (605 views)
Permalink
[PATCH 00/86] PATA fixes

Hi,

I've been going through PATA drivers for the last few days to make
sure that we offer similar level of hardware support in the new PATA
drivers as with the old IDE subsystem and the following patchset is
the end result of said audit.


Inside:

- many bugfixes

( ata_piix, pata_artop, pata_atiixp, pata_efar, pata_cmd64x,
pata_hpt3x3, pata_it8213, pata_legacy, pata_ns87415, pata_sis,
pata_radisys, pata_rz1000 & pata_via )

- add Power Management support for more controllers

( pata_artop, pata_pdc2027x, pata_sl82c105 )

- add 32-bit PIO support for more controllers

( pata_artop, pata_atiixp, pata_efar, pata_cmd64x, pata_cs5520,
pata_cs5530, pata_cs5535, pata_cypress, pata_hpt366, pata_hpt37x,
pata_hpt3x2n, pata_it8213, pata_it821x, pata_jmicron, pata_ns87415,
pata_opti, pata_pdc2027x, pata_pdc202xx_old, pata_rz1000,
pata_sc1200, pata_scc, pata_sch, pata_serverworks, pata_sl82c105,
pata_sis, pata_triflex & pata_via )

- fix QDI65x0 support in pata_legacy driver so pata_qdi driver can
be finally removed

- remove pata_qdi and pata_winbond drivers resulting in 600 LOC gone

(affected hardware is fully supported by pata_legacy driver now)

- unify code for programming PIO and MWDMA timings for 'PIIX-like'
controllers resulting in 200 LOC gone

( ata_piix, pata_efar, pata_it8213, pata_oldpiix, pata_radisys &
pata_rdc )

- add ->init_host method for abstracting host specific controller
initialization and then use it to cleanup Power Managment code
resulting in over 100 LOC gone

( pata_ali, pata_amd, pata_artop, pata_cmd640, pata_cmd64x,
pata_cs5530, pata_hpt366, pata_hpt3x3, pata_it821x, pata_ninja32,
pata_ns87415, pata_pdc2027x & sata_sil )

- misc fixes and cleanups


The following changes since commit 5c0e519edce8aa5c517e3b3e9a1fdf6fa0f3cf83:
Christoph Hellwig (1):
libata: add translation for SCSI WRITE SAME (aka TRIM support)

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/bart/misc.git atang-v1

Bartlomiej Zolnierkiewicz (86):
ata_piix: fix MWDMA handling on PIIX3
ata_piix: unify code for programming PIO and MWDMA timings
pata_artop: add 32-bit PIO support
pata_artop: fix chipsets naming
pata_artop: add Power Management support
pata_artop: unify ->prereset methods
pata_artop: remove dead 34MHz PCI clock support
pata_atiixp: add 32-bit PIO support
pata_atiixp: no need to program PIO timings for MWDMA
pata_atiixp: add MWDMA0 support
pata_atiixp: remove custom BMDMA methods
pata_atiixp: add proper ->prereset method
pata_efar: add 32-bit PIO support
pata_efar: fix wrong PIO timings being programmed
pata_efar: fix wrong MWDMA timings being programmed
pata_efar: MWDMA0 is unsupported
pata_efar: fix register naming used in efar_set_piomode()
pata_efar: unify code for programming PIO and MWDMA timings
pata_cmd640: document known issues
pata_cmd64x: add 32-bit PIO support
pata_cmd64x: add enablebits checking
pata_cmd64x: add cmd64x_fixup()
pata_cs5520: add 32-bit PIO support
pata_cs5520: remove dead VDMA support
pata_cs5530: add 32-bit PIO support
pata_cs5535: add 32-bit PIO support
pata_cs5535: no need to program PIO0 timings during device init
pata_cypress: add 32-bit PIO support
pata_cypress: document known issues
pata_hpt366: add 32-bit PIO support
pata_hpt37x: add 32-bit PIO support
pata_hpt3x2n: add 32-bit PIO support
pata_hpt3x3: Power Management fix
pata_it8213: add 32-bit PIO support
pata_it8213: fix UDMA handling
pata_it8213: add UDMA100 and UDMA133 support
pata_it8213: fix wrong PIO timings being programmed
pata_it8213: fix PIO2 underclocking
pata_it8213: fix wrong MWDMA timings being programmed
pata_it8213: fix register naming used in it8213_set_piomode()
pata_efar: unify code for programming PIO and MWDMA timings
pata_it8213: fix it8213_pre_reset() documentation
pata_it821x: add 32-bit PIO support
pata_jmicron: add 32-bit PIO support
pata_legacy: do not probe extra ports automatically if PCI is not present
pata_legacy: fix QDI6580DP support
pata_legacy: fix access to control register for QDI6580
pata_legacy: add pointers to QDI65x0 documentation
pata_legacy: unify QDI ->set_piomode methods
pata_legacy: use PIO mask defines
libata: remove no longer needed pata_qdi driver
libata: remove no longer needed pata_winbond driver
pata_marvell: fix marvell_pre_reset() documentation
pata_ns87415: add 32-bit PIO support
pata_ns87415: Power Management fix
pata_oldpiix: unify code for programming PIO and MWDMA timings
pata_opti: add 32-bit PIO support
pata_pdc2027x: add 32-bit PIO support
pata_pdc2027x: add Power Management support
pata_pdc202xx_old: add 32-bit PIO support
pata_sis: Power Management fix
pata_pdc202xx_old: document known issues
pata_radisys: fix UDMA handling
pata_radisys: unify code for programming PIO and MWDMA timings
pata_rdc: unify code for programming PIO and MWDMA timings
pata_rz1000: add 32-bit PIO support
pata_rz1000: Power Management fix
pata_sc1200: add 32-bit PIO support
pata_scc: add 32-bit PIO support
pata_scc: add proper cable detection method
pata_sch: add 32-bit PIO support
pata_serverworks: add 32-bit PIO support
pata_serverworks: use standard cable detection methods
pata_serverworks: add serverworks_fixup()
pata_sl82c105: add 32-bit PIO support
pata_sl82c105: add Power Management support
pata_sis: add 32-bit PIO support
pata_sis: Power Management fix
pata_triflex: add 32-bit PIO support
libata: make ata_sff_data_xfer_noirq() work with 32-bit PIO
pata_via: add 32-bit PIO support
pata_via: clear UDMA transfer mode bit for PIO and MWDMA
pata_via: add via_fixup()
libata: add ata_mwdma_to_pio() inline helper
libata: add ->init_host method
libata: add private driver field to struct ata_device

drivers/ata/Kconfig | 16 ++-
drivers/ata/Makefile | 2 -
drivers/ata/ata_piix.c | 113 ++++---------
drivers/ata/libata-core.c | 14 ++-
drivers/ata/libata-sff.c | 12 +-
drivers/ata/pata_ali.c | 29 +--
drivers/ata/pata_amd.c | 45 ++---
drivers/ata/pata_artop.c | 224 ++++++++++++-------------
drivers/ata/pata_atiixp.c | 112 ++++---------
drivers/ata/pata_cmd640.c | 27 +--
drivers/ata/pata_cmd64x.c | 100 +++++++-----
drivers/ata/pata_cs5520.c | 41 +----
drivers/ata/pata_cs5530.c | 33 +---
drivers/ata/pata_cs5535.c | 14 +--
drivers/ata/pata_cypress.c | 2 +-
drivers/ata/pata_efar.c | 121 +++++---------
drivers/ata/pata_hpt366.c | 32 ++---
drivers/ata/pata_hpt37x.c | 4 +-
drivers/ata/pata_hpt3x2n.c | 2 +-
drivers/ata/pata_hpt3x3.c | 23 ++--
drivers/ata/pata_it8213.c | 136 ++++++---------
drivers/ata/pata_it821x.c | 39 ++---
drivers/ata/pata_jmicron.c | 2 +-
drivers/ata/pata_legacy.c | 156 +++++++----------
drivers/ata/pata_marvell.c | 2 +-
drivers/ata/pata_ninja32.c | 30 ++--
drivers/ata/pata_ns87415.c | 22 ++-
drivers/ata/pata_oldpiix.c | 95 +++-------
drivers/ata/pata_opti.c | 2 +
drivers/ata/pata_pdc2027x.c | 24 ++-
drivers/ata/pata_pdc202xx_old.c | 37 ++++-
drivers/ata/pata_qdi.c | 366 ---------------------------------------
drivers/ata/pata_radisys.c | 78 +++------
drivers/ata/pata_rdc.c | 106 ++++--------
drivers/ata/pata_rz1000.c | 13 ++-
drivers/ata/pata_sc1200.c | 2 +-
drivers/ata/pata_scc.c | 16 +--
drivers/ata/pata_sch.c | 2 +-
drivers/ata/pata_serverworks.c | 104 +++++-------
drivers/ata/pata_sis.c | 25 +++-
drivers/ata/pata_sl82c105.c | 28 +++-
drivers/ata/pata_triflex.c | 2 +-
drivers/ata/pata_via.c | 74 ++++----
drivers/ata/pata_winbond.c | 282 ------------------------------
drivers/ata/sata_sil.c | 33 +---
include/linux/ata.h | 11 ++
include/linux/libata.h | 15 ++-
47 files changed, 854 insertions(+), 1814 deletions(-)
delete mode 100644 drivers/ata/pata_qdi.c
delete mode 100644 drivers/ata/pata_winbond.c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jeff at garzik

Nov 25, 2009, 9:19 AM

Post #2 of 36 (587 views)
Permalink
Re: [PATCH 00/86] PATA fixes [In reply to]

On 11/25/2009 12:02 PM, Bartlomiej Zolnierkiewicz wrote:
> I've been going through PATA drivers for the last few days to make
> sure that we offer similar level of hardware support in the new PATA
> drivers as with the old IDE subsystem and the following patchset is
> the end result of said audit.

Thanks!

> - add 32-bit PIO support for more controllers
>
> ( pata_artop, pata_atiixp, pata_efar, pata_cmd64x, pata_cs5520,
> pata_cs5530, pata_cs5535, pata_cypress, pata_hpt366, pata_hpt37x,
> pata_hpt3x2n, pata_it8213, pata_it821x, pata_jmicron, pata_ns87415,
> pata_opti, pata_pdc2027x, pata_pdc202xx_old, pata_rz1000,
> pata_sc1200, pata_scc, pata_sch, pata_serverworks, pata_sl82c105,
> pata_sis, pata_triflex& pata_via )

This should be all in one patch.

I'll let the comments from Alan and others trickle in before applying...

> - add ->init_host method for abstracting host specific controller
> initialization and then use it to cleanup Power Managment code
> resulting in over 100 LOC gone
>
> ( pata_ali, pata_amd, pata_artop, pata_cmd640, pata_cmd64x,
> pata_cs5530, pata_hpt366, pata_hpt3x3, pata_it821x, pata_ninja32,
> pata_ns87415, pata_pdc2027x & sata_sil )

hmmmm.... will reserve comment until I review it thoroughly, but I am a
bit reluctant to move away from the current struct-driver style driver
init/setup model.

Jeff



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


bzolnier at gmail

Nov 25, 2009, 9:24 AM

Post #3 of 36 (590 views)
Permalink
Re: [PATCH 00/86] PATA fixes [In reply to]

On Wednesday 25 November 2009 06:19:49 pm Jeff Garzik wrote:
> On 11/25/2009 12:02 PM, Bartlomiej Zolnierkiewicz wrote:
> > I've been going through PATA drivers for the last few days to make
> > sure that we offer similar level of hardware support in the new PATA
> > drivers as with the old IDE subsystem and the following patchset is
> > the end result of said audit.
>
> Thanks!
>
> > - add 32-bit PIO support for more controllers
> >
> > ( pata_artop, pata_atiixp, pata_efar, pata_cmd64x, pata_cs5520,
> > pata_cs5530, pata_cs5535, pata_cypress, pata_hpt366, pata_hpt37x,
> > pata_hpt3x2n, pata_it8213, pata_it821x, pata_jmicron, pata_ns87415,
> > pata_opti, pata_pdc2027x, pata_pdc202xx_old, pata_rz1000,
> > pata_sc1200, pata_scc, pata_sch, pata_serverworks, pata_sl82c105,
> > pata_sis, pata_triflex& pata_via )
>
> This should be all in one patch.

For review & testing purposes it is better do it this way, I can merge
individual patches easily later if desirable.

> I'll let the comments from Alan and others trickle in before applying...

See comment above.

> > - add ->init_host method for abstracting host specific controller
> > initialization and then use it to cleanup Power Managment code
> > resulting in over 100 LOC gone
> >
> > ( pata_ali, pata_amd, pata_artop, pata_cmd640, pata_cmd64x,
> > pata_cs5530, pata_hpt366, pata_hpt3x3, pata_it821x, pata_ninja32,
> > pata_ns87415, pata_pdc2027x & sata_sil )
>
> hmmmm.... will reserve comment until I review it thoroughly, but I am a
> bit reluctant to move away from the current struct-driver style driver
> init/setup model.

This change is not moving away from it. On the contrary -- it enhances
the current model by adding another possibility of doing things as the new
->init_host method is completely optional.

--
Bartlomiej Zolnierkiewicz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


alan at lxorguk

Nov 25, 2009, 10:01 AM

Post #4 of 36 (586 views)
Permalink
Re: [PATCH 00/86] PATA fixes [In reply to]

Summary would be lots of really good stuff and review.

> hmmmm.... will reserve comment until I review it thoroughly, but I am a
> bit reluctant to move away from the current struct-driver style driver
> init/setup model.

I think the model is right - I'd prefer it to be in the driver structs
somewhere but the basic point that init and resume often do the same job
is a very sound one.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jeff at garzik

Dec 3, 2009, 12:07 AM

Post #5 of 36 (581 views)
Permalink
Re: [PATCH 00/86] PATA fixes [In reply to]

On 11/25/2009 12:02 PM, Bartlomiej Zolnierkiewicz wrote:
> Hi,
>
> I've been going through PATA drivers for the last few days to make
> sure that we offer similar level of hardware support in the new PATA
> drivers as with the old IDE subsystem and the following patchset is
> the end result of said audit.
>
>
> Inside:
>
> - many bugfixes
>
> ( ata_piix, pata_artop, pata_atiixp, pata_efar, pata_cmd64x,
> pata_hpt3x3, pata_it8213, pata_legacy, pata_ns87415, pata_sis,
> pata_radisys, pata_rz1000& pata_via )
>
> - add Power Management support for more controllers
>
> ( pata_artop, pata_pdc2027x, pata_sl82c105 )
>
> - add 32-bit PIO support for more controllers
>
> ( pata_artop, pata_atiixp, pata_efar, pata_cmd64x, pata_cs5520,
> pata_cs5530, pata_cs5535, pata_cypress, pata_hpt366, pata_hpt37x,
> pata_hpt3x2n, pata_it8213, pata_it821x, pata_jmicron, pata_ns87415,
> pata_opti, pata_pdc2027x, pata_pdc202xx_old, pata_rz1000,
> pata_sc1200, pata_scc, pata_sch, pata_serverworks, pata_sl82c105,
> pata_sis, pata_triflex& pata_via )
>
> - fix QDI65x0 support in pata_legacy driver so pata_qdi driver can
> be finally removed
>
> - remove pata_qdi and pata_winbond drivers resulting in 600 LOC gone
>
> (affected hardware is fully supported by pata_legacy driver now)
>
> - unify code for programming PIO and MWDMA timings for 'PIIX-like'
> controllers resulting in 200 LOC gone
>
> ( ata_piix, pata_efar, pata_it8213, pata_oldpiix, pata_radisys&
> pata_rdc )
>
> - add ->init_host method for abstracting host specific controller
> initialization and then use it to cleanup Power Managment code
> resulting in over 100 LOC gone
>
> ( pata_ali, pata_amd, pata_artop, pata_cmd640, pata_cmd64x,
> pata_cs5530, pata_hpt366, pata_hpt3x3, pata_it821x, pata_ninja32,
> pata_ns87415, pata_pdc2027x& sata_sil )
>
> - misc fixes and cleanups

What are your plans for 2.6.33?

The merge window is upon us, which by strict rules means that anything
not already in libata-dev.git#upstream needs to wait until 2.6.34.

However, bug fixes and the like should definitely be in 2.6.33.
->init_host is definitely 2.6.34 material. Some of the other stuff
could go either way.

Jeff



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


bzolnier at gmail

Dec 3, 2009, 4:39 AM

Post #6 of 36 (579 views)
Permalink
Re: [PATCH 00/86] PATA fixes [In reply to]

On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote:
> On 11/25/2009 12:02 PM, Bartlomiej Zolnierkiewicz wrote:
> > Hi,
> >
> > I've been going through PATA drivers for the last few days to make
> > sure that we offer similar level of hardware support in the new PATA
> > drivers as with the old IDE subsystem and the following patchset is
> > the end result of said audit.
> >
> >
> > Inside:
> >
> > - many bugfixes
> >
> > ( ata_piix, pata_artop, pata_atiixp, pata_efar, pata_cmd64x,
> > pata_hpt3x3, pata_it8213, pata_legacy, pata_ns87415, pata_sis,
> > pata_radisys, pata_rz1000& pata_via )
> >
> > - add Power Management support for more controllers
> >
> > ( pata_artop, pata_pdc2027x, pata_sl82c105 )
> >
> > - add 32-bit PIO support for more controllers
> >
> > ( pata_artop, pata_atiixp, pata_efar, pata_cmd64x, pata_cs5520,
> > pata_cs5530, pata_cs5535, pata_cypress, pata_hpt366, pata_hpt37x,
> > pata_hpt3x2n, pata_it8213, pata_it821x, pata_jmicron, pata_ns87415,
> > pata_opti, pata_pdc2027x, pata_pdc202xx_old, pata_rz1000,
> > pata_sc1200, pata_scc, pata_sch, pata_serverworks, pata_sl82c105,
> > pata_sis, pata_triflex& pata_via )
> >
> > - fix QDI65x0 support in pata_legacy driver so pata_qdi driver can
> > be finally removed
> >
> > - remove pata_qdi and pata_winbond drivers resulting in 600 LOC gone
> >
> > (affected hardware is fully supported by pata_legacy driver now)
> >
> > - unify code for programming PIO and MWDMA timings for 'PIIX-like'
> > controllers resulting in 200 LOC gone
> >
> > ( ata_piix, pata_efar, pata_it8213, pata_oldpiix, pata_radisys&
> > pata_rdc )
> >
> > - add ->init_host method for abstracting host specific controller
> > initialization and then use it to cleanup Power Managment code
> > resulting in over 100 LOC gone
> >
> > ( pata_ali, pata_amd, pata_artop, pata_cmd640, pata_cmd64x,
> > pata_cs5530, pata_hpt366, pata_hpt3x3, pata_it821x, pata_ninja32,
> > pata_ns87415, pata_pdc2027x& sata_sil )
> >
> > - misc fixes and cleanups
>
> What are your plans for 2.6.33?

All past patches have been posted for review and have review issues addressed
already so right now I'm all busy with working on future patches.

> The merge window is upon us, which by strict rules means that anything
> not already in libata-dev.git#upstream needs to wait until 2.6.34.
>
> However, bug fixes and the like should definitely be in 2.6.33.
> ->init_host is definitely 2.6.34 material. Some of the other stuff
> could go either way.

If you would like to apply some of my patches to 2.6.33 you are more than
welcome to do it. I can even prepare separate git tree with specific changes
to make it easier for you once you tell me which changes you would like to
see in it.

--
Bartlomiej Zolnierkiewicz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


alan at lxorguk

Dec 3, 2009, 8:59 AM

Post #7 of 36 (577 views)
Permalink
Re: [PATCH 00/86] PATA fixes [In reply to]

> The merge window is upon us, which by strict rules means that anything
> not already in libata-dev.git#upstream needs to wait until 2.6.34.

Not quite yet - Linus hasn't said "go"

> However, bug fixes and the like should definitely be in 2.6.33.
> ->init_host is definitely 2.6.34 material. Some of the other stuff
> could go either way.

The bits that probably should be delayed a bit more (if any) IMHO are the
32bit enables for hardware that doesn't use 32bit by default on the
drivers/ide stack, and tweaks for obscure old hardware that won't get
much testing.

The sooner it's all upstream the better.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jeff at garzik

Dec 3, 2009, 9:39 AM

Post #8 of 36 (580 views)
Permalink
Re: [PATCH 00/86] PATA fixes [In reply to]

On 12/03/2009 11:59 AM, Alan Cox wrote:
>> The merge window is upon us, which by strict rules means that anything
>> not already in libata-dev.git#upstream needs to wait until 2.6.34.
>
> Not quite yet - Linus hasn't said "go"

He rarely if ever says "go." The kernel X is released, and people send
pull requests to Linus for X+1. He typically merges immediately, but
does not push out the first set of merges for a few days.

The stuff pushed to Linus for kernel X+1 should have already been living
in linux-next (libata-dev.git#NEXT, to us).


> The bits that probably should be delayed a bit more (if any) IMHO are the
> 32bit enables for hardware that doesn't use 32bit by default on the
> drivers/ide stack, and tweaks for obscure old hardware that won't get
> much testing.

Agreed mostly... I still want to push fixes even if for obscure hardware.

Jeff



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jeff at garzik

Dec 3, 2009, 9:53 AM

Post #9 of 36 (578 views)
Permalink
Re: [PATCH 00/86] PATA fixes [In reply to]

On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote:
>> The merge window is upon us, which by strict rules means that anything
>> not already in libata-dev.git#upstream needs to wait until 2.6.34.
>>
>> However, bug fixes and the like should definitely be in 2.6.33.
>> ->init_host is definitely 2.6.34 material. Some of the other stuff
>> could go either way.

> If you would like to apply some of my patches to 2.6.33 you are more than
> welcome to do it. I can even prepare separate git tree with specific changes
> to make it easier for you once you tell me which changes you would like to
> see in it.

OK, great.

Can you prepare a patchset containing only fixes? Comment-only changes
are acceptable too. Trivial changes too, if they are extremely trivial :)

Include nothing that adds features, removes or unifies drivers, etc.

Please do it in standard kernel submit form, which is either
(a) repost the patches (yes, again) being submitted for 2.6.33, or
(b) a standard git pull request, which includes shortlog, diffstat, and
all-in-one diff.

Jeff


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


bzolnier at gmail

Dec 3, 2009, 11:45 AM

Post #10 of 36 (576 views)
Permalink
Re: [PATCH 00/86] PATA fixes [In reply to]

On Thursday 03 December 2009 06:53:59 pm Jeff Garzik wrote:
> On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote:
> > On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote:
> >> The merge window is upon us, which by strict rules means that anything
> >> not already in libata-dev.git#upstream needs to wait until 2.6.34.
> >>
> >> However, bug fixes and the like should definitely be in 2.6.33.
> >> ->init_host is definitely 2.6.34 material. Some of the other stuff
> >> could go either way.
>
> > If you would like to apply some of my patches to 2.6.33 you are more than
> > welcome to do it. I can even prepare separate git tree with specific changes
> > to make it easier for you once you tell me which changes you would like to
> > see in it.
>
> OK, great.
>
> Can you prepare a patchset containing only fixes? Comment-only changes
> are acceptable too. Trivial changes too, if they are extremely trivial :)
>
> Include nothing that adds features, removes or unifies drivers, etc.

Since this is pretty high-level description and some changes fall into
many categories at once (i.e. addition of proper PCI Power Management
handling could be considered both as a fix and as a feature) I prepared
a rather conservative set of changes (which means that unfortunately
it misses many enhancements available in my tree):

> Please do it in standard kernel submit form, which is either
> (a) repost the patches (yes, again) being submitted for 2.6.33, or
> (b) a standard git pull request, which includes shortlog, diffstat, and
> all-in-one diff.

Thank you for the detailed explanation of the standard kernel submit
form (I wonder how would I know this otherwise :) but the thing is that
at the current moment I'm not submitting anything to the upstream.

That's it. While this may sound strange to some people it turns out
that in practice it is much less hassle for me personally to keep some
of trees outside of the (sometimes greatly overrated) upstream.

If knowing the above you still would like to include the aforementioned
set of changes in your libata-dev tree they are at kernel.org now.


The following changes since commit 184b8405d5d3e8510163d66efbac99d351faba2e:
Bartlomiej Zolnierkiewicz (1):
libata: add private driver field to struct ata_device

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/bart/misc.git atang-for-2.6.33

Bartlomiej Zolnierkiewicz (28):
ide-pci-generic: build fix
ata_piix: fix MWDMA handling on PIIX3
pata_efar: fix wrong PIO timings being programmed
pata_efar: fix wrong MWDMA timings being programmed
pata_efar: MWDMA0 is unsupported
pata_cmd640: document known issues
pata_cs5520: remove dead VDMA support
pata_cypress: document known issues
pata_hpt3x2n: fix overclocked MWDMA0 timing
pata_hpt3x3: Power Management fix
pata_it8213: fix UDMA handling
pata_it8213: fix wrong PIO timings being programmed
pata_it8213: fix PIO2 underclocking
pata_it8213: fix wrong MWDMA timings being programmed
pata_it8213: fix it8213_pre_reset() documentation
pata_it8213: MWDMA0 is unsupported
pata_legacy: fix QDI6580DP support
pata_legacy: fix access to control register for QDI6580
pata_legacy: add pointers to QDI65x0 documentation
pata_marvell: fix marvell_pre_reset() documentation
pata_ns87415: Power Management fix
pata_oldpiix: MWDMA0 is unsupported
pata_pdc202xx_old: document known issues
pata_radisys: fix UDMA handling
pata_rdc: MWDMA0 is unsupported
pata_rz1000: Power Management fix
pata_sis: Power Management fix
pata_via: clear UDMA transfer mode bit for PIO and MWDMA

drivers/ata/Kconfig | 14 ++++++++++++--
drivers/ata/ata_piix.c | 6 +++---
drivers/ata/pata_cs5520.c | 39 +--------------------------------------
drivers/ata/pata_efar.c | 9 +++++----
drivers/ata/pata_hpt3x2n.c | 3 +--
drivers/ata/pata_hpt3x3.c | 11 ++++++++++-
drivers/ata/pata_it8213.c | 27 +++++++++++++--------------
drivers/ata/pata_legacy.c | 14 +++++++++++---
drivers/ata/pata_marvell.c | 2 +-
drivers/ata/pata_ns87415.c | 32 +++++++++++++++++++++++++++-----
drivers/ata/pata_oldpiix.c | 2 +-
drivers/ata/pata_radisys.c | 4 ++--
drivers/ata/pata_rdc.c | 2 +-
drivers/ata/pata_rz1000.c | 11 ++++++++++-
drivers/ata/pata_sis.c | 21 +++++++++++++++++++--
drivers/ata/pata_via.c | 19 +++++++++++++------
drivers/ide/ide-pci-generic.c | 2 +-
17 files changed, 131 insertions(+), 87 deletions(-)

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 676f08b..25cb4e7 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -287,8 +287,11 @@ config PATA_CMD640_PCI
depends on PCI && EXPERIMENTAL
help
This option enables support for the CMD640 PCI IDE
- interface chip. Only the primary channel is currently
- supported.
+ interface chip.
+
+ Known issues:
+ - only the primary channel is currently supported
+ - only the PCI chip interface is currently supported

If unsure, say N.

@@ -344,6 +347,9 @@ config PATA_CYPRESS
This option enables support for the Cypress/Contaq CY82C693
chipset found in some Alpha systems

+ Known issues:
+ - only the primary channel is currently supported
+
If unsure, say N.

config PATA_EFAR
@@ -588,6 +594,10 @@ config PATA_PDC_OLD
This option enables support for the Promise 20246, 20262, 20263,
20265 and 20267 adapters.

+ Known issues:
+ - UDMA transfers fail mysteriously on some chipsets
+ - ATAPI DMA is unsupported currently
+
If unsure, say N.

config PATA_QDI
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 9ac4e37..0c6155f 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -869,10 +869,10 @@ static void do_pata_set_dmamode(struct ata_port *ap, struct ata_device *adev, in
(timings[pio][1] << 8);
}

- if (ap->udma_mask) {
+ if (ap->udma_mask)
udma_enable &= ~(1 << devid);
- pci_write_config_word(dev, master_port, master_data);
- }
+
+ pci_write_config_word(dev, master_port, master_data);
}
/* Don't scribble on 0x48 if the controller does not support UDMA */
if (ap->udma_mask)
diff --git a/drivers/ata/pata_cs5520.c b/drivers/ata/pata_cs5520.c
index 0df83cf..95ebdac 100644
--- a/drivers/ata/pata_cs5520.c
+++ b/drivers/ata/pata_cs5520.c
@@ -90,48 +90,12 @@ static void cs5520_set_timings(struct ata_port *ap, struct ata_device *adev, int
}

/**
- * cs5520_enable_dma - turn on DMA bits
- *
- * Turn on the DMA bits for this disk. Needed because the BIOS probably
- * has not done the work for us. Belongs in the core SATA code.
- */
-
-static void cs5520_enable_dma(struct ata_port *ap, struct ata_device *adev)
-{
- /* Set the DMA enable/disable flag */
- u8 reg = ioread8(ap->ioaddr.bmdma_addr + 0x02);
- reg |= 1<<(adev->devno + 5);
- iowrite8(reg, ap->ioaddr.bmdma_addr + 0x02);
-}
-
-/**
- * cs5520_set_dmamode - program DMA timings
- * @ap: ATA port
- * @adev: ATA device
- *
- * Program the DMA mode timings for the controller according to the pio
- * clocking table. Note that this device sets the DMA timings to PIO
- * mode values. This may seem bizarre but the 5520 architecture talks
- * PIO mode to the disk and DMA mode to the controller so the underlying
- * transfers are PIO timed.
- */
-
-static void cs5520_set_dmamode(struct ata_port *ap, struct ata_device *adev)
-{
- static const int dma_xlate[3] = { XFER_PIO_0, XFER_PIO_3, XFER_PIO_4 };
- cs5520_set_timings(ap, adev, dma_xlate[adev->dma_mode]);
- cs5520_enable_dma(ap, adev);
-}
-
-/**
* cs5520_set_piomode - program PIO timings
* @ap: ATA port
* @adev: ATA device
*
* Program the PIO mode timings for the controller according to the pio
- * clocking table. We know pio_mode will equal dma_mode because of the
- * CS5520 architecture. At least once we turned DMA on and wrote a
- * mode setter.
+ * clocking table.
*/

static void cs5520_set_piomode(struct ata_port *ap, struct ata_device *adev)
@@ -149,7 +113,6 @@ static struct ata_port_operations cs5520_port_ops = {
.qc_prep = ata_sff_dumb_qc_prep,
.cable_detect = ata_cable_40wire,
.set_piomode = cs5520_set_piomode,
- .set_dmamode = cs5520_set_dmamode,
};

static int __devinit cs5520_init_one(struct pci_dev *pdev, const struct pci_device_id *id)
diff --git a/drivers/ata/pata_efar.c b/drivers/ata/pata_efar.c
index 2a6412f..b2e71e6 100644
--- a/drivers/ata/pata_efar.c
+++ b/drivers/ata/pata_efar.c
@@ -2,6 +2,7 @@
* pata_efar.c - EFAR PIIX clone controller driver
*
* (C) 2005 Red Hat
+ * (C) 2009 Bartlomiej Zolnierkiewicz
*
* Some parts based on ata_piix.c by Jeff Garzik and others.
*
@@ -118,12 +119,12 @@ static void efar_set_piomode (struct ata_port *ap, struct ata_device *adev)
int shift = 4 * ap->port_no;
u8 slave_data;

- idetm_data &= 0xCC0F;
+ idetm_data &= 0xFF0F;
idetm_data |= (control << 4);

/* Slave timing in separate register */
pci_read_config_byte(dev, 0x44, &slave_data);
- slave_data &= 0x0F << shift;
+ slave_data &= ap->port_no ? 0x0F : 0xF0;
slave_data |= ((timings[pio][0] << 2) | timings[pio][1]) << shift;
pci_write_config_byte(dev, 0x44, slave_data);
}
@@ -200,7 +201,7 @@ static void efar_set_dmamode (struct ata_port *ap, struct ata_device *adev)
master_data &= 0xFF4F; /* Mask out IORDY|TIME1|DMAONLY */
master_data |= control << 4;
pci_read_config_byte(dev, 0x44, &slave_data);
- slave_data &= (0x0F + 0xE1 * ap->port_no);
+ slave_data &= ap->port_no ? 0x0F : 0xF0;
/* Load the matching timing */
slave_data |= ((timings[pio][0] << 2) | timings[pio][1]) << (ap->port_no ? 4 : 0);
pci_write_config_byte(dev, 0x44, slave_data);
@@ -251,7 +252,7 @@ static int efar_init_one (struct pci_dev *pdev, const struct pci_device_id *ent)
static const struct ata_port_info info = {
.flags = ATA_FLAG_SLAVE_POSS,
.pio_mask = ATA_PIO4,
- .mwdma_mask = ATA_MWDMA2,
+ .mwdma_mask = ATA_MWDMA12_ONLY,
.udma_mask = ATA_UDMA4,
.port_ops = &efar_ops,
};
diff --git a/drivers/ata/pata_hpt3x2n.c b/drivers/ata/pata_hpt3x2n.c
index d30da80..9a09a1b 100644
--- a/drivers/ata/pata_hpt3x2n.c
+++ b/drivers/ata/pata_hpt3x2n.c
@@ -80,14 +80,13 @@ static struct hpt_clock hpt3x2n_clocks[] = {

{ XFER_MW_DMA_2, 0x2c829c62 },
{ XFER_MW_DMA_1, 0x2c829c66 },
- { XFER_MW_DMA_0, 0x2c829d2c },
+ { XFER_MW_DMA_0, 0x2c829d2e },

{ XFER_PIO_4, 0x0c829c62 },
{ XFER_PIO_3, 0x0c829c84 },
{ XFER_PIO_2, 0x0c829ca6 },
{ XFER_PIO_1, 0x0d029d26 },
{ XFER_PIO_0, 0x0d029d5e },
- { 0, 0x0d029d5e }
};

/**
diff --git a/drivers/ata/pata_hpt3x3.c b/drivers/ata/pata_hpt3x3.c
index 7e31025..c86c716 100644
--- a/drivers/ata/pata_hpt3x3.c
+++ b/drivers/ata/pata_hpt3x3.c
@@ -255,8 +255,17 @@ static int hpt3x3_init_one(struct pci_dev *pdev, const struct pci_device_id *id)
#ifdef CONFIG_PM
static int hpt3x3_reinit_one(struct pci_dev *dev)
{
+ struct ata_host *host = dev_get_drvdata(&dev->dev);
+ int rc;
+
+ rc = ata_pci_device_do_resume(dev);
+ if (rc)
+ return rc;
+
hpt3x3_init_chipset(dev);
- return ata_pci_device_resume(dev);
+
+ ata_host_resume(host);
+ return 0;
}
#endif

diff --git a/drivers/ata/pata_it8213.c b/drivers/ata/pata_it8213.c
index f156da8..8f3325a 100644
--- a/drivers/ata/pata_it8213.c
+++ b/drivers/ata/pata_it8213.c
@@ -22,7 +22,7 @@
#define DRV_VERSION "0.0.3"

/**
- * it8213_pre_reset - check for 40/80 pin
+ * it8213_pre_reset - probe begin
* @link: link
* @deadline: deadline jiffies for the operation
*
@@ -92,18 +92,17 @@ static void it8213_set_piomode (struct ata_port *ap, struct ata_device *adev)
{ 2, 1 },
{ 2, 3 }, };

- if (pio > 2)
- control |= 1; /* TIME1 enable */
+ if (pio > 1)
+ control |= 1; /* TIME */
if (ata_pio_need_iordy(adev)) /* PIO 3/4 require IORDY */
- control |= 2; /* IORDY enable */
+ control |= 2; /* IE */
/* Bit 2 is set for ATAPI on the IT8213 - reverse of ICH/PIIX */
if (adev->class != ATA_DEV_ATA)
- control |= 4;
+ control |= 4; /* PPE */

pci_read_config_word(dev, idetm_port, &idetm_data);

- /* Enable PPE, IE and TIME as appropriate */
-
+ /* Set PPE, IE, and TIME as appropriate */
if (adev->devno == 0) {
idetm_data &= 0xCCF0;
idetm_data |= control;
@@ -112,17 +111,17 @@ static void it8213_set_piomode (struct ata_port *ap, struct ata_device *adev)
} else {
u8 slave_data;

- idetm_data &= 0xCC0F;
+ idetm_data &= 0xFF0F;
idetm_data |= (control << 4);

/* Slave timing in separate register */
pci_read_config_byte(dev, 0x44, &slave_data);
slave_data &= 0xF0;
- slave_data |= ((timings[pio][0] << 2) | timings[pio][1]) << 4;
+ slave_data |= (timings[pio][0] << 2) | timings[pio][1];
pci_write_config_byte(dev, 0x44, slave_data);
}

- idetm_data |= 0x4000; /* Ensure SITRE is enabled */
+ idetm_data |= 0x4000; /* Ensure SITRE is set */
pci_write_config_word(dev, idetm_port, idetm_data);
}

@@ -173,10 +172,10 @@ static void it8213_set_dmamode (struct ata_port *ap, struct ata_device *adev)

udma_enable |= (1 << devid);

- /* Load the UDMA mode number */
+ /* Load the UDMA cycle time */
pci_read_config_word(dev, 0x4A, &udma_timing);
udma_timing &= ~(3 << (4 * devid));
- udma_timing |= (udma & 3) << (4 * devid);
+ udma_timing |= u_speed << (4 * devid);
pci_write_config_word(dev, 0x4A, udma_timing);

/* Load the clock selection */
@@ -211,7 +210,7 @@ static void it8213_set_dmamode (struct ata_port *ap, struct ata_device *adev)
master_data &= 0xFF4F; /* Mask out IORDY|TIME1|DMAONLY */
master_data |= control << 4;
pci_read_config_byte(dev, 0x44, &slave_data);
- slave_data &= (0x0F + 0xE1 * ap->port_no);
+ slave_data &= 0xF0;
/* Load the matching timing */
slave_data |= ((timings[pio][0] << 2) | timings[pio][1]) << (ap->port_no ? 4 : 0);
pci_write_config_byte(dev, 0x44, slave_data);
@@ -263,7 +262,7 @@ static int it8213_init_one (struct pci_dev *pdev, const struct pci_device_id *en
static const struct ata_port_info info = {
.flags = ATA_FLAG_SLAVE_POSS,
.pio_mask = ATA_PIO4,
- .mwdma_mask = ATA_MWDMA2,
+ .mwdma_mask = ATA_MWDMA12_ONLY,
.udma_mask = ATA_UDMA4, /* FIXME: want UDMA 100? */
.port_ops = &it8213_ops,
};
diff --git a/drivers/ata/pata_legacy.c b/drivers/ata/pata_legacy.c
index 6932e56..9df1ff7 100644
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -25,6 +25,13 @@
* http://www.ryston.cz/petr/vlb/pdc20230b.html
* http://www.ryston.cz/petr/vlb/pdc20230c.html
* http://www.ryston.cz/petr/vlb/pdc20630.html
+ * QDI65x0:
+ * http://www.ryston.cz/petr/vlb/qd6500.html
+ * http://www.ryston.cz/petr/vlb/qd6580.html
+ *
+ * QDI65x0 probe code based on drivers/ide/legacy/qd65xx.c
+ * Rewritten from the work of Colten Edwards <pje120 [at] cs> by
+ * Samuel Thibault <samuel.thibault [at] ens-lyon>
*
* Unsupported but docs exist:
* Appian/Adaptec AIC25VL01/Cirrus Logic PD7220
@@ -35,7 +42,7 @@
* the MPIIX where the tuning is PCI side but the IDE is "ISA side".
*
* Specific support is included for the ht6560a/ht6560b/opti82c611a/
- * opti82c465mv/promise 20230c/20630/winbond83759A
+ * opti82c465mv/promise 20230c/20630/qdi65x0/winbond83759A
*
* Use the autospeed and pio_mask options with:
* Appian ADI/2 aka CLPD7220 or AIC25VL01.
@@ -672,7 +679,7 @@ static void qdi6580dp_set_piomode(struct ata_port *ap, struct ata_device *adev)
outb(timing, ld_qdi->timing + 2 * ap->port_no);
/* Clear the FIFO */
if (adev->class != ATA_DEV_ATA)
- outb(0x5F, ld_qdi->timing + 3);
+ outb(0x5F, (ld_qdi->timing & 0xFFF0) + 3);
}

/**
@@ -707,7 +714,7 @@ static void qdi6580_set_piomode(struct ata_port *ap, struct ata_device *adev)
outb(timing, ld_qdi->timing + 2 * adev->devno);
/* Clear the FIFO */
if (adev->class != ATA_DEV_ATA)
- outb(0x5F, ld_qdi->timing + 3);
+ outb(0x5F, (ld_qdi->timing & 0xFFF0) + 3);
}

/**
@@ -787,6 +794,7 @@ static struct ata_port_operations qdi6580_port_ops = {
static struct ata_port_operations qdi6580dp_port_ops = {
.inherits = &legacy_base_port_ops,
.set_piomode = qdi6580dp_set_piomode,
+ .qc_issue = qdi_qc_issue,
.sff_data_xfer = vlb32_data_xfer,
};

diff --git a/drivers/ata/pata_marvell.c b/drivers/ata/pata_marvell.c
index 2096fb7..950da39 100644
--- a/drivers/ata/pata_marvell.c
+++ b/drivers/ata/pata_marvell.c
@@ -58,7 +58,7 @@ static int marvell_pata_active(struct pci_dev *pdev)
}

/**
- * marvell_pre_reset - check for 40/80 pin
+ * marvell_pre_reset - probe begin
* @link: link
* @deadline: deadline jiffies for the operation
*
diff --git a/drivers/ata/pata_ns87415.c b/drivers/ata/pata_ns87415.c
index 773b159..061aa1c 100644
--- a/drivers/ata/pata_ns87415.c
+++ b/drivers/ata/pata_ns87415.c
@@ -325,6 +325,13 @@ static struct scsi_host_template ns87415_sht = {
ATA_BMDMA_SHT(DRV_NAME),
};

+static void ns87415_fixup(struct pci_dev *pdev)
+{
+ /* Select 512 byte sectors */
+ pci_write_config_byte(pdev, 0x55, 0xEE);
+ /* Select PIO0 8bit clocking */
+ pci_write_config_byte(pdev, 0x54, 0xB7);
+}

/**
* ns87415_init_one - Register 87415 ATA PCI device with kernel services
@@ -371,10 +378,8 @@ static int ns87415_init_one (struct pci_dev *pdev, const struct pci_device_id *e
if (rc)
return rc;

- /* Select 512 byte sectors */
- pci_write_config_byte(pdev, 0x55, 0xEE);
- /* Select PIO0 8bit clocking */
- pci_write_config_byte(pdev, 0x54, 0xB7);
+ ns87415_fixup(pdev);
+
return ata_pci_sff_init_one(pdev, ppi, &ns87415_sht, NULL);
}

@@ -384,6 +389,23 @@ static const struct pci_device_id ns87415_pci_tbl[] = {
{ } /* terminate list */
};

+#ifdef CONFIG_PM
+static int ns87415_reinit_one(struct pci_dev *pdev)
+{
+ struct ata_host *host = dev_get_drvdata(&pdev->dev);
+ int rc;
+
+ rc = ata_pci_device_do_resume(pdev);
+ if (rc)
+ return rc;
+
+ ns87415_fixup(pdev);
+
+ ata_host_resume(host);
+ return 0;
+}
+#endif
+
static struct pci_driver ns87415_pci_driver = {
.name = DRV_NAME,
.id_table = ns87415_pci_tbl,
@@ -391,7 +413,7 @@ static struct pci_driver ns87415_pci_driver = {
.remove = ata_pci_remove_one,
#ifdef CONFIG_PM
.suspend = ata_pci_device_suspend,
- .resume = ata_pci_device_resume,
+ .resume = ns87415_reinit_one,
#endif
};

diff --git a/drivers/ata/pata_oldpiix.c b/drivers/ata/pata_oldpiix.c
index 84ac503..9a8687d 100644
--- a/drivers/ata/pata_oldpiix.c
+++ b/drivers/ata/pata_oldpiix.c
@@ -239,7 +239,7 @@ static int oldpiix_init_one (struct pci_dev *pdev, const struct pci_device_id *e
static const struct ata_port_info info = {
.flags = ATA_FLAG_SLAVE_POSS,
.pio_mask = ATA_PIO4,
- .mwdma_mask = ATA_MWDMA2,
+ .mwdma_mask = ATA_MWDMA12_ONLY,
.port_ops = &oldpiix_pata_ops,
};
const struct ata_port_info *ppi[] = { &info, NULL };
diff --git a/drivers/ata/pata_radisys.c b/drivers/ata/pata_radisys.c
index 4401b33..4fd25e7 100644
--- a/drivers/ata/pata_radisys.c
+++ b/drivers/ata/pata_radisys.c
@@ -139,9 +139,9 @@ static void radisys_set_dmamode (struct ata_port *ap, struct ata_device *adev)
pci_read_config_byte(dev, 0x4A, &udma_mode);

if (adev->xfer_mode == XFER_UDMA_2)
- udma_mode &= ~ (1 << adev->devno);
+ udma_mode &= ~(2 << (adev->devno * 4));
else /* UDMA 4 */
- udma_mode |= (1 << adev->devno);
+ udma_mode |= (2 << (adev->devno * 4));

pci_write_config_byte(dev, 0x4A, udma_mode);

diff --git a/drivers/ata/pata_rdc.c b/drivers/ata/pata_rdc.c
index c843a1e..237a24d 100644
--- a/drivers/ata/pata_rdc.c
+++ b/drivers/ata/pata_rdc.c
@@ -284,7 +284,7 @@ static struct ata_port_info rdc_port_info = {

.flags = ATA_FLAG_SLAVE_POSS,
.pio_mask = ATA_PIO4,
- .mwdma_mask = ATA_MWDMA2,
+ .mwdma_mask = ATA_MWDMA12_ONLY,
.udma_mask = ATA_UDMA5,
.port_ops = &rdc_pata_ops,
};
diff --git a/drivers/ata/pata_rz1000.c b/drivers/ata/pata_rz1000.c
index a5e4dfe..2932998 100644
--- a/drivers/ata/pata_rz1000.c
+++ b/drivers/ata/pata_rz1000.c
@@ -105,11 +105,20 @@ static int rz1000_init_one (struct pci_dev *pdev, const struct pci_device_id *en
#ifdef CONFIG_PM
static int rz1000_reinit_one(struct pci_dev *pdev)
{
+ struct ata_host *host = dev_get_drvdata(&pdev->dev);
+ int rc;
+
+ rc = ata_pci_device_do_resume(pdev);
+ if (rc)
+ return rc;
+
/* If this fails on resume (which is a "cant happen" case), we
must stop as any progress risks data loss */
if (rz1000_fifo_disable(pdev))
panic("rz1000 fifo");
- return ata_pci_device_resume(pdev);
+
+ ata_host_resume(host);
+ return 0;
}
#endif

diff --git a/drivers/ata/pata_sis.c b/drivers/ata/pata_sis.c
index d70ecec..8af0dc8 100644
--- a/drivers/ata/pata_sis.c
+++ b/drivers/ata/pata_sis.c
@@ -2,7 +2,7 @@
* pata_sis.c - SiS ATA driver
*
* (C) 2005 Red Hat
- * (C) 2007 Bartlomiej Zolnierkiewicz
+ * (C) 2007,2009 Bartlomiej Zolnierkiewicz
*
* Based upon linux/drivers/ide/pci/sis5513.c
* Copyright (C) 1999-2000 Andre Hedrick <andre [at] linux-ide>
@@ -876,6 +876,23 @@ static int sis_init_one (struct pci_dev *pdev, const struct pci_device_id *ent)
return ata_pci_sff_init_one(pdev, ppi, &sis_sht, chipset);
}

+#ifdef CONFIG_PM
+static int sis_reinit_one(struct pci_dev *pdev)
+{
+ struct ata_host *host = dev_get_drvdata(&pdev->dev);
+ int rc;
+
+ rc = ata_pci_device_do_resume(pdev);
+ if (rc)
+ return rc;
+
+ sis_fixup(pdev, host->private_data);
+
+ ata_host_resume(host);
+ return 0;
+}
+#endif
+
static const struct pci_device_id sis_pci_tbl[] = {
{ PCI_VDEVICE(SI, 0x5513), }, /* SiS 5513 */
{ PCI_VDEVICE(SI, 0x5518), }, /* SiS 5518 */
@@ -891,7 +908,7 @@ static struct pci_driver sis_pci_driver = {
.remove = ata_pci_remove_one,
#ifdef CONFIG_PM
.suspend = ata_pci_device_suspend,
- .resume = ata_pci_device_resume,
+ .resume = sis_reinit_one,
#endif
};

diff --git a/drivers/ata/pata_via.c b/drivers/ata/pata_via.c
index 78eac27..0d97890 100644
--- a/drivers/ata/pata_via.c
+++ b/drivers/ata/pata_via.c
@@ -303,14 +303,21 @@ static void via_do_set_mode(struct ata_port *ap, struct ata_device *adev, int mo
}

/* Set UDMA unless device is not UDMA capable */
- if (udma_type && t.udma) {
- u8 cable80_status;
+ if (udma_type) {
+ u8 udma_etc;

- /* Get 80-wire cable detection bit */
- pci_read_config_byte(pdev, 0x50 + offset, &cable80_status);
- cable80_status &= 0x10;
+ pci_read_config_byte(pdev, 0x50 + offset, &udma_etc);

- pci_write_config_byte(pdev, 0x50 + offset, ut | cable80_status);
+ /* clear transfer mode bit */
+ udma_etc &= ~0x20;
+
+ if (t.udma) {
+ /* preserve 80-wire cable detection bit */
+ udma_etc &= 0x10;
+ udma_etc |= ut;
+ }
+
+ pci_write_config_byte(pdev, 0x50 + offset, udma_etc);
}
}

diff --git a/drivers/ide/ide-pci-generic.c b/drivers/ide/ide-pci-generic.c
index 3f0bc42..a743e68 100644
--- a/drivers/ide/ide-pci-generic.c
+++ b/drivers/ide/ide-pci-generic.c
@@ -165,7 +165,7 @@ static const struct pci_device_id generic_pci_tbl[] = {
{ PCI_VDEVICE(TOSHIBA, PCI_DEVICE_ID_TOSHIBA_PICCOLO_1), 4 },
{ PCI_VDEVICE(TOSHIBA, PCI_DEVICE_ID_TOSHIBA_PICCOLO_2), 4 },
{ PCI_VDEVICE(TOSHIBA, PCI_DEVICE_ID_TOSHIBA_PICCOLO_3), 4 },
- { PCI_VDEVICE(TOSHIBA, PCI_DEVICE_ID_TOSHIBA_PICCOLO_5) 4 },
+ { PCI_VDEVICE(TOSHIBA, PCI_DEVICE_ID_TOSHIBA_PICCOLO_5), 4 },
{ PCI_VDEVICE(NETCELL, PCI_DEVICE_ID_REVOLUTION), 6 },
/*
* Must come last. If you add entries adjust
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jeff at garzik

Dec 3, 2009, 12:11 PM

Post #11 of 36 (575 views)
Permalink
Re: [PATCH 00/86] PATA fixes [In reply to]

On 12/03/2009 02:45 PM, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 03 December 2009 06:53:59 pm Jeff Garzik wrote:
>> On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote:
>>> On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote:
>>>> The merge window is upon us, which by strict rules means that anything
>>>> not already in libata-dev.git#upstream needs to wait until 2.6.34.
>>>>
>>>> However, bug fixes and the like should definitely be in 2.6.33.
>>>> ->init_host is definitely 2.6.34 material. Some of the other stuff
>>>> could go either way.
>>
>>> If you would like to apply some of my patches to 2.6.33 you are more than
>>> welcome to do it. I can even prepare separate git tree with specific changes
>>> to make it easier for you once you tell me which changes you would like to
>>> see in it.
>>
>> OK, great.
>>
>> Can you prepare a patchset containing only fixes? Comment-only changes
>> are acceptable too. Trivial changes too, if they are extremely trivial :)
>>
>> Include nothing that adds features, removes or unifies drivers, etc.
>
> Since this is pretty high-level description and some changes fall into
> many categories at once (i.e. addition of proper PCI Power Management
> handling could be considered both as a fix and as a feature) I prepared
> a rather conservative set of changes (which means that unfortunately
> it misses many enhancements available in my tree):
>
>> Please do it in standard kernel submit form, which is either
>> (a) repost the patches (yes, again) being submitted for 2.6.33, or
>> (b) a standard git pull request, which includes shortlog, diffstat, and
>> all-in-one diff.
>
> Thank you for the detailed explanation of the standard kernel submit
> form (I wonder how would I know this otherwise :) but the thing is that
> at the current moment I'm not submitting anything to the upstream.

Ok, that explains my confusion, then. I had thought you intended to get
this stuff upstream, and into users' hands.


> That's it. While this may sound strange to some people it turns out
> that in practice it is much less hassle for me personally to keep some
> of trees outside of the (sometimes greatly overrated) upstream.
>
> If knowing the above you still would like to include the aforementioned
> set of changes in your libata-dev tree they are at kernel.org now.

I will go through this batch and cherry-pick. The build fix is already
in my tree. Existing kernel practice (and previous comments) indicate
that lists of known issues do not belong in Kconfig. Will take a look
at the other stuff...

Thanks,

Jeff



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


bzolnier at gmail

Dec 3, 2009, 12:26 PM

Post #12 of 36 (575 views)
Permalink
Re: [PATCH 00/86] PATA fixes [In reply to]

On Thursday 03 December 2009 09:11:19 pm Jeff Garzik wrote:
> On 12/03/2009 02:45 PM, Bartlomiej Zolnierkiewicz wrote:
> > On Thursday 03 December 2009 06:53:59 pm Jeff Garzik wrote:
> >> On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote:
> >>> On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote:
> >>>> The merge window is upon us, which by strict rules means that anything
> >>>> not already in libata-dev.git#upstream needs to wait until 2.6.34.
> >>>>
> >>>> However, bug fixes and the like should definitely be in 2.6.33.
> >>>> ->init_host is definitely 2.6.34 material. Some of the other stuff
> >>>> could go either way.
> >>
> >>> If you would like to apply some of my patches to 2.6.33 you are more than
> >>> welcome to do it. I can even prepare separate git tree with specific changes
> >>> to make it easier for you once you tell me which changes you would like to
> >>> see in it.
> >>
> >> OK, great.
> >>
> >> Can you prepare a patchset containing only fixes? Comment-only changes
> >> are acceptable too. Trivial changes too, if they are extremely trivial :)
> >>
> >> Include nothing that adds features, removes or unifies drivers, etc.
> >
> > Since this is pretty high-level description and some changes fall into
> > many categories at once (i.e. addition of proper PCI Power Management
> > handling could be considered both as a fix and as a feature) I prepared
> > a rather conservative set of changes (which means that unfortunately
> > it misses many enhancements available in my tree):
> >
> >> Please do it in standard kernel submit form, which is either
> >> (a) repost the patches (yes, again) being submitted for 2.6.33, or
> >> (b) a standard git pull request, which includes shortlog, diffstat, and
> >> all-in-one diff.
> >
> > Thank you for the detailed explanation of the standard kernel submit
> > form (I wonder how would I know this otherwise :) but the thing is that
> > at the current moment I'm not submitting anything to the upstream.
>
> Ok, that explains my confusion, then. I had thought you intended to get
> this stuff upstream, and into users' hands.

Interesting argument but the vast majority of users use distribution kernels
which are not upstream and I doubt that any self-respecting distribution would
miss such amount of fixes.

The rest can easily use my tree which follows upstream closely and can be
obtained using a single line git command.

> > That's it. While this may sound strange to some people it turns out
> > that in practice it is much less hassle for me personally to keep some
> > of trees outside of the (sometimes greatly overrated) upstream.
> >
> > If knowing the above you still would like to include the aforementioned
> > set of changes in your libata-dev tree they are at kernel.org now.
>
> I will go through this batch and cherry-pick. The build fix is already
> in my tree. Existing kernel practice (and previous comments) indicate
> that lists of known issues do not belong in Kconfig. Will take a look
> at the other stuff...

Well, you were aware that they were not dropped so you could have easily told
me that you specifically don't want this patches in the for-2.6.33 tree..

--
Bartlomiej Zolnierkiewicz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jeff at garzik

Dec 3, 2009, 12:39 PM

Post #13 of 36 (576 views)
Permalink
Re: [PATCH 00/86] PATA fixes [In reply to]

On 12/03/2009 03:26 PM, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 03 December 2009 09:11:19 pm Jeff Garzik wrote:
>> On 12/03/2009 02:45 PM, Bartlomiej Zolnierkiewicz wrote:
>>> On Thursday 03 December 2009 06:53:59 pm Jeff Garzik wrote:
>>>> On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote:
>>>>> On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote:
>>>>>> The merge window is upon us, which by strict rules means that anything
>>>>>> not already in libata-dev.git#upstream needs to wait until 2.6.34.
>>>>>>
>>>>>> However, bug fixes and the like should definitely be in 2.6.33.
>>>>>> ->init_host is definitely 2.6.34 material. Some of the other stuff
>>>>>> could go either way.
>>>>
>>>>> If you would like to apply some of my patches to 2.6.33 you are more than
>>>>> welcome to do it. I can even prepare separate git tree with specific changes
>>>>> to make it easier for you once you tell me which changes you would like to
>>>>> see in it.
>>>>
>>>> OK, great.
>>>>
>>>> Can you prepare a patchset containing only fixes? Comment-only changes
>>>> are acceptable too. Trivial changes too, if they are extremely trivial :)
>>>>
>>>> Include nothing that adds features, removes or unifies drivers, etc.
>>>
>>> Since this is pretty high-level description and some changes fall into
>>> many categories at once (i.e. addition of proper PCI Power Management
>>> handling could be considered both as a fix and as a feature) I prepared
>>> a rather conservative set of changes (which means that unfortunately
>>> it misses many enhancements available in my tree):
>>>
>>>> Please do it in standard kernel submit form, which is either
>>>> (a) repost the patches (yes, again) being submitted for 2.6.33, or
>>>> (b) a standard git pull request, which includes shortlog, diffstat, and
>>>> all-in-one diff.
>>>
>>> Thank you for the detailed explanation of the standard kernel submit
>>> form (I wonder how would I know this otherwise :) but the thing is that
>>> at the current moment I'm not submitting anything to the upstream.
>>
>> Ok, that explains my confusion, then. I had thought you intended to get
>> this stuff upstream, and into users' hands.
>
> Interesting argument but the vast majority of users use distribution kernels
> which are not upstream and I doubt that any self-respecting distribution would
> miss such amount of fixes.

Interesting argument, but applied across 1000+ developers this is
clearly an unscalable development model for distributions. Thus,
patches go upstream, and are then distributed widely, to eliminate
massive amounts of duplicated work across distributions.

You are essentially implying that each distribution must

- discover your tree
- look through the mailing list to figure out why each of
~80 changes are not upstream
- individually make a decision on each of ~80 changes
- actively track your tree for updates, repeating this process
over and over again

Talk about a lot of unwanted work pushed upon OTHER people, all because
you choose to avoid the standard upstream development process.


>>> That's it. While this may sound strange to some people it turns out
>>> that in practice it is much less hassle for me personally to keep some
>>> of trees outside of the (sometimes greatly overrated) upstream.
>>>
>>> If knowing the above you still would like to include the aforementioned
>>> set of changes in your libata-dev tree they are at kernel.org now.
>>
>> I will go through this batch and cherry-pick. The build fix is already
>> in my tree. Existing kernel practice (and previous comments) indicate
>> that lists of known issues do not belong in Kconfig. Will take a look
>> at the other stuff...
>
> Well, you were aware that they were not dropped so you could have easily told
> me that you specifically don't want this patches in the for-2.6.33 tree..

At the time you built atang-2.6.33, you were aware that those Kconfig
changes were not wanted -at all-.

You tell others "I think that there were enough hints in my mail
already" then fail to apply this logic to yourself.

Jeff


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


davem at davemloft

Dec 3, 2009, 12:48 PM

Post #14 of 36 (577 views)
Permalink
Re: [PATCH 00/86] PATA fixes [In reply to]

From: Jeff Garzik <jeff [at] garzik>
Date: Thu, 03 Dec 2009 12:39:48 -0500

> On 12/03/2009 11:59 AM, Alan Cox wrote:
>>> The merge window is upon us, which by strict rules means that anything
>>> not already in libata-dev.git#upstream needs to wait until 2.6.34.
>>
>> Not quite yet - Linus hasn't said "go"
>
> He rarely if ever says "go." The kernel X is released, and people
> send pull requests to Linus for X+1. He typically merges immediately,
> but does not push out the first set of merges for a few days.

I don't think he even starts pulling until 1 or 2 days later.

I personally never send him a pull request until a day or two in.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


bzolnier at gmail

Dec 3, 2009, 1:01 PM

Post #15 of 36 (576 views)
Permalink
Re: [PATCH 00/86] PATA fixes [In reply to]

On Thursday 03 December 2009 09:39:39 pm Jeff Garzik wrote:
> On 12/03/2009 03:26 PM, Bartlomiej Zolnierkiewicz wrote:
> > On Thursday 03 December 2009 09:11:19 pm Jeff Garzik wrote:
> >> On 12/03/2009 02:45 PM, Bartlomiej Zolnierkiewicz wrote:
> >>> On Thursday 03 December 2009 06:53:59 pm Jeff Garzik wrote:
> >>>> On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote:
> >>>>> On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote:
> >>>>>> The merge window is upon us, which by strict rules means that anything
> >>>>>> not already in libata-dev.git#upstream needs to wait until 2.6.34.
> >>>>>>
> >>>>>> However, bug fixes and the like should definitely be in 2.6.33.
> >>>>>> ->init_host is definitely 2.6.34 material. Some of the other stuff
> >>>>>> could go either way.
> >>>>
> >>>>> If you would like to apply some of my patches to 2.6.33 you are more than
> >>>>> welcome to do it. I can even prepare separate git tree with specific changes
> >>>>> to make it easier for you once you tell me which changes you would like to
> >>>>> see in it.
> >>>>
> >>>> OK, great.
> >>>>
> >>>> Can you prepare a patchset containing only fixes? Comment-only changes
> >>>> are acceptable too. Trivial changes too, if they are extremely trivial :)
> >>>>
> >>>> Include nothing that adds features, removes or unifies drivers, etc.
> >>>
> >>> Since this is pretty high-level description and some changes fall into
> >>> many categories at once (i.e. addition of proper PCI Power Management
> >>> handling could be considered both as a fix and as a feature) I prepared
> >>> a rather conservative set of changes (which means that unfortunately
> >>> it misses many enhancements available in my tree):
> >>>
> >>>> Please do it in standard kernel submit form, which is either
> >>>> (a) repost the patches (yes, again) being submitted for 2.6.33, or
> >>>> (b) a standard git pull request, which includes shortlog, diffstat, and
> >>>> all-in-one diff.
> >>>
> >>> Thank you for the detailed explanation of the standard kernel submit
> >>> form (I wonder how would I know this otherwise :) but the thing is that
> >>> at the current moment I'm not submitting anything to the upstream.
> >>
> >> Ok, that explains my confusion, then. I had thought you intended to get
> >> this stuff upstream, and into users' hands.
> >
> > Interesting argument but the vast majority of users use distribution kernels
> > which are not upstream and I doubt that any self-respecting distribution would
> > miss such amount of fixes.
>
> Interesting argument, but applied across 1000+ developers this is
> clearly an unscalable development model for distributions. Thus,

Interesting that you have brought distributions' convenience before
non-distribution developers' one.

> patches go upstream, and are then distributed widely, to eliminate
> massive amounts of duplicated work across distributions.
>
> You are essentially implying that each distribution must
>
> - discover your tree
> - look through the mailing list to figure out why each of
> ~80 changes are not upstream
> - individually make a decision on each of ~80 changes
> - actively track your tree for updates, repeating this process
> over and over again

Not really.

I'm only saying that the upstream is so much hassle to deal with it that
it is up to people wanting to see my changes upstream to do the work on
integrating them upstream if they want to see them in upstream faster.

Fair enough?

> Talk about a lot of unwanted work pushed upon OTHER people, all because
> you choose to avoid the standard upstream development process.

I'm not forcing any work on anybody and I'm not avoiding the standard
process. I just find other things to have higher priority than pushing
these changes upstream right now.

> >>> That's it. While this may sound strange to some people it turns out
> >>> that in practice it is much less hassle for me personally to keep some
> >>> of trees outside of the (sometimes greatly overrated) upstream.
> >>>
> >>> If knowing the above you still would like to include the aforementioned
> >>> set of changes in your libata-dev tree they are at kernel.org now.
> >>
> >> I will go through this batch and cherry-pick. The build fix is already
> >> in my tree. Existing kernel practice (and previous comments) indicate
> >> that lists of known issues do not belong in Kconfig. Will take a look
> >> at the other stuff...
> >
> > Well, you were aware that they were not dropped so you could have easily told
> > me that you specifically don't want this patches in the for-2.6.33 tree..
>
> At the time you built atang-2.6.33, you were aware that those Kconfig
> changes were not wanted -at all-.

Why should I remember/care/worry about such details?

> You tell others "I think that there were enough hints in my mail
> already" then fail to apply this logic to yourself.

You forgot that it was you who have asked me to prepare this tree to
enhance your tree.

--
Bartlomiej Zolnierkiewicz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jeff at garzik

Dec 3, 2009, 1:16 PM

Post #16 of 36 (575 views)
Permalink
Re: [PATCH 00/86] PATA fixes [In reply to]

Alan,

Can you sanity check me on these?

> Bartlomiej Zolnierkiewicz (28):
> ide-pci-generic: build fix

ACK but skipped -- already applied myself

> ata_piix: fix MWDMA handling on PIIX3

applied

> pata_efar: fix wrong PIO timings being programmed

applied

> pata_efar: fix wrong MWDMA timings being programmed

applied

> pata_efar: MWDMA0 is unsupported

skipped, pending discussion (just sent email)

> pata_cmd640: document known issues

rejected, for reasons already explained

> pata_cs5520: remove dead VDMA support

applied

> pata_cypress: document known issues

rejected, for reasons already explained

> pata_hpt3x2n: fix overclocked MWDMA0 timing

skipped, pending discussion (just sent email)

> 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.

> pata_it8213: fix UDMA handling

applied

> pata_it8213: fix wrong PIO timings being programmed

applied

> pata_it8213: fix PIO2 underclocking

applied

> pata_it8213: fix wrong MWDMA timings being programmed

applied

> pata_it8213: fix it8213_pre_reset() documentation

applied

> pata_it8213: MWDMA0 is unsupported

skipped, pending discussion (just sent email)

> pata_legacy: fix QDI6580DP support

applied

> pata_legacy: fix access to control register for QDI6580

applied

> pata_legacy: add pointers to QDI65x0 documentation

applied. I did not think the file path issue raised was important
enough to warrant patch rejection.

> pata_marvell: fix marvell_pre_reset() documentation

applied

> pata_ns87415: Power Management fix

applied

> pata_oldpiix: MWDMA0 is unsupported

skipped -- Alan, Sergey, comments?

> pata_pdc202xx_old: document known issues

rejected, for reasons already explained

> pata_radisys: fix UDMA handling

applied

> pata_rdc: MWDMA0 is unsupported

skipped -- Alan, Sergey, comments?

> pata_rz1000: Power Management fix

applied

> pata_sis: Power Management fix

applied

> 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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jeff at garzik

Dec 3, 2009, 1:28 PM

Post #17 of 36 (576 views)
Permalink
Re: [PATCH 00/86] PATA fixes [In reply to]

On 12/03/2009 04:01 PM, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 03 December 2009 09:39:39 pm Jeff Garzik wrote:
>> On 12/03/2009 03:26 PM, Bartlomiej Zolnierkiewicz wrote:
>>> On Thursday 03 December 2009 09:11:19 pm Jeff Garzik wrote:
>>>> On 12/03/2009 02:45 PM, Bartlomiej Zolnierkiewicz wrote:
>>>>> On Thursday 03 December 2009 06:53:59 pm Jeff Garzik wrote:
>>>>>> On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote:
>>>>>>> On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote:
>>>>>>>> The merge window is upon us, which by strict rules means that anything
>>>>>>>> not already in libata-dev.git#upstream needs to wait until 2.6.34.
>>>>>>>>
>>>>>>>> However, bug fixes and the like should definitely be in 2.6.33.
>>>>>>>> ->init_host is definitely 2.6.34 material. Some of the other stuff
>>>>>>>> could go either way.
>>>>>>
>>>>>>> If you would like to apply some of my patches to 2.6.33 you are more than
>>>>>>> welcome to do it. I can even prepare separate git tree with specific changes
>>>>>>> to make it easier for you once you tell me which changes you would like to
>>>>>>> see in it.
>>>>>>
>>>>>> OK, great.
>>>>>>
>>>>>> Can you prepare a patchset containing only fixes? Comment-only changes
>>>>>> are acceptable too. Trivial changes too, if they are extremely trivial :)
>>>>>>
>>>>>> Include nothing that adds features, removes or unifies drivers, etc.
>>>>>
>>>>> Since this is pretty high-level description and some changes fall into
>>>>> many categories at once (i.e. addition of proper PCI Power Management
>>>>> handling could be considered both as a fix and as a feature) I prepared
>>>>> a rather conservative set of changes (which means that unfortunately
>>>>> it misses many enhancements available in my tree):
>>>>>
>>>>>> Please do it in standard kernel submit form, which is either
>>>>>> (a) repost the patches (yes, again) being submitted for 2.6.33, or
>>>>>> (b) a standard git pull request, which includes shortlog, diffstat, and
>>>>>> all-in-one diff.
>>>>>
>>>>> Thank you for the detailed explanation of the standard kernel submit
>>>>> form (I wonder how would I know this otherwise :) but the thing is that
>>>>> at the current moment I'm not submitting anything to the upstream.
>>>>
>>>> Ok, that explains my confusion, then. I had thought you intended to get
>>>> this stuff upstream, and into users' hands.
>>>
>>> Interesting argument but the vast majority of users use distribution kernels
>>> which are not upstream and I doubt that any self-respecting distribution would
>>> miss such amount of fixes.
>>
>> Interesting argument, but applied across 1000+ developers this is
>> clearly an unscalable development model for distributions. Thus,
>
> Interesting that you have brought distributions' convenience before
> non-distribution developers' one.

uhwhu? You brought up distributions.


>> patches go upstream, and are then distributed widely, to eliminate
>> massive amounts of duplicated work across distributions.
>>
>> You are essentially implying that each distribution must
>>
>> - discover your tree
>> - look through the mailing list to figure out why each of
>> ~80 changes are not upstream
>> - individually make a decision on each of ~80 changes
>> - actively track your tree for updates, repeating this process
>> over and over again
>
> Not really.
>
> I'm only saying that the upstream is so much hassle to deal with it that
> it is up to people wanting to see my changes upstream to do the work on
> integrating them upstream if they want to see them in upstream faster.
>
> Fair enough?

I respect your opinion, sure. And respect that your time is your own.
And appreciate you spending that time to batch together some patches.

But it is simple logic that a non-standard distribution method for your
changes implies a self-imposed limited distribution, with possibly
useful fixes and changes not getting into the hands of users that can
use them.

That's your choice -- but it surprised me, is all. Usually developers
are more eager to get their changes into wide distribution, because that
benefits the most Linux users.

If you fail to send changes upstream, most people will assume that you
do not consider your changes "ready" for users, "ready" for wide
distribution and use. Because that is the common practice for nearly
all other Linux kernel developers in all subsystems.

Jeff


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jeff at garzik

Dec 3, 2009, 1:32 PM

Post #18 of 36 (574 views)
Permalink
Re: [PATCH 00/86] PATA fixes [In reply to]

On 12/03/2009 03:48 PM, David Miller wrote:
> From: Jeff Garzik<jeff [at] garzik>
> Date: Thu, 03 Dec 2009 12:39:48 -0500
>
>> On 12/03/2009 11:59 AM, Alan Cox wrote:
>>>> The merge window is upon us, which by strict rules means that anything
>>>> not already in libata-dev.git#upstream needs to wait until 2.6.34.
>>>
>>> Not quite yet - Linus hasn't said "go"
>>
>> He rarely if ever says "go." The kernel X is released, and people
>> send pull requests to Linus for X+1. He typically merges immediately,
>> but does not push out the first set of merges for a few days.
>
> I don't think he even starts pulling until 1 or 2 days later.
>
> I personally never send him a pull request until a day or two in.

<shrug> In the past he has commented on pulls, indicating some sort of
immediate action, yet not pushed for a few days.

Not a big deal. Plenty of other people send pull requests immediately,
even if you ignore the high-volume Ingo special case <chuckle>

In any case, the basic point is that Linus does not say "go" for merge
windows. People send, he pulls when he chooses, and pushes when he
chooses. It's all very zen ;-)

Jeff




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


davem at davemloft

Dec 3, 2009, 1:41 PM

Post #19 of 36 (576 views)
Permalink
Re: [PATCH 00/86] PATA fixes [In reply to]

From: Jeff Garzik <jeff [at] garzik>
Date: Thu, 03 Dec 2009 16:32:13 -0500

> In any case, the basic point is that Linus does not say "go" for merge
> windows. People send, he pulls when he chooses, and pushes when he
> chooses. It's all very zen ;-)

True.

But I also want to mention that I wait 2 days for another reason,
so that whatever I do toss to him gets full exposure in -next
at least one time.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


bzolnier at gmail

Dec 3, 2009, 1:42 PM

Post #20 of 36 (576 views)
Permalink
Re: [PATCH 00/86] PATA fixes [In reply to]

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).

> > pata_hpt3x2n: fix overclocked MWDMA0 timing
>
> skipped, pending discussion (just sent email)

ditto (http://lkml.org/lkml/2009/11/27/257).

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

> > 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

> > 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?

--
Bartlomiej Zolnierkiewicz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jeff at garzik

Dec 3, 2009, 1:51 PM

Post #21 of 36 (575 views)
Permalink
Re: [PATCH 00/86] PATA fixes [In reply to]

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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


bzolnier at gmail

Dec 3, 2009, 1:56 PM

Post #22 of 36 (577 views)
Permalink
Re: [PATCH 00/86] PATA fixes [In reply to]

On Thursday 03 December 2009 10:51:09 pm Jeff Garzik wrote:

> >>> 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.

Indeed.

From 94be9a58d7e683ac3c1df1858a17f09ebade8da0 Mon Sep 17 00:00:00 2001
From: Jeff Garzik <jeff [at] garzik>
Date: Fri, 16 Jan 2009 10:17:09 -0500
Subject: [PATCH] [libata] get-identity ioctl: Fix use of invalid memory pointer
for SAS drivers.

Caught by Ke Wei (and team?) at Marvell.

Also, move the ata_scsi_ioctl export to libata-scsi.c, as that seems to be the
general trend.

Acked-by: James Bottomley <James.Bottomley [at] HansenPartnership>
Signed-off-by: Jeff Garzik <jgarzik [at] redhat>
---
drivers/ata/libata-core.c | 1 -
drivers/ata/libata-scsi.c | 17 +++++++++++++----
drivers/scsi/ipr.c | 2 +-
drivers/scsi/libsas/sas_scsi_host.c | 2 +-
include/linux/libata.h | 2 ++
5 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 71218d7..552ecae 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -6638,7 +6638,6 @@ EXPORT_SYMBOL_GPL(ata_dev_pair);
EXPORT_SYMBOL_GPL(ata_port_disable);
EXPORT_SYMBOL_GPL(ata_ratelimit);
EXPORT_SYMBOL_GPL(ata_wait_register);
-EXPORT_SYMBOL_GPL(ata_scsi_ioctl);
EXPORT_SYMBOL_GPL(ata_scsi_queuecmd);
EXPORT_SYMBOL_GPL(ata_scsi_slave_config);
EXPORT_SYMBOL_GPL(ata_scsi_slave_destroy);
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 9e92107..a1a6e62 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -423,9 +423,9 @@ int ata_std_bios_param(struct scsi_device *sdev, struct block_device *bdev,
* RETURNS:
* Zero on success, negative errno on error.
*/
-static int ata_get_identity(struct scsi_device *sdev, void __user *arg)
+static int ata_get_identity(struct ata_port *ap, struct scsi_device *sdev,
+ void __user *arg)
{
- struct ata_port *ap = ata_shost_to_port(sdev->host);
struct ata_device *dev = ata_scsi_find_dev(ap, sdev);
u16 __user *dst = arg;
char buf[40];
@@ -645,7 +645,8 @@ int ata_task_ioctl(struct scsi_device *scsidev, void __user *arg)
return rc;
}

-int ata_scsi_ioctl(struct scsi_device *scsidev, int cmd, void __user *arg)
+int ata_sas_scsi_ioctl(struct ata_port *ap, struct scsi_device *scsidev,
+ int cmd, void __user *arg)
{
int val = -EINVAL, rc = -EINVAL;

@@ -663,7 +664,7 @@ int ata_scsi_ioctl(struct scsi_device *scsidev, int cmd, void __user *arg)
return 0;

case HDIO_GET_IDENTITY:
- return ata_get_identity(scsidev, arg);
+ return ata_get_identity(ap, scsidev, arg);

case HDIO_DRIVE_CMD:
if (!capable(CAP_SYS_ADMIN) || !capable(CAP_SYS_RAWIO))
@@ -682,6 +683,14 @@ int ata_scsi_ioctl(struct scsi_device *scsidev, int cmd, void __user *arg)

return rc;
}
+EXPORT_SYMBOL_GPL(ata_sas_scsi_ioctl);
+
+int ata_scsi_ioctl(struct scsi_device *scsidev, int cmd, void __user *arg)
+{
+ return ata_sas_scsi_ioctl(ata_shost_to_port(scsidev->host),
+ scsidev, cmd, arg);
+}
+EXPORT_SYMBOL_GPL(ata_scsi_ioctl);

/**
* ata_scsi_qc_new - acquire new ata_queued_cmd reference
diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c
index 841f460..0782900 100644
--- a/drivers/scsi/ipr.c
+++ b/drivers/scsi/ipr.c
@@ -4912,7 +4912,7 @@ static int ipr_ioctl(struct scsi_device *sdev, int cmd, void __user *arg)
if (res && ipr_is_gata(res)) {
if (cmd == HDIO_GET_IDENTITY)
return -ENOTTY;
- return ata_scsi_ioctl(sdev, cmd, arg);
+ return ata_sas_scsi_ioctl(res->sata_port->ap, sdev, cmd, arg);
}

return -EINVAL;
diff --git a/drivers/scsi/libsas/sas_scsi_host.c b/drivers/scsi/libsas/sas_scsi_host.c
index 7448387..1c558d3 100644
--- a/drivers/scsi/libsas/sas_scsi_host.c
+++ b/drivers/scsi/libsas/sas_scsi_host.c
@@ -717,7 +717,7 @@ int sas_ioctl(struct scsi_device *sdev, int cmd, void __user *arg)
struct domain_device *dev = sdev_to_domain_dev(sdev);

if (dev_is_sata(dev))
- return ata_scsi_ioctl(sdev, cmd, arg);
+ return ata_sas_scsi_ioctl(dev->sata_dev.ap, sdev, cmd, arg);

return -EINVAL;
}
diff --git a/include/linux/libata.h b/include/linux/libata.h
index b6b8a7f..73b69c7 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -927,6 +927,8 @@ extern void ata_host_init(struct ata_host *, struct device *,
extern int ata_scsi_detect(struct scsi_host_template *sht);
extern int ata_scsi_ioctl(struct scsi_device *dev, int cmd, void __user *arg);
extern int ata_scsi_queuecmd(struct scsi_cmnd *cmd, void (*done)(struct scsi_cmnd *));
+extern int ata_sas_scsi_ioctl(struct ata_port *ap, struct scsi_device *dev,
+ int cmd, void __user *arg);
extern void ata_sas_port_destroy(struct ata_port *);
extern struct ata_port *ata_sas_port_alloc(struct ata_host *,
struct ata_port_info *, struct Scsi_Host *);
--
1.6.4.2



--
Bartlomiej Zolnierkiewicz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jeff at garzik

Dec 3, 2009, 2:02 PM

Post #23 of 36 (576 views)
Permalink
Re: [PATCH 00/86] PATA fixes [In reply to]

On 12/03/2009 04:56 PM, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 03 December 2009 10:51:09 pm Jeff Garzik wrote:
>
>>>>> 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.
>
> Indeed.
>
> From 94be9a58d7e683ac3c1df1858a17f09ebade8da0 Mon Sep 17 00:00:00 2001
> From: Jeff Garzik<jeff [at] garzik>
> Date: Fri, 16 Jan 2009 10:17:09 -0500
> Subject: [PATCH] [libata] get-identity ioctl: Fix use of invalid memory pointer
> for SAS drivers.
>
> Caught by Ke Wei (and team?) at Marvell.
>
> Also, move the ata_scsi_ioctl export to libata-scsi.c, as that seems to be the
> general trend.
>
> Acked-by: James Bottomley<James.Bottomley [at] HansenPartnership>
> Signed-off-by: Jeff Garzik<jgarzik [at] redhat>

If your point, by posting this patch, is that it includes a ton of
gratuitous cosmetic changes, you misread the patch.

ata_scsi_ioctl() remains in existence; only the callers need to use the
new SAS-related ioctl function were updated. The remainder continued to
use ata_scsi_ioctl().

Jeff




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


sshtylyov at ru

Dec 3, 2009, 2:02 PM

Post #24 of 36 (575 views)
Permalink
Re: [PATCH 00/86] PATA fixes [In reply to]

Hello.

Jeff Garzik wrote:

>> pata_efar: MWDMA0 is unsupported
>
> skipped, pending discussion (just sent email)

There's basically nothing to discuss -- the PIIX like chips don't
support MWDMA0 (with an acceptable cycle length, if at all, anyway). The
way the driver is written, MWDMA0 is simply programmed overclocked.

>
>> pata_hpt3x2n: fix overclocked MWDMA0 timing
>
> skipped, pending discussion (just sent email)


Nothing to discuss either, this looks like a single digit typo to me...

>
>> pata_hpt3x3: Power Management fix
>
> applied, on a hope and a prayer (did not see this posted to mailing
> list?).

http://marc.info/?l=linux-ide&m=125916980522990

>
>> pata_it8213: MWDMA0 is unsupported
>
> skipped, pending discussion (just sent email)

Nothing to discuss...

> pata_oldpiix: MWDMA0 is unsupported
>
> skipped -- Alan, Sergey, comments?

Acked-by: Sergei Shtylyov <sshtylyov [at] ru>

>
>> pata_rdc: MWDMA0 is unsupported
>
> skipped -- Alan, Sergey, comments?

Acked-by: Sergei Shtylyov <sshtylyov [at] ru>

MBR, Sergei


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


bzolnier at gmail

Dec 3, 2009, 2:06 PM

Post #25 of 36 (578 views)
Permalink
Re: [PATCH 00/86] PATA fixes [In reply to]

On Thursday 03 December 2009 11:02:36 pm Jeff Garzik wrote:
> On 12/03/2009 04:56 PM, Bartlomiej Zolnierkiewicz wrote:
> > On Thursday 03 December 2009 10:51:09 pm Jeff Garzik wrote:
> >
> >>>>> 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.
> >
> > Indeed.
> >
> > From 94be9a58d7e683ac3c1df1858a17f09ebade8da0 Mon Sep 17 00:00:00 2001
> > From: Jeff Garzik<jeff [at] garzik>
> > Date: Fri, 16 Jan 2009 10:17:09 -0500
> > Subject: [PATCH] [libata] get-identity ioctl: Fix use of invalid memory pointer
> > for SAS drivers.
> >
> > Caught by Ke Wei (and team?) at Marvell.
> >
> > Also, move the ata_scsi_ioctl export to libata-scsi.c, as that seems to be the
> > general trend.
> >
> > Acked-by: James Bottomley<James.Bottomley [at] HansenPartnership>
> > Signed-off-by: Jeff Garzik<jgarzik [at] redhat>
>
> If your point, by posting this patch, is that it includes a ton of
> gratuitous cosmetic changes, you misread the patch.
>
> ata_scsi_ioctl() remains in existence; only the callers need to use the
> new SAS-related ioctl function were updated. The remainder continued to
> use ata_scsi_ioctl().

Moving kernel exports around is completely unrelated to a bug fix.

Yes, it is convenient to do it in the same patch and OK with me.

--
Bartlomiej Zolnierkiewicz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

First page Previous page 1 2 Next page Last page  View All Linux kernel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.