[OpenWrt-Devel] [PATCH] Add support for DHT11 driver
harald at ccbib.org
harald at ccbib.org
Sat Sep 27 03:12:52 EDT 2014
Sorry, accidentally droped the Mailinglist in my last message. Those
late to the party: See the fullquote below...
On Fri, 26 Sep 2014 23:58:03 +0200, Hartmut Knaack <knaack.h at gmx.de>
> harald at ccbib.org schrieb am 26.09.2014 22:33:
>> On Fri, 26 Sep 2014 21:03:07 +0200, Hartmut Knaack <knaack.h at gmx.de>
>>> harald at ccbib.org schrieb am 26.09.2014 12:46:
>>>> The DHT11 is a temperature and humidity sensor supported by linux
>>>> since 3.14.
>>>> This patch has been tested on recent mxs with kernel 3.14.18.
>>>> Signed-off-by: Harald Geyer <harald at ccbib.org>
>>> I would expect to make it also depend on device tree or architectures
>>> which support device tree. From what I remember, there are still
>>> architectures which have not yet been converted to devicetree. In
>>> cases, it would be confusing and useless to build this module. Or am I
>>> missing something? I don't have any practical experience with
>>> so far.
>> I did raise this point when submitting the driver for review and the
>> was: Don't bother. Anyway, the driver explicitely does not depend
>> on devicetree in the Kconfig file to allow for compile testing on those
>> non-devicetree architectures. - OTOH maybe OpenWrt cares more about end
>> user experience than kernel hackers do?
> That's weird, as there are some cases in IIO, where || COMPILE_TEST is
> added as dependency (at least I have seen this for platform specific
Yes, but it seems || COMPILE_TEST is considered a hack that is to be
avoided. The devicetree API is a noop on non-devicetree architectures
to get rid of || COMPILE_TEST.
> Anyway, while compiling the kernel still requires some advanced skills,
> OpenWRT should be heavily dedicated at end-users - so you need to make
> kind of idiot-proof. And not everyone able to solder will have the
> experience, as well. So, sooner or later I would expect people to come
> to the forum asking, how to deal with a custom device tree file, and
> someone has to explain that it won't work with their router, which
> the question, why the kernel module is built, if the router doesn't
> it. So, in my opinion, it would be best to make it depend on CONFIG_OF
> avoid any confusion.
Okay, I'll test and submit an updated patch.
>> If somebody want's to use this driver on an architecture without
>> I'm sure support for this will be added. OTOH depending on archtectures
>> which support devicetree would be a moving target and rather
>> It sure will be useless to build this module on some architectures, but
>> don't think it will be confusing: If somebody want's to attach the
>> to a gpio line they will obviously notice what they are missing.
>> So in conclusion I'd like to keep this as is but am willing to
>> if there is prior practise regarding devicetree to the contrary in
>> best regards,
>>>> package/kernel/linux/modules/other.mk | 20 ++++++++++++++++++++
>>>> 1 files changed, 20 insertions(+), 0 deletions(-)
>>>> diff --git a/package/kernel/linux/modules/other.mk
>>>> index d56bb50..bef24eb 100644
>>>> --- a/package/kernel/linux/modules/other.mk
>>>> +++ b/package/kernel/linux/modules/other.mk
>>>> @@ -258,6 +258,26 @@ endef
>>>> $(eval $(call KernelPackage,iio-ad799x))
>>>> +define KernelPackage/iio-dht11
>>>> + SUBMENU:=$(OTHER_MENU)
>>>> + DEPENDS:=kmod-iio-core @GPIO_SUPPORT
>>>> + TITLE:=DHT11 (and compatible) humidity and temperature sensors
>>>> + KCONFIG:= \
>>>> + CONFIG_DHT11
>>>> + FILES:=$(LINUX_DIR)/drivers/iio/humidity/dht11.ko
>>>> + AUTOLOAD:=$(call AutoLoad,56,dht11)
>>>> +define KernelPackage/iio-dht11/description
>>>> + support for DHT11 and DHT22 digitial humidity and temperature
>>>> + attached at GPIO lines. You will need a custom device tree file to
>>>> + specify the GPIO line to use.
>>>> +$(eval $(call KernelPackage,iio-dht11))
>>>> define KernelPackage/lp
>>>> TITLE:=Parallel port and line printer support
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel