* [PATCH] earlycon: Allow specifying a uartclk in options
From: Daniel Kurtz @ 2018-03-01 18:20 UTC (permalink / raw)
Cc: adurbin, briannorris, Daniel Kurtz, Greg Kroah-Hartman,
Jiri Slaby, open list:SERIAL DRIVERS, open list
Currently when an earlycon is registered, the uartclk is assumed to be
BASE_BAUD * 16 = 1843200. If a baud rate is specified in the earlycon
options, then 8250_early's init_port will program the UART clock divider
registers based on this assumed uartclk.
However, not all uarts have a UART clock of 1843200. For example, the
8250_dw uart in AMD's CZ/ST uses a fixed 48 MHz clock (as specified in
cz_uart_desc in acpi_apd.c). Thus, specifying a baud when using earlycon
on such a device will result in incorrect divider values and a wrong UART
clock.
Fix this by extending the earlycon options parameter to allow specification
of a uartclk, like so:
earlycon=uart,mmio32,0xfedc6000,115200,48000000
If none is specified, fall-back to prior behavior - 1843200.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
---
drivers/tty/serial/earlycon.c | 8 ++++++--
include/linux/serial_core.h | 2 +-
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index 870e84fb6e39..c9b38f520057 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -115,12 +115,17 @@ static int __init parse_options(struct earlycon_device *device, char *options)
}
if (options) {
- device->baud = simple_strtoul(options, NULL, 0);
+ char *uartclk;
+ device->baud = simple_strtoul(options, &uartclk, 0);
+ if (*uartclk++ == ',')
+ port->uartclk = simple_strtoul(uartclk, NULL, 0);
length = min(strcspn(options, " ") + 1,
(size_t)(sizeof(device->options)));
strlcpy(device->options, options, length);
}
+ port->uartclk = (port->uartclk) ?: BASE_BAUD * 16;
+
return 0;
}
@@ -134,7 +139,6 @@ static int __init register_earlycon(char *buf, const struct earlycon_id *match)
buf = NULL;
spin_lock_init(&port->lock);
- port->uartclk = BASE_BAUD * 16;
if (port->mapbase)
port->membase = earlycon_map(port->mapbase, 64);
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index b32df49a3bd5..b772f0d20b18 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -343,7 +343,7 @@ static inline int uart_poll_timeout(struct uart_port *port)
struct earlycon_device {
struct console *con;
struct uart_port port;
- char options[16]; /* e.g., 115200n8 */
+ char options[32]; /* e.g., 115200n8,48000000 */
unsigned int baud;
};
--
2.16.2.395.g2e18187dfd-goog
^ permalink raw reply related
* [PATCH] can: m_can: select pinctrl state in each suspend/resume function
From: Bich HEMON @ 2018-03-01 12:29 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Mark Rutland, Maxime Coquelin,
Alexandre TORGUE, Jiri Slaby, linux-serial@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: Bich HEMON
Make sure to apply the correct pin state in suspend/resume callbacks.
Putting pins in sleep state saves power.
Signed-off-by: Bich Hemon <bich.hemon@st.com>
---
drivers/net/can/m_can/m_can.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index 2594f77..a86ef69 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -1700,6 +1700,8 @@ static __maybe_unused int m_can_suspend(struct device *dev)
m_can_clk_stop(priv);
}
+ pinctrl_pm_select_sleep_state(dev);
+
priv->can.state = CAN_STATE_SLEEPING;
return 0;
@@ -1710,6 +1712,8 @@ static __maybe_unused int m_can_resume(struct device *dev)
struct net_device *ndev = dev_get_drvdata(dev);
struct m_can_priv *priv = netdev_priv(ndev);
+ pinctrl_pm_select_default_state(dev);
+
m_can_init_ram(priv);
priv->can.state = CAN_STATE_ERROR_ACTIVE;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] Bluetooth: btusb: Remove Yoga 920 from the btusb_needs_reset_resume_table
From: Marcel Holtmann @ 2018-03-01 7:43 UTC (permalink / raw)
To: Hans de Goede
Cc: Gustavo F. Padovan, Johan Hedberg, Kai-Heng Feng,
Bluez mailing list, linux-serial, ACPI Devel Maling List, stable,
Brian Norris
In-Reply-To: <20180228105750.6491-2-hdegoede@redhat.com>
Hi Hans,
> Commit 55a9c95d70ab ("Bluetooth: btusb: Use DMI matching for QCA
> reset_resume quirking"), added the Lenovo Yoga 920 to the
> btusb_needs_reset_resume_table.
>
> Testing has shown that this is a false positive and the problems where
> caused by issues with the initial fix: commit fd865802c66b ("Bluetooth:
> btusb: fix QCA Rome suspend/resume"), which has already been reverted.
>
> So the QCA Rome BT in the Yoga 920 does not need a reset-resume quirk at
> all and this commit removes it from the btusb_needs_reset_resume_table.
>
> Note that after this commit the btusb_needs_reset_resume_table is now
> empty. It is kept around on purpose, since this whole series of commits
> started for a reason and there are actually broken platforms around,
> which need to be added to it.
>
> BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1514836
> Fixes: 55a9c95d70ab ("Bluetooth: btusb: Use DMI matching for QCA ...")
> Cc: stable@vger.kernel.org
> Cc: Brian Norris <briannorris@chromium.org>
> Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
> Tested-by: Kevin Fenzi <kevin@scrye.com>
> Suggested-by: Brian Norris <briannorris@chromium.org>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/bluetooth/btusb.c | 7 -------
> 1 file changed, 7 deletions(-)
patch has been applied to bluetooth-stable tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Bluetooth: btusb: Remove Yoga 920 from the btusb_needs_reset_resume_table
From: Kai Heng Feng @ 2018-02-28 16:45 UTC (permalink / raw)
To: Brian Norris
Cc: Hans de Goede, Marcel Holtmann, Gustavo Padovan, Johan Hedberg,
Linux Bluetooth mailing list, linux-serial,
ACPI Devel Maling List, stable, Leif Liddy
In-Reply-To: <CA+ASDXNwiWXdhyRZMiMXkVazqGxr8pLfmTpo1hD2CbCBmNrzLg@mail.gmail.com>
Brian Norris <briannorris@chromium.org> wrote:
> + Leif
>
> On Wed, Feb 28, 2018 at 2:57 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Commit 55a9c95d70ab ("Bluetooth: btusb: Use DMI matching for QCA
>> reset_resume quirking"), added the Lenovo Yoga 920 to the
>> btusb_needs_reset_resume_table.
>>
>> Testing has shown that this is a false positive and the problems where
>> caused by issues with the initial fix: commit fd865802c66b ("Bluetooth:
>> btusb: fix QCA Rome suspend/resume"), which has already been reverted.
>>
>> So the QCA Rome BT in the Yoga 920 does not need a reset-resume quirk at
>> all and this commit removes it from the btusb_needs_reset_resume_table.
>>
>> Note that after this commit the btusb_needs_reset_resume_table is now
>> empty. It is kept around on purpose, since this whole series of commits
>> started for a reason and there are actually broken platforms around,
>> which need to be added to it.
>
> This is hilarious.
>
The platform at my hand still needs the quirk though, so the table is quite
useful.
I’ll send a patch soon.
> I think we need to go back to the author(s) of commit fd865802c66b and
> find proper details about said "numerous reported instances" of
> problems... Anyway:
>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
>
>> BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1514836
>> Fixes: 55a9c95d70ab ("Bluetooth: btusb: Use DMI matching for QCA ...")
>> Cc: stable@vger.kernel.org
>> Cc: Brian Norris <briannorris@chromium.org>
>> Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
>> Tested-by: Kevin Fenzi <kevin@scrye.com>
>> Suggested-by: Brian Norris <briannorris@chromium.org>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> drivers/bluetooth/btusb.c | 7 -------
>> 1 file changed, 7 deletions(-)
>>
>> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
>> index a4b62f0a93cc..418550eb1522 100644
>> --- a/drivers/bluetooth/btusb.c
>> +++ b/drivers/bluetooth/btusb.c
>> @@ -386,13 +386,6 @@ static const struct usb_device_id blacklist_table[]
>> = {
>> * the module itself. So we use a DMI list to match known broken platforms.
>> */
>> static const struct dmi_system_id btusb_needs_reset_resume_table[] = {
>> - {
>> - /* Lenovo Yoga 920 (QCA Rome device 0cf3:e300) */
>> - .matches = {
>> - DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>> - DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo YOGA 920"),
>> - },
>> - },
>> {}
>> };
>>
>> —
>> 2.14.3
^ permalink raw reply
* Re: [PATCH] Bluetooth: btusb: Remove Yoga 920 from the btusb_needs_reset_resume_table
From: Brian Norris @ 2018-02-28 16:38 UTC (permalink / raw)
To: Hans de Goede
Cc: Marcel Holtmann, Gustavo Padovan, Johan Hedberg, Kai-Heng Feng,
Linux Bluetooth mailing list, linux-serial,
ACPI Devel Maling List, stable, Leif Liddy
In-Reply-To: <20180228105750.6491-2-hdegoede@redhat.com>
+ Leif
On Wed, Feb 28, 2018 at 2:57 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Commit 55a9c95d70ab ("Bluetooth: btusb: Use DMI matching for QCA
> reset_resume quirking"), added the Lenovo Yoga 920 to the
> btusb_needs_reset_resume_table.
>
> Testing has shown that this is a false positive and the problems where
> caused by issues with the initial fix: commit fd865802c66b ("Bluetooth:
> btusb: fix QCA Rome suspend/resume"), which has already been reverted.
>
> So the QCA Rome BT in the Yoga 920 does not need a reset-resume quirk at
> all and this commit removes it from the btusb_needs_reset_resume_table.
>
> Note that after this commit the btusb_needs_reset_resume_table is now
> empty. It is kept around on purpose, since this whole series of commits
> started for a reason and there are actually broken platforms around,
> which need to be added to it.
This is hilarious.
I think we need to go back to the author(s) of commit fd865802c66b and
find proper details about said "numerous reported instances" of
problems... Anyway:
Reviewed-by: Brian Norris <briannorris@chromium.org>
> BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1514836
> Fixes: 55a9c95d70ab ("Bluetooth: btusb: Use DMI matching for QCA ...")
> Cc: stable@vger.kernel.org
> Cc: Brian Norris <briannorris@chromium.org>
> Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
> Tested-by: Kevin Fenzi <kevin@scrye.com>
> Suggested-by: Brian Norris <briannorris@chromium.org>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/bluetooth/btusb.c | 7 -------
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index a4b62f0a93cc..418550eb1522 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -386,13 +386,6 @@ static const struct usb_device_id blacklist_table[] = {
> * the module itself. So we use a DMI list to match known broken platforms.
> */
> static const struct dmi_system_id btusb_needs_reset_resume_table[] = {
> - {
> - /* Lenovo Yoga 920 (QCA Rome device 0cf3:e300) */
> - .matches = {
> - DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> - DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo YOGA 920"),
> - },
> - },
> {}
> };
>
> --
> 2.14.3
>
^ permalink raw reply
* Re: [PATCH 2/2] serial: stm32: update interrupt initialization
From: Andy Shevchenko @ 2018-02-28 15:41 UTC (permalink / raw)
To: Bich HEMON
Cc: Greg Kroah-Hartman, Rob Herring, Mark Rutland, Maxime Coquelin,
Alexandre TORGUE, Jiri Slaby, linux-serial@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CAHp75Vd+UcUSG7t6SxzTmUkB6d2TAYVmgO92m9iV0YVJ1=XbzA@mail.gmail.com>
On Wed, Feb 28, 2018 at 5:40 PM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Wed, Feb 28, 2018 at 12:51 PM, Bich HEMON <bich.hemon@st.com> wrote:
>> - port->irq = platform_get_irq(pdev, 0);
>> - stm32port->wakeirq = platform_get_irq(pdev, 1);
>> + stm32port->wakeirq = platform_get_irq_byname(pdev, "wakeup");
>
> But this one is redundant since Tony's patch:
> https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=bleeding-edge&id=da997b22c40473b7db60bde6ea188d35565d10c8
Oh, it'a bout getting a resource by name...
Sorry, discard my previous comment.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 2/2] serial: stm32: update interrupt initialization
From: Andy Shevchenko @ 2018-02-28 15:40 UTC (permalink / raw)
To: Bich HEMON
Cc: Greg Kroah-Hartman, Rob Herring, Mark Rutland, Maxime Coquelin,
Alexandre TORGUE, Jiri Slaby, linux-serial@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1519815044-22669-3-git-send-email-bich.hemon@st.com>
On Wed, Feb 28, 2018 at 12:51 PM, Bich HEMON <bich.hemon@st.com> wrote:
> For each port, get each IRQ using its specific name instead of its index.
>
> Signed-off-by: Bich Hemon <bich.hemon@st.com>
> ---
> drivers/tty/serial/stm32-usart.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
> index 0fa735b..5c85cbc 100644
> --- a/drivers/tty/serial/stm32-usart.c
> +++ b/drivers/tty/serial/stm32-usart.c
> @@ -680,8 +680,8 @@ static int stm32_init_port(struct stm32_port *stm32port,
> port->flags = UPF_BOOT_AUTOCONF;
> port->ops = &stm32_uart_ops;
> port->dev = &pdev->dev;
> - port->irq = platform_get_irq(pdev, 0);
> - stm32port->wakeirq = platform_get_irq(pdev, 1);
> + port->irq = platform_get_irq_byname(pdev, "event");
This is I have no idea about...
> + stm32port->wakeirq = platform_get_irq_byname(pdev, "wakeup");
But this one is redundant since Tony's patch:
https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=bleeding-edge&id=da997b22c40473b7db60bde6ea188d35565d10c8
> stm32port->fifoen = stm32port->info->cfg.has_fifo;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> --
> 1.9.1
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v7 04/37] earlycon: add reg-offset to physical address before mapping
From: Greg Kroah-Hartman @ 2018-02-28 12:39 UTC (permalink / raw)
To: Rob Herring
Cc: Greentime Hu, greentime, linux-kernel@vger.kernel.org,
Arnd Bergmann, linux-arch, Thomas Gleixner, Jason Cooper,
Marc Zyngier, netdev, deanbo422, devicetree, Al Viro,
David Howells, Will Deacon, Daniel Lezcano, linux-serial,
Geert Uytterhoeven, Linus Walleij, Mark Rutland, ren_guo,
Randy Dunlap, David Miller
In-Reply-To: <CAL_JsqJteT1P2GJGdesTsz=PuXU1qxiyhtKLURkGwV9sSQ7XZQ@mail.gmail.com>
On Thu, Feb 15, 2018 at 09:40:49AM -0600, Rob Herring wrote:
> On Tue, Feb 13, 2018 at 3:09 AM, Greentime Hu <green.hu@gmail.com> wrote:
> > It will get the wrong virtual address because port->mapbase is not added
> > the correct reg-offset yet. We have to update it before earlycon_map()
> > is called
> >
> > Signed-off-by: Greentime Hu <greentime@andestech.com>
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Peter Hurley <peter@hurleysoftware.com>
> > Cc: stable@vger.kernel.org
> > Fixes: 088da2a17619 ("of: earlycon: Initialize port fields from DT
> > properties")
>
> This should get applied now rather than sit in numerous revisions of
> this series for nds32.
>
> Acked-by: Rob Herring <robh@kernel.org>
>
> Greg, can you apply?
Yes, will queue it up now, thanks.
greg k-h
^ permalink raw reply
* Re: [PATCH v2] serial: 8250: Add Nuvoton NPCM UART
From: Greg Kroah-Hartman @ 2018-02-28 12:37 UTC (permalink / raw)
To: Joel Stanley
Cc: Rob Herring, Mark Rutland, linux-serial, devicetree, linux-kernel,
Tomer Maimon, Avi Fishman, Jeremy Kerr
In-Reply-To: <20180215021720.14870-1-joel@jms.id.au>
On Thu, Feb 15, 2018 at 12:47:20PM +1030, Joel Stanley wrote:
> The Nuvoton UART is almost compatible with the 8250 driver when probed
> via the 8250_of driver, however it requires some extra configuration
> at startup.
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
> v2:
> Remove redundant whitespace
> Use port number 40 to fill in a gap
>
> Documentation/devicetree/bindings/serial/8250.txt | 1 +
> drivers/tty/serial/8250/8250_of.c | 1 +
> drivers/tty/serial/8250/8250_port.c | 29 +++++++++++++++++++++++
> include/uapi/linux/serial_core.h | 3 +++
> include/uapi/linux/serial_reg.h | 5 ++++
> 5 files changed, 39 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/serial/8250.txt b/Documentation/devicetree/bindings/serial/8250.txt
> index dad3b2ec66d4..aeb6db4e35c3 100644
> --- a/Documentation/devicetree/bindings/serial/8250.txt
> +++ b/Documentation/devicetree/bindings/serial/8250.txt
> @@ -24,6 +24,7 @@ Required properties:
> - "ti,da830-uart"
> - "aspeed,ast2400-vuart"
> - "aspeed,ast2500-vuart"
> + - "nuvoton,npcm750-uart"
> - "serial" if the port type is unknown.
> - reg : offset and length of the register set for the device.
> - interrupts : should contain uart interrupt.
> diff --git a/drivers/tty/serial/8250/8250_of.c b/drivers/tty/serial/8250/8250_of.c
> index 160b8906d9b9..9835b1c1cbe1 100644
> --- a/drivers/tty/serial/8250/8250_of.c
> +++ b/drivers/tty/serial/8250/8250_of.c
> @@ -316,6 +316,7 @@ static const struct of_device_id of_platform_serial_table[] = {
> { .compatible = "mrvl,mmp-uart",
> .data = (void *)PORT_XSCALE, },
> { .compatible = "ti,da830-uart", .data = (void *)PORT_DA830, },
> + { .compatible = "nuvoton,npcm750-uart", .data = (void *)PORT_NPCM, },
> { /* end of list */ },
> };
> MODULE_DEVICE_TABLE(of, of_platform_serial_table);
> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
> index 1328c7e70108..a72222f8b005 100644
> --- a/drivers/tty/serial/8250/8250_port.c
> +++ b/drivers/tty/serial/8250/8250_port.c
> @@ -293,6 +293,15 @@ static const struct serial8250_config uart_config[] = {
> UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT,
> .flags = UART_CAP_FIFO,
> },
> + [PORT_NPCM] = {
> + .name = "Nuvoton 16550",
> + .fifo_size = 16,
> + .tx_loadsz = 16,
> + .fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10 |
> + UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT,
> + .rxtrig_bytes = {1, 4, 8, 14},
> + .flags = UART_CAP_FIFO,
> + },
> };
>
> /* Uart divisor latch read */
> @@ -2140,6 +2149,15 @@ int serial8250_do_startup(struct uart_port *port)
> UART_DA830_PWREMU_MGMT_FREE);
> }
>
> + if (port->type == PORT_NPCM) {
> + /*
> + * Nuvoton calls the scratch register 'UART_TOR' (timeout
> + * register). Enable it, and set TIOC (timeout interrupt
> + * comparator) to be 0x20 for correct operation.
> + */
> + serial_port_out(port, UART_NPCM_TOR, UART_NPCM_TOIE | 0x20);
> + }
> +
> #ifdef CONFIG_SERIAL_8250_RSA
> /*
> * If this is an RSA port, see if we can kick it up to the
> @@ -2462,6 +2480,15 @@ static unsigned int xr17v35x_get_divisor(struct uart_8250_port *up,
> return quot_16 >> 4;
> }
>
> +/* Nuvoton NPCM UARTs have a custom divisor calculation */
> +static unsigned int npcm_get_divisor(struct uart_8250_port *up,
> + unsigned int baud)
> +{
> + struct uart_port *port = &up->port;
> +
> + return DIV_ROUND_CLOSEST(port->uartclk, 16 * baud + 2) - 2;
> +}
> +
> static unsigned int serial8250_get_divisor(struct uart_8250_port *up,
> unsigned int baud,
> unsigned int *frac)
> @@ -2482,6 +2509,8 @@ static unsigned int serial8250_get_divisor(struct uart_8250_port *up,
> quot = 0x8002;
> else if (up->port.type == PORT_XR17V35X)
> quot = xr17v35x_get_divisor(up, baud, frac);
> + else if (up->port.type == PORT_NPCM)
> + quot = npcm_get_divisor(up, baud);
> else
> quot = uart_get_divisor(port, baud);
>
> diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
> index 1c8413f93e3d..dce5f9dae121 100644
> --- a/include/uapi/linux/serial_core.h
> +++ b/include/uapi/linux/serial_core.h
> @@ -76,6 +76,9 @@
> #define PORT_SUNZILOG 38
> #define PORT_SUNSAB 39
>
> +/* Nuvoton UART */
> +#define PORT_NPCM 40
> +
> /* Intel EG20 */
> #define PORT_PCH_8LINE 44
> #define PORT_PCH_2LINE 45
> diff --git a/include/uapi/linux/serial_reg.h b/include/uapi/linux/serial_reg.h
> index be07b5470f4b..f82f3c869df9 100644
> --- a/include/uapi/linux/serial_reg.h
> +++ b/include/uapi/linux/serial_reg.h
> @@ -376,5 +376,10 @@
> #define UART_ALTR_EN_TXFIFO_LW 0x01 /* Enable the TX FIFO Low Watermark */
> #define UART_ALTR_TX_LOW 0x41 /* Tx FIFO Low Watermark */
>
> +
> +/* Nuvoton NPCM timeout register */
> +#define UART_NPCM_TOR 7
> +#define UART_NPCM_TOIE BIT(7) /* Timeout Interrupt Enable */
Why is this needed in a userspace api file? That feels very odd for
just a new device. Please put this somewhere internal.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] Bluetooth: btusb: Remove Yoga 920 from the btusb_needs_reset_resume_table
From: Hans de Goede @ 2018-02-28 10:57 UTC (permalink / raw)
To: Marcel Holtmann, Gustavo Padovan, Johan Hedberg
Cc: Hans de Goede, Kai-Heng Feng, linux-bluetooth, linux-serial,
linux-acpi, stable, Brian Norris
In-Reply-To: <20180228105750.6491-1-hdegoede@redhat.com>
Commit 55a9c95d70ab ("Bluetooth: btusb: Use DMI matching for QCA
reset_resume quirking"), added the Lenovo Yoga 920 to the
btusb_needs_reset_resume_table.
Testing has shown that this is a false positive and the problems where
caused by issues with the initial fix: commit fd865802c66b ("Bluetooth:
btusb: fix QCA Rome suspend/resume"), which has already been reverted.
So the QCA Rome BT in the Yoga 920 does not need a reset-resume quirk at
all and this commit removes it from the btusb_needs_reset_resume_table.
Note that after this commit the btusb_needs_reset_resume_table is now
empty. It is kept around on purpose, since this whole series of commits
started for a reason and there are actually broken platforms around,
which need to be added to it.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1514836
Fixes: 55a9c95d70ab ("Bluetooth: btusb: Use DMI matching for QCA ...")
Cc: stable@vger.kernel.org
Cc: Brian Norris <briannorris@chromium.org>
Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
Tested-by: Kevin Fenzi <kevin@scrye.com>
Suggested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/bluetooth/btusb.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index a4b62f0a93cc..418550eb1522 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -386,13 +386,6 @@ static const struct usb_device_id blacklist_table[] = {
* the module itself. So we use a DMI list to match known broken platforms.
*/
static const struct dmi_system_id btusb_needs_reset_resume_table[] = {
- {
- /* Lenovo Yoga 920 (QCA Rome device 0cf3:e300) */
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
- DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo YOGA 920"),
- },
- },
{}
};
--
2.14.3
^ permalink raw reply related
* [PATCH 2/2] serial: stm32: add support for RS485 hardware control mode
From: Bich HEMON @ 2018-02-28 10:56 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Mark Rutland, Maxime Coquelin,
Alexandre TORGUE, Jiri Slaby, linux-serial@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: Bich HEMON
In-Reply-To: <1519815373-22940-1-git-send-email-bich.hemon@st.com>
Implement Driver Enable signal (DE) to activate the transmission mode
of the external transceiver.
Signed-off-by: Yves Coppeaux <yves.coppeaux@st.com>
Signed-off-by: Bich Hemon <bich.hemon@st.com>
---
drivers/tty/serial/stm32-usart.c | 134 ++++++++++++++++++++++++++++++++++++++-
drivers/tty/serial/stm32-usart.h | 3 +
2 files changed, 136 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
index 5c85cbc..6d34472 100644
--- a/drivers/tty/serial/stm32-usart.c
+++ b/drivers/tty/serial/stm32-usart.c
@@ -62,6 +62,113 @@ static void stm32_clr_bits(struct uart_port *port, u32 reg, u32 bits)
writel_relaxed(val, port->membase + reg);
}
+static void stm32_config_reg_rs485(u32 *cr1, u32 *cr3, u32 delay_ADE,
+ u32 delay_DDE, u32 baud)
+{
+ u32 rs485_deat_dedt;
+ u32 rs485_deat_dedt_max = (USART_CR1_DEAT_MASK >> USART_CR1_DEAT_SHIFT);
+ bool over8;
+
+ *cr3 |= USART_CR3_DEM;
+ over8 = *cr1 & USART_CR1_OVER8;
+
+ if (over8)
+ rs485_deat_dedt = delay_ADE * baud * 8;
+ else
+ rs485_deat_dedt = delay_ADE * baud * 16;
+
+ rs485_deat_dedt = DIV_ROUND_CLOSEST(rs485_deat_dedt, 1000);
+ rs485_deat_dedt = rs485_deat_dedt > rs485_deat_dedt_max ?
+ rs485_deat_dedt_max : rs485_deat_dedt;
+ rs485_deat_dedt = (rs485_deat_dedt << USART_CR1_DEAT_SHIFT) &
+ USART_CR1_DEAT_MASK;
+ *cr1 |= rs485_deat_dedt;
+
+ if (over8)
+ rs485_deat_dedt = delay_DDE * baud * 8;
+ else
+ rs485_deat_dedt = delay_DDE * baud * 16;
+
+ rs485_deat_dedt = DIV_ROUND_CLOSEST(rs485_deat_dedt, 1000);
+ rs485_deat_dedt = rs485_deat_dedt > rs485_deat_dedt_max ?
+ rs485_deat_dedt_max : rs485_deat_dedt;
+ rs485_deat_dedt = (rs485_deat_dedt << USART_CR1_DEDT_SHIFT) &
+ USART_CR1_DEDT_MASK;
+ *cr1 |= rs485_deat_dedt;
+}
+
+static int stm32_config_rs485(struct uart_port *port,
+ struct serial_rs485 *rs485conf)
+{
+ struct stm32_port *stm32_port = to_stm32_port(port);
+ struct stm32_usart_offsets *ofs = &stm32_port->info->ofs;
+ struct stm32_usart_config *cfg = &stm32_port->info->cfg;
+ u32 usartdiv, baud, cr1, cr3;
+ bool over8;
+ unsigned long flags;
+
+ spin_lock_irqsave(&port->lock, flags);
+ stm32_clr_bits(port, ofs->cr1, BIT(cfg->uart_enable_bit));
+
+ port->rs485 = *rs485conf;
+
+ rs485conf->flags |= SER_RS485_RX_DURING_TX;
+
+ if (rs485conf->flags & SER_RS485_ENABLED) {
+ cr1 = readl_relaxed(port->membase + ofs->cr1);
+ cr3 = readl_relaxed(port->membase + ofs->cr3);
+ usartdiv = readl_relaxed(port->membase + ofs->brr);
+ usartdiv = usartdiv & GENMASK(15, 0);
+ over8 = cr1 & USART_CR1_OVER8;
+
+ if (over8)
+ usartdiv = usartdiv | (usartdiv & GENMASK(4, 0))
+ << USART_BRR_04_R_SHIFT;
+
+ baud = DIV_ROUND_CLOSEST(port->uartclk, usartdiv);
+ stm32_config_reg_rs485(&cr1, &cr3,
+ rs485conf->delay_rts_before_send,
+ rs485conf->delay_rts_after_send, baud);
+
+ if (rs485conf->flags & SER_RS485_RTS_ON_SEND) {
+ cr3 &= ~USART_CR3_DEP;
+ rs485conf->flags &= ~SER_RS485_RTS_AFTER_SEND;
+ } else {
+ cr3 |= USART_CR3_DEP;
+ rs485conf->flags |= SER_RS485_RTS_AFTER_SEND;
+ }
+
+ writel_relaxed(cr3, port->membase + ofs->cr3);
+ writel_relaxed(cr1, port->membase + ofs->cr1);
+ } else {
+ stm32_clr_bits(port, ofs->cr3, USART_CR3_DEM | USART_CR3_DEP);
+ stm32_clr_bits(port, ofs->cr1,
+ USART_CR1_DEDT_MASK | USART_CR1_DEAT_MASK);
+ }
+
+ stm32_set_bits(port, ofs->cr1, BIT(cfg->uart_enable_bit));
+ spin_unlock_irqrestore(&port->lock, flags);
+
+ return 0;
+}
+
+static int stm32_init_rs485(struct uart_port *port,
+ struct platform_device *pdev)
+{
+ struct serial_rs485 *rs485conf = &port->rs485;
+
+ rs485conf->flags = 0;
+ rs485conf->delay_rts_before_send = 0;
+ rs485conf->delay_rts_after_send = 0;
+
+ if (!pdev->dev.of_node)
+ return -ENODEV;
+
+ uart_get_rs485_mode(&pdev->dev, rs485conf);
+
+ return 0;
+}
+
static int stm32_pending_rx(struct uart_port *port, u32 *sr, int *last_res,
bool threaded)
{
@@ -498,6 +605,7 @@ static void stm32_set_termios(struct uart_port *port, struct ktermios *termios,
struct stm32_port *stm32_port = to_stm32_port(port);
struct stm32_usart_offsets *ofs = &stm32_port->info->ofs;
struct stm32_usart_config *cfg = &stm32_port->info->cfg;
+ struct serial_rs485 *rs485conf = &port->rs485;
unsigned int baud;
u32 usartdiv, mantissa, fraction, oversampling;
tcflag_t cflag = termios->c_cflag;
@@ -515,7 +623,7 @@ static void stm32_set_termios(struct uart_port *port, struct ktermios *termios,
writel_relaxed(0, port->membase + ofs->cr1);
cr1 = USART_CR1_TE | USART_CR1_RE | USART_CR1_RXNEIE;
- cr1 |= BIT(cfg->uart_enable_bit);
+
if (stm32_port->fifoen)
cr1 |= USART_CR1_FIFOEN;
cr2 = 0;
@@ -553,9 +661,11 @@ static void stm32_set_termios(struct uart_port *port, struct ktermios *termios,
*/
if (usartdiv < 16) {
oversampling = 8;
+ cr1 |= USART_CR1_OVER8;
stm32_set_bits(port, ofs->cr1, USART_CR1_OVER8);
} else {
oversampling = 16;
+ cr1 &= ~USART_CR1_OVER8;
stm32_clr_bits(port, ofs->cr1, USART_CR1_OVER8);
}
@@ -592,10 +702,28 @@ static void stm32_set_termios(struct uart_port *port, struct ktermios *termios,
if (stm32_port->rx_ch)
cr3 |= USART_CR3_DMAR;
+ if (rs485conf->flags & SER_RS485_ENABLED) {
+ stm32_config_reg_rs485(&cr1, &cr3,
+ rs485conf->delay_rts_before_send,
+ rs485conf->delay_rts_after_send, baud);
+ if (rs485conf->flags & SER_RS485_RTS_ON_SEND) {
+ cr3 &= ~USART_CR3_DEP;
+ rs485conf->flags &= ~SER_RS485_RTS_AFTER_SEND;
+ } else {
+ cr3 |= USART_CR3_DEP;
+ rs485conf->flags |= SER_RS485_RTS_AFTER_SEND;
+ }
+
+ } else {
+ cr3 &= ~(USART_CR3_DEM | USART_CR3_DEP);
+ cr1 &= ~(USART_CR1_DEDT_MASK | USART_CR1_DEAT_MASK);
+ }
+
writel_relaxed(cr3, port->membase + ofs->cr3);
writel_relaxed(cr2, port->membase + ofs->cr2);
writel_relaxed(cr1, port->membase + ofs->cr1);
+ stm32_set_bits(port, ofs->cr1, BIT(cfg->uart_enable_bit));
spin_unlock_irqrestore(&port->lock, flags);
}
@@ -681,6 +809,10 @@ static int stm32_init_port(struct stm32_port *stm32port,
port->ops = &stm32_uart_ops;
port->dev = &pdev->dev;
port->irq = platform_get_irq_byname(pdev, "event");
+
+ port->rs485_config = stm32_config_rs485;
+ stm32_init_rs485(port, pdev);
+
stm32port->wakeirq = platform_get_irq_byname(pdev, "wakeup");
stm32port->fifoen = stm32port->info->cfg.has_fifo;
diff --git a/drivers/tty/serial/stm32-usart.h b/drivers/tty/serial/stm32-usart.h
index 2294d0f..6f294e2 100644
--- a/drivers/tty/serial/stm32-usart.h
+++ b/drivers/tty/serial/stm32-usart.h
@@ -135,6 +135,7 @@ struct stm32_usart_info stm32h7_info = {
#define USART_BRR_DIV_F_MASK GENMASK(3, 0)
#define USART_BRR_DIV_M_MASK GENMASK(15, 4)
#define USART_BRR_DIV_M_SHIFT 4
+#define USART_BRR_04_R_SHIFT 1
/* USART_CR1 */
#define USART_CR1_SBK BIT(0)
@@ -162,6 +163,8 @@ struct stm32_usart_info stm32h7_info = {
#define USART_CR1_M1 BIT(28) /* F7 */
#define USART_CR1_IE_MASK (GENMASK(8, 4) | BIT(14) | BIT(26) | BIT(27))
#define USART_CR1_FIFOEN BIT(29) /* H7 */
+#define USART_CR1_DEAT_SHIFT 21
+#define USART_CR1_DEDT_SHIFT 16
/* USART_CR2 */
#define USART_CR2_ADD_MASK GENMASK(3, 0) /* F4 */
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: serial: stm32: add RS485 optional properties
From: Bich HEMON @ 2018-02-28 10:56 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Mark Rutland, Maxime Coquelin,
Alexandre TORGUE, Jiri Slaby, linux-serial@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: Bich HEMON
In-Reply-To: <1519815373-22940-1-git-send-email-bich.hemon@st.com>
Add options for enabling RS485 hardware control and configuring
Driver Enable signal:
- rs485-rts-delay
- rs485-rx-during-tx
- rs485-rts-active-low
- linux,rs485-enabled-at-boot-time
Signed-off-by: Bich Hemon <bich.hemon@st.com>
---
Documentation/devicetree/bindings/serial/st,stm32-usart.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/st,stm32-usart.txt b/Documentation/devicetree/bindings/serial/st,stm32-usart.txt
index aaeb564..81e0011 100644
--- a/Documentation/devicetree/bindings/serial/st,stm32-usart.txt
+++ b/Documentation/devicetree/bindings/serial/st,stm32-usart.txt
@@ -16,6 +16,8 @@ Required properties:
Optional properties:
- pinctrl: The reference on the pins configuration
- st,hw-flow-ctrl: bool flag to enable hardware flow control.
+- rs485-rts-delay, rs485-rx-during-tx, rs485-rts-active-low,
+ linux,rs485-enabled-at-boot-time: see rs485.txt.
- dmas: phandle(s) to DMA controller node(s). Refer to stm32-dma.txt
- dma-names: "rx" and/or "tx"
- wakeup-source: bool flag to indicate this device has wakeup capabilities
--
1.9.1
^ permalink raw reply related
* [PATCH 0/2] Add support for RS485
From: Bich HEMON @ 2018-02-28 10:56 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Mark Rutland, Maxime Coquelin,
Alexandre TORGUE, Jiri Slaby, linux-serial@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: Bich HEMON
This patchset updates existing stm32 usart driver by adding support for RS485.
Bich Hemon (2):
dt-bindings: serial: stm32: add RS485 optional properties
serial: stm32: add support for RS485 hardware control mode
.../devicetree/bindings/serial/st,stm32-usart.txt | 2 +
drivers/tty/serial/stm32-usart.c | 134 ++++++++++++++++++++-
drivers/tty/serial/stm32-usart.h | 3 +
3 files changed, 138 insertions(+), 1 deletion(-)
--
1.9.1
^ permalink raw reply
* Re: [PATCH] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version
From: Hans de Goede @ 2018-02-28 10:54 UTC (permalink / raw)
To: Brian Norris
Cc: Marcel Holtmann, Gustavo F. Padovan, Johan Hedberg,
Bluez mailing list, linux-serial, ACPI Devel Maling List, stable,
Leif Liddy, Matthias Kaehlcke, Daniel Drake, Kai-Heng Feng,
Matadeen Mishra, Linux Kernel Mailing List, Greg Kroah-Hartman,
Guenter Roeck
In-Reply-To: <cdf043ef-b7d5-61f9-b8ea-7e75cb22485f@redhat.com>
Hi,
On 27-02-18 15:07, Hans de Goede wrote:
> Hi,
>
> On 27-02-18 03:29, Brian Norris wrote:
>> On Thu, Feb 22, 2018 at 11:14 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> On 23-02-18 04:12, Brian Norris wrote:
>>>> Hmm? I'm not sure I completely follow here when you say "he was not
>>>> hitting the firmware loading race". If things were functioning fine with
>>>> system suspend (but not with autosuspend), then he's not seeing the
>>>> controller (quoting commit fd865802c66b) "losing power during suspend".
>>>
>>>
>>> He was running a kernel with the original "fd865802c66b Bluetooth: btusb:
>>> fix QCA Rome suspend/resume" commit, which fixes regular suspend for
>>> devices which are "losing power during suspend", but does nothing for
>>> runtime-suspend.
>>>
>>> He ran tests both with and without runtime-pm enabled with that same kernel
>>> and he needed to disable runtime-pm to get working bluetooth.
>>
>> Did he ever test with commit fd865802c66b reverted?
>>
>> My symptoms were exactly the same as you described. BT was broken as
>> of v4.14 if I had runtime suspend enabled. Things were fine if I
>> either (a) reverted the patch or (b) disabled runtime suspend. I
>> obviously preferred (a), which is why I continued to complain :)
>>
>> Did your tester ever try (a)? If not, then I don't think you've really
>> ensured that he really needed a "fixed" version; he may not have
>> needed the patch at all.
>>
>> Or an alternative question: did that system work on an older Fedora
>> release (and presumably an older kernel)? If so, then he probably also
>> did not need that patch.
>>
>>>> So, that would suggest he could only be seeing the race (as I was), and
>>>> that his machine does not deserve a RESET_RESUME quirk?
>>>
>>>
>>> I hope my above answer helps to clarify why I believe the quirk is
>>> necessary on his machine.
>>
>> I'm sorry, but no it doesn't. If anything, it suggests to me even more
>> that it may not have been necessary.
>
> Ok, I've started another test-kernel build for the reporter this time
> without any quirks at all and I've asked him to test.
You were right, the Yoga 920 works fine without any quirks, thank you
for being persistent on getting this tested properly.
I will submit a patch dropping the Yoga 920 from the
btusb_needs_reset_resume_table.
Regards,
Hans
^ permalink raw reply
* [PATCH 2/2] serial: stm32: update interrupt initialization
From: Bich HEMON @ 2018-02-28 10:51 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Mark Rutland, Maxime Coquelin,
Alexandre TORGUE, Jiri Slaby, linux-serial@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: Bich HEMON
In-Reply-To: <1519815044-22669-1-git-send-email-bich.hemon@st.com>
For each port, get each IRQ using its specific name instead of its index.
Signed-off-by: Bich Hemon <bich.hemon@st.com>
---
drivers/tty/serial/stm32-usart.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
index 0fa735b..5c85cbc 100644
--- a/drivers/tty/serial/stm32-usart.c
+++ b/drivers/tty/serial/stm32-usart.c
@@ -680,8 +680,8 @@ static int stm32_init_port(struct stm32_port *stm32port,
port->flags = UPF_BOOT_AUTOCONF;
port->ops = &stm32_uart_ops;
port->dev = &pdev->dev;
- port->irq = platform_get_irq(pdev, 0);
- stm32port->wakeirq = platform_get_irq(pdev, 1);
+ port->irq = platform_get_irq_byname(pdev, "event");
+ stm32port->wakeirq = platform_get_irq_byname(pdev, "wakeup");
stm32port->fifoen = stm32port->info->cfg.has_fifo;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: serial: stm32: add wakeup option using note
From: Bich HEMON @ 2018-02-28 10:51 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Mark Rutland, Maxime Coquelin,
Alexandre TORGUE, Jiri Slaby, linux-serial@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: Bich HEMON
In-Reply-To: <1519815044-22669-1-git-send-email-bich.hemon@st.com>
Update bindings with interrupt-names and wakeup-source information
Signed-off-by: Bich Hemon <bich.hemon@st.com>
---
Documentation/devicetree/bindings/serial/st,stm32-usart.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/st,stm32-usart.txt b/Documentation/devicetree/bindings/serial/st,stm32-usart.txt
index d150b04..aaeb564 100644
--- a/Documentation/devicetree/bindings/serial/st,stm32-usart.txt
+++ b/Documentation/devicetree/bindings/serial/st,stm32-usart.txt
@@ -10,6 +10,7 @@ Required properties:
- interrupts:
- The interrupt line for the USART instance,
- An optional wake-up interrupt.
+- interrupt-names: Contains "event" for the USART interrupt line.
- clocks: The input clock of the USART instance
Optional properties:
@@ -17,6 +18,9 @@ Optional properties:
- st,hw-flow-ctrl: bool flag to enable hardware flow control.
- dmas: phandle(s) to DMA controller node(s). Refer to stm32-dma.txt
- dma-names: "rx" and/or "tx"
+- wakeup-source: bool flag to indicate this device has wakeup capabilities
+- interrupt-names : Should contain "wakeup" if optional wake-up interrupt is
+ used.
Examples:
usart4: serial@40004c00 {
--
1.9.1
^ permalink raw reply related
* [PATCH 0/2] Update interrupt names
From: Bich HEMON @ 2018-02-28 10:51 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Mark Rutland, Maxime Coquelin,
Alexandre TORGUE, Jiri Slaby, linux-serial@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: Bich HEMON
This patchset updates existing stm32 usart driver by updating interrupt
initialization by name.
Bich Hemon (2):
dt-bindings: serial: stm32: add wakeup option using note
serial: stm32: update interrupt initialization
Documentation/devicetree/bindings/serial/st,stm32-usart.txt | 4 ++++
drivers/tty/serial/stm32-usart.c | 4 ++--
2 files changed, 6 insertions(+), 2 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: [PATCH] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version
From: Hans de Goede @ 2018-02-27 14:07 UTC (permalink / raw)
To: Brian Norris
Cc: Marcel Holtmann, Gustavo F. Padovan, Johan Hedberg,
Bluez mailing list, linux-serial, ACPI Devel Maling List, stable,
Leif Liddy, Matthias Kaehlcke, Daniel Drake, Kai-Heng Feng,
Matadeen Mishra, Linux Kernel Mailing List, Greg Kroah-Hartman,
Guenter Roeck
In-Reply-To: <CA+ASDXOGhi4t2R5qrbXHTFkjtzvUL=qHxkJqku4XKJ6u8Wr+cg@mail.gmail.com>
Hi,
On 27-02-18 03:29, Brian Norris wrote:
> On Thu, Feb 22, 2018 at 11:14 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>> On 23-02-18 04:12, Brian Norris wrote:
>>> Hmm? I'm not sure I completely follow here when you say "he was not
>>> hitting the firmware loading race". If things were functioning fine with
>>> system suspend (but not with autosuspend), then he's not seeing the
>>> controller (quoting commit fd865802c66b) "losing power during suspend".
>>
>>
>> He was running a kernel with the original "fd865802c66b Bluetooth: btusb:
>> fix QCA Rome suspend/resume" commit, which fixes regular suspend for
>> devices which are "losing power during suspend", but does nothing for
>> runtime-suspend.
>>
>> He ran tests both with and without runtime-pm enabled with that same kernel
>> and he needed to disable runtime-pm to get working bluetooth.
>
> Did he ever test with commit fd865802c66b reverted?
>
> My symptoms were exactly the same as you described. BT was broken as
> of v4.14 if I had runtime suspend enabled. Things were fine if I
> either (a) reverted the patch or (b) disabled runtime suspend. I
> obviously preferred (a), which is why I continued to complain :)
>
> Did your tester ever try (a)? If not, then I don't think you've really
> ensured that he really needed a "fixed" version; he may not have
> needed the patch at all.
>
> Or an alternative question: did that system work on an older Fedora
> release (and presumably an older kernel)? If so, then he probably also
> did not need that patch.
>
>>> So, that would suggest he could only be seeing the race (as I was), and
>>> that his machine does not deserve a RESET_RESUME quirk?
>>
>>
>> I hope my above answer helps to clarify why I believe the quirk is
>> necessary on his machine.
>
> I'm sorry, but no it doesn't. If anything, it suggests to me even more
> that it may not have been necessary.
Ok, I've started another test-kernel build for the reporter this time
without any quirks at all and I've asked him to test.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version
From: Brian Norris @ 2018-02-27 2:29 UTC (permalink / raw)
To: Hans de Goede
Cc: Marcel Holtmann, Gustavo F. Padovan, Johan Hedberg,
Bluez mailing list, linux-serial, ACPI Devel Maling List, stable,
Leif Liddy, Matthias Kaehlcke, Daniel Drake, Kai-Heng Feng,
Matadeen Mishra, Linux Kernel Mailing List, Greg Kroah-Hartman,
Guenter Roeck
In-Reply-To: <a6090910-7941-b194-c094-7ce3ef047974@redhat.com>
On Thu, Feb 22, 2018 at 11:14 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> On 23-02-18 04:12, Brian Norris wrote:
>> Hmm? I'm not sure I completely follow here when you say "he was not
>> hitting the firmware loading race". If things were functioning fine with
>> system suspend (but not with autosuspend), then he's not seeing the
>> controller (quoting commit fd865802c66b) "losing power during suspend".
>
>
> He was running a kernel with the original "fd865802c66b Bluetooth: btusb:
> fix QCA Rome suspend/resume" commit, which fixes regular suspend for
> devices which are "losing power during suspend", but does nothing for
> runtime-suspend.
>
> He ran tests both with and without runtime-pm enabled with that same kernel
> and he needed to disable runtime-pm to get working bluetooth.
Did he ever test with commit fd865802c66b reverted?
My symptoms were exactly the same as you described. BT was broken as
of v4.14 if I had runtime suspend enabled. Things were fine if I
either (a) reverted the patch or (b) disabled runtime suspend. I
obviously preferred (a), which is why I continued to complain :)
Did your tester ever try (a)? If not, then I don't think you've really
ensured that he really needed a "fixed" version; he may not have
needed the patch at all.
Or an alternative question: did that system work on an older Fedora
release (and presumably an older kernel)? If so, then he probably also
did not need that patch.
>> So, that would suggest he could only be seeing the race (as I was), and
>> that his machine does not deserve a RESET_RESUME quirk?
>
>
> I hope my above answer helps to clarify why I believe the quirk is
> necessary on his machine.
I'm sorry, but no it doesn't. If anything, it suggests to me even more
that it may not have been necessary.
But hey, I'm not personally going to notice if random Lenovo laptops
are wasting power.
Brian
^ permalink raw reply
* Re: [RFC PATCH 0/2] serial: 8250_dw: IO space + polling mode support
From: John Garry @ 2018-02-26 15:07 UTC (permalink / raw)
To: Andy Shevchenko, gregkh, jslaby, p.zabel, heiko, ed.blake, jhogan
Cc: linux-serial, linux-kernel, linuxarm
In-Reply-To: <1519657365.10722.187.camel@linux.intel.com>
On 26/02/2018 15:02, Andy Shevchenko wrote:
> On Mon, 2018-02-26 at 13:15 +0000, John Garry wrote:
>> On 26/02/2018 12:27, Andy Shevchenko wrote:
>>> On Mon, 2018-02-26 at 14:21 +0200, Andy Shevchenko wrote:
>>>> On Mon, 2018-02-26 at 11:56 +0000, John Garry wrote:
>>>
>>>
>>>>> Device (LPC0.CON0) {
>>>>> Name (_HID, "HISI1031")
>>>>> // Name (_CID, "PNP0501") // cannot support PNP
>>>
>>>
>>> One more question. What is the problem with this CID? Do you have a
>>> race
>>> condition in enumeration?
>>>
>>
>> Hi Andy,
>>
>> Not sure if race condition exactly. I tried enabling this CID and a
>> pnp
>> device is created in pnpacpi_add_device_handler(), while we have
>> already
>> marked the corresponding acpi_device to skip enumeration in ACPI scan
>> handler (by flagging it as a serial bus slave).
>
> Is that code already in upstream?
No, not yet.
>
> If no, please, Cc next version to me and possible Mika.
Of course. I should be sending it later today.
>
All the best,
John
^ permalink raw reply
* Re: [RFC PATCH 0/2] serial: 8250_dw: IO space + polling mode support
From: Andy Shevchenko @ 2018-02-26 15:02 UTC (permalink / raw)
To: John Garry, gregkh, jslaby, p.zabel, heiko, ed.blake, jhogan
Cc: linux-serial, linux-kernel, linuxarm
In-Reply-To: <22270a6a-44fb-d2ad-d6d3-3d301bdde26e@huawei.com>
On Mon, 2018-02-26 at 13:15 +0000, John Garry wrote:
> On 26/02/2018 12:27, Andy Shevchenko wrote:
> > On Mon, 2018-02-26 at 14:21 +0200, Andy Shevchenko wrote:
> > > On Mon, 2018-02-26 at 11:56 +0000, John Garry wrote:
> >
> >
> > > > Device (LPC0.CON0) {
> > > > Name (_HID, "HISI1031")
> > > > // Name (_CID, "PNP0501") // cannot support PNP
> >
> >
> > One more question. What is the problem with this CID? Do you have a
> > race
> > condition in enumeration?
> >
>
> Hi Andy,
>
> Not sure if race condition exactly. I tried enabling this CID and a
> pnp
> device is created in pnpacpi_add_device_handler(), while we have
> already
> marked the corresponding acpi_device to skip enumeration in ACPI scan
> handler (by flagging it as a serial bus slave).
Is that code already in upstream?
If no, please, Cc next version to me and possible Mika.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* Re: [RFC PATCH 0/2] serial: 8250_dw: IO space + polling mode support
From: John Garry @ 2018-02-26 13:15 UTC (permalink / raw)
To: Andy Shevchenko, gregkh, jslaby, p.zabel, heiko, ed.blake, jhogan
Cc: linux-serial, linux-kernel, linuxarm
In-Reply-To: <1519648063.10722.185.camel@linux.intel.com>
On 26/02/2018 12:27, Andy Shevchenko wrote:
> On Mon, 2018-02-26 at 14:21 +0200, Andy Shevchenko wrote:
>> On Mon, 2018-02-26 at 11:56 +0000, John Garry wrote:
>
>
>>> Device (LPC0.CON0) {
>>> Name (_HID, "HISI1031")
>
>>> // Name (_CID, "PNP0501") // cannot support PNP
>
>
> One more question. What is the problem with this CID? Do you have a race
> condition in enumeration?
>
Hi Andy,
Not sure if race condition exactly. I tried enabling this CID and a pnp
device is created in pnpacpi_add_device_handler(), while we have already
marked the corresponding acpi_device to skip enumeration in ACPI scan
handler (by flagging it as a serial bus slave).
Thanks,
John
^ permalink raw reply
* Re: [RFC PATCH 0/2] serial: 8250_dw: IO space + polling mode support
From: John Garry @ 2018-02-26 12:37 UTC (permalink / raw)
To: Andy Shevchenko, gregkh, jslaby, p.zabel, heiko, ed.blake, jhogan
Cc: linux-serial, linux-kernel, linuxarm
In-Reply-To: <1519647669.10722.184.camel@linux.intel.com>
On 26/02/2018 12:21, Andy Shevchenko wrote:
> On Mon, 2018-02-26 at 11:56 +0000, John Garry wrote:
>>>>>>> Why you can't do properly in ACPI?
>>>>>
>>>>> No answer here either.
>>>>>
>>>>> Sorry, but with this level of communication it's no go for the
>>>>> series.
>>>>>
>>>>
>>>> Sorry if my answers did not tell you want you want to know.
>>>>
>>>> My point was that the 8250_pnp driver would be used for a
>>>> pnp_device,
>>>> but we are creating a platform device for this UART slave so would
>>>> require a platform device driver, that which 8250_dw.c is. But I
>>>> will
>>>> check on pnp device support.
>>
>> Hi Andy,
>>
>>> Perhaps it's not visible, though below is a description of the
>>> drivers
>>> we have:
>>>
>>> 8250_dw - OF/ACPI driver for Synopsys DW (+ DW DMA)
>>> 8250_lpss - PCI driver for Synopsys DW (+ DW DMA)
>>> 8250_of - generic 8250 compatible driver for OF
>>> 8250_pci - generic 8250 compatible driver for PCI
>>> 8250_pnp - generic 8250 compatible driver for ACPI
>>>
>>> 8250_* (except core parts) - custom glue drivers per some IPs
>>>
>>> By description you gave your driver fits 8250_pnp if ACPI tables
>>> crafted
>>> properly.
>>>
>>> Share the ACPI excerpt and we can discuss further how to improve
>>> them.
>>>
Hi Andy,
>>
>> For a bit of background, MFD support was discussed here initially:
>> https://lkml.org/lkml/2017/6/13/796
>>
>> Here is the ACPI table:
>> Scope(_SB) {
>> Device (LPC0) {
>> Name (_HID, "HISI0191") // HiSi LPC
>> Name (_CRS, ResourceTemplate () {
>> Memory32Fixed (ReadWrite, 0xa01b0000, 0x1000)
>> })
>> }
>>
>> Device (LPC0.CON0) {
>> Name (_HID, "HISI1031")
>> // Name (_CID, "PNP0501") // cannot support PNP
>> Name (LORS, ResourceTemplate() {
>> QWordIO (
>> ResourceConsumer,
>> MinNotFixed, // _MIF
>> MaxNotFixed, // _MAF
>> PosDecode,
>> EntireRange,
>> 0x0, // _GRA
>> 0x2F8, // _MIN
>
>> 0x3fff, // _MAX
>
> Shouldn't be 0x2ff ?
Yes, something like this. I have asked for it to be fixed.
>
>> 0x0, // _TRA
>> 0x08, // _LEN
>> , ,
>> IO02
>>
>>
>> The latest framework changes and host driver patchset are here:
>> https://lkml.org/lkml/2018/2/19/465
>>
>
> It still doesn't explain impediments you have.
>
> Just few approaches comes to my mind:
> - move UART outside of parent device
In this case the UART would not be a child and would not be enumerated
to have the correct iobase.
> - register PNP driver manually for that cell instead of MFD
Maybe it could work.
> - use serial8250 platform driver (I totally forgot that we have a
> generic platform driver, so, it might be what you need to use at the
> end)
Let me check this also. I am not fimilar.
>
Thanks for the support!
John
^ permalink raw reply
* Re: [RFC PATCH 0/2] serial: 8250_dw: IO space + polling mode support
From: Andy Shevchenko @ 2018-02-26 12:27 UTC (permalink / raw)
To: John Garry, gregkh, jslaby, p.zabel, heiko, ed.blake, jhogan
Cc: linux-serial, linux-kernel, linuxarm
In-Reply-To: <1519647669.10722.184.camel@linux.intel.com>
On Mon, 2018-02-26 at 14:21 +0200, Andy Shevchenko wrote:
> On Mon, 2018-02-26 at 11:56 +0000, John Garry wrote:
> > Device (LPC0.CON0) {
> > Name (_HID, "HISI1031")
> > // Name (_CID, "PNP0501") // cannot support PNP
One more question. What is the problem with this CID? Do you have a race
condition in enumeration?
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* Re: [RFC PATCH 0/2] serial: 8250_dw: IO space + polling mode support
From: Andy Shevchenko @ 2018-02-26 12:21 UTC (permalink / raw)
To: John Garry, gregkh, jslaby, p.zabel, heiko, ed.blake, jhogan
Cc: linux-serial, linux-kernel, linuxarm
In-Reply-To: <b5904a5a-66d8-4385-cc5b-a52529e9d28f@huawei.com>
On Mon, 2018-02-26 at 11:56 +0000, John Garry wrote:
> > > > > > Why you can't do properly in ACPI?
> > > >
> > > > No answer here either.
> > > >
> > > > Sorry, but with this level of communication it's no go for the
> > > > series.
> > > >
> > >
> > > Sorry if my answers did not tell you want you want to know.
> > >
> > > My point was that the 8250_pnp driver would be used for a
> > > pnp_device,
> > > but we are creating a platform device for this UART slave so would
> > > require a platform device driver, that which 8250_dw.c is. But I
> > > will
> > > check on pnp device support.
>
> Hi Andy,
>
> > Perhaps it's not visible, though below is a description of the
> > drivers
> > we have:
> >
> > 8250_dw - OF/ACPI driver for Synopsys DW (+ DW DMA)
> > 8250_lpss - PCI driver for Synopsys DW (+ DW DMA)
> > 8250_of - generic 8250 compatible driver for OF
> > 8250_pci - generic 8250 compatible driver for PCI
> > 8250_pnp - generic 8250 compatible driver for ACPI
> >
> > 8250_* (except core parts) - custom glue drivers per some IPs
> >
> > By description you gave your driver fits 8250_pnp if ACPI tables
> > crafted
> > properly.
> >
> > Share the ACPI excerpt and we can discuss further how to improve
> > them.
> >
>
> For a bit of background, MFD support was discussed here initially:
> https://lkml.org/lkml/2017/6/13/796
>
> Here is the ACPI table:
> Scope(_SB) {
> Device (LPC0) {
> Name (_HID, "HISI0191") // HiSi LPC
> Name (_CRS, ResourceTemplate () {
> Memory32Fixed (ReadWrite, 0xa01b0000, 0x1000)
> })
> }
>
> Device (LPC0.CON0) {
> Name (_HID, "HISI1031")
> // Name (_CID, "PNP0501") // cannot support PNP
> Name (LORS, ResourceTemplate() {
> QWordIO (
> ResourceConsumer,
> MinNotFixed, // _MIF
> MaxNotFixed, // _MAF
> PosDecode,
> EntireRange,
> 0x0, // _GRA
> 0x2F8, // _MIN
> 0x3fff, // _MAX
Shouldn't be 0x2ff ?
> 0x0, // _TRA
> 0x08, // _LEN
> , ,
> IO02
>
>
> The latest framework changes and host driver patchset are here:
> https://lkml.org/lkml/2018/2/19/465
>
It still doesn't explain impediments you have.
Just few approaches comes to my mind:
- move UART outside of parent device
- register PNP driver manually for that cell instead of MFD
- use serial8250 platform driver (I totally forgot that we have a
generic platform driver, so, it might be what you need to use at the
end)
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ 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