Re: [PATCH] ubifs: default to zstd compression

Hi, Richard, On Thu, 8 Apr 2021 at 12:00, Richard Weinberger wrote: > > I was about to NACK this patch but by looking at the diff I realized > that you change > the default compressor only for the default filesystem as created by > UBIFS itself. Yes, that was the idea. :) > Queued for the

[PATCH] ubifs: default to zstd compression

Compared to lzo and zlib, zstd is the best all-around performer, both in terms of speed and compression ratio. Set it as the default, if available. Signed-off-by: Rui Salvaterra --- fs/ubifs/sb.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/ubifs/sb.c b/fs/ubifs/sb.c index

Re: [RFC PATCH v2] jffs2: add support for zstd compression

Friendly ping (and also cc'ing dwmw2). On Tue, 16 Mar 2021 at 14:19, Rui Salvaterra wrote: > > Implement support for zstd compression in jffs2 at the default compression > level (3). > > Lightly tested in OpenWrt, on a single CPU embedded MIPS32 system (AirGrid > M2).

[RFC PATCH v2] jffs2: add support for zstd compression

Implement support for zstd compression in jffs2 at the default compression level (3). Lightly tested in OpenWrt, on a single CPU embedded MIPS32 system (AirGrid M2). Signed-off-by: Rui Salvaterra --- v2: fix blunder in compression context allocation fs/jffs2/Kconfig | 9 +++ fs

Re: [RFC PATCH] jffs2: add support for zstd compression

Hi, Please ignore this, I noticed a bug. I'll send a fixed v2 shortly. Thanks, Rui On Fri, 12 Mar 2021 at 09:56, Rui Salvaterra wrote: > > Implement support for zstd compression in jffs2 at the default compression > level (3). > > Lightly tested in OpenWrt, on a single CPU

[RFC PATCH] jffs2: add support for zstd compression

Implement support for zstd compression in jffs2 at the default compression level (3). Lightly tested in OpenWrt, on a single CPU embedded MIPS32 system (AirGrid M2). Signed-off-by: Rui Salvaterra --- Sent as RFC, since I have no idea if locking is required (the crypto API implementation doesn't

Re: [PATCH] ARM: dts: turris-omnia: fix hardware buffer management

Hi, Andrew, On Wed, 17 Feb 2021 at 16:22, Andrew Lunn wrote: > > Hi Rui > > I don't know all the details for the MBus Windows... Neither do I, I just followed the examples in other device trees (namely armada-385-linksys.dtsi). I wanted to get hardware buffer management working on my Omnia, in

Re: [PATCH] ARM: dts: turris-omnia: fix hardware buffer management

Hi again, Marek, On Wed, 17 Feb 2021 at 16:10, Marek Behún wrote: > > Rui, in the future make the subject prefix > [PATCH mvebu-dt] > or > [PATCH mvebu/dt] > > so that Gregory knows its for him and for which branch. Thanks, will do! Cheers, Rui

Re: [PATCH] ARM: dts: turris-omnia: fix hardware buffer management

Hi, Marek, On Wed, 17 Feb 2021 at 15:42, Marek Behún wrote: > > /o\ How did I manage to miss this? Heh… it happens. :) > Please wait a few minutes I am just going to do a fast compile and test. No worries. I'm going to cook a backport for OpenWrt. Cheers, Rui

[PATCH] ARM: dts: turris-omnia: fix hardware buffer management

Hardware buffer management has never worked on the Turris Omnia, as the required MBus window hadn't been reserved. Fix thusly. Fixes: 018b88eee1a2 ("ARM: dts: turris-omnia: enable HW buffer management") Signed-off-by: Rui Salvaterra --- arch/arm/boot/dts/armada-385-turris-omnia.dts

Re: [BUG] iwlwifi: card unusable after firmware crash

Hi, again, I haven't tested any patch or bisected, but I have another data point. I built and tested Linux 5.8.18, with the same firmware, and it is working correctly. I reduced the test case to just rfkilling the connection, which showed the register dump immediately (before that I was using the

Re: [BUG] iwlwifi: card unusable after firmware crash

Hi again, Emmanuel, On Wed, 9 Dec 2020 at 21:07, Emmanuel Grumbach wrote: > > Indeed, the bit is reverse logic. So we can put that aside. > Frankly, I have no clue. You can try our backport tree to bisect, > should be easier.. > What I see here is that your GP_CTRL value is 080003d8 > > #define

Re: [BUG] iwlwifi: card unusable after firmware crash

Hi, again, On Wed, 9 Dec 2020 at 20:40, Emmanuel Grumbach wrote: > > Besides, don't you get a stack dump in the vicinity of this register > dump? That's be helpful to see. Nope. No stack trace at all. Only the register dump. Thanks, Rui

Re: [BUG] iwlwifi: card unusable after firmware crash

Hi, Emmanuel, On Wed, 9 Dec 2020 at 20:32, Emmanuel Grumbach wrote: > > Rui, I looked at the register dump and looks like you're using AMT on > your system? > Can you confirm? AMT? You mean Intel Active Management? Heavens, no, not that I know of! This is a personal laptop (Lenovo B51-80). (And

Re: [BUG] iwlwifi: card unusable after firmware crash

Hi, guys, On Wed, 9 Dec 2020 at 17:13, Jakub Kicinski wrote: > > Any luck figuring this out, Luca? If this is a 5.10 regression we need > to let Linus know tomorrow, so the time is ticking :( I don't have the possibility to test other kernels at the moment, but I will do so in a few days (at

Re: [BUG] iwlwifi: card unusable after firmware crash

Hi, Luca, On Tue, 8 Dec 2020 at 16:27, Coelho, Luciano wrote: > > On Tue, 2020-12-08 at 11:27 +0000, Rui Salvaterra wrote: > > > > [ 3174.003910] iwlwifi :02:00.0: RF_KILL bit toggled to disable radio. > > [ 3174.003913] iwlwifi :02:00.0: reporting RF_KILL (radi

Re: [BUG] iwlwifi: card unusable after firmware crash

Hi, Jakub, On Tue, 8 Dec 2020 at 16:06, Jakub Kicinski wrote: > > Just to confirm - is this a regression in 5.10-rc? Does 5.9 work > smoothly in the problematic scenario? Good question. It's definitely a regression, though I don't remember exactly the last working version I had. I *think* 5.9

[BUG] iwlwifi: card unusable after firmware crash

Hi, everyone, I'm running Linux 5.10-rc7 with this firmware/hardware: [1.431878] iwlwifi :02:00.0: loaded firmware version 29.198743027.0 7265D-29.ucode op_mode iwlmvm [1.431899] iwlwifi :02:00.0: Detected Intel(R) Dual Band Wireless AC 3165, REV=0x210 Most of the time, after

[PATCH v7] zram: break the strict dependency from lzo

off-by: Rui Salvaterra --- v7: rebase against 5.10-rc7 and fix unmet direct dependencies, as reported by Stephen Rothwell on linux-next. v6: simplify the kconfig as per Minchan's suggestion. v5: incorporate Minchan's feedback. Allow the user to choose a default algorithm. v4: incorporate Serge

Re: linux-next: build failure after merge of the akpm-current tree

On Thu, 3 Dec 2020 at 09:37, Rui Salvaterra wrote: > > Thanks for the heads-up, I think I know where the problem is. Then again, maybe not. I don't have a PowerPC machine to test, at the moment, and all my x86(-64) machines work fine. If no one beats me to it, I can debug on an iB

Re: linux-next: build failure after merge of the akpm-current tree

Hi, Stephen, On Thu, 3 Dec 2020 at 09:08, Stephen Rothwell wrote: > > Hi all, > > After merging the akpm-current tree, today's linux-next build (powerpc > ppc44x_defconfig) failed like this: > […] > > Caused by commit > > a6d52df2d8bc ("zram: break the strict dependency from lzo") > > I have

[BUG] intel_idle: build failure on Linux 5.10-rc6

Hi, Peter, I'm sorry to bother you, but commit 6e1d2bc675bd57640f5658a4a657ae488db4c204 ("intel_idle: Fix intel_idle() vs tracing") broke my build, when CONFIG_ACPI_PROCESSOR is disabled (possibly because it selects CONFIG_ACPI_PROCESSOR_IDLE): drivers/idle/intel_idle.c: In function

Re: [PATCH v6] zram: break the strict dependency from lzo

On Wed, 25 Nov 2020 at 19:56, Minchan Kim wrote: > > Acked-by: Minchan Kim > > Thanks, Rui! You're welcome, thanks for the patience! :)

[PATCH v6] zram: break the strict dependency from lzo

off-by: Rui Salvaterra --- v6: simplify the kconfig as per Minchan's suggestion. v5: incorporate Minchan's feedback. Allow the user to choose a default algorithm. v4: incorporate Sergey's feedback and fix a small typo. v3: fix the default selection when lzo isn't present. Rebase against 5.10-rc1.

Re: [PATCH v5] zram: break the strict dependency from lzo

Hi, Minchan, On Sat, 21 Nov 2020 at 00:44, Rui Salvaterra wrote: > > Well, it's quite possible I mis{read,applied} your patch. And I obviously did. Your kconfig suggestion does basically the same, in a more simplified way. I guess a v6 is in order. Thanks, Rui

Re: [PATCH v5] zram: break the strict dependency from lzo

Hi, Minchan, On Fri, 20 Nov 2020 at 21:40, Minchan Kim wrote: > > Do I miss your point? Well, it's quite possible I mis{read,applied} your patch. It's late here, I'll test it with fresher brains tomorrow to see if it's functionally equivalent. Thanks, Rui

Re: [PATCH v5] zram: break the strict dependency from lzo

Hi, Minchan, On Thu, 19 Nov 2020 at 22:26, Minchan Kim wrote: > > What's the purpose of ZRAM_AUTOSEL_ALGO? > If you and Sergey already discussed, sorry about the missing it. The purpose of ZRAM_AUTOSEL_ALGO is to make sure at least one of the required compression algorithms is enabled, either

[PATCH v5] zram: break the strict dependency from lzo

off-by: Rui Salvaterra --- v5: incorporate Minchan's feedback. Allow the user to choose a default algorithm. v4: incorporate Sergey's feedback and fix a small typo. v3: fix the default selection when lzo isn't present. Rebase against 5.10-rc1. v2: fix the dependency on CRYPTO. I beli

Re: [PATCH v4] zram: break the strict dependency from lzo

Hi, Minchan, On Tue, 3 Nov 2020 at 21:29, Minchan Kim wrote: > > Can't we just provide choice/endchoice in Kconfig to select default > comp algorithm from admin? I'm fine with whatever you guys decide, just let me know what works best for everyone. Thanks, Rui

Re: [PATCH v3] zram: break the strict dependency from lzo

Hi, again, On Wed, 28 Oct 2020 at 18:22, Sergey Senozhatsky wrote: > > Right, but well we also need to select ZSMALLOC and CRYPTO for > zram to become visible (the thing that I found out recently is > that you can always check the hidden/blocked items by hitting > 'z' in menuconfig). Sure, I

[PATCH v4] zram: break the strict dependency from lzo

There's nothing special about zram and lzo. It works just fine without it, so as long as at least one of the other supported compression algorithms is selected. Suggested-by: Sergey Senozhatsky Signed-off-by: Rui Salvaterra --- v4: incorporate Sergey's feedback and fix a small typo. v3: fix

Re: [PATCH v3] zram: break the strict dependency from lzo

Hi, Sergey, On Wed, 28 Oct 2020 at 10:19, Sergey Senozhatsky wrote: > > Can the following work then? Almost! See below. :) > Completely untested. > > ===8<=== > > diff --git a/drivers/block/zram/Kconfig b/drivers/block/zram/Kconfig > index fe7a4b7d30cf..f93eed40e155 100644 > ---

Re: [PATCH v3] zram: break the strict dependency from lzo

Hi, Sergey, On Tue, 27 Oct 2020 at 01:22, Sergey Senozhatsky wrote: > > Honestly, I'm not entirely excited. lzo is a fallback compression > algorithm. If you want to use zram with something else thenconfigure > zram to use something else. What do all these #if/#elif buy us? The idea is to allow

[PATCH v3] zram: break the strict dependency from lzo

There's nothing special about zram and lzo. It works just fine without it, so as long as at least one of the other supported compression algorithms is selected. Signed-off-by: Rui Salvaterra --- v3: fix the default selection when lzo isn't present. Rebase against 5.10-rc1. v2: fix the dependency

Re: [PATCH v2] zram: break the strict dependency from lzo

Sigh. Please disregard this too, I also need to fix the default selection. I'll send a new version against 5.10-rc1, next week. On Thu, 22 Oct 2020 at 22:30, Rui Salvaterra wrote: > > There's nothing special about zram and lzo. It works just fine without it, so > as long as at

[PATCH v2] zram: break the strict dependency from lzo

There's nothing special about zram and lzo. It works just fine without it, so as long as at least one of the other supported compression algorithms is selected. Signed-off-by: Rui Salvaterra --- v2: fix the dependency on CRYPTO. drivers/block/zram/Kconfig | 6 +- drivers/block/zram/zcomp.c

Re: [PATCH] zram: break the strict dependency from lzo

Oops, this is broken, I'll send a v2 soon. On Thu, 22 Oct 2020 at 17:11, Rui Salvaterra wrote: > > There's nothing special about zram and lzo. It works just fine without it, so > as long as at least one of the other supported compression algorithms is > selected. > >

[PATCH] zram: break the strict dependency from lzo

-by: Rui Salvaterra --- drivers/block/zram/Kconfig | 8 ++-- drivers/block/zram/zcomp.c | 2 ++ 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/block/zram/Kconfig b/drivers/block/zram/Kconfig index fe7a4b7d30cf..2641b86f8677 100644 --- a/drivers/block/zram/Kconfig +++ b

Re: [BISECTED] bug/regression, x86-64: completely unbootable machine

On Sat, 25 Apr 2020 at 17:01, Giovanni Gherdovich wrote: > > There is an easy way to tell (besides compiling with those patches on top and > check if it works): run the command "turbostat --interval 1 sleep 0", the > output should tell you the content of the register MSR_TURBO_RATIO_LIMIT. > > If

Re: [PATCHv2] Bluetooth: trivial: tidy up printk message output from btrtl.

Hi, Marcel, On Thu, 26 Sep 2019 at 07:34, Marcel Holtmann wrote: > > Hi Rui, [patch snipped] > I have some similar patch in my tree. Can you check what is still missing and > send a new version. Thanks. Yeah, from a cursory look at your tree, it seems about the same as mine. I'll take a

Re: [PATCH] netfilter: trivial: remove extraneous space from message

Friendly ping. On Wed, 24 Jul 2019 at 15:37, Rui Salvaterra wrote: > > Pure ocd, but this one has been bugging me for a while. > > Signed-off-by: Rui Salvaterra > --- > net/netfilter/nf_conntrack_helper.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >

[PATCHv2] Bluetooth: trivial: tidy up printk message output from btrtl.

: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Signed-off-by: Rui Salvaterra --- drivers/bluetooth/btrtl.c | 62 +++--- drivers/bluetooth/btrtl.h | 8 ++--- drivers/bluetooth/hci_h5.c | 2 +- 3 files changed, 36 insertions(+), 36 deletions(-) diff --git

[PATCH] Bluetooth: trivial: tidy up printk message output from btrtl.

) Signed-off-by: Rui Salvaterra --- drivers/bluetooth/btrtl.c | 62 +++ drivers/bluetooth/btrtl.h | 8 ++--- 2 files changed, 35 insertions(+), 35 deletions(-) diff --git a/drivers/bluetooth/btrtl.c b/drivers/bluetooth/btrtl.c index 4f75a9b61d09..0c9c16444ce5

Re: [BUG] Linux 5.3-rc1: timer problem on x86-64 (Pentium D)

Hi, Thomas, On Thu, 25 Jul 2019 at 10:37, Thomas Gleixner wrote: > > Duh. Yes, this explains it nicely. > > > [1.123548] clocksource: timekeeping watchdog on CPU1: Marking > > clocksource 'tsc-early' as unstable because the skew is too large: > > [1.123552] clocksource:

Re: [BUG] Linux 5.3-rc1: timer problem on x86-64 (Pentium D)

On Wed, 24 Jul 2019 at 12:02, Thomas Gleixner wrote: > > Rui, > > On Wed, 24 Jul 2019, Rui Salvaterra wrote: > > I don't know if this has been reported before, but from a cursory > > search it doesn't seem to be the case. > > I have a x86-64 Pentium (4) D machine

[PATCH] netfilter: trivial: remove extraneous space from message

Pure ocd, but this one has been bugging me for a while. Signed-off-by: Rui Salvaterra --- net/netfilter/nf_conntrack_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/netfilter/nf_conntrack_helper.c b/net/netfilter/nf_conntrack_helper.c index 8d729e7c36ff

[BUG] Linux 5.3-rc1: timer problem on x86-64 (Pentium D)

Hi, everyone, I don't know if this has been reported before, but from a cursory search it doesn't seem to be the case. I have a x86-64 Pentium (4) D machine which always worked perfectly with Linux 5.2 using the TSC as the clock source. With Linux 5.3-rc1 I can't, for the life of me, boot it with

Re: use generic DMA mapping code in powerpc V4

On Mon, 10 Dec 2018 at 20:49, Benjamin Herrenschmidt wrote: > [snip] > > AGP is a gigantic nightmare :-) It's not just cache coherency issues > (some implementations are coherent, some aren't, Apple's is ... weird). > > Apple has all sort of bugs, and Darwin source code only sheds light on >

