Re: [ath9k-devel] [PATCH RFC v3 1/3] Documentation: dt: net: add ath9k wireless device binding

[Julian Calaby]

Hi Martin,

On Fri, Jun 24, 2016 at 10:34 PM, Martin Blumenstingl
 wrote:
> Add documentation how devicetree can be used to configure ath9k based
> devices.
>
> Signed-off-by: Martin Blumenstingl 
> ---
> changes in v2 -> v3:
> - improved wording of the qca,disable-2ghz and qca,disable-5ghz properties
> - replaced qca,eeprom-name with qca,no-eeprom (the eeprom name is now
>   built automatically within ath9k). The naming was chosen to stay
>   consistent with other drivers (such as davicom-dm9000 and via-velocity)
> - added reference to the mac-address and local-mac-address properties
> - removed invalid device_type property from the example
>
>  .../devicetree/bindings/net/wireless/qca,ath9k.txt | 46 
> ++
>  1 file changed, 46 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt 
> b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> new file mode 100644
> index 000..ff83fd4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> @@ -0,0 +1,46 @@
> +* Qualcomm Atheros ath9k wireless devices
> +
> +This node provides properties for configuring the ath9k wireless device. The
> +node is expected to be specified as a child node of the PCI controller to
> +which the wireless chip is connected.
> +
> +Required properties:
> +- compatible: Should be "qca,ath9k"
> +
> +Optional properties:
> +- reg: Address and length of the register set for the device.
> +- qca,gpio-mask: The GPIO mask
> +- qca,gpio-val: The GPIO value
> +- qca,led-pin: The GPIO number to which the LED is connected
> +- qca,led-active-high: The LED is active when the GPIO is HIGH
> +- qca,clk-25mhz: Defines that at 25MHz clock is used
> +- qca,no-eeprom: Indicates that there is on physical EEPROM connected

Typo: ...Indicates that there is _no_ physical EEPROM...

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH RFC v3 3/3] ath9k: parse the device configuration from an OF node

[Martin Blumenstingl]

On Sat, Jun 25, 2016 at 9:26 PM, Christian Lamparter
 wrote:
> The problem with the owl-loader is/was that it sticks around
> when it has initialized all the cards. Unloading a module by
> itself is tough. One way out would be to add it to ath9k's pci.c.
> The question is: will such a feature have support from the ath9k
> folks?
owl-loader seems very small (<7KiB) and it only allocates a few bytes
dynamically. Even if you move this code to ath9k you will still have
the same problem: as long as ath9k is not unloaded this code will hang
around in memory.
But apart from this - moving it to the kernel might have some benefits
though as it could be shared between ath9k and ath5k (as some ath5k
seem to require a similar "fixup" as well).

> I've added lede-dev and Luis since this is relevant for them.
> Maybe between the sysloadfw.sh and owl-loader, there's another
> solution we overlooked so far? I know Luis has been digging
> around in the firmware_class and added the sysdata API. But
> from what I can tell, this would ?break? LEDE/OpenWRT's
> userspace helper, since the sysfs interface in
> /sys/class/firmware which is used by procd to upload the data
> is gone with sysdata or am I wrong?
good idea to keep lede-dev in the loop, as they will be affected (in
my opinion: positively) by this change.


Regards,
Martin
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel