From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Lamparter Date: Sat, 25 Jun 2016 14:01:12 +0200 Subject: [ath9k-devel] [PATCH RFC v3 3/3] ath9k: parse the device configuration from an OF node In-Reply-To: <20160624123430.4097-4-martin.blumenstingl@googlemail.com> References: <20160624123430.4097-1-martin.blumenstingl@googlemail.com> <20160624123430.4097-4-martin.blumenstingl@googlemail.com> Message-ID: <2421107.Vh3zsAgVDf@debian64> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org 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 early pci-fixup routine for the device to work properly [0], [1]? How will this be handled/integrated? I know that the ar71xx and the lantiq platforms use similar pci-fixup routines that need a few bytes from the eeprom/cal data. So lantiq has a few extra properties: "ath,pci-slot", "ath,device-id" and "ath,eep-flash". As an example: the AR9280 in the Cisco Z1 AP is initially 0x168c:0xff1f (<-- ath9k doesn't know about that id). The pci-fixup routine will change it to 0x168c:0x002A. Only then ath9k can take it over and will initialize it. Thing is: this is all currently done by platform code for those architectures... And currently, the request_firmware doesn't work for caldata on UBI partitions. Regards, Christian [0] [1]