On Tue, 2025-09-02 at 18:14 +1000, Lachlan Hodges wrote: > > Consider the difference between AU and US in the regdb (the only > > countries currently listed with S1G support): > > > > country AU: DFS-ETSI > > (915 - 920 @ 4), (1000 mW) > > (920 - 928 @ 8), (1000 mW) > > > > country US: DFS-FCC > > (902 - 904 @ 2), (30) > > (904 - 920 @ 16), (30) > > (920 - 928 @ 8), (30) > > > > I'm not sure which operating class you're applying to get those channel > > numbers in your figure above, so I'm going to have to handwave a bit. > > But assuming such a restriction also applies on the lower band edge > > (OFDM is symmetric, so it probably should) then you'd have to disable > > The restrictions are not necessarily symmetric as adjacent bands may have > different limitations. Oh OK, so it's a bit more complex than what it seemed earlier, but that makes sense. > > different channels in AU and US regdomains, since one starts at 902 MHz > > and the other only at 915 MHz. So for a channel that's between 915/916 > > MHz (which according to your figure I guess would be channel 27?) you'd > > probably have to disable it in AU but not disable it in the US? > > For what it's worth, our current hardware does not disable AU channel 27 as > the emissions restrictions make it usable, but upper channels (eg 51) are > disabled. Right. > > So I'm not sure statically disabling the channels from the driver works > > unless you assume there's no regulatory domain involved or anything? > > > > If I'm right about this, then perhaps it should be expressed as a > > (wiphy-specific) "primary channel band edge distance"? > > Currently our existing driver queries the disabled channels from a binary blob > passed to chip firmware on initialisation/reg notification. This isn't quite a > complete regdom. Right, I was more thinking if you know this device is now operating in AU then things might change. > Our expectation for a future upstream driver would be to statically > advertise the entire set of potential supported channels, but to query the chip > firmware on initialisation or on reg notification so as to dynamically mark > channels NO_PRIMARY when required. Sort of similar to what the rsi_91x driver > is doing for NO_IR. That works I guess. > There are still issues with S1G channelisation that we will need to solve later > on (op classes, varying channel starting frequency etc.). I'll go reply to your other mail too. johannes
