Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp6786793imu; Mon, 3 Dec 2018 02:50:25 -0800 (PST) X-Google-Smtp-Source: AFSGD/XBuPvXtlHJyS6U4/Gn6YDnpL55XkPeooj+SlNgu6l2lzabsdALM1xx0BRN3naSfdangZNm X-Received: by 2002:a63:9c1a:: with SMTP id f26mr12956725pge.381.1543834225116; Mon, 03 Dec 2018 02:50:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543834225; cv=none; d=google.com; s=arc-20160816; b=BMnJDALBBt3P2BJlolJ9G+9Y2cdJhZIitBVxb4riDgkYY0gbSyNZmlv5x+5hMNX2WP CnxQhcl02d9QvOa+01WtFE5/Zqhwwc6DRT7pQ1y5FYE4thw9HNXnyvI2c0+Vu+fDwaQA Jy1+7eIx621X3QL5DP8wRfT8q9YlaxPYU9WhE3P23zHsiGpxm1KrxqxL1jdfAR+M6/tU CGbSOW8Jk6ZVMU5GXomyhf9ql7ss0YcFvtd/PHvsP8ixETyrawHUu660by6yO6YAeZFv xj8yW+QSEMoFgymuA2ZsRqxRdvE1OqoN2C4qYEsN39kBB8rG9AFVZcptPS5s/VPcFR9F alpw== 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=IrnbGahNoGKV2AMcsaA/6H5aQIiz2eA/mlbCnsHyd6c=; b=Ik/VfJ1PCo/AEkYQNmVZwLULB2ZcIPwe7q/gtxLjkX5Sy0VMRXoPTHix0uVn2LB4QR TInlsVzHYnYn++/hoO2JUX1tVs0asHstHWZ3kN7hn23a3/JUmZTtwDyKDQoxlV15m1s4 nlejJWmWFiBQDgp3G88bEEC7oaBphAhpEOJ2q+YBkdoo/h6kHAAXpeBIt6X2BRxePppU 6KpvLbabT+W3YDytA9cgLRlfCaTfQ/T5hwg7V3ec9GBxyQQnR+PmFfBrY2fWYyD8/RHY 89tN1Ojw89Vm5zGKjn+ukLRsxQurD0oM23nnrG5fXWCH9mvGrOLhkxPNdTKl9hPYs8rm Ks5w== 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 g5si12858322plo.108.2018.12.03.02.50.10; Mon, 03 Dec 2018 02:50:25 -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 S1726191AbeLCKt5 (ORCPT + 99 others); Mon, 3 Dec 2018 05:49:57 -0500 Received: from metis.ext.pengutronix.de ([85.220.165.71]:33761 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725947AbeLCKt5 (ORCPT ); Mon, 3 Dec 2018 05:49:57 -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 1gTln2-0007Ru-EO; Mon, 03 Dec 2018 11:49:24 +0100 Received: from ukl by ptx.hi.pengutronix.de with local (Exim 4.89) (envelope-from ) id 1gTln1-0003Xe-QQ; Mon, 03 Dec 2018 11:49:23 +0100 Date: Mon, 3 Dec 2018 11:49:23 +0100 From: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= To: Bartosz Golaszewski Cc: Thomas Gleixner , Linus Walleij , Linux Kernel Mailing List , "open list:GPIO SUBSYSTEM" , Bartosz Golaszewski Subject: Re: [PATCH 1/2] irq/irq_sim: provide irq_sim_fire_edge() Message-ID: <20181203104923.gcb2bcsaoczjcjhk@pengutronix.de> References: <20181120134032.31645-2-brgl@bgdev.pl> <20181120171742.gkwb4s4qbcqvnefj@pengutronix.de> <20181121191509.ia2vcklvx4q2rh56@pengutronix.de> <20181125211854.idnqxz4pco3r7ydr@pengutronix.de> <20181202215613.jcfrxwl4taiqgsql@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 03, 2018 at 11:23:38AM +0100, Bartosz Golaszewski wrote: > niedz., 2 gru 2018 o 23:20 Bartosz Golaszewski napisał(a): > > > > niedz., 2 gru 2018 o 22:56 Uwe Kleine-König > > napisał(a): > > > > > > Hello, > > > > > > On Thu, Nov 29, 2018 at 07:14:45PM +0100, Bartosz Golaszewski wrote: > > > > We're getting too much into details of how to handle simulated > > > > interrupts and we can continue discussing it, but meanwhile I'd like > > > > to address a different thing: > > > > > > > > Thomas, Linus: after commit fa38869b0161 ("gpiolib: Don't support irq > > > > sharing for userspace") some libgpiod tests are failing because we can > > > > no longer depend on reading the value of a dummy GPIO after detecting > > > > an interrupt to know the edge of the interrupt. While these interrupts > > > > are triggered from debugfs and debugfs is not required to maintain > > > > compatibility, I thing having a working test suite for the GPIO > > > > subsystem and uAPI is worth applying these two patches and also the > > > > previous one[1]. > > > > > > > > Can we have them applied for 4.20 or are there any objections? > > > > > > Just for the record: I objected the patch, Bartosz agrees to discuss > > > further and but because this is too much detail the patch should now be > > > applied anyhow to fix the test suite of an external project. This seems > > > wrong to me. > > > > > > > Just to look at it from a different perspective: we have a project > > whose tests rely on a behavior that was changed by Uwe's patch. While > > the patch is fine, we need to find a correct way of testing the GPIO > > user API. This may take a long time. In order to not break the tests > > of an external project in 4.20 I propose to patch the interrupt > > simulator (a component only used for testing) for now and to revisit > > it later without time pressure. > > > > Best regards, > > Bartosz > > In fact after re-reading this conversation I'm still not sure what > your objection is exactly. You're proposing a solution that may well > be nicely engineered but it's specific to your gpio-simulator. > Meanwhile I'm trying to provide a more generalized API for more > testing modules to use. I think you're generalizing something that won't find any user apart from your mockup driver. So I'd say the generalisation is wrong and the added code could better live in the mockup driver directly. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ |