From: David Flater Date: Fri, 10 May 2013 12:37:43 +0000 (+0200) Subject: pnp: restore automatic resolution of DMA conflicts X-Git-Tag: omap-for-v3.11/fixes-for-merge-window~19^2~11^2 X-Git-Url: http://git.openpandora.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=bdf0eb3a026922dbf57f6839f3184c8d2ecc5f2e;p=pandora-kernel.git pnp: restore automatic resolution of DMA conflicts To fix a 5-year-old regression, reverse changes made by commit 7ef3639 (PNP: don't fail device init if no DMA channel available). As an example to show the problem, my sound card provides a prioritized list of PnP "dependent sets" of requested resources: dependent set 0 (preferred) wants DMA 5. dependent set 1 (acceptable) will take DMA 5, 6, or 7. ... dependent set 4 (acceptable) doesn't request a high DMA. If DMA 5 is not available, pnp_assign_dma has to fail on set 0 so that pnp_auto_config_dev will move on to set 1 and get DMA 6 or 7. Instead, pnp_assign_dma adds the resource with flags |= IORESOURCE_DISABLED and returns success. pnp_auto_config_dev just sees success and therefore chooses set 0 with a disabled DMA and never tries the sets that would have resolved the conflict. Furthermore, this mode of "success" is unexpected and unhandled in sound/isa/sb and probably other drivers. sb assumes that the returned DMA is enabled and obliviously uses the invalid DMA number. Observed consequences were sb successfully grabbing a DMA that was expressly forbidden by the kernel parameter pnp_reserve_dma. The only upside to the original change would be as a kludge for devices that can operate in degraded mode without a DMA but that don't provide the corresponding non-preferred dependent set. The right workaround for those devices is to synthesize the missing set in quirks.c; otherwise, you're reinventing PnP fallback functionality at the driver level for that device and all others. Signed-off-by: David Flater Signed-off-by: Rafael J. Wysocki --- Reading git-diff-tree failed