Re: use generic DMA mapping code in powerpc V4

On Mon, 10 Dec 2018 at 19:33, Christoph Hellwig wrote: > > On Mon, Dec 10, 2018 at 05:04:46PM +0000, Rui Salvaterra wrote: > > Hi, Christoph and Ben, > > > > It just came to my mind (and this is most likely a stupid question, > > but still)… Is there any possi

Re: use generic DMA mapping code in powerpc V4

On Sat, 8 Dec 2018 at 17:17, Christoph Hellwig wrote: > > On Sun, Dec 02, 2018 at 05:11:02PM +1100, Benjamin Herrenschmidt wrote: > > Talking of which ... Christoph, not sure if we can do something about > > this at the DMA API level or keep hacks but some adapters such as the > > nVidia GPUs

Re: 4.19-rc3: bindeb-pkg target is failing on ppc64

On Thu, 13 Sep 2018 at 16:49, Ben Hutchings wrote: > > Like I said, please send the error messages; we're not going to guess. > > Ben. > > -- > Ben Hutchings > Computers are not intelligent. They only think they are. I'm an idiot. Turns out it's something completely unrelated. Here's the

Re: 4.19-rc3: bindeb-pkg target is failing on ppc64

On Thu, 13 Sep 2018 at 16:49, Ben Hutchings wrote: > > Like I said, please send the error messages; we're not going to guess. > > Ben. > > -- > Ben Hutchings > Computers are not intelligent. They only think they are. I'm an idiot. Turns out it's something completely unrelated. Here's the

