ata and netdev (was Re: -mm merge plans for 2.6.23)

ata and netdev (was Re: -mm merge plans for 2.6.23)

[Jeff Garzik]

(just to provide my indicator of status)

Andrew Morton wrote:
> libata-config_pm=n-compile-fix.patch

that's for a branch that you don't get via libata-dev#ALL, #mv-ahci-pata.


> pata_acpi-restore-driver.patch

see Alan's comments.  I've been ignoring pata_acpi for a while, because 
IMO it always needed work.


> libata-core-convert-to-use-cancel_rearming_delayed_work.patch

will merge


> libata-implement-ata_wait_after_reset.patch

I'm pretty much this is obsolete.  Tejun?


> sata_promise-sata-hotplug-support.patch

will merge


> libata-add-irq_flags-to-struct-pata_platform_info-fix.patch

are other pata_platform people happy with this?  I don't know embedded 
well enough to know if adding this struct member will break things.


> ata-add-the-sw-ncq-support-to-sata_nv-for-mcp51-mcp55-mcp61.patch
> sata_nv-allow-changing-queue-depth.patch

should be combined, really.  will merge eventually.  basic concept OK, 
but need to review in depth.

> pata_hpt3x3-major-reworking-and-testing.patch
> iomap-sort-out-the-broken-address-reporting-caused-by-the-iomap-layer.patch
> ata-use-iomap_name.patch

generally OK


> libata-check-for-an-support.patch
> scsi-expose-an-to-user-space.patch
> libata-expose-an-to-user-space.patch
> scsi-save-disk-in-scsi_device.patch
> libata-send-event-when-an-received.patch
> 
>  Am sitting on these due to confusion regarding the status of the ata-ahci
>  patches.

I will apply what I can, but it seems there are lifetime problems


> ata-ahci-alpm-store-interrupt-value.patch
> ata-ahci-alpm-expose-power-management-policy-option-to-users.patch
> ata-ahci-alpm-enable-link-power-management-for-ata-drivers.patch
> ata-ahci-alpm-enable-aggressive-link-power-management-for-ahci-controllers.patch
> 
>  These appear to need some work.

seemed mostly OK to me.  what comments did I miss?


> libata-add-human-readable-error-value-decoding.patch

still pondering; in my mbox queue

> libata-fix-hopefully-all-the-remaining-problems-with.patch
> testing-patch-for-ali-pata-fixes-hopefully-for-the-problems-with-atapi-dma.patch
> pata_ali-more-work.patch

No idea.  I would poke Alan.  Probably drop.


> 8139too-force-media-setting-fix.patch
> blackfin-on-chip-ethernet-mac-controller-driver.patch
> atari_pamsnetc-old-declaration-ritchie-style-fix.patch
> sundance-phy-address-form-0-only-for-device-id-0x0200.patch

Needs a bug fix, so that the newly modified loop doesn't scan the final 
phy id, then loop back around to scan the first again.


> 3x59x-fix-pci-resource-management.patch
> update-smc91x-driver-with-arm-versatile-board-info.patch
> drivers-net-ns83820c-add-paramter-to-disable-auto.patch
> 
>  netdev patches which are stuck in limbo land.

?  I don't think I've seen these.


> bonding-bond_mainc-make-2-functions-static.patch

FWIW bonding stuff should go to me, since it lives mostly in drivers/net


> x86-initial-fixmap-support.patch

Andi material?


> mm-revert-kernel_ds-buffered-write-optimisation.patch
> revert-81b0c8713385ce1b1b9058e916edcf9561ad76d6.patch
> revert-6527c2bdf1f833cc18e8f42bd97973d583e4aa83.patch
> mm-clean-up-buffered-write-code.patch
> mm-debug-write-deadlocks.patch
> mm-trim-more-holes.patch
> mm-buffered-write-cleanup.patch
> mm-write-iovec-cleanup.patch
> mm-fix-pagecache-write-deadlocks.patch
> mm-buffered-write-iterator.patch
> fs-fix-data-loss-on-error.patch
> mm-restore-kernel_ds-optimisations.patch
>  pagefault-in-write deadlock fixes.  Will hold for 2.6.24.

Any of the above worth 2.6.23?  Just wondering if they were useful 
cleanups / minor fixes prior to new aops patches?


> more-scheduled-oss-driver-removal.patch

ACK


> oss-trident-massive-whitespace-removal.patch
> oss-trident-fix-locking-around-write_voice_regs.patch
> oss-trident-replace-deprecated-pci_find_device-with-pci_get_device.patch
> remove-options-depending-on-oss_obsolete.patch
> 
>  Merge

