Re: [PATCH RT 1/2] tasklet: Address a race resulting in double-enqueue
On Tue, Jun 9, 2020 at 8:20 PM Tom Zanussi wrote:
>
> Hi Ramon,
>
> On Tue, 2020-06-09 at 20:14 +0300, Ramon Fried wrote:
> >
> > On June 9, 2020 8:10:43 PM GMT+03:00, Sebastian Andrzej Siewior <
> > bige...@linutronix.de> wrote:
> > > On 2020-06-09 20:07:06 [+0300], Ramon Fried wrote:
> > > > Indeed
> > > > I'm truly sorry, I thought our crash kernel is configured as RT
> > > > as
> > >
> > > well.
> > > > so, as I understand, if I build the RT kernel without preempt
> > > > enabled
> > >
> > > I can hit this bug?
> > >
> > > Don't worry, I should have been better with the details in the log.
> > >
> > > So you should _always_ hit the warning/bug if you compile a kernel
> > > without SMP and RT. If you enable one of these then everything
> > > should
> > > be
> > > fine.
> >
> > Would there be a fix for that?
>
> I haven't tested the fix yet, but can you try the below patch and see
> if it fixes your broken case?
>
> [PATCH] tasklet: Fix UP case for tasklet CHAINED state
>
> commit 62d0a2a30cd0 (tasklet: Address a race resulting in
> double-enqueue) addresses a problem that can result in a tasklet being
> enqueued on two cpus at the same time by combining the RUN flag with a
> new CHAINED flag, and relies on the combination to be present in order
> to zero it out, which can never happen on (!SMP and !PREEMPT_RT_FULL)
> because the RUN flag is SMP/PREEMPT_RT_FULL-only.
>
> So make sure the above commit is only applied for the SMP ||
> PREEMPT_RT_FULL case.
>
> Signed-off-by: Tom Zanussi
> ---
> kernel/softirq.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/kernel/softirq.c b/kernel/softirq.c
> index 73dae64bfc9c..9bad7a16dc61 100644
> --- a/kernel/softirq.c
> +++ b/kernel/softirq.c
> @@ -947,10 +947,12 @@ static void __tasklet_schedule_common(struct
> tasklet_struct *t,
> * is locked before adding it to the list.
> */
> if (test_bit(TASKLET_STATE_SCHED, >state)) {
> +#if defined(CONFIG_SMP) || defined(CONFIG_PREEMPT_RT_FULL)
> if (test_and_set_bit(TASKLET_STATE_CHAINED, >state))
> {
> tasklet_unlock(t);
> return;
> }
> +#endif
> t->next = NULL;
> *head->tail = t;
> head->tail = &(t->next);
> @@ -1044,7 +1046,11 @@ static void tasklet_action_common(struct
> softirq_action *a,
> again:
> t->func(t->data);
>
> +#if defined(CONFIG_SMP) || defined(CONFIG_PREEMPT_RT_FULL)
> while (cmpxchg(>state, TASKLET_STATEF_RC, 0) !=
> TASKLET_STATEF_RC) {
> +#else
> + while (!tasklet_tryunlock(t)) {
> +#endif
> /*
> * If it got disabled meanwhile, bail out:
> */
> --
> 2.17.1
>
>
Tested-By: Ramon Fried
Working, thanks a lot.
Re: [PATCH RT 1/2] tasklet: Address a race resulting in double-enqueue
On June 9, 2020 8:10:43 PM GMT+03:00, Sebastian Andrzej Siewior wrote: >On 2020-06-09 20:07:06 [+0300], Ramon Fried wrote: >> Indeed >> I'm truly sorry, I thought our crash kernel is configured as RT as >well. >> so, as I understand, if I build the RT kernel without preempt enabled >I can hit this bug? > >Don't worry, I should have been better with the details in the log. > >So you should _always_ hit the warning/bug if you compile a kernel >without SMP and RT. If you enable one of these then everything should >be >fine. Would there be a fix for that? > >Sebastian -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [PATCH RT 1/2] tasklet: Address a race resulting in double-enqueue
On June 9, 2020 7:42:13 PM GMT+03:00, Sebastian Andrzej Siewior wrote: >On 2020-06-09 19:40:03 [+0300], Ramon Fried wrote: >> Correction. normal kernel is running with RT enabled, crash kernel >without. > >no RT and no SMP in your crash kernel? So this information in your >first >email would have saved me some time… Indeed I'm truly sorry, I thought our crash kernel is configured as RT as well. so, as I understand, if I build the RT kernel without preempt enabled I can hit this bug? > >Sebastian -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [PATCH RT 1/2] tasklet: Address a race resulting in double-enqueue
On June 9, 2020 7:37:31 PM GMT+03:00, Ramon Fried wrote:
>
>
>On June 9, 2020 7:34:46 PM GMT+03:00, Sebastian Andrzej Siewior
> wrote:
>>On 2020-06-09 11:17:53 [-0500], Tom Zanussi wrote:
>>> Hi Sebastian,
>>Hi Tom,
>>
>>> I did find a problem with the patch when configured as !SMP since in
>>> that case the RUN flag is never set (will send a patch for that
>>> shortly), but that wouldn't be the case here.
>>
>>How?
>>
>>| #if defined(CONFIG_SMP) || defined(CONFIG_PREEMPT_RT_FULL)
>>| static inline int tasklet_trylock(struct tasklet_struct *t)
>>| {
>>| return !test_and_set_bit(TASKLET_STATE_RUN, &(t)->state);
>>| }
>>
>>I can't tell from the backtrace if he runs with RT or without but I
>>assumed RT. But yes, for !SMP && !RT it would explain it.
>PREEMT_FULL is enabled.
>I'm working on getting symbols for this trace, this is a crash kernel
>so everything is stripped naked.
>Thanks, Ramon
Correction. normal kernel is running with RT enabled, crash kernel without.
>>
>>> It would help to be able to reproduce it, but I haven't been able to
>>> yet.
>>>
>>> Tom
>>>
>>Sebastian
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [PATCH RT 1/2] tasklet: Address a race resulting in double-enqueue
On June 9, 2020 7:34:46 PM GMT+03:00, Sebastian Andrzej Siewior
wrote:
>On 2020-06-09 11:17:53 [-0500], Tom Zanussi wrote:
>> Hi Sebastian,
>Hi Tom,
>
>> I did find a problem with the patch when configured as !SMP since in
>> that case the RUN flag is never set (will send a patch for that
>> shortly), but that wouldn't be the case here.
>
>How?
>
>| #if defined(CONFIG_SMP) || defined(CONFIG_PREEMPT_RT_FULL)
>| static inline int tasklet_trylock(struct tasklet_struct *t)
>| {
>| return !test_and_set_bit(TASKLET_STATE_RUN, &(t)->state);
>| }
>
>I can't tell from the backtrace if he runs with RT or without but I
>assumed RT. But yes, for !SMP && !RT it would explain it.
PREEMT_FULL is enabled.
I'm working on getting symbols for this trace, this is a crash kernel so
everything is stripped naked.
Thanks, Ramon
>
>> It would help to be able to reproduce it, but I haven't been able to
>> yet.
>>
>> Tom
>>
>Sebastian
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [PATCH RT 1/2] tasklet: Address a race resulting in double-enqueue
On Thu, Apr 23, 2020 at 11:55 PM wrote:
>
> From: Zhang Xiao
>
> v4.19.115-rt49-rc1 stable review patch.
> If anyone has any objections, please let me know.
>
> ---
>
>
> The kernel bugzilla has the following race condition reported:
>
> CPU0CPU1CPU2
>
> test_set SCHED
> test_set RUN
>if SCHED
> add_list
> raise
> clear RUN
>
> test_set RUN
> test_clear SCHED
> ->func
> test_set SCHED
> tasklet_try_unlock ->0
> test_clear SCHED
> test_set SCHED
> ->func
> tasklet_try_unlock ->1
> test_set RUN
> if SCHED
> add list
> raise
> clear RUN
> test_set RUN
> if SCHED
> add list
> raise
> clear RUN
>
> As a result the tasklet is enqueued on both CPUs and run on both CPUs. Due
> to the nature of the list used here, it is possible that further
> (different) tasklets, which are enqueued after this double-enqueued
> tasklet, are scheduled on CPU2 but invoked on CPU1. It is also possible
> that these tasklets won't be invoked at all, because during the second
> enqueue process the t->next pointer is set to NULL - dropping everything
> from the list.
>
> This race will trigger one or two of the WARN_ON() in
> tasklet_action_common().
> The problem is that the tasklet may be invoked multiple times and clear
> SCHED bit on each invocation. This makes it possible to enqueue the
> very same tasklet on different CPUs.
>
> Current RT-devel is using the upstream implementation which does not
> re-run tasklets if they have SCHED set again and so it does not clear
> the SCHED bit multiple times on a single invocation.
>
> Introduce the CHAINED flag. The tasklet will only be enqueued if the
> CHAINED flag has been set successfully.
> If it is possible to exchange the flags (CHAINED | RUN) -> 0 then the
> tasklet won't be re-run. Otherwise the possible SCHED flag is removed
> and the tasklet is re-run again.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=61451
> Not-signed-off-by: Zhang Xiao
> [bigeasy: patch description]
> Signed-off-by: Sebastian Andrzej Siewior
>
> Signed-off-by: Tom Zanussi
> ---
> include/linux/interrupt.h | 5 -
> kernel/softirq.c | 6 +-
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
> index 97d9ba26915e..a3b5edb26bc5 100644
> --- a/include/linux/interrupt.h
> +++ b/include/linux/interrupt.h
> @@ -579,12 +579,15 @@ enum
> {
> TASKLET_STATE_SCHED,/* Tasklet is scheduled for execution */
> TASKLET_STATE_RUN, /* Tasklet is running (SMP only) */
> - TASKLET_STATE_PENDING /* Tasklet is pending */
> + TASKLET_STATE_PENDING, /* Tasklet is pending */
> + TASKLET_STATE_CHAINED /* Tasklet is chained */
> };
>
> #define TASKLET_STATEF_SCHED (1 << TASKLET_STATE_SCHED)
> #define TASKLET_STATEF_RUN (1 << TASKLET_STATE_RUN)
> #define TASKLET_STATEF_PENDING (1 << TASKLET_STATE_PENDING)
> +#define TASKLET_STATEF_CHAINED (1 << TASKLET_STATE_CHAINED)
> +#define TASKLET_STATEF_RC (TASKLET_STATEF_RUN | TASKLET_STATEF_CHAINED)
>
> #if defined(CONFIG_SMP) || defined(CONFIG_PREEMPT_RT_FULL)
> static inline int tasklet_trylock(struct tasklet_struct *t)
> diff --git a/kernel/softirq.c b/kernel/softirq.c
> index 25bcf2f2714b..73dae64bfc9c 100644
> --- a/kernel/softirq.c
> +++ b/kernel/softirq.c
> @@ -947,6 +947,10 @@ static void __tasklet_schedule_common(struct
> tasklet_struct *t,
> * is locked before adding it to the list.
> */
> if (test_bit(TASKLET_STATE_SCHED, >state)) {
> + if (test_and_set_bit(TASKLET_STATE_CHAINED, >state)) {
> + tasklet_unlock(t);
> + return;
> + }
> t->next = NULL;
> *head->tail = t;
> head->tail = &(t->next);
> @@ -1040,7 +1044,7 @@ static void tasklet_action_common(struct softirq_action
> *a,
> again:
> t->func(t->data);
>
> - while (!tasklet_tryunlock(t)) {
> + while (cmpxchg(>state, TASKLET_STATEF_RC, 0) !=
> TASKLET_STATEF_RC) {
> /*
> * If it got disabled meanwhile, bail out:
> */
> --
> 2.17.1
>
Hi, This patch introduced a regression in our kernel
(v4.19.124-rt53-rebase), It occurs when we're jumping to crush kernel
using kexec, in the initialization of the emmc driver.
I'm still debugging the root cause, but I thought of mentioning this
in the mailing list if you have any idea
[PATCH v3] gpiolib: Take MUX usage into account
From: Stefan Wahren
The user space like gpioinfo only see the GPIO usage but not the
MUX usage (e.g. I2C or SPI usage) of a pin. As a user we want to know which
pin is free/safe to use. So take the MUX usage of strict pinmux controllers
into account to get a more realistic view for ioctl GPIO_GET_LINEINFO_IOCTL.
Signed-off-by: Stefan Wahren
Tested-by: Ramon Fried
Signed-off-by: Ramon Fried
---
v3:
* Remove the debug message and replace with comment in code.
v2: Address review from linus:
* ** Please notive logic was reversed **
* renamed pinctrl_gpio_is_in_use() to pinctrl_gpio_can_use_line()
* renamed pinmux_is_in_use() to pinmux_can_be_used_for_gpio()
* changed dev_err to dev_dbg (Linus suggested removing it altogether, I
find it better to keep it for debug).
drivers/gpio/gpiolib.c | 3 ++-
drivers/pinctrl/core.c | 28
drivers/pinctrl/pinmux.c | 24
drivers/pinctrl/pinmux.h | 8
include/linux/pinctrl/consumer.h | 6 ++
5 files changed, 68 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index f497003f119c..52937bf8e514 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1084,7 +1084,8 @@ static long gpio_ioctl(struct file *filp, unsigned int
cmd, unsigned long arg)
test_bit(FLAG_IS_HOGGED, >flags) ||
test_bit(FLAG_USED_AS_IRQ, >flags) ||
test_bit(FLAG_EXPORT, >flags) ||
- test_bit(FLAG_SYSFS, >flags))
+ test_bit(FLAG_SYSFS, >flags) ||
+ !pinctrl_gpio_can_use_line(chip->base +
lineinfo.line_offset))
lineinfo.flags |= GPIOLINE_FLAG_KERNEL;
if (test_bit(FLAG_IS_OUT, >flags))
lineinfo.flags |= GPIOLINE_FLAG_IS_OUT;
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index b70df27874d1..2bbd8ee93507 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -736,6 +736,34 @@ int pinctrl_get_group_selector(struct pinctrl_dev *pctldev,
return -EINVAL;
}
+bool pinctrl_gpio_can_use_line(unsigned gpio)
+{
+ struct pinctrl_dev *pctldev;
+ struct pinctrl_gpio_range *range;
+ bool result;
+ int pin;
+
+ /*
+* Try to obtain GPIO range, if it fails
+* we're probably dealing with GPIO driver
+* without a backing pin controller - bail out.
+*/
+ if (pinctrl_get_device_gpio_range(gpio, , ))
+ return true;
+
+ mutex_lock(>mutex);
+
+ /* Convert to the pin controllers number space */
+ pin = gpio_to_pin(range, gpio);
+
+ result = pinmux_can_be_used_for_gpio(pctldev, pin);
+
+ mutex_unlock(>mutex);
+
+ return result;
+}
+EXPORT_SYMBOL_GPL(pinctrl_gpio_can_use_line);
+
/**
* pinctrl_gpio_request() - request a single pin to be used as GPIO
* @gpio: the GPIO pin number from the GPIO subsystem number space
diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index 020e54f843f9..e914f6efd39e 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -70,6 +70,30 @@ int pinmux_validate_map(const struct pinctrl_map *map, int i)
return 0;
}
+/**
+ * pinmux_can_be_used_for_gpio() - check if a specific pin
+ * is either muxed to a different function or used as gpio.
+ *
+ * @pin: the pin number in the global pin space
+ *
+ * Controllers not defined as strict will always return true,
+ * menaning that the gpio can be used.
+ */
+bool pinmux_can_be_used_for_gpio(struct pinctrl_dev *pctldev, unsigned pin)
+{
+ struct pin_desc *desc = pin_desc_get(pctldev, pin);
+ const struct pinmux_ops *ops = pctldev->desc->pmxops;
+
+ /* Can't inspect pin, assume it can be used */
+ if (!desc)
+ return true;
+
+ if (ops->strict && desc->mux_usecount)
+ return false;
+
+ return !(ops->strict && !!desc->gpio_owner);
+}
+
/**
* pin_request() - request a single pin to be muxed in, typically for GPIO
* @pin: the pin number in the global pin space
diff --git a/drivers/pinctrl/pinmux.h b/drivers/pinctrl/pinmux.h
index 794cb3a003ff..78c3a31be882 100644
--- a/drivers/pinctrl/pinmux.h
+++ b/drivers/pinctrl/pinmux.h
@@ -15,6 +15,8 @@ int pinmux_check_ops(struct pinctrl_dev *pctldev);
int pinmux_validate_map(const struct pinctrl_map *map, int i);
+bool pinmux_can_be_used_for_gpio(struct pinctrl_dev *pctldev, unsigned pin);
+
int pinmux_request_gpio(struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *range,
unsigned pin, unsigned gpio);
@@ -42,6 +44,12 @@ static inline int pinmux_validate_map(const struct
pinctrl_map *map, int i)
return 0;
}
+static inline bool pinmux_can_be_used_for_gpio(struct pinctrl_dev *pctldev
Re: [PATCH v2] gpiolib: Take MUX usage into account
On Tue, 2019-08-13 at 18:32 +0200, Stefan Wahren wrote:
> Am 13.08.19 um 08:10 schrieb Fried, Ramon:
> > On 8/13/2019 08:38, Stefan Wahren wrote:
> > > Hi Ramon,
> > >
> > > On 13.08.19 03:42, Ramon Fried wrote:
> > > > From: Stefan Wahren
> > > >
> > > > The user space like gpioinfo only see the GPIO usage but not
> > > > the
> > > > MUX usage (e.g. I2C or SPI usage) of a pin. As a user we want
> > > > to
> > > > know which
> > > > pin is free/safe to use. So take the MUX usage of strict pinmux
> > > > controllers
> > > > into account to get a more realistic view for ioctl
> > > > GPIO_GET_LINEINFO_IOCTL.
> > > >
> > > > Signed-off-by: Stefan Wahren
> > > > Tested-by: Ramon Fried
> > > > Signed-off-by: Ramon Fried
> > > > ---
> > > > v2: Address review from linus:
> > > > * ** Please notive logic was reversed **
> > > > * renamed pinctrl_gpio_is_in_use() to
> > > > pinctrl_gpio_can_use_line()
> > > > * renamed pinmux_is_in_use() to pinmux_can_be_used_for_gpio()
> > > > * changed dev_err to dev_dbg (Linus suggested removing it
> > > > altogether, I
> > > >find it better to keep it for debug).
> > > thanks for taking care of this.
> > > > drivers/gpio/gpiolib.c | 3 ++-
> > > > drivers/pinctrl/core.c | 28
> > > >
> > > > drivers/pinctrl/pinmux.c | 27
> > > > +++
> > > > drivers/pinctrl/pinmux.h | 8
> > > > include/linux/pinctrl/consumer.h | 6 ++
> > > > 5 files changed, 71 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> > > > index f497003f119c..52937bf8e514 100644
> > > > --- a/drivers/gpio/gpiolib.c
> > > > +++ b/drivers/gpio/gpiolib.c
> > > > @@ -1084,7 +1084,8 @@ static long gpio_ioctl(struct file *filp,
> > > > unsigned int cmd, unsigned long arg)
> > > > test_bit(FLAG_IS_HOGGED, >flags) ||
> > > > test_bit(FLAG_USED_AS_IRQ, >flags) ||
> > > > test_bit(FLAG_EXPORT, >flags) ||
> > > > -test_bit(FLAG_SYSFS, >flags))
> > > > +test_bit(FLAG_SYSFS, >flags) ||
> > > > +!pinctrl_gpio_can_use_line(chip->base +
> > > > lineinfo.line_offset))
> > > > lineinfo.flags |= GPIOLINE_FLAG_KERNEL;
> > > > if (test_bit(FLAG_IS_OUT, >flags))
> > > > lineinfo.flags |= GPIOLINE_FLAG_IS_OUT;
> > > > diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
> > > > index b70df27874d1..2bbd8ee93507 100644
> > > > --- a/drivers/pinctrl/core.c
> > > > +++ b/drivers/pinctrl/core.c
> > > > @@ -736,6 +736,34 @@ int pinctrl_get_group_selector(struct
> > > > pinctrl_dev *pctldev,
> > > > return -EINVAL;
> > > > }
> > > > +bool pinctrl_gpio_can_use_line(unsigned gpio)
> > > > +{
> > > > +struct pinctrl_dev *pctldev;
> > > > +struct pinctrl_gpio_range *range;
> > > > +bool result;
> > > > +int pin;
> > > > +
> > > > +/*
> > > > + * Try to obtain GPIO range, if it fails
> > > > + * we're probably dealing with GPIO driver
> > > > + * without a backing pin controller - bail out.
> > > > + */
> > > > +if (pinctrl_get_device_gpio_range(gpio, , ))
> > > > +return true;
> > > > +
> > > > +mutex_lock(>mutex);
> > > > +
> > > > +/* Convert to the pin controllers number space */
> > > > +pin = gpio_to_pin(range, gpio);
> > > > +
> > > > +result = pinmux_can_be_used_for_gpio(pctldev, pin);
> > > > +
> > > > +mutex_unlock(>mutex);
> > > > +
> > > > +return result;
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(pinctrl_gpio_can_use_line);
> > > > +
> > > > /**
> > > >* pinctrl_gpio_request() - request a single pin to be used
> > > > as GPIO
> > > >* @gpio: the GPIO pin number from the GPIO subsystem number
> > > > space
> > >
[PATCH v2] gpiolib: Take MUX usage into account
From: Stefan Wahren
The user space like gpioinfo only see the GPIO usage but not the
MUX usage (e.g. I2C or SPI usage) of a pin. As a user we want to know which
pin is free/safe to use. So take the MUX usage of strict pinmux controllers
into account to get a more realistic view for ioctl GPIO_GET_LINEINFO_IOCTL.
Signed-off-by: Stefan Wahren
Tested-by: Ramon Fried
Signed-off-by: Ramon Fried
---
v2: Address review from linus:
* ** Please notive logic was reversed **
* renamed pinctrl_gpio_is_in_use() to pinctrl_gpio_can_use_line()
* renamed pinmux_is_in_use() to pinmux_can_be_used_for_gpio()
* changed dev_err to dev_dbg (Linus suggested removing it altogether, I
find it better to keep it for debug).
drivers/gpio/gpiolib.c | 3 ++-
drivers/pinctrl/core.c | 28
drivers/pinctrl/pinmux.c | 27 +++
drivers/pinctrl/pinmux.h | 8
include/linux/pinctrl/consumer.h | 6 ++
5 files changed, 71 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index f497003f119c..52937bf8e514 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1084,7 +1084,8 @@ static long gpio_ioctl(struct file *filp, unsigned int
cmd, unsigned long arg)
test_bit(FLAG_IS_HOGGED, >flags) ||
test_bit(FLAG_USED_AS_IRQ, >flags) ||
test_bit(FLAG_EXPORT, >flags) ||
- test_bit(FLAG_SYSFS, >flags))
+ test_bit(FLAG_SYSFS, >flags) ||
+ !pinctrl_gpio_can_use_line(chip->base +
lineinfo.line_offset))
lineinfo.flags |= GPIOLINE_FLAG_KERNEL;
if (test_bit(FLAG_IS_OUT, >flags))
lineinfo.flags |= GPIOLINE_FLAG_IS_OUT;
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index b70df27874d1..2bbd8ee93507 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -736,6 +736,34 @@ int pinctrl_get_group_selector(struct pinctrl_dev *pctldev,
return -EINVAL;
}
+bool pinctrl_gpio_can_use_line(unsigned gpio)
+{
+ struct pinctrl_dev *pctldev;
+ struct pinctrl_gpio_range *range;
+ bool result;
+ int pin;
+
+ /*
+* Try to obtain GPIO range, if it fails
+* we're probably dealing with GPIO driver
+* without a backing pin controller - bail out.
+*/
+ if (pinctrl_get_device_gpio_range(gpio, , ))
+ return true;
+
+ mutex_lock(>mutex);
+
+ /* Convert to the pin controllers number space */
+ pin = gpio_to_pin(range, gpio);
+
+ result = pinmux_can_be_used_for_gpio(pctldev, pin);
+
+ mutex_unlock(>mutex);
+
+ return result;
+}
+EXPORT_SYMBOL_GPL(pinctrl_gpio_can_use_line);
+
/**
* pinctrl_gpio_request() - request a single pin to be used as GPIO
* @gpio: the GPIO pin number from the GPIO subsystem number space
diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index 020e54f843f9..7e42a5738d82 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -70,6 +70,33 @@ int pinmux_validate_map(const struct pinctrl_map *map, int i)
return 0;
}
+/**
+ * pinmux_can_be_used_for_gpio() - check if a specific pin
+ * is either muxed to a different function or used as gpio.
+ *
+ * @pin: the pin number in the global pin space
+ *
+ * Controllers not defined as strict will always return true,
+ * menaning that the gpio can be used.
+ */
+bool pinmux_can_be_used_for_gpio(struct pinctrl_dev *pctldev, unsigned pin)
+{
+ struct pin_desc *desc = pin_desc_get(pctldev, pin);
+ const struct pinmux_ops *ops = pctldev->desc->pmxops;
+
+ if (!desc) {
+ dev_dbg(pctldev->dev,
+ "pin %u is not registered so it cannot be requested\n",
+ pin);
+ return true;
+ }
+
+ if (ops->strict && desc->mux_usecount)
+ return false;
+
+ return !(ops->strict && !!desc->gpio_owner);
+}
+
/**
* pin_request() - request a single pin to be muxed in, typically for GPIO
* @pin: the pin number in the global pin space
diff --git a/drivers/pinctrl/pinmux.h b/drivers/pinctrl/pinmux.h
index 794cb3a003ff..78c3a31be882 100644
--- a/drivers/pinctrl/pinmux.h
+++ b/drivers/pinctrl/pinmux.h
@@ -15,6 +15,8 @@ int pinmux_check_ops(struct pinctrl_dev *pctldev);
int pinmux_validate_map(const struct pinctrl_map *map, int i);
+bool pinmux_can_be_used_for_gpio(struct pinctrl_dev *pctldev, unsigned pin);
+
int pinmux_request_gpio(struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *range,
unsigned pin, unsigned gpio);
@@ -42,6 +44,12 @@ static inline int pinmux_validate_map(const struct
pinctrl_map *map, int i)
return 0;
}
+
Re: [PATCH] gpiolib: Take MUX usage into account
On August 6, 2019 4:11:27 PM GMT+03:00, Linus Walleij wrote: >On Tue, Aug 6, 2019 at 3:04 PM Linus Walleij >wrote: >> On Sat, Aug 3, 2019 at 3:34 PM Ramon Fried >wrote: >> >> > From: Stefan Wahren >> > >> > The user space like gpioinfo only see the GPIO usage but not the >> > MUX usage (e.g. I2C or SPI usage) of a pin. As a user we want to >know which >> > pin is free/safe to use. So take the MUX usage of strict pinmux >controllers >> > into account to get a more realistic view for ioctl >GPIO_GET_LINEINFO_IOCTL. >> > >> > Signed-off-by: Stefan Wahren >> > Tested-By: Ramon Fried >> > Signed-off-by: Ramon Fried >> > --- >> > Sending Stefan's RFC as patch, as I tested it and it seems to work, >> > additionally, an accompanying fix was made by me to gpiolibd to fix >a >> > display error of the actual result: >> > https://patchwork.ozlabs.org/patch/1139923/ >> >> This is mostly fine, some style nits so I fixed it up when >> applying. > >Ooops no. It needs a deeper rework in accordance to my comments >last time it was posted. Please read this reply to Stefan's patch >and address the comments: > NP, I'll try to address these in a new patch. Thanks. Ramon >https://lore.kernel.org/linux-gpio/CACRpkdb5DjAMRYkT+b0U6HVk7E6ccLT79-LB=qgqwwte17a...@mail.gmail.com/ > >Yours, >Linus Walleij -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
[PATCH] gpiolib: Take MUX usage into account
From: Stefan Wahren
The user space like gpioinfo only see the GPIO usage but not the
MUX usage (e.g. I2C or SPI usage) of a pin. As a user we want to know which
pin is free/safe to use. So take the MUX usage of strict pinmux controllers
into account to get a more realistic view for ioctl GPIO_GET_LINEINFO_IOCTL.
Signed-off-by: Stefan Wahren
Tested-By: Ramon Fried
Signed-off-by: Ramon Fried
---
Sending Stefan's RFC as patch, as I tested it and it seems to work,
additionally, an accompanying fix was made by me to gpiolibd to fix a
display error of the actual result:
https://patchwork.ozlabs.org/patch/1139923/
drivers/gpio/gpiolib.c | 3 ++-
drivers/pinctrl/core.c | 23 +++
drivers/pinctrl/pinmux.c | 18 ++
drivers/pinctrl/pinmux.h | 7 +++
include/linux/pinctrl/consumer.h | 6 ++
5 files changed, 56 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index e013d417a936..2fd9eee0b98c 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1082,7 +1082,8 @@ static long gpio_ioctl(struct file *filp, unsigned int
cmd, unsigned long arg)
test_bit(FLAG_IS_HOGGED, >flags) ||
test_bit(FLAG_USED_AS_IRQ, >flags) ||
test_bit(FLAG_EXPORT, >flags) ||
- test_bit(FLAG_SYSFS, >flags))
+ test_bit(FLAG_SYSFS, >flags) ||
+ pinctrl_gpio_is_in_use(chip->base + lineinfo.line_offset))
lineinfo.flags |= GPIOLINE_FLAG_KERNEL;
if (test_bit(FLAG_IS_OUT, >flags))
lineinfo.flags |= GPIOLINE_FLAG_IS_OUT;
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index a64849a9d1b0..0dd00c175eed 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -759,6 +759,29 @@ int pinctrl_get_group_selector(struct pinctrl_dev *pctldev,
return -EINVAL;
}
+bool pinctrl_gpio_is_in_use(unsigned gpio)
+{
+ struct pinctrl_dev *pctldev;
+ struct pinctrl_gpio_range *range;
+ bool result;
+ int pin;
+
+ if (pinctrl_get_device_gpio_range(gpio, , ))
+ return false;
+
+ mutex_lock(>mutex);
+
+ /* Convert to the pin controllers number space */
+ pin = gpio_to_pin(range, gpio);
+
+ result = pinmux_is_in_use(pctldev, pin);
+
+ mutex_unlock(>mutex);
+
+ return result;
+}
+EXPORT_SYMBOL_GPL(pinctrl_gpio_is_in_use);
+
/**
* pinctrl_gpio_request() - request a single pin to be used as GPIO
* @gpio: the GPIO pin number from the GPIO subsystem number space
diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index 020e54f843f9..02d2751a4884 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -70,6 +70,24 @@ int pinmux_validate_map(const struct pinctrl_map *map, int i)
return 0;
}
+bool pinmux_is_in_use(struct pinctrl_dev *pctldev, unsigned pin)
+{
+ struct pin_desc *desc = pin_desc_get(pctldev, pin);
+ const struct pinmux_ops *ops = pctldev->desc->pmxops;
+
+ if (!desc) {
+ dev_err(pctldev->dev,
+ "pin %u is not registered so it cannot be requested\n",
+ pin);
+ return false;
+ }
+
+ if (ops->strict && desc->mux_usecount)
+ return true;
+
+ return ops->strict && !!desc->gpio_owner;
+}
+
/**
* pin_request() - request a single pin to be muxed in, typically for GPIO
* @pin: the pin number in the global pin space
diff --git a/drivers/pinctrl/pinmux.h b/drivers/pinctrl/pinmux.h
index 794cb3a003ff..24ae61136803 100644
--- a/drivers/pinctrl/pinmux.h
+++ b/drivers/pinctrl/pinmux.h
@@ -15,6 +15,8 @@ int pinmux_check_ops(struct pinctrl_dev *pctldev);
int pinmux_validate_map(const struct pinctrl_map *map, int i);
+bool pinmux_is_in_use(struct pinctrl_dev *pctldev, unsigned pin);
+
int pinmux_request_gpio(struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *range,
unsigned pin, unsigned gpio);
@@ -42,6 +44,11 @@ static inline int pinmux_validate_map(const struct
pinctrl_map *map, int i)
return 0;
}
+static inline bool pinmux_is_in_use(struct pinctrl_dev *pctldev, unsigned pin)
+{
+ return false;
+}
+
static inline int pinmux_request_gpio(struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *range,
unsigned pin, unsigned gpio)
diff --git a/include/linux/pinctrl/consumer.h b/include/linux/pinctrl/consumer.h
index 86720a5a384f..d26826b057a1 100644
--- a/include/linux/pinctrl/consumer.h
+++ b/include/linux/pinctrl/consumer.h
@@ -24,6 +24,7 @@ struct device;
#ifdef CONFIG_PINCTRL
/* External interface to pin control */
+extern bool pinctrl_gpio_is_in_use(unsigned gpio);
extern int pinctrl
[PATCH] pinctrl.txt: Remove outdated information
Returning -EAGAIN is no longer supported by pin_config_group_set()
since ad42fc6c8479 ("pinctrl: rip out the direct pinconf API")
Remove the relevant section from the documentation.
Signed-off-by: Ramon Fried
---
Documentation/driver-api/pinctl.rst | 9 -
1 file changed, 9 deletions(-)
diff --git a/Documentation/driver-api/pinctl.rst
b/Documentation/driver-api/pinctl.rst
index 6cb68d67fa75..2bb1bc484278 100644
--- a/Documentation/driver-api/pinctl.rst
+++ b/Documentation/driver-api/pinctl.rst
@@ -274,15 +274,6 @@ configuration in the pin controller ops like this::
.confops = _pconf_ops,
};
-Since some controllers have special logic for handling entire groups of pins
-they can exploit the special whole-group pin control function. The
-pin_config_group_set() callback is allowed to return the error code -EAGAIN,
-for groups it does not want to handle, or if it just wants to do some
-group-level handling and then fall through to iterate over all pins, in which
-case each individual pin will be treated by separate pin_config_set() calls as
-well.
-
-
Interaction with the GPIO subsystem
===
--
2.17.1
Re: pinctrl: -EAGAIN not supported but documented
On 1/21/19 4:26 PM, Linus Walleij wrote: On Mon, Jan 21, 2019 at 2:28 PM Ramon Fried wrote: Stated in Documentation/driver-api/pinctl.rst: Since some controllers have special logic for handling entire groups of pins they can exploit the special whole-group pin control function. The pin_config_group_set() callback is allowed to return the error code -EAGAIN, for groups it does not want to handle, or if it just wants to do some group-level handling and then fall through to iterate over all pins, in which case each individual pin will be treated by separate pin_config_set() calls as well. This is not supported, and there's no code for handling it. Should we add the necessary code or just remove the wrong documentation. The idea was removed in: commit ad42fc6c84795d19972e7f7dee70fe74bec4c2d8 "pinctrl: rip out the direct pinconf API" I think we should just remove the documentation. Do you want me to look into it or do you want to send a patch? Yours, Linus Walleij I'll send a patch shortly. Thanks. Ramon.
pinctrl: -EAGAIN not supported but documented
Hi Linus, Stated in Documentation/driver-api/pinctl.rst: Since some controllers have special logic for handling entire groups of pins they can exploit the special whole-group pin control function. The pin_config_group_set() callback is allowed to return the error code -EAGAIN, for groups it does not want to handle, or if it just wants to do some group-level handling and then fall through to iterate over all pins, in which case each individual pin will be treated by separate pin_config_set() calls as well. This is not supported, and there's no code for handling it. Should we add the necessary code or just remove the wrong documentation. Thanks, Ramon
Re: [PATCH 5/5] dma-direct: always allow dma mask <= physiscal memory size
On Mon, Nov 19, 2018 at 5:50 PM Robin Murphy wrote: > > On 19/11/2018 14:18, Ramon Fried wrote: > > On Tue, Oct 9, 2018 at 8:02 AM Benjamin Herrenschmidt > > wrote: > >> > >> On Wed, 2018-10-03 at 16:10 -0700, Alexander Duyck wrote: > >>>> -* Because 32-bit DMA masks are so common we expect every > >>>> architecture > >>>> -* to be able to satisfy them - either by not supporting more > >>>> physical > >>>> -* memory, or by providing a ZONE_DMA32. If neither is the > >>>> case, the > >>>> -* architecture needs to use an IOMMU instead of the direct > >>>> mapping. > >>>> -*/ > >>>> - if (mask < phys_to_dma(dev, DMA_BIT_MASK(32))) > >>>> + u64 min_mask; > >>>> + > >>>> + if (IS_ENABLED(CONFIG_ZONE_DMA)) > >>>> + min_mask = DMA_BIT_MASK(ARCH_ZONE_DMA_BITS); > >>>> + else > >>>> + min_mask = DMA_BIT_MASK(32); > >>>> + > >>>> + min_mask = min_t(u64, min_mask, (max_pfn - 1) << PAGE_SHIFT); > >>>> + > >>>> + if (mask >= phys_to_dma(dev, min_mask)) > >>>> return 0; > >>>> -#endif > >>>> return 1; > >>>>} > >>> > >>> So I believe I have run into the same issue that Guenter reported. On > >>> an x86_64 system w/ Intel IOMMU. I wasn't able to complete boot and > >>> all probe attempts for various devices were failing with -EIO errors. > >>> > >>> I believe the last mask check should be "if (mask < phys_to_dma(dev, > >>> min_mask))" not a ">=" check. > >> > >> Right, that test is backwards. I needed to change it here too (powermac > >> with the rest of the powerpc series). > >> > >> Cheers, > >> Ben. > >> > >> > > > > Hi, I'm working on a MIPS64 soc with PCIe root complex on it, and it > > appears that this series of patches are causing all PCI drivers that > > request 64bit mask to fail with -5. > > It's broken in 4.19. However, I just checked, it working on master. > > We may need to backport a couple of patches to 4.19. I'm not sure > > though which patches should be backported as there were at least 10 > > patches resolving this dma_direct area recently. > > Christoph, Robin. > > Can we ask Greg to backport all these changes ? What do you think ? > > As far as I'm aware, the only real issue in 4.19 was my subtle breakage > around setting bus_dma_mask - that's fixed by 6778be4e5209, which > according to my inbox got picked up by autosel for 4.19 stable last week. > > Robin. Yep, 6778be4e5209 fixes the issue. Thanks a lot ! Ramon.
Re: [PATCH 5/5] dma-direct: always allow dma mask <= physiscal memory size
On Mon, Nov 19, 2018 at 5:50 PM Robin Murphy wrote: > > On 19/11/2018 14:18, Ramon Fried wrote: > > On Tue, Oct 9, 2018 at 8:02 AM Benjamin Herrenschmidt > > wrote: > >> > >> On Wed, 2018-10-03 at 16:10 -0700, Alexander Duyck wrote: > >>>> -* Because 32-bit DMA masks are so common we expect every > >>>> architecture > >>>> -* to be able to satisfy them - either by not supporting more > >>>> physical > >>>> -* memory, or by providing a ZONE_DMA32. If neither is the > >>>> case, the > >>>> -* architecture needs to use an IOMMU instead of the direct > >>>> mapping. > >>>> -*/ > >>>> - if (mask < phys_to_dma(dev, DMA_BIT_MASK(32))) > >>>> + u64 min_mask; > >>>> + > >>>> + if (IS_ENABLED(CONFIG_ZONE_DMA)) > >>>> + min_mask = DMA_BIT_MASK(ARCH_ZONE_DMA_BITS); > >>>> + else > >>>> + min_mask = DMA_BIT_MASK(32); > >>>> + > >>>> + min_mask = min_t(u64, min_mask, (max_pfn - 1) << PAGE_SHIFT); > >>>> + > >>>> + if (mask >= phys_to_dma(dev, min_mask)) > >>>> return 0; > >>>> -#endif > >>>> return 1; > >>>>} > >>> > >>> So I believe I have run into the same issue that Guenter reported. On > >>> an x86_64 system w/ Intel IOMMU. I wasn't able to complete boot and > >>> all probe attempts for various devices were failing with -EIO errors. > >>> > >>> I believe the last mask check should be "if (mask < phys_to_dma(dev, > >>> min_mask))" not a ">=" check. > >> > >> Right, that test is backwards. I needed to change it here too (powermac > >> with the rest of the powerpc series). > >> > >> Cheers, > >> Ben. > >> > >> > > > > Hi, I'm working on a MIPS64 soc with PCIe root complex on it, and it > > appears that this series of patches are causing all PCI drivers that > > request 64bit mask to fail with -5. > > It's broken in 4.19. However, I just checked, it working on master. > > We may need to backport a couple of patches to 4.19. I'm not sure > > though which patches should be backported as there were at least 10 > > patches resolving this dma_direct area recently. > > Christoph, Robin. > > Can we ask Greg to backport all these changes ? What do you think ? > > As far as I'm aware, the only real issue in 4.19 was my subtle breakage > around setting bus_dma_mask - that's fixed by 6778be4e5209, which > according to my inbox got picked up by autosel for 4.19 stable last week. > > Robin. Yep, 6778be4e5209 fixes the issue. Thanks a lot ! Ramon.
Re: [PATCH 5/5] dma-direct: always allow dma mask <= physiscal memory size
On Tue, Oct 9, 2018 at 8:02 AM Benjamin Herrenschmidt wrote: > > On Wed, 2018-10-03 at 16:10 -0700, Alexander Duyck wrote: > > > -* Because 32-bit DMA masks are so common we expect every > > > architecture > > > -* to be able to satisfy them - either by not supporting more > > > physical > > > -* memory, or by providing a ZONE_DMA32. If neither is the case, > > > the > > > -* architecture needs to use an IOMMU instead of the direct > > > mapping. > > > -*/ > > > - if (mask < phys_to_dma(dev, DMA_BIT_MASK(32))) > > > + u64 min_mask; > > > + > > > + if (IS_ENABLED(CONFIG_ZONE_DMA)) > > > + min_mask = DMA_BIT_MASK(ARCH_ZONE_DMA_BITS); > > > + else > > > + min_mask = DMA_BIT_MASK(32); > > > + > > > + min_mask = min_t(u64, min_mask, (max_pfn - 1) << PAGE_SHIFT); > > > + > > > + if (mask >= phys_to_dma(dev, min_mask)) > > > return 0; > > > -#endif > > > return 1; > > > } > > > > So I believe I have run into the same issue that Guenter reported. On > > an x86_64 system w/ Intel IOMMU. I wasn't able to complete boot and > > all probe attempts for various devices were failing with -EIO errors. > > > > I believe the last mask check should be "if (mask < phys_to_dma(dev, > > min_mask))" not a ">=" check. > > Right, that test is backwards. I needed to change it here too (powermac > with the rest of the powerpc series). > > Cheers, > Ben. > > Hi, I'm working on a MIPS64 soc with PCIe root complex on it, and it appears that this series of patches are causing all PCI drivers that request 64bit mask to fail with -5. It's broken in 4.19. However, I just checked, it working on master. We may need to backport a couple of patches to 4.19. I'm not sure though which patches should be backported as there were at least 10 patches resolving this dma_direct area recently. Christoph, Robin. Can we ask Greg to backport all these changes ? What do you think ? Thanks, Ramon.
Re: [PATCH 5/5] dma-direct: always allow dma mask <= physiscal memory size
On Tue, Oct 9, 2018 at 8:02 AM Benjamin Herrenschmidt wrote: > > On Wed, 2018-10-03 at 16:10 -0700, Alexander Duyck wrote: > > > -* Because 32-bit DMA masks are so common we expect every > > > architecture > > > -* to be able to satisfy them - either by not supporting more > > > physical > > > -* memory, or by providing a ZONE_DMA32. If neither is the case, > > > the > > > -* architecture needs to use an IOMMU instead of the direct > > > mapping. > > > -*/ > > > - if (mask < phys_to_dma(dev, DMA_BIT_MASK(32))) > > > + u64 min_mask; > > > + > > > + if (IS_ENABLED(CONFIG_ZONE_DMA)) > > > + min_mask = DMA_BIT_MASK(ARCH_ZONE_DMA_BITS); > > > + else > > > + min_mask = DMA_BIT_MASK(32); > > > + > > > + min_mask = min_t(u64, min_mask, (max_pfn - 1) << PAGE_SHIFT); > > > + > > > + if (mask >= phys_to_dma(dev, min_mask)) > > > return 0; > > > -#endif > > > return 1; > > > } > > > > So I believe I have run into the same issue that Guenter reported. On > > an x86_64 system w/ Intel IOMMU. I wasn't able to complete boot and > > all probe attempts for various devices were failing with -EIO errors. > > > > I believe the last mask check should be "if (mask < phys_to_dma(dev, > > min_mask))" not a ">=" check. > > Right, that test is backwards. I needed to change it here too (powermac > with the rest of the powerpc series). > > Cheers, > Ben. > > Hi, I'm working on a MIPS64 soc with PCIe root complex on it, and it appears that this series of patches are causing all PCI drivers that request 64bit mask to fail with -5. It's broken in 4.19. However, I just checked, it working on master. We may need to backport a couple of patches to 4.19. I'm not sure though which patches should be backported as there were at least 10 patches resolving this dma_direct area recently. Christoph, Robin. Can we ask Greg to backport all these changes ? What do you think ? Thanks, Ramon.
RFC: completion: support poll()
Hi. If what I'm suggesting makes no sense please tell me. :) In a char driver I'm writing I'm using completion to wait for transmit operation to complete. The drivers also exposes poll() functionality to wait for transmission to complete. poll_wait() requires a wait queue, is there a reason why can't I use the wait queue that is hidden inside the completion struct ? I'm suggesting to add an API to get the wait_queue so it can be used for the above scenario. Appreciate your comments. Thanks, Ramon.
RFC: completion: support poll()
Hi. If what I'm suggesting makes no sense please tell me. :) In a char driver I'm writing I'm using completion to wait for transmit operation to complete. The drivers also exposes poll() functionality to wait for transmission to complete. poll_wait() requires a wait queue, is there a reason why can't I use the wait queue that is hidden inside the completion struct ? I'm suggesting to add an API to get the wait_queue so it can be used for the above scenario. Appreciate your comments. Thanks, Ramon.
Re: PCI Endpoint - Missing inbound mapping ops ?
On Tue, Aug 14, 2018 at 2:04 PM Kishon Vijay Abraham I wrote: > > Hi, > > On Tuesday 14 August 2018 06:25 PM, Ramon Fried wrote: > > On Tue, Aug 14, 2018 at 1:53 PM Kishon Vijay Abraham I > > wrote: > >> > >> Hi, > >> > >> On Tuesday 14 August 2018 06:19 PM, Ramon Fried wrote: > >>> Hi. > >>> I recently saw that the PCI endpoint API only supports outbound memory > >>> mapping: (AXI -> PCI) through the map_addr op. > >>> Why inbound mapping is missing (PCI->AXI) is missing ? > >>> In almost all of the PCI EP controllers I've worked with there was a > >>> need to map complete BARS or part of BARS to mmio/aperature regions on > >>> the device. > >> > >> pci_epc_set_bar() is used for mapping BAR. > > Thanks Kishon. > > what about address mapping ? Synopsys has this functionality if I > > recall correctly. > > The addresses that the RC will put in BAR's is not known while we initialize > the endpoint. So we really can't map BAR's PCI address to an inbound address > while EP initialization. > > I think some older version of Synopsys had this (and didn't have BAR mapping). > Actually TI's K2G had this IP. However the ATU registers here are mapped to > BAR0. So the host side PCI driver can program the PCI address (that the RC has > allocated for BARs) in ATU. Yes. you're right. Thanks for the clarification. > > Thanks > Kishon
Re: PCI Endpoint - Missing inbound mapping ops ?
On Tue, Aug 14, 2018 at 2:04 PM Kishon Vijay Abraham I wrote: > > Hi, > > On Tuesday 14 August 2018 06:25 PM, Ramon Fried wrote: > > On Tue, Aug 14, 2018 at 1:53 PM Kishon Vijay Abraham I > > wrote: > >> > >> Hi, > >> > >> On Tuesday 14 August 2018 06:19 PM, Ramon Fried wrote: > >>> Hi. > >>> I recently saw that the PCI endpoint API only supports outbound memory > >>> mapping: (AXI -> PCI) through the map_addr op. > >>> Why inbound mapping is missing (PCI->AXI) is missing ? > >>> In almost all of the PCI EP controllers I've worked with there was a > >>> need to map complete BARS or part of BARS to mmio/aperature regions on > >>> the device. > >> > >> pci_epc_set_bar() is used for mapping BAR. > > Thanks Kishon. > > what about address mapping ? Synopsys has this functionality if I > > recall correctly. > > The addresses that the RC will put in BAR's is not known while we initialize > the endpoint. So we really can't map BAR's PCI address to an inbound address > while EP initialization. > > I think some older version of Synopsys had this (and didn't have BAR mapping). > Actually TI's K2G had this IP. However the ATU registers here are mapped to > BAR0. So the host side PCI driver can program the PCI address (that the RC has > allocated for BARs) in ATU. Yes. you're right. Thanks for the clarification. > > Thanks > Kishon
Re: PCI Endpoint - Missing inbound mapping ops ?
On Tue, Aug 14, 2018 at 1:53 PM Kishon Vijay Abraham I wrote: > > Hi, > > On Tuesday 14 August 2018 06:19 PM, Ramon Fried wrote: > > Hi. > > I recently saw that the PCI endpoint API only supports outbound memory > > mapping: (AXI -> PCI) through the map_addr op. > > Why inbound mapping is missing (PCI->AXI) is missing ? > > In almost all of the PCI EP controllers I've worked with there was a > > need to map complete BARS or part of BARS to mmio/aperature regions on > > the device. > > pci_epc_set_bar() is used for mapping BAR. Thanks Kishon. what about address mapping ? Synopsys has this functionality if I recall correctly. > > Thanks > Kishon
Re: PCI Endpoint - Missing inbound mapping ops ?
On Tue, Aug 14, 2018 at 1:53 PM Kishon Vijay Abraham I wrote: > > Hi, > > On Tuesday 14 August 2018 06:19 PM, Ramon Fried wrote: > > Hi. > > I recently saw that the PCI endpoint API only supports outbound memory > > mapping: (AXI -> PCI) through the map_addr op. > > Why inbound mapping is missing (PCI->AXI) is missing ? > > In almost all of the PCI EP controllers I've worked with there was a > > need to map complete BARS or part of BARS to mmio/aperature regions on > > the device. > > pci_epc_set_bar() is used for mapping BAR. Thanks Kishon. what about address mapping ? Synopsys has this functionality if I recall correctly. > > Thanks > Kishon
PCI Endpoint - Missing inbound mapping ops ?
Hi. I recently saw that the PCI endpoint API only supports outbound memory mapping: (AXI -> PCI) through the map_addr op. Why inbound mapping is missing (PCI->AXI) is missing ? In almost all of the PCI EP controllers I've worked with there was a need to map complete BARS or part of BARS to mmio/aperature regions on the device. Thanks ! Ramon.
PCI Endpoint - Missing inbound mapping ops ?
Hi. I recently saw that the PCI endpoint API only supports outbound memory mapping: (AXI -> PCI) through the map_addr op. Why inbound mapping is missing (PCI->AXI) is missing ? In almost all of the PCI EP controllers I've worked with there was a need to map complete BARS or part of BARS to mmio/aperature regions on the device. Thanks ! Ramon.
[PATCH] soc: qcom: smem: fix checkpatch warnings
* Fixed checkpatch.sh warnings in smem.c & smem.h:
- WARNING: Prefer 'unsigned int' to bare use of 'unsigned'.
- WARNING: Block comments should align the * on each line.
- WARNING: line over 80 characters.
- ERROR: do not use assignment in if condition.
* Fixed grammar in comment.
Signed-off-by: Ramon Fried
---
drivers/soc/qcom/smem.c | 41 +++
include/linux/soc/qcom/smem.h | 6 ++---
2 files changed, 25 insertions(+), 22 deletions(-)
diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
index 0b94d62fad2b..e5ef6611ed73 100644
--- a/drivers/soc/qcom/smem.c
+++ b/drivers/soc/qcom/smem.c
@@ -22,7 +22,7 @@
#include
/*
- * The Qualcomm shared memory system is a allocate only heap structure that
+ * The Qualcomm shared memory system is an allocate only heap structure that
* consists of one of more memory areas that can be accessed by the processors
* in the SoC.
*
@@ -94,11 +94,11 @@
#define SMEM_HOST_COUNT10
/**
- * struct smem_proc_comm - proc_comm communication struct (legacy)
- * @command: current command to be executed
- * @status: status of the currently requested command
- * @params: parameters to the command
- */
+ * struct smem_proc_comm - proc_comm communication struct (legacy)
+ * @command: current command to be executed
+ * @status:status of the currently requested command
+ * @params:parameters to the command
+ */
struct smem_proc_comm {
__le32 command;
__le32 status;
@@ -276,7 +276,7 @@ struct qcom_smem {
size_t cacheline[SMEM_HOST_COUNT];
u32 item_count;
- unsigned num_regions;
+ unsigned int num_regions;
struct smem_region regions[0];
};
@@ -350,7 +350,7 @@ static struct qcom_smem *__smem;
static int qcom_smem_alloc_private(struct qcom_smem *smem,
struct smem_partition_header *phdr,
- unsigned item,
+ unsigned int item,
size_t size)
{
struct smem_private_entry *hdr, *end;
@@ -400,7 +400,7 @@ static int qcom_smem_alloc_private(struct qcom_smem *smem,
}
static int qcom_smem_alloc_global(struct qcom_smem *smem,
- unsigned item,
+ unsigned int item,
size_t size)
{
struct smem_global_entry *entry;
@@ -441,7 +441,7 @@ static int qcom_smem_alloc_global(struct qcom_smem *smem,
* Allocate space for a given smem item of size @size, given that the item is
* not yet allocated.
*/
-int qcom_smem_alloc(unsigned host, unsigned item, size_t size)
+int qcom_smem_alloc(unsigned int host, unsigned int item, size_t size)
{
struct smem_partition_header *phdr;
unsigned long flags;
@@ -482,14 +482,14 @@ int qcom_smem_alloc(unsigned host, unsigned item, size_t
size)
EXPORT_SYMBOL(qcom_smem_alloc);
static void *qcom_smem_get_global(struct qcom_smem *smem,
- unsigned item,
+ unsigned int item,
size_t *size)
{
struct smem_header *header;
struct smem_region *area;
struct smem_global_entry *entry;
u32 aux_base;
- unsigned i;
+ unsigned int i;
header = smem->regions[0].virt_base;
entry = >toc[item];
@@ -514,7 +514,7 @@ static void *qcom_smem_get_global(struct qcom_smem *smem,
static void *qcom_smem_get_private(struct qcom_smem *smem,
struct smem_partition_header *phdr,
size_t cacheline,
- unsigned item,
+ unsigned int item,
size_t *size)
{
struct smem_private_entry *e, *end;
@@ -575,7 +575,7 @@ static void *qcom_smem_get_private(struct qcom_smem *smem,
* Looks up smem item and returns pointer to it. Size of smem
* item is returned in @size.
*/
-void *qcom_smem_get(unsigned host, unsigned item, size_t *size)
+void *qcom_smem_get(unsigned int host, unsigned int item, size_t *size)
{
struct smem_partition_header *phdr;
unsigned long flags;
@@ -621,11 +621,11 @@ EXPORT_SYMBOL(qcom_smem_get);
* To be used by smem clients as a quick way to determine if any new
* allocations has been made.
*/
-int qcom_smem_get_free_space(unsigned host)
+int qcom_smem_get_free_space(unsigned int host)
{
struct smem_partition_header *phdr;
struct smem_header *header;
- unsigned ret;
+ unsigned int ret;
if (!__smem)
return -EPROBE_DEFER;
@@ -902,9 +902,12 @@ static int qcom_smem_probe(struct platform_device *pdev)
if (ret)
return ret;
- if (num_regions > 1 && (ret = qcom_smem_map_memory(smem, >dev,
-
[PATCH] soc: qcom: smem: fix checkpatch warnings
* Fixed checkpatch.sh warnings in smem.c & smem.h:
- WARNING: Prefer 'unsigned int' to bare use of 'unsigned'.
- WARNING: Block comments should align the * on each line.
- WARNING: line over 80 characters.
- ERROR: do not use assignment in if condition.
* Fixed grammar in comment.
Signed-off-by: Ramon Fried
---
drivers/soc/qcom/smem.c | 41 +++
include/linux/soc/qcom/smem.h | 6 ++---
2 files changed, 25 insertions(+), 22 deletions(-)
diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
index 0b94d62fad2b..e5ef6611ed73 100644
--- a/drivers/soc/qcom/smem.c
+++ b/drivers/soc/qcom/smem.c
@@ -22,7 +22,7 @@
#include
/*
- * The Qualcomm shared memory system is a allocate only heap structure that
+ * The Qualcomm shared memory system is an allocate only heap structure that
* consists of one of more memory areas that can be accessed by the processors
* in the SoC.
*
@@ -94,11 +94,11 @@
#define SMEM_HOST_COUNT10
/**
- * struct smem_proc_comm - proc_comm communication struct (legacy)
- * @command: current command to be executed
- * @status: status of the currently requested command
- * @params: parameters to the command
- */
+ * struct smem_proc_comm - proc_comm communication struct (legacy)
+ * @command: current command to be executed
+ * @status:status of the currently requested command
+ * @params:parameters to the command
+ */
struct smem_proc_comm {
__le32 command;
__le32 status;
@@ -276,7 +276,7 @@ struct qcom_smem {
size_t cacheline[SMEM_HOST_COUNT];
u32 item_count;
- unsigned num_regions;
+ unsigned int num_regions;
struct smem_region regions[0];
};
@@ -350,7 +350,7 @@ static struct qcom_smem *__smem;
static int qcom_smem_alloc_private(struct qcom_smem *smem,
struct smem_partition_header *phdr,
- unsigned item,
+ unsigned int item,
size_t size)
{
struct smem_private_entry *hdr, *end;
@@ -400,7 +400,7 @@ static int qcom_smem_alloc_private(struct qcom_smem *smem,
}
static int qcom_smem_alloc_global(struct qcom_smem *smem,
- unsigned item,
+ unsigned int item,
size_t size)
{
struct smem_global_entry *entry;
@@ -441,7 +441,7 @@ static int qcom_smem_alloc_global(struct qcom_smem *smem,
* Allocate space for a given smem item of size @size, given that the item is
* not yet allocated.
*/
-int qcom_smem_alloc(unsigned host, unsigned item, size_t size)
+int qcom_smem_alloc(unsigned int host, unsigned int item, size_t size)
{
struct smem_partition_header *phdr;
unsigned long flags;
@@ -482,14 +482,14 @@ int qcom_smem_alloc(unsigned host, unsigned item, size_t
size)
EXPORT_SYMBOL(qcom_smem_alloc);
static void *qcom_smem_get_global(struct qcom_smem *smem,
- unsigned item,
+ unsigned int item,
size_t *size)
{
struct smem_header *header;
struct smem_region *area;
struct smem_global_entry *entry;
u32 aux_base;
- unsigned i;
+ unsigned int i;
header = smem->regions[0].virt_base;
entry = >toc[item];
@@ -514,7 +514,7 @@ static void *qcom_smem_get_global(struct qcom_smem *smem,
static void *qcom_smem_get_private(struct qcom_smem *smem,
struct smem_partition_header *phdr,
size_t cacheline,
- unsigned item,
+ unsigned int item,
size_t *size)
{
struct smem_private_entry *e, *end;
@@ -575,7 +575,7 @@ static void *qcom_smem_get_private(struct qcom_smem *smem,
* Looks up smem item and returns pointer to it. Size of smem
* item is returned in @size.
*/
-void *qcom_smem_get(unsigned host, unsigned item, size_t *size)
+void *qcom_smem_get(unsigned int host, unsigned int item, size_t *size)
{
struct smem_partition_header *phdr;
unsigned long flags;
@@ -621,11 +621,11 @@ EXPORT_SYMBOL(qcom_smem_get);
* To be used by smem clients as a quick way to determine if any new
* allocations has been made.
*/
-int qcom_smem_get_free_space(unsigned host)
+int qcom_smem_get_free_space(unsigned int host)
{
struct smem_partition_header *phdr;
struct smem_header *header;
- unsigned ret;
+ unsigned int ret;
if (!__smem)
return -EPROBE_DEFER;
@@ -902,9 +902,12 @@ static int qcom_smem_probe(struct platform_device *pdev)
if (ret)
return ret;
- if (num_regions > 1 && (ret = qcom_smem_map_memory(smem, >dev,
-
Re: [PATCH] remoteproc: qcom_q6v5: don't auto boot remote processor
On Tue, May 29, 2018 at 7:20 AM, Bjorn Andersson wrote: > On Thu 24 May 12:21 PDT 2018, Ramon Fried wrote: > >> Sometimes that rmtfs userspace module is not brought >> up fast enough and the modem crashes. >> disabling automated boot in the driver and triggering >> the boot from user-space sovles the problem. >> >> Signed-off-by: Ramon Fried > > Thanks for your patch Ramon. While this nudges the behavior to make > things work slightly better I think we need to describe the explicit > dependency between the mss firmware and the existence of rmtfs. > > As our remoteprocs are essentially always-on I would prefer that they > start "automatically" and not through use of the sysfs interface. > > But we're at the point where this is a real problem on 410, 820 and 845, > so we have to come up with some way to tie these pieces together. If > your patch suits that solution I will happily take it. Yes. it was tested on 410, and it did the trick. > > Regards, > Bjorn > >> --- >> drivers/remoteproc/qcom_q6v5_pil.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/drivers/remoteproc/qcom_q6v5_pil.c >> b/drivers/remoteproc/qcom_q6v5_pil.c >> index cbbafdcaaecb..719ee96445b3 100644 >> --- a/drivers/remoteproc/qcom_q6v5_pil.c >> +++ b/drivers/remoteproc/qcom_q6v5_pil.c >> @@ -1133,6 +1133,8 @@ static int q6v5_probe(struct platform_device *pdev) >> return -ENOMEM; >> } >> >> + rproc->auto_boot = false; >> + >> qproc = (struct q6v5 *)rproc->priv; >> qproc->dev = >dev; >> qproc->rproc = rproc; >> -- >> 2.17.0 >>
Re: [PATCH] remoteproc: qcom_q6v5: don't auto boot remote processor
On Tue, May 29, 2018 at 7:20 AM, Bjorn Andersson wrote: > On Thu 24 May 12:21 PDT 2018, Ramon Fried wrote: > >> Sometimes that rmtfs userspace module is not brought >> up fast enough and the modem crashes. >> disabling automated boot in the driver and triggering >> the boot from user-space sovles the problem. >> >> Signed-off-by: Ramon Fried > > Thanks for your patch Ramon. While this nudges the behavior to make > things work slightly better I think we need to describe the explicit > dependency between the mss firmware and the existence of rmtfs. > > As our remoteprocs are essentially always-on I would prefer that they > start "automatically" and not through use of the sysfs interface. > > But we're at the point where this is a real problem on 410, 820 and 845, > so we have to come up with some way to tie these pieces together. If > your patch suits that solution I will happily take it. Yes. it was tested on 410, and it did the trick. > > Regards, > Bjorn > >> --- >> drivers/remoteproc/qcom_q6v5_pil.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/drivers/remoteproc/qcom_q6v5_pil.c >> b/drivers/remoteproc/qcom_q6v5_pil.c >> index cbbafdcaaecb..719ee96445b3 100644 >> --- a/drivers/remoteproc/qcom_q6v5_pil.c >> +++ b/drivers/remoteproc/qcom_q6v5_pil.c >> @@ -1133,6 +1133,8 @@ static int q6v5_probe(struct platform_device *pdev) >> return -ENOMEM; >> } >> >> + rproc->auto_boot = false; >> + >> qproc = (struct q6v5 *)rproc->priv; >> qproc->dev = >dev; >> qproc->rproc = rproc; >> -- >> 2.17.0 >>
Re: uImage target support on arm64
On Thu, May 24, 2018 at 10:34 PM, Baruch Siach <bar...@tkos.co.il> wrote:
> Hi Ramon,
>
> On Thu, May 24, 2018 at 10:05:15PM +0300, Ramon Fried wrote:
>> I've noticed that it's not supported.
>> Is it on purpose ?
>
> Yes. The 32bit load address in the uImage header in pretty limited when
> applied to 64bit ARM64. Even for ARM zImage is the preferred kernel format for
> quite some time now, since it allows flexible load address, as well as
> multi-platform kernels.
Hi Baruch.
I though that in terms of U-boot, the new FIT image is the preferred
kernel format.
Thanks,
Ramon.
>
>> If not I'll be happy to add support for: make uImage
>> for arm64 targets.
>
> baruch
>
> --
> http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
> =}ooO--U--Ooo{=
>- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
Re: uImage target support on arm64
On Thu, May 24, 2018 at 10:34 PM, Baruch Siach wrote:
> Hi Ramon,
>
> On Thu, May 24, 2018 at 10:05:15PM +0300, Ramon Fried wrote:
>> I've noticed that it's not supported.
>> Is it on purpose ?
>
> Yes. The 32bit load address in the uImage header in pretty limited when
> applied to 64bit ARM64. Even for ARM zImage is the preferred kernel format for
> quite some time now, since it allows flexible load address, as well as
> multi-platform kernels.
Hi Baruch.
I though that in terms of U-boot, the new FIT image is the preferred
kernel format.
Thanks,
Ramon.
>
>> If not I'll be happy to add support for: make uImage
>> for arm64 targets.
>
> baruch
>
> --
> http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
> =}ooO--U--Ooo{=
>- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
[PATCH] remoteproc: qcom_q6v5: don't auto boot remote processor
Sometimes that rmtfs userspace module is not brought up fast enough and the modem crashes. disabling automated boot in the driver and triggering the boot from user-space sovles the problem. Signed-off-by: Ramon Fried <ramon.fr...@gmail.com> --- drivers/remoteproc/qcom_q6v5_pil.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/remoteproc/qcom_q6v5_pil.c b/drivers/remoteproc/qcom_q6v5_pil.c index cbbafdcaaecb..719ee96445b3 100644 --- a/drivers/remoteproc/qcom_q6v5_pil.c +++ b/drivers/remoteproc/qcom_q6v5_pil.c @@ -1133,6 +1133,8 @@ static int q6v5_probe(struct platform_device *pdev) return -ENOMEM; } + rproc->auto_boot = false; + qproc = (struct q6v5 *)rproc->priv; qproc->dev = >dev; qproc->rproc = rproc; -- 2.17.0
[PATCH] remoteproc: qcom_q6v5: don't auto boot remote processor
Sometimes that rmtfs userspace module is not brought up fast enough and the modem crashes. disabling automated boot in the driver and triggering the boot from user-space sovles the problem. Signed-off-by: Ramon Fried --- drivers/remoteproc/qcom_q6v5_pil.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/remoteproc/qcom_q6v5_pil.c b/drivers/remoteproc/qcom_q6v5_pil.c index cbbafdcaaecb..719ee96445b3 100644 --- a/drivers/remoteproc/qcom_q6v5_pil.c +++ b/drivers/remoteproc/qcom_q6v5_pil.c @@ -1133,6 +1133,8 @@ static int q6v5_probe(struct platform_device *pdev) return -ENOMEM; } + rproc->auto_boot = false; + qproc = (struct q6v5 *)rproc->priv; qproc->dev = >dev; qproc->rproc = rproc; -- 2.17.0
uImage target support on arm64
Hi. I've noticed that it's not supported. Is it on purpose ? If not I'll be happy to add support for: make uImage for arm64 targets. Warm regards, Ramon.
uImage target support on arm64
Hi. I've noticed that it's not supported. Is it on purpose ? If not I'll be happy to add support for: make uImage for arm64 targets. Warm regards, Ramon.
[PATCH v3] wcn36xx: Add support for Factory Test Mode (FTM)
From: Eyal Ilsar <eil...@codeaurora.org>
Introduce infrastructure for supporting Factory Test Mode (FTM) of the
wireless LAN subsystem. In order for the user space to access the
firmware in test mode the relevant netlink channel needs to be exposed
from the kernel driver.
The above is achieved as follows:
1) Register wcn36xx driver to testmode callback from netlink
2) Add testmode callback implementation to handle incoming FTM commands
3) Add FTM command packet structure
4) Add handling for GET_BUILD_RELEASE_NUMBER (msgid=0x32A2)
5) Add generic handling for all PTT_MSG packets
Signed-off-by: Eyal Ilsar <eil...@codeaurora.org>
Signed-off-by: Ramon Fried <ramon.fr...@linaro.org>
---
v3:
* fixed kbuild warning
v2:
* check for NULL after kmalloc
* don't assign value to ret.
drivers/net/wireless/ath/wcn36xx/Makefile | 2 +
drivers/net/wireless/ath/wcn36xx/hal.h| 16 ++
drivers/net/wireless/ath/wcn36xx/main.c | 3 +
drivers/net/wireless/ath/wcn36xx/smd.c| 81 ++
drivers/net/wireless/ath/wcn36xx/smd.h| 4 +
drivers/net/wireless/ath/wcn36xx/testmode.c | 149 ++
drivers/net/wireless/ath/wcn36xx/testmode.h | 46 ++
drivers/net/wireless/ath/wcn36xx/testmode_i.h | 29
drivers/net/wireless/ath/wcn36xx/wcn36xx.h| 2 +
9 files changed, 332 insertions(+)
create mode 100644 drivers/net/wireless/ath/wcn36xx/testmode.c
create mode 100644 drivers/net/wireless/ath/wcn36xx/testmode.h
create mode 100644 drivers/net/wireless/ath/wcn36xx/testmode_i.h
diff --git a/drivers/net/wireless/ath/wcn36xx/Makefile
b/drivers/net/wireless/ath/wcn36xx/Makefile
index 3b09435104eb..582049f65735 100644
--- a/drivers/net/wireless/ath/wcn36xx/Makefile
+++ b/drivers/net/wireless/ath/wcn36xx/Makefile
@@ -6,3 +6,5 @@ wcn36xx-y += main.o \
smd.o \
pmc.o \
debug.o
+
+wcn36xx-$(CONFIG_NL80211_TESTMODE) += testmode.o
diff --git a/drivers/net/wireless/ath/wcn36xx/hal.h
b/drivers/net/wireless/ath/wcn36xx/hal.h
index 182963522941..8491b3cb3206 100644
--- a/drivers/net/wireless/ath/wcn36xx/hal.h
+++ b/drivers/net/wireless/ath/wcn36xx/hal.h
@@ -2230,6 +2230,22 @@ struct wcn36xx_hal_switch_channel_rsp_msg {
} __packed;
+struct wcn36xx_hal_process_ptt_msg_req_msg {
+ struct wcn36xx_hal_msg_header header;
+
+ /* Actual FTM Command body */
+ u8 ptt_msg[0];
+} __packed;
+
+struct wcn36xx_hal_process_ptt_msg_rsp_msg {
+ struct wcn36xx_hal_msg_header header;
+
+ /* FTM Command response status */
+ u32 ptt_msg_resp_status;
+ /* Actual FTM Command body */
+ u8 ptt_msg[0];
+} __packed;
+
struct update_edca_params_req_msg {
struct wcn36xx_hal_msg_header header;
diff --git a/drivers/net/wireless/ath/wcn36xx/main.c
b/drivers/net/wireless/ath/wcn36xx/main.c
index 69d6be59d97f..ea14f87d11ff 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -26,6 +26,7 @@
#include
#include
#include "wcn36xx.h"
+#include "testmode.h"
unsigned int wcn36xx_dbg_mask;
module_param_named(debug_mask, wcn36xx_dbg_mask, uint, 0644);
@@ -1116,6 +1117,8 @@ static const struct ieee80211_ops wcn36xx_ops = {
.sta_add= wcn36xx_sta_add,
.sta_remove = wcn36xx_sta_remove,
.ampdu_action = wcn36xx_ampdu_action,
+
+ CFG80211_TESTMODE_CMD(wcn36xx_tm_cmd)
};
static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c
b/drivers/net/wireless/ath/wcn36xx/smd.c
index 8932af5e4d8d..fb0192b7ee99 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.c
+++ b/drivers/net/wireless/ath/wcn36xx/smd.c
@@ -292,12 +292,26 @@ static void init_hal_msg(struct wcn36xx_hal_msg_header
*hdr,
msg_body.header.len = sizeof(msg_body); \
} while (0) \
+#define INIT_HAL_PTT_MSG(p_msg_body, ppt_msg_len) \
+ do { \
+ memset(p_msg_body, 0, sizeof(*p_msg_body) + ppt_msg_len); \
+ p_msg_body->header.msg_type = WCN36XX_HAL_PROCESS_PTT_REQ; \
+ p_msg_body->header.msg_version = WCN36XX_HAL_MSG_VERSION0; \
+ p_msg_body->header.len = sizeof(*p_msg_body) + ppt_msg_len; \
+ } while (0)
+
#define PREPARE_HAL_BUF(send_buf, msg_body) \
do {\
memset(send_buf, 0, msg_body.header.len); \
memcpy(send_buf, _body, sizeof(msg_body)); \
} while (0) \
+#define PREPARE_HAL_PTT_MSG_BUF(send_buf, p_msg_body) \
+ do {\
+ memset(send_buf, 0, p_msg_body->header.len); \
+ memcpy(send_buf, p_msg_body, p_msg_body
[PATCH v3] wcn36xx: Add support for Factory Test Mode (FTM)
From: Eyal Ilsar
Introduce infrastructure for supporting Factory Test Mode (FTM) of the
wireless LAN subsystem. In order for the user space to access the
firmware in test mode the relevant netlink channel needs to be exposed
from the kernel driver.
The above is achieved as follows:
1) Register wcn36xx driver to testmode callback from netlink
2) Add testmode callback implementation to handle incoming FTM commands
3) Add FTM command packet structure
4) Add handling for GET_BUILD_RELEASE_NUMBER (msgid=0x32A2)
5) Add generic handling for all PTT_MSG packets
Signed-off-by: Eyal Ilsar
Signed-off-by: Ramon Fried
---
v3:
* fixed kbuild warning
v2:
* check for NULL after kmalloc
* don't assign value to ret.
drivers/net/wireless/ath/wcn36xx/Makefile | 2 +
drivers/net/wireless/ath/wcn36xx/hal.h| 16 ++
drivers/net/wireless/ath/wcn36xx/main.c | 3 +
drivers/net/wireless/ath/wcn36xx/smd.c| 81 ++
drivers/net/wireless/ath/wcn36xx/smd.h| 4 +
drivers/net/wireless/ath/wcn36xx/testmode.c | 149 ++
drivers/net/wireless/ath/wcn36xx/testmode.h | 46 ++
drivers/net/wireless/ath/wcn36xx/testmode_i.h | 29
drivers/net/wireless/ath/wcn36xx/wcn36xx.h| 2 +
9 files changed, 332 insertions(+)
create mode 100644 drivers/net/wireless/ath/wcn36xx/testmode.c
create mode 100644 drivers/net/wireless/ath/wcn36xx/testmode.h
create mode 100644 drivers/net/wireless/ath/wcn36xx/testmode_i.h
diff --git a/drivers/net/wireless/ath/wcn36xx/Makefile
b/drivers/net/wireless/ath/wcn36xx/Makefile
index 3b09435104eb..582049f65735 100644
--- a/drivers/net/wireless/ath/wcn36xx/Makefile
+++ b/drivers/net/wireless/ath/wcn36xx/Makefile
@@ -6,3 +6,5 @@ wcn36xx-y += main.o \
smd.o \
pmc.o \
debug.o
+
+wcn36xx-$(CONFIG_NL80211_TESTMODE) += testmode.o
diff --git a/drivers/net/wireless/ath/wcn36xx/hal.h
b/drivers/net/wireless/ath/wcn36xx/hal.h
index 182963522941..8491b3cb3206 100644
--- a/drivers/net/wireless/ath/wcn36xx/hal.h
+++ b/drivers/net/wireless/ath/wcn36xx/hal.h
@@ -2230,6 +2230,22 @@ struct wcn36xx_hal_switch_channel_rsp_msg {
} __packed;
+struct wcn36xx_hal_process_ptt_msg_req_msg {
+ struct wcn36xx_hal_msg_header header;
+
+ /* Actual FTM Command body */
+ u8 ptt_msg[0];
+} __packed;
+
+struct wcn36xx_hal_process_ptt_msg_rsp_msg {
+ struct wcn36xx_hal_msg_header header;
+
+ /* FTM Command response status */
+ u32 ptt_msg_resp_status;
+ /* Actual FTM Command body */
+ u8 ptt_msg[0];
+} __packed;
+
struct update_edca_params_req_msg {
struct wcn36xx_hal_msg_header header;
diff --git a/drivers/net/wireless/ath/wcn36xx/main.c
b/drivers/net/wireless/ath/wcn36xx/main.c
index 69d6be59d97f..ea14f87d11ff 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -26,6 +26,7 @@
#include
#include
#include "wcn36xx.h"
+#include "testmode.h"
unsigned int wcn36xx_dbg_mask;
module_param_named(debug_mask, wcn36xx_dbg_mask, uint, 0644);
@@ -1116,6 +1117,8 @@ static const struct ieee80211_ops wcn36xx_ops = {
.sta_add= wcn36xx_sta_add,
.sta_remove = wcn36xx_sta_remove,
.ampdu_action = wcn36xx_ampdu_action,
+
+ CFG80211_TESTMODE_CMD(wcn36xx_tm_cmd)
};
static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c
b/drivers/net/wireless/ath/wcn36xx/smd.c
index 8932af5e4d8d..fb0192b7ee99 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.c
+++ b/drivers/net/wireless/ath/wcn36xx/smd.c
@@ -292,12 +292,26 @@ static void init_hal_msg(struct wcn36xx_hal_msg_header
*hdr,
msg_body.header.len = sizeof(msg_body); \
} while (0) \
+#define INIT_HAL_PTT_MSG(p_msg_body, ppt_msg_len) \
+ do { \
+ memset(p_msg_body, 0, sizeof(*p_msg_body) + ppt_msg_len); \
+ p_msg_body->header.msg_type = WCN36XX_HAL_PROCESS_PTT_REQ; \
+ p_msg_body->header.msg_version = WCN36XX_HAL_MSG_VERSION0; \
+ p_msg_body->header.len = sizeof(*p_msg_body) + ppt_msg_len; \
+ } while (0)
+
#define PREPARE_HAL_BUF(send_buf, msg_body) \
do {\
memset(send_buf, 0, msg_body.header.len); \
memcpy(send_buf, _body, sizeof(msg_body)); \
} while (0) \
+#define PREPARE_HAL_PTT_MSG_BUF(send_buf, p_msg_body) \
+ do {\
+ memset(send_buf, 0, p_msg_body->header.len); \
+ memcpy(send_buf, p_msg_body, p_msg_body->header.len); \
+ } while (0)
+
static int wcn36xx_smd_rsp_status_check(void
[PATCH v2] wcn36xx: Add support for Factory Test Mode (FTM)
From: Eyal Ilsar <eil...@codeaurora.org>
Introduce infrastructure for supporting Factory Test Mode (FTM) of the
wireless LAN subsystem. In order for the user space to access the
firmware in test mode the relevant netlink channel needs to be exposed
from the kernel driver.
The above is achieved as follows:
1) Register wcn36xx driver to testmode callback from netlink
2) Add testmode callback implementation to handle incoming FTM commands
3) Add FTM command packet structure
4) Add handling for GET_BUILD_RELEASE_NUMBER (msgid=0x32A2)
5) Add generic handling for all PTT_MSG packets
Signed-off-by: Eyal Ilsar <eil...@codeaurora.org>
Signed-off-by: Ramon Fried <ramon.fr...@linaro.org>
---
v2:
* check for NULL after kmalloc
* don't assign value to ret.
drivers/net/wireless/ath/wcn36xx/Makefile | 2 +
drivers/net/wireless/ath/wcn36xx/hal.h| 16 ++
drivers/net/wireless/ath/wcn36xx/main.c | 3 +
drivers/net/wireless/ath/wcn36xx/smd.c| 81 ++
drivers/net/wireless/ath/wcn36xx/smd.h| 4 +
drivers/net/wireless/ath/wcn36xx/testmode.c | 151 ++
drivers/net/wireless/ath/wcn36xx/testmode.h | 46 ++
drivers/net/wireless/ath/wcn36xx/testmode_i.h | 29
drivers/net/wireless/ath/wcn36xx/wcn36xx.h| 2 +
9 files changed, 334 insertions(+)
create mode 100644 drivers/net/wireless/ath/wcn36xx/testmode.c
create mode 100644 drivers/net/wireless/ath/wcn36xx/testmode.h
create mode 100644 drivers/net/wireless/ath/wcn36xx/testmode_i.h
diff --git a/drivers/net/wireless/ath/wcn36xx/Makefile
b/drivers/net/wireless/ath/wcn36xx/Makefile
index 3b09435104eb..582049f65735 100644
--- a/drivers/net/wireless/ath/wcn36xx/Makefile
+++ b/drivers/net/wireless/ath/wcn36xx/Makefile
@@ -6,3 +6,5 @@ wcn36xx-y += main.o \
smd.o \
pmc.o \
debug.o
+
+wcn36xx-$(CONFIG_NL80211_TESTMODE) += testmode.o
diff --git a/drivers/net/wireless/ath/wcn36xx/hal.h
b/drivers/net/wireless/ath/wcn36xx/hal.h
index 182963522941..8491b3cb3206 100644
--- a/drivers/net/wireless/ath/wcn36xx/hal.h
+++ b/drivers/net/wireless/ath/wcn36xx/hal.h
@@ -2230,6 +2230,22 @@ struct wcn36xx_hal_switch_channel_rsp_msg {
} __packed;
+struct wcn36xx_hal_process_ptt_msg_req_msg {
+ struct wcn36xx_hal_msg_header header;
+
+ /* Actual FTM Command body */
+ u8 ptt_msg[0];
+} __packed;
+
+struct wcn36xx_hal_process_ptt_msg_rsp_msg {
+ struct wcn36xx_hal_msg_header header;
+
+ /* FTM Command response status */
+ u32 ptt_msg_resp_status;
+ /* Actual FTM Command body */
+ u8 ptt_msg[0];
+} __packed;
+
struct update_edca_params_req_msg {
struct wcn36xx_hal_msg_header header;
diff --git a/drivers/net/wireless/ath/wcn36xx/main.c
b/drivers/net/wireless/ath/wcn36xx/main.c
index 69d6be59d97f..ea14f87d11ff 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -26,6 +26,7 @@
#include
#include
#include "wcn36xx.h"
+#include "testmode.h"
unsigned int wcn36xx_dbg_mask;
module_param_named(debug_mask, wcn36xx_dbg_mask, uint, 0644);
@@ -1116,6 +1117,8 @@ static const struct ieee80211_ops wcn36xx_ops = {
.sta_add= wcn36xx_sta_add,
.sta_remove = wcn36xx_sta_remove,
.ampdu_action = wcn36xx_ampdu_action,
+
+ CFG80211_TESTMODE_CMD(wcn36xx_tm_cmd)
};
static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c
b/drivers/net/wireless/ath/wcn36xx/smd.c
index 8932af5e4d8d..fb0192b7ee99 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.c
+++ b/drivers/net/wireless/ath/wcn36xx/smd.c
@@ -292,12 +292,26 @@ static void init_hal_msg(struct wcn36xx_hal_msg_header
*hdr,
msg_body.header.len = sizeof(msg_body); \
} while (0) \
+#define INIT_HAL_PTT_MSG(p_msg_body, ppt_msg_len) \
+ do { \
+ memset(p_msg_body, 0, sizeof(*p_msg_body) + ppt_msg_len); \
+ p_msg_body->header.msg_type = WCN36XX_HAL_PROCESS_PTT_REQ; \
+ p_msg_body->header.msg_version = WCN36XX_HAL_MSG_VERSION0; \
+ p_msg_body->header.len = sizeof(*p_msg_body) + ppt_msg_len; \
+ } while (0)
+
#define PREPARE_HAL_BUF(send_buf, msg_body) \
do {\
memset(send_buf, 0, msg_body.header.len); \
memcpy(send_buf, _body, sizeof(msg_body)); \
} while (0) \
+#define PREPARE_HAL_PTT_MSG_BUF(send_buf, p_msg_body) \
+ do {\
+ memset(send_buf, 0, p_msg_body->header.len); \
+ memcpy(send_buf, p_msg_body, p_msg_body->header.len); \
+ } while (0)
+
static i
[PATCH v2] wcn36xx: Add support for Factory Test Mode (FTM)
From: Eyal Ilsar
Introduce infrastructure for supporting Factory Test Mode (FTM) of the
wireless LAN subsystem. In order for the user space to access the
firmware in test mode the relevant netlink channel needs to be exposed
from the kernel driver.
The above is achieved as follows:
1) Register wcn36xx driver to testmode callback from netlink
2) Add testmode callback implementation to handle incoming FTM commands
3) Add FTM command packet structure
4) Add handling for GET_BUILD_RELEASE_NUMBER (msgid=0x32A2)
5) Add generic handling for all PTT_MSG packets
Signed-off-by: Eyal Ilsar
Signed-off-by: Ramon Fried
---
v2:
* check for NULL after kmalloc
* don't assign value to ret.
drivers/net/wireless/ath/wcn36xx/Makefile | 2 +
drivers/net/wireless/ath/wcn36xx/hal.h| 16 ++
drivers/net/wireless/ath/wcn36xx/main.c | 3 +
drivers/net/wireless/ath/wcn36xx/smd.c| 81 ++
drivers/net/wireless/ath/wcn36xx/smd.h| 4 +
drivers/net/wireless/ath/wcn36xx/testmode.c | 151 ++
drivers/net/wireless/ath/wcn36xx/testmode.h | 46 ++
drivers/net/wireless/ath/wcn36xx/testmode_i.h | 29
drivers/net/wireless/ath/wcn36xx/wcn36xx.h| 2 +
9 files changed, 334 insertions(+)
create mode 100644 drivers/net/wireless/ath/wcn36xx/testmode.c
create mode 100644 drivers/net/wireless/ath/wcn36xx/testmode.h
create mode 100644 drivers/net/wireless/ath/wcn36xx/testmode_i.h
diff --git a/drivers/net/wireless/ath/wcn36xx/Makefile
b/drivers/net/wireless/ath/wcn36xx/Makefile
index 3b09435104eb..582049f65735 100644
--- a/drivers/net/wireless/ath/wcn36xx/Makefile
+++ b/drivers/net/wireless/ath/wcn36xx/Makefile
@@ -6,3 +6,5 @@ wcn36xx-y += main.o \
smd.o \
pmc.o \
debug.o
+
+wcn36xx-$(CONFIG_NL80211_TESTMODE) += testmode.o
diff --git a/drivers/net/wireless/ath/wcn36xx/hal.h
b/drivers/net/wireless/ath/wcn36xx/hal.h
index 182963522941..8491b3cb3206 100644
--- a/drivers/net/wireless/ath/wcn36xx/hal.h
+++ b/drivers/net/wireless/ath/wcn36xx/hal.h
@@ -2230,6 +2230,22 @@ struct wcn36xx_hal_switch_channel_rsp_msg {
} __packed;
+struct wcn36xx_hal_process_ptt_msg_req_msg {
+ struct wcn36xx_hal_msg_header header;
+
+ /* Actual FTM Command body */
+ u8 ptt_msg[0];
+} __packed;
+
+struct wcn36xx_hal_process_ptt_msg_rsp_msg {
+ struct wcn36xx_hal_msg_header header;
+
+ /* FTM Command response status */
+ u32 ptt_msg_resp_status;
+ /* Actual FTM Command body */
+ u8 ptt_msg[0];
+} __packed;
+
struct update_edca_params_req_msg {
struct wcn36xx_hal_msg_header header;
diff --git a/drivers/net/wireless/ath/wcn36xx/main.c
b/drivers/net/wireless/ath/wcn36xx/main.c
index 69d6be59d97f..ea14f87d11ff 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -26,6 +26,7 @@
#include
#include
#include "wcn36xx.h"
+#include "testmode.h"
unsigned int wcn36xx_dbg_mask;
module_param_named(debug_mask, wcn36xx_dbg_mask, uint, 0644);
@@ -1116,6 +1117,8 @@ static const struct ieee80211_ops wcn36xx_ops = {
.sta_add= wcn36xx_sta_add,
.sta_remove = wcn36xx_sta_remove,
.ampdu_action = wcn36xx_ampdu_action,
+
+ CFG80211_TESTMODE_CMD(wcn36xx_tm_cmd)
};
static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c
b/drivers/net/wireless/ath/wcn36xx/smd.c
index 8932af5e4d8d..fb0192b7ee99 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.c
+++ b/drivers/net/wireless/ath/wcn36xx/smd.c
@@ -292,12 +292,26 @@ static void init_hal_msg(struct wcn36xx_hal_msg_header
*hdr,
msg_body.header.len = sizeof(msg_body); \
} while (0) \
+#define INIT_HAL_PTT_MSG(p_msg_body, ppt_msg_len) \
+ do { \
+ memset(p_msg_body, 0, sizeof(*p_msg_body) + ppt_msg_len); \
+ p_msg_body->header.msg_type = WCN36XX_HAL_PROCESS_PTT_REQ; \
+ p_msg_body->header.msg_version = WCN36XX_HAL_MSG_VERSION0; \
+ p_msg_body->header.len = sizeof(*p_msg_body) + ppt_msg_len; \
+ } while (0)
+
#define PREPARE_HAL_BUF(send_buf, msg_body) \
do {\
memset(send_buf, 0, msg_body.header.len); \
memcpy(send_buf, _body, sizeof(msg_body)); \
} while (0) \
+#define PREPARE_HAL_PTT_MSG_BUF(send_buf, p_msg_body) \
+ do {\
+ memset(send_buf, 0, p_msg_body->header.len); \
+ memcpy(send_buf, p_msg_body, p_msg_body->header.len); \
+ } while (0)
+
static int wcn36xx_smd_rsp_status_check(void *buf, size_t len)
{
struct wcn36xx_fw_msg
Re: [PATCH] wcn36xx: Add support for Factory Test Mode (FTM)
On 17 May 2018 at 21:37, Jeff Johnson <jjohn...@codeaurora.org> wrote:
> On 2018-05-17 04:32, Ramon Fried wrote:
>>
>> From: Eyal Ilsar <eil...@codeaurora.org>
>
> ...
>>
>> +int wcn36xx_smd_process_ptt_msg(struct wcn36xx *wcn,
>> + struct ieee80211_vif *vif, void *ptt_msg,
>> size_t len,
>> + void **ptt_rsp_msg)
>> +{
>> + struct wcn36xx_hal_process_ptt_msg_req_msg *p_msg_body;
>> + int ret = 0;
>> +
>> + mutex_lock(>hal_mutex);
>> + p_msg_body = kmalloc(
>> + sizeof(struct wcn36xx_hal_process_ptt_msg_req_msg) + len,
>> + GFP_ATOMIC);
>
>
> NULL check required?
>
>> + INIT_HAL_PTT_MSG(p_msg_body, len);
>> +
Thanks Jeff. will fix it and send again :)
Re: [PATCH] wcn36xx: Add support for Factory Test Mode (FTM)
On 17 May 2018 at 21:37, Jeff Johnson wrote:
> On 2018-05-17 04:32, Ramon Fried wrote:
>>
>> From: Eyal Ilsar
>
> ...
>>
>> +int wcn36xx_smd_process_ptt_msg(struct wcn36xx *wcn,
>> + struct ieee80211_vif *vif, void *ptt_msg,
>> size_t len,
>> + void **ptt_rsp_msg)
>> +{
>> + struct wcn36xx_hal_process_ptt_msg_req_msg *p_msg_body;
>> + int ret = 0;
>> +
>> + mutex_lock(>hal_mutex);
>> + p_msg_body = kmalloc(
>> + sizeof(struct wcn36xx_hal_process_ptt_msg_req_msg) + len,
>> + GFP_ATOMIC);
>
>
> NULL check required?
>
>> + INIT_HAL_PTT_MSG(p_msg_body, len);
>> +
Thanks Jeff. will fix it and send again :)
[PATCH] wcn36xx: Add support for Factory Test Mode (FTM)
From: Eyal Ilsar <eil...@codeaurora.org>
Introduce infrastructure for supporting Factory Test Mode (FTM) of the
wireless LAN subsystem. In order for the user space to access the
firmware in test mode the relevant netlink channel needs to be exposed
from the kernel driver.
The above is achieved as follows:
1) Register wcn36xx driver to testmode callback from netlink
2) Add testmode callback implementation to handle incoming FTM commands
3) Add FTM command packet structure
4) Add handling for GET_BUILD_RELEASE_NUMBER (msgid=0x32A2)
5) Add generic handling for all PTT_MSG packets
Signed-off-by: Eyal Ilsar <eil...@codeaurora.org>
Signed-off-by: Ramon Fried <ramon.fr...@linaro.org>
---
drivers/net/wireless/ath/wcn36xx/Makefile | 2 +
drivers/net/wireless/ath/wcn36xx/hal.h| 16 ++
drivers/net/wireless/ath/wcn36xx/main.c | 3 +
drivers/net/wireless/ath/wcn36xx/smd.c| 74 +
drivers/net/wireless/ath/wcn36xx/smd.h| 4 +
drivers/net/wireless/ath/wcn36xx/testmode.c | 151 ++
drivers/net/wireless/ath/wcn36xx/testmode.h | 46 ++
drivers/net/wireless/ath/wcn36xx/testmode_i.h | 29
drivers/net/wireless/ath/wcn36xx/wcn36xx.h| 2 +
9 files changed, 327 insertions(+)
create mode 100644 drivers/net/wireless/ath/wcn36xx/testmode.c
create mode 100644 drivers/net/wireless/ath/wcn36xx/testmode.h
create mode 100644 drivers/net/wireless/ath/wcn36xx/testmode_i.h
diff --git a/drivers/net/wireless/ath/wcn36xx/Makefile
b/drivers/net/wireless/ath/wcn36xx/Makefile
index 3b09435104eb..582049f65735 100644
--- a/drivers/net/wireless/ath/wcn36xx/Makefile
+++ b/drivers/net/wireless/ath/wcn36xx/Makefile
@@ -6,3 +6,5 @@ wcn36xx-y += main.o \
smd.o \
pmc.o \
debug.o
+
+wcn36xx-$(CONFIG_NL80211_TESTMODE) += testmode.o
diff --git a/drivers/net/wireless/ath/wcn36xx/hal.h
b/drivers/net/wireless/ath/wcn36xx/hal.h
index 182963522941..8491b3cb3206 100644
--- a/drivers/net/wireless/ath/wcn36xx/hal.h
+++ b/drivers/net/wireless/ath/wcn36xx/hal.h
@@ -2230,6 +2230,22 @@ struct wcn36xx_hal_switch_channel_rsp_msg {
} __packed;
+struct wcn36xx_hal_process_ptt_msg_req_msg {
+ struct wcn36xx_hal_msg_header header;
+
+ /* Actual FTM Command body */
+ u8 ptt_msg[0];
+} __packed;
+
+struct wcn36xx_hal_process_ptt_msg_rsp_msg {
+ struct wcn36xx_hal_msg_header header;
+
+ /* FTM Command response status */
+ u32 ptt_msg_resp_status;
+ /* Actual FTM Command body */
+ u8 ptt_msg[0];
+} __packed;
+
struct update_edca_params_req_msg {
struct wcn36xx_hal_msg_header header;
diff --git a/drivers/net/wireless/ath/wcn36xx/main.c
b/drivers/net/wireless/ath/wcn36xx/main.c
index 69d6be59d97f..ea14f87d11ff 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -26,6 +26,7 @@
#include
#include
#include "wcn36xx.h"
+#include "testmode.h"
unsigned int wcn36xx_dbg_mask;
module_param_named(debug_mask, wcn36xx_dbg_mask, uint, 0644);
@@ -1116,6 +1117,8 @@ static const struct ieee80211_ops wcn36xx_ops = {
.sta_add= wcn36xx_sta_add,
.sta_remove = wcn36xx_sta_remove,
.ampdu_action = wcn36xx_ampdu_action,
+
+ CFG80211_TESTMODE_CMD(wcn36xx_tm_cmd)
};
static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c
b/drivers/net/wireless/ath/wcn36xx/smd.c
index 8932af5e4d8d..8eaf192f8bdb 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.c
+++ b/drivers/net/wireless/ath/wcn36xx/smd.c
@@ -292,12 +292,26 @@ static void init_hal_msg(struct wcn36xx_hal_msg_header
*hdr,
msg_body.header.len = sizeof(msg_body); \
} while (0) \
+#define INIT_HAL_PTT_MSG(p_msg_body, ppt_msg_len) \
+ do { \
+ memset(p_msg_body, 0, sizeof(*p_msg_body) + ppt_msg_len); \
+ p_msg_body->header.msg_type = WCN36XX_HAL_PROCESS_PTT_REQ; \
+ p_msg_body->header.msg_version = WCN36XX_HAL_MSG_VERSION0; \
+ p_msg_body->header.len = sizeof(*p_msg_body) + ppt_msg_len; \
+ } while (0)
+
#define PREPARE_HAL_BUF(send_buf, msg_body) \
do {\
memset(send_buf, 0, msg_body.header.len); \
memcpy(send_buf, _body, sizeof(msg_body)); \
} while (0) \
+#define PREPARE_HAL_PTT_MSG_BUF(send_buf, p_msg_body) \
+ do {\
+ memset(send_buf, 0, p_msg_body->header.len); \
+ memcpy(send_buf, p_msg_body, p_msg_body->header.len); \
+ } while (0)
+
static int wcn36xx_smd_rsp_status_check(void *buf, size_t len)
{
struct wcn
[PATCH] wcn36xx: Add support for Factory Test Mode (FTM)
From: Eyal Ilsar
Introduce infrastructure for supporting Factory Test Mode (FTM) of the
wireless LAN subsystem. In order for the user space to access the
firmware in test mode the relevant netlink channel needs to be exposed
from the kernel driver.
The above is achieved as follows:
1) Register wcn36xx driver to testmode callback from netlink
2) Add testmode callback implementation to handle incoming FTM commands
3) Add FTM command packet structure
4) Add handling for GET_BUILD_RELEASE_NUMBER (msgid=0x32A2)
5) Add generic handling for all PTT_MSG packets
Signed-off-by: Eyal Ilsar
Signed-off-by: Ramon Fried
---
drivers/net/wireless/ath/wcn36xx/Makefile | 2 +
drivers/net/wireless/ath/wcn36xx/hal.h| 16 ++
drivers/net/wireless/ath/wcn36xx/main.c | 3 +
drivers/net/wireless/ath/wcn36xx/smd.c| 74 +
drivers/net/wireless/ath/wcn36xx/smd.h| 4 +
drivers/net/wireless/ath/wcn36xx/testmode.c | 151 ++
drivers/net/wireless/ath/wcn36xx/testmode.h | 46 ++
drivers/net/wireless/ath/wcn36xx/testmode_i.h | 29
drivers/net/wireless/ath/wcn36xx/wcn36xx.h| 2 +
9 files changed, 327 insertions(+)
create mode 100644 drivers/net/wireless/ath/wcn36xx/testmode.c
create mode 100644 drivers/net/wireless/ath/wcn36xx/testmode.h
create mode 100644 drivers/net/wireless/ath/wcn36xx/testmode_i.h
diff --git a/drivers/net/wireless/ath/wcn36xx/Makefile
b/drivers/net/wireless/ath/wcn36xx/Makefile
index 3b09435104eb..582049f65735 100644
--- a/drivers/net/wireless/ath/wcn36xx/Makefile
+++ b/drivers/net/wireless/ath/wcn36xx/Makefile
@@ -6,3 +6,5 @@ wcn36xx-y += main.o \
smd.o \
pmc.o \
debug.o
+
+wcn36xx-$(CONFIG_NL80211_TESTMODE) += testmode.o
diff --git a/drivers/net/wireless/ath/wcn36xx/hal.h
b/drivers/net/wireless/ath/wcn36xx/hal.h
index 182963522941..8491b3cb3206 100644
--- a/drivers/net/wireless/ath/wcn36xx/hal.h
+++ b/drivers/net/wireless/ath/wcn36xx/hal.h
@@ -2230,6 +2230,22 @@ struct wcn36xx_hal_switch_channel_rsp_msg {
} __packed;
+struct wcn36xx_hal_process_ptt_msg_req_msg {
+ struct wcn36xx_hal_msg_header header;
+
+ /* Actual FTM Command body */
+ u8 ptt_msg[0];
+} __packed;
+
+struct wcn36xx_hal_process_ptt_msg_rsp_msg {
+ struct wcn36xx_hal_msg_header header;
+
+ /* FTM Command response status */
+ u32 ptt_msg_resp_status;
+ /* Actual FTM Command body */
+ u8 ptt_msg[0];
+} __packed;
+
struct update_edca_params_req_msg {
struct wcn36xx_hal_msg_header header;
diff --git a/drivers/net/wireless/ath/wcn36xx/main.c
b/drivers/net/wireless/ath/wcn36xx/main.c
index 69d6be59d97f..ea14f87d11ff 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -26,6 +26,7 @@
#include
#include
#include "wcn36xx.h"
+#include "testmode.h"
unsigned int wcn36xx_dbg_mask;
module_param_named(debug_mask, wcn36xx_dbg_mask, uint, 0644);
@@ -1116,6 +1117,8 @@ static const struct ieee80211_ops wcn36xx_ops = {
.sta_add= wcn36xx_sta_add,
.sta_remove = wcn36xx_sta_remove,
.ampdu_action = wcn36xx_ampdu_action,
+
+ CFG80211_TESTMODE_CMD(wcn36xx_tm_cmd)
};
static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c
b/drivers/net/wireless/ath/wcn36xx/smd.c
index 8932af5e4d8d..8eaf192f8bdb 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.c
+++ b/drivers/net/wireless/ath/wcn36xx/smd.c
@@ -292,12 +292,26 @@ static void init_hal_msg(struct wcn36xx_hal_msg_header
*hdr,
msg_body.header.len = sizeof(msg_body); \
} while (0) \
+#define INIT_HAL_PTT_MSG(p_msg_body, ppt_msg_len) \
+ do { \
+ memset(p_msg_body, 0, sizeof(*p_msg_body) + ppt_msg_len); \
+ p_msg_body->header.msg_type = WCN36XX_HAL_PROCESS_PTT_REQ; \
+ p_msg_body->header.msg_version = WCN36XX_HAL_MSG_VERSION0; \
+ p_msg_body->header.len = sizeof(*p_msg_body) + ppt_msg_len; \
+ } while (0)
+
#define PREPARE_HAL_BUF(send_buf, msg_body) \
do {\
memset(send_buf, 0, msg_body.header.len); \
memcpy(send_buf, _body, sizeof(msg_body)); \
} while (0) \
+#define PREPARE_HAL_PTT_MSG_BUF(send_buf, p_msg_body) \
+ do {\
+ memset(send_buf, 0, p_msg_body->header.len); \
+ memcpy(send_buf, p_msg_body, p_msg_body->header.len); \
+ } while (0)
+
static int wcn36xx_smd_rsp_status_check(void *buf, size_t len)
{
struct wcn36xx_fw_msg_status_rsp *rsp;
@@ -741,6 +755,64 @@ int wcn36xx_smd_switch_channel(stru
Re: [PATCH v2] wcn36xx: Disable 5GHz for wcn3610
(adding Bjorn Andersson)
On 3/29/2018 10:15 AM, Kalle Valo wrote:
> (adding devicetree list)
>
> Ramon Fried <rfr...@codeaurora.org> writes:
>
>> wcn3610 can only operate on 2.4GHz band due to RF limitation.
>> If wcn36xx digital block is associated with an external IRIS
>> RF module, retrieve the id and disable 5GHz band in case of
>> wcn3610 id.
>>
>> Signed-off-by: Ramon Fried <rfr...@codeaurora.org>
>> ---
>> v2: fixed wrong assignment, which is logically introduces the
>> same behaviour, but for correctness.
>>
>> drivers/net/wireless/ath/wcn36xx/main.c| 4 +++-
>> drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 1 +
>> 2 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/ath/wcn36xx/main.c
>> b/drivers/net/wireless/ath/wcn36xx/main.c
>> index ab5be6d2c691..833531a68c95 100644
>> --- a/drivers/net/wireless/ath/wcn36xx/main.c
>> +++ b/drivers/net/wireless/ath/wcn36xx/main.c
>> @@ -1146,7 +1146,7 @@ static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
>> BIT(NL80211_IFTYPE_MESH_POINT);
>>
>> wcn->hw->wiphy->bands[NL80211_BAND_2GHZ] = _band_2ghz;
>> -if (wcn->rf_id != RF_IRIS_WCN3620)
>> +if (wcn->rf_id != RF_IRIS_WCN3610 && wcn->rf_id != RF_IRIS_WCN3620)
>> wcn->hw->wiphy->bands[NL80211_BAND_5GHZ] = _band_5ghz;
>>
>> wcn->hw->wiphy->max_scan_ssids = WCN36XX_MAX_SCAN_SSIDS;
>> @@ -1248,6 +1248,8 @@ static int wcn36xx_platform_get_resources(struct
>> wcn36xx *wcn,
>> if (iris_node) {
>> if (of_device_is_compatible(iris_node, "qcom,wcn3620"))
>> wcn->rf_id = RF_IRIS_WCN3620;
>> +else if (of_device_is_compatible(iris_node, "qcom,wcn3610"))
>> +wcn->rf_id = RF_IRIS_WCN3610;
>> of_node_put(iris_node);
>> }
> Should we document qcom,wcn3610 just like wcn3620 is:
>
> Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt:
> "qcom,wcn3620",
IMHO the mentioned bindings is related to the PIL (peripheral image loaded)
which is just the firmware part and has
nothing to do with wifi frontend(IRIS).
Re: [PATCH v2] wcn36xx: Disable 5GHz for wcn3610
(adding Bjorn Andersson)
On 3/29/2018 10:15 AM, Kalle Valo wrote:
> (adding devicetree list)
>
> Ramon Fried writes:
>
>> wcn3610 can only operate on 2.4GHz band due to RF limitation.
>> If wcn36xx digital block is associated with an external IRIS
>> RF module, retrieve the id and disable 5GHz band in case of
>> wcn3610 id.
>>
>> Signed-off-by: Ramon Fried
>> ---
>> v2: fixed wrong assignment, which is logically introduces the
>> same behaviour, but for correctness.
>>
>> drivers/net/wireless/ath/wcn36xx/main.c| 4 +++-
>> drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 1 +
>> 2 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/ath/wcn36xx/main.c
>> b/drivers/net/wireless/ath/wcn36xx/main.c
>> index ab5be6d2c691..833531a68c95 100644
>> --- a/drivers/net/wireless/ath/wcn36xx/main.c
>> +++ b/drivers/net/wireless/ath/wcn36xx/main.c
>> @@ -1146,7 +1146,7 @@ static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
>> BIT(NL80211_IFTYPE_MESH_POINT);
>>
>> wcn->hw->wiphy->bands[NL80211_BAND_2GHZ] = _band_2ghz;
>> -if (wcn->rf_id != RF_IRIS_WCN3620)
>> +if (wcn->rf_id != RF_IRIS_WCN3610 && wcn->rf_id != RF_IRIS_WCN3620)
>> wcn->hw->wiphy->bands[NL80211_BAND_5GHZ] = _band_5ghz;
>>
>> wcn->hw->wiphy->max_scan_ssids = WCN36XX_MAX_SCAN_SSIDS;
>> @@ -1248,6 +1248,8 @@ static int wcn36xx_platform_get_resources(struct
>> wcn36xx *wcn,
>> if (iris_node) {
>> if (of_device_is_compatible(iris_node, "qcom,wcn3620"))
>> wcn->rf_id = RF_IRIS_WCN3620;
>> +else if (of_device_is_compatible(iris_node, "qcom,wcn3610"))
>> +wcn->rf_id = RF_IRIS_WCN3610;
>> of_node_put(iris_node);
>> }
> Should we document qcom,wcn3610 just like wcn3620 is:
>
> Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt:
> "qcom,wcn3620",
IMHO the mentioned bindings is related to the PIL (peripheral image loaded)
which is just the firmware part and has
nothing to do with wifi frontend(IRIS).
Re: [PATCH] wcn36xx: Disable 5GHz for wcn3610
On 3/29/2018 9:58 AM, Rafał Miłecki wrote:
> On 03/29/2018 08:20 AM, Ramon Fried wrote:
>> wcn3610 can only operate on 2.4GHz band due to RF limitation.
>> If wcn36xx digital block is associated with an external IRIS
>> RF module, retrieve the id and disable 5GHz band in case of
>> wcn3610 id.
>>
>> Signed-off-by: Ramon Fried <rfr...@codeaurora.org>
>> ---
>> drivers/net/wireless/ath/wcn36xx/main.c | 4 +++-
>> drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 1 +
>> 2 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/ath/wcn36xx/main.c
>> b/drivers/net/wireless/ath/wcn36xx/main.c
>> index ab5be6d2c691..833531a68c95 100644
>> --- a/drivers/net/wireless/ath/wcn36xx/main.c
>> +++ b/drivers/net/wireless/ath/wcn36xx/main.c
>> @@ -1146,7 +1146,7 @@ static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
>> BIT(NL80211_IFTYPE_MESH_POINT);
>>
>> wcn->hw->wiphy->bands[NL80211_BAND_2GHZ] = _band_2ghz;
>> - if (wcn->rf_id != RF_IRIS_WCN3620)
>> + if (wcn->rf_id != RF_IRIS_WCN3610 && wcn->rf_id != RF_IRIS_WCN3620)
>> wcn->hw->wiphy->bands[NL80211_BAND_5GHZ] = _band_5ghz;
>>
>> wcn->hw->wiphy->max_scan_ssids = WCN36XX_MAX_SCAN_SSIDS;
>> @@ -1248,6 +1248,8 @@ static int wcn36xx_platform_get_resources(struct
>> wcn36xx *wcn,
>> if (iris_node) {
>> if (of_device_is_compatible(iris_node, "qcom,wcn3620"))
>> wcn->rf_id = RF_IRIS_WCN3620;
>> + else if (of_device_is_compatible(iris_node, "qcom,wcn3610"))
>> + wcn->rf_id = RF_IRIS_WCN3620;
>
> RF_IRIS_WCN3610 ?
You're correct. I also noticed just now.
Sent v2. Thanks.
>
> ___
> wcn36xx mailing list
> wcn3...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/wcn36xx
Re: [PATCH] wcn36xx: Disable 5GHz for wcn3610
On 3/29/2018 9:58 AM, Rafał Miłecki wrote:
> On 03/29/2018 08:20 AM, Ramon Fried wrote:
>> wcn3610 can only operate on 2.4GHz band due to RF limitation.
>> If wcn36xx digital block is associated with an external IRIS
>> RF module, retrieve the id and disable 5GHz band in case of
>> wcn3610 id.
>>
>> Signed-off-by: Ramon Fried
>> ---
>> drivers/net/wireless/ath/wcn36xx/main.c | 4 +++-
>> drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 1 +
>> 2 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/ath/wcn36xx/main.c
>> b/drivers/net/wireless/ath/wcn36xx/main.c
>> index ab5be6d2c691..833531a68c95 100644
>> --- a/drivers/net/wireless/ath/wcn36xx/main.c
>> +++ b/drivers/net/wireless/ath/wcn36xx/main.c
>> @@ -1146,7 +1146,7 @@ static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
>> BIT(NL80211_IFTYPE_MESH_POINT);
>>
>> wcn->hw->wiphy->bands[NL80211_BAND_2GHZ] = _band_2ghz;
>> - if (wcn->rf_id != RF_IRIS_WCN3620)
>> + if (wcn->rf_id != RF_IRIS_WCN3610 && wcn->rf_id != RF_IRIS_WCN3620)
>> wcn->hw->wiphy->bands[NL80211_BAND_5GHZ] = _band_5ghz;
>>
>> wcn->hw->wiphy->max_scan_ssids = WCN36XX_MAX_SCAN_SSIDS;
>> @@ -1248,6 +1248,8 @@ static int wcn36xx_platform_get_resources(struct
>> wcn36xx *wcn,
>> if (iris_node) {
>> if (of_device_is_compatible(iris_node, "qcom,wcn3620"))
>> wcn->rf_id = RF_IRIS_WCN3620;
>> + else if (of_device_is_compatible(iris_node, "qcom,wcn3610"))
>> + wcn->rf_id = RF_IRIS_WCN3620;
>
> RF_IRIS_WCN3610 ?
You're correct. I also noticed just now.
Sent v2. Thanks.
>
> ___
> wcn36xx mailing list
> wcn3...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/wcn36xx
[PATCH v2] wcn36xx: Disable 5GHz for wcn3610
wcn3610 can only operate on 2.4GHz band due to RF limitation.
If wcn36xx digital block is associated with an external IRIS
RF module, retrieve the id and disable 5GHz band in case of
wcn3610 id.
Signed-off-by: Ramon Fried <rfr...@codeaurora.org>
---
v2: fixed wrong assignment, which is logically introduces the
same behaviour, but for correctness.
drivers/net/wireless/ath/wcn36xx/main.c| 4 +++-
drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/wcn36xx/main.c
b/drivers/net/wireless/ath/wcn36xx/main.c
index ab5be6d2c691..833531a68c95 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -1146,7 +1146,7 @@ static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
BIT(NL80211_IFTYPE_MESH_POINT);
wcn->hw->wiphy->bands[NL80211_BAND_2GHZ] = _band_2ghz;
- if (wcn->rf_id != RF_IRIS_WCN3620)
+ if (wcn->rf_id != RF_IRIS_WCN3610 && wcn->rf_id != RF_IRIS_WCN3620)
wcn->hw->wiphy->bands[NL80211_BAND_5GHZ] = _band_5ghz;
wcn->hw->wiphy->max_scan_ssids = WCN36XX_MAX_SCAN_SSIDS;
@@ -1248,6 +1248,8 @@ static int wcn36xx_platform_get_resources(struct wcn36xx
*wcn,
if (iris_node) {
if (of_device_is_compatible(iris_node, "qcom,wcn3620"))
wcn->rf_id = RF_IRIS_WCN3620;
+ else if (of_device_is_compatible(iris_node, "qcom,wcn3610"))
+ wcn->rf_id = RF_IRIS_WCN3610;
of_node_put(iris_node);
}
diff --git a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
index 81017e6703b4..bc4d1a10d90e 100644
--- a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
+++ b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
@@ -95,6 +95,7 @@ enum wcn36xx_ampdu_state {
#define WCN36XX_MAX_POWER(__wcn) (__wcn->hw->conf.chandef.chan->max_power)
#define RF_UNKNOWN 0x
+#define RF_IRIS_WCN36100x3610
#define RF_IRIS_WCN36200x3620
static inline void buff_to_be(u32 *buf, size_t len)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v2] wcn36xx: Disable 5GHz for wcn3610
wcn3610 can only operate on 2.4GHz band due to RF limitation.
If wcn36xx digital block is associated with an external IRIS
RF module, retrieve the id and disable 5GHz band in case of
wcn3610 id.
Signed-off-by: Ramon Fried
---
v2: fixed wrong assignment, which is logically introduces the
same behaviour, but for correctness.
drivers/net/wireless/ath/wcn36xx/main.c| 4 +++-
drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/wcn36xx/main.c
b/drivers/net/wireless/ath/wcn36xx/main.c
index ab5be6d2c691..833531a68c95 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -1146,7 +1146,7 @@ static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
BIT(NL80211_IFTYPE_MESH_POINT);
wcn->hw->wiphy->bands[NL80211_BAND_2GHZ] = _band_2ghz;
- if (wcn->rf_id != RF_IRIS_WCN3620)
+ if (wcn->rf_id != RF_IRIS_WCN3610 && wcn->rf_id != RF_IRIS_WCN3620)
wcn->hw->wiphy->bands[NL80211_BAND_5GHZ] = _band_5ghz;
wcn->hw->wiphy->max_scan_ssids = WCN36XX_MAX_SCAN_SSIDS;
@@ -1248,6 +1248,8 @@ static int wcn36xx_platform_get_resources(struct wcn36xx
*wcn,
if (iris_node) {
if (of_device_is_compatible(iris_node, "qcom,wcn3620"))
wcn->rf_id = RF_IRIS_WCN3620;
+ else if (of_device_is_compatible(iris_node, "qcom,wcn3610"))
+ wcn->rf_id = RF_IRIS_WCN3610;
of_node_put(iris_node);
}
diff --git a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
index 81017e6703b4..bc4d1a10d90e 100644
--- a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
+++ b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
@@ -95,6 +95,7 @@ enum wcn36xx_ampdu_state {
#define WCN36XX_MAX_POWER(__wcn) (__wcn->hw->conf.chandef.chan->max_power)
#define RF_UNKNOWN 0x
+#define RF_IRIS_WCN36100x3610
#define RF_IRIS_WCN36200x3620
static inline void buff_to_be(u32 *buf, size_t len)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH] wcn36xx: Disable 5GHz for wcn3610
wcn3610 can only operate on 2.4GHz band due to RF limitation.
If wcn36xx digital block is associated with an external IRIS
RF module, retrieve the id and disable 5GHz band in case of
wcn3610 id.
Signed-off-by: Ramon Fried <rfr...@codeaurora.org>
---
drivers/net/wireless/ath/wcn36xx/main.c| 4 +++-
drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/wcn36xx/main.c
b/drivers/net/wireless/ath/wcn36xx/main.c
index ab5be6d2c691..833531a68c95 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -1146,7 +1146,7 @@ static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
BIT(NL80211_IFTYPE_MESH_POINT);
wcn->hw->wiphy->bands[NL80211_BAND_2GHZ] = _band_2ghz;
- if (wcn->rf_id != RF_IRIS_WCN3620)
+ if (wcn->rf_id != RF_IRIS_WCN3610 && wcn->rf_id != RF_IRIS_WCN3620)
wcn->hw->wiphy->bands[NL80211_BAND_5GHZ] = _band_5ghz;
wcn->hw->wiphy->max_scan_ssids = WCN36XX_MAX_SCAN_SSIDS;
@@ -1248,6 +1248,8 @@ static int wcn36xx_platform_get_resources(struct wcn36xx
*wcn,
if (iris_node) {
if (of_device_is_compatible(iris_node, "qcom,wcn3620"))
wcn->rf_id = RF_IRIS_WCN3620;
+ else if (of_device_is_compatible(iris_node, "qcom,wcn3610"))
+ wcn->rf_id = RF_IRIS_WCN3620;
of_node_put(iris_node);
}
diff --git a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
index 81017e6703b4..bc4d1a10d90e 100644
--- a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
+++ b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
@@ -95,6 +95,7 @@ enum wcn36xx_ampdu_state {
#define WCN36XX_MAX_POWER(__wcn) (__wcn->hw->conf.chandef.chan->max_power)
#define RF_UNKNOWN 0x
+#define RF_IRIS_WCN36100x3610
#define RF_IRIS_WCN36200x3620
static inline void buff_to_be(u32 *buf, size_t len)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH] wcn36xx: Disable 5GHz for wcn3610
wcn3610 can only operate on 2.4GHz band due to RF limitation.
If wcn36xx digital block is associated with an external IRIS
RF module, retrieve the id and disable 5GHz band in case of
wcn3610 id.
Signed-off-by: Ramon Fried
---
drivers/net/wireless/ath/wcn36xx/main.c| 4 +++-
drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/wcn36xx/main.c
b/drivers/net/wireless/ath/wcn36xx/main.c
index ab5be6d2c691..833531a68c95 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -1146,7 +1146,7 @@ static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
BIT(NL80211_IFTYPE_MESH_POINT);
wcn->hw->wiphy->bands[NL80211_BAND_2GHZ] = _band_2ghz;
- if (wcn->rf_id != RF_IRIS_WCN3620)
+ if (wcn->rf_id != RF_IRIS_WCN3610 && wcn->rf_id != RF_IRIS_WCN3620)
wcn->hw->wiphy->bands[NL80211_BAND_5GHZ] = _band_5ghz;
wcn->hw->wiphy->max_scan_ssids = WCN36XX_MAX_SCAN_SSIDS;
@@ -1248,6 +1248,8 @@ static int wcn36xx_platform_get_resources(struct wcn36xx
*wcn,
if (iris_node) {
if (of_device_is_compatible(iris_node, "qcom,wcn3620"))
wcn->rf_id = RF_IRIS_WCN3620;
+ else if (of_device_is_compatible(iris_node, "qcom,wcn3610"))
+ wcn->rf_id = RF_IRIS_WCN3620;
of_node_put(iris_node);
}
diff --git a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
index 81017e6703b4..bc4d1a10d90e 100644
--- a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
+++ b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
@@ -95,6 +95,7 @@ enum wcn36xx_ampdu_state {
#define WCN36XX_MAX_POWER(__wcn) (__wcn->hw->conf.chandef.chan->max_power)
#define RF_UNKNOWN 0x
+#define RF_IRIS_WCN36100x3610
#define RF_IRIS_WCN36200x3620
static inline void buff_to_be(u32 *buf, size_t len)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v3] qrtr: add MODULE_ALIAS macro to smd
Added MODULE_ALIAS("rpmsg:IPCRTR") to ensure qrtr-smd and qrtr will load
when IPCRTR channel is detected.
Signed-off-by: Ramon Fried <rfr...@codeaurora.org>
---
V2: Corrected subject line, this is not a part of a patchset.
V3: Placed the changelog under the ---.
net/qrtr/smd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/qrtr/smd.c b/net/qrtr/smd.c
index 50615d5efac1..9cf089b9754e 100644
--- a/net/qrtr/smd.c
+++ b/net/qrtr/smd.c
@@ -114,5 +114,6 @@ static struct rpmsg_driver qcom_smd_qrtr_driver = {
module_rpmsg_driver(qcom_smd_qrtr_driver);
+MODULE_ALIAS("rpmsg:IPCRTR");
MODULE_DESCRIPTION("Qualcomm IPC-Router SMD interface driver");
MODULE_LICENSE("GPL v2");
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v3] qrtr: add MODULE_ALIAS macro to smd
Added MODULE_ALIAS("rpmsg:IPCRTR") to ensure qrtr-smd and qrtr will load
when IPCRTR channel is detected.
Signed-off-by: Ramon Fried
---
V2: Corrected subject line, this is not a part of a patchset.
V3: Placed the changelog under the ---.
net/qrtr/smd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/qrtr/smd.c b/net/qrtr/smd.c
index 50615d5efac1..9cf089b9754e 100644
--- a/net/qrtr/smd.c
+++ b/net/qrtr/smd.c
@@ -114,5 +114,6 @@ static struct rpmsg_driver qcom_smd_qrtr_driver = {
module_rpmsg_driver(qcom_smd_qrtr_driver);
+MODULE_ALIAS("rpmsg:IPCRTR");
MODULE_DESCRIPTION("Qualcomm IPC-Router SMD interface driver");
MODULE_LICENSE("GPL v2");
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v2] qrtr: add MODULE_ALIAS macro to smd
Added MODULE_ALIAS("rpmsg:IPCRTR") to ensure qrtr-smd and qrtr will load
when IPCRTR channel is detected.
Signed-off-by: Ramon Fried <rfr...@codeaurora.org>
V2: Corrected subject line, this is not a part of a patchset.
---
net/qrtr/smd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/qrtr/smd.c b/net/qrtr/smd.c
index 50615d5efac1..9cf089b9754e 100644
--- a/net/qrtr/smd.c
+++ b/net/qrtr/smd.c
@@ -114,5 +114,6 @@ static struct rpmsg_driver qcom_smd_qrtr_driver = {
module_rpmsg_driver(qcom_smd_qrtr_driver);
+MODULE_ALIAS("rpmsg:IPCRTR");
MODULE_DESCRIPTION("Qualcomm IPC-Router SMD interface driver");
MODULE_LICENSE("GPL v2");
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v2] qrtr: add MODULE_ALIAS macro to smd
Added MODULE_ALIAS("rpmsg:IPCRTR") to ensure qrtr-smd and qrtr will load
when IPCRTR channel is detected.
Signed-off-by: Ramon Fried
V2: Corrected subject line, this is not a part of a patchset.
---
net/qrtr/smd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/qrtr/smd.c b/net/qrtr/smd.c
index 50615d5efac1..9cf089b9754e 100644
--- a/net/qrtr/smd.c
+++ b/net/qrtr/smd.c
@@ -114,5 +114,6 @@ static struct rpmsg_driver qcom_smd_qrtr_driver = {
module_rpmsg_driver(qcom_smd_qrtr_driver);
+MODULE_ALIAS("rpmsg:IPCRTR");
MODULE_DESCRIPTION("Qualcomm IPC-Router SMD interface driver");
MODULE_LICENSE("GPL v2");
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH 1/6] qrtr: add MODULE_ALIAS macro to smd
Added MODULE_ALIAS("rpmsg:IPCRTR") to ensure qrtr-smd and qrtr will load
when IPCRTR channel is detected.
Signed-off-by: Ramon Fried <rfr...@codeaurora.org>
---
net/qrtr/smd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/qrtr/smd.c b/net/qrtr/smd.c
index 50615d5efac1..9cf089b9754e 100644
--- a/net/qrtr/smd.c
+++ b/net/qrtr/smd.c
@@ -114,5 +114,6 @@ static struct rpmsg_driver qcom_smd_qrtr_driver = {
module_rpmsg_driver(qcom_smd_qrtr_driver);
+MODULE_ALIAS("rpmsg:IPCRTR");
MODULE_DESCRIPTION("Qualcomm IPC-Router SMD interface driver");
MODULE_LICENSE("GPL v2");
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH 1/6] qrtr: add MODULE_ALIAS macro to smd
Added MODULE_ALIAS("rpmsg:IPCRTR") to ensure qrtr-smd and qrtr will load
when IPCRTR channel is detected.
Signed-off-by: Ramon Fried
---
net/qrtr/smd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/qrtr/smd.c b/net/qrtr/smd.c
index 50615d5efac1..9cf089b9754e 100644
--- a/net/qrtr/smd.c
+++ b/net/qrtr/smd.c
@@ -114,5 +114,6 @@ static struct rpmsg_driver qcom_smd_qrtr_driver = {
module_rpmsg_driver(qcom_smd_qrtr_driver);
+MODULE_ALIAS("rpmsg:IPCRTR");
MODULE_DESCRIPTION("Qualcomm IPC-Router SMD interface driver");
MODULE_LICENSE("GPL v2");
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH] wcn36xx: Set BTLE coexistence related configuration values to defaults
From: Eyal Ilsar <eil...@codeaurora.org>
If the value for the firmware configuration parameters BTC_STATIC_LEN_LE_BT
and BTC_STATIC_LEN_LE_WLAN are not set the duty cycle between BT and WLAN
is such that if BT (including BLE) is active WLAN gets 0 bandwidth.
When tuning these parameters having a too high value for WLAN means that BLE
performance degrades.
The "sweet" point of roughly half of the maximal values was empirically found
to achieve
a balance between BLE and Wi-Fi coexistence performance.
Signed-off-by: Eyal Ilsar <eil...@codeaurora.org>
Signed-off-by: Ramon Fried <rfr...@codeaurora.org>
---
drivers/net/wireless/ath/wcn36xx/smd.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c
b/drivers/net/wireless/ath/wcn36xx/smd.c
index 9c6590d..1c75987 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.c
+++ b/drivers/net/wireless/ath/wcn36xx/smd.c
@@ -72,8 +72,10 @@ struct wcn36xx_cfg_val {
WCN36XX_CFG_VAL(DYNAMIC_PS_POLL_VALUE, 0),
WCN36XX_CFG_VAL(TX_PWR_CTRL_ENABLE, 1),
WCN36XX_CFG_VAL(ENABLE_CLOSE_LOOP, 1),
- WCN36XX_CFG_VAL(ENABLE_LPWR_IMG_TRANSITION, 0),
+ WCN36XX_CFG_VAL(BTC_STATIC_LEN_LE_BT, 12),
+ WCN36XX_CFG_VAL(BTC_STATIC_LEN_LE_WLAN, 3),
WCN36XX_CFG_VAL(MAX_ASSOC_LIMIT, 10),
+ WCN36XX_CFG_VAL(ENABLE_LPWR_IMG_TRANSITION, 0),
WCN36XX_CFG_VAL(ENABLE_MCC_ADAPTIVE_SCHEDULER, 0),
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH] wcn36xx: Set BTLE coexistence related configuration values to defaults
From: Eyal Ilsar
If the value for the firmware configuration parameters BTC_STATIC_LEN_LE_BT
and BTC_STATIC_LEN_LE_WLAN are not set the duty cycle between BT and WLAN
is such that if BT (including BLE) is active WLAN gets 0 bandwidth.
When tuning these parameters having a too high value for WLAN means that BLE
performance degrades.
The "sweet" point of roughly half of the maximal values was empirically found
to achieve
a balance between BLE and Wi-Fi coexistence performance.
Signed-off-by: Eyal Ilsar
Signed-off-by: Ramon Fried
---
drivers/net/wireless/ath/wcn36xx/smd.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c
b/drivers/net/wireless/ath/wcn36xx/smd.c
index 9c6590d..1c75987 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.c
+++ b/drivers/net/wireless/ath/wcn36xx/smd.c
@@ -72,8 +72,10 @@ struct wcn36xx_cfg_val {
WCN36XX_CFG_VAL(DYNAMIC_PS_POLL_VALUE, 0),
WCN36XX_CFG_VAL(TX_PWR_CTRL_ENABLE, 1),
WCN36XX_CFG_VAL(ENABLE_CLOSE_LOOP, 1),
- WCN36XX_CFG_VAL(ENABLE_LPWR_IMG_TRANSITION, 0),
+ WCN36XX_CFG_VAL(BTC_STATIC_LEN_LE_BT, 12),
+ WCN36XX_CFG_VAL(BTC_STATIC_LEN_LE_WLAN, 3),
WCN36XX_CFG_VAL(MAX_ASSOC_LIMIT, 10),
+ WCN36XX_CFG_VAL(ENABLE_LPWR_IMG_TRANSITION, 0),
WCN36XX_CFG_VAL(ENABLE_MCC_ADAPTIVE_SCHEDULER, 0),
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH] wcn36xx: Set BTLE coexistence related configuration values to defaults
From: Eyal Ilsar <eil...@codeaurora.org>
Signed-off-by: Eyal Ilsar <eil...@codeaurora.org>
Signed-off-by: Ramon Fried <rfr...@codeaurora.org>
---
drivers/net/wireless/ath/wcn36xx/main.c | 2 +-
drivers/net/wireless/ath/wcn36xx/smd.c | 4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/wcn36xx/main.c
b/drivers/net/wireless/ath/wcn36xx/main.c
index b83f01d..0d4ed41 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -27,7 +27,7 @@
#include
#include "wcn36xx.h"
-unsigned int wcn36xx_dbg_mask;
+unsigned int wcn36xx_dbg_mask = WCN36XX_DBG_NONE;
module_param_named(debug_mask, wcn36xx_dbg_mask, uint, 0644);
MODULE_PARM_DESC(debug_mask, "Debugging mask");
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c
b/drivers/net/wireless/ath/wcn36xx/smd.c
index 9c6590d..1c75987 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.c
+++ b/drivers/net/wireless/ath/wcn36xx/smd.c
@@ -72,8 +72,10 @@ struct wcn36xx_cfg_val {
WCN36XX_CFG_VAL(DYNAMIC_PS_POLL_VALUE, 0),
WCN36XX_CFG_VAL(TX_PWR_CTRL_ENABLE, 1),
WCN36XX_CFG_VAL(ENABLE_CLOSE_LOOP, 1),
- WCN36XX_CFG_VAL(ENABLE_LPWR_IMG_TRANSITION, 0),
+ WCN36XX_CFG_VAL(BTC_STATIC_LEN_LE_BT, 12),
+ WCN36XX_CFG_VAL(BTC_STATIC_LEN_LE_WLAN, 3),
WCN36XX_CFG_VAL(MAX_ASSOC_LIMIT, 10),
+ WCN36XX_CFG_VAL(ENABLE_LPWR_IMG_TRANSITION, 0),
WCN36XX_CFG_VAL(ENABLE_MCC_ADAPTIVE_SCHEDULER, 0),
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH] wcn36xx: Set BTLE coexistence related configuration values to defaults
From: Eyal Ilsar
Signed-off-by: Eyal Ilsar
Signed-off-by: Ramon Fried
---
drivers/net/wireless/ath/wcn36xx/main.c | 2 +-
drivers/net/wireless/ath/wcn36xx/smd.c | 4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/wcn36xx/main.c
b/drivers/net/wireless/ath/wcn36xx/main.c
index b83f01d..0d4ed41 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -27,7 +27,7 @@
#include
#include "wcn36xx.h"
-unsigned int wcn36xx_dbg_mask;
+unsigned int wcn36xx_dbg_mask = WCN36XX_DBG_NONE;
module_param_named(debug_mask, wcn36xx_dbg_mask, uint, 0644);
MODULE_PARM_DESC(debug_mask, "Debugging mask");
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c
b/drivers/net/wireless/ath/wcn36xx/smd.c
index 9c6590d..1c75987 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.c
+++ b/drivers/net/wireless/ath/wcn36xx/smd.c
@@ -72,8 +72,10 @@ struct wcn36xx_cfg_val {
WCN36XX_CFG_VAL(DYNAMIC_PS_POLL_VALUE, 0),
WCN36XX_CFG_VAL(TX_PWR_CTRL_ENABLE, 1),
WCN36XX_CFG_VAL(ENABLE_CLOSE_LOOP, 1),
- WCN36XX_CFG_VAL(ENABLE_LPWR_IMG_TRANSITION, 0),
+ WCN36XX_CFG_VAL(BTC_STATIC_LEN_LE_BT, 12),
+ WCN36XX_CFG_VAL(BTC_STATIC_LEN_LE_WLAN, 3),
WCN36XX_CFG_VAL(MAX_ASSOC_LIMIT, 10),
+ WCN36XX_CFG_VAL(ENABLE_LPWR_IMG_TRANSITION, 0),
WCN36XX_CFG_VAL(ENABLE_MCC_ADAPTIVE_SCHEDULER, 0),
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
RE: [PATCH] dmaengine: dmatest: Add support for scatter-gather DMA mode
Wow. Thanks a lot !
-Original Message-
From: Kedareswara rao Appana [mailto:appana.durga@xilinx.com]
Sent: Monday, April 25, 2016 11:48 AM
To: vinod.k...@intel.com; dan.j.willi...@intel.com; Ramon Fried
<ramon.fr...@tandemg.com>
Cc: dmaeng...@vger.kernel.org; linux-kernel@vger.kernel.org; Kedareswara rao
Appana <appa...@xilinx.com>
Subject: [PATCH] dmaengine: dmatest: Add support for scatter-gather DMA mode
This patch updates the dmatest client to support scatter-gather dma mode.
Signed-off-by: Kedareswara rao Appana <appa...@xilinx.com>
---
drivers/dma/dmatest.c | 38 --
1 file changed, 36 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c index
b8576fd..6f259d8 100644
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -51,6 +51,14 @@ module_param(iterations, uint, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(iterations,
"Iterations before stopping test (default: infinite)");
+static unsigned int sg_sources = 1;
+module_param(sg_sources, uint, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(sg_sources,
+ "Number of scatter gather buffers (default: 1)"); static
unsigned int
+dmatest = 1; module_param(dmatest, uint, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(dmatest,
+ "dmatest 0-memcpy 1-slave_sg (default: 1)");
static unsigned int xor_sources = 3;
module_param(xor_sources, uint, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(xor_sources, @@ -431,6 +439,8 @@ static int dmatest_func(void
*data)
dev = chan->device;
if (thread->type == DMA_MEMCPY)
src_cnt = dst_cnt = 1;
+ else if (thread->type == DMA_SG)
+ src_cnt = dst_cnt = sg_sources;
else if (thread->type == DMA_XOR) {
/* force odd to ensure dst = src */
src_cnt = min_odd(params->xor_sources | 1, dev->max_xor); @@
-485,6 +495,8 @@ static int dmatest_func(void *data)
dma_addr_t *dsts;
unsigned int src_off, dst_off, len;
u8 align = 0;
+ struct scatterlist tx_sg[src_cnt];
+ struct scatterlist rx_sg[src_cnt];
total_tests++;
@@ -577,10 +589,21 @@ static int dmatest_func(void *data)
um->bidi_cnt++;
}
+ sg_init_table(tx_sg, src_cnt);
+ sg_init_table(rx_sg, dst_cnt);
+ for (i = 0; i < src_cnt; i++) {
+ sg_dma_address(_sg[i]) = srcs[i];
+ sg_dma_address(_sg[i]) = dsts[i] + dst_off;
+ sg_dma_len(_sg[i]) = len;
+ sg_dma_len(_sg[i]) = len;
+ }
if (thread->type == DMA_MEMCPY)
tx = dev->device_prep_dma_memcpy(chan,
dsts[0] + dst_off,
srcs[0], len, flags);
+ else if (thread->type == DMA_SG)
+ tx = dev->device_prep_dma_sg(chan, tx_sg,
+ dst_cnt, rx_sg, src_cnt, flags);
else if (thread->type == DMA_XOR)
tx = dev->device_prep_dma_xor(chan,
dsts[0] + dst_off,
@@ -748,6 +771,8 @@ static int dmatest_add_threads(struct dmatest_info *info,
if (type == DMA_MEMCPY)
op = "copy";
+ else if (type == DMA_SG)
+ op = "sg";
else if (type == DMA_XOR)
op = "xor";
else if (type == DMA_PQ)
@@ -802,8 +827,16 @@ static int dmatest_add_channel(struct dmatest_info *info,
INIT_LIST_HEAD(>threads);
if (dma_has_cap(DMA_MEMCPY, dma_dev->cap_mask)) {
- cnt = dmatest_add_threads(info, dtc, DMA_MEMCPY);
- thread_count += cnt > 0 ? cnt : 0;
+ if (dmatest == 0) {
+ cnt = dmatest_add_threads(info, dtc, DMA_MEMCPY);
+ thread_count += cnt > 0 ? cnt : 0;
+ }
+ }
+ if (dma_has_cap(DMA_SG, dma_dev->cap_mask)) {
+ if (dmatest == 1) {
+ cnt = dmatest_add_threads(info, dtc, DMA_SG);
+ thread_count += cnt > 0 ? cnt : 0;
+ }
}
if (dma_has_cap(DMA_XOR, dma_dev->cap_mask)) {
cnt = dmatest_add_threads(info, dtc, DMA_XOR); @@ -877,6 +910,7
@@ static void run_threaded_test(struct dmatest_info *info)
request_channels(info, DMA_MEMCPY);
request_channels(info, DMA_XOR);
+ request_channels(info, DMA_SG);
request_channels(info, DMA_PQ);
}
--
2.1.2
RE: [PATCH] dmaengine: dmatest: Add support for scatter-gather DMA mode
Wow. Thanks a lot !
-Original Message-
From: Kedareswara rao Appana [mailto:appana.durga@xilinx.com]
Sent: Monday, April 25, 2016 11:48 AM
To: vinod.k...@intel.com; dan.j.willi...@intel.com; Ramon Fried
Cc: dmaeng...@vger.kernel.org; linux-kernel@vger.kernel.org; Kedareswara rao
Appana
Subject: [PATCH] dmaengine: dmatest: Add support for scatter-gather DMA mode
This patch updates the dmatest client to support scatter-gather dma mode.
Signed-off-by: Kedareswara rao Appana
---
drivers/dma/dmatest.c | 38 --
1 file changed, 36 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c index
b8576fd..6f259d8 100644
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -51,6 +51,14 @@ module_param(iterations, uint, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(iterations,
"Iterations before stopping test (default: infinite)");
+static unsigned int sg_sources = 1;
+module_param(sg_sources, uint, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(sg_sources,
+ "Number of scatter gather buffers (default: 1)"); static
unsigned int
+dmatest = 1; module_param(dmatest, uint, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(dmatest,
+ "dmatest 0-memcpy 1-slave_sg (default: 1)");
static unsigned int xor_sources = 3;
module_param(xor_sources, uint, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(xor_sources, @@ -431,6 +439,8 @@ static int dmatest_func(void
*data)
dev = chan->device;
if (thread->type == DMA_MEMCPY)
src_cnt = dst_cnt = 1;
+ else if (thread->type == DMA_SG)
+ src_cnt = dst_cnt = sg_sources;
else if (thread->type == DMA_XOR) {
/* force odd to ensure dst = src */
src_cnt = min_odd(params->xor_sources | 1, dev->max_xor); @@
-485,6 +495,8 @@ static int dmatest_func(void *data)
dma_addr_t *dsts;
unsigned int src_off, dst_off, len;
u8 align = 0;
+ struct scatterlist tx_sg[src_cnt];
+ struct scatterlist rx_sg[src_cnt];
total_tests++;
@@ -577,10 +589,21 @@ static int dmatest_func(void *data)
um->bidi_cnt++;
}
+ sg_init_table(tx_sg, src_cnt);
+ sg_init_table(rx_sg, dst_cnt);
+ for (i = 0; i < src_cnt; i++) {
+ sg_dma_address(_sg[i]) = srcs[i];
+ sg_dma_address(_sg[i]) = dsts[i] + dst_off;
+ sg_dma_len(_sg[i]) = len;
+ sg_dma_len(_sg[i]) = len;
+ }
if (thread->type == DMA_MEMCPY)
tx = dev->device_prep_dma_memcpy(chan,
dsts[0] + dst_off,
srcs[0], len, flags);
+ else if (thread->type == DMA_SG)
+ tx = dev->device_prep_dma_sg(chan, tx_sg,
+ dst_cnt, rx_sg, src_cnt, flags);
else if (thread->type == DMA_XOR)
tx = dev->device_prep_dma_xor(chan,
dsts[0] + dst_off,
@@ -748,6 +771,8 @@ static int dmatest_add_threads(struct dmatest_info *info,
if (type == DMA_MEMCPY)
op = "copy";
+ else if (type == DMA_SG)
+ op = "sg";
else if (type == DMA_XOR)
op = "xor";
else if (type == DMA_PQ)
@@ -802,8 +827,16 @@ static int dmatest_add_channel(struct dmatest_info *info,
INIT_LIST_HEAD(>threads);
if (dma_has_cap(DMA_MEMCPY, dma_dev->cap_mask)) {
- cnt = dmatest_add_threads(info, dtc, DMA_MEMCPY);
- thread_count += cnt > 0 ? cnt : 0;
+ if (dmatest == 0) {
+ cnt = dmatest_add_threads(info, dtc, DMA_MEMCPY);
+ thread_count += cnt > 0 ? cnt : 0;
+ }
+ }
+ if (dma_has_cap(DMA_SG, dma_dev->cap_mask)) {
+ if (dmatest == 1) {
+ cnt = dmatest_add_threads(info, dtc, DMA_SG);
+ thread_count += cnt > 0 ? cnt : 0;
+ }
}
if (dma_has_cap(DMA_XOR, dma_dev->cap_mask)) {
cnt = dmatest_add_threads(info, dtc, DMA_XOR); @@ -877,6 +910,7
@@ static void run_threaded_test(struct dmatest_info *info)
request_channels(info, DMA_MEMCPY);
request_channels(info, DMA_XOR);
+ request_channels(info, DMA_SG);
request_channels(info, DMA_PQ);
}
--
2.1.2
dmatest - scatter gather mode
I'm looking of a way to validate a DMA engine driver I've written. I came across dmatest module and while reading the code I've noticed that scatter-gather DMA mode is not implemented. I wonder if anyone one knows the reason, and if such enhancement will be welcome as a patch. Thanks. Ramon
dmatest - scatter gather mode
I'm looking of a way to validate a DMA engine driver I've written. I came across dmatest module and while reading the code I've noticed that scatter-gather DMA mode is not implemented. I wonder if anyone one knows the reason, and if such enhancement will be welcome as a patch. Thanks. Ramon
[PATCH] staging: lustre: llite_lib.c Set ll_md_setattr function to be static
This fixes the following sparse warning:
llite_lib.c:1240:5: warning: symbol 'll_md_setattr' was not declared. Should it
be static?
Signed-off-by: Ramon Fried
---
drivers/staging/lustre/lustre/llite/llite_lib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/llite/llite_lib.c
b/drivers/staging/lustre/lustre/llite/llite_lib.c
index 59e36b0..a8bcc51 100644
--- a/drivers/staging/lustre/lustre/llite/llite_lib.c
+++ b/drivers/staging/lustre/lustre/llite/llite_lib.c
@@ -1237,7 +1237,7 @@ void ll_clear_inode(struct inode *inode)
lli->lli_has_smd = false;
}
-int ll_md_setattr(struct dentry *dentry, struct md_op_data *op_data,
+static int ll_md_setattr(struct dentry *dentry, struct md_op_data *op_data,
struct md_open_data **mod)
{
struct lustre_md md;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: lustre: llite_lib.c Set ll_md_setattr function to be static
This fixes the following sparse warning:
llite_lib.c:1240:5: warning: symbol 'll_md_setattr' was not declared. Should it
be static?
Signed-off-by: Ramon Fried ramon.fr...@gmail.com
---
drivers/staging/lustre/lustre/llite/llite_lib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/llite/llite_lib.c
b/drivers/staging/lustre/lustre/llite/llite_lib.c
index 59e36b0..a8bcc51 100644
--- a/drivers/staging/lustre/lustre/llite/llite_lib.c
+++ b/drivers/staging/lustre/lustre/llite/llite_lib.c
@@ -1237,7 +1237,7 @@ void ll_clear_inode(struct inode *inode)
lli-lli_has_smd = false;
}
-int ll_md_setattr(struct dentry *dentry, struct md_op_data *op_data,
+static int ll_md_setattr(struct dentry *dentry, struct md_op_data *op_data,
struct md_open_data **mod)
{
struct lustre_md md;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: netlogic: Fix checkpatch.pl warning
This patch fixes the following checkpatch.pl warning:
WARNING: Possible unnecessary 'out of memory' message
#116: FILE: ./xlr_net.c:116:
+ if (!skb) {
+ pr_err("SKB allocation failed\n");
Signed-off-by: Ramon Fried
---
drivers/staging/netlogic/xlr_net.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/staging/netlogic/xlr_net.c
b/drivers/staging/netlogic/xlr_net.c
index f8120fe..3f9c5ad 100644
--- a/drivers/staging/netlogic/xlr_net.c
+++ b/drivers/staging/netlogic/xlr_net.c
@@ -112,10 +112,8 @@ static inline unsigned char *xlr_alloc_skb(void)
/* skb->data is cache aligned */
skb = alloc_skb(XLR_RX_BUF_SIZE, GFP_ATOMIC);
- if (!skb) {
- pr_err("SKB allocation failed\n");
+ if (!skb)
return NULL;
- }
skb_data = skb->data;
skb_put(skb, MAC_SKB_BACK_PTR_SIZE);
skb_pull(skb, MAC_SKB_BACK_PTR_SIZE);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: netlogic: fixed checkpatch.pl styling warnings
Hi Greg
Thanks for your patience. this is the first time I doing it...
I created the patch against linux-next, I will do it again and send it.
Regarding CC's, this is the output of get_maintainer script, how do I
extract the relevant people out of its output ?
Warm regards,
Ramon.
On Sun, Aug 31, 2014 at 3:32 AM, Greg Kroah-Hartman
wrote:
> On Sun, Aug 31, 2014 at 03:16:48AM +0300, Ramon Fried wrote:
>> This patch fixes the following checkpatch.pl warnings:
>>
>> WARNING: Possible unnecessary 'out of memory' message
>> #146: FILE: ./xlr_net.c:146:
>> + if (!skb) {
>> + pr_err("SKB allocation failed\n");
>>
>> WARNING: Missing a blank line after declarations
>> #1107: FILE: ./xlr_net.c:1107:
>> + struct xlr_net_priv *priv = platform_get_drvdata(pdev);
>> + unregister_netdev(priv->ndev);
>>
>> Signed-off-by: Ramon Fried
>
> This is two different things, and as such, should be sent in 2 different
> patches?
>
> Also, you sent this to a lot of people, did they all really need it?
>
>> ---
>> drivers/staging/netlogic/xlr_net.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/staging/netlogic/xlr_net.c
>> b/drivers/staging/netlogic/xlr_net.c
>> index 9bf407d..28a42831 100644
>> --- a/drivers/staging/netlogic/xlr_net.c
>> +++ b/drivers/staging/netlogic/xlr_net.c
>> @@ -142,10 +142,8 @@ static inline struct sk_buff *xlr_alloc_skb(void)
>>
>> /* skb->data is cache aligned */
>> skb = alloc_skb(XLR_RX_BUF_SIZE, GFP_ATOMIC);
>> - if (!skb) {
>> - pr_err("SKB allocation failed\n");
>> + if (!skb)
>> return NULL;
>> - }
>> mac_put_skb_back_ptr(skb);
>> return skb;
>> }
>> @@ -1104,6 +1102,7 @@ err_gmac:
>> static int xlr_net_remove(struct platform_device *pdev)
>> {
>> struct xlr_net_priv *priv = platform_get_drvdata(pdev);
>> +
>> unregister_netdev(priv->ndev);
>> mdiobus_unregister(priv->mii_bus);
>> mdiobus_free(priv->mii_bus);
>
> Finally, this patch doesn't apply at all to my tree, so even if I wanted
> to apply it, I couldn't. Please refresh it against the staging-next
> branch of the staging.git tree on git.kernel.org, and if it is still
> relevant (hint, half of it isn't), then redo it and resend.
>
> thanks,
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: netlogic: fixed checkpatch.pl styling warnings
Hi Greg
Thanks for your patience. this is the first time I doing it...
I created the patch against linux-next, I will do it again and send it.
Regarding CC's, this is the output of get_maintainer script, how do I
extract the relevant people out of its output ?
Warm regards,
Ramon.
On Sun, Aug 31, 2014 at 3:32 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Sun, Aug 31, 2014 at 03:16:48AM +0300, Ramon Fried wrote:
This patch fixes the following checkpatch.pl warnings:
WARNING: Possible unnecessary 'out of memory' message
#146: FILE: ./xlr_net.c:146:
+ if (!skb) {
+ pr_err(SKB allocation failed\n);
WARNING: Missing a blank line after declarations
#1107: FILE: ./xlr_net.c:1107:
+ struct xlr_net_priv *priv = platform_get_drvdata(pdev);
+ unregister_netdev(priv-ndev);
Signed-off-by: Ramon Fried ramon.fr...@gmail.com
This is two different things, and as such, should be sent in 2 different
patches?
Also, you sent this to a lot of people, did they all really need it?
---
drivers/staging/netlogic/xlr_net.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/netlogic/xlr_net.c
b/drivers/staging/netlogic/xlr_net.c
index 9bf407d..28a42831 100644
--- a/drivers/staging/netlogic/xlr_net.c
+++ b/drivers/staging/netlogic/xlr_net.c
@@ -142,10 +142,8 @@ static inline struct sk_buff *xlr_alloc_skb(void)
/* skb-data is cache aligned */
skb = alloc_skb(XLR_RX_BUF_SIZE, GFP_ATOMIC);
- if (!skb) {
- pr_err(SKB allocation failed\n);
+ if (!skb)
return NULL;
- }
mac_put_skb_back_ptr(skb);
return skb;
}
@@ -1104,6 +1102,7 @@ err_gmac:
static int xlr_net_remove(struct platform_device *pdev)
{
struct xlr_net_priv *priv = platform_get_drvdata(pdev);
+
unregister_netdev(priv-ndev);
mdiobus_unregister(priv-mii_bus);
mdiobus_free(priv-mii_bus);
Finally, this patch doesn't apply at all to my tree, so even if I wanted
to apply it, I couldn't. Please refresh it against the staging-next
branch of the staging.git tree on git.kernel.org, and if it is still
relevant (hint, half of it isn't), then redo it and resend.
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: netlogic: Fix checkpatch.pl warning
This patch fixes the following checkpatch.pl warning:
WARNING: Possible unnecessary 'out of memory' message
#116: FILE: ./xlr_net.c:116:
+ if (!skb) {
+ pr_err(SKB allocation failed\n);
Signed-off-by: Ramon Fried ramon.fr...@gmail.com
---
drivers/staging/netlogic/xlr_net.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/staging/netlogic/xlr_net.c
b/drivers/staging/netlogic/xlr_net.c
index f8120fe..3f9c5ad 100644
--- a/drivers/staging/netlogic/xlr_net.c
+++ b/drivers/staging/netlogic/xlr_net.c
@@ -112,10 +112,8 @@ static inline unsigned char *xlr_alloc_skb(void)
/* skb-data is cache aligned */
skb = alloc_skb(XLR_RX_BUF_SIZE, GFP_ATOMIC);
- if (!skb) {
- pr_err(SKB allocation failed\n);
+ if (!skb)
return NULL;
- }
skb_data = skb-data;
skb_put(skb, MAC_SKB_BACK_PTR_SIZE);
skb_pull(skb, MAC_SKB_BACK_PTR_SIZE);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: netlogic: fixed checkpatch.pl styling warnings
This patch fixes the following checkpatch.pl warnings:
WARNING: Possible unnecessary 'out of memory' message
#146: FILE: ./xlr_net.c:146:
+ if (!skb) {
+ pr_err("SKB allocation failed\n");
WARNING: Missing a blank line after declarations
#1107: FILE: ./xlr_net.c:1107:
+ struct xlr_net_priv *priv = platform_get_drvdata(pdev);
+ unregister_netdev(priv->ndev);
Signed-off-by: Ramon Fried
---
drivers/staging/netlogic/xlr_net.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/netlogic/xlr_net.c
b/drivers/staging/netlogic/xlr_net.c
index 9bf407d..28a42831 100644
--- a/drivers/staging/netlogic/xlr_net.c
+++ b/drivers/staging/netlogic/xlr_net.c
@@ -142,10 +142,8 @@ static inline struct sk_buff *xlr_alloc_skb(void)
/* skb->data is cache aligned */
skb = alloc_skb(XLR_RX_BUF_SIZE, GFP_ATOMIC);
- if (!skb) {
- pr_err("SKB allocation failed\n");
+ if (!skb)
return NULL;
- }
mac_put_skb_back_ptr(skb);
return skb;
}
@@ -1104,6 +1102,7 @@ err_gmac:
static int xlr_net_remove(struct platform_device *pdev)
{
struct xlr_net_priv *priv = platform_get_drvdata(pdev);
+
unregister_netdev(priv->ndev);
mdiobus_unregister(priv->mii_bus);
mdiobus_free(priv->mii_bus);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: netlogic: fixed checkpatch.pl styling warnings
This patch fixes the following checkpatch.pl warnings:
WARNING: Possible unnecessary 'out of memory' message
#146: FILE: ./xlr_net.c:146:
+ if (!skb) {
+ pr_err("SKB allocation failed\n");
WARNING: Missing a blank line after declarations
#1107: FILE: ./xlr_net.c:1107:
+ struct xlr_net_priv *priv = platform_get_drvdata(pdev);
+ unregister_netdev(priv->ndev);
>From 27b58d9b1d39ab99bf6022b82ac9e602621b2822 Mon Sep 17 00:00:00 2001
From: Ramon Fried
Date: Sat, 30 Aug 2014 22:26:11 +0300
Subject: [PATCH] staging: netlogic: fixed checkpatch.pl styling warnings
Signed-off-by: Ramon Fried
---
drivers/staging/netlogic/xlr_net.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/netlogic/xlr_net.c b/drivers/staging/netlogic/xlr_net.c
index 9bf407d..28a42831 100644
--- a/drivers/staging/netlogic/xlr_net.c
+++ b/drivers/staging/netlogic/xlr_net.c
@@ -142,10 +142,8 @@ static inline struct sk_buff *xlr_alloc_skb(void)
/* skb->data is cache aligned */
skb = alloc_skb(XLR_RX_BUF_SIZE, GFP_ATOMIC);
- if (!skb) {
- pr_err("SKB allocation failed\n");
+ if (!skb)
return NULL;
- }
mac_put_skb_back_ptr(skb);
return skb;
}
@@ -1104,6 +1102,7 @@ err_gmac:
static int xlr_net_remove(struct platform_device *pdev)
{
struct xlr_net_priv *priv = platform_get_drvdata(pdev);
+
unregister_netdev(priv->ndev);
mdiobus_unregister(priv->mii_bus);
mdiobus_free(priv->mii_bus);
--
1.9.1
[PATCH] staging: netlogic: fixed checkpatch.pl styling warnings
This patch fixes the following checkpatch.pl warnings:
WARNING: Possible unnecessary 'out of memory' message
#146: FILE: ./xlr_net.c:146:
+ if (!skb) {
+ pr_err(SKB allocation failed\n);
WARNING: Missing a blank line after declarations
#1107: FILE: ./xlr_net.c:1107:
+ struct xlr_net_priv *priv = platform_get_drvdata(pdev);
+ unregister_netdev(priv-ndev);
From 27b58d9b1d39ab99bf6022b82ac9e602621b2822 Mon Sep 17 00:00:00 2001
From: Ramon Fried ramon.fr...@gmail.com
Date: Sat, 30 Aug 2014 22:26:11 +0300
Subject: [PATCH] staging: netlogic: fixed checkpatch.pl styling warnings
Signed-off-by: Ramon Fried ramon.fr...@gmail.com
---
drivers/staging/netlogic/xlr_net.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/netlogic/xlr_net.c b/drivers/staging/netlogic/xlr_net.c
index 9bf407d..28a42831 100644
--- a/drivers/staging/netlogic/xlr_net.c
+++ b/drivers/staging/netlogic/xlr_net.c
@@ -142,10 +142,8 @@ static inline struct sk_buff *xlr_alloc_skb(void)
/* skb-data is cache aligned */
skb = alloc_skb(XLR_RX_BUF_SIZE, GFP_ATOMIC);
- if (!skb) {
- pr_err(SKB allocation failed\n);
+ if (!skb)
return NULL;
- }
mac_put_skb_back_ptr(skb);
return skb;
}
@@ -1104,6 +1102,7 @@ err_gmac:
static int xlr_net_remove(struct platform_device *pdev)
{
struct xlr_net_priv *priv = platform_get_drvdata(pdev);
+
unregister_netdev(priv-ndev);
mdiobus_unregister(priv-mii_bus);
mdiobus_free(priv-mii_bus);
--
1.9.1
[PATCH] staging: netlogic: fixed checkpatch.pl styling warnings
This patch fixes the following checkpatch.pl warnings:
WARNING: Possible unnecessary 'out of memory' message
#146: FILE: ./xlr_net.c:146:
+ if (!skb) {
+ pr_err(SKB allocation failed\n);
WARNING: Missing a blank line after declarations
#1107: FILE: ./xlr_net.c:1107:
+ struct xlr_net_priv *priv = platform_get_drvdata(pdev);
+ unregister_netdev(priv-ndev);
Signed-off-by: Ramon Fried ramon.fr...@gmail.com
---
drivers/staging/netlogic/xlr_net.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/netlogic/xlr_net.c
b/drivers/staging/netlogic/xlr_net.c
index 9bf407d..28a42831 100644
--- a/drivers/staging/netlogic/xlr_net.c
+++ b/drivers/staging/netlogic/xlr_net.c
@@ -142,10 +142,8 @@ static inline struct sk_buff *xlr_alloc_skb(void)
/* skb-data is cache aligned */
skb = alloc_skb(XLR_RX_BUF_SIZE, GFP_ATOMIC);
- if (!skb) {
- pr_err(SKB allocation failed\n);
+ if (!skb)
return NULL;
- }
mac_put_skb_back_ptr(skb);
return skb;
}
@@ -1104,6 +1102,7 @@ err_gmac:
static int xlr_net_remove(struct platform_device *pdev)
{
struct xlr_net_priv *priv = platform_get_drvdata(pdev);
+
unregister_netdev(priv-ndev);
mdiobus_unregister(priv-mii_bus);
mdiobus_free(priv-mii_bus);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
