Subclassing the generic USB device driver to override the
default configuration selection regardless of matching interface
drivers.
The r815x family devices expose a vendor specific function which
the r8152 interface driver wants to handle. This is the preferred
device mode. Additionally one or more USB class functions are
usually supported for hosts lacking a vendor specific driver. The
choice is USB configuration based, with one alternate function per
configuration.
Example device with both NCM and ECM alternate cfgs:
A problem with this is that Linux will prefer class functions over
vendor specific functions. Using the above example, Linux defaults
to cfg #2, running the device in a sub-optimal NCM mode.
Previously we've attempted to work around the problem by
blacklisting the devices in the ECM class driver "cdc_ether", and
matching on the ECM class function in the vendor specific interface
driver. The latter has been used to switch back to the vendor
specific configuration when the driver is probed for a class
function.
This workaround has several issues;
- class driver blacklists is additional maintanence cruft in an
unrelated driver
- class driver blacklists prevents users from optionally running
the devices in class mode
- each device needs double match entries in the vendor driver
- the initial probing as a class function slows down device
discovery
Now these issues have become even worse with the introduction of
firmware supporting both NCM and ECM, where NCM ends up as the
default mode in Linux. To use the same workaround, we now have
to blacklist the devices in to two different class drivers and
add yet another match entry to the vendor specific driver.
This patch implements an alternative workaround strategy -
independent of the interface drivers. It avoids adding a
blacklist to the cdc_ncm driver and will let us remove the
existing blacklist from the cdc_ether driver.
As an additional bonus, removing the blacklists allow users to
select one of the other device modes if wanted.
Change-Id: I664077c6d7744029fbe1434e885577c96aa1b18f
Signed-off-by: Bjørn Mork <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(backported from commit ec51fbd1b8a2bca2948dede99c14ec63dc57ff6b)
Signed-off-by: You-Sheng Yang <email address hidden>
We have to use ovl_upper_mnt_userns(ofs) helper to get proper user namespace
for idmapped layer. Otherwise we'll get -EPERM.
Right now, overlayfs on top of idmapped layer always mounted as read-only.
This is serious blocker for LXD/LXC unprivileged containers users who run
Docker containers inside.
Reproducer:
$ cd /idmapped/mount/path
$ mkdir {work,upper,lower,ovl}
$ mount -t overlay overlay -o lowerdir=lower,upperdir=upper,workdir=work ovl
$ touch ovl/test
touch: cannot touch 'ovl/test': Read-only file system
Error from dmesg:
overlayfs: failed to create directory work/work (errno: 1); mounting read-only
Reproducible on all Ubuntu kernels with the base >= 5.19
Fixes: eea996a46f ("UBUNTU: SAUCE: overlayfs: Skip permission checking for trusted.overlayfs.* xattrs")
Signed-off-by: Alexander Mikhalitsyn <email address hidden>
Acked-by: Andrea Righi <email address hidden>
Signed-off-by: Andrea Righi <email address hidden>
58f66ae...
by
Ankit Nautiyal <email address hidden>
drm/i915/display: Prune Interlace modes for Display >=12
Defeature Display Interlace support.
Support for interlace modes is removed from Gen 12 onwards.
Pruning the interlace modes for HDMI for Display >=12.
Bspec: 50490
v2: Add check for both DP and HDMI. (Ville)
Get rid of redundant check for interlace mode in modevalid. (Ville)
v3: Simplify the condition to avoid interlace modes. (Jani)
Signed-off-by: Ankit Nautiyal <email address hidden>
Reviewed-by: Jani Nikula <email address hidden>
Signed-off-by: Uma Shankar <email address hidden>
Link: https://patchwork.freedesktop<email address hidden>
(cherry picked from commit f71c9b7bc35ff7c1fb68d114903876eec658439b)
Signed-off-by: Koba Ko <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Acked-by: Timo Aaltonen <email address hidden>
Signed-off-by: Andrea Righi <email address hidden>
024c182...
by
Ankit Nautiyal <email address hidden>
drm/i915/display: Drop check for doublescan mode in modevalid
Since the DP/HDMI connector do not set connector->doublescan_allowed,
the doublescan modes will get automatically filtered during
drm_helper_probe_single_connector_modes().
Therefore check for double scan modes is not required and is dropped
from modevalid functions for both DP and HDMI.
Signed-off-by: Ankit Nautiyal <email address hidden>
Reviewed-by: Jani Nikula <email address hidden>
Signed-off-by: Uma Shankar <email address hidden>
Link: https://patchwork.freedesktop<email address hidden>
(cherry picked from commit 9d04eb20bc71a383b4d4e383b0b7fac8d38a2e34)
Signed-off-by: Koba Ko <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Acked-by: Timo Aaltonen <email address hidden>
Signed-off-by: Andrea Righi <email address hidden>
RDP instruction allows to reset DAT-protection bit in a PTE, with less
CPU synchronization overhead than IPTE instruction. In particular, IPTE
can cause machine-wide synchronization overhead, and excessive IPTE usage
can negatively impact machine performance.
RDP can be used instead of IPTE, if the new PTE only differs in SW bits
and _PAGE_PROTECT HW bit, for PTE protection changes from RO to RW.
SW PTE bit changes are allowed, e.g. for dirty and young tracking, but none
of the other HW-defined part of the PTE must change. This is because the
architecture forbids such changes to an active and valid PTE, which
is why invalidation with IPTE is always used first, before writing a new
entry.
The RDP optimization helps mainly for fault-driven SW dirty-bit tracking.
Writable PTEs are initially always mapped with HW _PAGE_PROTECT bit set,
to allow SW dirty-bit accounting on first write protection fault, where
the DAT-protection would then be reset. The reset is now done with RDP
instead of IPTE, if RDP instruction is available.
RDP cannot always guarantee that the DAT-protection reset is propagated
to all CPUs immediately. This means that spurious TLB protection faults
on other CPUs can now occur. For this, common code provides a
flush_tlb_fix_spurious_fault() handler, which will now be used to do a
CPU-local TLB flush. However, this will clear the whole TLB of a CPU, and
not just the affected entry. For more fine-grained flushing, by simply
doing a (local) RDP again, flush_tlb_fix_spurious_fault() would need to
also provide the PTE pointer.
Note that spurious TLB protection faults cannot really be distinguished
from racing pagetable updates, where another thread already installed the
correct PTE. In such a case, the local TLB flush would be unnecessary
overhead, but overall reduction of CPU synchronization overhead by not
using IPTE is still expected to be beneficial.
Reviewed-by: Alexander Gordeev <email address hidden>
Signed-off-by: Gerald Schaefer <email address hidden>
Signed-off-by: Heiko Carstens <email address hidden>
(cherry picked from commit 0807b856521f3313d3912ebb52a9144215c4ff08)
Signed-off-by: Frank Heimes <email address hidden>
Signed-off-by: Andrea Righi <email address hidden>
e218b3c...
by
Harald Freudenberger <email address hidden>
Since 0b63accf87225b5eb7e52814c374cf02d733d4bb, the test includes a
verification of time passage that is unstable as it is prone to
different results based on the system load.
Other investigations led to disabling this test in various other
places/projects. For example, Linaro also disabled it[1].
We have chosen to keep this test but to force its result unconditionally
successful as opposed to reverting the aforementioned commit because:
1. it keeps running the test with results and data that we can use in
the future for any "smarter" way to deal with it - eg. statistical
approach
2. it minimizes the maintenance burden of this patch kept in our kernel
trees
It is worth mentioning that upstream was contacted via the mailing list
with no feedback[2]. The request was to increase the current tolerance
set at 10%.
