linux-stable/drivers/tty/serial/max310x.c

1737 lines
48 KiB
C
Raw Normal View History

tty: add SPDX identifiers to all remaining files in drivers/tty/ It's good to have SPDX identifiers in all files to make it easier to audit the kernel tree for correct licenses. Update the drivers/tty files files with the correct SPDX license identifier based on the license text in the file itself. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This work is based on a script and data from Thomas Gleixner, Philippe Ombredanne, and Kate Stewart. Cc: Jiri Slaby <jslaby@suse.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Chris Metcalf <cmetcalf@mellanox.com> Cc: Jiri Kosina <jikos@kernel.org> Cc: David Sterba <dsterba@suse.com> Cc: James Hogan <jhogan@kernel.org> Cc: Rob Herring <robh@kernel.org> Cc: Eric Anholt <eric@anholt.net> Cc: Stefan Wahren <stefan.wahren@i2se.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Ray Jui <rjui@broadcom.com> Cc: Scott Branden <sbranden@broadcom.com> Cc: bcm-kernel-feedback-list@broadcom.com Cc: "James E.J. Bottomley" <jejb@parisc-linux.org> Cc: Helge Deller <deller@gmx.de> Cc: Joachim Eastwood <manabian@gmail.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Tobias Klauser <tklauser@distanz.ch> Cc: Russell King <linux@armlinux.org.uk> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Richard Genoud <richard.genoud@gmail.com> Cc: Alexander Shiyan <shc_work@mail.ru> Cc: Baruch Siach <baruch@tkos.co.il> Cc: "Maciej W. Rozycki" <macro@linux-mips.org> Cc: "Uwe Kleine-König" <kernel@pengutronix.de> Cc: Pat Gefre <pfg@sgi.com> Cc: "Guilherme G. Piccoli" <gpiccoli@linux.vnet.ibm.com> Cc: Jason Wessel <jason.wessel@windriver.com> Cc: Vladimir Zapolskiy <vz@mleia.com> Cc: Sylvain Lemieux <slemieux.tyco@gmail.com> Cc: Carlo Caione <carlo@caione.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Andy Gross <andy.gross@linaro.org> Cc: David Brown <david.brown@linaro.org> Cc: "Andreas Färber" <afaerber@suse.de> Cc: Kevin Cernekee <cernekee@gmail.com> Cc: Laxman Dewangan <ldewangan@nvidia.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: Barry Song <baohua@kernel.org> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Peter Korsgaard <jacmet@sunsite.dk> Cc: Timur Tabi <timur@tabi.org> Cc: Tony Prisk <linux@prisktech.co.nz> Cc: Michal Simek <michal.simek@xilinx.com> Cc: "Sören Brinkmann" <soren.brinkmann@xilinx.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Kate Stewart <kstewart@linuxfoundation.org> Cc: Philippe Ombredanne <pombredanne@nexb.com> Cc: Jiri Slaby <jslaby@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-06 17:11:51 +00:00
// SPDX-License-Identifier: GPL-2.0+
/*
* Maxim (Dallas) MAX3107/8/9, MAX14830 serial driver
*
* Copyright (C) 2012-2016 Alexander Shiyan <shc_work@mail.ru>
*
* Based on max3100.c, by Christian Pellegrin <chripell@evolware.org>
* Based on max3110.c, by Feng Tang <feng.tang@intel.com>
* Based on max3107.c, by Aavamobile
*/
#include <linux/bitops.h>
#include <linux/clk.h>
#include <linux/delay.h>
#include <linux/device.h>
#include <linux/gpio/driver.h>
#include <linux/i2c.h>
#include <linux/module.h>
#include <linux/mod_devicetable.h>
#include <linux/property.h>
#include <linux/regmap.h>
#include <linux/serial_core.h>
#include <linux/serial.h>
#include <linux/tty.h>
#include <linux/tty_flip.h>
#include <linux/spi/spi.h>
#include <linux/uaccess.h>
#define MAX310X_NAME "max310x"
#define MAX310X_MAJOR 204
#define MAX310X_MINOR 209
#define MAX310X_UART_NRMAX 16
#define MAX310X_MAX_PORTS 4 /* Maximum number of UART ports per IC. */
/* MAX310X register definitions */
#define MAX310X_RHR_REG (0x00) /* RX FIFO */
#define MAX310X_THR_REG (0x00) /* TX FIFO */
#define MAX310X_IRQEN_REG (0x01) /* IRQ enable */
#define MAX310X_IRQSTS_REG (0x02) /* IRQ status */
#define MAX310X_LSR_IRQEN_REG (0x03) /* LSR IRQ enable */
#define MAX310X_LSR_IRQSTS_REG (0x04) /* LSR IRQ status */
#define MAX310X_REG_05 (0x05)
#define MAX310X_SPCHR_IRQEN_REG MAX310X_REG_05 /* Special char IRQ en */
#define MAX310X_SPCHR_IRQSTS_REG (0x06) /* Special char IRQ status */
#define MAX310X_STS_IRQEN_REG (0x07) /* Status IRQ enable */
#define MAX310X_STS_IRQSTS_REG (0x08) /* Status IRQ status */
#define MAX310X_MODE1_REG (0x09) /* MODE1 */
#define MAX310X_MODE2_REG (0x0a) /* MODE2 */
#define MAX310X_LCR_REG (0x0b) /* LCR */
#define MAX310X_RXTO_REG (0x0c) /* RX timeout */
#define MAX310X_HDPIXDELAY_REG (0x0d) /* Auto transceiver delays */
#define MAX310X_IRDA_REG (0x0e) /* IRDA settings */
#define MAX310X_FLOWLVL_REG (0x0f) /* Flow control levels */
#define MAX310X_FIFOTRIGLVL_REG (0x10) /* FIFO IRQ trigger levels */
#define MAX310X_TXFIFOLVL_REG (0x11) /* TX FIFO level */
#define MAX310X_RXFIFOLVL_REG (0x12) /* RX FIFO level */
#define MAX310X_FLOWCTRL_REG (0x13) /* Flow control */
#define MAX310X_XON1_REG (0x14) /* XON1 character */
#define MAX310X_XON2_REG (0x15) /* XON2 character */
#define MAX310X_XOFF1_REG (0x16) /* XOFF1 character */
#define MAX310X_XOFF2_REG (0x17) /* XOFF2 character */
#define MAX310X_GPIOCFG_REG (0x18) /* GPIO config */
#define MAX310X_GPIODATA_REG (0x19) /* GPIO data */
#define MAX310X_PLLCFG_REG (0x1a) /* PLL config */
#define MAX310X_BRGCFG_REG (0x1b) /* Baud rate generator conf */
#define MAX310X_BRGDIVLSB_REG (0x1c) /* Baud rate divisor LSB */
#define MAX310X_BRGDIVMSB_REG (0x1d) /* Baud rate divisor MSB */
#define MAX310X_CLKSRC_REG (0x1e) /* Clock source */
#define MAX310X_REG_1F (0x1f)
#define MAX310X_EXTREG_START (0x20) /* Only relevant in SPI mode. */
#define MAX310X_REVID_REG MAX310X_REG_1F /* Revision ID */
#define MAX310X_GLOBALIRQ_REG MAX310X_REG_1F /* Global IRQ (RO) */
#define MAX310X_GLOBALCMD_REG MAX310X_REG_1F /* Global Command (WO) */
/* Extended registers */
#define MAX310X_REVID_EXTREG (0x25) /* Revision ID
* (extended addressing space)
*/
/* IRQ register bits */
#define MAX310X_IRQ_LSR_BIT (1 << 0) /* LSR interrupt */
#define MAX310X_IRQ_SPCHR_BIT (1 << 1) /* Special char interrupt */
#define MAX310X_IRQ_STS_BIT (1 << 2) /* Status interrupt */
#define MAX310X_IRQ_RXFIFO_BIT (1 << 3) /* RX FIFO interrupt */
#define MAX310X_IRQ_TXFIFO_BIT (1 << 4) /* TX FIFO interrupt */
#define MAX310X_IRQ_TXEMPTY_BIT (1 << 5) /* TX FIFO empty interrupt */
#define MAX310X_IRQ_RXEMPTY_BIT (1 << 6) /* RX FIFO empty interrupt */
#define MAX310X_IRQ_CTS_BIT (1 << 7) /* CTS interrupt */
/* LSR register bits */
#define MAX310X_LSR_RXTO_BIT (1 << 0) /* RX timeout */
#define MAX310X_LSR_RXOVR_BIT (1 << 1) /* RX overrun */
#define MAX310X_LSR_RXPAR_BIT (1 << 2) /* RX parity error */
#define MAX310X_LSR_FRERR_BIT (1 << 3) /* Frame error */
#define MAX310X_LSR_RXBRK_BIT (1 << 4) /* RX break */
#define MAX310X_LSR_RXNOISE_BIT (1 << 5) /* RX noise */
#define MAX310X_LSR_CTS_BIT (1 << 7) /* CTS pin state */
/* Special character register bits */
#define MAX310X_SPCHR_XON1_BIT (1 << 0) /* XON1 character */
#define MAX310X_SPCHR_XON2_BIT (1 << 1) /* XON2 character */
#define MAX310X_SPCHR_XOFF1_BIT (1 << 2) /* XOFF1 character */
#define MAX310X_SPCHR_XOFF2_BIT (1 << 3) /* XOFF2 character */
#define MAX310X_SPCHR_BREAK_BIT (1 << 4) /* RX break */
#define MAX310X_SPCHR_MULTIDROP_BIT (1 << 5) /* 9-bit multidrop addr char */
/* Status register bits */
#define MAX310X_STS_GPIO0_BIT (1 << 0) /* GPIO 0 interrupt */
#define MAX310X_STS_GPIO1_BIT (1 << 1) /* GPIO 1 interrupt */
#define MAX310X_STS_GPIO2_BIT (1 << 2) /* GPIO 2 interrupt */
#define MAX310X_STS_GPIO3_BIT (1 << 3) /* GPIO 3 interrupt */
#define MAX310X_STS_CLKREADY_BIT (1 << 5) /* Clock ready */
#define MAX310X_STS_SLEEP_BIT (1 << 6) /* Sleep interrupt */
/* MODE1 register bits */
#define MAX310X_MODE1_RXDIS_BIT (1 << 0) /* RX disable */
#define MAX310X_MODE1_TXDIS_BIT (1 << 1) /* TX disable */
#define MAX310X_MODE1_TXHIZ_BIT (1 << 2) /* TX pin three-state */
#define MAX310X_MODE1_RTSHIZ_BIT (1 << 3) /* RTS pin three-state */
#define MAX310X_MODE1_TRNSCVCTRL_BIT (1 << 4) /* Transceiver ctrl enable */
#define MAX310X_MODE1_FORCESLEEP_BIT (1 << 5) /* Force sleep mode */
#define MAX310X_MODE1_AUTOSLEEP_BIT (1 << 6) /* Auto sleep enable */
#define MAX310X_MODE1_IRQSEL_BIT (1 << 7) /* IRQ pin enable */
/* MODE2 register bits */
#define MAX310X_MODE2_RST_BIT (1 << 0) /* Chip reset */
#define MAX310X_MODE2_FIFORST_BIT (1 << 1) /* FIFO reset */
#define MAX310X_MODE2_RXTRIGINV_BIT (1 << 2) /* RX FIFO INT invert */
#define MAX310X_MODE2_RXEMPTINV_BIT (1 << 3) /* RX FIFO empty INT invert */
#define MAX310X_MODE2_SPCHR_BIT (1 << 4) /* Special chr detect enable */
#define MAX310X_MODE2_LOOPBACK_BIT (1 << 5) /* Internal loopback enable */
#define MAX310X_MODE2_MULTIDROP_BIT (1 << 6) /* 9-bit multidrop enable */
#define MAX310X_MODE2_ECHOSUPR_BIT (1 << 7) /* ECHO suppression enable */
/* LCR register bits */
#define MAX310X_LCR_LENGTH0_BIT (1 << 0) /* Word length bit 0 */
#define MAX310X_LCR_LENGTH1_BIT (1 << 1) /* Word length bit 1
*
* Word length bits table:
* 00 -> 5 bit words
* 01 -> 6 bit words
* 10 -> 7 bit words
* 11 -> 8 bit words
*/
#define MAX310X_LCR_STOPLEN_BIT (1 << 2) /* STOP length bit
*
* STOP length bit table:
* 0 -> 1 stop bit
* 1 -> 1-1.5 stop bits if
* word length is 5,
* 2 stop bits otherwise
*/
#define MAX310X_LCR_PARITY_BIT (1 << 3) /* Parity bit enable */
#define MAX310X_LCR_EVENPARITY_BIT (1 << 4) /* Even parity bit enable */
#define MAX310X_LCR_FORCEPARITY_BIT (1 << 5) /* 9-bit multidrop parity */
#define MAX310X_LCR_TXBREAK_BIT (1 << 6) /* TX break enable */
#define MAX310X_LCR_RTS_BIT (1 << 7) /* RTS pin control */
/* IRDA register bits */
#define MAX310X_IRDA_IRDAEN_BIT (1 << 0) /* IRDA mode enable */
#define MAX310X_IRDA_SIR_BIT (1 << 1) /* SIR mode enable */
/* Flow control trigger level register masks */
#define MAX310X_FLOWLVL_HALT_MASK GENMASK(3, 0) /* Flow control halt level */
#define MAX310X_FLOWLVL_RES_MASK GENMASK(7, 4) /* Flow control resume level */
#define MAX310X_FLOWLVL_HALT(words) ((words / 8) & 0x0f)
#define MAX310X_FLOWLVL_RES(words) (((words / 8) & 0x0f) << 4)
/* FIFO interrupt trigger level register masks */
#define MAX310X_FIFOTRIGLVL_TX_MASK GENMASK(3, 0) /* TX FIFO trigger level */
#define MAX310X_FIFOTRIGLVL_RX_MASK GENMASK(7, 4) /* RX FIFO trigger level */
#define MAX310X_FIFOTRIGLVL_TX(words) ((words / 8) & 0x0f)
#define MAX310X_FIFOTRIGLVL_RX(words) (((words / 8) & 0x0f) << 4)
/* Flow control register bits */
#define MAX310X_FLOWCTRL_AUTORTS_BIT (1 << 0) /* Auto RTS flow ctrl enable */
#define MAX310X_FLOWCTRL_AUTOCTS_BIT (1 << 1) /* Auto CTS flow ctrl enable */
#define MAX310X_FLOWCTRL_GPIADDR_BIT (1 << 2) /* Enables that GPIO inputs
* are used in conjunction with
* XOFF2 for definition of
* special character
*/
#define MAX310X_FLOWCTRL_SWFLOWEN_BIT (1 << 3) /* Auto SW flow ctrl enable */
#define MAX310X_FLOWCTRL_SWFLOW0_BIT (1 << 4) /* SWFLOW bit 0 */
#define MAX310X_FLOWCTRL_SWFLOW1_BIT (1 << 5) /* SWFLOW bit 1
*
* SWFLOW bits 1 & 0 table:
* 00 -> no transmitter flow
* control
* 01 -> receiver compares
* XON2 and XOFF2
* and controls
* transmitter
* 10 -> receiver compares
* XON1 and XOFF1
* and controls
* transmitter
* 11 -> receiver compares
* XON1, XON2, XOFF1 and
* XOFF2 and controls
* transmitter
*/
#define MAX310X_FLOWCTRL_SWFLOW2_BIT (1 << 6) /* SWFLOW bit 2 */
#define MAX310X_FLOWCTRL_SWFLOW3_BIT (1 << 7) /* SWFLOW bit 3
*
* SWFLOW bits 3 & 2 table:
* 00 -> no received flow
* control
* 01 -> transmitter generates
* XON2 and XOFF2
* 10 -> transmitter generates
* XON1 and XOFF1
* 11 -> transmitter generates
* XON1, XON2, XOFF1 and
* XOFF2
*/
/* PLL configuration register masks */
#define MAX310X_PLLCFG_PREDIV_MASK GENMASK(5, 0) /* PLL predivision value */
#define MAX310X_PLLCFG_PLLFACTOR_MASK GENMASK(7, 6) /* PLL multiplication factor */
/* Baud rate generator configuration register bits */
#define MAX310X_BRGCFG_2XMODE_BIT (1 << 4) /* Double baud rate */
#define MAX310X_BRGCFG_4XMODE_BIT (1 << 5) /* Quadruple baud rate */
/* Clock source register bits */
#define MAX310X_CLKSRC_CRYST_BIT (1 << 1) /* Crystal osc enable */
#define MAX310X_CLKSRC_PLL_BIT (1 << 2) /* PLL enable */
#define MAX310X_CLKSRC_PLLBYP_BIT (1 << 3) /* PLL bypass */
#define MAX310X_CLKSRC_EXTCLK_BIT (1 << 4) /* External clock enable */
#define MAX310X_CLKSRC_CLK2RTS_BIT (1 << 7) /* Baud clk to RTS pin */
/* Global commands */
#define MAX310X_EXTREG_ENBL (0xce)
#define MAX310X_EXTREG_DSBL (0xcd)
/* Misc definitions */
#define MAX310X_FIFO_SIZE (128)
#define MAX310x_REV_MASK GENMASK(7, 3)
#define MAX310X_WRITE_BIT 0x80
/* Port startup definitions */
#define MAX310X_PORT_STARTUP_WAIT_RETRIES 20 /* Number of retries */
#define MAX310X_PORT_STARTUP_WAIT_DELAY_MS 10 /* Delay between retries */
/* Crystal-related definitions */
#define MAX310X_XTAL_WAIT_RETRIES 20 /* Number of retries */
#define MAX310X_XTAL_WAIT_DELAY_MS 10 /* Delay between retries */
/* MAX3107 specific */
#define MAX3107_REV_ID (0xa0)
/* MAX3109 specific */
#define MAX3109_REV_ID (0xc0)
/* MAX14830 specific */
#define MAX14830_BRGCFG_CLKDIS_BIT (1 << 6) /* Clock Disable */
#define MAX14830_REV_ID (0xb0)
struct max310x_if_cfg {
int (*extended_reg_enable)(struct device *dev, bool enable);
u8 rev_id_offset;
};
struct max310x_devtype {
struct {
unsigned short min;
unsigned short max;
} slave_addr; /* Relevant only in I2C mode. */
int nr;
char name[9];
u8 mode1;
u8 rev_id_val;
u8 rev_id_reg; /* Relevant only if rev_id_val is defined. */
u8 power_reg; /* Register address for power/sleep control. */
u8 power_bit; /* Bit for sleep or power-off mode (active high). */
};
struct max310x_one {
struct uart_port port;
struct work_struct tx_work;
struct work_struct md_work;
struct work_struct rs_work;
struct regmap *regmap;
u8 rx_buf[MAX310X_FIFO_SIZE];
};
#define to_max310x_port(_port) \
container_of(_port, struct max310x_one, port)
struct max310x_port {
const struct max310x_devtype *devtype;
const struct max310x_if_cfg *if_cfg;
struct regmap *regmap;
struct clk *clk;
#ifdef CONFIG_GPIOLIB
struct gpio_chip gpio;
#endif
struct max310x_one p[];
};
static struct uart_driver max310x_uart = {
.owner = THIS_MODULE,
.driver_name = MAX310X_NAME,
.dev_name = "ttyMAX",
.major = MAX310X_MAJOR,
.minor = MAX310X_MINOR,
.nr = MAX310X_UART_NRMAX,
};
static DECLARE_BITMAP(max310x_lines, MAX310X_UART_NRMAX);
static u8 max310x_port_read(struct uart_port *port, u8 reg)
{
struct max310x_one *one = to_max310x_port(port);
unsigned int val = 0;
regmap_read(one->regmap, reg, &val);
return val;
}
static void max310x_port_write(struct uart_port *port, u8 reg, u8 val)
{
struct max310x_one *one = to_max310x_port(port);
regmap_write(one->regmap, reg, val);
}
static void max310x_port_update(struct uart_port *port, u8 reg, u8 mask, u8 val)
{
struct max310x_one *one = to_max310x_port(port);
regmap_update_bits(one->regmap, reg, mask, val);
}
static int max310x_detect(struct device *dev)
{
struct max310x_port *s = dev_get_drvdata(dev);
unsigned int val = 0;
int ret;
/* Check if variant supports REV ID register: */
if (s->devtype->rev_id_val) {
u8 rev_id_reg = s->devtype->rev_id_reg;
/* Check if REV ID is in extended addressing space: */
if (s->devtype->rev_id_reg >= MAX310X_EXTREG_START) {
ret = s->if_cfg->extended_reg_enable(dev, true);
if (ret)
return ret;
/* Adjust REV ID extended addressing space address: */
if (s->if_cfg->rev_id_offset)
rev_id_reg -= s->if_cfg->rev_id_offset;
}
regmap_read(s->regmap, rev_id_reg, &val);
if (s->devtype->rev_id_reg >= MAX310X_EXTREG_START) {
ret = s->if_cfg->extended_reg_enable(dev, false);
if (ret)
return ret;
}
if (((val & MAX310x_REV_MASK) != s->devtype->rev_id_val))
return dev_err_probe(dev, -ENODEV,
"%s ID 0x%02x does not match\n",
s->devtype->name, val);
} else {
/*
* For variant without REV ID register, just check default value
* from clocksource register to make sure everything works.
*/
ret = regmap_read(s->regmap, MAX310X_CLKSRC_REG, &val);
if (ret)
return ret;
if (val != (MAX310X_CLKSRC_EXTCLK_BIT | MAX310X_CLKSRC_PLLBYP_BIT))
return dev_err_probe(dev, -ENODEV,
"%s not present\n",
s->devtype->name);
}
return 0;
}
static void max310x_power(struct uart_port *port, int on)
{
struct max310x_port *s = dev_get_drvdata(port->dev);
max310x_port_update(port, s->devtype->power_reg, s->devtype->power_bit,
on ? 0 : s->devtype->power_bit);
if (on)
msleep(50);
}
static const struct max310x_devtype max3107_devtype = {
.name = "MAX3107",
.nr = 1,
.mode1 = MAX310X_MODE1_AUTOSLEEP_BIT | MAX310X_MODE1_IRQSEL_BIT,
.rev_id_val = MAX3107_REV_ID,
.rev_id_reg = MAX310X_REVID_REG,
.power_reg = MAX310X_MODE1_REG,
.power_bit = MAX310X_MODE1_FORCESLEEP_BIT,
.slave_addr = {
.min = 0x2c,
.max = 0x2f,
},
};
static const struct max310x_devtype max3108_devtype = {
.name = "MAX3108",
.nr = 1,
.mode1 = MAX310X_MODE1_AUTOSLEEP_BIT,
.rev_id_val = 0, /* Unsupported. */
.rev_id_reg = 0, /* Irrelevant when rev_id_val is not defined. */
.power_reg = MAX310X_MODE1_REG,
.power_bit = MAX310X_MODE1_FORCESLEEP_BIT,
.slave_addr = {
.min = 0x60,
.max = 0x6f,
},
};
static const struct max310x_devtype max3109_devtype = {
.name = "MAX3109",
.nr = 2,
.mode1 = MAX310X_MODE1_AUTOSLEEP_BIT,
.rev_id_val = MAX3109_REV_ID,
.rev_id_reg = MAX310X_REVID_EXTREG,
.power_reg = MAX310X_MODE1_REG,
.power_bit = MAX310X_MODE1_FORCESLEEP_BIT,
.slave_addr = {
.min = 0x60,
.max = 0x6f,
},
};
static const struct max310x_devtype max14830_devtype = {
.name = "MAX14830",
.nr = 4,
.mode1 = MAX310X_MODE1_IRQSEL_BIT,
.rev_id_val = MAX14830_REV_ID,
.rev_id_reg = MAX310X_REVID_EXTREG,
.power_reg = MAX310X_BRGCFG_REG,
.power_bit = MAX14830_BRGCFG_CLKDIS_BIT,
.slave_addr = {
.min = 0x60,
.max = 0x6f,
},
};
static bool max310x_reg_writeable(struct device *dev, unsigned int reg)
{
switch (reg) {
case MAX310X_IRQSTS_REG:
case MAX310X_LSR_IRQSTS_REG:
case MAX310X_SPCHR_IRQSTS_REG:
case MAX310X_STS_IRQSTS_REG:
case MAX310X_TXFIFOLVL_REG:
case MAX310X_RXFIFOLVL_REG:
return false;
default:
return true;
}
}
static bool max310x_reg_volatile(struct device *dev, unsigned int reg)
{
switch (reg) {
case MAX310X_RHR_REG:
case MAX310X_IRQSTS_REG:
case MAX310X_LSR_IRQSTS_REG:
case MAX310X_SPCHR_IRQSTS_REG:
case MAX310X_STS_IRQSTS_REG:
case MAX310X_TXFIFOLVL_REG:
case MAX310X_RXFIFOLVL_REG:
case MAX310X_GPIODATA_REG:
case MAX310X_BRGDIVLSB_REG:
case MAX310X_REG_05:
case MAX310X_REG_1F:
return true;
default:
return false;
}
}
static bool max310x_reg_precious(struct device *dev, unsigned int reg)
{
switch (reg) {
case MAX310X_RHR_REG:
case MAX310X_IRQSTS_REG:
case MAX310X_SPCHR_IRQSTS_REG:
case MAX310X_STS_IRQSTS_REG:
return true;
default:
return false;
}
}
static bool max310x_reg_noinc(struct device *dev, unsigned int reg)
{
return reg == MAX310X_RHR_REG;
}
static int max310x_set_baud(struct uart_port *port, int baud)
{
unsigned int mode = 0, div = 0, frac = 0, c = 0, F = 0;
/*
* Calculate the integer divisor first. Select a proper mode
* in case if the requested baud is too high for the pre-defined
* clocks frequency.
*/
div = port->uartclk / baud;
if (div < 8) {
/* Mode x4 */
c = 4;
mode = MAX310X_BRGCFG_4XMODE_BIT;
} else if (div < 16) {
/* Mode x2 */
c = 8;
mode = MAX310X_BRGCFG_2XMODE_BIT;
} else {
c = 16;
}
/* Calculate the divisor in accordance with the fraction coefficient */
div /= c;
F = c*baud;
/* Calculate the baud rate fraction */
if (div > 0)
frac = (16*(port->uartclk % F)) / F;
else
div = 1;
max310x_port_write(port, MAX310X_BRGDIVMSB_REG, div >> 8);
max310x_port_write(port, MAX310X_BRGDIVLSB_REG, div);
max310x_port_write(port, MAX310X_BRGCFG_REG, frac | mode);
/* Return the actual baud rate we just programmed */
return (16*port->uartclk) / (c*(16*div + frac));
}
static int max310x_update_best_err(unsigned long f, long *besterr)
{
/* Use baudrate 115200 for calculate error */
long err = f % (460800 * 16);
if ((*besterr < 0) || (*besterr > err)) {
*besterr = err;
return 0;
}
return 1;
}
static s32 max310x_set_ref_clk(struct device *dev, struct max310x_port *s,
unsigned long freq, bool xtal)
{
unsigned int div, clksrc, pllcfg = 0;
long besterr = -1;
unsigned long fdiv, fmul, bestfreq = freq;
/* First, update error without PLL */
max310x_update_best_err(freq, &besterr);
/* Try all possible PLL dividers */
for (div = 1; (div <= 63) && besterr; div++) {
fdiv = DIV_ROUND_CLOSEST(freq, div);
/* Try multiplier 6 */
fmul = fdiv * 6;
if ((fdiv >= 500000) && (fdiv <= 800000))
if (!max310x_update_best_err(fmul, &besterr)) {
pllcfg = (0 << 6) | div;
bestfreq = fmul;
}
/* Try multiplier 48 */
fmul = fdiv * 48;
if ((fdiv >= 850000) && (fdiv <= 1200000))
if (!max310x_update_best_err(fmul, &besterr)) {
pllcfg = (1 << 6) | div;
bestfreq = fmul;
}
/* Try multiplier 96 */
fmul = fdiv * 96;
if ((fdiv >= 425000) && (fdiv <= 1000000))
if (!max310x_update_best_err(fmul, &besterr)) {
pllcfg = (2 << 6) | div;
bestfreq = fmul;
}
/* Try multiplier 144 */
fmul = fdiv * 144;
if ((fdiv >= 390000) && (fdiv <= 667000))
if (!max310x_update_best_err(fmul, &besterr)) {
pllcfg = (3 << 6) | div;
bestfreq = fmul;
}
}
/* Configure clock source */
clksrc = MAX310X_CLKSRC_EXTCLK_BIT | (xtal ? MAX310X_CLKSRC_CRYST_BIT : 0);
/* Configure PLL */
if (pllcfg) {
clksrc |= MAX310X_CLKSRC_PLL_BIT;
regmap_write(s->regmap, MAX310X_PLLCFG_REG, pllcfg);
} else
clksrc |= MAX310X_CLKSRC_PLLBYP_BIT;
regmap_write(s->regmap, MAX310X_CLKSRC_REG, clksrc);
/* Wait for crystal */
if (xtal) {
bool stable = false;
unsigned int try = 0, val = 0;
do {
msleep(MAX310X_XTAL_WAIT_DELAY_MS);
regmap_read(s->regmap, MAX310X_STS_IRQSTS_REG, &val);
if (val & MAX310X_STS_CLKREADY_BIT)
stable = true;
} while (!stable && (++try < MAX310X_XTAL_WAIT_RETRIES));
if (!stable)
return dev_err_probe(dev, -EAGAIN,
"clock is not stable\n");
}
return bestfreq;
}
static void max310x_batch_write(struct uart_port *port, u8 *txbuf, unsigned int len)
{
struct max310x_one *one = to_max310x_port(port);
regmap_noinc_write(one->regmap, MAX310X_THR_REG, txbuf, len);
}
serial: max310x: Use batched reads when reasonably safe The hardware has a 128 byte RX FIFO buffer for each independent UART. Previously, the code was always reading that byte-by-byte via independent SPI transactions and the associated overhead. In practice, this led to up to eight bytes over SPI for just one byte in the UART's RX FIFO: - reading the global IRQ register (two bytes, one for command, the other for data) - reading one UART's ISR (again two bytes) - reading the byte count (two bytes yet again) - finally, reading one byte of the FIFO via another two-byte transaction We cannot always use a batched read. If the TTY is set to intercept break conditions or report framing or parity errors, then it is required to check the Line Status Register (LSR) for each byte which is read from the RX FIFO. The documentation does not show a way of doing that in a single SPI transaction; registers 0x00 and 0x04 are separate. In my testing, this is no silver bullet. I was feeding 2MB of random data over four daisy-chaned UARTs of MAX14830, and this is the distribution that I was getting: - R <= 1: 7437322 - R <= 2: 162093 - R <= 4: 4093 - R <= 8: 4196 - R <= 16: 645 - R <= 32: 165 - R <= 64: 58 - R <= 128: 0 For a reference, batching the write operations works much better: - W <= 1: 2664 - W <= 2: 1305 - W <= 4: 627 - W <= 8: 371 - W <= 16: 121 - W <= 32: 68 - W <= 64: 33 - W <= 128: 63139 That's probably because this HW/SW combination (Clearfog Base, Armada 388) is probably "good enough" to react to the chip's IRQ "fast enough" most of the time. Still, I was getting RX overruns every now and then. In future, I plan to improve this by letting the RX FIFO be filled a little more (the chip has support for that and also for a "stale timeout" to prevent additional starvation). Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-14 15:02:54 +00:00
static void max310x_batch_read(struct uart_port *port, u8 *rxbuf, unsigned int len)
{
struct max310x_one *one = to_max310x_port(port);
regmap_noinc_read(one->regmap, MAX310X_RHR_REG, rxbuf, len);
serial: max310x: Use batched reads when reasonably safe The hardware has a 128 byte RX FIFO buffer for each independent UART. Previously, the code was always reading that byte-by-byte via independent SPI transactions and the associated overhead. In practice, this led to up to eight bytes over SPI for just one byte in the UART's RX FIFO: - reading the global IRQ register (two bytes, one for command, the other for data) - reading one UART's ISR (again two bytes) - reading the byte count (two bytes yet again) - finally, reading one byte of the FIFO via another two-byte transaction We cannot always use a batched read. If the TTY is set to intercept break conditions or report framing or parity errors, then it is required to check the Line Status Register (LSR) for each byte which is read from the RX FIFO. The documentation does not show a way of doing that in a single SPI transaction; registers 0x00 and 0x04 are separate. In my testing, this is no silver bullet. I was feeding 2MB of random data over four daisy-chaned UARTs of MAX14830, and this is the distribution that I was getting: - R <= 1: 7437322 - R <= 2: 162093 - R <= 4: 4093 - R <= 8: 4196 - R <= 16: 645 - R <= 32: 165 - R <= 64: 58 - R <= 128: 0 For a reference, batching the write operations works much better: - W <= 1: 2664 - W <= 2: 1305 - W <= 4: 627 - W <= 8: 371 - W <= 16: 121 - W <= 32: 68 - W <= 64: 33 - W <= 128: 63139 That's probably because this HW/SW combination (Clearfog Base, Armada 388) is probably "good enough" to react to the chip's IRQ "fast enough" most of the time. Still, I was getting RX overruns every now and then. In future, I plan to improve this by letting the RX FIFO be filled a little more (the chip has support for that and also for a "stale timeout" to prevent additional starvation). Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-14 15:02:54 +00:00
}
serial: max310x: Use batched reads when reasonably safe The hardware has a 128 byte RX FIFO buffer for each independent UART. Previously, the code was always reading that byte-by-byte via independent SPI transactions and the associated overhead. In practice, this led to up to eight bytes over SPI for just one byte in the UART's RX FIFO: - reading the global IRQ register (two bytes, one for command, the other for data) - reading one UART's ISR (again two bytes) - reading the byte count (two bytes yet again) - finally, reading one byte of the FIFO via another two-byte transaction We cannot always use a batched read. If the TTY is set to intercept break conditions or report framing or parity errors, then it is required to check the Line Status Register (LSR) for each byte which is read from the RX FIFO. The documentation does not show a way of doing that in a single SPI transaction; registers 0x00 and 0x04 are separate. In my testing, this is no silver bullet. I was feeding 2MB of random data over four daisy-chaned UARTs of MAX14830, and this is the distribution that I was getting: - R <= 1: 7437322 - R <= 2: 162093 - R <= 4: 4093 - R <= 8: 4196 - R <= 16: 645 - R <= 32: 165 - R <= 64: 58 - R <= 128: 0 For a reference, batching the write operations works much better: - W <= 1: 2664 - W <= 2: 1305 - W <= 4: 627 - W <= 8: 371 - W <= 16: 121 - W <= 32: 68 - W <= 64: 33 - W <= 128: 63139 That's probably because this HW/SW combination (Clearfog Base, Armada 388) is probably "good enough" to react to the chip's IRQ "fast enough" most of the time. Still, I was getting RX overruns every now and then. In future, I plan to improve this by letting the RX FIFO be filled a little more (the chip has support for that and also for a "stale timeout" to prevent additional starvation). Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-14 15:02:54 +00:00
static void max310x_handle_rx(struct uart_port *port, unsigned int rxlen)
{
struct max310x_one *one = to_max310x_port(port);
serial: drivers: switch ch and flag to u8 Now that the serial layer explicitly expects 'u8' for flags and characters, propagate this type to drivers' (RX) routines. Note that amba-pl011's, clps711x's and st-asc's 'ch' are left unchanged because 'ch' contains not only a character, but whole status. Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Cc: Tobias Klauser <tklauser@distanz.ch> Cc: Russell King <linux@armlinux.org.uk> Cc: Vineet Gupta <vgupta@kernel.org> Cc: Richard Genoud <richard.genoud@gmail.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Claudiu Beznea <claudiu.beznea@microchip.com> Cc: Alexander Shiyan <shc_work@mail.ru> Cc: Baruch Siach <baruch@tkos.co.il> Cc: "Maciej W. Rozycki" <macro@orcam.me.uk> Cc: Taichi Sugaya <sugaya.taichi@socionext.com> Cc: Takao Orito <orito.takao@socionext.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: Kevin Cernekee <cernekee@gmail.com> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Cc: Alim Akhtar <alim.akhtar@samsung.com> Cc: Laxman Dewangan <ldewangan@nvidia.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Orson Zhai <orsonzhai@gmail.com> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Chunyan Zhang <zhang.lyra@gmail.com> Cc: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: Hammer Hsieh <hammerh0314@gmail.com> Acked-by: Richard GENOUD <richard.genoud@gmail.com> Acked-by: Tobias Klauser <tklauser@distanz.ch> Acked-by: Thierry Reding <treding@nvidia.com> Acked-by: Maciej W. Rozycki <macro@orcam.me.uk> Link: https://lore.kernel.org/r/20230712081811.29004-11-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-12 08:18:11 +00:00
unsigned int sts, i;
u8 ch, flag;
serial: max310x: Use batched reads when reasonably safe The hardware has a 128 byte RX FIFO buffer for each independent UART. Previously, the code was always reading that byte-by-byte via independent SPI transactions and the associated overhead. In practice, this led to up to eight bytes over SPI for just one byte in the UART's RX FIFO: - reading the global IRQ register (two bytes, one for command, the other for data) - reading one UART's ISR (again two bytes) - reading the byte count (two bytes yet again) - finally, reading one byte of the FIFO via another two-byte transaction We cannot always use a batched read. If the TTY is set to intercept break conditions or report framing or parity errors, then it is required to check the Line Status Register (LSR) for each byte which is read from the RX FIFO. The documentation does not show a way of doing that in a single SPI transaction; registers 0x00 and 0x04 are separate. In my testing, this is no silver bullet. I was feeding 2MB of random data over four daisy-chaned UARTs of MAX14830, and this is the distribution that I was getting: - R <= 1: 7437322 - R <= 2: 162093 - R <= 4: 4093 - R <= 8: 4196 - R <= 16: 645 - R <= 32: 165 - R <= 64: 58 - R <= 128: 0 For a reference, batching the write operations works much better: - W <= 1: 2664 - W <= 2: 1305 - W <= 4: 627 - W <= 8: 371 - W <= 16: 121 - W <= 32: 68 - W <= 64: 33 - W <= 128: 63139 That's probably because this HW/SW combination (Clearfog Base, Armada 388) is probably "good enough" to react to the chip's IRQ "fast enough" most of the time. Still, I was getting RX overruns every now and then. In future, I plan to improve this by letting the RX FIFO be filled a little more (the chip has support for that and also for a "stale timeout" to prevent additional starvation). Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-14 15:02:54 +00:00
if (port->read_status_mask == MAX310X_LSR_RXOVR_BIT) {
/*
* We are just reading, happily ignoring any error conditions.
serial: max310x: Use batched reads when reasonably safe The hardware has a 128 byte RX FIFO buffer for each independent UART. Previously, the code was always reading that byte-by-byte via independent SPI transactions and the associated overhead. In practice, this led to up to eight bytes over SPI for just one byte in the UART's RX FIFO: - reading the global IRQ register (two bytes, one for command, the other for data) - reading one UART's ISR (again two bytes) - reading the byte count (two bytes yet again) - finally, reading one byte of the FIFO via another two-byte transaction We cannot always use a batched read. If the TTY is set to intercept break conditions or report framing or parity errors, then it is required to check the Line Status Register (LSR) for each byte which is read from the RX FIFO. The documentation does not show a way of doing that in a single SPI transaction; registers 0x00 and 0x04 are separate. In my testing, this is no silver bullet. I was feeding 2MB of random data over four daisy-chaned UARTs of MAX14830, and this is the distribution that I was getting: - R <= 1: 7437322 - R <= 2: 162093 - R <= 4: 4093 - R <= 8: 4196 - R <= 16: 645 - R <= 32: 165 - R <= 64: 58 - R <= 128: 0 For a reference, batching the write operations works much better: - W <= 1: 2664 - W <= 2: 1305 - W <= 4: 627 - W <= 8: 371 - W <= 16: 121 - W <= 32: 68 - W <= 64: 33 - W <= 128: 63139 That's probably because this HW/SW combination (Clearfog Base, Armada 388) is probably "good enough" to react to the chip's IRQ "fast enough" most of the time. Still, I was getting RX overruns every now and then. In future, I plan to improve this by letting the RX FIFO be filled a little more (the chip has support for that and also for a "stale timeout" to prevent additional starvation). Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-14 15:02:54 +00:00
* Break condition, parity checking, framing errors -- they
* are all ignored. That means that we can do a batch-read.
*
* There is a small opportunity for race if the RX FIFO
* overruns while we're reading the buffer; the datasheets says
* that the LSR register applies to the "current" character.
* That's also the reason why we cannot do batched reads when
* asked to check the individual statuses.
*/
sts = max310x_port_read(port, MAX310X_LSR_IRQSTS_REG);
max310x_batch_read(port, one->rx_buf, rxlen);
serial: max310x: Use batched reads when reasonably safe The hardware has a 128 byte RX FIFO buffer for each independent UART. Previously, the code was always reading that byte-by-byte via independent SPI transactions and the associated overhead. In practice, this led to up to eight bytes over SPI for just one byte in the UART's RX FIFO: - reading the global IRQ register (two bytes, one for command, the other for data) - reading one UART's ISR (again two bytes) - reading the byte count (two bytes yet again) - finally, reading one byte of the FIFO via another two-byte transaction We cannot always use a batched read. If the TTY is set to intercept break conditions or report framing or parity errors, then it is required to check the Line Status Register (LSR) for each byte which is read from the RX FIFO. The documentation does not show a way of doing that in a single SPI transaction; registers 0x00 and 0x04 are separate. In my testing, this is no silver bullet. I was feeding 2MB of random data over four daisy-chaned UARTs of MAX14830, and this is the distribution that I was getting: - R <= 1: 7437322 - R <= 2: 162093 - R <= 4: 4093 - R <= 8: 4196 - R <= 16: 645 - R <= 32: 165 - R <= 64: 58 - R <= 128: 0 For a reference, batching the write operations works much better: - W <= 1: 2664 - W <= 2: 1305 - W <= 4: 627 - W <= 8: 371 - W <= 16: 121 - W <= 32: 68 - W <= 64: 33 - W <= 128: 63139 That's probably because this HW/SW combination (Clearfog Base, Armada 388) is probably "good enough" to react to the chip's IRQ "fast enough" most of the time. Still, I was getting RX overruns every now and then. In future, I plan to improve this by letting the RX FIFO be filled a little more (the chip has support for that and also for a "stale timeout" to prevent additional starvation). Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-14 15:02:54 +00:00
port->icount.rx += rxlen;
flag = TTY_NORMAL;
serial: max310x: Use batched reads when reasonably safe The hardware has a 128 byte RX FIFO buffer for each independent UART. Previously, the code was always reading that byte-by-byte via independent SPI transactions and the associated overhead. In practice, this led to up to eight bytes over SPI for just one byte in the UART's RX FIFO: - reading the global IRQ register (two bytes, one for command, the other for data) - reading one UART's ISR (again two bytes) - reading the byte count (two bytes yet again) - finally, reading one byte of the FIFO via another two-byte transaction We cannot always use a batched read. If the TTY is set to intercept break conditions or report framing or parity errors, then it is required to check the Line Status Register (LSR) for each byte which is read from the RX FIFO. The documentation does not show a way of doing that in a single SPI transaction; registers 0x00 and 0x04 are separate. In my testing, this is no silver bullet. I was feeding 2MB of random data over four daisy-chaned UARTs of MAX14830, and this is the distribution that I was getting: - R <= 1: 7437322 - R <= 2: 162093 - R <= 4: 4093 - R <= 8: 4196 - R <= 16: 645 - R <= 32: 165 - R <= 64: 58 - R <= 128: 0 For a reference, batching the write operations works much better: - W <= 1: 2664 - W <= 2: 1305 - W <= 4: 627 - W <= 8: 371 - W <= 16: 121 - W <= 32: 68 - W <= 64: 33 - W <= 128: 63139 That's probably because this HW/SW combination (Clearfog Base, Armada 388) is probably "good enough" to react to the chip's IRQ "fast enough" most of the time. Still, I was getting RX overruns every now and then. In future, I plan to improve this by letting the RX FIFO be filled a little more (the chip has support for that and also for a "stale timeout" to prevent additional starvation). Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-14 15:02:54 +00:00
sts &= port->read_status_mask;
serial: max310x: Use batched reads when reasonably safe The hardware has a 128 byte RX FIFO buffer for each independent UART. Previously, the code was always reading that byte-by-byte via independent SPI transactions and the associated overhead. In practice, this led to up to eight bytes over SPI for just one byte in the UART's RX FIFO: - reading the global IRQ register (two bytes, one for command, the other for data) - reading one UART's ISR (again two bytes) - reading the byte count (two bytes yet again) - finally, reading one byte of the FIFO via another two-byte transaction We cannot always use a batched read. If the TTY is set to intercept break conditions or report framing or parity errors, then it is required to check the Line Status Register (LSR) for each byte which is read from the RX FIFO. The documentation does not show a way of doing that in a single SPI transaction; registers 0x00 and 0x04 are separate. In my testing, this is no silver bullet. I was feeding 2MB of random data over four daisy-chaned UARTs of MAX14830, and this is the distribution that I was getting: - R <= 1: 7437322 - R <= 2: 162093 - R <= 4: 4093 - R <= 8: 4196 - R <= 16: 645 - R <= 32: 165 - R <= 64: 58 - R <= 128: 0 For a reference, batching the write operations works much better: - W <= 1: 2664 - W <= 2: 1305 - W <= 4: 627 - W <= 8: 371 - W <= 16: 121 - W <= 32: 68 - W <= 64: 33 - W <= 128: 63139 That's probably because this HW/SW combination (Clearfog Base, Armada 388) is probably "good enough" to react to the chip's IRQ "fast enough" most of the time. Still, I was getting RX overruns every now and then. In future, I plan to improve this by letting the RX FIFO be filled a little more (the chip has support for that and also for a "stale timeout" to prevent additional starvation). Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-14 15:02:54 +00:00
if (sts & MAX310X_LSR_RXOVR_BIT) {
dev_warn_ratelimited(port->dev, "Hardware RX FIFO overrun\n");
port->icount.overrun++;
}
for (i = 0; i < (rxlen - 1); ++i)
uart_insert_char(port, sts, 0, one->rx_buf[i], flag);
/*
* Handle the overrun case for the last character only, since
* the RxFIFO overflow happens after it is pushed to the FIFO
* tail.
*/
uart_insert_char(port, sts, MAX310X_LSR_RXOVR_BIT,
one->rx_buf[rxlen-1], flag);
serial: max310x: Use batched reads when reasonably safe The hardware has a 128 byte RX FIFO buffer for each independent UART. Previously, the code was always reading that byte-by-byte via independent SPI transactions and the associated overhead. In practice, this led to up to eight bytes over SPI for just one byte in the UART's RX FIFO: - reading the global IRQ register (two bytes, one for command, the other for data) - reading one UART's ISR (again two bytes) - reading the byte count (two bytes yet again) - finally, reading one byte of the FIFO via another two-byte transaction We cannot always use a batched read. If the TTY is set to intercept break conditions or report framing or parity errors, then it is required to check the Line Status Register (LSR) for each byte which is read from the RX FIFO. The documentation does not show a way of doing that in a single SPI transaction; registers 0x00 and 0x04 are separate. In my testing, this is no silver bullet. I was feeding 2MB of random data over four daisy-chaned UARTs of MAX14830, and this is the distribution that I was getting: - R <= 1: 7437322 - R <= 2: 162093 - R <= 4: 4093 - R <= 8: 4196 - R <= 16: 645 - R <= 32: 165 - R <= 64: 58 - R <= 128: 0 For a reference, batching the write operations works much better: - W <= 1: 2664 - W <= 2: 1305 - W <= 4: 627 - W <= 8: 371 - W <= 16: 121 - W <= 32: 68 - W <= 64: 33 - W <= 128: 63139 That's probably because this HW/SW combination (Clearfog Base, Armada 388) is probably "good enough" to react to the chip's IRQ "fast enough" most of the time. Still, I was getting RX overruns every now and then. In future, I plan to improve this by letting the RX FIFO be filled a little more (the chip has support for that and also for a "stale timeout" to prevent additional starvation). Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-14 15:02:54 +00:00
} else {
if (unlikely(rxlen >= port->fifosize)) {
dev_warn_ratelimited(port->dev, "Possible RX FIFO overrun\n");
port->icount.buf_overrun++;
/* Ensure sanity of RX level */
rxlen = port->fifosize;
}
serial: max310x: Use batched reads when reasonably safe The hardware has a 128 byte RX FIFO buffer for each independent UART. Previously, the code was always reading that byte-by-byte via independent SPI transactions and the associated overhead. In practice, this led to up to eight bytes over SPI for just one byte in the UART's RX FIFO: - reading the global IRQ register (two bytes, one for command, the other for data) - reading one UART's ISR (again two bytes) - reading the byte count (two bytes yet again) - finally, reading one byte of the FIFO via another two-byte transaction We cannot always use a batched read. If the TTY is set to intercept break conditions or report framing or parity errors, then it is required to check the Line Status Register (LSR) for each byte which is read from the RX FIFO. The documentation does not show a way of doing that in a single SPI transaction; registers 0x00 and 0x04 are separate. In my testing, this is no silver bullet. I was feeding 2MB of random data over four daisy-chaned UARTs of MAX14830, and this is the distribution that I was getting: - R <= 1: 7437322 - R <= 2: 162093 - R <= 4: 4093 - R <= 8: 4196 - R <= 16: 645 - R <= 32: 165 - R <= 64: 58 - R <= 128: 0 For a reference, batching the write operations works much better: - W <= 1: 2664 - W <= 2: 1305 - W <= 4: 627 - W <= 8: 371 - W <= 16: 121 - W <= 32: 68 - W <= 64: 33 - W <= 128: 63139 That's probably because this HW/SW combination (Clearfog Base, Armada 388) is probably "good enough" to react to the chip's IRQ "fast enough" most of the time. Still, I was getting RX overruns every now and then. In future, I plan to improve this by letting the RX FIFO be filled a little more (the chip has support for that and also for a "stale timeout" to prevent additional starvation). Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-14 15:02:54 +00:00
while (rxlen--) {
ch = max310x_port_read(port, MAX310X_RHR_REG);
sts = max310x_port_read(port, MAX310X_LSR_IRQSTS_REG);
sts &= MAX310X_LSR_RXPAR_BIT | MAX310X_LSR_FRERR_BIT |
MAX310X_LSR_RXOVR_BIT | MAX310X_LSR_RXBRK_BIT;
port->icount.rx++;
flag = TTY_NORMAL;
if (unlikely(sts)) {
if (sts & MAX310X_LSR_RXBRK_BIT) {
port->icount.brk++;
if (uart_handle_break(port))
continue;
} else if (sts & MAX310X_LSR_RXPAR_BIT)
port->icount.parity++;
else if (sts & MAX310X_LSR_FRERR_BIT)
port->icount.frame++;
else if (sts & MAX310X_LSR_RXOVR_BIT)
port->icount.overrun++;
sts &= port->read_status_mask;
if (sts & MAX310X_LSR_RXBRK_BIT)
flag = TTY_BREAK;
else if (sts & MAX310X_LSR_RXPAR_BIT)
flag = TTY_PARITY;
else if (sts & MAX310X_LSR_FRERR_BIT)
flag = TTY_FRAME;
else if (sts & MAX310X_LSR_RXOVR_BIT)
flag = TTY_OVERRUN;
}
if (uart_handle_sysrq_char(port, ch))
continue;
if (sts & port->ignore_status_mask)
continue;
uart_insert_char(port, sts, MAX310X_LSR_RXOVR_BIT, ch, flag);
}
}
tty_flip_buffer_push(&port->state->port);
}
static void max310x_handle_tx(struct uart_port *port)
{
struct circ_buf *xmit = &port->state->xmit;
unsigned int txlen, to_send, until_end;
if (unlikely(port->x_char)) {
max310x_port_write(port, MAX310X_THR_REG, port->x_char);
port->icount.tx++;
port->x_char = 0;
return;
}
if (uart_circ_empty(xmit) || uart_tx_stopped(port))
return;
/* Get length of data pending in circular buffer */
to_send = uart_circ_chars_pending(xmit);
until_end = CIRC_CNT_TO_END(xmit->head, xmit->tail, UART_XMIT_SIZE);
if (likely(to_send)) {
/* Limit to space available in TX FIFO */
txlen = max310x_port_read(port, MAX310X_TXFIFOLVL_REG);
txlen = port->fifosize - txlen;
to_send = (to_send > txlen) ? txlen : to_send;
if (until_end < to_send) {
/*
* It's a circ buffer -- wrap around.
* We could do that in one SPI transaction, but meh.
*/
max310x_batch_write(port, xmit->buf + xmit->tail, until_end);
max310x_batch_write(port, xmit->buf, to_send - until_end);
} else {
max310x_batch_write(port, xmit->buf + xmit->tail, to_send);
}
uart_xmit_advance(port, to_send);
}
if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
uart_write_wakeup(port);
}
serial: max310x: Reduce RX work starvation Prior to this patch, the code would happily trigger TX on some ports before having a chance of reading the RX buffer from the rest of them. When no flow control was used, this led to RX buffer overruns and therefore lost data under certain circumstances. I was able to reproduce this with MAX14830 (that's a quad channel one) and a simple daisy-chain of RX and TX ports on the eval board: - TX0 -> RX1 - TX1 -> RX2 - TX2 -> RX3 - TX3 -> RX0 I was testing this by transferring 2MB of data at 115200 baud via each port. I used a Solidrun Clearfog Base (Armada 388) which was talking to the UART over an SPI bus clocked at 26MHz (the chip's maximum). Without this patch, I would always get a "Possible RX FIFO overrun" in dmesg, and fewer-than-expected amount of bytes received over ttyMAX0. Results on ttyMAX{1,2,3} tended to be correct all the time, even without the previous patches in this series and with PIO SPI transfers ("indirect mode" as the Marvell datasheet calls it), so I assume that heavy congestion is needed in order to reproduce this. A drawback of this patch is that the throughput gets reduced "a bit". Previously, a 115200 baud resulted in about 11.2kBps throughput as reported by a simple `pv`. With this patch, the throughput of four parallel streams is roughly 7kBps each, and 9kBps for three streams. There is no slowdown for one or two parallel streams. Situation is worse if bytes are being read one-by-one (such as if the userspace wants to perform parity/framing/break checking) and therefore without the batched reads. With just this patch and no other modifications on top of 4.14, I was only getting roughly 3.6kBps with four parallel streams. The single-stream performance was the same, and I was seeing about 7.2kBps with two parallel streams. `perf top` said that a substantial amount of time was spent in `finish_task_switch`, `_raw_spin_unlock_irqrestore` and `__timer_delay`. Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-08 22:51:33 +00:00
static void max310x_start_tx(struct uart_port *port)
{
struct max310x_one *one = to_max310x_port(port);
serial: max310x: Reduce RX work starvation Prior to this patch, the code would happily trigger TX on some ports before having a chance of reading the RX buffer from the rest of them. When no flow control was used, this led to RX buffer overruns and therefore lost data under certain circumstances. I was able to reproduce this with MAX14830 (that's a quad channel one) and a simple daisy-chain of RX and TX ports on the eval board: - TX0 -> RX1 - TX1 -> RX2 - TX2 -> RX3 - TX3 -> RX0 I was testing this by transferring 2MB of data at 115200 baud via each port. I used a Solidrun Clearfog Base (Armada 388) which was talking to the UART over an SPI bus clocked at 26MHz (the chip's maximum). Without this patch, I would always get a "Possible RX FIFO overrun" in dmesg, and fewer-than-expected amount of bytes received over ttyMAX0. Results on ttyMAX{1,2,3} tended to be correct all the time, even without the previous patches in this series and with PIO SPI transfers ("indirect mode" as the Marvell datasheet calls it), so I assume that heavy congestion is needed in order to reproduce this. A drawback of this patch is that the throughput gets reduced "a bit". Previously, a 115200 baud resulted in about 11.2kBps throughput as reported by a simple `pv`. With this patch, the throughput of four parallel streams is roughly 7kBps each, and 9kBps for three streams. There is no slowdown for one or two parallel streams. Situation is worse if bytes are being read one-by-one (such as if the userspace wants to perform parity/framing/break checking) and therefore without the batched reads. With just this patch and no other modifications on top of 4.14, I was only getting roughly 3.6kBps with four parallel streams. The single-stream performance was the same, and I was seeing about 7.2kBps with two parallel streams. `perf top` said that a substantial amount of time was spent in `finish_task_switch`, `_raw_spin_unlock_irqrestore` and `__timer_delay`. Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-08 22:51:33 +00:00
schedule_work(&one->tx_work);
serial: max310x: Reduce RX work starvation Prior to this patch, the code would happily trigger TX on some ports before having a chance of reading the RX buffer from the rest of them. When no flow control was used, this led to RX buffer overruns and therefore lost data under certain circumstances. I was able to reproduce this with MAX14830 (that's a quad channel one) and a simple daisy-chain of RX and TX ports on the eval board: - TX0 -> RX1 - TX1 -> RX2 - TX2 -> RX3 - TX3 -> RX0 I was testing this by transferring 2MB of data at 115200 baud via each port. I used a Solidrun Clearfog Base (Armada 388) which was talking to the UART over an SPI bus clocked at 26MHz (the chip's maximum). Without this patch, I would always get a "Possible RX FIFO overrun" in dmesg, and fewer-than-expected amount of bytes received over ttyMAX0. Results on ttyMAX{1,2,3} tended to be correct all the time, even without the previous patches in this series and with PIO SPI transfers ("indirect mode" as the Marvell datasheet calls it), so I assume that heavy congestion is needed in order to reproduce this. A drawback of this patch is that the throughput gets reduced "a bit". Previously, a 115200 baud resulted in about 11.2kBps throughput as reported by a simple `pv`. With this patch, the throughput of four parallel streams is roughly 7kBps each, and 9kBps for three streams. There is no slowdown for one or two parallel streams. Situation is worse if bytes are being read one-by-one (such as if the userspace wants to perform parity/framing/break checking) and therefore without the batched reads. With just this patch and no other modifications on top of 4.14, I was only getting roughly 3.6kBps with four parallel streams. The single-stream performance was the same, and I was seeing about 7.2kBps with two parallel streams. `perf top` said that a substantial amount of time was spent in `finish_task_switch`, `_raw_spin_unlock_irqrestore` and `__timer_delay`. Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-08 22:51:33 +00:00
}
static irqreturn_t max310x_port_irq(struct max310x_port *s, int portno)
{
struct uart_port *port = &s->p[portno].port;
irqreturn_t res = IRQ_NONE;
do {
unsigned int ists, lsr, rxlen;
/* Read IRQ status & RX FIFO level */
ists = max310x_port_read(port, MAX310X_IRQSTS_REG);
rxlen = max310x_port_read(port, MAX310X_RXFIFOLVL_REG);
if (!ists && !rxlen)
break;
res = IRQ_HANDLED;
if (ists & MAX310X_IRQ_CTS_BIT) {
lsr = max310x_port_read(port, MAX310X_LSR_IRQSTS_REG);
uart_handle_cts_change(port, lsr & MAX310X_LSR_CTS_BIT);
}
if (rxlen)
max310x_handle_rx(port, rxlen);
serial: max310x: Reduce RX work starvation Prior to this patch, the code would happily trigger TX on some ports before having a chance of reading the RX buffer from the rest of them. When no flow control was used, this led to RX buffer overruns and therefore lost data under certain circumstances. I was able to reproduce this with MAX14830 (that's a quad channel one) and a simple daisy-chain of RX and TX ports on the eval board: - TX0 -> RX1 - TX1 -> RX2 - TX2 -> RX3 - TX3 -> RX0 I was testing this by transferring 2MB of data at 115200 baud via each port. I used a Solidrun Clearfog Base (Armada 388) which was talking to the UART over an SPI bus clocked at 26MHz (the chip's maximum). Without this patch, I would always get a "Possible RX FIFO overrun" in dmesg, and fewer-than-expected amount of bytes received over ttyMAX0. Results on ttyMAX{1,2,3} tended to be correct all the time, even without the previous patches in this series and with PIO SPI transfers ("indirect mode" as the Marvell datasheet calls it), so I assume that heavy congestion is needed in order to reproduce this. A drawback of this patch is that the throughput gets reduced "a bit". Previously, a 115200 baud resulted in about 11.2kBps throughput as reported by a simple `pv`. With this patch, the throughput of four parallel streams is roughly 7kBps each, and 9kBps for three streams. There is no slowdown for one or two parallel streams. Situation is worse if bytes are being read one-by-one (such as if the userspace wants to perform parity/framing/break checking) and therefore without the batched reads. With just this patch and no other modifications on top of 4.14, I was only getting roughly 3.6kBps with four parallel streams. The single-stream performance was the same, and I was seeing about 7.2kBps with two parallel streams. `perf top` said that a substantial amount of time was spent in `finish_task_switch`, `_raw_spin_unlock_irqrestore` and `__timer_delay`. Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-08 22:51:33 +00:00
if (ists & MAX310X_IRQ_TXEMPTY_BIT)
max310x_start_tx(port);
} while (1);
return res;
}
static irqreturn_t max310x_ist(int irq, void *dev_id)
{
struct max310x_port *s = (struct max310x_port *)dev_id;
bool handled = false;
if (s->devtype->nr > 1) {
do {
unsigned int val = ~0;
WARN_ON_ONCE(regmap_read(s->regmap,
MAX310X_GLOBALIRQ_REG, &val));
val = ((1 << s->devtype->nr) - 1) & ~val;
if (!val)
break;
if (max310x_port_irq(s, fls(val) - 1) == IRQ_HANDLED)
handled = true;
} while (1);
} else {
if (max310x_port_irq(s, 0) == IRQ_HANDLED)
handled = true;
}
return IRQ_RETVAL(handled);
}
static void max310x_tx_proc(struct work_struct *ws)
{
struct max310x_one *one = container_of(ws, struct max310x_one, tx_work);
max310x_handle_tx(&one->port);
}
static unsigned int max310x_tx_empty(struct uart_port *port)
{
u8 lvl = max310x_port_read(port, MAX310X_TXFIFOLVL_REG);
return lvl ? 0 : TIOCSER_TEMT;
}
static unsigned int max310x_get_mctrl(struct uart_port *port)
{
/*
* DCD and DSR are not wired and CTS/RTS is handled automatically
* so just indicate DSR and CAR asserted
*/
return TIOCM_DSR | TIOCM_CAR;
}
static void max310x_md_proc(struct work_struct *ws)
{
struct max310x_one *one = container_of(ws, struct max310x_one, md_work);
max310x_port_update(&one->port, MAX310X_MODE2_REG,
MAX310X_MODE2_LOOPBACK_BIT,
(one->port.mctrl & TIOCM_LOOP) ?
MAX310X_MODE2_LOOPBACK_BIT : 0);
}
static void max310x_set_mctrl(struct uart_port *port, unsigned int mctrl)
{
struct max310x_one *one = to_max310x_port(port);
schedule_work(&one->md_work);
}
static void max310x_break_ctl(struct uart_port *port, int break_state)
{
max310x_port_update(port, MAX310X_LCR_REG,
MAX310X_LCR_TXBREAK_BIT,
break_state ? MAX310X_LCR_TXBREAK_BIT : 0);
}
static void max310x_set_termios(struct uart_port *port,
struct ktermios *termios,
const struct ktermios *old)
{
unsigned int lcr = 0, flow = 0;
int baud;
/* Mask termios capabilities we don't support */
termios->c_cflag &= ~CMSPAR;
/* Word size */
switch (termios->c_cflag & CSIZE) {
case CS5:
break;
case CS6:
lcr = MAX310X_LCR_LENGTH0_BIT;
break;
case CS7:
lcr = MAX310X_LCR_LENGTH1_BIT;
break;
case CS8:
default:
lcr = MAX310X_LCR_LENGTH1_BIT | MAX310X_LCR_LENGTH0_BIT;
break;
}
/* Parity */
if (termios->c_cflag & PARENB) {
lcr |= MAX310X_LCR_PARITY_BIT;
if (!(termios->c_cflag & PARODD))
lcr |= MAX310X_LCR_EVENPARITY_BIT;
}
/* Stop bits */
if (termios->c_cflag & CSTOPB)
lcr |= MAX310X_LCR_STOPLEN_BIT; /* 2 stops */
/* Update LCR register */
max310x_port_write(port, MAX310X_LCR_REG, lcr);
/* Set read status mask */
port->read_status_mask = MAX310X_LSR_RXOVR_BIT;
if (termios->c_iflag & INPCK)
port->read_status_mask |= MAX310X_LSR_RXPAR_BIT |
MAX310X_LSR_FRERR_BIT;
serial: Fix IGNBRK handling If IGNBRK is set without either BRKINT or PARMRK set, some uart drivers send a 0x00 byte for BREAK without the TTYBREAK flag to the line discipline, when it should send either nothing or the TTYBREAK flag set. This happens because the read_status_mask masks out the BI condition, which uart_insert_char() then interprets as a normal 0x00 byte. SUS v3 is clear regarding the meaning of IGNBRK; Section 11.2.2, General Terminal Interface - Input Modes, states: "If IGNBRK is set, a break condition detected on input shall be ignored; that is, not put on the input queue and therefore not read by any process." Fix read_status_mask to include the BI bit if IGNBRK is set; the lsr status retains the BI bit if a BREAK is recv'd, which is subsequently ignored in uart_insert_char() when masked with the ignore_status_mask. Affected drivers: 8250 - all serial_txx9 mfd amba-pl010 amba-pl011 atmel_serial bfin_uart dz ip22zilog max310x mxs-auart netx-serial pnx8xxx_uart pxa sb1250-duart sccnxp serial_ks8695 sirfsoc_uart st-asc vr41xx_siu zs sunzilog fsl_lpuart sunsab ucc_uart bcm63xx_uart sunsu efm32-uart pmac_zilog mpsc msm_serial m32r_sio Unaffected drivers: omap-serial rp2 sa1100 imx icom Annotated for fixes: altera_uart mcf Drivers without break detection: 21285 xilinx-uartps altera_jtaguart apbuart arc-uart clps711x max3100 uartlite msm_serial_hs nwpserial lantiq vt8500_serial Unknown: samsung mpc52xx_uart bfin_sport_uart cpm_uart/core Fixes: Bugzilla #71651, '8250_core.c incorrectly handles IGNBRK flag' Reported-by: Ivan <athlon_@mail.ru> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-16 12:10:41 +00:00
if (termios->c_iflag & (IGNBRK | BRKINT | PARMRK))
port->read_status_mask |= MAX310X_LSR_RXBRK_BIT;
/* Set status ignore mask */
port->ignore_status_mask = 0;
if (termios->c_iflag & IGNBRK)
port->ignore_status_mask |= MAX310X_LSR_RXBRK_BIT;
if (!(termios->c_cflag & CREAD))
port->ignore_status_mask |= MAX310X_LSR_RXPAR_BIT |
MAX310X_LSR_RXOVR_BIT |
MAX310X_LSR_FRERR_BIT |
MAX310X_LSR_RXBRK_BIT;
/* Configure flow control */
max310x_port_write(port, MAX310X_XON1_REG, termios->c_cc[VSTART]);
max310x_port_write(port, MAX310X_XOFF1_REG, termios->c_cc[VSTOP]);
/*
* Disable transmitter before enabling AutoCTS or auto transmitter
* flow control
*/
if (termios->c_cflag & CRTSCTS || termios->c_iflag & IXOFF) {
max310x_port_update(port, MAX310X_MODE1_REG,
MAX310X_MODE1_TXDIS_BIT,
MAX310X_MODE1_TXDIS_BIT);
}
port->status &= ~(UPSTAT_AUTOCTS | UPSTAT_AUTORTS | UPSTAT_AUTOXOFF);
if (termios->c_cflag & CRTSCTS) {
/* Enable AUTORTS and AUTOCTS */
port->status |= UPSTAT_AUTOCTS | UPSTAT_AUTORTS;
flow |= MAX310X_FLOWCTRL_AUTOCTS_BIT |
MAX310X_FLOWCTRL_AUTORTS_BIT;
}
if (termios->c_iflag & IXON)
flow |= MAX310X_FLOWCTRL_SWFLOW3_BIT |
MAX310X_FLOWCTRL_SWFLOWEN_BIT;
if (termios->c_iflag & IXOFF) {
port->status |= UPSTAT_AUTOXOFF;
flow |= MAX310X_FLOWCTRL_SWFLOW1_BIT |
MAX310X_FLOWCTRL_SWFLOWEN_BIT;
}
max310x_port_write(port, MAX310X_FLOWCTRL_REG, flow);
/*
* Enable transmitter after disabling AutoCTS and auto transmitter
* flow control
*/
if (!(termios->c_cflag & CRTSCTS) && !(termios->c_iflag & IXOFF)) {
max310x_port_update(port, MAX310X_MODE1_REG,
MAX310X_MODE1_TXDIS_BIT,
0);
}
/* Get baud rate generator configuration */
baud = uart_get_baud_rate(port, termios, old,
port->uartclk / 16 / 0xffff,
port->uartclk / 4);
/* Setup baudrate generator */
baud = max310x_set_baud(port, baud);
/* Update timeout according to new baud rate */
uart_update_timeout(port, termios->c_cflag, baud);
}
static void max310x_rs_proc(struct work_struct *ws)
{
struct max310x_one *one = container_of(ws, struct max310x_one, rs_work);
unsigned int delay, mode1 = 0, mode2 = 0;
delay = (one->port.rs485.delay_rts_before_send << 4) |
one->port.rs485.delay_rts_after_send;
max310x_port_write(&one->port, MAX310X_HDPIXDELAY_REG, delay);
if (one->port.rs485.flags & SER_RS485_ENABLED) {
mode1 = MAX310X_MODE1_TRNSCVCTRL_BIT;
if (!(one->port.rs485.flags & SER_RS485_RX_DURING_TX))
mode2 = MAX310X_MODE2_ECHOSUPR_BIT;
}
max310x_port_update(&one->port, MAX310X_MODE1_REG,
MAX310X_MODE1_TRNSCVCTRL_BIT, mode1);
max310x_port_update(&one->port, MAX310X_MODE2_REG,
MAX310X_MODE2_ECHOSUPR_BIT, mode2);
}
static int max310x_rs485_config(struct uart_port *port, struct ktermios *termios,
struct serial_rs485 *rs485)
{
struct max310x_one *one = to_max310x_port(port);
if ((rs485->delay_rts_before_send > 0x0f) ||
(rs485->delay_rts_after_send > 0x0f))
return -ERANGE;
port->rs485 = *rs485;
schedule_work(&one->rs_work);
return 0;
}
static int max310x_startup(struct uart_port *port)
{
unsigned int val;
max310x_power(port, 1);
/* Configure MODE1 register */
max310x_port_update(port, MAX310X_MODE1_REG,
MAX310X_MODE1_TRNSCVCTRL_BIT, 0);
/* Configure MODE2 register & Reset FIFOs*/
val = MAX310X_MODE2_RXEMPTINV_BIT | MAX310X_MODE2_FIFORST_BIT;
max310x_port_write(port, MAX310X_MODE2_REG, val);
max310x_port_update(port, MAX310X_MODE2_REG,
MAX310X_MODE2_FIFORST_BIT, 0);
/* Configure mode1/mode2 to have rs485/rs232 enabled at startup */
val = (clamp(port->rs485.delay_rts_before_send, 0U, 15U) << 4) |
clamp(port->rs485.delay_rts_after_send, 0U, 15U);
max310x_port_write(port, MAX310X_HDPIXDELAY_REG, val);
if (port->rs485.flags & SER_RS485_ENABLED) {
max310x_port_update(port, MAX310X_MODE1_REG,
MAX310X_MODE1_TRNSCVCTRL_BIT,
MAX310X_MODE1_TRNSCVCTRL_BIT);
if (!(port->rs485.flags & SER_RS485_RX_DURING_TX))
max310x_port_update(port, MAX310X_MODE2_REG,
MAX310X_MODE2_ECHOSUPR_BIT,
MAX310X_MODE2_ECHOSUPR_BIT);
}
/*
* Configure flow control levels:
* resume: 48
* halt: 96
*/
max310x_port_write(port, MAX310X_FLOWLVL_REG,
MAX310X_FLOWLVL_RES(48) | MAX310X_FLOWLVL_HALT(96));
/* Clear IRQ status register */
max310x_port_read(port, MAX310X_IRQSTS_REG);
/* Enable RX, TX, CTS change interrupts */
val = MAX310X_IRQ_RXEMPTY_BIT | MAX310X_IRQ_TXEMPTY_BIT;
max310x_port_write(port, MAX310X_IRQEN_REG, val | MAX310X_IRQ_CTS_BIT);
return 0;
}
static void max310x_shutdown(struct uart_port *port)
{
/* Disable all interrupts */
max310x_port_write(port, MAX310X_IRQEN_REG, 0);
max310x_power(port, 0);
}
static const char *max310x_type(struct uart_port *port)
{
struct max310x_port *s = dev_get_drvdata(port->dev);
return (port->type == PORT_MAX310X) ? s->devtype->name : NULL;
}
static int max310x_request_port(struct uart_port *port)
{
/* Do nothing */
return 0;
}
static void max310x_config_port(struct uart_port *port, int flags)
{
if (flags & UART_CONFIG_TYPE)
port->type = PORT_MAX310X;
}
static int max310x_verify_port(struct uart_port *port, struct serial_struct *s)
{
if ((s->type != PORT_UNKNOWN) && (s->type != PORT_MAX310X))
return -EINVAL;
if (s->irq != port->irq)
return -EINVAL;
return 0;
}
static void max310x_null_void(struct uart_port *port)
{
/* Do nothing */
}
static const struct uart_ops max310x_ops = {
.tx_empty = max310x_tx_empty,
.set_mctrl = max310x_set_mctrl,
.get_mctrl = max310x_get_mctrl,
.stop_tx = max310x_null_void,
.start_tx = max310x_start_tx,
.stop_rx = max310x_null_void,
.break_ctl = max310x_break_ctl,
.startup = max310x_startup,
.shutdown = max310x_shutdown,
.set_termios = max310x_set_termios,
.type = max310x_type,
.request_port = max310x_request_port,
.release_port = max310x_null_void,
.config_port = max310x_config_port,
.verify_port = max310x_verify_port,
};
serial: max310x: Fix dev_pm_ops This patch fixes wrong dev_pm_ops which caused by commit: serial: max310x: Driver rework. CC drivers/tty/serial/max310x.o LD drivers/video/fb.o CC drivers/w1/slaves/w1_ds2433.o CC drivers/w1/slaves/w1_ds2760.o CC drivers/xen/balloon.o CC drivers/video/backlight/adp8870_bl.o drivers/tty/serial/max310x.c:1292:8: warning: initialization from incompatible pointer type [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: (near initialization for 'max310x_pm_ops.suspend') [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: initialization from incompatible pointer type [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: (near initialization for 'max310x_pm_ops.resume') [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: initialization from incompatible pointer type [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: (near initialization for 'max310x_pm_ops.freeze') [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: initialization from incompatible pointer type [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: (near initialization for 'max310x_pm_ops.thaw') [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: initialization from incompatible pointer type [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: (near initialization for 'max310x_pm_ops.poweroff') [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: initialization from incompatible pointer type [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: (near initialization for 'max310x_pm_ops.restore') [enabled by default] Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-29 15:27:32 +00:00
static int __maybe_unused max310x_suspend(struct device *dev)
{
serial: max310x: Fix dev_pm_ops This patch fixes wrong dev_pm_ops which caused by commit: serial: max310x: Driver rework. CC drivers/tty/serial/max310x.o LD drivers/video/fb.o CC drivers/w1/slaves/w1_ds2433.o CC drivers/w1/slaves/w1_ds2760.o CC drivers/xen/balloon.o CC drivers/video/backlight/adp8870_bl.o drivers/tty/serial/max310x.c:1292:8: warning: initialization from incompatible pointer type [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: (near initialization for 'max310x_pm_ops.suspend') [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: initialization from incompatible pointer type [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: (near initialization for 'max310x_pm_ops.resume') [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: initialization from incompatible pointer type [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: (near initialization for 'max310x_pm_ops.freeze') [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: initialization from incompatible pointer type [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: (near initialization for 'max310x_pm_ops.thaw') [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: initialization from incompatible pointer type [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: (near initialization for 'max310x_pm_ops.poweroff') [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: initialization from incompatible pointer type [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: (near initialization for 'max310x_pm_ops.restore') [enabled by default] Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-29 15:27:32 +00:00
struct max310x_port *s = dev_get_drvdata(dev);
int i;
for (i = 0; i < s->devtype->nr; i++) {
uart_suspend_port(&max310x_uart, &s->p[i].port);
max310x_power(&s->p[i].port, 0);
}
return 0;
}
serial: max310x: Fix dev_pm_ops This patch fixes wrong dev_pm_ops which caused by commit: serial: max310x: Driver rework. CC drivers/tty/serial/max310x.o LD drivers/video/fb.o CC drivers/w1/slaves/w1_ds2433.o CC drivers/w1/slaves/w1_ds2760.o CC drivers/xen/balloon.o CC drivers/video/backlight/adp8870_bl.o drivers/tty/serial/max310x.c:1292:8: warning: initialization from incompatible pointer type [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: (near initialization for 'max310x_pm_ops.suspend') [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: initialization from incompatible pointer type [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: (near initialization for 'max310x_pm_ops.resume') [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: initialization from incompatible pointer type [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: (near initialization for 'max310x_pm_ops.freeze') [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: initialization from incompatible pointer type [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: (near initialization for 'max310x_pm_ops.thaw') [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: initialization from incompatible pointer type [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: (near initialization for 'max310x_pm_ops.poweroff') [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: initialization from incompatible pointer type [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: (near initialization for 'max310x_pm_ops.restore') [enabled by default] Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-29 15:27:32 +00:00
static int __maybe_unused max310x_resume(struct device *dev)
{
serial: max310x: Fix dev_pm_ops This patch fixes wrong dev_pm_ops which caused by commit: serial: max310x: Driver rework. CC drivers/tty/serial/max310x.o LD drivers/video/fb.o CC drivers/w1/slaves/w1_ds2433.o CC drivers/w1/slaves/w1_ds2760.o CC drivers/xen/balloon.o CC drivers/video/backlight/adp8870_bl.o drivers/tty/serial/max310x.c:1292:8: warning: initialization from incompatible pointer type [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: (near initialization for 'max310x_pm_ops.suspend') [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: initialization from incompatible pointer type [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: (near initialization for 'max310x_pm_ops.resume') [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: initialization from incompatible pointer type [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: (near initialization for 'max310x_pm_ops.freeze') [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: initialization from incompatible pointer type [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: (near initialization for 'max310x_pm_ops.thaw') [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: initialization from incompatible pointer type [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: (near initialization for 'max310x_pm_ops.poweroff') [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: initialization from incompatible pointer type [enabled by default] drivers/tty/serial/max310x.c:1292:8: warning: (near initialization for 'max310x_pm_ops.restore') [enabled by default] Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-29 15:27:32 +00:00
struct max310x_port *s = dev_get_drvdata(dev);
int i;
for (i = 0; i < s->devtype->nr; i++) {
max310x_power(&s->p[i].port, 1);
uart_resume_port(&max310x_uart, &s->p[i].port);
}
return 0;
}
static SIMPLE_DEV_PM_OPS(max310x_pm_ops, max310x_suspend, max310x_resume);
#ifdef CONFIG_GPIOLIB
static int max310x_gpio_get(struct gpio_chip *chip, unsigned int offset)
{
unsigned int val;
struct max310x_port *s = gpiochip_get_data(chip);
struct uart_port *port = &s->p[offset / 4].port;
val = max310x_port_read(port, MAX310X_GPIODATA_REG);
return !!((val >> 4) & (1 << (offset % 4)));
}
static void max310x_gpio_set(struct gpio_chip *chip, unsigned int offset, int value)
{
struct max310x_port *s = gpiochip_get_data(chip);
struct uart_port *port = &s->p[offset / 4].port;
max310x_port_update(port, MAX310X_GPIODATA_REG, 1 << (offset % 4),
value ? 1 << (offset % 4) : 0);
}
static int max310x_gpio_direction_input(struct gpio_chip *chip, unsigned int offset)
{
struct max310x_port *s = gpiochip_get_data(chip);
struct uart_port *port = &s->p[offset / 4].port;
max310x_port_update(port, MAX310X_GPIOCFG_REG, 1 << (offset % 4), 0);
return 0;
}
static int max310x_gpio_direction_output(struct gpio_chip *chip,
unsigned int offset, int value)
{
struct max310x_port *s = gpiochip_get_data(chip);
struct uart_port *port = &s->p[offset / 4].port;
max310x_port_update(port, MAX310X_GPIODATA_REG, 1 << (offset % 4),
value ? 1 << (offset % 4) : 0);
max310x_port_update(port, MAX310X_GPIOCFG_REG, 1 << (offset % 4),
1 << (offset % 4));
return 0;
}
static int max310x_gpio_set_config(struct gpio_chip *chip, unsigned int offset,
unsigned long config)
{
struct max310x_port *s = gpiochip_get_data(chip);
struct uart_port *port = &s->p[offset / 4].port;
switch (pinconf_to_config_param(config)) {
case PIN_CONFIG_DRIVE_OPEN_DRAIN:
max310x_port_update(port, MAX310X_GPIOCFG_REG,
1 << ((offset % 4) + 4),
1 << ((offset % 4) + 4));
return 0;
case PIN_CONFIG_DRIVE_PUSH_PULL:
max310x_port_update(port, MAX310X_GPIOCFG_REG,
1 << ((offset % 4) + 4), 0);
return 0;
default:
return -ENOTSUPP;
}
}
#endif
static const struct serial_rs485 max310x_rs485_supported = {
.flags = SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND | SER_RS485_RX_DURING_TX,
.delay_rts_before_send = 1,
.delay_rts_after_send = 1,
};
static int max310x_probe(struct device *dev, const struct max310x_devtype *devtype,
const struct max310x_if_cfg *if_cfg,
struct regmap *regmaps[], int irq)
{
int i, ret, fmin, fmax, freq;
struct max310x_port *s;
s32 uartclk = 0;
bool xtal;
for (i = 0; i < devtype->nr; i++)
if (IS_ERR(regmaps[i]))
return PTR_ERR(regmaps[i]);
/* Alloc port structure */
s = devm_kzalloc(dev, struct_size(s, p, devtype->nr), GFP_KERNEL);
if (!s)
return dev_err_probe(dev, -ENOMEM,
"Error allocating port structure\n");
/* Always ask for fixed clock rate from a property. */
device_property_read_u32(dev, "clock-frequency", &uartclk);
xtal = device_property_match_string(dev, "clock-names", "osc") < 0;
if (xtal)
s->clk = devm_clk_get_optional(dev, "xtal");
else
s->clk = devm_clk_get_optional(dev, "osc");
if (IS_ERR(s->clk))
return PTR_ERR(s->clk);
ret = clk_prepare_enable(s->clk);
if (ret)
return ret;
freq = clk_get_rate(s->clk);
if (freq == 0)
freq = uartclk;
if (freq == 0) {
ret = dev_err_probe(dev, -EINVAL, "Cannot get clock rate\n");
goto out_clk;
}
if (xtal) {
fmin = 1000000;
fmax = 4000000;
} else {
fmin = 500000;
fmax = 35000000;
}
/* Check frequency limits */
if (freq < fmin || freq > fmax) {
ret = -ERANGE;
goto out_clk;
}
s->regmap = regmaps[0];
s->devtype = devtype;
s->if_cfg = if_cfg;
dev_set_drvdata(dev, s);
/* Check device to ensure we are talking to what we expect */
ret = max310x_detect(dev);
if (ret)
goto out_clk;
for (i = 0; i < devtype->nr; i++) {
bool started = false;
unsigned int try = 0, val = 0;
/* Reset port */
regmap_write(regmaps[i], MAX310X_MODE2_REG,
MAX310X_MODE2_RST_BIT);
/* Clear port reset */
regmap_write(regmaps[i], MAX310X_MODE2_REG, 0);
/* Wait for port startup */
do {
msleep(MAX310X_PORT_STARTUP_WAIT_DELAY_MS);
regmap_read(regmaps[i], MAX310X_BRGDIVLSB_REG, &val);
if (val == 0x01)
started = true;
} while (!started && (++try < MAX310X_PORT_STARTUP_WAIT_RETRIES));
if (!started) {
ret = dev_err_probe(dev, -EAGAIN, "port reset failed\n");
goto out_uart;
}
regmap_write(regmaps[i], MAX310X_MODE1_REG, devtype->mode1);
}
uartclk = max310x_set_ref_clk(dev, s, freq, xtal);
if (uartclk < 0) {
ret = uartclk;
goto out_uart;
}
dev_dbg(dev, "Reference clock set to %i Hz\n", uartclk);
for (i = 0; i < devtype->nr; i++) {
unsigned int line;
line = find_first_zero_bit(max310x_lines, MAX310X_UART_NRMAX);
if (line == MAX310X_UART_NRMAX) {
ret = -ERANGE;
goto out_uart;
}
/* Initialize port data */
s->p[i].port.line = line;
s->p[i].port.dev = dev;
s->p[i].port.irq = irq;
s->p[i].port.type = PORT_MAX310X;
s->p[i].port.fifosize = MAX310X_FIFO_SIZE;
s->p[i].port.flags = UPF_FIXED_TYPE | UPF_LOW_LATENCY;
s->p[i].port.iotype = UPIO_PORT;
s->p[i].port.iobase = i;
/*
* Use all ones as membase to make sure uart_configure_port() in
* serial_core.c does not abort for SPI/I2C devices where the
* membase address is not applicable.
*/
s->p[i].port.membase = (void __iomem *)~0;
s->p[i].port.uartclk = uartclk;
s->p[i].port.rs485_config = max310x_rs485_config;
s->p[i].port.rs485_supported = max310x_rs485_supported;
s->p[i].port.ops = &max310x_ops;
s->p[i].regmap = regmaps[i];
/* Disable all interrupts */
max310x_port_write(&s->p[i].port, MAX310X_IRQEN_REG, 0);
/* Clear IRQ status register */
max310x_port_read(&s->p[i].port, MAX310X_IRQSTS_REG);
/* Initialize queue for start TX */
INIT_WORK(&s->p[i].tx_work, max310x_tx_proc);
/* Initialize queue for changing LOOPBACK mode */
INIT_WORK(&s->p[i].md_work, max310x_md_proc);
/* Initialize queue for changing RS485 mode */
INIT_WORK(&s->p[i].rs_work, max310x_rs_proc);
/* Register port */
ret = uart_add_one_port(&max310x_uart, &s->p[i].port);
if (ret)
goto out_uart;
set_bit(line, max310x_lines);
/* Go to suspend mode */
max310x_power(&s->p[i].port, 0);
}
serial: max310x: Fix invalid memory access during GPIO init The `max310x_spi_probe` function attempted to setup the GPIO bits before the corresponding structs for each serial port were initialized. If the DTS file specified a GPIO hog, this led to a crash because the GPIO stack ended up calling `max310x_gpio_direction_output` which referenced uninitialized memory: [<c04598c0>] (max310x_gpio_direction_output) from [<c03f5a2c>] (_gpiod_direction_output_raw+0x94/0x2d4) [<c03f5a2c>] (_gpiod_direction_output_raw) from [<c03f991c>] (gpiod_hog+0x6c/0x154) [<c03f991c>] (gpiod_hog) from [<c03fa2d8>] (of_gpiochip_add+0x28c/0x444) [<c03fa2d8>] (of_gpiochip_add) from [<c03f6b2c>] (gpiochip_add_data+0x4f8/0x760) [<c03f6b2c>] (gpiochip_add_data) from [<c03f6dd4>] (devm_gpiochip_add_data+0x40/0x7c) [<c03f6dd4>] (devm_gpiochip_add_data) from [<c0459fec>] (max310x_spi_probe+0x530/0x894) [<c0459fec>] (max310x_spi_probe) from [<c0503294>] (spi_drv_probe+0x7c/0xac) [<c0503294>] (spi_drv_probe) from [<c046628c>] (driver_probe_device+0x234/0x2e8) [<c046628c>] (driver_probe_device) from [<c0464890>] (bus_for_each_drv+0x60/0x94) [<c0464890>] (bus_for_each_drv) from [<c0465f78>] (__device_attach+0xb0/0x114) [<c0465f78>] (__device_attach) from [<c0465548>] (bus_probe_device+0x84/0x8c) [<c0465548>] (bus_probe_device) from [<c0463a00>] (device_add+0x3f4/0x580) [<c0463a00>] (device_add) from [<c0504164>] (spi_add_device+0x9c/0x134) [<c0504164>] (spi_add_device) from [<c0504c18>] (spi_register_controller+0x484/0x910) [<c0504c18>] (spi_register_controller) from [<c0506ee0>] (orion_spi_probe+0x2f4/0x3b4) [<c0506ee0>] (orion_spi_probe) from [<c0467dac>] (platform_drv_probe+0x50/0xb0) [<c0467dac>] (platform_drv_probe) from [<c046628c>] (driver_probe_device+0x234/0x2e8) [<c046628c>] (driver_probe_device) from [<c04663f8>] (__driver_attach+0xb8/0xbc) [<c04663f8>] (__driver_attach) from [<c04647e8>] (bus_for_each_dev+0x68/0x9c) [<c04647e8>] (bus_for_each_dev) from [<c046574c>] (bus_add_driver+0x104/0x210) [<c046574c>] (bus_add_driver) from [<c0466f14>] (driver_register+0x78/0xf4) [<c0466f14>] (driver_register) from [<c0101bdc>] (do_one_initcall+0x44/0x168) [<c0101bdc>] (do_one_initcall) from [<c0a00dc0>] (kernel_init_freeable+0x140/0x1cc) [<c0a00dc0>] (kernel_init_freeable) from [<c078c590>] (kernel_init+0x8/0x108) [<c078c590>] (kernel_init) from [<c0107a50>] (ret_from_fork+0x14/0x24) This can be easily fixed by moving the corresponding code below. And because the UARTs are already there by the time we reach this point, the `goto` needs changing so that more stuff is freed. (I have not tested this error path.) Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-08 19:36:29 +00:00
#ifdef CONFIG_GPIOLIB
/* Setup GPIO controller */
serial: max310x: Fix invalid memory access during GPIO init The `max310x_spi_probe` function attempted to setup the GPIO bits before the corresponding structs for each serial port were initialized. If the DTS file specified a GPIO hog, this led to a crash because the GPIO stack ended up calling `max310x_gpio_direction_output` which referenced uninitialized memory: [<c04598c0>] (max310x_gpio_direction_output) from [<c03f5a2c>] (_gpiod_direction_output_raw+0x94/0x2d4) [<c03f5a2c>] (_gpiod_direction_output_raw) from [<c03f991c>] (gpiod_hog+0x6c/0x154) [<c03f991c>] (gpiod_hog) from [<c03fa2d8>] (of_gpiochip_add+0x28c/0x444) [<c03fa2d8>] (of_gpiochip_add) from [<c03f6b2c>] (gpiochip_add_data+0x4f8/0x760) [<c03f6b2c>] (gpiochip_add_data) from [<c03f6dd4>] (devm_gpiochip_add_data+0x40/0x7c) [<c03f6dd4>] (devm_gpiochip_add_data) from [<c0459fec>] (max310x_spi_probe+0x530/0x894) [<c0459fec>] (max310x_spi_probe) from [<c0503294>] (spi_drv_probe+0x7c/0xac) [<c0503294>] (spi_drv_probe) from [<c046628c>] (driver_probe_device+0x234/0x2e8) [<c046628c>] (driver_probe_device) from [<c0464890>] (bus_for_each_drv+0x60/0x94) [<c0464890>] (bus_for_each_drv) from [<c0465f78>] (__device_attach+0xb0/0x114) [<c0465f78>] (__device_attach) from [<c0465548>] (bus_probe_device+0x84/0x8c) [<c0465548>] (bus_probe_device) from [<c0463a00>] (device_add+0x3f4/0x580) [<c0463a00>] (device_add) from [<c0504164>] (spi_add_device+0x9c/0x134) [<c0504164>] (spi_add_device) from [<c0504c18>] (spi_register_controller+0x484/0x910) [<c0504c18>] (spi_register_controller) from [<c0506ee0>] (orion_spi_probe+0x2f4/0x3b4) [<c0506ee0>] (orion_spi_probe) from [<c0467dac>] (platform_drv_probe+0x50/0xb0) [<c0467dac>] (platform_drv_probe) from [<c046628c>] (driver_probe_device+0x234/0x2e8) [<c046628c>] (driver_probe_device) from [<c04663f8>] (__driver_attach+0xb8/0xbc) [<c04663f8>] (__driver_attach) from [<c04647e8>] (bus_for_each_dev+0x68/0x9c) [<c04647e8>] (bus_for_each_dev) from [<c046574c>] (bus_add_driver+0x104/0x210) [<c046574c>] (bus_add_driver) from [<c0466f14>] (driver_register+0x78/0xf4) [<c0466f14>] (driver_register) from [<c0101bdc>] (do_one_initcall+0x44/0x168) [<c0101bdc>] (do_one_initcall) from [<c0a00dc0>] (kernel_init_freeable+0x140/0x1cc) [<c0a00dc0>] (kernel_init_freeable) from [<c078c590>] (kernel_init+0x8/0x108) [<c078c590>] (kernel_init) from [<c0107a50>] (ret_from_fork+0x14/0x24) This can be easily fixed by moving the corresponding code below. And because the UARTs are already there by the time we reach this point, the `goto` needs changing so that more stuff is freed. (I have not tested this error path.) Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-08 19:36:29 +00:00
s->gpio.owner = THIS_MODULE;
s->gpio.parent = dev;
s->gpio.label = devtype->name;
serial: max310x: Fix invalid memory access during GPIO init The `max310x_spi_probe` function attempted to setup the GPIO bits before the corresponding structs for each serial port were initialized. If the DTS file specified a GPIO hog, this led to a crash because the GPIO stack ended up calling `max310x_gpio_direction_output` which referenced uninitialized memory: [<c04598c0>] (max310x_gpio_direction_output) from [<c03f5a2c>] (_gpiod_direction_output_raw+0x94/0x2d4) [<c03f5a2c>] (_gpiod_direction_output_raw) from [<c03f991c>] (gpiod_hog+0x6c/0x154) [<c03f991c>] (gpiod_hog) from [<c03fa2d8>] (of_gpiochip_add+0x28c/0x444) [<c03fa2d8>] (of_gpiochip_add) from [<c03f6b2c>] (gpiochip_add_data+0x4f8/0x760) [<c03f6b2c>] (gpiochip_add_data) from [<c03f6dd4>] (devm_gpiochip_add_data+0x40/0x7c) [<c03f6dd4>] (devm_gpiochip_add_data) from [<c0459fec>] (max310x_spi_probe+0x530/0x894) [<c0459fec>] (max310x_spi_probe) from [<c0503294>] (spi_drv_probe+0x7c/0xac) [<c0503294>] (spi_drv_probe) from [<c046628c>] (driver_probe_device+0x234/0x2e8) [<c046628c>] (driver_probe_device) from [<c0464890>] (bus_for_each_drv+0x60/0x94) [<c0464890>] (bus_for_each_drv) from [<c0465f78>] (__device_attach+0xb0/0x114) [<c0465f78>] (__device_attach) from [<c0465548>] (bus_probe_device+0x84/0x8c) [<c0465548>] (bus_probe_device) from [<c0463a00>] (device_add+0x3f4/0x580) [<c0463a00>] (device_add) from [<c0504164>] (spi_add_device+0x9c/0x134) [<c0504164>] (spi_add_device) from [<c0504c18>] (spi_register_controller+0x484/0x910) [<c0504c18>] (spi_register_controller) from [<c0506ee0>] (orion_spi_probe+0x2f4/0x3b4) [<c0506ee0>] (orion_spi_probe) from [<c0467dac>] (platform_drv_probe+0x50/0xb0) [<c0467dac>] (platform_drv_probe) from [<c046628c>] (driver_probe_device+0x234/0x2e8) [<c046628c>] (driver_probe_device) from [<c04663f8>] (__driver_attach+0xb8/0xbc) [<c04663f8>] (__driver_attach) from [<c04647e8>] (bus_for_each_dev+0x68/0x9c) [<c04647e8>] (bus_for_each_dev) from [<c046574c>] (bus_add_driver+0x104/0x210) [<c046574c>] (bus_add_driver) from [<c0466f14>] (driver_register+0x78/0xf4) [<c0466f14>] (driver_register) from [<c0101bdc>] (do_one_initcall+0x44/0x168) [<c0101bdc>] (do_one_initcall) from [<c0a00dc0>] (kernel_init_freeable+0x140/0x1cc) [<c0a00dc0>] (kernel_init_freeable) from [<c078c590>] (kernel_init+0x8/0x108) [<c078c590>] (kernel_init) from [<c0107a50>] (ret_from_fork+0x14/0x24) This can be easily fixed by moving the corresponding code below. And because the UARTs are already there by the time we reach this point, the `goto` needs changing so that more stuff is freed. (I have not tested this error path.) Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-08 19:36:29 +00:00
s->gpio.direction_input = max310x_gpio_direction_input;
s->gpio.get = max310x_gpio_get;
s->gpio.direction_output= max310x_gpio_direction_output;
s->gpio.set = max310x_gpio_set;
s->gpio.set_config = max310x_gpio_set_config;
serial: max310x: Fix invalid memory access during GPIO init The `max310x_spi_probe` function attempted to setup the GPIO bits before the corresponding structs for each serial port were initialized. If the DTS file specified a GPIO hog, this led to a crash because the GPIO stack ended up calling `max310x_gpio_direction_output` which referenced uninitialized memory: [<c04598c0>] (max310x_gpio_direction_output) from [<c03f5a2c>] (_gpiod_direction_output_raw+0x94/0x2d4) [<c03f5a2c>] (_gpiod_direction_output_raw) from [<c03f991c>] (gpiod_hog+0x6c/0x154) [<c03f991c>] (gpiod_hog) from [<c03fa2d8>] (of_gpiochip_add+0x28c/0x444) [<c03fa2d8>] (of_gpiochip_add) from [<c03f6b2c>] (gpiochip_add_data+0x4f8/0x760) [<c03f6b2c>] (gpiochip_add_data) from [<c03f6dd4>] (devm_gpiochip_add_data+0x40/0x7c) [<c03f6dd4>] (devm_gpiochip_add_data) from [<c0459fec>] (max310x_spi_probe+0x530/0x894) [<c0459fec>] (max310x_spi_probe) from [<c0503294>] (spi_drv_probe+0x7c/0xac) [<c0503294>] (spi_drv_probe) from [<c046628c>] (driver_probe_device+0x234/0x2e8) [<c046628c>] (driver_probe_device) from [<c0464890>] (bus_for_each_drv+0x60/0x94) [<c0464890>] (bus_for_each_drv) from [<c0465f78>] (__device_attach+0xb0/0x114) [<c0465f78>] (__device_attach) from [<c0465548>] (bus_probe_device+0x84/0x8c) [<c0465548>] (bus_probe_device) from [<c0463a00>] (device_add+0x3f4/0x580) [<c0463a00>] (device_add) from [<c0504164>] (spi_add_device+0x9c/0x134) [<c0504164>] (spi_add_device) from [<c0504c18>] (spi_register_controller+0x484/0x910) [<c0504c18>] (spi_register_controller) from [<c0506ee0>] (orion_spi_probe+0x2f4/0x3b4) [<c0506ee0>] (orion_spi_probe) from [<c0467dac>] (platform_drv_probe+0x50/0xb0) [<c0467dac>] (platform_drv_probe) from [<c046628c>] (driver_probe_device+0x234/0x2e8) [<c046628c>] (driver_probe_device) from [<c04663f8>] (__driver_attach+0xb8/0xbc) [<c04663f8>] (__driver_attach) from [<c04647e8>] (bus_for_each_dev+0x68/0x9c) [<c04647e8>] (bus_for_each_dev) from [<c046574c>] (bus_add_driver+0x104/0x210) [<c046574c>] (bus_add_driver) from [<c0466f14>] (driver_register+0x78/0xf4) [<c0466f14>] (driver_register) from [<c0101bdc>] (do_one_initcall+0x44/0x168) [<c0101bdc>] (do_one_initcall) from [<c0a00dc0>] (kernel_init_freeable+0x140/0x1cc) [<c0a00dc0>] (kernel_init_freeable) from [<c078c590>] (kernel_init+0x8/0x108) [<c078c590>] (kernel_init) from [<c0107a50>] (ret_from_fork+0x14/0x24) This can be easily fixed by moving the corresponding code below. And because the UARTs are already there by the time we reach this point, the `goto` needs changing so that more stuff is freed. (I have not tested this error path.) Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-08 19:36:29 +00:00
s->gpio.base = -1;
s->gpio.ngpio = devtype->nr * 4;
s->gpio.can_sleep = 1;
ret = devm_gpiochip_add_data(dev, &s->gpio, s);
if (ret)
goto out_uart;
#endif
/* Setup interrupt */
ret = devm_request_threaded_irq(dev, irq, NULL, max310x_ist,
IRQF_ONESHOT | IRQF_SHARED, dev_name(dev), s);
if (!ret)
return 0;
dev_err(dev, "Unable to request IRQ %i\n", irq);
out_uart:
for (i = 0; i < devtype->nr; i++) {
if (test_and_clear_bit(s->p[i].port.line, max310x_lines))
uart_remove_one_port(&max310x_uart, &s->p[i].port);
}
out_clk:
clk_disable_unprepare(s->clk);
return ret;
}
static void max310x_remove(struct device *dev)
{
struct max310x_port *s = dev_get_drvdata(dev);
int i;
for (i = 0; i < s->devtype->nr; i++) {
cancel_work_sync(&s->p[i].tx_work);
cancel_work_sync(&s->p[i].md_work);
cancel_work_sync(&s->p[i].rs_work);
if (test_and_clear_bit(s->p[i].port.line, max310x_lines))
uart_remove_one_port(&max310x_uart, &s->p[i].port);
max310x_power(&s->p[i].port, 0);
}
clk_disable_unprepare(s->clk);
}
static const struct of_device_id __maybe_unused max310x_dt_ids[] = {
{ .compatible = "maxim,max3107", .data = &max3107_devtype, },
{ .compatible = "maxim,max3108", .data = &max3108_devtype, },
{ .compatible = "maxim,max3109", .data = &max3109_devtype, },
{ .compatible = "maxim,max14830", .data = &max14830_devtype },
{ }
};
MODULE_DEVICE_TABLE(of, max310x_dt_ids);
static struct regmap_config regcfg = {
.reg_bits = 8,
.val_bits = 8,
.write_flag_mask = MAX310X_WRITE_BIT,
.cache_type = REGCACHE_RBTREE,
.max_register = MAX310X_REG_1F,
.writeable_reg = max310x_reg_writeable,
.volatile_reg = max310x_reg_volatile,
.precious_reg = max310x_reg_precious,
.writeable_noinc_reg = max310x_reg_noinc,
.readable_noinc_reg = max310x_reg_noinc,
.max_raw_read = MAX310X_FIFO_SIZE,
.max_raw_write = MAX310X_FIFO_SIZE,
};
static const char *max310x_regmap_name(u8 port_id)
{
switch (port_id) {
case 0: return "port0";
case 1: return "port1";
case 2: return "port2";
case 3: return "port3";
default:
WARN_ON(true);
return NULL;
}
}
#ifdef CONFIG_SPI_MASTER
static int max310x_spi_extended_reg_enable(struct device *dev, bool enable)
{
struct max310x_port *s = dev_get_drvdata(dev);
return regmap_write(s->regmap, MAX310X_GLOBALCMD_REG,
enable ? MAX310X_EXTREG_ENBL : MAX310X_EXTREG_DSBL);
}
static const struct max310x_if_cfg __maybe_unused max310x_spi_if_cfg = {
.extended_reg_enable = max310x_spi_extended_reg_enable,
.rev_id_offset = MAX310X_EXTREG_START,
};
static int max310x_spi_probe(struct spi_device *spi)
{
const struct max310x_devtype *devtype;
struct regmap *regmaps[MAX310X_MAX_PORTS];
unsigned int i;
int ret;
/* Setup SPI bus */
spi->bits_per_word = 8;
spi->mode = spi->mode ? : SPI_MODE_0;
spi->max_speed_hz = spi->max_speed_hz ? : 26000000;
ret = spi_setup(spi);
if (ret)
return ret;
devtype = spi_get_device_match_data(spi);
if (!devtype)
return dev_err_probe(&spi->dev, -ENODEV, "Failed to match device\n");
for (i = 0; i < devtype->nr; i++) {
u8 port_mask = i * 0x20;
regcfg.name = max310x_regmap_name(i);
regcfg.read_flag_mask = port_mask;
regcfg.write_flag_mask = port_mask | MAX310X_WRITE_BIT;
regmaps[i] = devm_regmap_init_spi(spi, &regcfg);
}
return max310x_probe(&spi->dev, devtype, &max310x_spi_if_cfg, regmaps, spi->irq);
}
static void max310x_spi_remove(struct spi_device *spi)
{
max310x_remove(&spi->dev);
}
static const struct spi_device_id max310x_id_table[] = {
{ "max3107", (kernel_ulong_t)&max3107_devtype, },
{ "max3108", (kernel_ulong_t)&max3108_devtype, },
{ "max3109", (kernel_ulong_t)&max3109_devtype, },
{ "max14830", (kernel_ulong_t)&max14830_devtype, },
{ }
};
MODULE_DEVICE_TABLE(spi, max310x_id_table);
static struct spi_driver max310x_spi_driver = {
.driver = {
.name = MAX310X_NAME,
.of_match_table = max310x_dt_ids,
.pm = &max310x_pm_ops,
},
.probe = max310x_spi_probe,
.remove = max310x_spi_remove,
.id_table = max310x_id_table,
};
#endif
#ifdef CONFIG_I2C
static int max310x_i2c_extended_reg_enable(struct device *dev, bool enable)
{
return 0;
}
static struct regmap_config regcfg_i2c = {
.reg_bits = 8,
.val_bits = 8,
.cache_type = REGCACHE_RBTREE,
.writeable_reg = max310x_reg_writeable,
.volatile_reg = max310x_reg_volatile,
.precious_reg = max310x_reg_precious,
.max_register = MAX310X_REVID_EXTREG,
.writeable_noinc_reg = max310x_reg_noinc,
.readable_noinc_reg = max310x_reg_noinc,
.max_raw_read = MAX310X_FIFO_SIZE,
.max_raw_write = MAX310X_FIFO_SIZE,
};
static const struct max310x_if_cfg max310x_i2c_if_cfg = {
.extended_reg_enable = max310x_i2c_extended_reg_enable,
.rev_id_offset = 0, /* No offset in I2C mode. */
};
static unsigned short max310x_i2c_slave_addr(unsigned short addr,
unsigned int nr)
{
/*
* For MAX14830 and MAX3109, the slave address depends on what the
* A0 and A1 pins are tied to.
* See Table I2C Address Map of the datasheet.
* Based on that table, the following formulas were determined:
* UART1 - UART0 = 0x10
* UART2 - UART1 = 0x20 + 0x10
* UART3 - UART2 = 0x10
*/
addr -= nr * 0x10;
if (nr >= 2)
addr -= 0x20;
return addr;
}
static int max310x_i2c_probe(struct i2c_client *client)
{
const struct max310x_devtype *devtype;
struct i2c_client *port_client;
struct regmap *regmaps[MAX310X_MAX_PORTS];
unsigned int i;
u8 port_addr;
devtype = i2c_get_match_data(client);
if (!devtype)
return dev_err_probe(&client->dev, -ENODEV, "Failed to match device\n");
if (client->addr < devtype->slave_addr.min ||
client->addr > devtype->slave_addr.max)
return dev_err_probe(&client->dev, -EINVAL,
"Slave addr 0x%x outside of range [0x%x, 0x%x]\n",
client->addr, devtype->slave_addr.min,
devtype->slave_addr.max);
regcfg_i2c.name = max310x_regmap_name(0);
regmaps[0] = devm_regmap_init_i2c(client, &regcfg_i2c);
for (i = 1; i < devtype->nr; i++) {
port_addr = max310x_i2c_slave_addr(client->addr, i);
port_client = devm_i2c_new_dummy_device(&client->dev,
client->adapter,
port_addr);
regcfg_i2c.name = max310x_regmap_name(i);
regmaps[i] = devm_regmap_init_i2c(port_client, &regcfg_i2c);
}
return max310x_probe(&client->dev, devtype, &max310x_i2c_if_cfg,
regmaps, client->irq);
}
i2c: Make remove callback return void The value returned by an i2c driver's remove function is mostly ignored. (Only an error message is printed if the value is non-zero that the error is ignored.) So change the prototype of the remove function to return no value. This way driver authors are not tempted to assume that passing an error to the upper layer is a good idea. All drivers are adapted accordingly. There is no intended change of behaviour, all callbacks were prepared to return 0 before. Reviewed-by: Peter Senna Tschudin <peter.senna@gmail.com> Reviewed-by: Jeremy Kerr <jk@codeconstruct.com.au> Reviewed-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Crt Mori <cmo@melexis.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Marek Behún <kabel@kernel.org> # for leds-turris-omnia Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Petr Machata <petrm@nvidia.com> # for mlxsw Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com> # for surface3_power Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> # for bmc150-accel-i2c + kxcjk-1013 Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> # for media/* + staging/media/* Acked-by: Miguel Ojeda <ojeda@kernel.org> # for auxdisplay/ht16k33 + auxdisplay/lcd2s Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # for versaclock5 Reviewed-by: Ajay Gupta <ajayg@nvidia.com> # for ucsi_ccg Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # for iio Acked-by: Peter Rosin <peda@axentia.se> # for i2c-mux-*, max9860 Acked-by: Adrien Grassein <adrien.grassein@gmail.com> # for lontium-lt8912b Reviewed-by: Jean Delvare <jdelvare@suse.de> # for hwmon, i2c-core and i2c/muxes Acked-by: Corey Minyard <cminyard@mvista.com> # for IPMI Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> # for drivers/power Acked-by: Krzysztof Hałasa <khalasa@piap.pl> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-08-15 08:02:30 +00:00
static void max310x_i2c_remove(struct i2c_client *client)
{
max310x_remove(&client->dev);
}
static const struct i2c_device_id max310x_i2c_id_table[] = {
{ "max3107", (kernel_ulong_t)&max3107_devtype, },
{ "max3108", (kernel_ulong_t)&max3108_devtype, },
{ "max3109", (kernel_ulong_t)&max3109_devtype, },
{ "max14830", (kernel_ulong_t)&max14830_devtype, },
{ }
};
MODULE_DEVICE_TABLE(i2c, max310x_i2c_id_table);
static struct i2c_driver max310x_i2c_driver = {
.driver = {
.name = MAX310X_NAME,
.of_match_table = max310x_dt_ids,
.pm = &max310x_pm_ops,
},
.probe = max310x_i2c_probe,
.remove = max310x_i2c_remove,
.id_table = max310x_i2c_id_table,
};
#endif
static int __init max310x_uart_init(void)
{
int ret;
bitmap_zero(max310x_lines, MAX310X_UART_NRMAX);
ret = uart_register_driver(&max310x_uart);
if (ret)
return ret;
#ifdef CONFIG_SPI_MASTER
ret = spi_register_driver(&max310x_spi_driver);
if (ret)
goto err_spi_register;
#endif
#ifdef CONFIG_I2C
ret = i2c_add_driver(&max310x_i2c_driver);
if (ret)
goto err_i2c_register;
#endif
return 0;
#ifdef CONFIG_I2C
err_i2c_register:
spi_unregister_driver(&max310x_spi_driver);
#endif
err_spi_register:
uart_unregister_driver(&max310x_uart);
return ret;
}
module_init(max310x_uart_init);
static void __exit max310x_uart_exit(void)
{
#ifdef CONFIG_I2C
i2c_del_driver(&max310x_i2c_driver);
#endif
#ifdef CONFIG_SPI_MASTER
spi_unregister_driver(&max310x_spi_driver);
#endif
uart_unregister_driver(&max310x_uart);
}
module_exit(max310x_uart_exit);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Alexander Shiyan <shc_work@mail.ru>");
MODULE_DESCRIPTION("MAX310X serial driver");