On Thu, May 12, 2016 at 4:42 PM, Jeremy Linton jlinton@redhat.com wrote:
On 05/12/2016 02:59 PM, Peter Robinson wrote:
The ARM Juno development platform's PCIe is supported by the generic PCI host driver. Enable it so that PCIe attached peripherals work.
Pushed as (F-24 and rawhide)
http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/commit/?h=f24&id=decd...
Let me know if there's other branches you'd like it on, also let me know if there's other improvements that can be made for Juno, we've not had anyone to test so what we have is a bit of a guess so any feedback for Juno support would be useful.
Thanks those two branches should be sufficient. I have a few other tweaks to post now that I seem to have cleared some internal hurtles.
Excellent, really glad to get confirmation it's looking reasonable.
FYI: There is a dmi_match oops on boot, and the SMSC's phy state change isn't consistently detected, resulting in unreliable link detection. Plus, there is likely a grub EFI issue (there are a couple bugs floating around about that).
- dmi_match oops we've seen for a long time, it doesn't seem to cause
issues but I think it's because most devices don't actually have dmi tables (or what ever they're called) so should likely be taught to behave on absence
This machine has DMI tables, the problem is that the fedora specific watchdog-Disable-watchdog-on-virtual-machines.patch is making calls to dmi_check_system before the smbios initcall has set up the tables (AFAIK).
When is that initcall done on your platform? lockup_detector_init is called in a kthread started by the rest_init function. All of that is called after acpi_subsystem_init, sfi_init_late, efi_late_init, and efi_free_boot_services.
Also, the dmi code protects itself behind the dmi_initialized variable, so if dmi_check_system is called before dmi_scan_machine is called then nothing bad should happen. On x86, dmi_scan_machine is called from setup_arch, which is well before any of the above functions are called.
josh