linux-kernel - Re: [PATCH v2] bus: hisi_lpc: Don't use devm_kzalloc() to allocate logical PIO range

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: <539835d3-770c-285c-0c49-ae15ceaa3079@huawei.com>
Date:   Tue, 18 Jun 2019 09:44:26 +0100
From:   John Garry <john.garry@...wei.com>
To:     Bjorn Helgaas <bhelgaas@...gle.com>
CC:     <xuwei5@...wei.com>, <linuxarm@...wei.com>, <arm@...nel.org>,
        "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
        Joe Perches <joe@...ches.com>
Subject: Re: [PATCH v2] bus: hisi_lpc: Don't use devm_kzalloc() to allocate
 logical PIO range

>>

- zhichang personal mail

>> It's now on my todo list.
>>
>> I'll need advice on how to test this for hot-pluggable host bridges.
>>
>>>
>>> Could you just move the logic_pio_register_range() call farther down
>>> in hisi_lpc_probe()?  IIUC, once logic_pio_register_range() returns,
>>> an inb() with the right port number will try to access that port, so
>>> we should be prepared for that, i.e., maybe this in the wrong order to
>>> begin with?
>>
>> No, unfortunately we can't. The reason is that we need the logical PIO
>> base for that range before we enumerate the children of that host. We
>> need that base address for "translating" the child bus addresses to
>> logical PIO addresses.
>

Hi Bjorn,

> Ah, yeah, that makes sense.  I think.  We do assume that we know all
> the MMIO and I/O port translations before enumerating devices.  It's
> *conceivable* that could be changed someday since we don't actually
> need the translations until a driver claims the device,

We actually need them before a driver claims the device.

The reason is that when we create that child platform device we set the 
device's IORESOURCE_IO resources according to the translated logic PIO 
addresses, and not the host bus address. This is what makes the host 
transparent to the child device driver.

and it would
> gain some flexibility if we didn't have to program the host bridge
> windows until we know how much space is required.  But I don't see
> that happening anytime soon.
>
> Bjorn
>
> .
>

BTW, as you may have noticed, in v3 I said I would drop this patch and 
fix it all properly.

My problem is that I need to ensure that the new logical PIO unregister 
function works ok for hot-pluggable host bridges. I need to get some way 
to test this. Advice?

Thanks,
John