linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lars-Peter Clausen <lars@metafoo.de>
To: Jonathan Cameron <jic23@kernel.org>
Cc: Hartmut Knaack <knaack.h@gmx.de>, linux-iio@vger.kernel.org
Subject: Re: [RFC]coding style for NULL pointer checks
Date: Thu, 20 Feb 2014 20:13:25 +0100	[thread overview]
Message-ID: <530653D5.8010404@metafoo.de> (raw)
In-Reply-To: <53064FA8.9060104@kernel.org>

On 02/20/2014 07:55 PM, Jonathan Cameron wrote:
> On 19/02/14 22:54, Hartmut Knaack wrote:
>> Jonathan Cameron schrieb:
>>> On 16/02/14 18:56, Lars-Peter Clausen wrote:
>>>> On 02/16/2014 01:19 PM, Hartmut Knaack wrote:
>>>>> Hi together,
>>>>> I noticed, that many pointers in the IIO subsystem are checked for
>>>>> successful allocation in the way of "if (pointer == NULL)" or "if (pointer
>>>>> != NULL)", while in a few cases the form of simply "if (!pointer)" or "if
>>>>> (pointer)" is used. So, is there any interest in having a more consistent
>>>>> style, and if so, for which one?
>>>>> My personal preference is for the latter one.
>>>> I think enforcing this is a bit to much nitpicking. So if you clean this up
>>>> the other pattern will probably appear again in new drivers at some point.
>>>>
>>>> Otherwise, if you feel strongly about this, go ahead and send a patch.
>>> My inclination on this is that there are better things to spend time on
>>> but as they say scratch the itch if you really want to!
>>>
>>> I'd rather have the nice error patch cleanups you've been doing or
>>> if you are really bored, there are lots of staging drivers in need of
>>> tendour loving care!
>>>
>>> J
>> Well, never mind then. Do you have some kind of To-Do-List?
> Saddly I / we are never quite that organised.  Tends to be mostly take
> a nice cleanup that was applied to a driver and propagate it across similar
> parts.  One outstanding one right now is to use the shared_by infomask
> elements recently introduced (by_dir and by_all) to get rid of as many
> hand specified attributes as possible.  The other big helpful thing
> is to review other peoples submissions.
>> Otherwise I would get back to my other projects.
> That's fair enough.  Nice to have some variety!
>> Concerning the staging drivers, I miss some motivation to work on
>> device drivers that I don't have the devices for.
> That's fair enough.  Strangely I can't remember when I last did any
> work on a device I actually own ;)  Still have a quite a few here
> somewhere that don't have drivers, but need to get the soldering iron out
> and never seem to get time.
>> Therefor I was  mainly focusing on the ad799x. So, by the way, which are
>> currently the show-stoppers for the ad799x preventing a move out of staging?
> None that I know of, other than a final review.  Sounds like Lars is happy which
> is always a good sign.
>> And, are there any plans to provide documentation about the supported IIO
>> devices (similar to hwmon)?
> Err. we tried this for a bit on the iio-utils wiki page, but rapidly got
> left behind.
>
> I guess it might be a useful resource if anyone fancies maintaining it?

For the ADI drivers we actually do have quite a bit of documentation. But it is 
not in the kernel tree, but on our wiki: 
http://wiki.analog.com/resources/tools-software/linux-drivers-all

- Lars

      reply	other threads:[~2014-02-20 19:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-16 12:19 [RFC]coding style for NULL pointer checks Hartmut Knaack
2014-02-16 18:56 ` Lars-Peter Clausen
2014-02-18  8:40   ` Jonathan Cameron
2014-02-19 22:54     ` Hartmut Knaack
2014-02-20  9:04       ` Lars-Peter Clausen
2014-02-20 18:55       ` Jonathan Cameron
2014-02-20 19:13         ` Lars-Peter Clausen [this message]

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=530653D5.8010404@metafoo.de \
    --to=lars@metafoo.de \
    --cc=jic23@kernel.org \
    --cc=knaack.h@gmx.de \
    --cc=linux-iio@vger.kernel.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).