* Re: [PATCHv3 00/10] Nokia H4+ support
From: Rob Herring @ 2017-04-05 18:16 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Marcel Holtmann, Sebastian Reichel, Gustavo F. Padovan,
Johan Hedberg, Samuel Thibault, Pavel Machek, Tony Lindgren,
Jiri Slaby, Mark Rutland, open list:BLUETOOTH DRIVERS,
linux-serial@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, David S. Miller
In-Reply-To: <20170331133353.GA32267@kroah.com>
On Fri, Mar 31, 2017 at 8:33 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Wed, Mar 29, 2017 at 11:33:26PM +0200, Marcel Holtmann wrote:
>> Hi Rob,
>>
>> >> Here is PATCHv3 for the Nokia bluetooth patchset. I addressed all comments from
>> >> Rob and Pavel regarding the serdev patches and dropped the *.dts patches, since
>> >> they were queued by Tony. I also changed the patch order, so that the serdev
>> >> patches come first. All of them have Acked-by from Rob, so I think it makes
>> >> sense to merge them to serdev subsystem (now) and provide an immutable branch
>> >> for the bluetooth subsystem.
>> >
>> > Greg doesn't read cover letters generally and since the serdev patches
>> > are Cc rather than To him, he's probably not planning to pick them up.
>>
>> I wonder actually if we should merge all of these via bluetooth-next
>> tree with proper Ack from Greg. However it would be good to also get
>> buy in from Dave for merging this ultimately through net-next.
>
> I don't really care where it goes. I can take the whole thing in my
> tty/serial tree now if no one objects and I get an ack from the relevant
> maintainers {hint...}
I think it is better if it goes thru BT tree. I have another driver
converted that is dependent on this series. There's a couple other
serdev changes on the list too, but this shouldn't depend on them.
Rob
^ permalink raw reply
* [PATCH 31/38] Annotate hardware config module parameters in drivers/tty/
From: David Howells @ 2017-04-05 17:01 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, gregkh, dhowells, linux-security-module, keyrings,
linux-serial, Jiri Slaby
In-Reply-To: <149141141298.29162.5612793122429261720.stgit@warthog.procyon.org.uk>
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/tty/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: Jiri Slaby <jslaby@suse.com>
cc: linux-serial@vger.kernel.org
---
drivers/tty/cyclades.c | 4 ++--
drivers/tty/moxa.c | 2 +-
drivers/tty/mxser.c | 2 +-
drivers/tty/rocket.c | 10 +++++-----
drivers/tty/serial/8250/8250_core.c | 4 ++--
drivers/tty/synclink.c | 6 +++---
6 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/tty/cyclades.c b/drivers/tty/cyclades.c
index 5e4fa9206861..104f09c58163 100644
--- a/drivers/tty/cyclades.c
+++ b/drivers/tty/cyclades.c
@@ -156,8 +156,8 @@ static unsigned int cy_isa_addresses[] = {
static long maddr[NR_CARDS];
static int irq[NR_CARDS];
-module_param_array(maddr, long, NULL, 0);
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(maddr, long, iomem, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
#endif /* CONFIG_ISA */
diff --git a/drivers/tty/moxa.c b/drivers/tty/moxa.c
index 4caf0c3b1f99..3b251f4e5df0 100644
--- a/drivers/tty/moxa.c
+++ b/drivers/tty/moxa.c
@@ -179,7 +179,7 @@ MODULE_FIRMWARE("c320tunx.cod");
module_param_array(type, uint, NULL, 0);
MODULE_PARM_DESC(type, "card type: C218=2, C320=4");
-module_param_array(baseaddr, ulong, NULL, 0);
+module_param_hw_array(baseaddr, ulong, ioport, NULL, 0);
MODULE_PARM_DESC(baseaddr, "base address");
module_param_array(numports, uint, NULL, 0);
MODULE_PARM_DESC(numports, "numports (ignored for C218)");
diff --git a/drivers/tty/mxser.c b/drivers/tty/mxser.c
index 7b8f383fb090..8bd6fb6d9391 100644
--- a/drivers/tty/mxser.c
+++ b/drivers/tty/mxser.c
@@ -183,7 +183,7 @@ static int ttymajor = MXSERMAJOR;
MODULE_AUTHOR("Casper Yang");
MODULE_DESCRIPTION("MOXA Smartio/Industio Family Multiport Board Device Driver");
-module_param_array(ioaddr, ulong, NULL, 0);
+module_param_hw_array(ioaddr, ulong, ioport, NULL, 0);
MODULE_PARM_DESC(ioaddr, "ISA io addresses to look for a moxa board");
module_param(ttymajor, int, 0);
MODULE_LICENSE("GPL");
diff --git a/drivers/tty/rocket.c b/drivers/tty/rocket.c
index d66c1edd9892..b51a877da986 100644
--- a/drivers/tty/rocket.c
+++ b/drivers/tty/rocket.c
@@ -250,15 +250,15 @@ static int sReadAiopNumChan(WordIO_t io);
MODULE_AUTHOR("Theodore Ts'o");
MODULE_DESCRIPTION("Comtrol RocketPort driver");
-module_param(board1, ulong, 0);
+module_param_hw(board1, ulong, ioport, 0);
MODULE_PARM_DESC(board1, "I/O port for (ISA) board #1");
-module_param(board2, ulong, 0);
+module_param_hw(board2, ulong, ioport, 0);
MODULE_PARM_DESC(board2, "I/O port for (ISA) board #2");
-module_param(board3, ulong, 0);
+module_param_hw(board3, ulong, ioport, 0);
MODULE_PARM_DESC(board3, "I/O port for (ISA) board #3");
-module_param(board4, ulong, 0);
+module_param_hw(board4, ulong, ioport, 0);
MODULE_PARM_DESC(board4, "I/O port for (ISA) board #4");
-module_param(controller, ulong, 0);
+module_param_hw(controller, ulong, ioport, 0);
MODULE_PARM_DESC(controller, "I/O port for (ISA) rocketport controller");
module_param(support_low_speed, bool, 0);
MODULE_PARM_DESC(support_low_speed, "1 means support 50 baud, 0 means support 460400 baud");
diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
index 76e03a7de9cc..89fde17d9617 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -1191,7 +1191,7 @@ module_exit(serial8250_exit);
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Generic 8250/16x50 serial driver");
-module_param(share_irqs, uint, 0644);
+module_param_hw(share_irqs, uint, other, 0644);
MODULE_PARM_DESC(share_irqs, "Share IRQs with other non-8250/16x50 devices (unsafe)");
module_param(nr_uarts, uint, 0644);
@@ -1201,7 +1201,7 @@ module_param(skip_txen_test, uint, 0644);
MODULE_PARM_DESC(skip_txen_test, "Skip checking for the TXEN bug at init time");
#ifdef CONFIG_SERIAL_8250_RSA
-module_param_array(probe_rsa, ulong, &probe_rsa_count, 0444);
+module_param_hw_array(probe_rsa, ulong, ioport, &probe_rsa_count, 0444);
MODULE_PARM_DESC(probe_rsa, "Probe I/O ports for RSA");
#endif
MODULE_ALIAS_CHARDEV_MAJOR(TTY_MAJOR);
diff --git a/drivers/tty/synclink.c b/drivers/tty/synclink.c
index 657eed82eeb3..a2c308f7d637 100644
--- a/drivers/tty/synclink.c
+++ b/drivers/tty/synclink.c
@@ -869,9 +869,9 @@ static int txholdbufs[MAX_TOTAL_DEVICES];
module_param(break_on_load, bool, 0);
module_param(ttymajor, int, 0);
-module_param_array(io, int, NULL, 0);
-module_param_array(irq, int, NULL, 0);
-module_param_array(dma, int, NULL, 0);
+module_param_hw_array(io, int, ioport, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
+module_param_hw_array(dma, int, dma, NULL, 0);
module_param(debug_level, int, 0);
module_param_array(maxframe, int, NULL, 0);
module_param_array(txdmabufs, int, NULL, 0);
^ permalink raw reply related
* Re: No output on console despite ignore_loglevel earlyprintk
From: Marc Gonzalez @ 2017-04-05 16:37 UTC (permalink / raw)
To: Russell King - ARM Linux, Andreas Farber
Cc: Rob Herring, Peter Hurley, Arnd Bergmann, Greg Kroah-Hartman,
Thibaud Cornic, linux-serial, Linux ARM
In-Reply-To: <20170303174643.GQ21222@n2100.armlinux.org.uk>
On 03/03/2017 18:46, Russell King - ARM Linux wrote:
> On Fri, Mar 03, 2017 at 06:26:28PM +0100, Andreas Färber wrote:
>
>> Am 03.03.2017 um 17:55 schrieb Russell King - ARM Linux:
>>
>>> On Fri, Mar 03, 2017 at 05:42:02PM +0100, Marc Gonzalez wrote:
>>>
>>>> I'm confused about early consoles and earlyprintk, and all that good stuff.
>>>> When my kernel panics, I don't get the expected output.
>>>>
>>>> Using "mem=256M ignore_loglevel earlyprintk"
>>>>
>>>> [ 0.014325] Console: colour dummy device 80x30
>>>> [ 0.018885] console [tty0] enabled
>>>> [ 0.022396] bootconsole [earlycon0] disabled
>>>>
>>>> And it hangs there.
>>>
>>> tty0 is the kernel virtual terminal console, which is what appears on
>>> VGA or framebuffers. This is the default console if nothing else is
>>> specified.
>>>
>>> What happened here is that the virtual terminal console registered, was
>>> detected to be the system console, so early console was shut down, and
>>> the boot messages logged to the virtual terminal console instead.
>>
>> Why does passing console= make a difference though?
>>
>> I expect stdout-path to have the same effect as the command line, and I
>> am pretty sure that that was previous behavior in, e.g., v4.4.
>>
>> Note that I am using earlycon, as opposed to earlyprintk above.
>
> The property is:
>
> stdout-path = "dt-node-name:hw-parameters";
>
> and this is parsed by the code in drivers/of/fdt.c,
> early_init_dt_scan_chosen_stdout() (briefly):
>
> offset = fdt_path_offset(fdt, "/chosen");
> p = fdt_getprop(fdt, offset, "stdout-path", &l);
>
> q = strchrnul(p, ':');
> if (*q != '\0')
> options = q + 1;
> l = q - p;
>
> /* Get the node specified by stdout-path */
> offset = fdt_path_offset_namelen(fdt, p, l);
> if (offset < 0) {
> pr_warn("earlycon: stdout-path %.*s not found\n", l, p);
>
> So here, offset points at the node named by "dt-node-name" above.
>
> This function then tries to patch the specified node's compatible with
> the drivers in the __earlycon_table:
>
> for (match = __earlycon_table; match < __earlycon_table_end; match++) {
> if (!match->compatible[0])
> continue;
>
> if (fdt_node_check_compatible(fdt, offset, match->compatible))
> continue;
>
> and when a match is found, calls:
>
> of_setup_earlycon(match, offset, options);
>
> Here, we go into the code in drivers/tty/serial/earlycon.c, which reads
> the standard properties (like "reg", etc) filling out a uart_port
> before calling the early console's ->setup method. If everything goes
> to plan, register_console() is called to register the early console.
>
> So there's nothing there which changes the default system console.
>
> The next place is of_alias_scan() in drivers/of/base.c. This records
> the device_node and options in of_stdout and of_stdout_options
> respectively - it, again, does not change the default system console.
>
> When a serial console is initialised, of_console_check() gets called by
> serial core to check whether the DT node for it is "of_stdout", and if
> it matches, it modifies the preferred system console.
>
> This all looks good, and one might expect that it has the desired
> effect, but this code is fatally flawed in design: the point at which
> of_console_check() gets called is _way_ after consoles like the virtual
> terminal console get initialised. What this means is that, at the point
> in time that the virtual terminal is initialised, as far as the console
> system is concerned, the preferred console is still the virtual terminal.
> It knows nothing about the desire for a different console.
>
> Given the current console handling, it's not easy to solve without
> overhauling the way consoles are chosen - the root problem is that the
> Linux console system works via Linux device driver names and indexes,
> and there's no easy way to translate a DT stdout-path property to a
> Linux device driver name and index without the driver having been
> initialised.
Time for me to take another stab at this issue.
Relevant parts of my DT:
aliases { serial = &uart; };
chosen { stdout-path = "serial:115200n8"; };
uart: serial@10700 {
compatible = "ralink,rt2880-uart";
reg = <0x10700 0x30>;
interrupts = <1 IRQ_TYPE_LEVEL_HIGH>;
clock-frequency = <7372800>;
reg-shift = <2>;
};
Relevant part of my kernel config:
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_GENERIC_EARLY_IOREMAP=y
CONFIG_OF_EARLY_FLATTREE=y
#
# Character devices
#
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_SERIAL_NONSTANDARD is not set
#
# Serial drivers
#
CONFIG_SERIAL_EARLYCON=y
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
# CONFIG_SERIAL_8250_FINTEK is not set
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_DMA=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set
CONFIG_SERIAL_8250_FSL=y
# CONFIG_SERIAL_8250_DW is not set
# CONFIG_SERIAL_8250_EM is not set
CONFIG_SERIAL_8250_RT288X=y
# CONFIG_SERIAL_8250_MOXA is not set
CONFIG_SERIAL_OF_PLATFORM=y
#
# Non-8250 serial port support
#
# CONFIG_SERIAL_EARLYCON_ARM_SEMIHOST is not set
# CONFIG_SERIAL_UARTLITE is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_SC16IS7XX is not set
# CONFIG_SERIAL_BCM63XX is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_SERIAL_RP2 is not set
# CONFIG_SERIAL_FSL_LPUART is not set
# CONFIG_SERIAL_CONEXANT_DIGICOLOR is not set
# CONFIG_SERIAL_ST_ASC is not set
# CONFIG_SERIAL_STM32 is not set
# CONFIG_HVC_DCC is not set
# CONFIG_IPMI_HANDLER is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
CONFIG_DEVPORT=y
# CONFIG_XILLYBUS is not set
CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S"
# CONFIG_DEBUG_UART_8250 is not set
CONFIG_UNCOMPRESS_INCLUDE="debug/uncompress.h"
Booting with mem=256M console=ttyS0,115200
[ 0.000213] Console: colour dummy device 80x30
[ 0.418383] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[ 0.419837] console [ttyS0] disabled
[ 0.419983] 10700.serial: ttyS0 at MMIO 0x10700 (irq = 20, base_baud = 460800) is a Palmchip BK-3103
[ 1.000504] console [ttyS0] enabled
Booting with mem=256M
[ 0.000212] Console: colour dummy device 80x30
[ 0.000547] console [tty0] enabled
[ 0.427260] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[ 0.428970] 10700.serial: ttyS0 at MMIO 0x10700 (irq = 20, base_baud = 460800) is a Palmchip BK-3103
[ 1.007672] console [ttyS0] enabled
Booting with mem=256M earlycon
[ 0.000000] ENTER param_setup_earlycon
[ 0.000000] ENTER early_init_dt_scan_chosen_stdout
[ 0.000000] early_init_dt_scan_chosen_stdout: scan __earlycon_table
[ 0.000000] name=uart compatible=snps,dw-apb-uart setup=early_serial8250_setup
[ 0.000000] name=uart compatible=nvidia,tegra20-uart setup=early_serial8250_setup
[ 0.000000] name=ns16550a compatible=ns16550a setup=early_serial8250_setup
[ 0.000000] name=ns16550 compatible=ns16550 setup=early_serial8250_setup
[ 0.000000] early_init_dt_scan_chosen_stdout: NO MATCH, return ENODEV
[ 0.000000] Malformed early option 'earlycon'
[ 0.000215] Console: colour dummy device 80x30
[ 0.000583] console [tty0] enabled
[ 0.420043] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[ 0.421945] 10700.serial: ttyS0 at MMIO 0x10700 (irq = 20, base_baud = 460800) is a Palmchip BK-3103
[ 1.014251] console [ttyS0] enabled
drivers/tty/serial/8250/8250_early.c
int __init early_serial8250_setup(struct earlycon_device *device, const char *options)
EARLYCON_DECLARE(uart8250, early_serial8250_setup);
EARLYCON_DECLARE(uart, early_serial8250_setup);
OF_EARLYCON_DECLARE(ns16550, "ns16550", early_serial8250_setup);
OF_EARLYCON_DECLARE(ns16550a, "ns16550a", early_serial8250_setup);
OF_EARLYCON_DECLARE(uart, "nvidia,tegra20-uart", early_serial8250_setup);
OF_EARLYCON_DECLARE(uart, "snps,dw-apb-uart", early_serial8250_setup);
I'm not matching anything, because my UART compatible string is:
uart: serial@10700 {
compatible = "ralink,rt2880-uart";
If I append "ns16550a" or "ns16550", the kernel hangs from the start:
Starting kernel ...
@
But if I add DEBUG_LL support with
CONFIG_DEBUG_LL=y
CONFIG_DEBUG_LL_UART_8250=y
CONFIG_DEBUG_UART_PHYS=0x10700
CONFIG_DEBUG_UART_VIRT=0xf0010700
CONFIG_DEBUG_UART_8250_WORD=y
CONFIG_DEBUG_UART_8250_PALMCHIP=y
and replace the implementation of vprintk_emit() with a very quick and dirty
char buf[400];
extern void printascii(const char *);
text_len = vsnprintf(buf, sizeof buf, fmt, args);
printascii(buf);
return text_len;
then the kernel boots correctly, and I see the following relevant logs:
ENTER param_setup_earlycon
ENTER early_init_dt_scan_chosen_stdout
early_init_dt_scan_chosen_stdout: scan __earlycon_table
name=uart compatible=snps,dw-apb-uart setup=early_serial8250_setup
name=uart compatible=nvidia,tegra20-uart setup=early_serial8250_setup
name=ns16550a compatible=ns16550a setup=early_serial8250_setup
ENTER of_setup_earlycon
earlycon: ns16550a0 at MMIO 0x00010700 (options '115200n8')
bootconsole [ns16550a0] enabled
Kernel command line: mem=256M earlycon
Console: colour dummy device 80x30
console [tty0] enabled
bootconsole [ns16550a0] disabled
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
10700.serial: ttyS0 at MMIO 0x10700 (irq = 20, base_baud = 460800) is a Palmchip BK-3103
console [ttyS0] enabled
I think the problem is that my UART (Palmchip BK-3103) requires
custom accessors to read/write 16550 registers. And these accessors
are probably ignored this early in the boot.
drivers/tty/serial/8250/8250_port.c
#ifdef CONFIG_SERIAL_8250_RT288X
/* Au1x00/RT288x UART hardware has a weird register layout */
static const s8 au_io_in_map[8] = {
0, /* UART_RX */
2, /* UART_IER */
3, /* UART_IIR */
5, /* UART_LCR */
6, /* UART_MCR */
7, /* UART_LSR */
8, /* UART_MSR */
-1, /* UART_SCR (unmapped) */
};
It is likely that I need to register a specific OF_EARLYCON_DECLARE,
like OMAP did?
Regards.
^ permalink raw reply
* Re: No output on console despite ignore_loglevel earlyprintk
From: Marc Gonzalez @ 2017-04-05 14:02 UTC (permalink / raw)
To: Russell King - ARM Linux, Andreas Farber
Cc: Peter Hurley, Arnd Bergmann, Greg Kroah-Hartman, Thibaud Cornic,
linux-serial, Linux ARM
In-Reply-To: <20170303174643.GQ21222@n2100.armlinux.org.uk>
On 03/03/2017 18:46, Russell King - ARM Linux wrote:
> On Fri, Mar 03, 2017 at 06:26:28PM +0100, Andreas Färber wrote:
>> Am 03.03.2017 um 17:55 schrieb Russell King - ARM Linux:
>>> On Fri, Mar 03, 2017 at 05:42:02PM +0100, Marc Gonzalez wrote:
>>>> I'm confused about early consoles and earlyprintk, and all that good stuff.
>>>> When my kernel panics, I don't get the expected output.
>>>>
>>>> Using "mem=256M ignore_loglevel earlyprintk"
>>>>
>> [...]
>>>> [ 0.014325] Console: colour dummy device 80x30
>>>> [ 0.018885] console [tty0] enabled
>>>> [ 0.022396] bootconsole [earlycon0] disabled
>>>>
>>>> And it hangs there.
>>>
>>> tty0 is the kernel virtual terminal console, which is what appears on
>>> VGA or framebuffers. This is the default console if nothing else is
>>> specified.
>>>
>>> What happened here is that the virtual terminal console registered, was
>>> detected to be the system console, so early console was shut down, and
>>> the boot messages logged to the virtual terminal console instead.
>>
>> Why does passing console= make a difference though?
>>
>> I expect stdout-path to have the same effect as the command line, and I
>> am pretty sure that that was previous behavior in, e.g., v4.4.
>>
>> Note that I am using earlycon, as opposed to earlyprintk above.
>
> The property is:
>
> stdout-path = "dt-node-name:hw-parameters";
>
> and this is parsed by the code in drivers/of/fdt.c,
> early_init_dt_scan_chosen_stdout() (briefly):
>
> offset = fdt_path_offset(fdt, "/chosen");
> p = fdt_getprop(fdt, offset, "stdout-path", &l);
>
> q = strchrnul(p, ':');
> if (*q != '\0')
> options = q + 1;
> l = q - p;
>
> /* Get the node specified by stdout-path */
> offset = fdt_path_offset_namelen(fdt, p, l);
> if (offset < 0) {
> pr_warn("earlycon: stdout-path %.*s not found\n", l, p);
>
> So here, offset points at the node named by "dt-node-name" above.
>
> This function then tries to patch the specified node's compatible with
> the drivers in the __earlycon_table:
>
> for (match = __earlycon_table; match < __earlycon_table_end; match++) {
> if (!match->compatible[0])
> continue;
>
> if (fdt_node_check_compatible(fdt, offset, match->compatible))
> continue;
>
> and when a match is found, calls:
>
> of_setup_earlycon(match, offset, options);
>
> Here, we go into the code in drivers/tty/serial/earlycon.c, which reads
> the standard properties (like "reg", etc) filling out a uart_port
> before calling the early console's ->setup method. If everything goes
> to plan, register_console() is called to register the early console.
>
> So there's nothing there which changes the default system console.
>
> The next place is of_alias_scan() in drivers/of/base.c. This records
> the device_node and options in of_stdout and of_stdout_options
> respectively - it, again, does not change the default system console.
>
> When a serial console is initialised, of_console_check() gets called by
> serial core to check whether the DT node for it is "of_stdout", and if
> it matches, it modifies the preferred system console.
>
> This all looks good, and one might expect that it has the desired
> effect, but this code is fatally flawed in design: the point at which
> of_console_check() gets called is _way_ after consoles like the virtual
> terminal console get initialised. What this means is that, at the point
> in time that the virtual terminal is initialised, as far as the console
> system is concerned, the preferred console is still the virtual terminal.
> It knows nothing about the desire for a different console.
>
> Given the current console handling, it's not easy to solve without
> overhauling the way consoles are chosen - the root problem is that the
> Linux console system works via Linux device driver names and indexes,
> and there's no easy way to translate a DT stdout-path property to a
> Linux device driver name and index without the driver having been
> initialised.
One issue with earlyprintk is that one must hard-code the UART address
directly into the kernel binary. If I build one kernel for two different
boards that don't have the same UART address, I'm going to run into
problems, right?
Is early console a better solution for this use-case?
Regards.
^ permalink raw reply
* Re: [PATCH v2 2/2] drivers/serial: Add driver for Aspeed virtual UART
From: Andy Shevchenko @ 2017-04-05 10:54 UTC (permalink / raw)
To: Joel Stanley
Cc: Greg Kroah-Hartman, Jiri Slaby, Mark Rutland, Rob Herring,
Jeremy Kerr, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree, Benjamin Herrenschmidt,
openbmc
In-Reply-To: <20170405040352.5661-3-joel@jms.id.au>
On Wed, Apr 5, 2017 at 7:03 AM, Joel Stanley <joel@jms.id.au> wrote:
> From: Jeremy Kerr <jk@ozlabs.org>
>
> This change adds a driver for the 16550-based Aspeed virtual UART
> device. We use a similar process to the of_serial driver for device
> probe, but expose some VUART-specific functions through sysfs too.
I would go with vUART abbreviation, but it's up to you.
>
> The VUART is two UART 'front ends' connected by their FIFO (no actual
> serial line in between). One is on the BMC side (management controller)
> and one is on the host CPU side.
>
> This driver is for the BMC side. The sysfs files allow the BMC
> userspace, which owns the system configuration policy, to specify at
> what IO port and interrupt number the host side will appear to the host
> on the Host <-> BMC LPC bus. It could be different on a different system
> (though most of them use 3f8/4).
>
> OpenPOWER host firmware doesn't like it when the host-side of the
> VUART's FIFO is not drained. This driver only disables host TX discard
> mode when the port is in use. We set the VUART enabled bit when we bind
> to the device, and clear it on unbind.
>
> We don't want to do this on open/release, as the host may be using this
> bit to configure serial output modes, which is independent of whether
> the devices has been opened by BMC userspace.
> - Move to 8250 directory
> - Rename ast -> aspeed to match other Aspeed drivers
> drivers/tty/serial/8250/aspeed-vuart.c | 341 +++++++++++++++++++++
There is a pattern 8250_x[_y].c
So, I would go with 8250_aspeed_virt.c or 8250_aspeed_vuart.c or alike.
> +config SERIAL_8250_ASPEED_VUART
> + tristate "Aspeed Virtual UART"
> + depends on SERIAL_8250
> + depends on OF
> + * 2 of the License, or (at your option) any later version.
> + *
Redundant line.
> + */
> +#include <linux/device.h>
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_platform.h>
> +#include <linux/clk.h>
> +static void aspeed_vuart_set_host_tx_discard(struct aspeed_vuart *vuart,
> + bool discard)
> +{
> + u8 reg;
> +
> + reg = readb(vuart->regs + ASPEED_VUART_GCRA);
> +
> + /* if the HOST_TX_DISCARD bit is set, discard is *disabled* */
Perhaps "disabled" for better readability?
> + reg &= ~ASPEED_VUART_GCRA_HOST_TX_DISCARD;
> + if (!discard)
> + reg |= ASPEED_VUART_GCRA_HOST_TX_DISCARD;
> +
> + writeb(reg, vuart->regs + ASPEED_VUART_GCRA);
> +}
> +static int aspeed_vuart_probe(struct platform_device *pdev)
> +{
> + struct uart_8250_port port;
> + struct resource *res;
> + struct aspeed_vuart *vuart;
> + struct device_node *np;
Longest line upper.
> + u32 clk, prop;
> + int rc;
> +
> + np = pdev->dev.of_node;
> +
> + vuart = devm_kzalloc(&pdev->dev, sizeof(*vuart), GFP_KERNEL);
> + if (!vuart)
> + return -ENOMEM;
> +
> + vuart->dev = &pdev->dev;
> +
> + /* The 8510 core creates the mapping, which we grab a reference to
> + * for VUART-specific registers */
/*
* Multi-line comments.
* Look like this.
*/
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + vuart->regs = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(vuart->regs))
> + return PTR_ERR(vuart->regs);
> +
> + memset(&port, 0, sizeof(port));
> + port.port.private_data = vuart;
> + port.port.membase = vuart->regs;
> + port.port.mapbase = res->start;
> + port.port.mapsize = resource_size(res);
> + port.port.startup = aspeed_vuart_startup;
> + port.port.shutdown = aspeed_vuart_shutdown;
> + port.port.dev = &pdev->dev;
> +
> + rc = sysfs_create_group(&vuart->dev->kobj, &aspeed_vuart_attr_group);
> + if (rc < 0)
> + return rc;
> +
> + if (of_property_read_u32(np, "clock-frequency", &clk)) {
> + vuart->clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(vuart->clk)) {
> + dev_warn(&pdev->dev,
> + "clk or clock-frequency not defined\n");
> + return PTR_ERR(vuart->clk);
> + }
> +
> + rc = clk_prepare_enable(vuart->clk);
> + if (rc < 0)
> + return rc;
> +
> + clk = clk_get_rate(vuart->clk);
> + }
> +
> + /* If current-speed was set, then try not to change it. */
> + if (of_property_read_u32(np, "current-speed", &prop) == 0)
> + port.port.custom_divisor = clk / (16 * prop);
> +
> + /* Check for shifted address mapping */
> + if (of_property_read_u32(np, "reg-offset", &prop) == 0)
> + port.port.mapbase += prop;
> +
> + /* Check for registers offset within the devices address range */
> + if (of_property_read_u32(np, "reg-shift", &prop) == 0)
> + port.port.regshift = prop;
> +
> + /* Check for fifo size */
> + if (of_property_read_u32(np, "fifo-size", &prop) == 0)
> + port.port.fifosize = prop;
> +
> + /* Check for a fixed line number */
> + rc = of_alias_get_id(np, "serial");
> + if (rc >= 0)
> + port.port.line = rc;
> +
> + port.port.irq = irq_of_parse_and_map(np, 0);
Isn't better to get this via platform_get_irq() ?
> + port.port.irqflags = IRQF_SHARED;
> + port.port.iotype = UPIO_MEM;
> + if (of_property_read_u32(np, "reg-io-width", &prop) == 0) {
I would still go with usual pattern.
> + switch (prop) {
> + case 1:
> + port.port.iotype = UPIO_MEM;
> + break;
> + case 4:
> + port.port.iotype = of_device_is_big_endian(np) ?
> + UPIO_MEM32BE : UPIO_MEM32;
Hmm... And this one is not in align with IO accessors used in this
driver. (readx()/writex() are little endian IO accessors).
> + break;
> + default:
> + dev_warn(&pdev->dev, "unsupported reg-io-width (%d)\n",
> + prop);
> + rc = -EINVAL;
> + goto err_clk_disable;
> + }
> + }
> +
> + port.port.type = PORT_16550A;
> + port.port.uartclk = clk;
> + port.port.flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF
> + | UPF_FIXED_PORT | UPF_FIXED_TYPE | UPF_NO_THRE_TEST;
> +
> + if (of_property_read_bool(np, "no-loopback-test"))
> + port.port.flags |= UPF_SKIP_TEST;
> +
> + if (port.port.fifosize)
> + port.capabilities = UART_CAP_FIFO;
> +
> + if (of_property_read_bool(np, "auto-flow-control"))
> + port.capabilities |= UART_CAP_AFE;
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 1/2] serial: 8250: Add flag so drivers can avoid THRE probe
From: Andy Shevchenko @ 2017-04-05 10:36 UTC (permalink / raw)
To: Joel Stanley
Cc: Greg Kroah-Hartman, Jiri Slaby, Mark Rutland, Rob Herring,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree,
Benjamin Herrenschmidt, Jeremy Kerr,
openbmc-uLR06cmDAlY/bJ5BZ2RsiQ
In-Reply-To: <20170405040352.5661-2-joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
On Wed, Apr 5, 2017 at 7:03 AM, Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org> wrote:
> The probing of THRE irq behaviour assumes the other end will be reading
> bytes out of the buffer in order to probe the port at driver init. In
> some cases the other end cannot be relied upon to read these bytes, so
> provide a flag for them to skip this step.
>
> Bit 16 was chosen as the flags are a int and the top bits are taken.
19 ?
>
> Acked-by: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> Signed-off-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
> ---
> drivers/tty/serial/8250/8250_port.c | 2 +-
> include/linux/serial_core.h | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
> index 6119516ef5fc..60a6c247340f 100644
> --- a/drivers/tty/serial/8250/8250_port.c
> +++ b/drivers/tty/serial/8250/8250_port.c
> @@ -2229,7 +2229,7 @@ int serial8250_do_startup(struct uart_port *port)
> }
> }
>
> - if (port->irq) {
> + if (port->irq && !(up->port.flags & UPF_NO_THRE_TEST)) {
> unsigned char iir1;
> /*
> * Test for UARTs that do not reassert THRE when the
> diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
> index 58484fb35cc8..260245deec94 100644
> --- a/include/linux/serial_core.h
> +++ b/include/linux/serial_core.h
> @@ -195,6 +195,7 @@ struct uart_port {
> #define UPF_NO_TXEN_TEST ((__force upf_t) (1 << 15))
> #define UPF_MAGIC_MULTIPLIER ((__force upf_t) ASYNC_MAGIC_MULTIPLIER /* 16 */ )
>
> +#define UPF_NO_THRE_TEST ((__force upf_t) (1 << 19))
> /* Port has hardware-assisted h/w flow control */
> #define UPF_AUTO_CTS ((__force upf_t) (1 << 20))
> #define UPF_AUTO_RTS ((__force upf_t) (1 << 21))
> --
> 2.11.0
>
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 2/2] drivers/serial: Add driver for Aspeed virtual UART
From: Joel Stanley @ 2017-04-05 4:03 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Mark Rutland, Rob Herring
Cc: Jeremy Kerr, linux-serial, linux-kernel, devicetree,
Andy Shevchenko, Benjamin Herrenschmidt, openbmc
In-Reply-To: <20170405040352.5661-1-joel@jms.id.au>
From: Jeremy Kerr <jk@ozlabs.org>
This change adds a driver for the 16550-based Aspeed virtual UART
device. We use a similar process to the of_serial driver for device
probe, but expose some VUART-specific functions through sysfs too.
The VUART is two UART 'front ends' connected by their FIFO (no actual
serial line in between). One is on the BMC side (management controller)
and one is on the host CPU side.
This driver is for the BMC side. The sysfs files allow the BMC
userspace, which owns the system configuration policy, to specify at
what IO port and interrupt number the host side will appear to the host
on the Host <-> BMC LPC bus. It could be different on a different system
(though most of them use 3f8/4).
OpenPOWER host firmware doesn't like it when the host-side of the
VUART's FIFO is not drained. This driver only disables host TX discard
mode when the port is in use. We set the VUART enabled bit when we bind
to the device, and clear it on unbind.
We don't want to do this on open/release, as the host may be using this
bit to configure serial output modes, which is independent of whether
the devices has been opened by BMC userspace.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Acked-by: Rob Herring <robh@kernel.org>
---
v2:
- Use attribute groups and DEVICE_ATTR_RW
- Use platform_get_resource/devm_ioremap_resource
- of_find_property -> of_property_read_bool
- Drop unncessary 0xff mask
- Fix comment style
- Use BIT and GENMASK where pssible
- Move to 8250 directory
- Rename ast -> aspeed to match other Aspeed drivers
- Add documentation of sysfs file
- Add detail to the commit message
- add Rob's ack for the binding change
---
Documentation/ABI/stable/sysfs-driver-aspeed-vuart | 15 +
Documentation/devicetree/bindings/serial/8250.txt | 2 +
drivers/tty/serial/8250/Kconfig | 10 +
drivers/tty/serial/8250/Makefile | 1 +
drivers/tty/serial/8250/aspeed-vuart.c | 341 +++++++++++++++++++++
5 files changed, 369 insertions(+)
create mode 100644 Documentation/ABI/stable/sysfs-driver-aspeed-vuart
create mode 100644 drivers/tty/serial/8250/aspeed-vuart.c
diff --git a/Documentation/ABI/stable/sysfs-driver-aspeed-vuart b/Documentation/ABI/stable/sysfs-driver-aspeed-vuart
new file mode 100644
index 000000000000..8062953ce77b
--- /dev/null
+++ b/Documentation/ABI/stable/sysfs-driver-aspeed-vuart
@@ -0,0 +1,15 @@
+What: /sys/bus/platform/drivers/aspeed-vuart/*/lpc_address
+Date: April 2017
+Contact: Jeremy Kerr <jk@ozlabs.org>
+Description: Configures which IO port the host side of the UART
+ will appear on the host <-> BMC LPC bus.
+Users: OpenBMC. Proposed changes should be mailed to
+ openbmc@lists.ozlabs.org
+
+What: /sys/bus/platform/drivers/aspeed-vuart*/sirq
+Date: April 2017
+Contact: Jeremy Kerr <jk@ozlabs.org>
+Description: Configures which interrupt number the host side of
+ the UART will appear on the host <-> BMC LPC bus.
+Users: OpenBMC. Proposed changes should be mailed to
+ openbmc@lists.ozlabs.org
diff --git a/Documentation/devicetree/bindings/serial/8250.txt b/Documentation/devicetree/bindings/serial/8250.txt
index 10276a46ecef..656733949309 100644
--- a/Documentation/devicetree/bindings/serial/8250.txt
+++ b/Documentation/devicetree/bindings/serial/8250.txt
@@ -20,6 +20,8 @@ Required properties:
- "fsl,16550-FIFO64"
- "fsl,ns16550"
- "ti,da830-uart"
+ - "aspeed,ast2400-vuart"
+ - "aspeed,ast2500-vuart"
- "serial" if the port type is unknown.
- reg : offset and length of the register set for the device.
- interrupts : should contain uart interrupt.
diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
index a65fb8197aec..fb217f02ec94 100644
--- a/drivers/tty/serial/8250/Kconfig
+++ b/drivers/tty/serial/8250/Kconfig
@@ -220,6 +220,16 @@ config SERIAL_8250_ACCENT
To compile this driver as a module, choose M here: the module
will be called 8250_accent.
+config SERIAL_8250_ASPEED_VUART
+ tristate "Aspeed Virtual UART"
+ depends on SERIAL_8250
+ depends on OF
+ help
+ If you want to use the virtual UART (VUART) device on Aspeed
+ BMC platforms, enable this option. This enables the 16550A-
+ compatible device on the local LPC bus, giving a UART device
+ with no physical RS232 connections.
+
config SERIAL_8250_BOCA
tristate "Support Boca cards"
depends on SERIAL_8250 != n && ISA && SERIAL_8250_MANY_PORTS
diff --git a/drivers/tty/serial/8250/Makefile b/drivers/tty/serial/8250/Makefile
index 2f30f9ecdb1b..405d720b51c7 100644
--- a/drivers/tty/serial/8250/Makefile
+++ b/drivers/tty/serial/8250/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_SERIAL_8250_EXAR) += 8250_exar.o
obj-$(CONFIG_SERIAL_8250_HP300) += 8250_hp300.o
obj-$(CONFIG_SERIAL_8250_CS) += serial_cs.o
obj-$(CONFIG_SERIAL_8250_ACORN) += 8250_acorn.o
+obj-$(CONFIG_SERIAL_8250_ASPEED_VUART) += aspeed-vuart.o
obj-$(CONFIG_SERIAL_8250_BCM2835AUX) += 8250_bcm2835aux.o
obj-$(CONFIG_SERIAL_8250_CONSOLE) += 8250_early.o
obj-$(CONFIG_SERIAL_8250_FOURPORT) += 8250_fourport.o
diff --git a/drivers/tty/serial/8250/aspeed-vuart.c b/drivers/tty/serial/8250/aspeed-vuart.c
new file mode 100644
index 000000000000..261b3dbaa7c1
--- /dev/null
+++ b/drivers/tty/serial/8250/aspeed-vuart.c
@@ -0,0 +1,341 @@
+/*
+ * Serial Port driver for Aspeed VUART device
+ *
+ * Copyright (C) 2016 Jeremy Kerr <jk@ozlabs.org>, IBM Corp.
+ * Copyright (C) 2006 Arnd Bergmann <arnd@arndb.de>, IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ */
+#include <linux/device.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/clk.h>
+
+#include "8250.h"
+
+#define ASPEED_VUART_GCRA 0x20
+#define ASPEED_VUART_GCRA_VUART_EN BIT(0)
+#define ASPEED_VUART_GCRA_HOST_TX_DISCARD BIT(5)
+#define ASPEED_VUART_GCRB 0x24
+#define ASPEED_VUART_GCRB_HOST_SIRQ_MASK GENMASK(7, 4)
+#define ASPEED_VUART_GCRB_HOST_SIRQ_SHIFT 4
+#define ASPEED_VUART_ADDRL 0x28
+#define ASPEED_VUART_ADDRH 0x2c
+
+struct aspeed_vuart {
+ struct device *dev;
+ void __iomem *regs;
+ struct clk *clk;
+ int line;
+};
+
+/*
+ * The VUART is basically two UART 'front ends' connected by their FIFO
+ * (no actual serial line in between). One is on the BMC side (management
+ * controller) and one is on the host CPU side.
+ *
+ * It allows the BMC to provide to the host a "UART" that pipes into
+ * the BMC itself and can then be turned by the BMC into a network console
+ * of some sort for example.
+ *
+ * This driver is for the BMC side. The sysfs files allow the BMC
+ * userspace which owns the system configuration policy, to specify
+ * at what IO port and interrupt number the host side will appear
+ * to the host on the Host <-> BMC LPC bus. It could be different on a
+ * different system (though most of them use 3f8/4).
+ */
+
+static ssize_t lpc_address_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct aspeed_vuart *vuart = dev_get_drvdata(dev);
+ u16 addr;
+
+ addr = (readb(vuart->regs + ASPEED_VUART_ADDRH) << 8) |
+ (readb(vuart->regs + ASPEED_VUART_ADDRL));
+
+ return snprintf(buf, PAGE_SIZE - 1, "0x%x\n", addr);
+}
+
+static ssize_t lpc_address_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct aspeed_vuart *vuart = dev_get_drvdata(dev);
+ unsigned long val;
+ int err;
+
+ err = kstrtoul(buf, 0, &val);
+ if (err)
+ return err;
+
+ writeb(val >> 8, vuart->regs + ASPEED_VUART_ADDRH);
+ writeb(val >> 0, vuart->regs + ASPEED_VUART_ADDRL);
+
+ return count;
+}
+
+static DEVICE_ATTR_RW(lpc_address);
+
+static ssize_t sirq_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct aspeed_vuart *vuart = dev_get_drvdata(dev);
+ u8 reg;
+
+ reg = readb(vuart->regs + ASPEED_VUART_GCRB);
+ reg &= ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
+ reg >>= ASPEED_VUART_GCRB_HOST_SIRQ_SHIFT;
+
+ return snprintf(buf, PAGE_SIZE - 1, "%u\n", reg);
+}
+
+static ssize_t sirq_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct aspeed_vuart *vuart = dev_get_drvdata(dev);
+ unsigned long val;
+ int err;
+ u8 reg;
+
+ err = kstrtoul(buf, 0, &val);
+ if (err)
+ return err;
+
+ val <<= ASPEED_VUART_GCRB_HOST_SIRQ_SHIFT;
+ val &= ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
+
+ reg = readb(vuart->regs + ASPEED_VUART_GCRB);
+ reg &= ~ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
+ reg |= val;
+ writeb(reg, vuart->regs + ASPEED_VUART_GCRB);
+
+ return count;
+}
+
+static DEVICE_ATTR_RW(sirq);
+
+static struct attribute *aspeed_vuart_attrs[] = {
+ &dev_attr_sirq.attr,
+ &dev_attr_lpc_address.attr,
+ NULL,
+};
+
+static const struct attribute_group aspeed_vuart_attr_group = {
+ .attrs = aspeed_vuart_attrs,
+};
+
+static void aspeed_vuart_set_enabled(struct aspeed_vuart *vuart, bool enabled)
+{
+ u8 reg;
+
+ reg = readb(vuart->regs + ASPEED_VUART_GCRA);
+ reg &= ~ASPEED_VUART_GCRA_VUART_EN;
+ if (enabled)
+ reg |= ASPEED_VUART_GCRA_VUART_EN;
+ writeb(reg, vuart->regs + ASPEED_VUART_GCRA);
+}
+
+static void aspeed_vuart_set_host_tx_discard(struct aspeed_vuart *vuart,
+ bool discard)
+{
+ u8 reg;
+
+ reg = readb(vuart->regs + ASPEED_VUART_GCRA);
+
+ /* if the HOST_TX_DISCARD bit is set, discard is *disabled* */
+ reg &= ~ASPEED_VUART_GCRA_HOST_TX_DISCARD;
+ if (!discard)
+ reg |= ASPEED_VUART_GCRA_HOST_TX_DISCARD;
+
+ writeb(reg, vuart->regs + ASPEED_VUART_GCRA);
+}
+
+static int aspeed_vuart_startup(struct uart_port *uart_port)
+{
+ struct uart_8250_port *uart_8250_port = up_to_u8250p(uart_port);
+ struct aspeed_vuart *vuart = uart_8250_port->port.private_data;
+ int rc;
+
+ rc = serial8250_do_startup(uart_port);
+ if (rc)
+ return rc;
+
+ aspeed_vuart_set_host_tx_discard(vuart, false);
+
+ return 0;
+}
+
+static void aspeed_vuart_shutdown(struct uart_port *uart_port)
+{
+ struct uart_8250_port *uart_8250_port = up_to_u8250p(uart_port);
+ struct aspeed_vuart *vuart = uart_8250_port->port.private_data;
+
+ aspeed_vuart_set_host_tx_discard(vuart, true);
+
+ serial8250_do_shutdown(uart_port);
+}
+
+static int aspeed_vuart_probe(struct platform_device *pdev)
+{
+ struct uart_8250_port port;
+ struct resource *res;
+ struct aspeed_vuart *vuart;
+ struct device_node *np;
+ u32 clk, prop;
+ int rc;
+
+ np = pdev->dev.of_node;
+
+ vuart = devm_kzalloc(&pdev->dev, sizeof(*vuart), GFP_KERNEL);
+ if (!vuart)
+ return -ENOMEM;
+
+ vuart->dev = &pdev->dev;
+
+ /* The 8510 core creates the mapping, which we grab a reference to
+ * for VUART-specific registers */
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ vuart->regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(vuart->regs))
+ return PTR_ERR(vuart->regs);
+
+ memset(&port, 0, sizeof(port));
+ port.port.private_data = vuart;
+ port.port.membase = vuart->regs;
+ port.port.mapbase = res->start;
+ port.port.mapsize = resource_size(res);
+ port.port.startup = aspeed_vuart_startup;
+ port.port.shutdown = aspeed_vuart_shutdown;
+ port.port.dev = &pdev->dev;
+
+ rc = sysfs_create_group(&vuart->dev->kobj, &aspeed_vuart_attr_group);
+ if (rc < 0)
+ return rc;
+
+ if (of_property_read_u32(np, "clock-frequency", &clk)) {
+ vuart->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(vuart->clk)) {
+ dev_warn(&pdev->dev,
+ "clk or clock-frequency not defined\n");
+ return PTR_ERR(vuart->clk);
+ }
+
+ rc = clk_prepare_enable(vuart->clk);
+ if (rc < 0)
+ return rc;
+
+ clk = clk_get_rate(vuart->clk);
+ }
+
+ /* If current-speed was set, then try not to change it. */
+ if (of_property_read_u32(np, "current-speed", &prop) == 0)
+ port.port.custom_divisor = clk / (16 * prop);
+
+ /* Check for shifted address mapping */
+ if (of_property_read_u32(np, "reg-offset", &prop) == 0)
+ port.port.mapbase += prop;
+
+ /* Check for registers offset within the devices address range */
+ if (of_property_read_u32(np, "reg-shift", &prop) == 0)
+ port.port.regshift = prop;
+
+ /* Check for fifo size */
+ if (of_property_read_u32(np, "fifo-size", &prop) == 0)
+ port.port.fifosize = prop;
+
+ /* Check for a fixed line number */
+ rc = of_alias_get_id(np, "serial");
+ if (rc >= 0)
+ port.port.line = rc;
+
+ port.port.irq = irq_of_parse_and_map(np, 0);
+ port.port.irqflags = IRQF_SHARED;
+ port.port.iotype = UPIO_MEM;
+ if (of_property_read_u32(np, "reg-io-width", &prop) == 0) {
+ switch (prop) {
+ case 1:
+ port.port.iotype = UPIO_MEM;
+ break;
+ case 4:
+ port.port.iotype = of_device_is_big_endian(np) ?
+ UPIO_MEM32BE : UPIO_MEM32;
+ break;
+ default:
+ dev_warn(&pdev->dev, "unsupported reg-io-width (%d)\n",
+ prop);
+ rc = -EINVAL;
+ goto err_clk_disable;
+ }
+ }
+
+ port.port.type = PORT_16550A;
+ port.port.uartclk = clk;
+ port.port.flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF
+ | UPF_FIXED_PORT | UPF_FIXED_TYPE | UPF_NO_THRE_TEST;
+
+ if (of_property_read_bool(np, "no-loopback-test"))
+ port.port.flags |= UPF_SKIP_TEST;
+
+ if (port.port.fifosize)
+ port.capabilities = UART_CAP_FIFO;
+
+ if (of_property_read_bool(np, "auto-flow-control"))
+ port.capabilities |= UART_CAP_AFE;
+
+ rc = serial8250_register_8250_port(&port);
+ if (rc < 0)
+ goto err_clk_disable;
+
+ vuart->line = rc;
+
+ aspeed_vuart_set_enabled(vuart, true);
+ aspeed_vuart_set_host_tx_discard(vuart, true);
+ platform_set_drvdata(pdev, vuart);
+
+ return 0;
+
+err_clk_disable:
+ clk_disable_unprepare(vuart->clk);
+ irq_dispose_mapping(port.port.irq);
+ return rc;
+}
+
+static int aspeed_vuart_remove(struct platform_device *pdev)
+{
+ struct aspeed_vuart *vuart = platform_get_drvdata(pdev);
+
+ aspeed_vuart_set_enabled(vuart, false);
+ serial8250_unregister_port(vuart->line);
+ sysfs_remove_group(&vuart->dev->kobj, &aspeed_vuart_attr_group);
+ clk_disable_unprepare(vuart->clk);
+
+ return 0;
+}
+
+static const struct of_device_id aspeed_vuart_table[] = {
+ { .compatible = "aspeed,ast2400-vuart" },
+ { .compatible = "aspeed,ast2500-vuart" },
+ { },
+};
+
+static struct platform_driver aspeed_vuart_driver = {
+ .driver = {
+ .name = "aspeed-vuart",
+ .of_match_table = aspeed_vuart_table,
+ },
+ .probe = aspeed_vuart_probe,
+ .remove = aspeed_vuart_remove,
+};
+
+module_platform_driver(aspeed_vuart_driver);
+
+MODULE_AUTHOR("Jeremy Kerr <jk@ozlabs.org>");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Driver for Aspeed VUART device");
--
2.11.0
^ permalink raw reply related
* [PATCH v2 1/2] serial: 8250: Add flag so drivers can avoid THRE probe
From: Joel Stanley @ 2017-04-05 4:03 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Mark Rutland, Rob Herring
Cc: linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Andy Shevchenko,
Benjamin Herrenschmidt, Jeremy Kerr,
openbmc-uLR06cmDAlY/bJ5BZ2RsiQ
In-Reply-To: <20170405040352.5661-1-joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
The probing of THRE irq behaviour assumes the other end will be reading
bytes out of the buffer in order to probe the port at driver init. In
some cases the other end cannot be relied upon to read these bytes, so
provide a flag for them to skip this step.
Bit 16 was chosen as the flags are a int and the top bits are taken.
Acked-by: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
Signed-off-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
---
drivers/tty/serial/8250/8250_port.c | 2 +-
include/linux/serial_core.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index 6119516ef5fc..60a6c247340f 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -2229,7 +2229,7 @@ int serial8250_do_startup(struct uart_port *port)
}
}
- if (port->irq) {
+ if (port->irq && !(up->port.flags & UPF_NO_THRE_TEST)) {
unsigned char iir1;
/*
* Test for UARTs that do not reassert THRE when the
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 58484fb35cc8..260245deec94 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -195,6 +195,7 @@ struct uart_port {
#define UPF_NO_TXEN_TEST ((__force upf_t) (1 << 15))
#define UPF_MAGIC_MULTIPLIER ((__force upf_t) ASYNC_MAGIC_MULTIPLIER /* 16 */ )
+#define UPF_NO_THRE_TEST ((__force upf_t) (1 << 19))
/* Port has hardware-assisted h/w flow control */
#define UPF_AUTO_CTS ((__force upf_t) (1 << 20))
#define UPF_AUTO_RTS ((__force upf_t) (1 << 21))
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 0/2] drivers: serial: Aspeed VUART driver
From: Joel Stanley @ 2017-04-05 4:03 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Mark Rutland, Rob Herring
Cc: linux-serial, linux-kernel, devicetree, openbmc, Andy Shevchenko,
Benjamin Herrenschmidt, Jeremy Kerr
This is v2 of a driver for the Aspeed VUART. This version addresses feedback
from Andy and Greg, and adds Rob's ack for the bindings change.
The VUART is a serial device on the BMC side of the LPC bus that connects a BMC
to it's host processor.
We add a flag to the serial core to allow the driver to skip probing of the
THRE irq behaviour, which could hang due to the host not reading bytes out of
the buffer.
We've been using this on systems for over a year, so it has seen a good amount
of testing.
Cheers,
Joel
Jeremy Kerr (1):
drivers/serial: Add driver for Aspeed virtual UART
Joel Stanley (1):
serial: 8250: Add flag so drivers can avoid THRE probe
Documentation/ABI/stable/sysfs-driver-aspeed-vuart | 15 +
Documentation/devicetree/bindings/serial/8250.txt | 2 +
drivers/tty/serial/8250/8250_port.c | 2 +-
drivers/tty/serial/8250/Kconfig | 10 +
drivers/tty/serial/8250/Makefile | 1 +
drivers/tty/serial/8250/aspeed-vuart.c | 341 +++++++++++++++++++++
include/linux/serial_core.h | 1 +
7 files changed, 371 insertions(+), 1 deletion(-)
create mode 100644 Documentation/ABI/stable/sysfs-driver-aspeed-vuart
create mode 100644 drivers/tty/serial/8250/aspeed-vuart.c
--
2.11.0
^ permalink raw reply
* Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems
From: Nicolas Pitre @ 2017-04-04 20:27 UTC (permalink / raw)
To: Tom Zanussi
Cc: Andy Shevchenko, Geert Uytterhoeven, Stuart Longland, Andi Kleen,
Greg Kroah-Hartman, Jiri Slaby, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1491335924.7125.87.camel@tzanussi-mobl.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 2105 bytes --]
On Tue, 4 Apr 2017, Tom Zanussi wrote:
> On Tue, 2017-04-04 at 21:04 +0300, Andy Shevchenko wrote:
> > I believe you did some research during time of that project…
> >
>
> Yes, as a matter of fact I did, and just found some notes I took at the
> time. I didn't dive into the code in detail - that level of analysis
> was supposed to come later but I did have these notes mentioning that I
> thought it would show the largest savings for a single item (outside of
> networking) 'if we could do it':
>
> "- Largest is still drivers
>
> - drivers/tty and serial is the biggest obvious win if we can do it
> - break down into granular config options
> - leave simplest possible tty/serial functionality
> - allow tailoring to specific hardware
> - also helps in effort to get rid of char devices
> - 65740/815190"
>
> Basically 65k out of an 800k text size could be partially or mostly
> saved by addressing that one item, which looks like it pretty much
> matches Nicolas' numbers...
One thing on x86 that inflates the size is the 8250 driver itself. I'm
looking at some ARM targets with their own UART whose driver is much
smaller.
> BTW, since I'm quoting my own notes on the subject, I thought I'd just
> include the whole thing, which covers a bunch of other areas possibly
> ripe for tinification, in case anyone might be interested (some of it
> should be taken with a grain of salt though ;-)
>
[...]
>
> - 2nd largest is kernel
>
> - should be able to cut *something* from time and sched
> - we have a handful of processes at most
> - we have very simple time needs
> - say 30000/815190 savings
>
> 150742 6376 8209 165327 285cf ./kernel/built-in.o
>
> 40951 1105 4720 46776 b6b8 ./kernel/time/built-in.o
Commit baa73d9e47 allows for shaving off 25K here. More could probably
be done.
> 21760 1318 112 23190 5a96 ./kernel/sched/built-in.o
I already have an alternative scheduler implementation that weights 9K.
It is on the backburner for now though. But don't let the scheduler
guys know just yet. ;-)
Nicolas
^ permalink raw reply
* Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems
From: Tom Zanussi @ 2017-04-04 19:58 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Geert Uytterhoeven, Stuart Longland, Nicolas Pitre, Andi Kleen,
Greg Kroah-Hartman, Jiri Slaby, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAHp75VfQVdMRZnbDFyH9m=HfSuoiUxqhf2y+H07u4u6xPd7DUA@mail.gmail.com>
On Tue, 2017-04-04 at 21:04 +0300, Andy Shevchenko wrote:
> On Tue, Apr 4, 2017 at 8:59 PM, Tom Zanussi <tom.zanussi@linux.intel.com> wrote:
> > On Tue, 2017-04-04 at 20:08 +0300, Andy Shevchenko wrote:
> >> On Tue, Apr 4, 2017 at 7:59 PM, Tom Zanussi <tom.zanussi@linux.intel.com> wrote:
> >> > On Tue, 2017-04-04 at 00:05 +0300, Andy Shevchenko wrote:
>
> >> > I was focused at that point mainly on the kernel static size, and using
> >> > a combination of Josh Triplett's tinification tree, Andi Kleen's LTO and
> >> > net-diet patches, and my own miscellaneous patches that I was planning
> >> > on eventually upstreaming, I ended up with a system that I could boot to
> >> > shell with a 455k text size:
> >> >
> >> > Memory: 235636K/245176K available (455K kernel code, 61K rwdata,
> >> > 64K rodata, 132K init, 56K bss, 3056K reserved, 0K cma-reserved)
>
> >> Thanks for sharing your experience. The question closer to this
> >> discussion what did you do against TTY/UART/(related) layer(s)?
> >>
> >
> > I'd have to go back and take a look, but nothing special AFIAR.
> >
> > No patches or hacks along those lines, and the only related thing I see
> > as far as config is:
> >
> > cfg/pty-disable.scc \
> >
> > which maps to:
> >
> > # CONFIG_UNIX98_PTYS is not set
>
> But on your guestimation how much can we squeeze TTY/UART layer if we
> do some compile-time configuration?
> Does it even make sense or better to introduce something like minitty
> special layer instead?
>
> I believe you did some research during time of that project…
>
Yes, as a matter of fact I did, and just found some notes I took at the
time. I didn't dive into the code in detail - that level of analysis
was supposed to come later but I did have these notes mentioning that I
thought it would show the largest savings for a single item (outside of
networking) 'if we could do it':
"- Largest is still drivers
- drivers/tty and serial is the biggest obvious win if we can do it
- break down into granular config options
- leave simplest possible tty/serial functionality
- allow tailoring to specific hardware
- also helps in effort to get rid of char devices
- 65740/815190"
Basically 65k out of an 800k text size could be partially or mostly
saved by addressing that one item, which looks like it pretty much
matches Nicolas' numbers...
So no doubt it would be worthwhile to address one way or the other.
Whether to do that by refactoring the tty layer or partial refactoring
and creation of a parallel minimal version would best be left up to
someone who actually understands it I would think...
BTW, since I'm quoting my own notes on the subject, I thought I'd just
include the whole thing, which covers a bunch of other areas possibly
ripe for tinification, in case anyone might be interested (some of it
should be taken with a grain of salt though ;-)
Tom
--------
galileo SMALLEST_SIZE
$ size vmlinux
text data bss dec hex filename
699668 186432 2271592 3157692 302ebc vmlinux
Not using this, because
$ size xxx.o shows all 0s with LTO
----
Using this:
galileo SMALLEST_SIZE with LTO off
$ size vmlinux
text data bss dec hex filename
815190 165696 2272760 3253646 31a58e vmlinux
This corresponds to LTO size:
$ size vmlinux
text data bss dec hex filename
677183 179528 1207280 2063991 1f7e77 vmlinux
$ ls -al arch/x86/boot/bzImage
-rw-r--r--. 1 427264 Mar 12 22:34 arch/x86/boot/bzImage
And booted size:
Memory: 235388K/245240K available (534K kernel code, 100K rwdata, 52K rodata, 14
8K init, 64K bss, 3172K reserved, 0K cma-reserved)
virtual kernel memory layout:
fixmap : 0xfffa4000 - 0xfffff000 ( 364 kB)
vmalloc : 0xd05f0000 - 0xfffa2000 ( 761 MB)
lowmem : 0xc0000000 - 0xcfdf0000 ( 253 MB)
.init : 0xc10af000 - 0xc10d4000 ( 148 kB)
.data : 0xc1085b9c - 0xc10ad120 ( 157 kB)
.text : 0xc1000000 - 0xc1085b9c ( 534 kB)
------
Totals - details below
------
- make ptrace configurable - this should help the hw breakpoints and x86 perf disable patches upstream
- 5k
- remove things not needed for CONFIG_SMP
- 5k
- support configuring out kswapd
- about 5k in vmscan
- support configuring out vmstat
- 0
- kernel capabilities
- 1k
- exec domains
- 1k
- tsc
3030 284 40 3354 d1a ./arch/x86/kernel/tsc.o
332 0 0 332 14c ./arch/x86/kernel/tsc_msr.o
- support configuring out signals
11852 36 4 11892 2e74 ./kernel/signal.o
3188 1 0 3189 c75 ./arch/x86/kernel/signal.o
- about 15k
- kernel/pid.o simplification - more for dynamic memory - simpler pidhash
1868 160 4 2032 7f0 ./kernel/pid.o
- about 2k
- remove kernel/exit.o
- assume processes never exit
- remove lib/kfifo
- about 2k
- remove kernel/irq/spurious
- about 1k
- make sys configurable
- about 7k
- remove xattr
- about 4k
- /drivers total possible savings, some percentage of:
- 136000/815190
- /kernel savings
- say 30000/815190 savings
- /fs savings
- 30000/815190 savings
- /arch/x86 savings
- 20000/815190
- /mm
- 5000/815190
- /lib
- 10000/815190
Totals without mmu:
146k + (2/3)*136k = 235k
235k/815190 = 30% savings
- x86 nommu
- about 50k
Totals with mmu:
285k/815190 = 35% savings
Applied to the 534k boot figure, we end up with text size of:
374k mmu
347k nommu
We could probably go lower with more fine-grained analysis, but we may
also need to add drivers, etc.
-----
NONET details
-----
- Largest is still drivers
- drivers/tty and serial is the biggest obvious win if we can do it
- break down into granular config options
- leave simplest possible tty/serial functionality
- allow tailoring to specific hardware
- also helps in effort to get rid of char devices
- 65740/815190
- pci is next largest
- assume we can break down into granular config options
- leave simplest possible pci functionality
- allow tailoring to specific hardware e.g. no discovery
- 47144/815190
- drivers/base
- simplify driver core for a small set of drivers
- simple_char: New infrastructure to simplify chardev management
- 25389/815190
- total possible savings, some percentage of:
- 136000/815190
206992 29331 6556 242879 3b4bf ./drivers/built-in.o
65740 16888 3132 85760 14f00 ./drivers/tty/built-in.o
32077 16680 2688 51445 c8f5 ./drivers/tty/serial/built-in.o
21628 15892 2644 40164 9ce4 ./drivers/tty/serial/8250/built-in.o
47144 1172 2100 50416 c4f0 ./drivers/pci/built-in.o
25389 1324 112 26825 68c9 ./drivers/base/built-in.o
15733 636 20 16389 4005 ./drivers/spi/built-in.o
11504 136 28 11668 2d94 ./drivers/clk/built-in.o
9605 460 72 10137 2799 ./drivers/thermal/built-in.o
5066 624 912 6602 19ca ./drivers/char/built-in.o
8531 480 36 9047 2357 ./drivers/i2c/built-in.o
- 2nd largest is kernel
- should be able to cut *something* from time and sched
- we have a handful of processes at most
- we have very simple time needs
- say 30000/815190 savings
150742 6376 8209 165327 285cf ./kernel/built-in.o
40951 1105 4720 46776 b6b8 ./kernel/time/built-in.o
21760 1318 112 23190 5a96 ./kernel/sched/built-in.o
9800 388 1328 11516 2cfc ./kernel/irq/built-in.o
4956 4 4 4964 1364 ./kernel/locking/built-in.o
1847 88 184 2119 847 ./kernel/printk/built-in.o
1757 33 0 1790 6fe ./kernel/rcu/built-in.o
1408 356 44 1808 710 ./kernel/power/built-in.o
- next is fs
- completely turn off proc
- requires userspace changes to cope with it
- 22046/815190, 100% of this
- simplify/featurize some core vfs?
- e.g. namei, small set of file names, no need for complexity
- disable vfs completely?
- init reads executables directly from storage
- all state in memory, no need to save anything
133526 1506 1552 136584 21588 ./fs/built-in.o
22046 140 40 22226 56d2 ./fs/proc/built-in.o
- next is arch/x86, mostly in arch/x86/kernel
- not much to save here, maybe 10 here and there
- maybe 3k in boot: video*
- maybe 5k in cpu: amd, transmeta, cachinfo, etc
- cut about 10k in arch/x86/mm for nommu
120755 50209 52712 223676 369bc ./arch/x86/built-in.o
100201 29261 19828 149290 2472a ./arch/x86/kernel/built-in.o
21713 8693 720 31126 7996 ./arch/x86/kernel/cpu/built-in.o
17480 5486 6324 29290 726a ./arch/x86/kernel/apic/built-in.o
10385 4365 532 15282 3bb2 ./arch/x86/kernel/cpu/mcheck/built-in.o
18237 208 30776 49221 c045 ./arch/x86/mm/built-in.o
14276 412 256 14944 3a60 ./arch/x86/pci/built-in.o
1345 8 28 1381 565 ./arch/x86/platform/intel-quark/built-in.o
1345 8 28 1381 565 ./arch/x86/platform/built-in.o
590 8228 16 8834 2282 ./arch/x86/vdso/built-in.o
379 12500 8 12887 3257 ./arch/x86/realmode/built-in.o
477 0 0 477 1dd ./arch/x86/lib/built-in.o
- next is mm
- cut about 5k for percpu
- cut about 40k for nommu
119008 13688 1824 134520 20d78 ./mm/built-in.o
1358 0 0 1358 54e ./mm/gup.o
10612 32 24 10668 29ac ./mm/memory.o
1072 0 0 1072 430 ./mm/mincore.o
2453 0 0 2453 995 ./mm/mlock.o
9918 176 8 10102 2776 ./mm/mmap.o
1403 0 0 1403 57b ./mm/mprotect.o
2155 0 0 2155 86b ./mm/mremap.o
520 0 0 520 208 ./mm/msync.o
4358 0 8 4366 110e ./mm/rmap.o
6355 57 28 6440 1928 ./mm/vmalloc.o
710 0 0 710 2c6 ./mm/pagewalk.o
92 0 0 92 5c ./mm/pgtable-generic.o
- next is lib
- no need for vsprintf if printk off, 10k
30654 24647 5 55306 d80a ./lib/built-in.o
9964 0 0 9964 26ec ./lib/zlib_inflate/built-in.o
-next is init
8456 16437 81 24974 618e ./init/built-in.o
----
Net sizes, maybe later...
galileo SMALLEST_SIZE_NET with LTO off
- this is without ipv4 net-diet
- includes ipv6
$ size vmlinux
text data bss dec hex filename
1368973 181184 2288560 3838717 3a92fd vmlinux
---
NET details
---
- net now largest, larger than drivers (and drivers goes up too)
465384 13818 17364 496566 793b6 ./net/built-in.o
183144 5409 7948 196501 2ff95 ./net/ipv4/built-in.o
128583 4648 6432 139663 2218f ./net/ipv6/built-in.o
108158 2092 2804 113054 1b99e ./net/core/built-in.o
15268 264 0 15532 3cac ./net/packet/built-in.o
14787 465 148 15400 3c28 ./net/netlink/built-in.o
4011 676 0 4687 124f ./net/sched/built-in.o
967 12 0 979 3d3 ./net/ethernet/built-in.o
- drivers second largest
255026 30512 6604 292142 4752e ./drivers/built-in.o
359 20 0 379 17b ./drivers/reset/built-in.o
2155 152 32 2339 923 ./drivers/pps/built-in.o
8870 580 0 9450 24ea ./drivers/net/phy/built-in.o
42421 861 8 43290 a91a ./drivers/net/built-in.o
30650 233 8 30891 78ab ./drivers/net/ethernet/stmicro/stmmac/built-in.o
30650 233 8 30891 78ab ./drivers/net/ethernet/stmicro/built-in.o
30650 233 8 30891 78ab ./drivers/net/ethernet/built-in.o
47144 1172 2100 50416 c4f0 ./drivers/pci/built-in.o
11504 136 28 11668 2d94 ./drivers/clk/built-in.o
25389 1324 112 26825 68c9 ./drivers/base/built-in.o
15733 636 20 16389 4005 ./drivers/spi/built-in.o
5066 624 912 6602 19ca ./drivers/char/built-in.o
9931 548 76 10555 293b ./drivers/thermal/built-in.o
4927 224 36 5187 1443 ./drivers/ptp/built-in.o
65740 16888 3132 85760 14f00 ./drivers/tty/built-in.o
32077 16680 2688 51445 c8f5 ./drivers/tty/serial/built-in.o
21628 15892 2644 40164 9ce4 ./drivers/tty/serial/8250/built-in.o
8531 480 36 9047 2357 ./drivers/i2c/built-in.o
- kernel next
157407 6376 8209 171992 29fd8 ./kernel/built-in.o
9800 388 1328 11516 2cfc ./kernel/irq/built-in.o
40951 1105 4720 46776 b6b8 ./kernel/time/built-in.o
6665 0 0 6665 1a09 ./kernel/bpf/built-in.o
1408 356 44 1808 710 ./kernel/power/built-in.o
21760 1318 112 23190 5a96 ./kernel/sched/built-in.o
4956 4 4 4964 1364 ./kernel/locking/built-in.o
1757 33 0 1790 6fe ./kernel/rcu/built-in.o
1847 88 184 2119 847 ./kernel/printk/built-in.o
- fs next
134562 1534 1552 137648 219b0 ./fs/built-in.o
1395 276 4 1675 68b ./fs/ramfs/built-in.o
22743 168 40 22951 59a7 ./fs/proc/built-in.o
1446 44 8 1498 5da ./fs/devpts/built-in.o
- arch/x86 next
120755 50209 52712 223676 369bc ./arch/x86/built-in.o
379 12500 8 12887 3257 ./arch/x86/realmode/built-in.o
14276 412 256 14944 3a60 ./arch/x86/pci/built-in.o
590 8228 16 8834 2282 ./arch/x86/vdso/built-in.o
18237 208 30776 49221 c045 ./arch/x86/mm/built-in.o
477 0 0 477 1dd ./arch/x86/lib/built-in.o
1345 8 28 1381 565 ./arch/x86/platform/intel-quark/built-in.o
1345 8 28 1381 565 ./arch/x86/platform/built-in.o
17480 5486 6324 29290 726a ./arch/x86/kernel/apic/built-in.o
21713 8693 720 31126 7996 ./arch/x86/kernel/cpu/built-in.o
10385 4365 532 15282 3bb2 ./arch/x86/kernel/cpu/mcheck/built-in.o
100201 29261 19828 149290 2472a ./arch/x86/kernel/built-in.o
- mm next
119008 13688 1824 134520 20d78 ./mm/built-in.o
- lib next
33042 24647 5 57694 e15e ./lib/built-in.o
9964 0 0 9964 26ec ./lib/zlib_inflate/built-in.o
- crypto next
30068 284 0 30352 7690 ./crypto/built-in.o
- init next
8456 16437 81 24974 618e ./init/built-in.o
^ permalink raw reply
* Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems
From: Nicolas Pitre @ 2017-04-04 19:26 UTC (permalink / raw)
To: Alan Cox
Cc: Andy Shevchenko, Rob Herring, Peter Hurley, Ard Biesheuvel,
Greg Kroah-Hartman, Jiri Slaby, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm Mailing List
In-Reply-To: <1491313228.3704.42.camel@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 774 bytes --]
On Tue, 4 Apr 2017, Alan Cox wrote:
> > we're down to 5.6K. At which point there's only a raw device
> > interface
> > to serial hardware.
>
> Which if you did a simple plain chardev without trying to fake the
> rather out of date uart layer would come down way further still.
Oh absolutely. I don't dispute that. Given infinite time as you said.
But I gained a 5x reduction already. I would prefer moving to some other
part of the kernel where another 5x reduction could be achieved now
rather than postponing that after I'm done rewriting the interface for
all UART drivers. Maybe someone else will feel inspired and take on
this UART driver modernizing task (that could be a nice mentorred
project for example).
PS: FUZIX is a real piece of art ;-)
Nicolas
^ permalink raw reply
* Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems
From: Nicolas Pitre @ 2017-04-04 18:53 UTC (permalink / raw)
To: Tom Zanussi
Cc: Andy Shevchenko, Geert Uytterhoeven, Stuart Longland, Andi Kleen,
Greg Kroah-Hartman, Jiri Slaby, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1491325150.7125.62.camel@tzanussi-mobl.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 4083 bytes --]
On Tue, 4 Apr 2017, Tom Zanussi wrote:
> Yes, in a previous project, I had been working toward getting a < 1M
> system to boot on Galileo hardware (which it did, but using more than
> that - the Galileo2 has 256MB, but it was the target hardware at the
> time, and I was hoping eventually to be able to boot out of the 512k
> on-chip SRAM).
>
> I was focused at that point mainly on the kernel static size, and using
> a combination of Josh Triplett's tinification tree, Andi Kleen's LTO and
> net-diet patches, and my own miscellaneous patches that I was planning
> on eventually upstreaming, I ended up with a system that I could boot to
> shell with a 455k text size:
>
> Memory: 235636K/245176K available (455K kernel code, 61K rwdata,
> 64K rodata, 132K init, 56K bss, 3056K reserved, 0K cma-reserved)
>
> virtual kernel memory layout:
> fixmap : 0xfffe5000 - 0xfffff000 ( 104 kB)
> vmalloc : 0xd05f0000 - 0xfffe3000 ( 761 MB)
> lowmem : 0xc0000000 - 0xcfdf0000 ( 253 MB)
> .init : 0xc1094000 - 0xc10b5000 ( 132 kB)
> .data : 0xc1071fac - 0xc1092760 ( 129 kB)
> .text : 0xc1000000 - 0xc1071fac ( 455 kB)
>
> That was without networking. Enabling networking added about 250k, and
> at that point I could ssh in and run a webserver, still less than 1M as
> far as kernel static size, which of course completely ignores the kernel
> dynamic size and userspace.
>
> My goal was to get rid of shell access and dropbear altogether and have
> all access be via webserver, which I did by using nostromo, mainly for
> convenience, until I could get some 'cgi' added to Alan Cox's µWeb
> (about 20k).
>
> Anyway, that work, as I left it a couple years ago, is here, in case
> anyone's interested (it's a yocto layer and yocto-based kernel
> containing many topic branches, but building it according to the
> directions in the README will yield a standard kernel and .config in the
> working directory and allow you to ignore all the yocto stuff):
>
> https://github.com/tzanussi/linux-yocto-micro-4.1
> https://github.com/tzanussi/meta-microlinux/tree/jethro
Thanks for sharing I'll certainly have a look.
> It's nice to see tinification work being done again - at the time I
> stopped working on it it seemed there was no desire from maintainers in
> general to merge anything that would create new options designed only
> for the purpose of tinification.
I successfully provided an option to disable POSIX timers lately. A
round trip into the Kconfig parser was required to achieve that though.
Many maintainers are resistant to change as their role is to preserve
stability of their code. Adding special cases in existing code makes it
much harder to maintain and validate. Sometimes it is way better to have
a parallel implementation rather that destabilizing the one version
available... as long as the interface is the same and that the big and
tiny versions can be used interchangeably.
> In fact, as a kind of backup plan for that, I also played around with
> the idea of auto-generating a kernel that would contain only the
> functions that were demonstrated to be used by the (single-purpose)
> workload. It was similar to the idea of making every system call
> configurable and then including only the ones used by the workload, but
> taking it a step further and doing that for every function in the
> kernel, not just system calls.
I thought about that too... and dismissed the idea as being too
frightening!
> I had a script that would take the output of the function_hist histogram
> taken while exhaustively running the workload:
>
> https://lkml.org/lkml/2015/5/20/994
>
> And with a kernel compiled using -ffunction-sections removing all
> functions that were never referenced. I never got a bootable kernel out
> of it, but mainly just because I ran out of time and had to move onto
> other things. I may dust it off and try again, just for fun... ;-)
That would be great.
I really wish to stir up interest from more people and have Linux gain
momentum in the tiny system space.
Nicolas
^ permalink raw reply
* Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems
From: Nicolas Pitre @ 2017-04-04 18:31 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Tom Zanussi, Geert Uytterhoeven, Stuart Longland, Andi Kleen,
Greg Kroah-Hartman, Jiri Slaby, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAHp75VfQVdMRZnbDFyH9m=HfSuoiUxqhf2y+H07u4u6xPd7DUA@mail.gmail.com>
On Tue, 4 Apr 2017, Andy Shevchenko wrote:
> On Tue, Apr 4, 2017 at 8:59 PM, Tom Zanussi <tom.zanussi@linux.intel.com> wrote:
> > On Tue, 2017-04-04 at 20:08 +0300, Andy Shevchenko wrote:
> >> On Tue, Apr 4, 2017 at 7:59 PM, Tom Zanussi <tom.zanussi@linux.intel.com> wrote:
> >> > On Tue, 2017-04-04 at 00:05 +0300, Andy Shevchenko wrote:
>
> >> > I was focused at that point mainly on the kernel static size, and using
> >> > a combination of Josh Triplett's tinification tree, Andi Kleen's LTO and
> >> > net-diet patches, and my own miscellaneous patches that I was planning
> >> > on eventually upstreaming, I ended up with a system that I could boot to
> >> > shell with a 455k text size:
> >> >
> >> > Memory: 235636K/245176K available (455K kernel code, 61K rwdata,
> >> > 64K rodata, 132K init, 56K bss, 3056K reserved, 0K cma-reserved)
>
> >> Thanks for sharing your experience. The question closer to this
> >> discussion what did you do against TTY/UART/(related) layer(s)?
> >>
> >
> > I'd have to go back and take a look, but nothing special AFIAR.
> >
> > No patches or hacks along those lines, and the only related thing I see
> > as far as config is:
> >
> > cfg/pty-disable.scc \
> >
> > which maps to:
> >
> > # CONFIG_UNIX98_PTYS is not set
>
> But on your guestimation how much can we squeeze TTY/UART layer if we
> do some compile-time configuration?
> Does it even make sense or better to introduce something like minitty
> special layer instead?
For the record I more or less came along the same path as Tom, playing
with LTO, gc-sections, syscall removal, module_param() removal, etc. At
the end of the day you still have that 45K of TTY code just to send
debug out, 100K of VFS even if using only ramfs, 54K of timer code even
if there's only one simple timer available, 28K of IRQ support code even
if there is only one type of interrupt used, etc. LTO / gc-section
cannot automatically get rid of those unused functions because they're
runtime selected callbacks and optimization tools no longer can do their
magic.
At some point there is no way other than having a parallel
implementation specifically for a limited scope to reduce both code
footprint and runtime RAM consumption. Who need a multicore scalable VFS
cache when there's only 256K of RAM and a single user space process
running?
Nicolas
^ permalink raw reply
* Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems
From: Andy Shevchenko @ 2017-04-04 18:04 UTC (permalink / raw)
To: Tom Zanussi
Cc: Geert Uytterhoeven, Stuart Longland, Nicolas Pitre, Andi Kleen,
Greg Kroah-Hartman, Jiri Slaby, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1491328749.7125.66.camel@tzanussi-mobl.amr.corp.intel.com>
On Tue, Apr 4, 2017 at 8:59 PM, Tom Zanussi <tom.zanussi@linux.intel.com> wrote:
> On Tue, 2017-04-04 at 20:08 +0300, Andy Shevchenko wrote:
>> On Tue, Apr 4, 2017 at 7:59 PM, Tom Zanussi <tom.zanussi@linux.intel.com> wrote:
>> > On Tue, 2017-04-04 at 00:05 +0300, Andy Shevchenko wrote:
>> > I was focused at that point mainly on the kernel static size, and using
>> > a combination of Josh Triplett's tinification tree, Andi Kleen's LTO and
>> > net-diet patches, and my own miscellaneous patches that I was planning
>> > on eventually upstreaming, I ended up with a system that I could boot to
>> > shell with a 455k text size:
>> >
>> > Memory: 235636K/245176K available (455K kernel code, 61K rwdata,
>> > 64K rodata, 132K init, 56K bss, 3056K reserved, 0K cma-reserved)
>> Thanks for sharing your experience. The question closer to this
>> discussion what did you do against TTY/UART/(related) layer(s)?
>>
>
> I'd have to go back and take a look, but nothing special AFIAR.
>
> No patches or hacks along those lines, and the only related thing I see
> as far as config is:
>
> cfg/pty-disable.scc \
>
> which maps to:
>
> # CONFIG_UNIX98_PTYS is not set
But on your guestimation how much can we squeeze TTY/UART layer if we
do some compile-time configuration?
Does it even make sense or better to introduce something like minitty
special layer instead?
I believe you did some research during time of that project…
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems
From: Tom Zanussi @ 2017-04-04 17:59 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Geert Uytterhoeven, Stuart Longland, Nicolas Pitre, Andi Kleen,
Greg Kroah-Hartman, Jiri Slaby, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAHp75VcUorx5D2ive8eNWhtu2BzSbYAm+y9_KeFYdkTMgsg0SA@mail.gmail.com>
On Tue, 2017-04-04 at 20:08 +0300, Andy Shevchenko wrote:
> On Tue, Apr 4, 2017 at 7:59 PM, Tom Zanussi <tom.zanussi@linux.intel.com> wrote:
> > On Tue, 2017-04-04 at 00:05 +0300, Andy Shevchenko wrote:
>
> > Yes, in a previous project, I had been working toward getting a < 1M
> > system to boot on Galileo hardware (which it did, but using more than
> > that - the Galileo2 has 256MB, but it was the target hardware at the
> > time, and I was hoping eventually to be able to boot out of the 512k
> > on-chip SRAM).
> >
> > I was focused at that point mainly on the kernel static size, and using
> > a combination of Josh Triplett's tinification tree, Andi Kleen's LTO and
> > net-diet patches, and my own miscellaneous patches that I was planning
> > on eventually upstreaming, I ended up with a system that I could boot to
> > shell with a 455k text size:
> >
> > Memory: 235636K/245176K available (455K kernel code, 61K rwdata,
> > 64K rodata, 132K init, 56K bss, 3056K reserved, 0K cma-reserved)
> >
> > virtual kernel memory layout:
> > fixmap : 0xfffe5000 - 0xfffff000 ( 104 kB)
> > vmalloc : 0xd05f0000 - 0xfffe3000 ( 761 MB)
> > lowmem : 0xc0000000 - 0xcfdf0000 ( 253 MB)
> > .init : 0xc1094000 - 0xc10b5000 ( 132 kB)
> > .data : 0xc1071fac - 0xc1092760 ( 129 kB)
> > .text : 0xc1000000 - 0xc1071fac ( 455 kB)
> >
> > That was without networking. Enabling networking added about 250k, and
> > at that point I could ssh in and run a webserver, still less than 1M as
> > far as kernel static size, which of course completely ignores the kernel
> > dynamic size and userspace.
>
> Thanks for sharing your experience. The question closer to this
> discussion what did you do against TTY/UART/(related) layer(s)?
>
I'd have to go back and take a look, but nothing special AFIAR.
No patches or hacks along those lines, and the only related thing I see
as far as config is:
cfg/pty-disable.scc \
which maps to:
# CONFIG_UNIX98_PTYS is not set
^ permalink raw reply
* Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems
From: Andy Shevchenko @ 2017-04-04 17:08 UTC (permalink / raw)
To: Tom Zanussi
Cc: Geert Uytterhoeven, Stuart Longland, Nicolas Pitre, Andi Kleen,
Greg Kroah-Hartman, Jiri Slaby, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1491325150.7125.62.camel@tzanussi-mobl.amr.corp.intel.com>
On Tue, Apr 4, 2017 at 7:59 PM, Tom Zanussi <tom.zanussi@linux.intel.com> wrote:
> On Tue, 2017-04-04 at 00:05 +0300, Andy Shevchenko wrote:
> Yes, in a previous project, I had been working toward getting a < 1M
> system to boot on Galileo hardware (which it did, but using more than
> that - the Galileo2 has 256MB, but it was the target hardware at the
> time, and I was hoping eventually to be able to boot out of the 512k
> on-chip SRAM).
>
> I was focused at that point mainly on the kernel static size, and using
> a combination of Josh Triplett's tinification tree, Andi Kleen's LTO and
> net-diet patches, and my own miscellaneous patches that I was planning
> on eventually upstreaming, I ended up with a system that I could boot to
> shell with a 455k text size:
>
> Memory: 235636K/245176K available (455K kernel code, 61K rwdata,
> 64K rodata, 132K init, 56K bss, 3056K reserved, 0K cma-reserved)
>
> virtual kernel memory layout:
> fixmap : 0xfffe5000 - 0xfffff000 ( 104 kB)
> vmalloc : 0xd05f0000 - 0xfffe3000 ( 761 MB)
> lowmem : 0xc0000000 - 0xcfdf0000 ( 253 MB)
> .init : 0xc1094000 - 0xc10b5000 ( 132 kB)
> .data : 0xc1071fac - 0xc1092760 ( 129 kB)
> .text : 0xc1000000 - 0xc1071fac ( 455 kB)
>
> That was without networking. Enabling networking added about 250k, and
> at that point I could ssh in and run a webserver, still less than 1M as
> far as kernel static size, which of course completely ignores the kernel
> dynamic size and userspace.
Thanks for sharing your experience. The question closer to this
discussion what did you do against TTY/UART/(related) layer(s)?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems
From: Tom Zanussi @ 2017-04-04 16:59 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Geert Uytterhoeven, Stuart Longland, Nicolas Pitre, Andi Kleen,
Greg Kroah-Hartman, Jiri Slaby, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAHp75VdCPHW-jZ7FCrEjqHQ6ULxH_U9EsBHTjb4a=Nhs_kYFGg@mail.gmail.com>
Hi,
On Tue, 2017-04-04 at 00:05 +0300, Andy Shevchenko wrote:
> +Cc: Tom
>
> Summon Tom to the discussion. He tried once hard to shrink a Linux
> kernel to something working in 1M+ RAM on x86.
>
Yes, in a previous project, I had been working toward getting a < 1M
system to boot on Galileo hardware (which it did, but using more than
that - the Galileo2 has 256MB, but it was the target hardware at the
time, and I was hoping eventually to be able to boot out of the 512k
on-chip SRAM).
I was focused at that point mainly on the kernel static size, and using
a combination of Josh Triplett's tinification tree, Andi Kleen's LTO and
net-diet patches, and my own miscellaneous patches that I was planning
on eventually upstreaming, I ended up with a system that I could boot to
shell with a 455k text size:
Memory: 235636K/245176K available (455K kernel code, 61K rwdata,
64K rodata, 132K init, 56K bss, 3056K reserved, 0K cma-reserved)
virtual kernel memory layout:
fixmap : 0xfffe5000 - 0xfffff000 ( 104 kB)
vmalloc : 0xd05f0000 - 0xfffe3000 ( 761 MB)
lowmem : 0xc0000000 - 0xcfdf0000 ( 253 MB)
.init : 0xc1094000 - 0xc10b5000 ( 132 kB)
.data : 0xc1071fac - 0xc1092760 ( 129 kB)
.text : 0xc1000000 - 0xc1071fac ( 455 kB)
That was without networking. Enabling networking added about 250k, and
at that point I could ssh in and run a webserver, still less than 1M as
far as kernel static size, which of course completely ignores the kernel
dynamic size and userspace.
My goal was to get rid of shell access and dropbear altogether and have
all access be via webserver, which I did by using nostromo, mainly for
convenience, until I could get some 'cgi' added to Alan Cox's µWeb
(about 20k).
Anyway, that work, as I left it a couple years ago, is here, in case
anyone's interested (it's a yocto layer and yocto-based kernel
containing many topic branches, but building it according to the
directions in the README will yield a standard kernel and .config in the
working directory and allow you to ignore all the yocto stuff):
https://github.com/tzanussi/linux-yocto-micro-4.1
https://github.com/tzanussi/meta-microlinux/tree/jethro
It's nice to see tinification work being done again - at the time I
stopped working on it it seemed there was no desire from maintainers in
general to merge anything that would create new options designed only
for the purpose of tinification.
In fact, as a kind of backup plan for that, I also played around with
the idea of auto-generating a kernel that would contain only the
functions that were demonstrated to be used by the (single-purpose)
workload. It was similar to the idea of making every system call
configurable and then including only the ones used by the workload, but
taking it a step further and doing that for every function in the
kernel, not just system calls.
I had a script that would take the output of the function_hist histogram
taken while exhaustively running the workload:
https://lkml.org/lkml/2015/5/20/994
And with a kernel compiled using -ffunction-sections removing all
functions that were never referenced. I never got a bootable kernel out
of it, but mainly just because I ran out of time and had to move onto
other things. I may dust it off and try again, just for fun... ;-)
hth,
Tom
> Tom, sorry, I recall this a bit late, perhaps you might be interested
> in reading discussion from the beginning.
>
> On Mon, Apr 3, 2017 at 9:14 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Mon, Apr 3, 2017 at 12:44 AM, Stuart Longland
> > <stuartl@longlandclan.id.au> wrote:
> >> On 03/04/17 07:41, Nicolas Pitre wrote:
> >>>> No PTYs seems like a big limitation. This means no sshd?
> >>> Again, my ultimate system target is in the sub-megabyte of RAM. I
> >>> really doubt you'll be able to fit an SSH server in there even if PTYs
> >>> were supported, unless sshd (or dropbear) can be made really tiny.
> >>> Otherwise you most probably have sufficient resources to run the regular
> >>> TTY code.
> >>
> >> Are we talking small microcontrollers here? The smallest machine in
> >> terms of RAM I ever recall running Linux on was a 386SX/25 MHz with 4MB
> >> RAM, and that had a MMU.
> >
> > Let's halve that. I once tried and ran Linux in 2 MiB, incl. X, twm, and xterm.
> > Of course with swap enabled. And swapping like hell.
>
>
^ permalink raw reply
* [PATCH v4] serdev: Add serdev_device_write subroutine
From: Andrey Smirnov @ 2017-04-04 14:22 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Andrey Smirnov, cphealy, Guenter Roeck, linux-serial,
linux-kernel
Add serdev_device_write() a blocking call allowing to transfer
arbitraty amount of data (potentially exceeding amount that
serdev_device_write_buf can process in a single call)
To support that, also add serdev_device_write_wakeup().
Drivers wanting to use full extent of serdev_device_write
functionality are expected to provide serdev_device_write_wakeup() as
a sole handler of .write_wakeup event or call it as a part of driver's
custom .write_wakeup code.
Because serdev_device_write() subroutine is a superset of
serdev_device_write_buf() the patch re-impelements latter is terms of
the former. For drivers wanting to just use serdev_device_write_buf()
.write_wakeup handler is optional.
Cc: cphealy@gmail.com
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: linux-serial@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
Changes since v3 (see [v3]):
- Fixed typos in commit message
- Collected Reviewed-by's from Andy and Rob
Changes since v2 (see [v2]):
- Changed subject and commit message wording to better reflect
nature of the patch
- Various spelling, formatting, documentation and wording
fixes as caught/suggested by Andy
Changes since v1 (see [v1]):
- Make timeout to be a total(as opposed to per-iteration)
timeout
- Keep serdev_device_write_buf() as a wrapper arount
serdev_device_write() for compatibility
[v3] https://lkml.org/lkml/2017/3/30/1000
[v2] https://lkml.org/lkml/2017/3/28/942
[v1] https://lkml.org/lkml/2017/3/20/650
drivers/tty/serdev/core.c | 36 +++++++++++++++++++++++++++++++-----
include/linux/serdev.h | 17 +++++++++++++++--
2 files changed, 46 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
index f4c6c90..6701d10 100644
--- a/drivers/tty/serdev/core.c
+++ b/drivers/tty/serdev/core.c
@@ -116,17 +116,41 @@ void serdev_device_close(struct serdev_device *serdev)
}
EXPORT_SYMBOL_GPL(serdev_device_close);
-int serdev_device_write_buf(struct serdev_device *serdev,
- const unsigned char *buf, size_t count)
+void serdev_device_write_wakeup(struct serdev_device *serdev)
+{
+ complete(&serdev->write_comp);
+}
+EXPORT_SYMBOL_GPL(serdev_device_write_wakeup);
+
+int serdev_device_write(struct serdev_device *serdev,
+ const unsigned char *buf, size_t count,
+ unsigned long timeout)
{
struct serdev_controller *ctrl = serdev->ctrl;
+ int ret;
- if (!ctrl || !ctrl->ops->write_buf)
+ if (!ctrl || !ctrl->ops->write_buf ||
+ (timeout && !serdev->ops->write_wakeup))
return -EINVAL;
- return ctrl->ops->write_buf(ctrl, buf, count);
+ mutex_lock(&serdev->write_lock);
+ do {
+ reinit_completion(&serdev->write_comp);
+
+ ret = ctrl->ops->write_buf(ctrl, buf, count);
+ if (ret < 0)
+ break;
+
+ buf += ret;
+ count -= ret;
+
+ } while (count &&
+ (timeout = wait_for_completion_timeout(&serdev->write_comp,
+ timeout)));
+ mutex_unlock(&serdev->write_lock);
+ return ret < 0 ? ret : (count ? -ETIMEDOUT : 0);
}
-EXPORT_SYMBOL_GPL(serdev_device_write_buf);
+EXPORT_SYMBOL_GPL(serdev_device_write);
void serdev_device_write_flush(struct serdev_device *serdev)
{
@@ -232,6 +256,8 @@ struct serdev_device *serdev_device_alloc(struct serdev_controller *ctrl)
serdev->dev.parent = &ctrl->dev;
serdev->dev.bus = &serdev_bus_type;
serdev->dev.type = &serdev_device_type;
+ init_completion(&serdev->write_comp);
+ mutex_init(&serdev->write_lock);
return serdev;
}
EXPORT_SYMBOL_GPL(serdev_device_alloc);
diff --git a/include/linux/serdev.h b/include/linux/serdev.h
index 5176cdc..0beaff8 100644
--- a/include/linux/serdev.h
+++ b/include/linux/serdev.h
@@ -39,12 +39,16 @@ struct serdev_device_ops {
* @nr: Device number on serdev bus.
* @ctrl: serdev controller managing this device.
* @ops: Device operations.
+ * @write_comp Completion used by serdev_device_write() internally
+ * @write_lock Lock to serialize access when writing data
*/
struct serdev_device {
struct device dev;
int nr;
struct serdev_controller *ctrl;
const struct serdev_device_ops *ops;
+ struct completion write_comp;
+ struct mutex write_lock;
};
static inline struct serdev_device *to_serdev_device(struct device *d)
@@ -186,7 +190,8 @@ int serdev_device_open(struct serdev_device *);
void serdev_device_close(struct serdev_device *);
unsigned int serdev_device_set_baudrate(struct serdev_device *, unsigned int);
void serdev_device_set_flow_control(struct serdev_device *, bool);
-int serdev_device_write_buf(struct serdev_device *, const unsigned char *, size_t);
+void serdev_device_write_wakeup(struct serdev_device *);
+int serdev_device_write(struct serdev_device *, const unsigned char *, size_t, unsigned long);
void serdev_device_write_flush(struct serdev_device *);
int serdev_device_write_room(struct serdev_device *);
@@ -223,7 +228,8 @@ static inline unsigned int serdev_device_set_baudrate(struct serdev_device *sdev
return 0;
}
static inline void serdev_device_set_flow_control(struct serdev_device *sdev, bool enable) {}
-static inline int serdev_device_write_buf(struct serdev_device *sdev, const unsigned char *buf, size_t count)
+static inline int serdev_device_write(struct serdev_device *sdev, const unsigned char *buf,
+ size_t count, unsigned long timeout)
{
return -ENODEV;
}
@@ -259,4 +265,11 @@ static inline struct device *serdev_tty_port_register(struct tty_port *port,
static inline void serdev_tty_port_unregister(struct tty_port *port) {}
#endif /* CONFIG_SERIAL_DEV_CTRL_TTYPORT */
+static inline int serdev_device_write_buf(struct serdev_device *serdev,
+ const unsigned char *data,
+ size_t count)
+{
+ return serdev_device_write(serdev, data, count, 0);
+}
+
#endif /*_LINUX_SERDEV_H */
--
2.9.3
^ permalink raw reply related
* Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems
From: Alan Cox @ 2017-04-04 13:40 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Andy Shevchenko, Rob Herring, Peter Hurley, Ard Biesheuvel,
Greg Kroah-Hartman, Jiri Slaby, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm Mailing List
In-Reply-To: <alpine.LFD.2.20.1704031433480.1847@knanqh.ubzr>
> But no job control. No line editing with echo when the shell is
> busy,
> etc.
This is a debug interface. If RAM is that precious do the line editing
on the other end of the link, like normal sane RTOS people do. Most
terminal apps support line by line modes.
> we're down to 5.6K. At which point there's only a raw device
> interface
> to serial hardware.
Which if you did a simple plain chardev without trying to fake the
rather out of date uart layer would come down way further still.
> the same low-level UART interface as
> drivers/tty/serial/serial_core.c is using to interact with UART
> drivers.
> If someone wants to make a change to that interface, the 30 or so
> UART
> drivers will have to be changed as well. I don't think that would be
> a
> big deal to change the minitty code to follow suit. And I won't hide
> under a rock while this happens.
Fair enough.
> > talks tty layer. In your case you are tying it to something we
> > eventually ought to get rid of.
>
> You won't get rid of UART drivers, right?
Given infinite time the uart layer ought to go away and be replaced
with a simple kfifo queue.
> vices, though, have 256K of on-chip RAM. Those devices will
> make
> it into your surrounding. Having so much more RAM (no pun intended)
> they'll be capable of even more damage. Would you be more confident,
> when a security issue arises (because it will), to know that some
> Linux
> code base is used rather than any random RTOS out there with only
> one
> hundredth of the actual Linux following? If so please indulge me a
> bit.
Actually for any safety critical system both terrify me about as much.
None of them are generally written to any appropriate ISO safety
standard, or in an appropriate language.
I did read your rationale. I am deeply dubious that re-doing the uart
layer is the right approach versus just doing a tiny char device, but
I've said my piece.
Alan
^ permalink raw reply
* Re: [PATCH v8 3/3] printk: fix double printing with earlycon
From: Petr Mladek @ 2017-04-04 11:12 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Aleksey Makarov, linux-serial, linux-kernel, Sudeep Holla,
Greg Kroah-Hartman, Peter Hurley, Jiri Slaby, Robin Murphy,
Steven Rostedt, Nair, Jayachandran, Sergey Senozhatsky
In-Reply-To: <20170330055546.GD513@jagdpanzerIV.localdomain>
On Thu 2017-03-30 14:55:46, Sergey Senozhatsky wrote:
> On (03/28/17 14:56), Petr Mladek wrote:
> [..]
> > > > Is it better? If not, I will send a version with console_cmdline_last.
> > >
> > > personally I'm fine with the nested loop. the latest version
> > > "for (last = MAX_CMDLINECONSOLES - 1; last >= 0;..."
> > >
> > > is even easier to read.
> >
> > The number of elements is bumped on a single location, so there
> > is not much to synchronize. The old approach was fine because
> > the for cycles were needed anyway, they started on the 0th element,
> > and NULL ended arrays are rather common practice.
> >
> > But we are searching the array from the end now. Also we use the
> > for cycle just to get the number here. This is not a common
> > practice and it makes the code more complicated and strange from
> > my point of view.
>
> I'm fine with either way :)
Alekesey, any chance to use the global variable to count used or point
to the last element?
I know that you have already spent a lot of time with it. It was great
work. But the current solution of the cycle looks weird to me.
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH v3 3/3] serial: samsung: Remove useless spinlock
From: Krzysztof Kozlowski @ 2017-04-04 9:36 UTC (permalink / raw)
To: Marek Szyprowski
Cc: linux-samsung-soc, linux-serial, Sylwester Nawrocki,
Bartlomiej Zolnierkiewicz, Greg Kroah-Hartman, Seung-Woo Kim,
Joonyoung Shim, Inki Dae
In-Reply-To: <1491200468-28463-3-git-send-email-m.szyprowski@samsung.com>
On Mon, Apr 03, 2017 at 08:21:01AM +0200, Marek Szyprowski wrote:
> Spinlock taken only for dma_map_single() for TX buffer is completely
> useless and doesn't protect anything, so remove it to simplify the code.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> drivers/tty/serial/samsung.c | 4 ----
> 1 file changed, 4 deletions(-)
>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 2/3] serial: samsung: Add missing checks for dma_map_single failure
From: Krzysztof Kozlowski @ 2017-04-04 9:36 UTC (permalink / raw)
To: Marek Szyprowski
Cc: linux-samsung-soc, linux-serial, Sylwester Nawrocki,
Bartlomiej Zolnierkiewicz, Greg Kroah-Hartman, Seung-Woo Kim,
Joonyoung Shim, Inki Dae, stable
In-Reply-To: <1491200468-28463-2-git-send-email-m.szyprowski@samsung.com>
On Mon, Apr 03, 2017 at 08:21:00AM +0200, Marek Szyprowski wrote:
> This patch adds missing checks for dma_map_single() failure and proper error
> reporting. Although this issue was harmless on ARM architecture, it is always
> good to use the DMA mapping API in a proper way. This patch fixes the following
> DMA API debug warning:
>
> WARNING: CPU: 1 PID: 3785 at lib/dma-debug.c:1171 check_unmap+0x8a0/0xf28
> dma-pl330 121a0000.pdma: DMA-API: device driver failed to check map error[device address=0x000000006e0f9000] [size=4096 bytes] [mapped as single]
> Modules linked in:
> CPU: 1 PID: 3785 Comm: (agetty) Tainted: G W 4.11.0-rc1-00137-g07ca963-dirty #59
> Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [<c011aaa4>] (unwind_backtrace) from [<c01127c0>] (show_stack+0x20/0x24)
> [<c01127c0>] (show_stack) from [<c06ba5d8>] (dump_stack+0x84/0xa0)
> [<c06ba5d8>] (dump_stack) from [<c0139528>] (__warn+0x14c/0x180)
> [<c0139528>] (__warn) from [<c01395a4>] (warn_slowpath_fmt+0x48/0x50)
> [<c01395a4>] (warn_slowpath_fmt) from [<c072a114>] (check_unmap+0x8a0/0xf28)
> [<c072a114>] (check_unmap) from [<c072a834>] (debug_dma_unmap_page+0x98/0xc8)
> [<c072a834>] (debug_dma_unmap_page) from [<c0803874>] (s3c24xx_serial_shutdown+0x314/0x52c)
> [<c0803874>] (s3c24xx_serial_shutdown) from [<c07f5124>] (uart_port_shutdown+0x54/0x88)
> [<c07f5124>] (uart_port_shutdown) from [<c07f522c>] (uart_shutdown+0xd4/0x110)
> [<c07f522c>] (uart_shutdown) from [<c07f6a8c>] (uart_hangup+0x9c/0x208)
> [<c07f6a8c>] (uart_hangup) from [<c07c426c>] (__tty_hangup+0x49c/0x634)
> [<c07c426c>] (__tty_hangup) from [<c07c78ac>] (tty_ioctl+0xc88/0x16e4)
> [<c07c78ac>] (tty_ioctl) from [<c03b5f2c>] (do_vfs_ioctl+0xc4/0xd10)
> [<c03b5f2c>] (do_vfs_ioctl) from [<c03b6bf4>] (SyS_ioctl+0x7c/0x8c)
> [<c03b6bf4>] (SyS_ioctl) from [<c010b4a0>] (ret_fast_syscall+0x0/0x3c)
>
> Reported-by: Seung-Woo Kim <sw0312.kim@samsung.com>
> Fixes: 62c37eedb74c8 ("serial: samsung: add dma reqest/release functions")
> CC: stable@vger.kernel.org # v4.10+
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> ---
> This issue was there since adding DMA support, but this patch applies cleanly
> only to v4.10+ kernels due to other changes in the surrounding code.
>
> v3:
> - moved spinlock removal to separate patch, extended commit message
Thanks for the changes, looks fine.
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems
From: Stuart Longland @ 2017-04-04 0:39 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Greg Kroah-Hartman, linux-kernel, Andi Kleen, linux-serial,
Jiri Slaby, linux-arm-kernel
In-Reply-To: <alpine.LFD.2.20.1704022040380.1847@knanqh.ubzr>
[-- Attachment #1.1.1: Type: text/plain, Size: 2703 bytes --]
On 03/04/17 11:01, Nicolas Pitre wrote:
> On Mon, 3 Apr 2017, Stuart Longland wrote:
>> On 03/04/17 07:41, Nicolas Pitre wrote:
>>>> No PTYs seems like a big limitation. This means no sshd?
>>> Again, my ultimate system target is in the sub-megabyte of RAM. I
>>> really doubt you'll be able to fit an SSH server in there even if PTYs
>>> were supported, unless sshd (or dropbear) can be made really tiny.
>>> Otherwise you most probably have sufficient resources to run the regular
>>> TTY code.
>>
>> Are we talking small microcontrollers here? The smallest machine in
>> terms of RAM I ever recall running Linux on was a 386SX/25 MHz with 4MB
>> RAM, and that had a MMU.
>
> Not to repeat what I've said already, I invite you to have a look at
> https://lkml.org/lkml/2017/3/24/634
>
>> I recall Slackware requiring that you booted with a mounted floppy (no
>> ramdisk) and possibly even required that you had a second floppy drive
>> formatted as swap so you'd be able to get through the install without
>> oomkiller knocking on your door.
>
> Did the oom killer even exist in those days? I don't remember.
> All I remember is the stack of 73 flopies or so to install Slackware...
> and of course floppy #68 would have developed a bad sector preventing
> you from completing the installation.
It probably didn't, my memory is a bit hazy, even though the machine in
question was long obsolete by the time I did this experiment. The
version of Slackware was pretty old by that time too.
Luckily for me, I had a network, I could mount the CD disk sets over NFS
that way, and so the only floppies I had to worry about were the boot
and root floppies.
But I digress… :-)
>> Sub-megabyte system support is a noble goal, but I'm wondering how
>> practical such systems would be, and whether an embedded real-time
>> kernel might be a better choice than Linux on such systems.
>
> Obviously, you need to leave the idea of a _distribution_ behind. If you
> think of a single user app, and a kernel that only provides those
> syscalls used by that app, and the minimal subset of kernel services
> that such an app require, then nothing prevents such and app/kernel from
> using the actual Linux API. And that's where you get a big advantage
> over other RTOSes. See the link above for the full rationale.
Fair enough… so basically using the Linux kernel in place of an embedded
kernel like FreeRTOS or eCos. Still, as I say a noble goal, I wish the
project well. I guess it can be our answer to RetroBSD. :-)
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems
From: Andy Shevchenko @ 2017-04-03 21:05 UTC (permalink / raw)
To: Geert Uytterhoeven, Tom Zanussi
Cc: Stuart Longland, Nicolas Pitre, Andi Kleen, Greg Kroah-Hartman,
Jiri Slaby, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAMuHMdUTW7Fh+3kWKFCToqhaz-+58--=Sx1Zv0KRnVY4bDKOGQ@mail.gmail.com>
+Cc: Tom
Summon Tom to the discussion. He tried once hard to shrink a Linux
kernel to something working in 1M+ RAM on x86.
Tom, sorry, I recall this a bit late, perhaps you might be interested
in reading discussion from the beginning.
On Mon, Apr 3, 2017 at 9:14 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Mon, Apr 3, 2017 at 12:44 AM, Stuart Longland
> <stuartl@longlandclan.id.au> wrote:
>> On 03/04/17 07:41, Nicolas Pitre wrote:
>>>> No PTYs seems like a big limitation. This means no sshd?
>>> Again, my ultimate system target is in the sub-megabyte of RAM. I
>>> really doubt you'll be able to fit an SSH server in there even if PTYs
>>> were supported, unless sshd (or dropbear) can be made really tiny.
>>> Otherwise you most probably have sufficient resources to run the regular
>>> TTY code.
>>
>> Are we talking small microcontrollers here? The smallest machine in
>> terms of RAM I ever recall running Linux on was a 386SX/25 MHz with 4MB
>> RAM, and that had a MMU.
>
> Let's halve that. I once tried and ran Linux in 2 MiB, incl. X, twm, and xterm.
> Of course with swap enabled. And swapping like hell.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox