Simple patch that fix spelling mistakes in igb_main.c
Signed-off-by: Johnny Park
---
Changes in v2:
- Fix spelling mor -> more
---
drivers/net/ethernet/intel/igb/igb_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
b/driv
On Tue, Oct 22, 2024 at 05:09:33PM +0100, Simon Horman wrote:
> On Mon, Oct 21, 2024 at 11:11:56PM -0600, Johnny Park wrote:
> > Simple patch that fixes the spelling mistake "intialize" in igb_main.c
> >
> > Signed-off-by: Johnny Park
>
> Thanks Johnny,
>
> I agree this is correct. But I am won
From: Christopher S M Hall
Move ktime_get_snapshot() into the loop. If a retry does occur, a more
recent snapshot will result in a more accurate cross-timestamp.
Fixes: a90ec8483732 ("igc: Add support for PTP getcrosststamp()")
Signed-off-by: Christopher S M Hall
---
drivers/net/ethernet/intel
From: Christopher S M Hall
Lengthen the hardware retry timer to four microseconds.
The i225/i226 hardware retries if it receives an inappropriate response
from the upstream device. If the device retries too quickly, the root
port does not respond.
The issue can be reproduced with the following:
From: Christopher S M Hall
Add a mutex around the PTM transaction to prevent multiple transactors
Multiple processes try to initiate a PTM transaction, one or all may
fail. This can be reproduced by running two instances of the
following:
$ sudo phc2sys -O 0 -i tsn0 -m
PHC2SYS exits with:
"io
From: Christopher S M Hall
Writing to clear the PTM status 'valid' bit while the PTM cycle is
triggered results in unreliable PTM operation. To fix this, clear the
PTM 'trigger' and status after each PTM transaction.
The issue can be reproduced with the following:
$ sudo phc2sys -R 1000 -O 0 -i
There have been sporadic reports of PTM timeouts using i225/i226 devices
These timeouts have been root caused to:
1) Manipulating the PTM status register while PTM is enabled and triggered
2) The hardware retrying too quickly when an inappropriate response is
received from the upstream device
On Mon, Oct 21, 2024 at 04:19:54PM +0200, Arkadiusz Kubalewski wrote:
> Currently HW support of PTP/timesync solutions in network PHY chips can be
> implemented with two different approaches, the timestamp maybe latched
> either at the beginning or after the Start of Frame Delimiter (SFD) [1].
Why
Link queues to NAPI instances via netdev-genl API so that users can
query this information with netlink. Handle a few cases in the driver:
1. Link/unlink the NAPIs when XDP is enabled/disabled
2. Handle IGC_FLAG_QUEUE_PAIRS enabled and disabled
Example output when IGC_FLAG_QUEUE_PAIRS is enabl
On Tue, Oct 22, 2024 at 01:00:47PM -0700, Joe Damato wrote:
> On Tue, Oct 22, 2024 at 05:21:53PM +, Joe Damato wrote:
> > e1000_down calls netif_queue_set_napi, which assumes that RTNL is held.
> >
> > There are a few paths for e1000_down to be called in e1000 where RTNL is
> > not currently b
Link IRQs to NAPI instances via netdev-genl API so that users can query
this information with netlink.
Compare the output of /proc/interrupts (noting that IRQ 128 is the
"other" IRQ which does not appear to have a NAPI instance):
$ cat /proc/interrupts | grep enp86s0 | cut --delimiter=":" -f1
12
Greetings:
Welcome to v4.
See changelog below and in each patch for changes from v3 [1].
This revision was inspired by a bug report for e1000 [2] and analysis of
the call paths for igc on the mailing list [3] to ensure that RTNL is
held in all appropriate paths.
This series adds support for net
On 10/22/2024 2:12 PM, Joe Damato wrote:
> On Tue, Oct 22, 2024 at 01:00:47PM -0700, Joe Damato wrote:
>> On Tue, Oct 22, 2024 at 05:21:53PM +, Joe Damato wrote:
>>> e1000_down calls netif_queue_set_napi, which assumes that RTNL is held.
>>>
>>> There are a few paths for e1000_down to be cal
On Tue, Oct 22, 2024 at 02:15:27PM -0700, Jacob Keller wrote:
>
>
> On 10/22/2024 2:12 PM, Joe Damato wrote:
> > On Tue, Oct 22, 2024 at 01:00:47PM -0700, Joe Damato wrote:
> >> On Tue, Oct 22, 2024 at 05:21:53PM +, Joe Damato wrote:
> >>> e1000_down calls netif_queue_set_napi, which assumes
On 10/22/2024 1:00 PM, Joe Damato wrote:
> On Tue, Oct 22, 2024 at 05:21:53PM +, Joe Damato wrote:
>> e1000_down calls netif_queue_set_napi, which assumes that RTNL is held.
>>
>> There are a few paths for e1000_down to be called in e1000 where RTNL is
>> not currently being held:
>> - e10
On Tue, Oct 22, 2024 at 01:53:01PM -0700, Jacob Keller wrote:
>
>
> On 10/22/2024 1:28 PM, Joe Damato wrote:
> > I took another look at this to make sure that RTNL is held when
> > igc_set_queue_napi is called after the e1000 bug report came in [1],
> > and there may be two locations I've missed:
On 10/22/2024 1:28 PM, Joe Damato wrote:
> I took another look at this to make sure that RTNL is held when
> igc_set_queue_napi is called after the e1000 bug report came in [1],
> and there may be two locations I've missed:
>
> 1. igc_resume, which calls __igc_open
> 2. igc_io_error_detected, w
On Fri, Oct 18, 2024 at 05:13:43PM +, Joe Damato wrote:
> Link queues to NAPI instances via netdev-genl API so that users can
> query this information with netlink. Handle a few cases in the driver:
> 1. Link/unlink the NAPIs when XDP is enabled/disabled
> 2. Handle IGC_FLAG_QUEUE_PAIRS ena
On Tue, Oct 22, 2024 at 05:21:53PM +, Joe Damato wrote:
> e1000_down calls netif_queue_set_napi, which assumes that RTNL is held.
>
> There are a few paths for e1000_down to be called in e1000 where RTNL is
> not currently being held:
> - e1000_shutdown (pci shutdown)
> - e1000_suspend (po
On Tue, Oct 22, 2024 at 11:50:15AM -0700, Jacob Keller wrote:
>
>
> On 10/18/2024 10:13 AM, Joe Damato wrote:
> > Link IRQs to NAPI instances via netdev-genl API so that users can query
> > this information with netlink.
> >
> > Compare the output of /proc/interrupts (noting that IRQ 144 is the
On 10/22/2024 12:32 AM, Simon Horman wrote:
> On Tue, Oct 22, 2024 at 02:56:19PM +0800, Yue Haibing wrote:
>> Fixing sparse error in xdp run code by introducing new variable xdp_res
>> instead of overloading this into the skb pointer as i40e drivers done
>> in commit 12738ac4754e ("i40e: Fix spa
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Aleksandr Loktionov
> Sent: 16 October 2024 15:00
> To: intel-wired-...@lists.osuosl.org; Nguyen, Anthony L
> ; Loktionov, Aleksandr
>
> Cc: net...@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH iwl-net v2] i40e: fix race
On 10/18/2024 10:13 AM, Joe Damato wrote:
> Link IRQs to NAPI instances via netdev-genl API so that users can query
> this information with netlink.
>
> Compare the output of /proc/interrupts (noting that IRQ 144 is the
> "other" IRQ which does not appear to have a NAPI instance):
>
Minor nit
This series fixes reset related issues, especially the case
where the idpf is running on the host and the platform running
the device control plane is rebooted. The first patch fixes the
link_ksettings and the second patch fixes the error path in
idpf_vc_core_init function.
Pavan Kumar Linga (2):
When the device control plane is removed or the platform
running device control plane is rebooted, a reset is detected
on the driver. On driver reset, it releases the resources and
waits for the reset to complete. If the reset fails, it takes
the error path and releases the vport lock. At this time
In an event where the platform running the device control plane
is rebooted, reset is detected on the driver. It releases
all the resources and waits for the reset to complete. Once the
reset is done, it tries to build the resources back. At this
time if the device control plane is not yet started,
On Tue, Oct 22, 2024 at 8:56 AM Simon Horman wrote:
>
> + Alexander Duyck
>
> On Tue, Oct 22, 2024 at 02:38:07PM +0800, Yuan Can wrote:
> > The pci_register_driver() can fail and when this happened, the dca_notifier
> > needs to be unregistered, otherwise the dca_notifier can be called when
> > ig
e1000_down calls netif_queue_set_napi, which assumes that RTNL is held.
There are a few paths for e1000_down to be called in e1000 where RTNL is
not currently being held:
- e1000_shutdown (pci shutdown)
- e1000_suspend (power management)
- e1000_reinit_locked (via e1000_reset_task delayed wo
On Mon, Oct 21, 2024 at 04:48:41PM +0200, Piotr Kwapulinski wrote:
> Add support for Intel(R) E610 Series of network devices. The E610
> is based on X550 but adds firmware managed link, enhanced security
> capabilities and support for updated server manageability
>
> Reviewed-by: Przemek Kitszel
On Mon, Oct 21, 2024 at 11:11:56PM -0600, Johnny Park wrote:
> Simple patch that fixes the spelling mistake "intialize" in igb_main.c
>
> Signed-off-by: Johnny Park
Thanks Johnny,
I agree this is correct. But I am wondering if you could also fix the
following around 3909. It seems to be the onl
On Tue, Oct 22, 2024 at 10:30:11AM -0500, Bjorn Helgaas wrote:
> On Mon, Oct 21, 2024 at 04:46:54PM +0200, Piotr Kwapulinski wrote:
> > PCI_VDEVICE_SUB generates the pci_device_id struct layout for
> > the specific PCI device/subdevice. Private data may follow the
> > output.
> >
> > Reviewed-by:
+ Alexander Duyck
On Tue, Oct 22, 2024 at 02:38:07PM +0800, Yuan Can wrote:
> The pci_register_driver() can fail and when this happened, the dca_notifier
> needs to be unregistered, otherwise the dca_notifier can be called when
> igb fails to install, resulting to invalid memory access.
>
> Fixes
On Mon, Oct 21, 2024 at 04:46:54PM +0200, Piotr Kwapulinski wrote:
> PCI_VDEVICE_SUB generates the pci_device_id struct layout for
> the specific PCI device/subdevice. Private data may follow the
> output.
>
> Reviewed-by: Przemek Kitszel
> Signed-off-by: Piotr Kwapulinski
This looks OK to me b
>From: Simon Horman
>Sent: Tuesday, October 22, 2024 3:40 PM
>
>On Mon, Oct 21, 2024 at 04:19:55PM +0200, Arkadiusz Kubalewski wrote:
>> Allow user to control the latch point of ptp HW timestamps in E825
>> devices.
>>
>> Reviewed-by: Aleksandr Loktionov
>> Signed-off-by: Arkadiusz Kubalewski
>>
As described in the previous patch, the drivers that provide their own
fdb_add and fdb_del callbacks should from now on be responsible for sending
the notification themselves. In this patch, implement the fdb_del leg of
the change.
Signed-off-by: Petr Machata
Reviewed-by: Amit Cohen
---
CC: Prze
Currently when FDB entries are added to or deleted from a VXLAN netdevice,
the VXLAN driver emits one notification, including the VXLAN-specific
attributes. The core however always sends a notification as well, a generic
one. Thus two notifications are unnecessarily sent for these operations. A
sim
In the next patch, responsibility for sending notification is moved from
the core to the driver that implement fdb_add (and fdb_del in the patch
after that). In this patch, export a helper that the core currently uses
for sending FDB notifications for the drivers to use as a fallback if there
is no
>From: Keller, Jacob E
>Sent: Tuesday, October 22, 2024 12:31 AM
>
>
>On 10/21/2024 7:19 AM, Arkadiusz Kubalewski wrote:
>> Currently HW support of PTP/timesync solutions in network PHY chips can
>> be
>> implemented with two different approaches, the timestamp maybe latched
>> either at the begin
Hello:
This patch was applied to netdev/net-next.git (main)
by Paolo Abeni :
On Tue, 15 Oct 2024 15:56:35 +0200 you wrote:
> The kernel test robot reported a build failure on m68k in the intel
> driver due to the recent shapers-related changes.
>
> The mentioned arch has funny alignment properti
On Mon, Oct 21, 2024 at 04:19:55PM +0200, Arkadiusz Kubalewski wrote:
> Allow user to control the latch point of ptp HW timestamps in E825
> devices.
>
> Reviewed-by: Aleksandr Loktionov
> Signed-off-by: Arkadiusz Kubalewski
> ---
> drivers/net/ethernet/intel/ice/ice_ptp.c| 46 +
>From: Paul Menzel
>Sent: Monday, October 21, 2024 5:34 PM
>
>Dear Arkadiusz,
>
>
>Thank you for the patch.
Thank you for the review!
>
>Am 21.10.24 um 16:19 schrieb Arkadiusz Kubalewski:
>> Allow user to control the latch point of ptp HW timestamps in E825
>> devices.
>
>Please give an example
>From: Paul Menzel
>Sent: Monday, October 21, 2024 5:21 PM
>
>Dear Arkadiusz,
>
>
>Thank you for your patch.
Thank you for the review!
>
>Am 21.10.24 um 16:19 schrieb Arkadiusz Kubalewski:
>> Currently HW support of PTP/timesync solutions in network PHY chips can
>> be
>> implemented with two di
allyesconfigclang-18
i386buildonly-randconfig-001-20241022clang-18
i386buildonly-randconfig-002-20241022clang-18
i386buildonly-randconfig-003-20241022clang-18
i386buildonly-randconfig-004-20241022clang-18
i386buildonly
On Tue, Oct 22, 2024 at 02:56:23PM +0800, Yue Haibing wrote:
> ixgbevf_run_xdp() converts customed xdp action to a negative error code
> with the sk_buff pointer type which be checked with IS_ERR in
> ixgbevf_clean_rx_irq(). Remove this error pointer handing instead use
> plain int return value.
>
On Tue, Oct 22, 2024 at 02:56:22PM +0800, Yue Haibing wrote:
> ixgbe_run_xdp() converts customed xdp action to a negative error code
> with the sk_buff pointer type which be checked with IS_ERR in
> ixgbe_clean_rx_irq(). Remove this error pointer handing instead use
> plain int return value.
>
> F
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Marcin Szycik
> Sent: Wednesday, October 9, 2024 8:49 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: net...@vger.kernel.org; Paul Menzel ;
> Marcin Szycik ; Michal Swiatkowski
>
> Subject: [Intel-wired-lan] [PATCH iwl-net v2] ic
On Tue, Oct 22, 2024 at 02:56:19PM +0800, Yue Haibing wrote:
> Fixing sparse error in xdp run code by introducing new variable xdp_res
> instead of overloading this into the skb pointer as i40e drivers done
> in commit 12738ac4754e ("i40e: Fix sparse errors in i40e_txrx.c") and
> commit ae4393dfd47
On 10/21/2024 8:48 PM, Vinicius Costa Gomes wrote:
Joe Damato writes:
Link queues to NAPI instances via netdev-genl API so that users can
query this information with netlink. Handle a few cases in the driver:
1. Link/unlink the NAPIs when XDP is enabled/disabled
2. Handle IGC_FLAG_QUE
On 10/21/2024 8:48 PM, Vinicius Costa Gomes wrote:
Joe Damato writes:
Link IRQs to NAPI instances via netdev-genl API so that users can query
this information with netlink.
Compare the output of /proc/interrupts (noting that IRQ 144 is the
"other" IRQ which does not appear to have a NAPI i
49 matches
Mail list logo
