We would free the proper number of curves, but in the wrong
slots, due to a missing level of indirection through
the pdgain_idx table.

It's simpler just to try to free all four slots, so do that.

Cc: stable@kernel.org
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When no interface has been brought up, the chip's power
state continued as AWAKE. So during resume, the chip never
been powered up.

Cc: stable@kernel.org
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This module and a bunch of dependancies are getting loaded on several
of laptops I have (probably picking up the mobile broadband device),
that have nothing to do with zaurus. Matching by class without
any vendor/device pair isn't the right thing to do here, as it
will prevent any other driver from correctly binding to it.
(Or in the absense of a driver, will just waste time & memory by
 unnecessarily loading modules)
Signed-off-by: NDave Jones <davej@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The two options "CAN bit-timing calculation" and
"Platform CAN drivers with Netlink support" have a "default Y". In order to
activate them by default, change to "default y".
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Acked-by: NWolfgang Grandegger <wg@grandegger.com>
Acked-by: NKurt Van Dijck <kurt.van.dijck@eia.be>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Function rionet_remove initializes local variable 'ndev' to NULL
and do nothing changes before the call to unregister_netdev(ndev),
this could cause a NULL pointer dereference.
Reported-by: NJesper Juhl <jj@chaosbits.net>
Signed-off-by: NYinglin Luan <synmyth@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

They are 64K and result in order-4 allocations, even with SLUB.

Therefore, just like we always have for the deflate buffers, use
vmalloc.
Reported-by: NMartin Jackson <mjackson220.list@gmail.com>
Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

"iwlagn: map command buffers BIDI" uses the DMA_* enumerations for DMA
directions, even though the pci_* DMA API is still in use.  That patch
was undoubtedly developed on top of "iwlagn: don't use the PCI wrappers
for DMA operation", which is due in the next release.
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently (3.0-rc2), modinfo iwlagn shows:
    firmware:       iwlwifi-5150-IWL5150_UCODE_API_MAX.ucode
    firmware:       iwlwifi-5000-IWL5000_UCODE_API_MAX.ucode
    firmware:       iwlwifi-6000g2b-IWL6000G2_UCODE_API_MAX.ucode
    firmware:       iwlwifi-6000g2a-IWL6000G2_UCODE_API_MAX.ucode
    firmware:       iwlwifi-6050-IWL6050_UCODE_API_MAX.ucode
    firmware:       iwlwifi-6000-IWL6000_UCODE_API_MAX.ucode
    firmware:       iwlwifi-100-IWL100_UCODE_API_MAX.ucode
    firmware:       iwlwifi-1000-IWL1000_UCODE_API_MAX.ucode
    firmware:       iwlwifi-105-IWL105_UCODE_API_MAX.ucode
    firmware:       iwlwifi-2030-IWL2030_UCODE_API_MAX.ucode
    firmware:       iwlwifi-2000-IWL2000_UCODE_API_MAX.ucode

which is obviously wrong, the user should not see the *_UCODE_API_MAX
macros but the actual ucode API versions here.

The problem are the
    #define *_MODULE_FIRMWARE(api) *_FW_PRE #api ".ucode"
which do not expand api correctly (because this is a macro itself).

Fixed by using __stringify() from linux/stringify.h.

Further information about macro stringification can be found here:
    http://gcc.gnu.org/onlinedocs/cpp/Stringification.htmlSigned-off-by: NEvgeni Golov <sargentd@die-welt.net>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Evidently, the device sometimes wants to write back
to command buffers, even if I see no reason why it
should. Allow it to do that.
Tested-by: NAndy Lutomirski <luto@mit.edu>
Tested-by: NKyle McMartin <kyle@redhat.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

