Add support for handling OMAP7xx specific gpio_init by
providing platform device data and doing device registration.
Signed-off-by: Charulatha V <charu@ti.com>
Acked-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Add support for handling OMAP16xx specific gpio_init by
providing platform device data and doing device registration.
Signed-off-by: Charulatha V <charu@ti.com>
Acked-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Add support for handling OMAP15xx specific gpio_init by
providing platform device data and doing device registration.
Signed-off-by: Charulatha V <charu@ti.com>
Acked-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Otherwise GPIO init on 16xx may try to access uninitialized GPIO
bank as the MPUIO bank does not have a revision register.
Acked-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Prepare for implementing GPIO as a platform driver.
Modifies omap_gpio_init() to make use of omap_gpio_chip_init()
and omap_gpio_mod_init(). omap_gpio_mod_init() does the module init
by clearing the status register and initializing the GPIO control register.
omap_gpio_chip_init() initializes the chip request, free, get, set and
other function pointers and sets the gpio irq handler.
This is only to reorganize the code so that the "omap gpio platform driver
implementation patch" looks cleaner and better to review.
Signed-off-by: Charulatha V <charu@ti.com>
Acked-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Looks like some boards are calling gpio_request from init_irq.
This will make the request_irq fail, as GPIO will be initialized
as postcore_initcall.
Reported-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Using true/false instead of 1/0 to update the free variable.
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
Acked-by: Jarkko Nikula <jhnikula@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Function omap_mcbsp_probe allocates struct omap_mcbsp *mcbsp but it is not
freed in omap_mcbsp_remove. Fix this, remove unneeded structure cleanups
and clk_disable calls since they are not needed here.
This is not problem currently but becomes if the mcbsp driver is ever
modularized.
Signed-off-by: Jarkko Nikula <jhnikula@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Value of "isr_reg" pointer is depend on configuration and GPIO method.
Potentially it may have NULL value and it is dereferenced later
in code. Warning and exit from function are added in this case.
Signed-off-by: Evgeny Kuznetsov <EXT-Eugeny.Kuznetsov@nokia.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
In some cases we can get error function `omap2_i2c_add_bus':
arch/arm/plat-omap/i2c.c:136: undefined reference to `omap2_i2c_mux_pins'
arch/arm/plat-omap/i2c.c:141: undefined reference to `omap_hwmod_lookup'
arch/arm/plat-omap/i2c.c:157: undefined reference to `omap_device_build'
Signed-off-by: Tony Lindgren <tony@atomide.com>
The firmware framework gets initialized during fs_initcall time, so
we are not allowed to call request_firmware earlier.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Avoid overflowing a 32 bit value.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Forbid allocating buffer bigger than visible VRAM or GTT, also
properly set lpfn field.
v2 - use max macro
- silence warning
v3 - don't explicitly set range limit
- use min macro
Cc: stable <stable@kernel.org>
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Prevents code that assumes that the encoder is active when asked to be
disabled from dying a horrible death.
Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kristian Høgsberg <krh@bitplanet.net>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Currently, in case of using scatter/gather mode, head of data is not sent to
destination. The cause is second descriptor address is set to NEXT.
The NEXT must have head of descriptor address.
This patch sets head of descriptor address to the NEXT.
Acked-by: Yong Wang <youg.y.wang@intel.com>
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
[dan.j.williams@intel.com: fixed up usage of virt_to_phys()]
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
As we may try to power down the link at various times, it is not
necessarily still coupled with an encoder and so we must be careful not
to depend upon an operation that is only valid when the link is still
attached to a pipe.
Fixes regression in 5bddd17.
Reported-and-tested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org [after applying 5bddd17]
Commit 4d17aeb1c5 ("OMAP: I2C: split
device registration and convert OMAP2+ to omap_device") broke I2C on
OMAP1. The following messages appear at boot:
i2c_omap i2c_omap.1: failure requesting irq 0
i2c_omap: probe of i2c_omap.1 failed with error -22
Investigation revealed that a chunk of code is missing from the
original plat-omap/i2c.c file which configured the IRQ and base address
for the I2C block on OMAP1. Upon adding this back, the OMAP1 I2C block
seems to initialize correctly.
Thanks to Cory Maccarrone <darkstar6262@gmail.com> for reporting the bug,
and apologies for the breakage.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Tested-by: Cory Maccarrone <darkstar6262@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Wrap mesh sections inside CONFIG_MAC80211_MESH to fix compilation
problems reported by Stephen Rothwell, Larry Finger and Bruno Randolf.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The structure struct ieee80211_rx_status *rxs is no longer needed to be
passed to ath_rx_send_to_mac80211 function
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
With the current save power save implementation we assume a dtim period
of 1.This value is assigned based on a sanity check in the driver
eventhough we had not parsed it from mac80211.This patch obtains the actual
DTIM period from AP by parsing it from mac80211.Yet for handling
multicast traffic we may still have it as fixed rather than parsing it
from mac80211 .This does not breaks power save or anything as the sleep
duration is currently fixed in the driver.This patch may serve to improve
power save in the future by using dtim period for sleep duration and using
correct dtim period adhoc mode.
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
AUTOSLEEP feature is enabled only for AR9271 and AR9003 version
chipsets.So unlikely macro should be used only to check whether
auto-sleep feature is enabled
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath.ko is a common module shared between ath5k, ar9170usb, ath9k and ath9k_htc.
Adding driver specific data to the shared structure would impact all the
drivers. Handling USB device recognition for devices specific to ath9k_htc
can be handled within the driver itself.
Also, AR7010 refers to the processor used in both AR9280/AR9287 based
devices. Rename the device enumerations accordingly.
While at it, check properly for the bus type when choosing the EEPROM
base address for UB95.
Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
net/mac80211/mlme.c: In function 'ieee80211_sta_work':
net/mac80211/mlme.c:1981: warning: too many arguments for format
Introduced by commit 04ac3c0ee2
("mac80211: speed up AP probing using nullfunc frames").
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
One thing I missed in my WME series: Older hardware does not have enough
hardware queues to support WME. In this case we just set up one data queue. Use
the capability information to decide how many queues to set up.
Signed-off-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In a situation where Smack access rules allow processes
with multiple labels to write to a directory it is easy
to get into a situation where the directory gets cluttered
with files that the owner can't deal with because while
they could be written to the directory a process at the
label of the directory can't write them. This is generally
the desired behavior, but when it isn't it is a real
issue.
This patch introduces a new attribute SMACK64TRANSMUTE that
instructs Smack to create the file with the label of the directory
under certain circumstances.
A new access mode, "t" for transmute, is made available to
Smack access rules, which are expanded from "rwxa" to "rwxat".
If a file is created in a directory marked as transmutable
and if access was granted to perform the operation by a rule
that included the transmute mode, then the file gets the
Smack label of the directory instead of the Smack label of the
creating process.
Note that this is equivalent to creating an empty file at the
label of the directory and then having the other process write
to it. The transmute scheme requires that both the access rule
allows transmutation and that the directory be explicitly marked.
Signed-off-by: Jarkko Sakkinen <ext-jarkko.2.sakkinen@nokia.com>
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
This decreases spammage in the log. A single line message
will still be printed, so users can be aware that problem
exists.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Acked-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
sidtab_context_to_sid takes up a large share of time when creating large
numbers of new inodes (~30-40% in oprofile runs). This patch implements a
cache of 3 entries which is checked before we do a full context_to_sid lookup.
On one system this showed over a x3 improvement in the number of inodes that
could be created per second and around a 20% improvement on another system.
Any time we look up the same context string sucessivly (imagine ls -lZ) we
should hit this cache hot. A cache miss should have a relatively minor affect
on performance next to doing the full table search.
All operations on the cache are done COMPLETELY lockless. We know that all
struct sidtab_node objects created will never be deleted until a new policy is
loaded thus we never have to worry about a pointer being dereferenced. Since
we also know that pointer assignment is atomic we know that the cache will
always have valid pointers. Given this information we implement a FIFO cache
in an array of 3 pointers. Every result (whether a cache hit or table lookup)
will be places in the 0 spot of the cache and the rest of the entries moved
down one spot. The 3rd entry will be lost.
Races are possible and are even likely to happen. Lets assume that 4 tasks
are hitting sidtab_context_to_sid. The first task checks against the first
entry in the cache and it is a miss. Now lets assume a second task updates
the cache with a new entry. This will push the first entry back to the second
spot. Now the first task might check against the second entry (which it
already checked) and will miss again. Now say some third task updates the
cache and push the second entry to the third spot. The first task my check
the third entry (for the third time!) and again have a miss. At which point
it will just do a full table lookup. No big deal!
Signed-off-by: Eric Paris <eparis@redhat.com>
Right now it is done for only AR9485, will be done for ar9003 also
after proper testing.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Also spur channel count and range is different for AR9485.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This helper function would be used for AR9485.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
