On 3/3/2025 3:50 PM, Johannes Berg wrote: > On Mon, 2025-03-03 at 15:48 +0530, Roopni Devanathan wrote: >>> >>> The order here also seems really odd? That basically means the driver >>> now needs to propagate it to all the radios, but you still have >>> different per-radio values at that point, that seems bad. You also >>> didn't even document any such assumptions. >> >> The idea is to maintain different variables for global RTS threshold and >> per-radio RTS threshold. Each time RTS threshold of a radio is getting >> changed, we are trying to update the RTS threshold for that radio alone. If >> global RTS threshold(rdev->wiphy.rts_threshold) is updated, we are trying to >> change the RTS threshold of all radios. This is the reason we are assigning >> same value - rts_threshold, to all radios. >> > > Sure, I get that, I just thought maybe it should be *before* calling the > driver, that way the driver can always access the per-radio thresholds > anyway, and just has to figure out whether to set all or not? > > Then you have to roll back if it fails, but the driver doesn't have to > track it individually itself? > Understood, thanks for explaining. In that case I can move the code snippet of setting per-radio RTS threshold before calling the driver. In this case, if setting RTS threshold fails, we might need to roll back to previous values. We might need to create local copies of RTS threshold values for each radio like other global attributes. While extending this design to other per-radio attributes, we might need to create local copies to store all per-radio attributes. Is this design okay? > johannes
