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
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
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
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
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
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
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.
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
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
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
___
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,
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
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.
101 - 113 of 113 matches
Mail list logo