lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bf435a7f-aee6-0f45-2eb8-128977a8a6ae@wanadoo.fr>
Date:   Thu, 27 Apr 2023 08:37:50 +0200
From:   Christophe JAILLET <christophe.jaillet@...adoo.fr>
To:     Kalle Valo <kvalo@...nel.org>, Joe Perches <joe@...ches.com>
Cc:     ath11k@...ts.infradead.org, christophe.jaillet@...adoo.fr,
        davem@...emloft.net, edumazet@...gle.com,
        kernel-janitors@...r.kernel.org, kuba@...nel.org,
        linux-kernel@...r.kernel.org, linux-wireless@...r.kernel.org,
        netdev@...r.kernel.org, pabeni@...hat.com
Subject: Re: [PATCH net-next] wifi: ath11k: Use list_count_nodes()

Le 27/04/2023 à 06:35, Kalle Valo a écrit :
> Christophe JAILLET <christophe.jaillet-39ZsbGIQGT5GWvitb5QawA@...lic.gmane.org> writes:
> 
>> ath11k_wmi_fw_stats_num_vdevs() and ath11k_wmi_fw_stats_num_bcn() really
>> look the same as list_count_nodes(), so use the latter instead of hand
>> writing it.
>>
>> The first ones use list_for_each_entry() and the other list_for_each(), but
>> they both count the number of nodes in the list.
>>
>> While at it, also remove to prototypes of non-existent functions.
>> Based on the names and prototypes, it is likely that they should be
>> equivalent to list_count_nodes().
>>
>> Signed-off-by: Christophe JAILLET <christophe.jaillet-39ZsbGIQGT5GWvitb5QawA@...lic.gmane.org>
>> ---
>> Un-tested
> 
> I'll run sanity tests on ath11k patches. I'll also add "Compile tested
> only" to the commit log.
> 
> Oh, and ath11k patches go to ath tree, not net-next.
> 
Hi,

[adding Joe Perches]

maybe checkpatch could be instrumented for that?

Something that would print a warning if the MAINTAINERS file has a git 
repo in T: or if F: states something related to 'net'.


WARNING: Your patch is against the xxx.git repo but the subject of the 
mail does not reflect it. Should [PATCH xxx] be used instead?
Also make sure that it applies cleanly on xxx.git to ease merge process.

WARNING: Your patch is related to 'net'. Such patches should state 
[PATCH net] when related to bug fix, or [PATCH net-next] otherwise.

Eventually, something if net-next is closed?


What do you think?
Would it be possible? Would it help?

CJ

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