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
http://driverdev.linuxdriverproject.org/mailman/listi
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 o
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 thi
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
de...@linuxdrive
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
___
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] = DT
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 anything
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 garb
On Fri, Nov 28, 2014 at 3:35 AM, Parth Sane wrote:
> Hi Linus,
> A wifi kernel module has to be added to the linux source tree.
>
>http://www.mediatek.com/en/downloads/mt7610u-usb/
>
> I've made an issue for the raspberry pirepository:
>
>https://github.com/raspberrypi/linux/issues/730
So
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, par
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 just pulled the two actual fix
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 a
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 ar
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 MAINTAI
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
On Wed, Feb 22, 2017 at 6:56 AM, Greg KH wrote:
>
> =?UTF-8?q?Simon=20Sandstr=C3=B6m?= (1):
> staging: vt6656: Add missing identifier names
Wow, your scripts really screwed up that name.
I'm assuming this is quilt not doing proper character set handling..
Because if it's git, we need to g
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
> networking code.
Hmm. The
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 incomprehensib
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 ("staging/lustre: remove IOC_LI
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 great
archiving point.
I k
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
> my master branch), but someho
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 fixe
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 that went back a few years, in o
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 general were a bit more
about what
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 this is against so
On Fri, Jan 31, 2014 at 6:32 AM, Greg KH wrote:
>
> Here's a single staging driver for a wireless chipset that has shown up
> in the SteamBox hardware. It is merged separately from the "main"
> staging pull request to sync up with the wireless api changes that came
> in from the networking tree.
On Mon, Feb 3, 2014 at 12:12 PM, Dan Carpenter wrote:
> On Mon, Feb 03, 2014 at 11:05:42AM -0600, Larry Finger wrote:
>> A combined driver would require very many branches based on chip
>> number and would certainly execute much more slowly.
>
> I seriously doubt there are performance issues with
On Mon, Feb 3, 2014 at 6:22 PM, Andrea Merello 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 think it works, keep
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 stuff deep in some trans
On Mon, Jul 1, 2013 at 10:17 AM, Greg KH wrote:
> The following changes since commit 7d132055814ef17a6c7b69f342244c410a5e000f:
>
> Linux 3.10-rc6 (2013-06-15 11:51:07 -1000)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/
> sta
30 matches
Mail list logo
