On 1/29/21 12:44 PM, Shoaib Rao wrote:
On 1/29/21 12:18 PM, Jakub Kicinski wrote:
On Fri, 29 Jan 2021 12:10:21 -0800 Shoaib Rao wrote:
On 1/29/21 12:02 PM, Jakub Kicinski wrote:
On Fri, 29 Jan 2021 11:48:15 -0800 Shoaib Rao wrote:
Data was discarded because the flag was not supported,
On Fri, Jan 29, 2021 at 12:41 PM Sedat Dilek wrote:
>
> On Fri, Jan 29, 2021 at 8:43 PM Nick Desaulniers
> wrote:
> >
> > diff --git a/Makefile b/Makefile
> > index 20141cd9319e..bed8b3b180b8 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -832,8 +832,20 @@ endif
> >
> >
Similarly to bitmap functions, users will benefit if we'll handle
a case of small-size bitmaps that fit into a single word.
While here, move the find_last_bit() declaration to bitops/find.h
where other find_*_bit() functions sit.
Signed-off-by: Yury Norov
---
include/asm-generic/bitops/find.h
On Mon, Jan 25, 2021 at 4:41 PM Dave Hansen wrote:
>
>
> From: Dave Hansen
>
> When memory fills up on a node, memory contents can be
> automatically migrated to another node. The biggest problems are
> knowing when to migrate and to where the migration should be
> targeted.
>
> The most
lib/find_bit.c declares five single-line wrappers for _find_next_bit().
We may turn those wrappers to inline functions. It eliminates unneeded
function calls and opens room for compile-time optimizations.
Signed-off-by: Yury Norov
---
include/asm-generic/bitops/find.h | 28 ++---
Similarly to bitmap functions, find_next_*_bit() users will benefit
if we'll handle a case of bitmaps that fit into a single word. In the
very best case, the compiler may replace a function call with a
single ffs or ffz instruction.
Signed-off-by: Yury Norov
---
Many algorithms become simplier if they are passed with relatively small
input values. One example is bitmap operations when the whole bitmap fits
into one word. To implement such simplifications, linux/bitmap.h declares
small_const_nbits() macro.
Other subsystems may also benefit from
On Fri, Jan 29, 2021 at 12:33:43PM -0800, Dave Hansen wrote:
> In that case is there any reason to keep the "depends on CPU_SUP_INTEL"?
Probably not. I haven't heard of the AMD implementation being somehow
different from Intel's.
--
Regards/Gruss,
Boris.
BITMAP_{LAST,FIRST}_WORD_MASK() in linux/bitmap.h duplicates the
functionality of GENMASK(). The scope of bitmap macros is wider than just
bitmap. This patch defines 4 new macros: BITS_FIRST(), BITS_LAST(),
BITS_FIRST_MASK() and BITS_LAST_MASK() in linux/bits.h on top of GENMASK()
and replaces
m68k and sh include bitmap/find.h prior to ffs/fls headers. New
fast-path implementation in find.h requires ffs/fls. Reordering
the order of headers inclusion helps to prevent compile-time
implicit-function-declaration error.
Signed-off-by: Yury Norov
Acked-by: Geert Uytterhoeven
---
On 1/29/21 12:18 PM, Jakub Kicinski wrote:
On Fri, 29 Jan 2021 12:10:21 -0800 Shoaib Rao wrote:
On 1/29/21 12:02 PM, Jakub Kicinski wrote:
On Fri, 29 Jan 2021 11:48:15 -0800 Shoaib Rao wrote:
Data was discarded because the flag was not supported, this patch
changes that but does not support
Bitmap operations are much simpler and faster in case of small bitmaps, whicn
fit into a single word. In linux/bitmap.h we have a machinery that allows
compiler to replace actual function call with a few instructions if bitmaps
passed into the function is small and its size is known at compile
On Thu, Dec 17, 2020 at 03:04:34PM +, Satya Tangirala wrote:
> Introduces functions that help with metadata encryption.
>
> In particular, we introduce:
>
> fscrypt_setup_metadata_encryption() - filesystems should call this function
> to set up metadata encryption on a super block with the
On Fri, Jan 29, 2021 at 8:43 PM Nick Desaulniers
wrote:
>
> DWARF v5 is the latest standard of the DWARF debug info format.
>
> Feature detection of DWARF5 is onerous, especially given that we've
> removed $(AS), so we must query $(CC) for DWARF5 assembler directive
> support.
>
> The DWARF
Hi Sven,
On Fri, Jan 29, 2021 at 01:05:14PM -0500, Sven Van Asbroeck wrote:
> Hi Clemens,
>
> On Fri, Jan 29, 2021 at 11:31 AM Clemens Gruber
> wrote:
> >
> > Ok, so you suggest we extend our get_state logic to deal with cases
> > like the following:
>
> Kind of. We can't control how other
> diff --git a/drivers/net/ethernet/microchip/lan743x_main.c
> b/drivers/net/ethernet/microchip/lan743x_main.c
> index f1f6eba4ace4..f485320e5784 100644
> --- a/drivers/net/ethernet/microchip/lan743x_main.c
> +++ b/drivers/net/ethernet/microchip/lan743x_main.c
> @@ -1957,11 +1957,11 @@ static int
On 1/29/21 11:58 AM, Andy Lutomirski wrote:
>> Did any CPUs ever get released that have this? If so, name them. If
>> not, time to change this to 2021, I think.
> Zen 3 :)
In that case is there any reason to keep the "depends on CPU_SUP_INTEL"?
Hi Guo,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: bec4c2968fce2f44ce62d05288a633cd99a722eb
commit: 18c07d23da5a48525b2955aa269b8bb108c19300 csky: Fixup calltrace panic
date: 9 months ago
config:
On Wed, Jan 13, 2021 at 05:34:47PM -0700, Nathan Chancellor wrote:
> The most common question around building the Linux kernel with clang is
> "does it work?" and the answer has always been "it depends on your
> architecture, configuration, and LLVM version" with no hard answers for
> users
On 1/29/2021 1:24 AM, Jack Pham wrote:
> Hi Wesley,
>
> On Thu, Jan 28, 2021 at 08:46:43PM -0800, Wesley Cheng wrote:
>> In order to take advantage of the TX fifo resizing logic, manually add
>> these properties to the DWC3 child node by default. This will allow
>> the DWC3 gadget to resize
On Fri, Jan 29, 2021 at 12:02 PM Linus Torvalds
wrote:
>
> It's fairly easy to work around in this in the tty layer by just
> avoiding that function entirely, so I'll cook up a patch to do that.
> But I'm adding the appropriate people to the participants here because
> this really is very subtle
On Fri, Jan 29, 2021 at 5:51 AM Pavel Tatashin
wrote:
>
> > Since we last talked about this the enabling for EFI "Special Purpose"
> > / Soft Reserved Memory has gone upstream and instantiates device-dax
> > instances for address ranges marked with EFI_MEMORY_SP attribute.
> > Critically this way
Create a new helper function that encapsulates issuing a set of
channel stop commands, retrying if appropriate, with a short delay
between attempts.
Signed-off-by: Alex Elder
---
drivers/net/ipa/gsi.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git
On Thu, Jan 28, 2021 at 09:45:41AM +0100, Mike Looijmans wrote:
> Hi Andrew,
>
> Response below...
Hi Mike
Everybody here knows that top posting is evil, we don't do it. We
expect the replay to be inline.
> > Hi Mike
> >
> > Did you look at the per PHY reset? mdiobus_register_gpiod() gets the
Transactions to send data for a network device can be allocated at
any time up until the point the TX queue is stopped. It is possible
for ipa_start_xmit() to be called in one context just before a
the transmit queue is stopped in another.
Update gsi_channel_trans_last() so that for TX channels
Disable the I/O completion interrupt on a channel *after* we
successfully stop it rather than before. This ensures a completion
occurring just before the channel is stopped triggers an interrupt.
Enable the interrupt *before* starting a channel rather than after,
to be symmetric. A stopped
The channel stop and suspend paths both call __gsi_channel_stop(),
which quiesces channel activity, disables NAPI, and (on other than
SDM845) stops the channel. Similarly, the start and resume paths
share __gsi_channel_start(), which starts the channel and re-enables
NAPI again.
Disabling NAPI
Move the calls to enable or disable IEOB interrupts out of
__gsi_channel_start() and __gsi_channel_stop() and into their
callers. This is a small step to make the next patch easier
to understand.
Signed-off-by: Alex Elder
---
drivers/net/ipa/gsi.c | 45
No completion interrupts will occur while an endpoint is suspended,
or when a channel has been stopped for suspend. So there's no need
to disable the interrupt during suspend and re-enable it when
resuming.
We'll enable the interrupt when we first start the channel, and
disable it again only
On 1/29/21 11:32 AM, Srinivas Kandagatla wrote:
Add support to new interrupts and update irq routine in a way
to deal with multiple pending interrupts with in a single interrupt!
I can't parse the wording after 'update irq routine'.
+ swrm->reg_write(swrm, SWRM_INTERRUPT_CLEAR,
Open-code gsi_channel_freeze() and gsi_channel_thaw() in all callers
and get rid of these two functions. This is part of reworking the
sequence of things done during channel suspend/resume and start/stop.
Signed-off-by: Alex Elder
---
drivers/net/ipa/gsi.c | 37
Create a new function that does most of the work of starting a
channel. What's different is that it takes a flag indicating
whether the channel should really be stopped or not. When doing a
"normal" channel start, the flag is true. Create another new
function __gsi_channel_stop() that behaves
If an error occurs starting a channel, don't "thaw" it.
We should assume the channel remains in a non-started state.
Update the comment in gsi_channel_stop(); calls to this function are
no longer retried.
Signed-off-by: Alex Elder
---
drivers/net/ipa/gsi.c | 6 --
1 file changed, 4
A few weeks ago I suggested a change that added a flag to determine
whether NAPI should be re-enabled on a channel when we're done
polling. That change was questioned, and upon further investigation
I realized the IPA suspend path was "doing it wrong."
Currently (for newer hardware) the IPA
On 1/29/21 11:32 AM, Srinivas Kandagatla wrote:
In the existing code every soundwire register read and register write
are kinda blocked. Each of these are using a special command id that
what does 'kinda blocked' mean?
generates interrupt after it successfully finishes. This is really
On Fri, Jan 29, 2021 at 12:17 PM Jakub Jelinek wrote:
>
> On Fri, Jan 29, 2021 at 11:43:17AM -0800, Nick Desaulniers wrote:
> > Modifies CONFIG_DEBUG_INFO_DWARF4 to be a member of a choice. Adds an
> > explicit CONFIG_DEBUG_INFO_DWARF2, which is the default. Does so in a
> > way that's forward
On 1/29/21 11:32 AM, Srinivas Kandagatla wrote:
version 1.5.1 and higher IPs of this controller required to set
continue execution on ingored command flag. This patch sets this flag.
typo: ignored.
On Fri, Jan 29, 2021 at 11:43:17AM -0800, Nick Desaulniers wrote:
> Modifies CONFIG_DEBUG_INFO_DWARF4 to be a member of a choice. Adds an
> explicit CONFIG_DEBUG_INFO_DWARF2, which is the default. Does so in a
> way that's forward compatible with existing configs, and makes adding
> future
On Fri, Jan 29, 2021 at 12:11 PM Nathan Chancellor wrote:
>
> clang produces .eh_frame sections when CONFIG_GCOV_KERNEL is enabled,
> even when -fno-asynchronous-unwind-tables is in KBUILD_CFLAGS:
>
> $ make CC=clang vmlinux
> ...
> ld: warning: orphan section `.eh_frame' from `init/main.o' being
On Fri, 29 Jan 2021 12:10:21 -0800 Shoaib Rao wrote:
> On 1/29/21 12:02 PM, Jakub Kicinski wrote:
> > On Fri, 29 Jan 2021 11:48:15 -0800 Shoaib Rao wrote:
> >> Data was discarded because the flag was not supported, this patch
> >> changes that but does not support any urgent data.
> > When you
struct qcom_swrm_port_config {
u8 si;
u8 off1;
u8 off2;
u8 bp_mode;
+ u8 hstart;
+ u8 hstop;
+ u8 word_length;
+ u8 bgp_count;
I couldn't figure out what 'bgp' was and had to search. Not sure how you
came up with this abbreviation of
clang produces .eh_frame sections when CONFIG_GCOV_KERNEL is enabled,
even when -fno-asynchronous-unwind-tables is in KBUILD_CFLAGS:
$ make CC=clang vmlinux
...
ld: warning: orphan section `.eh_frame' from `init/main.o' being placed in
section `.eh_frame'
ld: warning: orphan section `.eh_frame'
On 1/29/21 12:02 PM, Jakub Kicinski wrote:
On Fri, 29 Jan 2021 11:48:15 -0800 Shoaib Rao wrote:
SO_OOBINLINE does not control the delivery of signal, It controls how
OOB Byte is delivered. It may not be obvious but this change does not
deliver any Byte, just a signal. So, as long as sendmsg
On Thu, Jan 28, 2021 at 6:26 PM Daniel Latypov wrote:
>
> Currently, given something (fairly dystopian) like
> > KUNIT_EXPECT_EQ(test, 2 + 2, 5)
>
> KUnit will prints a failure message like this.
> > Expected 2 + 2 == 5, but
> > 2 + 2 == 4
> > 5 == 5
>
> With this patch, the output
From: Sven Van Asbroeck
The buffers in the lan743x driver's receive ring are always 9K,
even when the largest packet that can be received (the mtu) is
much smaller. This performs particularly badly on cpu archs
without dma cache snooping (such as ARM): each received packet
results in a 9K
Running an rcuscale stress-suite can lead to "Out of memory"
of a system. This can happen under high memory pressure with
a small amount of physical memory.
For example a KVM test configuration with 64 CPUs and 512 megabytes
can lead to of memory after running rcuscale with below parameters:
From: Sven Van Asbroeck
Simulate low-memory in lan743x_rx_trim_skb(): fail one allocation
in every 100.
Signed-off-by: Sven Van Asbroeck
---
Tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git #
46eb3c108fe1
To: Bryan Whitehead
To: unglinuxdri...@microchip.com
To: "David
To stress and test a single argument of kfree_rcu() call, we
should to have a special coverage for it. We used to have it
in the test-suite related to vmalloc stressing. The reason is
the rcuscale is a correct place for RCU related things.
Signed-off-by: Uladzislau Rezki (Sony)
---
From: Sven Van Asbroeck
Signed-off-by: Sven Van Asbroeck
---
Tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git #
46eb3c108fe1
To: Bryan Whitehead
To: unglinuxdri...@microchip.com
To: "David S. Miller"
To: Jakub Kicinski
Cc: Andrew Lunn
Cc: Alexey Denisov
Cc: Sergej
From: Sven Van Asbroeck
Now that we can use rx ring buffers smaller than the mtu,
we allow users to change the mtu on the fly.
Tested as follows:
Tests with debug logging enabled (add #define DEBUG).
1. Set the chip mtu to 1500, generate lots of network traffic.
Stop all network traffic.
On 1/29/21 11:54 AM, Shoaib Rao wrote:
On 1/29/21 11:19 AM, Matthew Wilcox wrote:
On Fri, Jan 29, 2021 at 09:56:48AM -0800, Shoaib Rao wrote:
On 1/25/21 3:36 PM, Jakub Kicinski wrote:
On Fri, 22 Jan 2021 15:06:37 + Matthew Wilcox (Oracle) wrote:
From: Rao Shoaib
TCP sockets allow
On Fri, Jan 29, 2021 at 8:43 PM Nick Desaulniers
wrote:
>
> DWARF v5 is the latest standard of the DWARF debug info format.
>
> DWARF5 wins significantly in terms of size and especially so when mixed
> with compression (CONFIG_DEBUG_INFO_COMPRESSED).
>
> Link:
On Fri, Jan 29, 2021 at 11:17 AM Linus Torvalds
wrote:
>
> On Fri, Jan 29, 2021 at 10:31 AM Hans de Goede wrote:
> >
> > You are using Fedora now a days, right ? In that case you should be
> > able to reproduce this yourself (depending on how custom your kernel
> > setup is) if you are using
On Fri, 29 Jan 2021 11:48:15 -0800 Shoaib Rao wrote:
> >> SO_OOBINLINE does not control the delivery of signal, It controls how
> >> OOB Byte is delivered. It may not be obvious but this change does not
> >> deliver any Byte, just a signal. So, as long as sendmsg flag contains
> >> MSG_OOB, signal
Fix coding style using __packed sentece instead of
__attribute__((__packed__)).
Signed-off-by: Emmanuel Arias
---
drivers/staging/media/allegro-dvt/allegro-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/allegro-dvt/allegro-core.c
On 1/29/2021 11:42 AM, Dave Hansen wrote:
On 1/27/21 1:25 PM, Yu-cheng Yu wrote:
+ help
+ Control-flow protection is a hardware security hardening feature
+ that detects function-return address or jump target changes by
+ malicious code.
It's not really one
> On Jan 29, 2021, at 11:42 AM, Dave Hansen wrote:
>
> On 1/27/21 1:25 PM, Yu-cheng Yu wrote:
>> +help
>> + Control-flow protection is a hardware security hardening feature
>> + that detects function-return address or jump target changes by
>> + malicious code.
>
> It's
On 1/29/21 11:19 AM, Matthew Wilcox wrote:
On Fri, Jan 29, 2021 at 09:56:48AM -0800, Shoaib Rao wrote:
On 1/25/21 3:36 PM, Jakub Kicinski wrote:
On Fri, 22 Jan 2021 15:06:37 + Matthew Wilcox (Oracle) wrote:
From: Rao Shoaib
TCP sockets allow SIGURG to be sent to the process holding
From: Sven Van Asbroeck
Simulate low-memory in lan743x_rx_allocate_skb(): fail 10
allocations in a row in every 100.
Signed-off-by: Sven Van Asbroeck
---
Tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git #
46eb3c108fe1
To: Bryan Whitehead
To:
On 29.01.2021 17:41, David Howells wrote:
Vadim Fedorenko wrote:
You missed the call to dst_release(sk->sk_rx_dst) in
rxrpc_sock_destructor. Without it we are still leaking the dst.
Hmmm... I no longer get the messages appearing with this patch. I'll have
another look.
Sorry, my bad.
On 1/29/2021 11:15 AM, Dave Hansen wrote:
On 1/29/21 10:56 AM, Yu, Yu-cheng wrote:
On 1/29/2021 9:07 AM, Dave Hansen wrote:
On 1/27/21 1:25 PM, Yu-cheng Yu wrote:
[...]
What's the point of doing copy_status_to_user() if the processor doesn't
support CET? In other words, shouldn't this be
Now that the driver was ported to use regmap, let's use
some help functions in order to simplify the code a little
bit.
Suggested-by: Mark Brown
Signed-off-by: Mauro Carvalho Chehab
---
.../staging/hikey9xx/hi6421v600-regulator.c | 45 ++-
1 file changed, 3 insertions(+), 42
This driver is ready for mainstream. So, move it out of staging.
Signed-off-by: Mauro Carvalho Chehab
---
.../mfd}/hisilicon,hi6421-spmi-pmic.yaml | 0
MAINTAINERS| 7 +++
drivers/mfd/Kconfig| 16
Remove the IRQ list from the header, as this is used only
inside the driver itself. Also, get rid of two unused
defines.
The net result is that only struct hi6421_spmi_pmic remains
on it, as this is used by the regulator driver.
Signed-off-by: Mauro Carvalho Chehab
---
From: Sven Van Asbroeck
Multi-buffer packets enable us to use rx ring buffers smaller than
the mtu. This will allow us to change the mtu on-the-fly, without
having to stop the network interface in order to re-size the rx
ring buffers.
This is a big change touching a key driver function
Add a device tree for the HiSilicon 6421v600 SPMI PMIC, used
on HiKey970 board.
As we now have support for it, change the fixed regulators
used by the SD I/O to use the proper LDO supplies.
Signed-off-by: Mauro Carvalho Chehab
---
.../boot/dts/hisilicon/hi3670-hikey970.dts| 22 +
Cleanup the error handling code, making the messages more
consistent and removing an uneeded call to free_irq().
While here, also remove debug messages and make the
error messages more consistent.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/hi6421-spmi-pmic.c | 50
- Use BIT() and GENMASK();
- Remove duplicated mask definitions;
- Simplify the code under IRQ handler;
- Add a few extra blank lines to make easier to see
spin_lock/spin_unlock;
- Remove debug code;
- Fix a few minor coding style issues.
Signed-off-by: Mauro Carvalho Chehab
---
Make it clearer about how the IRQ registers are filled by adding
a table with them, with two macros used to calculate the mask
register.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/hi6421-spmi-pmic.c | 39 +
1 file changed, 32 insertions(+), 7
From: Sven Van Asbroeck
The first patch of this series boosts the chip's rx performance by up to 3x
on cpus such as ARM. However it introduces a breaking change: the mtu
can no longer be changed while the network interface is up.
To get around this efficiently, the second patch adds driver
The Hisilicon 6421v600 SPMI driver is ready for mainstream.
So, move it from staging.
Signed-off-by: Mauro Carvalho Chehab
---
.../spmi}/hisilicon,hisi-spmi-controller.yaml | 0
MAINTAINERS | 7 +++
drivers/spmi/Kconfig
This driver is ready for mainstream. Move it out of staging.
Signed-off-by: Mauro Carvalho Chehab
---
MAINTAINERS | 7 +--
drivers/regulator/Kconfig| 9 +
drivers/regulator/Makefile | 1
The phy USB3 driver for Hisilicon 970 (hi3670) is ready
for mainstream. Mode it from staging into the main driver's
phy/ directory.
Signed-off-by: Mauro Carvalho Chehab
---
.../bindings/phy/hisilicon,hi3670-usb3.yaml | 0
MAINTAINERS | 9
At PMIC subsystem, C89 comments are preferred over C99.
While here, also update the copyrights of the header file.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/hi6421-spmi-pmic.c | 14 +++---
include/linux/mfd/hi6421-spmi-pmic.h| 1 +
2 files changed, 8
- When referring to regmap, rename map to regmap
- inside hi6421-spmi-pmic, call private data struct as
ddata.
No functional changes.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/hi6421-spmi-pmic.c | 104 +-
.../staging/hikey9xx/hi6421v600-regulator.c
Hi Greg/Mark/Lee/Vinod,
Another rebase , also the top of staging-testing.
This series contain the remaining patches for USB to start working,
except for a final DTS patch.
Patches 1 and 2 convert the SPMI and regulator
drivers to use regmap and simplifies the logic by using
regmap helpers.
Instead of doing its own SPMI I/O implementation, use the
already-existing regmap one.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/Kconfig | 2 +
drivers/staging/hikey9xx/hi6421-spmi-pmic.c | 115 ++
The conversion to regmap introduced a regression at the code
which reads from the IRQ register. Address that.
Fixes: 8148fe6afb24 ("staging: hikey9xx: spmi driver: convert to regmap")
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/hi6421-spmi-pmic.c | 2 +-
1 file changed, 1
On Fri, 29 Jan 2021 at 16:47, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 5.4.94 release.
> There are 18 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
>
On 1/29/21 11:06 AM, Jakub Kicinski wrote:
On Fri, 29 Jan 2021 09:56:48 -0800 Shoaib Rao wrote:
On 1/25/21 3:36 PM, Jakub Kicinski wrote:
On Fri, 22 Jan 2021 15:06:37 + Matthew Wilcox (Oracle) wrote:
From: Rao Shoaib
TCP sockets allow SIGURG to be sent to the process holding the other
On Fri, Jan 29, 2021 at 10:03:52AM -0500, Stefan Berger wrote:
>
> + .cra_name = "ecdsa-nist-p256",
> + .cra_driver_name = "ecdsa-nist-p256",
The driver name should have a "-generic" suffix in case a driver
provides this algorithm too.
Cheers,
--
Email: Herbert Xu
Home
Em Fri, 29 Jan 2021 16:45:11 +0100
Greg Kroah-Hartman escreveu:
> On Fri, Jan 29, 2021 at 04:03:36PM +0100, Mauro Carvalho Chehab wrote:
> > Instead of doing its own SPMI I/O implementation, use the
> > already-existing regmap one.
> >
> > Signed-off-by: Mauro Carvalho Chehab
> > ---
> >
On Fri, Jan 29, 2021 at 07:02:41PM +, Michal Rostecki wrote:
> On Fri, Jan 29, 2021 at 06:47:53PM +0100, David Sterba wrote:
> > On Fri, Jan 29, 2021 at 05:15:21PM +, Michal Rostecki wrote:
> > > On Fri, Jan 29, 2021 at 11:22:48AM -0500, Josef Bacik wrote:
> > > > On 1/27/21 8:57 AM,
DWARF v5 is the latest standard of the DWARF debug info format.
Feature detection of DWARF5 is onerous, especially given that we've
removed $(AS), so we must query $(CC) for DWARF5 assembler directive
support.
The DWARF version of a binary can be validated with:
$ llvm-dwarfdump vmlinux | head
Modifies CONFIG_DEBUG_INFO_DWARF4 to be a member of a choice. Adds an
explicit CONFIG_DEBUG_INFO_DWARF2, which is the default. Does so in a
way that's forward compatible with existing configs, and makes adding
future versions more straightforward.
Suggested-by: Arvind Sankar
Suggested-by:
DWARF v5 is the latest standard of the DWARF debug info format.
DWARF5 wins significantly in terms of size and especially so when mixed
with compression (CONFIG_DEBUG_INFO_COMPRESSED).
Link: http://www.dwarfstd.org/doc/DWARF5.pdf
Patch 1 is a cleanup that lays the ground work and isn't DWARF
v5
On 1/27/21 1:25 PM, Yu-cheng Yu wrote:
> + help
> + Control-flow protection is a hardware security hardening feature
> + that detects function-return address or jump target changes by
> + malicious code.
It's not really one feature. I also think it's not worth talking about
On Fri, Jan 29, 2021 at 2:12 PM Pavel Tatashin
wrote:
>
> On Fri, Jan 29, 2021 at 2:06 PM Pavel Tatashin
> wrote:
> >
> > > > Definitely, but we should try figuring out what's going on here. I
> > > > assume on x86-64 it behaves differently?
> > >
> > > Yes, we should root cause. I highly
From: Hangbin Liu
commit 2efdaaaf883a143061296467913c01aa1ff4b3ce upstream.
Based on RFC 8200, Section 4.5 Fragment Header:
- If the first fragment does not include all headers through an
Upper-Layer header, then that fragment should be discarded and
an ICMP Parameter Problem,
From: Hangbin Liu
commit b59e286be280fa3c2e94a0716ddcee6ba02bc8ba upstream.
Based on RFC7112, Section 6:
IANA has added the following "Type 4 - Parameter Problem" message to
the "Internet Control Message Protocol version 6 (ICMPv6) Parameters"
registry:
CODE
Optimize struct psil_endpoint_config for size by
- reordering fields
- grouping bitfields
- change mapped_channel_id type to s16 (32K channel is enough)
- default_flow_id type to s16 as it's assigned to -1
before:
textdata bssdec hex filename
12654100
On Sat, Jan 30, 2021 at 12:35:10AM +0530, Sai Prakash Ranjan wrote:
> Here the idea is to protect such important information from all users
> including root users since root privileges does not have to mean full
> control over the kernel [1] and root compromise does not have to be
> the end of
On Fri, Jan 29, 2021 at 7:08 AM Colin King wrote:
>
> From: Colin Ian King
>
> Currently there are three error return paths that don't kfree object
> caps. Fix this by performing the allocation of caps after the checks
> and error return paths to avoid the premature allocation and memory
>
From: Richard Neumann
Remove unused work_amd_i2c_common macro.
Signed-off-by: Richard Neumann
---
drivers/i2c/busses/i2c-amd-mp2.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-amd-mp2.h b/drivers/i2c/busses/i2c-amd-mp2.h
index 6b91e285745d..ddecd0c88656 100644
From: Richard Neumann
Use pci_{info,warn,err,dbg} functions of the kernel's PCI API.
Remove unnecessary ndev_pdev, ndev_name and ndev_dev macros.
Remove useless __func__ from logging.
Signed-off-by: Richard Neumann
---
drivers/i2c/busses/i2c-amd-mp2-pci.c | 53 +--
From: Richard Neumann
Clean up i2c-amd-mp2-{pci,plat} drivers:
* Use pci_* logging functions provided by the kernel's PCI API.
* Remove unused macros.
* Remove useless __func__ from logging.
Changes since v1:
* Remove useless __func__ from logging.
* Assign pci_dev to local variable where
On Thu, Jan 28, 2021 at 03:34:30PM -0800, Saravanan D wrote:
> To help with debugging the sluggishness caused by TLB miss/reload,
> we introduce monotonic hugepage [direct mapped] split event counts since
> system state: SYSTEM_RUNNING to be displayed as part of
> /proc/vmstat in x86 servers
>
>
On Thu, Jan 28, 2021 at 2:45 PM Abaci Team
wrote:
>
> Fix the following coccicheck warning:
> ./drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c:3137:35-40:
> WARNING: conversion to bool not needed here
>
> Reported-by: Abaci Robot
> Suggested-by: Yang Li
> Signed-off-by: Abaci Team
On Tue, 2021-01-19 at 17:37 +0530, Nitin Rawat wrote:
> As per JESD223D UFS HCI v3.0 spec, HCI version 3.0
> is also supported. Hence Adding UFS3.0 in UFS HCI
> version check to avoid logging of the error message.
>
> Signed-off-by: Nitin Rawat
> ---
> drivers/scsi/ufs/ufshcd.c | 5 +++--
>
29.01.2021 20:46, Viresh Kumar пишет:
> On 29-01-21, 18:23, Dmitry Osipenko wrote:
>> 29.01.2021 13:51, Viresh Kumar пишет:
>>> Not all devices that need to use OPP core need to have clocks, a missing
>>> clock is fine in which case -ENODEV shall be returned by clk_get().
>>>
>>> Anything else is
201 - 300 of 532 matches
Mail list logo
