Thomas, > Hopefully the information below explains the problem with the current pca9665_reset() function. Yes, it does :) > Let's say mod1 has the following This was the first needed information. You seem to not use i2c-pca-platform but a custom driver using the pca-algo, right? May I ask why the custom one is needed? > Now with the pca9665_reset() function, the i2c-algo-pca module sets > the mod1's reset_chip function pointer to pca9665_reset. When > pca_reset(adap) is called, the input parameter is of type > i2c_algo_pca_data as expected. Then pca_reset() calls > adap->reset_chip (pca9665_reset) with the first parameter being > adap->data. This parameter is of type mod1_pca_data_t * in this > example. The problem comes from the fact that pca9665_reset(void *pd) > is expecting the parameter to be of type i2c_algp_pca_data: To put in other words: All other wrappers from the algo call back to the bus driver which knows to handle its custom data. Only the pca9665 reset is staying inside the algo and facing a custom data structure it doesn't know. Okay, understood now. Thanks, Wolfram -- Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ |
Attachment:
signature.asc
Description: Digital signature
