Re: [PATCH] Staging: bcm2835-audio: bcm2835_ctl.c: Fixed a comment coding style issue

On Sat, May 20, 2017 at 01:00:17AM +0530, srishti sharma wrote: > Was the format of this patch acceptable ,the "from" matches the > "signed-off-by" right , so this should be correct , were there any > errors in this ? Should I resend it ? > > Regards, > Srishti > You should capitalize your name

Re: [PATCH] Staging: bcm2835-audio: bcm2835_ctl.c: Fixed a comment coding style issue

On Sat, May 20, 2017 at 01:00:17AM +0530, srishti sharma wrote: > Was the format of this patch acceptable ,the "from" matches the > "signed-off-by" right , so this should be correct , were there any > errors in this ? Should I resend it ? > > Regards, > Srishti > You should capitalize your name

Re: [RFC PATCH v2 08/17] cgroup: Move debug cgroup to its own file

On 05/19/2017 03:21 PM, Tejun Heo wrote: > Hello, Waiman. > > On Thu, May 18, 2017 at 11:52:18AM -0400, Waiman Long wrote: >> The controller name is "debug" and so it is obvious what this controller >> is for. However, the config prompt "Example controller" is indeed vague > Yeah but it also shows

Re: [RFC PATCH v2 08/17] cgroup: Move debug cgroup to its own file

On 05/19/2017 03:21 PM, Tejun Heo wrote: > Hello, Waiman. > > On Thu, May 18, 2017 at 11:52:18AM -0400, Waiman Long wrote: >> The controller name is "debug" and so it is obvious what this controller >> is for. However, the config prompt "Example controller" is indeed vague > Yeah but it also shows

Re: [PATCH 4/6] arch/sparc: Enable queued rwlocks for SPARC

On Fri, May 19, 2017 at 03:15:53PM -0400, David Miller wrote: > However, I don't see what any of this has to do with the feedback > I was giving the patch author :-) Uhm,... I think my morning brain read things like you having doubts about making it sparc64 only. But I could have easily misread

Re: [PATCH 4/6] arch/sparc: Enable queued rwlocks for SPARC

On Fri, May 19, 2017 at 03:15:53PM -0400, David Miller wrote: > However, I don't see what any of this has to do with the feedback > I was giving the patch author :-) Uhm,... I think my morning brain read things like you having doubts about making it sparc64 only. But I could have easily misread

Re: [PATCH] Staging: bcm2835-audio: bcm2835_ctl.c: Fixed a comment coding style issue

Was the format of this patch acceptable ,the "from" matches the "signed-off-by" right , so this should be correct , were there any errors in this ? Should I resend it ? Regards, Srishti On Thu, May 18, 2017 at 7:28 PM, Greg KH wrote: > On Thu, May 18, 2017 at

Re: [PATCH] Staging: bcm2835-audio: bcm2835_ctl.c: Fixed a comment coding style issue

Was the format of this patch acceptable ,the "from" matches the "signed-off-by" right , so this should be correct , were there any errors in this ? Should I resend it ? Regards, Srishti On Thu, May 18, 2017 at 7:28 PM, Greg KH wrote: > On Thu, May 18, 2017 at 04:20:15PM +0530, srishti wrote: >>

Re: next-20170515: WARNING: CPU: 0 PID: 1 at arch/x86/mm/dump_pagetables.c:236 note_page+0x630/0x7e0

On Fri, May 19, 2017 at 12:18 PM, Andy Lutomirski wrote: > On Fri, May 19, 2017 at 12:16 PM, Kees Cook wrote: >> On Fri, May 19, 2017 at 11:27 AM, Andy Lutomirski wrote: >>> One thing I've pondered: can we make some debugging mode

Re: next-20170515: WARNING: CPU: 0 PID: 1 at arch/x86/mm/dump_pagetables.c:236 note_page+0x630/0x7e0

On Fri, May 19, 2017 at 12:18 PM, Andy Lutomirski wrote: > On Fri, May 19, 2017 at 12:16 PM, Kees Cook wrote: >> On Fri, May 19, 2017 at 11:27 AM, Andy Lutomirski wrote: >>> One thing I've pondered: can we make some debugging mode (kmemleak, >>> perhaps?) check that freed memory is RW at the

Re: [PATCH net] bonding: fix randomly populated arp target array

On Fri, May 19, 2017 at 02:46:46PM -0400, Jarod Wilson wrote: > In commit dc9c4d0fe023, the arp_target array moved from a static global > to a local variable. By the nature of static globals, the array used to > be initialized to all 0. At present, it's full of random data, which > that gets

Re: [PATCH net] bonding: fix randomly populated arp target array

