This patch defines a new header file for all the DSC 1.2 structures
and creates a structure for PPS infoframe which will be used to send
picture parameter set secondary data packet for display stream compression.
All the PPS infoframe syntax elements are taken from DSC 1.2 specification
from VESA.
v4:
* Remove redundant blankline in doc (Ville)
* use drm_dsc namespace for all structs (Ville)
* Use packed struct (Ville)
v3:
* Add the SPDX shorthand (Chris Wilson)
v2:
* Do not use bitfields in the struct (Jani Nikula)
Cc: Gaurav K Singh <gaurav.k.singh@intel.com>
Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Acked-by: Sean Paul <seanpaul@chromium.org> (For merging through
drm-intel)
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181127214125.17658-2-manasi.d.navare@intel.com
There are spelling mistakes in debug messages, fix them.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
DSC DPCD color depth register advertises its color depth capabilities
by setting each of the bits that corresponding to a specific color
depth. This patch defines those specific color depths and adds
a helper to return an array of color depth capabilities.
v2:
* Simplify the logic (Ville)
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Acked-by: Sean Paul <seanpaul@chromium.org> (For merging through
drm-intel)
Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181127214125.17658-1-manasi.d.navare@intel.com
Ido Schimmel says:
====================
mlxsw: Prepare for VLAN-aware bridge w/VxLAN
The driver is using 802.1Q filtering identifiers (FIDs) to represent the
different VLANs in the VLAN-aware bridge (only one is supported).
However, the device cannot assign a VNI to such FIDs, which prevents the
driver from supporting the enslavement of VxLAN devices to the
VLAN-aware bridge.
This patchset works around this limitation by emulating 802.1Q FIDs
using 802.1D FIDs, which can be assigned a VNI and so far have only been
used in conjunction with VLAN-unaware bridges.
The downside of this approach is that multiple {Port,VID}->FID entries
are required, whereas a single VID->FID entry is required with "true"
802.1Q FIDs.
First four patches introduce the new FID family of emulated 802.1Q FIDs
and the associated type of router interfaces (RIFs). Last patch flips
the driver to use this new FID family.
The diff is relatively small because the internal implementation of each
FID family is contained and hidden in spectrum_fid.c. Different internal
users (e.g., bridge, router) are aware of the different FID types, but
do not care about their internal implementation. This makes it trivial
to swap the current implementation of 802.1Q FIDs with the new one,
using 802.1D FIDs.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Replace 802.1Q FIDs and VLAN RIFs with their emulated counterparts.
The emulated 802.1Q FIDs are actually 802.1D FIDs and thus use the same
flood tables, of per-FID type. Therefore, add 4K-1 entries to the
per-FID flood tables for the new FIDs and get rid of the FID-offset
flood tables that were used by the old 802.1Q FIDs.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Router interfaces (RIFs) constructed on top of VLAN-aware bridges are of
"VLAN" type, whereas RIFs constructed on top of VLAN-unaware bridges of
"FID" type.
In other words, the RIF type is derived from the underlying FID type.
VLAN RIFs are used on top of 802.1Q FIDs, whereas FID RIFs are used on
top of 802.1D FIDs.
Since the previous patch emulated 802.1Q FIDs using 802.1D FIDs, this
patch emulates VLAN RIFs using FID RIFs.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The driver uses 802.1Q FIDs when offloading a VLAN-aware bridge.
Unfortunately, it is not possible to assign a VNI to such FIDs, which
prompts the driver to forbid the enslavement of VxLAN devices to a
VLAN-aware bridge.
Workaround this hardware limitation by creating a new family of FIDs,
emulated 802.1Q FIDs. These FIDs are emulated using 802.1D FIDs, which
can be assigned a VNI.
The downside of this approach is that multiple {Port, VID}->FID entries
are required, whereas only a single VID->FID is required with "true"
802.1Q FIDs.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
802.1D FIDs use a per-FID flood table, where the flood index into the
table is calculated by subtracting 4K from the FID's index.
Currently, 802.1D FIDs start at 4K, so the calculation is correct, but
if it was ever to change, the calculation will no longer be correct.
In addition, this change will allow us to reuse the flood index
calculation function in the next patch, where we are going to emulate
802.1Q FIDs using 802.1D FIDs.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When configuring an FDB entry pointing to a LAG netdev (or its upper),
the driver should only set the 'lag_vid' field when the FID (filtering
identifier) is of 802.1D type.
Extend the 802.1D FID family with an attribute indicating whether this
field should be set and based on its value set the field or leave it
blank.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
firmware and VCHI driver to coordinate on using the correct cache line
size for the platform.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAlv9sgoACgkQtdYpNtH8
nuiXWhAArqokJBWAt2j3PzOD43i2WG1cJoPvrerUdk962fvzX3HlIOgptvWAWQ1f
drbfU+5TC8W5f6WVJaA4Xp2hHI778AyI2ij8TB4s5HJRUL+t6Znx53tkUuISswVp
/duV8wKZbdyg6iQv3ylv0wAvvVOh2927m6+CoU4Gf0IDr2Y4d/2riD8AbCB42pv5
LNOafJaYNJhPt2pkGgZ/8xvmBMXbJwP4F+GkyoqSW+02L/mua9JcZWoss+BNTIzb
6Qw46Rhp/bWzVjZaDJw1BzX8XLAL39xSJytUkTdQe9rVR/Nj8BiCNNEvwfi6Sbrx
mZl6mEYzv9coDffeoe1lK1qElcBIc98RzmGaEMduX4XKEnSkG7sPjkNqA5ghG8i4
QOH+sQo9WZAcZrD1oe1tp6Oc8RsSABvpKpuhGr2n5nyYqZ8wZwyM2nn9wcfpVWZU
MqcCag3wvf4LFVaSy/qFaV5f43/fp+Dw75Hx1UwkBP10snjWvZ6ytyRNXoniRIqS
boqGZ4kwhPxCRwFJY/di8P356WNrMQzaCuyEB0c4xfBYHzE9MUMuYn8uWUiaYuyh
Wc4/PFQzb2jO5ZIt/PuSHNFoEyQndcF6gUE9v2yyyseu/dvJqqDNSl2VyjdVbGL/
aMTfFCNcwM8wEUyFHRbI0x69FA1KRmI4Ic18agIS2OsMYoJ8NV0=
=BEZr
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAlv90pcACgkQh9CWnEQH
BwRoyQ//Wy0AjmVf3inDdvtCI4oOnUG/I1bTXQJLachpHmUId4jYIs1TsOrs4CeF
jMLj7QskySXYfPyglL2LQD03VydArKv26tQup3UHI7RgTphma5r/4q+/jX3KO0Ak
FgW0OfN6JU4PQz1yC4qOHYdvxv+36FiZFjACFS4PDLiXkdvUtipBnDYxsZi9F0Oj
Ut4q5lFumZBuc9JUGcW47N1F43ezV+D2HcyaeaQmPTxlvN7Ax3CcvWEDPEreICvr
hCGBguVB5c2qmDzyKg66TPP3kZ7vfSR2Q8oLezLVYzXPfJ+XMorIEgfaxCJbz+a8
ef6tjJiILdXARSdGenrgK+oUElVpQtBszjSwe7+ptZyKwKr3+p61J89pLQuLHSXT
u9bilEqbaNuN8iS939XCvkdl8F/T2/jNBKB0JCUDaXE7wwpHucIuIxeeCL1Dhs5J
IeYriOHyLYPsuuvr8vXe3C14Ej5fs6OXJdtYkGEYUH6VWoH4Yxa3MaqjyX6BE6oO
gwUCaJM2jkpSyEXWxu2tQ015tKlw0A0wMFKseIoe+jPGcnihC9XWfRaeOny1TgTa
J5mQL9pQntL++LCMYiXgZZU/Ff5dHBQU/yMJWfG8glS74RqJfDyrt1IBNb/199yC
6+ONHv0mtGH3ttKO8vxJUP2dlhirjvuDvDxsidgLxvnDhMmsRpQ=
=zY4r
-----END PGP SIGNATURE-----
Merge tag 'tags/bcm2835-dt-next-2018-11-27' into devicetree/next
This pull request adds a compatible string to the DT necessary for the
firmware and VCHI driver to coordinate on using the correct cache line
size for the platform.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
the firmware driver (silently hanging if the VPU doesn't respond to a
mailbox transaction, and undersized buffers in the firmware property
transactions for tags that aren't used yet in the upstream).
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAlv9sfwACgkQtdYpNtH8
nugJFxAAmcu7Z979i1tD7jiy/lgmVPsS9W2zYv/lKrZscFPVh1Mqq3UApypFHgkK
0qjtawFRAwRPzYV7RpHkVREvJsqPTygxxrSgkNEZPsP/r3ytygbZfB7KhFnoF93X
h2HH3czBTxsbajEDwG8BUW2bK8YoefaoaVB72oW6kslv3Mh4RPScf1UJHCRyVOgo
2BH9tq8dOaN+geqDX1VSVUb7r/lnUtwdykC5kxMmEBx5O272vzqBRvFMTFyABXxM
q9jEAd91PbNzX/YgjSM00ZqGmoB3MlchnHPbU2UzeTBuLMhpOc9TiD+ZWxTw0YI1
AHPIZnZ2yOpOhQcR+pF3BsAIG3lxWe0Es8QV1hZWYtOMgmVcwU8ahWGBhFO48v2l
zZIWeBP67nWWlK4mYXLFUhcDnIeM5ddcMiy1hsPdYpZn+3hM7iWBuZx4swmcKqHj
5Dsc45UpFbNgv98U3SKFznn8FsHXHBUvUJrlURBf/RVLiNH5E/chdjRLLQ7wlBV/
5gS41QgkUxz+QorFqrB3TH9HaEK1tIE/YSpz9At8XPaujWBMebssHZBVSddqNXFR
YvRIgRJ0LUBWqcMTzvNes3zUmbY9FZUXZson1UxtcsSkigrOj7nRPUMrlnA23pHE
wxBRHy7SbVEuWFrxi8GW+79OKgkwvqqU/5x/YPTxjSnoX7NM23w=
=Wn6c
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAlv90nAACgkQh9CWnEQH
BwSzIhAApvM869EXH3+SKWBNJYCPVk74eVlCsqEhPE21VHJxDo3i4S223ATkwUlP
YrEtmbY1q61bfwaImlg8NhKPkbQ2MU9OKH5HOiOcfnftpHWfltGQWfhjFEGaY0zM
aNxTMF/6JzY//VYF+nT3JL0Y3cZkBInjnr5Nm4XQAkuzUkpXnT3arYii9q4IFDId
eHyBbANmAvkU6JbupEYe05pXdfFrN5W6sSUw9oAALR1SedphkcXBhgPklIO4mhsA
E1LWswVl3PaoWlIycjjElU9I7Axb6A5ECpgZ0esbeIC7hQMbSMvXjxJorIfF6gq+
4Dvcb9PFmHg/bBrC3gIndJP0W707dyJldIWqYtcZMzbjcLMFzO4l74EoiDOcUD2E
ZCbipRLJqdA2jQ1DYcxgWfkdsomEAhqPOlMJ+OqvVXSBf36aYVNCVq+RGlUS5XMB
uv02mvbJ5BHyKLf+VdZwkAU3WeIJ7cP35ywNdqWy47u89aRF0elOK6BWAuL6HI2Y
FXrIgFxmb5QuL3JQVulpiij6iCwmSZjoOlcLDJhAGj0a6/AYcmYhn/nznZ9Y2uTM
j+8yA//FrE5CnKW506OST31CSwf28u0Q2rFeFu581AJSvSeY3LLvarh7N5PNLvM3
l89TNCfWSKxvXA1/H6/Nrc4TCPKIH3egzpFMxQMAnyk35VV9CNE=
=5L8p
-----END PGP SIGNATURE-----
Merge tag 'tags/bcm2835-drivers-next-2018-11-27' into drivers/next
This pull request adds SPDX to BCM2835 drivers, and fixes some bugs in
the firmware driver (silently hanging if the VPU doesn't respond to a
mailbox transaction, and undersized buffers in the firmware property
transactions for tags that aren't used yet in the upstream).
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c:260:7:
warning: variable 'err' set but not used [-Wunused-but-set-variable]
'err' should be returned while set MPI_DEINIT state fails
in hw_atl_utils_soft_reset.
Fixes: cce96d1883 ("net: aquantia: Regression on reset with 1.x firmware")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Nikolay Aleksandrov says:
====================
net: bridge: add an option to disabe linklocal learning
This set adds a new bridge option which can control learning from
link-local packets, by default learning is on to be consistent and avoid
breaking users expectations. If the new no_linklocal_learn option is
enabled then the bridge will stop learning from link-local packets.
In order to save space for future boolean options, patch 01 adds a new
bool option API that uses a bitmask to control boolean options. The
bridge is by far the largest netlink attr user and we keep adding simple
boolean options which waste nl attr ids and space. We're not directly
mapping these to the in-kernel bridge flags because some might require
more complex configuration changes (e.g. if we were to add the per port
vlan stats now, it'd require multiple checks before changing value).
Any new bool option needs to be handled by both br_boolopt_toggle and get
in order to be able to retrieve its state later. All such options are
automatically exported via netlink. The behaviour of setting such
options is consistent with netlink option handling when a missing
option is being set (silently ignored), e.g. when a newer iproute2 is used
on older kernel. All supported options are exported via bm's optmask
when dumping the new attribute.
v2: address Andrew Lunn's comments, squash a minor change into patch 01,
export all supported options via optmask when dumping, add patch 03,
pass down extack so options can return meaningful errors, add
WARN_ON on unsupported options (should not happen)
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Now that we have at least one bool option, we can export all of the
supported bool options via optmask when dumping them.
v2: new patch
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Use the new boolopt API to add an option which disables learning from
link-local packets. The default is kept as before and learning is
enabled. This is a simple map from a boolopt bit to a bridge private
flag that is tested before learning.
v2: pass NULL for extack via sysfs
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
We have been adding many new bridge options, a big number of which are
boolean but still take up netlink attribute ids and waste space in the skb.
Recently we discussed learning from link-local packets[1] and decided
yet another new boolean option will be needed, thus introducing this API
to save some bridge nl space.
The API supports changing the value of multiple boolean options at once
via the br_boolopt_multi struct which has an optmask (which options to
set, bit per opt) and optval (options' new values). Future boolean
options will only be added to the br_boolopt_id enum and then will have
to be handled in br_boolopt_toggle/get. The API will automatically
add the ability to change and export them via netlink, sysfs can use the
single boolopt function versions to do the same. The behaviour with
failing/succeeding is the same as with normal netlink option changing.
If an option requires mapping to internal kernel flag or needs special
configuration to be enabled then it should be handled in
br_boolopt_toggle. It should also be able to retrieve an option's current
state via br_boolopt_get.
v2: WARN_ON() on unsupported option as that shouldn't be possible and
also will help catch people who add new options without handling
them for both set and get. Pass down extack so if an option desires
it could set it on error and be more user-friendly.
[1] https://www.spinics.net/lists/netdev/msg532698.html
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
After switching the r8169 driver to use phylib some user reported that
their network is broken. This was caused by the genphy PHY driver being
used instead of the dedicated PHY driver for the RTL8211B. Users
reported that loading the Realtek PHY driver module upfront fixes the
issue. See also this mail thread:
https://marc.info/?t=154279781800003&r=1&w=2
The issue is quite weird and the root cause seems to be somewhere in
the base driver core. The patch works around the issue and may be
removed once the actual issue is fixed.
The Fixes tag refers to the first reported occurrence of the issue.
The issue itself may have been existing much longer and it may affect
users of other network chips as well. Users typically will recognize
this issue only if their PHY stops working when being used with the
genphy driver.
Fixes: f1e911d5d0 ("r8169: add basic phylib support")
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
We fail to advance the read pointer when reading the stat.oh field that
identifies the lock-holder in a TEST result.
This turns out not to matter if the server is knfsd, which always
returns a zero-length field. But other servers (Ganesha is an example)
may not do this. The result is bad values in fcntl F_GETLK results.
Fix this.
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
The idea here was that renaming a file on a nosubtreecheck export would
make lookups of the old filehandle return STALE, making it impossible
for clients to reclaim opens.
But during the grace period I think we should also hold off on
operations that would break delegations.
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Zero-length writes are legal; from 5661 section 18.32.3: "If the count
is zero, the WRITE will succeed and return a count of zero subject to
permissions checking".
This check is unnecessary and is causing zero-length reads to return
EINVAL.
Cc: stable@vger.kernel.org
Fixes: 3fd9557aec "NFSD: Refactor the generic write vector fill helper"
Cc: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
If pkg-config is available, use it to define the CFLAGS and
LDLIBS needed for libmount; else, use the current hard-coded
paths and options.
Using pkg-config is very helpful for cross-compilation
environments, and is sometimes readily available on developer
boxes to ensure we get the right compiler/linker options for
the given package.
Signed-off-by: Daniel Díaz <daniel.diaz@linaro.org>
Signed-off-by: Shuah Khan <shuah@kernel.org>
CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y is required for fw_fallback.sh.
Without it, fw_fallback.sh fails with 'usermode helper disabled so
ignoring test'. Enable the config in selftest so that it gets built by
default.
Signed-off-by: Dan Rue <dan.rue@linaro.org>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Shuah Khan <shuah@kernel.org>
"diff -Z" is used to trim the trailing whitespace when comparing the
loaded firmware file with the source firmware file. However, per the
comment in the source code, -Z should not be necessary. In testing, the
input and output files are identical.
Additionally, -Z is not a standard option and is not available in
environments such as busybox. When -Z is not supported, diff fails with
a usage error, which is suppressed, but then causes read_firmwares() to
exit with a false failure message.
Signed-off-by: Dan Rue <dan.rue@linaro.org>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Shuah Khan <shuah@kernel.org>
This is the same as the default drm_gem_dumb_map_offset()
implementation, except that this one missed the ban on userspace
mapping an imported dmabuf (which seems like intended common behavior
for drivers).
Signed-off-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20181126215929.20546-1-eric@anholt.net
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The extra to_v3d_bo() calls came from copying this from the vc4
driver, which stored the cma gem object in the structs.
v2: Fix an unused var warning
Signed-off-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108161654.19888-4-eric@anholt.net
Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com> (v1)
The last_cmd_status sequence buffer contains user-visible messages
(accessed via /sys/fs/resctrl/info/last_cmd_status) that detail any
errors encountered while interacting with the resctrl filesystem.
rdt_last_cmd_printf() and rdt_last_cmd_puts() are the two calls
available to respectively print a string with format specifiers or a
simple one (which contains no format specifiers) to the last_cmd_status
buffer.
A few occurrences exist where rdt_last_cmd_printf() is used to print
a simple string. Doing so does not result in incorrect result or
incorrect behavior, but rdt_last_cmd_puts() is the function intended to
be used in these cases, as it is faster and it doesn't need to do the
vsnprintf() formatting.
Fix these occurrences to use rdt_last_cmd_puts() instead. While doing
so, fix two typos that were recently introduced into two of these simple
strings.
[ bp: massage commit message and correct typos. ]
Fixes: 723f1a0dd8 ("x86/resctrl: Fixup the user-visible strings")
Fixes: e0bdfe8e36 ("x86/intel_rdt: Support creation/removal of pseudo-locked region")
Fixes: 9ab9aa15c3 ("x86/intel_rdt: Ensure requested schemata respects mode")
Fixes: d48d7a57f7 ("x86/intel_rdt: Introduce resource group's mode resctrl file")
Fixes: dfe9674b04 ("x86/intel_rdt: Enable entering of pseudo-locksetup mode")
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: babu.moger@amd.com
Cc: jithu.joseph@intel.com
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/f48e46a016d6a5c79f13de8faeca382052189e2e.1543346009.git.reinette.chatre@intel.com
In order to reduce the possibility of soft lock-ups, we bound the
maximum number of TLBI operations performed by a single call to
flush_tlb_range() to an arbitrary constant of 1024.
Whilst this does the job of avoiding lock-ups, we can actually be a bit
smarter by defining this as PTRS_PER_PTE. Due to the structure of our
page tables, using PTRS_PER_PTE means that an outer loop calling
flush_tlb_range() for entire table entries will end up performing just a
single TLBI operation for each entry. As an example, mremap()ing a 1GB
range mapped using 4k pages now requires only 512 TLBI operations when
moving the page tables as opposed to 262144 operations (512*512) when
using the current threshold of 1024.
Cc: Joel Fernandes <joel@joelfernandes.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Now that we have switched to the small code model entirely, and
reduced the extended KASLR range to 4 GB, we can be sure that the
targets of relative branches that are out of range are in range
for a ADRP/ADD pair, which is one instruction shorter than our
current MOVN/MOVK/MOVK sequence, and is more idiomatic and so it
is more likely to be implemented efficiently by micro-architectures.
So switch over the ordinary PLT code and the special handling of
the Cortex-A53 ADRP errata, as well as the ftrace trampline
handling.
Reviewed-by: Torsten Duwe <duwe@lst.de>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
[will: Added a couple of comments in the plt equality check]
Signed-off-by: Will Deacon <will.deacon@arm.com>
Max bitrate property is not supported for venus version 4xx.
Return unsupported from packetization layer. Handle it in
hfi_venus layer to exit gracefully to venc layer.
Signed-off-by: Malathi Gottam <mgottam@codeaurora.org>
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Acked-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Add USERPTR to queue access methods by adding this
support to io_modes on both the planes.
Signed-off-by: Malathi Gottam <mgottam@codeaurora.org>
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Acked-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Right now, it mentions two SPDX headers that don't exist inside the Kernel:
GFDL-1.1-or-later
And an exception:
no-invariant-sections
While it would be trivial to add the first one, there's no way,
currently, to distinguish, with SPDX, between a free and a non-free
document under GFDL.
Free documents with GFDL should not have invariant sections.
There's an open issue at SPDX tree waiting for it to be solved.
While we don't have this issue closed, let's just replace by a
free-text license, and add a TODO note to remind us to revisit it
later.
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
The dvb_frontend core already checks for the frequencies. No
need for any additional check inside the driver.
It is part of the fixes for the following bug:
https://bugzilla.opensuse.org/show_bug.cgi?id=1116374
Fixes: a3f90c75b8 ("media: dvb: convert tuner_info frequencies to Hz")
Reported-by: Stakanov Schufter <stakanov@eclipso.eu>
Reported-by: Takashi Iwai <tiwai@suse.de>
Cc: stable@vger.kernel.org # For 4.19
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Tuners should report frequencies in Hz. That works fine on most
drivers, but, in the case of dvb-pll, some settings are for
satellite tuners, while others are for terrestrial/cable ones.
The code was trying to solve it at probing time, but that doesn't
work, as, when _attach is called, the delivery system may be wrong.
Fix it by ensuring that all frequencies are in Hz at the per-tuner
max/min values.
While here, add a debug message, as this would help to debug any
issues there.
It partially fixes the following bug:
https://bugzilla.opensuse.org/show_bug.cgi?id=1116374
Fixes: a3f90c75b8 ("media: dvb: convert tuner_info frequencies to Hz")
Reported-by: Stakanov Schufter <stakanov@eclipso.eu>
Reported-by: Takashi Iwai <tiwai@suse.de>
Cc: stable@vger.kernel.org # For 4.19
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Add support for emitting ADR and ADRP instructions so we can switch
over our PLT generation code in a subsequent patch.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Document the asynchronous serdev_device_write_buf() and synchronous
serdev_device_write() functions using kernel-doc.
Specifically, mention that writing data only means that data has been
buffered by the controller, and that the synchronous helper depends on
serdev_device_write_wakeup() being called in the driver write_wakeup()
callback.
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Allow the synchronous serdev_device_write() helper to be interrupted.
This is useful for cases where I/O is performed on behalf of user space
and we don't want to block indefinitely when using flow control.
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Make the synchronous serdev_device_write() helper behave analogous to
the asynchronous serdev_device_write_buf() by returning the number of
bytes written (or rather buffered) also on timeout.
This will allow drivers to distinguish the case where data was partially
written from the case where no data was written.
Also update the only two users that checked the return value.
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use zero to indicate infinite timeout for the synchronous
serdev_device_write() helper.
This allows drivers to specify an infinite timeout without knowing about
serdev implementation details, while also allowing the same timeout
argument to be used for both serdev_device_write() and
serdev_device_wait_until_sent().
Note that passing zero to the current helper makes no sense; just call
the asynchronous serdev_device_write_buf() directly instead.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
__install_bp_hardening_cb() is called via stop_machine() as part
of the cpu_enable callback. To force each CPU to take its turn
when allocating slots, they take a spinlock.
With the RT patches applied, the spinlock becomes a mutex,
and we get warnings about sleeping while in stop_machine():
| [ 0.319176] CPU features: detected: RAS Extension Support
| [ 0.319950] BUG: scheduling while atomic: migration/3/36/0x00000002
| [ 0.319955] Modules linked in:
| [ 0.319958] Preemption disabled at:
| [ 0.319969] [<ffff000008181ae4>] cpu_stopper_thread+0x7c/0x108
| [ 0.319973] CPU: 3 PID: 36 Comm: migration/3 Not tainted 4.19.1-rt3-00250-g330fc2c2a880 #2
| [ 0.319975] Hardware name: linux,dummy-virt (DT)
| [ 0.319976] Call trace:
| [ 0.319981] dump_backtrace+0x0/0x148
| [ 0.319983] show_stack+0x14/0x20
| [ 0.319987] dump_stack+0x80/0xa4
| [ 0.319989] __schedule_bug+0x94/0xb0
| [ 0.319991] __schedule+0x510/0x560
| [ 0.319992] schedule+0x38/0xe8
| [ 0.319994] rt_spin_lock_slowlock_locked+0xf0/0x278
| [ 0.319996] rt_spin_lock_slowlock+0x5c/0x90
| [ 0.319998] rt_spin_lock+0x54/0x58
| [ 0.320000] enable_smccc_arch_workaround_1+0xdc/0x260
| [ 0.320001] __enable_cpu_capability+0x10/0x20
| [ 0.320003] multi_cpu_stop+0x84/0x108
| [ 0.320004] cpu_stopper_thread+0x84/0x108
| [ 0.320008] smpboot_thread_fn+0x1e8/0x2b0
| [ 0.320009] kthread+0x124/0x128
| [ 0.320010] ret_from_fork+0x10/0x18
Switch this to a raw spinlock, as we know this is only called with
IRQs masked.
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
The BAD_MADT_GICC_ENTRY check is a little too strict because
it rejects MADT entries that don't match the currently known
lengths. We should remove this restriction to avoid problems
if the table length changes. Future code which might depend on
additional fields should be written to validate those fields
before using them, rather than trying to globally check
known MADT version lengths.
Link: https://lkml.kernel.org/r/20181012192937.3819951-1-jeremy.linton@arm.com
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
[lorenzo.pieralisi@arm.com: added MADT macro comments]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Al Stone <ahs3@redhat.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Daniel Borkmann says:
====================
pull-request: bpf 2018-11-27
The following pull-request contains BPF updates for your *net* tree.
The main changes are:
1) Fix several bugs in BPF sparc JIT, that is, convergence for fused
branches, initialization of frame pointer register, and moving all
arguments into output registers from input registers in prologue
to fix BPF to BPF calls, from David.
2) Fix a bug in arm64 JIT for fetching BPF to BPF call addresses where
they are not guaranteed to fit into imm field and therefore must be
retrieved through prog aux data, from Daniel.
3) Explicitly add all JITs to MAINTAINERS file with developers able to
help out in feature development, fixes, review, etc.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
The thermal controller implementation on Tegra194 is very similar to the
implementation on Tegra186. Add a compatible string for the new
generation.
Signed-off-by: Thierry Reding <treding@nvidia.com>
