On 08/24/18 04:23, Liu, Jing2 wrote:
> Hi Laszlo,
>
> On 8/22/2018 5:13 PM, Laszlo Ersek wrote:
>> On 08/16/18 12:43, Liu, Jing2 wrote:
>>>
>>>
>>> On 8/16/2018 3:18 PM, Gerd Hoffmann wrote:
Hi,
> + if (pci_config_readw(bdf, PCI_VENDOR_ID) !=
> PCI_VENDOR_ID_REDHAT) {
On 08/24/18 09:48, Liu, Jing2 wrote:
>
>
> On 8/24/2018 3:12 PM, Laszlo Ersek wrote:
>> On 08/24/18 04:23, Liu, Jing2 wrote:
>>> Hi Laszlo,
>>>
>>> On 8/22/2018 5:13 PM, Laszlo Ersek wrote:
On 08/16/18 12:43, Liu, Jing2 wrote:
>
>
> On 8/16/2018 3:18 PM, Gerd Hoffmann wrote:
On 8/24/2018 4:02 PM, Laszlo Ersek wrote:
On 08/24/18 09:48, Liu, Jing2 wrote:
[...]
+ if (pci_config_readw(bdf, PCI_VENDOR_ID) !=
PCI_VENDOR_ID_REDHAT) {
+ dprintf(1, "PCI: QEMU resource reserve cap vendor ID
doesn't
match.\n");
I'd suggest to use a higher debug level for this
On 8/24/2018 3:12 PM, Laszlo Ersek wrote:
On 08/24/18 04:23, Liu, Jing2 wrote:
Hi Laszlo,
On 8/22/2018 5:13 PM, Laszlo Ersek wrote:
On 08/16/18 12:43, Liu, Jing2 wrote:
On 8/16/2018 3:18 PM, Gerd Hoffmann wrote:
Hi,
+ if (pci_config_readw(bdf, PCI_VENDOR_ID) !=
On 8/24/2018 3:12 PM, Laszlo Ersek wrote:
On 08/24/18 04:23, Liu, Jing2 wrote:
Hi Laszlo,
On 8/22/2018 5:13 PM, Laszlo Ersek wrote:
On 08/16/18 12:43, Liu, Jing2 wrote:
On 8/16/2018 3:18 PM, Gerd Hoffmann wrote:
Hi,
+ if (pci_config_readw(bdf, PCI_VENDOR_ID) !=
On Fri, Aug 24, 2018 at 09:12:47AM +0200, Laszlo Ersek wrote:
> On 08/24/18 04:23, Liu, Jing2 wrote:
> > Hi Laszlo,
> >
> > On 8/22/2018 5:13 PM, Laszlo Ersek wrote:
> >> On 08/16/18 12:43, Liu, Jing2 wrote:
> >>>
> >>>
> >>> On 8/16/2018 3:18 PM, Gerd Hoffmann wrote:
> Hi,
>
>
On 08/24/18 10:53, Jing Liu wrote:
> Enable the firmware recognizing RedHat legacy PCI bridge device ID,
> so QEMU can reserve additional PCI bridge resource capability.
> Change the debug level lower to 3 when it is non-QEMU bridge.
>
> Signed-off-by: Jing Liu
> ---
> src/fw/pciinit.c | 50
Hi Gerd,
On 8/24/2018 4:24 PM, Gerd Hoffmann wrote:
I imagine you'd post v3 with the update Gerd requested for the debug
level(s), and then I'd respond with my R-b. (Obviously I'm not a SeaBIOS
maintainer so that'll not be "decisive" by any means.)
Oh, BTW, I am considering, if only dismatch
Enable the firmware recognizing RedHat legacy PCI bridge device ID,
so QEMU can reserve additional PCI bridge resource capability.
Change the debug level lower to 3 when it is non-QEMU bridge.
Signed-off-by: Jing Liu
---
src/fw/pciinit.c | 50 +-
This patch serial is about QEMU resource reserve capability finding
in firmware.
Firstly, this fixes a logic bug. When the capability is truncated,
return zero instead of the truncated offset. Secondly, this modified
the debug messages when the capability is not found and when the vendor
ID or
Return zero when finding truncated capability.
Signed-off-by: Jing Liu
---
src/fw/pciinit.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
index 3a2f747..d2cea2b 100644
--- a/src/fw/pciinit.c
+++ b/src/fw/pciinit.c
@@ -539,6 +539,7 @@ static u8
Improve the debug message when QEMU resource reserve cap
is not found and when the vendor-id or device-id does't match
REDHAT special ones.
Signed-off-by: Jing Liu
---
src/fw/pciinit.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
> > I imagine you'd post v3 with the update Gerd requested for the debug
> > level(s), and then I'd respond with my R-b. (Obviously I'm not a SeaBIOS
> > maintainer so that'll not be "decisive" by any means.)
> >
> Oh, BTW, I am considering, if only dismatch vendor-id stands for
> "non-qemu
On Fri, Aug 24, 2018 at 09:01:03AM -0400, Chris wrote:
> I know it has been months but I just had an idea that seems to fix
> this issue. I still need to test for some time to make sure but so far
> it is working fine.
>
> What I did is simply add a delay before the SD card is initialized.
> The
On Fri, Aug 24, 2018 at 10:28 AM, Kevin O'Connor wrote:
> On Fri, Aug 24, 2018 at 09:48:27AM -0400, Chris wrote:
>> On Fri, Aug 24, 2018 at 9:28 AM, Chris wrote:
>> > So far it has worked on the first attempt every time. So it needs only
>> > the delay and nothing else.
>> >
>> > I still need to
On Fri, Aug 24, 2018 at 9:28 AM, Chris wrote:
> So far it has worked on the first attempt every time. So it needs only
> the delay and nothing else.
>
> I still need to test with all my SD cards. Though I only have a 64GB
> Sandisk and a handful of 32GB Samsung. The question is whether or not
>
I know it has been months but I just had an idea that seems to fix
this issue. I still need to test for some time to make sure but so far
it is working fine.
What I did is simply add a delay before the SD card is initialized.
The attached patch takes a brute force approach and will attempt to
On Fri, Aug 24, 2018 at 9:13 AM, Kevin O'Connor wrote:
> On Fri, Aug 24, 2018 at 09:01:03AM -0400, Chris wrote:
>> I know it has been months but I just had an idea that seems to fix
>> this issue. I still need to test for some time to make sure but so far
>> it is working fine.
>>
>> What I did
On Fri, Aug 24, 2018 at 09:48:27AM -0400, Chris wrote:
> On Fri, Aug 24, 2018 at 9:28 AM, Chris wrote:
> > So far it has worked on the first attempt every time. So it needs only
> > the delay and nothing else.
> >
> > I still need to test with all my SD cards. Though I only have a 64GB
> >
19 matches
Mail list logo
