- 11 Nov, 2011 40 commits
-
-
Kuninori Morimoto authored
commit 19b115e5 upstream. ak4642 register was 8bit, but cache table was defined as 16bit. ak4642 doesn't work correctry without this patch. Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Axel Lin authored
commit 3a340104 upstream. According to the datasheet: Format Control (05h) BITS[3:2] FMT[1:0] Audio data format selection 00 = right justified mode 01 = left justified mode 10 = I2S mode 11 = DSP mode BIT[4] LRP Polarity selec for LRCLK/DSP mode select 0 = normal LRCLK poalrity/DSP mode A 1 = inverted LRCLK poarity/DSP mode B For SND_SOC_DAIFMT_DSP_A, we should set 0x000C instead of 0x0003. For SND_SOC_DAIFMT_DSP_B, we should set 0x001C instead of 0x0013. Signed-off-by:
Axel Lin <axel.lin@gmail.com> Acked-by:
Liam Girdwood <lrg@ti.com> Signed-off-by:
-
Axel Lin authored
commit 5927f947 upstream. Reported-by:
Chris Paulson-Ellis <chris@edesix.com> Signed-off-by:
-
Daniel Vetter authored
commit 24dd85ff upstream. For the !HAVE_ATOMIC_IOMAP case the stub functions did not call pagefault_disable/_enable. The i915 driver relies on the map actually being atomic, otherwise it can deadlock with it's own pagefault handler in the gtt pwrite fastpath. This is exercised by gem_mmap_gtt from the intel-gpu-toosl gem testsuite. v2: Chris Wilson noted the lack of an include. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38115Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
-
Bryan Schumaker authored
commit a877ee03 upstream. nfsiostat was failing to find mounted filesystems on kernels after 2.6.38 because of changes to show_vfsstat() by commit c7f404b4. This patch adds back the "device" tag before the nfs server entry so scripts can parse the mountstats file correctly. Signed-off-by:
Bryan Schumaker <bjschuma@netapp.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
J. Bruce Fields authored
commit c30e92df upstream. We don't use WANT bits yet--and sending them can probably trigger a BUG() further down. Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
J. Bruce Fields authored
commit 3d02fa29 upstream. Yet another open-management regression: - nfs4_file_downgrade() doesn't remove the BOTH access bit on downgrade, so the server's idea of the stateid's access gets out of sync with the client's. If we want to keep an O_RDWR open in this case, we should do that in the file_put_access logic rather than here. - We forgot to convert v4 access to an open mode here. This logic has proven too hard to get right. In the future we may consider: - reexamining the lock/openowner relationship (locks probably don't really need to take their own references here). - adding open upgrade/downgrade support to the vfs. - removing the atomic operations. They're redundant as long as this is all under some other lock. Also, maybe some kind of additional static checking would help catch O_/NFS4_SHARE_ACCESS confusion. Signed-off-by:
-
J. Bruce Fields authored
commit a043226b upstream. A client that wants to execute a file must be able to read it. Read opens over nfs are therefore implicitly allowed for executable files even when those files are not readable. NFSv2/v3 get this right by using a passed-in NFSD_MAY_OWNER_OVERRIDE on read requests, but NFSv4 has gotten this wrong ever since dc730e17 "nfsd4: fix owner-override on open", when we realized that the file owner shouldn't override permissions on non-reclaim NFSv4 opens. So we can't use NFSD_MAY_OWNER_OVERRIDE to tell nfsd_permission to allow reads of executable files. So, do the same thing we do whenever we encounter another weird NFS permission nit: define yet another NFSD_MAY_* flag. The industry's future standardization on 128-bit processors will be motivated primarily by the need for integers with enough bits for all the NFSD_MAY_* flags. Reported-by:
Leonardo Borda <leonardoborda@gmail.com> Signed-off-by:
-
J. Bruce Fields authored
commit 57616300 upstream. The set of errors here does *not* agree with the set of errors specified in the rfc! While we're there, turn this macros into a function, for the usual reasons, and move it to the one place where it's actually used. Signed-off-by:
-
J. Bruce Fields authored
commit 3e772463 upstream. The server is returning nfserr_resource for both permanent errors and for errors (like allocation failures) that might be resolved by retrying later. Save nfserr_resource for the former and use delay/jukebox for the latter. Signed-off-by:
-
Bernd Schubert authored
commit 832023bf upstream. Fan Yong <yong.fan@whamcloud.com> noticed setting FMODE_32bithash wouldn't work with nfsd v4, as nfsd4_readdir() checks for 32 bit cookies. However, according to RFC 3530 cookies have a 64 bit type and cookies are also defined as u64 in 'struct nfsd4_readdir'. So remove the test for >32-bit values. Signed-off-by:
Bernd Schubert <bernd.schubert@itwm.fraunhofer.de> Signed-off-by:
-
Jeff Layton authored
commit 2da95652 upstream. nfs_find_and_lock_request will take a reference to the nfs_page and will then put it if the req is already locked. It's possible though that the reference will be the last one. That put then can kick off a whole series of reference puts: nfs_page nfs_open_context dentry inode If the inode ends up being deleted, then the VFS will call truncate_inode_pages. That function will try to take the page lock, but it was already locked when migrate_page was called. The code deadlocks. Fix this by simply refusing the migration request if PagePrivate is already set, indicating that the page is already associated with an active read or write request. We've had a customer test a backported version of this patch and the preliminary results seem good. Cc: Andrea Arcangeli <aarcange@redhat.com> Reported-by:
Harshula Jayasuriya <harshula@redhat.com> Signed-off-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Ian Campbell authored
commit 9bab0b7f upstream. This adds a mechanism to resume selected IRQs during syscore_resume instead of dpm_resume_noirq. Under Xen we need to resume IRQs associated with IPIs early enough that the resched IPI is unmasked and we can therefore schedule ourselves out of the stop_machine where the suspend/resume takes place. This issue was introduced by 676dc3cf "xen: Use IRQF_FORCE_RESUME". Signed-off-by:
Ian Campbell <ian.campbell@citrix.com> Cc: Rafael J. Wysocki <rjw@sisk.pl> Cc: Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com> Cc: xen-devel <xen-devel@lists.xensource.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Link: http://lkml.kernel.org/r/1318713254.11016.52.camel@dagon.hellion.org.ukSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Steven Rostedt authored
commit 436fc280 upstream. The trace_pipe_raw handler holds a cached page from the time the file is opened to the time it is closed. The cached page is used to handle the case of the user space buffer being smaller than what was read from the ring buffer. The left over buffer is held in the cache so that the next read will continue where the data left off. After EOF is returned (no more data in the buffer), the index of the cached page is set to zero. If a user app reads the page again after EOF, the check in the buffer will see that the cached page is less than page size and will return the cached page again. This will cause reading the trace_pipe_raw again after EOF to return duplicate data, making the output look like the time went backwards but instead data is just repeated. The fix is to not reset the index right after all data is read from the cache, but to reset it after all data is read and more data exists in the ring buffer. Reported-by:
Jeremy Eder <jeder@redhat.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Masami Hiramatsu authored
commit 02ca1521 upstream. Fix kprobe-tracer not to delete a probe if the probe is in use. In that case, delete operation will return -EBUSY. This bug can cause a kernel panic if enabled probes are deleted during perf record. (Add some probes on functions) sh-4.2# perf probe --del probe:\* sh-4.2# exit (kernel panic) This is originally reported on the fedora bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=742383 I've also checked that this problem doesn't happen on tracepoints when module removing because perf event locks target module. $ sudo ./perf record -e xfs:\* -aR sh sh-4.2# rmmod xfs ERROR: Module xfs is in use sh-4.2# exit [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.203 MB perf.data (~8862 samples) ] Signed-off-by:
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Frank Ch. Eigler <fche@redhat.com> Link: http://lkml.kernel.org/r/20111004104438.14591.6553.stgit@fedora15Signed-off-by:
-
Masami Hiramatsu authored
commit 44a56040 upstream. Fix perf probe to show correct error string when it fails to delete an event. The write(2) returns -1 if failed, and errno stores real error number. Signed-off-by:
-
NeilBrown authored
commit 355840e7 upstream. This bug was introduced in 415e72d0 which was in 2.6.36. There is a small window of time between when a device fails and when it is removed from the array. During this time we might still read from it, but we won't write to it - so it is possible that we could read stale data. We didn't need the test of 'Faulty' before because the test on In_sync is sufficient. Since we started allowing reads from the early part of non-In_sync devices we need a test on Faulty too. This is suitable for any kernel from 2.6.36 onwards, though the patch might need a bit of tweaking in 3.0 and earlier. Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
Jan Beulich authored
commit 838312be upstream. These warnings (generally one per CPU) are a result of initializing x86_cpu_to_logical_apicid while apic_default is still in use, but the check in setup_local_APIC() being done when apic_bigsmp was already used as an override in default_setup_apic_routing(): Overriding APIC driver with bigsmp Enabling APIC mode: Physflat. Using 5 I/O APICs ------------[ cut here ]------------ WARNING: at .../arch/x86/kernel/apic/apic.c:1239 ... CPU 1 irqstacks, hard=f1c9a000 soft=f1c9c000 Booting Node 0, Processors #1 smpboot cpu 1: start_ip = 9e000 Initializing CPU#1 ------------[ cut here ]------------ WARNING: at .../arch/x86/kernel/apic/apic.c:1239 setup_local_APIC+0x137/0x46b() Hardware name: ... CPU1 logical APIC ID: 2 != 8 ... Fix this (for the time being, i.e. until x86_32_early_logical_apicid() will get removed again, as Tejun says ought to be possible) by overriding the previously stored values at the point where the APIC driver gets overridden. v2: Move this and the pre-existing override logic into arch/x86/kernel/apic/bigsmp_32.c. Signed-off-by:
Jan Beulich <jbeulich@suse.com> Acked-by:
Tejun Heo <tj@kernel.org> Link: http://lkml.kernel.org/r/4E835D16020000780005844C@nat28.tlf.novell.comSigned-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
hank authored
commit cbbc719f upstream. The parameter's origin type is long. On an i386 architecture, it can easily be larger than 0x80000000, causing this function to convert it to a sign-extended u64 type. Change the type to unsigned long so we get the correct result. Signed-off-by:
hank <pyu@redhat.com> Cc: John Stultz <john.stultz@linaro.org> [ build fix ] Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Stanislaw Gruszka authored
commit 107ef97a upstream. This fix regression introduced by commit: commit 15b3f3b0 Author: Wey-Yi Guy <wey-yi.w.guy@intel.com> Date: Fri Jun 3 07:54:13 2011 -0700 iwlagn: set smps mode after assoc for 1000 device Also remove unneeded brackets on the way. Address: https://bugzilla.redhat.com/show_bug.cgi?id=744155Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Acked-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Luciano Coelho authored
commit 6cd9d21a upstream. We were using incorrect max and min dwell times during forced passive scans because we were still using the active scan states to scan (passively) the channels that were not marked as passive. Instead of doing passive scans in active states, we now skip active states and scan for all channels in passive states. Signed-off-by:
Luciano Coelho <coelho@ti.com> Signed-off-by:
-
Richard Cochran authored
commit da92b194 upstream. The pair of functions, * skb_clone_tx_timestamp() * skb_complete_tx_timestamp() were designed to allow timestamping in PHY devices. The first function, called during the MAC driver's hard_xmit method, identifies PTP protocol packets, clones them, and gives them to the PHY device driver. The PHY driver may hold onto the packet and deliver it at a later time using the second function, which adds the packet to the socket's error queue. As pointed out by Johannes, nothing prevents the socket from disappearing while the cloned packet is sitting in the PHY driver awaiting a timestamp. This patch fixes the issue by taking a reference on the socket for each such packet. In addition, the comments regarding the usage of these function are expanded to highlight the rule that PHY drivers must use skb_complete_tx_timestamp() to release the packet, in order to release the socket reference, too. These functions first appeared in v2.6.36. Reported-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
Richard Cochran <richard.cochran@omicron.at> Signed-off-by:
Eric Dumazet <eric.dumazet@gmail.com> Reviewed-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Johannes Berg authored
commit 28a1bcdb upstream. When I introduced in-kernel off-channel TX I introduced a bug -- the work can't be canceled again because the code clear the skb pointer. Fix this by keeping track separately of whether TX status has already been reported. Reported-by:
Jouni Malinen <j@w1.fi> Tested-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Richard Cochran authored
commit 8b3408f8 upstream. If the PHY should disappear (for example, on an USB Ethernet MAC), then the driver would leak any undelivered time stamp packets. This commit fixes the issue by calling the appropriate functions to free any packets left in the transmit and receive queues. The driver first appeared in v3.0. Signed-off-by:
-
Eric W. Biederman authored
commit d2237d35 upstream. Renato Westphal noticed that since commit a2835763 "rtnetlink: handle rtnl_link netlink notifications manually" was merged we no longer send a netlink message when a networking device is moved from one network namespace to another. Fix this by adding the missing manual notification in dev_change_net_namespaces. Since all network devices that are processed by dev_change_net_namspaces are in the initialized state the complicated tests that guard the manual rtmsg_ifinfo calls in rollback_registered and register_netdevice are unnecessary and we can just perform a plain notification. Tested-by:
Renato Westphal <renatowestphal@gmail.com> Signed-off-by:
Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
-
Ming Lei authored
commit 5e5a4f5d upstream. This quirk patch fixes one kind of bug inside some Intel Sandybridge chipsets, see reports from https://bugzilla.kernel.org/show_bug.cgi?id=40592. Many guys also have reported the problem before: https://bugs.launchpad.net/bugs/737388 https://bugs.launchpad.net/bugs/794642 https://bugs.launchpad.net/bugs/782389 ...... With help from Tejun, the problem is found to be caused by 32bit PIO mode, so introduce the quirk patch to disable 32bit PIO on SATA piix for some Sandybridge CPT chipsets. Seth also tested the patch on all five affected chipsets (pci device ID: 0x1c00, 0x1c01, 0x1d00, 0x1e00, 0x1e01), and found the patch does fix the problem. Tested-by:
Heasley, Seth <seth.heasley@intel.com> Cc: Alan Cox <alan@linux.intel.com> Signed-off-by:
Ming Lei <ming.lei@canonical.com> Acked-by:
Tejun Heo <htejun@gmail.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Jeff Layton authored
commit 3236c3e1 upstream. commit 420e3646 allowed the kernel to reduce the number of unnecessary commit calls by skipping the commit when there are a large number of outstanding pages. However, the current test in nfs_commit_unstable_pages does not handle the edge condition properly. When ncommit == 0, then that means that the kernel doesn't need to do anything more for the inode. The current test though in the WB_SYNC_NONE case will return true, and the inode will end up being marked dirty. Once that happens the inode will never be clean until there's a WB_SYNC_ALL flush. Fix this by immediately returning from nfs_commit_unstable_pages when ncommit == 0. Mike noticed this problem initially in RHEL5 (2.6.18-based kernel) which has a backported version of 420e3646. The inode cache there was growing very large. The inode cache was unable to be shrunk since the inodes were all marked dirty. Calling sync() would essentially "fix" the problem -- the WB_SYNC_ALL flush would result in the inodes all being marked clean. What I'm not clear on is how big a problem this is in mainline kernels as the writeback code there is very different. Either way, it seems incorrect to re-mark the inode dirty in this case. Reported-by:
Mike McLean <mikem@redhat.com> Signed-off-by:
-
Peng Tao authored
commit c1225158 upstream. The same function is used by idmap, gss and blocklayout code. Make it generic. Signed-off-by:
Peng Tao <peng_tao@emc.com> Signed-off-by:
Jim Rees <rees@umich.edu> Signed-off-by:
-
Trond Myklebust authored
commit 59b7c05f upstream. This reverts commit b80c3cb6. The reverted commit was rendered obsolete by a VFS fix: commit 5547e8aa (writeback: Update dirty flags in two steps). We now no longer need to worry about writeback_single_inode() missing our marking the inode for COMMIT in 'do_writepages()' call. Reverting this patch, fixes a performance regression in which the inode would continuously get queued to the dirty list, causing the writeback code to unnecessarily try to send a COMMIT. Signed-off-by:
Simon Kirby <sim@hostway.ca> Signed-off-by:
-
Jiri Kosina authored
commit 37252db6 upstream. Due to post-increment in condition of kmod_loop_msg in __request_module(), the system log can be spammed by much more than 5 instances of the 'runaway loop' message if the number of events triggering it makes the kmod_loop_msg to overflow. Fix that by making sure we never increment it past the threshold. Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Peng Tao authored
commit 75422745 upstream. We should check if the sector is already initialized before trying to grab the page from page cache. Otherwise when two pages of the same block are written back by two threads each calling from writepage_locked, it can cause deadlock like bellow. [ 1080.972099] INFO: task kswapd0:25 blocked for more than 120 seconds. [ 1080.972377] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1080.972812] kswapd0 D ffff88000c4926c0 0 25 2 0x00000000 [ 1080.972816] ffff88000df276b0 0000000000000046 ffff88000df27640 ffffffff81013ba7 [ 1080.972821] ffff88000c492310 ffff88000df27fd8 ffff88000df27fd8 00000000001d3440 [ 1080.972824] ffff88000c378000 ffff88000c492310 ffff8800175d3d40 ffff880017fc75a8 [ 1080.972828] Call Trace: [ 1080.972860] [<ffffffff81013ba7>] ? read_tsc+0x9/0x19 [ 1080.972877] [<ffffffff810e0b23>] ? lock_page+0x2b/0x2b [ 1080.972899] [<ffffffff81475a1d>] io_schedule+0x63/0x7e [ 1080.972902] [<ffffffff810e0b31>] sleep_on_page+0xe/0x12 [ 1080.972905] [<ffffffff81475fe8>] __wait_on_bit_lock+0x46/0x8f [ 1080.972916] [<ffffffff810822d7>] ? lock_release_holdtime.part.7+0x6b/0x72 [ 1080.972919] [<ffffffff810e0af6>] __lock_page+0x66/0x68 [ 1080.972928] [<ffffffff81072705>] ? autoremove_wake_function+0x3d/0x3d [ 1080.972932] [<ffffffff810e0b1f>] lock_page+0x27/0x2b [ 1080.972934] [<ffffffff810e0bcf>] find_lock_page+0x34/0x57 [ 1080.972937] [<ffffffff810e1738>] find_or_create_page+0x34/0x8a [ 1080.972947] [<ffffffffa034245b>] bl_write_pagelist+0x205/0x6da [blocklayoutdriver] [ 1080.972951] [<ffffffffa034145d>] ? bl_free_lseg+0x38/0x38 [blocklayoutdriver] [ 1080.972995] [<ffffffffa02e27b9>] ? nfs_write_rpcsetup+0x118/0x123 [nfs] [ 1080.973033] [<ffffffffa030246b>] pnfs_generic_pg_writepages+0x10b/0x1f4 [nfs] [ 1080.973089] [<ffffffffa02deaae>] nfs_pageio_doio+0x1a/0x43 [nfs] [ 1080.973098] [<ffffffffa02df035>] nfs_pageio_complete+0x16/0x2d [nfs] [ 1080.973108] [<ffffffffa02e2d8f>] nfs_writepage_locked+0xa0/0xbf [nfs] [ 1080.973119] [<ffffffffa02e36a1>] nfs_writepage+0x16/0x2b [nfs] [ 1080.973122] [<ffffffff810e8762>] ? clear_page_dirty_for_io+0x87/0x9a [ 1080.973133] [<ffffffff810efc5b>] shrink_page_list+0x39b/0x6c8 [ 1080.973139] [<ffffffff810f03bb>] shrink_inactive_list+0x22c/0x39e [ 1080.973144] [<ffffffff810822d7>] ? lock_release_holdtime.part.7+0x6b/0x72 [ 1080.973148] [<ffffffff810f0c33>] shrink_zone+0x445/0x588 [ 1080.973152] [<ffffffff810f1a11>] balance_pgdat+0x2c2/0x56b [ 1080.973170] [<ffffffff81254208>] ? __bitmap_weight+0x34/0x80 [ 1080.973175] [<ffffffff810f1f78>] kswapd+0x2be/0x2fa [ 1080.973179] [<ffffffff810726c8>] ? __init_waitqueue_head+0x4b/0x4b [ 1080.973183] [<ffffffff810f1cba>] ? balance_pgdat+0x56b/0x56b [ 1080.973187] [<ffffffff81071f69>] kthread+0xa8/0xb0 [ 1080.973200] [<ffffffff814806b4>] kernel_thread_helper+0x4/0x10 [ 1080.973205] [<ffffffff81071ec1>] ? __init_kthread_worker+0x5a/0x5a [ 1080.973210] [<ffffffff814806b0>] ? gs_change+0x13/0x13 [ 1080.973213] no locks held by kswapd0/25. Signed-off-by:
-
Peng Tao authored
commit e6d05a75 upstream. bl_add_page_to_bio returns error pointer. bio should be reset to NULL in failure cases as the out path always calls bl_submit_bio. Signed-off-by:
-
Peng Tao authored
commit 9b7eecdc upstream. For pnfs pagelist read failure, we need to pg_recoalesce and resend IO to mds. Signed-off-by:
-
Peng Tao authored
commit 8ce160c5 upstream. For pnfs pagelist write failure, we need to pg_recoalesce and resend IO to mds. Signed-off-by:
-
Peng Tao authored
commit 1b0ae068 upstream. file layout and block layout both use it to set mark layout io failure bit. So make it generic. Signed-off-by:
-
Peng Tao authored
commit 760383f1 upstream. Reviewed-by:
-
Jim Rees authored
commit fdc17abb upstream. Make the status field explicitly 32 bits. "...it's unlikely that the kernel and userspace would differ on the size of an int here, but it might be a good idea to go ahead and make that explicitly 32 bits in case we end up dealing with more exotic arches at some point in the future." Suggested-by:
Benny Halevy <bhalevy@tonian.com> Signed-off-by:
-
Jim Rees authored
commit 516f2e24 upstream. Always return PTR_ERR, not NULL, from nfs4_blk_get_deviceinfo and nfs4_blk_decode_device. Check for IS_ERR, not NULL, in bl_set_layoutdriver when calling nfs4_blk_get_deviceinfo. Signed-off-by:
-
David Herrmann authored
commit a7ea1992 upstream. samsung_init() should not return success if not all devices are initialized. Otherwise, samsung_exit() will dereference sdev NULL pointers and others. Signed-off-by:
David Herrmann <dh.herrmann@googlemail.com> Signed-off-by:
Matthew Garrett <mjg@redhat.com>
-
Jason Stubbs authored
commit bee460be upstream. The min_brightness value of the sabi_config is incorrectly used in brightness calculations. For the config where min_brightness = 1 and max_brightness = 8, the user visible range should be 0 to 7 with hardware being set in the range of 1 to 8. What is actually happening is that the user visible range is 0 to 8 with hardware being set in the range of -1 to 7. This patch fixes the above issue as well as a miscalculation that would occur in the case of min_brightness > 1. Signed-off-by:
Jason Stubbs <jasonbstubbs@gmail.com> Signed-off-by:
-
