From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Kieran Bingham <kieran.bingham@ideasonboard.com>
Cc: Wolfram Sang <wsa@the-dreams.de>,
Linux I2C <linux-i2c@vger.kernel.org>,
"open list:MEDIA DRIVERS FOR RENESAS - FCP"
<linux-renesas-soc@vger.kernel.org>
Subject: Re: i2c_new_{secondary_device,dummy,device}() return type.
Date: Fri, 09 Feb 2018 14:26:36 +0200 [thread overview]
Message-ID: <9433176.auEORrE3aR@avalon> (raw)
In-Reply-To: <6f03d1e1-b542-99cb-7cfe-8eae9addd8d9@ideasonboard.com>
Hi Kieran,
On Friday, 9 February 2018 12:01:09 EET Kieran Bingham wrote:
> Hi Wolfram,
>
> As part of my work looking at using i2c_new_secondary_device() to move
> address mappings into the device tree, it has become evident that the
> return code of the i2c_new_secondary_device() is obfuscated, and is simply
> a valid client - or NULL.
>
> This means that we must 'guess' as to whether the device failed due to a
> memory allocation, or if the device address was already in use (perhaps a
> more common failure).
>
> Because of this - I would like to see the return codes of
> i2c_new_secondary_device(), ic2_new_dummy(), and therefore i2c_new_device()
> support returning ERR_PTR()s rather than a client or NULL.
>
> These functions are used fairly extensively - thus it will be a fair bit of
> work (or a good coccinelle script) - So I'd like to ask your opinion on the
> validity of this task before I commence anything down that rabbit hole!
>
> Any comments? Pre-ack/nack? (from anyone?)
Pre-ack from me :-)
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2018-02-09 12:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-09 10:01 i2c_new_{secondary_device,dummy,device}() return type Kieran Bingham
2018-02-09 10:01 ` Kieran Bingham
2018-02-09 12:26 ` Laurent Pinchart [this message]
2018-02-09 17:59 ` Heiner Kallweit
2018-02-09 18:07 ` Kieran Bingham
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=9433176.auEORrE3aR@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=kieran.bingham@ideasonboard.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=wsa@the-dreams.de \
/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.