Re: [PATCH 3/5] add sg segment limitation info to device structure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2007-10-02 at 17:10 +0200, Kay Sievers wrote:
> On Tue, 2007-10-02 at 10:05 -0500, James Bottomley wrote:
> > On Tue, 2007-10-02 at 17:02 +0200, Kay Sievers wrote:
> > > On 10/2/07, James Bottomley <James.Bottomley@xxxxxxxxxxxx> wrote:
> > > > On Mon, 2007-10-01 at 21:22 -0700, Greg KH wrote:
> > > > > On Mon, Oct 01, 2007 at 07:39:02PM -0600, Matthew Wilcox wrote:
> > > > > > On Mon, Oct 01, 2007 at 07:36:10PM -0400, James Bottomley wrote:
> > > > > > > One possibility we could do is to add a
> > > > > > >
> > > > > > > struct dma_device {
> > > > > > >   struct device dev;
> > > > > > >   u64 dma_mask;
> > > > > > >   u64 coherent_dma_mask;
> > > > > > >   unsigned int max_segment_size;
> > > > > > >   /* plus any other DMA parameters */
> > > > > > > };
> > > > > > >
> > > > > > > but then every bus that can do DMA would need to include a struct
> > > > > > > dma_device instead of the struct device they do now.  Then the IOMMU
> > > > > > > would know it could cast out from struct device to struct dma_device,
> > > > > > > but this would be a lot of work to thread through the current
> > > > > > > infrastructure.
> > > > >
> > > > > Why not just hang these fields off of a struct device, that way if the
> > > > > device doesn't/can't do dma, it only has the "loss" of a single pointer,
> > > > > not all of these fields?
> > > >
> > > > Well, that's just a bit ugly ... I assume you're thinking of adding a
> > > > struct device_dma_parameters, and then defining the platform device as
> > > >
> > > > struct pci_dev {
> > > >         ...
> > > >         struct device dev;
> > > >         struct device_dma_parameters dma_parms;
> > > >         ...
> > > > };
> > > >
> > > > and then setting up the pointer?
> > > 
> > > I guess Greg means:
> > >   struct device {
> > >       ...
> > >       struct device_dma_parameters *dma_parms;
> > >   }
> > > 
> > > and allocate dma_parms on demand.
> > 
> > But they're demanded by every bus (with the possible exception of
> > PCMCIA) because they'll be holding the dma mask.  Sure, we could do a
> > separate allocation in every bus device creation routine, but isn't that
> > even more complex than sticking them in the global allocation of the bus
> > device because the failure modes are now more complex?
> 
> Hmm, SCSI devices are bus devices too, will they need it?

Actually, I don't think of SCSI devices as bus devices ... but the
answer's no, they don't.  Only devices on a DMA'able bus (like PCI,
parisc, sbus etc.)

James


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux