If CONFIG_RFKILL is not set, the Intel WiFi driver will not build
the iw_mvm driver part due to the missing rfill_soft_blocked()
call. Adding a inline declaration of rfill_soft_blocked() if
CONFIG_RFKILL=n fixes the following error:
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h: In function 'iwl_mvm_mei_set_sw_rfkill_state':
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h:2215:38: error: implicit declaration of function 'rfkill_soft_blocked'; did you mean 'rfkill_blocked'? [-Werror=implicit-function-declaration]
2215 | mvm->hw_registered ? rfkill_soft_blocked(mvm->hw->wiphy->rfkill) : false;
| ^~~~~~~~~~~~~~~~~~~
| rfkill_blocked
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Reported-by: Neill Whillans <neill.whillans@codethink.co.uk>
Fixes: 5bc9a9dd75 ("rfkill: allow to get the software rfkill state")
Link: https://lore.kernel.org/r/20220218093858.1245677-1-ben.dooks@codethink.co.uk
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
1. Several updates in the MTK SMI bindings.
2. Add support for MT8186 MTK SMI and improvements in support for MT8195.
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEE3dJiKD0RGyM7briowTdm5oaLg9cFAmIc+t8QHGtyemtAa2Vy
bmVsLm9yZwAKCRDBN2bmhouD10TUD/wMFqZN6N1363avdimmxK+kgBEHeAFCYd1U
Hg9eHWnfWnLoMBV4n91seE9kUHkJQYcI5YMJGtjKvyBB+nJzsK98XsjSJSmie6YI
0rUtllQ6z+bAEQPoZi8Z1u9iqktjVpzgWwQBN3fpC6mwNtRNXNsw9Y33qiDY3sO8
WfRJxSKRG+N/W5FT/BP3pX8FIi3+i+FkKNs7YEky15Vcriq5FlJGRDE0qGMRN/FO
kJ10XU0Qeo3BcKwjk4Cv4RucoawhQbFLST5U36c3J9goUGZG5rcbWszBAB5SvRme
CrZXcvL7E6wjzbgLFwCp9Ci5F66rkuigxl0GiSOJI8DhOWPcxmLMB0PPxf5Fa8cg
pfMih48/I7f5syxmSeFgPe4nxLV5ARbZobWP0GHQ/NqtsUaamKAVXDQGDVRaGiU0
ZK1eOG15gFaX0eNxmyYIuNAeZzDRoxbeFsgj4S0hUmhRiO7C2qSQbxT/aRYSFXrW
pgoXCKmxWY2dgqgR+v8A6SoHXwih93Irp15TkbimSS3mqkpyOJic1JelCgw7aZiQ
mXtwTjqMidYQ1BZgbZBM9wb4y6w2y1gNIDgQq62Mb957a1OFda5XC9iae7+zZWMJ
wq6lztAOEfmxgeicxmg5zanSGI+AuFZWR7RLhK9aAAiKc5EEaRsWgQfrPqxcKqg0
w3bxG6naAw==
=V7gd
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmId7NwACgkQmmx57+YA
GNkFdBAArWHbYlA28Ud5e/cDIgvaD6mQiXBmw+fz0yHHqQpkZMs74whJsJmQzaNp
gJDs9/pakjPJc+tEa7Y19t0W2i+ppfpdUo43yth4KRT3RMvmuFW4Ir5HC6ipRQRy
tYWTJNL+Qmkv1Xtqz1BThyw/pJN8M1Uv+wqCi6iWFw1V2xShXRJ5pWEtEoROPLxq
EK8c+STsipRnmsYPc27trjpjwxoswGShC6HVZzQQBJKO9UnTStPJ0TMCvZdUiMw8
LIhe3r8t3kLeuxMnAElCA++eMFgLfCrS+uqcoQXAwWR1qiZzBj80LPNggMsNLMsG
+rR/5opOGzrk6mGkGYhnFB59zhoO0Qb43NG+xNdEgH72opOiuhCMWEP5CoA2v1Rv
CHLaPme5jVWbhuHISOLbBSS26kt6teg4gj8FBs9a6d0/lyWrqEka/9G7LJcdhG8N
IOHz71+WY3cbhxLjyJH2lujZfzsaG/n0XHw4BIlZrD+AWraeEKQt/MlVpK/f/5B/
GtvZMa+C1O4/Uzhp1dPbZFulIOzRzVZ5uGJ/LESPmSkf5UncePBMDwEDaCz78d5/
oNcdJspM3FJwEtOsr3k6+wc4Jk3P/tXr7xxDDNKXkHQuTH04LPywo6yPCB/9KeMb
NXQbY7i6crGPwnws5CxAUamhqkt7ZMC/oBFWHlMtoZYz1KQllj0=
=Bquy
-----END PGP SIGNATURE-----
Merge tag 'memory-controller-drv-mediatek-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into arm/drivers
Memory controller drivers for v5.18 - Mediatek SoC
1. Several updates in the MTK SMI bindings.
2. Add support for MT8186 MTK SMI and improvements in support for MT8195.
* tag 'memory-controller-drv-mediatek-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl:
memory: mtk-smi: Enable sleep ctrl safety function for MT8195
memory: mtk-smi: mt8186: Add smi support
memory: mtk-smi: Add sleep ctrl function
memory: mtk-smi: handle positive return value for clk_bulk_prepare_enable
dt-bindings: memory: mediatek: Add mt8186 support
dt-bindings: memory: mtk-smi: Correct minItems to 2 for the gals clocks
dt-bindings: memory: mtk-smi: No need mediatek,larb-id for mt8167
dt-bindings: memory: mtk-smi: Rename clock to clocks
Link: https://lore.kernel.org/r/20220228164313.52931-2-krzysztof.kozlowski@canonical.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The SDX65 platform and MTP device was added twice to the DT binding,
this drops one of the occurances.
-----BEGIN PGP SIGNATURE-----
iQJPBAABCAA5FiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmIdlPsbHGJqb3JuLmFu
ZGVyc3NvbkBsaW5hcm8ub3JnAAoJEAsfOT8Nma3FCW8QAL0dIlj+m0grZxXg3UMI
yg8SxZxzHu5SHGXr8z0Xa6pHWjM9BFJ9NYXgqIz0+4eeQuhjW8FZWAM4jWasDW2S
ZXQCBsKR1FhtbQEiMUVcPaAn6ll04N9ZrsUkTwiE6652/8wSdLSrYOlcVnDwRMbp
SFrrCX/ojQ+/mvaUDk80Jpz8rUeXCv9GRuocgobyD8t6H8D/y7s1T83XYUh4vwqf
7wMLVOoujkRuhhxmBNpAZG1BiOdxGegkWevrcaO4uZjmDf2HMHL0+co9UkpIEqtM
y52wjeFHm9SSiCVi1R+h7yJIam77uZU+uCGr3hR81v12p71uxWkF6qGq1Jq+GCy4
GbNYqVlqtxYX4z85N7g3T5igFNMqU6Sd+9a1X6ccSbSv3EysK4Z89AbYs4hr6TV2
03kzHfWJHqc4kWKNbLqcvJ1P8x8oWh255GO1lEeic77EWrDN883YWBbxY1n8b6yO
b6YFMBUQiTz7SvMF48nu2t4A9m0HYAJ3EIMHAsqhW9QTj6V5hPyDSwXNUcVtCFot
334NuY2TkGJtd9H7n8ev7GBIqykq1/60ivzl5X90FhNSjK0UZdlq5ou+PWA3apSp
Fyh1sE2K+L0PVTbP0qUDXj3frrgKxkuSAmhICVZKfiztLtZ03t2pNsd7J0kk+E5a
SNSsUFBHmRfhtxRixAXbIgAE
=4pdZ
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmId61QACgkQmmx57+YA
GNmj/hAAnOrYQaT+AwWbErMfvmKRTwLCcOUMO70Kwk+9pkcNcgq1BsxyZwPsPxyH
dBF1HmzrQ74nIR0dVWpRgTbXSyhZ+rgcm6N4t7tEV2zzk6oIByKvHUwI90oaAvnr
X88z+sbnj6Tct1nKnfAI44pIoSlmF93wC+m2/6uioS6IefU0Fh96sOYTC4eKKxPd
FJQ2FxQFQydfJjoLb7Bx0eWa7bQk4Ab5ewjfnG/q/rqAAZHPe8J9d3YdBXZjr7Vw
QpwGJIKW/xsmNx0T3WFpsCW26fXyFu9gZtp/fthzdsyioaGt+XbceezG+n23+541
P2JeDaEVm06DLu5DoIPrjZ2oDA2F3sYQLwIRL3EN9hlZbq3lQpZcs6tpIqQXqnGy
r9bgYrcLP1aL031SsAN/f6sXiyvkr61Zoy5DOFmT+5qZU/TFIkBczoz9kmm2mcgo
bc8n8/mEPTcRIc87TEdbXd4aO8bcwIBt84Fb3E0pbq4Mv5aNTtvabyuFuPEbsSPj
ELQF663ILTUiZdRVel/IZ26E8q9DgD042Dtd8hmcCOs/Wxuj/f1OJctnhzk/nDlp
5MSrerOse2pmQA1QeXI7nkXtRsxwJjsljHoHn2Gu6S88Dfo7aCpHtOaAsAQorK0f
MwvkdBqv7xfsNyTniYFy7dVbb+2llpG5NF57YscjVQrWt+2tIsY=
=JDqJ
-----END PGP SIGNATURE-----
Merge tag 'qcom-dts-fixes-for-5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes
Qualcomm DeviceTree fixes for v5.17
The SDX65 platform and MTP device was added twice to the DT binding,
this drops one of the occurances.
* tag 'qcom-dts-fixes-for-5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
Revert "dt-bindings: arm: qcom: Document SDX65 platform and boards"
Link: https://lore.kernel.org/r/20220301033838.1801689-1-bjorn.andersson@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This starts off by fixing an issue introduced in a bug fix in the
global clock controller, where the symbol clocks for UFS would
end up picking the wrong parent clock which breaks UFS.
It then makes sure that the reference clock for the USB blocks are
enabled, even with booting without clk_ignore_unused.
It corrects the apps SMMU interrupts defintion by adding a missing
interrupt in the list.
Lastly it disables the Qualcomm crypto hardware (for now) on the Lenovo
Yoga C630, to prevent the cryptomanager tests during boot from crashing
the device.
-----BEGIN PGP SIGNATURE-----
iQJPBAABCAA5FiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmIdk9IbHGJqb3JuLmFu
ZGVyc3NvbkBsaW5hcm8ub3JnAAoJEAsfOT8Nma3Fi0UQAJEw6/F9aFsdaGRHO3D+
XhgEooCMMbF0QNewWdw5FXoYW46SH2enl3monIHSAbyoKO6mkzXxBmuOOfpIvkNj
mmqW6gOhsqa4ZUlAwJ9Q1OzQUuOfaLtvORMk0NSi6BohvNqtsN1mVNbYUlpEiYLj
9O2QHoLlKoq+yGUMvFOb+dLScGI2oLfqpfewLW+wRSNuDfLhZxbd850MeWH0ZpuQ
qOPSF+2WStVvf9ZZSijSPqZBl5gtf0fHiwXBJQfxdQvHcAMk4OKKZySSl8xJhX5i
Tgn/+5+B2bLIga1DdmfYu1y3h/05w2420qdVkouh5ue0YtZfp1I6LRUwJfNLnkzA
elu+p4N5g+8QstSV0ntN5cBpQSqqQodXOolcxDG9K/GdZwHdsOsC4Mgfowg6RMRI
hTWmGIT+ZDfXUlpJa6ZLv3qUEm4MqLKbNcVYYKqJD7UJJxOlw46owKvjJpJwAyxP
yzkJhXCzDb9rV6pPqj3XslWIl25xNipi5Spm8EXkL5SyZijF9RLlzCqnnMjGueNp
GHl4hKMJeyWxoOuiFhF7oCymQLnroEgzAJddWHqmH4lT2CZuri1yLiZGiTTBm8B/
Q7SuT9sAqQKUKM25o6XPdUS7JGLDVDIVSGORIQLeYLc8IddBCfDGIf7YJAzBhs0x
ROuQCmuSyUncsjO5AEXdOrSK
=soai
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmId60sACgkQmmx57+YA
GNl98w/+KWpsJ/FLxKqSsCjeqp2j6x4wkq/krSLelCI56G3BLhdI8SxnD4GUdiA3
yR5B8Hev1JFp/YlqU2F8JSyDwKKUkp1ghP1KuAkl1CWbgZo5TOGwOw4ZqBH8jUgd
mKNMfA+6m7Hqcwpq6ojN6r2HZKg315N22/egRsOPpx6Du5iGKGeepjiGXbixVyWe
EdI9gDKCuDSqg2Ium1z0oKwPUNTbFBHkrMXYDmlJFoSz63lJEpDvoJZHKx05hri1
S/PCzcoBEOVk91jKlrC1lnlofpCVcuoTnZ72awAOyIwMrvcjkw+nB6E3zHSuD818
RFBUgGu5CwfdhShMr1J8kcOgvhobnSgs0YH7shY99BsxJkwCwUkjbUJN/ihG4TN6
qnGvr2PbA6vphBIDPLcXj2gBSJyB8feu7xD9Su+H+6BgriP0hLQ0WOIMbznM808U
3fR8K0tqzfPx9MeEcdOYZ29wvATUn6++GZjszZEeDVkpqQJIhbscrHOZhOKgz/TR
l62chtqp1wt/hpspjzYOfDCbETS+qBhXtgz4Y8RArx7fGbdKbjZOMdAaoVzPQuKG
tSsjDH+7OpnBQ4+PeDd9044P8h6XyYT9SE5CqDI5WfNOLZve2fZuepbEwQI9KnKz
qzkFIyDq518IMWvTJMc2ethrgTrBlGp02fk7o6v1Jo1VwoWDhwY=
=9VJk
-----END PGP SIGNATURE-----
Merge tag 'qcom-arm64-fixes-for-5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes
Qualcomm ARM64 DeviceTree fixes for 5.17
This starts off by fixing an issue introduced in a bug fix in the
global clock controller, where the symbol clocks for UFS would
end up picking the wrong parent clock which breaks UFS.
It then makes sure that the reference clock for the USB blocks are
enabled, even with booting without clk_ignore_unused.
It corrects the apps SMMU interrupts defintion by adding a missing
interrupt in the list.
Lastly it disables the Qualcomm crypto hardware (for now) on the Lenovo
Yoga C630, to prevent the cryptomanager tests during boot from crashing
the device.
* tag 'qcom-arm64-fixes-for-5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
arm64: dts: qcom: c630: disable crypto due to serror
arm64: dts: qcom: sm8450: fix apps_smmu interrupts
arm64: dts: qcom: sm8450: enable GCC_USB3_0_CLKREF_EN for usb
arm64: dts: qcom: sm8350: Correct UFS symbol clocks
Link: https://lore.kernel.org/r/20220301033526.1801295-1-bjorn.andersson@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
It was the intention to reverse the bits, not make them all zero by
using logical NOT operator.
Fixes: cc19db8b31 ("MIPS: ralink: mt7621: do memory detection on KSEG1")
Suggested-by: Chuanhong Guo <gch981213@gmail.com>
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
Reviewed-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Exercise each of the migration scenarios, verifying that the final
placement and buffer contents match our expectations.
v2(Thomas): Replace for_i915_gem_ww() block with simpler object_lock()
v3:
- For testing purposes allow forcing the io_size such that we can
exercise the allocation + migration path on devices that don't have the
small BAR limit.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220228123607.580432-4-matthew.auld@intel.com
If we have to contend with non-mappable LMEM, then we need to ensure the
object fits within the mappable portion, like in the selftests, where we
later try to CPU access the pages. However if it can't then we need to
gracefully handle this, without throwing an error.
Also it looks like TTM will return -ENOMEM, in ttm_bo_mem_space() after
exhausting all possible placements.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Acked-by: Nirmoy Das <nirmoy.das@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220228123607.580432-3-matthew.auld@intel.com
The end goal is to have userspace tell the kernel what buffers will
require CPU access, however if we ever reach the CPU fault handler, and
the current resource is not mappable, then we should attempt to migrate
the buffer to the mappable portion of LMEM, or even system memory, if the
allowable placements permit it.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220228123607.580432-2-matthew.auld@intel.com
If we need to make room for some mappable object, then we should
only victimize objects that have one or pages that occupy the visible
portion of LMEM. Let's also create a new priority hint for objects that
are placed in mappable memory, where we know that CPU access was
requested, that way we hopefully victimize these last.
v2(Thomas): s/TTM_PL_PRIV/I915_PL_LMEM0/
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220228123607.580432-1-matthew.auld@intel.com
This patch updates the format of memory node in DT adding the
device_type.
Signed-off-by: Sam Shih <sam.shih@mediatek.com>
Link: https://lore.kernel.org/r/20220119123537.9968-3-sam.shih@mediatek.com
[mb: fixed commit message]
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
This patch updates the format of memory node in DT adding the correct
device_type.
Signed-off-by: Sam Shih <sam.shih@mediatek.com>
Link: https://lore.kernel.org/r/20220119123537.9968-2-sam.shih@mediatek.com
[mb: fixed commit message]
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Roopa Prabhu says:
====================
vxlan metadata device vnifiltering support
This series adds vnifiltering support to vxlan collect metadata device.
Motivation:
You can only use a single vxlan collect metadata device for a given
vxlan udp port in the system today. The vxlan collect metadata device
terminates all received vxlan packets. As shown in the below diagram,
there are use-cases where you need to support multiple such vxlan devices in
independent bridge domains. Each vxlan device must terminate the vni's
it is configured for.
Example usecase: In a service provider network a service provider
typically supports multiple bridge domains with overlapping vlans.
One bridge domain per customer. Vlans in each bridge domain are
mapped to globally unique vxlan ranges assigned to each customer.
This series adds vnifiltering support to collect metadata devices to
terminate only configured vnis. This is similar to vlan filtering in
bridge driver. The vni filtering capability is provided by a new flag on
collect metadata device.
In the below pic:
- customer1 is mapped to br1 bridge domain
- customer2 is mapped to br2 bridge domain
- customer1 vlan 10-11 is mapped to vni 1001-1002
- customer2 vlan 10-11 is mapped to vni 2001-2002
- br1 and br2 are vlan filtering bridges
- vxlan1 and vxlan2 are collect metadata devices with
vnifiltering enabled
┌──────────────────────────────────────────────────────────────────┐
│ switch │
│ │
│ ┌───────────┐ ┌───────────┐ │
│ │ │ │ │ │
│ │ br1 │ │ br2 │ │
│ └┬─────────┬┘ └──┬───────┬┘ │
│ vlans│ │ vlans │ │ │
│ 10,11│ │ 10,11│ │ │
│ │ vlanvnimap: │ vlanvnimap: │
│ │ 10-1001,11-1002 │ 10-2001,11-2002 │
│ │ │ │ │ │
│ ┌──────┴┐ ┌──┴─────────┐ ┌───┴────┐ │ │
│ │ swp1 │ │vxlan1 │ │ swp2 │ ┌┴─────────────┐ │
│ │ │ │ vnifilter:│ │ │ │vxlan2 │ │
│ └───┬───┘ │ 1001,1002│ └───┬────┘ │ vnifilter: │ │
│ │ └────────────┘ │ │ 2001,2002 │ │
│ │ │ └──────────────┘ │
│ │ │ │
└───────┼──────────────────────────────────┼───────────────────────┘
│ │
│ │
┌─────┴───────┐ │
│ customer1 │ ┌─────┴──────┐
│ host/VM │ │customer2 │
└─────────────┘ │ host/VM │
└────────────┘
v2:
- remove stale xstats declarations pointed out by Nikolay Aleksandrov
- squash selinux patch with the tunnel api patch as pointed out by
benjamin poirier
- Fix various build issues:
Reported-by: kernel test robot <lkp@intel.com>
v3:
- incorporate review feedback from Jakub
- move rhashtable declarations to c file
- define and use netlink policy for top level vxlan filter api
- fix unused stats function warning
- pass vninode from vnifilter lookup into stats count function
to avoid another lookup (only applicable to vxlan_rcv)
- fix missing vxlan vni delete notifications in vnifilter uninit
function
- misc cleanups
- remote dev check for multicast groups added via vnifiltering api
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Add support for VXLAN vni filter entries' stats dumping
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add per-vni statistics for vni filter mode. Counting Rx/Tx
bytes/packets/drops/errors at the appropriate places.
This patch changes vxlan_vs_find_vni to also return the
vxlan_vni_node in cases where the vni belongs to a vni
filtering vxlan device
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: Roopa Prabhu <roopa@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch adds a new test script test_vxlan_vnifiltering.sh
with tests for vni filtering api, various datapath tests.
Also has a test with a mix of traditional, metadata and vni
filtering devices inuse at the same time.
Signed-off-by: Roopa Prabhu <roopa@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch adds vnifiltering support to collect metadata device.
Motivation:
You can only use a single vxlan collect metadata device for a given
vxlan udp port in the system today. The vxlan collect metadata device
terminates all received vxlan packets. As shown in the below diagram,
there are use-cases where you need to support multiple such vxlan devices in
independent bridge domains. Each vxlan device must terminate the vni's
it is configured for.
Example usecase: In a service provider network a service provider
typically supports multiple bridge domains with overlapping vlans.
One bridge domain per customer. Vlans in each bridge domain are
mapped to globally unique vxlan ranges assigned to each customer.
vnifiltering support in collect metadata devices terminates only configured
vnis. This is similar to vlan filtering in bridge driver. The vni filtering
capability is provided by a new flag on collect metadata device.
In the below pic:
- customer1 is mapped to br1 bridge domain
- customer2 is mapped to br2 bridge domain
- customer1 vlan 10-11 is mapped to vni 1001-1002
- customer2 vlan 10-11 is mapped to vni 2001-2002
- br1 and br2 are vlan filtering bridges
- vxlan1 and vxlan2 are collect metadata devices with
vnifiltering enabled
┌──────────────────────────────────────────────────────────────────┐
│ switch │
│ │
│ ┌───────────┐ ┌───────────┐ │
│ │ │ │ │ │
│ │ br1 │ │ br2 │ │
│ └┬─────────┬┘ └──┬───────┬┘ │
│ vlans│ │ vlans │ │ │
│ 10,11│ │ 10,11│ │ │
│ │ vlanvnimap: │ vlanvnimap: │
│ │ 10-1001,11-1002 │ 10-2001,11-2002 │
│ │ │ │ │ │
│ ┌──────┴┐ ┌──┴─────────┐ ┌───┴────┐ │ │
│ │ swp1 │ │vxlan1 │ │ swp2 │ ┌┴─────────────┐ │
│ │ │ │ vnifilter:│ │ │ │vxlan2 │ │
│ └───┬───┘ │ 1001,1002│ └───┬────┘ │ vnifilter: │ │
│ │ └────────────┘ │ │ 2001,2002 │ │
│ │ │ └──────────────┘ │
│ │ │ │
└───────┼──────────────────────────────────┼───────────────────────┘
│ │
│ │
┌─────┴───────┐ │
│ customer1 │ ┌─────┴──────┐
│ host/VM │ │customer2 │
└─────────────┘ │ host/VM │
└────────────┘
With this implementation, vxlan dst metadata device can
be associated with range of vnis.
struct vxlan_vni_node is introduced to represent
a configured vni. We start with vni and its
associated remote_ip in this structure. This
structure can be extended to bring in other
per vni attributes if there are usecases for it.
A vni inherits an attribute from the base vxlan device
if there is no per vni attributes defined.
struct vxlan_dev gets a new rhashtable for
vnis called vxlan_vni_group. vxlan_vnifilter.c
implements the necessary netlink api, notifications
and helper functions to process and manage lifecycle
of vxlan_vni_node.
This patch also adds new helper functions in vxlan_multicast.c
to handle per vni remote_ip multicast groups which are part
of vxlan_vni_group.
Fix build problems:
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Roopa Prabhu <roopa@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch adds new rtm tunnel msg and api for tunnel id
filtering in dst_metadata devices. First dst_metadata
device to use the api is vxlan driver with AF_BRIDGE
family.
This and later changes add ability in vxlan driver to do
tunnel id filtering (or vni filtering) on dst_metadata
devices. This is similar to vlan api in the vlan filtering bridge.
this patch includes selinux nlmsg_route_perms support for RTM_*TUNNEL
api from Benjamin Poirier.
Signed-off-by: Roopa Prabhu <roopa@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch changes multicast helpers to take rip and ifindex as input.
This is needed in future patches where rip can come from a pervni
structure while the ifindex can come from the vxlan device.
Signed-off-by: Roopa Prabhu <roopa@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch moves some fdb helpers to non-static
for use in later patches. Ideally, all fdb code
could move into its own file vxlan_fdb.c.
This can be done as a subsequent patch and is out
of scope of this series.
Signed-off-by: Roopa Prabhu <roopa@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch moves common structures and global declarations
to a shared private headerfile vxlan_private.h. Subsequent
patches use this header file as a common header file for
additional shared declarations.
Signed-off-by: Roopa Prabhu <roopa@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix the below build warnings reported by kernel test robot:
- initialize vni in vxlan_xmit_one
- wrap label in ipv6 enabled checks in vxlan_xmit_one
warnings:
static
drivers/net/vxlan/vxlan_core.c:2437:14: warning: variable 'label' set
but not used [-Wunused-but-set-variable]
__be32 vni, label;
^
>> drivers/net/vxlan/vxlan_core.c:2483:7: warning: variable 'vni' is
used uninitialized whenever 'if' condition is true
[-Wsometimes-uninitialized]
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Roopa Prabhu <roopa@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
vxlan.c has grown too long. This patch moves
it to its own directory. subsequent patches add new
functionality in new files.
Signed-off-by: Roopa Prabhu <roopa@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Tony Nguyen says:
====================
Intel Wired LAN Driver Updates 2022-02-28
This series contains updates to igc and e1000e drivers.
Corinna Vinschen ensures release of hardware sempahore on failed
register read in igc_read_phy_reg_gpy().
Sasha does the same for the write variant, igc_write_phy_reg_gpy(). On
e1000e, he resolves an issue with hardware unit hang on s0ix exit
by disabling some bits and LAN connected device reset during power
management flows. Lastly, he allows for TGP platforms to correct its
NVM checksum.
v2: Fix Fixes tag on patch 3
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
This enables basic bootup support for the Airoha EN7523 SoC.
Signed-off-by: John Crispin <john@phrozen.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Link: https://lore.kernel.org/r/20220130145116.88406-5-nbd@nbd.name
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Airoha's GPIO controller on their ARM EN7523 SoCs consists of two banks of 32
GPIOs
Signed-off-by: John Crispin <john@phrozen.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Link: https://lore.kernel.org/r/20220130145116.88406-14-nbd@nbd.name
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
When "dump_apple_properties" is used on the kernel boot command line,
it causes an Unknown parameter message and the string is added to init's
argument strings:
Unknown kernel command line parameters "dump_apple_properties
BOOT_IMAGE=/boot/bzImage-517rc6 efivar_ssdt=newcpu_ssdt", will be
passed to user space.
Run /sbin/init as init process
with arguments:
/sbin/init
dump_apple_properties
with environment:
HOME=/
TERM=linux
BOOT_IMAGE=/boot/bzImage-517rc6
efivar_ssdt=newcpu_ssdt
Similarly when "efivar_ssdt=somestring" is used, it is added to the
Unknown parameter message and to init's environment strings, polluting
them (see examples above).
Change the return value of the __setup functions to 1 to indicate
that the __setup options have been handled.
Fixes: 58c5475aba ("x86/efi: Retrieve and assign Apple device properties")
Fixes: 475fb4e8b2 ("efi / ACPI: load SSTDs from EFI variables")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: Igor Zhbanov <i.zhbanov@omprussia.ru>
Link: lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0defe3@omprussia.ru
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-efi@vger.kernel.org
Cc: Lukas Wunner <lukas@wunner.de>
Cc: Octavian Purdila <octavian.purdila@intel.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Link: https://lore.kernel.org/r/20220301041851.12459-1-rdunlap@infradead.org
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
EN7523 is an armv8 based silicon used inside broadband access type devices
such as xPON and xDSL. It shares various silicon blocks with MediaTek
silicon such as the MT7622.
Add basic support for Airoha EN7523, enough for booting to console.
The UART is basically 8250-compatible, except for the clock selection.
A clock-frequency value is synthesized to get this to run at 115200 bps.
Signed-off-by: John Crispin <john@phrozen.org>
Signed-off-by: Bert Vermeulen <bert@biot.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Link: https://lore.kernel.org/r/20220130145116.88406-4-nbd@nbd.name
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
This adds dt-binding documentation of pwrap for Mediatek MT8186
SoCs Platform.
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Johnson Wang <johnson.wang@mediatek.com>
Link: https://lore.kernel.org/r/20220207083034.15327-3-johnson.wang@mediatek.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
MT8186 are highly integrated SoC and use PMIC_MT6366 for
power management. This patch adds pwrap master driver to
access PMIC_MT6366.
Acked-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Johnson Wang <johnson.wang@mediatek.com>
Link: https://lore.kernel.org/r/20220207083034.15327-2-johnson.wang@mediatek.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Add power domains controller node for SoC mt8192
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
Signed-off-by: Chun-Jie Chen <chun-jie.chen@mediatek.com>
Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Link: https://lore.kernel.org/r/20210825010426.30303-1-chun-jie.chen@mediatek.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
In commit d687e056a1 ("soc: mediatek: mmsys: Add mt8192 mmsys routing table"),
the mmsys routing table for mt8192 was introduced but the input selector
for DITHER->DSI0 has no value assigned to it.
This means that we are clearing bit 0 instead of setting it, blocking
communication between these two blocks; due to that, any display that
is connected to DSI0 will not work, as no data will go through.
The effect of that issue is that, during bootup, the DRM will block for
some time, while atomically waiting for a vblank that never happens;
later, the situation doesn't get better, leaving the display in a
non-functional state.
To fix this issue, fix the route entry in the table by assigning the
dither input selector to MT8192_DISP_DSI0_SEL_IN.
Fixes: d687e056a1 ("soc: mediatek: mmsys: Add mt8192 mmsys routing table")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Link: https://lore.kernel.org/r/20220128142056.359900-1-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Because there is no way to detect if the touchscreen has pen support,
the driver is allocating and registering the input_pen input_dev on
receiving the first pen event.
But this means that the input_dev gets allocated after the request_irq()
call which means that the devm framework will free it before disabling
the irq, leaving a window where the irq handler may run and reference the
free-ed input_dev.
To fix this move the allocation of the input_pen input_dev to before
the request_irq() call, while still only registering it on the first pen
event so that the driver does not advertise pen capability on touchscreens
without it (most goodix touchscreens do not have pen support).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220131143539.109142-4-hdegoede@redhat.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Use the new input_copy_abs() helper and move the 2 input_abs_set_res()
calls up to be directly after the 2 input_copy_abs() calls, so that
the calls initializing the X and Y axis are all together.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220131143539.109142-3-hdegoede@redhat.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Add a new helper function to copy absinfo from one input_dev to
another input_dev.
This is useful to e.g. setup a pen/stylus input-device for combined
touchscreen/pen hardware where the pen uses the same coordinates as
the touchscreen.
Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220131143539.109142-2-hdegoede@redhat.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The input core's error handling for input_alloc_absinfo() failures
is based on ignoring the error until input_register_device() runs
and then checks for the failure like this:
if (test_bit(EV_ABS, dev->evbit) && !dev->absinfo) {
dev_err(&dev->dev, ...);
return -EINVAL;
}
This relies on EV_ABS actually getting set in dev->evbit even
if input_alloc_absinfo() fails, change input_set_abs_params() and
input_set_capability() to actually adhere to this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220131143539.109142-1-hdegoede@redhat.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
MT8192 contains an experimental Accelerator Coherency Port
implementation, which does not work correctly but was unintentionally
enabled by default. For correct operation of the GPU, we must set a
chicken bit disabling ACP on MT8192.
Adapted from the following downstream change to the out-of-tree, legacy
Mali GPU driver:
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2781271/5
Note this change is required for both Panfrost and the legacy kernel
driver.
Co-developed-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Cc: Nick Fan <Nick.Fan@mediatek.com>
Cc: Nicolas Boichat <drinkcat@chromium.org>
Cc: Chen-Yu Tsai <wenst@chromium.org>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20220215184651.12168-1-alyssa.rosenzweig@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
ACPI/x86 devices with a Cherry Trail SoC should have a GpioInt + a regular
GPIO ACPI resource in their ACPI tables.
Some CHT devices have a bug, where the also is bogus interrupt resource
(likely copied from a previous Bay Trail based generation of the device).
The i2c-core-acpi code will assign the bogus, non-working, interrupt
resource to client->irq. Add a workaround to fix this up.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=2043960
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220228111613.363336-1-hdegoede@redhat.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
