From: Johannes Berg <johannes@sipsolutions.net>
To: Ajay.Kathat@microchip.com, linux-wireless@vger.kernel.org
Cc: gregkh@linuxfoundation.org, kvalo@codeaurora.org,
Adham.Abozaeid@microchip.com, Venkateswara.Kaja@microchip.com,
Nicolas.Ferre@microchip.com, Claudiu.Beznea@microchip.com
Subject: Re: [PATCH v2 02/16] wilc1000: add wilc_hif.c
Date: Fri, 12 Jul 2019 09:42:34 +0200 [thread overview]
Message-ID: <b6bb8a8b61ebbca40611dee07e4980a792bf2386.camel@sipsolutions.net> (raw)
In-Reply-To: <1562896697-8002-3-git-send-email-ajay.kathat@microchip.com>
> +struct wilc_set_multicast {
> + u32 enabled;
> + u32 cnt;
> + u8 *mc_list;
> +};
> +
> +struct wilc_del_all_sta {
> + u8 assoc_sta;
> + u8 mac[WILC_MAX_NUM_STA][ETH_ALEN];
> +};
> +
> +struct wilc_op_mode {
> + __le32 mode;
> +};
> +
> +struct wilc_reg_frame {
> + bool reg;
> + u8 reg_id;
> + __le16 frame_type;
> +} __packed;
'bool' is a pretty bad idea, there's no storage guarantee for it. Use u8
instead, especially in a firmware struct.
But overall, if I remember correctly, this is a massive improvement,
last time I looked I think you basically had something like
char msg[10];
int i = 0;
msg[i++] = reg;
msg[i++] = reg_id;
msg[i++] = frame_type >> 8;
msg[i++] = (u8)frame_type;
so obviously this is *much* better.
I still think you'd benefit from putting the firmware API structs into a
separate include file so you can differentiate them, but YMMV.
> +int wilc_scan(struct wilc_vif *vif, u8 scan_source, u8 scan_type,
> + u8 *ch_freq_list, u8 ch_list_len,
> + void (*scan_result_fn)(enum scan_event,
> + struct wilc_rcvd_net_info *, void *),
> + void *user_arg, struct cfg80211_scan_request *request)
> +{
> + int result = 0;
> + struct wid wid_list[5];
> + wid_list[index].id = WID_INFO_ELEMENT_PROBE;
> + wid_list[index].type = WID_BIN_DATA;
> + wid_list[index].val = (s8 *)request->ie;
> + wid_list[index].size = request->ie_len;
> + index++;
> +
> + wid_list[index].id = WID_SCAN_TYPE;
> + wid_list[index].type = WID_CHAR;
> + wid_list[index].size = sizeof(char);
> + wid_list[index].val = (s8 *)&scan_type;
> + index++;
I still find this whole wid_list stuff to be a bit confusing, especially
since it looks like a *firmware* thing but then you have the *host
pointer* inside the value ...
There must be a translation layer somewhere, but I can't help but wonder
if that's really worth the complexity, vs. just building the right thing
directly here (with some helpers perhaps).
johannes
next prev parent reply other threads:[~2019-07-12 7:42 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-12 1:58 [PATCH v2 00/16] wilc1000: move out of staging Ajay.Kathat
2019-07-12 1:58 ` [PATCH v2 01/16] wilc1000: add wilc_hif.h Ajay.Kathat
2019-10-23 10:03 ` Kalle Valo
[not found] ` <20191023100312.B1D2760A7E@smtp.codeaurora.org>
2019-10-29 3:06 ` Adham.Abozaeid
2019-07-12 1:58 ` [PATCH v2 02/16] wilc1000: add wilc_hif.c Ajay.Kathat
2019-07-12 7:42 ` Johannes Berg [this message]
2019-07-12 14:52 ` Ajay.Kathat
2019-07-12 1:58 ` [PATCH v2 03/16] wilc1000: add wilc_wlan_if.h Ajay.Kathat
2019-07-12 1:58 ` [PATCH v2 04/16] wilc1000: add wilc_wlan_cfg.h Ajay.Kathat
2019-07-12 1:58 ` [PATCH v2 05/16] wilc1000: add wilc_wlan_cfg.c Ajay.Kathat
2019-07-12 7:31 ` Johannes Berg
2019-07-12 10:58 ` Ajay.Kathat
2019-07-12 1:58 ` [PATCH v2 06/16] wilc1000: add wilc_wfi_netdevice.h Ajay.Kathat
2019-07-12 1:59 ` [PATCH v2 07/16] wilc1000: add wilc_wfi_cfgoperations.h Ajay.Kathat
2019-07-12 1:59 ` [PATCH v2 08/16] wilc1000: add wilc_wfi_cfgoperations.c Ajay.Kathat
2019-07-12 1:59 ` [PATCH v2 09/16] wilc1000: add wilc_netdev.c Ajay.Kathat
2019-07-12 1:59 ` [PATCH v2 10/16] wilc1000: add wilc_mon.c Ajay.Kathat
2019-07-12 1:59 ` [PATCH v2 11/16] wilc1000: add wilc_spi.c Ajay.Kathat
2019-07-12 1:59 ` [PATCH v2 12/16] wilc1000: add wilc_wlan.c Ajay.Kathat
2019-07-12 1:59 ` [PATCH v2 13/16] wilc1000: add wilc_wlan.h Ajay.Kathat
2019-07-12 1:59 ` [PATCH v2 14/16] wilc1000: add wilc_sdio.c Ajay.Kathat
2019-07-12 1:59 ` [PATCH v2 15/16] wilc1000: updated DT device binding for wilc1000 device Ajay.Kathat
2019-07-12 1:59 ` [PATCH v2 16/16] wilc1000: add Makefile and Kconfig files for wilc1000 compilation Ajay.Kathat
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b6bb8a8b61ebbca40611dee07e4980a792bf2386.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=Adham.Abozaeid@microchip.com \
--cc=Ajay.Kathat@microchip.com \
--cc=Claudiu.Beznea@microchip.com \
--cc=Nicolas.Ferre@microchip.com \
--cc=Venkateswara.Kaja@microchip.com \
--cc=gregkh@linuxfoundation.org \
--cc=kvalo@codeaurora.org \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.