Re: [PATCH v6] staging: sm750: Rename sm750_hw_cursor_* functions to snake_case

2023-03-29 Thread Greg Kroah-Hartman
On Wed, Mar 29, 2023 at 07:27:04PM +0800, Kloudifold wrote:
> sm750 driver has sm750_hw_cursor_* functions, which are named in
> camelcase. Rename them to snake case to follow the function naming
> convention.
> 
> - sm750_hw_cursor_setSize  => sm750_hw_cursor_set_size
> - sm750_hw_cursor_setPos   => sm750_hw_cursor_set_pos
> - sm750_hw_cursor_setColor => sm750_hw_cursor_set_color
> - sm750_hw_cursor_setData  => sm750_hw_cursor_set_data
> - sm750_hw_cursor_setData2 => sm750_hw_cursor_set_data2
> 
> Reported-by: kernel test robot 

The test robot did not report that the names were incorrect :(

> Link: 
> https://lore.kernel.org/oe-kbuild-all/202303110849.x24wnhnm-...@intel.com/
> Signed-off-by: Kloudifold 

Is that the name you use to sign documents?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: android: ashmem.c: Declared file operation with const keyword

2023-03-09 Thread Greg Kroah-Hartman
On Mon, Mar 06, 2023 at 12:30:57AM +0530, Santosh Mahto wrote:
> Warning found by checkpatch.pl script.
> 
> Signed-off-by: Santosh Mahto 
> ---
>  drivers/staging/android/ashmem.c | 2 +-

What kernel did you make this against?  This is not in my tree anymore.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [driver-core:driver-core-testing 77/77] drivers/base/base.h:221:63: error: void function 'devtmpfs_delete_node' should not return a value

2023-02-11 Thread Greg Kroah-Hartman
On Fri, Feb 10, 2023 at 11:38:45PM +0800, kernel test robot wrote:
> tree:   
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git 
> driver-core-testing
> head:   ecfd9f08fe2ef7616477c089dce1b0f05dcee13c
> commit: ecfd9f08fe2ef7616477c089dce1b0f05dcee13c [77/77] devtmpfs: remove 
> return value of devtmpfs_delete_node()
> config: arm-randconfig-r006-20230210 
> (https://download.01.org/0day-ci/archive/20230210/202302102345.uqfdskhw-...@intel.com/config)
> compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project 
> db0e6591612b53910a1b366863348bdb9d7d2fb1)
> reproduce (this is a W=1 build):
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # install arm cross compiling tool for clang build
> # apt-get install binutils-arm-linux-gnueabi
> # 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/commit/?id=ecfd9f08fe2ef7616477c089dce1b0f05dcee13c
> git remote add driver-core 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
> git fetch --no-tags driver-core driver-core-testing
> git checkout ecfd9f08fe2ef7616477c089dce1b0f05dcee13c
> # save the config file
> mkdir build_dir && cp config build_dir/.config
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
> O=build_dir ARCH=arm olddefconfig
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
> O=build_dir ARCH=arm SHELL=/bin/bash drivers/
> 
> If you fix the issue, kindly add following tag where applicable
> | Reported-by: kernel test robot 
> | Link: 
> https://lore.kernel.org/oe-kbuild-all/202302102345.uqfdskhw-...@intel.com/
> 
> All errors (new ones prefixed by >>):
> 
>In file included from drivers/base/core.c:35:
> >> drivers/base/base.h:221:63: error: void function 'devtmpfs_delete_node' 
> >> should not return a value [-Wreturn-type]
>static inline void devtmpfs_delete_node(struct device *dev) { return 0; }
>  ^  ~
>1 error generated.

I've fixed this up by hand by modifying the original commit and pushing
out an update.  No need for a separate patch.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [driver-core:debugfs_lookup_fix] [mm/damon/dbgfs] ff25f87cfc: kernel_BUG_at_lib/list_debug.c

2023-01-05 Thread Greg Kroah-Hartman
On Wed, Jan 04, 2023 at 06:35:39PM +, SeongJae Park wrote:
> Hello,
> 
> On Tue, 3 Jan 2023 21:16:09 +0800 kernel test robot  
> wrote:
> 
> > [-- Attachment #1: Type: text/plain, Size: 7528 bytes --]
> > 
> > 
> > Greeting,
> > 
> > FYI, we noticed kernel_BUG_at_lib/list_debug.c due to commit (built with 
> > gcc-11):
> 
> Thank you for the report!
> 
> > 
> > commit: ff25f87cfcfc34ebe652987f2a7beb184762785b ("mm/damon/dbgfs: fix 
> > memory leak when using debugfs_lookup()")
> > https://git.kernel.org/cgit/linux/kernel/git/gregkh/driver-core.git 
> > debugfs_lookup_fix
> 
> The commit is for fixing a memory leak due to missed dput() call.  The patch
> has posted originally by Greg and revised my I[1].  The revised version has
> merged in mainline during v6.0 stabilization period (1552fd3ef7db).
> 
> The problematic tree (driver-core/debugfs_lookup_fix) is based on v6.2-rc2, so
> the revised patch is already applied.  But the first version of the patch is
> applied again on the tree[2], probably by mistake, and caused double 'dput()'.
> 
> So I think the commit seems needs to be reverted.
> 
> If there is anything I missed or wrong, please let me know.
> 
> [1] https://lore.kernel.org/damon/20220902191149.112434-1...@kernel.org/
> [2] 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/commit/?h=debugfs_lookup_fix=5167d3e8149e332204274910da1057e8f907d7d2

Yeah, this is my fault, sorry.  That branch/tree has not been looked at
carefully in a while, I need to refresh it properly and verify it all is
correct.  I'll drop this change as part of that work as well, sorry for
the noise.

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [staging:staging-testing 54/54] drivers/staging/r8188eu/core/rtw_pwrctrl.c:400:6: warning: variable 'ret' is used uninitialized whenever 'if' condition is false

2022-07-30 Thread Greg Kroah-Hartman
On Sat, Jul 30, 2022 at 04:14:57PM +0800, kernel test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
> staging-testing
> head:   f3a76018dd55d8ddcd28cb47049f46ae5c0ce557
> commit: f3a76018dd55d8ddcd28cb47049f46ae5c0ce557 [54/54] staging: r8188eu: 
> remove initializer from ret in rtw_pwr_wakeup
> config: hexagon-randconfig-r015-20220729 
> (https://download.01.org/0day-ci/archive/20220730/202207301623.bfmklfhv-...@intel.com/config)
> compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project 
> 52cd00cabf479aa7eb6dbb063b7ba41ea57bce9e)
> reproduce (this is a W=1 build):
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?id=f3a76018dd55d8ddcd28cb47049f46ae5c0ce557
> git remote add staging 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> git fetch --no-tags staging staging-testing
> git checkout f3a76018dd55d8ddcd28cb47049f46ae5c0ce557
> # save the config file
> mkdir build_dir && cp config build_dir/.config
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
> O=build_dir ARCH=hexagon SHELL=/bin/bash drivers/staging/r8188eu/
> 
> If you fix the issue, kindly add following tag where applicable
> Reported-by: kernel test robot 
> 
> All warnings (new ones prefixed by >>):
> 
> >> drivers/staging/r8188eu/core/rtw_pwrctrl.c:400:6: warning: variable 'ret' 
> >> is used uninitialized whenever 'if' condition is false 
> >> [-Wsometimes-uninitialized]
>if (padapter->bDriverStopped || !padapter->bup || 
> !padapter->hw_init_completed) {
>
> ^~
>drivers/staging/r8188eu/core/rtw_pwrctrl.c:409:9: note: uninitialized use 
> occurs here
>return ret;
>   ^~~
>drivers/staging/r8188eu/core/rtw_pwrctrl.c:400:2: note: remove the 'if' if 
> its condition is always true
>if (padapter->bDriverStopped || !padapter->bup || 
> !padapter->hw_init_completed) {
>
> ^~~~
>drivers/staging/r8188eu/core/rtw_pwrctrl.c:384:9: note: initialize the 
> variable 'ret' to silence this warning
>int ret;
>   ^
>= 0
>1 warning generated.

Phillip, can you send a follow-up patch for this issue?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [driver-core:driver-core-testing 30/34] fs/kernfs/file.c:160:46: sparse: sparse: incorrect type in argument 1 (different address spaces)

2022-04-27 Thread Greg Kroah-Hartman
On Wed, Apr 27, 2022 at 04:17:29AM +0800, kernel test robot wrote:
> tree:   
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git 
> driver-core-testing
> head:   26360a8c9732cff2ee5bc2f180e9716b63e9f650
> commit: 07b42a72474e4ab59d6acb451f7816664095d7c0 [30/34] kernfs: make 
> ->attr.open RCU protected.
> config: alpha-randconfig-s032-20220425 
> (https://download.01.org/0day-ci/archive/20220427/202204270438.uex7kt3b-...@intel.com/config)
> compiler: alpha-linux-gcc (GCC) 11.3.0
> reproduce:
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # apt-get install sparse
> # sparse version: v0.6.4-dirty
> # 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/commit/?id=07b42a72474e4ab59d6acb451f7816664095d7c0
> git remote add driver-core 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
> git fetch --no-tags driver-core driver-core-testing
> git checkout 07b42a72474e4ab59d6acb451f7816664095d7c0
> # save the config file
> mkdir build_dir && cp config build_dir/.config
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.3.0 make.cross C=1 
> CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=alpha 
> SHELL=/bin/bash fs/kernfs/
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 
> 
> 
> sparse warnings: (new ones prefixed by >>)
> >> fs/kernfs/file.c:160:46: sparse: sparse: incorrect type in argument 1 
> >> (different address spaces) @@ expected struct atomic_t const 
> >> [usertype] *v @@ got struct atomic_t [noderef] __rcu * @@
>fs/kernfs/file.c:160:46: sparse: expected struct atomic_t const 
> [usertype] *v
>fs/kernfs/file.c:160:46: sparse: got struct atomic_t [noderef] __rcu *
>fs/kernfs/file.c:204:46: sparse: sparse: incorrect type in argument 1 
> (different address spaces) @@ expected struct atomic_t const [usertype] 
> *v @@ got struct atomic_t [noderef] __rcu * @@
>fs/kernfs/file.c:204:46: sparse: expected struct atomic_t const 
> [usertype] *v
>fs/kernfs/file.c:204:46: sparse: got struct atomic_t [noderef] __rcu *
> 
> vim +160 fs/kernfs/file.c
> 
> 414985ae23c031e Tejun Heo 2013-11-28  155  
> 414985ae23c031e Tejun Heo 2013-11-28  156  static int kernfs_seq_show(struct 
> seq_file *sf, void *v)
> 414985ae23c031e Tejun Heo 2013-11-28  157  {
> c525aaddc366df2 Tejun Heo 2013-12-11  158 struct kernfs_open_file *of = 
> sf->private;
> 414985ae23c031e Tejun Heo 2013-11-28  159  
> adc5e8b58f4886d Tejun Heo 2013-12-11 @160 of->event = 
> atomic_read(>kn->attr.open->event);
> 414985ae23c031e Tejun Heo 2013-11-28  161  
> adc5e8b58f4886d Tejun Heo 2013-12-11  162 return 
> of->kn->attr.ops->seq_show(sf, v);
> 414985ae23c031e Tejun Heo 2013-11-28  163  }
> 414985ae23c031e Tejun Heo 2013-11-28  164  
> 
> :: The code at line 160 was first introduced by commit
> :: adc5e8b58f4886d45f79f4ff41a09001a76a6b12 kernfs: drop s_ prefix from 
> kernfs_node members
> 
> :: TO: Tejun Heo 
> :: CC: Greg Kroah-Hartman 
> 

Imran, I'm going to go drop this change from my tree and let you
resubmit it after it's been fixed up (you need to grab the rcu reference
on attr.open here.)

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v10 0/1] wfx: get out from the staging area

2022-04-07 Thread Greg Kroah-Hartman
On Wed, Apr 06, 2022 at 10:06:33AM +0300, Kalle Valo wrote:
> Jakub Kicinski  writes:
> 
> > On Tue, 05 Apr 2022 10:16:58 +0300 Kalle Valo wrote:
> >> Sure, that would technically work. But I just think it's cleaner to use
> >> -rc1 (or later) as the baseline for an immutable branch. If the baseline
> >> is an arbitrary commit somewhere within merge windows commits, it's more
> >> work for everyone to verify the branch is suitable.
> >> 
> >> Also in general I would also prefer to base -next trees to -rc1 or newer
> >> to make the bisect cleaner. The less we need to test kernels from the
> >> merge window (ie. commits after the final release and before -rc1) the
> >> better.
> >> 
> >> But this is just a small wish from me, I fully understand that it might
> >> be too much changes to your process. Wanted to point out this anyway.
> >
> > Forwarded!
> 
> Awesome, thank you Jakub!
> 
> Greg, I now created an immutable branch for moving wfx from
> drivers/staging to drivers/net/wireless/silabs:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git 
> wfx-move-out-of-staging
> 
> The baseline for this branch is v5.18-rc1. If you think the branch is
> ok, please pull it to staging-next and let me know. I can then pull the
> branch to wireless-next and the transition should be complete. And do
> let me know if there are any problems.

Looks great to me!  I've pulled it into staging-next now.  And will not
take any more patches to the driver (some happened before the merge but
git handled the move just fine.)

thanks!

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v10 0/1] wfx: get out from the staging area

2022-02-26 Thread Greg Kroah-Hartman
On Sat, Feb 26, 2022 at 12:41:41PM +0200, Kalle Valo wrote:
> + jakub
> 
> Jerome Pouiller  writes:
> 
> > The firmware and the PDS files (= antenna configurations) are now a part of
> > the linux-firmware repository.
> >
> > All the issues have been fixed in staging tree. I think we are ready to get
> > out from the staging tree for the kernel 5.18.
> 
> [...]
> 
> >  rename Documentation/devicetree/bindings/{staging => 
> > }/net/wireless/silabs,wfx.yaml (98%)
> 
> I lost track, is this file acked by the DT maintainers now?
> 
> What I suggest is that we queue this for v5.19. After v5.18-rc1 is
> released I could create an immutable branch containing this one commit.
> Then I would merge the branch to wireless-next and Greg could merge it
> to the staging tree, that way we would minimise the chance of conflicts
> between trees.
> 
> Greg, what do you think? Would this work for you? IIRC we did the same
> with wilc1000 back in 2020 and I recall it went without hiccups.

That sounds great to me, let's plan on that happening after 5.18-rc1 is
out.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: wfx: fix scan with WFM200 and WW regulation

2022-02-18 Thread Greg Kroah-Hartman
On Fri, Feb 18, 2022 at 11:57:47AM +0100, Jérôme Pouiller wrote:
> On Friday 18 February 2022 11:53:58 CET Jerome Pouiller wrote:
> > From: Riccardo Ferrazzo 
> > 
> > Some variants of the WF200 disallow active scan on channel 12 and 13.
> > For these parts, the channels 12 and 13 are marked IEEE80211_CHAN_NO_IR.
> > 
> > However, the beacon hint procedure was removing the flag
> > IEEE80211_CHAN_NO_IR from channels where a BSS is discovered. This was
> > making subsequent scans to fail because the driver was trying active
> > scans on prohibited channels.
> > 
> > Signed-off-by: Jérôme Pouiller 
> 
> I forgot to mention I have reviewed on this patch:
> 
> Reviewed-by: Jérôme Pouiller 

Reviwed-by is implied with signed-off-by.

But what happened to the signed-off-by from the author of this change?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 2/2] staging: wfx: apply the necessary SDIO quirks for the Silabs WF200

2022-02-17 Thread Greg Kroah-Hartman
On Thu, Feb 17, 2022 at 04:41:38PM +0100, Jérôme Pouiller wrote:
> On Thursday 17 February 2022 16:04:51 CET Kalle Valo wrote:
> > Ulf Hansson  writes:
> > > On Thu, 17 Feb 2022 at 10:59, Kalle Valo  wrote:
> > >> Jerome Pouiller  writes:
> > >> > From: Jérôme Pouiller 
> > >> >
> > >> > Until now, the SDIO quirks are applied directly from the driver.
> > >> > However, it is better to apply the quirks before driver probing. So,
> > >> > this patch relocate the quirks in the MMC framework.
> > >>
> > >> It would be good to know how this is better, what's the concrete
> > >> advantage?
> > >
> > > The mmc core has a quirk interface for all types of cards
> > > (eMMC/SD/SDIO), which thus keeps these things from sprinkling to
> > > drivers. In some cases, the quirk needs to be applied already during
> > > card initialization, which is earlier than when probing an SDIO func
> > > driver or the MMC block device driver.
> > >
> > > Perhaps it's a good idea to explain a bit about this in the commit 
> > > message.
> > 
> > I would add the whole paragraph to the commit log :)
> 
> Arf, Greg has just pulled this patch into staging-testing. I assume it is
> too late to change the commit message.

I can drop it, but really, it's fine as-is.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: drop fpgaboot driver

2022-02-08 Thread Greg Kroah-Hartman
On Fri, Feb 04, 2022 at 11:08:35AM -0800, Tong Zhang wrote:
> The gs_fpgaboot driver is totally broken since 2014 and no one even
> noticed the driver is not probing. Given the quality of the driver
> and its current state it makes sense to drop it.
> 
> Signed-off-by: Tong Zhang 

Thanks, now dropped!

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: gs_fpgaboot: revert removed board specific code

2022-02-04 Thread Greg Kroah-Hartman
On Thu, Feb 03, 2022 at 09:40:27PM -0800, Tong Zhang wrote:
> gs_fpgaboot is currently useless since the board specific code is
> removed in 06a3fab941da.

Nit, commits should be printed out like this:
06a3fab941da ("staging: gs_fpgaboot: remove checks for CONFIG_B4860G100")

> Loading the driver will always fail since
> xl_init_io() always returns -1. This driver is broken since 2014 and I
> doubt anyone is actually using it, we could either remove it or revert
> to the previous working version.

Let's just remove it obviously no one is using it.

Or do you want to use it for your hardware?  if so, let's fix it for
that platform.

> 
> $ modprobe gs_fpga
> GPIO INIT FAIL!!
> 
> This patch reverts previously removed code and adds a Kconfig to make
> this board selectable for PPC_85xx processors.
> 
> Fixes: 06a3fab941da ("staging: gs_fpgaboot: remove checks for 
> CONFIG_B4860G100")
> Signed-off-by: Tong Zhang 
> ---
>  drivers/staging/gs_fpgaboot/Kconfig |  14 ++-
>  drivers/staging/gs_fpgaboot/io.c| 173 
>  2 files changed, 186 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/gs_fpgaboot/Kconfig 
> b/drivers/staging/gs_fpgaboot/Kconfig
> index 968a153c4ab6..0b4144450123 100644
> --- a/drivers/staging/gs_fpgaboot/Kconfig
> +++ b/drivers/staging/gs_fpgaboot/Kconfig
> @@ -5,4 +5,16 @@
>  config GS_FPGABOOT
>   tristate "Xilinx FPGA firmware download module"
>   help
> -   Xilinx FPGA firmware download module
> +   Xilinx FPGA firmware download module.
> +
> +choice
> + prompt "Support Board"
> + depends on GS_FPGABOOT

That's an odd config option, what will that show?  Shouldn't the prompt
have something to do with the board name?

Anyway, no new config options please, either lets remove it or fix it
for your hardware.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: android: ashmem: Declared file operation with const keyword

2022-01-23 Thread Greg Kroah-Hartman
On Sun, Jan 23, 2022 at 11:09:47PM -0800, ratnesh-r1 wrote:
> warning found by checkpatch.pl script.
> 
> Signed-off-by: ratnesh-r1 
> ---
>  drivers/staging/android/ashmem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/android/ashmem.c 
> b/drivers/staging/android/ashmem.c
> index c05a214..f9cfa15 100644
> --- a/drivers/staging/android/ashmem.c
> +++ b/drivers/staging/android/ashmem.c
> @@ -367,7 +367,7 @@ ashmem_vmfile_get_unmapped_area(struct file *file, 
> unsigned long addr,
>  
>  static int ashmem_mmap(struct file *file, struct vm_area_struct *vma)
>  {
> - static struct file_operations vmfile_fops;
> + static const struct file_operations vmfile_fops;
>   struct ashmem_area *asma = file->private_data;
>   int ret = 0;
>  
> -- 
> 2.7.4
> 
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- Your patch breaks the build.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v9 08/24] wfx: add bus_sdio.c

2022-01-12 Thread Greg Kroah-Hartman
On Wed, Jan 12, 2022 at 12:43:32PM +0100, Pali Rohár wrote:
> Btw, is there any project which maintains SDIO ids, like there is
> pci-ids.ucw.cz for PCI or www.linux-usb.org/usb-ids.html for USB?

Both of those projects have nothing to do with the kernel drivers or
values at all, they are only for userspace tools to use.

So even if there was such a thing for SDIO ids, I doubt it would help
here.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [driver-core:debugfs_cleanup 4/5] fs/d_path.c:59 prepend() warn: unsigned 'p->len' is never less than zero.

2022-01-01 Thread Greg Kroah-Hartman
On Fri, Dec 31, 2021 at 07:35:07PM +, Al Viro wrote:
> On Sat, Jan 01, 2022 at 01:08:41AM +0800, kernel test robot wrote:
> > tree:   
> > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git 
> > debugfs_cleanup
> > head:   a04bbe0a2c7e98669e11a47f94e53dd8228bbeba
> > commit: e95d5bed5d58c2f5352969369827e7135fa2261e [4/5] fs: make d_path-like 
> > functions all have unsigned size
> > config: i386-randconfig-m031-20211228 
> > (https://download.01.org/0day-ci/archive/20220101/202201010156.bjvo7gaw-...@intel.com/config)
> > compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
> > 
> > If you fix the issue, kindly add following tag as appropriate
> > Reported-by: kernel test robot 
> > 
> > smatch warnings:
> > fs/d_path.c:59 prepend() warn: unsigned 'p->len' is never less than zero.
> 
> What do you mean, "unsigned p->len"?
> 
> ->len really *can* be negative - that's how running out of buffer is 
> indicated.
> 
> Greg, I stand by the comment I made back in July - this kind of "hardening" is
> useless; there's no legitimate reason to pass a huge buffer length, especially
> since there's a limit on the length of pathname any syscall would accept.
> See https://www.spinics.net/lists/linux-fsdevel/msg200370.html for the
> variant I would prefer.

Sorry, yes, I agree with you, but never deleted this commit from this
"scratch" branch of mine.  I'll go rebase the branch and purge it from
the system so that 0-day doesn't hit it anymore, sorry for the noise.

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 4.9 01/62] staging: ion: Prevent incorrect reference counting behavour

2021-12-06 Thread Greg Kroah-Hartman
From: Lee Jones 

Supply additional checks in order to prevent unexpected results.

Fixes: b892bf75b2034 ("ion: Switch ion to use dma-buf")
Suggested-by: Dan Carpenter 
Signed-off-by: Lee Jones 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/staging/android/ion/ion.c |6 ++
 1 file changed, 6 insertions(+)

--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -489,6 +489,9 @@ static void *ion_buffer_kmap_get(struct
void *vaddr;
 
if (buffer->kmap_cnt) {
+   if (buffer->kmap_cnt == INT_MAX)
+   return ERR_PTR(-EOVERFLOW);
+
buffer->kmap_cnt++;
return buffer->vaddr;
}
@@ -509,6 +512,9 @@ static void *ion_handle_kmap_get(struct
void *vaddr;
 
if (handle->kmap_cnt) {
+   if (handle->kmap_cnt == INT_MAX)
+   return ERR_PTR(-EOVERFLOW);
+
handle->kmap_cnt++;
return buffer->vaddr;
}


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 4.4 01/52] staging: ion: Prevent incorrect reference counting behavour

2021-12-06 Thread Greg Kroah-Hartman
From: Lee Jones 

Supply additional checks in order to prevent unexpected results.

Fixes: b892bf75b2034 ("ion: Switch ion to use dma-buf")
Suggested-by: Dan Carpenter 
Signed-off-by: Lee Jones 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/staging/android/ion/ion.c |6 ++
 1 file changed, 6 insertions(+)

--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -606,6 +606,9 @@ static void *ion_buffer_kmap_get(struct
void *vaddr;
 
if (buffer->kmap_cnt) {
+   if (buffer->kmap_cnt == INT_MAX)
+   return ERR_PTR(-EOVERFLOW);
+
buffer->kmap_cnt++;
return buffer->vaddr;
}
@@ -626,6 +629,9 @@ static void *ion_handle_kmap_get(struct
void *vaddr;
 
if (handle->kmap_cnt) {
+   if (handle->kmap_cnt == INT_MAX)
+   return ERR_PTR(-EOVERFLOW);
+
handle->kmap_cnt++;
return buffer->vaddr;
}


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [driver-core:hid_is_usb 4/4] nios2-linux-ld: hid-prodikeys.c:undefined reference to `usb_hid_driver'

2021-12-03 Thread Greg Kroah-Hartman
On Fri, Dec 03, 2021 at 05:07:11AM +0800, kernel test robot wrote:
> tree:   
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git 
> hid_is_usb
> head:   be29771805ee7d748ac02a0df3e1e10f5ead521f
> commit: be29771805ee7d748ac02a0df3e1e10f5ead521f [4/4] HID: add USB_HID 
> dependancy on some USB HID drivers
> config: nios2-randconfig-r015-20211202 
> (https://download.01.org/0day-ci/archive/20211203/202112030506.anzw7upl-...@intel.com/config)
> compiler: nios2-linux-gcc (GCC) 11.2.0
> reproduce (this is a W=1 build):
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/commit/?id=be29771805ee7d748ac02a0df3e1e10f5ead521f
> git remote add driver-core 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
> git fetch --no-tags driver-core hid_is_usb
> git checkout be29771805ee7d748ac02a0df3e1e10f5ead521f
> # save the config file to linux build tree
> mkdir build_dir
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross 
> O=build_dir ARCH=nios2 SHELL=/bin/bash
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 
> 
> All errors (new ones prefixed by >>):
> 
>nios2-linux-ld: drivers/hid/hid-chicony.o: in function `ch_probe':
>hid-chicony.c:(.text+0x4): undefined reference to `usb_hid_driver'
>nios2-linux-ld: hid-chicony.c:(.text+0x8): undefined reference to 
> `usb_hid_driver'
>nios2-linux-ld: drivers/hid/hid-prodikeys.o: in function `pk_probe':
>hid-prodikeys.c:(.text+0x1150): undefined reference to `usb_hid_driver'
> >> nios2-linux-ld: hid-prodikeys.c:(.text+0x1154): undefined reference to 
> >> `usb_hid_driver'

Thanks, patch posted for this:

https://lore.kernel.org/r/20211203081231.2856936-1-gre...@linuxfoundation.org
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [driver-core:driver-core-testing 5/7] drivers/base/firmware_loader/test-builtin/test-builtin-firmware.bin.gen.S:5: Error: file not found: drivers/base/firmware_loader/test-builtin/test-builtin-fir

2021-11-27 Thread Greg Kroah-Hartman
On Sat, Nov 27, 2021 at 11:24:12AM +0800, kernel test robot wrote:
> tree:   
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git 
> driver-core-testing
> head:   7f67ea9c19735222f7999754f3fee922cd8f4781
> commit: 6a4e0b75cfa09e70c0aa39a03b478641cf2a7974 [5/7] test_firmware: add 
> support for testing built-in firmware
> config: powerpc-allyesconfig 
> (https://download.01.org/0day-ci/archive/20211127/202111271140.xmh9icbt-...@intel.com/config)
> compiler: powerpc-linux-gcc (GCC) 11.2.0
> reproduce (this is a W=1 build):
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/commit/?id=6a4e0b75cfa09e70c0aa39a03b478641cf2a7974
> git remote add driver-core 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
> git fetch --no-tags driver-core driver-core-testing
> git checkout 6a4e0b75cfa09e70c0aa39a03b478641cf2a7974
> # save the config file to linux build tree
> mkdir build_dir
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross 
> O=build_dir ARCH=powerpc SHELL=/bin/bash
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 
> 
> All errors (new ones prefixed by >>):
> 
>drivers/base/firmware_loader/test-builtin/test-builtin-firmware.bin.gen.S: 
> Assembler messages:
> >> drivers/base/firmware_loader/test-builtin/test-builtin-firmware.bin.gen.S:5:
> >>  Error: file not found: 
> >> drivers/base/firmware_loader/test-builtin/test-builtin-firmware.bin

Thanks for the report.  Luis, I'm dropping this series from my tree.

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v7 13/24] wfx: add hif_tx*.c/hif_tx*.h

2021-10-05 Thread Greg Kroah-Hartman
On Tue, Oct 05, 2021 at 10:17:32AM +0200, Jérôme Pouiller wrote:
> On Tuesday 5 October 2021 08:12:27 CEST Kalle Valo wrote:
> > Pali Rohár  writes:
> > > On Friday 01 October 2021 17:17:52 Jérôme Pouiller wrote:
> > >> On Friday 1 October 2021 11:55:33 CEST Kalle Valo wrote:
> > >> > Jerome Pouiller  writes:
> > >> >
> > >> > > From: Jérôme Pouiller 
> > >> > >
> > >> > > Signed-off-by: Jérôme Pouiller 
> > >> >
> > >> > [...]
> > >> >
> > >> > > --- /dev/null
> > >> > > +++ b/drivers/net/wireless/silabs/wfx/hif_tx_mib.h
> > >> > > @@ -0,0 +1,49 @@
> > >> > > +/* SPDX-License-Identifier: GPL-2.0-only */
> > >> > > +/*
> > >> > > + * Implementation of the host-to-chip MIBs of the hardware API.
> > >> > > + *
> > >> > > + * Copyright (c) 2017-2020, Silicon Laboratories, Inc.
> > >> > > + * Copyright (c) 2010, ST-Ericsson
> > >> > > + * Copyright (C) 2010, ST-Ericsson SA
> > >> > > + */
> > >> > > +#ifndef WFX_HIF_TX_MIB_H
> > >> > > +#define WFX_HIF_TX_MIB_H
> > >> > > +
> > >> > > +struct wfx_vif;
> > >> > > +struct sk_buff;
> > >> > > +
> > >> > > +int hif_set_output_power(struct wfx_vif *wvif, int val);
> > >> > > +int hif_set_beacon_wakeup_period(struct wfx_vif *wvif,
> > >> > > +  unsigned int dtim_interval,
> > >> > > +  unsigned int listen_interval);
> > >> > > +int hif_set_rcpi_rssi_threshold(struct wfx_vif *wvif,
> > >> > > + int rssi_thold, int rssi_hyst);
> > >> > > +int hif_get_counters_table(struct wfx_dev *wdev, int vif_id,
> > >> > > +struct hif_mib_extended_count_table *arg);
> > >> > > +int hif_set_macaddr(struct wfx_vif *wvif, u8 *mac);
> > >> > > +int hif_set_rx_filter(struct wfx_vif *wvif,
> > >> > > +   bool filter_bssid, bool fwd_probe_req);
> > >> > > +int hif_set_beacon_filter_table(struct wfx_vif *wvif, int tbl_len,
> > >> > > + const struct hif_ie_table_entry *tbl);
> > >> > > +int hif_beacon_filter_control(struct wfx_vif *wvif,
> > >> > > +   int enable, int beacon_count);
> > >> > > +int hif_set_operational_mode(struct wfx_dev *wdev, enum
> > >> > > hif_op_power_mode mode);
> > >> > > +int hif_set_template_frame(struct wfx_vif *wvif, struct sk_buff 
> > >> > > *skb,
> > >> > > +u8 frame_type, int init_rate);
> > >> > > +int hif_set_mfp(struct wfx_vif *wvif, bool capable, bool required);
> > >> > > +int hif_set_block_ack_policy(struct wfx_vif *wvif,
> > >> > > +  u8 tx_tid_policy, u8 rx_tid_policy);
> > >> > > +int hif_set_association_mode(struct wfx_vif *wvif, int 
> > >> > > ampdu_density,
> > >> > > +  bool greenfield, bool short_preamble);
> > >> > > +int hif_set_tx_rate_retry_policy(struct wfx_vif *wvif,
> > >> > > +  int policy_index, u8 *rates);
> > >> > > +int hif_keep_alive_period(struct wfx_vif *wvif, int period);
> > >> > > +int hif_set_arp_ipv4_filter(struct wfx_vif *wvif, int idx, __be32 
> > >> > > *addr);
> > >> > > +int hif_use_multi_tx_conf(struct wfx_dev *wdev, bool enable);
> > >> > > +int hif_set_uapsd_info(struct wfx_vif *wvif, unsigned long val);
> > >> > > +int hif_erp_use_protection(struct wfx_vif *wvif, bool enable);
> > >> > > +int hif_slot_time(struct wfx_vif *wvif, int val);
> > >> > > +int hif_wep_default_key_id(struct wfx_vif *wvif, int val);
> > >> > > +int hif_rts_threshold(struct wfx_vif *wvif, int val);
> > >> >
> > >> > "wfx_" prefix missing from quite a few functions.
> > >>
> > >> I didn't know it was mandatory to prefix all the functions with the
> > >> same prefix.
> > 
> > I don't know either if this is mandatory or not, for example I do not
> > have any recollection what Linus and other maintainers think of this. I
> > just personally think it's good practise to use driver prefix ("wfx_")
> > in all non-static functions.
> 
> What about structs (especially all the structs from hif_api.*.h)? Do you
> think I should also prefix them with wfx_? 

Why would they _not_ have wfx_ as a prefix if they only pertain to this
driver?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v7 13/24] wfx: add hif_tx*.c/hif_tx*.h

2021-10-05 Thread Greg Kroah-Hartman
On Tue, Oct 05, 2021 at 09:12:27AM +0300, Kalle Valo wrote:
> Pali Rohár  writes:
> 
> > On Friday 01 October 2021 17:17:52 Jérôme Pouiller wrote:
> >> On Friday 1 October 2021 11:55:33 CEST Kalle Valo wrote:
> >> > CAUTION: This email originated from outside of the organization.
> >> > Do not click links or open attachments unless you recognize the
> >> > sender and know the content is safe.
> >> > 
> >> > 
> >> > Jerome Pouiller  writes:
> >> > 
> >> > > From: Jérôme Pouiller 
> >> > >
> >> > > Signed-off-by: Jérôme Pouiller 
> >> > 
> >> > [...]
> >> > 
> >> > > --- /dev/null
> >> > > +++ b/drivers/net/wireless/silabs/wfx/hif_tx_mib.h
> >> > > @@ -0,0 +1,49 @@
> >> > > +/* SPDX-License-Identifier: GPL-2.0-only */
> >> > > +/*
> >> > > + * Implementation of the host-to-chip MIBs of the hardware API.
> >> > > + *
> >> > > + * Copyright (c) 2017-2020, Silicon Laboratories, Inc.
> >> > > + * Copyright (c) 2010, ST-Ericsson
> >> > > + * Copyright (C) 2010, ST-Ericsson SA
> >> > > + */
> >> > > +#ifndef WFX_HIF_TX_MIB_H
> >> > > +#define WFX_HIF_TX_MIB_H
> >> > > +
> >> > > +struct wfx_vif;
> >> > > +struct sk_buff;
> >> > > +
> >> > > +int hif_set_output_power(struct wfx_vif *wvif, int val);
> >> > > +int hif_set_beacon_wakeup_period(struct wfx_vif *wvif,
> >> > > +  unsigned int dtim_interval,
> >> > > +  unsigned int listen_interval);
> >> > > +int hif_set_rcpi_rssi_threshold(struct wfx_vif *wvif,
> >> > > + int rssi_thold, int rssi_hyst);
> >> > > +int hif_get_counters_table(struct wfx_dev *wdev, int vif_id,
> >> > > +struct hif_mib_extended_count_table *arg);
> >> > > +int hif_set_macaddr(struct wfx_vif *wvif, u8 *mac);
> >> > > +int hif_set_rx_filter(struct wfx_vif *wvif,
> >> > > +   bool filter_bssid, bool fwd_probe_req);
> >> > > +int hif_set_beacon_filter_table(struct wfx_vif *wvif, int tbl_len,
> >> > > + const struct hif_ie_table_entry *tbl);
> >> > > +int hif_beacon_filter_control(struct wfx_vif *wvif,
> >> > > +   int enable, int beacon_count);
> >> > > +int hif_set_operational_mode(struct wfx_dev *wdev, enum
> >> > > hif_op_power_mode mode);
> >> > > +int hif_set_template_frame(struct wfx_vif *wvif, struct sk_buff *skb,
> >> > > +u8 frame_type, int init_rate);
> >> > > +int hif_set_mfp(struct wfx_vif *wvif, bool capable, bool required);
> >> > > +int hif_set_block_ack_policy(struct wfx_vif *wvif,
> >> > > +  u8 tx_tid_policy, u8 rx_tid_policy);
> >> > > +int hif_set_association_mode(struct wfx_vif *wvif, int ampdu_density,
> >> > > +  bool greenfield, bool short_preamble);
> >> > > +int hif_set_tx_rate_retry_policy(struct wfx_vif *wvif,
> >> > > +  int policy_index, u8 *rates);
> >> > > +int hif_keep_alive_period(struct wfx_vif *wvif, int period);
> >> > > +int hif_set_arp_ipv4_filter(struct wfx_vif *wvif, int idx, __be32 
> >> > > *addr);
> >> > > +int hif_use_multi_tx_conf(struct wfx_dev *wdev, bool enable);
> >> > > +int hif_set_uapsd_info(struct wfx_vif *wvif, unsigned long val);
> >> > > +int hif_erp_use_protection(struct wfx_vif *wvif, bool enable);
> >> > > +int hif_slot_time(struct wfx_vif *wvif, int val);
> >> > > +int hif_wep_default_key_id(struct wfx_vif *wvif, int val);
> >> > > +int hif_rts_threshold(struct wfx_vif *wvif, int val);
> >> > 
> >> > "wfx_" prefix missing from quite a few functions.
> >> 
> >> I didn't know it was mandatory to prefix all the functions with the
> >> same prefix.
> 
> I don't know either if this is mandatory or not, for example I do not
> have any recollection what Linus and other maintainers think of this. I
> just personally think it's good practise to use driver prefix ("wfx_")
> in all non-static functions.
> 
> Any opinions from others? Greg?

For static functions, pick what you want.

For global functions, like this, use a common prefix that indicates the
driver as you are now playing in the global namespace of a 30 million
line project.

> >> With the rule of 80-columns, I think I will have to change a bunch of
> >> code :( .
> >
> > I think that new drivers can use 100 characters per line.
> 
> That's my understanding as well.

Yes, that's fine.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: rtl8723bs: put '{' on struct's first line

2021-08-18 Thread Greg Kroah-Hartman
On Tue, Aug 17, 2021 at 09:41:05PM -0700, daniel watson wrote:
> From: Daniel Watson 
> 
> Moved the opening curly brace to the end of the opening
> line of the phy_stat struct for style consistency.
> 
> Signed-off-by: Daniel Watson 
> ---
>  drivers/staging/rtl8723bs/include/rtl8192c_recv.h | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

This change does not apply to my tree at all.  Make sure that you are
working off of the latest development tree, and not older kernel trees
(like Linus's), otherwise you will end up duplicating work that others
have already done.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [driver-core:driver-core-testing 28/31] WARNING: modpost: vmlinux.o(.text.unlikely+0x156c): Section mismatch in reference from the function bitmap_equal() to the variable .init.data:initcall_level

2021-08-15 Thread Greg Kroah-Hartman
On Sun, Aug 15, 2021 at 03:27:04PM +1200, Barry Song wrote:
> On Sun, Aug 15, 2021 at 1:36 AM Greg Kroah-Hartman
>  wrote:
> >
> > On Sat, Aug 14, 2021 at 07:03:00PM +0800, kernel test robot wrote:
> > > tree:   
> > > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git 
> > > driver-core-testing
> > > head:   3b35f2a6a625126c57475aa56b5357d8e80b404c
> > > commit: 291f93ca339f5b5e6e90ad037bb8271f0f618165 [28/31] lib: 
> > > test_bitmap: add bitmap_print_bitmask/list_to_buf test cases
> > > config: xtensa-randconfig-r004-20210814 (attached as .config)
> > > compiler: xtensa-linux-gcc (GCC) 11.2.0
> > > reproduce (this is a W=1 build):
> > > wget 
> > > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross 
> > > -O ~/bin/make.cross
> > > chmod +x ~/bin/make.cross
> > > # 
> > > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/commit/?id=291f93ca339f5b5e6e90ad037bb8271f0f618165
> > > git remote add driver-core 
> > > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
> > > git fetch --no-tags driver-core driver-core-testing
> > > git checkout 291f93ca339f5b5e6e90ad037bb8271f0f618165
> > > # save the attached .config to linux build tree
> > > mkdir build_dir
> > > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross 
> > > O=build_dir ARCH=xtensa SHELL=/bin/bash
> > >
> > > If you fix the issue, kindly add following tag as appropriate
> > > Reported-by: kernel test robot 
> > >
> > > All warnings (new ones prefixed by >>, old ones prefixed by <<):
> > >
> > > >> WARNING: modpost: vmlinux.o(.text.unlikely+0x156c): Section mismatch 
> > > >> in reference from the function bitmap_equal() to the variable 
> > > >> .init.data:initcall_level_names
> > > The function bitmap_equal() references
> > > the variable __initdata initcall_level_names.
> > > This is often because bitmap_equal lacks a __initdata
> > > annotation or the annotation of initcall_level_names is wrong.
> > >
> > > The below error/warnings are from parent commit:
> > > << WARNING: modpost: vmlinux.o(.data+0x1a86d8): Section mismatch in 
> > > reference from the variable qed_mfw_legacy_maps to the variable 
> > > .init.rodata:__setup_str_initcall_blacklist
> > > << WARNING: modpost: vmlinux.o(.data+0x1a87c8): Section mismatch in 
> > > reference from the variable qed_mfw_ext_maps to the variable 
> > > .init.rodata:__setup_str_initcall_blacklist
> > > << WARNING: modpost: vmlinux.o(.data+0x1a8948): Section mismatch in 
> > > reference from the variable qede_forced_speed_maps to the variable 
> > > .init.rodata:__setup_str_initcall_blacklist
> > >
> > > ---
> > > 0-DAY CI Kernel Test Service, Intel Corporation
> > > https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
> >
> > Barry, can I get a fix for this?
> 
> Hi Greg,
> As I replied to Andy, this warning has nothing to do with my commit as my
> commit doesn't call the involved functions at all.
> 
> It has been there for more than one year. but i still send a patch for
> this issue
> over here:
> https://lore.kernel.org/lkml/20210815032132.14530-1-21cn...@gmail.com/T/#u
> 
> Note this patch is not fixing the latest commits. It is a general
> patch for bitmap.

Ah, ok, nevermind, I missed that.

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [driver-core:driver-core-testing 28/31] WARNING: modpost: vmlinux.o(.text.unlikely+0x156c): Section mismatch in reference from the function bitmap_equal() to the variable .init.data:initcall_level

2021-08-14 Thread Greg Kroah-Hartman
On Sat, Aug 14, 2021 at 07:03:00PM +0800, kernel test robot wrote:
> tree:   
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git 
> driver-core-testing
> head:   3b35f2a6a625126c57475aa56b5357d8e80b404c
> commit: 291f93ca339f5b5e6e90ad037bb8271f0f618165 [28/31] lib: test_bitmap: 
> add bitmap_print_bitmask/list_to_buf test cases
> config: xtensa-randconfig-r004-20210814 (attached as .config)
> compiler: xtensa-linux-gcc (GCC) 11.2.0
> reproduce (this is a W=1 build):
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/commit/?id=291f93ca339f5b5e6e90ad037bb8271f0f618165
> git remote add driver-core 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
> git fetch --no-tags driver-core driver-core-testing
> git checkout 291f93ca339f5b5e6e90ad037bb8271f0f618165
> # save the attached .config to linux build tree
> mkdir build_dir
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross 
> O=build_dir ARCH=xtensa SHELL=/bin/bash
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 
> 
> All warnings (new ones prefixed by >>, old ones prefixed by <<):
> 
> >> WARNING: modpost: vmlinux.o(.text.unlikely+0x156c): Section mismatch in 
> >> reference from the function bitmap_equal() to the variable 
> >> .init.data:initcall_level_names
> The function bitmap_equal() references
> the variable __initdata initcall_level_names.
> This is often because bitmap_equal lacks a __initdata
> annotation or the annotation of initcall_level_names is wrong.
> 
> The below error/warnings are from parent commit:
> << WARNING: modpost: vmlinux.o(.data+0x1a86d8): Section mismatch in reference 
> from the variable qed_mfw_legacy_maps to the variable 
> .init.rodata:__setup_str_initcall_blacklist
> << WARNING: modpost: vmlinux.o(.data+0x1a87c8): Section mismatch in reference 
> from the variable qed_mfw_ext_maps to the variable 
> .init.rodata:__setup_str_initcall_blacklist
> << WARNING: modpost: vmlinux.o(.data+0x1a8948): Section mismatch in reference 
> from the variable qede_forced_speed_maps to the variable 
> .init.rodata:__setup_str_initcall_blacklist
> 
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

Barry, can I get a fix for this?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v2 0/3] Remove blank lines at drivers/rtl8188eu/core/rtw_ap.c

2021-07-27 Thread Greg Kroah-Hartman
On Fri, Jul 23, 2021 at 04:27:50PM +0530, Benjamin Philip wrote:
> The following few patches remove some blank lines that before or after a 
> brace.
> 
> To test my changes, I have checked if it compiles (which it does). I also have
> checked the patch with checkpatch.pl, which does not pass any warnings of any 
> sort.
> 
> Changes in v2:
> * Tested by building (no changes code)
> 
> This is my first patch to the linux kernel. I apologize for all the 
> inconveniences caused
> by my unfamiliarity with the kernel workflow.
> 
> I also have split each line I removed into a patch so that it is convenient 
> for the
> maintainer. I hope it is so.
> 
> Thanks,
> Benjamin Philip
> 
> Benjamin Philip (3):
>   staging: rtl8188eu: Remove blank line at core/rtw_ap.c:385
>   staging: rtl8188eu: Remove blank line at core/rtw_ap.c:457
>   staging: rtl8188eu: Remove blank line at core/rtw_ap.c:1143

That's just too many patches, your first one was just fine :)

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: rtl8188eu: remove unnecessary blank lines in core/rtw_ap.c

2021-07-21 Thread Greg Kroah-Hartman
On Wed, Jul 21, 2021 at 04:28:09PM +0530, Benjamin Philip wrote:
> This commit fixes some checkpatch checks for blank lines before
> and after braces in drivers/staging/rtl8188eu/core/rtw_ap.c
> 
> Signed-off-by: Benjamin Philip 
> ---
> 
> This patch fixes some checkpatch.pl CHECKs for blank lines.
> 
> Note: Since all I have done is remove some empty blank lines, I didn't
> compile and test the driver.

Always test-build your changes, do not force me to do that for you.

Please do that and resend.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH] MAINTAINERS: move some real subsystems off of the staging mailing list

2021-03-13 Thread Greg Kroah-Hartman
The VME and Android drivers still have their MAINTAINERS entries
pointing to the "driverdevel" mailing list, due to them having their
codebase move out of the drivers/staging/ directory, but no one
remembered to change the mailing list entries.

Move them both to linux-kernel for lack of a more specific place at the
moment.  These are both low-volume areas of the kernel, so this
shouldn't be an issue.

Cc: Martyn Welch 
Cc: Manohar Vanga 
Cc: Arve Hjønnevåg 
Cc: Todd Kjos 
Cc: Martijn Coenen 
Cc: Joel Fernandes 
Cc: Christian Brauner 
Cc: Hridya Valsaraju 
Cc: Suren Baghdasaryan 
Reported-by: Konstantin Ryabitsev 
Signed-off-by: Greg Kroah-Hartman 

diff --git a/MAINTAINERS b/MAINTAINERS
index 72e5b9db5050..b02eec28ae2c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1181,7 +1181,7 @@ M:Joel Fernandes 
 M: Christian Brauner 
 M: Hridya Valsaraju 
 M: Suren Baghdasaryan 
-L: de...@driverdev.osuosl.org
+L: linux-ker...@vger.kernel.org
 S: Supported
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
 F: drivers/android/
@@ -19135,7 +19135,7 @@ VME SUBSYSTEM
 M: Martyn Welch 
 M: Manohar Vanga 
 M: Greg Kroah-Hartman 
-L: de...@driverdev.osuosl.org
+L: linux-ker...@vger.kernel.org
 S: Maintained
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
 F: Documentation/driver-api/vme.rst
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCHSET] remove 153 useless typedefs in staging/rtl8723bs

2021-03-12 Thread Greg Kroah-Hartman
On Fri, Mar 12, 2021 at 09:26:05AM +0100, Marco Cesati wrote:
> This set of patches remove 153 useless typedef instructions in the
> staging/rtl8723bs source code, as identified by the checkpatch.pl
> script. Every patch is purely syntactical: it does not change the
> generated machine code. Furthermore, every single patch leaves the
> source code fully compilable, so that 'git bisect' will not be affected.

I'll take these, but can you now clean up the ALL_CAPS structure names
that this patch series creates?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: gasket: Fix sizeof() in gasket_handle_ioctl()

2021-03-09 Thread Greg Kroah-Hartman
On Tue, Mar 09, 2021 at 04:57:59PM +, Walter Harms wrote:
> why not mark it as "Deprecated" and remove it with the next version ? Maybe 
> soneone will wakeup ?

We don't really have a "Deprecated" marking, we just delete them :)

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: gasket: Fix sizeof() in gasket_handle_ioctl()

2021-03-09 Thread Greg Kroah-Hartman
On Fri, Jan 22, 2021 at 06:01:13PM +0300, Dan Carpenter wrote:
> The "gasket_dev->num_page_tables" variable is an int but this is copying
> sizeof(u64).  On 32 bit systems this would end up disclosing a kernel
> pointer to user space, but on 64 bit it copies zeroes from a struct
> hole.
> 
> Fixes: 9a69f5087ccc ("drivers/staging: Gasket driver framework + Apex driver")
> Signed-off-by: Dan Carpenter 
> ---
> This is an API change.  Please review this carefully!  Another potential
> fix would be to make ->num_page_tables a long instead of an int.
> 
>  drivers/staging/gasket/gasket_ioctl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Looks like this driver is dead, with no response from anyone from
Google.

Should I just delete it?  The goal of using normal apis and getting this
out of staging seems to have totally died, so it shouldn't even still be
living in the kernel tree.  Even if having it here actually finds
security issues that the authors missed like this :(

So, any objection to me deleting it?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] drivers: staging: comedi: Fixed side effects from macro definition.

2021-02-23 Thread Greg Kroah-Hartman
A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Wed, Feb 24, 2021 at 12:47:26PM +0530, chakravarthi Kulkarni wrote:
> Hi,
> 
> I tested it will unit test cases it looks fine.
> int x = 10;
> NI_USUAL_PFI_SELECT(x++)
> 
> will not have side effects as it is taken care using local variable in
> macro.

You ignored what Ian said about why this change was not ok :(

It's long deleted from my review queue, sorry.

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 1/2] staging: octeon: refactor interface check logic in ethernet.c

2021-02-22 Thread Greg Kroah-Hartman
On Sun, Feb 21, 2021 at 09:35:44PM +0530, Shreesh Adiga wrote:
> The check for interface is duplicated in 3 places and has been refactored
> into a function.
> 
> Signed-off-by: Shreesh Adiga <16567adigashre...@gmail.com>
> ---
>  drivers/staging/octeon/ethernet.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/staging/octeon/ethernet.c 
> b/drivers/staging/octeon/ethernet.c
> index 5dea6e96ec90..af546ef41843 100644
> --- a/drivers/staging/octeon/ethernet.c
> +++ b/drivers/staging/octeon/ethernet.c
> @@ -228,6 +228,12 @@ static struct net_device_stats 
> *cvm_oct_common_get_stats(struct net_device *dev)
>   return >stats;
>  }
>  
> +static int cvm_oct_validate_interface(int interface)

Shouldn't this return a bool?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: octeon: refactor interface check logic in ethernet.c

2021-02-21 Thread Greg Kroah-Hartman
On Sun, Feb 21, 2021 at 08:25:05PM +0530, Shreesh Adiga wrote:
> The check for interface is duplicated in 3 places and has been refactored
> into a function. Also the if condition was wrapping the whole body in all
> three places, so it has been changed to return if the condition is false
> to reduce the indentation levels.

When you have an "also" in a changelog text, that's a huge hint this
needs to be broken up into multiple patches.

Please do that here and send a patch series.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 3/3] staging: media/atomisp: don't compile unused code

2021-02-21 Thread Greg Kroah-Hartman
On Sun, Feb 21, 2021 at 07:34:57PM +0530, karthik alapati wrote:
> currently the functions defined in ibuf_ctrl_rmgr.c file are only
> used by isys_init.c when CONFIG_VIDEO_ATOMISP_ISP2401 is selected
> so dont't compile it when not needed, also fixes some sparse warnings
> 
> Signed-off-by: karthik alapati 
> ---
>  drivers/staging/media/atomisp/Makefile | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

This has nothing to do with the previous 2 patches, why did you add it
to this series?

And note, you missed the correct people to send this patch to, so it's
not going to ever get applied :(

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: wimax/i2400m: fix byte-order type issue

2021-02-21 Thread Greg Kroah-Hartman
On Sat, Feb 20, 2021 at 06:22:31PM +0530, karthik alapati wrote:
> fix sparse type warning by converting le32 types to
> host byte-order types before comparison
> 
> Signed-off-by: karthik alapati 
> ---
>  drivers/staging/wimax/i2400m/fw.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/wimax/i2400m/fw.c 
> b/drivers/staging/wimax/i2400m/fw.c
> index 92ea5c101..f09de1810 100644
> --- a/drivers/staging/wimax/i2400m/fw.c
> +++ b/drivers/staging/wimax/i2400m/fw.c
> @@ -511,7 +511,7 @@ ssize_t __i2400m_bm_ack_verify(struct i2400m *i2400m, int 
> opcode,
>   opcode, i2400m_brh_get_response(ack));
>   goto error_ack_failed;
>   }
> - if (ack_size < ack->data_size + sizeof(*ack)) {
> + if (ack_size < le32_to_cpu(ack->data_size) + sizeof(*ack)) {
>   dev_err(dev, "boot-mode cmd %d: SW BUG "
>   "driver provided only %zu bytes for %zu bytes "
>   "of data\n", opcode, ack_size,

You sent 3 patches that seem to do the same thing, yet are a bit
different?

Please make your patches a patch series and provide proper subject lines
to make them unique.  I have now dropped all of your submitted patches
from my review queue.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 2/2] staging: media: ipu3: code style fix - missing a blank line after declarations

2021-02-21 Thread Greg Kroah-Hartman
On Sun, Feb 21, 2021 at 11:12:36AM +0300, Nikolay Kyx wrote:
> This patch fixes the following checkpatch.pl warning:
> 
> WARNING: Missing a blank line after declarations
> 
> in file ipu3-css-fw.h
> 
> Signed-off-by: Nikolay Kyx 
> ---
> 
> Additionally some style warnings remain valid here and could be fixed by
> another patch.
> 
>  drivers/staging/media/ipu3/ipu3-css-fw.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/staging/media/ipu3/ipu3-css-fw.h 
> b/drivers/staging/media/ipu3/ipu3-css-fw.h
> index 79ffa7045139..3c078f15a295 100644
> --- a/drivers/staging/media/ipu3/ipu3-css-fw.h
> +++ b/drivers/staging/media/ipu3/ipu3-css-fw.h
> @@ -148,6 +148,7 @@ union imgu_fw_union {
>  struct imgu_fw_info {
>   size_t header_size; /* size of fw header */
>   u32 type __aligned(8);  /* enum imgu_fw_type */
> +
>   union imgu_fw_union info;   /* Binary info */
>   struct imgu_abi_blob_info blob; /* Blob info */
>   /* Dynamic part */

With your knowledge of C, does this change look correct?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v3 2/3] staging: rtl8192u: fixed coding style of r8190_rtl8256.c

2021-02-19 Thread Greg Kroah-Hartman
On Fri, Feb 19, 2021 at 07:07:54PM +0800, Du Cheng wrote:
> use MACRO __func__ instead of "phy_rf8256_config_para_file" for RT_TRACE()
> inside phy_rf8256_config_para_file(), reported by scripts/checkpatch.pl.
> 
> Signed-off-by: Du Cheng 
> ---
>  drivers/staging/rtl8192u/r8190_rtl8256.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Why isn't this part of patch 1/3?  It does the same thing, right?

Please fix up and resend the series.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v2] staging: rtl8192u: fix coding style in r8190_rtl8256.c

2021-02-19 Thread Greg Kroah-Hartman
On Tue, Feb 16, 2021 at 06:28:06PM +0800, Du Cheng wrote:
> use __func__ macro instead of literal function name in RT_TRACE() in
>  * phy_set_rf8256_bandwidth()
>  * phy_rf8256_config_para_file()
> 
> remove unnecessary return at the end of phy_set_rf8256_ofdm_tx_power()
> 
> these coding style issues are flagged as warnings by scripts/checkpatch.pl.
> 
> 
> Signed-off-by: Du Cheng 
> ---
> changes v2:
> * improve description and subject
> 
> changes v1:
> * fix coding style
> 
>  drivers/staging/rtl8192u/r8190_rtl8256.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/rtl8192u/r8190_rtl8256.c 
> b/drivers/staging/rtl8192u/r8190_rtl8256.c
> index fee3bfb99075..54747fda552f 100644
> --- a/drivers/staging/rtl8192u/r8190_rtl8256.c
> +++ b/drivers/staging/rtl8192u/r8190_rtl8256.c
> @@ -73,11 +73,11 @@ void phy_set_rf8256_bandwidth(struct net_device *dev, 
> enum ht_channel_width Band
>   else
>   rtl8192_phy_SetRFReg(dev, (enum 
> rf90_radio_path_e)eRFPath, 0x14, bMask12Bits, 0x5ab);
>   } else {
> - RT_TRACE(COMP_ERR, 
> "phy_set_rf8256_bandwidth(): unknown hardware version\n");
> + RT_TRACE(COMP_ERR, "%s(): unknown 
> hardware version\n", __func__);
>   }
>   break;
>   default:
> - RT_TRACE(COMP_ERR, "phy_set_rf8256_bandwidth(): 
> unknown Bandwidth: %#X\n", Bandwidth);
> + RT_TRACE(COMP_ERR, "%s(): unknown Bandwidth: 
> %#X\n", __func__, Bandwidth);
>   break;
>   }
>   }
> @@ -213,7 +213,7 @@ static void phy_rf8256_config_para_file(struct net_device 
> *dev)
>   }
>  
>   if (ret) {
> - RT_TRACE(COMP_ERR, 
> "phy_rf8256_config_para_file():Radio[%d] Fail!!", eRFPath);
> + RT_TRACE(COMP_ERR, "%s():Radio[%d] Fail!!", __func__, 
> eRFPath);
>   goto phy_RF8256_Config_ParaFile_Fail;
>   }
>   }
> @@ -291,5 +291,4 @@ void phy_set_rf8256_ofdm_tx_power(struct net_device *dev, 
> u8 powerlevel)
>   }
>   rtl8192_setBBreg(dev, RegOffset[index], 0x7f7f7f7f, writeVal);
>   }
> - return;
>  }
> -- 
> 2.27.0

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- Your patch did many different things all at once, making it difficult
  to review.  All Linux kernel patches need to only do one thing at a
  time.  If you need to do multiple things (such as clean up all coding
  style issues in a file/driver), do it in a sequence of patches, each
  one doing only one thing.  This will make it easier to review the
  patches to ensure that they are correct, and to help alleviate any
  merge issues that larger patches can cause.

- You did not write a descriptive Subject: for the patch, allowing Greg,
  and everyone else, to know what this patch is all about.  Please read
  the section entitled "The canonical patch format" in the kernel file,
  Documentation/SubmittingPatches for what a proper Subject: line should
  look like.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: rtl8712: cleanup checkpatch.pl warnings

2021-02-19 Thread Greg Kroah-Hartman
On Sun, Feb 14, 2021 at 03:56:01PM +0530, Shreesh Adiga wrote:
> Cleanup warnings displayed by checkpatch.pl for the
> file rtl8171x_mlme.c for the below warning:
> WARNING: Avoid multiple line dereference
> 
> Signed-off-by: Shreesh Adiga <16567adigashre...@gmail.com>
> ---
>  drivers/staging/rtl8712/rtl871x_mlme.c | 112 +
>  1 file changed, 39 insertions(+), 73 deletions(-)

Always run checkpatch on your patch submission, to ensure that you got
it correct.  If you note, your Subject line is not ok...

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: i2400m: use explicit host byte-order types in comparison

2021-02-18 Thread Greg Kroah-Hartman
On Fri, Feb 19, 2021 at 06:00:47AM +0530, karthik alapati wrote:
> convert le32 types to host byte-order types before
> comparison

That says what you did, but not _why_ you did it.  Please fix up and
resend.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: emxx_udc: remove unused variable driver_desc

2021-02-18 Thread Greg Kroah-Hartman
On Thu, Feb 18, 2021 at 10:41:07PM -0500, Sean Behan wrote:
> Signed-off-by: Sean Behan 
> ---
>  drivers/staging/emxx_udc/emxx_udc.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/staging/emxx_udc/emxx_udc.c 
> b/drivers/staging/emxx_udc/emxx_udc.c
> index 3536c03ff523..741147a4f0fe 100644
> --- a/drivers/staging/emxx_udc/emxx_udc.c
> +++ b/drivers/staging/emxx_udc/emxx_udc.c
> @@ -38,7 +38,6 @@ static struct gpio_desc *vbus_gpio;
>  static int vbus_irq;
>  
>  static const chardriver_name[] = "emxx_udc";
> -static const chardriver_desc[] = DRIVER_DESC;
>  
>  
> /*===*/
>  /* Prototype */
> -- 
> 2.29.2

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- You did not specify a description of why the patch is needed, or
  possibly, any description at all, in the email body.  Please read the
  section entitled "The canonical patch format" in the kernel file,
  Documentation/SubmittingPatches for what is needed in order to
  properly describe the change.

- This looks like a new version of a previously submitted patch, but you
  did not list below the --- line any changes from the previous version.
  Please read the section entitled "The canonical patch format" in the
  kernel file, Documentation/SubmittingPatches for what needs to be done
  here to properly describe this.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [driver-core:debugfs_remove_return_value 2/8] drivers/net/wireless/broadcom/b43/debugfs.c:661:28: error: void value not ignored as it ought to be

2021-02-18 Thread Greg Kroah-Hartman
On Thu, Feb 18, 2021 at 05:58:41AM +0800, kernel test robot wrote:
> tree:   
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git 
> debugfs_remove_return_value
> head:   5187c2360ee1d023078e4302dad32fda1e895772
> commit: 72f2bf74b31aae983fb200aa7e84a05943bf27fc [2/8] debugfs: remove return 
> value of debugfs_create_bool()
> config: x86_64-randconfig-c002-20210216 (attached as .config)
> compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
> reproduce (this is a W=1 build):
> # 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/commit/?id=72f2bf74b31aae983fb200aa7e84a05943bf27fc
> git remote add driver-core 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
> git fetch --no-tags driver-core debugfs_remove_return_value
> git checkout 72f2bf74b31aae983fb200aa7e84a05943bf27fc
> # save the attached .config to linux build tree
> make W=1 ARCH=x86_64 
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 

You are working with an old tree, this was fixed 2 days ago, no need to
keep emailing me about this :(

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: emxx_udc: remove unused variable driver_desc

2021-02-17 Thread Greg Kroah-Hartman
On Wed, Feb 17, 2021 at 09:24:17AM -0500, Sean Behan wrote:
> When building with W=1, there is a warning that this variable is unused.
> 
> It is not used so remove it to fix the warning.
> 
> Thanks to nat...@kernel.org for helping me submit my first patch.

This is nice, but is it needed in the changelog text?  Please put it
below the --- line when you resend.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] remove unused variable driver_desc

2021-02-16 Thread Greg Kroah-Hartman
On Tue, Feb 16, 2021 at 10:59:51PM -0500, Sean Behan wrote:
> ---
>  drivers/staging/emxx_udc/emxx_udc.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/staging/emxx_udc/emxx_udc.c 
> b/drivers/staging/emxx_udc/emxx_udc.c
> index 3536c03ff523..741147a4f0fe 100644
> --- a/drivers/staging/emxx_udc/emxx_udc.c
> +++ b/drivers/staging/emxx_udc/emxx_udc.c
> @@ -38,7 +38,6 @@ static struct gpio_desc *vbus_gpio;
>  static int vbus_irq;
>  
>  static const chardriver_name[] = "emxx_udc";
> -static const chardriver_desc[] = DRIVER_DESC;
>  
>  
> /*===*/
>  /* Prototype */
> -- 
> 2.29.2


Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- Your patch does not have a Signed-off-by: line.  Please read the
  kernel file, Documentation/SubmittingPatches and resend it after
  adding that line.  Note, the line needs to be in the body of the
  email, before the patch, not at the bottom of the patch or in the
  email signature.

- You did not specify a description of why the patch is needed, or
  possibly, any description at all, in the email body.  Please read the
  section entitled "The canonical patch format" in the kernel file,
  Documentation/SubmittingPatches for what is needed in order to
  properly describe the change.

- You did not write a descriptive Subject: for the patch, allowing Greg,
  and everyone else, to know what this patch is all about.  Please read
  the section entitled "The canonical patch format" in the kernel file,
  Documentation/SubmittingPatches for what a proper Subject: line should
  look like.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v2] staging: greybus: fix coding style of greybus/loopback.c

2021-02-16 Thread Greg Kroah-Hartman
On Tue, Feb 16, 2021 at 07:13:53PM +0800, Du Cheng wrote:
> fix macro gb_loopback_stats_attrs by wrapping its multi-line definition
> inside a do {} while(0) block, in compliance to scripts/checkpatch.pl.
> 
> Signed-off-by: Du Cheng 
> ---
> changes v2:
> * relign backslashes with tabstop=8
> * improve description and subject
> 
> changes v1:
> * fix coding style of the macro
> 
>  drivers/staging/greybus/loopback.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/greybus/loopback.c 
> b/drivers/staging/greybus/loopback.c
> index 2471448ba42a..24b769688817 100644
> --- a/drivers/staging/greybus/loopback.c
> +++ b/drivers/staging/greybus/loopback.c
> @@ -163,9 +163,11 @@ static ssize_t name##_avg_show(struct device *dev,   
> \
>  static DEVICE_ATTR_RO(name##_avg)
>  
>  #define gb_loopback_stats_attrs(field)   \
> +do { \
>   gb_loopback_ro_stats_attr(field, min, u);   \
>   gb_loopback_ro_stats_attr(field, max, u);   \
> - gb_loopback_ro_avg_attr(field)
> + gb_loopback_ro_avg_attr(field); \
> +} while (0)
>  
>  #define gb_loopback_attr(field, type)
> \
>  static ssize_t field##_show(struct device *dev,  
> \
> -- 
> 2.27.0

Did you successfully build this change?

Please do so...

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v4] staging: qlge: fix comment style in qlge_main.c

2021-02-16 Thread Greg Kroah-Hartman
On Tue, Feb 16, 2021 at 05:40:12PM +0800, Du Cheng wrote:
> align * in block comments on each line

That says _what_ you did, not _why_ you did it.

And "each line"?  You only did this once.

> This series of patches is for Task 10 of the Eudyptula Challenge

This isn't a "series" of patches, it is a single patch.  And no one
cares about why you are doing this, this text isn't needed at all.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v3] staging: fix coding style in driver/staging/qlge/qlge_main.c

2021-02-16 Thread Greg Kroah-Hartman
On Tue, Feb 16, 2021 at 04:53:26PM +0800, Du Cheng wrote:
> align * in block comments on each line
> 
> changes v3:
> - add SUBSYSTEM in subject line
> - add explanation to past version of this patch
> 
> changes v2:
> - move closing of comment to the same line
> 
> changes v1:
> - align * in block comments

These "changes" should all go below the --- line, right?

And the subject shoudl be a bit more specific, look at how other commits
are done for this driver.  Something like:
Subject: staging: qlge: fix comment style in qlge_main.c
matches much better, and conveys what is actually happening here, right?

v4 please?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: ks7010: cleanup checkpatch.pl macro error

2021-02-14 Thread Greg Kroah-Hartman
On Sun, Feb 14, 2021 at 04:35:23PM +0530, Shreesh Adiga wrote:
> Add parentheses around the macro definitions in ks_hostif.h
> to clear the error output by checkpatch.pl
> 
> Signed-off-by: Shreesh Adiga <16567adigashre...@gmail.com>
> ---
>  drivers/staging/ks7010/ks_hostif.h | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/staging/ks7010/ks_hostif.h 
> b/drivers/staging/ks7010/ks_hostif.h
> index 39138191a556..c62a494ed6bb 100644
> --- a/drivers/staging/ks7010/ks_hostif.h
> +++ b/drivers/staging/ks7010/ks_hostif.h
> @@ -498,20 +498,20 @@ struct hostif_mic_failure_request {
>  #define TX_RATE_FIXED5
>  
>  /* 11b rate */
> -#define TX_RATE_1M   (u8)(10 / 5)/* 11b 11g basic rate */
> -#define TX_RATE_2M   (u8)(20 / 5)/* 11b 11g basic rate */
> -#define TX_RATE_5M   (u8)(55 / 5)/* 11g basic rate */
> -#define TX_RATE_11M  (u8)(110 / 5)   /* 11g basic rate */
> +#define TX_RATE_1M   ((u8)(10 / 5))  /* 11b 11g basic rate */
> +#define TX_RATE_2M   ((u8)(20 / 5))  /* 11b 11g basic rate */
> +#define TX_RATE_5M   ((u8)(55 / 5))  /* 11g basic rate */
> +#define TX_RATE_11M  ((u8)(110 / 5)) /* 11g basic rate */
>  
>  /* 11g rate */
> -#define TX_RATE_6M   (u8)(60 / 5)/* 11g basic rate */
> -#define TX_RATE_12M  (u8)(120 / 5)   /* 11g basic rate */
> -#define TX_RATE_24M  (u8)(240 / 5)   /* 11g basic rate */
> -#define TX_RATE_9M   (u8)(90 / 5)
> -#define TX_RATE_18M  (u8)(180 / 5)
> -#define TX_RATE_36M  (u8)(360 / 5)
> -#define TX_RATE_48M  (u8)(480 / 5)
> -#define TX_RATE_54M  (u8)(540 / 5)
> +#define TX_RATE_6M   ((u8)(60 / 5))  /* 11g basic rate */
> +#define TX_RATE_12M  ((u8)(120 / 5)) /* 11g basic rate */
> +#define TX_RATE_24M  ((u8)(240 / 5)) /* 11g basic rate */
> +#define TX_RATE_9M   ((u8)(90 / 5))
> +#define TX_RATE_18M  ((u8)(180 / 5))
> +#define TX_RATE_36M  ((u8)(360 / 5))
> +#define TX_RATE_48M  ((u8)(480 / 5))
> +#define TX_RATE_54M  ((u8)(540 / 5))
>  
>  static inline bool is_11b_rate(u8 rate)
>  {
> -- 
> 2.30.0


Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- You sent a patch that has been sent multiple times in the past few
  days, and is identical to ones that has been recently rejected.
  Please always look at the mailing list traffic to determine if you are
  duplicating other people's work.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: android: ashmem: Declared file operation with const keyword

2021-02-14 Thread Greg Kroah-Hartman
On Sat, Feb 13, 2021 at 11:31:36PM -0300, Thais Camacho wrote:
> Warning found by checkpatch.pl script
> 
> Signed-off-by: Thais Camacho 
> ---
>  drivers/staging/android/ashmem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/android/ashmem.c 
> b/drivers/staging/android/ashmem.c
> index 4789d36ddfd3..2cb665e0228c 100644
> --- a/drivers/staging/android/ashmem.c
> +++ b/drivers/staging/android/ashmem.c
> @@ -376,7 +376,7 @@ ashmem_vmfile_get_unmapped_area(struct file *file, 
> unsigned long addr,
>  
>  static int ashmem_mmap(struct file *file, struct vm_area_struct *vma)
>  {
> - static struct file_operations vmfile_fops;
> + static const struct file_operations vmfile_fops;
>   struct ashmem_area *asma = file->private_data;
>   int ret = 0;
>  
> -- 
> 2.20.1

Any specific reason why you did not test-build your change before
sending it to us?  Please always do so, otherwise it causes lots of
problems, and makes maintainers grumpy :)

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: wfx: logical continuations should be on the previous line

2021-02-13 Thread Greg Kroah-Hartman
On Sun, Feb 14, 2021 at 05:16:41AM +0800, zhuo1a...@outlook.com wrote:
> Move logical or operator to previous line to comply with
> the standard kernel coding style.
> 
> Signed-off-by: Zhuoran He 
> ---
> drivers/staging/wfx/hif_rx.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/wfx/hif_rx.c b/drivers/staging/wfx/hif_rx.c
> index 56a5f8914..9fca7f263 100644
> --- a/drivers/staging/wfx/hif_rx.c
> +++ b/drivers/staging/wfx/hif_rx.c
> @@ -391,9 +391,9 @@ void wfx_handle_rx(struct wfx_dev *wdev, struct sk_buff
> *skb)
>  }
>  // Note: mutex_is_lock cause an implicit memory barrier that protect
>  // buf_send
> - if (mutex_is_locked(>hif_cmd.lock)
> - && wdev->hif_cmd.buf_send
> - && wdev->hif_cmd.buf_send->id == hif_id) {
> + if (mutex_is_locked(>hif_cmd.lock) &&
> + wdev->hif_cmd.buf_send &&
> + wdev->hif_cmd.buf_send->id == hif_id) {
>   hif_generic_confirm(wdev, hif, hif->body);
>   goto free;
>  }
> --
> 2.30.1

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- Your patch is malformed (tabs converted to spaces, linewrapped, etc.)
  and can not be applied.  Please read the file,
  Documentation/email-clients.txt in order to fix this.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: rtl8723bs: fix function comments to follow kernel-doc

2021-02-11 Thread Greg Kroah-Hartman
On Thu, Feb 11, 2021 at 12:40:15AM +0530, karthik alapati wrote:
> fix checkpatch.pl warning for "block comments should align the
>  * on each line" and make function comments follow kernel-doc
> 
> Signed-off-by: karthik alapati 
> ---
>  .../staging/rtl8723bs/hal/rtl8723b_phycfg.c   | 185 +++---
>  1 file changed, 73 insertions(+), 112 deletions(-)
> 
> diff --git a/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c 
> b/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
> index cf23414d7..1fd504181 100644
> --- a/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
> +++ b/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
> @@ -20,16 +20,11 @@
>  #define MAX_DOZE_WAITING_TIMES_9x 64
>  
>  /**
> -* Function:  phy_CalculateBitShift
> -*
> -* OverView:  Get shifted position of the BitMask
> -*
> -* Input:
> -*u32 BitMask,
> -*
> -* Output:none
> -* Return:u32 Return the shift bit bit position of the mask
> -*/
> + *   phy_CalculateBitShift - Get shifted position of the BitMask.
> + *   @BitMask: Bitmask.
> + *
> + *   Return: Return the shift bit position of the mask
> + */

Why indent these comments by a tab?  A single space is fine.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: rtl8723bs: remove obsolete commented out code

2021-02-11 Thread Greg Kroah-Hartman
A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Thu, Feb 11, 2021 at 04:00:04PM +0530, karthek wrote:
> Should i send them as patch series?

Please do.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: rtl8723bs: fix function comments to follow kernel-doc

2021-02-11 Thread Greg Kroah-Hartman
On Thu, Feb 11, 2021 at 12:48:16AM +0530, karthek wrote:
> check this out

Why ask us again when you already sent a patch?  Do you see any other
developers doing that on the mailing lists?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] Staging: vt6655: Replace a camel case variable name

2021-02-10 Thread Greg Kroah-Hartman
On Thu, Feb 11, 2021 at 12:16:45PM +0530, Aakash Hemadri wrote:
> On 21/02/10 06:50PM, Greg Kroah-Hartman wrote:
> > On Wed, Feb 10, 2021 at 06:42:07PM +0800, Yujia Qiao wrote:
> > > Replace camel case variable names with snake case in baseband.c.
> > >
> > > Signed-off-by: Yujia Qiao 
> > > ---
> > >  drivers/staging/vt6655/baseband.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > This doesn't apply cleanly to my staging-next branch, can you please
> > rebase it and resend?
> >
> > thanks,
> >
> > greg k-h
> > ___
> > devel mailing list
> > de...@linuxdriverproject.org
> > http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
> 
> When I first encountered the CamelCase check I believed that
> making such changes would only cause trouble for others.

Nope.

> Are such changes to API welcome in the kernel?

There is no "stable api" within the kernel, so fixing up incorrect names
is acceptable and required.

> I presume it is as long it doesn't break building the kernel

Of course, no patch can break the kernel build.

> If I do decide to fix such checks what must I look out for?

That everything continues to work as before?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] Staging: vt6655: Replace a camel case variable name

2021-02-10 Thread Greg Kroah-Hartman
On Wed, Feb 10, 2021 at 06:42:07PM +0800, Yujia Qiao wrote:
> Replace camel case variable names with snake case in baseband.c.
> 
> Signed-off-by: Yujia Qiao 
> ---
>  drivers/staging/vt6655/baseband.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

This doesn't apply cleanly to my staging-next branch, can you please
rebase it and resend?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: ralink-gdma: Fix checkpatch.pl CHECK

2021-02-10 Thread Greg Kroah-Hartman
On Wed, Feb 10, 2021 at 05:33:48PM +0530, Aakash Hemadri wrote:
> Remove CHECK: Lines should not end with a '('
> 
> Signed-off-by: Aakash Hemadri 
> ---
> 
>  drivers/staging/ralink-gdma/ralink-gdma.c | 28 ---
>  1 file changed, 15 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/staging/ralink-gdma/ralink-gdma.c 
> b/drivers/staging/ralink-gdma/ralink-gdma.c
> index 655df317d0ee..a11f915f3308 100644
> --- a/drivers/staging/ralink-gdma/ralink-gdma.c
> +++ b/drivers/staging/ralink-gdma/ralink-gdma.c
> @@ -135,8 +135,7 @@ struct gdma_data {
>   int (*start_transfer)(struct gdma_dmaengine_chan *chan);
>  };
> 
> -static struct gdma_dma_dev *gdma_dma_chan_get_dev(
> - struct gdma_dmaengine_chan *chan)
> +static struct gdma_dma_dev *gdma_dma_chan_get_dev(struct gdma_dmaengine_chan 
> *chan)
>  {
>   return container_of(chan->vchan.chan.device, struct gdma_dma_dev,
>   ddev);
> @@ -510,10 +509,11 @@ static void gdma_dma_issue_pending(struct dma_chan *c)
>   spin_unlock_irqrestore(>vchan.lock, flags);
>  }
> 
> -static struct dma_async_tx_descriptor *gdma_dma_prep_slave_sg(
> - struct dma_chan *c, struct scatterlist *sgl,
> - unsigned int sg_len, enum dma_transfer_direction direction,
> - unsigned long flags, void *context)
> +static struct dma_async_tx_descriptor
> + *gdma_dma_prep_slave_sg(struct dma_chan *c, struct scatterlist *sgl,
> + unsigned int sg_len,
> + enum dma_transfer_direction direction,
> + unsigned long flags, void *context)
>  {
>   struct gdma_dmaengine_chan *chan = to_gdma_dma_chan(c);
>   struct gdma_dma_desc *desc;
> @@ -558,9 +558,10 @@ static struct dma_async_tx_descriptor 
> *gdma_dma_prep_slave_sg(
>   return NULL;
>  }
> 
> -static struct dma_async_tx_descriptor *gdma_dma_prep_dma_memcpy(
> - struct dma_chan *c, dma_addr_t dest, dma_addr_t src,
> - size_t len, unsigned long flags)
> +static struct dma_async_tx_descriptor
> + *gdma_dma_prep_dma_memcpy(struct dma_chan *c,
> +   dma_addr_t dest, dma_addr_t src,
> +   size_t len, unsigned long flags)
>  {
>   struct gdma_dmaengine_chan *chan = to_gdma_dma_chan(c);
>   struct gdma_dma_desc *desc;
> @@ -601,10 +602,11 @@ static struct dma_async_tx_descriptor 
> *gdma_dma_prep_dma_memcpy(
>   return vchan_tx_prep(>vchan, >vdesc, flags);
>  }
> 
> -static struct dma_async_tx_descriptor *gdma_dma_prep_dma_cyclic(
> - struct dma_chan *c, dma_addr_t buf_addr, size_t buf_len,
> - size_t period_len, enum dma_transfer_direction direction,
> - unsigned long flags)
> +static struct dma_async_tx_descriptor
> + *gdma_dma_prep_dma_cyclic(struct dma_chan *c, dma_addr_t buf_addr,
> +   size_t buf_len, size_t period_len,
> +   enum dma_transfer_direction direction,
> +       unsigned long flags)
>  {
>   struct gdma_dmaengine_chan *chan = to_gdma_dma_chan(c);
>   struct gdma_dma_desc *desc;
> --
> 2.30.0

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- You did not write a descriptive Subject: for the patch, allowing Greg,
  and everyone else, to know what this patch is all about.  Please read
  the section entitled "The canonical patch format" in the kernel file,
  Documentation/SubmittingPatches for what a proper Subject: line should
  look like.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: rtl8723bs: fix block comments alignment

2021-02-09 Thread Greg Kroah-Hartman
On Wed, Feb 10, 2021 at 12:23:17AM +0530, karthik alapati wrote:
> fix checkpatch.pl warning for "block comments should align the * on each line"
> 
> Signed-off-by: karthik alapati 
> ---
>  .../staging/rtl8723bs/hal/rtl8723b_phycfg.c   | 204 +-
>  1 file changed, 102 insertions(+), 102 deletions(-)
> 
> diff --git a/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c 
> b/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
> index cf23414d7..003f954c2 100644
> --- a/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
> +++ b/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
> @@ -20,16 +20,16 @@
>  #define MAX_DOZE_WAITING_TIMES_9x 64
>  
>  /**
> -* Function:  phy_CalculateBitShift
> -*
> -* OverView:  Get shifted position of the BitMask
> -*
> -* Input:
> -*u32 BitMask,
> -*
> -* Output:none
> -* Return:u32 Return the shift bit bit position of the mask
> -*/
> + * Function: phy_CalculateBitShift
> + *
> + * OverView: Get shifted position of the BitMask
> + *
> + * Input:
> + *   u32 BitMask,
> + *
> + * Output:   none
> + * Return:   u32 Return the shift bit bit position of the mask
> + */

These huge function comments are not normal kernel coding style anyway,
why not fix them up to use the correct style, don't paper over it and
keep this mess around any longer than it needs to be.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH AUTOSEL 5.10 14/36] media: rkisp1: uapi: change hist_bins array type from __u16 to __u32

2021-02-09 Thread Greg Kroah-Hartman
On Tue, Feb 09, 2021 at 02:39:41PM +0100, Hans Verkuil wrote:
> On 09/02/2021 14:02, Greg Kroah-Hartman wrote:
> > On Tue, Feb 09, 2021 at 01:45:35PM +0100, Dafna Hirschfeld wrote:
> >>
> >>
> >> Am 08.02.21 um 21:46 schrieb Hans Verkuil:
> >>> On 08/02/2021 18:57, Sasha Levin wrote:
> >>>> From: Dafna Hirschfeld 
> >>>>
> >>>> [ Upstream commit 31f190e0ccac8b75d33fdc95a797c526cf9b149e ]
> >>>>
> >>>> Each entry in the array is a 20 bits value composed of 16 bits unsigned
> >>>> integer and 4 bits fractional part. So the type should change to __u32.
> >>>> In addition add a documentation of how the measurements are done.
> >>>
> >>> Dafna, Helen, does it make sense at all to backport these three patches to
> >>> when rkisp1 was a staging driver?
> >>>
> >>> I would be inclined not to backport this.
> >>
> >> I also don't think it makes sense since this changes the uapi and it is 
> >> not really a bug fix.
> > 
> > Why was it ok to change the uapi in a newer kernel and not an older one?
> 
> In the older kernels this was a staging driver and the driver API was not 
> public.
> It's debatable whether there is any benefit from trying to backport patches 
> like
> this to a staging driver like that.
> 
> Also, these backports are incomplete, there are other patches that would need 
> to
> be applied to make this work. Applying just these three patches without the 
> other
> three (commits 66d81de7ea9d, fc672d806bd7 and ef357e02b6c4) makes it very 
> messy
> indeed.
> 
> I'd just leave the staging driver in older kernels as-is. Certainly don't just
> apply these three patches without the other three commits, that would make it
> even worse.

Fair enough, Sasha, can you drop these?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH AUTOSEL 5.10 14/36] media: rkisp1: uapi: change hist_bins array type from __u16 to __u32

2021-02-09 Thread Greg Kroah-Hartman
On Tue, Feb 09, 2021 at 01:45:35PM +0100, Dafna Hirschfeld wrote:
> 
> 
> Am 08.02.21 um 21:46 schrieb Hans Verkuil:
> > On 08/02/2021 18:57, Sasha Levin wrote:
> > > From: Dafna Hirschfeld 
> > > 
> > > [ Upstream commit 31f190e0ccac8b75d33fdc95a797c526cf9b149e ]
> > > 
> > > Each entry in the array is a 20 bits value composed of 16 bits unsigned
> > > integer and 4 bits fractional part. So the type should change to __u32.
> > > In addition add a documentation of how the measurements are done.
> > 
> > Dafna, Helen, does it make sense at all to backport these three patches to
> > when rkisp1 was a staging driver?
> > 
> > I would be inclined not to backport this.
> 
> I also don't think it makes sense since this changes the uapi and it is not 
> really a bug fix.

Why was it ok to change the uapi in a newer kernel and not an older one?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: rtl8723bs: fix block comments alignment

2021-02-07 Thread Greg Kroah-Hartman
This function is equal to "PutRFRegSetting" in PHY 
> programming guide
> -*/
> + * Function: PHY_SetRFReg
> + *
> + * OverView: Write "Specific bits" to RF register (page 8~)
> + *
> + * Input:
> + *   struct adapter *Adapter,
> + *   RF_PATH eRFPath,Radio path of A/B/C/D
> + *   u32 RegAddr,The target address to be 
> modified
> + *   u32 BitMask The target bit position in the 
> target address
> + *   to be modified
> + *   u32 DataThe new register Data in the 
> target bit position
> + *   of the target 
> address
> + *
> + * Output:   None
> + * Return:   None
> + * Note: This function is equal to "PutRFRegSetting" in PHY 
> programming guide
> + */
>  void PHY_SetRFReg_8723B(
>   struct adapter *Adapter,
>   u8 eRFPath,
> @@ -369,17 +369,17 @@ s32 PHY_MACConfig8723B(struct adapter *Adapter)
>  }
>  
>  /**
> -* Function:  phy_InitBBRFRegisterDefinition
> -*
> -* OverView:  Initialize Register definition offset for Radio Path A/B/C/D
> -*
> -* Input:
> -*struct adapter *Adapter,
> -*
> -* Output:None
> -* Return:None
> -* Note:  The initialization value is constant and it should 
> never be changes
> -*/
> + * Function: phy_InitBBRFRegisterDefinition
> + *
> + * OverView: Initialize Register definition offset for Radio Path A/B/C/D
> + *
> + * Input:
> + *   struct adapter *Adapter,
> + *
> + * Output:   None
> + * Return:   None
> + * Note: The initialization value is constant and it should 
> never be changes
> + */
>  static void phy_InitBBRFRegisterDefinition(struct adapter *Adapter)
>  {
>   struct hal_com_data *pHalData = GET_HAL_DATA(Adapter);
> -- 
> 2.30.0
> 
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- It looks like you did not use your "real" name for the patch on either
  the Signed-off-by: line, or the From: line (both of which have to
  match).  Please read the kernel file, Documentation/SubmittingPatches
  for how to do this correctly.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: fix ignoring return value warning

2021-02-07 Thread Greg Kroah-Hartman
On Sun, Feb 07, 2021 at 05:23:28PM +0800, Youling Tang wrote:
> Fix the below ignoring return value warning for device_reset.
> 
> drivers/staging/mt7621-dma/mtk-hsdma.c:685:2: warning: ignoring return value
> of function declared with 'warn_unused_result' attribute [-Wunused-result]
> device_reset(>dev);
> ^~~~ ~~
> drivers/staging/ralink-gdma/ralink-gdma.c:836:2: warning: ignoring return 
> value
> of function declared with 'warn_unused_result' attribute [-Wunused-result]
> device_reset(>dev);
> ^~~~ ~~
> 
> Signed-off-by: Youling Tang 
> ---
>  drivers/staging/mt7621-dma/mtk-hsdma.c| 6 +-
>  drivers/staging/ralink-gdma/ralink-gdma.c | 6 +-
>  2 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/mt7621-dma/mtk-hsdma.c 
> b/drivers/staging/mt7621-dma/mtk-hsdma.c
> index bc4bb43..d4ffa52 100644
> --- a/drivers/staging/mt7621-dma/mtk-hsdma.c
> +++ b/drivers/staging/mt7621-dma/mtk-hsdma.c
> @@ -682,7 +682,11 @@ static int mtk_hsdma_probe(struct platform_device *pdev)
>   return ret;
>   }
>  
> - device_reset(>dev);
> + ret = device_reset(>dev);
> + if (ret) {
> + dev_err(>dev, "failed to reset device\n");
> + return ret;
> + }
>  
>   dd = >ddev;
>   dma_cap_set(DMA_MEMCPY, dd->cap_mask);
> diff --git a/drivers/staging/ralink-gdma/ralink-gdma.c 
> b/drivers/staging/ralink-gdma/ralink-gdma.c
> index 655df31..df99c47 100644
> --- a/drivers/staging/ralink-gdma/ralink-gdma.c
> +++ b/drivers/staging/ralink-gdma/ralink-gdma.c
> @@ -833,7 +833,11 @@ static int gdma_dma_probe(struct platform_device *pdev)
>   return ret;
>   }
>  
> - device_reset(>dev);
> + ret = device_reset(>dev);
> + if (ret) {
> + dev_err(>dev, "failed to reset device\n");
> + return ret;
> + }
>  
>   dd = _dev->ddev;
>   dma_cap_set(DMA_MEMCPY, dd->cap_mask);
> -- 
> 2.1.0
> 


Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- Your patch did not apply to any known trees that Greg is in control
  of.  Possibly this is because you made it against Linus's tree, not
  the linux-next tree, which is where all of the development for the
  next version of the kernel is at.  Please refresh your patch against
  the linux-next tree, or even better yet, the development tree
  specified in the MAINTAINERS file for the subsystem you are submitting
  a patch for, and resend it.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging/mt7621-dma: mtk-hsdma.c->hsdma-mt7621.c

2021-02-02 Thread Greg Kroah-Hartman
On Tue, Feb 02, 2021 at 11:31:17AM +0300, Dan Carpenter wrote:
> Apparently this was already merged?  Never mind then.  Once it's merged
> it can't be changed.  No big stress...

Sorry, yes, already in my tree...
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v8 00/14] Move Hisilicon 6421v600 SPMI and USB drivers out of staging

2021-01-31 Thread Greg Kroah-Hartman
On Fri, Jan 29, 2021 at 08:51:46PM +0100, Mauro Carvalho Chehab wrote:
> Hi Greg/Mark/Lee/Vinod,
> 
> Another rebase , also the top of staging-testing.
> 
> This series contain the remaining patches for USB to start working,
> except for a final DTS patch.
> 
> Patches 1 and 2 convert the SPMI and regulator
> drivers to use regmap and simplifies the logic by using
> regmap helpers.
> 
> Patches 3 to 9 address some issues pointed by Lee at the MFD driver.
> 
> I guess the best would be if Greg could apply patches 1 to 9
> via the staging tree.

I've taken these first 9 patches in my staging tree.  If any other
subsystem maintainer wants to ack the move of the files out of staging
to their respective subsystems, I'll gladly apply those patches here as
well.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 1/2] staging: greybus: vibrator: use proper API for vibrator devices

2021-01-29 Thread Greg Kroah-Hartman
On Wed, Jan 06, 2021 at 01:08:15PM +0100, Johan Hovold wrote:
> On Wed, Jan 06, 2021 at 01:04:04PM +0100, Johan Hovold wrote:
> > On Tue, Jan 05, 2021 at 04:19:02PM +0100, Greg Kroah-Hartman wrote:
> > > The correct user/kernel api for vibrator devices is the Input rumble
> > > api, not a random sysfs file like the greybus vibrator driver currently
> > > uses.
> > > 
> > > Add support for the correct input api to the vibrator driver so that it
> > > hooks up to the kernel and userspace correctly.
> > > 
> > > Cc: Johan Hovold 
> > > Cc: Alex Elder 
> > > Signed-off-by: Greg Kroah-Hartman 
> > > ---
> > >  drivers/staging/greybus/vibrator.c | 59 ++
> > >  1 file changed, 59 insertions(+)
> > > 
> > > diff --git a/drivers/staging/greybus/vibrator.c 
> > > b/drivers/staging/greybus/vibrator.c
> > > index 0e2b188e5ca3..94110cadb5bd 100644
> > > --- a/drivers/staging/greybus/vibrator.c
> > > +++ b/drivers/staging/greybus/vibrator.c
> > > @@ -13,13 +13,18 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >  
> > >  struct gb_vibrator_device {
> > >   struct gb_connection*connection;
> > > + struct input_dev*input;
> > >   struct device   *dev;
> > >   int minor;  /* vibrator minor number */
> > >   struct delayed_work delayed_work;
> > > + boolrunning;
> > > + boolon;
> > > + struct work_struct  play_work;
> > >  };
> > >  
> > >  /* Greybus Vibrator operation types */
> > > @@ -36,6 +41,7 @@ static int turn_off(struct gb_vibrator_device *vib)
> > >  
> > >   gb_pm_runtime_put_autosuspend(bundle);
> > >  
> > > + vib->on = false;
> > 
> > You update but never seem to actually use vib->on.
> > 
> > >   return ret;
> > >  }
> > >  
> > > @@ -59,11 +65,48 @@ static int turn_on(struct gb_vibrator_device *vib, 
> > > u16 timeout_ms)
> > >   return ret;
> > >   }
> > >  
> > > + vib->on = true;
> > >   schedule_delayed_work(>delayed_work, msecs_to_jiffies(timeout_ms));
> > >  
> > >   return 0;
> > >  }
> > >  
> > > +static void gb_vibrator_play_work(struct work_struct *work)
> > > +{
> > > + struct gb_vibrator_device *vib =
> > > + container_of(work, struct gb_vibrator_device, play_work);
> > > +
> > > + if (vib->running)
> > 
> > Is this test inverted?
> > 
> > > + turn_off(vib);
> > > + else
> > > + turn_on(vib, 100);
> > 
> > Why 100 ms?
> > 
> > Shouldn't it just be left on indefinitely with the new API?
> > 
> > > +}
> > > +
> > > +static int gb_vibrator_play_effect(struct input_dev *input, void *data,
> > > +struct ff_effect *effect)
> > > +{
> > > + struct gb_vibrator_device *vib = input_get_drvdata(input);
> > > + int level;
> > > +
> > > + level = effect->u.rumble.strong_magnitude;
> > > + if (!level)
> > > + level = effect->u.rumble.weak_magnitude;
> > > +
> > > + vib->running = level;
> > > + schedule_work(>play_work);
> > > + return 0;
> > > +}
> > > +
> > > +static void gb_vibrator_close(struct input_dev *input)
> > > +{
> > > + struct gb_vibrator_device *vib = input_get_drvdata(input);
> > > +
> > > + cancel_delayed_work_sync(>delayed_work);
> > > + cancel_work_sync(>play_work);
> > > + turn_off(vib);
> > > + vib->running = false;
> > > +}
> > > +
> > >  static void gb_vibrator_worker(struct work_struct *work)
> > >  {
> > >   struct delayed_work *delayed_work = to_delayed_work(work);
> > > @@ -169,10 +212,26 @@ static int gb_vibrator_probe(struct gb_bundle 
> > > *bundle,
> > >  
> > >   INIT_DELAYED_WORK(>delayed_work, gb_vibrator_worker);
> > >  
> > > + INIT_WORK(>play_work, gb_vibrator_play_work);
> > 
> > Hmm. Looks like you forgot to actually allocate the input device...
> > 
> > > + vib->input->name = "greybus-vibrator";
> > > + vib->input->close = gb_vibrator_close;
> > > + vib->input->dev.parent = >dev;
> > > + vib->input->id.bustype = BUS_HOST;
> > > +
> > > + input_set_drvdata(vib->input, vib);
> > > + input_set_capability(vib->input, EV_FF, FF_RUMBLE);
> > > +
> > > + retval = input_ff_create_memless(vib->input, NULL,
> > > +  gb_vibrator_play_effect);
> > > + if (retval)
> > > + goto err_device_remove;
> > > +
> 
> Oh, and you forgot to register the input device here too (and deregister
> in remove()).

Ugh, wow, this patch series is messed up, sorry about that, and thanks
for the review.  I'll fix this up when I next get a chance and resend.

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v7 01/14] staging: hikey9xx: spmi driver: convert to regmap

2021-01-29 Thread Greg Kroah-Hartman
On Fri, Jan 29, 2021 at 04:03:36PM +0100, Mauro Carvalho Chehab wrote:
> Instead of doing its own SPMI I/O implementation, use the
> already-existing regmap one.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/staging/hikey9xx/hi6421-spmi-pmic.c   | 115 ++
>  .../staging/hikey9xx/hi6421v600-regulator.c   |  26 ++--
>  include/linux/mfd/hi6421-spmi-pmic.h  |   7 +-
>  3 files changed, 52 insertions(+), 96 deletions(-)

After applying this, I get a build failure:

ERROR: modpost: "__devm_regmap_init_spmi_ext" 
[drivers/staging/hikey9xx/hi6421-spmi-pmic.ko] undefined!

So you need some sort of build dependancy here :(

Also, when I apply the first 9 patches and stop, I get a build error
that you should see as well, so I can't take any of these right now,
sorry.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v12] staging: fbtft: add tearing signal detect

2021-01-29 Thread Greg Kroah-Hartman
On Fri, Jan 29, 2021 at 12:23:08PM +0200, Andy Shevchenko wrote:
> On Fri, Jan 29, 2021 at 7:01 AM carlis  wrote:
> > On Thu, 28 Jan 2021 16:33:02 +0200
> > Andy Shevchenko  wrote:
> > > On Thu, Jan 28, 2021 at 2:58 PM Carlis  wrote:
> > >
> > > Thanks for your contribution, my comments below.
> > >
> > > > From: zhangxuezhi 
> > >
> > > You probably have to configure your Git to use the same account for
> > > author and committer.
> >
> > hi,you mean like below:
> > Carlis 
> > ?
> 
> I meant that you shouldn't probably have a From: line in the commit message.

It's fine, some people like to be sure about this, there is no problem
with it being there at all.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: qlge/qlge_ethtool.c: strlcpy -> strscpy

2021-01-29 Thread Greg Kroah-Hartman
On Fri, Jan 29, 2021 at 02:38:33PM +0530, Kumar Kartikeya Dwivedi wrote:
> On 0129, Greg Kroah-Hartman wrote:
> > On Fri, Jan 29, 2021 at 01:51:55PM +0530, Kumar Kartikeya Dwivedi wrote:
> > > [Forgot to reply-all]
> > > 
> > > On 0129, Greg Kroah-Hartman wrote:
> > > > On Fri, Jan 29, 2021 at 12:15:23PM +0530, Kumar Kartikeya Dwivedi wrote:
> > > > > Fixes checkpatch warnings for usage of strlcpy.
> > > > 
> > > > What warning would that be?
> > > > 
> > > 
> > > 5dbdb2d87c294401a22e6a6002f08ebc9fbea38b
> > > 
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5dbdb2d87c294401a22e6a6002f08ebc9fbea38b
> > 
> > Hint, in the future, write the above as: 5dbdb2d87c29 ("checkpatch:
> > prefer strscpy to strlcpy").  The documentation has examples of how to
> > do this easily.
> > 
> > And yes, I know that checkpatch says that, but I need to know how you
> > know this is the correct change.
> > 
> > > > And if we could just search/replace for this, why hasn't that already
> > > > happened for the whole tree?
> > > >
> > > 
> > > I think that's because it is hard to tell whether truncation is expected 
> > > at the
> > > call site or not, so each change needs to be audited manually (to check 
> > > the
> > > return value or not). In cases where it's just a safe strcpy, strscpy is a
> > > relatively better choice (due to not reading the entire source string).
> > 
> > Did you do that auditing?  I need to know that you did and that this is
> > fine, or that maybe, this isn't needed at all?  All of that information
> > needs to go in the changelog.
> 
> Yes, because it's copying the source strings to fixed size buffers in
> ethtool_drvinfo, so truncation would be fine here (as it's the driver name and
> other identity related stuff).

So there is no need to make this change, or it is required to make this
change?  I can't tell from your response here.

> Should I send a v2 with the reason?

I've already rejected the first one as being incomplete :)

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: qlge/qlge_ethtool.c: strlcpy -> strscpy

2021-01-29 Thread Greg Kroah-Hartman
On Fri, Jan 29, 2021 at 01:51:55PM +0530, Kumar Kartikeya Dwivedi wrote:
> [Forgot to reply-all]
> 
> On 0129, Greg Kroah-Hartman wrote:
> > On Fri, Jan 29, 2021 at 12:15:23PM +0530, Kumar Kartikeya Dwivedi wrote:
> > > Fixes checkpatch warnings for usage of strlcpy.
> > 
> > What warning would that be?
> > 
> 
> 5dbdb2d87c294401a22e6a6002f08ebc9fbea38b
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5dbdb2d87c294401a22e6a6002f08ebc9fbea38b

Hint, in the future, write the above as: 5dbdb2d87c29 ("checkpatch:
prefer strscpy to strlcpy").  The documentation has examples of how to
do this easily.

And yes, I know that checkpatch says that, but I need to know how you
know this is the correct change.

> > And if we could just search/replace for this, why hasn't that already
> > happened for the whole tree?
> >
> 
> I think that's because it is hard to tell whether truncation is expected at 
> the
> call site or not, so each change needs to be audited manually (to check the
> return value or not). In cases where it's just a safe strcpy, strscpy is a
> relatively better choice (due to not reading the entire source string).

Did you do that auditing?  I need to know that you did and that this is
fine, or that maybe, this isn't needed at all?  All of that information
needs to go in the changelog.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: qlge/qlge_ethtool.c: strlcpy -> strscpy

2021-01-29 Thread Greg Kroah-Hartman
On Fri, Jan 29, 2021 at 12:15:23PM +0530, Kumar Kartikeya Dwivedi wrote:
> Fixes checkpatch warnings for usage of strlcpy.

What warning would that be?

And if we could just search/replace for this, why hasn't that already
happened for the whole tree?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v5 00/21] Move Hisilicon 6421v600 SPMI driver set out of staging

2021-01-27 Thread Greg Kroah-Hartman
On Wed, Jan 27, 2021 at 12:04:26PM +, Mark Brown wrote:
> On Wed, Jan 27, 2021 at 09:57:40AM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Jan 26, 2021 at 06:11:24PM +, Mark Brown wrote:
> 
> > > > Do you need a tag to pull from?
> 
> > > It'd be nice but not essential.
> 
> > Why do you want/need this?  Having these changes in your tree is good,
> > but what about other coding style cleanups that I will end up applying
> > over time before the 5.12-rc1 merge window opens?  Are you wanting to
> > take the moved driver in your tree, or something else?
> 
> I want to apply the regulator driver so I stop being sent this patch
> series which will help keep my backlog more manageable.
> 
> > Traditionally moving drivers out of staging can be done 2 ways:
> > - all happens in the staging tree, I take an ack from the
> >   subsystem maintainer that this is ok to do.
> > - A new driver enters the "real" subsystem tree, and then I
> >   delete the driver in the staging tree.  This doesn't preserve
> >   history as well (not at all), but can be easier for trees that
> >   move quickly (like networking.)
> 
> The whole reason the driver is in the staging tree is that Mauro has a
> requirement to do things in a way that preserves history and so won't
> send any non-incremental patches.

Ok, should we wait until after 5.12-rc1 is out then?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: greybus: audio_helper.c: Replace strlcpy() with strscpy()

2021-01-27 Thread Greg Kroah-Hartman
On Sat, Jan 09, 2021 at 06:57:31PM +0530, B K Karthik wrote:
> In gbaudio_remove_controls() , replace the usage of strlcpy() with
> strscpy() because strlcpy() only limits the *destination*
> size, and the source is always read fully.
> 
> https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
> was quoted by checkpatch while showing this warning.
> 
> Signed-off-by: B K Karthik 
> ---
>  drivers/staging/greybus/audio_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/greybus/audio_helper.c 
> b/drivers/staging/greybus/audio_helper.c
> index 3011b8abce38..1ed4772d2771 100644
> --- a/drivers/staging/greybus/audio_helper.c
> +++ b/drivers/staging/greybus/audio_helper.c
> @@ -166,7 +166,7 @@ static int gbaudio_remove_controls(struct snd_card *card, 
> struct device *dev,
>   snprintf(id.name, sizeof(id.name), "%s %s", prefix,
>control->name);
>   else
> - strlcpy(id.name, control->name, sizeof(id.name));
> + strscpy(id.name, control->name, sizeof(id.name));

Is this something that matters here?  Isn't the string coming from the
kernel (i.e. a trusted source), or if not, where is it coming from?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v5 00/21] Move Hisilicon 6421v600 SPMI driver set out of staging

2021-01-27 Thread Greg Kroah-Hartman
On Wed, Jan 27, 2021 at 10:08:16AM +, Lee Jones wrote:
> On Wed, 27 Jan 2021, Greg Kroah-Hartman wrote:
> 
> > On Tue, Jan 26, 2021 at 06:11:24PM +, Mark Brown wrote:
> > > On Tue, Jan 26, 2021 at 07:02:39PM +0100, Greg Kroah-Hartman wrote:
> > > > On Tue, Jan 26, 2021 at 05:57:52PM +, Mark Brown wrote:
> > > 
> > > > > Is there a branch we can pull from?
> > > 
> > > > Once 0-day passes, you can pull from my staging-testing branch from
> > > > staging.git on git.kernel.org if you want.  Give it 24 hours to pass
> > > > before it hits that location.
> > > 
> > > Thanks.
> > 
> > Should be out there now if you want to pull.
> > 
> > > > Do you need a tag to pull from?
> > > 
> > > It'd be nice but not essential.
> > 
> > Why do you want/need this?  Having these changes in your tree is good,
> > but what about other coding style cleanups that I will end up applying
> > over time before the 5.12-rc1 merge window opens?  Are you wanting to
> > take the moved driver in your tree, or something else?
> > 
> > Traditionally moving drivers out of staging can be done 2 ways:
> > - all happens in the staging tree, I take an ack from the
> >   subsystem maintainer that this is ok to do.
> > - A new driver enters the "real" subsystem tree, and then I
> >   delete the driver in the staging tree.  This doesn't preserve
> >   history as well (not at all), but can be easier for trees that
> >   move quickly (like networking.)
> > 
> > Which ever works for you is fine with me, but relying on the code to
> > stay "not touched" in my tree after you pull it almost never happens due
> > to the number of drive-by coding style cleanups that end up in the
> > staging tree every week.
> 
> I would have expected the whole set to be merged as a set into a
> single tree, placed on an immutable branch and a pull-request to be
> sent out for the other maintainers to pull from (if they so wished).
> 
> This would ensure development could continue on any/all of the
> affected drivers/files.
> 
> If it's not too late, I'd be more than happy to facilitate.

Given these patches are already in my public tree, that might be a bit
harder, why the huge work for this?  Worst case, I just keep all of the
patches that do not actually move the code in my tree, and then things
can move after 5.12-rc1.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v5 00/21] Move Hisilicon 6421v600 SPMI driver set out of staging

2021-01-27 Thread Greg Kroah-Hartman
On Tue, Jan 26, 2021 at 06:11:24PM +, Mark Brown wrote:
> On Tue, Jan 26, 2021 at 07:02:39PM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Jan 26, 2021 at 05:57:52PM +, Mark Brown wrote:
> 
> > > Is there a branch we can pull from?
> 
> > Once 0-day passes, you can pull from my staging-testing branch from
> > staging.git on git.kernel.org if you want.  Give it 24 hours to pass
> > before it hits that location.
> 
> Thanks.

Should be out there now if you want to pull.

> > Do you need a tag to pull from?
> 
> It'd be nice but not essential.

Why do you want/need this?  Having these changes in your tree is good,
but what about other coding style cleanups that I will end up applying
over time before the 5.12-rc1 merge window opens?  Are you wanting to
take the moved driver in your tree, or something else?

Traditionally moving drivers out of staging can be done 2 ways:
- all happens in the staging tree, I take an ack from the
  subsystem maintainer that this is ok to do.
- A new driver enters the "real" subsystem tree, and then I
  delete the driver in the staging tree.  This doesn't preserve
  history as well (not at all), but can be easier for trees that
  move quickly (like networking.)

Which ever works for you is fine with me, but relying on the code to
stay "not touched" in my tree after you pull it almost never happens due
to the number of drive-by coding style cleanups that end up in the
staging tree every week.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v5 00/21] Move Hisilicon 6421v600 SPMI driver set out of staging

2021-01-26 Thread Greg Kroah-Hartman
On Tue, Jan 26, 2021 at 05:57:52PM +, Mark Brown wrote:
> On Tue, Jan 26, 2021 at 06:54:57PM +0100, Greg Kroah-Hartman wrote:
> 
> > I've applied the first 13 patches, except for patch 3, as that did not
> > apply, to my tree, thanks.
> 
> Is there a branch we can pull from?

Once 0-day passes, you can pull from my staging-testing branch from
staging.git on git.kernel.org if you want.  Give it 24 hours to pass
before it hits that location.

Do you need a tag to pull from?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v5 00/21] Move Hisilicon 6421v600 SPMI driver set out of staging

2021-01-26 Thread Greg Kroah-Hartman
On Thu, Jan 21, 2021 at 08:18:02AM +0100, Mauro Carvalho Chehab wrote:
> Hi Mark/Lee,
> 
> This patch series finish addressing support for Hikey 970
> SPMI controller, PMIC and regulators.
> 
> This version was generated with -M, in order to make easier
> to merge upstream.  Also, rebased on the top of v5.10,
> without any dependencies from the other patch series
> I'm submitting for this board.
> 
> Yet,  patch 18 to 20 modifies drivers/staging/hikey9xx/Kconfig
> and drivers/staging/hikey9xx/Makefile. So, trivial conflicts
> will rise if they're applied via different trees, as they all
> remove some lines from such files. 

I've applied the first 13 patches, except for patch 3, as that did not
apply, to my tree, thanks.

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v4 0/5] Promote Hikey 970 USB phy out of staging

2021-01-26 Thread Greg Kroah-Hartman
On Tue, Jan 19, 2021 at 11:44:38AM +0100, Mauro Carvalho Chehab wrote:
> Hi Vinod/Rob,
> 
> This series moves  the Hikey 970 USB PHY driver out of staging.
> 
> Patches 1 to 4 contain the fixes from staging. Patch 5 moves the
> driver from staging:
> 
>   $ git show 82ce73ac9a38 --summary
>   ...
>rename drivers/staging/hikey9xx/phy-hi3670-usb3.yaml => 
> Documentation/devicetree/bindings/phy/hisilicon,hi3670-usb3.yaml (100%)
>rename drivers/{staging/hikey9xx => phy/hisilicon}/phy-hi3670-usb3.c 
> (100%)
> 
> I opted to use --no-renames on this series in order to make easier to
> review via e-mail, as the entire driver and DT bindings will be seen
> at the last patch on this series.

First 4 patches applied to my tree, thanks.

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: rtl8723bs: fix wireless regulatory API misuse

2021-01-26 Thread Greg Kroah-Hartman
On Tue, Jan 26, 2021 at 11:54:09AM +0100, Johannes Berg wrote:
> From: Johannes Berg 
> 
> This code ends up calling wiphy_apply_custom_regulatory(), for which
> we document that it should be called before wiphy_register(). This
> driver doesn't do that, but calls it from ndo_open() with the RTNL
> held, which caused deadlocks.
> 
> Since the driver just registers static regdomain data and then the
> notifier applies the channel changes if any, there's no reason for
> it to call this in ndo_open(), move it earlier to fix the deadlock.
> 
> Reported-and-tested-by: Hans de Goede 
> Fixes: 51d62f2f2c50 ("cfg80211: Save the regulatory domain with a lock")
> Signed-off-by: Johannes Berg 
> ---
> Greg, can you take this for 5.11 please? Or if you prefer, since the
> patch that exposed this and broke the driver went through my tree, I
> can take it as well.

Please feel free to take it through yours, as I don't think I'll have
any more staging patches for 5.11-final (or none have been sent to me
yet), so this might be the fastest way in:

Acked-by: Greg Kroah-Hartman 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] media: atomisp: ov2722: replace hardcoded function name

2021-01-06 Thread Greg Kroah-Hartman
On Wed, Jan 06, 2021 at 07:43:42PM +0200, Filip Kolev wrote:
> 
> 
> On 06-Jan-21 09:51, Greg Kroah-Hartman wrote:
> > On Tue, Jan 05, 2021 at 10:29:18PM +0200, Filip Kolev wrote:
> > > There is a debug message using hardcoded function name instead of the
> > > __func__ macro. Replace it.
> > > 
> > > Report from checkpatch.pl on the file:
> > > 
> > > WARNING: Prefer using '"%s...", __func__' to using 'ov2722_remove', this 
> > > function's name, in a string
> > > + dev_dbg(>dev, "ov2722_remove...\n");
> > > 
> > > Signed-off-by: Filip Kolev 
> > > ---
> > >   drivers/staging/media/atomisp/i2c/atomisp-ov2722.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/staging/media/atomisp/i2c/atomisp-ov2722.c 
> > > b/drivers/staging/media/atomisp/i2c/atomisp-ov2722.c
> > > index eecefcd734d0e..21d6bc62d452a 100644
> > > --- a/drivers/staging/media/atomisp/i2c/atomisp-ov2722.c
> > > +++ b/drivers/staging/media/atomisp/i2c/atomisp-ov2722.c
> > > @@ -1175,7 +1175,7 @@ static int ov2722_remove(struct i2c_client *client)
> > >   struct v4l2_subdev *sd = i2c_get_clientdata(client);
> > >   struct ov2722_device *dev = to_ov2722_sensor(sd);
> > > - dev_dbg(>dev, "ov2722_remove...\n");
> > > + dev_dbg(>dev, "%s...\n", __func__);
> > 
> > dev_dbg() provides the function name already, and this is just a "trace"
> > call, and ftrace should be used instead, so the whole line should be
> > removed entirely.
> 
> Thank you for the review!
> 
> How do I go about this? Do I amend the patch and re-send as v2 or create a
> new patch entirely?

New patch entirely please.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: ION: remove some references to CONFIG_ION

2021-01-06 Thread Greg Kroah-Hartman
On Wed, Jan 06, 2021 at 03:52:01PM +, Matthias Maennich wrote:
> With commit e722a295cf49 ("staging: ion: remove from the tree"), ION and
> its corresponding config CONFIG_ION is gone. Remove stale references
> from drivers/staging/media/atomisp/pci and from the recommended Android
> kernel config.
> 
> Fixes: e722a295cf49 ("staging: ion: remove from the tree")
> Cc: Greg Kroah-Hartman 
> Cc: Hridya Valsaraju 
> Cc: Rob Herring 
> Cc: linux-me...@vger.kernel.org
> Cc: de...@driverdev.osuosl.org
> Signed-off-by: Matthias Maennich 
> ---
>  .../media/atomisp/pci/atomisp_subdev.c| 20 ---
>  kernel/configs/android-recommended.config |  1 -
>  2 files changed, 21 deletions(-)

Thanks for finding these remnants, I'll go queue this up now.

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] media: atomisp: ov2722: replace hardcoded function name

2021-01-05 Thread Greg Kroah-Hartman
On Tue, Jan 05, 2021 at 10:29:18PM +0200, Filip Kolev wrote:
> There is a debug message using hardcoded function name instead of the
> __func__ macro. Replace it.
> 
> Report from checkpatch.pl on the file:
> 
> WARNING: Prefer using '"%s...", __func__' to using 'ov2722_remove', this 
> function's name, in a string
> + dev_dbg(>dev, "ov2722_remove...\n");
> 
> Signed-off-by: Filip Kolev 
> ---
>  drivers/staging/media/atomisp/i2c/atomisp-ov2722.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/media/atomisp/i2c/atomisp-ov2722.c 
> b/drivers/staging/media/atomisp/i2c/atomisp-ov2722.c
> index eecefcd734d0e..21d6bc62d452a 100644
> --- a/drivers/staging/media/atomisp/i2c/atomisp-ov2722.c
> +++ b/drivers/staging/media/atomisp/i2c/atomisp-ov2722.c
> @@ -1175,7 +1175,7 @@ static int ov2722_remove(struct i2c_client *client)
>   struct v4l2_subdev *sd = i2c_get_clientdata(client);
>   struct ov2722_device *dev = to_ov2722_sensor(sd);
>  
> - dev_dbg(>dev, "ov2722_remove...\n");
> + dev_dbg(>dev, "%s...\n", __func__);

dev_dbg() provides the function name already, and this is just a "trace"
call, and ftrace should be used instead, so the whole line should be
removed entirely.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 2/2] greybus: vibrator: rip out custom sysfs api

2021-01-05 Thread Greg Kroah-Hartman
No need for a custom sysfs api for the greybus vibrator driver now that
it is hooked up to the kernel's input layer, so rip it out.

Cc: Johan Hovold 
Cc: Alex Elder 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/staging/greybus/vibrator.c | 125 ++---
 1 file changed, 5 insertions(+), 120 deletions(-)

diff --git a/drivers/staging/greybus/vibrator.c 
b/drivers/staging/greybus/vibrator.c
index 94110cadb5bd..d93c8f7e1bd6 100644
--- a/drivers/staging/greybus/vibrator.c
+++ b/drivers/staging/greybus/vibrator.c
@@ -19,9 +19,6 @@
 struct gb_vibrator_device {
struct gb_connection*connection;
struct input_dev*input;
-   struct device   *dev;
-   int minor;  /* vibrator minor number */
-   struct delayed_work delayed_work;
boolrunning;
boolon;
struct work_struct  play_work;
@@ -45,7 +42,7 @@ static int turn_off(struct gb_vibrator_device *vib)
return ret;
 }
 
-static int turn_on(struct gb_vibrator_device *vib, u16 timeout_ms)
+static int turn_on(struct gb_vibrator_device *vib)
 {
struct gb_bundle *bundle = vib->connection->bundle;
int ret;
@@ -54,10 +51,6 @@ static int turn_on(struct gb_vibrator_device *vib, u16 
timeout_ms)
if (ret)
return ret;
 
-   /* Vibrator was switched ON earlier */
-   if (cancel_delayed_work_sync(>delayed_work))
-   turn_off(vib);
-
ret = gb_operation_sync(vib->connection, GB_VIBRATOR_TYPE_ON,
NULL, 0, NULL, 0);
if (ret) {
@@ -66,8 +59,6 @@ static int turn_on(struct gb_vibrator_device *vib, u16 
timeout_ms)
}
 
vib->on = true;
-   schedule_delayed_work(>delayed_work, msecs_to_jiffies(timeout_ms));
-
return 0;
 }
 
@@ -79,7 +70,7 @@ static void gb_vibrator_play_work(struct work_struct *work)
if (vib->running)
turn_off(vib);
else
-   turn_on(vib, 100);
+   turn_on(vib);
 }
 
 static int gb_vibrator_play_effect(struct input_dev *input, void *data,
@@ -101,68 +92,17 @@ static void gb_vibrator_close(struct input_dev *input)
 {
struct gb_vibrator_device *vib = input_get_drvdata(input);
 
-   cancel_delayed_work_sync(>delayed_work);
cancel_work_sync(>play_work);
turn_off(vib);
vib->running = false;
 }
 
-static void gb_vibrator_worker(struct work_struct *work)
-{
-   struct delayed_work *delayed_work = to_delayed_work(work);
-   struct gb_vibrator_device *vib =
-   container_of(delayed_work,
-struct gb_vibrator_device,
-delayed_work);
-
-   turn_off(vib);
-}
-
-static ssize_t timeout_store(struct device *dev, struct device_attribute *attr,
-const char *buf, size_t count)
-{
-   struct gb_vibrator_device *vib = dev_get_drvdata(dev);
-   unsigned long val;
-   int retval;
-
-   retval = kstrtoul(buf, 10, );
-   if (retval < 0) {
-   dev_err(dev, "could not parse timeout value %d\n", retval);
-   return retval;
-   }
-
-   if (val)
-   retval = turn_on(vib, (u16)val);
-   else
-   retval = turn_off(vib);
-   if (retval)
-   return retval;
-
-   return count;
-}
-static DEVICE_ATTR_WO(timeout);
-
-static struct attribute *vibrator_attrs[] = {
-   _attr_timeout.attr,
-   NULL,
-};
-ATTRIBUTE_GROUPS(vibrator);
-
-static struct class vibrator_class = {
-   .name   = "vibrator",
-   .owner  = THIS_MODULE,
-   .dev_groups = vibrator_groups,
-};
-
-static DEFINE_IDA(minors);
-
 static int gb_vibrator_probe(struct gb_bundle *bundle,
 const struct greybus_bundle_id *id)
 {
struct greybus_descriptor_cport *cport_desc;
struct gb_connection *connection;
struct gb_vibrator_device *vib;
-   struct device *dev;
int retval;
 
if (bundle->num_cports != 1)
@@ -192,26 +132,6 @@ static int gb_vibrator_probe(struct gb_bundle *bundle,
if (retval)
goto err_connection_destroy;
 
-   /*
-* For now we create a device in sysfs for the vibrator, but odds are
-* there is a "real" device somewhere in the kernel for this, but I
-* can't find it at the moment...
-*/
-   vib->minor = ida_simple_get(, 0, 0, GFP_KERNEL);
-   if (vib->minor < 0) {
-   retval = vib->minor;
-   goto err_connection_disable;
-   }
-   dev = device_create(_class, >dev,
-   MKDEV(0, 0), vib, "vibrator%d", vib->minor);
-   if (IS_ERR(dev)) {
-   retval = -EINVAL;
-   goto err_ida_remove;
-

[PATCH 1/2] staging: greybus: vibrator: use proper API for vibrator devices

2021-01-05 Thread Greg Kroah-Hartman
The correct user/kernel api for vibrator devices is the Input rumble
api, not a random sysfs file like the greybus vibrator driver currently
uses.

Add support for the correct input api to the vibrator driver so that it
hooks up to the kernel and userspace correctly.

Cc: Johan Hovold 
Cc: Alex Elder 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/staging/greybus/vibrator.c | 59 ++
 1 file changed, 59 insertions(+)

diff --git a/drivers/staging/greybus/vibrator.c 
b/drivers/staging/greybus/vibrator.c
index 0e2b188e5ca3..94110cadb5bd 100644
--- a/drivers/staging/greybus/vibrator.c
+++ b/drivers/staging/greybus/vibrator.c
@@ -13,13 +13,18 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 struct gb_vibrator_device {
struct gb_connection*connection;
+   struct input_dev*input;
struct device   *dev;
int minor;  /* vibrator minor number */
struct delayed_work delayed_work;
+   boolrunning;
+   boolon;
+   struct work_struct  play_work;
 };
 
 /* Greybus Vibrator operation types */
@@ -36,6 +41,7 @@ static int turn_off(struct gb_vibrator_device *vib)
 
gb_pm_runtime_put_autosuspend(bundle);
 
+   vib->on = false;
return ret;
 }
 
@@ -59,11 +65,48 @@ static int turn_on(struct gb_vibrator_device *vib, u16 
timeout_ms)
return ret;
}
 
+   vib->on = true;
schedule_delayed_work(>delayed_work, msecs_to_jiffies(timeout_ms));
 
return 0;
 }
 
+static void gb_vibrator_play_work(struct work_struct *work)
+{
+   struct gb_vibrator_device *vib =
+   container_of(work, struct gb_vibrator_device, play_work);
+
+   if (vib->running)
+   turn_off(vib);
+   else
+   turn_on(vib, 100);
+}
+
+static int gb_vibrator_play_effect(struct input_dev *input, void *data,
+  struct ff_effect *effect)
+{
+   struct gb_vibrator_device *vib = input_get_drvdata(input);
+   int level;
+
+   level = effect->u.rumble.strong_magnitude;
+   if (!level)
+   level = effect->u.rumble.weak_magnitude;
+
+   vib->running = level;
+   schedule_work(>play_work);
+   return 0;
+}
+
+static void gb_vibrator_close(struct input_dev *input)
+{
+   struct gb_vibrator_device *vib = input_get_drvdata(input);
+
+   cancel_delayed_work_sync(>delayed_work);
+   cancel_work_sync(>play_work);
+   turn_off(vib);
+   vib->running = false;
+}
+
 static void gb_vibrator_worker(struct work_struct *work)
 {
struct delayed_work *delayed_work = to_delayed_work(work);
@@ -169,10 +212,26 @@ static int gb_vibrator_probe(struct gb_bundle *bundle,
 
INIT_DELAYED_WORK(>delayed_work, gb_vibrator_worker);
 
+   INIT_WORK(>play_work, gb_vibrator_play_work);
+   vib->input->name = "greybus-vibrator";
+   vib->input->close = gb_vibrator_close;
+   vib->input->dev.parent = >dev;
+   vib->input->id.bustype = BUS_HOST;
+
+   input_set_drvdata(vib->input, vib);
+   input_set_capability(vib->input, EV_FF, FF_RUMBLE);
+
+   retval = input_ff_create_memless(vib->input, NULL,
+gb_vibrator_play_effect);
+   if (retval)
+   goto err_device_remove;
+
gb_pm_runtime_put_autosuspend(bundle);
 
return 0;
 
+err_device_remove:
+   device_unregister(vib->dev);
 err_ida_remove:
ida_simple_remove(, vib->minor);
 err_connection_disable:
-- 
2.30.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: rtl8192u: Add null check in rtl8192_usb_initendpoints

2020-12-28 Thread Greg Kroah-Hartman
On Sat, Dec 26, 2020 at 04:02:56PM +0800, Dinghao Liu wrote:
> There is an allocation for priv->rx_urb[16] has no null check,
> which may lead to a null pointer dereference.
> 
> Signed-off-by: Dinghao Liu 
> ---
>  drivers/staging/rtl8192u/r8192U_core.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
> b/drivers/staging/rtl8192u/r8192U_core.c
> index 93676af98629..9fc4adc83d77 100644
> --- a/drivers/staging/rtl8192u/r8192U_core.c
> +++ b/drivers/staging/rtl8192u/r8192U_core.c
> @@ -1608,6 +1608,8 @@ static short rtl8192_usb_initendpoints(struct 
> net_device *dev)
>   void *oldaddr, *newaddr;
>  
>   priv->rx_urb[16] = usb_alloc_urb(0, GFP_KERNEL);
> + if (!priv->rx_urb[16])
> + return -ENOMEM;
>   priv->oldaddr = kmalloc(16, GFP_KERNEL);
>   if (!priv->oldaddr)
>   return -ENOMEM;

There is a bug here, where the memory is not freed from the alloc urb
call, right?

Anyway, something to fix up in a leter patch, thanks.

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: android: ashmem: Declared file operation with const keyword

2020-12-27 Thread Greg Kroah-Hartman
On Mon, Dec 28, 2020 at 12:13:00AM -0500, jovin555 wrote:
> Warning found by checkpatch.pl script.
> 
> Signed-off-by: jovin555 
> ---
>  drivers/staging/android/ashmem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/android/ashmem.c 
> b/drivers/staging/android/ashmem.c
> index c05a214191da..f9cfa15b785f 100644
> --- a/drivers/staging/android/ashmem.c
> +++ b/drivers/staging/android/ashmem.c
> @@ -367,7 +367,7 @@ ashmem_vmfile_get_unmapped_area(struct file *file, 
> unsigned long addr,
>  
>  static int ashmem_mmap(struct file *file, struct vm_area_struct *vma)
>  {
> - static struct file_operations vmfile_fops;
> + static const struct file_operations vmfile_fops;
>   struct ashmem_area *asma = file->private_data;
>   int ret = 0;
>  

Did you build your modified kernel with this change in it?

Always do so...

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: android: ashmem: Fixed warning for structure declaration

2020-12-27 Thread Greg Kroah-Hartman
On Sun, Dec 27, 2020 at 04:56:45PM +0530, Angshuman Sengupta wrote:
> Warning found by checkpatch.pl script.
> 
> Signed-off-by: Angshuman Sengupta 
> ---
>  drivers/staging/android/ashmem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/android/ashmem.c 
> b/drivers/staging/android/ashmem.c
> index 4789d36ddfd3..2cb665e0228c 100644
> --- a/drivers/staging/android/ashmem.c
> +++ b/drivers/staging/android/ashmem.c
> @@ -376,7 +376,7 @@ ashmem_vmfile_get_unmapped_area(struct file *file, 
> unsigned long addr,
>  
>  static int ashmem_mmap(struct file *file, struct vm_area_struct *vma)
>  {
> - static struct file_operations vmfile_fops;
> + static const struct file_operations vmfile_fops;
>   struct ashmem_area *asma = file->private_data;
>   int ret = 0;
>  

Did you test build this change?  Why not?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v3 09/24] wfx: add hwio.c/hwio.h

2020-12-23 Thread Greg Kroah-Hartman
On Wed, Dec 23, 2020 at 09:01:33AM +0100, Jérôme Pouiller wrote:
> On Tuesday 22 December 2020 16:27:01 CET Greg Kroah-Hartman wrote:
> > On Tue, Dec 22, 2020 at 05:10:11PM +0200, Kalle Valo wrote:
> > > Jerome Pouiller  writes:
> > >
> > > > +/*
> > > > + * Internal helpers.
> > > > + *
> > > > + * About CONFIG_VMAP_STACK:
> > > > + * When CONFIG_VMAP_STACK is enabled, it is not possible to run DMA on 
> > > > stack
> > > > + * allocated data. Functions below that work with registers (aka 
> > > > functions
> > > > + * ending with "32") automatically reallocate buffers with kmalloc. 
> > > > However,
> > > > + * functions that work with arbitrary length buffers let's caller to 
> > > > handle
> > > > + * memory location. In doubt, enable CONFIG_DEBUG_SG to detect badly 
> > > > located
> > > > + * buffer.
> > > > + */
> > >
> > > This sounds very hacky to me, I have understood that you should never
> > > use stack with DMA.
> > 
> > You should never do that because some platforms do not support it, so no
> > driver should ever try to do that as they do not know what platform they
> > are running on.
> 
> Just to be curious, why these platforms don't support DMA in a stack
> allocated area?

Hardware is odd :(

> If the memory is contiguous (= not vmalloced), correctly
> aligned and in the first 4GB of physical memory, it should be sufficient,
> shouldn't?

Nope, sorry, this just does not work at all on many platforms.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v3 09/24] wfx: add hwio.c/hwio.h

2020-12-22 Thread Greg Kroah-Hartman
On Tue, Dec 22, 2020 at 05:10:11PM +0200, Kalle Valo wrote:
> Jerome Pouiller  writes:
> 
> > +/*
> > + * Internal helpers.
> > + *
> > + * About CONFIG_VMAP_STACK:
> > + * When CONFIG_VMAP_STACK is enabled, it is not possible to run DMA on 
> > stack
> > + * allocated data. Functions below that work with registers (aka functions
> > + * ending with "32") automatically reallocate buffers with kmalloc. 
> > However,
> > + * functions that work with arbitrary length buffers let's caller to handle
> > + * memory location. In doubt, enable CONFIG_DEBUG_SG to detect badly 
> > located
> > + * buffer.
> > + */
> 
> This sounds very hacky to me, I have understood that you should never
> use stack with DMA.

You should never do that because some platforms do not support it, so no
driver should ever try to do that as they do not know what platform they
are running on.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] Staging: silabs si4455 serial driver

2020-12-10 Thread 'Greg Kroah-Hartman'
On Thu, Dec 10, 2020 at 12:20:10PM +, József Horváth wrote:
> I send this again, because my original mail content was corrupted.
> 
> This is a serial port driver for
> Silicon Labs Si4455 Sub-GHz transciver.
> 
> Signed-off-by: József Horváth 
> ---
>  .../bindings/staging/serial/silabs,si4455.txt |   39 +
>  drivers/staging/Kconfig   |2 +
>  drivers/staging/Makefile  |1 +
>  drivers/staging/si4455/Kconfig|8 +
>  drivers/staging/si4455/Makefile   |2 +
>  drivers/staging/si4455/TODO   |3 +
>  drivers/staging/si4455/si4455.c   | 1465 +

I said I wasn't going to take this into drivers/staging/ so why is this
still here?

confused,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v1 1/2] Staging: silabs si4455 serial driver: fix directory structure and coding style

2020-12-10 Thread 'Greg Kroah-Hartman'
On Thu, Dec 10, 2020 at 12:20:59PM +, József Horváth wrote:
> fix: coding style
> fix: error checking
> remove: doc silabs,si4455.txt

What does all of this mean?

Please read the documentation for how to write an effective changelog
text, and where to put the "changes from the first version" text at.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] Staging: silabs si4455 serial driver

2020-12-09 Thread 'Greg Kroah-Hartman'
On Wed, Dec 09, 2020 at 12:09:58PM +0100, Info wrote:
> This is a serial port driver for
> Silicon Labs Si4455 Sub-GHz transciver.
> 
> Signed-off-by: József Horváth 

Note, your From: line does not match this line, so I can't take this.

But:

> ---
>  .../bindings/staging/serial/silabs,si4455.txt |   39 +

staging drivers need to be self-contained, so this should be here.  It
needs to be reviewed by the DT maintainers when moving out of staging.

> index ..aee5c7613b31
> --- /dev/null
> +++ b/drivers/staging/si4455/TODO
> @@ -0,0 +1,3 @@
> +TODO:
> +- add variable packet length support
> +- add firmware patching support in case of Si4455-C2A

Why are these a requirement to get it out of staging?  Why go into
staging at all?  Why not go into the 'real' part of the kernel directly?
What is keeping that from happening today?

These look like new features that you can add later, and shouldn't be a
requirement for acceptance into the normal part of the kernel for this
driver.  Why have you not tried doing that first?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: rtl8723bs: Add 024c:0627 to the list of SDIO device-ids

2020-11-06 Thread Greg Kroah-Hartman
On Thu, Oct 29, 2020 at 09:52:16AM -0400, Brian O'Keefe wrote:
> Add 024c:0627 to the list of SDIO device-ids, based on hardware found in
> the wild. This hardware exists on at least some Acer SW1-011 tablets.
> 
> Signed-off-by: Brian O'Keefe 
> Reviewed-by: Hans de Goede 
> ---
>  drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
> b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
> index 5b1392deb0a7..7256d55fcc1b 100644
> --- a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
> +++ b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
> @@ -21,6 +21,7 @@ static const struct sdio_device_id sdio_ids[] =
> { SDIO_DEVICE(0x024c, 0x0525), },
> { SDIO_DEVICE(0x024c, 0x0623), },
> { SDIO_DEVICE(0x024c, 0x0626), },
> +   { SDIO_DEVICE(0x024c, 0x0627), },
> { SDIO_DEVICE(0x024c, 0xb723), },
> { /* end: all zeroes */ },
>  };
> --
> 2.25.1

All of the tabs are gone in your email and it's only spaces, making this
patch impossible to apply :(

Can you fix up your email client and resend this and keep Hans's
Reviewed-by on it?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: comedi: cb_pcidas: reinstate delay removed from trimpot setting

2020-11-06 Thread Greg Kroah-Hartman
On Wed, Nov 04, 2020 at 10:49:18AM +, Ian Abbott wrote:
> On 02/11/2020 11:16, Ian Abbott wrote:
> > On 02/11/2020 10:25, Ian Abbott wrote:
> > > On 29/10/2020 14:18, Ian Abbott wrote:
> > > > Commit eddd2a4c675c ("staging: comedi: cb_pcidas: refactor
> > > > write_calibration_bitstream()") inadvertently removed one of the
> > > > `udelay(1)` calls when writing to the calibration register in
> > > > `cb_pcidas_calib_write()`.  Reinstate the delay.  It may seem strange
> > > > that the delay is placed before the register write, but this function is
> > > > called in a loop so the extra delay can make a difference.
> > > > 
> > > > This _might_ solve reported issues reading analog inputs on a
> > > > PCIe-DAS1602/16 card where the analog input values "were scaled in a
> > > > strange way that didn't make sense".  On the same hardware running a
> > > > system with a 3.13 kernel, and then a system with a 4.4 kernel, but with
> > > > the same application software, the system with the 3.13 kernel was fine,
> > > > but the one with the 4.4 kernel exhibited the problem.  Of the 90
> > > > changes to the driver between those kernel versions, this change looked
> > > > like the most likely culprit.
> > > 
> > > Actually, I've realized that this patch will have no effect on the
> > > PCIe-DAS1602/16 card because it uses a different driver -
> > > cb_pcimdas, not cb_pcidas.
> > 
> > But that's also confusing because PCIe-DAS1602/16 was not supported
> > until the 3.19 kernel!  I know the reported has both PCI-DAS1602/16 and
> > PCIe-DAS1602/16 cards (supported by cb_pcidas and cb_pcimdas
> > respectively), so there could have been some mix-up in the reporting.
> 
> Mystery solved.  The reporter had a mixture of PCIe-DAS1602/16 and
> PCIM-DAS1602/16 cards (not PCI-DAS1602/16).  Both of those are supported by
> the "cb_pcimdas" driver (not "cb_pcidas"), although the PCIe card was not
> supported until the 3.19 kernel (by commit 4e3d14af1286).  Testing with the
> 3.13 kernel was done with the PCIM card.
> 
> The "strange scaling" was due to a change in the ranges reported for the
> analog input subdevice in the 4.1 kernel (by commit c7549d770a27). Before
> then, it just reported a single dummy range [0, 100] with no units
> (converted to [0.0, 1.0] with no units by comedilib).  Afterwards, it
> reported four different voltage ranges (either unipolar or bipolar,
> depending in a status bit tied to a physical switch).  The reporter's
> application code was using the reported range to scale the raw values to a
> voltage (using comedilib functions), but because the reported range was
> bogus, the application code was performing additional scaling (outside of
> comedilib).  The application code can be changed to check whether the device
> is reporting a proper voltage range or the old, bogus range, and behave
> accordingly.
> 
> > > Greg, you might as well drop this patch if you haven't already
> > > applied it, since it was only a hunch that it fixed a problem.
> 
> That's still the case, although it won't do any harm if applied (apart from
> the incorrect patch description).

I'll leave it dropped :)

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [RFC] wimax: move out to staging

2020-10-27 Thread Greg Kroah-Hartman
On Tue, Oct 27, 2020 at 10:20:13PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> There are no known users of this driver as of October 2020, and it will
> be removed unless someone turns out to still need it in future releases.
> 
> According to https://en.wikipedia.org/wiki/List_of_WiMAX_networks, there
> have been many public wimax networks, but it appears that these entries
> are all stale, after everyone has migrated to LTE or discontinued their
> service altogether.
> 
> NetworkManager appears to have dropped userspace support in 2015
> https://bugzilla.gnome.org/show_bug.cgi?id=747846, the
> www.linuxwimax.org
> site had already shut down earlier.
> 
> WiMax is apparently still being deployed on airport campus networks
> ("AeroMACS"), but in a frequency band that was not supported by the old
> Intel 2400m (used in Sandy Bridge laptops and earlier), which is the
> only driver using the kernel's wimax stack.
> 
> Move all files into drivers/staging/wimax, including the uapi header
> files and documentation, to make it easier to remove it when it gets
> to that. Only minimal changes are made to the source files, in order
> to make it possible to port patches across the move.
> 
> Also remove the MAINTAINERS entry that refers to a broken mailing
> list and website.
> 
> Suggested-by: Inaky Perez-Gonzalez 
> Signed-off-by: Arnd Bergmann 

Is this ok for me to take through the staging tree?  If so, I need an
ack from the networking maintainers.

If not, feel free to send it through the networking tree and add:

Acked-by: Greg Kroah-Hartman 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: wfx: avoid uninitialized variable use

2020-10-27 Thread Greg Kroah-Hartman
On Mon, Oct 26, 2020 at 05:11:11PM +0100, Jérôme Pouiller wrote:
> On Monday 26 October 2020 17:02:22 CET Arnd Bergmann wrote:
> > 
> > From: Arnd Bergmann 
> > 
> > Move the added check of the 'band' variable after the
> > initialization. Pointed out by clang with
> > 
> > drivers/staging/wfx/data_tx.c:34:19: warning: variable 'band' is 
> > uninitialized when used here [-Wuninitialized]
> > if (rate->idx >= band->n_bitrates) {
> 
> Hello Arnd,
> 
> This patch has already been submitted[1]. I think it is going to be
> applied to staging very soon.
> 
> Sorry for the disturbing.
> 
> [1] 
> https://lore.kernel.org/driverdev-devel/20201019160604.1609180-1-jerome.pouil...@silabs.com/

Sorry for the delay, had to wait until -rc1 was out.

Now queued up in my tree.

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v2 1/2] staging: kpc2000: kpc_dma: rearrange lines exceeding 100 columns

2020-10-25 Thread Greg Kroah-Hartman
On Mon, Oct 26, 2020 at 09:34:53AM +0530, Deepak R Varma wrote:
> On Wed, Oct 21, 2020 at 01:01:07PM +0530, Deepak R Varma wrote:
> 
> Hello,
> Requesting a review / ack of this patch.

As I said in my previous email, to the outreachy list, if I have not
applied something, it needs to be resent, if you still think it is
needed.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v2 net] staging: octeon: Drop on uncorrectable alignment or FCS error

2020-10-25 Thread Greg Kroah-Hartman
On Fri, Oct 16, 2020 at 12:18:58PM +0200, Alexander A Sverdlin wrote:
> From: Alexander Sverdlin 
> 
> Currently in case of alignment or FCS error if the packet cannot be
> corrected it's still not dropped. Report the error properly and drop the
> packet while making the code around a little bit more readable.
> 
> Signed-off-by: Alexander Sverdlin 
> Fixes: 80ff0fd3ab ("Staging: Add octeon-ethernet driver files.")
> 
> Change-Id: Ie1fadcc57cb5e221cf3e83c169b53a5533b8edff

Please stop using gerrit for patches destined for upstream development
:(
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 2/2] staging: kpc2000: kpc_dma: rename show function per convention

2020-10-21 Thread Greg Kroah-Hartman
On Wed, Oct 21, 2020 at 10:40:21AM +0530, Deepak R Varma wrote:
> Rename show_engine_regs to engine_regs_show as per the convention
> followed. Issue reported by checkpatch script.
> 
> Signed-off-by: Deepak R Varma 
> ---
>  drivers/staging/kpc2000/kpc_dma/kpc_dma_driver.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/kpc2000/kpc_dma/kpc_dma_driver.c 
> b/drivers/staging/kpc2000/kpc_dma/kpc_dma_driver.c
> index 7698e5ef2a7c..b6d1afbd452d 100644
> --- a/drivers/staging/kpc2000/kpc_dma/kpc_dma_driver.c
> +++ b/drivers/staging/kpc2000/kpc_dma/kpc_dma_driver.c
> @@ -50,7 +50,7 @@ static void kpc_dma_del_device(struct kpc_dma_device *ldev)
>  }
>  
>  /**  SysFS Attributes **/
> -static ssize_t  show_engine_regs(struct device *dev, struct device_attribute 
> *attr, char *buf)
> +static ssize_t  engine_regs_show(struct device *dev, struct device_attribute 
> *attr, char *buf)
>  {
>   struct kpc_dma_device *ldev;
>   struct platform_device *pldev = to_platform_device(dev);
> @@ -80,7 +80,7 @@ static ssize_t  show_engine_regs(struct device *dev, struct 
> device_attribute *at
>   ldev->desc_completed
>   );
>  }
> -static DEVICE_ATTR(engine_regs, 0444, show_engine_regs, NULL);
> +static DEVICE_ATTR(engine_regs, 0444, engine_regs_show, NULL);

Shouldn't this just be using a DEVICE_ATTR_RO() macro instead?  Make
that change and the name will be fixed up at the same time.

And did checkpatch really complain about this?  What was the actual
message it produced?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v2 net] staging: octeon: Drop on uncorrectable alignment or FCS error

2020-10-16 Thread Greg Kroah-Hartman
On Fri, Oct 16, 2020 at 12:18:58PM +0200, Alexander A Sverdlin wrote:
> From: Alexander Sverdlin 
> 
> Currently in case of alignment or FCS error if the packet cannot be
> corrected it's still not dropped. Report the error properly and drop the
> packet while making the code around a little bit more readable.
> 
> Signed-off-by: Alexander Sverdlin 
> Fixes: 80ff0fd3ab ("Staging: Add octeon-ethernet driver files.")
> 
> Change-Id: Ie1fadcc57cb5e221cf3e83c169b53a5533b8edff

Why is the change-id still here???
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v2 net] staging: octeon: Drop on uncorrectable alignment or FCS error

2020-10-16 Thread Greg Kroah-Hartman
On Fri, Oct 16, 2020 at 12:18:58PM +0200, Alexander A Sverdlin wrote:
> From: Alexander Sverdlin 
> 
> Currently in case of alignment or FCS error if the packet cannot be
> corrected it's still not dropped. Report the error properly and drop the
> packet while making the code around a little bit more readable.
> 
> Signed-off-by: Alexander Sverdlin 
> Fixes: 80ff0fd3ab ("Staging: Add octeon-ethernet driver files.")
> 
> Change-Id: Ie1fadcc57cb5e221cf3e83c169b53a5533b8edff

You didn't run checkpatch :(

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: ion: remove from the tree

2020-10-16 Thread Greg Kroah-Hartman
On Thu, Aug 27, 2020 at 09:31:27AM -0400, Laura Abbott wrote:
> On 8/27/20 8:36 AM, Greg Kroah-Hartman wrote:
> > The ION android code has long been marked to be removed, now that we
> > dma-buf support merged into the real part of the kernel.
> > 
> > It was thought that we could wait to remove the ion kernel at a later
> > time, but as the out-of-tree Android fork of the ion code has diverged
> > quite a bit, and any Android device using the ion interface uses that
> > forked version and not this in-tree version, the in-tree copy of the
> > code is abandonded and not used by anyone.
> > 
> > Combine this abandoned codebase with the need to make changes to it in
> > order to keep the kernel building properly, which then causes merge
> > issues when merging those changes into the out-of-tree Android code, and
> > you end up with two different groups of people (the in-kernel-tree
> > developers, and the Android kernel developers) who are both annoyed at
> > the current situation.  Because of this problem, just drop the in-kernel
> > copy of the ion code now, as it's not used, and is only causing problems
> > for everyone involved.
> > 
> > Cc: "Arve Hjønnevåg" 
> > Cc: "Christian König" 
> > Cc: Christian Brauner 
> > Cc: Christoph Hellwig 
> > Cc: Hridya Valsaraju 
> > Cc: Joel Fernandes 
> > Cc: John Stultz 
> > Cc: Laura Abbott 
> > Cc: Martijn Coenen 
> > Cc: Shuah Khan 
> > Cc: Sumit Semwal 
> > Cc: Suren Baghdasaryan 
> > Cc: Todd Kjos 
> > Cc: de...@driverdev.osuosl.org
> > Cc: dri-de...@lists.freedesktop.org
> > Cc: linaro-mm-...@lists.linaro.org
> > Signed-off-by: Greg Kroah-Hartman 
> 
> We discussed this at the Android MC on Monday and the plan was to
> remove it after the next LTS release.

As 5.10 will be the next LTS release, I have now merged it to my
"testing" branch to go into 5.11-rc1.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


  1   2   3   4   5   6   7   8   9   10   >