Re: 4.19-rc3: bindeb-pkg target is failing on ppc64

On Thu, 13 Sep 2018 at 13:32, Ben Hutchings wrote: > > On Tue, 2018-09-11 at 15:58 +0100, Rui Salvaterra wrote: > > Greetings! I'm having trouble building the kernel on my ppc64 machine > > (Power Mac G5) running Debian Sid. The make bindeb-pkg target is failing >

Re: 4.19-rc3: bindeb-pkg target is failing on ppc64

On Thu, 13 Sep 2018 at 13:32, Ben Hutchings wrote: > > On Tue, 2018-09-11 at 15:58 +0100, Rui Salvaterra wrote: > > Greetings! I'm having trouble building the kernel on my ppc64 machine > > (Power Mac G5) running Debian Sid. The make bindeb-pkg target is failing >

Re: 4.19-rc3: bindeb-pkg target is failing on ppc64

On Wed, 12 Sep 2018 at 10:32, wrote: > > Hi, Rui, > > > > Could you cater to ‘git bisect’ ? > > > > Thanks > > > > > > Greetings! I'm having trouble building the kernel on my ppc64 machine (Power > Mac G5) running Debian Sid. The make bindeb-pkg target is failing ever since > 4.19-rc1. Is this

Re: 4.19-rc3: bindeb-pkg target is failing on ppc64

