We will need vendor hook of set_user_nice with lock to avoid race
condition.
Bug: 300872872
Change-Id: I24fc1e13cc6578dcc418d956a5146ad29ff76a56
Signed-off-by: Rick Yiu <rickyiu@google.com>
Vendor module code needs to ensure that pushes to the balance
callback queue are handled prior to releasing rq locks.
Export __balance_callbacks to facilitate this.
Bug: 241223356
Change-Id: I86a3f5cb6cc7b97d87bd2db3e11cb7a8d99d4aef
Signed-off-by: Stephen Dickey <quic_dickey@quicinc.com>
(cherry picked from commit a2f552f49c9084dcc48b2066888d06a324e34b98)
This structure is at the heart of the module support for pKVM. Add a
description to help anyone trying to create a module.
Bug: 312200309
Change-Id: Ie1d9043a6a94d15dd8ef25c6f0f8d442da26bc1f
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
(cherry picked from commit af85ead8ce)
It is possible that typec_register_partner() returns ERR_PTR on failure.
When port->partner is an error, a NULL pointer dereference may occur as
shown below.
[91222.095236][ T319] typec port0: failed to register partner (-17)
...
[91225.061491][ T319] Unable to handle kernel NULL pointer dereference
at virtual address 000000000000039f
[91225.274642][ T319] pc : tcpm_pd_data_request+0x310/0x13fc
[91225.274646][ T319] lr : tcpm_pd_data_request+0x298/0x13fc
[91225.308067][ T319] Call trace:
[91225.308070][ T319] tcpm_pd_data_request+0x310/0x13fc
[91225.308073][ T319] tcpm_pd_rx_handler+0x100/0x9e8
[91225.355900][ T319] kthread_worker_fn+0x178/0x58c
[91225.355902][ T319] kthread+0x150/0x200
[91225.355905][ T319] ret_from_fork+0x10/0x30
Add a check for port->partner to avoid dereferencing a NULL pointer.
Fixes: 5e1d4c49fb ("usb: typec: tcpm: Determine common SVDM Version")
Cc: stable@vger.kernel.org
Signed-off-by: Jimmy Hu <hhhuuu@google.com>
Link: https://lore.kernel.org/r/20231020012132.100960-1-hhhuuu@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 280207787
(cherry picked from commit 4987daf86c152ff882d51572d154ad12e4ff3a4b)
Change-Id: I609640ff70258b8fd0e7f9eaad9eb60db35ccfad
Signed-off-by: Kyle Tso <kyletso@google.com>
commit ff33299ec8 upstream.
Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors():
BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011
CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351
print_report mm/kasan/report.c:462 [inline]
kasan_report+0x11c/0x130 mm/kasan/report.c:572
read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
...
Allocated by task 758:
...
__do_kmalloc_node mm/slab_common.c:966 [inline]
__kmalloc+0x5e/0x190 mm/slab_common.c:979
kmalloc include/linux/slab.h:563 [inline]
kzalloc include/linux/slab.h:680 [inline]
usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887
usb_enumerate_device drivers/usb/core/hub.c:2407 [inline]
usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545
As analyzed by Khazhy Kumykov, the cause of this bug is a race between
read_descriptors() and hub_port_init(): The first routine uses a field
in udev->descriptor, not expecting it to change, while the second
overwrites it.
Prior to commit 45bf39f8df ("USB: core: Don't hold device lock while
reading the "descriptors" sysfs file") this race couldn't occur,
because the routines were mutually exclusive thanks to the device
locking. Removing that locking from read_descriptors() exposed it to
the race.
The best way to fix the bug is to keep hub_port_init() from changing
udev->descriptor once udev has been initialized and registered.
Drivers expect the descriptors stored in the kernel to be immutable;
we should not undermine this expectation. In fact, this change should
have been made long ago.
So now hub_port_init() will take an additional argument, specifying a
buffer in which to store the device descriptor it reads. (If udev has
not yet been initialized, the buffer pointer will be NULL and then
hub_port_init() will store the device descriptor in udev as before.)
This eliminates the data race responsible for the out-of-bounds read.
The changes to hub_port_init() appear more extensive than they really
are, because of indentation changes resulting from an attempt to avoid
writing to other parts of the usb_device structure after it has been
initialized. Similar changes should be made to the code that reads
the BOS descriptor, but that can be handled in a separate patch later
on. This patch is sufficient to fix the bug found by syzbot.
Bug: 290990909
Reported-and-tested-by: syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-usb/000000000000c0ffe505fe86c9ca@google.com/#r
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Khazhy Kumykov <khazhy@google.com>
Fixes: 45bf39f8df ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/b958b47a-9a46-4c22-a9f9-e42e42c31251@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 7fe9d87996)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Ia5e4a65cd5d895bf0d85a5aa5efa1c4d1368d069
commit de28e469da upstream.
The usb_get_device_descriptor() routine reads the device descriptor
from the udev device and stores it directly in udev->descriptor. This
interface is error prone, because the USB subsystem expects in-memory
copies of a device's descriptors to be immutable once the device has
been initialized.
The interface is changed so that the device descriptor is left in a
kmalloc-ed buffer, not copied into the usb_device structure. A
pointer to the buffer is returned to the caller, who is then
responsible for kfree-ing it. The corresponding changes needed in the
various callers are fairly small.
Bug: 290990909
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/d0111bb6-56c1-4f90-adf2-6cfe152f6561@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit eda9a29665)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I7c4be5b5dd06f7d5ba8aacad33ecf78f4a3b49e6
commit 85d07c5562 upstream.
In preparation for reworking the usb_get_device_descriptor() routine,
it is desirable to unite the two different code paths responsible for
initially determining endpoint 0's maximum packet size in a newly
discovered USB device. Making this determination presents a
chicken-and-egg sort of problem, in that the only way to learn the
maxpacket value is to get it from the device descriptor retrieved from
the device, but communicating with the device to retrieve a descriptor
requires us to know beforehand the ep0 maxpacket size.
In practice this problem is solved in two different ways, referred to
in hub.c as the "old scheme" and the "new scheme". The old scheme
(which is the approach recommended by the USB-2 spec) involves asking
the device to send just the first eight bytes of its device
descriptor. Such a transfer uses packets containing no more than
eight bytes each, and every USB device must have an ep0 maxpacket size
>= 8, so this should succeed. Since the bMaxPacketSize0 field of the
device descriptor lies within the first eight bytes, this is all we
need.
The new scheme is an imitation of the technique used in an early
Windows USB implementation, giving it the happy advantage of working
with a wide variety of devices (some of them at the time would not
work with the old scheme, although that's probably less true now). It
involves making an initial guess of the ep0 maxpacket size, asking the
device to send up to 64 bytes worth of its device descriptor (which is
only 18 bytes long), and then resetting the device to clear any error
condition that might have resulted from the guess being wrong. The
initial guess is determined by the connection speed; it should be
correct in all cases other than full speed, for which the allowed
values are 8, 16, 32, and 64 (in this case the initial guess is 64).
The reason for this patch is that the old- and new-scheme parts of
hub_port_init() use different code paths, one involving
usb_get_device_descriptor() and one not, for their initial reads of
the device descriptor. Since these reads have essentially the same
purpose and are made under essentially the same circumstances, this is
illogical. It makes more sense to have both of them use a common
subroutine.
This subroutine does basically what the new scheme's code did, because
that approach is more general than the one used by the old scheme. It
only needs to know how many bytes to transfer and whether or not it is
being called for the first iteration of a retry loop (in case of
certain time-out errors). There are two main differences from the
former code:
We initialize the bDescriptorType field of the transfer buffer
to 0 before performing the transfer, to avoid possibly
accessing an uninitialized value afterward.
We read the device descriptor into a temporary buffer rather
than storing it directly into udev->descriptor, which the old
scheme implementation used to do.
Since the whole point of this first read of the device descriptor is
to determine the bMaxPacketSize0 value, that is what the new routine
returns (or an error code). The value is stored in a local variable
rather than in udev->descriptor. As a side effect, this necessitates
moving a section of code that checks the bcdUSB field for SuperSpeed
devices until after the full device descriptor has been retrieved.
Bug: 290990909
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Oliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/495cb5d4-f956-4f4a-a875-1e67e9489510@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 56c49a3328)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I2ffdb9ee11219fca6aeb2cda7867ea53fd6ca61c
When we use an async work queue to perform the function of pumping
usb requests to the usb controller, it is possible that amongst other
factors, thread scheduling affects at what cadence we're able to pump
requests. This could mean isoc usb requests miss their uframes - resulting
in video stream flickers on the host device.
To avoid this, we make the async_wq thread only produce isoc usb_requests
with uvc buffers encoded into them. The process of queueing to the
endpoint is done by the uvc_video_complete() handler. In case no
usb_requests are ready with encoded information, we just queue a zero
length request to the endpoint from the complete handler.
For bulk endpoints the async_wq thread still queues usb requests to the
endpoint.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
Suggested-by: Avichal Rakesh <arakesh@google.com>
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20231120062026.3759463-1-jchowdhary@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 301915972
(cherry picked from commit 6acba0345b68772830582ca1ca369a2f45631275
https://kernel.googlesource.com/pub/scm/linux/kernel/git/gregkh/usb usb-next)
Change-Id: I5597cc29e9caec69e4f3575938d7d640857aaa28
Signed-off-by: Avichal Rakesh <arakesh@google.com>
Currently, the uvc gadget driver allocates all uvc_requests as one array
and deallocates them all when the video stream stops. This includes
de-allocating all the usb_requests associated with those uvc_requests.
This can lead to use-after-free issues if any of those de-allocated
usb_requests were still owned by the usb controller.
This is patch 2 of 2 in fixing the use-after-free issue. It adds a new
flag to uvc_video to track when frames and requests should be flowing.
When disabling the video stream, the flag is tripped and, instead
of de-allocating all uvc_requests and usb_requests, the gadget
driver only de-allocates those usb_requests that are currently
owned by it (as present in req_free). Other usb_requests are left
untouched until their completion handler is called which takes care
of freeing the usb_request and its corresponding uvc_request.
Now that uvc_video does not depends on uvc->state, this patch removes
unnecessary upates to uvc->state that were made to accommodate uvc_video
logic. This should ensure that uvc gadget driver never accidentally
de-allocates a usb_request that it doesn't own.
Link: https://lore.kernel.org/7cd81649-2795-45b6-8c10-b7df1055020d@google.com
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Suggested-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Tested-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Avichal Rakesh <arakesh@google.com>
Link: https://lore.kernel.org/r/20231109004104.3467968-4-arakesh@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 296925310
(cherry picked from commit da324ffce34c521b239f319d4051260444a3eb4a
https://kernel.googlesource.com/pub/scm/linux/kernel/git/gregkh/usb usb-next)
Change-Id: Ib0378394dc20e894507f60c70f71c579d046cd7a
Signed-off-by: Avichal Rakesh <arakesh@google.com>
Add trace hook so modules can track thermal changes to process
vendor value adds.
Bug: 203763121
Change-Id: I5c54b313d3c92c0514f18b07797dd20c9c6f5161
Signed-off-by: Shaleen Agrawal <shalagra@codeaurora.org>
Update vendor hook symbols for lenovo
Bug: 312392542
Change-Id: I1e596bee5a7c776ab4c2af12fd473bf0e6fb2db8
Signed-off-by: vincent wang <vincentwang3@lenovo.com>
In this vendor hook, we can register the energy model before sending the
notification to avoid pd_init failure for some clusters.
more detail info about pd_init failure, pls refer to the link:
https://lore.kernel.org/lkml/20230118044733.29391-1-bhuwz@163.com/T/
But the change patch cannot be submitted upstream due to differences in the
cpufreq code, the failure only appears on the aosp kernel.
Bug: 312392542
Change-Id: Ied4c72d73083d794ad6d8af1eb305be4fb382de3
Signed-off-by: vincent wang <vincentwang3@lenovo.com>
Currently, uinput doesn't use the input_set_timestamp API, so any
event injected using uinput is not accurately timestamped in terms of
measuring when the actual event happened. Hence, call the
input_set_timestamp API from uinput in order to provide a more
accurate sense of time for the event. Propagate only the timestamps
which are a) positive, b) within a pre-defined offset (10 secs) from
the current time, and c) not in the future.
Bug: 271946580
Bug: 277040837
Change-Id: I928be61d0114b78e2098995ee49eeb0376bef2a3
(cherry picked from commit 3a2df60200https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git master)
Signed-off-by: Biswarup Pal <biswarupp@google.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Siarhei Vishniakou <svv@google.com>
Link: https://lore.kernel.org/r/20230427000152.1407471-1-biswarupp@google.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
(cherry picked from commit ee1f5fc55cc7bf1bca78edbb8a1f9d989d4ea03e)
vendor may have the need to modify update_load_sum function
Bug: 181105055
Change-Id: I35964977a4b8917c62773d48a37340f880774e38
Signed-off-by: Chungkai Mei <chungkai@google.com>
modprobe needs /proc/cmdline to pass module arguments to the module
loader. Sadly, so early in the boot, nothing mounts that FS.
Bug: 301483379
Change-Id: Iaab3000e3b7f908fc81f7f36adf2f73c7d3129a4
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
ASoC need to use card->mutex with _INIT or _RUNTIME,
but there is no helper function for it.
This patch adds its helper function and use it.
Because people might misunderstand that _init() is mutex initialization,
this patch renames _INIT to _ROOT and adds new
snd_soc_card_mutex_lock_root() for it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87a5zlx3tw.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Bug: 303236405
(cherry picked from commit 0f3b818486)
[ Yixuan Jiang: Fix minor conflict ]
Change-Id: Ie8cd7aeeea759576423760d25b5fb5b2c9ae0d12
Signed-off-by: Yixuan Jiang <yixuanjiang@google.com>
soc-pcm.c has snd_soc_dpcm_mutex_lock/unlock(),
but other files can't use it because it is static function.
It requests snd_soc_pcm_runtime as parameter (A), but sometimes we
want to use it by snd_soc_card (B).
(A) static inline void snd_soc_dpcm_mutex_lock(struct snd_soc_pcm_runtime *rtd)
{
mutex_lock_nested(&rtd->card->pcm_mutex, rtd->card->pcm_subclass);
} ^^^^^^^^^
(B) mutex_lock_nested(&card->pcm_mutex, card->pcm_subclass);
^^^^
We want to use it with both "rtd" and "card" for dapm lock/unlock.
To enable it, this patch uses _Generic macro.
This patch makes snd_soc_dpcm_mutex_{un}lock() global function, and use it on
each files.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87bkk1x3ud.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Bug: 303236405
(cherry picked from commit 38e42f6d6c)
[ Yixuan Jiang: Fix minor conflict ]
Change-Id: I6cd7fc467b9ec23d6b051d3d531695568996f7a5
Signed-off-by: Yixuan Jiang <yixuanjiang@google.com>
soc.h has snd_soc_dapm_mutex_lock/unlock() definition and
many drivers are using it, but soc-dapm.c is not.
1st reason is snd_soc_dapm_mutex_lock/unlock() requests
snd_soc_dapm_context pointer as parameter (A), but sometimes soc-dapm.c
needs to use snd_soc_card (B).
(A) static inline void snd_soc_dapm_mutex_lock(struct snd_soc_dapm_context *dapm)
{
mutex_lock_nested(&dapm->card->dapm_mutex, SND_SOC_DAPM_CLASS_RUNTIME);
} ^^^^^^^^^^
(B) mutex_lock_nested(&card->dapm_mutex, SND_SOC_DAPM_CLASS_RUNTIME);
^^^^
2nd reason is it want to use SND_SOC_DAPM_CLASS_INIT for mutex_lock_nested(),
but helper is using _RUNTIME (A).
The conclusion is we want to use "dapm vs card" and "_RUNTIME vs _INIT"
for dapm lock/unlock. To enable this selfish request, this patch uses
_Generic macro. We can use snd_soc_dapm_mutex_lock/unlock() for both
dapm and card case.
snd_soc_dapm_mutex_lock(dapm); snd_soc_dapm_mutex_unlock(dapm);
snd_soc_dapm_mutex_lock(card); snd_soc_dapm_mutex_unlock(card);
Current soc-dapm.c is using both mutex_lock() and mutex_lock_nested().
This patch handles mutex_lock() as mutex_lock_nested(..., 0),
in other words, handles below as same.
mutex_lock(&card->dapm_mutex);
mutex_lock_nested(&card->dapm_mutex, SND_SOC_DAPM_CLASS_INIT);
Because people might misunderstand that _init() is mutex initialization,
this patch renames _INIT to _ROOT and adds new
snd_soc_dapm_mutex_lock_root() for it.
This patch also moves snd_soc_dapm_subclass definition from soc-dapm.h
to soc.h to keep related code together.
Because very complex soc.h vs soc-dapm.h relationship,
it is difficult/impossible to define these helper into soc-dapm.h.
Change-Id: I064718bbad9d053a0c84549be0a5e942f29a5dee
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87cz4hx3v0.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Bug: 303236405
(cherry picked from commit 4a778bdc7a)
[ Yixuan Jiang: Fix minor conflict ]
Change-Id: I0fdbc15471f438cd6d8b6c63b106de7186b07ea2
Signed-off-by: Yixuan Jiang <yixuanjiang@google.com>
On one error path, pin_user_pages has succeeded and should be
undone.
Bug: 310131277
Change-Id: I92fe0c54bb5b8005f848491f5e9be1090b61fbd1
Signed-off-by: Keir Fraser <keirf@google.com>
By this vh, so that we can skip if this page needs to be treated
specially, like as cma.
In the Android kernel, the use of cma is restricted, and filecache
cannot use cma.But during the memory compaction process, filecache
may be migrated to cma pool, so a judgment needs to be added here
to restrict filecache from entering cma.
Bug: 309371168
Change-Id: I3ec29bdf5f7b6ac4c7af0a317aa41ad77b71444d
Signed-off-by: Qinglin Li <qinglin.li@amlogic.com>
Look at the passthrough file and check to see if its mount is read-only.
Bug: 297482438
Signed-off-by: Lyon Wang <lyon.wang@mediatek.com>
Change-Id: I0f483c6bcb1effe395eee07b6d721f343840d115
This reverts commit 951d15786a.
Reason for revert: b/306244914
Change-Id: Icd3c3c8c7d330631c12a9133434abcb50fe9347d
Signed-off-by: Will Deacon <willdeacon@google.com>
commit 050d91c03b upstream.
The missing IP_SET_HASH_WITH_NET0 macro in ip_set_hash_netportnet can
lead to the use of wrong `CIDR_POS(c)` for calculating array offsets,
which can lead to integer underflow. As a result, it leads to slab
out-of-bound access.
This patch adds back the IP_SET_HASH_WITH_NET0 macro to
ip_set_hash_netportnet to address the issue.
Bug: 302199939
Fixes: 886503f34d ("netfilter: ipset: actually allow allowable CIDR 0 in hash:net,port,net")
Suggested-by: Jozsef Kadlecsik <kadlec@netfilter.org>
Signed-off-by: Kyle Zeng <zengyhkyle@gmail.com>
Acked-by: Jozsef Kadlecsik <kadlec@netfilter.org>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit a9e6142e5f)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I11cc1650e7df9d54041164b6bdb01f3a0de46de4
commit 7aed44babc upstream.
In the while loop of vringh_iov_xfer(), `partlen` could be 0 if one of
the `iov` has 0 lenght.
In this case, we should skip the iov and go to the next one.
But calling vringh_kiov_advance() with 0 lenght does not cause the
advancement, since it returns immediately if asked to advance by 0 bytes.
Let's restore the code that was there before commit b8c06ad4d6
("vringh: implement vringh_kiov_advance()"), avoiding using
vringh_kiov_advance().
Bug: 302200656
Fixes: b8c06ad4d6 ("vringh: implement vringh_kiov_advance()")
Cc: stable@vger.kernel.org
Reported-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 3a72decd6b)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I5ed14650aca07e0f8d52023cf148bd63e87d04c9
Take f_midi_bind() for example, when composite layer call it, it will
allocate hs descriptor by calling gadget_is_dualspeed() API to check
gadget max support speed capability, but most other gadget function didn't
do like this.
To follow other function drivers, it is safe to remove the check which
mean support all possible link speed by default in function driver.
Similar change apply to midi2 and uvc.
Also in midi and midi2, as there is no descriptor difference between
super speed and super speed plus, follow other gadget function drivers,
do not allocate descriptor for super speed plus, composite layer will
handle it properly.
Signed-off-by: Linyu Yuan <quic_linyyuan@quicinc.com>
Link: https://lore.kernel.org/r/20230803091053.9714-5-quic_linyyuan@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 301887900
Change-Id: I8b287266b3973c66e559bd3eea9adbe95e051be7
(cherry picked from commit 46decc82ffhttps://kernel.googlesource.com/pub/scm/linux/kernel/git/gregkh/usb usb-next)
[arakesh: f_midi2.c doesn't exist, so dropped those changes]
Signed-off-by: Avichal Rakesh <arakesh@google.com>
Upon receiving an ACK for a sent EXIT_MODE message, the DisplayPort
driver currently resets the status and configuration of the port
partner. The hpd signal is not updated despite being part of the
status, so the Display stack can still transmit video despite
typec_altmode_exit placing the lanes in a Safe State.
Set hpd to low when a sent EXIT_MODE message is ACK'ed.
Fixes: 0e3bb7d689 ("usb: typec: Add driver for DisplayPort alternate mode")
Cc: stable@vger.kernel.org
Signed-off-by: RD Babiera <rdbabiera@google.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20231009210057.3773877-2-rdbabiera@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 297208252
Bug: 308184880
(cherry picked from commit 89434b069e)
[rd: removed unused call to drm_connector_oob_hotplug_event]
Change-Id: Iad61fa4db6b126db7fc3bd717b60c2ca35da1311
Signed-off-by: RD Babiera <rdbabiera@google.com>
Adding the following symbols:
- kernfs_find_and_get_ns
- kernfs_notify
- kernfs_put
Bug: 297224564
Change-Id: I3a00968a09de82f954310db567065336e1857885
Signed-off-by: Roy Luo <royluo@google.com>
