aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2019-08-06pinctrl: nomadik: abx500: Add of_node_put() before returnNishka Dasgupta1-0/+1
Each iteration of for_each_child_of_node puts the previous node, but in the case of a return from the middle of the loop, there is no put, thus causing a memory leak. Hence add an of_node_put before the return. Issue found with Coccinelle. Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com> Link: https://lore.kernel.org/r/20190804155154.4916-1-nishkadg.linux@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-06pinctrl: nomadik: nomadik: Add of_node_put() before returnNishka Dasgupta1-0/+1
Each iteration of for_each_child_of_node puts the previous node, but in the case of a return from the middle of the loop, there is no put, thus causing a memory leak. Hence add an of_node_put before the return. Issue found with Coccinelle. Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com> Link: https://lore.kernel.org/r/20190804155117.4753-1-nishkadg.linux@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-06pinctrl: falcon: Add of_node_put() before returnNishka Dasgupta1-1/+4
Each iteration of for_each_compatible_node puts the previous node, but in the case of a return from the middle of the loop, there is no put, thus causing a memory leak. Hence add an of_node_put before the return in two places. Issue found with Coccinelle. Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com> Link: https://lore.kernel.org/r/20190804152745.2231-1-nishkadg.linux@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-05pinctrl: xway: Use devm_kasprintf() instead of fixed buffer formattingGeert Uytterhoeven1-3/+1
Improve readability and maintainability by replacing a hardcoded string allocation and formatting by the use of the devm_kasprintf() helper. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20190731132917.17607-4-geert+renesas@glider.be Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-05pinctrl: lantiq: Use kasprintf() instead of fixed buffer formattingGeert Uytterhoeven1-5/+1
Improve readability and maintainability by replacing a hardcoded string allocation and formatting by the use of the kasprintf() helper. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20190731132917.17607-3-geert+renesas@glider.be Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-05pinctrl: devicetree: Use strlen() instead of hardcoded numberGeert Uytterhoeven1-4/+2
Improve readability by replacing a hardcoded number requiring a comment by strlen(). Gcc is smart enough to evaluate the length of a constant string at compile-time. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20190731132917.17607-2-geert+renesas@glider.be Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-05pinctrl: Remove dev_err() usage after platform_get_irq()Stephen Boyd6-19/+6
We don't need dev_err() messages when platform_get_irq() fails now that platform_get_irq() prints an error message itself when something goes wrong. Let's remove these prints with a simple semantic patch. // <smpl> @@ expression ret; struct platform_device *E; @@ ret = ( platform_get_irq(E, ...) | platform_get_irq_byname(E, ...) ); if ( \( ret < 0 \| ret <= 0 \) ) { ( -if (ret != -EPROBE_DEFER) -{ ... -dev_err(...); -... } | ... -dev_err(...); ) ... } // </smpl> While we're here, remove braces on if statements that only have one statement (manually). Cc: Linus Walleij <linus.walleij@linaro.org> Cc: linux-gpio@vger.kernel.org Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20190730181557.90391-34-swboyd@chromium.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-05pinctrl: uniphier: Fix Pro5 SD pin-mux settingKunihiko Hayashi1-1/+1
SD uses the following pins starting from 247: SDCD, SDWP, SDVOLC, SDCLK, SDCMD, SDDAT{0,1,2,3} Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com> Link: https://lore.kernel.org/r/1564465410-9165-6-git-send-email-hayashi.kunihiko@socionext.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-05pinctrl: uniphier: Add Pro5 PCIe pin-mux settingsKunihiko Hayashi1-0/+5
Pro5 PCIe interface uses the following pins: XPERST, XPEWAKE, XPECLKRQ Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Link: https://lore.kernel.org/r/1564465410-9165-5-git-send-email-hayashi.kunihiko@socionext.com Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-05pinctrl: uniphier: Add 5th LD20 MPEG2-TS input pin-mux settingKunihiko Hayashi1-0/+5
The 5th serial TS interface uses the following pins: hscin4_s: PCA[11-14] Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com> Link: https://lore.kernel.org/r/1564465410-9165-4-git-send-email-hayashi.kunihiko@socionext.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-05pinctrl: uniphier: Add another audio I/O pin-mux settings for LD20Kunihiko Hayashi1-1/+4
This adds support for pinmux settings of aout1b group. This group includes audio I/O signals derived from xirq pins, and it is equivalent to "aout1" in functionality. Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Link: https://lore.kernel.org/r/1564465410-9165-3-git-send-email-hayashi.kunihiko@socionext.com Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-05pinctrl: uniphier: Separate modem group from UART ctsrts groupKunihiko Hayashi9-27/+63
It depends on the board implementation whether to have each pins of CTS/RTS, and others for modem. So it is necessary to divide current uart_ctsrts group into uart_ctsrts and uart_modem groups. Since the number of implemented pins for modem differs depending on SoC, each uart_modem group also has a different number of pins. Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Link: https://lore.kernel.org/r/1564465410-9165-2-git-send-email-hayashi.kunihiko@socionext.com Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-05pinctrl: meson-g12a: add pwm_a on GPIOE_2 pinmuxNeil Armstrong1-0/+9
Add the missing pinmux for the pwm_a function on the GPIOE_2 pin. Reviewed-by: Kevin Hilman <khilman@baylibre.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20190729125838.6498-1-narmstrong@baylibre.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-05dt-bindings: aspeed: Remove mention of deprecated compatiblesAndrew Jeffery4-11/+2
Guide readers away from using the aspeed,g[45].* compatible patterns. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20190724081313.12934-4-andrew@aj.id.au Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-05pinctrl: aspeed: Document existence of deprecated compatiblesAndrew Jeffery2-0/+8
Otherwise they look odd in the face of not being listed in the bindings documents. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20190724081313.12934-3-andrew@aj.id.au Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-05pinctrl: aspeed: Add AST2600 pinmux supportAndrew Jeffery3-0/+2404
The AST2600 pinmux is fairly similar to the previous generations of ASPEED BMC SoCs in terms of architecture, though differ in some of the design details. The complexity of the pin expressions is largely reduced (e.g. there are no-longer signals with multiple expressions muxing them to the associated pin), and there are now signals and buses with multiple pin groups. The driver implements pinmux support for all 244 GPIO-capable pins plus a further four pins that are not GPIO capable but which expose multiple signals. pinconf will be implemented in a follow-up patch. The implementation has been smoke-tested under qemu, and run on hardware by ASPEED. Debugged-by: Johnny Huang <johnny_huang@aspeedtech.com> Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20190711041942.23202-7-andrew@aj.id.au Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-05pinctrl: aspeed: Add SIG_DESC_CLEAR() helperAndrew Jeffery1-0/+1
The complement of SIG_DESC_SET(). Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20190729055604.13239-6-andrew@aj.id.au Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-05pinctrl: aspeed: Add multiple pin group support for functionsAndrew Jeffery3-1489/+1789
The AST2400 and AST2500 SoCs only exposed one pin group per function. Lone pin groups drove some implementation simplifications in the ASPEED pinmux infrastructure that is now invalid for the AST2600, which supports multiple groups per function for some functions on the chip (SMBus Alert pins and UARTs among others). This patch reworks the macro jungle to enable support for multiple pin groups. In the process we inflict some collateral damage on the existing AST2400 and AST2500 drivers, but the rework is mostly a relatively straight-forward, automated transform of adding the pin name as an argument to some macro calls and implementing wrappers to paper over groups in the cases where there aren't multiple. As previously documented, the macro infrastructure exposes mux configuration as symbols in the source file which are used to detect accidental duplication. Previously these symbols were named in terms of the signal for a given expression. As the AST2600 supports multiple pin groups for a function, the signal name on its own is no-longer unique, and we must switch to the (signal, group) tuple. However, this means that we can no-longer derive the signal expression symbol name from the signal name alone, which among other cases, impacts the operation of the PIN_DECL_x() macros. To fix that and avoid requiring we awkwardly provide the associated group name for every signal for every PIN_DECL_x() invocation, instead opportunistically alias the name of the signal expression symbol from the unique (signal, group) tuple to the also unique (pin, signal) tuple, then reference the alias symbol in the tables generated by PIN_DECL_x(). This way we do not require extra group parameters for PIN_DECL_x() as the pin name was already provided as an argument, and instead simply require that the pin name be provided to the expression declaration macros in order to generate the alias symbol. The patch implements the alias strategy and fixes up all the expression definition macro calls in the AST2400 and AST2500 drivers to account for pin groups. Given the implementation strategy has the property that compilation either fails or loudly warns for bad pin descriptions, this patch is theoretically tested by successfully compiling both affected drivers. For a more practical test I've inspected the diff of the content of the pinctrl debugfs entries before and after the patch under qemu; all pins, functions and groups match. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20190729055604.13239-5-andrew@aj.id.au Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-05pinctrl: aspeed: Add PIN_DECL_3() helperAndrew Jeffery1-32/+40
This case is common in the AST2600, so add to the collection. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20190729055604.13239-4-andrew@aj.id.au Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-05pinctrl: aspeed: Rename pin declaration macrosAndrew Jeffery3-405/+405
Rename macros as follows: * s/SS_PIN_DECL()/PIN_DECL_1()/ * s/MS_PIN_DECL()/PIN_DECL_2()/ * s/MS_PIN_DECL_()/PIN_DECL_()/ This is in preparation for adding PIN_DECL_3(). We could clean this up with e.g. CPPMAGIC_MAP() from ccan, but that might be a bridge too far given how much of a macro jungle we already have. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20190729055604.13239-3-andrew@aj.id.au Signed-off-by: Linus Walleij <linus.walleij@linaro.org>