Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp399311pxt; Thu, 12 Aug 2021 00:44:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwdiwy5wgaxgKgj+mkhme6nbRNUcuqmdaFxHzLhjGYyYCR0FxVLJ22OifUZvxfDcUibgn6H X-Received: by 2002:a05:6402:cb7:: with SMTP id cn23mr3855931edb.82.1628754254331; Thu, 12 Aug 2021 00:44:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628754254; cv=none; d=google.com; s=arc-20160816; b=coWqmIhroOQ0gTB0/YXNXn7mw6h6hYBx54QFOGr0e95LP4S2nBrQef/kCT64Acqzg7 lMKpSuZiT9sErlvJBFwPJ5xYJa8HzEg5KJF5S13dI4kIHzdAOEMwjDeWrMLbjMS3Sgxp sPts+nyjSEYtIqbVCeeg2M+wg14X/pn1Z0d+gQgY2F+RVX49TIj1OcSQedXCgKjGxh2X 5oC5e0fCKRMx4463/uFJ60ScseLK9rZeCRXi+z7u4JhSKu0D8+RBo2YUuRooi3z1lW9E aZUPeAPpcTSwio6pJYDD7T8Pn4YqYosPuQFZIXzeGRuEkP5ar0mc6h2loHiGe885tQGg yp0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=lV9jPJXpiH0fiUZWFWcriY6NFX57bz7ORw4+XHPVPFc=; b=CuZwdr+G2WhEHxpb4NrMonPaCOKFLXWl+SgtSc4/PC0ZRBkDVDYB+oKurhWigY1wiq jgNXJQtwPjnbx+Lra+1OvKL1KN6HReVht9VHPvc+/qTGgkP1ZM2KSl2WYVivJ2CNlQSg QG9pP7VuSD06/K8qvYVemoGadJIVzgwK/dtJWiqVXbydqFyasrAfGBKU5aL1ep0AFG2M irUHvx5bdSZVa5P27GHx53Ylqm95Qtk3kNFyY+UUGPPtxwXFsDSK1CD7uu70Gn/DN28k 3whuxGah6mYehMBqdpJJtuZzdkglX9bCNKhI5C9Q9QzL/d0A1goeLjk58AIR2njNqXtT W+oA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=s0hwkZyW; 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=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y10si1843078edv.172.2021.08.12.00.43.51; Thu, 12 Aug 2021 00:44:14 -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=@linuxfoundation.org header.s=korg header.b=s0hwkZyW; 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=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234780AbhHLHZJ (ORCPT + 99 others); Thu, 12 Aug 2021 03:25:09 -0400 Received: from mail.kernel.org ([198.145.29.99]:55102 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234686AbhHLHZJ (ORCPT ); Thu, 12 Aug 2021 03:25:09 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id B4DDF6103A; Thu, 12 Aug 2021 07:24:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1628753084; bh=EwIrU90Iyan+k9RsNBKZ0gRybIeyH+v6cfuZeVPl0fI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=s0hwkZyWBR5Ep5rk4tHGMjPtbEDl2w9149gwqk5hMIOxPcszYnLc9lnyYmbPntFj7 Ni8XTQvWfPpKD2L8KqXg/OAaAhjSOpquJnSI8uRTNE1hGZbK9pQFUd15Xp82SRr++x OryrwHjt40niZ/OtkKsyS+KGaAqcvAGlQYyCAfng= Date: Thu, 12 Aug 2021 09:24:41 +0200 From: Greg KH To: Barry Song <21cnbao@gmail.com> 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 Message-ID: References: <20210812041930.28931-1-21cnbao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210812041930.28931-1-21cnbao@gmail.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 12, 2021 at 04:19:30PM +1200, Barry Song wrote: > > 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() Ok, if this isn't easy then I guess it's not a big deal, but you should go through the MSI developers first. Why does a platform device have MSI interrupts? I thought they were only for PCI devices. thanks, greg k-h