| Age | Commit message (Collapse) | Author |
|---|
|
Wadim Egorov <[email protected]> says:
Although AM62x, AM62Ax, AM64x, and AM62Px share the same register for
reset reason, not all TRMs document this consistently. To avoid relying
on undocumented behavior, introduce SoC-specific implementations for
now. If TI confirms all SoCs share the same register, this can be moved to
common.c for reuse.
It will be mostly copy&paste for the mentioned devices.
Also, I am not sure how this Register operates exactly. I noticed that
two bits can be set at once, so I started to check for set bits instead
of having a switch/case logic.
Link: https://lore.kernel.org/r/[email protected]
|
|
Implement get_reset_reason() for AM62x to enable reporting of
the reset cause in the cpuinfo output.
Signed-off-by: Wadim Egorov <[email protected]>
|
|
Call get_reset_reason() during CPU info output and display the result
if the SoC provides the implementation. This helps in debugging by
providing context on the last system reset reason.
Signed-off-by: Wadim Egorov <[email protected]>
|
|
Tom Rini <[email protected]> says:
Hey all,
This is a v3 of Simon's series[1] and depends on the series[2] I posted
the other day that removes <env.h> from <command.h>. With this series
done, I believe we've tackled all of the current cases of headers which
include <env.h> without directly needing it. Much of this series is in
fact Simon's v2 with the main differneces being:
- Removing <env.h> from <net.h> at the end
- Removing env_to_ip() given how little it's used rather than shuffling
around where it's declared and un-inline'ing it. For a rarely used
helper, this ends up being cleaner I think. Especially looking at some
of the users (which called env_get repeatedly). If there's strong
opinion here about using the other method[3] we can do that instead.
- Setting aside for now how to handle CMD_ELF=y and NO_NET=y because
today it's actually fine as we unconditionally build lib/net_utils.c
where string_to_ip() is defined. I'm unsure if a further series is
warranted here or not. We rely on link-time optimization to keep code
readable too.
[1]: https://lore.kernel.org/all/[email protected]
[2]: https://lore.kernel.org/all/[email protected]
[3]: https://lore.kernel.org/all/[email protected]
Link: https://lore.kernel.org/r/[email protected]
|
|
Now that all of the cases of code that relied on <net.h> to provide
<env.h> (or one of the headers that it includes, and so forth) have been
fixed, we can drop the include from here.
Signed-off-by: Tom Rini <[email protected]>
|
|
Now that env_get_ip() has been removed, the include file <net.h> does
not need anything from <env.h>. Furthermore, include/env.h itself
includes other headers which can lead to longer indirect inclusion
paths. To prepare to remove <env.h> from <net.h> fix all of the
remaining places which had relied on this indirect inclusion to instead
include <env.h> directly.
Reviewed-by: Jerome Forissier <[email protected]> # net/lwip
Acked-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Wolfgang Wallner <[email protected]>
Reviewed-by: Martyn Welch <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
This file uses the environment but does not include the header file.
Update it.
Signed-off-by: Simon Glass <[email protected]>
|
|
This file uses the environment but does not include the header file.
Update it.
Signed-off-by: Simon Glass <[email protected]>
|
|
This file uses byteorder but does not include the header file. Update
it.
Signed-off-by: Simon Glass <[email protected]>
|
|
This file reads from the environment but does not include the correct
header. Update it.
Signed-off-by: Simon Glass <[email protected]>
|
|
This file reads from the environment but does not include the correct
header. Update it.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Lukasz Majewski <[email protected]>
|
|
This file reads from the environment but does not include the correct
header. Update it.
Signed-off-by: Simon Glass <[email protected]>
|
|
This file reads from the environment but does not include the correct
header. Update it.
Signed-off-by: Simon Glass <[email protected]>
|
|
This file reads from the environment but does not include the correct
header. Update it.
Reviewed-by: Viacheslav Bocharov <[email protected]>
Signed-off-by: Simon Glass <[email protected]>
|
|
This file reads from the environment but does not include the correct
header. Update it.
Reviewed-by: Stefan Roese <[email protected]>
Reviewed-by: Tony Dinh <[email protected]>
Signed-off-by: Simon Glass <[email protected]>
|
|
This file reads from the environment but does not include the correct
header. Update it.
Signed-off-by: Simon Glass <[email protected]>
|
|
This file uses the environment but does not include the header file.
Update it.
Acked-by: Oliver Graute <[email protected]>
Signed-off-by: Simon Glass <[email protected]>
|
|
Two files read from the environment but don't not include the correct
header. Update them.
Signed-off-by: Simon Glass <[email protected]>
|
|
This file reads from the environment but does not include the correct
header. Update it.
Signed-off-by: Simon Glass <[email protected]>
|
|
This file reads from the environment but does not include the correct
header. Update it.
Signed-off-by: Simon Glass <[email protected]>
|
|
This file reads from the environment but does not include the correct
header. Update it.
Signed-off-by: Simon Glass <[email protected]>
|
|
This file uses memcpy() but does not include the header file. Update it.
Reviewed-by: Jerome Forissier <[email protected]>
Signed-off-by: Simon Glass <[email protected]>
|
|
This file reads from the environment but does not include the correct
header. Update it.
Signed-off-by: Simon Glass <[email protected]>
|
|
This file reads from the environment but does not include the correct
header. Update it.
Signed-off-by: Simon Glass <[email protected]>
|
|
This file reads from the environment but does not include the correct
header. Update it.
Signed-off-by: Simon Glass <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Currently, we have the function env_get_ip which takes an IP address
in string form and returns a struct in_addr representation of that
address. It is however little used and means that a number of places
indirectly (and unclearly) get <env.h> via <net.h>. To clean this up
start by replacing env_get_ip() calls with string_to_ip() calls. This is
generally a no-op as env_get_ip(str) is an inline of
string_to_ip(env_get(str)) but in a few cases we can or already have
stored the result of env_get(str) and can save the additional call.
Signed-off-by: Tom Rini <[email protected]>
|
|
Tom Rini <[email protected]> says:
Given Simon's series at [1] I started looking in to what brings in
<env.h> when not strictly required and in turn has some unintended
implicit includes. This series takes care of the places where, commonly,
<linux/string.h> or <env.h> itself were required along with a few other
less common cases. This sets aside for the moment what to do about
net-common.h and env_get_ip() as I'm not entirely sure what's best
there.
[1]: https://patchwork.ozlabs.org/project/uboot/list/?series=454939&state=*
Link: https://lore.kernel.org/r/[email protected]
|
|
Now that all of the cases of code that relied on <command.h> to provide
<env.h> (or one of the headers that it includes, and so forth) have been
fixed, we can drop the include from here.
Signed-off-by: Tom Rini <[email protected]>
|
|
The include file <command.h> does not need anything from <env.h>.
Furthermore, include/env.h itself includes other headers which can lead
to longer indirect inclusion paths. To prepare to remove <env.h> from
<command.h> fix all of the places which had relied on this indirect
inclusion to instead include <env.h> directly.
Reviewed-by: Mattijs Korpershoek <[email protected]> # android, bcb
Reviewed-by: Jerome Forissier <[email protected]> # spawn
Signed-off-by: Tom Rini <[email protected]>
|
|
This driver takes a long implicit include path to get this header which
it directly uses. Add it.
Signed-off-by: Tom Rini <[email protected]>
|
|
These files require <compiler.h> in order to have MEM_SUPPORT_64BIT_DATA
be defined but currently rely on a long indirect include path to get it.
Add this directly.
Signed-off-by: Tom Rini <[email protected]>
|
|
In a number of cases we have C files which rely on a chain of indirect
include paths to get <linux/string.h> to be included via <command.h>. To
facilitate cleaning up <command.h> make this code directly include
<linux/string.h>.
Signed-off-by: Tom Rini <[email protected]>
|
|
Rasmus Villemoes <[email protected]> says:
This started as a rather simple patch, 1/12, adding the ability to
more conveniently do regex matching in shell.
But with that, it became very easy to see what the slre library can
and especially what it cannot do, and that way I found both outright
bugs and a "wow, doesn't it support that syntax" gotcha. I couldn't
find any tests ('git grep slre -- test/' was empty), so I added a
small test suite and tweaked slre.c.
Link: https://lore.kernel.org/r/[email protected]
|
|
Inspecting the slre.c code reveals a few bugs; those are easy to
demonstrate with the new '=~' test operator. Before fixing them, let's
add a place to add test cases.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
Add documentation for the test command, including the newly added =~
operator and some gotchas wrt. the numeric comparisons.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
The first of these, { "U-Boot", "^[B-Uo-t]*$", 0 }, would match
previously when the - and the letters were all interpreted literally.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
When trying to use U-Boot's regex facility, it is a rather large
gotcha that [a-z] range syntax is not supported. It doesn't require a
lot of extra code to implement that; we just let the regular parsing
emit the start and end literal symbols as usual, and add a new
"escape" code RANGE.
At match time, this means the code will first just see an 'a' and try
to match that, and only then recognize that it's actually part of a
range and then do the 'a' <= ch <= 'z' test.
Of course, this means that a - in the middle of a [] pair no longer
matches a literal dash, but I highly doubt anybody relies on
that. Putting it first or last, or escaping it with \, as in most
other RE engines, continues to work.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
At the compile stage, the anyof() function clearly intends to handle escape
sequences like \d (for digits) inside square brackets, since the logic
emits a 0 byte followed by the code representing the character
class (NONSPACE, SPACE or DIGIT).
However, this is not handled in the corresponding match helper
is_any_of(); it just naively loops over all the bytes in the ->data
array emitted by anyof() and compares those directly to the current
character. For example, this means that the string "\x11" (containing
the single character with value 17) is matched by the regex "[#%\d]",
because DIGIT happens to be 17.
Fix that by recognizing a zero byte as indicating something special
and act accordingly. In order not to repeat the "increment *ofs and
return 1" in all places, put those two lines after a new match: label.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
As preparation for fixing the handling of backslash-escapes used
inside a character class, refactor is_any_but() to be defined in terms
of is_any_of() so we don't have to repeat the same logic in two places.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
Add some tests for the "drop wrong anchored optimization". Without
the previous commit, the first, fifth and seventh of these would fail,
i.e. those:
{ "xby", "^a|b", 1},
{ "", "x*$", 1},
{ "yy", "x*$", 1},
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
The regex '^a|b' means "does the string start with a, or does it have
a b anywhere", not "does the string start with a or b" (the latter
should be spelled '^[ab]' or '^(a|b)'). It should match exactly the
same strings as 'b|^a'. But the current implementation hard-codes an
assumption that when the regex starts with a ^, the whole regex must
match from the beginning, i.e. it only attempts at offset 0.
It really should be completely symmetrical to 'b|c$' ("does it have a
b anywhere or end with c?"), which is treated correctly.
Another quirk is that currently the regex 'x*$', which should match
all strings (because it just means "does the string end
with 0 or more x'es"), does not, because in the unanchored case we
never attempt to match at ofs==len. In the anchored case, '^x*$', this
works correctly and matches exactly strings (including the empty
string) consisting entirely of x'es.
Fix both of these issues by dropping all use of the slre->anchored
member and always test at all possible offsets. If the regex does have
a ^ somewhere (including after a | branch character), that is
correctly handled by the match engine by only matching when *ofs is 0.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
I guess that touching these files means "tag, you're it". That's fine
with me.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
Currently, the only way to make use of regex matching in the shell is
by using "setexpr [g]sub" command. That's rather awkward for asking
whether a string matches a regex. At the very least, it requires
providing setexpr with a dummy target variable, but also, the return
value of setexpr doesn't say whether any substitutions were done, so
one would have to do some roundabout thing like
env set dummy "${string_to_test}"
setexpr sub dummy '<some regex>' ''
if test "${dummy}" != "${string_to_test}" ; then ...
When CONFIG_REGEX is set, teach the test command a new operator, =~,
which will allow one to more naturally write
if test "${string_to_test}" =~ '<some regex>' ; then ...
The =~ operator with similar functionality is also supported in bash
when using its "extended" test operator [[ ]].
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
Un-orphan the RZ/G2L , keep the RZ/G2L maintained.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Paul Barker <[email protected]>
|
|
I still intend to review patches, and will be using my own email address
going forward.
Signed-off-by: Paul Barker <[email protected]>
|
|
Enable CONFIG_SERIAL_RX_BUFFER on all Renesas R-Car devices which
use the SCIF serial port. This allows receiving large strings at
bulk even if the RX FIFO is small and would otherwise overflow.
The usual trigger for the problem addressed here is a paste of a
very long command into U-Boot command line, somewhere between 400
and 500 characters long. The trailing end of the string is usually
not received and the command line input stops responding due to RX
overflow errors. The CONFIG_SERIAL_RX_BUFFER allows efficient read
of data from the RX FIFO, which prevents the overflow, and allows
safe reception of long pasted strings.
Signed-off-by: Marek Vasut <[email protected]>
|
|
[1] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git
Signed-off-by: Tom Rini <[email protected]>
|
|
The issue here is that the function read_allocated_block() will report
problems via a negative return value. If we say the return value is
stored in an lbaint_t that can no longer happen (and Coverity discovered
this by reporting a no effect comparison and then dead code). The
problem being fixed by allowing for storing a larger block number will
have to be solved in some other manner.
This reverts commit df2ed552f0b05591090369a7fe7ddc92439dea5c.
Addresses-Coverity-ID: 131183
Signed-off-by: Tom Rini <[email protected]>
|
