If some error occurs, URB buffers should also be freed. If they aren't
freed with the dvb here, the em28xx_dvb_fini call doesn't frees the URB
buffers as dvb is set to NULL. The function in which error occurs should
do all the cleanup for the allocations it had done.
Tested the patch with the reproducer provided by syzbot. This patch
fixes the memleak.
Reported-by: syzbot+889397c820fa56adf25d@syzkaller.appspotmail.com
Signed-off-by: Muhammad Usama Anjum <musamaanjum@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
change 'vodeo' to 'video'
change 'nevery' to 'never'
change 'is' to 'it'
change 'connevted' to 'connected'
change 'swichers' to 'switchers'
change 'strucure' to 'structure'
change 'unblanced' to 'unbalanced'
change 'fonctionality' to 'functionality'
Signed-off-by: Xiaofeng Cao <caoxiaofeng@yulong.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The EDID failed with two edid-decode warnings:
Block 1, CTA-861 Extension Block:
Video Data Block: VIC 16 is the preferred timing, overriding the first detailed timings. Is this intended?
Video Capability Data Block: S_PT is equal to S_IT and S_CE, so should be set to 0 instead.
In addition, the first DTD had a wrong vsync value (6 instead of 5).
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Trivial fixes for many kernel-doc warnings. Most of the comments before
enums or struct can just be that: regular comments.
So just change /** to /*.
In one remaining case it was just a wrong construct: @mem_dev[] -> @mem_dev
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Currently the header argument is being passed by value, so a copy of 256
byte structure on the stack is potentially occurring. Fix this by passing
by reference to avoid any large stack copies.
Addresses-Coverity: ("Big parameter passed by value")
Fixes: 2db16c6ed7 ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add a description for enum values in hantro_enc_fmt,
in order to fix these warnings:
drivers/staging/media/hantro/hantro_hw.h:149: warning: Enum value 'RK3288_VPU_ENC_FMT_YUV420P' not described in enum 'hantro_enc_fmt'
drivers/staging/media/hantro/hantro_hw.h:149: warning: Enum value 'RK3288_VPU_ENC_FMT_YUV420SP' not described in enum 'hantro_enc_fmt'
drivers/staging/media/hantro/hantro_hw.h:149: warning: Enum value 'RK3288_VPU_ENC_FMT_YUYV422' not described in enum 'hantro_enc_fmt'
drivers/staging/media/hantro/hantro_hw.h:149: warning: Enum value 'RK3288_VPU_ENC_FMT_UYVY422' not described in enum 'hantro_enc_fmt'
While here, improve the kernel-doc style, adding an empty
line before the fields of the structs.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
In case of error, the function device_link_add() returns NULL
pointer not ERR_PTR(). The IS_ERR() test in the return value
check should be replaced with NULL test.
Fixes: 2db16c6ed7 ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Fix to return negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Fixes: 2db16c6ed7 ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Modify the documentation to point out which flags and structs are
used to configure the statistics.
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Reviewed-by: Sebastian Fricke <sebastian.fricke@posteo.net>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There is a spelling mistake in a dev_err message. Fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Fixes these kernel-doc warnings:
drivers/media/platform/exynos4-is/fimc-isp.h:139: warning: Function parameter or member 've' not described in 'fimc_is_video'
drivers/media/platform/exynos4-is/fimc-isp.h:139: warning: Function parameter or member 'buf_count' not described in 'fimc_is_video'
drivers/media/platform/exynos4-is/fimc-isp.h:139: warning: Function parameter or member 'buf_mask' not described in 'fimc_is_video'
drivers/media/platform/exynos4-is/fimc-isp.h:139: warning: Function parameter or member 'streaming' not described in 'fimc_is_video'
drivers/media/platform/exynos4-is/fimc-isp.h:139: warning: Function parameter or member 'buffers' not described in 'fimc_is_video'
drivers/media/platform/exynos4-is/fimc-isp.h:139: warning: Function parameter or member 'pixfmt' not described in 'fimc_is_video'
drivers/media/platform/exynos4-is/fimc-isp.h:176: warning: Function parameter or member 'src_fmt' not described in 'fimc_isp'
drivers/media/platform/exynos4-is/fimc-isp.h:176: warning: Function parameter or member 'sink_fmt' not described in 'fimc_isp'
drivers/media/platform/exynos4-is/fimc-isp.h:176: warning: Function parameter or member 'subdev_lock' not described in 'fimc_isp'
drivers/media/platform/exynos4-is/fimc-lite.h:178: warning: Function parameter or member 'events' not described in 'fimc_lite'
drivers/media/platform/exynos4-is/fimc-lite.h:178: warning: Function parameter or member 'streaming' not described in 'fimc_lite'
drivers/media/platform/exynos4-is/media-dev.h:143: warning: Function parameter or member 'wbclk' not described in 'fimc_md'
drivers/media/platform/exynos4-is/media-dev.h:143: warning: Function parameter or member 'fimc_lite' not described in 'fimc_md'
drivers/media/platform/exynos4-is/media-dev.h:143: warning: Function parameter or member 'clk_provider' not described in 'fimc_md'
drivers/media/platform/exynos4-is/media-dev.h:143: warning: Function parameter or member 'subdev_notifier' not described in 'fimc_md'
drivers/media/platform/exynos4-is/media-dev.h:143: warning: Function parameter or member 'pipelines' not described in 'fimc_md'
drivers/media/platform/exynos4-is/media-dev.h:143: warning: Function parameter or member 'link_setup_graph' not described in 'fimc_md'
drivers/media/platform/exynos4-is/fimc-core.h:261: warning: Function parameter or member 'alpha' not described in 'fimc_frame'
drivers/media/platform/exynos4-is/fimc-core.h:321: warning: Function parameter or member 'streaming' not described in 'fimc_vid_cap'
drivers/media/platform/exynos4-is/fimc-core.h:429: warning: Function parameter or member 'drv_data' not described in 'fimc_dev'
drivers/media/platform/exynos4-is/fimc-core.h:495: warning: Function parameter or member 'in_order_1p' not described in 'fimc_ctx'
drivers/media/platform/exynos4-is/fimc-core.h:673: warning: Function parameter or member 'vid_cap' not described in 'fimc_active_queue_add'
drivers/media/platform/exynos4-is/fimc-core.h:685: warning: Function parameter or member 'vid_cap' not described in 'fimc_active_queue_pop'
drivers/media/platform/exynos4-is/fimc-core.h:700: warning: Function parameter or member 'vid_cap' not described in 'fimc_pending_queue_add'
drivers/media/platform/exynos4-is/fimc-core.h:711: warning: Function parameter or member 'vid_cap' not described in 'fimc_pending_queue_pop'
drivers/media/platform/exynos4-is/fimc-reg.h:333: warning: Function parameter or member 'dev' not described in 'fimc_hw_set_dma_seq'
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Fixes these kernel-doc warnings:
drivers/media/platform/exynos-gsc/gsc-core.h:76: warning: Enum value 'GSC_MIXER' not described in enum 'gsc_datapath'
drivers/media/platform/exynos-gsc/gsc-core.h:76: warning: Enum value 'GSC_FIMD' not described in enum 'gsc_datapath'
drivers/media/platform/exynos-gsc/gsc-core.h:76: warning: Excess enum value 'GSC_LOCAL' description in 'gsc_datapath'
drivers/media/platform/exynos-gsc/gsc-core.h:124: warning: Function parameter or member 'color' not described in 'gsc_fmt'
drivers/media/platform/exynos-gsc/gsc-core.h:124: warning: Function parameter or member 'num_comp' not described in 'gsc_fmt'
drivers/media/platform/exynos-gsc/gsc-core.h:297: warning: Function parameter or member 'pix_max' not described in 'gsc_variant'
drivers/media/platform/exynos-gsc/gsc-core.h:297: warning: Function parameter or member 'pix_min' not described in 'gsc_variant'
drivers/media/platform/exynos-gsc/gsc-core.h:297: warning: Function parameter or member 'pix_align' not described in 'gsc_variant'
drivers/media/platform/exynos-gsc/gsc-core.h:297: warning: Function parameter or member 'in_buf_cnt' not described in 'gsc_variant'
drivers/media/platform/exynos-gsc/gsc-core.h:297: warning: Function parameter or member 'out_buf_cnt' not described in 'gsc_variant'
drivers/media/platform/exynos-gsc/gsc-core.h:297: warning: Function parameter or member 'sc_up_max' not described in 'gsc_variant'
drivers/media/platform/exynos-gsc/gsc-core.h:297: warning: Function parameter or member 'sc_down_max' not described in 'gsc_variant'
drivers/media/platform/exynos-gsc/gsc-core.h:297: warning: Function parameter or member 'poly_sc_down_max' not described in 'gsc_variant'
drivers/media/platform/exynos-gsc/gsc-core.h:297: warning: Function parameter or member 'pre_sc_down_max' not described in 'gsc_variant'
drivers/media/platform/exynos-gsc/gsc-core.h:297: warning: Function parameter or member 'local_sc_down' not described in 'gsc_variant'
drivers/media/platform/exynos-gsc/gsc-core.h:310: warning: Function parameter or member 'clk_names' not described in 'gsc_driverdata'
drivers/media/platform/exynos-gsc/gsc-core.h:310: warning: Function parameter or member 'num_clocks' not described in 'gsc_driverdata'
drivers/media/platform/exynos-gsc/gsc-core.h:340: warning: Function parameter or member 'num_clocks' not described in 'gsc_dev'
drivers/media/platform/exynos-gsc/gsc-core.h:340: warning: Function parameter or member 'v4l2_dev' not described in 'gsc_dev'
drivers/media/platform/exynos-gsc/gsc-core.h:376: warning: Function parameter or member 'rotation' not described in 'gsc_ctx'
drivers/media/platform/exynos-gsc/gsc-core.h:376: warning: Function parameter or member 'hflip' not described in 'gsc_ctx'
drivers/media/platform/exynos-gsc/gsc-core.h:376: warning: Function parameter or member 'vflip' not described in 'gsc_ctx'
drivers/media/platform/exynos-gsc/gsc-core.h:376: warning: Function parameter or member 'gsc_ctrls' not described in 'gsc_ctx'
drivers/media/platform/exynos-gsc/gsc-core.h:376: warning: Function parameter or member 'out_colorspace' not described in 'gsc_ctx'
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Fixes these warnings:
drivers/media/platform/s5p-jpeg/jpeg-core.h:136: warning: Function parameter or member 'irq_ret' not described in 's5p_jpeg'
drivers/media/platform/s5p-jpeg/jpeg-core.h:136: warning: Function parameter or member 'irq_status' not described in 's5p_jpeg'
drivers/media/platform/s5p-jpeg/jpeg-core.h:168: warning: Function parameter or member 'memplanes' not described in 's5p_jpeg_fmt'
drivers/media/platform/s5p-jpeg/jpeg-core.h:168: warning: Function parameter or member 'subsampling' not described in 's5p_jpeg_fmt'
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Fixes these warnings:
drivers/media/platform/s3c-camif/camif-core.h:156: warning: Function parameter or member 'pix_limits' not described in 's3c_camif_variant'
drivers/media/platform/s3c-camif/camif-core.h:156: warning: Function parameter or member 'has_img_effect' not described in 's3c_camif_variant'
drivers/media/platform/s3c-camif/camif-core.h:156: warning: Function parameter or member 'vp_offset' not described in 's3c_camif_variant'
drivers/media/platform/s3c-camif/camif-core.h:232: warning: Function parameter or member 'vdev' not described in 'camif_vp'
drivers/media/platform/s3c-camif/camif-core.h:232: warning: Function parameter or member 'vb_queue' not described in 'camif_vp'
drivers/media/platform/s3c-camif/camif-core.h:232: warning: Function parameter or member 'offset' not described in 'camif_vp'
drivers/media/platform/s3c-camif/camif-core.h:297: warning: Function parameter or member 'ctrl_test_pattern' not described in 'camif_dev'
drivers/media/platform/s3c-camif/camif-core.h:297: warning: Function parameter or member 'ctrl_colorfx' not described in 'camif_dev'
drivers/media/platform/s3c-camif/camif-core.h:297: warning: Function parameter or member 'ctrl_colorfx_cbcr' not described in 'camif_dev'
drivers/media/platform/s3c-camif/camif-core.h:297: warning: Function parameter or member 'colorfx' not described in 'camif_dev'
drivers/media/platform/s3c-camif/camif-core.h:297: warning: Function parameter or member 'colorfx_cb' not described in 'camif_dev'
drivers/media/platform/s3c-camif/camif-core.h:297: warning: Function parameter or member 'colorfx_cr' not described in 'camif_dev'
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Give typo in kernel-doc documentation: hdr -> hrd
Fixes this warning:
drivers/media/platform/allegro-dvt/nal-h264.h:33: warning: expecting prototype for struct nal_h264_hdr_parameters. Prototype was for struct
nal_h264_hrd_parameters instead
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Reviewed-by: Michael Tretter <m.tretter@pengutronix.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add a helper to update SGX_LEPUBKEYHASHn MSRs. SGX virtualization also
needs to update those MSRs based on guest's "virtual" SGX_LEPUBKEYHASHn
before EINIT from guest.
Signed-off-by: Kai Huang <kai.huang@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Dave Hansen <dave.hansen@intel.com>
Acked-by: Jarkko Sakkinen <jarkko@kernel.org>
Link: https://lkml.kernel.org/r/dfb7cd39d4dd62ea27703b64afdd8bccb579f623.1616136308.git.kai.huang@intel.com
Add a helper to extract the fault indicator from an encoded ENCLS return
value. SGX virtualization will also need to detect ENCLS faults.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Kai Huang <kai.huang@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Jarkko Sakkinen <jarkko@kernel.org>
Acked-by: Dave Hansen <dave.hansen@intel.com>
Link: https://lkml.kernel.org/r/c1f955898110de2f669da536fc6cf62e003dff88.1616136308.git.kai.huang@intel.com
Define the ENCLS leafs that are available with SGX2, also referred to as
Enclave Dynamic Memory Management (EDMM). The leafs will be used by KVM
to conditionally expose SGX2 capabilities to guests.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Kai Huang <kai.huang@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Jarkko Sakkinen <jarkko@kernel.org>
Acked-by: Dave Hansen <dave.hansen@intel.com>
Link: https://lkml.kernel.org/r/5f0970c251ebcc6d5add132f0d750cc753b7060f.1616136308.git.kai.huang@intel.com
Move the ENCLS leaf definitions to sgx.h so that they can be used by
KVM.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Kai Huang <kai.huang@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Jarkko Sakkinen <jarkko@kernel.org>
Acked-by: Dave Hansen <dave.hansen@intel.com>
Link: https://lkml.kernel.org/r/2e6cd7c5c1ced620cfcd292c3c6c382827fde6b2.1616136308.git.kai.huang@intel.com
Expose SGX architectural structures, as KVM will use many of the
architectural constants and structs to virtualize SGX.
Name the new header file as asm/sgx.h, rather than asm/sgx_arch.h, to
have single header to provide SGX facilities to share with other kernel
componments. Also update MAINTAINERS to include asm/sgx.h.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Co-developed-by: Kai Huang <kai.huang@intel.com>
Signed-off-by: Kai Huang <kai.huang@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Jarkko Sakkinen <jarkko@kernel.org>
Acked-by: Dave Hansen <dave.hansen@intel.com>
Link: https://lkml.kernel.org/r/6bf47acd91ab4d709e66ad1692c7803e4c9063a0.1616136308.git.kai.huang@intel.com
Modify sgx_init() to always try to initialize the virtual EPC driver,
even if the SGX driver is disabled. The SGX driver might be disabled
if SGX Launch Control is in locked mode, or not supported in the
hardware at all. This allows (non-Linux) guests that support non-LC
configurations to use SGX.
[ bp: De-silli-fy the test. ]
Signed-off-by: Kai Huang <kai.huang@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Sean Christopherson <seanjc@google.com>
Acked-by: Jarkko Sakkinen <jarkko@kernel.org>
Acked-by: Dave Hansen <dave.hansen@intel.com>
Link: https://lkml.kernel.org/r/d35d17a02bbf8feef83a536cec8b43746d4ea557.1616136308.git.kai.huang@intel.com
The kernel will currently disable all SGX support if the hardware does
not support launch control. Make it more permissive to allow SGX
virtualization on systems without Launch Control support. This will
allow KVM to expose SGX to guests that have less-strict requirements on
the availability of flexible launch control.
Improve error message to distinguish between three cases. There are two
cases where SGX support is completely disabled:
1) SGX has been disabled completely by the BIOS
2) SGX LC is locked by the BIOS. Bare-metal support is disabled because
of LC unavailability. SGX virtualization is unavailable (because of
Kconfig).
One where it is partially available:
3) SGX LC is locked by the BIOS. Bare-metal support is disabled because
of LC unavailability. SGX virtualization is supported.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Co-developed-by: Kai Huang <kai.huang@intel.com>
Signed-off-by: Kai Huang <kai.huang@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Jarkko Sakkinen <jarkko@kernel.org>
Acked-by: Dave Hansen <dave.hansen@intel.com>
Link: https://lkml.kernel.org/r/b3329777076509b3b601550da288c8f3c406a865.1616136308.git.kai.huang@intel.com
Add a misc device /dev/sgx_vepc to allow userspace to allocate "raw"
Enclave Page Cache (EPC) without an associated enclave. The intended
and only known use case for raw EPC allocation is to expose EPC to a
KVM guest, hence the 'vepc' moniker, virt.{c,h} files and X86_SGX_KVM
Kconfig.
The SGX driver uses the misc device /dev/sgx_enclave to support
userspace in creating an enclave. Each file descriptor returned from
opening /dev/sgx_enclave represents an enclave. Unlike the SGX driver,
KVM doesn't control how the guest uses the EPC, therefore EPC allocated
to a KVM guest is not associated with an enclave, and /dev/sgx_enclave
is not suitable for allocating EPC for a KVM guest.
Having separate device nodes for the SGX driver and KVM virtual EPC also
allows separate permission control for running host SGX enclaves and KVM
SGX guests.
To use /dev/sgx_vepc to allocate a virtual EPC instance with particular
size, the hypervisor opens /dev/sgx_vepc, and uses mmap() with the
intended size to get an address range of virtual EPC. Then it may use
the address range to create one KVM memory slot as virtual EPC for
a guest.
Implement the "raw" EPC allocation in the x86 core-SGX subsystem via
/dev/sgx_vepc rather than in KVM. Doing so has two major advantages:
- Does not require changes to KVM's uAPI, e.g. EPC gets handled as
just another memory backend for guests.
- EPC management is wholly contained in the SGX subsystem, e.g. SGX
does not have to export any symbols, changes to reclaim flows don't
need to be routed through KVM, SGX's dirty laundry doesn't have to
get aired out for the world to see, and so on and so forth.
The virtual EPC pages allocated to guests are currently not reclaimable.
Reclaiming an EPC page used by enclave requires a special reclaim
mechanism separate from normal page reclaim, and that mechanism is not
supported for virutal EPC pages. Due to the complications of handling
reclaim conflicts between guest and host, reclaiming virtual EPC pages
is significantly more complex than basic support for SGX virtualization.
[ bp:
- Massage commit message and comments
- use cpu_feature_enabled()
- vertically align struct members init
- massage Virtual EPC clarification text
- move Kconfig prompt to Virtualization ]
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Co-developed-by: Kai Huang <kai.huang@intel.com>
Signed-off-by: Kai Huang <kai.huang@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Dave Hansen <dave.hansen@intel.com>
Acked-by: Jarkko Sakkinen <jarkko@kernel.org>
Link: https://lkml.kernel.org/r/0c38ced8c8e5a69872db4d6a1c0dabd01e07cad7.1616136308.git.kai.huang@intel.com
These two Makefiles contain only built-in objects (i.e. obj-y), which
are collected by $(AR) into a thin-archive.
EXTRA_LDFLAGS is meaningless because $(LD) is not used here.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Link: https://lore.kernel.org/r/20210331144336.25628-2-masahiroy@kernel.org
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Don't clear the timer 1 configuration bits when clearing the interrupt flag
and counter overflow. As Michael reported, "This results in no timer
interrupts being delivered after the first. Initialization then hangs
in calibrate_delay as the jiffies counter is not updated."
On mvme16x, enable the timer after requesting the irq, consistent with
mvme147.
Cc: Michael Pavone <pavone@retrodev.com>
Fixes: 7529b90d05 ("m68k: mvme147: Handle timer counter overflow")
Fixes: 19999a8b87 ("m68k: mvme16x: Handle timer counter overflow")
Reported-and-tested-by: Michael Pavone <pavone@retrodev.com>
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Link: https://lore.kernel.org/r/4fdaa113db089b8fb607f7dd818479f8cdcc4547.1617089871.git.fthain@telegraphics.com.au
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Many architectures duplicate similar shell scripts.
This commit converts m68k to use scripts/syscallhdr.sh.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Link: https://lore.kernel.org/r/20210301142112.342909-2-masahiroy@kernel.org
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Many architectures duplicate similar shell scripts.
This commit converts m68k to use scripts/syscalltbl.sh.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Link: https://lore.kernel.org/r/20210301142112.342909-1-masahiroy@kernel.org
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Detected a broken boot on mcf54415, likely introduced from
commit 4bfc848e09
("m68k/mm: enable use of generic memory_model.h for !DISCONTIGMEM")
Fix ARCH_PFN_OFFSET to be a pfn.
Signed-off-by: Angelo Dureghello <angelo@kernel-space.org>
Acked-by: Mike Rapoport <rppt@linux.ibm.com>
Link: https://lore.kernel.org/r/20210228190828.392974-1-angelo@kernel-space.org
Fixes: 4bfc848e09 ("m68k/mm: enable use of generic memory_model.h for !DISCONTIGMEM")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Instead of triggering an integer overflow and undefined behavior if MDTS is
large, set max_hw_sectors to UINT_MAX.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Keith Busch <kbusch@kernel.org>
[hch: rebased to account for the new nvme_mps_to_sectors helper]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Commands that access LBA contents without a data transfer between the
host historically have not had a spec defined upper limit. The driver
set the queue constraints for such commands to the max data transfer
size just to be safe, but this artificial constraint frequently limits
devices below their capabilities.
The NVMe Workgroup ratified TP4040 defines how a controller may
advertise their non-MDTS limits. Use these if provided and default to
the current constraints if not. Since the Dataset Management command
limits are defined in logical blocks, but without a namespace to tell us
the logical block size, the code defaults to the safe 512b size.
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
When a passthru command targets a specific namespace, the ns parameter to
nvme_user_cmd()/nvme_user_cmd64() is set. However, there is currently no
validation that the nsid specified in the passthru command targets the
namespace/nsid represented by the block device that the ioctl was
performed on.
Add a check that validates that the nsid in the passthru command matches
that of the supplied namespace.
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Reviewed-by: Javier González <javier@javigon.com>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Reviewed-by: Kanchan Joshi <joshi.k@samsung.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
If ANA is enabled but no ANA group descriptor is found when creating
a new namespace the ANA log is most likely out of date, so trigger
a re-read. The namespace will be tagged with the NS_ANA_PENDING flag
to exclude it from path selection until the ANA log has been re-read.
Fixes: 32acab3181 ("nvme: implement multipath access to nvme subsystems")
Reported-by: Martin George <marting@netapp.com>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Keith Busch <kbusch@kernel.org>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Use direct register operations instead of a table of register
information to lower the stack usage.
Signed-off-by: Steen Hegelund <steen.hegelund@microchip.com>
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/20210329141309.612459-2-steen.hegelund@microchip.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
When USB and USB_COMMON are not enabled, phy-mvebu-cp110-utmi
suffers a build error due to a missing interface that is provided
by CONFIG_USB_COMMON, so make the driver depend on USB_COMMON.
ld: drivers/phy/marvell/phy-mvebu-cp110-utmi.o: in function `mvebu_cp110_utmi_phy_probe':
phy-mvebu-cp110-utmi.c:(.text+0x152): undefined reference to `of_usb_get_dr_mode_by_phy'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Kostya Porotchkin <kostap@marvell.com>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Vinod Koul <vkoul@kernel.org>
Cc: linux-phy@lists.infradead.org
Link: https://lore.kernel.org/r/20210401210045.23525-1-rdunlap@infradead.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
intel_link_probe() could return error and dev_get_drvdata() will return
null in such case. So we have to test link->cdns after
link->cdns = dev_get_drvdata(&ldev->auxdev.dev);
Otherwise, we will meet the "kernel NULL pointer dereference" error.
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20210406010101.11442-1-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Looks like return from reg_write is set but not checked.
Fix this by adding error return path.
Reported-by: coverity-bot <keescook+coverity-bot@chromium.org>
Addresses-Coverity-ID: 1503591 ("UNUSED_VALUE")
Fixes: 128eaf937a ("soundwire: qcom: add support to missing transport params")
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210401091502.15825-1-srinivas.kandagatla@linaro.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Internally used portconfig array for storing port bandwidth
params starts from offset zero. However port zero is not really
used and we also copy the bus parameters to offset zero.
So basically we endup with a code which has to subtract 1 from port
number to get to port parameters.
This is bit confusing to the reader so, make this bit more obvious by only
copying the parameters to offset 1 instead of zero. This will avoid doing
-1 every time when we try to get port params.
Similar thing has been recently done with din/dout_port_mask.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20210401092454.21299-1-srinivas.kandagatla@linaro.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
If we write registers very fast we can endup in a situation where some
of the writes will be dropped without any notice.
So wait for the fifo space to be available before reading/writing the
soundwire registers.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20210401090058.24041-1-srinivas.kandagatla@linaro.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
SoundWire device ports are statically mapped to Controller ports during
design. Add support to read these from SoundWire devices.
This controller uses static port map info to setup bandwidth
parameters for those ports.
A generic port allocation is not possible in this cases!
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20210315165650.13392-4-srinivas.kandagatla@linaro.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
currently the internal bitmask used for allocating ports starts with offset 0.
This is bit confusing as data port numbers on Qualcomm controller are valid
from 1 to 14. So adjust this bit mask accordingly, this will also help while
adding static port map support.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20210315165650.13392-3-srinivas.kandagatla@linaro.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Some of the SoundWire device ports are statically mapped to Controller
ports during design, however there is no way to expose this information
to the controller. Controllers like Qualcomm ones use this info to setup
static bandwidth parameters for those ports.
A generic port allocation is not possible in this cases!
So this patch adds a new member m_port_map to struct sdw_slave to expose
this static map.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20210315165650.13392-2-srinivas.kandagatla@linaro.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
When stream config is failed, master runtime will release all
slave runtime in the slave_rt_list, but slave runtime is not
added to the list at this time. This patch frees slave runtime
in the config error path to fix the memory leak.
Fixes: 89e590535f ("soundwire: Add support for SoundWire stream management")
Signed-off-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Keyon Jie <yang.jie@intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20210331004610.12242-1-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