On Fri, May 19, 2017 at 02:46:46PM -0400, Jarod Wilson wrote: > In commit dc9c4d0fe023, the arp_target array moved from a static global > to a local variable. By the nature of static globals, the array used to > be initialized to all 0. At present, it's full of random data, which > that gets

Re: [RFC PATCH v2 08/17] cgroup: Move debug cgroup to its own file

Hello, Waiman. On Thu, May 18, 2017 at 11:52:18AM -0400, Waiman Long wrote: > The controller name is "debug" and so it is obvious what this controller > is for. However, the config prompt "Example controller" is indeed vague Yeah but it also shows up as an integral part of stable interface

Re: [RFC PATCH v2 08/17] cgroup: Move debug cgroup to its own file

Hello, Waiman. On Thu, May 18, 2017 at 11:52:18AM -0400, Waiman Long wrote: > The controller name is "debug" and so it is obvious what this controller > is for. However, the config prompt "Example controller" is indeed vague Yeah but it also shows up as an integral part of stable interface

Re: [PATCH v4 15/27] fs: retrofit old error reporting API onto new infrastructure

On Mon, 2017-05-15 at 12:42 +0200, Jan Kara wrote: > On Tue 09-05-17 11:49:18, Jeff Layton wrote: > > Now that we have a better way to store and report errors that occur > > during writeback, we need to convert the existing codebase to use it. We > > could just adapt all of the filesystem code and

Re: [PATCH v4 15/27] fs: retrofit old error reporting API onto new infrastructure

On Mon, 2017-05-15 at 12:42 +0200, Jan Kara wrote: > On Tue 09-05-17 11:49:18, Jeff Layton wrote: > > Now that we have a better way to store and report errors that occur > > during writeback, we need to convert the existing codebase to use it. We > > could just adapt all of the filesystem code and

Re: [PATCH] Btrfs: work around maybe-uninitialized warning

On Fri, May 19, 2017 at 8:10 PM, Liu Bo wrote: > On Thu, May 18, 2017 at 03:33:29PM +0200, Arnd Bergmann wrote: >> A rewrite of btrfs_submit_direct_hook appears to have introduced a warning: >> >> fs/btrfs/inode.c: In function 'btrfs_submit_direct_hook': >>

Re: [PATCH] Btrfs: work around maybe-uninitialized warning

On Fri, May 19, 2017 at 8:10 PM, Liu Bo wrote: > On Thu, May 18, 2017 at 03:33:29PM +0200, Arnd Bergmann wrote: >> A rewrite of btrfs_submit_direct_hook appears to have introduced a warning: >> >> fs/btrfs/inode.c: In function 'btrfs_submit_direct_hook': >> fs/btrfs/inode.c:8467:14: error: 'bio'

Re: next-20170515: WARNING: CPU: 0 PID: 1 at arch/x86/mm/dump_pagetables.c:236 note_page+0x630/0x7e0

On Fri, May 19, 2017 at 12:16 PM, Kees Cook wrote: > On Fri, May 19, 2017 at 11:27 AM, Andy Lutomirski wrote: >> One thing I've pondered: can we make some debugging mode (kmemleak, >> perhaps?) check that freed memory is RW at the time it's freed? I >>

Re: next-20170515: WARNING: CPU: 0 PID: 1 at arch/x86/mm/dump_pagetables.c:236 note_page+0x630/0x7e0

On Fri, May 19, 2017 at 12:16 PM, Kees Cook wrote: > On Fri, May 19, 2017 at 11:27 AM, Andy Lutomirski wrote: >> One thing I've pondered: can we make some debugging mode (kmemleak, >> perhaps?) check that freed memory is RW at the time it's freed? I >> once wrote some buggy code that freed an R

Re: next-20170515: WARNING: CPU: 0 PID: 1 at arch/x86/mm/dump_pagetables.c:236 note_page+0x630/0x7e0

On Fri, May 19, 2017 at 11:27 AM, Andy Lutomirski wrote: > One thing I've pondered: can we make some debugging mode (kmemleak, > perhaps?) check that freed memory is RW at the time it's freed? I > once wrote some buggy code that freed an R page and caused an OOPS > much later,

Re: next-20170515: WARNING: CPU: 0 PID: 1 at arch/x86/mm/dump_pagetables.c:236 note_page+0x630/0x7e0

On Fri, May 19, 2017 at 11:27 AM, Andy Lutomirski wrote: > One thing I've pondered: can we make some debugging mode (kmemleak, > perhaps?) check that freed memory is RW at the time it's freed? I > once wrote some buggy code that freed an R page and caused an OOPS > much later, and this bug here

Re: [PATCH 4/6] arch/sparc: Enable queued rwlocks for SPARC

From: Peter Zijlstra Date: Fri, 19 May 2017 11:03:02 +0200 > On Thu, May 18, 2017 at 10:31:13PM -0400, David Miller wrote: >> From: Babu Moger >> Date: Thu, 18 May 2017 18:36:08 -0600 >> >> > @@ -82,6 +82,7 @@ config SPARC64 >> >select

