linux-kernel - [PATCH 5.10 0/1] mt76: move mt76_init_tx

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230122155910.32635-1-n.zhandarovich@fintech.ru>
Date:   Sun, 22 Jan 2023 07:59:10 -0800
From:   Nikita Zhandarovich <n.zhandarovich@...tech.ru>
To:     <stable@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:     Nikita Zhandarovich <n.zhandarovich@...tech.ru>,
        Felix Fietkau <nbd@....name>,
        Lorenzo Bianconi <lorenzo.bianconi83@...il.com>,
        Ryder Lee <ryder.lee@...iatek.com>,
        Kalle Valo <kvalo@...eaurora.org>,
        <linux-wireless@...r.kernel.org>, <netdev@...r.kernel.org>,
        <linux-mediatek@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>,
        "Alexey Khoroshilov" <khoroshilov@...ras.ru>,
        <lvc-project@...uxtesting.org>
Subject: [PATCH 5.10 0/1] mt76: move mt76_init_tx_queue in common code

My apologies, I should've have explained my reasoning for the patch better (and sooner).

1. My issue with 5.10 version of mt7615_init_tx_queues() in drivers/net/wireless/mediatek/mt76/mt7615/dma.c is that return value of final call to mt7615_init_tx_queue() is not taken into account
when returning result of mt7615_init_tx_queues(). So, if last mt7615_init_tx_queue() fails (due to memory issues, for instance), parent function will still erroneously return 0.

2. To correct the issue, I turned to Lorenzo's patch in b671da33d1c5973f90f098ff66a91953691df582 which solves my petit problem as well as rewrites a single mt76_init_tx_queue() function to be used
across all mt76 drivers.

3. I was torn between writing my own little patch to fix a single mistake or use an existing one that increases code readability and uniformity. I settled on latter.

4. As for this patch exclusivity to 5.10.y branch, I have an incentive to prioritize 5.10 of all others. Wasn't sure I should be the one to suggest the patch for other branches but it does make sense.

Keep having issues with quoting emails properly, hope this one worked fine.

Thanks,

Nikita