Re: [RFC][PATCH] move dma_mask into struct device

From: Arnd Bergmann (arndb@de.ibm.com)
Date: Sat Nov 16 2002 - 13:26:52 EST


On Saturday 16 November 2002 16:33, J.E.J. Bottomley wrote:

> The SCSI host itself has no need of a DMA mask. What we need the mask for
> is to set up the bounce limits for the block queue, we don't actually ever
> use it again. Unfortunately, dma_mask isn't architecture specific, its a
> universal property of the block queues used to determine when to bounce
> memory regions.

On my s390 system, I can have many thousand devices and none of them is
doing DMA, so I would indeed call it architecture specific. Note that
even in a normal PC system, most devices (e.g. CPUs, input devices or
the disks attached to the host adapter) don't have any concept of
DMA.

> The dma_mask is a property of the connection of the Scsi_Host to the
> machine bus, not of the Scsi_Host itself, so it does properly belong in the
> generic device which is used to reflect machine bus attachments.
Maybe, but if you put dma_mask in struct device, you are making it a property
of every single device in the system.

> Think of it this way: we have two struct device's per SCSI host: one for
> the actual HBA card or bus attachment, which contains all of the bus
> specific pieces, and one for the host itself reflecting the fact that it is
> a bridge from the machine bus to the scsi bus.
That does not sound right either, but I don't care so much about this because
you are not messing with my devices here. The problem is having two 'struct
device's for one physical device. The Scsi_Host should really be the
*driver_data of the bus devices, with the scsi devices being direct children
of that device.

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



This archive was generated by hypermail 2b29 : Sat Nov 23 2002 - 22:00:17 EST