Hey Linus,
Please pull the following change since commit: 2eaa9cfdf33b8d7fb7aff27792192e0019ae8fc6:
Linus Torvalds (1):
Linux 2.6.34-rc3
which is available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/ibft-2.6.git ibft-fixes
Yinghai Lu (1):
ibft, x86: Change reserve_ibft_region() to find_ibft_region()
arch/x86/kernel/setup.c | 14 ++++++++++++--
drivers/firmware/iscsi_ibft_find.c | 11 ++++++++---
include/linux/iscsi_ibft.h | 8 ++++++--
3 files changed, 26 insertions(+), 7 deletions(-)
From: Yinghai Lu <[email protected]>
So arch code could decide the way to reserve the ibft.
And We should reserve ibft as early as possible, instead of BOOTMEM stage,
in case the table is in RAM range and is not reserved by BIOS.
move that just sfter find_smp_config()
Also when CONFIG_NO_BOOTMEM=y, We will not have reserve_bootmem() anymore
-v2: fix typo about ibft pointed by Konrad Rzeszutek Wilk <[email protected]>
Signed-off-by: Yinghai Lu <[email protected]>
Cc: Pekka Enberg <[email protected]>
Cc: Peter Jones <[email protected]>
Cc: Konrad Rzeszutek Wilk <[email protected]>
CC: Jan Beulich <[email protected]>
Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
---
arch/x86/kernel/setup.c | 14 ++++++++++++--
drivers/firmware/iscsi_ibft_find.c | 11 ++++++++---
include/linux/iscsi_ibft.h | 8 ++++++--
3 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index d76e185..580e6b3 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -608,6 +608,16 @@ static int __init setup_elfcorehdr(char *arg)
early_param("elfcorehdr", setup_elfcorehdr);
#endif
+static __init void reserve_ibft_region(void)
+{
+ unsigned long addr, size = 0;
+
+ addr = find_ibft_region(&size);
+
+ if (size)
+ reserve_early_overlap_ok(addr, addr + size, "ibft");
+}
+
#ifdef CONFIG_X86_RESERVE_LOW_64K
static int __init dmi_low_memory_corruption(const struct dmi_system_id *d)
{
@@ -910,6 +920,8 @@ void __init setup_arch(char **cmdline_p)
*/
find_smp_config();
+ reserve_ibft_region();
+
reserve_trampoline_memory();
#ifdef CONFIG_ACPI_SLEEP
@@ -977,8 +989,6 @@ void __init setup_arch(char **cmdline_p)
dma32_reserve_bootmem();
- reserve_ibft_region();
-
#ifdef CONFIG_KVM_CLOCK
kvmclock_init();
#endif
diff --git a/drivers/firmware/iscsi_ibft_find.c b/drivers/firmware/iscsi_ibft_find.c
index dfb15c0..8f5d9e2 100644
--- a/drivers/firmware/iscsi_ibft_find.c
+++ b/drivers/firmware/iscsi_ibft_find.c
@@ -52,7 +52,7 @@ EXPORT_SYMBOL_GPL(ibft_addr);
* Routine used to find the iSCSI Boot Format Table. The logical
* kernel address is set in the ibft_addr global variable.
*/
-void __init reserve_ibft_region(void)
+unsigned long __init find_ibft_region(unsigned long *sizep)
{
unsigned long pos;
unsigned int len = 0;
@@ -78,6 +78,11 @@ void __init reserve_ibft_region(void)
}
}
}
- if (ibft_addr)
- reserve_bootmem(pos, PAGE_ALIGN(len), BOOTMEM_DEFAULT);
+ if (ibft_addr) {
+ *sizep = PAGE_ALIGN(len);
+ return pos;
+ }
+
+ *sizep = 0;
+ return 0;
}
diff --git a/include/linux/iscsi_ibft.h b/include/linux/iscsi_ibft.h
index 6092487..d2e4042 100644
--- a/include/linux/iscsi_ibft.h
+++ b/include/linux/iscsi_ibft.h
@@ -42,9 +42,13 @@ extern struct ibft_table_header *ibft_addr;
* mapped address is set in the ibft_addr variable.
*/
#ifdef CONFIG_ISCSI_IBFT_FIND
-extern void __init reserve_ibft_region(void);
+unsigned long find_ibft_region(unsigned long *sizep);
#else
-static inline void reserve_ibft_region(void) { }
+static inline unsigned long find_ibft_region(unsigned long *sizep)
+{
+ *sizep = 0;
+ return 0;
+}
#endif
#endif /* ISCSI_IBFT_H */
--
1.6.2.5
On Thu, 8 Apr 2010, Konrad Rzeszutek Wilk wrote:
>
> So arch code could decide the way to reserve the ibft.
>
> And We should reserve ibft as early as possible, instead of BOOTMEM stage,
> in case the table is in RAM range and is not reserved by BIOS.
For all I know this is all perfectly fine, but I have _no_ idea about how
ibft is supposed to work, so I can't really judge it. As a result, I won't
pull it without some more acks from people who actually know what that
thing is..
Linus
On Thu, Apr 08, 2010 at 08:53:48AM -0700, Linus Torvalds wrote:
>
>
> On Thu, 8 Apr 2010, Konrad Rzeszutek Wilk wrote:
> >
> > So arch code could decide the way to reserve the ibft.
> >
> > And We should reserve ibft as early as possible, instead of BOOTMEM stage,
> > in case the table is in RAM range and is not reserved by BIOS.
>
> For all I know this is all perfectly fine, but I have _no_ idea about how
> ibft is supposed to work, so I can't really judge it. As a result, I won't
> pull it without some more acks from people who actually know what that
> thing is..
Oh, I am definitely ACK-ing. Sorry about not explicitly stating that.
The developer is Yinghai Lu, I am the co-maintainer of the iBFT driver.
Linus, would you like me to modify the commit so that it has 'Acked-by:'
by me in the git tree?
> > For all I know this is all perfectly fine, but I have _no_ idea about how
> > ibft is supposed to work, so I can't really judge it. As a result, I won't
> > pull it without some more acks from people who actually know what that
> > thing is..
>
> Oh, I am definitely ACK-ing. Sorry about not explicitly stating that.
> The developer is Yinghai Lu, I am the co-maintainer of the iBFT driver.
>
> Linus, would you like me to modify the commit so that it has 'Acked-by:'
> by me in the git tree?
I've gone ahead and done that. The git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/ibft-2.6.git
ibft-fixes.acked
has the patch that was acked (and reviewed + tested on my iBFT rig)
by me.
(The ibft-fixes has the old commit, with the Signed-off-by instead of
Acked-by).
On Thu, 8 Apr 2010, Konrad Rzeszutek Wilk wrote:
>
> Oh, I am definitely ACK-ing. Sorry about not explicitly stating that.
> The developer is Yinghai Lu, I am the co-maintainer of the iBFT driver.
>
> Linus, would you like me to modify the commit so that it has 'Acked-by:'
> by me in the git tree?
No, no, a sign-off is already an ack, and is "stronger" than an ack, since
it actually also means that you send it onwards. A patch that you don't
like you would obviously never sign off on either.
I was more looking for comments from other people who know what the heck
that early reservation system does.
Linus
On 04/08/2010 01:28 PM, Linus Torvalds wrote:
>
>
> On Thu, 8 Apr 2010, Konrad Rzeszutek Wilk wrote:
>>
>> Oh, I am definitely ACK-ing. Sorry about not explicitly stating that.
>> The developer is Yinghai Lu, I am the co-maintainer of the iBFT driver.
>>
>> Linus, would you like me to modify the commit so that it has 'Acked-by:'
>> by me in the git tree?
>
> No, no, a sign-off is already an ack, and is "stronger" than an ack, since
> it actually also means that you send it onwards. A patch that you don't
> like you would obviously never sign off on either.
>
> I was more looking for comments from other people who know what the heck
> that early reservation system does.
Just for the record, it also looks good to me (the other co-maintainer), so:
Signed-Off-By: Peter Jones <[email protected]>
But obviously that doesn't actually constitute the acks you were /looking/
for.
--
Peter
What we need is either less corruption, or more chances to
participate in it.
On 04/08/2010 10:28 AM, Linus Torvalds wrote:
>
>
> On Thu, 8 Apr 2010, Konrad Rzeszutek Wilk wrote:
>>
>> Oh, I am definitely ACK-ing. Sorry about not explicitly stating that.
>> The developer is Yinghai Lu, I am the co-maintainer of the iBFT driver.
>>
>> Linus, would you like me to modify the commit so that it has 'Acked-by:'
>> by me in the git tree?
>
> No, no, a sign-off is already an ack, and is "stronger" than an ack, since
> it actually also means that you send it onwards. A patch that you don't
> like you would obviously never sign off on either.
>
> I was more looking for comments from other people who know what the heck
> that early reservation system does.
the patched is in mainline already in mainline through tip path by HPA.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=042be38e6106ed70b42d096ab4a1ed4187e510e6
Thanks
Yinghai