From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759033AbbA3P7r (ORCPT ); Fri, 30 Jan 2015 10:59:47 -0500 Received: from mail-qg0-f49.google.com ([209.85.192.49]:54156 "EHLO mail-qg0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752080AbbA3P7o (ORCPT ); Fri, 30 Jan 2015 10:59:44 -0500 Message-ID: <54CBAA6E.3050904@hurleysoftware.com> Date: Fri, 30 Jan 2015 10:59:42 -0500 From: Peter Hurley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Russell King - ARM Linux CC: Thierry Reding , Varka Bhadram , Chunyan Zhang , gregkh@linuxfoundation.org, mark.rutland@arm.com, gnomes@lxorguk.ukuu.org.uk, heiko@sntech.de, andrew@lunn.ch, jslaby@suse.cz, lanqing.liu@spreadtrum.com, pawel.moll@arm.com, zhang.lyra@gmail.com, zhizhou.zhang@spreadtrum.com, geng.ren@spreadtrum.com, antonynpavlov@gmail.com, linux-serial@vger.kernel.org, grant.likely@linaro.org, orsonzhai@gmail.com, florian.vaussard@epfl.ch, devicetree@vger.kernel.org, jason@lakedaemon.net, arnd@arndb.de, ijc+devicetree@hellion.org.uk, hytszk@gmail.com, robh+dt@kernel.org, wei.qiao@spreadtrum.com, linux-arm-kernel@lists.infradead.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, galak@codeaurora.org, shawn.guo@linaro.org Subject: Re: [PATCH v10 2/2] tty/serial: Add Spreadtrum sc9836-uart driver support References: <1422443324-25082-1-git-send-email-chunyan.zhang@spreadtrum.com> <1422443324-25082-3-git-send-email-chunyan.zhang@spreadtrum.com> <54CA5128.8050500@gmail.com> <54CA568E.6080306@hurleysoftware.com> <20150129160553.GC26493@n2100.arm.linux.org.uk> <20150130101838.GC16744@ulmo> <54CB72F7.8060706@hurleysoftware.com> <20150130140854.GJ26493@n2100.arm.linux.org.uk> <54CBA426.7050900@hurleysoftware.com> <20150130154926.GN26493@n2100.arm.linux.org.uk> In-Reply-To: <20150130154926.GN26493@n2100.arm.linux.org.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/30/2015 10:49 AM, Russell King - ARM Linux wrote: > On Fri, Jan 30, 2015 at 10:32:54AM -0500, Peter Hurley wrote: >> Before you say consistency, I think you should look at the stats below. >> IOW, if you want to change the error code return from probe() for >> consistency's sake, a tree-wide patch would be the appropriate way. > > Now look outside the serial driver sub-tree. > > There are 1234 instances of platform_get_resource(, IORESOURCE_MEM, ) in > the drivers/ sub-tree, with 700 instances of devm_ioremap_resource() > being used there. Of the devm_ioremap_resource() instances: > > - 555 use platform_get_resource() in the preceding two lines - which is > not enough to do anything but rely on the -EINVAL return value. > - 16 mention ENODEV in the preceding three lines. > > There are 132 which use platform_get_resource() and return ENODEV within > the following three lines (which may intersect with the above 16 number) > and 88 which use EINVAL. > > So, there are in total 643 instances where a missing resource returns > EINVAL, and between 132 and 148 instances which return ENODEV. > > Yes, 643 + 148 isn't 1234, but I'm not going to read through all 1234 > locations just for the sake of this thread. What's clear though is that > more than 50% of sites using platform_get_resource(, IORESOURCE_MEM, ) > return EINVAL for the lack of a resource. Sure, now that they're using devm_ioremap_resource(). What about before they were converted? For example, of the 10 serial drivers now using devm_ioremap_resource(), _not 1 returned EINVAL_ prior to using devm_ioremap_resource(). And of those 10 commits, only 1 mentions changing the return codes on purpose. In fact, all of them but one returned ENODEV. Regards, Peter Hurley From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Hurley Subject: Re: [PATCH v10 2/2] tty/serial: Add Spreadtrum sc9836-uart driver support Date: Fri, 30 Jan 2015 10:59:42 -0500 Message-ID: <54CBAA6E.3050904@hurleysoftware.com> References: <1422443324-25082-1-git-send-email-chunyan.zhang@spreadtrum.com> <1422443324-25082-3-git-send-email-chunyan.zhang@spreadtrum.com> <54CA5128.8050500@gmail.com> <54CA568E.6080306@hurleysoftware.com> <20150129160553.GC26493@n2100.arm.linux.org.uk> <20150130101838.GC16744@ulmo> <54CB72F7.8060706@hurleysoftware.com> <20150130140854.GJ26493@n2100.arm.linux.org.uk> <54CBA426.7050900@hurleysoftware.com> <20150130154926.GN26493@n2100.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150130154926.GN26493-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Russell King - ARM Linux Cc: Thierry Reding , Varka Bhadram , Chunyan Zhang , gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org, mark.rutland-5wv7dgnIgG8@public.gmane.org, gnomes-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org, heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org, andrew-g2DYL2Zd6BY@public.gmane.org, jslaby-AlSwsSmVLrQ@public.gmane.org, lanqing.liu-lxIno14LUO0EEoCn2XhGlw@public.gmane.org, pawel.moll-5wv7dgnIgG8@public.gmane.org, zhang.lyra-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, zhizhou.zhang-lxIno14LUO0EEoCn2XhGlw@public.gmane.org, geng.ren-lxIno14LUO0EEoCn2XhGlw@public.gmane.org, antonynpavlov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, orsonzhai-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, florian.vaussard-p8DiymsW2f8@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org, arnd-r2nGTMty4D4@public.gmane.org, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org, hytszk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, wei.qiao-lxIno14LUO0EEoCn2XhGlw@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org List-Id: devicetree@vger.kernel.org On 01/30/2015 10:49 AM, Russell King - ARM Linux wrote: > On Fri, Jan 30, 2015 at 10:32:54AM -0500, Peter Hurley wrote: >> Before you say consistency, I think you should look at the stats below. >> IOW, if you want to change the error code return from probe() for >> consistency's sake, a tree-wide patch would be the appropriate way. > > Now look outside the serial driver sub-tree. > > There are 1234 instances of platform_get_resource(, IORESOURCE_MEM, ) in > the drivers/ sub-tree, with 700 instances of devm_ioremap_resource() > being used there. Of the devm_ioremap_resource() instances: > > - 555 use platform_get_resource() in the preceding two lines - which is > not enough to do anything but rely on the -EINVAL return value. > - 16 mention ENODEV in the preceding three lines. > > There are 132 which use platform_get_resource() and return ENODEV within > the following three lines (which may intersect with the above 16 number) > and 88 which use EINVAL. > > So, there are in total 643 instances where a missing resource returns > EINVAL, and between 132 and 148 instances which return ENODEV. > > Yes, 643 + 148 isn't 1234, but I'm not going to read through all 1234 > locations just for the sake of this thread. What's clear though is that > more than 50% of sites using platform_get_resource(, IORESOURCE_MEM, ) > return EINVAL for the lack of a resource. Sure, now that they're using devm_ioremap_resource(). What about before they were converted? For example, of the 10 serial drivers now using devm_ioremap_resource(), _not 1 returned EINVAL_ prior to using devm_ioremap_resource(). And of those 10 commits, only 1 mentions changing the return codes on purpose. In fact, all of them but one returned ENODEV. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: peter@hurleysoftware.com (Peter Hurley) Date: Fri, 30 Jan 2015 10:59:42 -0500 Subject: [PATCH v10 2/2] tty/serial: Add Spreadtrum sc9836-uart driver support In-Reply-To: <20150130154926.GN26493@n2100.arm.linux.org.uk> References: <1422443324-25082-1-git-send-email-chunyan.zhang@spreadtrum.com> <1422443324-25082-3-git-send-email-chunyan.zhang@spreadtrum.com> <54CA5128.8050500@gmail.com> <54CA568E.6080306@hurleysoftware.com> <20150129160553.GC26493@n2100.arm.linux.org.uk> <20150130101838.GC16744@ulmo> <54CB72F7.8060706@hurleysoftware.com> <20150130140854.GJ26493@n2100.arm.linux.org.uk> <54CBA426.7050900@hurleysoftware.com> <20150130154926.GN26493@n2100.arm.linux.org.uk> Message-ID: <54CBAA6E.3050904@hurleysoftware.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 01/30/2015 10:49 AM, Russell King - ARM Linux wrote: > On Fri, Jan 30, 2015 at 10:32:54AM -0500, Peter Hurley wrote: >> Before you say consistency, I think you should look at the stats below. >> IOW, if you want to change the error code return from probe() for >> consistency's sake, a tree-wide patch would be the appropriate way. > > Now look outside the serial driver sub-tree. > > There are 1234 instances of platform_get_resource(, IORESOURCE_MEM, ) in > the drivers/ sub-tree, with 700 instances of devm_ioremap_resource() > being used there. Of the devm_ioremap_resource() instances: > > - 555 use platform_get_resource() in the preceding two lines - which is > not enough to do anything but rely on the -EINVAL return value. > - 16 mention ENODEV in the preceding three lines. > > There are 132 which use platform_get_resource() and return ENODEV within > the following three lines (which may intersect with the above 16 number) > and 88 which use EINVAL. > > So, there are in total 643 instances where a missing resource returns > EINVAL, and between 132 and 148 instances which return ENODEV. > > Yes, 643 + 148 isn't 1234, but I'm not going to read through all 1234 > locations just for the sake of this thread. What's clear though is that > more than 50% of sites using platform_get_resource(, IORESOURCE_MEM, ) > return EINVAL for the lack of a resource. Sure, now that they're using devm_ioremap_resource(). What about before they were converted? For example, of the 10 serial drivers now using devm_ioremap_resource(), _not 1 returned EINVAL_ prior to using devm_ioremap_resource(). And of those 10 commits, only 1 mentions changing the return codes on purpose. In fact, all of them but one returned ENODEV. Regards, Peter Hurley