what about just removing the OSS drivers in question?  :)


> intel-iommu-dmar-detection-and-parsing-logic.patch
> intel-iommu-pci-generic-helper-function.patch
> intel-iommu-clflush_cache_range-now-takes-size-param.patch
> intel-iommu-iova-allocation-and-management-routines.patch
> intel-iommu-intel-iommu-driver.patch
> intel-iommu-avoid-memory-allocation-failures-in-dma-map-api-calls.patch
> intel-iommu-intel-iommu-cmdline-option-forcedac.patch
> intel-iommu-dmar-fault-handling-support.patch
> intel-iommu-iommu-gfx-workaround.patch
> intel-iommu-iommu-floppy-workaround.patch
> 
>  Don't know.  I don't think there were any great objections, but I don't
>  think much benefit has been demonstrated?

Just the general march of progress on new hardware :)

I would like to see this support merged in /some/ form.  We've been 
telling Intel for years they were sillyheads for not bothering with an 
IOMMU.  Now that they have, we should give them a cookie and support 
good technology.

	Jeff

Re: ata and netdev (was Re: -mm merge plans for 2.6.23)

[Andrew Morton]

On Tue, 10 Jul 2007 13:42:16 -0400
Jeff Garzik <jeff@garzik.org> wrote:

> 
> (just to provide my indicator of status)

Thanks.

> > libata-add-irq_flags-to-struct-pata_platform_info-fix.patch
> 
> are other pata_platform people happy with this?  I don't know embedded 
> well enough to know if adding this struct member will break things.

This is just a silly remove-unneeded-cast-of-void* cleanup.  I wrote this
as a fixup against
libata-add-irq_flags-to-struct-pata_platform_info.patch with the intention
of folding it into that base patch, but you went and merged the submitter's
original patch so this trivial fixup got stranded in -mm.  Feel free to give
it the piss-off-too-trivial treatment.

> > ata-ahci-alpm-store-interrupt-value.patch
> > ata-ahci-alpm-expose-power-management-policy-option-to-users.patch
> > ata-ahci-alpm-enable-link-power-management-for-ata-drivers.patch
> > ata-ahci-alpm-enable-aggressive-link-power-management-for-ahci-controllers.patch
> > 
> >  These appear to need some work.
> 
> seemed mostly OK to me.  what comments did I miss?

Oh, I thought these were the patches which affected scsi and which James
had issues with.  I guess I got confused.

> 
> > libata-add-human-readable-error-value-decoding.patch
> 
> still pondering; in my mbox queue
> 
> > libata-fix-hopefully-all-the-remaining-problems-with.patch
> > testing-patch-for-ali-pata-fixes-hopefully-for-the-problems-with-atapi-dma.patch
> > pata_ali-more-work.patch
> 
> No idea.  I would poke Alan.  Probably drop.
> 

Alan: poke.

> 
> > 8139too-force-media-setting-fix.patch
> > blackfin-on-chip-ethernet-mac-controller-driver.patch
> > atari_pamsnetc-old-declaration-ritchie-style-fix.patch
> > sundance-phy-address-form-0-only-for-device-id-0x0200.patch
> 
> Needs a bug fix, so that the newly modified loop doesn't scan the final 
> phy id, then loop back around to scan the first again.
> 
> 
> > 3x59x-fix-pci-resource-management.patch
> > update-smc91x-driver-with-arm-versatile-board-info.patch
> > drivers-net-ns83820c-add-paramter-to-disable-auto.patch
> > 
> >  netdev patches which are stuck in limbo land.
> 
> ?  I don't think I've seen these.
> 

3x59x-fix-pci-resource-management.patch: you wrote it ;) I have a comment
here:

- I don't remember the story with cardbus either.  Presumably once upon a
  time the cardbus layer was claiming IO regions on behalf of cardbus
  devices (?)

Need to think about that.

update-smc91x-driver-with-arm-versatile-board-info.patch:

See comment from rmk in changelog:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc6/2.6.22-rc6-mm1/broken-out/update-smc91x-driver-with-arm-versatile-board-info.patch

Deepak, can we move this along a bit please?

drivers-net-ns83820c-add-paramter-to-disable-auto.patch:

See comments in changelog: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc6/2.6.22-rc6-mm1/broken-out/drivers-net-ns83820c-add-paramter-to-disable-auto.patch

Dan, Ben: is there any prospect of progress here?

> 
> > bonding-bond_mainc-make-2-functions-static.patch
> 
> FWIW bonding stuff should go to me, since it lives mostly in drivers/net
> 

