Re: [PATCH 0/6] Re-instate octeon staging drivers

2020-03-04 Thread YunQiang Su
Greg KH 于2020年3月4日周三 下午2:39写道： > > On Wed, Mar 04, 2020 at 09:48:46AM +0800, YunQiang Su wrote: > > Greg KH 于2020年2月13日周四 上午5:52写道： > > > > > > On Wed, Feb 05, 2020 at 01:11:10PM +1300, Chris Packham wrote: > > > > This series re-instates the octeon drivers that were recently removed > > > > and

Re: [PATCH 0/6] Re-instate octeon staging drivers

2020-03-04 Thread Greg KH
On Wed, Mar 04, 2020 at 06:25:34PM +0800, YunQiang Su wrote: > Greg KH 于2020年3月4日周三 下午2:39写道： > > > > On Wed, Mar 04, 2020 at 09:48:46AM +0800, YunQiang Su wrote: > > > Greg KH 于2020年2月13日周四 上午5:52写道： > > > > > > > > On Wed, Feb 05, 2020 at 01:11:10PM +1300, Chris Packham wrote: > > > > > This se

Re: [PATCH 2/2] uio: Prefer MSI(X) interrupts in PCI drivers

2020-03-04 Thread Stahl, Manuel
Hi Greg, so somehow this discussion stopped without any instructions how to proceed. I think this kind of driver helps every FPGA developer to interface his design via PCIe to a Linux PC. So if there is any chance to get this code merged, I'm glad to rebase this onto the latest kernel release.

Re: [PATCH 2/2] uio: Prefer MSI(X) interrupts in PCI drivers

2020-03-04 Thread gre...@linuxfoundation.org
On Wed, Mar 04, 2020 at 03:19:55PM +, Stahl, Manuel wrote: > Hi Greg, > > so somehow this discussion stopped without any instructions how to proceed. What is "this discussion"? > I think this kind of driver helps every FPGA developer to interface > his design via PCIe to a Linux PC. > So if

Re: [PATCH v2 2/3] binder: do not initialize locals passed to copy_from_user()

2020-03-04 Thread Kees Cook
On Tue, Mar 03, 2020 at 12:38:32PM +0300, Dan Carpenter wrote: > The real fix is to initialize everything manually, the automated > initialization is a hardenning feature which many people will disable. I cannot disagree more with this sentiment. Linus has specifically said he wants this initializ

[PATCH 1/2] staging: vt6656: Remove vnt_interrupt_buffer in_use flag.

2020-03-04 Thread Malcolm Priestley
mac80211 is the only user of in_use to start it and should not be true when so. So internal toggling of this variable is not relevant. Signed-off-by: Malcolm Priestley --- drivers/staging/vt6656/device.h | 1 - drivers/staging/vt6656/usbpipe.c | 28 +++- 2 files change

[PATCH 2/2] staging: vt6656: struct vnt_rcb remove unused in_use.

2020-03-04 Thread Malcolm Priestley
The variable merely toggles true to false and is unused. Signed-off-by: Malcolm Priestley --- drivers/staging/vt6656/device.h | 1 - drivers/staging/vt6656/main_usb.c | 3 --- drivers/staging/vt6656/usbpipe.c | 16 +++- 3 files changed, 3 insertions(+), 17 deletions(-) diff --g

Re: [PATCH 0/6] Re-instate octeon staging drivers

2020-03-04 Thread Chris Packham
On Wed, 2020-03-04 at 12:50 +0100, Greg KH wrote: > On Wed, Mar 04, 2020 at 06:25:34PM +0800, YunQiang Su wrote: > > Greg KH 于2020年3月4日周三 下午2:39写道： > > > > > > On Wed, Mar 04, 2020 at 09:48:46AM +0800, YunQiang Su wrote: > > > > Greg KH 于2020年2月13日周四 上午5:52写道： > > > > > > > > > > On Wed, Feb 05

[driver-core:driver-core-testing 6/17] drivers/base/core.c:2335:5: sparse: sparse: symbol 'fw_devlink_flags' was not declared. Should it be static?

2020-03-04 Thread kbuild test robot
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git driver-core-testing head: 68464d79015a1bbb41872a9119a07b2cb151a4b9 commit: 8375e74f2bca9802a4ddf431a6d7bd2ab9950f27 [6/17] driver core: Add fw_devlink kernel commandline option reproduce: # apt-get install sp

[RFC PATCH driver-core] driver core: fw_devlink_flags can be static

2020-03-04 Thread kbuild test robot
Fixes: 8375e74f2bca ("driver core: Add fw_devlink kernel commandline option") Signed-off-by: kbuild test robot --- core.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/base/core.c b/drivers/base/core.c index 26acb92aa966c..cd78a001d7198 100644 --- a/drivers/base

[driver-core:driver-core-linus] BUILD SUCCESS 77036165d8bcf7c7b2a2df28a601ec2c52bb172d

2020-03-04 Thread kbuild test robot
onfig pariscgeneric-32bit_defconfig x86_64 randconfig-a001-20200304 x86_64 randconfig-a002-20200304 x86_64 randconfig-a003-20200304 i386 randconfig-a001-20200304 i386 randconfig-a002-20200304

[staging:staging-testing] BUILD SUCCESS 0fc6d4e4ce010eb077c6db9ec1e18d999c69e3c3

2020-03-04 Thread kbuild test robot
-a003-20200304 i386 randconfig-a001-20200304 x86_64 randconfig-a001-20200304 i386 randconfig-a002-20200304 x86_64 randconfig-a003-20200304 x86_64 randconfig-a002-20200304 x86_64 randconfig-a001-20200305 x86_64

[PATCH 2/2] mm/vma: Introduce VM_ACCESS_FLAGS

2020-03-04 Thread Anshuman Khandual
There are many places where all basic VMA access flags (read, write, exec) are initialized or checked against as a group. One such example is during page fault. Existing vma_is_accessible() wrapper already creates the notion of VMA accessibility as a group access permissions. Hence lets just create

[PATCH] staging: speakup: Fix a typo error print for softsynthu device

2020-03-04 Thread Zhenzhong Duan
When softsynthu device fails the register, "/dev/softsynthu" should be printed instead of "/dev/softsynth". Signed-off-by: Zhenzhong Duan Cc: William Hubbs Cc: Chris Brannon Cc: Kirk Reiser Cc: Samuel Thibault Cc: Greg Kroah-Hartman --- drivers/staging/speakup/speakup_soft.c | 2 +- 1 file

Re: [PATCH] staging: speakup: Fix a typo error print for softsynthu device

2020-03-04 Thread Samuel Thibault
Zhenzhong Duan, le jeu. 05 mars 2020 15:21:51 +0800, a ecrit: > When softsynthu device fails the register, "/dev/softsynthu" should be > printed instead of "/dev/softsynth". Reviewed-by: Samuel Thibault Thanks! > Signed-off-by: Zhenzhong Duan > Cc: William Hubbs > Cc: Chris Brannon > Cc: Kir