Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <d23613213568545ec808599a33c04a2e77ac7889.camel@sipsolutions.net>
Subject: Re: [PATCH 1/5] wifi: rtl8xxxu: Add central frequency offset
 tracking
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Bitterblue Smith <rtl8821cerfe2@gmail.com>,
        Ping-Ke Shih <pkshih@realtek.com>,
        "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Cc:     Jes Sorensen <Jes.Sorensen@gmail.com>
Date:   Fri, 21 Oct 2022 22:22:14 +0200
In-Reply-To: <c3540f87-b124-2642-f53e-aa15704a54e8@gmail.com>
References: <2b29b6d9-c17e-76d6-c32f-630f24b407b7@gmail.com>
         <6a91fd1b8d5e4bf3910366121ed92f3b@realtek.com>
         <c3540f87-b124-2642-f53e-aa15704a54e8@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4 (3.44.4-2.fc36) 
MIME-Version: 1.0
Precedence: bulk

On Fri, 2022-10-21 at 21:32 +0300, Bitterblue Smith wrote:
> >=20
> > #define XTAL1 GENMASK(22, 17)
> > #define XTAL0 GENMASK(16, 11)
> >=20
> > val32 &=3D ~(XTAL1 | XTAL2)
> > val32 |=3D FIELD_PREP(XTAL1, crystal_cap) |
> >          FIELD_PREP(XTAL0, crystal_cap);
> >=20
>=20
> Ah, so that's what FIELD_PREP does.

FWIW, personally, I've come to prefer u32_encode_bits() and friends, or,
in this case perhaps

	u32p_replace_bits(&val32, crystal_cap, XTAL0);
	u32p_replace_bits(&val32, crystal_cap, XTAL1);

or maybe writing that as

val32 &=3D ~(XTAL0 | XTAL1);
val32 |=3D u32_encode_bits(crystal_cap, XTAL0);
val32 |=3D u32_encode_bits(crystal_cap, XTAL1);

instead.

That's partially because there are also le32 variants of it etc. that
are simpler to use with endian-fixed firmware interfaces or similar.


But YMMV (as might that of the maintainers of this driver) :-)

johannes