Re: Overhaul of I2C and SPI device autoconfiguration

[Jason Thorpe <thorpej%me.com@localhost>]

> On Sep 12, 2021, at 2:49 PM, Tobias Nygren <tnn%NetBSD.org@localhost> wrote:
> 
> On Sun, 12 Sep 2021 12:30:14 -0700
> Jason Thorpe <thorpej%me.com@localhost> wrote:
> 
>> Ok, sparc64 should be good do go now.  I made a bunch of fake fixup entries for the Qemu machine and, after a couple of additional fixes, verified that the machinery is working as expected.
> 
> Gets further but hits another problem.
> bus mutex uninitialized or points at wrong data?
> 
> iic0 at pcfiic0: I2C bus
> cpu0: data fault: pc=105f440 rpc=143e594 addr=1afc000
> kernel trap 6c: +fast data access protection
> Stopped in pid 0.0 (system) at  netbsd:_lock_cas:       casxa           0x80, %o1, %o2
> db{0}> bt
> iic_acquire_bus(1afd088, 8, 2003dac, 1af0400, 1afd098, 10) at netbsd:iic_acquire_bus+0x94
> spdmem_i2c_match(1075dfa80, 1c66f00, 2004710, 1aecc00, 73, 1c60b98) at netbsd:spdmem_i2c_match+0xa4
> config_match(1075dfa80, 1c66f00, 2004710, 2004710, 20, 0) at netbsd:config_match+0x38
> [rest of trace omitted]

Ok, I'm a little confused by this one.  pcfiic_attach() allocates a single channel structure if the ebus front-end did not already do so.  And then for either case, it then enumerates the channels and calls iic_tag_init(&ch->ch_i2c) for the tag on each one, which initializes the bus mutex.

Hm, but I spotted another bug ... I didn't update pcfiic_i2c_exec() for the channel split.  That could be clobbering something.  I just pushed an update to dev/ic/pcf8584.c -- can you give it a spin?

-- thorpej