From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) (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 9A682560AB6 for ; Wed, 14 Oct 2026 16:21:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791994868; cv=none; b=AgidOwgPylg0yb364PHoEHQTfhMRExSQWYqaMFNRrJlS8zhFUGgTLUZ/ohBW6jjCM5uDie7bUYa7tBETNtfgyRZz3UhY1Uu7wR37ww8JG2b1VWWOaDGqJSAqx+/hgJyEck4gjHr2f0fB9ua5ZmgFuWVI7OhZFusFpLDotxJTnb8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791994868; c=relaxed/simple; bh=P3+kOL1y2nv1UhzDI3hBIeFZ+qnuxfwB9W3emUPgCGE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=C77nrS2bxW7uXKfDLlvhXy7LbZLX/Ur0x5cuV6IiJ2ZpAGgvzkMPDQjQ0cbUY0VVjkFVAVWo42kVgpfxAXulQoptqqvnehW1qTviyzLc5tn7hd1uCgvHQLPoB4GFNjmpbDH4ezwbajOBd6YY3dlPDzqM/K/GmGlFxi4qt3l1auI= 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=PAZnYwE+; arc=none smtp.client-ip=209.85.214.175 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="PAZnYwE+" Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-2db3728f0c4so3960085ad.0 for ; Wed, 14 Oct 2026 09:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1791994865; x=1792599665; darn=vger.kernel.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:content-type:from:to:cc :subject:date:message-id:reply-to:content-type; bh=P3+kOL1y2nv1UhzDI3hBIeFZ+qnuxfwB9W3emUPgCGE=; b=PAZnYwE+Dstuux6bB4LXq6Uldd2Te10BQgI1YZL3P2o+AbWwKVs526yGHFXALkDRLk lUR2So0bMZnVLOTquUQfSfi3RoixIWXlpPii/G8nbg4H+jxFliaE4429mkVpBGMZCaQU C9zlT2GD8elQBy6VVTM/GYGfJG54gmyXEvIhQU8Uv7/1QwYQpiwTWojGG6ZcSWkZga8r qNR1xvEzP/DIEgQPnIGc9ZEllvPyD+NSNHZHmpu4a248FuFrxryNHY/aUPYh7PFBJUEW v+qKuZHLSlIRLcjOuoE0Idn/nP4gAdThfsELhtBka0FPUBD7mx0WodhaHt6WHF4XNnxh Y6jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791994865; x=1792599665; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:content-type:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=P3+kOL1y2nv1UhzDI3hBIeFZ+qnuxfwB9W3emUPgCGE=; b=vktIKMdjmSrX6Uh0+Wyl7OuxgnL+YpaAKJ8TOlaQJMDsPL0ufwkyXKUhkGyBgk0I/B n4lfpRJfXBG3+sEQ77bDD+GO7ZM3MWYzF15KPWLdphUhYfQH7IGlxaFyfV7Mftia2lNz NF7jf8IqXyePlGxgq1GQ8Spi1wsh5ic5qNqXz7Wn21avZj/ovvnNADaBPm0bnol7LSz7 dTFHOI07TZ85bcq8xkTMa8x3RH9dy5p9Az98nv6uCPb8GBWd5UWzYim66cFeDcFH2oPl 9idD9gBwYfNooArX3R9lEb9ly3HzvPli1E3yICVkKDDcbAis1ZlwwtvcQJhwX0UR+k1e atjA== X-Forwarded-Encrypted: i=1; AKwUvByGSQOyRmyz6V8M06sMO7BAWF7iW/lUaZ9eEPOOo9DM7bG9HDm/5rAwKo3IW/zXJTra5JtoGCUhN4cTvz8=@vger.kernel.org X-Gm-Message-State: AFq9FYL3DJ6AEwmtxBRGf85YMh4O5kyasYcIeCWWt2lDQBf5JlLzMRbt k2EO/2v/Yf1XERfi5A80s6yMs5/1wmy/CzAvrMTOtSSV/34a/F4fHPel X-Gm-Gg: AYBFou2WqGMok3X9firw0uq3A5eXcdoRhZ4MwfA+MKZ+fQhB+Yw7Nd2kTh0mTrPPWxh RBxiJyslI0n7QI/gR2HEs1EqkKlwbTO48Z3STmZIe6A93P/rQZuF3UboBfe9/7bSgkv6EWA+NOz yvimuV0Hj4bFJB16Sgq5WPyy6XIAE3x+mZQi9dnbLxPh/VavbC+9kK49B5lRn7YcvcnJDvKHPU0 goq9OTDG+GAV1JkxNXx2uNZMCbVRNWv6V98oFqUc9x87aR+QdAmhqee12Q5+EU/4OtYhouErhLK 1AVC2qzKgbtmjqdUA13QkBLrUBLQrTnIt3ehiBYbStaLfAYxXfEccT+EXEvWHdLn8eUtEyFBie6 cIPjbyPuvbPYyzTcIcaNBnyyXVwigLrSUuTV6qhSlfcIaiKMOCpPxq8qNGve3k4MABgN9XOn4X5 BN3b20yUc8C7Fr1rgojmQC43QucVk7VpPAyPcPjN+UDchV7cN9TK99jWIGoAjL2rNvGryIEUWix Ec6AorG419nZ5okIQQAv9YPBu8zsFc= X-Received: by 2002:a17:90a:d44d:b0:3a4:9d98:f980 with SMTP id 98e67ed59e1d1-3ab3a3b0c61mr24024340a91.1.1791994865254; Wed, 14 Oct 2026 09:21:05 -0700 (PDT) Received: from smtpclient.apple ([23.247.139.92]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3ac92a1f906sm335949a91.0.2026.10.14.09.21.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Oct 2026 09:21:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81.1.8\)) Subject: Re: [PATCH RFC v2 0/4] gpio: loongson-64bit: add interrupt support for more models From: Miao Wang In-Reply-To: Date: Thu, 15 Oct 2026 00:20:49 +0800 Cc: Andy Shevchenko , Miao Wang via B4 Relay , Jiaxun Yang , linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, Yinbo Zhu , Linus Walleij Content-Transfer-Encoding: quoted-printable Message-Id: <317E251E-9135-4376-B813-74B8A748FD72@gmail.com> References: <20261002-loongsongpio-v2-0-6e3eb150a4ef@gmail.com> <7D6EB1C6-0CCB-44F1-B698-89B0479EEDA2@gmail.com> To: Bartosz Golaszewski X-Mailer: Apple Mail (2.3826.700.81.1.8) Hi, > 2026=E5=B9=B410=E6=9C=8814=E6=97=A5 23:33=EF=BC=8CBartosz Golaszewski = =E5=86=99=E9=81=93=EF=BC=9A >=20 > On Thu, 8 Oct 2026 12:21:43 +0200, Miao Wang = said: >> Hi, >>=20 >>> 2026=E5=B9=B410=E6=9C=888=E6=97=A5 18:04=EF=BC=8CBartosz Golaszewski = =E5=86=99=E9=81=93=EF=BC=9A >>>=20 >>> On Thu, 1 Oct 2026 20:13:18 +0200, Miao Wang via B4 Relay >>> said: >>>> This patch series aims to correctly add interrupt support for GPIO >>>> controllers found on more Loongson CPUs. The GPIO controllers in = such >>>> models do not have a complete intgrated interrupt controller, but = choose >>>> to delegate interrupt handling to their parent interrupt = controller. >>>> This sounds like a heirarchical interrupt setup, but what makes it >>>> more complex is that multiple GPIO lines in these controllers may = share >>>> one interrupt line on the parent interrupt controller. The details = is >>>> described in the third patch. >>>>=20 >>>> Signed-off-by: Miao Wang >>>> --- >>>=20 >>> The series looks pretty good. Who is the RFC addressed at in this = case? I can't >>> really answer the questions from patch 3/4 as I don't know this = platform nor am >>> I well versed in ACPI. Maybe Cc the GPIO ACPI maintainers for = review? >>=20 >> Thanks for your review. The RFC contains two questions, the first is = about >> the firmware interface, including FDT and ACPI; the second is about = the >> way handling the delegated IRQs. >>=20 >> Regarding the firmware interface, it is to be decided how to declare >> platform irq numbers for the GPIO controller. Such a GPIO controller >> may have N gpio lines with M parent interrupt lines (M < N). The >> firmware should a) list M irq numbers corresponding to the M parent >> interrupt lines or b) list N irq numbers (which might be duplicated) >> orresponding to the N gpio lines. Previously b) was chosen by the >> kernel driver. However actual ACPI tables found in the published >> firmware chose a). The discussion about it happened in [1]. >>=20 >=20 > Unless it impacts DT systems, I'll let Andy handle the ACPI part. = Please Cc him > next time as I pointed out under the RFC. Will add him on the Cc list in further revisions. >> Regarding to the interrupt handling delegation, since there is no >> complete interrupt controller integrated with the GPIO controller, >> the interrupt handling, including detecting edge triggered interrupts >> and masking/unmasking, should be delegated to the parent IRQ = controller. >> I want to check if my implementation approach is acceptable and not >> violating any implicit rules on the interrupt subsystem side. >>=20 >=20 > I'd suggest to run your implementation by Thomas Gleixner because = directly > accessing the internals of the parent's irq data looks fishy. For = instance: > you call irq_set_type() directly without going through __setup_irq() = -> > __irq_set_trigger() which does some additional bookkeeping. I would originally tend to avoid directly calling into ->irq_set_type() = and other handlers like this. However, the IRQ subsystem does not seem to = provide APIs to mask, unmask or set type of a given IRQ. Furthermore, = __setup_irq() is for registering irq_handler for an irq, while in chained irq chip, = however, irq_flow_handler is needed and should be registered via = __irq_do_set_handler(). Cheers, Miao Wang