lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7eb9fedc-67c9-4886-9470-d747273f136c@163.com>
Date: Fri, 14 Feb 2025 16:23:33 +0800
From: Hans Zhang <18255117159@....com>
To: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
Cc: lpieralisi@...nel.org, kw@...ux.com, robh@...nel.org,
 bhelgaas@...gle.com, bwawrzyn@...co.com, cassel@...nel.org,
 wojciech.jasko-EXT@...tinental-corporation.com, a-verma1@...com,
 linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org, rockswang7@...il.com
Subject: Re: [v3] PCI: cadence: Fix sending message with data or without data



On 2025/2/14 15:30, Manivannan Sadhasivam wrote:
> On Fri, Feb 07, 2025 at 06:39:23PM +0800, Hans Zhang wrote:
>> View from cdns document cdn_pcie_gen4_hpa_axi_ips_ug_v1.04.pdf.
>> In section 9.1.7.1 AXI Subordinate to PCIe Address Translation
>> Registers below:
>>
>> axi_s_awaddr bits 16 is 1 for MSG with data and 0 for MSG without data.
>>
>> Signed-off-by: hans.zhang <18255117159@....com>
>> ---
>> Changes since v1-v2:
>> - Change email number and Signed-off-by
>> ---
>>   drivers/pci/controller/cadence/pcie-cadence-ep.c | 3 +--
>>   drivers/pci/controller/cadence/pcie-cadence.h    | 2 +-
>>   2 files changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/pci/controller/cadence/pcie-cadence-ep.c b/drivers/pci/controller/cadence/pcie-cadence-ep.c
>> index e0cc4560dfde..0bf4cde34f51 100644
>> --- a/drivers/pci/controller/cadence/pcie-cadence-ep.c
>> +++ b/drivers/pci/controller/cadence/pcie-cadence-ep.c
>> @@ -352,8 +352,7 @@ static void cdns_pcie_ep_assert_intx(struct cdns_pcie_ep *ep, u8 fn, u8 intx,
>>   	spin_unlock_irqrestore(&ep->lock, flags);
>>   
>>   	offset = CDNS_PCIE_NORMAL_MSG_ROUTING(MSG_ROUTING_LOCAL) |
>> -		 CDNS_PCIE_NORMAL_MSG_CODE(msg_code) |
>> -		 CDNS_PCIE_MSG_NO_DATA;
>> +		 CDNS_PCIE_NORMAL_MSG_CODE(msg_code);
>>   	writel(0, ep->irq_cpu_addr + offset);
>>   }
>>   
>> diff --git a/drivers/pci/controller/cadence/pcie-cadence.h b/drivers/pci/controller/cadence/pcie-cadence.h
>> index f5eeff834ec1..39ee9945c903 100644
>> --- a/drivers/pci/controller/cadence/pcie-cadence.h
>> +++ b/drivers/pci/controller/cadence/pcie-cadence.h
>> @@ -246,7 +246,7 @@ struct cdns_pcie_rp_ib_bar {
>>   #define CDNS_PCIE_NORMAL_MSG_CODE_MASK		GENMASK(15, 8)
>>   #define CDNS_PCIE_NORMAL_MSG_CODE(code) \
>>   	(((code) << 8) & CDNS_PCIE_NORMAL_MSG_CODE_MASK)
>> -#define CDNS_PCIE_MSG_NO_DATA			BIT(16)
>> +#define CDNS_PCIE_MSG_DATA			BIT(16)
> 
> Oops! So how did you spot the issue? Did INTx triggering ever worked? RC should
> have reported it as malformed TLP isn't it?
> 
In our first generation SOC, sending messages did not work, and the 
length of messages was all 1. Cadence fixed this problem in the second 
generation SOC. And I have verified in the EMU environment that it is OK 
to send various messages, including INTx.

And that's what Cadence's release documentation says:
axi_s_awaddr bits 16 is 1 for MSG with data and 0 for MSG without data.
The final verification results are also consistent with the 
documentation description.

Due to the RTL bug in Cadence IP of our SOC in the first generation, the 
AER Error reported at that time was Unsupported Request Error Status.

Best regards
Hans


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