Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4942442imu; Sun, 25 Nov 2018 13:19:55 -0800 (PST) X-Google-Smtp-Source: AFSGD/WTiGqH+eIEasicw3MSxRU/8IN3BqthdveX/BEW9ugHL8wv74/4liq5jd9+n72BX7l5TsQa X-Received: by 2002:a17:902:227:: with SMTP id 36mr24899162plc.140.1543180794948; Sun, 25 Nov 2018 13:19:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543180794; cv=none; d=google.com; s=arc-20160816; b=A787wVO25uNed8kJRk5qsbT7T0Kmvd2u+MSAfwQGuZ7nYDdN1MoDxYL8iN1aGQJN9U DuS4ZxqstM0sWK0oFd7+Gx3Pvxc3zTqJQAIh1ioX8LbOgjcS4XW56KpPUMwjLRPgSHdX 6RMRAepE4wPRN/YpS5IOZVZ/+iLkiqY1KXAwChWiA15nEjNyO8q+SBcgUyhjlsfBNvOC vjQpsHA6mq23gxVHt/t0+lXHYUGoSHf6JRbMZaDRvr1OT8ID9b1eslXp/P7Arx1s5sx9 NtEmC46At+IQuzXpZgC5sQw+XUXYKPMSy5u06olKcfj8cbJXNP2H/WtDdkq4IU7mY8ZY mc+Q== 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=DnSyp1PgKTR1J7Zjzxr5+sTZZpbQzqF9en7c4jm50AY=; b=cIVJQO23IwoFL+hPp8Gejl6frnMFadWbIEBsLEp2zW1k6jbDVCCcJYNlzTiP653+9P wQL9Nn1kSeetICOfWgKBJJspeMPLw70Ml2UCeR7VpKNgQvqd2tYZs/lShslJU+7APZ/e v4P9AgjZ6/eEis3RQIifaci/Hse5WNVt5omNJqweJqyLdx6oWwFKyCc7XbVG7ToizkFz BpPIAL0nNxYyrBSssHEDkQ2h8hXpXnIO9ERZ412JLYWiz+rJ9KytGfq+3bnKhezwGCGi u9ItV/eUhmzL+uALH38Kq1IDCm1/x2bqO//u8//IXiHWmB1fi33x/tjtYq/BMYXE4E+R 71Uw== 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 b19si38397700pfm.100.2018.11.25.13.19.39; Sun, 25 Nov 2018 13:19:54 -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 S1726132AbeKZIK4 (ORCPT + 99 others); Mon, 26 Nov 2018 03:10:56 -0500 Received: from metis.ext.pengutronix.de ([85.220.165.71]:34535 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725863AbeKZIKz (ORCPT ); Mon, 26 Nov 2018 03:10:55 -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 1gR1nr-0001vS-49; Sun, 25 Nov 2018 22:18:55 +0100 Received: from ukl by ptx.hi.pengutronix.de with local (Exim 4.89) (envelope-from ) id 1gR1nq-0003iH-8d; Sun, 25 Nov 2018 22:18:54 +0100 Date: Sun, 25 Nov 2018 22:18:54 +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: <20181125211854.idnqxz4pco3r7ydr@pengutronix.de> References: <20181120134032.31645-1-brgl@bgdev.pl> <20181120134032.31645-2-brgl@bgdev.pl> <20181120171742.gkwb4s4qbcqvnefj@pengutronix.de> <20181121191509.ia2vcklvx4q2rh56@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 Fri, Nov 23, 2018 at 04:59:46PM +0100, Bartosz Golaszewski wrote: > śr., 21 lis 2018 o 20:15 Uwe Kleine-König > napisał(a): > > > > Hello Bartosz, > > > > On Wed, Nov 21, 2018 at 05:34:32PM +0100, Bartosz Golaszewski wrote: > > > wt., 20 lis 2018 o 18:17 Uwe Kleine-König > > > napisał(a): > > > > > > > > On Tue, Nov 20, 2018 at 02:40:31PM +0100, Bartosz Golaszewski wrote: > > > > > From: Bartosz Golaszewski > > > > > > > > > > The irq_sim irqchip doesn't allow to configure the sensitivity so every > > > > > call to irq_sim_fire() fires a dummy interrupt. This used to not matter > > > > > for gpio-mockup (one of the irq_sim users) until commit fa38869b0161 > > > > > ("gpiolib: Don't support irq sharing for userspace") which made it > > > > > impossible for gpio-mockup to ignore certain events (e.g. only receive > > > > > notifications about rising edge events). > > > > > > > > > > Introduce a specialized variant of irq_sim_fire() which takes another > > > > > argument called edge. allowing to specify the trigger type for the > > > > > dummy interrupt. > > > > > > > > I wonder if it's worth the effort to fix irq_sim. If you take a look in > > > > my gpio-simulator patch, it is trivial to get it right without external > > > > help with an amount of code that is usual for a driver that handles > > > > irqs. > > > > > > You're basically recommending handcrafting another local piece of code > > > for simulating interrupts - something that multiple users may be > > > interested in. You did that in your proposed gpio-simulator and I > > > still can't understand why you couldn't reuse the existing solution. > > > Even if it's broken for your use-case, it's surely easier to fix it > > > than to rewrite and duplicate it? There are very few cases where code > > > consolidation is not a good thing and I don't think this is one of > > > them. > > > > I don't say that factoring out common stuff is bad. But if in the end > > you call > > > > irq_sim_something(some, parameters, offset); > > > > with the simulator and if you don't use the irq simulator you do > > > > irq = irq_find_mapping(irqdomain, offset); > > generic_handle_irq(irq); > > > > I prefer the latter because it's only a single additional line and in > > return it's more obvious what it does because it's the same that many > > other drivers (for real hardware) also do. > > I'm not sure I'm following you. You still need to add ~150 LOC for the > gpio_simulator_irqtrigger() worker and gpio_simulator_irq_*() routines > locally as you did in your gpio-simulator patch. A generic simulator + > using the irq_work saves you that. If you teach the irq-sim driver everything that the gpio-simulator does in the functions you pointed out then this is for sure functionality that other users of the irq-sim code won't make use of. This is about tracking the level of the gpio/irq line and the interrupt enable and raw status bits that usually happen in hardware. The dummy iio driver won't need that for sure as it only cares about triggering an irq and doesn't even specify an irq type. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ |