Re: [PATCH v2 4/4] iio: light: add support for veml6031x00 ALS series

[Jonathan Cameron]

On Wed, 13 May 2026 19:56:54 +0300
Andy Shevchenko <andriy.shevchenko@xxxxxxxxx> wrote:

> On Wed, May 13, 2026 at 05:49:44PM +1300, Javier Carrasco wrote:
> > These sensors provide two light channels (ALS and IR), I2C communication
> > and a multiplexed interrupt line to signal data ready and configurable
> > threshold alarms.  
> 
> Can you split this to two or more patches:
> - basic functionality
> - feature 1 (exempli gratia, IR)
> - feature 2 (exempli gratia, multiplexed interrupt)
> - ...
> 
> ?
> 
> But let's wait for Sashiko if it swallows this big slice of the pie
> and not choke on it.
> 
> ...
> 
> > +	{
> > +		.compatible = "vishay,veml6031x01",
> > +		.data = &veml6031x01_chip,
> > +	},
> > +	{
> > +		.compatible = "vishay,veml60311x00",
> > +		.data = &veml60311x00_chip,
> > +	},
> > +	{
> > +		.compatible = "vishay,veml60311x01",
> > +		.data = &veml60311x01_chip,
> > +	},  
> 
> Oh, is 'x' is a real letter in the part number or a wildcard? If the latter,
> please avoid. Choose the base part number instead.
> 
FWIW I wondered this before. It's an actual x not a wildcard.

> ...
> 
> > +static const struct i2c_device_id veml6031x00_id[] = {
> > +	{ "veml6031x00", (kernel_ulong_t)&veml6031x00_chip },
> > +	{ "veml6031x01", (kernel_ulong_t)&veml6031x01_chip },
> > +	{ "veml60311x00", (kernel_ulong_t)&veml60311x00_chip },
> > +	{ "veml60311x01", (kernel_ulong_t)&veml60311x01_chip },
> > +	{ }
> > +};  
> 
> Perhaps use C99 initialisers, as there is an activity to change all drivers to
> follow that. Jonathan, btw, what do you think we should do in the light of Uwe's
> approach? Require C99 initialisers in new code, or something else?

Require them for device_id tables so that Uwe doesn't fight a loosing battle for ever!

>