> On Jun 30, 2018, at 10:50 AM, Frank Kardel <kar...@netbsd.org> wrote:
>
> Hi Jason !
>
> It is not so odd as your comment suggests. The I2C address is stored in the
> device EEPROM and perfectly survives a power off.
Ah! If the data sheet mentions this fact, I completely missed it.
I'm afraid I probably did break it, so let's figure out how to fix... can it be
programmed to an arbitrary address, or are there a set of specific ones you can
chose from?
>
> All we need to be able to is to explicitly configure the device at a
> different address. I hope this capability was not disabled with this check-in
> as that would make my second sensor at 0x29 useless and prohibit multiple
> sensors on a I2C bus.
>
> For configuring the I2C address to a different value see the pkgsrc package
> hytctl.
>
> Thanks for re-working the attachment logic.
>
> Frank
>
>
> On 06/16/18 23:24, Jason R Thorpe wrote:
>> Module Name: src
>> Committed By: thorpej
>> Date: Sat Jun 16 21:24:36 UTC 2018
>>
>> Modified Files:
>> src/sys/dev/i2c: hytp14.c
>>
>> Log Message:
>> More cleanup to i2c autoconfiguration:
>>
>> - Get all of the drivers onto the new match quality constants.
>> - Introduce a new helper function, iic_use_direct_match(), that has
>> all of the logic for direct-config matching. If it returns true,
>> the driver returns the match result (which may be 0). If it returns
>> false, the driver does indirect-config matching.
>> - iic_compat_match() now returns a weighted match quality; matches to
>> lower-indexed "compatible" device property are more-specific matches,
>> and return a better match quality accordingly.
>>
>> XXX This driver is an odd-ball with respect to the hardware device.
>> See comments in the match routine. Unclear how best to handle it.
>>
>>
>> To generate a diff of this commit:
>> cvs rdiff -u -r1.7 -r1.8 src/sys/dev/i2c/hytp14.c
>>
>> Please note that diffs are not public domain; they are subject to the
>> copyright notices on the relevant files.
>>
>
-- thorpej
