Re: [GIT PULL] Staging/IIO driver updates for 5.13-rc1

On Mon, Apr 26, 2021 at 8:11 AM Greg KH wrote: > > Yeah, merge issues with other trees are hard to resolve in the single > tree here, not much I can just yet, have to wait for them to hit Linus's > tree. It's generally a good idea to mention these things if you know about them, just in case the

Re: [GIT PULL] Staging/IIO driver fixes for 5.11-rc5

On Sun, Jan 24, 2021 at 4:58 AM Greg KH wrote: > > David Lechner (1): > counter:ti-eqep: remove floor I'm not sure why that ti-eqep counter driver seems to be in your "iio/staging" pile rather than "char/misc", but whatever.. Linus

Re: [GIT PULL] Staging/IIO driver changes for 5.11-rc1

On Tue, Dec 15, 2020 at 3:48 AM Greg KH wrote: > > Linus, your call. This showed up in my build testing and I fixed it in the merge. No problem, but thanks to Stephen for tracking these things. Linus ___ devel mailing list

Re: [GIT PULL] Staging/IIO driver update for 5.10-rc1

On Thu, Oct 15, 2020 at 5:26 AM Greg KH wrote: > > Included in here are: > - new IIO drivers [...] > - no new drivers added or removed So which one is it? New drivers, or no new drivers, that is the question: Whether 'tis nobler in the mind to suffer.. I do understand what I

Re: [PATCH] vboxsf: move out of staging to fs/

On Tue, Nov 12, 2019 at 2:54 PM Greg Kroah-Hartman wrote: > > Christoph, this is what you mean, right? If so, I'll send this to Linus > later this week, or he can grab it right from this patch :) No. I was unhappy about a staging driver being added in rc7, but I went "whatever, it's Greg's

Re: [PATCH v8 00/24] erofs: promote erofs from staging v8

On Thu, Aug 15, 2019 at 2:06 AM Greg Kroah-Hartman wrote: > > I know everyone is busy, but given the length this has been in staging, > and the constant good progress toward cleaning it all up that has been > happening, I want to get this moved out of staging soon. Since it doesn't touch

Re: [PATCH v8 07/24] erofs: add directory operations

On Wed, Aug 14, 2019 at 9:42 PM Gao Xiang wrote: > > + > +static const unsigned char erofs_filetype_table[EROFS_FT_MAX] = { > + [EROFS_FT_UNKNOWN] = DT_UNKNOWN, > + [EROFS_FT_REG_FILE] = DT_REG, > + [EROFS_FT_DIR] = DT_DIR, > + [EROFS_FT_CHRDEV] =

Re: [GIT PULL] Staging/IIO driver patches for 5.2-rc1

On Tue, May 7, 2019 at 10:59 AM Greg KH wrote: > > All of these have been in linux-next for a while with no reported > issues, other than an odd gcc warning for one of the new drivers that > should be fixed up soon. Ok, that's truly a funky warning. But since I don't deal well with warnings,

Re: [GIT PULL] Staging/IIO driver patches for 4.20-rc1

On Mon, Oct 29, 2018 at 7:44 AM Greg KH wrote: > > Here is the big staging and IIO driver pull request for 4.20-rc1. Pulled, Linus ___ devel mailing list de...@linuxdriverproject.org

Re: [PATCH] vme: remove unneeded kfree

On Thu, Sep 6, 2018 at 1:51 AM Ding Xiang wrote: > > put_device will call vme_dev_release to free vdev, kfree is > unnecessary here. That does seem to be the case. I think "unnecessary" is overly kind, it does seem to be a double free. Looks like the issue was introduced back in 2013 by commit

Re: [GIT PULL] Staging/IIO driver patches for 4.19-rc1

On Sat, Aug 18, 2018 at 8:57 AM Greg KH wrote: > > Note, you will have a merge problem with a device tree IIO file and the > MAINTAINERS file, both resolutions are easy, just take all changed. Heh, no. In neither case should I take all changes: the IIO was "delete both sides"), and in the

Re: [PATCH] media: staging: omap4iss: Include asm/cacheflush.h after generic includes

On Tue, Jul 24, 2018 at 11:39 AM Mauro Carvalho Chehab wrote: > > Works for me. Do you intend to apply it directly? Yes, I took it and it should be pushed out. > Yeah, some time ago mailing lists got flooded with some janitorial's > patchset adding includes (some claiming to be needed on some

Re: [PATCH] media: staging: omap4iss: Include asm/cacheflush.h after generic includes