Re: [PATCH 4/6] arch/sparc: Enable queued rwlocks for SPARC

From: Peter Zijlstra Date: Fri, 19 May 2017 11:03:02 +0200 > On Thu, May 18, 2017 at 10:31:13PM -0400, David Miller wrote: >> From: Babu Moger >> Date: Thu, 18 May 2017 18:36:08 -0600 >> >> > @@ -82,6 +82,7 @@ config SPARC64 >> >select HAVE_ARCH_AUDITSYSCALL >> >select

[PATCH v8 1/5] firmware: add extensible driver data params

As the firmware API evolves we keep extending functions with more arguments. Stop this nonsense by proving an extensible data structure which can be used to represent both user parameters and private internal parameters. We introduce 3 data structures: o struct driver_data_req_params - used

[PATCH v8 1/5] firmware: add extensible driver data params

As the firmware API evolves we keep extending functions with more arguments. Stop this nonsense by proving an extensible data structure which can be used to represent both user parameters and private internal parameters. We introduce 3 data structures: o struct driver_data_req_params - used

[PATCH v8 3/5] test: add new driver_data load tester

This adds a load tester driver test_driver_data a for the new extensible driver_data loader API, part of firmware_class. This test driver enables you to build your tests in userspace by exposing knobs of the exported API to userspace and enables a trigger action to mimic a one time use of the

[PATCH v8 5/5] iwlwifi: convert to use driver data API

The driver data API provides support for looking for firmware from a specific set of API ranges, so just use that. Since we free the firmware on the callback immediately after consuming it, this also takes avantage of that feature. Signed-off-by: Luis R. Rodriguez ---

[PATCH v8 3/5] test: add new driver_data load tester

This adds a load tester driver test_driver_data a for the new extensible driver_data loader API, part of firmware_class. This test driver enables you to build your tests in userspace by exposing knobs of the exported API to userspace and enables a trigger action to mimic a one time use of the

[PATCH v8 5/5] iwlwifi: convert to use driver data API

The driver data API provides support for looking for firmware from a specific set of API ranges, so just use that. Since we free the firmware on the callback immediately after consuming it, this also takes avantage of that feature. Signed-off-by: Luis R. Rodriguez ---

[PATCH v8 0/5] firmware: add driver data API

k lock changes I had submitted earlier this month [3], and those remain without any noted issues. As usual, all pending changes for this series are available on my linux-next tree on the 20170519-driver-data branch [4], this series was rebased on next-20170519. Please let me know if there are any is

[PATCH v8 2/5] firmware: add extensible driver data API

The firmware API does not scale well: when new features are added we either add a new exported symbol or extend the arguments of existing routines. For the later case this means we need to traverse the kernel with a slew of collateral evolutions to adjust old driver users. The firmware API is also

[PATCH v8 0/5] firmware: add driver data API

k lock changes I had submitted earlier this month [3], and those remain without any noted issues. As usual, all pending changes for this series are available on my linux-next tree on the 20170519-driver-data branch [4], this series was rebased on next-20170519. Please let me know if there are any is

[PATCH v8 2/5] firmware: add extensible driver data API

The firmware API does not scale well: when new features are added we either add a new exported symbol or extend the arguments of existing routines. For the later case this means we need to traverse the kernel with a slew of collateral evolutions to adjust old driver users. The firmware API is also

[PATCH v8 4/5] firmware: document the extensible driver data API

This documents the driver data API. Signed-off-by: Luis R. Rodriguez --- Documentation/driver-api/firmware/driver_data.rst | 167 + Documentation/driver-api/firmware/index.rst| 1 + Documentation/driver-api/firmware/introduction.rst | 16 ++

[PATCH v8 4/5] firmware: document the extensible driver data API

This documents the driver data API. Signed-off-by: Luis R. Rodriguez --- Documentation/driver-api/firmware/driver_data.rst | 167 + Documentation/driver-api/firmware/index.rst| 1 + Documentation/driver-api/firmware/introduction.rst | 16 ++

Re: [4.12 regression] Thinkpad X250 Touchpad and Trackpoint not recognized anymore; commit e839ffa: "Input: synaptics - add support for Intertouch devices"

On May 19, 2017 11:46:16 AM PDT, Pascal Wichmann wrote: >Hello, > >using the latest 4.12-rc1 kernel, the trackpoint and touchpad of my >Thinkpad X250 are not recognized. > >This is caused by commit >e839ffa Input: synaptics - add support for Intertouch devices > > >The

Re: [4.12 regression] Thinkpad X250 Touchpad and Trackpoint not recognized anymore; commit e839ffa: "Input: synaptics - add support for Intertouch devices"

