From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 39399C4332F for ; Mon, 10 Jan 2022 13:47:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233256AbiAJNq6 (ORCPT ); Mon, 10 Jan 2022 08:46:58 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52578 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232889AbiAJNq4 (ORCPT ); Mon, 10 Jan 2022 08:46:56 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AC882C06173F; Mon, 10 Jan 2022 05:46:55 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 397D9B81657; Mon, 10 Jan 2022 13:46:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0887BC36AE3; Mon, 10 Jan 2022 13:46:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1641822413; bh=oq2ENPhcfVsV9txVSXFBcujEFmcA6SmT2Sowk/OZKJo=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=FAvyCWn4JyvlnEiHTfcqGoiit/WTZe4LvsO0SW4KXu3bN+k+dF+tvzn+K0Ne/vYu3 HIlZkRbctTuJXDXzU0aMwL2V8FPXA9abPbHJyRt1AYRBPkD3Rcx4OCuzv7Ft+3A+lf eixOoFI+hTS1XRvzRu5MCdO+RF2V1/JFFMtjR3GP/ltH8WsTltrhzr9LlGQYCmQV5w kWrJm3ct/ggpLXWoR41QxV763wf5lk87wfXujSox0A7mfcxCadj4eCm004tHdGEX7c t/9fplGMazuDNsuu6103Il8ofvMe4l2ndvmoetmQ2/dIl2tN0UaYSv6wBY0H+3o184 GYLJRM9HFmlNg== From: Kalle Valo To: Hector Martin Cc: "David S. Miller" , Jakub Kicinski , Rob Herring , "Rafael J. Wysocki" , Len Brown , Arend van Spriel , Franky Lin , Hante Meuleman , Chi-hsien Lin , Wright Feng , Dmitry Osipenko , Sven Peter , Alyssa Rosenzweig , Mark Kettenis , =?utf-8?Q?Rafa=C5=82_Mi=C5=82ecki?= , Pieter-Paul Giesberts , Linus Walleij , Hans de Goede , "John W. Linville" , "brian m. carlson" , Andy Shevchenko , linux-wireless@vger.kernel.org, netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, brcm80211-dev-list.pdl@broadcom.com, SHA-cyfmac-dev-list@infineon.com Subject: Re: [PATCH v2 00/35] brcmfmac: Support Apple T2 and M1 platforms References: <20220104072658.69756-1-marcan@marcan.st> <87tuebvqw4.fsf@kernel.org> <5226bf9f-fb0f-5dc5-3b82-2125fc229526@marcan.st> Date: Mon, 10 Jan 2022 15:46:45 +0200 In-Reply-To: <5226bf9f-fb0f-5dc5-3b82-2125fc229526@marcan.st> (Hector Martin's message of "Mon, 10 Jan 2022 20:21:03 +0900") Message-ID: <87fspvln3u.fsf@tynnyri.adurom.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org Hector Martin writes: > On 2022/01/10 19:14, Kalle Valo wrote: >> Hector Martin writes: >> >>> Hi everyone, >>> >>> Happy new year! This 35-patch series adds proper support for the >>> Broadcom FullMAC chips used on Apple T2 and M1 platforms: >>> >>> - BCM4355C1 >>> - BCM4364B2/B3 >>> - BCM4377B3 >>> - BCM4378B1 >>> - BCM4387C2 >> >> 35 patches is a lot to review. It would make things easier for reviewers >> if you can split this into smaller patchsets, 10-12 patches per set is >> what I usually recommend. More info in the wiki link below. > > The patches are already split into logical groupings, so I think there > isn't much more to be gained by sending them separately. As I described > in the cover letter: > > 01~09: Firmware selection stuff > 10~14: Add support for BCM4378 > 15~20: Add BCM4355/4364/4377 on top > 21~27: Add BCM4387 and its newer requirements > 28~32: Misc fixes > 33~35: TxCap & calibration support > > If you want to review the series piecemeal, feel free to stop at any of > those boundaries; the series will still make sense and is useful at any > of those stopping points. Really, having smaller patchsets makes the patch flow so much smoother for everyone. If you want to submit huge patchsets then go ahead, but that will automatically drop the patches to the bottom of my queue. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches