Hi Doug,
On 2016/3/22 7:33, Doug Anderson wrote:
> Shawn,
>
> On Wed, Mar 9, 2016 at 12:11 AM, Shawn Lin <shawn.lin at rock-chips.com> wrote:
>> Let's defer probing the driver if the return value of
>> dma_request_slave_channel is ERR_PTR(-EPROBE_DEFER) instead
>> of disabling dma capability directly.
>>
>> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
>> ---
>>
>> drivers/spi/spi-rockchip.c | 8 +++++++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
>> index ca4f4e0..75fa990 100644
>> --- a/drivers/spi/spi-rockchip.c
>> +++ b/drivers/spi/spi-rockchip.c
>> @@ -737,8 +737,14 @@ static int rockchip_spi_probe(struct platform_device *pdev)
>> master->handle_err = rockchip_spi_handle_err;
>>
>> rs->dma_tx.ch = dma_request_slave_channel(rs->dev, "tx");
>> - if (!rs->dma_tx.ch)
>> + if (IS_ERR_OR_NULL(rs->dma_tx.ch)) {
>> + /* Check tx to see if we need defer probing driver */
>> + if (PTR_ERR(rs->dma_tx.ch) == -EPROBE_DEFER) {
>> + ret = -EPROBE_DEFER;
>> + goto err_get_fifo_len;
>> + }
>> dev_warn(rs->dev, "Failed to request TX DMA channel\n");
>
> Presumably Dan would be happy if you just add this right after the dev_warn():
> rs->dma_tx.ch = NULL;
>
> Presumably from Dan's email it would also be wise to make sure you
> don't pass NULL to PTR_ERR, which you could probably do by just using
> ERR_PTR instead of PTR_ERR. I think you could structure like this:
>
> rs->dma_tx.ch = dma_request_slave_channel(rs->dev, "tx");
> - if (!rs->dma_tx.ch)
> + if (IS_ERR_OR_NULL(rs->dma_tx.ch)) {
> + /* Check tx to see if we need defer probing driver */
> + if (rs->dma_tx.ch == ERR_PTR(-EPROBE_DEFER)) {
> + ret = -EPROBE_DEFER;
> + goto err_get_fifo_len;
> + }
> dev_warn(rs->dev, "Failed to request TX DMA channel\n");
> + rs->dma_tx.ch = NULL;
> + }
>
>
> With that change your patch should be happy, I think. If some new
> unknown error return gets added to dma_request_slave_channel() then
> your code will continue to work properly. Such a change is simple and
> safe, so presumably you could just spin your patch with that fix.
> Although unlikely, it's probably good to check for IS_ERR_OR_NULL()
> when requesting the "rx" channel too.
Thanks for reminding it. I was planing to fix it, so give me a little
more time. :)
>
> ...but, looking at this, presumably before landing any patch that made
> dma_request_slave_channel() return -EPROBE_DEFER you'd need to modify
> _all_ users of dma_request_slave_channel to handle error pointers
> being returned. Right now dma_request_slave_channel() says it returns
> a pointer to a channel or NULL and the function explicitly avoids
> returning any errors. That might be possible, but it's a big
> change...
At first glance, it's a big change, but maybe not really.
Almost all of them use the templet like:
ch = dma_request_slave_channel
if (!ch)
balabala....
It's same for all the non-null return pointer/non-zero value ?
So from my view, we can safely change dma_request_slave_channel,
and leave the caller here. I presumably the respective
drivers will graduately migrate to check the return value with
EPROBE_DEFER if they do care this issue. Otherwise, we believe
they don't suffer the changes we make, just as what they did in the
past. Does that make sense?
>
>
> -Doug
>
>
>
--
Best Regards
Shawn Lin
