* re: spi: rockchip: check requesting dma channel with EPROBE_DEFER
@ 2016-03-14 9:48 Dan Carpenter
2016-03-14 10:21 ` Shawn Lin
0 siblings, 1 reply; 3+ messages in thread
From: Dan Carpenter @ 2016-03-14 9:48 UTC (permalink / raw)
To: shawn.lin-TNX95d0MmH7DzftRWevZcw
Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Hello Shawn Lin,
The patch 61cadcf46cfd: "spi: rockchip: check requesting dma channel
with EPROBE_DEFER" from Mar 9, 2016, leads to the following static
checker warning:
drivers/spi/spi-rockchip.c:742 rockchip_spi_probe()
warn: passing zero to 'PTR_ERR'
drivers/spi/spi-rockchip.c
732
733 rs->dma_tx.ch = dma_request_slave_channel(rs->dev, "tx");
734 if (IS_ERR_OR_NULL(rs->dma_tx.ch)) {
735 /* Check tx to see if we need defer probing driver */
736 if (PTR_ERR(rs->dma_tx.ch) == -EPROBE_DEFER) {
737 ret = -EPROBE_DEFER;
738 goto err_get_fifo_len;
What's going on here? Are we planning to change dma_request_slave_channel()
to return error pointers? Also what about other error pointers besides
EPROBE_DEFER it seems dangerous to leave rs->dma_tx.ch as an error
pointer. We probably eventually try to free it if it's non-NULL.
739 }
740 dev_warn(rs->dev, "Failed to request TX DMA channel\n");
741 }
742
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: spi: rockchip: check requesting dma channel with EPROBE_DEFER
2016-03-14 9:48 spi: rockchip: check requesting dma channel with EPROBE_DEFER Dan Carpenter
@ 2016-03-14 10:21 ` Shawn Lin
[not found] ` <56E6908C.3060904-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
0 siblings, 1 reply; 3+ messages in thread
From: Shawn Lin @ 2016-03-14 10:21 UTC (permalink / raw)
To: Dan Carpenter
Cc: shawn.lin-TNX95d0MmH7DzftRWevZcw,
linux-spi-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On 2016/3/14 17:48, Dan Carpenter wrote:
> Hello Shawn Lin,
>
> The patch 61cadcf46cfd: "spi: rockchip: check requesting dma channel
> with EPROBE_DEFER" from Mar 9, 2016, leads to the following static
> checker warning:
>
> drivers/spi/spi-rockchip.c:742 rockchip_spi_probe()
> warn: passing zero to 'PTR_ERR'
>
> drivers/spi/spi-rockchip.c
> 732
> 733 rs->dma_tx.ch = dma_request_slave_channel(rs->dev, "tx");
> 734 if (IS_ERR_OR_NULL(rs->dma_tx.ch)) {
> 735 /* Check tx to see if we need defer probing driver */
> 736 if (PTR_ERR(rs->dma_tx.ch) == -EPROBE_DEFER) {
> 737 ret = -EPROBE_DEFER;
> 738 goto err_get_fifo_len;
>
> What's going on here? Are we planning to change dma_request_slave_channel()
> to return error pointers? Also what about other error pointers besides
> EPROBE_DEFER it seems dangerous to leave rs->dma_tx.ch as an error
> pointer. We probably eventually try to free it if it's non-NULL.
yes, we are plannig to return EPROBE_DEFER/NULL for
dma_request_slave_channel to make sure we don't decide
the dma cap based on driver probe sequence.
No any other error pointer will be returned to the caller
>
> 739 }
> 740 dev_warn(rs->dev, "Failed to request TX DMA channel\n");
> 741 }
> 742
>
> regards,
> dan carpenter
>
>
>
--
Best Regards
Shawn Lin
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: spi: rockchip: check requesting dma channel with EPROBE_DEFER
[not found] ` <56E6908C.3060904-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
@ 2016-03-14 11:14 ` Dan Carpenter
0 siblings, 0 replies; 3+ messages in thread
From: Dan Carpenter @ 2016-03-14 11:14 UTC (permalink / raw)
To: Shawn Lin
Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-spi-u79uwXL29TY76Z2rM5mHXA
On Mon, Mar 14, 2016 at 06:21:00PM +0800, Shawn Lin wrote:
> On 2016/3/14 17:48, Dan Carpenter wrote:
> >Hello Shawn Lin,
> >
> >The patch 61cadcf46cfd: "spi: rockchip: check requesting dma channel
> >with EPROBE_DEFER" from Mar 9, 2016, leads to the following static
> >checker warning:
> >
> > drivers/spi/spi-rockchip.c:742 rockchip_spi_probe()
> > warn: passing zero to 'PTR_ERR'
> >
> >drivers/spi/spi-rockchip.c
> > 732
> > 733 rs->dma_tx.ch = dma_request_slave_channel(rs->dev, "tx");
> > 734 if (IS_ERR_OR_NULL(rs->dma_tx.ch)) {
> > 735 /* Check tx to see if we need defer probing driver */
> > 736 if (PTR_ERR(rs->dma_tx.ch) == -EPROBE_DEFER) {
> > 737 ret = -EPROBE_DEFER;
> > 738 goto err_get_fifo_len;
> >
> >What's going on here? Are we planning to change dma_request_slave_channel()
> >to return error pointers? Also what about other error pointers besides
> >EPROBE_DEFER it seems dangerous to leave rs->dma_tx.ch as an error
> >pointer. We probably eventually try to free it if it's non-NULL.
>
> yes, we are plannig to return EPROBE_DEFER/NULL for
> dma_request_slave_channel to make sure we don't decide
> the dma cap based on driver probe sequence.
>
> No any other error pointer will be returned to the caller
It would not be terribly shocking if a couple years from now someone
else adds a new error return without auditing all the caller functions.
regards,
dan carpenter
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-03-14 11:14 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-03-14 9:48 spi: rockchip: check requesting dma channel with EPROBE_DEFER Dan Carpenter
2016-03-14 10:21 ` Shawn Lin
[not found] ` <56E6908C.3060904-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2016-03-14 11:14 ` Dan Carpenter
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.