From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 06A3EA95C for ; Fri, 17 Jan 2025 18:03:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737137040; cv=none; b=TA4j29kjplvjvcRfZo1XTBcAfmRNcQGH2YSF+FCn+qS7aRZFDwmzaz2FueUx3kBk/5XVU1vxkzwDPqOx8i6iArQ3whP8q5XwxTba9PB90LYmRBhWK0NCmo7pvqItw4GoI2anUF56HFeUctW/hbtGxqi/bw437DUCNAVkcnPEnZo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737137040; c=relaxed/simple; bh=KuTujFjLFqC85RmNoU71r6vH4QchfC9uRvDqZB4AK3c=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=gGn/1A710glo+jdPD2/KlLnaHZhI00+rscDILnJbSPWYwYDjALfU23r4P8Y+sVsbjba1QhA4E6XuvKpXcsCEY6poK6Clm7XfQp3Uwwe2dOhlaK+KIRUCwdhbxLS3wkwlNQ2fxezRhQEm3EBqu7wBJ2f7tSdzARlds+lrACKUQz0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=QeYDUA50; arc=none smtp.client-ip=209.85.128.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="QeYDUA50" Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-436a39e4891so16377195e9.1 for ; Fri, 17 Jan 2025 10:03:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1737137037; x=1737741837; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=RatKvAJcD32MvFcTfJjNC+HdyA4yohSnyhYlOf4tvao=; b=QeYDUA50oGjkg1+5jCdnKzEcH3UH1hLvMbqQEj7YLxokY804scEF9OBUWKsLLqy7YN 5ZkBdtNFyZkJlXv5NB49UaKAApLYdYz7OVmMAamYIVC/Vh1rz5LaGgcBo68rkCpbmdyC aRU/Jd7HhsNIjoav0M3/vCZeakPujbwSKwntQF6DSKKDXgMK3y7P+uJMWbOy6Xo4eOpb +Y5m0iBc3nyUVRq0pnRnetVtnA1AeFfKX44AH3eLI37stmEAlO41to3wYhCrjw+eCh/G pPGQwMnwnQxl6G3NxSxW5yYCR4eWq3uSoWCIltwmxq4Gwp+yGB/JHo0cDmU3oJBSnWBV 9Wbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737137037; x=1737741837; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=RatKvAJcD32MvFcTfJjNC+HdyA4yohSnyhYlOf4tvao=; b=ZGAWc72I1/nfm56f4KftGL8KX8Qv48ZIFYN7WKvi679T3FkI013+FW+CjoYT/iX1k5 iuWwZ7NgLJOWMXNWlIe69B4ame/Pug7TBAxJAdqO1gJ6eEXiNxUZV9+Mv74u60lJjPr1 g9Fab/Lz4MEb/G3dGM0E1mdwi28o8Sxc6ykbOCTE1Oh7Bxwv29NP6xIKV3VpEyVTq8eY n9znx2T0G5u3kXhxEfPY1I7IJI0pgFGh4PqU6dzv1a5UCgWDBFY0RyINNSV+V8sSWXwz 3f9DiVTHOsAjIqjFwZGEWxobgjy0+WXaqZOAJmFwQOsjwHfaDRWSXvMinYn1U0m3iEdU FXGA== X-Forwarded-Encrypted: i=1; AJvYcCVjkpZ0iO8kcTb3gpnb0OYUvm0qcYp7/GAfgzqkwg9u+z9teOHqldQbWUn9jmdrtLkJav752sjHvVvu6xs=@vger.kernel.org X-Gm-Message-State: AOJu0Yxmlx3PlaPWqahELqwReEiqpMSXpca4iL9//4TSTgfnsmiMjtS8 F4BVP45MDhEBVDg8wgcS4Zjtxj6+9iVE+ODj44tQqmlN6d4qYp/iV2qFwE60 X-Gm-Gg: ASbGncsv20171Gh3Gt9wxuBhGtBAWfaV/Iq3huBXQr3enrGREcmlH6CiDJqG6AxNTMY gua+IN+9v48nWnRaD2P5FJNNnDizz1kJhruw8QxSvaHyi0BDWndGWGIKMdwSIeGhb9f5O7oU4+z eAACjJOtLNS+gitrAF3vR3PlLIsMegJKwkYNugl5ofa+YNWCgC6xjeptgtjuH7mU9/h0FkDGwQR xqGyoBgMr3CzGT5yaGVgH+tx+cC41Ran159ZXQXLdiCh6Sp5yRl3zUF X-Google-Smtp-Source: AGHT+IFNuc0bhE3QCtGngxDAAK7Ch517eRBZhc6hiiQQ+1TBfNiGOINQJUhPKIa3NHjKppEtZfy04A== X-Received: by 2002:a5d:64a1:0:b0:38a:39ad:3e2f with SMTP id ffacd0b85a97d-38bf565573dmr3662790f8f.2.1737137036896; Fri, 17 Jan 2025 10:03:56 -0800 (PST) Received: from eichest-laptop ([2a02:168:af72:0:a17a:6a28:e744:9a06]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38bf327e118sm3011964f8f.82.2025.01.17.10.03.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Jan 2025 10:03:56 -0800 (PST) Date: Fri, 17 Jan 2025 19:03:54 +0100 From: Stefan Eichenberger To: Thomas Gleixner Cc: andrew@lunn.ch, gregory.clement@bootlin.com, sebastian.hesselbarth@gmail.com, shivamurthy.shastri@linutronix.de, anna-maria@linutronix.de, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1] irqchip/irq-mvebu-icu: Fix irq_set_type for sei and nsr Message-ID: References: <20241217111623.92625-1-eichest@gmail.com> <87frlkcx2b.ffs@tglx> <87tt9ya2qy.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87tt9ya2qy.ffs@tglx> On Thu, Jan 16, 2025 at 10:05:25PM +0100, Thomas Gleixner wrote: > Hi! > > On Thu, Jan 16 2025 at 18:12, Stefan Eichenberger wrote: > > On Wed, Jan 15, 2025 at 09:15:24AM +0100, Thomas Gleixner wrote: > >> And looking at the potential platform MSI providers for MVEBU, then it > >> turns out that GICP and SEI both have the irq_set_type() callback > >> populated, though ODMI has not. So either this has never worked or there > >> is something else fishy. > >> > >> Can you please enable CONFIG_GENERIC_IRQ_DEBUGFS, build/boot a 6.10 > >> kernel and provide the output of > >> > >> cat /sys/kernel/debug/irq/irq/$N > >> > >> where $N is the interrupt number of the thermal sensor. > >> > >> Then provide the same information for a current kernel with your patch > >> applied. > > > > You are right I somehow didn't look back far enough. I tested once with > > kernel 6.12.5 and my patch applied: > > > root@localhost:~# uname -a > > Linux localhost.localdomain 6.12.5+ #157 SMP PREEMPT Thu Jan 16 17:32:21 CET 2025 aarch64 GNU/Linux > > root@localhost:~# cat /proc/interrupts |grep thermal > > 35: 0 0 0 0 AP SEI 18 Level f06f8000.system-controller:thermal-sensor@80 > > 90: 0 0 0 0 SEI-ICU-SEI-f21e0000.interrupt-controller:inter 116 Edge f2400000.system-controller:thermal-sensor@70 > > 91: 0 0 0 0 SEI-ICU-SEI-f61e0000.interrupt-controller:inter 116 Edge f6400000.system-controller:thermal-sensor@70 > > root@localhost:~# cat /sys/kernel/debug/irq/irqs/90 > > handler: handle_edge_irq > > device: f21e0000.interrupt-controller:interrupt-controller@50 > > status: 0x00000000 > > istate: 0x00004000 > > ddepth: 0 > > wdepth: 0 > > dstate: 0x02400204 > > IRQ_TYPE_LEVEL_HIGH > > IRQD_ACTIVATED > > IRQD_IRQ_STARTED > > IRQD_DEFAULT_TRIGGER_SET > > node: -1 > > affinity: 0-3 > > effectiv: > > domain: :cp0:config-space@f2000000:interrupt-controller@1e0000:interrupt-controller@50-16 > > hwirq: 0x74 > > chip: SEI-ICU-SEI-f21e0000.interrupt-controller:inter > > flags: 0x80 > > IRQCHIP_SUPPORTS_LEVEL_MSI > > parent: > > domain: :ap807:config-space@f0000000:interrupt-controller@3f0200-2 > > hwirq: 0x0 > > chip: CP SEI > > Ok. That explains it. CP SEI has: > > static int mvebu_sei_cp_set_type(struct irq_data *data, unsigned int type) > { > if ((type & IRQ_TYPE_SENSE_MASK) != IRQ_TYPE_EDGE_RISING) > return -EINVAL; > return 0; > } > > But the DT configuration requests: > > > IRQ_TYPE_LEVEL_HIGH > > IRQ_TYPE_LEVEL_HIGH = 0x00000004, > > > genirq: Setting trigger mode 4 for irq 85 failed (irq_chip_set_type_parent+0x0/0x34) > > which is not supported by CP SEI. > > With your patch the type request is just stored in the data, but no > actual type setting happens. That's default behaviour for chips which do > not have a set_type() callback. > > > root@localhost:~# cat /sys/kernel/debug/irq/irqs/90 > > handler: handle_edge_irq > > device: (null) > > > > It seems with kernel 6.10 the controller device was not set correctly, > > probably it was ignoring irq_set_type because of this. > > No. That's not related. > > > Do you by chance have an idea how to properly fix this or should I do > > some more research? > > It's unclear to me how the 6.10 kernel survives that. Do you have a > different device tree for those kernels? I used the same device tree for the 6.10 kernel as I did for kernel 6.12. I didn't even recompile it. Unfortunately, I couldn't figure out what exactly is different so far. However, on the 6.10 kernel I got the following trace: root@localhost:/sys/kernel/tracing# cat trace # tracer: function_graph # # CPU DURATION FUNCTION CALLS # | | | | | | | 1) | devm_request_threaded_irq() { 1) | request_threaded_irq() { 0) | __irq_set_trigger() { 0) | irq_chip_set_type_parent() { 0) | irq_chip_set_type_parent() { 0) 2.560 us | mvebu_sei_cp_set_type(); /* = 0x0 */ 0) 8.640 us | } /* irq_chip_set_type_parent = 0x0 */ 0) + 14.400 us | } /* irq_chip_set_type_parent = 0x0 */ 0) + 24.320 us | } /* __irq_set_trigger = 0x0 */ 0) * 13601.60 us | } /* request_threaded_irq = 0x0 */ 0) * 13617.44 us | } /* devm_request_threaded_irq = 0x0 */ It seems that irq_chip_set_type_parent is not failing. By adding some debug messages to kernel/irq/manage.c I found that irqd_get_trigger_type returns IRQF_TRIGGER_RISING even though it should return IRQF_TRIGGER_HIGH according to the device tree. Maybe this was fixed between 6.10 and 6.12 but I need to analyze that again in more detail. [ 91.069407] genirq: __setup_irq - kernel/irq/manage.c:1530, flags: 0x0 [ 91.076042] genirq: __setup_irq - kernel/irq/manage.c:1533, flags: 0x1 For a possible solution, should I just change the device tree so that IRQF_TRIGGER_RISING is used instead of IRQF_TRIGGER_HIGH? Regards, Stefan