Hi Philip, On Wed, 18 Oct 2023 at 05:00, Philip Oberfichtner <p...@denx.de> wrote: > > Hi Heiko, > > On Wed, Oct 18, 2023 at 06:31:57AM +0200, Heiko Schocher wrote: > > [...] > > > > May Philip can use uclass_get_device_by_phandle and try a list of > > possible UCLASS candidates, like UCLASS_RTC, UCLASS_I2C_EEPROM, > > UCLASS_POWER,... and if found, check if parent is UCLASS_I2C... > > > > may not so expensive ... > > Looks more cheap and elegant than the other variants indeed. But I'm not > sure if we can maintain generality using this approach. > > What if the specific I2C driver is not included in the build, because > the devices "actual" functionality is not required?
Then the device will not be bound and the function will fail. There needs to be a node and a bound device. > Or what if a driver > for the specific device does not even exist in U-Boot? > > Wouldn't the device fail to probe then? The DT should specify the compatible string so the correct i2c driver is used. If there isn't one,I believe it uses I2C_GENERIC but you'll need to check it. > > Please correct me if I'm wrong, I'd give it a shot in that case. > Otherwise I'll try it with the aforementioned > device_find_global_by_ofnode() followed by device_bind_driver() using > UCLASS_I2C_GENERIC (I hope that works). That is the same approach, I think. But anyway I think Heiko knows more about this than me. Regards, Simon
