linux-kernel - Re: [PATCH next] wifi: ath12k: clean up on error in ath12k_dp

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: <aUUGzCA-M-D3VFj9@stanley.mountain>
Date: Fri, 19 Dec 2025 11:03:24 +0300
From: Dan Carpenter <dan.carpenter@...aro.org>
To: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@....qualcomm.com>
Cc: Harsh Kumar Bijlani <quic_hbijlani@...cinc.com>,
	Jeff Johnson <jjohnson@...nel.org>,
	Ripan Deuri <quic_rdeuri@...cinc.com>,
	Baochen Qiang <baochen.qiang@....qualcomm.com>,
	linux-wireless@...r.kernel.org, ath12k@...ts.infradead.org,
	linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org
Subject: Re: [PATCH next] wifi: ath12k: clean up on error in ath12k_dp_setup()

On Fri, Dec 19, 2025 at 10:18:02AM +0300, Dan Carpenter wrote:
> On Fri, Dec 19, 2025 at 10:54:03AM +0530, Vasanthakumar Thiagarajan wrote:
> > 
> > 
> > On 12/18/2025 1:14 PM, Dan Carpenter wrote:
> > > Destroy the rhash_tbl before returning the error code.
> > > 
> > > Fixes: a88cf5f71adf ("wifi: ath12k: Add hash table for ath12k_dp_link_peer")
> > > Signed-off-by: Dan Carpenter <dan.carpenter@...aro.org>
> > 
> > nit: The next branch in ath is actually ath-next.
> 
> I'm working with over 400 different branches, right?  I can't keep track
> of them all so I just put "next" if it's in linux-next and leave it
> blanke if it's in Linus's tree.  It's automated.

For automated QC, it's really easy to automate on the recieving side.
In some ways, since there is only one place which recieves code and
does QC and a hundred different people sending patches, then it makes
more sense to do it on the recieving side.

This rule started with Dave Miller.  He was handling a hundred patches
a day.  Everything in networking except for wireless.  Also Sparc and
ata.  This was before I invented the Fixes tag, so that wasn't an
option.  Greg and Andrew still handle that level of traffic but they
just use Fixes tags to automate their process.

regards,
dan carpenter