Re: [PATCH 01/49] dt: bindings: net: add qcom,ath11k.txt
On Tue, Aug 20, 2019 at 06:47:27PM +0300, Kalle Valo wrote:
Missing commit message and Sob (and on the other patches).
> ---
> .../bindings/net/wireless/qcom,ath11k.txt | 127
> +
> 1 file changed, 127 insertions(+)
Please use the DT schema format (YAML). See writing-schema.md.
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.txt
> b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.txt
> new file mode 100644
> index ..1824238b4b50
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.txt
> @@ -0,0 +1,127 @@
> +* Qualcomm Technologies ath11k wireless devices
> +
> +Required properties:
> +- compatible: Should be "qcom,ipq8074-wifi"
> +
> +AHB based ipq8074 uses most of the properties defined in this doc.
> +
> +Optional properties:
> +- reg: Address and length of the register set for the device.
> +- interrupts: List of interrupt lines. Must contain an entry
> + for each entry in the interrupt-names property.
Need to be explicit as to how many interrupts and what they are.
> +- interrupt-names: Must include the entries for CE interrupt
> +names ("ce0" to "ce11") and hw srng interrupt
> +names.
> +- qcom,rproc: DT entry of q6v5-wcss
> +
> +Example:
> +
> +wifi0: wifi@c00 {
> + compatible = "qcom,ipq8074-wifi";
> + reg = <0xc00 0x200>;
> + interrupts = <0 320 1>,
> + <0 319 1>,
> + <0 318 1>,
> + <0 317 1>,
> + <0 316 1>,
> + <0 315 1>,
> + <0 314 1>,
> + <0 311 1>,
> + <0 310 1>,
> + <0 411 1>,
> + <0 410 1>,
> + <0 40 1>,
> + <0 39 1>,
> + <0 302 1>,
> + <0 301 1>,
> + <0 37 1>,
> + <0 36 1>,
> + <0 296 1>,
> + <0 295 1>,
> + <0 294 1>,
> + <0 293 1>,
> + <0 292 1>,
> + <0 291 1>,
> + <0 290 1>,
> + <0 289 1>,
> + <0 288 1>,
> + <0 239 1>,
> + <0 236 1>,
> + <0 235 1>,
> + <0 234 1>,
> + <0 233 1>,
> + <0 232 1>,
> + <0 231 1>,
> + <0 230 1>,
> + <0 229 1>,
> + <0 228 1>,
> + <0 224 1>,
> + <0 223 1>,
> + <0 203 1>,
> + <0 183 1>,
> + <0 180 1>,
> + <0 179 1>,
> + <0 178 1>,
> + <0 177 1>,
> + <0 176 1>,
> + <0 163 1>,
> + <0 162 1>,
> + <0 160 1>,
> + <0 159 1>,
> + <0 158 1>,
> + <0 157 1>,
> + <0 156 1>;
> + interrupt-names = "misc-pulse1",
> + "misc-latch",
> + "sw-exception",
> + "watchdog",
> + "ce0",
> + "ce1",
> + "ce2",
> + "ce3",
> + "ce4",
> + "ce5",
> + "ce6",
> + "ce7",
> + "ce8",
> + "ce9",
> + "ce10",
> + "ce11",
> + "host2wbm-desc-feed",
> + "host2reo-re-injection",
> + "host2reo-command",
> + "host2rxdma-monitor-ring3",
> + "host2rxdma-monitor-ring2",
> + "host2rxdma-monitor-ring1",
> + "reo2ost-exception",
> + "wbm2host-rx-release",
> + "reo2host-status",
> + "reo2host-destination-ring4",
> + "reo2host-destination-ring3",
> + "reo2host-destination-ring2",
> + "reo2host-destination-ring1",
> + "rxdma2host-monitor-destination-mac3",
> + "rxdma2host-monitor-destination-mac2",
> + "rxdma2host-monitor-destination-mac1",
> + "ppdu-end-interrupts-mac3",
> + "ppdu-end-interrupts-mac2",
> + "ppdu-end-interrupts-mac1",
> + "rxdma2host-monitor-status-ring-mac3",
> + "rxdma2host-monitor-status-ring-mac2",
> + "rxdma2host-monitor-status-ring-mac1",
> + "host2rxdma-host-buf-ring-mac3",
> + "host2rxdma-host-buf-ring-mac2",
> +
Re: [PATCH 2/3] dt-bindings: net: mt76: update binding for mt7603 driver
On Wed, 30 Jan 2019 15:07:55 +0100, Felix Fietkau wrote: > In addition to MT7603E PCI devices, the driver supports the WLAN core on > MT7628/MT7688, which needs to be defined in DT. > > Signed-off-by: Felix Fietkau > --- > .../bindings/net/wireless/mediatek,mt76.txt | 19 +++ > 1 file changed, 19 insertions(+) > Reviewed-by: Rob Herring
Re: [PATCH v4 1/3] dt-bindings: net: ath10k: fix node name and device type in qcom ath10k example
On Tue, 11 Dec 2018 21:43:22 +0530, Bhagavathi Perumal S wrote: > In qcom,ath10k documentation, ath10k is used as node name in the example of > pci based device. Normally, node name should be class of device and not the > model name, so fix it to node name "wifi". And remove the property device_type > pci since only pci bridges should have this property. > > Signed-off-by: Bhagavathi Perumal S > --- > Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > Reviewed-by: Rob Herring
Re: [PATCH v4 2/3] dt-bindings: net: ath10k: add new dt entry to identify external FEM
On Tue, Dec 11, 2018 at 09:43:23PM +0530, Bhagavathi Perumal S wrote: > This adds new dt entry ext-fem-name, it is used by ath10k driver > to select correct timing parameters and configure it in target wifi hardware. > The Front End Module(FEM) normally includes tx power amplifier(PA) and > rx low noise amplifier(LNA). The default timing parameters like tx end to > PA off timing values were fine tuned for internal FEM used in reference > design. And these timing values can not be same if ODM modifies hardware > design with different external FEM. This DT entry helps to choose correct > timing values in driver if different external FEM hardware used. > > Signed-off-by: Bhagavathi Perumal S > --- > Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) Please add acks/reviewed-bys when posting new versions.
Re: [PATCH v3 2/3] dt-bindings: net: ath10k: add new dt entry to identify external FEM
On Tue, 11 Dec 2018 00:01:30 +0530, Bhagavathi Perumal S wrote: > This adds new dt entry ext-fem-name, it is used by ath10k driver > to select correct timing parameters and configure it in target wifi hardware. > The Front End Module(FEM) normally includes tx power amplifier(PA) and > rx low noise amplifier(LNA). The default timing parameters like tx end to > PA off timing values were fine tuned for internal FEM used in reference > design. And these timing values can not be same if ODM modifies hardware > design with different external FEM. This DT entry helps to choose correct > timing values in driver if different external FEM hardware used. > > Signed-off-by: Bhagavathi Perumal S > --- > Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > Reviewed-by: Rob Herring
Re: [PATCH v3 1/3] dt-bindings: net: ath10k: fix node name and device type in qcom ath10k example
On Tue, Dec 11, 2018 at 12:01:29AM +0530, Bhagavathi Perumal S wrote:
> In qcom,ath10k documentation, ath10k is used as node name in the example of
> pci based device. Normally, node name shoud be class of device and not the
> model
s/shoud/should/
> name, so fix it to node name "wifi". And remove the property device_type pci
> since only pci bridges should have this property.
>
> Signed-off-by: Bhagavathi Perumal S
> ---
> Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> index 2196d1a..ef60f25 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> @@ -74,9 +74,8 @@ pci {
> #address-cells = <3>;
> device_type = "pci";
>
> - ath10k@0,0 {
> + wifi@0,0 {
> reg = <0 0 0 0 0>;
> - device_type = "pci";
> qcom,ath10k-calibration-data = [ 01 02 03 ... ];
> };
> };
> --
> 1.9.1
>
Re: [PATCH 1/2] dt: bindings: add new dt entry to indentify external FEM
On Tue, Oct 30, 2018 at 3:41 AM wrote:
>
> On 2018-10-16 00:54, Rob Herring wrote:
> > On Thu, Oct 04, 2018 at 05:12:43PM +0530, Bhagavathi Perumal S wrote:
> >> This adds new dt entry ext-fem-name, it is used by ath10k driver
> >> to select correct timing parameters and configure it in target wifi
> >> hardware.
> >> The Front End Module(FEM) normally includes tx power amplifier(PA) and
> >> rx low noise amplifier(LNA). The default timing parameters like tx end
> >> to
> >> PA off timing values were fine tuned for internal FEM used in
> >> reference
> >> design. And these timing values can not be same if ODM modifies
> >> hardware
> >> design with different external FEM. This DT entry helps to choose
> >> correct
> >> timing values in driver if different external FEM hardware used.
> >
> > 'dt-bindings: net: ath10k: ...' for the subject please.
> Sure, I will change and send v2 patch.
>
> >
> >>
> >> Signed-off-by: Bhagavathi Perumal S
> >> ---
> >> .../bindings/net/wireless/qcom,ath10k.txt | 22
> >> ++
> >> 1 file changed, 22 insertions(+)
> >>
> >> diff --git
> >> a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> >> b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> >> index 7fd4e8c..fbaf309 100644
> >> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> >> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> >> @@ -56,6 +56,7 @@ Optional properties:
> >> the length can vary between hw versions.
> >> - -supply: handle to the regulator device tree node
> >> optional "supply-name" is "vdd-0.8-cx-mx".
> >> +- ext-fem-name: name of external front end module used.
> >
> > What are valid names? What if the OS doesn't recognize the name?
> > Perhaps
> Some valid FEM devices are "microsemi-lx5586", "sky85703-11" and
> "sky85803" etc.
> Currently driver accepts only "microsemi-lx5586", Since this FEM
> requires different timing settings,
Assuming you keep this, then you need to enumerate what are valid
values in the binding. Otherwise, 'ext-fem-name = "rob"' is valid.
> And it can be extended for other FEM devices in future.
> If OS doesn't recognize the name, it uses predefined default timing
> settings.
>
> > this should be a compatible string for the particular module instead?
> > Then it could cover any differences, not just the FEM.
> >
> No, it is specific to FEM device.
You will be better off having either a specific compatible string or
using VID/PID as this is a PCI device. Then you can handle other
differences you may find between h/w versions without a DT change.
> >>
> >> Example (to supply the calibration data alone):
> >>
> >> @@ -150,3 +151,24 @@ wifi@1800 {
> >> <0 141 0 /* CE11 */ >;
> >> vdd-0.8-cx-mx-supply = <&pm8998_l5>;
> >> };
> >> +
> >> +Example (to supply the external front end module name):
> >> +
> >> +In this example, the front end module is defined as a property of the
> >> ath10k
> >> +device node.
> >
> > Really need a whole new example for 1 property?
> Will add this property in existing example.
>
> >
> >> +
> >> +pci {
> >> +pcie@0 {
> >> +reg = <0 0 0 0 0>;
> >> +#interrupt-cells = <1>;
> >> +#size-cells = <2>;
> >> +#address-cells = <3>;
> >> +device_type = "pci";
> >> +
> >> +ath10k@0,0 {
> >
> > wifi@0,0
> Added in ath10k@0,0 to make consistent with existing property
> "qcom,ath10k-calibration-data" below,
> "
I don't see how that matters.
> pci {
> pcie@0 {
> reg = <0 0 0 0 0>;
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> device_type = "pci";
>
> ath10k@0,0 {
> reg = <0 0 0 0 0>;
> device_type = "pci";
> qcom,ath10k-calibration-data = [ 01 02 03 ... ];
> };
> };
> };
> "
>
> If wifi@0,0 is preferable, then I will add new entry "wifi@0,0" and add
> ext-fem-name into it.
Node names are supposed to reflect the class of device, not the model.
See the DT spec for a list.
>
> >
> >> +reg = <0 0 0 0 0>;
> >> +device_type = "pci";
Also, this is wrong. Only PCI bridges should have this property. dtc
will give you a warning on this.
> >> +ext-fem-name = "microsemi-lx5586";
> >> +};
> >> +};
> >> +};
> >> --
> >> 1.9.1
> >>
>
> Thanks, Sorry for the delayed response,
> Bhagavathi Perumal S.
Re: [PATCH 1/2] dt: bindings: add new dt entry to indentify external FEM
On Thu, Oct 04, 2018 at 05:12:43PM +0530, Bhagavathi Perumal S wrote:
> This adds new dt entry ext-fem-name, it is used by ath10k driver
> to select correct timing parameters and configure it in target wifi hardware.
> The Front End Module(FEM) normally includes tx power amplifier(PA) and
> rx low noise amplifier(LNA). The default timing parameters like tx end to
> PA off timing values were fine tuned for internal FEM used in reference
> design. And these timing values can not be same if ODM modifies hardware
> design with different external FEM. This DT entry helps to choose correct
> timing values in driver if different external FEM hardware used.
'dt-bindings: net: ath10k: ...' for the subject please.
>
> Signed-off-by: Bhagavathi Perumal S
> ---
> .../bindings/net/wireless/qcom,ath10k.txt | 22
> ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> index 7fd4e8c..fbaf309 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> @@ -56,6 +56,7 @@ Optional properties:
>the length can vary between hw versions.
> - -supply: handle to the regulator device tree node
> optional "supply-name" is "vdd-0.8-cx-mx".
> +- ext-fem-name: name of external front end module used.
What are valid names? What if the OS doesn't recognize the name? Perhaps
this should be a compatible string for the particular module instead?
Then it could cover any differences, not just the FEM.
>
> Example (to supply the calibration data alone):
>
> @@ -150,3 +151,24 @@ wifi@1800 {
> <0 141 0 /* CE11 */ >;
> vdd-0.8-cx-mx-supply = <&pm8998_l5>;
> };
> +
> +Example (to supply the external front end module name):
> +
> +In this example, the front end module is defined as a property of the ath10k
> +device node.
Really need a whole new example for 1 property?
> +
> +pci {
> + pcie@0 {
> + reg = <0 0 0 0 0>;
> + #interrupt-cells = <1>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + device_type = "pci";
> +
> + ath10k@0,0 {
wifi@0,0
> + reg = <0 0 0 0 0>;
> + device_type = "pci";
> + ext-fem-name = "microsemi-lx5586";
> + };
> + };
> +};
> --
> 1.9.1
>
Re: [PATCH] dt-bindings: Add bindings for aliases node
On Tue, Oct 09, 2018 at 11:31:42AM -0700, Brian Norris wrote:
> On Tue, Oct 09, 2018 at 09:22:07AM +0200, Geert Uytterhoeven wrote:
> > Please note these aliases become cumbersome once you start considering
> > (dynamic) DT overlays. That's why I made them optional in the sh-sci
> > serial driver, cfr. commit 7678f4c20fa7670f ("serial: sh-sci: Add support
> > for dynamic instances").
>
> Note that as I understand it, the entire point of documenting this sort
> of thing is to help solidify the interface between a DT aware boot
> program (e.g., bootloader) and a device tree which is provided
> separately, to avoid memorizing node/path hierarchy. It doesn't need to
> (and doesn't, as I read it) enforce an OS's device naming policy.
I'm all for documenting this primarily to prevent folks from just adding
whatever they wish in /aliases. Some platforms seem to want to have
aliases for everything.
> > Relevant parts of the commit description are:
> >
> > On DT platforms, the sh-sci driver requires the presence of "serialN"
> > aliases in DT, from which instance IDs are derived. If a DT alias is
> > missing, the drivers fails to probe the corresponding serial port.
> >
> > This becomes cumbersome when considering DT overlays, as currently
> > there is no upstream support for dynamically updating the /aliases node
> > in DT.
>
> That part is not a DT spec problem :)
>
> > Furthermore, even in the presence of such support, hardcoded
> > instance IDs in independent overlays are prone to conflicts.
> >
> > Hence add support for dynamic instance IDs, to be used in the absence of
> > a DT alias. This makes serial ports behave similar to I2C and SPI
> > buses, which already support dynamic instances.
>
> This seems to be a much different sort of problem. People always love
> having predictable IDs given by the OS (myself included), but that's
> just plain hard to do and impossible in some cases. I don't think that's
> what this document is about though.
>
> IOW, this document seems pretty consistent with the above: it doesn't
> require the usage of aliases (and it seems silly to have a driver
> *require* an alias) -- it just documents how one should name such an
> alias if you expect multiple independent software components to
> understand it.
>
> > To clarify my point: R-Car M2-W has 4 different types of serial ports, for a
> > total of 18 ports, and the two ports on a board labeled 0 and 1 may not
> > correspond to the physical first two ports (what's "first" in a collection
> > of
> > 4 different types?).
> >
> > Aliases may be fine for referring to the main serial console (labeled
> > port 0 on the device, too), and the primary Ethernet interface (so U-Boot
> > knows where to add the "local-mac-address" property), but beyond that,
> > I think they should be avoided.
This basically matches my opinion on aliases.
I'd decouple it from board labels a bit. Sometimes the numbering may
match, but others not. What if a board serial port is labeled "DBG" for
example? I think 'label' is the right way to handle human identifible
ports (and then we should have something like /dev/serial/by-label/...).
> That's fair enough. Just because the solution isn't an all-purpose tool
> doesn't mean it shouldn't be documented. The general concept is already
> in ePAPR, but it's just not very specific about property names.
Agreed. I guess the question is what to do on used, but not recommended
aliases. I would put SPI and I2C into that category BTW.
Rob
Re: [PATCH v3 3/3] dt: bindings: add bindings for wifi iommu node
On Wed, 10 Oct 2018 17:22:56 +0530, Govind Singh wrote: > WCN3990 wifi module can optionally make use of the IOMMU. > Add binding documentation for phandle to the IOMMU and > the stream id of wifi iommu block. > > Signed-off-by: Govind Singh > --- > Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 5 + > 1 file changed, 5 insertions(+) > Reviewed-by: Rob Herring
Re: [PATCH v3 1/3] dt: bindings: add missing dt properties for WCN3990 wifi node
On Wed, 10 Oct 2018 17:22:54 +0530, Govind Singh wrote: > Add missing optional properties in WCN3990 wifi node. > > Signed-off-by: Govind Singh > --- > .../bindings/net/wireless/qcom,ath10k.txt | 28 > -- > 1 file changed, 21 insertions(+), 7 deletions(-) > Reviewed-by: Rob Herring
Re: [PATCH v4 2/2] drivers: remove force dma flag from buses
On Sat, Apr 28, 2018 at 08:21:59AM +0530, Nipun Gupta wrote: > With each bus implementing its own DMA configuration callback, > there is no need for bus to explicitly have force_dma in its > global structure. This patch modifies of_dma_configure API to > accept an input parameter which specifies if implicit DMA > configuration is required even when it is not described by the > firmware. > > Signed-off-by: Nipun Gupta > Acked-by: Bjorn Helgaas # PCI parts > --- > Changes in v2: > - This is a new change suggested by Robin and Christoph > and is added to the series. > > Changes in v3: > - Rebase and changes corresponding to the changes in patch 1/2 > > Changes in v4: > - Rebased on top of 4.17-rc2 > > drivers/amba/bus.c| 1 - > drivers/base/platform.c | 3 +-- > drivers/bcma/main.c | 2 +- > drivers/dma/qcom/hidma_mgmt.c | 2 +- > drivers/gpu/host1x/bus.c | 5 ++--- > drivers/of/device.c | 6 -- > drivers/of/of_reserved_mem.c | 2 +- > drivers/pci/pci-driver.c | 3 +-- > include/linux/device.h| 4 > include/linux/of_device.h | 8 ++-- > 10 files changed, 17 insertions(+), 19 deletions(-) Reviewed-by: Rob Herring
Re: [PATCH v2 13/13] dt: bindings: add bindings for wcn3990 wifi block
On Tue, Apr 10, 2018 at 10:19:46PM +0530, Govind Singh wrote:
> Add device tree binding documentation details for wcn3990
> wifi block present in Qualcomm SDM845/APQ8098 SoC into
> "qcom,ath10k.txt".
>
> Signed-off-by: Govind Singh
> ---
> .../bindings/net/wireless/qcom,ath10k.txt | 31
> ++
> 1 file changed, 31 insertions(+)
One nit, otherwise:
Reviewed-by: Rob Herring
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> index 3d2a031..34e4f98 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> @@ -4,6 +4,7 @@ Required properties:
> - compatible: Should be one of the following:
> * "qcom,ath10k"
> * "qcom,ipq4019-wifi"
> + * "qcom,wcn3990-wifi"
>
> PCI based devices uses compatible string "qcom,ath10k" and takes calibration
> data along with board specific data via "qcom,ath10k-calibration-data".
> @@ -18,8 +19,12 @@ In general, entry "qcom,ath10k-pre-calibration-data" and
> "qcom,ath10k-calibration-data" conflict with each other and only one
> can be provided per device.
>
> +SNOC based devices (i.e. wcn3990) uses compatible string "qcom,wcn3990-wifi".
> +
> Optional properties:
> - reg: Address and length of the register set for the device.
> +- reg-names: Must include the list of following reg names,
> + "membase"
> - resets: Must contain an entry for each entry in reset-names.
>See ../reset/reseti.txt for details.
> - reset-names: Must include the list of following reset names,
> @@ -49,6 +54,8 @@ Optional properties:
>hw versions.
> - qcom,ath10k-pre-calibration-data : pre calibration data as an array,
>the length can vary between hw versions.
> +- -supply: handle to the regulator device tree node
> +optional "supply-name" is "vdd-0.8-cx-mx".
>
> Example (to supply the calibration data alone):
>
> @@ -119,3 +126,27 @@ wifi0: wifi@a00 {
> qcom,msi_base = <0x40>;
> qcom,ath10k-pre-calibration-data = [ 01 02 03 ... ];
> };
> +
> +Example (to supply wcn3990 SoC wifi block details):
> +
> +qcom,wifi@1800 {
wifi@...
> + compatible = "qcom,wcn3990-wifi";
> + reg = <0x1880 0x80>;
> + reg-names = "membase";
> + clocks = <&clock_gcc clk_aggre2_noc_clk>;
> + clock-names = "smmu_aggre2_noc_clk"
> + interrupts =
> +<0 130 0 /* CE0 */ >,
> +<0 131 0 /* CE1 */ >,
> +<0 132 0 /* CE2 */ >,
> +<0 133 0 /* CE3 */ >,
> +<0 134 0 /* CE4 */ >,
> +<0 135 0 /* CE5 */ >,
> +<0 136 0 /* CE6 */ >,
> +<0 137 0 /* CE7 */ >,
> +<0 138 0 /* CE8 */ >,
> +<0 139 0 /* CE9 */ >,
> +<0 140 0 /* CE10 */ >,
> +<0 141 0 /* CE11 */ >;
> + vdd-0.8-cx-mx-supply = <&pm8998_l5>;
> +};
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] drivers: remove force dma flag from buses
On Fri, Mar 30, 2018 at 01:24:45PM +0530, Nipun Gupta wrote: > With each bus implementing its own DMA configuration callback, > there is no need for bus to explicitly have force_dma in its > global structure. This patch modifies of_dma_configure API to > accept an input parameter which specifies if implicit DMA > configuration is required even when it is not described by the > firmware. > > Signed-off-by: Nipun Gupta > --- > Changes in v2: > - This is a new change suggested by Robin and Christoph > and is added to the series. > > Changes in v3: > - Rebase and changes corresponding to the changes in patch 1/2 > > drivers/amba/bus.c| 1 - > drivers/base/platform.c | 3 +-- > drivers/bcma/main.c | 2 +- > drivers/dma/qcom/hidma_mgmt.c | 2 +- > drivers/gpu/host1x/bus.c | 5 ++--- > drivers/of/device.c | 6 -- > drivers/of/of_reserved_mem.c | 2 +- > drivers/pci/pci-driver.c | 3 +-- > include/linux/device.h| 4 > include/linux/of_device.h | 8 ++++++-- > 10 files changed, 17 insertions(+), 19 deletions(-) Reviewed-by: Rob Herring
Re: [PATCH v2] dt: bindings: add bindings for wcn3990 wifi block
On Fri, Feb 16, 2018 at 10:13:48AM +0530, Govind Singh wrote:
> Add device tree binding documentation details for wcn3990
> wifi block present in Qualcomm SDM845/APQ8098 SoC into
> "qcom,ath10k.txt".
>
> Signed-off-by: Govind Singh
> ---
> .../bindings/net/wireless/qcom,ath10k.txt | 35
> ++
> 1 file changed, 35 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> index 3d2a031..e34d8f8 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> @@ -4,6 +4,7 @@ Required properties:
> - compatible: Should be one of the following:
> * "qcom,ath10k"
> * "qcom,ipq4019-wifi"
> + * "qcom,wcn3990-wifi"
>
> PCI based devices uses compatible string "qcom,ath10k" and takes calibration
> data along with board specific data via "qcom,ath10k-calibration-data".
> @@ -18,8 +19,11 @@ In general, entry "qcom,ath10k-pre-calibration-data" and
> "qcom,ath10k-calibration-data" conflict with each other and only one
> can be provided per device.
>
> +SNOC based devices (i.e. wcn3990) uses compatible string "qcom,wcn3990-wifi".
> +
> Optional properties:
> - reg: Address and length of the register set for the device.
> +- reg-names: Names of the memory regions defined in reg entry.
You must define what the names are and how many (so reg needs updating
too if there is more than 1).
Though with only 1 -names, it is kind of pointless.
> - resets: Must contain an entry for each entry in reset-names.
>See ../reset/reseti.txt for details.
> - reset-names: Must include the list of following reset names,
> @@ -49,6 +53,12 @@ Optional properties:
>hw versions.
> - qcom,ath10k-pre-calibration-data : pre calibration data as an array,
>the length can vary between hw versions.
> +- qcom,-supply: handle to the regulator device tree node
> +optional "supply-name" is "vdd-0.8-cx-mx".
You can drop the qcom prefix. Just name this "vdd-0.8-cx-mx-supply".
> +- qcom,-config: Specifies voltage levels for supply. Should be
> + specified in pairs (min, max), units uV. There can
> +be optional load in uA and Regulator settle delay in
> +uS.
We have standard regulator properties for this I think.
>
> Example (to supply the calibration data alone):
>
> @@ -119,3 +129,28 @@ wifi0: wifi@a00 {
> qcom,msi_base = <0x40>;
> qcom,ath10k-pre-calibration-data = [ 01 02 03 ... ];
> };
> +
> +Example (to supply wcn3990 SoC wifi block details):
> +
> +qcom,msm_ath10k@1800 {
wifi@...
> + compatible = "qcom,wcn3990-wifi";
> + reg = <0x1880 0x80>;
> + reg-names = "membase";
> + clocks = <&clock_gcc clk_aggre2_noc_clk>;
> + clock-names = "smmu_aggre2_noc_clk"
> + interrupts =
> +<0 130 0 /* CE0 */ >,
> +<0 131 0 /* CE1 */ >,
> +<0 132 0 /* CE2 */ >,
> +<0 133 0 /* CE3 */ >,
> +<0 134 0 /* CE4 */ >,
> +<0 135 0 /* CE5 */ >,
> +<0 136 0 /* CE6 */ >,
> +<0 137 0 /* CE7 */ >,
> +<0 138 0 /* CE8 */ >,
> +<0 139 0 /* CE9 */ >,
> +<0 140 0 /* CE10 */ >,
> +<0 141 0 /* CE11 */ >;
> + qcom,vdd-0.8-cx-mx-supply = <&pm8998_l5>;
> + qcom,vdd-0.8-cx-mx-config = <80 80 2400 1000>;
> +};
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dt-bindings: net: wireless: Add sg parameters dts parsing
On Mon, Dec 11, 2017 at 10:55:18AM +0100, Arend van Spriel wrote: > On 12/11/2017 9:11 AM, Chi-Hsien Lin wrote: > > broken_sg_support, sd_head_align, and sd_sgentry_align are used in > > brcmfmac code but not configurable in dts file. Add the parsing logic. > > Now they can be configured like below in dts: > > brcm,broken_sg_support; > > brcm,sd_head_align = <4>; > > brcm,sd_sgentry_align = <4>; > > > > Signed-off-by: Chi-hsien Lin > > --- > > .../devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt| 8 > > > > 1 file changed, 8 insertions(+) > > > > diff --git > > a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt > > b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt > > index 86602f2..4d42f0d 100644 > > --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt > > +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt > > @@ -17,6 +17,11 @@ Optional properties: > > When not specified the device will use in-band SDIO interrupts. > >- interrupt-names : name of the out-of-band interrupt, which must be set > > to "host-wake". > > + - broken_sg_support : flag for broken sg list support of SDIO host > > controller. > > + Set this to true if the SDIO host controller has higher align > > + requirement than 32 bytes for each scatterlist item. > > In DT context, this does not characterize the device but as described it is > about the SDIO host controller. I think the same applies to the properties > below, but not entirely sure about that. Yes. However, all of this should be implied by the host controller's compatible property. For future reference, don't use '_' in property names either. Rob
Re: [PATCH v2 1/2] dt: bindings: add new dt entry for ath10k calibration variant
On Fri, Dec 08, 2017 at 11:37:41AM +0100, Sven Eckelmann wrote: > The bus + bmi-chip-id + bmi-board-id is not enough to identify the correct > board data file on QCA4019 based devices. Multiple different boards share > the same values. Only the original reference designs can currently be > identified and loaded from the board-2.bin. But these will not result in > the correct calibration data when combined with the pre-calibration data > from the device. > > An additional "variant" information has to be provided (via SMBIOS or DT) > to select the correct board data for a design which was modified by an ODM. > > Signed-off-by: Sven Eckelmann > --- > Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 3 +++ > 1 file changed, 3 insertions(+) Reviewed-by: Rob Herring
Re: [PATCH v7 1/3] dt-bindings: net: add mt76 wireless device binding
On Mon, Nov 20, 2017 at 08:35:47PM +0100, Felix Fietkau wrote: > Add documentation describing how device tree can be used to configure > wireless chips supported by the mt76 driver. > > Signed-off-by: Felix Fietkau > --- > .../bindings/net/wireless/mediatek,mt76.txt| 32 > ++ > 1 file changed, 32 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt Acked-by: Rob Herring
Re: [PATCH v6 1/3] dt-bindings: net: add mt76 wireless device binding
On Sat, Oct 14, 2017 at 10:43 AM, Christian Lamparter wrote: > On Saturday, October 14, 2017 9:20:46 AM CEST Felix Fietkau wrote: >> On 2017-10-13 21:07, Rob Herring wrote: >> > On Fri, Oct 06, 2017 at 01:02:47PM +0200, Felix Fietkau wrote: >> >> Add documentation describing how device tree can be used to configure >> >> wireless chips supported by the mt76 driver. >> >> >> >> Signed-off-by: Felix Fietkau >> >> --- >> >> .../bindings/net/wireless/mediatek,mt76.txt| 24 >> >> ++ >> >> 1 file changed, 24 insertions(+) >> >> create mode 100644 >> >> Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt >> >> >> >> diff --git >> >> a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt >> >> b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt >> >> new file mode 100644 >> >> index ..19522ab97d62 >> >> --- /dev/null >> >> +++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt >> >> @@ -0,0 +1,24 @@ >> >> +* MediaTek mt76xx devices >> >> + >> >> +This node provides properties for configuring the MediaTek mt76xx >> >> wireless >> >> +device. The node is expected to be specified as a child node of the PCI >> >> +controller to which the wireless chip is connected. >> >> + >> >> +Optional properties: >> >> + >> >> +- mac-address: See ethernet.txt in the parent directory >> >> +- local-mac-address: See ethernet.txt in the parent directory >> >> +- ieee80211-freq-limit: See ieee80211.txt >> >> +- mediatek,mtd-eeprom: Specify a MTD partition + offset containing >> >> EEPROM data >> > >> > MTD is a Linuxism. And is an EEPROM the only supported device? I'd >> > suggest naming if after what the data contains. >> PCI cards with this kind of wireless chip usually come with some form of >> EEPROM or use the on-chip OTP ROM. >> This property is for the case where the chip is built into an embedded >> device and the data that would otherwise be on an EEPROM is stored on a >> MTD partition instead. >> The EEPROM data itself contains multiple things: calibration data, >> hardware capabilities, MAC address, etc. >> I couldn't think of a better name for it, do you have any suggestions? Naming is hard. > This sort of reminds me of the failed ath9k nvmem patches: > https://patchwork.kernel.org/patch/9622127/ > > Which uses the nvmem system. > > https://github.com/torvalds/linux/blob/master/Documentation/nvmem/nvmem.txt > > Rob, would this be acceptable? Yeah, alignment with other drivers is a good thing. Rob
Re: [PATCH v6 1/3] dt-bindings: net: add mt76 wireless device binding
On Fri, Oct 06, 2017 at 01:02:47PM +0200, Felix Fietkau wrote:
> Add documentation describing how device tree can be used to configure
> wireless chips supported by the mt76 driver.
>
> Signed-off-by: Felix Fietkau
> ---
> .../bindings/net/wireless/mediatek,mt76.txt| 24
> ++
> 1 file changed, 24 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
> b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
> new file mode 100644
> index ..19522ab97d62
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
> @@ -0,0 +1,24 @@
> +* MediaTek mt76xx devices
> +
> +This node provides properties for configuring the MediaTek mt76xx wireless
> +device. The node is expected to be specified as a child node of the PCI
> +controller to which the wireless chip is connected.
> +
> +Optional properties:
> +
> +- mac-address: See ethernet.txt in the parent directory
> +- local-mac-address: See ethernet.txt in the parent directory
> +- ieee80211-freq-limit: See ieee80211.txt
> +- mediatek,mtd-eeprom: Specify a MTD partition + offset containing EEPROM
> data
MTD is a Linuxism. And is an EEPROM the only supported device? I'd
suggest naming if after what the data contains.
> +
> +&pcie {
> + status = "okay";
Don't show status in examples.
> +
> + pcie0 {
> + wifi@0,0 {
You need a compatible here too.
> + reg = <0x 0 0 0 0>;
> + ieee80211-freq-limit = <500 600>;
> + mediatek,mtd-eeprom = <&factory 0x8000>;
> + };
> + };
> +};
> --
> 2.14.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: dt-binding: net: wireless: add bcm43430-fmac
On Fri, Sep 1, 2017 at 2:10 PM, Arend van Spriel wrote: > On 01-09-17 18:49, Rob Herring wrote: >> >> On Wed, Aug 30, 2017 at 02:02:18PM +0200, Antony Antony wrote: >>> >>> hi, >>> >>> On Wed, Aug 30, 2017 at 10:28:20AM +0800, Chen-Yu Tsai wrote: >>>> >>>> On Wed, Aug 30, 2017 at 5:43 AM, Antony Antony >>>> wrote: >>> >>> >>>>> a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt >>>>> +++ >>>>> b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt >>>>> @@ -6,7 +6,9 @@ connects the device to the system. >>>>> >>>>> Required properties: >>>>> >>>>> - - compatible : Should be "brcm,bcm4329-fmac". >>>>> + - compatible : should be one of the following: >>>>> + * "brcm,bcm4329-fmac" >>>>> + * "brcm,bcm43430-fmac" >>>> >>>> >>>> You updated the bindings, but not the driver. So it's not actually >>>> going to work. More specifically, OOB interrupts won't work. >>>> >>> >>> understood, ignore this patch for now. Thanks Chen-Yu. >>> >>>> IIRC, The compatible string for this particular case, as it was >>>> originally proposed, only serves as a placeholder for the driver >>>> to check against. None of the instances in sunxi device trees >>>> match the actual chip model. Actual model matching is done >>>> through SDIO, as you've already seen. >>> >>> >>> yes it seems SDIO driveer code is smarter, once it initialize >>> brcm,bcm4329-fmac it ignore the DT info and read the chip details to >>> locate >>> firmware file. >>> >>> I also noticed other boards using bcm4329-fmac in similar situations. >>> https://patchwork.kernel.org/patch/9739181/ >>> >>> >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts?h=v4.13-rc7 >>> >>> I will resend "NanoPi NEO Plus2" dts with "brcm,bcm4329-fmac" and see >>> where >>> it goes. >> >> >> Adding the compatible or instead of? The former would be better. You >> should still have the actual chip in case you do have some difference to >> handle. > > > Hi Rob, > > Actually the Broadcom wifi chips themselves are discoverable. So once the > driver has access to the register space of the device it can determine the > actual chip, its revision, and exactly what cores (and their revision) are > present in the chip. Hence there is a single compatible string as there is > no need to convey the same information through device tree data. So if a chip has different power on/off sequencing you can discover that? I realize that most often you don't need it, but a more specific compatible is there in case you do and so it doesn't require a DTB update to handle some difference. But you can keep using one compatible because I can't really enforce any of that. Rob
Re: [PATCH] Documentation: dt-binding: net: wireless: add bcm43430-fmac
On Wed, Aug 30, 2017 at 02:02:18PM +0200, Antony Antony wrote: > hi, > > On Wed, Aug 30, 2017 at 10:28:20AM +0800, Chen-Yu Tsai wrote: > > On Wed, Aug 30, 2017 at 5:43 AM, Antony Antony wrote: > > > > a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt > > > +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt > > > @@ -6,7 +6,9 @@ connects the device to the system. > > > > > > Required properties: > > > > > > - - compatible : Should be "brcm,bcm4329-fmac". > > > + - compatible : should be one of the following: > > > + * "brcm,bcm4329-fmac" > > > + * "brcm,bcm43430-fmac" > > > > You updated the bindings, but not the driver. So it's not actually > > going to work. More specifically, OOB interrupts won't work. > > > > understood, ignore this patch for now. Thanks Chen-Yu. > > > IIRC, The compatible string for this particular case, as it was > > originally proposed, only serves as a placeholder for the driver > > to check against. None of the instances in sunxi device trees > > match the actual chip model. Actual model matching is done > > through SDIO, as you've already seen. > > yes it seems SDIO driveer code is smarter, once it initialize > brcm,bcm4329-fmac it ignore the DT info and read the chip details to locate > firmware file. > > I also noticed other boards using bcm4329-fmac in similar situations. > https://patchwork.kernel.org/patch/9739181/ > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts?h=v4.13-rc7 > > I will resend "NanoPi NEO Plus2" dts with "brcm,bcm4329-fmac" and see where > it goes. Adding the compatible or instead of? The former would be better. You should still have the actual chip in case you do have some difference to handle. Rob
Re: [PATCH] dt-bindings: add device tree binding for Allwinner XR819 SDIO Wi-Fi
On Tue, Jul 18, 2017 at 03:29:40PM +0800, Icenowy Zheng wrote:
> Allwinner XR819 is a SDIO Wi-Fi chip, which has the functionality to use
> an out-of-band interrupt pin instead of SDIO in-band interrupt.
>
> Add the device tree binding of this chip, in order to make it possible
> to add this interrupt pin to device trees.
>
> Signed-off-by: Icenowy Zheng
> ---
> .../bindings/net/wireless/allwinner,xr819.txt | 37
> ++
> 1 file changed, 37 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/net/wireless/allwinner,xr819.txt
>
> diff --git
> a/Documentation/devicetree/bindings/net/wireless/allwinner,xr819.txt
> b/Documentation/devicetree/bindings/net/wireless/allwinner,xr819.txt
> new file mode 100644
> index ..64dd9c1c0584
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/allwinner,xr819.txt
> @@ -0,0 +1,37 @@
> +Allwinner XRadio wireless SDIO devices
> +
> +This node provides properties for controlling the XRadio wireless device. The
> +node is expected to be specified as a child node to the SDIO controller that
> +connects the device to the system.
> +
> +Required properties:
> +
> + - compatible : Should be "allwinner,xr819".
reg is also required.
> +
> +Optional properties:
> + - interrupt-parent : the phandle for the interrupt controller to which the
> + device interrupts are connected.
> + - interrupts : specifies attributes for the out-of-band interrupt
> (host-wake).
> + When not specified the device will use in-band SDIO interrupts.
> +
> +Example:
> +
> +mmc1: mmc@01c1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc1_pins_a>;
> + vmmc-supply = <®_vcc_wifi>;
> + mmc-pwrseq = <&wifi_pwrseq>;
> + bus-width = <4>;
> + non-removable;
> + status = "okay";
Don't show status in examples.
> +
> + xr819: sdio_wifi@1 {
wifi@1
> + reg = <1>;
> + compatible = "allwinner,xr819";
> + interrupt-parent = <&pio>;
> + interrupts = <6 10 IRQ_TYPE_EDGE_RISING>;
> + };
> +};
> --
> 2.13.0
>
Re: [PATCH 3/3] Revert "NFC: trf7970a: Handle extra byte in response to Type 5 RMB commands"
On Thu, Jun 15, 2017 at 10:46:17AM -0700, Mark Greer wrote: > This reverts commit ab714817d7e891608d31f6996b1e4c43cf2bf342. > > The original commit was designed to handle a bug in the trf7970a NFC > controller where an extra byte was returned in Read Multiple Blocks (RMB) > command responses. However, it has become less clear whether it is a bug > in the trf7970a or in the tag. In addition, it was assumed that the extra > byte was always returned but it turns out that is not always the case. The > result is that a byte of good data is trimmed off when the extra byte is > not present ultimately causing the neard deamon to fail the read. > > Since the trf7970a driver does not have the context to know when to trim > the byte or not, remove the code from the trf7970a driver all together > (and move it up to the neard daemon). This has the added benefit of > simplifying the kernel driver and putting the extra complexity into > userspace. > > CC: Rob Herring > CC: devicet...@vger.kernel.org > Signed-off-by: Mark Greer > --- > .../devicetree/bindings/net/nfc/trf7970a.txt | 4 > drivers/nfc/trf7970a.c | 25 > ------ > 2 files changed, 4 insertions(+), 25 deletions(-) Acked-by: Rob Herring
Re: [PATCHv4] wlcore: add wl1285 compatible
On Mon, May 22, 2017 at 11:21 AM, Sebastian Reichel wrote: > Hi, > > On Mon, May 22, 2017 at 11:11:49AM -0500, Rob Herring wrote: >> On Mon, May 22, 2017 at 10:21 AM, Sebastian Reichel >> wrote: >> > Hi, >> > >> > On Mon, May 22, 2017 at 05:44:24PM +0300, Kalle Valo wrote: >> >> David Miller writes: >> >> > From: Kalle Valo >> >> > Date: Mon, 22 May 2017 12:28:20 +0300 >> >> > >> >> >> Sebastian Reichel writes: >> >> >> >> >> >>> Motorola Droid 4 uses a WL1285C. With differences between the >> >> >>> chips not being public let's add explicit binding for wl1285 >> >> >>> instead of relying on wl1283 being very similar. >> >> >>> >> >> >>> Reviewed-by: Rob Herring >> >> >>> Acked-by: Kalle Valo >> >> >>> Acked-by: Tony Lindgren >> >> >>> Signed-off-by: Sebastian Reichel >> >> >>> --- >> >> >>> Hi Dave, >> >> >>> >> >> >>> I previously send this in two patches, but its hard to apply without >> >> >>> requiring multiple kernel releases (the driver must be updated before >> >> >>> the DTS change). Since the actual change is not very complex Marcel >> >> >>> Holtmann & Tony Lindgren suggested, that I send this directly to you >> >> >>> in a single patch for inclusion into 4.12. This also means, that the >> >> >>> remaining series can be queued normally for 4.13. >> >> >> >> >> >> I noticed that Dave set this patch to Awaiting Upstream state on his >> >> >> patchwork: >> >> >> >> >> >> https://patchwork.ozlabs.org/patch/759042/ >> >> >> >> >> >> Which makes me suspect that he is waiting me to apply this (as I >> >> >> normally apply wlcore patches). Dave, should I actually take this >> >> >> patch? >> >> >> What do you prefer? >> >> > >> >> > Anything that touches wireless drivers I defer to you, yes. >> >> >> >> Thanks, I'll take it then. Not sure why Sebastian was suggested to >> >> submit this patch via your tree in the first place. >> >> >> >> https://patchwork.kernel.org/patch/9713645/ >> > >> > Thanks. The idea was to get into early 4.12-rc to avoid merge >> > conflicts in the droid 4 *.dts during 4.13 cycle. This strategy >> > obviously failed :) >> >> First, I'm not sure why you combined everything. A maintainer can just >> as easily take a series as a single patch and we prefer binding doc, >> dts and driver changes all separate. >> >> Second, the dts changes could go thru arm-soc and the driver change >> thru netdev. The binding doc can be thru either. There's no bisecting >> dependency and things shouldn't break. It just won't all work until >> you have both branches. > > This is only true for new devices. WLAN for droid4 works at the > moment using incorrect compatible string. If *.dts is updated and > driver is not yet updated WLAN does not work. IMHO that is a > bisecting dependency. True. That's also breaking compatibility if a new kernel doesn't work with an old DT. Is it just a compatible string change? If so, then just keep the old string as a fallback. Rob
Re: [PATCHv4] wlcore: add wl1285 compatible
On Mon, May 22, 2017 at 10:21 AM, Sebastian Reichel wrote: > Hi, > > On Mon, May 22, 2017 at 05:44:24PM +0300, Kalle Valo wrote: >> David Miller writes: >> > From: Kalle Valo >> > Date: Mon, 22 May 2017 12:28:20 +0300 >> > >> >> Sebastian Reichel writes: >> >> >> >>> Motorola Droid 4 uses a WL1285C. With differences between the >> >>> chips not being public let's add explicit binding for wl1285 >> >>> instead of relying on wl1283 being very similar. >> >>> >> >>> Reviewed-by: Rob Herring >> >>> Acked-by: Kalle Valo >> >>> Acked-by: Tony Lindgren >> >>> Signed-off-by: Sebastian Reichel >> >>> --- >> >>> Hi Dave, >> >>> >> >>> I previously send this in two patches, but its hard to apply without >> >>> requiring multiple kernel releases (the driver must be updated before >> >>> the DTS change). Since the actual change is not very complex Marcel >> >>> Holtmann & Tony Lindgren suggested, that I send this directly to you >> >>> in a single patch for inclusion into 4.12. This also means, that the >> >>> remaining series can be queued normally for 4.13. >> >> >> >> I noticed that Dave set this patch to Awaiting Upstream state on his >> >> patchwork: >> >> >> >> https://patchwork.ozlabs.org/patch/759042/ >> >> >> >> Which makes me suspect that he is waiting me to apply this (as I >> >> normally apply wlcore patches). Dave, should I actually take this patch? >> >> What do you prefer? >> > >> > Anything that touches wireless drivers I defer to you, yes. >> >> Thanks, I'll take it then. Not sure why Sebastian was suggested to >> submit this patch via your tree in the first place. >> >> https://patchwork.kernel.org/patch/9713645/ > > Thanks. The idea was to get into early 4.12-rc to avoid merge > conflicts in the droid 4 *.dts during 4.13 cycle. This strategy > obviously failed :) First, I'm not sure why you combined everything. A maintainer can just as easily take a series as a single patch and we prefer binding doc, dts and driver changes all separate. Second, the dts changes could go thru arm-soc and the driver change thru netdev. The binding doc can be thru either. There's no bisecting dependency and things shouldn't break. It just won't all work until you have both branches. Rob
Re: [PATCH 1/1] dt-binding: net: wireless: fix node name in the BCM43xx example
On Mon, May 15, 2017 at 10:13:56PM +0200, Martin Blumenstingl wrote: > The example in the BCM43xx documentation uses "brcmf" as node name. > However, wireless devices should be named "wifi" instead. Fix this to > make sure that .dts authors can simply use the documentation as > reference (or simply copy the node from the documentation and then > adjust only the board specific bits). > > Signed-off-by: Martin Blumenstingl > --- > Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied. Rob
Re: [PATCHv2 0/4] Motorola Droid 4: Add WL1285C support
On Wed, May 3, 2017 at 9:22 AM, Sebastian Reichel wrote: > Hi, > > Motorola Droid 4 uses a WL1285C, as visible on iFixit [0]. This > fixes the DT file to use correct compatible for the wifi node > and adds the bluetooth node. > > [0] https://www.ifixit.com/Teardown/Motorola+Droid+4+Teardown/7759#s31961 > > Changes to PATCHv1: > - use proper compatible value for bluetooth / shared transport > - add patches fixing wlcore compatible for Droid 4 > > -- Sebastian > > Sebastian Reichel (4): > wlcore: add wl1285 compatible > ARM: dts: omap4-droid4: Use wl1285 for wifi compatible > Bluetooth: hci_ll: Add compatible values for more WL chips > ARM: dts: omap4-droid4: Add bluetooth For the series, Reviewed-by: Rob Herring
Re: [PATCH v5 6/9] NFC: trf7970a: Remove support for 'vin-voltage-override' DT property
On Tue, Apr 25, 2017 at 03:43:53PM -0700, Mark Greer wrote: > The 'vin-voltage-override' DT property is used by the trf7970a > driver to override the voltage presented to the driver by the > regulator subsystem. This is unnecessary as properly specifying > the regulator chain via DT properties will accomplish the same > thing. Therefore, remove support for 'vin-voltage-override'. > > Signed-off-by: Mark Greer > --- > Documentation/devicetree/bindings/net/nfc/trf7970a.txt | 2 -- > drivers/nfc/trf7970a.c | 11 +-- > 2 files changed, 1 insertion(+), 12 deletions(-) Acked-by: Rob Herring
Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant
On Tue, Mar 21, 2017 at 9:33 AM, Sven Eckelmann
wrote:
> On Dienstag, 21. März 2017 08:00:34 CET Rob Herring wrote:
> [...]
>> > It would then up with something like this as compatibility string:
>> >
>> > * qcom,ipq4019-wifi-asus-rt-ac58u
>> > * qcom,ipq4019-wifi-fritzbox-4040
>> > * qcom,ipq4019-wifi-netgear-whatever
>> > * qcom,ipq4019-wifi-openmesh-i-have-no-idea
>> > * ...
>>
>> Are these all the same board design or variations? In the latter case,
>> you should have specific compatibles anyway. Now if the variants are
>> the same hardware, but different configurations say for different
>> regions or something, then I'd say a separate property is fine.
>>
>> We already have a "firmware-name" property. Would that work for you?
>
> Hm, maybe we should specify some names better:
>
> "qcom,ipq4019-wifi" == compatibility string for WiFi hardware inside the SoC.
> It is the one which ath10k supports on the Atheros Host Bus (ahb) of the
> QCA4019.
>
> The ath10k driver will use the information from these nodes to initialize the
> device. It will basically:
>
> 1. load a firmware(-5).bin from /lib/firmware/ath10k/QCA4019/hw1.0/
> 2. load the pre-cal (aka first part of calibration) data from
>/lib/firmware/ath10k/pre-cal-*
> 3. do some firmware magic to identify the reference design
> 4. load board data "files" (BDF) for this reference design from
> /lib/firmware/ath10k/QCA4019/hw1.0/board-2.bin
> 5. send the BDF data to the firmware to let it compute the final calibration
>data
> 6. start the actual wifi stuff
>
> The IPQ4018/4019 SoC doesn't contain the actual RF parts. There are a couple
> of reference designs (SoC+RF parts) from QCA which got official numbers. These
> numbers identify the BDFs inside the board-2.bin. And the board-2.bin is not
> the firmware - it is a container for multiple BDFs.
>
>
> To summarize:
>
> * pre-cal is some data stored in a special partition of the devices and will
>not be overwritten on updates
> * board-2.bin are multiple BDF files containing the second part of the
>calibration data
> * pre-cal + BDF (+ some OTP stuff) are getting combined to form the complete
>calibration data
>
> Asus RT-AC58U, Fritzbox 4040 and ZyXEL NBG6617 are products based on the same
> reference design. But of course, some (all?) fiddled around with the RF parts
> and therefore require special BDFs. They still use the same SoC and require
> that the closed source ath10k firmware behaves like on the official reference
> designs. Only the BDFs have to be different.
Is this always the case? There's never some variation beyond the
reference design that a BDF difference can't handle?
> So you could say that the wifi-chip hardware (part of the QCA4018/4019 SoC) is
> the same between these different products. But the hardware around the SoC is
> different and therefore requires a different "configuration"/calibration for
> the surrounding RF hardware. It is not a perfect match for your "separate
> property is fine" compromise. Maybe you still meant this - I let you decide.
>
>
> This is not only a problem on QCA4019 but also for other devices supported by
> ath10k. Waldemar Rymarkiewicz introduced the concept of BDF variants for
> this [1] and implemented the support for SMBIOS. The variant string (generated
> from the SMBIOS data) is then used by ath10k when it searches for the correct
> BDFs in the board-2.bin. Kalle Valo suggested to use the same mechanism for
> QCA401X based boards (which don't use SMBIOS).
>
> The "qcom,ath10k-calibration-variant" is now the (more or less) equivalent of
> the SMBIOS entry - but for device tree users. Let us assume that the variant
> string would be "RT-AC58U" for the Asus RT-AC58U and the first wifi device
> (bmi-board-id=16) gets initialized [2]. Then the step 4 would get splitted in
> following steps:
>
> 4.1. Get the the qcom,ath10k-calibration-variant content
> 4.2. jump to 4.5. when there is no qcom,ath10k-calibration-variant
> 4.3. calculate BDF search name with variant string
> "bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U"
> 4.4. load BDF and when found, jump to 5.
> 4.5. calculate BDF search name without variant string
> "bus=ahb,bmi-chip-id=0,bmi-board-id=16"
> 4.6. load the BDF
>
>
> There would be no changes in ath10k when adding a new BDF calibration variant
> using qcom,ath10k-calibration-variant. Only the device tree node would have to
> be updated:
>
> * device tree (simplified):
> / {
> model = "ASUS RT-AC58U";
>
>
Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant
On Mon, Mar 20, 2017 at 11:28 AM, Sven Eckelmann wrote: > On Montag, 20. März 2017 10:07:33 CET Rob Herring wrote: >> On Fri, Mar 10, 2017 at 09:06:14AM +0100, Sven Eckelmann wrote: >> > The bus + bmi-chip-id + bmi-board-id is not enough to identify the correct >> > board data file on QCA4019 based devices. Multiple different boards share >> > the same values. Only the original reference designs can currently be >> > identified and loaded from the board-2.bin. But these will not result in >> > the correct calibration data when combined with the pre-calibration data >> > from the device. >> > >> > An additional "variant" information has to be provided (via SMBIOS or DT) >> > to select the correct board data for a design which was modified by an ODM. >> > >> > Signed-off-by: Sven Eckelmann >> > --- >> > Since RFC: >> > >> > - Split patch in DT doc and ath10k part (thanks Christian Lamparter) >> > - Remove the words "bmi-chip-id" and "bmi-board-id" and replace them with >> >more generic "device specific ids" >> > --- >> > Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 3 +++ >> > 1 file changed, 3 insertions(+) >> > >> > diff --git >> > a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt >> > b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt >> > index 74d7f0af209c..3d2a031217da 100644 >> > --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt >> > +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt >> > @@ -41,6 +41,9 @@ Optional properties: >> > - qcom,msi_addr: MSI interrupt address. >> > - qcom,msi_base: Base value to add before writing MSI data into >> > MSI address register. >> > +- qcom,ath10k-calibration-variant: string to search for in the board-2.bin >> > + variant list with the same bus and device >> > + specific ids >> >> Sounds like you should use a more specific compatible string. > > Hm, this would require that each calibration data has an own compatibility > string - which then has to be supported by ath10k, right? Doesn't sound like > it would work well when each vendor (with an own calibration variant) would > have to modify ath10k to get it working. This sounds especially odd because > nothing else in ath10k has to be changed. Only the board data files which will > be selected by ath10k are different on these devices. > > It would then up with something like this as compatibility string: > > * qcom,ipq4019-wifi-asus-rt-ac58u > * qcom,ipq4019-wifi-fritzbox-4040 > * qcom,ipq4019-wifi-netgear-whatever > * qcom,ipq4019-wifi-openmesh-i-have-no-idea > * ... Are these all the same board design or variations? In the latter case, you should have specific compatibles anyway. Now if the variants are the same hardware, but different configurations say for different regions or something, then I'd say a separate property is fine. We already have a "firmware-name" property. Would that work for you? Rob
Re: [PATCH 1/7] Documentation: dt: net: Update the ath9k binding for SoC devices
On Mon, Mar 13, 2017 at 10:05:09PM +0100, Alban wrote:
> The current binding only cover PCI devices so extend it for SoC devices.
>
> Most SoC platforms use an MTD partition for the calibration data
> instead of an EEPROM. The qca,no-eeprom property was added to allow
> loading the EEPROM content using firmware loading. This new binding
> replace this hack with NVMEM cells, so we also mark the qca,no-eeprom
> property as deprecated in case anyone ever used it.
>
> Signed-off-by: Alban
> ---
> .../devicetree/bindings/net/wireless/qca,ath9k.txt | 41
> --
> 1 file changed, 38 insertions(+), 3 deletions(-)
For the subject, "dt-bindings: net: ..." and one nit below, otherwise:
Acked-by: Rob Herring
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> index b7396c8..61f5f6d 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> @@ -27,16 +27,34 @@ Required properties:
> - 0034 for AR9462
> - 0036 for AR9565
> - 0037 for AR9485
> + For SoC devices the compatible should be "qca,-wmac"
> + and one of the following fallbacks:
> + - "qca,ar9100-wmac"
> + - "qca,ar9330-wmac"
> + - "qca,ar9340-wmac"
> + - "qca,qca9550-wmac"
> + - "qca,qca9530-wmac"
> - reg: Address and length of the register set for the device.
>
> +Required properties for SoC devices:
> +- interrupt-parent: phandle of the parent interrupt controller.
> +- interrupts: Interrupt specifier for the controllers interrupt.
> +
> Optional properties:
> +- mac-address: See ethernet.txt in the parent directory
> +- local-mac-address: See ethernet.txt in the parent directory
> +- clock-names: has to be "ref"
> +- clocks: phandle of the reference clock
> +- resets: phandle of the reset line
> +- nvmem-cell-names: has to be "eeprom" and/or "address"
> +- nvmem-cells: phandle to the eeprom nvmem cell and/or to the mac address
> + nvmem cell.
> +
> +Deprecated properties:
> - qca,no-eeprom: Indicates that there is no physical EEPROM connected to the
> ath9k wireless chip (in this case the calibration /
> EEPROM data will be loaded from userspace using the
> kernel firmware loader).
> -- mac-address: See ethernet.txt in the parent directory
> -- local-mac-address: See ethernet.txt in the parent directory
> -
>
> In this example, the node is defined as child node of the PCI controller:
> &pci0 {
> @@ -46,3 +64,20 @@ In this example, the node is defined as child node of the
> PCI controller:
> qca,no-eeprom;
> };
> };
> +
> +In this example it is defined as a SoC device:
> + wmac@180c {
wifi@...
> + compatible = "qca,ar9132-wmac", "qca,ar9100-wmac";
> + reg = <0x180c 0x3>;
> +
> + interrupt-parent = <&cpuintc>;
> + interrupts = <2>;
> +
> + clock-names = "ref";
> + clocks = <&extosc>;
> +
> + nvmem-cell-names = "eeprom", "address";
> + nvmem-cells = <&wmac_eeprom>, <&wmac_address>;
> +
> + resets = <&rst 22>;
> + };
> --
> 2.7.4
>
Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant
On Fri, Mar 10, 2017 at 09:06:14AM +0100, Sven Eckelmann wrote: > The bus + bmi-chip-id + bmi-board-id is not enough to identify the correct > board data file on QCA4019 based devices. Multiple different boards share > the same values. Only the original reference designs can currently be > identified and loaded from the board-2.bin. But these will not result in > the correct calibration data when combined with the pre-calibration data > from the device. > > An additional "variant" information has to be provided (via SMBIOS or DT) > to select the correct board data for a design which was modified by an ODM. > > Signed-off-by: Sven Eckelmann > --- > Since RFC: > > - Split patch in DT doc and ath10k part (thanks Christian Lamparter) > - Remove the words "bmi-chip-id" and "bmi-board-id" and replace them with >more generic "device specific ids" > --- > Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt > b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt > index 74d7f0af209c..3d2a031217da 100644 > --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt > +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt > @@ -41,6 +41,9 @@ Optional properties: > - qcom,msi_addr: MSI interrupt address. > - qcom,msi_base: Base value to add before writing MSI data into > MSI address register. > +- qcom,ath10k-calibration-variant: string to search for in the board-2.bin > +variant list with the same bus and device > +specific ids Sounds like you should use a more specific compatible string. > - qcom,ath10k-calibration-data : calibration data + board specific data >as an array, the length can vary between >hw versions. > -- > 2.11.0 >
Re: [PATCH] NFC: remove TI nfcwilink driver
On Fri, Feb 24, 2017 at 3:43 PM, Marcel Holtmann wrote: > Hi Rob, > It appears that TI WiLink devices including NFC (WL185x/WL189x) never shipped. The only information I found were announcements in Feb 2012 about the parts. There's been no activity on this driver besided common changes since initially added in Jan 2012. There's also no in users that instantiate the platform device (nor DT bindings). This is a first step in removing TI ST (shared transport) driver in favor of extending the BT hci_ll driver to support WL183x chips. >>> >>> since the firmware files TINfcInit_* also never made it into the >>> linux-firmware tree, I have no idea who is using this driver. I am actually >>> fine with removing it since it would be easy enough to bring back based on >>> hci_ll driver once there is hardware to test this on. >> >> Ping. Someone going to pick up this patch? > > if Samuel does not have anything pending for his tree, I can take it through > bluetooth-next tree. >From the looks of -next, it doesn't appear so. Rob
Re: [PATCH] NFC: remove TI nfcwilink driver
On Wed, Jan 25, 2017 at 11:54 PM, Marcel Holtmann wrote: > Hi Rob, > >> It appears that TI WiLink devices including NFC (WL185x/WL189x) never >> shipped. The only information I found were announcements in Feb >> 2012 about the parts. There's been no activity on this driver besided >> common changes since initially added in Jan 2012. There's also no in >> users that instantiate the platform device (nor DT bindings). >> >> This is a first step in removing TI ST (shared transport) driver in >> favor of extending the BT hci_ll driver to support WL183x chips. > > since the firmware files TINfcInit_* also never made it into the > linux-firmware tree, I have no idea who is using this driver. I am actually > fine with removing it since it would be easy enough to bring back based on > hci_ll driver once there is hardware to test this on. Ping. Someone going to pick up this patch? Rob
Re: [PATCH] Make EN2 pin optional in the TRF7970A driver
On Sun, Feb 19, 2017 at 11:19 PM, Heiko Schocher wrote: > Hello all, > > Am 13.02.2017 um 22:31 schrieb Rob Herring: >> >> On Mon, Feb 13, 2017 at 12:38 AM, Heiko Schocher wrote: >>> >>> Hello Rob, >>> >>> >>> Am 10.02.2017 um 16:51 schrieb Rob Herring: >>>> >>>> >>>> On Tue, Feb 07, 2017 at 06:22:04AM +0100, Heiko Schocher wrote: >>>>> >>>>> >>>>> From: Guan Ben >>>>> >>>>> Make the EN2 pin optional. This is useful for boards, >>>>> which have this pin fix wired, for example to ground. >>>>> >>>>> Signed-off-by: Guan Ben >>>>> Signed-off-by: Mark Jonas >>>>> Signed-off-by: Heiko Schocher >>>>> >>>>> --- >>>>> >>>>>.../devicetree/bindings/net/nfc/trf7970a.txt | 4 ++-- >>>>>drivers/nfc/trf7970a.c | 26 >>>>> -- >>>>>2 files changed, 16 insertions(+), 14 deletions(-) >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt >>>>> b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt >>>>> index 32b35a0..5889a3d 100644 >>>>> --- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt >>>>> +++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt >>>>> @@ -5,8 +5,8 @@ Required properties: >>>>>- spi-max-frequency: Maximum SPI frequency (<= 200). >>>>>- interrupt-parent: phandle of parent interrupt handler. >>>>>- interrupts: A single interrupt specifier. >>>>> -- ti,enable-gpios: Two GPIO entries used for 'EN' and 'EN2' pins on >>>>> the >>>>> - TRF7970A. >>>>> +- ti,enable-gpios: One or two GPIO entries used for 'EN' and 'EN2' >>>>> pins >>>>> on the >>>>> + TRF7970A. EN2 is optional. >>>> >>>> >>>> >>>> Could EN ever be optional/fixed? If so, perhaps deprecate this property >>>> and do 2 properties, one for each pin. >>> >>> >>> >>> The hardware I have has the EN2 pin fix connected to ground. Looking >>> into http://www.ti.com/lit/ds/slos743k/slos743k.pdf page 19 table 6-3 >>> and 6-4 the EN2 pin is a don;t core if EN = 1. If EN = 0 EN2 pin >>> selects between Power Down and Sleep Mode ... I see no reason why >>> this is not possible/allowed ... >>> >>> Hmm.. I do not like the idea of deprecating the "ti,enable-gpios" >>> property into 2 seperate properties ... but if this would be a reason >>> for not accepting this patch, I can do this ... How should I name >>> the 2 new properties? >> >> >> I guess if this ever happens, then we just add "ti,enable2-gpios" and >> ti,enable-gpios continues to point to EN. We don't need to deprecate >> anything (or maybe just deprecate having both GPIOs on single >> property). >> >> In that case, >> >> Acked-by: Rob Herring > > > gentle ping. > > Are there any more comments to this patch? Is it acceptable as it > is? I acked it, so yes, it is fine. Rob
Re: [PATCH v5 1/3] Documentation: dt: net: add mt76 wireless device binding
On Tue, Feb 07, 2017 at 09:20:33PM +0100, Felix Fietkau wrote:
> Signed-off-by: Felix Fietkau
Commit msg? Also, use "dt-bindings: net: " for the subject prefix.
> ---
> .../bindings/net/wireless/mediatek,mt76.txt| 24
> ++
> 1 file changed, 24 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
> b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
> new file mode 100644
> index ..19522ab97d62
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
> @@ -0,0 +1,24 @@
> +* MediaTek mt76xx devices
> +
> +This node provides properties for configuring the MediaTek mt76xx wireless
> +device. The node is expected to be specified as a child node of the PCI
> +controller to which the wireless chip is connected.
> +
> +Optional properties:
> +
> +- mac-address: See ethernet.txt in the parent directory
> +- local-mac-address: See ethernet.txt in the parent directory
> +- ieee80211-freq-limit: See ieee80211.txt
> +- mediatek,mtd-eeprom: Specify a MTD partition + offset containing EEPROM
> data
> +
> +&pcie {
> + status = "okay";
> +
> + pcie0 {
> + wifi@0,0 {
> + reg = <0x 0 0 0 0>;
> + ieee80211-freq-limit = <500 600>;
> + mediatek,mtd-eeprom = <&factory 0x8000>;
> + };
> + };
> +};
> --
> 2.11.0
>
Re: [PATCH] Make EN2 pin optional in the TRF7970A driver
On Mon, Feb 13, 2017 at 12:38 AM, Heiko Schocher wrote: > Hello Rob, > > > Am 10.02.2017 um 16:51 schrieb Rob Herring: >> >> On Tue, Feb 07, 2017 at 06:22:04AM +0100, Heiko Schocher wrote: >>> >>> From: Guan Ben >>> >>> Make the EN2 pin optional. This is useful for boards, >>> which have this pin fix wired, for example to ground. >>> >>> Signed-off-by: Guan Ben >>> Signed-off-by: Mark Jonas >>> Signed-off-by: Heiko Schocher >>> >>> --- >>> >>> .../devicetree/bindings/net/nfc/trf7970a.txt | 4 ++-- >>> drivers/nfc/trf7970a.c | 26 >>> -- >>> 2 files changed, 16 insertions(+), 14 deletions(-) >>> >>> diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt >>> b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt >>> index 32b35a0..5889a3d 100644 >>> --- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt >>> +++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt >>> @@ -5,8 +5,8 @@ Required properties: >>> - spi-max-frequency: Maximum SPI frequency (<= 200). >>> - interrupt-parent: phandle of parent interrupt handler. >>> - interrupts: A single interrupt specifier. >>> -- ti,enable-gpios: Two GPIO entries used for 'EN' and 'EN2' pins on the >>> - TRF7970A. >>> +- ti,enable-gpios: One or two GPIO entries used for 'EN' and 'EN2' pins >>> on the >>> + TRF7970A. EN2 is optional. >> >> >> Could EN ever be optional/fixed? If so, perhaps deprecate this property >> and do 2 properties, one for each pin. > > > The hardware I have has the EN2 pin fix connected to ground. Looking > into http://www.ti.com/lit/ds/slos743k/slos743k.pdf page 19 table 6-3 > and 6-4 the EN2 pin is a don;t core if EN = 1. If EN = 0 EN2 pin > selects between Power Down and Sleep Mode ... I see no reason why > this is not possible/allowed ... > > Hmm.. I do not like the idea of deprecating the "ti,enable-gpios" > property into 2 seperate properties ... but if this would be a reason > for not accepting this patch, I can do this ... How should I name > the 2 new properties? I guess if this ever happens, then we just add "ti,enable2-gpios" and ti,enable-gpios continues to point to EN. We don't need to deprecate anything (or maybe just deprecate having both GPIOs on single property). In that case, Acked-by: Rob Herring > > "ti,pin-enable" and "ti,pin-enable2" ? > > bye, > Heiko > -- > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Re: [PATCH] Make EN2 pin optional in the TRF7970A driver
On Tue, Feb 07, 2017 at 06:22:04AM +0100, Heiko Schocher wrote: > From: Guan Ben > > Make the EN2 pin optional. This is useful for boards, > which have this pin fix wired, for example to ground. > > Signed-off-by: Guan Ben > Signed-off-by: Mark Jonas > Signed-off-by: Heiko Schocher > > --- > > .../devicetree/bindings/net/nfc/trf7970a.txt | 4 ++-- > drivers/nfc/trf7970a.c | 26 > -- > 2 files changed, 16 insertions(+), 14 deletions(-) > > diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt > b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt > index 32b35a0..5889a3d 100644 > --- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt > +++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt > @@ -5,8 +5,8 @@ Required properties: > - spi-max-frequency: Maximum SPI frequency (<= 200). > - interrupt-parent: phandle of parent interrupt handler. > - interrupts: A single interrupt specifier. > -- ti,enable-gpios: Two GPIO entries used for 'EN' and 'EN2' pins on the > - TRF7970A. > +- ti,enable-gpios: One or two GPIO entries used for 'EN' and 'EN2' pins on > the > + TRF7970A. EN2 is optional. Could EN ever be optional/fixed? If so, perhaps deprecate this property and do 2 properties, one for each pin. Rob
Re: [PATCH v4 1/3] Documentation: dt: net: add mt76 wireless device binding
On Thu, Feb 02, 2017 at 12:52:06PM +0100, Felix Fietkau wrote:
> Signed-off-by: Felix Fietkau
> ---
> .../bindings/net/wireless/mediatek,mt76.txt| 25
> ++
> 1 file changed, 25 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
> b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
> new file mode 100644
> index ..2be480c0eab8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
> @@ -0,0 +1,25 @@
> +* MediaTek mt76xx devices
> +
> +This node provides properties for configuring the MediaTek mt76xx wireless
> +device. The node is expected to be specified as a child node of the PCI
> +controller to which the wireless chip is connected.
> +
> +Optional properties:
> +
> +- mac-address: See ethernet.txt in the parent directory
> +- local-mac-address: See ethernet.txt in the parent directory
> +- ieee80211-freq-limit: See ieee80211.txt
> +- mediatek,mtd-eeprom: Specify a MTD partition + offset containing EEPROM
> data
> +
> +&pcie {
> + status = "okay";
> +
> + pcie0 {
> + mt76@0,0 {
wifi@0,0
> + reg = <0x 0 0 0 0>;
> + device_type = "pci";
This only applies to PCI bridge nodes, so drop.
> + ieee80211-freq-limit = <500 600>;
> + mediatek,mtd-eeprom = <&factory 0x8000>;
> + };
> + };
> +};
> --
> 2.11.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] NFC: remove TI nfcwilink driver
It appears that TI WiLink devices including NFC (WL185x/WL189x) never
shipped. The only information I found were announcements in Feb
2012 about the parts. There's been no activity on this driver besided
common changes since initially added in Jan 2012. There's also no in
users that instantiate the platform device (nor DT bindings).
This is a first step in removing TI ST (shared transport) driver in
favor of extending the BT hci_ll driver to support WL183x chips.
Cc: Ilan Elias
Cc: Marcel Holtmann
Cc: Samuel Ortiz
Cc: Lauro Ramos Venancio
Cc: Aloisio Almeida Jr
Cc: linux-wireless@vger.kernel.org
Signed-off-by: Rob Herring
---
drivers/nfc/Kconfig | 11 -
drivers/nfc/Makefile| 1 -
drivers/nfc/nfcwilink.c | 578
3 files changed, 590 deletions(-)
delete mode 100644 drivers/nfc/nfcwilink.c
diff --git a/drivers/nfc/Kconfig b/drivers/nfc/Kconfig
index 9d2369269abf..c4208487fadc 100644
--- a/drivers/nfc/Kconfig
+++ b/drivers/nfc/Kconfig
@@ -5,17 +5,6 @@
menu "Near Field Communication (NFC) devices"
depends on NFC
-config NFC_WILINK
- tristate "Texas Instruments NFC WiLink driver"
- depends on TI_ST && NFC_NCI
- help
- This enables the NFC driver for Texas Instrument's BT/FM/GPS/NFC
- combo devices. This makes use of shared transport line discipline
- core driver to communicate with the NFC core of the combo chip.
-
- Say Y here to compile support for Texas Instrument's NFC WiLink driver
- into the kernel or say M to compile it as module.
-
config NFC_TRF7970A
tristate "Texas Instruments TRF7970a NFC driver"
depends on SPI && NFC_DIGITAL
diff --git a/drivers/nfc/Makefile b/drivers/nfc/Makefile
index bab8ef06ae35..640b7274371c 100644
--- a/drivers/nfc/Makefile
+++ b/drivers/nfc/Makefile
@@ -6,7 +6,6 @@ obj-$(CONFIG_NFC_FDP) += fdp/
obj-$(CONFIG_NFC_PN544)+= pn544/
obj-$(CONFIG_NFC_MICROREAD)+= microread/
obj-$(CONFIG_NFC_PN533)+= pn533/
-obj-$(CONFIG_NFC_WILINK) += nfcwilink.o
obj-$(CONFIG_NFC_MEI_PHY) += mei_phy.o
obj-$(CONFIG_NFC_SIM) += nfcsim.o
obj-$(CONFIG_NFC_PORT100) += port100.o
diff --git a/drivers/nfc/nfcwilink.c b/drivers/nfc/nfcwilink.c
deleted file mode 100644
index 3fbd18b8e473..
--- a/drivers/nfc/nfcwilink.c
+++ /dev/null
@@ -1,578 +0,0 @@
-/*
- * Texas Instrument's NFC Driver For Shared Transport.
- *
- * NFC Driver acts as interface between NCI core and
- * TI Shared Transport Layer.
- *
- * Copyright (C) 2011 Texas Instruments, Inc.
- *
- * Written by Ilan Elias
- *
- * Acknowledgements:
- * This file is based on btwilink.c, which was written
- * by Raja Mani and Pavan Savoy.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, see <http://www.gnu.org/licenses/>.
- *
- */
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#define NFCWILINK_CHNL 12
-#define NFCWILINK_OPCODE 7
-#define NFCWILINK_MAX_FRAME_SIZE 300
-#define NFCWILINK_HDR_LEN 4
-#define NFCWILINK_OFFSET_LEN_IN_HDR1
-#define NFCWILINK_LEN_SIZE 2
-#define NFCWILINK_REGISTER_TIMEOUT 8000/* 8 sec */
-#define NFCWILINK_CMD_TIMEOUT 5000/* 5 sec */
-
-#define BTS_FILE_NAME_MAX_SIZE 40
-#define BTS_FILE_HDR_MAGIC 0x42535442
-#define BTS_FILE_CMD_MAX_LEN 0xff
-#define BTS_FILE_ACTION_TYPE_SEND_CMD 1
-
-#define NCI_VS_NFCC_INFO_CMD_GID 0x2f
-#define NCI_VS_NFCC_INFO_CMD_OID 0x12
-#define NCI_VS_NFCC_INFO_RSP_GID 0x4f
-#define NCI_VS_NFCC_INFO_RSP_OID 0x12
-
-struct nfcwilink_hdr {
- __u8 chnl;
- __u8 opcode;
- __le16 len;
-} __packed;
-
-struct nci_vs_nfcc_info_cmd {
- __u8 gid;
- __u8 oid;
- __u8 plen;
-} __packed;
-
-struct nci_vs_nfcc_info_rsp {
- __u8 gid;
- __u8 oid;
- __u8 plen;
- __u8 status;
- __u8 hw_id;
- __u8 sw_ver_x;
- __u8 sw_ver_z;
- __u8 patch_id;
-} __packed;
-
-struct bts_file_hdr {
- __le32 magic;
- __le32 ver;
- __u8 rfu[24];
- __u8 actions[0];
-} __packed;
-
-struct bts_file_action {
- __le16 type;
- __le16 len;
- __u8 data[0];
-} __packed;
-
-struct nfcwilink {
- struct
Re: [PATCH v3 1/2] devicetree: document new marvell-8xxx and pwrseq-sd8787 options
On Thu, Jan 12, 2017 at 09:29:36PM -0800, Matt Ranostay wrote:
Changelog?
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Matt Ranostay
> ---
> .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14
> ++
> .../devicetree/bindings/net/wireless/marvell-8xxx.txt | 7 ++-
> 2 files changed, 20 insertions(+), 1 deletion(-)
> create mode 100644
> Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>
> diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
> b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
> new file mode 100644
> index ..1b658351629b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
> @@ -0,0 +1,14 @@
> +* Marvell SD8787 power sequence provider
> +
> +Required properties:
> +- compatible: must be "mmc-pwrseq-sd8787".
> +- pwndn-gpio: contains a power down GPIO specifier.
powerdown-gpios
> +- reset-gpio: contains a reset GPIO specifier.
reset-gpios
And state the active state for both.
> +
> +Example:
> +
> + wifi_pwrseq: wifi_pwrseq {
> + compatible = "mmc-pwrseq-sd8787";
> + pwrdn-gpio = <&twl_gpio 0 GPIO_ACTIVE_LOW>;
> + reset-gpio = <&twl_gpio 1 GPIO_ACTIVE_LOW>;
> + }
> diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> index 980b16df74c3..0854451ff91d 100644
> --- a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> @@ -1,4 +1,4 @@
> -Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
> +Marvell 8787/8897/8997 (sd8787/sd8897/sd8997/pcie8997) SDIO/PCIE devices
> --
>
> This node provides properties for controlling the Marvell SDIO/PCIE wireless
> device.
> @@ -8,6 +8,7 @@ connects the device to the system.
> Required properties:
>
>- compatible : should be one of the following:
> + * "marvell,sd8787"
> * "marvell,sd8897"
> * "marvell,sd8997"
> * "pci11ab,2b42"
> @@ -34,6 +35,9 @@ Optional properties:
>so that the wifi chip can wakeup host platform under certain
> condition.
>during system resume, the irq will be disabled to make sure
>unnecessary interrupt is not received.
> + - vmmc-supply: a phandle of a regulator, supplying VCC to the card
> + - mmc-pwrseq: phandle to the MMC power sequence node. See "mmc-pwrseq-*"
> + for documentation of MMC power sequence bindings.
>
> Example:
>
> @@ -46,6 +50,7 @@ so that firmware can wakeup host using this device side pin.
> &mmc3 {
> status = "okay";
> vmmc-supply = <&wlan_en_reg>;
> + mmc-pwrseq = <&wifi_pwrseq>;
> bus-width = <4>;
> cap-power-off-card;
> keep-power-in-suspend;
> --
> 2.10.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] devicetree: document vmmc-supply and mmc-pwrseq options
On Thu, Jan 12, 2017 at 09:22:17PM -0800, Matt Ranostay wrote: > Cc: devicet...@vger.kernel.org > Signed-off-by: Matt Ranostay > --- > Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) Acked-by: Rob Herring
Re: [PATCH V6 1/3] dt-bindings: document common IEEE 802.11 frequency limit property
On Thu, Jan 5, 2017 at 5:51 AM, Johannes Berg wrote: > >> Acked-by: Rob Herring > > Do I take that to mean that we'll merge it through the subsystem tree, > and not go through some common DT tree? Yes, that's generally the case when bindings are in a series with driver changes. Rob
Re: [PATCH V6 1/3] dt-bindings: document common IEEE 802.11 frequency limit property
On Wed, Jan 4, 2017 at 11:58 AM, Rafał Miłecki wrote: > From: Rafał Miłecki > > This new file should be used for properties that apply to all wireless > devices. > > Signed-off-by: Rafał Miłecki > --- > V2: Switch to a single ieee80211-freq-limit property that allows specifying > *multiple* ranges. This resolves problem with more complex rules as > pointed > by Felx. > Make description implementation agnostic as pointed by Arend. > Rename node to wifi as suggested by Martin. > V3: Use more real-life frequencies in the example. > V5: Describe hardware design as possible use for this property > V6: Even better property description, thanks Rob for your help! > --- > .../devicetree/bindings/net/wireless/ieee80211.txt | 24 > ++ > 1 file changed, 24 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/net/wireless/ieee80211.txt Acked-by: Rob Herring
Re: [PATCH V5 4/3] brcmfmac: use wiphy_read_of_freq_limits to respect extra limits
On Tue, Jan 03, 2017 at 11:57:15PM +0100, Rafał Miłecki wrote: > From: Rafał Miłecki > > There are some devices (e.g. Netgear R8000 home router) with one chipset > model used for different radios, some of them limited to subbands. NVRAM > entries don't contain any extra info on such limitations and firmware > reports full list of channels to us. We need to store extra limitation > info on DT to support such devices properly. This is the type of explanation that I'm looking for in the DT patch as well as the examples of where this data comes from now. Certainly, I think having per platform settings in userspace is not what you want. Rob
Re: [PATCH V4 1/2] dt-bindings: document common IEEE 802.11 frequency limit property
On Tue, Jan 03, 2017 at 12:03:38PM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> This new file should be used for properties that apply to all wireless
> devices.
The commit msg should answer the questions I asked on v1.
> Signed-off-by: Rafał Miłecki
> ---
> V2: Switch to a single ieee80211-freq-limit property that allows specifying
> *multiple* ranges. This resolves problem with more complex rules as
> pointed
> by Felx.
> Make description implementation agnostic as pointed by Arend.
> Rename node to wifi as suggested by Martin.
> V3: Use more real-life frequencies in the example.
> ---
> .../devicetree/bindings/net/wireless/ieee80211.txt | 18
> ++
> 1 file changed, 18 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/net/wireless/ieee80211.txt
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
> b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
> new file mode 100644
> index 000..0cd1219
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
> @@ -0,0 +1,18 @@
> +Common IEEE 802.11 properties
> +
> +This provides documentation of common properties that are valid for all
> wireless
> +devices.
> +
> +Optional properties:
> + - ieee80211-freq-limit : list of supported frequency ranges in KHz
> +
> +Example:
> +
> +pcie@0,0 {
> + reg = <0x 0 0 0 0>;
> + wifi@0,0 {
> + reg = <0x 0 0 0 0>;
> + ieee80211-freq-limit = <2402000 2482000>,
> +<517 525>;
> + };
> +};
> --
> 2.10.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] dt-bindings: document common IEEE 802.11 frequency properties
On Wed, Dec 28, 2016 at 04:59:54PM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> This new file should be used for properties handled at higher level and
> so usable with all drivers.
Why is this needed? Where would this data normally come from?
> Signed-off-by: Rafał Miłecki
> ---
> .../devicetree/bindings/net/wireless/ieee80211.txt | 16
>
> 1 file changed, 16 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/net/wireless/ieee80211.txt
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
> b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
> new file mode 100644
> index 000..c762769
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
> @@ -0,0 +1,16 @@
> +Common IEEE 802.11 properties
> +
> +This provides documentation of common properties that are handled by a proper
> +net layer and don't require extra driver code.
Not relavent to a binding. Bindings describe h/w.
> +
> +Optional properties:
> + - ieee80211-min-center-freq : minimal supported frequency in KHz
> + - ieee80211-max-center-freq : maximal supported frequency in KHz
> +
> +Example:
> +
> +pcie@0,0 {
> + reg = <0x 0 0 0 0>;
> + ieee80211-min-center-freq = <2437000>;
> + ieee80211-max-center-freq = <2457000>;
> +};
> --
> 2.10.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/3] NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage
On Wed, Dec 21, 2016 at 11:18:33PM -0500, Geoff Lansberry wrote: > The TRF7970A has configuration options for supporting hardware designs > with 1.8 Volt or 3.3 Volt IO. This commit adds a device tree option, > using a fixed regulator binding, for setting the io voltage to match > the hardware configuration. If no option is supplied it defaults to > 3.3 volt configuration. > > Signed-off-by: Geoff Lansberry > --- > .../devicetree/bindings/net/nfc/trf7970a.txt | 2 ++ Acked-by: Rob Herring > drivers/nfc/trf7970a.c | 26 > +- > 2 files changed, 27 insertions(+), 1 deletion(-)
Re: [PATCH v3 1/3] NFC: trf7970a: add device tree option for 27MHz clock
On Wed, Dec 21, 2016 at 11:18:32PM -0500, Geoff Lansberry wrote: > The TRF7970A has configuration options to support hardware designs > which use a 27.12MHz clock. This commit adds a device tree option > 'clock-frequency' to support configuring the this chip for default > 13.56MHz clock or the optional 27.12MHz clock. > > Signed-off-by: Geoff Lansberry > --- > .../devicetree/bindings/net/nfc/trf7970a.txt | 2 + Acked-by: Rob Herring > drivers/nfc/trf7970a.c | 50 > +- > 2 files changed, 41 insertions(+), 11 deletions(-)
Re: [PATCH 1/3] NFC: trf7970a: add device tree option for 27MHz clock
On Mon, Dec 19, 2016 at 5:23 PM, Geoff Lansberry wrote: > I can make that change, however, I worry that it may be a bit > misleading, since there are only two supported clock frequencies, but > a number like that to me implies that it could be set to any number > you want. I'm new at this, and so I'll go ahead and change it as you > request, but I'd like to hear your thoughts on my concern. Then the binding doc just needs to state what are the 2 valid frequencies. Rob
Re: [PATCH 2/3] NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage
On Thu, Dec 15, 2016 at 05:30:43PM -0500, Geoff Lansberry wrote: > From: Geoff Lansberry > > --- > Documentation/devicetree/bindings/net/nfc/trf7970a.txt | 2 ++ > drivers/nfc/trf7970a.c | 13 - > 2 files changed, 14 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt > b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt > index 9dda879..208f045 100644 > --- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt > +++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt > @@ -21,6 +21,7 @@ Optional SoC Specific Properties: > - t5t-rmb-extra-byte-quirk: Specify that the trf7970a has the erratum >where an extra byte is returned by Read Multiple Block commands issued >to Type 5 tags. > +- vdd_io_1v8: Set to specify that the trf7970a io voltage should be set to > 1.8V Use the regulator binding and provide a fixed 1.8V supply. > - crystal_27mhz: Set to specify that the input frequency to the trf7970a is > 27.12MHz > > > @@ -45,6 +46,7 @@ Example (for ARM-based BeagleBone with TRF7970A on SPI1): > irq-status-read-quirk; > en2-rf-quirk; > t5t-rmb-extra-byte-quirk; > + vdd_io_1v8; > crystal_27mhz; > status = "okay"; > };
Re: [PATCH 1/3] NFC: trf7970a: add device tree option for 27MHz clock
On Thu, Dec 15, 2016 at 05:30:42PM -0500, Geoff Lansberry wrote: > From: Geoff Lansberry > > --- > .../devicetree/bindings/net/nfc/trf7970a.txt | 3 ++ > drivers/nfc/trf7970a.c | 42 > -- > 2 files changed, 34 insertions(+), 11 deletions(-) > > diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt > b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt > index 32b35a0..9dda879 100644 > --- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt > +++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt > @@ -21,6 +21,8 @@ Optional SoC Specific Properties: > - t5t-rmb-extra-byte-quirk: Specify that the trf7970a has the erratum >where an extra byte is returned by Read Multiple Block commands issued >to Type 5 tags. > +- crystal_27mhz: Set to specify that the input frequency to the trf7970a is > 27.12MHz > + Can't you use 'clock-frequency = "2700";'? > > Example (for ARM-based BeagleBone with TRF7970A on SPI1): > > @@ -43,6 +45,7 @@ Example (for ARM-based BeagleBone with TRF7970A on SPI1): > irq-status-read-quirk; > en2-rf-quirk; > t5t-rmb-extra-byte-quirk; > + crystal_27mhz; > status = "okay"; > }; > };
Re: [PATCH] mmc: pwrseq: add support for Marvell SD8787 chip
On Mon, Nov 28, 2016 at 9:54 AM, Ulf Hansson wrote:
> [...]
>
>>> +
>>> +Example:
>>> +
>>> + wifi_pwrseq: wifi_pwrseq {
>>> + compatible = "mmc-pwrseq-sd8787";
>>> + pwrdn-gpio = <&twl_gpio 0 GPIO_ACTIVE_LOW>;
>>> + reset-gpio = <&twl_gpio 1 GPIO_ACTIVE_LOW>;
>>> + }
>>> diff --git
>>> a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>>> b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>>> index c421aba0a5bc..08fd65d35725 100644
>>> --- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>>> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>>> @@ -32,6 +32,9 @@ Optional properties:
>>>so that the wifi chip can wakeup host platform under certain
>>> condition.
>>>during system resume, the irq will be disabled to make sure
>>>unnecessary interrupt is not received.
>>> + - vmmc-supply: a phandle of a regulator, supplying VCC to the card
>>
>> This is why pwrseq is wrong. You have some properties in the card node
>> and some in pwrseq node. Everything should be in the card node.
>
> Put "all" in the card node, just doesn't work for MMC. Particular in
> cases when we have removable cards, as then it would be wrong to have
> a card node.
When is there a problem with removable cards? The connector is
standard and everything needed (CD, VMMC, VDDIO, etc.) is defined in
the host controller node. If that isn't sufficient, then we should
start defining a connector node.
> The mmc pwrseq DT bindings just follows the legacy approach for MMC
> and that's why the pwrseq handle is at the controller node. Yes, would
> could have done it differently, but this is the case now, so we will
> have to accept that.
We're stuck with supporting the existing cases. That doesn't mean
we're stuck with the same thing for new cases.
Rob
Re: [PATCH] mmc: pwrseq: add support for Marvell SD8787 chip
On Thu, Nov 17, 2016 at 05:55:09PM -0800, Matt Ranostay wrote:
> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
> This can be abstracted to other chipsets if needed in the future.
I don't like the MMC pwrseq bindings, so I won't be acking any. Look at
the USB pwrseq for why.
> Cc: Tony Lindgren
> Cc: Ulf Hansson
> Cc: Mark Rutland
> Cc: Srinivas Kandagatla
> Signed-off-by: Matt Ranostay
> ---
> .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14 +++
> .../bindings/net/wireless/marvell-sd8xxx.txt | 4 +
> drivers/mmc/core/Kconfig | 10 ++
> drivers/mmc/core/Makefile | 1 +
> drivers/mmc/core/pwrseq_sd8787.c | 117
> +
> 5 files changed, 146 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
> create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
>
> diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
> b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
> new file mode 100644
> index ..1b658351629b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
> @@ -0,0 +1,14 @@
> +* Marvell SD8787 power sequence provider
> +
> +Required properties:
> +- compatible: must be "mmc-pwrseq-sd8787".
> +- pwndn-gpio: contains a power down GPIO specifier.
powerdown-gpios
> +- reset-gpio: contains a reset GPIO specifier.
reset-gpios
> +
> +Example:
> +
> + wifi_pwrseq: wifi_pwrseq {
> + compatible = "mmc-pwrseq-sd8787";
> + pwrdn-gpio = <&twl_gpio 0 GPIO_ACTIVE_LOW>;
> + reset-gpio = <&twl_gpio 1 GPIO_ACTIVE_LOW>;
> + }
> diff --git
> a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> index c421aba0a5bc..08fd65d35725 100644
> --- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> @@ -32,6 +32,9 @@ Optional properties:
>so that the wifi chip can wakeup host platform under certain
> condition.
>during system resume, the irq will be disabled to make sure
>unnecessary interrupt is not received.
> + - vmmc-supply: a phandle of a regulator, supplying VCC to the card
This is why pwrseq is wrong. You have some properties in the card node
and some in pwrseq node. Everything should be in the card node.
> + - mmc-pwrseq: phandle to the MMC power sequence node. See "mmc-pwrseq-*"
> + for documentation of MMC power sequence bindings.
>
> Example:
>
> @@ -44,6 +47,7 @@ so that firmware can wakeup host using this device side pin.
> &mmc3 {
> status = "okay";
> vmmc-supply = <&wlan_en_reg>;
> + mmc-pwrseq = <&wifi_pwrseq>;
> bus-width = <4>;
> cap-power-off-card;
> keep-power-in-suspend;
Re: [PATCH v8] mwifiex: parse device tree node for PCIe
On Fri, Nov 18, 2016 at 06:21:41PM +0200, Kalle Valo wrote: > Amitkumar Karwar writes: > > > From: Xinming Hu > > > > This patch derives device tree node from pcie bus layer framework. > > Device tree bindings file has been renamed(marvell-sd8xxx.txt -> > > marvell-8xxx.txt) to accommodate PCIe changes. > > > > Signed-off-by: Xinming Hu > > Signed-off-by: Rajat Jain > > Reviewed-by: Brian Norris > > Signed-off-by: Amitkumar Karwar > > [...] > > > @@ -10,6 +10,8 @@ Required properties: > >- compatible : should be one of the following: > > * "marvell,sd8897" > > * "marvell,sd8997" > > + * "pci11ab,2b42" > > + * "pci1b4b,2b42" > > Are these correct? In v6 Rob said: Yes, Marvell has 2 vendor IDs it turns out. > > "I think I already said this, but you have the vendor and product IDs > reversed." > > https://patchwork.kernel.org/patch/9390225/ > > -- > Kalle Valo > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8] mwifiex: parse device tree node for PCIe
On Fri, Nov 18, 2016 at 06:07:04PM +0530, Amitkumar Karwar wrote:
> From: Xinming Hu
>
> This patch derives device tree node from pcie bus layer framework.
> Device tree bindings file has been renamed(marvell-sd8xxx.txt ->
> marvell-8xxx.txt) to accommodate PCIe changes.
>
> Signed-off-by: Xinming Hu
> Signed-off-by: Rajat Jain
> Reviewed-by: Brian Norris
> Signed-off-by: Amitkumar Karwar
> ---
> v2: Included vendor and product IDs in compatible strings for PCIe
> chipsets(Rob Herring)
> v3: Patch is created using -M option so that it will only include diff of
> original and renamed files(Rob Herring)
> Resend v3: Resending the patch because I missed to include device tree mailing
> while sending v3.
> v4: Fix error handling, also move-on even if no device tree node is present.
> v5: Update commit log to include memory leak, return -EINVAL instead of -1.
> v6: Remove an unnecessary error print, fix typo in commit log
> v7: a) Earlier versions of this patch claims to have a change which fixes
> "memory
>leak". But it actually introduces double-free problem. That change is
> removed
> here(Brian Norris)
> b) Cosmetic change in bindings documentation(Rob Herring)
> s/marvell/Marvell/
> s/sdio\/pcie/SDIO\/PCIE/
> v8: Same as v7. I had missed to CC device tree mailing list in v7. Correcting
> this
> in v8.
> ---
> .../{marvell-sd8xxx.txt => marvell-8xxx.txt} | 8 +---
Acked-by: Rob Herring
> drivers/net/wireless/marvell/mwifiex/pcie.c| 24
> ++
> drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 3 ++-
> 3 files changed, 31 insertions(+), 4 deletions(-)
> rename Documentation/devicetree/bindings/net/wireless/{marvell-sd8xxx.txt =>
> marvell-8xxx.txt} (91%)
Re: [PATCHv2 3/4] dt: bindings: add new dt entry for BTCOEX feature in qcom,ath10k.txt
On Thu, Nov 17, 2016 at 05:14:23PM +0530, c_tr...@qti.qualcomm.com wrote: > From: Tamizh chelvam > > There two things done in this patch. > > 1) 'btcoex_support' flag for BTCOEX feature support by the hardware. > 2) 'wlan_btcoex_gpio' is used to fill wlan priority pin number for >BTCOEX priority feature support. > > Signed-off-by: Tamizh chelvam > --- > .../bindings/net/wireless/qcom,ath10k.txt |4 > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt > b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt > index 74d7f0a..08150e2d 100644 > --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt > +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt > @@ -46,6 +46,10 @@ Optional properties: >hw versions. > - qcom,ath10k-pre-calibration-data : pre calibration data as an array, >the length can vary between hw versions. > +- btcoex_support : should contain eithr "0" or "1" to indicate btcoex > + support by the hardware. This is BT coexistence? Make this boolean and n > +- btcoex_gpio_pin : btcoex gpio pin number for the device which > + supports BTCOEX. This is a pin number on the chip, not any pin number Linux GPIO subsys cares about, right? Is there a connection to the host too, or this is internal between BT and WiFi? Do you really need 2 properties? Does supporting this feature require the GPIO? If so, then the first property is redundant. Needs vendor prefix and don't use '_'. Should be something like 'qcom,bt-coexist-gpio-pin'. Rob
Re: [PATCH 1/2] Documentation: devicetree: Add bindings info for rfkill-regulator
On Tue, Nov 01, 2016 at 11:58:39AM +0100, Paul Cercueil wrote: > This document gives information about how to write a devicetree > node that corresponds to the rfkill-regulator driver. > > Signed-off-by: Paul Cercueil > --- > .../devicetree/bindings/net/rfkill-regulator.txt | 18 > ++ > 1 file changed, 18 insertions(+) > create mode 100644 Documentation/devicetree/bindings/net/rfkill-regulator.txt > > diff --git a/Documentation/devicetree/bindings/net/rfkill-regulator.txt > b/Documentation/devicetree/bindings/net/rfkill-regulator.txt > new file mode 100644 > index 000..aac2fe1 > --- /dev/null > +++ b/Documentation/devicetree/bindings/net/rfkill-regulator.txt > @@ -0,0 +1,18 @@ > +Device tree bindings for the rfkill-regulator driver > + > +Required properties: > + - compatible: should be "rfkill-regulator" > + - rfkill-name: the name of this rfkill device > + - rfkill-type: the type of this rfkill device; > + must correspond to a valid rfkill_type from > > + - vrfkill-supply: phandle to a regulator My understanding is it is generally felt that using the regulator enable GPIO commonly found on WiFi chips for rfkill is an abuse of rfkill as it is more that just an RF disable. From a DT standpoint, this seems like creating a binding for what a Linux driver wants. Instead, I think this should be either a GPIO or GPIO regulator and the driver for the WiFi chip should decide whether or not to register that as an rfkill driver. Rob
Re: [PATCH v6] mwifiex: parse device tree node for PCIe
On Fri, Oct 21, 2016 at 02:21:09PM -0700, Rajat Jain wrote:
> From: Xinming Hu
>
> This patch derives device tree node from pcie bus layer framework, and
> fixes a minor memory leak in mwifiex_pcie_probe() (in failure path).
> Device tree bindings file has been renamed(marvell-sd8xxx.txt ->
> marvell-8xxx.txt) to accommodate PCIe changes.
>
> Signed-off-by: Xinming Hu
> Signed-off-by: Amitkumar Karwar
> Signed-off-by: Rajat Jain
> Reviewed-by: Brian Norris
> ---
> v2: Included vendor and product IDs in compatible strings for PCIe
> chipsets(Rob Herring)
> v3: Patch is created using -M option so that it will only include diff of
> original and renamed files(Rob Herring)
> Resend v3: Resending the patch because I missed to include device tree mailing
> while sending v3.
> v4: Fix error handling, also move-on even if no device tree node is present.
> v5: Update commit log to include memory leak, return -EINVAL instead of -1.
> v6: Remove an unnecessary error print, fix typo in commit log
>
> .../{marvell-sd8xxx.txt => marvell-8xxx.txt} | 8 +++--
> drivers/net/wireless/marvell/mwifiex/pcie.c| 36
> +++---
> drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 3 +-
> 3 files changed, 39 insertions(+), 8 deletions(-)
> rename Documentation/devicetree/bindings/net/wireless/{marvell-sd8xxx.txt =>
> marvell-8xxx.txt} (91%)
>
> diff --git
> a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> similarity index 91%
> rename from Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> rename to Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> index c421aba..dfe5f8e 100644
> --- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> @@ -1,8 +1,8 @@
> -Marvell 8897/8997 (sd8897/sd8997) SDIO devices
> +Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
> --
>
> -This node provides properties for controlling the marvell sdio wireless
> device.
> -The node is expected to be specified as a child node to the SDIO controller
> that
> +This node provides properties for controlling the marvell sdio/pcie wireless
> device.
s/marvell/Marvell/
s/sdio\/pcie/SDIO\/PCIE/
> +The node is expected to be specified as a child node to the SDIO/PCIE
> controller that
> connects the device to the system.
>
> Required properties:
> @@ -10,6 +10,8 @@ Required properties:
>- compatible : should be one of the following:
> * "marvell,sd8897"
> * "marvell,sd8997"
> + * "pci11ab,2b42"
> + * "pci1b4b,2b42"
I think I already said this, but you have the vendor and product IDs
reversed.
Rob
Re: [PATCH v8 1/3] Documentation: dt: net: add ath9k wireless device binding
On Sun, Oct 16, 2016 at 10:59:05PM +0200, Martin Blumenstingl wrote: > Add documentation how devicetree can be used to configure ath9k based > devices. > > Signed-off-by: Martin Blumenstingl > --- > .../devicetree/bindings/net/wireless/qca,ath9k.txt | 48 > ++ > 1 file changed, 48 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt Acked-by: Rob Herring
Re: [PATCH v7 1/3] Documentation: dt: net: add ath9k wireless device binding
On Sun, Oct 02, 2016 at 11:47:41PM +0200, Martin Blumenstingl wrote:
> Add documentation how devicetree can be used to configure ath9k based
> devices.
>
> Signed-off-by: Martin Blumenstingl
> ---
> .../devicetree/bindings/net/wireless/qca,ath9k.txt | 30
> ++
> 1 file changed, 30 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 000..9b58ede
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> @@ -0,0 +1,30 @@
> +* 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: For PCI and PCIe devices this should be an identifier following
> + the format as defined in "PCI Bus Binding to Open Firmware"
> + Revision 2.1. One of the possible formats is "pci,"
> + where is the PCI vendor ID and is PCI device ID.
Are there some known values you can document here? Like the one in the
example.
> +- reg: Address and length of the register set for the device.
> +
> +Optional properties:
> +- qca,no-eeprom: Indicates that there is no physical EEPROM connected to the
> + ath9k wireless chip (in this case the calibration /
> + EEPROM data will be loaded from userspace using the
> + kernel firmware loader).
> +- mac-address: See ethernet.txt in the parent directory
> +- local-mac-address: See ethernet.txt in the parent directory
> +
> +
> +In this example, the node is defined as child node of the PCI controller:
> +&pci0 {
> + ath9k@168c,002d {
wifi@...
> + compatible = "pci168c,002d";
> + reg = <0x7000 0 0 0 0x1000>;
> + qca,no-eeprom;
> + };
> +};
> --
> 2.10.0
>
Re: [RFC 0/3] of: add common bindings to (de)activate IEEE 802.11 bands
On Wed, Oct 5, 2016 at 1:36 PM, Felix Fietkau wrote: > On 2016-10-05 20:25, Martin Blumenstingl wrote: >> On Mon, Oct 3, 2016 at 5:22 PM, Rob Herring wrote: >>> On Sun, Oct 2, 2016 at 5:50 PM, Martin Blumenstingl >>> wrote: >>>> There are at least two drivers (ath9k and mt76) out there, where >>>> devicetree authors need to override the enabled bands. >>>> >>>> For ath9k there is only one use-case: disabling a band which has been >>>> incorrectly enabled by the vendor in the EEPROM (enabling a band is not >>>> possible because the calibration data would be missing in the EEPROM). >>>> The mt76 driver (currently pending for review) however allows enabling >>>> and disabling the 2.4GHz and 5GHz band, see [0]. >>>> >>>> Based on the discussion of (earlier versions of) my ath9k devicetree >>>> patch it was suggested [1] that we use enable- and disable- properties. >>>> The current patch implements: >>>> - bands can be enabled or disabled with the corresponding property >>>> - if both (disable and enable) properties are given and a driver asks >>>> whether the band is enabled then the logic will return false (= not >>>> enabled, preferring the disabled flag) >>>> - if both (disable and enable) properties are given and a driver asks >>>> whether the band is disabled then the logic will return true (again, >>>> preferring the disabled flag over the enabled flag) >>>> >>>> We can still change the logic to do what the mt76 driver does (I am >>>> fine with both solutions): >>>> - property not available: driver decides which bands to enable >>>> - property set to 0: disable the band >>>> - property set to 1: enable the band >>> >>> I prefer this way. Really, I'd prefer just a boolean disable property. >>> I'm not sure why you need the enable. We usually have these tri-state >>> properties when you want not present to mean use the bootloader or >>> default setting. Try to make not present the most common case. >> Felix: could you please give a few details why mt76 can not only >> disable but also enable a specific band? >> There is no specific comment in the sources [0] why this is needed. >> All other drivers that I am aware of (ath9k, rt2x00) only allow >> disabling a specific band, they never enable it (this has to be done >> explicitly by the EEPROM). > None of the devices use it at the moment, I probably added it when I > played with a device that had broken EEPROM data. I guess I decided to > do it this way because on many devices the band capability field simply > cannot be trusted. > I guess I would be okay with just having a disable property and adding > an enable property later only if we end up actually needing it. If EEPROM is commonly wrong or missing, then seems like you want to plan ahead and support both enable and disable. The other approach I've mentioned before is just put raw EEPROM data into DT to override the EEPROM. This would be better if there's a large number of settings you need. Rob
Re: [PATCH RESEND v3] mwifiex: parse device tree node for PCIe
On Thu, Sep 29, 2016 at 10:09:43PM +0530, Amitkumar Karwar wrote:
> From: Xinming Hu
>
> This patch derives device tree node from pcie bus layer framework.
> Device tree bindings file has been renamed(marvell-sd8xxx.txt ->
> marvell-8xxx.txt) to accomodate PCIe changes.
>
> Signed-off-by: Xinming Hu
> Signed-off-by: Amitkumar Karwar
> ---
> v2: Included vendor and product IDs in compatible strings for PCIe
> chipsets(Rob Herring)
> v3: Patch is created using -M option so that it will only include diff of
> original and renamed files(Rob Herring)
> Resend v3: Resending the patch because I missed to include device tree mailing
> while sending v3.
> ---
> .../{marvell-sd8xxx.txt => marvell-8xxx.txt} | 8 +---
> drivers/net/wireless/marvell/mwifiex/pcie.c | 20
>
> drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 3 ++-
> 3 files changed, 27 insertions(+), 4 deletions(-)
> rename Documentation/devicetree/bindings/net/wireless/{marvell-sd8xxx.txt =>
> marvell-8xxx.txt} (91%)
>
> diff --git
> a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> similarity index 91%
> rename from Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> rename to Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> index c421aba..dfe5f8e 100644
> --- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> @@ -1,8 +1,8 @@
> -Marvell 8897/8997 (sd8897/sd8997) SDIO devices
> +Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
> --
>
> -This node provides properties for controlling the marvell sdio wireless
> device.
> -The node is expected to be specified as a child node to the SDIO controller
> that
> +This node provides properties for controlling the marvell sdio/pcie wireless
> device.
Capitalize SDIO/PCIe
> +The node is expected to be specified as a child node to the SDIO/PCIE
> controller that
> connects the device to the system.
>
> Required properties:
> @@ -10,6 +10,8 @@ Required properties:
>- compatible : should be one of the following:
> * "marvell,sd8897"
> * "marvell,sd8997"
> + * "pci11ab,2b42"
> + * "pci1b4b,2b42"
The string is pci,. Looks like you have vendor and device
swapped.
Rob
Re: [RFC 0/3] of: add common bindings to (de)activate IEEE 802.11 bands
On Sun, Oct 2, 2016 at 5:50 PM, Martin Blumenstingl wrote: > There are at least two drivers (ath9k and mt76) out there, where > devicetree authors need to override the enabled bands. > > For ath9k there is only one use-case: disabling a band which has been > incorrectly enabled by the vendor in the EEPROM (enabling a band is not > possible because the calibration data would be missing in the EEPROM). > The mt76 driver (currently pending for review) however allows enabling > and disabling the 2.4GHz and 5GHz band, see [0]. > > Based on the discussion of (earlier versions of) my ath9k devicetree > patch it was suggested [1] that we use enable- and disable- properties. > The current patch implements: > - bands can be enabled or disabled with the corresponding property > - if both (disable and enable) properties are given and a driver asks > whether the band is enabled then the logic will return false (= not > enabled, preferring the disabled flag) > - if both (disable and enable) properties are given and a driver asks > whether the band is disabled then the logic will return true (again, > preferring the disabled flag over the enabled flag) > > We can still change the logic to do what the mt76 driver does (I am > fine with both solutions): > - property not available: driver decides which bands to enable > - property set to 0: disable the band > - property set to 1: enable the band I prefer this way. Really, I'd prefer just a boolean disable property. I'm not sure why you need the enable. We usually have these tri-state properties when you want not present to mean use the bootloader or default setting. Try to make not present the most common case. > The new code has been integrated into ath9k to demonstrate how to use > it (with the benefit that the disable_2ghz and disable_5ghz settings > from the ath9k_platform_data can now also be configured via .dts). > > open questions/decisions needed: > - where to place this new code? I put it into drivers/of/of_ieee80211 > because that's where most other functions live. > However, I found that this makes backporting the code harder (using > wireless-backports from the driver-backports project [2]) We are generally moving subsystem specific code like this out of drivers/of/, so please do that here. Maybe someone will get motivated to move the other networking code out too. > - we need a decision whether we want to go with two flags for each > band (enable-ieee80211-band and disable-ieee80211-band) or if we > prefer the solution from the mt76 driver (which means that the > property for a band is absent for auto-detection, or > ieee80211-band-enabled = <0/1> is specified. we could also move > the 0 and 1 to a header file of course to make it easer to read, > such as IEEE80211_BAND_ENABLED and IEEE80211_BAND_DISABLED) Please don't add defines for this. 0/1 meaning false/true is clear enough IMO. Rob
Re: [PATCH] mwifiex: parse device tree node for PCIe
On Fri, Sep 09, 2016 at 08:47:34PM +0530, Amitkumar Karwar wrote: > From: Xinming Hu > > This patch derives device tree node from pcie bus layer framework. > Device tree bindings file has been renamed(marvell-sd8xxx.txt -> > marvell-8xxx.txt) to accomodate PCIe changes. > > Signed-off-by: Xinming Hu > Signed-off-by: Amitkumar Karwar > --- > .../bindings/net/wireless/marvell-8xxx.txt | 64 > ++ > .../bindings/net/wireless/marvell-sd8xxx.txt | 63 - Resend using -M option so I do have to figure out if you added 1 line or changed a bunch. > drivers/net/wireless/marvell/mwifiex/pcie.c| 19 +++ > drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 3 +- > 4 files changed, 85 insertions(+), 64 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt > delete mode 100644 > Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt > > diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt > b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt > new file mode 100644 > index 000..a8a95aa > --- /dev/null > +++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt > @@ -0,0 +1,64 @@ > +Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices > +-- > + > +This node provides properties for controlling the marvell sdio/pcie wireless > device. > +The node is expected to be specified as a child node to the SDIO/PCIE > controller that > +connects the device to the system. > + > +Required properties: > + > + - compatible : should be one of the following: > + * "marvell,sd8897" > + * "marvell,sd8997" > + * "marvell,pcie8997" PCIe uses vendor and product IDs for compatible strings. Please read the OF PCI bus bindings doc. Rob
Re: [PATCH v6 1/3] Documentation: dt: net: add ath9k wireless device binding
On Fri, Sep 09, 2016 at 10:57:06PM +0200, Martin Blumenstingl wrote:
> On Fri, Sep 9, 2016 at 9:48 AM, Oleksij Rempel wrote:
> >> +Optional properties:
> >> +- reg: Address and length of the register set for the device.
> >> +- qca,clk-25mhz: Defines that a 25MHz clock is used
> >
> > Some SoCs even Atheros WiSoCs use WiFi clock for System Clock. In this
> > case we need to use clock framework any way, so why not in this case too?
> > Provide dummy static clock in DT and connect it with this node?
> >
> > osc25m: oscillator {
> > compatible = "fixed-clock";
> > #clock-cells = <0>;
> > clock-frequency = <2500>;
> > clock-accuracy = <3>;
> > };
> >
> > acc: clock-controller@8004 {
> > compatible = "some-clock-controller";
> > #clock-cells = <1>;
> > clocks = <&osc25m>;
> > reg = <0x8004 0x204>;
> > };
> >
> >
> > &pci0 {
> > ath9k@168c,002d {
> > compatible = "pci168c,002d";
> > reg = <0x7000 0 0 0 0x1000>;
> > clocks = <&osc25m>;
> > qca,disable-5ghz;
> > };
> > };
> >
> >
> > driver will need to use clk_get and compare frequency instead of
> > of_property_read_bool(np, "qca,clk-25mhz"). In this case you will need
> > to define source clock only one time and reuse it by all affected DT
> > nodes. If we have 40MHz clock you will only need to change it in
> > fixed-clock.
> that does sound like a good idea, thanks for that input!
> However, I will remove the property for the first version because I am
> trying to get PCI(e) devices supported. OF support for AHB (WiSoC)
> needs more work (in other places, like ahb.c) anyways.
> But this suggestion should be remembered!
>
> >> +- qca,no-eeprom: Indicates that there is no physical EEPROM connected to
> >> the
> >> + ath9k wireless chip (in this case the calibration /
> >> + EEPROM data will be loaded from userspace using the
> >> + kernel firmware loader).
> >> +- qca,disable-2ghz: Overrides the settings from the EEPROM and disables
> >> the
> >> + 2.4GHz band. Setting this property is only needed
> >> + when the RF circuit does not support the 2.4GHz band
> >> + while it is enabled nevertheless in the EEPROM.
> >> +- qca,disable-5ghz: Overrides the settings from the EEPROM and disables
> >> the
> >> + 5GHz band. Setting this property is only needed when
> >> + the RF circuit does not support the 5GHz band while
> >> + it is enabled nevertheless in the EEPROM.
> >
> > This option can be reused for every WiFi controller. Not only for qca.
> > So may be instead of adding vendor specific name, make it reusable for
> > all vendors. Instead of qca,disable-5ghz and qca,disable-2ghz make
> > disable-5ghz and disable-2ghz?
Fine, but if you do this then document in a common location.
> I am personally fine with anything that fits best into the grand
> scheme of things.
> There are three scenarios I can think of which may be influenced by
> devicetree configuration:
> a) let the driver decide automatically whether the 2.4GHz and/or 5GHz
> band is/are enabled
> b) explicitly disable either bands (because the driver thinks due to
> whatever reason that a band is supported while in reality it isn't)
> c) explicitly enable a band (for example because the driver cannot
> automagically detect which band should be enabled)
>
> for ath9k we default to a) but also allow b): the EEPROM (device
> specific calibration data) contains information about which bands are
> enabled (or not). But some manufacturers are shipping devices for
> example with the 5G band enabled, while the actual hardware doesn't
> support it.
And you can't determine that based on different device IDs? If you can
use vendor/device ID, then you should. If not, then this is fine.
Is it possible to have no EEPROM at all? If so, you might want to just
put the raw EEPROM data into DT rather than a property for every field
(I'm assuming there's more than just what you have properties for now).
Rob
Re: [PATCH v6 1/3] Documentation: dt: net: add ath9k wireless device binding
On Tue, Sep 06, 2016 at 11:46:21PM +0200, Martin Blumenstingl wrote:
> Add documentation how devicetree can be used to configure ath9k based
> devices.
>
> Signed-off-by: Martin Blumenstingl
> ---
> .../devicetree/bindings/net/wireless/qca,ath9k.txt | 39
> ++
> 1 file changed, 39 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 000..77b9202
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> @@ -0,0 +1,39 @@
> +* 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: For PCI and PCIe devices this should be an identifier following
> + the format as defined in "PCI Bus Binding to Open Firmware"
> + Revision 2.1. One of the possible formats is "pci,"
> + where is the PCI vendor ID and is PCI device ID.
> +
> +Optional properties:
> +- reg: Address and length of the register set for the device.
reg is not optional.
> +- qca,clk-25mhz: Defines that a 25MHz clock is used
> +- qca,no-eeprom: Indicates that there is no physical EEPROM connected to the
> + ath9k wireless chip (in this case the calibration /
> + EEPROM data will be loaded from userspace using the
> + kernel firmware loader).
> +- qca,disable-2ghz: Overrides the settings from the EEPROM and disables the
> + 2.4GHz band. Setting this property is only needed
> + when the RF circuit does not support the 2.4GHz band
> + while it is enabled nevertheless in the EEPROM.
> +- qca,disable-5ghz: Overrides the settings from the EEPROM and disables the
> + 5GHz band. Setting this property is only needed when
> + the RF circuit does not support the 5GHz band while
> + it is enabled nevertheless in the EEPROM.
> +- mac-address: See ethernet.txt in the parent directory
> +- local-mac-address: See ethernet.txt in the parent directory
> +
> +
> +In this example, the node is defined as child node of the PCI controller:
> +&pci0 {
> + ath9k@168c,002d {
unit address is not the vendor/device ID, but the reg value. So
'@7000,0,0' I think in this case. Double check the OF PCI bus binding.
> + compatible = "pci168c,002d";
> + reg = <0x7000 0 0 0 0x1000>;
> + qca,disable-5ghz;
> + };
> +};
> --
> 2.9.3
>
Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property
On Thu, Jul 07, 2016 at 10:46:28AM +0200, Arnd Bergmann wrote: > On Wednesday, July 6, 2016 9:19:41 PM CEST Arend Van Spriel wrote: > > On 6-7-2016 15:42, Arnd Bergmann wrote: > > > On Wednesday, July 6, 2016 10:08:55 AM CEST Arend Van Spriel wrote: > > >> On Tue, Jul 5, 2016 at 3:43 PM, Arnd Bergmann wrote: > > > All existing uses of the model property in arch/arm/boot/dts and most of > > > the ones in arch/powerpc/boot/dts are against the intended usage in > > > one way or another, but adding different kind of incorrect usage won't > > > improve that. > > > > > > The only way I can see the model property being used correctly would > > > be to have it match the first entry in the compatible property, but > > > that is completely redundant, so we tend to omit it, except for the > > > root node in which it is required. For the root node however, the > > > historic practice that has crept in on ARM is to put something completely > > > different in there, which is a human-readable description of the > > > machine rather than something we can use as a unique indentifier. > > > > > > I'd just consider the "model" property burned, and not use it for anything > > > that doesn't already use it, just like we handle "device_type": a few > > > things require it, nothing else should use it. > > > > If that is the agreed approach in devicetree arena I am fine with it. I > > have been unaware of this and just looked at the suggestion from Jonas > > seeing a solution to the problem at hand. > > I don't think it has been discussed or decided before as the question > has not come up, so for now this is my personal view. Maybe one of > the devicetree maintainers can comment on this. Back from vacation and getting caught up. I agree with Arnd here. In my view model is the OEM branding on the device, compatible is the h/w. If you have different firmware related files, that goes beyond OEM branding. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] wlcore: spi: add wl18xx support
On Sun, Jul 10, 2016 at 08:32:40AM +, Reizer, Eyal wrote: > Add support for using with both wl12xx and wl18xx. > > - all wilink family needs special init command for entering wspi mode. > extra clock cycles should be sent after the spi init command while the > cs pin is high. > - Use inverted chip select for sending a dummy 4 bytes command that > completes the init stage. > > Signed-off-by: Eyal Reizer > --- > v1->v2:update device tree bindings configuration > v2->v3:revert from manual gpio manipulation. use inverted chip select instead > for sending the extra init cycle which, achieves the same hardware purpose. > update device tree bindings docucmentation accordingly > v3->v4: Remove redundant data form binding documentation and fix chip select > number mismatch in wl1271 example > v4->v5: Rebase on top of head of wireless-drivers-next Please add acks when reposting. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property
On Fri, Jul 01, 2016 at 10:17:37AM +0200, Arend Van Spriel wrote: > > > On 1-7-2016 4:08, Rob Herring wrote: > > On Wed, Jun 29, 2016 at 04:04:31PM +0200, Hans de Goede wrote: > >> Add a brcm,nvram_file_name dt property to allow overruling the default > >> nvram filename for sdio devices. The idea is that we can specify a > >> board specific nvram file, e.g. brcmfmac43362-ap6210.txt for boards > >> with an ap6210 wifi sdio module and ship this in linux-firmware, so > >> that wifi will work out of the box, without requiring users to find > >> and then manually install the right nvram file for their board. > > > > What about putting its contents directly into DT? It's just text > > key/value pairs so it would match up well. > > It would be an option, but I have no clue how to dig up documentation of > these key,value pairs. The file is typically obtained from a wifi module > vendor which would need to be converted to DT format, ie. prefix with > "brcm," etc. From driver perspective this would mean it need to know > keys. Currently, it just takes the file contents and sends it to the device. Okay, if it is opaque, then probably best to treat as firmware and not change it. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property
On Wed, Jun 29, 2016 at 04:04:31PM +0200, Hans de Goede wrote:
> Add a brcm,nvram_file_name dt property to allow overruling the default
> nvram filename for sdio devices. The idea is that we can specify a
> board specific nvram file, e.g. brcmfmac43362-ap6210.txt for boards
> with an ap6210 wifi sdio module and ship this in linux-firmware, so
> that wifi will work out of the box, without requiring users to find
> and then manually install the right nvram file for their board.
What about putting its contents directly into DT? It's just text
key/value pairs so it would match up well.
Also, I have to wonder how all the non-SDIO based cards don't need this
file.
> Signed-off-by: Hans de Goede
> ---
> .../devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 2 ++
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c | 2 ++
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 6
> ++
> include/linux/platform_data/brcmfmac.h | 2 ++
> 4 files changed, 12 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> index 5dbf169..2ba13a6 100644
> --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> @@ -11,6 +11,7 @@ Required properties:
> Optional properties:
> - brcm,drive-strength : drive strength used for SDIO pins on device in mA
> (default = 6).
> + - brcm,nvram_file_name : name of the nvram file to load
The need for firmware file names has come up several times though
nothing merged to yet. There has been at least some level of agreement
to use "firmware-name" here.
> - interrupt-parent : the phandle for the interrupt controller to which the
> device interrupts are connected.
> - interrupts : specifies attributes for the out-of-band interrupt
> (host-wake).
> @@ -34,6 +35,7 @@ mmc3: mmc@01c12000 {
> brcmf: bcrmf@1 {
> reg = <1>;
> compatible = "brcm,bcm4329-fmac";
> + brcm,nvram_file_name = "brcm/brcmfmac43362-ap6210.txt";
> interrupt-parent = <&pio>;
> interrupts = <10 8>; /* PH10 / EINT10 */
> interrupt-names = "host-wake";
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] wlcore: spi: add wl18xx support
On Sun, Jun 26, 2016 at 10:10:54AM +, Reizer, Eyal wrote: > Add support for using with both wl12xx and wl18xx. > > - all wilink family needs special init command for entering wspi mode. > extra clock cycles should be sent after the spi init command while the > cs pin is high. > - Use inverted chip select for sending a dummy 4 bytes command that > completes the init stage. > > Signed-off-by: Eyal Reizer > --- > v1->v2:update device tree bindings configuration > v2->v3:revert from manual gpio manipulation. use inverted chip select instead > for sending the extra init cycle which, achieves the same hardware purpose. > update device tree bindings docucmentation accordingly > v3->v4: Remove redundant data form binding documentation and fix chip select > number mismatch in wl1271 example > > .../bindings/net/wireless/ti,wlcore,spi.txt| 41 +-- Acked-by: Rob Herring > drivers/net/wireless/ti/wlcore/spi.c | 124 > + > 2 files changed, 137 insertions(+), 28 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3] wlcore: spi: add wl18xx support
On Tue, Jun 21, 2016 at 12:02:06PM +, Reizer, Eyal wrote:
> Add support for using with both wl12xx and wl18xx.
>
> - all wilink family needs special init command for entering wspi mode.
> extra clock cycles should be sent after the spi init command while the
> cs pin is high.
> - Use inverted chip select for sending a dummy 4 bytes command that
> completes the init stage and puts the wilink chip into wspi mode.
>
> Signed-off-by: Eyal Reizer
> ---
> v1->v2:update device tree bindings configuration
> v2->v3:revert from manual gpio manipulation. use inverted chip select instead
> for sending the extra init cycle, which achieves the same hardware purpose.
> update device tree bindings docucmentation accordingly
>
> .../bindings/net/wireless/ti,wlcore,spi.txt| 47 ++--
> drivers/net/wireless/ti/wlcore/spi.c | 124
> +
> 2 files changed, 145 insertions(+), 26 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
> b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
> index 9180724..35467cf 100644
> --- a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
> @@ -1,19 +1,30 @@
> -* Texas Instruments wl1271 wireless lan controller
> +* Texas Instruments wl12xx/wl18xx wireless lan controller
>
> -The wl1271 chip can be connected via SPI or via SDIO. This
> +The wl12xx/wl18xx chips can be connected via SPI or via SDIO. This
> document describes the binding for the SPI connected chip.
>
> Required properties:
> -- compatible : Should be "ti,wl1271"
> +- compatible : Should be one of the following:
> +* "ti,wl1271"
> +* "ti,wl1273"
> +* "ti,wl1281"
> +* "ti,wl1283"
> +* "ti,wl1801"
> +* "ti,wl1805"
> +* "ti,wl1807"
> +* "ti,wl1831"
> +* "ti,wl1835"
> +* "ti,wl1837"
> - reg : Chip select address of device
> - spi-max-frequency : Maximum SPI clocking speed of device in Hz
> -- ref-clock-frequency : Reference clock frequency
> - interrupt-parent, interrupts :
> Should contain parameters for 1 interrupt line.
> Interrupt parameters: parent, line number, type.
> -- vwlan-supply :Point the node of the regulator that powers/enable
> the wl1271 chip
> +- vwlan-supply :Point the node of the regulator that powers/enable
> the
> +wl12xx/wl18xx chip
>
> Optional properties:
> +- ref-clock-frequency : Reference clock frequency (should be set for wl12xx)
> - clock-xtal : boolean, clock is generated from XTAL
>
> - Please consult Documentation/devicetree/bindings/spi/spi-bus.txt
> @@ -21,10 +32,15 @@ Optional properties:
>
> Examples:
>
> +For wl12xx family:
> &spi1 {
> - wl1271@1 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&spi1_pins>;
> + #address-cells = <1>;
> + #size-cells = <0>;
None of this is really relevant to this binding.
> + wlcore: wlcore@0 {
Now your unit-address and reg value don't match.
> compatible = "ti,wl1271";
> -
> reg = <1>;
> spi-max-frequency = <4800>;
> clock-xtal;
> @@ -34,3 +50,20 @@ Examples:
> vwlan-supply = <&vwlan_fixed>;
> };
> };
> +
> +For wl18xx family:
> +&spi0{
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&spi0_pins>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + wlcore: wlcore@0 {
> + compatible = "ti,wl1835";
> + vwlan-supply = <&wlan_en_reg>;
> + spi-max-frequency = <4800>;
> + reg = <0>;
> + interrupt-parent = <&gpio0>;
> + interrupts = <27 IRQ_TYPE_EDGE_RISING>;
> + };
> +};
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/2] dt: bindings: add MARVELL's sd8xxx wireless device
On Mon, Apr 18, 2016 at 05:22:22AM -0700, Amitkumar Karwar wrote: > From: Xinming Hu > > Add device tree binding documentation for MARVELL's sd8xxx > (sd8897 and sd8997) wlan chip. > > Signed-off-by: Xinming Hu > Signed-off-by: Amitkumar Karwar > --- > Listing changelist for both 1/2 and 2/2 patches > v3: Don't update adapter->dt_node if mwifiex_plt_dev is NULL > > v4: a)Corrected the 'name' and 'compatible' property names.(Arnd Bergmann and > Rob > Herring) > b)Patch description wraped in 72 columns(Rob Herring) > c)Moved DT binding file to bindings/net/wireless/(Rob Herring) > d)Renamed "mwifiex,chip-gpio" to "marvell,wakeup-gpios"(Rob Herring/ > Arnd Bergmann) > e)Replaced #ifdef with __maybe_unused(Arnd Bergmann) > > v5: a)Removed wildcards from compatible string(Arnd Bergmann) > b)Prepared single patch for all binding changes(Rob Herring) > c)Specified our node as a subnode of SDIO controller. With this approach, > we > don't need to register new platform driver. (Rob herring) > > v6: a)List out the specific property names for marvell,caldata* and size of > the data(Rob Herring) > b)Use sdio function number for both the unit address and reg(Rob Herring) > > v7: a)Use suggested specific marvell,caldata property name and generic node > name(Rob Herring) > --- > .../bindings/net/wireless/marvell-sd8xxx.txt | 63 > ++++++ > 1 file changed, 63 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt Acked-by: Rob Herring -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/2] dt: bindings: add MARVELL's sd8xxx wireless device
On Wed, Mar 30, 2016 at 8:19 AM, Amitkumar Karwar wrote:
> From: Xinming Hu
>
> Add device tree binding documentation for MARVELL's sd8xxx
> (sd8897 and sd8997) wlan chip.
>
> Signed-off-by: Xinming Hu
> Signed-off-by: Amitkumar Karwar
> ---
> Listing changelist for both 1/2 and 2/2 patches
> v3: Don't update adapter->dt_node if mwifiex_plt_dev is NULL
>
> v4: a)Corrected the 'name' and 'compatible' property names.(Arnd Bergmann and
> Rob
> Herring)
> b)Patch description wraped in 72 columns(Rob Herring)
> c)Moved DT binding file to bindings/net/wireless/(Rob Herring)
> d)Renamed "mwifiex,chip-gpio" to "marvell,wakeup-gpios"(Rob Herring/
> Arnd Bergmann)
> e)Replaced #ifdef with __maybe_unused(Arnd Bergmann)
>
> v5: a)Removed wildcards from compatible string(Arnd Bergmann)
> b)Prepared single patch for all binding changes(Rob Herring)
> c)Specified our node as a subnode of SDIO controller. With this approach,
> we
> don't need to register new platform driver. (Rob herring)
>
> v6: a)List out the specific property names for marvell,caldata* and size of
> the data(Rob Herring)
> b)Use sdio function number for both the unit address and reg(Rob Herring)
> ---
> .../bindings/net/wireless/marvell-sd8xxx.txt | 63
> ++
> 1 file changed, 63 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>
> diff --git
> a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> new file mode 100644
> index 000..337fed4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> @@ -0,0 +1,63 @@
> +Marvell 8897/8997 (sd8897/sd8997) SDIO devices
> +--
> +
> +This node provides properties for controlling the marvell sdio wireless
> device.
> +The node is expected to be specified as a child node to the SDIO controller
> that
> +connects the device to the system.
> +
> +Required properties:
> +
> + - compatible : should be one of the following:
> + * "marvell,sd8897"
> + * "marvell,sd8997"
> +
> +Optional properties:
> +
> + - marvell,caldata* : A series of properties with marvell,caldata prefix,
> + represent calibration data downloaded to the device
> during
> + initialization. This is an array of unsigned values.
unsigned 8-bit values...
> + the properties should follow below property name and
> + corresponding array length:
> + "marvell,caldata_00_txpwrlimit_2g_cfg_set" (length = 566).
> + "marvell,caldata_00_txpwrlimit_5g_cfg_set_sub0" (length = 502).
> + "marvell,caldata_00_txpwrlimit_5g_cfg_set_sub1" (length = 688).
> + "marvell,caldata_00_txpwrlimit_5g_cfg_set_sub2" (length = 750).
> + "marvell,caldata_00_txpwrlimit_5g_cfg_set_sub3" (length = 502).
The 00 and cfg_set seem pretty pointless, and '-' is preferred over '_'. So:
marvell,caldata-txpwrlimit-5g-sub3
> + - marvell,wakeup-pin : 'wakeuppin' is a wakeup pin number of wifi chip
> which will
Drop "wakeuppin is"
> + be configured to firmware. firmware will wakeup host
> side use
> + the pin during suspend/resume stage.
> + - interrupt-parent: phandle of the parent interrupt controller
> + - interrupts : interrupt pin number to the cpu. driver will request an irq
> based on
> +this interrupt number. during system suspend, the irq will
> be enabled
> +as system wakeup source, so that the wifi chip can wakeup
> host
You need to use the wakeup-source binding here
(bindings/power/wakeup-source.txt). Probably on the BT binding too?
> +platform under certain condition. during system resume, the
> irq will
> +be disabled to make sure unnecessary interrupt is not
> received.
> +
> +Example:
> +
> +Tx power limit calibration data is configured in below example.
> +The calibration data is an array of unsigned values, the length
> +can vary between hw versions.
> +IRQ pin 38 is used as system wakeup source interrupt. wakeup pin 3 is
> configured
> +so that firmware can wakeup host using this device side pin.
> +
> +&mmc3 {
> + status = "okay";
> + vmmc-supply = <&wlan_en_reg>;
> + bus-width = <4>;
> + cap-power-off-card;
> + keep-power-in-suspend;
> +
&
Re: [PATCH v5 1/2] dt: bindings: add MARVELL's sd8xxx wireless device
On Fri, Mar 18, 2016 at 04:03:51AM -0700, Amitkumar Karwar wrote:
> From: Xinming Hu
>
> Add device tree binding documentation for MARVELL's sd8xxx
> (sd8897 and sd8997) wlan chip.
>
> Signed-off-by: Xinming Hu
> Signed-off-by: Amitkumar Karwar
> ---
> Listing changelist for both 1/2 and 2/2 patches
> v3: Don't update adapter->dt_node if mwifiex_plt_dev is NULL
>
> v4: a)Corrected the 'name' and 'compatible' property names.(Arnd Bergmann and
> Rob
> Herring)
> b)Patch description wraped in 72 columns(Rob Herring)
> c)Moved DT binding file to bindings/net/wireless/(Rob Herring)
> d)Renamed "mwifiex,chip-gpio" to "marvell,wakeup-gpios"(Rob Herring/
> Arnd Bergmann)
> e)Replaced #ifdef with __maybe_unused(Arnd Bergmann)
>
> v5: a)Removed wildcards from compatible string(Arnd Bergmann)
> b)Prepared single patch for all binding changes(Rob Herring)
> c)Specified our node as a subnode of SDIO controller. With this approach,
> we
> don't need to register new platform driver. (Rob herring)
> ---
> .../bindings/net/wireless/marvell-sd8xxx.txt | 56
> ++
> 1 file changed, 56 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>
> diff --git
> a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> new file mode 100644
> index 000..c43d488
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> @@ -0,0 +1,56 @@
> +Marvell 8897/8997 (sd8897/sd8997) SDIO devices
> +--
> +
> +This node provides properties for controlling the marvell sdio wireless
> device.
> +The node is expected to be specified as a child node to the SDIO controller
> that
> +connects the device to the system.
> +
> +Required properties:
> +
> + - compatible : should be one of the following:
> + * "marvell,sd8897"
> + * "marvell,sd8997"
> +
> +Optional properties:
> +
> + - marvell,caldata* : A series of properties with marvell,caldata prefix,
> + represent Calibration data downloaded to the device during
> + initialization. This is an array of unsigned values.
You need to list out the specific property names and size of the data.
> + - marvell,wakeup-pin : 'wakeuppin' is a wakeup pin number of wifi chip
> which will
> + be configured to firmware. firmware will wakeup host side
> use
> + the pin during suspend/resume stage.
> + - interrupt-parent: phandle of the parent interrupt controller
> + - interrupts : interrupt pin number to the cpu. driver will request an irq
> based on
> + this interrupt number. during system suspend, the irq will be
> enabled
> + as system wakeup source, so that the wifi chip can wakeup host
> + platform under certain condition. during system resume, the
> irq will
> + be disabled to make sure unnecessary interrupt is not received.
> +
> +Example:
> +
> +Tx power limit calibration data is configured in below example.
> +The calibration data is an array of unsigned values, the length
> +can vary between hw versions.
> +IRQ pin 38 is used as system wakeup source interrupt. wakeup pin 3 is
> configured
> +so that firmware can wakeup host using this device side pin.
> +
> +&mmc3 {
> + status = "okay";
> + vmmc-supply = <&wlan_en_reg>;
> + bus-width = <4>;
> + cap-power-off-card;
> + keep-power-in-suspend;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + mwifiex: mwifiex@3 {
The unit address and reg value don't match. IIRC, the correct value is
the SDIO function number.
> + compatible = "marvell,sd8897";
> + reg = <1>;
> + interrupt-parent = <&pio>;
> + interrupts = <38 IRQ_TYPE_LEVEL_LOW>;
> +
> + marvell,caldata_00_txpwrlimit_2g_cfg_set = /bits/ 8 <
> + 0x01 0x00 0x06 0x00 0x08 0x02 0x89 0x01>;
> + marvell,wakeup-pin = <3>;
> + };
> +};
> --
> 1.8.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dt: bindings: add new dt entry for pre calibration in qcom,ath10k.txt
On Thu, Mar 10, 2016 at 03:42:04PM +0530, Raja Mani wrote:
> There two things done in this patch,
>
> 1) Existing device tree entry 'qcom,ath10k-calibration-data' carries
>not only calibration data, it carries board specific data too.
>So, make appropriate update in doc.
>
> 2) ipq4019 wifi needs new devie tree entry to carry calibration
>data alone (called pre cal data, it doesn't include any other info).
>Using 'qcom,ath10k-calibration-data' for ipq4019 would alter
>the purpose of it. Hence, add new device tree entry called
>'qcom,ath10k-pre-calibration-data' to carry only pre calibration data.
>
> Signed-off-by: Raja Mani
> ---
>
> Below patches covers the corresponding changes in the ath10k driver.
> It's posted separately to ath10k and linux-wireless mailing list.
Generally the series should be posted together. The rest should not be
merged until this patch is accepted.
>
> 1) ath10k: pass cal data location as an argument to
> ath10k_download_cal_{file|dt}
> 2) ath10k: move cal data len to hw_params
> 3) ath10k: incorporate qca4019 cal data download sequence
>
> .../bindings/net/wireless/qcom,ath10k.txt | 23
> +++---
> 1 file changed, 16 insertions(+), 7 deletions(-)
Acked-by: Rob Herring
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] mwifiex: register platform specific driver
On Mon, Feb 08, 2016 at 02:15:26AM -0800, Amitkumar Karwar wrote:
> From: Xinming Hu
>
> Platform device and driver provides easy way to
> interact with device-tree-enabled system.
>
> This patch registers platform driver and reorganise
> existing device tree specific code.
> Corresponding device tree binding file is
> also created.
Wrap you lines at 72 columns.
> Signed-off-by: Xinming Hu
> Signed-off-by: Amitkumar Karwar
> ---
> v3: Don't update adapter->dt_node if mwifiex_plt_dev is NULL
> ---
> Documentation/devicetree/bindings/mwifiex.txt | 29 +++
This doesn't belong at top level of bindings. bindings/net/wireless/
Also, mwifiex is a linux driver name. Name it after the chips.
marvell-sd8xxx?
> drivers/net/wireless/marvell/mwifiex/Makefile | 1 +
> drivers/net/wireless/marvell/mwifiex/main.c| 2 +
> drivers/net/wireless/marvell/mwifiex/main.h| 14 +
> .../net/wireless/marvell/mwifiex/platform_drv.c| 59
> ++
> drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 6 +--
> drivers/net/wireless/marvell/mwifiex/sta_ioctl.c | 2 +-
> 7 files changed, 109 insertions(+), 4 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mwifiex.txt
> create mode 100644 drivers/net/wireless/marvell/mwifiex/platform_drv.c
>
> diff --git a/Documentation/devicetree/bindings/mwifiex.txt
> b/Documentation/devicetree/bindings/mwifiex.txt
> new file mode 100644
> index 000..39b6a74
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mwifiex.txt
> @@ -0,0 +1,29 @@
> +mwifiex
> +--
> +
> +Required properties:
> +
> + - name : must be "mwifiex"
> + - compatible : must be "marvell,mwifiex"
The naming should be named after the actual chip.
> +
> +Optional properties:
> +
> + - mwifiex,caldata* : A series of properties with marvell,caldata prefix,
mwifiex is not a vendor.
> + represent Calibration data downloaded to the device during
> + initialization. This is an array of unsigned values.
> +
> +
> +Example:
> +
> +Tx power limit calibration data is configured in below example.
> +The calibration data is an array of unsigned values, the length
> +can vary between hw versions.
> +
> +mwifiex {
These chips are SDIO devices, right? This should be a child node of the
SDIO controller.
> + compatible = "marvell,mwifiex";
> +
> + mwifiex,caldata_00_txpwrlimit_2g_cfg_set = /bits/ 8 <
> +0x01 0x00 0x06 0x00 0x08 0x02 0x89 0x01 ...>;
> +
> +};
> +
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/3] mwifiex: parse chip specific gpio from device tree
On Mon, Feb 08, 2016 at 01:11:03PM +0100, Arnd Bergmann wrote:
> On Monday 08 February 2016 02:15:27 Amitkumar Karwar wrote:
> > if (adapter->dt_node) {
> > + if (of_property_read_u32(adapter->dt_node,
> > +"mwifiex,chip-gpio",
> > +&data) == 0) {
> > + mwifiex_dbg(adapter, INFO,
> > + "chip_gpio = 0x%x\n", data);
> > + adapter->hs_cfg.gpio = data;
> > + }
> > +
> >
>
> Please use the GPIO DT binding. Reading a number from DT is not a proper
> way to get a GPIO number, as you may have more than one GPIO controller
> in a system and it is not obvious to which controller this number belongs,
> or if you need to specify things like polarity.
My read of this is it is not the host SOC gpio, but the WiFi device's
GPIO number. The host GPIO is defined in patch 3. We could still use the
GPIO binding to describe it doing something like "marvell,-gpios". Then the assignment is based on the property name.
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dt: bindings: add bindings for ipq4019 wifi block
On Wed, Dec 23, 2015 at 11:05:15AM +0530, Raja Mani wrote:
> Add device tree binding documentation details for wifi block present
> in Qualcomm IPQ4019 SoC into qcom,ath10k.txt.
>
> Signed-off-by: Raja Mani
> ---
> .../bindings/net/wireless/qcom,ath10k.txt | 87
> --
> 1 file changed, 82 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> index edefc26..ffd0742 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> @@ -1,17 +1,42 @@
> * Qualcomm Atheros ath10k wireless devices
>
> -For ath10k devices the calibration data can be provided through Device
> -Tree. The node is a child node of the PCI controller.
So it is now not a PCI device?
> -
> Required properties:
> --compatible : Should be "qcom,ath10k"
> +- compatible: Should be one of the following:
> + * "qcom,ath10k"
> + * "qcom,ipq4019-wifi"
One is a standalone PCI device and one is embedded block in an SOC?
These should be more separated as all these new properties would only
apply in the latter case.
>
> Optional properties:
> +- reg: Address and length of the register set for the device.
> +- core-id: Core number associated to the device.
This needs a better explanation.
> +- resets: Must contain an entry for each entry in reset-names.
> + See ../reset/reseti.txt for details.
> +- reset-names: Must include the list of following reset names,
> +"wifi_cpu_init"
> +"wifi_radio_srif"
> +"wifi_radio_warm"
> +"wifi_radio_cold"
> +"wifi_core_warm"
> +"wifi_core_cold"
> +- clocks: List of clock specifiers, must contain an entry for each required
> + entry in clock-names.
> +- clock-names: Should contain the clock names "wifi_wcss_cmd",
> "wifi_wcss_ref",
> + "wifi_wcss_rtc".
> +- interrupts: List of interrupt lines. Must contain an entry
> + for each entry in the interrupt-names property.
> +- interrupt-names: Must include the entries for MSI interrupt
> +names ("msi0" to "msi15") and legacy interrupt
> +name ("legacy"),
> +- qca,msi_addr: MSI interrupt address.
> +- qca,msi_base: Base value to add before writing MSI data into
> + MSI address register.
Why don't the standard MSI properties work?
> - qcom,ath10k-calibration-data : calibration data as an array, the
>length can vary between hw versions
> +- status: Either "disabled" or "ok".
> +
No need to document status here.
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] wlcore/wl12xx: spi: add device tree support
On Wed, Dec 23, 2015 at 10:35:43AM +0200, Uri Mashiach wrote: > Add DT support for the wl1271 SPI WiFi. > > Add documentation file for the wl1271 SPI WiFi. > > Signed-off-by: Uri Mashiach > Acked-by: Igor Grinberg > --- > .../bindings/net/wireless/ti,wlcore,spi.txt| 35 +++ For the binding: Acked-by: Rob Herring -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] dt: binding: Add Qualcomm wcn36xx WiFi binding
On Tue, Dec 29, 2015 at 11:03:57AM -0800, Bjorn Andersson wrote: > On Tue 29 Dec 10:34 PST 2015, Rob Herring wrote: > > > On Sun, Dec 27, 2015 at 05:34:27PM -0800, Bjorn Andersson wrote: > > > Add binding representing the Qualcomm wcn3620/60/80 WiFi block. > > > Signed-off-by: Bjorn Andersson > > > --- > > > .../bindings/net/wireless/qcom,wcn36xx-wifi.txt| 76 > > > ++ > > > 1 file changed, 76 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt > > > > > > diff --git > > > a/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt > > > b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt > > > new file mode 100644 > > > index ..7b314b9f30af > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt > > > @@ -0,0 +1,76 @@ > > > +Qualcomm WCN36xx WiFi Binding > > > + > > > +This binding describes the Qualcomm WCN36xx WiFi hardware. The hardware > > > block > > > +is part of the Qualcomm WCNSS core, a WiFi/BT/FM combo chip, found in a > > > variety > > > +of Qualcomm platforms. > > > > Are BT/FM functions completely separate? If so, separate bindings are > > okay. If not, then we need to describe the full chip. > > > > It's three different hardware blocks (WiFi, BT and FM-radio) with shared > RF-hardware and an ARM core for control logic. > > There seems to be some control commands going towards the BT part that > controls coexistence properties of the RF-hardware, but other than that > I see it as logically separate blocks. > > > So I think it's fine to model this as separate pieces in DT. Okay. Acked-by: Rob Herring -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] dt: binding: Add Qualcomm wcn36xx WiFi binding
On Sun, Dec 27, 2015 at 05:34:27PM -0800, Bjorn Andersson wrote: > Add binding representing the Qualcomm wcn3620/60/80 WiFi block. > Signed-off-by: Bjorn Andersson > --- > .../bindings/net/wireless/qcom,wcn36xx-wifi.txt| 76 > ++ > 1 file changed, 76 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt > > diff --git > a/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt > b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt > new file mode 100644 > index ..7b314b9f30af > --- /dev/null > +++ b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt > @@ -0,0 +1,76 @@ > +Qualcomm WCN36xx WiFi Binding > + > +This binding describes the Qualcomm WCN36xx WiFi hardware. The hardware block > +is part of the Qualcomm WCNSS core, a WiFi/BT/FM combo chip, found in a > variety > +of Qualcomm platforms. Are BT/FM functions completely separate? If so, separate bindings are okay. If not, then we need to describe the full chip. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/3] wlcore/wl12xx: spi: add device tree support
On Mon, Dec 28, 2015 at 02:02:18PM +0200, Uri Mashiach wrote: > Add DT support for the wl1271 SPI WiFi. > > Add documentation file for the wl1271 SPI WiFi. > > Signed-off-by: Uri Mashiach > Acked-by: Igor Grinberg > --- > v1 -> v2: update interrupt documentation. > replace interrupts and interrupt-parent with interrupts-extended. Why? interrupts-extended is really just for cases with 2 interrupt parents. > IRQ parameters retrieved from spi_device instead of DT. > remove redundant #ifdef CONFIG_OF > v2 -> v3: Add MODULE_DEVICE_TABLE. > Remove #ifdef CONFIG_OF. > Make the Kconfig symbol to depend on OF. > Replace irqd_get_trigger_type() with irq_get_trigger_type(). > > .../bindings/net/wireless/ti,wlcore,spi.txt | 34 In any case: Acked-by: Rob Herring > drivers/net/wireless/ti/wlcore/Kconfig | 2 +- > drivers/net/wireless/ti/wlcore/spi.c | 47 > -- > 3 files changed, 78 insertions(+), 5 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
