lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 27 Sep 2010 00:04:01 +0100 From: Ben Dooks <ben-linux@...ff.org> To: Sundar <sunder.svit@...il.com> CC: Kenneth Heitke <kheitke@...eaurora.org>, tsoni@...eaurora.org, Daniel Walker <dwalker@...eaurora.org>, sdharia@...eaurora.com, linus.walleij@...ricsson.com, Crane Cai <crane.cai@....com>, srinidhi.kasagar@...ricsson.com, linux-arm-msm@...r.kernel.org, Bryan Huntsman <bryanh@...eaurora.org>, Ralf Baechle <ralf@...ux-mips.org>, linux-kernel@...r.kernel.org, arve@...roid.com, linux-i2c@...r.kernel.org, ben-linux@...ff.org, swetland@...gle.com, khali@...ux-fr.org, Russell King <linux@....linux.org.uk>, David Brown <davidb@...eaurora.org>, linux-arm-kernel@...ts.infradead.org, Samuel Ortiz <sameo@...ux.intel.com> Subject: Re: [PATCH v3] i2c: QUP based bus driver for Qualcomm MSM chipsets On 09/09/10 20:01, Sundar wrote: > Hi Kenneth, > > just some error codes and leaks if I am right :) > > On Wed, Sep 8, 2010 at 6:29 AM, Kenneth Heitke <kheitke@...eaurora.org> wrote: >> + >> +static int __devinit >> +qup_i2c_probe(struct platform_device *pdev) >> +{ >> + >> + qup_mem = platform_get_resource_byname(pdev, IORESOURCE_MEM, >> + "qup_phys_addr"); >> + if (!qup_mem) { >> + dev_err(&pdev->dev, "no qup mem resource?\n"); >> + return -ENODEV; > > I think this should be -ENXIO instead of -ENODEV? I think both are inappropriate here, -ENXIO is an IO failure and -ENODEV is 'device is not here'. However, some people don't like the use of things like -ENOENT (filesystem errors) for this sort of situation. ENOTSUP might be something you could use. As a note, both ENXIO and ENODEV will be taken by the device framework as a device is not there at-all and not display any error to the user (which is annoying if you then forget to do anything about it) As a note, you may want to have a look at devres to offload the tracking of the requested and mapped resources. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists