[driver-core:driver-core-linus] BUILD SUCCESS 29c4a54bc645c8b6745eeb58519e9ad794ceb419
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git driver-core-linus branch HEAD: 29c4a54bc645c8b6745eeb58519e9ad794ceb419 device property: Avoid NULL pointer dereference in device_get_next_child_node() elapsed time: 3216m configs tested: 110 configs skipped: 1 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig i386 allnoconfig i386 allyesconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 defconfig nds32 allnoconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig xtensa defconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig powerpc defconfig i386 randconfig-a003-20200724 i386 randconfig-a005-20200724 i386 randconfig-a004-20200724 i386 randconfig-a006-20200724 i386 randconfig-a002-20200724 i386 randconfig-a001-20200724 i386 randconfig-a003-20200725 i386 randconfig-a005-20200725 i386 randconfig-a004-20200725 i386 randconfig-a006-20200725 i386 randconfig-a002-20200725 i386 randconfig-a001-20200725 x86_64 randconfig-a014-20200724 x86_64 randconfig-a016-20200724 x86_64 randconfig-a015-20200724 x86_64 randconfig-a012-20200724 x86_64 randconfig-a013-20200724 x86_64 randconfig-a011-20200724 i386 randconfig-a016-20200724 i386 randconfig-a013-20200724 i386 randconfig-a012-20200724 i386 randconfig-a015-20200724 i386 randconfig-a014-20200724 i386 randconfig-a011-20200724 i386 randconfig-a016-20200725 i386 randconfig-a013-20200725 i386 randconfig-a012-20200725 i386 randconfig-a015-20200725 i386 randconfig-a014-20200725 i386 randconfig-a011-20200725 x86_64 randconfig-a005-20200723 x86_64 randconfig-a004-20200723 x86_64 randconfig-a003-20200723 x86_64 randconfig-a002-20200723 x86_64 randconfig-a006-20200723 x86_64 randconfig-a001-20200723 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig s390 allyesconfig s390 allnoconfig s390 allmodconfig s390defconfig sparcallyesconfig sparc
Re: [PATCH 1/1] STAGING - REALTEK RTL8188EU DRIVERS: Fix Coding Style Error
On Sat, 2020-07-25 at 12:47 -0500, Larry Finger wrote:
> On 7/25/20 7:20 AM, Anant Thazhemadam wrote:
> > Running the checkpatch.pl script on the file for which patch was created,
> > the
> > following error was found to exist.
> > ERROR: space required after that ',' (ctx:VxV)
> >
> > Fixed the above error which was found on line #721 by inserting a blank
> > space at the appropriate position.
[]
> > diff --git a/drivers/staging/rtl8188eu/core/rtw_security.c
> > b/drivers/staging/rtl8188eu/core/rtw_security.c
[]
> > @@ -718,7 +718,7 @@ u32 rtw_tkip_decrypt(struct adapter *padapter, u8
> > *precvframe)
> > res = _FAIL;
> > }
> > } else {
> > - RT_TRACE(_module_rtl871x_security_c_, _drv_err_, ("%s:
> > stainfo==NULL!!!\n",__func__));
> > + RT_TRACE(_module_rtl871x_security_c_, _drv_err_, ("%s:
> > stainfo==NULL!!!\n", __func__));
> > res = _FAIL;
> > }
> > }
>
> In fixing one checkpatch.pl condition, you introduced another - the resulting
> line is too long. You should fix only one such condition, but you should fix
> any
> others that are introduced. You do need to document it.
I think that doesn't matter as it was also too long
before this change.
> Patch subjects for this driver should be written as "staging: rtl8188eu:
> .".
How likely is it that this driver would ever be
moved to drivers/net/wireless/realtek/rtlwifi?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] STAGING - REALTEK RTL8188EU DRIVERS: Fix Coding Style Error
On 7/25/20 1:39 PM, Joe Perches wrote:
On Sat, 2020-07-25 at 12:47 -0500, Larry Finger wrote:
On 7/25/20 7:20 AM, Anant Thazhemadam wrote:
Running the checkpatch.pl script on the file for which patch was created, the
following error was found to exist.
ERROR: space required after that ',' (ctx:VxV)
Fixed the above error which was found on line #721 by inserting a blank
space at the appropriate position.
[]
diff --git a/drivers/staging/rtl8188eu/core/rtw_security.c
b/drivers/staging/rtl8188eu/core/rtw_security.c
[]
@@ -718,7 +718,7 @@ u32 rtw_tkip_decrypt(struct adapter *padapter, u8
*precvframe)
res = _FAIL;
}
} else {
- RT_TRACE(_module_rtl871x_security_c_, _drv_err_, ("%s:
stainfo==NULL!!!\n",__func__));
+ RT_TRACE(_module_rtl871x_security_c_, _drv_err_, ("%s:
stainfo==NULL!!!\n", __func__));
res = _FAIL;
}
}
In fixing one checkpatch.pl condition, you introduced another - the resulting
line is too long. You should fix only one such condition, but you should fix any
others that are introduced. You do need to document it.
I think that doesn't matter as it was also too long
before this change.
Patch subjects for this driver should be written as "staging: rtl8188eu: .".
How likely is it that this driver would ever be
moved to drivers/net/wireless/realtek/rtlwifi?
Very unlikely. It I wanted to undertake that kind of effort, I would switch to
one of the later versions from Realtek that uses nl80211/cfg80211. Despite that,
it is likely that only the USB driver from rtlwifi could be used.
Larry
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] STAGING - REALTEK RTL8188EU DRIVERS: Fix Coding Style Error
On 7/25/20 7:20 AM, Anant Thazhemadam wrote:
Running the checkpatch.pl script on the file for which patch was created, the
following error was found to exist.
ERROR: space required after that ',' (ctx:VxV)
Fixed the above error which was found on line #721 by inserting a blank
space at the appropriate position.
Signed-off-by: Anant Thazhemadam
---
drivers/staging/rtl8188eu/core/rtw_security.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_security.c
b/drivers/staging/rtl8188eu/core/rtw_security.c
index 21f6652dd69f..57e171d3e48d 100644
--- a/drivers/staging/rtl8188eu/core/rtw_security.c
+++ b/drivers/staging/rtl8188eu/core/rtw_security.c
@@ -718,7 +718,7 @@ u32 rtw_tkip_decrypt(struct adapter *padapter, u8
*precvframe)
res = _FAIL;
}
} else {
- RT_TRACE(_module_rtl871x_security_c_, _drv_err_, ("%s:
stainfo==NULL!!!\n",__func__));
+ RT_TRACE(_module_rtl871x_security_c_, _drv_err_, ("%s:
stainfo==NULL!!!\n", __func__));
res = _FAIL;
}
}
In fixing one checkpatch.pl condition, you introduced another - the resulting
line is too long. You should fix only one such condition, but you should fix any
others that are introduced. You do need to document it.
Patch subjects for this driver should be written as "staging: rtl8188eu: .".
Larry
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V3] staging: rtl8723bs: core: Using comparison to true is error prone
On Sat, Jul 25, 2020 at 07:21:24PM +0200, Greg KH wrote: > On Sat, Jul 25, 2020 at 03:37:12PM +0100, John Oldman wrote: > > clear below issues reported by checkpatch.pl: > > > > CHECK: Using comparison to true is error prone > > Again, you did more than just this in the patch :( do you mean by reducing line lengths?? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V3] staging: rtl8723bs: core: Using comparison to true is error prone
On Sat, Jul 25, 2020 at 03:37:12PM +0100, John Oldman wrote: > clear below issues reported by checkpatch.pl: > > CHECK: Using comparison to true is error prone Again, you did more than just this in the patch :( ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V3] staging: rtl8723bs: core: Using comparison to true is error prone
clear below issues reported by checkpatch.pl:
CHECK: Using comparison to true is error prone
Signed-off-by: John Oldman
---
v1- First attempt: removed comparison to true.
v2- Removed unneccessary parentheses around 'pregistrypriv->ht_enable, missed
in v1.
v3- Corrected the 'odd' subject line; moved the || and && to the end of the
line.
drivers/staging/rtl8723bs/core/rtw_ieee80211.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
index ca98274ae390..46fad71197b6 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
@@ -363,8 +363,9 @@ int rtw_generate_ie(struct registry_priv *pregistrypriv)
}
/* HT Cap. */
- if (((pregistrypriv->wireless_mode_11_5N) ||
(pregistrypriv->wireless_mode_11_24N))
- && (pregistrypriv->ht_enable == true)) {
+ if (((pregistrypriv->wireless_mode & WIRELESS_11_5N) ||
+(pregistrypriv->wireless_mode & WIRELESS_11_24N)) &&
+pregistrypriv->ht_enable) {
/* todo: */
}
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V2] Subject: [PATCH] staging: rtl8723bs: core: Using comparison to true is error prone
On Sat, Jul 25, 2020 at 03:34:34PM +0200, Greg KH wrote:
> On Sat, Jul 25, 2020 at 02:28:06PM +0100, John Oldman wrote:
> > clear below issues reported by checkpatch.pl:
> >
> > CHECK: Using comparison to true is error prone
>
> Your subject line is very odd :(
Thanks, I should read all before I send: I will re-send the patch.
>
> > Signed-off-by: John Oldman
> > ---
> > v1: Initial attempt.
> > v2: Removed unneccessary parentheses around 'pregistrypriv->ht_enable'
> > Also considered clearing 'CHECK: Logical continuations should be on the
> > previous line' report
> > but this results in exceeding line length guideline.
> > drivers/staging/rtl8723bs/core/rtw_ieee80211.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
> > b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
> > index ca98274ae390..7aacbe1b763e 100644
> > --- a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
> > +++ b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
> > @@ -363,8 +363,9 @@ int rtw_generate_ie(struct registry_priv *pregistrypriv)
> > }
> >
> > /* HT Cap. */
> > - if (((pregistrypriv->wireless_mode_11_5N) ||
> > (pregistrypriv->wireless_mode_11_24N))
> > - && (pregistrypriv->ht_enable == true)) {
> > + if (((pregistrypriv->wireless_mode & WIRELESS_11_5N)
> > + || (pregistrypriv->wireless_mode & WIRELESS_11_24N))
> > + && pregistrypriv->ht_enable) {
>
> || and && go on the end of the line, not the front.
>
> But you also changed other things that were not needed here, and you did
> not say that in your changelog text :(
>
> thanks,
>
> greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V2] Subject: [PATCH] staging: rtl8723bs: core: Using comparison to true is error prone
On Sat, Jul 25, 2020 at 02:28:06PM +0100, John Oldman wrote:
> clear below issues reported by checkpatch.pl:
>
> CHECK: Using comparison to true is error prone
Your subject line is very odd :(
> Signed-off-by: John Oldman
> ---
> v1: Initial attempt.
> v2: Removed unneccessary parentheses around 'pregistrypriv->ht_enable'
> Also considered clearing 'CHECK: Logical continuations should be on the
> previous line' report
> but this results in exceeding line length guideline.
> drivers/staging/rtl8723bs/core/rtw_ieee80211.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
> b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
> index ca98274ae390..7aacbe1b763e 100644
> --- a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
> +++ b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
> @@ -363,8 +363,9 @@ int rtw_generate_ie(struct registry_priv *pregistrypriv)
> }
>
> /* HT Cap. */
> - if (((pregistrypriv->wireless_mode_11_5N) ||
> (pregistrypriv->wireless_mode_11_24N))
> - && (pregistrypriv->ht_enable == true)) {
> + if (((pregistrypriv->wireless_mode & WIRELESS_11_5N)
> + || (pregistrypriv->wireless_mode & WIRELESS_11_24N))
> + && pregistrypriv->ht_enable) {
|| and && go on the end of the line, not the front.
But you also changed other things that were not needed here, and you did
not say that in your changelog text :(
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2] Subject: [PATCH] staging: rtl8723bs: core: Using comparison to true is error prone
clear below issues reported by checkpatch.pl:
CHECK: Using comparison to true is error prone
Signed-off-by: John Oldman
---
v1: Initial attempt.
v2: Removed unneccessary parentheses around 'pregistrypriv->ht_enable'
Also considered clearing 'CHECK: Logical continuations should be on the
previous line' report
but this results in exceeding line length guideline.
drivers/staging/rtl8723bs/core/rtw_ieee80211.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
index ca98274ae390..7aacbe1b763e 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
@@ -363,8 +363,9 @@ int rtw_generate_ie(struct registry_priv *pregistrypriv)
}
/* HT Cap. */
- if (((pregistrypriv->wireless_mode_11_5N) ||
(pregistrypriv->wireless_mode_11_24N))
- && (pregistrypriv->ht_enable == true)) {
+ if (((pregistrypriv->wireless_mode & WIRELESS_11_5N)
+ || (pregistrypriv->wireless_mode & WIRELESS_11_24N))
+ && pregistrypriv->ht_enable) {
/* todo: */
}
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] media: cedrus: Add support for VP8 decoding
Hi Jernej,
As you know, I'm not familiar with this hardware,
but I've tried to take a detailed look anyway.
The driver looks mostly good to me, I just have
some minor comments.
More importantly, seems the current uAPI
control is supporting this platform nicely,
which gives us some confidence to mark it
as stable.
Comments below.
On Wed, 22 Jul 2020 at 17:35, Jernej Skrabec wrote:
>
> VP8 in Cedrus shares same engine as H264.
>
> Note that it seems necessary to call bitstream parsing functions,
> to parse frame header, otherwise decoded image is garbage. This is
> contrary to what is driver supposed to do. However, values are not
> really used, so this might be acceptable. It's possible that bitstream
> parsing functions set some internal VPU state, which is later necessary
> for proper decoding. Biggest suspect is "VP8 probs update" trigger.
>
I suggest that you also put this explanation here, as a comment
in the cedrus_vp8.c
> Signed-off-by: Jernej Skrabec
> ---
> Changes in v2:
> - rebased on top of current linux-media master branch
>
> drivers/staging/media/sunxi/cedrus/Makefile | 3 +-
> drivers/staging/media/sunxi/cedrus/cedrus.c | 8 +
> drivers/staging/media/sunxi/cedrus/cedrus.h | 15 +
> .../staging/media/sunxi/cedrus/cedrus_dec.c | 5 +
> .../staging/media/sunxi/cedrus/cedrus_hw.c| 1 +
> .../staging/media/sunxi/cedrus/cedrus_regs.h | 80 ++
> .../staging/media/sunxi/cedrus/cedrus_video.c | 9 +
> .../staging/media/sunxi/cedrus/cedrus_vp8.c | 699 ++
> 8 files changed, 819 insertions(+), 1 deletion(-)
> create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_vp8.c
>
> diff --git a/drivers/staging/media/sunxi/cedrus/Makefile
> b/drivers/staging/media/sunxi/cedrus/Makefile
> index 1bce49d3e7e2..a647b3690bf8 100644
> --- a/drivers/staging/media/sunxi/cedrus/Makefile
> +++ b/drivers/staging/media/sunxi/cedrus/Makefile
> @@ -2,4 +2,5 @@
> obj-$(CONFIG_VIDEO_SUNXI_CEDRUS) += sunxi-cedrus.o
>
> sunxi-cedrus-y = cedrus.o cedrus_video.o cedrus_hw.o cedrus_dec.o \
> -cedrus_mpeg2.o cedrus_h264.o cedrus_h265.o
> +cedrus_mpeg2.o cedrus_h264.o cedrus_h265.o \
> +cedrus_vp8.o
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c
> b/drivers/staging/media/sunxi/cedrus/cedrus.c
> index bc27f9430eeb..b2f5f03ad4a3 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> @@ -135,6 +135,13 @@ static const struct cedrus_control cedrus_controls[] = {
> .codec = CEDRUS_CODEC_H265,
> .required = false,
> },
> + {
> + .cfg = {
> + .id =
> V4L2_CID_MPEG_VIDEO_VP8_FRAME_HEADER,
> + },
> + .codec = CEDRUS_CODEC_VP8,
> + .required = true,
> + },
> };
>
> #define CEDRUS_CONTROLS_COUNT ARRAY_SIZE(cedrus_controls)
> @@ -381,6 +388,7 @@ static int cedrus_probe(struct platform_device *pdev)
> dev->dec_ops[CEDRUS_CODEC_MPEG2] = _dec_ops_mpeg2;
> dev->dec_ops[CEDRUS_CODEC_H264] = _dec_ops_h264;
> dev->dec_ops[CEDRUS_CODEC_H265] = _dec_ops_h265;
> + dev->dec_ops[CEDRUS_CODEC_VP8] = _dec_ops_vp8;
>
> mutex_init(>dev_mutex);
>
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h
> b/drivers/staging/media/sunxi/cedrus/cedrus.h
> index 9676ab8a..9f4605afa0f4 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus.h
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
> @@ -35,6 +35,7 @@ enum cedrus_codec {
> CEDRUS_CODEC_MPEG2,
> CEDRUS_CODEC_H264,
> CEDRUS_CODEC_H265,
> + CEDRUS_CODEC_VP8,
> CEDRUS_CODEC_LAST,
> };
>
> @@ -75,6 +76,10 @@ struct cedrus_h265_run {
> const struct v4l2_ctrl_hevc_slice_params*slice_params;
> };
>
> +struct cedrus_vp8_run {
> + const struct v4l2_ctrl_vp8_frame_header *slice_params;
I don't think VP8 has any concept of slice, as H264 does.
I think it's misleading to call this parameter as slice_params.
> +};
> +
> struct cedrus_run {
> struct vb2_v4l2_buffer *src;
> struct vb2_v4l2_buffer *dst;
> @@ -83,6 +88,7 @@ struct cedrus_run {
> struct cedrus_h264_run h264;
> struct cedrus_mpeg2_run mpeg2;
> struct cedrus_h265_run h265;
> + struct cedrus_vp8_run vp8;
> };
> };
>
> @@ -134,6 +140,14 @@ struct cedrus_ctx {
> void*neighbor_info_buf;
> dma_addr_t neighbor_info_buf_addr;
> } h265;
> + struct {
> + unsigned intlast_frame_p_type;
> + unsigned intlast_filter_type;
> + unsigned intlast_sharpness_level;
> +
> + u8 *entropy_probs_buf;
> +
Re: [PATCH v4] staging: nvec: change usage of slave to secondary
On 25/07/20 6:20 pm, Michał Mirosław wrote: > On Sat, Jul 25, 2020 at 06:01:19PM +0530, Rohit K Bharadwaj wrote: >> On 25/07/20 5:31 pm, Michał Mirosław wrote: >>> On Sat, Jul 25, 2020 at 11:59:39AM +0530, Rohit K Bharadwaj wrote: changed usage of slave (which is deprecated) to secondary without breaking the driver >>> >>> The relevant I2C and SMBus standards use master/slave terminology. Why are >>> you changing the names to something unfamiliar? >>> >>> If the reason are the recent coding-style changes, then please note they >>> are about avoiding introducing *NEW* uses of the specific words and not >>> about blindly replacing existing occurrences. >> >> I'm really sorry sir, I didn't knew about this, yes the reason for my change >> is according to the script checkpatch.pl to suit the coding style, I would >> try to fix some other coding style related issues if this patch seems to be >> a bad idea. > > I didn't know checkpatch does this (it doesn't in current Linus' master > tree). I can see there is a commit in next adding this, but seems that > it uses a test far from the original coding-style wording... > > Best Regards > Michał Mirosław > yes sir, in the linux-next tree, when I ran the script on this file it showed me it had style issues and the usage of slave is deprecated and it suggested me to replace it with secondary or target. and hence I made this patch, please do let me know if this patch can be acceptable or not. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] staging: nvec: change usage of slave to secondary
On Sat, Jul 25, 2020 at 06:01:19PM +0530, Rohit K Bharadwaj wrote: > On 25/07/20 5:31 pm, Michał Mirosław wrote: > > On Sat, Jul 25, 2020 at 11:59:39AM +0530, Rohit K Bharadwaj wrote: > >> changed usage of slave (which is deprecated) to secondary without breaking > >> the driver > > > > The relevant I2C and SMBus standards use master/slave terminology. Why are > > you changing the names to something unfamiliar? > > > > If the reason are the recent coding-style changes, then please note they > > are about avoiding introducing *NEW* uses of the specific words and not > > about blindly replacing existing occurrences. > > I'm really sorry sir, I didn't knew about this, yes the reason for my change > is according to the script checkpatch.pl to suit the coding style, I would > try to fix some other coding style related issues if this patch seems to be a > bad idea. I didn't know checkpatch does this (it doesn't in current Linus' master tree). I can see there is a commit in next adding this, but seems that it uses a test far from the original coding-style wording... Best Regards Michał Mirosław ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] staging: nvec: change usage of slave to secondary
On 25/07/20 5:31 pm, Michał Mirosław wrote: > On Sat, Jul 25, 2020 at 11:59:39AM +0530, Rohit K Bharadwaj wrote: >> changed usage of slave (which is deprecated) to secondary without breaking >> the driver > > The relevant I2C and SMBus standards use master/slave terminology. Why are > you changing the names to something unfamiliar? > > If the reason are the recent coding-style changes, then please note they > are about avoiding introducing *NEW* uses of the specific words and not > about blindly replacing existing occurrences. > > Best Regards > Michał Mirosław > I'm really sorry sir, I didn't knew about this, yes the reason for my change is according to the script checkpatch.pl to suit the coding style, I would try to fix some other coding style related issues if this patch seems to be a bad idea. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/1] STAGING - REALTEK RTL8188EU DRIVERS: Fix Coding Style Error
Running the checkpatch.pl script on the file for which patch was created, the
following error was found to exist.
ERROR: space required after that ',' (ctx:VxV)
Fixed the above error which was found on line #721 by inserting a blank
space at the appropriate position.
Signed-off-by: Anant Thazhemadam
---
drivers/staging/rtl8188eu/core/rtw_security.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_security.c
b/drivers/staging/rtl8188eu/core/rtw_security.c
index 21f6652dd69f..57e171d3e48d 100644
--- a/drivers/staging/rtl8188eu/core/rtw_security.c
+++ b/drivers/staging/rtl8188eu/core/rtw_security.c
@@ -718,7 +718,7 @@ u32 rtw_tkip_decrypt(struct adapter *padapter, u8
*precvframe)
res = _FAIL;
}
} else {
- RT_TRACE(_module_rtl871x_security_c_, _drv_err_, ("%s:
stainfo==NULL!!!\n",__func__));
+ RT_TRACE(_module_rtl871x_security_c_, _drv_err_, ("%s:
stainfo==NULL!!!\n", __func__));
res = _FAIL;
}
}
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] staging: nvec: change usage of slave to secondary
On Sat, Jul 25, 2020 at 11:59:39AM +0530, Rohit K Bharadwaj wrote: > changed usage of slave (which is deprecated) to secondary without breaking > the driver The relevant I2C and SMBus standards use master/slave terminology. Why are you changing the names to something unfamiliar? If the reason are the recent coding-style changes, then please note they are about avoiding introducing *NEW* uses of the specific words and not about blindly replacing existing occurrences. Best Regards Michał Mirosław ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Fix one coding style issue
On Sat, Jul 25, 2020 at 04:00:03PM +0530, Anant Thazhemadam wrote:
> The coding style issue that raised an error (upon checking against
> checkpatch.pl) has been fixed.
You are not saying what issue was fixed.
Also, your subject line needs to be fixed, please see the link provided
by the bot previously for what to do.
> Exactly one coding style issue has been fixed; as required by Task 10
> of the Eudyptula Challenge.
We don't care why you are doing this work, no need to put that in the
changelog.
>
> Signed-off-by: Anant Thazhemadam
> ---
> drivers/staging/rtl8188eu/core/rtw_security.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/rtl8188eu/core/rtw_security.c
> b/drivers/staging/rtl8188eu/core/rtw_security.c
> index 21f6652dd69f..dc22ee9c24ad 100644
> --- a/drivers/staging/rtl8188eu/core/rtw_security.c
> +++ b/drivers/staging/rtl8188eu/core/rtw_security.c
> @@ -718,7 +718,9 @@ u32 rtw_tkip_decrypt(struct adapter *padapter, u8
> *precvframe)
> res = _FAIL;
> }
> } else {
> - RT_TRACE(_module_rtl871x_security_c_, _drv_err_, ("%s:
> stainfo==NULL!!!\n",__func__));
> + RT_TRACE(_module_rtl871x_security_c_, _drv_err_,
> + ("%s: stainfo==NULL!!!\n", __func__)
> + );
Very odd line breaks, this now looks worse than before :(
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Fix one coding style issue
The coding style issue that raised an error (upon checking against
checkpatch.pl) has been fixed.
Exactly one coding style issue has been fixed; as required by Task 10
of the Eudyptula Challenge.
Signed-off-by: Anant Thazhemadam
---
drivers/staging/rtl8188eu/core/rtw_security.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_security.c
b/drivers/staging/rtl8188eu/core/rtw_security.c
index 21f6652dd69f..dc22ee9c24ad 100644
--- a/drivers/staging/rtl8188eu/core/rtw_security.c
+++ b/drivers/staging/rtl8188eu/core/rtw_security.c
@@ -718,7 +718,9 @@ u32 rtw_tkip_decrypt(struct adapter *padapter, u8
*precvframe)
res = _FAIL;
}
} else {
- RT_TRACE(_module_rtl871x_security_c_, _drv_err_, ("%s:
stainfo==NULL!!!\n",__func__));
+ RT_TRACE(_module_rtl871x_security_c_, _drv_err_,
+("%s: stainfo==NULL!!!\n", __func__)
+ );
res = _FAIL;
}
}
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
good day
I sent you a mesaage,did you receive that?Please let me know. Tony ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] media: atomisp-mt9m114: replace fixed function names
There are a couple of debug messages using hardcoded function names
instead of the preferred __func__ magic constant.
Replace them:
WARNING: Prefer using '"%s...", __func__' to using 'misensor_rmw_reg', this
function's name, in a string
215: FILE: ./media/atomisp/i2c/atomisp-mt9m114.c:215:
+ v4l2_err(client, "misensor_rmw_reg error exit, read failed\n");
WARNING: Prefer using '"%s...", __func__' to using 'misensor_rmw_reg', this
function's name, in a string
236: FILE: ./media/atomisp/i2c/atomisp-mt9m114.c:236:
+ v4l2_err(client, "misensor_rmw_reg error exit, write failed\n");
Signed-off-by: Juan Antonio Aldea-Armenteros
---
drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c
b/drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c
index 0d60918a9b19..54c24bc2061d 100644
--- a/drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c
+++ b/drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c
@@ -212,7 +212,7 @@ misensor_rmw_reg(struct i2c_client *client, u16
data_length, u16 reg,
err = mt9m114_read_reg(client, data_length, reg, );
if (err) {
- v4l2_err(client, "misensor_rmw_reg error exit, read failed\n");
+ v4l2_err(client, "%s exit, read failed\n", __func__);
return -EINVAL;
}
@@ -233,7 +233,7 @@ misensor_rmw_reg(struct i2c_client *client, u16
data_length, u16 reg,
err = mt9m114_write_reg(client, data_length, reg, val);
if (err) {
- v4l2_err(client, "misensor_rmw_reg error exit, write failed\n");
+ v4l2_err(client, "%s error exit, write failed\n", __func__);
return -EINVAL;
}
--
2.27.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 4/7] crypto: remove ARC4 support from the skcipher API
On Sat, 18 Jul 2020 at 11:18, Ard Biesheuvel wrote: > > On Fri, 3 Jul 2020 at 02:04, Ard Biesheuvel wrote: > > > > On Thu, 2 Jul 2020 at 20:21, Ard Biesheuvel wrote: > > > > > > On Thu, 2 Jul 2020 at 19:50, Eric Biggers wrote: > > > > > > > > [+linux-wireless, Marcel Holtmann, and Denis Kenzior] > > > > > > > > On Thu, Jul 02, 2020 at 12:19:44PM +0200, Ard Biesheuvel wrote: > > > > > Remove the generic ecb(arc4) skcipher, which is slightly cumbersome > > > > > from > > > > > a maintenance perspective, since it does not quite behave like other > > > > > skciphers do in terms of key vs IV lifetime. Since we are leaving the > > > > > library interface in place, which is used by the various WEP and TKIP > > > > > implementations we have in the tree, we can safely drop this code now > > > > > it no longer has any users. > > > > > > > > > > Signed-off-by: Ard Biesheuvel > > > > > > > > Last year there was a discussion where it was mentioned that iwd uses > > > > "ecb(arc4)" via AF_ALG. So can we really remove it yet? > > > > See > > > > https://lkml.kernel.org/r/97bb95f6-4a4c-4984-9eab-6069e19b4...@holtmann.org > > > > Note that the code isn't in "iwd" itself but rather in "libell" which > > > > iwd > > > > depends on: https://git.kernel.org/pub/scm/libs/ell/ell.git/ > > > > > > > > Apparently it also uses md4 and ecb(des) too. > > > > > > > > > > Ah yes, I remember now :-( > > > > > > > Marcel and Denis, what's your deprecation plan for these obsolete and > > > > insecure > > > > algorithms? > > > > > > > > > > Given Denis's statement: > > > > > > It sounds to me like it was broken and should be fixed. So our vote / > > > preference is to have ARC4 fixed to follow the proper semantics. We > > > can deal with the kernel behavioral change on our end easily enough; > > > the required workarounds are the worse evil. > > > > > > I would think that an ABI break is not the end of the world for them, > > > and given how trivial it is to implement RC4 in C, the workaround > > > should be to simply implement RC4 in user space, and not even bother > > > trying to use AF_ALG to get at ecb(arc4) > > > > > > (same applies to md4 and ecb(des) btw) > > > > > > There will always be a long tail of use cases, and at some point, we > > > just have to draw the line and remove obsolete and insecure cruft, > > > especially when it impedes progress on other fronts. > > > > > > > I have ported iwd to Nettle's LGPL 2.1 implementation of ARC4, and the > > diffstat is > > > > src/crypto.c | 80 > > src/main.c| 8 -- > > unit/test-eapol.c | 3 +- > > 3 files changed, 51 insertions(+), 40 deletions(-) > > > > https://git.kernel.org/pub/scm/linux/kernel/git/ardb/iwd.git/log/?h=arc4-cleanup > > Marcel, Denis, > > Do you have any objections to the ecb(arc4) skcipher being dropped > from the kernel, given the fallback i proposed above (which is a much > better way of doing rc4 in user space anyway)? > > For libell, I would suggest dropping rc4 entirely, once iwd stops > relying on it, as using rc4 for tls is obsolete as well. Ping? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: nvec: change usage of slave to secondary
On 25/07/20 2:12 am, Marc Dietrich wrote:
>
> Hi Rohit,
>
> On Fri, 24 Jul 2020, Rohit K Bharadwaj wrote:
>
>> On 24/07/20 10:06 pm, Marc Dietrich wrote:
>>>
>>>
>>> On Fri, 24 Jul 2020, Marc Dietrich wrote:
>>>
Hi Rohit,
On Fri, 24 Jul 2020, Rohit Bharadwaj wrote:
> On 24/07/20 1:58 pm, Greg KH wrote:
>> On Fri, Jul 24, 2020 at 01:44:27PM +0530, Rohit Bharadwaj wrote:
>>> On 24/07/20 10:06 am, Rohit K Bharadwaj wrote:
changed usage of slave (deprecated) to secondary
Signed-off-by: Rohit K Bharadwaj
---
v3: change patch subject, add version history
v2: add changelog text in body of mail
v1: fix style issues by changing usage of slave to secondary
drivers/staging/nvec/nvec.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
index 360ec0407740..5d7b66719a39 100644
--- a/drivers/staging/nvec/nvec.c
+++ b/drivers/staging/nvec/nvec.c
@@ -718,7 +718,7 @@ static irqreturn_t nvec_interrupt(int irq, void
*dev)
return IRQ_HANDLED;
}
-static void tegra_init_i2c_slave(struct nvec_chip *nvec)
+static void tegra_init_i2c_secondary(struct nvec_chip *nvec)
{
u32 val;
@@ -744,7 +744,7 @@ static void tegra_init_i2c_slave(struct nvec_chip
*nvec)
}
#ifdef CONFIG_PM_SLEEP
-static void nvec_disable_i2c_slave(struct nvec_chip *nvec)
+static void nvec_disable_i2c_secondary(struct nvec_chip *nvec)
{
disable_irq(nvec->irq);
writel(I2C_SL_NEWSL | I2C_SL_NACK, nvec->base + I2C_SL_CNFG);
@@ -784,7 +784,7 @@ static int tegra_nvec_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, nvec);
nvec->dev = dev;
- if (of_property_read_u32(dev->of_node, "slave-addr",
>i2c_addr)) {
+ if (of_property_read_u32(dev->of_node, "secondary-addr",
>i2c_addr)) {
dev_err(dev, "no i2c address specified");
return -ENODEV;
}
as Christoph said, please don't change this line.
>>>
>>> arr, I meant Dan of course ;-)
>> Dear all, thank you so much for your inputs, I will try to make some other
>> patch which will not break the driver (hopefully :p), or if you give me
>> permission to submit this patch itself by just keeping this one line
>>
>>> if (of_property_read_u32(dev->of_node, "slave-addr", >i2c_addr))
>>
>> unchanged, and provided it does not break the driver by doing so, I would
>> gladly make the changes and submit v4 of the patch.
>
> please resend the patch with the line above unchanged as v4. Don't forget to
> to update the changelog to the commit message. I tested your patch (without
> the dt property change) and it does not change behavoir - as expected,
> so you will recevice my Ack.
>
> Marc
Thank you so much for the suggestions and the Ack sir, I have made the
necessary changes and I have sent the v4 of the patch.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v4] staging: nvec: change usage of slave to secondary
changed usage of slave (which is deprecated) to secondary without breaking the
driver
Tested-by: Dan Carpenter
Acked-by: Marc Dietrich
Signed-off-by: Rohit K Bharadwaj
---
v4: undo the changes (which broke the driver) to this line: if
(of_property_read_u32(dev->of_node, "slave-addr", >i2c_addr))
v3: change patch subject, add version history
v2: add changelog text in body of mail
v1: fix style issues by changing usage of slave to secondary
drivers/staging/nvec/nvec.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
index 360ec0407740..a7e995bfe989 100644
--- a/drivers/staging/nvec/nvec.c
+++ b/drivers/staging/nvec/nvec.c
@@ -718,7 +718,7 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
return IRQ_HANDLED;
}
-static void tegra_init_i2c_slave(struct nvec_chip *nvec)
+static void tegra_init_i2c_secondary(struct nvec_chip *nvec)
{
u32 val;
@@ -744,7 +744,7 @@ static void tegra_init_i2c_slave(struct nvec_chip *nvec)
}
#ifdef CONFIG_PM_SLEEP
-static void nvec_disable_i2c_slave(struct nvec_chip *nvec)
+static void nvec_disable_i2c_secondary(struct nvec_chip *nvec)
{
disable_irq(nvec->irq);
writel(I2C_SL_NEWSL | I2C_SL_NACK, nvec->base + I2C_SL_CNFG);
@@ -839,7 +839,7 @@ static int tegra_nvec_probe(struct platform_device *pdev)
}
disable_irq(nvec->irq);
- tegra_init_i2c_slave(nvec);
+ tegra_init_i2c_secondary(nvec);
/* enable event reporting */
nvec_toggle_global_events(nvec, true);
@@ -913,7 +913,7 @@ static int nvec_suspend(struct device *dev)
if (!err)
nvec_msg_free(nvec, msg);
- nvec_disable_i2c_slave(nvec);
+ nvec_disable_i2c_secondary(nvec);
return 0;
}
@@ -923,7 +923,7 @@ static int nvec_resume(struct device *dev)
struct nvec_chip *nvec = dev_get_drvdata(dev);
dev_dbg(nvec->dev, "resuming\n");
- tegra_init_i2c_slave(nvec);
+ tegra_init_i2c_secondary(nvec);
nvec_toggle_global_events(nvec, true);
return 0;
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE
I am Maureen Hinckley and my foundation is donating (Five hundred and fifty thousand USD) to you. Contact us via my email at (maurhin...@gmail.com) for further details. Best Regards, Mrs. Maureen Hinckley, Copyright ©2020 The Maureen Hinckley Foundation All Rights Reserved. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
