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. - Steve -- Steve deRosier Cal-Sierra Consulting LLC https://www.cal-sierra.com/