commit edf408b946 ("PCI: dwc: Validate iATU outbound mappings against
hardware constraints") exposes an issue with the existing partitioning of
the aperture space where the Prefetchable apertures of controllers
C5, C7 and C9 in Tegra234 cross the 32GB boundary hardware constraint.
This patch makes sure that the Prefetchable region doesn't spill over
the 32GB boundary.
Fixes: ec142c44b0 ("arm64: tegra: Add P2U and PCIe controller nodes to Tegra234 DT")
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add a device tree node for NVDEC on Tegra234.
Booting the firmware requires some information regarding offsets
within the firmware binary. These are passed through the device
tree, but since the values vary depending on the firmware version,
and the firmware itself is not available to the OS, the flasher is
expected to provide a device tree overlay with values corresponding
to the firmware it is flashing. The overlay then replaces the
placeholder values here.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The currently specified 'ranges' properties don't actually include
all devices under the host1x bus on Tegra194 and Tegra234. Expand
them appropriately.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add the memory clients on Tegra234 which are needed for initialising the
SMMU for the Deep Learning Accelerator (DLA).
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Use DEFINE_SHOW_ATTRIBUTE helper macro to simplify the code. No
functional change.
Signed-off-by: Liu Shixin <liushixin2@huawei.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Use DEFINE_SHOW_ATTRIBUTE helper macro to simplify the code. No
functional change.
Signed-off-by: Liu Shixin <liushixin2@huawei.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Use DEFINE_SHOW_ATTRIBUTE helper macro to simplify the code. No
functional change.
Signed-off-by: Liu Shixin <liushixin2@huawei.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Use DEFINE_SHOW_ATTRIBUTE helper macro to simplify the code. No
functional change.
Signed-off-by: Liu Shixin <liushixin2@huawei.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Convert the Tegra XUSB controller bindings from the free-form text
format to json-schema.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Convert the Tegra PWFM bindings from the free-form text format to
json-schema.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Tegra194 has two separate instances of the pin controller, one called
AON (in the always-on domain) and another called "main". Instead of
treating them as a single pin controller, split them up into two
separate controllers. Doing so allows the mapping between the pinmux and
GPIO controllers to be trivial identity mappings and more cleanly
separates the AON from the main IP blocks.
Note that while this changes the DT node in an incompatible way, this
doesn't have any practical implications for backwards-compatibility. The
reason for this is that device trees have only reconfigured a very
narrow subset of pins of the main controller, so the new driver will
remain backwards-compatible with old device trees.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Convert the NVIDIA Tegra pinmux controller bindings from the free-form
text format to json-schema.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add support for ECAM aperture that is only supported for Tegra234
devices.
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Co-developed-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add compatible for nvidia,tegra234-pwm with nvidia,tegra194-pwm as a
fallback. The PWM controller blocks are identical to the ones found on
the Tegra194 SoC. No driver changes are required and compatible string
"nvidia,tegra194-pwm" will be used as a fallback.
Signed-off-by: Sandipan Patra <spatra@nvidia.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Update NVDEC bindings for Tegra234. This new engine version only has
two memory clients, but now requires three clocks, and as a bigger
change the engine loads firmware from a secure carveout configured by
the bootloader.
For the latter, we need to add a phandle to the memory controller
to query the location of this carveout, and several other properties
containing offsets into the firmware inside the carveout. This
carveout is not accessible by the CPU, but is needed by NVDEC,
so we need this information to be relayed from the bootloader.
As the binding was getting large with many conditional properties,
also split the Tegra234 version out into a separate file.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Update the device-tree clock, memory, power and reset headers for
Tegra234 by adding the definitions for all the various devices.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add a basic support for the Sony Xperia M5 (codename "Holly")
smartphone, powered by a MediaTek Helio X10 SoC.
This achieves a console boot.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20221027095504.37432-7-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Add the mmc nodes to support all of the four controllers, used for
eMMC, SD/MicroSD and SDIO storage.
All of these controller nodes are left disabled by default, as
usage is board dependent.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20221027095504.37432-5-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
This SoC has a DMA controller with tx/rx channels for all of the
UART controller IPs: add the apdma node and wire up the DMAs on
all controllers.
When one of the UART controllers is used as a serial console,
the DMA will be automatically ignored.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20221027095504.37432-4-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
The UART nodes had a dummy clock for early bringup, as it is
expected that these are left on by the bootloader: now that
the pericfg clock controller is supported, we can replace
them with the real clocks.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20221027095504.37432-3-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Add nodes for topckgen, infracfg and pericfg, providing various
clocks and resets and needed to support basic IPs of this SoC.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20221027095504.37432-2-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
In cherry projects, we use edptx as the internal display interface
and use dptx as the external display interface. To support this, we
need to add more properties.
- Add pinctrls for edptx and dptx.
- Add ports for edptx and dptx.
The port connections for the internal and external display:
dp-intf0 -> edptx -> panel
dp-intf1 -> dptx
The edptx endpoint is kept empty for now, as the panel addition will
come in a later commit.
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20221110063716.25677-5-rex-bc.chen@mediatek.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Dp-intfs provide the pixel data to edptx and dptx. To support edptx
and dptx, we need to add dp-intf0 and dp-intf1 ports.
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20221110063716.25677-4-rex-bc.chen@mediatek.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
In MT8195, we use edptx as the internal display interface and use
dptx as the external display interface. Therefore, we need to add
these nodes to support the internal display and the external display.
- Add dp calibration data in the efuse node.
- Add edptx and dptx nodes for MT8195.
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20221110063716.25677-3-rex-bc.chen@mediatek.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Dp-intfs provide the pixel data to edptx and dptx. To support edptx
and dptx, we need to add dp-intf0 and dp-intf1 nodes.
Dp-intf0 is for edptx and dp-intf1 is for dptx.
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20221110063716.25677-2-rex-bc.chen@mediatek.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Update its unit name to oscillator-26m and remove the unneeded unit
address to fix a unit_address_vs_reg warning.
Fixes: 464c510f60 ("arm64: dts: mediatek: add mt6797 support")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20221013152212.416661-9-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Update the names to regulator-usb-p{0-3}-vbus to fix unit_address_vs_reg
warnings for those.
Fixes: 1724f4cc51 ("arm64: dts: Add USB3 related nodes for MT2712")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20221013152212.416661-7-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Update the names to regulator-vproc-buck{0,1} to fix unit_addres_vs_reg
warnings for those.
Fixes: f75dd8bdd3 ("arm64: dts: mediatek: add mt2712 cpufreq related device nodes")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20221013152212.416661-6-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
The unit address for the pinctrl node is (0x)1000b000 and not
(0x)10005000, which is the syscfg_pctl_a address instead.
This fixes the following warning:
arch/arm64/boot/dts/mediatek/mt2712e.dtsi:264.40-267.4: Warning
(unique_unit_address): /syscfg_pctl_a@10005000: duplicate
unit-address (also used in node /pinctrl@10005000)
Fixes: f0c64340b7 ("arm64: dts: mt2712: add pintcrl device node.")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20221013152212.416661-5-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Rename the fixed-clock oscillators to remove the unit address.
This solves unit_address_vs_reg warnings.
Fixes: 5d4839709c ("arm64: dts: mt2712: Add clock controller device nodes")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20221013152212.416661-4-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Rename fixed-clock oscillators to oscillator-26m and oscillator-32k
and remove the unit address to fix the unit_address_vs_reg warning;
fix the unit address for interrupt and intpol controllers by
removing a leading zero in their unit address.
This commit fixes the following warnings:
(unit_address_vs_reg): /oscillator@0: node has a unit name, but
no reg or ranges property
(unit_address_vs_reg): /oscillator@1: node has a unit name, but
no reg or ranges property
(simple_bus_reg): /soc/interrupt-controller@0c000000: simple-bus
unit address format error, expected "c000000"
(simple_bus_reg): /soc/intpol-controller@0c53a650: simple-bus
unit address format error, expected "c53a650"
Fixes: 4c7a626077 ("arm64: dts: add dts nodes for MT6779")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20221013152212.416661-3-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Rename the oscillator fixed-clock to oscillator-40m and remove
the unit address to fix warnings.
arch/arm64/boot/dts/mediatek/mt7986a.dtsi:17.23-22.4: Warning
(unit_address_vs_reg): /oscillator@0: node has a unit name,
but no reg or ranges property
Fixes: 1f9986b258 ("arm64: dts: mediatek: add clock support for mt7986a")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20221013152212.416661-2-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
The capacity-dmips-mhz parameter was miscalculated: this SoC runs
the first (Cortex-A55) cluster at a maximum of 2000MHz and the
second (Cortex-A78) cluster at a maximum of 3000MHz.
In order to calculate the right capacity-dmips-mhz, the following
test was performed:
1. CPUFREQ governor was set to 'performance' on both clusters
2. Ran dhrystone with 500000000 iterations for 10 times on each cluster
3. Calculate the mean result for each cluster
4. Calculate DMIPS/MHz: dmips_mhz = dmips_per_second / cpu_mhz
5. Scale results to 1024:
result_c0 = (dmips_mhz_c0 - min_dmips_mhz(c0, c1)) /
(max_dmips_mhz(c0, c1) - min_dmips_mhz(c0, c1)) * 1024
The mean results for this SoC are:
Cluster 0 (LITTLE): 11990400 Dhry/s
Cluster 1 (BIG): 59809036 Dhry/s
The calculated scaled results are:
Cluster 0: 307,934312801831 (rounded to 308)
Cluster 1: 1024
Fixes: 37f2582883 ("arm64: dts: Add mediatek SoC mt8195 and evaluation board")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20221005093404.33102-1-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Conform to the rest of Hyper-V emulation selftests which have 'hyperv'
prefix. Get rid of '_test' suffix as well as the purpose of this code
is fairly obvious.
Reviewed-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20221101145426.251680-49-vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Enable Hyper-V L2 TLB flush and check that Hyper-V TLB flush hypercalls
from L2 don't exit to L1 unless 'TlbLockCount' is set in the Partition
assist page.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20221101145426.251680-48-vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Enable Hyper-V L2 TLB flush and check that Hyper-V TLB flush hypercalls
from L2 don't exit to L1 unless 'TlbLockCount' is set in the
Partition assist page.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20221101145426.251680-47-vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Hyper-V MSR-Bitmap tests do RDMSR from L2 to exit to L1. While 'evmcs_test'
correctly clobbers all GPRs (which are not preserved), 'hyperv_svm_test'
does not. Introduce a more generic rdmsr_from_l2() to avoid code
duplication and remove hardcoding of MSRs. Do not put it in common code
because it is really just a selftests bug rather than a processor
feature that requires it.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20221101145426.251680-46-vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
vmmcall()/vmcall() are used to exit from L2 to L1 and no concrete hypercall
ABI is currenty followed. With the introduction of Hyper-V L2 TLB flush
it becomes (theoretically) possible that L0 will take responsibility for
handling the call and no L1 exit will happen. Prevent this by stuffing RAX
(KVM ABI) and RCX (Hyper-V ABI) with 'safe' values.
While on it, convert vmmcall() to 'static inline', make it setup stack
frame and move to include/x86_64/svm_util.h.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20221101145426.251680-45-vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
There's no need to pollute VMX and SVM code with Hyper-V specific
stuff and allocate Hyper-V specific test pages for all test as only
few really need them. Create a dedicated struct and an allocation
helper.
Reviewed-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20221101145426.251680-43-vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
In preparation to putting Hyper-V specific test pages to a dedicated
struct, move eVMCS load logic from load_vmcs(). Tests call load_vmcs()
directly and the only one which needs 'enlightened' version is
evmcs_test so there's not much gain in having this merged.
Temporary pass both GPA and HVA to load_evmcs().
Reviewed-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20221101145426.251680-42-vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Hyper-V VP assist page is not eVMCS specific, it is also used for
enlightened nSVM. Move the code to vendor neutral place.
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20221101145426.251680-41-vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
'struct hv_vp_assist_page' definition doesn't match TLFS. Also, define
'struct hv_nested_enlightenments_control' and use it instead of opaque
'__u64'.
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20221101145426.251680-40-vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
'struct hv_enlightened_vmcs' definition in selftests is not '__packed'
and so we rely on the compiler doing the right padding. This is not
obvious so it seems beneficial to use the same definition as in kernel.
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20221101145426.251680-39-vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Introduce a selftest for Hyper-V PV TLB flush hypercalls
(HvFlushVirtualAddressSpace/HvFlushVirtualAddressSpaceEx,
HvFlushVirtualAddressList/HvFlushVirtualAddressListEx).
The test creates one 'sender' vCPU and two 'worker' vCPU which do busy
loop reading from a certain GVA checking the observed value. Sender
vCPU swaos the data page with another page filled with a different value.
The expectation for workers is also altered. Without TLB flush on worker
vCPUs, they may continue to observe old value. To guard against accidental
TLB flushes for worker vCPUs the test is repeated 100 times.
Hyper-V TLB flush hypercalls are tested in both 'normal' and 'XMM
fast' modes.
Reviewed-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20221101145426.251680-38-vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
netdev.vger.kernel.org archive mirror
Steen Hegelund says:
====================
net: Add support for VCAP debugFS in Sparx5
This provides support for getting VCAP instance, VCAP rule and VCAP port
keyset configuration information via the debug file system.
It builds on top of the initial IS2 VCAP support found in these series:
https://lore.kernel.org/all/20221020130904.1215072-1-steen.hegelund@microchip.com/https://lore.kernel.org/all/20221109114116.3612477-1-steen.hegelund@microchip.com/https://lore.kernel.org/all/20221111130519.1459549-1-steen.hegelund@microchip.com/
Functionality:
==============
The VCAP API exposes a /sys/kernel/debug/sparx5/vcaps folder containing
the following entries:
- raw_<vcap>_<instance>
This is a raw dump of the VCAP instance with a line for each available
VCAP rule. This information is limited to the VCAP rule address, the
rule size and the rule keyset name as this requires very little
information from the VCAP cache.
This can be used to detect if a valid rule is stored at the correct
address.
- <vcap>_<instance>
This dumps the VCAP instance configuration: address ranges, chain id
ranges, word size of keys and actions etc, and for each VCAP rule the
details of keys (values and masks) and actions are shown.
This is useful when discovering if the expected rule is present and in
which order it will be matched.
- <interface>
This shows the keyset configuration per lookup and traffic type and the
set of sticky bits (common for all interfaces). This is cleared when
shown, so it is possible to sample over a period of time.
It also shows if this port/lookup is enabled for matching in the VCAP.
This can be used to find out which keyset the traffic being sent to a
port, will be matched against, and if such traffic has been seen by one
of the ports.
Delivery:
=========
This is current plan for delivering the full VCAP feature set of Sparx5:
- TC protocol all support for IS2 VCAP
- Sparx5 IS0 VCAP support
- TC policer and drop action support (depends on the Sparx5 QoS support
upstreamed separately)
- Sparx5 ES0 VCAP support
- TC flower template support
- TC matchall filter support for mirroring and policing ports
- TC flower filter mirror action support
- Sparx5 ES2 VCAP support
Version History:
================
v2 Removed a 'support' folder (used for integration testing) that had
been added in patch 6/8 by a mistake.
Wrapped long lines.
v1 Initial version
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
