[PATCH net] r8169: always autoneg on resume

2018-09-29 Thread Alex Xu (Hello71)
This affects at least versions 25 and 33, so assume all cards are broken and just renegotiate by default. Fixes: a2965f12fde6 ("r8169: remove rtl8169_set_speed_xmii") Signed-off-by: Alex Xu (Hello71) --- drivers/net/ethernet/realtek/r8169.c | 7 +++ 1 file changed, 3 insert

[PATCH net] r8169: always autoneg on resume

2018-09-29 Thread Alex Xu (Hello71)
This affects at least versions 25 and 33, so assume all cards are broken and just renegotiate by default. Fixes: a2965f12fde6 ("r8169: remove rtl8169_set_speed_xmii") Signed-off-by: Alex Xu (Hello71) --- drivers/net/ethernet/realtek/r8169.c | 7 +++ 1 file changed, 3 insert

[PATCH v2] mm: fix z3fold warnings on CONFIG_SMP=n

2018-09-27 Thread Alex Xu (Hello71)
Spinlocks are always lockable on UP systems, even if they were just locked. Cc: Dan Streetman Signed-off-by: Alex Xu (Hello71) --- mm/z3fold.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/mm/z3fold.c b/mm/z3fold.c index 4b366d181..2e8d268ac 100644 --- a/mm/z3fold.c

[PATCH v2] mm: fix z3fold warnings on CONFIG_SMP=n

2018-09-27 Thread Alex Xu (Hello71)
Spinlocks are always lockable on UP systems, even if they were just locked. Cc: Dan Streetman Signed-off-by: Alex Xu (Hello71) --- mm/z3fold.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/mm/z3fold.c b/mm/z3fold.c index 4b366d181..2e8d268ac 100644 --- a/mm/z3fold.c

[PATCH] mm: fix z3fold warnings on CONFIG_SMP=n

2018-09-27 Thread Alex Xu (Hello71)
Spinlocks are always lockable on UP systems, even if they were just locked. Cc: Dan Streetman Signed-off-by: Alex Xu (Hello71) --- mm/z3fold.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/mm/z3fold.c b/mm/z3fold.c index 4b366d181..4e6ad2de4 100644 --- a/mm

[PATCH] mm: fix z3fold warnings on CONFIG_SMP=n

2018-09-27 Thread Alex Xu (Hello71)
Spinlocks are always lockable on UP systems, even if they were just locked. Cc: Dan Streetman Signed-off-by: Alex Xu (Hello71) --- mm/z3fold.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/mm/z3fold.c b/mm/z3fold.c index 4b366d181..4e6ad2de4 100644 --- a/mm

[PATCH] D49652: Apply -fdebug-prefix-map in reverse of command line order

2018-07-23 Thread Alex Xu (Hello71) via Phabricator via cfe-commits
alxu added a comment. my general theory is that it's better to have tests that test everything at once if possible, but I guess it's unlikely enough that the debug info path will be correct in the IR and then not correct in the generated file and that that won't be caught by LLVM tests.

[PATCH] D49466: Initial implementation of -fmacro-prefix-map and -ffile-prefix-map

2018-07-23 Thread Alex Xu (Hello71) via Phabricator via cfe-commits
alxu added a comment. FYI, gcc uses the stupid and bad string prefix matching approach. if clang supports the same option, it should have the same behavior. you could decide that it's a bad idea, but then the option should be called something else, otherwise people will have to go back to

[PATCH] D49652: Apply -fdebug-prefix-map in reverse of command line order

2018-07-23 Thread Alex Xu (Hello71) via Phabricator via cfe-commits
alxu added a comment. I was just going to run llvm-dwarfdump. Repository: rC Clang https://reviews.llvm.org/D49652 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49652: Apply -fdebug-prefix-map in reverse of command line order

2018-07-23 Thread Alex Xu (Hello71) via Phabricator via cfe-commits
alxu added a comment. Also, is it right to use SmallVector in one place and vector in the other? I just assumed based on the surrounding declarations, but I really have no idea. Repository: rC Clang https://reviews.llvm.org/D49652 ___

[PATCH] D49652: Apply -fdebug-prefix-map in reverse of command line order

2018-07-23 Thread Alex Xu (Hello71) via Phabricator via cfe-commits
alxu planned changes to this revision. alxu added a comment. The test syntax looked complicated, and I assumed that the documentation was terrible, like wine's, but it's actually pretty good, so I'll give it a go. I think the order is not really surprising though. It is run from right to left,

[PATCH] D49652: Apply -fdebug-prefix-map in reverse of command line order

2018-07-22 Thread Alex Xu (Hello71) via Phabricator via cfe-commits
alxu added a comment. Oh, I forgot to mention, this is the way that gcc does it. Therefore, I expect that almost everybody either doesn't care about the order, or assumes the gcc behavior. Repository: rC Clang https://reviews.llvm.org/D49652

[PATCH] D49652: Apply -fdebug-prefix-map in reverse of command line order

2018-07-22 Thread Alex Xu (Hello71) via Phabricator via cfe-commits
alxu created this revision. Herald added a subscriber: cfe-commits. Before this patch, it is applied in order of increasing OLD path length. This is not a useful behavior. After this patch, it is applied based on the command line order from right to left, stopping on the first match.

<    1   2