On 05/13/2016 12:41 PM, Josh Boyer wrote:
On Thu, May 12, 2016 at 4:42 PM, Jeremy Linton <jlinton@xxxxxxxxxx> 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=decdd1f9105004f6e2ca24cc85bffcf6efb82d28
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).
1) 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.
Its the WARN(!dmi_initialized, KERN_ERR "dmi check: not initialized
yet.\n"); in dmi_matches that is firing.
That is because, arm64_dmi_init is a core_initcall() and ends up being
called after the watchdog/SMP setup, same on IA64 the only other
platform with a dmi_scan_machine() call. A large part of this is because
it should run after arm_enable_runtime_services, which is an
early_initcall itself.
I moved the arm64_dmi_init() call into arm_enable_runtime_services() and
removed the core_initcall(arm64_dmi_init) and that solves the problem.
Of course that will likely cause a build failure on 32-bit ARM without
some kind of stubbed out call.
_______________________________________________
kernel mailing list
kernel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/kernel@xxxxxxxxxxxxxxxxxxxxxxx
