platform/kernel/linux-rpi.git
3 years agonet: dsa: microchip: ksz8795: use reg_mib_cnt where possible
Michael Grzeschik [Tue, 1 Dec 2020 20:44:59 +0000 (21:44 +0100)]
net: dsa: microchip: ksz8795: use reg_mib_cnt where possible

The extra define SWITCH_COUNTER_NUM is a copy of the KSZ8795_COUNTER_NUM
define. This patch initializes reg_mib_cnt with KSZ8795_COUNTER_NUM,
makes use of reg_mib_cnt everywhere instead and removes the extra
define.

Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet: dsa: microchip: ksz8795: move variable assignments from detect to init
Michael Grzeschik [Tue, 1 Dec 2020 20:44:58 +0000 (21:44 +0100)]
net: dsa: microchip: ksz8795: move variable assignments from detect to init

This patch moves all variable assignments to the init function. It
leaves the detect function for its single purpose to detect which chip
version is found.

Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet: dsa: microchip: ksz8795: remove superfluous port_cnt assignment
Michael Grzeschik [Tue, 1 Dec 2020 20:44:57 +0000 (21:44 +0100)]
net: dsa: microchip: ksz8795: remove superfluous port_cnt assignment

The port_cnt assignment will be done again in the init function.
This patch removes the previous assignment in the detect function.

Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet: dsa: microchip: ksz8795: remove unused last_port variable
Michael Grzeschik [Tue, 1 Dec 2020 20:44:56 +0000 (21:44 +0100)]
net: dsa: microchip: ksz8795: remove unused last_port variable

The variable last_port is not used anywhere, this patch removes it.

Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet: ipa: fix build-time bug in ipa_hardware_config_qsb()
Alex Elder [Wed, 2 Dec 2020 14:15:02 +0000 (08:15 -0600)]
net: ipa: fix build-time bug in ipa_hardware_config_qsb()

Jon Hunter reported observing a build bug in the IPA driver:
  https://lore.kernel.org/netdev/5b5d9d40-94d5-5dad-b861-fd9bef8260e2@nvidia.com

The problem is that the QMB0 max read value set for IPA v4.5 (16) is
too large to fit in the 4-bit field.

The actual value we want is 0, which requests that the hardware use
the maximum it is capable of.

Reported-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Alex Elder <elder@linaro.org>
Link: https://lore.kernel.org/r/20201202141502.21265-1-elder@linaro.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agomptcp: avoid potential infinite loop in mptcp_recvmsg()
Eric Dumazet [Wed, 2 Dec 2020 17:16:57 +0000 (09:16 -0800)]
mptcp: avoid potential infinite loop in mptcp_recvmsg()

If a packet is ready in receive queue, and application isssues
a recvmsg()/recvfrom()/recvmmsg() request asking for zero bytes,
we hang in mptcp_recvmsg().

Fixes: ea4ca586b16f ("mptcp: refine MPTCP-level ack scheduling")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Tested-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Link: https://lore.kernel.org/r/20201202171657.1185108-1-eric.dumazet@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agoocteontx2-af: debugfs: delete dead code
Dan Carpenter [Wed, 2 Dec 2020 06:57:02 +0000 (09:57 +0300)]
octeontx2-af: debugfs: delete dead code

These debugfs never return NULL so all this code will never be run.

In the normal case, (and in this case particularly), the debugfs
functions are not supposed to be checked for errors so all this error
checking code can be safely deleted.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/X8c6vpapJDYI2eWI@mwanda
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agoNFC: nxp-nci: Make firmware GPIO pin optional
Frieder Schrempf [Tue, 1 Dec 2020 11:39:09 +0000 (12:39 +0100)]
NFC: nxp-nci: Make firmware GPIO pin optional

There are other NXP NCI compatible NFC controllers such as the PN7150
that use an integrated firmware and therefore do not have a GPIO to
select firmware downloading mode. To support this kind of controller,
let's make the firmware GPIO optional.

Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20201201113921.6572-1-frieder.schrempf@kontron.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agor8169: set tc_offset only if tally counter reset isn't supported
Heiner Kallweit [Tue, 1 Dec 2020 08:57:29 +0000 (09:57 +0100)]
r8169: set tc_offset only if tally counter reset isn't supported

On chip versions supporting tally counter reset we currently update
the counters after a reset although we know all counters are zero.
Skip this unnecessary step.

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/526618b2-b1bf-1844-b82a-dab2df7bdc8f@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agoMerge branch 'net-ipa-ipa-v4-5-aggregation-and-qtime'
Jakub Kicinski [Wed, 2 Dec 2020 02:05:38 +0000 (18:05 -0800)]
Merge branch 'net-ipa-ipa-v4-5-aggregation-and-qtime'

Alex Elder says:

====================
net: ipa: IPA v4.5 aggregation and Qtime

This series updates some IPA register definitions that change in
substantive ways for IPA v4.5.

One register defines parameters used by an endpoint to aggregate
multiple packets into a buffer.  The size and position of most
fields in that register have changed with this new hardware version,
and consequently the function that programs it needs to be done a
bit differently.  The first patch takes care of this.

Second, IPA v4.5 introduces a unified time keeping component to be
used in several places by the IPA hardware.  A main clock divider
provides a fundamental tick rate, and several timestamped features
now define their granularity based on that.  There is also a set of
"pulse generators" derived from the main tick, and these are used
to implement timers used for aggregation and head-of-line block
avoidance.  The second patch adds IPA register updates to support
Qtime along with its configuration, and the last two patches
configure the timers that use it.
====================

Link: https://lore.kernel.org/r/20201130233712.29113-1-elder@linaro.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet: ipa: use Qtime for IPA v4.5 head-of-line time limit
Alex Elder [Mon, 30 Nov 2020 23:37:12 +0000 (17:37 -0600)]
net: ipa: use Qtime for IPA v4.5 head-of-line time limit

Extend ipa_reg_init_hol_block_timer_val() so it properly calculates
the head-of-line block timeout to use for IPA v4.5.

Introduce hol_block_timer_qtime_val() to compute the value to use
for IPA v4.5, where Qtime is used as the basis of the timer.  Call
that function from hol_block_timer_val() for IPA v4.5.

Both of these are private functions, so shorten their names a bit so
they don't take up so much space on the line.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet: ipa: use Qtime for IPA v4.5 aggregation time limit
Alex Elder [Mon, 30 Nov 2020 23:37:11 +0000 (17:37 -0600)]
net: ipa: use Qtime for IPA v4.5 aggregation time limit

Change aggr_time_limit_encoded() to properly calculate the
aggregation time limit to use for IPA v4.5.

Older IPA versions program the AGGR_GRANULARITY field of the
of the COUNTER_CFG register to set the granularity of the
aggregation timer, which we configure to be 500 microseconds.

Instead, IPA v4.5 selects between two possible granularity values
derived from the 19.2 MHz Qtime clock.  These granularities are
100 microseconds or 1 millisecond per tick.  We use the smaller
granularity if possible, unless the desired period is too large
to be specified that way.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet: ipa: set up IPA v4.5 Qtime configuration
Alex Elder [Mon, 30 Nov 2020 23:37:10 +0000 (17:37 -0600)]
net: ipa: set up IPA v4.5 Qtime configuration

IPA v4.5 introduces a new unified timer architecture driven on the
19.2 MHz SoC crystal oscillator (XO).  It is independent of the IPA
core clock and avoids some duplication.

Lower-resolution time stamps are derived from this by using only the
high-order bits of the 19.2 MHz Qtime clock.  And timers are derived
from this based on "pulse generators" configured to fire at a fixed
rate based on the Qtime clock.

This patch introduces ipa_qtime_config(), which configures the Qtime
mechanism for use.  It also adds to the IPA register definitions
related to timers and time stamping.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet: ipa: update IPA aggregation registers for IPA v4.5
Alex Elder [Mon, 30 Nov 2020 23:37:09 +0000 (17:37 -0600)]
net: ipa: update IPA aggregation registers for IPA v4.5

IPA v4.5 significantly changes the format of the configuration
register used for endpoint aggregation.  The AGGR_BYTE_LIMIT field
is now larger, and the positions of other fields are shifted.  This
complicates the way we have to access this register because functions
like u32_encode_bits() require their field mask argument to be constant.

A further complication is that we want to know the maximum value
representable by at least one of these fields, and that too requires
a constant field mask.

This patch adds support for IPA v4.5 endpoint aggregation registers
in a way that continues to support "legacy" IPA hardware.  It does
so in a way that keeps field masks constant.

First, for each variable field mask, we define an inline function
whose return value is either the legacy value or the IPA v4.5 value.

Second, we define functions for these fields that encode a value
to use in each field based on the IPA version (this approach is
already used elsewhere).  The field mask provided is supplied by
the function mentioned above.

Finally, for the aggregation byte limit fields where we want to
know the maximum representable value, we define a function that
returns that maximum, computed from the appropriate field mask.

We can no longer verify at build time that our buffer size is
in the range that can be represented by the aggregation byte
limit field.  So remove the test done by a BUILD_BUG_ON() call
in ipa_endpoint_validate_build(), and implement a comparable check
at the top of ipa_endpoint_data_valid().

Doing that makes ipa_endpoint_validate_build() contain a single
line BUILD_BUG_ON() call, so just remove that function and move
the remaining line into ipa_endpoint_data_valid().

One final note:  the aggregation time limit value for IPA v4.5 needs
to be computed differently.  That is handled in an upcoming patch.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agoMerge branch 'net-smc-add-support-for-generic-netlink-api'
Jakub Kicinski [Wed, 2 Dec 2020 01:56:15 +0000 (17:56 -0800)]
Merge branch 'net-smc-add-support-for-generic-netlink-api'

Karsten Graul says:

====================
net/smc: Add support for generic netlink API

Up to version 4 this patch series was using the sock_diag netlink
infrastructure. This version is using the generic netlink API. Generic
netlink API offers a better type safety between kernel and userspace
communication.
Using the generic netlink API the smc module can now provide information
about SMC linkgroups, links and devices (both for SMC-R and SMC-D).

v2: Add missing include to uapi header smc_diag.h.

v3: Apply code style recommendations from review comments.
    Instead of using EXPORTs to allow the smc_diag module to access
    data of the smc module, introduce struct smc_diag_ops and let
    smc_diag access the required data using function pointers.

v4: Address checkpatch.pl warnings. Do not use static inline for
    functions.

v5: Use generic netlink API instead of the sock_diag netlink
    infrastructure.

v6: Integrate more review comments from Jakub.

