drop extra argument, move cast
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch reverts the commit dba3c29ea4.
After bisecting, this commit dba3c29 is found to ruin micro-SD card data
(writing incorrect file, or fs is corrupt after several times mount)
on the beagle-xm revB, and reverting the commit will fix the problem.
Also from TRM of OMAP3/OMAP4/DM37x, the below is mentioned about
the Auto CMD12 Enable bit.
- SDIO does not support this feature.
- SD card only.
Looks it is not suitable to always enable Auto CMD12 in host controller
driver.
Considered that the commit is not mature enough, so ask to revert it
first.
Cc: Balaji T K <balajitk@ti.com>
Cc: Venkatraman S <svenkatr@ti.com>
Buglink: https://lkml.org/lkml/2012/6/10/225
Reported-by: Paolo Pisati <p.pisati@gmail.com>
Reported-bisected-and-tested-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Acked-by: Venkatraman S <svenkatr@ti.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
If multi block write operation fails for SD card, during
error handling we send the SD_APP_SEND_NUM_WR_BLKS (ACMD22)
to know how many blocks were already programmed by card.
But mmc_sd_num_wr_blocks() function which sends the ACMD22
calculates the data timeout value from csd.tacc_ns and
csd.tacc_clks parameters which will be 0 for block addressed
(>2GB cards) SD card. This would result in timeout_ns and
timeout_clks being 0 in the mmc_request passed to host driver.
This means host controller would program its data timeout timer
value with 0 which could result in DATA TIMEOUT errors from
controller.
To fix this issue, mmc_sd_num_wr_blocks() should instead
just call the mmc_set_data_timeout() to calculate the
data timeout value. mmc_set_data_timeout() function
ensures that non zero timeout value is set even for
block addressed SD cards.
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Reviewed-by: Venkatraman S <svenkatr@ti.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
The recent changes to the printk buffer management resulted in
SYSLOG_ACTION_READ to only return a single message, whereas previously
the buffer would get filled as much as possible. As, when too small to
fit everything, filling it to the last byte would be pretty ugly with
the new code, the patch arranges for as many messages as possible to
get returned in a single invocation. User space tools in at least all
SLES versions depend on the old behavior.
This at once addresses the issue attempted to get fixed with commit
b56a39ac26 ("printk: return -EINVAL if
the message len is bigger than the buf size"), and since that commit
widened the possibility for losing a message altogether, the patch
here assumes that this other commit would get reverted first
(otherwise the patch here won't apply).
Furthermore, this patch also addresses the problem dealt with in
commit 4a77a5a06e ("printk: use mutex
lock to stop syslog_seq from going wild"), so I'd recommend reverting
that one too (albeit there's no direct collision between the two).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kay Sievers <kay@vrfy.org>
Cc: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit b56a39ac26.
A better patch from Jan will follow this to resolve the issue.
Acked-by: Kay Sievers <kay@vrfy.org>
Cc: Fengguang Wu <wfg@linux.intel.com>
Cc: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Cc: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rename the driver name of the clock entry of Tegra APBDMA to
tegra-apbdma from of tegra-dma.
This name is more aligned towards the movement of dmaengine based
new DMA driver.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
intel_ips driver spews the warning message
"ME failed to update for more than 1s, likely hung"
at each second endlessly on HP ProBook laptops with IronLake.
As this has never worked, better to blacklist the driver for now.
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
We only initialize the high bits of "cfg". It probably doesn't cause
a problem given that this is platform specific code and doesn't have to
worry about endianness etc. But it's sort of messy.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Since bab7084c74, find_snc_handle
returns -EINVAL, not -1.
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
This needs to be signed to handle negative error codes.
Remove a redundant check, read_limits is always called with a valid
handle.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
We made this an unsigned long and it causes a bug on 64 bit big endian
systems when we try to pass the value to sony_nc_int_call().
Also value has to be signed because validate() returns negative error
codes.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
SNC needs input devices so better have those ready before starting
handle events.
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Some models offer the option to store the limits on the battery
(firmware?).
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Some Vaios come with both integrated and discrete graphics, plus a
switch for choosing one of the two. When the switch position is changed,
a notification is generated.
Signed-off-by: Marco Chiappero <marco@absence.it>
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Remove the radio enable/disable stuff and fix the
transition to FULL_SLEEP mode when the device is idle.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211 adds stations in HT IBSS as soon as a frame comes by,
even if the HT capabilities are not known yet (they are often
received later, e.g. in beacons). So far, ampdu factor/density
are only calculated when the station is initially added.
This patch changes this to update ampdu factor/density settings
when starting a blockack session.
Using this patch, we had performance boosts from 60 to 150 MBit/s
between two 2x2 Atheros devices in 5 GHz HT IBSS mode.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The command "make includecheck" yields the following for the rtlwifi tree:
/home/finger/linux-2.6/drivers/net/wireless/rtlwifi/rtl8192se/sw.c: ../pci.h is included more than once.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Pull drm fixes from Dave Airlie:
"Just two changes: one udl endian fix, one nouveau memory corruption on
some GPUs."
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/nouveau/fbcon: using nv_two_heads is not a good idea
drm/udl: Make sure to get correct endian keys from vendor descriptor
Pull HID fixes from Jiri Kosina:
"The most important one is a purification of Kconfig for CONFIG_HID;
the inclusion of HID groups and autoloading didn't leave the Kconfig
in a really consistent state. Henrik's patch fixes that. In addition
to that, there are two small fixes for logitech and magicmouse
drivers."
* 'upstream-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
HID: Fix the generic Kconfig options
HID: magicmouse: Correct report range of major / minor axes
HID: logitech: don't use stack based dj_report structures
As recovery queuing can now occur from multiple code paths
it's convenient to know what triggered it in all cases
other than an intended recovery which is part of the
switch between single role to multi role.
Signed-off-by: Eyal Shapira <eyal@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Following the addition of propagating errors from the bus ops
there's a need to distinguish between bus errors (including timeout)
and a legitimate timeout occuring in cmd_wait_for_event_or_timeout.
In case of real bus errors we need to queue recovery even in cases
where a timeout on a response from the FW to a command is acceptable.
Reported-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Eyal Shapira <eyal@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
commit 14bba17b "wl12xx: Propagate errors from wl1271_raw_write32"
breaks down TX in certain scenarios. wl1271_irq_locked() propagates
errors from wl1271_tx_work_locked however it may return -EBUSY
when the FW queues are full which is a legitimate case and not a
a real error. In this case a recovery is triggered by wl1271_irq
and this keeps repeating itself so TX is completely broken.
Fix it by avoiding propagating return values as errors even if they
aren't. Only bus (SDIO or SPI) ops failures would be progagated
as only these should trigger recovery.
Signed-off-by: Eyal Shapira <eyal@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
We need to release the IRQ if hw_info() or identify_chip() fails. And
we need unregister the HW with mac80211 if there are any failures
after it's registered.
Signed-off-by: Luciano Coelho <coelho@ti.com>
The new PG2 version of the chip has a few differences in terms of FW
API if compared to PG1. PG1 is just a sample that shouldn't be used
in real life, so to avoid having to handle both separately, mark the
PG1 version as deprecated and bail out during probe.
Signed-off-by: Luciano Coelho <coelho@ti.com>
The recent fix for power-map controls (commit b0791dda81) caused
regressions on some other HP laptops. They have fixed pins but these
pins are exposed as jack-detectable. Thus the driver tries to control
the power-map dynamically per jack detection where it never gets on.
This patch adds the check of connection and it assumes the no jack
detection is available for fixed pins no matter what pin capability
says.
BugLink: http://bugs.launchpad.net/bugs/1013183
Reported-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
There was a stray %s left from testing, remove it.
Add -w to the #! line (which is parsed by Perl even if the Perl
interpreter is invoked explicitly on the command line) to catch these
kinds of errors in the future.
Reported-by: Jean Delvare <khali@linux-fr.org>
Link: http://lkml.kernel.org/r/20120626143246.0c9bf301@endymion.delvare
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
The PCI core provides a generic pcibios_setup() routine. Drop this
architecture-specific version in favor of that.
Acked-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Myron Stowe <myron.stowe@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Currently, all of the architectures implement their own pcibios_setup()
routine. Most of the implementations do nothing so this patch introduces
a generic (__weak) routine in the core that can be used by all
architectures as a default. If necessary, it can be overridden by
architecture-specific code.
Signed-off-by: Myron Stowe <myron.stowe@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
nv_two_heads() was never meant to be used outside of pre-nv50 code. The
code checks for >= NV_10 for 2 CRTCs, then downgrades a few specific
chipsets to 1 CRTC based on (pci_device & 0x0ff0).
The breakage example seen is on GTX 560Ti, with a pciid of 0x1200, which
gets detected as an NV20 (0x020x) with 1 CRTC by nv_two_heads(), causing
memory corruption because there's actually 2 CRTCs..
This switches fbcon to use the CRTC count directly from the mode_config
structure, which will also fix the same issue on Kepler boards which have
4 CRTCs.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Sometimes it may be useful to allow a device to request a supply multiple
times, for example in order to allow framework management of some uses of
the supply with some additional driver specific management or in order to
allow multiple children of an MFD to work with the supply. Currently this
is not possible due to the creation of
Solve this by removing the requested_uA entry (we have no current users
of this feature anyway) and ignoring errors creating the symlink to the
consumer. We should do something nicer than this as this causes sysfs to
spew enormous warnings but it allows users to run for now.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
