From: "Nemanov, Michael" <michael.nemanov@ti.com>
To: Krzysztof Kozlowski <krzk@kernel.org>,
Kalle Valo <kvalo@kernel.org>,
Johannes Berg <johannes.berg@intel.com>,
Breno Leitao <leitao@debian.org>,
Justin Stitt <justinstitt@google.com>,
Kees Cook <keescook@chromium.org>,
<linux-wireless@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Cc: Sabeeh Khan <sabeeh-khan@ti.com>
Subject: Re: [PATCH 08/17] Add main.c
Date: Thu, 30 May 2024 14:54:26 +0300 [thread overview]
Message-ID: <456c8076-1e3a-4cc9-895c-e707e68fe610@ti.com> (raw)
In-Reply-To: <cfe33bf1-9df3-4d02-b4ed-e29a430b106d@kernel.org>
On 5/22/2024 12:46 PM, Krzysztof Kozlowski wrote:
> ... > +} > + > +static int read_version_info(struct cc33xx *cc) > +{ >
> + int ret; > + > + cc33xx_info("Wireless driver version %s",
> DRV_VERSION); Drop > + > + ret = cc33xx_acx_init_get_fw_versions(cc);
> > + if (ret < 0) { > + cc33xx_error("Get FW version FAILED!"); > +
> return ret; > + } > + > + cc33xx_info("Wireless firmware version
> %u.%u.%u.%u", > + cc->all_versions.fw_ver->major_version, > +
> cc->all_versions.fw_ver->minor_version, > +
> cc->all_versions.fw_ver->api_version, > +
> cc->all_versions.fw_ver->build_version); > + > + cc33xx_info("Wireless
> PHY version %u.%u.%u.%u.%u.%u", > +
> cc->all_versions.fw_ver->phy_version[5], > +
> cc->all_versions.fw_ver->phy_version[4], > +
> cc->all_versions.fw_ver->phy_version[3], > +
> cc->all_versions.fw_ver->phy_version[2], > +
> cc->all_versions.fw_ver->phy_version[1], > +
> cc->all_versions.fw_ver->phy_version[0]); > + > +
> cc->all_versions.driver_ver = DRV_VERSION; Drop
You mean drop the trace? Will exposing FW/PHY versions via debugfs be OK?
> > +} > + > +static int cc33xx_remove(struct platform_device *pdev) Why
> remove callback is before probe? Please follow standard driver
> convention. This goes immediately after probe.
Will fix
[...]
> > +{ > + struct cc33xx_platdev_data *pdev_data =
> dev_get_platdata(&pdev->dev); > + struct cc33xx *cc =
> platform_get_drvdata(pdev); > + > +
> set_bit(CC33XX_FLAG_DRIVER_REMOVED, &cc->flags); ?!?! Your code is
> seriously buggy if you depend on setting bit in remove callback.
If removal of the CC33xx driver was caused by the removal of its parent
SDIO device then all I/O operations will fail as SDIO transport is no
longer available. This will eventually trigger the recovery mechanism
which in this case is futile. If this flag is set, no recovery is attempted.
[...]
> > + return -EINVAL; > + } > + > + hw =
> cc33xx_alloc_hw(CC33XX_AGGR_BUFFER_SIZE); > + if (IS_ERR(hw)) { > +
> cc33xx_error("can't allocate hw"); Heh? Since when do we print memory
> allocation failures? Since when memory allocation returns ERR ptr?
Will fix
> > +}; > +MODULE_DEVICE_TABLE(platform, cc33xx_id_table); > + > +static
> struct platform_driver cc33xx_driver = { > + .probe = cc33xx_probe, >
> + .remove = cc33xx_remove, > + .id_table = cc33xx_id_table, > +
> .driver = { > + .name = "cc33xx_driver", > + } > +}; > + > +u32
> cc33xx_debug_level = DEBUG_NO_DATAPATH; Why this is global? Why u32?
> Why global variable is defined at the end of the file?!?!
cc33xx_debug_level together with cc33xx_debug/info/error() macros is how
all traces were done in drivers/net/wireless/ti/wlcore/ (originally was
wl1271_debug/info etc.) It enables / disables traces without rebuilding
or even reloading which is very helpful for remote support. These macros
map to dynamic_pr_debug / pr_debug. I saw similar wrappers in other
wireless drivers (ath12k). This is also why there are plenty of
cc33xx_debug() all over the code, most are silent by default.
> > +
> > +module_platform_driver(cc33xx_driver);
> > +
> > +module_param_named(debug_level, cc33xx_debug_level, uint, 0600);
> > +MODULE_PARM_DESC(debug_level, "cc33xx debugging level");
> > +
> > +MODULE_PARM_DESC(secure_boot_enable, "Enables secure boot and FW downlaod");
>
> Eh? why secure boot is module param?
>
> > +
> > +module_param_named(fwlog, fwlog_param, charp, 0);
> > +MODULE_PARM_DESC(fwlog, "FW logger options: continuous, dbgpins or disable");
> > +
> > +module_param(no_recovery, int, 0600);
> > +MODULE_PARM_DESC(no_recovery, "Prevent HW recovery. FW will remain stuck.");
> > +
> > +module_param_named(ht_mode, ht_mode_param, charp, 0400);
> > +MODULE_PARM_DESC(ht_mode, "Force HT mode: wide or siso20");
>
> Does not look like suitable for module params.
Was useful during development but can be removed
> > +
> > +MODULE_LICENSE("GPL v2");
> > +MODULE_DESCRIPTION("Texas Instruments CC33xx WLAN driver");
> > +MODULE_AUTHOR("Michael Nemanov <michael.nemanov@ti.com>");
> > +MODULE_AUTHOR("Sabeeh Khan <sabeeh-khan@ti.com>");
> > +
> > +MODULE_VERSION(DRV_VERSION);
>
> Drop.
I saw other drivers use this, is it no longer allowed?
Michael.
next prev parent reply other threads:[~2024-05-30 11:54 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-21 17:18 [PATCH 00/17] wifi: cc33xx: Add driver for new TI CC33xx wireless device family michael.nemanov
2024-05-21 17:18 ` [PATCH 01/17] Add cc33xx.h, cc33xx_i.h michael.nemanov
2024-05-22 9:38 ` Krzysztof Kozlowski
2024-05-22 15:44 ` Nemanov, Michael
2024-08-06 16:56 ` Nemanov, Michael
2024-05-21 17:18 ` [PATCH 02/17] Add debug.h michael.nemanov
2024-05-21 17:18 ` [PATCH 03/17] Add sdio.c, io.c, io.h michael.nemanov
2024-05-21 17:18 ` [PATCH 04/17] Add cmd.c, cmd.h michael.nemanov
2024-05-21 17:18 ` [PATCH 05/17] Add acx.c, acx.h michael.nemanov
2024-05-21 17:18 ` [PATCH 06/17] Add event.c, event.h michael.nemanov
2024-05-21 17:18 ` [PATCH 07/17] Add boot.c, boot.h michael.nemanov
2024-05-22 8:54 ` Breno Leitao
2024-05-22 11:12 ` Krzysztof Kozlowski
2024-05-22 15:15 ` [EXTERNAL] " Nemanov, Michael
2024-05-21 17:18 ` [PATCH 08/17] Add main.c michael.nemanov
2024-05-22 8:52 ` Breno Leitao
2024-05-22 9:46 ` Krzysztof Kozlowski
2024-05-30 11:54 ` Nemanov, Michael [this message]
2024-05-30 14:37 ` Kalle Valo
2024-05-31 7:35 ` Krzysztof Kozlowski
2024-05-31 13:50 ` Nemanov, Michael
2024-06-05 9:55 ` Nemanov, Michael
2024-06-05 10:04 ` Krzysztof Kozlowski
2024-06-05 11:13 ` Kalle Valo
2024-05-21 17:18 ` [PATCH 09/17] Add rx.c, rx.h michael.nemanov
2024-05-22 8:55 ` Breno Leitao
2024-05-26 6:03 ` Nemanov, Michael
2024-05-21 17:18 ` [PATCH 10/17] Add tx.c, tx.h michael.nemanov
2024-05-21 17:18 ` [PATCH 11/17] Add init.c, init.h michael.nemanov
2024-05-21 17:18 ` [PATCH 12/17] Add scan.c, scan.h michael.nemanov
2024-05-21 17:18 ` [PATCH 13/17] Add conf.h michael.nemanov
2024-05-22 9:48 ` Krzysztof Kozlowski
2024-05-23 7:08 ` Kalle Valo
2024-05-23 7:13 ` Krzysztof Kozlowski
2024-05-23 7:18 ` Kalle Valo
2024-05-24 7:48 ` Nemanov, Michael
2024-05-21 17:18 ` [PATCH 14/17] Add ps.c, ps.h michael.nemanov
2024-05-21 17:18 ` [PATCH 15/17] Add testmode.c, testmode.h michael.nemanov
2024-05-21 17:18 ` [PATCH 16/17] Add Kconfig, Makefile and integrate into wireless/ti folder michael.nemanov
2024-05-21 17:18 ` [PATCH 17/17] Add ti,cc33xx.yaml michael.nemanov
2024-05-22 9:35 ` Krzysztof Kozlowski
2024-05-26 6:35 ` Nemanov, Michael
2024-05-23 7:15 ` [PATCH 00/17] wifi: cc33xx: Add driver for new TI CC33xx wireless device family Kalle Valo
2024-05-24 7:48 ` Nemanov, Michael
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=456c8076-1e3a-4cc9-895c-e707e68fe610@ti.com \
--to=michael.nemanov@ti.com \
--cc=johannes.berg@intel.com \
--cc=justinstitt@google.com \
--cc=keescook@chromium.org \
--cc=krzk@kernel.org \
--cc=kvalo@kernel.org \
--cc=leitao@debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=sabeeh-khan@ti.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®