On Wed, 12 Sep 2018 at 10:32, wrote: > > Hi, Rui, > > > > Could you cater to ‘git bisect’ ? > > > > Thanks > > > > > > Greetings! I'm having trouble building the kernel on my ppc64 machine (Power > Mac G5) running Debian Sid. The make bindeb-pkg target is failing ever since > 4.19-rc1. Is this

Re: [PATCH v2 1/4] lib: Update LZ4 compressor module based on LZ4 v1.7.2.

On 8 January 2017 at 11:25, Greg KH wrote: > On Sat, Jan 07, 2017 at 05:55:42PM +0100, Sven Schmidt wrote: >> This patch updates LZ4 kernel module to LZ4 v1.7.2 by Yann Collet. >> The kernel module is inspired by the previous work by Chanho Min. >> The updated LZ4

Re: [PATCH v2 1/4] lib: Update LZ4 compressor module based on LZ4 v1.7.2.

On 8 January 2017 at 11:25, Greg KH wrote: > On Sat, Jan 07, 2017 at 05:55:42PM +0100, Sven Schmidt wrote: >> This patch updates LZ4 kernel module to LZ4 v1.7.2 by Yann Collet. >> The kernel module is inspired by the previous work by Chanho Min. >> The updated LZ4 module will not break existing

