aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2023-12-13watchdog: s3c2410_wdt: Update QUIRK macros to use BIT macroPeter Griffin1-5/+5
Update the remaining QUIRK macros to use the BIT macro. Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Link: https://lore.kernel.org/r/20231211162331.435900-12-peter.griffin@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-13watchdog: s3c2410_wdt: Add support for WTCON register DBGACK_MASK bitPeter Griffin1-3/+25
The WDT uses the CPU core signal DBGACK to determine whether the SoC is running in debug mode or not. If the DBGACK signal is asserted and DBGACK_MASK bit is enabled, then WDT output and interrupt is masked (disabled). Presence of the DBGACK_MASK bit is determined by adding a new QUIRK_HAS_DBGACK_BIT quirk. Also update to use BIT macro to avoid checkpatch --strict warnings. Tested-by: Will McVicker <willmcvicker@google.com> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Link: https://lore.kernel.org/r/20231211162331.435900-11-peter.griffin@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-12tty: serial: samsung: Add gs101 compatible and common fifoszdt_serial_drv_dataPeter Griffin1-0/+16
Add serial driver data for Google Tensor gs101 SoC and a common fifoszdt_serial_drv_data that can be used by platforms that specify the samsung,uart-fifosize DT property. A corresponding dt-bindings patch updates the yaml to ensure samsung,uart-fifosize is a required property. Tested-by: Will McVicker <willmcvicker@google.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Link: https://lore.kernel.org/r/20231211162331.435900-14-peter.griffin@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-12clk: samsung: clk-gs101: Add cmu_top, cmu_misc and cmu_apm supportPeter Griffin2-0/+2512
cmu_top is the top level clock management unit which contains PLLs, muxes, dividers and gates that feed the other clock management units. cmu_misc clocks IPs such as Watchdog and cmu_apm clocks ips part of the APM module. Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: André Draszik <andre.draszik@linaro.org> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Will McVicker <willmcvicker@google.com> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Link: https://lore.kernel.org/r/20231211162331.435900-9-peter.griffin@linaro.org [krzysztof: drop not needed linux/of_device.h include] Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-12clk: samsung: clk-pll: Add support for pll_{0516,0517,518}Peter Griffin2-0/+9
These plls are found in the Tensor gs101 SoC found in the Pixel 6. pll0516x: Integer PLL with high frequency pll0517x: Integer PLL with middle frequency pll0518x: Integer PLL with low frequency PLL0516x FOUT = (MDIV * 2 * FIN)/PDIV * 2^SDIV) PLL0517x and PLL0518x FOUT = (MDIV * FIN)/PDIV*2^SDIV) The PLLs are similar enough to pll_0822x that the same code can handle both. The main difference is the change in the fout formula for the high frequency 0516 pll. Locktime for 516,517 & 518 is 150 the same as the pll_0822x lock factor. MDIV, SDIV PDIV masks and bit shifts are also the same as 0822x. When defining the PLL the "con" parameter should be set to CON3 register, like this PLL(pll_0517x, CLK_FOUT_SHARED0_PLL, "fout_shared0_pll", "oscclk", PLL_LOCKTIME_PLL_SHARED0, PLL_CON3_PLL_SHARED0, NULL), Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Will McVicker <willmcvicker@google.com> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Link: https://lore.kernel.org/r/20231211162331.435900-8-peter.griffin@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-12dt-bindings: clock: google,gs101: fix incorrect numbering and DGB suffixPeter Griffin1-59/+59
166 was skipped by mistake and two clocks: * CLK_MOUT_CMU_HSI0_USBDPDGB * CLK_GOUT_HSI0_USBDPDGB Have an incorrect DGB ending instead of DBG. This is an ABI break, but as the patch was only applied yesterday this header has never been in an actual release so it seems better to fix this early than ignore it. Fixes: 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock management unit bindings") Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: André Draszik <andre.draszik@linaro.org> Link: https://lore.kernel.org/r/20231211162331.435900-7-peter.griffin@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-12dt-bindings: soc: samsung: usi: add google,gs101-usi compatibleTudor Ambarus1-0/+1
Add google,gs101-usi dedicated compatible for representing USI of Google GS101 SoC. Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Link: https://lore.kernel.org/r/20231211162331.435900-6-peter.griffin@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-12dt-bindings: serial: samsung: Make samsung,uart-fifosize a required propertyPeter Griffin1-0/+10
Specifying samsung,uart-fifosize in both DT and driver static data is error prone and relies on driver probe order and dt aliases to be correct. Additionally on many Exynos platforms these are (USI) universal serial interfaces which can be uart, spi or i2c, so it can change per board. For google,gs101-uart make samsung,uart-fifosize a required property. For this platform fifosize now *only* comes from DT. Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Link: https://lore.kernel.org/r/20231211162331.435900-5-peter.griffin@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-12dt-bindings: serial: samsung: Add google-gs101-uart compatiblePeter Griffin1-0/+1
Add dedicated google-gs101-uart compatible to the dt-schema for representing uart of the Google Tensor gs101 SoC. Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Link: https://lore.kernel.org/r/20231211162331.435900-4-peter.griffin@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-12dt-bindings: watchdog: Document Google gs101 watchdog bindingsPeter Griffin1-2/+6
Add the "google,gs101-wdt" compatible to the dt-schema documentation. gs101 SoC has two CPU clusters and each cluster has its own dedicated watchdog timer (similar to exynos850 and exynosautov9 SoCs). These WDT instances are controlled using different bits in PMU registers. Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Link: https://lore.kernel.org/r/20231211162331.435900-2-peter.griffin@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-11dt-bindings: samsung: exynos-sysreg: combine exynosautov920 with other enumKrzysztof Kozlowski1-5/+2
No need to create a new enum every time we bring-up new SoC. Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Jaewon Kim <jaewon02.kim@samsung.com> Link: https://lore.kernel.org/r/20231210134834.43943-1-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-10dt-bindings: soc: google: exynos-sysreg: add dedicated SYSREG compatibles to GS101Peter Griffin1-0/+3
GS101 has three different SYSREG controllers, add dedicated compatibles for them to the documentation. Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Link: https://lore.kernel.org/r/20231209233106.147416-4-peter.griffin@linaro.org [krzysztof: move Google entries to existing enum] Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-10dt-bindings: clock: Add Google gs101 clock management unit bindingsPeter Griffin2-0/+498
Provide dt-schema documentation for Google gs101 SoC clock controller. Currently this adds support for cmu_top, cmu_misc and cmu_apm. Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20231209233106.147416-3-peter.griffin@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-10dt-bindings: soc: samsung: exynos-pmu: Add gs101 compatiblePeter Griffin1-0/+2
Add gs101-pmu compatible to the bindings documentation. Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Link: https://lore.kernel.org/r/20231209233106.147416-2-peter.griffin@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-07dt-bindings: watchdog: samsung: add specific compatible for Tesla FSDKrzysztof Kozlowski1-8/+13
Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the others it reuses several devices from older designs. Historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add Tesla FSD compatible specific to be used with an existing fallback. Acked-by: Rob Herring <robh@kernel.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20231205092229.19135-6-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-07dt-bindings: samsung: exynos-pmu: add specific compatible for Tesla FSDKrzysztof Kozlowski1-0/+1
Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the others it reuses several devices from older designs. Historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add Tesla FSD compatible specific to be used with an existing fallback. Acked-by: Rob Herring <robh@kernel.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20231205092229.19135-5-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-07dt-bindings: serial: samsung: add specific compatible for Tesla FSDKrzysztof Kozlowski1-0/+1
Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the others it reuses several devices from older designs. Historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add Tesla FSD compatible specific to be used with an existing fallback. Acked-by: Rob Herring <robh@kernel.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20231205092229.19135-4-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-07dt-bindings: pwm: samsung: add specific compatible for Tesla FSDKrzysztof Kozlowski1-0/+1
Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the others it reuses several devices from older designs. Historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add Tesla FSD compatible specific to be used with an existing fallback. Acked-by: Rob Herring <robh@kernel.org> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20231205092229.19135-3-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-12-07dt-bindings: i2c: exynos5: add specific compatible for Tesla FSDKrzysztof Kozlowski1-0/+1
Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the others it reuses several devices from older designs. Historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add Tesla FSD compatible specific to be used with an existing fallback. Acked-by: Rob Herring <robh@kernel.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20231205092229.19135-2-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15dt-bindings: hwinfo: samsung,exynos-chipid: add exynosautov920 compatibleJaewon Kim1-0/+1
Add "samsung,exynosautov920-chipid" compatible string to binding document. Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com> Link: https://lore.kernel.org/r/20231115095609.39883-9-jaewon02.kim@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15dt-bindings: arm: samsung: Document exynosautov920 SADK board bindingJaewon Kim1-0/+6
Add binding for the ExynosAutov920 SADK(Samsung Automotive Development Kit) board. Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com> Link: https://lore.kernel.org/r/20231115095609.39883-8-jaewon02.kim@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15dt-bindings: pwm: samsung: add exynosautov920 compatibleJaewon Kim1-0/+1
Add samsung,exynosautov920-pwm compatible string to binding document. Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20231115095609.39883-6-jaewon02.kim@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15dt-bindings: serial: samsung: add exynosautov920-uart compatibleJaewon Kim1-1/+3
Add samsung,exynosautov9-uart dedicated compatible for representing uart of ExynosAutov920 SoC. Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com> Link: https://lore.kernel.org/r/20231115095609.39883-5-jaewon02.kim@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15dt-bindings: samsung: usi: add exynosautov920-usi compatibleJaewon Kim1-1/+3
Add samsung,exynosautov920-usi dedicated compatible for representing USI of ExynosAutoV920 SoC. Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com> Link: https://lore.kernel.org/r/20231115095609.39883-4-jaewon02.kim@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15dt-bindings: samsung: exynos-pmu: add exynosautov920 compatibleJaewon Kim1-0/+1
Add samsung,exynosautov920-pmu compatible for representing pmu of ExynosAutov920 SoC. Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com> Link: https://lore.kernel.org/r/20231115095609.39883-3-jaewon02.kim@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15dt-bindings: samsung: exynos-sysreg: add exynosautov920 sysregJaewon Kim1-0/+5
Add compatible for ExynosAutov920 sysreg controllers. Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com> Link: https://lore.kernel.org/r/20231115095609.39883-2-jaewon02.kim@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15soc: samsung: exynos-chipid: add exynosautov920 SoC supportJaewon Kim1-0/+1
Add EXYNOSAUTOV920 information to soc_ids tables. This SoC product id is "0x0A920000". Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com> Link: https://lore.kernel.org/r/20231115095609.39883-10-jaewon02.kim@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15dt-bindings: pwm: samsung: add specific compatibles for existing SoCKrzysztof Kozlowski1-0/+2
Samsung Exynos SoC reuses several devices from older designs, thus historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add compatibles specific to each SoC in front of all old-SoC-like compatibles. Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20231108104343.24192-13-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15ASoC: dt-bindings: samsung-i2s: add specific compatibles for existing SoCKrzysztof Kozlowski2-8/+13
Samsung Exynos SoC reuses several devices from older designs, thus historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add compatibles specific to each SoC in front of all old-SoC-like compatibles. Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Lee Jones <lee@kernel.org> Acked-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20231108104343.24192-12-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15dt-bindings: iio: samsung,exynos-adc: add specific compatibles for existing SoCKrzysztof Kozlowski1-12/+17
Samsung Exynos SoC reuses several devices from older designs, thus historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add compatibles specific to each SoC in front of all old-SoC-like compatibles. Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20231108104343.24192-11-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15dt-bindings: gpu: arm,mali-midgard: add specific compatibles for existing Exynos SoCKrzysztof Kozlowski1-0/+5
Samsung Exynos SoC reuses several devices from older designs, thus historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add compatibles specific to each SoC in front of all old-SoC-like compatibles. Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20231108104343.24192-10-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15dt-bindings: samsung: exynos-pmu: add specific compatibles for existing SoCKrzysztof Kozlowski1-0/+6
Samsung Exynos SoC reuses several devices from older designs, thus historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add compatibles specific to each SoC in front of all old-SoC-like compatibles. Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20231108104343.24192-9-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15dt-bindings: serial: samsung: add specific compatibles for existing SoCKrzysztof Kozlowski1-3/+11
Samsung Exynos SoC reuses several devices from older designs, thus historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add compatibles specific to each SoC in front of all old-SoC-like compatibles. Re-shuffle also the entries in compatibles, so the one-compatible-enum is the first. Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20231108104343.24192-8-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-15dt-bindings: rtc: s3c-rtc: add specific compatibles for existing SoCKrzysztof Kozlowski1-0/+5
Samsung Exynos SoC reuses several devices from older designs, thus historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add compatibles specific to each SoC in front of all old-SoC-like compatibles. Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20231108104343.24192-7-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-14dt-bindings: mmc: samsung,exynos-dw-mshc: add specific compatibles for existing SoCKrzysztof Kozlowski1-9/+16
Samsung Exynos SoC reuses several devices from older designs, thus historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add compatibles specific to each SoC in front of all old-SoC-like compatibles. While re-indenting the first enum, put also axis,artpec8-dw-mshc in alphabetical order. Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20231108104343.24192-5-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-14dt-bindings: i2c: samsung,s3c2410-i2c: add specific compatibles for existing SoCKrzysztof Kozlowski1-8/+14
Samsung Exynos SoC reuses several devices from older designs, thus historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add compatibles specific to each SoC in front of all old-SoC-like compatibles. Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Wolfram Sang <wsa@kernel.org> Link: https://lore.kernel.org/r/20231108104343.24192-4-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-14dt-bindings: i2c: exynos5: add specific compatibles for existing SoCKrzysztof Kozlowski2-2/+10
Samsung Exynos SoC reuses several devices from older designs, thus historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add compatibles specific to each SoC in front of all old-SoC-like compatibles. Acked-by: Rob Herring <robh@kernel.org> Acked-by: Wolfram Sang <wsa@kernel.org> Link: https://lore.kernel.org/r/20231108104343.24192-3-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-14dt-bindings: hwinfo: samsung,exynos-chipid: add specific compatibles for existing SoCKrzysztof Kozlowski1-3/+14
Samsung Exynos SoC reuses several devices from older designs, thus historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add compatibles specific to each SoC in front of all old-SoC-like compatibles. Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20231108104343.24192-2-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-11-12Linux 6.7-rc1Linus Torvalds1-2/+2
2023-11-12wifi: iwlwifi: fix system commands group orderingMiri Korenblit1-1/+1
The commands should be sorted inside the group definition. Fix the ordering so we won't get following warning: WARN_ON(iwl_cmd_groups_verify_sorted(trans_cfg)) Link: https://lore.kernel.org/regressions/2fa930bb-54dd-4942-a88d-05a47c8e9731@gmail.com/ Link: https://lore.kernel.org/linux-wireless/CAHk-=wix6kqQ5vHZXjOPpZBfM7mMm9bBZxi2Jh7XnaKCqVf94w@mail.gmail.com/ Fixes: b6e3d1ba4fcf ("wifi: iwlwifi: mvm: implement new firmware API for statistics") Tested-by: Niklāvs Koļesņikovs <pinkflames.linux@gmail.com> Tested-by: Damian Tometzki <damian@riscv-rocks.de> Acked-by: Kalle Valo <kvalo@kernel.org> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2023-11-11tracing/kprobes: Fix the order of argument descriptionsYujie Liu1-1/+1
The order of descriptions should be consistent with the argument list of the function, so "kretprobe" should be the second one. int __kprobe_event_gen_cmd_start(struct dynevent_cmd *cmd, bool kretprobe, const char *name, const char *loc, ...) Link: https://lore.kernel.org/all/20231031041305.3363712-1-yujie.liu@intel.com/ Fixes: 2a588dd1d5d6 ("tracing: Add kprobe event command generation functions") Suggested-by: Mukesh Ojha <quic_mojha@quicinc.com> Signed-off-by: Yujie Liu <yujie.liu@intel.com> Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2023-11-10drm/amdgpu: fix error handling in amdgpu_vm_initChristian König1-15/+16
When clearing the root PD fails we need to properly release it again. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2023-11-10drm/amdgpu: Fix possible null pointer dereferenceFelix Kuehling1-2/+2
mem = bo->tbo.resource may be NULL in amdgpu_vm_bo_update. Fixes: 180253782038 ("drm/ttm: stop allocating dummy resources during BO creation") Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2023-11-10drm/amdgpu: move UVD and VCE sched entity init after sched initAlex Deucher13-46/+37
We need kernel scheduling entities to deal with handle clean up if apps are not cleaned up properly. With commit 56e449603f0ac5 ("drm/sched: Convert the GPU scheduler to variable number of run-queues") the scheduler entities have to be created after scheduler init, so change the ordering to fix this. v2: Leave logic in UVD and VCE code Fixes: 56e449603f0a ("drm/sched: Convert the GPU scheduler to variable number of run-queues") Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Luben Tuikov <ltuikov89@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: ltuikov89@gmail.com
2023-11-10drm/amdgpu: move kfd_resume before the ip late initTim Huang1-7/+6
The kfd_resume needs to touch GC registers to enable the interrupts, it needs to be done before GFXOFF is enabled to ensure that the GFX is not off and GC registers can be touched. So move kfd_resume before the amdgpu_device_ip_late_init which enables the CGPG/GFXOFF. Signed-off-by: Tim Huang <Tim.Huang@amd.com> Reviewed-by: Yifan Zhang <yifan1.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-11-10drm/amd: Explicitly check for GFXOFF to be enabled for s0ixMario Limonciello1-0/+3
If a user has disabled GFXOFF this may cause problems for the suspend sequence. Ensure that it is enabled in amdgpu_acpi_is_s0ix_active(). The system won't reach the deepest state but it also won't hang. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-11-10cifs: update internal module version number for cifs.koSteve French1-2/+2
From 2.45 to 2.46 Signed-off-by: Steve French <stfrench@microsoft.com>
2023-11-10cifs: handle when server stops supporting multichannelShyam Prasad N6-10/+145
When a server stops supporting multichannel, we will keep attempting reconnects to the secondary channels today. Avoid this by freeing extra channels when negotiate returns no multichannel support. Signed-off-by: Shyam Prasad N <sprasad@microsoft.com> Signed-off-by: Steve French <stfrench@microsoft.com>
2023-11-10cifs: handle when server starts supporting multichannelShyam Prasad N3-2/+34
When the user mounts with multichannel option, but the server does not support it, there can be a time in future where it can be supported. With this change, such a case is handled. Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
2023-11-10Missing field not being returned in ioctl CIFS_IOC_GET_MNT_INFOSteve French1-0/+1
The tcon_flags field was always being set to zero in the information about the mount returned by the ioctl CIFS_IOC_GET_MNT_INFO instead of being set to the value of the Flags field in the tree connection structure as intended. Reviewed-by: Shyam Prasad N <sprasad@microsoft.com> Signed-off-by: Steve French <stfrench@microsoft.com>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.