There are multiple copies of setting the EFR register. Separate it to a
new universal function called __mxser_must_set_EFR. And use it in the
code by introducing mxser_must_set_enhance_mode instead of
mxser_disable_must_enchance_mode and mxser_enable_must_enchance_mode.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-41-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ModeMask local array is just inverted OP_MODE_MASK shifted by shiftbit.
Drop this array and use the value directly.
* return from the if's true branch and drop 'else' branch by moving the
code completely outside the if.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-40-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This ioctl code sets RS232, RS422 or RS485 mode. Move the code to a
separate function (mxser_ioctl_op_mode) with a note that these
mxser-special ioctls should be likely replaced eventually by TIOCGRS485
and TIOCSRS485.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-39-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It's an once-set constant, so define a macro for the constant
(MXSER_CUSTOM_DIVISOR) and use it in the code instead.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-37-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It's an once-set constant, so define a macro for the constant
(MXSER_BAUD_BASE) and use it in the code instead.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-36-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It's been a long time since mxser_port::stop_rx was abandoned. Remove it.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-35-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
After the previous patches, mxser_port::normal_termios is unused, so
time to wave bye-bye.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-34-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The MXSER_PORTS's tty_device is never registered and neither its
tty_port instance exists. Hence, it's quite pointless to allocate it.
It used to be used for global information fetches via ioctls. We have
just removed these as non-existent tty_device+tty_port was exactly the
reason to remove the ioctls.
It would be peculiar to add this "virtual" port as we require a backing
tty_port since commit ecbbfd44a0 (TTY: move tty buffers to tty_port)
in 2012.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-33-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
After the previous ioctls removal, cnt is needed only in
mxser_receive_chars_old now. So remove it from mxser_receive_chars and
mxser_receive_chars_new and account only in mxser_receive_chars_old.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-32-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1) The semantics are defined exactly nowhere.
2) The ioctl definition was never exposed to userspace, so noone should
actually be reliably using this.
3) It's not even mentioned in any of the mxser utilities.
Provided the above, remove this mxser-special ioctl.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-31-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1) The semantics are defined exactly nowhere.
2) The ioctl definition was never exposed to userspace, so noone should
actually be reliably using this.
3) It's not even mentioned in any of the mxser utilities.
Provided the above, remove this mxser-special ioctl.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-30-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1) MOXA_GETMSTATUS is broken at least since commit ecbbfd44a0 (TTY:
move tty buffers to tty_port) in 2012.
Even though it's mentioned in the mon_pa moxa utility, obviously
noone ever tried that in that timeframe.
2) The ioctl definition was never exposed to userspace, so noone
should actually be reliably using this.
Provided the above, remove this mxser-special ioctl.
And remove the whole concept of mxser_ioctl_special as this was the last
ioctl in there.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-29-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1) MOXA_GETDATACOUNT is broken at least since commit ecbbfd44a0 (TTY:
move tty buffers to tty_port) in 2012.
Even though it's mentioned in the mon_p moxa utility, obviously noone
ever tried that in that timeframe.
2) The ioctl definition was never exposed to userspace, so noone should
actually be reliably using this.
Provided the above, remove this mxser-special ioctl.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-28-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1) MOXA_CHKPORTENABLE is broken at least since commit ecbbfd44a0 (TTY:
move tty buffers to tty_port) in 2012.
2) The ioctl definition was never exposed to userspace, so noone should
actually be reliably using this.
3) It's not even mentioned in any of the mxser utilities.
Provided the above, remove this mxser-special ioctl.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-27-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1) The semantics are defined exactly nowhere.
2) The ioctl definition was never exposed to userspace, so noone should
actually be reliably using this.
3) It's not even mentioned in any of the mxser utilities.
Provided the above, remove this mxser-special ioctl.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-26-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1) MOXA_ASPP_MON_EXT is broken at least since commit ecbbfd44a0 (TTY:
move tty buffers to tty_port) in 2012.
2) The ioctl definitions were never exposed to userspace, so noone should
actually be reliably using them.
3) They're not even mentioned in any of the mxser utilities.
So remove all these mxser-special ioctls: MOXA_ASPP_MON,
MOXA_ASPP_MON_EXT, and MOXA_SDS_RSTICOUNTER.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-25-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1) The semantics are defined exactly nowhere.
2) The ioctl definition was never exposed to userspace, so noone should
actually be reliably using this.
3) It's not even mentioned in any of the mxser utilities.
Provided the above, remove this mxser-special ioctl.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-24-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* UART_MCR_AFE is a redefinition of serial_reg.h's one.
* UART_LSR_SPECIAL is a redefinition of serial_reg.h's
UART_LSR_BRK_ERROR_BITS.
So remove both and replace the latter uses by already defined
UART_LSR_BRK_ERROR_BITS.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-21-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Make the xmit ring buffer pointers and counter (xmit_head, xmit_tail,
xmit_cnt) unsigned. Now, the assumptions for the compiler are clear --
they cannot be negative.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-20-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In struct mxser_port, all the UART registers and masks, and the xon/xoff
character are stored into int. Let's re-type all these as UART registers
are 8bit (u8) and xon/xoff character is an unsigned char (cc_t in
ktermios).
This save some bytes in memory, but more importantly the change makes it
what it really is.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-19-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
UART_LSR_SPECIAL is composed of UART_LSR_BI, UART_LSR_PE, UART_LSR_FE,
UART_LSR_OE. So status cannot be anything else. Remove the unused else
branch.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-18-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Extract the new handling of receive chars (using the MUST chip
enhancements) into a separate function. This eliminates the need for the
intr_old label and makes the code of mxser_receive_chars more compact.
In the next step, we will extract the old handling too.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-16-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mxser_board::vector_mask is just a bitfield with bits set for all
available ports. We can obtain this value simply by
"BIT(brd->info->nports) - 1" directly in the ISR. So remove vector_mask
and simplify the code a bit.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-15-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The ISR is terrible mix of letters. Let's extract the proper per-port
handling to a separate function called mxser_port_isr. This way, we can
actually see what both mxser_interrupt and mxser_port_isr do now.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-14-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mxser_interrupt is a bit confusing as it passes a pointer to LSR
variable ("status") to mxser_receive_chars. That function can indeed
update the LCR variable. Make this clear by not passing a variable by
reference, instead, return updated status. And change its type
accordingly -- to u8.
Note that the next patches will rework ISR so that even the definition
of status will be u8 soon too.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-13-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
request_irq was passed a board. There is no need to check dev_id and/or
find the appropriate board in the ISR. Neither check if board is NULL.
Remove this nonsense.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-12-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mxser_port::max_baud is actually a board property, not port's. So move
it to mxser_board.
While at it, drop the printk informing about max baud rate during probe.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-11-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
board::uart_type is always set to PORT_16550A. So, use this constant in
the code instead. And drop the mxser_board member.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-10-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Provided the MUST HW ID is an enumeration, define one (enum
mxser_must_hwid) and use it in the code.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-9-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It is named IsMoxaMustChipFlag in the original Moxa's driver. Over the
time, it was reduced to chip_flag which doesn't make much sense. So dub
it again by what it is: must_hwid (mxser_must_get_hwid assigns to it).
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-8-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CheckIsMoxaMust actually finds out what the card is. So rename it to
mxser_must_get_hwid, so that the name conforms to the semantics of the
function.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-7-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Gpci_uart_info structure contains up to tripled information and
chose weird types for the members. Deduplicate the members and choose
proper types for the data -- everything can be u8 except baud rate.
There, we use speed_t, which is used in this context.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-6-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
As mxser.h serves only mxser.c, integrate the definitions into .c and
drop .h. There are some "semi-public" ioctl definitions, but they are
mostly go away in the next patches. If something, they would need to
live in an uapi header anyway.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-5-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There is no reason/desire to print module information upon module load.
Drop this printk (and a version define).
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-4-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
After the ISA cards removal in the previous patch, the mxser_cards array
has holes in it. So renumber the array while updating PCI device's
driver_data.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-3-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
While mxser PCI cards are still around and produced (Moxa provided me
with two recently), ISA cards are obsolete for a long time. I haven't
seen anyone using the cards and the ISA code paths are barely tested.
Hence, remove ISA support from mxser driver so that we can clean the
driver up.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210618061516.662-2-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Adjust the kconfig a little to allow disabling NO_IOMEM in UML. To
make an "allyesconfig" with CONFIG_NO_IOMEM=n build, adjust a few
Kconfig things elsewhere and add dummy asm/fb.h and asm/vga.h files.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
The GLOBETROTTER.cis entry in serial_cs matches more devices than
intended and breaks them. Remove it.
Example: # pccardctl info
PRODID_1="Option International
"
PRODID_2="GSM-Ready 56K/ISDN
"
PRODID_3="021
"
PRODID_4="A
"
MANFID=0013,0000
FUNCID=0
result:
pcmcia 0.0: Direct firmware load for cis/GLOBETROTTER.cis failed with error -2
The GLOBETROTTER.cis is nowhere to be found. There's GLOBETROTTER.cis.ihex at
https://netdev.vger.kernel.narkive.com/h4inqdxM/patch-axnet-cs-fix-phy-id-detection-for-bogus-asix-chip#post41
It's from completely diffetent card:
vers_1 4.1, "Option International", "GSM/GPRS GlobeTrotter", "001", "A"
Signed-off-by: Ondrej Zary <linux@zary.sk>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210611201940.23898-1-linux@zary.sk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Handle custom baud rates requested in the UPF_MAGIC_MULTIPLIER range
with BOTHER. Currently matching is exact, that is if a baud rate that
is not either of clk/4 or clk/8 is requested, then we fall through to
the default case, which will just divide the clock rate by 16 times the
rate requested, round it to closest integer, and possibly yield even
worse results then if clamping to the extra baud rates was chosen.
So for example if we have the usual base rate of 115200 and request a
rate of 230399, then the fall-through divisor calculation will yield 1,
and consequently the baud rate of 115200 will be programmed even though
obviously the magic rate of 230400 would be more appropriate.
Make the selection of the magic rates range-qualified then and use clk/4
for rates from clk/6 up (assuming `serial8250_get_baud_rate' has already
rejected any rates too far beyond clk/4), and otherwise use clk/8 for
rates from clk/12 up, and finally fall through to the standard divisor
calculation. Explicitly void using the undocumented rate of 153600bps
and stick to documented divisor values only.
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2105200232090.29169@angie.orcam.me.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Support for magic baud rate divisors of 32770 and 32769 used with SMSC
Super I/O chips for extra baud rates of 230400 and 460800 respectively
where base rate is 115200[1] has been added around Linux 2.5.64, which
predates our repo history, but the origin could be identified as commit
2a717aad772f ("Merge with Linux 2.5.64.") with the old MIPS/Linux repo
also at: <git://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git>.
Code that is now in `serial8250_do_get_divisor' was added back then to
`serial8250_get_divisor', but that code would only ever trigger if one
of the higher baud rates was actually requested, and that cannot ever
happen, because the earlier call to `serial8250_get_baud_rate' never
returns them. This is because it calls `uart_get_baud_rate' with the
maximum requested being the base rate, that is clk/16 or 115200 for SMSC
chips at their nominal clock rate.
Fix it then and allow UPF_MAGIC_MULTIPLIER baud rates to be selected, by
requesting the maximum baud rate of clk/4 rather than clk/16 if the flag
has been set. Also correct the minimum baud rate, observing that these
ports only support actual (non-magic) divisors of up to 32767 only.
References:
[1] "FDC37M81x, PC98/99 Compliant Enhanced Super I/O Controller with
Keyboard/Mouse Wake-Up", Standard Microsystems Corporation, Rev.
03/27/2000, Table 31 - "Baud Rates", p. 77
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2105190412280.29169@angie.orcam.me.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Contrary to what SMSC documentation says and unlike NS16C550A UARTs the
SMSC Super I/O IC claims compatibility with the SMSC UART implementation
does not support dividing the internal PLL clock by any divisor from 1
to 65535[1], with the exception of two magic divisors of 32769 and 32770
used respectively to select the high-speed data rates of 460800bps and
230400bps[2] if enabled on a port-by-port basis in with the Serial Port
Mode Register in the Device Configuration Space[3][4].
Instead empirical evidence indicates that the divisor, as stored in the
DLL and DLM register pair, has the range of 1 to 32767 only, and bit 7
of the DLM register (bit 15 of the divisor) effectively serves as a
selection bit for the prescaler from the base frequency of 7.3728MHz,
either 4 if the bit is 0, or 1 if the bit is 1 and high-speed operation
has been enabled with the Serial Port Mode Register.
So if high-speed operation has not been enabled, then say the values of
1 and 32769 (0x8001) written into the combined DLL and DLM register pair
both select the divisor of 1 and the baud rate of 115200bps.
[1] "FDC37M81x, PC98/99 Compliant Enhanced Super I/O Controller with
Keyboard/Mouse Wake-Up", Standard Microsystems Corporation, Rev.
03/27/2000, Section "Programmable Baud Rate Generator (and Divisor
Latches DLH, DLL)", p. 75
[2] same, Table 31 - "Baud Rates", p. 77
[3] same, Table 60 - "Serial Port 1, Logical Device 4 [Logical Device
Number = 0x04]", p. 153
[4] same, Table 61 - "Serial Port 2, Logical Device 5 [Logical Device
Number = 0x05]", p. 153
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2106092330530.5469@angie.orcam.me.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oxford Semiconductor PCIe (Tornado) serial port devices are driven by a
fixed 62.5MHz clock input derived from the 100MHz PCI Express clock.
In the enhanced (650) mode, which we select in `autoconfig_has_efr' by
setting the ECB bit in the EFR register, and in the absence of clock
reconfiguration, which we currently don't do, the clock rate is divided
only by the oversampling rate of 16 as it is supplied to the baud rate
generator, yielding the baud base of 3906250. This comes from the reset
values of the TCR and MCR[7] registers which are both zero[1][2][3][4],
choosing the oversampling rate of 16 and the normal (divide by 1) baud
rate generator prescaler respectively. This is the rate that is divided
by the value held in the divisor latch to determine the baud rate used.
Replace the incorrect baud base of 4000000 with the right value of
3906250 then.
References:
[1] "OXPCIe200 PCI Express Multi-Port Bridge", Oxford Semiconductor,
Inc., DS-0045, 10 Nov 2008, Section "Reset Configuration", p. 72
[2] "OXPCIe952 PCI Express Bridge to Dual Serial & Parallel Port",
Oxford Semiconductor, Inc., DS-0046, Mar 06 08, Section "Reset
Configuration", p. 27
[3] "OXPCIe954 PCI Express Bridge to Quad Serial Port", Oxford
Semiconductor, Inc., DS-0047, Feb 08, Section "Reset Configuration",
p. 28
[4] "OXPCIe958 PCI Express Bridge to Octal Serial Port", Oxford
Semiconductor, Inc., DS-0048, Feb 08, Section "Reset Configuration",
p. 28
Fixes: 7106b4e333 ("8250: Oxford Semiconductor Devices")
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2106100203510.5469@angie.orcam.me.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oxford Semiconductor PCIe (Tornado) serial port devices have their baud
base set incorrectly, however their `pciserial_board' entries have been
reused for Titan serial port devices. Define own entries for the latter
devices then, carrying over the settings, so that Oxford entries can be
fixed.
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2106100142310.5469@angie.orcam.me.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In the previous patch, we introduced tty_get_char_size() and
tty_get_frame_size() for computing character and frame sizes,
respectively. Here, we make use of them in various tty drivers where
applicable.
The stats look nice: 12 insertions, 169 deletions.
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: David Lin <dtwlin@gmail.com>
Cc: Johan Hovold <johan@kernel.org>
Cc: Alex Elder <elder@kernel.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Andy Gross <agross@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
Cc: Oliver Neukum <oneukum@suse.com>
Acked-by: Alex Elder <elder@kernel.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210610090247.2593-4-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It's a bit illogical to take magic constants in AUART_LINECTRL_WLEN.
Like in auart_console_get_options(), 2 means 7 bits. Switch
AUART_LINECTRL_WLEN to accept bit length, i.e. let it subtract 5 from
the parameter before doing the logic.
This will ease conversion from CSIZE to bits in mxs_auart_settermios()
in the next patch.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210610090247.2593-2-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Many tty drivers contain code to compute bits count depending on termios
cflags. So extract this code from serial core to two separate tty helper
functions:
* tty_get_char_size -- only size of a character, without flags,
* tty_get_frame_size -- complete size of a frame including flags.
In the next patch, calls to these new functions replace many copies of
this code.
Note that we accept only cflag as a parameter. That's because some
callers like pch_uart_startup or sunsab_console_setup don't have at hand
termios which we could pass around.
Cc: Joe Perches <joe@perches.com>
Cc: Johan Hovold <johan@kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210610090247.2593-1-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It's only set, but never read because commit 01261cb943 ("tty:
ipwireless: Remove tty->closing abort from ipw_open()") removed last use
of tty::closing.
Cc: Jiri Kosina <jikos@kernel.org>
Cc: David Sterba <dsterba@suse.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210610090307.2689-1-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Defer device probe operation when a DMA channel request probe deferral.
With this change both DMA channels are acquired before DMA channels are
configured. Once no probe deferral is expected, DMAs are
configured and any failure in their configuration will make the driver
to fallback to interrupt mode as prior this change.
Signed-off-by: Erwan Le Ray <erwan.leray@foss.st.com>
Signed-off-by: Etienne Carriere <etienne.carriere@foss.st.com>
Link: https://lore.kernel.org/r/20210610100020.2318-1-erwan.leray@foss.st.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Request the RX mailbox only after initializing the UART data
structures. Otherwise it can rarely happen that the receive
callback is called before the UART is ready.
Fixes: 2d908b38d4 ("serial: Add Tegra Combined UART driver")
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Link: https://lore.kernel.org/r/20210609155655.3567545-1-mperttunen@nvidia.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stop dmaengine transfer in sci_stop_tx(). Otherwise, the following
message is possible output when system enters suspend and while
transferring data, because clearing TIE bit in SCSCR is not able to
stop any dmaengine transfer.
sh-sci e6550000.serial: ttySC1: Unable to drain transmitter
Note that this driver has already used some #ifdef in the .c file
so that this patch also uses #ifdef to fix the issue. Otherwise,
build errors happens if the CONFIG_SERIAL_SH_SCI_DMA is disabled.
Fixes: 73a19e4c03 ("serial: sh-sci: Add DMA support.")
Cc: <stable@vger.kernel.org> # v4.9+
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/20210610110806.277932-1-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmDGe+4eHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiG/IUH/iyHVulAtAhL9bnR
qL4M1kWfcG1sKS2TzGRZzo6YiUABf89vFP90r4sKxG3AKrb8YkTwmJr8B/sWwcsv
PpKkXXTobbDfpSrsXGEapBkQOE7h2w739XeXyBLRPkoCR4UrEFn68TV2rLjMLBPS
/EIZkonXLWzzWalgKDP4wSJ7GaQxi3LMx3dGAvbFArEGZ1mPHNlgWy2VokFY/yBf
qh1EZ5rugysc78JCpTqfTf3fUPK2idQW5gtHSMbyESrWwJ/3XXL9o1ET3JWURYf1
b0FgVztzddwgULoIGWLxDH5WWts3l54sjBLj0yrLUlnGKA5FjrZb12g9PdhdywuY
/8KfjeE=
=JfJm
-----END PGP SIGNATURE-----
Merge tag 'v5.13-rc6' into tty-next
We want the tty fixes in here as well.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmDGe+4eHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiG/IUH/iyHVulAtAhL9bnR
qL4M1kWfcG1sKS2TzGRZzo6YiUABf89vFP90r4sKxG3AKrb8YkTwmJr8B/sWwcsv
PpKkXXTobbDfpSrsXGEapBkQOE7h2w739XeXyBLRPkoCR4UrEFn68TV2rLjMLBPS
/EIZkonXLWzzWalgKDP4wSJ7GaQxi3LMx3dGAvbFArEGZ1mPHNlgWy2VokFY/yBf
qh1EZ5rugysc78JCpTqfTf3fUPK2idQW5gtHSMbyESrWwJ/3XXL9o1ET3JWURYf1
b0FgVztzddwgULoIGWLxDH5WWts3l54sjBLj0yrLUlnGKA5FjrZb12g9PdhdywuY
/8KfjeE=
=JfJm
-----END PGP SIGNATURE-----
Merge tag 'v5.13-rc6' into driver-core-next
We need the driver core fix in here as well.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmDGe+4eHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiG/IUH/iyHVulAtAhL9bnR
qL4M1kWfcG1sKS2TzGRZzo6YiUABf89vFP90r4sKxG3AKrb8YkTwmJr8B/sWwcsv
PpKkXXTobbDfpSrsXGEapBkQOE7h2w739XeXyBLRPkoCR4UrEFn68TV2rLjMLBPS
/EIZkonXLWzzWalgKDP4wSJ7GaQxi3LMx3dGAvbFArEGZ1mPHNlgWy2VokFY/yBf
qh1EZ5rugysc78JCpTqfTf3fUPK2idQW5gtHSMbyESrWwJ/3XXL9o1ET3JWURYf1
b0FgVztzddwgULoIGWLxDH5WWts3l54sjBLj0yrLUlnGKA5FjrZb12g9PdhdywuY
/8KfjeE=
=JfJm
-----END PGP SIGNATURE-----
Merge tag 'v5.13-rc6' into char-misc-next
We need the fixes in here as well.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixes the following W=1 kernel build warning(s):
drivers/tty/tty_ldisc.c:63: warning: Excess function
parameter 'disc' description in 'tty_register_ldisc'
drivers/tty/tty_ldisc.c:90: warning: Function parameter or
member 'ldisc' not described in 'tty_unregister_ldisc'
drivers/tty/tty_ldisc.c:90: warning: Excess function
parameter 'disc' description in 'tty_unregister_ldisc'
Signed-off-by: Baokun Li <libaokun1@huawei.com>
Link: https://lore.kernel.org/r/20210608024843.2756746-1-libaokun1@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We would like to use DMI matching in other functions as well.
Hence, extract it as exar_get_platform() helper function.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210608144239.12697-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It's possible that during ->exit() the private_data is NULL,
for instance when there was no GPIO device instantiated.
Due to this we may not dereference it. Add a respective check.
Note, for now ->exit() only makes sense when GPIO device
was instantiated, that's why we may use the check for entire
function.
Fixes: 81171e7d31 ("serial: 8250_exar: Constify the software nodes")
Reported-by: Maxim Levitsky <mlevitsk@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20210608144239.12697-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use DEVICE_ATTR_*() macro helper instead of plain DEVICE_ATTR, which makes
the code a bit shorter and easier to read.
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Link: https://lore.kernel.org/r/20210602014839.10587-1-thunder.leizhen@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add serial support for RZ/G2L SoC with earlycon and
extended mode register support.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://lore.kernel.org/r/20210603221758.10305-11-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove the hack to assign the global console_port variable at probe time.
This assumption that cons->index is -1 is wrong for systems that specify
'console=' in the cmdline (or 'stdout-path' in dts). Hence, on such system
the actual console assignment is ignored, and the first UART that happens
to be probed is used as console instead.
Move the logic to console_setup() and map the console to the correct port
through the array of available ports instead.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Link: https://lore.kernel.org/r/20210528133321.1859346-1-daniel@zonque.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In order to optimize serial communication (performance/throughput VS
latency), we may need to tweak DMA period number and size. This adds
DT properties to configure those values before initialising DMA.
The defaults will stay the same as before.
[update documentation and commit message, rebase to current master,
switch back to DT instead of sysfs]
Signed-off-by: Fabien Lahoudere <fabien.lahoudere@collabora.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://lore.kernel.org/r/20210430175038.103226-2-sebastian.reichel@collabora.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Here are some small fixes for reported problems for tty and serial
drivers for 5.13-rc4.
They consist of:
- 8250 bugfixes and new device support
- lockdown security mode fixup
- syzbot found problems fixed
- 8250_omap fix for interrupt storm
- revert of 8250_omap driver fix as it caused worse problem than
the original issue
All but the last patch have been in linux-next for a while, the last one
is a revert of a problem found in linux-next with the 8250_omap driver
change.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCYLJODQ8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+yna7gCgmKIssymva29JpQb54HuzRooD8jcAn3XeMVWI
E4TQzaTFC1mNAQy8GU4F
=cLjq
-----END PGP SIGNATURE-----
Merge tag 'tty-5.13-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull tty / serial driver fixes from Greg KH:
"Here are some small fixes for reported problems for tty and serial
drivers for 5.13-rc4.
They consist of:
- 8250 bugfixes and new device support
- lockdown security mode fixup
- syzbot found problems fixed
- 8250_omap fix for interrupt storm
- revert of 8250_omap driver fix as it caused worse problem than the
original issue
All but the last patch have been in linux-next for a while, the last
one is a revert of a problem found in linux-next with the 8250_omap
driver change"
* tag 'tty-5.13-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
Revert "serial: 8250: 8250_omap: Fix possible interrupt storm"
serial: 8250_pci: handle FL_NOIRQ board flag
serial: rp2: use 'request_firmware' instead of 'request_firmware_nowait'
serial: 8250_pci: Add support for new HPE serial device
serial: 8250: 8250_omap: Fix possible interrupt storm
serial: 8250: Use BIT(x) for UART_{CAP,BUG}_*
serial: 8250: Add UART_BUG_TXRACE workaround for Aspeed VUART
serial: 8250_dw: Add device HID for new AMD UART controller
serial: sh-sci: Fix off-by-one error in FIFO threshold register setting
serial: core: fix suspicious security_locked_down() call
serial: tegra: Fix a mask operation that is always true
This reverts commit 31fae7c8b1.
Tony writes:
I just noticed this causes the following regression in Linux
next when pressing a key on uart console after boot at least on
omap3. This seems to happen on serial_port_in(port, UART_RX) in
the quirk handling.
So let's drop this.
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/YLCCJzkkB4N7LTQS@atomide.com
Fixes: 31fae7c8b1 ("serial: 8250: 8250_omap: Fix possible interrupt storm")
Reported-by: Tony Lindgren <tony@atomide.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In commit 8428413b1d ("serial: 8250_pci: Implement MSI(-X) support")
the way the irq gets allocated was changed. With that change the
handling FL_NOIRQ got lost. Restore the old behaviour.
Fixes: 8428413b1d ("serial: 8250_pci: Implement MSI(-X) support")
Cc: <stable@vger.kernel.org>
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Link: https://lore.kernel.org/r/20210527095529.26281-1-christian.gmeiner@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The error handling path is broken and we may un-register things that have
never been registered.
Update the loops index accordingly.
Fixes: 9842c38e91 ("kfifo: fix warn_unused_result")
Suggested-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/e28c2e92c7475da25b03d022ea2d6dcf1ba807a2.1621968629.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
hvterm_raw_put_chars() calls hvc_put_chars(), which may return -EAGAIN
when the underlying hcall returns a "busy" status, but udbg_hvc_putc()
doesn't handle this. When using xmon on a PowerVM guest, this can
result in incomplete or garbled output when printing relatively large
amounts of data quickly, such as when dumping the kernel log buffer.
Call again on -EAGAIN.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210514214422.3019105-1-nathanl@linux.ibm.com
Here is a big set of char/misc/other driver fixes for 5.13-rc3.
The majority here is the fallout of the umn.edu re-review of all prior
submissions. That resulted in a bunch of reverts along with the
"correct" changes made, such that there is no regression of any of the
potential fixes that were made by those individuals. I would like to
thank the over 80 different developers who helped with the review and
fixes for this mess.
Other than that, there's a few habanna driver fixes for reported issues,
and some dyndbg fixes for reported problems.
All of these have been in linux-next for a while with no reported
problems.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCYKZCBg8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ynhRQCdGk6ri4oluyn/Z/2KAjvXDOmTmvgAn12VP42d
S1Zmh4qRH2OWaLOBg7c2
=qtxj
-----END PGP SIGNATURE-----
Merge tag 'char-misc-5.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc driver fixes from Greg KH:
"Here is a big set of char/misc/other driver fixes for 5.13-rc3.
The majority here is the fallout of the umn.edu re-review of all prior
submissions. That resulted in a bunch of reverts along with the
"correct" changes made, such that there is no regression of any of the
potential fixes that were made by those individuals. I would like to
thank the over 80 different developers who helped with the review and
fixes for this mess.
Other than that, there's a few habanna driver fixes for reported
issues, and some dyndbg fixes for reported problems.
All of these have been in linux-next for a while with no reported
problems"
* tag 'char-misc-5.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (82 commits)
misc: eeprom: at24: check suspend status before disable regulator
uio_hv_generic: Fix another memory leak in error handling paths
uio_hv_generic: Fix a memory leak in error handling paths
uio/uio_pci_generic: fix return value changed in refactoring
Revert "Revert "ALSA: usx2y: Fix potential NULL pointer dereference""
dyndbg: drop uninformative vpr_info
dyndbg: avoid calling dyndbg_emit_prefix when it has no work
binder: Return EFAULT if we fail BINDER_ENABLE_ONEWAY_SPAM_DETECTION
cdrom: gdrom: initialize global variable at init time
brcmfmac: properly check for bus register errors
Revert "brcmfmac: add a check for the status of usb_register"
video: imsttfb: check for ioremap() failures
Revert "video: imsttfb: fix potential NULL pointer dereferences"
net: liquidio: Add missing null pointer checks
Revert "net: liquidio: fix a NULL pointer dereference"
media: gspca: properly check for errors in po1030_probe()
Revert "media: gspca: Check the return value of write_bridge for timeout"
media: gspca: mt9m111: Check write_bridge for timeout
Revert "media: gspca: mt9m111: Check write_bridge for timeout"
media: dvb: Add check on sp8870_readreg return
...
Add support for new HPE serial device. It is MSI enabled,
but otherwise similar to legacy HP server serial devices.
Tested-by: Jerry Hoemann <jerry.hoemann@hpe.com>
Signed-off-by: Randy Wright <rwright@hpe.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/1621009614-28836-1-git-send-email-rwright@hpe.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It is possible that RX TIMEOUT is signalled after RX FIFO has been
drained, in which case a dummy read of RX FIFO is required to clear RX
TIMEOUT condition. Otherwise, RX TIMEOUT condition is not cleared
leading to an interrupt storm
Cc: stable@vger.kernel.org
Reported-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20210511151955.28071-1-vigneshr@ti.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Aspeed Virtual UARTs directly bridge e.g. the system console UART on the
LPC bus to the UART interface on the BMC's internal APB. As such there's
no RS-232 signalling involved - the UART interfaces on each bus are
directly connected as the producers and consumers of the one set of
FIFOs.
The APB in the AST2600 generally runs at 100MHz while the LPC bus peaks
at 33MHz. The difference in clock speeds exposes a race in the VUART
design where a Tx data burst on the APB interface can result in a byte
lost on the LPC interface. The symptom is LSR[DR] remains clear on the
LPC interface despite data being present in its Rx FIFO, while LSR[THRE]
remains clear on the APB interface as the host has not consumed the data
the BMC has transmitted. In this state, the UART has stalled and no
further data can be transmitted without manual intervention (e.g.
resetting the FIFOs, resulting in loss of data).
The recommended work-around is to insert a read cycle on the APB
interface between writes to THR.
Cc: ChiaWei Wang <chiawei_wang@aspeedtech.com>
Tested-by: ChiaWei Wang <chiawei_wang@aspeedtech.com>
Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210520021334.497341-2-andrew@aj.id.au
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixes the following W=1 kernel build warning(s):
drivers/tty/n_gsm.c:525: warning: expecting prototype for gsm_stuff_packet(). Prototype was for gsm_stuff_frame() instead
drivers/tty/n_gsm.c:1608: warning: expecting prototype for gsm_dlci_control(). Prototype was for gsm_dlci_command() instead
drivers/tty/n_gsm.c:2561: warning: Function parameter or member 'cookie' not described in 'gsmld_read'
drivers/tty/n_gsm.c:2561: warning: Function parameter or member 'offset' not described in 'gsmld_read'
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20210520121906.3468725-11-lee.jones@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixes the following W=1 kernel build warning(s):
drivers/tty/serial/st-asc.c:73: warning: expecting prototype for Some of status comes from higher bits of the character and some come from(). Prototype was for ASC_RXBUF_DUMMY_RX() instead
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jirislaby@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-serial@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20210520121906.3468725-10-lee.jones@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixes the following W=1 kernel build warning(s):
drivers/tty/n_hdlc.c:421: warning: Function parameter or member 'kbuf' not described in 'n_hdlc_tty_read'
drivers/tty/n_hdlc.c:421: warning: Function parameter or member 'cookie' not described in 'n_hdlc_tty_read'
drivers/tty/n_hdlc.c:421: warning: Function parameter or member 'offset' not described in 'n_hdlc_tty_read'
drivers/tty/n_hdlc.c:421: warning: Excess function parameter 'buf' description in 'n_hdlc_tty_read'
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jirislaby@kernel.org>
Cc: Paul Fulghum <paulkf@microgate.com>
Cc: Michael Callahan <callahan@maths.ox.ac.uk>
Cc: Al Longyear <longyear@netcom.com>
Cc: Paul Mackerras <Paul.Mackerras@cs.anu.edu.au>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20210520121906.3468725-9-lee.jones@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixes the following W=1 kernel build warning(s):
drivers/tty/tty_jobctrl.c:33: warning: expecting prototype for tty_check_change(). Prototype was for __tty_check_change() instead
drivers/tty/tty_jobctrl.c:97: warning: expecting prototype for proc_set_tty(). Prototype was for __proc_set_tty() instead
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20210520121906.3468725-7-lee.jones@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixes the following W=1 kernel build warning(s):
drivers/tty/vt/selection.c:119: warning: expecting prototype for set loadlut(). Prototype was for sel_loadlut() instead
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20210520121906.3468725-2-lee.jones@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit f9e053dcfc (tty: Serialize tty flow control changes with
flow_lock) renamed start_tty to __start_tty and stop_tty to __stop_tty
and introduced new start_tty and stop_tty. But it left kernel-doc
comments on the old locations:
tty_io.c:785: warning: expecting prototype for stop_tty(). Prototype was for __stop_tty() instead
tty_io.c:816: warning: expecting prototype for start_tty(). Prototype was for __start_tty() instead
Fix that by moving the comments to appropriate locations.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210519072153.3859-4-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
After commits a9cbbb80e3 (tty: avoid using vfs_iocb_iter_write() for
redirected console writes) and dd78b0c483 (tty: implement read_iter),
the tty_read and tty_write kernel-doc comments don't match the code:
tty_io.c:931: warning: Function parameter or member 'iocb' not described in 'tty_read'
tty_io.c:931: warning: Function parameter or member 'to' not described in 'tty_read'
tty_io.c:931: warning: Excess function parameter 'file' description in 'tty_read'
tty_io.c:931: warning: Excess function parameter 'buf' description in 'tty_read'
tty_io.c:931: warning: Excess function parameter 'count' description in 'tty_read'
tty_io.c:931: warning: Excess function parameter 'ppos' description in 'tty_read'
tty_io.c:1115: warning: Function parameter or member 'iocb' not described in 'file_tty_write'
tty_io.c:1115: warning: Function parameter or member 'from' not described in 'file_tty_write'
tty_io.c:1115: warning: expecting prototype for tty_write(). Prototype was for file_tty_write() instead
Fix them to correspond the reality, i.e. the switch from read/write to
read_iter/write_iter.
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210519072153.3859-3-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
After the previous patch, we can make port passed to
serial8250_find_match_or_unused const. And then we can make const also
port of serial8250_register_8250_port.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210519072153.3859-2-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* make parameters const (as they are only read)
* return bool (as comparison results are returned)
* add \n before final return
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210519072153.3859-1-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Most litex boards using RISC-V soft cores us the sbi earlycon, however
this is not available for non RISC-V litex SoC's. This patch enables
earlycon for liteuart which is available on all Litex SoC's making
support for earycon debugging more widely available.
Cc: Florent Kermarrec <florent@enjoy-digital.fr>
Cc: Mateusz Holenko <mholenko@antmicro.com>
Cc: Joel Stanley <joel@jms.id.au>
Cc: Gabriel L. Somlo <gsomlo@gmail.com>
Reviewed-and-tested-by: Gabriel Somlo <gsomlo@gmail.com>
Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Stafford Horne <shorne@gmail.com>
Link: https://lore.kernel.org/r/20210517115453.24365-1-shorne@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix the following make W=1 kernel build warning:
drivers/tty/pty.c:307: warning: expecting prototype for pty_do_resize(). Prototype was for pty_resize() instead
Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20210518045353.611017-1-yangyingliang@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The variable fd is being initialized with a value that is never
read, it is being updated later on. The assignment is redundant and
can be removed.
Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Addresses-Coverity: ("Unused value")
Link: https://lore.kernel.org/r/20210513221833.137672-1-colin.king@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
