Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755151AbbKCQ4W (ORCPT ); Tue, 3 Nov 2015 11:56:22 -0500 Received: from mout.kundenserver.de ([212.227.126.131]:51580 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751549AbbKCQ4T (ORCPT ); Tue, 3 Nov 2015 11:56:19 -0500 From: Arnd Bergmann To: Sinan Kaya Cc: Tomasz Nowicki , Lorenzo Pieralisi , bhelgaas@google.com, will.deacon@arm.com, catalin.marinas@arm.com, rjw@rjwysocki.net, hanjun.guo@linaro.org, jiang.liu@linux.intel.com, robert.richter@caviumnetworks.com, Narinder.Dhillon@caviumnetworks.com, ddaney@caviumnetworks.com, Liviu.Dudau@arm.com, tglx@linutronix.de, wangyijing@huawei.com, Suravee.Suthikulpanit@amd.com, msalter@redhat.com, linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, linaro-acpi@lists.linaro.org Subject: Re: [PATCH V1 11/11] arm64, pci, acpi: Support for ACPI based PCI hostbridge init Date: Tue, 03 Nov 2015 17:55:17 +0100 Message-ID: <3736182.0iiYWufyXZ@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <5638E1CE.9000805@codeaurora.org> References: <1445963922-22711-1-git-send-email-tn@semihalf.com> <5802577.H74A3Lg5B3@wuerfel> <5638E1CE.9000805@codeaurora.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:WCAgdqw1U1KAJHuJ2iQEJCANawgpMPXw4rNkZko+CZYasps83FF B5HPFfSWgDbPJjEmUNW8g6WjMxWXG+Q60LvlqeHYz9cFeIQD5um+g2eL3iycQmN0crR5BXh sgjpP/hKbuWow/2Daq7X3Dw7UFcsfcq3d3WF9pW4yd8VfAFp6c/0ou3G6yWMj3ML1pJbuCN LugwVGRAw2PcCxy+e5yYw== X-UI-Out-Filterresults: notjunk:1;V01:K0:5ald3PWlOYo=:psxZUetp5uO8U2wwFwA2OC ZJHYsjMta4S2bt0OkWwgKBiQi4zuGKnEPsYIjBk1bA7z3utifIo3Pvgbs6QRfU6RGFzjT+uVp TwJPH4XI2OOIFpJfDXQaQKWWc1pXsjyN0Th/tfjgj9y0S+Eaecpov7oY0DgrcUbWx0eph5aCF c7e8wGz9O5K/b5mvB8IipdtnD19LCadlMJ6kMAA8J+FE/1OBecApFtxySLWnCLAfca+T9Q/0O G4kAMc6qD0SbPanEfLmyDoS9s1zAgddkB42bIOLVzPxQ8rxK7IAXd94NNiAlHueHPGvDBN8aU JhfDpjfhjWNtascCxfePjXsaNnzKtmElkvXxGJCS+L4EY+F4k49NUTW6K20UmY3sem9QjblQY yzFAa0VMcDdQvbO5xkFXWmrPQZJLfdEAIXZp41wGQXZlgmbZJsFHADcPUzrqV3YfKGZ8CL0pm 45Ud7BIQjvTGwV8RYzcgaNe2Ln0uwemShvsupPAihn/iaOxyFOpc61jeY091ydRgWqKpy7f0D G9aYhEcLMZRYQC6Qa93Np8+BjyemH/hDJJofXbFUcvPZiBRz8dk8N62EX1Mr/bvL+dlBbYq/z cyKss0+MlMyetxMq0Fh8/EoUKof0X+SCHPtZkeJtaY6f5+TDx74zAFLIFbPp2UHqygb7fet3U oJiawO2p/CKwAGYI3bgZr7TMqExebdjFYy5mgJG5xwERW3JdrEoxQRjks0Pr/D8mpMQo/795r hQSFR9CuogAzSdoR Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1999 Lines: 44 On Tuesday 03 November 2015 11:33:18 Sinan Kaya wrote: > > On 11/3/2015 10:59 AM, Arnd Bergmann wrote: > > On Tuesday 03 November 2015 10:10:21 Sinan Kaya wrote: > >> > >> I don't see anywhere in the SBSA spec addendum that the PCI > >> configuration space section that unaligned accesses *MUST* be supported. > >> > >> If this is required, please have this info added to the spec. I can work > >> with the designers for the next chip. > >> > >> Unaligned access on the current hardware returns incomplete values or > >> can cause bus faults. The behavior is undefined. > > > > Unaligned accesses are not allowed, but any PCI compliant device must > > support aligned 1, 2 or 4 byte accesses on its configuration space, > > though the byte-enable mechanism. In an ECAM host bridge, those are > > mapped to load/store accesses from the CPU with the respective width > > and natural alignment. > > As far as I see, the endpoints do not have any problems with unaligned > accesses. It is the host bridge itself (stuff that doesn't get on the > PCIe bus and uses traditional AXI kind bus internally) has problems with > alignment. > > If Linux is expecting all HW vendors to implement alignment support, > this needs to be put in the SBSA spec as a hard requirement. As I said, it's not unaligned accesses at all, just 1-byte and aligned 2-byte accesses, and it's not Linux mandating this but the PCI spec. Please read Russell's email again, it is not possible for PCI to work according to the specification unless the host bridge allows sub-32-bit accesses. You can probably work around this by using the legacy I/O port method rather than ECAM, if the PCI host bridge itself is functional and just the host bus it is connected to is buggy. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/