summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-07-04drm/bridge: fsl-ldb: Enable split mode for LVDS dual linkLiu Ying
When LVDS dual link is used, we have to enable the LDB_CTRL_SPLIT_MODE bit. Fixes: 463db5c2ed4a ("drm: bridge: ldb: Implement simple Freescale i.MX8MP LDB bridge") Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec@gmail.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Marek Vasut <marex@denx.de> Cc: NXP Linux Team <linux-imx@nxp.com> Signed-off-by: Liu Ying <victor.liu@nxp.com> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220701065634.4027537-3-victor.liu@nxp.com
2022-07-04drm/bridge: fsl-ldb: Fix mode clock rate validationLiu Ying
With LVDS dual link, up to 160MHz mode clock rate is supported. With LVDS single link, up to 80MHz mode clock rate is supported. Fix mode clock rate validation by swapping the maximum mode clock rates of the two link modes. Fixes: 463db5c2ed4a ("drm: bridge: ldb: Implement simple Freescale i.MX8MP LDB bridge") Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec@gmail.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Marek Vasut <marex@denx.de> Cc: NXP Linux Team <linux-imx@nxp.com> Signed-off-by: Liu Ying <victor.liu@nxp.com> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220701065634.4027537-2-victor.liu@nxp.com
2022-07-04Merge tag 'omap-for-v5.20/soc-signed' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/soc SoC changes omaps for v5.20 merge window SoC changes omaps mostly for missing of_node_put() calls and cosmetic Kconfig changes. These can be all merged when suitable, there is no urgent need to merge this as fixes. * tag 'omap-for-v5.20/soc-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: OMAP2+: Kconfig: Fix indentation ARM: OMAP2+: Fix refcount leak in omap3xxx_prm_late_init ARM: OMAP2+: pdata-quirks: Fix refcount leak bug ARM: OMAP2+: display: Fix refcount leak bug ARM: OMAP2+: Fix refcount leak in omapdss_init_of Link: https://lore.kernel.org/r/pull-1656918583-2801@atomide.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-07-04firmware: arm_scmi: Use fast channel tracingCristian Marussi
Make use of SCMI fast channel event tracing. Link: https://lore.kernel.org/r/20220704102241.2988447-7-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-07-04include: trace: Add SCMI fast channel tracingCristian Marussi
All the currently defined SCMI events are meant to trace only regular SCMI transfers based on SCMI messages exchanges; SCMI transactions based on fast channels, where used, are completely invisible from the tracing point of view. Add support to trace fast channel transactions; while doing that avoid exposing full shared memory location addresses. Link: https://lore.kernel.org/r/20220704102241.2988447-6-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-07-04firmware: arm_scmi: Add SCMI v3.1 powercap fast channels supportCristian Marussi
Add SCMIv3.1 powercap protocol fast channel support using common helpers provided by the SCMI core with scmi_proto_helpers_ops operations. Link: https://lore.kernel.org/r/20220704102241.2988447-5-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-07-04firmware: arm_scmi: Generalize the fast channel supportCristian Marussi
Generalize existing fast channel support used in the perf protocol and make it available to possibly any protocol refactoring the common code into a couple of new scmi_proto_helpers_ops routines. Make perf protocol use this new infrastructure. No functional change. Link: https://lore.kernel.org/r/20220704102241.2988447-4-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-07-04firmware: arm_scmi: Add SCMI v3.1 powercap protocol basic supportCristian Marussi
Add support for SCMI v3.1 powercap protocol, with the exception of powercap fast channels, exposing all the new related powercap protocol operations as usual in include/linux/scmi_protocol.h. Link: https://lore.kernel.org/r/20220704102241.2988447-3-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-07-04dt-bindings: firmware: arm,scmi: Add support for powercap protocolCristian Marussi
Add new SCMI v3.1 powercap protocol bindings definitions and example. Link: https://lore.kernel.org/r/20220704102241.2988447-2-cristian.marussi@arm.com Cc: Rob Herring <robh+dt@kernel.org> Cc: devicetree@vger.kernel.org Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-07-04firmware: arm_scmi: Add SCMI System Power Control driverCristian Marussi
Add an SCMI System Power control driver to handle platform's requests carried by SYSTEM_POWER_STATE_NOTIFIER notifications: such platform requested system-wide power state transitions are handled accordingly, gracefully or forcefully, depending on the notifications' message flags. Graceful requests are relayed to userspace using the same Kernel API used to handle ACPI Shutdown bus events. Link: https://lore.kernel.org/r/20220704101933.2981635-5-cristian.marussi@arm.com Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-07-04firmware: arm_scmi: Add devm_protocol_acquire helperCristian Marussi
Add a method to get hold of a protocol, causing it to be initialized and its resource accounting updated, without getting access to its operations and handle. Some protocols, like SCMI SystemPower, do not expose any protocol ops to the kernel OSPM agent but still need to be at least initialized. This helper avoids the need to invoke a full devm_get_protocol() only to get the protocol initialized while throwing away unused the protocol ops and handle. Link: https://lore.kernel.org/r/20220704101933.2981635-4-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-07-04firmware: arm_scmi: Add SCMI v3.1 System Power extensionsCristian Marussi
Add support for SCMIv3.1 System Power optional timeout field while dispatching SYSTEM_POWER_STATE_NOTIFIER notification. Link: https://lore.kernel.org/r/20220704101933.2981635-3-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-07-04firmware: arm_scmi: Support only one single system power deviceCristian Marussi
In order to minimize SCMI platform fw-side complexity, only one single SCMI platform should be in charge of SCMI SystemPower protocol communications with the OSPM. Enforce the existence of one single unique device associated with SystemPower protocol across any possible number of SCMI platforms, and warn if a system tries to register different SystemPower devices from multiple platforms. Link: https://lore.kernel.org/r/20220704101933.2981635-2-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-07-04firmware: arm_scmi: Use new SCMI full message tracingCristian Marussi
Add full message tracing for all transmitted and successfully received SCMI commands, replies and notifications. Link: https://lore.kernel.org/r/20220630173135.2086631-3-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-07-04include: trace: Add SCMI full message tracingCristian Marussi
Add a distinct trace event to dump full SCMI message headers and payloads. Link: https://lore.kernel.org/r/20220630173135.2086631-2-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-07-04firmware: arm_scpi: Ensure scpi_info is not assigned if the probe failsSudeep Holla
When scpi probe fails, at any point, we need to ensure that the scpi_info is not set and will remain NULL until the probe succeeds. If it is not taken care, then it could result use-after-free as the value is exported via get_scpi_ops() and could refer to a memory allocated via devm_kzalloc() but freed when the probe fails. Link: https://lore.kernel.org/r/20220701160310.148344-1-sudeep.holla@arm.com Cc: stable@vger.kernel.org # 4.19+ Reported-by: huhai <huhai@kylinos.cn> Reviewed-by: Jackie Liu <liuyun01@kylinos.cn> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-07-04Merge tag 'omap-for-v5.20/dt-signed' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/dt Devicetree changes omaps for v5.20 merge window Just one devicetree change to add EEPROM regulator for BeagleBone Black. * tag 'omap-for-v5.20/dt-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: dts: am33xx: Map baseboard EEPROM on BeagleBone Black Link: https://lore.kernel.org/r/pull-1656918942-515224@atomide.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-07-04Merge tag 'stm32-dt-for-v5.19-fixes-2' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32 into arm/fixes STM32 DT fixes for v5.19, round 2 Highlights: ----------- -Fixes STM32MP15: - Add missing usbh clock and fix clk order for usbh to avoid PLL issue. - Fix SCMI version: use scmi regulator and update missing SCMI clocks to be able to correcly boot. * tag 'stm32-dt-for-v5.19-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32: ARM: dts: stm32: add missing usbh clock and fix clk order on stm32mp15 ARM: dts: stm32: delete fixed clock node on STM32MP15-SCMI ARM: dts: stm32: DSI should use LSE SCMI clock on DK1/ED1 STM32 board ARM: dts: stm32: use the correct clock source for CEC on stm32mp151 ARM: dts: stm32: fix pwr regulators references to use scmi Link: https://lore.kernel.org/r/1259e082-a3a4-96a5-ec9c-05dbb893a746@foss.st.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-07-04soc: qcom: smem: use correct format charactersBill Wendling
When compiling with -Wformat, clang emits the following warnings: drivers/soc/qcom/smem.c:847:41: warning: format specifies type 'unsigned short' but the argument has type 'unsigned int' [-Wformat] dev_err(smem->dev, "bad host %hu\n", remote_host); ~~~ ^~~~~~~~~~~ %u ./include/linux/dev_printk.h:144:65: note: expanded from macro 'dev_err' dev_printk_index_wrap(_dev_err, KERN_ERR, dev, dev_fmt(fmt), ##__VA_ARGS__) ~~~ ^~~~~~~~~~~ ./include/linux/dev_printk.h:110:23: note: expanded from macro 'dev_printk_index_wrap' _p_func(dev, fmt, ##__VA_ARGS__); \ ~~~ ^~~~~~~~~~~ drivers/soc/qcom/smem.c:852:47: warning: format specifies type 'unsigned short' but the argument has type 'unsigned int' [-Wformat] dev_err(smem->dev, "duplicate host %hu\n", remote_host); ~~~ ^~~~~~~~~~~ %u ./include/linux/dev_printk.h:144:65: note: expanded from macro 'dev_err' dev_printk_index_wrap(_dev_err, KERN_ERR, dev, dev_fmt(fmt), ##__VA_ARGS__) ~~~ ^~~~~~~~~~~ ./include/linux/dev_printk.h:110:23: note: expanded from macro 'dev_printk_index_wrap' _p_func(dev, fmt, ##__VA_ARGS__); \ ~~~ ^~~~~~~~~~~ The types of these arguments are unconditionally defined, so this patch updates the format character to the correct one and change type of remote_host to "u16" to match with other types. Signed-off-by: Bill Wendling <morbo@google.com> Tested-by: Justin Stitt <jstitt007@gmail.com> Reviewed-by: Justin Stitt <jstitt007@gmail.com> Link: https://github.com/ClangBuiltLinux/linux/issues/378 Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-07-04Merge tag 'asoc-fix-v5.19-rc3' of ↵Takashi Iwai
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v5.19 A collection of fixes for v5.19, quite large but nothing major - a good chunk of it is more stuff that was identified by mixer-test regarding event generation.
2022-07-04ALSA: usb-audio: Add quirk for Fiero SC-01 (fw v1.0.0)Egor Vorontsov
The patch applies the same quirks used for SC-01 at firmware v1.1.0 to the ones running v1.0.0, with respect to hard-coded sample rates. I got two more units and successfully tested the patch series with both firmwares. The support is now complete (not accounting ASIO). Signed-off-by: Egor Vorontsov <sdoregor@sdore.me> Link: https://lore.kernel.org/r/20220627100041.2861494-2-sdoregor@sdore.me Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-07-04ALSA: usb-audio: Add quirk for Fiero SC-01Egor Vorontsov
Fiero SC-01 is a USB sound card with two mono inputs and a single stereo output. The inputs are composed into a single stereo stream. The device uses a vendor-provided driver on Windows and does not work at all without it. The driver mostly provides ASIO functionality, but also alters the way the sound card is queried for sample rates and clocks. ALSA queries those failing with an EPIPE (same as Windows 10 does). Presumably, the vendor-provided driver does not query it at all, simply matching by VID:PID. Thus, I consider this a buggy firmware and adhere to a set of fixed endpoint quirks instead. The soundcard has an internal clock. Implicit feedback mode is required for the playback. I have updated my device to v1.1.0 from a Windows 10 VM using a vendor- provided binary prior to the development, hoping for it to just begin working. The device provides no obvious way to downgrade the firmware, and regardless, there's no binary available for v1.0.0 anyway. Thus, I will be getting another unit to extend the patch with support for that. Expected to be a simple copy-paste of the existing one, though. There were no previous reports of that device in context of Linux anywhere. Other issues have been reported though, but that's out of the scope. Signed-off-by: Egor Vorontsov <sdoregor@sdore.me> Link: https://lore.kernel.org/r/20220627100041.2861494-1-sdoregor@sdore.me Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-07-04ALSA: hda/realtek: Add quirk for Clevo L140PUTim Crawford
Fixes headset detection on Clevo L140PU. Signed-off-by: Tim Crawford <tcrawford@system76.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220624144109.3957-1-tcrawford@system76.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-07-04ALSA: usb-audio: Add quirks for MacroSilicon MS2100/MS2106 devicesJohn Veness
Treat the claimed 96kHz 1ch in the descriptors as 48kHz 2ch, so that the audio stream doesn't sound mono. Also fix initial stream alignment, so that left and right channels are in the correct order. Signed-off-by: John Veness <john-linux@pelago.org.uk> Link: https://lore.kernel.org/r/20220624140757.28758-1-john-linux@pelago.org.uk Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-07-04drm/aperture: Run fbdev removal before internal helpersThomas Zimmermann
Always run fbdev removal first to remove simpledrm via sysfb_disable(). This clears the internal state. The later call to drm_aperture_detach_drivers() then does nothing. Otherwise, with drm_aperture_detach_drivers() running first, the call to sysfb_disable() uses inconsistent state. Example backtrace show below: [ 11.663422] ================================================================== [ 11.663426] BUG: KASAN: use-after-free in device_del+0x79/0x5f0 [ 11.663435] Read of size 8 at addr ffff888108185050 by task systemd-udevd/311 [ 11.663440] CPU: 0 PID: 311 Comm: systemd-udevd Tainted: G E 5 .19.0-rc2-1-default+ #1689 [ 11.663445] Hardware name: HP ProLiant DL120 G7, BIOS J01 04/21/2011 [ 11.663447] Call Trace: [ 11.663449] <TASK> [ 11.663451] ? device_del+0x79/0x5f0 [ 11.663456] dump_stack_lvl+0x5b/0x73 [ 11.663462] print_address_description.constprop.0+0x1f/0x1b0 [ 11.663468] ? device_del+0x79/0x5f0 [ 11.663471] ? device_del+0x79/0x5f0 [ 11.663475] print_report.cold+0x3c/0x21c [ 11.663481] ? lock_acquired+0x87/0x1e0 [ 11.663484] ? lock_acquired+0x87/0x1e0 [ 11.663489] ? device_del+0x79/0x5f0 [ 11.663492] kasan_report+0xbf/0xf0 [ 11.663498] ? device_del+0x79/0x5f0 [ 11.663503] device_del+0x79/0x5f0 [ 11.663509] ? device_remove_attrs+0x170/0x170 [ 11.663514] ? lock_is_held_type+0xe8/0x140 [ 11.663523] platform_device_del.part.0+0x19/0xe0 [ 11.663530] platform_device_unregister+0x1c/0x30 [ 11.663535] sysfb_disable+0x2d/0x70 [ 11.663540] remove_conflicting_framebuffers+0x1c/0xf0 [ 11.663546] remove_conflicting_pci_framebuffers+0x130/0x1a0 [ 11.663554] drm_aperture_remove_conflicting_pci_framebuffers+0x86/0xb0 [ 11.663561] ? mgag200_pci_remove+0x30/0x30 [mgag200] [ 11.663578] mgag200_pci_probe+0x2d/0x140 [mgag200] Reported-by: Zack Rusin <zackr@vmware.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Zack Rusin <zackr@vmware.com> Fixes: ee7a69aa38d8 ("fbdev: Disable sysfb device registration when removing conflicting FBs") Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Helge Deller <deller@gmx.de> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Zhen Lei <thunder.leizhen@huawei.com> Cc: Changcheng Deng <deng.changcheng@zte.com.cn> Link: https://patchwork.freedesktop.org/patch/msgid/20220617121027.30273-1-tzimmermann@suse.de (cherry picked from commit fb84efa28a48e30b87fa1122e8aab8016c7347cd) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2022-07-04arm64: fix oops in concurrently setting insn_emulation sysctlshaibinzhang (张海斌)
emulation_proc_handler() changes table->data for proc_dointvec_minmax and can generate the following Oops if called concurrently with itself: | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 | Internal error: Oops: 96000006 [#1] SMP | Call trace: | update_insn_emulation_mode+0xc0/0x148 | emulation_proc_handler+0x64/0xb8 | proc_sys_call_handler+0x9c/0xf8 | proc_sys_write+0x18/0x20 | __vfs_write+0x20/0x48 | vfs_write+0xe4/0x1d0 | ksys_write+0x70/0xf8 | __arm64_sys_write+0x20/0x28 | el0_svc_common.constprop.0+0x7c/0x1c0 | el0_svc_handler+0x2c/0xa0 | el0_svc+0x8/0x200 To fix this issue, keep the table->data as &insn->current_mode and use container_of() to retrieve the insn pointer. Another mutex is used to protect against the current_mode update but not for retrieving insn_emulation as table->data is no longer changing. Co-developed-by: hewenliang <hewenliang4@huawei.com> Signed-off-by: hewenliang <hewenliang4@huawei.com> Signed-off-by: Haibin Zhang <haibinzhang@tencent.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20220128090324.2727688-1-hewenliang4@huawei.com Link: https://lore.kernel.org/r/9A004C03-250B-46C5-BF39-782D7551B00E@tencent.com Signed-off-by: Will Deacon <will@kernel.org>
2022-07-04powerpc/powernv: delay rng platform device creation until later in bootJason A. Donenfeld
The platform device for the rng must be created much later in boot. Otherwise it tries to connect to a parent that doesn't yet exist, resulting in this splat: [ 0.000478] kobject: '(null)' ((____ptrval____)): is not initialized, yet kobject_get() is being called. [ 0.002925] [c000000002a0fb30] [c00000000073b0bc] kobject_get+0x8c/0x100 (unreliable) [ 0.003071] [c000000002a0fba0] [c00000000087e464] device_add+0xf4/0xb00 [ 0.003194] [c000000002a0fc80] [c000000000a7f6e4] of_device_add+0x64/0x80 [ 0.003321] [c000000002a0fcb0] [c000000000a800d0] of_platform_device_create_pdata+0xd0/0x1b0 [ 0.003476] [c000000002a0fd00] [c00000000201fa44] pnv_get_random_long_early+0x240/0x2e4 [ 0.003623] [c000000002a0fe20] [c000000002060c38] random_init+0xc0/0x214 This patch fixes the issue by doing the platform device creation inside of machine_subsys_initcall. Fixes: f3eac426657d ("powerpc/powernv: wire up rng during setup_arch") Cc: stable@vger.kernel.org Reported-by: Sachin Sant <sachinp@linux.ibm.com> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Tested-by: Sachin Sant <sachinp@linux.ibm.com> [mpe: Change "of node" to "platform device" in change log] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220630121654.1939181-1-Jason@zx2c4.com
2022-07-04soc: bcm: bcm2835-power: Bypass power_on/off() callsNicolas Saenz Julienne
Bypass power_on/power_off() when running on BCM2711 as they are not needed. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20220625113619.15944-12-stefan.wahren@i2se.com
2022-07-04soc: bcm: bcm2835-power: Add support for BCM2711's RPiVid ASBStefan Wahren
In BCM2711 the new RPiVid ASB took over V3D. The old ASB is still present with the ISP and H264 bits, and V3D is in the same place in the new ASB as the old one. Use the fact that 'pm->rpivid_asb' is populated as a hint that we're on BCM2711. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20220625113619.15944-11-stefan.wahren@i2se.com
2022-07-04soc: bcm: bcm2835-power: Resolve ASB register macrosStefan Wahren
The macros in order to access the ASB registers have a hard coded base address. So extending them for other platforms would make them harder to read. As a solution resolve these macros. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20220625113619.15944-10-stefan.wahren@i2se.com
2022-07-04soc: bcm: bcm2835-power: Refactor ASB controlStefan Wahren
The functions to control the async AXI bridges are almost identical. So define a general function to handle it and keep the original ones as wrapper. This should make this driver easier to extend. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20220625113619.15944-9-stefan.wahren@i2se.com
2022-07-04can: mcp251xfd: mcp251xfd_register_get_dev_id(): fix endianness conversionMarc Kleine-Budde
In mcp251xfd_register_get_dev_id() the device ID register is read with handcrafted SPI transfers. As all registers, this register is in little endian. Further it is not naturally aligned in struct mcp251xfd_map_buf_nocrc::data. However after the transfer the register content is converted from big endian to CPU endianness not taking care of being unaligned. Fix the conversion by converting from little endian to CPU endianness taking the unaligned source into account. Side note: So far the register content is 0x0 on all mcp251xfd compatible chips, and is only used for an informative printk. Link: https://lore.kernel.org/all/20220627092859.809042-1-mkl@pengutronix.de Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Reviewed-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-04can: mcp251xfd: mcp251xfd_register_get_dev_id(): use correct length to read ↵Marc Kleine-Budde
dev_id The device ID register is 32 bits wide. The driver uses incorrectly the size of a pointer to a u32 to calculate the length of the SPI transfer. This results in a read of 2 registers on 64 bit platforms. This is no problem on the Linux side, as the RX buffer of the SPI transfer is large enough. In the mpc251xfd chip this results in the read of an undocumented register. So far no problems were observed. Fix the length of the SPI transfer to read the device ID register only. Link: https://lore.kernel.org/all/20220616094914.244440-1-mkl@pengutronix.de Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Reported-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-04can: mcp251xfd: mcp251xfd_stop(): add missing hrtimer_cancel()Marc Kleine-Budde
In commit 169d00a25658 ("can: mcp251xfd: add TX IRQ coalescing support") software based TX coalescing was added to the driver. The key idea is to keep the TX complete IRQ disabled for some time after processing it and re-enable later by a hrtimer. When bringing the interface down, this timer has to be stopped. Add the missing hrtimer_cancel() of the tx_irq_time hrtimer to mcp251xfd_stop(). Link: https://lore.kernel.org/all/20220620143942.891811-1-mkl@pengutronix.de Fixes: 169d00a25658 ("can: mcp251xfd: add TX IRQ coalescing support") Cc: stable@vger.kernel.org # v5.18 Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-04can: mcp251xfd: mcp251xfd_regmap_crc_read(): update workaround broken CRC on ↵Thomas Kopp
TBC register The mcp251xfd compatible chips have an erratum ([1], [2]), where the received CRC doesn't match the calculated CRC. In commit c7eb923c3caf ("can: mcp251xfd: mcp251xfd_regmap_crc_read(): work around broken CRC on TBC register") the following workaround was implementierend. - If a CRC read error on the TBC register is detected and the first byte is 0x00 or 0x80, the most significant bit of the first byte is flipped and the CRC is calculated again. - If the CRC now matches, the _original_ data is passed to the reader. For now we assume transferred data was OK. New investigations and simulations indicate that the CRC send by the device is calculated on correct data, and the data is incorrectly received by the SPI host controller. Use flipped instead of original data and update workaround description in mcp251xfd_regmap_crc_read(). [1] mcp2517fd: DS80000792C: "Incorrect CRC for certain READ_CRC commands" [2] mcp2518fd: DS80000789C: "Incorrect CRC for certain READ_CRC commands" Link: https://lore.kernel.org/all/DM4PR11MB53901D49578FE265B239E55AFB7C9@DM4PR11MB5390.namprd11.prod.outlook.com Fixes: c7eb923c3caf ("can: mcp251xfd: mcp251xfd_regmap_crc_read(): work around broken CRC on TBC register") Cc: stable@vger.kernel.org Signed-off-by: Thomas Kopp <thomas.kopp@microchip.com> [mkl: split into 2 patches, update patch description and documentation] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-04can: mcp251xfd: mcp251xfd_regmap_crc_read(): improve workaround handling for ↵Thomas Kopp
mcp2517fd The mcp251xfd compatible chips have an erratum ([1], [2]), where the received CRC doesn't match the calculated CRC. In commit c7eb923c3caf ("can: mcp251xfd: mcp251xfd_regmap_crc_read(): work around broken CRC on TBC register") the following workaround was implementierend. - If a CRC read error on the TBC register is detected and the first byte is 0x00 or 0x80, the most significant bit of the first byte is flipped and the CRC is calculated again. - If the CRC now matches, the _original_ data is passed to the reader. For now we assume transferred data was OK. Measurements on the mcp2517fd show that the workaround is applicable not only of the lowest byte is 0x00 or 0x80, but also if 3 least significant bits are set. Update check on 1st data byte and workaround description accordingly. [1] mcp2517fd: DS80000792C: "Incorrect CRC for certain READ_CRC commands" [2] mcp2518fd: DS80000789C: "Incorrect CRC for certain READ_CRC commands" Link: https://lore.kernel.org/all/DM4PR11MB53901D49578FE265B239E55AFB7C9@DM4PR11MB5390.namprd11.prod.outlook.com Fixes: c7eb923c3caf ("can: mcp251xfd: mcp251xfd_regmap_crc_read(): work around broken CRC on TBC register") Cc: stable@vger.kernel.org Reported-by: Pavel Modilaynen <pavel.modilaynen@volvocars.com> Signed-off-by: Thomas Kopp <thomas.kopp@microchip.com> [mkl: split into 2 patches, update patch description and documentation] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-04can: kvaser_usb: kvaser_usb_leaf: fix bittiming limitsJimmy Assarsson
Use correct bittiming limits depending on device. For devices based on USBcanII, Leaf M32C or Leaf i.MX28. Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices") Fixes: b4f20130af23 ("can: kvaser_usb: add support for Kvaser Leaf v2 and usb mini PCIe") Fixes: f5d4abea3ce0 ("can: kvaser_usb: Add support for the USBcan-II family") Link: https://lore.kernel.org/all/20220603083820.800246-4-extja@kvaser.com Cc: stable@vger.kernel.org Signed-off-by: Jimmy Assarsson <extja@kvaser.com> [mkl: remove stray netlink.h include] [mkl: keep struct can_bittiming_const kvaser_usb_flexc_bittiming_const in kvaser_usb_hydra.c] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-04mfd: bcm2835-pm: Add support for BCM2711Stefan Wahren
In BCM2711 the new RPiVid ASB took over V3D. The old ASB is still present with the ISP and H264 bits, and V3D is in the same place in the new ASB as the old one. As per the devicetree bindings, BCM2711 will provide both the old and new ASB resources, so get both of them and pass them into 'bcm2835-power,' which will take care of selecting which one to use accordingly. Since the RPiVid ASB's resources were being provided prior to formalizing the bindings[1], also support the old DT files that didn't use 'reg-names.' [1] See: 7dbe8c62ceeb ("ARM: dts: Add minimal Raspberry Pi 4 support") Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20220625113619.15944-8-stefan.wahren@i2se.com
2022-07-04can: kvaser_usb: kvaser_usb_leaf: fix CAN clock frequency regressionJimmy Assarsson
The firmware of M32C based Leaf devices expects bittiming parameters calculated for 16MHz clock. Since we use the actual clock frequency of the device, the device may end up with wrong bittiming parameters, depending on user requested parameters. This regression affects M32C based Leaf devices with non-16MHz clock. Fixes: fb12797ab1fe ("can: kvaser_usb: get CAN clock frequency from device") Link: https://lore.kernel.org/all/20220603083820.800246-3-extja@kvaser.com Cc: stable@vger.kernel.org Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-04mfd: bcm2835-pm: Use 'reg-names' to get resourcesNicolas Saenz Julienne
If available in firmware, find resources by their 'reg-names' position instead of relying on hardcoded offsets. Care is taken to support old firmware nonetheless. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20220625113619.15944-7-stefan.wahren@i2se.com
2022-07-04can: kvaser_usb: replace run-time checks with struct kvaser_usb_driver_infoJimmy Assarsson
Unify and move compile-time known information into new struct kvaser_usb_driver_info, in favor of run-time checks. All Kvaser USBcanII supports listen-only mode and error counter reporting. Link: https://lore.kernel.org/all/20220603083820.800246-2-extja@kvaser.com Suggested-by: Marc Kleine-Budde <mkl@pengutronix.de> Cc: stable@vger.kernel.org Signed-off-by: Jimmy Assarsson <extja@kvaser.com> [mkl: move struct kvaser_usb_driver_info into kvaser_usb_core.c] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-04ibmvnic: Properly dispose of all skbs during a failover.Rick Lindsley
During a reset, there may have been transmits in flight that are no longer valid and cannot be fulfilled. Resetting and clearing the queues is insufficient; each skb also needs to be explicitly freed so that upper levels are not left waiting for confirmation of a transmit that will never happen. If this happens frequently enough, the apparent backlog will cause TCP to begin "congestion control" unnecessarily, culminating in permanently decreased throughput. Fixes: d7c0ef36bde03 ("ibmvnic: Free and re-allocate scrqs when tx/rx scrqs change") Tested-by: Nick Child <nnac123@linux.ibm.com> Reviewed-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: Rick Lindsley <ricklind@us.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-04can: m_can: m_can_{read_fifo,echo_tx_event}(): shift timestamp to full 32 bitsMarc Kleine-Budde
In commit 1be37d3b0414 ("can: m_can: fix periph RX path: use rx-offload to ensure skbs are sent from softirq context") the RX path for peripheral devices was switched to RX-offload. Received CAN frames are pushed to RX-offload together with a timestamp. RX-offload is designed to handle overflows of the timestamp correctly, if 32 bit timestamps are provided. The timestamps of m_can core are only 16 bits wide. So this patch shifts them to full 32 bit before passing them to RX-offload. Link: https://lore.kernel.org/all/20220612211410.4081390-1-mkl@pengutronix.de Fixes: 1be37d3b0414 ("can: m_can: fix periph RX path: use rx-offload to ensure skbs are sent from softirq context") Cc: <stable@vger.kernel.org> # 5.13 Cc: Torin Cooper-Bennun <torin@maxiluxsystems.com> Reviewed-by: Chandrasekar Ramakrishnan <rcsekar@samsung.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-04can: m_can: m_can_chip_config(): actually enable internal timestampingMarc Kleine-Budde
In commit df06fd678260 ("can: m_can: m_can_chip_config(): enable and configure internal timestamps") the timestamping in the m_can core should be enabled. In peripheral mode, the RX'ed CAN frames, TX compete frames and error events are sorted by the timestamp. The above mentioned commit however forgot to enable the timestamping. Add the missing bits to enable the timestamp counter to the write of the Timestamp Counter Configuration register. Link: https://lore.kernel.org/all/20220612212708.4081756-1-mkl@pengutronix.de Fixes: df06fd678260 ("can: m_can: m_can_chip_config(): enable and configure internal timestamps") Cc: <stable@vger.kernel.org> # 5.13 Cc: Torin Cooper-Bennun <torin@maxiluxsystems.com> Reviewed-by: Chandrasekar Ramakrishnan <rcsekar@samsung.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-04can: grcan: grcan_probe(): remove extra of_node_get()Liang He
In grcan_probe(), of_find_node_by_path() has already increased the refcount. There is no need to call of_node_get() again, so remove it. Link: https://lore.kernel.org/all/20220619070257.4067022-1-windhl@126.com Fixes: 1e93ed26acf0 ("can: grcan: grcan_probe(): fix broken system id check for errata workaround needs") Cc: stable@vger.kernel.org # v5.18 Cc: Andreas Larsson <andreas@gaisler.com> Signed-off-by: Liang He <windhl@126.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-04can: gs_usb: gs_usb_open/close(): fix memory leakRhett Aultman
The gs_usb driver appears to suffer from a malady common to many USB CAN adapter drivers in that it performs usb_alloc_coherent() to allocate a number of USB request blocks (URBs) for RX, and then later relies on usb_kill_anchored_urbs() to free them, but this doesn't actually free them. As a result, this may be leaking DMA memory that's been used by the driver. This commit is an adaptation of the techniques found in the esd_usb2 driver where a similar design pattern led to a memory leak. It explicitly frees the RX URBs and their DMA memory via a call to usb_free_coherent(). Since the RX URBs were allocated in the gs_can_open(), we remove them in gs_can_close() rather than in the disconnect function as was done in esd_usb2. For more information, see the 928150fad41b ("can: esd_usb2: fix memory leak"). Link: https://lore.kernel.org/all/alpine.DEB.2.22.394.2206031547001.1630869@thelappy Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Cc: stable@vger.kernel.org Signed-off-by: Rhett Aultman <rhett.aultman@samsara.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-04can: rcar_canfd: Fix data transmission failed on R-Car V3UDuy Nguyen
On R-Car V3U, this driver should use suitable register offset instead of other SoCs' one. Otherwise, data transmission failed on R-Car V3U. Fixes: 45721c406dcf ("can: rcar_canfd: Add support for r8a779a0 SoC") Link: https://lore.kernel.org/all/20220704074611.957191-1-yoshihiro.shimoda.uh@renesas.com Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Duy Nguyen <duy.nguyen.rh@renesas.com> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-04Revert "can: xilinx_can: Limit CANFD brp to 2"Srinivas Neeli
This reverts commit 05ca14fdb6fe65614e0652d03e44b02748d25af7. On early silicon engineering samples observed bit shrinking issue when we use brp as 1. Hence updated brp_min as 2. As in production silicon this issue is fixed, so reverting the patch. Link: https://lore.kernel.org/all/20220609082433.1191060-2-srinivas.neeli@xilinx.com Signed-off-by: Srinivas Neeli <srinivas.neeli@xilinx.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-04Merge branch 'netdev-docs'David S. Miller
Jakub Kicinski says: ==================== docs: netdev: document more of our rules The patch series length limit and reverse xmas tree are not documented. Add those, and a tl;dr section summarizing how we differ. v2: improve the series length blurb (Andrew) ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-04docs: netdev: add a cheat sheet for the rulesJakub Kicinski
Summarize the rules we see broken most often and which may be less familiar to kernel devs who are used to working outside of netdev. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit (git 2.34.1) at 2025-09-24 05:29:26 +0000