Function partial_name_hash() takes long type value into which can be stored
one Unicode code point. Therefore conversion from UTF-32 to UTF-16 is not
needed.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Git-commit: dddf7da3985ee144b46ee287e81e47b9ee8bb980
Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: lixiang <lixiang@codeaurora.org>
Remove the direct use of KERN_<LEVEL> in functions by creating
separate exfat_<level> macros.
Miscellanea:
o Remove several unnecessary terminating newlines in formats
o Realign arguments and fit to 80 columns where appropriate
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Git-commit: d1727d55c0327efdba2a5bad7801d509b721fef3
Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: lixiang <lixiang@codeaurora.org>
If two Unicode code points represented in UTF-16 are different then also
their UTF-32 representation must be different. Therefore conversion from
UTF-32 to UTF-16 is not needed.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Git-commit: 197298a64983e2beaf1a87413daff3044b4f3821
Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: lixiang <lixiang@codeaurora.org>
'es' is malloced from exfat_get_dentry_set() in exfat_find() and should
be freed before leaving from the error handling cases, otherwise it will
cause memory leak.
Fixes: 5f2aa075070c ("exfat: add inode operations")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Git-commit: 94182167ec730dadcaea5fbc6bb8f1136966ef66
Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: lixiang <lixiang@codeaurora.org>
Doing copy_file_range() on exfat with a file opened for direct IO leads
to an -EFAULT:
-c "copy_range -d 16384 -l 16384 -f 0" /mnt/test/junk
copy_range: Bad address
and the reason seems to be that we go through:
default_file_splice_write
splice_from_pipe
__splice_from_pipe
write_pipe_buf
__kernel_write
new_sync_write
generic_file_write_iter
generic_file_direct_write
exfat_direct_IO
do_blockdev_direct_IO
iov_iter_get_pages
and land in iterate_all_kinds(), which does "return -EFAULT" for our kvec
iter.
Setting exfat's splice_write to iter_file_splice_write fixes this and lets
fsx (which originally detected the problem) run to success from
the xfstests harness.
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Git-commit: 035779483072ff7854943dc0cbae82c4e0070d15
Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: lixiang <lixiang@codeaurora.org>
The timestamp for access_time has double seconds granularity(There is no
10msIncrement field for access_time unlike create/modify_time).
exfat's atimes are restricted to only 2s granularity so after
we set an atime, round it down to the nearest 2s and set the
sub-second component of the timestamp to 0.
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Git-commit: 81df1ad40644b706a1cdbd28a1471f9f0c0ea3e8
Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: lixiang <lixiang@codeaurora.org>
The s_time_gran superblock field indicates the on-disk nanosecond
granularity of timestamps, and for exfat that seems to be 10ms, so
set s_time_gran to 10000000ns. Without this, in-memory timestamps
change when they get re-read from disk.
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Git-commit: 674a9985b8e35288225f2b67829a7dee3bf761da
Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: lixiang <lixiang@codeaurora.org>
This adds the necessary MODULE_ALIAS_FS() to exfat so the module gets
automatically loaded when an exfat filesystem is mounted.
Signed-off-by: Thomas Backlund <tmb@mageia.org>
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Git-commit: cd76ac258cd92a6425cb68f95a76d6abdce5395a
Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: lixiang <lixiang@codeaurora.org>
Discard support was always unconditionally disabled. Now it is disabled
only in the case when blk_queue_discard() returns false.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Git-commit: b7e038a92449f191395fbb86538b14093c529833
Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: lixiang <lixiang@codeaurora.org>
enable qcom_scm and fastcvpd for vidc driver.
Change-Id: Idb17a079e1472e1d2a853d2ea68da6933768d7e1
Signed-off-by: Laisheng Hu <laisheng@codeaurora.org>
Consider a case where ep0 is not in setup stage and composition
switch happens. Currently DWC3_DEPCMD_ENDTRANSFER command is not
issued on ep0 which means that the transfers are not flushed out
and driver clears the run/stop bit hence stopping the controller.
Now as soon as driver sets the run/stop bit controller tries to
access the trb from the previous session which is already unmapped
resulting in SMMU fault.
Fix this by unconditionally issuing DWC3_DEPCMD_ENDTRANSFER
command on ep0. Although it is not specified in the data book
but if we know for sure that we are anyway going to stop the
controller then we can issue ENDTRANSFER command on ep0.
Change-Id: Ic6ee570acc8926897d3b6042181a501a47438d92
Signed-off-by: Pratham Pratap <prathampratap@codeaurora.org>
This can ease the complexity to port CNSS2 driver to non-MSM
platforms while still be able to maintain the compatibility.
Change-Id: I268cdd90c59085b34aa2fe3c3b845d60c4e2a417
Signed-off-by: Yue Ma <yuem@codeaurora.org>
Since there may be link issues if QCA6490 device boots up with Gen3
link speed, always set initial target PCIe link speed to Gen2. Device
is able to change it (back) later at any time if needed.
Change-Id: I9d617d71926fe98e59e67aff772984878e0a2689
Signed-off-by: Yue Ma <yuem@codeaurora.org>
Remove CONFIG_SLUB_DEBUG_ON from debug variant for performance
reasons. Also remove redundant HARDENED_USERCOPY from debug config
since this gets copied over from the standard config.
Change-Id: I7c6fc8620290cf126ced046f82811e9e39bc2a60
Signed-off-by: Dennis Cagle <dcagle@codeaurora.org>
There are usecases where clients want to change the maximum GEN
speed that PCIe can link up with. Provide clients the ability to
control the maximum PCIe GEN speed to for such usecases.
Change-Id: I834bee2063133546c9b0ebac2d5328ffbc5ceac6
Signed-off-by: Tony Truong <truong@codeaurora.org>
In HS Only mode of dwc3 controller version 1.9A, UTMI clock needs
to be selected before core soft reset as per the HPG sequence.
Or else the core soft reset fails, leading to enumeration
failure. Hence select UTMI clock before performing
SOFT_RESET operation.
Change-Id: I12d4a992872eecbfc38825282559cd4d592c3896
Signed-off-by: Elson Roy Serrao <eserrao@codeaurora.org>
For non-MSM platforms, PCI wake GPIO may not be handled by PCI root
complex driver so add support to handle it in device driver.
Change-Id: Ief6bc6b25bdc5b93887af1cc626acc721f9fa85a
Signed-off-by: Yue Ma <yuem@codeaurora.org>
This makes sure CNSS2 driver is able to work in the platforms and
kernels which do not have on-chip interconnect management feature.
Change-Id: I282ef1a282fab9ce4910e7ab914f26789b34ba64
Signed-off-by: Yue Ma <yuem@codeaurora.org>
This makes sure CNSS2 driver is able to work in non-MSM platforms
which do not have command DB feature.
Change-Id: I9551bfc639e6db0256e475a27db5dec87bce74ed
Signed-off-by: Yue Ma <yuem@codeaurora.org>
This makes sure CNSS2 driver is able to work in non-MSM platforms
which do not have IPC logging feature.
Change-Id: I4c8fe3eb45e38fd106f47c28f0e4da82b0bdf76f
Signed-off-by: Yue Ma <yuem@codeaurora.org>
This makes sure CNSS2 driver is able to work in non-MSM platforms
which do not have memory dump and mini dump features.
Change-Id: I5193deed941ff8e2e2ca2693150396a53eb3db7d
Signed-off-by: Yue Ma <yuem@codeaurora.org>
