- 24 7月, 2014 1 次提交
-
-
由 Minchan Kim 提交于
Sasha reported lockdep warning [1] introduced by [2]. It could be fixed by doing disk revalidation out of the init_lock. It's okay because disk capacity change is protected by init_lock so that revalidate_disk always sees up-to-date value so there is no race. [1] https://lkml.org/lkml/2014/7/3/735 [2] zram: revalidate disk after capacity change Fixes 2e32baea ("zram: revalidate disk after capacity change"). Signed-off-by: NMinchan Kim <minchan@kernel.org> Reported-by: NSasha Levin <sasha.levin@oracle.com> Cc: "Alexander E. Patrakov" <patrakov@gmail.com> Cc: Nitin Gupta <ngupta@vflare.org> Cc: Jerome Marchand <jmarchan@redhat.com> Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> CC: <stable@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 21 7月, 2014 4 次提交
-
-
由 Zoltan Kiss 提交于
Due to this pointer is increased prematurely, the error log contains rubbish. Signed-off-by: NZoltan Kiss <zoltan.kiss@citrix.com> Reported-by: NArmin Zentai <armin.zentai@ezit.hu> Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: xen-devel@lists.xenproject.org Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Zoltan Kiss 提交于
This patch makes this function aware that the first frag and the header might share the same ring slot. That could happen if the first slot is bigger than PKT_PROT_LEN. Due to this the error path might release that slot twice or never, depending on the error scenario. xenvif_idx_release is also removed from xenvif_idx_unmap, and called separately. Signed-off-by: NZoltan Kiss <zoltan.kiss@citrix.com> Reported-by: NArmin Zentai <armin.zentai@ezit.hu> Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: xen-devel@lists.xenproject.org Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Zoltan Kiss 提交于
When the grant operations failed, the skb is freed up eventually, and it tries to release the frags, if there is any. For the main skb nr_frags is set to 0 to avoid this, but on the frag_list it iterates through the frags array, and tries to call put_page on the page pointer which contains garbage at that time. Signed-off-by: NZoltan Kiss <zoltan.kiss@citrix.com> Reported-by: NArmin Zentai <armin.zentai@ezit.hu> Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: xen-devel@lists.xenproject.org Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Zoltan Kiss 提交于
The error handling for skb's with frag_list was completely wrong, it caused double unmap attempts to happen if the error was on the first skb. Move it to the right place in the loop. Signed-off-by: NZoltan Kiss <zoltan.kiss@citrix.com> Reported-by: NArmin Zentai <armin.zentai@ezit.hu> Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: xen-devel@lists.xenproject.org Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 19 7月, 2014 2 次提交
-
-
由 Hannes Frederic Sowa 提交于
The expression entropy_count -= ibytes << (ENTROPY_SHIFT + 3) could actually increase entropy_count if during assignment of the unsigned expression on the RHS (mind the -=) we reduce the value modulo 2^width(int) and assign it to entropy_count. Trinity found this. [ Commit modified by tytso to add an additional safety check for a negative entropy_count -- which should never happen, and to also add an additional paranoia check to prevent overly large count values to be passed into urandom_read(). ] Reported-by: NDave Jones <davej@redhat.com> Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: NTheodore Ts'o <tytso@mit.edu> Cc: stable@vger.kernel.org
-
由 Romain Degez 提交于
Add support of the Promise FastTrak TX8660 SATA HBA in ahci mode by registering the board in the ahci_pci_tbl[]. Note: this HBA also provide a hardware RAID mode when activated in BIOS but specific drivers from the manufacturer are required in this case. Signed-off-by: NRomain Degez <romain.degez@gmail.com> Tested-by: NRomain Degez <romain.degez@gmail.com> Signed-off-by: NTejun Heo <tj@kernel.org> Cc: stable@vger.kernel.org
-
- 18 7月, 2014 7 次提交
-
-
由 Tomasz Figa 提交于
Certain GIC implementation, namely those found on earlier, single cluster, Exynos SoCs, have registers mapped without per-CPU banking, which means that the driver needs to use different offset for each CPU. Currently the driver calculates the offset by multiplying value returned by cpu_logical_map() by CPU offset parsed from DT. This is correct when CPU topology is not specified in DT and aforementioned function returns core ID alone. However when DT contains CPU topology, the function changes to return cluster ID as well, which is non-zero on mentioned SoCs and so breaks the calculation in GIC driver. This patch fixes this by masking out cluster ID in CPU offset calculation so that only core ID is considered. Multi-cluster Exynos SoCs already have banked GIC implementations, so this simple fix should be enough. Reported-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reported-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: NTomasz Figa <t.figa@samsung.com> Fixes: db0d4db2 ("ARM: gic: allow GIC to support non-banked setups") Cc: <stable@vger.kernel.org> # v3.3+ Link: https://lkml.kernel.org/r/1405610624-18722-1-git-send-email-t.figa@samsung.comSigned-off-by: NJason Cooper <jason@lakedaemon.net>
-
由 Dexuan Cui 提交于
We should schedule the 5s "timer work" before starting the data transfer, otherwise, the data transfer code may finish so fast on another virtual cpu that when the code(fcopy_write()) trying to cancel the 5s "timer work" can occasionally fail because the "timer work" may haven't been scheduled yet and as a result the fcopy process will be aborted wrongly by fcopy_work_func() in 5s. Thank Liz Zhang <lizzha@microsoft.com> for the initial investigation on the bug. This addresses https://bugzilla.redhat.com/show_bug.cgi?id=1118123Tested-by: NLiz Zhang <lizzha@microsoft.com> Cc: Haiyang Zhang <haiyangz@microsoft.com> Cc: stable@vger.kernel.org Signed-off-by: NDexuan Cui <decui@microsoft.com> Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Gavin Guo 提交于
When using USB 3.0 pen drive with the [AMD] FCH USB XHCI Controller [1022:7814], the second hotplugging will experience the USB 3.0 pen drive is recognized as high-speed device. After bisecting the kernel, I found the commit number 41e7e056 (USB: Allow USB 3.0 ports to be disabled.) causes the bug. After doing some experiments, the bug can be fixed by avoiding executing the function hub_usb3_port_disable(). Because the port status with [AMD] FCH USB XHCI Controlleris [1022:7814] is already in RxDetect (I tried printing out the port status before setting to Disabled state), it's reasonable to check the port status before really executing hub_usb3_port_disable(). Fixes: 41e7e056 (USB: Allow USB 3.0 ports to be disabled.) Signed-off-by: NGavin Guo <gavin.guo@canonical.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Cc: <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Abbas Raza 提交于
There are 2 methods for ZLP (zero-length packet) generation: 1) In software 2) Automatic generation by device controller 1) is implemented in UDC driver and it attaches ZLP to IN packet if descriptor->size < wLength 2) can be enabled/disabled by setting ZLT bit in the QH When gadget ffs is connected to ubuntu host, the host sends get descriptor request and wLength in setup packet is 255 while the size of descriptor which will be sent by gadget in IN packet is 64 byte. So the composite driver sets req->zero = 1. In UDC driver following code will be executed then if (hwreq->req.zero && hwreq->req.length && (hwreq->req.length % hwep->ep.maxpacket == 0)) add_td_to_list(hwep, hwreq, 0); Case-A: So in case of ubuntu host, UDC driver will attach a ZLP to the IN packet. ubuntu host will request 255 byte in IN request, gadget will send 64 byte with ZLP and host will come to know that there is no more data. But hold on, by default ZLT=0 for endpoint 0 so hardware also tries to automatically generate the ZLP which blocks enumeration for ~6 seconds due to endpoint 0 STALL, NAKs are sent to host for any requests (OUT/PING) Case-B: In case when gadget ffs is connected to Apple device, Apple device sends setup packet with wLength=64. So descriptor->size = 64 and wLength=64 therefore req->zero = 0 and UDC driver will not attach any ZLP to the IN packet. Apple device requests 64 bytes, gets 64 bytes and doesn't further request for IN data. But ZLT=0 by default for endpoint 0 so hardware tries to automatically generate the ZLP which blocks enumeration for ~6 seconds due to endpoint 0 STALL, NAKs are sent to host for any requests (OUT/PING) According to USB2.0 specs: 8.5.3.2 Variable-length Data Stage A control pipe may have a variable-length data phase in which the host requests more data than is contained in the specified data structure. When all of the data structure is returned to the host, the function should indicate that the Data stage is ended by returning a packet that is shorter than the MaxPacketSize for the pipe. If the data structure is an exact multiple of wMaxPacketSize for the pipe, the function will return a zero-length packet to indicate the end of the Data stage. In Case-A mentioned above: If we disable software ZLP generation & ZLT=0 for endpoint 0 OR if software ZLP generation is not disabled but we set ZLT=1 for endpoint 0 then enumeration doesn't block for 6 seconds. In Case-B mentioned above: If we disable software ZLP generation & ZLT=0 for endpoint then enumeration still blocks due to ZLP automatically generated by hardware and host not needing it. But if we keep software ZLP generation enabled but we set ZLT=1 for endpoint 0 then enumeration doesn't block for 6 seconds. So the proper solution for this issue seems to disable automatic ZLP generation by hardware (i.e by setting ZLT=1 for endpoint 0) and let software (UDC driver) handle the ZLP generation based on req->zero field. Cc: stable@vger.kernel.org Signed-off-by: NAbbas Raza <Abbas_Raza@mentor.com> Signed-off-by: NPeter Chen <peter.chen@freescale.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Bjørn Mork 提交于
Huawei's usage of the subclass and protocol fields is not 100% clear to us, but there appears to be a very strict system. A device with the "shared" device ID 12d1:1506 and this NCM function was recently reported (showing only default altsetting): Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 22 iInterface 8 CDC Network Control Model (NCM) ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 06 24 1a 00 01 1f ** UNRECOGNIZED: 0c 24 1b 00 01 00 04 10 14 dc 05 20 ** UNRECOGNIZED: 0d 24 0f 0a 0f 00 00 00 ea 05 03 00 01 ** UNRECOGNIZED: 05 24 06 01 01 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 9 Cc: Enrico Mioso <mrkiko.rs@gmail.com> Signed-off-by: NBjørn Mork <bjorn@mork.no> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Bjørn Mork 提交于
Add two device IDs found in an out-of-tree driver downloadable from Netgear. Signed-off-by: NBjørn Mork <bjorn@mork.no> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Dan Carpenter 提交于
If "newmtu * 2 + 4" is too large then it can cause an integer overflow leading to memory corruption. Eric Dumazet suggests that 65534 is a reasonable upper limit. Btw, "newmtu" is not allowed to be a negative number because of the check in dev_set_mtu(), so that's ok. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 17 7月, 2014 18 次提交
-
-
由 Mario Kleiner 提交于
Need to protect mmio flip programming by event lock as well. Need to also first enable pflip irq, then mmio program, otherwise a flip completion may get unnoticed in the vblank of actual completion if the flip is programmed, but radeon_flip_work_func gets preempted immediately after mmio programming and before vblank. In that case the vblank irq handler wouldn't run radeon_crtc_handle_vblank() with the completion check routine, miss the completed flip, and only notice one vblank after actual completion, causing a false/delayed report of flip completion. Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Mario Kleiner 提交于
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Mario Kleiner 提交于
Not needed anymore, as it is already unreffed within radeon_flip_work_func() after its only use. Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Michel Dänzer 提交于
Otherwise the DRM core and userspace will be confused about which BO the CRTC is scanning out. Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Michel Dänzer 提交于
As well as enabling the vblank interrupt. These shouldn't take any significant amount of time, but at least pinning the BO has actually been seen to fail in practice before, in which case we need to let userspace know about it. Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Mario Kleiner 提交于
Since 3.16-rc1 we have this new failure: When the userspace XOrg ddx schedules vblank events to trigger deferred kms-pageflips, e.g., via the OML_sync_control extension call glXSwapBuffersMscOML(), or if a glXSwapBuffers() is called immediately after completion of a previous swapbuffers call, e.g., in a tight rendering loop with minimal rendering, it happens frequently that the pageflip ioctl() is executed within the same vblank in which a previous kms-pageflip completed, or - for deferred swaps - always one vblank earlier than requested by the client app. This causes premature pageflips and detection of failure by the ddx, e.g., XOrg log warnings like... "(WW) RADEON(1): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 201025 < target_msc 201026" ... and error/invalid return values of glXWaitForSbcOML() and Intel_swap_events extension. Reason is the new way in which kms-pageflips are programmed since 3.16. This commit changes the time window in which the hw can execute pending programmed pageflips. Before, a pending flip would get executed anywhere within the vblank interval. Now a pending flip only gets executed at the leading edge of vblank (start of front porch), making sure that a invocation of the pageflip ioctl() within a given vblank interval will only lead to pageflip completion in the following vblank. Tested to death on a DCE-4 card. Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
If the value in the scratch register is 0, set it to the max level. This fixes an issue where the console fb blanking code calls back into the backlight driver on unblank and then sets the backlight level to 0 after the driver has already set the mode and enabled the backlight. bugs: https://bugs.freedesktop.org/show_bug.cgi?id=81382 https://bugs.freedesktop.org/show_bug.cgi?id=70207Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Tested-by: NDavid Heidelberger <david.heidelberger@ixit.cz> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
In some cases we fetch the edid in the detect() callback in order to determine what sort of monitor is connected. If that happens, don't fetch the edid again in the get_modes() callback or we will leak the edid. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Suravee Suthikulpanit 提交于
Commit 3ab72f91 "dt-bindings: add GIC-400 binding" added the "arm,gic-400" compatible string, but the corresponding IRQCHIP_DECLARE was never added to the gic driver. Therefore add the missing irqchip declaration for it. Signed-off-by: NSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Removed additional empty line and adapted commit message to mark it as fixing an issue. Signed-off-by: NHeiko Stuebner <heiko@sntech.de> Acked-by: NWill Deacon <will.deacon@arm.com> Fixes: 3ab72f91 ("dt-bindings: add GIC-400 binding") Cc: <stable@vger.kernel.org> # v3.14+ Link: https://lkml.kernel.org/r/2621565.f5eISveXXJ@diegoSigned-off-by: NJason Cooper <jason@lakedaemon.net>
-
由 Andrey Utkin 提交于
[linux-3.16-rc5/drivers/ata/pata_ep93xx.c:929]: (style) Checking if unsigned variable 'irq' is less than zero. Source code is irq = platform_get_irq(pdev, 0); if (irq < 0) { but unsigned int irq; $ fgrep platform_get_irq `find . -name \*.h -print` ./include/linux/platform_device.h:extern int platform_get_irq(struct platform_device *, unsigned int); Now using "int" type instead of "unsigned int" for "irq" variable. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=80401Reported-by: NDavid Binderman <dcb314@hotmail.com> Signed-off-by: NAndrey Utkin <andrey.krieger.utkin@gmail.com> Signed-off-by: NTejun Heo <tj@kernel.org>
-
由 Viresh Kumar 提交于
This is only relevant to implementations with multiple clusters, where clusters have separate clock lines but all CPUs within a cluster share it. Consider a dual cluster platform with 2 cores per cluster. During suspend we start hot unplugging CPUs in order 1 to 3. When CPU2 is removed, policy->kobj would be moved to CPU3 and when CPU3 goes down we wouldn't free policy or its kobj as we want to retain permissions/values/etc. Now on resume, we will get CPU2 before CPU3 and will call __cpufreq_add_dev(). We will recover the old policy and update policy->cpu from 3 to 2 from update_policy_cpu(). But the kobj is still tied to CPU3 and isn't moved to CPU2. We wouldn't create a link for CPU2, but would try that for CPU3 while bringing it online. Which will report errors as CPU3 already has kobj assigned to it. This bug got introduced with commit 42f921a6, which overlooked this scenario. To fix this, lets move kobj to the new policy->cpu while bringing first CPU of a cluster back. Also do a WARN_ON() if kobject_move failed, as we would reach here only for the first CPU of a non-boot cluster. And we can't recover from this situation, if kobject_move() fails. Fixes: 42f921a6 (cpufreq: remove sysfs files for CPUs which failed to come back after resume) Cc: 3.13+ <stable@vger.kernel.org> # 3.13+ Reported-and-tested-by: NBu Yitian <ybu@qti.qualcomm.com> Reported-by: NSaravana Kannan <skannan@codeaurora.org> Reviewed-by: NSrivatsa S. Bhat <srivatsa@mit.edu> Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Christoph Schulz 提交于
Commit 568f194e ("net: ppp: use sk_unattached_filter api") inadvertently changed the logic when setting PPP pass and active filters. This applies to both the generic PPP subsystem implemented by drivers/net/ppp/ppp_generic.c and the ISDN PPP subsystem implemented by drivers/isdn/i4l/isdn_ppp.c. The original code in ppp_ioctl() (or isdn_ppp_ioctl(), resp.) handling PPPIOCSPASS and PPPIOCSACTIVE allowed to remove a pass/active filter previously set by using a filter of length zero. However, with the new code this is not possible anymore as this case is not explicitly checked for, which leads to passing NULL as a filter to sk_unattached_filter_create(). This results in returning EINVAL to the caller. Additionally, the variables ppp->pass_filter and ppp->active_filter (or is->pass_filter and is->active_filter, resp.) are not reset to NULL, although the filters they point to may have been destroyed by sk_unattached_filter_destroy(), so in this EINVAL case dangling pointers are left behind (provided the pointers were previously non-NULL). This patch corrects both problems by checking whether the filter passed is empty or non-empty, and prevents sk_unattached_filter_create() from being called in the first case. Moreover, the pointers are always reset to NULL as soon as sk_unattached_filter_destroy() returns. Signed-off-by: NChristoph Schulz <develop@kristov.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Amir Vadai 提交于
Fix a regression introduced by commit 35f6f453 ("net/mlx4_en: Don't use irq_affinity_notifier to track changes in IRQ affinity map"). When core is started in legacy EQ's (number of IRQ's < rx rings), cq->irq_desc was NULL. This caused a kernel crash under heavy traffic - when having more than rx NAPI budget completions. Fixed to have it set for both EQ modes. Signed-off-by: NAmir Vadai <amirv@mellanox.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Or Gerlitz 提交于
In commit f360d88a, we advertise blocking multicast loopback to both kernel and userspace consumers, but don't allow kernel consumers (e.g IPoIB) to use it with their UD QPs. Fix that. Fixes: f360d88a ("IB/mlx5: Add block multicast loopback support") Reported-by: NHaggai Eran <haggaie@mellanox.com> Signed-off-by: NEli Cohen <eli@mellanox.com> Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com> Signed-off-by: NRoland Dreier <roland@purestorage.com>
-
由 Sowmini Varadhan 提交于
Nothing cleans up the objects created by vnet_new(), they are completely leaked. vnet_exit(), after doing the vio_unregister_driver() to clean up ports, should call a helper function that iterates over vnet_list and cleans up those objects. This includes unregister_netdevice() as well as free_netdev(). Signed-off-by: NSowmini Varadhan <sowmini.varadhan@oracle.com> Acked-by: NDave Kleikamp <dave.kleikamp@oracle.com> Reviewed-by: NKarl Volz <karl.volz@oracle.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Michel Dänzer 提交于
The ethernet port on my ASUS A88X Pro mainboard stopped working several times a day, with messages like these in dmesg: AMD-Vi: Event logged [IO_PAGE_FAULT device=05:00.0 domain=0x001e address=0x0000000000003000 flags=0x0050] Searching the web for these messages led me to similar reports about different hardware supported by r8169, and eventually to commits 3ced8c95 ('r8169: enforce RX_MULTI_EN for the 8168f.') and eb2dc35d ('r8169: RxConfig hack for the 8168evl'). So I tried this change, and it fixes the problem for me. Signed-off-by: NMichel Dänzer <michel@daenzer.net> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Guenter Roeck 提交于
Temperature limit registers are signed. Limits therefore need to be clamped to (-128, 127) degrees C and not to (0, 255) degrees C. Without this fix, writing a limit of 128 degrees C sets the actual limit to -128 degrees C. Signed-off-by: NGuenter Roeck <linux@roeck-us.net> Cc: stable@vger.kernel.org Reviewed-by: NAxel Lin <axel.lin@ingics.com>
-
由 Jason Wang 提交于
Return IRQ_NONE if it was not our irq. This is necessary for the case when qxl is sharing irq line with a device A in a crash kernel. If qxl is initialized before A and A's irq was raised during this gap, returning IRQ_HANDLED in this case will cause this irq to be raised again after EOI since kernel think it was handled but in fact it was not. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: NJason Wang <jasowang@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 16 7月, 2014 8 次提交
-
-
由 Viresh Kumar 提交于
OPPs can be populated statically, via DT, or added at run time with dev_pm_opp_add(). While this driver handles the first case correctly, it would fail to populate OPPs added at runtime. Because call to of_init_opp_table() would fail as there are no OPPs in DT and probe will return early. To fix this, remove error checking and call dev_pm_opp_init_cpufreq_table() unconditionally. Update bindings as well. Suggested-by: NStephen Boyd <sboyd@codeaurora.org> Tested-by: NStephen Boyd <sboyd@codeaurora.org> Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Quentin Armitage 提交于
Commit ff1f0018 ("drivers: Enable building of Kirkwood drivers for mach-mvebu") added Kirkwood into mach-mvebu, adding MACH_KIRKWOOD to ARCH_KIRKWOOD in the KConfig files. The change for ARM_KIRKWOOD_CPUFREQ replaced ARCH_KIRKWOOD with MACH_KIRKWOOD, whereas all the other changes were ARCH_KIRKWOOD || MACH_KIRKWOOD. As a consequence of this change, the cpufreq driver is no longer enabled for ARCH_KIRKWOOD. This patch reinstates ARM_KIRKWOOD_CPUFREQ for ARCH_KIRKWOOD. Signed-off-by: NQuentin Armitage <quentin@armitage.org.uk> Acked-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Nicolas Del Piano 提交于
PM_OPP is a library used by several of the existing cpufreq drivers. ARM IMX6Q cpufreq driver uses this library for its functionality. Thus, it should be selected in Kconfig. Reported-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: NNicolas Del Piano <ndel314@gmail.com> Acked-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Linus Walleij 提交于
The Compaq iPAQ h3600 also has the K4S281632b-1H memory type. Verified by prying apart a broken board. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Acked-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Hans de Goede 提交于
As reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1025690 This is yet another model which needs this quirk. Link: https://bugzilla.redhat.com/show_bug.cgi?id=1025690Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Ingo Tuchscherer 提交于
Improve device probing process for zcrypt adapters to transmit service request during registration process. Signed-off-by: NIngo Tuchscherer <ingo.tuchscherer@de.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
由 Martin Schwidefsky 提交于
The size detection for 3270 terminals with the read-partition command is broken. The raw3270_reset_device_cb function clears the init_data array, but if raw3270_writesf_readpart has been called the read-partition command is queued which needs the init_data array. In this case the size detection will fail and the invalid command does funny things to the terminal. Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
由 Brian Norris 提交于
The return value from 'ubi_io_read_ec_hdr()' was stored in 'err', not in 'ret'. This fix makes sure Fastmap-enabled UBI does not miss bit-flip while reading EC headers, events and scrubs the affected PEBs. This issue was reported by Coverity Scan. Artem: improved the commit message. Signed-off-by: NBrian Norris <computersforpeace@gmail.com> Acked-by: NRichard Weinberger <richard@nod.at> Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
-