This repository has been archived by the owner on Jun 3, 2023. It is now read-only.
Gem5/v4.4 #1
Open
Gem5/v4.4 #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…l/git/powerpc/linux Pull powerpc fixes from Michael Ellerman: - Partial revert of "powerpc: Individual System V IPC system calls" - pr_warn_once on unsupported OPAL_MSG type from Stewart - Fix deadlock in opal-irqchip introduced by "Fix double endian conversion" from Alistair * tag 'powerpc-4.4-5' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/opal-irqchip: Fix deadlock introduced by "Fix double endian conversion" powerpc/powernv: pr_warn_once on unsupported OPAL_MSG type Partial revert of "powerpc: Individual System V IPC system calls"
Pull md fixes from Neil Brown: "Four fixes for md: - two recently introduced regressions fixed. - one older bug in RAID10 - tagged for -stable since 4.2 - one minor sysfs api improvement" * tag 'md/4.4-rc5-fixes' of git://neil.brown.name/md: Fix remove_and_add_spares removes drive added as spare in slot_store md: fix bug due to nested suspend MD: change journal disk role to disk 0 md/raid10: fix data corruption and crash during resync
…git/gregkh/usb Pull USB fixes from Greg KH: "Here are some USB and PHY fixes for 4.4-rc6. All of them resolve some reported problems. Full details in the shortlog" * tag 'usb-4.4-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: USB: fix invalid memory access in hub_activate() USB: ipaq.c: fix a timeout loop phy: core: Get a refcount to phy in devm_of_phy_get_by_index() phy: cygnus: pcie: add missing of_node_put phy: miphy365x: add missing of_node_put phy: miphy28lp: add missing of_node_put phy: rockchip-usb: add missing of_node_put phy: berlin-sata: add missing of_node_put phy: mt65xx-usb3: add missing of_node_put phy: brcmstb-sata: add missing of_node_put phy: sun9i-usb: add USB dependency
…git/gregkh/tty Pull tty/serial fixes from Greg KH: "Here are some tty/serial driver fixes for 4.4-rc6 that resolve some reported problems. All of these have been in linux-next. The details are in the shortlog" * tag 'tty-4.4-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: tty: Fix GPF in flush_to_ldisc() serial: earlycon: Add missing spinlock initialization serial: sh-sci: Fix length of scatterlist n_tty: Fix poll() after buffer-limited eof push read serial: 8250_uniphier: fix dl_read and dl_write functions
In A.D. 1582 Pope Gregory XIII found that the existing Julian calendar insufficiently represented reality, and changed the rules about calculating leap years to account for this. Similarly, in A.D. 2013 Rockchip hardware engineers found that the new Gregorian calendar still contained flaws, and that the month of November should be counted up to 31 days instead. Unfortunately it takes a long time for calendar changes to gain widespread adoption, and just like more than 300 years went by before the last Protestant nation implemented Greg's proposal, we will have to wait a while until all religions and operating system kernels acknowledge the inherent advantages of the Rockchip system. Until then we need to translate dates read from (and written to) Rockchip hardware back to the Gregorian format. This patch works by defining Jan 1st, 2016 as the arbitrary anchor date on which Rockchip and Gregorian calendars are in sync. From that we can translate arbitrary later dates back and forth by counting the number of November/December transitons since the anchor date to determine the offset between the calendars. We choose this method (rather than trying to regularly "correct" the date stored in hardware) since it's the only way to ensure perfect time-keeping even if the system may be shut down for an unknown number of years. The drawback is that other software reading the same hardware (e.g. mainboard firmware) must use the same translation convention (including the same anchor date) to be able to read and write correct timestamps from/to the RTC. Signed-off-by: Julius Werner <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Alexandre Belloni <[email protected]>
… power on
This fix alters the ordering of the IRQ and device registrations in the RTC
driver probe function. This change will apply to the RTC driver that supports
both DA9063 and DA9062 PMICs.
A problem could occur with the existing RTC driver if:
A system is started from a cold boot using the PMIC RTC IRQ to initiate a
power on operation. For instance, if an RTC alarm is used to start a
platform from power off.
The existing driver IRQ is requested before the device has been properly
registered.
i.e.
ret = devm_request_threaded_irq()
comes before
rtc->rtc_dev = devm_rtc_device_register();
In this case, the interrupt can be called before the device has been
registered and the handler can be called immediately. The IRQ handler
da9063_alarm_event() contains the function call
rtc_update_irq(rtc->rtc_dev, 1, RTC_IRQF | RTC_AF);
which in turn tries to access the unavailable rtc->rtc_dev.
The fix is to reorder the functions inside the RTC probe. The IRQ is
requested after the RTC device resource has been registered so that
get_irq_byname is the last thing to happen.
Signed-off-by: Steve Twiss <[email protected]>
Signed-off-by: Alexandre Belloni <[email protected]>
…t/abelloni/linux Pull RTC fixes from Alexandre Belloni: "Late fixes for the RTC subsystem for 4.4: A fix for a nasty hardware bug in rk808 and an initialization reordering in da9063 to fix a possible crash" * tag 'rtc-4.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: rtc: da9063: fix access ordering error during RTC interrupt at system power on rtc: rk808: Compensate for Rockchip calendar deviation on November 31st
md currently doesn't allow a 'sync_action' such as 'reshape' to be set while MD_RECOVERY_NEEDED is set. This s a problem, particularly since commit 738a273 as that can cause ->check_shape to call mddev_resume() which sets MD_RECOVERY_NEEDED. So by the time we come to start 'reshape' it is very likely that MD_RECOVERY_NEEDED is still set. Testing for this flag is not really needed and is in any case very racy as it can be set at any moment - asynchronously. Any race between setting a sync_action and setting MD_RECOVERY_NEEDED must already be handled properly in some locked code, probably md_check_recovery(), so remove the test here. The test on MD_RECOVERY_RUNNING is also racy in the 'reshape' case so we should test it again after getting mddev_lock(). As this fixes a race and a regression which can cause 'reshape' to fail, it is suitable for -stable kernels since 4.1 Reported-by: Xiao Ni <[email protected]> Fixes: 738a273 ("md/raid5: fix allocation of 'scribble' array.") Cc: [email protected] (v4.1+) Signed-off-by: NeilBrown <[email protected]>
The processor cooling device is no longer present for passive thermal control. Commit 239708a ("ACPI: Split out ACPI PSS from ACPI Processor driver") moved the processing to a new function acpi_pss_perf_init(), but missed "return 0" after successful creation. This causes the error handling functions to be called, which will delete the previously created processor cooling device. Fixes: 239708a (ACPI: Split out ACPI PSS from ACPI Processor driver) Signed-off-by: Srinivas Pandruvada <[email protected]> Cc: 4.3+ <[email protected]> # 4.3+ Signed-off-by: Rafael J. Wysocki <[email protected]>
| WARNING: vmlinux.o(.text+0xd6c2): Section mismatch in reference from the function alloc_kmap_pgtable() to the function | .init.text:__alloc_bootmem_low() The function alloc_kmap_pgtable() references the function __init __alloc_bootmem_low(). This is often because alloc_kmap_pgtable lacks a __init annotation or the annotation of __alloc_bootmem_low is wrong. Signed-off-by: Vineet Gupta <[email protected]>
ARC700 cores with MMU v2 don't have IC_PTAG AUX register and so we only
define ARC_REG_IC_PTAG for MMU versions >= 3.
But current implementation of cache_line_loop_vX() routines assumes
availability of all of them (v2, v3 and v4) simultaneously.
And given undefined ARC_REG_IC_PTAG if CONFIG_MMU_VER=2 we're seeing
compilation problem:
---------------------------------->8-------------------------------
CC arch/arc/mm/cache.o
arch/arc/mm/cache.c: In function '__cache_line_loop_v3':
arch/arc/mm/cache.c:270:13: error: 'ARC_REG_IC_PTAG' undeclared (first use in this function)
aux_tag = ARC_REG_IC_PTAG;
^
arch/arc/mm/cache.c:270:13: note: each undeclared identifier is reported only once for each function it appears in
scripts/Makefile.build:258: recipe for target 'arch/arc/mm/cache.o' failed
---------------------------------->8-------------------------------
The simples fix is to have ARC_REG_IC_PTAG defined regardless MMU
version being used.
We don't use it in cache_line_loop_v2() anyways so who cares.
Signed-off-by: Alexey Brodkin <[email protected]>
Signed-off-by: Vineet Gupta <[email protected]>
At -Os, ARC gcc generates millicode thunk for function prologue/epilogue,
which are served by libgcc.
Modules historically are NOT linked with libgcc to avoid code bloat, reducing
runtime relocation fixups etc. I even once tried doing that but got lost
in makefile intricacies.
This means modules at -Os don't get the millicode thunks, causing build
failures below:
| MODPOST 5 modules
| ERROR: "__ld_r13_to_r18" [crypto/sha256_generic.ko] undefined!
| ERROR: "__ld_r13_to_r18_ret" [crypto/sha256_generic.ko] undefined!
| ERROR: "__st_r13_to_r18" [crypto/sha256_generic.ko] undefined!
| ERROR: "__ld_r13_to_r17_ret" [crypto/sha256_generic.ko] undefined!
| ERROR: "__st_r13_to_r17" [crypto/sha256_generic.ko] undefined!
| ERROR: "__ld_r13_to_r16_ret" [crypto/sha256_generic.ko] undefined!
| ERROR: "__st_r13_to_r16" [crypto/sha256_generic.ko] undefined!
|....
|....
Workaround that by inhibiting millicode thunks for loadable modules
Fixes STAR 9000641864:
("Linux built with optimizations for size emits errors for modules")
Reported-by: Anton Kolesov <[email protected]>
Cc: Michal Marek <[email protected]>
Cc: [email protected]
Signed-off-by: Vineet Gupta <[email protected]>
… bailing" Blingly ignoring CIE.version != 1 was a bad idea. It still leaves "desirability" when running perf with callgraphing where libgcc symbols might show in hotspot. More importantly, basic CIE.version == 3 support already exists in code: | | retAddrReg = state.version <= 1 ? *ptr++ : get_uleb128(&ptr, end); | Next commit with simply add continue-not-bail for CIE.version != 1 This reverts commit 323f41f.
The rudimentary CIE.version == 3 handling is already present in code (for return address register specification) Signed-off-by: Vineet Gupta <[email protected]>
Instead of seeing empty stack traces, let kernel fail early so dwarf issues can be fixed sooner Signed-off-by: Vineet Gupta <[email protected]>
On parisc syscalls which are interrupted by signals sometimes failed to restart and instead returned -ENOSYS which in the worst case lead to userspace crashes. A similiar problem existed on MIPS and was fixed by commit e967ef0 ("MIPS: Fix restart of indirect syscalls"). On parisc the current syscall restart code assumes that all syscall callers load the syscall number in the delay slot of the ble instruction. That's how it is e.g. done in the unistd.h header file: ble 0x100(%sr2, %r0) ldi #syscall_nr, %r20 Because of that assumption the current code never restored %r20 before returning to userspace. This assumption is at least not true for code which uses the glibc syscall() function, which instead uses this syntax: ble 0x100(%sr2, %r0) copy regX, %r20 where regX depend on how the compiler optimizes the code and register usage. This patch fixes this problem by adding code to analyze how the syscall number is loaded in the delay branch and - if needed - copy the syscall number to regX prior returning to userspace for the syscall restart. Signed-off-by: Helge Deller <[email protected]> Cc: [email protected] Cc: Mathieu Desnoyers <[email protected]>
Signed-off-by: Andy Lutomirski <[email protected]> Reviewed-and-tested-by: Borislav Petkov <[email protected]> Cc: <[email protected]> Cc: Su Tao <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: <[email protected]> Cc: <[email protected]> Cc: <[email protected]> Cc: Brian Gerst <[email protected]> Cc: Mingwei Shi <[email protected]> Cc: Linus Torvalds <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]>
It turns out that some Android versions hardcode the SYSENTER calling convention. This is buggy and will cause problems no matter what the kernel does. Nonetheless, we should try to support it. Credit goes to Linus for pointing out a clean way to handle the SYSENTER/SYSCALL clobber differences while preserving straightforward DWARF annotations. I believe that the original offending Android commit was: https://android.googlesource.com/platform%2Fbionic/+/7dc3684d7a2587e43e6d2a8e0e3f39bf759bd535 Reported-by: Qiuxu Zhuo <[email protected]> Signed-off-by: Andy Lutomirski <[email protected]> Reviewed-and-tested-by: Borislav Petkov <[email protected]> Cc: <[email protected]> Cc: Su Tao <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: <[email protected]> Cc: <[email protected]> Cc: Brian Gerst <[email protected]> Cc: Mingwei Shi <[email protected]> Cc: Linus Torvalds <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]>
Unlike DW5550, Dell DW5812 is a mobile broadband card with no ARP capabilities: the patch makes this device to use wwan_noarp_info struct Signed-off-by: Daniele Palmas <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Unlike DW5550, Dell DW5813 is a mobile broadband card with no ARP capabilities: the patch makes this device to use wwan_noarp_info struct Signed-off-by: Daniele Palmas <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Daniele Palmas says: ==================== net: usb: cdc_ncm: Adding support for two new Dell devices This patch series add support in the cdc_ncm driver for two devices based on the same platform, that are different only for carrier customization. V2: Added comment for highlighting FLAG_NOARP usage for those devices ==================== Signed-off-by: David S. Miller <[email protected]>
Eryu Guan reported that loading scsi_debug would fail. This turned out to be caused by scsi_debug reporting an optimal I/O size of 32KB which is smaller than the 64KB page size on the PowerPC system in question. Add a check to ensure that we only use the device-reported OPTIMAL TRANSFER LENGTH if it is bigger than or equal to the page cache size. Reported-by: Eryu Guan <[email protected]> Reported-by: Ming Lei <[email protected]> Reviewed-by: Douglas Gilbert <[email protected]> Reviewed-by: Ewan Milne <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
Without this patch, internal speaker and line-out work,
but front headphone output jack stays silent on the
Mac Pro 4,1.
This code path also gets executed on the MacPro 5,1 due
to identical codec SSID, but i don't know if it has any
positive or adverse effects there or not.
(v2) Implement feedback from Takashi Iwai: Reuse
alc889_fixup_mbp_vref and just add a new nid
0x19 for the MacPro 4,1.
Signed-off-by: Mario Kleiner <[email protected]>
Cc: <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
The cursor code tries to treat base==0 to mean disabled. That fails when the cursor bo gets bound at ggtt offset 0, and the user is left looking at an invisible cursor. We lose the disabled->disabled optimization, but that seems like something better handled at a slightly higher level. Cc: [email protected] Cc: Takashi Iwai <[email protected]> Cc: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Chris Wilson <[email protected]> (cherry picked from commit 663f3122d00c0b412d429f105dca129aa8f4f094) Signed-off-by: Jani Nikula <[email protected]>
As we mark the preallocated objects as bound, we should also flag them correctly as being map-and-fenceable (if appropriate!) so that later users do not get confused and try and rebind the pinned vma in order to get a map-and-fenceable binding. Signed-off-by: Chris Wilson <[email protected]> Cc: "Goel, Akash" <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Jesse Barnes <[email protected]> Cc: [email protected] Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jesse Barnes <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> (cherry picked from commit d0710abbcd88b1ff17760e97d74a673e67b49ea1) Signed-off-by: Jani Nikula <[email protected]>
If we fail to reconstruct the BIOS fb (e.g., because the FB is too large), we'll be left with plane state that indicates the primary plane is visible yet has a NULL fb. This mismatch causes problems later on (e.g., for the watermark code). Since we've failed to reconstruct the BIOS FB, the best solution is to just disable the primary plane and pretend the BIOS never had it enabled. v2: Add intel_pre_disable_primary() call (Maarten) Cc: Daniel Vetter <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: [email protected] Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 200757f5d7c6f7f7032a0a07bbb8c02a840bbf7d) Signed-off-by: Jani Nikula <[email protected]>
The strlen_user() function calls __strlen_kernel_asm in both branches of the eva_kernel_access() conditional. For EVA it should be calling __strlen_user_eva for user accesses, otherwise it will load from the kernel address space instead of the user address space, and the access checking will likely be ineffective at preventing it due to EVA's overlapping user and kernel address spaces. This was found after extending the test_user_copy module to cover user string access functions, which gave the following error with EVA: test_user_copy: illegal strlen_user passed Fortunately the use of strlen_user() has been all but eradicated from the mainline kernel, so only out of tree modules could be affected. Fixes: e3a9b07 ("MIPS: asm: uaccess: Add EVA support for str*_user operations") Signed-off-by: James Hogan <[email protected]> Cc: Markos Chandras <[email protected]> Cc: Paul Burton <[email protected]> Cc: Leonid Yegoshin <[email protected]> Cc: [email protected] Cc: <[email protected]> # 3.15.x- Patchwork: https://patchwork.linux-mips.org/patch/10842/ Signed-off-by: Ralf Baechle <[email protected]>
The busywait in __i915_spin_request() does not respect pending signals and so may consume the entire timeslice for the task instead of returning to userspace to handle the signal. In the worst case this could cause a delay in signal processing of 20ms, which would be a noticeable jitter in cursor tracking. If a higher resolution signal was being used, for example to provide fairness of a server timeslices between clients, we could expect to detect some unfairness between clients (i.e. some windows not updating as fast as others). This issue was noticed when inspecting a report of poor interactivity resulting from excessively high __i915_spin_request usage. Fixes regression from commit 2def4ad [v4.2] Author: Chris Wilson <[email protected]> Date: Tue Apr 7 16:20:41 2015 +0100 drm/i915: Optimistically spin for the request completion v2: Try to assess the impact of the bug Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Cc: Jens Axboe <[email protected]> Cc; "Rogozhkin, Dmitry V" <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Eero Tamminen <[email protected]> Cc: "Rantala, Valtteri" <[email protected]> Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 91b0c352ace9afec1fb51590c7b8bd60e0eb9fbd) Signed-off-by: Jani Nikula <[email protected]>
When EVA is in use, __copy_from_user() was unconditionally using the EVA instructions to read the user address space, however this can also be used for kernel access. If the address isn't a valid user address it will cause an address error or TLB exception, and if it is then user memory may be read instead of kernel memory. For example in the following stack trace from Linux v3.10 (changes since then will prevent this particular one still happening) kernel_sendmsg() set the user address limit to KERNEL_DS, and tcp_sendmsg() goes on to use __copy_from_user() with a kernel address in KSeg0. [<8002d434>] __copy_fromuser_common+0x10c/0x254 [<805710e0>] tcp_sendmsg+0x5f4/0xf00 [<804e8e3c>] sock_sendmsg+0x78/0xa0 [<804e8f28>] kernel_sendmsg+0x24/0x38 [<804ee0f8>] sock_no_sendpage+0x70/0x7c [<8017c820>] pipe_to_sendpage+0x80/0x98 [<8017c6b0>] splice_from_pipe_feed+0xa8/0x198 [<8017cc54>] __splice_from_pipe+0x4c/0x8c [<8017e844>] splice_from_pipe+0x58/0x78 [<8017e884>] generic_splice_sendpage+0x20/0x2c [<8017d690>] do_splice_from+0xb4/0x110 [<8017d710>] direct_splice_actor+0x24/0x30 [<8017d394>] splice_direct_to_actor+0xd8/0x208 [<8017d51c>] do_splice_direct+0x58/0x7c [<8014eaf4>] do_sendfile+0x1dc/0x39c [<8014f82c>] SyS_sendfile+0x90/0xf8 Add the eva_kernel_access() check in __copy_from_user() like the one in copy_from_user(). Signed-off-by: James Hogan <[email protected]> Cc: Markos Chandras <[email protected]> Cc: Paul Burton <[email protected]> Cc: Leonid Yegoshin <[email protected]> Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/10843/ Signed-off-by: Ralf Baechle <[email protected]>
Pull KVM fix from Paolo Bonzini: "A simple fix. I'm sending it before the merge window, because it refines a patch found in your master branch but not yet in the kvm/next branch that is destined for 4.5" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: kvm: x86: only channel 0 of the i8254 is linked to the HPET
…nel/git/arm/arm-soc Pull ARM SoC fixes from Arnd Bergmann: "This is the final small set of ARM SoC bug fixes for linux-4.4, almost all regressions: OMAP: - data corruption on the Nokia N900 flash Allwinner: - Two defconfig change to get USB working again ARM Versatile: - Interrupt numbers gone bad after an older bug fix Nomadik: - Crashes from incorrect L2 cache settings VIA vt8500: - SD/MMC support on WM8650 never worked" * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: dts: vt8500: Add SDHC node to DTS file for WM8650 ARM: Fix broken USB support in multi_v7_defconfig for sunxi devices ARM: versatile: fix MMC/SD interrupt assignment ARM: nomadik: set latencies to 8 cycles ARM: OMAP2+: Fix onenand rate detection to avoid filesystem corruption ARM: Fix broken USB support in sunxi_defconfig
kernel test robot has reported the following crash: BUG: unable to handle kernel NULL pointer dereference at 00000100 IP: [<c1074df6>] __queue_work+0x26/0x390 *pdpt = 0000000000000000 *pde = f000ff53f000ff53 *pde = f000ff53f000ff53 Oops: 0000 [#1] PREEMPT PREEMPT SMP SMP CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.4.0-rc4-00139-g373ccbe #1 Workqueue: events vmstat_shepherd task: cb684600 ti: cb7ba000 task.ti: cb7ba000 EIP: 0060:[<c1074df6>] EFLAGS: 00010046 CPU: 0 EIP is at __queue_work+0x26/0x390 EAX: 00000046 EBX: cbb37800 ECX: cbb37800 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: cb7bbe68 ESP: cb7bbe38 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 CR0: 8005003b CR2: 00000100 CR3: 01fd5000 CR4: 000006b0 Stack: Call Trace: __queue_delayed_work+0xa1/0x160 queue_delayed_work_on+0x36/0x60 vmstat_shepherd+0xad/0xf0 process_one_work+0x1aa/0x4c0 worker_thread+0x41/0x440 kthread+0xb0/0xd0 ret_from_kernel_thread+0x21/0x40 The reason is that start_shepherd_timer schedules the shepherd work item which uses vmstat_wq (vmstat_shepherd) before setup_vmstat allocates that workqueue so if the further initialization takes more than HZ we might end up scheduling on a NULL vmstat_wq. This is really unlikely but not impossible. Fixes: 373ccbe ("mm, vmstat: allow WQ concurrency to discover memory reclaim doesn't make any progress") Reported-by: kernel test robot <[email protected]> Signed-off-by: Michal Hocko <[email protected]> Tested-by: Tetsuo Handa <[email protected]> Cc: [email protected] Cc: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
…rnel/git/helgaas/pci Pull PCI fixlet from Bjorn Helgaas: "This marks the TI DRA7xx host bridge driver as broken. Apparently it has never worked without some additional out-of-tree code, so I'm going to mark it broken now and remove it completely next cycle unless it's fixed" * tag 'pci-v4.4-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: PCI: dra7xx: Mark driver as broken
…it/jejb/scsi Pull SCSI fix from James Bottomley: "A single fix for machines with pages > 4k (PPC mostly). There's a bug in our optimal transfer size code where we don't account for pages > 4k and can set the transfer size to be less than the page size causing nasty failures" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: sd: Reject optimal transfer length smaller than page size
Export a set of symbols used for gem5 to determine sizes and locations of useful data structures within the kernel. Change-Id: Idcfaf5fcd91b7ea38e70f174af7f4d19c27a107e Signed-off-by: Andreas Sandberg <[email protected]> Reviewed-by: Curtis Dunham <[email protected]> Reviewed-by: Geoffrey Blake <[email protected]>
gem5's GIC model contains a gem5-specific extension that enables support for up to 255 CPUs. When enabled, the GIC interprets registers where a CPU bitmask would normally be present as a CPU ID. This extensions need to be enabled by setting the OF compatible string to "gem5,gic". Kudos to Matt Evans for the original version of this patch. Change-Id: I1a8776f1adcbfcd97813573050a8595176de6a7e Signed-off-by: Andreas Sandberg <[email protected]> Reviewed-by: Stephan Diestelhorst <[email protected]> Reviewed-by: Curtis Dunham <[email protected]> [Ported to 4.4] Signed-off-by: Andreas Sandberg <[email protected]>
Add a default gem5 Linux configuration Change-Id: I57d1bab24bb835b872bfc9528e59a3bb029041fe Reviewed-by: Curtis Dunham <[email protected]>
Add a default gem5 Linux configuration for arm64 Change-Id: Ib3247dbf99b10078f023b7a393e71c573eccdd4e Signed-off-by: Geoffrey Blake <[email protected]> Reviewed-by: Andreas Sandberg <[email protected]>
Update asm/io.h to provide known working implementations for writeq and readq to work with NVMe and IGB device drivers which perform 64-bit IO reads and writes. Signed-off-by: Geoffrey Blake <[email protected]> Change-Id: I1ec9bad6fc9d0ef4eda2f71200bc3e08460dcacf Reviewed-by: Andreas Sandberg <[email protected]>
Modify mach-vexpress/Kconfig and include/asm/Kbuild to build in MSI support for armv7 so we can use the GIC_V2M with PCI devices that support MSI and MSI-X. Signed-off-by: Geoffrey Blake <[email protected]> Change-Id: I0858eeb6ea713cb5725d24524dc522dfecd56e45 Reviewed-by: Andreas Sandberg <[email protected]>
Update gem5_defconfig to build in support for MSI-X and the GIC_V2M for default gem5 armv7 kernel builds. Signed-off-by: Geoffrey Blake <[email protected]> Change-Id: If330eb467bf3cebbaee677d817e5202913642aee Reviewed-by: Andreas Sandberg <[email protected]>
The HDLCD controller is a display controller that supports resolutions up to 4096x4096 pixels. It is present on various development boards produced by ARM Ltd and emulated by the latest Fast Models from the company. Cc: David Airlie <[email protected]> Cc: Robin Murphy <[email protected]> Signed-off-by: Liviu Dudau <[email protected]> [Kconfig cleanup and !CONFIG_PM fixes] Signed-off-by: Arnd Bergmann <[email protected]> Acked-by: Daniel Vetter <[email protected]> [Backported to gem5's 4.3 kernel] Signed-off-by: Andreas Sandberg <[email protected]>
Clock is acquired with devm_clk_get() which already manages corresponding resource. I.e. in case of driver removal or failure on installaiton clock resources will be automatically released and explicit call of devm_clk_put() is not required. Cc: Arnd Bergmann <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: David Airlie <[email protected]> Cc: Robin Murphy <[email protected]> Signed-off-by: Alexey Brodkin <[email protected]> Signed-off-by: Liviu Dudau <[email protected]>
We accidentally return PTR_ERR(NULL) which is success instead of a
negative error code.
Fixes: 879e40bea6f2 ('drm: ARM HDLCD - get rid of devm_clk_put()')
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Liviu Dudau <[email protected]>
Cc: Pawel Moll <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Ian Campbell <[email protected]> Cc: Kumar Gala <[email protected]> Acked-by: Rob Herring <[email protected]> Signed-off-by: Liviu Dudau <[email protected]>
Add DT bindings for a simple DRM encoder that gets the display timings information from the DT and can be connected to a driver via the OF graph bindings. Signed-off-by: Liviu Dudau <[email protected]>
This is a simple DRM encoder that gets its connector timings information from a OF subnode in the device tree and exposes that as a "discovered" panel. It can be used together with component-based DRM drivers in an emulated environment where no real encoder or connector hardware exists and the display output is configured outside the kernel. Signed-off-by: Liviu Dudau <[email protected]> [Backported to gem5's 4.3 kernel] Signed-off-by: Andreas Sandberg <[email protected]>
Add support for the dma-buf exporter role to the frame buffer API. The importer role isn't meaningful for frame buffer devices, as the frame buffer device model doesn't allow using externally allocated memory. Taken from an RFC on the linaro-mm-sig mailing list: http://lists.linaro.org/pipermail/linaro-mm-sig/2012-June/002167.html Signed-off-by: Guillaume Tucker <[email protected]> [Ported to gem5's 4.3 kernel] Signed-off-by: Andreas Sandberg <[email protected]>
The change that added dma-buf support to fbdev (fbdev: add dma-buf support) didn't correctly list dma-buf as a dependency. List it as a dependency of CONFIG_FB to avoid build errors. Change-Id: I8539b51c36c202a03b04a6888d03e8d28b0a78c4 Signed-off-by: Andreas Sandberg <[email protected]>
Add support for the new semi-standard fbdev API for dma-buf exports to user space. Change-Id: I8df10b2d214bb75a0c3f42f4c6ce58da9e9573b8 Signed-off-by: Andreas Sandberg <[email protected]> Reviewed-by: Liviu Dudau <[email protected]>
Change-Id: Ib5889feb5af659cecafcdd6ec896c0ca2e6370db Signed-off-by: Andreas Sandberg <[email protected]> Reviewed-by: Liviu Dudau <[email protected]>
Change-Id: I2b13286c48a095f74c32f80b0338062fa2cb9e9e Signed-off-by: Andreas Sandberg <[email protected]>
The gem5 GIC extensions weren't initialized correctly after the 4.4 rebase. This was caused by the distributor being initialized before the extensions were probed and enabled. This changeset moves the initialization from the OF-specific initialization code (gic_of_init) to the common path (__gic_init_bases). Change-Id: I31666c787675cddbb26858ec594702075d7775ac Signed-off-by: Andreas Sandberg <[email protected]> Reviewed-by: Geoffrey Blake <[email protected]>
The simple encoder depends on the DRM video mode helpers. Add this as a Kconfig dependency. Change-Id: I9fdc41fa9aca4a1a7ec08f22435086508ec2a133 Signed-off-by: Andreas Sandberg <[email protected]>
The fbdev helper that exports a dma-buf to user space didn't correctly increase the reference count of the DRM driver. Increase the reference count if exporting was successful. Change-Id: Id0239e10b7cd46b146dd596f78ee4690910ea747 Signed-off-by: Andreas Sandberg <[email protected]> Reviewed-by: Liviu Dudau <[email protected]>
The energy controller enables DVFS (dynamic voltage and frequency scaling support) of gem5 for up to 32 independent domains (or clusters). The changes are modelled somewhat after the VExpress SPC component, but are specific to gem5. Change-Id: I161913cb72bd9a8515f4e63686452e94ef222106 Signed-off-by: Sascha Bischoff <[email protected]> Reviewed-by: Geoffrey Blake <[email protected]> Signed-off-by: Andreas Sandberg <[email protected]>
In this changeset we enable the CPUFreq framework, as well as the corresponding gem5 drivers, in the gem5_defconfig for arm. We enable the following goverors: * Performance (Default) * Powersave * Userspace * Ondemand * Conservative The default governor is Performance as this will not adjust the frequency, and will leave it at the maximum frequency. Therefore, unless the governor is changed, future simulations should run as before. Change-Id: I02f2bac7e38824a9b4273dce58c1fda512e15176 Signed-off-by: Sascha Bischoff <[email protected]> Reviewed-by: Geoffrey Blake <[email protected]> Signed-off-by: Andreas Sandberg <[email protected]>
In this changeset we enable the CPUFreq framework, as well as the corresponding gem5 drivers, in the gem5_defconfig for arm64. We enable the following goverors: * Performance (Default) * Powersave * Userspace * Ondemand * Conservative The default governor is Performance as this will not adjust the frequency, and will leave it at the maximum frequency. Therefore, unless the governor is changed, future simulations should run as before. Change-Id: Iffe1734b92cc0421c2844b0e784b0ba34143d28d Signed-off-by: Sascha Bischoff <[email protected]> Reviewed-by: Geoffrey Blake <[email protected]> Signed-off-by: Andreas Sandberg <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.