| Message ID | f0c7d42c12a0b89c61265cdfe67a35b07d220aa0.1701936906.git.federico.serafini@bugseng.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | xen: add parameter names and remove function declarations | expand |
On 07.12.2023 09:47, Federico Serafini wrote: > Remove apci_pic_set_trigger() declaration: there is no definition and there are > no calls to such function in the XEN project. > > Signed-off-by: Federico Serafini <federico.serafini@bugseng.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> A reference to the offending commit would have been nice, the more that iirc I had already gone and fished that out for you. Jan
On 07/12/23 10:19, Jan Beulich wrote: > On 07.12.2023 09:47, Federico Serafini wrote: >> Remove apci_pic_set_trigger() declaration: there is no definition and there are >> no calls to such function in the XEN project. >> >> Signed-off-by: Federico Serafini <federico.serafini@bugseng.com> > > Reviewed-by: Jan Beulich <jbeulich@suse.com> > > A reference to the offending commit would have been nice, the more that iirc > I had already gone and fished that out for you. Is it correct to use Fixes: <id> ("subj") even if there are other useless entities left? In particular, this is what I think should be removed: Functions: __acpi_acquire_global_lock() __acpi_release_global_lock() acpi_save_state{mem,disk}() acpi_restore_state_mem() acpi_enter_state() {save,restore}_rest_processor_state() Variables: acpi_wakeup_address Macros: ACPI_ACQUIRE_GLOBAL_LOCK() If you agree with me, I can propose a new patch which includes such removals and refers to the offending commit with a Fixes.
On 07.12.2023 11:09, Federico Serafini wrote: > On 07/12/23 10:19, Jan Beulich wrote: >> On 07.12.2023 09:47, Federico Serafini wrote: >>> Remove apci_pic_set_trigger() declaration: there is no definition and there are >>> no calls to such function in the XEN project. >>> >>> Signed-off-by: Federico Serafini <federico.serafini@bugseng.com> >> >> Reviewed-by: Jan Beulich <jbeulich@suse.com> >> >> A reference to the offending commit would have been nice, the more that iirc >> I had already gone and fished that out for you. > > Is it correct to use Fixes: <id> ("subj") even if there are other > useless entities left? It was specifically because of being uncertain in this case that I didn't mention a possible Fixes: tag. There's no breakage from stray declarations, so it doesn't really feel to me like a "fix". > In particular, this is what I think should be removed: > > Functions: > __acpi_acquire_global_lock() > __acpi_release_global_lock() > acpi_save_state{mem,disk}() > acpi_restore_state_mem() > acpi_enter_state() > {save,restore}_rest_processor_state() > > Variables: > acpi_wakeup_address > > Macros: > ACPI_ACQUIRE_GLOBAL_LOCK() > > If you agree with me, I can propose a new patch which includes such > removals and refers to the offending commit with a Fixes. I haven't checked the entities above, but yes, I agree other stray declarations would want removing as well. In fact I was assuming that removal of just one item meant no other stray ones exist (right here). Jan
diff --git a/xen/arch/x86/include/asm/acpi.h b/xen/arch/x86/include/asm/acpi.h index 0df92d3714..48b1d69946 100644 --- a/xen/arch/x86/include/asm/acpi.h +++ b/xen/arch/x86/include/asm/acpi.h @@ -81,7 +81,6 @@ extern bool acpi_lapic, acpi_ioapic, acpi_noirq; extern bool acpi_force, acpi_ht, acpi_disabled; extern u32 acpi_smi_cmd; extern u8 acpi_enable_value, acpi_disable_value; -void acpi_pic_sci_set_trigger(unsigned int, u16); static inline void disable_acpi(void) {
Remove apci_pic_set_trigger() declaration: there is no definition and there are no calls to such function in the XEN project. Signed-off-by: Federico Serafini <federico.serafini@bugseng.com> --- xen/arch/x86/include/asm/acpi.h | 1 - 1 file changed, 1 deletion(-)