Re: [RFC] [PATCH] arch: x86: change GCC optimisation target from atom to bonnell

2016-10-11 1:11 GMT+01:00 <h...@zytor.com>: > On October 10, 2016 2:45:38 PM PDT, Rui Salvaterra <rsalvate...@gmail.com> > wrote: >>Hi, Thomas, Ingo, Peter, >> >>(Sending as RFC, since I don't know if this patch is acceptable.) >> >>The GCC team h

Re: [RFC] [PATCH] arch: x86: change GCC optimisation target from atom to bonnell

2016-10-11 1:11 GMT+01:00 : > On October 10, 2016 2:45:38 PM PDT, Rui Salvaterra > wrote: >>Hi, Thomas, Ingo, Peter, >> >>(Sending as RFC, since I don't know if this patch is acceptable.) >> >>The GCC team has deprecated atom as a march/mtune target since a

[RFC] [PATCH] arch: x86: change GCC optimisation target from atom to bonnell

). This patch changes the Atom optimisation target in the kernel to bonnell, as it was originally intended. Tested on an x86-64 Atom 330 machine. No functional changes. [1] https://gcc.gnu.org/ml/gcc-patches/2013-12/msg01805.html Signed-off-by: Rui Salvaterra <rsalvate...@gmail.com> --- arch/x86/Ma

[RFC] [PATCH] arch: x86: change GCC optimisation target from atom to bonnell

). This patch changes the Atom optimisation target in the kernel to bonnell, as it was originally intended. Tested on an x86-64 Atom 330 machine. No functional changes. [1] https://gcc.gnu.org/ml/gcc-patches/2013-12/msg01805.html Signed-off-by: Rui Salvaterra --- arch/x86/Makefile| 4 ++-- arch

