Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

taken a look at the specific code, and from my point of view the code
that sets up the LED (including callback) is so trivial that it's simply
not worth dealing with adding the leds-gpio driver to the mix.
It adds extra complexity and an extra dependency for no reason at all.
There's no extra functionality to be gained by using it.

Stupid question: If the LED driver isn't using the GPIO subsystem
(when enabled), what happens if the user uses the GPIO subsystem to
fiddle with the pin the LED is connected to?


in our case here it can coexist and will not have a negative effect 
since the led will still run. (except if you reconfigure the gpio to input)

for sure it makes no sense.
but however i can block the gpio for beeing reused if the led driver 
took it. this has been made in ath9k for instance.

in ath10k i did not do it, since there is no technical requirement for it.
but that might not be the case for all gpio controllers, so there is no 
generic answer. for ath10k. harmless


Sebastian


Thanks,



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets

[Julian Calaby]

Hi Felix,

On Fri, Mar 9, 2018 at 2:46 AM, Felix Fietkau  wrote:
> On 2018-03-08 15:05, Pavel Machek wrote:
>> On Thu 2018-03-08 13:33:29, Sebastian Gottschall wrote:
>>> Am 08.03.2018 um 10:02 schrieb Pavel Machek:
>>> >On Wed 2018-03-07 18:54:41, Sebastian Gottschall wrote:
>>> >>Am 07.03.2018 um 17:22 schrieb Rafał Miłecki:
>>> >>>On 2 March 2018 at 10:22, Sebastian Gottschall  
>>> >>>wrote:
>>> >>leds-gpio is crap and limited. you can just register one platform 
>>> >>data at
>>> >>kernel runtime since its identified by its object name "led-gpio" but 
>>> >>the
>>> >>kernel forbidds to register 2 platform datas with the same name
>>> >>consider the ar71xx devices with qca988x wifi chipsets. they all have
>>> >>already a led platform data registered
>>> >>at boottime. a second can't be registered anymore so gpio_led is 
>>> >>useless
>>> >>at
>>> >>all for most developers on such platforms. its mainly used for early
>>> >>kernel
>>> >>platform data initialisation for system leds.
>>> >If leds-gpio has limitations, please fix those, rather then
>>> >introducing duplicated code.
>>> there is no duplicated code introduced and there is no solution for it.
>>> consider that all wifi drivers with softled support
>>> are going that way with registering a own led driver. see ath9k for
>>> instance. gpio-led cannot be used for it and there is no way to
>>> support multiple platform datas with the same name. its a kernel 
>>> limitation
>>> >>>I just reviewed some mips arch patch adding support for more LEDs for
>>> >>>selected devices:
>>> >>>[PATCH] MIPS: BCM47XX: Add Luxul XAP1500/XWR1750 WiFi LEDs
>>> >>>https://patchwork.linux-mips.org/patch/18681/
>>> >>>
>>> >>>It seems to be simply adding another call to the
>>> >>>gpio_led_register_device(). It seems to me you can call that function
>>> >>>multiple times and register multiple structs with LEDs.
>>> >>>
>>> >>>Isn't all you need something like this?
>>> >>>
>>> >>>static const struct gpio_led ath10k_leds[] = {
>>> >>> {
>>> >>> .name = "ath10k:color:function",
>>> >>> .active_low = 1,
>>> >>> .default_state = LEDS_GPIO_DEFSTATE_KEEP,
>>> >>> }
>>> >>>};
>>> >>>
>>> >>>static struct gpio_led_platform_data bcm47xx_leds_pdata_extra = {
>>> >>> leds = ath10k_leds;
>>> >>> num_leds = ARRAY_SIZE(ath10k_leds);
>>> >>>};
>>> >>>
>>> >>>ath10k_leds.gpio = ar->hw_params.led_pin;
>>> >>>gpio_led_register_device(0, _leds);
>>> >>the problem are other architectures which have already registered gpio_led
>>> >>at system start like ar71xx
>>> >>you cannot register a second one. so a independend led driver is a
>>> >>requirement for direct control
>>> >If the limitation indeed exists, please fix the limitation rather than
>>> >working around it in each and every driver.
>>> see ath9k. its exact the same implementation.
>>
>> Ok, so one more driver to fix.
>>
>>> in addition my variant does also work without gpiolib support. so it can be
>>> used even if the kernel is configured
>>> without gpio support.
>>> and not to forget, using a own led driver is more ligthweight from the call
>>> path for each led on / off event which is important for
>>> low performance embedded devices
>>
>> We are not going to copy code because such code works without
>> libraries, and we are not going to copy code because that uses
>> less cache during calls. Sorry.
>>
>> NAK. Please fix your patch. Since this discussion seems to have taken a 
>> rather weird turn, I've
> taken a look at the specific code, and from my point of view the code
> that sets up the LED (including callback) is so trivial that it's simply
> not worth dealing with adding the leds-gpio driver to the mix.
> It adds extra complexity and an extra dependency for no reason at all.
> There's no extra functionality to be gained by using it.

Stupid question: If the LED driver isn't using the GPIO subsystem
(when enabled), what happens if the user uses the GPIO subsystem to
fiddle with the pin the LED is connected to?

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

ath10k tx scheduling and detection of preamble

[정승현]

 Hi all, 

I've got two questions.

1. I am trying to transmit an ack after successfully receiving a packet and 
waiting for certain amount of time (might not be SIFS)
Is it possible to schedule tx using ath10k as I want?

2. Can I be notified when the device detects a specific preamble or energy 
absorption?

Thanks,
Chung
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

DMA issues on PowerPC64

[Jared Bents]

Hi all,

Some background information first.  I transitioned a build from 32 bit
to 64 bit and discovered my wifi modules no longer work.  I am using
fsl-v2.0-1703 on a qoriq t1042.  I sourced the problem to DMA mapping
errors and found that it was trying to map addresses in regions not
allowed by the kernel.

ath10k_pci 0001:01:00.0: unable to get target info from device
ath10k_pci 0001:01:00.0: could not get target info (5)
ath10k_pci 0001:01:00.0: could not probe fw (5)


I discovered that if I limited my memory from the actual 8GB present
down to just 2GB with the bootarg mem=2048M, the ath10k modules
worked.

So I started poking around in ath10k/pci.c and noticed that if I ORed
the regions specified in the memory allocations with GFP_DMA, I could
get rid of the initial dma mapping errors.  A couple of examples are
below.

skb = __dev_alloc_skb(pipe->buf_sz, GFP_DMA | GFP_ATOMIC);
treq = kmemdup(req, req_len, GFP_DMA | GFP_KERNEL);


But then came across these failures which I have yet to sort out.

ath10k_pci 0001:01:00.0: failed to connect htt (-5)
ath10k_pci 0001:01:00.0: could not init core (-5)
ath10k_pci 0001:01:00.0: could not probe fw (-5)


I am wondering if anyone else has come across this issue and solved it
or if somehow this is just an issue on ppc64 and I am somehow the only
one in that use case.  Unfortunately because of the qoriq t1042, I am
on the latest kernel I can use via the latest available sdk for my
processor which is linux kernel version 4.1.35-rt41

Thank you,
Jared

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k