Re: [PATCH] staging: rtl8723bs: Add 024c:0627 to the list of SDIO device-ids
On 10/29/2020 2:52 PM, Brian O'Keefe wrote:
Add 024c:0627 to the list of SDIO device-ids, based on hardware found in
the wild. This hardware exists on at least some Acer SW1-011 tablets.
Signed-off-by: Brian O'Keefe
---
drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
index 5b1392deb0a7..7256d55fcc1b 100644
--- a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
+++ b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
@@ -21,6 +21,7 @@ static const struct sdio_device_id sdio_ids[] =
{ SDIO_DEVICE(0x024c, 0x0525), },
{ SDIO_DEVICE(0x024c, 0x0623), },
{ SDIO_DEVICE(0x024c, 0x0626), },
+ { SDIO_DEVICE(0x024c, 0x0627), },
{ SDIO_DEVICE(0x024c, 0xb723), },
shouldn't these be listed in include/linux/mmc/sdio_ids.h ?
Regards,
Arend
smime.p7s
Description: S/MIME Cryptographic Signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/20] Add support for Silicon Labs WiFi chip WF200 and further
On 9/19/2019 1:25 PM, Greg Kroah-Hartman wrote: - I also kept compatibility code for earlier Linux kernel version. I may drop it in future. Maybe I will maintain compatibility with older kernels in a external set of patches. That has to be dropped for the in-kernel version. There is no need to maintain such compatibility. You basically get it for free with the linux-backports project [1]. Regards, Arend [1] https://backports.wiki.kernel.org/index.php/Main_Page ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: use exact allocation for dma coherent memory
On 7/1/2019 10:48 AM, Christoph Hellwig wrote: On Fri, Jun 14, 2019 at 03:47:10PM +0200, Christoph Hellwig wrote: Switching to a slightly cleaned up alloc_pages_exact is pretty easy, but it turns out that because we didn't filter valid gfp_t flags on the DMA allocator, a bunch of drivers were passing __GFP_COMP to it, which is rather bogus in too many ways to explain. Arm has been filtering it for a while, but this series instead tries to fix the drivers and warn when __GFP_COMP is passed, which makes it much larger than just adding the functionality. Dear driver maintainers, can you look over the patches touching your drivers, please? I'd like to get as much as possible of the driver patches into this merge window, so that it can you through your maintainer trees. You made me look ;-) Actually not touching my drivers so I'm off the hook. However, I was wondering if drivers could know so I decided to look into the DMA-API.txt documentation which currently states: """ The flag parameter (dma_alloc_coherent() only) allows the caller to specify the ``GFP_`` flags (see kmalloc()) for the allocation (the implementation may choose to ignore flags that affect the location of the returned memory, like GFP_DMA). """ I do expect you are going to change that description as well now that you are going to issue a warning on __GFP_COMP. Maybe include that in patch 15/16 where you introduce that warning. Regards, Arend ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: feedback on mainlining wilc1000 staging driver
On 8/17/2018 9:49 AM, Kalle Valo wrote: Ajay Singh writes: On Thu, 16 Aug 2018 13:53:50 +0300 Kalle Valo wrote: Kalle Valo writes: Ajay Singh writes: Hi Greg, We all are working on submitting and reviewing patches for wilc1000 in staging driver for quite some time. We would like to have feedback on the next steps to bring wilc1000 driver closer to move into the wireless subsystem tree. In summary, the following major things from TODO have been addressed in staging: -remove the defined feature as kernel versions -remove OS wrapper functions -remove custom debug and tracing functions -rework comments and function headers(also coding style) -remove build warnings -replace all semaphores with mutexes or completions -make spi and sdio components coexist in one build -turn compile-time platform configuration (BEAGLE_BOARD, PANDA_BOARD, PLAT_WMS8304, PLAT_RK, CUSTOMER_PLATFORM, ...) into run-time options that are read from DT -replace SIOCDEVPRIVATE commands with generic API functions -use wext-core handling instead of private SIOCSIWPRIV implementation From wireless point of view: if I see wext mentioned anywhere in the driver I stop right there. cfg80211 is a hard requirement for us nowadays. Clarification: Depending on the hardware design either cfg80211 or mac80211 is a hard requirement. I haven't checked wilc1000 at all so I don't know what design it has but if it's a "softmac" design then it has to use mac80211, we do not want to support multiple 802.11 UMAC stacks. The TODO item to make use of wext-core is obsolete. Previously wilc1000 driver also had few wext ioctl use but now it’s completely removed and cfg80211 operation callbacks are used. wilc1000 driver make use of cfg80211 and isn’t a "softmac". Good. We need help to review and identify if there are any pending items for wilc1000 driver, so we can address those issues and make it ready to move to the wireless subsystem. I think the best way to get that forward is to submit a patch (or patchset) to linux-wireless, that's the easiest for reviewers. For brcm80211 drivers we used a single patch introducing it under the wireless drivers folder. Because it was quite a sizable patch we parked it on the wireless wiki page. Had a few iterations doing it like that. Regards, Arend ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/5] staging: wilc1000: fixes for undefined reference to `__this_module' error
On 8/14/2018 12:56 PM, Dan Carpenter wrote: On Sun, Aug 12, 2018 at 05:48:52PM +0530, Ajay Singh wrote: Yes, currently only code to read and writing for "wilc_debug_level" exists. The main purpose for this file was to configure(enable/disable) specific level debug logs to print. The kernel's dev_dbg() macros are really very clever. You can enable them for one file or for a specific line or for a function. Provided you have CONFIG_DYNAMIC_DEBUG selected. Gr. AvS ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: wilc1000: New cfg packet format in handle_set_wfi_drv_handler
On 10-4-2017 7:01, Aditya Shankar wrote:
> Change the config packet format used in handle_set_wfi_drv_handler()
> to align the host driver with the new format used in the wilc firmware.
>
> The change updates the format in which the host driver provides the
> firmware with the drv_handler index and also uses two new
> fields viz. "mode" and 'name" in the config packet along with this index
> to directly provide details about the interface and its mode to the
> firmware instead of having multiple if-else statements in the host driver
> to decide which interface to configure.
changelog should move after Signed-off-by tag separated by '---' so it
does not end up in the commit message.
> Change in v2:
> Fixed build warning
>
> Signed-off-by: Aditya Shankar
> ---
so put changelog here.
---
> drivers/staging/wilc1000/host_interface.c | 54
> +++
> drivers/staging/wilc1000/host_interface.h | 9 +++-
> drivers/staging/wilc1000/linux_wlan.c | 29 +++-
> drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 2 +-
> drivers/staging/wilc1000/wilc_wlan_if.h | 2 +-
> 5 files changed, 59 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/staging/wilc1000/host_interface.c
> b/drivers/staging/wilc1000/host_interface.c
> index c3a8af0..ad1e625 100644
> --- a/drivers/staging/wilc1000/host_interface.c
> +++ b/drivers/staging/wilc1000/host_interface.c
> @@ -198,6 +198,7 @@ struct host_if_msg {
> union message_body body;
> struct wilc_vif *vif;
> struct work_struct work;
> + void *drv_handler;
> };
>
> struct join_bss_param {
> @@ -334,14 +335,42 @@ static void handle_set_wfi_drv_handler(struct wilc_vif
> *vif,
> {
> int ret = 0;
> struct wid wid;
> + u8 *currbyte;
> + struct host_if_drv *hif_drv = NULL;
> + int driver_handler_id = 0;
> + u8 *buffer = kzalloc(DRV_HANDLER_SIZE, GFP_ATOMIC);
I would only use constant initializers. So declare buffer and do
kzalloc() later. Also be prepared to deal with kzalloc() returning a
NULL pointer upon allocation failure.
> + if (!vif->hif_drv)
> + return;
> +
> + if (!hif_drv_handler)
> + return;
> +
> + hif_drv = vif->hif_drv;
> +
> + if (hif_drv)
This if statement is bogus as you already checked vif->hif_drv earlier.
> + driver_handler_id = hif_drv->driver_handler_id;
> + else
> + driver_handler_id = 0;
> +
> + currbyte = buffer;
> + *currbyte = driver_handler_id & DRV_HANDLER_MASK;
This will crash with null-deref if kzalloc() fails.
> + currbyte++;
> + *currbyte = (u32)0 & DRV_HANDLER_MASK;
> + currbyte++;
> + *currbyte = (u32)0 & DRV_HANDLER_MASK;
> + currbyte++;
> + *currbyte = (u32)0 & DRV_HANDLER_MASK;
> + currbyte++;
> + *currbyte = (hif_drv_handler->name | (hif_drv_handler->mode << 1));
>
> wid.id = (u16)WID_SET_DRV_HANDLER;
> wid.type = WID_STR;
> - wid.val = (s8 *)hif_drv_handler;
> - wid.size = sizeof(*hif_drv_handler);
> + wid.val = (s8 *)buffer;
> + wid.size = DRV_HANDLER_SIZE;
>
> ret = wilc_send_config_pkt(vif, SET_CFG, &wid, 1,
> -hif_drv_handler->handler);
> +driver_handler_id);
>
> if (!hif_drv_handler->handler)
> complete(&hif_driver_comp);
[...]
> @@ -3099,7 +3128,8 @@ int wilc_set_mac_chnl_num(struct wilc_vif *vif, u8
> channel)
> return 0;
> }
>
> -int wilc_set_wfi_drv_handler(struct wilc_vif *vif, int index, u8 mac_idx)
> +int wilc_set_wfi_drv_handler(struct wilc_vif *vif, int index, u8 mode, char
> + *ifname)
> {
> int result = 0;
> struct host_if_msg msg;
> @@ -3107,9 +3137,14 @@ int wilc_set_wfi_drv_handler(struct wilc_vif *vif, int
> index, u8 mac_idx)
> memset(&msg, 0, sizeof(struct host_if_msg));
> msg.id = HOST_IF_MSG_SET_WFIDRV_HANDLER;
> msg.body.drv.handler = index;
> - msg.body.drv.mac_idx = mac_idx;
> + msg.body.drv.mode = mode;
> msg.vif = vif;
>
> + if (!memcmp(ifname, "wlan0", 5))
> + msg.body.drv.name = 1;
> + else if (!memcmp(ifname, "p2p0", 4))
> + msg.body.drv.name = 0;
> +
You really can not compare netdev names like that. User-space, eg.
udevd, determines the names. So you should find another way to map the
netdev to that name value. You could store the name value in the
structure you have in netdev_priv.
> result = wilc_enqueue_cmd(&msg);
> if (result) {
> netdev_err(vif->ndev, "wilc mq send fail\n");
> @@ -3330,6 +3365,7 @@ int wilc_init(struct net_device *dev, struct
> host_if_drv **hif_drv_handler)
> for (i = 0; i < wilc->vif_num; i++)
> if (dev == wilc->vif[i]->ndev) {
> wilc->vif[i]->hif_drv = hif_drv;
> + hif_drv->driver_handler_id = i + 1;
> br
Re: [PATCH RFC] remove custom Michael MIC implementation
On 3-4-2017 23:39, Tobin C. Harding wrote: > On Mon, Apr 03, 2017 at 12:15:15PM +0200, Arend Van Spriel wrote: >> seems we are missing out again? > > Sorry, I don't understand what this comment means? My bad. I had to reset my email account in thunderbird and now it needs to learn anew what is spam and what is not. So I missed out on the conversation as some messages (a lot actually) ended up in my spam folder. >> On 3-4-2017 11:50, Toke Høiland-Jørgensen wrote: >>> "Tobin C. Harding" writes: >>> >>>> Except one: do you know off the top of your head of a canonical >>>> implementation of a softmac wi-fi driver. >>> >>> I'll suggest taking a look at the ath9k driver :) >> >> Looking at ks7010 driver it looks like it has 802.11 stack in firmware >> and not sure if Renesas is actively supporting this effort to come up >> with mac80211-friendly firmware or provide detailed chip info. > > Thanks for taking a look. If the ks7010 driver has 802.11 stack in > firmware does that mean it is not compatible with using the kernel > mac80211 stack with the current firmware? I do not have my hopes up > about getting any chip information out of Renesas, all I think we have > to go in is the current WEXT driver. Indeed. That is my gut feeling as well and if that is truly the case your best option would be a cfg80211-based driver like ath6kl, mwifiex, and brcmfmac. > This is an exercise in learning for me, but I do not want to take any > ones time up with a project that is not that useful. Is getting the > ks7010 driver out of staging something that is of use to the kernel > community or are there other wi-fi tasks that our time is better spent > on? If there are linux users with this hardware than sure. Especially if it revised to interface with the latest wireless subsystem so tools like iw can operate on it. Also I suppose it is preferred if a driver is maintained. I do not see the ks7010 listed in the MAINTAINERS file yet. > thanks, > Tobin. > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC] remove custom Michael MIC implementation
seems we are missing out again? On 3-4-2017 11:50, Toke Høiland-Jørgensen wrote: > "Tobin C. Harding" writes: > >> Except one: do you know off the top of your head of a canonical >> implementation of a softmac wi-fi driver. > > I'll suggest taking a look at the ath9k driver :) Looking at ks7010 driver it looks like it has 802.11 stack in firmware and not sure if Renesas is actively supporting this effort to come up with mac80211-friendly firmware or provide detailed chip info. Regards, Arend ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: wilc1000: renames struct tstrRSSI and its members u8Index, u8Full
On 22-2-2017 18:14, Tahia Khan wrote:
> Fixes multiple camel case checks on struct tstrRSSI from checkpatch.pl:
>
> Avoid CamelCase:
> Avoid CamelCase:
> Avoid CamelCase:
Just a generic remark that may help you with other changes you will be
making in the linux kernel. Warnings from checkpatch.pl and other tools
are useful, but try to look further than just fixing a warning.
Understand what the code is doing is just as important.
> Signed-off-by: Tahia Khan
> ---
> drivers/staging/wilc1000/coreconfigurator.h | 8
> drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 10 +-
> 2 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/staging/wilc1000/coreconfigurator.h
> b/drivers/staging/wilc1000/coreconfigurator.h
> index cff1698..5b65c4f 100644
> --- a/drivers/staging/wilc1000/coreconfigurator.h
> +++ b/drivers/staging/wilc1000/coreconfigurator.h
> @@ -70,9 +70,9 @@ enum connect_status {
> CONNECT_STS_FORCE_16_BIT = 0x
> };
>
> -struct tstrRSSI {
> - u8 u8Full;
> - u8 u8Index;
> +struct tstr_RSSI {
> + u8 full;
> + u8 index;
> s8 as8RSSI[NUM_RSSI];
So you have a struct here with three members and you choose to only
change the first two. What do you think about the third one just by
looking at it. And what about the name of the struct. What does 'tstr' mean?
> };
>
> @@ -93,7 +93,7 @@ struct network_info {
> u8 *ies;
> u16 ies_len;
> void *join_params;
> - struct tstrRSSI str_rssi;
> + struct tstr_RSSI str_rssi;
> u64 tsf_hi;
> };
>
> diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> index f7ce47c..56f133e 100644
> --- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> +++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> @@ -205,8 +205,8 @@ static u32 get_rssi_avg(struct network_info *network_info)
> {
> u8 i;
> int rssi_v = 0;
> - u8 num_rssi = (network_info->str_rssi.u8Full) ?
> -NUM_RSSI : (network_info->str_rssi.u8Index);
> + u8 num_rssi = (network_info->str_rssi.full) ?
> +NUM_RSSI : (network_info->str_rssi.index);
so struct tstr_RSSI is really a rssi history buffer so maybe naming it
as such makes it clearer, ie. struct rssi_history_buffer.
> for (i = 0; i < num_rssi; i++)
> rssi_v += network_info->str_rssi.as8RSSI[i];
> @@ -346,13 +346,13 @@ static void add_network_to_shadow(struct network_info
> *pstrNetworkInfo,
> } else {
> ap_index = ap_found;
> }
> - rssi_index = last_scanned_shadow[ap_index].str_rssi.u8Index;
> + rssi_index = last_scanned_shadow[ap_index].str_rssi.index;
> last_scanned_shadow[ap_index].str_rssi.as8RSSI[rssi_index++] =
> pstrNetworkInfo->rssi;
> if (rssi_index == NUM_RSSI) {
> rssi_index = 0;
> - last_scanned_shadow[ap_index].str_rssi.u8Full = 1;
> + last_scanned_shadow[ap_index].str_rssi.full = 1;
So the 'full' member is actually a bool and you might type it as such.
Hope this helps.
Regards,
Arend
> }
> - last_scanned_shadow[ap_index].str_rssi.u8Index = rssi_index;
> + last_scanned_shadow[ap_index].str_rssi.index = rssi_index;
> last_scanned_shadow[ap_index].rssi = pstrNetworkInfo->rssi;
> last_scanned_shadow[ap_index].cap_info = pstrNetworkInfo->cap_info;
> last_scanned_shadow[ap_index].ssid_len = pstrNetworkInfo->ssid_len;
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wilc1000: remove unnecessary local array
On 10-2-2017 16:06, Franck Demathieu wrote:
> It fixes the following warning reported by sparse:
>
> drivers/staging/wilc1000/linux_wlan.c:67:33: warning: too long
> initializer-string for array of char(no space for nul char)
As this was already submitted this should probably say [PATCH V2] in the
subject.
> Signed-off-by: Franck Demathieu
> ---
And put a change log here, ie.:
V2:
- add de...@driverdev.osuosl.org
---
> drivers/staging/wilc1000/linux_wlan.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/staging/wilc1000/linux_wlan.c
> b/drivers/staging/wilc1000/linux_wlan.c
> index 2eebc62..fc61f4e 100644
> --- a/drivers/staging/wilc1000/linux_wlan.c
> +++ b/drivers/staging/wilc1000/linux_wlan.c
> @@ -64,7 +64,6 @@ static int dev_state_ev_handler(struct notifier_block *this,
> u8 *ip_addr_buf;
> struct wilc_vif *vif;
> u8 null_ip[4] = {0};
> - char wlan_dev_name[5] = "wlan0";
You could have changed it to 'const char dev_name[] = "wlan0";'.
> if (!dev_iface || !dev_iface->ifa_dev || !dev_iface->ifa_dev->dev)
> return NOTIFY_DONE;
> @@ -113,7 +112,7 @@ static int dev_state_ev_handler(struct notifier_block
> *this,
> wilc_optaining_ip = false;
> }
>
> - if (memcmp(dev_iface->ifa_label, wlan_dev_name, 5) == 0)
> + if (memcmp(dev_iface->ifa_label, "wlan0", 5) == 0)
First of all. Why using a memcmp here? dev_iface->ifa_label could be
shorter. Also using the value '5' here is tricky. So it would be better
to say:
if (strlen(dev_iface->ifa_label) == strlen(dev_name) &&
memcmp(dev_iface->ifa_label,
dev_name, strlen(dev_name)) == 0)
> wilc_set_power_mgmt(vif, 0, 0);
However, it does not make sense at all to compare with wlan0 in the
first place. The net_device is registered in wilc_netdev_init() with
"wlan%d" as it should so there is no guarantee it is wlan0.
Regards,
Arend
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 8/8] Makefile: drop -D__CHECK_ENDIAN__ from cflags
On 15-12-2016 6:15, Michael S. Tsirkin wrote: > That's the default now, no need for makefiles to set it. > > Signed-off-by: Michael S. Tsirkin > --- > drivers/bluetooth/Makefile| 2 -- > drivers/net/can/Makefile | 1 - > drivers/net/ethernet/altera/Makefile | 1 - > drivers/net/ethernet/atheros/alx/Makefile | 1 - > drivers/net/ethernet/freescale/Makefile | 2 -- > drivers/net/wireless/ath/Makefile | 2 -- > drivers/net/wireless/ath/wil6210/Makefile | 2 -- > drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile | 2 -- > drivers/net/wireless/broadcom/brcm80211/brcmsmac/Makefile | 1 - For brcm80211 drivers: Acked-by: Arend van Spriel Regards, Arend ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
