On Mon, Oct 14, 2024 at 08:15:15PM +0100, Jonathan Cameron wrote: > 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: ... > > > +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 :) I see your point! But shouldn't we have a formal criteria for choosing that one from the list? I would go with "most featured device" as it may be aligned with all enabled features that otherwise would be questionable / confusing for the chips that do not support them or support in a limited manner. -- With Best Regards, Andy Shevchenko
