On Mon, 25 Jul 2011, Ingo Molnar wrote: > * Yinghai Lu <yinghai@xxxxxxxxxx> wrote: > > > > This looks very messy. > > > > > > CONFIG_DMAR has no clear meaning. The DMAR table parsing > > > functionality is intermixed with the DMAR feature itself. The > > > kernel code is littered with a couple of dozen CONFIG_DMAR > > > #ifdefs with no clear structure to the initialization and to the > > > separation of functionality. > > > > CONFIG_DMAR is actually DMA_REMAP instead DMAR table. > > > > or Do you prefer to clean them up further with following depency? > > > > CONFIG_DMAR_TBL for DMAR table > > CONFIG_DMA_REMAP for DMA remapping > > CONFIG_INTR_REMAP for Interrupt remapping > > and XXX_REMAP will select DMAR_TBL > > 'DMAR', 'TBL' and 'INTR' are all misnomers! > > CONFIG_DMA_REMAP_TABLE > CONFIG_DMA_REMAP > CONFIG_IRQ_REMAP > > That way we'd get the 'DMAR tables' via CONFIG_DMA_REMAP_TABLE - on > top of which enabling CONFIG_DMA_REMAP and CONFIG_IRQ_REMAP would > enable and handle various hw remapping features. > > (Does anyone else have better/other code structure suggestions?) > > But yes, we should first do this rename/cleanup to clarify what it > all means, then fix whatever config-combos don't work perfectly yet. All, Is this re-work effort going to make it into 3.1? With 3.1.0-rc1, we are seeing the same 'no interupts being routed' issue. Applying Yinghai's patch to 3.1-rc1: http://www.spinics.net/lists/linux-scsi/msg53416.html get's interrupts routing again.... Thanks, AV -- 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
