From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 637D4F9; Fri, 1 Dec 2023 10:20:47 -0800 (PST) Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4ShhDz0xc5z689rj; Sat, 2 Dec 2023 02:20:19 +0800 (CST) Received: from lhrpeml500005.china.huawei.com (unknown [7.191.163.240]) by mail.maildlp.com (Postfix) with ESMTPS id 06FF8140B33; Sat, 2 Dec 2023 02:20:45 +0800 (CST) Received: from localhost (10.202.227.76) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 1 Dec 2023 18:20:44 +0000 Date: Fri, 1 Dec 2023 18:20:43 +0000 From: Jonathan Cameron To: Marek Vasut CC: "Dr.-Ing. Andre Werner" , , Andy Shevchenko , Matti Vaittinen , Alexander Stein , Bjorn Helgaas , Conor Dooley , Fabio Estevam , Guenter Roeck , Jonathan Cameron , Krzysztof Kozlowski , Lars-Peter Clausen , Luca Ceresoli , Mark Brown , Naresh Solanki , Patrick Rudolph , Rob Herring , Stefan Windfeldt-Prytz , Vincent Tremblay , Subject: Re: [PATCH v5 2/2] iio: light: isl76682: Add ISL76682 driver Message-ID: <20231201182043.000043a3@Huawei.com> In-Reply-To: <124ca1d8-5569-4c6c-8019-24e58dd8a5fc@denx.de> References: <20231125222738.97875-1-marex@denx.de> <20231125222738.97875-2-marex@denx.de> <907048010.848203.1701027206602.JavaMail.zimbra@systec-electronic.com> <124ca1d8-5569-4c6c-8019-24e58dd8a5fc@denx.de> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: lhrpeml100003.china.huawei.com (7.191.160.210) To lhrpeml500005.china.huawei.com (7.191.163.240) On Sun, 26 Nov 2023 23:17:55 +0100 Marek Vasut wrote: > On 11/26/23 20:33, Dr.-Ing. Andre Werner wrote: > > [...] > > > +static int isl76682_write_raw(struct iio_dev *indio_dev, > > + struct iio_chan_spec const *chan, > > + int val, int val2, long mask) > > +{ > > + struct isl76682_chip *chip = iio_priv(indio_dev); > > + int i; > > + > > + if (chan->type != IIO_LIGHT && chan->type != IIO_INTENSITY) > > + return -EINVAL; > > > > In my understanding, this is not necessary as you use that 'iio_chan_spec' to specify > > the channels available at all. So there will be no other channel types created by the IIO environment, I think. > > That's a good point, I think we can drop it in this case and the next one. > > Jonathan , is there any reason you can think of why this shouldn't be > dropped ? I don't mind a little paranoia, but fine with dropping it as well. The reason paranoia is fine is that if other channels are added in future we might not remember to fix this up if they happen to have no writeable attributes. I leave that assessment up to driver authors. Jonathan > > I'll add it into V6, thanks. >