[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101019154627.GC4589@kroah.com>
Date: Tue, 19 Oct 2010 08:46:27 -0700
From: Greg KH <greg@...ah.com>
To: Ohad Ben-Cohen <ohad@...ery.com>
Cc: linux-omap@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, akpm@...ux-foundation.org,
Tony Lindgren <tony@...mide.com>,
Benoit Cousson <b-cousson@...com>,
Grant Likely <grant.likely@...retlab.ca>,
Hari Kanigeri <h-kanigeri2@...com>, Suman Anna <s-anna@...com>,
Simon Que <sque@...com>,
"Krishnamoorthy, Balaji T" <balajitk@...com>
Subject: Re: [PATCH 1/3] drivers: misc: add omap_hwspinlock driver
On Mon, Oct 18, 2010 at 09:44:33AM +0200, Ohad Ben-Cohen wrote:
> +#else /* !CONFIG_OMAP_HWSPINLOCK */
> +
> +static inline struct omap_hwspinlock *omap_hwspinlock_request(void)
> +{
> + return ERR_PTR(-ENOSYS);
> +}
One note, do you really want to fail if this option isn't built into the
kernel, yet you have a driver that is asking for it? Shouldn't you
instead just silently succeed, and let the code path get compiled away?
We did that for debugfs, after learning the pain that procfs had with
its api for "is not built". Doing it the way you are requires the user
to always test for -ENOSYS, when in reality, if that is returned,
there's nothing the driver can do about it, so it should just not worry
about it.
Just something to think about.
thanks,
greg k-h
--
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