On Fri, Jan 26, 2018 at 3:39 AM, Rob Landley wrote:
> The problem with 1 second timestamps was you honestly could confuse
> "make" about which file was newer once an exec() could complete in the
> same second having done real work. That was the motivating issue causing
> the change, going to nano
On Thu 25-01-18 15:27:29, David Rientjes wrote:
> On Thu, 25 Jan 2018, Michal Hocko wrote:
>
> > > As a result, this would remove patch 3/4 from the series. Do you have
> > > any
> > > other feedback regarding the remainder of this patch series before I
> > > rebase it?
> >
> > Yes, and I hav
On Thu, 25 Jan 2018, Rob Landley wrote:
> That said, I don't think -h newcx should emit (or recognize) the
> "TRAILER!!!1!" entry. That's kinda silly in-band signaling for 2018:
> files have a length, pipes provide EOF, and each cpiox entry starts with
> 6 bytes of c_magic anyway. (I stopped toybox
On Fri, 26 Jan 2018, Henrique de Moraes Holschuh wrote:
On Thu, 25 Jan 2018, Rob Landley wrote:
That said, I don't think -h newcx should emit (or recognize) the
"TRAILER!!!1!" entry. That's kinda silly in-band signaling for 2018:
files have a length, pipes provide EOF, and each cpiox entry st
On Fri, 26 Jan 2018, Victor Kamensky wrote:
> On Fri, 26 Jan 2018, Henrique de Moraes Holschuh wrote:
> > On Thu, 25 Jan 2018, Rob Landley wrote:
> > > That said, I don't think -h newcx should emit (or recognize) the
> > > "TRAILER!!!1!" entry. That's kinda silly in-band signaling for 2018:
> > >
This patch convert the driver to the new crypto engine API.
Signed-off-by: Corentin Labbe
---
drivers/crypto/virtio/virtio_crypto_algs.c | 16 ++--
drivers/crypto/virtio/virtio_crypto_common.h | 3 +--
drivers/crypto/virtio/virtio_crypto_core.c | 3 ---
3 files changed, 11 inse
This patch convert the stm32-cryp driver to the new crypto engine API.
Signed-off-by: Corentin Labbe
Tested-by: Fabien Dessenne
---
drivers/crypto/stm32/stm32-cryp.c | 29 +
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/drivers/crypto/stm32/stm32-cryp
This patch convert the stm32-hash driver to the new crypto engine API.
Signed-off-by: Corentin Labbe
Tested-by: Fabien Dessenne
---
drivers/crypto/stm32/stm32-hash.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/crypto/stm32/stm32-hash.c
b/dr
The crypto engine could actually only enqueue hash and ablkcipher request.
This patch permit it to enqueue any type of crypto_async_request.
Signed-off-by: Corentin Labbe
Tested-by: Fabien Dessenne
---
crypto/crypto_engine.c | 301 ++--
include/crypt
This patch convert the driver to the new crypto engine API.
Signed-off-by: Corentin Labbe
---
drivers/crypto/omap-aes.c | 21 +++--
drivers/crypto/omap-aes.h | 3 +++
drivers/crypto/omap-des.c | 24 ++--
3 files changed, 36 insertions(+), 12 deletions(-)
dif
Hello
The current crypto_engine support only ahash and ablkcipher request.
My first patch which try to add skcipher was Nacked, it will add too many
functions
and adding other algs(aead, asymetric_key) will make the situation worst.
This patchset remove all algs specific stuff and now only proce
Signed-off-by: Corentin Labbe
---
Documentation/crypto/crypto_engine.rst | 48 ++
1 file changed, 48 insertions(+)
create mode 100644 Documentation/crypto/crypto_engine.rst
diff --git a/Documentation/crypto/crypto_engine.rst
b/Documentation/crypto/crypto_engine.
Hi,
On Fri, Jan 12, 2018 at 5:05 PM, Karthikeyan Ramasubramanian
wrote:
> This driver manages the Generic Interface (GENI) firmware based Qualcomm
> Universal Peripheral (QUP) Wrapper. GENI based QUP is the next generation
> programmable module composed of multiple Serial Engines (SE) and support
Hello,
there is cdrom autoclose feature that is supposed to close the tray, wait for
the disc to become ready, and then open the device.
This used to work in ancient times. Then in old times there was a hack in
util-linux which worked around the breakage which probably resulted from
swi
On Fri, 2018-01-26 at 17:58 +0100, Michal Suchanek wrote:
> First time I did not get any feedback for the patches.
This is likely because no-one who might inspect the code saw the
patches ... what list are they going to? I'm on the block, scsi and
ide mailing lists and I only saw a doc patch the
Quoting Rob Landley (2018-01-25 18:40:25)
> On 01/24/2018 09:27 PM, Taras Kondratiuk wrote:
> > diff --git a/usr/gen_init_cpio.c b/usr/gen_init_cpio.c
> > index 7a2a6d85345d..78a47a5bdcb1 100644
> > --- a/usr/gen_init_cpio.c
> > +++ b/usr/gen_init_cpio.c
> > @@ -10,6 +10,7 @@
> > #include
> > #i
Quoting Rob Landley (2018-01-25 18:40:54)
> On 01/24/2018 09:27 PM, Taras Kondratiuk wrote:
> > diff --git a/Documentation/early-userspace/buffer-format.txt
> > b/Documentation/early-userspace/buffer-format.txt
> > index e1fd7f9dad16..d818df4f72dc 100644
> > --- a/Documentation/early-userspace/buf
On Thu, 25 Jan 2018, Andrew Morton wrote:
> > Now that each mem cgroup on the system has a memory.oom_policy tunable to
> > specify oom kill selection behavior, remove the needless "groupoom" mount
> > option that requires (1) the entire system to be forced, perhaps
> > unnecessarily, perhaps unex
On Fri, 26 Jan 2018, Michal Hocko wrote:
> > Could you elaborate on why specifying the oom policy for the entire
> > hierarchy as part of the root mem cgroup and also for individual subtrees
> > is incomplete? It allows admins to specify and delegate policy decisions
> > to subtrees owners as
On Fri, 26 Jan 2018 14:20:24 -0800 (PST) David Rientjes
wrote:
> On Thu, 25 Jan 2018, Andrew Morton wrote:
>
> > > Now that each mem cgroup on the system has a memory.oom_policy tunable to
> > > specify oom kill selection behavior, remove the needless "groupoom" mount
> > > option that requires
On Fri, 26 Jan 2018, Andrew Morton wrote:
> > -ECONFUSED. We want to have a mount option that has the sole purpose of
> > doing echo cgroup > /mnt/cgroup/memory.oom_policy?
>
> Approximately. Let me put it another way: can we modify your patchset
> so that the mount option remains, and continu
On Fri, 26 Jan 2018 14:52:59 -0800 (PST) David Rientjes
wrote:
> On Fri, 26 Jan 2018, Andrew Morton wrote:
>
> > > -ECONFUSED. We want to have a mount option that has the sole purpose of
> > > doing echo cgroup > /mnt/cgroup/memory.oom_policy?
> >
> > Approximately. Let me put it another wa
The open_for_audio and open_for_data copies are bitrotten in different
ways already and will need to update the autoclose logic in both.
Signed-off-by: Michal Suchanek
---
drivers/cdrom/cdrom.c | 100 ++
1 file changed, 36 insertions(+), 64 deletio
23 matches
Mail list logo
