- 29 10月, 2014 4 次提交
-
-
由 Benjamin Tissoires 提交于
There is no point in keeping the header in a separate file, nobody but hid-logitech-dj should have access to its content. Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: NAndrew de los Reyes <adlr@chromium.org> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Benjamin Tissoires 提交于
Several benefits here: - we can drop the macro is_dj_device: I never been really conviced by this macro as we could fall into a null pointer anytime. Anyway time showed that this never happened. - we can simplify the hid driver logitech-djdevice, and make it aware of any new receiver VID/PID. - we can use the Wireless PID of the DJ device as the product id of the hid device, this way the sysfs will differentiate between different DJ devices. Signed-off-by: NBenjamin Tisssoires <benjamin.tissoires@redhat.com> Tested-by: NAndrew de los Reyes <adlr@chromium.org> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Benjamin Tissoires 提交于
This allows the transport layer (I have in mind hid-logitech-dj and uhid) to set the group before it is added to the hid bus. This way, it can bypass the hid_scan_report() call, and choose in advance which driver will handle the newly created hid device. Signed-off-by: NBenjamin Tisssoires <benjamin.tissoires@redhat.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Benjamin Tissoires 提交于
While merging wacom from the input to the hid tree, some comments have been duplicated. We can also integrate the test for Synaptics devices in the switch case below, so it is clear that there will be only one place for such quirks. No functional changes are expected in this commit. Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 22 10月, 2014 1 次提交
-
-
由 Hans de Goede 提交于
Currently unknown consumer page codes are ignored, which means that they cannot later be mapped from userspace using udev / hwdb. Map them to KEY_UNKNOWN, so that userspace can remap them for keyboards which make up their own consumer page codes. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 08 10月, 2014 4 次提交
-
-
由 Takao Indoh 提交于
This patch fixes a bug on hotmod removing. After ipmi interface is removed using hotmod, kernel panic occurs when rmmod impi_si. For example, try this: # echo "remove,"`cat /proc/ipmi/0/params` > \ /sys/module/ipmi_si/parameters/hotmod # rmmod ipmi_si Then, rmmod fails with the following messages. ------------[ cut here ]------------ WARNING: CPU: 12 PID: 10819 at /mnt/repos/linux/lib/list_debug.c:53 __list_del_entry+0x63/0xd0() CPU: 12 PID: 10819 Comm: rmmod Not tainted 3.17.0-rc1 #19 Hardware name: FUJITSU-SV PRIMERGY BX920 S2/D3030, BIOS 080015 Rev.3D81.3030 02/10/2012 Call Trace: dump_stack+0x45/0x56 warn_slowpath_common+0x7d/0xa0 warn_slowpath_fmt+0x4c/0x50 __list_del_entry+0x63/0xd0 list_del+0xd/0x30 cleanup_one_si+0x2a/0x230 [ipmi_si] ipmi_pnp_remove+0x15/0x20 [ipmi_si] pnp_device_remove+0x24/0x40 __device_release_driver+0x7f/0xf0 driver_detach+0xb0/0xc0 bus_remove_driver+0x55/0xd0 driver_unregister+0x2c/0x50 pnp_unregister_driver+0x12/0x20 cleanup_ipmi_si+0xbc/0xf0 [ipmi_si] SyS_delete_module+0x132/0x1c0 system_call_fastpath+0x16/0x1b ---[ end trace 70b4377268f85c23 ]--- list_del in cleanup_one_si() fails because the smi_info is already removed when hotmod removing. When ipmi interface is removed by hotmod, smi_info is removed by cleanup_one_si(), but is is still set in drvdata. Therefore when rmmod ipmi_si, ipmi_pnp_remove tries to remove it again and fails. By this patch, a pointer to smi_info in drvdata is cleared when hotmod removing so that it will be not accessed when rmmod. changelog: v2: - Clear drvdata in cleanup_one_si - Change subject v1: https://lkml.org/lkml/2014/9/8/741Signed-off-by: NTakao Indoh <indou.takao@jp.fujitsu.com> Signed-off-by: NCorey Minyard <cminyard@mvista.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Arnd Bergmann 提交于
Building ipmi on arm with gcc-4.9 results in this warning for an allmodconfig build: drivers/char/ipmi/ipmi_si_intf.c: In function 'ipmi_thread': include/linux/time.h:28:5: warning: 'busy_until.tv_sec' may be used uninitialized in this function [-Wmaybe-uninitialized] if (lhs->tv_sec > rhs->tv_sec) ^ drivers/char/ipmi/ipmi_si_intf.c:1007:18: note: 'busy_until.tv_sec' was declared here struct timespec busy_until; ^ The warning is bogus and this case can not occur. Apparently this is a false positive resulting from gcc getting a little smarter about tracking assignments but not smart enough. Marking the ipmi_thread_busy_wait function as inline gives the gcc optimization logic enough information to figure out for itself that the case cannot happen, which gets rid of the warning without adding any fake initialization. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NCorey Minyard <cminyard@mvista.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Benjamin Herrenschmidt 提交于
If an IPMI controller is used by the firmware and as such marked with a reserved status, we shouldn't use it. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NCorey Minyard <cminyard@mvista.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Corey Minyard 提交于
The code to send the channel config errors was missing an error report in one place and needed some more information in another, and had an extraneous bit of code. Clean all that up. Signed-off-by: NCorey Minyard <cminyard@mvista.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 03 10月, 2014 8 次提交
-
-
由 Michael Opdenacker 提交于
This replaces http://git.linuxtv.org/v4l-utils/ (broken link) by http://git.linuxtv.org/cgit.cgi/v4l-utils.git/Signed-off-by: NMichael Opdenacker <michael.opdenacker@free-electrons.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Michael Heimpold 提交于
Signed-off-by: NMichael Heimpold <mhei@heimpold.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Christoph Hellwig 提交于
The uas driver uses the block layer tag for USB3 stream IDs. With blk-mq we can get larger tag numbers that the queue depth, which breaks this assumption. A fix is under way for 3.18, but sits on top of large changes so can't easily be backported. Set the disable_blk_mq path so that a uas device can't easily crash the system when using blk-mq for SCSI. Signed-off-by: NChristoph Hellwig <hch@lst.de> Acked-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
-
由 Andy Gross 提交于
The runtime pm calls need to be done before populating the children via the i2c_add_adapter call. If this is not done, a child can run into issues trying to do i2c read/writes due to the pm_runtime_sync failing. Signed-off-by: NAndy Gross <agross@codeaurora.org> Reviewed-by: NFelipe Balbi <balbi@ti.com> Acked-by: NBjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org
-
由 Alexandru M Stan 提交于
i2cdetect -q was broken (everything was a false positive, and no transfers were actually being sent over i2c). The way it works is by sending a 0 length write request and checking for NACK. This patch fixes the 0 length writes and actually sends them. Reported-by: NDoug Anderson <dianders@chromium.org> Signed-off-by: NAlexandru M Stan <amstan@chromium.org> Tested-by: NDoug Anderson <dianders@chromium.org> Tested-by: NMax Schwarz <max.schwarz@online.de> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org
-
由 Andy Shevchenko 提交于
Though intel-mid-dma does not follow a new DMA workflow (*) let's prepare SPI DW driver for that. (*) The client is obliged to call dma_async_issue_pending() which starts the actual transfers. Old DMA drivers do not follow this, since requirement was introduced in the discussion of [1]. [1] http://www.spinics.net/lists/arm-kernel/msg125987.htmlSigned-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Andy Shevchenko 提交于
Instead of direct dereference to dmaengine callbacks we are going to use DMAengine wrappers. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Andy Shevchenko 提交于
Instead of using magic numbers in the code we create a bit map definition of the DMACR register and use it. There is no functional change. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 02 10月, 2014 13 次提交
-
-
由 NeilBrown 提交于
It has come to my attention (thanks Martin) that 'discard_zeroes_data' is only a hint. Some devices in some cases don't do what it says on the label. The use of DISCARD in RAID5 depends on reads from discarded regions being predictably zero. If a write to a previously discarded region performs a read-modify-write cycle it assumes that the parity block was consistent with the data blocks. If all were zero, this would be the case. If some are and some aren't this would not be the case. This could lead to data corruption after a device failure when data needs to be reconstructed from the parity. As we cannot trust 'discard_zeroes_data', ignore it by default and so disallow DISCARD on all raid4/5/6 arrays. As many devices are trustworthy, and as there are benefits to using DISCARD, add a module parameter to over-ride this caution and cause DISCARD to work if discard_zeroes_data is set. If a site want to enable DISCARD on some arrays but not on others they should select DISCARD support at the filesystem level, and set the raid456 module parameter. raid456.devices_handle_discard_safely=Y As this is a data-safety issue, I believe this patch is suitable for -stable. DISCARD support for RAID456 was added in 3.7 Cc: Shaohua Li <shli@kernel.org> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: Mike Snitzer <snitzer@redhat.com> Cc: Heinz Mauelshagen <heinzm@redhat.com> Cc: stable@vger.kernel.org (3.7+) Acked-by: NMartin K. Petersen <martin.petersen@oracle.com> Acked-by: NMike Snitzer <snitzer@redhat.com> Fixes: 620125f2Signed-off-by: NNeilBrown <neilb@suse.de>
-
由 Ben Skeggs 提交于
Linus commit 05c63c2f modified the runtime suspend/resume paths to skip over display-related tasks to avoid locking issues on resume. Unfortunately, this resulted in the display hardware being left in a partially initialised state, preventing subsequent modesets from completing. This commit unifies the (many) suspend/resume paths, bringing back display (and fbcon) handling in the runtime paths. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Preparation for some runtime pm fixes. Currently we skip over fbcon suspend/resume in the runtime path, which causes issues on resume if fbcon tries to write to the framebuffer before the BAR subdev has been resumed to restore the BAR1 VM setup. As we might be woken up via a sysfs connector, we are unable to call fb_set_suspend() in the resume path as it could make its way down to a modeset and cause all sorts of locking hilarity. To solve this, we'll just delay the fbcon resume to a workqueue. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Xorg (and any non-DRM client really) doesn't have permission to directly touch VRAM on nv50 and up, which the fence code prior to g84 depends on. It's less invasive to temporarily grant it premission to do so, as it previously did, than it is to rework fencenv50 to use the VM. That will come later on. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Reported in fdo#82527 comment #2. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 hayeswang 提交于
The firmware would be clear when the power cut is enabled for RTL8153. Signed-off-by: NHayes Wang <hayeswang@realtek.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 hayeswang 提交于
The xxx_clear_bp() is used to halt the firmware. It only necessary for updating the new firmware. Besides, depend on the version of the current firmware, it may have problem to halt the firmware directly. Finally, halt the firmware would let the firmware code useless, and the bugs which are fixed by the firmware would occur. Signed-off-by: NHayes Wang <hayeswang@realtek.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Vlad Yasevich 提交于
This driver, similar to tg3, has a check that will cause full sized 802.1ad frames to be dropped. The frame will be larger then the standard mtu due to the presense of vlan header that has not been stripped. The driver should not drop this frame and should process it just like it does for 802.1q. CC: Sony Chacko <sony.chacko@qlogic.com> CC: Dept-HSGLinuxNICDev@qlogic.com Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Vlad Yasevich 提交于
When receiving a vlan-tagged frame that still contains a vlan header, the length of the packet will be greater then MTU+ETH_HLEN since it will account of the extra vlan header. TG3 checks this for the case for 802.1Q, but not for 802.1ad. As a result, full sized 802.1ad frames get dropped by the card. Add a check for 802.1ad protocol when receving full sized frames. Suggested-by: NPrashant Sreedharan <prashant@broadcom.com> CC: Prashant Sreedharan <prashant@broadcom.com> CC: Michael Chan <mchan@broadcom.com> Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Helge Deller 提交于
Fix the serial console on machines where the serial port is located on the SuperIO chip. Signed-off-by: NHelge Deller <deller@gmx.de> Cc: Peter Hurley <peter@hurleysoftware.com>
-
由 Benjamin Tissoires 提交于
When uhid_get_report() or uhid_set_report() are called, they emit on the char device a UHID_GET_REPORT or UHID_SET_REPORT message. Then, the protocol says that the user space asnwers with UHID_GET_REPORT_REPLY or UHID_SET_REPORT_REPLY. Unfortunatelly, the current code waits for an event of type UHID_GET_REPORT or UHID_SET_REPORT instead of the reply one. Add 1 to UHID_GET_REPORT or UHID_SET_REPORT to actually wait for the reply, and validate the reply. Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Greg Ungerer 提交于
The Armada SoC family implementation of this SPI hardware module has extended the configuration register to allow for a wider range of SPI clock rates. Specifically the Serial Baud Rate Pre-selection bits in the SPI Interface Configuration Register now also use bits 6 and 7 as well. Modify the baud rate calculation to handle these differences for the Armada case. Potentially a baud rate can be setup using a number of different pre-scalar and scalar combinations. This code tries all possible pre-scalar divisors (8 in total) to try and find the most accurate set. This change introduces (and documents) a new device tree compatible device name "armada-370-spi" to support this. Signed-off-by: NGreg Ungerer <gerg@uclinux.org> Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com> Reviewed-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Anish Bhatt 提交于
cxgbi_inet6addr_handler() can be called in interrupt context, so use rcu protected list while finding netdev. This is observed as a scheduling in atomic oops when running over ipv6. Fixes: fc8d0590 ("libcxgbi: Add ipv6 api to driver") Fixes: 759a0cc5 ("cxgb4i: Add ipv6 code to driver, call into libcxgbi ipv6 api") Signed-off-by: NAnish Bhatt <anish@chelsio.com> Signed-off-by: NKaren Xie <kxie@chelsio.com> Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
-
- 01 10月, 2014 10 次提交
-
-
由 Oliver Neukum 提交于
There is a second mouse sharing the same vendor strings but different IDs. Signed-off-by: NOliver Neukum <oneukum@suse.de> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Benjamin Tissoires 提交于
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: NJason Gerecke <killertofu@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Benjamin Tissoires 提交于
ISDv4 and v5 are plain HID devices. We can directly implement a generic HID parsing/handling and remove the need to manually add those PID in the list of supported devices. This patch implements the pen support only. The finger part will come in a later patch. To be properly notified of an .event() and a .report(), we need to force hid-core to go through the HID parsing. By default, wacom.ko binds only hidraw, so the hid parsing is not done by hid-core. When a true HID device is there, we add the flag HID_CLAIMED_DRIVER to hid->claimed which will force hid-core to parse the incoming reports. (Note that this can be easily backported by directly setting the .claimed flag to HID_CLAIMED_DRIVER even if hid-core does not support HID_CONNECT_DRIVER) Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: NJason Gerecke <killertofu@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Benjamin Tissoires 提交于
This allows to have the input devices ready in while parsing the reports descriptor. Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: NJason Gerecke <killertofu@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Benjamin Tissoires 提交于
If the input can be created earlier during probe, we can already populate them while reading the report descriptor. This way, we can rely on the hid subsystem directly for tablets which already provide a meaningful report descriptor (like ISDv4-5). This patch only splits the allocation and registration, but do not change where we allocate the input. This will come in a later patch. Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: NJason Gerecke <killertofu@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Benjamin Tissoires 提交于
When we have to deal with new elements in probe, having the exit labels named sequencially is a pain to maintain. Put a meaningful name instead so that we do not have to renumber them on inserts. Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: NJason Gerecke <killertofu@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 hayeswang 提交于
The flag of RTL8152_UNPLUG should only be set when the device is unplugged, not each time the rtl8152_disconnect() is called. Otherwise, the device wouldn't be stopped normally. Signed-off-by: NHayes Wang <hayeswang@realtek.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Manish Chopra 提交于
o Driver is not updating sw_consumer while processing Tx completion when interface is going down. Due to this interface down path gets stuck forever waiting for NAPI to complete. Signed-off-by: NManish Chopra <manish.chopra@qlogic.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Manish Chopra 提交于
o __netxen_nic_down() function might sleep while holding spinlock_t(tx_clean_lock). Acquire this lock for only releasing TX buffers instead of taking it for whole down path. Reported-by: NMike Galbraith <umgwanakikbuti@gmail.com> Signed-off-by: NManish Chopra <manish.chopra@qlogic.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Viresh Kumar 提交于
Commit 8e30444e ("cpufreq: fix cpufreq suspend/resume for intel_pstate") introduced a bug where the governors wouldn't be stopped anymore for ->target{_index}() drivers during suspend. This happens because 'cpufreq_suspended' is updated before stopping the governors during suspend and due to this __cpufreq_governor() would return early due to this check: /* Don't start any governor operations if we are entering suspend */ if (cpufreq_suspended) return 0; Fixes: 8e30444e ("cpufreq: fix cpufreq suspend/resume for intel_pstate") Cc: 3.15+ <stable@vger.kernel.org> # 3.15+: 8e30444e "cpufreq: fix cpufreq suspend/resume for intel_pstate" Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-