Agreed, I am also not a fan of bloat code. I wasn't suggesting you
move it to the .h, just saying that if it were not static, that's how
I'd suggest doing it.
In this case, keep it static, keep it in the .c. And use the blocking
I suggested. You will get the optimizer friendly result you're lo
On Tue, Feb 20, 2018 at 10:06 AM, Sebastian Gottschall
wrote:
> Am 20.02.2018 um 17:52 schrieb Steve deRosier:
>>
>>
>>> +static int ath10k_register_gpio_chip(struct ath10k *ar)
>>> +{
>>> + struct ath10k_gpiocontrol *gpio;
>>> + gpio = kzalloc(sizeof(struct ath10k_gpiocontrol), GFP_KE
Am 20.02.2018 um 17:52 schrieb Steve deRosier:
+static int ath10k_register_gpio_chip(struct ath10k *ar)
+{
+ struct ath10k_gpiocontrol *gpio;
+ gpio = kzalloc(sizeof(struct ath10k_gpiocontrol), GFP_KERNEL);
+ if (!gpio) {
+ return -ENOMEM;
+ }
+
+ snp
Hi Sebastian,
On Mon, Feb 19, 2018 at 11:32 PM, wrote:
> From: Sebastian Gottschall
>
> Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based
> chipsets with on chipset connected led's
> using WMI Firmware API.
> The LED device will get available named as "ath10k-phyX" at sy
+struct ath10k_gpiocontrol {
+ struct ath10k *ar;
+ u32 gpio_set_num, gpio_num, gpio_input, gpio_pull_type,
gpio_intr_mode, gpio_set; /* since we have no gpio read method, these
are the state variables for debugfs. */
I think the checkpatch.pl will complain above defintely.
Best rega
Hi,
On Tue, Feb 20, 2018 at 08:32:59AM +0100, s.gottsch...@dd-wrt.com wrote:
From: Sebastian Gottschall
Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based
chipsets with on chipset connected led's
using WMI Firmware API.
The LED device will get available named as "ath10k-p
From: Sebastian Gottschall
Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based
chipsets with on chipset connected led's
using WMI Firmware API.
The LED device will get available named as "ath10k-phyX" at sysfs and can be
controlled with various triggers.
adds also debugfs i
