e759cda51b ("l2tp: use standard API for warning log messages")
Signed-off-by: Matthias Schiffer
---
v2:
- Add counter for invalid packets
- Reduce loglevel of more messages that can be abused for log spam
include/uapi/linux/l2tp.h | 1 +
net/l2tp/l
On 2/23/21 10:47 AM, Tom Parkin wrote:
On Mon, Feb 22, 2021 at 14:31:38 -0800, Jakub Kicinski wrote:
On Mon, 22 Feb 2021 17:40:16 +0100 Matthias Schiffer wrote:
This will not be sufficient for my usecase: To stay compatible with older
versions of fastd, I can't set the T flag in the
On 2/22/21 12:49 PM, Tom Parkin wrote:
On Sat, Feb 20, 2021 at 10:56:33 +0100, Matthias Schiffer wrote:
On 2/19/21 9:12 PM, Tom Parkin wrote:
On Fri, Feb 19, 2021 at 20:06:15 +0100, Matthias Schiffer wrote:
Before commit 5ee759cda51b ("l2tp: use standard API for warning log
messages&
Hi Tom,
On 2/19/21 9:12 PM, Tom Parkin wrote:
Hi Matthias,
Thanks for your patch!
On Fri, Feb 19, 2021 at 20:06:15 +0100, Matthias Schiffer wrote:
Before commit 5ee759cda51b ("l2tp: use standard API for warning log
messages"), it was possible for userspace applications to use
2TP version are checked
before the T flag.
Reduce all warnings debug level when packets are passed to userspace.
Fixes: 5ee759cda51b ("l2tp: use standard API for warning log messages")
Signed-off-by: Matthias Schiffer
---
I'm unsure what to do about the pr_warn_ratelimited() i
the fix lands in the kernel.
Moreover, this wouldn't leave the kernel sources in a non-bisect-able
state during that time.
--
-- Matthias Urlichs
OpenPGP_signature
Description: OpenPGP digital signature
From: Matthias Brugger
Apart from a firmware binary the chip needs a config file used by the
FW. Add the config files to modinfo so that they can be read by
userspace.
Signed-off-by: Matthias Brugger
---
Changes in v3:
Use only two more generic wildcards.
Changes in v2:
In comparison to
On 20/11/2020 11:05, Dmitry Osipenko wrote:
20.11.2020 12:52, matthias@kernel.org пишет:
From: Matthias Brugger
Apart from a firmware binary the chip needs a config file used by the
FW. Add the config files to modinfo so that they can be read by
userspace.
Signed-off-by: Matthias
From: Matthias Brugger
Apart from a firmware binary the chip needs a config file used by the
FW. Add the config files to modinfo so that they can be read by
userspace.
Signed-off-by: Matthias Brugger
---
Changes in v2:
In comparison to first version [0] we use wildcards to enumerate the
plied, thank you.
Regarding the DTS patches: Please coordinate with me the next time. I want to
prevent merge conflicts if both mine and your tree add patches to the files.
Thanks,
Matthias
Z8795 driver (which completely broke probing, as the CPU port
index was always failing the num_ports check).
Fixes: af199a1a9cb0 ("net: dsa: microchip: set the correct number of
ports")
Signed-off-by: Matthias Schiffer
---
drivers/net/dsa/microchip/ksz8795.c | 2 +-
1 file changed, 1
ition is met. Setting the output level in
software is also possible.
Regarding the option to emulate unsupported HW triggers in software,
two questions come to my mind:
- Do all PHYs support manual setting of the LED level, or are the PHYs
that can only work with HW triggers?
- Is setting PHY registers always efficiently possible, or should SW
triggers be avoided in certain cases? I'm thinking about setups like
mdio-gpio. I guess this can only become an issue for triggers that
blink.
Kind regards,
Matthias
On Mon, 2020-08-03 at 07:44 +0200, Michael Grzeschik wrote:
> Add KSZ88X3 driver support. We add support for the KXZ88X3 three port
> switches using the Microchip SMI Interface. They are supported using
> the
> MDIO-Bitbang Interface.
>
> Signed-off-by: Michael Grzeschik
>
> ---
> v1 -> v2: - t
drivers/net/dsa/microchip/ksz8863_reg.h
> create mode 100644 drivers/net/dsa/microchip/ksz8863_smi.c
>
Hello Michael,
I've given this series a spin on a TQ-Systems ARM64 board with a
KSZ8863 switch connected via SMI (rebased onto kernel 5.4.y), and
everything seems to work as expected. Feel free to CC me for the next
revision of the series, so I can add my Tested-by.
Kind regards,
Matthias
default:
dev_err_ratelimited(dev->dev, "tx urb failed: %d\n",
urb->status);
- fallthrough;
- case 0:
break;
}
Reviewed-by: Matthias Brugger
re is also a 3rd register that defines the blink frequency, but
as it allows only a single setting for all LEDs, I would ignore it for
now)
At least the per-LED polarity setting would be essential to have for
this feature to be useful for our TQ-Systems mainboards with TI PHYs.
Kind regards,
Matt
On Sat, 2020-08-22 at 18:08 +0200, Andrew Lunn wrote:
> On Fri, Aug 21, 2020 at 09:21:46AM +0200, Matthias Schiffer wrote:
> > These DT bindings are already in use by the imx7-mba7 DTS, but they
> > were
> > not supported by the PHY driver so far.
> >
> >
These DT bindings are already in use by the imx7-mba7 DTS, but they were
not supported by the PHY driver so far.
Signed-off-by: Matthias Schiffer
---
drivers/net/phy/dp83867.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/net/phy/dp83867.c b/drivers
.
Signed-off-by: Matthias Schiffer
---
.../devicetree/bindings/net/ti,dp83867.yaml | 18 ++
include/dt-bindings/net/ti-dp83867.h | 60 +++
2 files changed, 78 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.yaml
b/Documentation/devicetree
On 02/07/2020 20:00, Hans de Goede wrote:
> Hi,
>
> On 7/1/20 5:46 PM, Matthias Brugger wrote:
>> Hi Hans,
>>
>> On 01/07/2020 17:38, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 7/1/20 5:31 PM, matthias@kernel.org wrote:
>>>>
Hi Hans,
On 01/07/2020 17:38, Hans de Goede wrote:
> Hi,
>
> On 7/1/20 5:31 PM, matthias@kernel.org wrote:
>> From: Matthias Brugger
>>
>> Apart from a firmware binary the chip needs a config file used by the
>> FW. Add the config files to modinfo so that
From: Matthias Brugger
Apart from a firmware binary the chip needs a config file used by the
FW. Add the config files to modinfo so that they can be read by
userspace.
Signed-off-by: Matthias Brugger
---
.../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 16
1 file changed
From: Matthias Brugger
The driver relies on the compatible string from DT to determine which
FW configuration file it should load. The DTS spec allows for '/' as
part of the compatible string. We change this to '-' so that we will
still be able to load the config file, even
From: Matthias Brugger
The driver relies on the compatible string from DT to determine which
FW configuration file it should load. The DTS spec allows for '/' as
part of the compatible string. We change this to '-' so that we will
still be able to load the config file, even
From: Matthias Brugger
The driver relies on the compatible string from DT to determine which
FW configuration file it should load. The DTS spec allows for '/' as
part of the compatible string. We change this to '-' so that we will
still be able to load the config file, even
On 5/22/20 11:36 PM, David Miller wrote:
> From: Matthias Brugger
> Date: Fri, 22 May 2020 23:31:50 +0200
>
>>
>>
>> On 22/05/2020 23:20, David Miller wrote:
>>> From: Bartosz Golaszewski
>>> Date: Fri, 22 May 2020 14:06:49 +0200
>>&g
you.
>
If you say "series applied" do you mean you also applied the device tree parts?
These should go through my branch, because there could be conflicts if there are
other device tree patches from other series, not related with network, touching
the same files.
Regards,
Matthias
On 22/05/2020 14:06, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> This adds the driver for the MediaTek STAR Ethernet MAC currently used
> on the MT8* SoC family. For now we only support full-duplex.
MT85** SoC family, AFAIU it's not used on MT81** devices. Correct?
>
> Signed
onfig_intr= &at803x_config_intr,
> .get_tunable= at803x_get_tunable,
> .set_tunable= at803x_set_tunable,
> + .cable_test_start = at803x_cable_test_start,
> + .cable_test_get_status = at803x_cable_test_get_status,
> }, {
> /* Qualcomm Atheros AR8032 */
> PHY_ID_MATCH_EXACT(ATH8032_PHY_ID),
Hi
I've worked with this PHY quite often and we've hacked together some support
for the CDT in uboot.
Have you done any tests with the cable on the other side being plugged in?
With the cable being plugged in, we something (1 out of 10 or so) observed that
the test returns with a failure.
--> AT803X_CDT_STATUS_STAT_FAIL in AT803X_CDT_STATUS
Often you get the correct result if you simply try again. Sometimes however it
gets into a "stuck" state where it just
returns FAIL for ~3~10 seconds. After some that it seems to recover and gets
the correct result again.
BR
Matthias
From: Matthias Brugger
Depending on the HW, the maximal usable DMA burst size can vary.
If not set accordingly a timeout in the transmit queue happens and no
package can be sent. Read to optional max-burst-sz property, if not
present, fallback to the standard value.
Signed-off-by: Matthias
On 19/09/2019 16:44, Greg Kroah-Hartman wrote:
> On Thu, Sep 19, 2019 at 04:39:28PM +0200, Matthias May wrote:
>> On 19/09/2019 16:05, Or Gerlitz wrote:
>>> Hi Greg,
>>>
>>> If this is RTFM could you please point me to the Emm
>>>
>>> AFAIR if
lways contains a notice that
this release is now EOL.
I reference all these messages for each version.
BR
Matthias
On 28/08/2019 21:56, David Miller wrote:
> From: Matthias Brugger
> Date: Wed, 28 Aug 2019 11:29:45 +0200
>
>> Thanks for taking this patch. For the next time, please make sure that dts[i]
>> patches are independent from the binding description, as dts[i] should go
&
> arch/arm64/boot/dts/mediatek/mt7622.dtsi | 1 -
> 3 files changed, 19 insertions(+), 12 deletions(-)
Thanks for taking this patch. For the next time, please make sure that dts[i]
patches are independent from the binding description, as dts[i] should go
through my tree. No prob
Hi Florian,
On Wed, Jul 10, 2019 at 09:28:39AM -0700, Florian Fainelli wrote:
> On 7/10/19 8:55 AM, Rob Herring wrote:
> > On Wed, Jul 3, 2019 at 5:23 PM Matthias Kaehlcke wrote:
> >>
> >> Hi Florian,
> >>
> >> On Wed, Jul 03, 2019 at 02:37:47PM -070
ach and also
> can be reached from their parent device, other virtual devices and from
> outside, then please guide me to the right direction or provide links.
> Would be much appreciated.
> Otherwise I would like to see IP-Aliasing for IPv6.
>
> Hope to stimulate further though
uot;)
Link: https://github.com/ClangBuiltLinux/linux/issues/378
Signed-off-by: Matthias Maennich
---
net/sctp/chunk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sctp/chunk.c b/net/sctp/chunk.c
index 64bef313d436..5cb7c1ff97e9 100644
--- a/net/sctp/chunk.c
+++ b/net/sctp/chun
Add HCI_QUIRK_USE_BDADDR_PROPERTY to allow controllers to retrieve
the public Bluetooth address from the firmware node property
'local-bd-address'. If quirk is set and the property does not exist
or is invalid the controller is marked as unconfigured.
Signed-off-by: Matthias Kaehlcke
R
Use the HCI_QUIRK_USE_BDADDR_PROPERTY quirk to let the HCI
core handle the reading of 'local-bd-address'. With this there
is no need to set HCI_QUIRK_INVALID_BDADDR, the case of a
non-existing or invalid fwnode property is handled by the core
code.
Signed-off-by: Matthias Kaehlcke
R
ress'.
To avoid redundant open-coded reading of 'local-bd-address' and error
handling this series adds the quirk HCI_QUIRK_USE_BDADDR_PROPERTY to
retrieve the BD address of a device from the DT and adapts the
btqcomsmd and hci_qca drivers to use this quirk.
Matthias Kaehlcke (3):
Set quirk for wcn3990 to read BD_ADDR from a firmware node property.
Signed-off-by: Matthias Kaehlcke
Tested-by: Balakrishna Godavarthi
---
Changes in v4:
-none
Changes in v3:
- none
Changes in v2:
- patch added to the series
---
drivers/bluetooth/hci_qca.c | 1 +
1 file changed, 1 insertion
Hi Marcel,
On Mon, Feb 18, 2019 at 11:48:21AM +0100, Marcel Holtmann wrote:
> Hi Matthias,
>
> > [initial post: https://lore.kernel.org/patchwork/cover/1028184/]
> >
> > On some systems the Bluetooth Device Address (BD_ADDR) isn't stored
> > on the Bluetoot
nd hci_qca drivers to use this quirk.
Matthias Kaehlcke (3):
Bluetooth: Add quirk for reading BD_ADDR from fwnode property
Bluetooth: btqcomsmd: use HCI_QUIRK_USE_BDADDR_PROPERTY
Bluetooth: hci_qca: Set HCI_QUIRK_USE_BDADDR_PROPERTY for wcn3990
drivers/bluetooth/btqcomsmd.c | 29 +++
Use the HCI_QUIRK_USE_BDADDR_PROPERTY quirk to let the HCI
core handle the reading of 'local-bd-address'. With this there
is no need to set HCI_QUIRK_INVALID_BDADDR, the case of a
non-existing or invalid fwnode property is handled by the core
code.
Signed-off-by: Matthias Kaehlcke
R
Add HCI_QUIRK_USE_BDADDR_PROPERTY to allow controllers to retrieve
the public Bluetooth address from the firmware node property
'local-bd-address'. If quirk is set and the property does not exist
or is invalid the controller is marked as unconfigured.
Signed-off-by: Matthias Kaehlcke
R
Set quirk for wcn3990 to read BD_ADDR from a firmware node property.
Signed-off-by: Matthias Kaehlcke
Tested-by: Balakrishna Godavarthi
---
Changes in v3:
- none
Changes in v2:
- patch added to the series
---
drivers/bluetooth/hci_qca.c | 1 +
1 file changed, 1 insertion(+)
diff --git a
On Fri, Dec 28, 2018 at 02:05:44PM -0800, Matthias Kaehlcke wrote:
> Add HCI_QUIRK_USE_BDADDR_PROPERTY to allow controllers to retrieve
> the public Bluetooth address from the firmware node property
> 'local-bd-address'. If quirk is set and the property does not exist
cquire
the parent lock => BH context
Fixes: e16337622016 ("Bluetooth: Handle bt_accept_enqueue() socket atomically")
Signed-off-by: Matthias Kaehlcke
---
Changes in v2:
- use parameter in bt_accept_enqueue() to decide which lock to
acquire and adapt all callers
- updated co
ress'.
To avoid redundant open-coded reading of 'local-bd-address' and error
handling this series adds the quirk HCI_QUIRK_USE_BDADDR_PROPERTY to
retrieve the BD address of a device from the DT and adapts the
btqcomsmd and hci_qca drivers to use this quirk.
Matthias Kaehlcke (3):
Add HCI_QUIRK_USE_BDADDR_PROPERTY to allow controllers to retrieve
the public Bluetooth address from the firmware node property
'local-bd-address'. If quirk is set and the property does not exist
or is invalid the controller is marked as unconfigured.
Signed-off-by: Matthias Kaehlcke
R
Use the HCI_QUIRK_USE_BDADDR_PROPERTY quirk to let the HCI
core handle the reading of 'local-bd-address'. With this there
is no need to set HCI_QUIRK_INVALID_BDADDR, the case of a
non-existing or invalid fwnode property is handled by the core
code.
Signed-off-by: Matthias Kaehlcke
R
Set quirk for wcn3990 to read BD_ADDR from a firmware node property.
Signed-off-by: Matthias Kaehlcke
Tested-by: Balakrishna Godavarthi
---
Changes in v3:
- none
Changes in v2:
- patch added to the series
tested with https://lore.kernel.org/patchwork/patch/1003830
("Bluetooth: hci_qca
uirk is set and the property does not exist
> > or is invalid the controller is marked as unconfigured.
> >
> > Signed-off-by: Matthias Kaehlcke
> > Reviewed-by: Balakrishna Godavarthi
> > Tested-by: Balakrishna Godavarthi
> > ---
> > Changes in v2:
> &
Use the HCI_QUIRK_USE_BDADDR_PROPERTY quirk to let the HCI
core handle the reading of 'local-bd-address'. With this there
is no need to set HCI_QUIRK_INVALID_BDADDR, the case of a
non-existing or invalid fwnode property is handled by the core
code.
Signed-off-by: Matthias Kaehlcke
R
Set quirk for wcn3990 to read BD_ADDR from a firmware node property.
Signed-off-by: Matthias Kaehlcke
Tested-by: Balakrishna Godavarthi
---
Changes in v2:
- patch added to the series
tested with https://lore.kernel.org/patchwork/patch/1003830
("Bluetooth: hci_qca: Add helper to set d
nel.org/patchwork/project/lkml/list/?series=370982
Matthias Kaehlcke (3):
Bluetooth: Add quirk for reading BD_ADDR from fwnode property
Bluetooth: btqcomsmd: use HCI_QUIRK_USE_BDADDR_PROPERTY
Bluetooth: hci_qca: Set HCI_QUIRK_USE_BDADDR_PROPERTY for wcn3990
drivers/b
Add HCI_QUIRK_USE_BDADDR_PROPERTY to allow controllers to retrieve
the public Bluetooth address from the firmware node property
'local-bd-address'. If quirk is set and the property does not exist
or is invalid the controller is marked as unconfigured.
Signed-off-by: Matthias Kaehlcke
R
g" is odd.
>
Like John I don't think that the word "fuck" is something we have to ban from
the source code, but I don't care too much. Anyway, please don't change it to
something like heck as it might be difficult for non-english speaker to
understand.
Regards,
Dear Friend,
Mr. john Matthias ouedraogo, the manager in charge of auditing and accounting
section
of Bank of Africa (BOA) Ouagadougou Burkina-Faso West-Africa. I would like you
to indicate your interest to receive the transfer of $19.3 Million Dollars. I
will like you to stand as the next of
Hi Sean,
On Fri, May 18, 2018 at 03:07:27PM +0100, Sean Young wrote:
> The kernel IR decoders (drivers/media/rc/ir-*-decoder.c) support the most
> widely used IR protocols, but there are many protocols which are not
> supported[1]. For example, the lirc-remotes[2] repo has over 2700 remotes,
> man
disabling all.accept_ra would preclude users from explicitly enabling
accept_ra on individual interfaces.
Signed-off-by: Matthias Schiffer
---
net/ipv6/Kconfig| 12
net/ipv6/addrconf.c | 2 +-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/Kconfig b/net
disabling all.accept_ra would preclude users from explicitly enabling
accept_ra on individual interfaces.
Signed-off-by: Matthias Schiffer
---
net/ipv6/Kconfig| 12
net/ipv6/addrconf.c | 2 +-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/Kconfig b/net
The driver implementation returns support for private flags, while
no private flags are present. When asked for the number of private
flags it returns the number of statistic flag names.
Fix this by returning EOPNOTSUPP for not implemented ethtool flags.
Signed-off-by: Matthias Brugger
following warning:
drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c:304:13:
error: explicitly assigning value of variable of type 'u32'
(aka 'unsigned int') to itself [-Werror,-Wself-assign]
writeVal = writeVal;
Delete the branch with the self-assignment.
Signed-off-b
El Wed, Feb 07, 2018 at 02:35:59PM -0600 Larry Finger ha dit:
> On 02/07/2018 02:26 PM, Matthias Kaehlcke wrote:
> > In _rtl92c_get_txpower_writeval_by_regulatory() the variable writeVal
> > is assigned to itself in an if ... else statement, apparently only to
> > doc
l serves to
document the 'handling' of the branch condition.
Signed-off-by: Matthias Kaehlcke
---
drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c
b/driver
Leaving a variable with a generic name such as TARGETS undefined would lead
to Make picking up its value from the environment. Avoid this by always
defining TARGETS in the Makefiles.
Signed-off-by: Matthias Schiffer
---
I also noticed that many Makefiles refer to a variable LIBS, which is
On 12/14/2017 01:31 AM, Stefano Brivio wrote:
> On Thu, 14 Dec 2017 01:25:40 +0100
> Matthias Schiffer wrote:
>
>> On 12/14/2017 01:10 AM, Stefano Brivio wrote:
>>> On Thu, 14 Dec 2017 00:57:32 +0100
>>> Matthias Schiffer wrote:
>>>
>>>
On 12/14/2017 01:10 AM, Stefano Brivio wrote:
> On Thu, 14 Dec 2017 00:57:32 +0100
> Matthias Schiffer wrote:
>
>> As you note, there is another occurrence of this calculation in
>> vxlan_config_apply():
>>
>>
>> [...]
>> if (lowerdev) {
&
ax_mtu = lowerdev->mtu - (use_ipv6 ? VXLAN6_HEADROOM :
VXLAN_HEADROOM);
}
if (dev->mtu > max_mtu)
dev->mtu = max_mtu;
[...]
Unless I'm overlooking something, this should already do the same thing and
your
ere is that zero-copy only occurs if the RX-queue number
> match (XDP operating at driver ring level could know), meaning that NIC
> HW filter setup could happen async (but premapping userspace pages
> still have to happen upfront, before starting app/socket).
>
I see, a more sophisti
p?
Wouldn't that be key for massive parallelization either - With having a
queue(producer), a CPU (consumer) - vice versa - per flow at the
extreme? Did this end up in this SMART-NIC thingummy? The latter is
rather trageted at XDP, no?
--
Besten Gruß
Matthias Tafelmeier
0x8ADF34
Signed-off-by: Matthias Schiffer
---
drivers/net/wireless/ath/ath9k/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/Makefile
b/drivers/net/wireless/ath/ath9k/Makefile
index 36a40ffdce15..90e4a341076c 100644
--- a/drivers/net/wireless
th10k hardware.
Signed-off-by: Matthias Schiffer
---
checkpatch.pl wants me to write a more meaningful description for
ATH10K_SPECTRAL, but I don't actually know enough about the spectral scan
feature to do so...
drivers/net/wireless/ath/ath10k/Kconfig| 9 -
drivers/net/wi
routers, where we'd rather like to avoid the code size and RAM usage of the
relay support.
Signed-off-by: Matthias Schiffer
---
drivers/net/wireless/ath/ath9k/Kconfig | 14 ++
drivers/net/wireless/ath/ath9k/Makefile | 4 ++--
drivers/net/wireless/ath/ath9k/c
El Mon, Oct 09, 2017 at 12:41:53PM -0700 Matthias Kaehlcke ha dit:
> From: Behan Webster
>
> Convert Variable Length Array in Struct (VLAIS) to valid C by converting
> local struct definition to use a flexible array. The structure is only
> used to define a cast of a buffer so
El Tue, Oct 24, 2017 at 10:03:56AM -0700 Jakub Kicinski ha dit:
> On Tue, 24 Oct 2017 09:56:03 -0700, Matthias Kaehlcke wrote:
> > > @@ -561,6 +568,6 @@ int __nfp_eth_set_speed(struct nfp_nsp *nsp, unsigned
> > > int speed)
> > > */
> > > int __nfp_eth_
_STATE_RATE, rate,
> NSP_ETH_CTRL_SET_RATE);
> }
> @@ -561,6 +568,6 @@ int __nfp_eth_set_speed(struct nfp_nsp *nsp, unsigned int
> speed)
> */
> int __nfp_eth_set_split(struct nfp_nsp *nsp, unsigned int lanes)
> {
> - return nfp_eth_set_bit_config(nsp, NSP_ETH_RAW_PORT, NSP_ETH_PORT_LANES,
> + return NFP_ETH_SET_BIT_CONFIG(nsp, NSP_ETH_RAW_PORT, NSP_ETH_PORT_LANES,
> lanes, NSP_ETH_CTRL_SET_LANES);
> }
Do you plan to send this as an official patch?
Thanks
Matthias
-off-by: Mark Charebois
Suggested-by: Arnd Bergmann
Signed-off-by: Matthias Kaehlcke
---
drivers/net/wimax/i2400m/fw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wimax/i2400m/fw.c b/drivers/net/wimax/i2400m/fw.c
index c9c711dcd0e6..a89b5685e68b 100644
--- a
17:38:22 -0700, Manoj Gupta wrote:
> >> >> On Wed, Oct 4, 2017 at 4:25 PM, Jakub Kicinski wrote:
> >> >> > On Wed, 4 Oct 2017 16:16:49 -0700, Matthias Kaehlcke wrote:
> >> >> >> > > Thanks for the suggestion. This seems a viable alte
Hi Jakub,
El Wed, Oct 04, 2017 at 03:22:03PM -0700 Jakub Kicinski ha dit:
> On Wed, 4 Oct 2017 11:49:57 -0700, Matthias Kaehlcke wrote:
> > Hi Joe,
> >
> > El Wed, Oct 04, 2017 at 11:07:19AM -0700 Joe Perches ha dit:
> >
> > > On Tue, 2017-10-03 at
Hi Joe,
El Wed, Oct 04, 2017 at 11:07:19AM -0700 Joe Perches ha dit:
> On Tue, 2017-10-03 at 13:05 -0700, Matthias Kaehlcke wrote:
> > nfp_eth_set_bit_config() is marked as __always_inline to allow gcc to
> > identify the 'mask' parameter as known to be constant at c
El Wed, Oct 04, 2017 at 11:17:24AM -0700 Jakub Kicinski ha dit:
> On Wed, 4 Oct 2017 10:42:42 -0700, Manoj Gupta wrote:
> > Hi Jakub,
> >
> > I had discussed about supporting this code with some clang developers.
> > However, the consensus was this code relies on a specific GCC optimizer
> > beha
El Tue, Oct 03, 2017 at 02:50:00PM -0700 Jakub Kicinski ha dit:
> On Tue, 3 Oct 2017 13:05:46 -0700, Matthias Kaehlcke wrote:
> > nfp_eth_set_bit_config() is marked as __always_inline to allow gcc to
> > identify the 'mask' parameter as known to be constant at compile ti
ask' as a compile time constant.
Signed-off-by: Matthias Kaehlcke
---
I am aware that a lengthy macro is not a pretty solution, I'm open for
better suggestions.
Note: The patch has been build-tested only since I don't have any NFP
hardware.
.../ethernet/netronome/nfp/nfpcore/nfp_
switch ports (in ovs) as
"protected" which prevents looping them back between (even when flooding) see
[1].
I'm not sure if the bridge has a similar feature.
BR
Matthias
[1]http://openvswitch.org/support/dist-docs/ovs-vswitchd.conf.db.5.txt ctrl-f:
"protected: boolean"
original msg: "invalid all zero
> ethernet address"
It is inaccurate though, is_valid_ether_addr will also reject multicast
addresses.
Matthias
signature.asc
Description: OpenPGP digital signature
lue.
Signed-off-by: Matthias Kaehlcke
---
net/core/netpoll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 8357f164c660..912731bed7b7 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -666,7 +666,7 @@ int netpoll_setup(str
On 07/07/2017 09:11 AM, Gustavo A. R. Silva wrote:
Check return value from call to of_match_device()
in order to prevent a NULL pointer dereference.
In case of NULL print error message and return -ENODEV
Signed-off-by: Gustavo A. R. Silva
---
Reviewed-by: Matthias Brugger
drivers/net
copy_to_user() copies the struct the pointer is pointing to, but the
length check compares against sizeof(pointer) and not sizeof(struct).
On 32-bit the size is probably the same, so it might have worked
accidentally.
Signed-off-by: Matthias Rosenfelder
---
net/tls/tls_main.c | 2 +-
1 file
header
to userspace?
Thanks.
Best Regards,
Matthias
t;
> Fixes: a985343ba906 ("vxlan: refactor verification and application of
> configuration")
> Signed-off-by: Sabrina Dubroca
Thanks for fixing this up, I really didn't expect dev_net() not to return
the correct net in setup().
Reviewed-by: Matthias Schiffer
> -
icast addresses), and
add messages for the remaining attributes.
Signed-off-by: Matthias Schiffer
---
drivers/net/vxlan.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index fd0ff97e3d81..01957e39f2cd 100644
When refactoring the vxlan config validation, some kernel log messages were
removed. This brings them back using the new netlink_ext_ack support, and
adds some more in the recently added code handling link-local IPv6
addresses.
Signed-off-by: Matthias Schiffer
---
drivers/net/vxlan.c | 43
The access to the wrong variable could lead to a NULL dereference and
possibly other invalid memory reads in vxlan newlink/changelink requests
with a IFLA_MTU attribute.
Fixes: a985343ba906 "vxlan: refactor verification and application of
configuration"
Signed-off-by: Matthia
On 06/26/2017 03:33 PM, David Ahern wrote:
> On 6/26/17 2:43 AM, Matthias Schiffer wrote:
>> On 06/26/2017 06:08 AM, David Ahern wrote:
>>> On 6/25/17 10:04 PM, David Ahern wrote:
>>>> On 6/25/17 3:56 PM, Matthias Schiffer wrote:
>>>>> Add support for
On 06/26/2017 06:08 AM, David Ahern wrote:
> On 6/25/17 10:04 PM, David Ahern wrote:
>> On 6/25/17 3:56 PM, Matthias Schiffer wrote:
>>> Add support for extended error reporting.
>>>
>>> Signed-off-by: Matthias Schiffer
>>> ---
>>
>>
>&g
Add support for extended error reporting.
Signed-off-by: Matthias Schiffer
---
drivers/infiniband/ulp/ipoib/ipoib_netlink.c | 3 ++-
drivers/net/bonding/bond_netlink.c | 3 ++-
drivers/net/caif/caif_hsi.c | 3 ++-
drivers/net/can/dev.c| 3
Same changes as http://patchwork.ozlabs.org/patch/780351/ , split into
separate patches for each rtnl_link_ops field as requested.
Matthias Schiffer (5):
net: add netlink_ext_ack argument to rtnl_link_ops.newlink
net: add netlink_ext_ack argument to rtnl_link_ops.changelink
net: add
Add support for extended error reporting.
Signed-off-by: Matthias Schiffer
---
drivers/net/bonding/bond_netlink.c | 3 ++-
drivers/net/can/dev.c | 3 ++-
drivers/net/dummy.c| 3 ++-
drivers/net/geneve.c | 3 ++-
drivers/net/gtp.c | 3
1 - 100 of 296 matches
Mail list logo
