Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp3341871pxb; Mon, 18 Oct 2021 13:10:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzP6GoXu3jmhGdvGP8Oht+aFJ3l3DMmqoQ91hgakqezaXOgqZHUwfB7yLg12P5OHZcw5Fkc X-Received: by 2002:a63:1266:: with SMTP id 38mr25317242pgs.219.1634587842181; Mon, 18 Oct 2021 13:10:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634587842; cv=none; d=google.com; s=arc-20160816; b=iq9FAsiEoMQm13miiK/rG+FkvMvNw8Jx/Hii3iL4m/67loEjt0l6YyavsnkoNfihA6 mJW4vPG/5+PSES0EgfZv/6sjObeIBD13Stfj8FbdZQ2crCuDmyka5kFMqnN87JtM4uBI ktBQkkdOaKj19cl7+9RF5egwZzJzLuqlIGmvBQAnWqNIZh7h6PQX+p1fx0C0QwH1cwSH izXy0X7TubLa0B783quKJBeUfQjK+0Q/Cve21QrqXcdn/ZmySm9Mi7qtz+F0OWP78RX8 JxDuUBwyBsRuB4GJoHe4Ug7xE5Rstgys3A8kYLShKNNX0/59WrptxFNnbLKCLiqEX3OY P+vg== 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=gKTTpE8p+WiaFyUF/aGj8mgAscaXupISWQ2aMgExe3k=; b=rxOoBtptXzIKylfOgM5s0GhL4KBwDEtqeF34+AWTsJxUadjkymSIFfwgtZUpEyCRBd OmdUrRmj2ipCh1Y+492syLLHNMFbOu8lQKIbtfjLq0Np04rmzPkIEbVYBGPXVg2YYYrp aSjA+BA1ohNqhUs9OGYdTCz00LrUbuPSgJVxFVg+obYjakl3PQPf3mWFjN+suKfY9/kD YpZxe/b6U4wrCHIa6mGGm/AGM0Sku5uFzfnwkGN9Z8Sa+2UtD8JVs7IeiHTaEdzZE/U4 T9lCjvxtzPV8xmgJ+by6y+X3qPrJmyN1pD0cH4M2eHkE1cZC+D8rOOZMAOI0HziyWwsH APGA== 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 mw15si758618pjb.180.2021.10.18.13.10.29; Mon, 18 Oct 2021 13:10:42 -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 S233600AbhJRULZ (ORCPT + 99 others); Mon, 18 Oct 2021 16:11:25 -0400 Received: from mail.kernel.org ([198.145.29.99]:44544 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229941AbhJRULZ (ORCPT ); Mon, 18 Oct 2021 16:11:25 -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 D22AE611EF; Mon, 18 Oct 2021 20:09:11 +0000 (UTC) Date: Mon, 18 Oct 2021 21:13:26 +0100 From: Jonathan Cameron To: Peter Rosin Cc: Vincent Whitchurch , devicetree@vger.kernel.org, kernel@axis.com, lars@metafoo.de, linux-iio@vger.kernel.org, robh+dt@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 0/3] Add settle time support to iio-mux Message-ID: <20211018211326.7148b03e@jic23-huawei> In-Reply-To: <5f3b6dd9-b90c-9e54-1772-56a79cc8c1cc@axentia.se> References: <20211007134641.13417-1-vincent.whitchurch@axis.com> <7c14fabc-8811-5875-15a0-67884e2da78d@axentia.se> <20211017183108.1797d416@jic23-huawei> <5f3b6dd9-b90c-9e54-1772-56a79cc8c1cc@axentia.se> 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 Sun, 17 Oct 2021 23:08:06 +0200 Peter Rosin wrote: > On 2021-10-17 19:31, Jonathan Cameron wrote: > > On Sat, 9 Oct 2021 01:09:56 +0200 > > Peter Rosin wrote: > > > >> Hi Vincent! > >> > >> On 2021-10-07 15:46, Vincent Whitchurch wrote: > >>> On one of our boards we use gpio-mux with iio-mux to read voltages using an ADC > >>> from a few different channels, and on this board the input voltage needs some > >>> time to stabilize after a switch of the mux. > >>> > >>> This series add devicetree and driver support for this kind of hardware which > >>> requries a settle time after muxing. > >>> > >>> v1 -> v2: > >>> - Move property support to iio-mux and delay handling to mux core as suggested > >>> by Peter. > >>> > >>> v1: https://lore.kernel.org/all/20211004153640.20650-1-vincent.whitchurch@axis.com/ > >>> > >>> Vincent Whitchurch (3): > >>> mux: add support for delay after muxing > >>> dt-bindings: iio: io-channel-mux: Add property for settle time > >>> iio: multiplexer: iio-mux: Support settle-time-us property > >>> > >>> .../iio/multiplexer/io-channel-mux.yaml | 5 +++ > >>> drivers/iio/multiplexer/iio-mux.c | 7 +++- > >>> drivers/mux/core.c | 36 ++++++++++++++++--- > >>> include/linux/mux/consumer.h | 23 +++++++++--- > >>> include/linux/mux/driver.h | 4 +++ > >>> 5 files changed, 65 insertions(+), 10 deletions(-) > >>> > >> > >> This looks really nice, thank you! The only question I see is if it should > >> go via my (virtually unused) mux tree or via the iio tree. Yes, the meat is > >> in mux/core.c, but I'm happy to just ack these patches and have Jonathan > >> handle them. But, I'm also fine with handling it in the mux tree (but I'm > >> getting old and forgetful, and it's been so many moons that I need to > >> re-learn the steps). > >> > >> Jonathan, you or me? If you, you can add: > >> > >> Acked-by: Peter Rosin > > > > I don't really mind, but the 4/3 and 5/3 have broken my b4 based flow + Rob > > hasn't yet given an Ack on those two, so I'll not pick any of them up just yet. > > I can sort out the two oddly numbered patches if Rob is happy, though they'll > > probably not have the nice link tags that b4 automates. > > > > Note Rob didn't actually say he was happy with patch 2 yet as far as I can tell. > > Getting Rob's ack on 2/3 is of course a prerequisite to 1/3 and 3/3. Given Rob has now given that, I'll queue these 3 patches up. Applied to the iio-togreg branch of iio.git and pushed out as testing for 0-day to poke at. > > Just ignore 4/3 and 5/3 if they are holding things back or are making things > difficult in any way. I'll resend them later if need be, as they really have > very little to do with this series. > > With hindsight I should probably have sent them as a fresh series, and I can > re-post them as such immediately if that helps? But then again, maybe that > just muddies the water even further... Let's deal with those two separately. I can pick them off list if Rob is happy with those two. The dt bindings patchwork has them as needing review so I'm sure they'll get it shortly. Thanks, Jonathan > > Cheers, > Peter