[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211027222839.GA252933@bhelgaas>
Date: Wed, 27 Oct 2021 17:28:39 -0500
From: Bjorn Helgaas <helgaas@...nel.org>
To: Dongdong Liu <liudongdong3@...wei.com>
Cc: hch@...radead.org, kw@...ux.com, logang@...tatee.com,
leon@...nel.org, linux-pci@...r.kernel.org, rajur@...lsio.com,
hverkuil-cisco@...all.nl, linux-media@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: [PATCH V10 4/8] PCI/sysfs: Add a 10-Bit Tag sysfs file PCIe
Endpoint devices
On Sat, Oct 09, 2021 at 06:49:34PM +0800, Dongdong Liu wrote:
> PCIe spec 5.0 r1.0 section 2.2.6.2 says:
>
> If an Endpoint supports sending Requests to other Endpoints (as
> opposed to host memory), the Endpoint must not send 10-Bit Tag
> Requests to another given Endpoint unless an implementation-specific
> mechanism determines that the Endpoint supports 10-Bit Tag Completer
> capability.
>
> Add a 10bit_tag sysfs file, write 0 to disable 10-Bit Tag Requester
> when the driver does not bind the device. The typical use case is for
> p2pdma when the peer device does not support 10-Bit Tag Completer.
> Write 1 to enable 10-Bit Tag Requester when RC supports 10-Bit Tag
> Completer capability. The typical use case is for host memory targeted
> by DMA Requests. The 10bit_tag file content indicate current status of
> 10-Bit Tag Requester Enable.
Don't we have a hole here? We're adding knobs to control 10-Bit Tag
usage, but don't we have basically the same issues with Extended
(8-bit) Tags?
I wonder if we should be adding a more general "tags" file that can
manage both 8-bit and 10-bit tag usage.
> +static struct device_attribute dev_attr_10bit_tag = __ATTR(10bit_tag, 0644,
> + pci_10bit_tag_show,
> + pci_10bit_tag_store);
I think this should use DEVICE_ATTR(). Or even better, if the name
doesn't start with a digit, DEVICE_ATTR_RW().
Powered by blists - more mailing lists