* ata and netdev (was Re: -mm merge plans for 2.6.23) [not found] <20070710013152.ef2cd200.akpm@linux-foundation.org> @ 2007-07-10 17:42 ` Jeff Garzik 2007-07-10 18:24 ` Andrew Morton 2007-07-10 19:56 ` Sergei Shtylyov 0 siblings, 2 replies; 8+ messages in thread From: Jeff Garzik @ 2007-07-10 17:42 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, IDE/ATA development list, netdev, Tejun Heo (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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ata and netdev (was Re: -mm merge plans for 2.6.23) 2007-07-10 17:42 ` ata and netdev (was Re: -mm merge plans for 2.6.23) Jeff Garzik @ 2007-07-10 18:24 ` Andrew Morton 2007-07-10 18:55 ` James Bottomley ` (3 more replies) 2007-07-10 19:56 ` Sergei Shtylyov 1 sibling, 4 replies; 8+ messages in thread From: Andrew Morton @ 2007-07-10 18:24 UTC (permalink / raw) To: Jeff Garzik Cc: linux-kernel, IDE/ATA development list, netdev, Tejun Heo, Alan Cox, Deepak Saxena, Dan Faerch, Benjamin LaHaise 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ata and netdev (was Re: -mm merge plans for 2.6.23) 2007-07-10 18:24 ` Andrew Morton @ 2007-07-10 18:55 ` James Bottomley 2007-07-10 18:57 ` Jeff Garzik ` (2 subsequent siblings) 3 siblings, 0 replies; 8+ messages in thread From: James Bottomley @ 2007-07-10 18:55 UTC (permalink / raw) To: Andrew Morton Cc: Jeff Garzik, linux-kernel, IDE/ATA development list, netdev, Tejun Heo, Alan Cox, Deepak Saxena, Dan Faerch, Benjamin LaHaise 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ata and netdev (was Re: -mm merge plans for 2.6.23) 2007-07-10 18:24 ` Andrew Morton 2007-07-10 18:55 ` James Bottomley @ 2007-07-10 18:57 ` Jeff Garzik 2007-07-10 20:31 ` Sergei Shtylyov 2007-07-11 16:47 ` Dan Faerch 3 siblings, 0 replies; 8+ messages in thread From: Jeff Garzik @ 2007-07-10 18:57 UTC (permalink / raw) To: Andrew Morton Cc: linux-kernel, IDE/ATA development list, netdev, Tejun Heo, Alan Cox, Deepak Saxena, Dan Faerch, Benjamin LaHaise 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ata and netdev (was Re: -mm merge plans for 2.6.23) 2007-07-10 18:24 ` Andrew Morton 2007-07-10 18:55 ` James Bottomley 2007-07-10 18:57 ` Jeff Garzik @ 2007-07-10 20:31 ` Sergei Shtylyov 2007-07-10 20:35 ` Andrew Morton 2007-07-11 16:47 ` Dan Faerch 3 siblings, 1 reply; 8+ messages in thread From: Sergei Shtylyov @ 2007-07-10 20:31 UTC (permalink / raw) To: Andrew Morton; +Cc: Jeff Garzik, linux-kernel, netdev 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ata and netdev (was Re: -mm merge plans for 2.6.23) 2007-07-10 20:31 ` Sergei Shtylyov @ 2007-07-10 20:35 ` Andrew Morton 0 siblings, 0 replies; 8+ messages in thread From: Andrew Morton @ 2007-07-10 20:35 UTC (permalink / raw) To: Sergei Shtylyov; +Cc: Jeff Garzik, linux-kernel, netdev 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ata and netdev (was Re: -mm merge plans for 2.6.23) 2007-07-10 18:24 ` Andrew Morton ` (2 preceding siblings ...) 2007-07-10 20:31 ` Sergei Shtylyov @ 2007-07-11 16:47 ` Dan Faerch 3 siblings, 0 replies; 8+ messages in thread From: Dan Faerch @ 2007-07-11 16:47 UTC (permalink / raw) To: Andrew Morton Cc: Jeff Garzik, linux-kernel, IDE/ATA development list, netdev, Tejun Heo, Alan Cox, Deepak Saxena, Benjamin LaHaise 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ata and netdev (was Re: -mm merge plans for 2.6.23) 2007-07-10 17:42 ` ata and netdev (was Re: -mm merge plans for 2.6.23) Jeff Garzik 2007-07-10 18:24 ` Andrew Morton @ 2007-07-10 19:56 ` Sergei Shtylyov 1 sibling, 0 replies; 8+ messages in thread From: Sergei Shtylyov @ 2007-07-10 19:56 UTC (permalink / raw) To: Jeff Garzik; +Cc: Andrew Morton, linux-kernel, netdev 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2007-07-11 16:47 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20070710013152.ef2cd200.akpm@linux-foundation.org>
2007-07-10 17:42 ` ata and netdev (was Re: -mm merge plans for 2.6.23) Jeff Garzik
2007-07-10 18:24 ` Andrew Morton
2007-07-10 18:55 ` James Bottomley
2007-07-10 18:57 ` Jeff Garzik
2007-07-10 20:31 ` Sergei Shtylyov
2007-07-10 20:35 ` Andrew Morton
2007-07-11 16:47 ` Dan Faerch
2007-07-10 19:56 ` Sergei Shtylyov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).