Re: [PATCH 2/2] Add S6 support

> "Charles" == Charles Chiou writes: Charles, Charles> Hi all, Ping? Does this patch has any issue need to fix? Thank Charles> you. I'm hoping somebody will review it soon. However, we're in the middle of the 4.11 merge window so people are mostly focused on

Re: [PATCH 2/2] Add S6 support

> "Charles" == Charles Chiou writes: Charles, Charles> Hi all, Ping? Does this patch has any issue need to fix? Thank Charles> you. I'm hoping somebody will review it soon. However, we're in the middle of the 4.11 merge window so people are mostly focused on regressions. I expect to

Re: [PATCH] input: cpcap-pwrbutton: new driver

* Tony Lindgren [170225 11:21]: > * Dmitry Torokhov [170225 11:00]: > > On Fri, Feb 24, 2017 at 09:59:09AM +0100, Sebastian Reichel wrote: > > > +#include > > > + > > > +#define CPCAP_IRQ_ON 23 > > > +#define CPCAP_IRQ_ON_BITMASK (1 << (CPCAP_IRQ_ON

Re: [PATCH] input: cpcap-pwrbutton: new driver

* Tony Lindgren [170225 11:21]: > * Dmitry Torokhov [170225 11:00]: > > On Fri, Feb 24, 2017 at 09:59:09AM +0100, Sebastian Reichel wrote: > > > +#include > > > + > > > +#define CPCAP_IRQ_ON 23 > > > +#define CPCAP_IRQ_ON_BITMASK (1 << (CPCAP_IRQ_ON % 16)) > > > > Is this truly static or it

Re: [PATCH 0/2] key payload access with just rcu_read_lock()

- Original Message - > From: "David Howells" > To: "Jan Stancek" > Cc: dhowe...@redhat.com, linux-kernel@vger.kernel.org, > linux-...@vger.kernel.org, bcodd...@redhat.com, > asav...@redhat.com > Sent: Monday, 27 February, 2017 11:04:21 PM >

Re: [PATCH 0/2] key payload access with just rcu_read_lock()

- Original Message - > From: "David Howells" > To: "Jan Stancek" > Cc: dhowe...@redhat.com, linux-kernel@vger.kernel.org, > linux-...@vger.kernel.org, bcodd...@redhat.com, > asav...@redhat.com > Sent: Monday, 27 February, 2017 11:04:21 PM > Subject: Re: [PATCH 0/2] key payload access

[PATCH v4] vfio error recovery: kernel support

From: "Michael S. Tsirkin" 0. What happens now (PCIE AER only) Fatal errors cause a link reset. Non fatal errors don't. All errors stop the VM eventually, but not immediately because it's detected and reported asynchronously. Interrupts are forwarded as usual.

Re: [PATCH] jump_label: align jump_entry table to at least 4-bytes

On Mon, 27 Feb 2017 11:59:50 -0800 David Daney wrote: > For me the size is not the important issue, it is the alignment of the > struct jump_entry entries in the table. I don't understand how your > patch helps, and I cannot Acked-by unless I understand what is

[PATCH v4] vfio error recovery: kernel support

From: "Michael S. Tsirkin" 0. What happens now (PCIE AER only) Fatal errors cause a link reset. Non fatal errors don't. All errors stop the VM eventually, but not immediately because it's detected and reported asynchronously. Interrupts are forwarded as usual. Correctable

Re: [PATCH] jump_label: align jump_entry table to at least 4-bytes

On Mon, 27 Feb 2017 11:59:50 -0800 David Daney wrote: > For me the size is not the important issue, it is the alignment of the > struct jump_entry entries in the table. I don't understand how your > patch helps, and I cannot Acked-by unless I understand what is being > done and can see that

IB on s390 broken with commit 99db94940 "IB/core: Remove ib_device.dma_device"

Hi, commit 99db94940 "IB/core: Remove ib_device.dma_device" breaks infiniband on s390 (and I think also other archs that do something like to_pci_dev(dev) in one of their dma_ops callbacks). With this commit you use the dma_ops of the device that called ib_register_device but you call e.g.

IB on s390 broken with commit 99db94940 "IB/core: Remove ib_device.dma_device"

Hi, commit 99db94940 "IB/core: Remove ib_device.dma_device" breaks infiniband on s390 (and I think also other archs that do something like to_pci_dev(dev) in one of their dma_ops callbacks). With this commit you use the dma_ops of the device that called ib_register_device but you call e.g.

Re: [PATCH] cpufreq: intel_pstate: Fix operation mode switching

On Tue, 2017-02-28 at 00:05 +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > There is a problem with intel_pstate operation mode switching > introduced by commit fb1fe1041c04 (cpufreq: intel_pstate: Operation > mode control from sysfs), because the global

Re: [PATCH] cpufreq: intel_pstate: Fix operation mode switching

On Tue, 2017-02-28 at 00:05 +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > There is a problem with intel_pstate operation mode switching > introduced by commit fb1fe1041c04 (cpufreq: intel_pstate: Operation > mode control from sysfs), because the global sysfs limits are >

