> You can have reading vdd from sysfs also update the cache, but then you > should also read data->ref_is_vdd at the same time. If the user is > going to always read all the values at once then this is the most > efficient approach. Yup. Just if not, then we will have another useless read (reading adc_ref_vdd when we always want to know vdd) as on embedded boards, sysfs is often used directly. Also, I can't factor out the caching-routine, as show_input() needs vdd only if adc_ref_vdd is set. Adding a force_flag for always reading vdd to a factored out function seems a bit too complex for that case to me. I think I'll leave it at the current state: show_input() does the caching, show_vdd() always reads from the chip. We might end up reading vdd twice within a second. Well, it shouldn't hurt that much. > > I hate this driver, it makes me look pretty stupid :/ > > Naah ;) Stupid developers are the ones who let me review their driver > code and then refuse to fix the problems I have found. As long as your > driver ends up upstream, you're doing the right thing! I am quite positive it will end upstream at the end; still, I'd like to have spared you from those obvious flaws. Can't be helped, I'll try harder next time and buy a couple of brown paper bags ;) > OK, thanks. Remember that you can also do preliminary testing using > i2c-stub + a dump of the chip. I haven't forgotten, just some effects of the configuration bits can't be tested with that method. And as I still have that board set up... Have a nice weekend! Wolfram -- Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ |
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
