On Mon, Nov 25, 2013 at 10:00 AM, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > On Mon, Nov 25, 2013 at 09:45:18AM -0800, Dan Williams wrote: >> Regardless of whether the driver was dma_request_channel as a >> fallback, it will currently use NULL to indicate an allocation >> failure. > > At the moment, dma_request_slave_channel()'s return values are valid > pointer or NULL. I'd suggest as that's how it's been established, > that function is left alone - changing the return values in this kind > of invisible way is Really Bad(tm) because you can't check that it's > right in any future users - unless you're prepared to review every > single new user of this function for the next few years or more. > > Instead, leaving it as is and introducing a new function name with > the different return error method is the right way to do this. I was attempting to tap the brakes on the number of request_channel apis in circulation. dma_request_channel dma_request_slave_channel dma_request_slave_channel_compat ... and now dma_request_slave_channel_reason ...but given we already have things like samsung_dmadev_request() in the wild, tracking correct usage going forward will be an uphill battle. We can do this the other way round. Introduce the new api and delete the old one (after some time). Stephen, Can we make the new api not pass the 'defer' flag. You mention it is for compat reasons, but since there are no users I'm not seeing how there can be compatibility concerns. Can you elaborate? -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
