d80211: The struct ieee80211_hw_modes array is a pain

d80211: The struct ieee80211_hw_modes array is a pain

[Michael Buesch]

I am currently porting the bcm43xx driver to my new Sonics
Silicon Backplane busdriver.
I am having a major pain implementing the hw->modes field
for this. In particular, the problem is allocation.
I always felt sick about hw->modes, but with my new code it's
damn complicated to get allocation of the stuff right.
The problem is, that I do not know in advance which PHYMODEs
my device supports (in fact, we never knew that, but we worked
around it (in a broken way)).
We have the following scenario: The PHYs are probed one after
each other. We have one data structure per PHY. This bites
the static hw->modes array in its ass. I would either have to
allocate it "big enough" at the first time (wasting lots of memory)
or I'd have to re-allocate it every time a new PHY is probed.
Another (much harder to fix) problem is the opposite of the probing:
Removing the PHYs.

So, what I'd like to have is:

One struct ieee802111_hw_mode which I can embed into the PHY
data structure. This struct is now dynamically registered to the
ieee80211 subsystem (instead of doing a static array pain).

Registering and unregistering would be done with simple linked lists,
perhaps, in d80211.

If nobody has any objections against this approach, I will do a
patch soon.

-- 
Greetings Michael.

Re: d80211: The struct ieee80211_hw_modes array is a pain

[Ivo Van Doorn]

Hi,

> I am currently porting the bcm43xx driver to my new Sonics
> Silicon Backplane busdriver.
> I am having a major pain implementing the hw->modes field
> for this. In particular, the problem is allocation.
> I always felt sick about hw->modes, but with my new code it's
> damn complicated to get allocation of the stuff right.
> The problem is, that I do not know in advance which PHYMODEs
> my device supports (in fact, we never knew that, but we worked
> around it (in a broken way)).
> We have the following scenario: The PHYs are probed one after
> each other. We have one data structure per PHY. This bites
> the static hw->modes array in its ass. I would either have to
> allocate it "big enough" at the first time (wasting lots of memory)
> or I'd have to re-allocate it every time a new PHY is probed.
> Another (much harder to fix) problem is the opposite of the probing:
> Removing the PHYs.
>
> So, what I'd like to have is:
>
> One struct ieee802111_hw_mode which I can embed into the PHY
> data structure. This struct is now dynamically registered to the
> ieee80211 subsystem (instead of doing a static array pain).
>
> Registering and unregistering would be done with simple linked lists,
> perhaps, in d80211.

Sounds good to me. This would also solve the issue where the dscape stack
would always select the first mode in the array as the default mode.
Which means that the array should always be allocated in a specific
order since if B is first followed by G, then B would always be used
(even if G is supported by the AP).

Ivo