From: Arend Van Spriel <arend.vanspriel@broadcom.com> To: Martin Blumenstingl <martin.blumenstingl@googlemail.com>, ath9k-devel@qca.qualcomm.com, linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org Cc: nbd@nbd.name, chunkeey@googlemail.com, mark.rutland@arm.com, robh+dt@kernel.org Subject: Re: [PATCH RFC v2 1/2] Documentation: dt: net: add ath9k wireless device binding Date: Thu, 23 Jun 2016 21:25:48 +0200 [thread overview] Message-ID: <5bba7624-ad61-f603-5574-d9863e2c666e@broadcom.com> (raw) In-Reply-To: <20160623174536.5967-2-martin.blumenstingl@googlemail.com> On 23-6-2016 19:45, Martin Blumenstingl wrote: > Add documentation how devicetree can be used to configure ath9k based > devices. > > Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> > --- > changes in v1 -> v2: > - use vendor prefix "qca" instead of "ath" > - extend the example so it includes the "compatible" property > > .../devicetree/bindings/net/wireless/qca,ath9k.txt | 41 ++++++++++++++++++++++ > 1 file changed, 41 insertions(+) > create mode 100644 Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt > > diff --git a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt > new file mode 100644 > index 0000000..bb78f68 > --- /dev/null > +++ b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt > @@ -0,0 +1,41 @@ > +* Qualcomm Atheros ath9k wireless devices > + > +This node provides properties for configuring the ath9k wireless device. The > +node is expected to be specified as a child node of the PCI controller to > +which the wireless chip is connected. > + > +Required properties: > +- compatible: Should be "qca,ath9k" > + > +Optional properties: > +- reg: Address and length of the register set for the device. Is 'reg' property handled. I don't see it in patch 2/2. > +- qca,gpio-mask: The GPIO mask > +- qca,gpio-val: The GPIO value > +- qca,led-pin: The GPIO number to which the LED is connected > +- qca,led-active-high: The LED is active when the GPIO is HIGH > +- qca,clk-25mhz: Defines that at 25MHz clock is used For the above I can somehow see them as variables for different hardware platforms. > +- qca,eeprom-name: The name of the file which contains the EEPROM data (which > + will be loaded via request_firmware) > +- qca,check-eeprom-endianness: Allow checking the EEPROM endianness and > + swapping of the EEPROM data if required > +- qca,disable-2ghz: Disables the 2.4GHz band, even if enabled in the EEPROM > +- qca,disable-5ghz: Disables the 5GHz band, even if enabled in the EEPROM These not really. Storing filename information in device tree seems wrong as it does not describe hardware configuration. The other three also seem more like driver module parameters. I think what you are trying here with the last two properties is to use the same eeprom file for different types of hardware, ie. for dual-band, 2g-only, and 5g-only devices. From device tree perspective I would use those types, eg.: qca,2g-capable: Device can operate in 2.4GHz band. qca,5g-capable: Device can operate in 5GHz band. The other patch also looks for a MAC address for the device. I suppose that should be documented as well. > +In this example, the node is defined as child node of the PCI controller. > + > +pci { > + pcie@0 { > + reg = <0 0 0 0 0>; > + #interrupt-cells = <1>; > + #size-cells = <2>; > + #address-cells = <3>; > + device_type = "pci"; > + > + ath9k@0,0 { > + compatible = "qca,ath9k"; > + reg = <0 0 0 0 0>; > + device_type = "pci"; Is this just a copy-paste or should device_type be specified? Regards, Arend
WARNING: multiple messages have this Message-ID (diff)
From: Arend Van Spriel <arend.vanspriel@broadcom.com> To: ath9k-devel@lists.ath9k.org Subject: [ath9k-devel] [PATCH RFC v2 1/2] Documentation: dt: net: add ath9k wireless device binding Date: Thu, 23 Jun 2016 19:33:02 -0000 [thread overview] Message-ID: <5bba7624-ad61-f603-5574-d9863e2c666e@broadcom.com> (raw) In-Reply-To: <20160623174536.5967-2-martin.blumenstingl@googlemail.com> On 23-6-2016 19:45, Martin Blumenstingl wrote: > Add documentation how devicetree can be used to configure ath9k based > devices. > > Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> > --- > changes in v1 -> v2: > - use vendor prefix "qca" instead of "ath" > - extend the example so it includes the "compatible" property > > .../devicetree/bindings/net/wireless/qca,ath9k.txt | 41 ++++++++++++++++++++++ > 1 file changed, 41 insertions(+) > create mode 100644 Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt > > diff --git a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt > new file mode 100644 > index 0000000..bb78f68 > --- /dev/null > +++ b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt > @@ -0,0 +1,41 @@ > +* Qualcomm Atheros ath9k wireless devices > + > +This node provides properties for configuring the ath9k wireless device. The > +node is expected to be specified as a child node of the PCI controller to > +which the wireless chip is connected. > + > +Required properties: > +- compatible: Should be "qca,ath9k" > + > +Optional properties: > +- reg: Address and length of the register set for the device. Is 'reg' property handled. I don't see it in patch 2/2. > +- qca,gpio-mask: The GPIO mask > +- qca,gpio-val: The GPIO value > +- qca,led-pin: The GPIO number to which the LED is connected > +- qca,led-active-high: The LED is active when the GPIO is HIGH > +- qca,clk-25mhz: Defines that at 25MHz clock is used For the above I can somehow see them as variables for different hardware platforms. > +- qca,eeprom-name: The name of the file which contains the EEPROM data (which > + will be loaded via request_firmware) > +- qca,check-eeprom-endianness: Allow checking the EEPROM endianness and > + swapping of the EEPROM data if required > +- qca,disable-2ghz: Disables the 2.4GHz band, even if enabled in the EEPROM > +- qca,disable-5ghz: Disables the 5GHz band, even if enabled in the EEPROM These not really. Storing filename information in device tree seems wrong as it does not describe hardware configuration. The other three also seem more like driver module parameters. I think what you are trying here with the last two properties is to use the same eeprom file for different types of hardware, ie. for dual-band, 2g-only, and 5g-only devices. From device tree perspective I would use those types, eg.: qca,2g-capable: Device can operate in 2.4GHz band. qca,5g-capable: Device can operate in 5GHz band. The other patch also looks for a MAC address for the device. I suppose that should be documented as well. > +In this example, the node is defined as child node of the PCI controller. > + > +pci { > + pcie at 0 { > + reg = <0 0 0 0 0>; > + #interrupt-cells = <1>; > + #size-cells = <2>; > + #address-cells = <3>; > + device_type = "pci"; > + > + ath9k at 0,0 { > + compatible = "qca,ath9k"; > + reg = <0 0 0 0 0>; > + device_type = "pci"; Is this just a copy-paste or should device_type be specified? Regards, Arend
next prev parent reply other threads:[~2016-06-23 19:25 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-06-23 17:45 [RFC v2] ath9k: add devicetree support to ath9k Martin Blumenstingl 2016-06-23 17:45 ` [ath9k-devel] " Martin Blumenstingl 2016-06-23 17:45 ` [PATCH RFC v2 1/2] Documentation: dt: net: add ath9k wireless device binding Martin Blumenstingl 2016-06-23 17:45 ` [ath9k-devel] " Martin Blumenstingl 2016-06-23 17:58 ` Mark Rutland 2016-06-23 18:08 ` [ath9k-devel] " Mark Rutland 2016-06-23 18:14 ` Martin Blumenstingl 2016-06-23 18:14 ` [ath9k-devel] " Martin Blumenstingl 2016-06-27 12:57 ` Mark Rutland 2016-06-27 12:57 ` [ath9k-devel] " Mark Rutland 2016-06-27 13:07 ` Felix Fietkau 2016-06-27 13:07 ` [ath9k-devel] " Felix Fietkau 2016-06-27 14:58 ` Martin Blumenstingl 2016-06-27 14:58 ` [ath9k-devel] " Martin Blumenstingl 2016-06-23 19:25 ` Arend Van Spriel [this message] 2016-06-23 19:33 ` Arend Van Spriel 2016-06-23 21:46 ` Martin Blumenstingl 2016-06-23 21:46 ` [ath9k-devel] " Martin Blumenstingl 2016-06-23 17:45 ` [PATCH RFC v2 2/2] ath9k: parse the device configuration from an OF node Martin Blumenstingl 2016-06-23 17:45 ` [ath9k-devel] " Martin Blumenstingl
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=5bba7624-ad61-f603-5574-d9863e2c666e@broadcom.com \ --to=arend.vanspriel@broadcom.com \ --cc=ath9k-devel@lists.ath9k.org \ --cc=ath9k-devel@qca.qualcomm.com \ --cc=chunkeey@googlemail.com \ --cc=linux-wireless@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=martin.blumenstingl@googlemail.com \ --cc=nbd@nbd.name \ --cc=robh+dt@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.