linux-kernel - Re: [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case

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: <CAKv+Gu8x0j-O3WPE7Cvi4oX5J5Cq1vUhDNB_UdjE88eQh83DDA@mail.gmail.com>
Date:   Thu, 14 Sep 2017 07:06:58 -0700
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Gabriele Paoloni <gabriele.paoloni@...wei.com>
Cc:     Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Hanjun Guo <hanjun.guo@...aro.org>,
        Marcin Wojtas <mw@...ihalf.com>,
        Wangyijing <wangyijing@...wei.com>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "liudongdong (C)" <liudongdong3@...wei.com>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific
 register range for ACPI case

(remove most cc's)

Hi all,

Apologies for digging up this old thread.

I am currently looking into whether it is feasible to refactor some of
the ACPI PCI quirk code we have so it can apply to more instances of
the Synopsys Designware PCIe (i.e., for Marvell and Socionext SOCs),
which all suffer from the same issue that type 0 config TLPs are not
filtered before being sent out on the link, resulting in devices
appearing multiple times.

The pci-hisi.c quirk already appears to do exactly what would solve
the problem on other SoCs as well. So I will try to refactor this code
into something that I could propose for upstream, while probably
getting the ARM SBSA authors to offer some guidance that this IP must
not be used for new designs.

In any case, the chances of any such changes being acceptable upstream
are probably higher if we can reuse the exact same quirk as we have
already implemented for HiSilicon, so I wonder if anyone from Huawei
could comment on some questions I have:
- Why does the config space accessor override use 32-bit accesses only
for bus #0? Is that really necessary?
- Why does the Hisi quirk use different config base addresses for bus
#0 and the other buses? Is this simply because the firmware does not
use contiguous iATU windows for bus #0 and buses #1 and up? So is
there anything mapped in the 1 MB slice at the base of the respective
256 MB mappings that generate type1 config cycles?

Having just a shared set of config space accessor overrides would
already be an improvement, given that they can be shared with a DT
based driver for this IP in ECAM mode as well.

Thanks,
Ard.