1015624 Commits

Author SHA1 Message Date
M Chetan Kumar
faed4c6f6f net: iosm: shared memory protocol
1) Defines messaging protocol for handling Transfer Descriptor
   in both UL/DL direction.
2) Ring buffer management.

Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13 13:49:38 -07:00
M Chetan Kumar
be8c936e54 net: iosm: power management
Implements state machine to handle host & device sleep.

Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13 13:49:38 -07:00
M Chetan Kumar
9413491e20 net: iosm: encode or decode datagram
1) Encode UL packet into datagram.
2) Decode DL datagram and route it to network layer.
3) Supports credit based flow control.

Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13 13:49:38 -07:00
M Chetan Kumar
51c45fa954 net: iosm: multiplex IP sessions
Establish IP session between host-device & session management.

Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13 13:49:38 -07:00
M Chetan Kumar
3b575260cb net: iosm: bottom half
1) Bottom half(tasklet) for IRQ and task processing.
2) Tasks are processed asynchronous and synchronously.

Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13 13:49:38 -07:00
M Chetan Kumar
10685b6e98 net: iosm: wwan port control device
Implements wwan port for MBIM & AT protocol communication

Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13 13:49:38 -07:00
M Chetan Kumar
30ebda7a31 net: iosm: channel configuration
Defines pipes & channel configurations like channel type,
pipe mappings, No. of transfer descriptors and transfer
buffer size etc.

Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13 13:49:38 -07:00
M Chetan Kumar
edf6423c04 net: iosm: shared memory I/O operations
1) Binds logical channel between host-device for communication.
2) Implements device specific(Char/Net) IO operations.

Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13 13:49:38 -07:00
M Chetan Kumar
3670970dd8 net: iosm: shared memory IPC interface
1) Initializes shared memory for host-device communication.
2) Allocate resources required for control & data operations.
3) Transfers the Device IRQ to IPC execution thread.
4) Defines the timer cbs for async events.

Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13 13:49:38 -07:00
M Chetan Kumar
dc0514f5d8 net: iosm: mmio scratchpad
1) Initializes the Scratchpad region for Host-Device communication.
2) Exposes device capabilities like chip info and device execution
   stages.

Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13 13:49:38 -07:00
M Chetan Kumar
7f41ce085d net: iosm: irq handling
1) Request interrupt vector, frees allocated resource.
2) Registers IRQ handler.

Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13 13:49:38 -07:00
M Chetan Kumar
7e98d785ae net: iosm: entry point
1) Register IOSM driver with kernel to manage Intel WWAN PCIe
   device(PCI_VENDOR_ID_INTEL, INTEL_CP_DEVICE_7560_ID).
2) Exposes the EP PCIe device capability to Host PCIe core.
3) Initializes PCIe EP configuration and defines PCIe driver probe, remove
   and power management OPS.
4) Allocate and map(dma) skb memory for data communication from device to
   kernel and vice versa.

Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13 13:49:38 -07:00
David S. Miller
ffbbc5e5c7 Merge branch 'rmnet-checksums-part-2'
Alex Elder says:

====================
net: qualcomm: rmnet: MAPv4 download checksum cleanup, part 2

This is part 2 of a large series that reworks some code that handles
downloaded packets when MAPv4 checksum offload is enabled.  The
first part, which includes an overview, is here:
  https://lore.kernel.org/netdev/20210611190529.3085813-1-elder@linaro.org/

This second part of the series completes the simplification of this
handling code, removing unnecessary byte swaps and bitwise inversions
of checksum values, and along the way avoids the need for almost all
of the forced type casts.  The checksum field in an RMNet download
trailer is given __sum16_t type to accurately reflect the meaning of
that field.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-12 13:18:49 -07:00
Alex Elder
185a108fe0 net: qualcomm: rmnet: IPv6 payload length is simple
We don't support any extension headers for IPv6 packets.  Extension
headers therefore contribute 0 bytes to the payload length.  As a
result we can just use the IPv6 payload length as the length used to
compute the pseudo header checksum for both UDP and TCP messages.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-12 13:18:49 -07:00
Alex Elder
411a795e14 net: qualcomm: rmnet: drop some unary NOTs
We compare a payload checksum with a pseudo checksum value for
equality in rmnet_map_ipv4_dl_csum_trailer().  Both of those values
are computed with a unary NOT (~) operation.  The result of the
comparison is the same if we omit that NOT for both values.

