"Peer, Ilan" <ilan.peer@xxxxxxxxx> writes: > Hi, > >> > >> > As depicted above, the need to inform the driver about the intended >> > usage of the interface is real. >> >> Sure, I can understand the need is real. This just feels like an ugly workaround, >> not a proper solution. >> > > If you have a different solution in mind, please share. Yeah, fix the root cause :) >> And the documentation for this is quite vague, I'm worried how do we get >> similarly working drivers? Let's say if I were to implement a user space >> application for this, or a driver implementation for that matter, it would be a >> guessing game for me. For example, what's "soon" in this context? 5 mins, 50 >> secs or 5 secs? Can the mac80211 operation sleep? >> > > I understand this is not clear. The intention was to say that by the > time the interface is enabled, > the interface type might change, and that the driver should be aware > of that. I can try to better express > this in the command and documentation. > >> So user space is now always supposed to always call this nl80211 command >> and at what stage exactly? Or is it optional? But if it's optional what's the point >> of adding it? >> > > It is optional. User space should use it when it expects the interface type to > change before the interface is activated. If this is optional for user space (wpasupplicant, iwd etc.) then the driver cannot rely on it being called, no? So this command cannot be used for anything important because it's optional. Also I'm worried how this will give a different user experience based on if the user space calls this optional command or not. The way I see that this is designed just to workaround one iwlwifi bug, not really as a generic nl80211 command which could be useful for all drivers. But I'm more than happy to be proven wrong! >> > We encountered several P2P cases in which an interface was added and >> > P2P Group Ownership Negotiation and P2P Invitation signalling were >> > completed successfully, but the P2P Group Session establishment failed >> > since the interface type changed from P2P Client to P2P GO and the >> > local device was no longer able to accommodate the P2P GO operation >> > due to resource constraints. >> > >> > With this new API, user space can now inform the driver about the >> > intended usage of the interface so the driver will make the resources >> > available for all possible interface types. With this the information >> > exchanged during the P2P signalling would correctly reflect state and >> > the P2P group session would be able to be established. >> >> Why not allocate the resources during driver initialisation? Or when changing >> the interface? Why need this weird interface? >> > > Allocating resources to all possible interface combinations etc. is waste as > not all allocations would eventually be used. Sure, in ath11k/ath12k we have problems with resource allocation as well, for example how to allocate firmware memory (number of clients vs size data buffers etc), and we really should find a solution for that. Quite a few people are pushing for INI files to be able to configure wireless driver resource allocation but I cannot see how that would be accepted to upstream. It would be great find some type of dynamic configuration solution for wireless drivers, for example devlink or similar. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
