On 30/05/2024 6:11 pm, Yury Norov wrote:
On Wed, May 29, 2024 at 04:12:25PM +0100, Robin Murphy wrote:
Hi Alexander,
On 27/03/2024 3:23 pm, Alexander Lobakin wrote:
Now that we have generic bitmap_read() and bitmap_write(), which are
inline and try to take care of non-bound-crossing and aligne
On 5/30/2024 10:06 AM, Paul Greenwalt wrote:
> Commit 24407a01e57c ("ice: Add 200G speed/phy type use") added support
> for 200G PHY speeds, but did not include 200G link speed message
> support. As a result the driver incorrectly reports Unknown for 200G
> link speed.
>
> Fix this by adding 200G
Commit 24407a01e57c ("ice: Add 200G speed/phy type use") added support
for 200G PHY speeds, but did not include 200G link speed message
support. As a result the driver incorrectly reports Unknown for 200G
link speed.
Fix this by adding 200G support to ice_print_link_msg().
Fixes: 24407a01e57c ("i
On Wed, May 29, 2024 at 04:12:25PM +0100, Robin Murphy wrote:
> Hi Alexander,
>
> On 27/03/2024 3:23 pm, Alexander Lobakin wrote:
> > Now that we have generic bitmap_read() and bitmap_write(), which are
> > inline and try to take care of non-bound-crossing and aligned cases
> > to keep them optimi
A bug in https://bugzilla.kernel.org/show_bug.cgi?id=218906 describes
that irdma would break and report hardware initialization failed after
suspend/resume with Intel E810 NIC (tested on 6.9.0-rc5).
The problem is caused due to the collision between the irq numbers
requested in irdma and the irq n
Alexander Lobakin wrote:
> Currently, idpf uses the following model for the header buffers:
>
> * buffers are allocated via dma_alloc_coherent();
> * when receiving, napi_alloc_skb() is called and then the header is
> copied to the newly allocated linear part.
>
> This is far from optimal as DM
On Thu, May 30, 2024 at 8:52 AM D, Lakshmi Sowjanya
wrote:
> > -Original Message-
> > From: Andy Shevchenko
> > Sent: Monday, May 27, 2024 8:04 PM
> > Mon, May 27, 2024 at 11:48:54AM +, D, Lakshmi Sowjanya kirjoitti:
> > > > -Original Message-
> > > > From: Andy Shevchenko
>
On 5/22/2024 10:23, Sasha Neftin wrote:
The commit 01cf893bf0f4 ("net: intel: i40e/igc: Remove setting Autoneg in
EEE capabilities") removed SUPPORTED_Autoneg field but left inappropriate
ethtool_keee structure initialization. When "ethtool --show "
(get_eee) invoke, the 'ethtool_keee' structure
On 27.05.24 15:50, Jani Nikula wrote:
>
> Hi all, the Intel graphics CI hits a lockdep issue with commit
> 86167183a17e ("igc: fix a log entry using uninitialized netdev") in
> v6.10-rc1.
FWIW, there is a earlier regression report bisected to that commit id:
https://lore.kernel.org/lkml/cabxgcsok
Dear En-Wei,
Thank you for your quick reply.
Am 30.05.24 um 09:08 schrieb En-Wei WU:
Sorry for being unclear. I meant, does resuming the system take longer
now? (initcall_debug might give a clue.)
I've tested the S3 suspend/resume with the initcall_debug kernel
command option, and it shows n
Thank you for your reply.
> Sorry for being unclear. I meant, does resuming the system take longer
> now? (initcall_debug might give a clue.)
I've tested the S3 suspend/resume with the initcall_debug kernel
command option, and it shows no clear difference between having or not
having the ice_init_
11 matches
Mail list logo