summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-06-25arm64: dts: marvell: armada-37xx: Fix reg for standard variant of UARTPali Rohár
UART1 (standard variant with DT node name 'uart0') has register space 0x12000-0x12018 and not whole size 0x200. So fix also this in example. Signed-off-by: Pali Rohár <pali@kernel.org> Fixes: c737abc193d1 ("arm64: dts: marvell: Fix A37xx UART0 register size") Link: https://lore.kernel.org/r/20210624224909.6350-6-pali@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25dt-bindings: mvebu-uart: fix documentationPali Rohár
Both UARTs support higher baudrates and are not limited to baudrate 230400. Only current kernel driver implementation has limitation for both UARTs in maximal baudrate 230400. This limitation will be removed in next patches. So remove incorrect information about (hardware) limitation from bindings. UART1 (standard variant with DT node name 'uart0') has register space 0x12000-0x12018 and not whole size 0x200. So fix also this in example. Signed-off-by: Pali Rohár <pali@kernel.org> Fixes: d160c3413478 ("dt-bindings: mvebu-uart: update documentation with extended UART") Link: https://lore.kernel.org/r/20210624224909.6350-5-pali@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25serial: mvebu-uart: correctly calculate minimal possible baudratePali Rohár
For default (x16) scheme which is currently used by mvebu-uart.c driver, maximal divisor of UART base clock is 1023*16. Therefore there is limit for minimal supported baudrate. This change calculate it correctly and prevents setting invalid divisor 0 into hardware registers. Signed-off-by: Pali Rohár <pali@kernel.org> Fixes: 68a0db1d7da2 ("serial: mvebu-uart: add function to change baudrate") Link: https://lore.kernel.org/r/20210624224909.6350-4-pali@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25serial: mvebu-uart: do not allow changing baudrate when uartclk is not availablePali Rohár
Testing mvuart->clk for non-error is not enough as mvuart->clk may contain valid clk pointer but when clk_prepare_enable(mvuart->clk) failed then port->uartclk is zero. When mvuart->clk is not available then port->uartclk is zero too. Parent clock rate port->uartclk is needed to calculate UART clock divisor and without it is not possible to change baudrate. So fix test condition when it is possible to change baudrate. Signed-off-by: Pali Rohár <pali@kernel.org> Fixes: 68a0db1d7da2 ("serial: mvebu-uart: add function to change baudrate") Link: https://lore.kernel.org/r/20210624224909.6350-3-pali@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25serial: mvebu-uart: fix calculation of clock divisorPali Rohár
The clock divisor should be rounded to the closest value. Signed-off-by: Pali Rohár <pali@kernel.org> Fixes: 68a0db1d7da2 ("serial: mvebu-uart: add function to change baudrate") Cc: stable@vger.kernel.org # 0e4cf69ede87 ("serial: mvebu-uart: clarify the baud rate derivation") Link: https://lore.kernel.org/r/20210624224909.6350-2-pali@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25PCI: aardvark: Fix checking for PIO Non-posted RequestPali Rohár
PIO_NON_POSTED_REQ for PIO_STAT register is incorrectly defined. Bit 10 in register PIO_STAT indicates the response is to a non-posted request. Link: https://lore.kernel.org/r/20210624213345.3617-2-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Marek Behún <kabel@kernel.org> Cc: stable@vger.kernel.org
2021-06-25spi: core: add dma_map_dev for dma deviceVinod Koul
Some controllers like qcom geni need the parent device to be used for dma mapping, so add a dma_map_dev field and let drivers fill this to be used as mapping device Signed-off-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20210625052213.32260-4-vkoul@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2021-06-25spi: convert Xilinx Zynq UltraScale+ MPSoC GQSPI bindings to YAMLNobuhiro Iwamatsu
Convert spi for Xilinx Zynq UltraScale+ MPSoC GQSPI bindings documentation to YAML. Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20210613214317.296667-1-iwamatsu@nigauri.org Signed-off-by: Mark Brown <broonie@kernel.org>
2021-06-25bpfilter: Specify the log level for the kmsg messageGary Lin
Per the kmsg document [0], if we don't specify the log level with a prefix "<N>" in the message string, the default log level will be applied to the message. Since the default level could be warning(4), this would make the log utility such as journalctl treat the message, "Started bpfilter", as a warning. To avoid confusion, this commit adds the prefix "<5>" to make the message always a notice. [0] https://www.kernel.org/doc/Documentation/ABI/testing/dev-kmsg Fixes: 36c4357c63f3 ("net: bpfilter: print umh messages to /dev/kmsg") Reported-by: Martin Loviska <mloviska@suse.com> Signed-off-by: Gary Lin <glin@suse.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Dmitrii Banshchikov <me@ubique.spb.ru> Link: https://lore.kernel.org/bpf/20210623040918.8683-1-glin@suse.com
2021-06-25docs: driver-api: gpio: using-gpio.rst: avoid using ReST :doc:`foo` markupMauro Carvalho Chehab
The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-06-25dt-bindings: gpio: pcf857x: Convert to json-schemaGeert Uytterhoeven
Convert the PCF857x-compatible I/O expanders Device Tree binding documentation to json-schema. Document missing compatible values, properties, and gpio hogs. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-06-25gpio: mxs: Prefer unsigned int to bare use of unsignedJinchao Wang
Fix checkpatch warnings: WARNING: Prefer 'unsigned int' to bare use of 'unsigned' Signed-off-by: Jinchao Wang <wjc@cdjrlc.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-06-25dt-bindings: gpio: stp: convert to json-schemaAleksander Jan Bajkowski
Convert the Lantiq STP Device Tree binding documentation to json-schema. Add the missing pinctrl property to the example. Add missing lantiq,phy3 and lantiq,phy4 bindings for xRX300 and xRX330 SoCs. Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl> Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-06-25gpio: AMD8111 and TQMX86 require HAS_IOPORT_MAPJohannes Berg
Both of these drivers use ioport_map(), so they need to depend on HAS_IOPORT_MAP. Otherwise, they cannot be built even with COMPILE_TEST on architectures without an ioport implementation, such as ARCH=um. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-06-25staging: hi6421-spmi-pmic: cleanup some macrosMauro Carvalho Chehab
Before moving this driver out of staging, cleanup the macros, in order to make the driver clearer. No functional changes. Suggested-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/95341999de15b395242b5b7850ec5e727420ce19.1624606660.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25staging: hi6421-spmi-pmic: change identation of a tableMauro Carvalho Chehab
The struct regmap_config is idented with two tabs. Just one tab is enough. Suggested-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/a4d718b0479e3867bedc93861e4b2c9c1321aabd.1624606660.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25staging: hi6421-spmi-pmic: change a return codeMauro Carvalho Chehab
return -ENODEV if irq_create_mapping() fails at probing time. Suggested-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/e978eabd99c0d3c471026659a2c585deb706e2c4.1624606660.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25staging: hi6421-spmi-pmic: better name IRQsMauro Carvalho Chehab
Instead of naming them as just "hisi", use hi6421v600 to make it clearer. Suggested-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/327fb075905b889a43a0f9dced29ea9966d611f8.1624606660.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25staging: hi6421-spmi-pmic: use devm_request_threaded_irq()Mauro Carvalho Chehab
Use devm_request_threaded_irq() in order to simplify the driver. Suggested-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/b47827c3466eeef3a7de6ac56b1fe93b5ff84e30.1624606660.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25staging: hisilicon,hi6421-spmi-pmic.yaml: cleanup descriptionsMauro Carvalho Chehab
Minor cleanups at the schema: - There's no need to describe interrupt-controller; - gpios need a description. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/9f421e254061a42b7b598bd96b12f05460c175c9.1624606660.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25spmi: hisi-spmi-controller: move driver from stagingMauro Carvalho Chehab
The Hisilicon 6421v600 SPMI driver is ready for mainstream. So, move it from staging. Acked-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/35b9f9169889c1f4d51eff8bf2035450c9e02576.1624606660.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25phy: phy-hi3670-usb3: move driver from staging into phyMauro Carvalho Chehab
The phy USB3 driver for Hisilicon 970 (hi3670) is ready for mainstream. Mode it from staging into the main driver's phy/ directory. Acked-by: Rob Herring <robh@kernel.org> Acked-By: Vinod Koul <vkoul@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/dcf66a01aaeaab93cda52f9a283ecbdf9fa71bb8.1624606660.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25tty: make linux/tty_flip.h self-containedJiri Slaby
If someone includes linux/tty_flip.h before linux/tty.h, they see many compiler errors like: include/linux/tty_flip.h:23:30: error: invalid use of undefined type 'struct tty_port' include/linux/tty_flip.h:26:14: error: invalid use of undefined type 'struct tty_buffer' tty_flip.h actually lexicographically sorts before tty.h. So if people sort includes (as I tried in amiserial), the compilation suddenly breaks. Solve this by including linux/tty.h from linux/tty_flip.h, so that everything is defined as needed. Another alternative would be to uninline tty_insert_flip_char and just insert forward declarations of tty_port and tty_buffer structs into tty_flip.h as that inline is the only real user. But that would mean slowing down the fast path without any good reason. (Provided the fix is that easy and there were no real problems with this until now.) Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210625073511.4514-1-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25ALSA: firewire-lib: Fix 'amdtp_domain_start()' when no AMDTP_OUT_STREAM ↵Christophe JAILLET
stream is found The intent here is to return an error code if we don't find what we are looking for in the 'list_for_each_entry()' loop. 's' is not NULL if the list is empty or if we scan the complete list. Introduce a new 'found' variable to handle such cases. Fixes: 60dd49298ec5 ("ALSA: firewire-lib: handle several AMDTP streams in callback handler of IRQ target") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/9c9a53a4905984a570ba5672cbab84f2027dedc1.1624560484.git.christophe.jaillet@wanadoo.fr Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-06-25staging: rtl8188eu: remove include/rtw_debug.h headerPhillip Potter
Remove include/rtw_debug.h header file, as this isn't used and gets rid of the various other definitions we don't need. Also move the DRIVERVERSION constant value directly to os_dep/os_intfs.c as it is only used there anyway. This results in removal of more unnecessary code. Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210625000756.6313-24-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25staging: rtl8188eu: remove GlobalDebugLevel variablePhillip Potter
Remove GlobalDebugLevel variable and all of its uses, as it is now no longer used anywhere in this driver. Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210625000756.6313-23-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25staging: rtl8188eu: remove DRIVER_PREFIX preprocessor definitionPhillip Potter
Remove DRIVER_PREFIX preprocessor definition, as well as the short block of dumping code that uses it in core/rtw_recv.c - this code is unneeded, as normal debugging facilities can tell us what driver this is simply by pathname etc. Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210625000756.6313-22-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25staging: rtl8188eu: remove RT_TRACE macroPhillip Potter
Remove RT_TRACE macro from include/rtw_debug.h, as it now has no callers, and does not follow best practices and kernel coding conventions. Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210625000756.6313-21-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25staging: rtl8188eu: remove all RT_TRACE calls from hal/rtl8188eu_recv.cPhillip Potter
Remove all RT_TRACE calls from hal/rtl8188eu_recv.c as this macro is unnecessary, and these calls are dubious in terms of necessity. Removing all calls will ultimately allow the removal of the macro itself. Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210625000756.6313-20-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25staging: rtl8188eu: remove all RT_TRACE calls from hal/hal_intf.cPhillip Potter
Remove all RT_TRACE calls from hal/hal_intf.c as this macro is unnecessary, and these calls are dubious in terms of necessity. Removing all calls will ultimately allow the removal of the macro itself. Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210625000756.6313-19-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25staging: rtl8188eu: remove all RT_TRACE calls from hal/rtl8188eu_xmit.cPhillip Potter
Remove all RT_TRACE calls from hal/rtl8188eu_xmit.c as this macro is unnecessary, and these calls are dubious in terms of necessity. Removing all calls will ultimately allow the removal of the macro itself. Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210625000756.6313-18-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25staging: rtl8188eu: remove all RT_TRACE calls from core/rtw_xmit.cPhillip Potter
Remove all RT_TRACE calls from core/rtw_xmit.c as this macro is unnecessary, and these calls are dubious in terms of necessity. Removing all calls will ultimately allow the removal of the macro itself. Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210625000756.6313-17-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25staging: rtl8188eu: remove all RT_TRACE calls from core/rtw_pwrctrl.cPhillip Potter
Remove all RT_TRACE calls from core/rtw_pwrctrl.c as this macro is unnecessary, and these calls are dubious in terms of necessity. Removing all calls will ultimately allow the removal of the macro itself. Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210625000756.6313-16-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25staging: rtl8188eu: remove all RT_TRACE calls from core/rtw_recv.cPhillip Potter
Remove all RT_TRACE calls from core/rtw_recv.c as this macro is unnecessary, and these calls are dubious in terms of necessity. Removing all calls will ultimately allow the removal of the macro itself. Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210625000756.6313-15-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25staging: rtl8188eu: remove all RT_TRACE calls from core/rtw_ioctl_set.cPhillip Potter
Remove all RT_TRACE calls from core/rtw_ioctl_set.c as this macro is unnecessary, and these calls are dubious in terms of necessity. Removing all calls will ultimately allow the removal of the macro itself. Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210625000756.6313-14-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25staging: rtl8188eu: remove all RT_TRACE calls from core/rtw_ieee80211.cPhillip Potter
Remove all RT_TRACE calls from core/rtw_ieee80211.c as this macro is unnecessary, and these calls are dubious in terms of necessity. Removing all calls will ultimately allow the removal of the macro itself. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210625000756.6313-13-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25staging: rtl8188eu: remove all RT_TRACE calls from core/rtw_wlan_util.cPhillip Potter
Remove all RT_TRACE calls from core/rtw_wlan_util.c as this macro is unnecessary, and these calls are dubious in terms of necessity. Removing all calls will ultimately allow the removal of the macro itself. Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210625000756.6313-12-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25staging: rtl8188eu: remove all RT_TRACE calls from core/rtw_led.cPhillip Potter
Remove all RT_TRACE calls from core/rtw_led.c as this macro is unnecessary, and these calls are dubious in terms of necessity. Removing all calls will ultimately allow the removal of the macro itself. Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210625000756.6313-11-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25staging: rtl8188eu: remove all RT_TRACE calls from core/rtw_mlme.cPhillip Potter
Remove all RT_TRACE calls from core/rtw_mlme.c as this macro is unnecessary, and these calls are dubious in terms of necessity. Removing all calls will ultimately allow the removal of the macro itself. Also remove rtw_atimdone_event_callback and rtw_cpwm_event_callback functions and their associated header declarations/usages, as all they do is call RT_TRACE and nothing else. Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210625000756.6313-10-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25staging: rtl8188eu: remove all RT_TRACE calls from core/rtw_mlme_ext.cPhillip Potter
Remove all RT_TRACE calls from core/rtw_mlme_ext.c as this macro is unnecessary, and these calls are dubious in terms of necessity. Removing all calls will ultimately allow the removal of the macro itself. Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210625000756.6313-9-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25staging: rtl8188eu: remove all RT_TRACE calls from core/rtw_sta_mgt.cPhillip Potter
Remove all RT_TRACE calls from core/rtw_sta_mgt.c as this macro is unnecessary, and these calls are dubious in terms of necessity. Removing all calls will ultimately allow the removal of the macro itself. Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210625000756.6313-8-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25staging: rtl8188eu: remove all RT_TRACE calls from core/rtw_security.cPhillip Potter
Remove all RT_TRACE calls from core/rtw_security.c as this macro is unnecessary, and these calls are dubious in terms of necessity. Removing all calls will ultimately allow the removal of the macro itself. Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210625000756.6313-7-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25staging: rtl8188eu: remove all RT_TRACE calls from os_dep/recv_linux.cPhillip Potter
Remove all RT_TRACE calls from os_dep/recv_linux.c as this macro is unnecessary, and these calls are dubious in terms of necessity. Removing all calls will ultimately allow the removal of the macro itself. Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210625000756.6313-6-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25staging: rtl8188eu: remove all RT_TRACE calls from os_dep/mlme_linux.cPhillip Potter
Remove all RT_TRACE calls from os_dep/mlme_linux.c as this macro is unnecessary, and these calls are dubious in terms of necessity. Removing all calls will ultimately allow the removal of the macro itself. Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210625000756.6313-5-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25staging: rtl8188eu: remove all RT_TRACE calls from os_dep/os_intfs.cPhillip Potter
Remove all RT_TRACE calls from os_dep/os_intfs.c as this macro is unnecessary, and these calls are dubious in terms of necessity. Removing all calls will ultimately allow the removal of the macro itself. Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210625000756.6313-4-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25staging: rtl8188eu: remove all RT_TRACE calls from os_dep/xmit_linux.cPhillip Potter
Remove all RT_TRACE calls from os_dep/xmit_linux.c as this macro is unnecessary, and these calls are dubious in terms of necessity. Removing all calls will ultimately allow the removal of the macro itself. Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210625000756.6313-3-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25staging: rtl8188eu: remove all RT_TRACE calls from os_dep/ioctl_linux.cPhillip Potter
Remove all RT_TRACE calls from os_dep/ioctl_linux.c as this macro is unnecessary, and these calls are dubious in terms of necessity. Removing all calls will ultimately allow the removal of the macro itself. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210625000756.6313-2-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-25powerpc/pseries/vas: Include irqdomain.hMichael Ellerman
There are patches in flight to break the dependency between asm/irq.h and linux/irqdomain.h, which would break compilation of vas.c because it needs the declaration of irq_create_mapping() etc. So add an explicit include of irqdomain.h to avoid that becoming a problem in future. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210625045337.3197833-1-mpe@ellerman.id.au
2021-06-25powerpc: mark local variables around longjmp as volatileArnd Bergmann
gcc-11 points out that modifying local variables next to a longjmp/setjmp may cause undefined behavior: arch/powerpc/kexec/crash.c: In function 'crash_kexec_prepare_cpus.constprop': arch/powerpc/kexec/crash.c:108:22: error: variable 'ncpus' might be clobbered by 'longjmp' or 'vfork' [-Werror=clobbere d] arch/powerpc/kexec/crash.c:109:13: error: variable 'tries' might be clobbered by 'longjmp' or 'vfork' [-Werror=clobbere d] arch/powerpc/xmon/xmon.c: In function 'xmon_print_symbol': arch/powerpc/xmon/xmon.c:3625:21: error: variable 'name' might be clobbered by 'longjmp' or 'vfork' [-Werror=clobbered] arch/powerpc/xmon/xmon.c: In function 'stop_spus': arch/powerpc/xmon/xmon.c:4057:13: error: variable 'i' might be clobbered by 'longjmp' or 'vfork' [-Werror=clobbered] arch/powerpc/xmon/xmon.c: In function 'restart_spus': arch/powerpc/xmon/xmon.c:4098:13: error: variable 'i' might be clobbered by 'longjmp' or 'vfork' [-Werror=clobbered] arch/powerpc/xmon/xmon.c: In function 'dump_opal_msglog': arch/powerpc/xmon/xmon.c:3008:16: error: variable 'pos' might be clobbered by 'longjmp' or 'vfork' [-Werror=clobbered] arch/powerpc/xmon/xmon.c: In function 'show_pte': arch/powerpc/xmon/xmon.c:3207:29: error: variable 'tsk' might be clobbered by 'longjmp' or 'vfork' [-Werror=clobbered] arch/powerpc/xmon/xmon.c: In function 'show_tasks': arch/powerpc/xmon/xmon.c:3302:29: error: variable 'tsk' might be clobbered by 'longjmp' or 'vfork' [-Werror=clobbered] arch/powerpc/xmon/xmon.c: In function 'xmon_core': arch/powerpc/xmon/xmon.c:494:13: error: variable 'cmd' might be clobbered by 'longjmp' or 'vfork' [-Werror=clobbered] arch/powerpc/xmon/xmon.c:860:21: error: variable 'bp' might be clobbered by 'longjmp' or 'vfork' [-Werror=clobbered] arch/powerpc/xmon/xmon.c:860:21: error: variable 'bp' might be clobbered by 'longjmp' or 'vfork' [-Werror=clobbered] arch/powerpc/xmon/xmon.c:492:48: error: argument 'fromipi' might be clobbered by 'longjmp' or 'vfork' [-Werror=clobbered] According to the documentation, marking these as 'volatile' is sufficient to avoid the problem, and it shuts up the warning. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210429080708.1520360-1-arnd@kernel.org
2021-06-25powerpc/pmu: Make the generic compat PMU use the architected eventsPaul Mackerras
This changes generic-compat-pmu.c so that it only uses architected events defined in Power ISA v3.0B, rather than event encodings which, while common to all the IBM Power Systems implementations, are nevertheless implementation-specific rather than architected. The intention is that any CPU implementation designed to conform to Power ISA v3.0B or later can use generic-compat-pmu.c. In addition to the existing events for cycles and instructions, this adds several other architected events, including alternative encodings for some events. In order to make it possible to measure cycles and instructions at the same time as each other, we set the CC5-6RUN bit in MMCR0, which makes PMC5 and PMC6 count instructions and cycles regardless of the run bit, so their events are now PM_CYC and PM_INST_CMPL rather than PM_RUN_CYC and PM_RUN_INST_CMPL (the latter are still available via other event codes). Note that POWER9 has an erratum where one architected event (PM_FLOP_CMPL, floating-point operations completed, code 0x100f4) does not work correctly. Given that there is a specific PMU driver for P9 which will be used in preference to generic-compat-pmu.c, that is not a real problem. Signed-off-by: Paul Mackerras <paulus@ozlabs.org> Reviewed-by: Madhavan Srinivasan <maddy@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/YJD7L9yeoxvxqeYi@thinks.paulus.ozlabs.org
generated by cgit (git 2.34.1) at 2025-09-20 02:39:27 +0000