On Thu, Dec 20, 2018 at 4:45 AM Mauro Carvalho Chehab
wrote:
>
> Also, it would be good if you merge first the docs-next pull request from
> Jon, as otherwise, you'll see some warnings when building documentation,
> due to an issue at scripts/kernel-doc, whose fix is at documentation tree.
I don'
On Wed, Oct 31, 2018 at 11:05 AM Linus Torvalds
wrote:
>
> But pulled,
I have no idea how I missed this during the actual test compile after
the pull (and yes, I'm sure I did one), but after doing a couple of
more pulls I finally did notice.
After the media pull I get this warnin
On Tue, Oct 30, 2018 at 6:53 AM Mauro Carvalho Chehab
wrote:
>
> For a new media API: the request API
Ugh. I don't know how much being in staging matters - if people start
using it, they start using it.
"Staging" does not mean "regressions don't matter".
But pulled,
Linus
On Mon, Oct 29, 2018 at 1:34 PM Mauro Carvalho Chehab
wrote:
>
> media updates for v4.20-rc1
Pulled,
Linus
On Tue, Feb 6, 2018 at 2:16 PM, Stephen Rothwell wrote:
>> See: https://lkml.org/lkml/2018/1/1/547
>
> Looks like you missed this when doing the merge :-(
Gaah. I noticed the actual conflicts, and then didn't actually notice
that there had been some other __poll_t noise too.
Will apply your
On Fri, Jan 12, 2018 at 4:15 PM, Tony Luck wrote:
>
> Here there isn't any reason for speculation. The core has the
> value of 'x' in a register and the upper bound encoded into the
> "cmp" instruction. Both are right there, no waiting, no speculation.
So this is an argument I haven't seen befor
On Thu, Jan 11, 2018 at 4:46 PM, Dan Williams wrote:
>
> This series incorporates Mark Rutland's latest ARM changes and adds
> the x86 specific implementation of 'ifence_array_ptr'. That ifence
> based approach is provided as an opt-in fallback, but the default
> mitigation, '__array_ptr', uses a
On Tue, Jan 9, 2018 at 9:57 AM, Eric Dumazet wrote:
>
> Your patch considers TASKLET_SOFTIRQ being a candidate for 'immediate
> handling', but TCP Small queues heavily use TASKLET,
> so as far as I am concerned a revert would have the same effect.
Does it actually?
TCP ends up dropping packets o
On Tue, Jan 9, 2018 at 9:42 AM, Mauro Carvalho Chehab
wrote:
>
> On my preliminar tests, writing to a file on an ext4 partition at a
> USB stick loses data up to the point to make it useless (1/4 of the data
> is lost!). However, writing to a class 10 microSD card is doable.
Note that most USB st
On Tue, Jan 9, 2018 at 9:27 AM, Eric Dumazet wrote:
>
> So yes, commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job") has
> shown up multiple times in various 'regressions'
> simply because it could surface the problem more often.
> But even if you revert it, you can still make the faulty
> dr
On Mon, Jan 8, 2018 at 11:15 AM, Alan Stern wrote:
>
> Both dwc2_hsotg and ehci-hcd use the tasklets embedded in the
> giveback_urb_bh member of struct usb_hcd. See usb_hcd_giveback_urb()
> in drivers/usb/core/hcd.c; the calls are
>
> else if (high_prio_bh)
> tasklet_hi_sc
On Mon, Jan 8, 2018 at 9:55 AM, Ingo Molnar wrote:
>
> as I doubt we have enough time to root-case this properly.
Well, it's not like this is a new issue, and we don't have to get it
fixed for 4.15. It's been around since 4.9, it's not a "have to
suddenly fix it this week" issue.
I just think th
On Sat, Jan 6, 2018 at 11:54 AM, Mauro Carvalho Chehab
wrote:
>
> Em Sat, 6 Jan 2018 16:04:16 +0100
> "Josef Griebichler" escreveu:
>>
>> the causing commit has been identified.
>> After reverting commit
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4cd13c21b20
On Fri, Dec 8, 2017 at 7:56 AM, Mauro Carvalho Chehab
wrote:
>
> - The largest amount of fixes in this series is with regards to comments
> that aren't kernel-doc, but start with "/**". A new check added for
> 4.15 makes it to produce a *huge* amount of new warnings (I'm compiling
> here wit
On Wed, Nov 15, 2017 at 4:28 PM, Mauro Carvalho Chehab
wrote:
>
> PS.: This time, there is a merge from staging tree, from the same commit
> you pulled on your tree, in order to solve a conflict at the
> atomisp driver, as reported by Stephen Rothwell.
Please don't do that.
I got confl
On Mon, Oct 16, 2017 at 4:31 PM, Mauro Carvalho Chehab
wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
> media/v4.14-2
No such tag.
Did you forget to push out? The latest tag I see is v4.14-1.
I do see the branch (v4l_for_linus) that contains the commit you
menti
On Fri, Jul 14, 2017 at 2:25 AM, Arnd Bergmann wrote:
> FIFO_MODE is an macro expression with a '<<' operator, which
> gcc points out could be misread as a '<':
Yeah, no, NAK again.
We don't make the code look worse just because gcc is being a f*cking
moron about things.
This warning is clearly
On Fri, Jul 14, 2017 at 12:21 PM, Linus Torvalds
wrote:
>
> NAK. This takes unintentionally insane code and turns it intentionally
> insane. Any non-zero return is considered an error.
>
> The right fix is almost certainly to just return -EINVAL unconditionally.
Btw, this is why
On Fri, Jul 14, 2017 at 2:25 AM, Arnd Bergmann wrote:
> - return capable(CAP_SYS_ADMIN) ? : -EINVAL;
> + return capable(CAP_SYS_ADMIN) ? 1 : -EINVAL;
NAK. This takes unintentionally insane code and turns it intentionally
insane. Any non-zero return is considered an error.
The right f
On Tue, Jul 11, 2017 at 8:17 PM, Linus Torvalds
wrote:
>
> If that's the case, I'd prefer just turning off the format-truncation
> (but not overflow) warning with '-Wno-format-trunction".
Doing
KBUILD_CFLAGS += $(call cc-disable-warning, format-truncation)
in the
On Tue, Jul 11, 2017 at 8:10 PM, Guenter Roeck wrote:
>
> The hwmon warnings are all about supporting no more than 9,999 sensors
> (applesmc) to 999,999,999 sensors (scpi) of a given type.
Yeah, I think that's enough.
> Easy "fix" would be to replace snprintf() with scnprintf(), presumably
> bec
[ Very random list of maintainers and mailing lists, at least
partially by number of warnings generated by gcc-7.1.1 that is then
correlated with the get_maintainers script ]
So I upgraded one of my boxes to F26, which upgraded the compiler to gcc-7.1.1
Which in turn means that my nice clean allm
On Mon, Feb 27, 2017 at 7:41 AM, Ingo Molnar wrote:
>
> BTW., instead of trying to avoid the scenario, wow about moving in the other
> direction: making CONFIG_DEBUG_SHIRQ=y unconditional property in the IRQ core
> code
> starting from v4.12 or so
The problem is that it's generally almost undebu
On Sat, Feb 25, 2017 at 1:07 AM, Ingo Molnar wrote:
>
> So, should we revert the hw-retrigger change:
>
> a9b4f08770b4 x86/ioapic: Restore IO-APIC irq_chip retrigger callback
>
> ... until we managed to fix CONFIG_DEBUG_SHIRQ=y? If you'd like to revert it
> upstream straight away:
>
> Acked-by:
line cleaned up.
Linus
On Fri, Feb 24, 2017 at 11:15 AM, Linus Torvalds
wrote:
> Added more relevant people. I've debugged the immediate problem below,
> but I think there's another problem that actually triggered this.
>
> On Fri, Feb 24, 2017 at 10:28 AM, kernel test robot
>
Added more relevant people. I've debugged the immediate problem below,
but I think there's another problem that actually triggered this.
On Fri, Feb 24, 2017 at 10:28 AM, kernel test robot
wrote:
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> https://git.kernel.
On Sat, Nov 19, 2016 at 12:54 PM, Mauro Carvalho Chehab
wrote:
>
> I did some research on Friday trying to identify where those images
> came. It turns that, for the oldest images (before I took the media
> maintainership), PDF were actually their "source", as far as I could track,
> in the sense
On Sat, Nov 19, 2016 at 9:55 AM, David Woodhouse wrote:
>
> I know it's unfashionable these days, but TeX always used to be bloody
> good at that kind of thing.
You must have used a different TeX than I did.
TeX is a horrible example. The moment you needed to insert anything
that TeX didn't know
On Thu, Nov 17, 2016 at 3:07 AM, Arnd Bergmann wrote:
>
> [adding Linus for clarification]
>
> I understood the concern as being about binary files that you cannot
> modify with classic 'patch', which is a separate issue.
No. That is how I *noticed* the issue. Those stupid pdf binary files
have b
On Thu, Nov 17, 2016 at 8:02 AM, Linus Torvalds
wrote:
>
> No. That is how I *noticed* the issue. Those stupid pdf binary files
> have been around forever, I just didn't notice until the Fedora people
> started complaining about the patches.
Side note: my release patches these
On Thu, Nov 10, 2016 at 8:44 AM, Arnd Bergmann wrote:
>
> Please merge these directly if you are happy with the result.
I will take this.
I do see two warnings, but they both seem to be valid and recent,
though, so I have no issues with the spurious cases.
Warning #1:
sound/soc/qcom/lpass-pl
On Wed, Nov 9, 2016 at 3:09 AM, Jörg Otte wrote:
>
> Tried patch with no success. Again a NULL ptr dereferece.
That patch was pure garbage, I think. Pretty much all the other
drivers that use the same approach will have the same issue. Adding
that init function just for the semaphore is crazy.
I
On Sun, Nov 6, 2016 at 7:40 AM, Jörg Otte wrote:
> Since v4.9-rc4 I get following crash in dvb-usb-cinergyT2 module.
Looks like it's commit 5ef8ed0e5608f ("[media] cinergyT2-core: don't
do DMA on stack"), which movced the DMA data array from the stack to
the "private" pointer. In the process it a
On Fri, 15 Jul 2016, James Patrick-Evans wrote:
>
> The memory leak is caused by the probe function of the airspy driver
> mishandeling errors and not freeing the corresponding control structures when
> an error occours registering the device to v4l2 core.
The patch causes a warning about the no
On Fri, May 27, 2016 at 2:23 PM, Arnd Bergmann wrote:
>
> This patch changes all users of IS_ERR_VALUE() that I could find
> on 32-bit ARM randconfig builds and x86 allmodconfig. For the
> moment, this doesn't change the definition of IS_ERR_VALUE()
> because there are probably still architecture
On Fri, May 27, 2016 at 2:46 PM, Andrew Morton
wrote:
>
> So you do plan to add some sort of typechecking into IS_ERR_VALUE()?
The easiest way to do it is to just turn the (x) into (unsigned
long)(void *)(x), which then complains about casting an integer to a
pointer if the integer has the wrong
On Wed, May 4, 2016 at 12:28 PM, Stefan Lippers-Hollmann wrote:
>
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -875,7 +875,7 @@ void __media_device_usb_init(struct medi
> const char *board_name,
> const cha
On Tue, May 3, 2016 at 9:39 PM, Stefan Lippers-Hollmann wrote:
>
> Just as a cross-check, this (incomplete, but au0828, cx231xx and em28xx
> aren't needed/ loaded on my system) crude revert avoids the problem for
> me on v4.6-rc6-113-g83858a7.
Hmm.
That just open-codes __media_device_usb_init().
On Tue, May 3, 2016 at 2:38 PM, Stefan Lippers-Hollmann wrote:
> Hi
> [...]
>> Mauro Carvalho Chehab (95):
> [...]
>> [media] use v4l2_mc_usb_media_device_init() on most USB devices
> [...]
>
> This change, as part of v4.6-rc6-85-g1248ded, breaks two systems, each
> equipped with a TeVii s48
On Fri, Nov 27, 2015 at 7:18 AM, Mauro Carvalho Chehab
wrote:
> Al Viro escreveu:
>
>> Take a look at this:
>> static unsigned int gsc_m2m_poll(struct file *file,
>> struct poll_table_struct *wait)
>> {
>> struct gsc_ctx *ctx = fh_to_ctx(file->priva
On Tue, Aug 18, 2015 at 1:18 PM, Mauro Carvalho Chehab
wrote:
>
> - Revert the IR encode patches, as the API is not mature enough.
> So, better to postpone the changes to a latter Kernel;
What the hell have you done with the commit messages?
The first line is completely corrupt
On Wed, Aug 12, 2015 at 12:05 AM, Christoph Hellwig wrote:
> + for_each_sg(sg, s, nents, i) {
> + if (sg_has_page(s))
> + kmemcheck_mark_initialized(sg_virt(s), s->length);
> + }
[ Again, I'm responding to one random patch - this pattern was in
othe
On Wed, Aug 12, 2015 at 12:05 AM, Christoph Hellwig wrote:
> Make all cache invalidation conditional on sg_has_page() and use
> sg_phys to get the physical address directly.
So this worries me a bit (I'm just reacting to one random patch in the series).
The reason?
I think this wants a big honk
It does seem like the error handling for mantis_dma_init() is insane..
Linus
On Sun, Aug 9, 2015 at 5:12 PM, RUC_Soft_Sec wrote:
> Summary:
> there exists a wrong return value of function mantis_dma_init().It's a
> theoretical problem. we use static analysis method to dete
On Fri, Feb 20, 2015 at 8:27 AM, Sumit Semwal wrote:
>
> Could you please pull a few dma-buf changes for 3.20-rc1? Nothing
> fancy, minor cleanups.
No.
I pulled, and immediately unpulled again.
This is complete shit, and the compiler even tells you so:
drivers/staging/android/ion/ion.c: In
-- Forwarded message --
From: Peter Kovář
Date: Sun, Feb 8, 2015 at 2:18 PM
Subject: divide error: in the gspca_topro
To: Linus Torvalds
Hi++ Linus!
There is a trivial bug in the gspca_topro webcam driver.
/* set the JPEG quality for sensor soi763a */
static void jpeg_s
On Sat, Jan 24, 2015 at 1:26 AM, Mauro Carvalho Chehab
wrote:
>
> Please pull from:
> git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
> media/v3.19-4
That does not exist.
The tip of that linux-media tree does match the commit you claim is
the tip but that's just the unsigned
Yeah, this is pure crap. It doesn't even compile.
drivers/media/dvb-frontends/si2165.c:1063:17: error: expected ‘,’ or
‘;’ before ‘SI2165_FIRMWARE’
MODULE_FIRMWARE(SI2165_FIRMWARE);
because it should presumably say "SI2165_FIRMWARE_REV_D" now.
Why the f*ck do you send me totally untested cr
On Sun, Sep 21, 2014 at 7:50 AM, Mauro Carvalho Chehab
wrote:
>
> PS.: FYI, I'm now starting to use mche...@osg.samsung.com e-mail address.
> The old one (m.che...@samsung.com) is still valid, but we're using the
> OSG subdomain for the Samsung's Open Source Group.
Thanks for signing this. When I
Brian, please use
./scripts/get_maintainer -f drivers/media/usb/dvb-usb-v2/rtl28xxu.c
to get the proper people to send this to, so that it doesn't get lost
in the flood in lkml.
The indentation of that new entry also seems to be suspect, in that it
doesn't match the ones around it.
Quoting ful
On Thu, Apr 3, 2014 at 9:11 AM, Mauro Carvalho Chehab
wrote:
>
> Please pull from:
> git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
> v4l_for_linus
Oh, just noticed that this seems to be the cause of a new annoying warning:
usr/include/linux/v4l2-common.h:72: found __[us
On Thu, Apr 3, 2014 at 9:11 AM, Mauro Carvalho Chehab
wrote:
>
> PS.: You'll find some minor conflicts between this changeset and upstream,
> mainly due to some code that moved from V4L2 to OF subsystem.
That conflict was not at all minor, unless I were willing to do the
merge incorrectly and jus
On Mon, Mar 31, 2014 at 1:06 AM, Hans Verkuil wrote:
>
> Running sparse over this gives:
>
> error: bad integer constant expression
So technically sparse is correct in this case. The kernel ends up
doing some questionable things that gcc allows. The index in an
assignment initializer is supposed
On Mon, Mar 31, 2014 at 12:51 AM, Hans Verkuil wrote:
>
> Here is a simple test case for this problem:
>
> == anon-union.c ==
> struct s {
> union {
> int val;
> };
> };
>
> static struct s foo = { .val = 5, };
Ok, this fixes the warning, but we seem to sti
On Sun, Mar 30, 2014 at 9:48 AM, Linus Torvalds
wrote:
>
> I'll think about how to fix it cleanly. Expect a patch shortly.
Ok, patch sent to linux-sparse mailing list. It fixes the particular
cut-down test-case and seems pretty simple and straightforward, but is
otherwise entirely u
On Sun, Mar 30, 2014 at 5:03 AM, Hans Verkuil wrote:
>
> which is clearly a sparse bug somewhere.
Yes. What is going on is that we create separate symbols for each
declaration, and we tie them all together (and warn if they have
conflicting types).
But then when we look up a symbol, we only look
On Fri, Feb 7, 2014 at 5:57 AM, Mauro Carvalho Chehab
wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
>
> for you to fetch changes up to 57f0547fbc1e925f5e58c76f311a6632c3f37740:
Grr. You missed the branch name.
I can see from the SHA1 (and historical pull requests
On Thu, Sep 5, 2013 at 7:24 AM, Mauro Carvalho Chehab
wrote:
>
> Also, a trivial conflict at s5p_mfc_dec.c and s5p_mfc_enc.c will happen as
> a macro name got renamed from IS_MFCV6 to IS_MFCV6_PLUS.
I did an "ugly merge" when fixing that conflict up, because the stupid
code at the conflict site d
On Sat, Aug 31, 2013 at 1:00 AM, Knut Petersen
wrote:
> Hi Linus!
>
> It would be nice to have head cx88fix of
> git.linuxtv.org/hverkuil/media_tree.git
> (git.linuxtv.org/hverkuil/media_tree.git/commit/5dce3635bf803cfe9dde84e00f5f9594439e6c02)
> in 3.11 as it is a trivial and tested fix for a reg
Jörg - does current git work for you? It has a patch from Rafael that
just reverts the insane error code, and fixed something very similar
for him.
(I just pushed out, so it might take a few minutes to mirror out to
the public sites).
Linus
On Sun, Dec 23, 2012 at 8:46 AM, Jörg Ott
On Wed, Oct 3, 2012 at 6:33 PM, Ming Lei wrote:
>
> Yes, the patch will make firmware cache not working, I would like to fix
> that when I return from one trip next week.
>
> BTW, firmware cache is still needed even direct loading is taken.
I agree 100%, I'd have liked to do the caching for the d
On Wed, Oct 3, 2012 at 3:48 PM, Andy Walls wrote:
>
> I don't know if you can remove the /sys/.../firmware ABI altogether, because
> there is at least one, somewhat popular udev replacement that also uses it:
> mdev
>
> http://git.busybox.net/busybox/plain/docs/mdev.txt
Heh. That web doc docume
On Wed, Oct 3, 2012 at 2:58 PM, Lucas De Marchi
wrote:
>
> So maintaining the fallback or adding a configurable entry to set the
> firmware paths might be good.
Yeah, I do think we need to make it configurable. Probably both at
kernel compile time and dynamically.
The aim of having a user-mode d
On Wed, Oct 3, 2012 at 12:50 PM, Greg KH wrote:
>>
>> Ok, like this?
>
> This looks good to me. Having udev do firmware loading and tieing it to
> the driver model may have not been such a good idea so many years ago.
> Doing it this way makes more sense.
Ok, I wish this had been getting more te
On Wed, Oct 3, 2012 at 12:48 PM, Kirill A. Shutemov
wrote:
>
> AFAIK, accessing files on filesystem form kernel directly was no-go for a
> long time. What's the new rule here?
Oh, we've *always* accessed files from the kernel.
What we don't want is random drivers doing so directly and without a
On Wed, Oct 3, 2012 at 10:24 AM, Kay Sievers wrote:
>
> Nothing really "breaks", It's "slow" and it will surely be fixed when
> we know what's the right fix, which we haven't sorted out at this
> moment.
A thirty-second pause at bootup is easily long enough that some people
might think the machin
On Wed, Oct 3, 2012 at 10:09 AM, Al Viro wrote:
>
> + if (!S_ISREG(inode->i_mode))
> + return false;
> + size = i_size_read(inode);
>
> Probably better to do vfs_getattr() and check mode and size in kstat; if
> it's sufficiently hot for that to hurt, we are fucked anyway.
On Wed, Oct 3, 2012 at 9:38 AM, Linus Torvalds
wrote:
>
> Anyway. Attached is a really stupid patch that tries to do the "direct
> firmware load" as suggested by Ivan. It has not been tested very
> extensively at all (but I did test that it loaded the brcmsmac
> firmware
On Wed, Oct 3, 2012 at 8:13 AM, Mauro Carvalho Chehab
wrote:
>
> Yes. The issue was noticed with media drivers when people started using the
> drivers on Fedora 17, witch came with udev-182. There's an open
> bugzilla there:
> https://bugzilla.redhat.com/show_bug.cgi?id=827538
Yeah, that
On Wed, Oct 3, 2012 at 7:36 AM, Kay Sievers wrote:
>
> If that unfortunate module_init() lockup can't be solved properly in
> the kernel
Stop this idiocy.
The kernel doesn't have a lockup problem. udev does.
As even you admit, it is *udev* that has the whole serialization
issue, and does exces
On Tue, Oct 2, 2012 at 5:01 PM, Jiri Kosina wrote:
> On Tue, 2 Oct 2012, Linus Torvalds wrote:
>
>> And see this email from Kay Sievers that shows that it was all known
>> about and intentional in the udev camp:
>>
>> http://www.spinics.net/lists/netdev/msg185742
On Tue, Oct 2, 2012 at 3:23 PM, Greg KH wrote:
>
> which went into udev release 187 which I think corresponds to the place
> when people started having problems, right Mauro?
According to what I've seen, people started complaining in 182, not 187.
See for example
http://patchwork.linuxtv.org/
On Tue, Oct 2, 2012 at 2:03 PM, Ivan Kalvachev wrote:
>
> I'm not kernel developer and probably my opinion would be a little
> naive, but here it is.
>
> Please, make the kernel load firmware from the filesystem on its own.
We probably should do that, not just for firmware, but for modules
too. I
On Tue, Oct 2, 2012 at 6:03 AM, Mauro Carvalho Chehab
wrote:
>
> I basically tried a few different approaches, including deferred probe(),
> as you suggested, and request_firmware_async(), as Kay suggested.
Stop this crazy. FIX UDEV ALREADY, DAMMIT.
Who maintains udev these days? Is it Lennart/K
On Fri, May 25, 2012 at 2:17 AM, Sumit Semwal wrote:
>
> I am really sorry - I goofed up in the git URL (sent the ssh URL
> instead).
I was going to send you an acerbic email asking for your private ssh
key, but then noticed that you had sent another email with the public
version of the git tree.
On Thu, May 24, 2012 at 3:33 PM, Mauro Carvalho Chehab
wrote:
>
> The Kconfig default for DVB_FE_CUSTOMISE is 'n'. So, if no DVB bridge is
> selected,
> nothing will be compiled.
Sadly, it looks like the default for distro kernels is 'y'.
Which means that if you start with a distro kernel confi
Btw, I only noticed now, because I normally don't build DVB on my main
machine with "oldconfig" - why the hell does DVB add tuners with
"default m"?
Why would *anybody* with an old config ever want to get those new
drivers as modules?
Get rid of all the stupid
default m if DVB_FE_CUSTOMISE
be
On Sun, Apr 1, 2012 at 10:23 AM, wrote:
> From: Tracey
Please fix your git config to have proper name and email (or whatever
tool you used). Your 'cc' list is similarly broken.
> Either selecting or depending on the CONFIG_SND_FM801_TEA575X_BOOL
> fixes the problem, but select seems to be more
On Fri, Jan 6, 2012 at 8:19 AM, Arnd Bergmann wrote:
>
> For a simpler solution, we could keep the old warning message, but change
> the logic from
>
> (.compat_ioctl == NULL || .compat_ioctl() == -ENOIOCTL) && (no generic
> handler)
>
> to
>
> (.ioctl != NULL && .compat_ioctl == NULL) && (no gen
On Thu, Jan 5, 2012 at 9:37 AM, Mauro Carvalho Chehab
wrote:
>
> For the media drivers, we've already fixed it, at the V4L side:
> -EINVAL doesn't mean that an ioctl is not supported anymore.
> I think that such fix went into Kernel 3.1.
Ok, I'm happy to hear that the thing should be fixed. My gr
On Thu, Jan 5, 2012 at 9:26 AM, Paolo Bonzini wrote:
> On 01/05/2012 06:02 PM, Linus Torvalds wrote:
>>
>> + return ret == -EINVAL ||
>> + ret == -ENOTTY ||
>> + ret == ENOIOCTLCMD;
>
>
> Missing minus before ENOIOCTLCM
On Thu, Jan 5, 2012 at 9:02 AM, Linus Torvalds
wrote:
>
> Added, linux-media and Mauro to the Cc, because I'm about to commit
> something like the attached patch to see if anything breaks. We may
> have to revert it if things get too nasty, but we should have done
> this yea
On Thu, Jan 5, 2012 at 8:16 AM, Linus Torvalds
wrote:
>
> Just fix the *obvious* breakage in BLKROSET. It's clearly what the
> code *intends* to do, it just didn't check for ENOIOCTLCMD.
So it seems from quick grepping that the block layer isn't actually
all that confused
On Mon, Jun 27, 2011 at 11:04 PM, Hans Verkuil wrote:
>
> Of course, since vfs_ioctl does the same thing this is clearly isn't some
> isolated V4L thing. Pot. Kettle.
Oh, absolutely. V4L is not at all the only confused user around.
The EINVAL thing goes way back, and is a disaster. It predates L
On Mon, Jun 27, 2011 at 10:07 AM, Hans Verkuil wrote:
>
> No, what we do is perfectly consistent: i.e. we always return EINVAL when an
> ioctl is not supported. That's what 'consistent' means. Whether that is the
> *right* error code is something else.
You don't even understand the problem.
The
On Sun, Jun 26, 2011 at 9:06 AM, Mauro Carvalho Chehab
wrote:
> + ENOIOCTLCMD
> +
> + The application attempted to use a non-existent ioctl. This
> is returned by the V4L2 core only.
> + Applications should be able to handle this error code, in
> order to detec
On Wed, Jan 26, 2011 at 8:00 AM, Mauro Carvalho Chehab
wrote:
>
> See, it will only look into the 16-bits scancode space. There are several
> remote
> controllers with 24 bits and 32 bits, so the tool is already broken anyway.
Mauro, stop blathering.
The problem is that the tool used to work wi
On Wed, Jan 26, 2011 at 7:01 AM, Dmitry Torokhov
wrote:
>
> BTW, another issue is that evdev's ioctl returns -EINVAL for unknown
> ioctls so applications would have hard time figuring out whether error
> returned because of kernel being too old or because they are trying to
> retrieve/establish in
On Wed, Jan 26, 2011 at 2:48 AM, Dmitry Torokhov
wrote:
>
> We should be able to handle the case where scancode is valid even though
> it might be unmapped yet. This is regardless of what version of
> EVIOCGKEYCODE we use, 1 or 2, and whether it is sparse keymap or not.
>
> Is it possible to valid
Hi Marcos,
[ full email quoted for new cc's ]
you really would be much better off sending a diff rather than trying
to explain what changes you did, but quite frankly, even if you did
that, I'd still want this to go through the actual maintainers of the
em28xx driver.
The USB error sounds like s
On Mon, Sep 27, 2010 at 1:57 PM, Mauro Carvalho Chehab
wrote:
> The following changes since commit 32163f4b2cef28a5aab8b226ffecfc6379a53786:
>
> alpha: fix usp value in multithreaded coredumps (2010-09-25 14:38:13 -0700)
>
> are available in the git repository at:
> ssh://master.kernel.org/pub/s
On Mon, 8 Feb 2010, Chicken Shack wrote:
> ...
Please stop emailing me. I'm simply not interested in your political
troubles with the DVB people.
I see with my own eyes why people have issues with your way of
communication, and quite frankly, I'm not interested in discussing
name-calling wit
On Mon, 8 Feb 2010, Mauro Carvalho Chehab wrote:
>
> are available in the git repository at:
>
> ssh://linuxtv.org/git/fixes.git v4l_for_linus
I don't have ssh access to that thing, and git:// doesn't work.
You probably meant
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/li
On Mon, 8 Feb 2010, Chicken Shack wrote:
>
> This is a SCANDAL, not fun! This is SCANDALOUS!
I agree that this whole thread has been totally inappropriate from
beginning to end.
On all sides, btw. I would suggest that somebody who can't even use his
own name should be the last to complain a
On Wed, 18 Nov 2009, Tejun Heo wrote:
>
> I might have been too early with the 'easy' part but I definitely can
> give it a shot. What do you think about the scheduler notifier
> implementation? It seems we'll end up with three callbacks. It can
> either be three hlist_heads in the struct_tas
On Tue, 17 Nov 2009, Tejun Heo wrote:
>
> Do you think that usage is wide-spread? Implementing strict ordering
> shouldn't be too difficult but I can't help but feeling that such
> assumption is abuse of implementation detail.
I think it would be good if it were more than an implementation deta
On Sat, 7 Nov 2009, Mauro Carvalho Chehab wrote:
>
> Please pull from:
>
> ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
> for_linus
"Already up-to-date."
Forgot to push it out?
Linus
--
To unsubscribe from this list: send the line "u
On Wed, 12 Aug 2009, Mauro Carvalho Chehab wrote:
>
> Please pull from:
>
> ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
> for_linus
"Already up-to-date."
Forgot to push?
Linus
--
To unsubscribe from this list: send the line "unsubscribe lin
On Mon, 6 Jul 2009, Krzysztof Helt wrote:
>
> Who should I send this patch to be included as a 2.6.31 regression fix?
Just send the patches to me. I've got the patch, but no changelog, and so
I'd like to see them again, with changelogs and the proper "Acked-by:" or
"Tested-by" lines etc.
On Mon, 6 Jul 2009, Paul Mundt wrote:
>
> Ok, here is an updated version with an updated matroxfb and the sm501fb
> change reverted.
Wu Zhangjin, can you also confirm that this works for you (without your
patch)?
Linus
--
To unsubscribe from this list: send the line "unsubscrib
1 - 100 of 105 matches
Mail list logo
