Add definitions for the dsa_netdevice_ops structure which is a subset of
the net_device_ops structure for the specific operations that we care
about overlaying on top of the DSA CPU port net_device and provide
inline stubs that take core managing whether DSA code is reachable.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
====================
Fully describe the waveform for PTP periodic output
While using the ancillary pin functionality of PTP hardware clocks to
synchronize multiple DSA switches on a board, a need arised to be able
to configure the duty cycle of the master of this PPS hierarchy.
Also, the PPS master is not able to emit PPS starting from arbitrary
absolute times, so a new flag is introduced to support such hardware
without making guesses.
With these patches, struct ptp_perout_request now basically describes a
general-purpose square wave.
Changes in v2:
Made sure this applies to net-next.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Oltean [Thu, 16 Jul 2020 22:45:31 +0000 (01:45 +0300)]
net: mscc: ocelot: add support for PTP waveform configuration
For PPS output (perout period is 1.000000000), accept the new "phase"
parameter from the periodic output request structure.
For both PPS and freeform output, accept the new "on" argument for
specifying the duty cycle of the generated signal. Preserve the old
defaults for this "on" time: 1 us for PPS, and half the period for
freeform output.
Also preserve the old behavior that accepted the "phase" via the "start"
argument.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Oltean [Thu, 16 Jul 2020 22:45:30 +0000 (01:45 +0300)]
ptp: introduce a phase offset in the periodic output request
Some PHCs like the ocelot/felix switch cannot emit generic periodic
output, but just PPS (pulse per second) signals, which:
- don't start from arbitrary absolute times, but are rather
phase-aligned to the beginning of [the closest next] second.
- have an optional phase offset relative to that beginning of the
second.
For those, it was initially established that they should reject any
other absolute time for the PTP_PEROUT_REQUEST than 0.000000000 [1].
But when it actually came to writing an application [2] that makes use
of this functionality, we realized that we can't really deal generically
with PHCs that support absolute start time, and with PHCs that don't,
without an explicit interface. Namely, in an ideal world, PHC drivers
would ensure that the "perout.start" value written to hardware will
result in a functional output. This means that if the PTP time has
become in the past of this PHC's current time, it should be
automatically fast-forwarded by the driver into a close enough future
time that is known to work (note: this is necessary only if the hardware
doesn't do this fast-forward by itself). But we don't really know what
is the status for PHC drivers in use today, so in the general sense,
user space would be risking to have a non-functional periodic output if
it simply asked for a start time of 0.000000000.
So let's introduce a flag for this type of reduced-functionality
hardware, named PTP_PEROUT_PHASE. The start time is just "soon", the
only thing we know for sure about this signal is that its rising edge
events, Rn, occur at:
Rn = perout.phase + n * perout.period
The "phase" in the periodic output structure is simply an alias to the
"start" time, since both cannot logically be specified at the same time.
Therefore, the binary layout of the structure is not affected.
Vladimir Oltean [Thu, 16 Jul 2020 22:45:29 +0000 (01:45 +0300)]
ptp: add ability to configure duty cycle for periodic output
There are external event timestampers (PHCs with support for
PTP_EXTTS_REQUEST) that timestamp both event edges.
When those edges are very close (such as in the case of a short pulse),
there is a chance that the collected timestamp might be of the rising,
or of the falling edge, we never know.
There are also PHCs capable of generating periodic output with a
configurable duty cycle. This is good news, because we can space the
rising and falling edge out enough in time, that the risks to overrun
the 1-entry timestamp FIFO of the extts PHC are lower (example: the
perout PHC can be configured for a period of 1 second, and an "on" time
of 0.5 seconds, resulting in a duty cycle of 50%).
A flag is introduced for signaling that an on time is present in the
perout request structure, for preserving compatibility. Logically
speaking, the duty cycle cannot exceed 100% and the PTP core checks for
this.
PHC drivers that don't support this flag emit a periodic output of an
unspecified duty cycle, same as before.
The duty cycle is encoded as an "on" time, similar to the "start" and
"period" times, and reuses the reserved space while preserving overall
binary layout.
Willem de Bruijn [Fri, 10 Jul 2020 13:29:02 +0000 (09:29 -0400)]
icmp: support rfc 4884
Add setsockopt SOL_IP/IP_RECVERR_4884 to return the offset to an
extension struct if present.
ICMP messages may include an extension structure after the original
datagram. RFC 4884 standardized this behavior. It stores the offset
in words to the extension header in u8 icmphdr.un.reserved[1].
The field is valid only for ICMP types destination unreachable, time
exceeded and parameter problem, if length is at least 128 bytes and
entire packet does not exceed 576 bytes.
Return the offset to the start of the extension struct when reading an
ICMP error from the error queue, if it matches the above constraints.
Do not return the raw u8 field. Return the offset from the start of
the user buffer, in bytes. The kernel does not return the network and
transport headers, so subtract those.
Also validate the headers. Return the offset regardless of validation,
as an invalid extension must still not be misinterpreted as part of
the original datagram. Note that !invalid does not imply valid. If
the extension version does not match, no validation can take place,
for instance.
For backward compatibility, make this optional, set by setsockopt
SOL_IP/IP_RECVERR_RFC4884. For API example and feature test, see
github.com/wdebruij/kerneltools/blob/master/tests/recv_icmp_v2.c
For forward compatibility, reserve only setsockopt value 1, leaving
other bits for additional icmp extensions.
Changes
v1->v2:
- convert word offset to byte offset from start of user buffer
- return in ee_data as u8 may be insufficient
- define extension struct and object header structs
- return len only if constraints met
- if returning len, also validate
Signed-off-by: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
====================
rework mvneta napi_poll loop for XDP multi-buffers
Rework mvneta_rx_swbm routine in order to process all rx descriptors before
building the skb or run the xdp program attached to the interface.
Introduce xdp_get_shared_info_from_{buff,frame} utility routines to get the
skb_shared_info pointer from xdp_buff or xdp_frame.
This is a preliminary series to enable multi-buffers and jumbo frames for XDP
according to [1]
Lorenzo Bianconi [Thu, 16 Jul 2020 22:16:30 +0000 (00:16 +0200)]
net: mvneta: move skb build after descriptors processing
Move skb build after all descriptors processing. This is a preliminary
patch to enable multi-buffers and JUMBO frames support for XDP.
Introduce mvneta_xdp_put_buff routine to release all pages used by a
XDP multi-buffer
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Introduce xdp_get_shared_info_from_{buff,frame} utility routines to get
skb_shared_info from xdp buffer/frame pointer.
xdp_get_shared_info_from_{buff,frame} will be used to implement xdp
multi-buffer support
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
====================
do a single memdup_user in sctp_setsockopt v2
here is a resend of my series to lift the copy_from_user out of the
individual sctp sockopt handlers into the main sctp_setsockopt
routine.
Changes since v1:
- fixes a few sizeof calls.
- use memzero_explicit in sctp_setsockopt_auth_key instead of special
casing it for a kzfree in the caller
- remove some minor cleanups from sctp_setsockopt_autoclose to keep
it closer to the existing version
- add another little only vaguely related cleanup patch
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
sctp: pass a kernel pointer to sctp_setsockopt_auth_key
Use the kernel pointer that sctp_setsockopt has available instead of
directly handling the user pointer. Adapt sctp_setsockopt to use a
kzfree for this case.
Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: David S. Miller <davem@davemloft.net>
sctp: pass a kernel pointer to sctp_setsockopt_bindx
Rename sctp_setsockopt_bindx_kernel back to sctp_setsockopt_bindx,
and use the kernel pointer that sctp_setsockopt has available instead of
directly handling the user pointer in the old sctp_setsockopt_bindx.
Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: David S. Miller <davem@davemloft.net>
sctp: copy the optval from user space in sctp_setsockopt
Prepare for for moving the copy_from_user from the individual sockopts
to the main setsockopt helper. As of this commit the kopt variable
is not used yet, but the following commits will start using it.
Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Mon, 20 Jul 2020 01:16:41 +0000 (18:16 -0700)]
Merge branch 'sockopt-cleanups'
Christoph Hellwig says:
====================
sockopt cleanups
this series cleans up various lose ends in the sockopt code, most
importantly removing the compat_{get,set}sockopt infrastructure in favor
of just using in_compat_syscall() in the few places that care.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Handle the few cases that need special treatment in-line using
in_compat_syscall(). This also removes all the now unused
compat_{get,set}sockopt methods.
Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: David S. Miller <davem@davemloft.net>
All instances handle compat sockopts via in_compat_syscall() now, so
remove the compat_{get,set} methods as well as the
compat_nf_{get,set}sockopt wrappers.
Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: David S. Miller <davem@davemloft.net>
netfilter/ebtables: clean up compat {get, set}sockopt handling
Merge the native and compat {get,set}sockopt handlers using
in_compat_syscall(). Note that this required moving a fair
amout of code around to be done sanely.
Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: David S. Miller <davem@davemloft.net>
Now that the ->compat_{get,set}sockopt proto_ops methods are gone
there is no good reason left to keep the compat syscalls separate.
This fixes the odd use of unsigned int for the compat_setsockopt
optlen and the missing sock_use_custom_sol_socket.
It would also easily allow running the eBPF hooks for the compat
syscalls, but such a large change in behavior does not belong into
a consolidation patch like this one.
Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: David S. Miller <davem@davemloft.net>
Add the compat handling to sock_common_{get,set}sockopt instead,
keyed of in_compat_syscall(). This allow to remove the now unused
->compat_{get,set}sockopt methods from struct proto_ops.
Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Matthieu Baerts <matthieu.baerts@tessares.net> Acked-by: Stefan Schmidt <stefan@datenfreihafen.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Add a helper that copies either a native or compat bpf_fprog from
userspace after verifying the length, and remove the compat setsockopt
handlers that now aren't required.
Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: David S. Miller <davem@davemloft.net>
Randy Dunlap [Sun, 19 Jul 2020 18:08:24 +0000 (11:08 -0700)]
net: rds: rdma_transport.h: delete duplicated word
Delete the doubled word "be" in a comment.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Santosh Shilimkar <santosh.shilimkar@oracle.com> Cc: netdev@vger.kernel.org Cc: linux-rdma@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
Randy Dunlap [Sun, 19 Jul 2020 18:08:01 +0000 (11:08 -0700)]
net: atm: lec_arpc.h: delete duplicated word
Delete the doubled word "the" in a comment.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: netdev@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
net: phy: at803x: add mdix configuration support for AR9331 and AR8035
This patch add MDIX configuration ability for AR9331 and AR8035. Theoretically
it should work on other Atheros PHYs, but I was able to test only this
two.
Since I have no certified reference HW able to detect or configure MDIX, this
functionality was confirmed by oscilloscope.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
These patches were picked from the following series:
https://lore.kernel.org/netdev/1567779344-30965-1-git-send-email-claudiu.manoil@nxp.com/
They have never been resent. I've picked them up, addressed Andrews
comments, fixed some more bugs and asked Claudiu if I can keep their SOB
tags; he agreed. I've tested this on our board which happens to have a
bootloader which doesn't do the enetc setup in all cases. Though, only
SGMII mode was tested.
changes since v6:
- dropped _LPA_ infix for USXGMII constants
changes since v5:
- fixed pcs->autoneg_complete and pcs->link assignment. Thanks Vladimir.
changes since v4:
- moved (and renamed) the USXGMII constants to include/uapi/linux/mdio.h.
Suggested by Russell King.
changes since v3:
- rebased to latest net-next where devm_mdiobus_free() was removed.
replace it by mdiobus_free(). The internal MDIO bus is optional, if
there is any error, we try to run with the bootloader default PCS
settings, thus in the error case, we need to free the mdiobus.
changes since v2:
- removed SOBs from "net: enetc: Initialize SerDes for SGMII and USXGMII
protocols" because almost everything has changed.
- get a phy_device for the internal PCS PHY so we can use the phy_
functions instead of raw mdiobus writes
- reuse macros already defined in fsl_mdio.h, move missing bits from
felix to fsl_mdio.h, because they share the same PCS PHY building
block
- added 2500BaseX mode (based on felix init routine)
- changed xgmii mode to usxgmii mode, because it is actually USXGMII and
felix does the same.
- fixed devad, which is 0x1f (MMD_VEND2)
changes since v1:
- mdiobus id is '"imdio-%s", dev_name(dev)' because the plain dev_name()
is used by the emdio.
- use mdiobus_write() instead of imdio->write(imdio, ..), since this is
already a full featured mdiobus
- set phy_mask to ~0 to avoid scanning the bus
- use phy_interface_mode_is_rgmii(phy_mode) to also include the RGMII
modes with pad delays.
- move enetc_imdio_init() to enetc_pf.c, there shouldn't be any other
users, should it?
- renamed serdes to SerDes
- printing the error code of mdiobus_register() in the error path
- call mdiobus_unregister() on _remove()
- call devm_mdiobus_free() if mdiobus_register() fails, since an
error is not fatal
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Alex Marginean [Sun, 19 Jul 2020 22:03:36 +0000 (00:03 +0200)]
net: enetc: Use DT protocol information to set up the ports
Use DT information rather than in-band information from bootloader to
set up MAC for XGMII. For RGMII use the DT indication in addition to
RGMII defaults in hardware.
However, this implies that PHY connection information needs to be
extracted before netdevice creation, when the ENETC Port MAC is
being configured.
Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com> Signed-off-by: Michael Walle <michael@walle.cc> Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Michael Walle [Sun, 19 Jul 2020 22:03:35 +0000 (00:03 +0200)]
net: enetc: Initialize SerDes for SGMII and USXGMII protocols
ENETC has ethernet MACs capable of SGMII, 2500BaseX and USXGMII. But in
order to use these protocols some SerDes configurations need to be
performed. The SerDes is configurable via an internal PCS PHY which is
connected to an internal MDIO bus at address 0.
This patch basically removes the dependency on bootloader regarding
SerDes initialization.
Signed-off-by: Michael Walle <michael@walle.cc> Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com> Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Now that there are USXGMII constants available, drop the old definitions
and reuse the generic ones.
Signed-off-by: Michael Walle <michael@walle.cc> Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Michael Walle [Sun, 19 Jul 2020 22:03:33 +0000 (00:03 +0200)]
net: phy: add USXGMII link partner ability constants
The constants are taken from the USXGMII Singleport Copper Interface
specification. The naming are based on the SGMII ones, but with an MDIO_
prefix.
Signed-off-by: Michael Walle <michael@walle.cc> Reviewed-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>