[GIT] Networking

1) Don't save TIPC header values before the header has been validated, from Jon Paul Maloy. 2) Fix memory leak in RDS, from Zhu Yanjun. 3) We miss to initialize the UID in the flow key in some paths, from Julian Anastasov. 4) Fix latent TOS masking bug in the routing cache removal from

[GIT] Networking

1) Don't save TIPC header values before the header has been validated, from Jon Paul Maloy. 2) Fix memory leak in RDS, from Zhu Yanjun. 3) We miss to initialize the UID in the flow key in some paths, from Julian Anastasov. 4) Fix latent TOS masking bug in the routing cache removal from

Re: [PULL] bcache: based on for-4.10/block, multiple updates

On Wed, 14 Dec 2016, Jens Axboe wrote: > On 12/14/2016 06:50 PM, Eric Wheeler wrote: > > Hi Jens, > > > > I know you're busy, so when you get a moment: > > > > I've not yet seen your ack/nack on this yet and I want to make sure it > > gets in before the merge window closes for v4.10. I rebased

Re: [PULL] bcache: based on for-4.10/block, multiple updates

On Wed, 14 Dec 2016, Jens Axboe wrote: > On 12/14/2016 06:50 PM, Eric Wheeler wrote: > > Hi Jens, > > > > I know you're busy, so when you get a moment: > > > > I've not yet seen your ack/nack on this yet and I want to make sure it > > gets in before the merge window closes for v4.10. I rebased

Re: [PATCH] ide: palm_bk3710: add __initdata to palm_bk3710_port_info

From: Bhumika Goyal Date: Fri, 30 Dec 2016 14:50:02 +0530 > The object palm_bk3710_port_info of type ide_port_info is never > referenced anywhere after initialization by palm_bk3710_probe. It is > also passed as a parameter to ide_host_add which is called from the init >

Re: [PATCH] ide: palm_bk3710: add __initdata to palm_bk3710_port_info

From: Bhumika Goyal Date: Fri, 30 Dec 2016 14:50:02 +0530 > The object palm_bk3710_port_info of type ide_port_info is never > referenced anywhere after initialization by palm_bk3710_probe. It is > also passed as a parameter to ide_host_add which is called from the init > function but this call

[GIT] IDE

Just one actual change here this time around, adding some init data annotations. The other change was bogus and got reverted. Please pull, thanks! The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77: Linux 4.10-rc1 (2016-12-25 16:13:08 -0800) are available in the

[GIT] IDE

Just one actual change here this time around, adding some init data annotations. The other change was bogus and got reverted. Please pull, thanks! The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77: Linux 4.10-rc1 (2016-12-25 16:13:08 -0800) are available in the

Re: [PATCH v2] mm/vmscan: fix high cpu usage of kswapd if there are no reclaimable pages

Hi Johannes I have another concern: kswapd -> balance_pgdat -> age_active_anon This code path will do some background works to age anon list, will this patch have some impact on it if the retry time is > 16 and kswapd is not waken up? B.R. Jia On 28/02/2017 1:06 AM, Johannes Weiner wrote: On

Re: [PATCH v2] mm/vmscan: fix high cpu usage of kswapd if there are no reclaimable pages

Hi Johannes I have another concern: kswapd -> balance_pgdat -> age_active_anon This code path will do some background works to age anon list, will this patch have some impact on it if the retry time is > 16 and kswapd is not waken up? B.R. Jia On 28/02/2017 1:06 AM, Johannes Weiner wrote: On

Re: tip.today - scheduler bam boom crash (cpu hotplug)

2017-02-28 0:11 GMT+08:00 Paolo Bonzini : > > > On 27/02/2017 16:59, Peter Zijlstra wrote: >> OK, so if !KVM_FEATURE_CLOCKSOURCE_STABLE_BIT nothing is stable, but if >> it is set, TSC might still not be stable, but kvm_clock_read() is. >> >>> However, if kvmclock is stable, we

Re: tip.today - scheduler bam boom crash (cpu hotplug)

2017-02-28 0:11 GMT+08:00 Paolo Bonzini : > > > On 27/02/2017 16:59, Peter Zijlstra wrote: >> OK, so if !KVM_FEATURE_CLOCKSOURCE_STABLE_BIT nothing is stable, but if >> it is set, TSC might still not be stable, but kvm_clock_read() is. >> >>> However, if kvmclock is stable, we know that the sched

Re: [usb] bea5b158ff WARNING: CPU: 0 PID: 25 at drivers/usb/core/urb.c:338 usb_submit_urb

