On Mon, Jun 27, 2016 at 01:38:43AM +0200, Martin Blumenstingl wrote:
> On Sat, Jun 25, 2016 at 9:26 PM, Christian Lamparter
> wrote:
> > 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 fa
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
On Saturday, June 25, 2016 05:08:29 PM Martin Blumenstingl wrote:
> On Sat, Jun 25, 2016 at 2:01 PM, Christian Lamparter
> wrote:
> > On Friday, June 24, 2016 02:34:30 PM Martin Blumenstingl wrote:
> >> This makes it possible to configure ath9k based devices using
> >> devicetree. That makes some
On Sat, Jun 25, 2016 at 2:01 PM, Christian Lamparter
wrote:
> On Friday, June 24, 2016 02:34:30 PM Martin Blumenstingl wrote:
>> This makes it possible to configure ath9k based devices using
>> devicetree. That makes some out-of-tree "convert devicetree to
>> ath9k_platform_data glue"-code obsolet
On Friday, June 24, 2016 02:34:30 PM Martin Blumenstingl wrote:
> This makes it possible to configure ath9k based devices using
> devicetree. That makes some out-of-tree "convert devicetree to
> ath9k_platform_data glue"-code obsolete.
Hm, what about the embedded ath9k pcie chips that need the ear
This makes it possible to configure ath9k based devices using
devicetree. That makes some out-of-tree "convert devicetree to
ath9k_platform_data glue"-code obsolete.
Signed-off-by: Martin Blumenstingl
---
changes in v2 -> v3:
- replaced qca,eeprom-name with a boolean "qca,no-eeprom". The name of