* Re: [PATCH v3 2/2] kconfig: rename silentoldconfig to syncconfig
From: Ulf Magnusson @ 2018-03-01 14:10 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Linux Kbuild mailing list, Sam Ravnborg, Randy Dunlap,
Marc Herbert, Linux Kernel Mailing List, open list:DOCUMENTATION,
Jonathan Corbet, Jeff Kirsher, Michal Marek, intel-wired-lan
In-Reply-To: <1519886077-31914-2-git-send-email-yamada.masahiro@socionext.com>
On Thu, Mar 1, 2018 at 7:34 AM, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
> As commit cedd55d49dee ("kconfig: Remove silentoldconfig from help
> and docs; fix kconfig/conf's help") mentioned, 'silentoldconfig' is a
> historical misnomer. That commit removed it from help and docs since
> it is an internal interface. If so, it should be allowed to rename
> it to something more intuitive. 'syncconfig' is the one I came up
> with because it updates the .config if necessary, then synchronize
> include/generated/autoconf.h and include/config/* with it.
>
> You should not manually invoke 'silentoldcofig'. Display warning if
> used in case existing scripts are doing wrong.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
>
> Changes in v3:
> - Fix Documentation/networking/i40e.txt
> - Display warning if silentoldconfig is used
>
> Changes in v2:
> - newly added
>
> Documentation/kbuild/kconfig.txt | 2 +-
> Documentation/networking/i40e.txt | 2 +-
> Makefile | 2 +-
> scripts/kconfig/Makefile | 13 ++++++++++---
> scripts/kconfig/conf.c | 20 ++++++++++----------
> 5 files changed, 23 insertions(+), 16 deletions(-)
>
> diff --git a/Documentation/kbuild/kconfig.txt b/Documentation/kbuild/kconfig.txt
> index bbc99c0..7233118 100644
> --- a/Documentation/kbuild/kconfig.txt
> +++ b/Documentation/kbuild/kconfig.txt
> @@ -119,7 +119,7 @@ Examples:
> 15% of tristates will be set to 'y', 15% to 'm', 70% to 'n'
>
> ______________________________________________________________________
> -Environment variables for 'silentoldconfig'
> +Environment variables for 'syncconfig'
>
> KCONFIG_NOSILENTUPDATE
> --------------------------------------------------
> diff --git a/Documentation/networking/i40e.txt b/Documentation/networking/i40e.txt
> index 57e616e..c2d6e18 100644
> --- a/Documentation/networking/i40e.txt
> +++ b/Documentation/networking/i40e.txt
> @@ -32,7 +32,7 @@ Enabling the driver
> The driver is enabled via the standard kernel configuration system,
> using the make command:
>
> - Make oldconfig/silentoldconfig/menuconfig/etc.
> + make config/oldconfig/menuconfig/etc.
>
> The driver is located in the menu structure at:
>
> diff --git a/Makefile b/Makefile
> index 7f0aba6..4fb97e9 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -597,7 +597,7 @@ $(KCONFIG_CONFIG) include/config/auto.conf.cmd: ;
> # include/generated/ and include/config/. Update them if .config is newer than
> # include/config/auto.conf (which mirrors .config).
> include/config/%.conf: $(KCONFIG_CONFIG) include/config/auto.conf.cmd
> - $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
> + $(Q)$(MAKE) -f $(srctree)/Makefile syncconfig
> else
> # external modules needs include/generated/autoconf.h and include/config/auto.conf
> # but do not care if they are up-to-date. Use auto.conf to trigger the test
> diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
> index 41e2a9f..753a6de4 100644
> --- a/scripts/kconfig/Makefile
> +++ b/scripts/kconfig/Makefile
> @@ -3,7 +3,7 @@
> # Kernel configuration targets
> # These targets are used from top-level makefile
>
> -PHONY += xconfig gconfig menuconfig config silentoldconfig update-po-config \
> +PHONY += xconfig gconfig menuconfig config syncconfig update-po-config \
> localmodconfig localyesconfig
>
> ifdef KBUILD_KCONFIG
> @@ -36,7 +36,7 @@ nconfig: $(obj)/nconf
>
> # This has become an internal implementation detail and is now deprecated
> # for external use.
> -silentoldconfig: $(obj)/conf
> +syncconfig: $(obj)/conf
> $(Q)mkdir -p include/config include/generated
> $(Q)test -e include/generated/autoksyms.h || \
> touch include/generated/autoksyms.h
> @@ -88,7 +88,7 @@ PHONY += $(simple-targets)
> $(simple-targets): $(obj)/conf
> $< $(silent) --$@ $(Kconfig)
>
> -PHONY += oldnoconfig savedefconfig defconfig
> +PHONY += oldnoconfig silentoldconfig savedefconfig defconfig
>
> # oldnoconfig is an alias of olddefconfig, because people already are dependent
> # on its behavior (sets new symbols to their default value but not 'n') with the
> @@ -97,6 +97,13 @@ oldnoconfig: olddefconfig
> @echo " WARNING: \"oldnoconfig\" target will be removed after Linux 4.19"
> @echo " Please use \"olddefconfig\" instead, which is an alias."
>
> +# We do not expect manual invokcation of "silentoldcofig" (or "syncconfig").
> +silentoldconfig: syncconfig
> + @echo " WARNING: \"silentoldconfig\" has been renamed to \"syncconfig\""
> + @echo " and is now an internal implementation detail."
> + @echo " What you want is probably \"oldconfig\"."
> + @echo " \"silentoldconfig\" will be removed after Linux 4.19"
> +
> savedefconfig: $(obj)/conf
> $< $(silent) --$@=defconfig $(Kconfig)
>
> diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
> index 11a4e45..4e08121 100644
> --- a/scripts/kconfig/conf.c
> +++ b/scripts/kconfig/conf.c
> @@ -23,7 +23,7 @@ static void check_conf(struct menu *menu);
>
> enum input_mode {
> oldaskconfig,
> - silentoldconfig,
> + syncconfig,
> oldconfig,
> allnoconfig,
> allyesconfig,
> @@ -100,7 +100,7 @@ static int conf_askvalue(struct symbol *sym, const char *def)
>
> switch (input_mode) {
> case oldconfig:
> - case silentoldconfig:
> + case syncconfig:
> if (sym_has_value(sym)) {
> printf("%s\n", def);
> return 0;
> @@ -293,7 +293,7 @@ static int conf_choice(struct menu *menu)
> printf("[1-%d?]: ", cnt);
> switch (input_mode) {
> case oldconfig:
> - case silentoldconfig:
> + case syncconfig:
> if (!is_new) {
> cnt = def;
> printf("%d\n", cnt);
> @@ -441,7 +441,7 @@ static void check_conf(struct menu *menu)
> static struct option long_opts[] = {
> {"oldaskconfig", no_argument, NULL, oldaskconfig},
> {"oldconfig", no_argument, NULL, oldconfig},
> - {"silentoldconfig", no_argument, NULL, silentoldconfig},
> + {"syncconfig", no_argument, NULL, syncconfig},
> {"defconfig", optional_argument, NULL, defconfig},
> {"savedefconfig", required_argument, NULL, savedefconfig},
> {"allnoconfig", no_argument, NULL, allnoconfig},
> @@ -468,8 +468,8 @@ static void conf_usage(const char *progname)
> printf(" --listnewconfig List new options\n");
> printf(" --oldaskconfig Start a new configuration using a line-oriented program\n");
> printf(" --oldconfig Update a configuration using a provided .config as base\n");
> - printf(" --silentoldconfig Similar to oldconfig but generates configuration in\n"
> - " include/{generated/,config/} (oldconfig used to be more verbose)\n");
> + printf(" --syncconfig Similar to oldconfig but generates configuration in\n"
> + " include/{generated/,config/}\n");
> printf(" --olddefconfig Same as oldconfig but sets new symbols to their default value\n");
> printf(" --oldnoconfig An alias of olddefconfig\n");
> printf(" --defconfig <file> New config with default defined in <file>\n");
> @@ -501,7 +501,7 @@ int main(int ac, char **av)
> }
> input_mode = (enum input_mode)opt;
> switch (opt) {
> - case silentoldconfig:
> + case syncconfig:
> sync_kconfig = 1;
> break;
> case defconfig:
> @@ -583,7 +583,7 @@ int main(int ac, char **av)
> }
> break;
> case savedefconfig:
> - case silentoldconfig:
> + case syncconfig:
> case oldaskconfig:
> case oldconfig:
> case listnewconfig:
> @@ -667,7 +667,7 @@ int main(int ac, char **av)
> /* fall through */
> case oldconfig:
> case listnewconfig:
> - case silentoldconfig:
> + case syncconfig:
> /* Update until a loop caused no more changes */
> do {
> conf_cnt = 0;
> @@ -680,7 +680,7 @@ int main(int ac, char **av)
> }
>
> if (sync_kconfig) {
> - /* silentoldconfig is used during the build so we shall update autoconf.
> + /* syncconfig is used during the build so we shall update autoconf.
> * All other commands are only used to generate a config.
> */
> if (conf_get_changed() && conf_write(NULL)) {
> --
> 2.7.4
>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
Cheers,
Ulf
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] char/bsr: add sysfs interface documentation
From: Aishwarya Pant @ 2018-03-01 18:25 UTC (permalink / raw)
To: Arnd Bergmann, linux-kernel, Jonathan Corbet; +Cc: Julia Lawall, linux-doc
Descriptions have collected from code comments and by reading through
code.
Signed-off-by: Aishwarya Pant <aishpant@gmail.com>
---
Documentation/ABI/testing/sysfs-class-bsr | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-bsr
diff --git a/Documentation/ABI/testing/sysfs-class-bsr b/Documentation/ABI/testing/sysfs-class-bsr
new file mode 100644
index 000000000000..7bf145d32cbc
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-bsr
@@ -0,0 +1,25 @@
+What: /sys/class/bsr/bsr*/bsr_size
+Date: Jul, 2008
+KernelVersion: 2.6.27
+Contact: Arnd Bergmann <arnd@arndb.de>,
+ Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Description:
+ (RO) Size of the barrier-synchronization register (BSR)
+ register in bytes.
+
+What: /sys/class/bsr/bsr*/bsr_length
+Date: Jul, 2008
+KernelVersion: 2.6.27
+Contact: Arnd Bergmann <arnd@arndb.de>,
+ Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Description:
+ (RO) The length of memory region that can be mapped in bytes.
+
+What: /sys/class/bsr/bsr*/bsr_stride
+Date: Jul, 2008
+KernelVersion: 2.6.27
+Contact: Arnd Bergmann <arnd@arndb.de>,
+ Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Description:
+ (RO) The stride or the interval at which the allocated BSR bytes
+ repeat within the mapping.
--
2.16.2
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2] earlycon: Allow specifying a uartclk in options
From: Daniel Kurtz @ 2018-03-01 18:43 UTC (permalink / raw)
Cc: adurbin, briannorris, Daniel Kurtz, Jonathan Corbet,
Greg Kroah-Hartman, Jiri Slaby, Ingo Molnar, Thomas Gleixner,
Christoffer Dall, Paul E. McKenney, Marc Zyngier,
Frederic Weisbecker, David Woodhouse, Tom Saeger, Mimi Zohar,
Levin, Alexander (Sasha Levin), open list:DOCUMENTATION,
open list, open list:SERIAL DRIVERS
Currently when an earlycon is registered, the uartclk is assumed to be
BASE_BAUD * 16 = 1843200. If a baud rate is specified in the earlycon
options, then 8250_early's init_port will program the UART clock divider
registers based on this assumed uartclk.
However, not all uarts have a UART clock of 1843200. For example, the
8250_dw uart in AMD's CZ/ST uses a fixed 48 MHz clock (as specified in
cz_uart_desc in acpi_apd.c). Thus, specifying a baud when using earlycon
on such a device will result in incorrect divider values and a wrong UART
clock.
Fix this by extending the earlycon options parameter to allow specification
of a uartclk, like so:
earlycon=uart,mmio32,0xfedc6000,115200,48000000
If none is specified, fall-back to prior behavior - 1843200.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
---
Documentation/admin-guide/kernel-parameters.txt | 3 +++
drivers/tty/serial/earlycon.c | 8 ++++++--
include/linux/serial_core.h | 2 +-
3 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 1d1d53f85ddd..20e72cada38e 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -958,6 +958,9 @@
to be equivalent to 'mmio'. 'options' are specified
in the same format described for "console=ttyS<n>"; if
unspecified, the h/w is not initialized.
+ A UART clock rate can also be appended after the baud,
+ as in <options> = 115200n8,48000000; if unspecified,
+ the default 1843200 will be used.
pl011,<addr>
pl011,mmio32,<addr>
diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index 870e84fb6e39..e846f406a1c6 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -115,12 +115,17 @@ static int __init parse_options(struct earlycon_device *device, char *options)
}
if (options) {
- device->baud = simple_strtoul(options, NULL, 0);
+ char *uartclk;
+ device->baud = simple_strtoul(options, &uartclk, 0);
+ if (*uartclk++ == ',')
+ port->uartclk = simple_strtoul(uartclk, NULL, 0);
length = min(strcspn(options, " ") + 1,
(size_t)(sizeof(device->options)));
strlcpy(device->options, options, length);
}
+ port->uartclk = (port->uartclk) ?: BASE_BAUD * 16;
+
return 0;
}
@@ -134,7 +139,6 @@ static int __init register_earlycon(char *buf, const struct earlycon_id *match)
buf = NULL;
spin_lock_init(&port->lock);
- port->uartclk = BASE_BAUD * 16;
if (port->mapbase)
port->membase = earlycon_map(port->mapbase, 64);
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index b32df49a3bd5..b772f0d20b18 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -343,7 +343,7 @@ static inline int uart_poll_timeout(struct uart_port *port)
struct earlycon_device {
struct console *con;
struct uart_port port;
- char options[16]; /* e.g., 115200n8 */
+ char options[32]; /* e.g., 115200n8,48000000 */
unsigned int baud;
};
--
2.16.2.395.g2e18187dfd-goog
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v2] earlycon: Allow specifying a uartclk in options
From: Andy Shevchenko @ 2018-03-01 18:47 UTC (permalink / raw)
To: Daniel Kurtz
Cc: adurbin, Brian Norris, Jonathan Corbet, Greg Kroah-Hartman,
Jiri Slaby, Ingo Molnar, Thomas Gleixner, Christoffer Dall,
Paul E. McKenney, Marc Zyngier, Frederic Weisbecker,
David Woodhouse, Tom Saeger, Mimi Zohar,
Levin, Alexander (Sasha Levin), open list:DOCUMENTATION,
open list, open list:SERIAL DRIVERS
In-Reply-To: <20180301184335.248378-1-djkurtz@chromium.org>
On Thu, Mar 1, 2018 at 8:43 PM, Daniel Kurtz <djkurtz@chromium.org> wrote:
Please, hold on with new versions.
I'm not satisfied (yet?) by the approach.
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] earlycon: Allow specifying a uartclk in options
From: Daniel Kurtz @ 2018-03-01 19:22 UTC (permalink / raw)
To: Andy Shevchenko
Cc: adurbin, Brian Norris, corbet, Greg Kroah-Hartman, jslaby, mingo,
Thomas Gleixner, cdall, paulmck, marc.zyngier, frederic, dwmw,
tom.saeger, zohar, alexander.levin, linux-doc, linux-kernel,
linux-serial
In-Reply-To: <CAHp75VfHuNHnjMqsvLZPSNeP57YX1CDZgf=EH-JNSh5bAVdUBA@mail.gmail.com>
On Thu, Mar 1, 2018 at 11:47 AM Andy Shevchenko <andy.shevchenko@gmail.com>
wrote:
> On Thu, Mar 1, 2018 at 8:43 PM, Daniel Kurtz <djkurtz@chromium.org> wrote:
> Please, hold on with new versions.
> I'm not satisfied (yet?) by the approach.
Copying over your comment on v1:
> It needs to be discussed.
Sure.
> First of all, if you are going to do this you need to add a parse of
> human readable formats (IIRC kernel has helpers), i.e. "48M", "38.4M"
> and so on.
> Next, I was under impression that purpose of earlycon (in difference
> to earlyprintk) is to re-use existing drivers as fully as possible.
> So, what exactly happens in your case? Are your driver lacks of
> properly set clock? Or earlycon does simple not utilizing this
> information?
"earlycon simply does not utilize the information".
earlycon parses iotype, mapbase and baud (from options). However, it is
hard-coded to assume that the clock used to generate the UART bitclock is
always "BASE_BAUD * 16" (1843200). While this may be true for many UARTs,
it isn't true for AMD's CZ/ST which has a 8250_dw and uses a fixed 48 MHz
clock. The main 8250_dw driver uses devm_clk_get to get the "baudclk" and
uses its rate to initialize uartclk. For AMD CZ/ST, this "baudclk" is
actually a set up in acpi_apd.c when there is an acpi match for "AMD0020",
with a rate read from the .fixed_clk_rate param of the corresponding
apd_device_desc.
This patch attempts to add a way to inform earlycon about this clock. As
noted above, the information is actually already in the kernel and used by
8250_dw - I would happy be to hear recommendations for wiring this data
into earlycon that doesn't require adding another command line arg.
I see that support was also added recently to earlycon to let it use ACPI
SPCR to choose a console and configure its parameters... but AFAICT, this
path also doesn't allow specifying the uart clock.
-Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] earlycon: Allow specifying a uartclk in options
From: Andy Shevchenko @ 2018-03-01 20:02 UTC (permalink / raw)
To: Daniel Kurtz
Cc: adurbin, Brian Norris, Jonathan Corbet, Greg Kroah-Hartman,
Jiri Slaby, Ingo Molnar, Thomas Gleixner, Christoffer Dall,
Paul E. McKenney, Marc Zyngier, Frederic Weisbecker,
David Woodhouse, Tom Saeger, Mimi Zohar,
Levin, Alexander (Sasha Levin), Linux Documentation List,
Linux Kernel Mailing List, open list:SERIAL DRIVERS
In-Reply-To: <CAGS+omCfVUPb0yq3XOEqO_zQ0_uppkKaGhqtB0OqXmQDK9xH1Q@mail.gmail.com>
On Thu, Mar 1, 2018 at 9:22 PM, Daniel Kurtz <djkurtz@chromium.org> wrote:
> On Thu, Mar 1, 2018 at 11:47 AM Andy Shevchenko <andy.shevchenko@gmail.com>
> wrote:
> "earlycon simply does not utilize the information".
>
> earlycon parses iotype, mapbase and baud (from options). However, it is
> hard-coded to assume that the clock used to generate the UART bitclock is
> always "BASE_BAUD * 16" (1843200). While this may be true for many UARTs,
> it isn't true for AMD's CZ/ST which has a 8250_dw and uses a fixed 48 MHz
> clock. The main 8250_dw driver uses devm_clk_get to get the "baudclk" and
> uses its rate to initialize uartclk. For AMD CZ/ST, this "baudclk" is
> actually a set up in acpi_apd.c when there is an acpi match for "AMD0020",
> with a rate read from the .fixed_clk_rate param of the corresponding
> apd_device_desc.
>
> This patch attempts to add a way to inform earlycon about this clock. As
> noted above, the information is actually already in the kernel and used by
> 8250_dw - I would happy be to hear recommendations for wiring this data
> into earlycon that doesn't require adding another command line arg.
And it should not require that for sure!
I would look to this later. It's late here. I need to do a bit of
research for the answer.
> I see that support was also added recently to earlycon to let it use ACPI
> SPCR to choose a console and configure its parameters... but AFAICT, this
> path also doesn't allow specifying the uart clock.
Fix your firmware then. It should set console to 115200 like (almost)
everyone does.
Okay, configures a necessary IPs to feed UART with expected 1.8432M clock.
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] earlycon: Allow specifying a uartclk in options
From: Aaron Durbin @ 2018-03-01 21:24 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Daniel Kurtz, Aaron Durbin, Brian Norris, Jonathan Corbet,
Greg Kroah-Hartman, Jiri Slaby, Ingo Molnar, Thomas Gleixner,
Christoffer Dall, Paul E. McKenney, Marc Zyngier,
Frederic Weisbecker, David Woodhouse, Tom Saeger, Mimi Zohar,
Levin, Alexander (Sasha Levin), Linux Documentation List,
Linux Kernel Mailing List, open list:SERIAL DRIVERS
In-Reply-To: <CAHp75VfL82ujwBa1h0B8nEgBtFcBJPmS9ir7H5YWByDgxFGskA@mail.gmail.com>
On Thu, Mar 1, 2018 at 1:02 PM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Thu, Mar 1, 2018 at 9:22 PM, Daniel Kurtz <djkurtz@chromium.org> wrote:
>> On Thu, Mar 1, 2018 at 11:47 AM Andy Shevchenko <andy.shevchenko@gmail.com>
>> wrote:
>
>> "earlycon simply does not utilize the information".
>>
>> earlycon parses iotype, mapbase and baud (from options). However, it is
>> hard-coded to assume that the clock used to generate the UART bitclock is
>> always "BASE_BAUD * 16" (1843200). While this may be true for many UARTs,
>> it isn't true for AMD's CZ/ST which has a 8250_dw and uses a fixed 48 MHz
>> clock. The main 8250_dw driver uses devm_clk_get to get the "baudclk" and
>> uses its rate to initialize uartclk. For AMD CZ/ST, this "baudclk" is
>> actually a set up in acpi_apd.c when there is an acpi match for "AMD0020",
>> with a rate read from the .fixed_clk_rate param of the corresponding
>> apd_device_desc.
>>
>> This patch attempts to add a way to inform earlycon about this clock. As
>> noted above, the information is actually already in the kernel and used by
>> 8250_dw - I would happy be to hear recommendations for wiring this data
>> into earlycon that doesn't require adding another command line arg.
>
> And it should not require that for sure!
But it does require that. There's an input clock to the uart ip block.
That is a design constraint by the hardware and is required to make
baud calculation work.
>
> I would look to this later. It's late here. I need to do a bit of
> research for the answer.
>
>> I see that support was also added recently to earlycon to let it use ACPI
>> SPCR to choose a console and configure its parameters... but AFAICT, this
>> path also doesn't allow specifying the uart clock.
>
> Fix your firmware then. It should set console to 115200 like (almost)
> everyone does.
It's not a firmware problem. Its the driver's problem in that it
assumes an input clock to the uart block that does not reflect
reality.
> Okay, configures a necessary IPs to feed UART with expected 1.8432M clock.
That's only possible if there is a clock divider on the front end of
the uart block. For this hardware that's not the case. I actually did
this very thing on intel chromebook devices, but it was only possible
because there was a hardware divider that could be tuned to reach the
assumed clock that the code currently assumes.
>
> --
> With Best Regards,
> Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 05/10] hwmon: generic-pwm-tachometer: Add generic PWM based tachometer
From: Rob Herring @ 2018-03-01 22:08 UTC (permalink / raw)
To: Mikko Perttunen
Cc: Guenter Roeck, Rajkumar Rampelli, mark.rutland, thierry.reding,
jonathanh, jdelvare, corbet, catalin.marinas, will.deacon,
kstewart, gregkh, pombredanne, mmaddireddy, mperttunen, arnd,
gregory.clement, timur, andy.gross, xuwei5, elder, heiko, krzk,
ard.biesheuvel, devicetree, linux-kernel, linux-pwm, linux-tegra,
linux-hwmon, linux-doc, linux-arm-kernel, ldewangan
In-Reply-To: <a5db25f7-6999-ff3a-21c2-161cfcf4db35@kapsi.fi>
On Wed, Feb 21, 2018 at 05:20:29PM +0200, Mikko Perttunen wrote:
> On 21.02.2018 16:46, Guenter Roeck wrote:
> > On 02/20/2018 11:15 PM, Mikko Perttunen wrote:
> > > AIUI, the PWM framework already exposes a sysfs node with period
> > > information. We should just use that instead of adding a new driver
> > > for this.
> > >
> >
> > I am kind of lost. Please explain.
> >
> > Are you saying that we should drop the pwm-fan driver as well (which goes
> > the opposite way), as well as any other drivers doing anything with pwm
> > signals,
> > because after all those signals are already exposed to userspace a sysfs
> > attributes,
> > and a kernel driver to abstract those values is thus not needed ?
>
> The only thing this driver does is do a constant division in kernelspace.
> I'm not really seeing why that couldn't be done in userspace. But if you
> think it's appropriate to do the RPM conversion in kernelspace then I'm not
> greatly opposed to that.
>
> >
> > > In any case, we cannot add something like this to device tree since
> > > it's not a hardware device.
> > >
> >
> > So you are saying there is no means to express in devicetree that
> > a pwm input is connected to a fan ? How is that not hardware ?
> >
> > If so, how do you express in devicetree that a pwm signal is connected
> > to anything ?
>
> If we want to describe that the tachometer is connected to a fan, then we
> should have a fan node in the board's device tree. We don't have a chip that
> has a thing called "generic-pwm-tachometer" attached to it. (We have chips
> that have a "nvidia,tegra186-tachometer", so it's proper to have that.)
We already have some fan control bindings in the tree. Follow those.
There's only so many ways to control fans, so lets have some alignment.
And yes, we should have a fan node.
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [RFC 1/5] seq_file: introduce seq_open_data helper
From: Rasmus Villemoes @ 2018-03-01 23:37 UTC (permalink / raw)
To: Jonathan Corbet, Alexander Viro
Cc: Rasmus Villemoes, Tony Luck, linux-ia64, Michael Ellerman,
linuxppc-dev, linux-doc, linux-kernel, linux-fsdevel
There are quite a few callers of seq_open that could be simplified by
setting the ->private member via the seq_open call instead of fetching
file->private_data afterwards.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
I've just included a few examples of possible users of this helper,
there are many more similar cases. As a bonus, the first two fix
potential NULL derefs (if one believes that seq_open can actually
fail).
seq_open_private would have been a better name, but that one is
already taken...
Documentation/filesystems/seq_file.txt | 9 +++++----
fs/seq_file.c | 9 ++++++++-
include/linux/seq_file.h | 1 +
3 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/Documentation/filesystems/seq_file.txt b/Documentation/filesystems/seq_file.txt
index 9de4303201e1..68571b8275d8 100644
--- a/Documentation/filesystems/seq_file.txt
+++ b/Documentation/filesystems/seq_file.txt
@@ -234,10 +234,11 @@ Here, the call to seq_open() takes the seq_operations structure we created
before, and gets set up to iterate through the virtual file.
On a successful open, seq_open() stores the struct seq_file pointer in
-file->private_data. If you have an application where the same iterator can
-be used for more than one file, you can store an arbitrary pointer in the
-private field of the seq_file structure; that value can then be retrieved
-by the iterator functions.
+file->private_data. If you have an application where the same iterator
+can be used for more than one file, you can store an arbitrary pointer
+in the private field of the seq_file structure; that value can then be
+retrieved by the iterator functions. Using the wrapper seq_open_data()
+allows you to set the initial value for that field.
There is also a wrapper function to seq_open() called seq_open_private(). It
kmallocs a zero filled block of memory and stores a pointer to it in the
diff --git a/fs/seq_file.c b/fs/seq_file.c
index eea09f6d8830..f2145cb6e23d 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -45,7 +45,7 @@ static void *seq_buf_alloc(unsigned long size)
* Note: seq_open() will allocate a struct seq_file and store its
* pointer in @file->private_data. This pointer should not be modified.
*/
-int seq_open(struct file *file, const struct seq_operations *op)
+int seq_open_data(struct file *file, const struct seq_operations *op, void *data)
{
struct seq_file *p;
@@ -59,6 +59,7 @@ int seq_open(struct file *file, const struct seq_operations *op)
mutex_init(&p->lock);
p->op = op;
+ p->private = data;
// No refcounting: the lifetime of 'p' is constrained
// to the lifetime of the file.
@@ -85,6 +86,12 @@ int seq_open(struct file *file, const struct seq_operations *op)
}
EXPORT_SYMBOL(seq_open);
+int seq_open(struct file *file, const struct seq_operations *op)
+{
+ return seq_open_data(file, op, NULL);
+}
+EXPORT_SYMBOL(seq_open_data);
+
static int traverse(struct seq_file *m, loff_t offset)
{
loff_t pos = 0, index;
diff --git a/include/linux/seq_file.h b/include/linux/seq_file.h
index ab437dd2e3b9..f5ff376fa62b 100644
--- a/include/linux/seq_file.h
+++ b/include/linux/seq_file.h
@@ -107,6 +107,7 @@ void seq_pad(struct seq_file *m, char c);
char *mangle_path(char *s, const char *p, const char *esc);
int seq_open(struct file *, const struct seq_operations *);
+int seq_open_data(struct file *, const struct seq_operations *, void *);
ssize_t seq_read(struct file *, char __user *, size_t, loff_t *);
loff_t seq_lseek(struct file *, loff_t, int);
int seq_release(struct inode *, struct file *);
--
2.15.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [RFC 1/5] seq_file: introduce seq_open_data helper
From: Andreas Dilger @ 2018-03-01 23:44 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: Jonathan Corbet, Alexander Viro, Tony Luck, linux-ia64,
Michael Ellerman, linuxppc-dev, linux-doc, linux-kernel,
linux-fsdevel
In-Reply-To: <20180301233724.20440-1-linux@rasmusvillemoes.dk>
[-- Attachment #1: Type: text/plain, Size: 4152 bytes --]
On Mar 1, 2018, at 4:37 PM, Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote:
>
> There are quite a few callers of seq_open that could be simplified by
> setting the ->private member via the seq_open call instead of fetching
> file->private_data afterwards.
>
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> ---
> I've just included a few examples of possible users of this helper,
> there are many more similar cases. As a bonus, the first two fix
> potential NULL derefs (if one believes that seq_open can actually
> fail).
>
> seq_open_private would have been a better name, but that one is
> already taken...
>
> Documentation/filesystems/seq_file.txt | 9 +++++----
> fs/seq_file.c | 9 ++++++++-
> include/linux/seq_file.h | 1 +
> 3 files changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/filesystems/seq_file.txt b/Documentation/filesystems/seq_file.txt
> index 9de4303201e1..68571b8275d8 100644
> --- a/Documentation/filesystems/seq_file.txt
> +++ b/Documentation/filesystems/seq_file.txt
> @@ -234,10 +234,11 @@ Here, the call to seq_open() takes the seq_operations structure we created
> before, and gets set up to iterate through the virtual file.
>
> On a successful open, seq_open() stores the struct seq_file pointer in
> -file->private_data. If you have an application where the same iterator can
> -be used for more than one file, you can store an arbitrary pointer in the
> -private field of the seq_file structure; that value can then be retrieved
> -by the iterator functions.
> +file->private_data. If you have an application where the same iterator
> +can be used for more than one file, you can store an arbitrary pointer
> +in the private field of the seq_file structure; that value can then be
> +retrieved by the iterator functions. Using the wrapper seq_open_data()
> +allows you to set the initial value for that field.
>
> There is also a wrapper function to seq_open() called seq_open_private(). It
> kmallocs a zero filled block of memory and stores a pointer to it in the
> diff --git a/fs/seq_file.c b/fs/seq_file.c
> index eea09f6d8830..f2145cb6e23d 100644
> --- a/fs/seq_file.c
> +++ b/fs/seq_file.c
> @@ -45,7 +45,7 @@ static void *seq_buf_alloc(unsigned long size)
> * Note: seq_open() will allocate a struct seq_file and store its
> * pointer in @file->private_data. This pointer should not be modified.
> */
> -int seq_open(struct file *file, const struct seq_operations *op)
> +int seq_open_data(struct file *file, const struct seq_operations *op, void *data)
> {
> struct seq_file *p;
>
> @@ -59,6 +59,7 @@ int seq_open(struct file *file, const struct seq_operations *op)
>
> mutex_init(&p->lock);
> p->op = op;
> + p->private = data;
>
> // No refcounting: the lifetime of 'p' is constrained
> // to the lifetime of the file.
> @@ -85,6 +86,12 @@ int seq_open(struct file *file, const struct seq_operations *op)
> }
> EXPORT_SYMBOL(seq_open);
>
> +int seq_open(struct file *file, const struct seq_operations *op)
> +{
> + return seq_open_data(file, op, NULL);
> +}
> +EXPORT_SYMBOL(seq_open_data);
This is a bit confusing. You export "seq_open" after seq_open_data(),
and export "seq_open_data" here after seq_open(). Not strictly a bug,
but could become one in the future.
Cheers, Andreas
> +
> static int traverse(struct seq_file *m, loff_t offset)
> {
> loff_t pos = 0, index;
> diff --git a/include/linux/seq_file.h b/include/linux/seq_file.h
> index ab437dd2e3b9..f5ff376fa62b 100644
> --- a/include/linux/seq_file.h
> +++ b/include/linux/seq_file.h
> @@ -107,6 +107,7 @@ void seq_pad(struct seq_file *m, char c);
>
> char *mangle_path(char *s, const char *p, const char *esc);
> int seq_open(struct file *, const struct seq_operations *);
> +int seq_open_data(struct file *, const struct seq_operations *, void *);
> ssize_t seq_read(struct file *, char __user *, size_t, loff_t *);
> loff_t seq_lseek(struct file *, loff_t, int);
> int seq_release(struct inode *, struct file *);
> --
> 2.15.1
>
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 873 bytes --]
^ permalink raw reply
* [PATCH] HID: ntrig: document sysfs interface
From: Aishwarya Pant @ 2018-03-02 5:30 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, linux-input, linux-kernel,
Jonathan Corbet, Greg KH
Cc: Julia Lawall, linux-doc
Add sysfs documentation for N-Trig touchscreens under Documentation/ABI.
Descriptions have been collected from code comments.
Signed-off-by: Aishwarya Pant <aishpant@gmail.com>
---
Documentation/ABI/testing/sysfs-driver-hid-ntrig | 70 ++++++++++++++++++++++++
1 file changed, 70 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-driver-hid-ntrig
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-ntrig b/Documentation/ABI/testing/sysfs-driver-hid-ntrig
new file mode 100644
index 000000000000..e574a5625efe
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-hid-ntrig
@@ -0,0 +1,70 @@
+What: /sys/bus/hid/drivers/ntrig/<dev>/activate_slack
+Date: May, 2010
+KernelVersion: 2.6.35
+Contact: linux-input@vger.kernel.org
+Description:
+ (RW) Number of contact frames ignored before acknowledging the
+ start of activity (activating touch).
+
+
+What: /sys/bus/hid/drivers/ntrig/<dev>/decativate_slack
+Date: May, 2010
+KernelVersion: 2.6.35
+Contact: linux-input@vger.kernel.org
+Description:
+ (RW) Number of empty (no contact) frames ignored before
+ acknowledging the end of activity (deactivating touch).
+
+ When the last finger is removed from the device, it sends a
+ number of empty frames. By holding off on deactivation for a few
+ frames false erroneous disconnects can be tolerated, where the
+ sensor may mistakenly not detect a finger that is still present.
+
+
+What: /sys/bus/hid/drivers/ntrig/<dev>/activation_width
+What: /sys/bus/hid/drivers/ntrig/<dev>/activation_height
+Date: May, 2010
+KernelVersion: 2.6.35
+Contact: linux-input@vger.kernel.org
+Description:
+ Threholds to override activation slack.
+
+ activation_width: (RW) Width threshold to immediately
+ start processing touch events.
+
+ activation_height: (RW) Height threshold to immediately
+ start processing touch events.
+
+
+What: /sys/bus/hid/drivers/ntrig/<dev>/min_width
+What: /sys/bus/hid/drivers/ntrig/<dev>/min_height
+Date: May, 2010
+KernelVersion: 2.6.35
+Contact: linux-input@vger.kernel.org
+Description:
+ Minimum size contact accepted.
+
+ min_width: (RW) Minimum touch contact width to decide
+ activation and activity.
+
+ min_height: (RW) Minimum touch contact height to decide
+ activation and activity.
+
+
+What: /sys/bus/hid/drivers/ntrig/<dev>/sensor_physical_width
+What: /sys/bus/hid/drivers/ntrig/<dev>/sensor_physical_height
+Date: May, 2010
+KernelVersion: 2.6.35
+Contact: linux-input@vger.kernel.org
+Description:
+ (RO) These are internal ranges not used for normal events but
+ useful for tuning.
+
+
+What: /sys/bus/hid/drivers/ntrig/<dev>/sensor_logical_width
+What: /sys/bus/hid/drivers/ntrig/<dev>/sensor_logical_height
+Date: May, 2010
+KernelVersion: 2.6.35
+Contact: linux-input@vger.kernel.org
+Description:
+ (RO) The range for positions reported during activity.
--
2.16.2
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 00/23] kconfig: move compiler capability tests to Kconfig
From: Masahiro Yamada @ 2018-03-02 5:50 UTC (permalink / raw)
To: Ulf Magnusson
Cc: Arnd Bergmann, Rich Felker, Kernel Hardening, X86 ML,
Paul Mackerras, H. Peter Anvin, sparclinux, Sam Ravnborg,
Yoshinori Sato, Jonathan Corbet, Richard Weinberger,
Linux-sh list, Ingo Molnar, Emese Revfy, Kees Cook, uml-devel,
Linux Kbuild mailing list, Peter Oberparleiter, Jeff Dike,
linuxppc-dev, user-mode-linux-user, Thomas Gleixner, Michal Marek,
Greg Kroah-Hartman, Randy Dunlap, open list:DOCUMENTATION,
Linux Kernel Mailing List, Linus Torvalds, David S. Miller
In-Reply-To: <20180221213946.w4v6ywy7fbiy6oyc@huvuddator>
2018-02-22 6:39 GMT+09:00 Ulf Magnusson <ulfalizer@gmail.com>:
> On Wed, Feb 21, 2018 at 09:57:03PM +0900, Masahiro Yamada wrote:
>> 2018-02-21 19:52 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
>> > On Wed, Feb 21, 2018 at 11:20 AM, Masahiro Yamada
>> > <yamada.masahiro@socionext.com> wrote:
>> >> 2018-02-21 18:56 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
>> >>> On Wed, Feb 21, 2018 at 8:38 AM, Masahiro Yamada
>> >>> <yamada.masahiro@socionext.com> wrote:
>> >>>> 2018-02-20 0:18 GMT+09:00 Ulf Magnusson <ulfalizer@gmail.com>:
>> >>
>> >> Let me clarify my concern.
>> >>
>> >> When we test the compiler flag, is there a case
>> >> where a particular flag depends on -m{32,64} ?
>> >>
>> >> For example, is there a compiler that supports -fstack-protector
>> >> for 64bit mode, but unsupports it for 32bit mode?
>> >>
>> >> $(cc-option -m32) -> y
>> >> $(cc-option -m64) -> y
>> >> $(cc-option -fstack-protector) -> y
>> >> $(cc-option -m32 -fstack-protector) -> n
>> >> $(cc-option -m64 -fstack-protector) -> y
>> >>
>> >> I guess this is unlikely to happen,
>> >> but I am not whether it is zero possibility.
>> >>
>> >> If this could happen,
>> >> $(cc-option ) must be evaluated together with
>> >> correct bi-arch option (either -m32 or -m64).
>> >>
>> >>
>> >> Currently, -m32/-m64 is specified in Makefile,
>> >> but we are moving compiler tests to Kconfig
>> >> and, CONFIG_64BIT can be dynamically toggled in Kconfig.
>> >
>> > I don't think it can happen for this particular combination (stack protector
>> > and word size), but I'm sure we'll eventually run into options that
>> > need to be tested in combination. For the current CFLAGS_KERNEL
>> > setting, we definitely have the case of needing the variables to be
>> > evaluated in a specific order.
>> >
>>
>>
>>
>>
>> I was thinking of how we can handle complex cases
>> in the current approach.
>>
>>
>>
>> (Case 1)
>>
>> Compiler flag -foo and -bar interacts, so
>> we also need to check the combination of the two.
>>
>>
>> config CC_HAS_FOO
>> def_bool $(cc-option -foo)
>>
>> config CC_HAS_BAR
>> def_bool $(cc-option -bar)
>>
>> config CC_HAS_FOO_WITH_BAR
>> def_bool $(cc-option -foo -bar)
>>
>>
>>
>> (Case 2)
>> Compiler flag -foo is sensitive to word-size.
>> So, we need to test this option together with -m32/-m64.
>> User can toggle CONFIG_64BIT, like i386/x86_64.
>>
>>
>> config CC_NEEDS_M64
>> def_bool $(cc-option -m64) && 64BIT
>>
>> config CC_NEEDS_M32
>> def_bool $(cc-option -m32) && !64BIT
>>
>> config CC_HAS_FOO
>> bool
>> default $(cc-option -m64 -foo) if CC_NEEDS_M64
>> default $(cc-option -m32 -foo) if CC_NEEDS_M32
>> default $(cc-option -foo)
>>
>>
>>
>> (Case 3)
>> Compiler flag -foo is sensitive to endian-ness.
>>
>>
>> config CC_NEEDS_BIG_ENDIAN
>> def_bool $(cc-option -mbig-endian) && CPU_BIG_ENDIAN
>>
>> config CC_NEEDS_LITTLE_ENDIAN
>> def_bool $(cc-option -mlittle-endian) && CPU_LITTLE_ENDIAN
>>
>> config CC_HAS_FOO
>> bool
>> default $(cc-option -mbig-endian -foo) if CC_NEEDS_BIG_ENDIAN
>> default $(cc-option -mlittle-endian -foo) if CC_NEEDS_LITTLE_ENDIAN
>> default $(cc-option -foo)
>>
>>
>>
>>
>> Hmm, I think I can implement those somehow.
>> But, I hope we do not have many instances like this...
>>
>>
>> If you know more naive cases, please share your knowledge.
>>
>> Thanks!
>>
>>
>> --
>> Best Regards
>> Masahiro Yamada
>
> Would get pretty bad if a test needs to consider multiple symbols.
> Exponential explosion there...
>
>
> I thought some more about the implementation of dynamic (post-parsing)
> functions to see how bad it would get with the current implementation.
>
> Some background on how things work now:
>
> 1. All expression operands in Kconfig are symbols.
>
> 2. Returning '$ENV' or '$(fn foo)' as a T_WORD during parsing gets
> you symbols with those strings as names and S_UNKNOWN type (because
> they act like references to undefined symbols).
>
> 3. For "foo-$(fn foo)", you also get a symbol with that string as its
> name and S_UNKNOWN type (stored among the SYMBOL_CONST symbols)
>
> 4. Symbols with S_UNKNOWN type get their name as their string value,
> and the tristate value n.
>
> So, if you do string expansion on the names of symbols with S_UNKNOWN
> type in sym_calc_value(), you're almost there with the current
> implementation, except for the tristate case.
>
> Maybe you could set the tristate value of S_UNKNOWN symbols depending on
> the string value you end up with. Things are getting pretty confusing at
> that point.
>
> Could have something like S_DYNAMIC as well. More Kconfig complexity...
>
> Then there's other complications:
>
> 1. SYMBOL_CONST is no longer constant.
>
> 2. Dependency loop detection needs to consider symbol references
> within strings.
>
> 3. Dependency loop detection relies on static knowledge of what
> symbols a symbol depends on. That might get messy for certain
> expansions, though it might be things you wouldn't do in practice.
>
> 4. Symbols still need to be properly invalidated. It looks like at
> least menuconfig just does a dumb invalidate-everything whenever
> the value of a symbol is changed though, so it might not require
> extra work. (Bit messier in Kconfiglib, which does minimal
> invalidation to keep scripts fast, but just need to extract a few
> extra deps there.)
>
>
> It looks like dynamic functions could get quite messy, but might be
> doable if absolutely required. There's probably more devils in the
> details though.
>
> I don't think the static function model precludes switching models later
> btw, when people have more experience.
I really want to start with the static function model
and see if we need the dynamic function implementation.
Here is an idea for the migration path in case
we need to do that in the future.
Currently, every time user input is given,
sym_clear_all_valid() is called.
It is not efficient to blindly re-evaluate expensive $(shell ...)
So, have a list of symbols the function depends on
in its arguments.
For example,
config CC_HAS_SANE_STACKPROTECTOR
def_bool $(shell $srctree/scripts/gcc-has-stack-protector.sh
$CC $(1), CFLAGS_BASE)
Here the first argument
$srctree/scripts/gcc-x86-has-stack-protector.sh $CC $(1)
is the shell command.
$(1), $(2), ... will be replaced with the values of symbols (or expressions)
that follow when running the shell command.
The second argument
CFLAGS_BASE
is the dependency symbol (or expression).
CFLAGS_BASE can be dynamically changed like
config CFLAGS_BASE
string
default "-m64" if 64BIT
default "-m32"
When and only when CFLAGS_BASE is updated, the function should be re-calculated.
(This will require efforts to minimize the amount of re-evaluation.)
cc-option will be implemented like follows:
macro cc-option $(shell $CC -Werror $$(1) $(1) -c -x c /dev/null -o
/dev/null, CFLAGS_BASE)
Please notice the difference between $$(1) and $(1).
$(1) is immediately expanded by cc-option macro.
$$(1) is escaped since we want to expand it by $(shell ...), not by
$(cc-option ...)
For example,
$(cc-option -fstack-protector)
will be expanded to
$(shell gcc -Werror $(1) -fstack-protector -c -x c /dev/null -o
/dev/null, CFLAGS_BASE)
Since macros are just textual shorthand, so this expansion happens
during the parse phase.
Then, the evaluation phase does the following every time CFLAGS_BASE is updated.
gcc -Werror [value of CFLAGS_BASE] -fstack-protector -c -x c /dev/null
-o /dev/null
This is a new form of expression, so it will be managed in AST tree
with a flag E_SHELL (or E_FUNC) etc.
Not implemented at all. Just a rough sketch.
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 00/23] kconfig: move compiler capability tests to Kconfig
From: Ulf Magnusson @ 2018-03-02 9:12 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Arnd Bergmann, Rich Felker, Kernel Hardening, X86 ML,
Paul Mackerras, H. Peter Anvin, sparclinux, Sam Ravnborg,
Yoshinori Sato, Jonathan Corbet, Richard Weinberger,
Linux-sh list, Ingo Molnar, Emese Revfy, Kees Cook, uml-devel,
Linux Kbuild mailing list, Peter Oberparleiter, Jeff Dike,
linuxppc-dev, user-mode-linux-user, Thomas Gleixner, Michal Marek,
Greg Kroah-Hartman, Randy Dunlap, open list:DOCUMENTATION,
Linux Kernel Mailing List, Linus Torvalds, David S. Miller
In-Reply-To: <20180302090326.h55wontzv3traxnn@huvuddator>
On Fri, Mar 02, 2018 at 10:03:26AM +0100, Ulf Magnusson wrote:
> On Fri, Mar 02, 2018 at 02:50:39PM +0900, Masahiro Yamada wrote:
> > 2018-02-22 6:39 GMT+09:00 Ulf Magnusson <ulfalizer@gmail.com>:
> > > On Wed, Feb 21, 2018 at 09:57:03PM +0900, Masahiro Yamada wrote:
> > >> 2018-02-21 19:52 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
> > >> > On Wed, Feb 21, 2018 at 11:20 AM, Masahiro Yamada
> > >> > <yamada.masahiro@socionext.com> wrote:
> > >> >> 2018-02-21 18:56 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
> > >> >>> On Wed, Feb 21, 2018 at 8:38 AM, Masahiro Yamada
> > >> >>> <yamada.masahiro@socionext.com> wrote:
> > >> >>>> 2018-02-20 0:18 GMT+09:00 Ulf Magnusson <ulfalizer@gmail.com>:
> > >> >>
> > >> >> Let me clarify my concern.
> > >> >>
> > >> >> When we test the compiler flag, is there a case
> > >> >> where a particular flag depends on -m{32,64} ?
> > >> >>
> > >> >> For example, is there a compiler that supports -fstack-protector
> > >> >> for 64bit mode, but unsupports it for 32bit mode?
> > >> >>
> > >> >> $(cc-option -m32) -> y
> > >> >> $(cc-option -m64) -> y
> > >> >> $(cc-option -fstack-protector) -> y
> > >> >> $(cc-option -m32 -fstack-protector) -> n
> > >> >> $(cc-option -m64 -fstack-protector) -> y
> > >> >>
> > >> >> I guess this is unlikely to happen,
> > >> >> but I am not whether it is zero possibility.
> > >> >>
> > >> >> If this could happen,
> > >> >> $(cc-option ) must be evaluated together with
> > >> >> correct bi-arch option (either -m32 or -m64).
> > >> >>
> > >> >>
> > >> >> Currently, -m32/-m64 is specified in Makefile,
> > >> >> but we are moving compiler tests to Kconfig
> > >> >> and, CONFIG_64BIT can be dynamically toggled in Kconfig.
> > >> >
> > >> > I don't think it can happen for this particular combination (stack protector
> > >> > and word size), but I'm sure we'll eventually run into options that
> > >> > need to be tested in combination. For the current CFLAGS_KERNEL
> > >> > setting, we definitely have the case of needing the variables to be
> > >> > evaluated in a specific order.
> > >> >
> > >>
> > >>
> > >>
> > >>
> > >> I was thinking of how we can handle complex cases
> > >> in the current approach.
> > >>
> > >>
> > >>
> > >> (Case 1)
> > >>
> > >> Compiler flag -foo and -bar interacts, so
> > >> we also need to check the combination of the two.
> > >>
> > >>
> > >> config CC_HAS_FOO
> > >> def_bool $(cc-option -foo)
> > >>
> > >> config CC_HAS_BAR
> > >> def_bool $(cc-option -bar)
> > >>
> > >> config CC_HAS_FOO_WITH_BAR
> > >> def_bool $(cc-option -foo -bar)
> > >>
> > >>
> > >>
> > >> (Case 2)
> > >> Compiler flag -foo is sensitive to word-size.
> > >> So, we need to test this option together with -m32/-m64.
> > >> User can toggle CONFIG_64BIT, like i386/x86_64.
> > >>
> > >>
> > >> config CC_NEEDS_M64
> > >> def_bool $(cc-option -m64) && 64BIT
> > >>
> > >> config CC_NEEDS_M32
> > >> def_bool $(cc-option -m32) && !64BIT
> > >>
> > >> config CC_HAS_FOO
> > >> bool
> > >> default $(cc-option -m64 -foo) if CC_NEEDS_M64
> > >> default $(cc-option -m32 -foo) if CC_NEEDS_M32
> > >> default $(cc-option -foo)
> > >>
> > >>
> > >>
> > >> (Case 3)
> > >> Compiler flag -foo is sensitive to endian-ness.
> > >>
> > >>
> > >> config CC_NEEDS_BIG_ENDIAN
> > >> def_bool $(cc-option -mbig-endian) && CPU_BIG_ENDIAN
> > >>
> > >> config CC_NEEDS_LITTLE_ENDIAN
> > >> def_bool $(cc-option -mlittle-endian) && CPU_LITTLE_ENDIAN
> > >>
> > >> config CC_HAS_FOO
> > >> bool
> > >> default $(cc-option -mbig-endian -foo) if CC_NEEDS_BIG_ENDIAN
> > >> default $(cc-option -mlittle-endian -foo) if CC_NEEDS_LITTLE_ENDIAN
> > >> default $(cc-option -foo)
> > >>
> > >>
> > >>
> > >>
> > >> Hmm, I think I can implement those somehow.
> > >> But, I hope we do not have many instances like this...
> > >>
> > >>
> > >> If you know more naive cases, please share your knowledge.
> > >>
> > >> Thanks!
> > >>
> > >>
> > >> --
> > >> Best Regards
> > >> Masahiro Yamada
> > >
> > > Would get pretty bad if a test needs to consider multiple symbols.
> > > Exponential explosion there...
> > >
> > >
> > > I thought some more about the implementation of dynamic (post-parsing)
> > > functions to see how bad it would get with the current implementation.
> > >
> > > Some background on how things work now:
> > >
> > > 1. All expression operands in Kconfig are symbols.
> > >
> > > 2. Returning '$ENV' or '$(fn foo)' as a T_WORD during parsing gets
> > > you symbols with those strings as names and S_UNKNOWN type (because
> > > they act like references to undefined symbols).
> > >
> > > 3. For "foo-$(fn foo)", you also get a symbol with that string as its
> > > name and S_UNKNOWN type (stored among the SYMBOL_CONST symbols)
> > >
> > > 4. Symbols with S_UNKNOWN type get their name as their string value,
> > > and the tristate value n.
> > >
> > > So, if you do string expansion on the names of symbols with S_UNKNOWN
> > > type in sym_calc_value(), you're almost there with the current
> > > implementation, except for the tristate case.
> > >
> > > Maybe you could set the tristate value of S_UNKNOWN symbols depending on
> > > the string value you end up with. Things are getting pretty confusing at
> > > that point.
> > >
> > > Could have something like S_DYNAMIC as well. More Kconfig complexity...
> > >
> > > Then there's other complications:
> > >
> > > 1. SYMBOL_CONST is no longer constant.
> > >
> > > 2. Dependency loop detection needs to consider symbol references
> > > within strings.
> > >
> > > 3. Dependency loop detection relies on static knowledge of what
> > > symbols a symbol depends on. That might get messy for certain
> > > expansions, though it might be things you wouldn't do in practice.
> > >
> > > 4. Symbols still need to be properly invalidated. It looks like at
> > > least menuconfig just does a dumb invalidate-everything whenever
> > > the value of a symbol is changed though, so it might not require
> > > extra work. (Bit messier in Kconfiglib, which does minimal
> > > invalidation to keep scripts fast, but just need to extract a few
> > > extra deps there.)
> > >
> > >
> > > It looks like dynamic functions could get quite messy, but might be
> > > doable if absolutely required. There's probably more devils in the
> > > details though.
> > >
> > > I don't think the static function model precludes switching models later
> > > btw, when people have more experience.
> >
> >
> >
> > I really want to start with the static function model
> > and see if we need the dynamic function implementation.
>
> Yeah, let's start with static functions, IMO.
>
> Either we'll learn that they're powerful enough in practice, and save
> ourselves some work, or we'll gain experience for later. Converting from
> static to dynamic functions should be painless, if needed.
>
> My plan would be something like:
>
> 1. Implement static functions
>
> 2. Convert as many simple cases over to them as possible
>
> 3. See how bad the bad cases get. If they get really bad, then decide
> what to do next (extend Kconfig, handle them in the Makefiles,
> etc.)
>
> >
> > Here is an idea for the migration path in case
> > we need to do that in the future.
> >
> >
> >
> > Currently, every time user input is given,
> > sym_clear_all_valid() is called.
> >
> > It is not efficient to blindly re-evaluate expensive $(shell ...)
>
> I think menuconfig only reevalutes the symbols in the menu that's
> currently shown in the interface (along with their dependencies).
>
> Maybe that'd be bad enough though.
>
> >
> >
> > So, have a list of symbols the function depends on
> > in its arguments.
> >
> > For example,
> >
> > config CC_HAS_SANE_STACKPROTECTOR
> > def_bool $(shell $srctree/scripts/gcc-has-stack-protector.sh
> > $CC $(1), CFLAGS_BASE)
> >
> >
> > Here the first argument
> > $srctree/scripts/gcc-x86-has-stack-protector.sh $CC $(1)
> >
> > is the shell command.
> > $(1), $(2), ... will be replaced with the values of symbols (or expressions)
> > that follow when running the shell command.
> >
> >
> > The second argument
> > CFLAGS_BASE
> > is the dependency symbol (or expression).
> >
> >
> > CFLAGS_BASE can be dynamically changed like
> >
> > config CFLAGS_BASE
> > string
> > default "-m64" if 64BIT
> > default "-m32"
> >
> >
> > When and only when CFLAGS_BASE is updated, the function should be re-calculated.
> > (This will require efforts to minimize the amount of re-evaluation.)
> >
> >
> >
> >
> > cc-option will be implemented like follows:
> >
> > macro cc-option $(shell $CC -Werror $$(1) $(1) -c -x c /dev/null -o
> > /dev/null, CFLAGS_BASE)
> >
> >
> >
> > Please notice the difference between $$(1) and $(1).
> >
> > $(1) is immediately expanded by cc-option macro.
> >
> > $$(1) is escaped since we want to expand it by $(shell ...), not by
> > $(cc-option ...)
> >
> >
> >
> > For example,
> >
> > $(cc-option -fstack-protector)
> >
> > will be expanded to
> >
> > $(shell gcc -Werror $(1) -fstack-protector -c -x c /dev/null -o
> > /dev/null, CFLAGS_BASE)
> >
> > Since macros are just textual shorthand, so this expansion happens
> > during the parse phase.
> >
> >
> >
> > Then, the evaluation phase does the following every time CFLAGS_BASE is updated.
> >
> > gcc -Werror [value of CFLAGS_BASE] -fstack-protector -c -x c /dev/null
> > -o /dev/null
> >
> >
> > This is a new form of expression, so it will be managed in AST tree
> > with a flag E_SHELL (or E_FUNC) etc.
> >
> >
> > Not implemented at all. Just a rough sketch.
>
> A simpler syntax like
>
> $(shell $CC -Werror {CFLAGS_BASE} -c -x c /dev/null -o /dev/null)
*$(shell $CC -Werror {CFLAGS_BASE} -fstack-protector -c -x c /dev/null -o /dev/null)
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 05/10] pwm: add PWM mode to pwm_config()
From: Claudiu Beznea @ 2018-03-02 9:19 UTC (permalink / raw)
To: Thierry Reding
Cc: shc_work, kgene, krzk, linux, mturquette, sboyd, jani.nikula,
joonas.lahtinen, rodrigo.vivi, airlied, kamil, b.zolnierkie,
jdelvare, linux, dmitry.torokhov, rpurdie, jacek.anaszewski,
pavel, mchehab, sean, lee.jones, daniel.thompson, jingoohan1,
milo.kim, robh+dt, mark.rutland, corbet, nicolas.ferre,
alexandre.belloni, linux-pwm, linux-kernel, linux-arm-kernel,
linux-samsung-soc, linux-clk, intel-gfx, dri-devel, linux-hwmon,
linux-input, linux-leds, linux-media, linux-fbdev, devicetree,
linux-doc
In-Reply-To: <20180228194429.GD22932@mithrandir>
On 28.02.2018 21:44, Thierry Reding wrote:
> On Thu, Feb 22, 2018 at 02:01:16PM +0200, Claudiu Beznea wrote:
>> Add PWM mode to pwm_config() function. The drivers which uses pwm_config()
>> were adapted to this change.
>>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
>> ---
>> arch/arm/mach-s3c24xx/mach-rx1950.c | 11 +++++++++--
>> drivers/bus/ts-nbus.c | 2 +-
>> drivers/clk/clk-pwm.c | 3 ++-
>> drivers/gpu/drm/i915/intel_panel.c | 17 ++++++++++++++---
>> drivers/hwmon/pwm-fan.c | 2 +-
>> drivers/input/misc/max77693-haptic.c | 2 +-
>> drivers/input/misc/max8997_haptic.c | 6 +++++-
>> drivers/leds/leds-pwm.c | 5 ++++-
>> drivers/media/rc/ir-rx51.c | 5 ++++-
>> drivers/media/rc/pwm-ir-tx.c | 5 ++++-
>> drivers/video/backlight/lm3630a_bl.c | 4 +++-
>> drivers/video/backlight/lp855x_bl.c | 4 +++-
>> drivers/video/backlight/lp8788_bl.c | 5 ++++-
>> drivers/video/backlight/pwm_bl.c | 11 +++++++++--
>> drivers/video/fbdev/ssd1307fb.c | 3 ++-
>> include/linux/pwm.h | 6 ++++--
>> 16 files changed, 70 insertions(+), 21 deletions(-)
>
> I don't think it makes sense to leak mode support into the legacy API.
> The pwm_config() function is considered legacy
I missed this aspect.
and should eventually go
> away. As such it doesn't make sense to integrate a new feature such as
> PWM modes into it.
Agree.
All users of pwm_config() assume normal mode, and
> that's what pwm_config() should provide.
Agree.
>
> Anyone that needs something other than normal mode should use the new
> atomic PWM API.
Agree.
>
> Thierry
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 05/10] pwm: add PWM mode to pwm_config()
From: Claudiu Beznea @ 2018-03-02 9:28 UTC (permalink / raw)
To: Jani Nikula, Thierry Reding
Cc: shc_work, kgene, krzk, linux, mturquette, sboyd, joonas.lahtinen,
rodrigo.vivi, airlied, kamil, b.zolnierkie, jdelvare, linux,
dmitry.torokhov, rpurdie, jacek.anaszewski, pavel, mchehab, sean,
lee.jones, daniel.thompson, jingoohan1, milo.kim, robh+dt,
mark.rutland, corbet, nicolas.ferre, alexandre.belloni, linux-pwm,
linux-kernel, linux-arm-kernel, linux-samsung-soc, linux-clk,
intel-gfx, dri-devel, linux-hwmon, linux-input, linux-leds,
linux-media, linux-fbdev, devicetree, linux-doc
In-Reply-To: <87r2p4hod7.fsf@intel.com>
On 28.02.2018 22:04, Jani Nikula wrote:
> On Wed, 28 Feb 2018, Thierry Reding <thierry.reding@gmail.com> wrote:
>> Anyone that needs something other than normal mode should use the new
>> atomic PWM API.
>
> At the risk of revealing my true ignorance, what is the new atomic PWM
> API? Where? Examples of how one would convert old code over to the new
> API?
As far as I know, the old PWM core code uses config(), set_polarity(),
enable(), disable() methods of driver, registered as pwm_ops:
struct pwm_ops {
int (*request)(struct pwm_chip *chip, struct pwm_device *pwm);
void (*free)(struct pwm_chip *chip, struct pwm_device *pwm);
int (*config)(struct pwm_chip *chip, struct pwm_device *pwm,
int duty_ns, int period_ns);
int (*set_polarity)(struct pwm_chip *chip, struct pwm_device *pwm,
enum pwm_polarity polarity);
int (*capture)(struct pwm_chip *chip, struct pwm_device *pwm,
struct pwm_capture *result, unsigned long timeout);
int (*enable)(struct pwm_chip *chip, struct pwm_device *pwm);
void (*disable)(struct pwm_chip *chip, struct pwm_device *pwm);
int (*apply)(struct pwm_chip *chip, struct pwm_device *pwm,
struct pwm_state *state);
void (*get_state)(struct pwm_chip *chip, struct pwm_device *pwm,
struct pwm_state *state);
#ifdef CONFIG_DEBUG_FS
void (*dbg_show)(struct pwm_chip *chip, struct seq_file *s);
#endif
struct module *owner;
};
to do settings on hardware. In order to so settings on a PWM the users
should have been follow the below steps:
->config()
->set_polarity()
->enable()
Moreover, if the PWM was previously enabled it should have been first
disable and then to follow the above steps in order to apply a new settings
on hardware.
The driver should have been provide, at probe, all the above function:
->config(), ->set_polarity(), ->disable(), ->enable(), function that were
used by PWM core.
Now, having atomic PWM, the driver should provide one function to PWM core,
which is ->apply() function. Every PWM has a state associated, which keeps
the period, duty cycle, polarity and enable/disable status. The driver's
->apply() function takes as argument the state that should be applied and
it takes care of applying this new state directly without asking user to
call ->disable(), then ->config()/->set_polarity(), then ->enable() to
apply new hardware settings.
The PWM consumer could set a new state for PWM it uses, using
pwm_apply_state(pwm, new_state);
Regarding the models to switch on atomic PWM, on the controller side you
can check for drivers that registers apply function at probe time.
Regarding the PWM users, you can look for pwm_apply_state()
(drivers/hwmon/pwm-fan.c or drivers/input/misc/pwm-beeper.c are some examples).
Thierry, please correct me if I'm wrong.
Thank you,
Claudiu Beznea
>
> BR,
> Jani.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 00/23] kconfig: move compiler capability tests to Kconfig
From: Ulf Magnusson @ 2018-03-02 9:03 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Arnd Bergmann, Rich Felker, Kernel Hardening, X86 ML,
Paul Mackerras, H. Peter Anvin, sparclinux, Sam Ravnborg,
Yoshinori Sato, Jonathan Corbet, Richard Weinberger,
Linux-sh list, Ingo Molnar, Emese Revfy, Kees Cook, uml-devel,
Linux Kbuild mailing list, Peter Oberparleiter, Jeff Dike,
linuxppc-dev, user-mode-linux-user, Thomas Gleixner, Michal Marek,
Greg Kroah-Hartman, Randy Dunlap, open list:DOCUMENTATION,
Linux Kernel Mailing List, Linus Torvalds, David S. Miller
In-Reply-To: <CAK7LNARd-9KNRTHT3jrNganqLisheAWbDQMGi_ujp+1GpYzSOg@mail.gmail.com>
On Fri, Mar 02, 2018 at 02:50:39PM +0900, Masahiro Yamada wrote:
> 2018-02-22 6:39 GMT+09:00 Ulf Magnusson <ulfalizer@gmail.com>:
> > On Wed, Feb 21, 2018 at 09:57:03PM +0900, Masahiro Yamada wrote:
> >> 2018-02-21 19:52 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
> >> > On Wed, Feb 21, 2018 at 11:20 AM, Masahiro Yamada
> >> > <yamada.masahiro@socionext.com> wrote:
> >> >> 2018-02-21 18:56 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
> >> >>> On Wed, Feb 21, 2018 at 8:38 AM, Masahiro Yamada
> >> >>> <yamada.masahiro@socionext.com> wrote:
> >> >>>> 2018-02-20 0:18 GMT+09:00 Ulf Magnusson <ulfalizer@gmail.com>:
> >> >>
> >> >> Let me clarify my concern.
> >> >>
> >> >> When we test the compiler flag, is there a case
> >> >> where a particular flag depends on -m{32,64} ?
> >> >>
> >> >> For example, is there a compiler that supports -fstack-protector
> >> >> for 64bit mode, but unsupports it for 32bit mode?
> >> >>
> >> >> $(cc-option -m32) -> y
> >> >> $(cc-option -m64) -> y
> >> >> $(cc-option -fstack-protector) -> y
> >> >> $(cc-option -m32 -fstack-protector) -> n
> >> >> $(cc-option -m64 -fstack-protector) -> y
> >> >>
> >> >> I guess this is unlikely to happen,
> >> >> but I am not whether it is zero possibility.
> >> >>
> >> >> If this could happen,
> >> >> $(cc-option ) must be evaluated together with
> >> >> correct bi-arch option (either -m32 or -m64).
> >> >>
> >> >>
> >> >> Currently, -m32/-m64 is specified in Makefile,
> >> >> but we are moving compiler tests to Kconfig
> >> >> and, CONFIG_64BIT can be dynamically toggled in Kconfig.
> >> >
> >> > I don't think it can happen for this particular combination (stack protector
> >> > and word size), but I'm sure we'll eventually run into options that
> >> > need to be tested in combination. For the current CFLAGS_KERNEL
> >> > setting, we definitely have the case of needing the variables to be
> >> > evaluated in a specific order.
> >> >
> >>
> >>
> >>
> >>
> >> I was thinking of how we can handle complex cases
> >> in the current approach.
> >>
> >>
> >>
> >> (Case 1)
> >>
> >> Compiler flag -foo and -bar interacts, so
> >> we also need to check the combination of the two.
> >>
> >>
> >> config CC_HAS_FOO
> >> def_bool $(cc-option -foo)
> >>
> >> config CC_HAS_BAR
> >> def_bool $(cc-option -bar)
> >>
> >> config CC_HAS_FOO_WITH_BAR
> >> def_bool $(cc-option -foo -bar)
> >>
> >>
> >>
> >> (Case 2)
> >> Compiler flag -foo is sensitive to word-size.
> >> So, we need to test this option together with -m32/-m64.
> >> User can toggle CONFIG_64BIT, like i386/x86_64.
> >>
> >>
> >> config CC_NEEDS_M64
> >> def_bool $(cc-option -m64) && 64BIT
> >>
> >> config CC_NEEDS_M32
> >> def_bool $(cc-option -m32) && !64BIT
> >>
> >> config CC_HAS_FOO
> >> bool
> >> default $(cc-option -m64 -foo) if CC_NEEDS_M64
> >> default $(cc-option -m32 -foo) if CC_NEEDS_M32
> >> default $(cc-option -foo)
> >>
> >>
> >>
> >> (Case 3)
> >> Compiler flag -foo is sensitive to endian-ness.
> >>
> >>
> >> config CC_NEEDS_BIG_ENDIAN
> >> def_bool $(cc-option -mbig-endian) && CPU_BIG_ENDIAN
> >>
> >> config CC_NEEDS_LITTLE_ENDIAN
> >> def_bool $(cc-option -mlittle-endian) && CPU_LITTLE_ENDIAN
> >>
> >> config CC_HAS_FOO
> >> bool
> >> default $(cc-option -mbig-endian -foo) if CC_NEEDS_BIG_ENDIAN
> >> default $(cc-option -mlittle-endian -foo) if CC_NEEDS_LITTLE_ENDIAN
> >> default $(cc-option -foo)
> >>
> >>
> >>
> >>
> >> Hmm, I think I can implement those somehow.
> >> But, I hope we do not have many instances like this...
> >>
> >>
> >> If you know more naive cases, please share your knowledge.
> >>
> >> Thanks!
> >>
> >>
> >> --
> >> Best Regards
> >> Masahiro Yamada
> >
> > Would get pretty bad if a test needs to consider multiple symbols.
> > Exponential explosion there...
> >
> >
> > I thought some more about the implementation of dynamic (post-parsing)
> > functions to see how bad it would get with the current implementation.
> >
> > Some background on how things work now:
> >
> > 1. All expression operands in Kconfig are symbols.
> >
> > 2. Returning '$ENV' or '$(fn foo)' as a T_WORD during parsing gets
> > you symbols with those strings as names and S_UNKNOWN type (because
> > they act like references to undefined symbols).
> >
> > 3. For "foo-$(fn foo)", you also get a symbol with that string as its
> > name and S_UNKNOWN type (stored among the SYMBOL_CONST symbols)
> >
> > 4. Symbols with S_UNKNOWN type get their name as their string value,
> > and the tristate value n.
> >
> > So, if you do string expansion on the names of symbols with S_UNKNOWN
> > type in sym_calc_value(), you're almost there with the current
> > implementation, except for the tristate case.
> >
> > Maybe you could set the tristate value of S_UNKNOWN symbols depending on
> > the string value you end up with. Things are getting pretty confusing at
> > that point.
> >
> > Could have something like S_DYNAMIC as well. More Kconfig complexity...
> >
> > Then there's other complications:
> >
> > 1. SYMBOL_CONST is no longer constant.
> >
> > 2. Dependency loop detection needs to consider symbol references
> > within strings.
> >
> > 3. Dependency loop detection relies on static knowledge of what
> > symbols a symbol depends on. That might get messy for certain
> > expansions, though it might be things you wouldn't do in practice.
> >
> > 4. Symbols still need to be properly invalidated. It looks like at
> > least menuconfig just does a dumb invalidate-everything whenever
> > the value of a symbol is changed though, so it might not require
> > extra work. (Bit messier in Kconfiglib, which does minimal
> > invalidation to keep scripts fast, but just need to extract a few
> > extra deps there.)
> >
> >
> > It looks like dynamic functions could get quite messy, but might be
> > doable if absolutely required. There's probably more devils in the
> > details though.
> >
> > I don't think the static function model precludes switching models later
> > btw, when people have more experience.
>
>
>
> I really want to start with the static function model
> and see if we need the dynamic function implementation.
Yeah, let's start with static functions, IMO.
Either we'll learn that they're powerful enough in practice, and save
ourselves some work, or we'll gain experience for later. Converting from
static to dynamic functions should be painless, if needed.
My plan would be something like:
1. Implement static functions
2. Convert as many simple cases over to them as possible
3. See how bad the bad cases get. If they get really bad, then decide
what to do next (extend Kconfig, handle them in the Makefiles,
etc.)
>
> Here is an idea for the migration path in case
> we need to do that in the future.
>
>
>
> Currently, every time user input is given,
> sym_clear_all_valid() is called.
>
> It is not efficient to blindly re-evaluate expensive $(shell ...)
I think menuconfig only reevalutes the symbols in the menu that's
currently shown in the interface (along with their dependencies).
Maybe that'd be bad enough though.
>
>
> So, have a list of symbols the function depends on
> in its arguments.
>
> For example,
>
> config CC_HAS_SANE_STACKPROTECTOR
> def_bool $(shell $srctree/scripts/gcc-has-stack-protector.sh
> $CC $(1), CFLAGS_BASE)
>
>
> Here the first argument
> $srctree/scripts/gcc-x86-has-stack-protector.sh $CC $(1)
>
> is the shell command.
> $(1), $(2), ... will be replaced with the values of symbols (or expressions)
> that follow when running the shell command.
>
>
> The second argument
> CFLAGS_BASE
> is the dependency symbol (or expression).
>
>
> CFLAGS_BASE can be dynamically changed like
>
> config CFLAGS_BASE
> string
> default "-m64" if 64BIT
> default "-m32"
>
>
> When and only when CFLAGS_BASE is updated, the function should be re-calculated.
> (This will require efforts to minimize the amount of re-evaluation.)
>
>
>
>
> cc-option will be implemented like follows:
>
> macro cc-option $(shell $CC -Werror $$(1) $(1) -c -x c /dev/null -o
> /dev/null, CFLAGS_BASE)
>
>
>
> Please notice the difference between $$(1) and $(1).
>
> $(1) is immediately expanded by cc-option macro.
>
> $$(1) is escaped since we want to expand it by $(shell ...), not by
> $(cc-option ...)
>
>
>
> For example,
>
> $(cc-option -fstack-protector)
>
> will be expanded to
>
> $(shell gcc -Werror $(1) -fstack-protector -c -x c /dev/null -o
> /dev/null, CFLAGS_BASE)
>
> Since macros are just textual shorthand, so this expansion happens
> during the parse phase.
>
>
>
> Then, the evaluation phase does the following every time CFLAGS_BASE is updated.
>
> gcc -Werror [value of CFLAGS_BASE] -fstack-protector -c -x c /dev/null
> -o /dev/null
>
>
> This is a new form of expression, so it will be managed in AST tree
> with a flag E_SHELL (or E_FUNC) etc.
>
>
> Not implemented at all. Just a rough sketch.
A simpler syntax like
$(shell $CC -Werror {CFLAGS_BASE} -c -x c /dev/null -o /dev/null)
might work as well. Then you wouldn't have to any double escaping, and
having both $(1) and the value for it appear in the same place seems a
bit redundant.
I wonder if dependency management might get messy...
Anyway, let's just go with static functions...
Cheers,
Ulf
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] Documentation/sphinx: Fix Directive import error
From: Takashi Iwai @ 2018-03-02 11:49 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: Jani Nikula, linux-doc, linux-kernel
The sphinx.util.compat Directive stuff was deprecated in the recent
Sphinx version, and now we get a build error.
Let's take a fallback to the newer one, from docutils.parsers.rst.
Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1083694
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
I'm no expert of sphinx nor python, so something might be wrong.
Please check it.
--- a/Documentation/sphinx/kerneldoc.py
+++ b/Documentation/sphinx/kerneldoc.py
@@ -37,7 +37,10 @@ import glob
from docutils import nodes, statemachine
from docutils.statemachine import ViewList
from docutils.parsers.rst import directives
-from sphinx.util.compat import Directive
+try:
+ from sphinx.util.compat import Directive
+except ImportError:
+ from docutils.parsers.rst import directives, Directive
from sphinx.ext.autodoc import AutodocReporter
__version__ = '1.0'
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] HID: logitech-hidpp: document sysfs interface
From: Aishwarya Pant @ 2018-03-02 13:16 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, linux-input, linux-kernel,
Jonathan Corbet, Greg KH
Cc: Julia Lawall, linux-doc
Descriptions have been collected from git commit logs.
Signed-off-by: Aishwarya Pant <aishpant@gmail.com>
---
.../ABI/testing/sysfs-driver-hid-logitech-hidpp | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-driver-hid-logitech-hidpp
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-logitech-hidpp b/Documentation/ABI/testing/sysfs-driver-hid-logitech-hidpp
new file mode 100644
index 000000000000..d8f831f2d6b5
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-hid-logitech-hidpp
@@ -0,0 +1,19 @@
+What: /sys/bus/hid/drivers/logitech-hidpp-device/<dev>/range
+Date: Jan, 2016
+KernelVersion: 4.6
+Contact: linux-input@vger.kernel.org
+Description:
+ (RW) This attribute controls the amount of 'turn' permitted in
+ Logitech G920 wheel. Reading from the file shows the current
+ range of the steering wheel. Writing a value within the min and
+ max boundary sets the range of the wheel.
+
+What: /sys/bus/hid/drivers/logitech-hidpp-device/<dev>/builtin_power_supply
+Date: Apr, 2017
+KernelVersion: 4.12
+Contact: linux-input@vger.kernel.org
+Description:
+ Presence of this file indicates that HID++ driver is capable of
+ handling battery properties in the kernel. This way, upower can
+ add a udev rule to decide whether or not it should use the
+ internal unifying support or the generic kernel one.
--
2.16.2
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH] xfs: Change URL for the project in xfs.txt
From: Masanari Iida @ 2018-03-02 13:30 UTC (permalink / raw)
To: darrick.wong, linux-xfs, linux-kernel, corbet, linux-doc; +Cc: Masanari Iida
The oss.sgi.com doesn't exist any more.
Change it to current project URL, https://xfs.wiki.kernel.org/
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
---
Documentation/filesystems/xfs.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/filesystems/xfs.txt b/Documentation/filesystems/xfs.txt
index 3b9b5c149f32..4d9ff0a7f8e1 100644
--- a/Documentation/filesystems/xfs.txt
+++ b/Documentation/filesystems/xfs.txt
@@ -9,7 +9,7 @@ variable block sizes, is extent based, and makes extensive use of
Btrees (directories, extents, free space) to aid both performance
and scalability.
-Refer to the documentation at http://oss.sgi.com/projects/xfs/
+Refer to the documentation at https://xfs.wiki.kernel.org/
for further details. This implementation is on-disk compatible
with the IRIX version of XFS.
--
2.16.2.345.g7e31236f652a
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* kernel-doc unbuildable with sphinx 1.7
From: Jiri Slaby @ 2018-03-02 14:10 UTC (permalink / raw)
To: Jani Nikula; +Cc: corbet, linux-doc
Hi,
in openSUSE, sphinx was updated to 1.7.1 and kernel-doc cannot be built
since that time:
Running Sphinx v1.7.1
Extension error:
Could not import extension kerneldoc (exception: cannot import name
'Directive')
It is because sphinx.util.compat.* was removed from sphinx in 1.7 since
it was deprecated for a long time:
"sphinx.util.compat.%s is deprecated and will be removed "
"in Sphinx 1.7, please use docutils' instead."
Could you fix that up? python is not my favourite interpreter so fixing
it myself is not feasible on my side.
thanks,
--
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: kernel-doc unbuildable with sphinx 1.7
From: Jonathan Corbet @ 2018-03-02 14:34 UTC (permalink / raw)
To: Jiri Slaby; +Cc: Jani Nikula, linux-doc, Takashi Iwai
In-Reply-To: <1b24cf1c-941b-9f0d-21e5-b595f64c49b6@suse.cz>
On Fri, 2 Mar 2018 15:10:14 +0100
Jiri Slaby <jslaby@suse.cz> wrote:
> in openSUSE, sphinx was updated to 1.7.1 and kernel-doc cannot be built
> since that time:
> Running Sphinx v1.7.1
>
> Extension error:
> Could not import extension kerneldoc (exception: cannot import name
> 'Directive')
>
> It is because sphinx.util.compat.* was removed from sphinx in 1.7 since
> it was deprecated for a long time:
> "sphinx.util.compat.%s is deprecated and will be removed "
> "in Sphinx 1.7, please use docutils' instead."
>
>
> Could you fix that up? python is not my favourite interpreter so fixing
> it myself is not feasible on my side.
I got a patch from Takashi this very morning for that problem; I guess
I'll have to fast-track it Linusward.
Thanks,
jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: kernel-doc unbuildable with sphinx 1.7
From: Jiri Slaby @ 2018-03-02 14:40 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: Jani Nikula, linux-doc, Takashi Iwai
In-Reply-To: <20180302073409.2cce15ff@lwn.net>
On 03/02/2018, 03:34 PM, Jonathan Corbet wrote:
> I got a patch from Takashi this very morning for that problem; I guess
> I'll have to fast-track it Linusward.
Oh, thanks!
P.S.: Takashi, could you push it to our master & stable branches?
--
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: kernel-doc unbuildable with sphinx 1.7
From: Takashi Iwai @ 2018-03-02 14:44 UTC (permalink / raw)
To: Jiri Slaby; +Cc: Jonathan Corbet, Jani Nikula, linux-doc
In-Reply-To: <895ece54-4bde-47d8-7c0c-adfdd21fdf23@suse.cz>
On Fri, 02 Mar 2018 15:40:37 +0100,
Jiri Slaby wrote:
>
> On 03/02/2018, 03:34 PM, Jonathan Corbet wrote:
> > I got a patch from Takashi this very morning for that problem; I guess
> > I'll have to fast-track it Linusward.
>
> Oh, thanks!
>
> P.S.: Takashi, could you push it to our master & stable branches?
Sure, just waited for the feedback from Jon :)
Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Documentation/sphinx: Fix Directive import error
From: Matthew Wilcox @ 2018-03-02 14:50 UTC (permalink / raw)
To: Takashi Iwai; +Cc: Jonathan Corbet, Jani Nikula, linux-doc, linux-kernel
In-Reply-To: <s5hbmg6hf4g.wl-tiwai@suse.de>
On Fri, Mar 02, 2018 at 12:49:03PM +0100, Takashi Iwai wrote:
> I'm no expert of sphinx nor python, so something might be wrong.
> Please check it.
I'm also not a pythonista, but ...
> --- a/Documentation/sphinx/kerneldoc.py
> +++ b/Documentation/sphinx/kerneldoc.py
> @@ -37,7 +37,10 @@ import glob
> from docutils import nodes, statemachine
> from docutils.statemachine import ViewList
> from docutils.parsers.rst import directives
> -from sphinx.util.compat import Directive
> +try:
> + from sphinx.util.compat import Directive
> +except ImportError:
> + from docutils.parsers.rst import directives, Directive
It seems to me the previous line already imported
docutils.parsers.rst.directives, and we should probably prefer the newer
parser even with Sphinx 1.6, so I would think this would work better:
-from sphinx.util.compat import Directive
+try:
+ from docutils.parsers.rst import Directive
+except ImportError:
+ from sphinx.util.compat import Directive
(it works on Debian with Sphinx 1.6.7)
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: kernel-doc unbuildable with sphinx 1.7
From: Jonathan Corbet @ 2018-03-02 14:52 UTC (permalink / raw)
To: Takashi Iwai; +Cc: Jiri Slaby, Jani Nikula, linux-doc
In-Reply-To: <s5hvaeefsf6.wl-tiwai@suse.de>
On Fri, 02 Mar 2018 15:44:45 +0100
Takashi Iwai <tiwai@suse.de> wrote:
> Sure, just waited for the feedback from Jon :)
I want to try it with both old and new Sphinx, of course, but will have a
hard time doing it today - on the road all day. But it looks reasonable
at a first glance; I'll try to get it into -rc4 (and -stable, I guess) if
I can.
Thanks,
jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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