[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CABBYNZLRcX_tAupW0BB-7ykioXF96M2wHXMSRv+189gQSffR1w@mail.gmail.com>
Date: Thu, 17 Jul 2025 12:42:44 -0400
From: Luiz Augusto von Dentz <luiz.dentz@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: davem@...emloft.net, linux-bluetooth@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: [GIT PULL] bluetooth 2025-07-17
Hi Jakub,
On Thu, Jul 17, 2025 at 11:54 AM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Thu, 17 Jul 2025 11:47:49 -0400 Luiz Augusto von Dentz wrote:
> > > On Thu, 17 Jul 2025 10:28:49 -0400 Luiz Augusto von Dentz wrote:
> > > > Bluetooth: hci_dev: replace 'quirks' integer by 'quirk_flags' bitmap
> > >
> > > FTR this rename and adding the helpers does not seem to be very
> > > necessary for the fix? I know Greg says that we shouldn't intentionally
> > > try to make fixes small, but there's a fine line between following that
> > > and coincidental code refactoring.
> >
> > I should have reworded that commit, it is actually a fix, not just
> > renaming, we run out of bits on a 32 bits system due to usage of int
> > as storage.
>
> Right, but I think if the new bitmap was called quirks the existing
> set_bit / test_bit call sites would have been just fine, right?
> The bit ops operate on single ulong and bitmaps all the same.
I guess you are talking about the likes of hci_set_quirk vs using
set_bit directly? hci_set_quirk is just a macro that does use set_bit:
#define hci_set_quirk(hdev, nr) set_bit((nr), (hdev)->quirk_flags)
I guess we didn't have to introduce it at the same time and calling it
just quirks would be fine by me, but I find it cleaner this way even
though we had to fix all the drivers in the process, that said maybe
it won't be that easy to backport and may affect out of the tree
drivers just because we change its name.
--
Luiz Augusto von Dentz
Powered by blists - more mailing lists