As suggested by Vincent, renaming of esd_usb2.c to esd_usb.c
and according to that, adaption of Kconfig and Makfile, too.

Link: https://lore.kernel.org/all/20220624190517.2299701-2-frank.jungclaus@esd.euSigned-off-by: NFrank Jungclaus <frank.jungclaus@esd.eu>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

can: netlink: allow configuring of fixed data bit rates without need for do_set_data_bittiming callback

This patch is similar to 7e193a42 ("can: netlink: allow
configuring of fixed bit rates without need for do_set_bittiming
callback") but for data bit rates instead of bit rates.

Usually CAN devices support configurable data bit rates. The limits
are defined by struct can_priv::data_bittiming_const. Another way is
to implement the struct can_priv::do_set_data_bittiming callback.

If the bit rate is configured via netlink, the can_changelink()
function checks that either can_priv::data_bittiming_const or struct
can_priv::do_set_data_bittiming is implemented.

In commit 431af779 ("can: dev: add CAN interface API for fixed
bitrates") an API for configuring bit rates on CAN interfaces that
only support fixed bit rates was added. The supported bit rates are
defined by struct can_priv::bitrate_const.

However the above mentioned commit forgot to add the struct
can_priv::data_bitrate_const to the check in can_changelink().

In order to avoid to implement a no-op can_priv::do_set_data_bittiming
callback on devices with fixed data bit rates, extend the check in
can_changelink() accordingly.

Link: https://lore.kernel.org/all/20220613143633.4151884-1-mkl@pengutronix.de
Fixes: 431af779 ("can: dev: add CAN interface API for fixed bitrates")
Acked-by: NMax Staudt <max@enpas.org>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Conor Dooley says:

====================
When adding the dts for PolarFire SoC, the can controllers were
omitted, so here they are...
====================

Link: https://lore.kernel.org/all/20220607065459.2035746-1-conor.dooley@microchip.comSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

PolarFire SoC has a pair of CAN controllers, but as they were
undocumented there were omitted from the device tree. Add them.

Link: https://lore.kernel.org/all/20220607065459.2035746-3-conor.dooley@microchip.comSigned-off-by: NConor Dooley <conor.dooley@microchip.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Add a binding for the CAN controller on PolarFire SoC (MPFS).

A data sheet and a register map can be downloaded at:

| https://www.microsemi.com/document-portal/doc_download/1245725-polarfire-soc-fpga-mss-technical-reference-manual
| https://www.microsemi.com/document-portal/doc_download/1244581-polarfire-soc-register-map

An alternative location for the register map is:

| http://web.archive.org/web/20220403030214/https://www.microsemi.com/document-portal/doc_download/1244581-polarfire-soc-register-map

Link: https://lore.kernel.org/all/20220607065459.2035746-2-conor.dooley@microchip.comSigned-off-by: NConor Dooley <conor.dooley@microchip.com>
Reviewed-by: NRob Herring <robh@kernel.org>
[mkl: add link to data sheet and register map]
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Vincent Mailhol says:

====================
This series contains two clean up patches toward struct es58x_device
of the CAN etas_es58x driver. The first one removes the field
rx_max_packet_size which value can actually be retrieved from the
helper function usb_maxpacket(). The second one fixes the signedness
of the TX and RX pipes.

No functional changes.
====================

Link: https://lore.kernel.org/all/20220611162037.1507-1-mailhol.vincent@wanadoo.frSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

USB pipes are meant to be unsigned int (c.f. [1]). However, fields
rx_pipe and tx_pipe of struct es58x_device are both signed
integers. Change the type of those two fields from int to unsigned
int.

[1] https://elixir.bootlin.com/linux/v5.18/source/include/linux/usb.h#L1571

Link: https://lore.kernel.org/all/20220611162037.1507-3-mailhol.vincent@wanadoo.frSigned-off-by: NVincent Mailhol <mailhol.vincent@wanadoo.fr>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

The field rx_max_packet_size of struct es58x_device in nothing else
than usb_endpoint_descriptor::wMaxPacketSize and can be easily
retrieved using usb_maxpacket(). Also, rx_max_packet_size being used a
single time, there is no merit to cache it locally.

Remove es58x_device::rx_max_packet_size and rely on usb_maxpacket()
instead.

Link: https://lore.kernel.org/all/20220611162037.1507-2-mailhol.vincent@wanadoo.frSigned-off-by: NVincent Mailhol <mailhol.vincent@wanadoo.fr>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

There are two sections called "Local Loopback of Sent Frames". One was
meant to link to the other, but pointed at itself instead.

Link: https://lore.kernel.org/all/20220611171155.9090-1-max@enpas.org
Fixes: 7d597739 ("can: migrate documentation to restructured text")
Signed-off-by: NMax Staudt <max@enpas.org>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Vincent Mailhol says

====================
Aside of calc_bittiming.o which can be configured with
CAN_CALC_BITTIMING, all objects from drivers/net/can/dev/ get linked
unconditionally to can-dev.o even if not needed by the user.

This series first goal it to split the can-dev modules so that the
only the needed features get built in during compilation.
Additionally, the CAN Device Drivers menu is moved from the
"Networking support" category to the "Device Drivers" category (where
all drivers are supposed to be).

* menu before this series *

CAN bus subsystem support
  symbol: CONFIG_CAN
  |
  +-> CAN Device Drivers
      (no symbol)
      |
      +-> software/virtual CAN device drivers
      |   (at time of writing: slcan, vcan, vxcan)
      |
      +-> Platform CAN drivers with Netlink support
          symbol: CONFIG_CAN_DEV
          |
          +-> CAN bit-timing calculation  (optional for hardware drivers)
          |   symbol: CONFIG_CAN_CALC_BITTIMING
          |
          +-> All other CAN devices drivers

* menu after this series *

Network device support
  symbol: CONFIG_NETDEVICES
  |
  +-> CAN Device Drivers
      symbol: CONFIG_CAN_DEV
      |
      +-> software/virtual CAN device drivers
      |   (at time of writing: slcan, vcan, vxcan)
      |
      +-> CAN device drivers with Netlink support
          symbol: CONFIG_CAN_NETLINK (matches previous CONFIG_CAN_DEV)
          |
          +-> CAN bit-timing calculation (optional for all drivers)
          |   symbol: CONFIG_CAN_CALC_BITTIMING
          |
          +-> All other CAN devices drivers
              (some may select CONFIG_CAN_RX_OFFLOAD)
              |
              +-> CAN rx offload (automatically selected by some drivers)
                  (hidden symbol: CONFIG_CAN_RX_OFFLOAD)

Patches 1 to 5 of this series do above modification.

The last two patches add a check toward CAN_CTRLMODE_LISTENONLY in
can_dropped_invalid_skb() to discard tx skb (such skb can potentially
reach the driver if injected via the packet socket). In more details,
patch 6 moves can_dropped_invalid_skb() from skb.h to skb.o and patch
7 is the actual change.

Those last two patches are actually connected to the first five ones:
because slcan and v(x)can requires can_dropped_invalid_skb(), it was
necessary to add those three devices to the scope of can-dev before
moving the function to skb.o.

This design results from the lengthy discussion in [1].

[1] https://lore.kernel.org/linux-can/20220514141650.1109542-1-mailhol.vincent@wanadoo.fr/

** Changelog **

v5 -> v6:

  * fix typo in patch #1's title: Kbuild -> Kconfig.

  * make CONFIG_RX_CAN an hidden config symbol and modify the diagram
    in the cover letter accordingly.

    @Oliver, with CONFIG_CAN_RX_OFFLOAD now being an hidden config,
    that option fully depends on the drivers. So contrary to your
    suggestion, I put CONFIG_CAN_RX_OFFLOAD below the device drivers
    in the diagram.

  * fix typo in cover letter: CONFIG_CAN_BITTIMING -> CONFIG_CAN_CALC_BITTIMING.

v4 -> v5:

  * m_can is also requires RX offload. Add the "select CAN_RX_OFFLOAD"
    to its Makefile.

  * Reorder the lines of drivers/net/can/dev/Makefile.

  * Remove duplicated rx-offload.o target in drivers/net/can/dev/Makefile

  * Remove the Nota Bene in the cover letter.

v3 -> v4:

  * Five additional patches added to split can-dev module and refactor
    Kbuild. c.f. below (lengthy) thread:
    https://lore.kernel.org/linux-can/20220514141650.1109542-1-mailhol.vincent@wanadoo.fr/

v2 -> v3:

  * Apply can_dropped_invalid_skb() to slcan.

  * Make vcan, vxcan and slcan dependent of CONFIG_CAN_DEV by
    modifying Kbuild.

  * fix small typos.

v1 -> v2:

  * move can_dropped_invalid_skb() to skb.c instead of dev.h

  * also move can_skb_headroom_valid() to skb.c
====================

Link: https://lore.kernel.org/all/20220610143009.323579-1-mailhol.vincent@wanadoo.frSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Frames can be directly injected to a can driver via the packet
socket. By doing so, it is possible to reach the
net_device_ops::ndo_start_xmit function even if the driver is
configured in listen only mode.

Add a check in can_dropped_invalid_skb() to discard the skb if
CAN_CTRLMODE_LISTENONLY is set.

Link: https://lore.kernel.org/all/20220610143009.323579-8-mailhol.vincent@wanadoo.frSigned-off-by: NVincent Mailhol <mailhol.vincent@wanadoo.fr>
Acked-by: NMax Staudt <max@enpas.org>
Tested-by: NOliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

The functions can_dropped_invalid_skb() and can_skb_headroom_valid()
grew a lot over the years to a point which it does not make much sense
to have them defined as static inline in header files. Move those two
functions to the .c counterpart of skb.h.

can_skb_headroom_valid()'s only caller being
can_dropped_invalid_skb(), the declaration is removed from the
header. Only can_dropped_invalid_skb() gets its symbol exported.

While doing so, do a small cleanup: add brackets around the else block
in can_dropped_invalid_skb().

Link: https://lore.kernel.org/all/20220610143009.323579-7-mailhol.vincent@wanadoo.frSigned-off-by: NVincent Mailhol <mailhol.vincent@wanadoo.fr>
Reported-by: Nkernel test robot <lkp@intel.com>
Acked-by: NMax Staudt <max@enpas.org>
Tested-by: NOliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

The devices are meant to be under the "Device Drivers" category of the
menuconfig. The CAN subsystem is currently one of the rare exception
with all of its devices under the "Networking support" category.

The CAN_DEV menuentry gets moved to fix this discrepancy. The CAN menu
is added just before MCTP in order to be consistent with the current
order under the "Networking support" menu.

A dependency on CAN is added to CAN_DEV so that the CAN devices only
show up if the CAN subsystem is enabled.

Link: https://lore.kernel.org/all/20220610143009.323579-6-mailhol.vincent@wanadoo.frSigned-off-by: NVincent Mailhol <mailhol.vincent@wanadoo.fr>
Acked-by: NMax Staudt <max@enpas.org>
Tested-by: NOliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Only a few drivers rely on the CAN rx offload framework (as of the
writing of this patch, only four: flexcan, m_can, mcp251xfd and
ti_hecc). Split it out of can-dev and add a new config symbol:
CAN_RX_OFFLOAD.

The drivers relying on CAN rx offload are in different sub
folders. Make CAN_RX_OFFLOAD an hidden option and tag all the drivers
depending on that feature with "select CAN_RX_OFFLOAD" so that the
option gets automatically enabled if and only if one of those drivers
is chosen.

Link: https://lore.kernel.org/all/20220610143009.323579-5-mailhol.vincent@wanadoo.frSuggested-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Suggested-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NVincent Mailhol <mailhol.vincent@wanadoo.fr>
Acked-by: NMax Staudt <max@enpas.org>
Tested-by: NOliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

The canonical way to select or deselect an object during compilation
is to use this pattern in the relevant Makefile:

bar-$(CONFIG_FOO) := foo.o

bittiming.c instead uses some #ifdef CONFIG_CAN_CALC_BITTIMG.

Create a new file named calc_bittiming.c with all the functions which
are conditionally compiled with CONFIG_CAN_CALC_BITTIMG and modify the
Makefile according to above pattern.

Link: https://lore.kernel.org/all/20220610143009.323579-4-mailhol.vincent@wanadoo.frSigned-off-by: NVincent Mailhol <mailhol.vincent@wanadoo.fr>
Acked-by: NMax Staudt <max@enpas.org>
Tested-by: NOliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

In the next patches, the software/virtual drivers (slcan, v(x)can)
will depend on drivers/net/can/dev/skb.o.

This patch changes the scope of the can-dev module to include the
above mentioned drivers.

To do so, we reuse the menu "CAN Device Drivers" and turn it into a
configmenu using the config symbol CAN_DEV (which we released in
previous patch). Also, add a description to this new CAN_DEV
menuconfig.

The symbol CAN_DEV now only triggers the build of skb.o. For this
reasons, all the macros from linux/module.h are deported from
drivers/net/can/dev/dev.c to drivers/net/can/dev/skb.c.

Finally, drivers/net/can/dev/Makefile is adjusted accordingly.

Link: https://lore.kernel.org/all/20220610143009.323579-3-mailhol.vincent@wanadoo.frSuggested-by: NOliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: NVincent Mailhol <mailhol.vincent@wanadoo.fr>
Acked-by: NMax Staudt <max@enpas.org>
Tested-by: NOliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

In the next patches, the scope of the can-dev module will grow to
engloble the software/virtual drivers (slcan, v(x)can). To this
extent, release CAN_DEV by renaming it into CAN_NETLINK. The config
symbol CAN_DEV will be reused to cover this extended scope.

The rationale for the name CAN_NETLINK is that netlink is the
predominant feature added here.

The current description only mentions platform drivers despite the
fact that this symbol is also required by "normal" devices (e.g. USB
or PCI) which do not fall under the platform devices category. The
description is updated accordingly to fix this gap.

Link: https://lore.kernel.org/all/20220610143009.323579-2-mailhol.vincent@wanadoo.frSigned-off-by: NVincent Mailhol <mailhol.vincent@wanadoo.fr>
Acked-by: NMax Staudt <max@enpas.org>
Tested-by: NOliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Usually CAN devices support configurable bit rates. The limits are
defined by struct can_priv::bittiming_const. Another way is to
implement the struct can_priv::do_set_bittiming callback.

If the bit rate is configured via netlink, the can_changelink()
function checks that either can_priv::bittiming_const or struct
can_priv::do_set_bittiming is implemented.

In commit 431af779 ("can: dev: add CAN interface API for fixed
bitrates") an API for configuring bit rates on CAN interfaces that
only support fixed bit rates was added. The supported bit rates are
defined by struct can_priv::bitrate_const.

However the above mentioned commit forgot to add the struct
can_priv::bitrate_const to the check in can_changelink().

In order to avoid to implement a no-op can_priv::do_set_bittiming
callback on devices with fixed bit rates, extend the check in
can_changelink() accordingly.

Link: https://lore.kernel.org/all/20220611144248.3924903-1-mkl@pengutronix.de
Fixes: 431af779 ("can: dev: add CAN interface API for fixed bitrates")
Reported-by: NMax Staudt <max@enpas.org>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

This patch fixes the typo prescalar -> prescaler.

Link: https://lore.kernel.org/all/20220610112037.3857192-1-mkl@pengutronix.deReviewed-by: NChandrasekar Ramakrishnan <rcsekar@samsung.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

This patch fixes the typo prescalar -> prescaler.

Link: https://lore.kernel.org/all/20220609111424.3819039-1-mkl@pengutronix.deReported-by: NVincent MAILHOL <mailhol.vincent@wanadoo.fr>
Cc: Srinivas Neeli <srinivas.neeli@xilinx.com>
Cc: Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com>
Cc: Naga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

This patch adds Transmitter Delay Compensation (TDC) feature support.

In the case of higher measured loop delay with higher bit rates, bit
stuff errors are observed. Enabling the TDC feature in CAN-FD
controllers will compensate for the measured loop delay in the receive
path.

Link: https://lore.kernel.org/all/20220609103157.1425730-1-srinivas.neeli@xilinx.comSigned-off-by: NSrinivas Neeli <srinivas.neeli@xilinx.com>
Reviewed-by: NVincent Mailhol <mailhol.vincent@wanadoo.fr>
[mkl: fix indention]
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Previously the traffic class field is ignored while firmware has
already supported to pedit flowinfo fields, including traffic
class and flow label, now add it back.
Signed-off-by: NYinjun Zhang <yinjun.zhang@corigine.com>
Link: https://lore.kernel.org/r/20220609080136.151830-1-simon.horman@corigine.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

The commit a14857c2 ("rtnetlink: verify rate parameters for calls to
ndo_set_vf_rate") has been merged to master, so we can to remove the
now-duplicate checks in drivers.
Signed-off-by: NBin Chen <bin.chen@corigine.com>
Signed-off-by: NBaowen Zheng <baowen.zheng@corigine.com>
Signed-off-by: NSimon Horman <simon.horman@corigine.com>
Link: https://lore.kernel.org/r/20220609084717.155154-1-simon.horman@corigine.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Tony Nguyen says:

====================
10GbE Intel Wired LAN Driver Updates 2022-06-09

Maximilian Heyne adds reporting of VF statistics on ixgbe via iproute2
interface.

Kai-Heng Feng removes duplicate defines from igb.

Jiaqing Zhao fixes typos in e1000, ixgb, and ixgbe drivers.

Julia Lawall fixes typos for fm10k, ixgbe, and ice drivers.

* '10GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue:
  drivers/net/ethernet/intel: fix typos in comments
  ixgbe: Fix typos in comments
  ixgb: Fix typos in comments
  e1000: Fix typos in comments
  igb: Remove duplicate defines
  drivers, ixgbe: export vf statistics
====================

Link: https://lore.kernel.org/r/20220609171257.2727150-1-anthony.l.nguyen@intel.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Eric Dumazet says:

====================
net: reduce tcp_memory_allocated inflation

Hosts with a lot of sockets tend to hit so called TCP memory pressure,
leading to very bad TCP performance and/or OOM.

The problem is that some TCP sockets can hold up to 2MB of 'forward
allocations' in their per-socket cache (sk->sk_forward_alloc),
and there is no mechanism to make them relinquish their share
under mem pressure.
Only under some potentially rare events their share is reclaimed,
one socket at a time.

In this series, I implemented a per-cpu cache instead of a per-socket one.

Each CPU has a +1/-1 MB (256 pages on x86) forward alloc cache, in order
to not dirty tcp_memory_allocated shared cache line too often.

We keep sk->sk_forward_alloc values as small as possible, to meet
memcg page granularity constraint.

Note that memcg already has a per-cpu cache, although MEMCG_CHARGE_BATCH
is defined to 32 pages, which seems a bit small.

Note that while this cover letter mentions TCP, this work is generic
and supports TCP, UDP, DECNET, SCTP.
====================

Link: https://lore.kernel.org/r/20220609063412.2205738-1-eric.dumazet@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

These two helpers are only used from core networking.
Signed-off-by: NEric Dumazet <edumazet@google.com>
Reviewed-by: NShakeel Butt <shakeelb@google.com>
Acked-by: NSoheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Currently, tcp_memory_allocated can hit tcp_mem[] limits quite fast.

Each TCP socket can forward allocate up to 2 MB of memory, even after
flow became less active.

10,000 sockets can have reserved 20 GB of memory,
and we have no shrinker in place to reclaim that.

Instead of trying to reclaim the extra allocations in some places,
just keep sk->sk_forward_alloc values as small as possible.

This should not impact performance too much now we have per-cpu
reserves: Changes to tcp_memory_allocated should not be too frequent.

For sockets not using SO_RESERVE_MEM:
 - idle sockets (no packets in tx/rx queues) have zero forward alloc.
 - non idle sockets have a forward alloc smaller than one page.

Note:

 - Removal of SK_RECLAIM_CHUNK and SK_RECLAIM_THRESHOLD
   is left to MPTCP maintainers as a follow up.
Signed-off-by: NEric Dumazet <edumazet@google.com>
Reviewed-by: NShakeel Butt <shakeelb@google.com>
Acked-by: NSoheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

If sk->sk_forward_alloc is 150000, and we need to schedule 150001 bytes,
we want to allocate 1 byte more (rounded up to one page),
instead of 150001 :/

Fixes: 1da177e4 ("Linux-2.6.12-rc2")
Signed-off-by: NEric Dumazet <edumazet@google.com>
Reviewed-by: NShakeel Butt <shakeelb@google.com>
Acked-by: NSoheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

We plan keeping sk->sk_forward_alloc as small as possible
in future patches.

This means we are going to call sk_memory_allocated_add()
and sk_memory_allocated_sub() more often.

Implement a per-cpu cache of +1/-1 MB, to reduce number
of changes to sk->sk_prot->memory_allocated, which
would otherwise be cause of false sharing.
Signed-off-by: NEric Dumazet <edumazet@google.com>
Acked-by: NSoheil Hassas Yeganeh <soheil@google.com>
Reviewed-by: NShakeel Butt <shakeelb@google.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Each protocol having a ->memory_allocated pointer gets a corresponding
per-cpu reserve, that following patches will use.

Instead of having reserved bytes per socket,
we want to have per-cpu reserves.
Signed-off-by: NEric Dumazet <edumazet@google.com>
Reviewed-by: NShakeel Butt <shakeelb@google.com>
Acked-by: NSoheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Due to memcg interface, SK_MEM_QUANTUM is effectively PAGE_SIZE.

This might change in the future, but it seems better to avoid the
confusion.
Signed-off-by: NEric Dumazet <edumazet@google.com>
Reviewed-by: NShakeel Butt <shakeelb@google.com>
Acked-by: NSoheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

This reverts commit bd68a2a8.

This change broke memcg on arches with PAGE_SIZE != 4096

Later, commit 2bb2f5fb ("net: add new socket option SO_RESERVE_MEM")
also assumed PAGE_SIZE==SK_MEM_QUANTUM

Following patches in the series will greatly reduce the over allocations
problem.
Signed-off-by: NEric Dumazet <edumazet@google.com>
Reviewed-by: NShakeel Butt <shakeelb@google.com>
Acked-by: NSoheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

No conflicts.
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Pull more devicetree fixes from Rob Herring:

 - More DT meta-schema check fixes from new bindings in merge window

 - Fix stale DT binding references from Mauro

 - Update various binding maintainers

 - Fix in arm,malidp properties to match reality

 - Add deprecated 'atheros' vendor prefix

* tag 'devicetree-fixes-for-5.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux:
  dt-bindings: display: arm,malidp: remove bogus RQOS property
  dt-bindings: pinctrl: ralink: Fix 'enum' lists with duplicate entries
  dt-bindings: Drop more redundant 'maxItems/minItems' in if/then schemas
  dt-bindings: nvme: apple,nvme-ans: Drop 'maxItems' from 'apple,sart'
  MAINTAINERS: rectify entries for ARM DRM DRIVERS after dt conversion
  MAINTAINERS: update snps,axs10x-reset.yaml reference
  MAINTAINERS: update dongwoon,dw9807-vcm.yaml reference
  MAINTAINERS: update cortina,gemini-ethernet.yaml reference
  dt-bindings: mfd: rk808: update rockchip,rk808.yaml reference
  dt-bindings: reset: update st,stih407-powerdown.yaml references
  dt-bindings: arm: update vexpress-config.yaml references
  dt-bindings: interrupt-controller: update brcm,l2-intc.yaml reference
  dt-bindings: mfd: bd9571mwv: update rohm,bd9571mwv.yaml reference
  dt-bindings: update Luca Ceresoli's e-mail address
  dt-bindings: msm: update maintainers list with proper id
  dt-bindings: vendor-prefixes: document deprecated Atheros
  dt-bindings: Update QCOM USB subsystem maintainer information

Pull power management fixes from Rafael Wysocki:
 "These fix an intel_idle issue introduced during the 5.16 development
  cycle and two recent regressions in the system reboot/poweroff code.

  Specifics:

   - Fix CPUIDLE_FLAG_IRQ_ENABLE handling in intel_idle (Peter Zijlstra)

   - Allow all platforms to use the global poweroff handler and make
     non-syscall poweroff code paths work again (Dmitry Osipenko)"

* tag 'pm-5.19-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  cpuidle,intel_idle: Fix CPUIDLE_FLAG_IRQ_ENABLE
  kernel/reboot: Fix powering off using a non-syscall code paths
  kernel/reboot: Use static handler for register_platform_power_off()

There's a rule in certs/Makefile for which the command begins with eight
spaces.  This results in:

        ../certs/Makefile:21: FORCE prerequisite is missing
        ../certs/Makefile:21: *** missing separator.  Stop.

Fix this by turning the spaces into a tab.

Fixes: addf4663 ("certs: Check that builtin blacklist hashes are valid")
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org>
Reviewed-by: NMickaël Salaün <mic@linux.microsoft.com>
cc: keyrings@vger.kernel.org
Link: https://lore.kernel.org/r/486b1b80-9932-aab6-138d-434c541c934a@digikod.net/ # v1
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

As Liviu pointed out, the arm,malidp-arqos-high-level property
mentioned in the original .txt binding was a mistake, and
arm,malidp-arqos-value needs to take its place.

The binding commit ce6eb025 ("dt/bindings: display: Add optional
property node define for Mali DP500") mentions the right name in the
commit message, but has the wrong name in the diff.
Commit d298e6a2 ("drm/arm/mali-dp: Add display QoS interface
configuration for Mali DP500") uses the property in the driver, but uses
the shorter name.

Remove the wrong property from the binding, and use the proper name in
the example. The actual property was already documented properly.

Fixes: 2c8b082a ("dt-bindings: display: convert Arm Mali-DP to DT schema")
Link: https://lore.kernel.org/linux-arm-kernel/YnumGEilUblhBx8E@e110455-lin.cambridge.arm.com/Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Reported-by: NLiviu Dudau <liviu.dudau@arm.com>
Reviewed-by: NLiviu Dudau <liviu.dudau@arm.com>
Signed-off-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220609162729.1441760-1-andre.przywara@arm.com

Merge fixes for regressions introduced by the recent rework of the
system reboot/poweroff code.

* pm-sysoff:
  kernel/reboot: Fix powering off using a non-syscall code paths
  kernel/reboot: Use static handler for register_platform_power_off()

There's no reason to list the same value twice in an 'enum'. This was fixed
treewide in commit c3b00681 ("dt-bindings: Fix 'enum' lists with
duplicate entries"), but this one got added in the merge window.

A meta-schema change will catch future cases.
Signed-off-by: NRob Herring <robh@kernel.org>
Acked-by: NSergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20220606212239.1360877-1-robh@kernel.org

Pull documentation fixes from Jonathan Corbet:
 "A few documentation fixes for 5.19, including moving the new HTE docs
  to a more suitable location, adding loongarch to the features lists,
  and a couple of typo fixes"

* tag 'docs-5.19-3' of git://git.lwn.net/linux:
  docs: arm: tcm: Fix typo in description of TCM and MMU usage
  docs: Move the HTE documentation to driver-api/
  docs: usb: fix literal block marker in usbmon verification example
  Documentation/features: Update the arch support status files