- 03 7月, 2011 1 次提交
-
-
由 Dan Williams 提交于
Support for the up to 2x4-port 6Gb/s SAS controllers embedded in the chipset. This is a snapshot of the first publicly available version of the driver, commit 4c1db2d0 in the 'historical' branch. git://git.kernel.org/pub/scm/linux/kernel/git/djbw/isci.git historical Signed-off-by: NMaciej Trela <maciej.trela@intel.com> Signed-off-by: NDave Jiang <dave.jiang@intel.com> Signed-off-by: NEdmund Nadolski <edmund.nadolski@intel.com> Signed-off-by: NDan Williams <dan.j.williams@intel.com>
-
- 05 6月, 2011 1 次提交
-
-
由 Per Dalén 提交于
Improve detection of MAX6642 by reading non existing registers (0x04, 0x06 and 0xff). Reading those registers returns the previously read value. Signed-off-by: NPer Dalen <per.dalen@appeartv.com> [guenter.roeck@ericsson.com: added second set of register reads] Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
-
- 04 6月, 2011 1 次提交
-
-
由 Linus Torvalds 提交于
This reverts commit b1c43f82. It was broken in so many ways, and results in random odd pty issues. It re-introduced the buggy schedule_work() in flush_to_ldisc() that can cause endless work-loops (see commit a5660b41: "tty: fix endless work loop when the buffer fills up"). It also used an "unsigned int" return value fo the ->receive_buf() function, but then made multiple functions return a negative error code, and didn't actually check for the error in the caller. And it didn't actually work at all. BenH bisected down odd tty behavior to it: "It looks like the patch is causing some major malfunctions of the X server for me, possibly related to PTYs. For example, cat'ing a large file in a gnome terminal hangs the kernel for -minutes- in a loop of what looks like flush_to_ldisc/workqueue code, (some ftrace data in the quoted bits further down). ... Some more data: It -looks- like what happens is that the flush_to_ldisc work queue entry constantly re-queues itself (because the PTY is full ?) and the workqueue thread will basically loop forver calling it without ever scheduling, thus starving the consumer process that could have emptied the PTY." which is pretty much exactly the problem we fixed in a5660b41. Milton Miller pointed out the 'unsigned int' issue. Reported-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Reported-by: NMilton Miller <miltonm@bga.com> Cc: Stefan Bigler <stefan.bigler@keymile.com> Cc: Toby Gray <toby.gray@realvnc.com> Cc: Felipe Balbi <balbi@ti.com> Cc: Greg Kroah-Hartman <gregkh@suse.de> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 03 6月, 2011 1 次提交
-
-
由 Matt Carlson 提交于
This function attempts to free one fragment beyond the number of fragments that were actually mapped. This patch brings back the limit to the correct spot. Signed-off-by: NMatt Carlson <mcarlson@broadcom.com> Tested-by: NAlex Williamson <alex.williamson@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 02 6月, 2011 13 次提交
-
-
由 James Bottomley 提交于
In certain circumstances, we can get an oops from a torn down device. Most notably this is from CD roms trying to call scsi_ioctl. The root cause of the problem is the fact that after scsi_remove_device() has been called, the queue is fully torn down. This is actually wrong since the queue can be used until the sdev release function is called. Therefore, we add an extra reference to the queue which is released in sdev->release, so the queue always exists. Reported-by: NParag Warudkar <parag.lkml@gmail.com> Cc: stable@kernel.org Signed-off-by: NJames Bottomley <jbottomley@parallels.com>
-
由 Julia Lawall 提交于
The failed_get label is used after the call to clk_get has succeeded, so it should be moved up above the call to clk_put. The failed_req labels doesn't do anything different than failed_get, so delete it. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r exists@ expression e1,e2; statement S; @@ e1 = clk_get@p1(...); ... when != e1 = e2 when != clk_put(e1) when any if (...) { ... when != clk_put(e1) when != if (...) { ... clk_put(e1) ... } * return@p3 ...; } else S // </smpl> Signed-off-by: NJulia Lawall <julia@diku.dk> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Guennadi Liakhovetski 提交于
A recent patch has introduced a regression, where repeating a memcpy DMA test with shdma module unloading between them skips the DMA channel configuration. Fix this regression by always configuring the channel during its allocation. Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
-
由 Mark Brown 提交于
Currently the DM9000 driver requests the primary interrupt before it resets the chip and puts it into a known good state. This means that if the chip is asserting interrupt for some reason we can end up with a screaming IRQ that the interrupt handler is unable to deal with. Avoid this by only requesting the interrupt after we've reset the chip so we know what state it's in. This started manifesting itself on one of my boards in the past month or so, I suspect as a result of some core infrastructure changes removing some form of mitigation against bad behaviour here, even when things boot it seems that the new code brings the interface up more quickly. Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Julia Lawall 提交于
Go to existing error handling code at the end of the function that calls clk_put. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r exists@ expression e1,e2; statement S; @@ e1 = clk_get@p1(...); ... when != e1 = e2 when != clk_put(e1) when any if (...) { ... when != clk_put(e1) when != if (...) { ... clk_put(e1) ... } * return@p3 ...; } else S // </smpl> Signed-off-by: NJulia Lawall <julia@diku.dk> Acked-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Stefan Metzmacher 提交于
This avoids messages like this after suspend: cdc_ncm 2-1.4:1.6: no reset_resume for driver cdc_ncm? cdc_ncm 2-1.4:1.7: no reset_resume for driver cdc_ncm? cdc_ncm 2-1.4:1.6: usb0: unregister 'cdc_ncm' usb-0000:00:1d.0-1.4, CDC NCM This is important for the Ericsson F5521gw GSM/UMTS modem. Otherwise modemmanager looses the fact that the cdc_ncm and cdc_acm devices belong together. The cdc_ether module does the same. Signed-off-by: NStefan Metzmacher <metze@samba.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Guenter Roeck 提交于
Further relax temperature range checks after reading the IA32_TEMPERATURE_TARGET register. If the register returns a value other than 0 in bits 16..32, assume that the returned value is correct. This change applies to both packet and core temperature limits. Cc: Carsten Emde <C.Emde@osadl.org> Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: Jean Delvare <khali@linux-fr.org> Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com> Acked-by: NFenghua Yu <fenghua.yu@intel.com>
-
由 Guenter Roeck 提交于
Commit a321cedb excludes CPU models 0xe, 0xf, 0x16, and 0x1a from TjMax temperature adjustment, even though several of those CPUs are known to have TiMax other than 100 degrees C, and even though the code in adjust_tjmax() explicitly handles those CPUs and points to a Web document listing several of the affected CPU IDs. Reinstate original TjMax adjustment if TjMax can not be determined using the IA32_TEMPERATURE_TARGET register. https://bugzilla.kernel.org/show_bug.cgi?id=32582Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com> Cc: Huaxu Wan <huaxu.wan@linux.intel.com> Cc: Carsten Emde <C.Emde@osadl.org> Cc: Valdis Kletnieks <valdis.kletnieks@vt.edu> Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Yong Wang <yong.y.wang@linux.intel.com> Cc: Rudolf Marek <r.marek@assembler.cz> Cc: Fenghua Yu <fenghua.yu@intel.com> Tested-by: NJean Delvare <khali@linux-fr.org> Acked-by: NJean Delvare <khali@linux-fr.org> Acked-by: NFenghua Yu <fenghua.yu@intel.com> Cc: <stable@kernel.org> # .35.x .36.x .37.x .38.x .39.x
-
由 Linus Torvalds 提交于
Jens' back-merge commit 698567f3 ("Merge commit 'v2.6.39' into for-2.6.40/core") was incorrectly done, and re-introduced the DISK_EVENT_MEDIA_CHANGE lines that had been removed earlier in commits - 9fd097b1 ("block: unexport DISK_EVENT_MEDIA_CHANGE for legacy/fringe drivers") - 7eec77a1 ("ide: unexport DISK_EVENT_MEDIA_CHANGE for ide-gd and ide-cd") because of conflicts with the "g->flags" updates near-by by commit d4dc210f ("block: don't block events on excl write for non-optical devices") As a result, we re-introduced the hanging behavior due to infinite disk media change reports. Tssk, tssk, people! Don't do back-merges at all, and *definitely* don't do them to hide merge conflicts from me - especially as I'm likely better at merging them than you are, since I do so many merges. Reported-by: NSteven Rostedt <rostedt@goodmis.org> Cc: Jens Axboe <jaxboe@fusionio.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Stanislaw Gruszka 提交于
In some cases we can read wrong temperature value. If after that temperature value will not be updated to good one, we badly configure tx power parameters and device is unable to send a data. Resolves: https://bugzilla.kernel.org/show_bug.cgi?id=35932 Cc: stable@kernel.org # 2.6.39+ Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Daniel Halperin 提交于
This is the same fix as commit 84105160 Author: Matteo Croce <technoboy85@gmail.com> Date: Fri Dec 3 02:25:08 2010 +0100 The ath9k driver subtracts 3 dBm to the txpower as with two radios the signal power is doubled. The resulting value is assigned in an u16 which overflows and makes the card work at full power. in two more places. I grepped the ath tree and didn't find any others. Cc: stable@kernel.org Signed-off-by: NDaniel Halperin <dhalperi@cs.washington.edu> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Jean Delvare 提交于
The current temperature range check of MSR_IA32_TEMPERATURE_TARGET seems too strict to me, some TjMax values documented in Documentation/hwmon/coretemp wouldn't pass. Relax the check so that all the documented values pass. Signed-off-by: NJean Delvare <khali@linux-fr.org> Cc: Carsten Emde <C.Emde@osadl.org> Cc: Fenghua Yu <fenghua.yu@intel.com> Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
-
由 Per Dalen 提交于
The temp_fault sysfs attribute is wrong, it should be temp2_fault instead. Reported-by: NGuenter Roeck <guenter.roeck@ericsson.com> Signed-off-by: NPer Dalen <per.dalen@appeartv.com> Acked-by: NJean Delvare <khali@linux-fr.org> Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
-
- 01 6月, 2011 22 次提交
-
-
由 Dan Carpenter 提交于
blkbk->pending_pages can be NULL here so I added a check for it. Signed-off-by: NDan Carpenter <error27@gmail.com> [v1: Redid the loop a bit] Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
由 Laszlo Ersek 提交于
...because vbd_size() dereferences bd_disk if bd_part is NULL. Signed-off-by: Laszlo Ersek<lersek@redhat.com> Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
由 David Woodhouse 提交于
We were mapping an extra byte (and hence usually an extra page): iommu_prepare_identity_map() expects to be given an 'end' argument which is the last byte to be mapped; not the first byte *not* to be mapped. Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 Mike Habeck 提交于
The comment in domain_remove_one_dev_info() states "No need to compare PCI domain; it has to be the same". But for the si_domain that isn't going to be true, as it consists of all the PCI devices that are identity mapped thus multiple PCI domains can be in si_domain. The code needs to validate the PCI domain too. Signed-off-by: NMike Habeck <habeck@sgi.com> Signed-off-by: NMike Travis <travis@sgi.com> Cc: stable@kernel.org Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 Mike Travis 提交于
When using the 1:1 (identity) PCI DMA remapping, PCI Host Bridge devices that do not use the IOMMU causes a kernel panic. Fix that by not inserting those devices into the si_domain. Signed-off-by: NMike Travis <travis@sgi.com> Reviewed-by: NMike Habeck <habeck@sgi.com> Cc: stable@kernel.org Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 Mike Travis 提交于
The __intel_map_single function is not honoring the passed in DMA mask. This results in not using the coherent DMA mask when called from intel_alloc_coherent(). Signed-off-by: NMike Travis <travis@sgi.com> Acked-by: NChris Wright <chrisw@sous-sol.org> Reviewed-by: NMike Habeck <habeck@sgi.com> Cc: stable@kernel.org Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 Chris Wright 提交于
Mike Travis and Mike Habeck reported an issue where iova allocation would return a range that was larger than a device's dma mask. https://lkml.org/lkml/2011/3/29/423 The dmar initialization code will reserve all PCI MMIO regions and copy those reservations into a domain specific iova tree. It is possible for one of those regions to be above the dma mask of a device. It is typical to allocate iovas with a 32bit mask (despite device's dma mask possibly being larger) and cache the result until it exhausts the lower 32bit address space. Freeing the iova range that is >= the last iova in the lower 32bit range when there is still an iova above the 32bit range will corrupt the cached iova by pointing it to a region that is above 32bit. If that region is also larger than the device's dma mask, a subsequent allocation will return an unusable iova and cause dma failure. Simply don't cache an iova that is above the 32bit caching boundary. Reported-by: NMike Travis <travis@sgi.com> Reported-by: NMike Habeck <habeck@sgi.com> Cc: stable@kernel.org Acked-by: NMike Travis <travis@sgi.com> Tested-by: NMike Habeck <habeck@sgi.com> Signed-off-by: NChris Wright <chrisw@sous-sol.org> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 Mike Travis 提交于
When there are a large count of PCI devices, and the pass through option for iommu is set, much time is spent in the identity_mapping function hunting though the iommu domains to check if a specific device is "identity mapped". Speed up the function by checking the cached info to see if it's mapped to the static identity domain. Signed-off-by: NMike Travis <travis@sgi.com> Reviewed-by: NMike Habeck <habeck@sgi.com> Cc: stable@kernel.org Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 Chris Wright 提交于
The identity mapping code appears to make the assumption that if the devices dma_mask is greater than 32bits the device can use identity mapping. But that is not true: take the case where we have a 40bit device in a 44bit architecture. The device can potentially receive a physical address that it will truncate and cause incorrect addresses to be used. Instead check to see if the device's dma_mask is large enough to address the system's dma_mask. Signed-off-by: NMike Travis <travis@sgi.com> Reviewed-by: NMike Habeck <habeck@sgi.com> Cc: stable@kernel.org Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 Alex Williamson 提交于
Commit a97590e5 added unlinking domains from iommus to reciprocate the iommu from domains unlinking that was already done. We actually want to only do this for device domains and never for the static identity map domain or VM domains. The SI domain is special and never freed, while VM domain->id lives in their own special address space, separate from iommu->domain_ids. In the current code, a VM can get domain->id zero, then mark that domain unused when unbound from pci-stub. This leads to DMAR write faults when the device is re-bound to the host driver. Signed-off-by: NAlex Williamson <alex.williamson@redhat.com> Cc: stable@kernel.org Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 Youquan Song 提交于
There are no externally-visible changes with this. In the loop in the internal __domain_mapping() function, we simply detect if we are mapping: - size >= 2MiB, and - virtual address aligned to 2MiB, and - physical address aligned to 2MiB, and - on hardware that supports superpages. (and likewise for larger superpages). We automatically use a superpage for such mappings. We never have to worry about *breaking* superpages, since we trust that we will always *unmap* the same range that was mapped. So all we need to do is ensure that dma_pte_clear_range() will also cope with superpages. Adjust pfn_to_dma_pte() to take a superpage 'level' as an argument, so it can return a PTE at the appropriate level rather than always extending the page tables all the way down to level 1. Again, this is simplified by the fact that we should never encounter existing small pages when we're creating a mapping; any old mapping that used the same virtual range will have been entirely removed and its obsolete page tables freed. Provide an 'intel_iommu=sp_off' argument on the command line as a chicken bit. Not that it should ever be required. == The original commit seen in the iommu-2.6.git was Youquan's implementation (and completion) of my own half-baked code which I'd typed into an email. Followed by half a dozen subsequent 'fixes'. I've taken the unusual step of rewriting history and collapsing the original commits in order to keep the main history simpler, and make life easier for the people who are going to have to backport this to older kernels. And also so I can give it a more coherent commit comment which (hopefully) gives a better explanation of what's going on. The original sequence of commits leading to identical code was: Youquan Song (3): intel-iommu: super page support intel-iommu: Fix superpage alignment calculation error intel-iommu: Fix superpage level calculation error in dma_pfn_level_pte() David Woodhouse (4): intel-iommu: Precalculate superpage support for dmar_domain intel-iommu: Fix hardware_largepage_caps() intel-iommu: Fix inappropriate use of superpages in __domain_mapping() intel-iommu: Fix phys_pfn in __domain_mapping for sglist pages Signed-off-by: NYouquan Song <youquan.song@intel.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 Mike Frysinger 提交于
The new instruction_pointer_set helper is defined for people who have converted to asm-generic/ptrace.h, so don't use it generally unless the arch needs it (in which case it has been converted). This should fix building of kgdb tests for arches not yet converted. Signed-off-by: NMike Frysinger <vapier@gentoo.org> Acked-by: NStephen Rothwell <sfr@canb.auug.org.au> Cc: Jason Wessel <jason.wessel@windriver.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 David S. Miller 提交于
This reverts commit e5cb966c. It causes new build regressions with gcc-4.2 which is pretty common on non-x86 platforms. Reported-by: NJames Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Alexey Khoroshilov 提交于
catc_ctrl_run() calls usb_submit_urb() with GFP_KERNEL, while it is called from catc_ctrl_async() and catc_ctrl_done() with catc->ctrl_lock spinlock held. The patch replaces GFP_KERNEL with GFP_ATOMIC. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Dennis Aberilla 提交于
This patch fixes a driver crash during packet reception due to not enough bytes allocated in the skb. Since the loop reads out 4 bytes at a time, we need to allow for up to 3 bytes of slack space. Signed-off-by: NDennis Aberilla <denzzzhome@yahoo.com> Signed-off-by: NDavid S. Miller <davem@zippy.davemloft.net>
-
由 Wey-Yi Guy 提交于
For 6150 devices, modify the supported PCI subsystem ID. Cc: stable@kernel.org Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Jussi Kivilinna 提交于
zd1211 devices register 'EP 4 OUT' endpoint as Interrupt type on USB 2.0: Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 However on USB 1.1 endpoint becomes Bulk: Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Commit 37939810 assumed that endpoint is always interrupt type and changed usb_bulk_msg() calls to usb_interrupt_msg(). Problem here is that usb_bulk_msg() on interrupt endpoint selfcorrects the call and changes requested pipe to interrupt type (see usb_bulk_msg). However with usb_interrupt_msg() on bulk endpoint does not correct the pipe type to bulk, but instead URB is submitted with interrupt type pipe. So pre-2.6.39 used usb_bulk_msg() and therefore worked with both endpoint types, however in 2.6.39 usb_interrupt_msg() with bulk endpoint causes ohci_hcd to fail submitted URB instantly with -ENOSPC and preventing zd1211rw from working with OHCI. Fix this by detecting endpoint type and using correct endpoint/pipe types for URB. Also fix asynchronous zd_usb_iowrite16v_async() to use right URB type on 'EP 4 OUT'. Cc: stable@kernel.org Signed-off-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luciano Coelho 提交于
Fix kernel oops when trying to use passive scheduled scans. The reason was that in passive scans there are no SSIDs, so there was a NULL pointer dereference. To solve the problem, we now check the number of SSIDs provided in the sched_scan request and only access the list if there's one or more (ie. passive scan is not forced). We also force all the channels to be passive by adding the IEEE80211_CHAN_PASSIVE_SCAN flag locally before the checks in the wl1271_scan_get_sched_scan_channels() function. Signed-off-by: NLuciano Coelho <coelho@ti.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luciano Coelho 提交于
Use a different value for DFS dwell time when performing a scheduled scan. Previously we were using the same value as for normal passive scans. This adds some flexibility between these two different types of passive scan. For now we use 150 TUs for DFS channel dwell time. This may need to be fine-tuned in the future. Signed-off-by: NLuciano Coelho <coelho@ti.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luciano Coelho 提交于
DFS channels were never getting included in the scheduled scans, because they always contain the passive flag as well and the call was asking for DFS and active channels. Fix this by ignoring the passive flag when collecting DFS channels. Also, move the DFS channels in the channel list before the 5GHz active channels (this was implemented in the FW differently than specified). Signed-off-by: NLuciano Coelho <coelho@ti.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luciano Coelho 提交于
We were comparing bitwise AND results with a boolean, so when the boolean was set to true, it was not matching as it should. Fix this by booleanizing the bitwise AND results with !!. Signed-off-by: NLuciano Coelho <coelho@ti.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Daniel Drake 提交于
Before this patch, the command sequence number is being set before lbs_queue_cmd() adds the command to the queue. However, lbs_queue_cmd() sometimes forces commands to queue-jump (e.g. CMD_802_11_WAKEUP_CONFIRM). It currently does this without considering that sequence numbers might need adjusting to keep things running in order. Fix this by setting the sequence number at a later stage, just before we're actually submitting the command to the hardware. Also fixes a possible race where seqnum was being modified outside of the driver lock. Signed-off-by: NDaniel Drake <dsd@laptop.org> Acked-by: NDan Williams <dcbw@redhat.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 31 5月, 2011 1 次提交
-
-
由 Paul Mundt 提交于
The runtime PM changes introduce sh_dmae_rst() wrapping via the runtime_resume helper, depending on dev_get_drvdata() to fetch the platform data needed for the DMAOR initialization default at a time where drvdata hasn't yet been established by the probe path, resulting in general probe misery: Unable to handle kernel NULL pointer dereference at virtual address 000000c4 pc = 8025adee *pde = 00000000 Oops: 0000 [#1] Modules linked in: Pid : 1, Comm: swapper CPU : 0 Not tainted (3.0.0-rc1-00012-g9436b4ab-dirty #1456) PC is at sh_dmae_rst+0x28/0x86 PR is at sh_dmae_rst+0x22/0x86 PC : 8025adee SP : 9e803d10 SR : 400080f1 TEA : 000000c4 R0 : 000000c4 R1 : 0000fff8 R2 : 00000000 R3 : 00000040 R4 : 000000f0 R5 : 00000000 R6 : 00000000 R7 : 804f184c R8 : 00000000 R9 : 804dd0e8 R10 : 80283204 R11 : ffffffda R12 : 000000a0 R13 : 804dd18c R14 : 9e803d10 MACH: 00000000 MACL: 00008f20 GBR : 00000000 PR : 8025ade8 Call trace: [<8025ae70>] sh_dmae_runtime_resume+0x24/0x34 [<80283238>] pm_generic_runtime_resume+0x34/0x3c [<80283370>] rpm_callback+0x4a/0x7e [<80283efc>] rpm_resume+0x240/0x384 [<80283f54>] rpm_resume+0x298/0x384 [<8028428c>] __pm_runtime_resume+0x44/0x7c [<8038a358>] __ioremap_caller+0x0/0xec [<80284296>] __pm_runtime_resume+0x4e/0x7c [<8038a358>] __ioremap_caller+0x0/0xec [<80666254>] sh_dmae_probe+0x180/0x6a0 [<802803ae>] platform_drv_probe+0x26/0x2e Fix up the ordering accordingly. Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
-