This patch serial is about QEMU resource reserve capability finding
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 device Id doesn't match REDHAT special ones.
Last, this enables the firmware recongizing the REDHAT PCI BRIDGE device ID,
and changes the debug level to 3 when it is non-qemu bridge.
v2 -> v1
* Add two patches for fixing small bugs
v3 -> v2
* Change the debug level
Jing Liu (3):
pci: fix the return value for truncated capability
pci: clean up the debug message for pci capability found
pci: recognize RH PCI legacy bridge resource reservation capability
src/fw/pciinit.c | 45 ++++++++++++++++++++++++++++-----------------
src/hw/pci_ids.h | 1 +
2 files changed, 29 insertions(+), 17 deletions(-)
On Fri, Aug 24, 2018 at 10:45:55AM -0400, Chris wrote:
> On Fri, Aug 24, 2018 at 10:28 AM, Kevin O'Connor <kevin(a)koconnor.net> wrote:
> > On Fri, Aug 24, 2018 at 09:48:27AM -0400, Chris wrote:
> >> On Fri, Aug 24, 2018 at 9:28 AM, Chris <coderight(a)gmail.com> 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
> >> > the delay is dependent on the card type or if it's just the controller
> >> > that needs to stabilize.
> >> OK, I tested all the cards I have and everything works. Attached is
> >> the simplified patch. Hopefully someone can test other cards. I'm
> >> interested to know if 128+GB and 16GB works.
> > Thanks. If you increase SDHCI_POWER_ON_TIME instead, does that also
> > work?
> > -Kevin
> Yes. Seems to work the same so far using the same delay (5).
Thanks. I committed this change.