Regulatory Framework & rt2x00.

Regulatory Framework & rt2x00.

[Gertjan van Wingerde]

Hi Luis,

I'm working on making rt2x00 use the regulatory framework to report its 
EEPROM region settings to mac80211, and I have stumbled upon an issue 
that I don't really know how to solve with the current regulatory 
framework code.

The problem I'm facing is that many of the Ralink devices have 2 region 
settings in their EEPROM, one for 802.11a networks, and one for 
802.11[bgn] networks. So far I have only seen devices where these two 
settings contain the same region indication, but I don't know whether 
this is the case for all devices.

At this point in time I use the regulatory_hint function at driver 
start-up time to communicate the region setting that matches the 
configured band, but that would (probably) not hold up when the user 
reconfigures the mode.

So, at this point in time I have the following questions:
1. How would I be able to communicate both these settings to the 
regulatory framework?
2. Should I re-use regulator_hint whenever the configured band changes?
3. Would a driver supplied region override a user configured setting 
(via iw/crda)?

I would appreciate your help in solving this issue.

---
Gertjan van Wingerde
rt2x00 project developer
http://rt2x00.serialmonkey.com/

Re: Regulatory Framework & rt2x00.

[Luis R. Rodriguez]

On Thu, Oct 02, 2008 at 01:20:23PM -0700, Gertjan van Wingerde wrote:
> Hi Luis,
> 
> I'm working on making rt2x00 use the regulatory framework to report its
> EEPROM region settings to mac80211, 

Excellent! Glad to see someone pick this work up for Ralink!

> and I have stumbled upon an issue
> that I don't really know how to solve with the current regulatory
> framework code.
>
> The problem I'm facing is that many of the Ralink devices have 2 region
> settings in their EEPROM, one for 802.11a networks, and one for
> 802.11[bgn] networks. So far I have only seen devices where these two
> settings contain the same region indication, but I don't know whether
> this is the case for all devices.

Actually as per the documenation I have the EEPROM *should not* be
relied on for proper regulatory compliance on some Ralink devices.
The windows registry is used so for these I'd recommend to rely on
db.txt and help enhance it further. Not sure if the documentation
for *all* devices says this though so we'll have to find out.

I'll send you the documentation I have in private.

Anyway Atheros devices also use a per band EEPROM value, I don't follow
the issue (should you really want to follow the EEPROM, please check the
documentation I will send you).

> At this point in time I use the regulatory_hint function at driver
> start-up time to communicate the region setting that matches the
> configured band, but that would (probably) not hold up when the user
> reconfigures the mode.

It does if you really want it to by using the reg_notifier() callback
you can register. We plan on eventually using this on ath9k for example
to respect the EEPROM values to come up with the intersection of the
regulatory domain the user set and what the EEPROM has. I had sent
an intersection patch a while ago under RFC for 802.11d. The
intersection routine is not yet merged.

> So, at this point in time I have the following questions:
> 1. How would I be able to communicate both these settings to the
> regulatory framework?

I think I answered them, please let me know if you need further
information.

> 2. Should I re-use regulator_hint whenever the configured band changes?

Nope, never.

> 3. Would a driver supplied region override a user configured setting
> (via iw/crda)?

Only if a callback is provided, reg_notifier() or if you register
*always* only the channels in that regulatory domain. I wouldn't
recommend this last strategy, but instead to use the first. The nice
thing with the first approach is you get to eventually support
world roaming then. You accomplish this by *not* allowing new regulatory
changes if the initiator was REGDOM_SET_BY_USER but consider them
to be applicable if your device has the
dot11MultiDomainCapabilityEnabled flag enabled, which by the 802.11
standard should be assumed to false *and* if the initiator was
REGDOM_SET_BY_COUNTRY_IE, which indicates the new regulatory_hint()
came from processing a 802.11d country IE; heck you can even check
the alpha2 here and decide if you device is world-roaming capable
in this country too. In fact to world roam since the IEEE-802.11
Country IE is crap (it really lacks a lot of information to really
be regulatory compliant IMO) we will need to do the intersection
of the built regulatory domain from the recieved Country IE and
what we have in our db.txt -- our db.txt has other information
such as DFS flags (note if your stack supports DFS for all modes
then DFS flags are useless as you are compliant to DFS always) and
max channel bandwidth limitations. If you want to be even more
conservative you can then take the intersection of this new intersected
regulatory domain and what you define based on your intelligence on
your EEPROM. What you end up is perhaps the most compliant regulatory
solution for world roaming available :)

