On Wed, 2 Oct 2024 05:49:15 +0300 Tudor Gheorghiu <tudor.reda@xxxxxxxxx> wrote: > On Wed, Oct 02, 2024 at 12:54:26AM +0200, Nam Cao wrote: > > > > You probably want to elaborate what you mean by "their naming choice" (i.e. > > how does the naming choice causes this false warning?) > > > > I got curious and digged into checkpatch.pl. This script expects macros > > whose names match "IIO_DEV_ATTR_[A-Z_]+" to have the first integer argument > > to be octal. And this driver defines macros which "luckily" match that > > pattern. > > > > There is only IIO_DEV_ATTR_SAMP_FREQ which matches the pattern, and accepts > > umode_t as its first argument. > > > > Instead of changing code just to make checkpatch.pl happy, perhaps it's > > better to fix the checkpatch script? Maybe something like the untested > > patch below? > > > > Or since checkpatch is wrong, maybe just ignore it. > > > > Best regards, > > Nam > > > > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl > > index 4427572b2477..2fb4549fede2 100755 > > --- a/scripts/checkpatch.pl > > +++ b/scripts/checkpatch.pl > > @@ -817,7 +817,7 @@ our @mode_permission_funcs = ( > > ["debugfs_create_(?:file|u8|u16|u32|u64|x8|x16|x32|x64|size_t|atomic_t|bool|blob|regset32|u32_array)", 2], > > ["proc_create(?:_data|)", 2], > > ["(?:CLASS|DEVICE|SENSOR|SENSOR_DEVICE|IIO_DEVICE)_ATTR", 2], > > - ["IIO_DEV_ATTR_[A-Z_]+", 1], > > + ["IIO_DEV_ATTR_SAMP_FREQ", 1], > > ["SENSOR_(?:DEVICE_|)ATTR_2", 2], > > ["SENSOR_TEMPLATE(?:_2|)", 3], > > ["__ATTR", 2], > > Hi! > > Yes, this is exactly what I discovered while inspecting checkpatch > myself, however it did not occur to me this could be a problem with > checkpatch. But looking deeper, it seems like it is: > > IIO_DEV_ATTR_SAMP_FREQ is defined in include/linux/iio/sysfs.h, along > with other helper macros: > > > /** > > * IIO_DEV_ATTR_SAMP_FREQ - sets any internal clock frequency > > * @_mode: sysfs file mode/permissions > > * @_show: output method for the attribute > > * @_store: input method for the attribute > > **/ > > #define IIO_DEV_ATTR_SAMP_FREQ(_mode, _show, _store) \ > > IIO_DEVICE_ATTR(sampling_frequency, _mode, _show, _store, 0) > > > > /** > > * IIO_DEV_ATTR_SAMP_FREQ_AVAIL - list available sampling frequencies > > * @_show: output method for the attribute > > * > > * May be mode dependent on some devices > > **/ > > #define IIO_DEV_ATTR_SAMP_FREQ_AVAIL(_show) \ > > IIO_DEVICE_ATTR(sampling_frequency_available, S_IRUGO, _show, NULL, 0) > > /** > > * IIO_DEV_ATTR_INT_TIME_AVAIL - list available integration times > > * @_show: output method for the attribute > > **/ > > #define IIO_DEV_ATTR_INT_TIME_AVAIL(_show) \ > > IIO_DEVICE_ATTR(integration_time_available, S_IRUGO, _show, NULL, 0) > > > > #define IIO_DEV_ATTR_TEMP_RAW(_show) \ > > IIO_DEVICE_ATTR(in_temp_raw, S_IRUGO, _show, NULL, 0) > > The checkpatch script will match all these macros, even if > IIO_DEV_ATTR_SAMP_FREQ is the only one where we need to check for octal > literal arguments. I grep'd through the entire sourcecode, and the only > false positives with literal decimal arguments which match "IIO_DEV_ATTR_[A-Z_]+" > are inside this driver. > > I accidentally discovered this issue by running > checkpatch on the said driver files. > > I will submit a patch to the checkpatch maintainers with this thread > linked, and if they agree this is a bug and accept the patch, > this driver patch will no longer be needed, since checkpatch will no longer flag > these macros as false positives. > > Do I have your permission to add your name and email to Suggested-by? Hmm. If you really want to clean this up, then these macros shouldn't exist at all. They are legacy of ancient IIO code style and some slightly ropey code even then (which is why it's in staging!) Right option is to use the read_raw callbacks in conjunction with the info_mask_* bitmaps that indicate which attributes the IIO core should create. There are some corners in here such as PHASESYMBOL for which we've never fixed on an ABI and that might need custom attributes, but even then these macros probably wouldn't be involved. So I'd don't mind 'fixing' checkpatch or the code, but I'd rather we fixed the drivers up properly. However I would also like someone from ADI to input on whether they plan to clean these up in future? Or is this something you'd support someone else doing? I quickly checked one of them and the ad9832 is still a production part so they may be interest in a clean upstream driver. +CC Nuno to chase that question down. This is the ad9832 and ad9834 DDS chips. ADI are doing a good job at bringing out of tree code in at the moment, but it would also be good to finally tidy up the remaining stuff in staging (or dump it once and for all!) Jonathan > > Thanks! > Tudor
