- 03 Aug, 2015 34 commits
-
-
Theodore Ts'o authored
commit 0f0ff9a9 upstream. Commit 8f4d8558: "ext4: fix lazytime optimization" was not a complete fix. In the case where the inode number is a multiple of 16, and we could still end up updating an inode with dirty timestamps written to the wrong inode on disk. Oops. This can be easily reproduced by using generic/005 with a file system with metadata_csum and lazytime enabled. Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Theodore Ts'o authored
commit a2fd66d0 upstream. Newer versions of mount parse the lazytime feature and pass it to the mount system call via the flags field in the mount system call, removing the lazytime string from the mount options list. So we need to check for the presence of MS_LAZYTIME and set it in sb->s_flags in order for this flag to be set on a remount. Signed-off-by:
-
Darrick J. Wong authored
commit 292db1bc upstream. ext4 isn't willing to map clusters to a non-extent file. Don't signal this with an out of space error, since the FS will retry the allocation (which didn't fail) forever. Instead, return EUCLEAN so that the operation will fail immediately all the way back to userspace. (The fix is either to run e2fsck -E bmap2extent, or to chattr +e the file.) Signed-off-by:
Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by:
-
Theodore Ts'o authored
commit 89d96a6f upstream. Normally all of the buffers will have been forced out to disk before we call invalidate_bdev(), but there will be some cases, where a file system operation was aborted due to an ext4_error(), where there may still be some dirty buffers in the buffer cache for the device. So try to force them out to memory before calling invalidate_bdev(). This fixes a warning triggered by generic/081: WARNING: CPU: 1 PID: 3473 at /usr/projects/linux/ext4/fs/block_dev.c:56 __blkdev_put+0xb5/0x16f() Signed-off-by:
-
Theodore Ts'o authored
commit bdf96838 upstream. The commit cf108bca: "ext4: Invert the locking order of page_lock and transaction start" caused __ext4_journalled_writepage() to drop the page lock before the page was written back, as part of changing the locking order to jbd2_journal_start -> page_lock. However, this introduced a potential race if there was a truncate racing with the data=journalled writeback mode. Fix this by grabbing the page lock after starting the journal handle, and then checking to see if page had gotten truncated out from under us. This fixes a number of different warnings or BUG_ON's when running xfstests generic/086 in data=journalled mode, including: jbd2_journal_dirty_metadata: vdc-8: bad jh for block 115643: transaction (ee3fe7 c0, 164), jh->b_transaction ( (null), 0), jh->b_next_transaction ( (null), 0), jlist 0 - and - kernel BUG at /usr/projects/linux/ext4/fs/jbd2/transaction.c:2200! ... Call Trace: [<c02b2ded>] ? __ext4_journalled_invalidatepage+0x117/0x117 [<c02b2de5>] __ext4_journalled_invalidatepage+0x10f/0x117 [<c02b2ded>] ? __ext4_journalled_invalidatepage+0x117/0x117 [<c027d883>] ? lock_buffer+0x36/0x36 [<c02b2dfa>] ext4_journalled_invalidatepage+0xd/0x22 [<c0229139>] do_invalidatepage+0x22/0x26 [<c0229198>] truncate_inode_page+0x5b/0x85 [<c022934b>] truncate_inode_pages_range+0x156/0x38c [<c0229592>] truncate_inode_pages+0x11/0x15 [<c022962d>] truncate_pagecache+0x55/0x71 [<c02b913b>] ext4_setattr+0x4a9/0x560 [<c01ca542>] ? current_kernel_time+0x10/0x44 [<c026c4d8>] notify_change+0x1c7/0x2be [<c0256a00>] do_truncate+0x65/0x85 [<c0226f31>] ? file_ra_state_init+0x12/0x29 - and - WARNING: CPU: 1 PID: 1331 at /usr/projects/linux/ext4/fs/jbd2/transaction.c:1396 irty_metadata+0x14a/0x1ae() ... Call Trace: [<c01b879f>] ? console_unlock+0x3a1/0x3ce [<c082cbb4>] dump_stack+0x48/0x60 [<c0178b65>] warn_slowpath_common+0x89/0xa0 [<c02ef2cf>] ? jbd2_journal_dirty_metadata+0x14a/0x1ae [<c0178bef>] warn_slowpath_null+0x14/0x18 [<c02ef2cf>] jbd2_journal_dirty_metadata+0x14a/0x1ae [<c02d8615>] __ext4_handle_dirty_metadata+0xd4/0x19d [<c02b2f44>] write_end_fn+0x40/0x53 [<c02b4a16>] ext4_walk_page_buffers+0x4e/0x6a [<c02b59e7>] ext4_writepage+0x354/0x3b8 [<c02b2f04>] ? mpage_release_unused_pages+0xd4/0xd4 [<c02b1b21>] ? wait_on_buffer+0x2c/0x2c [<c02b5a4b>] ? ext4_writepage+0x3b8/0x3b8 [<c02b5a5b>] __writepage+0x10/0x2e [<c0225956>] write_cache_pages+0x22d/0x32c [<c02b5a4b>] ? ext4_writepage+0x3b8/0x3b8 [<c02b6ee8>] ext4_writepages+0x102/0x607 [<c019adfe>] ? sched_clock_local+0x10/0x10e [<c01a8a7c>] ? __lock_is_held+0x2e/0x44 [<c01a8ad5>] ? lock_is_held+0x43/0x51 [<c0226dff>] do_writepages+0x1c/0x29 [<c0276bed>] __writeback_single_inode+0xc3/0x545 [<c0277c07>] writeback_sb_inodes+0x21f/0x36d ... Signed-off-by:
-
Srinivas Pandruvada authored
commit 1e25aa96 upstream. By default all the sensors are runtime suspended state (lowest power state). During Linux suspend process, all the run time suspended devices are resumed and then suspended. This caused all sensors to power up and introduced delay in suspend time, when we introduced runtime PM for HID sensors. The opposite process happens during resume process. To fix this, we do powerup process of the sensors only when the request is issued from user (raw or tiggerred). In this way when runtime, resume calls for powerup it will simply return as this will not match user requested state. Note this is a regression fix as the increase in suspend / resume times can be substantial (report of 8 seconds on Len's laptop!) Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Tested-by:
Len Brown <len.brown@intel.com> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Ian Abbott authored
commit b08ad665 upstream. Normally, low-level Comedi drivers set an `insn_bits` handler for digital input (DI), digital output (DO) and digital input/output (DIO) subdevice types to handle normal reading and writing of digital channels. The "cb_pcimdas" driver currently has an `insn_read` handler for the DI subdevice and an `insn_write` handler for the DO subdevice. However, the actual handler functions `cb_pcimdas_di_insn_read()` and `cb_pcimdas_do_insn_write()` are written to behave like `insn_bits` handlers. Something's wrong there! To fix it, set the functions as `insn_bits` handlers and rename them for consistency. Fixes: e56d03de ("staging: comedi: cb_pcimdas: add main connector digital input/output") Signed-off-by:
Ian Abbott <abbotti@mev.co.uk> Signed-off-by:
-
Haggai Eran authored
commit cab46214 upstream. With an RTL8191SU USB adaptor, sometimes the hints for a fragmented packet are set, but the packet length is too large. Allocate enough space to prevent memory corruption and a resulting kernel panic [1]. [1] http://www.spinics.net/lists/linux-wireless/msg136546.htmlSigned-off-by:
Haggai Eran <haggai.eran@gmail.com> ACKed-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Malcolm Priestley authored
commit b5eeed8c upstream. There is a small chance that pRD->pRDInfo->skb could go NULL while the interrupt is processing. Put NULL check on loop to break out. Signed-off-by:
Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by:
-
Malcolm Priestley authored
commit 8e8e9198 upstream. Sometimes bssid can go null on failed association. Signed-off-by:
-
Malcolm Priestley authored
commit d309509f upstream. Sometimes bssid can go null on failed association. Signed-off-by:
-
Lennert Buytenhek authored
commit 8a70cefa upstream. The AF_IEEE802154 sockaddr looks like this: struct sockaddr_ieee802154 { sa_family_t family; /* AF_IEEE802154 */ struct ieee802154_addr_sa addr; }; struct ieee802154_addr_sa { int addr_type; u16 pan_id; union { u8 hwaddr[IEEE802154_ADDR_LEN]; u16 short_addr; }; }; On most architectures there will be implicit structure padding here, in two different places: * In struct sockaddr_ieee802154, two bytes of padding between 'family' (unsigned short) and 'addr', so that 'addr' starts on a four byte boundary. * In struct ieee802154_addr_sa, two bytes at the end of the structure, to make the structure 16 bytes. When calling recvmsg(2) on a PF_IEEE802154 SOCK_DGRAM socket, the ieee802154 stack constructs a struct sockaddr_ieee802154 on the kernel stack without clearing these padding fields, and, depending on the addr_type, between four and ten bytes of uncleared kernel stack will be copied to userspace. We can't just insert two 'u16 __pad's in the right places and zero those before copying an address to userspace, as not all architectures insert this implicit padding -- from a quick test it seems that avr32, cris and m68k don't insert this padding, while every other architecture that I have cross compilers for does insert this padding. The easiest way to plug the leak is to just memset the whole struct sockaddr_ieee802154 before filling in the fields we want to fill in, and that's what this patch does. Signed-off-by:
Lennert Buytenhek <buytenh@wantstofly.org> Acked-by:
Alexander Aring <alex.aring@gmail.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Vincent Fann authored
commit 1277fa2a upstream. Several of these drivers have there TX randomly blocked for 3~5 seconds while measuring tx throughput (iperf). The root couse happens in rtl_pci_flush(). The function uses a while-loop to wait for TX queue length to decrease to 0. The TX queue length counts the number of packets that are queued in the driver. The driver relys on the TX OK interrupt to return skb and reduce TX queue length. The interrupt subroutine disables interupts, reads the interrupt registers, and then clears the registers in the beginning of _rtl_pci_interrupt(). After all interupts process are finished, the driver invokes enable_interrupt() to enable interupts. This behavior is normal for an interrupt subroutine. But enable_interrupt() invokes clear_interrupt() again. This unexpected interrupt clearing may cleari me fresh TX OK interrupts. These missing interrupts cause TX queue length to never reduce to 0i, which causes rtl_pci_flush() to be stuck in unterminated while-loop. This patch removes clear_interrupt() in enable_interrupt() to avoid this behavior. Signed-off-by:
Vincent Fann <vincent_fann@realtek.com> Signed-off-by:
Shao Fu <shaofu@realtek.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Dan Carpenter authored
commit 191f1aee upstream. In d8a2c51c ('ath9k_htc: Use atomic operations for op_flags') we changed things like this: - if (priv->op_flags & OP_TSF_RESET) { + if (test_bit(OP_TSF_RESET, &priv->op_flags)) { The problem is that test_bit() takes a bit number and not a mask. It means that when we do: set_bit(OP_TSF_RESET, &priv->op_flags); Then it sets the (1 << 6) bit instead of the 6 bit so we are setting a bit which is past the end of the unsigned long. Fixes: d8a2c51c ('ath9k_htc: Use atomic operations for op_flags') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Felix Fietkau authored
commit 300f77c0 upstream. AR93xx and newer needs to stop rx before tx to avoid getting the DMA engine or MAC into a stuck state. This should reduce/fix the occurence of "Failed to stop Tx DMA" logspam. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Chris Mason authored
commit 7bee8b08 upstream. Commit 1c8ba6d0 moved around the setup code for broadcomm chips, and also added btbcm_read_verbose_config() to read extra information about the hardware. It's returning errors on some macbooks: Bluetooth: hci0: BCM: Read verbose config info failed (-16) Which makes us error out of the setup function. Since this probe isn't critical to operate the chip, this patch just changes things to carry on when it fails. Signed-off-by:
Chris Mason <clm@fb.com> Signed-off-by:
-
Aleksei Volkov authored
commit 2eeac871 upstream. That patch corrects the typo in usb vendor id for Roper Class 1 Bluetooth Dongle. Problem with typo is present since 4.0 kernel. Content /sys/kernel/debug/usb/devices for these dongle: T: Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1310 ProdID=0001 Rev=15.00 S: Manufacturer=SiW S: Product=SiW S: SerialNumber=E7BB050D0B00 C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr= 50mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by:
Aleksei Volkov <info@dv2c.ru> Signed-off-by:
-
Marcel Holtmann authored
commit e66890a9 upstream. This patch fixes the command length alignment issue for Intel Bluetooth 8260. The length of parameters in the firmware downloading command must be multiplication of 4. If not, the command must append Intel_NOP command with extra parameters, zeros, at the end, and the firmware file is already included Intel_NOP command for alignment. This patch checks the next command and if the next command is Intel_NOP command, it reads the Intel_NOP command and send them together. For example, if the data from the firmware file looks like this: 8E FC 03 11 22 33 02 FC 03 00 00 00 Previously, btusb sends two commands: 09 FC 06 8E FC 03 11 22 33 09 FC 06 02 FC 03 00 00 00 This won't work because the length of parameters are 6 which violates the 4 byte alignment. This patch will append them together and send as one command: 09 FC 0C 8E FC 03 11 22 33 02 FC 03 00 00 00 Based on previous work from Tedd Ho-Jeong An <tedd.an@intel.com> Reported-by:
Tedd Ho-Jeong An <tedd.an@intel.com> Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com> Signed-off-by:
-
Marcel Holtmann authored
commit ecffc804 upstream. The SKB returned from the Intel specific version information command is missing a kfree_skb. Signed-off-by:
-
Marcel Holtmann authored
commit 781f899f upstream. During the initial setup stage of a controller, the low-level transport is actually active. This means that HCI_UP is true. To avoid toggling the transport off and back on again for normal operation the kernel holds a grace period with HCI_AUTO_OFF that will turn the low-level transport off in case no user is present. The idea of the grace period is important to avoid having to initialize all of the controller twice. So legacy ioctl and the new management interface knows how to clear this grace period and then start normal operation. For the user channel operation this grace period has not been taken into account which results in the problem that HCI_UP and HCI_AUTO_OFF are set and the kernel will return EBUSY. However from a system point of view the controller is ready to be grabbed by either the ioctl, the management interface or the user channel. This patch brings the user channel to the same level as the other two entries for operating a controller. Signed-off-by:
-
Greg Ungerer authored
commit d9ee4896 upstream. It is possible to disable the clock selection at configuration time, but for ColdFire targets we always expect a clock frequency to be selected. This results in the following compile time error: CC arch/m68k/kernel/asm-offsets.s In file included from ./arch/m68k/include/asm/timex.h:14:0, from include/linux/timex.h:65, from include/linux/sched.h:19, from arch/m68k/kernel/asm-offsets.c:14: ./arch/m68k/include/asm/coldfire.h:25:2: error: #error "Don't know what your ColdFire CPU clock frequency is??" Remove CONFIG_CLOCK_SELECT completely and always enable CONFIG_CLOCK_FREQ for ColdFire. Signed-off-by:
Greg Ungerer <gerg@uclinux.org> Acked-by:
Geert Uytterhoeven <geert@linux-m68k.org> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Greg Ungerer authored
commit fa95a1dd upstream. It would be nice if we could support multiple ColdFire SoC types in a single binary - but currently the code simply does not support it. Change the SoC selection config options to be a choice instead of individual selectable entries. This fixes problems with building allnoconfig, and means that a sane linux kernel is generated for a single ColdFire SoC type. Signed-off-by:
-
Andrew Morton authored
commit 04ea1e91 upstream. openrisc-allnoconfig: kernel/uid16.c: In function 'SYSC_setgroups16': kernel/uid16.c:184:2: error: implicit declaration of function 'groups_alloc' kernel/uid16.c:184:13: warning: assignment makes pointer from integer without a cast openrisc shouldn't be setting CONFIG_UID16 when CONFIG_MULTIUSER=n. Fixes: 2813893f ("kernel: conditionally support non-root users, groups and capabilities") Reported-by:
Fengguang Wu <fengguang.wu@gmail.com> Cc: Iulia Manda <iulia.manda21@gmail.com> Cc: Josh Triplett <josh@joshtriplett.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Thomas Petazzoni authored
commit ea78b951 upstream. There was a mistake in the definition of the functions for MPP48 on Marvell Armada XP. The second function is dev(clkout), and not tclk. Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Fixes: 463e270f ("pinctrl: mvebu: add pinctrl driver for Armada XP") Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Thomas Petazzoni authored
commit 80b3d04f upstream. The latest version of the Armada XP datasheet no longer documents the VDD cpu_pd functions, which might indicate they are not working and/or not supported. This commit ensures the pinctrl driver matches the datasheet. Signed-off-by:
-
Thomas Petazzoni authored
commit bc99357f upstream. After updating to a more recent version of the Armada XP datasheet, we realized that some of the pins documented as having a NAND-related functionality in fact did not have such functionality. This commit updates the pinctrl driver accordingly. Signed-off-by:
-
Thomas Petazzoni authored
commit 7c580311 upstream. The pinctrl_gpio_range[] array described a first bank of 32 GPIOs and a second one of 27 GPIOs. However, since there is a total of 60 MPP pins that can be muxed as GPIOs, the second bank really has 28 GPIOs. Signed-off-by:
-
Thomas Petazzoni authored
commit 27e7cd01 upstream. The pinctrl_gpio_range[] array described a first bank of 32 GPIOs and a second one of 27 GPIOs. However, since there is a total of 60 MPP pins that can be muxed as GPIOs, the second bank really has 28 GPIOs. Signed-off-by:
-
Thomas Petazzoni authored
commit 331642fb upstream. A new revision of the Marvell Armada 38x hardware datasheet unveiled that the definition of some of the PCIe functions were not correct. This commit fixes the pinctrl driver accordingly. Some PCIe functions simply do not exist, some of the PCIe functions in fact were corresponding to other functions, and some PCIe functions have been added. Note: the seemingly unrelated removal of spi(cs2) on MPP47 is related: this function is in fact implemented on MPP43, instead of a PCIe function. Signed-off-by:
-
Thomas Petazzoni authored
commit e5447d26 upstream. After updating to a more recent version of the Armada 375, we realized that some of the pins documented as having a NAND-related functionality in fact did not have such functionality. This commit updates the pinctrl driver accordingly. Signed-off-by:
-
Thomas Petazzoni authored
commit d538990e upstream. There was an incorrect space in the definition of the function of one pin in the Armada 375 pinctrl driver, which this commit fixes. Signed-off-by:
-
Thomas Petazzoni authored
commit 438881df upstream. Due to a mistake, the CS0 and CS1 SPI0 functions were incorrectly named "spi0-1" instead of just "spi0". This commit fixes that. This DT binding change does not affect any of the in-tree users. Signed-off-by:
-
Masahiro Yamada authored
commit 5cf021d5 upstream. The address for SD0_WP_CD_SEL, SD1_WP_CD_SEL is 0xf8000830, 0xf8000834, respectively. Each offset address must be prefixed with 0x. Fixes: add958ce "pinctrl: Add driver for Zynq" Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by:
Sören Brinkmann <soren.brinkmann@xilinx.com> Signed-off-by:
-
Masahiro Yamada authored
commit 4f652cea upstream. The offset to the mux register is missing. Fixes: add958ce "pinctrl: Add driver for Zynq" Signed-off-by:
-
- 21 Jul, 2015 6 commits
-
-
Greg Kroah-Hartman authored
-
Frodo Lai authored
commit 469d7d22 upstream. The i2c_master_recv() uses readsize to receive data from i2c but compares to size of rdbuf which is always 27. This would cause problem when the max_fingers is not 5. Change the comparison value to readsize instead. Fixes: 36874c7e ("Input: pixcir_i2c_ts - support up to 5 fingers and hardware tracking IDs:) Signed-off-by:
Frodo Lai <frodo_lai@bcmcom.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Zhichang Yuan authored
commit 5dbb4c61 upstream. 41f8bba7 ("of/pci: Add pci_register_io_range() and pci_pio_to_address()") added support for systems with several I/O ranges described by OF bindings. It modified pci_address_to_pio() look up the io_range for a given CPU physical address, but the conversion was wrong. Fix the conversion of address to I/O port. [bhelgaas: changelog] Fixes: 41f8bba7 ("of/pci: Add pci_register_io_range() and pci_pio_to_address()") Signed-off-by:
Zhichang Yuan <yuanzhichang@hisilicon.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by:
-
Alex Williamson authored
commit a5dd4b4b upstream. The commit referenced below deferred waiting for command completion until the start of the next command, allowing hardware to do the latching asynchronously. Unfortunately, being ready to accept a new command is the only indication we have that the previous command is completed. In cases where we need that state change to be enabled, we must still wait for completion. For instance, pciehp_reset_slot() attempts to disable anything that might generate a surprise hotplug on slots that support presence detection. If we don't wait for those settings to latch before the secondary bus reset, we negate any value in attempting to prevent the spurious hotplug. Create a base function with optional wait and helper functions so that pcie_write_cmd() turns back into the "safe" interface which waits before and after issuing a command and add pcie_write_cmd_nowait(), which eliminates the trailing wait for asynchronous completion. The following functions are returned to their previous behavior: pciehp_power_on_slot pciehp_power_off_slot pcie_disable_notification pciehp_reset_slot The rationale is that pciehp_power_on_slot() enables the link and therefore relies on completion of power-on. pciehp_power_off_slot() and pcie_disable_notification() need a wait because data structures may be freed after these calls and continued signaling from the device would be unexpected. And, of course, pciehp_reset_slot() needs to wait for the scenario outlined above. Fixes: 3461a068 ("PCI: pciehp: Wait for hotplug command completion lazily") Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
Yinghai Lu authored
commit 3a9ad0b4 upstream. David Ahern reported that d63e2e1f ("sparc/PCI: Clip bridge windows to fit in upstream windows") fails to boot on sparc/T5-8: pci 0000:06:00.0: reg 0x184: can't handle BAR above 4GB (bus address 0x110204000) The problem is that sparc64 assumed that dma_addr_t only needed to hold DMA addresses, i.e., bus addresses returned via the DMA API (dma_map_single(), etc.), while the PCI core assumed dma_addr_t could hold *any* bus address, including raw BAR values. On sparc64, all DMA addresses fit in 32 bits, so dma_addr_t is a 32-bit type. However, BAR values can be 64 bits wide, so they don't fit in a dma_addr_t. d63e2e1f added new checking that tripped over this mismatch. Add pci_bus_addr_t, which is wide enough to hold any PCI bus address, including both raw BAR values and DMA addresses. This will be 64 bits on 64-bit platforms and on platforms with a 64-bit dma_addr_t. Then dma_addr_t only needs to be wide enough to hold addresses from the DMA API. [bhelgaas: changelog, bugzilla, Kconfig to ensure pci_bus_addr_t is at least as wide as dma_addr_t, documentation] Fixes: d63e2e1f ("sparc/PCI: Clip bridge windows to fit in upstream windows") Fixes: 23b13bc7 ("PCI: Fail safely if we can't handle BARs larger than 4GB") Link: http://lkml.kernel.org/r/CAE9FiQU1gJY1LYrxs+ma5LCTEEe4xmtjRG0aXJ9K_Tsu+m9Wuw@mail.gmail.com Link: http://lkml.kernel.org/r/1427857069-6789-1-git-send-email-yinghai@kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=96231Reported-by:
David Ahern <david.ahern@oracle.com> Tested-by:
Yinghai Lu <yinghai@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Rafael J. Wysocki authored
commit 08249651 upstream. Refine the mechanism introduced by commit f244d8b6 ("ACPIPHP / radeon / nouveau: Fix VGA switcheroo problem related to hotplug") to propagate the ignore_hotplug setting of the device to its parent bridge in case hotplug notifications related to the graphics adapter switching are given for the bridge rather than for the device itself (they need to be ignored in both cases). Link: https://bugzilla.kernel.org/show_bug.cgi?id=61891 Link: https://bugs.freedesktop.org/show_bug.cgi?id=88927 Fixes: b440bde7 ("PCI: Add pci_ignore_hotplug() to ignore hotplug events for a device") Reported-and-tested-by:
tiagdtd-lava <tiagdtd-lava@yahoo.de> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
