Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2681427yba; Mon, 6 May 2019 09:53:54 -0700 (PDT) X-Google-Smtp-Source: APXvYqzzoPyBtmApdL/3uOfaQ/7lu6Jy9Y1dWu0rO5vWdRH2vKlTaHEYZuz0F/6LESyEV5gr4i4L X-Received: by 2002:a65:44c8:: with SMTP id g8mr8070400pgs.443.1557161634739; Mon, 06 May 2019 09:53:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557161634; cv=none; d=google.com; s=arc-20160816; b=Z66oIOQLRfMX9VCw3PfPlwIN/lKophckqvNl5RFtd3U17OsL2Z8n2Si15DL02oa/Yh il5IC8/F9FglI5IucZhOQGVpc2K382WmS9VratdsGTgylXuzClZGNYeK0wEiOjmqWGKm WxLSHtf7IJbYf7V6GrvvL4PfsGAXZHPbP7U+YFsvQjCcseEnFY45aozXz3McbjcbJJPD i5FiwfShp6PG6WBi1pgAndU70FrmV7Lw5Ze3kls2sg+lgN14tGpf/k1HRjQeTMI6O9pj P6seWtb73hN3VZp14KjE07u0MTIn3ccpJizLkWuKhpsb/zUwF7fDJqImQg63cLVLfkfa kXFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:date:cc:to:from:subject :message-id; bh=6zbqZJB90ddpsNbbE0BDfnJrUQb7v9I3MYOYsS+JRVM=; b=APPo2RojhvPppvfh+nU+nf2HcIjb9e3PYQwm7PYIcmJlprrUSEVE5I0yxYtM6g4ryo pjBokY/JpdziJ91YUiViLnjC+wwnU1lvG1N0CsxRD8x1/g9jUCM4chS1JVMR8VZDzDFD XNtnpUIWJB1zSS/ojLDdWVs/OEQoTJblYP1gJRun38LGqLjDTo7W/KLju5M761PSZ+br 733YVvoRpzx8WymMjRzZuL9QvmveaK2ofJ7Tk5ehV2g2uA2+CDr8cO63zDyJbnv1Gdln uurfZ6D75MatJbPd/vT6yFV9cIy1aZC/HIXlKM5UKcf49ft9F5JiLZSHIIxF9XT6+3ic 5amQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d6si14365168pgv.583.2019.05.06.09.53.38; Mon, 06 May 2019 09:53:54 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726541AbfEFQwi (ORCPT + 99 others); Mon, 6 May 2019 12:52:38 -0400 Received: from hermes.aosc.io ([199.195.250.187]:48555 "EHLO hermes.aosc.io" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726321AbfEFQwi (ORCPT ); Mon, 6 May 2019 12:52:38 -0400 Received: from localhost (localhost [127.0.0.1]) (Authenticated sender: icenowy@aosc.io) by hermes.aosc.io (Postfix) with ESMTPSA id 572BE6DA6E; Mon, 6 May 2019 16:52:30 +0000 (UTC) Message-ID: <282ccf0979e6c58effd0e177917bdf824c32f64e.camel@aosc.io> Subject: Re: [PATCH 1/7] iio: adc: sun4i-gpadc: rework for support multiple thermal sensor From: Icenowy Zheng To: Maxime Ripard , Jonathan Cameron Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, lars@metafoo.de, Yangtao Li , linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org, wens@csie.org, robh+dt@kernel.org, pmeerw@pmeerw.net, knaack.h@gmx.de, lee.jones@linaro.org, linux-arm-kernel@lists.infradead.org Date: Tue, 07 May 2019 00:52:22 +0800 In-Reply-To: <20190506122807.4u323iys74jddcet@flea> References: <20190503072813.2719-1-tiny.windzz@gmail.com> <20190503072813.2719-2-tiny.windzz@gmail.com> <20190505162215.3594f77d@archlinux> <20190506122807.4u323iys74jddcet@flea> Organization: Anthon Open-Source Community Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2019-05-06一的 14:28 +0200,Maxime Ripard写道: > Hi, > > On Sun, May 05, 2019 at 04:22:15PM +0100, Jonathan Cameron wrote: > > On Fri, 3 May 2019 03:28:07 -0400 > > Yangtao Li wrote: > > > > > For some SOCs, there are more than one thermal sensor, and there > > > are > > > currently four sensors on the A80. So we need to do some work in > > > order > > > to support multiple thermal sensors: > > > > > > 1) add sensor_count in gpadc_data. > > > 2) introduce sun4i_sensor_tzd in sun4i_gpadc_iio, to support > > > multiple > > > thermal_zone_device and distinguish between different > > > sensors. > > > 3) modify read temperature and initialization function. > > > > This comment doesn't mention the devm change. If it had it would > > have > > raised immediate alarm bells. > > > > I'm also not keen on the web of pointers that this driver is > > steadily > > evolving. I can't immediately see how to reduce that complexity > > however. > > So I might be responsible for that, and looking back, this has been a > mistake. > > This driver was initally put together to support a controller found > in > older (A10 up to A31) Allwinner SoCs. This controller had an ADC > driver that could be operated as a touchscreen controller, and was > providing a CPU temperature sensor and a general purpose ADC. > > However, we already had a driver for that controller in drivers/input > to report the CPU temperature, and the one in IIO was introduced to > support the general purpose ADC (and the CPU temperature). The long > term goal was to add the touchscreen feature as well eventually so > that we could remove the one in drivers/input. That didn't happen. > > At the same time, the Allwinner hardware slowly evolved to remove the > touchscreen and ADC features, and only keep the CPU temperature > readout. It then evolved further on to support multiple temperatures > (for different clusters, the GPU, and so on). > > So, today, we're in a situation where I was pushing everything into > that IIO drivers since there was similiraties between all the > generations, but the fact that we have to support so many odd cases > (DT bindings compatibility, controllers with and without ADC, etc) > that it becomes a real mess. > > And that mess isn't really used by anybody, since we want to have the > touchscreen. > > There's only one SoC that is supported only by that driver, which is > the A33 that only had a CPU temperature readout, and is still pretty > similar to the latest SoC from Allwinner (that is supported by this > series). > > I guess, for everyone's sanity and in order to not stall this > further, > it would just be better to create an hwmon driver for the A33 (and > onwards, including the H6) for the SoC that just have the temperature > readout feature. And for the older SoC, we just keep the older driver > under input/. Once the A33 is supported, we'll remove the driver in > IIO (and the related bits in drivers/mfd). I think a thermal driver is better. Other SoCs' thermal sensor drivers are all thermal drivers. > > Armbian already has a driver for that they never upstreamed iirc, so > it might be a good starting point, and we would add the support for > the H6. How does that sound? I think the developer abandoned to upstream it because of the previous problem ;-) Maybe it can be taken and add A33&H6 support. > > Sorry for wasting everybody's time on this. > > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel