From: christian pellegrin <chripell-VaTbYqLCNhc@public.gmane.org>
To: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH net-next-2.6] can: Proper ctrlmode handling for CAN devices
Date: Thu, 14 Jan 2010 15:18:28 +0100 [thread overview]
Message-ID: <cabda6421001140618w2fb4e20fk680f8f01ff827e66@mail.gmail.com> (raw)
In-Reply-To: <4B4E2567.8060907-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On Wed, Jan 13, 2010 at 8:56 PM, Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org> wrote:
> Hi Christian,
Hi,
> Could you please explain, what the "check_ctrlmode" callback is good
> for. For me it seems useless, at a first glance. Without, also the
> variable ctrlmode is not necessary.
It's needed to avoid unmeaningful combinations like loop-back +
listen-only (it's quite sure you won't hear nothing and this mode
isn't even programmable on the mcp251x for example; other could be
more subtle, like having one-shot mode on or off doesn't make any
difference both with loop-back or listen-only). Of course I can
hard-code this but if we add some other fancy options with
controller-specific behavior I'm not sure all the possible cases could
be catch. On the other hand it's supposed that people who set ctrlmode
more or less know what are they doing, so this test may be superflous.
If you think so I can just eliminate it.
>> + return -EOPNOTSUPP;
>
> In another mail you mentioned, that "ENOTSUPP" does not result in a
> useful user space error message. I checked "errno.h" of my Linux
> distribution and there ENOTSUPP is not even defined, in contrast to
> "EOPNOTSUPP". Hm, ENOTSUPP is used in may places in the kernel and also
> in some CAN source files and I think we should fix that.
>
I agree, perhaps this should be pointed out on LKML too (even if we
risk to ignite a flame war between kernel and glibc folks ;-) )
>> + return 0;
>> +}
>
> For me this check never fails if "priv->can.ctrlmode_supported" is set
> properly. Or have I missed something?
>
as I said above it catches the case when the device is put in
loop-back and listen-only at the same time.
--
Christian Pellegrin, see http://www.evolware.org/chri/
"Real Programmers don't play tennis, or any other sport which requires
you to change clothes. Mountain climbing is OK, and Real Programmers
wear their climbing boots to work in case a mountain should suddenly
spring up in the middle of the computer room."
next prev parent reply other threads:[~2010-01-14 14:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-13 17:27 [PATCH net-next-2.6] can: Proper ctrlmode handling for CAN devices Christian Pellegrin
[not found] ` <1263403629-18827-1-git-send-email-chripell-VaTbYqLCNhc@public.gmane.org>
2010-01-13 19:56 ` Wolfgang Grandegger
[not found] ` <4B4E2567.8060907-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
2010-01-14 14:18 ` christian pellegrin [this message]
[not found] ` <cabda6421001140618w2fb4e20fk680f8f01ff827e66-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-01-14 14:36 ` Wolfgang Grandegger
[not found] ` <4B4F2C01.5000007-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
2010-01-14 14:53 ` christian pellegrin
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=cabda6421001140618w2fb4e20fk680f8f01ff827e66@mail.gmail.com \
--to=chripell-vatbyqlcnhc@public.gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org \
--cc=wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).