On May 19, 2017 11:46:16 AM PDT, Pascal Wichmann wrote: >Hello, > >using the latest 4.12-rc1 kernel, the trackpoint and touchpad of my >Thinkpad X250 are not recognized. > >This is caused by commit >e839ffa Input: synaptics - add support for Intertouch devices > > >The specific problem seems to

Re: Use case for TASKS_RCU

On Fri, May 19, 2017 at 10:23:31AM -0400, Steven Rostedt wrote: > On Fri, 19 May 2017 10:04:21 -0400 > Steven Rostedt wrote: > > > On Fri, 19 May 2017 06:35:50 -0700 > > "Paul E. McKenney" wrote: > > > > > Simpler would be better! > > > > > >

Re: Use case for TASKS_RCU

On Fri, May 19, 2017 at 10:23:31AM -0400, Steven Rostedt wrote: > On Fri, 19 May 2017 10:04:21 -0400 > Steven Rostedt wrote: > > > On Fri, 19 May 2017 06:35:50 -0700 > > "Paul E. McKenney" wrote: > > > > > Simpler would be better! > > > > > > However, is it really guaranteed that one

Darlehen angebot 3 %

Sehr geehrte Damen und Herren, Haben Sie Interesse über einer finanziellen Darlehen zu 3%? kontaktieren Sie mich für mehr Details und Bedingungen. ich kann all jenen helfen, wer ein Darlehen benötigen. Ich kann Ihnen biete ein darlehen in hohe von 10.000.000 EUR Meine mail:

Darlehen angebot 3 %

Sehr geehrte Damen und Herren, Haben Sie Interesse über einer finanziellen Darlehen zu 3%? kontaktieren Sie mich für mehr Details und Bedingungen. ich kann all jenen helfen, wer ein Darlehen benötigen. Ich kann Ihnen biete ein darlehen in hohe von 10.000.000 EUR Meine mail:

[4.12 regression] Thinkpad X250 Touchpad and Trackpoint not recognized anymore; commit e839ffa: "Input: synaptics - add support for Intertouch devices"

Hello, using the latest 4.12-rc1 kernel, the trackpoint and touchpad of my Thinkpad X250 are not recognized. This is caused by commit e839ffa Input: synaptics - add support for Intertouch devices The specific problem seems to be the detection of whether to use synaptics_intertouch for the

[4.12 regression] Thinkpad X250 Touchpad and Trackpoint not recognized anymore; commit e839ffa: "Input: synaptics - add support for Intertouch devices"

Hello, using the latest 4.12-rc1 kernel, the trackpoint and touchpad of my Thinkpad X250 are not recognized. This is caused by commit e839ffa Input: synaptics - add support for Intertouch devices The specific problem seems to be the detection of whether to use synaptics_intertouch for the

[PATCH net] bonding: fix randomly populated arp target array

In commit dc9c4d0fe023, the arp_target array moved from a static global to a local variable. By the nature of static globals, the array used to be initialized to all 0. At present, it's full of random data, which that gets interpreted as arp_target values, when none have actually been specified.

[PATCH net] bonding: fix randomly populated arp target array

In commit dc9c4d0fe023, the arp_target array moved from a static global to a local variable. By the nature of static globals, the array used to be initialized to all 0. At present, it's full of random data, which that gets interpreted as arp_target values, when none have actually been specified.

[GIT PULL] KVM fixes for v4.12-rc2

