From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dsl78-143-211-26.in-addr.fast.co.uk ([78.143.211.26]:37501 "EHLO ben-laptop" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S932266Ab0IZXEY (ORCPT ); Sun, 26 Sep 2010 19:04:24 -0400 Message-ID: <4C9FD161.2000606@fluff.org> Date: Mon, 27 Sep 2010 00:04:01 +0100 From: Ben Dooks MIME-Version: 1.0 Subject: Re: [PATCH v3] i2c: QUP based bus driver for Qualcomm MSM chipsets References: <1283907557-1874-1-git-send-email-kheitke@codeaurora.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-arm-msm-owner@vger.kernel.org List-ID: To: Sundar Cc: Kenneth Heitke , tsoni@codeaurora.org, Daniel Walker , sdharia@codeaurora.com, linus.walleij@stericsson.com, Crane Cai , srinidhi.kasagar@stericsson.com, linux-arm-msm@vger.kernel.org, Bryan Huntsman , Ralf Baechle , linux-kernel@vger.kernel.org, arve@android.com, linux-i2c@vger.kernel.org, ben-linux@fluff.org, swetland@google.com, khali@linux-fr.org, Russell King , David Brown , linux-arm-kernel@lists.infradead.org, Samuel Ortiz 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 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Dooks Subject: Re: [PATCH v3] i2c: QUP based bus driver for Qualcomm MSM chipsets Date: Mon, 27 Sep 2010 00:04:01 +0100 Message-ID: <4C9FD161.2000606@fluff.org> References: <1283907557-1874-1-git-send-email-kheitke@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-i2c-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Sundar Cc: Kenneth Heitke , tsoni-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, Daniel Walker , sdharia-sgV2jX0FEOLY0TyS/+Ba5Q@public.gmane.org, linus.walleij-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org, Crane Cai , srinidhi.kasagar-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org, linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Bryan Huntsman , Ralf Baechle , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, arve-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org, linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org, swetland-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org, Russell King , David Brown , linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Samuel Ortiz List-Id: linux-i2c@vger.kernel.org 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 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: ben-linux@fluff.org (Ben Dooks) Date: Mon, 27 Sep 2010 00:04:01 +0100 Subject: [PATCH v3] i2c: QUP based bus driver for Qualcomm MSM chipsets In-Reply-To: References: <1283907557-1874-1-git-send-email-kheitke@codeaurora.org> Message-ID: <4C9FD161.2000606@fluff.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 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.