- 02 Jun, 2015 3 commits
-
-
Aravind Gopalakrishnan authored
commit f89ce270 upstream. This patch adds temperature monitoring support for F15h M60h processor. - Add new pci device id for the relevant processor - The functionality of REG_REPORTED_TEMPERATURE is moved to D0F0xBC_xD820_0CA4 [Reported Temperature Control] - So, use this to get CUR_TEMP value - Since we need an indirect register access, protect this with a mutex lock - Add Kconfig, Doc entries to indicate support for this processor. Signed-off-by:
Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com> Acked-by:
Borislav Petkov <bp@suse.de> Acked-by:
Clemens Ladisch <clemens@ladisch.de> [Guenter Roeck: Declare new mutex and function static] Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Aravind Gopalakrishnan authored
commit ec015950 upstream. Adding new PCI ID to support AMD F16 M30h processor (Mullins). While at it, modify Kconfig and Doc files to reflect the support for newer processors Note: PCI ID for this processor will make it into pci_ids.h as part of this patch: http://marc.info/?l=linux-kernel&m=139291362126057&w=2 which should be pulled into 3.15 when merge window opens (It currently sits in 'for-next' branch of bp.git- https://git.kernel.org/cgit/linux/kernel/git/bp/bp.git/log/?h=for-next) Signed-off-by:
-
Aravind Gopalakrishnan authored
commit 85a8885b upstream. Extend ECC decoding support for F16h M30h. Tested on F16h M30h with ECC turned on using mce_amd_inj module and the patch works fine. Signed-off-by:
Arindam Nath <Arindam.Nath@amd.com> Acked-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
- 26 May, 2015 24 commits
-
-
Chen Gang authored
commit 9493c242 upstream. Remove 2 redundant extern inline functions: qla8044_set_qsnt_ready() and qla8044_need_reset_handler(). At present, within upstream next kernel source code, they are only used within "drivers/scsi/qla2xxx/qla_nx2.c". The related error and warnings (with allmodconfig under tile): CC [M] drivers/scsi/qla2xxx/qla_nx2.o drivers/scsi/qla2xxx/qla_nx2.c:1633:1: error: static declaration of 'qla8044_need_reset_handler' follows non-static declaration qla8044_need_reset_handler(struct scsi_qla_host *vha) ^ In file included from drivers/scsi/qla2xxx/qla_def.h:3706:0, from drivers/scsi/qla2xxx/qla_nx2.c:11: drivers/scsi/qla2xxx/qla_gbl.h:756:20: note: previous declaration of 'qla8044_need_reset_handler' was here extern inline void qla8044_need_reset_handler(struct scsi_qla_host *vha); ^ drivers/scsi/qla2xxx/qla_gbl.h:756:20: warning: inline function 'qla8044_need_reset_handler' declared but never defined make[3]: *** [drivers/scsi/qla2xxx/qla_nx2.o] Error 1 make[2]: *** [drivers/scsi/qla2xxx] Error 2 make[1]: *** [drivers/scsi] Error 2 make: *** [drivers] Error 2 CC [M] drivers/scsi/qla2xxx/qla_tmpl.o In file included from drivers/scsi/qla2xxx/qla_def.h:3706:0, from drivers/scsi/qla2xxx/qla_tmpl.c:7: drivers/scsi/qla2xxx/qla_gbl.h:755:20: warning: inline function 'qla8044_set_qsnt_ready' declared but never defined extern inline void qla8044_set_qsnt_ready(struct scsi_qla_host *vha); ^ Signed-off-by:
Chen Gang <gang.chen.5i5j@gmail.com> Acked-by:
Saurav Kashyap <saurav.kashyap@qlogic.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Kirill A. Shutemov authored
commit 51b97e35 upstream. Sasha Levin reports: "gcc5 changes the default standard to c11, which makes kernel build unhappy Explicitly define the kernel standard to be gnu89 which should keep everything working exactly like it was before gcc5" There are multiple small issues with the new default, but the biggest issue seems to be that the old - and very useful - GNU extension to allow a cast in front of an initializer has gone away. Patch updated by Kirill: "I'm pretty sure all gcc versions you can build kernel with supports -std=gnu89. cc-option is redunrant. We also need to adjust HOSTCFLAGS otherwise allmodconfig fails for me" Note by Andrew Pinski: "Yes it was reported and both problems relating to this extension has been added to gnu99 and gnu11. Though there are other issues with the kernel dealing with extern inline have different semantics between gnu89 and gnu99/11" End result: we may be able to move up to a newer stdc model eventually, but right now the newer models have some annoying deficiencies, so the traditional "gnu89" model ends up being the preferred one. Signed-off-by:
Sasha Levin <sasha.levin@oracle.com> Singed-off-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Behan Webster authored
commit 62ec95f8 upstream. rtllib_probe_req is defined as "static inline" in rtllib_softmac.c however it is declared differently as "extern inline" in rtllib_softmac.h. Since it isn't used outside of the scope of rtllib_softmac, it makes sense to remove the incorrect declaration. Signed-off-by:
Behan Webster <behanw@converseincode.com> Suggested-by:
Arnd Bergmann <arnd@arndb.de> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Arnd Bergmann authored
commit 0c9f3a65 upstream. The rtl8712 driver has an 'extern inline' function that contains an 'if', which causes lots of warnings with CONFIG_PROFILE_ALL_BRANCHES overriding the definition of 'if': drivers/staging/rtl8712/ieee80211.h:759:229: warning: '______f' is static but declared in inline function 'ieee80211_get_hdrlen' which is not static [enabled by default] This changes the driver to use 'static inline' instead, which happens to be the correct annotation anyway. Signed-off-by:
-
Behan Webster authored
commit 6d91857d upstream. With compilers which follow the C99 standard (like modern versions of gcc and clang), "extern inline" does the opposite thing from older versions of gcc (emits code for an externally linkable version of the inline function). "static inline" does the intended behavior in all cases instead. Signed-off-by:
-
Greg Kroah-Hartman authored
Patch not upstream as this driver is deleted there. Fix up some "extern inline" functions as they break the build when using a "modern" complier (i.e. gcc5). Signed-off-by: -
Logan Gunthorpe authored
commit dc703ec2 upstream. I've had the same issue as described in commit c68929f7 Except my touchscreen's ID is ID 04f3:0125 Elan Microelectronics Corp. Signed-off-by:
Logan Gunthorpe <logang@deltatee.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Heinrich Schuchardt authored
commit bd5fb0ae upstream. A string written by the user may not be zero terminated. sscanf may read memory beyond the buffer if no zero byte is found. For testing build with CONFIG_USB_CHIPIDEA=y, CONFIG_USB_CHIPIDEA_DEBUG=y. Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
-
Ming-ting Yao Wei authored
commit 0604949c upstream. This adds rumble support for Xbox One controller by sending continuous rumble command. Trigger button rumbling is not yet implemented. Signed-off-by:
Ming-ting Yao Wei <mwei@lxde.org> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Tommi Rantala authored
commit 4dfb15cd upstream. Add Thrustmaster as Xbox 360 controller vendor. This is required for example to make the GP XID (044f:b326) gamepad work. Signed-off-by:
Tommi Rantala <tt.rantala@gmail.com> Signed-off-by:
-
Ted Mielczarek authored
commit 1a48ff81 upstream. Xbox One controllers require an initialization message to start sending data, so xpad_init_output becomes a required function. The Xbox One controller does not have LEDs like the Xbox 360 controller, so that functionality is not implemented. The format of messages controlling rumble is currently undocumented, so rumble support is not yet implemented. Note that Xbox One controller advertises three interfaces with the same interface class, subclass and protocol, so we have to also match against interface number. Signed-off-by:
Ted Mielczarek <ted@mielczarek.org> Signed-off-by:
-
Tomeu Vizoso authored
commit ef30a406 upstream. As the comment right before explains, the keyboard state is to be cleared only if the EC wasn't a wakeup source in the last suspend. Without this commit, there's an unneeded delay when resuming from suspend and we also lose the key that was pressed while suspended. Signed-off-by:
Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by:
Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by:
-
Lars Poeschel authored
commit dbea4032 upstream. This adds support for another model of IRTOUCH SYSTEMS Co.,LtD infrared touchscreens. The USB vendorID/deviceID is 6615/0012. It is also sold under the label "Elektrosil". The datasheet states that coordinates for x and y are in the range from 0 to 32767. Signed-off-by:
Lars Poeschel <poeschel@lemonage.de> Signed-off-by:
-
Jiri Kosina authored
commit 8fec02a7 upstream. In the unlikely case of hdev vanishing while hid_debug_events_read() was sleeping, we can't really break out of the case switch as with other cases, as on the way out we'll try to remove ourselves from the hdev waitqueue. Fix this by taking a shortcut exit path and avoiding cleanup that doesn't make sense in case hdev doesn't exist any more anyway. Reported-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
David Fries authored
commit a30cfa47 upstream. The struct cn_msg len field comes from userspace and needs to be validated. More logical to do so here where the cn_msg pointer is pulled out of the sk_buff than the callback which is passed cn_msg * and might assume no validation is needed. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Evgeniy Polyakov <zbr@ioremap.net> Signed-off-by:
David Fries <David@Fries.net> Signed-off-by:
-
Eric W. Biederman authored
commit cd4a4017 upstream. The only users of collect_mounts are in audit_tree.c In audit_trim_trees and audit_add_tree_rule the path passed into collect_mounts is generated from kern_path passed an audit_tree pathname which is guaranteed to be an absolute path. In those cases collect_mounts is obviously intended to work on mounted paths and if a race results in paths that are unmounted when collect_mounts it is reasonable to fail early. The paths passed into audit_tag_tree don't have the absolute path check. But are used to play with fsnotify and otherwise interact with the audit_trees, so again operating only on mounted paths appears reasonable. Avoid having to worry about what happens when we try and audit unmounted filesystems by restricting collect_mounts to mounts that appear in the mount tree. Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Jens Axboe authored
commit dc48e56d upstream. exit_aio() currently serializes killing io contexts. Each context killing ends up having to do percpu_ref_kill(), which in turns has to wait for an RCU grace period. This can take a long time, depending on the number of contexts. And there's no point in doing them serially, when we could be waiting for all of them in one fell swoop. This patches makes my fio thread offload test case exit 0.2s instead of almost 6s. Reviewed-by:
Jeff Moyer <jmoyer@redhat.com> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Oleg Nesterov authored
commit 4b70ac5f upstream. On 04/30, Benjamin LaHaise wrote: > > > - ctx->mmap_size = 0; > > - > > - kill_ioctx(mm, ctx, NULL); > > + if (ctx) { > > + ctx->mmap_size = 0; > > + kill_ioctx(mm, ctx, NULL); > > + } > > Rather than indenting and moving the two lines changing mmap_size and the > kill_ioctx() call, why not just do "if (!ctx) ... continue;"? That reduces > the number of lines changed and avoid excessive indentation. OK. To me the code looks better/simpler with "if (ctx)", but this is subjective of course, I won't argue. The patch still removes the empty line between mmap_size = 0 and kill_ioctx(), we reset mmap_size only for kill_ioctx(). But feel free to remove this change. ------------------------------------------------------------------------------- Subject: [PATCH v3 1/2] aio: change exit_aio() to load mm->ioctx_table once and avoid rcu_read_lock() 1. We can read ->ioctx_table only once and we do not read rcu_read_lock() or even rcu_dereference(). This mm has no users, nobody else can play with ->ioctx_table. Otherwise the code is buggy anyway, if we need rcu_read_lock() in a loop because ->ioctx_table can be updated then kfree(table) is obviously wrong. 2. Update the comment. "exit_mmap(mm) is coming" is the good reason to avoid munmap(), but another reason is that we simply can't do vm_munmap() unless current->mm == mm and this is not true in general, the caller is mmput(). 3. We do not really need to nullify mm->ioctx_table before return, probably the current code does this to catch the potential problems. But in this case RCU_INIT_POINTER(NULL) looks better. Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
Benjamin LaHaise <bcrl@kvack.org> Signed-off-by:
-
Tomas Henzl authored
commit 3b747298 upstream. Sometimes when the card is restarted it may cause - "irq 16: nobody cared (try booting with the "irqpoll" option)" that is likely caused so, that the card, after the hard reset finishes, pulls on the irq. Disabling the ints before or after the hpsa_kdump_hard_reset_controller fixes it. At this point we can't know in which state the card is, so using SA5_INTR_OFF + SA5_REPLY_INTR_MASK_OFFSET defines directly, instead of the function the drivers provides, seems to be apropriate. Reviewed-by:
Scott Teel <scott.teel@pmcs.com> Signed-off-by:
Don Brace <don.brace@pmcs.com> Signed-off-by:
-
Tomas Henzl authored
commit 859c75ab upstream. Add a call to pci_set_master(...) missing in the previous patch "hpsa: refine the pci enable/disable handling". Found thanks to Rob Elliot. Signed-off-by:
Tomas Henzl <thenzl@redhat.com> Reviewed-by:
Robert Elliott <elliott@hp.com> Tested-by:
-
Tomas Henzl authored
commit 132aa220 upstream. When a second(kdump) kernel starts and the hard reset method is used the driver calls pci_disable_device without previously enabling it, so the kernel shows a warning - [ 16.876248] WARNING: at drivers/pci/pci.c:1431 pci_disable_device+0x84/0x90() [ 16.882686] Device hpsa disabling already-disabled device ... This patch fixes it, in addition to this I tried to balance also some other pairs of enable/disable device in the driver. Unfortunately I wasn't able to verify the functionality for the case of a sw reset, because of a lack of proper hw. Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
-
Konrad Rzeszutek Wilk authored
commit a6dfa128 upstream. A huge amount of NIC drivers use the DMA API, however if compiled under 32-bit an very important part of the DMA API can be ommitted leading to the drivers not working at all (especially if used with 'swiotlb=force iommu=soft'). As Prashant Sreedharan explains it: "the driver [tg3] uses DEFINE_DMA_UNMAP_ADDR(), dma_unmap_addr_set() to keep a copy of the dma "mapping" and dma_unmap_addr() to get the "mapping" value. On most of the platforms this is a no-op, but ... with "iommu=soft and swiotlb=force" this house keeping is required, ... otherwise we pass 0 while calling pci_unmap_/pci_dma_sync_ instead of the DMA address." As such enable this even when using 32-bit kernels. Reported-by:
Ian Jackson <Ian.Jackson@eu.citrix.com> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Acked-by:
David S. Miller <davem@davemloft.net> Acked-by:
Prashant Sreedharan <prashant@broadcom.com> Cc: Borislav Petkov <bp@alien8.de> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Michael Chan <mchan@broadcom.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: boris.ostrovsky@oracle.com Cc: cascardo@linux.vnet.ibm.com Cc: david.vrabel@citrix.com Cc: sanjeevb@broadcom.com Cc: siva.kallam@broadcom.com Cc: vyasevich@gmail.com Cc: xen-devel@lists.xensource.com Link: http://lkml.kernel.org/r/20150417190448.GA9462@l.oracle.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Martin K. Petersen authored
commit 9a9324d3 upstream. The queued TRIM problems appear to be generic to Samsung's firmware and not tied to a particular model. A recent update to the 840 EVO firmware introduced the same issue as we saw on 850 Pro. Blacklist queued TRIM on all 800-series drives while we work this issue with Samsung. Reported-by:
Günter Waller <g.wal@web.de> Reported-by:
Sven Köhler <sven.koehler@gmail.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Martin K. Petersen authored
commit ff7f53fb upstream. Micron has released an updated firmware (MU02) for M510/M550/MX100 drives to fix the issues with queued TRIM. Queued TRIM remains broken on M500 but is working fine on later drives such as M600 and MX200. Tweak our blacklist to reflect the above. Link: https://bugzilla.kernel.org/show_bug.cgi?id=71371Signed-off-by:
-
- 21 May, 2015 1 commit
-
-
Martin Kaiser authored
drivers/gpio/gpiolib-of.c: In function 'of_gpiochip_find_and_xlate': drivers/gpio/gpiolib-of.c:52:21: warning: assignment makes integer from pointer without a cast [enabled by default] gg_data->out_gpio = ERR_PTR(ret); ^ This was introduced in 72464765, a backport of upstream commit 7b8792bb. The upstream kernel changed the type of out_gpio from int to struct gpio_desc * as part of a larger refactoring that wasn't backported Signed-off-by:Martin Kaiser <martin@kaiser.cx> Signed-off-by:
-
- 20 May, 2015 12 commits
-
-
Ian Wilson authored
[ upstream commit 78146572 ] nfnl_cthelper_parse_tuple() is called from nfnl_cthelper_new(), nfnl_cthelper_get() and nfnl_cthelper_del(). In each case they pass a pointer to an nf_conntrack_tuple data structure local variable: struct nf_conntrack_tuple tuple; ... ret = nfnl_cthelper_parse_tuple(&tuple, tb[NFCTH_TUPLE]); The problem is that this local variable is not initialized, and nfnl_cthelper_parse_tuple() only initializes two fields: src.l3num and dst.protonum. This leaves all other fields with undefined values based on whatever is on the stack: tuple->src.l3num = ntohs(nla_get_be16(tb[NFCTH_TUPLE_L3PROTONUM])); tuple->dst.protonum = nla_get_u8(tb[NFCTH_TUPLE_L4PROTONUM]); The symptom observed was that when the rpc and tns helpers were added then traffic to port 1536 was being sent to user-space. Signed-off-by:
Ian Wilson <iwilson@brocade.com> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Jiri Slaby authored
-
Lv Zheng authored
commit 1d0a0b2f upstream. ACPICA commit b60612373a4ef63b64a57c124576d7ddb6d8efb6 For physical addresses, since the address may exceed 32-bit address range after calculation, we should use 0x%8.8X%8.8X instead of ACPI_PRINTF_UINT and ACPI_FORMAT_UINT64() instead of ACPI_FORMAT_NATIVE_UINT()/ACPI_FORMAT_TO_UINT(). This patch also removes above replaced macros as there are no users. This is a preparation to switch acpi_physical_address to 64-bit on 32-bit kernel builds. Link: https://github.com/acpica/acpica/commit/b6061237Signed-off-by:
Lv Zheng <lv.zheng@intel.com> Signed-off-by:
Bob Moore <robert.moore@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
Dirk Behme <dirk.behme@gmail.com> Signed-off-by:
George G. Davis <george_davis@mentor.com> Signed-off-by:
-
Lv Zheng authored
commit cc2080b0 upstream. ACPICA commit 7f06739db43a85083a70371c14141008f20b2198 For physical addresses, since the address may exceed 32-bit address range after calculation, we should use %8.8X%8.8X (see ACPI_FORMAT_UINT64()) to convert the %p formats. This is a preparation to switch acpi_physical_address to 64-bit on 32-bit kernel builds. Link: https://github.com/acpica/acpica/commit/7f06739dSigned-off-by:
-
Lv Zheng authored
commit 6d3fd3cc upstream. ACPICA commit 154f6d074dd38d6ebc0467ad454454e6c5c9ecdf There are code pieces converting pointers using "(acpi_physical_address) x" or "ACPI_CAST_PTR (t, x)" formats, this patch cleans up them. Known issues: 1. Cleanup of "(ACPI_PHYSICAL_ADDRRESS) x" for a table field For the conversions around the table fields, it is better to fix it with alignment also fixed. So this patch doesn't modify such code. There should be no functional problem by leaving them unchanged. Link: https://github.com/acpica/acpica/commit/154f6d07Signed-off-by:
-
Lv Zheng authored
commit f254e3c5 upstream. ACPICA commit 7d9fd64397d7c38899d3dc497525f6e6b044e0e3 OSPMs like Linux expect an acpi_physical_address returning value from acpi_find_root_pointer(). This triggers warnings if sizeof (acpi_size) doesn't equal to sizeof (acpi_physical_address): drivers/acpi/osl.c:275:3: warning: passing argument 1 of 'acpi_find_root_pointer' from incompatible pointer type [enabled by default] In file included from include/acpi/acpi.h:64:0, from include/linux/acpi.h:36, from drivers/acpi/osl.c:41: include/acpi/acpixf.h:433:1: note: expected 'acpi_size *' but argument is of type 'acpi_physical_address *' This patch corrects acpi_find_root_pointer(). Link: https://github.com/acpica/acpica/commit/7d9fd643Signed-off-by:
-
Alexey Khoroshilov authored
commit bc26d4d0 upstream. A deadlock can be initiated by userspace via ioctl(SNDCTL_SEQ_OUTOFBAND) on /dev/sequencer with TMR_ECHO midi event. In this case the control flow is: sound_ioctl() -> case SND_DEV_SEQ: case SND_DEV_SEQ2: sequencer_ioctl() -> case SNDCTL_SEQ_OUTOFBAND: spin_lock_irqsave(&lock,flags); play_event(); -> case EV_TIMING: seq_timing_event() -> case TMR_ECHO: seq_copy_to_input() -> spin_lock_irqsave(&lock,flags); It seems that spin_lock_irqsave() around play_event() is not necessary, because the only other call location in seq_startplay() makes the call without acquiring spinlock. So, the patch just removes spinlocks around play_event(). By the way, it removes unreachable code in seq_timing_event(), since (seq_mode == SEQ_2) case is handled in the beginning. Compile tested only. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Cc: Willy Tarreau <w@1wt.eu> Signed-off-by:
-
Takeshi Kihara authored
commit bad4371d upstream. f9fd54f2 ("mmc: sh_mmcif: Use msecs_to_jiffies() for host->timeout") changed the timeout value from 1000 jiffies to 1s. In the case where HZ is 1000 the values are the same. However, for smaller HZ values the timeout is now smaller, 1s instead of 10s in the case of HZ=100. Since the timeout occurs in spite of a normal data transfer a timeout of 10s seems more appropriate. This restores the previous timeout in the case where HZ=100 and results in an increase over the previous timeout for larger values of HZ. Fixes: f9fd54f2 ("mmc: sh_mmcif: Use msecs_to_jiffies() for host->timeout") Signed-off-by:
Takeshi Kihara <takeshi.kihara.df@renesas.com> [horms: rewrote changelog to refer to HZ] Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Signed-off-by:
Yoshihiro Kaneko <ykaneko0929@gmail.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Grygorii Strashko authored
commit 184af16b upstream. The PM_RESTORE_PREPARE is not handled now in mmc_pm_notify(), as result mmc_rescan() could be scheduled and executed at late hibernation restore stages when MMC device is suspended already - which, in turn, will lead to system crash on TI dra7-evm board: WARNING: CPU: 0 PID: 3188 at drivers/bus/omap_l3_noc.c:148 l3_interrupt_handler+0x258/0x374() 44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data Access in User mode during Functional access Hence, add missed PM_RESTORE_PREPARE PM event in mmc_pm_notify(). Fixes: 4c2ef25f (mmc: fix all hangs related to mmc/sd card...) Signed-off-by:
Grygorii Strashko <Grygorii.Strashko@linaro.org> Signed-off-by:
-
Chuanxiao Dong authored
commit 4e93b9a6 upstream. During kernel boot, it will try to read some logical sectors of each block device node for the possible partition table. But since RPMB partition is special and can not be accessed by normal eMMC read / write CMDs, it will cause below error messages during kernel boot: ... mmc0: Got data interrupt 0x00000002 even though no data operation was in progress. mmcblk0rpmb: error -110 transferring data, sector 0, nr 32, cmd response 0x900, card status 0xb00 mmcblk0rpmb: retrying using single block read mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 end_request: I/O error, dev mmcblk0rpmb, sector 0 Buffer I/O error on device mmcblk0rpmb, logical block 0 end_request: I/O error, dev mmcblk0rpmb, sector 8 Buffer I/O error on device mmcblk0rpmb, logical block 1 end_request: I/O error, dev mmcblk0rpmb, sector 16 Buffer I/O error on device mmcblk0rpmb, logical block 2 end_request: I/O error, dev mmcblk0rpmb, sector 24 Buffer I/O error on device mmcblk0rpmb, logical block 3 ... This patch will discard the access request in eMMC queue if it is RPMB partition access request. By this way, it avoids trigger above error messages. Fixes: 090d25fe ("mmc: core: Expose access to RPMB partition") Signed-off-by:
Yunpeng Gao <yunpeng.gao@intel.com> Signed-off-by:
Chuanxiao Dong <chuanxiao.dong@intel.com> Tested-by:
Michael Shigorin <mike@altlinux.org> Signed-off-by:
-
Doug Anderson authored
commit c5272a28 upstream. Way back, when the world was a simpler place and there was no war, no evil, and no kernel bugs, there was just a single pinctrl lock. That was how the world was when (57291ce2 pinctrl: core device tree mapping table parsing support) was written. In that case, there were instances where the pinctrl mutex was already held when pinctrl_register_map() was called, hence a "locked" parameter was passed to the function to indicate that the mutex was already locked (so we shouldn't lock it again). A few years ago in (42fed7ba pinctrl: move subsystem mutex to pinctrl_dev struct), we switched to a separate pinctrl_maps_mutex. ...but (oops) we forgot to re-think about the whole "locked" parameter for pinctrl_register_map(). Basically the "locked" parameter appears to still refer to whether the bigger pinctrl_dev mutex is locked, but we're using it to skip locks of our (now separate) pinctrl_maps_mutex. That's kind of a bad thing(TM). Probably nobody noticed because most of the calls to pinctrl_register_map happen at boot time and we've got synchronous device probing. ...and even cases where we're asynchronous don't end up actually hitting the race too often. ...but after banging my head against the wall for a bug that reproduced 1 out of 1000 reboots and lots of looking through kgdb, I finally noticed this. Anyway, we can now safely remove the "locked" parameter and go back to a war-free, evil-free, and kernel-bug-free world. Fixes: 42fed7ba ("pinctrl: move subsystem mutex to pinctrl_dev struct") Signed-off-by:
Doug Anderson <dianders@chromium.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Christian König authored
commit d52cdfa4 upstream. MPEG 2/4 are only supported since UVD3. Signed-off-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