On 02/27, Peter Chen wrote: >On Sun, Feb 26, 2017 at 06:19:59PM +0800, Fengguang Wu wrote: >> [Sorry, resend to correct Felipe's email address] >> >> Greetings, >> >> This debug patch possibly discloses some USB/I2C bugs. Since the USB >> warning shows up earlier in dmesg, it might also be the

Re: [usb] bea5b158ff WARNING: CPU: 0 PID: 25 at drivers/usb/core/urb.c:338 usb_submit_urb

On 02/27, Peter Chen wrote: >On Sun, Feb 26, 2017 at 06:19:59PM +0800, Fengguang Wu wrote: >> [Sorry, resend to correct Felipe's email address] >> >> Greetings, >> >> This debug patch possibly discloses some USB/I2C bugs. Since the USB >> warning shows up earlier in dmesg, it might also be the

[RFC PATCH] uapi: fix linux/packet_diag.h userspace compilation error

Replace MAX_ADDR_LEN with its numeric value to fix the following linux/packet_diag.h userspace compilation error: /usr/include/linux/packet_diag.h:67:17: error: 'MAX_ADDR_LEN' undeclared here (not in a function) __u8 pdmc_addr[MAX_ADDR_LEN]; This is not the first case in the UAPI where the

[RFC PATCH] uapi: fix linux/packet_diag.h userspace compilation error

Replace MAX_ADDR_LEN with its numeric value to fix the following linux/packet_diag.h userspace compilation error: /usr/include/linux/packet_diag.h:67:17: error: 'MAX_ADDR_LEN' undeclared here (not in a function) __u8 pdmc_addr[MAX_ADDR_LEN]; This is not the first case in the UAPI where the

Re: [PATCH] jump_label: align jump_entry table to at least 4-bytes

On 02/27/2017 01:06 PM, Steven Rostedt wrote: On Mon, 27 Feb 2017 11:59:50 -0800 David Daney wrote: For me the size is not the important issue, it is the alignment of the struct jump_entry entries in the table. I don't understand how your patch helps, and I cannot

Re: [PATCH] jump_label: align jump_entry table to at least 4-bytes

On 02/27/2017 01:06 PM, Steven Rostedt wrote: On Mon, 27 Feb 2017 11:59:50 -0800 David Daney wrote: For me the size is not the important issue, it is the alignment of the struct jump_entry entries in the table. I don't understand how your patch helps, and I cannot Acked-by unless I

Re: [PATCH v4 2/4] Documentation: devicetree: Add LED subnode binding for MT6323 PMIC

On Sat, Feb 25, 2017 at 02:47:19AM +0800, sean.w...@mediatek.com wrote: > From: Sean Wang > > This patch adds documentation for devicetree bindings > for LED support as the subnode of MT6323 PMIC > > Signed-off-by: Sean Wang > --- >

Re: [PATCH v4 2/4] Documentation: devicetree: Add LED subnode binding for MT6323 PMIC

On Sat, Feb 25, 2017 at 02:47:19AM +0800, sean.w...@mediatek.com wrote: > From: Sean Wang > > This patch adds documentation for devicetree bindings > for LED support as the subnode of MT6323 PMIC > > Signed-off-by: Sean Wang > --- > Documentation/devicetree/bindings/mfd/mt6397.txt | 4 >

Re: [Regression?] 1ea0ce4069 ("selinux: allow changing labels for cgroupfs") stops Android from booting

On Mon, 2017-02-27 at 14:42 -0500, Stephen Smalley wrote: > On Thu, 2017-02-23 at 19:01 -0500, Paul Moore wrote: > > > > On Thu, Feb 23, 2017 at 1:43 PM, John Stultz > g> > > wrote: > > > > > > > > > Hey folks, > > >    I've not been able to figure out why yet, but I

Re: [Regression?] 1ea0ce4069 ("selinux: allow changing labels for cgroupfs") stops Android from booting

On Mon, 2017-02-27 at 14:42 -0500, Stephen Smalley wrote: > On Thu, 2017-02-23 at 19:01 -0500, Paul Moore wrote: > > > > On Thu, Feb 23, 2017 at 1:43 PM, John Stultz > g> > > wrote: > > > > > > > > > Hey folks, > > >    I've not been able to figure out why yet, but I wanted to > > > raise > >

Re: [PATCH v3 1/2] perf/sdt: Introduce util func is_sdt_event()

On Fri, 24 Feb 2017 13:13:24 +0530 Ravi Bangoria wrote: > No Functionality changes. Please describe even it seems not have much info. Factor out the SDT event name checking routine as is_sdt_event(). BTW, would we really need to move it in util.c? I

Re: [PATCH v3 1/2] perf/sdt: Introduce util func is_sdt_event()

On Fri, 24 Feb 2017 13:13:24 +0530 Ravi Bangoria wrote: > No Functionality changes. Please describe even it seems not have much info. Factor out the SDT event name checking routine as is_sdt_event(). BTW, would we really need to move it in util.c? I think parse-event.{c,h} is a

[PATCH 2/2] gpu: drm: Convert printk(KERN_ to pr_

Use a more common logging style. Miscellanea: o Coalesce formats and realign arguments o Neaten a few macros now using pr_ Signed-off-by: Joe Perches --- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c | 4 +-

[PATCH 2/2] gpu: drm: Convert printk(KERN_ to pr_

Use a more common logging style. Miscellanea: o Coalesce formats and realign arguments o Neaten a few macros now using pr_ Signed-off-by: Joe Perches --- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c | 4 +-

[PATCH 0/2] gpu: drm: Use pr_cont and neaten logging

Joe Perches (2): drm: Use pr_cont where appropriate gpu: drm: Convert printk(KERN_ to pr_ drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 4 +-

[PATCH 1/2] drm: Use pr_cont where appropriate

Using 'printk("\n")' is not preferred anymore and using printk to continue logging messages now produces multiple line logging output unless the continuations use KERN_CONT. Convert these uses to appropriately use pr_cont or a single printk where possible. Miscellanea: o Use a temporary const

[PATCH 0/2] gpu: drm: Use pr_cont and neaten logging

Joe Perches (2): drm: Use pr_cont where appropriate gpu: drm: Convert printk(KERN_ to pr_ drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 4 +-

[PATCH 1/2] drm: Use pr_cont where appropriate

Using 'printk("\n")' is not preferred anymore and using printk to continue logging messages now produces multiple line logging output unless the continuations use KERN_CONT. Convert these uses to appropriately use pr_cont or a single printk where possible. Miscellanea: o Use a temporary const

Re: [PATCH] vfio pci: kernel support of error recovery only for non fatal error

On 02/28/2017 12:16 AM, Michael S. Tsirkin wrote: > On Mon, Feb 27, 2017 at 03:28:43PM +0800, Cao jin wrote: >> Subject: Re: [PATCH] vfio pci: kernel support of error recovery only for non >> fatal error > > Don't make the subject so long. This is why I had > [PATCH v3] vfio error

Re: [PATCH] vfio pci: kernel support of error recovery only for non fatal error

On 02/28/2017 12:16 AM, Michael S. Tsirkin wrote: > On Mon, Feb 27, 2017 at 03:28:43PM +0800, Cao jin wrote: >> Subject: Re: [PATCH] vfio pci: kernel support of error recovery only for non >> fatal error > > Don't make the subject so long. This is why I had > [PATCH v3] vfio error

[PATCH 1/1] Drivers: hv: util: don't forget to init host_ts.lock

From: Dexuan Cui Without the patch, I always get a "BUG: spinlock bad magic" warning. Fixes: 3716a49a81ba ("hv_utils: implement Hyper-V PTP source") Signed-off-by: Dexuan Cui Cc: Vitaly Kuznetsov Cc: "K. Y. Srinivasan"

[PATCH 1/1] Drivers: hv: util: don't forget to init host_ts.lock

From: Dexuan Cui Without the patch, I always get a "BUG: spinlock bad magic" warning. Fixes: 3716a49a81ba ("hv_utils: implement Hyper-V PTP source") Signed-off-by: Dexuan Cui Cc: Vitaly Kuznetsov Cc: "K. Y. Srinivasan" Cc: Haiyang Zhang Cc: Stephen Hemminger Signed-off-by: K. Y. Srinivasan

Re: Crash in -next due to 'objtool: Improve detection of BUG() and other dead ends'

Hi Josh, On Mon, Feb 27, 2017 at 04:21:14PM -0600, Josh Poimboeuf wrote: > On Mon, Feb 27, 2017 at 12:59:23PM -0800, Guenter Roeck wrote: > > Hi, > > > > my qemu tests for mips64 in -next fail as follows. > > > > ... > > VFS: Mounted root (ext3 filesystem) on device 8:0. > > Freeing unused

Re: Crash in -next due to 'objtool: Improve detection of BUG() and other dead ends'

Hi Josh, On Mon, Feb 27, 2017 at 04:21:14PM -0600, Josh Poimboeuf wrote: > On Mon, Feb 27, 2017 at 12:59:23PM -0800, Guenter Roeck wrote: > > Hi, > > > > my qemu tests for mips64 in -next fail as follows. > > > > ... > > VFS: Mounted root (ext3 filesystem) on device 8:0. > > Freeing unused

Re: [PATCH v4 1/4] Documentation: dt-bindings: Document ADXL345 accelerometer binding

On Sun, Feb 26, 2017 at 09:45:04PM +0800, Eva Rachel Retuya wrote: > Add the device tree binding documentation for the ADXL345 3-axis digital > accelerometer. Use "dt-bindings: iio: accel: ..." for the subject prefix. > > Signed-off-by: Eva Rachel Retuya > --- >

Re: [PATCH v4 1/4] Documentation: dt-bindings: Document ADXL345 accelerometer binding

On Sun, Feb 26, 2017 at 09:45:04PM +0800, Eva Rachel Retuya wrote: > Add the device tree binding documentation for the ADXL345 3-axis digital > accelerometer. Use "dt-bindings: iio: accel: ..." for the subject prefix. > > Signed-off-by: Eva Rachel Retuya > --- >

Re: [lkp-robot] [x86/mm/ptdump] 243b72aae2: WARNING:at_arch/x86/mm/dump_pagetables.c:#note_page

On 02/28, Masami Hiramatsu wrote: >On Mon, 27 Feb 2017 16:01:34 +0300 >Andrey Ryabinin wrote: > >> On 02/27/2017 04:03 AM, kernel test robot wrote: >> > >> > FYI, we noticed the following commit: >> > >> > commit: 243b72aae28ca1032284028323bb81c9235b15c9

Re: [lkp-robot] [x86/mm/ptdump] 243b72aae2: WARNING:at_arch/x86/mm/dump_pagetables.c:#note_page

On 02/28, Masami Hiramatsu wrote: >On Mon, 27 Feb 2017 16:01:34 +0300 >Andrey Ryabinin wrote: > >> On 02/27/2017 04:03 AM, kernel test robot wrote: >> > >> > FYI, we noticed the following commit: >> > >> > commit: 243b72aae28ca1032284028323bb81c9235b15c9 ("x86/mm/ptdump: Optimize >> > check

Re: [Lsf-pc] [LSF/MM TOPIC] do we really need PG_error at all?

On Tue, 2017-02-28 at 10:32 +1100, NeilBrown wrote: > On Mon, Feb 27 2017, Andreas Dilger wrote: > > > > > My thought is that PG_error is definitely useful for applications to get > > correct errors back when doing write()/sync_file_range() so that they know > > there is an error in the data

Re: [Lsf-pc] [LSF/MM TOPIC] do we really need PG_error at all?

On Tue, 2017-02-28 at 10:32 +1100, NeilBrown wrote: > On Mon, Feb 27 2017, Andreas Dilger wrote: > > > > > My thought is that PG_error is definitely useful for applications to get > > correct errors back when doing write()/sync_file_range() so that they know > > there is an error in the data

Re: [PATCH] KVM: Prevent double-free on HPT resize commit path

On Wed, Feb 15, 2017 at 02:40:04PM +1100, David Gibson wrote: > resize_hpt_release(), called once the HPT resize of a KVM guest is > completed (successfully or unsuccessfully) free()s the state structure for > the resize. It is currently not safe to call with a NULL pointer. > > However, one of

Re: [PATCH] KVM: Prevent double-free on HPT resize commit path

On Wed, Feb 15, 2017 at 02:40:04PM +1100, David Gibson wrote: > resize_hpt_release(), called once the HPT resize of a KVM guest is > completed (successfully or unsuccessfully) free()s the state structure for > the resize. It is currently not safe to call with a NULL pointer. > > However, one of

Re: [PATCH v4 1/4] Documentation: devicetree: Add document bindings for leds-mt6323

On Sat, Feb 25, 2017 at 02:47:18AM +0800, sean.w...@mediatek.com wrote: > From: Sean Wang > > This patch adds documentation for devicetree bindings > for LED support on MT6323 PMIC Also, please use "dt-bindings: leds: ..." for the subject prefix. > > Signed-off-by:

Re: [PATCH v4 1/4] Documentation: devicetree: Add document bindings for leds-mt6323

On Sat, Feb 25, 2017 at 02:47:18AM +0800, sean.w...@mediatek.com wrote: > From: Sean Wang > > This patch adds documentation for devicetree bindings > for LED support on MT6323 PMIC Also, please use "dt-bindings: leds: ..." for the subject prefix. > > Signed-off-by: Sean Wang > --- >

Re: [PATCH 0/2] key payload access with just rcu_read_lock()

Jan Stancek wrote: > Looks like there are still couple users that need updating, > I'm hitting following compilation error: Aargh - I remembered to grep for rcu_dereference_key() but not user_key_payload(). How about the attached? David --- commit

Re: [PATCH 0/2] key payload access with just rcu_read_lock()

Jan Stancek wrote: > Looks like there are still couple users that need updating, > I'm hitting following compilation error: Aargh - I remembered to grep for rcu_dereference_key() but not user_key_payload(). How about the attached? David --- commit f0268360a253f0f86b9ec538ae3755e187229bbb

Re: [PATCH] [media] tw5864: handle unknown video std gracefully

Hi Arnd, Thanks for sending this patch. On Mon, Feb 27, 2017 at 09:32:34PM +0100, Arnd Bergmann wrote: > tw5864_frameinterval_get() only initializes its output when it successfully > identifies the video standard in tw5864_input. We get a warning here because > gcc can't always track the state

Re: [PATCH] [media] tw5864: handle unknown video std gracefully

Hi Arnd, Thanks for sending this patch. On Mon, Feb 27, 2017 at 09:32:34PM +0100, Arnd Bergmann wrote: > tw5864_frameinterval_get() only initializes its output when it successfully > identifies the video standard in tw5864_input. We get a warning here because > gcc can't always track the state

Re: [PATCH v2 2/2] efi: efi_mem_reserve(): don't reserve through memblock after mm_init()

On Mon, 09 Jan, at 01:31:52PM, Mel Gorman wrote: > > Well, you could put in a __init global variable about availability into > mm/memblock.c and then check it in memblock APIs like memblock_reserve() > to BUG_ON? I know BUG_ON is frowned upon but this is not likely to be a > situation that can be

Re: [PATCH v2 2/2] efi: efi_mem_reserve(): don't reserve through memblock after mm_init()

On Mon, 09 Jan, at 01:31:52PM, Mel Gorman wrote: > > Well, you could put in a __init global variable about availability into > mm/memblock.c and then check it in memblock APIs like memblock_reserve() > to BUG_ON? I know BUG_ON is frowned upon but this is not likely to be a > situation that can be

Re: [PATCH] bcm2048: Fix checkpatch checks

On Mon, Feb 27, 2017 at 4:21 PM, Greg Kroah-Hartman wrote: > On Sat, Feb 18, 2017 at 11:52:37AM +0800, Man Choy wrote: >> Fix following checks: >> >> CHECK: Avoid crashing the kernel - try using WARN_ON & recovery code rather >> than BUG() or BUG_ON() >> +

Re: [PATCH] bcm2048: Fix checkpatch checks

On Mon, Feb 27, 2017 at 4:21 PM, Greg Kroah-Hartman wrote: > On Sat, Feb 18, 2017 at 11:52:37AM +0800, Man Choy wrote: >> Fix following checks: >> >> CHECK: Avoid crashing the kernel - try using WARN_ON & recovery code rather >> than BUG() or BUG_ON() >> + BUG_ON((index+2) >=

Re: [PATCH v4 1/4] Documentation: devicetree: Add document bindings for leds-mt6323

On Sun, Feb 26, 2017 at 06:35:11PM +0100, Jacek Anaszewski wrote: > Hi Sean, > > Thanks for the update. I have one comment below. > > On 02/24/2017 07:47 PM, sean.w...@mediatek.com wrote: > > From: Sean Wang > > > > This patch adds documentation for devicetree bindings

Re: [PATCH v4 1/4] Documentation: devicetree: Add document bindings for leds-mt6323

On Sun, Feb 26, 2017 at 06:35:11PM +0100, Jacek Anaszewski wrote: > Hi Sean, > > Thanks for the update. I have one comment below. > > On 02/24/2017 07:47 PM, sean.w...@mediatek.com wrote: > > From: Sean Wang > > > > This patch adds documentation for devicetree bindings > > for LED support on

Re: [PATCH] speakup: synth: Fix checkpatch warning

On Mon, Feb 27, 2017 at 10:42 PM, Greg KH wrote: > On Sun, Feb 26, 2017 at 01:22:18PM +0800, Man Choy wrote: >> Fix following checkpatch warning: >> >> WARNING: line over 80 characters >> +>attributes) >> < 0) >>

Re: [PATCH] speakup: synth: Fix checkpatch warning

On Mon, Feb 27, 2017 at 10:42 PM, Greg KH wrote: > On Sun, Feb 26, 2017 at 01:22:18PM +0800, Man Choy wrote: >> Fix following checkpatch warning: >> >> WARNING: line over 80 characters >> +>attributes) >> < 0) >> >> total: 0 errors, 1

Re: [PATCH v2] Input: pwm-beeper: support customized freq for SND_BELL

On Mon, Feb 20, 2017 at 09:37:43AM +0100, Heiko Schocher wrote: > From: Guan Ben > > extend the pwm-beeper driver to support customized frequency > for SND_BELL from device tree. > > Signed-off-by: Guan Ben > Signed-off-by: Mark Jonas

Re: [PATCH v2] Input: pwm-beeper: support customized freq for SND_BELL

On Mon, Feb 20, 2017 at 09:37:43AM +0100, Heiko Schocher wrote: > From: Guan Ben > > extend the pwm-beeper driver to support customized frequency > for SND_BELL from device tree. > > Signed-off-by: Guan Ben > Signed-off-by: Mark Jonas > [h...@denx.de: adapted to 4.10-rc7] > Signed-off-by:

[RFC PATCH] uapi: move struct reiserfs_security_handle out from linux/reiserfs_xattr.h

As there seems to be no way struct reiserfs_security_handle could be passed between the kernel and userspace, move its definition from the UAPI header to a private header fs/reiserfs/xattr.h which is the only file in the tree that includes linux/reiserfs_xattr.h. This also fixes the following

[RFC PATCH] uapi: move struct reiserfs_security_handle out from linux/reiserfs_xattr.h

As there seems to be no way struct reiserfs_security_handle could be passed between the kernel and userspace, move its definition from the UAPI header to a private header fs/reiserfs/xattr.h which is the only file in the tree that includes linux/reiserfs_xattr.h. This also fixes the following

Re: [Outreachy kernel] [PATCH 3/5] staging: rtl8712: Remove unnecessary else after return

On Mon, 27 Feb 2017, simran singhal wrote: > This patch fixes the checkpatch warning that else is not generally > useful after a break or return. > > This was done using Coccinelle: > @@ > expression e2; > statement s1; > @@ > if(e2) { ... return ...; } > -else > s1 One might be

Re: [Outreachy kernel] [PATCH 3/5] staging: rtl8712: Remove unnecessary else after return

On Mon, 27 Feb 2017, simran singhal wrote: > This patch fixes the checkpatch warning that else is not generally > useful after a break or return. > > This was done using Coccinelle: > @@ > expression e2; > statement s1; > @@ > if(e2) { ... return ...; } > -else > s1 One might be

Re: [Regression?] 1ea0ce4069 ("selinux: allow changing labels for cgroupfs") stops Android from booting

On Mon, 2017-02-27 at 12:48 -0800, Nick Kralevich wrote: > On Mon, Feb 27, 2017 at 11:53 AM, Stephen Smalley > wrote: > > > > > > > > I can reproduce it on angler (with a back-port of just that > > > patch), > > > although I am unclear on the cause.  The patch is only

Re: [Regression?] 1ea0ce4069 ("selinux: allow changing labels for cgroupfs") stops Android from booting

On Mon, 2017-02-27 at 12:48 -0800, Nick Kralevich wrote: > On Mon, Feb 27, 2017 at 11:53 AM, Stephen Smalley > wrote: > > > > > > > > I can reproduce it on angler (with a back-port of just that > > > patch), > > > although I am unclear on the cause.  The patch is only supposed > > > to > > >

Re: [PATCH V3 1/7] PM / Domains: Introduce "performance-states" binding

On Fri, Feb 24, 2017 at 02:36:33PM +0530, Viresh Kumar wrote: > Some platforms have the capability to configure the performance state of > their power domains. The process of configuring the performance state is > pretty much platform dependent and we may need to work with a wide range > of

Re: [PATCH V3 1/7] PM / Domains: Introduce "performance-states" binding

On Fri, Feb 24, 2017 at 02:36:33PM +0530, Viresh Kumar wrote: > Some platforms have the capability to configure the performance state of > their power domains. The process of configuring the performance state is > pretty much platform dependent and we may need to work with a wide range > of

[BUG] ACPI Error: Needed type [Reference], found [Integer]

Latest Linux git has ACPI errors on Macbook IVB: [0.333133] ACPI Error: Needed type [Reference], found [Integer] 880261656f30 (20170119/exresop-103) [0.333141] ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [Store] (20170119/dswexec-461) [0.333150] ACPI Error:

Re: [LSF/MM TOPIC] do we really need PG_error at all?

On Mon, 2017-02-27 at 15:51 -0700, Andreas Dilger wrote: > On Feb 27, 2017, at 8:07 AM, Jeff Layton wrote: > > > > On Mon, 2017-02-27 at 11:27 +1100, NeilBrown wrote: > > > On Sun, Feb 26 2017, James Bottomley wrote: > > > > > > > On Mon, 2017-02-27 at 08:03 +1100, NeilBrown

[BUG] ACPI Error: Needed type [Reference], found [Integer]

Latest Linux git has ACPI errors on Macbook IVB: [0.333133] ACPI Error: Needed type [Reference], found [Integer] 880261656f30 (20170119/exresop-103) [0.333141] ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [Store] (20170119/dswexec-461) [0.333150] ACPI Error:

Re: [LSF/MM TOPIC] do we really need PG_error at all?

On Mon, 2017-02-27 at 15:51 -0700, Andreas Dilger wrote: > On Feb 27, 2017, at 8:07 AM, Jeff Layton wrote: > > > > On Mon, 2017-02-27 at 11:27 +1100, NeilBrown wrote: > > > On Sun, Feb 26 2017, James Bottomley wrote: > > > > > > > On Mon, 2017-02-27 at 08:03 +1100, NeilBrown wrote: > > > > > On

Re: [PATCH v2 4/5] ARM64: dts: Prepare Realtek RTD1295 and Zidoo X9S

On Thu, Feb 23, 2017 at 05:45:51PM +0100, Andreas Färber wrote: > Add initial device trees for the RTD1295 SoC and the Zidoo X9S TV box. > > The CPUs lack the enable-method property because the vendor device tree > uses a custom "rtk-spin-table" method and "psci" did not appear to work. > > The

Re: [PATCH v2 4/5] ARM64: dts: Prepare Realtek RTD1295 and Zidoo X9S

On Thu, Feb 23, 2017 at 05:45:51PM +0100, Andreas Färber wrote: > Add initial device trees for the RTD1295 SoC and the Zidoo X9S TV box. > > The CPUs lack the enable-method property because the vendor device tree > uses a custom "rtk-spin-table" method and "psci" did not appear to work. > > The

Re: [Regression?] 1ea0ce4069 ("selinux: allow changing labels for cgroupfs") stops Android from booting

On Mon, Feb 27, 2017 at 11:53 AM, Stephen Smalley wrote: >> I can reproduce it on angler (with a back-port of just that patch), >> although I am unclear on the cause. The patch is only supposed to >> enable explicit setting of security labels by userspace on cgroup >> files,

Re: [Regression?] 1ea0ce4069 ("selinux: allow changing labels for cgroupfs") stops Android from booting

On Mon, Feb 27, 2017 at 11:53 AM, Stephen Smalley wrote: >> I can reproduce it on angler (with a back-port of just that patch), >> although I am unclear on the cause. The patch is only supposed to >> enable explicit setting of security labels by userspace on cgroup >> files, so it isn't supposed

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

On Mon, Feb 27, 2017 at 04:52:06PM +0100, Nicolai Stange wrote: > Hi Abel, > > On Fri, Feb 24 2017, Abel Vesa wrote: > > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > index fda6a46..877df5b 100644 > > --- a/arch/arm/Kconfig > > +++ b/arch/arm/Kconfig > > @@ -55,6 +55,7 @@ config

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

On Mon, Feb 27, 2017 at 04:52:06PM +0100, Nicolai Stange wrote: > Hi Abel, > > On Fri, Feb 24 2017, Abel Vesa wrote: > > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > index fda6a46..877df5b 100644 > > --- a/arch/arm/Kconfig > > +++ b/arch/arm/Kconfig > > @@ -55,6 +55,7 @@ config

Re: [LSF/MM TOPIC] do we really need PG_error at all?

On Feb 27, 2017, at 8:07 AM, Jeff Layton wrote: > > On Mon, 2017-02-27 at 11:27 +1100, NeilBrown wrote: >> On Sun, Feb 26 2017, James Bottomley wrote: >> >>> On Mon, 2017-02-27 at 08:03 +1100, NeilBrown wrote: On Sun, Feb 26 2017, James Bottomley wrote: >

Re: [LSF/MM TOPIC] do we really need PG_error at all?

On Feb 27, 2017, at 8:07 AM, Jeff Layton wrote: > > On Mon, 2017-02-27 at 11:27 +1100, NeilBrown wrote: >> On Sun, Feb 26 2017, James Bottomley wrote: >> >>> On Mon, 2017-02-27 at 08:03 +1100, NeilBrown wrote: On Sun, Feb 26 2017, James Bottomley wrote: > [added linux-scsi and

Re: Crash in -next due to 'objtool: Improve detection of BUG() and other dead ends'

On Mon, Feb 27, 2017 at 03:23:28PM -0800, Guenter Roeck wrote: > Hi Josh, > > On Mon, Feb 27, 2017 at 04:21:14PM -0600, Josh Poimboeuf wrote: > > On Mon, Feb 27, 2017 at 12:59:23PM -0800, Guenter Roeck wrote: > > > Hi, > > > > > > my qemu tests for mips64 in -next fail as follows. > > > > > >

Re: Crash in -next due to 'objtool: Improve detection of BUG() and other dead ends'

On Mon, Feb 27, 2017 at 03:23:28PM -0800, Guenter Roeck wrote: > Hi Josh, > > On Mon, Feb 27, 2017 at 04:21:14PM -0600, Josh Poimboeuf wrote: > > On Mon, Feb 27, 2017 at 12:59:23PM -0800, Guenter Roeck wrote: > > > Hi, > > > > > > my qemu tests for mips64 in -next fail as follows. > > > > > >

Re: [PATCH v2 02/17] dt-bindings: arm: Document Actions Semi S500

On Fri, Feb 24, 2017 at 04:40:40AM +0100, Andreas Färber wrote: > The Actions Semi S500 is a quad-core ARM Cortex-A9 SoC. > The LeMaker Guitar is an SODIMM-format module with that SoC. > > Signed-off-by: Andreas Färber > --- > v1 -> v2: > * Adopted "actions" vendor prefix >

Re: [PATCH v2 02/17] dt-bindings: arm: Document Actions Semi S500

On Fri, Feb 24, 2017 at 04:40:40AM +0100, Andreas Färber wrote: > The Actions Semi S500 is a quad-core ARM Cortex-A9 SoC. > The LeMaker Guitar is an SODIMM-format module with that SoC. > > Signed-off-by: Andreas Färber > --- > v1 -> v2: > * Adopted "actions" vendor prefix > * Extended text >

Re: [PATCH v2 01/17] dt-bindings: Add vendor prefix for Actions Semi

On Mon, Feb 27, 2017 at 03:57:19PM +0100, Andreas Färber wrote: > Am 24.02.2017 um 04:40 schrieb Andreas Färber: > > Actions Semiconductor was listed on NASDAQ as ACTS until Dec 16, 2016. > > > > Cc: mp...@actions-semi.com > > Signed-off-by: Andreas Färber > > --- > > v1 ->

Re: [PATCH v2 01/17] dt-bindings: Add vendor prefix for Actions Semi

On Mon, Feb 27, 2017 at 03:57:19PM +0100, Andreas Färber wrote: > Am 24.02.2017 um 04:40 schrieb Andreas Färber: > > Actions Semiconductor was listed on NASDAQ as ACTS until Dec 16, 2016. > > > > Cc: mp...@actions-semi.com > > Signed-off-by: Andreas Färber > > --- > > v1 -> v2: > > * Reverted

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