[PATCH] ks7010: removed checkpatch.pl format errors
Signed-off-by: shivang upadhyay
---
drivers/staging/ks7010/ks_hostif.h | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/ks7010/ks_hostif.h
b/drivers/staging/ks7010/ks_hostif.h
index 39138191a556..c62a494ed6bb 100644
--- a/drivers/staging/ks7010/ks_hostif.h
+++ b/drivers/staging/ks7010/ks_hostif.h
@@ -498,20 +498,20 @@ struct hostif_mic_failure_request {
#define TX_RATE_FIXED 5
/* 11b rate */
-#define TX_RATE_1M (u8)(10 / 5)/* 11b 11g basic rate */
-#define TX_RATE_2M (u8)(20 / 5)/* 11b 11g basic rate */
-#define TX_RATE_5M (u8)(55 / 5)/* 11g basic rate */
-#define TX_RATE_11M(u8)(110 / 5) /* 11g basic rate */
+#define TX_RATE_1M ((u8)(10 / 5)) /* 11b 11g basic rate */
+#define TX_RATE_2M ((u8)(20 / 5)) /* 11b 11g basic rate */
+#define TX_RATE_5M ((u8)(55 / 5)) /* 11g basic rate */
+#define TX_RATE_11M((u8)(110 / 5)) /* 11g basic rate */
/* 11g rate */
-#define TX_RATE_6M (u8)(60 / 5)/* 11g basic rate */
-#define TX_RATE_12M(u8)(120 / 5) /* 11g basic rate */
-#define TX_RATE_24M(u8)(240 / 5) /* 11g basic rate */
-#define TX_RATE_9M (u8)(90 / 5)
-#define TX_RATE_18M(u8)(180 / 5)
-#define TX_RATE_36M(u8)(360 / 5)
-#define TX_RATE_48M(u8)(480 / 5)
-#define TX_RATE_54M(u8)(540 / 5)
+#define TX_RATE_6M ((u8)(60 / 5)) /* 11g basic rate */
+#define TX_RATE_12M((u8)(120 / 5)) /* 11g basic rate */
+#define TX_RATE_24M((u8)(240 / 5)) /* 11g basic rate */
+#define TX_RATE_9M ((u8)(90 / 5))
+#define TX_RATE_18M((u8)(180 / 5))
+#define TX_RATE_36M((u8)(360 / 5))
+#define TX_RATE_48M((u8)(480 / 5))
+#define TX_RATE_54M((u8)(540 / 5))
static inline bool is_11b_rate(u8 rate)
{
--
2.27.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RESEND PATCH v5 1/6] dt-bindings: clock: add dt binding header for mt7621 clocks
Adds dt binding header for 'mediatek,mt7621-clk' clocks. Acked-by: Rob Herring Signed-off-by: Sergio Paracuellos --- include/dt-bindings/clock/mt7621-clk.h | 41 ++ 1 file changed, 41 insertions(+) create mode 100644 include/dt-bindings/clock/mt7621-clk.h diff --git a/include/dt-bindings/clock/mt7621-clk.h b/include/dt-bindings/clock/mt7621-clk.h new file mode 100644 index ..1422badcf9de --- /dev/null +++ b/include/dt-bindings/clock/mt7621-clk.h @@ -0,0 +1,41 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Author: Sergio Paracuellos + */ + +#ifndef _DT_BINDINGS_CLK_MT7621_H +#define _DT_BINDINGS_CLK_MT7621_H + +#define MT7621_CLK_XTAL0 +#define MT7621_CLK_CPU 1 +#define MT7621_CLK_BUS 2 +#define MT7621_CLK_50M 3 +#define MT7621_CLK_125M4 +#define MT7621_CLK_150M5 +#define MT7621_CLK_250M6 +#define MT7621_CLK_270M7 + +#define MT7621_CLK_HSDMA 8 +#define MT7621_CLK_FE 9 +#define MT7621_CLK_SP_DIVTX10 +#define MT7621_CLK_TIMER 11 +#define MT7621_CLK_PCM 12 +#define MT7621_CLK_PIO 13 +#define MT7621_CLK_GDMA14 +#define MT7621_CLK_NAND15 +#define MT7621_CLK_I2C 16 +#define MT7621_CLK_I2S 17 +#define MT7621_CLK_SPI 18 +#define MT7621_CLK_UART1 19 +#define MT7621_CLK_UART2 20 +#define MT7621_CLK_UART3 21 +#define MT7621_CLK_ETH 22 +#define MT7621_CLK_PCIE0 23 +#define MT7621_CLK_PCIE1 24 +#define MT7621_CLK_PCIE2 25 +#define MT7621_CLK_CRYPTO 26 +#define MT7621_CLK_SHXC27 + +#define MT7621_CLK_MAX 28 + +#endif /* _DT_BINDINGS_CLK_MT7621_H */ -- 2.25.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RESEND PATCH v5 0/6] MIPS: ralink: add CPU clock detection and clock driver for MT7621
This patchset ports CPU clock detection for MT7621 from OpenWrt and adds a complete clock plan for the mt7621 SOC. The documentation for this SOC only talks about two registers regarding to the clocks: * SYSC_REG_CPLL_CLKCFG0 - provides some information about boostrapped refclock. PLL and dividers used for CPU and some sort of BUS (AHB?). * SYSC_REG_CPLL_CLKCFG1 - a banch of gates to enable/disable clocks for all or some ip cores. No documentation about a probably existent set of dividers for each ip core is included in the datasheets. So we cannot make anything better, AFAICT. Looking into driver code, and some openWRT patched there are another frequences which are used in some drivers (uart, sd...). According to all of this information the clock plan for this SoC is set as follows: - Main top clock "xtal" from where all the rest of the world is derived. - CPU clock "cpu" derived from "xtal" frequencies and a bunch of register reads and predividers. - BUS clock "bus" derived from "cpu" and with (cpu / 4) MHz. - Fixed clocks from "xtal": * "50m": 50 MHz. * "125m": 125 MHz. * "150m": 150 MHz. * "250m": 250 MHz. * "270m": 270 MHz. We also have a buch of gate clocks with their parents: - "hsdma": "150m" - "fe": "250m" - "sp_divtx": "270m" - "timer": "50m" - "pcm": "270m" - "pio": "50m" - "gdma": "bus" - "nand": "125m" - "i2c": "50m" - "i2s": "270m" - "spi": "bus" - "uart1": "50m" - "uart2": "50m" - "uart3": "50m" - "eth": "50m" - "pcie0": "125m" - "pcie1": "125m" - "pcie2": "125m" - "crypto": "250m" - "shxc": "50m" There was a previous attempt of doing this here[0] but the author (Chuanhong Guo) did not wanted to make assumptions of a clock plan for the platform that time. It seems that now he has a better idea of how the clocks are dispossed for this SoC so he share code[1] where some frequencies and clock parents for the gates are coded from a real mediatek private clock plan. I do really want this to be upstreamed so according to the comments in previous attempt[0] from Oleksij Rempel and the frequencies in code[1] I have tried to do this by myself. All of this patches have been tested in a GNUBee PC1 resulting in a working platform. v5 RESEND notes: - I am resending this as I was told to do that. - Please, take into account Rob's comments to DT node patch and my reply with explanation about how are the current device tree nodes for this architecture being used in [2]. Changes in v5: - Avoid the use of syscon. All drivers of this platform are just using platform operations defined in 'asm/mach-ralink/ralink_regs.h'. We also need them for some PLL registers that are not in the sys control area. Hence, since we must use this dependency avoid to define clock driver as a child of the sysc node in the device tree and follow current platform code style. - Update bindings documentation to don't refer the syscon and make remove 'clock-output-names' property from required ones. - Use 'asm/mach-ralink/ralink_regs.h' platform read and write operations instead of regmap from the syscon node. - Remove 'mt7621_clk_provider' and directly declare 'clk_hw_onecell_data' pointer in 'mt7621_clk_init' and pass from there into different register functions. Remove pointers to 'mt7621_clk_provider' in the rest fo structs used in this driver. - Remove MHZ macro and just pass values directly in hertzs. - Avoid 'CLK_IGNORE_UNUSED' flag for gates and add a new function called 'mt7621_prepare_enable_clocks' to prepare all of them to make clocks referenced and don't affect current driver code. - Remove COMPILE_TEST from Kconfig because of the use of especific arch stuff. - Fix commit message where a typo for "frequencies" word was present. - Make use of parent_clk_data in 'CLK_BASE' macro. - Remove MODULE_* macros from code since this is not a module. - Remove not needed includes. - Hardcode "xtal" as parent in FIXED macro. - Change 'else if' clause into 'if' clause since a return statement was being used in 'mt7621_xtal_recalc_rate'. NOTES: - Driver is still being declared using 'CLK_OF_DECLARE' for all the clocks. I have explored the possibility to make some of them available afterwards using 'CLK_OF_DECLARE_DRIVER' for top clocks and the rest using a platform driver. The resulting code was uglier since we only want to use the same device tree node and the top clocks must be copied again for the new platform register stuff to properly have a good hierarchy. New globals needs to be introduced and in this particular case I don't really see the benefits of doing in this way. I am totally ok to have all the clocks registered at early stage since from other drivers perspective we only really need to enable gates. So, I prefer to have them in that way if it is not a real problem, of course. Changes in v4: - Add
[RESEND PATCH v5 6/6] MAINTAINERS: add MT7621 CLOCK maintainer
Adding myself as maintainer for mt7621 clock driver. Signed-off-by: Sergio Paracuellos --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index f5eafee83bc6..f0c51d9760ec 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11247,6 +11247,12 @@ L: linux-wirel...@vger.kernel.org S: Maintained F: drivers/net/wireless/mediatek/mt7601u/ +MEDIATEK MT7621 CLOCK DRIVER +M: Sergio Paracuellos +S: Maintained +F: Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml +F: drivers/clk/ralink/clk-mt7621.c + MEDIATEK MT7621/28/88 I2C DRIVER M: Stefan Roese L: linux-...@vger.kernel.org -- 2.25.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RESEND PATCH v5 3/6] clk: ralink: add clock driver for mt7621 SoC
The documentation for this SOC only talks about two registers regarding to the clocks: * SYSC_REG_CPLL_CLKCFG0 - provides some information about boostrapped refclock. PLL and dividers used for CPU and some sort of BUS. * SYSC_REG_CPLL_CLKCFG1 - a banch of gates to enable/disable clocks for all or some ip cores. Looking into driver code, and some openWRT patched there are another frequencies which are used in some drivers (uart, sd...). According to all of this information the clock plan for this SoC is set as follows: - Main top clock "xtal" from where all the rest of the world is derived. - CPU clock "cpu" derived from "xtal" frequencies and a bunch of register reads and predividers. - BUS clock "bus" derived from "cpu" and with (cpu / 4) MHz. - Fixed clocks from "xtal": * "50m": 50 MHz. * "125m": 125 MHz. * "150m": 150 MHz. * "250m": 250 MHz. * "270m": 270 MHz. We also have a buch of gate clocks with their parents: * "hsdma": "150m" * "fe": "250m" * "sp_divtx": "270m" * "timer": "50m" * "pcm": "270m" * "pio": "50m" * "gdma": "bus" * "nand": "125m" * "i2c": "50m" * "i2s": "270m" * "spi": "bus" * "uart1": "50m" * "uart2": "50m" * "uart3": "50m" * "eth": "50m" * "pcie0": "125m" * "pcie1": "125m" * "pcie2": "125m" * "crypto": "250m" * "shxc": "50m" With this information the clk driver will provide clock and gates functionality from a a set of hardcoded clocks allowing to define a nice device tree without fixed clocks. Signed-off-by: Sergio Paracuellos --- drivers/clk/Kconfig | 1 + drivers/clk/Makefile| 1 + drivers/clk/ralink/Kconfig | 14 ++ drivers/clk/ralink/Makefile | 2 + drivers/clk/ralink/clk-mt7621.c | 411 5 files changed, 429 insertions(+) create mode 100644 drivers/clk/ralink/Kconfig create mode 100644 drivers/clk/ralink/Makefile create mode 100644 drivers/clk/ralink/clk-mt7621.c diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 85856cff506c..7c6ad73c985c 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -381,6 +381,7 @@ source "drivers/clk/mediatek/Kconfig" source "drivers/clk/meson/Kconfig" source "drivers/clk/mvebu/Kconfig" source "drivers/clk/qcom/Kconfig" +source "drivers/clk/ralink/Kconfig" source "drivers/clk/renesas/Kconfig" source "drivers/clk/rockchip/Kconfig" source "drivers/clk/samsung/Kconfig" diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index dbdc590e7de3..29b957d83c4e 100644 --- a/drivers/clk/Makefile +++ b/drivers/clk/Makefile @@ -101,6 +101,7 @@ obj-$(CONFIG_COMMON_CLK_NXP)+= nxp/ obj-$(CONFIG_MACH_PISTACHIO) += pistachio/ obj-$(CONFIG_COMMON_CLK_PXA) += pxa/ obj-$(CONFIG_COMMON_CLK_QCOM) += qcom/ +obj-y += ralink/ obj-y += renesas/ obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/ obj-$(CONFIG_COMMON_CLK_SAMSUNG) += samsung/ diff --git a/drivers/clk/ralink/Kconfig b/drivers/clk/ralink/Kconfig new file mode 100644 index ..f1de548ed781 --- /dev/null +++ b/drivers/clk/ralink/Kconfig @@ -0,0 +1,14 @@ +# SPDX-License-Identifier: GPL-2.0-only +# +# MediaTek Mt7621 Clock Driver +# +menu "Clock driver for Mediatek mt7621 SoC" + depends on SOC_MT7621 + +config CLK_MT7621 + bool "Clock driver for MediaTek MT7621" + depends on SOC_MT7621 + default SOC_MT7621 + help + This driver supports MediaTek MT7621 basic clocks. +endmenu diff --git a/drivers/clk/ralink/Makefile b/drivers/clk/ralink/Makefile new file mode 100644 index ..cf6f9216379d --- /dev/null +++ b/drivers/clk/ralink/Makefile @@ -0,0 +1,2 @@ +# SPDX-License-Identifier: GPL-2.0 +obj-$(CONFIG_CLK_MT7621) += clk-mt7621.o diff --git a/drivers/clk/ralink/clk-mt7621.c b/drivers/clk/ralink/clk-mt7621.c new file mode 100644 index ..52aa98318abf --- /dev/null +++ b/drivers/clk/ralink/clk-mt7621.c @@ -0,0 +1,411 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Mediatek MT7621 Clock Driver + * Author: Sergio Paracuellos + */ + +#include +#include +#include +#include +#include +#include + +/* Configuration registers */ +#define SYSC_REG_SYSTEM_CONFIG0 0x10 +#define SYSC_REG_SYSTEM_CONFIG1 0x14 +#define SYSC_REG_CLKCFG0 0x2c +#define SYSC_REG_CLKCFG1 0x30 +#define SYSC_REG_CUR_CLK_STS 0x44 + +#define MEMC_REG_CPU_PLL 0x648 +#define XTAL_MODE_SEL_MASK 0x7 +#define XTAL_MODE_SEL_SHIFT6 + +#define CPU_CLK_SEL_MASK 0x3 +#define CPU_CLK_SEL_SHIFT 30 + +#define CUR_CPU_FDIV_MASK 0x1f +#define CUR_CPU_FDIV_SHIFT 8 +#define CUR_CPU_FFRAC_MASK 0x1f +#define CUR_CPU_FFRAC_SHIFT0 + +#define CPU_PLL_PREDIV_MASK0x3 +#define CPU_PLL_PREDIV_SHIFT 12 +#define CPU_PLL_FBDIV_MASK
[RESEND PATCH v5 5/6] staging: mt7621-dts: use valid vendor 'mediatek' instead of invalid 'mtk'
Vendor listed for mediatek in kernel vendor file 'vendor-prefixes.yaml'
contains 'mediatek' as a valid vendor string. Some nodes in the device
tree are using an invalid vendor string vfor 'mtk' instead. Fix all of
them in dts file. Update also ralink mt7621 related code to properly
match new strings. Even there are used in the device tree there are
some strings that are not referred anywhere but have been also updated
with new vendor name. These are 'mtk,mt7621-wdt', 'mtk,mt7621-nand',
'mtk,mt7621-mc', and 'mtk,mt7621-cpc'.
Signed-off-by: Sergio Paracuellos
---
arch/mips/ralink/mt7621.c | 6 +++---
drivers/staging/mt7621-dts/mt7621.dtsi | 12 ++--
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/mips/ralink/mt7621.c b/arch/mips/ralink/mt7621.c
index ca0ac607b0f3..5d74fc1c96ac 100644
--- a/arch/mips/ralink/mt7621.c
+++ b/arch/mips/ralink/mt7621.c
@@ -112,8 +112,8 @@ phys_addr_t mips_cpc_default_phys_base(void)
void __init ralink_of_remap(void)
{
- rt_sysc_membase = plat_of_remap_node("mtk,mt7621-sysc");
- rt_memc_membase = plat_of_remap_node("mtk,mt7621-memc");
+ rt_sysc_membase = plat_of_remap_node("mediatek,mt7621-sysc");
+ rt_memc_membase = plat_of_remap_node("mediatek,mt7621-memc");
if (!rt_sysc_membase || !rt_memc_membase)
panic("Failed to remap core resources");
@@ -181,7 +181,7 @@ void prom_soc_init(struct ralink_soc_info *soc_info)
if (n0 == MT7621_CHIP_NAME0 && n1 == MT7621_CHIP_NAME1) {
name = "MT7621";
- soc_info->compatible = "mtk,mt7621-soc";
+ soc_info->compatible = "mediatek,mt7621-soc";
} else {
panic("mt7621: unknown SoC, n0:%08x n1:%08x\n", n0, n1);
}
diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
b/drivers/staging/mt7621-dts/mt7621.dtsi
index 51d83cb3b4ee..ba113e5ced51 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -56,7 +56,7 @@ palmbus: palmbus@1E00 {
#size-cells = <1>;
sysc: sysc@0 {
- compatible = "mtk,mt7621-sysc";
+ compatible = "mediatek,mt7621-sysc";
reg = <0x0 0x100>;
};
@@ -69,7 +69,7 @@ pll: pll {
};
wdt: wdt@100 {
- compatible = "mtk,mt7621-wdt";
+ compatible = "mediatek,mt7621-wdt";
reg = <0x100 0x100>;
};
@@ -126,17 +126,17 @@ i2s: i2s@a00 {
};
memc: memc@5000 {
- compatible = "mtk,mt7621-memc";
+ compatible = "mediatek,mt7621-memc";
reg = <0x5000 0x1000>;
};
cpc: cpc@1fbf {
-compatible = "mtk,mt7621-cpc";
+compatible = "mediatek,mt7621-cpc";
reg = <0x1fbf 0x8000>;
};
mc: mc@1fbf8000 {
- compatible = "mtk,mt7621-mc";
+ compatible = "mediatek,mt7621-mc";
reg = <0x1fbf8000 0x8000>;
};
@@ -369,7 +369,7 @@ timer {
nand: nand@1e003000 {
status = "disabled";
- compatible = "mtk,mt7621-nand";
+ compatible = "mediatek,mt7621-nand";
bank-width = <2>;
reg = <0x1e003000 0x800
0x1e003800 0x800>;
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RESEND PATCH v5 4/6] staging: mt7621-dts: make use of new 'mt7621-clk'
Clocks for SoC mt7621 have been properly integrated so there is
no need to declare fixed clocks at all in the device tree. Remove
all of them, add new device tree nodes for mt7621-clk and update
the rest of the nodes to use them.
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-dts/gbpc1.dts | 11
drivers/staging/mt7621-dts/mt7621.dtsi | 73 --
2 files changed, 34 insertions(+), 50 deletions(-)
diff --git a/drivers/staging/mt7621-dts/gbpc1.dts
b/drivers/staging/mt7621-dts/gbpc1.dts
index a7c0d3115d72..7716d0efe524 100644
--- a/drivers/staging/mt7621-dts/gbpc1.dts
+++ b/drivers/staging/mt7621-dts/gbpc1.dts
@@ -100,17 +100,6 @@ partition@5 {
};
};
- {
- compatible = "fixed-clock";
- /* This is normally 1/4 of cpuclock */
- clock-frequency = <22500>;
-};
-
- {
- compatible = "fixed-clock";
- clock-frequency = <9>;
-};
-
{
pinctrl-names = "default";
pinctrl-0 = <_pins>;
diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
b/drivers/staging/mt7621-dts/mt7621.dtsi
index 5b9d3bf82cb1..51d83cb3b4ee 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -1,5 +1,6 @@
#include
#include
+#include
/ {
#address-cells = <1>;
@@ -27,27 +28,6 @@ aliases {
serial0 =
};
- cpuclock: cpuclock@0 {
- #clock-cells = <0>;
- compatible = "fixed-clock";
-
- /* FIXME: there should be way to detect this */
- clock-frequency = <88000>;
- };
-
- sysclock: sysclock@0 {
- #clock-cells = <0>;
- compatible = "fixed-clock";
-
- /* This is normally 1/4 of cpuclock */
- clock-frequency = <22000>;
- };
-
- mmc_clock: mmc_clock@0 {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <4800>;
- };
mmc_fixed_3v3: fixedregulator@0 {
compatible = "regulator-fixed";
@@ -80,6 +60,14 @@ sysc: sysc@0 {
reg = <0x0 0x100>;
};
+ pll: pll {
+ compatible = "mediatek,mt7621-clk";
+ #clock-cells = <1>;
+ clock-output-names = "xtal", "cpu", "bus",
+"50m", "125m", "150m",
+"250m", "270m";
+ };
+
wdt: wdt@100 {
compatible = "mtk,mt7621-wdt";
reg = <0x100 0x100>;
@@ -101,8 +89,8 @@ i2c: i2c@900 {
compatible = "mediatek,mt7621-i2c";
reg = <0x900 0x100>;
- clocks = <>;
-
+ clocks = < MT7621_CLK_I2C>;
+ clock-names = "i2c";
resets = < 16>;
reset-names = "i2c";
@@ -119,8 +107,8 @@ i2s: i2s@a00 {
compatible = "mediatek,mt7621-i2s";
reg = <0xa00 0x100>;
- clocks = <>;
-
+ clocks = < MT7621_CLK_I2S>;
+ clock-names = "i2s";
resets = < 17>;
reset-names = "i2s";
@@ -156,8 +144,8 @@ uartlite: uartlite@c00 {
compatible = "ns16550a";
reg = <0xc00 0x100>;
- clocks = <>;
- clock-frequency = <5000>;
+ clocks = < MT7621_CLK_UART1>;
+ clock-names = "uart1";
interrupt-parent = <>;
interrupts = ;
@@ -173,7 +161,8 @@ spi0: spi@b00 {
compatible = "ralink,mt7621-spi";
reg = <0xb00 0x100>;
- clocks = <>;
+ clocks = < MT7621_CLK_SPI>;
+ clock-names = "spi";
resets = < 18>;
reset-names = "spi";
@@ -189,6 +178,8 @@ gdma: gdma@2800 {
compatible = "ralink,rt3883-gdma";
reg = <0x2800 0x800>;
+ clocks = < MT7621_CLK_GDMA>;
+ clock-names = "gdma";
resets = < 14>;
reset-names = "dma";
@@ -206,6 +197,8 @@ hsdma: hsdma@7000 {
compatible = "mediatek,mt7621-hsdma";
reg = <0x7000 0x1000>;
+ clocks = < MT7621_CLK_HSDMA>;
+ clock-names = "hsdma";
resets = < 5>;
reset-names = "hsdma";
@@ -316,11 +309,6 @@ rstctrl: rstctrl {
[RESEND PATCH v5 2/6] dt: bindings: add mt7621-clk device tree binding documentation
Adds device tree binding documentation for clocks in the
MT7621 SOC.
Signed-off-by: Sergio Paracuellos
---
.../bindings/clock/mediatek,mt7621-clk.yaml | 52 +++
1 file changed, 52 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
b/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
new file mode 100644
index ..f58d01bdc82c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mediatek,mt7621-clk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MT7621 Clock Device Tree Bindings
+
+maintainers:
+ - Sergio Paracuellos
+
+description: |
+ The MT7621 has a PLL controller from where the cpu clock is provided
+ as well as derived clocks for the bus and the peripherals. It also
+ can gate SoC device clocks.
+
+ Each clock is assigned an identifier and client nodes use this identifier
+ to specify the clock which they consume.
+
+ All these identifiers could be found in:
+ [1]: .
+
+properties:
+ compatible:
+const: mediatek,mt7621-clk
+
+ "#clock-cells":
+description:
+ The first cell indicates the clock number, see [1] for available
+ clocks.
+const: 1
+
+ clock-output-names:
+maxItems: 8
+
+required:
+ - compatible
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+pll {
+ compatible = "mediatek,mt7621-clk";
+ #clock-cells = <1>;
+ clock-output-names = "xtal", "cpu", "bus",
+ "50m", "125m", "150m",
+ "250m", "270m";
+};
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH -next] staging: nvec: minor coding style fix
Fix for the below coding style warning.
Warning: Move const after static - use 'static const int'
Signed-off-by: Fatih Yildirim
---
drivers/staging/nvec/nvec_power.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/nvec/nvec_power.c
b/drivers/staging/nvec/nvec_power.c
index 0e861c4bfcbf..b1ef196e1cfe 100644
--- a/drivers/staging/nvec/nvec_power.c
+++ b/drivers/staging/nvec/nvec_power.c
@@ -338,7 +338,7 @@ static const struct power_supply_desc nvec_psy_desc = {
};
static int counter;
-static int const bat_iter[] = {
+static const int bat_iter[] = {
SLOT_STATUS, VOLTAGE, CURRENT, CAPACITY_REMAINING,
#ifdef EC_FULL_DIAG
AVERAGE_CURRENT, TEMPERATURE, TIME_REMAINING,
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1 2/9] cpufreq: sfi-cpufreq: Remove driver for deprecated firmware
On 11-02-21, 15:40, Andy Shevchenko wrote: > SFI-based platforms are gone. So does this driver. > > Signed-off-by: Andy Shevchenko > Acked-by: Linus Walleij > --- > drivers/cpufreq/Kconfig.x86 | 10 --- > drivers/cpufreq/Makefile | 1 - > drivers/cpufreq/sfi-cpufreq.c | 127 -- > 3 files changed, 138 deletions(-) > delete mode 100644 drivers/cpufreq/sfi-cpufreq.c Acked-by: Viresh Kumar -- viresh ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: wimax: Fix some coding style problem
This fixes checkpatch error "open brace '{' following struct go on
the same line" in file drivers/staging/wimax/i2400m/rx.c .
Signed-off-by: Hemansh Agnihotri
---
drivers/staging/wimax/i2400m/rx.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/wimax/i2400m/rx.c
b/drivers/staging/wimax/i2400m/rx.c
index 5b3a85035f6a..702a1e2fabcd 100644
--- a/drivers/staging/wimax/i2400m/rx.c
+++ b/drivers/staging/wimax/i2400m/rx.c
@@ -485,8 +485,7 @@ struct i2400m_roq_data {
* store the sequence number (sn) and the cs (packet type) coming from
* the RX payload header from the device.
*/
-struct i2400m_roq
-{
+struct i2400m_roq {
unsigned ws;
struct sk_buff_head queue;
struct i2400m_roq_log *log;
--
2.30.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 0/6] MIPS: ralink: add CPU clock detection and clock driver for MT7621
Quoting Sergio Paracuellos (2021-01-17 06:19:36) > Hi all, > > On Sun, Dec 20, 2020 at 10:37 AM Sergio Paracuellos > wrote: > > > > - Hardcode "xtal" as parent in FIXED macro. > > - Change 'else if' clause into 'if' clause since a return statement was > >being used in 'mt7621_xtal_recalc_rate'. > > > > NOTES: > >- Driver is still being declared using 'CLK_OF_DECLARE' for all the > > clocks. I have explored the possibility to make some of them available > > afterwards using 'CLK_OF_DECLARE_DRIVER' for top clocks and the rest > > using a platform driver. The resulting code was uglier since we only > > want > > to use the same device tree node and the top clocks must be copied > > again > > for the new platform register stuff to properly have a good hierarchy. > > New globals needs to be introduced and in this particular case I don't > > really see the benefits of doing in this way. I am totally ok to have > > all > > the clocks registered at early stage since from other drivers > > perspective > > we only really need to enable gates. So, I prefer to have them in that > > way if it is not a real problem, of course. > > Any comments on this? Is ok to maintain this as it is done in this > version or should I change this to any other approach taking into > account my comments in device tree related PATCH? Nothing has been > suggested there yet. > Please resend. It seems to have fallen off of DT review list. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: vt6656: Fixed issue with alignment in rf.c
This change fixes a checkpatch CHECK style issue for "Alignment should
match open parenthesis".
Signed-off-by: Pritthijit Nath
---
Fixed trailing space in changelog.
drivers/staging/vt6656/rf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
index 5b8da06e3916..bcd4d467e03a 100644
--- a/drivers/staging/vt6656/rf.c
+++ b/drivers/staging/vt6656/rf.c
@@ -687,7 +687,7 @@ static int vnt_rf_set_txpower(struct vnt_private *priv, u8
power,
if (hw_value < ARRAY_SIZE(vt3226d0_lo_current_table)) {
ret = vnt_rf_write_embedded(priv,
- vt3226d0_lo_current_table[hw_value]);
+
vt3226d0_lo_current_table[hw_value]);
if (ret)
return ret;
}
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: vt6656: Fixed issue with alignment in rf.c
This change fixes a checkpatch CHECK style issue for "Alignment should
match open parenthesis".
Signed-off-by: Pritthijit Nath
---
drivers/staging/vt6656/rf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
index 5b8da06e3916..bcd4d467e03a 100644
--- a/drivers/staging/vt6656/rf.c
+++ b/drivers/staging/vt6656/rf.c
@@ -687,7 +687,7 @@ static int vnt_rf_set_txpower(struct vnt_private *priv, u8
power,
if (hw_value < ARRAY_SIZE(vt3226d0_lo_current_table)) {
ret = vnt_rf_write_embedded(priv,
- vt3226d0_lo_current_table[hw_value]);
+
vt3226d0_lo_current_table[hw_value]);
if (ret)
return ret;
}
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: vt6656: Fixed issue with alignment in rf.c
On 12/02/21 2:14 am, Greg KH wrote:
> On Fri, Feb 12, 2021 at 02:07:50AM +0530, Pritthijit Nath wrote:
>> On 12/02/21 1:59 am, Greg KH wrote:
>>> On Thu, Feb 11, 2021 at 08:54:26PM +0530, Pritthijit Nath wrote:
This change fixes a checkpatch CHECK style issue for "Alignment should
match open parenthesis".
Signed-off-by: Pritthijit Nath
---
drivers/staging/vt6656/rf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
index 5b8da06e3916..bcd4d467e03a 100644
--- a/drivers/staging/vt6656/rf.c
+++ b/drivers/staging/vt6656/rf.c
@@ -687,7 +687,7 @@ static int vnt_rf_set_txpower(struct vnt_private
*priv, u8 power,
if (hw_value < ARRAY_SIZE(vt3226d0_lo_current_table)) {
ret = vnt_rf_write_embedded(priv,
- vt3226d0_lo_current_table[hw_value]);
+
vt3226d0_lo_current_table[hw_value]);
if (ret)
return ret;
}
--
2.25.1
>>>
>>> Please run this change, with the changelog above, through
>>> checkpatch.pl, fix that, and resend.
>>>
>>> thanks,
>>>
>>> greg k-h
>>>
>>
>> This change fixes a checkpatch CHECK style issue for "Alignment should
>> match open parenthesis".
>>
>> Signed-off-by: Pritthijit Nath
>> ---
>> drivers/staging/vt6656/rf.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
>> index 5b8da06e3916..bcd4d467e03a 100644
>> --- a/drivers/staging/vt6656/rf.c
>> +++ b/drivers/staging/vt6656/rf.c
>> @@ -687,7 +687,7 @@ static int vnt_rf_set_txpower(struct vnt_private *priv,
>> u8 power,
>>
>> if (hw_value < ARRAY_SIZE(vt3226d0_lo_current_table)) {
>> ret = vnt_rf_write_embedded(priv,
>> -vt3226d0_lo_current_table[hw_value]);
>> +
>> vt3226d0_lo_current_table[hw_value]);
>> if (ret)
>> return ret;
>> }
>
> I can't take this type of submission, do you see other patches submitted
> this way on the mailing list?
Actually I am having a hard time since this one's my first. I would really
appreciate if you could be a little clear. Should I resend the entire patch as
a new thread?
>
> Also, you have a trailing space in your changelog text :(
Thanks for pointing out. Yes, I have fixed the trailing space.
>
> thanks,
>
> greg k-h
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: vt6656: Fixed issue with alignment in rf.c
On 12/02/21 1:59 am, Greg KH wrote:
> On Thu, Feb 11, 2021 at 08:54:26PM +0530, Pritthijit Nath wrote:
>> This change fixes a checkpatch CHECK style issue for "Alignment should match
>> open parenthesis".
>>
>> Signed-off-by: Pritthijit Nath
>> ---
>> drivers/staging/vt6656/rf.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
>> index 5b8da06e3916..bcd4d467e03a 100644
>> --- a/drivers/staging/vt6656/rf.c
>> +++ b/drivers/staging/vt6656/rf.c
>> @@ -687,7 +687,7 @@ static int vnt_rf_set_txpower(struct vnt_private *priv,
>> u8 power,
>>
>> if (hw_value < ARRAY_SIZE(vt3226d0_lo_current_table)) {
>> ret = vnt_rf_write_embedded(priv,
>> -vt3226d0_lo_current_table[hw_value]);
>> +
>> vt3226d0_lo_current_table[hw_value]);
>> if (ret)
>> return ret;
>> }
>> --
>> 2.25.1
>
> Please run this change, with the changelog above, through
> checkpatch.pl, fix that, and resend.
>
> thanks,
>
> greg k-h
>
This change fixes a checkpatch CHECK style issue for "Alignment should
match open parenthesis".
Signed-off-by: Pritthijit Nath
---
drivers/staging/vt6656/rf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
index 5b8da06e3916..bcd4d467e03a 100644
--- a/drivers/staging/vt6656/rf.c
+++ b/drivers/staging/vt6656/rf.c
@@ -687,7 +687,7 @@ static int vnt_rf_set_txpower(struct vnt_private *priv, u8
power,
if (hw_value < ARRAY_SIZE(vt3226d0_lo_current_table)) {
ret = vnt_rf_write_embedded(priv,
- vt3226d0_lo_current_table[hw_value]);
+
vt3226d0_lo_current_table[hw_value]);
if (ret)
return ret;
}
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
11-02-2021
I am Mrs. Yara Mariam Abdul-Azeez 57 years old suffering from long term cancer of the blood (leukemia) and according to the doctors i have very few months to spend in this world before I die due to the fact that the cancer is in it's third and final stage and has affected many vital organs in my lower body and made me paralyzed. I am just here to make good friends and share with you the message of Almighty GOD before I die. God Bless You Mrs Yara Mariam Abdul-Azeez. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: vt6656: Fixed issue with alignment in rf.c
On Fri, Feb 12, 2021 at 02:56:47AM +0530, Pritthijit Nath wrote:
> This change fixes a checkpatch CHECK style issue for "Alignment should
> match open parenthesis".
>
> Signed-off-by: Pritthijit Nath
> ---
> drivers/staging/vt6656/rf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
> index 5b8da06e3916..bcd4d467e03a 100644
> --- a/drivers/staging/vt6656/rf.c
> +++ b/drivers/staging/vt6656/rf.c
> @@ -687,7 +687,7 @@ static int vnt_rf_set_txpower(struct vnt_private *priv,
> u8 power,
>
> if (hw_value < ARRAY_SIZE(vt3226d0_lo_current_table)) {
> ret = vnt_rf_write_embedded(priv,
> - vt3226d0_lo_current_table[hw_value]);
> +
> vt3226d0_lo_current_table[hw_value]);
> if (ret)
> return ret;
> }
> --
> 2.25.1
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- This looks like a new version of a previously submitted patch, but you
did not list below the --- line any changes from the previous version.
Please read the section entitled "The canonical patch format" in the
kernel file, Documentation/SubmittingPatches for what needs to be done
here to properly describe this.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: vt6656: Fixed issue with alignment in rf.c
On Fri, Feb 12, 2021 at 02:32:51AM +0530, Pritthijit Nath wrote:
> On 12/02/21 2:14 am, Greg KH wrote:
> > On Fri, Feb 12, 2021 at 02:07:50AM +0530, Pritthijit Nath wrote:
> >> On 12/02/21 1:59 am, Greg KH wrote:
> >>> On Thu, Feb 11, 2021 at 08:54:26PM +0530, Pritthijit Nath wrote:
> This change fixes a checkpatch CHECK style issue for "Alignment should
> match open parenthesis".
>
> Signed-off-by: Pritthijit Nath
> ---
> drivers/staging/vt6656/rf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
> index 5b8da06e3916..bcd4d467e03a 100644
> --- a/drivers/staging/vt6656/rf.c
> +++ b/drivers/staging/vt6656/rf.c
> @@ -687,7 +687,7 @@ static int vnt_rf_set_txpower(struct vnt_private
> *priv, u8 power,
>
> if (hw_value <
> ARRAY_SIZE(vt3226d0_lo_current_table)) {
> ret = vnt_rf_write_embedded(priv,
> -
> vt3226d0_lo_current_table[hw_value]);
> +
> vt3226d0_lo_current_table[hw_value]);
> if (ret)
> return ret;
> }
> --
> 2.25.1
> >>>
> >>> Please run this change, with the changelog above, through
> >>> checkpatch.pl, fix that, and resend.
> >>>
> >>> thanks,
> >>>
> >>> greg k-h
> >>>
> >>
> >> This change fixes a checkpatch CHECK style issue for "Alignment should
> >> match open parenthesis".
> >>
> >> Signed-off-by: Pritthijit Nath
> >> ---
> >> drivers/staging/vt6656/rf.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
> >> index 5b8da06e3916..bcd4d467e03a 100644
> >> --- a/drivers/staging/vt6656/rf.c
> >> +++ b/drivers/staging/vt6656/rf.c
> >> @@ -687,7 +687,7 @@ static int vnt_rf_set_txpower(struct vnt_private
> >> *priv, u8 power,
> >>
> >>if (hw_value < ARRAY_SIZE(vt3226d0_lo_current_table)) {
> >>ret = vnt_rf_write_embedded(priv,
> >> - vt3226d0_lo_current_table[hw_value]);
> >> +
> >> vt3226d0_lo_current_table[hw_value]);
> >>if (ret)
> >>return ret;
> >>}
> >
> > I can't take this type of submission, do you see other patches submitted
> > this way on the mailing list?
> Actually I am having a hard time since this one's my first. I would really
> appreciate if you could be a little clear. Should I resend the entire patch
> as a new thread?
Of course, the kernel documentation says to do this, correct?
Look at the patches on the list for examples of how this works.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] removed enclosed parenthesis errors given by checkpatch.pl
On Fri, Feb 12, 2021 at 02:27:39AM +0530, roz wrote:
> Signed-off-by: roz
> ---
> drivers/staging/ks7010/ks_hostif.h | 24
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/staging/ks7010/ks_hostif.h
> b/drivers/staging/ks7010/ks_hostif.h
> index 39138191a556..c62a494ed6bb 100644
> --- a/drivers/staging/ks7010/ks_hostif.h
> +++ b/drivers/staging/ks7010/ks_hostif.h
> @@ -498,20 +498,20 @@ struct hostif_mic_failure_request {
> #define TX_RATE_FIXED5
>
> /* 11b rate */
> -#define TX_RATE_1M (u8)(10 / 5)/* 11b 11g basic rate */
> -#define TX_RATE_2M (u8)(20 / 5)/* 11b 11g basic rate */
> -#define TX_RATE_5M (u8)(55 / 5)/* 11g basic rate */
> -#define TX_RATE_11M (u8)(110 / 5) /* 11g basic rate */
> +#define TX_RATE_1M ((u8)(10 / 5)) /* 11b 11g basic rate */
> +#define TX_RATE_2M ((u8)(20 / 5)) /* 11b 11g basic rate */
> +#define TX_RATE_5M ((u8)(55 / 5)) /* 11g basic rate */
> +#define TX_RATE_11M ((u8)(110 / 5)) /* 11g basic rate */
>
> /* 11g rate */
> -#define TX_RATE_6M (u8)(60 / 5)/* 11g basic rate */
> -#define TX_RATE_12M (u8)(120 / 5) /* 11g basic rate */
> -#define TX_RATE_24M (u8)(240 / 5) /* 11g basic rate */
> -#define TX_RATE_9M (u8)(90 / 5)
> -#define TX_RATE_18M (u8)(180 / 5)
> -#define TX_RATE_36M (u8)(360 / 5)
> -#define TX_RATE_48M (u8)(480 / 5)
> -#define TX_RATE_54M (u8)(540 / 5)
> +#define TX_RATE_6M ((u8)(60 / 5)) /* 11g basic rate */
> +#define TX_RATE_12M ((u8)(120 / 5)) /* 11g basic rate */
> +#define TX_RATE_24M ((u8)(240 / 5)) /* 11g basic rate */
> +#define TX_RATE_9M ((u8)(90 / 5))
> +#define TX_RATE_18M ((u8)(180 / 5))
> +#define TX_RATE_36M ((u8)(360 / 5))
> +#define TX_RATE_48M ((u8)(480 / 5))
> +#define TX_RATE_54M ((u8)(540 / 5))
>
> static inline bool is_11b_rate(u8 rate)
> {
> --
> 2.27.0
>
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- You did not specify a description of why the patch is needed, or
possibly, any description at all, in the email body. Please read the
section entitled "The canonical patch format" in the kernel file,
Documentation/SubmittingPatches for what is needed in order to
properly describe the change.
- You did not write a descriptive Subject: for the patch, allowing Greg,
and everyone else, to know what this patch is all about. Please read
the section entitled "The canonical patch format" in the kernel file,
Documentation/SubmittingPatches for what a proper Subject: line should
look like.
- It looks like you did not use your "real" name for the patch on either
the Signed-off-by: line, or the From: line (both of which have to
match). Please read the kernel file, Documentation/SubmittingPatches
for how to do this correctly.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] removed enclosed parenthesis errors given by checkpatch.pl
Signed-off-by: roz
---
drivers/staging/ks7010/ks_hostif.h | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/ks7010/ks_hostif.h
b/drivers/staging/ks7010/ks_hostif.h
index 39138191a556..c62a494ed6bb 100644
--- a/drivers/staging/ks7010/ks_hostif.h
+++ b/drivers/staging/ks7010/ks_hostif.h
@@ -498,20 +498,20 @@ struct hostif_mic_failure_request {
#define TX_RATE_FIXED 5
/* 11b rate */
-#define TX_RATE_1M (u8)(10 / 5)/* 11b 11g basic rate */
-#define TX_RATE_2M (u8)(20 / 5)/* 11b 11g basic rate */
-#define TX_RATE_5M (u8)(55 / 5)/* 11g basic rate */
-#define TX_RATE_11M(u8)(110 / 5) /* 11g basic rate */
+#define TX_RATE_1M ((u8)(10 / 5)) /* 11b 11g basic rate */
+#define TX_RATE_2M ((u8)(20 / 5)) /* 11b 11g basic rate */
+#define TX_RATE_5M ((u8)(55 / 5)) /* 11g basic rate */
+#define TX_RATE_11M((u8)(110 / 5)) /* 11g basic rate */
/* 11g rate */
-#define TX_RATE_6M (u8)(60 / 5)/* 11g basic rate */
-#define TX_RATE_12M(u8)(120 / 5) /* 11g basic rate */
-#define TX_RATE_24M(u8)(240 / 5) /* 11g basic rate */
-#define TX_RATE_9M (u8)(90 / 5)
-#define TX_RATE_18M(u8)(180 / 5)
-#define TX_RATE_36M(u8)(360 / 5)
-#define TX_RATE_48M(u8)(480 / 5)
-#define TX_RATE_54M(u8)(540 / 5)
+#define TX_RATE_6M ((u8)(60 / 5)) /* 11g basic rate */
+#define TX_RATE_12M((u8)(120 / 5)) /* 11g basic rate */
+#define TX_RATE_24M((u8)(240 / 5)) /* 11g basic rate */
+#define TX_RATE_9M ((u8)(90 / 5))
+#define TX_RATE_18M((u8)(180 / 5))
+#define TX_RATE_36M((u8)(360 / 5))
+#define TX_RATE_48M((u8)(480 / 5))
+#define TX_RATE_54M((u8)(540 / 5))
static inline bool is_11b_rate(u8 rate)
{
--
2.27.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: vt6656: Fixed issue with alignment in rf.c
On Fri, Feb 12, 2021 at 02:07:50AM +0530, Pritthijit Nath wrote:
> On 12/02/21 1:59 am, Greg KH wrote:
> > On Thu, Feb 11, 2021 at 08:54:26PM +0530, Pritthijit Nath wrote:
> >> This change fixes a checkpatch CHECK style issue for "Alignment should
> >> match open parenthesis".
> >>
> >> Signed-off-by: Pritthijit Nath
> >> ---
> >> drivers/staging/vt6656/rf.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
> >> index 5b8da06e3916..bcd4d467e03a 100644
> >> --- a/drivers/staging/vt6656/rf.c
> >> +++ b/drivers/staging/vt6656/rf.c
> >> @@ -687,7 +687,7 @@ static int vnt_rf_set_txpower(struct vnt_private
> >> *priv, u8 power,
> >>
> >>if (hw_value < ARRAY_SIZE(vt3226d0_lo_current_table)) {
> >>ret = vnt_rf_write_embedded(priv,
> >> - vt3226d0_lo_current_table[hw_value]);
> >> +
> >> vt3226d0_lo_current_table[hw_value]);
> >>if (ret)
> >>return ret;
> >>}
> >> --
> >> 2.25.1
> >
> > Please run this change, with the changelog above, through
> > checkpatch.pl, fix that, and resend.
> >
> > thanks,
> >
> > greg k-h
> >
>
> This change fixes a checkpatch CHECK style issue for "Alignment should
> match open parenthesis".
>
> Signed-off-by: Pritthijit Nath
> ---
> drivers/staging/vt6656/rf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
> index 5b8da06e3916..bcd4d467e03a 100644
> --- a/drivers/staging/vt6656/rf.c
> +++ b/drivers/staging/vt6656/rf.c
> @@ -687,7 +687,7 @@ static int vnt_rf_set_txpower(struct vnt_private *priv,
> u8 power,
>
> if (hw_value < ARRAY_SIZE(vt3226d0_lo_current_table)) {
> ret = vnt_rf_write_embedded(priv,
> - vt3226d0_lo_current_table[hw_value]);
> +
> vt3226d0_lo_current_table[hw_value]);
> if (ret)
> return ret;
> }
I can't take this type of submission, do you see other patches submitted
this way on the mailing list?
Also, you have a trailing space in your changelog text :(
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wimax/i2400m: fix some byte order issues found by sparse
On Fri, Feb 12, 2021 at 01:59:08AM +0530, Anirudh Rayabharam wrote:
> Fix sparse byte-order warnings in the i2400m_bm_cmd_prepare()
> function:
>
> wimax/i2400m/fw.c:194:36: warning: restricted __le32 degrades to integer
> wimax/i2400m/fw.c:195:34: warning: invalid assignment: +=
> wimax/i2400m/fw.c:195:34:left side has type unsigned int
> wimax/i2400m/fw.c:195:34:right side has type restricted __le32
> wimax/i2400m/fw.c:196:32: warning: restricted __le32 degrades to integer
> wimax/i2400m/fw.c:196:47: warning: restricted __le32 degrades to integer
> wimax/i2400m/fw.c:196:66: warning: restricted __le32 degrades to integer
>
> Signed-off-by: Anirudh Rayabharam
> ---
> drivers/staging/wimax/i2400m/fw.c | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/wimax/i2400m/fw.c
> b/drivers/staging/wimax/i2400m/fw.c
> index b2fd4bd2c5f9..bce651a6b543 100644
> --- a/drivers/staging/wimax/i2400m/fw.c
> +++ b/drivers/staging/wimax/i2400m/fw.c
> @@ -189,12 +189,16 @@ void i2400m_bm_cmd_prepare(struct i2400m_bootrom_header
> *cmd)
> {
> if (i2400m_brh_get_use_checksum(cmd)) {
> int i;
> - u32 checksum = 0;
> + __le32 checksum = 0;
__le32 is only for when the data crosses the kernel/user boundry, just
use le32 in the kernel for stuff like this.
> const u32 *checksum_ptr = (void *) cmd->payload;
Add a blank line here, right?
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wimax: Fix some coding style problems
On Thu, Feb 11, 2021 at 10:43:20PM +0530, Hemansh Agnihotri wrote:
> This fixes checkpatch errors :- "else should follow close brace '}'",
> "space required before the open parenthesis '('" and "spaces required
> around that '?' (ctx:VxW)" in drivers/staging/wimax/i2400m/rx.c file.
>
> Signed-off-by: Hemansh Agnihotri
> ---
> drivers/staging/wimax/i2400m/rx.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/wimax/i2400m/rx.c
> b/drivers/staging/wimax/i2400m/rx.c
> index 5b3a85035f6a..8ea0bd039ed7 100644
> --- a/drivers/staging/wimax/i2400m/rx.c
> +++ b/drivers/staging/wimax/i2400m/rx.c
> @@ -485,8 +485,7 @@ struct i2400m_roq_data {
> * store the sequence number (sn) and the cs (packet type) coming from
> * the RX payload header from the device.
> */
> -struct i2400m_roq
> -{
> +struct i2400m_roq {
> unsigned ws;
> struct sk_buff_head queue;
> struct i2400m_roq_log *log;
> @@ -556,7 +555,7 @@ void i2400m_roq_log_entry_print(struct i2400m *i2400m,
> unsigned index,
> {
> struct device *dev = i2400m_dev(i2400m);
>
> - switch(e->type) {
> + switch (e->type) {
> case I2400M_RO_TYPE_RESET:
> dev_err(dev, "q#%d reset ws %u cnt %u sn %u/%u"
> " - new nws %u\n",
> @@ -1046,7 +1045,7 @@ void i2400m_rx_edata(struct i2400m *i2400m, struct
> sk_buff *skb_rx,
>ro_type, ro_cin, roq->ws, ro_sn,
>__i2400m_roq_nsn(roq, ro_sn), size);
> d_dump(2, dev, payload, size);
> - switch(ro_type) {
> + switch (ro_type) {
> case I2400M_RO_TYPE_RESET:
> i2400m_roq_reset(i2400m, roq);
> kfree_skb(skb); /* no data here */
> @@ -1346,7 +1345,7 @@ int i2400m_rx_setup(struct i2400m *i2400m)
> {
> int result = 0;
>
> - i2400m->rx_reorder = i2400m_rx_reorder_disabled? 0 : 1;
> + i2400m->rx_reorder = i2400m_rx_reorder_disabled ? 0 : 1;
> if (i2400m->rx_reorder) {
> unsigned itr;
> struct i2400m_roq_log *rd;
> @@ -1365,7 +1364,7 @@ int i2400m_rx_setup(struct i2400m *i2400m)
> goto error_roq_log_alloc;
> }
>
> - for(itr = 0; itr < I2400M_RO_CIN + 1; itr++) {
> + for (itr = 0; itr < I2400M_RO_CIN + 1; itr++) {
> __i2400m_roq_init(>rx_roq[itr]);
> i2400m->rx_roq[itr].log = [itr];
> }
> --
> 2.30.0
>
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- Your patch did many different things all at once, making it difficult
to review. All Linux kernel patches need to only do one thing at a
time. If you need to do multiple things (such as clean up all coding
style issues in a file/driver), do it in a sequence of patches, each
one doing only one thing. This will make it easier to review the
patches to ensure that they are correct, and to help alleviate any
merge issues that larger patches can cause.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: greybus: Fixed misspelling and alignment issue in hid.c
On Thu, Feb 11, 2021 at 09:00:01PM +0530, Pritthijit Nath wrote: > This change fixes a checkpatch CHECK style issue for "Alignment should match > open parenthesis". > In addition the misspelling of "transferred" also has been fixed. When you say "also" or "in addition" in a changelog, that is a huge hint that this needs to be broken up into multiple patches. Please do so, and fix your changelog ling length and send this as a patch series. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: wimax/i2400m: fix some byte order issues found by sparse
Fix sparse byte-order warnings in the i2400m_bm_cmd_prepare()
function:
wimax/i2400m/fw.c:194:36: warning: restricted __le32 degrades to integer
wimax/i2400m/fw.c:195:34: warning: invalid assignment: +=
wimax/i2400m/fw.c:195:34:left side has type unsigned int
wimax/i2400m/fw.c:195:34:right side has type restricted __le32
wimax/i2400m/fw.c:196:32: warning: restricted __le32 degrades to integer
wimax/i2400m/fw.c:196:47: warning: restricted __le32 degrades to integer
wimax/i2400m/fw.c:196:66: warning: restricted __le32 degrades to integer
Signed-off-by: Anirudh Rayabharam
---
drivers/staging/wimax/i2400m/fw.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/wimax/i2400m/fw.c
b/drivers/staging/wimax/i2400m/fw.c
index b2fd4bd2c5f9..bce651a6b543 100644
--- a/drivers/staging/wimax/i2400m/fw.c
+++ b/drivers/staging/wimax/i2400m/fw.c
@@ -189,12 +189,16 @@ void i2400m_bm_cmd_prepare(struct i2400m_bootrom_header
*cmd)
{
if (i2400m_brh_get_use_checksum(cmd)) {
int i;
- u32 checksum = 0;
+ __le32 checksum = 0;
const u32 *checksum_ptr = (void *) cmd->payload;
- for (i = 0; i < cmd->data_size / 4; i++)
- checksum += cpu_to_le32(*checksum_ptr++);
- checksum += cmd->command + cmd->target_addr + cmd->data_size;
- cmd->block_checksum = cpu_to_le32(checksum);
+ for (i = 0; i < le32_to_cpu(cmd->data_size) / 4; i++)
+ le32_add_cpu(, *checksum_ptr++);
+
+ le32_add_cpu(, le32_to_cpu(cmd->command));
+ le32_add_cpu(, le32_to_cpu(cmd->target_addr));
+ le32_add_cpu(, le32_to_cpu(cmd->data_size));
+
+ cmd->block_checksum = checksum;
}
}
EXPORT_SYMBOL_GPL(i2400m_bm_cmd_prepare);
--
2.26.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: vt6656: Fixed issue with alignment in rf.c
On Thu, Feb 11, 2021 at 08:54:26PM +0530, Pritthijit Nath wrote:
> This change fixes a checkpatch CHECK style issue for "Alignment should match
> open parenthesis".
>
> Signed-off-by: Pritthijit Nath
> ---
> drivers/staging/vt6656/rf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
> index 5b8da06e3916..bcd4d467e03a 100644
> --- a/drivers/staging/vt6656/rf.c
> +++ b/drivers/staging/vt6656/rf.c
> @@ -687,7 +687,7 @@ static int vnt_rf_set_txpower(struct vnt_private *priv,
> u8 power,
>
> if (hw_value < ARRAY_SIZE(vt3226d0_lo_current_table)) {
> ret = vnt_rf_write_embedded(priv,
> - vt3226d0_lo_current_table[hw_value]);
> +
> vt3226d0_lo_current_table[hw_value]);
> if (ret)
> return ret;
> }
> --
> 2.25.1
Please run this change, with the changelog above, through
checkpatch.pl, fix that, and resend.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: greybus: Fixed misspelling and alignment issue in hid.c
This change fixes a checkpatch CHECK style issue for "Alignment should match
open parenthesis".
In addition the misspelling of "transferred" also has been fixed.
Signed-off-by: Pritthijit Nath
---
drivers/staging/greybus/hid.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/greybus/hid.c b/drivers/staging/greybus/hid.c
index ed706f39e87a..adb91286803a 100644
--- a/drivers/staging/greybus/hid.c
+++ b/drivers/staging/greybus/hid.c
@@ -221,8 +221,8 @@ static void gb_hid_init_reports(struct gb_hid *ghid)
}
static int __gb_hid_get_raw_report(struct hid_device *hid,
- unsigned char report_number, __u8 *buf, size_t count,
- unsigned char report_type)
+ unsigned char report_number, __u8 *buf,
size_t count,
+ unsigned char report_type)
{
struct gb_hid *ghid = hid->driver_data;
int ret;
@@ -254,7 +254,7 @@ static int __gb_hid_output_raw_report(struct hid_device
*hid, __u8 *buf,
ret = gb_hid_set_report(ghid, report_type, report_id, buf, len);
if (report_id && ret >= 0)
- ret++; /* add report_id to the number of transfered bytes */
+ ret++; /* add report_id to the number of transferred bytes */
return 0;
}
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: vt6656: Fixed issue with alignment in rf.c
This change fixes a checkpatch CHECK style issue for "Alignment should match
open parenthesis".
Signed-off-by: Pritthijit Nath
---
drivers/staging/vt6656/rf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
index 5b8da06e3916..bcd4d467e03a 100644
--- a/drivers/staging/vt6656/rf.c
+++ b/drivers/staging/vt6656/rf.c
@@ -687,7 +687,7 @@ static int vnt_rf_set_txpower(struct vnt_private *priv, u8
power,
if (hw_value < ARRAY_SIZE(vt3226d0_lo_current_table)) {
ret = vnt_rf_write_embedded(priv,
- vt3226d0_lo_current_table[hw_value]);
+
vt3226d0_lo_current_table[hw_value]);
if (ret)
return ret;
}
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: vt6656: Fixed alignment with issue in rf.c
On 11/02/21 7:15 pm, Pritthijit Nath wrote:
> This change fixes a checkpatch CHECK style issue for "Alignment should match
> open parenthesis".
>
> Signed-off-by: Pritthijit Nath
> ---
> drivers/staging/vt6656/rf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
> index 5b8da06e3916..bcd4d467e03a 100644
> --- a/drivers/staging/vt6656/rf.c
> +++ b/drivers/staging/vt6656/rf.c
> @@ -687,7 +687,7 @@ static int vnt_rf_set_txpower(struct vnt_private *priv,
> u8 power,
>
> if (hw_value < ARRAY_SIZE(vt3226d0_lo_current_table)) {
> ret = vnt_rf_write_embedded(priv,
> - vt3226d0_lo_current_table[hw_value]);
> +
> vt3226d0_lo_current_table[hw_value]);
> if (ret)
> return ret;
> }
>
I am resubmitting this patch. Pardon the typo in the subject line.
thanks,
Pritthijit
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: vt6656: Fixed alignment with issue in rf.c
This change fixes a checkpatch CHECK style issue for "Alignment should match
open parenthesis".
Signed-off-by: Pritthijit Nath
---
drivers/staging/vt6656/rf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
index 5b8da06e3916..bcd4d467e03a 100644
--- a/drivers/staging/vt6656/rf.c
+++ b/drivers/staging/vt6656/rf.c
@@ -687,7 +687,7 @@ static int vnt_rf_set_txpower(struct vnt_private *priv, u8
power,
if (hw_value < ARRAY_SIZE(vt3226d0_lo_current_table)) {
ret = vnt_rf_write_embedded(priv,
- vt3226d0_lo_current_table[hw_value]);
+
vt3226d0_lo_current_table[hw_value]);
if (ret)
return ret;
}
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wlan-ng: Fix comments typos
On Thu, Feb 11, 2021 at 05:55:18PM +0100, Mairo P. Rufus wrote: > > Hi, > > > > This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him > > a patch that has triggered this response. He used to manually respond > > to these common problems, but in order to save his sanity (he kept > > writing the same thing over and over, yet to different people), I was > > created. Hopefully you will not take offence and will fix the problem > > in your patch and resubmit it so that it can be accepted into the Linux > > kernel tree. > > > > You are receiving this message because of the following common error(s) > > as indicated below: > > > > - You did not specify a description of why the patch is needed, or > > possibly, any description at all, in the email body. Please read the > > section entitled "The canonical patch format" in the kernel file, > > Documentation/SubmittingPatches for what is needed in order to > > properly describe the change. > > > > - You did not write a descriptive Subject: for the patch, allowing Greg, > > and everyone else, to know what this patch is all about. Please read > > the section entitled "The canonical patch format" in the kernel file, > > Documentation/SubmittingPatches for what a proper Subject: line should > > look like. > > > > If you wish to discuss this problem further, or you have questions about > > how to resolve this issue, please feel free to respond to this email and > > Greg will reply once he has dug out from the pending patches received > > from other developers. > > > > thanks, > > > > greg k-h's patch email bot > > After double checking, I still can't figure out what I did wrong. I'm > sorry for abusing your time, but can you help me on this one? You don't quote your changelog text here, so it's hard to determine what needs to be done. But your subject line could use a lot of work, don't you agree? Read the above links for how to write a good one. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: wimax: Fix some coding style problems
This fixes checkpatch errors :- "else should follow close brace '}'",
"space required before the open parenthesis '('" and "spaces required
around that '?' (ctx:VxW)" in drivers/staging/wimax/i2400m/rx.c file.
Signed-off-by: Hemansh Agnihotri
---
drivers/staging/wimax/i2400m/rx.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/wimax/i2400m/rx.c
b/drivers/staging/wimax/i2400m/rx.c
index 5b3a85035f6a..8ea0bd039ed7 100644
--- a/drivers/staging/wimax/i2400m/rx.c
+++ b/drivers/staging/wimax/i2400m/rx.c
@@ -485,8 +485,7 @@ struct i2400m_roq_data {
* store the sequence number (sn) and the cs (packet type) coming from
* the RX payload header from the device.
*/
-struct i2400m_roq
-{
+struct i2400m_roq {
unsigned ws;
struct sk_buff_head queue;
struct i2400m_roq_log *log;
@@ -556,7 +555,7 @@ void i2400m_roq_log_entry_print(struct i2400m *i2400m,
unsigned index,
{
struct device *dev = i2400m_dev(i2400m);
- switch(e->type) {
+ switch (e->type) {
case I2400M_RO_TYPE_RESET:
dev_err(dev, "q#%d reset ws %u cnt %u sn %u/%u"
" - new nws %u\n",
@@ -1046,7 +1045,7 @@ void i2400m_rx_edata(struct i2400m *i2400m, struct
sk_buff *skb_rx,
ro_type, ro_cin, roq->ws, ro_sn,
__i2400m_roq_nsn(roq, ro_sn), size);
d_dump(2, dev, payload, size);
- switch(ro_type) {
+ switch (ro_type) {
case I2400M_RO_TYPE_RESET:
i2400m_roq_reset(i2400m, roq);
kfree_skb(skb); /* no data here */
@@ -1346,7 +1345,7 @@ int i2400m_rx_setup(struct i2400m *i2400m)
{
int result = 0;
- i2400m->rx_reorder = i2400m_rx_reorder_disabled? 0 : 1;
+ i2400m->rx_reorder = i2400m_rx_reorder_disabled ? 0 : 1;
if (i2400m->rx_reorder) {
unsigned itr;
struct i2400m_roq_log *rd;
@@ -1365,7 +1364,7 @@ int i2400m_rx_setup(struct i2400m *i2400m)
goto error_roq_log_alloc;
}
- for(itr = 0; itr < I2400M_RO_CIN + 1; itr++) {
+ for (itr = 0; itr < I2400M_RO_CIN + 1; itr++) {
__i2400m_roq_init(>rx_roq[itr]);
i2400m->rx_roq[itr].log = [itr];
}
--
2.30.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wlan-ng: Fix comments typos
> Hi, > > This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him > a patch that has triggered this response. He used to manually respond > to these common problems, but in order to save his sanity (he kept > writing the same thing over and over, yet to different people), I was > created. Hopefully you will not take offence and will fix the problem > in your patch and resubmit it so that it can be accepted into the Linux > kernel tree. > > You are receiving this message because of the following common error(s) > as indicated below: > > - You did not specify a description of why the patch is needed, or > possibly, any description at all, in the email body. Please read the > section entitled "The canonical patch format" in the kernel file, > Documentation/SubmittingPatches for what is needed in order to > properly describe the change. > > - You did not write a descriptive Subject: for the patch, allowing Greg, > and everyone else, to know what this patch is all about. Please read > the section entitled "The canonical patch format" in the kernel file, > Documentation/SubmittingPatches for what a proper Subject: line should > look like. > > If you wish to discuss this problem further, or you have questions about > how to resolve this issue, please feel free to respond to this email and > Greg will reply once he has dug out from the pending patches received > from other developers. > > thanks, > > greg k-h's patch email bot After double checking, I still can't figure out what I did wrong. I'm sorry for abusing your time, but can you help me on this one? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wimax: Fix some coding style problems
On Thu, Feb 11, 2021 at 09:45:53PM +0530, Hemansh Agnihotri wrote:
> This fixes following warnings and errors as reported by checkpatch.pl:
> 1) WARNING: Missing a blank line after declarations
> 2) WARNING: Block comments use a trailing */ on a separate line
> 3) ERROR: code indent should use tabs where possible
> 4) ERROR: space required before the open parenthesis '('
> 5) ERROR: spaces required around that '?' (ctx:VxW)
> 6) ERROR: open brace '{' following struct go on the same line
>
> Signed-off-by: Hemansh Agnihotri
> ---
> drivers/staging/wimax/i2400m/netdev.c | 2 +-
> drivers/staging/wimax/i2400m/rx.c | 20 +---
> drivers/staging/wimax/i2400m/tx.c | 34 +++
> drivers/staging/wimax/i2400m/usb-rx.c | 8 +--
> drivers/staging/wimax/i2400m/usb.c| 10 +---
> drivers/staging/wimax/op-msg.c| 1 +
> drivers/staging/wimax/op-rfkill.c | 7 --
> drivers/staging/wimax/stack.c | 2 ++
> 8 files changed, 58 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/staging/wimax/i2400m/netdev.c
> b/drivers/staging/wimax/i2400m/netdev.c
> index cd06eaf75e8b..5b53e59084c8 100644
> --- a/drivers/staging/wimax/i2400m/netdev.c
> +++ b/drivers/staging/wimax/i2400m/netdev.c
> @@ -523,7 +523,7 @@ void i2400m_net_erx(struct i2400m *i2400m, struct sk_buff
> *skb,
>
> d_fnstart(2, dev, "(i2400m %p skb %p [%u] cs %d)\n",
> i2400m, skb, skb->len, cs);
> - switch(cs) {
> + switch (cs) {
> case I2400M_CS_IPV4_0:
> case I2400M_CS_IPV4:
> i2400m_rx_fake_eth_header(i2400m->wimax_dev.net_dev,
> diff --git a/drivers/staging/wimax/i2400m/rx.c
> b/drivers/staging/wimax/i2400m/rx.c
> index 5b3a85035f6a..036210a1fd55 100644
> --- a/drivers/staging/wimax/i2400m/rx.c
> +++ b/drivers/staging/wimax/i2400m/rx.c
> @@ -485,8 +485,7 @@ struct i2400m_roq_data {
> * store the sequence number (sn) and the cs (packet type) coming from
> * the RX payload header from the device.
> */
> -struct i2400m_roq
> -{
> +struct i2400m_roq {
> unsigned ws;
> struct sk_buff_head queue;
> struct i2400m_roq_log *log;
> @@ -522,6 +521,7 @@ static
> unsigned __i2400m_roq_nsn(struct i2400m_roq *roq, unsigned sn)
> {
> int r;
> +
> r = ((int) sn - (int) roq->ws) % 2048;
> if (r < 0)
> r += 2048;
> @@ -556,7 +556,7 @@ void i2400m_roq_log_entry_print(struct i2400m *i2400m,
> unsigned index,
> {
> struct device *dev = i2400m_dev(i2400m);
>
> - switch(e->type) {
> + switch (e->type) {
> case I2400M_RO_TYPE_RESET:
> dev_err(dev, "q#%d reset ws %u cnt %u sn %u/%u"
> " - new nws %u\n",
> @@ -694,7 +694,8 @@ void __i2400m_roq_queue(struct i2400m *i2400m, struct
> i2400m_roq *roq,
>* not empty, so we are not the first ones; we also know we
>* are not going to be the last ones. The list is sorted, so
>* we have to insert before the the first guy with an nsn_itr
> - * greater that our nsn. */
> + * greater that our nsn.
> + */
> skb_queue_walk(>queue, skb_itr) {
> roq_data_itr = (struct i2400m_roq_data *) _itr->cb;
> nsn_itr = __i2400m_roq_nsn(roq, roq_data_itr->sn);
> @@ -1016,7 +1017,8 @@ void i2400m_rx_edata(struct i2400m *i2400m, struct
> sk_buff *skb_rx,
> /* now we have to pull and trim so that the skb points to the
>* beginning of the IP packet; the netdev part will add the
>* ethernet header as needed - we know there is enough space
> - * because we checked in i2400m_rx_edata(). */
> + * because we checked in i2400m_rx_edata().
> + */
> skb_pull(skb, payload + sizeof(*hdr) - (void *) skb->data);
> skb_trim(skb, (void *) skb_end_pointer(skb) - payload - sizeof(*hdr));
>
> @@ -1046,7 +1048,7 @@ void i2400m_rx_edata(struct i2400m *i2400m, struct
> sk_buff *skb_rx,
>ro_type, ro_cin, roq->ws, ro_sn,
>__i2400m_roq_nsn(roq, ro_sn), size);
> d_dump(2, dev, payload, size);
> - switch(ro_type) {
> + switch (ro_type) {
> case I2400M_RO_TYPE_RESET:
> i2400m_roq_reset(i2400m, roq);
> kfree_skb(skb); /* no data here */
> @@ -1146,6 +1148,7 @@ int i2400m_rx_msg_hdr_check(struct i2400m *i2400m,
> {
> int result = -EIO;
> struct device *dev = i2400m_dev(i2400m);
> +
> if (buf_size < sizeof(*msg_hdr)) {
> dev_err(dev, "RX: HW BUG? message with short header (%zu "
> "vs %zu bytes expected)\n", buf_size, sizeof(*msg_hdr));
> @@ -1313,6 +1316,7 @@ void i2400m_unknown_barker(struct i2400m *i2400m,
> struct device *dev = i2400m_dev(i2400m);
> char prefix[64];
> const __le32 *barker = buf;
> +
> dev_err(dev, "RX: HW BUG? unknown barker
[PATCH] staging: wimax: Fix some coding style problems
This fixes following warnings and errors as reported by checkpatch.pl:
1) WARNING: Missing a blank line after declarations
2) WARNING: Block comments use a trailing */ on a separate line
3) ERROR: code indent should use tabs where possible
4) ERROR: space required before the open parenthesis '('
5) ERROR: spaces required around that '?' (ctx:VxW)
6) ERROR: open brace '{' following struct go on the same line
Signed-off-by: Hemansh Agnihotri
---
drivers/staging/wimax/i2400m/netdev.c | 2 +-
drivers/staging/wimax/i2400m/rx.c | 20 +---
drivers/staging/wimax/i2400m/tx.c | 34 +++
drivers/staging/wimax/i2400m/usb-rx.c | 8 +--
drivers/staging/wimax/i2400m/usb.c| 10 +---
drivers/staging/wimax/op-msg.c| 1 +
drivers/staging/wimax/op-rfkill.c | 7 --
drivers/staging/wimax/stack.c | 2 ++
8 files changed, 58 insertions(+), 26 deletions(-)
diff --git a/drivers/staging/wimax/i2400m/netdev.c
b/drivers/staging/wimax/i2400m/netdev.c
index cd06eaf75e8b..5b53e59084c8 100644
--- a/drivers/staging/wimax/i2400m/netdev.c
+++ b/drivers/staging/wimax/i2400m/netdev.c
@@ -523,7 +523,7 @@ void i2400m_net_erx(struct i2400m *i2400m, struct sk_buff
*skb,
d_fnstart(2, dev, "(i2400m %p skb %p [%u] cs %d)\n",
i2400m, skb, skb->len, cs);
- switch(cs) {
+ switch (cs) {
case I2400M_CS_IPV4_0:
case I2400M_CS_IPV4:
i2400m_rx_fake_eth_header(i2400m->wimax_dev.net_dev,
diff --git a/drivers/staging/wimax/i2400m/rx.c
b/drivers/staging/wimax/i2400m/rx.c
index 5b3a85035f6a..036210a1fd55 100644
--- a/drivers/staging/wimax/i2400m/rx.c
+++ b/drivers/staging/wimax/i2400m/rx.c
@@ -485,8 +485,7 @@ struct i2400m_roq_data {
* store the sequence number (sn) and the cs (packet type) coming from
* the RX payload header from the device.
*/
-struct i2400m_roq
-{
+struct i2400m_roq {
unsigned ws;
struct sk_buff_head queue;
struct i2400m_roq_log *log;
@@ -522,6 +521,7 @@ static
unsigned __i2400m_roq_nsn(struct i2400m_roq *roq, unsigned sn)
{
int r;
+
r = ((int) sn - (int) roq->ws) % 2048;
if (r < 0)
r += 2048;
@@ -556,7 +556,7 @@ void i2400m_roq_log_entry_print(struct i2400m *i2400m,
unsigned index,
{
struct device *dev = i2400m_dev(i2400m);
- switch(e->type) {
+ switch (e->type) {
case I2400M_RO_TYPE_RESET:
dev_err(dev, "q#%d reset ws %u cnt %u sn %u/%u"
" - new nws %u\n",
@@ -694,7 +694,8 @@ void __i2400m_roq_queue(struct i2400m *i2400m, struct
i2400m_roq *roq,
* not empty, so we are not the first ones; we also know we
* are not going to be the last ones. The list is sorted, so
* we have to insert before the the first guy with an nsn_itr
-* greater that our nsn. */
+* greater that our nsn.
+*/
skb_queue_walk(>queue, skb_itr) {
roq_data_itr = (struct i2400m_roq_data *) _itr->cb;
nsn_itr = __i2400m_roq_nsn(roq, roq_data_itr->sn);
@@ -1016,7 +1017,8 @@ void i2400m_rx_edata(struct i2400m *i2400m, struct
sk_buff *skb_rx,
/* now we have to pull and trim so that the skb points to the
* beginning of the IP packet; the netdev part will add the
* ethernet header as needed - we know there is enough space
-* because we checked in i2400m_rx_edata(). */
+* because we checked in i2400m_rx_edata().
+*/
skb_pull(skb, payload + sizeof(*hdr) - (void *) skb->data);
skb_trim(skb, (void *) skb_end_pointer(skb) - payload - sizeof(*hdr));
@@ -1046,7 +1048,7 @@ void i2400m_rx_edata(struct i2400m *i2400m, struct
sk_buff *skb_rx,
ro_type, ro_cin, roq->ws, ro_sn,
__i2400m_roq_nsn(roq, ro_sn), size);
d_dump(2, dev, payload, size);
- switch(ro_type) {
+ switch (ro_type) {
case I2400M_RO_TYPE_RESET:
i2400m_roq_reset(i2400m, roq);
kfree_skb(skb); /* no data here */
@@ -1146,6 +1148,7 @@ int i2400m_rx_msg_hdr_check(struct i2400m *i2400m,
{
int result = -EIO;
struct device *dev = i2400m_dev(i2400m);
+
if (buf_size < sizeof(*msg_hdr)) {
dev_err(dev, "RX: HW BUG? message with short header (%zu "
"vs %zu bytes expected)\n", buf_size, sizeof(*msg_hdr));
@@ -1313,6 +1316,7 @@ void i2400m_unknown_barker(struct i2400m *i2400m,
struct device *dev = i2400m_dev(i2400m);
char prefix[64];
const __le32 *barker = buf;
+
dev_err(dev, "RX: HW BUG? unknown barker %08x, "
"dropping %zu bytes\n", le32_to_cpu(*barker), size);
snprintf(prefix, sizeof(prefix), "%s %s: ",
@@ -1346,7 +1350,7 @@ int i2400m_rx_setup(struct
Re: [PATCH v1 0/9] x86/platform: Remove SFI framework and users
Hi, On 2/11/21 4:24 PM, Rafael J. Wysocki wrote: > On Thu, Feb 11, 2021 at 2:50 PM Andy Shevchenko > wrote: >> >> This is last part of Intel MID (SFI based) removal. We have no more users of >> it >> in the kernel and since SFI has been marked Obsolete for a few years already, >> Remove all the stuff altogether. >> >> Note, the more recent platforms (Intel Merrifield and Moorefield) still work >> as >> long as they provide correct ACPI tables. >> >> The series requires two prerequisite branches to be pulled first, i.e. >> - one form Rafael's PM tree (currently bleeding-edge) >> - one form TIP tree (x86/platform), actually only one patch is needed from it >> >> Due to above it's convenient to proceed all of these via Rafael's PM tree, >> >> Note, atomisp change is tagged by Sakari on behalf of media tree maintainers. >> >> Andy Shevchenko (9): >> media: atomisp: Remove unused header >> cpufreq: sfi-cpufreq: Remove driver for deprecated firmware >> sfi: Remove framework for deprecated firmware >> x86/PCI: Get rid of custom x86 model comparison >> x86/PCI: Describe @reg for type1_access_ok() >> x86/platform/intel-mid: Get rid of intel_scu_ipc_legacy.h >> x86/platform/intel-mid: Drop unused __intel_mid_cpu_chip and Co. >> x86/platform/intel-mid: Remove unused header inclusion in intel-mid.h >> x86/platform/intel-mid: Update Copyright year and drop file names >> >> Documentation/ABI/testing/sysfs-firmware-sfi | 15 - >> Documentation/ABI/testing/sysfs-platform-kim | 2 +- >> MAINTAINERS | 7 - >> arch/x86/Kconfig | 7 +- >> arch/x86/include/asm/intel-mid.h | 65 +-- >> arch/x86/include/asm/intel_scu_ipc.h | 2 - >> arch/x86/include/asm/intel_scu_ipc_legacy.h | 74 --- >> arch/x86/include/asm/platform_sst_audio.h | 2 - >> arch/x86/kernel/apic/io_apic.c| 4 +- >> arch/x86/kernel/setup.c | 2 - >> arch/x86/pci/intel_mid_pci.c | 18 +- >> arch/x86/pci/mmconfig-shared.c| 6 +- >> arch/x86/platform/Makefile| 1 - >> arch/x86/platform/intel-mid/Makefile | 5 - >> .../platform/intel-mid/device_libs/Makefile | 23 - >> .../intel-mid/device_libs/platform_bcm43xx.c | 101 >> .../intel-mid/device_libs/platform_bma023.c | 16 - >> .../intel-mid/device_libs/platform_bt.c | 101 >> .../intel-mid/device_libs/platform_emc1403.c | 39 -- >> .../device_libs/platform_gpio_keys.c | 81 --- >> .../intel-mid/device_libs/platform_lis331.c | 37 -- >> .../intel-mid/device_libs/platform_max7315.c | 77 --- >> .../intel-mid/device_libs/platform_mpu3050.c | 32 -- >> .../device_libs/platform_mrfld_pinctrl.c | 39 -- >> .../device_libs/platform_mrfld_rtc.c | 44 -- >> .../intel-mid/device_libs/platform_mrfld_sd.c | 43 -- >> .../device_libs/platform_mrfld_spidev.c | 50 -- >> .../device_libs/platform_pcal9555a.c | 95 >> .../intel-mid/device_libs/platform_tc35876x.c | 42 -- >> .../intel-mid/device_libs/platform_tca6416.c | 53 -- >> arch/x86/platform/intel-mid/intel-mid.c | 27 +- >> arch/x86/platform/intel-mid/sfi.c | 419 -- >> arch/x86/platform/sfi/Makefile| 2 - >> arch/x86/platform/sfi/sfi.c | 100 >> drivers/Makefile | 2 +- >> drivers/cpufreq/Kconfig.x86 | 10 - >> drivers/cpufreq/Makefile | 1 - >> drivers/cpufreq/sfi-cpufreq.c | 127 - >> drivers/platform/x86/intel_scu_pcidrv.c | 22 +- >> drivers/sfi/Kconfig | 18 - >> drivers/sfi/Makefile | 4 - >> drivers/sfi/sfi_acpi.c| 214 --- >> drivers/sfi/sfi_core.c| 522 -- >> drivers/sfi/sfi_core.h| 81 --- >> .../atomisp/include/linux/atomisp_platform.h | 1 - >> include/linux/sfi.h | 210 --- >> include/linux/sfi_acpi.h | 93 >> init/main.c | 2 - >> 48 files changed, 37 insertions(+), 2901 deletions(-) >> delete mode 100644 Documentation/ABI/testing/sysfs-firmware-sfi >> delete mode 100644 arch/x86/include/asm/intel_scu_ipc_legacy.h >> delete mode 100644 arch/x86/platform/intel-mid/device_libs/Makefile >> delete mode 100644 >> arch/x86/platform/intel-mid/device_libs/platform_bcm43xx.c >> delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_bma023.c >> delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_bt.c >> delete mode 100644 >> arch/x86/platform/intel-mid/device_libs/platform_emc1403.c >> delete mode 100644 >> arch/x86/platform/intel-mid/device_libs/platform_gpio_keys.c >> delete mode 100644
Re: [PATCH v1 0/9] x86/platform: Remove SFI framework and users
On Thu, Feb 11, 2021 at 2:50 PM Andy Shevchenko wrote: > > This is last part of Intel MID (SFI based) removal. We have no more users of > it > in the kernel and since SFI has been marked Obsolete for a few years already, > Remove all the stuff altogether. > > Note, the more recent platforms (Intel Merrifield and Moorefield) still work > as > long as they provide correct ACPI tables. > > The series requires two prerequisite branches to be pulled first, i.e. > - one form Rafael's PM tree (currently bleeding-edge) > - one form TIP tree (x86/platform), actually only one patch is needed from it > > Due to above it's convenient to proceed all of these via Rafael's PM tree, > > Note, atomisp change is tagged by Sakari on behalf of media tree maintainers. > > Andy Shevchenko (9): > media: atomisp: Remove unused header > cpufreq: sfi-cpufreq: Remove driver for deprecated firmware > sfi: Remove framework for deprecated firmware > x86/PCI: Get rid of custom x86 model comparison > x86/PCI: Describe @reg for type1_access_ok() > x86/platform/intel-mid: Get rid of intel_scu_ipc_legacy.h > x86/platform/intel-mid: Drop unused __intel_mid_cpu_chip and Co. > x86/platform/intel-mid: Remove unused header inclusion in intel-mid.h > x86/platform/intel-mid: Update Copyright year and drop file names > > Documentation/ABI/testing/sysfs-firmware-sfi | 15 - > Documentation/ABI/testing/sysfs-platform-kim | 2 +- > MAINTAINERS | 7 - > arch/x86/Kconfig | 7 +- > arch/x86/include/asm/intel-mid.h | 65 +-- > arch/x86/include/asm/intel_scu_ipc.h | 2 - > arch/x86/include/asm/intel_scu_ipc_legacy.h | 74 --- > arch/x86/include/asm/platform_sst_audio.h | 2 - > arch/x86/kernel/apic/io_apic.c| 4 +- > arch/x86/kernel/setup.c | 2 - > arch/x86/pci/intel_mid_pci.c | 18 +- > arch/x86/pci/mmconfig-shared.c| 6 +- > arch/x86/platform/Makefile| 1 - > arch/x86/platform/intel-mid/Makefile | 5 - > .../platform/intel-mid/device_libs/Makefile | 23 - > .../intel-mid/device_libs/platform_bcm43xx.c | 101 > .../intel-mid/device_libs/platform_bma023.c | 16 - > .../intel-mid/device_libs/platform_bt.c | 101 > .../intel-mid/device_libs/platform_emc1403.c | 39 -- > .../device_libs/platform_gpio_keys.c | 81 --- > .../intel-mid/device_libs/platform_lis331.c | 37 -- > .../intel-mid/device_libs/platform_max7315.c | 77 --- > .../intel-mid/device_libs/platform_mpu3050.c | 32 -- > .../device_libs/platform_mrfld_pinctrl.c | 39 -- > .../device_libs/platform_mrfld_rtc.c | 44 -- > .../intel-mid/device_libs/platform_mrfld_sd.c | 43 -- > .../device_libs/platform_mrfld_spidev.c | 50 -- > .../device_libs/platform_pcal9555a.c | 95 > .../intel-mid/device_libs/platform_tc35876x.c | 42 -- > .../intel-mid/device_libs/platform_tca6416.c | 53 -- > arch/x86/platform/intel-mid/intel-mid.c | 27 +- > arch/x86/platform/intel-mid/sfi.c | 419 -- > arch/x86/platform/sfi/Makefile| 2 - > arch/x86/platform/sfi/sfi.c | 100 > drivers/Makefile | 2 +- > drivers/cpufreq/Kconfig.x86 | 10 - > drivers/cpufreq/Makefile | 1 - > drivers/cpufreq/sfi-cpufreq.c | 127 - > drivers/platform/x86/intel_scu_pcidrv.c | 22 +- > drivers/sfi/Kconfig | 18 - > drivers/sfi/Makefile | 4 - > drivers/sfi/sfi_acpi.c| 214 --- > drivers/sfi/sfi_core.c| 522 -- > drivers/sfi/sfi_core.h| 81 --- > .../atomisp/include/linux/atomisp_platform.h | 1 - > include/linux/sfi.h | 210 --- > include/linux/sfi_acpi.h | 93 > init/main.c | 2 - > 48 files changed, 37 insertions(+), 2901 deletions(-) > delete mode 100644 Documentation/ABI/testing/sysfs-firmware-sfi > delete mode 100644 arch/x86/include/asm/intel_scu_ipc_legacy.h > delete mode 100644 arch/x86/platform/intel-mid/device_libs/Makefile > delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_bcm43xx.c > delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_bma023.c > delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_bt.c > delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_emc1403.c > delete mode 100644 > arch/x86/platform/intel-mid/device_libs/platform_gpio_keys.c > delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_lis331.c > delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_max7315.c > delete mode 100644
[PATCH] staging: ks7010: enclosed complex macro definitions with parentheses
kshostif.h
fixed ERROR: Macros with complex values should be enclosed in
paranthesis
Signed-off-by: Pritthijit Nath
---
drivers/staging/ks7010/ks_hostif.h | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/ks7010/ks_hostif.h
b/drivers/staging/ks7010/ks_hostif.h
index 39138191a556..c62a494ed6bb 100644
--- a/drivers/staging/ks7010/ks_hostif.h
+++ b/drivers/staging/ks7010/ks_hostif.h
@@ -498,20 +498,20 @@ struct hostif_mic_failure_request {
#define TX_RATE_FIXED 5
/* 11b rate */
-#define TX_RATE_1M (u8)(10 / 5)/* 11b 11g basic rate */
-#define TX_RATE_2M (u8)(20 / 5)/* 11b 11g basic rate */
-#define TX_RATE_5M (u8)(55 / 5)/* 11g basic rate */
-#define TX_RATE_11M(u8)(110 / 5) /* 11g basic rate */
+#define TX_RATE_1M ((u8)(10 / 5)) /* 11b 11g basic rate */
+#define TX_RATE_2M ((u8)(20 / 5)) /* 11b 11g basic rate */
+#define TX_RATE_5M ((u8)(55 / 5)) /* 11g basic rate */
+#define TX_RATE_11M((u8)(110 / 5)) /* 11g basic rate */
/* 11g rate */
-#define TX_RATE_6M (u8)(60 / 5)/* 11g basic rate */
-#define TX_RATE_12M(u8)(120 / 5) /* 11g basic rate */
-#define TX_RATE_24M(u8)(240 / 5) /* 11g basic rate */
-#define TX_RATE_9M (u8)(90 / 5)
-#define TX_RATE_18M(u8)(180 / 5)
-#define TX_RATE_36M(u8)(360 / 5)
-#define TX_RATE_48M(u8)(480 / 5)
-#define TX_RATE_54M(u8)(540 / 5)
+#define TX_RATE_6M ((u8)(60 / 5)) /* 11g basic rate */
+#define TX_RATE_12M((u8)(120 / 5)) /* 11g basic rate */
+#define TX_RATE_24M((u8)(240 / 5)) /* 11g basic rate */
+#define TX_RATE_9M ((u8)(90 / 5))
+#define TX_RATE_18M((u8)(180 / 5))
+#define TX_RATE_36M((u8)(360 / 5))
+#define TX_RATE_48M((u8)(480 / 5))
+#define TX_RATE_54M((u8)(540 / 5))
static inline bool is_11b_rate(u8 rate)
{
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: wfx: remove unused included header files
Many header files have been included, but never used. Those header
files have been removed.
Signed-off-by: Muhammad Usama Anjum
---
drivers/staging/wfx/bh.c | 1 -
drivers/staging/wfx/bh.h | 4
drivers/staging/wfx/bus.h | 3 ---
drivers/staging/wfx/bus_sdio.c| 6 --
drivers/staging/wfx/bus_spi.c | 7 ---
drivers/staging/wfx/data_rx.c | 5 -
drivers/staging/wfx/data_tx.c | 5 -
drivers/staging/wfx/data_tx.h | 3 ---
drivers/staging/wfx/debug.c | 6 --
drivers/staging/wfx/fwio.c| 2 --
drivers/staging/wfx/hif_api_cmd.h | 4
drivers/staging/wfx/hif_api_general.h | 9 -
drivers/staging/wfx/hif_tx.c | 4
drivers/staging/wfx/hif_tx_mib.c | 5 -
drivers/staging/wfx/hwio.c| 3 ---
drivers/staging/wfx/hwio.h| 2 --
drivers/staging/wfx/key.c | 2 --
drivers/staging/wfx/key.h | 2 --
drivers/staging/wfx/main.c| 7 ---
drivers/staging/wfx/main.h| 3 ---
drivers/staging/wfx/queue.c | 4
drivers/staging/wfx/queue.h | 3 ---
drivers/staging/wfx/scan.h| 2 --
drivers/staging/wfx/sta.c | 6 --
drivers/staging/wfx/sta.h | 2 --
drivers/staging/wfx/traces.h | 3 ---
drivers/staging/wfx/wfx.h | 3 ---
27 files changed, 106 deletions(-)
diff --git a/drivers/staging/wfx/bh.c b/drivers/staging/wfx/bh.c
index ed53d0b45592..cd6bcfdfbe9a 100644
--- a/drivers/staging/wfx/bh.c
+++ b/drivers/staging/wfx/bh.c
@@ -5,7 +5,6 @@
* Copyright (c) 2017-2020, Silicon Laboratories, Inc.
* Copyright (c) 2010, ST-Ericsson
*/
-#include
#include
#include "bh.h"
diff --git a/drivers/staging/wfx/bh.h b/drivers/staging/wfx/bh.h
index 78c49329e22a..92ef3298d4ac 100644
--- a/drivers/staging/wfx/bh.h
+++ b/drivers/staging/wfx/bh.h
@@ -8,10 +8,6 @@
#ifndef WFX_BH_H
#define WFX_BH_H
-#include
-#include
-#include
-
struct wfx_dev;
struct wfx_hif {
diff --git a/drivers/staging/wfx/bus.h b/drivers/staging/wfx/bus.h
index ca04b3da6204..ea3911485307 100644
--- a/drivers/staging/wfx/bus.h
+++ b/drivers/staging/wfx/bus.h
@@ -8,9 +8,6 @@
#ifndef WFX_BUS_H
#define WFX_BUS_H
-#include
-#include
-
#define WFX_REG_CONFIG0x0
#define WFX_REG_CONTROL 0x1
#define WFX_REG_IN_OUT_QUEUE 0x2
diff --git a/drivers/staging/wfx/bus_sdio.c b/drivers/staging/wfx/bus_sdio.c
index e06d7e1ebe9c..588edce44854 100644
--- a/drivers/staging/wfx/bus_sdio.c
+++ b/drivers/staging/wfx/bus_sdio.c
@@ -5,19 +5,13 @@
* Copyright (c) 2017-2020, Silicon Laboratories, Inc.
* Copyright (c) 2010, ST-Ericsson
*/
-#include
#include
#include
#include
-#include
#include
-#include
#include "bus.h"
#include "wfx.h"
-#include "hwio.h"
-#include "main.h"
-#include "bh.h"
static const struct wfx_platform_data wfx_sdio_pdata = {
.file_fw = "wfm_wf200",
diff --git a/drivers/staging/wfx/bus_spi.c b/drivers/staging/wfx/bus_spi.c
index a99125d1a30d..f89855abe9f8 100644
--- a/drivers/staging/wfx/bus_spi.c
+++ b/drivers/staging/wfx/bus_spi.c
@@ -6,19 +6,12 @@
* Copyright (c) 2011, Sagrad Inc.
* Copyright (c) 2010, ST-Ericsson
*/
-#include
-#include
-#include
#include
-#include
#include
#include
#include "bus.h"
#include "wfx.h"
-#include "hwio.h"
-#include "main.h"
-#include "bh.h"
#define SET_WRITE 0x7FFF/* usage: and operation */
#define SET_READ 0x8000 /* usage: or operation */
diff --git a/drivers/staging/wfx/data_rx.c b/drivers/staging/wfx/data_rx.c
index 385f2d42a0e2..2cfa16279220 100644
--- a/drivers/staging/wfx/data_rx.c
+++ b/drivers/staging/wfx/data_rx.c
@@ -5,13 +5,8 @@
* Copyright (c) 2017-2020, Silicon Laboratories, Inc.
* Copyright (c) 2010, ST-Ericsson
*/
-#include
-#include
-
#include "data_rx.h"
#include "wfx.h"
-#include "bh.h"
-#include "sta.h"
static void wfx_rx_handle_ba(struct wfx_vif *wvif, struct ieee80211_mgmt *mgmt)
{
diff --git a/drivers/staging/wfx/data_tx.c b/drivers/staging/wfx/data_tx.c
index 77fb104efdec..76f26e3c4381 100644
--- a/drivers/staging/wfx/data_tx.c
+++ b/drivers/staging/wfx/data_tx.c
@@ -6,14 +6,9 @@
* Copyright (c) 2010, ST-Ericsson
*/
#include
-#include
-#include "data_tx.h"
#include "wfx.h"
-#include "bh.h"
#include "sta.h"
-#include "queue.h"
-#include "debug.h"
#include "traces.h"
#include "hif_tx_mib.h"
diff --git a/drivers/staging/wfx/data_tx.h b/drivers/staging/wfx/data_tx.h
index 401363d6b563..6b3020097efa 100644
--- a/drivers/staging/wfx/data_tx.h
+++ b/drivers/staging/wfx/data_tx.h
@@ -8,9 +8,6 @@
#ifndef WFX_DATA_TX_H
#define WFX_DATA_TX_H
-#include
-#include
-
#include "hif_api_cmd.h"
#include "hif_api_mib.h"
diff --git a/drivers/staging/wfx/debug.c b/drivers/staging/wfx/debug.c
index eedada78c25f..3e87d13eb358 100644
--- a/drivers/staging/wfx/debug.c
+++
Re: [PATCH] staging: wfx: avoid defining array of flexible struct
> I think that "#include " is no more necessary. Good catch. I'll send another patch. Thanks, Usama ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] staging: gdm724x: Fix DMA from stack
On Thu, Feb 11, 2021 at 01:28:41PM +, David Laight wrote: > > Stack allocated buffers cannot be used for DMA > > on all architectures so allocate hci_packet buffer > > using kmalloc. > > I wonder if the usb stack ought/could support a short bounce > buffer within the memory is already has to allocate? No. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v1 3/9] sfi: Remove framework for deprecated firmware
SFI-based platforms are gone. So does this framework. This removes mention of SFI through the drivers and other code as well. Signed-off-by: Andy Shevchenko Reviewed-by: Hans de Goede Acked-by: Linus Walleij --- Documentation/ABI/testing/sysfs-firmware-sfi | 15 - Documentation/ABI/testing/sysfs-platform-kim | 2 +- MAINTAINERS | 7 - arch/x86/Kconfig | 7 +- arch/x86/include/asm/intel-mid.h | 37 -- arch/x86/include/asm/intel_scu_ipc_legacy.h | 58 +- arch/x86/include/asm/platform_sst_audio.h | 2 - arch/x86/kernel/apic/io_apic.c| 4 +- arch/x86/kernel/setup.c | 2 - arch/x86/pci/mmconfig-shared.c| 6 +- arch/x86/platform/Makefile| 1 - arch/x86/platform/intel-mid/Makefile | 5 - .../platform/intel-mid/device_libs/Makefile | 23 - .../intel-mid/device_libs/platform_bcm43xx.c | 101 .../intel-mid/device_libs/platform_bma023.c | 16 - .../intel-mid/device_libs/platform_bt.c | 101 .../intel-mid/device_libs/platform_emc1403.c | 39 -- .../device_libs/platform_gpio_keys.c | 81 --- .../intel-mid/device_libs/platform_lis331.c | 37 -- .../intel-mid/device_libs/platform_max7315.c | 77 --- .../intel-mid/device_libs/platform_mpu3050.c | 32 -- .../device_libs/platform_mrfld_pinctrl.c | 39 -- .../device_libs/platform_mrfld_rtc.c | 44 -- .../intel-mid/device_libs/platform_mrfld_sd.c | 43 -- .../device_libs/platform_mrfld_spidev.c | 50 -- .../device_libs/platform_pcal9555a.c | 95 .../intel-mid/device_libs/platform_tc35876x.c | 42 -- .../intel-mid/device_libs/platform_tca6416.c | 53 -- arch/x86/platform/intel-mid/intel-mid.c | 1 - arch/x86/platform/intel-mid/sfi.c | 419 -- arch/x86/platform/sfi/Makefile| 2 - arch/x86/platform/sfi/sfi.c | 100 drivers/Makefile | 2 +- drivers/platform/x86/intel_scu_pcidrv.c | 22 +- drivers/sfi/Kconfig | 18 - drivers/sfi/Makefile | 4 - drivers/sfi/sfi_acpi.c| 214 --- drivers/sfi/sfi_core.c| 522 -- drivers/sfi/sfi_core.h| 81 --- include/linux/sfi.h | 210 --- include/linux/sfi_acpi.h | 93 init/main.c | 2 - 42 files changed, 14 insertions(+), 2695 deletions(-) delete mode 100644 Documentation/ABI/testing/sysfs-firmware-sfi delete mode 100644 arch/x86/platform/intel-mid/device_libs/Makefile delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_bcm43xx.c delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_bma023.c delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_bt.c delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_emc1403.c delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_gpio_keys.c delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_lis331.c delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_max7315.c delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_mpu3050.c delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_mrfld_pinctrl.c delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_mrfld_rtc.c delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_mrfld_sd.c delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_mrfld_spidev.c delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_pcal9555a.c delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_tc35876x.c delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_tca6416.c delete mode 100644 arch/x86/platform/intel-mid/sfi.c delete mode 100644 arch/x86/platform/sfi/Makefile delete mode 100644 arch/x86/platform/sfi/sfi.c delete mode 100644 drivers/sfi/Kconfig delete mode 100644 drivers/sfi/Makefile delete mode 100644 drivers/sfi/sfi_acpi.c delete mode 100644 drivers/sfi/sfi_core.c delete mode 100644 drivers/sfi/sfi_core.h delete mode 100644 include/linux/sfi.h delete mode 100644 include/linux/sfi_acpi.h diff --git a/Documentation/ABI/testing/sysfs-firmware-sfi b/Documentation/ABI/testing/sysfs-firmware-sfi deleted file mode 100644 index 5210e0f06ddb.. --- a/Documentation/ABI/testing/sysfs-firmware-sfi +++ /dev/null @@ -1,15 +0,0 @@ -What: /sys/firmware/sfi/tables/ -Date: May 2010 -Contact: Len Brown -Description: - SFI defines a number of small static memory tables - so the kernel can get platform information from firmware. - - The tables are defined in the latest SFI
[PATCH v1 8/9] x86/platform/intel-mid: Remove unused header inclusion in intel-mid.h
After the commit f1be6cdaf57c ("x86/platform/intel-mid: Make
intel_scu_device_register() static") the platform_device.h is not being
used anymore by intel-mid.h. Remove it.
Signed-off-by: Andy Shevchenko
---
arch/x86/include/asm/intel-mid.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h
index c2c7da4c60cf..c043e91f45ad 100644
--- a/arch/x86/include/asm/intel-mid.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -8,7 +8,6 @@
#define _ASM_X86_INTEL_MID_H
#include
-#include
extern int intel_mid_pci_init(void);
extern int intel_mid_pci_set_power_state(struct pci_dev *pdev, pci_power_t
state);
--
2.30.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v1 6/9] x86/platform/intel-mid: Get rid of intel_scu_ipc_legacy.h
The header is used by a single user. Move header content to that user.
Signed-off-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
---
arch/x86/include/asm/intel_scu_ipc.h| 2 --
arch/x86/include/asm/intel_scu_ipc_legacy.h | 18 --
arch/x86/platform/intel-mid/intel-mid.c | 7 +--
3 files changed, 5 insertions(+), 22 deletions(-)
delete mode 100644 arch/x86/include/asm/intel_scu_ipc_legacy.h
diff --git a/arch/x86/include/asm/intel_scu_ipc.h
b/arch/x86/include/asm/intel_scu_ipc.h
index 11d457af68c5..8537f597d20a 100644
--- a/arch/x86/include/asm/intel_scu_ipc.h
+++ b/arch/x86/include/asm/intel_scu_ipc.h
@@ -65,6 +65,4 @@ static inline int intel_scu_ipc_dev_command(struct
intel_scu_ipc_dev *scu, int c
inlen, out, outlen);
}
-#include
-
#endif
diff --git a/arch/x86/include/asm/intel_scu_ipc_legacy.h
b/arch/x86/include/asm/intel_scu_ipc_legacy.h
deleted file mode 100644
index fa529e5ec142..
--- a/arch/x86/include/asm/intel_scu_ipc_legacy.h
+++ /dev/null
@@ -1,18 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef _ASM_X86_INTEL_SCU_IPC_LEGACY_H_
-#define _ASM_X86_INTEL_SCU_IPC_LEGACY_H_
-
-#include
-
-#define IPCMSG_COLD_OFF0x80/* Only for Tangier */
-#define IPCMSG_COLD_RESET 0xF1
-
-/* Don't call these in new code - they will be removed eventually */
-
-/* Issue commands to the SCU with or without data */
-static inline int intel_scu_ipc_simple_command(int cmd, int sub)
-{
- return intel_scu_ipc_dev_simple_command(NULL, cmd, sub);
-}
-
-#endif
diff --git a/arch/x86/platform/intel-mid/intel-mid.c
b/arch/x86/platform/intel-mid/intel-mid.c
index 2c044e260b4b..846b2ded39d9 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -29,6 +29,9 @@
#include
#include
+#define IPCMSG_COLD_OFF0x80/* Only for Tangier */
+#define IPCMSG_COLD_RESET 0xF1
+
enum intel_mid_cpu_type __intel_mid_cpu_chip;
EXPORT_SYMBOL_GPL(__intel_mid_cpu_chip);
@@ -38,12 +41,12 @@ static void intel_mid_power_off(void)
intel_mid_pwr_power_off();
/* Only for Tangier, the rest will ignore this command */
- intel_scu_ipc_simple_command(IPCMSG_COLD_OFF, 1);
+ intel_scu_ipc_dev_simple_command(NULL, IPCMSG_COLD_OFF, 1);
};
static void intel_mid_reboot(void)
{
- intel_scu_ipc_simple_command(IPCMSG_COLD_RESET, 0);
+ intel_scu_ipc_dev_simple_command(NULL, IPCMSG_COLD_RESET, 0);
}
static void __init intel_mid_time_init(void)
--
2.30.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v1 7/9] x86/platform/intel-mid: Drop unused __intel_mid_cpu_chip and Co.
Since there is no more user of this global variable and associated custom API,
we may safely drop this legacy reinvented a wheel from the kernel sources.
Signed-off-by: Andy Shevchenko
---
arch/x86/include/asm/intel-mid.h| 23 ---
arch/x86/platform/intel-mid/intel-mid.c | 17 -
2 files changed, 40 deletions(-)
diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h
index 6306fe3e5c4a..c2c7da4c60cf 100644
--- a/arch/x86/include/asm/intel-mid.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -21,36 +21,13 @@ extern void intel_mid_pwr_power_off(void);
extern int intel_mid_pwr_get_lss_id(struct pci_dev *pdev);
-/*
- * Medfield is the follow-up of Moorestown, it combines two chip solution into
- * one. Other than that it also added always-on and constant tsc and lapic
- * timers. Medfield is the platform name, and the chip name is called Penwell
- * we treat Medfield/Penwell as a variant of Moorestown. Penwell can be
- * identified via MSRs.
- */
-enum intel_mid_cpu_type {
- /* 1 was Moorestown */
- INTEL_MID_CPU_CHIP_PENWELL = 2,
- INTEL_MID_CPU_CHIP_CLOVERVIEW,
- INTEL_MID_CPU_CHIP_TANGIER,
-};
-
-extern enum intel_mid_cpu_type __intel_mid_cpu_chip;
-
#ifdef CONFIG_X86_INTEL_MID
-static inline enum intel_mid_cpu_type intel_mid_identify_cpu(void)
-{
- return __intel_mid_cpu_chip;
-}
-
extern void intel_scu_devices_create(void);
extern void intel_scu_devices_destroy(void);
#else /* !CONFIG_X86_INTEL_MID */
-#define intel_mid_identify_cpu() 0
-
static inline void intel_scu_devices_create(void) { }
static inline void intel_scu_devices_destroy(void) { }
diff --git a/arch/x86/platform/intel-mid/intel-mid.c
b/arch/x86/platform/intel-mid/intel-mid.c
index 846b2ded39d9..2802b5e4637b 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -32,9 +32,6 @@
#define IPCMSG_COLD_OFF0x80/* Only for Tangier */
#define IPCMSG_COLD_RESET 0xF1
-enum intel_mid_cpu_type __intel_mid_cpu_chip;
-EXPORT_SYMBOL_GPL(__intel_mid_cpu_chip);
-
static void intel_mid_power_off(void)
{
/* Shut down South Complex via PWRMU */
@@ -58,29 +55,15 @@ static void __init intel_mid_time_init(void)
static void intel_mid_arch_setup(void)
{
- if (boot_cpu_data.x86 != 6) {
- pr_err("Unknown Intel MID CPU (%d:%d), default to Penwell\n",
- boot_cpu_data.x86, boot_cpu_data.x86_model);
- __intel_mid_cpu_chip = INTEL_MID_CPU_CHIP_PENWELL;
- goto out;
- }
-
switch (boot_cpu_data.x86_model) {
- case 0x35:
- __intel_mid_cpu_chip = INTEL_MID_CPU_CHIP_CLOVERVIEW;
- break;
case 0x3C:
case 0x4A:
- __intel_mid_cpu_chip = INTEL_MID_CPU_CHIP_TANGIER;
x86_platform.legacy.rtc = 1;
break;
- case 0x27:
default:
- __intel_mid_cpu_chip = INTEL_MID_CPU_CHIP_PENWELL;
break;
}
-out:
/*
* Intel MID platforms are using explicitly defined regulators.
*
--
2.30.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v1 5/9] x86/PCI: Describe @reg for type1_access_ok()
Describe missed parameter in documentation of type1_access_ok(). Otherwise "make W=1 arch/x86/pci/" produces the following warning: CHECK arch/x86/pci/intel_mid_pci.c CC arch/x86/pci/intel_mid_pci.o arch/x86/pci/intel_mid_pci.c:152: warning: Function parameter or member 'reg' not described in 'type1_access_ok' Signed-off-by: Andy Shevchenko --- arch/x86/pci/intel_mid_pci.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/pci/intel_mid_pci.c b/arch/x86/pci/intel_mid_pci.c index 938a8b7bfe7f..8edd62206604 100644 --- a/arch/x86/pci/intel_mid_pci.c +++ b/arch/x86/pci/intel_mid_pci.c @@ -142,6 +142,7 @@ static int pci_device_update_fixed(struct pci_bus *bus, unsigned int devfn, * type1_access_ok - check whether to use type 1 * @bus: bus number * @devfn: device & function in question + * @reg: configuration register offset * * If the bus is on a Lincroft chip and it exists, or is not on a Lincroft at * all, the we can go ahead with any reads & writes. If it's on a Lincroft, -- 2.30.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v1 9/9] x86/platform/intel-mid: Update Copyright year and drop file names
Update Copyright year and drop file names from files themselves. Signed-off-by: Andy Shevchenko --- arch/x86/include/asm/intel-mid.h| 4 ++-- arch/x86/platform/intel-mid/intel-mid.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h index c043e91f45ad..c201083b34f6 100644 --- a/arch/x86/include/asm/intel-mid.h +++ b/arch/x86/include/asm/intel-mid.h @@ -1,8 +1,8 @@ /* SPDX-License-Identifier: GPL-2.0-only */ /* - * intel-mid.h: Intel MID specific setup code + * Intel MID specific setup code * - * (C) Copyright 2009 Intel Corporation + * (C) Copyright 2009, 2021 Intel Corporation */ #ifndef _ASM_X86_INTEL_MID_H #define _ASM_X86_INTEL_MID_H diff --git a/arch/x86/platform/intel-mid/intel-mid.c b/arch/x86/platform/intel-mid/intel-mid.c index 2802b5e4637b..f4592dc7a1c1 100644 --- a/arch/x86/platform/intel-mid/intel-mid.c +++ b/arch/x86/platform/intel-mid/intel-mid.c @@ -1,8 +1,8 @@ // SPDX-License-Identifier: GPL-2.0-only /* - * intel-mid.c: Intel MID platform setup code + * Intel MID platform setup code * - * (C) Copyright 2008, 2012 Intel Corporation + * (C) Copyright 2008, 2012, 2021 Intel Corporation * Author: Jacob Pan (jacob.jun@intel.com) * Author: Sathyanarayanan Kuppuswamy */ -- 2.30.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v1 1/9] media: atomisp: Remove unused header
sfi.h is not anyhow used by the driver. Remove it. Signed-off-by: Andy Shevchenko Acked-by: Sakari Ailus Acked-by: Linus Walleij --- drivers/staging/media/atomisp/include/linux/atomisp_platform.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/media/atomisp/include/linux/atomisp_platform.h b/drivers/staging/media/atomisp/include/linux/atomisp_platform.h index 5a5121d958ed..8c65733e0255 100644 --- a/drivers/staging/media/atomisp/include/linux/atomisp_platform.h +++ b/drivers/staging/media/atomisp/include/linux/atomisp_platform.h @@ -22,7 +22,6 @@ #include #include -#include #include #include "atomisp.h" -- 2.30.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v1 2/9] cpufreq: sfi-cpufreq: Remove driver for deprecated firmware
SFI-based platforms are gone. So does this driver.
Signed-off-by: Andy Shevchenko
Acked-by: Linus Walleij
---
drivers/cpufreq/Kconfig.x86 | 10 ---
drivers/cpufreq/Makefile | 1 -
drivers/cpufreq/sfi-cpufreq.c | 127 --
3 files changed, 138 deletions(-)
delete mode 100644 drivers/cpufreq/sfi-cpufreq.c
diff --git a/drivers/cpufreq/Kconfig.x86 b/drivers/cpufreq/Kconfig.x86
index 399526289320..92701a18bdd9 100644
--- a/drivers/cpufreq/Kconfig.x86
+++ b/drivers/cpufreq/Kconfig.x86
@@ -62,16 +62,6 @@ config X86_ACPI_CPUFREQ_CPB
By enabling this option the acpi_cpufreq driver provides the old
entry in addition to the new boost ones, for compatibility reasons.
-config X86_SFI_CPUFREQ
- tristate "SFI Performance-States driver"
- depends on X86_INTEL_MID && SFI
- help
- This adds a CPUFreq driver for some Silvermont based Intel Atom
- architectures like Z34xx and Z35xx which enumerate processor
- performance states through SFI.
-
- If in doubt, say N.
-
config ELAN_CPUFREQ
tristate "AMD Elan SC400 and SC410"
depends on MELAN
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index f1b7e3dd6e5d..18c9b0eafd09 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -43,7 +43,6 @@ obj-$(CONFIG_X86_P4_CLOCKMOD) += p4-clockmod.o
obj-$(CONFIG_X86_CPUFREQ_NFORCE2) += cpufreq-nforce2.o
obj-$(CONFIG_X86_INTEL_PSTATE) += intel_pstate.o
obj-$(CONFIG_X86_AMD_FREQ_SENSITIVITY) += amd_freq_sensitivity.o
-obj-$(CONFIG_X86_SFI_CPUFREQ) += sfi-cpufreq.o
##
# ARM SoC drivers
diff --git a/drivers/cpufreq/sfi-cpufreq.c b/drivers/cpufreq/sfi-cpufreq.c
deleted file mode 100644
index 45cfdf67cf03..
--- a/drivers/cpufreq/sfi-cpufreq.c
+++ /dev/null
@@ -1,127 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * SFI Performance States Driver
- *
- * Author: Vishwesh M Rudramuni
- * Author: Srinidhi Kasagar
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-
-static struct cpufreq_frequency_table *freq_table;
-static struct sfi_freq_table_entry *sfi_cpufreq_array;
-static int num_freq_table_entries;
-
-static int sfi_parse_freq(struct sfi_table_header *table)
-{
- struct sfi_table_simple *sb;
- struct sfi_freq_table_entry *pentry;
- int totallen;
-
- sb = (struct sfi_table_simple *)table;
- num_freq_table_entries = SFI_GET_NUM_ENTRIES(sb,
- struct sfi_freq_table_entry);
- if (num_freq_table_entries <= 1) {
- pr_err("No p-states discovered\n");
- return -ENODEV;
- }
-
- pentry = (struct sfi_freq_table_entry *)sb->pentry;
- totallen = num_freq_table_entries * sizeof(*pentry);
-
- sfi_cpufreq_array = kmemdup(pentry, totallen, GFP_KERNEL);
- if (!sfi_cpufreq_array)
- return -ENOMEM;
-
- return 0;
-}
-
-static int sfi_cpufreq_target(struct cpufreq_policy *policy, unsigned int
index)
-{
- unsigned int next_perf_state = 0; /* Index into perf table */
- u32 lo, hi;
-
- next_perf_state = policy->freq_table[index].driver_data;
-
- rdmsr_on_cpu(policy->cpu, MSR_IA32_PERF_CTL, , );
- lo = (lo & ~INTEL_PERF_CTL_MASK) |
- ((u32) sfi_cpufreq_array[next_perf_state].ctrl_val &
- INTEL_PERF_CTL_MASK);
- wrmsr_on_cpu(policy->cpu, MSR_IA32_PERF_CTL, lo, hi);
-
- return 0;
-}
-
-static int sfi_cpufreq_cpu_init(struct cpufreq_policy *policy)
-{
- policy->shared_type = CPUFREQ_SHARED_TYPE_HW;
- policy->cpuinfo.transition_latency = 10;/* 100us */
- policy->freq_table = freq_table;
-
- return 0;
-}
-
-static struct cpufreq_driver sfi_cpufreq_driver = {
- .flags = CPUFREQ_CONST_LOOPS,
- .verify = cpufreq_generic_frequency_table_verify,
- .target_index = sfi_cpufreq_target,
- .init = sfi_cpufreq_cpu_init,
- .name = "sfi-cpufreq",
- .attr = cpufreq_generic_attr,
-};
-
-static int __init sfi_cpufreq_init(void)
-{
- int ret, i;
-
- /* parse the freq table from SFI */
- ret = sfi_table_parse(SFI_SIG_FREQ, NULL, NULL, sfi_parse_freq);
- if (ret)
- return ret;
-
- freq_table = kcalloc(num_freq_table_entries + 1, sizeof(*freq_table),
-GFP_KERNEL);
- if (!freq_table) {
- ret = -ENOMEM;
- goto err_free_array;
- }
-
- for (i = 0; i < num_freq_table_entries; i++) {
- freq_table[i].driver_data = i;
- freq_table[i].frequency = sfi_cpufreq_array[i].freq_mhz * 1000;
- }
- freq_table[i].frequency = CPUFREQ_TABLE_END;
-
- ret =
[PATCH v1 4/9] x86/PCI: Get rid of custom x86 model comparison
Switch the platform code to use x86_id_table and accompanying API
instead of custom comparison against x86 CPU model.
This is one of the last users of custom API for that and following
changes will remove it for the good.
Signed-off-by: Andy Shevchenko
---
arch/x86/pci/intel_mid_pci.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/x86/pci/intel_mid_pci.c b/arch/x86/pci/intel_mid_pci.c
index 95e2e6bd8d8c..938a8b7bfe7f 100644
--- a/arch/x86/pci/intel_mid_pci.c
+++ b/arch/x86/pci/intel_mid_pci.c
@@ -28,10 +28,12 @@
#include
#include
+#include
#include
#include
#include
#include
+#include
#include
#include
@@ -212,10 +214,17 @@ static int pci_write(struct pci_bus *bus, unsigned int
devfn, int where,
where, size, value);
}
+static const struct x86_cpu_id intel_mid_cpu_ids[] = {
+ X86_MATCH_INTEL_FAM6_MODEL(ATOM_SILVERMONT_MID, NULL),
+ {}
+};
+
static int intel_mid_pci_irq_enable(struct pci_dev *dev)
{
+ const struct x86_cpu_id *id;
struct irq_alloc_info info;
bool polarity_low;
+ u16 model = 0;
int ret;
u8 gsi;
@@ -228,8 +237,12 @@ static int intel_mid_pci_irq_enable(struct pci_dev *dev)
return ret;
}
- switch (intel_mid_identify_cpu()) {
- case INTEL_MID_CPU_CHIP_TANGIER:
+ id = x86_match_cpu(intel_mid_cpu_ids);
+ if (id)
+ model = id->model;
+
+ switch (model) {
+ case INTEL_FAM6_ATOM_SILVERMONT_MID:
polarity_low = false;
/* Special treatment for IRQ0 */
--
2.30.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v1 0/9] x86/platform: Remove SFI framework and users
This is last part of Intel MID (SFI based) removal. We have no more users of it in the kernel and since SFI has been marked Obsolete for a few years already, Remove all the stuff altogether. Note, the more recent platforms (Intel Merrifield and Moorefield) still work as long as they provide correct ACPI tables. The series requires two prerequisite branches to be pulled first, i.e. - one form Rafael's PM tree (currently bleeding-edge) - one form TIP tree (x86/platform), actually only one patch is needed from it Due to above it's convenient to proceed all of these via Rafael's PM tree, Note, atomisp change is tagged by Sakari on behalf of media tree maintainers. Andy Shevchenko (9): media: atomisp: Remove unused header cpufreq: sfi-cpufreq: Remove driver for deprecated firmware sfi: Remove framework for deprecated firmware x86/PCI: Get rid of custom x86 model comparison x86/PCI: Describe @reg for type1_access_ok() x86/platform/intel-mid: Get rid of intel_scu_ipc_legacy.h x86/platform/intel-mid: Drop unused __intel_mid_cpu_chip and Co. x86/platform/intel-mid: Remove unused header inclusion in intel-mid.h x86/platform/intel-mid: Update Copyright year and drop file names Documentation/ABI/testing/sysfs-firmware-sfi | 15 - Documentation/ABI/testing/sysfs-platform-kim | 2 +- MAINTAINERS | 7 - arch/x86/Kconfig | 7 +- arch/x86/include/asm/intel-mid.h | 65 +-- arch/x86/include/asm/intel_scu_ipc.h | 2 - arch/x86/include/asm/intel_scu_ipc_legacy.h | 74 --- arch/x86/include/asm/platform_sst_audio.h | 2 - arch/x86/kernel/apic/io_apic.c| 4 +- arch/x86/kernel/setup.c | 2 - arch/x86/pci/intel_mid_pci.c | 18 +- arch/x86/pci/mmconfig-shared.c| 6 +- arch/x86/platform/Makefile| 1 - arch/x86/platform/intel-mid/Makefile | 5 - .../platform/intel-mid/device_libs/Makefile | 23 - .../intel-mid/device_libs/platform_bcm43xx.c | 101 .../intel-mid/device_libs/platform_bma023.c | 16 - .../intel-mid/device_libs/platform_bt.c | 101 .../intel-mid/device_libs/platform_emc1403.c | 39 -- .../device_libs/platform_gpio_keys.c | 81 --- .../intel-mid/device_libs/platform_lis331.c | 37 -- .../intel-mid/device_libs/platform_max7315.c | 77 --- .../intel-mid/device_libs/platform_mpu3050.c | 32 -- .../device_libs/platform_mrfld_pinctrl.c | 39 -- .../device_libs/platform_mrfld_rtc.c | 44 -- .../intel-mid/device_libs/platform_mrfld_sd.c | 43 -- .../device_libs/platform_mrfld_spidev.c | 50 -- .../device_libs/platform_pcal9555a.c | 95 .../intel-mid/device_libs/platform_tc35876x.c | 42 -- .../intel-mid/device_libs/platform_tca6416.c | 53 -- arch/x86/platform/intel-mid/intel-mid.c | 27 +- arch/x86/platform/intel-mid/sfi.c | 419 -- arch/x86/platform/sfi/Makefile| 2 - arch/x86/platform/sfi/sfi.c | 100 drivers/Makefile | 2 +- drivers/cpufreq/Kconfig.x86 | 10 - drivers/cpufreq/Makefile | 1 - drivers/cpufreq/sfi-cpufreq.c | 127 - drivers/platform/x86/intel_scu_pcidrv.c | 22 +- drivers/sfi/Kconfig | 18 - drivers/sfi/Makefile | 4 - drivers/sfi/sfi_acpi.c| 214 --- drivers/sfi/sfi_core.c| 522 -- drivers/sfi/sfi_core.h| 81 --- .../atomisp/include/linux/atomisp_platform.h | 1 - include/linux/sfi.h | 210 --- include/linux/sfi_acpi.h | 93 init/main.c | 2 - 48 files changed, 37 insertions(+), 2901 deletions(-) delete mode 100644 Documentation/ABI/testing/sysfs-firmware-sfi delete mode 100644 arch/x86/include/asm/intel_scu_ipc_legacy.h delete mode 100644 arch/x86/platform/intel-mid/device_libs/Makefile delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_bcm43xx.c delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_bma023.c delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_bt.c delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_emc1403.c delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_gpio_keys.c delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_lis331.c delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_max7315.c delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_mpu3050.c delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_mrfld_pinctrl.c delete mode 100644 arch/x86/platform/intel-mid/device_libs/platform_mrfld_rtc.c delete mode
Re: [PATCH -next] staging: ks7010: Macros with complex values
Ok, thanks!
On Thu, Feb 11, 2021 at 3:52 PM Greg KH wrote:
>
> On Thu, Feb 11, 2021 at 03:23:24PM +0300, Fatih Yildirim wrote:
> > On Thu, Feb 11, 2021 at 12:10:44PM +0100, Greg KH wrote:
> > > On Thu, Feb 11, 2021 at 01:57:04PM +0300, Fatih YILDIRIM wrote:
> > > > On Thu, Feb 11, 2021 at 11:02:51AM +0100, Greg KH wrote:
> > > > > On Thu, Feb 11, 2021 at 12:22:39PM +0300, Fatih Yildirim wrote:
> > > > > > Fix for checkpatch.pl warning:
> > > > > > Macros with complex values should be enclosed in parentheses.
> > > > > >
> > > > > > Signed-off-by: Fatih Yildirim
> > > > > > ---
> > > > > > drivers/staging/ks7010/ks_hostif.h | 24
> > > > > > 1 file changed, 12 insertions(+), 12 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/staging/ks7010/ks_hostif.h
> > > > > > b/drivers/staging/ks7010/ks_hostif.h
> > > > > > index 39138191a556..c62a494ed6bb 100644
> > > > > > --- a/drivers/staging/ks7010/ks_hostif.h
> > > > > > +++ b/drivers/staging/ks7010/ks_hostif.h
> > > > > > @@ -498,20 +498,20 @@ struct hostif_mic_failure_request {
> > > > > > #define TX_RATE_FIXED5
> > > > > >
> > > > > > /* 11b rate */
> > > > > > -#define TX_RATE_1M (u8)(10 / 5)/* 11b 11g basic rate */
> > > > > > -#define TX_RATE_2M (u8)(20 / 5)/* 11b 11g basic rate */
> > > > > > -#define TX_RATE_5M (u8)(55 / 5)/* 11g basic rate */
> > > > > > -#define TX_RATE_11M (u8)(110 / 5) /* 11g basic rate */
> > > > > > +#define TX_RATE_1M ((u8)(10 / 5)) /* 11b 11g basic rate */
> > > > > > +#define TX_RATE_2M ((u8)(20 / 5)) /* 11b 11g basic rate */
> > > > > > +#define TX_RATE_5M ((u8)(55 / 5)) /* 11g basic rate */
> > > > > > +#define TX_RATE_11M ((u8)(110 / 5)) /* 11g basic rate */
> > > > >
> > > > > But these are not "complex macros" that need an extra () added to
> > > > > them,
> > > > > right?
> > > > >
> > > > > Checkpatch is a hint, it's not a code parser and can not always know
> > > > > what is happening. With your knowledge of C, does this look like
> > > > > something that needs to be "fixed"?
> > > > >
> > > > > thanks,
> > > > >
> > > > > greg k-h
> > > >
> > > > Hi Greg,
> > > >
> > > > Thanks for your reply.
> > > > Actually, I'm following the Eudyptula Challenge and I'm at task 10.
> > >
> > > First rule of that challenge is that you are not allowed to talk about
> > > it in public :)
> > >
> > > That being said, you didn't answer any of my questions above :(
> > >
> > > greg k-h
> >
> > Ohh no, missed the rule. Sorry for that, I feel rookie :)
> > You are right, they are not complex macros.
> > Besides that, type cast operator doesn't have the highest precedence.
> > So, I think we can use enclosing paranthesis.
>
> I don't think they are needed, see how these are used please.
>
> thanks,
>
> greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH v4] staging: gdm724x: Fix DMA from stack
> Stack allocated buffers cannot be used for DMA > on all architectures so allocate hci_packet buffer > using kmalloc. I wonder if the usb stack ought/could support a short bounce buffer within the memory is already has to allocate? For hci and lengths less than 8 the immediate data can be placed directly in the ring structure replacing the data pointer itself. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging: greybus: Added do - while in multi statement macro
Hi Hemansh,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on staging/staging-testing]
url:
https://github.com/0day-ci/linux/commits/Hemansh-Agnihotri/staging-greybus-Added-do-while-in-multi-statement-macro/20210211-175717
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
6953026f21092199a59f2c641a880b1c4025f932
config: m68k-randconfig-r003-20210211 (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/e0f87bc4986d8e909dfda91664ce1700b01acb85
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Hemansh-Agnihotri/staging-greybus-Added-do-while-in-multi-statement-macro/20210211-175717
git checkout e0f87bc4986d8e909dfda91664ce1700b01acb85
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=m68k
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/staging/greybus/loopback.c:165:40: error: expected identifier or '('
>> before 'do'
165 | #define gb_loopback_stats_attrs(field) do { \
|^~
drivers/staging/greybus/loopback.c:272:1: note: in expansion of macro
'gb_loopback_stats_attrs'
272 | gb_loopback_stats_attrs(latency);
| ^~~
>> drivers/staging/greybus/loopback.c:169:4: error: expected identifier or '('
>> before 'while'
169 | } while (0)
|^
drivers/staging/greybus/loopback.c:272:1: note: in expansion of macro
'gb_loopback_stats_attrs'
272 | gb_loopback_stats_attrs(latency);
| ^~~
>> drivers/staging/greybus/loopback.c:165:40: error: expected identifier or '('
>> before 'do'
165 | #define gb_loopback_stats_attrs(field) do { \
|^~
drivers/staging/greybus/loopback.c:274:1: note: in expansion of macro
'gb_loopback_stats_attrs'
274 | gb_loopback_stats_attrs(requests_per_second);
| ^~~
>> drivers/staging/greybus/loopback.c:169:4: error: expected identifier or '('
>> before 'while'
169 | } while (0)
|^
drivers/staging/greybus/loopback.c:274:1: note: in expansion of macro
'gb_loopback_stats_attrs'
274 | gb_loopback_stats_attrs(requests_per_second);
| ^~~
>> drivers/staging/greybus/loopback.c:165:40: error: expected identifier or '('
>> before 'do'
165 | #define gb_loopback_stats_attrs(field) do { \
|^~
drivers/staging/greybus/loopback.c:276:1: note: in expansion of macro
'gb_loopback_stats_attrs'
276 | gb_loopback_stats_attrs(throughput);
| ^~~
>> drivers/staging/greybus/loopback.c:169:4: error: expected identifier or '('
>> before 'while'
169 | } while (0)
|^
drivers/staging/greybus/loopback.c:276:1: note: in expansion of macro
'gb_loopback_stats_attrs'
276 | gb_loopback_stats_attrs(throughput);
| ^~~
>> drivers/staging/greybus/loopback.c:165:40: error: expected identifier or '('
>> before 'do'
165 | #define gb_loopback_stats_attrs(field) do { \
|^~
drivers/staging/greybus/loopback.c:278:1: note: in expansion of macro
'gb_loopback_stats_attrs'
278 | gb_loopback_stats_attrs(apbridge_unipro_latency);
| ^~~
>> drivers/staging/greybus/loopback.c:169:4: error: expected identifier or '('
>> before 'while'
169 | } while (0)
|^
drivers/staging/greybus/loopback.c:278:1: note: in expansion of macro
'gb_loopback_stats_attrs'
278 | gb_loopback_stats_attrs(apbridge_unipro_latency);
| ^~~
>> drivers/staging/greybus/loopback.c:165:40: error: expected identifier or '('
>> before 'do'
165 | #define gb_loopback_stats_attrs(field) do { \
|^~
drivers/staging/greybus/loopback.c:280:1: note: in expansion of macro
'gb_loopback_stats_attrs'
280 | gb_loopback_stats_attrs(gbphy_firmware_latency);
| ^~~
>> drivers/staging/greybus/loopback.c:169:4: error: expected identifier or '('
>> before 'while'
169 | } while (0)
|^
drivers/staging/greybus/loopback.c:280:1: note: in expansion of macro
'gb_loopback_stats_attrs'
280 | gb_loopback_stats_attrs(gbphy_firmware_latency)
[PATCH v4 2/2] staging: rtl8723bs: remove obsolete commented out code
There is a bunch of messy, commented out code. Just delete it.
Suggested-by: Dan Carpenter
Signed-off-by: karthik alapati
---
.../staging/rtl8723bs/hal/rtl8723b_phycfg.c | 40 +--
1 file changed, 2 insertions(+), 38 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
b/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
index 77132e4ee..22365926a 100644
--- a/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
+++ b/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
@@ -57,8 +57,6 @@ u32 PHY_QueryBBReg_8723B(struct adapter *Adapter, u32
RegAddr, u32 BitMask)
return 0;
#endif
- /* RT_TRACE(COMP_RF, DBG_TRACE, ("--->PHY_QueryBBReg(): RegAddr(%#lx),
BitMask(%#lx)\n", RegAddr, BitMask)); */
-
OriginalValue = rtw_read32(Adapter, RegAddr);
BitShift = phy_CalculateBitShift(BitMask);
@@ -94,8 +92,6 @@ void PHY_SetBBReg_8723B(
return;
#endif
- /* RT_TRACE(COMP_RF, DBG_TRACE, ("--->PHY_SetBBReg(): RegAddr(%#lx),
BitMask(%#lx), Data(%#lx)\n", RegAddr, BitMask, Data)); */
-
if (BitMask != bMaskDWord) { /* if not "double word" write */
OriginalValue = rtw_read32(Adapter, RegAddr);
BitShift = phy_CalculateBitShift(BitMask);
@@ -159,13 +155,9 @@ static u32 phy_RFSerialRead_8723B(
if (RfPiEnable) {
/* Read from BBreg8b8, 12 bits for 8190, 20bits for T65 RF */
retValue = PHY_QueryBBReg(Adapter,
pPhyReg->rfLSSIReadBackPi|MaskforPhySet, bLSSIReadBackData);
-
- /* RT_DISP(FINIT, INIT_RF, ("Readback from RF-PI : 0x%x\n",
retValue)); */
} else {
/* Read from BBreg8a0, 12 bits for 8190, 20 bits for T65 RF */
retValue = PHY_QueryBBReg(Adapter,
pPhyReg->rfLSSIReadBack|MaskforPhySet, bLSSIReadBackData);
-
- /* RT_DISP(FINIT, INIT_RF, ("Readback from RF-SI : 0x%x\n",
retValue)); */
}
return retValue;
@@ -230,15 +222,11 @@ static void phy_RFSerialWrite_8723B(
/* */
/* Put write addr in [5:0] and write data in [31:16] */
/* */
- /* DataAndAddr = (Data<<16) | (NewOffset&0x3f); */
DataAndAddr = ((NewOffset<<20) | (Data&0x000f)) & 0x0fff;
/* T65 RF */
-
/* */
/* Write Operation */
/* */
PHY_SetBBReg(Adapter, pPhyReg->rf3wireOffset, bMaskDWord, DataAndAddr);
- /* RTPRINT(FPHY, PHY_RFW, ("RFW-%d Addr[0x%lx]= 0x%lx\n", eRFPath,
pPhyReg->rf3wireOffset, DataAndAddr)); */
-
}
@@ -473,7 +461,6 @@ int PHY_RFConfig8723B(struct adapter *Adapter)
rtStatus = PHY_RF6052_Config8723B(Adapter);
phy_LCK_8723B(Adapter);
- /* PHY_BB8723B_Config_1T(Adapter); */
return rtStatus;
}
@@ -580,8 +567,6 @@ u8 PHY_GetTxPowerIndex(
s8 txPower = 0, powerDiffByRate = 0, limit = 0;
bool bIn24G = false;
- /* DBG_871X("===>%s\n", __func__); */
-
txPower = (s8) PHY_GetTxPowerIndexBase(padapter, RFPath, Rate,
BandWidth, Channel, );
powerDiffByRate = PHY_GetTxPowerByRate(padapter, BAND_ON_2_4G,
ODM_RF_PATH_A, RF_1TX, Rate);
@@ -603,7 +588,6 @@ u8 PHY_GetTxPowerIndex(
if (txPower > MAX_POWER_INDEX)
txPower = MAX_POWER_INDEX;
- /* DBG_871X("Final Tx Power(RF-%c, Channel: %d) = %d(0x%X)\n", ((RFPath
== 0)?'A':'B'), Channel, txPower, txPower)); */
return (u8) txPower;
}
@@ -750,8 +734,6 @@ static void phy_PostSetBwMode8723B(struct adapter *Adapter)
PHY_SetBBReg(Adapter, rFPGA1_RFMOD, bRFMOD, 0x0);
-/* PHY_SetBBReg(Adapter, rFPGA0_AnalogParameter2, BIT10,
1); */
-
PHY_SetBBReg(Adapter, rOFDM0_TxPseudoNoiseWgt, (BIT31|BIT30),
0x0);
break;
@@ -766,15 +748,9 @@ static void phy_PostSetBwMode8723B(struct adapter *Adapter)
PHY_SetBBReg(Adapter, rOFDM1_LSTF, 0xC00,
pHalData->nCur40MhzPrimeSC);
-/* PHY_SetBBReg(Adapter, rFPGA0_AnalogParameter2, BIT10, 0); */
-
PHY_SetBBReg(Adapter, 0x818, (BIT26|BIT27),
(pHalData->nCur40MhzPrimeSC == HAL_PRIME_CHNL_OFFSET_LOWER) ? 2 : 1);
-
break;
-
default:
- /*RT_TRACE(COMP_DBG, DBG_LOUD, ("phy_SetBWMode8723B(): unknown
Bandwidth: %#X\n"\
- , pHalData->CurrentChannelBW));*/
break;
}
@@ -787,10 +763,8 @@ static void phy_SwChnl8723B(struct adapter *padapter)
struct hal_com_data *pHalData = GET_HAL_DATA(padapter);
u8 channelToSW = pHalData->CurrentChannel;
- if (pHalData->rf_chip == RF_PSEUDO_11N) {
- /* RT_TRACE(COMP_MLME, DBG_LOUD, ("phy_SwChnl8723B: return for
PSEUDO\n")); */
+ if (pHalData->rf_chip == RF_PSEUDO_11N)
return;
- }
pHalData->RfRegChnlVal[0] = ((pHalData->RfRegChnlVal[0] & 0xf00) |
channelToSW);
PHY_SetRFReg(padapter, ODM_RF_PATH_A, RF_CHNLBW, 0x3FF,
[PATCH v4 1/2] staging: rtl8723bs: fix function comments to follow kernel-doc
there are some good function comments not following
kernel-doc. Make them follow kernel-doc style
Signed-off-by: karthik alapati
---
.../staging/rtl8723bs/hal/rtl8723b_phycfg.c | 185 +++---
1 file changed, 73 insertions(+), 112 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
b/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
index cf23414d7..77132e4ee 100644
--- a/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
+++ b/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
@@ -20,16 +20,11 @@
#define MAX_DOZE_WAITING_TIMES_9x 64
/**
-* Function:phy_CalculateBitShift
-*
-* OverView:Get shifted position of the BitMask
-*
-* Input:
-* u32 BitMask,
-*
-* Output: none
-* Return: u32 Return the shift bit bit position of the mask
-*/
+ * phy_CalculateBitShift - Get shifted position of the BitMask.
+ * @BitMask: Bitmask.
+ *
+ * Return: Return the shift bit position of the mask
+ */
static u32 phy_CalculateBitShift(u32 BitMask)
{
u32 i;
@@ -43,19 +38,17 @@ static u32 phy_CalculateBitShift(u32 BitMask)
/**
-* Function:PHY_QueryBBReg
-*
-* OverView:Read "specific bits" from BB register
-*
-* Input:
-* struct adapter *Adapter,
-* u32 RegAddr,The target address to be
readback
-* u32 BitMask The target bit position in the
target address
-* to be readback
-* Output: None
-* Return: u32 DataThe readback register
value
-* Note:This function is equal to "GetRegSetting" in PHY
programming guide
-*/
+ * PHY_QueryBBReg - Read "specific bits" from BB register.
+ * @Adapter:
+ * @RegAddr: The target address to be readback
+ * @BitMask: The target bit position in the target address
+ * to be readback
+ *
+ * Return: The readback register value
+ *
+ * .. Note:: This function is equal to "GetRegSetting" in PHY programming
+ * guide
+ */
u32 PHY_QueryBBReg_8723B(struct adapter *Adapter, u32 RegAddr, u32 BitMask)
{
u32 OriginalValue, BitShift;
@@ -75,22 +68,17 @@ u32 PHY_QueryBBReg_8723B(struct adapter *Adapter, u32
RegAddr, u32 BitMask)
/**
-* Function:PHY_SetBBReg
-*
-* OverView:Write "Specific bits" to BB register (page 8~)
-*
-* Input:
-* struct adapter *Adapter,
-* u32 RegAddr,The target address to be
modified
-* u32 BitMask The target bit position in the
target address
-* to be modified
-* u32 DataThe new register value in the
target bit position
-* of the target
address
-*
-* Output: None
-* Return: None
-* Note:This function is equal to "PutRegSetting" in PHY
programming guide
-*/
+ * PHY_SetBBReg - Write "Specific bits" to BB register (page 8~).
+ * @Adapter:
+ * @RegAddr: The target address to be modified
+ * @BitMask: The target bit position in the target address
+ * to be modified
+ * @Data: The new register value in the target bit position
+ * of the target address
+ *
+ * .. Note:: This function is equal to "PutRegSetting" in PHY programming
+ * guide
+ */
void PHY_SetBBReg_8723B(
struct adapter *Adapter,
@@ -184,27 +172,21 @@ static u32 phy_RFSerialRead_8723B(
}
/**
-* Function:phy_RFSerialWrite_8723B
-*
-* OverView:Write data to RF register (page 8~)
-*
-* Input:
-* struct adapter *Adapter,
-* RF_PATH eRFPath,Radio path of A/B/C/D
-* u32 Offset, The target address to be read
-* u32 DataThe new register Data in the
target bit position
-* of the target
to be read
-*
-* Output: None
-* Return: None
-* Note:Threre are three types of serial operations:
-* 1. Software serial write
-* 2. Hardware LSSI-Low Speed Serial Interface
-* 3. Hardware HSSI-High speed
-* serial write. Driver need to implement (1) and (2).
-* This function is equal to the combination of RF_ReadReg() and
RFLSSIRead()
+ * phy_RFSerialWrite_8723B - Write data to RF register (page 8~).
+ * @Adapter:
+ * @eRFPath: Radio path of A/B/C/D
+ * @Offset:The target address to be read
+ * @Data: The new register Data in the target bit position
+ * of the target to be read
+ *
+ * .. Note:: Threre are three types of serial operations:
+ * 1.
[PATCH v4 0/2] staging: rtl8723bs: driver cleanup
karthik alapati (2): staging: rtl8723bs: fix function comments to follow kernel-doc staging: rtl8723bs: remove obsolete commented out code .../staging/rtl8723bs/hal/rtl8723b_phycfg.c | 225 ++ 1 file changed, 75 insertions(+), 150 deletions(-) -- 2.30.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH -next] staging: ks7010: Macros with complex values
On Thu, Feb 11, 2021 at 03:23:24PM +0300, Fatih Yildirim wrote:
> On Thu, Feb 11, 2021 at 12:10:44PM +0100, Greg KH wrote:
> > On Thu, Feb 11, 2021 at 01:57:04PM +0300, Fatih YILDIRIM wrote:
> > > On Thu, Feb 11, 2021 at 11:02:51AM +0100, Greg KH wrote:
> > > > On Thu, Feb 11, 2021 at 12:22:39PM +0300, Fatih Yildirim wrote:
> > > > > Fix for checkpatch.pl warning:
> > > > > Macros with complex values should be enclosed in parentheses.
> > > > >
> > > > > Signed-off-by: Fatih Yildirim
> > > > > ---
> > > > > drivers/staging/ks7010/ks_hostif.h | 24
> > > > > 1 file changed, 12 insertions(+), 12 deletions(-)
> > > > >
> > > > > diff --git a/drivers/staging/ks7010/ks_hostif.h
> > > > > b/drivers/staging/ks7010/ks_hostif.h
> > > > > index 39138191a556..c62a494ed6bb 100644
> > > > > --- a/drivers/staging/ks7010/ks_hostif.h
> > > > > +++ b/drivers/staging/ks7010/ks_hostif.h
> > > > > @@ -498,20 +498,20 @@ struct hostif_mic_failure_request {
> > > > > #define TX_RATE_FIXED5
> > > > >
> > > > > /* 11b rate */
> > > > > -#define TX_RATE_1M (u8)(10 / 5)/* 11b 11g basic rate */
> > > > > -#define TX_RATE_2M (u8)(20 / 5)/* 11b 11g basic rate */
> > > > > -#define TX_RATE_5M (u8)(55 / 5)/* 11g basic rate */
> > > > > -#define TX_RATE_11M (u8)(110 / 5) /* 11g basic rate */
> > > > > +#define TX_RATE_1M ((u8)(10 / 5)) /* 11b 11g basic rate */
> > > > > +#define TX_RATE_2M ((u8)(20 / 5)) /* 11b 11g basic rate */
> > > > > +#define TX_RATE_5M ((u8)(55 / 5)) /* 11g basic rate */
> > > > > +#define TX_RATE_11M ((u8)(110 / 5)) /* 11g basic rate */
> > > >
> > > > But these are not "complex macros" that need an extra () added to them,
> > > > right?
> > > >
> > > > Checkpatch is a hint, it's not a code parser and can not always know
> > > > what is happening. With your knowledge of C, does this look like
> > > > something that needs to be "fixed"?
> > > >
> > > > thanks,
> > > >
> > > > greg k-h
> > >
> > > Hi Greg,
> > >
> > > Thanks for your reply.
> > > Actually, I'm following the Eudyptula Challenge and I'm at task 10.
> >
> > First rule of that challenge is that you are not allowed to talk about
> > it in public :)
> >
> > That being said, you didn't answer any of my questions above :(
> >
> > greg k-h
>
> Ohh no, missed the rule. Sorry for that, I feel rookie :)
> You are right, they are not complex macros.
> Besides that, type cast operator doesn't have the highest precedence.
> So, I think we can use enclosing paranthesis.
I don't think they are needed, see how these are used please.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wfx: avoid defining array of flexible struct
On Thursday 11 February 2021 11:50:26 CET Muhammad Usama Anjum wrote:
>
> In this particular case, the struct element is already flexible struct.
> Thus struct element ie[] is ambiguous inside another struct. The members
> of struct element ie aren't being accessed in code anywhere. The data of
> u8 type is copied in it. So it has been changed to u8 ie[] to make the
> sparse happy and code simple.
You may also mention that the driver code does not care of the type of
the ie attribute. It is only accessed from one place with memcpy().
>
> Warning from sparse:
> drivers/stagingwfx/hif_tx.c: note: in included file (through
> drivers/stagingwfx/data_tx.h, drivers/staging//wfx/wfx.h):
> drivers/staging//wfx/hif_api_cmd.h:103:26: warning: array of flexible
> structures
>
> Signed-off-by: Muhammad Usama Anjum
> ---
> drivers/staging/wfx/hif_api_cmd.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/wfx/hif_api_cmd.h
> b/drivers/staging/wfx/hif_api_cmd.h
> index 11bc1a58edae..58c9bb036011 100644
> --- a/drivers/staging/wfx/hif_api_cmd.h
> +++ b/drivers/staging/wfx/hif_api_cmd.h
> @@ -100,7 +100,7 @@ struct hif_req_update_ie {
> u8 reserved1:5;
> u8 reserved2;
> __le16 num_ies;
> - struct element ie[];
> + u8 ie[];
> } __packed;
>
> struct hif_cnf_update_ie {
> --
> 2.25.1
>
>
I think that "#include " is no more necessary.
Else:
Reviewed-by: Jérôme Pouiller
--
Jérôme Pouiller
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH -next] staging: ks7010: Macros with complex values
On Thu, Feb 11, 2021 at 12:10:44PM +0100, Greg KH wrote:
> On Thu, Feb 11, 2021 at 01:57:04PM +0300, Fatih YILDIRIM wrote:
> > On Thu, Feb 11, 2021 at 11:02:51AM +0100, Greg KH wrote:
> > > On Thu, Feb 11, 2021 at 12:22:39PM +0300, Fatih Yildirim wrote:
> > > > Fix for checkpatch.pl warning:
> > > > Macros with complex values should be enclosed in parentheses.
> > > >
> > > > Signed-off-by: Fatih Yildirim
> > > > ---
> > > > drivers/staging/ks7010/ks_hostif.h | 24
> > > > 1 file changed, 12 insertions(+), 12 deletions(-)
> > > >
> > > > diff --git a/drivers/staging/ks7010/ks_hostif.h
> > > > b/drivers/staging/ks7010/ks_hostif.h
> > > > index 39138191a556..c62a494ed6bb 100644
> > > > --- a/drivers/staging/ks7010/ks_hostif.h
> > > > +++ b/drivers/staging/ks7010/ks_hostif.h
> > > > @@ -498,20 +498,20 @@ struct hostif_mic_failure_request {
> > > > #define TX_RATE_FIXED 5
> > > >
> > > > /* 11b rate */
> > > > -#define TX_RATE_1M (u8)(10 / 5)/* 11b 11g basic rate */
> > > > -#define TX_RATE_2M (u8)(20 / 5)/* 11b 11g basic rate */
> > > > -#define TX_RATE_5M (u8)(55 / 5)/* 11g basic rate */
> > > > -#define TX_RATE_11M(u8)(110 / 5) /* 11g basic rate */
> > > > +#define TX_RATE_1M ((u8)(10 / 5)) /* 11b 11g basic rate */
> > > > +#define TX_RATE_2M ((u8)(20 / 5)) /* 11b 11g basic rate */
> > > > +#define TX_RATE_5M ((u8)(55 / 5)) /* 11g basic rate */
> > > > +#define TX_RATE_11M((u8)(110 / 5)) /* 11g basic rate */
> > >
> > > But these are not "complex macros" that need an extra () added to them,
> > > right?
> > >
> > > Checkpatch is a hint, it's not a code parser and can not always know
> > > what is happening. With your knowledge of C, does this look like
> > > something that needs to be "fixed"?
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > Hi Greg,
> >
> > Thanks for your reply.
> > Actually, I'm following the Eudyptula Challenge and I'm at task 10.
>
> First rule of that challenge is that you are not allowed to talk about
> it in public :)
>
> That being said, you didn't answer any of my questions above :(
>
> greg k-h
Ohh no, missed the rule. Sorry for that, I feel rookie :)
You are right, they are not complex macros.
Besides that, type cast operator doesn't have the highest precedence.
So, I think we can use enclosing paranthesis.
Thanks,
Fatih
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/4] reset: Add reset driver for IMX8MQ VPU block
IMX8MQ SoC got a dedicated hardware block to reset the video processor
units (G1 and G2).
Signed-off-by: Benjamin Gaignard
---
drivers/reset/Kconfig| 8 ++
drivers/reset/Makefile | 1 +
drivers/reset/reset-imx8mq-vpu.c | 169 +++
3 files changed, 178 insertions(+)
create mode 100644 drivers/reset/reset-imx8mq-vpu.c
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 71ab75a46491..fa95380b271a 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -80,6 +80,14 @@ config RESET_IMX7
help
This enables the reset controller driver for i.MX7 SoCs.
+config RESET_VPU_IMX8MQ
+ tristate "i.MX8MQ VPU Reset Driver"
+ depends on HAS_IOMEM
+ depends on (ARM64 && ARCH_MXC) || COMPILE_TEST
+ select MFD_SYSCON
+ help
+ This enables the VPU reset controller driver for i.MX8MQ SoCs.
+
config RESET_INTEL_GW
bool "Intel Reset Controller Driver"
depends on OF && HAS_IOMEM
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 1054123fd187..6007e0cdfc05 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_RESET_BRCMSTB) += reset-brcmstb.o
obj-$(CONFIG_RESET_BRCMSTB_RESCAL) += reset-brcmstb-rescal.o
obj-$(CONFIG_RESET_HSDK) += reset-hsdk.o
obj-$(CONFIG_RESET_IMX7) += reset-imx7.o
+obj-$(CONFIG_RESET_VPU_IMX8MQ) += reset-imx8mq-vpu.o
obj-$(CONFIG_RESET_INTEL_GW) += reset-intel-gw.o
obj-$(CONFIG_RESET_LANTIQ) += reset-lantiq.o
obj-$(CONFIG_RESET_LPC18XX) += reset-lpc18xx.o
diff --git a/drivers/reset/reset-imx8mq-vpu.c b/drivers/reset/reset-imx8mq-vpu.c
new file mode 100644
index ..14c589f19266
--- /dev/null
+++ b/drivers/reset/reset-imx8mq-vpu.c
@@ -0,0 +1,169 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2021, Collabora
+ *
+ * i.MX8MQ VPU Reset Controller driver
+ *
+ * Author: Benjamin Gaignard
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define CTRL_SOFT_RESET0x00
+#define RESET_G1 ((u32)BIT(1))
+#define RESET_G2 ((u32)BIT(0))
+
+#define CTRL_ENABLE0x04
+#define ENABLE_G1 BIT(1)
+#define ENABLE_G2 BIT(0)
+
+#define CTRL_G1_DEC_FUSE 0x08
+#define CTRL_G1_PP_FUSE0x0c
+#define CTRL_G2_DEC_FUSE 0x10
+
+struct imx8mq_vpu_reset {
+ struct reset_controller_dev rcdev;
+ struct regmap *regmap;
+ struct clk_bulk_data *clocks;
+ int num_clocks;
+ struct device *dev;
+};
+
+static inline struct imx8mq_vpu_reset *to_imx8mq_vpu_reset(struct
reset_controller_dev *rcdev)
+{
+ return container_of(rcdev, struct imx8mq_vpu_reset, rcdev);
+}
+
+static int imx8mq_vpu_reset_assert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct imx8mq_vpu_reset *reset = to_imx8mq_vpu_reset(rcdev);
+ int ret = -EINVAL;
+
+ ret = clk_bulk_prepare_enable(reset->num_clocks, reset->clocks);
+ if (ret) {
+ dev_err(reset->dev, "Failed to prepare clocks\n");
+ return ret;
+ }
+
+ switch (id) {
+ case IMX8MQ_RESET_VPU_RESET_G1:
+ ret = regmap_update_bits(reset->regmap, CTRL_SOFT_RESET,
RESET_G1, ~RESET_G1);
+ ret |= regmap_update_bits(reset->regmap, CTRL_ENABLE,
ENABLE_G1, ENABLE_G1);
+ break;
+ case IMX8MQ_RESET_VPU_RESET_G2:
+ ret = regmap_update_bits(reset->regmap, CTRL_SOFT_RESET,
RESET_G2, ~RESET_G2);
+ ret |= regmap_update_bits(reset->regmap, CTRL_ENABLE,
ENABLE_G2, ENABLE_G2);
+ break;
+ }
+
+ /* Set values of the fuse registers */
+ ret |= regmap_write(reset->regmap, CTRL_G1_DEC_FUSE, 0x);
+ ret |= regmap_write(reset->regmap, CTRL_G1_PP_FUSE, 0x);
+ ret |= regmap_write(reset->regmap, CTRL_G2_DEC_FUSE, 0x);
+
+ clk_bulk_disable_unprepare(reset->num_clocks, reset->clocks);
+
+ return ret;
+}
+
+static int imx8mq_vpu_reset_deassert(struct reset_controller_dev *rcdev,
+unsigned long id)
+{
+ struct imx8mq_vpu_reset *reset = to_imx8mq_vpu_reset(rcdev);
+ int ret;
+
+ ret = clk_bulk_prepare_enable(reset->num_clocks, reset->clocks);
+ if (ret) {
+ dev_err(reset->dev, "Failed to prepare clocks\n");
+ return ret;
+ }
+
+ switch (id) {
+ case IMX8MQ_RESET_VPU_RESET_G1:
+ return regmap_update_bits(reset->regmap, CTRL_SOFT_RESET,
RESET_G1, RESET_G1);
+ case IMX8MQ_RESET_VPU_RESET_G2:
+ return regmap_update_bits(reset->regmap, CTRL_SOFT_RESET,
RESET_G2, RESET_G2);
+ }
+
+ clk_bulk_disable_unprepare(reset->num_clocks, reset->clocks);
+
+ return -EINVAL;
+}
+
+static int
[PATCH 4/4] arm64: dts: imx8mq: Use reset driver for VPU hardware block
Add a vpu reset hardware block node.
Signed-off-by: Benjamin Gaignard
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 31 ++-
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index a841a023e8e0..7d4863d47112 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include "dt-bindings/input/input.h"
#include
@@ -1267,19 +1268,36 @@ usb3_phy1: usb-phy@382f0040 {
status = "disabled";
};
+ vpu_reset: vpu-reset@3832 {
+ compatible = "fsl,imx8mq-vpu-reset", "syscon";
+ reg = <0x3832 0x1>;
+ clocks = < IMX8MQ_CLK_VPU_G1_ROOT>,
+< IMX8MQ_CLK_VPU_G2_ROOT>,
+< IMX8MQ_CLK_VPU_DEC_ROOT>;
+ assigned-clocks = < IMX8MQ_CLK_VPU_G1>,
+ < IMX8MQ_CLK_VPU_G2>,
+ < IMX8MQ_CLK_VPU_BUS>,
+ < IMX8MQ_VPU_PLL_BYPASS>;
+ assigned-clock-parents = < IMX8MQ_VPU_PLL_OUT>,
+< IMX8MQ_VPU_PLL_OUT>,
+< IMX8MQ_SYS1_PLL_800M>,
+< IMX8MQ_VPU_PLL>;
+ assigned-clock-rates = <6>, <6>,
+ <8>, <0>;
+ #reset-cells = <1>;
+ };
+
vpu: video-codec@3830 {
compatible = "nxp,imx8mq-vpu";
reg = <0x3830 0x1>,
- <0x3831 0x1>,
- <0x3832 0x1>;
- reg-names = "g1", "g2", "ctrl";
+ <0x3831 0x1>;
+ reg-names = "g1", "g2";
interrupts = ,
;
interrupt-names = "g1", "g2";
clocks = < IMX8MQ_CLK_VPU_G1_ROOT>,
-< IMX8MQ_CLK_VPU_G2_ROOT>,
-< IMX8MQ_CLK_VPU_DEC_ROOT>;
- clock-names = "g1", "g2", "bus";
+< IMX8MQ_CLK_VPU_G2_ROOT>;
+ clock-names = "g1", "g2";
assigned-clocks = < IMX8MQ_CLK_VPU_G1>,
< IMX8MQ_CLK_VPU_G2>,
< IMX8MQ_CLK_VPU_BUS>,
@@ -1290,6 +1308,7 @@ vpu: video-codec@3830 {
< IMX8MQ_VPU_PLL>;
assigned-clock-rates = <6>, <6>,
<8>, <0>;
+ resets = <_reset IMX8MQ_RESET_VPU_RESET_G1>;
power-domains = <_vpu>;
};
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/4] media: hantro: Use reset driver
Rather use a reset like feature inside the driver use the reset
controller API to get the same result.
Signed-off-by: Benjamin Gaignard
---
drivers/staging/media/hantro/Kconfig| 1 +
drivers/staging/media/hantro/imx8m_vpu_hw.c | 61 -
2 files changed, 12 insertions(+), 50 deletions(-)
diff --git a/drivers/staging/media/hantro/Kconfig
b/drivers/staging/media/hantro/Kconfig
index 5b6cf9f62b1a..dd1d4dde2658 100644
--- a/drivers/staging/media/hantro/Kconfig
+++ b/drivers/staging/media/hantro/Kconfig
@@ -20,6 +20,7 @@ config VIDEO_HANTRO_IMX8M
bool "Hantro VPU i.MX8M support"
depends on VIDEO_HANTRO
depends on ARCH_MXC || COMPILE_TEST
+ select RESET_VPU_IMX8MQ
default y
help
Enable support for i.MX8M SoCs.
diff --git a/drivers/staging/media/hantro/imx8m_vpu_hw.c
b/drivers/staging/media/hantro/imx8m_vpu_hw.c
index c222de075ef4..d5b4312b9391 100644
--- a/drivers/staging/media/hantro/imx8m_vpu_hw.c
+++ b/drivers/staging/media/hantro/imx8m_vpu_hw.c
@@ -7,49 +7,12 @@
#include
#include
+#include
#include "hantro.h"
#include "hantro_jpeg.h"
#include "hantro_g1_regs.h"
-#define CTRL_SOFT_RESET0x00
-#define RESET_G1 BIT(1)
-#define RESET_G2 BIT(0)
-
-#define CTRL_CLOCK_ENABLE 0x04
-#define CLOCK_G1 BIT(1)
-#define CLOCK_G2 BIT(0)
-
-#define CTRL_G1_DEC_FUSE 0x08
-#define CTRL_G1_PP_FUSE0x0c
-#define CTRL_G2_DEC_FUSE 0x10
-
-static void imx8m_soft_reset(struct hantro_dev *vpu, u32 reset_bits)
-{
- u32 val;
-
- /* Assert */
- val = readl(vpu->ctrl_base + CTRL_SOFT_RESET);
- val &= ~reset_bits;
- writel(val, vpu->ctrl_base + CTRL_SOFT_RESET);
-
- udelay(2);
-
- /* Release */
- val = readl(vpu->ctrl_base + CTRL_SOFT_RESET);
- val |= reset_bits;
- writel(val, vpu->ctrl_base + CTRL_SOFT_RESET);
-}
-
-static void imx8m_clk_enable(struct hantro_dev *vpu, u32 clock_bits)
-{
- u32 val;
-
- val = readl(vpu->ctrl_base + CTRL_CLOCK_ENABLE);
- val |= clock_bits;
- writel(val, vpu->ctrl_base + CTRL_CLOCK_ENABLE);
-}
-
static int imx8mq_runtime_resume(struct hantro_dev *vpu)
{
int ret;
@@ -60,13 +23,10 @@ static int imx8mq_runtime_resume(struct hantro_dev *vpu)
return ret;
}
- imx8m_soft_reset(vpu, RESET_G1 | RESET_G2);
- imx8m_clk_enable(vpu, CLOCK_G1 | CLOCK_G2);
+ ret = device_reset(vpu->dev);
+ if (ret)
+ dev_err(vpu->dev, "Failed to reset Hantro VPU\n");
- /* Set values of the fuse registers */
- writel(0x, vpu->ctrl_base + CTRL_G1_DEC_FUSE);
- writel(0x, vpu->ctrl_base + CTRL_G1_PP_FUSE);
- writel(0x, vpu->ctrl_base + CTRL_G2_DEC_FUSE);
clk_bulk_disable_unprepare(vpu->variant->num_clocks, vpu->clocks);
@@ -151,16 +111,17 @@ static irqreturn_t imx8m_vpu_g1_irq(int irq, void *dev_id)
static int imx8mq_vpu_hw_init(struct hantro_dev *vpu)
{
vpu->dec_base = vpu->reg_bases[0];
- vpu->ctrl_base = vpu->reg_bases[vpu->variant->num_regs - 1];
return 0;
}
-static void imx8m_vpu_g1_reset(struct hantro_ctx *ctx)
+static void imx8mq_vpu_reset(struct hantro_ctx *ctx)
{
struct hantro_dev *vpu = ctx->dev;
+ int ret = device_reset(vpu->dev);
- imx8m_soft_reset(vpu, RESET_G1);
+ if (ret)
+ dev_err(vpu->dev, "Failed to reset Hantro VPU\n");
}
/*
@@ -170,19 +131,19 @@ static void imx8m_vpu_g1_reset(struct hantro_ctx *ctx)
static const struct hantro_codec_ops imx8mq_vpu_codec_ops[] = {
[HANTRO_MODE_MPEG2_DEC] = {
.run = hantro_g1_mpeg2_dec_run,
- .reset = imx8m_vpu_g1_reset,
+ .reset = imx8mq_vpu_reset,
.init = hantro_mpeg2_dec_init,
.exit = hantro_mpeg2_dec_exit,
},
[HANTRO_MODE_VP8_DEC] = {
.run = hantro_g1_vp8_dec_run,
- .reset = imx8m_vpu_g1_reset,
+ .reset = imx8mq_vpu_reset,
.init = hantro_vp8_dec_init,
.exit = hantro_vp8_dec_exit,
},
[HANTRO_MODE_H264_DEC] = {
.run = hantro_g1_h264_dec_run,
- .reset = imx8m_vpu_g1_reset,
+ .reset = imx8mq_vpu_reset,
.init = hantro_h264_dec_init,
.exit = hantro_h264_dec_exit,
},
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/4] Reset driver for IMX8MQ VPU hardware block
The two VPUs inside IMX8MQ share the same control block which can be see as a reset hardware block. In order to be able to add the second VPU (for HECV decoding) it will be more handy if the both VPU drivers instance don't have to share the control block registers. This lead to implement it as an independ reset driver and to change the VPU driver to use it. Benjamin Gaignard (4): dt-bindings: reset: IMX8MQ VPU reset reset: Add reset driver for IMX8MQ VPU block media: hantro: Use reset driver arm64: dts: imx8mq: Use reset driver for VPU hardware block .../bindings/reset/fsl,imx8mq-vpu-reset.yaml | 54 ++ arch/arm64/boot/dts/freescale/imx8mq.dtsi | 31 +++- drivers/reset/Kconfig | 8 + drivers/reset/Makefile| 1 + drivers/reset/reset-imx8mq-vpu.c | 169 ++ drivers/staging/media/hantro/Kconfig | 1 + drivers/staging/media/hantro/imx8m_vpu_hw.c | 61 ++- include/dt-bindings/reset/imx8mq-vpu-reset.h | 16 ++ 8 files changed, 285 insertions(+), 56 deletions(-) create mode 100644 Documentation/devicetree/bindings/reset/fsl,imx8mq-vpu-reset.yaml create mode 100644 drivers/reset/reset-imx8mq-vpu.c create mode 100644 include/dt-bindings/reset/imx8mq-vpu-reset.h -- 2.25.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/4] dt-bindings: reset: IMX8MQ VPU reset
Document bindings for IMX8MQ VPU reset hardware block
Signed-off-by: Benjamin Gaignard
---
.../bindings/reset/fsl,imx8mq-vpu-reset.yaml | 54 +++
include/dt-bindings/reset/imx8mq-vpu-reset.h | 16 ++
2 files changed, 70 insertions(+)
create mode 100644
Documentation/devicetree/bindings/reset/fsl,imx8mq-vpu-reset.yaml
create mode 100644 include/dt-bindings/reset/imx8mq-vpu-reset.h
diff --git a/Documentation/devicetree/bindings/reset/fsl,imx8mq-vpu-reset.yaml
b/Documentation/devicetree/bindings/reset/fsl,imx8mq-vpu-reset.yaml
new file mode 100644
index ..00020421c0e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/fsl,imx8mq-vpu-reset.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reset/fsl,imx8mq-vpu-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8MQ VPU Reset Controller
+
+maintainers:
+ - Benjamin Gaignard
+
+description: |
+ The VPU reset controller is used to reset the video processor
+ unit peripherals. Device nodes that need access to reset lines should
+ specify them as a reset phandle in their corresponding node as
+ specified in reset.txt.
+
+ For list of all valid reset indices see
+ for i.MX8MQ.
+
+properties:
+ compatible:
+items:
+ - const: fsl,imx8mq-vpu-reset
+ - const: syscon
+
+ reg:
+maxItems: 1
+
+ clocks:
+minItems: 1
+maxItems: 3
+
+ '#reset-cells':
+const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+vpu-reset@3832 {
+compatible = "fsl,imx8mq-vpu-reset", "syscon";
+reg = <0x3832 0x1>;
+clocks = < IMX8MQ_CLK_VPU_DEC_ROOT>;
+#reset-cells = <1>;
+};
diff --git a/include/dt-bindings/reset/imx8mq-vpu-reset.h
b/include/dt-bindings/reset/imx8mq-vpu-reset.h
new file mode 100644
index ..efcbe18177fe
--- /dev/null
+++ b/include/dt-bindings/reset/imx8mq-vpu-reset.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2021, Collabora
+ *
+ * i.MX7 System Reset Controller (SRC) driver
+ *
+ * Author: Benjamin Gaignard
+ */
+
+#ifndef DT_BINDINGS_VPU_RESET_IMX8MQ
+#define DT_BINDINGS_VPU_RESET_IMX8MQ
+
+#define IMX8MQ_RESET_VPU_RESET_G1 0
+#define IMX8MQ_RESET_VPU_RESET_G2 1
+
+#endif
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH][next] staging: rtl8723bs: Replace one-element array with flexible-array member in struct ndis_80211_var_ie
On 2/11/21 05:06, Dan Carpenter wrote:
> On Wed, Feb 10, 2021 at 04:49:37PM -0600, Gustavo A. R. Silva wrote:
>> There is a regular need in the kernel to provide a way to declare having
>> a dynamically sized set of trailing elements in a structure. Kernel code
>> should always use “flexible array members”[1] for these cases. The older
>> style of one-element or zero-length arrays should no longer be used[2].
>>
>> Refactor the code according to the use of a flexible-array member in
>> struct ndis_80211_var_ie, instead of a one-element array.
>>
>> Also, this helps with the ongoing efforts to enable -Warray-bounds and
>> fix the following warnings:
>>
>> CC [M] drivers/staging/rtl8723bs/core/rtw_wlan_util.o
>> In file included from ./drivers/staging/rtl8723bs/include/drv_types.h:20,
>> from drivers/staging/rtl8723bs/core/rtw_wlan_util.c:9:
>> drivers/staging/rtl8723bs/core/rtw_wlan_util.c: In function
>> ‘HT_caps_handler’:
>> ./drivers/staging/rtl8723bs/include/basic_types.h:108:11: warning: array
>> subscript 1 is above array bounds of ‘u8[1]’ {aka ‘unsigned char[1]’}
>> [-Warray-bounds]
>> 108 | (EF1BYTE(*((u8 *)(__pstart
>> | ^
>> ./drivers/staging/rtl8723bs/include/basic_types.h:42:8: note: in definition
>> of macro ‘EF1BYTE’
>>42 | ((u8)(_val))
>> |^~~~
>> ./drivers/staging/rtl8723bs/include/basic_types.h:127:4: note: in expansion
>> of macro ‘LE_P1BYTE_TO_HOST_1BYTE’
>> 127 | (LE_P1BYTE_TO_HOST_1BYTE(__pstart) >> (__bitoffset)) & \
>> |^~~
>> ./drivers/staging/rtl8723bs/include/rtw_ht.h:97:55: note: in expansion of
>> macro ‘LE_BITS_TO_1BYTE’
>>97 | #define GET_HT_CAPABILITY_ELE_RX_STBC(_pEleStart)
>> LE_BITS_TO_1BYTE((_pEleStart)+1, 0, 2)
>> |
>> ^~~~
>> drivers/staging/rtl8723bs/core/rtw_wlan_util.c:1104:58: note: in expansion
>> of macro ‘GET_HT_CAPABILITY_ELE_RX_STBC’
>> 1104 | if (TEST_FLAG(phtpriv->stbc_cap, STBC_HT_ENABLE_TX) &&
>> GET_HT_CAPABILITY_ELE_RX_STBC(pIE->data)) {
>> |
>> ^
>> drivers/staging/rtl8723bs/core/rtw_wlan_util.c:1051:75: warning: array
>> subscript 2 is above array bounds of ‘u8[1]’ {aka ‘unsigned char[1]’}
>> [-Warray-bounds]
>> 1051 |if ((pmlmeinfo->HT_caps.u.HT_cap_element.AMPDU_para & 0x3) >
>> (pIE->data[i] & 0x3))
>> |
>> ~^~~
>> drivers/staging/rtl8723bs/core/rtw_wlan_util.c: In function ‘check_assoc_AP’:
>> drivers/staging/rtl8723bs/core/rtw_wlan_util.c:1606:19: warning: array
>> subscript 4 is above array bounds of ‘u8[1]’ {aka ‘unsigned char[1]’}
>> [-Warray-bounds]
>> 1606 | if (pIE->data[4] == 1)
>> | ~^~~
>> drivers/staging/rtl8723bs/core/rtw_wlan_util.c:1609:20: warning: array
>> subscript 5 is above array bounds of ‘u8[1]’ {aka ‘unsigned char[1]’}
>> [-Warray-bounds]
>> 1609 | if (pIE->data[5] & RT_HT_CAP_USE_92SE)
>> | ~^~~
>> drivers/staging/rtl8723bs/core/rtw_wlan_util.c:1613:19: warning: array
>> subscript 5 is above array bounds of ‘u8[1]’ {aka ‘unsigned char[1]’}
>> [-Warray-bounds]
>> 1613 | if (pIE->data[5] & RT_HT_CAP_USE_SOFTAP)
>> | ~^~~
>> drivers/staging/rtl8723bs/core/rtw_wlan_util.c:1617:20: warning: array
>> subscript 6 is above array bounds of ‘u8[1]’ {aka ‘unsigned char[1]’}
>> [-Warray-bounds]
>> 1617 | if (pIE->data[6] & RT_HT_CAP_USE_JAGUAR_BCUT) {
>> | ~^~~
>>
>> [1] https://en.wikipedia.org/wiki/Flexible_array_member
>> [2]
>> https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays
>>
>> Link: https://github.com/KSPP/linux/issues/79
>> Link: https://github.com/KSPP/linux/issues/109
>> Build-tested-by: kernel test robot
>> Link: https://lore.kernel.org/lkml/602434b8.jc5doxj0bmhoxgil%25...@intel.com/
>> Signed-off-by: Gustavo A. R. Silva
>
> Looks okay to me. I looked for potential issues with changing the
> sizeof the struct but couldn't find any.
Great. Yeah; that's one of the first things I look at when I make
these changes. Thanks for double checking. :)
> Reviewed-by: Dan Carpenter
Thanks!
--
Gustavo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: ks7010: enclosed complex macro definitions with parentheses
On Thu, Feb 11, 2021 at 04:26:36PM +0530, Pritthijit Nath wrote:
> kshostif.h
Why is this in the changelog text?
>
> fixed ERROR: Macros with complex values should be enclosed in
> paranthesis
What does that mean?
>
> Signed-off-by: Pritthijit Nath
> ---
> drivers/staging/ks7010/ks_hostif.h | 24
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/staging/ks7010/ks_hostif.h
> b/drivers/staging/ks7010/ks_hostif.h
> index 39138191a556..c62a494ed6bb 100644
> --- a/drivers/staging/ks7010/ks_hostif.h
> +++ b/drivers/staging/ks7010/ks_hostif.h
> @@ -498,20 +498,20 @@ struct hostif_mic_failure_request {
> #define TX_RATE_FIXED5
>
> /* 11b rate */
> -#define TX_RATE_1M (u8)(10 / 5)/* 11b 11g basic rate */
> -#define TX_RATE_2M (u8)(20 / 5)/* 11b 11g basic rate */
> -#define TX_RATE_5M (u8)(55 / 5)/* 11g basic rate */
> -#define TX_RATE_11M (u8)(110 / 5) /* 11g basic rate */
> +#define TX_RATE_1M ((u8)(10 / 5)) /* 11b 11g basic rate */
> +#define TX_RATE_2M ((u8)(20 / 5)) /* 11b 11g basic rate */
> +#define TX_RATE_5M ((u8)(55 / 5)) /* 11g basic rate */
> +#define TX_RATE_11M ((u8)(110 / 5)) /* 11g basic rate */
>
> /* 11g rate */
> -#define TX_RATE_6M (u8)(60 / 5)/* 11g basic rate */
> -#define TX_RATE_12M (u8)(120 / 5) /* 11g basic rate */
> -#define TX_RATE_24M (u8)(240 / 5) /* 11g basic rate */
> -#define TX_RATE_9M (u8)(90 / 5)
> -#define TX_RATE_18M (u8)(180 / 5)
> -#define TX_RATE_36M (u8)(360 / 5)
> -#define TX_RATE_48M (u8)(480 / 5)
> -#define TX_RATE_54M (u8)(540 / 5)
> +#define TX_RATE_6M ((u8)(60 / 5)) /* 11g basic rate */
> +#define TX_RATE_12M ((u8)(120 / 5)) /* 11g basic rate */
> +#define TX_RATE_24M ((u8)(240 / 5)) /* 11g basic rate */
> +#define TX_RATE_9M ((u8)(90 / 5))
> +#define TX_RATE_18M ((u8)(180 / 5))
> +#define TX_RATE_36M ((u8)(360 / 5))
> +#define TX_RATE_48M ((u8)(480 / 5))
> +#define TX_RATE_54M ((u8)(540 / 5))
>
> static inline bool is_11b_rate(u8 rate)
> {
Did you see the review comments on the list for this identical patch?
Please refer to that...
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: fix function comments to follow kernel-doc
On Thu, Feb 11, 2021 at 12:40:15AM +0530, karthik alapati wrote: > fix checkpatch.pl warning for "block comments should align the > * on each line" and make function comments follow kernel-doc > > Signed-off-by: karthik alapati > --- > .../staging/rtl8723bs/hal/rtl8723b_phycfg.c | 185 +++--- > 1 file changed, 73 insertions(+), 112 deletions(-) > > diff --git a/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c > b/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c > index cf23414d7..1fd504181 100644 > --- a/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c > +++ b/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c > @@ -20,16 +20,11 @@ > #define MAX_DOZE_WAITING_TIMES_9x 64 > > /** > -* Function: phy_CalculateBitShift > -* > -* OverView: Get shifted position of the BitMask > -* > -* Input: > -*u32 BitMask, > -* > -* Output:none > -* Return:u32 Return the shift bit bit position of the mask > -*/ > + * phy_CalculateBitShift - Get shifted position of the BitMask. > + * @BitMask: Bitmask. > + * > + * Return: Return the shift bit position of the mask > + */ Why indent these comments by a tab? A single space is fine. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH -next] staging: ks7010: Macros with complex values
On Thu, Feb 11, 2021 at 01:57:04PM +0300, Fatih YILDIRIM wrote:
> On Thu, Feb 11, 2021 at 11:02:51AM +0100, Greg KH wrote:
> > On Thu, Feb 11, 2021 at 12:22:39PM +0300, Fatih Yildirim wrote:
> > > Fix for checkpatch.pl warning:
> > > Macros with complex values should be enclosed in parentheses.
> > >
> > > Signed-off-by: Fatih Yildirim
> > > ---
> > > drivers/staging/ks7010/ks_hostif.h | 24
> > > 1 file changed, 12 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/drivers/staging/ks7010/ks_hostif.h
> > > b/drivers/staging/ks7010/ks_hostif.h
> > > index 39138191a556..c62a494ed6bb 100644
> > > --- a/drivers/staging/ks7010/ks_hostif.h
> > > +++ b/drivers/staging/ks7010/ks_hostif.h
> > > @@ -498,20 +498,20 @@ struct hostif_mic_failure_request {
> > > #define TX_RATE_FIXED5
> > >
> > > /* 11b rate */
> > > -#define TX_RATE_1M (u8)(10 / 5)/* 11b 11g basic rate */
> > > -#define TX_RATE_2M (u8)(20 / 5)/* 11b 11g basic rate */
> > > -#define TX_RATE_5M (u8)(55 / 5)/* 11g basic rate */
> > > -#define TX_RATE_11M (u8)(110 / 5) /* 11g basic rate */
> > > +#define TX_RATE_1M ((u8)(10 / 5)) /* 11b 11g basic rate */
> > > +#define TX_RATE_2M ((u8)(20 / 5)) /* 11b 11g basic rate */
> > > +#define TX_RATE_5M ((u8)(55 / 5)) /* 11g basic rate */
> > > +#define TX_RATE_11M ((u8)(110 / 5)) /* 11g basic rate */
> >
> > But these are not "complex macros" that need an extra () added to them,
> > right?
> >
> > Checkpatch is a hint, it's not a code parser and can not always know
> > what is happening. With your knowledge of C, does this look like
> > something that needs to be "fixed"?
> >
> > thanks,
> >
> > greg k-h
>
> Hi Greg,
>
> Thanks for your reply.
> Actually, I'm following the Eudyptula Challenge and I'm at task 10.
First rule of that challenge is that you are not allowed to talk about
it in public :)
That being said, you didn't answer any of my questions above :(
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH][next] staging: rtl8723bs: Replace one-element array with flexible-array member in struct ndis_80211_var_ie
On Wed, Feb 10, 2021 at 04:49:37PM -0600, Gustavo A. R. Silva wrote:
> There is a regular need in the kernel to provide a way to declare having
> a dynamically sized set of trailing elements in a structure. Kernel code
> should always use “flexible array members”[1] for these cases. The older
> style of one-element or zero-length arrays should no longer be used[2].
>
> Refactor the code according to the use of a flexible-array member in
> struct ndis_80211_var_ie, instead of a one-element array.
>
> Also, this helps with the ongoing efforts to enable -Warray-bounds and
> fix the following warnings:
>
> CC [M] drivers/staging/rtl8723bs/core/rtw_wlan_util.o
> In file included from ./drivers/staging/rtl8723bs/include/drv_types.h:20,
> from drivers/staging/rtl8723bs/core/rtw_wlan_util.c:9:
> drivers/staging/rtl8723bs/core/rtw_wlan_util.c: In function ‘HT_caps_handler’:
> ./drivers/staging/rtl8723bs/include/basic_types.h:108:11: warning: array
> subscript 1 is above array bounds of ‘u8[1]’ {aka ‘unsigned char[1]’}
> [-Warray-bounds]
> 108 | (EF1BYTE(*((u8 *)(__pstart
> | ^
> ./drivers/staging/rtl8723bs/include/basic_types.h:42:8: note: in definition
> of macro ‘EF1BYTE’
>42 | ((u8)(_val))
> |^~~~
> ./drivers/staging/rtl8723bs/include/basic_types.h:127:4: note: in expansion
> of macro ‘LE_P1BYTE_TO_HOST_1BYTE’
> 127 | (LE_P1BYTE_TO_HOST_1BYTE(__pstart) >> (__bitoffset)) & \
> |^~~
> ./drivers/staging/rtl8723bs/include/rtw_ht.h:97:55: note: in expansion of
> macro ‘LE_BITS_TO_1BYTE’
>97 | #define GET_HT_CAPABILITY_ELE_RX_STBC(_pEleStart)
> LE_BITS_TO_1BYTE((_pEleStart)+1, 0, 2)
> | ^~~~
> drivers/staging/rtl8723bs/core/rtw_wlan_util.c:1104:58: note: in expansion of
> macro ‘GET_HT_CAPABILITY_ELE_RX_STBC’
> 1104 | if (TEST_FLAG(phtpriv->stbc_cap, STBC_HT_ENABLE_TX) &&
> GET_HT_CAPABILITY_ELE_RX_STBC(pIE->data)) {
> |
> ^
> drivers/staging/rtl8723bs/core/rtw_wlan_util.c:1051:75: warning: array
> subscript 2 is above array bounds of ‘u8[1]’ {aka ‘unsigned char[1]’}
> [-Warray-bounds]
> 1051 |if ((pmlmeinfo->HT_caps.u.HT_cap_element.AMPDU_para & 0x3) >
> (pIE->data[i] & 0x3))
> |
> ~^~~
> drivers/staging/rtl8723bs/core/rtw_wlan_util.c: In function ‘check_assoc_AP’:
> drivers/staging/rtl8723bs/core/rtw_wlan_util.c:1606:19: warning: array
> subscript 4 is above array bounds of ‘u8[1]’ {aka ‘unsigned char[1]’}
> [-Warray-bounds]
> 1606 | if (pIE->data[4] == 1)
> | ~^~~
> drivers/staging/rtl8723bs/core/rtw_wlan_util.c:1609:20: warning: array
> subscript 5 is above array bounds of ‘u8[1]’ {aka ‘unsigned char[1]’}
> [-Warray-bounds]
> 1609 | if (pIE->data[5] & RT_HT_CAP_USE_92SE)
> | ~^~~
> drivers/staging/rtl8723bs/core/rtw_wlan_util.c:1613:19: warning: array
> subscript 5 is above array bounds of ‘u8[1]’ {aka ‘unsigned char[1]’}
> [-Warray-bounds]
> 1613 | if (pIE->data[5] & RT_HT_CAP_USE_SOFTAP)
> | ~^~~
> drivers/staging/rtl8723bs/core/rtw_wlan_util.c:1617:20: warning: array
> subscript 6 is above array bounds of ‘u8[1]’ {aka ‘unsigned char[1]’}
> [-Warray-bounds]
> 1617 | if (pIE->data[6] & RT_HT_CAP_USE_JAGUAR_BCUT) {
> | ~^~~
>
> [1] https://en.wikipedia.org/wiki/Flexible_array_member
> [2]
> https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays
>
> Link: https://github.com/KSPP/linux/issues/79
> Link: https://github.com/KSPP/linux/issues/109
> Build-tested-by: kernel test robot
> Link: https://lore.kernel.org/lkml/602434b8.jc5doxj0bmhoxgil%25...@intel.com/
> Signed-off-by: Gustavo A. R. Silva
Looks okay to me. I looked for potential issues with changing the
sizeof the struct but couldn't find any.
Reviewed-by: Dan Carpenter
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH -next] staging: ks7010: Macros with complex values
On Thu, Feb 11, 2021 at 11:02:51AM +0100, Greg KH wrote:
> On Thu, Feb 11, 2021 at 12:22:39PM +0300, Fatih Yildirim wrote:
> > Fix for checkpatch.pl warning:
> > Macros with complex values should be enclosed in parentheses.
> >
> > Signed-off-by: Fatih Yildirim
> > ---
> > drivers/staging/ks7010/ks_hostif.h | 24
> > 1 file changed, 12 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/staging/ks7010/ks_hostif.h
> > b/drivers/staging/ks7010/ks_hostif.h
> > index 39138191a556..c62a494ed6bb 100644
> > --- a/drivers/staging/ks7010/ks_hostif.h
> > +++ b/drivers/staging/ks7010/ks_hostif.h
> > @@ -498,20 +498,20 @@ struct hostif_mic_failure_request {
> > #define TX_RATE_FIXED 5
> >
> > /* 11b rate */
> > -#define TX_RATE_1M (u8)(10 / 5)/* 11b 11g basic rate */
> > -#define TX_RATE_2M (u8)(20 / 5)/* 11b 11g basic rate */
> > -#define TX_RATE_5M (u8)(55 / 5)/* 11g basic rate */
> > -#define TX_RATE_11M(u8)(110 / 5) /* 11g basic rate */
> > +#define TX_RATE_1M ((u8)(10 / 5)) /* 11b 11g basic rate */
> > +#define TX_RATE_2M ((u8)(20 / 5)) /* 11b 11g basic rate */
> > +#define TX_RATE_5M ((u8)(55 / 5)) /* 11g basic rate */
> > +#define TX_RATE_11M((u8)(110 / 5)) /* 11g basic rate */
>
> But these are not "complex macros" that need an extra () added to them,
> right?
>
> Checkpatch is a hint, it's not a code parser and can not always know
> what is happening. With your knowledge of C, does this look like
> something that needs to be "fixed"?
>
> thanks,
>
> greg k-h
Hi Greg,
Thanks for your reply.
Actually, I'm following the Eudyptula Challenge and I'm at task 10.
Task is to find and fix a coding style in linux-next/drivers/staging.
I've checked many files with checkpatch.pl but they are almost fine :)
I found this one and prepared a patch for it.
Thanks in advance for your comments and advice.
Thanks,
Fatih
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: remove obsolete commented out code
On Thu, Feb 11, 2021 at 4:16 PM Greg Kroah-Hartman wrote: > > A: http://en.wikipedia.org/wiki/Top_post > Q: Were do I find info about this thing called top-posting? > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? > > A: No. > Q: Should I include quotations after my reply? > > http://daringfireball.net/2007/07/on_top > > On Thu, Feb 11, 2021 at 04:00:04PM +0530, karthek wrote: > > Should i send them as patch series? > > Please do. > > thanks, > > greg k-h Yeah, it is clearly mentioned in lfd103 which i do remember but i want you to know that it's purely accidental ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: wfx: avoid defining array of flexible struct
In this particular case, the struct element is already flexible struct.
Thus struct element ie[] is ambiguous inside another struct. The members
of struct element ie aren't being accessed in code anywhere. The data of
u8 type is copied in it. So it has been changed to u8 ie[] to make the
sparse happy and code simple.
Warning from sparse:
drivers/stagingwfx/hif_tx.c: note: in included file (through
drivers/stagingwfx/data_tx.h, drivers/staging//wfx/wfx.h):
drivers/staging//wfx/hif_api_cmd.h:103:26: warning: array of flexible structures
Signed-off-by: Muhammad Usama Anjum
---
drivers/staging/wfx/hif_api_cmd.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wfx/hif_api_cmd.h
b/drivers/staging/wfx/hif_api_cmd.h
index 11bc1a58edae..58c9bb036011 100644
--- a/drivers/staging/wfx/hif_api_cmd.h
+++ b/drivers/staging/wfx/hif_api_cmd.h
@@ -100,7 +100,7 @@ struct hif_req_update_ie {
u8 reserved1:5;
u8 reserved2;
__le16 num_ies;
- struct element ie[];
+ u8 ie[];
} __packed;
struct hif_cnf_update_ie {
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: remove obsolete commented out code
A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Thu, Feb 11, 2021 at 04:00:04PM +0530, karthek wrote: > Should i send them as patch series? Please do. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: fix function comments to follow kernel-doc
Sorry On Thu, Feb 11, 2021 at 3:34 PM Greg Kroah-Hartman wrote: > > On Thu, Feb 11, 2021 at 12:48:16AM +0530, karthek wrote: > > check this out > > Why ask us again when you already sent a patch? Do you see any other > developers doing that on the mailing lists? > > thanks, > > greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: remove obsolete commented out code
Should i send them as patch series?
On Thu, Feb 11, 2021 at 1:27 PM Dan Carpenter wrote:
>
> On Thu, Feb 11, 2021 at 12:40:41AM +0530, karthik alapati wrote:
> > @@ -867,10 +845,8 @@ static void PHY_HandleSwChnlAndSetBW8723B(
> > if (bSetBandWidth)
> > pHalData->bSetChnlBW = true;
> >
> > - if (!pHalData->bSetChnlBW && !pHalData->bSwChnl) {
> > - /* DBG_871X("<= PHY_HandleSwChnlAndSetBW8812: bSwChnl %d,
> > bSetChnlBW %d\n", pHalData->bSwChnl, pHalData->bSetChnlBW); */
> > + if (!pHalData->bSetChnlBW && !pHalData->bSwChnl)
> > return;
> > - }
>
> In this case, the + line is correct. Good job.
>
> >
> >
> > if (pHalData->bSwChnl) {
> > @@ -929,9 +905,7 @@ void PHY_SetSwChnlBWMode8723B(
> > u8 Offset80
> > )
> > {
> > - /* DBG_871X("%s() ===>\n", __func__); */
> >
> > PHY_HandleSwChnlAndSetBW8723B(Adapter, true, true, channel,
> > Bandwidth, Offset40, Offset80, channel);
> >
> > - /* DBG_871X("<==%s()\n", __func__); */
>
> Please delete the blank lines as well.
>
> regards,
> dan carpenter
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [greybus-dev] [PATCH 1/1] staging: greybus: Added do - while in multi statement macro
On 11-02-21, 11:00, Greg KH wrote: > On Thu, Feb 11, 2021 at 03:24:44PM +0530, Hemansh Agnihotri wrote: > > This patch add fixes an checkpatch error for "Macros with multiple > > statements > > should be enclosed in a do - while loop" > > > > Signed-off-by: Hemansh Agnihotri > > Any reason you didn't test-build your patch before sending it out? > > That's a bit rude to reviewers :( I also wonder how two people stumbled upon the exact same thing at the same time. Copy/paste ? https://lore.kernel.org/lkml/20210210221439.3489-2-yildirim.fa...@gmail.com/ And of course NAK for the patch. The macro is used outside of any other routine, and is actually used to create routines. No do-while required here. -- viresh ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: fix function comments to follow kernel-doc
On Thu, Feb 11, 2021 at 12:48:16AM +0530, karthek wrote: > check this out Why ask us again when you already sent a patch? Do you see any other developers doing that on the mailing lists? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH -next] staging: ks7010: Macros with complex values
On Thu, Feb 11, 2021 at 12:22:39PM +0300, Fatih Yildirim wrote:
> Fix for checkpatch.pl warning:
> Macros with complex values should be enclosed in parentheses.
>
> Signed-off-by: Fatih Yildirim
> ---
> drivers/staging/ks7010/ks_hostif.h | 24
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/staging/ks7010/ks_hostif.h
> b/drivers/staging/ks7010/ks_hostif.h
> index 39138191a556..c62a494ed6bb 100644
> --- a/drivers/staging/ks7010/ks_hostif.h
> +++ b/drivers/staging/ks7010/ks_hostif.h
> @@ -498,20 +498,20 @@ struct hostif_mic_failure_request {
> #define TX_RATE_FIXED5
>
> /* 11b rate */
> -#define TX_RATE_1M (u8)(10 / 5)/* 11b 11g basic rate */
> -#define TX_RATE_2M (u8)(20 / 5)/* 11b 11g basic rate */
> -#define TX_RATE_5M (u8)(55 / 5)/* 11g basic rate */
> -#define TX_RATE_11M (u8)(110 / 5) /* 11g basic rate */
> +#define TX_RATE_1M ((u8)(10 / 5)) /* 11b 11g basic rate */
> +#define TX_RATE_2M ((u8)(20 / 5)) /* 11b 11g basic rate */
> +#define TX_RATE_5M ((u8)(55 / 5)) /* 11g basic rate */
> +#define TX_RATE_11M ((u8)(110 / 5)) /* 11g basic rate */
But these are not "complex macros" that need an extra () added to them,
right?
Checkpatch is a hint, it's not a code parser and can not always know
what is happening. With your knowledge of C, does this look like
something that needs to be "fixed"?
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging: greybus: Added do - while in multi statement macro
On Thu, Feb 11, 2021 at 03:24:44PM +0530, Hemansh Agnihotri wrote: > This patch add fixes an checkpatch error for "Macros with multiple statements > should be enclosed in a do - while loop" > > Signed-off-by: Hemansh Agnihotri Any reason you didn't test-build your patch before sending it out? That's a bit rude to reviewers :( Please always do that. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/1] staging: greybus: Added do - while in multi statement macro
This patch add fixes an checkpatch error for "Macros with multiple statements
should be enclosed in a do - while loop"
Signed-off-by: Hemansh Agnihotri
---
drivers/staging/greybus/loopback.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/greybus/loopback.c
b/drivers/staging/greybus/loopback.c
index 2471448ba42a..6dd95d648999 100644
--- a/drivers/staging/greybus/loopback.c
+++ b/drivers/staging/greybus/loopback.c
@@ -162,10 +162,11 @@ static ssize_t name##_avg_show(struct device *dev,
\
} \
static DEVICE_ATTR_RO(name##_avg)
-#define gb_loopback_stats_attrs(field) \
+#define gb_loopback_stats_attrs(field) do { \
gb_loopback_ro_stats_attr(field, min, u); \
gb_loopback_ro_stats_attr(field, max, u); \
- gb_loopback_ro_avg_attr(field)
+ gb_loopback_ro_avg_attr(field); \
+ } while (0)
#define gb_loopback_attr(field, type) \
static ssize_t field##_show(struct device *dev,
\
--
2.30.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH -next] staging: ks7010: Macros with complex values
Fix for checkpatch.pl warning:
Macros with complex values should be enclosed in parentheses.
Signed-off-by: Fatih Yildirim
---
drivers/staging/ks7010/ks_hostif.h | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/ks7010/ks_hostif.h
b/drivers/staging/ks7010/ks_hostif.h
index 39138191a556..c62a494ed6bb 100644
--- a/drivers/staging/ks7010/ks_hostif.h
+++ b/drivers/staging/ks7010/ks_hostif.h
@@ -498,20 +498,20 @@ struct hostif_mic_failure_request {
#define TX_RATE_FIXED 5
/* 11b rate */
-#define TX_RATE_1M (u8)(10 / 5)/* 11b 11g basic rate */
-#define TX_RATE_2M (u8)(20 / 5)/* 11b 11g basic rate */
-#define TX_RATE_5M (u8)(55 / 5)/* 11g basic rate */
-#define TX_RATE_11M(u8)(110 / 5) /* 11g basic rate */
+#define TX_RATE_1M ((u8)(10 / 5)) /* 11b 11g basic rate */
+#define TX_RATE_2M ((u8)(20 / 5)) /* 11b 11g basic rate */
+#define TX_RATE_5M ((u8)(55 / 5)) /* 11g basic rate */
+#define TX_RATE_11M((u8)(110 / 5)) /* 11g basic rate */
/* 11g rate */
-#define TX_RATE_6M (u8)(60 / 5)/* 11g basic rate */
-#define TX_RATE_12M(u8)(120 / 5) /* 11g basic rate */
-#define TX_RATE_24M(u8)(240 / 5) /* 11g basic rate */
-#define TX_RATE_9M (u8)(90 / 5)
-#define TX_RATE_18M(u8)(180 / 5)
-#define TX_RATE_36M(u8)(360 / 5)
-#define TX_RATE_48M(u8)(480 / 5)
-#define TX_RATE_54M(u8)(540 / 5)
+#define TX_RATE_6M ((u8)(60 / 5)) /* 11g basic rate */
+#define TX_RATE_12M((u8)(120 / 5)) /* 11g basic rate */
+#define TX_RATE_24M((u8)(240 / 5)) /* 11g basic rate */
+#define TX_RATE_9M ((u8)(90 / 5))
+#define TX_RATE_18M((u8)(180 / 5))
+#define TX_RATE_36M((u8)(360 / 5))
+#define TX_RATE_48M((u8)(480 / 5))
+#define TX_RATE_54M((u8)(540 / 5))
static inline bool is_11b_rate(u8 rate)
{
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
