[PATCH] rtlwifi: btcoexist: fix semicolon.cocci warnings

Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci CC: Larry Finger Signed-off-by: Julia Lawall Signed-off-by: Fengguang Wu --- halbtc8821a2ant.c |2 +- 1 file changed, 1 insertion(+),

[PATCH] rtlwifi: btcoexist: fix semicolon.cocci warnings

Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci CC: Larry Finger Signed-off-by: Julia Lawall Signed-off-by: Fengguang Wu --- halbtc8821a2ant.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ---

Re: Sed-opal fixups

e0;136;0csOn Thu, Feb 09, 2017 at 11:24:58AM -0700, Jens Axboe wrote: > On 02/09/2017 10:45 AM, Scott Bauer wrote: > > On Thu, Feb 09, 2017 at 05:43:20PM +, David Laight wrote: > >> From: Scott Bauer > >>> Sent: 09 February 2017 17:20 > >>> It may be too late to change anyhting in the uapi

Re: Sed-opal fixups

e0;136;0csOn Thu, Feb 09, 2017 at 11:24:58AM -0700, Jens Axboe wrote: > On 02/09/2017 10:45 AM, Scott Bauer wrote: > > On Thu, Feb 09, 2017 at 05:43:20PM +, David Laight wrote: > >> From: Scott Bauer > >>> Sent: 09 February 2017 17:20 > >>> It may be too late to change anyhting in the uapi

Re: [GIT PULL] PCI fixes for v4.10

On Thu, Feb 09, 2017 at 09:09:50AM -0600, Bjorn Helgaas wrote: > [+cc Ashok, Keith] > > On Thu, Feb 09, 2017 at 05:06:48AM +0100, Lukas Wunner wrote: > > On Wed, Feb 08, 2017 at 01:22:56PM -0600, Bjorn Helgaas wrote: > > > Bjorn Helgaas (1): > > > Revert "PCI: pciehp: Add runtime PM support

Re: [GIT PULL] PCI fixes for v4.10

On Thu, Feb 09, 2017 at 09:09:50AM -0600, Bjorn Helgaas wrote: > [+cc Ashok, Keith] > > On Thu, Feb 09, 2017 at 05:06:48AM +0100, Lukas Wunner wrote: > > On Wed, Feb 08, 2017 at 01:22:56PM -0600, Bjorn Helgaas wrote: > > > Bjorn Helgaas (1): > > > Revert "PCI: pciehp: Add runtime PM support

Re: linux <=4.9.5, 4.10-rc7 ok, 4.9.6 - 4.9.8 nok with realtek wlan, atom

