[linux-sunxi] Re: [PATCH 27/54] dt-bindings: net: wireless: Convert ESP ESP8089 binding to a schema
Maxime Ripard wrote: > The ESP8089 Wireless Chip is supported by Linux (through an out-of-tree > driver) thanks to its device tree binding. > > Now that we have the DT validation in place, let's convert the device > tree bindings for that driver over to a YAML schema. > > Cc: "David S. Miller" > Cc: de Goede > Cc: Jakub Kicinski > Cc: Kalle Valo > Cc: linux-wirel...@vger.kernel.org > Cc: net...@vger.kernel.org > Signed-off-by: Maxime Ripard > Reviewed-by: Rob Herring We support out-of-tree drivers in DT? Via which tree is this supposed to go? I guess not via wireless-drivers-next as this is an out-of-tree driver. -- https://patchwork.kernel.org/project/linux-wireless/patch/20210721140424.725744-28-max...@cerno.tech/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20210806084710.BD0BEC4338A%40smtp.codeaurora.org.
[linux-sunxi] Re: [PATCH 11/12] brcmfmac: Loading the correct firmware for brcm43456
meg...@megous.com wrote: > From: Ondrej Jirman > > SDIO based brcm43456 is currently misdetected as brcm43455 and the wrong > firmware name is used. Correct the detection and load the correct > firmware file. Chiprev for brcm43456 is "9". > > Signed-off-by: Ondrej Jirman Patch applied to wireless-drivers-next.git, thanks. e3062e05e1cf brcmfmac: Loading the correct firmware for brcm43456 -- https://patchwork.kernel.org/patch/10888023/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v3 1/2] dt-bindings: add device tree binding for Allwinner XR819 SDIO Wi-Fi
icen...@aosc.io writes: >>>>> > > Like I asked already last time, AFAICS there is no upstream xr819 >>>>> > > wireless driver in drivers/net/wireless directory. Do we still >>>> accept >>>>> > > bindings like this for out-of-tree drivers? >>>>> > >>>>> > See esp8089. >>>>> > >>>>> > There's also no in-tree driver for it. >>>>> >>>>> The question is whether we should. The above might be a precedent, >>>> but it >>>>> may not necessarily be the way to go. The commit message for esp8089 >>>> seems >>>>> to hint that there is intent to have an in-tree driver: >>>>> >>>>> """ >>>>> Note that at this point there only is an out of tree driver for >>>> this >>>>> hardware, there is no clear timeline / path for merging this. >>>> Still >>>>> I believe it would be good to specify the binding for this in >>>> tree >>>>> now, so that any future migration to an in tree driver will not >>>> cause >>>>> compatiblity issues. >>>>> >>>>> Cc: Icenowy Zheng <icen...@aosc.xyz> >>>>> Signed-off-by: Hans de Goede <hdego...@redhat.com> >>>>> Signed-off-by: Rob Herring <r...@kernel.org> >>>>> """ >>>>> >>>>> Regardless the bindings are in principle independent of the kernel >>>> and just >>>>> describing hardware. I think there have been discussions to move the >>>>> bindings to their own repository, but apparently it was decided >>>> otherwise. >>>> >>>> Yeah, I guess especially how it could be merged with the cw1200 >>>> driver >>>> would be very relevant to that commit log. >>> >>> The cw1200 driver seems to still have some legacy platform >>> data. Maybe they should also be convert to DT. >>> (Or maybe compatible = "allwinner,xr819" is enough, as >>> xr819 is a specified variant of cw1200 family) >> >> Ah, so the upstream cw1200 driver supports xr819? Has anyone tested >> that? Or does cw1200 more changes than just adding the DT support? > > The support of XR819 in CW1200 driver is far more difficult than I > imagined -- the codedrop used in the mainlined CW1200 driver seems to > be so old that it's before XR819 (which seems to be based on CW1160), > and there's a large number of problems to adapt it to a modern CW1200 > variant. > > P.S. could you apply this device tree binding patch now? As I haven't seen any consensus that applying bindings document for out-of-tree drivers is ok so at least I'm not taking this. Though not sure what DT maintainers are planning to do. -- Kalle Valo -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v3 1/2] dt-bindings: add device tree binding for Allwinner XR819 SDIO Wi-Fi
Icenowy Zheng <icen...@aosc.io> writes: > 于 2017年10月4日 GMT+08:00 下午6:11:45, Maxime Ripard > <maxime.rip...@free-electrons.com> 写到: >>On Wed, Oct 04, 2017 at 10:02:48AM +, Arend van Spriel wrote: >>> On 10/4/2017 11:03 AM, Icenowy Zheng wrote: >>> > >>> > >>> > 于 2017年10月4日 GMT+08:00 下午5:02:17, Kalle Valo <kv...@codeaurora.org> >>写到: >>> > > Icenowy Zheng <icen...@aosc.io> writes: >>> > > >>> > > > 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 <icen...@aosc.io> >>> > > > Acked-by: Rob Herring <r...@kernel.org> >>> > > > --- >>> > > > Changes in v3: >>> > > > - Renames the node name. >>> > > > - Adds ACK from Rob. >>> > > > Changes in v2: >>> > > > - Removed status property in example. >>> > > > - Added required property reg. >>> > > > >>> > > > .../bindings/net/wireless/allwinner,xr819.txt | 38 >>> > > ++ >>> > > > 1 file changed, 38 insertions(+) >>> > > > create mode 100644 >>> > > >>Documentation/devicetree/bindings/net/wireless/allwinner,xr819.txt >>> > > >>> > > Like I asked already last time, AFAICS there is no upstream xr819 >>> > > wireless driver in drivers/net/wireless directory. Do we still >>accept >>> > > bindings like this for out-of-tree drivers? >>> > >>> > See esp8089. >>> > >>> > There's also no in-tree driver for it. >>> >>> The question is whether we should. The above might be a precedent, >>but it >>> may not necessarily be the way to go. The commit message for esp8089 >>seems >>> to hint that there is intent to have an in-tree driver: >>> >>> """ >>> Note that at this point there only is an out of tree driver for >>this >>> hardware, there is no clear timeline / path for merging this. >>Still >>> I believe it would be good to specify the binding for this in >>tree >>> now, so that any future migration to an in tree driver will not >>cause >>> compatiblity issues. >>> >>> Cc: Icenowy Zheng <icen...@aosc.xyz> >>> Signed-off-by: Hans de Goede <hdego...@redhat.com> >>> Signed-off-by: Rob Herring <r...@kernel.org> >>> """ >>> >>> Regardless the bindings are in principle independent of the kernel >>and just >>> describing hardware. I think there have been discussions to move the >>> bindings to their own repository, but apparently it was decided >>otherwise. >> >>Yeah, I guess especially how it could be merged with the cw1200 driver >>would be very relevant to that commit log. > > The cw1200 driver seems to still have some legacy platform > data. Maybe they should also be convert to DT. > (Or maybe compatible = "allwinner,xr819" is enough, as > xr819 is a specified variant of cw1200 family) Ah, so the upstream cw1200 driver supports xr819? Has anyone tested that? Or does cw1200 more changes than just adding the DT support? -- Kalle Valo -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v3 1/2] dt-bindings: add device tree binding for Allwinner XR819 SDIO Wi-Fi
Icenowy Zheng <icen...@aosc.io> writes: > 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 <icen...@aosc.io> > Acked-by: Rob Herring <r...@kernel.org> > --- > Changes in v3: > - Renames the node name. > - Adds ACK from Rob. > Changes in v2: > - Removed status property in example. > - Added required property reg. > > .../bindings/net/wireless/allwinner,xr819.txt | 38 > ++ > 1 file changed, 38 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/net/wireless/allwinner,xr819.txt Like I asked already last time, AFAICS there is no upstream xr819 wireless driver in drivers/net/wireless directory. Do we still accept bindings like this for out-of-tree drivers? -- Kalle Valo -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] dt-bindings: add device tree binding for Allwinner XR819 SDIO Wi-Fi
Icenowy Zheng <icen...@aosc.io> writes: > 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 <icen...@aosc.io> > --- > .../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". > + > +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. Where is the driver which uses this? I don't see it in drivers/net/wireless but I guess that's not a blocker for the bindings? -- Kalle Valo -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property
Jonas Gorski <jonas.gor...@gmail.com> writes:
> Hi,
>
> On 30 June 2016 at 21:23, Arend Van Spriel <arend.vanspr...@broadcom.com>
> wrote:
>>
>>
>> On 30-6-2016 13:31, Arnd Bergmann wrote:
>>> On Thursday, June 30, 2016 12:25:15 PM CEST Hans de Goede wrote:
>>>>> So then how about making use of a more specific compatible string?
>>>>>
>>>>> e.g.
>>>>>
>>>>> brcmf {
>>>>> compatible = "foo,ap6210", "brcm,bcm4329-fmac";
>>>>> ...
>>>>> };
>>>>>
>>>>> and if the compatible has more than one element you request
>>>>> FW_NAME_.txt as the nvram file. Or try each comptible (and
>>>>> lastly no suffix) until you get a match. (AFAICT, this is what the
>>>>> "model" property was originally intended for anyway, but almost nobody
>>>>> did it right, and everyone put a user readable string into "model" for
>>>>> boards instead of the ePAPR defined compatible string).
>>>>
>>>> Hmm, interesting idea. Not sure how easy / hard it will be to implement
>>>> this, but from a dt binding point of view it seems elegant.
>>>>
>>>> Kalle, Arend, what do you think of this ?
>>
>> At first glance I like the suggestion, but this would mean updating the
>> bindings document for each new wifi module that we want to add. Not a
>> big problem, but it makes that I have a slight preference to using a
>> property for it, eg. brcm,module = "ap6210";
>
> If you want a separate property, then I repeat my very first
> suggestion, the well defined model property.
> e.g.
>
> brcmf@0 {
> model = "ampak,ap6210";
> compatible = "brcm,bcm4329-fmac";
> ...
> };
>
> All device nodes may have a model property, not just the top "machine" one.
I like this model property but I'm no DT expert. What others think about
it, would it work?
--
Kalle Valo
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property
Hans de Goede <hdego...@redhat.com> writes: > Hi, > > On 30-06-16 11:02, Kalle Valo wrote: >> Priit Laes <pl...@plaes.org> writes: >> >>>> What is the size of this nvram file? As it's board specific, I wonder >>>> if we can simply include it inside of the DT verbatim. I remember >>>> doing that (in the pre-dtb days, on real open firmware) for the >>>> "spidernet" >>>> ethernet driver. >>> >>> It contains a bit too much info: >>> >>> This is what CubieTruck requires: >>> >>> http://dl.cubieboard.org/public/Cubieboard/benn/firmware/ap6210/nvram_ap6210.txt >> >> In the nvram file I see lots of identifiers: >> >> manfid=0x2d0 >> prodid=0x492 >> vendid=0x14e4 >> devid=0x4343 >> boardtype=0x0598 >> boardrev=0x1307 >> boardnum=777 >> >> Are any of these (or a combination of them) unique for each board type? >> What if one of these is provided through DT and then the driver could >> choose the nvram file based on the board id? Just another idea... > > That would require updating a table in the driver every time a new > board comes out, I do not believe that that is a good solution. You don't necessarily need to have a table in the driver if you embed the id to the filename, for example something like this: nvram-0598-1307.txt nvram--.txt -- Kalle Valo -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property
Priit Laes <pl...@plaes.org> writes: >> What is the size of this nvram file? As it's board specific, I wonder >> if we can simply include it inside of the DT verbatim. I remember >> doing that (in the pre-dtb days, on real open firmware) for the >> "spidernet" >> ethernet driver. > > It contains a bit too much info: > > This is what CubieTruck requires: > > http://dl.cubieboard.org/public/Cubieboard/benn/firmware/ap6210/nvram_ap6210.txt In the nvram file I see lots of identifiers: manfid=0x2d0 prodid=0x492 vendid=0x14e4 devid=0x4343 boardtype=0x0598 boardrev=0x1307 boardnum=777 Are any of these (or a combination of them) unique for each board type? What if one of these is provided through DT and then the driver could choose the nvram file based on the board id? Just another idea... -- Kalle Valo -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property
Arend Van Spriel <arend.vanspr...@broadcom.com> writes: >>> Typical wifi devices will have some sort of non volatile storage >>> on board to not only store the ethernet(mac) address, but also >>> to contain e.g. info about the antenna gain so that the firmware >>> and/or the driver can take the antenna gain into account and ensure >>> that they never exceed the maximum allowed broadcast strength. >>> >>> However on some embedded devices there is no non-volatile storage >>> for the wifi (for cost reasons) and instead this configuration info >>> (which is board / pcb specific) is loaded in the form of a >>> file which contains the contents which would normally be in the >>> non-volatile storage. >>> >>> Since we are dealing with a per-board config-file here, which is >>> loaded from the os filesystem we really need to specify a basename >>> here as the list of possible boards is endless, so we cannot >>> have a lookup table in the driver. > > As a note: For BT Marcel was playing with the idea of having a lookup > table on the file system which would be loaded by the driver. In ath10k we have a similar problem but in our case we can use the subsystem id to detect what board file to use, so it's not exactly same as yours. In our board-2.bin we have identifiers like this from which ath10k selects the correct board file: bus=pci,vendor=168c,device=003e,subsystem-vendor=168c,subsystem-device=334e bus=pci,vendor=168c,device=003e,subsystem-vendor=168c,subsystem-device=3360 bus=pci,vendor=168c,device=003e,subsystem-vendor=168c,subsystem-device=3361 -- Kalle Valo -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property
Arend Van Spriel <arend.vanspr...@broadcom.com> writes: >> Since we are dealing with a per-board config-file here, which is >> loaded from the os filesystem we really need to specify a basename >> here as the list of possible boards is endless, so we cannot >> have a lookup table in the driver. > > As Jonas mentioned the general principle of device tree is to be > agnostic with regards to OS and/or driver as you undoubtedly know. His > proposal seems like a usable solution for your problem while complying > to the device tree principle. So instead of overriding the default > brcmfmac should modify it when dt specifies the "module" property, ie: > > no "module" in DT:nvram filename = brcm/brcmfmac43362-sdio.txt > "module=ap6210" in DT:nvram filename = brcm/brcmfmac43362-ap6210.txt Just out of curiosity, what does "ap6210" exactly mean? I get that 43362 is the chip id, but not ap6210. Is it just an arbitrary name? -- Kalle Valo -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 2/4] ARM: dts: sun7i-a20-cubietruck: Set brcm,nvram_file_name
Hans de Goede <hdego...@redhat.com> writes: > The cubietruck uses an ap6210 sdio wifi module, set brcm,nvram_file_name > to brcmfmac43362-ap6210.txt so that we can ship the ap6210 specific > nvram file in linunx-firmware to get the wifi to work out of the box > without users needing to download and install the nvram file themselves. > > Note a downside of this patch is that users who have already manually > installed the nvram file will need to rename it. > > Signed-off-by: Hans de Goede <hdego...@redhat.com> > --- > arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 1 + > 1 file changed, 1 insertion(+) I can't apply .dts changes so better to send them in a separate patchset. -- Kalle Valo -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property
Hans de Goede <hdego...@redhat.com> writes: > Hi, > > On 29-06-16 16:42, Jonas Gorski wrote: >> Hi, >> >> On 29 June 2016 at 16:04, Hans de Goede <hdego...@redhat.com> 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. >> >> Directly defining a filename doesn't seem like a good OS-agnostic >> approach. Maybe an alternative would be to add a model-property to the >> nodes (this is allowed) and make brcmfmac to request >> "FWFILENAME-" as firmware if set? That would leave it to the OS >> on how the filename is set. > > It only defines the base-filename, not the entire path, how / where > this file is searched for / loaded-from is then left up to the os It's still a bad idea. The filename, including the path, should be created in the driver. Can't you provide chipname (or similar) via device tree and then the driver can choose what image to use? Can you tell more about the naming the firmware image, how does it work exactly? -- Kalle Valo -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
