From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from wolverine01.qualcomm.com ([199.106.114.254]) by bombadil.infradead.org with esmtps (Exim 4.85_2 #1 (Red Hat Linux)) id 1bvHXv-0001Rm-Ch for ath10k@lists.infradead.org; Sat, 15 Oct 2016 05:30:12 +0000 From: "Valo, Kalle" Subject: Re: [RFC 0/5] ath6kl: non WMI data service support Date: Sat, 15 Oct 2016 05:29:45 +0000 Message-ID: <87bmym9o3a.fsf@kamboji.qca.qualcomm.com> References: <1476376769-4708-1-git-send-email-erik.stromdahl@gmail.com> <87k2dbbczu.fsf@kamboji.qca.qualcomm.com> In-Reply-To: (Erik Stromdahl's message of "Fri, 14 Oct 2016 17:54:27 +0200") Content-Language: en-US Content-ID: <18E3A8F36F30054DAB76B3B88FCD6B1F@qualcomm.com> MIME-Version: 1.0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "ath10k" Errors-To: ath10k-bounces+kvalo=adurom.com@lists.infradead.org To: Erik Stromdahl Cc: "linux-wireless@vger.kernel.org" , "ath10k@lists.infradead.org" (Adding ath10k list) Erik Stromdahl writes: > On 10/14/2016 09:34 AM, Valo, Kalle wrote: >> Erik Stromdahl writes: >> >>> This patch series is intended to prepare the ath6kl driver >>> for newer chipsets that doesn't use the current WMI data >>> endpoints for data traffic. >>> >>> The chipset I have been working with (and used for testing) >>> is QCA6584. It is SDIO based (at least the variant I have >>> been using) with 802.11p WAVE DSRC capabilities. >>> >>> This chipset is different from the AR600X family in that >>> it does not use the WMI data services (service id's 0x101 >>> to 0x104 ) for data traffic. >>> Instead it uses the HTT data service for data and wmi unified >>> for control messages. >>> It is also different when it comes to mailbox addresses >>> and HTC header format as well, but these differences are not >>> part of this patch series. >> >> Do you have more patches implemented, like something already working or >> have just started? >> > > I have an implementation with all features I need so far, but the other > patches will require cleanup before I can submit anything. > > I have been using the qcacld driver as a basis for the work and some of > the stuff in that driver is not really compliant with the kernel coding > style (to say the least). > > I have so far mainly been focused on getting all features up and running > and that has (unfortunately) resulted in some copy-pasting from > qcacld. Can you share the current code you have somewhere so that I could take a quick look? I don't care how ugly it is, I would just like to understand what kind of changes are needed. > I will start having a look at ath10k and see how much work it would be > to add sdio support to it... Thanks, let me know how it goes or if I can help somehow. My time is limited but if nothing else I can give some tips. -- Kalle Valo _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k