Remove these operations in rmnet_map_ipv6_dl_csum_trailer() also.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-12 13:18:49 -07:00
Alex Elder
be754f6435 net: qualcomm: rmnet: trailer value is a checksum
The csum_value field in the rmnet_map_dl_csum_trailer structure is a
"real" Internet checksum.  It is a 16 bit value, in big endian format,
which represents an inverted ones' complement sum over pairs of bytes.

Make that clear by changing its type to __sum16.

This makes a typecast in rmnet_map_ipv4_dl_csum_trailer() and
another in rmnet_map_ipv6_dl_csum_trailer() unnecessary.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-12 13:18:49 -07:00
Alex Elder
698aa6c46b net: qualcomm: rmnet: remove unneeded code
The previous patch makes rmnet_map_ipv4_dl_csum_trailer() return
early with an error if it is determined that the computed checksum
for the IP payload does not match what was expected.

If the computed checksum *does* match the expected value, the IP
payload (i.e., the transport message), can be considered good.
There is no need to do any further processing of the message.

This means a big block of code is unnecessary for validating the
transport checksum value, and can be removed.

Make comparable changes in rmnet_map_ipv6_dl_csum_trailer().

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-12 13:18:48 -07:00
Alex Elder
fab01a6f3a net: qualcomm: rmnet: return earlier for bad checksum
In rmnet_map_ipv4_dl_csum_trailer(), if the sum of the trailer
checksum and the pseudo checksum is non-zero, checksum validation
has failed.  We can return an error as soon as we know that.

We can do the same thing in rmnet_map_ipv6_dl_csum_trailer().

Add some comments that explain where we're headed.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-12 13:18:48 -07:00
Alex Elder
9d0407bc4c net: qualcomm: rmnet: show that an intermediate sum is zero
This patch simply demonstrates that a checksum value computed when
verifying an offloaded transport checksum value for both IPv4 and
IPv6 is (normally) 0.  It can be squashed into the next patch.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-12 13:18:48 -07:00
Alex Elder
bbd45f10ed net: qualcomm: rmnet: rearrange some NOTs
With the ones' complement arithmetic, the sum of two negated values
is equal to the negation of the sum of the two original values [1].
Rearrange the calculation ip6_payload_sum using this property.

[1] https://tools.ietf.org/html/rfc1071

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-12 13:18:48 -07:00
Alex Elder
0e6af897fc net: qualcomm: rmnet: remove some local variables
In rmnet_map_ipv4_dl_csum_trailer(), remove the "csum_temp" and
"addend" local variables, and simplify a few lines of code.

Remove the "csum_temp", "csum_value", "ip6_hdr_csum", and "addend"
local variables in rmnet_map_ipv6_dl_csum_trailer(), and simplify a
few lines of code there as well.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-12 13:18:48 -07:00
David S. Miller
73a378601a Merge branch 'wwan-link-creation'
Loic Poulain says:

====================
net: Add WWAN link creation support

Most of the modern WWAN modems are able to support multiple network
contexts, allowing user to connect to different APNs (e.g. Internet,
MMS, etc...). These contexts are usually dynamically configured via
a control channel such as MBIM, QMI or AT.

Each context is naturally represented as a network link/device, and
the muxing of these links is usually vendor/bus specific (QMAP, MBIM,
intel iosm...). Today some drivers create a static collection of
netdevs at init time, some relies on VLAN link for associating a context
(cdc-mbim), some exposes sysfs attribute for dynamically creating
additional netdev (qmi_wwan add_mux attr) or relies on vendor specific
link type (rmnet) for performing the muxing... so there is no generic
way to handle WWAN links, making user side integration painful.

This series introduces a generic WWAN link management interface to the
WWAN framework, allowing user to dynamically create and remove WWAN
links through rtnetlink ('wwan' type). The underlying 'muxing' vendor
implementation is completely abstracted.

