sn't actually need to populate the sg_table with pages.
At the very least, there are places such as i915_gem_stolen.c and
(some situations of) videobuf-dma-sg.c that take this approach.
Cheers,
David
--
Benötigen Sie dringend einen Kredit? Wenn ja, antworten Sie für weitere
Details
150 styles and colors to choose from.
People will keep the USB drive you give them and show it to others
increasing your marketing value
Please click
to see all of our stock models and get a quote.
If you are nonprofit, have further discounts for schools and charities.
Thanks,
David
USB Drive
150 styles and colors to choose from.
People will keep the USB drive you give them and show it to others
increasing your marketing value
Please click
to see all of our stock models and get a quote.
If you are nonprofit, have further discounts for schools and charities.
Thanks,
David
USB Drive
From: Christoph Hellwig
Date: Mon, 10 Dec 2018 20:22:28 +0100
> On Mon, Dec 10, 2018 at 10:10:39AM -0800, David Miller wrote:
>> From: Christoph Hellwig
>> Date: Mon, 10 Dec 2018 17:32:56 +0100
>>
>> > Dave, can you pick the series up through the sparc tree? I co
From: Christoph Hellwig
Date: Mon, 10 Dec 2018 17:32:56 +0100
> Dave, can you pick the series up through the sparc tree? I could also
> merge it through the dma-mapping tree, but given that there is no
> dependency on it the sparc tree seem like the better fit.
I thought that some of this is a
hi
using the experimental version of the media stack and i get this
[ 80.606898] dvb-usb: found a 'DViCO FusionHDTV DVB-T NANO2 w/o
firmware' in cold state, will try to load a firmware
[ 80.620010] dvb-usb: downloading firmware from file
'dvb-usb-bluebird-02.fw'
[ 80.656195] usbcore: re
-off-by: Christoph Hellwig
Acked-by: David S. Miller
From: Christoph Hellwig
Date: Sat, 8 Dec 2018 09:36:58 -0800
> Just allocate the memory and use map_page to map the memory.
>
> Signed-off-by: Christoph Hellwig
Acked-by: David S. Miller
-off-by: Christoph Hellwig
Acked-by: David S. Miller
From: Christoph Hellwig
Date: Sat, 8 Dec 2018 09:37:00 -0800
> Just allocate the memory and use map_page to map the memory.
>
> Signed-off-by: Christoph Hellwig
Acked-by: David S. Miller
From: Christoph Hellwig
Date: Sat, 8 Dec 2018 09:41:14 -0800
> It has nothing to do with the content of the pci.h header.
>
> Suggested by: Sam Ravnborg
> Signed-off-by: Christoph Hellwig
Acked-by: David S. Miller
lwig
Acked-by: David S. Miller
From: Christoph Hellwig
Date: Sat, 8 Dec 2018 09:41:15 -0800
> There are enough common defintions that a single header seems nicer.
>
> Also drop the pointless include.
>
> Signed-off-by: Christoph Hellwig
> Acked-by: Sam Ravnborg
Acked-by: David S. Miller
From: Christoph Hellwig
Date: Sat, 8 Dec 2018 09:41:11 -0800
> Factor the code to remap memory returned from the DMA coherent allocator
> into two helpers that can be shared by the IOMMU and direct mapping code.
>
> Signed-off-by: Christoph Hellwig
Acked-by: David S. Miller
From: Christoph Hellwig
Date: Sat, 8 Dec 2018 09:41:13 -0800
> The only thing we need to explicitly pull in is the defines for the
> CPU type.
>
> Signed-off-by: Christoph Hellwig
Acked-by: David S. Miller
ever appear).
>
> Similarly a dma_supported method that always returns 0 is rather
> pointless. The only thing that indicates is that no one ever calls
> the method on sbus devices.
>
> Signed-off-by: Christoph Hellwig
Acked-by: David S. Miller
From: Jarkko Sakkinen
Date: Fri, 30 Nov 2018 13:44:05 -0800
> On Fri, Nov 30, 2018 at 01:01:02PM -0800, James Bottomley wrote:
>> No because use of what some people consider to be bad language isn't
>> necessarily abusive, offensive or degrading. Our most heavily censored
>> medium is TV and "fu
From: Jarkko Sakkinen
Date: Fri, 30 Nov 2018 13:42:33 -0800
> Can you tell how the CoC should be interpreted then?
Regardless of what I think, as others have showen the CoC explicitly
does not apply to existing code.
From: Abuse
Date: Fri, 30 Nov 2018 20:39:01 +
> I assume I will now be barred.
Perhaps, but not because you said fuck. It would be because you're
intentionally creating a disturbance on the list and making it more
difficult for developers to get their work done and intentionally
creating a
From: Jens Axboe
Date: Fri, 30 Nov 2018 13:12:26 -0700
> On 11/30/18 12:56 PM, Davidlohr Bueso wrote:
>> On Fri, 30 Nov 2018, Kees Cook wrote:
>>
>>> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
>>> wrote:
In order to comply with the CoC, replace with a hug.
>>
>> I hope thi
From: Davidlohr Bueso
Date: Fri, 30 Nov 2018 11:56:52 -0800
> I hope this is some kind of joke.
Whether or not it is a joke, it is censorship.
And because of that I have no intention to apply any patches like this
to any code I am in charge of.
us places per Andrew
> - Updated 'dev_to_node' to use NUMA_NO_NODE instead per Vinod
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
his might also have replaced some false positives.
> I will appreciate suggestions, inputs and review.
>
> 1. git grep "nid == -1"
> 2. git grep "node == -1"
> 3. git grep "nid = -1"
> 4. git grep "node = -1"
Hopefully you found most users :)
Did you check if some are encoded into function calls? f(-1, ...)
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
dvb_register() in cx23885-dvb.c - or does that prevent the firmware from
loading?
And I'm guessing this change would have to be applied to all drivers?
David
David Howells wrote:
> > > > Devices without a mac address shouldn't have a mac_dvb sysfs attribute,
> > > > I think.
> > >
> > > I'm not sure that's possible within the core infrastructure. It's a
> > > class attribute se
org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/media/rc/rc-main.c#n1844
By analogy, then, I think the thing to do is to put something like struct
rc_dev::sysfs_groups[] into struct dvb_device (or maybe struct dvb_adapter)
and then the dvb_mac attribute in there during dvb_register_device() based on
whether or not the MAC address is not all zeros at that point.
David
Sean Young wrote:
> > How do I tell? If it's all zeros it's not there?
>
> The mac gets populated through read_mac_address member of
> dvb_usb_device_properties.
That doesn't seem to be true for all drivers. The cx23885 driver does things
differently, for instance.
David
than it doesn't have the real MAC address in it?
> Having said that dvb_type does look a little nicer:
>
> ATTR{dvb_type}=="demux"
So I should keep that or drop that?
David
/dvb0.demux0/dvb_mac <==
> 00:00:00:00:00:00
I can't say why that happens. I don't have access to this hardware. Should
it have a MAC address there? Is the MAC address getting stored in
dvbdev->adapter->proposed_mac? Maybe it's not getting read - on the card I
use it's read by the cx23885 driver... I think... The nova-t-usb2.c file
doesn't mention proposed_mac.
David
additional bufs on interrupt
Cheers
David
On 15/09/18 01:42, Vincent McIntyre wrote:
> On Thu, Sep 13, 2018 at 06:39:57PM +0100, David R wrote:
>> Hi
>>
>> Just a heads up. I'm having to revert cx23885-core.c to the 4.17 version
>> to obtain stability with my
stB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR-
Kernel driver in use: cx23885
Cheers
David
don't
need to enable quirks to fetch the image when using it but the cropped
image is exactly the same.
Here is the system configuration:
* Kernel 4.9.52
* v4l 1.14.2
* XHV57-NBL60 usb camera with uvcvideo driver
Would you know how I could know V4l is not causing such issue?
Best regards,
David Bensoussan
From: Kieran Bingham [mailto:kieran.bingham+rene...@ideasonboard.com]
> On 13/03/18 11:20, David Laight wrote:
> > From: Kieran Bingham
> >> Sent: 09 March 2018 22:04
> >> The kernel provides a __packed definition to abstract away from the
> >> compiler specif
_list lists[8];
> u32 next_header;
> u32 flags;
> -} __attribute__((__packed__));
> +} __packed;
>
> struct vsp1_dl_entry {
> u32 addr;
> u32 data;
> -} __attribute__((__packed__));
> +} __packed;
Do these structures ever actually appear in misaligned memory?
If they don't then they shouldn't be marked 'packed'.
David
iver doesn't call either of these functions as far as I
can tell - at least, not directly. Maybe by vb2_dvb_register_bus()?
Note that these attribute files appear for the demux, dvr and net directories
as well as for the frontend.
Hmmm... further, the port number is no longer getting through and all adapters
are showing port 0. The MAC address works, though. Maybe I should drop the
port number.
David
From: Bjorn Helgaas
Date: Wed, 17 Jan 2018 18:08:18 -0600
> [+cc David, FYI, I plan to merge this via PCI along with the rest of
> Christoph's series]
No problem.
Note that binding the dvb-net device to a network interface and changing it
there does not reflect back into the the dvb_adapter struct and doesn't
change the MAC address here. This means that a system with two identical
cards in it may need to distinguish them by some other means t
virtual address).
lspci lies [1], run lspci -x (or hexdump config space through /sys/devices)
to see what is actually in the BAR.
[1] The addresses come from somewhere other than reading the BAR.
If the endpoint resets the BAR lspci will still report the old
addresses.
David
ut we've had 'fun' getting Altera fpga
to do sensible PCIe cycles (I ended up writing a simple dma controller
that would generate long TLP).
We also found a bug in the Altera logic that processed interleaved
read completions.
David
October 4, 2017 6:57 PM, "Mauro Carvalho Chehab"
wrote:
> Em Sun, 25 Jun 2017 14:31:50 +0200
> David Härdeman escreveu:
>
>> lirc_zilog uses a chunk_size of 2 and ir-lirc-codec uses sizeof(int).
>>
>> Therefore, using stack memory should be perfec
Hello
Is it possible to use the HDMI output as a V4L Video Output Interface or
Video Output Overlay Interface using mainline kernels?
Dave
From: Arnd Bergmann
Date: Fri, 22 Sep 2017 23:29:18 +0200
> Inlining these functions creates lots of stack variables that each take
> 64 bytes when KASAN is enabled, leading to this warning about potential
> stack overflow:
>
> drivers/net/ethernet/rocker/rocker_ofdpa.c: In function
> 'ofdpa_cm
From: Arnd Bergmann
Date: Fri, 22 Sep 2017 23:29:19 +0200
> When CONFIG_KASAN is enabled, the "--param asan-stack=1" causes rather large
> stack frames in some functions. This goes unnoticed normally because
> CONFIG_FRAME_WARN is disabled with CONFIG_KASAN by default as of commit
> 3f181b4d8652
almost certainly be a marker in a header file somewhere,
so it should be possibly to teach it about other functions.
David
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Desk of Mr.pdf
Description: Adobe PDF document
On 08/19/2017 03:34 AM, Bhumika Goyal wrote:
Make these const as they are only used in a copy operation.
Done using Coccinelle.
Signed-off-by: Bhumika Goyal
i2c-octeon-platdrv.c and i2c-thunderx-pcidrv.c changes:
Acked-by: David Daney
Thanks.
---
drivers/i2c/busses/i2c-kempld.c
On Sat, Jul 01, 2017 at 01:20:50PM +0100, Sean Young wrote:
>On Thu, Jun 22, 2017 at 09:24:00PM +0200, David Härdeman wrote:
>> Protocols like NEC generate around 10 repeat events per second.
>>
>> The input events are not very useful for userspace but still waste power
renames the mutex at the same time (the name
irctl_lock will be misleading once struct irctl goes away in later
patches).
V2: make sure ir->d.minor is set as well once allocated
(found by Fengguang Wu )
Signed-off-by: David Härdeman
---
drivers/media/rc/lirc_dev.c |
ir-lirc-codec is the only user of these functions, so instead of exporting them
from lirc_dev, move all of them over to ir-lirc-codec.
This means that all ir-lirc-codec fops can be found next to each other in
ir-lirc-codec.
Signed-off-by: David Härdeman
---
drivers/media/rc/ir-lirc-codec.c
: driver ir-lirc-codec (rc-loopback) registered at minor
= 0
After:
rc rc0: rc-core loopback device as /devices/virtual/rc/rc0
input: rc-core loopback device as /devices/virtual/rc/rc0/input23
lirc lirc0: rc-core loopback device as /devices/virtual/rc/rc0/lirc0
Signed-off-by: David Härdeman
ir_lirc_ioctl() is the only caller of lirc_dev_fop_ioctl() so merging the
latter into the former makes the code more readable. At the same time, this
allows the locking situation in ir_lirc_ioctl() to be fixed by holding
the lirc_dev mutex during the whole ioctl call.
Signed-off-by: David
lifetime
of the resulting struct and simplifies the code at the same time.
Signed-off-by: David Härdeman
---
drivers/media/rc/ir-lirc-codec.c| 15 +-
drivers/media/rc/lirc_dev.c | 288 +--
drivers/staging/media/lirc/lirc_zilog.c | 20
struct lirc_dev.
Signed-off-by: David Härdeman
---
drivers/staging/media/lirc/lirc_zilog.c | 69 ++-
1 file changed, 40 insertions(+), 29 deletions(-)
diff --git a/drivers/staging/media/lirc/lirc_zilog.c
b/drivers/staging/media/lirc/lirc_zilog.c
index 51512ba7f5b8
simplistic at this point, later patches will put
more flesh on the bones of both.
Signed-off-by: David Härdeman
---
drivers/media/rc/ir-lirc-codec.c |2 +-
drivers/media/rc/lirc_dev.c | 13 +
include/media/lirc_dev.h |9 -
3 files changed, 18 insertions(+), 6
The define is only used in the lirc_zilog driver and once in lirc_dev.
In lirc_dev it rather serves to make the limits on d->code_length less clear,
so move the define to lirc_zilog.
Signed-off-by: David Härdeman
---
drivers/media/rc/lirc_dev.c |5 ++---
drivers/staging/me
Using the kernel-provided IDA simplifies the code and makes it possible
to remove the lirc_dev_lock mutex.
Signed-off-by: David Härdeman
---
drivers/media/rc/lirc_dev.c | 36
include/media/lirc_dev.h|1 -
2 files changed, 12 insertions(+), 25
lirc_zilog stashes a pointer to the parent device in struct lirc_dev and uses
it for logging. It makes more sense to let lirc_zilog keep track of that
pointer in its own struct (this is in preparation for subsequent patches
which will remodel struct lirc_dev).
Signed-off-by: David Härdeman
This is in preparation for the later patches which do away with
struct irctl entirely.
Signed-off-by: David Härdeman
---
drivers/media/rc/ir-lirc-codec.c| 50 ---
drivers/media/rc/lirc_dev.c | 12 ---
drivers/media/rc/rc-core-priv.h
renames the mutex at the same time (the name
irctl_lock will be misleading once struct irctl goes away in later
patches).
Signed-off-by: David Härdeman
---
drivers/media/rc/lirc_dev.c | 164 ---
1 file changed, 91 insertions(+), 73 deletions(-)
diff --git a
The "attached" member of struct irctl is a boolean value, so let the code
reflect that.
Signed-off-by: David Härdeman
---
drivers/media/rc/lirc_dev.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_d
#x27;t very elegant, but
it's a stopgap measure which can be removed once lirc_zilog is converted
to rc-core.
Signed-off-by: David Härdeman
---
drivers/media/rc/lirc_dev.c | 70 +--
drivers/staging/media/lirc/lirc_zilog.c | 53 --
Replace calls to cdev_add() and device_add() with the cdev_device_add()
helper function.
Signed-off-by: David Härdeman
---
drivers/media/rc/lirc_dev.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc
ready available from struct lirc_buffer).
Signed-off-by: David Härdeman
---
drivers/media/rc/lirc_dev.c | 26 +-
drivers/staging/media/lirc/lirc_zilog.c |5 +
include/media/lirc_dev.h|9 +
3 files changed, 19 insertions(+
lirc_zilog uses a chunk_size of 2 and ir-lirc-codec uses sizeof(int).
Therefore, using stack memory should be perfectly fine.
Signed-off-by: David Härdeman
---
drivers/media/rc/lirc_dev.c |8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/media/rc/lirc_dev.c
If an error is generated, it is more logical to error out ASAP.
Signed-off-by: David Härdeman
---
drivers/media/rc/lirc_dev.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index db1e7b70c998..9c1d55e41e34
There are no users of this functionality (ir-lirc-codec.c has its own
implementation and lirc_zilog.c doesn't use it) so remove it.
Signed-off-by: David Härdeman
---
drivers/media/rc/lirc_dev.c | 18 --
include/media/lirc_dev.h|8
2 files changed, 26 dele
All users of lirc_register_driver() uses dynamic minor allocation, therefore
we can remove the ability to explicitly request a given number.
This changes the function prototype of lirc_unregister_driver() to also
take a struct lirc_driver pointer as the sole argument.
Signed-off-by: David
locking in lirc_dev is also much improved by only having one mutex per
struct lirc_dev which is used to synchronize all operations.
The modifications to lirc_dev and ir-lirc-codec have been tested using
rc-loopback and mceusb. The changes to lirc_zilog are only compile tested.
---
David Härdeman (19
Protocols like NEC generate around 10 repeat events per second.
The input events are not very useful for userspace but still waste power
by waking up every listener. So let's remove them (MSC_SCAN events
are still generated for the initial keypress).
Signed-off-by: David Härdeman
---
dr
keydown check into rc_repeat() where the proper
locking is done.
The second patch I'd consider optional, it removes the input events for
repeat messages which I consider to be rather pointless.
---
David Härdeman (2):
rc-core: consistent use of rc_repeat()
rc-main: remove
yo and modifying the check a bit in rc_repeat() so that
no input event is generated if the key isn't pressed.
Signed-off-by: David Härdeman
---
drivers/media/rc/ir-nec-decoder.c | 10 +++---
drivers/media/rc/ir-sanyo-decoder.c | 10 +++---
drivers/media/rc/rc-main.c |
On Sun, Jun 11, 2017 at 05:17:40PM +0100, Sean Young wrote:
>On Sat, Apr 29, 2017 at 10:44:58AM +0200, David Härdeman wrote:
>> >This can be implemented without breaking userspace.
>>
>> How?
>
>The current keymaps we have do not specify the protocol variant, only
On Sun, May 28, 2017 at 04:04:30PM +0100, Sean Young wrote:
>On Sun, May 28, 2017 at 10:23:37AM +0200, David Härdeman wrote:
>> On Sun, May 21, 2017 at 09:57:13AM +0100, Sean Young wrote:
>> >On Mon, May 01, 2017 at 06:03:51PM +0200, David Härdeman wrote:
>> >
On Sun, Jun 11, 2017 at 05:02:24PM +0100, Sean Young wrote:
>On Sun, May 28, 2017 at 10:28:44AM +0200, David Härdeman wrote:
>> On Mon, May 22, 2017 at 09:40:30PM +0100, Sean Young wrote:
>> >On Mon, May 01, 2017 at 06:10:06PM +0200, David Härdeman wrote:
>> >> Obvi
On Tue, May 23, 2017 at 10:20:27AM +0100, Sean Young wrote:
>On Mon, May 01, 2017 at 06:10:17PM +0200, David Härdeman wrote:
>> Replace the REP_DELAY value with a static value, which makes more sense.
>> Automatic repeat handling in the input layer has no relevance for the driver
On Mon, May 22, 2017 at 09:40:30PM +0100, Sean Young wrote:
>On Mon, May 01, 2017 at 06:10:06PM +0200, David Härdeman wrote:
>> Obvious fix, leave repeat handling to rc-core
>>
>> Signed-off-by: David Härdeman
>> ---
>> drivers/media/rc/ir-nec-decoder.c | 10
On Mon, May 22, 2017 at 09:09:42PM +0100, Sean Young wrote:
>On Mon, May 01, 2017 at 06:04:42PM +0200, David Härdeman wrote:
>> Using the kernel ida facilities, we can avoid a lot of unnecessary code and
>> at the same
>> time get rid of lirc_dev_lock in favour of per-dev
On Sun, May 21, 2017 at 09:57:13AM +0100, Sean Young wrote:
>On Mon, May 01, 2017 at 06:03:51PM +0200, David Härdeman wrote:
>> If an error is generated, nonseekable_open() shouldn't be called.
>
>There is no harm in calling nonseekable_open(), so this commit is
>misleading
On Fri, May 19, 2017 at 07:21:23PM +0100, Sean Young wrote:
>On Mon, May 01, 2017 at 06:04:47PM +0200, David Härdeman wrote:
>> Remove superfluous includes and defines.
>>
>> Signed-off-by: David Härdeman
>> ---
>> drivers/media/rc/lirc_dev.c | 12 +--
On Sat, May 20, 2017 at 12:10:40PM +0100, Sean Young wrote:
>On Wed, May 03, 2017 at 12:04:00PM +0200, David Härdeman wrote:
>> The device core infrastructure is based on the presumption that
>> once a driver calls device_add(), it must be ready to accept
>> userspace int
On Wed, May 17, 2017 at 09:09:57PM +0100, Sean Young wrote:
>Hi David,
>
>On Wed, May 03, 2017 at 12:04:00PM +0200, David Härdeman wrote:
>> The device core infrastructure is based on the presumption that
>> once a driver calls device_add(), it must be ready to accept
>
before calling device_add().
Version 2: switch the order in which rc_prepare_rx_device() and
ir_raw_event_prepare() gets called so that dev->change_protocol()
gets called before device_add().
Signed-off-by: David Härdeman
---
drivers/media/rc/rc-core-priv.h |2 +
drivers/media/rc/rc-ir-ra
On Tue, May 02, 2017 at 09:48:26PM +0100, Sean Young wrote:
>On Tue, May 02, 2017 at 08:53:02PM +0200, David Härdeman wrote:
>> On Mon, May 01, 2017 at 07:47:25PM +0200, David Härdeman wrote:
>> >On Mon, May 01, 2017 at 05:49:53PM +0100, Sean Young wrote:
>> >>On T
On Mon, May 01, 2017 at 07:47:25PM +0200, David Härdeman wrote:
>On Mon, May 01, 2017 at 05:49:53PM +0100, Sean Young wrote:
>>On Thu, Apr 27, 2017 at 10:34:03PM +0200, David Härdeman wrote:
>>> The device core infrastructure is based on the presumption that
>>> onc
On Tue, May 02, 2017 at 06:04:18PM +0100, Sean Young wrote:
>On Mon, May 01, 2017 at 06:04:52PM +0200, David Härdeman wrote:
>> The name is only used for a few debug messages and the name of the parent
>> device as well as the name of the lirc device (e.g. "lirc0")
On Mon, May 01, 2017 at 05:49:53PM +0100, Sean Young wrote:
>On Thu, Apr 27, 2017 at 10:34:03PM +0200, David Härdeman wrote:
>> The device core infrastructure is based on the presumption that
>> once a driver calls device_add(), it must be ready to accept
>> userspace int
Just some debug statements to change.
Signed-off-by: David Härdeman
---
drivers/media/usb/cx231xx/cx231xx-input.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/media/usb/cx231xx/cx231xx-input.c
b/drivers/media/usb/cx231xx/cx231xx-input.c
index 6e80f3c573f3
Not sure what the driver is trying to do, however, IR handling seems incomplete
ATM so deleting the offending parts shouldn't affect functionality
Signed-off-by: David Härdeman
---
drivers/media/usb/tm6000/tm6000-input.c |4
1 file changed, 4 deletions(-)
diff --git a/drivers/
Replace the REP_DELAY value with a static value, which makes more sense.
Automatic repeat handling in the input layer has no relevance for the drivers
idea of "a long time".
Signed-off-by: David Härdeman
---
drivers/media/rc/rc-ir-raw.c |4 +---
1 file changed, 1 insertion(+), 3
Obvious fix, leave repeat handling to rc-core
Signed-off-by: David Härdeman
---
drivers/media/rc/ir-nec-decoder.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/media/rc/ir-nec-decoder.c
b/drivers/media/rc/ir-nec-decoder.c
index 3ce850314dca
Changing the protocol does not imply that the keymap changes.
Signed-off-by: David Härdeman
---
drivers/media/rc/img-ir/img-ir-hw.c |4
1 file changed, 4 deletions(-)
diff --git a/drivers/media/rc/img-ir/img-ir-hw.c
b/drivers/media/rc/img-ir/img-ir-hw.c
index 431d33b36fb0
Leave repeat handling to rc-core.
Signed-off-by: David Härdeman
---
drivers/media/rc/ir-sanyo-decoder.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/media/rc/ir-sanyo-decoder.c
b/drivers/media/rc/ir-sanyo-decoder.c
index 520bb77dcb62..e6a906a34f90
The following patch series fixes up various drivers which go
poking around in struct rc_dev for no good reason.
---
David Härdeman (7):
rc-core: ati_remote - leave the internals of rc_dev alone
rc-core: img-ir - leave the internals of rc_dev alone
rc-core: img-nec-decoder
The REP_DELAY setting on the input device is independent of hardware. This
change should not change how to driver works (as it does a keydown/keyup and
has no real repeat handling).
Signed-off-by: David Härdeman
---
drivers/media/rc/ati_remote.c |3 ---
1 file changed, 3 deletions(-)
diff
Most drivers return both values when the device is gone.
Signed-off-by: David Härdeman
---
drivers/media/rc/lirc_dev.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 57d21201ff93..e44e0b23b883 100644
--- a
Remove superfluous includes and defines.
Signed-off-by: David Härdeman
---
drivers/media/rc/lirc_dev.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 7db7d4c57991..4ba6c7e2d41b 100644
--- a
Remove some stuff from lirc_dev.h which is not used anywhere.
Signed-off-by: David Härdeman
---
include/media/lirc_dev.h | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/include/media/lirc_dev.h b/include/media/lirc_dev.h
index 11f455a34090..af738d522dec 100644
The name is only used for a few debug messages and the name of the parent
device as well as the name of the lirc device (e.g. "lirc0") are sufficient
anyway.
Signed-off-by: David Härdeman
---
drivers/media/rc/ir-lirc-codec.c|2 --
drivers/media/rc/lirc_dev.c
Using the kernel ida facilities, we can avoid a lot of unnecessary code and at
the same
time get rid of lirc_dev_lock in favour of per-device locks (the irctls array
was used
throughout lirc_dev so this patch necessarily touches a lot of code).
Signed-off-by: David Härdeman
---
drivers/media
1 - 100 of 1202 matches
Mail list logo
