On Tue, May 12, 2020 at 06:44:51PM +0200, Christian Nilsson wrote: > A patch was sent to the list a few hours ago in regards to PCI devices, is it > related?
I did see that come in, just as I had gotten a working patch and was actually amazed by how closely they are related. Long story short, efipci_root is only looking at PCI_SEG to determine which EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL to use. But as the other patch notes, EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL->Configure() returns a descriptor list that outlines which bus numbers each root is associated with. Because PCI_SEG is the same across this particular system, it was always incorrectly picking the first root, so attempts to read the PCI config space failed and the NIC fell back to NII. Modifying efipci_root to retrieve and compare this descriptor list allows it to actually find the correct root. Amusingly enough, it turns out that the rest of our EFI systems (mostly Dell 14th Gen) only work by blind luck because the first root is the correct one. But on these AMD systems it isn't. There is definitely overlap with the other patch which, I'll be honest, I don't fully understand. I'm primarily a kernel guy and EFI is not my thing at all (which means I'm also probably butchering the terminology). Hopefully someone who does know this stuff can comment once I can get a patch posted. > Nothing really special, I assume that you have mostly modified existing files, > so they will be released under the license already there, preferably you allow > for UBDL License: [2]https://github.com/ipxe/ipxe/blob/master/COPYING.UBDL > > There is also [3]https://secure-web.cisco.com/ > 1CihNP07LOZUmhFYqtrtoXr9BQKqFBgJjv6mJkRTOoH9w6V9fwRqrWLz3T9PfhQ24soCZN0eKYS1A9spmh3N6_V9dMx_bq-PtLgLHX790xKZ7KbueVqjwzrXQD7f2X_xyeIcA3iz7GV0N5tobvvqbB982xOJFefcy4Z2UhaWKGOv4lMOxcSeHAvpoC4F3P35E7p2xzYac_ACYKd7XCBqmlKq-JTfKi5vYGMAZPlmM7QtEtwEhHmst5MFtJVcot9jx2XO62JTbNa3j_TY-pq4_cA > /https%3A%2F%2Fipxe.org%2Flicensing > Other relevant page in regards to patches is [4]http://secure-web.cisco.com/ > 1kqGWWeaUKzwWWPQFYXTYl-KSw6daTKNYOkYOGnZmOB7qcUrolGlVvo3cRpVhxUMdXqjuGaAHJfOqDP7-RlboVp90iISPLaSIjPFM44OaMu-uDs9_iDuIVwYOs9J7ZYEvcckB025WI4nwE_8IX-uCwUB3f7LYpC1PbyhjC7tJLOkaa8M_X7FBKnH0Nm3slnY0d7PX39lOgP5GEbhq1ueWC_-T0skRMx0cSffmx9IKWwFJXJ11xfUj3s9LBSiv6qPZa8EQhBAjgT85FUphKvAKGQ > /http%3A%2F%2Fipxe.org%2Fadmin > > If you want to be on the totally safe side, please see [5]https:// > secure-web.cisco.com/ > 1eTBlZBGcRHNKBwINqiFi5Fa3UOxPD3W9t6Dq9ejaD_OJ-qCeWAnC5JAjQUPHmQtWLB1eCzNbO4xxtsl5xnLCPu5jDJuzUTYqj1hr0ywCzztTwnc7zpqnJyTJY27RjJKJJM8ZAh2kwDolgeTIJ1vmgOOEjt2Mdqy951fMbggArypOJgAsD1L-G_11wGU6sKpQ6yHC_l4Z1OEIouPn1GSuDQlFdRpjIeDrGX5gatmGndKEg8F3cXAr098GFF5RCxSspXVTyPmMeoSjYMW_5NDkGg > /https%3A%2F%2Fwww.fensystems.co.uk%2Fcontact.php > Thanks. GPLv2 and the binary policy shouldn't be a problem. Just need to make sure this isn't some uber-restrictive CLA lurking in the shadows. _______________________________________________ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