v7: Use nla_nest_start() with the new family. Use .maxattr=1 in the
    genl family and define one entry for attribute 1 in the policy to
    reject this attritbute for all commands. All other possible attributes
    are rejected because NL_VALIDATE_STRICT is set for the policy
    implicitely, which includes NL_VALIDATE_MAXTYPE.
    Setting policy[0].strict_start_type=1 does not work here because there
    is no valid attribute defined for this family, only plain commands. For
    any type > maxtype (which is .maxattr) validate_nla() would return 0 to
    userspace instead of -EINVAL. What helps here is __nla_validate_parse()
    which checks for type > maxtype and returns -EINVAL when NL_VALIDATE_MAXTYPE
    is set. This requires the one entry for type == .maxattr with
    .type = NLA_REJECT in the nla_policy.
    When a future command wants to allow attributes then it can easily specify a
    dedicated .policy for this new command in the genl_ops array. This dedicated
    policy overlays the global policy specified in the genl_family structure.
====================

Link: https://lore.kernel.org/r/20201201192049.53517-1-kgraul@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet/smc: Add support for obtaining SMCR device list
Guvenc Gulce [Tue, 1 Dec 2020 19:20:49 +0000 (20:20 +0100)]
net/smc: Add support for obtaining SMCR device list

Deliver SMCR device information via netlink based
diagnostic interface.

Signed-off-by: Guvenc Gulce <guvenc@linux.ibm.com>
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet/smc: Add support for obtaining SMCD device list
Guvenc Gulce [Tue, 1 Dec 2020 19:20:48 +0000 (20:20 +0100)]
net/smc: Add support for obtaining SMCD device list

Deliver SMCD device information via netlink based
diagnostic interface.

Signed-off-by: Guvenc Gulce <guvenc@linux.ibm.com>
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet/smc: Add SMC-D Linkgroup diagnostic support
Guvenc Gulce [Tue, 1 Dec 2020 19:20:47 +0000 (20:20 +0100)]
net/smc: Add SMC-D Linkgroup diagnostic support

Deliver SMCD Linkgroup information via netlink based
diagnostic interface.

Signed-off-by: Guvenc Gulce <guvenc@linux.ibm.com>
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet/smc: Introduce SMCR get link command
Guvenc Gulce [Tue, 1 Dec 2020 19:20:46 +0000 (20:20 +0100)]
net/smc: Introduce SMCR get link command

Introduce get link command which loops through
all available links of all available link groups. It
uses the SMC-R linkgroup list as entry point, not
the socket list, which makes linkgroup diagnosis
possible, in case linkgroup does not contain active
connections anymore.

Signed-off-by: Guvenc Gulce <guvenc@linux.ibm.com>
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet/smc: Introduce SMCR get linkgroup command
Guvenc Gulce [Tue, 1 Dec 2020 19:20:45 +0000 (20:20 +0100)]
net/smc: Introduce SMCR get linkgroup command

Introduce get linkgroup command which loops through
all available SMCR linkgroups. It uses the SMC-R linkgroup
list as entry point, not the socket list, which makes
linkgroup diagnosis possible, in case linkgroup does not
contain active connections anymore.

Signed-off-by: Guvenc Gulce <guvenc@linux.ibm.com>
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet/smc: Add support for obtaining system information
Guvenc Gulce [Tue, 1 Dec 2020 19:20:44 +0000 (20:20 +0100)]
net/smc: Add support for obtaining system information

Add new netlink command to obtain system information
of the smc module.

Signed-off-by: Guvenc Gulce <guvenc@linux.ibm.com>
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet/smc: Introduce generic netlink interface for diagnostic purposes
Guvenc Gulce [Tue, 1 Dec 2020 19:20:43 +0000 (20:20 +0100)]
net/smc: Introduce generic netlink interface for diagnostic purposes

Introduce generic netlink interface infrastructure to expose
the diagnostic information regarding smc linkgroups, links and devices.

Signed-off-by: Guvenc Gulce <guvenc@linux.ibm.com>
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet/smc: Refactor smc ism v2 capability handling
Guvenc Gulce [Tue, 1 Dec 2020 19:20:42 +0000 (20:20 +0100)]
net/smc: Refactor smc ism v2 capability handling

Encapsulate the smc ism v2 capability boolean value
in a function for better information hiding.

Signed-off-by: Guvenc Gulce <guvenc@linux.ibm.com>
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet/smc: Add diagnostic information to link structure
Guvenc Gulce [Tue, 1 Dec 2020 19:20:41 +0000 (20:20 +0100)]
net/smc: Add diagnostic information to link structure

During link creation add net-device ifindex and ib-device
name to link structure. This is needed for diagnostic purposes.

When diagnostic information is gathered, we need to traverse
device, linkgroup and link structures, to be able to do that
we need to hold a spinlock for the linkgroup list, without this
diagnostic information in link structure, another device list
mutex holding would be necessary to dereference the device
pointer in the link structure which would be impossible when
holding a spinlock already.

Signed-off-by: Guvenc Gulce <guvenc@linux.ibm.com>
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet/smc: Add diagnostic information to smc ib-device
Guvenc Gulce [Tue, 1 Dec 2020 19:20:40 +0000 (20:20 +0100)]
net/smc: Add diagnostic information to smc ib-device

During smc ib-device creation, add network device ifindex to smc
ib-device structure. Register for netdevice changes and update ib-device
accordingly. This is needed for diagnostic purposes.

Signed-off-by: Guvenc Gulce <guvenc@linux.ibm.com>
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet/smc: Add link counters for IB device ports
Guvenc Gulce [Tue, 1 Dec 2020 19:20:39 +0000 (20:20 +0100)]
net/smc: Add link counters for IB device ports

Add link counters to the structure of the smc ib device, one counter per
ib port. Increase/decrease the counters as needed in the corresponding
routines.

Signed-off-by: Guvenc Gulce <guvenc@linux.ibm.com>
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet/smc: Add connection counters for links
Guvenc Gulce [Tue, 1 Dec 2020 19:20:38 +0000 (20:20 +0100)]
net/smc: Add connection counters for links

Add connection counters to the structure of the link.
Increase/decrease the counters as needed in the corresponding
routines.

Signed-off-by: Guvenc Gulce <guvenc@linux.ibm.com>
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet/smc: Use active link of the connection
Guvenc Gulce [Tue, 1 Dec 2020 19:20:37 +0000 (20:20 +0100)]
net/smc: Use active link of the connection

Use active link of the connection directly and not
via linkgroup array structure when obtaining link
data of the connection.

Signed-off-by: Guvenc Gulce <guvenc@linux.ibm.com>
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet/smc: use helper smc_conn_abort() in listen processing
Karsten Graul [Tue, 1 Dec 2020 19:20:36 +0000 (20:20 +0100)]
net/smc: use helper smc_conn_abort() in listen processing

The helper smc_connect_abort() can be used by the listen processing
functions, too. And rename this helper to smc_conn_abort() to make the
purpose clearer.
No functional change.

Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet/tls: make sure tls offload sets salt_size
Rohit Maheshwari [Tue, 1 Dec 2020 09:07:52 +0000 (14:37 +0530)]
net/tls: make sure tls offload sets salt_size

Recent changes made to remove AES constants started using protocol
aware salt_size. ctx->prot_info's salt_size is filled in tls sw case,
but not in tls offload mode, and was working so far because of the
hard coded value was used.

Fixes: 6942a284fb3e ("net/tls: make inline helpers protocol-aware")
Signed-off-by: Rohit Maheshwari <rohitm@chelsio.com>
Link: https://lore.kernel.org/r/20201201090752.27355-1-rohitm@chelsio.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agoMerge branch 'ionic-updates'
Jakub Kicinski [Wed, 2 Dec 2020 01:14:26 +0000 (17:14 -0800)]
Merge branch 'ionic-updates'

Shannon Nelson says:

====================
ionic updates

These are a pair of small code cleanups.
====================

Link: https://lore.kernel.org/r/20201201002546.4123-1-snelson@pensando.io
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agoionic: change mtu after queues are stopped
Shannon Nelson [Tue, 1 Dec 2020 00:25:46 +0000 (16:25 -0800)]
ionic: change mtu after queues are stopped

Order of operations is slightly more correct in the driver
to change the netdev->mtu after the queues have been stopped
rather than before.

Signed-off-by: Shannon Nelson <snelson@pensando.io>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agoionic: remove some unnecessary oom messages
Shannon Nelson [Tue, 1 Dec 2020 00:25:45 +0000 (16:25 -0800)]
ionic: remove some unnecessary oom messages

Remove memory allocation fail messages where the OOM stack
trace will make it obvious which allocation request failed.

Signed-off-by: Shannon Nelson <snelson@pensando.io>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet: phy: marvell: replace phy_modify()
Yejune Deng [Mon, 30 Nov 2020 10:41:35 +0000 (18:41 +0800)]
net: phy: marvell: replace phy_modify()

a set of phy_set_bits() looks more neater

Signed-off-by: Yejune Deng <yejune.deng@gmail.com>
Link: https://lore.kernel.org/r/1606732895-9136-1-git-send-email-yejune.deng@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agoMerge branch 's390-ctcm-updates-2020-11-30'
Jakub Kicinski [Wed, 2 Dec 2020 00:56:05 +0000 (16:56 -0800)]
Merge branch 's390-ctcm-updates-2020-11-30'

Julian Wiedmann says:

====================
s390/ctcm: updates 2020-11-30

Some rare ctcm updates by Sebastian, who cleans up all places where
in_interrupt() was used to determine the correct GFP_* mask for
allocations.
In the first three patches we can get rid of those allocations entirely,
as they just end up being copied into the skb.
====================

Link: https://lore.kernel.org/r/20201130100950.42051-1-jwi@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agos390/ctcm: Use GFP_ATOMIC in ctcmpc_tx().
Sebastian Andrzej Siewior [Mon, 30 Nov 2020 10:09:50 +0000 (11:09 +0100)]
s390/ctcm: Use GFP_ATOMIC in ctcmpc_tx().

gfp_type() uses in_interrupt() to figure out the correct GFP mask.

The usage of in_interrupt() in drivers is phased out and Linus clearly
requested that code which changes behaviour depending on context should
either be separated or the context be conveyed in an argument passed by the
caller, which usually knows the context.

ctcmpc_tx() is used as net_device_ops::ndo_start_xmit. This callback is
invoked with disabled bottom halves.

Use GFP_ATOMIC for memory allocation in ctcmpc_tx().
Remove gfp_type() since the last user is gone.

Reviewed-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agos390/ctcm: Use GFP_KERNEL in add_channel().
Sebastian Andrzej Siewior [Mon, 30 Nov 2020 10:09:49 +0000 (11:09 +0100)]
s390/ctcm: Use GFP_KERNEL in add_channel().

gfp_type() uses in_interrupt() to figure out the correct GFP mask.

The usage of in_interrupt() in drivers is phased out and Linus clearly
requested that code which changes behaviour depending on context should
either be separated or the context be conveyed in an argument passed by the
caller, which usually knows the context.

