On 08/14/2018 12:15 PM, Liu, Jing2 wrote:
Hi Marcel,
On 8/12/2018 3:11 PM, Marcel Apfelbaum wrote:
Hi Laszlo,
[...]
hw/pci-bridge/pci_bridge_dev.c | 20
1 file changed, 20 insertions(+)
+cap_error:
+ msi_uninit(dev);
(4) This error handler doesn't look
On 08/14/2018 12:32 PM, Liu, Jing2 wrote:
On 8/12/2018 3:11 PM, Marcel Apfelbaum wrote:
[...]
I don't know what to suggest for the new capability's
teardown, in pci_bridge_dev_exitfn() -- should we just ignore it (as
suggested by this patch)?
No, we should remove it properly.
I think
On 8/14/2018 9:27 PM, Laszlo Ersek wrote:
[...]
+cap_error:
+ msi_uninit(dev);
(4) This error handler doesn't look entirely correct; we can reach it
without having initialized MSI. (MSI setup is conditional; and even if
we attempt it, it is permitted to fail with "msi=auto".)
On 08/14/18 10:39, Liu, Jing2 wrote:
> Hi Laszlo,
> Sorry for late reply. I missed these mails because of wrong filter.
> And thanks very much for comments. My reply as belows.
>
> On 8/7/2018 8:19 PM, Laszlo Ersek wrote:
>> On 08/07/18 09:04, Jing Liu wrote:
> [...]
>>> @@ -46,6 +46,12 @@ struct
On 8/12/2018 3:11 PM, Marcel Apfelbaum wrote:
[...]
I don't know what to suggest for the new capability's
teardown, in pci_bridge_dev_exitfn() -- should we just ignore it (as
suggested by this patch)?
No, we should remove it properly.
I think it is not considered a "big" issue since
Hi Marcel,
On 8/12/2018 3:11 PM, Marcel Apfelbaum wrote:
Hi Laszlo,
[...]
hw/pci-bridge/pci_bridge_dev.c | 20
1 file changed, 20 insertions(+)
+cap_error:
+ msi_uninit(dev);
(4) This error handler doesn't look entirely correct; we can reach it
without having
Hi Laszlo,
Sorry for late reply. I missed these mails because of wrong filter.
And thanks very much for comments. My reply as belows.
On 8/7/2018 8:19 PM, Laszlo Ersek wrote:
On 08/07/18 09:04, Jing Liu wrote:
[...]
@@ -46,6 +46,12 @@ struct PCIBridgeDev {
uint32_t flags;
On 08/12/18 09:11, Marcel Apfelbaum wrote:
> On 08/07/2018 06:59 PM, Laszlo Ersek wrote:
>> First, under the label "shpc_error", we call pci_bridge_exitfn(), which
>> seems to clean up everything (checking individually for each thing to
>> clean up). Given this, I wonder why we introduced the
Hi Laszlo,
On 08/07/2018 06:59 PM, Laszlo Ersek wrote:
On 08/07/18 14:19, Laszlo Ersek wrote:
On 08/07/18 09:04, Jing Liu wrote:
Add hint to firmware (e.g. SeaBIOS) to reserve addtional
IO/MEM/PREF spaces for legacy pci-pci bridge, to enable
some pci devices hotplugging whose IO/MEM/PREF
Hi,
On 08/07/2018 03:19 PM, Laszlo Ersek wrote:
On 08/07/18 09:04, Jing Liu wrote:
Add hint to firmware (e.g. SeaBIOS) to reserve addtional
IO/MEM/PREF spaces for legacy pci-pci bridge, to enable
some pci devices hotplugging whose IO/MEM/PREF spaces
requests are larger than the ones in pci-pci
On 08/07/18 14:19, Laszlo Ersek wrote:
> On 08/07/18 09:04, Jing Liu wrote:
>> Add hint to firmware (e.g. SeaBIOS) to reserve addtional
>> IO/MEM/PREF spaces for legacy pci-pci bridge, to enable
>> some pci devices hotplugging whose IO/MEM/PREF spaces
>> requests are larger than the ones in
On 08/07/18 09:04, Jing Liu wrote:
> Add hint to firmware (e.g. SeaBIOS) to reserve addtional
> IO/MEM/PREF spaces for legacy pci-pci bridge, to enable
> some pci devices hotplugging whose IO/MEM/PREF spaces
> requests are larger than the ones in pci-pci bridge set
> by firmware.
>
>
Add hint to firmware (e.g. SeaBIOS) to reserve addtional
IO/MEM/PREF spaces for legacy pci-pci bridge, to enable
some pci devices hotplugging whose IO/MEM/PREF spaces
requests are larger than the ones in pci-pci bridge set
by firmware.
Signed-off-by: Jing Liu
---
hw/pci-bridge/pci_bridge_dev.c
13 matches
Mail list logo
