Define snd_ak4114_suspend() and snd_ak4114_resume() functions to
handle PM properly, stopping and restarting the work at PM.
Currently only ice1712/juli.c deals with the PM and ak4114, so fix the
calls there appropriately.
The same PM functions are defined in ak4113.c, too, although they
aren't currently called yet (ice1712/quartet.c may be enhanced to
support PM later).
Acked-by: Jaroslav Kysela <perex@perex.cz>
Tested-by: Pavel Hofman <pavel.hofman@ivitera.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When ak4114 work calls its callback and the callback invokes
ak4114_reinit(), it stalls due to flush_delayed_work(). For avoiding
this, control the reentrance by introducing a refcount. Also
flush_delayed_work() is replaced with cancel_delayed_work_sync().
The exactly same bug is present in ak4113.c and fixed as well.
Reported-by: Pavel Hofman <pavel.hofman@ivitera.com>
Acked-by: Jaroslav Kysela <perex@perex.cz>
Tested-by: Pavel Hofman <pavel.hofman@ivitera.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The Intel Bluetooth controllers can provide an additional exception
info string when a hardware error event occurs. The core will now
call hdev->hw_error to let the driver read out this information.
This change will cause a reset of the hardware to bring it back
into functional state and then read the Intel exception info
string and print it along with the error information.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When receiving a HCI Hardware Error event, the controller should be
assumed to be non-functional until issuing a HCI Reset command.
The Bluetooth hardware errors are vendor specific and so add a
new hdev->hw_error callback that drivers can provide to run extra
code to handle the hardware error.
After completing the vendor specific error handling perform a full
reset of the Bluetooth stack by closing and re-opening the transport.
Based-on-patch-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Split the hci_dev_reset ioctl handling into using hci_dev_do_reset
helper function. Similar to what has been done with hci_dev_do_open
and hci_dev_do_close.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The discovery state should be set to stopped when the HCI device is
powered off. This patch adds the appropriate call to the
hci_discovery_set_state() function from hci_dev_do_close() which is
responsible for the power-off procedure.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When HCI_Reset is issued the discovery state is assumed to be stopped.
The hci_cc_reset() handler was trying to set the state but it was doing
it without using the hci_discovery_set_state() function. Because of this
e.g. the mgmt Discovering event could go without being sent. This patch
fixes the code to use the hci_discovery_set_state() function instead of
just blindly setting the state value.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
There's a check in set_secure_conn() that's supposed to ensure that SSP
is enabled before we try to request the controller to enable SC (since
SSP is a pre-requisite for it). However, this check only makes sense for
controllers actually supporting BR/EDR SC. If we have a 4.0 controller
we're only interested in the LE part of SC and should therefore not be
requiring SSP to be enabled. This patch adds an additional condition to
check for lmp_sc_capable(hdev) before requiring SSP to be enabled.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The btusb_disconnect() callback calls hci_unregister_dev() which in turn
calls btusb_close() if the HCI device is powered. The btusb_close()
function in turn will call btusb_free_frags(). It's therefore
unnecessary to have another call to btusb_free_frags() in the
btusb_disconnect() function. Besides the redundancy the second call
seems to also cause some strange stability issues which this patch then
also fixes.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When loading the Intel firmware it can happen that the firmware loading
complete vendor event arrives before the command complete event for the
last firmware fragment.
< HCI Command: Vendor (0x3f|0x0009) plen 7
01 02 fc 03 00 00 00
> HCI Event: Vendor (0xff) plen 5
06 00 00 00 00
> HCI Event: Command Complete (0x0e) plen 4
Vendor (0x3f|0x0009) ncmd 31
Status: Success (0x00)
This is mainly caused by the fact that the vendor command and its
command complete event are transported over the bulk endpoints. The
firmware loading complete event however is send over the interrupt
endpoint. So with just bad timing one event arrives before the other.
Currently the code does not account for it. There are precautions for
receiving firmware loading complete event quickly, but not for receiving
it before the command complete.
Introduce an extra flag that tracks when the firmware sending has
completed from the driver point of view and track the completion of
the firmware loading procedure with a different flag. That way the
wakeup can be handled properly.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
If Secure Connections Only mode has been enabled, the it is important
to check that OOB data for P-256 values is provided. In case it is not,
then tell the remote side that no OOB data is present.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When replying to the IO capability request for Secure Simple Pairing and
Secure Connections, the OOB data present fields needs to set. Instead of
making the calculation inline, split this into a separate helper
function.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When Secure Connections Only mode has been enabled and remote OOB data
is requested, then only provide P-256 hash and randomizer vaulues. The
fields for P-192 hash and randomizer should be set to zero.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Until legacy SMP OOB pairing is implemented user space should be given a
clear error when trying to use it. This patch adds a corresponding check
to the Add Remote OOB Data handler function which returns "invalid
parameters" if non-zero Rand192 or Hash192 parameters were given for an
LE address.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The core only supports up to 32 slaves, and the chipselect function
expects the same.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Most of them are rather relevant with the definitions in driver.h,
and there are only a few lines, so just rip it off.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Just reformatting the comments and typos fixed, no functional
changes. Particularly,
- avoid the kerneldoc marker "/**",
- reduce multiple comment lines into single lines,
- corrected wrongly referred function names
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Refactor drms_uA_update() slightly to allow regulator_set_optimum_mode()
to utilize the same logic instead of duplicating it.
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
"force_mode" is a u32 so it is never "< 0", but because of type
promotion then comparing "== -1" will do what we want.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Small transfers generally can be accomplished faster in polling mode.
This patch select the transfer which size is bellow the buffer size to
be done on polling mode
Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Simplify the code by using the unit used on most of the code logic.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Simplify the code by using the unit used on most of the code logic.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
spi_rx handles the case where the buffer is null. Nevertheless spi_tx
did not handle it, and was handled by the caller function.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Simplify the code by removing the tx and and rx function pointers and
substitute them by a single function.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The core controls the chip select lines individually.
By default, all the lines are consider active_low. After
spi_setup_transfer, it has its real value.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When no irq is used, there is no need to inhibit the transmission for
every transaction. This inhibition was implemented to avoid a race
condition with the irq handler.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The core can run in polling mode. In fact, the performance of the core
is similar (or even better), due to the fact most of the spi
transactions are just a couple of bytes and there is one irq per
transactions.
When an mtd device is connected via spi, reading 8MB of data produces
more than 80K interrupts (with irq disabling, context swith....)
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The control register has not changed since the previous access.
Therefore we can use the cached value and safe one bus access.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
On the transmission loop, check for remaining bytes at the loop
condition.
This way we can handle transmissions of 0 bytes and clean the code.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Instead of enabling the IRQ and disabling it for every transaction.
Specially the small transactions (1,2 words) benefit from removing 3 bus
accesses.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Instead of checking the TX_FULL flag for every transaction, find out the
size of the buffer at probe time and use it.
To avoid situations where the core had some data on the buffer before
initialization, the core is reseted before the buffer size is detected
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
With the relase of Lollipop, Android no longer
requires the logger driver.
There are three patches which the android dev's
still need before they drop logger on all their
devices:
[PATCH v4 1/5] pstores: use scnprintf
[PATCH v2 2/5] pstore: remove superfluous memory size check
[PATCH 3/5] pstore: handle zero-sized prz in series
[PATCH v4 4/5] pstore: add pmsg
[PATCH 5/5] pstore: selinux: add security in-core xattr support for pstore and debugfs
But these seem to have been acked and are hopefully
queued for upstream.
So this patch removes the logger driver from staging.
Cc: Rom Lemarchand <romlem@google.com>,
Cc: Mark Salyzyn <salyzyn@google.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Android Kernel Team <kernel-team@android.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "wlf,wm8912" compatible string is used for wm8912, which
share driver with wm8904, however, the data type is different.
Signed-off-by: Bo Shen <voice.shen@atmel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The WM8904 and WM8918 has the same data type, while the WM8912
has different data type. So, use the data in dt ids table to
distinguish them.
Signed-off-by: Alexander Morozov <linux@meltdown.ru>
[voice.shen@atmel.com: add code to distinguish device type]
Signed-off-by: Bo Shen <voice.shen@atmel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The PLL introduces jitter, which in turn introduces noice if used
to clock the DAC. Thus, avoid the PLL output, and use the PLL input
to drive the DAC clock, if possible.
This is described for the PCM5142/PCM5242 chips in the answers to the
forum post "PCM5142/PCM5242 DAC clock source" at the TI E2E community
pages (1).
(1) http://e2e.ti.com/support/data_converters/audio_converters/f/64/t/389994
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Mark Brown <broonie@kernel.org>
Using the PLL in master mode requires using an external connection
between one of the GPIO pins (configured as PLL/4 output) and the
SCK pin. It also requires the external clock to be fed to some other
GPIO pin instead of the SCK pin.
This is described for the PCM5122 chip in the answers to the forum post
"PCM5122 DAC as I2S master troubles with PLL mode" at the TI E2E
community pages (1). The clocking functionality is also much better
described in the datasheet for the chip PCM5242, which seems to be
register compatible with PCM512x and PCM514x (which both have severely
lacking datasheets).
(1) http://e2e.ti.com/support/data_converters/audio_converters/f/64/t/267830
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Mark Brown <broonie@kernel.org>
Use register field names from the seemingly compatible PCM5242 datasheet,
as the PCM512x and PCM514x datasheets are severly lacking.
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch fixes the following coccicheck warning:
No need to set .owner here. The core will do it.
Signed-off-by: Heba Aamer <heba93aamer@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai