- 28 Feb, 2013 40 commits
-
-
Ben Skeggs authored
commit ac8cc241 upstream. A single U encoder table can match multiple DCB entries, whereas the reverse is not true and can lead to us not matching a DCB entry at all, and fail to initialise some encoders. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ben Skeggs authored
commit 8e992c8d upstream. Matches format used by a couple of other vbios tables, useful to have laying around already calculated. Signed-off-by:
-
Ben Skeggs authored
commit f3ed1048 upstream. Signed-off-by:
-
Fabio Baltieri authored
commit 99d17cfa upstream. This patch converts the module to use clk_prepare_enable and clk_disable_unprepare variants as required by common clock framework. Without this the system crash during probe function. Signed-off-by:
Fabio Baltieri <fabio.baltieri@linaro.org> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Ming Lei authored
commit 25736e0c upstream. This patch let glue driver return -EPROBE_DEFER if the transceiver is not readly, so we can support defer probe on musb to fix the below error on 3.7-rc5 if transceiver drivers are built as module: [ 19.052490] unable to find transceiver of type USB2 PHY [ 19.072052] HS USB OTG: no transceiver configured [ 19.076995] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -19 [ 19.089355] musb-hdrc: probe of musb-hdrc.0.auto rejects match -19 [ 19.096771] driver: 'musb-omap2430': driver_bound: bound to device 'musb-omap2430' [ 19.105194] bus: 'platform': really_probe: bound device musb-omap2430 to driver musb-omap2430 [ 19.174407] bus: 'platform': add driver twl4030_usb [ 19.179656] bus: 'platform': driver_probe_device: matched device twl4030_usb with driver twl4030_usb [ 19.202270] bus: 'platform': really_probe: probing driver twl4030_usb with device twl4030_usb [ 19.214172] twl4030_usb twl4030_usb: HW_CONDITIONS 0xc0/192; link 3 [ 19.239624] musb-omap2430 musb-omap2430: musb core is not yet ready [ 19.246765] twl4030_usb twl4030_usb: Initialized TWL4030 USB module [ 19.254516] driver: 'twl4030_usb': driver_bound: bound to device 'twl4030_usb' [ 19.263580] bus: 'platform': really_probe: bound device twl4030_usb to driver twl4030_usb Cc: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by:
Ming Lei <ming.lei@canonical.com> Signed-off-by:
-
Ming Lei authored
commit 681d1e87 upstream. In the fail1~fail5 failure path, pm_runtime_disable() should be called to avoid 'Unbalanced pm_runtime_enable' error in next probe() which may be triggered by defer probe or next 'modprobe musb_hdrc'. Cc: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by:
-
Josh Boyer authored
commit 18e03310 upstream. The current entry in unusual_cypress.h for the Super TOP SATA bridge devices seems to be causing corruption on newer revisions of this device. This has been reported in Arch Linux and Fedora. The original patch was tested on devices with bcdDevice of 1.60, whereas the newer devices report bcdDevice as 2.20. Limit the UNUSUAL_DEV entry to devices less than 2.20. This fixes https://bugzilla.redhat.com/show_bug.cgi?id=909591 The Arch Forum post on this is here: https://bbs.archlinux.org/viewtopic.php?id=152011Reported-by:
Carsten S. <carsteniq@yahoo.com> Tested-by:
Josh Boyer <jwboyer@redhat.com> Signed-off-by:
-
fangxiaozhi authored
commit cd060956 upstream. 1. The idProduct is little endian, so make sure its value to be compatible with the current CPU. Make no break on big endian processors. Signed-off-by:
fangxiaozhi <huananhu@huawei.com> Signed-off-by:
-
Roger Quadros authored
commit 04753523 upstream. The module alias should be "ehci-omap" and not "omap-ehci" to match the platform device name. The omap-ehci module should now autoload correctly. Signed-off-by:
Roger Quadros <rogerq@ti.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Bjørn Mork authored
commit 1f3f6877 upstream. The USB device descriptor of one identity presented by a few Huawei morphing devices have serial functions with class codes 02/02/ff, indicating CDC ACM with a vendor specific protocol. This combination is often used for MSFT RNDIS functions, and the CDC ACM class driver will therefore ignore such functions. The CDC ACM class driver cannot support functions with only 2 endpoints. The underlying serial functions of these modems are also believed to be the same as for alternate device identities already supported by the option driver. Letting the same driver handle these functions independently of the current identity ensures consistent handling and user experience. There is no need to blacklist these devices in the rndis_host driver. Huawei serial functions will either have only 2 endpoints or a CDC ACM functional descriptor with bmCapabilities != 0, making them correctly ignored as "non RNDIS" by that driver. Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Bjørn Mork authored
commit cd565279 upstream. Interface layout: 00 CD-ROM 01 debug COM port 02 AP control port 03 modem 04 usb-ethernet Bus=01 Lev=02 Prnt=02 Port=01 Cnt=02 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0408 ProdID=ea42 Rev= 0.00 S: Manufacturer=Qualcomm, Incorporated S: Product=Qualcomm CDMA Technologies MSM S: SerialNumber=353568051xxxxxx C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=84(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=86(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms Signed-off-by:
-
Bjørn Mork authored
commit f8f0302b upstream. Adding three currently unsupported modems based on information from .inf driver files: Diag VID_1BBB&PID_0052&MI_00 AGPS VID_1BBB&PID_0052&MI_01 VOICE VID_1BBB&PID_0052&MI_02 AT VID_1BBB&PID_0052&MI_03 Modem VID_1BBB&PID_0052&MI_05 wwan VID_1BBB&PID_0052&MI_06 Diag VID_1BBB&PID_00B6&MI_00 AT VID_1BBB&PID_00B6&MI_01 Modem VID_1BBB&PID_00B6&MI_02 wwan VID_1BBB&PID_00B6&MI_03 Diag VID_1BBB&PID_00B7&MI_00 AGPS VID_1BBB&PID_00B7&MI_01 VOICE VID_1BBB&PID_00B7&MI_02 AT VID_1BBB&PID_00B7&MI_03 Modem VID_1BBB&PID_00B7&MI_04 wwan VID_1BBB&PID_00B7&MI_05 Updating the blacklist info for the X060S_X200 and X220_X500D, reserving interfaces for a wwan driver, based on wwan VID_1BBB&PID_0000&MI_04 wwan VID_1BBB&PID_0017&MI_06 Signed-off-by:
-
Maciej Sosnowski authored
commit c419fcfd upstream. When providers get blocked unregister_dca_providers() is called ending up with dca_providers and dca_domain lists emptied. Dca should be prevented from trying to unregister any provider if dca_domain list is found empty. Reported-by:
Jiang Liu <jiang.liu@huawei.com> Tested-by:
Gaohuai Han <hangaohuai@huawei.com> Signed-off-by:
Maciej Sosnowski <maciej.sosnowski@intel.com> Signed-off-by:
Dan Williams <djbw@fb.com> Signed-off-by:
-
Guennadi Liakhovetski authored
commit 7c1119bd upstream. If dmaengine driver's .device_alloc_chan_resources() method returns -ENODEV, dma_request_channel() will decide, that the driver has been removed and will remove the device from its list. To prevent this use ENXIO if a slave lookup fails. Reported-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
Vinod Koul <vinod.koul@linux.intel.com> Signed-off-by:
-
Magnus Damm authored
commit c7886b18 upstream. Adjust the gpio-em.c driver to reconsider the pdata->irq_base variable. Non-DT board code like for instance board-kzm9d.c needs to operate of a static IRQ range for platform devices. So this patch is updating the code to make use of the function irq_domain_add_simple() instead of irq_domain_add_linear(). Fixes a EMEV2 / KZM9D runtime error caused by the following commit: 7385500a gpio/em: convert to linear IRQ domain Signed-off-by:
Magnus Damm <damm@opensource.se> Tested-by:
Simon Horman <horms+renesas@verge.net.au> Reported-by:
-
Roger Quadros authored
commit 428525f9 upstream. This driver does not request any gpios so don't free them. Fixes L3 bus error on multiple modprobe/rmmod of ehci_hcd with ehci-omap in use. Without this patch, EHCI will break on repeated insmod/rmmod of ehci_hcd for all OMAP2+ platforms that use EHCI and set 'phy_reset = true' in usbhs_omap_board_data. i.e. board-3430sdp.c: .phy_reset = true, board-3630sdp.c: .phy_reset = true, board-am3517crane.c: .phy_reset = true, board-am3517evm.c: .phy_reset = true, board-cm-t3517.c: .phy_reset = true, board-cm-t35.c: .phy_reset = true, board-devkit8000.c: .phy_reset = true, board-igep0020.c: .phy_reset = true, board-igep0020.c: .phy_reset = true, board-omap3beagle.c: .phy_reset = true, board-omap3evm.c: .phy_reset = true, board-omap3pandora.c: .phy_reset = true, board-omap3stalker.c: .phy_reset = true, board-omap3touchbook.c: .phy_reset = true, board-omap4panda.c: .phy_reset = false, board-overo.c: .phy_reset = true, board-zoom.c: .phy_reset = true, Signed-off-by:
-
Johannes Berg authored
Commit 5b36ebd8 upstream. In some cases when disconnecting after (or during?) CSA the queues might not recover, and then the only way to recover is reloading the module. Fix this by always unblocking the queue CSA reason when disconnecting. Reported-by:
Jan-Michael Brummer <jan.brummer@tabos.org> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Cong Wang authored
[ Upstream commit da8c8724 ] There are two places to call vlan_set_encap_proto(): vlan_untag() and __pop_vlan_tci(). vlan_untag() assumes skb->data points after mac addr, otherwise the following code vhdr = (struct vlan_hdr *) skb->data; vlan_tci = ntohs(vhdr->h_vlan_TCI); __vlan_hwaccel_put_tag(skb, vlan_tci); skb_pull_rcsum(skb, VLAN_HLEN); won't be correct. But __pop_vlan_tci() assumes points _before_ mac addr. In vlan_set_encap_proto(), it looks for some magic L2 value after mac addr: rawp = skb->data; if (*(unsigned short *) rawp == 0xFFFF) ... Therefore __pop_vlan_tci() is obviously wrong. A quick fix is avoiding using skb->data in vlan_set_encap_proto(), use 'vhdr+1' is always correct in both cases. Signed-off-by:
Cong Wang <amwang@redhat.com> Cc: David S. Miller <davem@davemloft.net> Cc: Jesse Gross <jesse@nicira.com> Acked-by:
Jesse Gross <jesse@nicira.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Mathias Krause authored
[ Upstream commit 6e601a53 ] Userland can send a netlink message requesting SOCK_DIAG_BY_FAMILY with a family greater or equal then AF_MAX -- the array size of sock_diag_handlers[]. The current code does not test for this condition therefore is vulnerable to an out-of-bound access opening doors for a privilege escalation. Signed-off-by:
Mathias Krause <minipli@googlemail.com> Acked-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Kleber Sacilotto de Souza authored
[ Upstream commit 37706996 ] The mlx4_en driver allocates the number of objects for the CPU affinity reverse-map based on the number of rx rings of the device. However, mlx4_assign_eq() calls irq_cpu_rmap_add() as many times as IRQ's are assigned to EQ's, which can be as large as mlx4_dev->caps.comp_pool. If caps.comp_pool is larger than rx_ring_num we will eventually hit the BUG_ON() in cpu_rmap_add(). Fix this problem by allocating space for the maximum number of CPU affinity reverse-map objects we might want to add. Signed-off-by:
Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com> Acked-by:
Amir Vadai <amirv@mellanox.com> Signed-off-by:
-
Kleber Sacilotto de Souza authored
[ Upstream commit 427a9625 ] The memory to hold the network device tx_cq is not being allocated with the correct size in mlx4_en_init_netdev(). It should use MAX_TX_RINGS instead of MAX_RX_RINGS. This can cause problems if the number of tx rings being used is greater than MAX_RX_RINGS. Signed-off-by:
-
Yuchung Cheng authored
[ Upstream commit 1b63edd6 ] In fast open the sender unncessarily reduces the space available for data in SYN by 12 bytes. This is because in the sender incorrectly reserves space for TS option twice in tcp_send_syn_data(): tcp_mtu_to_mss() already accounts for TS option space. But it further reserves MAX_TCP_OPTION_SPACE when computing the payload space. Signed-off-by:
Yuchung Cheng <ycheng@google.com> Acked-by:
-
Li Wei authored
[ Upstream commit 5b052042 ] Now we handle icmp errors in each transport protocol's err_handler, for icmp protocols, that is ping_err. Since this handler only care of those icmp errors triggered by echo request, errors triggered by echo reply(which sent by kernel) are sliently ignored. So wrap ping_err() with icmp_err() to deal with those icmp errors. Signed-off-by:
Li Wei <lw@cn.fujitsu.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 08dcdbf6 ] It looks like its possible to open thousands of TCP IPv6 sessions on a server, all landing in a single slot of TCP hash table. Incoming packets have to lookup sockets in a very long list. We should hash all bits from foreign IPv6 addresses, using a salt and hash mix, not a simple XOR. inet6_ehashfn() can also separately use the ports, instead of xoring them. Reported-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
-
Li Wei authored
[ Upstream commit b531ed61 ] We should get 'type' and 'code' from the outer ICMP header. Signed-off-by:
-
YOSHIFUJI Hideaki authored
[ Upstream commit ecd98837 ] Eric Dumazet wrote: | Some strange crashes happen in rt6_check_expired(), with access | to random addresses. | | At first glance, it looks like the RTF_EXPIRES and | stuff added in commit 1716a961 | (ipv6: fix problem with expired dst cache) | are racy : same dst could be manipulated at the same time | on different cpus. | | At some point, our stack believes rt->dst.from contains a dst pointer, | while its really a jiffie value (as rt->dst.expires shares the same area | of memory) | | rt6_update_expires() should be fixed, or am I missing something ? | | CC Neil because of https://bugzilla.redhat.com/show_bug.cgi?id=892060 Because we do not have any locks for dst_entry, we cannot change essential structure in the entry; e.g., we cannot change reference to other entity. To fix this issue, split 'from' and 'expires' field in dst_entry out of union. Once it is 'from' is assigned in the constructor, keep the reference until the very last stage of the life time of the object. Of course, it is unsafe to change 'from', so make rt6_set_from simple just for fresh entries. Reported-by:
Eric Dumazet <eric.dumazet@gmail.com> Reported-by:
Neil Horman <nhorman@tuxdriver.com> CC: Gao Feng <gaofeng@cn.fujitsu.com> Signed-off-by:
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Reviewed-by:
Steinar H. Gunderson <sesse@google.com> Reviewed-by:
-
Eric Dumazet authored
[ Upstream commit 303c07db ] If a qdisc is installed on a ppp device, its possible to get a lockdep splat under stress, because nested dev_queue_xmit() can lock busylock a second time (on a different device, so its a false positive) Avoid this problem using a distinct lock_class_key for ppp devices. Reported-by:
Yanko Kaneti <yaneti@declera.com> Tested-by:
-
Romain KUNTZ authored
[ Upstream commit 18cf0d07 ] Neighbor is cloned in xfrm6_fill_dst but seems to never be released. Neighbor entry should be released when XFRM6 dst entry is destroyed in xfrm6_dst_destroy, otherwise references may be kept forever on the device pointed by the neighbor entry. I may not have understood all the subtleties of XFRM & dst so I would be happy to receive comments on this patch. Signed-off-by:
Romain Kuntz <r.kuntz@ipflavors.com> Signed-off-by:
-
Ying Xue authored
[ Upstream commit dec34fb0 ] When SOCK_REFCNT_DEBUG is enabled, below build error is met: kernel/sysctl_binary.o: In function `sk_refcnt_debug_release': include/net/sock.h:1025: multiple definition of `sk_refcnt_debug_release' kernel/sysctl.o:include/net/sock.h:1025: first defined here kernel/audit.o: In function `sk_refcnt_debug_release': include/net/sock.h:1025: multiple definition of `sk_refcnt_debug_release' kernel/sysctl.o:include/net/sock.h:1025: first defined here make[1]: *** [kernel/built-in.o] Error 1 make: *** [kernel] Error 2 So we decide to make sk_refcnt_debug_release static to eliminate the error. Signed-off-by:
Ying Xue <ying.xue@windriver.com> Signed-off-by:
-
David Vrabel authored
[ Upstream commit 3e55f8b3 ] If the credit timer is left armed after calling xen_netbk_remove_xenvif(), then it may fire and attempt to schedule the vif which will then oops as vif->netbk == NULL. This may happen both in the fatal error path and during normal disconnection from the front end. The sequencing during shutdown is critical to ensure that: a) vif->netbk doesn't become unexpectedly NULL; and b) the net device/vif is not freed. 1. Mark as unschedulable (netif_carrier_off()). 2. Synchronously cancel the timer. 3. Remove the vif from the schedule list. 4. Remove it from it netback thread group. 5. Wait for vif->refcnt to become 0. Signed-off-by:
David Vrabel <david.vrabel@citrix.com> Acked-by:
Ian Campbell <ian.campbell@citrix.com> Reported-by:
Christopher S. Aker <caker@theshore.net> Signed-off-by:
-
David Vrabel authored
[ Upstream commit 35876b5f ] netbk_count_requests() could detect an error, call netbk_fatal_tx_error() but return 0. The vif may then be used afterwards (e.g., in a call to netbk_tx_error(). Since netbk_fatal_tx_error() could set vif->refcnt to 1, the vif may be freed immediately after the call to netbk_fatal_tx_error() (e.g., if the vif is also removed). Netback thread Xenwatch thread ------------------------------------------- netbk_fatal_tx_err() netback_remove() xenvif_disconnect() ... free_netdev() netbk_tx_err() Oops! Signed-off-by:
Wei Liu <wei.liu2@citrix.com> Signed-off-by:
Jan Beulich <JBeulich@suse.com> Signed-off-by:
-
Bjørn Mork authored
[ Upstream commit f350ca03 ] commit bd329e12 ("net: cdc_ncm: do not bind to NCM compatible MBIM devices") added a test for a CDC MBIM altsetting, implementing the cdc_ncm part of MBIM backward compatibility support. This intentionally made the driver behave differently for CDC NCM devices with 2 alternate settings for the Communication interface, depending on whether or not CONFIG_USB_NET_CDC_MBIM was enabled. This is correct iff alternate setting #1 really *is* a MBIM setting. If not, then NCM probing will use a different altsetting than before, possibly causing probing failures depending on CONFIG_USB_NET_CDC_MBIM. Fix by setting the altsetting back to default after the test, restoring the previous behaviour for non MBIM devices. This bug causes probing of Huawei E3276 devices to fail when the MBIM driver is enabled, because these devices have a second alternate setting with no CDC functional descriptors. Reported-and-tested-by:
Jonathan A. <yo.natan@hotmail.com> Cc: Greg Suarez <gsuarez@smithmicro.com> Cc: Alexey Orishko <alexey.orishko@stericsson.com> Signed-off-by:
-
David Herrmann authored
commit 89bdd0c6 upstream. The buttons of the Wii Remote Nunchuck extension are actually active low. Fix the parser to forward the inverted values. The comment in the function always said "0 == pressed" but the implementation was wrong from the beginning. Reported-by:
Victor Quicksilver <victor.quicksilver@gmail.com> Signed-off-by:
David Herrmann <dh.herrmann@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Balaji T K authored
commit d0123cca upstream. SET_BLOCK_COUNT CMD23 is needed for all access to RPMB partition. If block count is not set by CMD23, all subsequent read/write commands fail as per eMMC specification. So, If the host does not support CMD23, do not expose RPMB partition. Accessing RPMB partition can cause hang / huge delay for hosts which do not support CMD23. Signed-off-by:
Balaji T K <balajitk@ti.com> Reported-and-Tested-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
Chris Ball <cjb@laptop.org> Signed-off-by:
-
Shawn Guo authored
commit ef4d0888 upstream. When commit 95a2482a (mmc: sdhci-esdhc-imx: add basic imx6q usdhc support) works around host version issue on imx6q, it gets the register address fixup "reg ^= 2" lost for imx25/35/51/53 esdhc. Thus, the controller version on these SoCs is wrongly identified as v1 while it's actually v2. Add the address fixup back and take a different approach to correct imx6q host version, so that the host version read gets back to work for all SoCs. Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
-
Dave Airlie authored
commit 054430e7 upstream. Okay so Alan's patch handled the case where there was no registered fbcon, however the other path entered in set_con2fb_map pit. In there we called fbcon_takeover, but we also took the console lock in a couple of places. So push the console lock out to the callers of set_con2fb_map, this means fbmem and switcheroo needed to take the lock around the fb notifier entry points that lead to this. This should fix the efifb regression seen by Maarten. Tested-by:
Maarten Lankhorst <maarten.lankhorst@canonical.com> Tested-by:
Lu Hua <huax.lu@intel.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Takashi Iwai authored
commit e93a9a86 upstream. I've still got lockdep warnings even after Alan's patch, and it seems that yet more band aids are required to paper over similar paths for unbind_con_driver() and unregister_con_driver(). After this hack, lockdep warnings are finally gone. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Cc: Alan Cox <alan@linux.intel.com> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Jiri Kosina <jkosina@suse.cz> Tested-by:
Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Alan Cox authored
commit 50e244cc upstream. Adjust the console layer to allow a take over call where the caller already holds the locks. Make the fb layer lock in order. This is partly a band aid, the fb layer is terminally confused about the locking rules it uses for its notifiers it seems. [akpm@linux-foundation.org: remove stray non-ascii char, tidy comment] [akpm@linux-foundation.org: export do_take_over_console()] [airlied: cleanup another non-ascii char] Signed-off-by:
Alan Cox <alan@linux.intel.com> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Jiri Kosina <jkosina@suse.cz> Tested-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Dave Airlie authored
commit ae128786 upstream. If grub2 loads efifb/vesafb, then when systemd starts it can set the console font on that framebuffer device, however when we then load the native KMS driver, the first thing it does is tear down the generic framebuffer driver. The thing is the generic code is doing the right thing, it frees the font because otherwise it would leak memory. However we can assume that if you are removing the generic firmware driver (vesa/efi/offb), that a new driver *should* be loading soon after, so we effectively leak the font. However the old code left a dangling pointer in vc->vc_font.data and we can now reuse that dangling pointer to load the font into the new driver, now that we aren't freeing it. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=892340Signed-off-by:
-
Anatolij Gustschin authored
commit b2639b5f upstream. Since commit f74de500 "drivers/video: fsl-diu-fb: streamline enabling of interrupts" the interrupt handling in the driver is broken. Enabling diu interrupt causes an interrupt storm and results in system lockup. The cookie for the interrupt handler function passed to request_irq() is wrong (it must be a pointer to the diu struct, and not the address of the pointer to the diu struct). As a result the interrupt handler can not read diu registers and acknowledge the interrupt. Fix cookie arguments for request_irq() and free_irq(). Registering the diu interrupt handler in probe() must happen before install_fb() calls since this function registers framebuffer devices and if fbcon tries to take over framebuffer after registering a frame buffer device, it will call fb_open of the diu driver and enable the interrupts. At this time the diu interrupt handler must be registered already. Disabling the interrupts in fsl_diu_release() must happen only if all other AOIs are closed. Otherwise closing an overlay plane will disable the interrupts even if the primary frame buffer plane is opened. Add an appropriate check in the release function. Signed-off-by:
Anatolij Gustschin <agust@denx.de> Cc: Timur Tabi <timur@tabi.org> Signed-off-by:
-
