Re: [PATCH v2] thinkpad_acpi: Support the battery wear control
Hi! In newer series (I can't find it at the moment, sorry) you return "NOT_CHARGING" status when not charging because of wear control. Maybe we should have separate status "not charging due to wear control"? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v2] thinkpad_acpi: Support the battery wear control
On 09/12/2017, Pavel Machek wrote: > In newer series (I can't find it at the moment, sorry) The new series is a 3-patch patchset that obsoletes this patch. It is in the testing stage and will be pushed to the mailing lists and maintainers in a few days. > Maybe we should have separate status "not charging due to wear > control"? No, because the ACPI battery driver is a extension to the generic power supply driver, that does not understand the battery wear control. Also, Rafael specifically noted NOT to include any thinkpad_acpi-specific behavior to the generic drivers. That behavior you are describing can be implemented in the userspace. Thanks for the time! Ognjen -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] thinkpad_acpi: Support the battery wear control
On Sat 2017-12-09 11:29:51, Ognjen Galić wrote: > On 09/12/2017, Pavel Machek wrote: > > In newer series (I can't find it at the moment, sorry) > > The new series is a 3-patch patchset that obsoletes this > patch. It is in the testing stage and will be pushed to > the mailing lists and maintainers in a few days. > > > Maybe we should have separate status "not charging due to wear > > control"? > > No, because the ACPI battery driver is a extension to the generic > power supply driver, that does not understand the battery wear control. > Also, Rafael specifically noted NOT to include any thinkpad_acpi-specific > behavior to the generic drivers. Yeah, what I'm saying is that maybe we need to extend generic power supply driver. On small devices, we usually have enough control over hardware to be able to implement "wear control" in kernel. Nokia N900 is an example. "Wear control" is certainly not thinkpad-specific concept. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v2] thinkpad_acpi: Support the battery wear control
On 09/12/2017, Pavel Machek wrote: > Yeah, what I'm saying is that maybe we need to extend generic power > supply driver. I don't know about that, you would have to ask the maintainers if that is appropriate. Thanks for the time! Ognjen -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] doc: convert printk-formats.txt to rst
On Fri, Dec 08, 2017 at 06:18:45PM -0800, Joe Perches wrote: > On Sat, 2017-12-09 at 12:27 +1100, Tobin C. Harding wrote: > > On Fri, Dec 08, 2017 at 01:22:37PM -0800, Joe Perches wrote: > > > > Outside of the documentation, what could be useful is for > > > someone to add a tool to verify %p extension to > > > the typeof address actually passed as an argument. > > > > This sounds interesting to work no. At first glance I have no idea how > > one would go about this. Some form of static analysis would be a good > > place to start, right? I'd like to allocate some cycles to this, any > > pointers most appreciated. > > A gcc-plugin would likely work best. > > There was some discussion about such a thing here: > http://www.openwall.com/lists/kernel-hardening/2017/02/14/38 > > I vaguely recall someone else doing a broader use tool > which I believe was not smatch, but my google-fu isn't > finding it. Yeah. Smatch has a check for this. Rasmus Villemoes wrote it. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] kbuild: prepare to remove C files pre-generated by flex and bison
In Linux build system convention, pre-generated files are version-
controlled with a "_shipped" suffix. During the kernel building,
they are simply shipped (copied) removing the suffix.
This approach can reduce external tool dependency for the kernel build,
but it is tedious to manually regenerate such artifacts from developers'
point of view. (We need to do "make REGENERATE_PARSERS=1" every time
we touch real source files such as *.l, *.y)
Some months ago, I sent out RFC patches to run flex, bison, and gperf
during the build.
In the review and test, Linus noticed gperf-3.1 had changed the lookup
function prototype. Then, the use of gperf in kernel was entirely
removed by commit bb3290d91695 ("Remove gperf usage from toolchain").
I tested several versions of flex and bison, and I was not hit by any
compatibility issue except a flaw in flex-2.6.3; if you generate lexer
for dtc and genksyms with flex-2.6.3, you will see "yywrap redefined"
warning. This was not intentional, but a bug fixed by flex-2.6.4.
Otherwise, flex and bison look fairly stable for a long time.
This commit prepares some build rules to start removing the _shipped
files. Also, document minimal requirement for flex and bison.
Rationale for the minimal version:
The -Wmissing-prototypes option of GCC reports "no previous prototype"
warnings for lexers generated by flex-2.5.34, so I chose 2.5.35 as the
required version for flex. Flex-2.5.35 was released in 2008. Bison
looked more stable. I did not see any problem with bison-2.0, released
in 2004. I did not test bison-1.x, but bison-2.0 should be old enough.
Tested flex versions:
2.5.35
2.5.36
2.5.37
2.5.39
2.6.0
2.6.1
2.6.2
2.6.3 (*)
2.6.4
(*) flex-2.6.3 causes "yywrap redefined" warning
Tested bison versions:
2.0
2.1
2.2
2.3
2.4
2.4.1
2.5.1
2.6
2.6.1
2.6.2
2.6.3
2.6.4
2.6.5
2.7
2.7.1
3.0
3.0.1
3.0.2
3.0.3
3.0.4
Signed-off-by: Masahiro Yamada
---
Documentation/process/changes.rst | 25 +
scripts/Makefile.lib | 20 +---
2 files changed, 42 insertions(+), 3 deletions(-)
diff --git a/Documentation/process/changes.rst
b/Documentation/process/changes.rst
index 560beae..fc9c7c3 100644
--- a/Documentation/process/changes.rst
+++ b/Documentation/process/changes.rst
@@ -32,6 +32,8 @@ you probably needn't concern yourself with isdn4k-utils.
GNU C 3.2 gcc --version
GNU make 3.81 make --version
binutils 2.20 ld -v
+flex 2.5.35 flex --version
+bison 2.0 bison --version
util-linux 2.10ofdformat --version
module-init-tools 0.9.10 depmod -V
e2fsprogs 1.41.4 e2fsck -V
@@ -79,6 +81,19 @@ The build system has, as of 4.13, switched to using thin
archives (`ar T`)
rather than incremental linking (`ld -r`) for built-in.o intermediate steps.
This requires binutils 2.20 or newer.
+Flex
+
+
+Since Linux 4.16, the build system generates lexical analisers
+during build. This requires flex 2.5.35 or later.
+
+
+Bison
+-
+
+Since Linux 4.16, the build system generates parsers
+during build. This requires bison 2.0 or later.
+
Perl
@@ -333,6 +348,16 @@ Binutils
-
+
+Bison
+-
+
+-
[PATCH 0/3] kbuild,kconfig: generate lexer/parser C files instead of copying _shipped files
In Linux build system convention, pre-generated files are version- controlled with a "_shipped" suffix. During the kernel building, they are simply shipped (copied) removing the suffix. >From users' point of view, this approach can reduce external tool dependency for the kernel build, >From developers point of view, it is tedious to manually regenerate such artifacts. In fact, we see several patches to regenerate _shipped files. They are noise commits. When we update a *.y or *.l file, it would be better to update the corresponding _shipped file in the same commit, but it is painful. If you use a different version of flex/bison, it will produce lots of irrelevant diffs. We could update _shipped files after adding various changes to the real sources, but it is not very nice for a git-bisect'ability. In case of a problem, "git bisect" would point to the commit updating _shipped files, but the root cause would be in another commit that has changed the corresponding .l or .y files. Some months ago, I sent RFC patches to run flex, bison, and gperf during the build. https://lkml.org/lkml/2017/8/19/49 Basically Linus agreed this, but he found a problem in gperf, then use of gperf in kernel was removed. It took some months for me to come back. This time, I installed various versions of flex/bison on my machine, and tested them more carefully. My current motivation is in Kconfig. There are several Kconfig patches touching *.y and *.l (and Linus suggested another improvement for Kconfig) so I want to remove zconf.lex.c_shipped and zconf.tab.c_shipped now. Kconfig has no problem for this switch. dtc and genksyms will be taken care of later because both of them are having shift/reduce conflicts now. The ambiguous grammar in dtc has been fixed in upstream, but not reflected to kernel yet. We can proceed migration in sub-system base. Masahiro Yamada (3): kbuild: add LEX and YACC variables kbuild: prepare to remove C files pre-generated by flex and bison kconfig: generate lexer and parser during build instead of shipping Documentation/process/changes.rst | 25 + Makefile|4 +- scripts/Makefile.lib| 24 +- scripts/kconfig/Makefile|1 + scripts/kconfig/zconf.lex.c_shipped | 2473 --- scripts/kconfig/zconf.tab.c_shipped | 2471 -- 6 files changed, 48 insertions(+), 4950 deletions(-) delete mode 100644 scripts/kconfig/zconf.lex.c_shipped delete mode 100644 scripts/kconfig/zconf.tab.c_shipped -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation: mono: Update links and s/CVS/Git/
The URLs in mono.rst redirect to pages on www.mono-project.com, so let's update them. I took the liberty to update the compilation instructions to the Linux-specific version, because readers of the kernel documentation will most likely use Linux. Signed-off-by: Jonathan Neuschäfer --- Documentation/admin-guide/mono.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/admin-guide/mono.rst b/Documentation/admin-guide/mono.rst index cdddc099af64..59e6d59f0ed9 100644 --- a/Documentation/admin-guide/mono.rst +++ b/Documentation/admin-guide/mono.rst @@ -9,14 +9,14 @@ This will allow you to execute Mono-based .NET binaries just like any other program after you have done the following: 1) You MUST FIRST install the Mono CLR support, either by downloading - a binary package, a source tarball or by installing from CVS. Binary + a binary package, a source tarball or by installing from Git. Binary packages for several distributions can be found at: - http://go-mono.com/download.html + http://www.mono-project.com/download/ Instructions for compiling Mono can be found at: - http://www.go-mono.com/compiling.html + http://www.mono-project.com/docs/compiling-mono/linux/ Once the Mono CLR support has been installed, just check that ``/usr/bin/mono`` (which could be located elsewhere, for example -- 2.15.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] kbuild: prepare to remove C files pre-generated by flex and bison
On 12/09/2017 08:02 AM, Masahiro Yamada wrote: > > Signed-off-by: Masahiro Yamada > --- > > Documentation/process/changes.rst | 25 + > scripts/Makefile.lib | 20 +--- > 2 files changed, 42 insertions(+), 3 deletions(-) > > diff --git a/Documentation/process/changes.rst > b/Documentation/process/changes.rst > index 560beae..fc9c7c3 100644 > --- a/Documentation/process/changes.rst > +++ b/Documentation/process/changes.rst > @@ -32,6 +32,8 @@ you probably needn't concern yourself with isdn4k-utils. > GNU C 3.2 gcc --version > GNU make 3.81 make --version > binutils 2.20 ld -v > +flex 2.5.35 flex --version > +bison 2.0 bison --version > util-linux 2.10ofdformat --version > module-init-tools 0.9.10 depmod -V > e2fsprogs 1.41.4 e2fsck -V > @@ -79,6 +81,19 @@ The build system has, as of 4.13, switched to using thin > archives (`ar T`) > rather than incremental linking (`ld -r`) for built-in.o intermediate steps. > This requires binutils 2.20 or newer. > > +Flex > + > + > +Since Linux 4.16, the build system generates lexical analisers analyzers or analysers > +during build. This requires flex 2.5.35 or later. thanks. -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] i2c: update i2c-dev.h warning in documentation
`dev-interface` document gives examples for accessing i2c from
userspace.
There's a note warning developers about the different `i2c-dev.h` header
files which were shipped with the kernel and i2c-tools separately.
However, these commits in i2c-tools repository suggests that the header
files are now identical (in functionality) and `i2c_*` functions are now
defined in a separate header called `i2c/smbus.h`, which is distributed
with i2c-tools:
commit 652619121974 ("Minimize differences with kernel flavor")
commit 93caf007f4cb ("Move SMBus helper functions to include/i2c/smbus.h")
Thus, I've converted the warning paragraph into a historical note and
updated the suggested header files.
Signed-off-by: Cengiz Can
---
Documentation/i2c/dev-interface | 29 -
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/Documentation/i2c/dev-interface
b/Documentation/i2c/dev-interface index 5ff19447ac44..04d110697863
100644 --- a/Documentation/i2c/dev-interface
+++ b/Documentation/i2c/dev-interface
@@ -9,21 +9,24 @@ i2c adapters present on your system at a given time.
i2cdetect is part of the i2c-tools package.
I2C device files are character device files with major device number 89
-and a minor device number corresponding to the number assigned as
-explained above. They should be called "i2c-%d" (i2c-0, i2c-1, ...,
+and a minor device number corresponding to the number assigned as
+explained above. They should be called "i2c-%d" (i2c-0, i2c-1, ...,
i2c-10, ...). All 256 minor device numbers are reserved for i2c.
C example
=
-So let's say you want to access an i2c adapter from a C program. The
-first thing to do is "#include ". Please note that
-there are two files named "i2c-dev.h" out there, one is distributed
-with the Linux kernel and is meant to be included from kernel
-driver code, the other one is distributed with i2c-tools and is
-meant to be included from user-space programs. You obviously want
-the second one here.
+So let's say you want to access an i2c adapter from a C program.
First, you +need to include these two headers:
+
+ #include
+ #include
+
+(Please note that there are two files named "i2c-dev.h" out there. One
is +distributed with the Linux kernel and the other one is included in
the +source tree of i2c-tools. They used to be different in content but
since 2012 +they're identical. You should use "linux/i2c-dev.h").
Now, you have to decide which adapter you want to access. You should
inspect /sys/class/i2c-dev/ or run "i2cdetect -l" to decide this.
@@ -35,7 +38,7 @@ Next thing, open the device file, as follows:
int file;
int adapter_nr = 2; /* probably dynamically determined */
char filename[20];
-
+
snprintf(filename, 19, "/dev/i2c-%d", adapter_nr);
file = open(filename, O_RDWR);
if (file < 0) {
@@ -69,7 +72,7 @@ the device supports them. Both are illustrated below.
/* res contains the read word */
}
- /* Using I2C Write, equivalent of
+ /* Using I2C Write, equivalent of
i2c_smbus_write_word_data(file, reg, 0x6543) */
buf[0] = reg;
buf[1] = 0x43;
@@ -144,7 +147,7 @@ You can do plain i2c transactions by using read(2)
and write(2) calls. You do not need to pass the address byte; instead,
set it through ioctl I2C_SLAVE before you try to access the device.
-You can do SMBus level transactions (see documentation file
smbus-protocol +You can do SMBus level transactions (see documentation
file smbus-protocol for details) through the following functions:
__s32 i2c_smbus_write_quick(int file, __u8 value);
__s32 i2c_smbus_read_byte(int file);
@@ -155,7 +158,7 @@ for details) through the following functions:
__s32 i2c_smbus_write_word_data(int file, __u8 command, __u16 value);
__s32 i2c_smbus_process_call(int file, __u8 command, __u16 value);
__s32 i2c_smbus_read_block_data(int file, __u8 command, __u8
*values);
- __s32 i2c_smbus_write_block_data(int file, __u8 command, __u8
length,
+ __s32 i2c_smbus_write_block_data(int file, __u8 command, __u8 length,
__u8 *values);
All these transactions return -1 on failure; you can read errno to see
what happened. The 'write' transactions return 0 on success; the
--
2.15.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] i2c: update i2c-dev.h warning in documentation
`dev-interface` document gives examples for accessing i2c from
userspace.
There's a note warning developers about the different `i2c-dev.h` header
files which were shipped with the kernel and i2c-tools separately.
However, these commits in i2c-tools repository suggests that the header
files are now identical (in functionality) and `i2c_*` functions are now
defined in a separate header called `i2c/smbus.h`, which is distributed
with i2c-tools:
commit 652619121974 ("Minimize differences with kernel flavor")
commit 93caf007f4cb ("Move SMBus helper functions to include/i2c/smbus.h")
Thus, I've converted the warning paragraph into a historical note and
updated the suggested header files.
Signed-off-by: Cengiz Can
---
Sorry for duplicate mails. My email client hard-wrapped previous patch.
Thanks.
Documentation/i2c/dev-interface | 29 -
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface
index 5ff19447ac44..04d110697863 100644
--- a/Documentation/i2c/dev-interface
+++ b/Documentation/i2c/dev-interface
@@ -9,21 +9,24 @@ i2c adapters present on your system at a given time.
i2cdetect is part of
the i2c-tools package.
I2C device files are character device files with major device number 89
-and a minor device number corresponding to the number assigned as
-explained above. They should be called "i2c-%d" (i2c-0, i2c-1, ...,
+and a minor device number corresponding to the number assigned as
+explained above. They should be called "i2c-%d" (i2c-0, i2c-1, ...,
i2c-10, ...). All 256 minor device numbers are reserved for i2c.
C example
=
-So let's say you want to access an i2c adapter from a C program. The
-first thing to do is "#include ". Please note that
-there are two files named "i2c-dev.h" out there, one is distributed
-with the Linux kernel and is meant to be included from kernel
-driver code, the other one is distributed with i2c-tools and is
-meant to be included from user-space programs. You obviously want
-the second one here.
+So let's say you want to access an i2c adapter from a C program. First, you
+need to include these two headers:
+
+ #include
+ #include
+
+(Please note that there are two files named "i2c-dev.h" out there. One is
+distributed with the Linux kernel and the other one is included in the
+source tree of i2c-tools. They used to be different in content but since 2012
+they're identical. You should use "linux/i2c-dev.h").
Now, you have to decide which adapter you want to access. You should
inspect /sys/class/i2c-dev/ or run "i2cdetect -l" to decide this.
@@ -35,7 +38,7 @@ Next thing, open the device file, as follows:
int file;
int adapter_nr = 2; /* probably dynamically determined */
char filename[20];
-
+
snprintf(filename, 19, "/dev/i2c-%d", adapter_nr);
file = open(filename, O_RDWR);
if (file < 0) {
@@ -69,7 +72,7 @@ the device supports them. Both are illustrated below.
/* res contains the read word */
}
- /* Using I2C Write, equivalent of
+ /* Using I2C Write, equivalent of
i2c_smbus_write_word_data(file, reg, 0x6543) */
buf[0] = reg;
buf[1] = 0x43;
@@ -144,7 +147,7 @@ You can do plain i2c transactions by using read(2) and
write(2) calls.
You do not need to pass the address byte; instead, set it through
ioctl I2C_SLAVE before you try to access the device.
-You can do SMBus level transactions (see documentation file smbus-protocol
+You can do SMBus level transactions (see documentation file smbus-protocol
for details) through the following functions:
__s32 i2c_smbus_write_quick(int file, __u8 value);
__s32 i2c_smbus_read_byte(int file);
@@ -155,7 +158,7 @@ for details) through the following functions:
__s32 i2c_smbus_write_word_data(int file, __u8 command, __u16 value);
__s32 i2c_smbus_process_call(int file, __u8 command, __u16 value);
__s32 i2c_smbus_read_block_data(int file, __u8 command, __u8 *values);
- __s32 i2c_smbus_write_block_data(int file, __u8 command, __u8 length,
+ __s32 i2c_smbus_write_block_data(int file, __u8 command, __u8 length,
__u8 *values);
All these transactions return -1 on failure; you can read errno to see
what happened. The 'write' transactions return 0 on success; the
--
2.15.1
--
Cengiz Can
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