The memory allocation of `ch' a few lines above is using GFP_KERNEL,
also an allocation a few lines later is using GFP_KERNEL.

Use GFP_KERNEL for the memory allocation.

Reviewed-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agos390/ctcm: Use explicit allocation mask in ctcmpc_unpack_skb().
Sebastian Andrzej Siewior [Mon, 30 Nov 2020 10:09:48 +0000 (11:09 +0100)]
s390/ctcm: Use explicit allocation mask in ctcmpc_unpack_skb().

gfp_type() uses in_interrupt() to figure out the correct GFP mask.

The usage of in_interrupt() in drivers is phased out and Linus clearly
requested that code which changes behaviour depending on context should
either be separated or the context be conveyed in an argument passed by the
caller, which usually knows the context.

The call chain of ctcmpc_unpack_skb():
ctcmpc_bh()
 -> ctcmpc_unpack_skb()

ctcmpc_bh() is a tasklet handler so GFP_ATOMIC is needed.

Use GFP_ATOMIC as allocation type in ctcmpc_unpack_skb().

Reviewed-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agos390/ctcm: Avoid temporary allocation of struct pdu.
Sebastian Andrzej Siewior [Mon, 30 Nov 2020 10:09:47 +0000 (11:09 +0100)]
s390/ctcm: Avoid temporary allocation of struct pdu.

The size of struct pdu is 8 byte. The memory is allocated, initialized,
used and deallocated a few lines later.

It is more efficient to avoid the allocation/free dance and assign the
values directly to skb's data part instead of using memcpy() for it.

Avoid an allocation of struct pdu and use the resulting skb pointer
instead.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
[jwi: Fix-up the pdu_offset, adjust skb->len for the pushed length.
      Reflow the commit msg.]
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agos390/ctcm: Avoid temporary allocation of struct qllc.
Sebastian Andrzej Siewior [Mon, 30 Nov 2020 10:09:46 +0000 (11:09 +0100)]
s390/ctcm: Avoid temporary allocation of struct qllc.

The size of struct qllc is 2 byte. The memory for is allocated,
initialized, used and deallocated a few lines later.

It is more efficient to avoid the allocation/free dance and assign the
values directly to skb's data part instead of using memcpy() for it.

Avoid an allocation of struct qllc and use the resulting skb pointer
instead.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
[jwi: remove a newline, reflow the commit msg]
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agos390/ctcm: Avoid temporary allocation of struct th_header and th_sweep.
Sebastian Andrzej Siewior [Mon, 30 Nov 2020 10:09:45 +0000 (11:09 +0100)]
s390/ctcm: Avoid temporary allocation of struct th_header and th_sweep.

The size of struct th_header is 8 byte and the size of struct th_sweep
is 16 byte. The memory for is allocated, initialized, used and
deallocated a few lines later.

It is more efficient to avoid the allocation/free dance and assign the
values directly to skb's data part instead of using memcpy() for it.

Avoid an allocation of struct th_sweep/th_header and use the resulting
skb pointer instead.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
[jwi: use skb_put_zero(), instead of skb_put() + memset to 0]
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet: freescale: ucc_geth: remove unused SKB_ALLOC_TIMEOUT
Chris Packham [Mon, 30 Nov 2020 00:10:10 +0000 (13:10 +1300)]
net: freescale: ucc_geth: remove unused SKB_ALLOC_TIMEOUT

This was added in commit ce973b141dfa ("[PATCH] Freescale QE UCC gigabit
ethernet driver") but doesn't appear to have been used. Remove it now.

Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Link: https://lore.kernel.org/r/20201130001010.28998-1-chris.packham@alliedtelesis.co.nz
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet: delete __dev_getfirstbyhwtype
Vladimir Oltean [Sun, 29 Nov 2020 20:05:50 +0000 (22:05 +0200)]
net: delete __dev_getfirstbyhwtype

The last user of the RTNL brother of dev_getfirstbyhwtype (the latter
being synchronized under RCU) has been deleted in commit b4db2b35fc44
("afs: Use core kernel UUID generation").

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: David Howells <dhowells@redhat.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20201129200550.2433401-1-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agoMerge branch 'net-tipc-fix-all-kernel-doc-and-add-tipc-networking-chapter'
Jakub Kicinski [Tue, 1 Dec 2020 23:38:46 +0000 (15:38 -0800)]
Merge branch 'net-tipc-fix-all-kernel-doc-and-add-tipc-networking-chapter'

Randy Dunlap says:

====================
net/tipc: fix all kernel-doc and add TIPC networking chapter

Fix lots of net/tipc/ kernel-doc warnings. Add many struct field and
function parameter descriptions.

Then add a TIPC chapter to the networking documentation book.

All patches have been rebased to current net-next.

Note: some of the struct members and function parameters are marked
with "FIXME". They could use some additional descriptions if
someone could help add to them. Thanks.
====================

Link: https://lore.kernel.org/r/20201129183251.7049-1-rdunlap@infradead.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet/tipc: add TIPC chapter to networking Documentation
Randy Dunlap [Sun, 29 Nov 2020 18:32:51 +0000 (10:32 -0800)]
net/tipc: add TIPC chapter to networking Documentation

Add a TIPC chapter to the networking docbook.

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet/tipc: fix all function Return: notation
Randy Dunlap [Sun, 29 Nov 2020 18:32:48 +0000 (10:32 -0800)]
net/tipc: fix all function Return: notation

Fix Return: kernel-doc notation in all net/tipc/ source files.
Also keep ReST list notation intact for output formatting.
Fix a few typos in comments.

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet/tipc: fix socket.c kernel-doc
Randy Dunlap [Sun, 29 Nov 2020 18:32:49 +0000 (10:32 -0800)]
net/tipc: fix socket.c kernel-doc

Fix socket.c kernel-doc warnings in preparation for adding to the
networking docbook.

Also, for rcvbuf_limit(), use bullet notation so that the lines do
not run together.

../net/tipc/socket.c:130: warning: Function parameter or member 'cong_links' not described in 'tipc_sock'
../net/tipc/socket.c:130: warning: Function parameter or member 'probe_unacked' not described in 'tipc_sock'
../net/tipc/socket.c:130: warning: Function parameter or member 'snd_win' not described in 'tipc_sock'
../net/tipc/socket.c:130: warning: Function parameter or member 'peer_caps' not described in 'tipc_sock'
../net/tipc/socket.c:130: warning: Function parameter or member 'rcv_win' not described in 'tipc_sock'
../net/tipc/socket.c:130: warning: Function parameter or member 'group' not described in 'tipc_sock'
../net/tipc/socket.c:130: warning: Function parameter or member 'oneway' not described in 'tipc_sock'
../net/tipc/socket.c:130: warning: Function parameter or member 'nagle_start' not described in 'tipc_sock'
../net/tipc/socket.c:130: warning: Function parameter or member 'snd_backlog' not described in 'tipc_sock'
../net/tipc/socket.c:130: warning: Function parameter or member 'msg_acc' not described in 'tipc_sock'
../net/tipc/socket.c:130: warning: Function parameter or member 'pkt_cnt' not described in 'tipc_sock'
../net/tipc/socket.c:130: warning: Function parameter or member 'expect_ack' not described in 'tipc_sock'
../net/tipc/socket.c:130: warning: Function parameter or member 'nodelay' not described in 'tipc_sock'
../net/tipc/socket.c:130: warning: Function parameter or member 'group_is_open' not described in 'tipc_sock'
../net/tipc/socket.c:267: warning: Function parameter or member 'sk' not described in 'tsk_advance_rx_queue'
../net/tipc/socket.c:295: warning: Function parameter or member 'sk' not described in 'tsk_rej_rx_queue'
../net/tipc/socket.c:295: warning: Function parameter or member 'error' not described in 'tsk_rej_rx_queue'
../net/tipc/socket.c:894: warning: Function parameter or member 'tsk' not described in 'tipc_send_group_msg'
../net/tipc/socket.c:1187: warning: Function parameter or member 'net' not described in 'tipc_sk_mcast_rcv'
../net/tipc/socket.c:1323: warning: Function parameter or member 'inputq' not described in 'tipc_sk_conn_proto_rcv'
../net/tipc/socket.c:1323: warning: Function parameter or member 'xmitq' not described in 'tipc_sk_conn_proto_rcv'
../net/tipc/socket.c:1885: warning: Function parameter or member 'sock' not described in 'tipc_recvmsg'
../net/tipc/socket.c:1993: warning: Function parameter or member 'sock' not described in 'tipc_recvstream'
../net/tipc/socket.c:2313: warning: Function parameter or member 'xmitq' not described in 'tipc_sk_filter_rcv'
../net/tipc/socket.c:2404: warning: Function parameter or member 'xmitq' not described in 'tipc_sk_enqueue'
../net/tipc/socket.c:2456: warning: Function parameter or member 'net' not described in 'tipc_sk_rcv'
../net/tipc/socket.c:2693: warning: Function parameter or member 'kern' not described in 'tipc_accept'
../net/tipc/socket.c:3816: warning: Excess function parameter 'sysctl_tipc_sk_filter' description in 'tipc_sk_filtering'

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet/tipc: fix node.c kernel-doc
Randy Dunlap [Sun, 29 Nov 2020 18:32:47 +0000 (10:32 -0800)]
net/tipc: fix node.c kernel-doc

Fix node.c kernel-doc warnings in preparation for adding to the
networking docbook.

../net/tipc/node.c:141: warning: Function parameter or member 'kref' not described in 'tipc_node'
../net/tipc/node.c:141: warning: Function parameter or member 'bc_entry' not described in 'tipc_node'
../net/tipc/node.c:141: warning: Function parameter or member 'failover_sent' not described in 'tipc_node'
../net/tipc/node.c:141: warning: Function parameter or member 'peer_id' not described in 'tipc_node'
../net/tipc/node.c:141: warning: Function parameter or member 'peer_id_string' not described in 'tipc_node'
../net/tipc/node.c:141: warning: Function parameter or member 'conn_sks' not described in 'tipc_node'
../net/tipc/node.c:141: warning: Function parameter or member 'keepalive_intv' not described in 'tipc_node'
../net/tipc/node.c:141: warning: Function parameter or member 'timer' not described in 'tipc_node'
../net/tipc/node.c:141: warning: Function parameter or member 'peer_net' not described in 'tipc_node'
../net/tipc/node.c:141: warning: Function parameter or member 'peer_hash_mix' not described in 'tipc_node'
../net/tipc/node.c:273: warning: Function parameter or member '__n' not described in 'tipc_node_crypto_rx'
../net/tipc/node.c:822: warning: Function parameter or member 'n' not described in '__tipc_node_link_up'
../net/tipc/node.c:822: warning: Function parameter or member 'bearer_id' not described in '__tipc_node_link_up'
../net/tipc/node.c:822: warning: Function parameter or member 'xmitq' not described in '__tipc_node_link_up'
../net/tipc/node.c:888: warning: Function parameter or member 'n' not described in 'tipc_node_link_up'
../net/tipc/node.c:888: warning: Function parameter or member 'bearer_id' not described in 'tipc_node_link_up'
../net/tipc/node.c:888: warning: Function parameter or member 'xmitq' not described in 'tipc_node_link_up'
../net/tipc/node.c:948: warning: Function parameter or member 'n' not described in '__tipc_node_link_down'
../net/tipc/node.c:948: warning: Function parameter or member 'bearer_id' not described in '__tipc_node_link_down'
../net/tipc/node.c:948: warning: Function parameter or member 'xmitq' not described in '__tipc_node_link_down'
../net/tipc/node.c:948: warning: Function parameter or member 'maddr' not described in '__tipc_node_link_down'
../net/tipc/node.c:1537: warning: Function parameter or member 'net' not described in 'tipc_node_get_linkname'
../net/tipc/node.c:1537: warning: Function parameter or member 'len' not described in 'tipc_node_get_linkname'
../net/tipc/node.c:1891: warning: Function parameter or member 'n' not described in 'tipc_node_check_state'
../net/tipc/node.c:1891: warning: Function parameter or member 'xmitq' not described in 'tipc_node_check_state'

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet/tipc: fix name_table.c kernel-doc
Randy Dunlap [Sun, 29 Nov 2020 18:32:46 +0000 (10:32 -0800)]
net/tipc: fix name_table.c kernel-doc

Fix name_table.c kernel-doc warnings in preparation for adding to the
networking docbook.

../net/tipc/name_table.c:115: warning: Function parameter or member 'start' not described in 'service_range_foreach_match'
../net/tipc/name_table.c:115: warning: Function parameter or member 'end' not described in 'service_range_foreach_match'
../net/tipc/name_table.c:127: warning: Function parameter or member 'start' not described in 'service_range_match_first'
../net/tipc/name_table.c:127: warning: Function parameter or member 'end' not described in 'service_range_match_first'
../net/tipc/name_table.c:176: warning: Function parameter or member 'start' not described in 'service_range_match_next'
../net/tipc/name_table.c:176: warning: Function parameter or member 'end' not described in 'service_range_match_next'
../net/tipc/name_table.c:225: warning: Function parameter or member 'type' not described in 'tipc_publ_create'
../net/tipc/name_table.c:225: warning: Function parameter or member 'lower' not described in 'tipc_publ_create'
../net/tipc/name_table.c:225: warning: Function parameter or member 'upper' not described in 'tipc_publ_create'
../net/tipc/name_table.c:225: warning: Function parameter or member 'scope' not described in 'tipc_publ_create'
../net/tipc/name_table.c:225: warning: Function parameter or member 'node' not described in 'tipc_publ_create'
../net/tipc/name_table.c:225: warning: Function parameter or member 'port' not described in 'tipc_publ_create'
../net/tipc/name_table.c:225: warning: Function parameter or member 'key' not described in 'tipc_publ_create'
../net/tipc/name_table.c:252: warning: Function parameter or member 'type' not described in 'tipc_service_create'
../net/tipc/name_table.c:252: warning: Function parameter or member 'hd' not described in 'tipc_service_create'
../net/tipc/name_table.c:367: warning: Function parameter or member 'sr' not described in 'tipc_service_remove_publ'
../net/tipc/name_table.c:367: warning: Function parameter or member 'node' not described in 'tipc_service_remove_publ'
../net/tipc/name_table.c:367: warning: Function parameter or member 'key' not described in 'tipc_service_remove_publ'
../net/tipc/name_table.c:383: warning: Function parameter or member 'pa' not described in 'publication_after'
../net/tipc/name_table.c:383: warning: Function parameter or member 'pb' not described in 'publication_after'
../net/tipc/name_table.c:401: warning: Function parameter or member 'service' not described in 'tipc_service_subscribe'
../net/tipc/name_table.c:401: warning: Function parameter or member 'sub' not described in 'tipc_service_subscribe'
../net/tipc/name_table.c:546: warning: Function parameter or member 'net' not described in 'tipc_nametbl_translate'
../net/tipc/name_table.c:546: warning: Function parameter or member 'type' not described in 'tipc_nametbl_translate'
../net/tipc/name_table.c:546: warning: Function parameter or member 'instance' not described in 'tipc_nametbl_translate'
../net/tipc/name_table.c:546: warning: Function parameter or member 'dnode' not described in 'tipc_nametbl_translate'
../net/tipc/name_table.c:762: warning: Function parameter or member 'net' not described in 'tipc_nametbl_withdraw'
../net/tipc/name_table.c:762: warning: Function parameter or member 'type' not described in 'tipc_nametbl_withdraw'
../net/tipc/name_table.c:762: warning: Function parameter or member 'lower' not described in 'tipc_nametbl_withdraw'
../net/tipc/name_table.c:762: warning: Function parameter or member 'upper' not described in 'tipc_nametbl_withdraw'
../net/tipc/name_table.c:762: warning: Function parameter or member 'key' not described in 'tipc_nametbl_withdraw'
../net/tipc/name_table.c:796: warning: Function parameter or member 'sub' not described in 'tipc_nametbl_subscribe'
../net/tipc/name_table.c:826: warning: Function parameter or member 'sub' not described in 'tipc_nametbl_unsubscribe'
../net/tipc/name_table.c:876: warning: Function parameter or member 'net' not described in 'tipc_service_delete'
../net/tipc/name_table.c:876: warning: Function parameter or member 'sc' not described in 'tipc_service_delete'

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet/tipc: fix name_distr.c kernel-doc
Randy Dunlap [Sun, 29 Nov 2020 18:32:45 +0000 (10:32 -0800)]
net/tipc: fix name_distr.c kernel-doc

Fix name_distr.c kernel-doc warnings in preparation for adding to the
networking docbook.

../net/tipc/name_distr.c:55: warning: Function parameter or member 'i' not described in 'publ_to_item'
../net/tipc/name_distr.c:55: warning: Function parameter or member 'p' not described in 'publ_to_item'
../net/tipc/name_distr.c:70: warning: Function parameter or member 'net' not described in 'named_prepare_buf'
../net/tipc/name_distr.c:70: warning: Function parameter or member 'type' not described in 'named_prepare_buf'
../net/tipc/name_distr.c:70: warning: Function parameter or member 'size' not described in 'named_prepare_buf'
../net/tipc/name_distr.c:70: warning: Function parameter or member 'dest' not described in 'named_prepare_buf'
../net/tipc/name_distr.c:88: warning: Function parameter or member 'net' not described in 'tipc_named_publish'
../net/tipc/name_distr.c:88: warning: Function parameter or member 'publ' not described in 'tipc_named_publish'
../net/tipc/name_distr.c:116: warning: Function parameter or member 'net' not described in 'tipc_named_withdraw'
../net/tipc/name_distr.c:116: warning: Function parameter or member 'publ' not described in 'tipc_named_withdraw'
../net/tipc/name_distr.c:147: warning: Function parameter or member 'net' not described in 'named_distribute'
../net/tipc/name_distr.c:147: warning: Function parameter or member 'seqno' not described in 'named_distribute'
../net/tipc/name_distr.c:199: warning: Function parameter or member 'net' not described in 'tipc_named_node_up'
../net/tipc/name_distr.c:199: warning: Function parameter or member 'dnode' not described in 'tipc_named_node_up'
../net/tipc/name_distr.c:199: warning: Function parameter or member 'capabilities' not described in 'tipc_named_node_up'
../net/tipc/name_distr.c:225: warning: Function parameter or member 'net' not described in 'tipc_publ_purge'
../net/tipc/name_distr.c:225: warning: Function parameter or member 'publ' not described in 'tipc_publ_purge'
../net/tipc/name_distr.c:225: warning: Function parameter or member 'addr' not described in 'tipc_publ_purge'
../net/tipc/name_distr.c:272: warning: Function parameter or member 'net' not described in 'tipc_update_nametbl'
../net/tipc/name_distr.c:272: warning: Function parameter or member 'i' not described in 'tipc_update_nametbl'
../net/tipc/name_distr.c:272: warning: Function parameter or member 'node' not described in 'tipc_update_nametbl'
../net/tipc/name_distr.c:272: warning: Function parameter or member 'dtype' not described in 'tipc_update_nametbl'
../net/tipc/name_distr.c:353: warning: Function parameter or member 'net' not described in 'tipc_named_rcv'
../net/tipc/name_distr.c:353: warning: Function parameter or member 'namedq' not described in 'tipc_named_rcv'
../net/tipc/name_distr.c:353: warning: Function parameter or member 'rcv_nxt' not described in 'tipc_named_rcv'
../net/tipc/name_distr.c:353: warning: Function parameter or member 'open' not described in 'tipc_named_rcv'
../net/tipc/name_distr.c:383: warning: Function parameter or member 'net' not described in 'tipc_named_reinit'

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet/tipc: fix link.c kernel-doc
Randy Dunlap [Sun, 29 Nov 2020 18:32:44 +0000 (10:32 -0800)]
net/tipc: fix link.c kernel-doc

Fix link.c kernel-doc warnings in preparation for adding to the
networking docbook.

../net/tipc/link.c:200: warning: Function parameter or member 'session' not described in 'tipc_link'
../net/tipc/link.c:200: warning: Function parameter or member 'snd_nxt_state' not described in 'tipc_link'
../net/tipc/link.c:200: warning: Function parameter or member 'rcv_nxt_state' not described in 'tipc_link'
../net/tipc/link.c:200: warning: Function parameter or member 'in_session' not described in 'tipc_link'
../net/tipc/link.c:200: warning: Function parameter or member 'active' not described in 'tipc_link'
../net/tipc/link.c:200: warning: Function parameter or member 'if_name' not described in 'tipc_link'
../net/tipc/link.c:200: warning: Function parameter or member 'rst_cnt' not described in 'tipc_link'
../net/tipc/link.c:200: warning: Function parameter or member 'drop_point' not described in 'tipc_link'
../net/tipc/link.c:200: warning: Function parameter or member 'failover_reasm_skb' not described in 'tipc_link'
../net/tipc/link.c:200: warning: Function parameter or member 'failover_deferdq' not described in 'tipc_link'
../net/tipc/link.c:200: warning: Function parameter or member 'transmq' not described in 'tipc_link'
../net/tipc/link.c:200: warning: Function parameter or member 'backlog' not described in 'tipc_link'
../net/tipc/link.c:200: warning: Function parameter or member 'snd_nxt' not described in 'tipc_link'
../net/tipc/link.c:200: warning: Function parameter or member 'rcv_unacked' not described in 'tipc_link'
../net/tipc/link.c:200: warning: Function parameter or member 'deferdq' not described in 'tipc_link'
../net/tipc/link.c:200: warning: Function parameter or member 'window' not described in 'tipc_link'
../net/tipc/link.c:200: warning: Function parameter or member 'min_win' not described in 'tipc_link'
../net/tipc/link.c:200: warning: Function parameter or member 'ssthresh' not described in 'tipc_link'
../net/tipc/link.c:200: warning: Function parameter or member 'max_win' not described in 'tipc_link'
../net/tipc/link.c:200: warning: Function parameter or member 'cong_acks' not described in 'tipc_link'
../net/tipc/link.c:200: warning: Function parameter or member 'checkpoint' not described in 'tipc_link'
../net/tipc/link.c:200: warning: Function parameter or member 'reasm_tnlmsg' not described in 'tipc_link'
../net/tipc/link.c:200: warning: Function parameter or member 'last_gap' not described in 'tipc_link'
../net/tipc/link.c:200: warning: Function parameter or member 'last_ga' not described in 'tipc_link'
../net/tipc/link.c:200: warning: Function parameter or member 'bc_rcvlink' not described in 'tipc_link'
../net/tipc/link.c:200: warning: Function parameter or member 'bc_sndlink' not described in 'tipc_link'
../net/tipc/link.c:200: warning: Function parameter or member 'nack_state' not described in 'tipc_link'
../net/tipc/link.c:200: warning: Function parameter or member 'bc_peer_is_up' not described in 'tipc_link'
../net/tipc/link.c:473: warning: Function parameter or member 'self' not described in 'tipc_link_create'
../net/tipc/link.c:473: warning: Function parameter or member 'peer_id' not described in 'tipc_link_create'
../net/tipc/link.c:473: warning: Excess function parameter 'ownnode' description in 'tipc_link_create'
../net/tipc/link.c:544: warning: Function parameter or member 'ownnode' not described in 'tipc_link_bc_create'
../net/tipc/link.c:544: warning: Function parameter or member 'peer' not described in 'tipc_link_bc_create'
../net/tipc/link.c:544: warning: Function parameter or member 'peer_id' not described in 'tipc_link_bc_create'
../net/tipc/link.c:544: warning: Function parameter or member 'peer_caps' not described in 'tipc_link_bc_create'
../net/tipc/link.c:544: warning: Function parameter or member 'bc_sndlink' not described in 'tipc_link_bc_create'

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet/tipc: fix bearer.c for kernel-doc
Randy Dunlap [Sun, 29 Nov 2020 18:32:42 +0000 (10:32 -0800)]
net/tipc: fix bearer.c for kernel-doc

Fix kernel-doc warnings in bearer.c:

../net/tipc/bearer.c:77: warning: Function parameter or member 'name' not described in 'tipc_media_find'
../net/tipc/bearer.c:91: warning: Function parameter or member 'type' not described in 'media_find_id'
../net/tipc/bearer.c:105: warning: Function parameter or member 'buf' not described in 'tipc_media_addr_printf'
../net/tipc/bearer.c:105: warning: Function parameter or member 'len' not described in 'tipc_media_addr_printf'
../net/tipc/bearer.c:105: warning: Function parameter or member 'a' not described in 'tipc_media_addr_printf'
../net/tipc/bearer.c:174: warning: Function parameter or member 'net' not described in 'tipc_bearer_find'
../net/tipc/bearer.c:174: warning: Function parameter or member 'name' not described in 'tipc_bearer_find'
../net/tipc/bearer.c:238: warning: Function parameter or member 'net' not described in 'tipc_enable_bearer'
../net/tipc/bearer.c:238: warning: Function parameter or member 'name' not described in 'tipc_enable_bearer'
../net/tipc/bearer.c:238: warning: Function parameter or member 'disc_domain' not described in 'tipc_enable_bearer'
../net/tipc/bearer.c:238: warning: Function parameter or member 'prio' not described in 'tipc_enable_bearer'
../net/tipc/bearer.c:238: warning: Function parameter or member 'attr' not described in 'tipc_enable_bearer'
../net/tipc/bearer.c:350: warning: Function parameter or member 'net' not described in 'tipc_reset_bearer'
../net/tipc/bearer.c:350: warning: Function parameter or member 'b' not described in 'tipc_reset_bearer'
../net/tipc/bearer.c:374: warning: Function parameter or member 'net' not described in 'bearer_disable'
../net/tipc/bearer.c:374: warning: Function parameter or member 'b' not described in 'bearer_disable'
../net/tipc/bearer.c:462: warning: Function parameter or member 'net' not described in 'tipc_l2_send_msg'
../net/tipc/bearer.c:479: warning: Function parameter or member 'net' not described in 'tipc_l2_send_msg'

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet/tipc: fix various kernel-doc warnings
Randy Dunlap [Sun, 29 Nov 2020 18:32:50 +0000 (10:32 -0800)]
net/tipc: fix various kernel-doc warnings

kernel-doc and Sphinx fixes to eliminate lots of warnings
in preparation for adding to the networking docbook.

../net/tipc/crypto.c:57: warning: cannot understand function prototype: 'enum '
../net/tipc/crypto.c:69: warning: cannot understand function prototype: 'enum '
../net/tipc/crypto.c:130: warning: Function parameter or member 'tfm' not described in 'tipc_tfm'
../net/tipc/crypto.c:130: warning: Function parameter or member 'list' not described in 'tipc_tfm'
../net/tipc/crypto.c:172: warning: Function parameter or member 'stat' not described in 'tipc_crypto_stats'
../net/tipc/crypto.c:232: warning: Function parameter or member 'flags' not described in 'tipc_crypto'
../net/tipc/crypto.c:329: warning: Function parameter or member 'ukey' not described in 'tipc_aead_key_validate'
../net/tipc/crypto.c:329: warning: Function parameter or member 'info' not described in 'tipc_aead_key_validate'
../net/tipc/crypto.c:482: warning: Function parameter or member 'aead' not described in 'tipc_aead_tfm_next'
../net/tipc/trace.c:43: warning: cannot understand function prototype: 'unsigned long sysctl_tipc_sk_filter[5] __read_mostly = '

Documentation/networking/tipc:57: ../net/tipc/msg.c:584: WARNING: Unexpected indentation.
Documentation/networking/tipc:63: ../net/tipc/name_table.c:536: WARNING: Unexpected indentation.
Documentation/networking/tipc:63: ../net/tipc/name_table.c:537: WARNING: Block quote ends without a blank line; unexpected unindent.
Documentation/networking/tipc:78: ../net/tipc/socket.c:3809: WARNING: Unexpected indentation.
Documentation/networking/tipc:78: ../net/tipc/socket.c:3807: WARNING: Inline strong start-string without end-string.
Documentation/networking/tipc:72: ../net/tipc/node.c:904: WARNING: Unexpected indentation.
Documentation/networking/tipc:39: ../net/tipc/crypto.c:97: WARNING: Block quote ends without a blank line; unexpected unindent.
Documentation/networking/tipc:39: ../net/tipc/crypto.c:98: WARNING: Block quote ends without a blank line; unexpected unindent.
Documentation/networking/tipc:39: ../net/tipc/crypto.c:141: WARNING: Inline strong start-string without end-string.

../net/tipc/discover.c:82: warning: Function parameter or member 'skb' not described in 'tipc_disc_init_msg'

../net/tipc/msg.c:69: warning: Function parameter or member 'gfp' not described in 'tipc_buf_acquire'
../net/tipc/msg.c:382: warning: Function parameter or member 'offset' not described in 'tipc_msg_build'
../net/tipc/msg.c:708: warning: Function parameter or member 'net' not described in 'tipc_msg_lookup_dest'

../net/tipc/subscr.c:65: warning: Function parameter or member 'seq' not described in 'tipc_sub_check_overlap'
../net/tipc/subscr.c:65: warning: Function parameter or member 'found_lower' not described in 'tipc_sub_check_overlap'
../net/tipc/subscr.c:65: warning: Function parameter or member 'found_upper' not described in 'tipc_sub_check_overlap'

../net/tipc/udp_media.c:75: warning: Function parameter or member 'proto' not described in 'udp_media_addr'
../net/tipc/udp_media.c:75: warning: Function parameter or member 'port' not described in 'udp_media_addr'
../net/tipc/udp_media.c:75: warning: Function parameter or member 'ipv4' not described in 'udp_media_addr'
../net/tipc/udp_media.c:75: warning: Function parameter or member 'ipv6' not described in 'udp_media_addr'
../net/tipc/udp_media.c:98: warning: Function parameter or member 'rcast' not described in 'udp_bearer'

Also fixed a typo of "duest" to "dest".

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet/tipc: fix tipc header files for kernel-doc
Randy Dunlap [Sun, 29 Nov 2020 18:32:43 +0000 (10:32 -0800)]
net/tipc: fix tipc header files for kernel-doc

Fix tipc header files for adding to the networking docbook.

Remove some uses of "/**" that were not kernel-doc notation.

Fix some source formatting to eliminate Sphinx warnings.

Add missing struct member and function argument kernel-doc descriptions.

Correct the description of a couple of struct members that were
marked as "(FIXME)".

Documentation/networking/tipc:18: ../net/tipc/name_table.h:65: WARNING: Unexpected indentation.
Documentation/networking/tipc:18: ../net/tipc/name_table.h:66: WARNING: Block quote ends without a blank line; unexpected unindent.

../net/tipc/bearer.h:128: warning: Function parameter or member 'min_win' not described in 'tipc_media'
../net/tipc/bearer.h:128: warning: Function parameter or member 'max_win' not described in 'tipc_media'

../net/tipc/bearer.h:171: warning: Function parameter or member 'min_win' not described in 'tipc_bearer'
../net/tipc/bearer.h:171: warning: Function parameter or member 'max_win' not described in 'tipc_bearer'
../net/tipc/bearer.h:171: warning: Function parameter or member 'disc' not described in 'tipc_bearer'
../net/tipc/bearer.h:171: warning: Function parameter or member 'up' not described in 'tipc_bearer'
../net/tipc/bearer.h:171: warning: Function parameter or member 'refcnt' not described in 'tipc_bearer'

../net/tipc/name_distr.h:68: warning: Function parameter or member 'port' not described in 'distr_item'

../net/tipc/name_table.h:111: warning: Function parameter or member 'services' not described in 'name_table'
../net/tipc/name_table.h:111: warning: Function parameter or member 'cluster_scope_lock' not described in 'name_table'
../net/tipc/name_table.h:111: warning: Function parameter or member 'rc_dests' not described in 'name_table'
../net/tipc/name_table.h:111: warning: Function parameter or member 'snd_nxt' not described in 'name_table'

../net/tipc/subscr.h:67: warning: Function parameter or member 'kref' not described in 'tipc_subscription'
../net/tipc/subscr.h:67: warning: Function parameter or member 'net' not described in 'tipc_subscription'
../net/tipc/subscr.h:67: warning: Function parameter or member 'service_list' not described in 'tipc_subscription'
../net/tipc/subscr.h:67: warning: Function parameter or member 'conid' not described in 'tipc_subscription'
../net/tipc/subscr.h:67: warning: Function parameter or member 'inactive' not described in 'tipc_subscription'
../net/tipc/subscr.h:67: warning: Function parameter or member 'lock' not described in 'tipc_subscription'

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agoMerge branch 'mlxsw-add-support-for-802-1ad-bridging'
Jakub Kicinski [Tue, 1 Dec 2020 23:21:15 +0000 (15:21 -0800)]
Merge branch 'mlxsw-add-support-for-802-1ad-bridging'

Ido Schimmel says:

====================
mlxsw: Add support for 802.1ad bridging

802.1ad, also known as QinQ, is an extension to the 802.1q standard,
which is concerned with passing possibly 802.1q-tagged packets through
another VLAN-like tunnel. The format of 802.1ad tag is the same as
802.1q, except it uses the EtherType of 0x88a8, unlike 802.1q's 0x8100.

Currently, mlxsw supports bridging with VLAN-unaware (802.1d) bridges
and with VLAN-aware bridges whose VLAN protocol is 802.1q. This set adds
support for VLAN-aware bridges whose VLAN protocol is 802.1ad.

From mlxsw perspective, 802.1ad support entails two main changes:

1. Ports member in an 802.1ad bridge need to be configured to classify
802.1ad packets as tagged and all other packets as untagged

2. When pushing a VLAN at ingress (PVID), its EtherType needs to be
0x88a8 instead of 802.1q's 0x8100

The rest stays the same as with 802.1q bridges.

A follow-up patch set will add support for QinQ with VXLAN, also known
as QinVNI. Currently, linking of a VXLAN netdev to an 802.1ad bridge is
vetoed and an error is returned to user space.

Patch set overview:

Patches #1-#2 add the registers required to configure the two changes
described above.

Patch #3 changes the device to only treat 802.1q packets as tagged by
default, as opposed to both 802.1q and 802.1ad packets. This is more
inline with the behavior supported by the driver.

Patch #4 adds the ability to configure the EtherType when pushing a PVID
at ingress.

Patch #5 performs small refactoring to allow for code re-use in the next
patch.

Patch #6 adds support for 802.1ad bridging and allows mlxsw ports and
their uppers to join such a bridge.

Patch #7 changes the bridge driver to notify about changes to its VLAN
protocol, so that these could be vetoed by mlxsw in the next patch.

Patches #8-#9 teach mlxsw to veto unsupported 802.1ad configurations and
add a corresponding selftest to make sure such configurations are indeed
vetoed.
====================

Link: https://lore.kernel.org/r/20201129125407.1391557-1-idosch@idosch.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agoselftests: forwarding: Add QinQ veto testing
Danielle Ratson [Sun, 29 Nov 2020 12:54:07 +0000 (14:54 +0200)]
selftests: forwarding: Add QinQ veto testing

Test that each veto that was added in the previous patch, is indeed
vetoed.

$ ./q_in_q_veto.sh

TEST: create 802.1ad vlan upper on top of a front panel             [ OK ]
TEST: create 802.1ad vlan upper on top of a bridge port             [ OK ]
TEST: create 802.1ad vlan upper on top of a lag                     [ OK ]
TEST: create 802.1ad vlan upper on top 802.1q bridge                [ OK ]
TEST: create 802.1ad vlan upper on top 802.1ad bridge               [ OK ]
TEST: create 802.1q vlan upper on top 802.1ad bridge                [ OK ]
TEST: create vlan upper on top of front panel enslaved to 802.1ad bridge
[ OK ]
TEST: create vlan upper on top of lag enslaved to 802.1ad bridge    [ OK ]
TEST: enslave front panel with vlan upper to 802.1ad bridge         [ OK ]
TEST: enslave lag with vlan upper to 802.1ad bridge                 [ OK ]
TEST: IP address addition to 802.1ad bridge                         [ OK ]
TEST: switch bridge protocol                                        [ OK ]

Signed-off-by: Danielle Ratson <danieller@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agomlxsw: Add QinQ configuration vetoes
Danielle Ratson [Sun, 29 Nov 2020 12:54:06 +0000 (14:54 +0200)]
mlxsw: Add QinQ configuration vetoes

After adding support for QinQ, a.k.a 802.1ad protocol, there are a few
scenarios that should be vetoed.

The vetoes are motivated by various ASIC limitations.
For example, a port that is member in a 802.1ad bridge cannot have 802.1q
uppers as the port needs to be configured to treat 802.1q packets as
untagged packets.

Veto all those unsupported scenarios and return suitable messages.

Signed-off-by: Danielle Ratson <danieller@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agobridge: switchdev: Notify about VLAN protocol changes
Danielle Ratson [Sun, 29 Nov 2020 12:54:05 +0000 (14:54 +0200)]
bridge: switchdev: Notify about VLAN protocol changes

Drivers that support bridge offload need to be notified about changes to
the bridge's VLAN protocol so that they could react accordingly and
potentially veto the change.

Add a new switchdev attribute to communicate the change to drivers.

Signed-off-by: Danielle Ratson <danieller@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Ivan Vecera <ivecera@redhat.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agomlxsw: spectrum_switchdev: Add support of QinQ traffic
Amit Cohen [Sun, 29 Nov 2020 12:54:04 +0000 (14:54 +0200)]
mlxsw: spectrum_switchdev: Add support of QinQ traffic

802.1ad, also known as QinQ is an extension to the 802.1q standard, which
is concerned with passing possibly 802.1q-tagged packets through another
VLAN-like tunnel. The format of 802.1ad tag is the same as 802.1q, except
it uses the EtherType of 0x88a8, unlike 802.1q's 0x8100.

Add support for 802.1ad protocol. Most of the configuration is the same
as 802.1q. The difference is that before a port joins an 802.1ad bridge it
needs to be configured to recognize 802.1ad packets as tagged and other
packets (e.g., 802.1q) as untagged.

VXLAN is not currently supported with 802.1ad bridge, so return an error
with an appropriate extack message.

Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agomlxsw: spectrum_switchdev: Create common functions for VLAN-aware bridge
Amit Cohen [Sun, 29 Nov 2020 12:54:03 +0000 (14:54 +0200)]
mlxsw: spectrum_switchdev: Create common functions for VLAN-aware bridge

The code in mlxsw_sp_bridge_8021q_port_{join, leave}() can be used also
for 802.1ad bridge.

Move the code to functions called
mlxsw_sp_bridge_vlan_aware_port_{join, leave}() and call them from
mlxsw_sp_bridge_8021q_port_{join, leave}() respectively to enable code
reuse.

Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agomlxsw: Make EtherType configurable when pushing VLAN at ingress
Amit Cohen [Sun, 29 Nov 2020 12:54:02 +0000 (14:54 +0200)]
mlxsw: Make EtherType configurable when pushing VLAN at ingress

Currently, when pushing a PVID at ingress, mlxsw always uses 802.1q
EtherType.

Make this EtherType configurable by extending mlxsw_sp_port_pvid_set()
with an EtherType argument.

This is a preparation for QinQ support, that needs to push a PVID with
802.1ad EtherType.

Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agomlxsw: spectrum: Only treat 802.1q packets as tagged packets
Amit Cohen [Sun, 29 Nov 2020 12:54:01 +0000 (14:54 +0200)]
mlxsw: spectrum: Only treat 802.1q packets as tagged packets

By default, the device considers both 802.1ad and 802.1q packets as tagged,
but this is not supported by the driver. It only supports VLAN and bridge
devices that use 802.1q protocol.

Instead, configure the device to only treat 802.1q packets as tagged
packets.

Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agomlxsw: reg: Add et_vlan field to SPVID register
Amit Cohen [Sun, 29 Nov 2020 12:54:00 +0000 (14:54 +0200)]
mlxsw: reg: Add et_vlan field to SPVID register

et_vlan field is used to configure which EtherType is used when VLAN is
pushed at ingress (for untagged packets or for QinQ push mode).

It will be used to configure tagging with ether_type1 (i.e., 0x88A8) for
QinQ mode.

Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agomlxsw: reg: Add Switch Port VLAN Classification Register
Amit Cohen [Sun, 29 Nov 2020 12:53:59 +0000 (14:53 +0200)]
mlxsw: reg: Add Switch Port VLAN Classification Register

SPVC configures the port to identify packets as untagged / single tagged /
double tagged packets based on the packet EtherTypes.

It will be used to classify 802.1q packets as untagged and 802.1ad packets
as tagged when received by ports member in a 802.1ad bridge.

Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agoMerge branch 'net-hns3-updates-for-next'
Jakub Kicinski [Tue, 1 Dec 2020 23:16:33 +0000 (15:16 -0800)]
Merge branch 'net-hns3-updates-for-next'

Huazhong Tan says:

====================
net: hns3: updates for -next

This series includes some updates for the HNS3 ethernet driver.

 #1~#6: add some updates related to the checksum offload.
 #7: add support for multiple TCs' MAC pauce mode.
====================

Link: https://lore.kernel.org/r/1606535510-44346-1-git-send-email-tanhuazhong@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet: hns3: keep MAC pause mode when multiple TCs are enabled
Yonglong Liu [Sat, 28 Nov 2020 03:51:50 +0000 (11:51 +0800)]
net: hns3: keep MAC pause mode when multiple TCs are enabled

Bellow HNAE3_DEVICE_VERSION_V3, MAC pause mode just support one
TC, when enabled multiple TCs, force enable PFC mode.

HNAE3_DEVICE_VERSION_V3 can support MAC pause mode on multiple
TCs, so when enable multiple TCs, just keep MAC pause mode,
and enable PFC mode just according to the user settings.

Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet: hns3: add a check for devcie's verion in hns3_tunnel_csum_bug()
Huazhong Tan [Sat, 28 Nov 2020 03:51:49 +0000 (11:51 +0800)]
net: hns3: add a check for devcie's verion in hns3_tunnel_csum_bug()

For the device whose version is above V3(include V3), the hardware
can do checksum offload for the non-tunnel udp packet, who has
a dest port as the IANA assigned. So add a check for devcie's verion
in hns3_tunnel_csum_bug().

Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet: hns3: add more info to hns3_dbg_bd_info()
Huazhong Tan [Sat, 28 Nov 2020 03:51:48 +0000 (11:51 +0800)]
net: hns3: add more info to hns3_dbg_bd_info()

Since TX hardware checksum and RX completion checksum have been
supported now, so add related information in hns3_dbg_bd_info().

Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet: hns3: add udp tunnel checksum segmentation support
Huazhong Tan [Sat, 28 Nov 2020 03:51:47 +0000 (11:51 +0800)]
net: hns3: add udp tunnel checksum segmentation support

For the device who has the capability to handle udp tunnel
checksum segmentation, add support for it.

Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet: hns3: remove unsupported NETIF_F_GSO_UDP_TUNNEL_CSUM
Huazhong Tan [Sat, 28 Nov 2020 03:51:46 +0000 (11:51 +0800)]
net: hns3: remove unsupported NETIF_F_GSO_UDP_TUNNEL_CSUM

Currently, device V1 and V2 do not support segmentation
offload for UDP based tunnel packet who needs outer UDP
checksum offload, so there is a workaround in the driver
to set the checksum of the outer UDP checksum as zero. This
is not what the user wants, so remove this feature for
device V1 and V2, add support for it later(when the device
has the ability to do that).

Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet: hns3: add support for TX hardware checksum offload
Huazhong Tan [Sat, 28 Nov 2020 03:51:45 +0000 (11:51 +0800)]
net: hns3: add support for TX hardware checksum offload

For the device that supports TX hardware checksum, the hardware
can calculate the checksum from the start and fill the checksum
to the offset position, which reduces the operations of
calculating the type and header length of L3/L4. So add this
feature for the HNS3 ethernet driver.

The previous simple BD description is unsuitable, rename it as
HW TX CSUM.

Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet: hns3: add support for RX completion checksum
Huazhong Tan [Sat, 28 Nov 2020 03:51:44 +0000 (11:51 +0800)]
net: hns3: add support for RX completion checksum

In some cases (for example ip fragment), hardware will
calculate the checksum of whole packet in RX, and setup
the HNS3_RXD_L2_CSUM_B flag in the descriptor, so add
support to utilize this checksum.

Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet/ipv6: propagate user pointer annotation
Lukas Bulwahn [Fri, 27 Nov 2020 09:34:21 +0000 (10:34 +0100)]
net/ipv6: propagate user pointer annotation

For IPV6_2292PKTOPTIONS, do_ipv6_getsockopt() stores the user pointer
optval in the msg_control field of the msghdr.

Hence, sparse rightfully warns at ./net/ipv6/ipv6_sockglue.c:1151:33:

  warning: incorrect type in assignment (different address spaces)
      expected void *msg_control
      got char [noderef] __user *optval

Since commit 1f466e1f15cf ("net: cleanly handle kernel vs user buffers for
->msg_control"), user pointers shall be stored in the msg_control_user
field, and kernel pointers in the msg_control field. This allows to
propagate __user annotations nicely through this struct.

Store optval in msg_control_user to properly record and propagate the
memory space annotation of this pointer.

Note that msg_control_is_user is set to true, so the key invariant, i.e.,
use msg_control_user if and only if msg_control_is_user is true, holds.

The msghdr is further used in the six alternative put_cmsg() calls, with
msg_control_is_user being true, put_cmsg() picks msg_control_user
preserving the __user annotation and passes that properly to
copy_to_user().

No functional change. No change in object code.

Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20201127093421.21673-1-lukas.bulwahn@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet: switch to storing KCOV handle directly in sk_buff
Marco Elver [Wed, 25 Nov 2020 22:48:40 +0000 (23:48 +0100)]
net: switch to storing KCOV handle directly in sk_buff

It turns out that usage of skb extensions can cause memory leaks. Ido
Schimmel reported: "[...] there are instances that blindly overwrite
'skb->extensions' by invoking skb_copy_header() after __alloc_skb()."

Therefore, give up on using skb extensions for KCOV handle, and instead
directly store kcov_handle in sk_buff.

Fixes: 6370cc3bbd8a ("net: add kcov handle to skb extensions")
Fixes: 85ce50d337d1 ("net: kcov: don't select SKB_EXTENSIONS when there is no NET")
Fixes: 97f53a08cba1 ("net: linux/skbuff.h: combine SKB_EXTENSIONS + KCOV handling")
Link: https://lore.kernel.org/linux-wireless/20201121160941.GA485907@shredder.lan/
Reported-by: Ido Schimmel <idosch@idosch.org>
Signed-off-by: Marco Elver <elver@google.com>
Link: https://lore.kernel.org/r/20201125224840.2014773-1-elver@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet: sched: remove redundant 'rtnl_held' argument
Vlad Buslov [Fri, 27 Nov 2020 15:12:05 +0000 (17:12 +0200)]
net: sched: remove redundant 'rtnl_held' argument

Functions tfilter_notify_chain() and tcf_get_next_proto() are always called
with rtnl lock held in current implementation. Moreover, attempting to call
them without rtnl lock would cause a warning down the call chain in
function __tcf_get_next_proto() that requires the lock to be held by
callers. Remove the 'rtnl_held' argument in order to simplify the code and
make rtnl lock requirement explicit.

Signed-off-by: Vlad Buslov <vladbu@nvidia.com>
Link: https://lore.kernel.org/r/20201127151205.23492-1-vladbu@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agoMerge tag 'linux-can-next-for-5.11-20201130' of git://git.kernel.org/pub/scm/linux...
Jakub Kicinski [Tue, 1 Dec 2020 03:03:31 +0000 (19:03 -0800)]
Merge tag 'linux-can-next-for-5.11-20201130' of git://git./linux/kernel/git/mkl/linux-can-next

Marc Kleine-Budde says:

====================
pull-request: can-next 2020-11-30

Gustavo A. R. Silva's patch for the pcan_usb driver fixes fall-through warnings
for Clang.

The next 5 patches target the mcp251xfd driver and are by Ursula Maplehurst and
me. They optimizie the TEF and RX path by reducing number of SPI core requests
to set the UINC bit.

The remaining 8 patches target the m_can driver. The first 4 are various
cleanups for the SPI binding driver (tcan4x5x) by Sean Nyekjaer, Dan Murphy and
me. Followed by 4 cleanup patches by me for the m_can and m_can_platform
driver.

* tag 'linux-can-next-for-5.11-20201130' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next:
  can: m_can: m_can_class_unregister(): move right after m_can_class_register()
  can: m_can: m_can_plat_remove(): remove unneeded platform_set_drvdata()
  can: m_can: remove not used variable struct m_can_classdev::freq
  can: m_can: Kconfig: convert the into menu
  can: tcan4x5x: tcan4x5x_can_probe(): remove probe failed error message
  can: tcan4x5x: remove mram_start and reg_offset from struct tcan4x5x_priv
  can: tcan4x5x: rename parse_config() function
  can: tcan4x5x: tcan4x5x_clear_interrupts(): remove redundant return statement
  can: mcp251xfd: tef-path: reduce number of SPI core requests to set UINC bit
  can: mcp251xfd: move struct mcp251xfd_tef_ring definition
  can: mcp251xfd: struct mcp251xfd_priv::tef to array of length 1
  can: mcp25xxfd: rx-path: reduce number of SPI core requests to set UINC bit
  can: mcp251xfd: mcp25xxfd_ring_alloc(): add define instead open coding the maximum number of RX objects
  can: pcan_usb_core: fix fall-through warnings for Clang
====================

Link: https://lore.kernel.org/r/20201130141432.278219-1-mkl@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agonet: wan: remove trailing semicolon in macro definition
Tom Rix [Fri, 27 Nov 2020 16:57:34 +0000 (08:57 -0800)]
net: wan: remove trailing semicolon in macro definition

The macro use will already have a semicolon.

Signed-off-by: Tom Rix <trix@redhat.com>
Link: https://lore.kernel.org/r/20201127165734.2694693-1-trix@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agoMerge branch 'mptcp-avoid-workqueue-usage-for-data'
Jakub Kicinski [Tue, 1 Dec 2020 01:55:26 +0000 (17:55 -0800)]
Merge branch 'mptcp-avoid-workqueue-usage-for-data'

Paolo Abeni says:

====================
mptcp: avoid workqueue usage for data

The current locking schema used to protect the MPTCP data-path
requires the usage of the MPTCP workqueue to process the incoming
data, depending on trylock result.

The above poses scalability limits and introduces random delays
in MPTCP-level acks.

With this series we use a single spinlock to protect the MPTCP
data-path, removing the need for workqueue and delayed ack usage.

This additionally reduces the number of atomic operations required
per packet and cleans-up considerably the poll/wake-up code.
====================

Link: https://lore.kernel.org/r/cover.1606413118.git.pabeni@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agomptcp: use mptcp release_cb for delayed tasks
Paolo Abeni [Fri, 27 Nov 2020 10:10:27 +0000 (11:10 +0100)]
mptcp: use mptcp release_cb for delayed tasks

We have some tasks triggered by the subflow receive path
which require to access the msk socket status, specifically:
mptcp_clean_una() and mptcp_push_pending()

We have almost everything in place to defer to the msk
release_cb such tasks when the msk sock is owned.

Since the worker is no more used to clean the acked data,
for fallback sockets we need to explicitly flush them.

As an added bonus we can move the wake-up code in __mptcp_clean_una(),
simplify a lot mptcp_poll() and move the timer update under
the data lock.

The worker is now used only to process and send DATA_FIN
packets and do the mptcp-level retransmissions.

Acked-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agomptcp: avoid a few atomic ops in the rx path
Paolo Abeni [Fri, 27 Nov 2020 10:10:26 +0000 (11:10 +0100)]
mptcp: avoid a few atomic ops in the rx path

Extending the data_lock scope in mptcp_incoming_option
we can use that to protect both snd_una and wnd_end.
In the typical case, we will have a single atomic op instead of 2

Acked-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agomptcp: allocate TX skbs in msk context
Paolo Abeni [Fri, 27 Nov 2020 10:10:25 +0000 (11:10 +0100)]
mptcp: allocate TX skbs in msk context

Move the TX skbs allocation in mptcp_sendmsg() scope,
and tentatively pre-allocate a skbs number proportional
to the sendmsg() length.

Use the ssk tx skb cache to prevent the subflow allocation.

This allows removing the msk skb extension cache and will
make possible the later patches.

Acked-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agomptcp: protect the rx path with the msk socket spinlock
Paolo Abeni [Fri, 27 Nov 2020 10:10:24 +0000 (11:10 +0100)]
mptcp: protect the rx path with the msk socket spinlock

Such spinlock is currently used only to protect the 'owned'
flag inside the socket lock itself. With this patch, we extend
its scope to protect the whole msk receive path and
sk_forward_memory.

Given the above, we can always move data into the msk receive
queue (and OoO queue) from the subflow.

We leverage the previous commit, so that we need to acquire the
spinlock in the tx path only when moving fwd memory.

recvmsg() must now explicitly acquire the socket spinlock
when moving skbs out of sk_receive_queue. To reduce the number of
lock operations required we use a second rx queue and splice the
first into the latter in mptcp_lock_sock(). Additionally rmem
allocated memory is bulk-freed via release_cb()

Acked-by: Florian Westphal <fw@strlen.de>
Co-developed-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agomptcp: implement wmem reservation
Paolo Abeni [Fri, 27 Nov 2020 10:10:23 +0000 (11:10 +0100)]
mptcp: implement wmem reservation

This leverages the previous commit to reserve the wmem
required for the sendmsg() operation when the msk socket
lock is first acquired.
Some heuristics are used to get a reasonable [over] estimation of
the whole memory required. If we can't forward alloc such amount
fallback to a reasonable small chunk, otherwise enter the wait
for memory path.

When sendmsg() needs more memory it looks at wmem_reserved
first and if that is exhausted, move more space from
sk_forward_alloc.

The reserved memory is not persistent and is released at the
next socket unlock via the release_cb().

Overall this will simplify the next patch.

Acked-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agomptcp: open code mptcp variant for lock_sock
Paolo Abeni [Fri, 27 Nov 2020 10:10:22 +0000 (11:10 +0100)]
mptcp: open code mptcp variant for lock_sock

This allows invoking an additional callback under the
socket spin lock.

Will be used by the next patches to avoid additional
spin lock contention.

Acked-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agoMerge branch 'dpaa_eth-add-xdp-support'
Jakub Kicinski [Tue, 1 Dec 2020 01:32:03 +0000 (17:32 -0800)]
Merge branch 'dpaa_eth-add-xdp-support'

Camelia Groza says:

====================
dpaa_eth: add XDP support

Enable XDP support for the QorIQ DPAA1 platforms.

Implement all the current actions (DROP, ABORTED, PASS, TX, REDIRECT). No
Tx batching is added at this time.

Additional XDP_PACKET_HEADROOM bytes are reserved in each frame's headroom.

After transmit, a reference to the xdp_frame is saved in the buffer for
clean-up on confirmation in a newly created structure for software
annotations. DPAA_TX_PRIV_DATA_SIZE bytes are reserved in the buffer for
storing this structure and the XDP program is restricted from accessing
them.

The driver shares the egress frame queues used for XDP with the network
stack. The DPAA driver is a LLTX driver so no explicit locking is required
on transmission.
====================

Link: https://lore.kernel.org/r/cover.1606322126.git.camelia.groza@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agodpaa_eth: implement the A050385 erratum workaround for XDP
Camelia Groza [Wed, 25 Nov 2020 16:53:36 +0000 (18:53 +0200)]
dpaa_eth: implement the A050385 erratum workaround for XDP

For XDP TX, even tough we start out with correctly aligned buffers, the
XDP program might change the data's alignment. For REDIRECT, we have no
control over the alignment either.

Create a new workaround for xdp_frame structures to verify the erratum
conditions and move the data to a fresh buffer if necessary. Create a new
xdp_frame for managing the new buffer and free the old one using the XDP
API.

Due to alignment constraints, all frames have a 256 byte headroom that
is offered fully to XDP under the erratum. If the XDP program uses all
of it, the data needs to be move to make room for the xdpf backpointer.

Disable the metadata support since the information can be lost.

Acked-by: Madalin Bucur <madalin.bucur@oss.nxp.com>
Signed-off-by: Camelia Groza <camelia.groza@nxp.com>
Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agodpaa_eth: rename current skb A050385 erratum workaround
Camelia Groza [Wed, 25 Nov 2020 16:53:35 +0000 (18:53 +0200)]
dpaa_eth: rename current skb A050385 erratum workaround

Explicitly point that the current workaround addresses skbs. This change is
in preparation for adding a workaround for XDP scenarios.

Acked-by: Madalin Bucur <madalin.bucur@oss.nxp.com>
Signed-off-by: Camelia Groza <camelia.groza@nxp.com>
Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agodpaa_eth: add XDP_REDIRECT support
Camelia Groza [Wed, 25 Nov 2020 16:53:34 +0000 (18:53 +0200)]
dpaa_eth: add XDP_REDIRECT support

After transmission, the frame is returned on confirmation queues for
cleanup. For this, store a backpointer to the xdp_frame in the private
reserved area at the start of the TX buffer.

No TX batching support is implemented at this time.

Acked-by: Madalin Bucur <madalin.bucur@oss.nxp.com>
Signed-off-by: Camelia Groza <camelia.groza@nxp.com>
Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agodpaa_eth: add XDP_TX support
Camelia Groza [Wed, 25 Nov 2020 16:53:33 +0000 (18:53 +0200)]
dpaa_eth: add XDP_TX support

Use an xdp_frame structure for managing the frame. Store a backpointer to
the structure at the start of the buffer before enqueueing for cleanup
on TX confirmation. Reserve DPAA_TX_PRIV_DATA_SIZE bytes from the frame
size shared with the XDP program for this purpose. Use the XDP
API for freeing the buffer when it returns to the driver on the TX
confirmation path.

The frame queues are shared with the netstack. The DPAA driver is a LLTX
driver so no explicit locking is required on transmission.

This approach will be reused for XDP REDIRECT.

Acked-by: Madalin Bucur <madalin.bucur@oss.nxp.com>
Signed-off-by: Camelia Groza <camelia.groza@nxp.com>
Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agodpaa_eth: limit the possible MTU range when XDP is enabled
Camelia Groza [Wed, 25 Nov 2020 16:53:32 +0000 (18:53 +0200)]
dpaa_eth: limit the possible MTU range when XDP is enabled

Implement the ndo_change_mtu callback to prevent users from setting an
MTU that would permit processing of S/G frames. The maximum MTU size
is dependent on the buffer size.

Acked-by: Madalin Bucur <madalin.bucur@oss.nxp.com>
Signed-off-by: Camelia Groza <camelia.groza@nxp.com>
Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agodpaa_eth: add basic XDP support
Camelia Groza [Wed, 25 Nov 2020 16:53:31 +0000 (18:53 +0200)]
dpaa_eth: add basic XDP support

Implement the XDP_DROP and XDP_PASS actions.

Avoid draining and reconfiguring the buffer pool at each XDP
setup/teardown by increasing the frame headroom and reserving
XDP_PACKET_HEADROOM bytes from the start. Since we always reserve an
entire page per buffer, this change only impacts Jumbo frame scenarios
where the maximum linear frame size is reduced by 256 bytes. Multi
buffer Scatter/Gather frames are now used instead in these scenarios.

Allow XDP programs to access the entire buffer.

The data in the received frame's headroom can be overwritten by the XDP
program. Extract the relevant fields from the headroom while they are
still available, before running the XDP program.

Since the headroom might be resized before the frame is passed up to the
stack, remove the check for a fixed headroom value when building an skb.

Allow the meta data to be updated and pass the information up the stack.

Scatter/Gather frames are dropped when XDP is enabled.

Acked-by: Madalin Bucur <madalin.bucur@oss.nxp.com>
Signed-off-by: Camelia Groza <camelia.groza@nxp.com>
Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agodpaa_eth: add struct for software backpointers
Camelia Groza [Wed, 25 Nov 2020 16:53:30 +0000 (18:53 +0200)]
dpaa_eth: add struct for software backpointers

We maintain an skb backpointer in the software annotations area of Tx
frames. Introduce a structure for explicit handling.

Acked-by: Madalin Bucur <madalin.bucur@oss.nxp.com>
Signed-off-by: Camelia Groza <camelia.groza@nxp.com>
Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 years agocan: m_can: m_can_class_unregister(): move right after m_can_class_register()
Marc Kleine-Budde [Mon, 30 Nov 2020 13:37:13 +0000 (14:37 +0100)]
can: m_can: m_can_class_unregister(): move right after m_can_class_register()

This patch moves the function m_can_class_unregister() directly after the
m_can_class_register() function.

Link: https://lore.kernel.org/r/20201130133713.269256-7-mkl@pengutronix.de
Reviewed-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
3 years agocan: m_can: m_can_plat_remove(): remove unneeded platform_set_drvdata()
Marc Kleine-Budde [Mon, 30 Nov 2020 13:37:12 +0000 (14:37 +0100)]
can: m_can: m_can_plat_remove(): remove unneeded platform_set_drvdata()

There's no need to unset the drvdata on remove, so remove the unneeded call to
platform_set_drvdata() in m_can_plat_remove().

Link: https://lore.kernel.org/r/20201130133713.269256-6-mkl@pengutronix.de
Reviewed-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
3 years agocan: m_can: remove not used variable struct m_can_classdev::freq
Marc Kleine-Budde [Mon, 30 Nov 2020 13:37:11 +0000 (14:37 +0100)]
can: m_can: remove not used variable struct m_can_classdev::freq

This patch removes the unused variable freq from the struct m_can_classdev.

Link: https://lore.kernel.org/r/20201130133713.269256-5-mkl@pengutronix.de
Reviewed-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
3 years agocan: m_can: Kconfig: convert the into menu
Marc Kleine-Budde [Mon, 30 Nov 2020 13:37:10 +0000 (14:37 +0100)]
can: m_can: Kconfig: convert the into menu

Since there is more than one base driver for the m_can core, let's
convert this into a menu.

Link: https://lore.kernel.org/r/20201130133713.269256-4-mkl@pengutronix.de
Reviewed-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
3 years agocan: tcan4x5x: tcan4x5x_can_probe(): remove probe failed error message
Marc Kleine-Budde [Mon, 30 Nov 2020 13:37:09 +0000 (14:37 +0100)]
can: tcan4x5x: tcan4x5x_can_probe(): remove probe failed error message

The driver core already emits a probe failed error message, so remove this one
from the driver.

Link: https://lore.kernel.org/r/20201130133713.269256-3-mkl@pengutronix.de
Reviewed-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
3 years agocan: tcan4x5x: remove mram_start and reg_offset from struct tcan4x5x_priv
Marc Kleine-Budde [Mon, 30 Nov 2020 13:37:08 +0000 (14:37 +0100)]
can: tcan4x5x: remove mram_start and reg_offset from struct tcan4x5x_priv

Both struct tcan4x5x_priv::mram_start and struct tcan4x5x_priv::reg_offset are
only assigned once with a constant and then always used read-only. This patch
changes the driver to use the constant directly instead.

Link: https://lore.kernel.org/r/20201130133713.269256-2-mkl@pengutronix.de
Reviewed-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
3 years agocan: tcan4x5x: rename parse_config() function
Dan Murphy [Wed, 26 Feb 2020 14:03:58 +0000 (08:03 -0600)]
can: tcan4x5x: rename parse_config() function

Rename the tcan4x5x_parse_config() function to tcan4x5x_get_gpios() since the
function retrieves the gpio configurations from the firmware.

Signed-off-by: Dan Murphy <dmurphy@ti.com>
Link: http://lore.kernel.org/r/20200226140358.30017-1-dmurphy@ti.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
3 years agocan: tcan4x5x: tcan4x5x_clear_interrupts(): remove redundant return statement
Sean Nyekjaer [Wed, 11 Dec 2019 14:16:35 +0000 (15:16 +0100)]
can: tcan4x5x: tcan4x5x_clear_interrupts(): remove redundant return statement

This patch removes a redundant return at the end of
tcan4x5x_clear_interrupts().

Signed-off-by: Sean Nyekjaer <sean@geanix.com>
Link: http://lore.kernel.org/r/20191211141635.322577-1-sean@geanix.com
Reported-by: Daniels Umanovskis <daniels@umanovskis.se>
Acked-by: Dan Murphy <dmurphy@ti.com>
Fixes: 5443c226ba91 ("can: tcan4x5x: Add tcan4x5x driver to the kernel")
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>