From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Buesch Subject: Re: [PATCH 1/2] d80211: Add software RTS support Date: Mon, 5 Feb 2007 19:23:50 +0100 Message-ID: <200702051923.50792.mb@bu3sch.de> References: <200701312016.50524.IvDoorn@gmail.com> <200702051843.07026.mb@bu3sch.de> <20070205190834.40c0a619@griffin.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Ivo van Doorn , "John Linville" , netdev@vger.kernel.org, Michael Buesch , Johannes Berg To: Jiri Benc Return-path: Received: from static-ip-62-75-166-246.inaddr.intergenia.de ([62.75.166.246]:45823 "EHLO vs166246.vserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933019AbXBESX5 (ORCPT ); Mon, 5 Feb 2007 13:23:57 -0500 In-Reply-To: <20070205190834.40c0a619@griffin.suse.cz> Content-Disposition: inline Sender: netdev-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Monday 05 February 2007 19:08, Jiri Benc wrote: > On Mon, 5 Feb 2007 18:43:06 +0100, Michael Buesch wrote: > > I also think that sending RTS in software is not going to work, > > as the timing can not be guaranteed. And timing is why we do it in > > the first place. If the HW is not capable of sending RTS frames, we > > should not try to emulate them in SW, as it might make the situation > > even worse by messing up the NAVs by wrong timing. > > That's not emulation in the software, it's just similar approach as > with sending fragmented frames - you need (more or less) precise timing > there as well and many cards still want them enqueued one-by-one. The > firmware takes care of the precise timing. The same could apply to RTS > frames (i. e. the firmware recognize them and doesn't send them before > it has the next frame ready). Yeah, ok. I got the point. But still, this does not work with bcm43xx. :) -- Greetings Michael.