Re: [PATCH] i2c-EEPROM: Export memory accessor

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi David,

On Oct 30, 2012, at 8:46 PM, David Daney wrote:

> On 10/31/2012 08:56 AM, Pantelis Antoniou wrote:
>> Various platforms need access to the EEPROM in other
>> places besides their platform registration callbacks.
>> Export the memory accessor to the i2c_client
> 
> i2c_clients are *not* intrinsically memory, so adding this to the generic i2c_client structure doesn't really make sense.   What would the semantics of this interface be with respect to temperature sensors and GPIO expanders?
> 
> NACK.
> 

It's only filled in for EEPROM devices. There's no other I2C memory read interface for kernel clients.

> 
>> and implement
>> it for the at24 driver.
>> 
>> And before you ask, no, the platform callback can't be used
>> for anything that depends on DT.
> 
> Why can't you just allocate (and populate) a struct at24_platform_data for the device if it isn't supplied by whatever created the device?
> 
> 
> 

There are no platform_data in the case of device tree only generic-boards. Everything is configured via the DT and there are
no callbacks. DT is a purely data driver concept.

I'm open to suggestions on how to read an EEPROM from another kernel client, when there's no such thing as platform_data anymore.

Regards

-- Pantelis



--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux