| Age | Commit message (Collapse) | Author |
|---|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP2xxx: PM: fix OMAP2xxx-specific UART idle bug in v3.3
ARM: OMAP3: cm-t35: fix section mismatch warning
ARM: OMAP2: Fix the OMAP2 only build break seen with 2011+ ARM tool-chains
ARM: OMAP2+: board-generic: Add missing handle_irq callbacks
|
|
git://git.infradead.org/users/cbou/battery-urgent
Just a few small fixes for a bunch of drivers. Nothing noteworthy.
* tag 'battery-fixes-for-v3.3-rc2' of git://git.infradead.org/users/cbou/battery-urgent:
lp8727_charger: Add terminating entry for i2c_device_id table
power_supply: Fix modalias for charger-manager
lp8727_chager: Fix permissions on a header file
bq27x00_battery: Fix flag register read
Revert "bq27x00_battery: Fix reporting status value for bq27500 battery"
|
|
Two bugfixes in XFS for 3.3: one fix passes KMEM_SLEEP to kmem_realloc
instead of 0, and the other resolves a possible deadlock in xfs quotas.
* 'for-linus' of git://oss.sgi.com/xfs/xfs:
xfs: use a normal shrinker for the dquot freelist
xfs: pass KM_SLEEP flag to kmem_realloc() in xlog_recover_add_to_cnt_trans()
|
|
This set of changes are fixing various section mismatch warnings which
look to be completely valid. Primerily, those which are fixed are those
which can cause oopses by manipulation of driver binding via sysfs. For
example: calling code marked __init from driver probe __devinit
functions.
Some of these changes will be reworked at the next merge window when the
underlying reasons are sorted out. In the mean time, I think it's
important to have this fixed for correctness.
Also included in this set are fixes to various error messages in OMAP -
including making them gramatically correct, fixing a few spelling
errors, and more importantly, making them greppable by unwrapping them.
Tony Lindgren has acked all these patches, put them out for testing a
week ago, and I've tested them on the platforms I have.
* 'omap-fixes-warnings' of git://git.linaro.org/people/rmk/linux-arm:
ARM: omap: resolve nebulous 'Error setting wl12xx data'
ARM: omap: fix wrapped error messages in omap_hwmod.c
ARM: omap: fix section mismatch warnings in mux.c caused by hsmmc.c
ARM: omap: fix section mismatch warning for sdp3430_twl_gpio_setup()
ARM: omap: fix section mismatch error for omap_4430sdp_display_init()
ARM: omap: fix section mismatch warning for omap_secondary_startup()
ARM: omap: preemptively fix section mismatch in omap4_sdp4430_wifi_mux_init()
ARM: omap: fix section mismatch warning in mux.c
ARM: omap: fix section mismatch errors in TWL PMIC driver
ARM: omap: fix uninformative vc/i2c configuration error message
ARM: omap: fix vc.c PMIC error message
ARM: omap: fix prm44xx.c OMAP44XX_IRQ_PRCM build error
|
|
This pull request covers the major oopsing issues with OMAP, caused by
the lack of the TWL driver. Even when the TWL driver is not built in,
we shouldn't oops.
* 'omap-fixes-urgent' of git://git.linaro.org/people/rmk/linux-arm:
ARM: omap: fix broken twl-core dependencies and ifdefs
ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c
ARM: omap: fix oops in arch/arm/mach-omap2/vp.c when pmic is not found
|
|
* 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
ARM: 7322/1: Print BUG instead of undefined instruction on BUG_ON()
ARM: 7321/1: cache-v7: Disable preemption when reading CCSIDR
ARM: 7320/1: Fix proc_info table alignment
|
|
Some code - especially the crypto layer - wants to use the x86
FP/MMX/AVX register set in what may be interrupt (typically softirq)
context.
That *can* be ok, but the tests for when it was ok were somewhat
suspect. We cannot touch the thread-specific status bits either, so
we'd better check that we're not going to try to save FP state or
anything like that.
Now, it may be that the TS bit is always cleared *before* we set the
USEDFPU bit (and only set when we had already cleared the USEDFP
before), so the TS bit test may actually have been sufficient, but it
certainly was not obviously so.
So this explicitly verifies that we will not touch the TS_USEDFPU bit,
and adds a few related sanity-checks. Because it seems that somehow
AES-NI is corrupting user FP state. The cause is not clear, and this
patch doesn't fix it, but while debugging it I really wanted the code to
be more obviously correct and robust.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
It was marked asmlinkage for some really old and stale legacy reasons.
Fix that and the equally stale comment.
Noticed when debugging the irq_fpu_usable() bugs.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
This fix a similar problem as in 72092cc45378176ba700034c91b7af2db524df26
and 481a8199142c050b72bff8a1956a49fd0a75bbe0 ("can:
fix NOHZ local_softirq_pending 08 warning"). This fix replaces netif_rx()
with netif_rx_ni() which has to be used from process/softirq context.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
commit 619c5cb6885 (New 7.0 FW: bnx2x, cnic, bnx2i, bnx2fc) added new
sparse warnings.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Eilon Greenstein <eilong@broadcom.com>
Cc: Vladislav Zolotarov <vladz@broadcom.com>
Cc: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Commit 0869b3a4: ixp4xx-eth: use an unique MDIO bus name changed
the MDIO bus name from "0" to "ixp4xx-eth-0", as a result the PHY
name is not longer appropriate and will not match the MDIO bus name
so PHY connection will not succeed, fix that.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Commit "d6c25be: mdio-octeon: use an unique MDIO bus name" changed the
octeon MDIO bus name from "0" to "mdio-octeon-0", change the PHY
formatting logic to account for that name change, so that PHY connection
on this bus succeeds.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Commit "391420f7: fec: use an unique MDIO bus name" first modified
the MDIO bus name to include the platform name, then in commit
"a7ed07d5: net: fec: correct phy_name buffer length when init phy_name"
the PHY name formatting was fixed in the case the PHY matches a PHY
driver.
The FEC driver however, also handles the case where we want to attach
to the fixed MDIO bus name, which was previously named "0", and now
"fixed-0". Change the PHY formatting logic to account for that.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Commit 3e617506: bcm63xx_enet: use an unique MDIO bus name introduced
a regression in the PHY connection logic, since the PHY name was formatted
to expect the bus name to be "0" or "1", whereas it is now "bcm63xx-enet-0"
or "bcm63xx-enet-1".
Reported-by: Joel EJC <joel_ejc@yahoofr>
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Commit d1733f07: cpmac: use an unique MDIO bus name changed the MDIO bus
name from "1" to "cpmac-1", this breaks the PHY connection logic because
the PHY name still uses the old bus names "0" and "1", fix that to
always use the mdio bus id instead.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The first parameter should be "number of elements" and the second parameter
should be "element size".
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This patch replaces the locking from the downclock routines with an assert
to ensure the registers are indeed unlocked. Without this patch, pre-SNB
devices would lock the registers when downclocking which would cause a
WARNING on suspend/resume with downclocking enabled.
Note: To hit this bug, you need to have lvds downclocking enabled.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
WARNING: drivers/spi/built-in.o(.devinit.text+0xdb8): Section mismatch in reference from the function pl022_probe() to the function .init.text:pl022_dma_probe()
The function __devinit pl022_probe() references
a function __init pl022_dma_probe().
If pl022_dma_probe is only used by pl022_probe then
annotate pl022_dma_probe with a matching annotation.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
Driver at91_ide is broken and should not be fixed: remove it.
Modification of device files that where making use of it. The
PATA driver (pata_at91) is able to replace at91_ide.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
|
|
pata_at91 driver is broken since faee0cc:
"make smc register base soc independent"
Fix it with newly introduced SMC accessors.
The overall action of removal of at91_sys_read/write will allow
to use the pata_at91 on a single zImage kernel.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: linux-ide@vger.kernel.org
|
|
SMC, Static Memory Controller will need more accessors to fine
configure its parameters.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
|
|
Instead of computing virtual address with AT91_VA_BASE_SYS, use the
appropriate ioremap() call on the driver "memory" resource.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
|
|
Registration of at91_udc as a module will enable SoC
related code.
Fix following an idea from Karel Znamenacek.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Karel Znamenacek <karel@ryston.cz>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: stable <stable@vger.kernel.org>
|
|
Conflicts:
sound/pci/hda/patch_realtek.c
Merged back the fix for Acer Aspire 6935 with ALC889 codec.
The fix commit was based on 3.2 kernel so that it can be applied to
stable kernel cleanly.
|
|
Since 3.2 kernel, the driver starts trying to assign the multi-io DACs
before the speaker, thus it assigns DAC2/3 for multi-io and DAC4 for
the speaker for a standard laptop setup like a HP, a speaker, a mic-in
and a line-in. However, on Acer Aspire 6935, it seems that the
speaker pin 0x14 must be connected with either DAC1 or 2; otherwise it
results in silence by some reason, although the codec itself allows
the routing to DAC3/4.
As a workaround, the connection list of each pin is reduced to be
mapped to either only DAC1/2 or DAC3/4, so that the compatible
assignment as in kernel 3.1 is achieved.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42740
Cc: <stable@kernel.org> [v3.2+]
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
VT1705 codec has two ADCs where the secondary ADC has no MUX but only
a fixed connection to the mic pin. This confused the driver and it
tries always overriding the input-source selection by assumption of
the existing MUX for the secondary ADC, resulted in resetting the
input-source at each time PM (including power-saving) occurs.
The fix is simply to check the existence of MUX for secondary ADCs in
the initialization code.
Tested-by: Anisse Astier <anisse@astier.eu>
Cc: <stable@kernel.org> [v3.1+]
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
evergreen and northern island gpu needs more informations for 2D tiling
than previous r6xx/r7xx. Add field to tiling ioctl to allow userspace
to provide those.
The v8 cs checking change to track color view on r6xx/r7xx doesn't
affect old userspace as old userspace always emited 0 for this register.
v2 fix r6xx/r7xx 2D tiling computation
v3 fix r6xx/r7xx height align for untiled surface & add support for
tile split on evergreen and newer
v4 improve tiling debugging output
v5 fix tile split code for evergreen and newer
v6 set proper tile split for crtc register
v7 fix tile split limit value
v8 add COLOR_VIEW checking to r6xx/r7xx checker, add evergreen cs
checking, update safe reg for r600, evergreen and cayman.
Evergreen checking need some work around for stencil alignment
issues
v9 fix tile split value range, fix compressed texture handling and
mipmap calculation, allow evergreen check to be silencious in
front of current broken userspace (depth/stencil alignment issue)
v10 fix eg 3d texture and compressed texture, fix r600 depth array,
fix r600 color view computation, add support for evergreen stencil
split
v11 more verbose debugging in some case
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
v2: agd5f: add strmout CS checking, copy_dw register checking
v3: agd5f: don't use cs_check_reg() for copy_dw checking as it
will incorrectly patch the command stream for certain regs.
v4: agd5f: add warning if safe reg check fails for copy_dw
v5: agd5f: add stricter checking for 6xx/7xx
v6: agd5f: add range checking for copy_dw on eg+,
add sx_surface_sync to safe reg list for 7xx.
v7: agd5f: add stricter checking for eg+
Signed-off-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
The first parameter should be "number of elements" and the second parameter
should be "element size".
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
* drm-vmware-next:
drm/vmwgfx: Bump driver minor
vmwgfx: Move function declaration to correct header
drm/vmwgfx: Treat out-of-range initial width and height as host errors
vmwgfx: Pick up the initial size from the width and height regs
vmwgfx: Add page flip support
vmwgfx: Pipe fence out of screen object dirty functions
vmwgfx: Make it possible to get fence from execbuf
vmwgfx: Clean up pending event references to struct drm_file objects on close
vmwgfx: Rework fence event action
|
|
Bump driver minor to signal availability of the page-flip ioctl.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
And assign the initial width and height to the minimum in that case.
Strange values (-1) from these registers have been reported by users.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Pending events may have stale pointer references to struct drm_file objects
after a file has been closed, but before the event is supposed to be
attached to the drm file. Remove such events on file close.
Tested with "modetest".
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
CEA actually specifies an interlaced mode with even vtotal and
supplies a diagram showing how this is supposed to work.
Note that interlaced modes with an even vtotal seem to be a fairly
recent invention. All modelines lore I could dig up with googling says
that vtotal for interlaced modes _needs_ to be odd. But the even
modelines in CEA are not a spec-bug, there's a figure in CEA-861-E
called "Figure 5 Special Interlaced Video Format Timing (Even Vtotal)"
that explains how it's supposed to work. Furthermore intel Bspec
explicitly mentions that both odd and even interlaced vtotal are
supported (VTOTAL register in the south display engine of PCH split
chips).
Acked-by: Adam Jackson <ajax@redhat.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
The locking in our setup and teardown paths is rather arbitrary, but
generally we try to protect gem stuff with dev->struct_mutex. Further,
the ums/gem ioctl to setup gem _does_ take the look. So fix up this
benign inconsistency.
Notice while reading through code.
v2: Rebased on top of the ppgtt code.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
It's useful to print the error code when a called function fails so a
diagnosis of why it failed is possible. In this case, it fails because
we try to register some data for the wl12xx driver, but as the driver
is not configured, a stub function is used which simply returns -ENOSYS.
Let's do the simple thing for -rc and print the error code.
Also, the return code from platform_register_device() at each of these
sites was not being checked. Add some checking, and again print the
error code.
This should be fixed properly for the next merge window so we don't
issue error messages merely because a driver is not configured.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
While trying to debug my OMAP platforms, they emitted this message:
omap_hwmod: %s: enabled state can only be entered from initialized, idle, or disabled state
The following backtrace said it was from a function called '_enable',
which didn't provide much clue. Grepping didn't find it either.
The message is wrapped, so unwrap the message so grep can find it. Do
the same for three other messages in this file.
Acked-by: Paul Walmsley <paul@pwsan.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
The previous commit causes new section mismatch warnings:
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb30): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_gpio()
The function omap_init_hsmmc() references
the function __init omap_mux_init_gpio().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_gpio is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb4c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_gpio()
The function omap_init_hsmmc() references
the function __init omap_mux_init_gpio().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_gpio is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb60): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb6c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb78): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb90): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb9c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdba8): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbc0): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbcc): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbd8): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbf8): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc04): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc10): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc28): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc34): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc40): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc58): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc64): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc70): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc7c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
Again, as for omap2_hsmmc_init(), these functions are callable at
runtime via the gpio-twl4030.c driver, and so these can't be marked
__init.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xd0f0): Section mismatch in reference from the function sdp3430_twl_gpio_setup() to the function .init.text:omap2_hsmmc_init()
The function sdp3430_twl_gpio_setup() references
the function __init omap2_hsmmc_init().
This is often because sdp3430_twl_gpio_setup lacks a __init
annotation or the annotation of omap2_hsmmc_init is wrong.
sdp3430_twl_gpio_setup() is called via platform data from the
gpio-twl4030 module, which can be inserted and removed at runtime.
This makes sdp3430_twl_gpio_setup() callable at runtime, and prevents
it being marked with an __init annotation.
As it calls omap2_hsmmc_init() unconditionally, the only resolution to
this warning is to remove the __init markings from omap2_hsmmc_init()
and its called functions. This addresses the functions in hsmmc.c.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xb798): Section mismatch in reference from the function omap_4430sdp_display_init() to the function .init.text:omap_display_init()
The function omap_4430sdp_display_init() references
the function __init omap_display_init().
This is often because omap_4430sdp_display_init lacks a __init
annotation or the annotation of omap_display_init is wrong.
Fix this by adding __init to omap_4430sdp_display_init().
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
WARNING: vmlinux.o(.text+0x1c664): Section mismatch in reference from the function omap_secondary_startup() to the function .cpuinit.text:secondary_startup()
The function omap_secondary_startup() references
the function __cpuinit secondary_startup().
This is often because omap_secondary_startup lacks a __cpuinit
annotation or the annotation of secondary_startup is wrong.
Unfortunately, fixing this causes a new warning which is harder to
solve:
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x5328): Section mismatch in reference from the function omap4_hotplug_cpu() to the function .cpuinit.text:omap_secondary_startup()
The function omap4_hotplug_cpu() references
the function __cpuinit omap_secondary_startup().
This is often because omap4_hotplug_cpu lacks a __cpuinit
annotation or the annotation of omap_secondary_startup is wrong.
because omap4_hotplug_cpu() is used by power management code as well,
which may not end up using omap_secondary_startup().
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Found by review.
omap4_sdp4430_wifi_mux_init() is called by an __init marked function,
and only calls omap_mux_init_gpio() and omap_mux_init_signal() which
are both also an __init marked functions.
The only reason this doesn't issue a warning is because the compiler
inlines omap4_sdp4430_wifi_mux_init() into omap4_sdp4430_wifi_init().
So, lets add the __init annotation to ensure this remains safe should
the compiler choose not to inline.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x15a4): Section mismatch in reference from the function omap_mux_init_signals() to the function .init.text:omap_mux_init_signal()
The function omap_mux_init_signals() references
the function __init omap_mux_init_signal().
This is often because omap_mux_init_signals lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
WARNING: drivers/mfd/built-in.o(.devinit.text+0x258): Section mismatch in reference from the function twl_probe() to the function .init.text:twl4030_power_init()
The function __devinit twl_probe() references
a function __init twl4030_power_init().
If twl4030_power_init is only used by twl_probe then
annotate twl4030_power_init with a matching annotation.
twl4030_power_init() references other __init marked functions, so
these too must become __devinit.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