Ah, noted.

> > x86-initial-fixmap-support.patch
> 
> Andi material?
> 

Spose so.  But it's buried in the middle of a series of four patches.

> 
> > mm-revert-kernel_ds-buffered-write-optimisation.patch
> > revert-81b0c8713385ce1b1b9058e916edcf9561ad76d6.patch
> > revert-6527c2bdf1f833cc18e8f42bd97973d583e4aa83.patch
> > mm-clean-up-buffered-write-code.patch
> > mm-debug-write-deadlocks.patch
> > mm-trim-more-holes.patch
> > mm-buffered-write-cleanup.patch
> > mm-write-iovec-cleanup.patch
> > mm-fix-pagecache-write-deadlocks.patch
> > mm-buffered-write-iterator.patch
> > fs-fix-data-loss-on-error.patch
> > mm-restore-kernel_ds-optimisations.patch
> >  pagefault-in-write deadlock fixes.  Will hold for 2.6.24.
> 
> Any of the above worth 2.6.23?  Just wondering if they were useful 
> cleanups / minor fixes prior to new aops patches?
> 

The first few patches will a) fix up our writev performance regression and
b) reintroduce the writev() deadlock which the writev()-regresion-adding
patch fixed.

So it's all a bit ugly.

> 
> > oss-trident-massive-whitespace-removal.patch
> > oss-trident-fix-locking-around-write_voice_regs.patch
> > oss-trident-replace-deprecated-pci_find_device-with-pci_get_device.patch
> > remove-options-depending-on-oss_obsolete.patch
> > 
> >  Merge
> 
> what about just removing the OSS drivers in question?  :)
> 

Hey, I only work here.

> 
> > intel-iommu-dmar-detection-and-parsing-logic.patch
> > intel-iommu-pci-generic-helper-function.patch
> > intel-iommu-clflush_cache_range-now-takes-size-param.patch
> > intel-iommu-iova-allocation-and-management-routines.patch
> > intel-iommu-intel-iommu-driver.patch
> > intel-iommu-avoid-memory-allocation-failures-in-dma-map-api-calls.patch
> > intel-iommu-intel-iommu-cmdline-option-forcedac.patch
> > intel-iommu-dmar-fault-handling-support.patch
> > intel-iommu-iommu-gfx-workaround.patch
> > intel-iommu-iommu-floppy-workaround.patch
> > 
> >  Don't know.  I don't think there were any great objections, but I don't
> >  think much benefit has been demonstrated?
> 
> Just the general march of progress on new hardware :)
> 
> I would like to see this support merged in /some/ form.  We've been 
> telling Intel for years they were sillyheads for not bothering with an 
> IOMMU.  Now that they have, we should give them a cookie and support 
> good technology.

OK, thanks.

Re: ata and netdev (was Re: -mm merge plans for 2.6.23)

[James Bottomley]

On Tue, 2007-07-10 at 11:24 -0700, Andrew Morton wrote:
> > > ata-ahci-alpm-store-interrupt-value.patch
> > > ata-ahci-alpm-expose-power-management-policy-option-to-users.patch
> > > ata-ahci-alpm-enable-link-power-management-for-ata-drivers.patch
> > > ata-ahci-alpm-enable-aggressive-link-power-management-for-ahci-controllers.patch
> > > 
> > >  These appear to need some work.
> > 
> > seemed mostly OK to me.  what comments did I miss?
> 
> Oh, I thought these were the patches which affected scsi and which James
> had issues with.  I guess I got confused.

Well ... my concern was really how to make them more generic ... ahci
isn't the only controller that can do phy power management, and it also
seemed to me that the most generic entity for power management was the
transport rather than the SCSI mid-layer, but that debate is still
ongoing.

James

Re: ata and netdev (was Re: -mm merge plans for 2.6.23)

[Jeff Garzik]

Andrew Morton wrote:
> On Tue, 10 Jul 2007 13:42:16 -0400
> Jeff Garzik <jeff@garzik.org> wrote:
> 
>> (just to provide my indicator of status)
> 
> Thanks.
> 
>>> libata-add-irq_flags-to-struct-pata_platform_info-fix.patch
>> are other pata_platform people happy with this?  I don't know embedded 
>> well enough to know if adding this struct member will break things.
> 
> This is just a silly remove-unneeded-cast-of-void* cleanup.  I wrote this
> as a fixup against
> libata-add-irq_flags-to-struct-pata_platform_info.patch with the intention
> of folding it into that base patch, but you went and merged the submitter's
> original patch so this trivial fixup got stranded in -mm.  Feel free to give
> it the piss-off-too-trivial treatment.

