linux-kernel - Re: [PATCH v4 06/10] PCI: brcmstb: Enable external MSI-X if available

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: <ab136131-a306-4344-adaf-904e3b32326e@suse.de>
Date: Wed, 18 Dec 2024 16:54:57 +0200
From: Stanimir Varbanov <svarbanov@...e.de>
To: James Quinlan <james.quinlan@...adcom.com>,
 Stanimir Varbanov <svarbanov@...e.de>, linux-kernel@...r.kernel.org,
 devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-rpi-kernel@...ts.infradead.org, linux-pci@...r.kernel.org,
 Broadcom internal kernel review list <bcm-kernel-feedback-list@...adcom.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Florian Fainelli <florian.fainelli@...adcom.com>,
 Jim Quinlan <jim2101024@...il.com>,
 Nicolas Saenz Julienne <nsaenz@...nel.org>,
 Bjorn Helgaas <bhelgaas@...gle.com>,
 Lorenzo Pieralisi <lpieralisi@...nel.org>, kw@...ux.com,
 Philipp Zabel <p.zabel@...gutronix.de>,
 Andrea della Porta <andrea.porta@...e.com>,
 Phil Elwell <phil@...pberrypi.com>, Jonathan Bell <jonathan@...pberrypi.com>
Subject: Re: [PATCH v4 06/10] PCI: brcmstb: Enable external MSI-X if available

Hi Jim,

Thanks for comments!

On 12/11/24 10:01 PM, James Quinlan wrote:
> On 10/25/24 08:45, Stanimir Varbanov wrote:
>> On RPi5 there is an external MIP MSI-X interrupt controller
>> which can handle up to 64 interrupts.
>>
>> Signed-off-by: Stanimir Varbanov <svarbanov@...e.de>
>> ---
>> v3 -> v4:
>>   - no changes.
>>
>>   drivers/pci/controller/pcie-brcmstb.c | 63 +++++++++++++++++++++++++--
>>   1 file changed, 59 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/
>> controller/pcie-brcmstb.c
>> index c01462b07eea..af01a7915c94 100644
>> --- a/drivers/pci/controller/pcie-brcmstb.c
>> +++ b/drivers/pci/controller/pcie-brcmstb.c
>> @@ -1318,6 +1318,52 @@ static int brcm_pcie_start_link(struct
>> brcm_pcie *pcie)
>>       return 0;
>>   }
>>   +static int brcm_pcie_enable_external_msix(struct brcm_pcie *pcie,
>> +                      struct device_node *msi_np)
>> +{
>> +    struct inbound_win inbound_wins[PCIE_BRCM_MAX_INBOUND_WINS];
>> +    u64 msi_pci_addr, msi_phys_addr;
>> +    struct resource r;
>> +    int mip_bar, ret;
>> +    u32 val, reg;
>> +
>> +    ret = of_property_read_reg(msi_np, 1, &msi_pci_addr, NULL);
>> +    if (ret)
>> +        return ret;
>> +
>> +    ret = of_address_to_resource(msi_np, 0, &r);
>> +    if (ret)
>> +        return ret;
>> +
>> +    msi_phys_addr = r.start;
>> +
>> +    /* Find free inbound window for MIP access */
>> +    mip_bar = brcm_pcie_get_inbound_wins(pcie, inbound_wins);
>> +    if (mip_bar < 0)
>> +        return mip_bar;
>> +
>> +    mip_bar += 1;
>> +    reg = brcm_bar_reg_offset(mip_bar);
>> +
>> +    val = lower_32_bits(msi_pci_addr);
>> +    val |= brcm_pcie_encode_ibar_size(SZ_4K);
>> +    writel(val, pcie->base + reg);
>> +
>> +    val = upper_32_bits(msi_pci_addr);
>> +    writel(val, pcie->base + reg + 4);
>> +
>> +    reg = brcm_ubus_reg_offset(mip_bar);
>> +
>> +    val = lower_32_bits(msi_phys_addr);
>> +    val |= PCIE_MISC_UBUS_BAR1_CONFIG_REMAP_ACCESS_EN_MASK;
>> +    writel(val, pcie->base + reg);
>> +
>> +    val = upper_32_bits(msi_phys_addr);
>> +    writel(val, pcie->base + reg + 4);
> 
> Hi Stan,
> 
> It looks like all this is doing is setting up an identity-mapped inbound
> window, is that correct?  If so, couldn't you get the same effect by
> adding an identity-mapped dma-range in the PCIe DT node?

Yes, that approach could work, I verified it.

Do you want me to drop this patch from the series and make the relevant
changes in PCIe dma-ranges properties?

~Stan