[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <587C61B3.3070107@ti.com>
Date: Mon, 16 Jan 2017 11:31:23 +0530
From: Kishon Vijay Abraham I <kishon@...com>
To: Christoph Hellwig <hch@...radead.org>
CC: Bjorn Helgaas <bhelgaas@...gle.com>,
Jingoo Han <jingoohan1@...il.com>,
Joao Pinto <Joao.Pinto@...opsys.com>,
Arnd Bergmann <arnd@...db.de>, <linux-pci@...r.kernel.org>,
<linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<devicetree@...r.kernel.org>, <linux-omap@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-samsung-soc@...r.kernel.org>,
<linuxppc-dev@...ts.ozlabs.org>, <linux-arm-kernel@...s.com>,
<linux-arm-msm@...r.kernel.org>, <nsekhar@...com>
Subject: Re: [PATCH 16/37] PCI: endpoint: Introduce configfs entry for
configuring EP functions
Hi Christoph,
On Friday 13 January 2017 11:36 PM, Christoph Hellwig wrote:
> Hi Kishon,
>
> a couple comments on the configfs layout based on my experiments with
> your previous drop to implement a NVMe device using it.
Thanks for trying it out!
>
> I don't think most of these configfs files should be present here, as
> they are properties of the implemented PCIe devices. E.g. for my
> NVMe device they will be sort of hardcoded most of the time, as they
> would be for other devices that would always have a fixed vendor/device/
> class ID, cacheline size, etc.
Actually not all devices have hardcoded headers. E.g the platform I'm using
doesn't have hardcoded headers and it can be configured based on the function
the user would like to use. If the devices are hardcoded, then using configfs
can be skipped altogether. In such cases, APIs like pci_epf_create() can
directly be used by the drivers instead of going via configfs.
Thanks
Kishon
Powered by blists - more mailing lists