Re: [PATCH 1/7] Documentation: dt: net: Update the ath9k binding for SoC devices

2017-04-05 Thread Kalle Valo
Alban writes: > The current binding only cover PCI devices so extend it for SoC devices. > > Most SoC platforms use an MTD partition for the calibration data > instead of an EEPROM. The qca,no-eeprom property was added to allow > loading the EEPROM content using firmware loading.

Re: [PATCH 1/7] Documentation: dt: net: Update the ath9k binding for SoC devices

2017-03-28 Thread Christian Lamparter
On Tuesday, March 28, 2017 6:41:59 PM CEST Andrew Lunn wrote: > > Oh, in that case you should probably go "all out" and ask on the > > LKML to remove all of the ath9k and ath10k ahb work. From what I > > know all the "users" are running some sort of OpenWRT/LEDE or a > > derivative. This is

Re: [PATCH 1/7] Documentation: dt: net: Update the ath9k binding for SoC devices

2017-03-28 Thread Andrew Lunn
> Oh, in that case you should probably go "all out" and ask on the > LKML to remove all of the ath9k and ath10k ahb work. From what I > know all the "users" are running some sort of OpenWRT/LEDE or a > derivative. This is because Atheros/QCA provided a SDK based on > OpenWRT. > > Alban has been

Re: [PATCH 1/7] Documentation: dt: net: Update the ath9k binding for SoC devices

2017-03-28 Thread Christian Lamparter
On Tuesday, March 28, 2017 5:18:37 PM CEST Andrew Lunn wrote: > > But LEDE/OpenWRT rely on the firmware loading API more than ever and > > currently there is not a replacement for it. > > > > > > I looked into 10-ath9k-eeprom [0] of LEDE's AR71XX target and I noticed > > that quite a few

Re: [PATCH 1/7] Documentation: dt: net: Update the ath9k binding for SoC devices

2017-03-28 Thread Andrew Lunn
> But LEDE/OpenWRT rely on the firmware loading API more than ever and > currently there is not a replacement for it. > I looked into 10-ath9k-eeprom [0] of LEDE's AR71XX target and I noticed > that quite a few devices patch the MACs of the wifi. > If you look at the code for the Airtight

Re: [PATCH 1/7] Documentation: dt: net: Update the ath9k binding for SoC devices

2017-03-28 Thread Christian Lamparter
On Tuesday, March 28, 2017 10:44:41 AM CEST Alban wrote: > On Mon, 27 Mar 2017 18:11:15 +0200 > Christian Lamparter wrote: > > > On Monday, March 13, 2017 10:05:09 PM CEST Alban wrote: > > > The current binding only cover PCI devices so extend it for SoC devices. > > >

Re: [PATCH 1/7] Documentation: dt: net: Update the ath9k binding for SoC devices

2017-03-28 Thread Alban
On Mon, 27 Mar 2017 18:11:15 +0200 Christian Lamparter wrote: > On Monday, March 13, 2017 10:05:09 PM CEST Alban wrote: > > The current binding only cover PCI devices so extend it for SoC devices. > > > > Most SoC platforms use an MTD partition for the calibration data

Re: [PATCH 1/7] Documentation: dt: net: Update the ath9k binding for SoC devices

2017-03-27 Thread Christian Lamparter
On Monday, March 13, 2017 10:05:09 PM CEST Alban wrote: > The current binding only cover PCI devices so extend it for SoC devices. > > Most SoC platforms use an MTD partition for the calibration data > instead of an EEPROM. The qca,no-eeprom property was added to allow > loading the EEPROM

Re: [PATCH 1/7] Documentation: dt: net: Update the ath9k binding for SoC devices

2017-03-20 Thread Rob Herring
On Mon, Mar 13, 2017 at 10:05:09PM +0100, Alban wrote: > The current binding only cover PCI devices so extend it for SoC devices. > > Most SoC platforms use an MTD partition for the calibration data > instead of an EEPROM. The qca,no-eeprom property was added to allow > loading the EEPROM content

[PATCH 1/7] Documentation: dt: net: Update the ath9k binding for SoC devices

2017-03-13 Thread Alban
The current binding only cover PCI devices so extend it for SoC devices. Most SoC platforms use an MTD partition for the calibration data instead of an EEPROM. The qca,no-eeprom property was added to allow loading the EEPROM content using firmware loading. This new binding replace this hack with