* [PATCH 2/4] serial: 8250: Copy mctrl when register port.
From: Giulio Benetti @ 2018-06-06 9:49 UTC (permalink / raw)
Cc: matwey.kornilov, Giulio Benetti, Greg Kroah-Hartman, Jiri Slaby,
Andy Shevchenko, Matthias Brugger, Kees Cook, Allen Pais,
Sean Young, open list:SERIAL DRIVERS, open list
In-Reply-To: <CAJs94EZqdQAQG+inWvj89FCQtv06LxhY_J4YgNmK8mtvgDTchQ@mail.gmail.com>
RS485 can modify mctrl on startup, especially when RTS_AFTER_SEND is on
TIOCM_RTS is set, then need to keep it set when registering port.
Copy mctrl to new port too.
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
drivers/tty/serial/8250/8250_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
index c8c2b260c681..c8e62fbd6570 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -993,6 +993,7 @@ int serial8250_register_8250_port(struct uart_8250_port *up)
uart->port.unthrottle = up->port.unthrottle;
uart->port.rs485_config = up->port.rs485_config;
uart->port.rs485 = up->port.rs485;
+ uart->port.mctrl = up->port.mctrl;
uart->dma = up->dma;
uart->em485 = up->em485;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 4/8] serial: 8250: Handle case port doesn't have TEMT interrupt using em485.
From: Giulio Benetti @ 2018-06-06 9:36 UTC (permalink / raw)
To: Matwey V. Kornilov
Cc: Greg Kroah-Hartman, Jiri Slaby, Andy Shevchenko, Kees Cook,
Matthias Brugger, Allen Pais, Sean Young, Ed Blake, Stefan Potyra,
Philipp Zabel, Joshua Scott, Vignesh R, Rolf Evers-Fischer,
Aaron Sierra, Rafael Gago, Joel Stanley, Sean Wang, linux-serial,
linux-kernel
In-Reply-To: <CAJs94EZqdQAQG+inWvj89FCQtv06LxhY_J4YgNmK8mtvgDTchQ@mail.gmail.com>
Hi,
Il 05/06/2018 12:51, Matwey V. Kornilov ha scritto:
> Could I ask to split the series into fixes and new features? I see
> that the fixes can be applied, probably it would be better to apply
> them separately from discussing new features.
Sure, I'm going to send 2 different patchsets.
Thanks
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
^ permalink raw reply
* Re: [PATCH 18/19] serdev: ttydev: Serdev driver that creates an standard TTY port
From: Ricardo Ribalda Delgado @ 2018-06-06 7:47 UTC (permalink / raw)
To: Andy Shevchenko
Cc: LKML, open list:SERIAL DRIVERS, Rob Herring, Johan Hovold,
Greg Kroah-Hartman, Jiri Slaby
In-Reply-To: <CAPybu_0zByhDeVf6_Tv_PwU0WL_y6bkVPn0ha+VBvPcxWV4rLA@mail.gmail.com>
Hi Andy,
On Wed, Jun 6, 2018 at 8:58 AM Ricardo Ribalda Delgado
<ricardo.ribalda@gmail.com> wrote:
>
> Hi Andy
> On Tue, Jun 5, 2018 at 3:42 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> >
> > On Tue, May 29, 2018 at 4:10 PM, Ricardo Ribalda Delgado
> > <ricardo.ribalda@gmail.com> wrote:
> > > Standard TTY port that can be loaded/unloaded via serdev sysfs. This
> > > serdev driver can only be used by serdev controllers that are compatible
> > > with ttyport.
> >
> > > +config SERIAL_DEV_CTRL_TTYDEV
> > > + tristate "TTY port dynamically loaded by the Serial Device Bus"
> > > + help
> > > + Say Y here if you want to create a bridge driver between the Serial
> > > + device bus and the TTY chardevice. This driver can be dynamically
> > > + loaded/unloaded by the Serial Device Bus.
> > > +
> > > + If unsure, say Y.
> > > + depends on SERIAL_DEV_CTRL_TTYPORT
> >
> > > + default m
> >
> > Hmm... Can't we survive w/o this by default?
>
> If this module is not available and serdev is enabled the user would
> miss his /dev/ttyS* nodes, so I rather leave this on.
Sorry, brain fart. This is exactly what #if
IS_ENABLED(CONFIG_SERIAL_DEV_CTRL_TTYDEV) prevents.
I have defaulted the module to n as you suggested. You can take a look
to the patches that I plan to submit tomorrow at:
https://github.com/ribalda/linux/tree/serdev2
>
> >
> > > +static int __init ttydev_serdev_init(void)
> > > +{
> > > + return serdev_device_driver_register(&ttydev_serdev_driver);
> > > +}
> > > +module_init(ttydev_serdev_init);
> > > +
> > > +static void __exit ttydev_serdev_exit(void)
> > > +{
> > > + return serdev_device_driver_unregister(&ttydev_serdev_driver);
> > > +}
> > > +module_exit(ttydev_serdev_exit);
> >
> > Isn't above is just a macro in serdev.h?
> > I.e. module_serdev_device_driver().
>
> ACK, thanks!
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
>
> Best regards
>
> --
> Ricardo Ribalda
--
Ricardo Ribalda
^ permalink raw reply
* Re: [PATCH 19/19] serdev: Instantiate a ttydev serdev if acpi and of fails
From: Ricardo Ribalda Delgado @ 2018-06-06 7:28 UTC (permalink / raw)
To: Andy Shevchenko
Cc: LKML, open list:SERIAL DRIVERS, Rob Herring, Johan Hovold,
Greg Kroah-Hartman, Jiri Slaby
In-Reply-To: <CAHp75VeNhtJSa-2NJ5hCJP5yxtcaiNi-P8QA3BYCbGSNRfyvrg@mail.gmail.com>
Hi Andy,
On Tue, Jun 5, 2018 at 3:44 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Tue, May 29, 2018 at 4:10 PM, Ricardo Ribalda Delgado
> <ricardo.ribalda@gmail.com> wrote:
> > If a serdev ttyport controller does not have an acpi nor an of child,
> > create a ttydev as a child of that controller.
> >
> > Doing this allows the removal, addition and replacement of ttydev devices
> > at runtime.
>
> > @@ -619,6 +619,27 @@ static inline int acpi_serdev_register_devices(struct serdev_controller *ctrl)
> > }
> > #endif /* CONFIG_ACPI */
> >
> > +
>
> Redundant blank line.
ACK
>
> > +#if IS_ENABLED(CONFIG_SERIAL_DEV_CTRL_TTYDEV)
>
> > - if (ret_of && ret_acpi) {
> > - dev_dbg(&ctrl->dev, "no devices registered: of:%d acpi:%d\n",
> > - ret_of, ret_acpi);
> > +
> > +#if IS_ENABLED(CONFIG_SERIAL_DEV_CTRL_TTYDEV)
> > + if (ret_of && ret_acpi && ctrl->is_ttyport)
> > + ret_tty = serdev_controller_add_ttydev(ctrl);
> > +#endif
> > +
> > + if (ret_of && ret_acpi && ret_tty) {
> > + dev_dbg(&ctrl->dev,
> > + "no devices registered: of:%d acpi:%d tty:%d\n",
> > + ret_of, ret_acpi, ret_tty);
> > ret = -ENODEV;
> > goto out_dev_del;
> > }
>
> Wouldn't be better to leave above if-condition and introduce your
> stuff inside it?
I have redesign the logic in the function on the next version
Thanks
--
Ricardo Ribalda
^ permalink raw reply
* Re: [PATCH 18/19] serdev: ttydev: Serdev driver that creates an standard TTY port
From: Ricardo Ribalda Delgado @ 2018-06-06 6:58 UTC (permalink / raw)
To: Andy Shevchenko
Cc: LKML, open list:SERIAL DRIVERS, Rob Herring, Johan Hovold,
Greg Kroah-Hartman, Jiri Slaby
In-Reply-To: <CAHp75VfFTtysSBvYfmCMoKZz8BpHb73qh=Zy-gpn6RKO2DE-5Q@mail.gmail.com>
Hi Andy
On Tue, Jun 5, 2018 at 3:42 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Tue, May 29, 2018 at 4:10 PM, Ricardo Ribalda Delgado
> <ricardo.ribalda@gmail.com> wrote:
> > Standard TTY port that can be loaded/unloaded via serdev sysfs. This
> > serdev driver can only be used by serdev controllers that are compatible
> > with ttyport.
>
> > +config SERIAL_DEV_CTRL_TTYDEV
> > + tristate "TTY port dynamically loaded by the Serial Device Bus"
> > + help
> > + Say Y here if you want to create a bridge driver between the Serial
> > + device bus and the TTY chardevice. This driver can be dynamically
> > + loaded/unloaded by the Serial Device Bus.
> > +
> > + If unsure, say Y.
> > + depends on SERIAL_DEV_CTRL_TTYPORT
>
> > + default m
>
> Hmm... Can't we survive w/o this by default?
If this module is not available and serdev is enabled the user would
miss his /dev/ttyS* nodes, so I rather leave this on.
>
> > +static int __init ttydev_serdev_init(void)
> > +{
> > + return serdev_device_driver_register(&ttydev_serdev_driver);
> > +}
> > +module_init(ttydev_serdev_init);
> > +
> > +static void __exit ttydev_serdev_exit(void)
> > +{
> > + return serdev_device_driver_unregister(&ttydev_serdev_driver);
> > +}
> > +module_exit(ttydev_serdev_exit);
>
> Isn't above is just a macro in serdev.h?
> I.e. module_serdev_device_driver().
ACK, thanks!
>
> --
> With Best Regards,
> Andy Shevchenko
Best regards
--
Ricardo Ribalda
^ permalink raw reply
* [GIT PULL] TTY/Serial patches for 4.18-rc1
From: Greg KH @ 2018-06-05 18:59 UTC (permalink / raw)
To: Linus Torvalds, Jiri Slaby
Cc: Stephen Rothwell, Andrew Morton, linux-kernel, linux-serial
The following changes since commit 6da6c0db5316275015e8cc2959f12a17584aeb64:
Linux v4.17-rc3 (2018-04-29 14:17:42 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/ tags/tty-4.18-rc1
for you to fetch changes up to 4b4ecd9cb853c14913a3726cfcc60ccda1d2924a:
vt: Perform safe console erase only once (2018-05-25 18:01:16 +0200)
----------------------------------------------------------------
TTY/Serial patches for 4.18-rc1
Here is the big tty/serial driver update for 4.18-rc1.
There's nothing major here, just lots of serial driver updates. Full
details are in the shortlog, nothing anything specific to call out here.
All have been in linux-next for a while with no reported issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----------------------------------------------------------------
Colin Ian King (1):
tty: nozomi: fix spelling mistake in macro NOZOMI_STATE_UKNOWN
DaeRyong Jeong (1):
tty: Fix data race in tty_insert_flip_string_fixed_flag
Dan Carpenter (1):
serial/aspeed-vuart: fix a couple mod_timer() calls
Daniel Wagner (1):
serial: sh-sci: Use spin_{try}lock_irqsave instead of open coding version
Dave Martin (1):
tty: pl011: Avoid spuriously stuck-off interrupts
Douglas Anderson (1):
serial: core: Make sure compiler barfs for 16-byte earlycon names
Evan Green (1):
tty: serial: msm_geni_serial: Fix TX infinite loop
Geert Uytterhoeven (2):
serial: sh-sci: Add support for dynamic instances
serial: Remove depends on HAS_DMA in case of platform dependency
Giulio Benetti (1):
tty: fix typo in ASYNCB_FOURPORT comment
Greg Kroah-Hartman (1):
Merge 4.17-rc3 into tty-next
Jeremy Kerr (4):
serial: Introduce UPSTAT_SYNC_FIFO for synchronised FIFOs
serial/8250: export serial8250_read_char
serial/aspeed-vuart: Implement rx throttling
serial/aspeed-vuart: Implement quick throttle mechanism
Jia-Ju Bai (1):
tty: ipwireless: Replace GFP_ATOMIC with GFP_KERNEL in ipwireless_network_create
Joey Pabalinas (2):
tty/nozomi: cleanup DUMP() macro
tty/nozomi: fix inconsistent indentation
John Crispin (1):
tty: serial: drop ATH79 specific SoC symbols
John Garry (1):
serial: 8250_of: Add IO space support
Joshua Scott (1):
serial: 8250_dw: Limit dw8250_tx_wait_empty quirk to armada-38x devices
Karthikeyan Ramasubramanian (8):
tty: serial: qcom_geni_serial: Add comments for clarification
tty: serial: qcom_geni_serial: Cleanup redundant code
tty: serial: qcom_geni_serial: Use min3 to find minimum of 3 values
tty: serial: qcom_geni_serial: Initialize console port statically
tty: serial: qcom_geni_serial: Remove unnecessary memory barrier
tty: serial: qcom_geni_serial: Use iowrite32_rep to write to FIFO
tty: serial: qcom_geni_serial: Return IRQ_NONE for spurious interrupts
tty: serial: qcom_geni_serial: Add early console support
Kurt Kanzenbach (1):
tty: serial: 8250: pass IRQ shared flag to UART ports
Luc Van Oostenryck (1):
tty: n_gsm: fix gsm_mux_net_start_xmit()'s return type
Marek Szyprowski (2):
serial: samsung: fix maxburst parameter for DMA transactions
serial: samsung: check DMA engine capabilities before using DMA mode
Marek Vasut (1):
serial: 8250: Add missing rxtrig_bytes on Altera 16550 UART
Michal Simek (7):
earlycon: Initialize port->uartclk based on clock-frequency property
serial: 8250_early: Setup divider when uartclk is passed
serial: uartps: Remove console_initcall from the driver
serial: uartps: Use dynamic array for console port
serial: uartps: Move cnds_uart_get_port to probe
serial: uartps: Remove static port array
earlycon: Remove hardcoded port->uartclk initialization in of_setup_earlycon
Miquel Raynal (1):
serial: mvebu-uart: add suspend/resume support
Nicolas Pitre (1):
vt: Perform safe console erase only once
Pascal Huerst (2):
tty: serial: msm_serial: Add support for suspend/resume
tty: serial: msm_serial: Add __maybe_unused to suspend/resume callbacks
Phil Edworthy (1):
serial: 8250_dw: Fix runtime PM handling
Sebastian Andrzej Siewior (1):
tty/serial: atmel: use port->name as name in request_irq()
Sebastian Reichel (4):
serial: imx: cleanup imx_uart_disable_dma()
serial: imx: dma_unmap_sg buffers on shutdown
serial: imx: drop CTS/RTS handling from shutdown
serial: imx: disable UCR4_OREN on shutdown
Stefan Potyra (1):
sc16is7xx: Check for an error when the clock is enabled.
Tony Lindgren (1):
serial: 8250: omap: Fix idling of clocks for unused uarts
Ulrich Hecht (1):
serial: sh-sci: Support for HSCIF RX sampling point adjustment
Vignesh R (1):
serial: 8250: omap: Provide ability to enable/disable UART as wakeup source
Wolfram Sang (1):
tty: serial: simplify getting .drvdata
Documentation/admin-guide/kernel-parameters.txt | 6 +
arch/arm/boot/dts/armada-38x.dtsi | 4 +-
drivers/tty/ipwireless/network.c | 2 +-
drivers/tty/n_gsm.c | 2 +-
drivers/tty/nozomi.c | 104 +++++++-------
drivers/tty/pty.c | 3 +
drivers/tty/serial/8250/8250_aspeed_vuart.c | 125 +++++++++++++++++
drivers/tty/serial/8250/8250_dw.c | 35 ++++-
drivers/tty/serial/8250/8250_early.c | 2 +-
drivers/tty/serial/8250/8250_of.c | 63 +++++----
drivers/tty/serial/8250/8250_omap.c | 27 +++-
drivers/tty/serial/8250/8250_port.c | 6 +-
drivers/tty/serial/Kconfig | 8 +-
drivers/tty/serial/amba-pl011.c | 16 +++
drivers/tty/serial/atmel_serial.c | 5 +-
drivers/tty/serial/earlycon.c | 5 +-
drivers/tty/serial/imx.c | 43 +++---
drivers/tty/serial/msm_serial.c | 23 +++
drivers/tty/serial/mvebu-uart.c | 64 +++++++++
drivers/tty/serial/qcom_geni_serial.c | 177 ++++++++++++++++--------
drivers/tty/serial/samsung.c | 40 ++++--
drivers/tty/serial/sc16is7xx.c | 5 +-
drivers/tty/serial/serial_core.c | 4 +-
drivers/tty/serial/sh-sci.c | 81 +++++++----
drivers/tty/serial/sh-sci.h | 4 +
drivers/tty/serial/st-asc.c | 6 +-
drivers/tty/serial/xilinx_uartps.c | 108 ++++++---------
drivers/tty/vt/vt.c | 16 +--
include/linux/serial_8250.h | 1 +
include/linux/serial_core.h | 4 +-
include/uapi/linux/tty_flags.h | 2 +-
31 files changed, 694 insertions(+), 297 deletions(-)
^ permalink raw reply
* Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
From: Tony Lindgren @ 2018-06-05 14:14 UTC (permalink / raw)
To: Rob Herring
Cc: Nishanth Menon, Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, open list:SERIAL DRIVERS,
linux-kernel@vger.kernel.org, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Vignesh R, Tero Kristo, Russell King, Sudeep Holla
In-Reply-To: <CAL_JsqJusWTvr4A_-Bk81meYddMHBMJ4=Fch6L0MFoF7HfBW2w@mail.gmail.com>
* Rob Herring <robh+dt@kernel.org> [180605 14:08]:
> On Tue, Jun 5, 2018 at 1:05 AM, Nishanth Menon <nm@ti.com> wrote:
> > + soc0: soc0 {
> > + compatible = "simple-bus";
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
>
> Really need 64-bit addresses and sizes? Use ranges to limit the
> address space if possible.
And in addition to using ranges, please set up separate bus instances
for the interconnects. This will then allow you to probe WKUP or
similar instance first and the other bus instances after. And that
pretty much allows you to get rid of the annoying -EPROBE_DEFER
ping pong and allows making clocks proper device drivers ;)
Regards,
Tony
^ permalink raw reply
* Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
From: Rob Herring @ 2018-06-05 14:05 UTC (permalink / raw)
To: Nishanth Menon
Cc: Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, open list:SERIAL DRIVERS,
linux-kernel@vger.kernel.org, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Tony Lindgren, Vignesh R, Tero Kristo, Russell King, Sudeep Holla
In-Reply-To: <20180605060510.32473-1-nm@ti.com>
On Tue, Jun 5, 2018 at 1:05 AM, Nishanth Menon <nm@ti.com> wrote:
> The AM654 SoC is a lead device of the K3 Multicore SoC architecture
> platform, targeted for broad market and industrial control with aim to
> meet the complex processing needs of modern embedded products.
>
> Some highlights of this SoC are:
> * Quad ARMv8 A53 cores split over two clusters
> * GICv3 compliant GIC500
> * Configurable L3 Cache and IO-coherent architecture
> * Dual lock-step capable R5F uC for safety-critical applications
> * High data throughput capable distributed DMA architecture under NAVSS
> * Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual
> PRUs and dual RTUs
> * Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
> * Centralized System Controller for Security, Power, and Resource
> management.
> * Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD
> * Flash subystem with OSPI and Hyperbus interfaces
> * Multimedia capability with CAL, DSS7-UL, SGX544, McASP
> * Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI,
> GPIO
>
> See AM65x Technical Reference Manual (SPRUID7, April 2018)
> for further details: http://www.ti.com/lit/pdf/spruid7
>
> We introduce the Kconfig symbol for the SoC along with this patch since
> it is logically relevant point, however the usage is in subsequent
> patches.
>
> NOTE: AM654 is the first of the device variants, hence we introduce a
> generic am6.dtsi.
>
> Signed-off-by: Benjamin Fair <b-fair@ti.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> MAINTAINERS | 1 +
> arch/arm64/boot/dts/ti/k3-am6.dtsi | 144 +++++++++++++++++++++++++++++++++++
> arch/arm64/boot/dts/ti/k3-am654.dtsi | 117 ++++++++++++++++++++++++++++
> drivers/soc/ti/Kconfig | 14 ++++
> 4 files changed, 276 insertions(+)
> create mode 100644 arch/arm64/boot/dts/ti/k3-am6.dtsi
> create mode 100644 arch/arm64/boot/dts/ti/k3-am654.dtsi
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index cfb35b252ac7..5f5c4eddec7a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2092,6 +2092,7 @@ M: Nishanth Menon <nm@ti.com>
> L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> S: Supported
> F: Documentation/devicetree/bindings/arm/ti/k3.txt
> +F: arch/arm64/boot/dts/ti/k3-*
>
> ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE
> M: Santosh Shilimkar <ssantosh@kernel.org>
> diff --git a/arch/arm64/boot/dts/ti/k3-am6.dtsi b/arch/arm64/boot/dts/ti/k3-am6.dtsi
> new file mode 100644
> index 000000000000..cdfa12173aac
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am6.dtsi
> @@ -0,0 +1,144 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for AM6 SoC Family
> + *
> + * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
> + */
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/ {
> + model = "Texas Instruments K3 AM654 SoC";
> + compatible = "ti,am654";
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + aliases {
> + serial0 = &wkup_uart0;
> + serial1 = &mcu_uart0;
> + serial2 = &main_uart0;
> + serial3 = &main_uart1;
> + serial4 = &main_uart2;
> + };
> +
> + chosen { };
> +
> + firmware {
> + optee {
> + compatible = "linaro,optee-tz";
> + method = "smc";
> + };
> +
> + psci: psci {
> + compatible = "arm,psci-1.0";
> + method = "smc";
> + };
> + };
> +
> + soc0: soc0 {
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
Really need 64-bit addresses and sizes? Use ranges to limit the
address space if possible.
> +
> + a53_timer0: timer-cl0-cpu0 {
> + compatible = "arm,armv8-timer";
> + interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, /* cntpsirq */
> + <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, /* cntpnsirq */
> + <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, /* cntvirq */
> + <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; /* cnthpirq */
> + };
> +
> + pmu: pmu {
> + compatible = "arm,armv8-pmuv3";
> + /* Recommendation from GIC500 TRM Table A.3 */
> + interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
> + };
These 2 nodes aren't on the bus, so move them up a level.
> +
> + gic: interrupt-controller@1800000 {
> + compatible = "arm,gic-v3";
gic-500?
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> + #interrupt-cells = <3>;
> + interrupt-controller;
> + /*
> + * NOTE: we are NOT gicv2 backward compat, so no GICC,
> + * GICH or GICV
The compatible should imply this.
> + */
> + reg = <0x0 0x01800000 0x0 0x10000>, /* GICD */
> + <0x0 0x01880000 0x0 0x90000>; /* GICR */
> +
> + /*
> + * vcpumntirq:
> + * virtual CPU interface maintenance interrupt
> + */
> + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> +
> + gic_its: gic-its@1000000 {
> + compatible = "arm,gic-v3-its";
> + reg = <0x0 0x1820000 0x0 0x10000>;
> + msi-controller;
> + #msi-cells = <1>;
> + };
> + };
> +
> + wkup_uart0: serial@42300000 {
> + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
> + reg = <0x0 0x42300000 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 697 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + status = "disabled";
> + };
> +
> + mcu_uart0: serial@40a00000 {
> + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
> + reg = <0x0 0x40a00000 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 565 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <96000000>;
> + current-speed = <115200>;
> + status = "disabled";
> + };
> +
> + main_uart0: serial@2800000 {
> + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
> + reg = <0x0 0x02800000 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + status = "disabled";
> + };
> +
> + main_uart1: serial@2810000 {
> + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
> + reg = <0x0 0x02810000 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + status = "disabled";
> + };
> +
> + main_uart2: serial@2820000 {
> + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
> + reg = <0x0 0x02820000 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + status = "disabled";
> + };
> + };
> +};
> diff --git a/arch/arm64/boot/dts/ti/k3-am654.dtsi b/arch/arm64/boot/dts/ti/k3-am654.dtsi
> new file mode 100644
> index 000000000000..d9b70081daba
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am654.dtsi
> @@ -0,0 +1,117 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for AM6 SoC family in Quad core configuration
> + *
> + * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
> + */
> +
> +#include "k3-am6.dtsi"
> +
> +/ {
> + cpus: cpus {
Really need a label?
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cpu-map {
IIRC, this goes at the top level.
> + cluster0: cluster0 {
> + core0 {
> + cpu = <&cpu0>;
> + };
> +
> + core1 {
> + cpu = <&cpu1>;
> + };
> + };
> +
> + cluster1: cluster1 {
> + core0 {
> + cpu = <&cpu2>;
> + };
> +
> + core1 {
> + cpu = <&cpu3>;
> + };
> + };
> + };
> +
> + cpu0: cpu@0 {
> + compatible = "arm,cortex-a53","arm,armv8";
space between compatibles.
> + reg = <0x000>;
> + device_type = "cpu";
> + enable-method = "psci";
> + i-cache-size = <0x8000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <256>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
All this should be discoverable.
> + next-level-cache = <&L2_0>;
> + };
> +
> + cpu1: cpu@1 {
> + compatible = "arm,cortex-a53","arm,armv8";
> + reg = <0x001>;
> + device_type = "cpu";
> + enable-method = "psci";
> + i-cache-size = <0x8000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <256>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + next-level-cache = <&L2_0>;
> + };
> +
> + cpu2: cpu@100 {
> + compatible = "arm,cortex-a53","arm,armv8";
> + reg = <0x100>;
> + device_type = "cpu";
> + enable-method = "psci";
> + i-cache-size = <0x8000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <256>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + next-level-cache = <&L2_1>;
> + };
> +
> + cpu3: cpu@101 {
> + compatible = "arm,cortex-a53","arm,armv8";
> + reg = <0x101>;
> + device_type = "cpu";
> + enable-method = "psci";
> + i-cache-size = <0x8000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <256>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + next-level-cache = <&L2_1>;
> + };
> + };
> +};
> +
> +&soc0 {
> + L2_0: l2-cache0 {
> + compatible = "cache";
Is this documented?
> + cache-level = <2>;
> + cache-size = <0x80000>;
> + cache-line-size = <64>;
> + cache-sets = <512>;
Discoverable?
> + next-level-cache = <&msmc_l3>;
> + };
> +
> + L2_1: l2-cache1 {
> + compatible = "cache";
> + cache-level = <2>;
> + cache-size = <0x80000>;
> + cache-line-size = <64>;
> + cache-sets = <512>;
> + next-level-cache = <&msmc_l3>;
> + };
> +
> + msmc_l3: l3-cache0 {
> + compatible = "cache";
Is this something TI specific or follows the (ARM) architecture?
> + cache-level = <3>;
> + };
> +};
> diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
> index 92770d84a288..be4570baad96 100644
> --- a/drivers/soc/ti/Kconfig
> +++ b/drivers/soc/ti/Kconfig
> @@ -1,3 +1,17 @@
> +# 64-bit ARM SoCs from TI
> +if ARM64
> +
> +if ARCH_K3
> +
> +config ARCH_K3_AM6_SOC
This should be in another patch (or dropped?).
> + bool "K3 AM6 SoC"
> + help
> + Enable support for TI's AM6 SoC Family support
> +
> +endif
> +
> +endif
> +
> #
> # TI SOC drivers
> #
> --
> 2.15.1
>
^ permalink raw reply
* Re: [PATCH 04/19] Bluetooth: hci_nokia: Add serdev_id_table
From: Marcel Holtmann @ 2018-06-05 13:53 UTC (permalink / raw)
To: Ricardo Ribalda Delgado
Cc: LKML, linux-serial, Johan Hedberg, Rob Herring, Johan Hovold,
linux-bluetooth
In-Reply-To: <20180529131014.18641-5-ricardo.ribalda@gmail.com>
Hi Ricardo,
> Describe which hardware is supported by the current driver.
>
> Cc: Marcel Holtmann <marcel@holtmann.org>
> Cc: Johan Hedberg <johan.hedberg@gmail.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Johan Hovold <johan@kernel.org>
> Cc: linux-bluetooth@vger.kernel.org
> Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
> ---
> drivers/bluetooth/hci_nokia.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/bluetooth/hci_nokia.c b/drivers/bluetooth/hci_nokia.c
> index 3539fd03f47e..e32dfcd56b8d 100644
> --- a/drivers/bluetooth/hci_nokia.c
> +++ b/drivers/bluetooth/hci_nokia.c
> @@ -801,6 +801,11 @@ static const struct of_device_id nokia_bluetooth_of_match[] = {
> MODULE_DEVICE_TABLE(of, nokia_bluetooth_of_match);
> #endif
>
> +static struct serdev_device_id nokia_bluetooth_serdev_id[] = {
> + { "hp4-bluetooth", },
> + {},
> +};
> +
> static struct serdev_device_driver nokia_bluetooth_serdev_driver = {
> .probe = nokia_bluetooth_serdev_probe,
> .remove = nokia_bluetooth_serdev_remove,
> @@ -809,6 +814,7 @@ static struct serdev_device_driver nokia_bluetooth_serdev_driver = {
> .pm = &nokia_bluetooth_pm_ops,
> .of_match_table = of_match_ptr(nokia_bluetooth_of_match),
> },
> + .id_table = nokia_bluetooth_serdev_id,
> };
I would actually skip this hardware. First of all it is such a dedicated custom Nokia transport and hardware, and secondly it is no longer produced anyway.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 19/19] serdev: Instantiate a ttydev serdev if acpi and of fails
From: Andy Shevchenko @ 2018-06-05 13:44 UTC (permalink / raw)
To: Ricardo Ribalda Delgado
Cc: Linux Kernel Mailing List, open list:SERIAL DRIVERS, Rob Herring,
Johan Hovold, Greg Kroah-Hartman, Jiri Slaby
In-Reply-To: <20180529131014.18641-20-ricardo.ribalda@gmail.com>
On Tue, May 29, 2018 at 4:10 PM, Ricardo Ribalda Delgado
<ricardo.ribalda@gmail.com> wrote:
> If a serdev ttyport controller does not have an acpi nor an of child,
> create a ttydev as a child of that controller.
>
> Doing this allows the removal, addition and replacement of ttydev devices
> at runtime.
> @@ -619,6 +619,27 @@ static inline int acpi_serdev_register_devices(struct serdev_controller *ctrl)
> }
> #endif /* CONFIG_ACPI */
>
> +
Redundant blank line.
> +#if IS_ENABLED(CONFIG_SERIAL_DEV_CTRL_TTYDEV)
> - if (ret_of && ret_acpi) {
> - dev_dbg(&ctrl->dev, "no devices registered: of:%d acpi:%d\n",
> - ret_of, ret_acpi);
> +
> +#if IS_ENABLED(CONFIG_SERIAL_DEV_CTRL_TTYDEV)
> + if (ret_of && ret_acpi && ctrl->is_ttyport)
> + ret_tty = serdev_controller_add_ttydev(ctrl);
> +#endif
> +
> + if (ret_of && ret_acpi && ret_tty) {
> + dev_dbg(&ctrl->dev,
> + "no devices registered: of:%d acpi:%d tty:%d\n",
> + ret_of, ret_acpi, ret_tty);
> ret = -ENODEV;
> goto out_dev_del;
> }
Wouldn't be better to leave above if-condition and introduce your
stuff inside it?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 18/19] serdev: ttydev: Serdev driver that creates an standard TTY port
From: Andy Shevchenko @ 2018-06-05 13:42 UTC (permalink / raw)
To: Ricardo Ribalda Delgado
Cc: Linux Kernel Mailing List, open list:SERIAL DRIVERS, Rob Herring,
Johan Hovold, Greg Kroah-Hartman, Jiri Slaby
In-Reply-To: <20180529131014.18641-19-ricardo.ribalda@gmail.com>
On Tue, May 29, 2018 at 4:10 PM, Ricardo Ribalda Delgado
<ricardo.ribalda@gmail.com> wrote:
> Standard TTY port that can be loaded/unloaded via serdev sysfs. This
> serdev driver can only be used by serdev controllers that are compatible
> with ttyport.
> +config SERIAL_DEV_CTRL_TTYDEV
> + tristate "TTY port dynamically loaded by the Serial Device Bus"
> + help
> + Say Y here if you want to create a bridge driver between the Serial
> + device bus and the TTY chardevice. This driver can be dynamically
> + loaded/unloaded by the Serial Device Bus.
> +
> + If unsure, say Y.
> + depends on SERIAL_DEV_CTRL_TTYPORT
> + default m
Hmm... Can't we survive w/o this by default?
> +static int __init ttydev_serdev_init(void)
> +{
> + return serdev_device_driver_register(&ttydev_serdev_driver);
> +}
> +module_init(ttydev_serdev_init);
> +
> +static void __exit ttydev_serdev_exit(void)
> +{
> + return serdev_device_driver_unregister(&ttydev_serdev_driver);
> +}
> +module_exit(ttydev_serdev_exit);
Isn't above is just a macro in serdev.h?
I.e. module_serdev_device_driver().
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 04/19] Bluetooth: hci_nokia: Add serdev_id_table
From: Andy Shevchenko @ 2018-06-05 13:36 UTC (permalink / raw)
To: Ricardo Ribalda Delgado
Cc: Linux Kernel Mailing List, open list:SERIAL DRIVERS,
Marcel Holtmann, Johan Hedberg, Rob Herring, Johan Hovold,
linux-bluetooth
In-Reply-To: <20180529131014.18641-5-ricardo.ribalda@gmail.com>
On Tue, May 29, 2018 at 4:09 PM, Ricardo Ribalda Delgado
<ricardo.ribalda@gmail.com> wrote:
> Describe which hardware is supported by the current driver.
> +static struct serdev_device_id nokia_bluetooth_serdev_id[] = {
> + { "hp4-bluetooth", },
> + {},
Terminator line better w/o comma.
> +};
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 4/8] serial: 8250: Handle case port doesn't have TEMT interrupt using em485.
From: Matwey V. Kornilov @ 2018-06-05 10:51 UTC (permalink / raw)
To: Giulio Benetti
Cc: Greg Kroah-Hartman, Jiri Slaby, Andy Shevchenko, Kees Cook,
Matthias Brugger, Allen Pais, Sean Young, Ed Blake, Stefan Potyra,
Philipp Zabel, Joshua Scott, Vignesh R, Rolf Evers-Fischer,
Aaron Sierra, Rafael Gago, Joel Stanley, Sean Wang, linux-serial,
linux-kernel
In-Reply-To: <d130718a-444d-3a39-4da8-0f0b907f850d@micronovasrl.com>
2018-06-04 21:50 GMT+03:00 Giulio Benetti <giulio.benetti@micronovasrl.com>:
> Il 04/06/2018 19:40, Matwey V. Kornilov ha scritto:
>>
>> 01.06.2018 15:40, Giulio Benetti пишет:
>>>
>>> Some 8250 ports only have TEMT interrupt, so current implementation
>>> can't work for ports without it. The only chance to make it work is to
>>> loop-read on LSR register.
>>>
>>> With NO TEMT interrupt check if both TEMT and THRE are set looping on
>>> LSR register.
>>>
>>> Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
>>> ---
>>> drivers/tty/serial/8250/8250.h | 2 +-
>>> drivers/tty/serial/8250/8250_dw.c | 2 +-
>>> drivers/tty/serial/8250/8250_omap.c | 2 +-
>>> drivers/tty/serial/8250/8250_port.c | 26 ++++++++++++++++++--------
>>> include/linux/serial_8250.h | 1 +
>>> 5 files changed, 22 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/tty/serial/8250/8250.h
>>> b/drivers/tty/serial/8250/8250.h
>>> index ebfb0bd5bef5..5c6ae5f69432 100644
>>> --- a/drivers/tty/serial/8250/8250.h
>>> +++ b/drivers/tty/serial/8250/8250.h
>>> @@ -136,7 +136,7 @@ void serial8250_rpm_put(struct uart_8250_port *p);
>>> void serial8250_rpm_get_tx(struct uart_8250_port *p);
>>> void serial8250_rpm_put_tx(struct uart_8250_port *p);
>>> -int serial8250_em485_init(struct uart_8250_port *p);
>>> +int serial8250_em485_init(struct uart_8250_port *p, bool has_temt_isr);
>>> void serial8250_em485_destroy(struct uart_8250_port *p);
>>> static inline void serial8250_out_MCR(struct uart_8250_port *up, int
>>> value)
>>> diff --git a/drivers/tty/serial/8250/8250_dw.c
>>> b/drivers/tty/serial/8250/8250_dw.c
>>> index 0f8b4da03d4e..888280ff5451 100644
>>> --- a/drivers/tty/serial/8250/8250_dw.c
>>> +++ b/drivers/tty/serial/8250/8250_dw.c
>>> @@ -330,7 +330,7 @@ static int dw8250_rs485_config(struct uart_port *p,
>>> * are idempotent
>>> */
>>> if (rs485->flags & SER_RS485_ENABLED) {
>>> - int ret = serial8250_em485_init(up);
>>> + int ret = serial8250_em485_init(up, false);
>>> if (ret) {
>>> rs485->flags &= ~SER_RS485_ENABLED;
>>> diff --git a/drivers/tty/serial/8250/8250_omap.c
>>> b/drivers/tty/serial/8250/8250_omap.c
>>> index 624b501fd253..ab483c8b30c8 100644
>>> --- a/drivers/tty/serial/8250/8250_omap.c
>>> +++ b/drivers/tty/serial/8250/8250_omap.c
>>> @@ -725,7 +725,7 @@ static int omap_8250_rs485_config(struct uart_port
>>> *port,
>>> * are idempotent
>>> */
>>> if (rs485->flags & SER_RS485_ENABLED) {
>>> - int ret = serial8250_em485_init(up);
>>> + int ret = serial8250_em485_init(up, true);
>>> if (ret) {
>>> rs485->flags &= ~SER_RS485_ENABLED;
>>> diff --git a/drivers/tty/serial/8250/8250_port.c
>>> b/drivers/tty/serial/8250/8250_port.c
>>> index 95833cbc4338..e14badbbf181 100644
>>> --- a/drivers/tty/serial/8250/8250_port.c
>>> +++ b/drivers/tty/serial/8250/8250_port.c
>>> @@ -599,15 +599,16 @@ EXPORT_SYMBOL_GPL(serial8250_rpm_put);
>>> /**
>>> * serial8250_em485_init() - put uart_8250_port into rs485 emulating
>>> * @p: uart_8250_port port instance
>>> + * @p: bool specify if 8250 port has TEMT interrupt or not
>>> *
>>> * The function is used to start rs485 software emulating on the
>>> * &struct uart_8250_port* @p. Namely, RTS is switched before/after
>>> * transmission. The function is idempotent, so it is safe to call
>>> it
>>> * multiple times.
>>> *
>>> - * The caller MUST enable interrupt on empty shift register before
>>> - * calling serial8250_em485_init(). This interrupt is not a part of
>>> - * 8250 standard, but implementation defined.
>>> + * If has_temt_isr is passed as true, the caller MUST enable
>>> interrupt
>>> + * on empty shift register before calling serial8250_em485_init().
>>> + * This interrupt is not a part of 8250 standard, but implementation
>>> defined.
>>> *
>>> * The function is supposed to be called from .rs485_config callback
>>> * or from any other callback protected with p->port.lock spinlock.
>>> @@ -616,7 +617,7 @@ EXPORT_SYMBOL_GPL(serial8250_rpm_put);
>>> *
>>> * Return 0 - success, -errno - otherwise
>>> */
>>> -int serial8250_em485_init(struct uart_8250_port *p)
>>> +int serial8250_em485_init(struct uart_8250_port *p, bool has_temt_isr)
>>> {
>>> if (p->em485)
>>> return 0;
>>> @@ -633,6 +634,7 @@ int serial8250_em485_init(struct uart_8250_port *p)
>>> p->em485->start_tx_timer.function =
>>> &serial8250_em485_handle_start_tx;
>>> p->em485->port = p;
>>> p->em485->active_timer = NULL;
>>> + p->em485->has_temt_isr = has_temt_isr;
>>> serial8250_em485_rts_after_send(p);
>>> return 0;
>>> @@ -1517,11 +1519,19 @@ static inline void __stop_tx(struct
>>> uart_8250_port *p)
>>> /*
>>> * To provide required timeing and allow FIFO transfer,
>>> * __stop_tx_rs485() must be called only when both FIFO
>>> and
>>> - * shift register are empty. It is for device driver to
>>> enable
>>> - * interrupt on TEMT.
>>> + * shift register are empty. If 8250 port supports it,
>>> + * it is for device driver to enable interrupt on TEMT.
>>> + * Otherwise must loop-read until TEMT and THRE flags are
>>> set.
>>> */
>>> - if ((lsr & BOTH_EMPTY) != BOTH_EMPTY)
>>> - return;
>>> + if (em485->has_temt_isr) {
>>> + if ((lsr & BOTH_EMPTY) != BOTH_EMPTY)
>>> + return;
>>> + } else {
>>> + while ((lsr & BOTH_EMPTY) != BOTH_EMPTY) {
>>> + lsr = serial_in(p, UART_LSR);
>>> + cpu_relax();
>>> + }
>>
>>
>> What happens if TEMP never be empty after interruption occurring?
>>
>
> I've added the field has_temt_isr to identify if peripheral provides or not
> TEMT interrupt. In DW case, differentely from OMAP case, there is not TEMT
> interrupt, at least on Datasheet I've found.
> At this time I don't have access to latest Datasheet.
>
> Specifying has_temt_isr = false during serial8250_em485_init(),
> I assume TEMT interrupt is not available and also is not enabled.
>
> IMHO the only possible case to loop inside there is if shift register is
> costantly filled, but soon or late it will get empty(hope I didn't miss
> something).
Well, I would not rely on this behavior. Eventually, powersave or
something else disable transmit with characters left in buffer, or
happens something like that.
Could I ask to split the series into fixes and new features? I see
that the fixes can be applied, probably it would be better to apply
them separately from discussing new features.
>
> --
> Giulio Benetti
> CTO
>
> MICRONOVA SRL
> Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
> Tel. 049/8931563 - Fax 049/8931346
> Cod.Fiscale - P.IVA 02663420285
> Capitale Sociale € 26.000 i.v.
> Iscritta al Reg. Imprese di Padova N. 02663420285
> Numero R.E.A. 258642
--
With best regards,
Matwey V. Kornilov
^ permalink raw reply
* Re: [PATCH v4.9-stable] serial: pl011: add console matching function
From: Greg KH @ 2018-06-05 10:19 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: stable, leif.lindholm, graeme.gregory, linux, jslaby,
linux-serial, linux-arm-kernel
In-Reply-To: <20180604131612.14407-1-ard.biesheuvel@linaro.org>
On Mon, Jun 04, 2018 at 03:16:12PM +0200, Ard Biesheuvel wrote:
> From: Aleksey Makarov <aleksey.makarov@linaro.org>
>
> Commit 10879ae5f12e9cab3c4e8e9504c1aaa8a033bde7 upstream.
>
> This patch adds function pl011_console_match() that implements
> method match of struct console. It allows to match consoles against
> data specified in a string, for example taken from command line or
> compiled by ACPI SPCR table handler.
>
> This patch was merged to tty-next but then reverted because of
> conflict with
>
> commit 46e36683f433 ("serial: earlycon: Extend earlycon command line option to support 64-bit addresses")
>
> Now it is fixed.
>
> Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
> Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
> Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
> Tested-by: Christopher Covington <cov@codeaurora.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
>
> Please consider for v4.9-stable. It is the missing puzzle piece for SPCR
> support on arm64 ACPI systems, which got merged for v4.9 [0]. Now that more
> systems are becoming available to people working in the kernel community, it
> turns out that v4.9 distro installers (e.g., Debian Stretch) won't work
> unless you pass a 'console=' parameter explicitly, which is annoying.
> Given that it was clearly the intent to include this code at the time,
> I hope it will be considered for backporting.
>
> [0] To quote the tty maintainer:
>
> Also in here is the long-suffering ACPI SPCR patchset, which was
> passed around from maintainer to maintainer like a hot-potato. Seems I
> was the sucker^Wlucky one. All of those patches have been acked by the
> various subsystem maintainers as well.
Now queued up, thanks.
greg k-h
^ permalink raw reply
* Re: [PATCH 1/2] serial: 8250: enable SERIAL_MCTRL_GPIO by default.
From: Andy Shevchenko @ 2018-06-05 10:00 UTC (permalink / raw)
To: Giulio Benetti, Greg Kroah-Hartman
Cc: Jiri Slaby, Kees Cook, Matthias Brugger, Allen Pais, Sean Young,
Ed Blake, Stefan Potyra, Philipp Zabel, Joshua Scott, Vignesh R,
Rolf Evers-Fischer, Aaron Sierra, Rafael Gago, Joel Stanley,
Sean Wang, linux-serial, linux-kernel, Yegor Yefremov
In-Reply-To: <7f4d688c-095a-d056-1edd-430bfc4e00da@micronovasrl.com>
On Mon, 2018-06-04 at 20:57 +0200, Giulio Benetti wrote:
> Il 04/06/2018 13:49, Andy Shevchenko ha scritto:
> > On Fri, 2018-06-01 at 16:11 +0200, Giulio Benetti wrote:
> > > It can be useful to override 8250 mctrl lines with gpios, for rts
> > > on
> > > rs485 for example, when rts is not mapped correctly to HW RTS pin.
> > >
> > > Enable SERIAL_MCTRL_GPIO by default.
> > >
> >
> > Unfortunately NAK, see
> >
> > commit 5db4f7f80d165fc9725f356e99feec409e446baa
> > Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Date: Tue Aug 16 15:06:54 2016 +0300
> >
> > Revert "tty/serial/8250: use mctrl_gpio helpers"
> >
> > for the details.
> >
> > I would love to see a solution that will satisfy everyone, though I
> > have
> > only means to test proposals for now.
>
> Thanks for pointing me that.
> I would try to solve serial breakage on intel with already extisting
> patches dropping this one.
> I'm going to try.
>
> I can't understand if it's enough using qemu x86 to reproduce the bug.
> If so I'm going to debug and check what makes driver to fail.
You need to provide an ACPI table with UART contains GpioInt() or
GpioIo() resource in it.
Where GPIO number is a number of pin related to UART's RxD.
> Do you think it makes sense? Would it be accepted after bug fixing?
I can test on our hardware. Can't say about the rest, though.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* [RFC PATCH 6/6] arm64: dts: ti: Add support for AM654 EVM base board
From: Nishanth Menon @ 2018-06-05 6:05 UTC (permalink / raw)
To: Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, Rob Herring
Cc: linux-serial, linux-kernel, devicetree, linux-arm-kernel,
Tony Lindgren, Vignesh R, Tero Kristo, Russell King, Sudeep Holla,
nm
In-Reply-To: <20180605060510.32473-1-nm@ti.com>
The EValuation Module(EVM) platform for AM654 consists of a
common Base board + one or more of daughter cards, which include:
a) "Personality Modules", which can be specific to a profile, such as
ICSSG enabled or Multi-media (including audio).
b) SERDES modules, which may be 2 lane PCIe or two port PCIe + USB2
c) Camera daughter card
d) various display panels
Among other options. There are two basic configurations defined which
include an "EVM" configuration and "IDK" (Industrial development kit)
which differ in the specific combination of daughter cards that are
used.
To simplify support, we choose to support just the base board as the
core device tree file and all daughter cards would be expected to be
device tree overlays.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
MAINTAINERS | 1 +
arch/arm64/boot/dts/Makefile | 1 +
arch/arm64/boot/dts/ti/Makefile | 9 ++++++
arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 40 ++++++++++++++++++++++++++
4 files changed, 51 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/Makefile
create mode 100644 arch/arm64/boot/dts/ti/k3-am654-base-board.dts
diff --git a/MAINTAINERS b/MAINTAINERS
index 5f5c4eddec7a..4491a0f0625f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2092,6 +2092,7 @@ M: Nishanth Menon <nm@ti.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Supported
F: Documentation/devicetree/bindings/arm/ti/k3.txt
+F: arch/arm64/boot/dts/ti/Makefile
F: arch/arm64/boot/dts/ti/k3-*
ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index 3543bc324553..4690364d584b 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -23,5 +23,6 @@ subdir-y += rockchip
subdir-y += socionext
subdir-y += sprd
subdir-y += synaptics
+subdir-y += ti
subdir-y += xilinx
subdir-y += zte
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
new file mode 100644
index 000000000000..63e619d0b5b8
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -0,0 +1,9 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Make file to build device tree binaries for boards based on
+# Texas Instruments Inc processors
+#
+# Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+#
+
+dtb-$(CONFIG_ARCH_K3_AM6_SOC) += k3-am654-base-board.dtb
diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
new file mode 100644
index 000000000000..d227d792de60
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+/dts-v1/;
+
+#include "k3-am654.dtsi"
+
+/ {
+ compatible = "ti,am654-evm", "ti,am654";
+ model = "Texas Instruments AM654 Base Board";
+
+ chosen {
+ stdout-path = "serial2:115200n8";
+ bootargs = "earlycon=ns16550a,mmio32,0x02800000";
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ /* 4G RAM */
+ reg = <0x00000000 0x80000000 0x00000000 0x80000000>,
+ <0x00000008 0x80000000 0x00000000 0x80000000>;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ secure_ddr: secure_ddr@9e800000 {
+ reg = <0 0x9e800000 0 0x01800000>; /* for OP-TEE */
+ alignment = <0x1000>;
+ no-map;
+ };
+ };
+};
+
+&main_uart0 {
+ status = "okay";
+};
--
2.15.1
^ permalink raw reply related
* [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
From: Nishanth Menon @ 2018-06-05 6:05 UTC (permalink / raw)
To: Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, Rob Herring
Cc: linux-serial, linux-kernel, devicetree, linux-arm-kernel,
Tony Lindgren, Vignesh R, Tero Kristo, Russell King, Sudeep Holla,
nm
In-Reply-To: <=<20180605060125.9518-1-nm@ti.com>
The AM654 SoC is a lead device of the K3 Multicore SoC architecture
platform, targeted for broad market and industrial control with aim to
meet the complex processing needs of modern embedded products.
Some highlights of this SoC are:
* Quad ARMv8 A53 cores split over two clusters
* GICv3 compliant GIC500
* Configurable L3 Cache and IO-coherent architecture
* Dual lock-step capable R5F uC for safety-critical applications
* High data throughput capable distributed DMA architecture under NAVSS
* Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual
PRUs and dual RTUs
* Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
* Centralized System Controller for Security, Power, and Resource
management.
* Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD
* Flash subystem with OSPI and Hyperbus interfaces
* Multimedia capability with CAL, DSS7-UL, SGX544, McASP
* Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI,
GPIO
See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7
We introduce the Kconfig symbol for the SoC along with this patch since
it is logically relevant point, however the usage is in subsequent
patches.
NOTE: AM654 is the first of the device variants, hence we introduce a
generic am6.dtsi.
Signed-off-by: Benjamin Fair <b-fair@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
MAINTAINERS | 1 +
arch/arm64/boot/dts/ti/k3-am6.dtsi | 144 +++++++++++++++++++++++++++++++++++
arch/arm64/boot/dts/ti/k3-am654.dtsi | 117 ++++++++++++++++++++++++++++
drivers/soc/ti/Kconfig | 14 ++++
4 files changed, 276 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am6.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am654.dtsi
diff --git a/MAINTAINERS b/MAINTAINERS
index cfb35b252ac7..5f5c4eddec7a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2092,6 +2092,7 @@ M: Nishanth Menon <nm@ti.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Supported
F: Documentation/devicetree/bindings/arm/ti/k3.txt
+F: arch/arm64/boot/dts/ti/k3-*
ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE
M: Santosh Shilimkar <ssantosh@kernel.org>
diff --git a/arch/arm64/boot/dts/ti/k3-am6.dtsi b/arch/arm64/boot/dts/ti/k3-am6.dtsi
new file mode 100644
index 000000000000..cdfa12173aac
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am6.dtsi
@@ -0,0 +1,144 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for AM6 SoC Family
+ *
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+ model = "Texas Instruments K3 AM654 SoC";
+ compatible = "ti,am654";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ serial0 = &wkup_uart0;
+ serial1 = &mcu_uart0;
+ serial2 = &main_uart0;
+ serial3 = &main_uart1;
+ serial4 = &main_uart2;
+ };
+
+ chosen { };
+
+ firmware {
+ optee {
+ compatible = "linaro,optee-tz";
+ method = "smc";
+ };
+
+ psci: psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+ };
+
+ soc0: soc0 {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ a53_timer0: timer-cl0-cpu0 {
+ compatible = "arm,armv8-timer";
+ interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, /* cntpsirq */
+ <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, /* cntpnsirq */
+ <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, /* cntvirq */
+ <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; /* cnthpirq */
+ };
+
+ pmu: pmu {
+ compatible = "arm,armv8-pmuv3";
+ /* Recommendation from GIC500 TRM Table A.3 */
+ interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ gic: interrupt-controller@1800000 {
+ compatible = "arm,gic-v3";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ /*
+ * NOTE: we are NOT gicv2 backward compat, so no GICC,
+ * GICH or GICV
+ */
+ reg = <0x0 0x01800000 0x0 0x10000>, /* GICD */
+ <0x0 0x01880000 0x0 0x90000>; /* GICR */
+
+ /*
+ * vcpumntirq:
+ * virtual CPU interface maintenance interrupt
+ */
+ interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+
+ gic_its: gic-its@1000000 {
+ compatible = "arm,gic-v3-its";
+ reg = <0x0 0x1820000 0x0 0x10000>;
+ msi-controller;
+ #msi-cells = <1>;
+ };
+ };
+
+ wkup_uart0: serial@42300000 {
+ compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
+ reg = <0x0 0x42300000 0x0 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 697 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <48000000>;
+ current-speed = <115200>;
+ status = "disabled";
+ };
+
+ mcu_uart0: serial@40a00000 {
+ compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
+ reg = <0x0 0x40a00000 0x0 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 565 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <96000000>;
+ current-speed = <115200>;
+ status = "disabled";
+ };
+
+ main_uart0: serial@2800000 {
+ compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
+ reg = <0x0 0x02800000 0x0 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <48000000>;
+ current-speed = <115200>;
+ status = "disabled";
+ };
+
+ main_uart1: serial@2810000 {
+ compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
+ reg = <0x0 0x02810000 0x0 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <48000000>;
+ current-speed = <115200>;
+ status = "disabled";
+ };
+
+ main_uart2: serial@2820000 {
+ compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
+ reg = <0x0 0x02820000 0x0 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <48000000>;
+ current-speed = <115200>;
+ status = "disabled";
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am654.dtsi b/arch/arm64/boot/dts/ti/k3-am654.dtsi
new file mode 100644
index 000000000000..d9b70081daba
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am654.dtsi
@@ -0,0 +1,117 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for AM6 SoC family in Quad core configuration
+ *
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#include "k3-am6.dtsi"
+
+/ {
+ cpus: cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu-map {
+ cluster0: cluster0 {
+ core0 {
+ cpu = <&cpu0>;
+ };
+
+ core1 {
+ cpu = <&cpu1>;
+ };
+ };
+
+ cluster1: cluster1 {
+ core0 {
+ cpu = <&cpu2>;
+ };
+
+ core1 {
+ cpu = <&cpu3>;
+ };
+ };
+ };
+
+ cpu0: cpu@0 {
+ compatible = "arm,cortex-a53","arm,armv8";
+ reg = <0x000>;
+ device_type = "cpu";
+ enable-method = "psci";
+ i-cache-size = <0x8000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <256>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ next-level-cache = <&L2_0>;
+ };
+
+ cpu1: cpu@1 {
+ compatible = "arm,cortex-a53","arm,armv8";
+ reg = <0x001>;
+ device_type = "cpu";
+ enable-method = "psci";
+ i-cache-size = <0x8000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <256>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ next-level-cache = <&L2_0>;
+ };
+
+ cpu2: cpu@100 {
+ compatible = "arm,cortex-a53","arm,armv8";
+ reg = <0x100>;
+ device_type = "cpu";
+ enable-method = "psci";
+ i-cache-size = <0x8000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <256>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ next-level-cache = <&L2_1>;
+ };
+
+ cpu3: cpu@101 {
+ compatible = "arm,cortex-a53","arm,armv8";
+ reg = <0x101>;
+ device_type = "cpu";
+ enable-method = "psci";
+ i-cache-size = <0x8000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <256>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ next-level-cache = <&L2_1>;
+ };
+ };
+};
+
+&soc0 {
+ L2_0: l2-cache0 {
+ compatible = "cache";
+ cache-level = <2>;
+ cache-size = <0x80000>;
+ cache-line-size = <64>;
+ cache-sets = <512>;
+ next-level-cache = <&msmc_l3>;
+ };
+
+ L2_1: l2-cache1 {
+ compatible = "cache";
+ cache-level = <2>;
+ cache-size = <0x80000>;
+ cache-line-size = <64>;
+ cache-sets = <512>;
+ next-level-cache = <&msmc_l3>;
+ };
+
+ msmc_l3: l3-cache0 {
+ compatible = "cache";
+ cache-level = <3>;
+ };
+};
diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
index 92770d84a288..be4570baad96 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -1,3 +1,17 @@
+# 64-bit ARM SoCs from TI
+if ARM64
+
+if ARCH_K3
+
+config ARCH_K3_AM6_SOC
+ bool "K3 AM6 SoC"
+ help
+ Enable support for TI's AM6 SoC Family support
+
+endif
+
+endif
+
#
# TI SOC drivers
#
--
2.15.1
^ permalink raw reply related
* [RFC PATCH 4/6] serial: 8250_omap: Make 8250_omap driver driver depend on ARCH_K3
From: Nishanth Menon @ 2018-06-05 6:01 UTC (permalink / raw)
To: Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, Rob Herring
Cc: Nishanth Menon, devicetree, Vignesh R, Tony Lindgren,
linux-kernel, Russell King, Tero Kristo, Lokesh Vutla,
linux-serial, Sudeep Holla, linux-arm-kernel
In-Reply-To: <20180605060125.9518-1-nm@ti.com>
From: Lokesh Vutla <lokeshvutla@ti.com>
Allow 8250 omap serial driver to be used for K3 platforms.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
drivers/tty/serial/8250/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
index f005eaf8bc57..15c2c5463835 100644
--- a/drivers/tty/serial/8250/Kconfig
+++ b/drivers/tty/serial/8250/Kconfig
@@ -375,7 +375,7 @@ config SERIAL_8250_RT288X
config SERIAL_8250_OMAP
tristate "Support for OMAP internal UART (8250 based driver)"
- depends on SERIAL_8250 && ARCH_OMAP2PLUS
+ depends on SERIAL_8250 && (ARCH_OMAP2PLUS || ARCH_K3)
help
If you have a machine based on an Texas Instruments OMAP CPU you
can enable its onboard serial ports by enabling this option.
--
2.15.1
^ permalink raw reply related
* [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller
From: Nishanth Menon @ 2018-06-05 6:01 UTC (permalink / raw)
To: Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, Rob Herring
Cc: linux-serial, linux-kernel, devicetree, linux-arm-kernel,
Tony Lindgren, Vignesh R, Tero Kristo, Russell King, Sudeep Holla,
Nishanth Menon, Sekhar Nori
In-Reply-To: <20180605060125.9518-1-nm@ti.com>
AM654 uses a UART controller that is compatible (partially) with
existing 8250 UART, however, has a few differences with respect to DMA
support and control paths. Introduce a base definition that allows us
to build up the differences in follow on patches.
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Vignesh R <vigneshr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
drivers/tty/serial/8250/8250_omap.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 4b0f05adb228..c35d5ece1156 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -1,6 +1,7 @@
OMAP UART controller
Required properties:
+- compatible : should be "ti,am654-uart" for AM654 controllers
- compatible : should be "ti,omap2-uart" for OMAP2 controllers
- compatible : should be "ti,omap3-uart" for OMAP3 controllers
- compatible : should be "ti,omap4-uart" for OMAP4 controllers
diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
index 1b337fee07ed..a019286f8bb6 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -1115,6 +1115,7 @@ static const u8 am3352_habit = OMAP_DMA_TX_KICK | UART_ERRATA_CLOCK_DISABLE;
static const u8 dra742_habit = UART_ERRATA_CLOCK_DISABLE;
static const struct of_device_id omap8250_dt_ids[] = {
+ { .compatible = "ti,am654-uart" },
{ .compatible = "ti,omap2-uart" },
{ .compatible = "ti,omap3-uart" },
{ .compatible = "ti,omap4-uart", .data = &omap4_habit, },
--
2.15.1
^ permalink raw reply related
* [RFC PATCH 2/6] arm64: Add support for TI's K3 Multicore SoC architecture
From: Nishanth Menon @ 2018-06-05 6:01 UTC (permalink / raw)
To: Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, Rob Herring
Cc: linux-serial, linux-kernel, devicetree, linux-arm-kernel,
Tony Lindgren, Vignesh R, Tero Kristo, Russell King, Sudeep Holla,
Nishanth Menon
In-Reply-To: <20180605060125.9518-1-nm@ti.com>
Add support for Texas Instrument's K3 Multicore SoC architecture
processors.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm64/Kconfig.platforms | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index d5aeac351fc3..52df25bf4f8c 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -71,6 +71,13 @@ config ARCH_EXYNOS
help
This enables support for ARMv8 based Samsung Exynos SoC family.
+config ARCH_K3
+ bool "Texas Instruments Inc. K3 multicore SoC architecture"
+ select PM_GENERIC_DOMAINS if PM
+ help
+ This enables support for Texas Instruments' K3 multicore SoC
+ architecture.
+
config ARCH_LAYERSCAPE
bool "ARMv8 based Freescale Layerscape SoC family"
select EDAC_SUPPORT
--
2.15.1
^ permalink raw reply related
* [RFC PATCH 1/6] Documentation: arm: ti: Add bindings for AM654 SoC
From: Nishanth Menon @ 2018-06-05 6:01 UTC (permalink / raw)
To: Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, Rob Herring
Cc: linux-serial, linux-kernel, devicetree, linux-arm-kernel,
Tony Lindgren, Vignesh R, Tero Kristo, Russell King, Sudeep Holla,
Nishanth Menon
In-Reply-To: <20180605060125.9518-1-nm@ti.com>
The AM654 SoC is a lead device of the K3 Multicore SoC architecture
platform, targeted for broad market and industrial control with aim to
meet the complex processing needs of modern embedded products.
Some highlights of this SoC are:
* Quad ARMv8 A53 cores split over two clusters
* GICv3 compliant GIC500
* Configurable L3 Cache and IO-coherent architecture
* Dual lock-step capable R5F uC for safety-critical applications
* High data throughput capable distributed DMA architecture under NAVSS
* Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual
PRUs and dual RTUs
* Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
* Centralized System Controller for Security, Power, and Resource
management.
* Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD
* Flash subystem with OSPI and Hyperbus interfaces
* Multimedia capability with CAL, DSS7-UL, SGX544, McASP
* Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI,
GPIO
See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Documentation/devicetree/bindings/arm/ti/k3.txt | 33 +++++++++++++++++++++++++
MAINTAINERS | 7 ++++++
2 files changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/ti/k3.txt
diff --git a/Documentation/devicetree/bindings/arm/ti/k3.txt b/Documentation/devicetree/bindings/arm/ti/k3.txt
new file mode 100644
index 000000000000..cbabb1b89f6f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/ti/k3.txt
@@ -0,0 +1,33 @@
+Texas Instruments K3 Multicore SoC architecture device tree bindings
+--------------------------------------------------------------------
+
+Boards based on K3 Multicore SoC architecture shall have the following property:
+- compatible: Every hardware block introduced in K3 Multicore SoC
+ architecture shall be of the form:
+ "ti,XXX-YYY", where:
+ 'XXX' represents the specific SoC part for which the support is added.
+ 'YYY' represents the corresponding peripheral in SoC being supported.
+
+ NOTE: Generic devices such as GIC or legacy devices shall use the specified
+ compatible for those devices.
+
+ Example:
+ compatible = "ti,am654-i2c";
+
+SoCs
+-------------------------------------------
+
+Each device tree root node must specify which exact SoC in K3 Multicore SoC
+architecture it uses, using one of the following compatible values:
+
+- AM654
+ compatible = "ti,am654";
+
+Boards
+-------------------------------------------
+
+In addition, each device tree root node must specify which one or more
+of the following board-specific compatible values:
+
+- AM654 EVM
+ compatible = "ti,am654-evm", "ti,am654";
diff --git a/MAINTAINERS b/MAINTAINERS
index f39a8de1bbd7..cfb35b252ac7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2086,6 +2086,13 @@ L: linux-kernel@vger.kernel.org
S: Maintained
F: drivers/memory/*emif*
+ARM/TEXAS INSTRUMENTS K3 ARCHITECTURE
+M: Tero Kristo <t-kristo@ti.com>
+M: Nishanth Menon <nm@ti.com>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S: Supported
+F: Documentation/devicetree/bindings/arm/ti/k3.txt
+
ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE
M: Santosh Shilimkar <ssantosh@kernel.org>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
--
2.15.1
^ permalink raw reply related
* [RFC PATCH 0/6] arm64: Initial support Texas Instrument's AM654 Platform
From: Nishanth Menon @ 2018-06-05 6:01 UTC (permalink / raw)
To: Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, Rob Herring
Cc: linux-serial, linux-kernel, devicetree, linux-arm-kernel,
Tony Lindgren, Vignesh R, Tero Kristo, Russell King, Sudeep Holla,
Nishanth Menon
Hi,
The following series enables support for newest addition in TI's SoC
portfolio - AM654 SoC.
The series is an RFC based off next-20180604 and will post formally once
v4.18-rc1 is available.
The series (part 1 of 4) is available here:
https://github.com/nmenon/linux-2.6-playground/commits/upstream/next-20180604/k3-1-am6-base
Full Boot log is available here: https://pastebin.ubuntu.com/p/vWCzMKtBCW/
The AM654 SoC is a lead device of the K3 Multicore SoC architecture
platform, targeted for broad market and industrial control with aim to
meet the complex processing needs of modern embedded products.
The Linux development follows closely the 66AK2G SoC model in aarch64.
See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7
Lokesh Vutla (1):
serial: 8250_omap: Make 8250_omap driver driver depend on ARCH_K3
Nishanth Menon (5):
Documentation: arm: ti: Add bindings for AM654 SoC
arm64: Add support for TI's K3 Multicore SoC architecture
serial: 8250_omap: Add support for AM654 UART controller
arm64: dts: ti: Add Support for AM654 SoC
arm64: dts: ti: Add support for AM654 EVM base board
Documentation/devicetree/bindings/arm/ti/k3.txt | 33 +++++
.../devicetree/bindings/serial/omap_serial.txt | 1 +
MAINTAINERS | 9 ++
arch/arm64/Kconfig.platforms | 7 +
arch/arm64/boot/dts/Makefile | 1 +
arch/arm64/boot/dts/ti/Makefile | 9 ++
arch/arm64/boot/dts/ti/k3-am6.dtsi | 144 +++++++++++++++++++++
arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 40 ++++++
arch/arm64/boot/dts/ti/k3-am654.dtsi | 117 +++++++++++++++++
drivers/soc/ti/Kconfig | 14 ++
drivers/tty/serial/8250/8250_omap.c | 1 +
drivers/tty/serial/8250/Kconfig | 2 +-
12 files changed, 377 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/arm/ti/k3.txt
create mode 100644 arch/arm64/boot/dts/ti/Makefile
create mode 100644 arch/arm64/boot/dts/ti/k3-am6.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am654-base-board.dts
create mode 100644 arch/arm64/boot/dts/ti/k3-am654.dtsi
--
2.15.1
^ permalink raw reply
* Re: [PATCH] uart: fix race between uart_put_char() and uart_shutdown()
From: Serge E. Hallyn @ 2018-06-05 3:59 UTC (permalink / raw)
To: Tycho Andersen
Cc: Greg Kroah-Hartman, Jiri Slaby, linux-serial, linux-kernel,
Serge E . Hallyn
In-Reply-To: <20180605000127.5495-1-tycho@tycho.ws>
Quoting Tycho Andersen (tycho@tycho.ws):
> We have reports of the following crash:
>
> PID: 7 TASK: ffff88085c6d61c0 CPU: 1 COMMAND: "kworker/u25:0"
> #0 [ffff88085c6db710] machine_kexec at ffffffff81046239
> #1 [ffff88085c6db760] crash_kexec at ffffffff810fc248
> #2 [ffff88085c6db830] oops_end at ffffffff81008ae7
> #3 [ffff88085c6db860] no_context at ffffffff81050b8f
> #4 [ffff88085c6db8b0] __bad_area_nosemaphore at ffffffff81050d75
> #5 [ffff88085c6db900] bad_area_nosemaphore at ffffffff81050e83
> #6 [ffff88085c6db910] __do_page_fault at ffffffff8105132e
> #7 [ffff88085c6db9b0] do_page_fault at ffffffff8105152c
> #8 [ffff88085c6db9c0] page_fault at ffffffff81a3f122
> [exception RIP: uart_put_char+149]
> RIP: ffffffff814b67b5 RSP: ffff88085c6dba78 RFLAGS: 00010006
> RAX: 0000000000000292 RBX: ffffffff827c5120 RCX: 0000000000000081
> RDX: 0000000000000000 RSI: 000000000000005f RDI: ffffffff827c5120
> RBP: ffff88085c6dba98 R8: 000000000000012c R9: ffffffff822ea320
> R10: ffff88085fe4db04 R11: 0000000000000001 R12: ffff881059f9c000
> R13: 0000000000000001 R14: 000000000000005f R15: 0000000000000fba
> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
> #9 [ffff88085c6dbaa0] tty_put_char at ffffffff81497544
> #10 [ffff88085c6dbac0] do_output_char at ffffffff8149c91c
> #11 [ffff88085c6dbae0] __process_echoes at ffffffff8149cb8b
> #12 [ffff88085c6dbb30] commit_echoes at ffffffff8149cdc2
> #13 [ffff88085c6dbb60] n_tty_receive_buf_fast at ffffffff8149e49b
> #14 [ffff88085c6dbbc0] __receive_buf at ffffffff8149ef5a
> #15 [ffff88085c6dbc20] n_tty_receive_buf_common at ffffffff8149f016
> #16 [ffff88085c6dbca0] n_tty_receive_buf2 at ffffffff8149f194
> #17 [ffff88085c6dbcb0] flush_to_ldisc at ffffffff814a238a
> #18 [ffff88085c6dbd50] process_one_work at ffffffff81090be2
> #19 [ffff88085c6dbe20] worker_thread at ffffffff81091b4d
> #20 [ffff88085c6dbeb0] kthread at ffffffff81096384
> #21 [ffff88085c6dbf50] ret_from_fork at ffffffff81a3d69f
>
> after slogging through some dissasembly:
>
> ffffffff814b6720 <uart_put_char>:
> ffffffff814b6720: 55 push %rbp
> ffffffff814b6721: 48 89 e5 mov %rsp,%rbp
> ffffffff814b6724: 48 83 ec 20 sub $0x20,%rsp
> ffffffff814b6728: 48 89 1c 24 mov %rbx,(%rsp)
> ffffffff814b672c: 4c 89 64 24 08 mov %r12,0x8(%rsp)
> ffffffff814b6731: 4c 89 6c 24 10 mov %r13,0x10(%rsp)
> ffffffff814b6736: 4c 89 74 24 18 mov %r14,0x18(%rsp)
> ffffffff814b673b: e8 b0 8e 58 00 callq ffffffff81a3f5f0 <mcount>
> ffffffff814b6740: 4c 8b a7 88 02 00 00 mov 0x288(%rdi),%r12
> ffffffff814b6747: 45 31 ed xor %r13d,%r13d
> ffffffff814b674a: 41 89 f6 mov %esi,%r14d
> ffffffff814b674d: 49 83 bc 24 70 01 00 cmpq $0x0,0x170(%r12)
> ffffffff814b6754: 00 00
> ffffffff814b6756: 49 8b 9c 24 80 01 00 mov 0x180(%r12),%rbx
> ffffffff814b675d: 00
> ffffffff814b675e: 74 2f je ffffffff814b678f <uart_put_char+0x6f>
> ffffffff814b6760: 48 89 df mov %rbx,%rdi
> ffffffff814b6763: e8 a8 67 58 00 callq ffffffff81a3cf10 <_raw_spin_lock_irqsave>
> ffffffff814b6768: 41 8b 8c 24 78 01 00 mov 0x178(%r12),%ecx
> ffffffff814b676f: 00
> ffffffff814b6770: 89 ca mov %ecx,%edx
> ffffffff814b6772: f7 d2 not %edx
> ffffffff814b6774: 41 03 94 24 7c 01 00 add 0x17c(%r12),%edx
> ffffffff814b677b: 00
> ffffffff814b677c: 81 e2 ff 0f 00 00 and $0xfff,%edx
> ffffffff814b6782: 75 23 jne ffffffff814b67a7 <uart_put_char+0x87>
> ffffffff814b6784: 48 89 c6 mov %rax,%rsi
> ffffffff814b6787: 48 89 df mov %rbx,%rdi
> ffffffff814b678a: e8 e1 64 58 00 callq ffffffff81a3cc70 <_raw_spin_unlock_irqrestore>
> ffffffff814b678f: 44 89 e8 mov %r13d,%eax
> ffffffff814b6792: 48 8b 1c 24 mov (%rsp),%rbx
> ffffffff814b6796: 4c 8b 64 24 08 mov 0x8(%rsp),%r12
> ffffffff814b679b: 4c 8b 6c 24 10 mov 0x10(%rsp),%r13
> ffffffff814b67a0: 4c 8b 74 24 18 mov 0x18(%rsp),%r14
> ffffffff814b67a5: c9 leaveq
> ffffffff814b67a6: c3 retq
> ffffffff814b67a7: 49 8b 94 24 70 01 00 mov 0x170(%r12),%rdx
> ffffffff814b67ae: 00
> ffffffff814b67af: 48 63 c9 movslq %ecx,%rcx
> ffffffff814b67b2: 41 b5 01 mov $0x1,%r13b
> ffffffff814b67b5: 44 88 34 0a mov %r14b,(%rdx,%rcx,1)
> ffffffff814b67b9: 41 8b 94 24 78 01 00 mov 0x178(%r12),%edx
> ffffffff814b67c0: 00
> ffffffff814b67c1: 83 c2 01 add $0x1,%edx
> ffffffff814b67c4: 81 e2 ff 0f 00 00 and $0xfff,%edx
> ffffffff814b67ca: 41 89 94 24 78 01 00 mov %edx,0x178(%r12)
> ffffffff814b67d1: 00
> ffffffff814b67d2: eb b0 jmp ffffffff814b6784 <uart_put_char+0x64>
> ffffffff814b67d4: 66 66 66 2e 0f 1f 84 data32 data32 nopw %cs:0x0(%rax,%rax,1)
> ffffffff814b67db: 00 00 00 00 00
>
> for our build, this is crashing at:
>
> circ->buf[circ->head] = c;
>
> Looking in uart_port_startup(), it seems that circ->buf (state->xmit.buf)
> protected by the "per-port mutex", which based on uart_port_check() is
> state->port.mutex. Indeed, the lock acquired in uart_put_char() is
> uport->lock, i.e. not the same lock.
>
> Anyway, since the lock is not acquired, if uart_shutdown() is called, the
> last chunk of that function may release state->xmit.buf before its assigned
> to null, and cause the race above.
>
> To fix it, we simply also acquire state->port.mutex.
>
> Unfortunately, I don't have any insightful thoughts about how to test this.
> Ideas are appreciated :)
I wonder whether there is something we can do with qemu -serial pipe: ?
> Signed-off-by: Tycho Andersen <tycho@tycho.ws>
Acked-by: Serge Hallyn <serge@hallyn.com>
> ---
> drivers/tty/serial/serial_core.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index 0466f9f08a91..883a8c15510c 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -532,9 +532,15 @@ static int uart_put_char(struct tty_struct *tty, unsigned char c)
> unsigned long flags;
> int ret = 0;
>
> + /*
> + * state->xmit.buf is protected by state->port.mutex, see the note in
> + * uart_port_startup()
> + */
> + mutex_lock(&state->port.mutex);
> +
> circ = &state->xmit;
> if (!circ->buf)
> - return 0;
> + goto out;
>
> port = uart_port_lock(state, flags);
> if (port && uart_circ_chars_free(circ) != 0) {
> @@ -543,6 +549,9 @@ static int uart_put_char(struct tty_struct *tty, unsigned char c)
> ret = 1;
> }
> uart_port_unlock(port, flags);
> +
> +out:
> + mutex_unlock(&state->port.mutex);
> return ret;
> }
>
> --
> 2.17.0
^ permalink raw reply
* [PATCH] uart: fix race between uart_put_char() and uart_shutdown()
From: Tycho Andersen @ 2018-06-05 0:01 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: linux-serial, linux-kernel, Serge E . Hallyn, Tycho Andersen
We have reports of the following crash:
PID: 7 TASK: ffff88085c6d61c0 CPU: 1 COMMAND: "kworker/u25:0"
#0 [ffff88085c6db710] machine_kexec at ffffffff81046239
#1 [ffff88085c6db760] crash_kexec at ffffffff810fc248
#2 [ffff88085c6db830] oops_end at ffffffff81008ae7
#3 [ffff88085c6db860] no_context at ffffffff81050b8f
#4 [ffff88085c6db8b0] __bad_area_nosemaphore at ffffffff81050d75
#5 [ffff88085c6db900] bad_area_nosemaphore at ffffffff81050e83
#6 [ffff88085c6db910] __do_page_fault at ffffffff8105132e
#7 [ffff88085c6db9b0] do_page_fault at ffffffff8105152c
#8 [ffff88085c6db9c0] page_fault at ffffffff81a3f122
[exception RIP: uart_put_char+149]
RIP: ffffffff814b67b5 RSP: ffff88085c6dba78 RFLAGS: 00010006
RAX: 0000000000000292 RBX: ffffffff827c5120 RCX: 0000000000000081
RDX: 0000000000000000 RSI: 000000000000005f RDI: ffffffff827c5120
RBP: ffff88085c6dba98 R8: 000000000000012c R9: ffffffff822ea320
R10: ffff88085fe4db04 R11: 0000000000000001 R12: ffff881059f9c000
R13: 0000000000000001 R14: 000000000000005f R15: 0000000000000fba
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#9 [ffff88085c6dbaa0] tty_put_char at ffffffff81497544
#10 [ffff88085c6dbac0] do_output_char at ffffffff8149c91c
#11 [ffff88085c6dbae0] __process_echoes at ffffffff8149cb8b
#12 [ffff88085c6dbb30] commit_echoes at ffffffff8149cdc2
#13 [ffff88085c6dbb60] n_tty_receive_buf_fast at ffffffff8149e49b
#14 [ffff88085c6dbbc0] __receive_buf at ffffffff8149ef5a
#15 [ffff88085c6dbc20] n_tty_receive_buf_common at ffffffff8149f016
#16 [ffff88085c6dbca0] n_tty_receive_buf2 at ffffffff8149f194
#17 [ffff88085c6dbcb0] flush_to_ldisc at ffffffff814a238a
#18 [ffff88085c6dbd50] process_one_work at ffffffff81090be2
#19 [ffff88085c6dbe20] worker_thread at ffffffff81091b4d
#20 [ffff88085c6dbeb0] kthread at ffffffff81096384
#21 [ffff88085c6dbf50] ret_from_fork at ffffffff81a3d69f
after slogging through some dissasembly:
ffffffff814b6720 <uart_put_char>:
ffffffff814b6720: 55 push %rbp
ffffffff814b6721: 48 89 e5 mov %rsp,%rbp
ffffffff814b6724: 48 83 ec 20 sub $0x20,%rsp
ffffffff814b6728: 48 89 1c 24 mov %rbx,(%rsp)
ffffffff814b672c: 4c 89 64 24 08 mov %r12,0x8(%rsp)
ffffffff814b6731: 4c 89 6c 24 10 mov %r13,0x10(%rsp)
ffffffff814b6736: 4c 89 74 24 18 mov %r14,0x18(%rsp)
ffffffff814b673b: e8 b0 8e 58 00 callq ffffffff81a3f5f0 <mcount>
ffffffff814b6740: 4c 8b a7 88 02 00 00 mov 0x288(%rdi),%r12
ffffffff814b6747: 45 31 ed xor %r13d,%r13d
ffffffff814b674a: 41 89 f6 mov %esi,%r14d
ffffffff814b674d: 49 83 bc 24 70 01 00 cmpq $0x0,0x170(%r12)
ffffffff814b6754: 00 00
ffffffff814b6756: 49 8b 9c 24 80 01 00 mov 0x180(%r12),%rbx
ffffffff814b675d: 00
ffffffff814b675e: 74 2f je ffffffff814b678f <uart_put_char+0x6f>
ffffffff814b6760: 48 89 df mov %rbx,%rdi
ffffffff814b6763: e8 a8 67 58 00 callq ffffffff81a3cf10 <_raw_spin_lock_irqsave>
ffffffff814b6768: 41 8b 8c 24 78 01 00 mov 0x178(%r12),%ecx
ffffffff814b676f: 00
ffffffff814b6770: 89 ca mov %ecx,%edx
ffffffff814b6772: f7 d2 not %edx
ffffffff814b6774: 41 03 94 24 7c 01 00 add 0x17c(%r12),%edx
ffffffff814b677b: 00
ffffffff814b677c: 81 e2 ff 0f 00 00 and $0xfff,%edx
ffffffff814b6782: 75 23 jne ffffffff814b67a7 <uart_put_char+0x87>
ffffffff814b6784: 48 89 c6 mov %rax,%rsi
ffffffff814b6787: 48 89 df mov %rbx,%rdi
ffffffff814b678a: e8 e1 64 58 00 callq ffffffff81a3cc70 <_raw_spin_unlock_irqrestore>
ffffffff814b678f: 44 89 e8 mov %r13d,%eax
ffffffff814b6792: 48 8b 1c 24 mov (%rsp),%rbx
ffffffff814b6796: 4c 8b 64 24 08 mov 0x8(%rsp),%r12
ffffffff814b679b: 4c 8b 6c 24 10 mov 0x10(%rsp),%r13
ffffffff814b67a0: 4c 8b 74 24 18 mov 0x18(%rsp),%r14
ffffffff814b67a5: c9 leaveq
ffffffff814b67a6: c3 retq
ffffffff814b67a7: 49 8b 94 24 70 01 00 mov 0x170(%r12),%rdx
ffffffff814b67ae: 00
ffffffff814b67af: 48 63 c9 movslq %ecx,%rcx
ffffffff814b67b2: 41 b5 01 mov $0x1,%r13b
ffffffff814b67b5: 44 88 34 0a mov %r14b,(%rdx,%rcx,1)
ffffffff814b67b9: 41 8b 94 24 78 01 00 mov 0x178(%r12),%edx
ffffffff814b67c0: 00
ffffffff814b67c1: 83 c2 01 add $0x1,%edx
ffffffff814b67c4: 81 e2 ff 0f 00 00 and $0xfff,%edx
ffffffff814b67ca: 41 89 94 24 78 01 00 mov %edx,0x178(%r12)
ffffffff814b67d1: 00
ffffffff814b67d2: eb b0 jmp ffffffff814b6784 <uart_put_char+0x64>
ffffffff814b67d4: 66 66 66 2e 0f 1f 84 data32 data32 nopw %cs:0x0(%rax,%rax,1)
ffffffff814b67db: 00 00 00 00 00
for our build, this is crashing at:
circ->buf[circ->head] = c;
Looking in uart_port_startup(), it seems that circ->buf (state->xmit.buf)
protected by the "per-port mutex", which based on uart_port_check() is
state->port.mutex. Indeed, the lock acquired in uart_put_char() is
uport->lock, i.e. not the same lock.
Anyway, since the lock is not acquired, if uart_shutdown() is called, the
last chunk of that function may release state->xmit.buf before its assigned
to null, and cause the race above.
To fix it, we simply also acquire state->port.mutex.
Unfortunately, I don't have any insightful thoughts about how to test this.
Ideas are appreciated :)
Signed-off-by: Tycho Andersen <tycho@tycho.ws>
---
drivers/tty/serial/serial_core.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 0466f9f08a91..883a8c15510c 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -532,9 +532,15 @@ static int uart_put_char(struct tty_struct *tty, unsigned char c)
unsigned long flags;
int ret = 0;
+ /*
+ * state->xmit.buf is protected by state->port.mutex, see the note in
+ * uart_port_startup()
+ */
+ mutex_lock(&state->port.mutex);
+
circ = &state->xmit;
if (!circ->buf)
- return 0;
+ goto out;
port = uart_port_lock(state, flags);
if (port && uart_circ_chars_free(circ) != 0) {
@@ -543,6 +549,9 @@ static int uart_put_char(struct tty_struct *tty, unsigned char c)
ret = 1;
}
uart_port_unlock(port, flags);
+
+out:
+ mutex_unlock(&state->port.mutex);
return ret;
}
--
2.17.0
^ permalink raw reply related
* Re: [PATCH 1/2] serial: 8250: enable SERIAL_MCTRL_GPIO by default.
From: Giulio Benetti @ 2018-06-04 18:57 UTC (permalink / raw)
To: Andy Shevchenko, Greg Kroah-Hartman
Cc: Jiri Slaby, Kees Cook, Matthias Brugger, Allen Pais, Sean Young,
Ed Blake, Stefan Potyra, Philipp Zabel, Joshua Scott, Vignesh R,
Rolf Evers-Fischer, Aaron Sierra, Rafael Gago, Joel Stanley,
Sean Wang, linux-serial, linux-kernel, Yegor Yefremov
In-Reply-To: <b850a3cf565a24414d3290f6699f5a040bf61223.camel@linux.intel.com>
Il 04/06/2018 13:49, Andy Shevchenko ha scritto:
> On Fri, 2018-06-01 at 16:11 +0200, Giulio Benetti wrote:
>> It can be useful to override 8250 mctrl lines with gpios, for rts on
>> rs485 for example, when rts is not mapped correctly to HW RTS pin.
>>
>> Enable SERIAL_MCTRL_GPIO by default.
>>
>
> Unfortunately NAK, see
>
> commit 5db4f7f80d165fc9725f356e99feec409e446baa
> Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Date: Tue Aug 16 15:06:54 2016 +0300
>
> Revert "tty/serial/8250: use mctrl_gpio helpers"
>
> for the details.
>
> I would love to see a solution that will satisfy everyone, though I have
> only means to test proposals for now.
Thanks for pointing me that.
I would try to solve serial breakage on intel with already extisting
patches dropping this one.
I'm going to try.
I can't understand if it's enough using qemu x86 to reproduce the bug.
If so I'm going to debug and check what makes driver to fail.
Do you think it makes sense? Would it be accepted after bug fixing?
Thanks
Best regards
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
>
>> Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
>> ---
>> drivers/tty/serial/8250/Kconfig | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/tty/serial/8250/Kconfig
>> b/drivers/tty/serial/8250/Kconfig
>> index f005eaf8bc57..c7992b94fece 100644
>> --- a/drivers/tty/serial/8250/Kconfig
>> +++ b/drivers/tty/serial/8250/Kconfig
>> @@ -7,6 +7,7 @@ config SERIAL_8250
>> tristate "8250/16550 and compatible serial support"
>> depends on !S390
>> select SERIAL_CORE
>> + select SERIAL_MCTRL_GPIO if GPIOLIB
>> ---help---
>> This selects whether you want to include the driver for the
>> standard
>> serial ports. The standard answer is Y. People who might
>> say N
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox