summaryrefslogtreecommitdiff
path: root/drivers/staging/media/atomisp/i2c/imx
AgeCommit message (Collapse)Author
2017-11-02License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-08-26media: staging: atomisp: imx: remove dead codeArnd Bergmann
Making some functions 'static' has uncovered a few functions that have no caller, through the gcc warnings: atomisp/i2c/imx/imx.c:1111:12: error: 'imx_t_focus_vcm' defined but not used [-Werror=unused-function] atomisp/i2c/imx/imx.c:1103:12: error: 'imx_vcm_init' defined but not used [-Werror=unused-function] atomisp/i2c/imx/imx.c:1095:12: error: 'imx_vcm_power_down' defined but not used [-Werror=unused-function] atomisp/i2c/imx/imx.c:1087:12: error: 'imx_vcm_power_up' defined but not used [-Werror=unused-function] All four of these can be removed. Since they call indirect functions, I also looked at how those are used in turn: - The power_up/power_down callbacks are called from other functions and are still needed. - The t_focus_vcm callbacks pointers are completely unused and can be removed in both imx and ov8858. Some of the handlers are called directly and can now be marked static, the others are dummy implemntations that we can remove. - vcm_init is unused in imx, but dw9718_vcm_init is used in ov8858, but is not used in imx, so that one needs to stay around. The callback pointers in imx can be removed. Fixes: 9a5a6911aa3f ("staging: imx: fix non-static declarations") 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@s-opensource.com>
2017-08-08media: staging: imx: fix non-static declarationsJB Van Puyvelde
Add static keywords to fix this kind of sparse warnings: warning: symbol 'imx_t_vcm_timing' was not declared. Should it be static? Signed-off-by: JB Van Puyvelde <jbvanpuyvelde@gmail.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2017-07-26media: atomisp2: array underflow in imx_enum_frame_size()Dan Carpenter
The code looks in imx_enum_frame_size() looks like this: 2066 int index = fse->index; 2067 struct imx_device *dev = to_imx_sensor(sd); 2068 2069 mutex_lock(&dev->input_lock); 2070 if (index >= dev->entries_curr_table) { 2071 mutex_unlock(&dev->input_lock); 2072 return -EINVAL; 2073 } 2074 2075 fse->min_width = dev->curr_res_table[index].width; "fse->index" is a u32 that comes from the user. We want negative values of "index" to be -EINVAL so we don't read before the start of the dev->curr_res_table[] array. I've made "entries_curr_table" unsigned long to fix this. I thought about making it unsigned int, but because of struct alignment, it doesn't use more memory either way. Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2017-06-08[media] atomisp: use correct dialect to disable warningsMauro Carvalho Chehab
There's a Macro that checks if gcc supports a warning before disabling it. Use it, in order to avoid warnings when building with older gcc versions. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2017-05-19[media] atomisp: disable several warnings when W=1Mauro Carvalho Chehab
The atomisp currently produce hundreds of warnings when W=1. It is a known fact that this driver is currently in bad shape, and there are lot of things to be done here. We don't want to be bothered by those "minor" stuff for now, while the driver doesn't receive a major cleanup. So, disable those warnings. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2017-05-18[media] atomisp: don't treat warnings as errorsMauro Carvalho Chehab
Several atomisp files use: ccflags-y += -Werror As, on media, our usual procedure is to use W=1, and atomisp has *a lot* of warnings with such flag enabled,like: ./drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/system_local.h:62:26: warning: 'DDR_BASE' defined but not used [-Wunused-const-variable=] At the end, it causes our build to fail, impacting our workflow. So, remove this crap. If one wants to force -Werror, he can still build with it enabled by passing a parameter to make. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2017-03-21atomisp/imx: Fix locking bug on error pathAlan Cox
This was reported by Dan Carpenter. When we error with an IMX 227 we don't release the lock and the sensor would then hang. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-16Staging: atomisp: kfreeing a devm allocated pointerDan Carpenter
We shouldn't pass devm allocated pointers to kfree() or it leads to a double free. Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-07staging: atomisp: fix include Makefile messGreg Kroah-Hartman
Using LINUXINCLUDE is a very old hack, and doesn't play well with building objects in a different directory than the kernel source is in. So fix up the include file references to be relative to make it obvious we are pulling in local include files, which need to get fixed up. Reported-by: kbuild test robot <fengguang.wu@intel.com> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-06atomisp: fix __udiv warningAlan Cox
Certain combinations of compiler and compiler options product an imx.o that calls compiler helpers for a u64 divide. Use the do_div() call instead. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-06staging/atomisp: fix platform_no_drv_owner.cocci warningskbuild test robot
drivers/staging/media/atomisp/i2c/imx/imx.c:2486:3-8: No need to set .owner here. The core will do it. Remove .owner field if calls are used which set it automatically Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-06staging/atomisp: Add support for the Intel IPU v2Alan Cox
This patch adds support for the Intel IPU v2 as found on Android and IoT Baytrail-T and Baytrail-CR platforms (those with the IPU PCI mapped). You will also need the firmware files from your device (Android usually puts them into /etc) - or you can find them in the downloadable restore/upgrade kits if you blew them away for some reason. It may be possible to extend the driver to handle the BYT/T windows platforms such as the ASUS T100TA. These platforms don't expose the IPU via the PCI interface but via ACPI buried in the GPU description and with the camera information somewhere unknown so would need a platform driver interface adding to the codebase *IFF* the firmware works on such devices. To get good results you also need a suitable support library such as libxcam. The camera is intended to be driven from Android so it has a lot of features that many desktop apps don't fully spport. In theory all the pieces are there to build it with -DISP2401 and some differing files to get CherryTrail/T support, but unifying the drivers properlly is a work in progress. The IPU driver represents the work of a lot of people within Intel over many years. It's historical goal was portability rather than Linux upstream. Any queries about the upstream aimed driver should be sent to me not to the original authors. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>