On Mon, Jul 23, 2018 at 8:41 PM Mauro Carvalho Chehab wrote: > > While I won't be against merging it, IMHO a better fix would be to > add the includes asm/cacheflush.h needs inside it, e. g. something > like adding: No. The includes really should come after . This is a media driver bug, plain

Re: [cfs_trace_lock_tcd] BUG: KASAN: null-ptr-deref in cfs_trace_lock_tcd+0x25/0xeb

Ugh, that lustre code is disgusting. I thought we were getting rid of it. Anyway, I started looking at why the stack trace is such an incredible mess, with lots of stale entries. The reason (well, _one_ reason) seems to be "ksocknal_startup". It has a 500-byte stack frame for some

Re: [GIT PULL] Staging/IIO driver changes for 4.17-rc1

On Wed, Apr 4, 2018 at 3:32 AM, Greg KH wrote: > > It is a lot, over 500 changes, but not huge by previous kernel release > standards. We deleted more lines than we added again (27k added vs. 91k > remvoed), thanks to finally being able to delete the IRDA drivers and

Re: [PATCH] staging: vchiq_arm: Clear VLA warning

On Fri, Mar 9, 2018 at 10:35 AM, Kees Cook wrote: > > I think you mean ARRAY_SIZE(service_data) ? In that case, yeah, it > seems like a raw "64" for the array size can be used instead. I think 64 is much too big anyway. That's 768 bytes of stack data that is used to check

Re: [GIT PULL] Staging driver fixes for 4.15-rc4

On Fri, Dec 15, 2017 at 11:00 AM, Greg KH wrote: > > While there are 4 patches in here, there's really only 2, as one ion > patch got reverted due to build errors reported by 0-day. Since the revert was for the previous commit and the two were the top two commits, I

Re: [lustre-devel] [PATCH 08/28] staging: lustre: restore initialization of return code

On Mon, Oct 17, 2016 at 3:29 PM, Arnd Bergmann wrote: > > Sorry, I pasted the wrong error message when writing the changelog. Not just the warning, the summary above it talks about the wrong function too. And the commit it references doesn't actually exist either. So apparently

Re: [GIT PULL] Staging/IIO driver patches for 4.9-rc1

On Wed, Oct 5, 2016 at 1:17 PM, Greg KH wrote: > > Should I respin the merge request with the above information in it? This is sufficient - I just need to know (and want to document) the reasons for the merges I do. In fact, I'd love it if your pull requests in

Re: [GIT PULL] Staging/IIO driver patches for 4.9-rc1

On Wed, Oct 5, 2016 at 12:22 AM, Greg KH wrote: > > Here is the big staging and IIO driver pull request for 4.9-rc1. > > There are a lot of patches in here, the majority due to the > drivers/staging/greybus/ subsystem being merged in with full development > history

Re: [PATCH net-next] netvsc: Use the new in-place consumption APIs in the rx path

Srinivasan, these are all sent through linuxonhyperv.com, and fail DMARC because they have a microsoft.com address but no valid DKIM. Please fix your email setup. You need to go through the real microsoft smtp servers if you use a microsoft.com address. Or you need to get linuxonhyperv.com

Re: [GIT PULL] Staging driver patches for 4.6-rc1

On Thu, Mar 17, 2016 at 8:25 PM, Greg KH wrote: > Ok, the diffstat below seems "odd" in that I had done a merge with my > char-misc tree to resolve some merge issues a while ago, and that tree > is now in your tree, so the diffstat shouldn't be showing it (I updated >

Re: [PATCH] staging/ion: Add support to get ion handle from dma buf

On Wed, Jan 6, 2016 at 1:06 AM, Dan Carpenter wrote: > It's not really necessary to CC linux-kernel. No one reads it. > I only send patches there when there isn't another public mailing > list available. Actually, cc'ing lkml is still often a good idea, because it's a

Re: [PATCH v2] staging: lustre: remove IOC_LIBCFS_PING_TEST ioctl

On Mon, Dec 21, 2015 at 2:06 PM, Greg Kroah-Hartman wrote: > > No one told me it fixed a bug, let me see if it's still even needed... You were definitely cc'd on a couple of the threads.. But it's done now (well, two weeks ago), I applied it as commit d035e336287b

Re: rtl8821ae.

On Mon, Feb 3, 2014 at 6:22 PM, Andrea Merello andrea.mere...@gmail.com wrote: Right now I have merged rtl8187se support in rtl8180 driver. But I must admit that I ever been in doubt about whether to produce a separate driver rather than going on merging. If you've already merged them, and you