Move dmi_scan_machine() call ealier

I'd like to move our call to dmi_scan_machine up earlier in the boot
process so that we can take advantage of a DMI hook, called out of acpi_early_init, to enable _OSI(Linux) on Xen HVM domains. Since the SMBIOS parsing makes use of ioremap, which Bjorn pointed out is fragile early in boot, I'm reluctant to move this too much earlier. Given those restrictions, it seems best to simply move this up into our check_bugs function. Since the DMI hooks are mainly used for adjusting code path based on platform, it doesn't seem like such an unreasonable place to set it up. Please let me know if you have comments. Thanks,

Alex

Signed-off-by Alex Williamson <[email protected]>

--

diff -r c7f1be4e5832 arch/ia64/kernel/setup.c

arch/ia64/kernel/setup.c +1 -8

@@ -982,11 +982,5 @@ check_bugs (void)
 {
 	ia64_patch_mckinley_e9((unsigned long) __start___mckinley_e9_bundles,
 			       (unsigned long) __end___mckinley_e9_bundles);
-}
-
-static int __init run_dmi_scan(void)
-{
 	dmi_scan_machine();
-	return 0;
-}
-core_initcall(run_dmi_scan);
+}
 
 
-

To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 10 lines · Alex Williamson

I'd like to move our call to dmi_scan_machine up earlier in the boot
process so that we can take advantage of a DMI hook, called out of acpi_early_init, to enable _OSI(Linux) on Xen HVM domains. Since the SMBIOS parsing makes use of ioremap, which Bjorn pointed out is fragile early in boot, I'm reluctant to move this too much earlier. Given those restrictions, it seems best to simply move this up into our check_bugs function. Since the DMI hooks are mainly used for adjusting code path based on platform, it doesn't seem like such an unreasonable place to set it up. Please let me know if you have comments. Thanks,

I guess if that works then its ok. But if a name is worth anything, I don't think check_bugs() really encompases the behaviour of run_dmi_scan().

Also, you should probably fix up the comment in run_dmi_scan() that says it is run as a core_initcall().

Thanks for the review Simon. Is the patch below more like what
you're thinking? I agree that check_bugs doesn't initial seem like the most appropriate place to setup DMI, but think about what DMI is typically used for in the kernel.

Quoted 4 lines

Thanks for the review Simon. Is the patch below more like what
you're thinking? I agree that check_bugs doesn't initial seem like the most appropriate place to setup DMI, but think about what DMI is typically used for in the kernel.

Then re-name check_bugs() to something more suited to the things that it is now doing. [I think that was what Simon was hinting at].

Quoted 12 lines · Simon Horman

Quoted 10 lines · Alex Williamson

I'd like to move our call to dmi_scan_machine up earlier in the boot
process so that we can take advantage of a DMI hook, called out of acpi_early_init, to enable _OSI(Linux) on Xen HVM domains. Since the SMBIOS parsing makes use of ioremap, which Bjorn pointed out is fragile early in boot, I'm reluctant to move this too much earlier. Given those restrictions, it seems best to simply move this up into our check_bugs function. Since the DMI hooks are mainly used for adjusting code path based on platform, it doesn't seem like such an unreasonable place to set it up. Please let me know if you have comments. Thanks,

Quoted 6 lines

I guess if that works then its ok. But if a name is worth anything, I don't think check_bugs() really encompases the behaviour of run_dmi_scan().

Also, you should probably fix up the comment in run_dmi_scan() that says it is run as a core_initcall().

Thanks for the review Simon. Is the patch below more like what
you're thinking? I agree that check_bugs doesn't initial seem like the most appropriate place to setup DMI, but think about what DMI is typically used for in the kernel. Mostly quirks and identifying systems that need something special. Without creating a safer early ioremap, the range of places to call this is fairly small. If you see a better spot, please suggest it. I'm not sure what an early ioremap should look like on ia64 to deal with all the cases that our normal ioremap does. Thanks,

Alex

Signed-off-by Alex Williamson <[email protected]>

--

diff -r 99bc021994c4 arch/ia64/kernel/setup.c

arch/ia64/kernel/setup.c +1 -7

@@ -982,11 +982,5 @@ check_bugs (void)
 {
 	ia64_patch_mckinley_e9((unsigned long) __start___mckinley_e9_bundles,
 			       (unsigned long) __end___mckinley_e9_bundles);
-}
-
-static int __init run_dmi_scan(void)
-{
 	dmi_scan_machine();
-	return 0;
-}
-core_initcall(run_dmi_scan);
+}

diff -r 99bc021994c4 drivers/firmware/dmi_scan.c

drivers/firmware/dmi_scan.c +2 -2

@@ -302,8 +302,8 @@ void __init dmi_scan_machine(void)
 		if (efi.smbios = EFI_INVALID_TABLE_ADDR)
 			goto out;
 
-		/* This is called as a core_initcall() because it isn't
-		 * needed during early boot.  This also means we can
+		/* This is called later in bootup, when normal
+		 * ioremap is available.  This means we can
 		 * iounmap the space when we're done with it.
 		 */
 		p = dmi_ioremap(efi.smbios, 32);

Quoted 5 lines · Tony

Quoted 4 lines

Thanks for the review Simon. Is the patch below more like what
you're thinking? I agree that check_bugs doesn't initial seem like the most appropriate place to setup DMI, but think about what DMI is typically used for in the kernel.

Quoted 2 lines

Then re-name check_bugs() to something more suited to the things that it is now doing. [I think that was what Simon was hinting at].

Re-naming check_bugs() becomes a cross architecture endeavor. Since
x86 calls dmi_scan_machine() in setup_arch(), this would only be for ia64. Perhaps the right answer is to make dmi_scan_machine() callable from setup_arch() on ia64, but that requires an safer early ioremap, and I'm still not sure what that should look like. Thanks,