Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2885600imu; Mon, 17 Dec 2018 09:21:56 -0800 (PST) X-Google-Smtp-Source: AFSGD/XdwfrjDTr/OnfHftDgu1Gh6TzVPtD0ZYN8etRDgW2IsmApYo2XB6PLQ6HklMNIhcmwFdj6 X-Received: by 2002:a62:13c3:: with SMTP id 64mr13497478pft.93.1545067316430; Mon, 17 Dec 2018 09:21:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1545067316; cv=none; d=google.com; s=arc-20160816; b=ggux/iDZrKnx0PJ88sFkaNrSbtcC5efIEznL+OBD52Y7C64IeFKwwjFmD9+X1SV/Jz M0qWGg1dmQlZSmamS+qmRfRYbz7BsAwnzhrGrgdui4m78tvwoeHHRwUp9Jo2csR5Eb8c Gb3Qk3Sx6v9Yciq7bQ4/h2hVWW3oZvqM7+JLxUfhdWBM6Vrg6LKFXh6Lzvq5SawRHwQj UdHpM8QiljUlxzbK43ohoe5yON2Mur9dqLdElubTQoJUT/kpWKk88PoLr3BP7jN2zQO2 u9rKsFoA7VEQjFnJTiEXJwNbEeKEQGCeeKMQlmt1InV1TcQYCsVUocZiSdbVodxRzMCE cCZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=f/PJyfviakQ09G9eit6+ESDDC3eJyySxOn4pdW+zwQ8=; b=RMWGkhGnIkAYZjn69v40uhyhJ/gEYBxH2RRMNfNzgbryNMQjdzhuxehuNQ4XV7kLvx soqWQ551zeihwrThEdXYce8JiVnERH/feKFGSQAMboXrGkixZC5fBJP7ffWoXbLHrABU SkN76nhey05ADbn/1uVJXH67Fw19DFF+u3HZCysXk8Wa3K4LSe5hmgRyjq2ewKsO7E+C n8f+a+y6OtzyLUjtwy3YthsmtkdTyFe3HKUn4RexhJJwVruEMQgIR5XKsFycmoO754QF jIcP6YsdQW/cYh0Tmsfub0GpGkhQ7k4TXsEmuf7eMFXL8SB3/5yFwU6R6KQ5IIWJX4Aq OWtg== 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 e129si11016718pgc.333.2018.12.17.09.21.40; Mon, 17 Dec 2018 09:21:56 -0800 (PST) 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 S1732224AbeLQM7J (ORCPT + 99 others); Mon, 17 Dec 2018 07:59:09 -0500 Received: from metis.ext.pengutronix.de ([85.220.165.71]:53269 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726758AbeLQM7I (ORCPT ); Mon, 17 Dec 2018 07:59:08 -0500 Received: from ptx.hi.pengutronix.de ([2001:67c:670:100:1d::c0]) by metis.ext.pengutronix.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gYsUE-0004Ce-Cp; Mon, 17 Dec 2018 13:59:06 +0100 Received: from ukl by ptx.hi.pengutronix.de with local (Exim 4.89) (envelope-from ) id 1gYsUD-0002Ou-G0; Mon, 17 Dec 2018 13:59:05 +0100 Date: Mon, 17 Dec 2018 13:59:05 +0100 From: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= To: Bartosz Golaszewski Cc: Marc Zyngier , Linus Walleij , Thomas Gleixner , LKML , linux-gpio , Bartosz Golaszewski Subject: Re: [PATCH 1/2] irq/irq_sim: provide irq_sim_fire_edge() Message-ID: <20181217125905.fwbmipvmx4kahlge@pengutronix.de> References: <20181202215613.jcfrxwl4taiqgsql@pengutronix.de> <20181203104923.gcb2bcsaoczjcjhk@pengutronix.de> <20181203110654.53o3prw3qu3u2uyf@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c0 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 17, 2018 at 11:32:45AM +0100, Bartosz Golaszewski wrote: > śr., 5 gru 2018 o 13:38 Bartosz Golaszewski > napisał(a): > > > > śr., 5 gru 2018 o 13:20 Linus Walleij napisał(a): > > > > > > On Mon, Dec 3, 2018 at 12:06 PM Uwe Kleine-König > > > wrote: > > > > On Mon, Dec 03, 2018 at 11:57:26AM +0100, Bartosz Golaszewski wrote: > > > > > > > > It used to live in the gpio-mockup driver and I generalized it > > > > > precisely because there was another driver - iio evgen - which was > > > > > doing basically the same thing. While I don't know if there'll be more > > > > > users (I'd guess it would be useful for testing purposes of other > > > > > subsystems) having the same functionality implemented once is better > > > > > than twice. > > > > > > > > The iio testing driver only needs the trigger and relies on an irq that > > > > then calls the registerd handler. The iio driver doesn't need to tune > > > > the edge sensitivity though and if your mockup driver just only calls > > > > the fire routine if the configured sensitivity justifies that, > > > > everything should work as expected. > > > > > > Simulating edges in the generic IRQ simulator codes seems > > > generally useful to me, even if there is just one user now. > > > > > > Certainly for any kind of IRQ testing, it could be interesting to > > > throw several low-to-high and high-to-low transitions > > > on a driver and see how it reacts. > > > > > > But it is up to the irqchip maintainers to state whether they > > > agree. > > > > > > > All that would be great, but at this point I just want to fix broken > > tests in user-space. After that we can think about how to > > improve/approach simulating interrupts all we want. > > > > Marc: is my explanation for using an int instead of bool for > > irq_sim_fire_edge() fine? Can Linus pick this up for fixes? > > > > Ping. We have only this week left to fix the regression - can we get > your Ack Marc? I don't understand the urge. The problem is that libgpiod's test is failing. And that is because when userspace requested IRQF_TRIGGER_FALLING the mockup driver also fires if the line rised and with my change libgpiod now sees that and wonders about it. Apart from the test failure both libgpiod and the gpio framework are entirely fine (AFAICT). The "fix" under discussion is to modify the mockup driver to only report a falling irq if the output is set to 0. But it also fires if the value is already 0 and is set to 0 again. So the problem isn't addressed completely, but only enough to make libgpiod's test suite report success. In my eyes this is not how test-driven development works. Tests are here to bring breakage into the light. That worked just fine here. And now as a test fails, the goal is to fix the breakage, but not to change just enough details to get the test to pass and then urge them through because "we're already at -rc7 and userspace broke!" And no, the right fix isn't hard. My concerns were expressed Tuesday last week, and the problem wasn't important enough since then to fix the patch set. But maybe it's just me and the Linux development process changed since I learned about it and today the demand on quality isn't that high any more. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ |