Add support in ethtool for switching EQE/CQE mode.
Signed-off-by: Yufeng Mo <moyufeng@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
For device whose version is above V3(include V3), the GL can
select EQE or CQE mode, so adds support for it.
In CQE mode, the coalesced timer will restart when the first new
completion occurs, while in EQE mode, the timer will not restart.
Signed-off-by: Yufeng Mo <moyufeng@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In order to support more coalesce parameters through netlink,
add two new parameter kernel_coal and extack for .set_coalesce
and .get_coalesce, then some extra info can return to user with
the netlink API.
Signed-off-by: Yufeng Mo <moyufeng@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Currently, there are many drivers who support CQE mode configuration,
some configure it as a fixed when initialized, some provide an
interface to change it by ethtool private flags. In order to make it
more generic, add two new 'ETHTOOL_A_COALESCE_USE_CQE_TX' and
'ETHTOOL_A_COALESCE_USE_CQE_RX' coalesce attributes, then these
parameters can be accessed by ethtool netlink coalesce uAPI.
Also add an new structure kernel_ethtool_coalesce, then the
new parameter can be added into this struct.
Signed-off-by: Yufeng Mo <moyufeng@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Clang warns:
In file included from drivers/gpu/drm/i915/gt/intel_reset.c:1514:
drivers/gpu/drm/i915/gt/selftest_hangcheck.c:465:62: warning: variable
'err' is uninitialized when used here [-Wuninitialized]
pr_err("[%s] Create context failed: %d!\n", engine->name, err);
^~~
...
drivers/gpu/drm/i915/gt/selftest_hangcheck.c:580:62: warning: variable
'err' is uninitialized when used here [-Wuninitialized]
pr_err("[%s] Create context failed: %d!\n", engine->name, err);
^~~
...
2 warnings generated.
This appears to be a copy and paste issue. Use ce directly using the %pe
specifier to pretty print the error code so that err is not used
uninitialized in these functions.
Fixes: 3a7b72665e ("drm/i915/selftest: Bump selftest timeouts for hangcheck")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210813171158.2665823-1-nathan@kernel.org
(cherry picked from commit ac5a2dff42)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
If the intel_engine_create_pinned_context() function returns an error
pointer, then dereferencing "ce" will Oops. Use "vm" instead of
"ce->vm".
Fixes: cf58602164 ("drm/i915/gt: Pipelined page migration")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210813113600.GC30697@kili
(cherry picked from commit ff12ce2c9c)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
One of the cases that the bspec lists for when underrun recovery must be
disabled is "COG;" that note actually refers to eDP multi-segmented
operation (MSO). Let's ensure the this additional restriction is
honored by the driver.
Bspec: 50351
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: ba3b049f47 ("drm/i915/adl_p: Allow underrun recovery when possible")
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210816204112.2960624-1-matthew.d.roper@intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
(cherry picked from commit c00e14cd4d)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The kernel builds with -Werror=designated-init, and __designated_init
is used by CONFIG_GCC_PLUGIN_RANDSTRUCT for automatically selected (all
function pointer) structures. Include the field names in the init/exit
table. Avoids warnings like:
drivers/gpu/drm/i915/i915_module.c:59:4: error: positional initialization of field in 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: David Airlie <airlied@linux.ie>
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Fixes: a04ea6ae7c ("drm/i915: Use a table for i915_init/exit (v2)")
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210817233357.2379455-1-keescook@chromium.org
(cherry picked from commit 90fd2194a0)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
__bio_iov_append_get_pages() doesn't put not appended pages on
bio_add_hw_page() failure, so potentially leaking them, fix it. Also, do
the same for __bio_iov_iter_get_pages(), even though it looks like it
can't be triggered by userspace in this case.
Fixes: 0512a75b98 ("block: Introduce REQ_OP_ZONE_APPEND")
Cc: stable@vger.kernel.org # 5.8+
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Link: https://lore.kernel.org/r/1edfa6a2ffd66d55e6345a477df5387d2c1415d0.1626653825.git.asml.silence@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
The addition of the buckets conversion for the histogram code, updated the
documentation table of available conversions, but did not update the format
to accommodate the extra size needed to cover the description.
Link: https://lkml.kernel.org/r/20210823100007.71ce2ba9@oasis.local.home
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
f_hid provides the OUT Endpoint as only way for receiving reports
from the host. SETUP/SET_REPORT method is not supported, and this causes
a number of compatibility problems with various host drivers, especially
in the case of keyboard emulation using f_hid.
- Some hosts do not support the OUT Endpoint and ignore it,
so it becomes impossible for the gadget to receive a report
from the host. In the case of a keyboard, the gadget loses
the ability to receive the status of the LEDs.
- Some BIOSes/UEFIs can't work with HID devices with the OUT Endpoint
at all. This may be due to their bugs or incomplete implementation
of the HID standard.
For example, absolutely all Apple UEFIs can't handle the OUT Endpoint
if it goes after IN Endpoint in the descriptor and require the reverse
order (OUT, IN) which is a violation of the standard.
Other hosts either do not initialize gadgets with a descriptor
containing the OUT Endpoint completely (like some HP and DELL BIOSes
and embedded firmwares like on KVM switches), or initialize them,
but will not poll the IN Endpoint.
This patch adds configfs option no_out_endpoint=1 to disable
the OUT Endpoint and allows f_hid to receive reports from the host
via SETUP/SET_REPORT.
Previously, there was such a feature in f_hid, but it was replaced
by the OUT Endpoint [1] in the commit 99c5150058 ("usb: gadget: hidg:
register OUT INT endpoint for SET_REPORT"). So this patch actually
returns the removed functionality while making it optional.
For backward compatibility reasons, the OUT Endpoint mode remains
the default behaviour.
- The OUT Endpoint mode provides the report queue and reduces
USB overhead (eliminating SETUP routine) on transmitting a report
from the host.
- If the SETUP/SET_REPORT mode is used, there is no report queue,
so the userspace will only read last report. For classic HID devices
like keyboards this is not a problem, since it's intended to transmit
the status of the LEDs and only the last report is important.
This mode provides better compatibility with strange and buggy
host drivers.
Both modes passed USBCV tests. Checking with the USB protocol analyzer
also confirmed that everything is working as it should and the new mode
ensures operability in all of the described cases.
Link: https://www.spinics.net/lists/linux-usb/msg65494.html [1]
Reviewed-by: Maciej Żenczykowski <zenczykowski@gmail.com>
Acked-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Maxim Devaev <mdevaev@gmail.com>
Link: https://lore.kernel.org/r/20210821134004.363217-1-mdevaev@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
- Core has updates to support SoundWire mockup device (includes tag from
asoc), improved error handling and slave status.
- Drivers has update on Intel driver for new quriks and better handling of
errors and suspend routines
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE+vs47OPLdNbVcHzyfBQHDyUjg0cFAmEkgJ8ACgkQfBQHDyUj
g0eXEw/+MLJeThhmORvTeHuvo6MsuXAP2g88ZGaQdXG1QQ32nObnpjdgReSSVWRs
77UcGnoy45TNq6HnjJ8AH8hjPlnOwOEVxwCdJO55gcP8UTJYgxlSsHrANidngDge
Gal6Ch25AQptdLAtoP9otsCb146NQvi3FXA9s9ManrUO2zORR1/FmVb9sTMUf6JL
AkrKspStsnAGjziDwRBkTjmV1Oe0YMUgI4EAaNpQryJjT5NgVWYlsgovsazbc/GI
JUvuactLum/8QCPxFo5NzdXN3n0BJpT7qJ0Phl7qy7lX5bZA05ZdsxLBeb3Ked2z
YesZqfZhjBJlada439VdN1enThqs13FLBmkWRy1otbBovr+DPYmIqi48A1eSRENS
3MYVlOtPyuzHbVFmyngJ5yvpUyCPCj3HxEE88Srz2XDxhbGpQv4ecK2w/RUvO4Yu
7wrRHpRlHU9yLl92dyq0kRY9Owm9n1drmrspxoBKj53qWuZIr2LyBiyGrAOp7mao
7JUoBwhA089b/31Glc1ykYcTVIwt60uuewNY4lXh0EAZzfjKd4ZJOdiWf/sjsnWM
/qj4BZxWBg4HodNS5dE/pCGagVOpFyqMGYWcROliZ+jXLl5x/JNuJrM9M3hRfXu5
NB2hf8s+Bhvvpwop7i6/C0ZlzViUNmbLBF0gOeO6mM/8IOgSr0s=
=TCAF
-----END PGP SIGNATURE-----
Merge tag 'soundwire-5.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire into char-misc-next
Vinod writes:
soundwire updates for 5.15-rc1
- Core has updates to support SoundWire mockup device (includes tag from
asoc), improved error handling and slave status.
- Drivers has update on Intel driver for new quriks and better handling of
errors and suspend routines
* tag 'soundwire-5.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire:
soundwire: cadence: do not extend reset delay
soundwire: intel: conditionally exit clock stop mode on system suspend
soundwire: intel: skip suspend/resume/wake when link was not started
soundwire: intel: fix potential race condition during power down
soundwire: cadence: override PDI configurations to create loopback
soundwire: cadence: add debugfs interface for PDI loopbacks
soundwire: stream: don't program mockup device ports
soundwire: bus: squelch error returned by mockup devices
soundwire: add flag to ignore all command/control for mockup devices
soundwire: stream: don't abort bank switch on Command_Ignored/-ENODATA
soundwire: cadence: add paranoid check on self-clearing bits
soundwire: dmi-quirks: add quirk for Intel 'Bishop County' NUC M15
soundwire: bus: update Slave status in sdw_clear_slave_status
soundwire: cadence: Remove ret variable from sdw_cdns_irq()
soundwire: bus: filter out more -EDATA errors on clock stop
soundwire: dmi-quirks: add ull suffix for SoundWire _ADR values
ASoC: Intel: boards: sof_sdw: add SoundWire mockup codecs for tests
ASoC: soc-acpi: tgl: add table for SoundWire mockup devices
ASoC: soc-acpi: cnl: add table for SoundWire mockup devices
ASoC: codecs: add SoundWire mockup device support
- Updates:
- Yaml conversion for Freescale imx8mq usb phy, TI AM654 SERDES phy,
Cadence torrent phy
- Updates for Amlogic Meson8b-usb2 phy, Samsung ufs phy
- New support:
- UFS phy for Qualcomm SM6115
- PCIe & USB/DP phy for Qualcomm sc8180x
- USB3 PHY support for Qualcomm IPQ6018
- Renesas USB2.0 PHY for RZ/G2L
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE+vs47OPLdNbVcHzyfBQHDyUjg0cFAmEkfloACgkQfBQHDyUj
g0dwzA/9G658xS6jZSLTQX3PzWSpxk+mmmC2IR7fkeB5ShVcrju83PGRD0OQnpkG
aRZRZy20iGbuKkrA/+oIliVgNEg44D32zqD5pojHAfmwMUNMUP6R4YmAFNreJ3Do
sHXLlS3p9hhRZONKbl6VMg6rS4yTre79ozTovNH6HGyTlSObezAaKVjUTCofuSaa
/AXL2/WCINJuCtZmm67/AHxgzptK/h7FSqJdg4JET7Dt6Y/HN/WrNCwcyOlloteQ
Dyc+C0cdBncRK6A1og83A3jw7oiOhl2/72paCyQFljvS4v0BW8B3Sth1hukE2rsE
RmtP4EYSLN8uWXdLsBjerS09WFfjZBlE8UeU46AhzffCWOwCwgRwdJFpqUjN/OCO
ain9X16yQY8SBHShjxQAQMt5OtTNJCb0qhfcDa+47D5b+NNVJxfMoUTjPzqg7dpB
JJZZzUgNyd2PxvLApzgkYj5yqv/PN1cXB6UYqOQN/YojmyZKtIB1U+9JvY01Qb8c
9Dj92M7rUGzgfmUqLl4WPWhUZu56e0W/VRlYftFNOgAbQ+SehyG9CREaEqJCNzzl
m9HAL4ZzpK8hGQbS5FHiWrplcX8IQWd+XF8vXhkVV+wiE+ryGiPB5LrkjKfvEmoa
AgfpzHBOSATpR2nuRL/bruMZeHFhj2kzFQpg0MXhyfZAr06Zq5U=
=3U1A
-----END PGP SIGNATURE-----
Merge tag 'phy-for-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy into char-misc-next
Vinod writes:
phy-for-5.15
- Updates:
- Yaml conversion for Freescale imx8mq usb phy, TI AM654 SERDES phy,
Cadence torrent phy
- Updates for Amlogic Meson8b-usb2 phy, Samsung ufs phy
- New support:
- UFS phy for Qualcomm SM6115
- PCIe & USB/DP phy for Qualcomm sc8180x
- USB3 PHY support for Qualcomm IPQ6018
- Renesas USB2.0 PHY for RZ/G2L
* tag 'phy-for-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy: (45 commits)
phy: qcom-qmp: Add support for SM6115 UFS phy
dt-bindings: phy: qcom,qmp: Add SM6115 UFS PHY bindings
phy: qmp: Provide unique clock names for DP clocks
phy: xilinx: zynqmp: skip PHY initialization and PLL lock for USB
phy: amlogic: meson8b-usb2: don't log an error on -EPROBE_DEFER
phy: amlogic: meson8b-usb2: Power off the PHY by putting it into reset mode
phy: phy-mtk-mipi-dsi: convert to devm_platform_ioremap_resource
phy: phy-mtk-mipi-dsi: remove dummy assignment of error number
phy: phy-mtk-hdmi: convert to devm_platform_ioremap_resource
phy: phy-mtk-ufs: use clock bulk to get clocks
phy: phy-mtk-tphy: remove error log of ioremap failure
phy: phy-mtk-tphy: print error log using child device
phy: phy-mtk-tphy: support type switch by pericfg
phy: phy-mtk-tphy: use clock bulk to get clocks
dt-bindings: phy: mediatek: tphy: support type switch by pericfg
phy: cadence-torrent: Check PIPE mode PHY status to be ready for operation
phy: cadence-torrent: Add debug information for PHY configuration
phy: cadence-torrent: Add separate functions for reusable code
phy: cadence-torrent: Add PHY configuration for DP with 100MHz ref clock
phy: cadence-torrent: Add PHY registers for DP in array format
...
Here are changes for the 5.15-rc1 merge window consisting of interconnect
core and driver updates.
Framework change:
- Add sanity check to detect if node is already added to provider.
Driver changes:
- RPMh drivers probe function consolidation
- Add driver for SC8180x platforms
- Add support for SC8180x OSM L3
- Use driver-specific naming in OSM L3
Signed-off-by: Georgi Djakov <djakov@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJhI7tWAAoJEIDQzArG2BZjRWsQAIPaOLOBYGN7+aGLI0MO4aRx
u5P7i5QD/EJzSQ6z+MtNkzwgDV4+D6EzWxA2eyIPtHQsbpmift+qdWBVHPZcRFkD
sKV+B0NqJZSJe2W/RQ8u66yKaj931nbiSfxvCdpCB/Vamrfip8Bv7IO0hRsmFsSe
ji+UFg7SnCyou1C461visnl7+yGVwDB6e5BS7aXTYJ/3gl5lJ7IGooCwXs6w/EsS
FBBrvBqGU3ez61y6SYKrTQTI9MQEcioIUULXa0z8OGdAIqjfY3lWOIk6bhJTYFj8
snjowrGxMP+K7JzR9KgktB/eCivzYAdyMJKJrd6z1sPUS6vrAOLd0OZdHKVF87si
8s1ed6gUTkEK62Eg1OL1dIL3D6Ivf+UgGolz98hFqr2IxI/WRLGQ5oeuSHefiE8U
Rni13/vCNeM82mYIxk4e5VScM1PWPUdSPJl/40TgKELt7XvxKTPc0FO2u6mc+nRl
vsMJpnnVFszas0I40g0eIspWI4NYnukOFARP+2AXTpVuAylbf4YLkKSiwG1MN5TV
LdralsxcRLvp2ot9IliqmXjam+QJILK7GBpIqWe0jbo6ND4fGcd5ZN48pGmWxot6
mrNMXfq7cUbsG0aWrHIUZ8bISUEBlBBqqTSzKqVT4RtSZ8862lvQEHx5j72sQLj/
EYGoCI2F7tqFzs5P+qqm
=K/bk
-----END PGP SIGNATURE-----
Merge tag 'icc-5.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/djakov/icc into char-misc-next
Georgi writes:
interconnect changes for 5.15
Here are changes for the 5.15-rc1 merge window consisting of interconnect
core and driver updates.
Framework change:
- Add sanity check to detect if node is already added to provider.
Driver changes:
- RPMh drivers probe function consolidation
- Add driver for SC8180x platforms
- Add support for SC8180x OSM L3
- Use driver-specific naming in OSM L3
Signed-off-by: Georgi Djakov <djakov@kernel.org>
* tag 'icc-5.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/djakov/icc:
interconnect: qcom: osm-l3: Use driver-specific naming
interconnect: qcom: osm-l3: Add sc8180x support
dt-bindings: interconnect: Add SC8180x to OSM L3 DT binding
interconnect: qcom: Add SC8180x providers
dt-bindings: interconnect: Add Qualcomm SC8180x DT bindings
interconnect: Sanity check that node isn't already on list
interconnect: qcom: icc-rpmh: Consolidate probe functions
This includes following Thunderbolt/USB4 changes for the v5.15 merge
window:
* Include authorized value in the KOBJ_CHANGE event of a device router
* A couple of improvements to get the driver working also with the AMD
USB4 host controller.
All these have been in linux-next with no reported issues.
-----BEGIN PGP SIGNATURE-----
iQJUBAABCgA+FiEEVTdhRGBbNzLrSUBaAP2fSd+ZWKAFAmEkzz8gHG1pa2Eud2Vz
dGVyYmVyZ0BsaW51eC5pbnRlbC5jb20ACgkQAP2fSd+ZWKCU1hAAiyvLKqFBsgye
y8Zp6aeKkIjZ8wqnM0q97ba+cq23T/NwGsgSVDPLJesZc2hJPbAQIf0Iy3BKFjL3
G5feynsWxLhHqnOsY3tL7iw1lUJoreeagPycZ5Bj4xkVDEsCbvyGnDCrlLsO4MzP
Ia9zFN6kHyLGEmk0DROM1lAWZiAf7gIL6XW+mU2KDCYYaTcgQE2Im199yr3oqgi/
8y4VsYkHolg3r0DtiwKBa5jFZ+iiCJJqAjz8+Yh12bjB0+dSBlxJWSpeH/fsDPwq
FqMX6lMZuQPd71dlBOAIFr8RHjEg0owX8HUyxVb9MLoufhLFf0MIS/uKYRRfxTIH
zcTf8LOmZIM8FUqtsnXT3nO7rdCz2YWUmmjPLkYX2Ssi1XoxWvkeWBfKmZyXHiKB
uWwaHc3+uLSJSMvMqSLCTG6pK24Ux8C0LELoun4cj6CVi7018yLp+JiYAIn/QSoI
QFIXg9EKC2WOXo539LxlkNVDnLumVhc3e/Sg+ykq8KVj++AfMbZzaOpvyhuDs9cj
PHfSybRpC0+Q6RUMhazxjiMs2u8uRYkfp4kS6htg1MrxGcEbvv/22y0TuKl3D/nr
pBEZGELgvnMd69TuhFP9yM4504P6BFaoQCDy9XhReeUTbRnmBBMDG5uSAoj/+gbe
od3B0YhSIjujKBewMeXh689+30DYtqQ=
=1bPR
-----END PGP SIGNATURE-----
Merge tag 'thunderbolt-for-v5.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-next
Mika writes:
thunderbolt: Changes for v5.15 merge window
This includes following Thunderbolt/USB4 changes for the v5.15 merge
window:
* Include authorized value in the KOBJ_CHANGE event of a device router
* A couple of improvements to get the driver working also with the AMD
USB4 host controller.
All these have been in linux-next with no reported issues.
* tag 'thunderbolt-for-v5.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt:
thunderbolt: Fix port linking by checking all adapters
thunderbolt: Do not read control adapter config space
thunderbolt: Handle ring interrupt by reading interrupt status register
thunderbolt: Add vendor specific NHI quirk for auto-clearing interrupt status
thunderbolt: Add authorized value to the KOBJ_CHANGE uevent
According to SD specification checking state of DAT0 only, is enough while
polling for card busy completion. Let's update the comment in the header
file to correct this, as the comment says DAT[0:3].
Signed-off-by: Mårten Lindahl <marten.lindahl@axis.com>
Link: https://lore.kernel.org/r/20210816153054.24082-1-marten.lindahl@axis.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
When switching card voltage to UHS voltage the mmc framework tries to
check the card busy signal, meaning the card pulling DAT0 line low,
before the switch is made. Drivers that does not implement the card_busy
function will manage to do the switch anyway, but the framework will
print a warning about not being able to verify the voltage signal.
Implement card_busy function.
Signed-off-by: Mårten Lindahl <marten.lindahl@axis.com>
Link: https://lore.kernel.org/r/20210816142314.1168-1-marten.lindahl@axis.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The book3s_64_mmu_radix.o object is not part of the KVM builtins and
all the callers of the exported symbols are in the same kvm-hv.ko
module so we should not need to export any symbols.
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210805212616.2641017-4-farosas@linux.ibm.com
Both paths into __kvmhv_copy_tofrom_guest_radix ensure that we arrive
with an effective address that is smaller than our total addressable
space and addresses quadrant 0.
- The H_COPY_TOFROM_GUEST hypercall path rejects the call with
H_PARAMETER if the effective address has any of the twelve most
significant bits set.
- The kvmhv_copy_tofrom_guest_radix path clears the top twelve bits
before calling the internal function.
Although the callers make sure that the effective address is sane, any
future use of the function is exposed to a programming error, so add a
sanity check.
Suggested-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210805212616.2641017-3-farosas@linux.ibm.com
The __kvmhv_copy_tofrom_guest_radix function was introduced along with
nested HV guest support. It uses the platform's Radix MMU quadrants to
provide a nested hypervisor with fast access to its nested guests
memory (H_COPY_TOFROM_GUEST hypercall). It has also since been added
as a fast path for the kvmppc_ld/st routines which are used during
instruction emulation.
The commit def0bfdbd6 ("powerpc: use probe_user_read() and
probe_user_write()") changed the low level copy function from
raw_copy_from_user to probe_user_read, which adds a check to
access_ok. In powerpc that is:
static inline bool __access_ok(unsigned long addr, unsigned long size)
{
return addr < TASK_SIZE_MAX && size <= TASK_SIZE_MAX - addr;
}
and TASK_SIZE_MAX is 0x0010000000000000UL for 64-bit, which means that
setting the two MSBs of the effective address (which correspond to the
quadrant) now cause access_ok to reject the access.
This was not caught earlier because the most common code path via
kvmppc_ld/st contains a fallback (kvm_read_guest) that is likely to
succeed for L1 guests. For nested guests there is no fallback.
Another issue is that probe_user_read (now __copy_from_user_nofault)
does not return the number of bytes not copied in case of failure, so
the destination memory is not being cleared anymore in
kvmhv_copy_from_guest_radix:
ret = kvmhv_copy_tofrom_guest_radix(vcpu, eaddr, to, NULL, n);
if (ret > 0) <-- always false!
memset(to + (n - ret), 0, ret);
This patch fixes both issues by skipping access_ok and open-coding the
low level __copy_to/from_user_inatomic.
Fixes: def0bfdbd6 ("powerpc: use probe_user_read() and probe_user_write()")
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210805212616.2641017-2-farosas@linux.ibm.com
Add missing M7 core clock entry to the iMX8MN clock driver.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Abel Vesa <abel.vesa@nxp.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Cc: Abel Vesa <abel.vesa@nxp.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Link: https://lore.kernel.org/r/20210819202036.2084782-1-marex@denx.de
Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
On the i.MX8M*, the TF-A exposes a SiP (Silicon Provider) service
for DDR frequency scaling. The imx8m-ddrc-devfreq driver calls the
SiP and then does clk_set_parent on the DDR muxes to synchronize
the clock tree.
Since 936c383673 ("clk: imx: fix composite peripheral flags"),
these TF-A managed muxes have SET_PARENT_GATE set, which results
in imx8m-ddrc-devfreq's clk_set_parent after SiP failing with -EBUSY:
echo 25000000 > userspace/set_freq
imx8m-ddrc-devfreq 3d400000.memory-controller: failed to set
dram_apb parent: -16
Fix this by adding a new i.MX composite flag for firmware managed
clocks, which clears SET_PARENT_GATE.
This is safe to do, because updating the Linux clock tree to reflect
reality will always be glitch-free.
Fixes: 936c383673 ("clk: imx: fix composite peripheral flags")
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Reviewed-by: Abel Vesa <abel.vesa@nxp.com>
Link: https://lore.kernel.org/r/20210810151432.9228-1-a.fatoum@pengutronix.de
Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
.determine_rate is meant to replace .round_rate in CCF in the future.
Switch over to .determine_rate now that clk_divider_ops has gained
support for that.
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Abel Vesa <abel.vesa@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Abel Vesa <abel.vesa@nxp.com>
Link: https://lore.kernel.org/r/20210702225145.2643303-3-martin.blumenstingl@googlemail.com
Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
The mux in the clkout path needs the current selected parent to
be enabled for the switch to work. Use the correct mux type
to have the clk framework take care of this requirement.
Fixes: af4df655040 ("clk: imx8mn: add clkout1/2 support")
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Abel Vesa <abel.vesa@nxp.com>
Link: https://lore.kernel.org/r/20210628211554.2510238-2-l.stach@pengutronix.de
Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
The mux in the clkout path needs the current selected parent to
be enabled for the switch to work. Use the correct mux type
to have the clk framework take care of this requirement.
Fixes: c1ae5c6f78 ("clk: imx8mm: add clkout1/2 support")
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Abel Vesa <abel.vesa@nxp.com>
Link: https://lore.kernel.org/r/20210628211554.2510238-1-l.stach@pengutronix.de
Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
If sdhci use PIO mode, and use mmc_send_tuning() to send the tuning
command, system will stuck because of the storm irq of sdhci. For PIO mode,
use mmc_send_tuning(), it will trigger buffer_read_ready interrupt and data
transfer complete interrupt. In current code logic, it will directly
return in sdhci_data_irq, can not call the sdhci_transfer_pio(). So the
buffer_read_ready interrupt storm happen. So for standard tuning method,
need to exclude this case.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1628858041-1911-1-git-send-email-haibo.chen@nxp.com
[Ulf: Dropped redundant parenthesis in an expression]
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This might have been a neat debug aid when the extended dev_t was
added, but that time is long gone.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20210824075216.1179406-3-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
blk_alloc_ext_minor already returns just a minor number, so no need to
mask the high bits.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20210824075216.1179406-2-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
The resources that use the hns bitmap interface: qp, cq, mr, pd, xrcd,
uar, srq, have been changed to IDA interfaces, and the unused hns' own
bitmap interfaces need to be deleted.
Link: https://lore.kernel.org/r/1629336980-17499-4-git-send-email-liangwenpeng@huawei.com
Signed-off-by: Yangyang Li <liyangyang20@huawei.com>
Signed-off-by: Wenpeng Liang <liangwenpeng@huawei.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Switch srq index allocation and release from hns' own bitmap interface to
IDA interface.
Link: https://lore.kernel.org/r/1629336980-17499-3-git-send-email-liangwenpeng@huawei.com
Signed-off-by: Yangyang Li <liyangyang20@huawei.com>
Signed-off-by: Wenpeng Liang <liangwenpeng@huawei.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Switch uar index allocation and release from hns' own bitmap interface to
IDA interface.
Link: https://lore.kernel.org/r/1629336980-17499-2-git-send-email-liangwenpeng@huawei.com
Signed-off-by: Yangyang Li <liyangyang20@huawei.com>
Signed-off-by: Wenpeng Liang <liangwenpeng@huawei.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Commit 3efee0567b4a ("fs: remove mandatory file locking support") removes
some operations in functions rw_verify_area().
As these functions are now simplified, do some syntactic clean-up as
follow-up to the removal as well, which was pointed out by compiler
warnings and static analysis.
No functional change.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
ASPM is disabled completely because we've seen different types of
problems in the past. However it seems these problems occurred with
L1 or L1 sub-states only. On all the chip versions I've seen the
acceptable L0s exit latency is 512ns. This should be short enough not
to cause problems. If the actual L0s exit latency of the PCIe link
is bigger than 512ns then the PCI core will disable L0s anyway.
So let's give it a try and disable L1 and L1 sub-states only.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In early erratas this issue only covered port 0 when changing from
[x]MII (rev A 3.6). In subsequent errata versions this errata changed to
cover the additional "Hardware reset in CPU managed mode" condition, and
removed the note specifying that it only applied to port 0.
In designs where the device is configured with CPU managed mode
(CPU_MGD), on reset all SERDES ports (p0, p9, p10) have a stuck power
down bit and require this initial power up procedure. As such apply this
errata to all three SERDES ports of the mv88e6393x.
Signed-off-by: Nathan Rossi <nathan.rossi@digi.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There is no need to synchronize the account updating, so
use the relaxed atomic to avoid some memory barrier in the
data path.
Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
correct comments in set and get fn_sernum
Signed-off-by: zhang kai <zhangkaiheb@126.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix the following coccicheck warning:
./arch/x86/boot/compressed/kaslr.c:671:10-11:WARNING:return of 0/1
in function 'process_mem_region' with return type bool
Generated by: scripts/coccinelle/misc/boolreturn.cocci
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Jing Yangyang <jing.yangyang@zte.com.cn>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20210824070515.61065-1-deng.changcheng@zte.com.cn
When a fatal machine check results in a system reset, Linux does not
clear the error(s) from machine check bank(s) - hardware preserves the
machine check banks across a warm reset.
During initialization of the kernel after the reboot, Linux reads, logs,
and clears all machine check banks.
But there is a problem. In:
5de97c9f6d ("x86/mce: Factor out and deprecate the /dev/mcelog driver")
the call to mce_register_decode_chain() moved later in the boot
sequence. This means that /dev/mcelog doesn't see those early error
logs.
This was partially fixed by:
cd9c57cad3 ("x86/MCE: Dump MCE to dmesg if no consumers")
which made sure that the logs were not lost completely by printing
to the console. But parsing console logs is error prone. Users of
/dev/mcelog should expect to find any early errors logged to standard
places.
Add a new flag MCP_QUEUE_LOG to machine_check_poll() to be used in early
machine check initialization to indicate that any errors found should
just be queued to genpool. When mcheck_late_init() is called it will
call mce_schedule_work() to actually log and flush any errors queued in
the genpool.
[ Based on an original patch, commit message by and completely
productized by Tony Luck. ]
Fixes: 5de97c9f6d ("x86/mce: Factor out and deprecate the /dev/mcelog driver")
Reported-by: Sumanth Kamatala <skamatala@juniper.net>
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20210824003129.GA1642753@agluck-desk2.amr.corp.intel.com
Vladimir Oltean says:
====================
Plug holes in DSA's software bridging support
Changes in v2:
- Make sure that leaving an unoffloaded bridge works well too
- Remove a set but unused variable
- Tweak a commit message
This series addresses some oddities reported by Alvin while he was
working on the new rtl8365mb driver (a driver which does not implement
bridge offloading for now, and relies on software bridging).
First is that DSA behaves, in the lack of a .port_bridge_join method, as
if the operation succeeds, and does not kick off its internal procedures
for software bridging (the same procedures that were written for indirect
software bridging, meaning bridging with an unoffloaded software LAG).
Second is that even after being patched to treat ports with software
bridging as standalone, we still don't get rid of bridge VLANs, even
though we have code to ignore them, that code manages to get bypassed.
This is in fact a recurring issue which was brought up by Tobias
Waldekranz a while ago, but the solution never made it to the git tree.
After debugging with Florian the last time:
https://patchwork.kernel.org/project/netdevbpf/patch/20210320225928.2481575-3-olteanv@gmail.com/
I became very concerned about sending these patches to stable kernels.
They are relatively large reworks, and they are only tested properly on
net-next.
A few commands on my test vehicle which has ds->vlan_filtering_is_global
set to true:
| Nothing is committed to hardware when we add VLAN 100 on a standalone
| port
$ ip link add link sw0p2 name sw0p2.100 type vlan id 100
| When a neighbor port joins a VLAN-aware bridge, VLAN filtering gets
| enabled globally on the switch. This replays the VLAN 100 from
| sw0p2.100 and also installs VLAN 1 from the bridge on sw0p0.
$ ip link add br0 type bridge vlan_filtering 1 && ip link set sw0p0 master br0
[ 97.948087] sja1105 spi2.0: Reset switch and programmed static config. Reason: VLAN filtering
[ 97.957989] sja1105 spi2.0: sja1105_bridge_vlan_add: port 2 vlan 100
[ 97.964442] sja1105 spi2.0: sja1105_bridge_vlan_add: port 4 vlan 100
[ 97.971202] device sw0p0 entered promiscuous mode
[ 97.976129] sja1105 spi2.0: sja1105_bridge_vlan_add: port 0 vlan 1
[ 97.982640] sja1105 spi2.0: sja1105_bridge_vlan_add: port 4 vlan 1
| We can see that sw0p2, the standalone port, is now filtering because
| of the bridge
$ ethtool -k sw0p2 | grep vlan
rx-vlan-filter: on [fixed]
| When we make the bridge VLAN-unaware, the 8021q upper sw0p2.100 is
| uncomitted from hardware. The VLANs managed by the bridge still remain
| committed to hardware, because they are managed by the bridge.
$ ip link set br0 type bridge vlan_filtering 0
[ 134.218869] sja1105 spi2.0: Reset switch and programmed static config. Reason: VLAN filtering
[ 134.228913] sja1105 spi2.0: sja1105_bridge_vlan_del: port 2 vlan 100
| And now the standalone port is not filtering anymore.
ethtool -k sw0p2 | grep vlan
rx-vlan-filter: off [fixed]
The same test with .port_bridge_join and .port_bridge_leave commented
out from this driver:
| Not a flinch
$ ip link add link sw0p2 name sw0p2.100 type vlan id 100
$ ip link add br0 type bridge vlan_filtering 1 && ip link set sw0p0 master br0
Warning: dsa_core: Offloading not supported.
$ ethtool -k sw0p2 | grep vlan
rx-vlan-filter: off [fixed]
$ ip link set br0 type bridge vlan_filtering 0
$ ethtool -k sw0p2 | grep vlan
rx-vlan-filter: off [fixed]
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
As explained in commit e358bef7c3 ("net: dsa: Give drivers the chance
to veto certain upper devices"), the hellcreek driver uses some tricks
to comply with the network stack expectations: it enforces port
separation in standalone mode using VLANs. For untagged traffic,
bridging between ports is prevented by using different PVIDs, and for
VLAN-tagged traffic, it never accepts 8021q uppers with the same VID on
two ports, so packets with one VLAN cannot leak from one port to another.
That is almost fine*, and has worked because hellcreek relied on an
implicit behavior of the DSA core that was changed by the previous
patch: the standalone ports declare the 'rx-vlan-filter' feature as 'on
[fixed]'. Since most of the DSA drivers are actually VLAN-unaware in
standalone mode, that feature was actually incorrectly reflecting the
hardware/driver state, so there was a desire to fix it. This leaves the
hellcreek driver in a situation where it has to explicitly request this
behavior from the DSA framework.
We configure the ports as follows:
- Standalone: 'rx-vlan-filter' is on. An 8021q upper on top of a
standalone hellcreek port will go through dsa_slave_vlan_rx_add_vid
and will add a VLAN to the hardware tables, giving the driver the
opportunity to refuse it through .port_prechangeupper.
- Bridged with vlan_filtering=0: 'rx-vlan-filter' is off. An 8021q upper
on top of a bridged hellcreek port will not go through
dsa_slave_vlan_rx_add_vid, because there will not be any attempt to
offload this VLAN. The driver already disables VLAN awareness, so that
upper should receive the traffic it needs.
- Bridged with vlan_filtering=1: 'rx-vlan-filter' is on. An 8021q upper
on top of a bridged hellcreek port will call dsa_slave_vlan_rx_add_vid,
and can again be vetoed through .port_prechangeupper.
*It is not actually completely fine, because if I follow through
correctly, we can have the following situation:
ip link add br0 type bridge vlan_filtering 0
ip link set lan0 master br0 # lan0 now becomes VLAN-unaware
ip link set lan0 nomaster # lan0 fails to become VLAN-aware again, therefore breaking isolation
This patch fixes that corner case by extending the DSA core logic, based
on this requested attribute, to change the VLAN awareness state of the
switch (port) when it leaves the bridge.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Kurt Kanzenbach <kurt@linutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
There have been multiple independent reports about
dsa_slave_vlan_rx_add_vid being called (and consequently calling the
drivers' .port_vlan_add) when it isn't needed, and sometimes (not
always) causing problems in the process.
Case 1:
mv88e6xxx_port_vlan_prepare is stubborn and only accepts VLANs on
bridged ports. That is understandably so, because standalone mv88e6xxx
ports are VLAN-unaware, and VTU entries are said to be a scarce
resource.
Otherwise said, the following fails lamentably on mv88e6xxx:
ip link add br0 type bridge vlan_filtering 1
ip link set lan3 master br0
ip link add link lan10 name lan10.1 type vlan id 1
[485256.724147] mv88e6085 d0032004.mdio-mii:12: p10: hw VLAN 1 already used by port 3 in br0
RTNETLINK answers: Operation not supported
This has become a worse issue since commit 9b236d2a69 ("net: dsa:
Advertise the VLAN offload netdev ability only if switch supports it").
Up to that point, the driver was returning -EOPNOTSUPP and DSA was
reconverting that error to 0, making the 8021q upper think all is ok
(but obviously the error message was there even prior to this change).
After that change the -EOPNOTSUPP is propagated to vlan_vid_add, and it
is a hard error.
Case 2:
Ports that don't offload the Linux bridge (have a dp->bridge_dev = NULL
because they don't implement .port_bridge_{join,leave}). Understandably,
a standalone port should not offload VLANs either, it should remain VLAN
unaware and any VLAN should be a software VLAN (as long as the hardware
is not quirky, that is).
In fact, dsa_slave_port_obj_add does do the right thing and rejects
switchdev VLAN objects coming from the bridge when that bridge is not
offloaded:
case SWITCHDEV_OBJ_ID_PORT_VLAN:
if (!dsa_port_offloads_bridge_port(dp, obj->orig_dev))
return -EOPNOTSUPP;
err = dsa_slave_vlan_add(dev, obj, extack);
But it seems that the bridge is able to trick us. The __vlan_vid_add
from br_vlan.c has:
/* Try switchdev op first. In case it is not supported, fallback to
* 8021q add.
*/
err = br_switchdev_port_vlan_add(dev, v->vid, flags, extack);
if (err == -EOPNOTSUPP)
return vlan_vid_add(dev, br->vlan_proto, v->vid);
So it says "no, no, you need this VLAN in your life!". And we, naive as
we are, say "oh, this comes from the vlan_vid_add code path, it must be
an 8021q upper, sure, I'll take that". And we end up with that bridge
VLAN installed on our port anyway. But this time, it has the wrong flags:
if the bridge was trying to install VLAN 1 as a pvid/untagged VLAN,
failed via switchdev, retried via vlan_vid_add, we have this comment:
/* This API only allows programming tagged, non-PVID VIDs */
So what we do makes absolutely no sense.
Backtracing a bit, we see the common pattern. We allow the network stack
to think that our standalone ports are VLAN-aware, but they aren't, for
the vast majority of switches. The quirky ones should not dictate the
norm. The dsa_slave_vlan_rx_add_vid and dsa_slave_vlan_rx_kill_vid
methods exist for drivers that need the 'rx-vlan-filter: on' feature in
ethtool -k, which can be due to any of the following reasons:
1. vlan_filtering_is_global = true, and some ports are under a
VLAN-aware bridge while others are standalone, and the standalone
ports would otherwise drop VLAN-tagged traffic. This is described in
commit 061f6a505a ("net: dsa: Add ndo_vlan_rx_{add, kill}_vid
implementation").
2. the ports that are under a VLAN-aware bridge should also set this
feature, for 8021q uppers having a VID not claimed by the bridge.
In this case, the driver will essentially not even know that the VID
is coming from the 8021q layer and not the bridge.
3. Hellcreek. This driver needs it because in standalone mode, it uses
unique VLANs per port to ensure separation. For separation of untagged
traffic, it uses different PVIDs for each port, and for separation of
VLAN-tagged traffic, it never accepts 8021q uppers with the same vid
on two ports.
If a driver does not fall under any of the above 3 categories, there is
no reason why it should advertise the 'rx-vlan-filter' feature, therefore
no reason why it should offload the VLANs added through vlan_vid_add.
This commit fixes the problem by removing the 'rx-vlan-filter' feature
from the slave devices when they operate in standalone mode, and when
they offload a VLAN-unaware bridge.
The way it works is that vlan_vid_add will now stop its processing here:
vlan_add_rx_filter_info:
if (!vlan_hw_filter_capable(dev, proto))
return 0;
So the VLAN will still be saved in the interface's VLAN RX filtering
list, but because it does not declare VLAN filtering in its features,
the 8021q module will return zero without committing that VLAN to
hardware.
This gives the drivers what they want, since it keeps the 8021q VLANs
away from the VLAN table until VLAN awareness is enabled (point at which
the ports are no longer standalone, hence in the mv88e6xxx case, the
check in mv88e6xxx_port_vlan_prepare passes).
Since the issue predates the existence of the hellcreek driver, case 3
will be dealt with in a separate patch.
The main change that this patch makes is to no longer set
NETIF_F_HW_VLAN_CTAG_FILTER unconditionally, but toggle it dynamically
(for most switches, never).
The second part of the patch addresses an issue that the first part
introduces: because the 'rx-vlan-filter' feature is now dynamically
toggled, and our .ndo_vlan_rx_add_vid does not get called when
'rx-vlan-filter' is off, we need to avoid bugs such as the following by
replaying the VLANs from 8021q uppers every time we enable VLAN
filtering:
ip link add link lan0 name lan0.100 type vlan id 100
ip addr add 192.168.100.1/24 dev lan0.100
ping 192.168.100.2 # should work
ip link add br0 type bridge vlan_filtering 0
ip link set lan0 master br0
ping 192.168.100.2 # should still work
ip link set br0 type bridge vlan_filtering 1
ping 192.168.100.2 # should still work but doesn't
As reported by Florian, some drivers look at ds->vlan_filtering in
their .port_vlan_add() implementation. So this patch also makes sure
that ds->vlan_filtering is committed before calling the driver. This is
the reason why it is first committed, then restored on the failure path.
Reported-by: Tobias Waldekranz <tobias@waldekranz.com>
Reported-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If the driver does not implement .port_bridge_{join,leave}, then we must
fall back to standalone operation on that port, and trigger the error
path of dsa_port_bridge_join. This sets dp->bridge_dev = NULL.
In turn, having a non-NULL dp->bridge_dev when there is no offloading
support makes the following things go wrong:
- dsa_default_offload_fwd_mark make the wrong decision in setting
skb->offload_fwd_mark. It should set skb->offload_fwd_mark = 0 for
ports that don't offload the bridge, which should instruct the bridge
to forward in software. But this does not happen, dp->bridge_dev is
incorrectly set to point to the bridge, so the bridge is told that
packets have been forwarded in hardware, which they haven't.
- switchdev objects (MDBs, VLANs) should not be offloaded by ports that
don't offload the bridge. Standalone ports should behave as packet-in,
packet-out and the bridge should not be able to manipulate the pvid of
the port, or tag stripping on egress, or ingress filtering. This
should already work fine because dsa_slave_port_obj_add has:
case SWITCHDEV_OBJ_ID_PORT_VLAN:
if (!dsa_port_offloads_bridge_port(dp, obj->orig_dev))
return -EOPNOTSUPP;
err = dsa_slave_vlan_add(dev, obj, extack);
but since dsa_port_offloads_bridge_port works based on dp->bridge_dev,
this is again sabotaging us.
All the above work in case the port has an unoffloaded LAG interface, so
this is well exercised code, we should apply it for plain unoffloaded
bridge ports too.
Reported-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