> I would appreciate your help in solving this issue.

I hope this helps,

  Luis

Re: Regulatory Framework & rt2x00.

[Gertjan van Wingerde]

Luis R. Rodriguez wrote:
> On Thu, Oct 02, 2008 at 01:20:23PM -0700, Gertjan van Wingerde wrote:
>    
>> Hi Luis,
>>
>> I'm working on making rt2x00 use the regulatory framework to report its
>> EEPROM region settings to mac80211,
>>      
>
> Excellent! Glad to see someone pick this work up for Ralink!
>
>    
>> and I have stumbled upon an issue
>> that I don't really know how to solve with the current regulatory
>> framework code.
>>
>> The problem I'm facing is that many of the Ralink devices have 2 region
>> settings in their EEPROM, one for 802.11a networks, and one for
>> 802.11[bgn] networks. So far I have only seen devices where these two
>> settings contain the same region indication, but I don't know whether
>> this is the case for all devices.
>>      
>
> Actually as per the documenation I have the EEPROM *should not* be
> relied on for proper regulatory compliance on some Ralink devices.
> The windows registry is used so for these I'd recommend to rely on
> db.txt and help enhance it further. Not sure if the documentation
> for *all* devices says this though so we'll have to find out.
>
> I'll send you the documentation I have in private.
>
> Anyway Atheros devices also use a per band EEPROM value, I don't follow
> the issue (should you really want to follow the EEPROM, please check the
> documentation I will send you).
>    

My tests on the Ralink devices I have show that indeed the PCI devices 
do not contain a region indication in EEPROM. However, all the USB 
devices I have do contain such an indication (or one indication per band).

Do you have any sample code available on how the Atheros devices 
interact with the regulatory framework with their EEPROM values?

>    
>> At this point in time I use the regulatory_hint function at driver
>> start-up time to communicate the region setting that matches the
>> configured band, but that would (probably) not hold up when the user
>> reconfigures the mode.
>>      
>
> It does if you really want it to by using the reg_notifier() callback
> you can register. We plan on eventually using this on ath9k for example
> to respect the EEPROM values to come up with the intersection of the
> regulatory domain the user set and what the EEPROM has. I had sent
> an intersection patch a while ago under RFC for 802.11d. The
> intersection routine is not yet merged.
>    

OK. I guess that depends on what model we want to have with Linux. For 
me, the user should always have the possibility to override the HW 
settings on region, as he might have taken the HW he bought in one 
region of the world to another. So, as far as I am concerned the EEPROM 
information is just an initial setting, which may be overridden later.

So, at the moment, I'm not interested in using the notifier.

>    
>> So, at this point in time I have the following questions:
>> 1. How would I be able to communicate both these settings to the
>> regulatory framework?
>>      
>
> I think I answered them, please let me know if you need further
> information.
>    

I'm not entirely sure yet. The basic question I have is that if I have a 
device with has in EEPROM a region setting of US for the 5GHz band and 
EU for the 2GHz band, what do I pass to the regulatory_hint function?

>    
>> 2. Should I re-use regulator_hint whenever the configured band changes?
>>      
>
> Nope, never.
>
>    
>> 3. Would a driver supplied region override a user configured setting
>> (via iw/crda)?
>>      
>
> Only if a callback is provided, reg_notifier() or if you register
> *always* only the channels in that regulatory domain. I wouldn't
> recommend this last strategy, but instead to use the first. The nice
> thing with the first approach is you get to eventually support
> world roaming then. You accomplish this by *not* allowing new regulatory
> changes if the initiator was REGDOM_SET_BY_USER but consider them
> to be applicable if your device has the
> dot11MultiDomainCapabilityEnabled flag enabled, which by the 802.11
> standard should be assumed to false *and* if the initiator was
> REGDOM_SET_BY_COUNTRY_IE, which indicates the new regulatory_hint()
> came from processing a 802.11d country IE; heck you can even check
> the alpha2 here and decide if you device is world-roaming capable
> in this country too. In fact to world roam since the IEEE-802.11
> Country IE is crap (it really lacks a lot of information to really
> be regulatory compliant IMO) we will need to do the intersection
> of the built regulatory domain from the recieved Country IE and
> what we have in our db.txt -- our db.txt has other information
> such as DFS flags (note if your stack supports DFS for all modes
> then DFS flags are useless as you are compliant to DFS always) and
> max channel bandwidth limitations. If you want to be even more
> conservative you can then take the intersection of this new intersected
> regulatory domain and what you define based on your intelligence on
> your EEPROM. What you end up is perhaps the most compliant regulatory
> solution for world roaming available :)
>
>    
>> I would appreciate your help in solving this issue.
>>      
>
> I hope this helps,
>
>    Luis
>
>    

