Re: [PATCH v8] staging: vt6656: add error code handling to unused variable
On 03/31/20 02:01:03, Stefano Brivio wrote: > On Mon, 30 Mar 2020 16:39:00 -0700 > "John B. Wyatt IV" wrote: > > > Add error code handling to unused 'ret' variable that was never used. > > Return an error code from functions called within vnt_radio_power_on. > > > > Issue reported by coccinelle (coccicheck). > > > > Suggested-by: Quentin Deslandes > > Suggested-by: Stefano Brivio > > Reviewed-by: Quentin Deslandes > ^ This should be dropped unless Quentin agrees to this version as well > > > Signed-off-by: John B. Wyatt IV > > Reviewed-by: Stefano Brivio > > -- > Stefano > Just reviewed it so John doesn't need to send a v9. Everything seems good, I'm happy and checkpatch is too. Reviewed-by: Quentin Deslandes Thanks, Quentin ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: vt6656: Use defines in vnt_mac_reg_bits_* functions
On Sat, Mar 28, 2020 at 10:54:33AM +0100, Oscar Carter wrote:
> Define the necessary bits in the CHANNEL, PAPEDELAY and GPIOCTL0
> registers to can use them in the calls to vnt_mac_reg_bits_on and
> vnt_mac_reg_bits_off functions. In this way, avoid the use of BIT()
> macros and clarify the code.
>
> Fixes: 3017e587e368 ("staging: vt6656: Use BIT() macro in vnt_mac_reg_bits_*
> functions")
> Suggested-by: Dan Carpenter
> Signed-off-by: Oscar Carter
> ---
> drivers/staging/vt6656/baseband.c | 6 --
> drivers/staging/vt6656/card.c | 3 +--
> drivers/staging/vt6656/mac.h | 12
> drivers/staging/vt6656/main_usb.c | 2 +-
> 4 files changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/vt6656/baseband.c
> b/drivers/staging/vt6656/baseband.c
> index a19a563d8bcc..dd3c3bf5e8b5 100644
> --- a/drivers/staging/vt6656/baseband.c
> +++ b/drivers/staging/vt6656/baseband.c
> @@ -442,7 +442,8 @@ int vnt_vt3184_init(struct vnt_private *priv)
> if (ret)
> goto end;
>
> - ret = vnt_mac_reg_bits_on(priv, MAC_REG_PAPEDELAY, BIT(0));
> + ret = vnt_mac_reg_bits_on(priv, MAC_REG_PAPEDELAY,
> + PAPEDELAY_B0);
This doesn't clarify anything. It makes it less clear because someone
would assume B0 means something but it's just hiding a magic number
behind a meaningless define. B0 means BIT(0) which means nothing. So
now we have to jump through two hoops to find out that we don't know
anything.
Just leave it as-is. Same for the rest.
There problem is a hardware spec which explains what this stuff is.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: vt6656: Define EnCFG_BBType_MASK as OR between previous defines
Thanks! Reviewed-by: Dan Carpenter regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: vt6656: Use BIT() macro in vnt_mac_reg_bits_* functions
On Thu, Mar 26, 2020 at 06:10:43PM +0100, Oscar Carter wrote: > I will make these changes and i will send and incremental patch with the > "Fixes:" tag due to the this patch has already been added to the staging-next > branch of the greg staging tree. Fixes is only for bug fixes, not style issues. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[staging:staging-testing 278/280] drivers/most/core.c:1287 most_register_interface() error: we previously assumed 'iface' could be null (see line 1285)
Hi Christian,
First bad commit (maybe != root cause):
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
staging-testing
head: 4a1a3e9bf5654e98bb48f5b074af17af96ded30d
commit: b276527539188f1f61c082ebef27803db93e536d [278/280] staging: most: move
core files out of the staging area
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
Reported-by: Dan Carpenter
smatch warnings:
drivers/most/core.c:1287 most_register_interface() error: we previously assumed
'iface' could be null (see line 1285)
#
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?id=b276527539188f1f61c082ebef27803db93e536d
git remote add staging
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
git remote update staging
git checkout b276527539188f1f61c082ebef27803db93e536d
vim +/iface +1287 drivers/most/core.c
4d5f022f3a664e drivers/staging/most/core.c Christian Gromm
2017-11-21 1279 int most_register_interface(struct most_interface *iface)
57562a72414ca3 drivers/staging/most/mostcore/core.c Christian Gromm
2015-07-24 1280 {
57562a72414ca3 drivers/staging/most/mostcore/core.c Christian Gromm
2015-07-24 1281unsigned int i;
57562a72414ca3 drivers/staging/most/mostcore/core.c Christian Gromm
2015-07-24 1282int id;
fcb7fad82e23f6 drivers/staging/most/core.c Christian Gromm
2017-11-21 1283struct most_channel *c;
57562a72414ca3 drivers/staging/most/mostcore/core.c Christian Gromm
2015-07-24 1284
57562a72414ca3 drivers/staging/most/mostcore/core.c Christian Gromm
2015-07-24 @1285if (!iface || !iface->enqueue || !iface->configure ||
^^
57562a72414ca3 drivers/staging/most/mostcore/core.c Christian Gromm
2015-07-24 1286!iface->poison_channel || (iface->num_channels >
MAX_CHANNELS)) {
6a82c775812944 drivers/staging/most/core.c Christian Gromm
2020-01-23 @1287dev_err(iface->dev, "Bad interface or channel
overflow\n");
^^
Hopefully, we can just remove the NULL check?
4d5f022f3a664e drivers/staging/most/core.c Christian Gromm
2017-11-21 1288return -EINVAL;
57562a72414ca3 drivers/staging/most/mostcore/core.c Christian Gromm
2015-07-24 1289}
57562a72414ca3 drivers/staging/most/mostcore/core.c Christian Gromm
2015-07-24 1290
57562a72414ca3 drivers/staging/most/mostcore/core.c Christian Gromm
2015-07-24 1291id = ida_simple_get(&mdev_id, 0, 0, GFP_KERNEL);
57562a72414ca3 drivers/staging/most/mostcore/core.c Christian Gromm
2015-07-24 1292if (id < 0) {
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v4 00/33] Media Kconfig menu reorg and improvements
The media Kconfig menu is complex. From time to time, it requires some improvements. This series is organized on two parts: 1. Patches 1 to 19: cleanups and improvements; - Try to be smarter when selecting features. So, auto-select Cypress firmware support on drivers that use it. Also, auto-select Media Controller and V4L2 subdevice API for devices that won't work without such features. Please notice that some drivers have can work optionally with those features enabled (or not). For those, users should still explicitly enable such features. - Platform and test drivers have now an option at the device support selection; - The test drivers are not platform drivers. They deserve their own directory. When a test driver is selected, the needed API support will be automatically selected. - Do some Kconfig reorg, in order to keep the main media Kconfig as clean as possible. - The help messafe for media support was outdated; - The ddbridge driver was abusing at the dvb dummy frontend driver (meant to be just an example). It will now have its own internal dummy driver, as the original one will soon receive more code and become a virtual driver. - There's a longstanding issue with hybrid TV devices: for an hybrid device to work, *both* analog and digital TV would need to be selected. As the Kconfig language improved, we can now address it. So, selecting either analog or digital TV support should display all hybrid devices. When an hybrid driver is selected, both V4L2 and DVB core will be available. 2. Patches 20 to 33: visual changes. - At the beginning, media had just "technical" options to enable/disable each feature. However, that leads into hundreds of different options, being a nightmare for a mortal to set it up. So, the Kconfig menu options were re-designed in order to bring a more user-oriented view: The initial items select the type of devices (analog TV, digital TV, cameras, ...). Selecting it would auto-select the core drivers. The next step would be to select either PCI or USB, and the needed driver. While this makes life simpler, now there are many embedded developers. Most seem to prefer to be able of seeing everything without filters. The main focus of this part is to make everybody happy: it is now possible to unselect the filters, making all options visible. Also, now, when the filter is enabled, the media drivers menu will show a message warning that the filter is active. Hopefully, this should make both embedded developers and normal users happy. - The media menus now have a more modern visual, grouping options in a way that it is now clearer about what they do. So, the Media support menu is now: --- Media support [ ] Filter media drivers [ ] Autoselect ancillary drivers Media device types ---> Media core support ---> Video4Linux options ---> Media controller options ---> Digital TV options ---> HDMI CEC options ---> Media drivers ---> Media ancillary drivers ---> Mauro Carvalho Chehab (33): media: dvb-usb: auto-select CYPRESS_FIRMWARE media: Kconfig: add an option to filter in/out platform drivers media: Kconfig: not all V4L2 platform drivers are for camera media: pci: move VIDEO_PCI_SKELETON to a different Kconfig media: Kconfig: update the MEDIA_SUPPORT help message media: split test drivers from platform directory media: Kconfig: move comment to siano include media: Kconfig: move drivers-specific TTPCI_EEPROM Kconfig var media: Kconfig: mode firewire comment to firewire/Kconfig media: ddbridge: copy the dvb_dummy_fe driver to ddbridge media: ddbridge-dummy_fe: do some vars and function renames media: ddbridge: use the ddbridge's own dummy fe driver media: Kconfig: mark other drivers as test drivers media: Kconfig: simplify some dependencies media: Kconfig: better support hybrid TV devices media: Kconfig: fix selection for test drivers media: add SPDX headers on Kconfig and Makefile files media: dvb-core: Kconfig: default to use dynamic minors media: Kconfig files: use select for V4L2 subdevs and MC media: Kconfig: reorganize the drivers menu options media: Kconfig: use a sub-menu to select supported devices media: Kconfig: make filtering devices optional media: Kconfig: warn if drivers are filtered media: Kconfig: move CEC-specific options to cec/Kconfig media: Kconfig: move DVB-specific options to dvb-core/Kconfig media: Kconfig: move V4L2 subdev API to v4l2-core/Kconfig media: Kconfig: move media controller core select to main Kconfig media: Kconfig: place all options under a sub-menu media: Kconfig: move the position of sub-driver autoselection media: Kconfig: on !EMBEDDED && !EXPERT, enable driver filtering media: Kconfig: Better organize the per-API options media: i2c/Kconfig: reorganize items there med
[PATCH v4 19/33] media: Kconfig files: use select for V4L2 subdevs and MC
There are lots of drivers that only work when the media controller and/or the V4L2 subdev APIs are present. Right now, someone need to first enable those APIs before using those drivers. Well, ideally, drivers, should, instead *optionally* depend on it, in order for PC camera drivers to be able to use them, but nowadays most drivers are UVC cameras, with don't require a sensor driver. So, be it. Let's instead make them select the MEDIA_CONTROLLER and the SUBDEV API, in order to make easier for people to be able of enabling them. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/i2c/Kconfig | 210 -- drivers/media/i2c/et8ek8/Kconfig | 4 +- drivers/media/i2c/m5mols/Kconfig | 5 +- drivers/media/i2c/smiapp/Kconfig | 5 +- drivers/media/mc/Kconfig | 2 +- drivers/media/pci/cobalt/Kconfig | 4 +- drivers/media/pci/intel/ipu3/Kconfig | 4 +- drivers/media/pci/sta2x11/Kconfig | 6 +- drivers/media/platform/Kconfig| 28 ++- drivers/media/platform/am437x/Kconfig | 4 +- drivers/media/platform/atmel/Kconfig | 4 +- drivers/media/platform/cadence/Kconfig| 8 +- drivers/media/platform/exynos4-is/Kconfig | 5 +- drivers/media/platform/rcar-vin/Kconfig | 8 +- .../media/platform/sunxi/sun4i-csi/Kconfig| 4 +- .../media/platform/sunxi/sun6i-csi/Kconfig| 4 +- drivers/media/platform/xilinx/Kconfig | 4 +- drivers/media/spi/Kconfig | 4 +- drivers/media/test_drivers/vimc/Kconfig | 4 +- drivers/staging/media/hantro/Kconfig | 5 +- drivers/staging/media/imx/Kconfig | 5 +- drivers/staging/media/ipu3/Kconfig| 3 +- drivers/staging/media/omap4iss/Kconfig| 4 +- drivers/staging/media/rkisp1/Kconfig | 4 +- drivers/staging/media/sunxi/cedrus/Kconfig| 5 +- 25 files changed, 237 insertions(+), 106 deletions(-) diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index 125d596c13dd..4bc4cfea2f20 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -19,7 +19,7 @@ config VIDEO_IR_I2C In doubt, say Y. # -# Encoder / Decoder module configuration +# V4L2 I2C drivers that aren't related with Camera support # comment "I2C drivers hidden by 'Autoselect ancillary drivers'" @@ -28,6 +28,10 @@ comment "I2C drivers hidden by 'Autoselect ancillary drivers'" menu "I2C Encoders, decoders, sensors and other helper chips" visible if !MEDIA_HIDE_ANCILLARY_SUBDRV +# +# Encoder / Decoder module configuration +# + comment "Audio decoders, processors and mixers" config VIDEO_TVAUDIO @@ -62,11 +66,13 @@ config VIDEO_TDA9840 config VIDEO_TDA1997X tristate "NXP TDA1997x HDMI receiver" - depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API + depends on VIDEO_V4L2 && I2C depends on SND_SOC select HDMI select SND_PCM select V4L2_FWNODE + select MEDIA_CONTROLLER + select VIDEO_V4L2_SUBDEV_API help V4L2 subdevice driver for the NXP TDA1997x HDMI receivers. @@ -204,7 +210,9 @@ comment "Video decoders" config VIDEO_ADV7180 tristate "Analog Devices ADV7180 decoder" - depends on GPIOLIB && VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API + depends on GPIOLIB && VIDEO_V4L2 && I2C + select MEDIA_CONTROLLER + select VIDEO_V4L2_SUBDEV_API help Support for the Analog Devices ADV7180 video decoder. @@ -223,8 +231,10 @@ config VIDEO_ADV7183 config VIDEO_ADV748X tristate "Analog Devices ADV748x decoder" - depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API + depends on VIDEO_V4L2 && I2C depends on OF + select MEDIA_CONTROLLER + select VIDEO_V4L2_SUBDEV_API select REGMAP_I2C select V4L2_FWNODE help @@ -236,8 +246,10 @@ config VIDEO_ADV748X config VIDEO_ADV7604 tristate "Analog Devices ADV7604 decoder" - depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API + depends on VIDEO_V4L2 && I2C depends on GPIOLIB || COMPILE_TEST + select MEDIA_CONTROLLER + select VIDEO_V4L2_SUBDEV_API select REGMAP_I2C select HDMI select V4L2_FWNODE @@ -260,7 +272,9 @@ config VIDEO_ADV7604_CEC config VIDEO_ADV7842 tristate "Analog Devices ADV7842 decoder" - depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API + depends on VIDEO_V4L2 && I2C + select MEDIA_CONTROLLER + select VIDEO_V4L2_SUBDEV_API select HDMI help Support for the Analog Devices ADV7842 video decoder. @@ -347,7 +361,9 @@ config VIDEO_SAA711X config VIDEO_TC358743 tristate "Toshiba TC358743 decoder" - depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API + depends on VIDEO_V4L2 && I2C
[PATCH v4 17/33] media: add SPDX headers on Kconfig and Makefile files
Most of media Kconfig/Makefile files already has SPDX, but there are a few ones still missing. Add it to them. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/dvb-frontends/Kconfig | 2 ++ drivers/media/mc/Kconfig| 2 ++ drivers/media/platform/sunxi/Kconfig| 2 ++ drivers/media/platform/sunxi/Makefile | 2 ++ drivers/media/platform/sunxi/sun4i-csi/Kconfig | 2 ++ drivers/media/platform/sunxi/sun4i-csi/Makefile | 2 ++ drivers/staging/media/hantro/Makefile | 2 ++ drivers/staging/media/rkisp1/Makefile | 2 ++ 8 files changed, 16 insertions(+) diff --git a/drivers/media/dvb-frontends/Kconfig b/drivers/media/dvb-frontends/Kconfig index 1f45808d94da..aa24506257b3 100644 --- a/drivers/media/dvb-frontends/Kconfig +++ b/drivers/media/dvb-frontends/Kconfig @@ -1,3 +1,5 @@ +# SPDX-License-Identifier: GPL-2.0 + if MEDIA_DIGITAL_TV_SUPPORT comment "DVB Frontend drivers hidden by 'Autoselect ancillary drivers'" diff --git a/drivers/media/mc/Kconfig b/drivers/media/mc/Kconfig index 3b9795cfcb36..0c5c52f14c64 100644 --- a/drivers/media/mc/Kconfig +++ b/drivers/media/mc/Kconfig @@ -1,3 +1,5 @@ +# SPDX-License-Identifier: GPL-2.0 + # # Media controller # Selectable only for webcam/grabbers, as other drivers don't use it diff --git a/drivers/media/platform/sunxi/Kconfig b/drivers/media/platform/sunxi/Kconfig index 71808e93ac2e..7151cc249afa 100644 --- a/drivers/media/platform/sunxi/Kconfig +++ b/drivers/media/platform/sunxi/Kconfig @@ -1,2 +1,4 @@ +# SPDX-License-Identifier: GPL-2.0 + source "drivers/media/platform/sunxi/sun4i-csi/Kconfig" source "drivers/media/platform/sunxi/sun6i-csi/Kconfig" diff --git a/drivers/media/platform/sunxi/Makefile b/drivers/media/platform/sunxi/Makefile index ff0993f70dc3..fc537c9f5ca9 100644 --- a/drivers/media/platform/sunxi/Makefile +++ b/drivers/media/platform/sunxi/Makefile @@ -1,3 +1,5 @@ +# SPDX-License-Identifier: GPL-2.0 + obj-y += sun4i-csi/ obj-y += sun6i-csi/ obj-y += sun8i-di/ diff --git a/drivers/media/platform/sunxi/sun4i-csi/Kconfig b/drivers/media/platform/sunxi/sun4i-csi/Kconfig index e86e29b6a603..93b4e82a2655 100644 --- a/drivers/media/platform/sunxi/sun4i-csi/Kconfig +++ b/drivers/media/platform/sunxi/sun4i-csi/Kconfig @@ -1,3 +1,5 @@ +# SPDX-License-Identifier: GPL-2.0 + config VIDEO_SUN4I_CSI tristate "Allwinner A10 CMOS Sensor Interface Support" depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA diff --git a/drivers/media/platform/sunxi/sun4i-csi/Makefile b/drivers/media/platform/sunxi/sun4i-csi/Makefile index 7c790a57f5ee..5062b006d63e 100644 --- a/drivers/media/platform/sunxi/sun4i-csi/Makefile +++ b/drivers/media/platform/sunxi/sun4i-csi/Makefile @@ -1,3 +1,5 @@ +# SPDX-License-Identifier: GPL-2.0 + sun4i-csi-y += sun4i_csi.o sun4i-csi-y += sun4i_dma.o sun4i-csi-y += sun4i_v4l2.o diff --git a/drivers/staging/media/hantro/Makefile b/drivers/staging/media/hantro/Makefile index 68c29a9c4946..743ce08eb184 100644 --- a/drivers/staging/media/hantro/Makefile +++ b/drivers/staging/media/hantro/Makefile @@ -1,3 +1,5 @@ +# SPDX-License-Identifier: GPL-2.0 + obj-$(CONFIG_VIDEO_HANTRO) += hantro-vpu.o hantro-vpu-y += \ diff --git a/drivers/staging/media/rkisp1/Makefile b/drivers/staging/media/rkisp1/Makefile index 69ca59c7ef34..ab32a77db8f7 100644 --- a/drivers/staging/media/rkisp1/Makefile +++ b/drivers/staging/media/rkisp1/Makefile @@ -1,3 +1,5 @@ +# SPDX-License-Identifier: GPL-2.0 + obj-$(CONFIG_VIDEO_ROCKCHIP_ISP1) += rockchip-isp1.o rockchip-isp1-objs += rkisp1-capture.o \ rkisp1-common.o \ -- 2.25.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V2] x86/Hyper-V: don't allocate clockevent device when synthetic timer is unavailable
ltyker...@gmail.com writes:
> From: Tianyu Lan
>
> Current code initializes clock event data structure for syn timer
> even when it's unavailable. Fix it.
>
> Signed-off-by: Tianyu Lan
> ---
> Change since v1:
> Update title and commit log.
>
> drivers/hv/hv.c | 15 +--
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
> index 632d25674e7f..2e893768fc76 100644
> --- a/drivers/hv/hv.c
> +++ b/drivers/hv/hv.c
> @@ -212,13 +212,16 @@ int hv_synic_alloc(void)
> tasklet_init(&hv_cpu->msg_dpc,
>vmbus_on_msg_dpc, (unsigned long) hv_cpu);
>
> - hv_cpu->clk_evt = kzalloc(sizeof(struct clock_event_device),
> - GFP_KERNEL);
> - if (hv_cpu->clk_evt == NULL) {
> - pr_err("Unable to allocate clock event device\n");
> - goto err;
> + if (ms_hyperv.features & HV_MSR_SYNTIMER_AVAILABLE) {
> + hv_cpu->clk_evt =
> + kzalloc(sizeof(struct clock_event_device),
> + GFP_KERNEL);
> + if (hv_cpu->clk_evt == NULL) {
> + pr_err("Unable to allocate clock event
> device\n");
> + goto err;
> + }
> + hv_init_clockevent_device(hv_cpu->clk_evt, cpu);
> }
> - hv_init_clockevent_device(hv_cpu->clk_evt, cpu);
>
> hv_cpu->synic_message_page =
> (void *)get_zeroed_page(GFP_ATOMIC);
Thank you for fixing the subject! I had one more question on the
previous version which still stands: which tree is this patch for?
Upstream, clockevent allocation has moved to
drivers/clocksource/hyperv_timer.c and the code there is different.
Is this intended for some stable tree?
--
Vitaly
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 17/33] media: add SPDX headers on Kconfig and Makefile files
Hi Mauro, Thank you for the patch. On Tue, Mar 31, 2020 at 01:11:53PM +0200, Mauro Carvalho Chehab wrote: > Most of media Kconfig/Makefile files already has SPDX, > but there are a few ones still missing. Add it to them. I think it's a good idea to state the license of each source file, the patch looks fine to me. I've however been thinking about licenses for build system files recently, and I'll hijack this thread a bit to ask a question :-) For a project like the Linux kernel, and especially for subsystems that are covered by a single license, the choice is easy, we can apply the same license to the build files. However, for a project that contains components covered by different licenses (such as, for instance, an LGPL library, a GPL application and a BSD plugin), how should the license covering the build system files be selected ? I searched a bit for guidance on this topic, and couldn't find much. > Signed-off-by: Mauro Carvalho Chehab > --- > drivers/media/dvb-frontends/Kconfig | 2 ++ > drivers/media/mc/Kconfig| 2 ++ > drivers/media/platform/sunxi/Kconfig| 2 ++ > drivers/media/platform/sunxi/Makefile | 2 ++ > drivers/media/platform/sunxi/sun4i-csi/Kconfig | 2 ++ > drivers/media/platform/sunxi/sun4i-csi/Makefile | 2 ++ > drivers/staging/media/hantro/Makefile | 2 ++ > drivers/staging/media/rkisp1/Makefile | 2 ++ > 8 files changed, 16 insertions(+) > > diff --git a/drivers/media/dvb-frontends/Kconfig > b/drivers/media/dvb-frontends/Kconfig > index 1f45808d94da..aa24506257b3 100644 > --- a/drivers/media/dvb-frontends/Kconfig > +++ b/drivers/media/dvb-frontends/Kconfig > @@ -1,3 +1,5 @@ > +# SPDX-License-Identifier: GPL-2.0 > + > if MEDIA_DIGITAL_TV_SUPPORT > > comment "DVB Frontend drivers hidden by 'Autoselect ancillary drivers'" > diff --git a/drivers/media/mc/Kconfig b/drivers/media/mc/Kconfig > index 3b9795cfcb36..0c5c52f14c64 100644 > --- a/drivers/media/mc/Kconfig > +++ b/drivers/media/mc/Kconfig > @@ -1,3 +1,5 @@ > +# SPDX-License-Identifier: GPL-2.0 > + > # > # Media controller > #Selectable only for webcam/grabbers, as other drivers don't use it > diff --git a/drivers/media/platform/sunxi/Kconfig > b/drivers/media/platform/sunxi/Kconfig > index 71808e93ac2e..7151cc249afa 100644 > --- a/drivers/media/platform/sunxi/Kconfig > +++ b/drivers/media/platform/sunxi/Kconfig > @@ -1,2 +1,4 @@ > +# SPDX-License-Identifier: GPL-2.0 > + > source "drivers/media/platform/sunxi/sun4i-csi/Kconfig" > source "drivers/media/platform/sunxi/sun6i-csi/Kconfig" > diff --git a/drivers/media/platform/sunxi/Makefile > b/drivers/media/platform/sunxi/Makefile > index ff0993f70dc3..fc537c9f5ca9 100644 > --- a/drivers/media/platform/sunxi/Makefile > +++ b/drivers/media/platform/sunxi/Makefile > @@ -1,3 +1,5 @@ > +# SPDX-License-Identifier: GPL-2.0 > + > obj-y+= sun4i-csi/ > obj-y+= sun6i-csi/ > obj-y+= sun8i-di/ > diff --git a/drivers/media/platform/sunxi/sun4i-csi/Kconfig > b/drivers/media/platform/sunxi/sun4i-csi/Kconfig > index e86e29b6a603..93b4e82a2655 100644 > --- a/drivers/media/platform/sunxi/sun4i-csi/Kconfig > +++ b/drivers/media/platform/sunxi/sun4i-csi/Kconfig > @@ -1,3 +1,5 @@ > +# SPDX-License-Identifier: GPL-2.0 > + > config VIDEO_SUN4I_CSI > tristate "Allwinner A10 CMOS Sensor Interface Support" > depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA > diff --git a/drivers/media/platform/sunxi/sun4i-csi/Makefile > b/drivers/media/platform/sunxi/sun4i-csi/Makefile > index 7c790a57f5ee..5062b006d63e 100644 > --- a/drivers/media/platform/sunxi/sun4i-csi/Makefile > +++ b/drivers/media/platform/sunxi/sun4i-csi/Makefile > @@ -1,3 +1,5 @@ > +# SPDX-License-Identifier: GPL-2.0 > + > sun4i-csi-y += sun4i_csi.o > sun4i-csi-y += sun4i_dma.o > sun4i-csi-y += sun4i_v4l2.o > diff --git a/drivers/staging/media/hantro/Makefile > b/drivers/staging/media/hantro/Makefile > index 68c29a9c4946..743ce08eb184 100644 > --- a/drivers/staging/media/hantro/Makefile > +++ b/drivers/staging/media/hantro/Makefile > @@ -1,3 +1,5 @@ > +# SPDX-License-Identifier: GPL-2.0 > + > obj-$(CONFIG_VIDEO_HANTRO) += hantro-vpu.o > > hantro-vpu-y += \ > diff --git a/drivers/staging/media/rkisp1/Makefile > b/drivers/staging/media/rkisp1/Makefile > index 69ca59c7ef34..ab32a77db8f7 100644 > --- a/drivers/staging/media/rkisp1/Makefile > +++ b/drivers/staging/media/rkisp1/Makefile > @@ -1,3 +1,5 @@ > +# SPDX-License-Identifier: GPL-2.0 > + > obj-$(CONFIG_VIDEO_ROCKCHIP_ISP1) += rockchip-isp1.o > rockchip-isp1-objs +=rkisp1-capture.o \ > rkisp1-common.o \ -- Regards, Laurent Pinchart ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 17/33] media: add SPDX headers on Kconfig and Makefile files
On Tue, Mar 31, 2020 at 03:06:08PM +0300, Laurent Pinchart wrote: > Hi Mauro, > > Thank you for the patch. > > On Tue, Mar 31, 2020 at 01:11:53PM +0200, Mauro Carvalho Chehab wrote: > > Most of media Kconfig/Makefile files already has SPDX, > > but there are a few ones still missing. Add it to them. > > I think it's a good idea to state the license of each source file, the > patch looks fine to me. I've however been thinking about licenses for > build system files recently, and I'll hijack this thread a bit to ask a > question :-) > > For a project like the Linux kernel, and especially for subsystems that > are covered by a single license, the choice is easy, we can apply the > same license to the build files. However, for a project that contains > components covered by different licenses (such as, for instance, an LGPL > library, a GPL application and a BSD plugin), how should the license > covering the build system files be selected ? I searched a bit for > guidance on this topic, and couldn't find much. By "default" if there is no license on a file in the kernel tree, it falls under the GPLv2 license and we should explicity state it, like this patch does. So this is fine, but if you want to license the build files some other way, that's good too, but do so when you add them to the tree, not at some later time when it could cause confusion :) thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 17/33] media: add SPDX headers on Kconfig and Makefile files
Hi Greg, On Tue, Mar 31, 2020 at 02:22:09PM +0200, Greg Kroah-Hartman wrote: > On Tue, Mar 31, 2020 at 03:06:08PM +0300, Laurent Pinchart wrote: > > On Tue, Mar 31, 2020 at 01:11:53PM +0200, Mauro Carvalho Chehab wrote: > > > Most of media Kconfig/Makefile files already has SPDX, > > > but there are a few ones still missing. Add it to them. > > > > I think it's a good idea to state the license of each source file, the > > patch looks fine to me. I've however been thinking about licenses for > > build system files recently, and I'll hijack this thread a bit to ask a > > question :-) > > > > For a project like the Linux kernel, and especially for subsystems that > > are covered by a single license, the choice is easy, we can apply the > > same license to the build files. However, for a project that contains > > components covered by different licenses (such as, for instance, an LGPL > > library, a GPL application and a BSD plugin), how should the license > > covering the build system files be selected ? I searched a bit for > > guidance on this topic, and couldn't find much. > > By "default" if there is no license on a file in the kernel tree, it > falls under the GPLv2 license and we should explicity state it, like > this patch does. > > So this is fine, but if you want to license the build files some other > way, that's good too, but do so when you add them to the tree, not at > some later time when it could cause confusion :) Thanks for your answer. I was hijacking the thread a little bit, the question wasn't related to the kernel, but in this case to libcamera. We've been wondering how to pick licenses for build files there, and I thought fellow kernel developers may have valuable input on this topic. -- Regards, Laurent Pinchart ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 17/33] media: add SPDX headers on Kconfig and Makefile files
On Tue, Mar 31, 2020 at 03:39:14PM +0300, Laurent Pinchart wrote: > Hi Greg, > > On Tue, Mar 31, 2020 at 02:22:09PM +0200, Greg Kroah-Hartman wrote: > > On Tue, Mar 31, 2020 at 03:06:08PM +0300, Laurent Pinchart wrote: > > > On Tue, Mar 31, 2020 at 01:11:53PM +0200, Mauro Carvalho Chehab wrote: > > > > Most of media Kconfig/Makefile files already has SPDX, > > > > but there are a few ones still missing. Add it to them. > > > > > > I think it's a good idea to state the license of each source file, the > > > patch looks fine to me. I've however been thinking about licenses for > > > build system files recently, and I'll hijack this thread a bit to ask a > > > question :-) > > > > > > For a project like the Linux kernel, and especially for subsystems that > > > are covered by a single license, the choice is easy, we can apply the > > > same license to the build files. However, for a project that contains > > > components covered by different licenses (such as, for instance, an LGPL > > > library, a GPL application and a BSD plugin), how should the license > > > covering the build system files be selected ? I searched a bit for > > > guidance on this topic, and couldn't find much. > > > > By "default" if there is no license on a file in the kernel tree, it > > falls under the GPLv2 license and we should explicity state it, like > > this patch does. > > > > So this is fine, but if you want to license the build files some other > > way, that's good too, but do so when you add them to the tree, not at > > some later time when it could cause confusion :) > > Thanks for your answer. I was hijacking the thread a little bit, the > question wasn't related to the kernel, but in this case to libcamera. > We've been wondering how to pick licenses for build files there, and I > thought fellow kernel developers may have valuable input on this topic. I would make the files the same license as your project overall is to make things simpler for everyone involved :) thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 17/33] media: add SPDX headers on Kconfig and Makefile files
Hi Greg, On Tue, Mar 31, 2020 at 02:47:56PM +0200, Greg Kroah-Hartman wrote: > On Tue, Mar 31, 2020 at 03:39:14PM +0300, Laurent Pinchart wrote: > > On Tue, Mar 31, 2020 at 02:22:09PM +0200, Greg Kroah-Hartman wrote: > > > On Tue, Mar 31, 2020 at 03:06:08PM +0300, Laurent Pinchart wrote: > > > > On Tue, Mar 31, 2020 at 01:11:53PM +0200, Mauro Carvalho Chehab wrote: > > > > > Most of media Kconfig/Makefile files already has SPDX, > > > > > but there are a few ones still missing. Add it to them. > > > > > > > > I think it's a good idea to state the license of each source file, the > > > > patch looks fine to me. I've however been thinking about licenses for > > > > build system files recently, and I'll hijack this thread a bit to ask a > > > > question :-) > > > > > > > > For a project like the Linux kernel, and especially for subsystems that > > > > are covered by a single license, the choice is easy, we can apply the > > > > same license to the build files. However, for a project that contains > > > > components covered by different licenses (such as, for instance, an LGPL > > > > library, a GPL application and a BSD plugin), how should the license > > > > covering the build system files be selected ? I searched a bit for > > > > guidance on this topic, and couldn't find much. > > > > > > By "default" if there is no license on a file in the kernel tree, it > > > falls under the GPLv2 license and we should explicity state it, like > > > this patch does. > > > > > > So this is fine, but if you want to license the build files some other > > > way, that's good too, but do so when you add them to the tree, not at > > > some later time when it could cause confusion :) > > > > Thanks for your answer. I was hijacking the thread a little bit, the > > question wasn't related to the kernel, but in this case to libcamera. > > We've been wondering how to pick licenses for build files there, and I > > thought fellow kernel developers may have valuable input on this topic. > > I would make the files the same license as your project overall is to > make things simpler for everyone involved :) I would if the project had a single license, but we have GPL, LGPL and BSD components :-S -- Regards, Laurent Pinchart ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V2] x86/Hyper-V: don't allocate clockevent device when synthetic timer is unavailable
On 3/31/2020 7:20 PM, Vitaly Kuznetsov wrote:
ltyker...@gmail.com writes:
From: Tianyu Lan
Current code initializes clock event data structure for syn timer
even when it's unavailable. Fix it.
Signed-off-by: Tianyu Lan
---
Change since v1:
Update title and commit log.
drivers/hv/hv.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index 632d25674e7f..2e893768fc76 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -212,13 +212,16 @@ int hv_synic_alloc(void)
tasklet_init(&hv_cpu->msg_dpc,
vmbus_on_msg_dpc, (unsigned long) hv_cpu);
- hv_cpu->clk_evt = kzalloc(sizeof(struct clock_event_device),
- GFP_KERNEL);
- if (hv_cpu->clk_evt == NULL) {
- pr_err("Unable to allocate clock event device\n");
- goto err;
+ if (ms_hyperv.features & HV_MSR_SYNTIMER_AVAILABLE) {
+ hv_cpu->clk_evt =
+ kzalloc(sizeof(struct clock_event_device),
+ GFP_KERNEL);
+ if (hv_cpu->clk_evt == NULL) {
+ pr_err("Unable to allocate clock event
device\n");
+ goto err;
+ }
+ hv_init_clockevent_device(hv_cpu->clk_evt, cpu);
}
- hv_init_clockevent_device(hv_cpu->clk_evt, cpu);
hv_cpu->synic_message_page =
(void *)get_zeroed_page(GFP_ATOMIC);
Thank you for fixing the subject! I had one more question on the
previous version which still stands: which tree is this patch for?
Upstream, clockevent allocation has moved to
drivers/clocksource/hyperv_timer.c and the code there is different.
Yes, I just noticed I fixed an issue on the old code after Michael
reminded me. Sorry for noise. Please ignore it.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [staging:staging-testing 278/280] drivers/most/core.c:1287 most_register_interface() error: we previously assumed 'iface' could be null (see line 1285)
On Tue, 2020-03-31 at 13:45 +0300, Dan Carpenter wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
>
> Hi Christian,
>
> First bad commit (maybe != root cause):
>
> tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> staging-testing
> head: 4a1a3e9bf5654e98bb48f5b074af17af96ded30d
> commit: b276527539188f1f61c082ebef27803db93e536d [278/280] staging:
> most: move core files out of the staging area
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot
> Reported-by: Dan Carpenter
>
> smatch warnings:
> drivers/most/core.c:1287 most_register_interface() error: we
> previously assumed 'iface' could be null (see line 1285)
>
> #
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?id=b276527539188f1f61c082ebef27803db93e536d
> git remote add staging
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> git remote update staging
> git checkout b276527539188f1f61c082ebef27803db93e536d
> vim +/iface +1287 drivers/most/core.c
>
> 4d5f022f3a664e drivers/staging/most/core.c Christian
> Gromm 2017-11-21 1279 int most_register_interface(struct
> most_interface *iface)
> 57562a72414ca3 drivers/staging/most/mostcore/core.c Christian
> Gromm 2015-07-24 1280 {
> 57562a72414ca3 drivers/staging/most/mostcore/core.c Christian
> Gromm 2015-07-24 1281unsigned int i;
> 57562a72414ca3 drivers/staging/most/mostcore/core.c Christian
> Gromm 2015-07-24 1282int id;
> fcb7fad82e23f6 drivers/staging/most/core.c Christian
> Gromm 2017-11-21 1283struct most_channel *c;
> 57562a72414ca3 drivers/staging/most/mostcore/core.c Christian
> Gromm 2015-07-24 1284
> 57562a72414ca3 drivers/staging/most/mostcore/core.c Christian
> Gromm 2015-07-24 @1285if (!iface || !iface->enqueue ||
> !iface->configure ||
>
>^^
>
> 57562a72414ca3 drivers/staging/most/mostcore/core.c Christian
> Gromm 2015-07-24 1286!iface->poison_channel ||
> (iface->num_channels > MAX_CHANNELS)) {
> 6a82c775812944 drivers/staging/most/core.c Christian
> Gromm 2020-01-23 @1287dev_err(iface->dev, "Bad
> interface or channel overflow\n");
>
>^^
>
> Hopefully, we can just remove the NULL check?
Yes we can. The modules that register such an interface with the
core already check that.
I'll send a patch that removes the NULL check of the "iface" pointer.
thanks,
Chris
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
SPDX headers - Was: Re: [PATCH v4 17/33] media: add SPDX headers on Kconfig and Makefile files
Em Tue, 31 Mar 2020 15:06:08 +0300 Laurent Pinchart escreveu: > I've however been thinking about licenses for > build system files recently, and I'll hijack this thread a bit to ask a > question :-) Ok, I'll change the subject, as the answers won't be related to the Kernel :-) > For a project like the Linux kernel, and especially for subsystems that > are covered by a single license, the choice is easy, we can apply the > same license to the build files. However, for a project that contains > components covered by different licenses (such as, for instance, an LGPL > library, a GPL application and a BSD plugin), how should the license > covering the build system files be selected ? I searched a bit for > guidance on this topic, and couldn't find much. Then everything becomes a way more complex :-) I guess nobody has a clear answer for that. Also, IANAL. What I can tell is what it would makes sense for me. The big impact of a complex licenses model would be for the ones packaging it on some distro, and for the users of such distros. The distros need to know if they have the rights to redistribute, and need to notify their usages about each package's license. Let's assume a project "foo-utils" that has such complexity. Assuming a project that started on a green field (like libcamera), and such project doesn't use stuff from external libraries, what one could do would be to design it in a way that different licenses would be packaged differently. For instance: foo-libs# everything here is under LGPL foo-bsd-plugin # everything here is under BSD foo-utils # everything here is under GPLv3 Then, on each of them, a COPYING.foo file (or whatever other way distros would use to identify the per-package license) would contain the license with applied to it. Btw, if you want to take a look on a real-case scenario, see, for example: https://build.opensuse.org/package/view_file/devel:libraries:c_c++/v4l-utils/v4l-utils.spec?rev=a250bff0f849e8c2fa7e476a1f2849a8 %package -n libv4l-devel License:LGPLv2+ ... %package -n qv4l2 License:GPLv2+ Btw, GStreamer actually follows a similar approach, but they even split those into different git trees (core, good, bad and ugly plugins). Thanks, Mauro ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: b276527539 ("staging: most: move core files out of the staging .."): [ 12.247349] BUG: kernel NULL pointer dereference, address: 00000000
On Sun, 2020-03-29 at 21:39 +0800, kernel test robot wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you > know the content is safe > > Greetings, > > 0day kernel testing robot got the below dmesg and the first bad > commit is > > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git > staging-next > > commit b276527539188f1f61c082ebef27803db93e536d > Author: Christian Gromm > AuthorDate: Tue Mar 10 14:02:40 2020 +0100 > Commit: Greg Kroah-Hartman > CommitDate: Tue Mar 24 13:42:44 2020 +0100 > > staging: most: move core files out of the staging area > > This patch moves the core module to the /drivers/most directory > and makes all necessary changes in order to not break the build. > > Signed-off-by: Christian Gromm > Link: > https://lore.kernel.org/r/1583845362-26707-2-git-send-email-christian.gr...@microchip.com > Signed-off-by: Greg Kroah-Hartman > > 22dd4acc80 Staging: speakup: Add identifier name to function > declaration arguments. > b276527539 staging: most: move core files out of the staging area > e681bb287f staging: vt6656: Use DIV_ROUND_UP macro instead of > specific code > +---+-- > --+++ > > | 22dd4acc80 > > | b276527539 | e681bb287f | > +---+-- > --+++ > > boot_successes| > > 26 | 0 | 0 | > > boot_failures | > > 8 | 11 | 11 | > > WARNING:possible_circular_locking_dependency_detected | > > 8 ||| > > BUG:kernel_NULL_pointer_dereference,address | > > 0 | 11 | 11 | > > Oops:#[##]| > > 0 | 11 | 11 | > > EIP:__list_add_valid | > > 0 | 11 | 11 | > > Kernel_panic-not_syncing:Fatal_exception | > > 0 | 11 | 11 | > +---+-- > --+++ > > If you fix the issue, kindly add following tag > Reported-by: kernel test robot > > [ 12.242090] no options. > [ 12.245364] FPGA DOWNLOAD ---> > [ 12.245723] FPGA image file name: xlinx_fpga_firmware.bit > [ 12.246548] GPIO INIT FAIL!! > [ 12.246995] most_sound: init() > [ 12.247349] BUG: kernel NULL pointer dereference, address: > > [ 12.248032] #PF: supervisor read access in kernel mode > [ 12.248322] #PF: error_code(0x) - not-present page > [ 12.248322] *pdpt = *pde = f000ff53f000ff53 > [ 12.248322] Oops: [#1] PREEMPT SMP > [ 12.248322] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.6.0-rc7- > 00376-gb276527539188 #1 > [ 12.248322] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), > BIOS 1.12.0-1 04/01/2014 > [ 12.248322] EIP: __list_add_valid+0x29/0x77 > [ 12.248322] Code: c3 55 89 e5 56 53 83 ec 10 8b 59 04 39 d3 74 1a > 89 4c 24 0c 89 5c 24 08 89 54 24 04 c7 04 24 00 cc bd c2 e8 84 9e b4 > ff 0f 0b <8b> 33 39 ce 74 1a 89 5c 24 0c 89 74 24 08 89 4c 24 04 c7 > 04 24 7c > [ 12.248322] EAX: c2f45800 EBX: ECX: c3e8df50 EDX: > > [ 12.248322] ESI: EDI: ec4a7f68 EBP: ec4a7ee8 ESP: > ec4a7ed0 > [ 12.248322] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: > 00010246 > [ 12.248322] CR0: 80050033 CR2: CR3: 03256000 CR4: > 001406b0 > [ 12.248322] Call Trace: > [ 12.248322] ? vprintk_func+0x9d/0xa7 > [ 12.248322] most_register_component+0x33/0x53 This function does a NULL check on the passed argument struct most_component, berfore it calls list_add_tail(). So the dereferenced pointer must be the struct list_head comp_list of the core. > [ 12.248322] ? wilc_spi_driver_init+0x11/0x11 > [ 12.248322] audio_init+0x2c/0x76 > [ 12.248322] do_one_initcall+0xf0/0x284 > [ 12.248322] ? __might_sleep+0x70/0x77 > [ 12.262064] kernel_init_freeable+0x141/0x1a5 > [ 12.262064] ? rest_init+0x205/0x205 > [ 12.262064] kernel_init+0xb/0xea > [ 12.262064] ? schedule_tail_wrapper+0x9/0xc > [ 12.262064] ret_from_fork+0x2e/0x38 > [ 12.262064] Modules linked in: > [ 12.262064] CR2: > [ 12.262064] ---[ end trace 7c7a2cb6d11f9c5d ]--- > [ 12.262064] EIP: __list_add_valid+0x29/0x77 which is weird, as the list_head used here is not dynamically allocated and INIT_LIST_HEAD is definitely being called in the __init function most_init() of the core module before its first usage. I've never seen the code failing at this point, nor has this being reported by anyone yet. Need to investigate. thanks, Chris ___ devel mailing list de...@linuxdriverproject.o
[driver-core:debugfs_cleanup] BUILD SUCCESS 8bc760d4977eeecc8c9eb13d5614f39d73151c0e
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git debugfs_cleanup branch HEAD: 8bc760d4977eeecc8c9eb13d5614f39d73151c0e powerpc: powernv: no need to check return value of debugfs_create functions elapsed time: 787m configs tested: 150 configs skipped: 0 The following configs have been built successfully. More configs may be tested in the coming days. arm allmodconfig arm allnoconfig arm allyesconfig arm64allmodconfig arm64 allnoconfig arm64allyesconfig arm efm32_defconfig arm at91_dt_defconfig armshmobile_defconfig arm64 defconfig arm exynos_defconfig armmulti_v5_defconfig arm sunxi_defconfig armmulti_v7_defconfig riscv rv32_defconfig nios2 10m50_defconfig sparc64 allmodconfig i386 allnoconfig i386 allyesconfig i386 alldefconfig i386defconfig ia64 alldefconfig ia64 allmodconfig ia64 allnoconfig ia64 allyesconfig ia64defconfig nios2 3c120_defconfig c6xevmc6678_defconfig xtensa iss_defconfig c6x allyesconfig xtensa common_defconfig openrisc simple_smp_defconfig openriscor1ksim_defconfig nds32 defconfig nds32 allnoconfig cskydefconfig alpha defconfig h8300 h8s-sim_defconfig h8300 edosk2674_defconfig m68k m5475evb_defconfig m68k allmodconfig h8300h8300h-sim_defconfig m68k sun3_defconfig m68k multi_defconfig arc allyesconfig arc defconfig microblaze mmu_defconfig microblazenommu_defconfig powerpc allnoconfig powerpc defconfig powerpc ppc64_defconfig powerpc rhel-kconfig mips 32r2_defconfig mips 64r6el_defconfig mips allmodconfig mips allnoconfig mips allyesconfig mips fuloong2e_defconfig mips malta_kvm_defconfig pariscallnoconfig parisc allyesconfig pariscgeneric-32bit_defconfig pariscgeneric-64bit_defconfig x86_64 randconfig-a003-20200331 x86_64 randconfig-a002-20200331 i386 randconfig-a001-20200331 i386 randconfig-a002-20200331 i386 randconfig-a003-20200331 x86_64 randconfig-a001-20200331 riscvrandconfig-a001-20200331 mips randconfig-a001-20200331 m68k randconfig-a001-20200331 parisc randconfig-a001-20200331 alpharandconfig-a001-20200331 nds32randconfig-a001-20200331 microblaze randconfig-a001-20200331 h8300randconfig-a001-20200331 nios2randconfig-a001-20200331 c6x randconfig-a001-20200331 sparc64 randconfig-a001-20200331 csky randconfig-a001-20200331 s390 randconfig-a001-20200331 xtensa randconfig-a001-20200331 openrisc randconfig-a001-20200331 sh randconfig-a001-20200331 x86_64 randconfig-b001-20200331 x86_64 randconfig-b002-20200331 x86_64 randconfig-b003-20200331 i386 randconfig-b001-20200331 i386 randconfig-b002-20200331 i386 randconfig-b003-20200331 i386 randconfig-c003-20200331 x86_64 randconfig-c003-20200331 x86_64 randconfig-c002-20200331 i386 randconfig-c002-20200331 x86_64 randconfig-c001-20200331 i386 randconfig-c001-20200331 i386 randconfig-d003-20200331 i386 randconfig-d001-20200331 i386 randconfig-d002-20200331
[driver-core:debugfs_remove_return_value] BUILD SUCCESS 3777507a35aed836416a6233140b9f889cbb90d7
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git debugfs_remove_return_value branch HEAD: 3777507a35aed836416a6233140b9f889cbb90d7 debugfs: remove return value of debugfs_create_u32() elapsed time: 786m configs tested: 152 configs skipped: 0 The following configs have been built successfully. More configs may be tested in the coming days. arm allmodconfig arm allnoconfig arm allyesconfig arm64allmodconfig arm64 allnoconfig arm64allyesconfig arm efm32_defconfig arm at91_dt_defconfig armshmobile_defconfig arm64 defconfig arm exynos_defconfig armmulti_v5_defconfig arm sunxi_defconfig armmulti_v7_defconfig sparcallyesconfig riscv rv32_defconfig mips malta_kvm_defconfig s390defconfig ia64defconfig powerpc defconfig nios2 10m50_defconfig sparc64 allmodconfig i386 allnoconfig i386 allyesconfig i386 alldefconfig i386defconfig ia64 allmodconfig ia64 allnoconfig ia64 allyesconfig ia64 alldefconfig nios2 3c120_defconfig c6xevmc6678_defconfig xtensa iss_defconfig c6x allyesconfig xtensa common_defconfig openrisc simple_smp_defconfig openriscor1ksim_defconfig nds32 defconfig nds32 allnoconfig cskydefconfig alpha defconfig h8300 h8s-sim_defconfig h8300 edosk2674_defconfig m68k m5475evb_defconfig m68k allmodconfig h8300h8300h-sim_defconfig m68k sun3_defconfig m68k multi_defconfig arc allyesconfig arc defconfig microblaze mmu_defconfig microblazenommu_defconfig powerpc allnoconfig powerpc ppc64_defconfig powerpc rhel-kconfig mips 32r2_defconfig mips 64r6el_defconfig mips allmodconfig mips allnoconfig mips allyesconfig mips fuloong2e_defconfig pariscallnoconfig parisc allyesconfig pariscgeneric-32bit_defconfig pariscgeneric-64bit_defconfig x86_64 randconfig-a001-20200331 x86_64 randconfig-a002-20200331 x86_64 randconfig-a003-20200331 i386 randconfig-a001-20200331 i386 randconfig-a002-20200331 i386 randconfig-a003-20200331 riscvrandconfig-a001-20200331 mips randconfig-a001-20200331 m68k randconfig-a001-20200331 parisc randconfig-a001-20200331 alpharandconfig-a001-20200331 nds32randconfig-a001-20200331 c6x randconfig-a001-20200331 h8300randconfig-a001-20200331 microblaze randconfig-a001-20200331 nios2randconfig-a001-20200331 sparc64 randconfig-a001-20200331 csky randconfig-a001-20200331 openrisc randconfig-a001-20200331 s390 randconfig-a001-20200331 sh randconfig-a001-20200331 xtensa randconfig-a001-20200331 x86_64 randconfig-b001-20200331 x86_64 randconfig-b002-20200331 x86_64 randconfig-b003-20200331 i386 randconfig-b001-20200331 i386 randconfig-b002-20200331 i386 randconfig-b003-20200331 i386 randconfig-c003-20200331 x86_64 randconfig-c003-20200331 x86_64 randconfig-c002-20200331 i386 randconfig-c002-20200331 x86_64 randconfig-c001-20200331 i386 randconfig-c001-20200331 x86_64 randconfig-e001-20200331 x86_64
[PATCH -next] staging: greybus: fix a missing-check bug in gb_lights_light_config()
In gb_lights_light_config(), 'light->name' is allocated by kstrndup(). It returns NULL when fails, add check for it. Signed-off-by: Chen Zhou --- drivers/staging/greybus/light.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c index d6ba25f..d2672b6 100644 --- a/drivers/staging/greybus/light.c +++ b/drivers/staging/greybus/light.c @@ -1026,7 +1026,8 @@ static int gb_lights_light_config(struct gb_lights *glights, u8 id) light->channels_count = conf.channel_count; light->name = kstrndup(conf.name, NAMES_MAX, GFP_KERNEL); - + if (!light->name) + return -ENOMEM; light->channels = kcalloc(light->channels_count, sizeof(struct gb_channel), GFP_KERNEL); if (!light->channels) -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
