[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e42c5484-d66-e41a-8b2e-a1fa4495ce2@linux.intel.com>
Date: Thu, 2 Nov 2023 14:24:06 +0200 (EET)
From: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To: Johannes Berg <johannes@...solutions.net>
cc: Ma Jun <Jun.Ma2@....com>, amd-gfx@...ts.freedesktop.org,
lenb@...nel.org, davem@...emloft.net, edumazet@...gle.com,
kuba@...nel.org, pabeni@...hat.com, alexander.deucher@....com,
Lijo.Lazar@....com, mario.limonciello@....com,
Netdev <netdev@...r.kernel.org>, linux-wireless@...r.kernel.org,
LKML <linux-kernel@...r.kernel.org>, linux-doc@...r.kernel.org,
platform-driver-x86@...r.kernel.org, majun@....com,
Evan Quan <quanliangl@...mail.com>
Subject: Re: [Patch v13 4/9] wifi: mac80211: Add support for WBRF features
On Thu, 2 Nov 2023, Johannes Berg wrote:
> On Thu, 2023-11-02 at 13:55 +0200, Ilpo Järvinen wrote:
>
> > > +static void get_chan_freq_boundary(u32 center_freq, u32 bandwidth, u64 *start, u64 *end)
> > > +{
> > > + bandwidth = MHZ_TO_KHZ(bandwidth);
> > > + center_freq = MHZ_TO_KHZ(center_freq);
> >
> > Please use include/linux/units.h ones for these too.
>
> Now we're feature creeping though - this has existed for *years* in the
> wireless stack with many instances? We can convert them over, I guess,
> but not sure that makes much sense here - we'd want to add such macros
> to units.h, but ... moving them can be independent of this patch?
What new macros you're talking about? Nothing new needs to be added
as there's already KHZ_PER_MHZ so these would just be:
bandwidth *= KHZ_PER_MHZ;
center_freq *= KHZ_PER_MHZ;
Everything can of course be postponed by the argument that some
subsystem specific mechanism has been there before the generic one
but the end of that road won't be pretty... What I was trying to do
here was to point out the new stuff introduced by this series into the
direction of the generic thing.
--
i.
Powered by blists - more mailing lists