[PATCH] powerpc: wire up preadv2 and pwritev2 syscalls

Wire up preadv2/pwritev2 in the same way as preadv/pwritev. Fixes two build warnings on ppc64. Signed-off-by: Rui Salvaterra <rsalvate...@gmail.com> --- arch/powerpc/include/asm/systbl.h | 2 ++ arch/powerpc/include/asm/unistd.h | 2 +- arch/powerpc/include/uapi/asm/unistd.h | 2

[PATCH] powerpc: wire up preadv2 and pwritev2 syscalls

Wire up preadv2/pwritev2 in the same way as preadv/pwritev. Fixes two build warnings on ppc64. Signed-off-by: Rui Salvaterra --- arch/powerpc/include/asm/systbl.h | 2 ++ arch/powerpc/include/asm/unistd.h | 2 +- arch/powerpc/include/uapi/asm/unistd.h | 2 ++ 3 files changed, 5

[PATCH v2 1/2] lib: lz4: fixed zram with lz4 on big endian machines

into the 32-bit definitions on ppc64). Tested on ppc64 with no regression on x86_64. [1] http://marc.info/?l=linux-kernel=145994470805853=4 Cc: sta...@vger.kernel.org Suggested-by: Sergey Senozhatsky <sergey.senozhat...@gmail.com> Signed-off-by: Rui Salvaterra <rsalvate...@gmail.com>

