All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Paul Bolle <pebolle@tiscali.nl>
Cc: David Miller <davem@davemloft.net>, linux-kernel@vger.kernel.org
Subject: Re: Can we drop __must_check from driver_for_each_device()?
Date: Wed, 7 Aug 2013 14:51:54 +0900	[thread overview]
Message-ID: <20130807055154.GA5304@kroah.com> (raw)
In-Reply-To: <1375821085.7303.33.camel@x61.thuisdomein>

On Tue, Aug 06, 2013 at 10:31:25PM +0200, Paul Bolle wrote:
> On Fri, 2013-08-02 at 08:31 +0800, Greg Kroah-Hartman wrote:
> > On Wed, Jul 31, 2013 at 11:35:13PM +0200, Paul Bolle wrote:
> > > 2) Please note that if the callback always returns zero,
> > > driver_for_each_device() can still return -EINVAL, but only if it was
> > > provided a NULL "drv" (a struct device_driver). It sure seems odd to do
> > > so. Can that actually happen?
> > 
> > Possibly.
> 
> So driver_for_each_device() really should be NULL "drv" safe.

Probably not, now that I think about it some more.  I don't see how that
could ever really happen, do you?

> But wouldn't it therefor be better to make sure the callback functions
> do not return -EINVAL themselves, so -EINVAL will always only indicate
> the NULL "drv" case?

I doubt it's a real need at all.

> > > 3) So to me it looks the __must_check attribute of
> > > driver_for_each_device() can be dropped. Do you agree?
> > 
> > Nope, it should be making people think about the return value of the
> > function.  If they use it or not might be a problem, but I would argue
> > that those call-sites must be fixed, as you point out above.
> 
> I see. I guess I should try to submit patches that do just that.
> 
> > Is this somehow causing a problem that removing the marking would solve
> > for you?
> 
> The, rather trivial, issue I'd like to fix is this (long standing)
> warning:
>     drivers/isdn/hardware/mISDN/hfcpci.c:2298:2: warning: \
>     ignoring return value of ‘driver_for_each_device’, \
>     declared with attribute warn_unused_result [-Wunused-result]
>
> I've submitted a patch to silence that warning about a year ago (see
> https://lkml.org/lkml/2012/9/21/138 ). Dave Miller was pretty clear that
> that approach wouldn't do. (I've added Dave to the CC, just because I
> mentioned him here.)

I agree with David, that patch is pointless.

> So, since this warning is still there, I'm looking for another way to
> get rid of it.

Fix it properly would be good to do, don't you think?

thanks,

greg k-h

  reply	other threads:[~2013-08-07  5:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-31 21:35 Can we drop __must_check from driver_for_each_device()? Paul Bolle
2013-08-02  0:31 ` Greg Kroah-Hartman
2013-08-06 20:31   ` Paul Bolle
2013-08-07  5:51     ` Greg Kroah-Hartman [this message]
2013-08-07 16:57       ` Paul Bolle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130807055154.GA5304@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pebolle@tiscali.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.