commit 16e28abb7290c4ca3b3a0f333ba067f34bb18c86 upstream.
Fujitsu Lifebook T725 laptop requires, like a few other similar
models, the nomux and notimeout options to probe the touchpad
properly. This patch adds the corresponding quirk entries.
BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1191980
Tested-by: Neal Gompa <ngompa13@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20211103070019.13374-1-tiwai@suse.de
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit be896bd3b72b44126c55768f14c22a8729b0992e upstream.
Some firmwares occasionally report bogus data from trackpoint, with X or Y
displacement being too large (outside of [-127, 127] range). Let's drop such
packets so that we do not generate jumps.
Signed-off-by: Phoenix Huang <phoenix@emc.com.tw>
Tested-by: Yufei Du <yufeidu@cs.unc.edu>
Link: https://lore.kernel.org/r/20210729010940.5752-1-phoenix@emc.com.tw
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 744d0090a5f6dfa4c81b53402ccdf08313100429 upstream.
USB control-message timeouts are specified in milliseconds and should
specifically not vary with CONFIG_HZ.
Fixes: 4873586278 ("Input: iforce - use DMA-safe buffer when getting IDs from USB")
Signed-off-by: Johan Hovold <johan@kernel.org>
Cc: stable@vger.kernel.org # 5.3
Link: https://lore.kernel.org/r/20211025115501.5190-1-johan@kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4d5b5539742d2554591751b4248b0204d20dcc9d upstream.
Use the 'struct cred' saved at binder_open() to lookup
the security ID via security_cred_getsecid(). This
ensures that the security context that opened binder
is the one used to generate the secctx.
Cc: stable@vger.kernel.org # 5.4+
Fixes: ec74136ded ("binder: create node flag to request sender's security context")
Signed-off-by: Todd Kjos <tkjos@google.com>
Suggested-by: Stephen Smalley <stephen.smalley.work@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Acked-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 52f88693378a58094c538662ba652aff0253c4fe upstream.
Since binder was integrated with selinux, it has passed
'struct task_struct' associated with the binder_proc
to represent the source and target of transactions.
The conversion of task to SID was then done in the hook
implementations. It turns out that there are race conditions
which can result in an incorrect security context being used.
Fix by using the 'struct cred' saved during binder_open and pass
it to the selinux subsystem.
Cc: stable@vger.kernel.org # 5.14 (need backport for earlier stables)
Fixes: 79af73079d ("Add security hooks to binder and implement the hooks for SELinux.")
Suggested-by: Jann Horn <jannh@google.com>
Signed-off-by: Todd Kjos <tkjos@google.com>
Acked-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 29bc22ac5e5bc63275e850f0c8fc549e3d0e306b upstream.
Save the 'struct cred' associated with a binder process
at initial open to avoid potential race conditions
when converting to an euid.
Set a transaction's sender_euid from the 'struct cred'
saved at binder_open() instead of looking up the euid
from the binder proc's 'struct task'. This ensures
the euid is associated with the security context that
of the task that opened binder.
Cc: stable@vger.kernel.org # 4.4+
Fixes: 457b9a6f09 ("Staging: android: add binder driver")
Signed-off-by: Todd Kjos <tkjos@google.com>
Suggested-by: Stephen Smalley <stephen.smalley.work@gmail.com>
Suggested-by: Jann Horn <jannh@google.com>
Acked-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 660a92a59b9e831a0407e41ff62875656d30006e upstream.
AMD's Yellow Carp platform supports runtime power management for
XHCI Controllers, so enable the same by default for all XHCI Controllers.
[ regrouped and aligned the PCI_DEVICE_ID definitions -Mathias]
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: Nehal Bakulchandra Shah <Nehal-Bakulchandra.shah@amd.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20211014121200.75433-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e1959faf085b004e6c3afaaaa743381f00e7c015 upstream.
Some USB 3.1 enumeration issues were reported after the hub driver removed
the minimum 100ms limit for the power-on-good delay.
Since commit 90d28fb53d4a ("usb: core: reduce power-on-good delay time of
root hub") the hub driver sets the power-on-delay based on the
bPwrOn2PwrGood value in the hub descriptor.
xhci driver has a 20ms bPwrOn2PwrGood value for both roothubs based
on xhci spec section 5.4.8, but it's clearly not enough for the
USB 3.1 devices, causing enumeration issues.
Tests indicate full 100ms delay is needed.
Reported-by: Walt Jr. Brake <mr.yming81@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Fixes: 90d28fb53d4a ("usb: core: reduce power-on-good delay time of root hub")
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211105160036.549516-1-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 051373292b.
Reason for revert: tests will be dropped from gsi
Change-Id: I435df6e02114a3e66591f2f6d2d2136d7893842a
Signed-off-by: Alistair Delva <adelva@google.com>
Change a variable type in QMI encode logic to avoid
buffer overflow scenario.
Change-Id: I11b10cce0e9ab5b02738b2ba13e637df979e9310
Signed-off-by: Gopala Krishna Nuthaki <gnuthaki@codeaurora.org>
commit 541fd20c3ce5b0bc39f0c6a52414b6b92416831c upstream.
USB control-message timeouts are specified in milliseconds and should
specifically not vary with CONFIG_HZ.
Use the common control-message timeout define for the five-second
timeout.
Fixes: dad0d04fa7 ("rsi: Add RS9113 wireless driver")
Cc: stable@vger.kernel.org # 3.15
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211025120522.6045-5-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a44f9d6f9dc1fb314a3f1ed2dcd4fbbcc3d9f892 upstream.
There is a wrong comparison of the total size of the loaded firmware
css->fw->size with the size of a pointer to struct imgu_fw_header.
Turn binary_header into a flexible-array member[1][2], use the
struct_size() helper and fix the wrong size comparison. Notice
that the loaded firmware needs to contain at least one 'struct
imgu_fw_info' item in the binary_header[] array.
It's also worth mentioning that
"css->fw->size < struct_size(css->fwp, binary_header, 1)"
with binary_header declared as a flexible-array member is equivalent
to
"css->fw->size < sizeof(struct imgu_fw_header)"
with binary_header declared as a one-element array (as in the original
code).
The replacement of the one-element array with a flexible-array member
also helps with the ongoing efforts to globally enable -Warray-bounds
and get us closer to being able to tighten the FORTIFY_SOURCE routines
on memcpy().
[1] https://en.wikipedia.org/wiki/Flexible_array_member
[2] https://www.kernel.org/doc/html/v5.10/process/deprecated.html#zero-length-and-one-element-arrays
Link: https://github.com/KSPP/linux/issues/79
Link: https://github.com/KSPP/linux/issues/109
Fixes: 09d290f0ba ("media: staging/intel-ipu3: css: Add support for firmware management")
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4cfa36d312d6789448b59a7aae770ac8425017a3 upstream.
USB control-message timeouts are specified in milliseconds and should
specifically not vary with CONFIG_HZ.
Fixes: 8fc8598e61 ("Staging: Added Realtek rtl8192u driver to staging")
Cc: stable@vger.kernel.org # 2.6.33
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20211025120910.6339-2-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ce4940525f36ffdcf4fa623bcedab9c2a6db893a upstream.
USB control-message timeouts are specified in milliseconds and should
specifically not vary with CONFIG_HZ.
Fixes: 2865d42c78 ("staging: r8712u: Add the new driver to the mainline kernel")
Cc: stable@vger.kernel.org # 2.6.37
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20211025120910.6339-3-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a56d3e40bda460edf3f8d6aac00ec0b322b4ab83 upstream.
USB bulk and interrupt message timeouts are specified in milliseconds
and should specifically not vary with CONFIG_HZ.
Note that the bulk-out transfer timeout was set to the endpoint
bInterval value, which should be ignored for bulk endpoints and is
typically set to zero. This meant that a failing bulk-out transfer
would never time out.
Assume that the 10 second timeout used for all other transfers is more
than enough also for the bulk-out endpoint.
Fixes: 985cafccbf ("Staging: Comedi: vmk80xx: Add k8061 support")
Fixes: 951348b377 ("staging: comedi: vmk80xx: wait for URBs to complete")
Cc: stable@vger.kernel.org # 2.6.31
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://lore.kernel.org/r/20211025114532.4599-6-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 78cdfd62bd54af615fba9e3ca1ba35de39d3871d upstream.
The driver is using endpoint-sized buffers but must not assume that the
tx and rx buffers are of equal size or a malicious device could overflow
the slab-allocated receive buffer when doing bulk transfers.
Fixes: 985cafccbf ("Staging: Comedi: vmk80xx: Add k8061 support")
Cc: stable@vger.kernel.org # 2.6.31
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://lore.kernel.org/r/20211025114532.4599-5-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a23461c47482fc232ffc9b819539d1f837adf2b1 upstream.
The driver uses endpoint-sized USB transfer buffers but up until
recently had no sanity checks on the sizes.
Commit e1f13c879a7c ("staging: comedi: check validity of wMaxPacketSize
of usb endpoints found") inadvertently fixed NULL-pointer dereferences
when accessing the transfer buffers in case a malicious device has a
zero wMaxPacketSize.
Make sure to allocate buffers large enough to handle also the other
accesses that are done without a size check (e.g. byte 18 in
vmk80xx_cnt_insn_read() for the VMK8061_MODEL) to avoid writing beyond
the buffers, for example, when doing descriptor fuzzing.
The original driver was for a low-speed device with 8-byte buffers.
Support was later added for a device that uses bulk transfers and is
presumably a full-speed device with a maximum 64-byte wMaxPacketSize.
Fixes: 985cafccbf ("Staging: Comedi: vmk80xx: Add k8061 support")
Cc: stable@vger.kernel.org # 2.6.31
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://lore.kernel.org/r/20211025114532.4599-4-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 907767da8f3a925b060c740e0b5c92ea7dbec440 upstream.
The driver uses endpoint-sized USB transfer buffers but had no sanity
checks on the sizes. This can lead to zero-size-pointer dereferences or
overflowed transfer buffers in ni6501_port_command() and
ni6501_counter_command() if a (malicious) device has smaller max-packet
sizes than expected (or when doing descriptor fuzz testing).
Add the missing sanity checks to probe().
Fixes: a03bb00e50 ("staging: comedi: add NI USB-6501 support")
Cc: stable@vger.kernel.org # 3.18
Cc: Luca Ellero <luca.ellero@brickedbrain.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20211027093529.30896-2-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 536de747bc48262225889a533db6650731ab25d3 upstream.
USB transfer buffers are typically mapped for DMA and must not be
allocated on the stack or transfers will fail.
Allocate proper transfer buffers in the various command helpers and
return an error on short transfers instead of acting on random stack
data.
Note that this also fixes a stack info leak on systems where DMA is not
used as 32 bytes are always sent to the device regardless of how short
the command is.
Fixes: 63274cd7d3 ("Staging: comedi: add usb dt9812 driver")
Cc: stable@vger.kernel.org # 2.6.29
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20211027093529.30896-3-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e96a1866b40570b5950cda8602c2819189c62a48 upstream.
When isofs image is suitably corrupted isofs_read_inode() can read data
beyond the end of buffer. Sanity-check the directory entry length before
using it.
Reported-and-tested-by: syzbot+6fc7fb214625d82af7d1@syzkaller.appspotmail.com
CC: stable@vger.kernel.org
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3cffa06aeef7ece30f6b5ac0ea51f264e8fea4d0 upstream.
The commit 48021f98130880dd74 ("printk: handle blank console arguments
passed in.") prevented crash caused by empty console= parameter value.
Unfortunately, this value is widely used on Chromebooks to disable
the console output. The above commit caused performance regression
because the messages were pushed on slow console even though nobody
was watching it.
Use ttynull driver explicitly for console="" and console=null
parameters. It has been created for exactly this purpose.
It causes that preferred_console is set. As a result, ttySX and ttyX
are not used as a fallback. And only ttynull console gets registered by
default.
It still allows to register other consoles either by additional console=
parameters or SPCR. It prevents regression because it worked this way even
before. Also it is a sane semantic. Preventing output on all consoles
should be done another way, for example, by introducing mute_console
parameter.
Link: https://lore.kernel.org/r/20201006025935.GA597@jagdpanzerIV.localdomain
Suggested-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Link: https://lore.kernel.org/r/20201111135450.11214-3-pmladek@suse.com
Cc: Yi Fan <yfa@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 32e9f56a96d8d0f23cb2aeb2a3cd18d40393e787 upstream.
When freeing txn buffers, binder_transaction_buffer_release()
attempts to detect whether the current context is the target by
comparing current->group_leader to proc->tsk. This is an unreliable
test. Instead explicitly pass an 'is_failure' boolean.
Detecting the sender was being used as a way to tell if the
transaction failed to be sent. When cleaning up after
failing to send a transaction, there is no need to close
the fds associated with a BINDER_TYPE_FDA object. Now
'is_failure' can be used to accurately detect this case.
Fixes: 44d8047f1d ("binder: use standard functions to allocate fds")
Cc: stable <stable@vger.kernel.org>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Todd Kjos <tkjos@google.com>
Link: https://lore.kernel.org/r/20211015233811.3532235-1-tkjos@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 05c8f1b67e67dcd786ae3fe44492bbc617b4bd12 upstream.
These drive enclosures have firmware bugs that make it impossible to mount
a new virtual ISO image after Linux ejects the old one if the device is
locked by Linux. Windows bypasses this problem by the fact that they do
not lock the device. Add a quirk to disable device locking for these
drive enclosures.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: James Buren <braewoods+lkml@braewoods.net>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211014015504.2695089-1-braewoods+lkml@braewoods.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 21b5fcdccb32ff09b6b63d4a83c037150665a83f upstream.
musb_gadget_queue() adds the passed request to musb_ep::req_list. If the
endpoint is idle and it is the first request then it invokes
musb_queue_resume_work(). If the function returns an error then the
error is passed to the caller without any clean-up and the request
remains enqueued on the list. If the caller enqueues the request again
then the list corrupts.
Remove the request from the list on error.
Fixes: ea2f35c01d ("usb: musb: Fix sleeping function called from invalid context for hdrc glue")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Viraj Shah <viraj.shah@linutronix.de>
Link: https://lore.kernel.org/r/20211021093644.4734-1-viraj.shah@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a0548b26901f082684ad1fb3ba397d2de3a1406a upstream.
On 64-bit:
drivers/usb/gadget/udc/fsl_qe_udc.c: In function ‘qe_ep0_rx’:
drivers/usb/gadget/udc/fsl_qe_udc.c:842:13: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
842 | vaddr = (u32)phys_to_virt(in_be32(&bd->buf));
| ^
In file included from drivers/usb/gadget/udc/fsl_qe_udc.c:41:
drivers/usb/gadget/udc/fsl_qe_udc.c:843:28: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
843 | frame_set_data(pframe, (u8 *)vaddr);
| ^
The driver assumes physical and virtual addresses are 32-bit, hence it
cannot work on 64-bit platforms.
Acked-by: Li Yang <leoyang.li@nxp.com>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Link: https://lore.kernel.org/r/20211027080849.3276289-1-geert@linux-m68k.org
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7f2d73788d9067fd4f677ac5f60ffd25945af7af upstream.
For Aspeed, HCHalted status depends on not only Run/Stop but also
ASS/PSS status.
Handshake CMD_RUN on startup instead.
Tested-by: Tao Ren <rentao.bupt@gmail.com>
Reviewed-by: Tao Ren <rentao.bupt@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Neal Liu <neal_liu@aspeedtech.com>
Link: https://lore.kernel.org/r/20210910073619.26095-1-neal_liu@aspeedtech.com
Cc: Joel Stanley <joel@jms.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1e254d0d86a0f2efd4190a89d5204b37c18c6381 upstream.
This reverts commit 76b4f357d0e7d8f6f0013c733e6cba1773c266d3.
The commit has the wrong reasoning, as KVM_MAX_VCPU_ID is not defining the
maximum allowed vcpu-id as its name suggests, but the number of vcpu-ids.
So revert this patch again.
Suggested-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20210913135745.13944-2-jgross@suse.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
kgsl_ioctl_gpu_aux_command creates a separate drawobj for each command
in numcmds sent from userspace. All drawbojs created will have same
timestamp. We can not queue more than one drawobj with same timestamp.
Each new drawobj must have timestamp greater than previously queued
drawobjs. This results in failure of kgsl_ioctl_gpu_aux_command.
Add proper check and return early when numcmds is invalid.
Change-Id: I06413c16b0a21abcffb121b2e332752eb71e6be0
Signed-off-by: Pranav Patel <pranavp@codeaurora.org>
Signed-off-by: Akhil P Oommen <akhilpo@codeaurora.org>
This implements a mitigation device to place a minimum frequency floor
on a particular devfreq device. This mitigation device will be used by
low temperature reliability rules to mitigate a devfreq device at
minimum operating level.
Change-Id: Iaae6ea4ffa12735145fc2b573ddfa98183b379fe
Signed-off-by: Manaf Meethalavalappu Pallikunhi <manafm@codeaurora.org>
Signed-off-by: Priyansh Jain <priyjain@codeaurora.org>
When runtime suspend occurs xhci_suspend is called and now all the
clocks are turned off. Now if pm_suspend happens xhci_suspend is again
called which leads to unclocked access of registers in function
xhci_disable_hub_port_wake. Fix this by considering second
call of xhci_suspend due to pm_suspend as no-op.
Change-Id: Ic053636ac1d6c54150b40e5477b5eb373fcdbeb3
Signed-off-by: Rohith Kollalsi <quic_rkollals@quicinc.com>
Sync up with android11-5.4 for the following commits:
bfb2ce3eb1 ANDROID: GKI: rework the ANDROID_KABI_USE() macro to not use __UNIQUE()
937e6e41cc UPSTREAM: security: selinux: allow per-file labeling for bpffs
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I5c3546d9d9a2216f2f81a86e2824fa2de9a6bd8c
Enable the default available cpufreq governor used to scale
cpu frequency based on the load for sdxnightjar perf config.
Change-Id: I93aeb27350562fe1c488c22d5ac24b80b4a9fdf4
Signed-off-by: Santosh Mardi <gsantosh@codeaurora.org>
Driver core invokes runtime PM idle after the device is probed. When the
runtime idle callback returns 0, platform bus proceed to runtime suspend.
If this races with state machine work which marks the runtime state as
active and enables runtime PM, there is a possibility that the runtime
PM thinks device is suspended. Because the runtime PM suspend patch
returns simply because in_lpm is true. Now, state machine work calls
dwc3_msm_resume() which sets WAIT_FOR_LPM flag hoping that it would be
cleared while runtime suspend happens via pm_runtime_put_sync(). Though
the device is in resume state, runtime PM core thinks it is suspended
due to the race mentioned above. The fact that WAIT_FOR_LPM is set,
state machine for ever stuck in DRD_STATE_IDLE waiting for this flag to
be cleared.
Fix this by calling dwc3_msm_resume before setting device as active so
that the corresponding pm_runtime_put_sync operation happens correctly.
Change-Id: I3ee58ca01d2afdf169b1f52816d7d4d448cbf8e6
Signed-off-by: Rohith Kollalsi <quic_rkollals@quicinc.com>
The __UNIQUE_ID() macro causes problems as it turns out to not be
deterministic across different compiler runs as it relies on the
__COUNTER__ macro which could have been used on other .h files previous
to this .h file being included.
This shows up specifically when building with "LTO=thin" vs. "LTO=full"
as different build paths seem to be triggered.
As the structure name isn't really needed at all here, we were just
including it for older compilers that could not handle anonymous
structures in a union, just drop the whole thing which resolves the abi
naming issue.
Bug: 210255585
Reported-by: Giuliano Procida <gprocida@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I6b9449fa9d26ffc5d66b2f0f3b41e2d5f3003f68
This change is to meet the spec for i2c at 400KHz. Note that there
is a QUP FW change along with this and then only this will work.
FW change takes care of the duty cycle, clock on/off.
FW change CR : 3019821
CR fixed : 3017809.
Change-Id: I7c03d78ce4c54454b0bb66dcd587f327e63d07e1
Signed-off-by: Mukesh Kumar Savaliya <msavaliy@codeaurora.org>
If getting close-loop TLRA failed in driver probe, such as if there
is no valid value in SDAM register for CAL_TLRA_CL_STS because of the
bootloader had not run the frequency calibration successfully. Use
open-loop TLRA to program the hardware so the vibrator can still be
functional but just lose some efficiency because of unadjusted
frequency.
Change-Id: I8b8dd0906aa6b3fa882e2044cdbe579c746714a3
Signed-off-by: Fenglin Wu <fenglinw@codeaurora.org>
Reallocate memory using vmalloc() for custom FIFO data if the memory
allocation using kcalloc() is failed. This may happen if the vibrator
HAL is passing down a vibration effect with a very big chunk of FIFO
data and system is running out of memory.
Change-Id: I3612208df42e46a44ca0fd43ec9b4c6ca862620e
Signed-off-by: Fenglin Wu <fenglinw@codeaurora.org>
