i2c_new_{secondary_device,dummy,device}() return type.

i2c_new_{secondary_device,dummy,device}() return type.

[Kieran Bingham]

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?)

Re: i2c_new_{secondary_device,dummy,device}() return type.

[Laurent Pinchart]

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

Re: i2c_new_{secondary_device,dummy,device}() return type.

[Heiner Kallweit]

Am 09.02.2018 um 11:01 schrieb Kieran Bingham:
> 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?)
> 

This has been addressed as part of adding a devm_i2c_new_dummy().
Related patches are in status "under review" since end of December.
See also here:
https://marc.info/?l=linux-i2c&m=151375074832371&w=2
https://patchwork.ozlabs.org/patch/851268/

Maybe these patches cover already what you need.

Rgds, Heiner

> --
> Regards
> 
> Kieran Bingham
> .
> 

Re: i2c_new_{secondary_device,dummy,device}() return type.

[Kieran Bingham]

Hi Heiner,

On 09/02/18 17:59, Heiner Kallweit wrote:
> Am 09.02.2018 um 11:01 schrieb Kieran Bingham:
>> 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?)
>>
> 
> This has been addressed as part of adding a devm_i2c_new_dummy().
> Related patches are in status "under review" since end of December.
> See also here:
> https://marc.info/?l=linux-i2c&m=151375074832371&w=2
> https://patchwork.ozlabs.org/patch/851268/
> 
> Maybe these patches cover already what you need.

Thankyou - I will take a look (albeit - next week now!)

--
Regards

Kieran

> 
> Rgds, Heiner
> 
>> --
>> Regards
>>
>> Kieran Bingham
>> .
>>
>