| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <622f5382-10c9-4bd5-84ab-544d7c16f1fe@gmail.com> Date: Mon, 8 Jul 2024 15:43:29 +0300 From: Matti Vaittinen <mazziesaccount@...il.com> To: Jonathan Cameron <jic23@...nel.org> Cc: Matti Vaittinen <matti.vaittinen@...rohmeurope.com>, Lars-Peter Clausen <lars@...afoo.de>, Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, linux-iio@...r.kernel.org, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH v2 1/7] dt-bindings: iio: BU27034 => BU27034ANUC On 7/7/24 16:05, Jonathan Cameron wrote: > On Fri, 5 Jul 2024 13:54:12 +0300 > Matti Vaittinen <mazziesaccount@...il.com> wrote: > >> The BU27034NUC was cancelled before it entered mass production. It was >> replaced by a new variant BU27034ANUC (note, added 'A'). The new >> variant gained a few significant changes, like removal of the 3.rd data >> channel and dropping some of the gain settings. This means that, from >> software point of view these ICs are incompatible. Lux calculation based >> on the data from the sensors needs to be done differently, and on the >> BU27034ANUC the channel 3 data is missing. Also, the gain setting >> differencies matter. >> >> Unfortunately, the identification register was not changed so there is no >> safe way for the software to distinguish the variants. >> >> According to the ROHM HQ engineers, the old BU27034NUC should not be >> encountered in the wild. Hence it makes sense to remove the support for >> the old BU27034NUC and add support for the new BU27034ANUC. Change the >> compatible in order to not load the incompatible old driver for new sensor >> (or, if someone had the old sensor, the new driver for it). >> >> Drop the compatible for old sensor which should not be in the wild and >> add a new compatible for the new model with accurate model suffix >> 'anuc'. >> >> Signed-off-by: Matti Vaittinen <mazziesaccount@...il.com> > Rename indeed makes sense. One minor, 'whilst you are here' comment inline. > >> >> --- >> A patch renaming the file according to the new compatible will follow. >> If renaming is not needed or appropriate, that patch can be dropped. >> >> Revision history: >> v2: New patch >> --- >> .../devicetree/bindings/iio/light/rohm,bu27034.yaml | 9 ++++----- >> 1 file changed, 4 insertions(+), 5 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/iio/light/rohm,bu27034.yaml b/Documentation/devicetree/bindings/iio/light/rohm,bu27034.yaml >> index 30a109a1bf3b..535bd18348ac 100644 >> --- a/Documentation/devicetree/bindings/iio/light/rohm,bu27034.yaml >> +++ b/Documentation/devicetree/bindings/iio/light/rohm,bu27034.yaml >> @@ -4,20 +4,19 @@ >> $id: http://devicetree.org/schemas/iio/light/rohm,bu27034.yaml# >> $schema: http://devicetree.org/meta-schemas/core.yaml# >> >> -title: ROHM BU27034 ambient light sensor >> +title: ROHM BU27034ANUC ambient light sensor >> >> maintainers: >> - Matti Vaittinen <mazziesaccount@...il.com> >> >> description: | >> - ROHM BU27034 is an ambient light sesnor with 3 channels and 3 photo diodes >> + ROHM BU27034ANUC is an ambient light sesnor with 2 channels and 2 photo diodes > > sensor Thanks Jonathan! I won't re-spin this unless you ask me to because you wrote you can fix it whilist applying... Please, let me know if you wish me to fix and re-spin :) -- Matti Vaittinen Linux kernel developer at ROHM Semiconductors Oulu Finland ~~ When things go utterly wrong vim users can always type :help! ~~
Powered by blists - more mailing lists