* Re: [PATCH 07/23] wfx: add bus_sdio.c [not found] ` <2628294.9EgBEFZmRI@pc-42> @ 2020-10-14 12:43 ` Pali Rohár 2020-10-15 14:03 ` Jérôme Pouiller 0 siblings, 1 reply; 4+ messages in thread From: Pali Rohár @ 2020-10-14 12:43 UTC (permalink / raw) To: Jérôme Pouiller, Ulf Hansson Cc: linux-wireless, netdev, devel, linux-kernel, Greg Kroah-Hartman, Kalle Valo, David S . Miller, devicetree, Rob Herring, linux-mmc On Wednesday 14 October 2020 13:52:15 Jérôme Pouiller wrote: > Hello Pali, > > On Tuesday 13 October 2020 22:11:56 CEST Pali Rohár wrote: > > Hello! > > > > On Monday 12 October 2020 12:46:32 Jerome Pouiller wrote: > > > +#define SDIO_VENDOR_ID_SILABS 0x0000 > > > +#define SDIO_DEVICE_ID_SILABS_WF200 0x1000 > > > +static const struct sdio_device_id wfx_sdio_ids[] = { > > > + { SDIO_DEVICE(SDIO_VENDOR_ID_SILABS, SDIO_DEVICE_ID_SILABS_WF200) }, > > > > Please move ids into common include file include/linux/mmc/sdio_ids.h > > where are all SDIO ids. Now all drivers have ids defined in that file. > > > > > + // FIXME: ignore VID/PID and only rely on device tree > > > + // { SDIO_DEVICE(SDIO_ANY_ID, SDIO_ANY_ID) }, > > > > What is the reason for ignoring vendor and device ids? > > The device has a particularity, its VID/PID is 0000:1000 (as you can see > above). This value is weird. The risk of collision with another device is > high. Those ids looks strange. You are from Silabs, can you check internally in Silabs if ids are really correct? And which sdio vendor id you in Silabs got assigned for your products? I know that sdio devices with multiple functions may have different sdio vendor/device id particular function and in common CIS (function 0). Could not be a problem that on one place is vendor/device id correct and on other place is that strange value? I have sent following patch (now part of upstream kernel) which exports these ids to userspace: https://lore.kernel.org/linux-mmc/20200527110858.17504-2-pali@kernel.org/T/#u Also for debugging ids and information about sdio cards, I sent another patch which export additional data: https://lore.kernel.org/linux-mmc/20200727133837.19086-1-pali@kernel.org/T/#u Could you try them and look at /sys/class/mmc_host/ attribute outputs? > So, maybe the device should be probed only if it appears in the DT. Since > WF200 targets embedded platforms, I don't think it is a problem to rely on > DT. You will find another FIXME further in the code about that: > > + dev_warn(&func->dev, > + "device is not declared in DT, features will be limited\n"); > + // FIXME: ignore VID/PID and only rely on device tree > + // return -ENODEV; > > However, it wouldn't be usual way to manage SDIO devices (and it is the > reason why the code is commented out). > > Anyway, if we choose to rely on the DT, should we also check the VID/PID? > > Personally, I am in favor to probe the device only if VID/PID match and if > a DT node is found, even if it is not the usual way. Normally all sdio devices are hotplugged in linux kernel based on sdio device and vendor ids. And these ids are unique identifiers of sdio devices. So should be enough for detection. Months ago I have checked it and moved all SDIO device and vendor ids into common include/linux/mmc/sdio_ids.h file. I would like to not have this "mess" again, which was basically fully cleaned. I'm adding linux-mmc mailing list and Ulf Hansson to loop. Ulf, can you look at this "problem"? What do you think about those "strange" sdio ids? ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH 07/23] wfx: add bus_sdio.c 2020-10-14 12:43 ` [PATCH 07/23] wfx: add bus_sdio.c Pali Rohár @ 2020-10-15 14:03 ` Jérôme Pouiller 2020-10-16 11:54 ` Ulf Hansson 0 siblings, 1 reply; 4+ messages in thread From: Jérôme Pouiller @ 2020-10-15 14:03 UTC (permalink / raw) To: Ulf Hansson, Pali Rohár Cc: linux-wireless, netdev, devel, linux-kernel, Greg Kroah-Hartman, Kalle Valo, David S . Miller, devicetree, Rob Herring, linux-mmc On Wednesday 14 October 2020 14:43:34 CEST Pali Rohár wrote: > On Wednesday 14 October 2020 13:52:15 Jérôme Pouiller wrote: > > On Tuesday 13 October 2020 22:11:56 CEST Pali Rohár wrote: > > > On Monday 12 October 2020 12:46:32 Jerome Pouiller wrote: > > > > +#define SDIO_VENDOR_ID_SILABS 0x0000 > > > > +#define SDIO_DEVICE_ID_SILABS_WF200 0x1000 > > > > +static const struct sdio_device_id wfx_sdio_ids[] = { > > > > + { SDIO_DEVICE(SDIO_VENDOR_ID_SILABS, SDIO_DEVICE_ID_SILABS_WF200) }, > > > > > > Please move ids into common include file include/linux/mmc/sdio_ids.h > > > where are all SDIO ids. Now all drivers have ids defined in that file. > > > > > > > + // FIXME: ignore VID/PID and only rely on device tree > > > > + // { SDIO_DEVICE(SDIO_ANY_ID, SDIO_ANY_ID) }, > > > > > > What is the reason for ignoring vendor and device ids? > > > > The device has a particularity, its VID/PID is 0000:1000 (as you can see > > above). This value is weird. The risk of collision with another device is > > high. > > Those ids looks strange. You are from Silabs, can you check internally > in Silabs if ids are really correct? And which sdio vendor id you in > Silabs got assigned for your products? I confirm these ids are the ones burned in the WF200. We have to deal with that :( . > I know that sdio devices with multiple functions may have different sdio > vendor/device id particular function and in common CIS (function 0). > > Could not be a problem that on one place is vendor/device id correct and > on other place is that strange value? > > I have sent following patch (now part of upstream kernel) which exports > these ids to userspace: > https://lore.kernel.org/linux-mmc/20200527110858.17504-2-pali@kernel.org/T/#u > > Also for debugging ids and information about sdio cards, I sent another > patch which export additional data: > https://lore.kernel.org/linux-mmc/20200727133837.19086-1-pali@kernel.org/T/#u > > Could you try them and look at /sys/class/mmc_host/ attribute outputs? Here is: # cd /sys/class/mmc_host/ && grep -r . mmc1/ mmc1/power/runtime_suspended_time:0 grep: mmc1/power/autosuspend_delay_ms: Input/output error mmc1/power/runtime_active_time:0 mmc1/power/control:auto mmc1/power/runtime_status:unsupported mmc1/mmc1:0001/vendor:0x0000 mmc1/mmc1:0001/rca:0x0001 mmc1/mmc1:0001/device:0x1000 mmc1/mmc1:0001/mmc1:0001:1/vendor:0x0000 mmc1/mmc1:0001/mmc1:0001:1/device:0x1000 grep: mmc1/mmc1:0001/mmc1:0001:1/info4: No data available mmc1/mmc1:0001/mmc1:0001:1/power/runtime_suspended_time:0 grep: mmc1/mmc1:0001/mmc1:0001:1/power/autosuspend_delay_ms: Input/output error mmc1/mmc1:0001/mmc1:0001:1/power/runtime_active_time:0 mmc1/mmc1:0001/mmc1:0001:1/power/control:auto mmc1/mmc1:0001/mmc1:0001:1/power/runtime_status:unsupported mmc1/mmc1:0001/mmc1:0001:1/class:0x00 grep: mmc1/mmc1:0001/mmc1:0001:1/info2: No data available mmc1/mmc1:0001/mmc1:0001:1/modalias:sdio:c00v0000d1000 mmc1/mmc1:0001/mmc1:0001:1/revision:0.0 mmc1/mmc1:0001/mmc1:0001:1/uevent:OF_NAME=mmc mmc1/mmc1:0001/mmc1:0001:1/uevent:OF_FULLNAME=/soc/sdhci@7e300000/mmc@1 mmc1/mmc1:0001/mmc1:0001:1/uevent:OF_COMPATIBLE_0=silabs,wfx-sdio mmc1/mmc1:0001/mmc1:0001:1/uevent:OF_COMPATIBLE_N=1 mmc1/mmc1:0001/mmc1:0001:1/uevent:SDIO_CLASS=00 mmc1/mmc1:0001/mmc1:0001:1/uevent:SDIO_ID=0000:1000 mmc1/mmc1:0001/mmc1:0001:1/uevent:SDIO_REVISION=0.0 mmc1/mmc1:0001/mmc1:0001:1/uevent:MODALIAS=sdio:c00v0000d1000 grep: mmc1/mmc1:0001/mmc1:0001:1/info3: No data available grep: mmc1/mmc1:0001/mmc1:0001:1/info1: No data available mmc1/mmc1:0001/ocr:0x00200000 grep: mmc1/mmc1:0001/info4: No data available mmc1/mmc1:0001/power/runtime_suspended_time:0 grep: mmc1/mmc1:0001/power/autosuspend_delay_ms: Input/output error mmc1/mmc1:0001/power/runtime_active_time:0 mmc1/mmc1:0001/power/control:auto mmc1/mmc1:0001/power/runtime_status:unsupported grep: mmc1/mmc1:0001/info2: No data available mmc1/mmc1:0001/type:SDIO mmc1/mmc1:0001/revision:0.0 mmc1/mmc1:0001/uevent:MMC_TYPE=SDIO mmc1/mmc1:0001/uevent:SDIO_ID=0000:1000 mmc1/mmc1:0001/uevent:SDIO_REVISION=0.0 grep: mmc1/mmc1:0001/info3: No data available grep: mmc1/mmc1:0001/info1: No data available -- Jérôme Pouiller ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH 07/23] wfx: add bus_sdio.c 2020-10-15 14:03 ` Jérôme Pouiller @ 2020-10-16 11:54 ` Ulf Hansson 2020-11-02 16:02 ` Kalle Valo 0 siblings, 1 reply; 4+ messages in thread From: Ulf Hansson @ 2020-10-16 11:54 UTC (permalink / raw) To: Jérôme Pouiller Cc: Pali Rohár, linux-wireless, netdev, driverdevel, Linux Kernel Mailing List, Greg Kroah-Hartman, Kalle Valo, David S . Miller, DTML, Rob Herring, linux-mmc@vger.kernel.org On Thu, 15 Oct 2020 at 16:03, Jérôme Pouiller <jerome.pouiller@silabs.com> wrote: > > On Wednesday 14 October 2020 14:43:34 CEST Pali Rohár wrote: > > On Wednesday 14 October 2020 13:52:15 Jérôme Pouiller wrote: > > > On Tuesday 13 October 2020 22:11:56 CEST Pali Rohár wrote: > > > > On Monday 12 October 2020 12:46:32 Jerome Pouiller wrote: > > > > > +#define SDIO_VENDOR_ID_SILABS 0x0000 > > > > > +#define SDIO_DEVICE_ID_SILABS_WF200 0x1000 > > > > > +static const struct sdio_device_id wfx_sdio_ids[] = { > > > > > + { SDIO_DEVICE(SDIO_VENDOR_ID_SILABS, SDIO_DEVICE_ID_SILABS_WF200) }, > > > > > > > > Please move ids into common include file include/linux/mmc/sdio_ids.h > > > > where are all SDIO ids. Now all drivers have ids defined in that file. > > > > > > > > > + // FIXME: ignore VID/PID and only rely on device tree > > > > > + // { SDIO_DEVICE(SDIO_ANY_ID, SDIO_ANY_ID) }, > > > > > > > > What is the reason for ignoring vendor and device ids? > > > > > > The device has a particularity, its VID/PID is 0000:1000 (as you can see > > > above). This value is weird. The risk of collision with another device is > > > high. > > > > Those ids looks strange. You are from Silabs, can you check internally > > in Silabs if ids are really correct? And which sdio vendor id you in > > Silabs got assigned for your products? > > I confirm these ids are the ones burned in the WF200. We have to deal with > that :( . Yep. Unfortunately this isn't so uncommon when targeting the embedded types of devices. The good thing is, that we already have bindings allowing us to specify this. > > > > I know that sdio devices with multiple functions may have different sdio > > vendor/device id particular function and in common CIS (function 0). > > > > Could not be a problem that on one place is vendor/device id correct and > > on other place is that strange value? > > > > I have sent following patch (now part of upstream kernel) which exports > > these ids to userspace: > > https://lore.kernel.org/linux-mmc/20200527110858.17504-2-pali@kernel.org/T/#u > > > > Also for debugging ids and information about sdio cards, I sent another > > patch which export additional data: > > https://lore.kernel.org/linux-mmc/20200727133837.19086-1-pali@kernel.org/T/#u > > > > Could you try them and look at /sys/class/mmc_host/ attribute outputs? > > Here is: > > # cd /sys/class/mmc_host/ && grep -r . mmc1/ > mmc1/power/runtime_suspended_time:0 > grep: mmc1/power/autosuspend_delay_ms: Input/output error > mmc1/power/runtime_active_time:0 > mmc1/power/control:auto > mmc1/power/runtime_status:unsupported > mmc1/mmc1:0001/vendor:0x0000 > mmc1/mmc1:0001/rca:0x0001 > mmc1/mmc1:0001/device:0x1000 > mmc1/mmc1:0001/mmc1:0001:1/vendor:0x0000 > mmc1/mmc1:0001/mmc1:0001:1/device:0x1000 > grep: mmc1/mmc1:0001/mmc1:0001:1/info4: No data available > mmc1/mmc1:0001/mmc1:0001:1/power/runtime_suspended_time:0 > grep: mmc1/mmc1:0001/mmc1:0001:1/power/autosuspend_delay_ms: Input/output error > mmc1/mmc1:0001/mmc1:0001:1/power/runtime_active_time:0 > mmc1/mmc1:0001/mmc1:0001:1/power/control:auto > mmc1/mmc1:0001/mmc1:0001:1/power/runtime_status:unsupported > mmc1/mmc1:0001/mmc1:0001:1/class:0x00 > grep: mmc1/mmc1:0001/mmc1:0001:1/info2: No data available > mmc1/mmc1:0001/mmc1:0001:1/modalias:sdio:c00v0000d1000 > mmc1/mmc1:0001/mmc1:0001:1/revision:0.0 > mmc1/mmc1:0001/mmc1:0001:1/uevent:OF_NAME=mmc > mmc1/mmc1:0001/mmc1:0001:1/uevent:OF_FULLNAME=/soc/sdhci@7e300000/mmc@1 > mmc1/mmc1:0001/mmc1:0001:1/uevent:OF_COMPATIBLE_0=silabs,wfx-sdio > mmc1/mmc1:0001/mmc1:0001:1/uevent:OF_COMPATIBLE_N=1 > mmc1/mmc1:0001/mmc1:0001:1/uevent:SDIO_CLASS=00 > mmc1/mmc1:0001/mmc1:0001:1/uevent:SDIO_ID=0000:1000 > mmc1/mmc1:0001/mmc1:0001:1/uevent:SDIO_REVISION=0.0 > mmc1/mmc1:0001/mmc1:0001:1/uevent:MODALIAS=sdio:c00v0000d1000 > grep: mmc1/mmc1:0001/mmc1:0001:1/info3: No data available > grep: mmc1/mmc1:0001/mmc1:0001:1/info1: No data available > mmc1/mmc1:0001/ocr:0x00200000 > grep: mmc1/mmc1:0001/info4: No data available > mmc1/mmc1:0001/power/runtime_suspended_time:0 > grep: mmc1/mmc1:0001/power/autosuspend_delay_ms: Input/output error > mmc1/mmc1:0001/power/runtime_active_time:0 > mmc1/mmc1:0001/power/control:auto > mmc1/mmc1:0001/power/runtime_status:unsupported > grep: mmc1/mmc1:0001/info2: No data available > mmc1/mmc1:0001/type:SDIO > mmc1/mmc1:0001/revision:0.0 > mmc1/mmc1:0001/uevent:MMC_TYPE=SDIO > mmc1/mmc1:0001/uevent:SDIO_ID=0000:1000 > mmc1/mmc1:0001/uevent:SDIO_REVISION=0.0 > grep: mmc1/mmc1:0001/info3: No data available > grep: mmc1/mmc1:0001/info1: No data available > > Please have a look at the Documentation/devicetree/bindings/mmc/mmc-controller.yaml, there you find that from a child node of the mmc host's node, we can specify an embedded SDIO functional device. In sdio_add_func(), which calls sdio_set_of_node() - we assign the func->dev.of_node its corresponding child node for the SDIO func. Allowing the sdio functional driver to be matched with the SDIO func device. Perhaps what is missing, is that we may want to avoid probing an in-correct sdio driver, based upon buggy SDIO ids. I don't think we take some actions in the mmc core to prevent this, but maybe it's not a big problem anyway. When it comes to documenting the buggy SDIO ids, please add some information about this in the common SDIO headers. It's nice to have a that information, if any issue comes up later on. Kind regards Uffe ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH 07/23] wfx: add bus_sdio.c 2020-10-16 11:54 ` Ulf Hansson @ 2020-11-02 16:02 ` Kalle Valo 0 siblings, 0 replies; 4+ messages in thread From: Kalle Valo @ 2020-11-02 16:02 UTC (permalink / raw) To: Ulf Hansson Cc: Jérôme Pouiller, Pali Rohár, linux-wireless, netdev, driverdevel, Linux Kernel Mailing List, Greg Kroah-Hartman, David S . Miller, DTML, Rob Herring, linux-mmc@vger.kernel.org Ulf Hansson <ulf.hansson@linaro.org> writes: > On Thu, 15 Oct 2020 at 16:03, Jérôme Pouiller > <jerome.pouiller@silabs.com> wrote: >> >> On Wednesday 14 October 2020 14:43:34 CEST Pali Rohár wrote: >> > On Wednesday 14 October 2020 13:52:15 Jérôme Pouiller wrote: >> > > On Tuesday 13 October 2020 22:11:56 CEST Pali Rohár wrote: >> > > > On Monday 12 October 2020 12:46:32 Jerome Pouiller wrote: >> > > > > +#define SDIO_VENDOR_ID_SILABS 0x0000 >> > > > > +#define SDIO_DEVICE_ID_SILABS_WF200 0x1000 >> > > > > +static const struct sdio_device_id wfx_sdio_ids[] = { >> > > > > + { SDIO_DEVICE(SDIO_VENDOR_ID_SILABS, SDIO_DEVICE_ID_SILABS_WF200) }, >> > > > >> > > > Please move ids into common include file include/linux/mmc/sdio_ids.h >> > > > where are all SDIO ids. Now all drivers have ids defined in that file. >> > > > >> > > > > + // FIXME: ignore VID/PID and only rely on device tree >> > > > > + // { SDIO_DEVICE(SDIO_ANY_ID, SDIO_ANY_ID) }, >> > > > >> > > > What is the reason for ignoring vendor and device ids? >> > > >> > > The device has a particularity, its VID/PID is 0000:1000 (as you can see >> > > above). This value is weird. The risk of collision with another device is >> > > high. >> > >> > Those ids looks strange. You are from Silabs, can you check internally >> > in Silabs if ids are really correct? And which sdio vendor id you in >> > Silabs got assigned for your products? >> >> I confirm these ids are the ones burned in the WF200. We have to deal with >> that :( . > > Yep. Unfortunately this isn't so uncommon when targeting the embedded > types of devices. > > The good thing is, that we already have bindings allowing us to specify this. > >> >> >> > I know that sdio devices with multiple functions may have different sdio >> > vendor/device id particular function and in common CIS (function 0). >> > >> > Could not be a problem that on one place is vendor/device id correct and >> > on other place is that strange value? >> > >> > I have sent following patch (now part of upstream kernel) which exports >> > these ids to userspace: >> > https://lore.kernel.org/linux-mmc/20200527110858.17504-2-pali@kernel.org/T/#u >> > >> > Also for debugging ids and information about sdio cards, I sent another >> > patch which export additional data: >> > https://lore.kernel.org/linux-mmc/20200727133837.19086-1-pali@kernel.org/T/#u >> > >> > Could you try them and look at /sys/class/mmc_host/ attribute outputs? >> >> Here is: >> >> # cd /sys/class/mmc_host/ && grep -r . mmc1/ >> mmc1/power/runtime_suspended_time:0 >> grep: mmc1/power/autosuspend_delay_ms: Input/output error >> mmc1/power/runtime_active_time:0 >> mmc1/power/control:auto >> mmc1/power/runtime_status:unsupported >> mmc1/mmc1:0001/vendor:0x0000 >> mmc1/mmc1:0001/rca:0x0001 >> mmc1/mmc1:0001/device:0x1000 >> mmc1/mmc1:0001/mmc1:0001:1/vendor:0x0000 >> mmc1/mmc1:0001/mmc1:0001:1/device:0x1000 >> grep: mmc1/mmc1:0001/mmc1:0001:1/info4: No data available >> mmc1/mmc1:0001/mmc1:0001:1/power/runtime_suspended_time:0 >> grep: mmc1/mmc1:0001/mmc1:0001:1/power/autosuspend_delay_ms: Input/output error >> mmc1/mmc1:0001/mmc1:0001:1/power/runtime_active_time:0 >> mmc1/mmc1:0001/mmc1:0001:1/power/control:auto >> mmc1/mmc1:0001/mmc1:0001:1/power/runtime_status:unsupported >> mmc1/mmc1:0001/mmc1:0001:1/class:0x00 >> grep: mmc1/mmc1:0001/mmc1:0001:1/info2: No data available >> mmc1/mmc1:0001/mmc1:0001:1/modalias:sdio:c00v0000d1000 >> mmc1/mmc1:0001/mmc1:0001:1/revision:0.0 >> mmc1/mmc1:0001/mmc1:0001:1/uevent:OF_NAME=mmc >> mmc1/mmc1:0001/mmc1:0001:1/uevent:OF_FULLNAME=/soc/sdhci@7e300000/mmc@1 >> mmc1/mmc1:0001/mmc1:0001:1/uevent:OF_COMPATIBLE_0=silabs,wfx-sdio >> mmc1/mmc1:0001/mmc1:0001:1/uevent:OF_COMPATIBLE_N=1 >> mmc1/mmc1:0001/mmc1:0001:1/uevent:SDIO_CLASS=00 >> mmc1/mmc1:0001/mmc1:0001:1/uevent:SDIO_ID=0000:1000 >> mmc1/mmc1:0001/mmc1:0001:1/uevent:SDIO_REVISION=0.0 >> mmc1/mmc1:0001/mmc1:0001:1/uevent:MODALIAS=sdio:c00v0000d1000 >> grep: mmc1/mmc1:0001/mmc1:0001:1/info3: No data available >> grep: mmc1/mmc1:0001/mmc1:0001:1/info1: No data available >> mmc1/mmc1:0001/ocr:0x00200000 >> grep: mmc1/mmc1:0001/info4: No data available >> mmc1/mmc1:0001/power/runtime_suspended_time:0 >> grep: mmc1/mmc1:0001/power/autosuspend_delay_ms: Input/output error >> mmc1/mmc1:0001/power/runtime_active_time:0 >> mmc1/mmc1:0001/power/control:auto >> mmc1/mmc1:0001/power/runtime_status:unsupported >> grep: mmc1/mmc1:0001/info2: No data available >> mmc1/mmc1:0001/type:SDIO >> mmc1/mmc1:0001/revision:0.0 >> mmc1/mmc1:0001/uevent:MMC_TYPE=SDIO >> mmc1/mmc1:0001/uevent:SDIO_ID=0000:1000 >> mmc1/mmc1:0001/uevent:SDIO_REVISION=0.0 >> grep: mmc1/mmc1:0001/info3: No data available >> grep: mmc1/mmc1:0001/info1: No data available >> >> > > Please have a look at the > Documentation/devicetree/bindings/mmc/mmc-controller.yaml, there you > find that from a child node of the mmc host's node, we can specify an > embedded SDIO functional device. > > In sdio_add_func(), which calls sdio_set_of_node() - we assign the > func->dev.of_node its corresponding child node for the SDIO func. > Allowing the sdio functional driver to be matched with the SDIO func > device. > > Perhaps what is missing, is that we may want to avoid probing an > in-correct sdio driver, based upon buggy SDIO ids. I don't think we > take some actions in the mmc core to prevent this, but maybe it's not > a big problem anyway. > > When it comes to documenting the buggy SDIO ids, please add some > information about this in the common SDIO headers. It's nice to have a > that information, if any issue comes up later on. And if there's some special setup (DT etc) needed to get the wireless driver working that should be documented in the driver side as well. The expectation is that an upstream driver is just plug and play, and if it's not there should be clear documentation how to enable the driver. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-11-02 16:03 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20201012104648.985256-1-Jerome.Pouiller@silabs.com>
[not found] ` <20201012104648.985256-8-Jerome.Pouiller@silabs.com>
[not found] ` <20201013201156.g27gynu5bhvaubul@pali>
[not found] ` <2628294.9EgBEFZmRI@pc-42>
2020-10-14 12:43 ` [PATCH 07/23] wfx: add bus_sdio.c Pali Rohár
2020-10-15 14:03 ` Jérôme Pouiller
2020-10-16 11:54 ` Ulf Hansson
2020-11-02 16:02 ` Kalle Valo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).