Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp7246935rwb; Wed, 23 Nov 2022 04:17:57 -0800 (PST) X-Google-Smtp-Source: AA0mqf4lQWf5NRHmAzZWxpgacoMpXzt0sYmgrO3rBSZxlt+o9eCAY6q7+C+p7s9ffp8weFrKu07Z X-Received: by 2002:a05:6402:3893:b0:461:b033:90ac with SMTP id fd19-20020a056402389300b00461b03390acmr13503901edb.257.1669205877027; Wed, 23 Nov 2022 04:17:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669205877; cv=none; d=google.com; s=arc-20160816; b=yauhWuiUMh96SwCejTe2v3U3XdPid+WeKQKi6Oi0249r+ZOjN+Gi2p/fIhTrAUnFKg T6Mqhm6/ilyrWEqoPkpmO/UHREN/gphmmvzvVZHGPTP5MnhPw/keqK9B/sOE+to3nofs H0bNPz2bkVmpVsl2/csBCWcW+4seCpzGsPJctwKbqwyNiK81ZpuLoqrjqVOsWLACp4RC opH77+qYt32rAN6rQGNv9k80regUOD/35BjI2Cu+6GYffGpJqhIJPPQxC5yC83S18qDT 4gCgweeTM84ztblE0csdJmzp9uoh402TXLB3Ft22VdPw2HQC06xKpsf1SB6Apg9hnrGj Akrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=c7FlrRcKHIFrRkveac6JF/JglSqA3pnlIgJwgHBeStQ=; b=i6Lzv/LGZs5YaLdG662kjLqKFAK6vk+mmfnz5jxZGOOkMsG68rN887bZA+xY7VqLUl 5aJ3EwEhhlSm9kpZ2zpbbxAzHChfogRG2SrG/hbURCJXc6uyksweCHtEPU7KZ1dmqH8Y GyVc7qENFXso1Tn6VMgEB6Om4Yf5aXRCpiudi8r1qxEIe71hV+/LTxgSgqio/7Cv9yEd R4MSEo/yzzCLmJjRMBcpw7kWL0yxffhf15Q9XAj1tPkUMjIxJB7Lh46i5UM6JbHKevNy 4cEcbhpOqmfEC/oDsxZT7mM+xDwD/Ky6YyXq9IdPYW/5XczujEcWASmO0V+Q8YbAGzIQ 4hmg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=qgyTEwou; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b8-20020a056402278800b0045c7611d8ddsi14624937ede.179.2022.11.23.04.17.34; Wed, 23 Nov 2022 04:17:57 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=qgyTEwou; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236987AbiKWLiO (ORCPT + 89 others); Wed, 23 Nov 2022 06:38:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48780 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235950AbiKWLiL (ORCPT ); Wed, 23 Nov 2022 06:38:11 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DDFE610891E; Wed, 23 Nov 2022 03:38:10 -0800 (PST) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1669203489; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=c7FlrRcKHIFrRkveac6JF/JglSqA3pnlIgJwgHBeStQ=; b=qgyTEwouWkDqwBtPTCRvXfUr+Sf0+ZE1xJx7iOH3iyXycWsnawONGi48BREDiIAn2APn/3 2i93++u3PGfhxSiB8dXRzVTDrseed7iuEVhpHYFoXA1Um53D+/VeJoACr7KTSg3xIPOG5Y UaSjE72bWKOSMAeHAktclJ4S78PNoIlHlUpeY0IMqoFIrJTOCQUVfk48el7XMAeAWQ4isM 9voMIBx/u7Hkm0O1JfL4Cx5H7NvlY6Rui+E/7FkiYn3iLnWkE50ksc2+eHb/S1AkhIvD+9 oh6kPwtjqICbs1XyZuPLLqqh9e+U9nz/IllkqTukUg49nbx5ZG6t3d2vHxBs9Q== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1669203489; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=c7FlrRcKHIFrRkveac6JF/JglSqA3pnlIgJwgHBeStQ=; b=YnTSrjh0MPSCf5N+/jH1zstArJBEc2I71dc4NMcPzS1HLbHzwLtbt+/u3XlAVmgzFkGUbO 9KkYwN2nUbNop2Cg== To: "Tian, Kevin" , LKML Cc: "x86@kernel.org" , Joerg Roedel , Will Deacon , "linux-pci@vger.kernel.org" , Bjorn Helgaas , Lorenzo Pieralisi , Marc Zyngier , Greg Kroah-Hartman , Jason Gunthorpe , "Jiang, Dave" , Alex Williamson , "Williams, Dan J" , Logan Gunthorpe , "Raj, Ashok" , Jon Mason , Allen Hubbe Subject: RE: [patch V2 07/33] genirq/msi: Provide msi_create/free_device_irq_domain() In-Reply-To: References: <20221121083657.157152924@linutronix.de> <20221121091326.879869866@linutronix.de> Date: Wed, 23 Nov 2022 12:38:08 +0100 Message-ID: <8735a9gau7.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 23 2022 at 08:02, Kevin Tian wrote: >> From: Thomas Gleixner >> Sent: Monday, November 21, 2022 10:38 PM >> >> >> +static inline void msi_remove_device_irqdomains(struct device *dev, struct >> msi_device_data *md) >> +{ > > 'md' is unused Duh, yes. >> + * >> + * Return: True on success, false otherwise > > Can you elaborate why boolean type is selected instead of returning the > actual error codes? the outmost callers are all new functions: > > pci_setup_msi[x]_device_domain() > pci_create_ims_domain() > > I didn't find out any legacy convention forcing this way... What's the value of error codes? 99% of all callsites do: ret = foo(); if (ret) goto fail; Nothing evaluates the error codes, unless there is real useful information like EAGAIN or ENOSPC which can tell the caller to retry eventually or with different parameters. But for the above, the error code is just useless. >> + bundle = kmemdup(template, sizeof(*bundle), GFP_KERNEL); >> + if (!bundle) >> + return false; >> + >> + bundle->info.hwsize = hwsize ? hwsize : MSI_MAX_INDEX; > > patch04 marks that hwsize being 0 means unknown or unlimited in the > header file. > > but here info.hwsize always gets a value i.e. the meaning of 0 only exists > in this function. What about removing the trailing words about 0 in > patch04? > > - + * @hwsize: The hardware table size (0 if unknown/unlimited) > + + * @hwsize: The hardware table size Fair enough, though I rather make that: * @hwsize: The hardware table size or the software defined index limit