Linus, The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6: Linux 4.12-rc1 (2017-05-13 13:19:49 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus for you to fetch changes up to

[GIT PULL] KVM fixes for v4.12-rc2

Linus, The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6: Linux 4.12-rc1 (2017-05-13 13:19:49 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus for you to fetch changes up to

Re: [PATCH] selinux: Remove redundant check for unknown labeling behavior

On Fri, May 19, 2017 at 1:09 PM, Matthias Kaehlcke wrote: > The check is already performed in ocontext_read() when the policy is > loaded. Removing the array also fixes the following warning when > building with clang: > > security/selinux/hooks.c:338:20: error: variable

Re: [PATCH] selinux: Remove redundant check for unknown labeling behavior

On Fri, May 19, 2017 at 1:09 PM, Matthias Kaehlcke wrote: > The check is already performed in ocontext_read() when the policy is > loaded. Removing the array also fixes the following warning when > building with clang: > > security/selinux/hooks.c:338:20: error: variable 'labeling_behaviors' >

Re: [PATCH v3 00/11] Broadcom Stingray SOC Initial Support

On 05/16/2017 09:24 PM, Anup Patel wrote: > On Wed, May 17, 2017 at 12:23 AM, Olof Johansson wrote: >> Hi, >> >> >> >> On Tue, May 16, 2017 at 4:30 AM, Anup Patel wrote: >>> This patchset adds initial support of Broadcom Stingray SOC >>> by reusing

Re: [PATCH v3 00/11] Broadcom Stingray SOC Initial Support

On 05/16/2017 09:24 PM, Anup Patel wrote: > On Wed, May 17, 2017 at 12:23 AM, Olof Johansson wrote: >> Hi, >> >> >> >> On Tue, May 16, 2017 at 4:30 AM, Anup Patel wrote: >>> This patchset adds initial support of Broadcom Stingray SOC >>> by reusing existing Broadcom iProc device drivers. >>> >>>

Re: [PATCH v3 2/3] thermal: broadcom: ns-thermal: default on iProc SoCs

On 04/28/2017 01:11 PM, Jon Mason wrote: > Tweak the Kconfig description to mention support for NSP and make the > default on for iProc based platforms. > > Signed-off-by: Jon Mason Zhang, Eduardo, please apply, the Kconfig and DTS changes have been queued for 4.13 in my

Re: [PATCH v3 2/3] thermal: broadcom: ns-thermal: default on iProc SoCs

On 04/28/2017 01:11 PM, Jon Mason wrote: > Tweak the Kconfig description to mention support for NSP and make the > default on for iProc based platforms. > > Signed-off-by: Jon Mason Zhang, Eduardo, please apply, the Kconfig and DTS changes have been queued for 4.13 in my ARM-SoC pull request

Re: [PATCH v6 3/5] test: add new driver_data load tester

On Wed, May 17, 2017 at 05:45:22PM -0500, Li, Yi wrote: > hi Luis > > > On 5/11/2017 12:11 PM, Luis R. Rodriguez wrote: > > On Thu, May 11, 2017 at 07:46:27PM +0900, AKASHI Takahiro wrote: > > > Luis, > > > > > > On Fri, Apr 28, 2017 at 03:45:35AM +0200, Luis R. Rodriguez wrote: > > > > > > +To

Re: [PATCH v6 3/5] test: add new driver_data load tester

On Wed, May 17, 2017 at 05:45:22PM -0500, Li, Yi wrote: > hi Luis > > > On 5/11/2017 12:11 PM, Luis R. Rodriguez wrote: > > On Thu, May 11, 2017 at 07:46:27PM +0900, AKASHI Takahiro wrote: > > > Luis, > > > > > > On Fri, Apr 28, 2017 at 03:45:35AM +0200, Luis R. Rodriguez wrote: > > > > > > +To

Re: [PATCH v3 1/3] ARM: BCM: Enable thermal support for NSP SoCs

On 04/28/2017 01:11 PM, Jon Mason wrote: > Change the Northstar Plus Kconfig to select THERMAL and THERMAL_OF, > which allows the ns-thermal driver to be selected via menuconfig. > > Signed-off-by: Jon Mason Applied, thanks Jon -- Florian

Re: [PATCH v3 1/3] ARM: BCM: Enable thermal support for NSP SoCs

On 04/28/2017 01:11 PM, Jon Mason wrote: > Change the Northstar Plus Kconfig to select THERMAL and THERMAL_OF, > which allows the ns-thermal driver to be selected via menuconfig. > > Signed-off-by: Jon Mason Applied, thanks Jon -- Florian

Re: [PATCH v3 3/3] ARM: dts: NSP: Add Thermal Support

On 04/28/2017 01:11 PM, Jon Mason wrote: > Add thermal support via the ns-thermal driver and create a single > thermal zone for the entire SoC. > > Signed-off-by: Jon Mason > Acked-by: Eduardo Valentin Applied. thanks Jon -- Florian

Re: [PATCH v3 3/3] ARM: dts: NSP: Add Thermal Support

On 04/28/2017 01:11 PM, Jon Mason wrote: > Add thermal support via the ns-thermal driver and create a single > thermal zone for the entire SoC. > > Signed-off-by: Jon Mason > Acked-by: Eduardo Valentin Applied. thanks Jon -- Florian

Re: git merges of tags

On Thu, May 18, 2017 at 4:23 PM, Stephen Rothwell wrote: > > Just a reminder that if you are merging Linus' tree (or any tree > really) via a tag, git was changed some time ago so that merging a tag > will not do a fast forward (there is a good reason for this - I just >

Re: git merges of tags

On Thu, May 18, 2017 at 4:23 PM, Stephen Rothwell wrote: > > Just a reminder that if you are merging Linus' tree (or any tree > really) via a tag, git was changed some time ago so that merging a tag > will not do a fast forward (there is a good reason for this - I just > can't recall it ATM).

Re: [RFC PATCH 02/11] drm: sun4i: add support for H3 mixers

On Thu, May 18, 2017 at 12:43:45AM +0800, Icenowy Zheng wrote: > From: Icenowy Zheng > > Allwinner H3 SoC has two mixers, one has 1 VI channel and 3 UI channels, > and the other has 1 VI and 1 UI. > > Add support for these two variants. > > Signed-off-by: Icenowy Zheng

Re: [RFC PATCH 02/11] drm: sun4i: add support for H3 mixers

On Thu, May 18, 2017 at 12:43:45AM +0800, Icenowy Zheng wrote: > From: Icenowy Zheng > > Allwinner H3 SoC has two mixers, one has 1 VI channel and 3 UI channels, > and the other has 1 VI and 1 UI. > > Add support for these two variants. > > Signed-off-by: Icenowy Zheng > --- >

[PATCH] efi-pstore: Fix write/erase id tracking

Prior to the pstore interface refactoring, the "id" generated during a backend pstore_write() was only retained by the internal pstore inode tracking list. Additionally the "part" was ignored, so EFI would encode this in the id. This corrects the misunderstandings and correctly sets "id" during

Re: next-20170515: WARNING: CPU: 0 PID: 1 at arch/x86/mm/dump_pagetables.c:236 note_page+0x630/0x7e0

On Fri, May 19, 2017 at 10:35 AM, Catalin Marinas wrote: > On Fri, May 19, 2017 at 05:40:16PM +0200, Luis R. Rodriguez wrote: >> If the following is a legit forced way to get query the kernel to ask it >> who owns a page then perhaps this technique can be used in the

[PATCH] efi-pstore: Fix write/erase id tracking

Prior to the pstore interface refactoring, the "id" generated during a backend pstore_write() was only retained by the internal pstore inode tracking list. Additionally the "part" was ignored, so EFI would encode this in the id. This corrects the misunderstandings and correctly sets "id" during

Re: next-20170515: WARNING: CPU: 0 PID: 1 at arch/x86/mm/dump_pagetables.c:236 note_page+0x630/0x7e0

On Fri, May 19, 2017 at 10:35 AM, Catalin Marinas wrote: > On Fri, May 19, 2017 at 05:40:16PM +0200, Luis R. Rodriguez wrote: >> If the following is a legit forced way to get query the kernel to ask it >> who owns a page then perhaps this technique can be used in the future to >> figure out who

[PATCH v2] zlib: Mark get_unaligned16() as __maybe_unused

The function is not used with all configurations. Adding the attribute fixes the following warning when building with clang and CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y: lib/zlib_inflate/inffast.c:31:1: error: unused function 'get_unaligned16' [-Werror,-Wunused-function] get_unaligned16(const

[PATCH v2] zlib: Mark get_unaligned16() as __maybe_unused

The function is not used with all configurations. Adding the attribute fixes the following warning when building with clang and CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y: lib/zlib_inflate/inffast.c:31:1: error: unused function 'get_unaligned16' [-Werror,-Wunused-function] get_unaligned16(const

Re: [linux-sunxi] Re: [RFC PATCH 10/11] ARM: sun8i: h3: add display engine pipeline for TVE

于 2017年5月20日 GMT+08:00 上午2:06:16, Maxime Ripard 写到: >On Thu, May 18, 2017 at 12:43:53AM +0800, Icenowy Zheng wrote: >> As we have already the support for the TV encoder on Allwinner H3, >add >> the display engine pipeline device tree nodes to its DTSI file. >>

Re: [linux-sunxi] Re: [RFC PATCH 10/11] ARM: sun8i: h3: add display engine pipeline for TVE

于 2017年5月20日 GMT+08:00 上午2:06:16, Maxime Ripard 写到: >On Thu, May 18, 2017 at 12:43:53AM +0800, Icenowy Zheng wrote: >> As we have already the support for the TV encoder on Allwinner H3, >add >> the display engine pipeline device tree nodes to its DTSI file. >> >> The H5 pipeline has some

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

On Fri, May 19, 2017 at 7:18 AM, Keith Busch wrote: > On Thu, May 18, 2017 at 11:35:05PM -0700, Christoph Hellwig wrote: >> On Thu, May 18, 2017 at 06:13:55PM -0700, Andy Lutomirski wrote: >> > a) Leave the Dell quirk in place until someone from Dell or Samsung >> > figures

Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC

Hi, Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng napisal(a): > 于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard 写到: > >On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng wrote: > >> Allwinner H3 features a TV encoder similar to the one in

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

On Fri, May 19, 2017 at 7:18 AM, Keith Busch wrote: > On Thu, May 18, 2017 at 11:35:05PM -0700, Christoph Hellwig wrote: >> On Thu, May 18, 2017 at 06:13:55PM -0700, Andy Lutomirski wrote: >> > a) Leave the Dell quirk in place until someone from Dell or Samsung >> > figures out what's actually

Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC

Hi, Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng napisal(a): > 于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard 写到: > >On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng wrote: > >> Allwinner H3 features a TV encoder similar to the one in earlier > > > >SoCs, > > > >> but with

Re: [PATCH][drm-next] drm/pl111: make structure pl111_display_funcs static

Jani Nikula writes: > On Fri, 19 May 2017, Colin King wrote: >> From: Colin Ian King >> >> structure pl111_display_funcs can be made static as it does not need to be >> in global scope. Fixes sparse warning: >>

Re: [PATCH][drm-next] drm/pl111: make structure pl111_display_funcs static

Jani Nikula writes: > On Fri, 19 May 2017, Colin King wrote: >> From: Colin Ian King >> >> structure pl111_display_funcs can be made static as it does not need to be >> in global scope. Fixes sparse warning: >> >> "warning: symbol 'pl111_display_funcs' was not declared. Should it >> be

Re: [PATCH v2] drm/pl111: Register the clock divider and use it.

Stephen Boyd writes: > On 05/08, Eric Anholt wrote: >> This is required for the panel to work on bcm911360, where CLCDCLK is >> the fixed 200Mhz AXI41 clock. The rate set is still passed up to the >> CLCDCLK, for platforms that have a settable rate on that one. >> >> v2:

Re: [PATCH v2] drm/pl111: Register the clock divider and use it.

Stephen Boyd writes: > On 05/08, Eric Anholt wrote: >> This is required for the panel to work on bcm911360, where CLCDCLK is >> the fixed 200Mhz AXI41 clock. The rate set is still passed up to the >> CLCDCLK, for platforms that have a settable rate on that one. >> >> v2: Set SET_RATE_PARENT

Re: [PATCH] drm/pl111: Add a debugfs node to dump our registers.

Eric Engestrom writes: > On Wednesday, 2017-05-17 17:56:40 -0700, Eric Anholt wrote: >> While debugging an X11 display failure, I wanted to see where we were >> actually scanning out from. This is probably generally useful to >> others that might be working on this

Re: [PATCH] drm/pl111: Add a debugfs node to dump our registers.

Eric Engestrom writes: > On Wednesday, 2017-05-17 17:56:40 -0700, Eric Anholt wrote: >> While debugging an X11 display failure, I wanted to see where we were >> actually scanning out from. This is probably generally useful to >> others that might be working on this device. >> >> Signed-off-by:

Re: [GIT PULL] bcm2835 DT fixes for 4.12

On 05/16/2017 03:19 PM, Eric Anholt wrote: > Hi Florian, > > The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6: > > Linux 4.12-rc1 (2017-05-13 13:19:49 -0700) > > are available in the git repository at: > > git://github.com/anholt/linux

Re: [GIT PULL] bcm2835 DT fixes for 4.12

On 05/16/2017 03:19 PM, Eric Anholt wrote: > Hi Florian, > > The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6: > > Linux 4.12-rc1 (2017-05-13 13:19:49 -0700) > > are available in the git repository at: > > git://github.com/anholt/linux

Re: [linux-sunxi] Re: [RFC PATCH 02/11] drm: sun4i: add support for H3 mixers

Hi! Dne petek, 19. maj 2017 ob 19:49:58 CEST je Icenowy Zheng napisal(a): > 于 2017年5月20日 GMT+08:00 上午1:47:29, Maxime Ripard 写到: > >On Thu, May 18, 2017 at 12:43:45AM +0800, Icenowy Zheng wrote: > >> From: Icenowy Zheng > >> > >> Allwinner H3

Re: [linux-sunxi] Re: [RFC PATCH 02/11] drm: sun4i: add support for H3 mixers

Hi! Dne petek, 19. maj 2017 ob 19:49:58 CEST je Icenowy Zheng napisal(a): > 于 2017年5月20日 GMT+08:00 上午1:47:29, Maxime Ripard 写到: > >On Thu, May 18, 2017 at 12:43:45AM +0800, Icenowy Zheng wrote: > >> From: Icenowy Zheng > >> > >> Allwinner H3 SoC has two mixers, one has 1 VI channel and 3 UI >

Re: [PATCH] Btrfs: work around maybe-uninitialized warning

On Thu, May 18, 2017 at 03:33:29PM +0200, Arnd Bergmann wrote: > A rewrite of btrfs_submit_direct_hook appears to have introduced a warning: > > fs/btrfs/inode.c: In function 'btrfs_submit_direct_hook': > fs/btrfs/inode.c:8467:14: error: 'bio' may be used uninitialized in this > function

Re: [PATCH] Btrfs: work around maybe-uninitialized warning

On Thu, May 18, 2017 at 03:33:29PM +0200, Arnd Bergmann wrote: > A rewrite of btrfs_submit_direct_hook appears to have introduced a warning: > > fs/btrfs/inode.c: In function 'btrfs_submit_direct_hook': > fs/btrfs/inode.c:8467:14: error: 'bio' may be used uninitialized in this > function

Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC

于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard 写到: >On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng wrote: >> Allwinner H3 features a TV encoder similar to the one in earlier >SoCs, >> but with some different points about clocks: >> - It has a mod

[PATCH 3/4] ueagle-atm: Delete unnecessary return statements in two functions

From: Markus Elfring Date: Fri, 19 May 2017 19:22:12 +0200 The script "checkpatch.pl" pointed information out like the following. WARNING: void function return statements are not generally useful Thus remove such a statement in the affected functions.

Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC

于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard 写到: >On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng wrote: >> Allwinner H3 features a TV encoder similar to the one in earlier >SoCs, >> but with some different points about clocks: >> - It has a mod clock and a bus clock. >> - The mod

[PATCH 3/4] ueagle-atm: Delete unnecessary return statements in two functions

From: Markus Elfring Date: Fri, 19 May 2017 19:22:12 +0200 The script "checkpatch.pl" pointed information out like the following. WARNING: void function return statements are not generally useful Thus remove such a statement in the affected functions. Signed-off-by: Markus Elfring ---

Re: [PATCH] kconfig: always use user input symbols

Hi Geert, On Fri, May 19, 2017 at 07:29:05PM +0200, Geert Uytterhoeven wrote: > Hi Tycho, > > On Fri, May 19, 2017 at 5:08 PM, Tycho Andersen wrote: > > ...regardless of visibility. > > > > When a symbol that is not visible by default (e.g. PNFS_FLEXFILE_LAYOUT) > > has a

Re: [PATCH] kconfig: always use user input symbols

Hi Geert, On Fri, May 19, 2017 at 07:29:05PM +0200, Geert Uytterhoeven wrote: > Hi Tycho, > > On Fri, May 19, 2017 at 5:08 PM, Tycho Andersen wrote: > > ...regardless of visibility. > > > > When a symbol that is not visible by default (e.g. PNFS_FLEXFILE_LAYOUT) > > has a default value, it is

Re: [RFC PATCH 01/11] dt-bindings: update the binding for Allwinner H3 TVE support

于 2017年5月20日 GMT+08:00 上午2:02:15, Maxime Ripard 写到: >On Thu, May 18, 2017 at 12:43:44AM +0800, Icenowy Zheng wrote: >> -On SoCs other than the A33 and V3s, there is one more clock >required: >> +For the following compatibles: >> + * allwinner,sun5i-a13-tcon

Re: [RFC PATCH 01/11] dt-bindings: update the binding for Allwinner H3 TVE support

于 2017年5月20日 GMT+08:00 上午2:02:15, Maxime Ripard 写到: >On Thu, May 18, 2017 at 12:43:44AM +0800, Icenowy Zheng wrote: >> -On SoCs other than the A33 and V3s, there is one more clock >required: >> +For the following compatibles: >> + * allwinner,sun5i-a13-tcon >> + * allwinner,sun6i-a31-tcon

Re: [RFC PATCH 10/11] ARM: sun8i: h3: add display engine pipeline for TVE

On Thu, May 18, 2017 at 12:43:53AM +0800, Icenowy Zheng wrote: > As we have already the support for the TV encoder on Allwinner H3, add > the display engine pipeline device tree nodes to its DTSI file. > > The H5 pipeline has some differences and will be enabled later. > > The currently-unused

Re: [RFC PATCH 10/11] ARM: sun8i: h3: add display engine pipeline for TVE

On Thu, May 18, 2017 at 12:43:53AM +0800, Icenowy Zheng wrote: > As we have already the support for the TV encoder on Allwinner H3, add > the display engine pipeline device tree nodes to its DTSI file. > > The H5 pipeline has some differences and will be enabled later. > > The currently-unused

Re: [copyleft-next] Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

On Fri, May 19, 2017 at 10:59 AM, Luis R. Rodriguez wrote: > On Fri, May 19, 2017 at 05:09:20PM +0200, Luis R. Rodriguez wrote: >> On Fri, May 19, 2017 at 12:31:50PM +0100, Alan Cox wrote: >> > > I really cannot see how you might have an attorney who wants ink on >> > > 2A but

Re: [copyleft-next] Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

On Fri, May 19, 2017 at 10:59 AM, Luis R. Rodriguez wrote: > On Fri, May 19, 2017 at 05:09:20PM +0200, Luis R. Rodriguez wrote: >> On Fri, May 19, 2017 at 12:31:50PM +0100, Alan Cox wrote: >> > > I really cannot see how you might have an attorney who wants ink on >> > > 2A but not 1A. >> > > I

<    1   2   3   4   5   6   7   8   9   10   >