- 12 4月, 2016 1 次提交
-
-
由 Jerry Hoemann 提交于
The ACPI specification states that arguments "Revision ID" and "Function Index" to a _DSM are type "Integer." Type Integers are 64 bit quantities. The function evaluate_dsm specifies these types as simple "int" which are 32 bits. Widen type passed to acpi_evaluate_dsm and its callers and derived callers to pass correct type. acpi_check_dsm and acpi_evaluate_dsm_typed had similar issue and were corrected as well. This is in preparation for libnvdimm implementing a generic _DSM passthrough facility to have the capacity to pass 64-bit values as the ACPI specification allows. [djbw: clarify the changelog, add rationale] Signed-off-by: NJerry Hoemann <jerry.hoemann@hpe.com> Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: NDan Williams <dan.j.williams@intel.com>
-
- 09 4月, 2016 3 次提交
-
-
由 Wolfram Sang 提交于
Make sure we avoid a division-by-zero OOPS in case clock-frequency is set too low in DT. Add missing '\n' while we are here. Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Acked-by: NAxel Lin <axel.lin@ingics.com>
-
由 Wolfram Sang 提交于
This reverts commit 34cf2acd. 'ret' is not set when bailing out. Also, there is a better place to check for 0. Reported-by: NAxel Lin <axel.lin@ingics.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Jason Wang 提交于
After commit f84bb1ea ("net: fix IFF_NO_QUEUE for drivers using alloc_netdev"), default qdisc was changed to noqueue because tuntap does not set tx_queue_len during .setup(). This patch restores default qdisc by setting tx_queue_len in tun_setup(). Fixes: f84bb1ea ("net: fix IFF_NO_QUEUE for drivers using alloc_netdev") Cc: Phil Sutter <phil@nwl.cc> Signed-off-by: NJason Wang <jasowang@redhat.com> Acked-by: NMichael S. Tsirkin <mst@redhat.com> Acked-by: NPhil Sutter <phil@nwl.cc> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 08 4月, 2016 23 次提交
-
-
由 Yong Li 提交于
The current implementation only uses the first byte in val, the second byte is always 0. Change it to use cpu_to_le16 to write the two bytes into the register Cc: stable@vger.kernel.org Signed-off-by: NYong Li <sdliyong@gmail.com> Reviewed-by: NPhil Reid <preid@electromag.com.au> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Guenter Roeck 提交于
Since commit ff2b1359 ("gpio: make the gpiochip a real device"), attempts to add a gpio chip prior to gpiolib initialization cause the system to crash. This happens because gpio_bus_type has not been registered yet. Defer creating gpio devices until after gpiolib has been initialized to fix the problem. Cc: Greg Ungerer <gerg@uclinux.org> Cc: Alexandre Courbot <gnurou@gmail.com> Fixes: ff2b1359 ("gpio: make the gpiochip a real device") Signed-off-by: NGuenter Roeck <linux@roeck-us.net> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Guenter Roeck 提交于
It is possible that a gpio chip is registered before the gpiolib initialization code has run. This means we can not use devm_ functions to allocate memory at that time. Do it the old fashioned way. Cc: Alexandre Courbot <gnurou@gmail.com> Cc: Greg Ungerer <gerg@uclinux.org> Signed-off-by: NGuenter Roeck <linux@roeck-us.net> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Robert Jarzmik 提交于
In legacy pxa builds, ie. non device-tree and platform-data only builds, pinctrl is not yet available. As a consequence, the pinctrl gpio direction change function is a stub, returning always success. In the current state, the gpio driver direction function believes the pinctrl direction change was successful, and exits without actually changing the gpio direction. This patch changes the logic : - if the pinctrl direction function fails, gpio direction will report that failure - if the pinctrl direction function succeeds, gpio direction is changed by the gpio driver anyway. This is sub optimal in the pinctrl aware case, as the gpio direction will be changed twice: once by pinctrl function and another time by the gpio direction function. Yet it should be acceptable in this form, as this is functional for all pxa platforms (device-tree and platform-data), and moreover changing a gpio direction is very very seldom, usually in machine initialization, seldom in drivers probe, and an exception for ac97 reset bug. Fixes: a770d946 ("gpio: pxa: add pin control gpio direction and request") Reported-by: NGuenter Roeck <guenter@roeck-us.net> Tested-by: NGuenter Roeck <guenter@roeck-us.net> Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Dmitry Torokhov 提交于
When firmware does not use _DSD properties that allow properly name GPIO resources, the kernel falls back on parsing _CRS resources, and will return entries described as GpioInt() as general purpose GPIOs even though they are meant to be used simply as interrupt sources for the device: Device (ETSA) { Name (_HID, "ELAN0001") ... Method(_CRS, 0x0, NotSerialized) { Name(BUF0,ResourceTemplate () { I2CSerialBus( 0x10, /* SlaveAddress */ ControllerInitiated, /* SlaveMode */ 400000, /* ConnectionSpeed */ AddressingMode7Bit, /* AddressingMode */ "\\_SB.I2C1", /* ResourceSource */ ) GpioInt (Edge, ActiveLow, ExclusiveAndWake, PullNone,, "\\_SB.GPSW") { BOARD_TOUCH_GPIO_INDEX } } ) Return (BUF0) } ... } This gives troubles with drivers such as Elan Touchscreen driver (elants_i2c) that uses devm_gpiod_get to look up "reset" GPIO line and decide whether the driver is responsible for powering up and resetting the device, or firmware is. In the above case the lookup succeeds, we map GPIO as output and later fail to request client->irq interrupt that is mapped to the same GPIO. Let's ignore resources described as GpioInt() while parsing _CRS when requesting output GPIOs (but allow them when requesting GPIOD_ASIS or GPIOD_IN as some drivers, such as i2c-hid, do request GPIO as input and then map it to interrupt with gpiod_to_irq). Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NDmitry Torokhov <dtor@chromium.org> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Dan Williams 提交于
When section alignment padding is in effect we need to shift / truncate the range that is queried for poison by the 'start_pad' or 'end_trunc' reservations. It's easiest if we just pass in an adjusted resource range rather than deriving it from the passed in namespace. With the resource range resolution pushed out to the caller we can also push the namespace-to-region lookup to the caller and drop the implicit pmem-type assumption about the passed in namespace object. Cc: Vishal Verma <vishal.l.verma@intel.com> Signed-off-by: NDan Williams <dan.j.williams@intel.com>
-
由 Dan Williams 提交于
If we detect a namespace has a stale info block in the init path, we should overwrite with the latest configuration. In fact, we already return -ENODEV when the parent uuid is invalid, the same should be done for the 'self' uuid. Otherwise we can get into a condition where userspace is unable to reconfigure the pfn-device without directly / manually invalidating the info block. Cc: <stable@vger.kernel.org> Reported-by: NJeff Moyer <jmoyer@redhat.com> Signed-off-by: NDan Williams <dan.j.williams@intel.com>
-
由 Dan Williams 提交于
It appears that smart data retrieval has been broken the since the initial implementation. Fix the payload size to be 128-bytes per the specification. Cc: <stable@vger.kernel.org> Signed-off-by: NDan Williams <dan.j.williams@intel.com>
-
由 Bart Van Assche 提交于
This reverts commit 0fd10721. That patch causes the ib_srpt driver to crash as soon as the first SCSI command is received: kernel BUG at drivers/infiniband/ulp/srpt/ib_srpt.c:1439! invalid opcode: 0000 [#1] SMP Workqueue: target_completion target_complete_ok_work [target_core_mod] RIP: srpt_queue_response+0x437/0x4a0 [ib_srpt] Call Trace: srpt_queue_data_in+0x9/0x10 [ib_srpt] target_complete_ok_work+0x152/0x2b0 [target_core_mod] process_one_work+0x197/0x480 worker_thread+0x49/0x490 kthread+0xea/0x100 ret_from_fork+0x22/0x40 Aside from the crash, the shortcomings of that patch are as follows: - It makes the ib_srpt driver use I/O contexts allocated by transport_alloc_session_tags() but it does not initialize these I/O contexts properly. All the initializations performed by srpt_alloc_ioctx() are skipped. - It swaps the order of the send ioctx allocation and the transition to RTR mode which is wrong. - The amount of memory that is needed for I/O contexts is doubled. - srpt_rdma_ch.free_list is no longer used but is not removed. Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com> Cc: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Strashko, Grygorii 提交于
Now wakeirq stops working for device if wakeup option for this device will be reconfigured through sysfs, like: echo disabled > /sys/devices/platform/extcon_usb1/power/wakeup echo enabled > /sys/devices/platform/extcon_usb1/power/wakeup Once above set of commands is executed the device's wakeup_source opject will be recreated and dev->power.wakeup->wakeirq field will contain NULL. As result, device_wakeup_arm_wake_irqs() will not arm wakeirq for the affected device. Hece, lets try to fix it in the following way: check for dev->wakeirq field when device_wakeup_attach() is called and if !NULL re-attach wakeirq to the device Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com> Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Len Brown 提交于
KBL is similar to SKL Signed-off-by: NLen Brown <len.brown@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Len Brown 提交于
SKX is similar to BDX Signed-off-by: NLen Brown <len.brown@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Richard Cochran 提交于
This driver registers cpuidle devices when a CPU comes online, but it leaves the registrations in place when a CPU goes offline. The module exit code only unregisters the currently online CPUs, leaving the devices for offline CPUs dangling. This patch changes the driver to clean up all registrations on exit, even those from CPUs that are offline. Signed-off-by: NRichard Cochran <rcochran@linutronix.de> Signed-off-by: NLen Brown <len.brown@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Richard Cochran 提交于
If a cpuidle registration error occurs during the hot plug notifier callback, we should really inform the hot plug machinery instead of just ignoring the error. This patch changes the callback to properly return on error. Signed-off-by: NRichard Cochran <rcochran@linutronix.de> Signed-off-by: NLen Brown <len.brown@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Richard Cochran 提交于
The helper function, intel_idle_cpu_init, registers one new device with the cpuidle layer. If the registration should fail, that function immediately calls intel_idle_cpuidle_devices_uninit() to unregister every last CPU's device. However, it makes no sense to do so, when called from the hot plug notifier callback. This patch moves the call to intel_idle_cpuidle_devices_uninit() outside of the helper function to the one call site that actually needs to perform the de-registrations. Signed-off-by: NRichard Cochran <rcochran@linutronix.de> Signed-off-by: NLen Brown <len.brown@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Richard Cochran 提交于
This driver sets the broadcast tick quite early on during probe and does not clean up again in cast of failure. This patch moves the setup call after the registration, placing the on_each_cpu() calls within the global CPU lock region. Signed-off-by: NRichard Cochran <rcochran@linutronix.de> Signed-off-by: NLen Brown <len.brown@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Richard Cochran 提交于
The helper function, intel_idle_cpuidle_devices_uninit, frees the globally allocated per-CPU data. However, this function is invoked from the hot plug notifier callback at a time when freeing that data is not safe. If the call to cpuidle_register_driver() should fail (say, due to lack of memory), then the driver will free its per-CPU region. On the *next* CPU_ONLINE event, the driver will happily use the region again and even free it again if the failure repeats. This patch fixes the issue by moving the call to free_percpu() outside of the helper function at the two call sites that actually need to free the per-CPU data. Signed-off-by: NRichard Cochran <rcochran@linutronix.de> Signed-off-by: NLen Brown <len.brown@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Richard Cochran 提交于
In the module_init() method, if the per-CPU allocation fails, then the active cpuidle registration is not cleaned up. This patch fixes the issue by attempting the allocation before registration, and then cleaning it up again on registration failure. Signed-off-by: NRichard Cochran <rcochran@linutronix.de> Signed-off-by: NLen Brown <len.brown@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Richard Cochran 提交于
In the module_exit() method, this driver first frees its per-CPU pointer, then unregisters a callback making use of the pointer. Furthermore, the function, intel_idle_cpuidle_devices_uninit, is racy against CPU hot plugging as it calls for_each_online_cpu(). This patch corrects the issues by unregistering first on the exit path while holding the hot plug lock. Signed-off-by: NRichard Cochran <rcochran@linutronix.de> Signed-off-by: NLen Brown <len.brown@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Richard Cochran 提交于
The function, intel_idle_cpuidle_driver_init, makes calls on each CPU to auto_demotion_disable() and c1e_promotion_disable(). These calls are redundant, as intel_idle_cpu_init() does the same calls just a bit later on. They are also premature, as the driver registration may yet fail. This patch removes the redundant code. Signed-off-by: NRichard Cochran <rcochran@linutronix.de> Signed-off-by: NLen Brown <len.brown@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Richard Cochran 提交于
The function, intel_idle_cpuidle_driver_init, delivers no error codes at all. This patch changes the function to return 'void' instead of returning zero. Signed-off-by: NRichard Cochran <rcochran@linutronix.de> Signed-off-by: NLen Brown <len.brown@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Richard Cochran 提交于
Signed-off-by: NRichard Cochran <rcochran@linutronix.de> Signed-off-by: NLen Brown <len.brown@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Wolfram Sang 提交于
Make sure we don't OOPS in case clock-frequency is set to 0 in a DT. The variable set here is later used as a divisor. Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 07 4月, 2016 12 次提交
-
-
由 Dan Carpenter 提交于
My static checker complains that "dma_alias" is uninitialized unless we are dealing with a pci device. This is true but harmless. Anyway, we can flip the condition around to silence the warning. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 John Keeping 提交于
Since commit cd6438c5 ("iommu/rockchip: Reconstruct to support multi slaves") rk_iommu_is_stall_active() always returns false because the bitwise AND operates on the boolean flag promoted to an integer and a value that is either zero or BIT(2). Explicitly convert the right-hand value to a boolean so that both sides are guaranteed to be either zero or one. rk_iommu_is_paging_enabled() does not suffer from the same problem since RK_MMU_STATUS_PAGING_ENABLED is BIT(0), but let's apply the same change for consistency and to make it clear that it's correct without needing to lookup the value. Fixes: cd6438c5 ("iommu/rockchip: Reconstruct to support multi slaves") Signed-off-by: NJohn Keeping <john@metanate.com> Reviewed-by: NHeiko Stuebner <heiko@sntech.de> Tested-by: NTomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Joerg Roedel 提交于
IOMMU drivers that do not support default domains, but make use of the the group->domain pointer can get that pointer overwritten with NULL on device add/remove. Make sure this can't happen by only overwriting the domain pointer when it is NULL. Cc: stable@vger.kernel.org # v4.4+ Fixes: 1228236d ('iommu: Move default domain allocation to iommu_group_get_for_dev()') Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Gabriel Somlo 提交于
Allowing for the future possibility of implementing AML-based (i.e., firmware-triggered) access to the QEMU fw_cfg device, acquire the global ACPI lock when accessing the device on behalf of the guest-side sysfs driver, to prevent any potential race conditions. Suggested-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NGabriel Somlo <somlo@cmu.edu> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Michael S. Tsirkin 提交于
The spec says: after writing 0 to device_status, the driver MUST wait for a read of device_status to return 0 before reinitializing the device. Cc: stable@vger.kernel.org Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Acked-by: NJason Wang <jasowang@redhat.com>
-
由 Michael S. Tsirkin 提交于
If platform_driver_register fails, we should cleanup fw_cfg_top_ko before exiting. Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Acked-by: NGabriel Somlo <somlo@cmu.edu>
-
由 Bjørn Mork 提交于
Thomas reports: "Windows: 00 diagnostics 01 modem 02 at-port 03 nmea 04 nic Linux: T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2001 ProdID=7e19 Rev=02.32 S: Manufacturer=Mobile Connect S: Product=Mobile Connect S: SerialNumber=0123456789ABCDEF C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan I: If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage" Reported-by: NThomas Schäfer <tschaefer@t-online.de> Cc: <stable@vger.kernel.org> Signed-off-by: NBjørn Mork <bjorn@mork.no> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Martyn Welch 提交于
The CP2105 is used in the GE Healthcare Remote Alarm Box, with the Manufacturer ID of 0x1901 and Product ID of 0x0194. Signed-off-by: NMartyn Welch <martyn.welch@collabora.co.uk> Cc: stable <stable@vger.kernel.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Josh Boyer 提交于
A Fedora user reports that the ftdi_sio driver works properly for the ICP DAS I-7561U device. Further, the user manual for these devices instructs users to load the driver and add the ids using the sysfs interface. Add support for these in the driver directly so that the devices work out of the box instead of needing manual configuration. Reported-by: <thesource@mail.ru> CC: stable <stable@vger.kernel.org> Signed-off-by: NJosh Boyer <jwboyer@fedoraproject.org> Signed-off-by: NJohan Hovold <johan@kernel.org>
-
由 Shanker Donthineni 提交于
The acpi_pcc_probe() may end up accessing memory outside of the PCCT table space causing the kernel panic(). Increment the pcct_entry pointer after parsing 'HW-reduced Communications Subspace' to fix the problem. This change also enables the parsing of subtable at index 0. Signed-off-by: NShanker Donthineni <shankerd@codeaurora.org> Acked-by: NAshwin Chaugule <ashwin.chaugule@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Giuseppe CAVALLARO 提交于
While initializing the phy, the stmmac driver sets the PHY_IGNORE_INTERRUPT so the PAL won't call the adjust hook that is needed, on some platforms, e.g. STi, to invoke the glue. The patch allows the PAL to poll the stmmac_adjust_link just one time in case of a switch is attached, setting later the PHY_IGNORE_INTERRUPT flag. Moving this kind of logic inside the adjust_link it makes sense to anticipate the check for EEE that will never initialized in this scenario. Reported-by: NGabriel Fernandez <gabriel.fernandez@linaro.org> Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com> Tested-by: NGabriel Fernandez <gabriel.fernandez@linaro.org> Cc: Alexandre TORGUE <alexandre.torgue@st.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Hariprasad Shenai 提交于
Signed-off-by: NHariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 06 4月, 2016 1 次提交
-
-
由 Arnd Bergmann 提交于
gcc finds that the i40iw_make_cm_node() function in the recently added i40iw driver uses an uninitilized variable as an index into an array if CONFIG_IPV6 is disabled and the driver uses IPv6 mode: drivers/infiniband/hw/i40iw/i40iw_cm.c: In function 'i40iw_make_cm_node': drivers/infiniband/hw/i40iw/i40iw_cm.c:2206:52: error: 'arpindex' may be used uninitialized in this function [-Werror=maybe-uninitialized] ether_addr_copy(cm_node->rem_mac, iwdev->arp_table[arpindex].mac_addr); As far as I can tell, this code path can not be used because the ipv4 variable is always set with CONFIG_IPV6 is disabled, but it's better to be sure and prevent the undefined behavior, as well as shut up that warning in a proper way. This adds an 'else' clause for the case we get the warning about, causing the function to return an error in a controlled way. To avoid adding extra mess with combined io()/#ifdef clauses, I'm also converting the existing #ifdef into a more readable if(IS_ENABLED()) check. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Fixes: f27b4746 ("i40iw: add connection management code") Acked-by: NMustafa Ismail <Mustafa.ismail@intel.com> Signed-off-by: NDoug Ledford <dledford@redhat.com>
-