- 13 4月, 2015 1 次提交
-
-
由 Anand Moon 提交于
pwm_config() must be called with a duty cycle of 0 prior to calling pwm_disable() to ensure that the pwm signal is set to low. Reported-by: NMarkus Reichl <m.reichl@fivetechno.de> Tested-by: NMarkus Reichl <m.reichl@fivetechno.de> Reviewed-by: NLukasz Majewski <l.majewski@samsung.com> Reviewed-by: NSjoerd Simons <sjoerd.simons@collabora.co.uk> Signed-off-by: NAnand Moon <linux.amoon@gmail.com> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
- 12 4月, 2015 1 次提交
-
-
由 Linus Torvalds 提交于
This reverts commit ecc19d17. It added a new warning to try to encourage driver writers to set the device capabities properly, but drivers haven't been updated and in the meantime it just generaters a scary message that users cannot actually do anything about. Warnings like these are appropriate if you actually expect to fix the code that causes them. They are not appropriate for releases. Requested-by: NPeter Hurley <peter@hurleysoftware.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 11 4月, 2015 5 次提交
-
-
由 Felipe Balbi 提交于
Add missing directions, residue_granularity, srd_addr_widths and dst_addr_widths bitfields. Without those we will see a kernel WARN() when loading musb on am335x devices. Signed-off-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NVinod Koul <vinod.koul@intel.com>
-
由 Corey Minyard 提交于
The code was using an normal completion, but that caused stuck task errors after a while. Use an interruptible one to avoid that. Signed-off-by: NCorey Minyard <cminyard@mvista.com>
-
由 Alistair Popple 提交于
If ipmi_powernv_recv(...) is called without a current message it prints a warning and returns. However it fails to release the message lock causing the system to dead lock during any subsequent IPMI operations. This error path should never normally be taken unless there are bugs elsewhere in the system. Signed-off-by: NAlistair Popple <alistair@popple.id.au> Signed-off-by: NCorey Minyard <cminyard@mvista.com>
-
由 Corey Minyard 提交于
Some BMCs don't let you clear the receive irq bit in the global enables. This is kind of silly, but they give an error if you try to clear it. Compensate for this by detecting the situation and working around it. Signed-off-by: NCorey Minyard <cminyard@mvista.com> Tested-by: NThomas D <whissi@whissi.de> Reviewed-by: NThomas D <whissi@whissi.de>
-
由 Mike Christie 提交于
This fixes a oops due to a double list add when adding a reject PDU for iscsit_allocate_iovecs allocation failures. The cmd has already been added to the conn_cmd_list in iscsit_setup_scsi_cmd, so this has us call iscsit_reject_cmd. Note that for ERL0 the reject PDU is not actually sent, so this patch is not completely tested. Just verified we do not oops. The problem is the add reject functions return -1 which is returned all the way up to iscsi_target_rx_thread which for ERL0 will drop the connection. Signed-off-by: NMike Christie <michaelc@cs.wisc.edu> Cc: <stable@vger.kernel.org> # v3.10+ Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
-
- 10 4月, 2015 1 次提交
-
-
由 NeilBrown 提交于
Since commit 20d0189b in v3.14-rc1 RAID0 has performed incorrect calculations when the chunksize is not a power of 2. This happens because "sector_div()" modifies its first argument, but this wasn't taken into account in the patch. So restore that first arg before re-using the variable. Reported-by: NJoe Landman <joe.landman@gmail.com> Reported-by: NDave Chinner <david@fromorbit.com> Fixes: 20d0189b Cc: stable@vger.kernel.org (3.14 and later). Signed-off-by: NNeilBrown <neilb@suse.de>
-
- 09 4月, 2015 9 次提交
-
-
由 Guenter Roeck 提交于
Feature macros work on sio_data as well, so use them there. Reviewed-by: NJean Delvare <jdelvare@suse.de> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Guenter Roeck 提交于
Fix drivers/hwmon/ibmpowernv.c: In function 'get_logical_cpu': drivers/hwmon/ibmpowernv.c:121:3: error: implicit declaration of function 'get_hard_smp_processor_id' seen for some configurations, possibly if SMP is not configured. Fixes: 3df2f59f ("hwmon: (ibmpowernv) pretty print labels") Cc: Cédric Le Goater <clg@fr.ibm.com> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Nishanth Menon 提交于
Thermal framework may already be ready and cooling policies might already be functional when we are attempting to register gpio fan as a cooling device. This can be reproduced by changing probe order in which registration of various modules are done in a system. In such a case, kernel generates an oops since the data structures are not completely populated with the wrong assumption that thermal framework is not yet ready. Fix this by reordering the thermal framework registration to occur after hwmon registration of the fan is complete. Example kernel oops: [ 149.005828] Unable to handle kernel NULL pointer dereference at virtual address 0000008c [ 149.014369] pgd = ecf48000 [ 149.017204] [0000008c] *pgd=ac065831, *pte=00000000, *ppte=00000000 [ 149.023820] Internal error: Oops: 17 [#1] SMP ARM [ 149.028745] Modules linked in: gpio_fan(+) cpufreq_dt ipv6 evdev leds_gpio led_class omap_wdt phy_omap_usb2 rtc_palmas palmas_pwrbutton tmp102 ti_soc_thermal dwc3_omap thermal_sys extcon rtc_omap rtc_ds1307 hwmon [ 149.048629] CPU: 1 PID: 1183 Comm: modprobe Not tainted 4.0.0-rc7-next-20150407-00002-g7a82da074c99 #3 [ 149.058383] Hardware name: Generic DRA74X (Flattened Device Tree) [ 149.064763] task: edec1240 ti: ec0e0000 task.ti: ec0e0000 [ 149.070421] PC is at dev_driver_string+0x0/0x38 [ 149.075165] LR is at __dev_printk+0x24/0x70 [ 149.079540] pc : [<c03d6cd0>] lr : [<c03d72c4>] psr: 20000013 [ 149.079540] sp : ec0e1c28 ip : edec1240 fp : 00000000 [ 149.091568] r10: edf3eee0 r9 : 00000000 r8 : ffffffff [ 149.097040] r7 : edf3eea0 r6 : 00000034 r5 : 00000010 r4 : ec0e1c44 [ 149.103871] r3 : ec0e1c4c r2 : ec0e1c44 r1 : c079d800 r0 : 00000010 [ 149.110709] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 149.118182] Control: 10c5387d Table: acf4806a DAC: 00000015 [ 149.124198] Process modprobe (pid: 1183, stack limit = 0xec0e0218) [ 149.130673] Stack: (0xec0e1c28 to 0xec0e2000) [ 149.135235] 1c20: 60000013 c05e2ae0 00000000 edf3ec00 ec934a10 c03d73d4 ... [ 149.392230] 1fe0: befe1888 befe1878 00019418 b6ea08f0 80000010 00000003 00000000 00000000 [ 149.400798] [<c03d6cd0>] (dev_driver_string) from [<c03d72c4>] (__dev_printk+0x24/0x70) [ 149.409193] [<c03d72c4>] (__dev_printk) from [<c03d73d4>] (dev_warn+0x34/0x48) [ 149.416767] [<c03d73d4>] (dev_warn) from [<bf0f54fc>] (get_fan_speed_index+0x94/0xa4 [gpio_fan]) [ 149.425980] [<bf0f54fc>] (get_fan_speed_index [gpio_fan]) from [<bf0f5524>] (gpio_fan_get_cur_state+0x18/0x30 [gpio_fan]) [ 149.437476] [<bf0f5524>] (gpio_fan_get_cur_state [gpio_fan]) from [<bf02767c>] (thermal_zone_trip_update+0xe8/0x2a4 [thermal_sys]) [ 149.449794] [<bf02767c>] (thermal_zone_trip_update [thermal_sys]) from [<bf027844>] (step_wise_throttle+0xc/0x74 [thermal_sys]) [ 149.461832] [<bf027844>] (step_wise_throttle [thermal_sys]) from [<bf024ff4>] (handle_thermal_trip+0x5c/0x188 [thermal_sys]) [ 149.473603] [<bf024ff4>] (handle_thermal_trip [thermal_sys]) from [<bf0256c4>] (thermal_zone_device_update+0x94/0x108 [thermal_sys]) [ 149.486104] [<bf0256c4>] (thermal_zone_device_update [thermal_sys]) from [<bf026470>] (__thermal_cooling_device_register+0x2e8/0x374 [thermal_sys]) [ 149.499956] [<bf026470>] (__thermal_cooling_device_register [thermal_sys]) from [<bf0f58e4>] (gpio_fan_probe+0x350/0x4d0 [gpio_fan]) [ 149.512438] [<bf0f58e4>] (gpio_fan_probe [gpio_fan]) from [<c03db8a0>] (platform_drv_probe+0x48/0x98) [ 149.522109] [<c03db8a0>] (platform_drv_probe) from [<c03da30c>] (driver_probe_device+0x1b0/0x26c) [ 149.531399] [<c03da30c>] (driver_probe_device) from [<c03da45c>] (__driver_attach+0x94/0x98) [ 149.540238] [<c03da45c>] (__driver_attach) from [<c03d8bb0>] (bus_for_each_dev+0x54/0x88) [ 149.548814] [<c03d8bb0>] (bus_for_each_dev) from [<c03d9a34>] (bus_add_driver+0xdc/0x1d4) [ 149.557381] [<c03d9a34>] (bus_add_driver) from [<c03dac30>] (driver_register+0x78/0xf4) [ 149.565765] [<c03dac30>] (driver_register) from [<c0009784>] (do_one_initcall+0x80/0x1d8) [ 149.574340] [<c0009784>] (do_one_initcall) from [<c00c2278>] (do_init_module+0x5c/0x1b8) [ 149.582833] [<c00c2278>] (do_init_module) from [<c00c3bbc>] (load_module+0x1720/0x1dcc) [ 149.591212] [<c00c3bbc>] (load_module) from [<c00c43d0>] (SyS_finit_module+0x68/0x6c) [ 149.599418] [<c00c43d0>] (SyS_finit_module) from [<c000f3c0>] (ret_fast_syscall+0x0/0x4c) [ 149.607994] Code: 15830000 e1a00006 e28dd008 e8bd8070 (e590307c) Cc: Eduardo Valentin <edubezval@gmail.com> Fixes: b5cf88e4 ("(gpio-fan): Add thermal control hooks") Signed-off-by: NNishanth Menon <nm@ti.com> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Cédric Le Goater 提交于
The new OPAL device tree adds a few properties which can be used to add extra information on the sensor label. In the case of a cpu core sensor, the firmware exposes the physical identifier of the core in the "ibm,pir" property. The driver translates this identifier in a linux cpu number and prints out a range corresponding to the hardware threads of the core (as they share the same sensor). The numbering gives a hint on the localization of the core in the system (which socket, which chip). Signed-off-by: NCédric Le Goater <clg@fr.ibm.com> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Cédric Le Goater 提交于
Currently, sensors are only identified by their type and index. The new OPAL device tree can expose extra properties to identify some sensors by their name or location. This patch adds the creation of a new hwmon *_label attribute when such properties are detected. Signed-off-by: NCédric Le Goater <clg@fr.ibm.com> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Cédric Le Goater 提交于
The new OPAL device tree for sensors has a different layout and uses new property names, for the type and for the handler used to capture the sensor data. This patch modifies the ibmpowernv driver to support such a tree in a way preserving compatibility with older OPAL firmwares. This is achieved by changing the error path of the routine parsing an OPAL node name. The node is simply considered being from the new device tree layout and fallback values are used. Signed-off-by: NCédric Le Goater <clg@fr.ibm.com> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Cédric Le Goater 提交于
This should shorten a bit the code necessary to create a hmwon attribute. Signed-off-by: NCédric Le Goater <clg@fr.ibm.com> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Bart Van Assche 提交于
SCSI transport drivers and SCSI LLDs block a SCSI device if the transport layer is not operational. This means that in this state no requests should be processed, even if the REQ_PREEMPT flag has been set. This patch avoids that a rescan shortly after a cable pull sporadically triggers the following kernel oops: BUG: unable to handle kernel paging request at ffffc9001a6bc084 IP: [<ffffffffa04e08f2>] mlx4_ib_post_send+0xd2/0xb30 [mlx4_ib] Process rescan-scsi-bus (pid: 9241, threadinfo ffff88053484a000, task ffff880534aae100) Call Trace: [<ffffffffa0718135>] srp_post_send+0x65/0x70 [ib_srp] [<ffffffffa071b9df>] srp_queuecommand+0x1cf/0x3e0 [ib_srp] [<ffffffffa0001ff1>] scsi_dispatch_cmd+0x101/0x280 [scsi_mod] [<ffffffffa0009ad1>] scsi_request_fn+0x411/0x4d0 [scsi_mod] [<ffffffff81223b37>] __blk_run_queue+0x27/0x30 [<ffffffff8122a8d2>] blk_execute_rq_nowait+0x82/0x110 [<ffffffff8122a9c2>] blk_execute_rq+0x62/0xf0 [<ffffffffa000b0e8>] scsi_execute+0xe8/0x190 [scsi_mod] [<ffffffffa000b2f3>] scsi_execute_req+0xa3/0x130 [scsi_mod] [<ffffffffa000c1aa>] scsi_probe_lun+0x17a/0x450 [scsi_mod] [<ffffffffa000ce86>] scsi_probe_and_add_lun+0x156/0x480 [scsi_mod] [<ffffffffa000dc2f>] __scsi_scan_target+0xdf/0x1f0 [scsi_mod] [<ffffffffa000dfa3>] scsi_scan_host_selected+0x183/0x1c0 [scsi_mod] [<ffffffffa000edfb>] scsi_scan+0xdb/0xe0 [scsi_mod] [<ffffffffa000ee13>] store_scan+0x13/0x20 [scsi_mod] [<ffffffff811c8d9b>] sysfs_write_file+0xcb/0x160 [<ffffffff811589de>] vfs_write+0xce/0x140 [<ffffffff81158b53>] sys_write+0x53/0xa0 [<ffffffff81464592>] system_call_fastpath+0x16/0x1b [<00007f611c9d9300>] 0x7f611c9d92ff Reported-by: NMax Gurtuvoy <maxg@mellanox.com> Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com> Reviewed-by: NMike Christie <michaelc@cs.wisc.edu> Cc: <stable@vger.kernel.org> Signed-off-by: NJames Bottomley <JBottomley@Odin.com>
-
由 John Soni Jose 提交于
Kernel panic was happening as iscsi_host_remove() was called on a host which was not yet added. Signed-off-by: NJohn Soni Jose <sony.john-n@emulex.com> Reviewed-by: NMike Christie <michaelc@cs.wisc.edu> Cc: <stable@vger.kernel.org> Signed-off-by: NJames Bottomley <JBottomley@Odin.com>
-
- 08 4月, 2015 7 次提交
-
-
由 Bjorn Helgaas 提交于
Booting a v3.18 or newer Xen domU kernel with PCI devices passed through results in an oops (this is a 32-bit 3.13.11 dom0 with a 64-bit 4.4.0 hypervisor and 32-bit domU): BUG: unable to handle kernel paging request at 0030303e IP: [<c06ed0e6>] acpi_ns_validate_handle+0x12/0x1a Call Trace: [<c06eda4d>] ? acpi_evaluate_object+0x31/0x1fc [<c06b78e1>] ? pci_get_hp_params+0x111/0x4e0 [<c0407bc7>] ? xen_force_evtchn_callback+0x17/0x30 [<c04085fb>] ? xen_restore_fl_direct_reloc+0x4/0x4 [<c0699d34>] ? pci_device_add+0x24/0x450 Don't look for ACPI configuration information if ACPI has been disabled. I don't think this is the best fix, because we can boot plain Linux (no Xen) with "acpi=off", and we don't need this check in pci_get_hp_params(). There should be a better fix that would make Xen domU work the same way. The domU kernel has ACPI support but it has no AML. There should be a way to initialize the ACPI data structures so things fail gracefully rather than oopsing. This is an interim fix to address the regression. Fixes: 6cd33649 ("PCI: Add pci_configure_device() during enumeration") Link: https://bugzilla.kernel.org/show_bug.cgi?id=96301Reported-by: NMichael D Labriola <mlabriol@gdeb.com> Tested-by: NMichael D Labriola <mlabriol@gdeb.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.18+
-
由 Tommi Rantala 提交于
Regression in commit 2caa80e7 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Feb 22 11:38:36 2015 +0100 drm: Fix deadlock due to getconnector locking changes If the drm_connector_find() call returns NULL, we should no longer call drm_modeset_unlock() to avoid locking imbalance. Signed-off-by: NTommi Rantala <tt.rantala@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Gu Zheng 提交于
Simon reported the md io stats accounting issue: " I'm seeing "iostat -x -k 1" print this after a RAID1 rebuild on 4.0-rc5. It's not abnormal other than it's 3-disk, with one being SSD (sdc) and the other two being write-mostly: Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 md0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 345.00 0.00 0.00 0.00 0.00 100.00 md2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 58779.00 0.00 0.00 0.00 0.00 100.00 md1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 12.00 0.00 0.00 0.00 0.00 100.00 " The cause is commit "18c0b223" uses the generic_start_io_acct to account the disk stats rather than the open code, but it also introduced the increase to .in_flight[rw] which is needless to md. So we re-use the open code here to fix it. Reported-by: NSimon Kirby <sim@hostway.ca> Cc: <stable@vger.kernel.org> 3.19 Signed-off-by: NGu Zheng <guz.fnst@cn.fujitsu.com> Signed-off-by: NNeilBrown <neilb@suse.de>
-
由 Andy Grover 提交于
"The domainname can be specified as either a DNS host name, a dotted-decimal IPv4 address, or a bracketed IPv6 address as specified in [RFC2732]." See https://bugzilla.redhat.com/show_bug.cgi?id=1206868Reported-by: NKyle Brantley <kyle@averageurl.com> Signed-off-by: NAndy Grover <agrover@redhat.com> Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
-
由 Eduardo Valentin 提交于
Simple patch to make symbols static. Symbols that are not shared with other parts of the kernel can be made static. This change also removes several sparse complains. Cc: Zhang Rui <rui.zhang@intel.com> Cc: Lee Jones <lee.jones@linaro.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Ajit Pal Singh <ajitpal.singh@st.com> Cc: linux-pm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: NEduardo Valentin <edubezval@gmail.com>
-
由 Fabian Frederick 提交于
of_device_id is always used as const. (See driver.of_match_table and open firmware functions) Signed-off-by: NFabian Frederick <fabf@skynet.be> Signed-off-by: NEduardo Valentin <edubezval@gmail.com>
-
由 Hans de Goede 提交于
Some temperature sensors only get updated every few seconds and while waiting for the first irq reporting a (new) temperature to happen there get_temp operand will return -EAGAIN as it does not have any data to report yet. Not logging an error in this case avoids messages like these from showing up in dmesg on affected systems: [ 1.219353] thermal thermal_zone0: failed to read out thermal zone 0 [ 2.015433] thermal thermal_zone0: failed to read out thermal zone 0 [ 2.416737] thermal thermal_zone0: failed to read out thermal zone 0 Reviewed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NEduardo Valentin <edubezval@gmail.com>
-
- 07 4月, 2015 5 次提交
-
-
由 Jesse Barnes 提交于
Looks like it was introduced in: commit 650ad970 Author: Imre Deak <imre.deak@intel.com> Date: Fri Apr 18 16:35:02 2014 +0300 drm/i915: vlv: factor out vlv_force_gfx_clock and check for pending force-of but I'm not sure why. It has caused problems for us in the past (see 85250ddf "drm/i915/chv: Remove Wait for a previous gfx force-off" and 8d4eee9c "drm/i915: vlv: increase timeout when forcing on the GFX clock") and doesn't seem to be required, so let's just drop it. References: https://bugs.freedesktop.org/show_bug.cgi?id=89611Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Tested-by: NDarren Hart <dvhart@linux.intel.com> Reviewed-by: NDeepak S <deepak.s@linux.intel.com> Cc: stable@vger.kernel.org # c9c52e24: drm/i915/chv: Remove Wait ... Cc: stable@vger.kernel.org Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Deepak S 提交于
On CHV, PUNIT team confirmed that 'VLV_GFX_CLK_STATUS_BIT' is not a sticky bit and it will always be set. So ignore Check for previous Gfx force off during suspend and allow the force clk as part S0ix Sequence Signed-off-by: NDeepak S <deepak.s@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Jesse Barnes 提交于
Some BIOSes (e.g. the one on the Minnowboard) don't save/restore this reg. If it's unlocked, we can just restore the previous value, and if it's locked (in case the BIOS re-programmed it for us) the write will be ignored and we'll still have "did it move" sanity check in the PM code to warn us if something is still amiss. References: https://bugs.freedesktop.org/show_bug.cgi?id=89611Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Tested-by: NDarren Hart <dvhart@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NDeepak S <deepak.s@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Jack Morgenstein 提交于
Commit 1daa4303 ("net/mlx4_core: Deprecate error message at ConnectX-2 cards startup to debug") did the deprecation only for port 1 of the card. Need to deprecate for port 2 as well. Fixes: 1daa4303 ("net/mlx4_core: Deprecate error message at ConnectX-2 cards startup to debug") Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by: NAmir Vadai <amirv@mellanox.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Stas Sergeev 提交于
mvneta_adjust_link() is a callback for of_phy_connect() and should not be called directly. The result of calling it directly is as below: Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 06 4月, 2015 2 次提交
-
-
由 Hans de Goede 提交于
On V2 devices the DualPoint Stick reports bare packets, these should be reported via the "AlpsPS/2 ALPS DualPoint Stick" dev2 evdev node, which also has the INPUT_PROP_POINTING_STICK propbit set. Note that since there is no way to distinguish these packets from an external PS/2 mouse (insofar as these laptops have an external PS/2 port) this means that we will be reporting PS/2 mouse events via this evdev node too, as we've been doing in kernel 3.19 and older. This has been tested on a Dell Latitude D620 and a Dell Latitude E6400, which both have a V2 touchpad + a DualPoint Stick which reports bare packets. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Reviewed-by: NPali Rohár <pali.rohar@gmail.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Hans de Goede 提交于
Bare packets should be reported via the same evdev device independent on whether they are detected on the beginning of a packet or in the middle of a packet. This has been tested on a Dell Latitude E6400, where the DualPoint Stick reports bare packets, which get reported via dev3 when the touchpad is idle, and via dev2 when the touchpad and stick are used simultaneously. This commit fixes this inconsistency by always reporting bare packets via dev3. Note that since the come from a DualPoint Stick they really should be reported via dev2, this gets fixed in a later commit. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Reviewed-by: NPali Rohár <pali.rohar@gmail.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 05 4月, 2015 6 次提交
-
-
由 Guenter Roeck 提交于
IT8620E supports up to 6 fan tachometers. Reviewed-by: NJean Delvare <jdelvare@suse.de> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Guenter Roeck 提交于
IT8620E is mostly compatible to IT7828F. Add generic support for it. IT8620E supports up to 6 fan tachometers and 6 pwm controls. Support for the 6th tachometer and for the additional pwm controls are addded in separate patches. Reviewed-by: NJean Delvare <jdelvare@suse.de> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Guenter Roeck 提交于
IT8790E is a super-IO chip with three fan tachometers. It is mostly compatible to IT8728F, but only supports three fan tachometers instead of five. Reviewed-by: NJean Delvare <jdelvare@suse.de> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Guenter Roeck 提交于
On some chips, in7 is always an internal voltage sensor. Introduce feature flag to reflect this condition to simplify adding support for new chips. Reviewed-by: NJean Delvare <jdelvare@suse.de> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Guenter Roeck 提交于
ITE chips may have 'E', 'F', or both 'E' and 'F' suffixes. Introduce suffic configuration to the it87_devices structure to simplify adding new chips. Reviewed-by: NJean Delvare <jdelvare@suse.de> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Guenter Roeck 提交于
On chips with newer PWM control, the PWM frequency divider is 256 instead of 128. Since the base PWM frequency remained the same, the actual PWM frequency is half of what it used to be with the older PWM control mechanism. Reviewed-by: NJean Delvare <jdelvare@suse.de> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
- 03 4月, 2015 3 次提交
-
-
由 Thomas Schlichter 提交于
Fix a bug that leads to showing the name and description of C-state C0 as "<null>" in sysfs after the ACPI C-states changed (e.g. after AC->DC or DC->AC transition). The function poll_idle_init() in drivers/cpuidle/driver.c initializes the state 0 during cpuidle_register_driver(), so we better do not overwrite it again with '\0' during acpi_processor_cst_has_changed(). Signed-off-by: NThomas Schlichter <thomas.schlichter@web.de> Reviewed-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: 3.13+ <stable@vger.kernel.org> # 3.13+ Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Thomas Schlichter reports the following issue on his Samsung NC20: "The C-states C1 and C2 to the OS when connected to AC, and additionally provides the C3 C-state when disconnected from AC. However, the number of C-states shown in sysfs is fixed to the number of C-states present at boot. If I boot with AC connected, I always only see the C-states up to C2 even if I disconnect AC. The reason is commit 130a5f69 (ACPI / cpuidle: remove dev->state_count setting). It removes the update of dev->state_count, but sysfs uses exactly this variable to show the C-states. The fix is to use drv->state_count in sysfs. As this is currently the last user of dev->state_count, this variable can be completely removed." Remove dev->state_count as per the above. Reported-by: NThomas Schlichter <thomas.schlichter@web.de> Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com> Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org> Cc: 3.14+ <stable@vger.kernel.org> # 3.14+ [ rjw: Changelog ] Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Viresh Kumar 提交于
All CPUs leaving the first-online CPU are hotplugged out on suspend and and cpufreq core stops managing them. On resume, we need to call cpufreq_update_policy() for this CPU's policy to make sure its frequency is in sync with cpufreq's cached value, as it might have got updated by hardware during suspend/resume. The policies are always added to the top of the policy-list. So, in normal circumstances, CPU 0's policy will be the last one in the list. And so the code checks for the last policy. But there are cases where it will fail. Consider quad-core system, with policy-per core. If CPU0 is hotplugged out and added back again, the last policy will be on CPU1 :( To fix this in a proper way, always look for the policy of the first online CPU. That way we will be sure that we are calling cpufreq_update_policy() for the only CPU that wasn't hotplugged out. Cc: 3.15+ <stable@vger.kernel.org> # 3.15+ Fixes: 2f0aea93 ("cpufreq: suspend governors on system suspend/hibernate") Reported-by: NSaravana Kannan <skannan@codeaurora.org> Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org> Acked-by: NSaravana Kannan <skannan@codeaurora.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-