[+cc rtl8192ce folks in case they've seen this] On Thu, Feb 09, 2017 at 03:45:01PM +0100, rupert THURNER wrote: > hi, > > not technical expert enough, i just wanted to give a short user > feedback. for realtek wlan on atom, kernels up to 4.9.5 are ok, and > kernel 4.10.0-rc7-g926af6273fc6 (arch

Re: linux <=4.9.5, 4.10-rc7 ok, 4.9.6 - 4.9.8 nok with realtek wlan, atom

[+cc rtl8192ce folks in case they've seen this] On Thu, Feb 09, 2017 at 03:45:01PM +0100, rupert THURNER wrote: > hi, > > not technical expert enough, i just wanted to give a short user > feedback. for realtek wlan on atom, kernels up to 4.9.5 are ok, and > kernel 4.10.0-rc7-g926af6273fc6 (arch

[PATCH v2 2/4] [media] exynos-gsc: Respect userspace colorspace setting

If the colorspace is specified by userspace we should respect it and not reset it ourself if we can support it. Signed-off-by: Thibault Saunier --- drivers/media/platform/exynos-gsc/gsc-core.c | 25 + 1 file changed, 17 insertions(+), 8

[PATCH v2 2/4] [media] exynos-gsc: Respect userspace colorspace setting

If the colorspace is specified by userspace we should respect it and not reset it ourself if we can support it. Signed-off-by: Thibault Saunier --- drivers/media/platform/exynos-gsc/gsc-core.c | 25 + 1 file changed, 17 insertions(+), 8 deletions(-) diff --git

Re: [PATCH 3/3 staging-next] mm: Remove RCU and tasklocks from lmk

On Thu 09-02-17 14:21:52, peter enderborg wrote: > Fundamental changes: > 1 Does NOT take any RCU lock in shrinker functions. > 2 It returns same result for scan and counts, so we dont need to do > shinker will know when it is pointless to call scan. > 3 It does not lock any other process than

Re: [PATCH 3/3 staging-next] mm: Remove RCU and tasklocks from lmk

On Thu 09-02-17 14:21:52, peter enderborg wrote: > Fundamental changes: > 1 Does NOT take any RCU lock in shrinker functions. > 2 It returns same result for scan and counts, so we dont need to do > shinker will know when it is pointless to call scan. > 3 It does not lock any other process than

[PATCH v2 4/4] [media] s5p-mfc: Always check and set 'v4l2_pix_format:field' field

It is required by the standard that the field order is set by the driver. Signed-off-by: Thibault Saunier --- drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 23 +-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git

[PATCH v2 4/4] [media] s5p-mfc: Always check and set 'v4l2_pix_format:field' field

It is required by the standard that the field order is set by the driver. Signed-off-by: Thibault Saunier --- drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 23 +-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c

[PATCH v2 0/4] [media] Fixes for colorspace logic in exynos-gsc and s5p-mfc drivers

Changes since v1: - Fix a silly build error that slipped in while rebasing the patches Javier Martinez Canillas (1): [media] exynos-gsc: Use 576p instead 720p as a threshold for colorspaces Thibault Saunier (3): [media] exynos-gsc: Respect userspace colorspace setting [media]

[PATCH v2 0/4] [media] Fixes for colorspace logic in exynos-gsc and s5p-mfc drivers

Changes since v1: - Fix a silly build error that slipped in while rebasing the patches Javier Martinez Canillas (1): [media] exynos-gsc: Use 576p instead 720p as a threshold for colorspaces Thibault Saunier (3): [media] exynos-gsc: Respect userspace colorspace setting [media]

[PATCH v2 1/4] [media] exynos-gsc: Use 576p instead 720p as a threshold for colorspaces

From: Javier Martinez Canillas The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV. But drivers don't agree on the display resolution that should be used as a threshold. Some drivers set

[PATCH v2 1/4] [media] exynos-gsc: Use 576p instead 720p as a threshold for colorspaces

From: Javier Martinez Canillas The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV. But drivers don't agree on the display resolution that should be used as a threshold. Some drivers set V4L2_COLORSPACE_REC709

[PATCH v2 3/4] [media] s5p-mfc: Set colorspace in VIDIO_{G,TRY}_FMT

The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV but the driver didn't set the colorimetry, also respect usespace setting. Use 576p display resolution as a threshold to set this. Signed-off-by: Thibault Saunier

[PATCH v2 3/4] [media] s5p-mfc: Set colorspace in VIDIO_{G,TRY}_FMT

The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV but the driver didn't set the colorimetry, also respect usespace setting. Use 576p display resolution as a threshold to set this. Signed-off-by: Thibault Saunier

RE: [PATCH 1/2] hyperv: implement hv_get_tsc_page()

The actual code looks fine, but the style police will not like you. { should be at start of line on functions. And #else should be at start of line, But maybe this was just more of exchange mangling the mail. -Original Message- From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] Sent:

RE: [PATCH 1/2] hyperv: implement hv_get_tsc_page()

The actual code looks fine, but the style police will not like you. { should be at start of line on functions. And #else should be at start of line, But maybe this was just more of exchange mangling the mail. -Original Message- From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] Sent:

[PATCH 2/3] Input: synaptics-rmi4 - clean up F30 implementation

This patch does several cleanup changes to F30 code - switch to using BIT() macro - use DIV_ROUND_UP() where appropriate - factor out code setting up and reporting buttons - use single loop when reporting buttons: arithmetic is cheap compared to conditionals and associated branch misprediction.

[PATCH 2/3] Input: synaptics-rmi4 - clean up F30 implementation

This patch does several cleanup changes to F30 code - switch to using BIT() macro - use DIV_ROUND_UP() where appropriate - factor out code setting up and reporting buttons - use single loop when reporting buttons: arithmetic is cheap compared to conditionals and associated branch misprediction.

Re: [RFC][PATCH 00/21] tracing: Inter-event (e.g. latency) support

On Thu, 09 Feb 2017 11:18:32 -0600 Tom Zanussi wrote: > I think it might make a lot of sense at this point to actually create a > system-wide list of active triggers e.g. tracing/events/triggers or > something like that. It's something I've kind of wanted anyway,

Re: [RFC][PATCH 00/21] tracing: Inter-event (e.g. latency) support

On Thu, 09 Feb 2017 11:18:32 -0600 Tom Zanussi wrote: > I think it might make a lot of sense at this point to actually create a > system-wide list of active triggers e.g. tracing/events/triggers or > something like that. It's something I've kind of wanted anyway, and > would be really useful if

[GIT PULL] pstore fix for v4.10-rc8

Hi, This pstore regression was just noticed. If I'm too late, this can land in v4.11 and -stable, but if the fix window is still open for v4.10, I'd love to see this fix pulled for v4.10. Thanks! -Kees The following changes since commit d966564fcdc19e13eb6ba1fbe6b8101070339c3d: Revert

[GIT PULL] pstore fix for v4.10-rc8

Hi, This pstore regression was just noticed. If I'm too late, this can land in v4.11 and -stable, but if the fix window is still open for v4.10, I'd love to see this fix pulled for v4.10. Thanks! -Kees The following changes since commit d966564fcdc19e13eb6ba1fbe6b8101070339c3d: Revert

[PATCH 1/3] Input: synaptics - use SERIO_OOB_DATA to handle trackstick buttons

Instead of using custom method of "passing" extended buttons from the touchpad to trackstick, let's switch to the newly introduced SERIO_OOB_DATA channel. Signed-off-by: Dmitry Torokhov --- drivers/input/mouse/synaptics.c | 26 +-

[PATCH 1/3] Input: synaptics - use SERIO_OOB_DATA to handle trackstick buttons

Instead of using custom method of "passing" extended buttons from the touchpad to trackstick, let's switch to the newly introduced SERIO_OOB_DATA channel. Signed-off-by: Dmitry Torokhov --- drivers/input/mouse/synaptics.c | 26 +- drivers/input/mouse/synaptics.h | 1 -

Re: [PATCH V3 2/2] Move stack parameters for sed_ioctl to prevent oversized stack with CONFIG_KASAN

On Thu, Feb 09, 2017 at 10:20:01AM -0700, Scott Bauer wrote: > When CONFIG_KASAN is enabled, compilation fails: > > block/sed-opal.c: In function 'sed_ioctl': > block/sed-opal.c:2447:1: error: the frame size of 2256 bytes is larger than > 2048 bytes [-Werror=frame-larger-than=] > > Moved all

Re: [PATCH V3 2/2] Move stack parameters for sed_ioctl to prevent oversized stack with CONFIG_KASAN

On Thu, Feb 09, 2017 at 10:20:01AM -0700, Scott Bauer wrote: > When CONFIG_KASAN is enabled, compilation fails: > > block/sed-opal.c: In function 'sed_ioctl': > block/sed-opal.c:2447:1: error: the frame size of 2256 bytes is larger than > 2048 bytes [-Werror=frame-larger-than=] > > Moved all

Re: [PATCH v3 1/3] of: Support parsing phandle argument lists through a nexus node

Quoting Rob Herring (2017-02-09 08:00:05) > On Thu, Feb 9, 2017 at 9:35 AM, Russell King - ARM Linux > wrote: > > On Thu, Feb 09, 2017 at 09:17:58AM -0600, Rob Herring wrote: > >> Frank, any more comments on this? If not, I plan to apply this series. > > > > Well, I find

Re: [PATCH v3 1/3] of: Support parsing phandle argument lists through a nexus node

Quoting Rob Herring (2017-02-09 08:00:05) > On Thu, Feb 9, 2017 at 9:35 AM, Russell King - ARM Linux > wrote: > > On Thu, Feb 09, 2017 at 09:17:58AM -0600, Rob Herring wrote: > >> Frank, any more comments on this? If not, I plan to apply this series. > > > > Well, I find that a little annoying,

Re: [PATCH for-4.10] pstore: don't OOPS when there are no ftrace zones

On Wed, Feb 8, 2017 at 10:44 PM, Brian Norris wrote: > We'll OOPS in ramoops_get_next_prz() if the platform didn't ask for any > ftrace zones (i.e., cxt->fprzs will be NULL). Let's just skip this > entire FTRACE section if there's no 'fprzs'. > > Regression seen on a

Re: [PATCH for-4.10] pstore: don't OOPS when there are no ftrace zones

On Wed, Feb 8, 2017 at 10:44 PM, Brian Norris wrote: > We'll OOPS in ramoops_get_next_prz() if the platform didn't ask for any > ftrace zones (i.e., cxt->fprzs will be NULL). Let's just skip this > entire FTRACE section if there's no 'fprzs'. > > Regression seen on a coreboot/depthcharge-based

[PATCH] x86: Optimize clear_page()

From: Borislav Petkov Currently, we CALL clear_page() which then JMPs to the proper function chosen by the alternatives. What we should do instead is CALL the proper function directly. (This was something Ingo suggested a while ago). So let's do that. Measuring our favourite

[PATCH] x86: Optimize clear_page()

From: Borislav Petkov Currently, we CALL clear_page() which then JMPs to the proper function chosen by the alternatives. What we should do instead is CALL the proper function directly. (This was something Ingo suggested a while ago). So let's do that. Measuring our favourite kernel build

[PATCH 3/3] Input: synaptics-rmi4 - forward upper mechanical buttons to PS/2 guest

From: Benjamin Tissoires On the latest series of ThinkPads, the button events for the TrackPoint are reported through the touchpad itself as opposed to the TrackPoint device. In order to report these buttons properly, we need to forward them to the TrackPoint

[PATCH 3/3] Input: synaptics-rmi4 - forward upper mechanical buttons to PS/2 guest

From: Benjamin Tissoires On the latest series of ThinkPads, the button events for the TrackPoint are reported through the touchpad itself as opposed to the TrackPoint device. In order to report these buttons properly, we need to forward them to the TrackPoint device and notify psmouse to send

Re: [PATCH] drivers: usb: usbip: Add missing break statement to switch

On 02/09/2017 12:49 AM, Gustavo A. R. Silva wrote: > Add missing break statement to prevent the code for case > USB_PORT_FEAT_C_RESET falling through to the default case. > > Addresses-Coverity-ID: 143155 > Signed-off-by: Gustavo A. R. Silva > --- >

Re: [PATCH] drivers: usb: usbip: Add missing break statement to switch

On 02/09/2017 12:49 AM, Gustavo A. R. Silva wrote: > Add missing break statement to prevent the code for case > USB_PORT_FEAT_C_RESET falling through to the default case. > > Addresses-Coverity-ID: 143155 > Signed-off-by: Gustavo A. R. Silva > --- > drivers/usb/usbip/vhci_hcd.c | 1 + > 1 file

Re: [PATCH 2/3 staging-next] oom: Add notification for oom_score_adj

On Thu 09-02-17 14:21:49, peter enderborg wrote: > This adds subscribtion for changes in oom_score_adj, this > value is important to android systems. Why? Who is user of this API? -- Michal Hocko SUSE Labs

Re: [PATCH 2/3 staging-next] oom: Add notification for oom_score_adj

On Thu 09-02-17 14:21:49, peter enderborg wrote: > This adds subscribtion for changes in oom_score_adj, this > value is important to android systems. Why? Who is user of this API? -- Michal Hocko SUSE Labs

Re: [PATCH v7 0/5] Update LZ4 compressor module

On Thu, Feb 09, 2017 at 12:02:11PM +0100, Sven Schmidt wrote: > > > > [Also, for some reason linux-crypto is apparently still not receiving patch > > 1/5 > > in the series. It's missing from the linux-crypto archive at > > http://www.spinics.net/lists/linux-crypto/, so it's not just me.] > > >

Re: [PATCH v7 0/5] Update LZ4 compressor module

On Thu, Feb 09, 2017 at 12:02:11PM +0100, Sven Schmidt wrote: > > > > [Also, for some reason linux-crypto is apparently still not receiving patch > > 1/5 > > in the series. It's missing from the linux-crypto archive at > > http://www.spinics.net/lists/linux-crypto/, so it's not just me.] > > >

Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion

On Thu, 2017-02-09 at 12:04 -0700, Jason Gunthorpe wrote: > On Thu, Feb 09, 2017 at 05:19:22PM +0200, Jarkko Sakkinen wrote: > > The current patch set does not define policy. The simple policy > > addition that could be added soon is the limit of connections > > because it is easy to implement in

Re: [Xen-devel] [PATCH 1/3] xen/privcmd: return -ENOSYS for unimplemented IOCTLs

On 02/09/2017 09:40 AM, Jan Beulich wrote: On 09.02.17 at 15:17, wrote: The code goes so far as to set the default return code to -ENOSYS but then overrides this to -EINVAL in the switch() statement's default case. If you already change this, isn't -ENOTTY the

Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion

On Thu, 2017-02-09 at 12:04 -0700, Jason Gunthorpe wrote: > On Thu, Feb 09, 2017 at 05:19:22PM +0200, Jarkko Sakkinen wrote: > > The current patch set does not define policy. The simple policy > > addition that could be added soon is the limit of connections > > because it is easy to implement in

Re: [Xen-devel] [PATCH 1/3] xen/privcmd: return -ENOSYS for unimplemented IOCTLs

On 02/09/2017 09:40 AM, Jan Beulich wrote: On 09.02.17 at 15:17, wrote: The code goes so far as to set the default return code to -ENOSYS but then overrides this to -EINVAL in the switch() statement's default case. If you already change this, isn't -ENOTTY the traditional way of indicating

Re: [PATCH 4.4 01/27] netvsc: reduce maximum GSO size

On Fri, 2017-01-13 at 12:38 +0100, Greg Kroah-Hartman wrote: > 4.4-stable review patch.  If anyone has any objections, please let me know. > > -- > > From: stephen hemminger > > > [ Upstream commit a50af86dd49ee1851d1ccf06dd0019c05b95e297 ] > >

Re: [PATCH 4.4 01/27] netvsc: reduce maximum GSO size

On Fri, 2017-01-13 at 12:38 +0100, Greg Kroah-Hartman wrote: > 4.4-stable review patch.  If anyone has any objections, please let me know. > > -- > > From: stephen hemminger > > > [ Upstream commit a50af86dd49ee1851d1ccf06dd0019c05b95e297 ] > > Hyper-V (and Azure) support

Re: [RFC] syscalls: Restore address limit after a syscall

d mitigation this bug: > > - https://bugs.chromium.org/p/project-zero/issues/detail?id=990 > > Signed-off-by: Thomas Garnier <thgar...@google.com> > --- > Based on next-20170209 > --- > include/linux/syscalls.h | 5 - > 1 file changed, 4 insertions(+), 1 deletion(

Re: [RFC] syscalls: Restore address limit after a syscall

ug: > > - https://bugs.chromium.org/p/project-zero/issues/detail?id=990 > > Signed-off-by: Thomas Garnier > --- > Based on next-20170209 > --- > include/linux/syscalls.h | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/include/linux/syscalls.h

Re: [PATCH 1/3 staging-next] android: Collect statistics from lowmemorykiller

On Thu 09-02-17 14:21:45, peter enderborg wrote: > This collects stats for shrinker calls and how much > waste work we do within the lowmemorykiller. This doesn't explain why do we need this information and who is going to use it. Not to mention it exports it in /proc which is considered a stable

Re: [PATCH 1/3 staging-next] android: Collect statistics from lowmemorykiller

On Thu 09-02-17 14:21:45, peter enderborg wrote: > This collects stats for shrinker calls and how much > waste work we do within the lowmemorykiller. This doesn't explain why do we need this information and who is going to use it. Not to mention it exports it in /proc which is considered a stable

Re: Intel PT decoder switch case fallthrough cases reported by gcc 7

Em Thu, Feb 09, 2017 at 11:13:16AM -0800, Andi Kleen escreveu: > > But what about my question? Do you think the changes are ok? I actually > > made all be fallthrough, i.e. considered that the existing code was ok. > > Yes the changes are fine. Thanks! - Arnaldo

Re: Intel PT decoder switch case fallthrough cases reported by gcc 7

Em Thu, Feb 09, 2017 at 11:13:16AM -0800, Andi Kleen escreveu: > > But what about my question? Do you think the changes are ok? I actually > > made all be fallthrough, i.e. considered that the existing code was ok. > > Yes the changes are fine. Thanks! - Arnaldo

[PATCH] net: micrel: ksz884x: use new api ethtool_{get|set}_link_ksettings

The ethtool api {get|set}_settings is deprecated. We move this driver to new api {get|set}_link_ksettings. As I don't have the hardware, I'd be very pleased if someone may test this patch. Signed-off-by: Philippe Reynes --- drivers/net/ethernet/micrel/ksz884x.c | 62

[PATCH] net: micrel: ksz884x: use new api ethtool_{get|set}_link_ksettings

The ethtool api {get|set}_settings is deprecated. We move this driver to new api {get|set}_link_ksettings. As I don't have the hardware, I'd be very pleased if someone may test this patch. Signed-off-by: Philippe Reynes --- drivers/net/ethernet/micrel/ksz884x.c | 62

Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion

On Thu, 2017-02-09 at 03:06 -0600, Dr. Greg Wettstein wrote: > Referring back to Ken's comments about having 20+ clients waiting to > get access to the hardware. Even with the focus in TPM2 on having it > be more of a cryptographic accelerator are we convinced that the > hardware is ever going to

Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion

On Thu, 2017-02-09 at 03:06 -0600, Dr. Greg Wettstein wrote: > Referring back to Ken's comments about having 20+ clients waiting to > get access to the hardware. Even with the focus in TPM2 on having it > be more of a cryptographic accelerator are we convinced that the > hardware is ever going to

Re: [PATCH] security: selinux: allow per-file labeling for cgroupfs

On Thu, Feb 9, 2017 at 12:39 PM, Antonio Murdaca wrote: > On Feb 9, 2017 17:14, "Paul Moore" wrote: > On Thu, Feb 9, 2017 at 11:02 AM, Antonio Murdaca > wrote: >> From: Antonio Murdaca >> >> This patch allows

Re: [PATCH] security: selinux: allow per-file labeling for cgroupfs

On Thu, Feb 9, 2017 at 12:39 PM, Antonio Murdaca wrote: > On Feb 9, 2017 17:14, "Paul Moore" wrote: > On Thu, Feb 9, 2017 at 11:02 AM, Antonio Murdaca > wrote: >> From: Antonio Murdaca >> >> This patch allows genfscon per-file labeling for cgroupfs. For instance, >> this allows to label the

Re: [PATCH] fs: ext4: block_validity.c

On Thu, Feb 09, 2017 at 01:57:21PM -0500, Nathan Howard wrote: > Fixed coding style issues. Sorry, I only take coding style fixups as part of substantive (bug fixes, new features, or optimizatoins) changes to the code in question. If you're trying to do "my first kernel patch", the recommended

Re: [PATCH] fs: ext4: block_validity.c

On Thu, Feb 09, 2017 at 01:57:21PM -0500, Nathan Howard wrote: > Fixed coding style issues. Sorry, I only take coding style fixups as part of substantive (bug fixes, new features, or optimizatoins) changes to the code in question. If you're trying to do "my first kernel patch", the recommended

Re: [PATCH 3/8] mm: cma: Export a few symbols

[CC CMA people] On Thu 09-02-17 17:39:17, Maxime Ripard wrote: > Modules might want to check their CMA pool size and address for debugging > and / or have additional checks. > > The obvious way to do this would be through dev_get_cma_area and > cma_get_base and cma_get_size, that are currently

Re: [PATCH 3/8] mm: cma: Export a few symbols

[CC CMA people] On Thu 09-02-17 17:39:17, Maxime Ripard wrote: > Modules might want to check their CMA pool size and address for debugging > and / or have additional checks. > > The obvious way to do this would be through dev_get_cma_area and > cma_get_base and cma_get_size, that are currently

Re: mm: deadlock between get_online_cpus/pcpu_alloc

On Thu 09-02-17 11:22:49, Cristopher Lameter wrote: > On Thu, 9 Feb 2017, Thomas Gleixner wrote: > > > You are just not getting it, really. > > > > The problem is that this for_each_online_cpu() is racy against a concurrent > > hot unplug and therefor can queue stuff for a not longer online cpu.

Re: mm: deadlock between get_online_cpus/pcpu_alloc

On Thu 09-02-17 11:22:49, Cristopher Lameter wrote: > On Thu, 9 Feb 2017, Thomas Gleixner wrote: > > > You are just not getting it, really. > > > > The problem is that this for_each_online_cpu() is racy against a concurrent > > hot unplug and therefor can queue stuff for a not longer online cpu.

Re: Intel PT decoder switch case fallthrough cases reported by gcc 7

> But what about my question? Do you think the changes are ok? I actually > made all be fallthrough, i.e. considered that the existing code was ok. Yes the changes are fine. -Andi

Re: Intel PT decoder switch case fallthrough cases reported by gcc 7

> But what about my question? Do you think the changes are ok? I actually > made all be fallthrough, i.e. considered that the existing code was ok. Yes the changes are fine. -Andi

Re: Intel PT decoder switch case fallthrough cases reported by gcc 7

Em Thu, Feb 09, 2017 at 10:25:19AM -0800, Andi Kleen escreveu: > On Thu, Feb 09, 2017 at 01:50:39PM -0300, Arnaldo Carvalho de Melo wrote: > > Hi, > > > > I've updated the container with Fedora Rawhide I use to build > > tools/perf/ and samples/bcc/ and it now comes with gcc 7, where I get >

Re: [PATCHv3] arm: ftrace: Adds support for CONFIG_DYNAMIC_FTRACE_WITH_REGS

On Thu, Feb 09, 2017 at 07:01:10PM +, Abel Vesa wrote: > On Thu, Feb 09, 2017 at 01:14:52PM -0500, Steven Rostedt wrote: > > > > [ sending again with Masami Cc'd ] > > > > On Thu, 9 Feb 2017 13:14:14 -0500 > > Steven Rostedt wrote: > > > > > On Thu, 9 Feb 2017 18:06:44

Re: Intel PT decoder switch case fallthrough cases reported by gcc 7

Em Thu, Feb 09, 2017 at 10:25:19AM -0800, Andi Kleen escreveu: > On Thu, Feb 09, 2017 at 01:50:39PM -0300, Arnaldo Carvalho de Melo wrote: > > Hi, > > > > I've updated the container with Fedora Rawhide I use to build > > tools/perf/ and samples/bcc/ and it now comes with gcc 7, where I get >

Re: [PATCHv3] arm: ftrace: Adds support for CONFIG_DYNAMIC_FTRACE_WITH_REGS

On Thu, Feb 09, 2017 at 07:01:10PM +, Abel Vesa wrote: > On Thu, Feb 09, 2017 at 01:14:52PM -0500, Steven Rostedt wrote: > > > > [ sending again with Masami Cc'd ] > > > > On Thu, 9 Feb 2017 13:14:14 -0500 > > Steven Rostedt wrote: > > > > > On Thu, 9 Feb 2017 18:06:44 + > > > Russell

[PATCH v2 0/6] DRM OF graph clean-up

I've been unhappy with the OF graph API for some time and decided to do something about it. The problem is drivers have to do too much of the graph parsing and walking themselves. This has led to the same pattern duplicated over and over. This series adds 2 new helpers and adapts DRM drivers to

[PATCH v2 0/6] DRM OF graph clean-up

I've been unhappy with the OF graph API for some time and decided to do something about it. The problem is drivers have to do too much of the graph parsing and walking themselves. This has led to the same pattern duplicated over and over. This series adds 2 new helpers and adapts DRM drivers to

[PATCH v2 5/6] drm: convert drivers to use drm_of_find_panel_or_bridge

Similar to the previous commit, convert drivers open coding OF graph parsing to use drm_of_find_panel_or_bridge instead. This changes some error messages to debug messages (in the graph core). Graph connections are often "no connects" depending on the particular board, so we want to avoid

[PATCH v2 5/6] drm: convert drivers to use drm_of_find_panel_or_bridge

Similar to the previous commit, convert drivers open coding OF graph parsing to use drm_of_find_panel_or_bridge instead. This changes some error messages to debug messages (in the graph core). Graph connections are often "no connects" depending on the particular board, so we want to avoid

[PATCH v2 6/6] drm: omap: use common OF graph helpers

The OMAP driver has its own OF graph helpers that are similar to the common helpers. This commit replaces most of the calls with the common helpers. There's still a couple of custom helpers left, but the driver needs more extensive changes to get rid of them. In dss_init_ports, we invert the

[PATCH v2 6/6] drm: omap: use common OF graph helpers

The OMAP driver has its own OF graph helpers that are similar to the common helpers. This commit replaces most of the calls with the common helpers. There's still a couple of custom helpers left, but the driver needs more extensive changes to get rid of them. In dss_init_ports, we invert the

Re: [PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC

On Thu, Feb 09, 2017 at 05:38:26PM +, Daniel Stone wrote: > Hi, > > On 9 February 2017 at 17:01, Daniel Vetter wrote: > > On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote: > >> +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned > >> long

Re: [PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC

On Thu, Feb 09, 2017 at 05:38:26PM +, Daniel Stone wrote: > Hi, > > On 9 February 2017 at 17:01, Daniel Vetter wrote: > > On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote: > >> +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned > >> long arg) > >> +{ > >>

[PATCH] fs: ext4: block_validity.c

Fixed coding style issues. Signed-off-by: Nathan Howard --- fs/ext4/block_validity.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/fs/ext4/block_validity.c b/fs/ext4/block_validity.c index fdb1954..fead1f9 100644 ---

[PATCH] fs: ext4: block_validity.c

Fixed coding style issues. Signed-off-by: Nathan Howard --- fs/ext4/block_validity.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/fs/ext4/block_validity.c b/fs/ext4/block_validity.c index fdb1954..fead1f9 100644 --- a/fs/ext4/block_validity.c +++

[PATCH v2 1/6] of: introduce of_graph_get_remote_node

The OF graph API leaves too much of the graph walking to clients when in many cases the driver doesn't care about accessing the port or endpoint nodes. The drivers typically just want the device connected via a particular graph connection. of_graph_get_remote_node provides this functionality.

[PATCH v2 1/6] of: introduce of_graph_get_remote_node

The OF graph API leaves too much of the graph walking to clients when in many cases the driver doesn't care about accessing the port or endpoint nodes. The drivers typically just want the device connected via a particular graph connection. of_graph_get_remote_node provides this functionality.

[PATCH v2 3/6] drm: of: introduce drm_of_find_panel_or_bridge

Many drivers have a common pattern of searching the OF graph for either an attached panel or bridge and then finding the DRM struct for the panel or bridge. Also, most drivers need to handle deferred probing when the DRM device is not yet instantiated. Create a common function,

[PATCH v2 3/6] drm: of: introduce drm_of_find_panel_or_bridge

Many drivers have a common pattern of searching the OF graph for either an attached panel or bridge and then finding the DRM struct for the panel or bridge. Also, most drivers need to handle deferred probing when the DRM device is not yet instantiated. Create a common function,

Re: [PATCH v2] vfio/mdev: Use a module softdep for vfio_mdev

On 2/9/2017 3:46 AM, Alex Williamson wrote: > Use an explicit module softdep rather than a request module call such > that the dependency is exposed to userspace. This allows us to more > easily support modules loaded at initrd time. > > Signed-off-by: Alex Williamson

Re: [PATCH v2] vfio/mdev: Use a module softdep for vfio_mdev

On 2/9/2017 3:46 AM, Alex Williamson wrote: > Use an explicit module softdep rather than a request module call such > that the dependency is exposed to userspace. This allows us to more > easily support modules loaded at initrd time. > > Signed-off-by: Alex Williamson > --- > Looks good to me.

[PATCH v2 4/6] drm: convert drivers to use of_graph_get_remote_node

Convert drivers to use the new of_graph_get_remote_node() helper instead of parsing the endpoint node and then getting the remote device node. Now drivers can just specify the device node and which port/endpoint and get back the connected remote device node. The details of the graph binding are

[PATCH v2 2/6] drm: make of_drm_find_panel also depend on CONFIG_DRM_PANEL

For drm_of_find_panel_or_bridge() added in the next commit, an empty version of of_drm_find_panel is needed for !CONFIG_DRM_PANEL. Signed-off-by: Rob Herring --- v2: - new patch include/drm/drm_panel.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v2 4/6] drm: convert drivers to use of_graph_get_remote_node

Convert drivers to use the new of_graph_get_remote_node() helper instead of parsing the endpoint node and then getting the remote device node. Now drivers can just specify the device node and which port/endpoint and get back the connected remote device node. The details of the graph binding are

[PATCH v2 2/6] drm: make of_drm_find_panel also depend on CONFIG_DRM_PANEL

For drm_of_find_panel_or_bridge() added in the next commit, an empty version of of_drm_find_panel is needed for !CONFIG_DRM_PANEL. Signed-off-by: Rob Herring --- v2: - new patch include/drm/drm_panel.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm_panel.h

Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion

On Thu, Feb 09, 2017 at 05:19:22PM +0200, Jarkko Sakkinen wrote: > > userspace instance with subsequent relinquishment of privilege. At > > that point one has the freedom to implement all sorts of policy. > > If you look at the patch set that I sent yesterday it exactly has a > feature that

Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion

On Thu, Feb 09, 2017 at 05:19:22PM +0200, Jarkko Sakkinen wrote: > > userspace instance with subsequent relinquishment of privilege. At > > that point one has the freedom to implement all sorts of policy. > > If you look at the patch set that I sent yesterday it exactly has a > feature that

Re: [PATCHv3] arm: ftrace: Adds support for CONFIG_DYNAMIC_FTRACE_WITH_REGS

On Thu, Feb 09, 2017 at 01:14:52PM -0500, Steven Rostedt wrote: > > [ sending again with Masami Cc'd ] > > On Thu, 9 Feb 2017 13:14:14 -0500 > Steven Rostedt wrote: > > > On Thu, 9 Feb 2017 18:06:44 + > > Russell King - ARM Linux wrote: > > > >

Re: [PATCHv3] arm: ftrace: Adds support for CONFIG_DYNAMIC_FTRACE_WITH_REGS

On Thu, Feb 09, 2017 at 01:14:52PM -0500, Steven Rostedt wrote: > > [ sending again with Masami Cc'd ] > > On Thu, 9 Feb 2017 13:14:14 -0500 > Steven Rostedt wrote: > > > On Thu, 9 Feb 2017 18:06:44 + > > Russell King - ARM Linux wrote: > > > > > On Thu, Feb 09, 2017 at 12:13:22PM -0500,

<    3   4   5   6   7   8   9   10   11   12   >