Re: Regulatory Framework & rt2x00.

[Luis R. Rodriguez]

On Fri, Oct 03, 2008 at 01:20:08PM -0700, Gertjan van Wingerde wrote:
> My tests on the Ralink devices I have show that indeed the PCI devices
> do not contain a region indication in EEPROM. However, all the USB
> devices I have do contain such an indication (or one indication per band).

Even if they have one if the docs say to ignore it then I'd ignore it.

> Do you have any sample code available on how the Atheros devices
> interact with the regulatory framework with their EEPROM values?

Nope, not yet, rigth now we register the channels based on our EEPROM,
and the user sets the regulatory domain to enhance regulatory domain
enforcement. Later once we want to allow world roaming and support
parsing Country IEs we will take on registering all our supported
channels and then use the reg_notifier() to review the data passed
for the alpha2.

> OK. I guess that depends on what model we want to have with Linux. For
> me, the user should always have the possibility to override the HW
> settings on region, as he might have taken the HW he bought in one
> region of the world to another.

This should only be possible if the devices were designed to world roam.
Remember that world roaming is part of the IEEE-802.11 specs, and by
default devices should be assumed to not be capable of it.

For example iwl3945 or iwlagn driveres are not capable of world roaming
because as of right now these devices are not designed to allow the
driver to *add* new channels.

Also keep in mind vendors tend to want to respect the EEPROM
map of the regulatory domain. This is to deal with two issues:

1. Rogue APs sending sending a strange channels for an alpha2 through
   a Country IE

2. Vendor's customers tend to like to stick sometimes to frequency
   ranges which may be old in terms of regulatory rules because
   although the device is capable of other frequencies the customer
   may not have tested the device or certified it under the other
   channels even adding a new channel may be seen as a feature.

So it really depends. The answer to these questions *are* really
vendor dependant and I what I would *highly* recommend is to take
a conservative approach unless you have the vendor's blessing
to do things differently, even if the vendor is not being
cooeperative. Keep in mind though that doing this requires
developer effort though so I can see why we won't have all drivers
using regulatory_hint() and a reg_notifier() for example. But
developers are forthcoming to write this then great -- if you
don't get vendor support to enhance this then its really up us
to decide what is best.

> So, as far as I am concerned the EEPROM
> information is just an initial setting, which may be overridden later.

It depends on the vendor and their policies. For ath9k for example
this is not true -- the regulatory infrastructure allows the driver
to use your EEPROM map in case vendors wish to think their map
is the better source of knowledge.

> So, at the moment, I'm not interested in using the notifier.

It requires quite some work so I can understand why you may not
be inclined to use it, but if you do get vendor support I'd
be nice for you to reconsider. Up to you though of course, as
you are doing the work :)

> I'm not entirely sure yet. The basic question I have is that if I have a
> device with has in EEPROM a region setting of US for the 5GHz band and
> EU for the 2GHz band, what do I pass to the regulatory_hint function?

Think about this for a second -- does this make any sense? I don't see
how. Perhaps this is why its not recommended you rely on it. In the end,
you won't know unless you ask the vendor.

  Luis

Re: Regulatory Framework & rt2x00.

[Gertjan van Wingerde]

Luis R. Rodriguez wrote:
> On Fri, Oct 03, 2008 at 01:20:08PM -0700, Gertjan van Wingerde wrote:
>    
>> My tests on the Ralink devices I have show that indeed the PCI devices
>> do not contain a region indication in EEPROM. However, all the USB
>> devices I have do contain such an indication (or one indication per band).
>>      
>
> Even if they have one if the docs say to ignore it then I'd ignore it.
>    

