From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EA553C433FE for ; Thu, 20 Oct 2022 11:21:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231270AbiJTLV0 (ORCPT ); Thu, 20 Oct 2022 07:21:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60128 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229994AbiJTLVW (ORCPT ); Thu, 20 Oct 2022 07:21:22 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 913521863C5 for ; Thu, 20 Oct 2022 04:21:21 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 84580B82665 for ; Thu, 20 Oct 2022 11:21:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 24CFAC433C1; Thu, 20 Oct 2022 11:21:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1666264878; bh=ZqkTbSIIHiSCMMP0Aesd2axqUOQGZtqEXv7ZKLyrImU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=YIha/i3gu3KV+2jTNtUk70NvuLFSqn57fWcQYluWjgd0D1z7H0rmRBtxkWp7ZXuy+ /h1tsSzhviT8AOMMtxX9qetMp6ckqWcWnIlKpc7zrVsXu2FUi6wPR1lNJI+qGBp3Us VfyaeXYKX2cORxH16dNcwZmnmLTKcsxI2JaaFbzknZP4COh+4D1qLefGmc5zcTsdyX VRXQw3eFbCXOvUIOI0NDDMqHGdlNRDsiazrKjmuNtx6fgQppA67hWpDF0jHcbFE3o3 dVipxHdx5UJq2VK9vjr8fnTuB5qG4F0Yyv8hVL0SXEyW/o3Dy4S4jKTDLrcrPpsbW1 ySunh0QmbwbGA== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1olTbw-000E6m-0y; Thu, 20 Oct 2022 12:21:16 +0100 Date: Thu, 20 Oct 2022 12:21:15 +0100 Message-ID: <864jvyg2qc.wl-maz@kernel.org> From: Marc Zyngier To: Huacai Chen Cc: Thomas Gleixner , loongarch@lists.linux.dev, linux-kernel@vger.kernel.org, Xuefeng Li , Huacai Chen , Jiaxun Yang Subject: Re: [PATCH] irqchip/loongarch: Adjust acpi_cascade_irqdomain_init() and sub-routines In-Reply-To: <20221020073346.536494-1-chenhuacai@loongson.cn> References: <20221020073346.536494-1-chenhuacai@loongson.cn> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: chenhuacai@loongson.cn, tglx@linutronix.de, loongarch@lists.linux.dev, linux-kernel@vger.kernel.org, lixuefeng@loongson.cn, chenhuacai@gmail.com, jiaxun.yang@flygoat.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 20 Oct 2022 08:33:46 +0100, Huacai Chen wrote: > > 1, Adjust prototype of acpi_cascade_irqdomain_init() because we don't > need its return value. > 2, Combine unnecessary short lines to one long line. > > Signed-off-by: Huacai Chen > --- > drivers/irqchip/irq-loongarch-cpu.c | 19 +++++++------------ > drivers/irqchip/irq-loongson-eiointc.c | 19 +++++++------------ > drivers/irqchip/irq-loongson-pch-pic.c | 11 ++++------- > 3 files changed, 18 insertions(+), 31 deletions(-) > > diff --git a/drivers/irqchip/irq-loongarch-cpu.c b/drivers/irqchip/irq-loongarch-cpu.c > index 741612ba6a52..093609c8eaa7 100644 > --- a/drivers/irqchip/irq-loongarch-cpu.c > +++ b/drivers/irqchip/irq-loongarch-cpu.c > @@ -92,31 +92,26 @@ static const struct irq_domain_ops loongarch_cpu_intc_irq_domain_ops = { > .xlate = irq_domain_xlate_onecell, > }; > > -static int __init > -liointc_parse_madt(union acpi_subtable_headers *header, > - const unsigned long end) > +static int __init liointc_parse_madt(union acpi_subtable_headers *header, > + const unsigned long end) > { > struct acpi_madt_lio_pic *liointc_entry = (struct acpi_madt_lio_pic *)header; > > return liointc_acpi_init(irq_domain, liointc_entry); > } > > -static int __init > -eiointc_parse_madt(union acpi_subtable_headers *header, > - const unsigned long end) > +static int __init eiointc_parse_madt(union acpi_subtable_headers *header, > + const unsigned long end) > { > struct acpi_madt_eio_pic *eiointc_entry = (struct acpi_madt_eio_pic *)header; > > return eiointc_acpi_init(irq_domain, eiointc_entry); > } > > -static int __init acpi_cascade_irqdomain_init(void) > +static void __init acpi_cascade_irqdomain_init(void) > { > - acpi_table_parse_madt(ACPI_MADT_TYPE_LIO_PIC, > - liointc_parse_madt, 0); > - acpi_table_parse_madt(ACPI_MADT_TYPE_EIO_PIC, > - eiointc_parse_madt, 0); > - return 0; > + acpi_table_parse_madt(ACPI_MADT_TYPE_LIO_PIC, liointc_parse_madt, 0); > + acpi_table_parse_madt(ACPI_MADT_TYPE_EIO_PIC, eiointc_parse_madt, 0); This definitely looks like it is moving in the wrong direction. The parsing can return an error, and you're not handling it anywhere. Given how often firmware tables are broken, this seems pretty bad. M. -- Without deviation from the norm, progress is not possible.