| Message ID | 20200802163735.76617-1-ceggers@arri.de |
|---|---|
| Headers | show |
| Series | iio: light: Support AMS AS73211 digital XYZ sensor | expand |
On Sun, Aug 2, 2020 at 7:40 PM Christian Eggers <ceggers@arri.de> wrote: > > Support for AMS AS73211 JENCOLOR(R) Digital XYZ Sensor. > > This driver has no built-in trigger. In order for making triggered > measurements, an external (software) trigger driver like > iio-trig-hrtimer or iio-trig-sysfs is required. > > The sensor supports single and continuous measurement modes. The latter > is not used by design as this would require tight timing synchronization > between hardware and driver without much benefit. Thanks for an update, my comments below. > Datasheet: https://ams.com/documents/20143/36005/AS73211_DS000556_3-01.pdf/a65474c0-b302-c2fd-e30a-c98df87616df Do we need the UUID after the document file name? ... > +/* Available sample frequencies are 1.024MHz multiplied by powers of two. */ > +static const int as73211_samp_freq_avail[] = { > + AS73211_SAMPLE_FREQ_BASE * 1, > + AS73211_SAMPLE_FREQ_BASE * 2, > + AS73211_SAMPLE_FREQ_BASE * 4, > + AS73211_SAMPLE_FREQ_BASE * 8 + Comma. > +}; ... > +#define AS73211_OFFSET_TEMP (-66.9) > +#define AS73211_SCALE_TEMP 0.05 In the kernel we don't do float arithmetic. How these are being used? ... > + *val2 = (AS73211_OFFSET_TEMP - (int)AS73211_OFFSET_TEMP) * 1000000; > + *val2 = (AS73211_SCALE_TEMP - (int)AS73211_SCALE_TEMP) * 1000000; Magic 1000000 multiplier. I think here you got them always 0. And to fix that you need to redefine (with also units included in the name) above constants like #define ..._OFFSET_TEMP_mC 66500 ... _SCALE_TEMP_?? 50 Consider to use definitions from https://elixir.bootlin.com/linux/latest/source/include/linux/units.h ... > + }} > + > + return -EINVAL; Make it default case. > + } > + > + return -EINVAL; Ditto. ... > + }} > + > + return -EINVAL; Ditto. ... > + ret = devm_iio_device_register(dev, indio_dev); > + if (ret < 0) > + return ret; > + > + return 0; return devm_iio_device_register(); And consider to drop ' < 0' for devm_*() calls. As far as I understood your intention to explicitly leave them because of i2c_*() calls, though devm_*() and such are different.
On Sunday, 2 August 2020, 20:02:35 CEST, Andy Shevchenko wrote: > Thanks for an update, my comments below. Thanks for the review. Please see below for my questions. Best regards Christian > On Sun, Aug 2, 2020 at 7:40 PM Christian Eggers <ceggers@arri.de> wrote: > > Datasheet: > > https://ams.com/documents/20143/36005/AS73211_DS000556_3-01.pdf/a65474c0- > > b302-c2fd-e30a-c98df87616df > Do we need the UUID after the document file name? I have send AMS an inquiry. Not sure whether I will get an answer. I will wait a few days until sending v6. > > +#define AS73211_OFFSET_TEMP (-66.9) > > +#define AS73211_SCALE_TEMP 0.05 > > In the kernel we don't do float arithmetic. How these are being used? Does this restriction also apply for compile time constants? I am quite sure that all calculations using these defines will be evaluated at compile time. If found a number of other places where probably the same is done: find . -name '*.c' | xargs grep "#define.*[0-9]\.[0-9]" | grep -v '"' | grep -v "\/\*.*[0-9]\.[0-9]" > > + *val2 = (AS73211_OFFSET_TEMP - (int)AS73211_OFFSET_TEMP) * > > 1000000; > > > > + *val2 = (AS73211_SCALE_TEMP - > > (int)AS73211_SCALE_TEMP) * 1000000; > Magic 1000000 multiplier. I think that in the context of IIO_VAL_INT_PLUS_MICRO this isn't quite magic. Using 1000000 directly seems quite usual: find drivers/iio/ -type f | xargs grep "val2 = .*1000000" > I think here you got them always 0. And to fix that you need to > redefine (with also units included in the name) above constants like > #define ..._OFFSET_TEMP_mC 66500 > ... _SCALE_TEMP_?? 50 a scale factor has no unit > > Consider to use definitions from > https://elixir.bootlin.com/linux/latest/source/include/linux/units.h There are only definition for milli celsius. For IIO_VAL_INT_PLUS_MICRO I would require micro celsius. If I have the freedom, I would keep it as it is. Else I would suggest the following: #define AS73211_OFFSET_TEMP_INT (-66) #define AS73211_OFFSET_TEMP_MICRO 900000 #define AS73211_SCALE_TEMP_INT 0 #define AS73211_SCALE_TEMP_MICRO 50000 > > + }} > > + > > + return -EINVAL; > > Make it default case. changed. Is there any benefit? My IDE's syntax checker now complains "No return, in a function returning non-void". But gcc is happy with this. > > + ret = devm_iio_device_register(dev, indio_dev); > > + if (ret < 0) > > + return ret; > > + > > + return 0; > > return devm_iio_device_register(); changed. I prefer the original pattern as it would produce less changed lines if something needs to inserted later.
On Tue, Aug 4, 2020 at 10:42 AM Christian Eggers <ceggers@arri.de> wrote: > On Sunday, 2 August 2020, 20:02:35 CEST, Andy Shevchenko wrote: > > On Sun, Aug 2, 2020 at 7:40 PM Christian Eggers <ceggers@arri.de> wrote: ... > > > Datasheet: > > > https://ams.com/documents/20143/36005/AS73211_DS000556_3-01.pdf/a65474c0- > > > b302-c2fd-e30a-c98df87616df > > Do we need the UUID after the document file name? > I have send AMS an inquiry. Not sure whether I will get an answer. I will wait > a few days until sending v6. I have successfully opened a document w/o additional UUID at the end of URI. I think you may drop it. ... > > > +#define AS73211_OFFSET_TEMP (-66.9) > > > +#define AS73211_SCALE_TEMP 0.05 > > > > In the kernel we don't do float arithmetic. How these are being used? > Does this restriction also apply for compile time constants? I am quite > sure that all calculations using these defines will be evaluated at compile > time. If found a number of other places where probably the same is done: > > find . -name '*.c' | xargs grep "#define.*[0-9]\.[0-9]" | grep -v '"' | grep -v "\/\*.*[0-9]\.[0-9]" Side note: `git grep ...` is much faster and better. % git grep -n -w '#define[^"/]\+[0-9]\+\.[0-9]\+' -- drivers/ include/ arch/ | wc -l 47 + DRM, yes. In any case... > > > + *val2 = (AS73211_OFFSET_TEMP - (int)AS73211_OFFSET_TEMP) * > > > 1000000; > > > > > > + *val2 = (AS73211_SCALE_TEMP - > > > (int)AS73211_SCALE_TEMP) * 1000000; > > Magic 1000000 multiplier. > I think that in the context of IIO_VAL_INT_PLUS_MICRO this isn't quite magic. Using > 1000000 directly seems quite usual: > > find drivers/iio/ -type f | xargs grep "val2 = .*1000000" Hmm... Okay. > > I think here you got them always 0. And to fix that you need to > > redefine (with also units included in the name) above constants like > > #define ..._OFFSET_TEMP_mC 66500 > > ... _SCALE_TEMP_?? 50 > a scale factor has no unit > > > > > Consider to use definitions from > > https://elixir.bootlin.com/linux/latest/source/include/linux/units.h > There are only definition for milli celsius. For IIO_VAL_INT_PLUS_MICRO I would > require micro celsius. > > If I have the freedom, I would keep it as it is. Else I would suggest the following: > #define AS73211_OFFSET_TEMP_INT (-66) > #define AS73211_OFFSET_TEMP_MICRO 900000 > #define AS73211_SCALE_TEMP_INT 0 > #define AS73211_SCALE_TEMP_MICRO 50000 ...somewhat like above would be better. But your freedom is defined by maintainers (not by me), so wait for their comments. ... > > > + }} > > > + > > > + return -EINVAL; > > > > Make it default case. > changed. Is there any benefit? My IDE's syntax checker now complains > "No return, in a function returning non-void". But gcc is happy with this. Your IDE is buggy :-) Yes, there is a benefit of doing this, at some point compiler complains about switches that don't cover all cases. ... > > > + ret = devm_iio_device_register(dev, indio_dev); > > > + if (ret < 0) > > > + return ret; > > > + > > > + return 0; > > > > return devm_iio_device_register(); > changed. I prefer the original pattern as it would produce less changed lines > if something needs to inserted later. But if not, it will be a bulk of several lines of code which is the bait for all kinds of janitors and clean up scripts (I saw that IRL, so it's not unrealistic). In that case it will be twice the churn.
On 8/4/20 9:40 AM, Christian Eggers wrote: > On Sunday, 2 August 2020, 20:02:35 CEST, Andy Shevchenko wrote: >> Thanks for an update, my comments below. > Thanks for the review. Please see below for my questions. > > Best regards > Christian > >> On Sun, Aug 2, 2020 at 7:40 PM Christian Eggers <ceggers@arri.de> wrote: >>> Datasheet: >>> https://ams.com/documents/20143/36005/AS73211_DS000556_3-01.pdf/a65474c0- >>> b302-c2fd-e30a-c98df87616df >> Do we need the UUID after the document file name? > I have send AMS an inquiry. Not sure whether I will get an answer. I will wait > a few days until sending v6. > >>> +#define AS73211_OFFSET_TEMP (-66.9) >>> +#define AS73211_SCALE_TEMP 0.05 >> In the kernel we don't do float arithmetic. How these are being used? > Does this restriction also apply for compile time constants? I am quite > sure that all calculations using these defines will be evaluated at compile > time. If found a number of other places where probably the same is done: > > find . -name '*.c' | xargs grep "#define.*[0-9]\.[0-9]" | grep -v '"' | grep -v "\/\*.*[0-9]\.[0-9]" I believe it is implementation defined. The compiler is free to generate floating math and do the conversion at runtime. Although it is probably safe to assume that no reasonable compiler will do this for your code. If only we had constexpr in C, then there was a way to make it guaranteed that the conversion happens during compile time. But I agree with you, it would be nice to have a cleaner way of declaring fixed point numbers without having to pay attention to how many 0s you have to put after the least significant digit.