Skip to content
  1. Oct 30, 2020
  3. Oct 23, 2020
  5. Oct 22, 2020
  7. Oct 21, 2020
  9. Oct 20, 2020
    • Ard Biesheuvel's avatar
      netsec: ignore 'phy-mode' device property on ACPI systems · acd7aaf5
      Ard Biesheuvel authored 
      

Since commit bbc4d71d ("net: phy: realtek: fix rtl8211e rx/tx
delay config"), the Realtek PHY driver will override any TX/RX delay
set by hardware straps if the phy-mode device property does not match.

This is causing problems on SynQuacer based platforms (the only SoC
that incorporates the netsec hardware), since many were built with
this Realtek PHY, and shipped with firmware that defines the phy-mode
as 'rgmii', even though the PHY is configured for TX and RX delay using
pull-ups.

From the driver's perspective, we should not make any assumptions in
the general case that the PHY hardware does not require any initial
configuration. However, the situation is slightly different for ACPI
boot, since it implies rich firmware with AML abstractions to handle
hardware details that are not exposed to the OS. So in the ACPI case,
it is reasonable to assume that the PHY comes up in the right mode,
regardless of whether the mode is set by straps, by boot time firmware
or by AML executed by the ACPI interpreter.

So let's ignore the 'phy-mode' device property when probing the netsec
driver in ACPI mode, and hardcode the mode to PHY_INTERFACE_MODE_NA,
which should work with any PHY provided that it is configured by the
time the driver attaches to it. While at it, document that omitting
the mode is permitted for DT probing as well, by setting the phy-mode
DT property to the empty string.

Fixes: 533dd11a ("net: socionext: Add Synquacer NetSec driver")
Signed-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
Reviewed-by: default avatarIlias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20201018163625.2392-1-ardb@kernel.org


Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      acd7aaf5
    • Jeremy Sowden's avatar
      docs: nf_flowtable: fix typo. · 64747d5e
      Jeremy Sowden authored 
      

"mailined" should be "mainlined."

Signed-off-by: default avatarJeremy Sowden <jeremy@azazel.net>
Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      64747d5e
    • Juergen Gross's avatar
      xen/events: defer eoi in case of excessive number of events · e99502f7
      Juergen Gross authored 
      

In case rogue guests are sending events at high frequency it might
happen that xen_evtchn_do_upcall() won't stop processing events in
dom0. As this is done in irq handling a crash might be the result.

In order to avoid that, delay further inter-domain events after some
time in xen_evtchn_do_upcall() by forcing eoi processing into a
worker on the same cpu, thus inhibiting new events coming in.

The time after which eoi processing is to be delayed is configurable
via a new module parameter "event_loop_timeout" which specifies the
maximum event loop time in jiffies (default: 2, the value was chosen
after some tests showing that a value of 2 was the lowest with an
only slight drop of dom0 network throughput while multiple guests
performed an event storm).

How long eoi processing will be delayed can be specified via another
parameter "event_eoi_delay" (again in jiffies, default 10, again the
value was chosen after testing with different delay values).

This is part of XSA-332.

Cc: stable@vger.kernel.org
Reported-by: default avatarJulien Grall <julien@xen.org>
Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
Reviewed-by: default avatarStefano Stabellini <sstabellini@kernel.org>
Reviewed-by: default avatarWei Liu <wl@xen.org>
      e99502f7
  11. Oct 19, 2020
  13. Oct 16, 2020