- 18 6月, 2015 2 次提交
-
-
由 Jason Gerecke 提交于
The USB devices that this driver has historically supported segregate the pen and touch portions of the tablet. Oftentimes the segregation would be done at the interface level, though on occasion (e.g. Cintiq 24HDT) the tablet would combine two totally independent USB devices behind an internal USB hub. Because pen and touch never shared the same interface, it made sense for the 'device_type' to store a single value: "pen" or "touch". Recently, however, some I2C devices have been created which combine the two. A first step to accomodating this is to expand 'device_type' so that it can represent two (or potentially more) types simultaneously. To do this, we treat it as a bitfield and set/check individual bits rather than using the '=' and '==' operators. This should not result in any functional change since no supported devices (that I'm aware of, at least) have HID descriptors that indicate both pen and touch reports on a single interface. Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Jason Gerecke 提交于
A little bit of cleanup work for 'wacom_update_name' to make it easier on the eyes. Creates a temporary 'name' variable on which we'll perform our edits. Once the name is in its final form, it will be copied (with appropriate suffix) to 'wacom_wac->name' and 'wacom_wac->pad_name'. Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 22 5月, 2015 2 次提交
-
-
由 Jason Gerecke 提交于
Hardware may not respond to a request for the HID_DG_CONTACTMAX feature and we should be tolerant of such a failure. This is especially true when using hid-replay where the hardware doesn't exist, but also for devices attached to a flaky bus. This patch increases the number of allowable retries to match other calls to 'wacom_get_report' and also provides a fallback which forces 'touch_max = 16' (enough for any Wacom device seen so far). Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com> Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Jason Gerecke 提交于
Retrying on -EPIPE makes very little sense since this typically indicates a problem that will not just disappear on its own. For instance, the USB documentation states that it will be sent if the endpoint is stalled or the device has disconnected. Instead, we should retry if -EAGAIN is received since this indicates a temporary error condition such as a busy bus. In addition to adjusting the conditions we retry under, we also log an error on failure so that we can be aware of what's going on. Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com> Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 04 5月, 2015 3 次提交
-
-
由 Jason Gerecke 提交于
The last patch was careful to maintain backwards-compatible behavior by forcing device_type to BTN_TOOL_PEN (and printing a warning) if it were still uninitialized after scanning the HID descriptor and applying quirks. We should be more strict with HID_GENERIC devices, however, since there is no a priori guarantee that it is a tablet or touchpad. If the device_type is still uninitialized for a HID_GENERIC device then we assume that it isn't something the driver can work with and so fail the probe. Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com> Reviewed-by: NPing Cheng <pingc@wacom.com> Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Jason Gerecke 提交于
Currently, we assume a device_type of BTN_TOOL_PEN before scanning the HID descriptor and then change the device_type if what we discover proves that assumption wrong. This way of doing things makes it more difficult to figure out if a device (particularly a HID_GENERIC device) actually does tablet/touch input or is something completley different. This patch leaves device_type at its initial value of 0 and then calls 'wacom_parse_hid' for every device (not just those that have touch). As we map the usages, we can set the device_type as before. After we're finished, we can then check if the value is still zero and do whatever is most appropriate. Detecting the pen can be a little tricky on most Wacom devices because the descriptors describe opaque blobs. Fortunately, older Wacom tablets have the HID_DG_DIGITIZER usage on the pen's application collection and newer tablets seem to have a similar vendor-defined usage that we can trigger on. Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com> Reviewed-by: NPing Cheng <pingc@wacom.com> Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Jason Gerecke 提交于
The naming logic currently assumes that all devices will be a pen, finger, or pad. Though this has historically been the case, the new HID_GENERIC catch-all may cause us to probe devices with Wacom's 056A VID which aren't any of these types (e.g. the "Cintiq 24HDT Monitor Control"). This patch updates the logic so that no suffix will be added to the device name if the device type is unknown. Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com> Reviewed-by: NPing Cheng <pingc@wacom.com> Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 27 4月, 2015 1 次提交
-
-
由 Ping Cheng 提交于
HID generic devices share the same default name, "Wacom HID". This causes userland programs to show same device names for different devices, which would confuse end users with same device names for different devices too. This patch uses name retrieved from HID descriptor, if a meaningful name is reported. Otherwise, affix its product ID to "Wacom HID". Names from descriptor may contain extra whitespaces. To comfort readers' eyes, we removed those extra whitespaces too. Signed-off-by: NPing Cheng <pingc@wacom.com> Reviewed-by: NJason Gerecke <killertofu@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 23 4月, 2015 5 次提交
-
-
由 Aaron Skomra 提交于
Signed-off-by: NAaron Skomra <aaron.skomra@wacom.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Jason Gerecke 提交于
To determine if a touch is present in the single-touch case, we can simply check if the BTN_TOUCH key is active or not. This will work for both HID_GENERIC and other device types. Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Ping Cheng 提交于
We use generic hid_report_len() to get individual packet length now. Signed-off-by: NPing Cheng <pingc@wacom.com> Reviewed-by: NJason Gerecke <jason.gerecke@wacom.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Ping Cheng 提交于
That is where they belong... Signed-off-by: NPing Cheng <pingc@wacom.com> Reviewed-by: NJason Gerecke <jason.gerecke@wacom.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Ping Cheng 提交于
It makes probe routine easy to follow. Signed-off-by: NPing Cheng <pingc@wacom.com> Reviewed-by: NJason Gerecke <jason.gerecke@wacom.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 15 4月, 2015 1 次提交
-
-
由 Krzysztof Kozlowski 提交于
Commit 297d716f ("power_supply: Change ownership from driver to core") inverted the logic in battery_notify(). As an effect already present battery was re-added on each system suspend or hibernation. WARNING: CPU: 0 PID: 303 at ../fs/sysfs/dir.c:31 sysfs_warn_dup+0x68/0x80() sysfs: cannot create duplicate filename '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/PNP0C0A:00/power_supply/BAT0' CPU: 0 PID: 303 Comm: rtcwake Not tainted 4.0.0-ARCH-02621-g07e6253af953 #48 Call Trace: sysfs_create_dir_ns+0x8d/0xa0 kobject_add_internal+0xb6/0x370 kobject_add+0x6f/0xd0 device_add+0x120/0x6c0 __power_supply_register+0x145/0x290 power_supply_register_no_ws+0x10/0x20 sysfs_add_battery+0x84/0xc5 [battery] battery_notify+0x45/0x6b [battery] notifier_call_chain+0x4f/0x80 __blocking_notifier_call_chain+0x4b/0x70 blocking_notifier_call_chain+0x16/0x20 pm_notifier_call_chain+0x1a/0x40 pm_suspend+0x3ed/0x4e0 Signed-off-by: NKrzysztof Kozlowski <k.kozlowski.k@gmail.com> Reported-by: NLinus Torvalds <torvalds@linux-foundation.org> Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-By: NSebastian Reichel <sre@kernel.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 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 9 次提交
-
-
由 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>
-
由 Srinivas Pandruvada 提交于
HID Sensor Spec defines two usage ids for custom sensors HID_USAGE_SENSOR_TYPE_OTHER_CUSTOM (0x09, 0xE1) HID_USAGE_SENSOR_TYPE_OTHER_GENERIC(0x09, 0xE2) In addition the standard also defines usage ids for custom fields. The purpose of these sensors is to extend the functionality or provide a way to obfuscate the data being communicated by a sensor. Without knowing the mapping between the data and its encapsulated form, it is difficult for an driver to determine what data is being communicated by the sensor. This allows some differentiating use cases, where vendor can provide applications. Since these can't be represented by standard sensor interfaces like IIO, we present these as fields with - type (input/output) - units - min/max - get/set value In addition an dev interface to transfer report events. Details about this interface is described in /Documentation/hid/hid-sensor.txt. Manufacturers should not use these ids for any standard sensors, otherwise the the product/vendor id can be added to black list. Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reviewed-by: NJonathan Cameron <jic23@kernel.org> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 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>
-
由 Martin Sperl 提交于
In cases of short transfer times the CPU is spending lots of time in the interrupt handler and scheduler to reschedule the worker thread. Measurements show that we have times where it takes 29.32us to between the last clock change and the time that the worker-thread is running again returning from wait_for_completion_timeout(). During this time the interrupt-handler is running calling complete() and then also the scheduler is rescheduling the worker thread. This time can vary depending on how much of the code is still in CPU-caches, when there is a burst of spi transfers the subsequent delays are in the order of 25us, so the value of 30us seems reasonable. With polling the whole transfer of 4 bytes at 10MHz finishes after 6.16us (CS down to up) with the real transfer (clock running) taking 3.56us. So the efficiency has much improved and is also freeing CPU cycles, reducing interrupts and context switches. Because of the above 30us seems to be a reasonable limit for polling. Signed-off-by: NMartin Sperl <kernel@martin.sperl.org> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Martin Sperl 提交于
Transforms the bcm-2835 native SPI-chip select to their gpio-cs equivalent. This allows for some support of some optimizations that are not possible due to HW-gliches on the CS line - especially filling the FIFO before enabling SPI interrupts (by writing to CS register) while the transfer is already in progress (See commit: e3a2be30) This patch also works arround some issues in bcm2835-pinctrl which does not set the value when setting the GPIO as output - it just sets up output and (typically) leaves the GPIO as low. When a fix for this is merged then this gpio_set_value can get removed from bcm2835_spi_setup. Signed-off-by: NMartin Sperl <kernel@martin.sperl.org> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Markus Pargmann 提交于
It is not necessary to have regulator init data for a regulator. This patch removes the necessity of this data and handles a NULL pointer properly. Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 10 4月, 2015 15 次提交
-
-
由 Jiri Kosina 提交于
In the unlikely case of hdev vanishing while hid_debug_events_read() was sleeping, we can't really break out of the case switch as with other cases, as on the way out we'll try to remove ourselves from the hdev waitqueue. Fix this by taking a shortcut exit path and avoiding cleanup that doesn't make sense in case hdev doesn't exist any more anyway. Reported-by: NJiri Slaby <jslaby@suse.cz> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Heiko Stübner 提交于
Voltage regulators can have (unregulated) current limits too, so we should probably output both voltage and current for all regulators. Holding the rdev->mutex actually conflicts with _regulator_get_current_limit but also is not really necessary, as the global regulator_list_mutex already protects us from the regulator vanishing while we go through the list. On the rk3288-firefly the summary now looks like: regulator use open bypass voltage current min max ------------------------------------------------------------------------------- vcc_sys 0 12 0 5000mV 0mA 5000mV 5000mV vcc_lan 1 1 0 3300mV 0mA 3300mV 3300mV ff290000.ethernet 0mV 0mV vcca_33 0 0 0 3300mV 0mA 3300mV 3300mV vcca_18 0 0 0 1800mV 0mA 1800mV 1800mV vdd10_lcd 0 0 0 1000mV 0mA 1000mV 1000mV [...] Suggested-by: NMark Brown <broonie@kernel.org> Signed-off-by: NHeiko Stuebner <heiko@sntech.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Heiko Stübner 提交于
On modern systems the regulator hierarchy can get quite long and nested with regulators supplying other regulators. In some cases when debugging it might be nice to get a tree of these regulators, their consumers and the regulation constraints in one go. To achieve this add a regulator_summary sysfs node, similar to clk_summary in the common clock framework, that walks the regulator list and creates a tree out of the regulators, their consumers and core per-regulator settings. On a rk3288-firefly the regulator_summary would for example look something like: regulator use open bypass value min max ----------------------------------------------------------------------- vcc_sys 0 12 0 5000mV 5000mV 5000mV vcc_lan 1 1 0 3300mV 3300mV 3300mV ff290000.ethernet 0mV 0mV vcca_33 0 0 0 3300mV 3300mV 3300mV vcca_18 0 0 0 1800mV 1800mV 1800mV vdd10_lcd 0 0 0 1000mV 1000mV 1000mV vccio_sd 0 0 0 3300mV 3300mV 3300mV vcc_20 0 3 0 2000mV 2000mV 2000mV vcc18_lcd 0 0 0 1800mV 1800mV 1800mV vcc_18 0 2 0 1800mV 1800mV 1800mV ff100000.saradc 0mV 0mV ff0d0000.dwmmc 1650mV 1950mV vdd_10 0 0 0 1000mV 1000mV 1000mV vdd_log 0 0 0 1100mV 1100mV 1100mV vcc_io 0 3 0 3300mV 3300mV 3300mV ff0f0000.dwmmc 3300mV 3400mV vcc_flash 1 1 0 1800mV 1800mV 1800mV ff0f0000.dwmmc 1700mV 1950mV vcc_sd 1 1 0 3300mV 3300mV 3300mV ff0c0000.dwmmc 3300mV 3400mV vcc_ddr 0 0 0 1200mV 1200mV 1200mV vdd_gpu 0 0 0 1000mV 850mV 1350mV vdd_cpu 0 1 0 900mV 850mV 1350mV cpu0 900mV 900mV vcc_5v 0 2 0 5000mV 5000mV 5000mV vcc_otg_5v 0 0 0 5000mV 5000mV 5000mV vcc_host_5v 0 0 0 5000mV 5000mV 5000mV regulator-dummy 0 0 0 0mV 0mV 0mV Signed-off-by: NHeiko Stuebner <heiko@sntech.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Chase Metzger 提交于
Ran checkpatch.pl on file and removed a warning about an unwanted space before a tab. Signed-off-by: NChase Metzger <chasemetzger15@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Gregory Herrero 提交于
msleep(USB_RESUME_TIMEOUT) must be done when the controller drives the resume. This is true after HPRT0_RES is written. Moreover, restore the delay after controller power is up. Signed-off-by: NGregory Herrero <gregory.herrero@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Peter Griffin 提交于
Some additional quirks need to be enabled now we support UHS modes. This avoids some spurious warnings like "Got data interrupt 0x00000002 even though no data operation was in progress" Testing on stih410-b2120 board achieves the following speeds with HS200 eMMC card. max-frequency = 200Mhz /dev/mmcblk0p1: Timing buffered disk reads: 270 MB in 3.02 seconds = 89.54 MB/sec max-frequency = 100Mhz root@debian-armhf:~# hdparm -t /dev/mmcblk0p1 /dev/mmcblk0p1: Timing buffered disk reads: 210 MB in 3.00 seconds = 70.00 MB/sec max-frequency = 50Mhz root@debian-armhf:~# hdparm -t /dev/mmcblk0p1 /dev/mmcblk0p1: Timing buffered disk reads: 118 MB in 3.00 seconds = 39.28 MB/sec This is better than the 3.10 kernel which achieves 77.59 MB/sec at 200Mhz clock (same board/soc/eMMC). Signed-off-by: NPeter Griffin <peter.griffin@linaro.org> Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com> Acked-by: NMaxime Coquelin <maxime.coquelin@st.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Peter Griffin 提交于
To allow UHS modes to work properly we need to provide the st specific set_uhs_signaling callback function. This function differs from the generic sdhci_set_uhs_signaling callback in that we need to configure the correct delay depending on the UHS mode, and also set the V18_EN bit. Signed-off-by: NPeter Griffin <peter.griffin@linaro.org> Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com> Acked-by: NMaxime Coquelin <maxime.coquelin@st.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Peter Griffin 提交于
STiH407 family SoC's have glue registers in the flashSS subsystem which are used to configure the Arasan HC. This patch configures these glue registers according to what has been specified in the DT. Signed-off-by: NPeter Griffin <peter.griffin@linaro.org> Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com> Acked-by: NMaxime Coquelin <maxime.coquelin@st.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Peter Griffin 提交于
Due to the tight timing constraints in some UHS modes, it is required to have some delay management in the design. Two types of delay management are supported in the HW: - 1) Static delay management 2) Dynamic delay management NB: The delay management is only there when eMMC interface is selected. 1: Static delay management: is used to provide PVT dependent static delay on the clock/data lines to manage setup/hold requirements of the interface. The maximum delay possible is 3.25ns. These delays are PVT dependent, and thus delay values applied are not accurate and vary across provcess voltage and temperature range. Due to this these delays must not be used on the very time critical paths. 2. Dynamic delay locked loop (DLL): is used to provide dynamic delay management. The advantage of DLL is that it provides accurate & PVT indepedent delay. The DLL is used to provide delay on the loopback clock on "Read Path" to capture read data reliably. On TX path the clock on which output data is transmitted is delayed, resulting in delay of TX data. Signed-off-by: NPeter Griffin <peter.griffin@linaro.org> Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Peter Griffin 提交于
STiH407 family SoC's can have a reset signal for the controller which needs to be managed. Also the eMMC controller has some additional 'top' memory mapped registers which are used to manage the dynamic and static delay required for UHS modes. This patch adds support for creating the mapping, which will be used by subsequent patches. Signed-off-by: NPeter Griffin <peter.griffin@linaro.org> Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com> Acked-by: NMaxime Coquelin <maxime.coquelin@st.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Peter Griffin 提交于
The stih407 family SoC's have additional glue registers in the flashSS which are used to configure the Arasan controller. This patch adds macros for the register offsets and bitfields which will be used by subsequent patches to support stih407 family SoC's. Signed-off-by: NPeter Griffin <peter.griffin@linaro.org> Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com> Acked-by: NMaxime Coquelin <maxime.coquelin@st.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 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>
-
由 Sean O. Stalley 提交于
Reading both the capability ID and "next" pointer at the same time lets us parse the list with half the number of config reads. Signed-off-by: NSean O. Stalley <sean.stalley@intel.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
devm_ioremap_resource() validates the resource it receives, so if we check for devm_ioremap_resource() failure, we need not check for failure of the preceding platform_get_resource(). Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
Check for failure from platform_get_resource() (this check actually happens inside devm_ioremap_resource()) before dereferencing the pointer returned from platform_get_resource(). Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-