[driver-core:debugfs_cleanup] BUILD SUCCESS f1b215306397b46aba05c40e7a320297589178af
parisc defconfig s390 allyesconfig s390 allmodconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a003-20210518 i386 randconfig-a001-20210518 i386 randconfig-a005-20210518 i386 randconfig-a004-20210518 i386 randconfig-a002-20210518 i386 randconfig-a006-20210518 i386 randconfig-a003-20210519 i386 randconfig-a001-20210519 i386 randconfig-a005-20210519 i386 randconfig-a004-20210519 i386 randconfig-a002-20210519 i386 randconfig-a006-20210519 x86_64 randconfig-a012-20210519 x86_64 randconfig-a015-20210519 x86_64 randconfig-a013-20210519 x86_64 randconfig-a011-20210519 x86_64 randconfig-a016-20210519 x86_64 randconfig-a014-20210519 i386 randconfig-a014-20210519 i386 randconfig-a016-20210519 i386 randconfig-a011-20210519 i386 randconfig-a015-20210519 i386 randconfig-a012-20210519 i386 randconfig-a013-20210519 x86_64 randconfig-a003-20210518 x86_64 randconfig-a004-20210518 x86_64 randconfig-a005-20210518 x86_64 randconfig-a001-20210518 x86_64 randconfig-a002-20210518 x86_64 randconfig-a006-20210518 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig um allmodconfig umallnoconfig um allyesconfig x86_64 allyesconfig x86_64rhel-8.3-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kbuiltin x86_64 kexec clang tested configs: x86_64 randconfig-b001-20210519 x86_64 randconfig-a003-20210519 x86_64 randconfig-a004-20210519 x86_64 randconfig-a005-20210519 x86_64 randconfig-a001-20210519 x86_64 randconfig-a002-20210519 x86_64 randconfig-a006-20210519 x86_64 randconfig-a015-20210518 x86_64 randconfig-a012-20210518 x86_64 randconfig-a013-20210518 x86_64 randconfig-a011-20210518 x86_64 randconfig-a016-20210518 x86_64 randconfig-a014-20210518 --- 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
Differnt grades different size graphite block 1.78/1.80/1.85/1.91
Dear Sirs, We are the professional manufacturer of graphite block,graphite rod, graphite plate,and graphite mold. make it according to your drawing and sizes. We can make different grades,Such as:density for 1.78g,1.80g,1.85g,1.91g/cm3. Block size:500*300*200mm,510*310*250mm,540*310*250mm,910*310*310mm. Do you have any requirements for our products? Welcome to your enquiry. Thanks Chris Wechat/Whatsapp: 15010322402 Website: Http://www.chinagraphitefactory.com ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: iio: cdc: ad7746: Remove unnecessary assignment in ad7746_probe()
On Tue, 18 May 2021 13:16:26 +0300 Dan Carpenter wrote: > On Tue, May 18, 2021 at 05:56:47PM +0800, Tang Bin wrote: > > In the function ad7746_probe(), the initialized value of 'ret' is unused, > > because it will be assigned by the function i2c_smbus_write_byte_data(), > > thus remove it. > > > > Signed-off-by: Tang Bin > > Thanks! > > Reviewed-by: Dan Carpenter > > regards, > dan carpenter > As this doesn't (I think) overlap with Lucas' series I've applied this one to the togreg branch of iio.git and pushed it out as testing for the autobuilders to see if we missed anything. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: iio: cdc: ad7746: Fix unnecessary check andassignment in ad7746_probe()
On Tue, 18 May 2021 17:27:07 +0800 tangbin wrote: > Hi Dan： > > On 2021/5/18 15:52, Dan Carpenter wrote: > > On Mon, May 17, 2021 at 11:00:06PM +0800, Tang Bin wrote: > >> @@ -730,11 +730,7 @@ static int ad7746_probe(struct i2c_client *client, > >>if (ret < 0) > >>return ret; > >> > >> - ret = devm_iio_device_register(indio_dev->dev.parent, indio_dev); > >> - if (ret) > >> - return ret; > >> - > >> - return 0; > >> + return devm_iio_device_register(indio_dev->dev.parent, indio_dev); > >> } > > This sort of thing is done deliberately as a style choice... I probably > > wouldn't have written it that way myself, but there really isn't a > > downside to leaving it as-is. > > > > The unused "int ret = 0;" just introduces a static checker warning about > > unused assignments and disables the static checker warning for > > uninitialized variables so we want to remove that. > > > Got it, I will send this patch for you. I fall a bit different on this and would consider the above a cleanup though one I'd prefer to get with more significant stuff rather than on it's own. However, there is already a patch in revision that includes the same change from Lucas Stankus. > > Thanks > > Tang Bin > > > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v10 6/9] media: uapi: Add a control for HANTRO driver
Le dimanche 16 mai 2021 à 20:04 -0300, Ezequiel Garcia a écrit : > Hi Hans, > > On Thu, 2021-05-06 at 14:50 +0200, Hans Verkuil wrote: > > On 05/05/2021 17:20, Benjamin Gaignard wrote: > > > > > > Le 05/05/2021 à 16:55, Hans Verkuil a écrit : > > > > On 20/04/2021 14:10, Benjamin Gaignard wrote: > > > > > The HEVC HANTRO driver needs to know the number of bits to skip at > > > > > the beginning of the slice header. > > > > > That is a hardware specific requirement so create a dedicated control > > > > > for this purpose. > > > > > > > > > > Signed-off-by: Benjamin Gaignard > > > > > --- > > > > > .../userspace-api/media/drivers/hantro.rst | 19 > > > > > +++ > > > > > .../userspace-api/media/drivers/index.rst | 1 + > > > > > include/media/hevc-ctrls.h | 13 + > > > > > 3 files changed, 33 insertions(+) > > > > > create mode 100644 > > > > > Documentation/userspace-api/media/drivers/hantro.rst > > > > > > > > > > diff --git a/Documentation/userspace-api/media/drivers/hantro.rst > > > > > b/Documentation/userspace-api/media/drivers/hantro.rst > > > > > new file mode 100644 > > > > > index ..cd9754b4e005 > > > > > --- /dev/null > > > > > +++ b/Documentation/userspace-api/media/drivers/hantro.rst > > > > > @@ -0,0 +1,19 @@ > > > > > +.. SPDX-License-Identifier: GPL-2.0 > > > > > + > > > > > +Hantro video decoder driver > > > > > +=== > > > > > + > > > > > +The Hantro video decoder driver implements the following > > > > > driver-specific controls: > > > > > + > > > > > +``V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP (integer)`` > > > > > + Specifies to Hantro HEVC video decoder driver the number of data > > > > > (in bits) to > > > > > + skip in the slice segment header. > > > > > + If non-IDR, the bits to be skipped go from syntax element > > > > > "pic_output_flag" > > > > > + to before syntax element "slice_temporal_mvp_enabled_flag". > > > > > + If IDR, the skipped bits are just "pic_output_flag" > > > > > + (separate_colour_plane_flag is not supported). > > > > I'm not very keen on this. Without this information the video data > > > > cannot be > > > > decoded, or will it just be suboptimal? > > > > > > Without that information the video can't be decoded. > > > > > > > > > > > The problem is that a generic decoder would have to know that the HW is > > > > a hantro, > > > > and then call this control. If they don't (and are testing on > > > > non-hantro HW), then > > > > it won't work, thus defeating the purpose of the HW independent decoder > > > > API. > > > > > > > > Since hantro is widely used, and if there is no other way to do this > > > > beside explitely > > > > setting this control, then perhaps this should be part of the standard > > > > HEVC API. > > > > Non-hantro drivers that do not need this can just skip it. > > > > > > Even if I put this parameter in decode_params structure that would means > > > that a generic > > > userland decoder will have to know how the compute this value for hantro > > > HW since it > > > isn't something that could be done on kernel side. > > > > But since hantro is very common, any userland decoder will need to > > calculate this anyway. > > So perhaps it is better to have this as part of the decode_params? > > > > I'd like to know what others think about this. > > > > As you know, I'm not a fan of carrying these "unstable" APIs around. > I know it's better than nothing, but I feel they create the illusion > of the interface being supported in mainline. Since it's unstable, > it's difficult for applications to adopt them. > > As Nicolas mentioned, this means neither FFmpeg nor GStreamer will adopt > these APIs, which worries me, as that means we lose two major user bases. > > My personal take from this, is that we need to find ways to stabilize > our stateless codec APIs in less time and perhaps with less effort. > > IMO, a less stiff interface could help us here, and that's why I think > having hardware-specific controls can be useful. Hardware designers > can be so creative :) > > I'm not against introducing this specific parameter in > v4l2_ctrl_hevc_codec_params, arguing that Hantro is widely used, > but I'd like us to be open to hardware-specific controls as a way > to extend the APIs seamlessly. > > Applications won't have to _know_ what hardware they are running on, > they can just use VIDIOC_QUERYCTRL to find out which controls are needed. Can you extend on this, perhaps we need an RFC for this specific mechanism. I don't immediatly see how I could enumerate controls and figure-out which one are needed. Perhaps we need to add new control flags for mandatory control ? This way userspace could detect unsupported HW if it finds a mandatory control that it does not know about ? > > Thanks, > Ezequiel > ___ devel mailing list de...@linuxdriverproject.org
Re: [PATCH] staging: iio: cdc: ad7746: Remove unnecessary assignment in ad7746_probe()
On Tue, May 18, 2021 at 05:56:47PM +0800, Tang Bin wrote: > In the function ad7746_probe(), the initialized value of 'ret' is unused, > because it will be assigned by the function i2c_smbus_write_byte_data(), > thus remove it. > > Signed-off-by: Tang Bin Thanks! Reviewed-by: Dan Carpenter regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: iio: cdc: ad7746: Remove unnecessary assignment in ad7746_probe()
In the function ad7746_probe(), the initialized value of 'ret' is unused, because it will be assigned by the function i2c_smbus_write_byte_data(), thus remove it. Signed-off-by: Tang Bin --- drivers/staging/iio/cdc/ad7746.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c index dfd71e99e..be4ef454d 100644 --- a/drivers/staging/iio/cdc/ad7746.c +++ b/drivers/staging/iio/cdc/ad7746.c @@ -680,7 +680,7 @@ static int ad7746_probe(struct i2c_client *client, struct ad7746_chip_info *chip; struct iio_dev *indio_dev; unsigned char regval = 0; - int ret = 0; + int ret; indio_dev = devm_iio_device_alloc(>dev, sizeof(*chip)); if (!indio_dev) -- 2.20.1.windows.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: iio: cdc: ad7746: Fix unnecessary check andassignment in ad7746_probe()
Hi Dan： On 2021/5/18 15:52, Dan Carpenter wrote: On Mon, May 17, 2021 at 11:00:06PM +0800, Tang Bin wrote: @@ -730,11 +730,7 @@ static int ad7746_probe(struct i2c_client *client, if (ret < 0) return ret; - ret = devm_iio_device_register(indio_dev->dev.parent, indio_dev); - if (ret) - return ret; - - return 0; + return devm_iio_device_register(indio_dev->dev.parent, indio_dev); } This sort of thing is done deliberately as a style choice... I probably wouldn't have written it that way myself, but there really isn't a downside to leaving it as-is. The unused "int ret = 0;" just introduces a static checker warning about unused assignments and disables the static checker warning for uninitialized variables so we want to remove that. Got it, I will send this patch for you. Thanks Tang Bin ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: iio: cdc: ad7746: Fix unnecessary check and assignment in ad7746_probe()
On Mon, May 17, 2021 at 11:00:06PM +0800, Tang Bin wrote: > @@ -730,11 +730,7 @@ static int ad7746_probe(struct i2c_client *client, > if (ret < 0) > return ret; > > - ret = devm_iio_device_register(indio_dev->dev.parent, indio_dev); > - if (ret) > - return ret; > - > - return 0; > + return devm_iio_device_register(indio_dev->dev.parent, indio_dev); > } This sort of thing is done deliberately as a style choice... I probably wouldn't have written it that way myself, but there really isn't a downside to leaving it as-is. The unused "int ret = 0;" just introduces a static checker warning about unused assignments and disables the static checker warning for uninitialized variables so we want to remove that. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
