- 20 Aug, 2015 4 commits
-
-
Christophe Ricard authored
skb can be NULL and may lead to a NULL pointer error. Add a check condition before setting HCI rx buffer. Cc: stable@vger.kernel.org Signed-off-by:
Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Robert Baldyga authored
Add driver for Samsung S3FWRN5 NFC controller. S3FWRN5 is using NCI protocol and I2C communication interface. Signed-off-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
-
Robert Baldyga authored
Some drivers needs to have ability to reinit NCI core, for example after updating firmware in setup() of post_setup() callback. This patch makes nci_core_reset() and nci_core_init() functions public, to make it possible. Signed-off-by:
-
Robert Baldyga authored
Some drivers require non-standard configuration after NCI_CORE_INIT request, because they need to know ndev->manufact_specific_info or ndev->manufact_id. This patch adds post_setup handler allowing to do such custom configuration. Signed-off-by:
-
- 19 Aug, 2015 2 commits
-
-
Mark Greer authored
Although it should be unnecessary, add a NULL pointer check to trf7970a_send_upstream() to eliminate a smatch warning. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Mark Greer <mgreer@animalcreek.com> Signed-off-by:
-
Mark Greer authored
The SDD_EN bit in the NFC Target Detection Level Register is bit 5 not bit 3 so change the TRF7970A_NFC_TARGET_LEVEL_SDD_EN macro accordingly. Reported-by:
Raymond Lei <Raymond.Lei@ecolab.com> Signed-off-by:
-
- 17 Aug, 2015 1 commit
-
-
Christophe Ricard authored
When NFC_ATTR_VENDOR_DATA is not set, data_len is 0 and data is NULL. Fixes the following warning: net/nfc/netlink.c:1536:3: warning: 'data' may be used uninitialized +in this function [-Wmaybe-uninitialized] return cmd->doit(dev, data, data_len); Cc: stable@vger.kernel.org Signed-off-by:
-
- 16 Aug, 2015 11 commits
-
-
Christophe Ricard authored
NFC_ATTR_VENDOR_DATA is an optional vendor_cmd argument. The current code was potentially using a non existing argument leading to potential catastrophic results. Cc: stable@vger.kernel.org Signed-off-by:
-
Christophe Ricard authored
spi phy needs to use ndlc_recv at every spi transaction causing "unknown packet control byte" error message each time the header is 00. Make this silent. Signed-off-by:
-
Christophe Ricard authored
Add st-nci-spi phy devicetree documentation Signed-off-by:
-
Christophe Ricard authored
st21nfcb does support another phy than i2c: spi. st21nfcc does not support spi as the spi ios are used by the AMS RF booster. st21nfcb is not following NCI NFC Forum recommendations for spi but rely on ST prioritary protocol ndlc as for i2c. Signed-off-by:
-
Christophe Ricard authored
PCB_SYNC different than PCB_TYPE_SUPERVISOR or PCB_TYPE_DATAFRAME should be discarded. Irrelevant data may be forwarded up to the ndlc state machine by phys like spi to prevent missing potential data during "write" transactions. Cc: stable@vger.kernel.org Signed-off-by:
-
Christophe Ricard authored
When receiving a NDLC PCB_SYNC_ACK the pending data was never removed from ack_pending_q and cleared. Cc: stable@vger.kernel.org Signed-off-by:
-
Christophe Ricard authored
st_nci_hci_load_session() calls kfree_skb() on unitialized variables skb_pipe_info and skb_pipe_list if the call to nci_hci_connect_gate() failed. Reword the error path to not use these variables when they are not initialized. While at it, there seemed to be a memory leak because skb_pipe_info was only freed once, after the for-loop, even though several ones were created by nci_hci_send_cmd. Cc: stable@vger.kernel.org Acked-by:
Nicolas Iooss <nicolas.iooss_linux@m4x.org> Signed-off-by:
-
Christophe Ricard authored
st21nfca_hci_load_session() calls kfree_skb() on unitialized variables skb_pipe_info and skb_pipe_list if the call to nfc_hci_connect_gate() failed. Reword the error path to not use these variables when they are not initialized. While at it, there seemed to be a memory leak because skb_pipe_info was only freed once, after the for-loop, even though several ones were created by nfc_hci_send_cmd. Fixes: ec03ff1a ("NFC: st21nfca: Remove skb_pipe_list and skb_pipe_info useless allocation") Cc: stable@vger.kernel.org Acked-by:
-
Christophe Ricard authored
Due to a copy and paste error st_nci_i2c_read still contains st21nfca header comment. Cc: stable@vger.kernel.org Signed-off-by:
-
Christophe Ricard authored
Replace ST21NFCB with ST_NCI or st21nfcb with st_nci as it was forgotten in commit "nfc: st-nci: Rename st21nfcb to st-nci" ed06aeef Cc: stable@vger.kernel.org Signed-off-by:
-
Christophe Ricard authored
commit "nfc: st-nci: Rename st21nfcb to st-nci" adds include/linux/platform_data/st_nci.h duplicated with include/linux/platform_data/st-nci.h. Only drivers/nfc/st-nci/i2c.c uses platform_data/st_nci.h. Cc: stable@vger.kernel.org Reported-by:
Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by:
-
- 14 Aug, 2015 22 commits
-
-
David S. Miller authored
David Ahern says: ==================== VRF-lite - v6 In the context of internet scale routing a requirement that always comes up is the need to partition the available routing tables into disjoint routing planes. A specific use case is the multi-tenancy problem where each tenant has their own unique routing tables and in the very least need different default gateways. This patch allows the ability to create virtual router domains (aka VRFs (VRF-lite to be specific) in the linux packet forwarding stack. The main observation is that through the use of rules and socket binding to interfaces, all the facilities that we need are already present in the infrastructure. What is missing is a handle that identifies a routing domain and can be used to gather applicable rules/tables and uniqify neighbor selection. The scheme used needs to preserves the notions of ECMP, and general routing principles. This driver is a cross between functionality that the IPVLAN driver and the Team drivers provide where a device is created and packets into/out of the routing domain are shuttled through this device. The device is then used as a handle to identify the applicable rules. The VRF device is thus the layer3 equivalent of a vlan device. The very important point to note is that this is only a Layer3 concept so L2 tools (e.g., LLDP) do not need to be run in each VRF, processes can run in unaware mode or select a VRF to be talking through. Also the behavioral model is a generalized application of the familiar VRF-Lite model with some performance paths that need optimization. (Specifically the output route selector that Roopa, Robert, Thomas and EricB are currently discussing on the MPLS thread) High Level points ================= 1. Simple overlay driver (minimal changes to current stack) * uses the existing fib tables and fib rules infrastructure 2. Modelled closely after the ipvlan driver 3. Uses current API and infrastructure. * Applications can use SO_BINDTODEVICE or cmsg device indentifiers to pick VRF (ping, traceroute just work) * Standard IP Rules work, and since they are aggregated against the device, scale is manageable 4. Completely orthogonal to Namespaces and only provides separation in the routing plane (and ARP) N2 N1 (all configs here) +---------------+ +--------------+ | | |swp1 :10.0.1.1+----------------------+swp1 :10.0.1.2 | | | | | |swp2 :10.0.2.1+----------------------+swp2 :10.0.2.2 | | | +---------------+ | VRF 1 | | table 5 | | | +---------------+ | | | VRF 2 | N3 | table 6 | +---------------+ | | | | |swp3 :10.0.2.1+----------------------+swp1 :10.0.2.2 | | | | | |swp4 :10.0.3.1+----------------------+swp2 :10.0.3.2 | +--------------+ +---------------+ Given the topology above, the setup needed to get the basic VRF functions working would be Create the VRF devices and associate with a table ip link add vrf1 type vrf table 5 ip link add vrf2 type vrf table 6 Install the lookup rules that map table to VRF domain ip rule add pref 200 oif vrf1 lookup 5 ip rule add pref 200 iif vrf1 lookup 5 ip rule add pref 200 oif vrf2 lookup 6 ip rule add pref 200 iif vrf2 lookup 6 ip link set vrf1 up ip link set vrf2 up Enslave the routing member interfaces ip link set swp1 master vrf1 ip link set swp2 master vrf1 ip link set swp3 master vrf2 ip link set swp4 master vrf2 Connected and local routes are automatically moved from main and local tables to the VRF table. ping using VRF0 is simply ping -I vrf0 10.0.1.2 Design Highlights ================= If a device is enslaved to a VRF device (ie., associated with a VRF) then: 1. Rx path The master device index is used as the iif for all lookups. 2. Tx path Similarly, for Tx the VRF device oif is used in the flow to direct lookups to the table associated with the VRF via its rule. From there the FLOWI_FLAG_VRFSRC flag is used to indicate that the oif should not be used for FIB table lookups. 3. Connected and local routes On link up for a device, connected and local routes are added to the table associated with the VRF device, rather than the local and main tables. 4. Socket lookups Sockets operating in the VRF must be bound to the VRF device. As such socket lookups compare the VRF device index to sk_bound_dev_if. 5. Neighbor entries Neighbor entries are not impacted by the VRF device. Entries are associated with a particular interface; the VRF association is indirect via the interface-to-VRF device enslavement. Version 6 - addressed comments from DaveM - added patch to properly set oif in ip_send_unicast_reply. Needs to be set to VRF device for proper FIB lookup - added patch to handle IP fragments Version 5 - dropped patch regarding socket lookups; no longer needed + removed vrf helpers no longer needed after this patch is dropped - removed dev_open and close operations + no need to reset vrf data on an ifdown and creates problems if a slave is deleted while the vrf interface is down (Thanks, Nikolay) - cleanups for sparse warnings + make C=2 is now clean for vrf driver Version 4 - builds are clean with and without VRF device enabled (no, yes and module) - tightened the driver implementation + device add/delete, slave add/remove, and module unload are all clean - fixed RCU references + with RCU and lock debugging enabled changes are clean through the suite of tests - TX path uses custom dst, so patch refactoring rtable allocation is dropped along with the patch adding rt_nexthop helper - dropped the task patch that adds default bind to interface for sockets and the associated chvrf example command + the patches are a convenience for running unmodified code. They are not needed for the core functionality. Any application with support for SO_BINDTODEVICE works properly with this patch set. Version 3 - addressed comments from first 2 RFCs with the exception of the name Nicolas: We will do the name conversion once we agree on what the correct name should be (vrf, mrf or something else) - packets flow through the VRF device in both directions allowing the following: - tcpdump -i vrf<n> - tc rules on vrf device - netfilter rules on vrf device TO-DO ===== 1. IPv6 2. ipsec, xfrms - dst patch accepted into ipsec-next; will post VRF patch once merge happens 3. listen filter to allow 1 socket to work with multiple VRF devices - i.e., bind to VRF's a, b, c only or NOT VRFs e, f, g Eric B: I have ipsec working with VRFs implemented using the VRF driver, including the worst case scenario of complete duplication in the networking config. Thanks to Nikolay for his many, many code reviews whipping the device driver into shape, and bug-Fixes and ideas from Hannes, Roopa Prabhu, Jon Toppins, Jamal. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
David Ahern authored
This driver borrows heavily from IPvlan and teaming drivers. Routing domains (VRF-lite) are created by instantiating a VRF master device with an associated table and enslaving all routed interfaces that participate in the domain. As part of the enslavement, all connected routes for the enslaved devices are moved to the table associated with the VRF device. Outgoing sockets must bind to the VRF device to function. Standard FIB rules bind the VRF device to tables and regular fib rule processing is followed. Routed traffic through the box, is forwarded by using the VRF device as the IIF and following the IIF rule to a table that is mated with the VRF. Example: Create vrf 1: ip link add vrf1 type vrf table 5 ip rule add iif vrf1 table 5 ip rule add oif vrf1 table 5 ip route add table 5 prohibit default ip link set vrf1 up Add interface to vrf 1: ip link set eth1 master vrf1 Signed-off-by:Shrijeet Mukherjee <shm@cumulusnetworks.com> Signed-off-by:
David Ahern <dsa@cumulusnetworks.com> Signed-off-by:
-
David Ahern authored
Fragmentation cache uses information from the IP header to reassemble packets. That information can be duplicated across VRFs -- same source and destination addresses, protocol and id. Handle fragmentation with VRFs by adding the VRF device index to entries in the cache and the lookup arg. Signed-off-by:
-
David Ahern authored
If output device is not specified use VRF device if input device is enslaved. This is needed to ensure tcp acks and resets go out VRF device. Signed-off-by:
-
David Ahern authored
If a user passes in a table for new routes use that table for nexthop lookups. Specifically, this solves the case where a connected route does not exist in the main table, but only another table and then a subsequent route is added with a next hop using the connected route. ie., $ ip route ls default via 10.0.2.2 dev eth0 10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15 169.254.0.0/16 dev eth0 scope link metric 1003 192.168.56.0/24 dev eth1 proto kernel scope link src 192.168.56.51 $ ip route ls table 10 1.1.1.0/24 dev eth2 scope link Without this patch adding a nexthop route fails: $ ip route add table 10 2.2.2.0/24 via 1.1.1.10 RTNETLINK answers: Network is unreachable With this patch the route is added successfully. Signed-off-by:
-
David Ahern authored
When a device associated with a VRF is brought up or down routes should be added to/removed from the table associated with the VRF. fib_magic defaults to using the main or local tables. Have it use the table with the device if there is one. A part of this is directing prefsrc validations to the correct table as well. Signed-off-by:
-
David Ahern authored
Currently inet_addr_type and inet_dev_addr_type expect local addresses to be in the local table. With the VRF device local routes for devices associated with a VRF will be in the table associated with the VRF. Provide an alternate inet_addr lookup to use a specific table rather than defaulting to the local table. inet_addr_type_dev_table keeps the same semantics as inet_addr_type but if the passed in device is enslaved to a VRF then the table for that VRF is used for the lookup. Signed-off-by:
-
David Ahern authored
Currently inet_addr_type and inet_dev_addr_type expect local addresses to be in the local table. With the VRF device local routes for devices associated with a VRF will be in the table associated with the VRF. Provide an alternate inet_addr lookup to use a specific table rather than defaulting to the local table. Signed-off-by:
-
David Ahern authored
For unconnected UDP sockets using a VRF device lookup source address based on VRF table. This allows the UDP header to be properly setup before showing up at the VRF device via the dst. Signed-off-by:
-
David Ahern authored
As with ingress use the index of VRF master device for route lookups on egress. However, the oif should only be used to direct the lookups to a specific table. Routes in the table are not based on the VRF device but rather interfaces that are part of the VRF so do not consider the oif for lookups within the table. The FLOWI_FLAG_VRFSRC is used to control this latter part. Signed-off-by:
-
David Ahern authored
On ingress use index of VRF master device for route lookups if real device is enslaved. Rules are expected to be installed for the VRF device to direct lookups to a specific table. Signed-off-by:
-
David Ahern authored
Add a VRF_MASTER flag for interfaces and helper functions for determining if a device is a VRF_MASTER. Add link attribute for passing VRF_TABLE id. Add vrf_ptr to netdevice. Add various macros for determining if a device is a VRF device, the index of the master VRF device and table associated with VRF device. Signed-off-by:
-
Andy Gospodarek authored
This is useful information to include in ipv6 netlink messages that report interface information. IFLA_OPERSTATE is already included in ipv4 messages, but missing for ipv6. This closes that gap. Signed-off-by:
Andy Gospodarek <gospo@cumulusnetworks.com> Signed-off-by:
-
Sasha Levin authored
Commit 10e4ea75 ("net: Fix race condition in store_rps_map") has moved the manipulation of the rps_needed jump label under a spinlock. Since changing the state of a jump label may sleep this is incorrect and causes warnings during runtime. Make rps_map_lock a mutex to allow sleeping under it. Fixes: 10e4ea75 ("net: Fix race condition in store_rps_map") Signed-off-by:
Sasha Levin <sasha.levin@oracle.com> Acked-by:
Tom Herbert <tom@herbertland.com> Signed-off-by:
-
David S. Miller authored
Vivien Didelot says: ==================== net: dsa: mv88e6xxx: add hardware VLAN support This patchset brings support to access hardware VLAN entries in DSA and mv88e6xxx, through switchdev VLAN objects. In the following example, ports swp[0-2] belong to bridge br0, and ports swp[3-4] belong to bridge br1. Here's an example of what can be achieved after this patchset: # bridge vlan add dev swp1 vid 100 master # bridge vlan add dev swp2 vid 100 master # bridge vlan add dev swp3 vid 100 master # bridge vlan add dev swp4 vid 100 master # bridge vlan del dev swp1 vid 100 master The above commands correctly programmed hardware VLAN 100 for port swp2, while ports swp3 and swp4 use software VLAN 100, as shown with: # bridge vlan port vlan ids swp0 None swp0 swp1 None swp1 swp2 100 swp2 100 swp3 100 swp3 swp4 100 swp4 br0 None br1 None Assuming that port 5 is the CPU port, the hardware VLAN table would contain the following data: VID FID SID 0 1 2 3 4 5 6 100 8 0 x x t x x t x Where 'x' means excluded, and 't' means tagged. Also, adding an FDB entry to VLAN 100 for port swp2 like this: # bridge fdb add 3c:97:0e:11:6e:30 dev swp2 vlan 100 Would result in the following example output: # bridge fdb # 01:00:5e:00:00:01 dev eth0 self permanent # 01:00:5e:00:00:01 dev eth1 self permanent # 00:50:d2:10:78:15 dev swp0 master br0 permanent # 00:50:d2:10:78:15 dev swp2 vlan 100 master br0 permanent # 3c:97:0e:11:6e:30 dev swp2 vlan 100 self static # 00:50:d2:10:78:15 dev swp3 master br1 permanent # 00:50:d2:10:78:15 dev swp3 vlan 100 master br1 permanent And the Address Translation Unit would contain: DB T/P Vec State Addr 008 Port 004 e 3c:97:0e:11:6e:30 ==================== Signed-off-by: -
Vivien Didelot authored
This commit changes the 802.1Q mode of each port from Disabled to Secure. This enables the VLAN support, by checking the VTU entries on ingress. Signed-off-by:
Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by:
-
Vivien Didelot authored
Implement port_pvid_set and port_vlan_add to add new entries in the VLAN hardware table, and join ports to them. The patch also implement the STU Get Next and Load Purge operations, since it is required to have a valid STU entry for at least all VLANs. Each VLAN has its own forwarding database, with FID num_ports+1 to 4095. Signed-off-by:
-
Vivien Didelot authored
Add support for the VTU Load Purge operation and implement the port_vlan_del driver function to remove a port from a VLAN entry, and delete the VLAN if the given port was its last member. Signed-off-by:
-
Vivien Didelot authored
Add an helper function to read the next valid VLAN entry for a given port. It is used in the VID to FID conversion function to retrieve the forwarding database assigned to a given VLAN port. Finally update the FDB getnext operation to iterate on the next valid port VLAN when the end of the current database is reached. Signed-off-by:
-
Vivien Didelot authored
Implement the port_pvid_get and vlan_getnext driver functions required to dump VLAN entries from the hardware, with the VTU Get Next operation. Some functions and structure will be shared with STU operations, since their table format are similar (e.g. STU data entries are accessible with the same registers as VTU entries, except with an offset of 2). Signed-off-by:
-
Vivien Didelot authored
Implement the VTU Flush operation (which also flushes the STU), so that warm boots won't preserved old entries. Signed-off-by:
-
Vivien Didelot authored
Add new functions in DSA drivers to access hardware VLAN entries through SWITCHDEV_OBJ_PORT_VLAN objects: - port_pvid_get() and vlan_getnext() to dump a VLAN - port_vlan_del() to exclude a port from a VLAN - port_pvid_set() and port_vlan_add() to join a port to a VLAN The DSA infrastructure will ensure that each VLAN of the given range does not already belong to another bridge. If it does, it will fallback to software VLAN and won't program the hardware. Signed-off-by:
-
