Steve deRosier <derosier@xxxxxxxxx> writes: > On Tue, Feb 27, 2018 at 12:33 AM, Kalle Valo <kvalo@xxxxxxxxxxxxxx> wrote: >> Luca Coelho <luca@xxxxxxxxx> writes: >> >>>> > We do have wiphy::max_ap_assoc_sta, but I see only ath10k, qtnfmac >>>> > and >>>> > rsi_91x setting it. I wish all drivers would use that. >>>> > >>>> > * @max_ap_assoc_sta: maximum number of associated stations >>>> > supported in AP mode >>>> > * (including P2P GO) or 0 to indicate no such limit is advertised. >>>> > The >>>> > * driver is allowed to advertise a theoretical limit that it can >>>> > reach in >>>> > * some cases, but may not always reach. >>>> >>>> Cool, I hadn't noticed this before. I'll add a patch to iwlwifi to >>>> add it. >>> >>> Actually this is not so straightforward, because every time we add a >>> p2p vif, we lose one more station. So the max_ap_assoc_sta value must >>> be dynamic (or we can state the theoretical lowest number to start >>> with, which would not be very nice). >>> >>> I don't think this feature is worth the trouble, so I'll skip it for >>> now. >> >> I think the documentation answers that part pretty well: >> >> "The driver is allowed to advertise a theoretical limit that it can >> reach in some cases, but may not always reach." >> >> So I still thank having the drivers to advertise the theoretical maximum >> numbers of client is useful, even if it would not be always 100% >> correct. For example, an average user most likely will not have any clue >> if the limit is 10, 50 or 100 clients. And besides, very few people use >> P2P anyway ;) >> >> But of course this is just nice-to-have category cand we have far more >> important things to fix first. >> > > From a practical point-of-view, many chipsets don't advertise this > information. Luca was able to look the limit up or knew it for his > chip. For example, on the ath6kl chips I most commonly have worked > with, the number is not specified by QCA and was only determined by us > via experimentation. And even on the same chip, it'll change with > firmware version as the necessary resources get consumed by new > features or fixes. If the firmware can send that number up to the > driver (or the driver can reliably know it because it can't change), > then expose it, but otherwise I'd advise publishing a value of 0. I'd > rather see the unknown flag rather than relying on a number that may > or may not be accurate. Yeah, definitely. The value needs to be based on facts, not guesses. -- Kalle Valo