[PATCH v2 1/2] lib: lz4: fixed zram with lz4 on big endian machines

into the 32-bit definitions on ppc64). Tested on ppc64 with no regression on x86_64. [1] http://marc.info/?l=linux-kernel=145994470805853=4 Cc: sta...@vger.kernel.org Suggested-by: Sergey Senozhatsky Signed-off-by: Rui Salvaterra --- lib/lz4/lz4defs.h | 21 - 1 file changed, 12

[PATCH v2 2/2] lib: lz4: cleanup unaligned access efficiency detection

These identifiers are bogus. The interested architectures should define HAVE_EFFICIENT_UNALIGNED_ACCESS whenever relevant to do so. If this isn't true for some arch, it should be fixed in the arch definition. Signed-off-by: Rui Salvaterra <rsalvate...@gmail.com> --- lib/lz4/lz4defs.h | 4 +

[PATCH v2 0/2] lib: lz4: fix for big endian and cleanup

v2: - Addressed GregKH's review and comments. Hi, The first patch fixes zram with lz4 compression on ppc64 (and big endian architectures with efficient unaligned access), the second is just a cleanup. Thanks, Rui Rui Salvaterra (2): lib: lz4: fixed zram with lz4 on big endian

[PATCH v2 2/2] lib: lz4: cleanup unaligned access efficiency detection

These identifiers are bogus. The interested architectures should define HAVE_EFFICIENT_UNALIGNED_ACCESS whenever relevant to do so. If this isn't true for some arch, it should be fixed in the arch definition. Signed-off-by: Rui Salvaterra --- lib/lz4/lz4defs.h | 4 +--- 1 file changed, 1

[PATCH v2 0/2] lib: lz4: fix for big endian and cleanup

v2: - Addressed GregKH's review and comments. Hi, The first patch fixes zram with lz4 compression on ppc64 (and big endian architectures with efficient unaligned access), the second is just a cleanup. Thanks, Rui Rui Salvaterra (2): lib: lz4: fixed zram with lz4 on big endian

[PATCH] lib: lz4: fixed zram with lz4 on big endian machines

Based on Sergey's test patch [1], this fixes zram with lz4 compression on big endian cpus. Tested on ppc64 with no regression on x86_64. [1] http://marc.info/?l=linux-kernel=145994470805853=4 Cc: sta...@vger.kernel.org Signed-off-by: Rui Salvaterra <rsalvate...@gmail.com> --- lib/lz4/lz4

[PATCH] lib: lz4: fixed zram with lz4 on big endian machines

Based on Sergey's test patch [1], this fixes zram with lz4 compression on big endian cpus. Tested on ppc64 with no regression on x86_64. [1] http://marc.info/?l=linux-kernel=145994470805853=4 Cc: sta...@vger.kernel.org Signed-off-by: Rui Salvaterra --- lib/lz4/lz4defs.h | 29

