[PATCH] staging: unisys: visornic: Fix repeated words in comments
This patch removes some repeated words in code comments. Signed-off-by: Klemen Košir --- drivers/staging/unisys/visornic/visornic_main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/unisys/visornic/visornic_main.c b/drivers/staging/unisys/visornic/visornic_main.c index 0433536930a9..13e72fbe7bb1 100644 --- a/drivers/staging/unisys/visornic/visornic_main.c +++ b/drivers/staging/unisys/visornic/visornic_main.c @@ -534,7 +534,7 @@ static int visornic_disable_with_timeout(struct net_device *netdev, return err; /* wait for ack to arrive before we try to free rcv buffers -* NOTE: the other end automatically unposts the rcv buffers when +* NOTE: the other end automatically unposts the rcv buffers * when it gets a disable. */ spin_lock_irqsave(&devdata->priv_lock, flags); @@ -1750,7 +1750,7 @@ static int visornic_poll(struct napi_struct *napi, int budget) } /* poll_for_irq- checks the status of the response queue - * @t: pointer to the 'struct timer_list' from which we can retrieve the + * @t: pointer to the 'struct timer_list' from which we can retrieve * the visornic devdata struct. * * Main function of the vnic_incoming thread. Periodically check the response -- 2.29.2 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 0/5] Reset driver for IMX8MQ VPU hardware block
Hi Benjamin, On Mon, 2021-03-01 at 16:17 +0100, Benjamin Gaignard wrote: > The two VPUs inside IMX8MQ share the same control block which can be see > as a reset hardware block. This isn't a reset controller though. The control block also contains clock gates of some sort and a filter register for the featureset fuses. Those shouldn't be manipulated via the reset API. > 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. Why not switch to a syscon regmap for the control block? That should also allow to keep backwards compatibility with the old binding with minimal effort. > Please note that this series break the compatibility between the DTB and > kernel. This break is limited to IMX8MQ SoC and is done when the driver > is still in staging directory. I know in this case we are pretty sure there are no users of this binding except for a staging driver, but it would still be nice to keep support for the deprecated binding, to avoid the requirement of updating kernel and DT in lock-step. regards Philipp ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 3/5] reset: Add reset driver for IMX8MQ VPU block
On Mon, 2021-03-01 at 16:17 +0100, Benjamin Gaignard wrote:
> 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_RESET 0x00
> +#define RESET_G1 ((u32)BIT(1))
> +#define RESET_G2 ((u32)BIT(0))
> +
> +#define CTRL_ENABLE 0x04
> +#define ENABLE_G1BIT(1)
> +#define ENABLE_G2BIT(0)
> +
> +#define CTRL_G1_DEC_FUSE 0x08
> +#define CTRL_G1_PP_FUSE 0x0c
> +#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);
This doesn't belong in reset_assert.
> + 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);
Same as above, this doesn't belong in reset_assert.
> + clk_bulk_disable_unprepare(reset->num_clocks, reset->clocks);
Also I assume that only the VPU_DEC_ROOT clock is required to control
these registers. Enabling the VPU_G1_ROOT and VPU_G2_ROOT clocks
(presumably to make sure the resets propagate into the respective VPU
core) would be the reset consumer's responsibility.
regards
Philipp
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 4/5] media: hantro: Use reset driver
On Mon, 2021-03-01 at 16:17 +0100, Benjamin Gaignard wrote:
> 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_RESET 0x00
> -#define RESET_G1 BIT(1)
> -#define RESET_G2 BIT(0)
> -
> -#define CTRL_CLOCK_ENABLE0x04
> -#define CLOCK_G1 BIT(1)
> -#define CLOCK_G2 BIT(0)
> -
> -#define CTRL_G1_DEC_FUSE 0x08
> -#define CTRL_G1_PP_FUSE 0x0c
> -#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);
The way it is implemented in the reset driver, the clocks are now
ungated between assert and deassert instead of afterwards. Is this on
purpose?
regards
Philipp
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 4/5] media: hantro: Use reset driver
Le 03/03/2021 à 15:39, Philipp Zabel a écrit :
On Mon, 2021-03-01 at 16:17 +0100, Benjamin Gaignard wrote:
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_RESET 0x00
-#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);
The way it is implemented in the reset driver, the clocks are now
ungated between assert and deassert instead of afterwards. Is this on
purpose?
No and that could be changed on next version.
Benjamin
regards
Philipp
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 0/5] Reset driver for IMX8MQ VPU hardware block
Le 03/03/2021 à 15:17, Philipp Zabel a écrit : Hi Benjamin, On Mon, 2021-03-01 at 16:17 +0100, Benjamin Gaignard wrote: The two VPUs inside IMX8MQ share the same control block which can be see as a reset hardware block. This isn't a reset controller though. The control block also contains clock gates of some sort and a filter register for the featureset fuses. Those shouldn't be manipulated via the reset API. They are all part of the control block and of the reset process for this hardware that why I put them here. I guess it is border line :-) 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. Why not switch to a syscon regmap for the control block? That should also allow to keep backwards compatibility with the old binding with minimal effort. I will give a try in this direction. Please note that this series break the compatibility between the DTB and kernel. This break is limited to IMX8MQ SoC and is done when the driver is still in staging directory. I know in this case we are pretty sure there are no users of this binding except for a staging driver, but it would still be nice to keep support for the deprecated binding, to avoid the requirement of updating kernel and DT in lock-step. If I want to use a syscon (or a reset) the driver must not ioremap the "ctrl" registers. It means that "ctrl" has to be removed from the driver requested reg-names (imx8mq_reg_names[]). Doing that break the kernel/DT compatibility. Somehow syscon and "ctrl" are exclusive. Benjamin regards Philipp ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 0/5] Reset driver for IMX8MQ VPU hardware block
On Wed, 2021-03-03 at 16:20 +0100, Benjamin Gaignard wrote: > Le 03/03/2021 à 15:17, Philipp Zabel a écrit : > > Hi Benjamin, > > > > On Mon, 2021-03-01 at 16:17 +0100, Benjamin Gaignard wrote: > > > The two VPUs inside IMX8MQ share the same control block which can be see > > > as a reset hardware block. > > This isn't a reset controller though. The control block also contains > > clock gates of some sort and a filter register for the featureset fuses. > > Those shouldn't be manipulated via the reset API. > > They are all part of the control block and of the reset process for this > hardware that why I put them here. I guess it is border line :-) I'm pushing back to keep the reset control framework focused on controlling reset lines. Every side effect (such as the asymmetric clock ungating) in a random driver makes it harder to reason about behaviour at the API level, and to review patches for hardware I am not familiar with. > > > 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. > > Why not switch to a syscon regmap for the control block? That should > > also allow to keep backwards compatibility with the old binding with > > minimal effort. > > I will give a try in this direction. Thank you. > > > Please note that this series break the compatibility between the DTB and > > > kernel. This break is limited to IMX8MQ SoC and is done when the driver > > > is still in staging directory. > > I know in this case we are pretty sure there are no users of this > > binding except for a staging driver, but it would still be nice to keep > > support for the deprecated binding, to avoid the requirement of updating > > kernel and DT in lock-step. > > If I want to use a syscon (or a reset) the driver must not ioremap the "ctrl" > registers. It means that "ctrl" has to be removed from the driver requested > reg-names (imx8mq_reg_names[]). Doing that break the kernel/DT compatibility. > Somehow syscon and "ctrl" are exclusive. The way the driver is set up currently, yes. You could add a bit of platform specific probe code, though, that would set up the regmap either by calling syscon_regmap_lookup_by_phandle(); for the new binding, or, if the phandle is not available, fall back to platform_get_resource_byname(..., "ctrl"); devm_ioremap_resource(); devm_regmap_init_mmio(); for the old binding. The actual codec .reset and variant .runtime_resume ops could be identical then. regards Philipp ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH][next] staging: rtl8188eu: Replace one-element array with flexible-array in struct ndis_802_11_var_ie
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].
Use flexible-array member in struct ndis_802_11_var_ie, instead of
one-element array.
Also, this helps with the ongoing efforts to enable -Warray-bounds by
fixing the following warning:
drivers/staging/rtl8188eu/core/rtw_wlan_util.c: In function ‘HT_caps_handler’:
drivers/staging/rtl8188eu/core/rtw_wlan_util.c:665:65: warning: array subscript
2 is above array bounds of ‘u8[1]’ {aka ‘unsigned char[1]’} [-Warray-bounds]
665 |if ((pmlmeinfo->HT_caps.ampdu_params_info & 0x3) > (pIE->data[i] &
0x3))
|~^~~
[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
Signed-off-by: Gustavo A. R. Silva
---
drivers/staging/rtl8188eu/include/wlan_bssdef.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/include/wlan_bssdef.h
b/drivers/staging/rtl8188eu/include/wlan_bssdef.h
index 2c184ce8746b..350bbf9057b8 100644
--- a/drivers/staging/rtl8188eu/include/wlan_bssdef.h
+++ b/drivers/staging/rtl8188eu/include/wlan_bssdef.h
@@ -64,7 +64,7 @@ struct ndis_802_11_fixed_ie {
struct ndis_802_11_var_ie {
u8 ElementID;
u8 Length;
- u8 data[1];
+ u8 data[];
};
/*
--
2.27.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Investment Partner Required.
My name is Reem Hashimy, the Emirates Minister of State and Managing Director of the United Arab Emirates (Dubai) World Expo 2020 Committee which has been postponed to October 2021 to March 2022 because of the Covid-19 pandemic. I am writing to you to manage the funds I received as financial gratification from various foreign companies I assisted to receive a participation approval to the coming event. The amount is $44,762,906.00 United States dollars. But I can not personally manage the fund in my country because of the sensitive nature of my office and the certain restriction on married Muslim women. For this reason, an agreement was reached with a consulting firm to direct the various financial gifts into an open beneficiary account in my name with a bank where it will be possible for me to instruct the transfer of ownership right to a third party for investment purpose; which is the reason I am contacting you to receive the fund and manage it as my investment partner. Note that the fund is NOT connected to any criminal or terrorist activity. On your indication of interest with your information to include your nahme, your phone number and contact mailing address; I will instruct the consulting firm to process the fund from the bank to your country for investment purposes. Regards. Reem Hashimy. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
