summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-01-17ASoC: madera: Correct error path handling in madera_out1_demux_putCharles Keepax
Should the write to MADERA_OUTPUT_ENABLES_1 fail and out_clamp[0] not be set an additional error message will be printed. Clear the ret variable to avoid this. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20200114161841.451-3-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-17ASoC: SOF: Intel: hda: Fix SKL dai countCezary Rojewski
With fourth pin added for iDisp for skl_dai, update SOF_SKL_DAI_NUM to account for the change. Without this, dais from the bottom of the list are skipped. In current state that's the case for 'Alt Analog CPU DAI'. Fixes: ac42b142cd76 ("ASoC: SOF: Intel: hda: Add iDisp4 DAI") Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200113114054.9716-1-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-17ASoC: madera: Update handling of DAPM routes for mono muxed outputsCharles Keepax
Correctly link both channels on the DAC if an output muxed between a stereo and mono output. Without this one channel of the DAC may be erroneously powered down whilst in mono mode. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20200114161841.451-4-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-17ASoC: wm_adsp: Correct cache handling of new kernel control APICharles Keepax
The recently added API that exposes firmware mixer controls to the kernel is missing cache handling and all writes bypass the cache, this obviously causes the cache to get out of sync with the hardware. Factor out the cache handling into two new helper functions and call those from both the normal ALSA control handlers and the new kernel API. Fixes: eb65ccdb0836 ("ASoC: wm_adsp: Expose mixer control API") Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20200114161841.451-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-17USB: serial: quatech2: handle unbound portsJohan Hovold
Check for NULL port data in the modem- and line-status handlers to avoid dereferencing a NULL pointer in the unlikely case where a port device isn't bound to a driver (e.g. after an allocation failure on port probe). Note that the other (stubbed) event handlers qt2_process_xmit_empty() and qt2_process_flush() would need similar sanity checks in case they are ever implemented. Fixes: f7a33e608d9a ("USB: serial: add quatech2 usb to serial driver") Cc: stable <stable@vger.kernel.org> # 3.5 Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2020-01-17USB: serial: keyspan: handle unbound portsJohan Hovold
Check for NULL port data in the control URB completion handlers to avoid dereferencing a NULL pointer in the unlikely case where a port device isn't bound to a driver (e.g. after an allocation failure on port probe()). Fixes: 0ca1268e109a ("USB Serial Keyspan: add support for USA-49WG & USA-28XG") Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable <stable@vger.kernel.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2020-01-17USB: serial: io_edgeport: add missing active-port sanity checkJohan Hovold
The driver receives the active port number from the device, but never made sure that the port number was valid. This could lead to a NULL-pointer dereference or memory corruption in case a device sends data for an invalid port. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable <stable@vger.kernel.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2020-01-17USB: serial: io_edgeport: handle unbound ports on URB completionJohan Hovold
Check for NULL port data in the shared interrupt and bulk completion callbacks to avoid dereferencing a NULL pointer in case a device sends data for a port device which isn't bound to a driver (e.g. due to a malicious device having unexpected endpoints or after an allocation failure on port probe). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable <stable@vger.kernel.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2020-01-17USB: serial: ch341: handle unbound port at reset_resumeJohan Hovold
Check for NULL port data in reset_resume() to avoid dereferencing a NULL pointer in case the port device isn't bound to a driver (e.g. after a failed control request at port probe). Fixes: 1ded7ea47b88 ("USB: ch341 serial: fix port number changed after resume") Cc: stable <stable@vger.kernel.org> # 2.6.30 Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2020-01-17lib/vdso: Update coarse timekeeper unconditionallyThomas Gleixner
The low resolution parts of the VDSO, i.e.: clock_gettime(CLOCK_*_COARSE), clock_getres(), time() can be used even if there is no VDSO capable clocksource. But if an architecture opts out of the VDSO data update then this information becomes stale. This affects ARM when there is no architected timer available. The lack of update causes userspace to use stale data forever. Make the update of the low resolution parts unconditional and only skip the update of the high resolution parts if the architecture requests it. Fixes: 44f57d788e7d ("timekeeping: Provide a generic update_vsyscall() implementation") Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20200114185946.765577901@linutronix.de
2020-01-17lib/vdso: Make __arch_update_vdso_data() logic understandableThomas Gleixner
The function name suggests that this is a boolean checking whether the architecture asks for an update of the VDSO data, but it works the other way round. To spare further confusion invert the logic. Fixes: 44f57d788e7d ("timekeeping: Provide a generic update_vsyscall() implementation") Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20200114185946.656652824@linutronix.de
2020-01-17debugobjects: Fix various data racesMarco Elver
The counters obj_pool_free, and obj_nr_tofree, and the flag obj_freeing are read locklessly outside the pool_lock critical sections. If read with plain accesses, this would result in data races. This is addressed as follows: * reads outside critical sections become READ_ONCE()s (pairing with WRITE_ONCE()s added); * writes become WRITE_ONCE()s (pairing with READ_ONCE()s added); since writes happen inside critical sections, only the write and not the read of RMWs needs to be atomic, thus WRITE_ONCE(var, var +/- X) is sufficient. The data races were reported by KCSAN: BUG: KCSAN: data-race in __free_object / fill_pool write to 0xffffffff8beb04f8 of 4 bytes by interrupt on cpu 1: __free_object+0x1ee/0x8e0 lib/debugobjects.c:404 __debug_check_no_obj_freed+0x199/0x330 lib/debugobjects.c:969 debug_check_no_obj_freed+0x3c/0x44 lib/debugobjects.c:994 slab_free_hook mm/slub.c:1422 [inline] read to 0xffffffff8beb04f8 of 4 bytes by task 1 on cpu 2: fill_pool+0x3d/0x520 lib/debugobjects.c:135 __debug_object_init+0x3c/0x810 lib/debugobjects.c:536 debug_object_init lib/debugobjects.c:591 [inline] debug_object_activate+0x228/0x320 lib/debugobjects.c:677 debug_rcu_head_queue kernel/rcu/rcu.h:176 [inline] BUG: KCSAN: data-race in __debug_object_init / fill_pool read to 0xffffffff8beb04f8 of 4 bytes by task 10 on cpu 6: fill_pool+0x3d/0x520 lib/debugobjects.c:135 __debug_object_init+0x3c/0x810 lib/debugobjects.c:536 debug_object_init_on_stack+0x39/0x50 lib/debugobjects.c:606 init_timer_on_stack_key kernel/time/timer.c:742 [inline] write to 0xffffffff8beb04f8 of 4 bytes by task 1 on cpu 3: alloc_object lib/debugobjects.c:258 [inline] __debug_object_init+0x717/0x810 lib/debugobjects.c:544 debug_object_init lib/debugobjects.c:591 [inline] debug_object_activate+0x228/0x320 lib/debugobjects.c:677 debug_rcu_head_queue kernel/rcu/rcu.h:176 [inline] BUG: KCSAN: data-race in free_obj_work / free_object read to 0xffffffff9140c190 of 4 bytes by task 10 on cpu 6: free_object+0x4b/0xd0 lib/debugobjects.c:426 debug_object_free+0x190/0x210 lib/debugobjects.c:824 destroy_timer_on_stack kernel/time/timer.c:749 [inline] write to 0xffffffff9140c190 of 4 bytes by task 93 on cpu 1: free_obj_work+0x24f/0x480 lib/debugobjects.c:313 process_one_work+0x454/0x8d0 kernel/workqueue.c:2264 worker_thread+0x9a/0x780 kernel/workqueue.c:2410 Reported-by: Qian Cai <cai@lca.pw> Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20200116185529.11026-1-elver@google.com
2020-01-17btrfs: check rw_devices, not num_devices for balanceJosef Bacik
The fstest btrfs/154 reports [ 8675.381709] BTRFS: Transaction aborted (error -28) [ 8675.383302] WARNING: CPU: 1 PID: 31900 at fs/btrfs/block-group.c:2038 btrfs_create_pending_block_groups+0x1e0/0x1f0 [btrfs] [ 8675.390925] CPU: 1 PID: 31900 Comm: btrfs Not tainted 5.5.0-rc6-default+ #935 [ 8675.392780] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba527-rebuilt.opensuse.org 04/01/2014 [ 8675.395452] RIP: 0010:btrfs_create_pending_block_groups+0x1e0/0x1f0 [btrfs] [ 8675.402672] RSP: 0018:ffffb2090888fb00 EFLAGS: 00010286 [ 8675.404413] RAX: 0000000000000000 RBX: ffff92026dfa91c8 RCX: 0000000000000001 [ 8675.406609] RDX: 0000000000000000 RSI: ffffffff8e100899 RDI: ffffffff8e100971 [ 8675.408775] RBP: ffff920247c61660 R08: 0000000000000000 R09: 0000000000000000 [ 8675.410978] R10: 0000000000000000 R11: 0000000000000000 R12: 00000000ffffffe4 [ 8675.412647] R13: ffff92026db74000 R14: ffff920247c616b8 R15: ffff92026dfbc000 [ 8675.413994] FS: 00007fd5e57248c0(0000) GS:ffff92027d800000(0000) knlGS:0000000000000000 [ 8675.416146] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8675.417833] CR2: 0000564aa51682d8 CR3: 000000006dcbc004 CR4: 0000000000160ee0 [ 8675.419801] Call Trace: [ 8675.420742] btrfs_start_dirty_block_groups+0x355/0x480 [btrfs] [ 8675.422600] btrfs_commit_transaction+0xc8/0xaf0 [btrfs] [ 8675.424335] reset_balance_state+0x14a/0x190 [btrfs] [ 8675.425824] btrfs_balance.cold+0xe7/0x154 [btrfs] [ 8675.427313] ? kmem_cache_alloc_trace+0x235/0x2c0 [ 8675.428663] btrfs_ioctl_balance+0x298/0x350 [btrfs] [ 8675.430285] btrfs_ioctl+0x466/0x2550 [btrfs] [ 8675.431788] ? mem_cgroup_charge_statistics+0x51/0xf0 [ 8675.433487] ? mem_cgroup_commit_charge+0x56/0x400 [ 8675.435122] ? do_raw_spin_unlock+0x4b/0xc0 [ 8675.436618] ? _raw_spin_unlock+0x1f/0x30 [ 8675.438093] ? __handle_mm_fault+0x499/0x740 [ 8675.439619] ? do_vfs_ioctl+0x56e/0x770 [ 8675.441034] do_vfs_ioctl+0x56e/0x770 [ 8675.442411] ksys_ioctl+0x3a/0x70 [ 8675.443718] ? trace_hardirqs_off_thunk+0x1a/0x1c [ 8675.445333] __x64_sys_ioctl+0x16/0x20 [ 8675.446705] do_syscall_64+0x50/0x210 [ 8675.448059] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 8675.479187] BTRFS: error (device vdb) in btrfs_create_pending_block_groups:2038: errno=-28 No space left We now use btrfs_can_overcommit() to see if we can flip a block group read only. Before this would fail because we weren't taking into account the usable un-allocated space for allocating chunks. With my patches we were allowed to do the balance, which is technically correct. The test is trying to start balance on degraded mount. So now we're trying to allocate a chunk and cannot because we want to allocate a RAID1 chunk, but there's only 1 device that's available for usage. This results in an ENOSPC. But we shouldn't even be making it this far, we don't have enough devices to restripe. The problem is we're using btrfs_num_devices(), that also includes missing devices. That's not actually what we want, we need to use rw_devices. The chunk_mutex is not needed here, rw_devices changes only in device add, remove or replace, all are excluded by EXCL_OP mechanism. Fixes: e4d8ec0f65b9 ("Btrfs: implement online profile changing") CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Josef Bacik <josef@toxicpanda.com> Reviewed-by: David Sterba <dsterba@suse.com> [ add stacktrace, update changelog, drop chunk_mutex ] Signed-off-by: David Sterba <dsterba@suse.com>
2020-01-17Btrfs: always copy scrub arguments back to user spaceFilipe Manana
If scrub returns an error we are not copying back the scrub arguments structure to user space. This prevents user space to know how much progress scrub has done if an error happened - this includes -ECANCELED which is returned when users ask for scrub to stop. A particular use case, which is used in btrfs-progs, is to resume scrub after it is canceled, in that case it relies on checking the progress from the scrub arguments structure and then use that progress in a call to resume scrub. So fix this by always copying the scrub arguments structure to user space, overwriting the value returned to user space with -EFAULT only if copying the structure failed to let user space know that either that copying did not happen, and therefore the structure is stale, or it happened partially and the structure is probably not valid and corrupt due to the partial copy. Reported-by: Graham Cobb <g.btrfs@cobb.uk.net> Link: https://lore.kernel.org/linux-btrfs/d0a97688-78be-08de-ca7d-bcb4c7fb397e@cobb.uk.net/ Fixes: 06fe39ab15a6a4 ("Btrfs: do not overwrite scrub error with fault error in scrub ioctl") CC: stable@vger.kernel.org # 5.1+ Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Reviewed-by: Qu Wenruo <wqu@suse.com> Tested-by: Graham Cobb <g.btrfs@cobb.uk.net> Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2020-01-17cpu-topology: Don't error on more than CONFIG_NR_CPUS CPUs in device treeZeng Tao
When the kernel is configured with CONFIG_NR_CPUS smaller than the number of CPU nodes in the device tree(DT), all the CPU nodes parsing done to fetch topology information will fail. This is not reasonable as it is legal to have all the physical CPUs in the system in the DT. Let us just skip such CPU DT nodes that are not used in the kernel rather than returning an error. Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Zeng Tao <prime.zeng@hisilicon.com> Link: https://lore.kernel.org/r/1579225973-32423-1-git-send-email-prime.zeng@hisilicon.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-17Merge tag 'iwlwifi-for-kalle-2020-01-11' of ↵Kalle Valo
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes First batch of fixes intended for v5.5 * Don't send the PPAG command when PPAG is disabled, since it can cause problems; * A few fixes for a HW bug; * A fix for RS offload; * A fix for 3168 devices where the NVM tables where the wrong tables were being read. * Fix a couple of potential memory leaks in TXQ code; * Disable L0S states in all hardware since our hardware doesn't officially support them anymore (and older versions of the hardware had instability in these states); * Remove lar_disable parameter since it has been causing issues for some people who erroneously disable it; * Force the debug monitor HW to stop also when debug is disabled, since it sometimes stays on and prevents low system power states;
2020-01-17Merge tag 'gpio-v5.5-4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO fixes from Linus Walleij: "This reverts the GPIOLIB_IRQCHIP in the ThunderX driver. ThunderX is a piece of Arm-based server chip. I converted the driver to hierarchical gpiochip without access to real silicon and failed miserably since I didn't take MSI's into account. Kevin Hao helpfully stepped in and fixed it properly, let's revert it for v5.5 and put the proper conversion into v5.6" * tag 'gpio-v5.5-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: Revert "gpio: thunderx: Switch to GPIOLIB_IRQCHIP"
2020-01-17Merge tag 'block-5.5-2020-01-16' of git://git.kernel.dk/linux-blockLinus Torvalds
Pull block fixes from Jens Axboe: "Three fixes that should go into this release: - The 32-bit segment size fix that I mentioned last week (Ming) - Use uint for the block size (Mikulas) - A null_blk zone write handling fix (Damien)" * tag 'block-5.5-2020-01-16' of git://git.kernel.dk/linux-block: block: fix an integer overflow in logical block size null_blk: Fix zone write handling block: fix get_max_segment_size() overflow on 32bit arch
2020-01-17x86/apic/uv: Avoid unused variable warningArnd Bergmann
When CONFIG_PROC_FS is disabled, the compiler warns about an unused variable: arch/x86/kernel/apic/x2apic_uv_x.c: In function 'uv_setup_proc_files': arch/x86/kernel/apic/x2apic_uv_x.c:1546:8: error: unused variable 'name' [-Werror=unused-variable] char *name = hubless ? "hubless" : "hubbed"; Simplify the code so this variable is no longer needed. Fixes: 8785968bce1c ("x86/platform/uv: Add UV Hubbed/Hubless Proc FS Files") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20191212140419.315264-1-arnd@arndb.de
2020-01-17arm64: entry: cleanup sp_el0 manipulationMark Rutland
The kernel stashes the current task struct in sp_el0 so that this can be acquired consistently/cheaply when required. When we take an exception from EL0 we have to: 1) stash the original sp_el0 value 2) find the current task 3) update sp_el0 with the current task pointer Currently steps #1 and #2 occur in one place, and step #3 a while later. As the value of sp_el0 is immaterial between these points, let's move them together to make the code clearer and minimize ifdeffery. This necessitates moving the comment for MDSCR_EL1.SS. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: James Morse <james.morse@arm.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2020-01-17arm64: entry: cleanup el0 svc handler namingMark Rutland
For most of the exception entry code, <foo>_handler() is the first C function called from the entry assembly in entry-common.c, and external functions handling the bulk of the logic are called do_<foo>(). For consistency, apply this scheme to el0_svc_handler and el0_svc_compat_handler, renaming them to do_el0_svc and do_el0_svc_compat respectively. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: James Morse <james.morse@arm.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2020-01-17arm64: entry: mark all entry code as notraceMark Rutland
Almost all functions in entry-common.c are marked notrace, with el1_undef and el1_inv being the only exceptions. We appear to have done this on the assumption that there were no exception registers that we needed to snapshot, and thus it was safe to run trace code that might result in further exceptions and clobber those registers. However, until we inherit the DAIF flags, our irq flag tracing is stale, and this discrepancy could set off warnings in some configurations. For example if CONFIG_DEBUG_LOCKDEP is selected and a trace function calls into any flag-checking locking routines. Given we don't expect to trigger el1_undef or el1_inv unless something is already wrong, any irqflag warnigns are liable to mask the information we'd actually care about. Let's keep things simple and mark el1_undef and el1_inv as notrace. Developers can trace do_undefinstr and bad_mode if they really want to monitor these cases. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: James Morse <james.morse@arm.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2020-01-17arm64: assembler: remove smp_dmb macroMark Rutland
These days arm64 kernels are always SMP, and thus smp_dmb is an overly-long way of writing dmb. Naturally, no-one uses it. Remove the unused macro. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2020-01-17arm64: assembler: remove inherit_daif macroMark Rutland
We haven't needed the inherit_daif macro since commit: ed3768db588291dd ("arm64: entry: convert el1_sync to C") ... which converted all callers to C and the local_daif_inherit function. Remove the unused macro. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: James Morse <james.morse@arm.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2020-01-17ACPI/IORT: Fix 'Number of IDs' handling in iort_id_map()Hanjun Guo
The IORT specification [0] (Section 3, table 4, page 9) defines the 'Number of IDs' as 'The number of IDs in the range minus one'. However, the IORT ID mapping function iort_id_map() treats the 'Number of IDs' field as if it were the full IDs mapping count, with the following check in place to detect out of boundary input IDs: InputID >= Input base + Number of IDs This check is flawed in that it considers the 'Number of IDs' field as the full number of IDs mapping and disregards the 'minus one' from the IDs count. The correct check in iort_id_map() should be implemented as: InputID > Input base + Number of IDs this implements the specification correctly but unfortunately it breaks existing firmwares that erroneously set the 'Number of IDs' as the full IDs mapping count rather than IDs mapping count minus one. e.g. PCI hostbridge mapping entry 1: Input base: 0x1000 ID Count: 0x100 Output base: 0x1000 Output reference: 0xC4 //ITS reference PCI hostbridge mapping entry 2: Input base: 0x1100 ID Count: 0x100 Output base: 0x2000 Output reference: 0xD4 //ITS reference Two mapping entries which the second entry's Input base = the first entry's Input base + ID count, so for InputID 0x1100 and with the correct InputID check in place in iort_id_map() the kernel would map the InputID to ITS 0xC4 not 0xD4 as it would be expected. Therefore, to keep supporting existing flawed firmwares, introduce a workaround that instructs the kernel to use the old InputID range check logic in iort_id_map(), so that we can support both firmwares written with the flawed 'Number of IDs' logic and the correct one as defined in the specifications. [0]: http://infocenter.arm.com/help/topic/com.arm.doc.den0049d/DEN0049D_IO_Remapping_Table.pdf Reported-by: Pankaj Bansal <pankaj.bansal@nxp.com> Link: https://lore.kernel.org/linux-acpi/20191215203303.29811-1-pankaj.bansal@nxp.com/ Signed-off-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Pankaj Bansal <pankaj.bansal@nxp.com> Cc: Will Deacon <will@kernel.org> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2020-01-17mm: Reserve asm-generic prot flags 0x10 and 0x20 for arch useDave Martin
The asm-generic/mman.h definitions are used by a few architectures that also define arch-specific PROT flags with value 0x10 and 0x20. This currently applies to sparc and powerpc for 0x10, while arm64 will soon join with 0x10 and 0x20. To help future maintainers, document the use of this flag in the asm-generic header too. Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Dave Martin <Dave.Martin@arm.com> [catalin.marinas@arm.com: reserve 0x20 as well] Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2020-01-17arm64: Use macros instead of hard-coded constants for MAIR_EL1Catalin Marinas
Currently, the arm64 __cpu_setup has hard-coded constants for the memory attributes that go into the MAIR_EL1 register. Define proper macros in asm/sysreg.h and make use of them in proc.S. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2020-01-17arm64: Add KRYO{3,4}XX CPU cores to spectre-v2 safe listSai Prakash Ranjan
The "silver" KRYO3XX and KRYO4XX CPU cores are not affected by Spectre variant 2. Add them to spectre_v2 safe list to correct the spurious ARM_SMCCC_ARCH_WORKAROUND_1 warning and vulnerability status reported under sysfs. Reviewed-by: Stephen Boyd <swboyd@chromium.org> Tested-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> [will: tweaked commit message to remove stale mention of "gold" cores] Signed-off-by: Will Deacon <will@kernel.org>
2020-01-17net: systemport: Fixed queue mapping in internal ring mapFlorian Fainelli
We would not be transmitting using the correct SYSTEMPORT transmit queue during ndo_select_queue() which looks up the internal TX ring map because while establishing the mapping we would be off by 4, so for instance, when we populate switch port mappings we would be doing: switch port 0, queue 0 -> ring index #0 switch port 0, queue 1 -> ring index #1 ... switch port 0, queue 3 -> ring index #3 switch port 1, queue 0 -> ring index #8 (4 + 4 * 1) ... instead of using ring index #4. This would cause our ndo_select_queue() to use the fallback queue mechanism which would pick up an incorrect ring for that switch port. Fix this by using the correct switch queue number instead of SYSTEMPORT queue number. Fixes: 25c440704661 ("net: systemport: Simplify queue mapping logic") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17net: dsa: bcm_sf2: Configure IMP port for 2Gb/secFlorian Fainelli
With the implementation of the system reset controller we lost a setting that is currently applied by the bootloader and which configures the IMP port for 2Gb/sec, the default is 1Gb/sec. This is needed given the number of ports and applications we expect to run so bring back that setting. Fixes: 01b0ac07589e ("net: dsa: bcm_sf2: Add support for optional reset controller line") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17netns: Constify exported functionsGuillaume Nault
Mark function parameters as 'const' where possible. Signed-off-by: Guillaume Nault <gnault@redhat.com> Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17net: dsa: sja1105: Don't error out on disabled ports with no phy-modeVladimir Oltean
The sja1105_parse_ports_node function was tested only on device trees where all ports were enabled. Fix this check so that the driver continues to probe only with the ports where status is not "disabled", as expected. Fixes: 8aa9ebccae87 ("net: dsa: Introduce driver for NXP SJA1105 5-port L2 switch") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17net: dsa: felix: Don't error out on disabled ports with no phy-modeVladimir Oltean
The felix_parse_ports_node function was tested only on device trees where all ports were enabled. Fix this check so that the driver continues to probe only with the ports where status is not "disabled", as expected. Fixes: bdeced75b13f ("net: dsa: felix: Add PCS operations for PHYLINK") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17net: dsa: felix: Don't restart PCS SGMII AN if not neededAlex Marginean
Some PHYs like VSC8234 don't like it when AN restarts on their system side and they restart line side AN too, going into an endless link up/down loop. Don't restart PCS AN if link is up already. Although in theory this feedback loop should be possible with the other in-band AN modes too, for some reason it was not seen with the VSC8514 QSGMII and AQR412 USXGMII PHYs. So keep this logic only for SGMII where the problem was found. Fixes: bdeced75b13f ("net: dsa: felix: Add PCS operations for PHYLINK") Suggested-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17net: dsa: felix: Set USXGMII link based on BMSR, not LPAAlex Marginean
At least some PHYs (AQR412) don't advertise copper-side link status during system side AN. So remove this duplicate assignment to pcs->link and rely on the previous one for link state: the local indication from the MAC PCS. Fixes: bdeced75b13f ("net: dsa: felix: Add PCS operations for PHYLINK") Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17Documentation: Fix typo in devlink documentationIdo Schimmel
The driver is named "mlxsw", not "mlx5". Fixes: d4255d75856f ("devlink: document info versions for each driver") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17EDAC/amd64: Do not warn when removing instancesBorislav Petkov
On machines which do not populate all nodes with DIMMs, the driver doesn't initialize an instance there. However, the instance removal remove_one_instance() path will warn unconditionally, which is wrong. Remove the WARN_ON() even if the warning is innocent because it causes a splat in dmesg. Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20200117115939.5524-1-bp@alien8.de
2020-01-17enetc: Don't print from enetc_sched_speed_set when link goes downVladimir Oltean
It is not an error to unplug a cable from the ENETC port even with TSN offloads, so don't spam the log with link-related messages from the tc-taprio offload subsystem, a single notification is sufficient: [10972.351859] fsl_enetc 0000:00:00.0 eno0: Qbv PSPEED set speed link down. [10972.360241] fsl_enetc 0000:00:00.0 eno0: Link is Down Fixes: 2e47cb415f0a ("enetc: update TSN Qbv PSPEED set according to adjust link speed") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17ALSA: hda/realtek - Add Headset Mic supported for HP cPCKailang Yang
HP ALC671 need to support Headset Mic. Signed-off-by: Kailang Yang <kailang@realtek.com> Link: https://lore.kernel.org/r/06a9d2b176e14706976d6584cbe2d92a@realtek.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-01-17USB: serial: garmin_gps: Use flexible-array memberGustavo A. R. Silva
Old code in the kernel uses 1-byte and 0-byte arrays to indicate the presence of a "variable length array": struct something { int length; u8 data[1]; }; struct something *instance; instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL); instance->length = size; memcpy(instance->data, source, size); There is also 0-byte arrays. Both cases pose confusion for things like sizeof(), CONFIG_FORTIFY_SOURCE, etc.[1] Instead, the preferred mechanism to declare variable-length types such as the one above is a flexible array member[2] which need to be the last member of a structure and empty-sized: struct something { int stuff; u8 data[]; }; Also, by making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being unadvertenly introduced[3] to the codebase from now on. [1] https://github.com/KSPP/linux/issues/21 [2] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2020-01-17net: phy: adin: const-ify static dataAlexandru Ardelean
Some bits of static data should have been made const from the start. This change adds the const qualifier where appropriate. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17net: phy: dp83867: Set FORCE_LINK_GOOD to default after resetMichael Grzeschik
According to the Datasheet this bit should be 0 (Normal operation) in default. With the FORCE_LINK_GOOD bit set, it is not possible to get a link. This patch sets FORCE_LINK_GOOD to the default value after resetting the phy. Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17perf/x86/intel/uncore: Remove PCIe3 unit for SNRKan Liang
The PCIe Root Port driver for CPU Complex PCIe Root Ports are not loaded on SNR. The device ID for SNR PCIe3 unit is used by both uncore driver and the PCIe Root Port driver. If uncore driver is loaded, the PCIe Root Port driver never be probed. Remove the PCIe3 unit for SNR for now. The support for PCIe3 unit will be added later separately. Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lkml.kernel.org/r/20200116200210.18937-2-kan.liang@linux.intel.com
2020-01-17perf/x86/intel/uncore: Fix missing marker for snr_uncore_imc_freerunning_eventsKan Liang
An Oops during the boot is found on some SNR machines. It turns out this is because the snr_uncore_imc_freerunning_events[] array was missing an end-marker. Fixes: ee49532b38dd ("perf/x86/intel/uncore: Add IMC uncore support for Snow Ridge") Reported-by: Like Xu <like.xu@linux.intel.com> Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Tested-by: Like Xu <like.xu@linux.intel.com> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20200116200210.18937-1-kan.liang@linux.intel.com
2020-01-17perf/x86/intel/uncore: Add PCI ID of IMC for Xeon E3 V5 FamilyKan Liang
The IMC uncore support is missed for E3-1585 v5 CPU. Intel Xeon E3 V5 Family has Sky Lake CPU. Add the PCI ID of IMC for Intel Xeon E3 V5 Family. Reported-by: Rosales-fernandez, Carlos <carlos.rosales-fernandez@intel.com> Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Tested-by: Rosales-fernandez, Carlos <carlos.rosales-fernandez@intel.com> Link: https://lkml.kernel.org/r/1578687311-158748-1-git-send-email-kan.liang@linux.intel.com
2020-01-17perf: Correctly handle failed perf_get_aux_event()Mark Rutland
Vince reports a worrying issue: | so I was tracking down some odd behavior in the perf_fuzzer which turns | out to be because perf_even_open() sometimes returns 0 (indicating a file | descriptor of 0) even though as far as I can tell stdin is still open. ... and further the cause: | error is triggered if aux_sample_size has non-zero value. | | seems to be this line in kernel/events/core.c: | | if (perf_need_aux_event(event) && !perf_get_aux_event(event, group_leader)) | goto err_locked; | | (note, err is never set) This seems to be a thinko in commit: ab43762ef010967e ("perf: Allow normal events to output AUX data") ... and we should probably return -EINVAL here, as this should only happen when the new event is mis-configured or does not have a compatible aux_event group leader. Fixes: ab43762ef010967e ("perf: Allow normal events to output AUX data") Reported-by: Vince Weaver <vincent.weaver@maine.edu> Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Tested-by: Vince Weaver <vincent.weaver@maine.edu>
2020-01-17USB: serial: opticon: stop all I/O on close()Johan Hovold
Make sure to stop any submitted write URBs on close(). Note that the tty layer will wait up to 30 seconds for the buffers to drain before close() is called. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2020-01-17USB: serial: opticon: add chars_in_buffer() implementationJohan Hovold
Add a chars_in_buffer() implementation so that the tty layer will wait for outgoing buffered data to be drained when needed (e.g. on final close()). Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2020-01-17drivers/net: netdevsim depends on INETHongbo Yao
If CONFIG_INET is not set and CONFIG_NETDEVSIM=y. Building drivers/net/netdevsim/fib.o will get the following error: drivers/net/netdevsim/fib.o: In function `nsim_fib4_rt_hw_flags_set': fib.c:(.text+0x12b): undefined reference to `fib_alias_hw_flags_set' drivers/net/netdevsim/fib.o: In function `nsim_fib4_rt_destroy': fib.c:(.text+0xb11): undefined reference to `free_fib_info' Correct the Kconfig for netdevsim. Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: 48bb9eb47b270 ("netdevsim: fib: Add dummy implementation for FIB offload") Signed-off-by: Hongbo Yao <yaohongbo@huawei.com> Acked-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17Merge tag 'devfreq-next-for-5.6' of ↵Rafael J. Wysocki
git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux Pull devfreq updates for v5.6 from Chanwoo Choi: "1. Update devfreq core - Add new 'name' attribute of sysfs to show the device name : /sys/class/devfreq/devfreqX/name - Make 'trans_stat' sysfs reset by entering zero(0) : echo 0 > /sys/class/devfreq/devfreqX/trans_stat - Add debugfs support with 'devfreq_summary' to show the summary : /sys/kernel/debug/devfreq/devfreq_summary - Change the type of time variable to 64bit to avoid overflows. - Make separate devfreq_stats including the statistics information. - Fix minor coding-style like indentation and kernel-doc warnings. 2. Update devfreq drivers - Add new imx8m-ddrc.c devfreq driver for dynamic scaling of DDR frequency. It changes the DDR frequency by using ARM SMCCC(SMC Calling Convention) interface to control TF-A firmware. - Add COMPILE_TEST dependency for rk3399_dmc.c. - Clean-up code for exynos-bus.c and rk3399_dmc.c without behavior changes 3. Update devfreq-event drivers - Fix excessive stack usage of exynos-ppmu.c and clean-up code of rockchip-dfi.c without behavior changes." * tag 'devfreq-next-for-5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux: (24 commits) PM / devfreq: Add debugfs support with devfreq_summary file PM / devfreq: exynos: Rename Exynos to lowercase PM / devfreq: imx8m-ddrc: Fix inconsistent IS_ERR and PTR_ERR PM / devfreq: exynos-bus: Add error log when fail to get devfreq-event PM / devfreq: exynos-bus: Disable devfreq-event device when fails PM / devfreq: rk3399_dmc: Disable devfreq-event device when fails PM / devfreq: imx8m-ddrc: Remove unused defines PM / devfreq: exynos-bus: Reduce goto statements and remove unused headers PM / devfreq: rk3399_dmc: Add COMPILE_TEST and HAVE_ARM_SMCCC dependency PM / devfreq: rockchip-dfi: Convert to devm_platform_ioremap_resource PM / devfreq: rk3399_dmc: Add missing of_node_put() PM / devfreq: rockchip-dfi: Add missing of_node_put() PM / devfreq: Fix multiple kernel-doc warnings PM / devfreq: exynos-bus: Extract exynos_bus_profile_init_passive() PM / devfreq: exynos-bus: Extract exynos_bus_profile_init() PM / devfreq: Move declaration of DEVICE_ATTR_RW(min_freq) PM / devfreq: Move statistics to separate struct devfreq_stats PM / devfreq: Add clearing transitions stats PM / devfreq: Change time stats to 64-bit PM / devfreq: Add new name attribute for sysfs ...
generated by cgit (git 2.34.1) at 2025-09-19 06:08:48 +0000