Linux Media Controller development
 help / color / mirror / Atom feed
From: Dongdong Liu <liudongdong3@huawei.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: <hch@infradead.org>, <kw@linux.com>, <logang@deltatee.com>,
	<leon@kernel.org>, <linux-pci@vger.kernel.org>,
	<rajur@chelsio.com>, <hverkuil-cisco@xs4all.nl>,
	<linux-media@vger.kernel.org>, <netdev@vger.kernel.org>
Subject: Re: [PATCH V10 4/8] PCI/sysfs: Add a 10-Bit Tag sysfs file PCIe Endpoint devices
Date: Thu, 28 Oct 2021 15:44:49 +0800	[thread overview]
Message-ID: <29edb35a-4c46-8b5d-26e5-debf6b3a72bc@huawei.com> (raw)
In-Reply-To: <20211027222839.GA252933@bhelgaas>

Hi Bjorn

Many thanks for your review.
On 2021/10/28 6:28, Bjorn Helgaas wrote:
> 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?

All PCIe completers are required to support 8-bit tags
from the "[PATCH] PCI: enable extended tags support for PCIe endpoints"
(https://patchwork.kernel.org/project/linux-arm-msm/patch/1474769434-5756-1-git-send-email-okaya@codeaurora.org/).

I ask hardware colleagues, also says all PCIe devices should support
8-bit tags completer default, so seems no need to do this for 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().
Yes, will do.

Thanks,
Dongdong
> Or even better, if the name doesn't start with a digit, DEVICE_ATTR_RW().
> .
>

  reply	other threads:[~2021-10-28  7:45 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-09 10:49 [PATCH V10 0/8] PCI: Enable 10-Bit tag support for PCIe devices Dongdong Liu
2021-10-09 10:49 ` [PATCH V10 1/8] PCI: Use cached devcap in more places Dongdong Liu
2021-10-09 10:49 ` [PATCH V10 2/8] PCI: Cache Device Capabilities 2 Register Dongdong Liu
2021-10-09 10:49 ` [PATCH V10 3/8] PCI: Add 10-Bit Tag register definitions Dongdong Liu
2021-10-09 10:49 ` [PATCH V10 4/8] PCI/sysfs: Add a 10-Bit Tag sysfs file PCIe Endpoint devices Dongdong Liu
2021-10-27 22:28   ` Bjorn Helgaas
2021-10-28  7:44     ` Dongdong Liu [this message]
2021-10-28 17:24       ` Bjorn Helgaas
2021-10-29  7:16         ` Dongdong Liu
2021-10-09 10:49 ` [PATCH V10 5/8] PCI/IOV: Add 10-Bit Tag sysfs files for VF devices Dongdong Liu
2021-10-09 10:49 ` [PATCH V10 6/8] PCI/P2PDMA: Add a 10-Bit Tag check in P2PDMA Dongdong Liu
2021-10-27 21:20   ` Bjorn Helgaas
2021-10-28  7:56     ` Dongdong Liu
2021-10-27 23:11   ` Bjorn Helgaas
2021-10-27 23:41     ` Logan Gunthorpe
2021-10-28  1:39       ` Bjorn Helgaas
2021-10-28 15:56         ` Logan Gunthorpe
2021-10-09 10:49 ` [PATCH V10 7/8] PCI: Enable 10-Bit Tag support for PCIe Endpoint device Dongdong Liu
2021-10-09 10:49 ` [PATCH V10 8/8] PCI/IOV: Enable 10-Bit Tag support for PCIe VF devices Dongdong Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=29edb35a-4c46-8b5d-26e5-debf6b3a72bc@huawei.com \
    --to=liudongdong3@huawei.com \
    --cc=hch@infradead.org \
    --cc=helgaas@kernel.org \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=kw@linux.com \
    --cc=leon@kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=logang@deltatee.com \
    --cc=netdev@vger.kernel.org \
    --cc=rajur@chelsio.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox