Hi Masahiro,
On 3 December 2014 at 08:52, Masahiro YAMADA <yamad...@jp.panasonic.com> wrote:
> Hi Simon,
>
>
> 2014-12-04 0:23 GMT+09:00 Simon Glass <s...@chromium.org>:
>
>>>> -/* Probe to see if a chip is present. */
>>>> -static int tegra_i2c_probe(struct i2c_adapter *adap, uchar chip)
>>>> +static int tegra_i2c_set_offset_len(struct udevice *dev, const uint olen)
>>>> {
>>>> - struct i2c_bus *bus;
>>>> - int rc;
>>>> - uchar reg;
>>>> -
>>>> - debug("i2c_probe: addr=0x%x\n", chip);
>>>> - bus = tegra_i2c_get_bus(adap);
>>>> - if (!bus)
>>>> - return 1;
>>>> - reg = 0;
>>>> - rc = i2c_write_data(bus, chip, ®, 1, false);
>>>> - if (rc) {
>>>> - debug("Error probing 0x%x.\n", chip);
>>>> - return 1;
>>>> - }
>>>> - return 0;
>>>> -}
>>>> + if (olen < 4)
>>>> + return 0;
>>>
>>>
>>> The maximum length 4 is not tegra-specific.
>>> I can't find good reason to have .set_offset_len handler.
>>
>> It's not needed here as 4 is the maximum supported by the uclass. Some
>> drivers may support less though, so perhaps we should keep the method?
>>
>
> I think this handler is totally useless.
>
> Moreover, the offset address within a chip is out of the scope of I2C
> protocol.
> I think it is odd for each of I2C drivers to care about it.
The Intel SPI driver requires us to figure out the offset from the
spi_xfer() call, and it is painful. I wondered if there might be I2C
drivers that need to do the same thing. I have not looked.
Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
