Messages in this thread | | | Date | Fri, 31 Mar 2023 22:23:55 +0200 | Subject | Re: [PATCH 1/2] dmaengine: mv_xor_v2: Fix an error code. | From | Christophe JAILLET <> |
| |
Le 29/03/2023 à 12:27, Dan Carpenter a écrit : > On Sun, Mar 26, 2023 at 09:06:37AM +0200, Christophe JAILLET wrote: >> If the probe is deferred, -EPROBE_DEFER should be returned, not >> +EPROBE_DEFER. >> >> Fixes: 3cd2c313f1d6 ("dmaengine: mv_xor_v2: Fix clock resource by adding a register clock") >> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> >> --- >> drivers/dma/mv_xor_v2.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/dma/mv_xor_v2.c b/drivers/dma/mv_xor_v2.c >> index 89790beba305..0991b8265829 100644 >> --- a/drivers/dma/mv_xor_v2.c >> +++ b/drivers/dma/mv_xor_v2.c >> @@ -752,7 +752,7 @@ static int mv_xor_v2_probe(struct platform_device *pdev) >> >> xor_dev->clk = devm_clk_get(&pdev->dev, NULL); >> if (PTR_ERR(xor_dev->clk) == -EPROBE_DEFER) { >> - ret = EPROBE_DEFER; >> + ret = -EPROBE_DEFER; >> goto disable_reg_clk; > > Heh. Looking through the Smatch results, I don't think this actually > affects runtime because driver_probe_device() checks for both positive > and negatives. People shouldn't be returning positives, of course, but > it appears there is a work around for bugs built in already.
Correct, but weird.
I've tried to look at the history of [1], but couldn't find any rational for it.
Apparently it was already in the v1 of the serie. [2]
CJ
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=45ddcb42949f825f0caa25352e825cede94b6aba [2]: https://lore.kernel.org/all/20210614150846.4111871-5-hch@lst.de/
> > regards, > dan carpenter > >
| |