On 23/04/2024 19:23, Greg Kroah-Hartman wrote:
On Fri, Apr 19, 2024 at 12:20:05PM -0400, Jérôme Carretero wrote:
Hi Sasha,
Thank you, sorry for the delay but I coudln't reboot.
Adding Greg KH because I don't know if stable will receive my e-mail
(not subscribed) but the regression was integra
Andrew Lunn writes:
> On Tue, Apr 23, 2024 at 12:24:54PM +0200, Corinna Vinschen wrote:
>> During successful probe, igc logs this:
>>
>> [5.133667] igc :01:00.0 (unnamed net_device) (uninitialized): PHC
>> added
>>
>>
On 4/23/2024 7:40 AM, Ilpo Järvinen wrote:
PCI_HEADER_TYPE_MULTIFUNC is define by e1000e and ixgbe and both are
unused. There is already PCI_HEADER_TYPE_MFD in pci_regs.h anyway which
should be used instead so remove the duplicated defines of it.
Signed-off-by: Ilpo Järvinen
Thanks Ilpo!
Rev
On Tue, Apr 23, 2024 at 12:24:54PM +0200, Corinna Vinschen wrote:
> During successful probe, igc logs this:
>
> [5.133667] igc :01:00.0 (unnamed net_device) (uninitialized): PHC
> added
>
> The reason is that igc_ptp_ini
> -Original Message-
> From: Polchlopek, Mateusz
> Sent: Monday, April 22, 2024 2:23 AM
> To: Rahul Rameshbabu
> Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org;
> ho...@kernel.org;
> Nguyen, Anthony L ; Keller, Jacob E
> ; Drewek, Wojciech
> Subject: Re: [Intel-wired-lan
On 4/19/2024 10:13 AM, Michal Swiatkowski wrote:
+/**
+ * ice_eswitch_cfg_vsi - configure VSI to work in slow-path
+ * @vsi: VSI structure of representee
+ * @mac: representee MAC
Can you fix the kdoc for this?
> drivers/net/ethernet/intel/ice/ice_eswitch.c:140: warning: No
description fo
allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-001-20240424 gcc
arc randconfig-002-20240424 gcc
arm allmodconfig
On 4/24/2024 8:07 AM, Jiri Pirko wrote:
> Wed, Apr 24, 2024 at 12:03:25AM CEST, jacob.e.kel...@intel.com wrote:
>>
>>
>> On 4/23/2024 6:14 AM, Jiri Pirko wrote:
>>> Tue, Apr 23, 2024 at 01:56:55PM CEST, sergey.temerkha...@intel.com wrote:
> -Original Message-
> From: Ji
On Wed, Apr 24, 2024 at 09:44:22PM +0700, Bui Quang Minh wrote:
> Currently, we allocate a lbuf-sized kernel buffer and copy lbuf from
> userspace to that buffer. Later, we use scanf on this buffer but we don't
> ensure that the string is terminated inside the buffer, this can lead to
> OOB read wh
On Wed, Apr 24, 2024 at 09:44:22PM +0700, Bui Quang Minh wrote:
> Currently, we allocate a lbuf-sized kernel buffer and copy lbuf from
> userspace to that buffer. Later, we use scanf on this buffer but we don't
> ensure that the string is terminated inside the buffer, this can lead to
> OOB read wh
On Tue, Apr 23, 2024 at 09:46:35PM +0700, Bui Quang Minh wrote:
> > > - buffer = vmemdup_user(buf, lbuf);
> > > + buffer = vmemdup_user(buf, lbuf + 1);
> > > if (IS_ERR(buffer))
> > > return -ENOMEM;
> > > + buffer[lbuf] = '\0';
> >
> > This would read one byte too much
We try to access count + 1 byte from userspace with memdup_user(buffer,
count + 1). However, the userspace only provides buffer of count bytes and
only these count bytes are verified to be okay to access. To ensure the
copied buffer is NUL terminated, we use memdup_user_nul instead.
Fixes: 3a2eb51
Currently, we allocate a lbuf-sized kernel buffer and copy lbuf from
userspace to that buffer. Later, we use scanf on this buffer but we don't
ensure that the string is terminated inside the buffer, this can lead to
OOB read when using scanf. Fix this issue by using memdup_user_nul instead.
Fixes:
Currently, we allocate a count-sized kernel buffer and copy count from
userspace to that buffer. Later, we use kstrtouint on this buffer but we
don't ensure that the string is terminated inside the buffer, this can
lead to OOB read when using kstrtouint. Fix this issue by using
memdup_user_nul inst
Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from
userspace to that buffer. Later, we use sscanf on this buffer but we don't
ensure that the string is terminated inside the buffer, this can lead to
OOB read when using sscanf. Fix this issue by using memdup_user_nul
instead of
Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from
userspace to that buffer. Later, we use sscanf on this buffer but we don't
ensure that the string is terminated inside the buffer, this can lead to
OOB read when using sscanf. Fix this issue by using memdup_user_nul
instead of
Currently, we allocate a count-sized kernel buffer and copy count bytes
from userspace to that buffer. Later, we use sscanf on this buffer but we
don't ensure that the string is terminated inside the buffer, this can lead
to OOB read when using sscanf. Fix this issue by using memdup_user_nul
instea
Hi everyone,
I found that some drivers contains an out-of-bound read pattern like this
kern_buf = memdup_user(user_buf, count);
...
sscanf(kern_buf, ...);
The sscanf can be replaced by some other string-related functions. This
pattern can lead to out-of-bound read of kern
> PCI_HEADER_TYPE_MULTIFUNC is define by e1000e and ixgbe and both are
> unused. There is already PCI_HEADER_TYPE_MFD in pci_regs.h anyway which
> should be used instead so remove the duplicated defines of it.
>
> Signed-off-by: Ilpo Järvinen
> ---
> drivers/net/ethernet/intel/e1000e/defines.h
Wed, Apr 24, 2024 at 12:03:25AM CEST, jacob.e.kel...@intel.com wrote:
>
>
>On 4/23/2024 6:14 AM, Jiri Pirko wrote:
>> Tue, Apr 23, 2024 at 01:56:55PM CEST, sergey.temerkha...@intel.com wrote:
>>>
>>>
-Original Message-
From: Jiri Pirko
Sent: Tuesday, April 23, 2024 1:36 PM
>
Dear Piotr,
Thank you for the patch.
Am 24.04.24 um 16:22 schrieb Piotr Kwapulinski:
Add high level link management support for E610 device. Enable the
following features:
- driver load
- bring up network interface
- IP address assignment
- pass traffic
- show statistics (e.g. via ethtool)
- d
allmodconfig gcc
arc allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-001-20240424 gcc
arc randconfig-002
Wed, Apr 24, 2024 at 03:49:09PM CEST, piotr.kwapulin...@intel.com wrote:
>>>-Original Message-
>>>From: Jiri Pirko
>>>Sent: Monday, April 22, 2024 4:26 PM
>>>To: Kwapulinski, Piotr
>>>Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org;
>>>ho...@kernel.org; Wyborny, Carolyn ; J
Add high level link management support for E610 device. Enable the
following features:
- driver load
- bring up network interface
- IP address assignment
- pass traffic
- show statistics (e.g. via ethtool)
- disable network interface
- driver unload
Co-developed-by: Carolyn Wyborny
Signed-off-by:
Add low level link management support for E610 device. Link management
operations are handled via the Admin Command Interface. Add the following
link management operations:
- get link capabilities
- set up link
- get media type
- get link status, link status events
- link power management
Co-devel
Add low level support for accessing NVM in E610 device. NVM operations are
handled via the Admin Command Interface. Add the following NVM specific
operations:
- acquire, release, read
- validate checksum
- read shadow ram
Co-developed-by: Stefan Wegrzyn
Signed-off-by: Stefan Wegrzyn
Co-developed
Add low level support for E610 device capabilities detection. The
capabilities are discovered via the Admin Command Interface. Discover the
following capabilities:
- function caps: vmdq, dcb, rss, rx/tx qs, msix, nvm, orom, reset
- device caps: vsi, fdir, 1588
- phy caps
Co-developed-by: Stefan We
Add low level support for Admin Command Interface (ACI). ACI is the
Firmware interface used by a driver to communicate with E610 adapter. Add
the following ACI features:
- data structures, macros, register definitions
- commands handling
- events handling
Co-developed-by: Stefan Wegrzyn
Signed-of
Add initial 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.
This patch series adds low level support for the following features and
enables link management.
>>-Original Message-
>>From: Jiri Pirko
>>Sent: Monday, April 22, 2024 4:26 PM
>>To: Kwapulinski, Piotr
>>Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org;
>>ho...@kernel.org; Wyborny, Carolyn ; Jagielski,
>>Jedrzej ; Glaza, Jan
>>Subject: Re: [PATCH iwl-next v4 5/5] ixgbe
From: Grzegorz Nitka
>From FW/HW perspective, 2 port topology in E825C devices requires
merging of 2 port mapping internally and breakout mapping externally.
As a consequence, it requires different port numbering from PTP code
perspective.
For that topology, pf_id can not be used to index PTP por
There are E825C products featuring 2 NACs. Those have only one source
clock on the primary NAC.
For those devices, there
should be only one clock controller on the primary NAC. All PFs from
both NACs should connect as auxiliary devices to the auxiliary driver on
the primary NAC.
Reviewed-by: Igor
From: Grzegorz Nitka
Add new device capability ICE_AQC_CAPS_NAC_TOPOLOGY which allows to
determine the mode of operation (1 or 2 NAC).
Define a new structure to store data from new capability and
corresponding parser code.
Co-developed-by: Prathisna Padmasanan
Signed-off-by: Prathisna Padmasana
From: Michal Michalik
The CGU layout of E825-C is a little different than E822/E823. Add
support the new hardware adding relevant functions.
Signed-off-by: Michal Michalik
Reviewed-by: Przemek Kitszel
Reviewed-by: Arkadiusz Kubalewski
Signed-off-by: Karol Kolacinski
---
V9 -> V10: changed 15
From: Sergey Temerkhanov
E825C products feature a new PHY model - ETH56G.
Introduces all necessary PHY definitions, functions etc. for ETH56G PHY,
analogous to E82X and E810 ones with addition of a few HW-specific
functionalities for ETH56G like one-step timestamping.
It ensures correct PTP ini
Simplify the code by using anonymous struct in CGU registers instead of
naming each structure 'field'.
Suggested-by: Przemek Kitszel
Reviewed-by: Przemek Kitszel
Reviewed-by: Arkadiusz Kubalewski
Signed-off-by: Karol Kolacinski
---
drivers/net/ethernet/intel/ice/ice_cgu_regs.h | 12 ++---
dri
From: Jacob Keller
Add a new helper for getting base clock increment value for specific HW.
Signed-off-by: Jacob Keller
Reviewed-by: Przemek Kitszel
Reviewed-by: Arkadiusz Kubalewski
Signed-off-by: Karol Kolacinski
---
V4 -> V5: Removed unused UNKNOWN_INCVAL_E82X
drivers/net/ethernet/intel
From: Sergey Temerkhanov
Move CGU block to the beginning of ice_ptp_hw.c
Signed-off-by: Sergey Temerkhanov
Reviewed-by: Przemek Kitszel
Reviewed-by: Arkadiusz Kubalewski
Signed-off-by: Karol Kolacinski
---
V7 -> V8: brought back P_REG_40B_HIGH_S due to 32 bit compatibility issue
V6 -> V7: -
Add a possibility to mark all transmitted/received timestamps as invalid
by clearing PHY OFFSET_READY registers.
Reviewed-by: Przemek Kitszel
Reviewed-by: Arkadiusz Kubalewski
Signed-off-by: Karol Kolacinski
---
drivers/net/ethernet/intel/ice/ice_ptp.c| 11 ---
drivers/net/ethernet/int
From: Sergey Temerkhanov
Introduce functions enabling/disabling Tx TS interrupts
for the E822 and ETH56G PHYs
Signed-off-by: Sergey Temerkhanov
Reviewed-by: Przemek Kitszel
Reviewed-by: Arkadiusz Kubalewski
Signed-off-by: Karol Kolacinski
---
V5 -> V6: Adjusted return in ice_phy_cfg_intr_e82
From: Jacob Keller
Multiple places in the driver code need to convert enum ice_ptp_tmr_cmd
values into register bits for both the main timer and the PHY port
timers. The main MAC register has one bit scheme for timer commands,
while the PHY commands use a different scheme.
The E810 and E830 devi
Create new ice_ptp_hw struct and use it for all HW and PTP-related
fields from struct ice_hw.
Replace definitions with struct fields, which values are set accordingly
to a specific device.
Reviewed-by: Przemek Kitszel
Reviewed-by: Arkadiusz Kubalewski
Signed-off-by: Karol Kolacinski
---
V4 -> V
E825C products have a different PHY model than E822, E823 and E810 products.
This PHY is ETH56G and its support is necessary to have functional PTP stack
for E825C products.
Grzegorz Nitka (2):
ice: Add NAC Topology device capability parser
ice: Adjust PTP init for 2x50G E825C devices
Jacob K
onfig gcc
arc allmodconfig gcc
arc allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-001-20240424 gcc
allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-001-20240424 gcc
arc randconfig-002-20240424 gcc
arm
arc allmodconfig gcc
arc allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-001-20240424 gcc
arc randc
>-Original Message-
>From: Simon Horman
>Sent: Monday, April 22, 2024 8:32 PM
>To: Kwapulinski, Piotr
>Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; Gomes, Vinicius
>; Wegrzyn, Stefan ;
>Jagielski, Jedrzej ; Sokolowski, Jan
>
>Subject: Re: [PATCH iwl-next v2 2/5] ixgb
Dear Vitaly,
Thank you for the patch.
Am 17.04.24 um 21:03 schrieb Vitaly Lifshits:
This is a partial revert of commit 6dbdd4de0362 ("e1000e: Workaround
for sporadic MDI error on Meteor Lake systems"). The referenced commit
introduced an issue on vPro systems, where disconnecting and reconnec
>-Original Message-
>From: Simon Horman
>Sent: Monday, April 22, 2024 8:32 PM
>To: Kwapulinski, Piotr
>Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; Gomes, Vinicius
>; Wegrzyn, Stefan ;
>Jagielski, Jedrzej ; Sokolowski, Jan
>
>Subject: Re: [PATCH iwl-next v2 2/5] ixgbe
>-Original Message-
>From: Jiri Pirko
>Sent: Monday, April 22, 2024 4:26 PM
>To: Kwapulinski, Piotr
>Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org;
>ho...@kernel.org; Wyborny, Carolyn ; Jagielski,
>Jedrzej ; Glaza, Jan
>Subject: Re: [PATCH iwl-next v4 5/5] ixgbe: Enable
50 matches
Mail list logo
