- 27 Sep, 2013 40 commits
-
-
Aravind Gopalakrishnan authored
commit 7d64ac64 upstream. F15h, models 0x30 and later don't have a GART. Note that. Also check CPUID leaf 0x80000006 for L3 prescence because there are models which don't sport an L3 cache. Signed-off-by:
Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com> [ Boris: rewrite commit message, cleanup comments. ] Signed-off-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Aravind Gopalakrishnan authored
commit 6bdaa63c upstream. Add PCI device IDs for AMD F15h, model 30h. They will be used in amd_nb.c and amd64_edac.c Signed-off-by:
-
Al Viro authored
commit bd1c149a upstream. For performance reasons, when SMAP is in use, SMAP is left open for an entire put_user_try { ... } put_user_catch(); block, however, calling __put_user() in the middle of that block will close SMAP as the STAC..CLAC constructs intentionally do not nest. Furthermore, using __put_user() rather than put_user_ex() here is bad for performance. Thus, introduce new [compat_]save_altstack_ex() helpers that replace __[compat_]save_altstack() for x86, being currently the only architecture which supports put_user_try { ... } put_user_catch(). Reported-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
H. Peter Anvin authored
commit 7263dda4 upstream. Add SMAP annotations to csum_partial_copy_to/from_user(). These functions legitimately access user space and thus need to set the AC flag. TODO: add explicit checks that the side with the kernel space pointer really points into kernel space. Signed-off-by:
-
Steffen Trumtrar authored
commit 9f6f0afb upstream. The MC13783 Chip Errata, Rev. 4 says, that depending on SPI clock and main audio clock speed, the Audio Codec or Stereo DAC do sometimes not start when programmed to do so. This is due to an internal clock timing issue related to the loading of the SPI bits into the audio block. On an i.MX27 based system, this issue lead to switched audio channels under certain circumstances: RTC + Touch + Audio are used and loaded at startup. The mentioned workaround of writing registers 40 and 41 two times is implemented here. Signed-off-by:
Steffen Trumtrar <s.trumtrar@pengutronix.de> Signed-off-by:
Mark Brown <broonie@linaro.org> Signed-off-by:
-
Mike Dyer authored
commit 85fa532b upstream. Bit 9 of PLL2,3 and 4 is reserved as '0'. The 24bit fractional part should be split across each register in 8bit chunks. Signed-off-by:
Mike Dyer <mike.dyer@md-soft.co.uk> Signed-off-by:
-
Tejun Heo authored
commit c34ac00c upstream. list_first_or_null() should test whether the list is empty and return pointer to the first entry if not in a RCU safe manner. It's broken in several ways. * It compares __kernel @__ptr with __rcu @__next triggering the following sparse warning. net/core/dev.c:4331:17: error: incompatible types in comparison expression (different address spaces) * It doesn't perform rcu_dereference*() and computes the entry address using container_of() directly from the __rcu pointer which is inconsitent with other rculist interface. As a result, all three in-kernel users - net/core/dev.c, macvlan, cgroup - are buggy. They dereference the pointer w/o going through read barrier. * While ->next dereference passes through list_next_rcu(), the compiler is still free to fetch ->next more than once and thus nullify the "__ptr != __next" condition check. Fix it by making list_first_or_null_rcu() dereference ->next directly using ACCESS_ONCE() and then use list_entry_rcu() on it like other rculist accessors. v2: Paul pointed out that the compiler may fetch the pointer more than once nullifying the condition check. ACCESS_ONCE() added on ->next dereference. v3: Restored () around macro param which was accidentally removed. Spotted by Paul. Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by:
Fengguang Wu <fengguang.wu@intel.com> Cc: Dipankar Sarma <dipankar@in.ibm.com> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Li Zefan <lizefan@huawei.com> Cc: Patrick McHardy <kaber@trash.net> Signed-off-by:
Paul E. McKenney <paulmck@linux.vnet.ibm.com> Reviewed-by:
Josh Triplett <josh@joshtriplett.org> Signed-off-by:
-
Lan Tianyu authored
commit 98a4f1ff upstream. The pm qos NO_POWER_OFF flag is checked twice during usb device suspend to see if the usb port power off condition is met. This is redundant and also will prevent the port from being powered off if the NO_POWER_OFF flag is changed to 1 from 0 after the device was already suspended. More detail in the following link. http://marc.info/?l=linux-usb&m=136543949130865&w=2 This patch should be backported to kernels as old as 3.7, that contain the commit f7ac7787 "usb/acpi: Use ACPI methods to power off ports." Signed-off-by:
Lan Tianyu <tianyu.lan@intel.com> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Alan Stern authored
commit aa5ceae2 upstream. The hub driver's usb_port_suspend() routine doesn't handle errors related to Link Power Management properly. It always returns failure, it doesn't try to clean up the wakeup setting, (in the case of system sleep) it doesn't try to go ahead with the port suspend regardless, and it doesn't try to apply the new power-off mechanism. This patch fixes these problems. Note: Sarah fixed this patch to apply against 3.11, since the original commit (4fae6f0f "USB: handle LPM errors during device suspend correctly") called usb_disable_remote_wakeup, which won't be added until 3.12. This patch should be backported to kernels as old as 3.5, that contain the commit 8306095f "USB: Disable USB 3.0 LPM in critical sections.". There will be merge conflicts, since LTM wasn't added until 3.6. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Hans de Goede authored
commit b4f17a48 upstream. While reading the config parsing code I noticed this check is missing, without this check config->desc.wTotalLength can end up with a value larger then the dev->rawdescriptors length for the config, and when userspace then tries to get the rawdescriptors bad things may happen. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Alan Stern authored
commit 9d892429 upstream. This patch fixes a build error that occurs when CONFIG_PM is enabled and CONFIG_PM_SLEEP isn't: >> drivers/usb/host/ohci-pci.c:294:10: error: 'usb_hcd_pci_pm_ops' undeclared here (not in a function) .pm = &usb_hcd_pci_pm_ops Since the usb_hcd_pci_pm_ops structure is defined and used when CONFIG_PM is enabled, its declaration should not be protected by CONFIG_PM_SLEEP. Signed-off-by:
-
Sarah Sharp authored
commit d49dad3e upstream. Userspace can tell the kernel to power off any USB port, including ones that are visible and connectible to users. When an attached USB device goes into suspend, the port will be powered off if the pm_qos_no_port_poweroff file for its port is set to 0, the device does not have remote wakeup enabled, and the device is marked as persistent. If the user disconnects the USB device while the port is powered off, the current code does not handle that properly. If you disconnect a device, and then run `lsusb -v -s` for the device, the device disconnect does not get handled by the USB core. The runtime resume of the port fails, because hub_port_debounce_be_connected() returns -ETIMEDOUT. This means the port resume fails and khubd doesn't handle the USB device disconnect. This leaves the device listed in lsusb, and the port's runtime_status will be permanently marked as "error". Fix this by ignoring the return value of hub_port_debounce_be_connected. Users can disconnect USB devices while the ports are powered off, and we must be able to handle that. This patch should be backported to kernels as old as 3.9, that contain the commit ad493e5e "usb: add usb port auto power off mechanism" Signed-off-by:
-
Laurent Pinchart authored
commit ebe864a6 upstream. The conversion to videobuf2 failed to check the return value of vb2_qbuf(). Fix it. Reported-by:
Michael Grzeschik <mgr@pengutronix.de> Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-By:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Oliver Neukum authored
commit 6dd433e6 upstream. Both could want to submit the same URB. Some checks of the flag intended to prevent that were missing. Signed-off-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
Daniel Mack authored
commit f375fc52 upstream. Commit 7e8d5cd9 ("USB: Add EHCI support for MX27 and MX31 based boards") introduced code that could potentially lead to a NULL pointer dereference on driver removal. Fix this by checking for the value of pdata before dereferencing it. Signed-off-by:
Daniel Mack <zonque@gmail.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Johan Hovold authored
commit 3b716caf upstream. Fix endianess bugs in parallel-port code which caused corrupt control-requests to be issued on big-endian machines. Reported-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
Dan Carpenter authored
commit d0bd9a41 upstream. The write_parport_reg_nonblock() function shouldn't sleep because it's called with spinlocks held. Signed-off-by:
-
Mika Westerberg authored
commit af65cfe9 upstream. Intel LPSS devices that are enumerated from ACPI have both MMIO and IRQ resources returned in their _CRS method. However, Apple Macbook Air with Haswell has LPSS devices enumerated from PCI bus instead and _CRS method returns only an interrupt number (but the device has _HID set that causes the scan handler to match it). The current ACPI / LPSS code sets pdata->dev_desc only when MMIO resource is found for the device and in case of Macbook Air it is never found. That leads to a NULL pointer dereference in register_device_clock(). Correct this by always setting the pdata->dev_desc. Reported-and-tested-by:
Imre Kaloz <kaloz@openwrt.org> Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Marek Vasut authored
commit 2a961d09 upstream. The removed check in the read_raw implementation was always true, therefore remove it. This also fixes a bug, by closely inspecting the code, one can notice the iio_validate_scan_mask_onehot() will always return 1 and therefore the subsequent condition will always succeed, therefore making the mxs_lradc_read_raw() function always return -EINVAL; . Signed-off-by:
Marek Vasut <marex@denx.de> Tested-by:
Otavio Salvador <otavio@ossystems.com.br> Acked-by:
Hector Palacios <hector.palacios@digi.com> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Marek Vasut authored
commit e1b1fa66 upstream. The struct iio_dev .trig field is to be used only by the IIO core, the driver shall not fill this field. This fixes ugly crash when the driver is compiled as a module and the module is rmmod'd. Signed-off-by:
-
Dan Carpenter authored
commit 2c4283ca upstream. In dt282x_ai_insn_read() we call this macro like: wait_for(!mux_busy(), comedi_error(dev, "timeout\n"); return -ETIME;); Because the if statement doesn't have curly braces it means we always return -ETIME and the function never succeeds. Signed-off-by:
Ian Abbott <abbotti@mev.co.uk> Signed-off-by:
-
Andy Lutomirski authored
commit d661684c upstream. This is a security bug. The follow-up will fix nsproxy to discourage this type of issue from happening again. Signed-off-by:
Andy Lutomirski <luto@amacapital.net> Reviewed-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Alan Stern authored
commit 69820e01 upstream. Since ohci-hcd supports runtime PM, the .pm field in its pci_driver structure should be protected by CONFIG_PM rather than CONFIG_PM_SLEEP. Without this change, OHCI controllers won't do runtime suspend if system suspend or hibernation isn't enabled. Signed-off-by:
-
Pavel Shilovsky authored
commit 933d4b36 upstream. If a server sends a lease break to a connection that doesn't have opens with a lease key specified in the server response, we can't find an open file to send an ack. Fix this by walking through all connections we have. Signed-off-by:
Pavel Shilovsky <pshilovsky@samba.org> Signed-off-by:
Steve French <smfrench@gmail.com> Signed-off-by:
-
Pavel Shilovsky authored
commit 1a05096d upstream. This happens when we receive a lease break from a server, then find an appropriate lease key in opened files and schedule the oplock_break slow work. lw pointer isn't freed in this case. Signed-off-by:
-
Jeff Layton authored
commit 73e216a8 upstream. Oleksii reported that he had seen an oops similar to this: BUG: unable to handle kernel NULL pointer dereference at 0000000000000088 IP: [<ffffffff814dcc13>] sock_sendmsg+0x93/0xd0 PGD 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: ipt_MASQUERADE xt_REDIRECT xt_tcpudp iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables carl9170 ath usb_storage f2fs nfnetlink_log nfnetlink md4 cifs dns_resolver hid_generic usbhid hid af_packet uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev rfcomm btusb bnep bluetooth qmi_wwan qcserial cdc_wdm usb_wwan usbnet usbserial mii snd_hda_codec_hdmi snd_hda_codec_realtek iwldvm mac80211 coretemp intel_powerclamp kvm_intel kvm iwlwifi snd_hda_intel cfg80211 snd_hda_codec xhci_hcd e1000e ehci_pci snd_hwdep sdhci_pci snd_pcm ehci_hcd microcode psmouse sdhci thinkpad_acpi mmc_core i2c_i801 pcspkr usbcore hwmon snd_timer snd_page_alloc snd ptp rfkill pps_core soundcore evdev usb_common vboxnetflt(O) vboxdrv(O)Oops#2 Part8 loop tun binfmt_misc fuse msr acpi_call(O) ipv6 autofs4 CPU: 0 PID: 21612 Comm: kworker/0:1 Tainted: G W O 3.10.1SIGN #28 Hardware name: LENOVO 2306CTO/2306CTO, BIOS G2ET92WW (2.52 ) 02/22/2013 Workqueue: cifsiod cifs_echo_request [cifs] task: ffff8801e1f416f0 ti: ffff880148744000 task.ti: ffff880148744000 RIP: 0010:[<ffffffff814dcc13>] [<ffffffff814dcc13>] sock_sendmsg+0x93/0xd0 RSP: 0000:ffff880148745b00 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff880148745b78 RCX: 0000000000000048 RDX: ffff880148745c90 RSI: ffff880181864a00 RDI: ffff880148745b78 RBP: ffff880148745c48 R08: 0000000000000048 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff880181864a00 R13: ffff880148745c90 R14: 0000000000000048 R15: 0000000000000048 FS: 0000000000000000(0000) GS:ffff88021e200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000088 CR3: 000000020c42c000 CR4: 00000000001407b0 Oops#2 Part7 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Stack: ffff880148745b30 ffffffff810c4af9 0000004848745b30 ffff880181864a00 ffffffff81ffbc40 0000000000000000 ffff880148745c90 ffffffff810a5aab ffff880148745bc0 ffffffff81ffbc40 ffff880148745b60 ffffffff815a9fb8 Call Trace: [<ffffffff810c4af9>] ? finish_task_switch+0x49/0xe0 [<ffffffff810a5aab>] ? lock_timer_base.isra.36+0x2b/0x50 [<ffffffff815a9fb8>] ? _raw_spin_unlock_irqrestore+0x18/0x40 [<ffffffff810a673f>] ? try_to_del_timer_sync+0x4f/0x70 [<ffffffff815aa38f>] ? _raw_spin_unlock_bh+0x1f/0x30 [<ffffffff814dcc87>] kernel_sendmsg+0x37/0x50 [<ffffffffa081a0e0>] smb_send_kvec+0xd0/0x1d0 [cifs] [<ffffffffa081a263>] smb_send_rqst+0x83/0x1f0 [cifs] [<ffffffffa081ab6c>] cifs_call_async+0xec/0x1b0 [cifs] [<ffffffffa08245e0>] ? free_rsp_buf+0x40/0x40 [cifs] Oops#2 Part6 [<ffffffffa082606e>] SMB2_echo+0x8e/0xb0 [cifs] [<ffffffffa0808789>] cifs_echo_request+0x79/0xa0 [cifs] [<ffffffff810b45b3>] process_one_work+0x173/0x4a0 [<ffffffff810b52a1>] worker_thread+0x121/0x3a0 [<ffffffff810b5180>] ? manage_workers.isra.27+0x2b0/0x2b0 [<ffffffff810bae00>] kthread+0xc0/0xd0 [<ffffffff810bad40>] ? kthread_create_on_node+0x120/0x120 [<ffffffff815b199c>] ret_from_fork+0x7c/0xb0 [<ffffffff810bad40>] ? kthread_create_on_node+0x120/0x120 Code: 84 24 b8 00 00 00 4c 89 f1 4c 89 ea 4c 89 e6 48 89 df 4c 89 60 18 48 c7 40 28 00 00 00 00 4c 89 68 30 44 89 70 14 49 8b 44 24 28 <ff> 90 88 00 00 00 3d ef fd ff ff 74 10 48 8d 65 e0 5b 41 5c 41 RIP [<ffffffff814dcc13>] sock_sendmsg+0x93/0xd0 RSP <ffff880148745b00> CR2: 0000000000000088 The client was in the middle of trying to send a frame when the server->ssocket pointer got zeroed out. In most places, that we access that pointer, the srv_mutex is held. There's only one spot that I see that the server->ssocket pointer gets set and the srv_mutex isn't held. This patch corrects that. The upstream bug report was here: https://bugzilla.kernel.org/show_bug.cgi?id=60557Reported-by:
Oleksii Shevchuk <alxchk@gmail.com> Signed-off-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
-
Oleg Nesterov authored
commit 03e12617 upstream. Starting from v3.10 (probably commit f91e2590: "tty: Signal foreground group processes in hangup") disassociate_ctty() sends SIGCONT if tty && on_exit. This breaks LSB test-suite, in particular test8 in _exit.c and test40 in sigcon5.c. Put the "!on_exit" check back to restore the old behaviour. Review by Peter Hurley: "Yes, this regression was introduced by me in that commit. The effect of the regression is that ptys will receive a SIGCONT when, in similar circumstances, ttys would not. The fact that two test vectors accidentally tripped over this regression suggests that some other apps may as well. Thanks for catching this" Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Reported-by:
Karel Srot <ksrot@redhat.com> Reviewed-by:
Peter Hurley <peter@hurleysoftware.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Felipe Balbi authored
commit b0d7ffd4 upstream. We cannot request an IRQ with spinlocks held as that would trigger a sleeping inside spinlock warning. Reported-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Shawn Nematbakhsh authored
commit c8476fb8 upstream. If a USB controller with XHCI_RESET_ON_RESUME goes to runtime suspend, a reset will be performed upon runtime resume. Any previously suspended devices attached to the controller will be re-enumerated at this time. This will cause problems, for example, if an open system call on the device triggered the resume (the open call will fail). Note that this change is only relevant when persist_enabled is not set for USB devices. This patch should be backported to kernels as old as 3.0, that contain the commit c877b3b2 "xhci: Add reset on resume quirk for asrock p67 host". Signed-off-by:
Shawn Nematbakhsh <shawnn@chromium.org> Signed-off-by:
-
Sarah Sharp authored
commit 52fb6125 upstream. The xHCI platform driver calls into usb_add_hcd to register the irq for its platform device. It does not want the xHCI generic driver to register an interrupt for it at all. The original code did that by setting the XHCI_BROKEN_MSI quirk, which tells the xHCI driver to not enable MSI or MSI-X for a PCI host. Unfortunately, if CONFIG_PCI is enabled, and CONFIG_USB_DW3 is enabled, the xHCI generic driver will attempt to register a legacy PCI interrupt for the xHCI platform device in xhci_try_enable_msi(). This will result in a bogus irq being registered, since the underlying device is a platform_device, not a pci_device, and thus the pci_device->irq pointer will be bogus. Add a new quirk, XHCI_PLAT, so that the xHCI generic driver can distinguish between a PCI device that can't handle MSI or MSI-X, and a platform device that should not have its interrupts touched at all. This quirk may be useful in the future, in case other corner cases like this arise. This patch should be backported to kernels as old as 3.9, that contain the commit 00eed9c8 "USB: xhci: correctly enable interrupts". Signed-off-by:
Yu Y Wang <yu.y.wang@intel.com> Tested-by:
-
Paul Mackerras authored
commit 7bfa9ad5 upstream. Commit 8e44ddc3 ("powerpc/kvm/book3s: Add support for H_IPOLL and H_XIRR_X in XICS emulation") added a call to get_tb() but didn't include the header that defines it, and on some configs this means book3s_xics.c fails to compile: arch/powerpc/kvm/book3s_xics.c: In function ‘kvmppc_xics_hcall’: arch/powerpc/kvm/book3s_xics.c:812:3: error: implicit declaration of function ‘get_tb’ [-Werror=implicit-function-declaration] Signed-off-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
Alexander Graf <agraf@suse.de> Signed-off-by:
-
Peter Maydell authored
commit 99f2b130 upstream. The SMAP register offsets in the versatile PCI controller code were all off by four. (This didn't have any observable bad effects because on this board PHYS_OFFSET is zero, and (a) writing zero to the flags register at offset 0x10 has no effect and (b) the reset value of the SMAP register is zero anyway, so failing to write SMAP2 didn't matter.) Signed-off-by:
Peter Maydell <peter.maydell@linaro.org> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Kevin Hilman <khilman@linaro.org> Signed-off-by:
-
Peter Maydell authored
commit 829f9fed upstream. The versatile PCI controller code was confused between the PCI I/O window (at 0x43000000) and the first PCI memory window (at 0x44000000). Pass the correct base address to pci_remap_io() so that PCI I/O accesses work. Since the first PCI memory window isn't used at all (it's an odd size), rename the associated variables and labels so that it's clear that it isn't related to the I/O window. This has been tested and confirmed to fix PCI I/O accesses both on physical PB926+PCI backplane hardware and on QEMU. Signed-off-by:
-
Peter Maydell authored
commit f9b71fef upstream. The PCI controller code for the Versatile board has never had the correct IRQ mapping for hardware. For many years it had an odd mapping ("all interrupts are int 27") which aligned with the equivalent bug in QEMU. However as of commit 1bc39ac5 the mapping changed and no longer matched either hardware or QEMU, with the result that any PCI card beyond the first in QEMU would not have functioning interrupts; for example a boot with a SCSI controller would time out as follows: ------------ sym0: <895a> rev 0x0 at pci 0000:00:0d.0 irq 92 sym0: SCSI BUS has been reset. scsi0 : sym-2.2.3 [...] scsi 0:0:0:0: ABORT operation started scsi 0:0:0:0: ABORT operation timed-out. scsi 0:0:0:0: DEVICE RESET operation started scsi 0:0:0:0: DEVICE RESET operation timed-out. scsi 0:0:0:0: BUS RESET operation started scsi 0:0:0:0: BUS RESET operation timed-out. scsi 0:0:0:0: HOST RESET operation started sym0: SCSI BUS has been reset ------------ Fix the mapping so that it matches real hardware (checked against the schematics for PB926 and backplane, and tested against the hardware). This allows PCI cards using interrupts to work on hardware for the first time; this change will also work with QEMU 1.5 or later, where the equivalent bugs in the modelling of the hardware have been fixed. Although QEMU will attempt to autodetect whether the kernel is expecting the long-standing "everything is int 27" mapping or the one hardware has, for certainty we force it into "definitely behave like hardware mode"; this will avoid unexpected surprises later if we implement sparse irqs. This is harmless on hardware. Thanks to Paul Gortmaker for bisecting the problem and finding an initial solution, to Russell King for providing the correct interrupt mapping, and to Guenter Roeck for providing an initial version of this patch and prodding me into relocating the hardware and retesting everything. Signed-off-by:
-
Will Deacon authored
commit 178cd9ce upstream. This is a port of f2fe09b0 ("ARM: 7663/1: perf: fix ARMv7 EVTYPE_MASK to include NSH bit") to arm64, which fixes the broken evtype mask to include the NSH bit, allowing profiling at EL2. Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Will Deacon authored
commit 8455e6ec upstream. This is a port of cb2d8b34 ("ARM: 7698/1: perf: fix group validation when using enable_on_exec") to arm64, which fixes the event validation checking so that events in the OFF state are still considered when enable_on_exec is true. Signed-off-by:
-
Christoffer Dall authored
commit 240e99cb upstream. The PAR was exported as CRn == 7 and CRm == 0, but in fact the primary coprocessor register number was determined by CRm for 64-bit coprocessor registers as the user space API was modeled after the coprocessor access instructions (see the ARM ARM rev. C - B3-1445). However, just changing the CRn to CRm breaks the sorting check when booting the kernel, because the internal kernel logic always treats CRn as the primary register number, and it makes the table sorting impossible to understand for humans. Alternatively we could change the logic to always have CRn == CRm, but that becomes unclear in the number of ways we do look up of a coprocessor register. We could also have a separate 64-bit table but that feels somewhat over-engineered. Instead, keep CRn the primary representation of the primary coproc. register number in-kernel and always export the primary number as CRm as per the existing user space ABI. Note: The TTBR registers just magically worked because they happened to follow the CRn(0) regs and were considered CRn(0) in the in-kernel representation. Signed-off-by:
Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by:
Kim Phillips <kim.phillips@linaro.org> Cc: Gleb Natapov <gleb@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Jonghwan Choi <jhbird.choi@samsung.com> Signed-off-by:
-
Arnd Bergmann authored
commit 8b2efa89 upstream. A recent series has added CPU numbers to a lot of dts files, but unfortunately in a few cases the #address-cells and #size-cells values are missing, which causes build warnings. This adds the missing ones for sunxi and sama5 that I found through build testing. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
-
Lorenzo Pieralisi authored
commit 14c44aa5 upstream. This patch updates the in-kernel dts files according to the latest cpus and cpu bindings updates for ARM. Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
-
Lorenzo Pieralisi authored
commit e757a6ee upstream. This patch updates the in-kernel dts files according to the latest cpus and cpu bindings updates for ARM. Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
-