The idea is to use this interface for upcoming WWAN drivers (intel
iosm) and to progressively integrate support into existing ones
(qmi_wwan, cdc-mbim, mhi_net, etc...).

v2: - Squashed Johannes and Sergey changes
    - Added IFLA_PARENT_DEV_BUS_NAME attribute
    - reworded commit message + introduce Sergey's comment

v3: - Added basic new interface user to this series (mhi_net)
    - Moved IFLA_PARENT_DEV_NAME nla_policy introduction to right patch
    - Added cover letter
    - moved kdoc to .c file
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-12 13:16:45 -07:00
Loic Poulain
13adac0329 net: mhi_net: Register wwan_ops for link creation
Register wwan_ops for link management via wwan rtnetlink. This is
only basic support for now, since we only support creating one
single link (link-0), but is useful to validate new wwan rtnetlink
interface.

For backward compatibity support, we still register a default netdev
at probe time, except if 'create_default_iface' module parameter is
set to false.

This has been tested with iproute2 and mbimcli:
$ ip link add dev wwan0-0 parentdev-name wwan0 type wwan linkid 0
$ mbimcli -p -d /dev/wwan0p2MBIM --connect apn=free
$ ip link set dev wwan0-0 up
$ ip addr add dev wwan0 ${IP}
$ ip route replace default via ${IP}
$ ping 8.8.8.8
...

Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-12 13:16:45 -07:00
Johannes Berg
88b710532e wwan: add interface creation support
Add support to create (and destroy) interfaces via a new
rtnetlink kind "wwan". The responsible driver has to use
the new wwan_register_ops() to make this possible.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-12 13:16:45 -07:00
Johannes Berg
00e77ed8e6 rtnetlink: add IFLA_PARENT_[DEV|DEV_BUS]_NAME
In some cases, for example in the upcoming WWAN framework changes,
there's no natural "parent netdev", so sometimes dummy netdevs are
created or similar. IFLA_PARENT_DEV_NAME is a new attribute intended to
contain a device (sysfs, struct device) name that can be used instead
when creating a new netdev, if the rtnetlink family implements it.

As suggested by Parav Pandit, we also introduce IFLA_PARENT_DEV_BUS_NAME
attribute in order to uniquely identify a device on the system (with
bus/name pair).

ip-link(8) support for the generic parent device attributes will help
us avoid code duplication, so no other link type will require a custom
code to handle the parent name attribute. E.g. the WWAN interface
creation command will looks like this:

$ ip link add wwan0-1 parent-dev wwan0 type wwan channel-id 1

So, some future subsystem (or driver) FOO will have an interface
creation command that looks like this:

$ ip link add foo1-3 parent-dev foo1 type foo bar-id 3 baz-type Y

Below is an example of dumping link info of a random device with these
new attributes:

$ ip --details link show wlp0s20f3
  4: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
     state UP mode DORMANT group default qlen 1000
     ...
     parent_bus pci parent_dev 0000:00:14.3

Co-developed-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
Co-developed-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Suggested-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-12 13:16:45 -07:00
Johannes Berg
8c713dc93c rtnetlink: add alloc() method to rtnl_link_ops
In order to make rtnetlink ops that can create different
kinds of devices, like what we want to add to the WWAN
framework, the priv_size and setup parameters aren't quite
sufficient. Make this easier to manage by allowing ops to
allocate their own netdev via an @alloc method that gets
the tb netlink data.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-12 13:16:45 -07:00
Lijun Pan
73214a690c ibmvnic: fix kernel build warnings in build_hdr_descs_arr
Fix the following kernel build warnings:
drivers/net/ethernet/ibm/ibmvnic.c:1516: warning: Function parameter or member 'skb' not described in 'build_hdr_descs_arr'
drivers/net/ethernet/ibm/ibmvnic.c:1516: warning: Function parameter or member 'indir_arr' not described in 'build_hdr_descs_arr'
drivers/net/ethernet/ibm/ibmvnic.c:1516: warning: Excess function parameter 'txbuff' description in 'build_hdr_descs_arr'

