public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: "Nemanov, Michael" <michael.nemanov@ti.com>,
	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: Fri, 31 May 2024 09:35:04 +0200	[thread overview]
Message-ID: <97d8acf9-6cb3-4da7-ad4e-0f2d0a63c172@kernel.org> (raw)
In-Reply-To: <456c8076-1e3a-4cc9-895c-e707e68fe610@ti.com>

On 30/05/2024 13:54, Nemanov, Michael wrote:
> 
> 
> 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?

It's impossible to read your email.

I have no clue what you are referring to.


>>> +} > + > +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?

Was never allowed. There is only one version: the kernel version. There
were many comments already explaining why "driver version" is
wrong/meaningless.

Best regards,
Krzysztof


  parent reply	other threads:[~2024-05-31  7:35 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
2024-05-30 14:37       ` Kalle Valo
2024-05-31  7:35       ` Krzysztof Kozlowski [this message]
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=97d8acf9-6cb3-4da7-ad4e-0f2d0a63c172@kernel.org \
    --to=krzk@kernel.org \
    --cc=johannes.berg@intel.com \
    --cc=justinstitt@google.com \
    --cc=keescook@chromium.org \
    --cc=kvalo@kernel.org \
    --cc=leitao@debian.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=michael.nemanov@ti.com \
    --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