On 06-07-17 21:23, Hans de Goede wrote: > Hi, > > On 28-06-17 14:35, Arend Van Spriel wrote: >> Op 28 jun. 2017 12:07 schreef "Hans de Goede" <hdegoede@xxxxxxxxxx >> <mailto:hdegoede@xxxxxxxxxx>>: >> > >> > Hi, >> > >> > I noticed today that my GPD Win (x86 clamshell mini laptop) >> > which uses a brcmfmac4356-pci wifi does not see an APs which >> > is using channel 13. >> > >> > I've tried updating brcmfmac4356-pci.txt changing "ccode=US" >> > to "ccode=EU" and then rebooted, but that does not help. >> >> Some variables may be stored on the device. However, EU may not be >> valid. Could you try NL instead? > > Yes changing it to NL fixes this. This is still a bit problematic > though. Because what are we going to put in the nvram file we want > to put in linux-firmware ? Agree. I am surprised (not pleasantly) that these devices are not properly programmed and thus need nvram for the country code. >> > I believe that the Linux wifi stack is supposed to automatically >> > figure out the country settings based on AP provided info ? >> >> That depends. The device runs its own wifi stack which should have >> 802.11d support for what you describe. >> >> > But that does not seem to be working here ? Any hints on howto >> > debug this further would be appreciated. >> >> You could try doing "country" iovar get somewhere in >> brcmf_bus_started() to check country setting in firmware. > > Let me know if you still want me to do this given that ccode=NL fixes this. Well. Could you try it with ccode commented out in nvram file. Regards, Arend
