[GIT PULL] ibft fix for 3.2-rc6

[GIT PULL] ibft fix for 3.2-rc6

[Konrad Rzeszutek Wilk]

[-- Attachment #1: Type: text/plain, Size: 965 bytes --]

Hey Linus,

Please git pull the following branch:

 git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/ibft.git linux-next

which has a fix to make the ACPI table called 'iSCSI Boot Format Table'
(IBFT) be found by the iscsi-ibft driver when booting under UEFI.

The functionality to grab the APCI IBFT was added some time ago, but we
did not have the UEFI box to test it. Now that it has been tested it was
uncovered that the ACPI parser code was run way to early - so it did not
parse the iBFT table at all. This patch fixes it by doing the ACPI parsing later.
The legacy iBFT searching is not affected (which is to scan 640K->1MB
for the iBFT signature) and works correctly.

Please pull!

Yinghai Lu (1):
      ibft: Fix finding IBFT ACPI table on UEFI

 drivers/firmware/iscsi_ibft.c      |   42 ++++++++++++++++++++++++++++++++++-
 drivers/firmware/iscsi_ibft_find.c |   26 +--------------------
 2 files changed, 42 insertions(+), 26 deletions(-)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [GIT PULL] ibft fix for 3.2-rc6

[Yinghai Lu]

On Thu, Dec 15, 2011 at 1:05 PM, Konrad Rzeszutek Wilk
<konrad@darnok.org> wrote:
> Hey Linus,
>
> Please git pull the following branch:
>
>  git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/ibft.git linux-next
>
> which has a fix to make the ACPI table called 'iSCSI Boot Format Table'
> (IBFT) be found by the iscsi-ibft driver when booting under UEFI.
>
> The functionality to grab the APCI IBFT was added some time ago, but we
> did not have the UEFI box to test it. Now that it has been tested it was
> uncovered that the ACPI parser code was run way to early - so it did not
> parse the iBFT table at all. This patch fixes it by doing the ACPI parsing later.
> The legacy iBFT searching is not affected (which is to scan 640K->1MB
> for the iBFT signature) and works correctly.
>
> Please pull!
>
> Yinghai Lu (1):
>      ibft: Fix finding IBFT ACPI table on UEFI
>
>  drivers/firmware/iscsi_ibft.c      |   42 ++++++++++++++++++++++++++++++++++-
>  drivers/firmware/iscsi_ibft_find.c |   26 +--------------------
>  2 files changed, 42 insertions(+), 26 deletions(-)

Greg,

Can you please put this one into stable

	935a9fee51c945b8942be2d7b4bae069167b4886

actually,  even still need to apply to 2.6.32 stable

but commit description could be some different:

for 2.6.32, and kernel before memblock is supported in x86:
Even we call reserve_ibft_region() in x86 setup_arch() some late, but
it still in early stage.
at that time, acpi table is mapped for temporal use and will be
unmapped after handler is called
So handler should not store remapped address for late use.

only after init_main()/early_acpi_init(), we can store those remapped
address for acpi tables in handles

Thanks

Yinghai

Re: [GIT PULL] ibft fix for 3.2-rc6

[Greg KH]

On Thu, Dec 15, 2011 at 03:15:55PM -0800, Yinghai Lu wrote:
> On Thu, Dec 15, 2011 at 1:05 PM, Konrad Rzeszutek Wilk
> <konrad@darnok.org> wrote:
> > Hey Linus,
> >
> > Please git pull the following branch:
> >
> >  git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/ibft.git linux-next
> >
> > which has a fix to make the ACPI table called 'iSCSI Boot Format Table'
> > (IBFT) be found by the iscsi-ibft driver when booting under UEFI.
> >
> > The functionality to grab the APCI IBFT was added some time ago, but we
> > did not have the UEFI box to test it. Now that it has been tested it was
> > uncovered that the ACPI parser code was run way to early - so it did not
> > parse the iBFT table at all. This patch fixes it by doing the ACPI parsing later.
> > The legacy iBFT searching is not affected (which is to scan 640K->1MB
> > for the iBFT signature) and works correctly.
> >
> > Please pull!
> >
> > Yinghai Lu (1):
> >      ibft: Fix finding IBFT ACPI table on UEFI
> >
> >  drivers/firmware/iscsi_ibft.c      |   42 ++++++++++++++++++++++++++++++++++-
> >  drivers/firmware/iscsi_ibft_find.c |   26 +--------------------
> >  2 files changed, 42 insertions(+), 26 deletions(-)
> 
> Greg,
> 
> Can you please put this one into stable
> 
> 	935a9fee51c945b8942be2d7b4bae069167b4886
> 
> actually,  even still need to apply to 2.6.32 stable

<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
for how to do this properly.

</formletter>


That being said, I've queued this up for the 3.0 and 3.1 stable releases
now.

> but commit description could be some different:

Sorry, if you want something different, you are going to have to send me
the whole patch to stable@vger.kernel.org.

> for 2.6.32, and kernel before memblock is supported in x86:
> Even we call reserve_ibft_region() in x86 setup_arch() some late, but
> it still in early stage.
> at that time, acpi table is mapped for temporal use and will be
> unmapped after handler is called
> So handler should not store remapped address for late use.
> 
> only after init_main()/early_acpi_init(), we can store those remapped
> address for acpi tables in handles

I have no idea what you are referring to here.

The patch as-is does not apply to 2.6.32, so I can't apply it there.  If
you want it applied there, please provide the backport to the above
mentioned email address.

thanks,

greg k-h

Re: [GIT PULL] ibft fix for 3.2-rc6

[Yinghai Lu]

On Thu, Dec 15, 2011 at 4:07 PM, Greg KH <gregkh@suse.de> wrote:

> The patch as-is does not apply to 2.6.32, so I can't apply it there.  If
> you want it applied there, please provide the backport to the above
> mentioned email address.

ok, will do.

Thanks

Yinghai

Re: [GIT PULL] ibft fix for 3.2-rc6

[Yinghai Lu]

[-- Attachment #1: Type: text/plain, Size: 730 bytes --]

On Thu, Dec 15, 2011 at 4:37 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> On Thu, Dec 15, 2011 at 4:07 PM, Greg KH <gregkh@suse.de> wrote:
>
>> The patch as-is does not apply to 2.6.32, so I can't apply it there.  If
>> you want it applied there, please provide the backport to the above
>> mentioned email address.

please check back ported patch for 2.6.36 to 2.6.39

We don't need to this one for 2.6.32, because EFI/ACPI ibft detecting
is only added from 2.6.36.

but 2.6.32 base kernel still could take iscsi_ibft.c related changes
in the patch, and ignore conflicts with iscs_ibft_find.c.
but that will add new feature to 2.6.32. Not sure if stable tree
should take that kind of change.

Thanks

Yinghai

[-- Attachment #2: fix_ibft_checking_2.6.39.patch --]
[-- Type: text/x-patch, Size: 4005 bytes --]

[PATCH -stable] ibft: Fix finding IBFT ACPI table on UEFI

commit 935a9fee51c945b8942be2d7b4bae069167b4886 upstream.

it is backporting for:
	kernel 2.6.36, 2.6.37, 2.6.38, 2.6.39

Found one system with UEFI/iBFT, kernel does not detect the iBFT during
iscsi_ibft module loading.

Root cause: on x86 (UEFI), we are calling of find_ibft_region() much earlier
	- specifically in setup_arch() before ACPI is enabled.

Try to split acpi checking code out and call that later

At that time ACPI iBFT already get permanent mapped with ioremap.
So isa_virt_to_bus() will get wrong phys from right virt address.
We could just skip that phys address printing.

For legacy one, print the found address early.

-v2: update comments and description according to Konrad.
-v3: fix problem about module use case that is found by Konrad.
-v4: use acpi_get_table() instead of acpi_table_parse() to handle module use case that is found by Konrad again..

Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 drivers/firmware/iscsi_ibft.c      |   42 +++++++++++++++++++++++++++++++++++--
 drivers/firmware/iscsi_ibft_find.c |   22 +------------------
 2 files changed, 42 insertions(+), 22 deletions(-)

Index: linux-2.6/drivers/firmware/iscsi_ibft.c
===================================================================
--- linux-2.6.orig/drivers/firmware/iscsi_ibft.c
+++ linux-2.6/drivers/firmware/iscsi_ibft.c
@@ -738,6 +738,37 @@ static void __exit ibft_exit(void)
 	ibft_cleanup();
 }
 
+#ifdef CONFIG_ACPI
+static const struct {
+	char *sign;
+} ibft_signs[] = {
+	/*
+	 * One spec says "IBFT", the other says "iBFT". We have to check
+	 * for both.
+	 */
+	{ ACPI_SIG_IBFT },
+	{ "iBFT" },
+};
+
+static void __init acpi_find_ibft_region(void)
+{
+	int i;
+	struct acpi_table_header *table = NULL;
+
+	if (acpi_disabled)
+		return;
+
+	for (i = 0; i < ARRAY_SIZE(ibft_signs) && !ibft_addr; i++) {
+		acpi_get_table(ibft_signs[i].sign, 0, &table);
+		ibft_addr = (struct acpi_table_ibft *)table;
+	}
+}
+#else
+static void __init acpi_find_ibft_region(void)
+{
+}
+#endif
+
 /*
  * ibft_init() - creates sysfs tree entries for the iBFT data.
  */
@@ -745,9 +776,16 @@ static int __init ibft_init(void)
 {
 	int rc = 0;
 
+	/*
+	   As on UEFI systems the setup_arch()/find_ibft_region()
+	   is called before ACPI tables are parsed and it only does
+	   legacy finding.
+	*/
+	if (!ibft_addr)
+		acpi_find_ibft_region();
+
 	if (ibft_addr) {
-		printk(KERN_INFO "iBFT detected at 0x%llx.\n",
-		       (u64)isa_virt_to_bus(ibft_addr));
+		pr_info("iBFT detected.\n");
 
 		rc = ibft_check_device();
 		if (rc)
Index: linux-2.6/drivers/firmware/iscsi_ibft_find.c
===================================================================
--- linux-2.6.orig/drivers/firmware/iscsi_ibft_find.c
+++ linux-2.6/drivers/firmware/iscsi_ibft_find.c
@@ -49,14 +49,6 @@ EXPORT_SYMBOL_GPL(ibft_addr);
 #define VGA_MEM 0xA0000 /* VGA buffer */
 #define VGA_SIZE 0x20000 /* 128kB */
 
-#ifdef CONFIG_ACPI
-static int __init acpi_find_ibft(struct acpi_table_header *header)
-{
-	ibft_addr = (struct acpi_table_ibft *)header;
-	return 0;
-}
-#endif /* CONFIG_ACPI */
-
 static int __init find_ibft_in_mem(void)
 {
 	unsigned long pos;
@@ -77,6 +69,7 @@ static int __init find_ibft_in_mem(void)
 			 * the table cannot be valid. */
 			if (pos + len <= (IBFT_END-1)) {
 				ibft_addr = (struct acpi_table_ibft *)virt;
+				pr_info("iBFT found at 0x%lx.\n", pos);
 				break;
 			}
 		}
@@ -92,21 +85,10 @@ unsigned long __init find_ibft_region(un
 
 	ibft_addr = NULL;
 
-#ifdef CONFIG_ACPI
-	/*
-	 * One spec says "IBFT", the other says "iBFT". We have to check
-	 * for both.
-	 */
-	if (!ibft_addr)
-		acpi_table_parse(ACPI_SIG_IBFT, acpi_find_ibft);
-	if (!ibft_addr)
-		acpi_table_parse(IBFT_SIGN, acpi_find_ibft);
-#endif /* CONFIG_ACPI */
-
 	/* iBFT 1.03 section 1.4.3.1 mandates that UEFI machines will
 	 * only use ACPI for this */
 
-	if (!ibft_addr && !efi_enabled)
+	if (!efi_enabled)
 		find_ibft_in_mem();
 
 	if (ibft_addr) {

Re: [GIT PULL] ibft fix for 3.2-rc6

[Konrad Rzeszutek Wilk]

On Fri, Dec 16, 2011 at 04:40:34PM -0800, Yinghai Lu wrote:
> On Thu, Dec 15, 2011 at 4:37 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> > On Thu, Dec 15, 2011 at 4:07 PM, Greg KH <gregkh@suse.de> wrote:
> >
> >> The patch as-is does not apply to 2.6.32, so I can't apply it there.  If
> >> you want it applied there, please provide the backport to the above
> >> mentioned email address.
> 
> please check back ported patch for 2.6.36 to 2.6.39
> 
> We don't need to this one for 2.6.32, because EFI/ACPI ibft detecting
> is only added from 2.6.36.

Then 2.6.36 and above should have the fix below. Thanks for porting it
over.
> 
> but 2.6.32 base kernel still could take iscsi_ibft.c related changes
> in the patch, and ignore conflicts with iscs_ibft_find.c.
> but that will add new feature to 2.6.32. Not sure if stable tree
> should take that kind of change.

It could, but I am not too thrilled about it.
> 
> Thanks
> 
> Yinghai

> [PATCH -stable] ibft: Fix finding IBFT ACPI table on UEFI
> 
> commit 935a9fee51c945b8942be2d7b4bae069167b4886 upstream.
> 
> it is backporting for:
> 	kernel 2.6.36, 2.6.37, 2.6.38, 2.6.39
> 
> Found one system with UEFI/iBFT, kernel does not detect the iBFT during
> iscsi_ibft module loading.
> 
> Root cause: on x86 (UEFI), we are calling of find_ibft_region() much earlier
> 	- specifically in setup_arch() before ACPI is enabled.
> 
> Try to split acpi checking code out and call that later
> 
> At that time ACPI iBFT already get permanent mapped with ioremap.
> So isa_virt_to_bus() will get wrong phys from right virt address.
> We could just skip that phys address printing.
> 
> For legacy one, print the found address early.
> 
> -v2: update comments and description according to Konrad.
> -v3: fix problem about module use case that is found by Konrad.
> -v4: use acpi_get_table() instead of acpi_table_parse() to handle module use case that is found by Konrad again..
> 
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> 
> ---
>  drivers/firmware/iscsi_ibft.c      |   42 +++++++++++++++++++++++++++++++++++--
>  drivers/firmware/iscsi_ibft_find.c |   22 +------------------
>  2 files changed, 42 insertions(+), 22 deletions(-)
> 
> Index: linux-2.6/drivers/firmware/iscsi_ibft.c
> ===================================================================
> --- linux-2.6.orig/drivers/firmware/iscsi_ibft.c
> +++ linux-2.6/drivers/firmware/iscsi_ibft.c
> @@ -738,6 +738,37 @@ static void __exit ibft_exit(void)
>  	ibft_cleanup();
>  }
>  
> +#ifdef CONFIG_ACPI
> +static const struct {
> +	char *sign;
> +} ibft_signs[] = {
> +	/*
> +	 * One spec says "IBFT", the other says "iBFT". We have to check
> +	 * for both.
> +	 */
> +	{ ACPI_SIG_IBFT },
> +	{ "iBFT" },
> +};
> +
> +static void __init acpi_find_ibft_region(void)
> +{
> +	int i;
> +	struct acpi_table_header *table = NULL;
> +
> +	if (acpi_disabled)
> +		return;
> +
> +	for (i = 0; i < ARRAY_SIZE(ibft_signs) && !ibft_addr; i++) {
> +		acpi_get_table(ibft_signs[i].sign, 0, &table);
> +		ibft_addr = (struct acpi_table_ibft *)table;
> +	}
> +}
> +#else
> +static void __init acpi_find_ibft_region(void)
> +{
> +}
> +#endif
> +
>  /*
>   * ibft_init() - creates sysfs tree entries for the iBFT data.
>   */
> @@ -745,9 +776,16 @@ static int __init ibft_init(void)
>  {
>  	int rc = 0;
>  
> +	/*
> +	   As on UEFI systems the setup_arch()/find_ibft_region()
> +	   is called before ACPI tables are parsed and it only does
> +	   legacy finding.
> +	*/
> +	if (!ibft_addr)
> +		acpi_find_ibft_region();
> +
>  	if (ibft_addr) {
> -		printk(KERN_INFO "iBFT detected at 0x%llx.\n",
> -		       (u64)isa_virt_to_bus(ibft_addr));
> +		pr_info("iBFT detected.\n");
>  
>  		rc = ibft_check_device();
>  		if (rc)
> Index: linux-2.6/drivers/firmware/iscsi_ibft_find.c
> ===================================================================
> --- linux-2.6.orig/drivers/firmware/iscsi_ibft_find.c
> +++ linux-2.6/drivers/firmware/iscsi_ibft_find.c
> @@ -49,14 +49,6 @@ EXPORT_SYMBOL_GPL(ibft_addr);
>  #define VGA_MEM 0xA0000 /* VGA buffer */
>  #define VGA_SIZE 0x20000 /* 128kB */
>  
> -#ifdef CONFIG_ACPI
> -static int __init acpi_find_ibft(struct acpi_table_header *header)
> -{
> -	ibft_addr = (struct acpi_table_ibft *)header;
> -	return 0;
> -}
> -#endif /* CONFIG_ACPI */
> -
>  static int __init find_ibft_in_mem(void)
>  {
>  	unsigned long pos;
> @@ -77,6 +69,7 @@ static int __init find_ibft_in_mem(void)
>  			 * the table cannot be valid. */
>  			if (pos + len <= (IBFT_END-1)) {
>  				ibft_addr = (struct acpi_table_ibft *)virt;
> +				pr_info("iBFT found at 0x%lx.\n", pos);
>  				break;
>  			}
>  		}
> @@ -92,21 +85,10 @@ unsigned long __init find_ibft_region(un
>  
>  	ibft_addr = NULL;
>  
> -#ifdef CONFIG_ACPI
> -	/*
> -	 * One spec says "IBFT", the other says "iBFT". We have to check
> -	 * for both.
> -	 */
> -	if (!ibft_addr)
> -		acpi_table_parse(ACPI_SIG_IBFT, acpi_find_ibft);
> -	if (!ibft_addr)
> -		acpi_table_parse(IBFT_SIGN, acpi_find_ibft);
> -#endif /* CONFIG_ACPI */
> -
>  	/* iBFT 1.03 section 1.4.3.1 mandates that UEFI machines will
>  	 * only use ACPI for this */
>  
> -	if (!ibft_addr && !efi_enabled)
> +	if (!efi_enabled)
>  		find_ibft_in_mem();
>  
>  	if (ibft_addr) {

Re: [GIT PULL] ibft fix for 3.2-rc6

[Konrad Rzeszutek Wilk]

On Fri, Dec 16, 2011 at 04:40:34PM -0800, Yinghai Lu wrote:
> On Thu, Dec 15, 2011 at 4:37 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> > On Thu, Dec 15, 2011 at 4:07 PM, Greg KH <gregkh@suse.de> wrote:
> >
> >> The patch as-is does not apply to 2.6.32, so I can't apply it there. �If
> >> you want it applied there, please provide the backport to the above
> >> mentioned email address.
> 
> please check back ported patch for 2.6.36 to 2.6.39
> 
> We don't need to this one for 2.6.32, because EFI/ACPI ibft detecting
> is only added from 2.6.36.

Then 2.6.36 and above should have the fix below. Thanks for porting it
over.
> 
> but 2.6.32 base kernel still could take iscsi_ibft.c related changes
> in the patch, and ignore conflicts with iscs_ibft_find.c.
> but that will add new feature to 2.6.32. Not sure if stable tree
> should take that kind of change.

It could, but I am not too thrilled about it.
> 
> Thanks
> 
> Yinghai

> [PATCH -stable] ibft: Fix finding IBFT ACPI table on UEFI
> 
> commit 935a9fee51c945b8942be2d7b4bae069167b4886 upstream.
> 
> it is backporting for:
> 	kernel 2.6.36, 2.6.37, 2.6.38, 2.6.39
> 
> Found one system with UEFI/iBFT, kernel does not detect the iBFT during
> iscsi_ibft module loading.
> 
> Root cause: on x86 (UEFI), we are calling of find_ibft_region() much earlier
> 	- specifically in setup_arch() before ACPI is enabled.
> 
> Try to split acpi checking code out and call that later
> 
> At that time ACPI iBFT already get permanent mapped with ioremap.
> So isa_virt_to_bus() will get wrong phys from right virt address.
> We could just skip that phys address printing.
> 
> For legacy one, print the found address early.
> 
> -v2: update comments and description according to Konrad.
> -v3: fix problem about module use case that is found by Konrad.
> -v4: use acpi_get_table() instead of acpi_table_parse() to handle module use case that is found by Konrad again..
> 
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> 
> ---
>  drivers/firmware/iscsi_ibft.c      |   42 +++++++++++++++++++++++++++++++++++--
>  drivers/firmware/iscsi_ibft_find.c |   22 +------------------
>  2 files changed, 42 insertions(+), 22 deletions(-)
> 
> Index: linux-2.6/drivers/firmware/iscsi_ibft.c
> ===================================================================
> --- linux-2.6.orig/drivers/firmware/iscsi_ibft.c
> +++ linux-2.6/drivers/firmware/iscsi_ibft.c
> @@ -738,6 +738,37 @@ static void __exit ibft_exit(void)
>  	ibft_cleanup();
>  }
>  
> +#ifdef CONFIG_ACPI
> +static const struct {
> +	char *sign;
> +} ibft_signs[] = {
> +	/*
> +	 * One spec says "IBFT", the other says "iBFT". We have to check
> +	 * for both.
> +	 */
> +	{ ACPI_SIG_IBFT },
> +	{ "iBFT" },
> +};
> +
> +static void __init acpi_find_ibft_region(void)
> +{
> +	int i;
> +	struct acpi_table_header *table = NULL;
> +
> +	if (acpi_disabled)
> +		return;
> +
> +	for (i = 0; i < ARRAY_SIZE(ibft_signs) && !ibft_addr; i++) {
> +		acpi_get_table(ibft_signs[i].sign, 0, &table);
> +		ibft_addr = (struct acpi_table_ibft *)table;
> +	}
> +}
> +#else
> +static void __init acpi_find_ibft_region(void)
> +{
> +}
> +#endif
> +
>  /*
>   * ibft_init() - creates sysfs tree entries for the iBFT data.
>   */
> @@ -745,9 +776,16 @@ static int __init ibft_init(void)
>  {
>  	int rc = 0;
>  
> +	/*
> +	   As on UEFI systems the setup_arch()/find_ibft_region()
> +	   is called before ACPI tables are parsed and it only does
> +	   legacy finding.
> +	*/
> +	if (!ibft_addr)
> +		acpi_find_ibft_region();
> +
>  	if (ibft_addr) {
> -		printk(KERN_INFO "iBFT detected at 0x%llx.\n",
> -		       (u64)isa_virt_to_bus(ibft_addr));
> +		pr_info("iBFT detected.\n");
>  
>  		rc = ibft_check_device();
>  		if (rc)
> Index: linux-2.6/drivers/firmware/iscsi_ibft_find.c
> ===================================================================
> --- linux-2.6.orig/drivers/firmware/iscsi_ibft_find.c
> +++ linux-2.6/drivers/firmware/iscsi_ibft_find.c
> @@ -49,14 +49,6 @@ EXPORT_SYMBOL_GPL(ibft_addr);
>  #define VGA_MEM 0xA0000 /* VGA buffer */
>  #define VGA_SIZE 0x20000 /* 128kB */
>  
> -#ifdef CONFIG_ACPI
> -static int __init acpi_find_ibft(struct acpi_table_header *header)
> -{
> -	ibft_addr = (struct acpi_table_ibft *)header;
> -	return 0;
> -}
> -#endif /* CONFIG_ACPI */
> -
>  static int __init find_ibft_in_mem(void)
>  {
>  	unsigned long pos;
> @@ -77,6 +69,7 @@ static int __init find_ibft_in_mem(void)
>  			 * the table cannot be valid. */
>  			if (pos + len <= (IBFT_END-1)) {
>  				ibft_addr = (struct acpi_table_ibft *)virt;
> +				pr_info("iBFT found at 0x%lx.\n", pos);
>  				break;
>  			}
>  		}
> @@ -92,21 +85,10 @@ unsigned long __init find_ibft_region(un
>  
>  	ibft_addr = NULL;
>  
> -#ifdef CONFIG_ACPI
> -	/*
> -	 * One spec says "IBFT", the other says "iBFT". We have to check
> -	 * for both.
> -	 */
> -	if (!ibft_addr)
> -		acpi_table_parse(ACPI_SIG_IBFT, acpi_find_ibft);
> -	if (!ibft_addr)
> -		acpi_table_parse(IBFT_SIGN, acpi_find_ibft);
> -#endif /* CONFIG_ACPI */
> -
>  	/* iBFT 1.03 section 1.4.3.1 mandates that UEFI machines will
>  	 * only use ACPI for this */
>  
> -	if (!ibft_addr && !efi_enabled)
> +	if (!efi_enabled)
>  		find_ibft_in_mem();
>  
>  	if (ibft_addr) {

Re: [GIT PULL] ibft fix for 3.2-rc6

[Yinghai Lu]

On Sat, Dec 17, 2011 at 6:42 AM, Konrad Rzeszutek Wilk
<konrad@darnok.org> wrote:
>>
>> but 2.6.32 base kernel still could take iscsi_ibft.c related changes
>> in the patch, and ignore conflicts with iscs_ibft_find.c.
>> but that will add new feature to 2.6.32. Not sure if stable tree
>> should take that kind of change.
>
> It could, but I am not too thrilled about it.

RHEL 6.x are still with 2.6.32...

So under UEFI mode installation, users need to input iscsi target info
again during selecting storage for installation. Because kernel does
not to parse that from acpi iBFT table.

When legacy mode iscsi installation is used, installation program will
not need user install those info again.

QA are complaining that difference.

Thanks

Yinghai Lu

Re: [GIT PULL] ibft fix for 3.2-rc6

[Konrad Rzeszutek Wilk]

>>> but that will add new feature to 2.6.32. Not sure if stable tree
>>> should take that kind of change.
>>
>> It could, but I am not too thrilled about it.
>
> RHEL 6.x are still with 2.6.32...
>

If Red Hat needs it, they can back-port it. It is not that hard for it
to be done and they are very proficient at it.

> So under UEFI mode installation, users need to input iscsi target info
> again during selecting storage for installation. Because kernel does
> not to parse that from acpi iBFT table.
>
> When legacy mode iscsi installation is used, installation program will
> not need user install those info again.
>
> QA are complaining that difference.

I think I understand your position. You are getting emails from QA
testing some hardware saying it does not work with RHEL, so you try
upstream, find the bug and fix it (awesome, thanks for doing that),
and then you want to back-port the fix so RHEL picks it up (and can
close the bug). Thr mechanism for that is by contacting the vendor
about this - either using the Program Manager to open a feature
request, or waiting for a customer to report this bug (on the Red Hat
side) and then your fix will be magically picked up.

The stable 2.6.32.x tree would require the sub-maintainer (that is me)
to sign off on supporting this in 2.6.32.x tree and I am not signing
up for it b/c I don't have the time to support it (this is after-work
hours fun stuff I do).

Re: [GIT PULL] ibft fix for 3.2-rc6

[Yinghai Lu]

[-- Attachment #1: Type: text/plain, Size: 863 bytes --]

On Thu, Dec 22, 2011 at 7:50 PM, Konrad Rzeszutek Wilk
<konrad@darnok.org> wrote:
>>
>> When legacy mode iscsi installation is used, installation program will
>> not need user install those info again.
>>
>> QA are complaining that difference.
>
> I think I understand your position. You are getting emails from QA
> testing some hardware saying it does not work with RHEL, so you try
> upstream, find the bug and fix it (awesome, thanks for doing that),
> and then you want to back-port the fix so RHEL picks it up (and can
> close the bug). Thr mechanism for that is by contacting the vendor
> about this - either using the Program Manager to open a feature
> request, or waiting for a customer to report this bug (on the Red Hat
> side) and then your fix will be magically picked up.

yes,

attached is the patch for 2.6.32 to close the loop.

Thanks

Yinghai

[-- Attachment #2: fix_ibft_checking_2.6.32.patch --]
[-- Type: text/x-patch, Size: 2060 bytes --]

[PATCH -v2.6.32] ibft: Finding IBFT ACPI table on UEFI

commit 935a9fee51c945b8942be2d7b4bae069167b4886 upstream.

Found one system with UEFI/iBFT, kernel does not detect the iBFT during
iscsi_ibft module loading.

So users will need to input iscsi info during RHEL 6.x installation.

We can add checking in ibft_init for acpi.

At that time ACPI iBFT already get permanent mapped with ioremap.

For legacy one, print the found address early.


Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 drivers/firmware/iscsi_ibft.c |   42 ++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 40 insertions(+), 2 deletions(-)

Index: linux-2.6/drivers/firmware/iscsi_ibft.c
===================================================================
--- linux-2.6.orig/drivers/firmware/iscsi_ibft.c
+++ linux-2.6/drivers/firmware/iscsi_ibft.c
@@ -926,6 +926,37 @@ static int __init ibft_register_attribut
 	return rc;
 }
 
+#ifdef CONFIG_ACPI
+static const struct {
+	char *sign;
+} ibft_signs[] = {
+	/*
+	 * One spec says "IBFT", the other says "iBFT". We have to check
+	 * for both.
+	 */
+	{ ACPI_SIG_IBFT },
+	{ "iBFT" },
+};
+
+static void __init acpi_find_ibft_region(void)
+{
+	int i;
+	struct acpi_table_header *table = NULL;
+
+	if (acpi_disabled)
+		return;
+
+	for (i = 0; i < ARRAY_SIZE(ibft_signs) && !ibft_addr; i++) {
+		acpi_get_table(ibft_signs[i].sign, 0, &table);
+		ibft_addr = (struct acpi_table_ibft *)table;
+	}
+}
+#else
+static void __init acpi_find_ibft_region(void)
+{
+}
+#endif
+
 /*
  * ibft_init() - creates sysfs tree entries for the iBFT data.
  */
@@ -937,9 +968,16 @@ static int __init ibft_init(void)
 	if (!ibft_kset)
 		return -ENOMEM;
 
+	/*
+	   As on UEFI systems the setup_arch()/find_ibft_region()
+	   is called before ACPI tables are parsed and it only does
+	   legacy finding.
+	*/
+	if (!ibft_addr)
+		acpi_find_ibft_region();
+
 	if (ibft_addr) {
-		printk(KERN_INFO "iBFT detected at 0x%llx.\n",
-		       (u64)isa_virt_to_bus(ibft_addr));
+		pr_info("iBFT detected.\n");
 
 		rc = ibft_check_device();
 		if (rc)

Re: [GIT PULL] ibft fix for 3.2-rc6

[Greg KH]

On Fri, Dec 16, 2011 at 04:40:34PM -0800, Yinghai Lu wrote:
> On Thu, Dec 15, 2011 at 4:37 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> > On Thu, Dec 15, 2011 at 4:07 PM, Greg KH <gregkh@suse.de> wrote:
> >
> >> The patch as-is does not apply to 2.6.32, so I can't apply it there.  If
> >> you want it applied there, please provide the backport to the above
> >> mentioned email address.
> 
> please check back ported patch for 2.6.36 to 2.6.39

Thanks, but I don't think these kernel versions are maintained by anyone
anymore, sorry.

> We don't need to this one for 2.6.32, because EFI/ACPI ibft detecting
> is only added from 2.6.36.
> 
> but 2.6.32 base kernel still could take iscsi_ibft.c related changes
> in the patch, and ignore conflicts with iscs_ibft_find.c.
> but that will add new feature to 2.6.32. Not sure if stable tree
> should take that kind of change.

No it will not, sorry.

greg k-h

Re: [GIT PULL] ibft fix for 3.2-rc6

[Greg KH]

On Fri, Dec 16, 2011 at 04:40:34PM -0800, Yinghai Lu wrote:
> On Thu, Dec 15, 2011 at 4:37 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> > On Thu, Dec 15, 2011 at 4:07 PM, Greg KH <gregkh@suse.de> wrote:
> >
> >> The patch as-is does not apply to 2.6.32, so I can't apply it there. �If
> >> you want it applied there, please provide the backport to the above
> >> mentioned email address.
> 
> please check back ported patch for 2.6.36 to 2.6.39

Thanks, but I don't think these kernel versions are maintained by anyone
anymore, sorry.

> We don't need to this one for 2.6.32, because EFI/ACPI ibft detecting
> is only added from 2.6.36.
> 
> but 2.6.32 base kernel still could take iscsi_ibft.c related changes
> in the patch, and ignore conflicts with iscs_ibft_find.c.
> but that will add new feature to 2.6.32. Not sure if stable tree
> should take that kind of change.

No it will not, sorry.

greg k-h