When we stop the device while a command is in
flight that uses multiple TBs, we can leak the
DMA buffers for the second and higher TBs. Fix
this by using iwlagn_unmap_tfd() as we do when
we normally recover the entry.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Fixed call to skb_record_rx_queue where we were passing the queue index
relative to the adapter when it should have been relative to the net_device.
Signed-off-by: NJohn (Jay) Hernandez <jay@chelsio.com>
Signed-off-by: NDivy Le Ray <divy@chelsio.com>
Reported-by: NShawn Bohrer <sbohrer@rgmadvisors.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When an interface changes type to a P2P type,
iwlagn will erroneously set vif->type to the
P2P type and not the reduced/split type. Fix
this by keeping "newtype" in another variable
for the assignment to vif->type.

Cc: stable@kernel.org [2.6.38+]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Since we don't have HUGE command any more, there is no point in adding 1
to the num of slots in the command queue. Doing so is buggy and might corrupt
memory.

Bug introduced by 4ce7cc2b
iwlagn: support multiple TBs per command

Cc: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>

"status" should be an int here for the error handling to work.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

-Support for big endian.
-Do not use USB buffers at the stack.
-Safer/more efficient code for local constants.
Signed-off-by: NMarius B. Kotsbak <marius@kotsbak.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In commit 3ac5e26a entitled
"rtlwifi: rtl8192c-common: Change common firmware routines for addition
of rtl8192se and rtl8192de", the firmware loading code was moved.
Unfortunately, some necessary code was dropped for rtl8192cu.

The dmesg output shows the following:

rtl8192c: Loading firmware file rtlwifi/rtl8192cufw.bin
rtl8192c_common:_rtl92c_fw_free_to_go():<0-0> Polling FW ready fail!! REG_MCUFWDL:0x00000006 .
rtl8192c_common:rtl92c_download_fw():<0-0> Firmware is not ready to run!

In addition, the interface will authenticate and associate, but cannot
transfer data.

This is reported as Kernel Bug #38012.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When NETCONSOLE_DYNAMIC=y and CONFIGFS_FS=m, there are build errors
in netconsole:

drivers/built-in.o: In function `drop_netconsole_target':
netconsole.c:(.text+0x1a100f): undefined reference to `config_item_put'
drivers/built-in.o: In function `make_netconsole_target':
netconsole.c:(.text+0x1a10b9): undefined reference to `config_item_init_type_name'
drivers/built-in.o: In function `write_msg':
netconsole.c:(.text+0x1a11a4): undefined reference to `config_item_get'
netconsole.c:(.text+0x1a1211): undefined reference to `config_item_put'
drivers/built-in.o: In function `netconsole_netdev_event':
netconsole.c:(.text+0x1a12cc): undefined reference to `config_item_put'
netconsole.c:(.text+0x1a12ec): undefined reference to `config_item_get'
netconsole.c:(.text+0x1a1366): undefined reference to `config_item_put'
drivers/built-in.o: In function `init_netconsole':
netconsole.c:(.init.text+0x953a): undefined reference to `config_group_init'
netconsole.c:(.init.text+0x9560): undefined reference to `configfs_register_subsystem'
drivers/built-in.o: In function `dynamic_netconsole_exit':
netconsole.c:(.exit.text+0x809): undefined reference to `configfs_unregister_subsystem'

so fix the NETCONSOLE_DYNAMIC depends clause to prevent this.
Based on email suggestion from Ben Hutchings.  Thanks.

Fixes https://bugzilla.kernel.org/show_bug.cgi?id=37992Reported-by: NDavid Hill <hilld@binarystorm.net>
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Cc: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

0xff01 is not an actual voltage value, but a flag
for the driver.  If the power state as that value,
skip setting the voltage.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Because the socket buffer is freed in the completion interrupt, it is not
safe to access it after submitting it to the hardware.

Cc: stable@kernel.org
Cc: Sachin Sanap <ssanap@marvell.com>
Cc: Zhangfei Gao <zgao6@marvell.com>
Cc: Philip Rakity <prakity@marvell.com>
Signed-off-by: NRichard Cochran <richard.cochran@omicron.at>
Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