Re: [BUG] lib: zram lz4 compression/decompression still broken on big endian

2016-04-07 15:07 GMT+01:00 Sergey Senozhatsky <sergey.senozhat...@gmail.com>: > On (04/07/16 13:33), Rui Salvaterra wrote: > [..] >> Hi again, Sergey > > Hello, > >> Thanks for the patch, I'll test it as soon as possible. I agree with >> your second option, u

Re: [BUG] lib: zram lz4 compression/decompression still broken on big endian

2016-04-07 15:07 GMT+01:00 Sergey Senozhatsky : > On (04/07/16 13:33), Rui Salvaterra wrote: > [..] >> Hi again, Sergey > > Hello, > >> Thanks for the patch, I'll test it as soon as possible. I agree with >> your second option, usually one selects lz4 when (e

Re: [BUG] lib: zram lz4 compression/decompression still broken on big endian

2016-04-06 14:09 GMT+01:00 Sergey Senozhatsky <sergey.senozhat...@gmail.com>: > Cc Chanho Min, Kyungsik Lee > > > Hello, > > On (04/06/16 10:39), Rui Salvaterra wrote: >> > may we please ask you to test the patch first? quite possible there >> > is nothin

Re: [BUG] lib: zram lz4 compression/decompression still broken on big endian

2016-04-06 14:09 GMT+01:00 Sergey Senozhatsky : > Cc Chanho Min, Kyungsik Lee > > > Hello, > > On (04/06/16 10:39), Rui Salvaterra wrote: >> > may we please ask you to test the patch first? quite possible there >> > is nothing to fix there; I've no access

Re: [BUG] lib: zram lz4 compression/decompression still broken on big endian

2016-04-06 6:33 GMT+01:00 Sergey Senozhatsky <sergey.senozhatsky.w...@gmail.com>: > On (04/05/16 17:02), Rui Salvaterra wrote: > [..] >> > For some reason it never got merged, sorry, I don't remember why. >> > >> > Have you tested this patch? If so,

Re: [BUG] lib: zram lz4 compression/decompression still broken on big endian

2016-04-06 6:33 GMT+01:00 Sergey Senozhatsky : > On (04/05/16 17:02), Rui Salvaterra wrote: > [..] >> > For some reason it never got merged, sorry, I don't remember why. >> > >> > Have you tested this patch? If so, can you resend it with your >> > tes

Re: [BUG] lib: zram lz4 compression/decompression still broken on big endian

2016-04-05 16:34 GMT+01:00 Greg KH <gre...@linuxfoundation.org>: > On Tue, Apr 05, 2016 at 03:07:48PM +0100, Rui Salvaterra wrote: >> Hi, >> >> >> I apologise in advance if I've cc'ed too many/the wrong people/lists. >> >> Whenever I try to

Re: [BUG] lib: zram lz4 compression/decompression still broken on big endian

2016-04-05 16:34 GMT+01:00 Greg KH : > On Tue, Apr 05, 2016 at 03:07:48PM +0100, Rui Salvaterra wrote: >> Hi, >> >> >> I apologise in advance if I've cc'ed too many/the wrong people/lists. >> >> Whenever I try to use zram with lz4, on my Power Mac G5 (teste

[BUG] lib: zram lz4 compression/decompression still broken on big endian

believe Eunbong Song wrote a patch [1] to fix this (or a very identical) bug on MIPS, but it never got merged (maybe incorrect/incomplete?). Is there any hope of seeing this bug fixed? Thanks, Rui Salvaterra [1] http://comments.gmane.org/gmane.linux.kernel/1752745

[BUG] lib: zram lz4 compression/decompression still broken on big endian

believe Eunbong Song wrote a patch [1] to fix this (or a very identical) bug on MIPS, but it never got merged (maybe incorrect/incomplete?). Is there any hope of seeing this bug fixed? Thanks, Rui Salvaterra [1] http://comments.gmane.org/gmane.linux.kernel/1752745