Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp286890pxt; Wed, 11 Aug 2021 21:24:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzEw2awtoI+9W3R4QCYXCaDdzz4sjtG7a4h/zHCxhSUgd5chQ8rZihVNci8qDhVcO6BtISz X-Received: by 2002:aa7:d5c8:: with SMTP id d8mr3112205eds.110.1628742297448; Wed, 11 Aug 2021 21:24:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628742297; cv=none; d=google.com; s=arc-20160816; b=ZwcFK7JyoCEiBlSDeXqGVQ+F+gyaK9SLYKh40O60WAjOBTc60BgynwqGx/LcPo7eqQ 0P/QDYHaMLbfBuvqfnmnRxLWQb5lHDH1pZ3q3emnrgcDUA5NWCASm0O+LfTR4BR2mTAb jhOkHu2TQm7riwoultsngJId3TQQFuXL+UYRvHSRs/E75Tj/93qvp2b/uwTv13h8bxX2 P+39gsNdf8fUKABv4WV5QrtadbbbhGOdTI2R1mF8cjWETx4SHqIxSjpRiRvqS8B3zj5e yJ1gHdGNlUZyGCX/vPapT1ynQXYoG0PhKDREjAmTiMD/7AAbm5op9y4sEENHXk4FEVbn ysxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=XAWS1Fzhv4ugWPxdQYgyaalWdh5gKPCIpOricQxOSqE=; b=t+6VSyef64XyDyxO4YiYJFg1es9D6kEN772MzzC2+zQJbOUJdVITJA7in/FSsj3O5W SbfILOAmrc4aRKerm4ovFy9UsDHrqHKKLfgNfknVaYCEBWXPO3JY/RJhRqSG5tC/8AL0 eIjaKJAAuvEF6k4zSktC6SmkiIFieURd401nhFuToUUta7RDU3hOdWmipmv+C6KGX72o RnzZfUw0vUjhGZvl071TC2wa6DbBWXKFxFW1+lK0lbFNYO9/4h5YC42xEa63A3heq9n/ UI8gs79aQvpj2wQtmvzTJBeTrc82SXKYbwwtT3Xl8RmxumyEfyWx7uWPiP1443cGV8k8 Gb4A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=BCFoXTQs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d21si1477740edq.255.2021.08.11.21.24.32; Wed, 11 Aug 2021 21:24:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=BCFoXTQs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229825AbhHLEUP (ORCPT + 99 others); Thu, 12 Aug 2021 00:20:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49418 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229531AbhHLEUO (ORCPT ); Thu, 12 Aug 2021 00:20:14 -0400 Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1E16CC061765 for ; Wed, 11 Aug 2021 21:19:43 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id l11so5573390plk.6 for ; Wed, 11 Aug 2021 21:19:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=XAWS1Fzhv4ugWPxdQYgyaalWdh5gKPCIpOricQxOSqE=; b=BCFoXTQsHbkiIkvbjWEdPulFyID6opdl2wdKX1x4akrMJrAy2RCouDIu3Od9lY+Igk KD0e4sxVSkt7K3OGVAMA1pdbWdSrgF7zfLgULu58LXkpAtUajVokIcE4QPHOY7spnIBr bMDQ+UIvBWLD2Rin65XKoVyv+MfxAUS0badbIC7eB7GWdTjC/fH5fENAZmu5lxIpdcKa BxPiDs3DwME9i5w5joo9IkMhGuowhTie219wK0mbay1bcsQ/iLufsJRT96BBqYrO0o/H HiM5lqfgersR/WjcegQV0DVGds1Tn08I4f4LF8JrrgH1x4VSjjrsm8Rm6ikEZy2AS9IE FTjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=XAWS1Fzhv4ugWPxdQYgyaalWdh5gKPCIpOricQxOSqE=; b=saMpZUwFsW5bEVjnw90oyoZECtK7Q2eqDoeVn/iO4nA6/dnBmKztPYa0SgUHl7eVWW tJYGEcXaVVmllgIb+NbnLDLYt9b8wBgQMfdkarfSaO+Z4RxxpNaMlg7sWQXJU0NZS9qU 9RaBpa6CikX769qiE+eeX/Pq61eMoO8cx0IpSSetdb1E1tuKOzjj1W6C2NdvfUOvuaaV 55jMMKbyZ/PKv1p/nqLIplDHks7KbIZKwKKwDevIM3CkYR31y16wObshlvtuFAzde/WM XVVGuDvHC2iaiCAdDDG4yKB9/wEelxd0z9iBEei1oT09l3/fI5lw+sQD3huUhXKuylNG uAgQ== X-Gm-Message-State: AOAM533RW9DVTkgLB/c3g54KdsZJ/bEqY4B0Mv9wyciihrgs2nlw8JBg 1vGcpKdQfRcizN/Nl5fTUD8= X-Received: by 2002:a17:90a:fb81:: with SMTP id cp1mr2341998pjb.52.1628741982604; Wed, 11 Aug 2021 21:19:42 -0700 (PDT) Received: from localhost.localdomain ([2407:7000:8916:5000:73b9:7bc0:297c:e850]) by smtp.gmail.com with ESMTPSA id v10sm8480332pjd.29.2021.08.11.21.19.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Aug 2021 21:19:42 -0700 (PDT) From: Barry Song <21cnbao@gmail.com> To: gregkh@linuxfoundation.org Cc: linux-kernel@vger.kernel.org, linuxarm@huawei.com, rafael@kernel.org, robin.murphy@arm.com, song.bao.hua@hisilicon.com, wangzhou1@hisilicon.com, will@kernel.org Subject: Re: [PATCH] platform-msi: Add ABI to show msi_irqs of platform devices Date: Thu, 12 Aug 2021 16:19:30 +1200 Message-Id: <20210812041930.28931-1-21cnbao@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > > +static ssize_t platform_msi_show(struct device *dev, struct device_attribute *attr, > > + char *buf) > > +{ > > + struct msi_desc *entry; > > + unsigned long irq; > > + int retval; > > + > > + retval = kstrtoul(attr->attr.name, 10, &irq); > > + if (retval) > > + return retval; > > + > > + entry = irq_get_msi_desc(irq); > > + if (entry) > > + return sprintf(buf, "msi\n"); > > sysfs_emit()? yep. > > But why isn't this all handled by the MSI core code? Why would each bus > need to have this logic in it? i think i can extract some common code for sysfs populate/destroy to msi core from pci and platform. but we still need some pci/platform specific code in pci-msi and platform-msi cores. for example, pci-msi has specific data which will be accessed in its show() entry. struct msi_desc { ... union { /* PCI MSI/X specific data */ struct { u32 masked; struct { u8 is_msix : 1; u8 multiple : 3; u8 multi_cap : 3; u8 maskbit : 1; u8 is_64 : 1; u8 is_virtual : 1; u16 entry_nr; unsigned default_irq; } msi_attrib; union { u8 mask_pos; void __iomem *mask_base; }; }; ... struct platform_msi_desc platform; ... }; }; in addition, they are quite different in initialization/release and also need different places to save sysfs groups. so probably i can let msi cores provide msi_populate_sysfs() and msi_destroy_sysfs() APIs. And ask pci and platform to call msi_populate_sysfs() in their init code and save the groups in their specific pointers, and then they can free sysfs in their release paths by calling msi_destroy_sysfs() > > thanks, > > greg k-h Thanks Barry