Unfortunately we don't have the EEPROM docs for the other chipsets (most 
notably USB-chipsets). I've asked Ralink whether they can share these 
with us.
I'll also study the Ralink provided driver in more detail. Maybe it 
gives some hints on how that driver uses the EEPROM information.

>
>> OK. I guess that depends on what model we want to have with Linux. For
>> me, the user should always have the possibility to override the HW
>> settings on region, as he might have taken the HW he bought in one
>> region of the world to another.
>>      
>
> This should only be possible if the devices were designed to world roam.
> Remember that world roaming is part of the IEEE-802.11 specs, and by
> default devices should be assumed to not be capable of it.
>
> For example iwl3945 or iwlagn driveres are not capable of world roaming
> because as of right now these devices are not designed to allow the
> driver to *add* new channels.
>
> Also keep in mind vendors tend to want to respect the EEPROM
> map of the regulatory domain. This is to deal with two issues:
>
> 1. Rogue APs sending sending a strange channels for an alpha2 through
>     a Country IE
>
> 2. Vendor's customers tend to like to stick sometimes to frequency
>     ranges which may be old in terms of regulatory rules because
>     although the device is capable of other frequencies the customer
>     may not have tested the device or certified it under the other
>     channels even adding a new channel may be seen as a feature.
>
> So it really depends. The answer to these questions *are* really
> vendor dependant and I what I would *highly* recommend is to take
> a conservative approach unless you have the vendor's blessing
> to do things differently, even if the vendor is not being
> cooeperative. Keep in mind though that doing this requires
> developer effort though so I can see why we won't have all drivers
> using regulatory_hint() and a reg_notifier() for example. But
> developers are forthcoming to write this then great -- if you
> don't get vendor support to enhance this then its really up us
> to decide what is best.
>    

Hmm, interesting. I would have assumed that in this era whether people 
are traveling round the world that vendors would create some more robust 
HW that is capable of coping with that. For instance, for my real-life 
job I do travel round the world a lot, and I'm using the built-in (as 
well as the Ralink PC-card I have) basically everywhere.

>
>> I'm not entirely sure yet. The basic question I have is that if I have a
>> device with has in EEPROM a region setting of US for the 5GHz band and
>> EU for the 2GHz band, what do I pass to the regulatory_hint function?
>>      
>
> Think about this for a second -- does this make any sense? I don't see
> how. Perhaps this is why its not recommended you rely on it. In the end,
> you won't know unless you ask the vendor.
>    

Yep, that's exactly the issue I had with this. It doesn't make sense to 
me to have multiple (potentially) different region codes programmed in 
EEPROM. Note that the example I gave is a real-life example. The EEPROM 
of my rt73usb device contain exactly these EEPROM settings for the 
region information :-(

---
Gertjan.

Re: Regulatory Framework & rt2x00.

[Luis R. Rodriguez]

On Fri, Oct 03, 2008 at 03:19:59PM -0700, Gertjan van Wingerde wrote:
> Luis R. Rodriguez wrote:
> >
> > This should only be possible if the devices were designed to world roam.
> > Remember that world roaming is part of the IEEE-802.11 specs, and by
> > default devices should be assumed to not be capable of it.
> >
> > For example iwl3945 or iwlagn driveres are not capable of world roaming
> > because as of right now these devices are not designed to allow the
> > driver to *add* new channels.
> >
> > Also keep in mind vendors tend to want to respect the EEPROM
> > map of the regulatory domain. This is to deal with two issues:
> >
> > 1. Rogue APs sending sending a strange channels for an alpha2 through
> >     a Country IE
> >
> > 2. Vendor's customers tend to like to stick sometimes to frequency
> >     ranges which may be old in terms of regulatory rules because
> >     although the device is capable of other frequencies the customer
> >     may not have tested the device or certified it under the other
> >     channels even adding a new channel may be seen as a feature.
> >
> > So it really depends. The answer to these questions *are* really
> > vendor dependant and I what I would *highly* recommend is to take
> > a conservative approach unless you have the vendor's blessing
> > to do things differently, even if the vendor is not being
> > cooeperative. Keep in mind though that doing this requires
> > developer effort though so I can see why we won't have all drivers
> > using regulatory_hint() and a reg_notifier() for example. But
> > developers are forthcoming to write this then great -- if you
> > don't get vendor support to enhance this then its really up us
> > to decide what is best.
> >
> 
> Hmm, interesting. I would have assumed that in this era whether people
> are traveling round the world that vendors would create some more robust
> HW that is capable of coping with that. For instance, for my real-life
> job I do travel round the world a lot, and I'm using the built-in (as
> well as the Ralink PC-card I have) basically everywhere.

