* Re: [PATCH v2 00/21] Allow compile-testing NO_DMA (drivers)
From: Rob Herring @ 2018-04-05 0:32 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Ulf Hansson, Wolfram Sang, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-fpga-u79uwXL29TY76Z2rM5mHXA,
open list:REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM, Linux-ALSA,
Bjorn Andersson, Eric Anholt, netdev,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Linux I2C,
linux1394-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
Christoph Hellwig, Stefan Wahren, Boris Brezillon,
James E . J . Bottomley, Herbert Xu,
linux-scsi-u79uwXL29TY76Z2rM5mHXA, Richard Weinberger, Jassi Brar,
Marek Vasut, "open list:SERIAL DRIVERS" <linux-serial@
In-Reply-To: <1521208314-4783-1-git-send-email-geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
On Fri, Mar 16, 2018 at 8:51 AM, Geert Uytterhoeven
<geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
> Hi all,
>
> If NO_DMA=y, get_dma_ops() returns a reference to the non-existing
> symbol bad_dma_ops, thus causing a link failure if it is ever used.
>
> The intention of this is twofold:
> 1. To catch users of the DMA API on systems that do no support the DMA
> mapping API,
> 2. To avoid building drivers that cannot work on such systems anyway.
>
> However, the disadvantage is that we have to keep on adding dependencies
> on HAS_DMA all over the place.
>
> Thanks to the COMPILE_TEST symbol, lots of drivers now depend on one or
> more platform dependencies (that imply HAS_DMA) || COMPILE_TEST, thus
> already covering intention #2. Having to add an explicit dependency on
> HAS_DMA here is cumbersome, and hinders compile-testing.
The same can be said for CONFIG_IOMEM and CONFIG_OF. Any plans to
remove those too? CONFIG_IOMEM is mostly just a !CONFIG_UM option.
Rob
^ permalink raw reply
* [GIT PULL] TTY/Serial patches for 4.17-rc1
From: Greg KH @ 2018-04-04 10:31 UTC (permalink / raw)
To: Linus Torvalds, Jiri Slaby
Cc: Stephen Rothwell, Andrew Morton, linux-kernel, linux-serial
The following changes since commit c698ca5278934c0ae32297a8725ced2e27585d7f:
Linux 4.16-rc6 (2018-03-18 17:48:42 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/ tags/tty-4.17-rc1
for you to fetch changes up to 4f794097797f551917b68797e39f25fcb17d5b3a:
serial: expose buf_overrun count through proc interface (2018-03-23 16:34:06 +0100)
----------------------------------------------------------------
TTY/Serial driver patches for 4.17-rc1
Here is the big set of tty and serial driver patches for 4.17-rc1
Not all that big really, most are just small fixes and additions to
existing drivers. There's a bunch of work on the imx serial driver
recently for some reason, and a new embedded serial driver added as
well.
Full details are in the shortlog.
All of these have been in the linux-next tree for a while with no
reported issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----------------------------------------------------------------
Alexey Khoroshilov (1):
serial: mxs-auart: disable clks of Alphascale ASM9260
Andy Shevchenko (2):
serial, pci_ids: Move duplicate IDs to PCI IDs database
serial: 8250_dw: Switch to use acpi_dev_present()
Bich HEMON (3):
dt-bindings: serial: stm32: add RS485 optional properties
serial: stm32: add support for RS485 hardware control mode
serial: stm32: fix initialization of RS485 mode
Christian Brauner (4):
devpts: hoist out check for DEVPTS_SUPER_MAGIC
devpts: resolve devpts bind-mounts
devpts: comment devpts_mntget()
selftests: add devpts selftests
Colin Ian King (1):
serial: mvebu-uart: remove duplicated bit-wise or of STAT_FRM_ERR
Frédéric Danis (1):
serdev: Fix typo in serdev_device_alloc
Gabriel Matni (1):
serial: mvebu-uart: fix tx lost characters
Geert Uytterhoeven (9):
serial: arc_uart: Fix out-of-bounds access through DT alias
serial: fsl_lpuart: Fix out-of-bounds access through DT alias
serial: imx: Fix out-of-bounds access through serial port index
serial: mxs-auart: Fix out-of-bounds access through serial port index
serial: pxa: Fix out-of-bounds access through serial port index
serial: samsung: Fix out-of-bounds access through serial port index
serial: sh-sci: Fix out-of-bounds access through DT alias
serial: sirf: Fix out-of-bounds access through DT alias
serial: xuartps: Fix out-of-bounds access through DT alias
Greg Kroah-Hartman (1):
Merge 4.16-rc6 into tty-next
Jan Kundrát (1):
gpio: serial: max310x: Use HW type for gpio_chip's label
Jeremy Kerr (1):
serial: expose buf_overrun count through proc interface
Joel Stanley (1):
serial: 8250: Add Nuvoton NPCM UART
Joshua Scott (1):
serial: 8250_dw: Allow TX FIFO to drain before writing to UART_LCR
Karthikeyan Ramasubramanian (1):
tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP
Kees Cook (4):
console: SisUSB2VGA: Drop dummy con_font_get()
console: Fill in struct consw argument names
console: Expand dummy functions for CFI
console: Drop added "static" for newport_con
Mathieu Malaterre (1):
powerpc: Mark the variable earlycon_acpi_spcr_enable maybe_unused
Michael Moese (1):
8250-men-mcb: add support for 16z025 and 16z057
Mike Frysinger (1):
vt: change SGR 21 to follow the standards
Palmer Dabbelt (1):
tty: New RISC-V SBI console driver
Patrice Chotard (3):
tty: st-asc: Update tty alias
ARM: dts: STi: Fix aliases property name for STi boards
ARM: dts: STi: Remove "console=ttyASN" from bootargs for STi boards
Sergei Shtylyov (1):
DT: serial: renesas,sci-serial: document R8A77980 bindings
Troy Kisky (1):
tty: serial: imx: allow breaks to be received when using dma
Ulrich Hecht (1):
serial: sh-sci: use hrtimer for receive timeout
Uwe Kleine-König (22):
serial: altera: ensure port->regshift is honored consistently
serial: altera: don't enable any irq if the device doesn't feature an irq
serial: altera: set RRDY flag also without irq
serial: imx: drop if that always evaluates to true
serial: imx: rename variables to match the register names
serial: imx: Only handle irqs that are actually enabled
serial: imx: simplify tracking of dma being initialized
serial: imx: drop check for enabled dma in .startup
serial: imx: Rename register fields to match newer reference manuals
serial: imx: document functions that are called with port.lock taken
serial: imx: add wrappers for writel and readl
serial: imx: implement shadow registers for UCRx and UFCR
serial: imx: simplify some conditions related to dma
serial: imx: simplify check that prevents starting PIO when DMA is in use
serial: imx: use u32 variables with matching names for registers
serial: imx: setup fifo waterlevel before enabling aging timer
serial: imx: Stop to receive in .stop_rx()
serial: imx: ensure that RX irqs are off if RX is off
serial: imx: Also enable the aging timer in PIO mode
serial: imx: Fix handling of TC irq in combination with DMA
serial: imx: don't prepare to send if no data is available
serial: imx: consistently use imx_uart_ as prefix for all functions
Vignesh R (2):
serial: 8250: Don't service RX FIFO if interrupts are disabled
serial: 8250: 8250_omap: Fix throttling when DMA is enabled
Wei Yongjun (1):
tty: serial: msm_geni_serial: Fix return value check in qcom_geni_serial_probe()
Documentation/devicetree/bindings/serial/8250.txt | 1 +
.../bindings/serial/renesas,sci-serial.txt | 2 +
.../devicetree/bindings/serial/st,stm32-usart.txt | 2 +
arch/arm/boot/dts/stih407-b2120.dts | 4 +-
arch/arm/boot/dts/stih410-b2120.dts | 4 +-
arch/arm/boot/dts/stih410-b2260.dts | 4 +-
arch/arm/boot/dts/stih418-b2199.dts | 4 +-
drivers/parport/parport_serial.c | 3 -
drivers/tty/hvc/Kconfig | 10 +
drivers/tty/hvc/Makefile | 1 +
drivers/tty/hvc/hvc_riscv_sbi.c | 60 +
drivers/tty/serdev/core.c | 2 +-
drivers/tty/serial/8250/8250_dw.c | 34 +-
drivers/tty/serial/8250/8250_men_mcb.c | 125 +-
drivers/tty/serial/8250/8250_of.c | 1 +
drivers/tty/serial/8250/8250_omap.c | 11 +-
drivers/tty/serial/8250/8250_pci.c | 3 -
drivers/tty/serial/8250/8250_port.c | 36 +-
drivers/tty/serial/8250/Kconfig | 5 +-
drivers/tty/serial/Kconfig | 15 +
drivers/tty/serial/Makefile | 1 +
drivers/tty/serial/altera_uart.c | 58 +-
drivers/tty/serial/arc_uart.c | 5 +
drivers/tty/serial/fsl_lpuart.c | 4 +
drivers/tty/serial/imx.c | 1209 +++++++++++---------
drivers/tty/serial/max310x.c | 2 +-
drivers/tty/serial/mvebu-uart.c | 4 +-
drivers/tty/serial/mxs-auart.c | 40 +-
drivers/tty/serial/pxa.c | 4 +
drivers/tty/serial/qcom_geni_serial.c | 1158 +++++++++++++++++++
drivers/tty/serial/samsung.c | 4 +
drivers/tty/serial/serial_core.c | 2 +
drivers/tty/serial/sh-sci.c | 51 +-
drivers/tty/serial/sirfsoc_uart.c | 5 +
drivers/tty/serial/st-asc.c | 4 +-
drivers/tty/serial/stm32-usart.c | 134 ++-
drivers/tty/serial/stm32-usart.h | 3 +
drivers/tty/serial/xilinx_uartps.c | 2 +-
drivers/tty/vt/vt.c | 6 +-
drivers/usb/misc/sisusbvga/sisusb_con.c | 68 +-
drivers/video/console/dummycon.c | 69 +-
drivers/video/console/newport_con.c | 8 +-
drivers/video/console/vgacon.c | 20 +-
drivers/video/fbdev/core/fbcon.c | 3 +-
fs/devpts/inode.c | 66 +-
include/linux/console.h | 58 +-
include/linux/pci_ids.h | 3 +
include/linux/serial_core.h | 2 +-
include/uapi/linux/serial_core.h | 3 +
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/filesystems/.gitignore | 1 +
tools/testing/selftests/filesystems/Makefile | 2 +-
tools/testing/selftests/filesystems/devpts_pts.c | 313 +++++
53 files changed, 2902 insertions(+), 738 deletions(-)
create mode 100644 drivers/tty/hvc/hvc_riscv_sbi.c
create mode 100644 drivers/tty/serial/qcom_geni_serial.c
create mode 100644 tools/testing/selftests/filesystems/devpts_pts.c
^ permalink raw reply
* [PATCH] serial: xuartps: Fix the early_console junk character issue
From: Michal Simek @ 2018-04-04 10:20 UTC (permalink / raw)
To: linux-kernel, monstr, agraf
Cc: Nava kishore Manne, Jiri Slaby, linux-serial, Greg Kroah-Hartman,
linux-arm-kernel
From: Nava kishore Manne <nava.manne@xilinx.com>
In the early_console_setup is trying to access the unregister clock value,
so we are receiving some garbage clk value because of this wrong clk value
the early_console_setup is fail to set the required console baud rate.
This path fix this issue.
Signed-off-by: Nava kishore Manne <navam@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
drivers/tty/serial/xilinx_uartps.c | 27 +--------------------------
1 file changed, 1 insertion(+), 26 deletions(-)
diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index 19d370779767..4176c3a0b4e8 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -1130,34 +1130,9 @@ static void cdns_early_write(struct console *con, const char *s,
static int __init cdns_early_console_setup(struct earlycon_device *device,
const char *opt)
{
- struct uart_port *port = &device->port;
-
- if (!port->membase)
+ if (!device->port.membase)
return -ENODEV;
- /* initialise control register */
- writel(CDNS_UART_CR_TX_EN|CDNS_UART_CR_TXRST|CDNS_UART_CR_RXRST,
- port->membase + CDNS_UART_CR);
-
- /* only set baud if specified on command line - otherwise
- * assume it has been initialized by a boot loader.
- */
- if (device->baud) {
- u32 cd = 0, bdiv = 0;
- u32 mr;
- int div8;
-
- cdns_uart_calc_baud_divs(port->uartclk, device->baud,
- &bdiv, &cd, &div8);
- mr = CDNS_UART_MR_PARITY_NONE;
- if (div8)
- mr |= CDNS_UART_MR_CLKSEL;
-
- writel(mr, port->membase + CDNS_UART_MR);
- writel(cd, port->membase + CDNS_UART_BAUDGEN);
- writel(bdiv, port->membase + CDNS_UART_BAUDDIV);
- }
-
device->con->write = cdns_early_write;
return 0;
--
1.9.1
^ permalink raw reply related
* [PATCH v3 0/3] Add r8a77470/iW-RainboW-G23S single board computer support
From: Biju Das @ 2018-04-03 11:19 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Michael Turquette, Stephen Boyd,
Philipp Zabel, Greg Kroah-Hartman, Russell King
Cc: Fabrizio Castro, Kishon Vijay Abraham I, Chris Paterson,
Borislav Petkov, Geert Uytterhoeven, Sergei Shtylyov, devicetree,
Tony Lindgren, Magnus Damm, Krzysztof Kozlowski, Vladimir Barinov,
linux-renesas-soc, Marc Zyngier, Simon Horman, Jacopo Mondi,
linux-arm-kernel, linux-serial, Biju Das, linux-clk,
Arnd Bergmann, Marek Szyprowski
Hello,
This series adds support for Rensas RZ/G1C (r8a77470) SoC and
RZ/G1C based iW-RainboW-G23S single board computer.
The series introduces a cpg-mssr clock/power gating module, a power/reset
controller for the SoC.
power areas for RZ/G1C are similar to RZ/G1E.
Few functionalities have currently been enabled in DTS and tested: serial
boot console.
This patch series tested against renesas-dev branch
tag "renesas-dev-20180328-v4.16-rc7
V1-->V2
Incorporated geert's review comments.
V2-->V3
Incorporated simon and geert's review comments.
Biju Das (3):
serial: sh-sci: Document r8a77470 bindings
ARM: dts: r8a77470: Initial SoC device tree
ARM: dts: iwg23s-sbc: Add support for iWave G23S-SBC based on RZ/G1C
.../bindings/serial/renesas,sci-serial.txt | 2 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts | 35 +++++
arch/arm/boot/dts/r8a77470.dtsi | 154 +++++++++++++++++++++
4 files changed, 192 insertions(+)
create mode 100644 arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
create mode 100644 arch/arm/boot/dts/r8a77470.dtsi
--
2.7.4
^ permalink raw reply
* Re: [PATCH v1 2/7] serdev: add dev_pm_domain_attach|detach()
From: Marcel Holtmann @ 2018-04-03 10:29 UTC (permalink / raw)
To: sean.wang
Cc: Rob Herring, Mark Rutland, Johan Hedberg, devicetree,
Bluez mailing list, linux-arm-kernel, linux-mediatek, LKML,
Rob Herring, Ulf Hansson, Greg Kroah-Hartman, Jiri Slaby,
linux-serial
In-Reply-To: <f976766cd499c8d7053a1f442aba1494b4d3314f.1522736996.git.sean.wang@mediatek.com>
Hi Sean,
> In order to open up the required power gate before any operation can be
> effectively performed over the serial bus between CPU and serdev, it's
> clearly essential to add common attach functions for PM domains to serdev
> at the probe phase.
>
> Similarly, the relevant dettach function for the PM domains should be
> properly and reversely added at the remove phase.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Jiri Slaby <jslaby@suse.com>
> Cc: linux-serial@vger.kernel.org
> ---
> drivers/tty/serdev/core.c | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
> index df93b72..c93d8ee 100644
> --- a/drivers/tty/serdev/core.c
> +++ b/drivers/tty/serdev/core.c
> @@ -13,6 +13,7 @@
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/of_device.h>
> +#include <linux/pm_domain.h>
> #include <linux/serdev.h>
> #include <linux/slab.h>
>
> @@ -330,8 +331,16 @@ EXPORT_SYMBOL_GPL(serdev_device_set_tiocm);
> static int serdev_drv_probe(struct device *dev)
> {
> const struct serdev_device_driver *sdrv = to_serdev_device_driver(dev->driver);
> + int ret;
> +
> + ret = dev_pm_domain_attach(dev, true);
> + if (ret != -EPROBE_DEFER) {
> + ret = sdrv->probe(to_serdev_device(dev));
> + if (ret)
> + dev_pm_domain_detach(dev, true);
> + }
so if this is deferred, when does the serdev device gets probed?
>
> - return sdrv->probe(to_serdev_device(dev));
> + return ret;
> }
>
> static int serdev_drv_remove(struct device *dev)
> @@ -339,6 +348,9 @@ static int serdev_drv_remove(struct device *dev)
> const struct serdev_device_driver *sdrv = to_serdev_device_driver(dev->driver);
> if (sdrv->remove)
> sdrv->remove(to_serdev_device(dev));
> +
> + dev_pm_domain_detach(dev, true);
> +
> return 0;
> }
Regards
Marcel
^ permalink raw reply
* [PATCH v1 2/7] serdev: add dev_pm_domain_attach|detach()
From: sean.wang @ 2018-04-03 7:15 UTC (permalink / raw)
To: robh+dt, mark.rutland, marcel, johan.hedberg
Cc: devicetree, Ulf Hansson, Rob Herring, Greg Kroah-Hartman,
Sean Wang, linux-kernel, linux-bluetooth, linux-mediatek,
linux-serial, Jiri Slaby, linux-arm-kernel
In-Reply-To: <cover.1522736996.git.sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
In order to open up the required power gate before any operation can be
effectively performed over the serial bus between CPU and serdev, it's
clearly essential to add common attach functions for PM domains to serdev
at the probe phase.
Similarly, the relevant dettach function for the PM domains should be
properly and reversely added at the remove phase.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-serial@vger.kernel.org
---
drivers/tty/serdev/core.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
index df93b72..c93d8ee 100644
--- a/drivers/tty/serdev/core.c
+++ b/drivers/tty/serdev/core.c
@@ -13,6 +13,7 @@
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_device.h>
+#include <linux/pm_domain.h>
#include <linux/serdev.h>
#include <linux/slab.h>
@@ -330,8 +331,16 @@ EXPORT_SYMBOL_GPL(serdev_device_set_tiocm);
static int serdev_drv_probe(struct device *dev)
{
const struct serdev_device_driver *sdrv = to_serdev_device_driver(dev->driver);
+ int ret;
+
+ ret = dev_pm_domain_attach(dev, true);
+ if (ret != -EPROBE_DEFER) {
+ ret = sdrv->probe(to_serdev_device(dev));
+ if (ret)
+ dev_pm_domain_detach(dev, true);
+ }
- return sdrv->probe(to_serdev_device(dev));
+ return ret;
}
static int serdev_drv_remove(struct device *dev)
@@ -339,6 +348,9 @@ static int serdev_drv_remove(struct device *dev)
const struct serdev_device_driver *sdrv = to_serdev_device_driver(dev->driver);
if (sdrv->remove)
sdrv->remove(to_serdev_device(dev));
+
+ dev_pm_domain_detach(dev, true);
+
return 0;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2] serial: 8250: omap: Provide ability to enable/disable UART as wakeup source
From: Andy Shevchenko @ 2018-04-02 14:03 UTC (permalink / raw)
To: Vignesh R
Cc: Greg Kroah-Hartman, Jiri Slaby, Tony Lindgren,
open list:SERIAL DRIVERS, Linux Kernel Mailing List,
Linux OMAP Mailing List
In-Reply-To: <CAHp75VdKxsAb4ect_no0g8N2+DQ_OoitWKM8ZH6ao-sfD5dekw@mail.gmail.com>
On Mon, Apr 2, 2018 at 5:01 PM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Mon, Apr 2, 2018 at 3:20 PM, Vignesh R <vigneshr@ti.com> wrote:
>> + if (!device_may_wakeup(dev))
>> + priv->wer = 0;
>
> Can it be
>
> priv->wer = device_may_wakeup(dev);
>
> ?
Answering to myself, missed that this value is used as actual one for the HW.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2] serial: 8250: omap: Provide ability to enable/disable UART as wakeup source
From: Andy Shevchenko @ 2018-04-02 14:01 UTC (permalink / raw)
To: Vignesh R
Cc: Greg Kroah-Hartman, Jiri Slaby, Tony Lindgren,
open list:SERIAL DRIVERS, Linux Kernel Mailing List,
Linux OMAP Mailing List
In-Reply-To: <20180402122037.2710-1-vigneshr@ti.com>
On Mon, Apr 2, 2018 at 3:20 PM, Vignesh R <vigneshr@ti.com> wrote:
> + pm_runtime_get_sync(dev);
> + if (!device_may_wakeup(dev))
> + priv->wer = 0;
Can it be
priv->wer = device_may_wakeup(dev);
?
> + serial_out(up, UART_OMAP_WER, priv->wer);
> + pm_runtime_mark_last_busy(dev);
> + pm_runtime_put_autosuspend(dev);
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v2] serial: 8250: omap: Provide ability to enable/disable UART as wakeup source
From: Vignesh R @ 2018-04-02 12:20 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Jiri Slaby, Tony Lindgren, Vignesh R, linux-serial, linux-kernel,
linux-omap
Enable/Clear module level UART wakeup in UART_OMAP_WER register based on
return value of device_may_wakeup() in .suspend(). This allows
userspace to use sysfs to control the ability of UART to wakeup the
system from deep sleep state. Register is restored back in .startup()
call that happens as part of resume sequence.
With this patch, userspace can control UART wakeup capability via sysfs:
To enable wakeup capability:
echo enabled > /sys/class/tty/ttyXX/device/power/wakeup
For disabling wakeup capability:
echo disabled > /sys/class/tty/ttyXX/device/power/wakeup
Note that the UART wakeup events configured in the 8250 hardware only
work for idle modes that do not cut off power for the UART. For deeper
idle states, dedicated padconf wakeirqs must be used. Or in some cases
the UART RX pin can be remuxed to GPIO input if the GPIO block stays
powered.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
---
v2: update commit log.
drivers/tty/serial/8250/8250_omap.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
index 624b501fd253..6aaa84355fd1 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -1310,8 +1310,17 @@ static void omap8250_complete(struct device *dev)
static int omap8250_suspend(struct device *dev)
{
struct omap8250_priv *priv = dev_get_drvdata(dev);
+ struct uart_8250_port *up = serial8250_get_port(priv->line);
serial8250_suspend_port(priv->line);
+
+ pm_runtime_get_sync(dev);
+ if (!device_may_wakeup(dev))
+ priv->wer = 0;
+ serial_out(up, UART_OMAP_WER, priv->wer);
+ pm_runtime_mark_last_busy(dev);
+ pm_runtime_put_autosuspend(dev);
+
flush_work(&priv->qos_work);
return 0;
}
@@ -1403,6 +1412,8 @@ static int omap8250_runtime_suspend(struct device *dev)
/* Restore to UART mode after reset (for wakeup) */
omap8250_update_mdr1(up, priv);
+ /* Restore wakeup enable register */
+ serial_out(up, UART_OMAP_WER, priv->wer);
}
if (up->dma && up->dma->rxchan)
--
2.16.2
^ permalink raw reply related
* Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge
From: Aaron Durbin @ 2018-04-01 18:54 UTC (permalink / raw)
To: Alan Cox
Cc: Aaron Durbin, Andy Shevchenko, Daniel Kurtz,
Ricardo Ribalda Delgado, Greg Kroah-Hartman, Jiri Slaby,
Marc Gonzalez, Doug Anderson, Matt Redfearn, Jeffy,
open list:SERIAL DRIVERS, Linux Kernel Mailing List
In-Reply-To: <20180329143400.6d9256a5@alans-desktop>
On Thu, Mar 29, 2018 at 6:34 AM, Alan Cox <gnomes@lxorguk.ukuu.org.uk> wrote:
> On Mon, 26 Mar 2018 20:56:45 -0600
> Aaron Durbin <adurbin@chromium.org> wrote:
>
>> On Mon, Mar 26, 2018 at 12:24 PM, Alan Cox <gnomes@lxorguk.ukuu.org.uk> wrote:
>> >> Sadly, this situation
>> >> is not unique to this hardware. There is hardware all over that does
>> >> not meet the current assumptions being made in the early uart drivers
>> >> within the kernel.
>> >
>> > Is there any fundamental reason you can't just embed dt entries in the
>> > ACPI table to describe the other features you need. I appreciate it
>> > doesn't solve the generic PC case but it ought to help for anything where
>> > the firmware cares about Linux ?
>>
>> What's the method for doing that? Using _DSD methods? Or have a
>> pointer to examples? Sorry, I haven't spelunked into the current state
>> of bridging ACPI and devicetree in a while.
>
> ACPI 5.1 adds an _DSD method UUID for device properties.
>
> The kernel device_property_* interface will pick them up just as if they
> came from DT tables etc.
But we don't have the full ACPI interpreter up in the early part of
the kernel. All these 'early' devices have their own setup/config
which is the source of the issue. Or maybe I am wrong about the full
interpreter and the early drivers are just not taking advantage of the
ACPI device binding?
-Aaron
^ permalink raw reply
* Re: How to move serial8250_init out of the critical path to decrease boot time?
From: Greg Kroah-Hartman @ 2018-04-01 8:05 UTC (permalink / raw)
To: Paul Menzel; +Cc: linux-serial, linux-kernel
In-Reply-To: <e086c888-df77-1fde-e3b8-9246c9ab3377@molgen.mpg.de>
On Sun, Apr 01, 2018 at 09:11:15AM +0200, Paul Menzel wrote:
> Dear Linux folks,
>
>
> The goal is to boot a *distribution* Linux kernel as fast as possible. (The
> goal is currently 500 ms.)
What distro?
> With Linux 4.16-rc7, `serial8250_init()` takes almost 34 ms according to
> `initcall_debug` on the laptop TUXEDO Book BU1406 with an Intel Kaby Lake
> processor.
>
> ```
> [ 2.657950] calling serial8250_init+0x0/0x168 @ 1
> [ 2.657963] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
> [ 2.692598] initcall serial8250_init+0x0/0x168 returned 0 after 33820
> usecs
> ```
>
> One problem is, that the distributions do not build this as a module,
> despite more and more devices do not actually have serial connectors, but
> the chipset still exposes them.
Then fix that in the distro kernel build.
> What options are there?
File a bug with the distro.
> 1. Try to probe it asynchronously as in the attached patch, which is not
> tested yet.
Please test it and watch to see what breaks :)
good luck!
greg k-h
^ permalink raw reply
* How to move serial8250_init out of the critical path to decrease boot time?
From: Paul Menzel @ 2018-04-01 7:11 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-serial, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1137 bytes --]
Dear Linux folks,
The goal is to boot a *distribution* Linux kernel as fast as possible.
(The goal is currently 500 ms.)
With Linux 4.16-rc7, `serial8250_init()` takes almost 34 ms according to
`initcall_debug` on the laptop TUXEDO Book BU1406 with an Intel Kaby
Lake processor.
```
[ 2.657950] calling serial8250_init+0x0/0x168 @ 1
[ 2.657963] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
[ 2.692598] initcall serial8250_init+0x0/0x168 returned 0 after 33820
usecs
```
One problem is, that the distributions do not build this as a module,
despite more and more devices do not actually have serial connectors,
but the chipset still exposes them.
What options are there?
1. Try to probe it asynchronously as in the attached patch, which is
not tested yet.
2. Where possible try to deactivate this in the firmware?
3. Recommend to build this as a module? But this would only fix future
systems?
4. Avoid the probe, by have an interface to pass the infomr
5. Add an option to disable the driver, which could be specified on the
Linux kernel command line? `8250.disable`?
Kind regards,
Paul
[-- Attachment #2: 0001-tty-serial-8250-Request-driver-probe-from-an-async-t.patch --]
[-- Type: text/x-patch, Size: 1080 bytes --]
>From 536100229e59d9ff7c910d0c26e1c54a56daba81 Mon Sep 17 00:00:00 2001
From: Paul Menzel <pmenzel@molgen.mpg.de>
Date: Sun, 1 Apr 2018 08:57:53 +0200
Subject: [PATCH] tty/serial/8250: Request driver probe from an async task
Currently, according to `initcall_debug` running `serial8250_init` takes
around 33 ms on a Lenovo X60 and TUXEDO Book BU1406.
As this is in the critical path, and most distributions do *not* build
*8250* as a module, that means `CONFIG_SERIAL_8250=y`, probe the device
asynchronously, so other tasks are not hold up.
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
---
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 9342fc2ee7df..996de9c78001 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -894,6 +894,7 @@ static struct platform_driver serial8250_isa_driver = {
.driver = {
.name = "serial8250",
},
+ .driver.probe_type = PROBE_PREFER_ASYNCHRONOUS,
};
/*
--
2.14.1
^ permalink raw reply related
* Re: ns16550 earlycon baud broken on BCM5301X since commit 31cb9a8575ca0 ("earlycon: initialise baud field of earlycon device structure")
From: Rafał Miłecki @ 2018-03-29 14:37 UTC (permalink / raw)
To: Eugeniy Paltsev
Cc: gregkh@linuxfoundation.org, jonmason@broadcom.com,
hauke@hauke-m.de, Alexey Brodkin,
bcm-kernel-feedback-list@broadcom.com,
linux-serial@vger.kernel.org, jslaby@suse.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1522329420.32101.3.camel@synopsys.com>
On 29 March 2018 at 15:17, Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> wrote:
> Hm, your 'port->uartclk' value (and therefore 'BASE_BAUD' value) looks strange to me...
> Looks like you have 'BASE_BAUD' set to 115200.
>
>
> Here is my example:
> uart clock is 33333333Hz (fixed 33.33MHz xtal clock)
> So 'BASE_BAUD' is 33333333/16 = 2083333
> So 'port->uartclk' is BASE_BAUD*16 = 33333328
> 'device->baud' is 115200 (which is read from device tree)
> So when we calculate divisor with this code
> ------------------->8---------------
> divisor = DIV_ROUND_CLOSEST(port->uartclk, 16 * device->baud);
> ------------------->8---------------
> We got 'divisor' = 181 which is correct value for us.
You're right. 115200 is the default BASE_BAUD value coming from:
./include/asm-generic/serial.h:#define BASE_BAUD (1843200 / 16)
You must be using arch/machine that has custom serial.h with different value.
Could there be some wrong logic regarding uartclk / BASE_BAUD / baud
in the tty subsystem?
^ permalink raw reply
* Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge
From: Alan Cox @ 2018-03-29 13:34 UTC (permalink / raw)
To: Aaron Durbin
Cc: Andy Shevchenko, Daniel Kurtz, Ricardo Ribalda Delgado,
Greg Kroah-Hartman, Jiri Slaby, Marc Gonzalez, Doug Anderson,
Matt Redfearn, Jeffy, open list:SERIAL DRIVERS,
Linux Kernel Mailing List
In-Reply-To: <CAE2855tGOq2jjqaZUnWJKL953iM6+9JCgkCAEXhKLkkLRdgUBg@mail.gmail.com>
On Mon, 26 Mar 2018 20:56:45 -0600
Aaron Durbin <adurbin@chromium.org> wrote:
> On Mon, Mar 26, 2018 at 12:24 PM, Alan Cox <gnomes@lxorguk.ukuu.org.uk> wrote:
> >> Sadly, this situation
> >> is not unique to this hardware. There is hardware all over that does
> >> not meet the current assumptions being made in the early uart drivers
> >> within the kernel.
> >
> > Is there any fundamental reason you can't just embed dt entries in the
> > ACPI table to describe the other features you need. I appreciate it
> > doesn't solve the generic PC case but it ought to help for anything where
> > the firmware cares about Linux ?
>
> What's the method for doing that? Using _DSD methods? Or have a
> pointer to examples? Sorry, I haven't spelunked into the current state
> of bridging ACPI and devicetree in a while.
ACPI 5.1 adds an _DSD method UUID for device properties.
The kernel device_property_* interface will pick them up just as if they
came from DT tables etc.
Alan
^ permalink raw reply
* Re: ns16550 earlycon baud broken on BCM5301X since commit 31cb9a8575ca0 ("earlycon: initialise baud field of earlycon device structure")
From: Koen Vandeputte @ 2018-03-29 13:23 UTC (permalink / raw)
To: Eugeniy Paltsev, zajec5@gmail.com
Cc: gregkh@linuxfoundation.org, jonmason@broadcom.com,
hauke@hauke-m.de, Alexey Brodkin,
bcm-kernel-feedback-list@broadcom.com,
linux-serial@vger.kernel.org, jslaby@suse.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1522329420.32101.3.camel@synopsys.com>
shouldn't 1843200 be 18432000 (as in 18.432 MHz)?
(I used this source clock a lot during my 8051 days a long time ago :) )
Koen
On 2018-03-29 15:17, Eugeniy Paltsev wrote:
> Hi Rafał,
>
> Hm, your 'port->uartclk' value (and therefore 'BASE_BAUD' value) looks strange to me...
> Looks like you have 'BASE_BAUD' set to 115200.
>
>
> Here is my example:
> uart clock is 33333333Hz (fixed 33.33MHz xtal clock)
> So 'BASE_BAUD' is 33333333/16 = 2083333
> So 'port->uartclk' is BASE_BAUD*16 = 33333328
> 'device->baud' is 115200 (which is read from device tree)
> So when we calculate divisor with this code
> ------------------->8---------------
> divisor = DIV_ROUND_CLOSEST(port->uartclk, 16 * device->baud);
> ------------------->8---------------
> We got 'divisor' = 181 which is correct value for us.
>
>
> On Thu, 2018-03-29 at 14:34 +0200, Rafał Miłecki wrote:
>> Hi,
>>
>> I upgraded my BCM5301X device based on BCM4708 SoC from 4.13 to 4.14
>> and noticed earlycon output is corrupted (a wrong baud rate is used).
>>
>>
>> I bisected this problem down to the:
>>
>> commit 31cb9a8575ca04f47ea113434d4782b695638b62
>> Author: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
>> Date: Mon Aug 21 19:22:13 2017 +0300
>>
>> earlycon: initialise baud field of earlycon device structure
>>
>>
>> My device uses arch/arm/boot/dts/bcm4708.dtsi:
>>
>> uart0: serial@0300 {
>> compatible = "ns16550";
>> reg = <0x0300 0x100>;
>> interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
>> clocks = <&iprocslow>;
>> status = "okay";
>> };
>>
>> aliases {
>> serial0 = &uart0;
>> };
>>
>> chosen {
>> stdout-path = "serial0:115200n8";
>> };
>>
>>
>> A valid UART divisor for my device is 54. This is what bootloader sets
>> and what works with my serial console running 115200 8n1.
>>
>>
>> Before the commit 31cb9a8575ca0 early_serial8250_setup() never tried
>> setting baud because device->baud was 0. It left baud (divisor) to
>> whatever was configured by the bootloader. It has changed with above
>> commit though. So now the setup looks like that:
>> 1) port->uartclk equals 1843200 as set in the of_setup_earlycon():
>> port->uartclk = BASE_BAUD * 16;
>> 2) [NEW] device->baud equals 115200 as set in the of_setup_earlycon():
>> early_console_dev.baud = simple_strtoul(options, NULL, 0);
>> (a value of options is "115200n8")
>> 3) [NEW] divisor is calculated to 1 in the init_port():
>> divisor = DIV_ROUND_CLOSEST(port->uartclk, 16 * device->baud);
>> 4) [NEW] divisor is set using UART_DLL and UART_DLM in the init_port()
>>
>> Obviously setting divisor 1 instead of 54 results in a wrong baud.
>>
>>
>> So right now my serial console output looks like that:
>> �6;'+{.��s�.���.".��4��.�����.��J|�.�.8��.�..������g��~.����L>.��,�9z9�{�Z�.."���NC�<�9.�/���.�.�}��~.���"�.�|����;?�.��yy�.[
>> 0.043623] console [ttyS0] enabled
>> [ 0.043623] console [ttyS0] enabled
>> [ 0.050842] bootconsole [ns16550] disabled
>> [ 0.050842] bootconsole [ns16550] disabled
>> [ 0.062939] libphy: Fixed MDIO Bus: probed
>> (...)
>>
>> For a complete log (coming from dmesg command) see attachment.
>>
>>
>> Can you take a look at this problem, please? Is there something wrong
>> with my DT? Or is a problem in 8250 or earlycon?
>>
--
Koen Vandeputte - Software Developer
koen.vandeputte@ncentric.com | +32499736158
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: ns16550 earlycon baud broken on BCM5301X since commit 31cb9a8575ca0 ("earlycon: initialise baud field of earlycon device structure")
From: Eugeniy Paltsev @ 2018-03-29 13:17 UTC (permalink / raw)
To: zajec5@gmail.com
Cc: gregkh@linuxfoundation.org, jonmason@broadcom.com,
hauke@hauke-m.de, Alexey Brodkin,
bcm-kernel-feedback-list@broadcom.com,
linux-serial@vger.kernel.org, jslaby@suse.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CACna6rzki=sjXQS12eF3yPXH7XeFYTCXVOdj--F=P=jkJZX7fg@mail.gmail.com>
Hi Rafał,
Hm, your 'port->uartclk' value (and therefore 'BASE_BAUD' value) looks strange to me...
Looks like you have 'BASE_BAUD' set to 115200.
Here is my example:
uart clock is 33333333Hz (fixed 33.33MHz xtal clock)
So 'BASE_BAUD' is 33333333/16 = 2083333
So 'port->uartclk' is BASE_BAUD*16 = 33333328
'device->baud' is 115200 (which is read from device tree)
So when we calculate divisor with this code
------------------->8---------------
divisor = DIV_ROUND_CLOSEST(port->uartclk, 16 * device->baud);
------------------->8---------------
We got 'divisor' = 181 which is correct value for us.
On Thu, 2018-03-29 at 14:34 +0200, Rafał Miłecki wrote:
> Hi,
>
> I upgraded my BCM5301X device based on BCM4708 SoC from 4.13 to 4.14
> and noticed earlycon output is corrupted (a wrong baud rate is used).
>
>
> I bisected this problem down to the:
>
> commit 31cb9a8575ca04f47ea113434d4782b695638b62
> Author: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
> Date: Mon Aug 21 19:22:13 2017 +0300
>
> earlycon: initialise baud field of earlycon device structure
>
>
> My device uses arch/arm/boot/dts/bcm4708.dtsi:
>
> uart0: serial@0300 {
> compatible = "ns16550";
> reg = <0x0300 0x100>;
> interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&iprocslow>;
> status = "okay";
> };
>
> aliases {
> serial0 = &uart0;
> };
>
> chosen {
> stdout-path = "serial0:115200n8";
> };
>
>
> A valid UART divisor for my device is 54. This is what bootloader sets
> and what works with my serial console running 115200 8n1.
>
>
> Before the commit 31cb9a8575ca0 early_serial8250_setup() never tried
> setting baud because device->baud was 0. It left baud (divisor) to
> whatever was configured by the bootloader. It has changed with above
> commit though. So now the setup looks like that:
> 1) port->uartclk equals 1843200 as set in the of_setup_earlycon():
> port->uartclk = BASE_BAUD * 16;
> 2) [NEW] device->baud equals 115200 as set in the of_setup_earlycon():
> early_console_dev.baud = simple_strtoul(options, NULL, 0);
> (a value of options is "115200n8")
> 3) [NEW] divisor is calculated to 1 in the init_port():
> divisor = DIV_ROUND_CLOSEST(port->uartclk, 16 * device->baud);
> 4) [NEW] divisor is set using UART_DLL and UART_DLM in the init_port()
>
> Obviously setting divisor 1 instead of 54 results in a wrong baud.
>
>
> So right now my serial console output looks like that:
> �6;'+{.��s�.���.".��4��.�����.��J|�.�.8��.�..������g��~.����L>.��,�9z9�{�Z�.."���NC�<�9.�/���.�.�}��~.���"�.�|����;?�.��yy�.[
> 0.043623] console [ttyS0] enabled
> [ 0.043623] console [ttyS0] enabled
> [ 0.050842] bootconsole [ns16550] disabled
> [ 0.050842] bootconsole [ns16550] disabled
> [ 0.062939] libphy: Fixed MDIO Bus: probed
> (...)
>
> For a complete log (coming from dmesg command) see attachment.
>
>
> Can you take a look at this problem, please? Is there something wrong
> with my DT? Or is a problem in 8250 or earlycon?
>
--
Eugeniy Paltsev
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* ns16550 earlycon baud broken on BCM5301X since commit 31cb9a8575ca0 ("earlycon: initialise baud field of earlycon device structure")
From: Rafał Miłecki @ 2018-03-29 12:34 UTC (permalink / raw)
To: Eugeniy Paltsev, Greg Kroah-Hartman, Jiri Slaby, linux-serial,
Hauke Mehrtens, Jon Mason, bcm-kernel-feedback-list,
linux-arm-kernel@lists.infradead.org
[-- Attachment #1: Type: text/plain, Size: 2448 bytes --]
Hi,
I upgraded my BCM5301X device based on BCM4708 SoC from 4.13 to 4.14
and noticed earlycon output is corrupted (a wrong baud rate is used).
I bisected this problem down to the:
commit 31cb9a8575ca04f47ea113434d4782b695638b62
Author: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Date: Mon Aug 21 19:22:13 2017 +0300
earlycon: initialise baud field of earlycon device structure
My device uses arch/arm/boot/dts/bcm4708.dtsi:
uart0: serial@0300 {
compatible = "ns16550";
reg = <0x0300 0x100>;
interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&iprocslow>;
status = "okay";
};
aliases {
serial0 = &uart0;
};
chosen {
stdout-path = "serial0:115200n8";
};
A valid UART divisor for my device is 54. This is what bootloader sets
and what works with my serial console running 115200 8n1.
Before the commit 31cb9a8575ca0 early_serial8250_setup() never tried
setting baud because device->baud was 0. It left baud (divisor) to
whatever was configured by the bootloader. It has changed with above
commit though. So now the setup looks like that:
1) port->uartclk equals 1843200 as set in the of_setup_earlycon():
port->uartclk = BASE_BAUD * 16;
2) [NEW] device->baud equals 115200 as set in the of_setup_earlycon():
early_console_dev.baud = simple_strtoul(options, NULL, 0);
(a value of options is "115200n8")
3) [NEW] divisor is calculated to 1 in the init_port():
divisor = DIV_ROUND_CLOSEST(port->uartclk, 16 * device->baud);
4) [NEW] divisor is set using UART_DLL and UART_DLM in the init_port()
Obviously setting divisor 1 instead of 54 results in a wrong baud.
So right now my serial console output looks like that:
�6;'+{.��s�.���.".��4��.�����.��J|�.�.8��.�..������g��~.����L>.��,�9z9�{�Z�.."���NC�<�9.�/���.�.�}��~.���"�.�|����;?�.��yy�.[
0.043623] console [ttyS0] enabled
[ 0.043623] console [ttyS0] enabled
[ 0.050842] bootconsole [ns16550] disabled
[ 0.050842] bootconsole [ns16550] disabled
[ 0.062939] libphy: Fixed MDIO Bus: probed
(...)
For a complete log (coming from dmesg command) see attachment.
Can you take a look at this problem, please? Is there something wrong
with my DT? Or is a problem in 8250 or earlycon?
--
Rafał
[-- Attachment #2: dmesg.txt --]
[-- Type: text/plain, Size: 5512 bytes --]
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] random: get_random_bytes called from start_kernel+0x28/0x3a8 with crng_init=0
[ 0.000000] Linux version 4.13.0-rc5+ (zajec@linux-samsung.lan) (gcc version 7.3.0 (OpenWrt GCC 7.3.0 r6427+1-ed3860c3e3)) #0 SMP Tue Mar 27 09:33:51 2018
[ 0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt: Machine model: Luxul XAP-1510 V1
[ 0.000000] earlycon: ns16550 at MMIO 0x18000300 (options '115200n8')
[ 0.000000] bootconsole [ns16550] enabled
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] Hit pending asynchronous external abort (FSR=0x00001c06) during first unmask, this is most likely caused by a firmware/bootloader bug.
[ 0.000000] percpu: Embedded 14 pages/cpu @c7ed4000 s26572 r8192 d22580 u57344
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
[ 0.000000] Kernel command line: console=ttyS0,115200 earlycon
[ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
[ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.000000] Memory: 123204K/131072K available (4096K kernel code, 110K rwdata, 816K rodata, 1024K init, 293K bss, 7868K reserved, 0K cma-reserved, 0K highmem)
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
[ 0.000000] vmalloc : 0xc8800000 - 0xff800000 ( 880 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xc8000000 ( 128 MB)
[ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
[ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
[ 0.000000] .text : 0xc0008000 - 0xc0500000 (5088 kB)
[ 0.000000] .init : 0xc0600000 - 0xc0700000 (1024 kB)
[ 0.000000] .data : 0xc0700000 - 0xc071ba40 ( 111 kB)
[ 0.000000] .bss : 0xc071ba40 - 0xc076514c ( 294 kB)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[ 0.000000] Hierarchical RCU implementation.
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] L2C-310 cache controller enabled, 16 ways, 256 kB
[ 0.000000] L2C-310: CACHE_ID 0x410000c8, AUX_CTRL 0x0a130000
[ 0.000017] sched_clock: 64 bits at 400MHz, resolution 2ns, wraps every 4398046511103ns
[ 0.008536] clocksource: arm_global_timer: mask: 0xffffffffffffffff max_cycles: 0x5c4093a7d1, max_idle_ns: 440795210635 ns
[ 0.020288] Switching to timer-based delay loop, resolution 2ns
[ 0.026902] Calibrating delay loop (skipped), value calculated using timer frequency.. 800.00 BogoMIPS (lpj=4000000)
[ 0.038468] pid_max: default: 32768 minimum: 301
[ 0.043609] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.050668] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.058963] CPU: Testing write buffer coherency: ok
[ 0.064541] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.071125] Setting up static identity map for 0x100000 - 0x10003c
[ 0.077950] Hierarchical SRCU implementation.
[ 0.083177] smp: Bringing up secondary CPUs ...
[ 0.088934] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.089061] smp: Brought up 1 node, 2 CPUs
[ 0.099529] SMP: Total of 2 processors activated (1600.00 BogoMIPS).
[ 0.106315] CPU: WARNING: CPU(s) started in wrong/inconsistent modes (primary CPU mode 0x13)
[ 0.115346] CPU: This may indicate a broken bootloader or firmware.
[ 0.124186] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.134761] futex hash table entries: 512 (order: 3, 32768 bytes)
[ 0.141421] pinctrl core: initialized pinctrl subsystem
[ 0.147498] NET: Registered protocol family 16
[ 0.153026] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.162370] random: fast init done
[ 0.175223] clocksource: Switched to clocksource arm_global_timer
[ 0.182987] NET: Registered protocol family 2
[ 0.188307] TCP established hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.195823] TCP bind hash table entries: 1024 (order: 1, 8192 bytes)
[ 0.202676] TCP: Hash tables configured (established 1024 bind 1024)
[ 0.209613] UDP hash table entries: 256 (order: 1, 8192 bytes)
[ 0.215886] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
[ 0.222894] NET: Registered protocol family 1
[ 0.229199] workingset: timestamp_bits=30 max_order=15 bucket_order=0
[ 0.241675] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[ 0.248020] jffs2: version 2.2. (NAND) (SUMMARY) �� 2001-2006 Red Hat, Inc.
[ 0.259223] io scheduler noop registered
[ 0.263418] io scheduler deadline registered (default)
[ 0.268977] io scheduler mq-deadline registered
[ 0.273817] io scheduler kyber registered
[ 0.279206] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[ 0.287045] console [ttyS0] disabled
[ 0.290933] 18000300.serial: ttyS0 at MMIO 0x18000300 (irq = 18, base_baud = 6250000) is a 16550
[ 0.300420] console [ttyS0] enabled
[ 0.300420] console [ttyS0] enabled
[ 0.307614] bootconsole [ns16550] disabled
[ 0.307614] bootconsole [ns16550] disabled
[ 0.319308] libphy: Fixed MDIO Bus: probed
(...)
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] serial: 8250: omap: Provide ability to enable/disable UART as wakeup source
From: Vignesh R @ 2018-03-29 5:32 UTC (permalink / raw)
To: Tony Lindgren
Cc: Greg Kroah-Hartman, Jiri Slaby, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org
In-Reply-To: <20180328223020.GL5700@atomide.com>
On Thursday 29 March 2018 04:00 AM, Tony Lindgren wrote:
> * Vignesh R <vigneshr@ti.com> [180327 12:03]:
>> Enable/Clear module level UART wakeup in UART_OMAP_WER register based on
>> return value of device_may_wakeup() in .suspend(). This allows
>> userspace to use sysfs to control the ability of UART to wakeup the
>> system from deep sleep state. Register is restored back in .startup()
>> call that happens as part of resume sequence.
>>
>> With this patch, userspace can control UART wakeup capability via sysfs:
>> To enable wakeup capability:
>> echo enabled > /sys/class/tty/ttyXX/device/power/wakeup
>> For disabling wakeup capability:
>> echo disabled > /sys/class/tty/ttyXX/device/power/wakeup
>
> To avoid confusion, can you please add this to the description:
>
> Note that the UART wakeup events configured in the 8250 hardware only
> work for idle modes that do not cut off power for the UART. For deeper
> idle states, dedicated padconf wakeirqs must be used. Or in some cases
> the UART RX pin can be remuxed to GPIO input if the GPIO block stays
> powered.
>
That makes sense, I will add it to patch description in v2.
> I tested this briefly and the dedicated wakeirqs still work for me,
> so from that point of view:
>
> Tested-by: Tony Lindgren <tony@atomide.com>
Thanks for testing!
--
Regards
Vignesh
^ permalink raw reply
* Re: [PATCH] serial: 8250: omap: Provide ability to enable/disable UART as wakeup source
From: Tony Lindgren @ 2018-03-28 22:30 UTC (permalink / raw)
To: Vignesh R
Cc: Greg Kroah-Hartman, Jiri Slaby, linux-serial, linux-kernel,
linux-omap
In-Reply-To: <20180327120217.4749-1-vigneshr@ti.com>
* Vignesh R <vigneshr@ti.com> [180327 12:03]:
> Enable/Clear module level UART wakeup in UART_OMAP_WER register based on
> return value of device_may_wakeup() in .suspend(). This allows
> userspace to use sysfs to control the ability of UART to wakeup the
> system from deep sleep state. Register is restored back in .startup()
> call that happens as part of resume sequence.
>
> With this patch, userspace can control UART wakeup capability via sysfs:
> To enable wakeup capability:
> echo enabled > /sys/class/tty/ttyXX/device/power/wakeup
> For disabling wakeup capability:
> echo disabled > /sys/class/tty/ttyXX/device/power/wakeup
To avoid confusion, can you please add this to the description:
Note that the UART wakeup events configured in the 8250 hardware only
work for idle modes that do not cut off power for the UART. For deeper
idle states, dedicated padconf wakeirqs must be used. Or in some cases
the UART RX pin can be remuxed to GPIO input if the GPIO block stays
powered.
I tested this briefly and the dedicated wakeirqs still work for me,
so from that point of view:
Tested-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH v2 0/8] Add r8a77470/iW-RainboW-G23S single board computer support
From: Biju Das @ 2018-03-28 19:27 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Michael Turquette, Stephen Boyd,
Philipp Zabel, Greg Kroah-Hartman, Russell King
Cc: Fabrizio Castro, Kishon Vijay Abraham I, Chris Paterson,
Borislav Petkov, Geert Uytterhoeven, Sergei Shtylyov, devicetree,
Tony Lindgren, Magnus Damm, Krzysztof Kozlowski, Vladimir Barinov,
linux-renesas-soc, Marc Zyngier, Simon Horman, Jacopo Mondi,
linux-arm-kernel, linux-serial, Biju Das, linux-clk,
Arnd Bergmann, Marek Szyprowski
Hello,
This series adds support for Rensas RZ/G1C (r8a77470) SoC and
RZ/G1C based iW-RainboW-G23S single board computer.
The series introduces a cpg-mssr clock/power gating module, a power/reset
controller for the SoC.
power areas for RZ/G1C are similar to RZ/G1E.
Few functionalities have currently been enabled in DTS and tested: serial
boot console.
This patch series tested against renesas-dev branch
tag "renesas-dev-20180328-v4.16-rc7
V1-->V2
Incorporated geert's review comments.
Biju Das (8):
soc: renesas: rcar-sysc: Add r8a77470 support
serial: sh-sci: Document r8a77470 bindings
clk: renesas: Add r8a77470 CPG Core Clock Definitions
clk: renesas: cpg-mssr: Add r8a77470 support
ARM: shmobile: r8a77470: basic SoC support
ARM: dts: r8a77470: Initial SoC device tree
ARM: dts: iwg23s-sbc: Add support for iWave G23S-SBC based on RZ/G1C
ARM: multi_v7_defconfig: Enable r8a77470 SoC
Documentation/devicetree/bindings/arm/shmobile.txt | 2 +
.../devicetree/bindings/clock/renesas,cpg-mssr.txt | 9 +-
.../bindings/power/renesas,rcar-sysc.txt | 1 +
.../bindings/serial/renesas,sci-serial.txt | 2 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts | 35 ++++
arch/arm/boot/dts/r8a77470.dtsi | 156 ++++++++++++++
arch/arm/configs/multi_v7_defconfig | 1 +
arch/arm/mach-shmobile/Kconfig | 4 +
arch/arm/mach-shmobile/setup-rcar-gen2.c | 2 +
drivers/clk/renesas/Kconfig | 5 +
drivers/clk/renesas/Makefile | 1 +
drivers/clk/renesas/r8a77470-cpg-mssr.c | 229 +++++++++++++++++++++
drivers/clk/renesas/rcar-gen2-cpg.c | 12 ++
drivers/clk/renesas/renesas-cpg-mssr.c | 6 +
drivers/clk/renesas/renesas-cpg-mssr.h | 1 +
drivers/soc/renesas/Kconfig | 5 +
drivers/soc/renesas/Makefile | 1 +
drivers/soc/renesas/r8a77470-sysc.c | 29 +++
drivers/soc/renesas/rcar-sysc.c | 3 +
drivers/soc/renesas/rcar-sysc.h | 1 +
include/dt-bindings/clock/r8a77470-cpg-mssr.h | 36 ++++
include/dt-bindings/power/r8a77470-sysc.h | 22 ++
23 files changed, 561 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
create mode 100644 arch/arm/boot/dts/r8a77470.dtsi
create mode 100644 drivers/clk/renesas/r8a77470-cpg-mssr.c
create mode 100644 drivers/soc/renesas/r8a77470-sysc.c
create mode 100644 include/dt-bindings/clock/r8a77470-cpg-mssr.h
create mode 100644 include/dt-bindings/power/r8a77470-sysc.h
--
2.7.4
^ permalink raw reply
* Re: [PATCH] Bluetooth: hci_bcm: Remove DMI quirk for the MINIX Z83-4
From: Marcel Holtmann @ 2018-03-28 9:39 UTC (permalink / raw)
To: ianwmorrison
Cc: Gustavo F. Padovan, Johan Hedberg, Bluez mailing list,
linux-serial, linux-acpi, stable, hdegoede
In-Reply-To: <20180326220928.2755-1-ianwmorrison@gmail.com>
Hi Ian,
> As Interrupt resource specified IRQs are now assumed to be always
> active-low the DMI quirk for the MINIX Z83-4 is no longer required.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Ian W MORRISON <ianwmorrison@gmail.com>
> ---
> drivers/bluetooth/hci_bcm.c | 7 -------
> 1 file changed, 7 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* [PATCH 00/12] Add r8a77470/iW-RainboW-G23S single board computer support
From: Biju Das @ 2018-03-27 14:37 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Michael Turquette, Stephen Boyd,
Philipp Zabel, Greg Kroah-Hartman, Russell King
Cc: Fabrizio Castro, Kishon Vijay Abraham I, Chris Paterson,
Borislav Petkov, Geert Uytterhoeven, Sergei Shtylyov, devicetree,
Tony Lindgren, Magnus Damm, Krzysztof Kozlowski, Vladimir Barinov,
linux-renesas-soc, Marc Zyngier, Simon Horman, Jacopo Mondi,
linux-arm-kernel, linux-serial, Biju Das, linux-clk,
Arnd Bergmann, Marek Szyprowski
Hello,
This series adds support for Rensas RZ/G1C (r8a77470) SoC and
RZ/G1C based iW-RainboW-G23S single board computer.
The series introduces a cpg-mssr clock/power gating module, a power/reset
controller for the SoC.
power areas for RZ/G1C are similar to RZ/G1E.
Few functionalities have currently been enabled in DTS and tested: serial
boot console.
This patch series tested against linux-next tag next-20180327 and
renesas-dev branch tag "renesas-dev-20180326v2-v4.16-rc7
Biju Das (12):
soc: renesas: rcar-sysc: Add r8a77470 support
soc: renesas: Identify RZ/G1C
soc: renesas: rcar-rst: Add support for RZ/G1C
serial: sh-sci: Document r8a77470 bindings
clk: renesas: Add r8a77470 CPG Core Clock Definitions
clk: renesas: cpg-mssr: Add r8a77470 support
ARM: shmobile: r8a77470: basic SoC support
ARM: dts: r8a77470: Initial SoC device tree
ARM: shmobile: Document iW-RainboW-G23S single board computer
ARM: dts: iwg23s-sbc: Add support for iWave G23S-SBC based on RZ/G1C
ARM: shmobile: defconfig: Enable r8a77470 SoC
ARM: multi_v7_defconfig: Enable r8a77470 SoC
Documentation/devicetree/bindings/arm/shmobile.txt | 4 +
.../devicetree/bindings/clock/renesas,cpg-mssr.txt | 9 +-
.../bindings/power/renesas,rcar-sysc.txt | 1 +
.../devicetree/bindings/reset/renesas,rst.txt | 1 +
.../bindings/serial/renesas,sci-serial.txt | 2 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts | 30 +++
arch/arm/boot/dts/r8a77470.dtsi | 156 ++++++++++++++
arch/arm/configs/multi_v7_defconfig | 1 +
arch/arm/configs/shmobile_defconfig | 1 +
arch/arm/mach-shmobile/Kconfig | 4 +
arch/arm/mach-shmobile/setup-rcar-gen2.c | 2 +
drivers/clk/renesas/Kconfig | 5 +
drivers/clk/renesas/Makefile | 1 +
drivers/clk/renesas/r8a7747x-cpg-mssr.c | 229 +++++++++++++++++++++
drivers/clk/renesas/rcar-gen2-cpg.c | 34 ++-
drivers/clk/renesas/renesas-cpg-mssr.c | 6 +
drivers/clk/renesas/renesas-cpg-mssr.h | 1 +
drivers/soc/renesas/Kconfig | 5 +
drivers/soc/renesas/Makefile | 1 +
drivers/soc/renesas/r8a7747x-sysc.c | 29 +++
drivers/soc/renesas/rcar-rst.c | 1 +
drivers/soc/renesas/rcar-sysc.c | 3 +
drivers/soc/renesas/rcar-sysc.h | 1 +
drivers/soc/renesas/renesas-soc.c | 8 +
include/dt-bindings/clock/r8a7747x-cpg-mssr.h | 36 ++++
include/dt-bindings/power/r8a7747x-sysc.h | 22 ++
27 files changed, 587 insertions(+), 7 deletions(-)
create mode 100644 arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
create mode 100644 arch/arm/boot/dts/r8a77470.dtsi
create mode 100644 drivers/clk/renesas/r8a7747x-cpg-mssr.c
create mode 100644 drivers/soc/renesas/r8a7747x-sysc.c
create mode 100644 include/dt-bindings/clock/r8a7747x-cpg-mssr.h
create mode 100644 include/dt-bindings/power/r8a7747x-sysc.h
--
2.7.4
^ permalink raw reply
* [PATCH] serial: 8250: omap: Provide ability to enable/disable UART as wakeup source
From: Vignesh R @ 2018-03-27 12:02 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Jiri Slaby, Tony Lindgren, Vignesh R, linux-serial, linux-kernel,
linux-omap
Enable/Clear module level UART wakeup in UART_OMAP_WER register based on
return value of device_may_wakeup() in .suspend(). This allows
userspace to use sysfs to control the ability of UART to wakeup the
system from deep sleep state. Register is restored back in .startup()
call that happens as part of resume sequence.
With this patch, userspace can control UART wakeup capability via sysfs:
To enable wakeup capability:
echo enabled > /sys/class/tty/ttyXX/device/power/wakeup
For disabling wakeup capability:
echo disabled > /sys/class/tty/ttyXX/device/power/wakeup
Signed-off-by: Vignesh R <vigneshr@ti.com>
---
drivers/tty/serial/8250/8250_omap.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
index 624b501fd253..6aaa84355fd1 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -1310,8 +1310,17 @@ static void omap8250_complete(struct device *dev)
static int omap8250_suspend(struct device *dev)
{
struct omap8250_priv *priv = dev_get_drvdata(dev);
+ struct uart_8250_port *up = serial8250_get_port(priv->line);
serial8250_suspend_port(priv->line);
+
+ pm_runtime_get_sync(dev);
+ if (!device_may_wakeup(dev))
+ priv->wer = 0;
+ serial_out(up, UART_OMAP_WER, priv->wer);
+ pm_runtime_mark_last_busy(dev);
+ pm_runtime_put_autosuspend(dev);
+
flush_work(&priv->qos_work);
return 0;
}
@@ -1403,6 +1412,8 @@ static int omap8250_runtime_suspend(struct device *dev)
/* Restore to UART mode after reset (for wakeup) */
omap8250_update_mdr1(up, priv);
+ /* Restore wakeup enable register */
+ serial_out(up, UART_OMAP_WER, priv->wer);
}
if (up->dma && up->dma->rxchan)
--
2.16.2
^ permalink raw reply related
* Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge
From: Aaron Durbin @ 2018-03-27 2:56 UTC (permalink / raw)
To: Alan Cox
Cc: Aaron Durbin, Andy Shevchenko, Daniel Kurtz,
Ricardo Ribalda Delgado, Greg Kroah-Hartman, Jiri Slaby,
Marc Gonzalez, Doug Anderson, Matt Redfearn, Jeffy,
open list:SERIAL DRIVERS, Linux Kernel Mailing List
In-Reply-To: <20180326192428.71c23abf@alans-desktop>
On Mon, Mar 26, 2018 at 12:24 PM, Alan Cox <gnomes@lxorguk.ukuu.org.uk> wrote:
>> Sadly, this situation
>> is not unique to this hardware. There is hardware all over that does
>> not meet the current assumptions being made in the early uart drivers
>> within the kernel.
>
> Is there any fundamental reason you can't just embed dt entries in the
> ACPI table to describe the other features you need. I appreciate it
> doesn't solve the generic PC case but it ought to help for anything where
> the firmware cares about Linux ?
What's the method for doing that? Using _DSD methods? Or have a
pointer to examples? Sorry, I haven't spelunked into the current state
of bridging ACPI and devicetree in a while.
-Aaron
^ permalink raw reply
* Re: [PATCH v5] earlycon: Use a pointer table to fix __earlycon_table stride
From: Rob Herring @ 2018-03-26 22:24 UTC (permalink / raw)
To: Daniel Kurtz
Cc: Greg Kroah-Hartman, Guenter Roeck, adurbin, linux-kernel,
Frank Rowand, Jiri Slaby, Arnd Bergmann,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE,
open list:SERIAL DRIVERS,
open list:GENERIC INCLUDE/ASM HEADER FILES
In-Reply-To: <20180320220536.20245-1-djkurtz@chromium.org>
On Tue, Mar 20, 2018 at 04:05:36PM -0600, Daniel Kurtz wrote:
> Commit 99492c39f39f ("earlycon: Fix __earlycon_table stride") tried to fix
> __earlycon_table stride by forcing the earlycon_id struct alignment to 32
> and asking the linker to 32-byte align the __earlycon_table symbol. This
> fix was based on commit 07fca0e57fca92 ("tracing: Properly align linker
> defined symbols") which tried a similar fix for the tracing subsystem.
>
> However, this fix doesn't quite work because there is no guarantee that
> gcc will place structures packed into an array format. In fact, gcc 4.9
> chooses to 64-byte align these structs by inserting additional padding
> between the entries because it has no clue that they are supposed to be in
> an array. If we are unlucky, the linker will assign symbol
> "__earlycon_table" to a 32-byte aligned address which does not correspond
> to the 64-byte aligned contents of section "__earlycon_table".
>
> To address this same problem, the fix to the tracing system was
> subsequently re-implemented using a more robust table of pointers approach
> by commits:
> 3d56e331b653 ("tracing: Replace syscall_meta_data struct array with pointer array")
> 654986462939 ("tracepoints: Fix section alignment using pointer array")
> e4a9ea5ee7c8 ("tracing: Replace trace_event struct array with pointer array")
>
> Let's use this same "array of pointers to structs" approach for
> EARLYCON_TABLE.
Wouldn't every use of linker sections with structs have this problem? We
use them for clocks, irqs, timers unless those have been fixed.
>
> Fixes: 99492c39f39f ("earlycon: Fix __earlycon_table stride")
> Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
> Suggested-by: Aaron Durbin <adurbin@chromium.org>
> ---
> Changes since v2:
> * Use __initconst instead of __initdata to avoid h8300 and alpha kbuild errors
>
> Changes since v3:
> * Fixed typos in commit message
>
> Changes since v4:
> * removed Change-Id: from commit message
>
> drivers/of/fdt.c | 7 +++++--
> drivers/tty/serial/earlycon.c | 6 ++++--
> include/asm-generic/vmlinux.lds.h | 2 +-
> include/linux/serial_core.h | 21 ++++++++++++++-------
> 4 files changed, 24 insertions(+), 12 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ 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