- 19 Nov, 2019 2 commits
-
-
Dan Carpenter authored
We used to take a lock in amp_physical_cfm() but then we moved it to the caller function. Unfortunately the unlock on this error path was overlooked so it leads to a double unlock. Fixes: a514b17f ("Bluetooth: Refactor locking in amp_physical_cfm") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Stephan Gerhold authored
Add the device ID for the WiFi/BT/FM combo chip BCM4334 (rev B0). The chip seems to use 43:34:b0:00:00:00 as default address, so add it to the list of default addresses and leave it up to the user to configure a valid one. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
- 15 Nov, 2019 1 commit
-
-
Oliver Neukum authored
If setup() fails a reference for runtime PM has already been taken. Proper use of the error handling in btusb_open()is needed. You cannot just return. Fixes: ace31982 ("Bluetooth: btusb: Add setup callback for chip init on USB") Signed-off-by: Oliver Neukum <oneukum@suse.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
- 13 Nov, 2019 22 commits
-
-
David S. Miller authored
Stefan Wahren says: ==================== ARM: Enable GENET support for RPi 4 Raspberry Pi 4 uses the broadcom genet chip in version five. This chip has a dma controller integrated. Up to now the maximal burst size was hard-coded to 0x10. But it turns out that Raspberry Pi 4 does only work with the smaller maximal burst size of 0x8. Additionally the patch series has some IRQ retrieval improvements and adds support for a missing PHY mode. This series based on Matthias Brugger's V1 series [1]. [1] - https://patchwork.kernel.org/cover/11186193/ Changes in V5: - address Doug's comment Changes in V4: - rebased on current net-next - remove RGMII_ID support - remove fixes tag from patch 1 - add Florian's suggestions to patch 5 Changes in V3: - introduce SoC-specific compatibles for GENET (incl. dt-binding) - use platform_get_irq_optional for optional IRQ - remove Fixes tag from IRQ error handling change - move most of MDIO stuff to bcm2711.dtsi Changes in V2: - add 2 fixes for IRQ retrieval - add support for missing PHY modes - declare PHY mode RGMII RXID based on the default settings - add alias to allow firmware append the MAC address ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stefan Wahren authored
This adds the missing support for the PHY mode RGMII_RXID. It's necessary for the Raspberry Pi 4. Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stefan Wahren authored
The register access in bcmgenet_mii_config() is a little bit opaque and not easy to extend. In preparation for the missing RGMII PHY modes move all the phy name assignments into the switch statement and the register access to the end of the function. This make the code easier to read and extend. Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stefan Wahren authored
The BCM2711 needs a different maximum DMA burst length. If not set accordingly a timeout in the transmit queue happens and no package can be sent. So use the new compatible to derive this value. Until now the GENET HW version was used as the platform identifier. This doesn't work with SoC-specific modifications, so introduce a proper platform data structure. Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Matthias Brugger <mbrugger@suse.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stefan Wahren authored
The BCM2711 has some modifications to the GENET v5. So add this SoC specific compatible. Suggested-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stefan Wahren authored
This fixes the error handling for the mandatory IRQs. There is no need for the error message anymore, this is now handled by platform_get_irq. Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stefan Wahren authored
As platform_get_irq() now prints an error when the interrupt does not exist, we are getting a confusing error message in case the optional WOL IRQ is not defined: bcmgenet fd58000.ethernet: IRQ index 2 not found Fix this by using the platform_get_irq_optional(). Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
Sometimes it can be quite opaque even for me why the driver decided to reset the switch. So instead of adding dump_stack() calls each time for debugging, just add a reset reason to sja1105_static_config_reload calls which gets printed to the console. Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Matthias Schiffer says: ==================== Implement get_link_ksettings for VXLAN and bridge Mesh routing protocol batman-adv (in particular the new BATMAN_V algorithm) uses the link speed reported by get_link_ksettings to determine a path metric for wired links. In the mesh framework Gluon [1], we layer VXLAN and sometimes bridge interfaces on our Ethernet links. These patches implement get_link_ksettings for these two interface types. While this is obviously not accurate for bridges with multiple active ports, it's much better than having no estimate at all (and in the particular setup of Gluon, bridges with a single port aren't completely uncommon). [1] https://github.com/freifunk-gluon/gluon ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Matthias Schiffer authored
We return the maximum speed of all active ports. This matches how the link speed would give an upper limit for traffic to/from any single peer if the bridge were replaced with a hardware switch. Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Matthias Schiffer authored
Similar to VLAN and similar drivers, we can forward get_link_ksettings to the lower dev if we have one to get meaningful speed/duplex data. Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
It is possible for a switch driver to use NET_DSA_TAG_8021Q as a valid DSA tagging protocol since it registers itself as such, unfortunately since there are not xmit or rcv functions provided, the lack of a xmit() function will lead to a NPD in dsa_slave_xmit() to start with. net/dsa/tag_8021q.c is only comprised of a set of helper functions at the moment, but is not a fully autonomous or functional tagging "driver" (though it could become later on). We do not have any users of NET_DSA_TAG_8021Q so now is a good time to make sure there are not issues being encountered by making this file strictly a place holder for helper functions. Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Hoang Le authored
In commit 25b0b9c4 ("tipc: handle collisions of 32-bit node address hash values"), the 32-bit node address only generated after one second trial period expired. However the self's addr in struct tipc_monitor do not update according to node address generated. This lead to it is always zero as initial value. As result, sorting algorithm using this value does not work as expected, neither neighbor monitoring framework. In this commit, we add a fix to update self's addr when 32-bit node address generated. Fixes: 25b0b9c4 ("tipc: handle collisions of 32-bit node address hash values") Acked-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Pablo Neira Ayuso says: ==================== netfilter flowtable hardware offload The following patchset adds hardware offload support for the flowtable infrastructure [1]. This infrastructure provides a fast datapath for the classic Linux forwarding path that users can enable through policy, eg. table inet x { flowtable f { hook ingress priority 10 devices = { eth0, eth1 } flags offload } chain y { type filter hook forward priority 0; policy accept; ip protocol tcp flow offload @f } } This example above enables the fastpath for TCP traffic between devices eth0 and eth1. Users can turn on the hardware offload through the 'offload' flag from the flowtable definition. If this new flag is not specified, the software flowtable datapath is used. This patchset is composed of 4 preparation patches: room to extend this infrastructure, eg. accelerate bridge forwarding. And 2 patches to add the hardware offload control and data planes: hardware offload. This includes a new NFTA_FLOWTABLE_FLAGS netlink attribute to convey the optional NF_FLOWTABLE_HW_OFFLOAD flag. API available at net/core/flow_offload.h to represent the flow through two flow_rule objects to configure an exact 5-tuple matching on each direction plus the corresponding forwarding actions, that is, the MAC address, NAT and checksum updates; and port redirection in order to configure the hardware datapath. This patch only supports for IPv4 support and statistics collection for flow aging as an initial step. This patchset introduces a new flow_block callback type that needs to be set up to configure the flowtable hardware offload. The first client of this infrastructure follows up after this batch. I would like to thank Mellanox for developing the first upstream driver to use this infrastructure. [1] Documentation/networking/nf_flowtable.txt ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Pablo Neira Ayuso authored
This patch adds the dataplane hardware offload to the flowtable infrastructure. Three new flags represent the hardware state of this flow: * FLOW_OFFLOAD_HW: This flow entry resides in the hardware. * FLOW_OFFLOAD_HW_DYING: This flow entry has been scheduled to be remove from hardware. This might be triggered by either packet path (via TCP RST/FIN packet) or via aging. * FLOW_OFFLOAD_HW_DEAD: This flow entry has been already removed from the hardware, the software garbage collector can remove it from the software flowtable. This patch supports for: * IPv4 only. * Aging via FLOW_CLS_STATS, no packet and byte counter synchronization at this stage. This patch also adds the action callback that specifies how to convert the flow entry into the flow_rule object that is passed to the driver. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Pablo Neira Ayuso authored
This patch adds the NFTA_FLOWTABLE_FLAGS attribute that allows users to specify the NF_FLOWTABLE_HW_OFFLOAD flag. This patch also adds a new setup interface for the flowtable type to perform the flowtable offload block callback configuration. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Pablo Neira Ayuso authored
This patch adds the infrastructure to support for flow entry types. The initial type is NF_FLOW_OFFLOAD_ROUTE that stores the routing information into the flow entry to define a fastpath for the classic forwarding path. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Pablo Neira Ayuso authored
Move rcu_head to struct flow_offload, then remove the flow_offload_entry structure definition. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Pablo Neira Ayuso authored
Drivers do not have access to the flow_offload structure, hence remove this union from this flow_offload object as well as the original comment on top of it. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Pablo Neira Ayuso authored
Simplify this code by storing the pointer to conntrack object in the flow_offload structure. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Roman Mashak authored
Added tests for 'cmp' extended match rules. Signed-off-by: Roman Mashak <mrv@mojatatu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next Johan Hedberg says: ==================== pull request: linux-bluetooth 2019-11-11 Here's one more bluetooth-next pull request for the 5.5 kernel release. - Several fixes for LE advertising - Added PM support to hci_qca driver - Added support for WCN3991 SoC in hci_qca driver - Added DT bindings for BCM43540 module - A few other small cleanups/fixes ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 12 Nov, 2019 15 commits
-
-
David S. Miller authored
Merge tag 'linux-can-next-for-5.5-20191111' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2019-10-07 this is a pull request for net-next/master consisting of 32 patches. The first patch is by Gustavo A. R. Silva and removes unused code in the generic CAN infrastructure. The next three patches target the mcp251x driver. The one by Andy Shevchenko removes the legacy platform data support from the driver. The other two are by Timo Schlüßler and reset the device only when needed, to prevent glitches on the output when GPIO support is added. I'm contributing two patches fixing checkpatch warnings in the c_can_platform and peak_canfd driver. Stephane Grosjean's patch for the peak_canfd driver adds hw timestamps support in rx skbs. The next three patches target the xilinx_can driver. One patch by me to fix checkpatch warnings, one patch by Anssi Hannula to avoid non requested bus error frames, and a patch by YueHaibing that switches the driver to devm_platform_ioremap_resource(). Pankaj Sharma contributes two patches for the m_can driver, the first one adds support for one shot mode, the other support for handling arbitration errors. Followed by four patches by YueHaibing, switching the grcan, ifi, rcar, and sun4i drivers to devm_platform_ioremap_resource() I'm contributing cleanup patches for the rx-offload helper, while Joakim Zhang's patch prepares the rx-offload helper for CAN-FD support. The rx offload users flexcan and ti_hecc are converted accordingly. The remaining twelve patches target the flexcan driver. First Joakim Zhang switches the driver to devm_platform_ioremap_resource(). The remaining eleven patch are by me and clean up the abstract the access of the iflag1 and iflag2 register both for RX and TX mailboxes. This is a preparation for the upcoming CAN-FD support. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Arthur Fabre authored
The sfc driver can drop packets processed with XDP, notably when running out of buffer space on XDP_TX, or returning an unknown XDP action. This increments the rx_xdp_bad_drops ethtool counter. Call trace_xdp_exception everywhere rx_xdp_bad_drops is incremented, except for fragmented RX packets as the XDP program hasn't run yet. This allows it to easily be monitored from userspace. This mirrors the behavior of other drivers. Signed-off-by: Arthur Fabre <afabre@cloudflare.com> Acked-by: Edward Cree <ecree@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
YueHaibing authored
When do randbuilding, we got this warning: WARNING: unmet direct dependencies detected for PTP_1588_CLOCK Depends on [n]: NET [=y] && POSIX_TIMERS [=n] Selected by [y]: - PTP_1588_CLOCK_IDTCM [=y] Make PTP_1588_CLOCK_IDTCM depends on PTP_1588_CLOCK to fix this. Fixes: 3a6ba7dc ("ptp: Add a ptp clock driver for IDT ClockMatrix.") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Reviewed-by: Vincent Cheng <vincent.cheng.xh@renesas.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Davide Caratti authored
after commit 4097e9d2 ("net: sched: don't use tc_action->order during action dump"), 'act->order' is initialized but then it's no more read, so we can just remove this member of struct tc_action. CC: Ivan Vecera <ivecera@redhat.com> Signed-off-by: Davide Caratti <dcaratti@redhat.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Ivan Vecera <ivecera@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Colin Ian King authored
There is a stray semicolon in an if statement that will cause a dev_err message to be printed unconditionally. Fix this by removing the stray semicolon. Addresses-Coverity: ("Stay semicolon") Fixes: f0942e00 ("net: dsa: mv88e6xxx: Add support for port mirroring") Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Aya Levin says: ==================== Update devlink binary output This series changes the devlink binary interface: -The first patch forces binary values to be enclosed in an array. In addition, devlink_fmsg_binary_pair_put breaks the binary value into chunks to comply with devlink's restriction for value length. -The second patch removes redundant code and uses the fixed devlink interface (devlink_fmsg_binary_pair_put). -The third patch make self test to use the updated devlink interface. -The fourth, adds a verification of dumping a very large binary content. This test verifies breaking the data into chunks in a valid JSON output. Series was generated against net-next commit: ca22d697 Merge branch 'stmmac-next' ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Aya Levin authored
Add a test of 2 PAGEs size (exceeds devlink previous length limitation) of binary data on a 'devlink health dump show' command. Set binary length to 8192, issue a dump show command and clear it. Signed-off-by: Aya Levin <ayal@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Aya Levin authored
Update dummy reporter's output to use updated devlink interface of binary fmsg pair. Signed-off-by: Aya Levin <ayal@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Aya Levin authored
Remove redundant code from fw_fatal reporter's dump callback. Use updated devlink interface of binary fmsg pair which breaks the output into chunks internally. Signed-off-by: Aya Levin <ayal@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Acked-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Aya Levin authored
Devlink supports pair output of name and value. When the value is binary, it must be presented in an array. If the length of the binary value exceeds fmsg limitation, break the value into chunks internally. Signed-off-by: Aya Levin <ayal@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Russell King authored
When building with SFP disabled, the stub for sfp_bus_add_upstream() missed "inline". Add it. Fixes: 727b3668 ("net: sfp: rework upstream interface") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
zhengbin authored
Fix sparse warnings: drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_mqprio.c:242:6: warning: symbol 'cxgb4_mqprio_free_hw_resources' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: 2d0cb84d ("cxgb4: add ETHOFLD hardware queue support") Signed-off-by: zhengbin <zhengbin13@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
zhengbin says: ==================== net: atlantic: make some symbol & function static v1->v2: add Fixes tag ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
zhengbin authored
Fix sparse warnings: drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c:706:5: warning: symbol 'aq_ethtool_get_priv_flags' was not declared. Should it be static? drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c:713:5: warning: symbol 'aq_ethtool_set_priv_flags' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: ea4b4d7f ("net: atlantic: loopback tests via private flags") Signed-off-by: zhengbin <zhengbin13@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
zhengbin authored
Fix sparse warnings: drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c:426:25: warning: symbol 'aq_pm_ops' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: 8aaa112a ("net: atlantic: refactoring pm logic") Signed-off-by: zhengbin <zhengbin13@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-