All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Buesch <mb@bu3sch.de>
To: jt@hpl.hp.com
Cc: Dan Williams <dcbw@redhat.com>,
	netdev@vger.kernel.org, Johannes Berg <johannes@sipsolutions.net>
Subject: Re: proposal for new wireless configuration API
Date: Thu, 17 Aug 2006 23:24:08 +0200	[thread overview]
Message-ID: <200608172324.08556.mb@bu3sch.de> (raw)
In-Reply-To: <20060817193938.GA29676@bougret.hpl.hp.com>

On Thursday 17 August 2006 21:39, Jean Tourrilhes wrote:
> On Tue, Aug 15, 2006 at 09:13:23PM +0200, Michael Buesch wrote:
> > On Tuesday 15 August 2006 20:14, Dan Williams wrote:
> > > On Tue, 2006-08-15 at 18:38 +0200, Michael Buesch wrote:
> > > > On Tuesday 15 August 2006 18:29, Dan Williams wrote:
> > > > > o Separate attributes for channel and frequency
> > > > 
> > > > No, channel and freq is the same. It's just another name
> > > > for the same child. I would say we only want to deal with channel numbers
> > > > in the API. That's much easier, as we don't have to deal with this
> > > > fixed-point (or even floating point) mess. Look at WE for the
> > > > fixed-point mess.
> > > 
> > > Right, I don't have a problem with only using one or the other; but we
> > > _HAVE_ to provide a function in the driver that allows userspace
> > > programs to convert channel <-> frequency both ways, like you suggest
> > > below.  Obviously the channel/frequency mapping isn't the same
> > > everywhere.
> > > 
> > > [ or is it?  I'd be very uncomfortable using the same channel #s
> > > everywhere unless some IEEE spec states exactly what the channel #s are
> > > for every frequency range that wireless stuff operates in ]
> > 
> > The channel<->freq mapping is stable.
> 
> 	We may need to double check this...
> 	It is already clear that WiMax, ZigBee and pre-802.11 HW don't
> use the same channel<->freq mapping as 802.11.
> 	Further, I remember somebody (was it Jouni) mentioning that
> some variations of 802.11 have different channel mappings. But, we
> would need to check that.

Yes, I should have been more verbose here.
What I meant is: In a particular PHYMODE the channel->freq mapping
is stable. That is, if we are in G-PHY mode, the mapping is always
stable with channels 1-14. Wimax and so on would be another PHYMODE.
The PHYMODE would be selected otherwise (through other netlink attrs
or whatever).

> > > No argument here; as long as we provide the mapping function in the
> > > driver for each card.
> > 
> > Hm, I don't know if I understand this correctly.
> > You want to implement the mapping function in every driver
> > or in the d80211 stack?
> 
> 	A simple mapping table is probably enough, similar to what we
> already have.

Well, a mapping function, because we must look at the different PHYMODEs.

-- 
Greetings Michael.

  reply	other threads:[~2006-08-17 21:25 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-15 15:28 proposal for new wireless configuration API Johannes Berg
2006-08-15 16:14 ` Luis R. Rodriguez
2006-08-16  7:26   ` Johannes Berg
2006-08-15 16:29 ` Dan Williams
2006-08-15 16:38   ` Michael Buesch
2006-08-15 18:14     ` Dan Williams
2006-08-15 19:13       ` Michael Buesch
2006-08-15 19:27         ` Simon Barber
2006-08-15 19:35           ` Michael Buesch
2006-08-15 20:06             ` Dan Williams
2006-08-15 19:59         ` Dan Williams
2006-08-16  7:14           ` Johannes Berg
2006-08-17 19:39         ` Jean Tourrilhes
2006-08-17 21:24           ` Michael Buesch [this message]
2006-08-17 23:29     ` Ulrich Kunitz
2006-08-18  7:12       ` Johannes Berg
2006-08-18 15:00         ` John W. Linville
2006-08-18 21:29         ` Ulrich Kunitz
2006-08-18 22:02           ` Michael Buesch
2006-08-21  7:31             ` Johannes Berg
2006-08-16  6:51   ` Johannes Berg
2006-08-16 18:02     ` Simon Barber
2006-08-17  7:19       ` Johannes Berg
2006-08-17 16:42         ` Simon Barber
2006-08-17 23:23           ` Ulrich Kunitz
2006-08-18  7:01           ` Johannes Berg
2006-08-18 16:45             ` Simon Barber
2006-08-21  6:45               ` Johannes Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200608172324.08556.mb@bu3sch.de \
    --to=mb@bu3sch.de \
    --cc=dcbw@redhat.com \
    --cc=johannes@sipsolutions.net \
    --cc=jt@hpl.hp.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.