- 01 1月, 2016 7 次提交
-
-
由 Bob Moore 提交于
ACPICA commit c2a7d000b6be34313b1c50c8a718df16113f0f32 Should be no functional change. Link: https://github.com/acpica/acpica/commit/c2a7d000Signed-off-by: NBob Moore <robert.moore@intel.com> Signed-off-by: NLv Zheng <lv.zheng@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 LABBE Corentin 提交于
ACPICA commit 28645f8a113f346c8db103a4f7565fcba88c746f Most of the "get_name" - style functions can return "const char *" with no ill side-effects. Original linux patch from LABBE Corentin <clabbe.montjoie@gmail.com> and backported to ACPICA. Link: https://github.com/acpica/acpica/commit/28645f8aSigned-off-by: NLABBE Corentin <clabbe.montjoie@gmail.com> Signed-off-by: NBob Moore <robert.moore@intel.com> Signed-off-by: NLv Zheng <lv.zheng@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 David E. Box 提交于
ACPICA commit 253e3c03efc1a495d2aa61eee09ab1d0842a3dce The control method auto-serialization can interfere with existing ASL code that makes use of Mutex/Method SyncLevel support. This change makes the auto-serialization transparent to the SyncLevel support and management. David Box. Link: https://github.com/acpica/acpica/commit/253e3c03Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com> Signed-off-by: NBob Moore <robert.moore@intel.com> Signed-off-by: NLv Zheng <lv.zheng@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Lv Zheng 提交于
ACPICA commit 75c0da9e796bdf9bdd46d75f028a3e1779903214 In the error logs and debugger outputs, use new external path format that does not contain a trailing underscore. This patch takes care of acpi_ns_get_external_pathname() invocations, chaning them into acpi_ns_get_normalized_pathname(TRUE) where possible. Along with some error log fixes, the following debugger commands are fixed: resources, handlers, paths. Lv Zheng. Link: https://github.com/acpica/acpica/commit/75c0da9eSigned-off-by: NLv Zheng <lv.zheng@intel.com> Signed-off-by: NBob Moore <robert.moore@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Lv Zheng 提交于
ACPICA commit 20228e39e125d92f9d80c6e07d3767b225d0536e The Info->Node in acpi_ns_init_one_device() may not be initialized. Even it is initialized, the redundant "._INI" can be seen for this log entry. This patch fixes this issue by using device_node instead. Lv Zheng. Link: https://github.com/acpica/acpica/commit/20228e39Signed-off-by: NLv Zheng <lv.zheng@intel.com> Signed-off-by: NBob Moore <robert.moore@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Prarit Bhargava 提交于
ACPICA commit 7bb77313091e52a846df4c9c2bea90be31bfb9d8 Eliminate warnings for "not found" _Sx errors, since these are optional. Original NOT_FOUND status is still returned. Original changes by Prarit Bhargava. ACPICA BZ 1208. Link: https://github.com/acpica/acpica/commit/7bb77313 Link: https://bugs.acpica.org/show_bug.cgi?id=1208Signed-off-by: NPrarit Bhargava <prarit@redhat.com> Signed-off-by: NBob Moore <robert.moore@intel.com> Signed-off-by: NLv Zheng <lv.zheng@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Lv Zheng 提交于
The patch reduces source code differences between the Linux kernel and the ACPICA upstream so that the linuxized ACPICA 20151218 release can be applied with reduced human intervention. The pscode.c has already been out of sync for months, and it becomes more and more difficult to merge pscode.c changes, so instead of update the affected lines of pscode.c, this patch synchronizes entire pscode.c file. Signed-off-by: NLv Zheng <lv.zheng@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 28 12月, 2015 4 次提交
-
-
由 Lv Zheng 提交于
Fix a double mutex_unlock() issue where acpi_initialize_debugger() is called with the mutex already unlocked. Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NLv Zheng <lv.zheng@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Dan Carpenter 提交于
The copy_to/from_user() functions don't return error codes, they return the number of bytes remaining. We had intended to return -EFUALT here. We actually have already checked access_ok() in an earlier function so I don't think these functions will fail but let's fix it anyway. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Dan Carpenter 提交于
"count" is unsigned so checking for less than zero here causes a static checker warning. And really it's better to let the access_ok() check fail if the user passes in a NULL "buf" pointer because -EFAULT is the correct error code. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Lv Zheng 提交于
There is one line of code, executed out of locking due to rebase mistakes. This patch fixes this issue. Signed-off-by: NLv Zheng <lv.zheng@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 25 12月, 2015 2 次提交
-
-
由 Vijay Kumar 提交于
When sysrq is triggered from console, serial driver for SUN hypervisor console receives a console break and enables the sysrq. It expects a valid sysrq char following with break. Meanwhile if driver receives 'NULL' ASCII char then it disables sysrq and sysrq handler will never be invoked. This fix skips calling uart sysrq handler when 'NULL' is received while sysrq is enabled. Signed-off-by: NVijay Kumar <vijay.ac.kumar@oracle.com> Acked-by: NKarl Volz <karl.volz@oracle.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Aya Mahfouz 提交于
Constifies sunhv_ops structures in tty's serial driver since they are not modified after their initialization. Detected and found using Coccinelle. Suggested-by: NJulia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: NAya Mahfouz <mahfouz.saif.elyazal@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 24 12月, 2015 1 次提交
-
-
由 Dan Carpenter 提交于
The "domain" variable needs to be signed for the error handling to work. Fixes: 8def3103 (cpufreq: arm_big_little: add SCPI interface driver) Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Acked-by: NViresh Kumar <viresh.kumar@linaro.org> Acked-by: NSudeep Holla <sudeep.holla@arm.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 23 12月, 2015 4 次提交
-
-
由 Chen-Yu Tsai 提交于
0x4e is the runtime address normally associated with perihperal ICs. 0x45 is not a valid runtime address. Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NOlof Johansson <olof@lixom.net>
-
由 Chen-Yu Tsai 提交于
The primary PMICs use 0x3a3 as their hardware address, not 0x3e3. Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NOlof Johansson <olof@lixom.net>
-
由 Mike Krinkin 提交于
blk_end_request_all may free request, so we need to save request_queue pointer before blk_end_request_all call. The problem was introduced in commit cf8ecc5a ("null_blk: guarantee device restart in all irq modes") and causes general protection fault with slab poisoning enabled. Fixes: cf8ecc5a ("null_blk: guarantee device restart in all irq modes") Signed-off-by: NMike Krinkin <krinkin.m.u@gmail.com> Reviewed-by: NMing Lei <tom.leiming@gmail.com> Signed-off-by: NJens Axboe <axboe@fb.com>
-
由 Keith Busch 提交于
This patch fixes a lost request discovered during IO + hot removal. The driver's pci removal deletes gendisks prior to shutting down the controller to allow dirty data to sync. Dirty data can not be synced on a surprise removal, though, and would potentially block indefinitely. The driver previously had marked the queue as dying in this scenario to prevent new requests from attempting, however it will still block for requests that already entered the queue. This patch fixes this by quiescing IO first, then aborting the requeued requests before deleting disks. Reported-by: NSujith Pandel <sujith_pandel@dell.com> Signed-off-by: NKeith Busch <keith.busch@intel.com> Tested-by: NSujith Pandel <sujith_pandel@dell.com> Signed-off-by: NJens Axboe <axboe@fb.com>
-
- 22 12月, 2015 10 次提交
-
-
由 Gary Wang 提交于
The total delay of HDMI hotplug detecting with 30ms have already been split into a resolution of 3 retries of 10ms each, for the worst cases. But it still suffered from only waiting 10ms at most in intel_hdmi_detect(). This patch corrects it by reading hotplug status with 4 times at most for 30ms delay. v2: - straight up to loop execution for more clear in code readability - mdelay will replace with msleep by Daniel's new patch drm/i915: mdelay(10) considered harmful - suggest to re-evaluate try times for being compatible to old HDMI monitor Reviewed-by: NCooper Chiou <cooper.chiou@intel.com> Tested-by: NGary Wang <gary.c.wang@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Gavin Hindman <gavin.hindman@intel.com> Cc: Sonika Jindal <sonika.jindal@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: NGary Wang <gary.c.wang@intel.com> [danvet: fixup conflict with s/mdelay/msleep/ patch.] Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 61fb3980) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Daniel Vetter 提交于
I missed this myself when reviewing commit 237ed86c Author: Sonika Jindal <sonika.jindal@intel.com> Date: Tue Sep 15 09:44:20 2015 +0530 drm/i915: Check live status before reading edid Long sleeps like this really shouldn't waste cpu cycles spinning. Cc: Sonika Jindal <sonika.jindal@intel.com> Cc: "Wang, Gary C" <gary.c.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1449859455-32609-1-git-send-email-daniel.vetter@ffwll.chReviewed-by: NSonika Jindal <sonika.jindal@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 71a199ba) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Ville Syrjälä 提交于
The vma may have been rebound between the last time the cursor was enabled and now, so skipping the cursor gtt offset deduction is not safe unless we would also reset cursor_bo to NULL when disabling the cursor. Just thow cursor_bo to the bin instead since it's lost all other uses thanks to universal plane support. Chris pointed out that cursor updates are currently too slow via universal planes that micro optimizations like these wouldn't even help. v2: Add a note about futility of micro optimizations (Chris) Cc: drm-intel-fixes@lists.freedesktop.org References: http://lists.freedesktop.org/archives/intel-gfx/2015-December/082976.html Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Takashi Iwai <tiwai@suse.de> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450107302-17171-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit 1264859d) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Ville Syrjälä 提交于
Turns out CHV pipe C was glued on somewhat poorly, and there's something wrong with the cursor. If the cursor straddles the left screen edge, and is then moved away from the edge or disabled, the pipe will often underrun. If enough underruns are triggered quickly enough the pipe will fall over and die (it just scans out a solid color and reports a constant underrun). We need to turn the disp2d power well off and on again to recover the pipe. None of that is very nice for the user, so let's just refuse to place the cursor in the compromised position. The ddx appears to fall back to swcursor when the ioctl returns an error, so theoretically there's no loss of functionality for the user (discounting swcursor bugs). I suppose most cursors images actually have the hotspot not exactly at 0,0 so under typical conditions the fallback will in fact kick in as soon as the cursor touches the left edge of the screen. Any atomic compositor should anyway be prepared to fall back to GPU composition when things don't work out, so there should be no problem with those. Other things that I tried to solve this include flipping all display related clock gating knobs I could find, increasing the minimum gtt alignment all the way up to 512k. I also tried to see if there are more specific screen coordinates that hit the bug, but the findings were somewhat inconclusive. Sometimes the failures happen almost across the whole left edge, sometimes more at the very top and around the bottom half. I wasn't able to find any real pattern to these variations, so it seems our only choice is to just refuse to straddle the left screen edge at all. Cc: stable@vger.kernel.org Cc: Jason Plum <max@warheads.net> Testcase: igt/kms_chv_cursor_fail Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92826Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450459479-16286-1-git-send-email-ville.syrjala@linux.intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit b29ec92c) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
Limit busywaiting only to the request currently being processed by the GPU. If the request is not currently being processed by the GPU, there is a very low likelihood of it being completed within the 2 microsecond spin timeout and so we will just be wasting CPU cycles. v2: Check for logical inversion when rebasing - we were incorrectly checking for this request being active, and instead busywaiting for when the GPU was not yet processing the request of interest. v3: Try another colour for the seqno names. v4: Another colour for the function names. v5: Remove the forced coherency when checking for the active request. On reflection and plenty of recent experimentation, the issue is not a cache coherency problem - but an irq/seqno ordering problem (timing issue). Here, we do not need the w/a to force ordering of the read with an interrupt. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: "Rogozhkin, Dmitry V" <dmitry.v.rogozhkin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Eero Tamminen <eero.t.tamminen@intel.com> Cc: "Rantala, Valtteri" <valtteri.rantala@intel.com> Cc: stable@vger.kernel.org Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449833608-22125-4-git-send-email-chris@chris-wilson.co.uk (cherry picked from commit 821485dc) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
When waiting for high frequency requests, the finite amount of time required to set up the irq and wait upon it limits the response rate. By busywaiting on the request completion for a short while we can service the high frequency waits as quick as possible. However, if it is a slow request, we want to sleep as quickly as possible. The tradeoff between waiting and sleeping is roughly the time it takes to sleep on a request, on the order of a microsecond. Based on measurements of synchronous workloads from across big core and little atom, I have set the limit for busywaiting as 10 microseconds. In most of the synchronous cases, we can reduce the limit down to as little as 2 miscroseconds, but that leaves quite a few test cases regressing by factors of 3 and more. The code currently uses the jiffie clock, but that is far too coarse (on the order of 10 milliseconds) and results in poor interactivity as the CPU ends up being hogged by slow requests. To get microsecond resolution we need to use a high resolution timer. The cheapest of which is polling local_clock(), but that is only valid on the same CPU. If we switch CPUs because the task was preempted, we can also use that as an indicator that the system is too busy to waste cycles on spinning and we should sleep instead. __i915_spin_request was introduced in commit 2def4ad9 [v4.2] Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Apr 7 16:20:41 2015 +0100 drm/i915: Optimistically spin for the request completion v2: Drop full u64 for unsigned long - the timer is 32bit wraparound safe, so we can use native register sizes on smaller architectures. Mention the approximate microseconds units for elapsed time and add some extra comments describing the reason for busywaiting. v3: Raise the limit to 10us v4: Now 5us. Reported-by: NJens Axboe <axboe@kernel.dk> Link: https://lkml.org/lkml/2015/11/12/621Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: "Rogozhkin, Dmitry V" <dmitry.v.rogozhkin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Eero Tamminen <eero.t.tamminen@intel.com> Cc: "Rantala, Valtteri" <valtteri.rantala@intel.com> Cc: stable@vger.kernel.org Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449833608-22125-3-git-send-email-chris@chris-wilson.co.uk (cherry picked from commit ca5b721e) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
The busywait in __i915_spin_request() does not respect pending signals and so may consume the entire timeslice for the task instead of returning to userspace to handle the signal. In the worst case this could cause a delay in signal processing of 20ms, which would be a noticeable jitter in cursor tracking. If a higher resolution signal was being used, for example to provide fairness of a server timeslices between clients, we could expect to detect some unfairness between clients (i.e. some windows not updating as fast as others). This issue was noticed when inspecting a report of poor interactivity resulting from excessively high __i915_spin_request usage. Fixes regression from commit 2def4ad9 [v4.2] Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Apr 7 16:20:41 2015 +0100 drm/i915: Optimistically spin for the request completion v2: Try to assess the impact of the bug Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Jens Axboe <axboe@kernel.dk> Cc; "Rogozhkin, Dmitry V" <dmitry.v.rogozhkin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Eero Tamminen <eero.t.tamminen@intel.com> Cc: "Rantala, Valtteri" <valtteri.rantala@intel.com> Cc: stable@vger.kernel.org Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449833608-22125-2-git-send-email-chris@chris-wilson.co.uk (cherry picked from commit 91b0c352) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Matt Roper 提交于
If we fail to reconstruct the BIOS fb (e.g., because the FB is too large), we'll be left with plane state that indicates the primary plane is visible yet has a NULL fb. This mismatch causes problems later on (e.g., for the watermark code). Since we've failed to reconstruct the BIOS FB, the best solution is to just disable the primary plane and pretend the BIOS never had it enabled. v2: Add intel_pre_disable_primary() call (Maarten) Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1449171462-30763-2-git-send-email-matthew.d.roper@intel.com (cherry picked from commit 200757f5) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
As we mark the preallocated objects as bound, we should also flag them correctly as being map-and-fenceable (if appropriate!) so that later users do not get confused and try and rebind the pinned vma in order to get a map-and-fenceable binding. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: "Goel, Akash" <akash.goel@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: drm-intel-fixes@lists.freedesktop.org Link: http://patchwork.freedesktop.org/patch/msgid/1448029000-10616-1-git-send-email-chris@chris-wilson.co.ukReviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit d0710abb) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Ville Syrjälä 提交于
The cursor code tries to treat base==0 to mean disabled. That fails when the cursor bo gets bound at ggtt offset 0, and the user is left looking at an invisible cursor. We lose the disabled->disabled optimization, but that seems like something better handled at a slightly higher level. Cc: drm-intel-fixes@lists.freedesktop.org Cc: Takashi Iwai <tiwai@suse.de> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450091808-32607-3-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit 663f3122) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 21 12月, 2015 2 次提交
-
-
由 Srinivas Pandruvada 提交于
The processor cooling device is no longer present for passive thermal control. Commit 239708a3 ("ACPI: Split out ACPI PSS from ACPI Processor driver") moved the processing to a new function acpi_pss_perf_init(), but missed "return 0" after successful creation. This causes the error handling functions to be called, which will delete the previously created processor cooling device. Fixes: 239708a3 (ACPI: Split out ACPI PSS from ACPI Processor driver) Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: 4.3+ <stable@vger.kernel.org> # 4.3+ Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 NeilBrown 提交于
md currently doesn't allow a 'sync_action' such as 'reshape' to be set while MD_RECOVERY_NEEDED is set. This s a problem, particularly since commit 738a2738 as that can cause ->check_shape to call mddev_resume() which sets MD_RECOVERY_NEEDED. So by the time we come to start 'reshape' it is very likely that MD_RECOVERY_NEEDED is still set. Testing for this flag is not really needed and is in any case very racy as it can be set at any moment - asynchronously. Any race between setting a sync_action and setting MD_RECOVERY_NEEDED must already be handled properly in some locked code, probably md_check_recovery(), so remove the test here. The test on MD_RECOVERY_RUNNING is also racy in the 'reshape' case so we should test it again after getting mddev_lock(). As this fixes a race and a regression which can cause 'reshape' to fail, it is suitable for -stable kernels since 4.1 Reported-by: NXiao Ni <xni@redhat.com> Fixes: 738a2738 ("md/raid5: fix allocation of 'scribble' array.") Cc: stable@vger.kernel.org (v4.1+) Signed-off-by: NNeilBrown <neilb@suse.com>
-
- 20 12月, 2015 3 次提交
-
-
由 Steve Twiss 提交于
This fix alters the ordering of the IRQ and device registrations in the RTC driver probe function. This change will apply to the RTC driver that supports both DA9063 and DA9062 PMICs. A problem could occur with the existing RTC driver if: A system is started from a cold boot using the PMIC RTC IRQ to initiate a power on operation. For instance, if an RTC alarm is used to start a platform from power off. The existing driver IRQ is requested before the device has been properly registered. i.e. ret = devm_request_threaded_irq() comes before rtc->rtc_dev = devm_rtc_device_register(); In this case, the interrupt can be called before the device has been registered and the handler can be called immediately. The IRQ handler da9063_alarm_event() contains the function call rtc_update_irq(rtc->rtc_dev, 1, RTC_IRQF | RTC_AF); which in turn tries to access the unavailable rtc->rtc_dev. The fix is to reorder the functions inside the RTC probe. The IRQ is requested after the RTC device resource has been registered so that get_irq_byname is the last thing to happen. Signed-off-by: NSteve Twiss <stwiss.opensource@diasemi.com> Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
-
由 Julius Werner 提交于
In A.D. 1582 Pope Gregory XIII found that the existing Julian calendar insufficiently represented reality, and changed the rules about calculating leap years to account for this. Similarly, in A.D. 2013 Rockchip hardware engineers found that the new Gregorian calendar still contained flaws, and that the month of November should be counted up to 31 days instead. Unfortunately it takes a long time for calendar changes to gain widespread adoption, and just like more than 300 years went by before the last Protestant nation implemented Greg's proposal, we will have to wait a while until all religions and operating system kernels acknowledge the inherent advantages of the Rockchip system. Until then we need to translate dates read from (and written to) Rockchip hardware back to the Gregorian format. This patch works by defining Jan 1st, 2016 as the arbitrary anchor date on which Rockchip and Gregorian calendars are in sync. From that we can translate arbitrary later dates back and forth by counting the number of November/December transitons since the anchor date to determine the offset between the calendars. We choose this method (rather than trying to regularly "correct" the date stored in hardware) since it's the only way to ensure perfect time-keeping even if the system may be shut down for an unknown number of years. The drawback is that other software reading the same hardware (e.g. mainboard firmware) must use the same translation convention (including the same anchor date) to be able to read and write correct timestamps from/to the RTC. Signed-off-by: NJulius Werner <jwerner@chromium.org> Reviewed-by: NDouglas Anderson <dianders@chromium.org> Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
-
由 Andrzej Hajda 提交于
Since atomic check is called also for disabled crtcs it should skip mode checking as it can be uninitialized. The patch fixes it. Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com> Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Tested-by: NJavier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
- 19 12月, 2015 7 次提交
-
-
由 Wolfram Sang 提交于
When we also are I2C slave, we need to disable runtime PM because the address detection mechanism needs to be active all the time. However, we can reenable runtime PM once the slave instance was unregistered. So, use pm_runtime_get_sync/put to achieve this, since it has proper refcounting. pm_runtime_allow/forbid is like a global knob controllable from userspace which is unsuitable here. Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org
-
由 James Chen 提交于
When sending "SLEEP" command to the controller it ceases scanning completely and is unable to wake the system up from sleep, so if it is configured as a wakeup source we should simply configure interrupt for wakeup and rely on idle logic within the controller to reduce power consumption while it is not used. Signed-off-by: NJames Chen <james.chen@emc.com.tw> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Alan Stern 提交于
Commit 8520f380 ("USB: change hub initialization sleeps to delayed_work") changed the hub_activate() routine to make part of it run in a workqueue. However, the commit failed to take a reference to the usb_hub structure or to lock the hub interface while doing so. As a result, if a hub is plugged in and quickly unplugged before the work routine can run, the routine will try to access memory that has been deallocated. Or, if the hub is unplugged while the routine is running, the memory may be deallocated while it is in active use. This patch fixes the problem by taking a reference to the usb_hub at the start of hub_activate() and releasing it at the end (when the work is finished), and by locking the hub interface while the work routine is running. It also adds a check at the start of the routine to see if the hub has already been disconnected, in which nothing should be done. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Reported-by: NAlexandru Cornea <alexandru.cornea@intel.com> Tested-by: NAlexandru Cornea <alexandru.cornea@intel.com> Fixes: 8520f380 ("USB: change hub initialization sleeps to delayed_work") CC: <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Dan Carpenter 提交于
The code expects the loop to end with "retries" set to zero but, because it is a post-op, it will end set to -1. I have fixed this by moving the decrement inside the loop. Fixes: 014aa2a3 ('USB: ipaq: minor ipaq_open() cleanup.') Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Antti Palosaari 提交于
Driver requested device firmware version string during probe using only 24 byte long buffer. That buffer is too small for newer firmware versions, which causes device firmware hang - device stops responding to any commands after that. Increase buffer size to 128 which should be enough for any current and future version strings. Link: https://github.com/airspy/host/issues/27 Cc: <stable@vger.kernel.org> # 3.17+ Reported-by: NBenjamin Vernoux <bvernoux@gmail.com> Signed-off-by: NAntti Palosaari <crope@iki.fi> Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
-
由 Antti Palosaari 提交于
Used Avago MGA-81563 RF amplifier could be destroyed pretty easily with too strong signal or transmitting to bad antenna. Add module parameter 'enable_rf_gain_ctrl' which allows enabling RF gain control - otherwise, default without the module parameter, RF gain control is set to 'grabbed' state which prevents setting value to the control. Signed-off-by: NAntti Palosaari <crope@iki.fi> Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
-
由 Antti Palosaari 提交于
drivers/media/usb/hackrf/hackrf.c:1533 hackrf_probe() error: we previously assumed 'dev' could be null (see line 1366) Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NAntti Palosaari <crope@iki.fi> Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
-