On 1/23/24 23:32, Daniel Kiper wrote:
On Wed, Jan 17, 2024 at 12:39:06PM +0530, Mukesh Kumar Chaurasiya wrote:
On 11/30/23 00:45, Daniel Kiper wrote:
On Mon, Nov 27, 2023 at 06:07:42PM +0530, Mukesh Kumar Chaurasiya wrote:
Signed-off-by: Mukesh Kumar Chaurasiya <mchau...@linux.ibm.com>
---
grub-core/disk/ieee1275/ofdisk.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/grub-core/disk/ieee1275/ofdisk.c b/grub-core/disk/ieee1275/ofdisk.c
index c6cba0c8a..9cd8898f1 100644
--- a/grub-core/disk/ieee1275/ofdisk.c
+++ b/grub-core/disk/ieee1275/ofdisk.c
@@ -222,8 +222,12 @@ dev_iterate (const struct grub_ieee1275_devalias *alias)
grub_ieee1275_cell_t table;
}
args;
+ struct lun_buf {
+ grub_uint64_t *buf_addr;
This will not work on 32-bit architectures.
Umm...
well i checked this and the definition for 32bit and 64bit are same. So the
I am not entirely sure what you mean by "the same" here.
structure part should be fine.
+ ptr =(grub_uint64_t*)(grub_addr_t) tbl[i].buf_addr;
and this should handle the 32bit arch in terms of address.
for rest i'll send out a new version of patch
The problem is with the *buf_addr pointer. Its size on 32-bit platform
is 32-bit. So, on 32-bit platform you will have struct with 32-bit member and
64-bit member following it. This is not what you expect. The buf_addr/buf_size
table has each entry with two 64-bit members. Am I missing something?
Daniel
In case of 32 bit the upper 4 bytes are padded with 00. I am not sure
why, this was weird for me too.
Regards
Mukesh
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