Signed-off-by: Lijun Pan <lijunp213@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-12 13:14:39 -07:00
Lijun Pan
822ebc2cf5 ibmvnic: fix kernel build warning
drivers/net/ethernet/ibm/ibmvnic.c: In function ‘adapter_state_to_string’:
drivers/net/ethernet/ibm/ibmvnic.c:855:2: warning: enumeration value ‘VNIC_DOWN’ not handled in switch [-Wswitch]
  855 |  switch (state) {
      |  ^~~~~~
drivers/net/ethernet/ibm/ibmvnic.c: In function ‘reset_reason_to_string’:
drivers/net/ethernet/ibm/ibmvnic.c:1958:2: warning: enumeration value ‘VNIC_RESET_PASSIVE_INIT’ not handled in switch [-Wswitch]
 1958 |  switch (reason) {
      |  ^~~~~~

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Lijun Pan <lijunp213@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-12 13:14:39 -07:00
David S. Miller
02b0bb51a8 Merge branch 'stmmac-intel-cleanups'
Wong Vee Khee says:

====================
stmmac: intel: minor clean-up

This patch series include two minor-cleanup patches:

  1. Move all the hardcoded DEFINEs to dwmac-intel header file.
  2. Fix the wrong kernel-doc on the intel_eth_pci_remove() function.

Since the changes are minor, only basic sanity tests are done on a
Intel TigerLake with Marvell88E2110 PHY:-

  - Link is up and able to perform ping.
  - phc2sys and ptp4l are running without errors.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-12 13:10:52 -07:00
Wong Vee Khee
3c3ea630e8 stmmac: intel: fix wrong kernel-doc
Kernel-doc for intel_eth_pci_remove is incorrect, pdev datatype is
struct pci_dev. Changed it to the 'pci device pointer'.

Signed-off-by: Wong Vee Khee <vee.khee.wong@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-12 13:10:52 -07:00
Wong Vee Khee
fb9349c416 stmmac: intel: move definitions to dwmac-intel header file
Currently some of the dwmac-intel definitions are in the header file,
while some are in the driver source file. Cleaning this by moving all
the definitions to the header file.

Signed-off-by: Wong Vee Khee <vee.khee.wong@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-12 13:10:52 -07:00
David S. Miller
bf75213f24 Merge branch 'phy-25G-BASE-R'
Steen Hegelund says:

====================
Add 25G BASE-R support

This series add the 25G BASE-R mode to the set modes supported.
This mode is used by the Sparx5 Switch for its 25G SerDes.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-12 13:08:58 -07:00
Steen Hegelund
21e0c59edc net: phylink: Add 25G BASE-R support
Add 25gbase-r interface type and speed to phylink.
This is needed for the Sparx5 switch.

Signed-off-by: Steen Hegelund <steen.hegelund@microchip.com>
Signed-off-by: Bjarni Jonasson <bjarni.jonasson@microchip.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-12 13:08:58 -07:00
Steen Hegelund
452d2c6fba net: sfp: add support for 25G BASE-R SFPs
Add support for 25gbase-r modules. This is needed for the Sparx5 switch.

Signed-off-by: Steen Hegelund <steen.hegelund@microchip.com>
Signed-off-by: Bjarni Jonasson <bjarni.jonasson@microchip.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-12 13:08:57 -07:00
Steen Hegelund
a56c286865 net: phy: Add 25G BASE-R interface mode
Add 25gbase-r phy interface mode

Signed-off-by: Steen Hegelund <steen.hegelund@microchip.com>
Signed-off-by: Bjarni Jonasson <bjarni.jonasson@microchip.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-12 13:08:57 -07:00
Steen Hegelund
858252c9c3 dt-bindings: net: Add 25G BASE-R phy interface
Add 25gbase-r PHY interface mode.

Signed-off-by: Steen Hegelund <steen.hegelund@microchip.com>
Signed-off-by: Bjarni Jonasson <bjarni.jonasson@microchip.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-12 13:08:57 -07:00
David S. Miller
abf6420edb Merge branch 's390-net-updates'
Julian Wiedmann says:

====================
s390/iucv: updates 2021-06-11

please apply the following iucv patches to netdev's net-next tree.

This cleans up a pattern of forward declarations in two iucv drivers,
so that they stop causing compile warnings with gcc11.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-12 13:06:34 -07:00
Heiko Carstens
fbf1796836 s390/netiuvc: get rid of forward declarations
Move netiucv_handler to get rid of forward declarations and gcc11
compile warnings:

drivers/s390/net/netiucv.c:518:65: warning: argument 2 of type ‘u8[16]’ {aka ‘unsigned char[16]’} with mismatched bound [-Warray-parameter=]
  518 | static void netiucv_callback_connack(struct iucv_path *path, u8 ipuser[16])
      |                                                              ~~~^~~~~~~~~~
drivers/s390/net/netiucv.c:122:58: note: previously declared as ‘u8 *’ {aka ‘unsigned char *’}
  122 | static void netiucv_callback_connack(struct iucv_path *, u8 *);

Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-12 13:06:33 -07:00
Julian Wiedmann
87c272c618 net/af_iucv: clean up some forward declarations
The forward declarations for the iucv_handler callbacks are causing
various compile warnings with gcc-11. Reshuffle the code to get rid
of these prototypes.

Reported-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-12 13:06:33 -07:00
David S. Miller
1f1aa3fe02 Merge branch 'ipa-sysfs'
Alex Elder says:

====================
net: ipa: introduce ipa_syfs.c

This series (its last patch, actually) creates a new source file,
"ipa_syfs.c", to contain functions and data that expose to user
space information known by the IPA driver via device attributes.

The directory containing these files on supported systems is:
    /sys/devices/platform/soc@0/1e40000.ipa

And within that direcftory, the following files and directories
are added:
    .
    |-- feature
    |   |-- rx_offload          Type of checksum offload supported
    |   `-- tx_offload
    |   . . .
    |-- modem
    |   |-- rx_endpoint_id      IPA endpoint IDs for the embedded modem
    |   `-- tx_endpoint_id
    |   . . .
    |-- version                 IPA hardware version (informational)
        . . .

The first patch just makes endpoint validation unconditional, as
suggested by Leon Romanovsky.  The second just ensures the version
defined in configuration data is valid, so the version attribute
doesn't have to handle unrecognized version numbers.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11 14:13:18 -07:00
Alex Elder
2e3cf97f47 net: ipa: introduce sysfs code
Add IPA device attributes to expose information known by the IPA
driver about the hardware and its configuration.

All pointers used to display these attribute values (i.e., IPA
pointer and endpoint pointers) will have been initialized by the
time IPA probe has completed, so they may be safely dereferenced.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11 14:13:18 -07:00
Alex Elder
e22e8e2fae net: ipa: introduce ipa_version_valid()
Define and use a new function that just validates the version
defined in configuration data.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11 14:13:18 -07:00
Alex Elder
9e8fb7bf9c net: ipa: make endpoint data validation unconditional
The cost of validating the endpoint configuration data is not all
that high, so just do it unconditionally, rather than doing so only
when IPA_VALIDATAION is defined.

Suggested-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11 14:13:18 -07:00
Lijun Pan
0b217d3d74 ibmvnic: fix kernel build warning in strncpy
drivers/net/ethernet/ibm/ibmvnic.c: In function ‘handle_vpd_rsp’:
drivers/net/ethernet/ibm/ibmvnic.c:4393:3: warning: ‘strncpy’ output truncated before terminating nul copying 3 bytes from a string of the same length [-Wstringop-truncation]
 4393 |   strncpy((char *)adapter->fw_version, "N/A", 3 * sizeof(char));
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Signed-off-by: Lijun Pan <lijunp213@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11 13:56:23 -07:00
David S. Miller
2227ec7baa Merge branch 'sja1105-xpcs'
Vladimir Oltean says:

====================
Port the SJA1105 DSA driver to XPCS

As requested when adding support for the NXP SJA1110, the SJA1105 driver
could make use of the common XPCS driver, to eliminate some hardware
specific code duplication.

This series modifies the XPCS driver so that it can accommodate the XPCS
instantiation from NXP switches, and the SJA1105 driver so it can expose
what the XPCS driver expects.

Tested on NXP SJA1105S and SJA1110A.

Changes in v3:
None. This is a resend of v2 which had "changes requested" even though
there was no direct feedback.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11 13:43:56 -07:00
Vladimir Oltean
56b6346633 net: dsa: sja1105: plug in support for 2500base-x
The MAC treats 2500base-x same as SGMII (yay for that) except that it
must be set to a different speed.

Extend all places that check for SGMII to also check for 2500base-x.

Also add the missing 2500base-x compatibility matrix entry for SJA1110D.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11 13:43:56 -07:00
Vladimir Oltean
ece578bc3e net: dsa: sja1105: SGMII and 2500base-x on the SJA1110 are 'special'
For the xMII Mode Parameters Table to be properly configured for SGMII
mode on SJA1110, we need to set the "special" bit, since SGMII is
officially bitwise coded as 0b0011 in SJA1105 (decimal 3, equal to
XMII_MODE_SGMII), and as 0b1011 in SJA1110 (decimal 11).

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11 13:43:56 -07:00
Vladimir Oltean
27871359bd net: dsa: sja1105: register the PCS MDIO bus for SJA1110
On the SJA1110, the PCS of each SERDES-capable port is accessed through
a different memory window which is 0x100 bytes in size, denoted by
"pcs_base".

In each PCS register access window, the XPCS MMDs are accessed in an
indirect way: in pages/banks of up to 0x100 addresses each. Changing the
page/bank is done by writing to a special register at the end of the
access window.

The MDIO register map accessed indirectly through the indirect banked
method described above is similar to what SJA1105 has: upper 5 bits are
the MMD, lower 16 bits are the MDIO address within that MMD.

Since the PHY ID reported by the XPCS inside SJA1110 is also all zeroes
(like SJA1105), we need to trap those reads and return a fake PHY ID so
that the xpcs driver can apply some specific fixups for our integration.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11 13:43:56 -07:00
Vladimir Oltean
3ad1d17154 net: dsa: sja1105: migrate to xpcs for SGMII
There is a desire to use the generic driver for the Synopsys XPCS
located in drivers/net/pcs, and to achieve that, the sja1105 driver must
expose an MDIO bus for the SGMII PCS, because the XPCS probes as an
mdio_device.

In preparation of the SJA1110 which in fact has a different access
procedure for the SJA1105, we register this PCS MDIO bus once in the
common code, but we implement function pointers for the read and write
methods. In this patch there is a single implementation for them.

There is exactly one MDIO bus for the PCS, this will contain all PCSes
at MDIO addresses equal to the port number.

We delete a bunch of hardware support code because the xpcs driver
already does what we need.

We need to hack up the MDIO reads for the PHY ID, since our XPCS
instantiation returns zeroes and there are some specific fixups which
need to be applied by the xpcs driver.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11 13:43:56 -07:00
Vladimir Oltean
a853c68e29 net: pcs: xpcs: export xpcs_do_config and xpcs_link_up
The sja1105 hardware has a quirk in that some changes require a switch
reset, which loses all configuration. When the reset is initiated,
everything needs to be reprogrammed, including the MACs and the PCS.
This is currently done in sja1105_static_config_reload() - we manually
call sja1105_adjust_port_config(), sja1105_sgmii_pcs_config() and
sja1105_sgmii_pcs_force_speed() which are all internal functions.

There is a desire for sja1105 to use the common xpcs driver, and that
means that the equivalents of those functions, xpcs_do_config() and
xpcs_link_up() respectively, will no longer be local functions.

Forcing phylink to retrigger a resolve somehow, say by doing dev_close()
followed by dev_open() is not really an option, because the CPU port
might have a PCS as well, and there is no net device which we can close
and reopen for that. Additionally, the dev_close/dev_open sequence might
force a renegotiation of the copper-side link for SGMII ports connected
to a PHY, and this is undesirable as well, because the switch reset is
much quicker than a PHY autoneg, so we would have a lot more downtime.

The only solution I see is for the sja1105 driver to keep doing what
it's doing, and that means we need to export the equivalents from xpcs
for sja1105_sgmii_pcs_config and sja1105_sgmii_pcs_force_speed, and call
them directly in sja1105_static_config_reload(). This will be done
during the conversion patch.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11 13:43:56 -07:00