From: kernel test robot <lkp@intel.com>
To: KobaK <kobak@nvidia.com>, Matt Ochs <mochs@nvidia.com>,
James Morse <james.morse@arm.com>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Len Brown <lenb@kernel.org>,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
Zhang Rui <rui.zhang@intel.com>,
linux-efi@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev
Subject: Re: [PATCH V7] acpi/prmt: find block with specific type
Date: Sun, 13 Oct 2024 01:26:04 +0800 [thread overview]
Message-ID: <202410130117.PZ2JPuxo-lkp@intel.com> (raw)
In-Reply-To: <20241009064517.2678456-1-kobak@nvidia.com>
Hi KobaK,
kernel test robot noticed the following build warnings:
[auto build test WARNING on rafael-pm/linux-next]
[also build test WARNING on rafael-pm/bleeding-edge linus/master v6.12-rc2 next-20241011]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/KobaK/acpi-prmt-find-block-with-specific-type/20241009-144658
base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
patch link: https://lore.kernel.org/r/20241009064517.2678456-1-kobak%40nvidia.com
patch subject: [PATCH V7] acpi/prmt: find block with specific type
config: x86_64-kexec (https://download.01.org/0day-ci/archive/20241013/202410130117.PZ2JPuxo-lkp@intel.com/config)
compiler: clang version 18.1.8 (https://github.com/llvm/llvm-project 3b5b5c1ec4a3095ab096dd780e84d7ab81f3d7ff)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241013/202410130117.PZ2JPuxo-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202410130117.PZ2JPuxo-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/acpi/prmt.c:88:60: warning: format specifies type 'void *' but the argument has type 'u64' (aka 'unsigned long long') [-Wformat]
88 | pr_warn("Failed to find VA for GUID: %pUL, PA: %p", guid, pa);
| ~~ ^~
| %llu
include/linux/printk.h:543:37: note: expanded from macro 'pr_warn'
543 | printk(KERN_WARNING pr_fmt(fmt), ##__VA_ARGS__)
| ~~~ ^~~~~~~~~~~
include/linux/printk.h:490:60: note: expanded from macro 'printk'
490 | #define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
| ~~~ ^~~~~~~~~~~
include/linux/printk.h:462:19: note: expanded from macro 'printk_index_wrap'
462 | _p_func(_fmt, ##__VA_ARGS__); \
| ~~~~ ^~~~~~~~~~~
>> drivers/acpi/prmt.c:156:29: warning: passing 1-byte aligned argument to 4-byte aligned parameter 1 of 'efi_pa_va_lookup' may result in an unaligned pointer access [-Walign-mismatch]
156 | (void *)efi_pa_va_lookup(&th->guid, handler_info->handler_address);
| ^
drivers/acpi/prmt.c:159:21: warning: passing 1-byte aligned argument to 4-byte aligned parameter 1 of 'efi_pa_va_lookup' may result in an unaligned pointer access [-Walign-mismatch]
159 | efi_pa_va_lookup(&th->guid, handler_info->static_data_buffer_address);
| ^
drivers/acpi/prmt.c:162:21: warning: passing 1-byte aligned argument to 4-byte aligned parameter 1 of 'efi_pa_va_lookup' may result in an unaligned pointer access [-Walign-mismatch]
162 | efi_pa_va_lookup(&th->guid, handler_info->acpi_param_buffer_address);
| ^
4 warnings generated.
vim +88 drivers/acpi/prmt.c
74
75 static u64 efi_pa_va_lookup(efi_guid_t *guid, u64 pa)
76 {
77 efi_memory_desc_t *md;
78 u64 pa_offset = pa & ~PAGE_MASK;
79 u64 page = pa & PAGE_MASK;
80
81 for_each_efi_memory_desc(md) {
82 if ((md->attribute & EFI_MEMORY_RUNTIME) &&
83 (md->phys_addr < pa && pa < md->phys_addr + PAGE_SIZE * md->num_pages)) {
84 return pa_offset + md->virt_addr + page - md->phys_addr;
85 }
86 }
87
> 88 pr_warn("Failed to find VA for GUID: %pUL, PA: %p", guid, pa);
89
90 return 0;
91 }
92
93 #define get_first_handler(a) ((struct acpi_prmt_handler_info *) ((char *) (a) + a->handler_info_offset))
94 #define get_next_handler(a) ((struct acpi_prmt_handler_info *) (sizeof(struct acpi_prmt_handler_info) + (char *) a))
95
96 static int __init
97 acpi_parse_prmt(union acpi_subtable_headers *header, const unsigned long end)
98 {
99 struct acpi_prmt_module_info *module_info;
100 struct acpi_prmt_handler_info *handler_info;
101 struct prm_handler_info *th;
102 struct prm_module_info *tm;
103 u64 *mmio_count;
104 u64 cur_handler = 0;
105 u32 module_info_size = 0;
106 u64 mmio_range_size = 0;
107 void *temp_mmio;
108
109 module_info = (struct acpi_prmt_module_info *) header;
110 module_info_size = struct_size(tm, handlers, module_info->handler_info_count);
111 tm = kmalloc(module_info_size, GFP_KERNEL);
112 if (!tm)
113 goto parse_prmt_out1;
114
115 guid_copy(&tm->guid, (guid_t *) module_info->module_guid);
116 tm->major_rev = module_info->major_rev;
117 tm->minor_rev = module_info->minor_rev;
118 tm->handler_count = module_info->handler_info_count;
119 tm->updatable = true;
120
121 if (module_info->mmio_list_pointer) {
122 /*
123 * Each module is associated with a list of addr
124 * ranges that it can use during the service
125 */
126 mmio_count = (u64 *) memremap(module_info->mmio_list_pointer, 8, MEMREMAP_WB);
127 if (!mmio_count)
128 goto parse_prmt_out2;
129
130 mmio_range_size = struct_size(tm->mmio_info, addr_ranges, *mmio_count);
131 tm->mmio_info = kmalloc(mmio_range_size, GFP_KERNEL);
132 if (!tm->mmio_info)
133 goto parse_prmt_out3;
134
135 temp_mmio = memremap(module_info->mmio_list_pointer, mmio_range_size, MEMREMAP_WB);
136 if (!temp_mmio)
137 goto parse_prmt_out4;
138 memmove(tm->mmio_info, temp_mmio, mmio_range_size);
139 } else {
140 tm->mmio_info = kmalloc(sizeof(*tm->mmio_info), GFP_KERNEL);
141 if (!tm->mmio_info)
142 goto parse_prmt_out2;
143
144 tm->mmio_info->mmio_count = 0;
145 }
146
147 INIT_LIST_HEAD(&tm->module_list);
148 list_add(&tm->module_list, &prm_module_list);
149
150 handler_info = get_first_handler(module_info);
151 do {
152 th = &tm->handlers[cur_handler];
153
154 guid_copy(&th->guid, (guid_t *)handler_info->handler_guid);
155 th->handler_addr =
> 156 (void *)efi_pa_va_lookup(&th->guid, handler_info->handler_address);
157
158 th->static_data_buffer_addr =
159 efi_pa_va_lookup(&th->guid, handler_info->static_data_buffer_address);
160
161 th->acpi_param_buffer_addr =
162 efi_pa_va_lookup(&th->guid, handler_info->acpi_param_buffer_address);
163
164 } while (++cur_handler < tm->handler_count && (handler_info = get_next_handler(handler_info)));
165
166 return 0;
167
168 parse_prmt_out4:
169 kfree(tm->mmio_info);
170 parse_prmt_out3:
171 memunmap(mmio_count);
172 parse_prmt_out2:
173 kfree(tm);
174 parse_prmt_out1:
175 return -ENOMEM;
176 }
177
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
next prev parent reply other threads:[~2024-10-12 17:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-09 6:45 [PATCH V7] acpi/prmt: find block with specific type KobaK
2024-10-09 6:50 ` Ard Biesheuvel
2024-10-09 6:51 ` Koba Ko
2024-10-12 17:26 ` kernel test robot [this message]
2024-10-12 17:57 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202410130117.PZ2JPuxo-lkp@intel.com \
--to=lkp@intel.com \
--cc=ardb@kernel.org \
--cc=james.morse@arm.com \
--cc=kobak@nvidia.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=mochs@nvidia.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=rafael@kernel.org \
--cc=rui.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.