As soon as skb is given to hardware, TX completion can free skb under
us.
Therefore, we should update dev stats before kicking the device.
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
CC: Amit Kumar Salecha <amit.salecha@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There are two devices with PCI ID 0x10ec:0x8192, namely RTL8192E and
RTL8192SE. The method of distinguishing them is by the revision ID
at offset 0x8 of the PCI configuration space. If the value is 0x10,
then the device uses rtl8192se for a driver.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

this printk isn't really useful, just drop it for now.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Since we were calling the wptr function before checking if the IH was
even enabled, or the GPU wasn't shutdown, we'd get spam in the logs when
the GPU readback 0xffffffff. This reorders things so we return early
in the no IH and GPU shutdown cases.

Reported-and-tested-by: ManDay on #radeon
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is used during phy init to set up the phy for DP.  This may
fix DP problems on DCE3.2 cards.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Certain revisions of the vbios on DCE3.2 cards have a bug
in the transmitter control table which prevents duallink from
being enabled properly on some cards.  The action switch statement
jumps to the wrong offset for the OUTPUT_ENABLE action.  The fix
is to use the ENABLE action rather than the OUTPUT_ENABLE action
on the affected cards.  In fixed version of the vbios, both
actions jump to the same offset, so the change should be safe.
Reported-and-tested-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Its illegal to dereference skb after dev_kfree_skb(skb)
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
CC: Robin Holt <holt@sgi.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

As soon as skb is given to hardware and spinlock released, TX completion
can free skb under us. Therefore, we should update netdev stats before
spinlock release.
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Otherwise we will not see the name of the slave dev in error
message:

[  388.469446] (null):  doesn't support polling, aborting.
Signed-off-by: NWANG Cong <amwang@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

According to the data sheet for G4, AP4 and AG5 KEYSC MODE_6 is 8x8 keys.
Bump up MAXKEYS to 64 too.
Signed-off-by: NMagnus Damm <damm@opensource.se>
Reviewed-by: NSimon Horman <horms@verge.net.au>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

Otherwise the updated evdev driver (commit cdda911c,
"Input: evdev - only signal polls on full packets") no longer works on
top of omap-keypad.

Tested on Amstrad Delta.
Signed-off-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Reviewed-by: NHenrik Rydberg <rydberg@euromail.se>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

We should only wake waiters on the event device when we actually post
an EV_SYN/SYN_REPORT to the queue. Otherwise we end up making waiting
threads runnable only to go right back to sleep because the device
still isn't readable.
Reported-by: NJeffrey Brown <jeffbrown@android.com>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

Initialize dynamically allocated sysfs attributes before device_create_file()
call to suppress lockdep_init_map() warning if lockdep debugging is enabled.
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
Acked-by: NJean Delvare <khali@linux-fr.org>
Cc: stable@kernel.org # 2.6.34+

Initialize dynamically allocated sysfs attributes before device_create_file()
call to suppress lockdep_init_map() warning if lockdep debugging is enabled.
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
Acked-by: NJean Delvare <khali@linux-fr.org>
Cc: stable@kernel.org # 2.6.34+

Initialize dynamically allocated sysfs attributes before device_create_file()
call to suppress lockdep_init_map() warning if lockdep debugging is enabled.
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
Acked-by: NJean Delvare <khali@linux-fr.org>
Cc: stable@kernel.org # 2.6.34+

Call sysfs_attr_init() from atk_init_attribute() to handle sysfs attribute
initialization in a single function.
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
Cc: Luca Tettamanti <kronos.it@gmail.com>
Acked-by: NJean Delvare <khali@linux-fr.org>

pdev_entry.cpu and pdev_entry.cpu_core_id aren't used anywhere in the
driver code so we can drop these struct members.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Guenter Roeck <guenter.roeck@ericsson.com>
Cc: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>

The DDX modifies DMA_SEMAPHORE on nv50 in order to implement sync-to-vblank,
things will go very wrong for cross-channel sync after this.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

While parsing the perf table, there is no check if
the num of entries read from the vbios is less than
the currently allocated number.

In case of a buggy vbios this will cause overwriting
of kernel memory, causing aditional problems.

Add a simple check in order to prevent the case
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>