04 Apr, 2020
1 commit
-
Pull char/misc driver updates from Greg KH:
"Here is the big set of char/misc/other driver patches for 5.7-rc1.Lots of things in here, and it's later than expected due to some
reverts to resolve some reported issues. All is now clean with no
reported problems in linux-next.Included in here is:
- interconnect updates
- mei driver updates
- uio updates
- nvmem driver updates
- soundwire updates
- binderfs updates
- coresight updates
- habanalabs updates
- mhi new bus type and core
- extcon driver updates
- some Kconfig cleanups
- other small misc driver cleanups and updatesAs mentioned, all have been in linux-next for a while, and with the
last two reverts, all is calm and good"* tag 'char-misc-5.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (174 commits)
Revert "driver core: platform: Initialize dma_parms for platform devices"
Revert "amba: Initialize dma_parms for amba devices"
amba: Initialize dma_parms for amba devices
driver core: platform: Initialize dma_parms for platform devices
bus: mhi: core: Drop the references to mhi_dev in mhi_destroy_device()
bus: mhi: core: Initialize bhie field in mhi_cntrl for RDDM capture
bus: mhi: core: Add support for reading MHI info from device
misc: rtsx: set correct pcr_ops for rts522A
speakup: misc: Use dynamic minor numbers for speakup devices
mei: me: add cedar fork device ids
coresight: do not use the BIT() macro in the UAPI header
Documentation: provide IBM contacts for embargoed hardware
nvmem: core: remove nvmem_sysfs_get_groups()
nvmem: core: use is_bin_visible for permissions
nvmem: core: use device_register and device_unregister
nvmem: core: add root_only member to nvmem device struct
extcon: axp288: Add wakeup support
extcon: Mark extcon_get_edev_name() function as exported symbol
extcon: palmas: Hide error messages if gpio returns -EPROBE_DEFER
dt-bindings: extcon: usbc-cros-ec: convert extcon-usbc-cros-ec.txt to yaml format
...
01 Apr, 2020
1 commit
-
Pull tty/serial updates from Greg KH:
"Here is the big set of TTY / Serial patches for 5.7-rc1Lots of console fixups and reworking in here, serial core tweaks
(doesn't that ever get old, why are we still creating new serial
devices?), serial driver updates, line-protocol driver updates, and
some vt cleanups and fixes included in here as well.All have been in linux-next with no reported issues"
* tag 'tty-5.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (161 commits)
serial: 8250: Optimize irq enable after console write
serial: 8250: Fix rs485 delay after console write
vt: vt_ioctl: fix use-after-free in vt_in_use()
vt: vt_ioctl: fix VT_DISALLOCATE freeing in-use virtual console
tty: serial: make SERIAL_SPRD depend on COMMON_CLK
tty: serial: fsl_lpuart: fix return value checking
tty: serial: fsl_lpuart: move dma_request_chan()
ARM: dts: tango4: Make /serial compatible with ns16550a
ARM: dts: mmp*: Make the serial ports compatible with xscale-uart
ARM: dts: mmp*: Fix serial port names
ARM: dts: mmp2-brownstone: Don't redeclare phandle references
ARM: dts: pxa*: Make the serial ports compatible with xscale-uart
ARM: dts: pxa*: Fix serial port names
ARM: dts: pxa*: Don't redeclare phandle references
serial: omap: drop unused dt-bindings header
serial: 8250: 8250_omap: Add DMA support for UARTs on K3 SoCs
serial: 8250: 8250_omap: Work around errata causing spurious IRQs with DMA
serial: 8250: 8250_omap: Extend driver data to pass FIFO trigger info
serial: 8250: 8250_omap: Move locking out from __dma_rx_do_complete()
serial: 8250: 8250_omap: Account for data in flight during DMA teardown
...
30 Mar, 2020
1 commit
-
* pm-qos: (30 commits)
PM: QoS: annotate data races in pm_qos_*_value()
Documentation: power: fix pm_qos_interface.rst format warning
PM: QoS: Make CPU latency QoS depend on CONFIG_CPU_IDLE
Documentation: PM: QoS: Update to reflect previous code changes
PM: QoS: Update file information comments
PM: QoS: Drop PM_QOS_CPU_DMA_LATENCY and rename related functions
sound: Call cpu_latency_qos_*() instead of pm_qos_*()
drivers: usb: Call cpu_latency_qos_*() instead of pm_qos_*()
drivers: tty: Call cpu_latency_qos_*() instead of pm_qos_*()
drivers: spi: Call cpu_latency_qos_*() instead of pm_qos_*()
drivers: net: Call cpu_latency_qos_*() instead of pm_qos_*()
drivers: mmc: Call cpu_latency_qos_*() instead of pm_qos_*()
drivers: media: Call cpu_latency_qos_*() instead of pm_qos_*()
drivers: hsi: Call cpu_latency_qos_*() instead of pm_qos_*()
drm: i915: Call cpu_latency_qos_*() instead of pm_qos_*()
x86: platform: iosf_mbi: Call cpu_latency_qos_*() instead of pm_qos_*()
cpuidle: Call cpu_latency_qos_limit() instead of pm_qos_request()
PM: QoS: Add CPU latency QoS API wrappers
PM: QoS: Adjust pm_qos_request() signature and reorder pm_qos.h
PM: QoS: Simplify definitions of CPU latency QoS trace events
...
27 Mar, 2020
2 commits
-
Commit 7f9803072ff6 ("serial: 8250: Support console on software emulated
rs485 ports") amended serial8250_console_write() with rs485 support, but
positioned the invocation of ->rs485_stop_tx() after re-enablement of
interrupts. The irq handler and ->console_write() are serialized with
the port spinlock, so no problem there, but due to the rs485 delay, the
irq handler may unnecessarily spin for a while. Avoid that by moving
->rs485_stop_tx() before re-enablement of interrupts, which also mirrors
the order at the beginning of serial8250_console_write().Signed-off-by: Lukas Wunner
Link: https://lore.kernel.org/r/019839cb1f61b01210b6ff9ac9f9079ca77f8411.1585319447.git.lukas@wunner.de
Signed-off-by: Greg Kroah-Hartman -
Due to a silly copy-paste mistake, commit 7f9803072ff6 ("serial: 8250:
Support console on software emulated rs485 ports") erroneously pauses
for the duration of delay_rts_before_send after writing to the console,
instead of delay_rts_after_send. Mea culpa.Fixes: 7f9803072ff6 ("serial: 8250: Support console on software emulated rs485 ports")
Signed-off-by: Lukas Wunner
Link: https://lore.kernel.org/r/9dd67f33c90d23f7fafa3b81b1e812ddabf9ca24.1585319447.git.lukas@wunner.de
Signed-off-by: Greg Kroah-Hartman
26 Mar, 2020
3 commits
-
kbuild-test reported an error:
config: mips-randconfig-a001-20200321 ...
>> drivers/tty/serial/sprd_serial.c:1175: undefined reference
to `clk_set_parent'Because some mips Kconfig selects HAVE_CLK but not COMMON_CLK and no
clk_set_parent implemented, so the error was exposed. So adding
dependence on COMMON_CLK can fix this issue.Fixes: 7ba87cfec71a ("tty: serial: make SERIAL_SPRD not depend on ARCH_SPRD")
Reported-by: kbuild test robot
Signed-off-by: Chunyan Zhang
Link: https://lore.kernel.org/r/20200325081427.20312-1-zhang.lyra@gmail.com
Signed-off-by: Greg Kroah-Hartman -
The return value of lpuart_dma_tx_request() is an negative errno on
failure and zero on success.Fixes: 159381df1442f ("tty: serial: fsl_lpuart: fix DMA operation when using IOMMU")
Reported-by: Leonard Crestez
Signed-off-by: Michael Walle
Reviewed-by: Fugang Duan
Link: https://lore.kernel.org/r/20200325090658.25967-2-michael@walle.cc
Signed-off-by: Greg Kroah-Hartman -
Move dma_request_chan() out of the atomic context. First this call
should not be in the atomic context at all and second the
dev_info_once() may cause a hang because because the console takes this
spinlock, too.Fixes: 159381df1442f ("tty: serial: fsl_lpuart: fix DMA operation when using IOMMU")
Reported-by: Leonard Crestez
Signed-off-by: Michael Walle
Reviewed-by: Fugang Duan
Tested-by: Leonard Crestez
Link: https://lore.kernel.org/r/20200325090658.25967-1-michael@walle.cc
Signed-off-by: Greg Kroah-Hartman
24 Mar, 2020
12 commits
-
The definitons in the dt-binding's gpio header only contains some
constants to be used in device trees. It is not relevant for omap-serial
(as the gpio API hides the details) and in fact unused so it can just be
dropped.Signed-off-by: Uwe Kleine-König
Link: https://lore.kernel.org/r/20200321204031.30369-1-uwe@kleine-koenig.org
Signed-off-by: Greg Kroah-Hartman -
UART on K3 SoCs has configurable RX timeout behavior (controlled via
EFR2) and better DMA integration. This allows to transfer as larger
amount data per DMA transfer compared to older SoCs. Add support for
the same.Signed-off-by: Vignesh Raghavendra
Link: https://lore.kernel.org/r/20200319110344.21348-7-vigneshr@ti.com
Signed-off-by: Greg Kroah-Hartman -
As per Advisory 27 of AM437x Silicon errata document, Spurious UART
interrupts may occur when DMA mode (FCR.DMA_MODE) is enabled. The
Interrupt Controller flags that a UART interrupt has occurred; however,
the associated IT_PENDING bit remains set to 1, indicating that no
interrupt is pending. Acknowledge the spurious interrupts for every
occurrence as workaround.Errata is applicable to all TI SoCs with this IP.
Signed-off-by: Vignesh Raghavendra
Link: https://lore.kernel.org/r/20200319110344.21348-6-vigneshr@ti.com
Signed-off-by: Greg Kroah-Hartman -
Although same 8250 compliant UART IP is reused across different SoC,
their integration wrt DMA varies greatly across SoCs. Therefore,
different SoC may need to use different FIFO trigger level for DMA
event and DMA configuration parameters. Provide a way to pass this
information via driver data. This is required to support UART DMA on
AM654/J721e SoCs.Signed-off-by: Vignesh Raghavendra
Link: https://lore.kernel.org/r/20200319110344.21348-5-vigneshr@ti.com
Signed-off-by: Greg Kroah-Hartman -
Caller functions of __dma_rx_do_complete() already hold rx_dma_lock.
Therefore move locking out of the function to avoid need to release and
reacquire lock.Signed-off-by: Peter Ujfalusi
Signed-off-by: Vignesh Raghavendra
Link: https://lore.kernel.org/r/20200319110344.21348-4-vigneshr@ti.com
Signed-off-by: Greg Kroah-Hartman -
Take into account data stuck in DMA internal buffers before pushing data
to higher layer. dma_tx_state has "in_flight_bytes" member that provides
this information.Signed-off-by: Vignesh Raghavendra
Link: https://lore.kernel.org/r/20200319110344.21348-3-vigneshr@ti.com
Signed-off-by: Greg Kroah-Hartman -
Terminate and flush DMA internal buffers, before pushing RX data to
higher layer. Otherwise, this will lead to data corruption, as driver
would end up pushing stale buffer data to higher layer while actual data
is still stuck inside DMA hardware and has yet not arrived at the
memory.
While at that, replace deprecated dmaengine_terminate_all() with
dmaengine_terminate_async().Signed-off-by: Vignesh Raghavendra
Link: https://lore.kernel.org/r/20200319110344.21348-2-vigneshr@ti.com
Signed-off-by: Greg Kroah-Hartman -
When booting j721e the following bug is printed:
[ 1.154821] BUG: sleeping function called from invalid context at kernel/sched/completion.c:99
[ 1.154827] in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 12, name: kworker/0:1
[ 1.154832] 3 locks held by kworker/0:1/12:
[ 1.154836] #0: ffff000840030728 ((wq_completion)events){+.+.}, at: process_one_work+0x1d4/0x6e8
[ 1.154852] #1: ffff80001214fdd8 (deferred_probe_work){+.+.}, at: process_one_work+0x1d4/0x6e8
[ 1.154860] #2: ffff00084060b170 (&dev->mutex){....}, at: __device_attach+0x38/0x138
[ 1.154872] irq event stamp: 63096
[ 1.154881] hardirqs last enabled at (63095): [] _raw_spin_unlock_irqrestore+0x70/0x78
[ 1.154887] hardirqs last disabled at (63096): [] _raw_spin_lock_irqsave+0x28/0x80
[ 1.154893] softirqs last enabled at (62254): [] _stext+0x488/0x564
[ 1.154899] softirqs last disabled at (62247): [] irq_exit+0x114/0x140
[ 1.154906] CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.6.0-rc6-next-20200318-00094-g45e4089b0bd3 #221
[ 1.154911] Hardware name: Texas Instruments K3 J721E SoC (DT)
[ 1.154917] Workqueue: events deferred_probe_work_func
[ 1.154923] Call trace:
[ 1.154928] dump_backtrace+0x0/0x190
[ 1.154933] show_stack+0x14/0x20
[ 1.154940] dump_stack+0xe0/0x148
[ 1.154946] ___might_sleep+0x150/0x1f0
[ 1.154952] __might_sleep+0x4c/0x80
[ 1.154957] wait_for_completion_timeout+0x40/0x140
[ 1.154964] ti_sci_set_device_state+0xa0/0x158
[ 1.154969] ti_sci_cmd_get_device_exclusive+0x14/0x20
[ 1.154977] ti_sci_dev_start+0x34/0x50
[ 1.154984] genpd_runtime_resume+0x78/0x1f8
[ 1.154991] __rpm_callback+0x3c/0x140
[ 1.154996] rpm_callback+0x20/0x80
[ 1.155001] rpm_resume+0x568/0x758
[ 1.155007] __pm_runtime_resume+0x44/0xb0
[ 1.155013] omap8250_probe+0x2b4/0x508
[ 1.155019] platform_drv_probe+0x50/0xa0
[ 1.155023] really_probe+0xd4/0x318
[ 1.155028] driver_probe_device+0x54/0xe8
[ 1.155033] __device_attach_driver+0x80/0xb8
[ 1.155039] bus_for_each_drv+0x74/0xc0
[ 1.155044] __device_attach+0xdc/0x138
[ 1.155049] device_initial_probe+0x10/0x18
[ 1.155053] bus_probe_device+0x98/0xa0
[ 1.155058] deferred_probe_work_func+0x74/0xb0
[ 1.155063] process_one_work+0x280/0x6e8
[ 1.155068] worker_thread+0x48/0x430
[ 1.155073] kthread+0x108/0x138
[ 1.155079] ret_from_fork+0x10/0x18To fix the bug we need to first call pm_runtime_enable() prior to any
pm_runtime calls.Reported-by: Tomi Valkeinen
Signed-off-by: Peter Ujfalusi
Link: https://lore.kernel.org/r/20200320125200.6772-1-peter.ujfalusi@ti.com
Signed-off-by: Greg Kroah-Hartman -
Call stop_rx() to halt reception when throttle is requested. Update
unthrottle callback to restart reception.Signed-off-by: Vignesh Raghavendra
Link: https://lore.kernel.org/r/20200319103230.16867-3-vigneshr@ti.com
Signed-off-by: Greg Kroah-Hartman -
When port's throttle callback is called, it should stop pushing any more
data into TTY buffer to avoid buffer overflow. This means driver has to
stop HW from receiving more data and assert the HW flow control. For
UARTs with auto HW flow control (such as 8250_omap) manual assertion of
flow control line is not possible and only way is to allow RX FIFO to
fill up, thus trigger auto HW flow control logic.Therefore make sure that 8250 generic IRQ handler does not drain data
when port is stopped (i.e UART_LSR_DR is unset in read_status_mask). Not
servicing, RX FIFO would trigger auto HW flow control when FIFO
occupancy reaches preset threshold, thus halting RX.
Since, error conditions in UART_LSR register are cleared just by reading
the register, data has to be drained in case there are FIFO errors, else
error information will lost.Signed-off-by: Vignesh Raghavendra
Link: https://lore.kernel.org/r/20200319103230.16867-2-vigneshr@ti.com
Signed-off-by: Greg Kroah-Hartman -
Make sure that all bytes are transmitted out of Uart by monitoring
CDNS_UART_SR_TACTIVE bit as well.Signed-off-by: Raviteja Narayanam
Signed-off-by: Shubhrajyoti Datta
Acked-by: Maarten Brock
Link: https://lore.kernel.org/r/e2514818af5973be291cc117d07739f068b71639.1584610774.git.shubhrajyoti.datta@xilinx.com
Signed-off-by: Greg Kroah-Hartman -
set_termios function should not wait for the transmit FIFO empty
(CDNS_UART_SR_TXEMPTY) unconditionally. The tty layer takes care
of it based on the parameter passed (TCSANOW/TCSADRAIN/TCSAFLUSH).Signed-off-by: Raviteja Narayanam
Signed-off-by: Shubhrajyoti Datta
Link: https://lore.kernel.org/r/536e190dd5bbb474007a67e6323c048288942a28.1584610774.git.shubhrajyoti.datta@xilinx.com
Signed-off-by: Greg Kroah-Hartman
18 Mar, 2020
4 commits
-
Since snprintf() returns the would-be-output size instead of the
actual output size, the succeeding calls may go beyond the given
buffer limit. Fix it by replacing with scnprintf().Signed-off-by: Takashi Iwai
Link: https://lore.kernel.org/r/20200311092930.24433-1-tiwai@suse.de
Signed-off-by: Greg Kroah-Hartman -
We don't need to cleanup sprd_port anymore, since we've dropped the way
of using the sprd_port[] array to get port index.Reviewed-by: Baolin Wang
Signed-off-by: Chunyan Zhang
Link: https://lore.kernel.org/r/20200318105049.19623-3-zhang.lyra@gmail.com
Signed-off-by: Greg Kroah-Hartman -
This patch simplifies the process of getting serial port number, with
this patch, serial devices must have aliases configured in devicetree.The serial port searched out via sprd_port array maybe wrong if we don't
have serial alias defined in devicetree, and specify console with command
line, we would get the wrong port number if other serial ports probe
failed before console's. So using aliases is mandatory.Reviewed-by: Baolin Wang
Signed-off-by: Chunyan Zhang
Link: https://lore.kernel.org/r/20200318105049.19623-2-zhang.lyra@gmail.com
Signed-off-by: Greg Kroah-Hartman -
Add CONSOLE_POLL support for future KGDB porting.
Signed-off-by: Vincent Chen
Changes since v1:
1. Fix the compile error reported by kbuild test robot
Link: https://lore.kernel.org/r/1584492027-23236-1-git-send-email-vincent.chen@sifive.comSigned-off-by: Greg Kroah-Hartman
17 Mar, 2020
7 commits
-
It would be too tricky and error prone to allow DMA operations on
kernel console.One of the concern is when DMA is a separate device, for example on
Intel CherryTrail platforms, and might need special work around to be
functional, see the commiteebb3e8d8aaf ("ACPI / LPSS: override power state for LPSS DMA device")
for more information.
Another one is that kernel console is used in atomic context, e.g.
when printing crucial information to the user (Oops or crash),
and DMA may not serve due to power management complications
including non-atomic ACPI calls but not limited to it (see above).Besides that, other concerns are described in the commit
84b40e3b57ee ("serial: 8250: omap: Disable DMA for console UART")
done for OMAP UART and may be repeated here.
Disable any kind of DMA operations on kernel console due to above concerns.
Signed-off-by: Andy Shevchenko
Link: https://lore.kernel.org/r/20200217114016.49856-7-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman -
Doing any kind of power management for kernel console is really bad idea.
First of all, it runs in poll and atomic mode. This fact attaches a limitation
on the functions that might be called. For example, pm_runtime_get_sync() might
sleep and thus can't be used. This call needs, for example, to bring the device
to powered on state on the system, where the power on sequence may require
on-atomic operations, such as Intel Cherrytrail with ACPI enumerated UARTs.
That said, on ACPI enabled platforms it might even call firmware for a job.On the other hand pm_runtime_get() doesn't guarantee that device will become
powered on fast enough.Besides that, imagine the case when console is about to print a kernel Oops and
it's powered off. In such an emergency case calling the complex functions is
not the best what we can do, taking into consideration that user wants to see
at least something of the last kernel word before it passes away.Here we modify the 8250 console code to prevent runtime power management.
Note, there is a behaviour change for OMAP boards. It will require to detach
kernel console to become idle.Link: https://lists.openwall.net/linux-kernel/2018/09/29/65
Suggested-by: Russell King
Signed-off-by: Andy Shevchenko
Link: https://lore.kernel.org/r/20200217114016.49856-6-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman -
In the future we would like to disable power management on the serial devices
used as kernel consoles to avoid weird behaviour in some cases. However,
disabling PM may prevent system to go to deep sleep states, which in its turn
leads to the higher power consumption.Tony Lindgren proposed a work around, i.e. allow user to detach such consoles
to make PM working again. In case user wants to see what's going on, it also
provides a mechanism to attach console back.Link: https://lists.openwall.net/linux-kernel/2018/09/29/65
Suggested-by: Tony Lindgren
Signed-off-by: Andy Shevchenko
Link: https://lore.kernel.org/r/20200217114016.49856-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman -
This reverts commit 175b558d0efb8b4f33aa7bd2c1b5389b912d3019.
When the user configures a kernel without support for Samsung SoCs, it
makes no sense to ask the user about enabling "Samsung SoC serial
support", as Samsung serial ports can only be found on Samsung SoCs.Signed-off-by: Geert Uytterhoeven
Link: https://lore.kernel.org/r/20200306102301.16870-1-geert+renesas@glider.be
Signed-off-by: Greg Kroah-Hartman -
We should validate if the 'sup' is NULL or not before freeing DMA
memory, to fix below warning."drivers/tty/serial/sprd_serial.c:1141 sprd_remove()
error: we previously assumed 'sup' could be null (see line 1132)"Fixes: f4487db58eb7 ("serial: sprd: Add DMA mode support")
Reported-by: Dan Carpenter
Signed-off-by: Lanqing Liu
Cc: stable
Link: https://lore.kernel.org/r/e2bd92691538e95b04a2c2a728f3292e1617018f.1584325957.git.liuhhome@gmail.com
Signed-off-by: Greg Kroah-Hartman -
The function sprd_console_setup() would be called from .probe() which can
be called after freeing __init functions, for example the .probe() would
return -EPROBE_DEFER since it depends on clock modules.Signed-off-by: Chunyan Zhang
Reviewed-by: Baolin Wang
Link: https://lore.kernel.org/r/20200316101930.9962-3-zhang.lyra@gmail.com
Signed-off-by: Greg Kroah-Hartman -
The SPRD serial driver need to know which serial port would be used as
console in an early period during initialization, the purpose is to
keep the console port alive as possible even if there's some error
caused by no clock configured under serial devicetree nodes. But with
the patch [1], the console port couldn't be identified if missing
console command line.So this patch adds using another interface to do check by reading
stdout-path.[1] https://lore.kernel.org/lkml/20190826072929.7696-4-zhang.lyra@gmail.com/
Signed-off-by: Chunyan Zhang
Reviewed-by: Baolin Wang
Link: https://lore.kernel.org/r/20200316101930.9962-2-zhang.lyra@gmail.com
Signed-off-by: Greg Kroah-Hartman
14 Mar, 2020
2 commits
-
The geni serial driver's shutdown code had a special case to call
console_stop(). Grepping through the code, it was the only serial
driver doing something like this (the only other caller of
console_stop() was in serial_core.c).As far as I can tell there's no reason to call console_stop() in the
geni code. ...and a good reason _not_ to call it. Specifically if
you have an agetty running on the same serial port as the console then
killing the agetty kills your console and if you start the agetty
again the console doesn't come back.Fixes: c4f528795d1a ("tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP")
Signed-off-by: Douglas Anderson
Link: https://lore.kernel.org/r/20200313134635.2.I3648fac6c98b887742934146ac2729ecb7232eb1@changeid
Signed-off-by: Greg Kroah-Hartman -
On a board using qcom_geni_serial I found that I could no longer
interact with kdb if I got a crash after the "agetty" running on the
same serial port was killed. This meant that various classes of
crashes that happened at reboot time were undebuggable.Reading through the code, I couldn't figure out why qcom_geni_serial
felt the need to run so much code at port shutdown time. All we need
to do is disable the interrupt.After I make this change then a hardcoded kgdb_breakpoint in some late
shutdown code now allows me to interact with the debugger. I also
could freely close / re-open the port without problems.Fixes: c4f528795d1a ("tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP")
Signed-off-by: Douglas Anderson
Link: https://lore.kernel.org/r/20200313134635.1.Icf54c533065306b02b880c46dfd401d8db34e213@changeid
Signed-off-by: Greg Kroah-Hartman
13 Mar, 2020
5 commits
-
'source' (include) all of the tty/*/Kconfig files from
drivers/tty/Kconfig instead of from drivers/char/Kconfig.
This consolidates them both in source code and in menu
presentation to the user.Move hvc/Kconfig and serial/Kconfig 'source' lines into the
if TTY/endif block and remove the if TTY/endif blocks from
those 2 files.Cc: linux-serial@vger.kernel.org
Cc: Jiri Slaby
Cc: Greg Kroah-Hartman
Cc: Arnd Bergmann
Suggested-by: Jiri Slaby
Suggested-by: Arnd Bergmann
Acked-by: Arnd Bergmann
Signed-off-by: Randy Dunlap
Link: https://lore.kernel.org/r/20200311225736.32147-3-rdunlap@infradead.org
Signed-off-by: Greg Kroah-Hartman -
Refactor uart_unlock_and_check_sysrq() to:
- explicitly show that we release a port lock which makes
static analyzers happy:CHECK drivers/tty/serial/serial_core.c
.../serial_core.c:3290:17: warning: context imbalance in 'uart_unlock_and_check_sysrq' - unexpected unlock- use flags instead of irqflags to avoid confusion with IRQ flags
- provide one return point
- be more compact
Signed-off-by: Andy Shevchenko
Reviewed-by: Dmitry Safonov
Link: https://lore.kernel.org/r/20200310174337.74109-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman -
Use uart_console() helper in SysRq code instead of open coded variant.
This eliminates the conditional entirely for SERIAL_CORE_CONSOLE=n case.
While here, refactor the conditional to be more compact.Reviewed-by: Dmitry Safonov
Signed-off-by: Andy Shevchenko
Link: https://lore.kernel.org/r/20200310174337.74109-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman -
It is useful to see on the serial console the magic sequence itself
to enable SysRq without rummaging source code.Reviewed-by: Dmitry Safonov
Signed-off-by: Andy Shevchenko
Link: https://lore.kernel.org/r/20200310174337.74109-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman -
Compiler is not happy about using ARRAY_SIZE() in comparison to smaller type:
CC drivers/tty/serial/serial_core.o
.../serial_core.c: In function ‘uart_try_toggle_sysrq’:
.../serial_core.c:3222:24: warning: comparison is always false due to limited range of data type [-Wtype-limits]
3222 | if (++port->sysrq_seq < (ARRAY_SIZE(sysrq_toggle_seq) - 1)) {
| ^Looking at the code it appears that there is an additional weirdness,
i.e. use ARRAY_SIZE() against simple string literal. Yes, the idea probably
was to allow '\0' in the sequence, but it's impractical: kernel configuration
won't accept it to begin with followed by a comment about '\0' before
comparison in question.Drop all these by switching to strlen() and convert code accordingly.
Note, GCC seems clever enough to calculate string length at compile time.
Fixes: 68af43173d3f ("serial/sysrq: Add MAGIC_SYSRQ_SERIAL_SEQUENCE")
Reviewed-by: Dmitry Safonov
Signed-off-by: Andy Shevchenko
Link: https://lore.kernel.org/r/20200310174337.74109-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman
12 Mar, 2020
2 commits
-
To fix the RX cancel command failure, rx_fifo buffer needs to be
flushed in stop_rx() by calling handle_rx().In handle_rx() the data
in rx_fifo buffer is read and then dropped, not sent to upper layers.If set_termios is called before startup, by this time memory is not
allocated to port->rx_fifo buffer, which leads to a NULL pointer
dereference.To avoid this NULL pointer dereference allocate memory to port->rx_fifo
in probe itself.Signed-off-by: satya priya
Reported-by: Stephen Boyd
Link: https://lore.kernel.org/r/1583477228-32231-2-git-send-email-skakit@codeaurora.org
Signed-off-by: Greg Kroah-Hartman -
This driver for the Intel MID never seems to have been properly
integrated upstream: the platform data in
is not used anywhere in the kernel and haven't been since it was
merged into the kernel in 2010.There might be out-of-tree users, so I don't want to delete the
driver, but I will refactor it to use GPIO descriptors, which
means that out-of-tree users will need to adapt.There are several examples in the kernel of how to provide the
resources necessary for using GPIO descriptors to pass in the
GPIO lines, for the MID platform in particular, it will suffice
to inspect the code in files like:
arch/x86/platform/intel-mid/device_libs/platform_bt.cThis refactoring transfers all GPIOs in the driver, including
a hard-coded "PMU reset" in the driver to use GPIO descriptors
instead.The following named GPIO descriptors need to be supplied:
- reset
- power
- mrdy
- srdy
- rst_out
- pmu_resetCc: Russ Gorby
Signed-off-by: Linus Walleij
Reviewed-by: Andy Shevchenko
Link: https://lore.kernel.org/r/20200311083131.693908-2-linus.walleij@linaro.org
Signed-off-by: Greg Kroah-Hartman
