On Fri, 2018-06-22 at 12:08 +0200, Geert Uytterhoeven wrote:
> Submitters of device tree binding documentation may forget to CC
> the subsystem maintainer if this is missing.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> v3:
> - Update for next-20180622,
>
> v2:
> - No changes.
>
> Impact
Acked-by: Anson Huang
I also saw such issue on i.MX6SLL evk board, and also sent out patch for
i.MX6SLL.
Anson Huang
Best Regards!
> -Original Message-
> From: Robin Gong
> Sent: Monday, June 25, 2018 8:34 PM
> To: shawn...@kernel.org; ker...@pengutronix.de; Fabio Estevam
> ;
On Fri, 2018-06-22 at 12:08 +0200, Geert Uytterhoeven wrote:
> Submitters of device tree binding documentation may forget to CC
> the subsystem maintainer if this is missing.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> v3:
> - Update for next-20180622,
>
> v2:
> - No changes.
>
> Impact
Acked-by: Anson Huang
I also saw such issue on i.MX6SLL evk board, and also sent out patch for
i.MX6SLL.
Anson Huang
Best Regards!
> -Original Message-
> From: Robin Gong
> Sent: Monday, June 25, 2018 8:34 PM
> To: shawn...@kernel.org; ker...@pengutronix.de; Fabio Estevam
> ;
Hi all,
Changes since 20180622:
New tree: drm-fixes
The cifs tree gained a build failure so I used the version from
next-20180622.
The drm tree gained a build failure for which I disabled some sample
code.
Non-merge commits (relative to Linus' tree): 2098
2146 files changed, 64960
Hi all,
Changes since 20180622:
New tree: drm-fixes
The cifs tree gained a build failure so I used the version from
next-20180622.
The drm tree gained a build failure for which I disabled some sample
code.
Non-merge commits (relative to Linus' tree): 2098
2146 files changed, 64960
Kselftest test case mov_ss_trap_64 is causing kernel panic on
qemu-system-x86_64 and PASS on real x86_64 hardware.
Test code snippet,
main() {
<>
printf("[RUN]\tMOV SS; CS CS INT3\n");
asm volatile ("mov %[ss], %%ss; .byte 0x2e, 0x2e; int3" :: [ss] "m" (ss));
<>
}
Linux version
Kselftest test case mov_ss_trap_64 is causing kernel panic on
qemu-system-x86_64 and PASS on real x86_64 hardware.
Test code snippet,
main() {
<>
printf("[RUN]\tMOV SS; CS CS INT3\n");
asm volatile ("mov %[ss], %%ss; .byte 0x2e, 0x2e; int3" :: [ss] "m" (ss));
<>
}
Linux version
From: yiqiaoxihui
GCC 5.4.0 enables raw strings by default and they have higher priority
than macros, thus R is interpreted incorrectly.
Fix it by putting a space between macro R and a string literal.
Signed-off-by: yiqiaoxihui
---
arch/x86/kvm/svm.c | 36 ++--
From: yiqiaoxihui
GCC 5.4.0 enables raw strings by default and they have higher priority
than macros, thus R is interpreted incorrectly.
Fix it by putting a space between macro R and a string literal.
Signed-off-by: yiqiaoxihui
---
arch/x86/kvm/svm.c | 36 ++--
If PAGE_SIZE is unsigned type then negative error code will be
larger than PAGE_SIZE.
Signed-off-by: Chengguang Xu
---
kernel/power/swap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/power/swap.c b/kernel/power/swap.c
index c2bcf97d24c8..d7f6c1a288d3 100644
If PAGE_SIZE is unsigned type then negative error code will be
larger than PAGE_SIZE.
Signed-off-by: Chengguang Xu
---
kernel/power/swap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/power/swap.c b/kernel/power/swap.c
index c2bcf97d24c8..d7f6c1a288d3 100644
On 24 June 2018 at 20:53, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.110 release.
> There are 39 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 24 June 2018 at 20:53, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.110 release.
> There are 39 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.
>
>
From: Bjorn Andersson
Some LED controllers have support for autonomously controlling
brightness over time, according to some preprogrammed pattern or
function.
This adds a new optional operator that LED class drivers can implement
if they support such functionality as well as a new device
From: Bjorn Andersson
Some LED controllers have support for autonomously controlling
brightness over time, according to some preprogrammed pattern or
function.
This adds a new optional operator that LED class drivers can implement
if they support such functionality as well as a new device
This patch implements the 'pattern_set', 'pattern_get' and 'pattern_clear'
interfaces to support SC27XX LED breathing mode.
Signed-off-by: Baolin Wang
---
drivers/leds/leds-sc27xx-bltc.c | 160 +++
1 file changed, 160 insertions(+)
diff --git
This patch implements the 'pattern_set', 'pattern_get' and 'pattern_clear'
interfaces to support SC27XX LED breathing mode.
Signed-off-by: Baolin Wang
---
drivers/leds/leds-sc27xx-bltc.c | 160 +++
1 file changed, 160 insertions(+)
diff --git
On 21-06-18, 14:40, Srinivas Kandagatla wrote:
> + if (txn->mt == SLIM_MSG_MT_CORE &&
> + (txn->mc == SLIM_MSG_MC_CONNECT_SOURCE ||
> + txn->mc == SLIM_MSG_MC_CONNECT_SINK ||
> + txn->mc == SLIM_MSG_MC_DISCONNECT_PORT)) {
> +
> + txn->mt =
On 21-06-18, 14:40, Srinivas Kandagatla wrote:
> + if (txn->mt == SLIM_MSG_MT_CORE &&
> + (txn->mc == SLIM_MSG_MC_CONNECT_SOURCE ||
> + txn->mc == SLIM_MSG_MC_CONNECT_SINK ||
> + txn->mc == SLIM_MSG_MC_DISCONNECT_PORT)) {
> +
> + txn->mt =
SW4 is one power rail for LPDDR2 on i.mx6sl-evk, so it should
be kept always on. But it's disabled after switch disabled
interface implemented in pfuze driver
'commit 5fe156f1cab4
("regulator: pfuze100: add enable/disable for switch")'.Thus,
it breaks kernel bootup. Add 'regulator-always-on' for
SW4 is one power rail for LPDDR2 on i.mx6sl-evk, so it should
be kept always on. But it's disabled after switch disabled
interface implemented in pfuze driver
'commit 5fe156f1cab4
("regulator: pfuze100: add enable/disable for switch")'.Thus,
it breaks kernel bootup. Add 'regulator-always-on' for
This patch adds GPIO for headphone detection on LD20 global board.
Signed-off-by: Katsuhiro Suzuki
---
arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
This patch adds GPIO for headphone detection on LD11 global board.
Signed-off-by: Katsuhiro Suzuki
---
arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
This patch adds GPIO for headphone detection on LD20 global board.
Signed-off-by: Katsuhiro Suzuki
---
arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
This patch adds GPIO for headphone detection on LD11 global board.
Signed-off-by: Katsuhiro Suzuki
---
arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
The UniPhier platform highly relies on the reset controller.
Select RESET_CONTROLLER to enable it forcibly.
Signed-off-by: Masahiro Yamada
---
arch/arm/mach-uniphier/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-uniphier/Kconfig b/arch/arm/mach-uniphier/Kconfig
The UniPhier platform highly relies on the reset controller.
Select RESET_CONTROLLER to enable it forcibly.
Signed-off-by: Masahiro Yamada
---
arch/arm/mach-uniphier/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-uniphier/Kconfig b/arch/arm/mach-uniphier/Kconfig
The UniPhier platform highly relies on the reset controller.
Select RESET_CONTROLLER to enable it forcibly.
Signed-off-by: Masahiro Yamada
---
arch/arm64/Kconfig.platforms | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index
The UniPhier platform highly relies on the reset controller.
Select RESET_CONTROLLER to enable it forcibly.
Signed-off-by: Masahiro Yamada
---
arch/arm64/Kconfig.platforms | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index
Hi Loic Pallardy, Bjorn Andersson,
This patchset also helps in getting VirtIO RPMSG driver working
with VirtIO MMIO transport.
Is it possible to have this patchset part of Linux-4.19 or Linux-4.20?
Regards,
Anup
Hi Loic Pallardy, Bjorn Andersson,
This patchset also helps in getting VirtIO RPMSG driver working
with VirtIO MMIO transport.
Is it possible to have this patchset part of Linux-4.19 or Linux-4.20?
Regards,
Anup
In 1GB huge pages allocation, a regression bug could be triggered when
KASLR is enabled. On a KVM guest with 4GB RAM, after adding the following
to the kernel command-line:
'default_hugepagesz=1G hugepagesz=1G hugepages=1'
then boot the guest and check number of 1GB pages reserved:
#
In 1GB huge pages allocation, a regression bug could be triggered when
KASLR is enabled. On a KVM guest with 4GB RAM, after adding the following
to the kernel command-line:
'default_hugepagesz=1G hugepagesz=1G hugepages=1'
then boot the guest and check number of 1GB pages reserved:
#
This is a regression bug fix. Luiz's team reported that 1GB huge page
allocation will get one less 1GB page randomly when KASLR is enabled. On
their KVM guest with 4GB RAM, which only has one good 1GB huge page,
they found the 1GB huge page allocation sometime failed with below
kernel option
Functions parse_gb_huge_pages() and process_gb_huge_pages() are
introduced to handle a conflict between KASLR and huge pages of
GB, will be used in the next patch.
Function parse_gb_huge_pages() is used to parse kernel
command-line to get how many 1GB huge pages have been specified.
A static
This is a regression bug fix. Luiz's team reported that 1GB huge page
allocation will get one less 1GB page randomly when KASLR is enabled. On
their KVM guest with 4GB RAM, which only has one good 1GB huge page,
they found the 1GB huge page allocation sometime failed with below
kernel option
Functions parse_gb_huge_pages() and process_gb_huge_pages() are
introduced to handle a conflict between KASLR and huge pages of
GB, will be used in the next patch.
Function parse_gb_huge_pages() is used to parse kernel
command-line to get how many 1GB huge pages have been specified.
A static
Gentle Ping...
Anson Huang
Best Regards!
> -Original Message-
> From: Anson Huang
> Sent: Sunday, June 3, 2018 11:01 AM
> To: shawn...@kernel.org; ker...@pengutronix.de; Fabio Estevam
> ; mturque...@baylibre.com; sb...@kernel.org
> Cc: dl-linux-imx ;
Gentle Ping...
Anson Huang
Best Regards!
> -Original Message-
> From: Anson Huang
> Sent: Sunday, June 3, 2018 11:01 AM
> To: shawn...@kernel.org; ker...@pengutronix.de; Fabio Estevam
> ; mturque...@baylibre.com; sb...@kernel.org
> Cc: dl-linux-imx ;
Gentle Ping...
Anson Huang
Best Regards!
> -Original Message-
> From: Anson Huang
> Sent: Sunday, June 3, 2018 9:44 AM
> To: shawn...@kernel.org; ker...@pengutronix.de; Fabio Estevam
> ; robh...@kernel.org; mark.rutl...@arm.com;
> mturque...@baylibre.com; sb...@kernel.org;
>
Gentle Ping...
Anson Huang
Best Regards!
> -Original Message-
> From: Anson Huang
> Sent: Sunday, June 3, 2018 9:44 AM
> To: shawn...@kernel.org; ker...@pengutronix.de; Fabio Estevam
> ; robh...@kernel.org; mark.rutl...@arm.com;
> mturque...@baylibre.com; sb...@kernel.org;
>
Hello Yamada-san,
> -Original Message-
> From: Masahiro Yamada
> Sent: Saturday, June 23, 2018 12:47 PM
> To: Suzuki, Katsuhiro/鈴木 勝博
> Cc: linux-arm-kernel ; DTML
> ; Masami Hiramatsu ;
> Jassi Brar ; Linux Kernel Mailing List
>
> Subject: Re: [PATCH 1/2] arm64: dts: uniphier: add
Hello Yamada-san,
> -Original Message-
> From: Masahiro Yamada
> Sent: Saturday, June 23, 2018 12:47 PM
> To: Suzuki, Katsuhiro/鈴木 勝博
> Cc: linux-arm-kernel ; DTML
> ; Masami Hiramatsu ;
> Jassi Brar ; Linux Kernel Mailing List
>
> Subject: Re: [PATCH 1/2] arm64: dts: uniphier: add
From: A.s. Dong Sent: 2018年6月24日 12:24
> Copy Andy & Frank,
>
> > -Original Message-
> > From: Michal Vokáč [mailto:michal.vo...@ysoft.com]
> > Sent: Tuesday, June 12, 2018 11:10 PM
> > To: linux-g...@vger.kernel.org
> > Cc: linux-arm-ker...@lists.infradead.org; Shawn Guo
> > ; Sascha
From: A.s. Dong Sent: 2018年6月24日 12:24
> Copy Andy & Frank,
>
> > -Original Message-
> > From: Michal Vokáč [mailto:michal.vo...@ysoft.com]
> > Sent: Tuesday, June 12, 2018 11:10 PM
> > To: linux-g...@vger.kernel.org
> > Cc: linux-arm-ker...@lists.infradead.org; Shawn Guo
> > ; Sascha
Hi Jonathan,
On 22 June 2018 at 22:26, Jonathan Cameron wrote:
> On Mon, 18 Jun 2018 18:47:18 +0800
> Baolin Wang wrote:
>
>> Hi Jonathan,
>>
>> On 18 June 2018 at 18:20, Jonathan Cameron
>> wrote:
>> >
>> >
>> > On 17 June 2018 09:03:04 BST, Baolin Wang wrote:
>> >>Hi Jonathan,
>> >>
>>
Hi Jonathan,
On 22 June 2018 at 22:26, Jonathan Cameron wrote:
> On Mon, 18 Jun 2018 18:47:18 +0800
> Baolin Wang wrote:
>
>> Hi Jonathan,
>>
>> On 18 June 2018 at 18:20, Jonathan Cameron
>> wrote:
>> >
>> >
>> > On 17 June 2018 09:03:04 BST, Baolin Wang wrote:
>> >>Hi Jonathan,
>> >>
>>
2018-06-20 16:27 GMT+09:00 Abhishek Sahu :
> commit 2c8f8afa7f92 ("mtd: nand: add generic helpers to check,
> match, maximize ECC settings") provides generic helpers which
> drivers can use for setting up ECC parameters.
>
> Since same board can have different ECC strength nand chips so
>
2018-06-20 16:27 GMT+09:00 Abhishek Sahu :
> commit 2c8f8afa7f92 ("mtd: nand: add generic helpers to check,
> match, maximize ECC settings") provides generic helpers which
> drivers can use for setting up ECC parameters.
>
> Since same board can have different ECC strength nand chips so
>
On 06/24/2018 04:51 PM, Randy Dunlap wrote:
> Hi,
>
> I'm seeing lots of this type of warning in 4.18-rc2 (maybe even before,
> but this is on x86_32/i386, so maybe people aren't checking it so much?):
>
> In file included from ../arch/x86/kernel/process_32.c:40:
>
On 06/24/2018 04:51 PM, Randy Dunlap wrote:
> Hi,
>
> I'm seeing lots of this type of warning in 4.18-rc2 (maybe even before,
> but this is on x86_32/i386, so maybe people aren't checking it so much?):
>
> In file included from ../arch/x86/kernel/process_32.c:40:
>
On Tue, Jun 05, 2018 at 08:59:52PM +0200, Alexandre Belloni wrote:
> On 05/06/2018 20:51:06+0200, Enric Balletbo i Serra wrote:
> > Hi Alexandre,
> >
> > On 05/06/18 11:46, Alexandre Belloni wrote:
> > > On 05/06/2018 11:22:05+0200, Enric Balletbo i Serra wrote:
> > >> Adopt the SPDX license
On Tue, Jun 05, 2018 at 08:14:24PM +0200, Enric Balletbo i Serra wrote:
> Hi Fabio,
>
> On 05/06/18 20:04, Fabio Estevam wrote:
> > Hi Enric,
> >
> > On Tue, Jun 5, 2018 at 2:54 PM, Enric Balletbo i Serra
> > wrote:
> >> Adopt the SPDX license identifier headers to ease license compliance
> >>
On Tue, Jun 05, 2018 at 08:59:52PM +0200, Alexandre Belloni wrote:
> On 05/06/2018 20:51:06+0200, Enric Balletbo i Serra wrote:
> > Hi Alexandre,
> >
> > On 05/06/18 11:46, Alexandre Belloni wrote:
> > > On 05/06/2018 11:22:05+0200, Enric Balletbo i Serra wrote:
> > >> Adopt the SPDX license
On Tue, Jun 05, 2018 at 08:14:24PM +0200, Enric Balletbo i Serra wrote:
> Hi Fabio,
>
> On 05/06/18 20:04, Fabio Estevam wrote:
> > Hi Enric,
> >
> > On Tue, Jun 5, 2018 at 2:54 PM, Enric Balletbo i Serra
> > wrote:
> >> Adopt the SPDX license identifier headers to ease license compliance
> >>
Hi Jonathan,
On 24 June 2018 at 21:47, Jonathan Cameron wrote:
> On Sun, 24 Jun 2018 14:30:09 +0100
> Jonathan Cameron wrote:
>
>> On Sun, 24 Jun 2018 17:13:00 +0800
>> Baolin Wang wrote:
>>
>> > Hi Jonathan,
>> >
>> > On 22 June 2018 at 22:13, Jonathan Cameron
>> > wrote:
>> > > On Thu, 21
Hi Jonathan,
On 24 June 2018 at 21:47, Jonathan Cameron wrote:
> On Sun, 24 Jun 2018 14:30:09 +0100
> Jonathan Cameron wrote:
>
>> On Sun, 24 Jun 2018 17:13:00 +0800
>> Baolin Wang wrote:
>>
>> > Hi Jonathan,
>> >
>> > On 22 June 2018 at 22:13, Jonathan Cameron
>> > wrote:
>> > > On Thu, 21
On (06/24/18 22:33), Colin King wrote:
> The functions zs_page_isolate, zs_page_migrate, zs_page_putback,
> lock_zspage, trylock_zspage and structure zsmalloc_aops are local to
> source and do not need to be in global scope, so make them static.
>
> Cleans up sparse warnings:
> symbol
On (06/24/18 22:33), Colin King wrote:
> The functions zs_page_isolate, zs_page_migrate, zs_page_putback,
> lock_zspage, trylock_zspage and structure zsmalloc_aops are local to
> source and do not need to be in global scope, so make them static.
>
> Cleans up sparse warnings:
> symbol
On (06/22/18 22:06), Tetsuo Handa wrote:
> >
> > Awesome. If you and Fengguang can combine forces and lead the
> > whole thing towards "we couldn't care of pr_cont() less", it
> > would be really huge. Go for it!
>
> Can't we have seq_printf()-like one which flushes automatically upon seeing
On (06/22/18 22:06), Tetsuo Handa wrote:
> >
> > Awesome. If you and Fengguang can combine forces and lead the
> > whole thing towards "we couldn't care of pr_cont() less", it
> > would be really huge. Go for it!
>
> Can't we have seq_printf()-like one which flushes automatically upon seeing
On 06/24/2018 04:39 PM, Matthew Wilcox wrote:
On Sat, Jun 23, 2018 at 09:01:37PM -0700, Guenter Roeck wrote:
Yes, that is much better:
Build reference: next-20180622-1-g023ad92e94da
Building mcf5208evb:m5208:m5208evb_defconfig:initrd ... running passed
Building
On 06/24/2018 04:39 PM, Matthew Wilcox wrote:
On Sat, Jun 23, 2018 at 09:01:37PM -0700, Guenter Roeck wrote:
Yes, that is much better:
Build reference: next-20180622-1-g023ad92e94da
Building mcf5208evb:m5208:m5208evb_defconfig:initrd ... running passed
Building
On Sun, Jun 24, 2018 at 10:44:19AM -0700, Nathan Chancellor wrote:
> On Sun, Jun 24, 2018 at 11:23:47PM +0800, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.9.110 release.
> > There are 39 patches in this series, all will be posted as a response
> > to this
On Sun, Jun 24, 2018 at 10:44:19AM -0700, Nathan Chancellor wrote:
> On Sun, Jun 24, 2018 at 11:23:47PM +0800, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.9.110 release.
> > There are 39 patches in this series, all will be posted as a response
> > to this
A végső értesítés Önnek
Ön elnyerte a 450.000,00 euró (négyszázötvenezer euró) és az e-mail
programot Spanyolország Nemzetközi jótékonysági program "El Gordo Mi
levélben jelezzük ezt a díjat, Batch number: Ref: GP.ES/01091/7/61 .Ticket
79/71/02/23/88.
Vegye fel a kapcsolatot a képviselő
A végső értesítés Önnek
Ön elnyerte a 450.000,00 euró (négyszázötvenezer euró) és az e-mail
programot Spanyolország Nemzetközi jótékonysági program "El Gordo Mi
levélben jelezzük ezt a díjat, Batch number: Ref: GP.ES/01091/7/61 .Ticket
79/71/02/23/88.
Vegye fel a kapcsolatot a képviselő
Should be ok now - It was missing an update that Aurelien and I worked
on for that patch - so I backed that patch out. It was also
suggested that that Kconfig parm and #ifdef be removed since SMB3.11
is strongly recommended to be set (which would have avoided this as
well) and will be added to
Should be ok now - It was missing an update that Aurelien and I worked
on for that patch - so I backed that patch out. It was also
suggested that that Kconfig parm and #ifdef be removed since SMB3.11
is strongly recommended to be set (which would have avoided this as
well) and will be added to
On Sun, Jun 24, 2018 at 08:41:03AM -0700, Joe Perches wrote:
> On Tue, 2018-06-19 at 06:31 -0700, Joe Perches wrote:
> > Greg? Ping?
> >
> > The patches to impi have hit -next and the impi code
> > works differently without this patch.
>
> Greg?
>
> You are listed as the maintainer for this
On Sun, Jun 24, 2018 at 08:41:03AM -0700, Joe Perches wrote:
> On Tue, 2018-06-19 at 06:31 -0700, Joe Perches wrote:
> > Greg? Ping?
> >
> > The patches to impi have hit -next and the impi code
> > works differently without this patch.
>
> Greg?
>
> You are listed as the maintainer for this
On Wed, Jun 20, 2018 at 10:59:08PM -0400, Nicolas Pitre wrote:
> On Thu, 21 Jun 2018, Adam Borowski wrote:
>
> > On Tue, Jun 19, 2018 at 11:34:34AM -0400, Nicolas Pitre wrote:
> > > On Tue, 19 Jun 2018, Adam Borowski wrote:
> > > > Thus, it'd be nice to use the structure you add to implement full
On Wed, Jun 20, 2018 at 10:59:08PM -0400, Nicolas Pitre wrote:
> On Thu, 21 Jun 2018, Adam Borowski wrote:
>
> > On Tue, Jun 19, 2018 at 11:34:34AM -0400, Nicolas Pitre wrote:
> > > On Tue, 19 Jun 2018, Adam Borowski wrote:
> > > > Thus, it'd be nice to use the structure you add to implement full
The Dell laptop I have has an ACPI that sends 0xCB and 0xCC on entering
tablet mode. On exiting tablet mode it sends 0xCA and 0xCD. Based on:
http://www.traby.de/medion/DSDT/dsdt.dsl
https://gist.github.com/jprvita/5737de3cbb670e80973b7d4e51c38ab6
The Dell laptop I have has an ACPI that sends 0xCB and 0xCC on entering
tablet mode. On exiting tablet mode it sends 0xCA and 0xCD. Based on:
http://www.traby.de/medion/DSDT/dsdt.dsl
https://gist.github.com/jprvita/5737de3cbb670e80973b7d4e51c38ab6
Hi,
I'm seeing lots of this type of warning in 4.18-rc2 (maybe even before,
but this is on x86_32/i386, so maybe people aren't checking it so much?):
In file included from ../arch/x86/kernel/process_32.c:40:
../include/linux/syscalls.h:234:18: warning: 'sys_arch_prctl' alias between
functions
Hi,
I'm seeing lots of this type of warning in 4.18-rc2 (maybe even before,
but this is on x86_32/i386, so maybe people aren't checking it so much?):
In file included from ../arch/x86/kernel/process_32.c:40:
../include/linux/syscalls.h:234:18: warning: 'sys_arch_prctl' alias between
functions
On Sat, Jun 23, 2018 at 09:01:37PM -0700, Guenter Roeck wrote:
> Yes, that is much better:
>
> Build reference: next-20180622-1-g023ad92e94da
>
> Building mcf5208evb:m5208:m5208evb_defconfig:initrd ... running passed
> Building q800:m68040:mac_defconfig:initrd ... running passed
>
On Sat, Jun 23, 2018 at 09:01:37PM -0700, Guenter Roeck wrote:
> Yes, that is much better:
>
> Build reference: next-20180622-1-g023ad92e94da
>
> Building mcf5208evb:m5208:m5208evb_defconfig:initrd ... running passed
> Building q800:m68040:mac_defconfig:initrd ... running passed
>
Hi all,
After merging the cifs tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
fs/cifs/smb2ops.c: In function 'smb311_queryfs':
fs/cifs/smb2ops.c:1543:11: error: 'struct cifs_tcon' has no member named
'posix_extensions'
if (!tcon->posix_extensions)
^~
At
Hi all,
After merging the cifs tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
fs/cifs/smb2ops.c: In function 'smb311_queryfs':
fs/cifs/smb2ops.c:1543:11: error: 'struct cifs_tcon' has no member named
'posix_extensions'
if (!tcon->posix_extensions)
^~
At
This is called after the ONFI parameter page checksum is verified
and allows us to override the contents of the parameter page.
Suggested-by: Boris Brezillon
Signed-off-by: Chris Packham
Reviewed-by: Boris Brezillon
---
Changes in v2:
- New
Changes in v3:
- Add doc comment and review from
Some Micron NAND chips have on-die ECC forceably enabled. Detect these
based on chip ID as there seems to be no other way of distinguishing
these chips from those that have optional support for on-die ECC.
Signed-off-by: Chris Packham
Reviewed-by: Boris Brezillon
---
Changes in v4:
- New
Add defines for the ONFI version bits and use them in
nand_flash_detect_onfi().
Signed-off-by: Chris Packham
Reviewed-by: Boris Brezillon
---
Changes in v4:
- New
Changes in v5:
- Add review from Boris
Changes in v6:
- None
drivers/mtd/nand/raw/nand_base.c | 10 +-
This is called after the ONFI parameter page checksum is verified
and allows us to override the contents of the parameter page.
Suggested-by: Boris Brezillon
Signed-off-by: Chris Packham
Reviewed-by: Boris Brezillon
---
Changes in v2:
- New
Changes in v3:
- Add doc comment and review from
Some Micron NAND chips have on-die ECC forceably enabled. Detect these
based on chip ID as there seems to be no other way of distinguishing
these chips from those that have optional support for on-die ECC.
Signed-off-by: Chris Packham
Reviewed-by: Boris Brezillon
---
Changes in v4:
- New
Add defines for the ONFI version bits and use them in
nand_flash_detect_onfi().
Signed-off-by: Chris Packham
Reviewed-by: Boris Brezillon
---
Changes in v4:
- New
Changes in v5:
- Add review from Boris
Changes in v6:
- None
drivers/mtd/nand/raw/nand_base.c | 10 +-
Some Micron NAND chips (MT29F1G08ABAFAWP-ITE:F) report 00 00 for the
revision number field of the ONFI parameter page. Rather than rejecting
these outright assume ONFI version 1.0 if the revision number is 00 00.
Signed-off-by: Chris Packham
Reviewed-by: Boris Brezillon
---
This is now
On Sun, Jun 24, 2018 at 02:31:03PM -0700, Dmitry Torokhov wrote:
> External Email
>
> On Sat, Jun 23, 2018 at 10:35:02AM +0300, Yury Norov wrote:
> > On top of next-20180622 and Andy Shevchenko series:
> > https://lkml.org/lkml/2018/6/18/841
> >
> > The series mentioned above introduces helpers
Some Micron NAND chips (MT29F1G08ABAFAWP-ITE:F) report 00 00 for the
revision number field of the ONFI parameter page. Rather than rejecting
these outright assume ONFI version 1.0 if the revision number is 00 00.
Signed-off-by: Chris Packham
Reviewed-by: Boris Brezillon
---
This is now
On Sun, Jun 24, 2018 at 02:31:03PM -0700, Dmitry Torokhov wrote:
> External Email
>
> On Sat, Jun 23, 2018 at 10:35:02AM +0300, Yury Norov wrote:
> > On top of next-20180622 and Andy Shevchenko series:
> > https://lkml.org/lkml/2018/6/18/841
> >
> > The series mentioned above introduces helpers
>From the controllers point of view this is the same as no or
software only ECC.
Signed-off-by: Chris Packham
Reviewed-by: Boris Brezillon
---
Changes in v2:
- New
Changes in v3:
- Add review from Boris
Changes in v4:
- None
Changes in v5:
- None
Changes in v6:
- None
>From the controllers point of view this is the same as no or
software only ECC.
Signed-off-by: Chris Packham
Reviewed-by: Boris Brezillon
---
Changes in v2:
- New
Changes in v3:
- Add review from Boris
Changes in v4:
- None
Changes in v5:
- None
Changes in v6:
- None
Hi,
I'm looking at adding support for the Micron MT29F1G08ABAFAWP-ITE:F chip
to one of our boards which uses the Marvell NFCv2 controller.
This particular chip is a bit odd in that the datasheet states support
for ONFI 1.0 but the revision number field is 00 00. It also is marked
ABAFA but
Hi,
I'm looking at adding support for the Micron MT29F1G08ABAFAWP-ITE:F chip
to one of our boards which uses the Marvell NFCv2 controller.
This particular chip is a bit odd in that the datasheet states support
for ONFI 1.0 but the revision number field is 00 00. It also is marked
ABAFA but
Micron MT29F1G08ABAFAWP-ITE:F supports an on-die ECC with 8 bits
per 512 bytes. Add support for this combination.
Signed-off-by: Chris Packham
Reviewed-by: Boris Brezillon
---
Changes in v2:
- New
Changes in v3:
- Handle reporting of corrected errors that don't require a rewrite, expand
Micron MT29F1G08ABAFAWP-ITE:F supports an on-die ECC with 8 bits
per 512 bytes. Add support for this combination.
Signed-off-by: Chris Packham
Reviewed-by: Boris Brezillon
---
Changes in v2:
- New
Changes in v3:
- Handle reporting of corrected errors that don't require a rewrite, expand
Instead of open-coding the loop, let's use canned macro.
Also make sure we are not leaking "cpus" node reference.
Signed-off-by: Dmitry Torokhov
---
arch/sh/boards/of-generic.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/sh/boards/of-generic.c
Instead of open-coding the loop, let's use canned macro.
Also make sure we are not leaking "cpus" node reference.
Signed-off-by: Dmitry Torokhov
---
arch/sh/boards/of-generic.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/sh/boards/of-generic.c
1 - 100 of 840 matches
Mail list logo
