- 13 Apr, 2015 40 commits
-
-
Andy Shevchenko authored
commit 854d2f24 upstream. The logic of DMA completion is broken now since test_and_clear_bit() never returns the other bit is set. It means condition are always false and we have spi_finalize_current_transfer() called per each DMA completion which is wrong. The patch fixes logic by clearing BUSY bit first and then check for the other one. Fixes: 30c8eb52 (spi: dw-mid: split rx and tx callbacks when DMA) Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ivan T. Ivanov authored
commit 12cb89e3 upstream. num-cs is 32 bit property, don't read just upper 16 bits. Fixes: 4a8573ab (spi: qup: Remove chip select function) Signed-off-by:
Ivan T. Ivanov <iivanov@mm-sol.com> Signed-off-by:
-
Mikulas Patocka authored
commit 09ee96b2 upstream. The "dm snapshot: suspend origin when doing exception handover" commit fixed a exception store handover bug associated with pending exceptions to the "snapshot-origin" target. However, a similar problem exists in snapshot merging. When snapshot merging is in progress, we use the target "snapshot-merge" instead of "snapshot-origin". Consequently, during exception store handover, we must find the snapshot-merge target and suspend its associated mapped_device. To avoid lockdep warnings, the target must be suspended and resumed without holding _origins_lock. Introduce a dm_hold() function that grabs a reference on a mapped_device, but unlike dm_get(), it doesn't crash if the device has the DMF_FREEING flag set, it returns an error in this case. In snapshot_resume() we grab the reference to the origin device using dm_hold() while holding _origins_lock (_origins_lock guarantees that the device won't disappear). Then we release _origins_lock, suspend the device and grab _origins_lock again. NOTE to stable@ people: When backporting to kernels 3.18 and older, use dm_internal_suspend and dm_internal_resume instead of dm_internal_suspend_fast and dm_internal_resume_fast. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Mikulas Patocka authored
commit b735fede upstream. In the function snapshot_resume we perform exception store handover. If there is another active snapshot target, the exception store is moved from this target to the target that is being resumed. The problem is that if there is some pending exception, it will point to an incorrect exception store after that handover, causing a crash due to dm-snap-persistent.c:get_exception()'s BUG_ON. This bug can be triggered by repeatedly changing snapshot permissions with "lvchange -p r" and "lvchange -p rw" while there are writes on the associated origin device. To fix this bug, we must suspend the origin device when doing the exception store handover to make sure that there are no pending exceptions: - introduce _origin_hash that keeps track of dm_origin structures. - introduce functions __lookup_dm_origin, __insert_dm_origin and __remove_dm_origin that manipulate the origin hash. - modify snapshot_resume so that it calls dm_internal_suspend_fast() and dm_internal_resume_fast() on the origin device. NOTE to stable@ people: When backporting to kernels 3.12-3.18, use dm_internal_suspend and dm_internal_resume instead of dm_internal_suspend_fast and dm_internal_resume_fast. When backporting to kernels older than 3.12, you need to pick functions dm_internal_suspend and dm_internal_resume from the commit fd2ed4d2. Signed-off-by:
-
Joe Thornber authored
commit 5f027a3b upstream. It was always intended that a read to an unprovisioned block will return zeroes regardless of whether the pool is in read-only or read-write mode. thin_bio_map() was inconsistent with its handling of such reads when the pool is in read-only mode, it now properly zero-fills the bios it returns in response to unprovisioned block reads. Eliminate thin_bio_map()'s special read-only mode handling of -ENODATA and just allow the IO to be deferred to the worker which will result in pool->process_bio() handling the IO (which already properly zero-fills reads to unprovisioned blocks). Reported-by:
Eric Sandeen <sandeen@redhat.com> Signed-off-by:
Joe Thornber <ejt@redhat.com> Signed-off-by:
-
Darrick J. Wong authored
commit e5db2980 upstream. Since it's possible for the discard and write same queue limits to change while the upper level command is being sliced and diced, fix up both of them (a) to reject IO if the special command is unsupported at the start of the function and (b) read the limits once and let the commands error out on their own if the status happens to change. Signed-off-by:
Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by:
-
Mikulas Patocka authored
commit ab7c7bb6 upstream. __dm_destroy() must take the suspend_lock so that its presuspend and postsuspend calls do not race with an internal suspend. Signed-off-by:
-
Andy Shevchenko authored
commit a104a45b upstream. The commit 9cade1a4 (dma: dw: split driver to library part and platform code) introduced a separate platform driver but missed to add a MODULE_ALIAS("platform:dw_dmac"); to that module. The patch adds this to get driver loaded automatically if platform device is registered. Reported-by:
"Blin, Jerome" <jerome.blin@intel.com> Fixes: 9cade1a4 (dma: dw: split driver to library part and platform code) Signed-off-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
Malcolm Priestley authored
commit 1f51d580 upstream. byRFType is not set prior to registration of mac80211 causing unpredictable operation after channel scans. With byRFType unset all channels are enabled this causes tx power to be set to values not present its eeprom. Move setting of this variable to vt6655_probe. byRFType must have a mask set. byRevId not used by driver and is removed. Signed-off-by:
Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by:
-
Malcolm Priestley authored
commit 40c8790b upstream. When the driver sets this rate a power of zero value is set causing data flow stoppage until another rate is tried. Signed-off-by:
-
Malcolm Priestley authored
commit 163fe301 upstream. When the driver sets this rate a power of zero value is set causing data flow stoppage until another rate is tried. Signed-off-by:
-
Peter Zijlstra authored
commit d525211f upstream. Vince reported a watchdog lockup like: [<ffffffff8115e114>] perf_tp_event+0xc4/0x210 [<ffffffff810b4f8a>] perf_trace_lock+0x12a/0x160 [<ffffffff810b7f10>] lock_release+0x130/0x260 [<ffffffff816c7474>] _raw_spin_unlock_irqrestore+0x24/0x40 [<ffffffff8107bb4d>] do_send_sig_info+0x5d/0x80 [<ffffffff811f69df>] send_sigio_to_task+0x12f/0x1a0 [<ffffffff811f71ce>] send_sigio+0xae/0x100 [<ffffffff811f72b7>] kill_fasync+0x97/0xf0 [<ffffffff8115d0b4>] perf_event_wakeup+0xd4/0xf0 [<ffffffff8115d103>] perf_pending_event+0x33/0x60 [<ffffffff8114e3fc>] irq_work_run_list+0x4c/0x80 [<ffffffff8114e448>] irq_work_run+0x18/0x40 [<ffffffff810196af>] smp_trace_irq_work_interrupt+0x3f/0xc0 [<ffffffff816c99bd>] trace_irq_work_interrupt+0x6d/0x80 Which is caused by an irq_work generating new irq_work and therefore not allowing forward progress. This happens because processing the perf irq_work triggers another perf event (tracepoint stuff) which in turn generates an irq_work ad infinitum. Avoid this by raising the recursion counter in the irq_work -- which effectively disables all software events (including tracepoints) from actually triggering again. Reported-by:
Vince Weaver <vincent.weaver@maine.edu> Tested-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Steven Rostedt <rostedt@goodmis.org> Link: http://lkml.kernel.org/r/20150219170311.GH21418@twins.programming.kicks-ass.netSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Laurent Pinchart authored
commit d7c14605 upstream. The error code paths that require cleanup use a goto to jump to the cleanup code and return an error code. However, the error code variable res, which is initialized to -EINVAL when declared, is then overwritten with the return value of of_parse_phandle_with_args(), and reused as the return code from of_irq_parse_one(). This leads to an undetermined error being returned instead of the expected -EINVAL value. Fix it. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Pontus Fuchs authored
commit 3f161534 upstream. A short or malformed vendor command buffer could cause reads outside the command buffer. Signed-off-by:
Pontus Fuchs <pontusf@broadcom.com> [arend@broadcom.com: slightly modified debug trace output] Signed-off-by:
Arend van Spriel <arend@broadcom.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Gregory CLEMENT authored
commit 43b68879 upstream. As stated in kernel/cpu_pm.c, "Platform is responsible for ensuring that cpu_pm_enter is not called twice on the same CPU before cpu_pm_exit is called.". In the current code in case of failure when calling mvebu_v7_cpu_suspend, the function cpu_pm_exit() is never called whereas cpu_pm_enter() was called just before. This patch moves the cpu_pm_exit() in order to balance the cpu_pm_enter() calls. Reported-by:
Fulvio Benini <fbf@libero.it> Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by:
-
Larry Finger authored
commit c8f03455 upstream. Routine rtl_is_special_data() is supposed to identify packets that need to use a low bit rate so that the probability of successful transmission is high. The current version has a bug that causes all IPv6 packets to be labelled as special, with a corresponding low rate of transmission. A complete fix will be quite intrusive, but until that is available, all IPv6 packets are identified as regular. This patch also removes a magic number. Reported-and-tested-by:
Alan Fisher <acf@unixcube.org> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: Alan Fisher <acf@unixcube.org> Signed-off-by:
-
Thierry Reding authored
commit 2f1bce48 upstream. devm_phy_create() stores the pointer to the new PHY at the address returned by devres_alloc(). The res parameter passed to devm_phy_match() is therefore the location where the pointer to the PHY is stored, hence it needs to be dereferenced before comparing to the match data in order to find the correct match. Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
-
Peter Chen authored
commit a886bd92 upstream. We should signal connect (pull up dp) after we have already at peripheral mode, otherwise, the dp may be toggled due to we reset controller or do disconnect during the initialization for peripheral, then, the host may be confused during the enumeration, eg, it finds the reset can't succeed, but the device is still there, see below error message. hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: cannot reset port 1 (err = -32) hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? hub 1-0:1.0: unable to enumerate USB device on port 1 Fixes: the issue existed when the otg fsm code was added. Signed-off-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
-
Li Jun authored
commit d20f7807 upstream. This patch adds response to a_alt_hnp_support set feature request from legacy A device, that is, B-device can provide a message to the user indicating that the user needs to connect the B-device to an alternate port on the A-device. A device sets this feature indicates to the B-device that it is connected to an A-device port that is not capable of HNP, but that the A-device does have an alternate port that is capable of HNP. [Peter] Without this patch, the OTG B device can't be enumerated on non-HNP port at A device, see below log: [ 2.287464] usb 1-1: Dual-Role OTG device on non-HNP port [ 2.293105] usb 1-1: can't set HNP mode: -32 [ 2.417422] usb 1-1: new high-speed USB device number 4 using ci_hdrc [ 2.460635] usb 1-1: Dual-Role OTG device on non-HNP port [ 2.466424] usb 1-1: can't set HNP mode: -32 [ 2.587464] usb 1-1: new high-speed USB device number 5 using ci_hdrc [ 2.630649] usb 1-1: Dual-Role OTG device on non-HNP port [ 2.636436] usb 1-1: can't set HNP mode: -32 [ 2.641003] usb usb1-port1: unable to enumerate USB device Acked-by:
Li Jun <b47624@freescale.com> Signed-off-by:
-
David Dueck authored
commit d0f347d6 upstream. This fixes a potential null pointer dereference. Fixes: d4332013 ("driver core: dev_get_drvdata: Don't check for NULL dev") Acked-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
David Dueck <davidcdueck@googlemail.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Hans de Goede authored
commit bda13e35 upstream. A new uas compatible controller has shown up in some people's devices from the manufacturer Initio Corporation, this controller needs the US_FL_NO_ATA_1X quirk to work properly with uas, so add it to the uas quirks table. Reported-and-tested-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Andrei Otcheretianski authored
commit 833d9b97 upstream. iwl_mvm_stop_roc removes TE only if running flag is set. This is not correct since this flag is only set when the TE is started. This resulted in a TE not being removed, when mac80211 believes that there are no active ROCs. Fixes: bf5da87f ("iwlwifi: mvm: add remove flow for AUX ROC time events") Signed-off-by:
Andrei Otcheretianski <andrei.otcheretianski@intel.com> Reviewed-by:
Matti Gottlieb <matti.gottlieb@intel.com> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Emmanuel Grumbach authored
commit 4cd4b50c upstream. The commit below introduced an unsafe dereference of mvmvif->phy_ctxt. It can be NULL even if we hold the mutex. We can be handling a BT Coex notification while the vif has already been unassigned. This can happen since the BT Coex notification is hanled asynchronuously: we can have started to handle the BT Coex notification trying to acquire the mutex while the unassign flow already got it. The BT Coex notification handling will wait for the mutext. I'll get it later, but then mvmvif->phy_ctxt will be NULL. Panic log: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<f985180d>] iwl_mvm_bt_notif_iterator+0x9d/0x340 [iwlmvm] *pdpt = 0000000000000000 *pde = f000eef300000007 Oops: 0000 [#1] SMP Workqueue: events iwl_mvm_async_handlers_wk [iwlmvm] task: ed719b20 ti: ec03e000 task.ti: ec03e000 EIP: 0060:[<f985180d>] EFLAGS: 00010202 CPU: 2 EIP is at iwl_mvm_bt_notif_iterator+0x9d/0x340 [iwlmvm] EAX: 00000000 EBX: f6d3cb70 ECX: f6d3cb70 EDX: 00000000 ESI: ec03fe40 EDI: efeb8810 EBP: ec03fdf0 ESP: ec03fdac DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 CR0: 80050033 CR2: 00000000 CR3: 01a1a000 CR4: 001407f0 Stack: f743ca80 f744a404 ec03fdcc c10e3952 00003aba f743ca80 00000246 f743ca80 00000246 00000000 00000001 00000000 ebd45ff6 ebd458a4 f6d3c500 ebd45578 ebd44b01 ec03fe18 f99e1bc2 00000002 ebd44bc0 f9851770 00000000 f6d3c500 Call Trace: [<c10e3952>] ? ring_buffer_unlock_commit+0xa2/0xd0 [<f99e1bc2>] __iterate_interfaces+0x82/0x110 [mac80211] [<f9851770>] ? iwl_mvm_bt_coex_reduced_txp+0x140/0x140 [iwlmvm] [<f99e1c6a>] ieee80211_iterate_active_interfaces_atomic+0x1a/0x20 [mac80211] [<f9851427>] iwl_mvm_bt_coex_notif_handle+0x77/0x280 [iwlmvm] [<f9852161>] iwl_mvm_rx_bt_coex_notif_old+0x211/0x220 [iwlmvm] [<f9850b8b>] iwl_mvm_rx_bt_coex_notif+0x19b/0x1b0 [iwlmvm] [<f983944f>] iwl_mvm_async_handlers_wk+0x7f/0xe0 [iwlmvm] Fixes: 123f5156 ("iwlwifi: mvm: BT Coex - add support for TTC / RRC") Signed-off-by:
-
Emmanuel Grumbach authored
commit 540623ca upstream. The commit below didn't update the max_ht_ampdu_exponent for the devices listed in iwl-[1-6]000.c which, in result, became 0 instead of 8K. This reduced the size of the Rx AMPDU from 64K to 8K which had an impact in the Rx throughput. One user reported that because of this, his downstream throughput droppped by a half. Fixes: c064ddf3 ("iwlwifi: change max HT and VHT A-MPDU exponent") Reported-and-tested-by:
Valentin Manea <linux-wireless@mrs.ro> Signed-off-by:
-
Eyal Shapira authored
commit 57bff148 upstream. The check to avoid the shared antenna was passed the wrong antenna parameter. It should have checked whether the antenna of the next column we're considering is allowed and instead it was passed the current antenna. This could lead to a wrong choice of the next column in the rs algorithm and non optimal performance. Fixes: commit 219fb66b ("iwlwifi: mvm: rs - don't use the shared antenna when BT load is high") Signed-off-by:
Eyal Shapira <eyalx.shapira@intel.com> Reviewed-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Jacob Pan authored
commit d474a4d3 upstream. The current driver assumes all RAPL domains within a CPU package have the same energy unit. This is no longer true for HSW server CPUs since DRAM domain has is own fixed energy unit which can be different than the package energy unit enumerated by package power MSR. In fact, the default HSW EP package power unit is 61uJ whereas DRAM domain unit is 15.3uJ. The result is that DRAM power consumption is counted 4x more than real power reported by energy counters, similarly for max_energy_range_uj of DRAM domain. This patch adds domain specific energy unit per cpu type, it allows domain energy unit to override package energy unit if non zero. Please see this document for details. "Intel Xeon Processor E5-1600 and E5-2600 v3 Product Families, Volume 2 of 2. Datasheet, September 2014, Reference Number: 330784-001 " Signed-off-by:
Jacob Pan <jacob.jun.pan@linux.intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Andrei Otcheretianski authored
commit 0f611d28 upstream. Since moving the interface combination checks to mac80211, it's broken because it now only considers interfaces with an assigned channel context, so for example any interface that isn't active can still be up, which is clearly an issue; also, in particular P2P-Device wdevs are an issue since they never have a chanctx. Fix this by counting running interfaces instead the ones with a channel context assigned. Fixes: 73de86a3 ("cfg80211/mac80211: move interface counting for combination check to mac80211") Signed-off-by:
-
Bob Copeland authored
commit d0c22119 upstream. The mesh forwarding path was not checking that data frames were protected when running an encrypted network; add the necessary check. Reported-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
Bob Copeland <me@bobcopeland.com> Signed-off-by:
-
Michal Kazior authored
commit aa75ebc2 upstream. Some APs experience problems when working with U-APSD. Decreasing the probability of that happening by using legacy mode for all ACs but VO isn't enough. Cisco 4410N originally forced us to enable VO by default only because it treated non-VO ACs as legacy. However some APs (notably Netgear R7000) silently reclassify packets to different ACs. Since u-APSD ACs require trigger frames for frame retrieval clients would never see some frames (e.g. ARP responses) or would fetch them accidentally after a long time. It makes little sense to enable u-APSD queues by default because it needs userspace applications to be aware of it to actually take advantage of the possible additional powersavings. Implicitly depending on driver autotrigger frame support doesn't make much sense. Signed-off-by:
Michal Kazior <michal.kazior@tieto.com> Signed-off-by:
-
Johannes Berg authored
commit 496fcc29 upstream. As HT/VHT depend heavily on QoS/WMM, it's not a good idea to let userspace add clients that have HT/VHT but not QoS/WMM. Since it does so in certain cases we've observed (client is using HT IEs but not QoS/WMM) just ignore the HT/VHT info at this point and don't pass it down to the drivers which might unconditionally use it. Signed-off-by:
-
Benjamin Tissoires authored
commit b57a7128 upstream. The board id capability has been added in firmware 7.5. Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Benjamin Tissoires authored
commit ebc80840 upstream. The Fimware 8.1 has a bug in which the extra buttons are only sent when the ExtBit is 1. This should be fixed in a future FW update which should have a bump of the minor version. Signed-off-by:
-
Dmitry Torokhov authored
commit dc5465dc upstream. On the X1 Carbon 3rd gen (with a 2015 broadwell cpu), the physical middle button of the trackstick (attached to the touchpad serio device, of course) seems to get lost. Actually, the touchpads reports 3 extra buttons, which falls in the switch below to the '2' case. Let's handle the case of odd numbers also, so that the middle button finds its way back. Signed-off-by:
-
Benjamin Tissoires authored
commit 02e07492 upstream. Post-2013 Lenovo laptops provide correct min/max dimensions, which are different with the ones currently quirked. According to https://bugzilla.kernel.org/show_bug.cgi?id=91541 the following board ids are assigned in the post-2013 touchpads: t440p/t440s: LEN0036 -> 2964/2962 t540p: LEN0034 -> 2964 Using 2961 as the common minimum makes these 3 laptops OK. We may need to update those values later if other pnp_ids has a lower board_id. Signed-off-by:
-
Daniel Martin authored
commit 5b3089dd upstream. Add a min/max range for board ids to the min/max coordinates quirk. This makes it possible to restrict quirks to specific models based upon their board id. The define ANY_BOARD_ID (0) serves as a wild card. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=91541Signed-off-by:
Daniel Martin <daniel.martin@secunet.com> Acked-by:
-
Daniel Martin authored
commit b05f4d1c upstream. The firmware of the X240 (LEN0035, 2013/12) exposes the same values x [1232..5710], y [1156..4696] as the quirk applies. Signed-off-by:
Daniel Martin <consume.noise@gmail.com> Acked-by:
-
Daniel Martin authored
commit ac097930 upstream. Query the min dimensions even if the check SYN_EXT_CAP_REQUESTS(priv->capabilities) >= 7 fails, but we know that the firmware version 8.1 is safe. With that we don't need quirks for post-2013 models anymore as they expose correct min and max dimensions. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=91541Signed-off-by:
-
Daniel Martin authored
commit 9aff6598 upstream. Logging the dimension values we queried and the values we use from a quirk to overwrite can be helpful for debugging. This partly relates to bug: https://bugzilla.kernel.org/show_bug.cgi?id=91541Signed-off-by:
-
Daniel Martin authored
commit 8b04baba upstream. Split the function synaptics_resolution() into synaptics_resolution() and synaptics_quirks(). synaptics_resolution() will be called before synaptics_quirks() to query dimensions and resolutions before overwriting them with quirks. Signed-off-by:
-
Bart Van Assche authored
commit 75c3d0bf upstream. This patch fixes the incorrect use of __transport_register_session() in tcm_qla2xxx_check_initiator_node_acl() code, that does not perform explicit se_tpg->session_lock when accessing se_tpg->tpg_sess_list to add new se_sess nodes. Given that tcm_qla2xxx_check_initiator_node_acl() is not called with qla_hw->hardware_lock held for all accesses of ->tpg_sess_list, the code should be using transport_register_session() instead. Signed-off-by:
Bart Van Assche <bart.vanassche@sandisk.com> Cc: Giridhar Malavali <giridhar.malavali@qlogic.com> Cc: Quinn Tran <quinn.tran@qlogic.com> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