Well due to the "regulatory boogeyman", as Sam likes to call it,
companies which do not have solid regulatory infrastructure tend to
like to simply not world roam or simply not deal with this in FOSS.

Fortunately now we have a pretty beefy regulatory infrastructure though
so this can change now. Keep in mind that you *shouldn't* run into
problems unless you hit channels on band edges which are usually the
ones that may get removed, like channels 12 and 13 on the 2 GHZ band,
for example.

> >> I'm not entirely sure yet. The basic question I have is that if I have a
> >> device with has in EEPROM a region setting of US for the 5GHz band and
> >> EU for the 2GHz band, what do I pass to the regulatory_hint function?
> >>
> >
> > Think about this for a second -- does this make any sense? I don't see
> > how. Perhaps this is why its not recommended you rely on it. In the end,
> > you won't know unless you ask the vendor.
> >
> 
> Yep, that's exactly the issue I had with this. It doesn't make sense to
> me to have multiple (potentially) different region codes programmed in
> EEPROM. 

Right, well I mean, it could make sense if although its "US" for 2 GHz
and "EU" for 5 GHz that this is not really an EEPROM country code but
more rather an EEPROM code for the collection of channels on each band.
In regulatory world these are called SKUs [1]. So If you start thinking
of it in terms of SKUs you then then to find what the SKU means and
simply just use that to only register those channels. This would be a
very conservative approach but it limits your devices to not be
able to world roam later. If instead you use a reg_notifier() to
review the regulatory changes and if the initiator is the user
(REGDOM_SET_BY_USER) you can then override any changes by crda as your
driver may claim to know better. That was the whole point of
reg_notifier() -- in case you want to say you know better in case of a
user override. This can then let you world roam later if the initiator
is REGDOM_SET_BY_COUNTRY_IE and you want to be more flexible there.

As you can see this requires quite a bit of work and knowledge of the
device's regulatory information and the original intentions behind the
design of the device. This is why its difficult to simply assume
you can build it on your own without vendor involvement and why I was
recommending a more conservative approach.

> Note that the example I gave is a real-life example. The EEPROM
> of my rt73usb device contain exactly these EEPROM settings for the
> region information :-(

Heh yeah, if you think in terms of SKUs it makes a little more sense, I
hope.

[1] http://en.wikipedia.org/wiki/Stock-keeping_unit

Re: Regulatory Framework & rt2x00.

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]

On Thu, 2008-10-02 at 22:20 +0200, Gertjan van Wingerde wrote:

> The problem I'm facing is that many of the Ralink devices have 2 region 
> settings in their EEPROM, one for 802.11a networks, and one for 
> 802.11[bgn] networks. So far I have only seen devices where these two 
> settings contain the same region indication, but I don't know whether 
> this is the case for all devices.
> 
> At this point in time I use the regulatory_hint function at driver 
> start-up time to communicate the region setting that matches the 
> configured band, but that would (probably) not hold up when the user 
> reconfigures the mode.

I think you basically have two choices depending on whether you have a
country code in the eeprom or not.

If you have a country code, I suggest you just use either one.

As far as I know, though, you don't have country codes. So if there's a
valid code in the EEPROM you probably should use the regdomain struct
hint rather than the alpha2 hint and build a regdomain that contains
both 2.4 and 5 GHz channels based on the two region values you have.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Regulatory Framework & rt2x00.

[Ivo van Doorn]

Hi,

> > The problem I'm facing is that many of the Ralink devices have 2 region 
> > settings in their EEPROM, one for 802.11a networks, and one for 
> > 802.11[bgn] networks. So far I have only seen devices where these two 
> > settings contain the same region indication, but I don't know whether 
> > this is the case for all devices.
> > 
> > At this point in time I use the regulatory_hint function at driver 
> > start-up time to communicate the region setting that matches the 
> > configured band, but that would (probably) not hold up when the user 
> > reconfigures the mode.
> 
> I think you basically have two choices depending on whether you have a
> country code in the eeprom or not.
> 
> If you have a country code, I suggest you just use either one.
> 
> As far as I know, though, you don't have country codes. So if there's a
> valid code in the EEPROM you probably should use the regdomain struct
> hint rather than the alpha2 hint and build a regdomain that contains
> both 2.4 and 5 GHz channels based on the two region values you have.

