[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABBYNZ+M5FYzGe6xLM7uThwNrfRs4-hN40-LYiwp_249NKMomQ@mail.gmail.com>
Date: Tue, 14 May 2024 10:44:19 -0400
From: Luiz Augusto von Dentz <luiz.dentz@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Willem de Bruijn <willemdebruijn.kernel@...il.com>, davem@...emloft.net,
linux-bluetooth@...r.kernel.org, netdev@...r.kernel.org,
Pauli Virtanen <pav@....fi>
Subject: Re: pull request: bluetooth-next 2024-05-10
Hi Jakub,
On Tue, May 14, 2024 at 10:34 AM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Mon, 13 May 2024 22:12:04 -0400 Luiz Augusto von Dentz wrote:
> > > > It might be safer to only suppress the sk_error_report in
> > > > sock_queue_err_skb. Or at least in bt_sock_poll to check the type of
> > > > all outstanding errors and only suppress if all are timestamps.
> > >
> > > Or perhaps we could actually do that via poll/epoll directly? Not that
> > > it would make it much simpler since the library tends to wrap the
> > > usage of poll/epoll but POLLERR meaning both errors or errqueue events
> > > is sort of the problem we are trying to figure out how to process them
> > > separately.
> >
> > @Jakub Kicinski I'm fine removing these from the pull request, or if
> > you want to do it yourself, in order not to miss the merge window,
> > then we can discuss it better and even put you and Willem on CC to
> > review the upcoming changes.
>
> Sounds like the best way forward, thanks!
> Could you drop them and resend the PR?
>
> It's going to take me until noon pacific to write up the PR text
> for all of net-next, to give you a sense of when our PR will come
> out.
Perfect, will also make sure to include the btintel_pcie fix for the
warning and drop the entire set implementing support SO_TIMESTAMPING.
--
Luiz Augusto von Dentz
Powered by blists - more mailing lists