> s/unrequired/"not required"/
> s/consme/consume/ .two different places
> s/accros/across/
>
> Signed-off-by: Bhaskar Chowdhury
Acked-by: Igor Russkikh
Thanks
Igor
GvqcEGj8wEOVoN1BySZhGUVECVTBJCmNiRsHUw&s=J1SWrfEL
> erJOzUlJdD_S5afGaZosmVP8lyKsu9DTULw&e=
> Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Igor Russkikh
Thanks,
Igor
> Igor, can you please ack these patches?
>
> Igor, please also let us know:
> A. if you will pick them up and let them travel through your tree, or
> B. if the spdx maintainers shall pick them up and they shall route them
> directly to Linus.
Thanks Lukas,
Acked on ethernet driver p
iewed-by: Richard Fontana
> Reviewed-by: Jilayne Lovejoy
> Reviewed-by: Alexios Zavras
> Signed-off-by: Lukas Bulwahn
Acked-by: Igor Russkikh
Thanks,
Igor
Richard Fontana
> Reviewed-by: Jilayne Lovejoy
> Reviewed-by: Alexios Zavras
> Signed-off-by: Lukas Bulwahn
Acked-by: Igor Russkikh
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
> b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
> index 1426c691c7c4..0346771396ce 100644
> --- a/drivers/net/e
> --
> On Thu, 16 Jul 2020 14:54:43 +0300 Alexander Lobakin wrote:
>> These ports ship on new boards revisions and are supported by newer
>> firmware versions.
>>
>> Signed-off-by: Alexander L
>>> We have a new ethernet card that is supported by the atlantic driver:
>>> 01:00.0 Ethernet controller [0200]: Aquantia Corp. AQC107 NBase-T/IEEE
> 802.3bz Ethernet Controller [AQtion] [1d6a:07b1] (rev 02)
>>>
>>> But the driver failed to probe the device:
>>> kernel: atlantic: Bad FW version
ike pci_save_state()
> and
> pci_enable_wake(), inside them
>
> Compile-tested only.
>
> Signed-off-by: Vaibhav Gupta
Acked-by: Igor Russkikh
Thanks!
d: FW 8.42.2.0 debug features")
> Signed-off-by: Colin Ian King
> ---
>
> V2: use the error message as suggested by Igor Russkikh
>
> ---
Thanks!
Acked-by: Igor Russkikh
x2x/bnx2x_main.c | 3 +--
> 3 files changed, 8 insertions(+), 14 deletions(-)
Acked-by: Igor Russkikh
Sudarsana, could you please give it a short sanity test and report back?
Thanks,
Igor
Hi Colin!
Thanks for catching this, indeed this was missed!
>
> /* DBG_STATUS_INVALID_FILTER_TRIGGER_DWORDS */
> "The filter/trigger constraint dword offsets are not enabled for
> recording",
> -
> + /* DBG_STATUS_NO_MATCHING_FRAMING_MODE */
> + "No matching framing mode",
>
> >
> > This one is perfect, thanks!
>
> Can I add your Reviewed-by provided I remove the hunk above?
>
> Luis
Sure, I'm OK.
Regards,
Igor
>
> So do you mean like the changes below?
>
> diff --git a/drivers/net/ethernet/qlogic/qed/qed_debug.c
> b/drivers/net/ethernet/qlogic/qed/qed_debug.c
> index f4eebaabb6d0..95cb7da2542e 100644
> --- a/drivers/net/ethernet/qlogic/qed/qed_debug.c
> +++ b/drivers/net/ethernet/qlogic/qed/qed_debug.c
>> So I think its not a good place to insert this call.
>> Its hard to find exact good place to insert it in qed.
>
> Is there a way to check if what happened was indeed a fw crash?
Our driver has two firmwares (slowpath and fastpath).
For slowpath firmware the way to understand it crashed is t
> This makes use of the new module_firmware_crashed() to help
> annotate when firmware for device drivers crash. When firmware
> crashes devices can sometimes become unresponsive, and recovery
> sometimes requires a driver unload / reload and in the worst cases
> a reboot.
>
> Using a taint flag
> #include
> +#include
> #include
> #include
> #include
> @@ -574,13 +575,13 @@ int qede_add_tc_flower_fltr(struct qede_dev *edev,
> __be16 proto,
> #define RX_RING_SIZE ((u16)BIT(RX_RING_SIZE_POW))
> #define NUM_RX_BDS_MAX (RX_RING_SIZE - 1)
> #define NUM_RX_BD
output;
> - mark code blocks and literals as such;
> - adjust identation, whitespaces and blank lines where needed;
> - add to networking/index.rst.
>
> Signed-off-by: Mauro Carvalho Chehab
Acked-by: Igor Russkikh
Thanks alot, Mauro, for this conversion!
Igor
ed-off-by: Chenwandun
Reviewed-by: Igor Russkikh
Regards,
Igor
> Right. I did not see how *not* to strip the sectag in the h/w back then,
> I'll have another look because that would improve things a lot.
>
> @all: do other MACsec offloading hardware allow not to stip the sectag?
I've just checked this, and see an action option in our HW classifier to keep
m
>
> Talking about packet numbers, can you describe how PN exhaustion is
> handled? I couldn't find much about packet numbers at all in the
> driver patches (I hope the hw doesn't wrap around from 2^32-1 to 0 on
> the same SA). At some point userspace needs to know that we're
> getting close to
On 13.08.2019 16:17, Andrew Lunn wrote:
> On Tue, Aug 13, 2019 at 10:58:17AM +0200, Antoine Tenart wrote:
>> I think this question is linked to the use of a MACsec virtual interface
>> when using h/w offloading. The starting point for me was that I wanted
>> to reuse the data structures and the A
On 10.08.2019 19:34, Andrew Lunn wrote:
> On Thu, Aug 08, 2019 at 04:05:57PM +0200, Antoine Tenart wrote:
>> The MACsec configuration is passed to device drivers supporting it
>> through macsec_hw_offload() which is called from the MACsec genl
>> helpers. This function calls the macsec ops of PH
On 08.08.2019 17:05, Antoine Tenart wrote:
> The Rx and TX handlers are modified to take in account the special case
> were the MACsec transformation happens in the hardware, whether in a PHY
> or in a MAC, as the packets seen by the networking stack on both the
Don't you think we may eventually
Hi Antoine,
Overall good looking patchset, great!
> +/**
> + * struct macsec_tx_sa - transmit secure association
> + * @active:
> + * @next_pn: packet number to use for the next packet
> + * @lock: protects next_pn manipulations
> + * @key: key structure
> + * @stats: per-SA stats
> + */
> +stru
On 15.05.2019 13:56, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.1.3 release.
> There are 46 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
>
> Oliver Neu
On 15.05.2019 13:56, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.1.3 release.
> There are 46 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
...
> Oliver Neuk
Hi Stephen,
Thanks for heads up.
We are now looking into this, but the strange thing is atlantic driver had no
valuable changes
between 4.20 and 5.0rc.
Also, from what user writes up in the ticket, the issue seems to be related
with pci/thunderbolt
subsystem, not with the device driver itself
Hi Antoine,
Its great to see macsec hw offload infrastructure happening!
> @@ -1441,6 +1445,10 @@ struct net_device_ops {
> u32 flags);
> int (*ndo_xsk_async_xmit)(struct net_device *dev,
>
>> Fixes: a09bd81b5413 ("net: aquantia: Limit number of vectors to actually
>> allocated irqs")
>> Signed-off-by: Colin Ian King
>
> This doesn't apply to net-next.
>
Colin, believe thats because you should target to net, not net-next.
BR, Igor
gt;
> Detected by CoverityScan, CID#1468650 ("Unsigned compared against 0")
>
> Fixes: a09bd81b5413 ("net: aquantia: Limit number of vectors to actually
> allocated irqs")
> Signed-off-by: Colin Ian King
> ---
Acked-by: Igor Russkikh
> Patch timing is sometimes surprising!
Indeed it.
>
> Not sure at all if it can be an issue, but I also noted that the order of
> 'pci_release_regions()' and 'free_netdev()' is in reverse
> order in the 'aq_pci_remove()' function.
> I don't know if done on purpose and/or needed, so I've left
Hi Christophe,
On 08.05.2018 09:39, Christophe JAILLET wrote:
> The position of 2 labels should be swapped in order to release resources
> in the correct order and avoid leaks.
>
> kfree(self->aq_hw);
> err_ioremap:
> free_netdev(ndev);
> -err_pci_func:
> - pci_release_regions(p
33 matches
Mail list logo