For rt61pci and rt73usb you should do as Johannes suggested by using the
regdomain struct. For rt2500pci and rt2500usb it sounds much easier to
take the country code from the EEPROM since those devices only contain
a single regdom value.

Ivo

Re: Regulatory Framework & rt2x00.

[Gertjan van Wingerde]

Ivo van Doorn wrote:
> Hi,
>
>    
>>> The problem I'm facing is that many of the Ralink devices have 2 region
>>> settings in their EEPROM, one for 802.11a networks, and one for
>>> 802.11[bgn] networks. So far I have only seen devices where these two
>>> settings contain the same region indication, but I don't know whether
>>> this is the case for all devices.
>>>
>>> At this point in time I use the regulatory_hint function at driver
>>> start-up time to communicate the region setting that matches the
>>> configured band, but that would (probably) not hold up when the user
>>> reconfigures the mode.
>>>        
>> I think you basically have two choices depending on whether you have a
>> country code in the eeprom or not.
>>
>> If you have a country code, I suggest you just use either one.
>>
>> As far as I know, though, you don't have country codes. So if there's a
>> valid code in the EEPROM you probably should use the regdomain struct
>> hint rather than the alpha2 hint and build a regdomain that contains
>> both 2.4 and 5 GHz channels based on the two region values you have.
>>      
>
> For rt61pci and rt73usb you should do as Johannes suggested by using the
> regdomain struct. For rt2500pci and rt2500usb it sounds much easier to
> take the country code from the EEPROM since those devices only contain
> a single regdom value.

Hmm, but building the regdomain struct would mean detailed region 
knowledge inside the driver. This is something I was trying to prevent, 
as all that knowledge has been moved to user-space with crda.

Luis, any other suggestions?

---
Gertjan.

Re: Regulatory Framework & rt2x00.

[Luis R. Rodriguez]

On Fri, Oct 03, 2008 at 01:02:04PM -0700, Gertjan van Wingerde wrote:
> Ivo van Doorn wrote:
> > Hi,
> >
> >
> >>> The problem I'm facing is that many of the Ralink devices have 2 region
> >>> settings in their EEPROM, one for 802.11a networks, and one for
> >>> 802.11[bgn] networks. So far I have only seen devices where these two
> >>> settings contain the same region indication, but I don't know whether
> >>> this is the case for all devices.
> >>>
> >>> At this point in time I use the regulatory_hint function at driver
> >>> start-up time to communicate the region setting that matches the
> >>> configured band, but that would (probably) not hold up when the user
> >>> reconfigures the mode.
> >>>
> >> I think you basically have two choices depending on whether you have a
> >> country code in the eeprom or not.
> >>
> >> If you have a country code, I suggest you just use either one.
> >>
> >> As far as I know, though, you don't have country codes. So if there's a
> >> valid code in the EEPROM you probably should use the regdomain struct
> >> hint rather than the alpha2 hint and build a regdomain that contains
> >> both 2.4 and 5 GHz channels based on the two region values you have.
> >>
> >
> > For rt61pci and rt73usb you should do as Johannes suggested by using the
> > regdomain struct. For rt2500pci and rt2500usb it sounds much easier to
> > take the country code from the EEPROM since those devices only contain
> > a single regdom value.
> 
> Hmm, but building the regdomain struct would mean detailed region
> knowledge inside the driver. This is something I was trying to prevent,
> as all that knowledge has been moved to user-space with crda.
> 
> Luis, any other suggestions?

Proper regulatory implementation does require vendor involvement. I'd take it
up with Ralink to figure this out. In the meantime I'd suggest to just
let the user pick the alpha2 or to simply regulatory_hint() to a country
in which the devices are mostly sold on.

Remember -- RT61 EEPROM docs indicate you shouldn't rely on the EEPROM so its
pointless. I suspect its the same with the other devices but since
we do not have docs we cannot be sure.

  Luis