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
>>
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
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,
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
