On Mon, 2008-10-20 at 19:37 -0700, Luis R. Rodriguez wrote: > As I mentioned in my previous e-mail, the real problem is what you are > asking for changes the entire regulatory design from: "disable > everything and enable only this" to "enable everything except for > elements I don't define in the band I tell you to". There are many > design flaws with this; an obvious problem to this is what is a band? > In my patch I took the liberty to define that a frequency is part of a > band if a rule was present within 2 GHz of itself. This works but it > is trying to make a definition out of something that doesn't exist -- > its trying to solve the wrong problem. Since regulatory database is in > KHz it is designed to allow us to grow regardless of band notions or > associations. In the regulatory database we allow for 2 GHz, 5 GHz, > etc KH definitions for any country and this was designed to account > for misinformation on drivers to help the user be more compliant. By > changing the design to what you are suggesting you'd have to add a > dummy rule for every frequency "band" if you really want to disable > all other bands. I agree you on the band and KHz. > The real problem here is you are not providing 5 GHz regulatory rules > on a 2 GHz capable built-in card because you currently handle > regulatory definitions by intersecting with hardware capabilities > *and* the issue is what happens when a user plugs in a 5 GHz capable > card. For >= iwlagn you have only a few SKUs so if you want you can > put these definitions in the driver. As Tomas points out for iwl3945 > and iwl4965 your SKUs are more complicated. Regulatory *is* > complicated, and that is the current outsourcing of db.txt to > userspace tries to accomplish. So the solution isn't to try to "fix" > the regulatory infrastructure to handle your particular issue when a > single Intel 2 GHz band card is present and you connect a dual band > card by changing its overall design, because we already provide a > mechanism to deal with overriding regulatory rules to help the user be > more compliant. The real problem is you are forcing a device to provide a SKU even it is not capable of. An SKU is not always necessary as long as the hardware provides other ways to comply with regulatory. To solve the problem, I'd suggest a special regdomain named EVERYTHING. In the case the driver or firmware enforces reg_rules, the core wireless reg_rules are safe to be bypassed. EVERYTHING can always be overwritten by other regdomains. For example, when the user inserts a second card with regdomain of EU, EU becomes the global regdomain. A driver should only claim to use EVERYTHING when it has its own way to enforce regulatory. Now the concept changes to "the first non-EVERYTHING regdomain wins". Thoughts? > The proper solution is to either add 5 GHz regulatory rules to your > regulatory_hint() and/or rely on crda to enable the 5 GHz channels > required for the country the user is in. It is true that you need > manual intervention and the way I am trying to resolve that is not by > changing the design of the current regulatory infrastructure, instead > I want to add country selection support to say wpa_supplicant or > Network Manager. That, IMO, is how to address the problem correctly. I > also suggested a temporary solution which a distribution can use which > requires absolutely no manual user intervention, that of determining > the country through whatever means the distribution deems more fit and > calling iw reg set on $COUNTRY. See Marcel's comment on supporting new kernels with old applications. Thanks, -yi -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
