On Mon, 14 Oct 2024 16:14:27 +0300 Andy Shevchenko <andy@xxxxxxxxxx> wrote: > On Mon, Oct 14, 2024 at 12:40:40PM +0300, Antoniu Miclaus wrote: > > Add support for the AD485X a fully buffered, 8-channel simultaneous > > sampling, 16/20-bit, 1 MSPS data acquisition system (DAS) with > > differential, wide common-mode range inputs. > > ... > > > +config AD4851 > > + tristate "Analog Device AD4851 DAS Driver" > > + depends on SPI > > + select REGMAP_SPI > > + select IIO_BACKEND > > + help > > + Say yes here to build support for Analog Devices AD4851, AD4852, > > + AD4853, AD4854, AD4855, AD4856, AD4857, AD4858, AD4858I high speed > > + data acquisition system (DAS). > > I think I already commented on this... Anyway, it's much better to support when > this list is broke down on per device per line. In such a case it's less churn > if we need to remove or add an entry in the future. > > > + To compile this driver as a module, choose M here: the module will be > > + called ad4851. > > Also, with all these devices to be supported why not ad485x as the name of > the driver? Is it a preference by the IIO subsystem? Don't. We've been bitten by too many cases of manufacturers noticing a hole in their part numbers and 'slotting' something unrelated in. So it just causes confusion. Hence strong preference for any new code is pick a name from the list. The wild card also implies restrictions that tend to break overtime when other part numbers outside the range are used. Not using a wildcard keeps it consistently wrong so people get used to it :) > > ... > > > +#include <asm/unaligned.h> > > linux/unaligned nowadays (I learnt it quite recently). > (It requires v6.12-rc2). Yup. That bit me in the IIO tree 3 times so far. I've merged rc2 in for that reason.
