- 03 Mar, 2013 30 commits
-
-
Jeff Liu authored
commit 32918dd9 upstream. We need to re-initialize the security for a new reflinked inode with its parent dirs if it isn't specified to be preserved for ocfs2_reflink(). However, the code logic is broken at ocfs2_init_security_and_acl() although ocfs2_init_security_get() succeed. As a result, ocfs2_acl_init() does not involked and therefore the default ACL of parent dir was missing on the new inode. Note this was introduced by 9d8f13ba ("security: new security_inode_init_security API adds function callback") To reproduce: set default ACL for the parent dir(ocfs2 in this case): $ setfacl -m default:user:jeff:rwx ../ocfs2/ $ getfacl ../ocfs2/ # file: ../ocfs2/ # owner: jeff # group: jeff user::rwx group::r-x other::r-x default:user::rwx default:user:jeff:rwx default:group::r-x default:mask::rwx default:other::r-x $ touch a $ getfacl a # file: a # owner: jeff # group: jeff user::rw- group::rw- other::r-- Before patching, create reflink file b from a, the user default ACL entry(user:jeff:rwx)was missing: $ ./ocfs2_reflink a b $ getfacl b # file: b # owner: jeff # group: jeff user::rw- group::rw- other::r-- In this case, the end user can also observed an error message at syslog: (ocfs2_reflink,3229,2):ocfs2_init_security_and_acl:7193 ERROR: status = 0 After applying this patch, create reflink file c from a: $ ./ocfs2_reflink a c $ getfacl c # file: c # owner: jeff # group: jeff user::rw- user:jeff:rwx #effective:rw- group::r-x #effective:r-- mask::rw- other::r-- Test program: /* Usage: reflink <source> <dest> */ #include <stdio.h> #include <stdint.h> #include <stdbool.h> #include <string.h> #include <errno.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <sys/ioctl.h> static int reflink_file(char const *src_name, char const *dst_name, bool preserve_attrs) { int fd; #ifndef REFLINK_ATTR_NONE # define REFLINK_ATTR_NONE 0 #endif #ifndef REFLINK_ATTR_PRESERVE # define REFLINK_ATTR_PRESERVE 1 #endif #ifndef OCFS2_IOC_REFLINK struct reflink_arguments { uint64_t old_path; uint64_t new_path; uint64_t preserve; }; # define OCFS2_IOC_REFLINK _IOW ('o', 4, struct reflink_arguments) #endif struct reflink_arguments args = { .old_path = (unsigned long) src_name, .new_path = (unsigned long) dst_name, .preserve = preserve_attrs ? REFLINK_ATTR_PRESERVE : REFLINK_ATTR_NONE, }; fd = open(src_name, O_RDONLY); if (fd < 0) { fprintf(stderr, "Failed to open %s: %s\n", src_name, strerror(errno)); return -1; } if (ioctl(fd, OCFS2_IOC_REFLINK, &args) < 0) { fprintf(stderr, "Failed to reflink %s to %s: %s\n", src_name, dst_name, strerror(errno)); return -1; } } int main(int argc, char *argv[]) { if (argc != 3) { fprintf(stdout, "Usage: %s source dest\n", argv[0]); return 1; } return reflink_file(argv[1], argv[2], 0); } Signed-off-by:
Jie Liu <jeff.liu@oracle.com> Reviewed-by:
Tao Ma <boyu.mt@taobao.com> Cc: Mimi Zohar <zohar@linux.vnet.ibm.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Mark Fasheh <mfasheh@suse.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jan Kara authored
commit 9b171e0c upstream. Running AIO is pinning inode in memory using file reference. Once AIO is completed using aio_complete(), file reference is put and inode can be freed from memory. So we have to be sure that calling aio_complete() is the last thing we do with the inode. Signed-off-by:
Jan Kara <jack@suse.cz> Acked-by:
Jeff Moyer <jmoyer@redhat.com> Acked-by:
Joel Becker <jlbec@evilplan.org> Cc: Mark Fasheh <mfasheh@suse.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Nicholas Bellinger authored
commit fbbf8555 upstream. This patch adds missing bounds checking for the configfs provided mapped_lun value during target_fabric_make_mappedlun() setup ahead of se_lun_acl initialization. This addresses a potential OOPs when using a mapped_lun value that exceeds the hardcoded TRANSPORT_MAX_LUNS_PER_TPG-1 value within se_node_acl->device_list[]. Reported-by:
Jan Engelhardt <jengelh@inai.de> Cc: Jan Engelhardt <jengelh@inai.de> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Nicholas Bellinger authored
commit fcf29481 upstream. This patch fixes a bug in core_tpg_check_initiator_node_acl() -> core_tpg_get_initiator_node_acl() where a dynamically created se_node_acl generated during session login would be skipped during subsequent lookup due to the '!acl->dynamic_node_acl' check, causing a new se_node_acl to be created with a duplicate ->initiatorname. This would occur when a fabric endpoint was configured with TFO->tpg_check_demo_mode()=1 + TPF->tpg_check_demo_mode_cache()=1 preventing the release of an existing se_node_acl during se_session shutdown. Also, drop the unnecessary usage of core_tpg_get_initiator_node_acl() within core_dev_init_initiator_node_lun_acl() that originally required the extra '!acl->dynamic_node_acl' check, and just pass the configfs provided se_node_acl pointer instead. Signed-off-by:
-
H. Peter Anvin authored
commit 7c100936 upstream. On non-BIOS platforms it is possible that the BIOS data area contains garbage instead of being zeroed or something equivalent (firmware people: we are talking of 1.5K here, so please do the sane thing.) We need on the order of 20-30K of low memory in order to boot, which may grow up to < 64K in the future. We probably want to avoid the lowest of the low memory. At the same time, it seems extremely unlikely that a legitimate EBDA would ever reach down to the 128K (which would require it to be over half a megabyte in size.) Thus, pick 128K as the cutoff for "this is insane, ignore." We may still end up reserving a bunch of extra memory on the low megabyte, but that is not really a major issue these days. In the worst case we lose 512K of RAM. This code really should be merged with trim_bios_range() in arch/x86/kernel/setup.c, but that is a bigger patch for a later merge window. Reported-by:
Darren Hart <dvhart@linux.intel.com> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Cc: Matt Fleming <matt.fleming@intel.com> Link: http://lkml.kernel.org/n/tip-oebml055yyfm8yxmria09rja@git.kernel.orgSigned-off-by:
-
Konrad Rzeszutek Wilk authored
commit a2fd6419 upstream. Both the PowerPC hypervisor and Xen hypervisor can utilize the hvc driver. Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Link: http://lkml.kernel.org/r/1361825650-14031-3-git-send-email-konrad.wilk@oracle.comSigned-off-by:
-
Konrad Rzeszutek Wilk authored
commit 2482a92e upstream. The earlyprintk for Xen PV guests utilizes a simple hypercall (console_io) to provide output to Xen emergency console. Note that the Xen hypervisor should be booted with 'loglevel=all' to output said information. Reported-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Matt Fleming authored
commit fb834c7a upstream. commit 1de63d60 ("efi: Clear EFI_RUNTIME_SERVICES rather than EFI_BOOT by "noefi" boot parameter") attempted to make "noefi" true to its documentation and disable EFI runtime services to prevent the bricking bug described in commit e0094244 ("samsung-laptop: Disable on EFI hardware"). However, it's not possible to clear EFI_RUNTIME_SERVICES from an early param function because EFI_RUNTIME_SERVICES is set in efi_init() *after* parse_early_param(). This resulted in "noefi" effectively becoming a no-op and no longer providing users with a way to disable EFI, which is bad for those users that have buggy machines. Reported-by:
Walt Nelson Jr <walt0924@gmail.com> Cc: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com> Signed-off-by:
Matt Fleming <matt.fleming@intel.com> Link: http://lkml.kernel.org/r/1361392572-25657-1-git-send-email-matt@console-pimps.orgSigned-off-by:
-
Mathias Krause authored
commit 27cf9298 upstream. Including " lapic " in the kernel cmdline on an x86-64 kernel makes it panic while parsing early params -- e.g. with no user visible output. Fix this bug by ensuring arg is non-NULL before passing it to strncmp(). Reported-by:
PaX Team <pageexec@freemail.hu> Signed-off-by:
Mathias Krause <minipli@googlemail.com> Acked-by:
David Rientjes <rientjes@google.com> Cc: Suresh Siddha <suresh.b.siddha@intel.com> Link: http://lkml.kernel.org/r/1361303227-13174-1-git-send-email-minipli@googlemail.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Steven Rostedt (Red Hat) authored
commit 8c189ea6 upstream. Commit: c1bf08ac "ftrace: Be first to run code modification on modules" changed ftrace module notifier's priority to INT_MAX in order to process the ftrace nops before anything else could touch them (namely kprobes). This was the correct thing to do. Unfortunately, the ftrace module notifier also contains the ftrace clean up code. As opposed to the set up code, this code should be run *after* all the module notifiers have run in case a module is doing correct clean-up and unregisters its ftrace hooks. Basically, ftrace needs to do clean up on module removal, as it needs to know about code being removed so that it doesn't try to modify that code. But after it removes the module from its records, if a ftrace user tries to remove a probe, that removal will fail due as the record of that code segment no longer exists. Nothing really bad happens if the probe removal is called after ftrace did the clean up, but the ftrace removal function will return an error. Correct code (such as kprobes) will produce a WARN_ON() if it fails to remove the probe. As people get annoyed by frivolous warnings, it's best to do the ftrace clean up after everything else. By splitting the ftrace_module_notifier into two notifiers, one that does the module load setup that is run at high priority, and the other that is called for module clean up that is run at low priority, the problem is solved. Reported-by:
Frank Ch. Eigler <fche@redhat.com> Acked-by:
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Tejun Heo authored
commit e182bb38 upstream. When idr_find() was fed a negative ID, it used to look up the ID ignoring the sign bit before recent ("idr: remove MAX_IDR_MASK and move left MAX_IDR_* into idr.c") patch. Now a negative ID triggers a WARN_ON_ONCE(). __lock_timer() feeds timer_id from userland directly to idr_find() without sanitizing it which can trigger the above malfunctions. Add a range check on @timer_id before invoking idr_find() in __lock_timer(). While timer_t is defined as int by all archs at the moment, Andrew worries that it may be defined as a larger type later on. Make the test cover larger integers too so that it at least is guaranteed to not return the wrong timer. Note that WARN_ON_ONCE() in idr_find() on id < 0 is transitional precaution while moving away from ignoring MSB. Once it's gone we can remove the guard as long as timer_t isn't larger than int. Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by:
Sasha Levin <sasha.levin@oracle.com> Cc: Andrew Morton <akpm@linux-foundation.org> Link: http://lkml.kernel.org/r/20130220232412.GL3570@htj.dyndns.orgSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Joerg Roedel authored
commit f528d980 upstream. When dma_ops are initialized the unity mappings are created. The init_device_table_dma() function makes sure DMA from all devices is blocked by default. This opens a short window in time where DMA to unity mapped regions is blocked by the IOMMU. Make sure this does not happen by initializing the device table after dma_ops. Signed-off-by:
Joerg Roedel <joro@8bytes.org> Signed-off-by:
-
Adam Thomas authored
commit 8afd500c upstream. The last orphan in the dnext list has its dnext set to NULL. Because of that, ubifs_delete_orphan assumes that it is not on the dnext list and frees it immediately instead ignoring it as a second delete. The orphan is later freed again by erase_deleted. This change adds an explicit flag to ubifs_orphan indicating whether it is pending delete. Signed-off-by:
Adam Thomas <adamthomas1111@gmail.com> Signed-off-by:
Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by:
-
Adam Thomas authored
commit 2928f0d0 upstream. The last orphan in the cnext list has its cnext set to NULL. Because of that, ubifs_delete_orphan assumes that it is not on the cnext list and frees it immediately instead of adding it to the dnext list. The freed orphan is later modified by write_orph_node. This can cause various inconsistencies including directory entries that cannot be removed and this error: UBIFS error (pid 20685): layout_cnodes: LPT out of space at LEB 14:129009 needing 17, done_ltab 1, done_lsave 1 This is a regression introduced by "7074e5eb UBIFS: remove invalid reference to list iterator variable". This change adds an explicit flag to ubifs_orphan indicating whether it is pending commit. Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
-
Larry Finger authored
commit 63a02ce1 upstream. On unload, b43 produces a lockdep warning that can be summarized in the following way: ====================================================== [ INFO: possible circular locking dependency detected ] 3.8.0-wl+ #117 Not tainted ------------------------------------------------------- modprobe/5557 is trying to acquire lock: ((&wl->firmware_load)){+.+.+.}, at: [<ffffffff81062160>] flush_work+0x0/0x2a0 but task is already holding lock: (rtnl_mutex){+.+.+.}, at: [<ffffffff813bd7d2>] rtnl_lock+0x12/0x20 which lock already depends on the new lock. [ INFO: possible circular locking dependency detected ] ====================================================== The full output is available at http://lkml.indiana.edu/hypermail/linux/kernel/1302.3/00060.html. To summarize, commit 6b6fa586 added a 'cancel_work_sync(&wl->firmware_load)' call in the wrong place. The fix is to move the cancel_work_sync() call to b43_bcma_remove() and b43_ssb_remove(). Thanks to Johannes Berg and Michael Buesch for help in diagnosing the log output. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Felipe Balbi authored
commit 1a947746 upstream. First of all, that 28 value makes no sense as HIRD threshold is a 4-bit value, second of all it's causing issues for OMAP5. Using 12 because commit cbc725b3 (usb: dwc3: keep default hird threshold value as 4b1100) had the intention of setting the maximum allowed value of 0xc. Also, original code has been wrong forever, so this should be backported as far back as possible. Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Pratyush Anand authored
commit 915e202a upstream. When we reach to link trb, we just need to increase free_slot and then calculate TRB. Return is not correct, as it will cause wrong TRB DMA address to fetch in case of update transfer. Signed-off-by:
Pratyush Anand <pratyush.anand@st.com> Signed-off-by:
-
Pratyush Anand authored
commit cdc359dd upstream. There were still some corner cases where isoc transfer was not able to restart, specially when missed isoc does not happen , and in fact gadget does not queue any new request during giveback. Cleanup function calls giveback first, which provides a way to queue another request to gadget. But gadget did not had any data. So , it did not call ep_queue. To twist it further, gadget did not queue till cleanup for last queued TRB is called. If we ever reach this scenario, we must call END TRANSFER, so that we receive a new xfernotready with information about current microframe number. Also insure that there is no request submitted to core when issuing END TRANSFER. Signed-off-by:
-
Pratyush Anand authored
commit 7efea86c upstream. There are two reasons to generate missed isoc. 1. when the host does not poll for all the data. 2. because of application-side delays that prevent all the data from being transferred in programmed microframe. Current code was able to handle first case only. This patch handles scenario 2 as well.Scenario 2 sometime may occur with complex gadget application, however it can be easily reproduced for testing purpose as follows: a. use isoc binterval as 1 in f_sourcesink. b. use pattern=0 c. introduce a delay of 150us deliberately in source_sink_complete, so that after few frames it lands into scenario 2. d. now run testusb 16 (isoc in test). You will notice that if this patch is not applied then isoc transfer is not able to recover after first missed. Current patch's approach is as under: If missed isoc occurs and there is no request queued then issue END TRANSFER, so that core generates next xfernotready and we will issue a fresh START TRANSFER. If there are still queued request then wait, do not issue either END or UPDATE TRANSFER, just attach next request in request_list during giveback. If any future queued request is successfully transferred then we will issue UPDATE TRANSFER for all request in the request_list. Signed-off-by:
-
Pratyush Anand authored
commit 2b758350 upstream. Synopsys says: The HIRD Threshold field must be set to ‘0’ when the device core is operating in super speed mode. This patch implements above statement. Acked-by:
Paul Zimmerman <paulz@synopsys.com> Signed-off-by:
-
Theodore Ts'o authored
commit c3ad83d9 upstream. Otherwise, ext4 file systems with the quota featured enable will get a very confusing "No such process" error message if the quota code is built as a module and the quota_v2 module has not been loaded. Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Reviewed-by:
Carlos Maiolino <cmaiolino@redhat.com> Acked-by:
-
Bart Van Assche authored
commit 2ce19e72 upstream. If an SRP target is no longer reachable and srp_reset_host() fails to reconnect then ib_srp will invoke scsi_remove_host(). That function will invoke __scsi_remove_device() for each LUN. And that last function will change the device state from SDEV_TRANSPORT_OFFLINE into SDEV_CANCEL. Certain user space software, e.g. older versions of multipathd, continue queueing I/O to SCSI devices that are in the SDEV_CANCEL state. If these I/O requests are submitted as SG_IO that means that the REQ_PREEMPT flag will be set and hence that these requests will be passed to srp_queuecommand(). These requests will time out. If new requests are queued fast enough from user space these active requests will prevent __scsi_remove_device() to finish. Avoid this by failing I/O requests in the SDEV_CANCEL state if the transport is offline. Introduce a new variable to keep track of the transport state instead of failing requests if (!target->connected || target->qp_in_error), so that the SCSI error handler has a chance to retry commands after a transport layer failure occurred. Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
-
Bart Van Assche authored
commit c7c4e7ff upstream. If a SCSI command times out it is passed to the SCSI error handler. The SCSI error handler will try to abort the commands that timed out. If aborting fails, a device reset will be attempted. If the device reset also fails a host reset will be attempted. If the host reset also fails the whole procedure will be repeated. srp_abort() and srp_reset_device() fail for a QP in the error state. srp_reset_host() fails after host removal has started. Hence if the SCSI error handler gets invoked after host removal has started and with the QP in the error state an endless loop will be triggered. Modify the SCSI error handling functions in ib_srp as follows: - Abort SCSI commands properly even if the QP is in the error state. - Make srp_reset_host() reset SCSI requests even after host removal has already started or if reconnecting fails. Signed-off-by:
David Dillow <dave@thedillows.org> Signed-off-by:
-
Bart Van Assche authored
commit 3780d1f0 upstream. Do not send a task management function if sending will fail anyway because either there is no RDMA/RC connection or the QP is in the error state. Signed-off-by:
-
Bart Van Assche authored
commit e1b2f13a upstream. Remove an assignment that incorrectly overwrites the connection state update by srp_connect_target(). Signed-off-by:
-
Florian Zeitz authored
commit b56ddbe5 upstream. This expands the regression fix from d2821599. The firmware also needs to be loaded when it was already cached. Signed-off-by:
Florian Zeitz <florob@babelmonkeys.de> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Mihail Zenkov authored
commit d2821599 upstream. This patch fix regression in emu1010 firmware loading after http://git.alsa-project.org/?p=alsa-kprivate.git;a=commitdiff;h=b209c4dfcd960ab176d4746ab7dc442a3edb4575 I just revert small part of this commit. Tested on emu1212m pci. Signed-off-by:
Mihail Zenkov <mihail.zenkov@gmail.com> Signed-off-by:
-
David Henningsson authored
commit 30efd8de upstream. Just as for analog codecs, a jack that isn't suitable for detection (in this case, NO_PRESENCE was set) should be a phantom Jack instead of a normal one. Thanks to Raymond Yau for spotting. BugLink: https://bugs.launchpad.net/bugs/961286 BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=903869Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
-
Takashi Iwai authored
commit aacfddfd upstream. Along with a clean up commit [e9f66d9b: ALSA: pci: clean up using module_pci_driver()], bt87x driver lost the functionality of load_all parameter. This patch does a partial revert of the commit only for bt87x.c to recover it. Reported-by:
Clemens Ladisch <cladisch@googlemail.com> Signed-off-by:
-
Linus Torvalds authored
commit 09884964 upstream. The stack vma is designed to grow automatically (marked with VM_GROWSUP or VM_GROWSDOWN depending on architecture) when an access is made beyond the existing boundary. However, particularly if you have not limited your stack at all ("ulimit -s unlimited"), this can cause the stack to grow even if the access was really just one past *another* segment. And that's wrong, especially since we first grow the segment, but then immediately later enforce the stack guard page on the last page of the segment. So _despite_ first growing the stack segment as a result of the access, the kernel will then make the access cause a SIGSEGV anyway! So do the same logic as the guard page check does, and consider an access to within one page of the next segment to be a bad access, rather than growing the stack to abut the next segment. Reported-and-tested-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
-
- 28 Feb, 2013 10 commits
-
-
Greg Kroah-Hartman authored
-
Ben Skeggs authored
commit ac8cc241 upstream. A single U encoder table can match multiple DCB entries, whereas the reverse is not true and can lead to us not matching a DCB entry at all, and fail to initialise some encoders. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Ben Skeggs authored
commit 8e992c8d upstream. Matches format used by a couple of other vbios tables, useful to have laying around already calculated. Signed-off-by:
-
Ben Skeggs authored
commit f3ed1048 upstream. Signed-off-by:
-
Fabio Baltieri authored
commit 99d17cfa upstream. This patch converts the module to use clk_prepare_enable and clk_disable_unprepare variants as required by common clock framework. Without this the system crash during probe function. Signed-off-by:
Fabio Baltieri <fabio.baltieri@linaro.org> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Ming Lei authored
commit 25736e0c upstream. This patch let glue driver return -EPROBE_DEFER if the transceiver is not readly, so we can support defer probe on musb to fix the below error on 3.7-rc5 if transceiver drivers are built as module: [ 19.052490] unable to find transceiver of type USB2 PHY [ 19.072052] HS USB OTG: no transceiver configured [ 19.076995] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -19 [ 19.089355] musb-hdrc: probe of musb-hdrc.0.auto rejects match -19 [ 19.096771] driver: 'musb-omap2430': driver_bound: bound to device 'musb-omap2430' [ 19.105194] bus: 'platform': really_probe: bound device musb-omap2430 to driver musb-omap2430 [ 19.174407] bus: 'platform': add driver twl4030_usb [ 19.179656] bus: 'platform': driver_probe_device: matched device twl4030_usb with driver twl4030_usb [ 19.202270] bus: 'platform': really_probe: probing driver twl4030_usb with device twl4030_usb [ 19.214172] twl4030_usb twl4030_usb: HW_CONDITIONS 0xc0/192; link 3 [ 19.239624] musb-omap2430 musb-omap2430: musb core is not yet ready [ 19.246765] twl4030_usb twl4030_usb: Initialized TWL4030 USB module [ 19.254516] driver: 'twl4030_usb': driver_bound: bound to device 'twl4030_usb' [ 19.263580] bus: 'platform': really_probe: bound device twl4030_usb to driver twl4030_usb Cc: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by:
Ming Lei <ming.lei@canonical.com> Signed-off-by:
-
Ming Lei authored
commit 681d1e87 upstream. In the fail1~fail5 failure path, pm_runtime_disable() should be called to avoid 'Unbalanced pm_runtime_enable' error in next probe() which may be triggered by defer probe or next 'modprobe musb_hdrc'. Cc: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by:
-
Josh Boyer authored
commit 18e03310 upstream. The current entry in unusual_cypress.h for the Super TOP SATA bridge devices seems to be causing corruption on newer revisions of this device. This has been reported in Arch Linux and Fedora. The original patch was tested on devices with bcdDevice of 1.60, whereas the newer devices report bcdDevice as 2.20. Limit the UNUSUAL_DEV entry to devices less than 2.20. This fixes https://bugzilla.redhat.com/show_bug.cgi?id=909591 The Arch Forum post on this is here: https://bbs.archlinux.org/viewtopic.php?id=152011Reported-by:
Carsten S. <carsteniq@yahoo.com> Tested-by:
Josh Boyer <jwboyer@redhat.com> Signed-off-by:
-
fangxiaozhi authored
commit cd060956 upstream. 1. The idProduct is little endian, so make sure its value to be compatible with the current CPU. Make no break on big endian processors. Signed-off-by:
fangxiaozhi <huananhu@huawei.com> Signed-off-by:
-
Roger Quadros authored
commit 04753523 upstream. The module alias should be "ehci-omap" and not "omap-ehci" to match the platform device name. The omap-ehci module should now autoload correctly. Signed-off-by:
Roger Quadros <rogerq@ti.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
