Bartosz Golaszewski <brgl@xxxxxxxx> writes: > On Thu, Jun 6, 2024 at 6:16 PM Kalle Valo <kvalo@xxxxxxxxxx> wrote: > >> >> Bartosz Golaszewski <brgl@xxxxxxxx> writes: >> >> > On Thu, Jun 6, 2024 at 4:02 PM Kalle Valo <kvalo@xxxxxxxxxx> wrote: >> > >> >> Sure, I'm not worried about functionality. I'm worried that if I >> >> there's, for example, an ARM based setup which uses DT and wants to use >> >> a similar QCA6390 board that I have, and set >> >> qcom,ath11k-calibration-variant in DT. In other words, I'm worried if >> >> you are looking at this only for Snapdragon family of boards? >> >> >> > >> > No, what I'm looking at is the entire QCA6390 package. That means WLAN >> > *and* Bluetooth *and* the PMU that manages power. >> >> I think we are just looking at this from different point of views. You >> are looking at a datasheet (most likely for a Snapdragon based system) >> and I'm looking what actual devices there are out in the field. >> >> > If you're using the QCA6390 on a device-tree system then you should >> > probably model at least the WLAN node and the PMU and the problem with >> > supplies is fixed. >> >> But why? If there are boards out there who don't need any of this why >> would they still need to model all this in DT? >> > > Because this is what is there? The goal of the device tree is to > describe the hardware. The fact we didn't describe it before doesn't > make it correct. > >> Based on the discussions I have heard only Snapdragon systems who >> require all this configuration you describe. Of course there can be >> other systems but I have not heard about those. >> > > DT is not configuration, it is description of actual hardware. It > doesn't matter if Snapdragon systems are the only ones that actually > *require* this description to make WLAN/BT functional upstream. The > chipset would be the same on any PCIe board, it's just that the host > systems wouldn't need to take care with its power sequence. But for a > dynamic board like this, you don't need DT. > >> > But if you don't have the supplies, that's alright for downstream. >> >> What do you mean downstream in this context? >> > > I mean: if you wanted to upstream the DT sources, then they should > include the supplies AND the PMU node. But if you just want to make > the WLAN run on some vendor kernel then you don't need to think about > it, it will work. > >> >> Again, I don't see this as a blocker. I just want to understand how this >> >> should work for all types of devices there are out there. >> >> >> >> > But if you have a QCA6390 then you have its PMU too and the bindings >> >> > model the real-world hardware. >> >> > >> >> > IOW: your laptop should be alright but the supplies are really there >> >> > which warrants adding them to the bindings. >> >> >> >> Sorry, not following here. Can you clarify your comment "the supplies >> >> are really there"? You mean inside the PCI board? But that's not visible >> >> to the kernel in anyway, the PCI board just works after I plug it in. >> >> It's like a regular PCI device. So I don't understand why that should be >> >> visible in DT, but I can very well be missing something. >> >> >> > >> > I think you're thinking about some kind of detachable PCIe board with >> > this chipset on it. >> >> Exactly, a lot of WLAN boards are like this. >> >> > I refer to the QCA6390 chipset itself which is also more than just >> > PCI. The Bluetooth interface doesn't use PCI at all. On the boards I'm >> > working on, the chipset is just soldered to the main board. >> >> And I guess you are looking at Snapdragon boards only? >> > > But what is your point? My point (again) is that to me it look likes that you are looking this only for Snapdragon type of devices and ignoring the rest. I am looking at this to support _all_ type of devices and I want to make sure that we don't have any artificial restrictions to use ath11k or ath12k devices in upstream Linux. I could not find a public example of a QCA6390 M.2 board like I have, but here's one for QCA2066: https://compex.com.sg/shop/wifi-module/wlt206h-wifi6-ble5-1-11ax-qca2062-qca2065/ QCA2066 is a mobile chipset supported by ath11k, similarly like QCA6390. It's just newer and different features, and with a different PCI id. In the past using these kind of M.2 boards for Wi-Fi has been quite common but don't know how commit it is nowadays. >> > If your detachable board "just works" then it must be wired in a way >> > that enables WLAN the moment it's plugged in but this doesn't happen >> > over PCI. The chipset has a power input and GPIOs to enable each >> > module. >> >> I don't know how the boards are implemented but it could be so. But from >> host system point of view it's just a regular PCI device. >> > > And you don't need DT anyway for this type of devices. I wish we wouldn't need to use DT for such M.2 boards, but we do need to use qcom,ath11k-calibration-variant in some cases when the device (or the firmware) doesn't provide unique enough identifier to choose the correct board file automatically. I already mentioned the property in my earlier emails. I hope this clears up what I'm trying to say. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
