linux-kernel - using one gpio for multiple dht22 sensors

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 13 Oct 2020 23:34:31 +0200
From:   Rasmus Villemoes <linux@...musvillemoes.dk>
To:     Peter Rosin <peda@...ntia.se>
Cc:     LKML <linux-kernel@...r.kernel.org>
Subject: using one gpio for multiple dht22 sensors

Hi Peter

Since you're the author of io-channel-mux.txt, gpio-mux.txt and
mux-controller.txt, I hope you don't mind me asking some perhaps silly
questions.

I'm going to hook up a bunch of dht22 humidity (and temperature) sensors
[1] (drivers/iio/humidity/dht11.c), but partly due to limited number of
available gpios, I'm also going to use a 74hc4051 multiplexer [2], so
that all the dht22's actually sit on the same gpio.

It's pretty obvious how the multiplexer is to be described in
device-tree (I'm probably going to send a patch to add support for an
optional "enable-gpio", as on the 74hc4051, so that MUX_IDLE_DISCONNECT
gets supported).

It also seems like io-channel-mux should somehow magically apply to all
kinds of iio devices, but it can't be that simple. And if it is, I can't
figure out how to write the DT. So:

- do I need to teach the dht11.c driver to be mux-aware?
- currently, a dht11/dht22 shows up in sysfs with just two files,
in_humidityrelative_input and in_temp_input. Now, should I end up with
one device and, say, 2*8 files (so that it seems like one sensor with
eight input channels), or should it show up as eight different devices?
If the latter, I guess the device tree would end up with the same "gpios
= " spec for all eight - is that even allowed?

If you can show how the DT is supposed to describe this situation, I'll
try to fill out the missing pieces on the driver side.

[I could also just not describe the multiplexer at all and control
everything about it by toggling gpios from userspace, and just have a
single dht22 in DT, but I prefer doing this "the right way" if it's
feasible.]

Thanks,
Rasmus

Just FTR:

[1]
https://www.electroschematics.com/wp-content/uploads/2015/02/DHT22-datasheet.pdf
[2] https://assets.nexperia.com/documents/data-sheet/74HC_HCT4051.pdf