Johan writes:
USB-serial updates for 5.11-rc1
Here are the USB-serial updates for 5.11-rc1, including:
- keyspan_pda write-implementation fixes
- digi_acceleport write-wakeup fix
- mos7720 parport-restore fix
- mos7720 parport-tasklet removal
- cp210x termios-handling cleanups
- option device-flag fix
- ftdi_sio GPIO CBUS-configuration improvements
- removal of in_interrupt() uses
Included are also various clean ups.
All have been in linux-next with no reported issues.
* tag 'usb-serial-5.11-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: (30 commits)
USB: serial: ftdi_sio: log the CBUS GPIO validity
USB: serial: ftdi_sio: drop GPIO line checking dead code
USB: serial: ftdi_sio: report the valid GPIO lines to gpiolib
USB: serial: option: add interface-number sanity check to flag handling
USB: serial: cp210x: clean up dtr_rts()
USB: serial: cp210x: refactor flow-control handling
USB: serial: cp210x: drop flow-control debugging
USB: serial: cp210x: set terminal settings on open
USB: serial: cp210x: clean up line-control handling
USB: serial: cp210x: return early on unchanged termios
USB: serial: mos7720: defer state restore to a workqueue
USB: serial: mos7720: fix parallel-port state restore
USB: serial: remove write wait queue
USB: serial: digi_acceleport: fix write-wakeup deadlocks
USB: serial: keyspan_pda: drop redundant usb-serial pointer
USB: serial: keyspan_pda: use BIT() macro
USB: serial: keyspan_pda: clean up comments and whitespace
USB: serial: keyspan_pda: clean up xircom/entrega support
USB: serial: keyspan_pda: add write-fifo support
USB: serial: keyspan_pda: increase transmitter threshold
...
Drivers for multi-queue platform devices may also want managed interrupts
for handling HW queue completion interrupts, so add support.
The function accepts an affinity descriptor pointer, which covers all IRQs
expected for the device.
The function is devm class as the only current in-tree user will also use
devm method for requesting the interrupts; as such, the function is made
as devm as it can ensure ordering of freeing the irq and disposing of the
mapping.
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Acked-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/1606905417-183214-5-git-send-email-john.garry@huawei.com
Add a function to allow the affinity of an interrupt be switched to
managed, such that interrupts allocated for platform devices may be
managed.
This new interface has certain limitations, and attempts to use it in the
following circumstances will fail:
- For when the kernel is configured for generic IRQ reservation mode (in
config GENERIC_IRQ_RESERVATION_MODE). The reason being that it could
conflict with managed vs. non-managed interrupt accounting.
- The interrupt is already started, which should not be the case during
init
- The interrupt is already configured as managed, which means double init
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/1606905417-183214-2-git-send-email-john.garry@huawei.com
We have two flavours of platform-MSI:
- MSIs generated by devices for themselves (the usual case)
- MSIs generated on behalf of other devices, as the generating
device is some form of bridge (either a wire-to-MSI bridge,
or even a non-transparent PCI bridge that repaints the PCI
requester ID).
In the latter case, the underlying interrupt architecture may need
to track this in order to keep the mapping alive even when no MSI
are currently being generated.
Add a set of flags to the generic msi_alloc_info_t structure, as
well as the MSI_ALLOC_FLAGS_PROXY_DEVICE flag that will get
advertized by the platform-MSI code when allocating an irqdomain
for a device.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Tested-by: John Garry <john.garry@huawei.com>
Link: https://lore.kernel.org/r/20201129135208.680293-2-maz@kernel.org
ti_sci_intr_irq_domain_free() assumes that out_irq of intr is stored in
data->chip_data and uses it for calling ti_sci irq_free() and then
mark the out_irq as available resource. But ti_sci_intr_irq_domain_alloc()
is storing p_hwirq(parent's hardware irq) which is translated from out_irq.
This is causing resource leakage and eventually out_irq resources might
be exhausted. Fix ti_sci_intr_irq_domain_alloc() by storing the out_irq
in data->chip_data.
Fixes: a5b659bd4b ("irqchip/ti-sci-intr: Add support for INTR being a parent to INTR")
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20201102120631.11165-1-lokeshvutla@ti.com
On a successful probe, the driver tries to print a success message with
INTA device id. It uses pdev->id for printing the id but id is stored in
inta->ti_sci_id. Fix it by correcting the dev_info parameter.
Fixes: 5c4b585d29 ("irqchip/ti-sci-inta: Add support for INTA directly connecting to GIC")
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20201102120614.11109-1-lokeshvutla@ti.com
handle_percpu_devid_fasteoi_ipi() states:
* The biggest difference with the IRQ version is that the interrupt is
* EOIed early, as the IPI could result in a context switch, and we need to
* make sure the IPI can fire again
All that can actually happen scheduler-wise within the handling of an IPI
is the raising of TIF_NEED_RESCHED (and / or folding thereof into
preempt_count); see scheduler_ipi() or sched_ttwu_pending() for instance.
Said flag / preempt_count is evaluated some time later before returning to
whatever context was interrupted, and this gates a call to
preempt_schedule_irq() (arm64_preempt_schedule_irq() in arm64).
Per the above, SGI's do not need a different handler than PPI's, so make
them use the same (handle_percpu_devid_irq).
Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20201109094121.29975-2-valentin.schneider@arm.com
A driver remove callback is only called if the device was bound before.
So it's sure that both dev and dev->driver are valid and dev is an i2c
device. If the check fails something louder than "return 0" might be
appropriate because the problem is grave (something like memory
corruption), otherwise the check is useless.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
The driver core ignores the return value of struct bus_type::remove. So
warn if there is an error that went unnoticed before and return 0
unconditionally in i2c_device_remove().
This prepares changing struct bus_type::remove to return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
[wsa: added a comment and removed unneeded initializtion]
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Fix build warnings as below:
drivers/irqchip/irq-loongson-htpic.c: In function 'htpic_reg_init':
>> drivers/irqchip/irq-loongson-htpic.c:62:12: warning: variable 'val' set but not used [-Wunused-but-set-variable]
62 | uint32_t val;
| ^~~
drivers/irqchip/irq-loongson-htpic.c: At top level:
>> drivers/irqchip/irq-loongson-htpic.c:84:12: warning: no previous prototype for 'htpic_of_init' [-Wmissing-prototypes]
84 | int __init htpic_of_init(struct device_node *node, struct device_node *parent)
| ^~~~~~~~~~~~~
Fixes: a93f1d903f ("irqchip: Add driver for Loongson-3 HyperTransport PIC controller")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Huacai Chen <chenhuacai@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/1607159744-995-1-git-send-email-chenhuacai@kernel.org
While performing suspend/resume, we were getting below kernel crash.
[ 54.541672] [FTS][Info]gesture suspend...
[ 54.605256] [FTS][Error][GESTURE]Enter into gesture(suspend) failed!
[ 54.605256]
[ 58.345850] irq event 10: bogus return value fffffff3
......
[ 58.345966] [<ffff0000080830f0>] el1_irq+0xb0/0x124
[ 58.345971] [<ffff000008085360>] arch_cpu_idle+0x10/0x18
[ 58.345975] [<ffff0000081077f4>] do_idle+0x1ac/0x1e0
[ 58.345979] [<ffff0000081079c8>] cpu_startup_entry+0x20/0x28
[ 58.345983] [<ffff000008a80ed0>] rest_init+0xd0/0xdc
[ 58.345988] [<ffff0000091c0b48>] start_kernel+0x390/0x3a4
[ 58.345990] handlers:
[ 58.345994] [<ffff0000085120d0>] bam_dma_irq
The reason for the crash we found is, bam_dma_irq() was returning
negative value when the device resumes in some conditions.
In addition, the irq handler should have one of the below return values.
IRQ_NONE interrupt was not from this device or was not handled
IRQ_HANDLED interrupt was handled by this device
IRQ_WAKE_THREAD handler requests to wake the handler thread
Therefore, to resolve this crash, we have changed the return value to
IRQ_NONE.
Signed-off-by: Parth Y Shah <sparth1292@gmail.com>
Link: https://lore.kernel.org/r/1607322820-7450-1-git-send-email-sparth1292@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Add support to allow configuration of Intel Analytics Accelerator (IAX) in
addition to the Intel Data Streaming Accelerator (DSA). The IAX hardware
has the same configuration interface as DSA. The main difference
is the type of operations it performs. We can support the DSA and
IAX devices on the same driver with some tweaks.
IAX has a 64B completion record that needs to be 64B aligned, as opposed to
a 32B completion record that is 32B aligned for DSA. IAX also does not
support token management.
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/160564555488.1834439.4261958859935360473.stgit@djiang5-desk3.ch.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Update the kerneldoc function headers to fix build warnings:
drivers/dma/qcom/qcom_adm.c:180: warning: Function parameter or member 'chan' not described in 'adm_free_chan'
drivers/dma/qcom/qcom_adm.c:190: warning: Function parameter or member 'burst' not described in 'adm_get_blksize'
drivers/dma/qcom/qcom_adm.c:466: warning: Function parameter or member 'chan' not described in 'adm_terminate_all'
drivers/dma/qcom/qcom_adm.c:466: warning: Excess function parameter 'achan' description in 'adm_terminate_all'
drivers/dma/qcom/qcom_adm.c:503: warning: Function parameter or member 'achan' not described in 'adm_start_dma'
Signed-off-by: Jonathan McDowell <noodles@earth.li>
Link: https://lore.kernel.org/r/20201126184602.GA1008@earth.li
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The check for infoframe transmit status in hdmi_infoframe_uptodate()
makes the assumption that packet buffer index is set to zero.
Align code with specification and explicitly set the index before
AC_VERB_GET_HDMI_DIP_XMIT. The packet index setting affects both
DIP-Data and DIP-XmitCtrl verbs.
There are no known cases where the old implementation has caused driver
to work incorrectly. This change is purely based on code review against
the specification (HDA spec rev1.0a).
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20201211131613.3271407-1-kai.vehmanen@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Dan reported that smatch reports wrong size check and after analysis it
is confirmed that we are comparing wrong value: pointer size instead of
array size. However the check itself is problematic as in UAPI header
there are two fields:
struct snd_soc_tplg_enum_control {
(...)
char texts[SND_SOC_TPLG_NUM_TEXTS][SNDRV_CTL_ELEM_ID_NAME_MAXLEN];
__le32 values[SND_SOC_TPLG_NUM_TEXTS * SNDRV_CTL_ELEM_ID_NAME_MAXLEN / 4];
the texts field is for names and the values one for values assigned to
those named fields, after analysis it becomes clear that there is quite
a lot overhead values than we may possibly name. So instead of changing
check to ARRAY_SIZE(ec->values), as it was first suggested, use
hardcoded value of SND_SOC_TPLG_NUM_TEXTS.
Link: https://lore.kernel.org/alsa-devel/X9B0eDcKy+9B6kZl@mwanda/
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20201210152541.191728-1-amadeuszx.slawinski@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The condition boot_iteration == HDA_FW_BOOT_ATTEMPTS to determine
the log level for the DSP status dump would only work in the case of DSP
init failure after maximum number of attempts to initialize the DSP. If
DSP init succeeds in less than HDA_FW_BOOT_ATTEMPTS attempts and FW
loading fails, the ROM status dump would end up getting logged as debug
instead of an error.
So, add a new flag, SOF_DBG_DUMP_LOG_ERROR, to explicitly specify
the log level for DSP status dump.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20201211100743.3188821-4-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
