linux-kernel - Re: [PATCH v1 5/5] pci: keystone: add pcie driver based on designware core driver

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>] [day] [month] [year] [list]

Message-ID: <20140526233132.GA12179@obsidianresearch.com>
Date:	Mon, 26 May 2014 17:31:32 -0600
From:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To:	Murali Karicheri <m-karicheri2@...com>
Cc:	Arnd Bergmann <arnd@...db.de>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"Strashko, Grygorii" <grygorii.strashko@...com>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	Jingoo Han <jg1.han@...sung.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Shilimkar, Santosh" <santosh.shilimkar@...com>,
	Mohit Kumar <mohit.kumar@...com>,
	Bjorn Helgaas <bhelgaas@...gle.com>
Subject: Re: [PATCH v1 5/5] pci: keystone: add pcie driver based on
 designware core driver

On Thu, May 22, 2014 at 06:20:19PM -0400, Murali Karicheri wrote:

>> What is the MPSS?
> 
>    MPS published in DEV CAP is 1 (256 bytes). In our IP for some reason,
>    mrss is set to 2 though IP
>    support only 256 bytes. I am trying to resolve this with IP team. If
>    this is an IP issue, then
>    software will overwrite this to 1.

The MRSS of the root port bridge is very rarely used, it is OK to be
larger than the MPS, but I'm not sure it makes much sense as a
default.

>    So the mps  will not get written to mrss for performance mode. So the
>    check seems not right. It should be changed to

So, looking at this more closely, the MRRS does not *have* to be
smaller than the MPS, but it probably performs better if it is.

I think that reflects what the code is doing.

The fact your root complex can't segment replies is a serious defect,
and there is no infrastructure to support that in the kernel.

Adding something to this generic code might be your best option to
cover the majority of cases.

It would also be good to know for sure that it can correctly segment a
256 byte read into 128 byte packets, and that only 512 is mishandled.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/