Received: by 2002:a05:6a10:c7c6:0:0:0:0 with SMTP id h6csp279709pxy; Sat, 31 Jul 2021 07:09:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJynz5Qpe5BkmOauMqEt5PQeaWT85JQznNtltxZ4V5ndHHDQINFvjCqHdWVsC9q8bWxOJGVk X-Received: by 2002:aa7:cc83:: with SMTP id p3mr9394635edt.365.1627740540804; Sat, 31 Jul 2021 07:09:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627740540; cv=none; d=google.com; s=arc-20160816; b=eAQRtzsAlEufeQu3ohBY17c+T2jBQfi+3HZ8crv7t4RlW+CcTiKpwkcQGBNaPyL2tK M1nsFEUB6Yl/C+CT14q0CORnYOopnfw8y48xqo9RoNq0YQLSLW3aYPSa9H2IwzggbXGA vVg3gK7LIJ4nxcY0v7PVCkyh+qfuLUOOMzNPXtf+DnrGi7htvIgX800VAOW2FYKOrZvR PrFS9iKra6qZ0Qx9j/sNIUOageN69Ty7LFanXEOONmV4VtPZKgGr6CwYwZQ9jSYlSceP xpS3aRLTAnb7I2l1Zj8xIQCzmsOSQ9Q+meN82nLnbnMKFzldv8CgST53RwkX5fkP5sFf sqGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=aGt4vB9yK1FQWAuoUXmXB1pQpTN0pKifVAZlG0Zez08=; b=Ty97TBML71celzicoPIMUrQZHTG8yNd3XhKRgYYCEK2lGpe4D4j2tIjmSzsB4CD5Bz rPDv7JFssKZDqmSakSa/5q6oUYKUD9ET8Ju0Xg4KMc/BKnFBQqAuTnVBHZO82f/KP51J 9CviN4Gtni5eNidqcjAjiOgOPP7PkcM0tFx970c6d5tT6dcuDnM4agLM2llg5uTEWmjs HY20uracPqCO+I3gjCKF84H0dUHw17Z6ReCYmNlWvz4spQpNK2sUetpKZOI2/Nk8ko3k xCq+esyeiHBJdSWUYInxFWsLltzFE//tA6KfP2mFURyBLiiWIM/PKP0M7D1LNHlWxGSw 54ew== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id de56si4693492ejc.111.2021.07.31.07.08.15; Sat, 31 Jul 2021 07:09:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233061AbhGaOGz (ORCPT + 99 others); Sat, 31 Jul 2021 10:06:55 -0400 Received: from mail.kernel.org ([198.145.29.99]:54432 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232752AbhGaOGy (ORCPT ); Sat, 31 Jul 2021 10:06:54 -0400 Received: from jic23-huawei (cpc108967-cmbg20-2-0-cust86.5-4.cable.virginm.net [81.101.6.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7409860E94; Sat, 31 Jul 2021 14:06:47 +0000 (UTC) Date: Sat, 31 Jul 2021 15:09:26 +0100 From: Jonathan Cameron To: Cc: , Subject: Re: [PATCH 0/3] iio: adc: Fix flags in sigma-delta drivers Message-ID: <20210731150926.42a2da31@jic23-huawei> In-Reply-To: <20210729084731.79135-1-alexandru.tachici@analog.com> References: <20210729084731.79135-1-alexandru.tachici@analog.com> X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 29 Jul 2021 11:47:28 +0300 wrote: > From: Alexandru Tachici > > Some sigma-delta drivers use wrong irq_flags specified in the > ad_sigma_delta_info struct. Add the flags corresponding to the > interrupt type specified in the data-sheets of each chip. > The complexity here is that we normally now leave this to the firmware description of the interrupt. The reason for that is people have an annoying habit of building boards where there is an inverter used as a cheap level converter on the interrupt line. It an also be somewhat 'fun' to identify from a datasheet if the signal is actually an edge interrupt or a level interrupt and in the case of devices that don't have any autonomous triggering (i.e. won't grab new data unless you tell the to) the difference is irrelevant. Take the ad7780 for example. It has an interrupt that remains low unless a) The data is read - normal case I'd imagine b) New data capture occurs (slowly at 10Hz) So we aren't dealing with a short pulse, or a situation where we have an interrupt that will stay set after the data is read (both of which would make this definitely an edge interrupt to avoid possibility of either missing or double triggering). Hence whilst it will work as an edge interrupt, it will also work fine with the existing level interrupt and in some ways level is more appropriate as the interrupt will remain set if you don't read it (for a while anyway and after that it's not safe to read). For extra fun / background for anyone else reading this thread, this interrupt line is also the data out line, so we absolutely 'must' keep the interrupt disabled until we are done with the read out, but that's handled in the ad_sigma_delta core. Conclusion, I'm not sure these are actually wrong, and if we were doing this today we wouldn't have them anyway... So have we seen any problems with current code? Jonathan > Alexandru Tachici (3): > iio: adc: ad7192: Fix IRQ flag > iio: adc: ad7780: Fix IRQ flag > iio: adc: ad7923: Fix IRQ flag > > drivers/iio/adc/ad7192.c | 1 + > drivers/iio/adc/ad7780.c | 2 +- > drivers/iio/adc/ad7793.c | 2 +- > 3 files changed, 3 insertions(+), 2 deletions(-) > > -- > 2.25.1