From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965259AbbLRVLc (ORCPT ); Fri, 18 Dec 2015 16:11:32 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:57328 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965134AbbLRVLb (ORCPT ); Fri, 18 Dec 2015 16:11:31 -0500 Date: Fri, 18 Dec 2015 13:11:24 -0800 From: Darren Hart To: "H. Peter Anvin" , Thomas Gleixner , Kuppuswamy Sathyanarayanan Cc: Linux Kernel Mailing List Subject: arch/x86: sfi: intel_scu_devices_create() section mismatch warnings Message-ID: <20151218211124.GC15346@malice.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I noticed the following in my build logs: WARNING: vmlinux.o(.text+0xa90d8): Section mismatch in reference from the function intel_scu_devices_create() to the function .init.text:i2c_register_board_info() The function intel_scu_devices_create() references the function __init i2c_register_board_info(). This is often because intel_scu_devices_create lacks a __init annotation or the annotation of i2c_register_board_info is wrong. The relevant code in arch/x86/platform/intel-mid/sfi.c: > /* Called by IPC driver */ > void intel_scu_devices_create(void) > { > int i; > > for (i = 0; i < ipc_next_dev; i++) > platform_device_add(ipc_devs[i]); > > for (i = 0; i < spi_next_dev; i++) > spi_register_board_info(spi_devs[i], 1); > > for (i = 0; i < i2c_next_dev; i++) { > struct i2c_adapter *adapter; > struct i2c_client *client; > > adapter = i2c_get_adapter(i2c_bus[i]); > if (adapter) { > client = i2c_new_device(adapter, i2c_devs[i]); > if (!client) > pr_err("can't create i2c device %s\n", > i2c_devs[i]->type); > } else > i2c_register_board_info(i2c_bus[i], i2c_devs[i], 1); i2c_register_board_info is annotated as __init and is intended for static machine board-files. The correct usage afaict is i2c_new_device() as used above. I presume what we're doing here is falling back to the static style configuration if this driver probes before the i2c adapters do? What I wasn't able to determine quickly is if this is a safe thing to do and the section mismatch can be ignored or not. > } > intel_scu_notifier_post(SCU_AVAILABLE, NULL); > } Thanks, -- Darren Hart Intel Open Source Technology Center