summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-12-07staging: rtl8723bs: replace RTW_IEEE80211_ADDBA_PARAM_BUF_SIZE_MASKRoss Schmidt
Replace unique macro RTW_IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK with kernel provided IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK. The other IEEE80211_ADDBA_* and IEEE_DELBA_* macros are duplicates already defined in linux/ieee80211.h, remove them. Signed-off-by: Ross Schmidt <ross.schm.dev@gmail.com> Link: https://lore.kernel.org/r/20201206034517.4276-7-ross.schm.dev@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-07staging: rtl8723bs: remove WLAN_HT_CAP_SM_PS_* macrosRoss Schmidt
The WLAN_HT_CAP_SM_PS_* macro family is already defined in linux/ieee80211.h, remove them. Signed-off-by: Ross Schmidt <ross.schm.dev@gmail.com> Link: https://lore.kernel.org/r/20201206034517.4276-6-ross.schm.dev@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-07staging: rtl8723bs: replace OP_MODE_* and HT_INFO_OPERATION_MODE_* macrosRoss Schmidt
Replace unique OP_MODE_* and HT_INFO_OPERATION_MODE_* macro families with kernel provided IEEE80211_HT_OP_MODE_* macros. Signed-off-by: Ross Schmidt <ross.schm.dev@gmail.com> Link: https://lore.kernel.org/r/20201206034517.4276-5-ross.schm.dev@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-07staging: rtl8723bs: replace HT_CAP_AMPDU_FACTORRoss Schmidt
Replace unique HT_CAP_AMPDU_FACTOR enum with kernel provided ieee80211_max_ampdu_length_exp enum. Signed-off-by: Ross Schmidt <ross.schm.dev@gmail.com> Link: https://lore.kernel.org/r/20201206034517.4276-4-ross.schm.dev@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-07staging: rtl8723bs: replace cap_* macrosRoss Schmidt
Replace unique cap_* macros with kernel provided WLAN_CAPABILITY_* macros. Signed-off-by: Ross Schmidt <ross.schm.dev@gmail.com> Link: https://lore.kernel.org/r/20201206034517.4276-3-ross.schm.dev@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-07staging: rtl8723bs: replace WIFI_REASON_CODERoss Schmidt
Replace unique macros and WIFI_REASON_CODE enum with the kernel provided ieee80211_reasoncode. Signed-off-by: Ross Schmidt <ross.schm.dev@gmail.com> Link: https://lore.kernel.org/r/20201206034517.4276-2-ross.schm.dev@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-07staging: rtl8723bs: replace unique macros and WIFI_STATUS_CODERoss Schmidt
Replace many unique macros and WIFI_STATUS_CODE enum with kernel provided ieee80211_statuscode. A duplicate WLAN_STATUS_ASSOC_DENIED_NOSHORT macro is also removed. Signed-off-by: Ross Schmidt <ross.schm.dev@gmail.com> Link: https://lore.kernel.org/r/20201206034517.4276-1-ross.schm.dev@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-07staging: greybus: audio: Fix possible leak free widgets in ↵Wang Hai
gbaudio_dapm_free_controls In gbaudio_dapm_free_controls(), if one of the widgets is not found, an error will be returned directly, which will cause the rest to be unable to be freed, resulting in leak. This patch fixes the bug. If if one of them is not found, just skip and free the others. Fixes: 510e340efe0c ("staging: greybus: audio: Add helper APIs for dynamic audio module") Reported-by: Hulk Robot <hulkci@huawei.com> Reviewed-by: Vaibhav Agarwal <vaibhav.sr@gmail.com> Signed-off-by: Wang Hai <wanghai38@huawei.com> Link: https://lore.kernel.org/r/20201205103827.31244-1-wanghai38@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-07staging: mt7621-pinctrl: stop using the deprecated 'pinctrl_add_gpio_range'Sergio Paracuellos
If the gpio DT node has the 'gpio-ranges' property, the range will be added by the gpio core and doesn't need to be added by the pinctrl driver. By having the gpio-ranges property, we can map every pin between gpio node and pinctrl node and we can stop using the deprecated pinctrl_add_gpio_range() function. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Link: https://lore.kernel.org/r/20201206105333.18428-1-sergio.paracuellos@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-07Staging: rtl8723bs/core: add blank line after declarationsBrother Matthew De Angelis
Fix coding style issue. Add blank line after variable declarations at all the locations found by checkpatch.pl. Signed-off-by: Brother Matthew De Angelis <matthew.v.deangelis@gmail.com> Link: https://lore.kernel.org/r/20201206025945.GA464875@a Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-07Staging: rtl8723bs/core: fix brace coding style issueBrother Matthew De Angelis
Remove unnecessary braces identified by checkpatch.pl at lines 740, 1039,1602,1922,1939. Signed-off-by: Brother Matthew De Angelis <matthew.v.deangelis@gmail.com> Link: https://lore.kernel.org/r/8ddd195a246696e9315dacfcce06b7ba7f9d7d1a.1607209336.git.matthew.v.deangelis@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-07Staging: rtl8723bs/core: delete empty if statementBrother Matthew De Angelis
Delete an if statement that was not executing anything when true. This has the side effect of removing one checkpatch warning about braces not being necessary. Signed-off-by: Brother Matthew De Angelis <matthew.v.deangelis@gmail.com> Link: https://lore.kernel.org/r/1895dc8a7b44bfdcb6a46273703fabad80cbdf99.1607209336.git.matthew.v.deangelis@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-07media: vivid: fix 'disconnect' error injectionHans Verkuil
The 'disconnect' error injection functionality suffered from bit rot. New device nodes were added without updating vivid_user_gen_s_ctrl(), so that function had to be updated for the new device nodes. Also, vivid didn't check if specific device nodes were actually ever created, so the vivid_is_last_user() would fail on that (it would return true instead of false in that case). Finally, selecting Disconnect, then unbind the vivid driver would fail since the remove() would think that the device nodes were already unregistered. Keep track of whether disconnect was pressed and re-register the device nodes in remove() before doing the real unregister. [hverkuil: unsigned uses -> unsigned int uses] Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-07staging: bcm2835: fix vchiq_mmal dependenciesArnd Bergmann
When the MMAL code is built-in but the vchiq core config is set to =m, the mmal code never gets built, which in turn can lead to link errors: ERROR: modpost: "vchiq_mmal_port_set_format" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! ERROR: modpost: "vchiq_mmal_port_disable" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! ERROR: modpost: "vchiq_mmal_port_parameter_set" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! ERROR: modpost: "vchiq_mmal_component_finalise" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! ERROR: modpost: "vchiq_mmal_port_connect_tunnel" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! ERROR: modpost: "vchiq_mmal_component_enable" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! ERROR: modpost: "vchiq_mmal_finalise" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! ERROR: modpost: "vchiq_mmal_component_init" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! ERROR: modpost: "vchiq_mmal_component_disable" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! ERROR: modpost: "mmal_vchi_buffer_init" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! ERROR: modpost: "vchiq_mmal_port_enable" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! ERROR: modpost: "vchiq_mmal_version" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! ERROR: modpost: "vchiq_mmal_submit_buffer" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! ERROR: modpost: "vchiq_mmal_init" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! ERROR: modpost: "mmal_vchi_buffer_cleanup" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! ERROR: modpost: "vchiq_mmal_port_parameter_get" [drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined! Change the Kconfig to depend on BCM2835_VCHIQ like the other drivers, and remove the now redundant dependencies. Fixes: b18ee53ad297 ("staging: bcm2835: Break MMAL support out from camera") Acked-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20201203223836.1362313-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-07media: rcar-vin: Mask VNCSI_IFMD registerJacopo Mondi
The VNCSI_IFMD register controls the data expansion mode and the channel routing between the CSI-2 receivers and VIN instances. According to the chip manual revision 2.20 not all fields are available for all the SoCs: - V3M, V3H and E3 do not support the DES1 field has they do not feature a CSI20 receiver. - D3 only supports parallel input, and the whole register shall always be written as 0. Inspect the per-SoC channel routing table where the available CSI-2 instances are reported and configure VNCSI_IFMD accordingly. This patch supports this BSP change commit: https://github.com/renesas-rcar/linux-bsp/commit/f54697394457 ("media: rcar-vin: Fix VnCSI_IFMD register access for r8a77990") [hverkuil: replace BSP commit ID with BSP URL] Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Suggested-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-07media: MAINTAINERS: Add myself as maintainer of the Amlogic GE2D driverNeil Armstrong
Add new entry to MAINTAINERS. [hverkuil: added changelog] Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-07media: meson: Add M2M driver for the Amlogic GE2D Accelerator UnitNeil Armstrong
The GE2D is a 2D accelerator with various features like configurable blitter with alpha blending, frame rotation, scaling, format conversion and colorspace conversion. The driver implements a Memory2Memory VB2 V4L2 streaming device permitting: - 0, 90, 180, 270deg rotation - horizontal/vertical flipping - source cropping - destination compositing - 32bit/24bit/16bit format conversion This adds the support for the GE2D version found in the AXG SoCs Family. The missing features are: - Source scaling - Colorspace conversion - Advanced alpha blending & blitting options Is passes v4l2-compliance: SHA: ea16a7ef13a902793a5c2626b0cefc4d956147f3, 64 bits, 64-bit time_t [hverkuil: add missing linux/bitfield.h include] Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-07media: dt-bindings: media: Add bindings for the Amlogic GE2D Accelerator UnitNeil Armstrong
The GE2D is a 2D accelerator with various features like configurable blitter with alpha blending, frame rotation, scaling, format conversion and colorspace conversion. This adds the bindings for the GE2D version found in the AXG SoCs Family. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-07media: cedrus: Make VP8 codec as capabilityJernej Skrabec
Commit 31d9b9ef8564 ("media: cedrus: Register all codecs as capability") makes separate capability flags for each codec. However, VP8 codec was merged at the same time as mentioned patch, so there is no capability flag for it. This patch adds capability flag for VP8 and enables it for all variants except for V3s. Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-07media: gspca: Fix memory leak in probeAlan Stern
The gspca driver leaks memory when a probe fails. gspca_dev_probe2() calls v4l2_device_register(), which takes a reference to the underlying device node (in this case, a USB interface). But the failure pathway neglects to call v4l2_device_unregister(), the routine responsible for dropping this reference. Consequently the memory for the USB interface and its device never gets released. This patch adds the missing function call. Reported-and-tested-by: syzbot+44e64397bd81d5e84cba@syzkaller.appspotmail.com Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: <stable@vger.kernel.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-07media: doc: pixfmt-yuv: Move all planar YUV formats to common fileLaurent Pinchart
Planar pixel formats are documented in separate files. This duplicates information, as those formats share comon traits. Consolidate them in a single file and summarize their descriptions in a single table. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-07media: doc: pixfmt-yuv: Move all semi-planar YUV formats to common fileLaurent Pinchart
Semi-planar pixel formats are documented in separate files. This duplicates information, as those formats share comon traits. Consolidate them in a single file and summarize their descriptions in a single table. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-07media: doc: pixfmt-yuv: Move all luma-only YUV formats to common fileLaurent Pinchart
Luma-only pixel formats are documented in separate files. This duplicates information, as those formats share comon traits. Consolidate them in a single file and describe them in a single table. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-07media: doc: pixfmt-packed-yuv: Clarify naming scheme for 4:4:4 formatsLaurent Pinchart
Document the naming scheme for the existing packed YUV 4:4:4 formats, as previously done for the RGB formats. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-07media: doc: pixfmt-packed-yuv: Express 4:4:4 formats in a more compact wayLaurent Pinchart
The 4:4:4 packed YUV formats are documented with a bit-level representation, which creates a wide table. Switch to a byte-oriented representation to make it more compact. This prepares for the addition of formats with more than 8 bits per component, that would make the table way too wide. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-07media: doc: pixfmt-packed-yuv: Fill padding bits with 'X'Laurent Pinchart
The padding bits are left blank, which look weird in the XYUV format, and, worse, may lead to the VUYX format to be understand as consuming 3 bytes per pixel. Add 'X' for padding bits as we do for RGB formats. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-07media: doc: pixfmt-yuv: Move all packed YUV formats to common fileLaurent Pinchart
The pixfmt-packed-yuv.rst file documents packed YUV 4:4:4 formats, but is titled generically as "Packed YUV formats". 4:2:2 and 4:1:1 packed YUV formats are documented in separate files, which can be confusing. Group all packed YUV formats in pixfmt-packed-yuv.rst, which allows documenting the 4:2:2 formats in a more concise way. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-07media: doc: pixfmt-yuv: Document subsampling in more detailsLaurent Pinchart
Document YUV subsampling, including chroma spatial siting, and replace the siting examples in individual formats by references to the common documentation. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-07media: doc: pixfmt-rgb: Replace '-' with 'X' to denote paddingLaurent Pinchart
Using '-' to represent padding bits and bytes make text and tables more difficult to read. Use 'x' and 'X' instead. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-07media: doc: pixfmt-rgb: Make 8 bits per component table more compactLaurent Pinchart
All formats using 8 bits per component can be described with a byte granularity instead of a bit granularity without loss of precision. This makes the corresponding table more compact and easier to read. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-07media: doc: pixfmt-rgb: Clarify naming scheme for RGB formatsLaurent Pinchart
The naming scheme for the RGB pixel formats has been developed organically, and isn't consistent between formats using less than 8 bits per pixels (mostly stored in 1 or 2 bytes per pixel, except for RGB666 that uses 4 bytes per pixel) and formats with 8 bits per pixel (stored in 3 or 4 bytes). For the latter category, the names use a components order convention that is the opposite of the first category, and the opposite of DRM pixel formats. This has led to lots of confusion in the past, and would really benefit from being explained more precisely. Do so, which also prepares for the addition of additional RGB pixels formats. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-07media: doc: pixfmt-rgb: Add title for deprecated formatsLaurent Pinchart
Improve readability of the documentation by adding a section title for the deprecated formats. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-07media: doc: pixfmt-rgb: Remove layout table for packed RGB formatsLaurent Pinchart
The packed RGB formats documentation includes a layout table without any context. This doesn't bring much useful information, and is confusing at best. Remove it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-07media: videodev2.h: Move HM12 format to YUV semi-planar sectionLaurent Pinchart
V4L2_PIX_FMT_HM12 is a YUV semi-planar macro-block format. Move it from the packed YUV formats section where it was misplaced to the YUV semi-planar formats section. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-07media: videodev2.h: Move HI240 format to vendor-specific sectionLaurent Pinchart
V4L2_PIX_FMT_HI240 is a 8-bit dithered RGB format specific to BTTV. Move it from the packed YUV formats section where it was misplaced to the vendor-specific formats section. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-07media: videodev2.h: Remove unneeded comment about 4CC valueLaurent Pinchart
The V4L2_PIX_FMT_BGRA444 format has a comment that explains why its 4CC value is GA12. This explains the development history and isn't of much interest to readers, it should have been part of a commit message instead. Drop the comment, anyone interested in history can turn to git. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-07media: ccs: Fix return value from probeSakari Ailus
rval wasn't set, resulting in probe returning zero instead of an error. Fixes: de10c1619c48 ("[media] smiapp: Get clock rate if it's not available through DT") Reported-by: Zhang Changzhong <zhangchangzhong@huawei.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-07media: ccs: avoid printing an uninitialized variableArnd Bergmann
There is no intialization for the 'reg' variable, so printing it produces undefined behavior as well as a compile-time warning: drivers/media/i2c/ccs/ccs-core.c:314:49: error: variable 'reg' is uninitialized when used here [-Werror,-Wuninitialized] "0x%8.8x %s pixels: %d %s (pixelcode %u)\n", reg, Remove the variable and stop printing it. Fixes: fd9065812c7b ("media: smiapp: Obtain frame descriptor from CCS limits") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-07media: i2c: fix an uninitialized error codeArnd Bergmann
Clang points out that the error handling in ov02a10_s_stream() is broken, and just returns a random error code: drivers/media/i2c/ov02a10.c:537:6: warning: variable 'ret' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized] if (ov02a10->streaming == on) ^~~~~~~~~~~~~~~~~~~~~~~~ drivers/media/i2c/ov02a10.c:568:9: note: uninitialized use occurs here return ret; ^~~ drivers/media/i2c/ov02a10.c:537:2: note: remove the 'if' if its condition is always false if (ov02a10->streaming == on) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If streaming is already on, leave it that way and return success. Suggested-by: Dongchun Zhu <dongchun.zhu@mediatek.com> Fixes: 91807efbe8ec ("media: i2c: add OV02A10 image sensor driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-07media: Revert "media: dt-bindings: media: Use OF graph schema"Sakari Ailus
This reverts commit f61eb7bc9256aeb173d2d730f59cdd569d261c52. While aligning with the OF graph schema will be done for the media DT bindings, this patch got merged a little too hastily. Revert it for now. Suggested-by: Rob Herring <robh@kernel.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-07media: rc: add keymap for pine64 remoteJonas Karlman
Add a keymap for the pine64 IR remote [0]. The mouse key has been mapped to KEY_EPG to provide a more useful remote. [0] http://files.pine64.org/doc/Pine%20A64%20Schematic/remote-wit-logo.jpg Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-12-07x86/alternative: Update text_poke_bp() kernel-doc commentQiujun Huang
Update kernel-doc parameter name after c3d6324f841b ("x86/alternatives: Teach text_poke_bp() to emulate instructions") changed the last parameter from @handler to @emulate. [ bp: Make commit message more precise. ] Signed-off-by: Qiujun Huang <hqjagain@gmail.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20201203145020.2441-1-hqjagain@gmail.com
2020-12-07EDAC/mv64x60: Remove orphan mv64x60 driverMichael Ellerman
The mv64x60 EDAC driver depends on CONFIG_MV64X60. But that symbol is not user-selectable, and the last code that selected it was removed with the C2K board support in 2018, see: 92c8c16f3457 ("powerpc/embedded6xx: Remove C2K board support") That means the driver is now dead code, so remove it. Suggested-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20201207040253.628528-1-mpe@ellerman.id.au
2020-12-07EDAC/aspeed: Add support for AST2400 and AST2600Troy Lee
Add AST2400 and AST2600 EDAC driver support. Signed-off-by: Troy Lee <troy_lee@aspeedtech.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Stefan Schaeckeler <sschaeck@cisco.com> Link: https://lkml.kernel.org/r/20201207090013.14145-3-troy_lee@aspeedtech.com
2020-12-07ARM: dts: aspeed: Add AST2600 EDAC into common devicetreeTroy Lee
Add Aspeed AST2600 EDAC node into the common devicetree. Signed-off-by: Troy Lee <troy_lee@aspeedtech.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Joel Stanley <joel@jms.id.au> Link: https://lkml.kernel.org/r/20201207090013.14145-2-troy_lee@aspeedtech.com
2020-12-07dt-bindings: edac: aspeed-sdram-edac: Add ast2400/ast2600 supportTroy Lee
Add Aspeed AST2400 and AST2600 binding for the Aspeed EDAC driver. Signed-off-by: Troy Lee <troy_lee@aspeedtech.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Joel Stanley <joel@jms.id.au> Link: https://lkml.kernel.org/r/20201207090013.14145-1-troy_lee@aspeedtech.com
2020-12-07iommu/amd: Set DTE[IntTabLen] to represent 512 IRTEsSuravee Suthikulpanit
According to the AMD IOMMU spec, the commit 73db2fc595f3 ("iommu/amd: Increase interrupt remapping table limit to 512 entries") also requires the interrupt table length (IntTabLen) to be set to 9 (power of 2) in the device table mapping entry (DTE). Fixes: 73db2fc595f3 ("iommu/amd: Increase interrupt remapping table limit to 512 entries") Reported-by: Jerry Snitselaar <jsnitsel@redhat.com> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Link: https://lore.kernel.org/r/20201207091920.3052-1-suravee.suthikulpanit@amd.com Signed-off-by: Will Deacon <will@kernel.org>
2020-12-07MAINTAINERS: Update m68k Mac entryFinn Thain
Two files under drivers/macintosh are actually m68k-only. I think that patches for these files should be reviewed in the appropriate forum and merged via the appropriate tree, rather than falling to the powerpc maintainers to deal with. Update the "M68K ON APPLE MACINTOSH" section accordingly. Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Joshua Thompson <funaho@jurai.org> Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-m68k@lists.linux-m68k.org Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Acked-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/fbac2cd8632bb719f48cd1368910abd310548a0e.1607139987.git.fthain@telegraphics.com.au Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2020-12-07macintosh/adb-iop: Send correct poll commandFinn Thain
The behaviour of the IOP firmware is not well documented but we do know that IOP message reply data can be used to issue new ADB commands. Use the message reply to better control autopoll behaviour by sending a Talk Register 0 command after every ADB response, not unlike the algorithm in the via-macii driver. This poll command is addressed to that device which last received a Talk command (explicit or otherwise). Cc: Joshua Thompson <funaho@jurai.org> Fixes: 32226e817043 ("macintosh/adb-iop: Implement idle -> sending state transition") Tested-by: Stan Johnson <userm57@yahoo.com> Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Link: https://lore.kernel.org/r/58bba4310da4c29b068345a4b36af8a531397ff7.1605847196.git.fthain@telegraphics.com.au Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2020-12-07macintosh/adb-iop: Always wait for reply message from IOPFinn Thain
A recent patch incorrectly altered the adb-iop state machine behaviour and introduced a regression that can appear intermittently as a malfunctioning ADB input device. This seems to be caused when reply packets from different ADB commands become mixed up, especially during the adb bus scan. Fix this by unconditionally entering the awaiting_reply state after sending an explicit command, even when the ADB command won't generate a reply from the ADB device. It turns out that the IOP always generates reply messages, even when the ADB command does not produce a reply packet (e.g. ADB Listen command). So it's not really the ADB reply packets that are being mixed up, it's the IOP messages that enclose them. The bug goes like this: 1. CPU sends a message to the IOP, expecting no response because this message contains an ADB Listen command. The ADB command is now considered complete. 2. CPU sends a second message to the IOP, this time expecting a response because this message contains an ADB Talk command. This ADB command needs a reply before it can be completed. 3. adb-iop driver receives an IOP message and assumes that it relates to the Talk command. It's actually an empty one (with flags == ADB_IOP_EXPLICIT|ADB_IOP_TIMEOUT) for the previous command. The Talk command is now considered complete but it gets the wrong reply data. 4. adb-iop driver gets another IOP response message, which contains the actual reply data for the Talk command, but this is dropped (the driver is no longer in awaiting_reply state). Cc: Joshua Thompson <funaho@jurai.org> Fixes: e2954e5f727f ("macintosh/adb-iop: Implement sending -> idle state transition") Tested-by: Stan Johnson <userm57@yahoo.com> Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Link: https://lore.kernel.org/r/0f0a25855391e7eaa53a50f651aea0124e8525dd.1605847196.git.fthain@telegraphics.com.au Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
generated by cgit (git 2.34.1) at 2025-09-17 02:54:05 +0000