The tty3270_close function set tty->driver_data to NULL after the
open count dropped to zero but tty3270_cleanup still needs the
pointer to the tty3270 view to drop the reference count.
Move the clearing of tty->driver_data to tty3270_cleanup and
drop the unnecessary tty_port_tty_set calls in tty3270_install.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
The tty3270_resize_work functions acquires a reference to the tty
to call tty_do_resize but fails to release the reference again.
Add the missing tty_kref_put.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Implement return_address() and use it instead of __builtin_return_address(n).
__builtin_return_address(n) is not guaranteed to work for n > 0,
therefore implement a private return_address() function which walks
the stack frames and returns the proper return address.
This way we get also rid of a compile warning which gcc 6.1 emits and
look like all other architectures.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
This fixes a simple typo in one of the comments.
Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
We were calling dma_release_channel(rs->dma_tx.ch) when "rs->dma_tx.ch"
is potentially NULL. There is actually a call to that in the unwind
code at the bottom of the function so we can just re-arrange this a bit
and remove the call. Also there is no need to set rs->dma_tx.ch to
NULL on this error path.
Fixes: e4c0e06f94 ('spi: rockchip: fix probe deferral handling')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Embarrassingly while fixing up the old paths for i915 I managed to
misplace a locking check for the new _unlocked paths. That's what I
get for not retesting on radeon.
Fixes: 9f0ba539d1 ("drm/gem: support BO freeing without dev->struct_mutex")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
The if pclk enable fails the refclk is not disabled.
Fix the same.
Signed-off-by: Shubhrajyoti Datta <shubhraj@xilinx.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add even more ZTE device ids.
Signed-off-by: lei liu <liu.lei78@zte.com.cn>
Cc: stable <stable@vger.kernel.org>
[johan: rebase and replace commit message ]
Signed-off-by: Johan Hovold <johan@kernel.org>
After commit 8fa520af50 "intel_pstate: Remove freq calculation from
intel_pstate_calc_busy()" intel_pstate_get() calls get_avg_frequency()
to compute the average frequency, which is problematic for two reasons.
First, intel_pstate_get() may be invoked before the driver reads the
CPU feedback registers for the first time and if that happens,
get_avg_frequency() will attempt to divide by zero.
Second, the get_avg_frequency() call in intel_pstate_get() is racy
with respect to intel_pstate_sample() and it may end up returning
completely meaningless values for this reason.
Moreover, after commit 7349ec0470 "intel_pstate: Move
intel_pstate_calc_busy() into get_target_pstate_use_performance()"
sample.core_pct_busy is never computed on Atom, but it is used in
intel_pstate_adjust_busy_pstate() in that case too.
To address those problems notice that if sample.core_pct_busy
was used in the average frequency computation carried out by
get_avg_frequency(), both the divide by zero problem and the
race with respect to intel_pstate_sample() would be avoided.
Accordingly, move the invocation of intel_pstate_calc_busy() from
get_target_pstate_use_performance() to intel_pstate_update_util(),
which also will take care of the uninitialized sample.core_pct_busy
on Atom, and modify get_avg_frequency() to use sample.core_pct_busy
as per the above.
Reported-by: kernel test robot <ying.huang@linux.intel.com>
Link: http://marc.info/?l=linux-kernel&m=146226437623173&w=4
Fixes: 8fa520af50 "intel_pstate: Remove freq calculation from intel_pstate_calc_busy()"
Fixes: 7349ec0470 "intel_pstate: Move intel_pstate_calc_busy() into get_target_pstate_use_performance()"
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
commit 61b914eb81f8 ("mmc: sdhci-of-arasan: add phy support for
sdhci-of-arasan") introduce phy support for arasan. According to
the vendor's databook, we should make sure the phy is in poweroff
status before we configure the clk stuff. Otherwise it may cause
some IO sample timing issues from the test. And we don't need this
extra operation while running in low performance mode since phy
doesn't trigger sampling block.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
With the new dma_request_chan() the client driver does not need to look for
the DMA resource and it does not need to pass filter_fn anymore.
By switching to the new API the driver can now support deferred probing
against DMA.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
CC: Ulf Hansson <ulf.hansson@linaro.org>
CC: Jarkko Nikula <jarkko.nikula@bitmer.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
CMD0 or hardware reset may invalidate the cache, so it needs to be
flushed before reset.
In the case of recovery, we can't expect flushing the cache to work
always, but have a go and ignore errors.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This adds the following sysfs files according to the iio ABI:
-rw-r--r-- 4096 in_accel_oversampling_ratio
-r--r--r-- 4096 in_accel_oversampling_ratio_available
Internally, the device knows about 4 different power modes that differ
in oversampling ratio (and power consumption). We just show the user
what oversampling ratio(s) is/are available, depending on the current
frequency.
The referenced table in the datasheets makes it easier to understand.
Signed-off-by: Martin Kepplinger <martink@posteo.de>
Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
We register a new device type named "dummy", this will create a
configfs entry under:
* /config/iio/devices/dummy.
Creating dummy devices is now as simple as:
$ mkdir /config/iio/devices/dummy/my_dummy_device
Signed-off-by: Daniel Baluta <daniel.baluta@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This is similar with support for creating triggers via configfs.
Devices will be hosted under:
* /config/iio/devices
We allow users to register "device types" under:
* /config/iio/devices/<device_types>/
Signed-off-by: Daniel Baluta <daniel.baluta@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
No dev->struct_mutex anywhere to be seen.
Cc: Christian Gmeiner <christian.gmeiner@gmail.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Acked-by: Lucas Stach <l.stach@pengutronix.de>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1461691808-12414-17-git-send-email-daniel.vetter@ffwll.ch
Finally all the core gem and a lot of drivers are entirely free of
dev->struct_mutex depencies, and we can start to have an entirely
lockless unref path.
To make sure that no one who touches the core code accidentally breaks
existing drivers which still require dev->struct_mutex I've made the
might_lock check unconditional.
While at it de-inline the ref/unref functions, they've become a bit
too big.
v2: Make it not leak like a sieve.
v3: Review from Lucas:
- drop != NULL in pointer checks.
- fixup copypasted kerneldoc to actually match the functions.
v4:
Add __drm_gem_object_unreference as a fastpath helper for drivers who
abolished dev->struct_mutex, requested by Chris.
v5: Fix silly mistake in drm_gem_object_unreference_unlocked caught by
intel-gfx CI - I checked for gem_free_object instead of
gem_free_object_unlocked ...
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de> (v3)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v4)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1462178451-1765-1-git-send-email-daniel.vetter@ffwll.ch
These definitions are not currently used and if the functionality
they represent is needed the values should be added back to a table
for easy userspace use.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The current channel number for the LEDs should match the stage
number that they are active during, fix this here.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Currently the TIA gain settings are exported to userspace as sysfs
entries that do not clearly represent their internal relation to the
sampling stages. The gain settings are enabled on a per-stage basis,
this can be seen in figure 24 of the current AFE4404 datasheet.
These gain settings should therefore be tied to the channels that are
read during these stages. Make this change here.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
These drivers can use regmap fields to access fields in registers, this
allows us to remove some macros/defines and simplify code, do this here.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Only has one user and is nothing more than a shim on top of
i915_vma_unbind, so let's just get rid of it.
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Suggested-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1461842691-27575-1-git-send-email-matthew.auld@intel.com
These AFEs have 4 ADC mesuring stages (called LED2, ALED2, LED1, and
ALED1 in the datasheet), we map these as channels, these stages can serve
different purposes depending on the application. For instance the AFE4404
has an additional LED (LED3), this LED can be timed to be active during
stage 2 (or anystage, but the datasheet describes this case and the name
of the stage reflects this use). This ability is used further in upcoming
parts that tie the front-end gain and the LED timings together. For these
reasons we remove explicit naming the channels.
Without channel names it is best that the index numbers are in order to
match the stage number, reorder the channel numbers.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Input channel LED3 is only an alias for stage ALED2, this virtual channel
does nothing for us, remove this channel.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
No channel in the afe4403 driver has IIO_CHAN_INFO_OFFSET set so
remove the handlers for this.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The LED channels are not scannable and so scan_index should
be negative, fix this here.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Locking the two gain stages to the same setting adds no value for us,
so initialize them as unlocked and remove the sysfs for unlocking them.
This also allows us to greatly simplify showing and setting the gain
registers.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The drivers set some register values during initialization that can be
set at runtime, these defaults were used in testing but are not
necessary, remove these.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The drivers DT tables are not built-in when OF is not enabled, this does
not save us enough to justify ugly ifdefs. Clean this up.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Fix kernel-doc formatting for structs, and while we are making little
fixes, clarify the module description and update the copywrite.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
When writing a value using direct reg access from debugfs
we need to return and not fall through to reading the
value, lest we'll dereference a NULL pointer.
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The > here should be >= or we go beyond the end for the array.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
mask and val parameters of regmap_update_bits were reveresed.
Fixes: 77c4ad2d6a ("iio: imu: Add initial support for Bosch BMI160")
Signed-off-by: Daniel Baluta <daniel.baluta@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Format is INT_PLUS_MICRO and micro odr part of ODR should
be parts of a micro.
Also s/8000/800 this is obviously a typo.
Fixes: 77c4ad2d6a ("iio: imu: Add initial support for Bosch BMI160")
Signed-off-by: Daniel Baluta <daniel.baluta@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Disabling of the touchscreen IRQs should be done in
mxs_lradc_disable_ts. So disable only the masked virtual channels
in mxs_lradc_hw_stop and finally remove the unused function
mxs_lradc_irq_en_mask.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Tested-by: Marek Vasut <marex@denx.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
After using devm_input_allocate_device for registration
the function mxs_lradc_ts_unregister isn't necessary anymore
since mxs_lradc_ts_close already does the job.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This patch simplifies the TS registration of mxs-lradc by
using devm_input_allocate_device.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Minimal implementation of an IIO driver for the Freescale
MMA7660FC 3-axis accelerometer. Datasheet:
http://www.nxp.com/files/sensors/doc/data_sheet/MMA7660FC.pdf
Includes:
- ACPI support;
- read_raw for x,y,z axes;
- reading and setting the scale (range) parameter.
- power management
Signed-off-by: Constantin Musca <constantin.musca@intel.com>
Reviewed-by: Martin Klepplinger <martink@posteo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Some kind of Freescale Layerscape SoC provides a MSI
implementation which uses two SCFG registers MSIIR and
MSIR to support 32 MSI interrupts for each PCIe controller.
The patch is to support it.
Signed-off-by: Minghuan Lian <Minghuan.Lian@nxp.com>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
While we can not fully fence of the Nonquiescing Key-Setting facility,
we should as try our best to hide it.
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
We should never inject an exception after we manually rewound the PSW
(to retry the ESSA instruction in this case). This will mess up the PSW.
So this never worked and therefore never really triggered.
Looking at the details, we don't even have to perform any validity checks.
1. Bits 52-63 of an entry are stored as 0 by the hardware.
2. We are dealing with absolute addresses but only check for the prefix
starting at address 0. This isn't correct and doesn't make much sense,
cpus could still zap the prefix of other cpus. But as prefix pages
cannot be swapped out without a notifier being called for the affected
VCPU, a zap can never remove a protected prefix.
Reviewed-by: Dominik Dingel <dingel@linux.vnet.ibm.com>
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
