Re: [PATCH 0/19] clean ups on the drivers
From: FUJITA Tomonori [EMAIL PROTECTED] Subject: Re: [PATCH 0/19] clean ups on the drivers Date: Mon, 14 May 2007 23:40:03 +0900 From: Christoph Hellwig [EMAIL PROTECTED] Subject: Re: [PATCH 0/19] clean ups on the drivers Date: Sat, 12 May 2007 16:30:23 +0100 On Sat, May 12, 2007 at 07:05:42PM +0900, FUJITA Tomonori wrote: There are two patches for each driver, removing the non-use-sg code and converting to use the accessors. One patch would probably be fine aswell. I merged the two. And I finished cleaning up 35 drivers in total. git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-bidi.git cleanups I rebased the cleanup patchset against the latest scsi-misc (352e921f0dd42f79652cdb50dd91122d068d7209). It includes the cleanups for more than 40 drivers. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/19] clean ups on the drivers
On Mon, May 14, 2007 at 05:39:06PM +0200, Stefan Richter wrote:
FUJITA Tomonori wrote:
There are two patches for each driver, removing the non-use-sg code
and converting to use the accessors.
...
I merged the two. And I finished cleaning up 35 drivers in total.
git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-bidi.git
cleanups
According to what I see via gitweb, at least usb-storage, ieee1394/sbp2,
and firewire/fw-sbp2 weren't treated yet. If somebody does so for the
latter two: The shost-shost_gendev.parent has to be changed for
scsi_dma_{un}map. I don't know if this can be done without breaking
anything.
That means they should not be converted to these helpers for now.
Personally I'd still love to have the dma mapping routines to work on
any given struct device but walking up the parent chain until an iommu
is found, but that was vetoed when first proposed.
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/19] clean ups on the drivers
On Tue, 2007-05-15 at 10:01 +0100, Christoph Hellwig wrote:
On Mon, May 14, 2007 at 05:39:06PM +0200, Stefan Richter wrote:
FUJITA Tomonori wrote:
There are two patches for each driver, removing the non-use-sg code
and converting to use the accessors.
...
I merged the two. And I finished cleaning up 35 drivers in total.
git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-bidi.git
cleanups
According to what I see via gitweb, at least usb-storage, ieee1394/sbp2,
and firewire/fw-sbp2 weren't treated yet. If somebody does so for the
latter two: The shost-shost_gendev.parent has to be changed for
scsi_dma_{un}map. I don't know if this can be done without breaking
anything.
That means they should not be converted to these helpers for now.
Personally I'd still love to have the dma mapping routines to work on
any given struct device but walking up the parent chain until an iommu
is found, but that was vetoed when first proposed.
Er ... I really hope not ... that's exactly how the parisc iommu
platform code works ... and why I designed the generic dma mapping this
way. The key thing parisc needed was the ability to walk up different
busses until it found the iommu (for example the pci bus - dino - GSC
- IOMMU) which it does by traversing the dev-parent; However, I didn't
mandate working this way for other architectures.
James
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/19] clean ups on the drivers
On Tue, May 15, 2007 at 06:54:16AM -0500, James Bottomley wrote: Er ... I really hope not ... that's exactly how the parisc iommu platform code works ... and why I designed the generic dma mapping this way. The key thing parisc needed was the ability to walk up different busses until it found the iommu (for example the pci bus - dino - GSC - IOMMU) which it does by traversing the dev-parent; However, I didn't mandate working this way for other architectures. Well, the NACK was not for the implementation details but rather the exported and documented interface. IIRC the rationale was that Dave wants to keep the sparc implementation super-optimized and avoid indirection. If it was up to me I'd have something like the parisc implementation in generic code. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/19] clean ups on the drivers
On Tue, 2007-05-15 at 12:57 +0100, Christoph Hellwig wrote: On Tue, May 15, 2007 at 06:54:16AM -0500, James Bottomley wrote: Er ... I really hope not ... that's exactly how the parisc iommu platform code works ... and why I designed the generic dma mapping this way. The key thing parisc needed was the ability to walk up different busses until it found the iommu (for example the pci bus - dino - GSC - IOMMU) which it does by traversing the dev-parent; However, I didn't mandate working this way for other architectures. Well, the NACK was not for the implementation details but rather the exported and documented interface. IIRC the rationale was that Dave wants to keep the sparc implementation super-optimized and avoid indirection. Well, actually, I do understand that. How about the weaker requirement that you be able to call the dma_ functions on any dev (provided it's properly parented) and leave the implementation up to the platform? If it was up to me I'd have something like the parisc implementation in generic code. It might make sense to put it in lib ... however, I don't think many architectures have the problems we have ... specifically certain boxes can have 1 IOMMU, then you really have to know *which* iommu you're programming. James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/19] clean ups on the drivers
From: James Bottomley [EMAIL PROTECTED] Date: Tue, 15 May 2007 12:57:25 -0400 It might make sense to put it in lib ... however, I don't think many architectures have the problems we have ... specifically certain boxes can have 1 IOMMU, then you really have to know *which* iommu you're programming. Sparc64 boxes will have this at some point, but what I'm going to do is simply fill in the dev_archdata properly at device scan time. Instead of doing a bus walk up the parent every IOMMU request, why not cache those results in the dev_archdata? That seems to make the most sense. If there is some probing complexity, catch not-setup dev_archdata at the IOMMU request, and slow path into a resolver of some sort. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/19] clean ups on the drivers
On Tue, 2007-05-15 at 13:37 -0700, David Miller wrote: From: James Bottomley [EMAIL PROTECTED] Date: Tue, 15 May 2007 12:57:25 -0400 It might make sense to put it in lib ... however, I don't think many architectures have the problems we have ... specifically certain boxes can have 1 IOMMU, then you really have to know *which* iommu you're programming. Sparc64 boxes will have this at some point, but what I'm going to do is simply fill in the dev_archdata properly at device scan time. Instead of doing a bus walk up the parent every IOMMU request, why not cache those results in the dev_archdata? That seems to make the most sense. That is what we do ... except parisc caches the result in platform_data, largely because dev_archdata wasn't around when the scheme was concocted. However, if we find a NULL platform_data we walk up the tree until we find a non-NULL value and use that (IOMMUs are on a disconnected bus topology). If there is some probing complexity, catch not-setup dev_archdata at the IOMMU request, and slow path into a resolver of some sort. Yes, that's where we do the walk if the cache is NULL. James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/19] clean ups on the drivers
From: Christoph Hellwig [EMAIL PROTECTED] Subject: Re: [PATCH 0/19] clean ups on the drivers Date: Sat, 12 May 2007 16:30:23 +0100 On Sat, May 12, 2007 at 07:05:42PM +0900, FUJITA Tomonori wrote: There are two patches for each driver, removing the non-use-sg code and converting to use the accessors. One patch would probably be fine aswell. I merged the two. And I finished cleaning up 35 drivers in total. git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-bidi.git cleanups - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/19] clean ups on the drivers
On Sat, May 12, 2007 at 07:05:42PM +0900, FUJITA Tomonori wrote: There are two patches for each driver, removing the non-use-sg code and converting to use the accessors. One patch would probably be fine aswell. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
