| Message ID | 91e68ca7f65bee7197ed5829ef91bc526df16e8a.1629508039.git.chunkeey@gmail.com |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
| Series | [RFC,v1,1/3] dt-bindings:net:wireless:qca,ath9k: add nvmem-cells for calibration data | expand |
| Context | Check | Description |
|---|---|---|
| robh/checkpatch | success |
Christian Lamparter <chunkeey@gmail.com> writes: > On most embedded ath9k devices (like range extenders, > routers, accesspoints, ...) the calibration data for > the RF/PHY is simply stored in a MTD partition named > "ART", "caldata"/"calibration", etc. > > Any mtd partition is automatically registered in the > nvmem subsystem. This makes is possible to fetch the > necessary calibration directly from there at the low > cost of adding nvmem cell information via the > device-tree or via similar means. > > This speeds up the driver's initialization a lot, > because the driver doesn't have to wait for userspace > to provide the data via helpers. > > Signed-off-by: Christian Lamparter <chunkeey@gmail.com> The series looks good to me. But I'm curious, why you marked this as RFC? Is there something controversial I missed?
On 21/08/2021 07:40, Kalle Valo wrote: > Christian Lamparter <chunkeey@gmail.com> writes: > >> On most embedded ath9k devices (like range extenders, >> routers, accesspoints, ...) the calibration data for >> the RF/PHY is simply stored in a MTD partition named >> "ART", "caldata"/"calibration", etc. >> >> Any mtd partition is automatically registered in the >> nvmem subsystem. This makes is possible to fetch the >> necessary calibration directly from there at the low >> cost of adding nvmem cell information via the >> device-tree or via similar means. >> >> This speeds up the driver's initialization a lot, >> because the driver doesn't have to wait for userspace >> to provide the data via helpers. >> >> Signed-off-by: Christian Lamparter <chunkeey@gmail.com> > > The series looks good to me. But I'm curious, why you marked this as > RFC? Is there something controversial I missed? yeah. Last night (it was already really late) I was tunnel-visioning at the thought that device-tree binding update was a must there. ... And ath9k's qca,ath9k.txt is still in that .txt and not .yaml format. So, I'm not sure if that file has to be converted first. (I couldn't get Rob's tools to work. And without them, I've no idea what error messages a converted .yaml of it will pop up) However... since then, I had the change to re-read: <https://www.kernel.org/doc/Documentation/nvmem/nvmem.txt> And found that nvmem cells and lookups can be specified in the old platform data way as well... So that binding patch 1/3 is optional. So, yeah. If nobody has an comment until next week, I'll post this series with only patches 2/3 and 3/3. Cheers, Christian
Christian Lamparter <chunkeey@gmail.com> writes: > On 21/08/2021 07:40, Kalle Valo wrote: >> Christian Lamparter <chunkeey@gmail.com> writes: >> >>> On most embedded ath9k devices (like range extenders, >>> routers, accesspoints, ...) the calibration data for >>> the RF/PHY is simply stored in a MTD partition named >>> "ART", "caldata"/"calibration", etc. >>> >>> Any mtd partition is automatically registered in the >>> nvmem subsystem. This makes is possible to fetch the >>> necessary calibration directly from there at the low >>> cost of adding nvmem cell information via the >>> device-tree or via similar means. >>> >>> This speeds up the driver's initialization a lot, >>> because the driver doesn't have to wait for userspace >>> to provide the data via helpers. >>> >>> Signed-off-by: Christian Lamparter <chunkeey@gmail.com> >> >> The series looks good to me. But I'm curious, why you marked this as >> RFC? Is there something controversial I missed? > > yeah. Last night (it was already really late) I was tunnel-visioning > at the thought that device-tree binding update was a must there. > ... And ath9k's qca,ath9k.txt is still in that .txt and not .yaml > format. So, I'm not sure if that file has to be converted first. > (I couldn't get Rob's tools to work. And without them, I've no idea > what error messages a converted .yaml of it will pop up) > > However... since then, I had the change to re-read: > <https://www.kernel.org/doc/Documentation/nvmem/nvmem.txt> > > And found that nvmem cells and lookups can be specified in > the old platform data way as well... So that binding patch > 1/3 is optional. > > So, yeah. If nobody has an comment until next week, I'll post this > series with only patches 2/3 and 3/3. Sounds good, thanks for the background.
On Sat, Aug 21, 2021 at 10:02:57PM +0200, Christian Lamparter wrote: > On 21/08/2021 07:40, Kalle Valo wrote: > > Christian Lamparter <chunkeey@gmail.com> writes: > > > > > On most embedded ath9k devices (like range extenders, > > > routers, accesspoints, ...) the calibration data for > > > the RF/PHY is simply stored in a MTD partition named > > > "ART", "caldata"/"calibration", etc. > > > > > > Any mtd partition is automatically registered in the > > > nvmem subsystem. This makes is possible to fetch the > > > necessary calibration directly from there at the low > > > cost of adding nvmem cell information via the > > > device-tree or via similar means. > > > > > > This speeds up the driver's initialization a lot, > > > because the driver doesn't have to wait for userspace > > > to provide the data via helpers. > > > > > > Signed-off-by: Christian Lamparter <chunkeey@gmail.com> > > > > The series looks good to me. But I'm curious, why you marked this as > > RFC? Is there something controversial I missed? > > yeah. Last night (it was already really late) I was tunnel-visioning > at the thought that device-tree binding update was a must there. > ... And ath9k's qca,ath9k.txt is still in that .txt and not .yaml > format. So, I'm not sure if that file has to be converted first. That would be nice, but it still falls under my bar for must convert first. :) > (I couldn't get Rob's tools to work. And without them, I've no idea > what error messages a converted .yaml of it will pop up) What issue were you having? Rob
On Sat, 21 Aug 2021 03:09:13 +0200, Christian Lamparter wrote: > On most embedded ath9k devices (like range extenders, > routers, accesspoints, ...) the calibration data for > the RF/PHY is simply stored in a MTD partition named > "ART", "caldata"/"calibration", etc. > > Any mtd partition is automatically registered in the > nvmem subsystem. This makes is possible to fetch the > necessary calibration directly from there at the low > cost of adding nvmem cell information via the > device-tree or via similar means. > > This speeds up the driver's initialization a lot, > because the driver doesn't have to wait for userspace > to provide the data via helpers. > > Signed-off-by: Christian Lamparter <chunkeey@gmail.com> > --- > .../devicetree/bindings/net/wireless/qca,ath9k.txt | 10 ++++++++++ > 1 file changed, 10 insertions(+) > Acked-by: Rob Herring <robh@kernel.org>
diff --git a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt index aaaeeb5f935b..88b322b55dd8 100644 --- a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt +++ b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt @@ -34,6 +34,13 @@ Optional properties: ath9k wireless chip (in this case the calibration / EEPROM data will be loaded from userspace using the kernel firmware loader). +- nvmem-cells: A phandle pointing to a nvmem-cells node representing registers + that has information about the MAC-Address or + calibration data. + Please refer the for nvmem-cells bindings + Documentation/devicetree/bindings/nvmem/nvmem.yaml. +- nvmem-cell-names: Should be "address" for the MAC address. "calibration" + for ART/caldata. The MAC address will be determined using the optional properties defined in net/ethernet.txt. @@ -44,5 +51,8 @@ In this example, the node is defined as child node of the PCI controller: compatible = "pci168c,002d"; reg = <0x7000 0 0 0 0x1000>; qca,no-eeprom; + + nvmem-cells = <&macaddr_art_c>, <&cal_art_1000>; + nvmem-cell-names = "mac-address", "calibration"; }; };
On most embedded ath9k devices (like range extenders, routers, accesspoints, ...) the calibration data for the RF/PHY is simply stored in a MTD partition named "ART", "caldata"/"calibration", etc. Any mtd partition is automatically registered in the nvmem subsystem. This makes is possible to fetch the necessary calibration directly from there at the low cost of adding nvmem cell information via the device-tree or via similar means. This speeds up the driver's initialization a lot, because the driver doesn't have to wait for userspace to provide the data via helpers. Signed-off-by: Christian Lamparter <chunkeey@gmail.com> --- .../devicetree/bindings/net/wireless/qca,ath9k.txt | 10 ++++++++++ 1 file changed, 10 insertions(+)