I'm sorry, I didn't look closely enough.  I was referring to the 
add-irq-flags patch itself, not your small fix.


>>> ata-ahci-alpm-store-interrupt-value.patch
>>> ata-ahci-alpm-expose-power-management-policy-option-to-users.patch
>>> ata-ahci-alpm-enable-link-power-management-for-ata-drivers.patch
>>> ata-ahci-alpm-enable-aggressive-link-power-management-for-ahci-controllers.patch
>>>
>>>  These appear to need some work.
>> seemed mostly OK to me.  what comments did I miss?
> 
> Oh, I thought these were the patches which affected scsi and which James
> had issues with.  I guess I got confused.

hrm.  ISTR James wanted some cleanups, Kristen did some cleanups, then 
looking at the cleanups decided they were needed / appropriate at this time.

Anyway, these are in my mbox queue and the libata portions (of which the 
code is the majority) seem OK.  Need to give them a final review.

	Jeff

Re: ata and netdev (was Re: -mm merge plans for 2.6.23)

[Sergei Shtylyov]

Hello.

Jeff Garzik wrote:

>> 3x59x-fix-pci-resource-management.patch

    Now that the fix for CONFIG_PCI=n has been merged, what's left is to test 
this on EISA (at least Andrew wanted it :-).

>>  netdev patches which are stuck in limbo land.

> ?  I don't think I've seen these.

    You should have, I was sending it to you.

WBR, Sergei

Re: ata and netdev (was Re: -mm merge plans for 2.6.23)

[Sergei Shtylyov]

Hello.

Andrew Morton wrote:

> 3x59x-fix-pci-resource-management.patch: you wrote it ;) I have a comment

    No, I did, almost a year ago already. :-)

> here:

> - I don't remember the story with cardbus either.  Presumably once upon a
>   time the cardbus layer was claiming IO regions on behalf of cardbus
>   devices (?)

    IIRC, that's your own comment.

> Need to think about that.

WBR, Sergei

Re: ata and netdev (was Re: -mm merge plans for 2.6.23)

[Andrew Morton]

On Wed, 11 Jul 2007 00:31:23 +0400
Sergei Shtylyov <sshtylyov@ru.mvista.com> wrote:

> Hello.
> 
> Andrew Morton wrote:
> 
> > 3x59x-fix-pci-resource-management.patch: you wrote it ;) I have a comment
> 
>     No, I did, almost a year ago already. :-)

I thought that was odd.  I fixed the attribution.
 
> > here:
> 
> > - I don't remember the story with cardbus either.  Presumably once upon a
> >   time the cardbus layer was claiming IO regions on behalf of cardbus
> >   devices (?)
> 
>     IIRC, that's your own comment.

yup, that's what "I have a comment" meant ;)

The comment seems rather bogus actually.  Let's just merge it.

Re: ata and netdev (was Re: -mm merge plans for 2.6.23)

[Dan Faerch]

Andrew Morton wrote:
> drivers-net-ns83820c-add-paramter-to-disable-auto.patch:
>
> See comments in changelog: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc6/2.6.22-rc6-mm1/broken-out/drivers-net-ns83820c-add-paramter-to-disable-auto.patch
>
> Dan, Ben: is there any prospect of progress here?
Mmm.. Ben had 2 comments last year:

In regards to the ethtool stuff i coded:

> This part is good, although doing something for copper cards needs doing, 

I know very little about hardware and only own the fiber version of this 
card. Even if i tried to make code for the copper version, it would 
probably blow it up the phy and set the switches on fire ;).

And in regards to the '"disable_autoneg" module argument':

> This is the part I disagree with.  Are you sure it isn't a bug in the 
> link autonegotiation state machine for fibre cards?  It should be defaulting 
> to 1Gbit/full duplex if no autonegotiation is happening, and if it isn't 
> then that should be fixed instead of papering over things with a config 
> option.

This is pretty much Russian to me. 
I wouldnt know where to find the "link-autonegotiation-state-machine-for-fibre-cards" or know what to do with it anyway :).

The "disable_autoneg" is a convenient feature (for me and the other guy who made the same patch last year) and i consider it a harmless feature in every way.
It is simply an 'if'-statement, that skips the "start autoneg" function upon load.
We can simply remove the feature entirely if it is deemed undesirable.



So in conclusion:
- I vote "use the patch as-is", but im fine with it being changed. 
- If it needs support for copper, someone else has to code it.


Regards
- Dan