- 14 11月, 2012 1 次提交
-
-
由 Emmanuel Grumbach 提交于
The allocation failure will already be very verbose. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 10 11月, 2012 1 次提交
-
-
由 Johannes Berg 提交于
When a firmware error occurs, don't just abort synchronous commands but also return an error (-EIO) and block any new commands as well. Currently, an error is only returned if WANT_SKB was set which is confusing and can lead to issues. Blocking is done until a new firmware image is loaded. Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 07 11月, 2012 4 次提交
-
-
由 Johannes Berg 提交于
The printk message should say RX, not TX. Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
There's no need to print the PCI resource length and base address, nor the hardware revision ID (which can be found in lspci) Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
There's no reason to print these all the time, the messages aren't all that interesting. Leave them as DEBUG_INFO though, just in case. Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
If the EEPROM reading was successful, don't print a message by default, the EEPROM version isn't all that interesting. Change the message to DEBUG_INFO priority so it can still be obtained. Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 05 11月, 2012 6 次提交
-
-
由 Emmanuel Grumbach 提交于
People tend not to set the fields they want to leave as 0. So make sure the struct is zeroed properly. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Emmanuel Grumbach 提交于
The ALIVE response of new fw inclues the base address of the SCD in SRAM. Until we read it from a prph register, which was set by the fw. Since the fw might well stop updating the prph register, add a WARN when there is an inconsitency between the ALIVE response and the register to catch any change in the behavior. Reviewed-by: NGregory Greenman <gregory.greenman@intel.com> Reviewed-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Instead of open-coding it with a temporary list_head pointer, just use list_first_entry. Reviewed-by: NGregory Greenman <gregory.greenman@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
The flush_control parameter to iwlagn_txfifo_flush is passed as an internal value (context flags) and then sent to the device, that can't be right. Fix the confusion by removing the parameter, always use IWL_DROP_ALL that is redefined according to the firmware API in the flush control. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
There's no reason to clear the CTL_AMPDU flag on transmitted frame status, it's not used by the driver here and mac80211 only uses it for some rate statistics. Also remove a stray space in the function. Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
The flush command really flushes queues, not FIFOs, and the first 32 bits indicate the queues to flush, not FIFOs. Change the command accordingly. Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 01 11月, 2012 2 次提交
-
-
由 Emmanuel Grumbach 提交于
When we unregister from mac80211 it will down the device anyway. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Emmanuel Grumbach 提交于
No HCMD can be sent while RFKILL is asserted. If a SYNC command is running while RFKILL is asserted the fw will silently discard it. This means that the driver needs to wake the process that sleeps on the CMD_SYNC. Since the RFKILL interrupt is handled in the transport layer and the code that sleeps in CMD_SYNC is also in the transport layer, all this logic can be handled there. This simplifies the work of the op_mode. So the transport layer will now return -ERFKILL when a CMD is sent and RFKILL is asserted. This will be the case even when the CMD is SYNC. The transport layer will return -ERFKILL straight away. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 29 10月, 2012 2 次提交
-
-
由 Johannes Berg 提交于
Clarify the documentation to indicate that these flags can only be used at the end, i.e. after them a copy TFD (no flags set) is invalid. Reported-by: NInbal Hacohen <inbal.hacohen@intel.com> Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
In addition to the NOCOPY flag, add a DUP flag that tells the transport to kmemdup() the buffer and free it after the command completes. Currently this is only supported for a single buffer in a given command, but that could be extended if it should be needed. Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 23 10月, 2012 2 次提交
-
-
由 Assaf Krauss 提交于
Remove the Kconfig option CONFIG_IWLWIFI_EXPERIMENTAL_MFP, if the firmware doesn't support MFP then the user shouldn't have the option to enable it as it won't work correctly. Signed-off-by: NAssaf Krauss <assaf.krauss@intel.com> Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Emmanuel Grumbach 提交于
Since the queue might not be empty, we need to free the pending Tx packets. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 16 10月, 2012 8 次提交
-
-
由 Emmanuel Grumbach 提交于
This can happen when we shut down suddenly an interface. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Emmanuel Grumbach 提交于
Once in bus enumeration is enough, no need to print it again when the op_mode loads. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Emmanuel Grumbach 提交于
Doing the opposite is wrong, the SCD wouldn't like someone to clear its data while the queue is still active. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Emmanuel Grumbach 提交于
Instead of hardcoding the expression, use the macro provided in the previous patch. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Emmanuel Grumbach 提交于
When we disable a queue, we don't want the SCD to remember anything about this queue (what packet was transmitted but not acked, what packed was acked etc...). Wipe out all this data in its SRAM. Constify the arguments to iwl_write_targ_mem_dwords on the way. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Remove a number of variables that are assigned, but not used. Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
When tracing in iwlwifi, we get all data. Most of the time, we don't need it, and it just takes up a lot of extra space in the trace. Make this optional by recording the data into two separate trace events if it is needed. Without it, record only the content of non-data and EAPOL TX frames. As a result, tracing without the data tracepoints will record meta information including the 802.11 headers for all frames but will not record the contents of data frames to reduce trace overhead. Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
When warning about a command that is too large, print out the command name/ID to help figure out which place is attempting to send a command that is too large. Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 13 10月, 2012 5 次提交
-
-
由 Mikulas Patocka 提交于
Use the recently-added bio front_pad field to allocate struct dm_target_io. Prior to this patch, dm_target_io was allocated from a mempool. For each dm_target_io, there is exactly one bio allocated from a bioset. This patch merges these two allocations into one allocation: we create a bioset with front_pad equal to the size of dm_target_io so that every bio allocated from the bioset has sizeof(struct dm_target_io) bytes before it. We allocate a bio and use the bytes before the bio as dm_target_io. _tio_cache is removed and the tio_pool mempool is now only used for request-based devices. This idea was introduced by Kent Overstreet. Signed-off-by: NMikulas Patocka <mpatocka@redhat.com> Cc: Kent Overstreet <koverstreet@google.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: tj@kernel.org Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Bill Pemberton <wfp5p@viridian.itc.virginia.edu> Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
-
由 Mike Snitzer 提交于
The bio prison code will be useful to other future DM targets so move it to a separate module. Signed-off-by: NMike Snitzer <snitzer@redhat.com> Signed-off-by: NJoe Thornber <ejt@redhat.com> Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
-
由 Mike Snitzer 提交于
The bio prison code will be useful to share with future DM targets. Prepare to move this code into a separate module, adding a dm prefix to structures and functions that will be exported. Signed-off-by: NMike Snitzer <snitzer@redhat.com> Signed-off-by: NJoe Thornber <ejt@redhat.com> Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
-
由 Mike Snitzer 提交于
Support discards when the pool's block size is not a power of 2. The block layer assumes discard_granularity is a power of 2 (in blkdev_issue_discard), so we set this to the largest power of 2 that is a divides into the number of sectors in each block, but never less than DATA_DEV_BLOCK_SIZE_MIN_SECTORS. This patch eliminates the "Discard support must be disabled when the block size is not a power of 2" constraint that was imposed in commit 55f2b8bd ("dm thin: support for non power of 2 pool blocksize"). That commit was incomplete: using a block size that is not a power of 2 shouldn't mean disabling discard support on the device completely. Signed-off-by: NMike Snitzer <snitzer@redhat.com> Signed-off-by: NJoe Thornber <ejt@redhat.com> Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
-
由 Ondrej Zary 提交于
The device had an undocumented "feature": it can provide a sequence of spurious link-down status data even if the link is up all the time. A sequence of 10 was seen so update the link state only after the device reports the same link state 20 times. Signed-off-by: NOndrej Zary <linux@rainbow-software.org> Reported-by: NMichael Leun <lkml20120218@newton.leun.net> Tested-by: NMichael Leun <lkml20120218@newton.leun.net> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 12 10月, 2012 9 次提交
-
-
由 Wei Yongjun 提交于
Convert cpu_to_le32(le32_to_cpu(E1) + E2) to use le32_add_cpu(). dpatch engine is used to auto generate this patch. (https://github.com/weiyj/dpatch) Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
-
由 Mikulas Patocka 提交于
Use the ACCESS_ONCE macro in dm-bufio and dm-verity where a variable can be modified asynchronously (through sysfs) and we want to prevent compiler optimizations that assume that the variable hasn't changed. (See Documentation/atomic_ops.txt.) Signed-off-by: NMikulas Patocka <mpatocka@redhat.com> Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
-
由 Wei Yongjun 提交于
Use list_move() instead of list_del() + list_add(). spatch with a semantic match was used to find this. (http://coccinelle.lip6.fr/) Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
-
由 Wei Yongjun 提交于
The mpio dereference should be moved below the BUG_ON NULL test in multipath_end_io(). spatch with a semantic match was used to found this. (http://coccinelle.lip6.fr/) Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
-
由 Konrad Rzeszutek Wilk 提交于
The commit 254d1a3f, titled "xen/pv-on-hvm kexec: shutdown watches from old kernel" assumes that the XenBus backend can deal with reading of values from: "control/platform-feature-xs_reset_watches": ... a patch for xenstored is required so that it accepts the XS_RESET_WATCHES request from a client (see changeset 23839:42a45baf037d in xen-unstable.hg). Without the patch for xenstored the registration of watches will fail and some features of a PVonHVM guest are not available. The guest is still able to boot, but repeated kexec boots will fail." Sadly this is not true when using a Xen 3.4 hypervisor and booting a PVHVM guest. We end up hanging at: err = xenbus_scanf(XBT_NIL, "control", "platform-feature-xs_reset_watches", "%d", &supported); This can easily be seen with guests hanging at xenbus_init: NX (Execute Disable) protection: active SMBIOS 2.4 present. DMI: Xen HVM domU, BIOS 3.4.0 05/13/2011 Hypervisor detected: Xen HVM Xen version 3.4. Xen Platform PCI: I/O protocol version 1 ... snip .. calling xenbus_init+0x0/0x27e @ 1 Reverting the commit or using the attached patch fixes the issue. This fix checks whether the hypervisor is older than 4.0 and if so does not try to perform the read. Fixes-Oracle-Bug: 14708233 CC: stable@vger.kernel.org Acked-by: NOlaf Hering <olaf@aepfle.de> [v2: Added a comment in the source code] Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
由 Jason Wessel 提交于
It is possible to miss data when using the kdb pager. The kdb pager does not pay attention to the maximum column constraint of the screen or serial terminal. This result is not incrementing the shown lines correctly and the pager will print more lines that fit on the screen. Obviously that is less than useful when using a VGA console where you cannot scroll back. The pager will now look at the kdb_buffer string to see how many characters are printed. It might not be perfect considering you can output ASCII that might move the cursor position, but it is a substantially better approximation for viewing dmesg and trace logs. This also means that the vt screen needs to set the kdb COLUMNS variable. Cc: <stable@vger.kernel.org> Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
-
由 Jason Wessel 提交于
It is a common enough mistake for people to specify "kdb" when they meant to type "kbd" that the kgdboc can just accept both since they both mean the same thing anyway. Specifically it is for the case where you want kdb to be active on your graphics console + keyboard (where kbd was the original abbreviation for keyboard). With this change kgdboc will now accept either to mean the same thing: kgdboc=kbd kgdboc=kdb Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
-
由 Marek Vasut 提交于
The following error appeared due to a merge problem; the patches: fc108d24 "mmc: mxs-mmc: fix deadlock caused by recursion loop" 829c1bf4 "mmc: spi: Pull out parts shared between MMC and SPI" came in through separate branches and cause this build error when combined. drivers/mmc/host/mxs-mmc.c: In function 'mxs_mmc_enable_sdio_irq': drivers/mmc/host/mxs-mmc.c:527:3: error: 'struct mxs_mmc_host' has no member named 'base' drivers/mmc/host/mxs-mmc.c:527:3: error: 'struct mxs_mmc_host' has no member named 'devid' make[3]: *** [drivers/mmc/host/mxs-mmc.o] Error 1 This patch corrects the issue. Signed-off-by: NMarek Vasut <marex@denx.de> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Oliver Neukum 提交于
Some device types support a form of power management in which the device suggests to the host that the device may be suspended now. Support for that is best located in usbnet. Signed-off-by: NOliver Neukum <oneukum@suse.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-