[PATCH v2 1/7] iio: inv_mpu6050: Do burst reads using spi/i2c directly

Using regmap_read_bulk is wrong because it assumes that a range of registers is being read. In our case reading from the fifo register will return multiple values but this is *not* auto-increment. This currently works by accident. Signed-off-by: Crestez Dan Leonard

[PATCH v2 1/7] iio: inv_mpu6050: Do burst reads using spi/i2c directly

Using regmap_read_bulk is wrong because it assumes that a range of registers is being read. In our case reading from the fifo register will return multiple values but this is *not* auto-increment. This currently works by accident. Signed-off-by: Crestez Dan Leonard ---

Re: [PATCH] ARM: samsung: improve static dma_mask definition

On 05/12/2016 10:38 AM, Arnd Bergmann wrote: > When no DMA master devices are part of the kernel configuration, > we get a warning about the unused dma mask definition: > > arch/arm/plat-samsung/devs.c:71:12: error: 'samsung_device_dma_mask' defined > but not used [-Werror=unused-variable] >

Re: [PATCH] ARM: samsung: improve static dma_mask definition

On 05/12/2016 10:38 AM, Arnd Bergmann wrote: > When no DMA master devices are part of the kernel configuration, > we get a warning about the unused dma mask definition: > > arch/arm/plat-samsung/devs.c:71:12: error: 'samsung_device_dma_mask' defined > but not used [-Werror=unused-variable] >

Re: [PATCH v6 2/8] debugfs: prevent access to removed files' private data

Hi Sasha, Sasha Levin writes: > On 03/22/2016 09:11 AM, Nicolai Stange wrote: >> Upon return of debugfs_remove()/debugfs_remove_recursive(), it might >> still be attempted to access associated private file data through >> previously opened struct file objects. If that

Re: [PATCH v6 2/8] debugfs: prevent access to removed files' private data

Hi Sasha, Sasha Levin writes: > On 03/22/2016 09:11 AM, Nicolai Stange wrote: >> Upon return of debugfs_remove()/debugfs_remove_recursive(), it might >> still be attempted to access associated private file data through >> previously opened struct file objects. If that data has been freed by >>

[PATCH v2 2/7] iio: inv_mpu6050: Initial regcache support

Signed-off-by: Crestez Dan Leonard --- drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 47 ++ drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c | 5 drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h | 1 + drivers/iio/imu/inv_mpu6050/inv_mpu_spi.c |

[PATCH v2 2/7] iio: inv_mpu6050: Initial regcache support

Signed-off-by: Crestez Dan Leonard --- drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 47 ++ drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c | 5 drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h | 1 + drivers/iio/imu/inv_mpu6050/inv_mpu_spi.c | 5 4 files changed,

Re: [PATCH] crypto: public_key: select CRYPTO_AKCIPHER2

On Wednesday 18 May 2016 22:50:31 Herbert Xu wrote: > On Wed, May 18, 2016 at 04:12:44PM +0200, Arnd Bergmann wrote: > > In some rare randconfig builds, we can end up with > > ASYMMETRIC_PUBLIC_KEY_SUBTYPE enabled but CRYPTO_AKCIPHER2 disabled, > > which fails to link because of the reference to

Re: [PATCH] crypto: public_key: select CRYPTO_AKCIPHER2

On Wednesday 18 May 2016 22:50:31 Herbert Xu wrote: > On Wed, May 18, 2016 at 04:12:44PM +0200, Arnd Bergmann wrote: > > In some rare randconfig builds, we can end up with > > ASYMMETRIC_PUBLIC_KEY_SUBTYPE enabled but CRYPTO_AKCIPHER2 disabled, > > which fails to link because of the reference to

[PATCH v2] crypto: public_key: select CRYPTO_AKCIPHER

In some rare randconfig builds, we can end up with ASYMMETRIC_PUBLIC_KEY_SUBTYPE enabled but CRYPTO_AKCIPHER disabled, which fails to link because of the reference to crypto_alloc_akcipher: crypto/built-in.o: In function `public_key_verify_signature': :(.text+0x110e4): undefined reference to

Re: [PATCH] usb: echi-hcd: Add register access check in shutdown

On Wed, 18 May 2016, Srinivas Kandagatla wrote: > This patch adds a check in ehci_shutdown(), to make sure > that the register access is available before accessing registers. > > The use case is simple, for boards like DB410c where the usb host > or device functionality is decided based on the

Re: [PATCH] usb: echi-hcd: Add register access check in shutdown

On Wed, 18 May 2016, Srinivas Kandagatla wrote: > This patch adds a check in ehci_shutdown(), to make sure > that the register access is available before accessing registers. > > The use case is simple, for boards like DB410c where the usb host > or device functionality is decided based on the

[PATCH v2] crypto: public_key: select CRYPTO_AKCIPHER

In some rare randconfig builds, we can end up with ASYMMETRIC_PUBLIC_KEY_SUBTYPE enabled but CRYPTO_AKCIPHER disabled, which fails to link because of the reference to crypto_alloc_akcipher: crypto/built-in.o: In function `public_key_verify_signature': :(.text+0x110e4): undefined reference to

Re: [PATCH] xen: add steal_clock support on x86

On 18/05/16 16:46, Boris Ostrovsky wrote: > On 05/18/2016 08:15 AM, Juergen Gross wrote: >> } >> >> +void __init xen_time_setup_guest(void) >> +{ >> +pv_time_ops.steal_clock = xen_steal_clock; >> + >> +static_key_slow_inc(_steal_enabled); >> +/* >> + * We can't set

Re: [PATCH] xen: add steal_clock support on x86

On 18/05/16 16:46, Boris Ostrovsky wrote: > On 05/18/2016 08:15 AM, Juergen Gross wrote: >> } >> >> +void __init xen_time_setup_guest(void) >> +{ >> +pv_time_ops.steal_clock = xen_steal_clock; >> + >> +static_key_slow_inc(_steal_enabled); >> +/* >> + * We can't set

Re: [PATCH] crypto: public_key: select CRYPTO_AKCIPHER2

On Wed, May 18, 2016 at 04:12:44PM +0200, Arnd Bergmann wrote: > In some rare randconfig builds, we can end up with > ASYMMETRIC_PUBLIC_KEY_SUBTYPE enabled but CRYPTO_AKCIPHER2 disabled, > which fails to link because of the reference to crypto_alloc_akcipher: This symbol is not meant to be

Re: [PATCH] crypto: public_key: select CRYPTO_AKCIPHER2

On Wed, May 18, 2016 at 04:12:44PM +0200, Arnd Bergmann wrote: > In some rare randconfig builds, we can end up with > ASYMMETRIC_PUBLIC_KEY_SUBTYPE enabled but CRYPTO_AKCIPHER2 disabled, > which fails to link because of the reference to crypto_alloc_akcipher: This symbol is not meant to be

Re: [PATCH] Let chip-driver set brightness if, software blink not used.

On 05/18/2016 12:33 PM, Tony Makkiel wrote: On 18/05/16 10:03, Jacek Anaszewski wrote: Hi Tony, Thanks for the patch. I'd like to improve the commit message. Please let me know if you have any suggestions related to the below: led: core: Fix brightness setting upon hardware blinking

Re: [PATCH] Let chip-driver set brightness if, software blink not used.

On 05/18/2016 12:33 PM, Tony Makkiel wrote: On 18/05/16 10:03, Jacek Anaszewski wrote: Hi Tony, Thanks for the patch. I'd like to improve the commit message. Please let me know if you have any suggestions related to the below: led: core: Fix brightness setting upon hardware blinking

Re: [GIT PULL] move ARM LCD display driver to auxdisplay

On Thu, May 12, 2016 at 12:25 PM, Robin van der Gracht wrote: > First half is completed. I've added myself as maintainer for the > driver I've posted recently (HT16K33 LED CONTROLLER DRIVER). Good! > According to MAINTAINERS, Miguel maintains: > - CFAG12864B LCD DRIVER > -

Re: [GIT PULL] move ARM LCD display driver to auxdisplay

On Thu, May 12, 2016 at 12:25 PM, Robin van der Gracht wrote: > First half is completed. I've added myself as maintainer for the > driver I've posted recently (HT16K33 LED CONTROLLER DRIVER). Good! > According to MAINTAINERS, Miguel maintains: > - CFAG12864B LCD DRIVER > - CFAG12864BFB LCD

[PATCH v3] net: sock: move ->sk_shutdown out of bitfields.

->sk_shutdown bits share one bitfield with some other bits in sock struct, such as ->sk_no_check_[r,t]x, ->sk_userlocks ... sock_setsockopt() may write to these bits, while holding the socket lock. In case of AF_UNIX sockets, we change ->sk_shutdown bits while holding only unix_state_lock(). So

[PATCH v3] net: sock: move ->sk_shutdown out of bitfields.

->sk_shutdown bits share one bitfield with some other bits in sock struct, such as ->sk_no_check_[r,t]x, ->sk_userlocks ... sock_setsockopt() may write to these bits, while holding the socket lock. In case of AF_UNIX sockets, we change ->sk_shutdown bits while holding only unix_state_lock(). So

Re: [PATCH v6 2/8] debugfs: prevent access to removed files' private data

On 03/22/2016 09:11 AM, Nicolai Stange wrote: > Upon return of debugfs_remove()/debugfs_remove_recursive(), it might > still be attempted to access associated private file data through > previously opened struct file objects. If that data has been freed by > the caller of debugfs_remove*() in the

Re: [PATCH v6 2/8] debugfs: prevent access to removed files' private data

On 03/22/2016 09:11 AM, Nicolai Stange wrote: > Upon return of debugfs_remove()/debugfs_remove_recursive(), it might > still be attempted to access associated private file data through > previously opened struct file objects. If that data has been freed by > the caller of debugfs_remove*() in the

[PATCH 1/2] MIPS: Add definitions of SegCtl registers and use them

The SegCtl registers are standard for MIPSr3..MIPSr5. Add definitions of these registers and use them rather than constants Signed-off-by: Matt Redfearn --- arch/mips/include/asm/mach-malta/kernel-entry-init.h | 6 +++--- arch/mips/include/asm/mipsregs.h

Re: [PATCH] xen: add steal_clock support on x86

On 05/18/2016 08:15 AM, Juergen Gross wrote: > } > > +void __init xen_time_setup_guest(void) > +{ > + pv_time_ops.steal_clock = xen_steal_clock; > + > + static_key_slow_inc(_steal_enabled); > + /* > + * We can't set paravirt_steal_rq_enabled as this would require the > + *

[PATCH 1/2] MIPS: Add definitions of SegCtl registers and use them

The SegCtl registers are standard for MIPSr3..MIPSr5. Add definitions of these registers and use them rather than constants Signed-off-by: Matt Redfearn --- arch/mips/include/asm/mach-malta/kernel-entry-init.h | 6 +++--- arch/mips/include/asm/mipsregs.h | 3 +++ 2 files

Re: [PATCH] xen: add steal_clock support on x86

On 05/18/2016 08:15 AM, Juergen Gross wrote: > } > > +void __init xen_time_setup_guest(void) > +{ > + pv_time_ops.steal_clock = xen_steal_clock; > + > + static_key_slow_inc(_steal_enabled); > + /* > + * We can't set paravirt_steal_rq_enabled as this would require the > + *

RE: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core

> >> > >> I didn't want to have complex Kconfig so decided to have otg as > >> built-in only. > >> What do you want me to change in existing code? and why? > > > > Remove those stuff which only for pass diff driver config Like every > > controller driver need a duplicated > > > > static struct

RE: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core

> >> > >> I didn't want to have complex Kconfig so decided to have otg as > >> built-in only. > >> What do you want me to change in existing code? and why? > > > > Remove those stuff which only for pass diff driver config Like every > > controller driver need a duplicated > > > > static struct

[PATCH 2/2] MIPS: CPS: Copy EVA configuration when starting secondary VPs.

When starting secondary VPEs which support EVA and the SegCtl registers, copy the memory segmentation configuration from the running VPE to ensure that all VPEs in the core have a consitent virtual memory map. The EVA configuration of secondary cores is dealt with when starting the core via the

[PATCH 2/2] MIPS: CPS: Copy EVA configuration when starting secondary VPs.

When starting secondary VPEs which support EVA and the SegCtl registers, copy the memory segmentation configuration from the running VPE to ensure that all VPEs in the core have a consitent virtual memory map. The EVA configuration of secondary cores is dealt with when starting the core via the

[PATCH] xen: use same main loop for counting and remapping pages

Instead of having two functions for cycling through the E820 map in order to count to be remapped pages and remap them later, just use one function with a caller supplied sub-function called for each region to be processed. This eliminates the possibility of a mismatch between both loops which

[PATCH] xen: use same main loop for counting and remapping pages

Instead of having two functions for cycling through the E820 map in order to count to be remapped pages and remap them later, just use one function with a caller supplied sub-function called for each region to be processed. This eliminates the possibility of a mismatch between both loops which

Re: Linux-next parallel cp workload hang

On Wed, May 18, 2016 at 07:46:17PM +0800, Xiong Zhou wrote: > > On Wed, May 18, 2016 at 07:54:09PM +1000, Dave Chinner wrote: > > On Wed, May 18, 2016 at 04:31:50PM +0800, Xiong Zhou wrote: > > > Hi, > > > > > > On Wed, May 18, 2016 at 03:56:34PM +1000, Dave Chinner wrote: > > > > On Wed, May

Re: Linux-next parallel cp workload hang

On Wed, May 18, 2016 at 07:46:17PM +0800, Xiong Zhou wrote: > > On Wed, May 18, 2016 at 07:54:09PM +1000, Dave Chinner wrote: > > On Wed, May 18, 2016 at 04:31:50PM +0800, Xiong Zhou wrote: > > > Hi, > > > > > > On Wed, May 18, 2016 at 03:56:34PM +1000, Dave Chinner wrote: > > > > On Wed, May

[PATCH] arm64: dts: rockchip: fixes the gic400 2nd region size for rk3368

The 2nd additional region is the GIC virtual cpu interface register base and size. As the gic400 of rk3368 says, the cpu interface register map as below : -0x GICC_CTRL . . . -0x00fc GICC_IIDR -0x1000 GICC_IDR Obviously, the region size should be greater than 0x1000. So we should make sure

[PATCH] arm64: dts: rockchip: fixes the gic400 2nd region size for rk3368

The 2nd additional region is the GIC virtual cpu interface register base and size. As the gic400 of rk3368 says, the cpu interface register map as below : -0x GICC_CTRL . . . -0x00fc GICC_IIDR -0x1000 GICC_IDR Obviously, the region size should be greater than 0x1000. So we should make sure

Re: [RFC 13/13] mm, compaction: fix and improve watermark handling

On Wed, May 18, 2016 at 04:27:53PM +0200, Michal Hocko wrote: > > > > - __compaction_suitable() then checks the low watermark plus a (2 << > > > > order) gap > > > > to decide if there's enough free memory to perform compaction. This > > > > check > > > > > > And this was a real head

Re: [RFC 13/13] mm, compaction: fix and improve watermark handling

On Wed, May 18, 2016 at 04:27:53PM +0200, Michal Hocko wrote: > > > > - __compaction_suitable() then checks the low watermark plus a (2 << > > > > order) gap > > > > to decide if there's enough free memory to perform compaction. This > > > > check > > > > > > And this was a real head

Re: UBSAN whinge in ihci-hub.c

On Wed, 18 May 2016, Andrey Ryabinin wrote: > 2016-05-18 13:19 GMT+03:00 Oliver Neukum : > > On Wed, 2016-05-18 at 12:16 +0300, Andrey Ryabinin wrote: > >> 2016-05-18 11:18 GMT+03:00 Oliver Neukum : > >> > On Wed, 2016-05-18 at 10:40 +0300, Andrey Ryabinin

Re: UBSAN whinge in ihci-hub.c

On Wed, 18 May 2016, Andrey Ryabinin wrote: > 2016-05-18 13:19 GMT+03:00 Oliver Neukum : > > On Wed, 2016-05-18 at 12:16 +0300, Andrey Ryabinin wrote: > >> 2016-05-18 11:18 GMT+03:00 Oliver Neukum : > >> > On Wed, 2016-05-18 at 10:40 +0300, Andrey Ryabinin wrote: > >> >> 2016-05-18 1:16 GMT+03:00

Re: [PATCH omap v2 0/6] Fix OMAP uses of RCU from idle loop

On 05/16/2016 11:48 AM, Paul E. McKenney wrote: Hello! The following series fixes a number of uses of RCU from the idle loop. These are all due to tracing, so the fix is simply to append _rcuidle to the event-tracing call. Changes since v1: Fix commit-log subjects and add maintainers on CC.

Re: [PATCH omap v2 0/6] Fix OMAP uses of RCU from idle loop

On 05/16/2016 11:48 AM, Paul E. McKenney wrote: Hello! The following series fixes a number of uses of RCU from the idle loop. These are all due to tracing, so the fix is simply to append _rcuidle to the event-tracing call. Changes since v1: Fix commit-log subjects and add maintainers on CC.

Re: [linux310][linux316] Backport of 'compiler-gcc: integrate the various compiler-gcc[345].h'

Hi Philip, On Tue, May 17, 2016 at 04:38:11PM +0200, Philip Müller wrote: > Hi Willy, hi Ben, > > I've backported the 'compiler-gcc: integrate the various > compiler-gcc[345].h' patch to support gcc 6.1 series also for linux 3.10 > and 3.16 stable series. Now queued for 3.10, thanks! willy

Re: [linux310][linux316] Backport of 'compiler-gcc: integrate the various compiler-gcc[345].h'

Hi Philip, On Tue, May 17, 2016 at 04:38:11PM +0200, Philip Müller wrote: > Hi Willy, hi Ben, > > I've backported the 'compiler-gcc: integrate the various > compiler-gcc[345].h' patch to support gcc 6.1 series also for linux 3.10 > and 3.16 stable series. Now queued for 3.10, thanks! willy

Re: [PATCH v3 0/2] nvmem: remove regmap dependency

On 18/05/16 15:30, Stefan Wahren wrote: Hi Srinivas, Am 02.05.2016 um 20:36 schrieb Srinivas Kandagatla: Hi Greg, This is v3 patchset for the leftover 2 patches for nvmem regmap removal series [1]. These patches are based on char-misc tree. nvmem uses regmap_raw_read/write apis to

Re: [PATCH v3 0/2] nvmem: remove regmap dependency

On 18/05/16 15:30, Stefan Wahren wrote: Hi Srinivas, Am 02.05.2016 um 20:36 schrieb Srinivas Kandagatla: Hi Greg, This is v3 patchset for the leftover 2 patches for nvmem regmap removal series [1]. These patches are based on char-misc tree. nvmem uses regmap_raw_read/write apis to

Re: [RFC 13/13] mm, compaction: fix and improve watermark handling

On Wed 18-05-16 14:50:04, Mel Gorman wrote: > On Mon, May 16, 2016 at 11:25:05AM +0200, Michal Hocko wrote: > > On Tue 10-05-16 09:36:03, Vlastimil Babka wrote: > > > Compaction has been using watermark checks when deciding whether it was > > > successful, and whether compaction is at all

Re: [RFC 13/13] mm, compaction: fix and improve watermark handling

On Wed 18-05-16 14:50:04, Mel Gorman wrote: > On Mon, May 16, 2016 at 11:25:05AM +0200, Michal Hocko wrote: > > On Tue 10-05-16 09:36:03, Vlastimil Babka wrote: > > > Compaction has been using watermark checks when deciding whether it was > > > successful, and whether compaction is at all

Re: [PATCH v6 3/3] MAINTAINERS: auxdisplay: Added myself as maintainer for ht16k33 driver

On Wed, May 18, 2016 at 2:23 PM, Robin van der Gracht wrote: > Signed-off-by: Robin van der Gracht Acked-by: Linus Walleij Yours, Linus Walleij

Re: [PATCH v6 3/3] MAINTAINERS: auxdisplay: Added myself as maintainer for ht16k33 driver

On Wed, May 18, 2016 at 2:23 PM, Robin van der Gracht wrote: > Signed-off-by: Robin van der Gracht Acked-by: Linus Walleij Yours, Linus Walleij

Re: [PATCH] ftrace/x86: Set ftrace_stub to weak to prevent gcc from using short jumps to it

Ingo, Did you want to take this patch through the tip tree, or do you want me to take it? Thanks, -- Steve On Mon, 16 May 2016 23:00:35 -0400 Steven Rostedt wrote: > Matt Fleming reported seeing crashes when enabling and disabling > function profiling which uses

Re: [PATCH] ftrace/x86: Set ftrace_stub to weak to prevent gcc from using short jumps to it

Ingo, Did you want to take this patch through the tip tree, or do you want me to take it? Thanks, -- Steve On Mon, 16 May 2016 23:00:35 -0400 Steven Rostedt wrote: > Matt Fleming reported seeing crashes when enabling and disabling > function profiling which uses function graph tracer.

Re: [RFC 1/8] dma-buf/fence: add fence_collection fences

Hi Christian, 2016-05-18 Christian König : > Am 15.04.2016 um 21:25 schrieb Daniel Vetter: > > On Fri, Apr 15, 2016 at 11:27:50AM -0700, Gustavo Padovan wrote: > > > 2016-04-15 Christian König : > > > > Amdgpu also has an implementation for a

Re: [RFC 1/8] dma-buf/fence: add fence_collection fences

Hi Christian, 2016-05-18 Christian König : > Am 15.04.2016 um 21:25 schrieb Daniel Vetter: > > On Fri, Apr 15, 2016 at 11:27:50AM -0700, Gustavo Padovan wrote: > > > 2016-04-15 Christian König : > > > > Amdgpu also has an implementation for a fence collection which uses a a > > > > hashtable to

Re: [PATCH v3 0/2] nvmem: remove regmap dependency

Hi Srinivas, Am 02.05.2016 um 20:36 schrieb Srinivas Kandagatla: > Hi Greg, > > This is v3 patchset for the leftover 2 patches for nvmem regmap > removal series [1]. These patches are based on char-misc tree. > > nvmem uses regmap_raw_read/write apis to read/write data from providers, > With

Re: [PATCH v3 0/2] nvmem: remove regmap dependency

Hi Srinivas, Am 02.05.2016 um 20:36 schrieb Srinivas Kandagatla: > Hi Greg, > > This is v3 patchset for the leftover 2 patches for nvmem regmap > removal series [1]. These patches are based on char-misc tree. > > nvmem uses regmap_raw_read/write apis to read/write data from providers, > With

Re: SCHED_DEADLINE cpudeadline.{h,c} fixup

Hi Tommaso, On 18/05/16 00:43, Tommaso Cucinotta wrote: > On 17/05/2016 13:46, luca abeni wrote: > >Maybe the ... change can be split in a separate > >patch, which is a bugfix (and IMHO uncontroversial)? > > Ok, the bugfix alone might look like the attached. Couldn't avoid > the little

Re: SCHED_DEADLINE cpudeadline.{h,c} fixup

Hi Tommaso, On 18/05/16 00:43, Tommaso Cucinotta wrote: > On 17/05/2016 13:46, luca abeni wrote: > >Maybe the ... change can be split in a separate > >patch, which is a bugfix (and IMHO uncontroversial)? > > Ok, the bugfix alone might look like the attached. Couldn't avoid > the little

[PATCH] mlx5: avoid unused variable warning

When CONFIG_NET_CLS_ACT is disabled, we get a new warning in the mlx5 ethernet driver because the tc_for_each_action() loop never references the iterator: mellanox/mlx5/core/en_tc.c: In function 'mlx5e_stats_flower': mellanox/mlx5/core/en_tc.c:431:20: error: unused variable 'a'

[PATCH] mlx5: avoid unused variable warning

When CONFIG_NET_CLS_ACT is disabled, we get a new warning in the mlx5 ethernet driver because the tc_for_each_action() loop never references the iterator: mellanox/mlx5/core/en_tc.c: In function 'mlx5e_stats_flower': mellanox/mlx5/core/en_tc.c:431:20: error: unused variable 'a'

Re: linux-next: manual merge of the vfs tree with the ext4 tree

On Tuesday 17 May 2016 10:23:55 Stephen Rothwell wrote: > ++static ssize_t ext4_direct_IO_read(struct kiocb *iocb, struct iov_iter > *iter) > +{ > + int unlocked = 0; > + struct inode *inode = iocb->ki_filp->f_mapping->host; > ++ loff_t offset = iocb->ki_pos; > + ssize_t

Re: linux-next: manual merge of the vfs tree with the ext4 tree

On Tuesday 17 May 2016 10:23:55 Stephen Rothwell wrote: > ++static ssize_t ext4_direct_IO_read(struct kiocb *iocb, struct iov_iter > *iter) > +{ > + int unlocked = 0; > + struct inode *inode = iocb->ki_filp->f_mapping->host; > ++ loff_t offset = iocb->ki_pos; > + ssize_t

Re: [GIT] Networking

On Wed, 2016-05-18 at 06:51 -0600, Reinoud Koornstra wrote: > On Wed, May 18, 2016 at 6:41 AM, Coelho, Luciano > wrote: > > > > On Wed, 2016-05-18 at 06:20 -0600, Reinoud Koornstra wrote: > > > > > > On Wed, May 18, 2016 at 4:51 AM, Coelho, Luciano > > >

Re: [GIT] Networking

On Wed, 2016-05-18 at 06:51 -0600, Reinoud Koornstra wrote: > On Wed, May 18, 2016 at 6:41 AM, Coelho, Luciano > wrote: > > > > On Wed, 2016-05-18 at 06:20 -0600, Reinoud Koornstra wrote: > > > > > > On Wed, May 18, 2016 at 4:51 AM, Coelho, Luciano > > > wrote: > > > > > > > > > > > > Hi

[PATCH] ARM: exynos: don't select keyboard driver

The samsung-keypad driver is implicitly selected by ARCH_EXYNOS4 (why?), but this fails if CONFIG_INPUT is a loadable module: drivers/input/built-in.o: In function `samsung_keypad_remove': drivers/input/keyboard/samsung-keypad.c:461: undefined reference to `input_unregister_device'

[PATCH] ARM: exynos: don't select keyboard driver

The samsung-keypad driver is implicitly selected by ARCH_EXYNOS4 (why?), but this fails if CONFIG_INPUT is a loadable module: drivers/input/built-in.o: In function `samsung_keypad_remove': drivers/input/keyboard/samsung-keypad.c:461: undefined reference to `input_unregister_device'

Re: 4.5-rc0 regression: GPRS breaks after very short while

Hi Pavel, On Wed, May 18, 2016 at 09:49:24AM +0200, Pavel Machek wrote: > I was afraid another GSM chip desoldered itself in N900, but no, it > seems to be software this time. > > In 4.4, GPRS is rock solid, can survive overnight ping. > > In 4.5-rc0 and v4.6, modem fails when I use gprs for

[PATCH] PCI: host-generic: select IRQ_DOMAIN

The generic PCI host controller calls of_irq_parse_and_map_pci in its IRQ fixup, but that function is only available when CONFIG_IRQ_DOMAIN is set: drivers/pci/built-in.o: In function `pci_host_common_probe': drivers/pci/host/pci-host-common.c:181: undefined reference to

Re: 4.5-rc0 regression: GPRS breaks after very short while

Hi Pavel, On Wed, May 18, 2016 at 09:49:24AM +0200, Pavel Machek wrote: > I was afraid another GSM chip desoldered itself in N900, but no, it > seems to be software this time. > > In 4.4, GPRS is rock solid, can survive overnight ping. > > In 4.5-rc0 and v4.6, modem fails when I use gprs for

[PATCH] PCI: host-generic: select IRQ_DOMAIN

The generic PCI host controller calls of_irq_parse_and_map_pci in its IRQ fixup, but that function is only available when CONFIG_IRQ_DOMAIN is set: drivers/pci/built-in.o: In function `pci_host_common_probe': drivers/pci/host/pci-host-common.c:181: undefined reference to

Re: general protection fault (btrfs_real_readdir)

On Wed, May 18, 2016 at 01:21:14PM +0100, Al Viro wrote: > On Wed, May 18, 2016 at 01:31:40PM +0200, Markus Trippelsdorf wrote: > > I'm running the latest Linus git tree and the parallel filesystem directory > > handling update seems to cause the following issue: > > > Call Trace: > > [] ?

Re: general protection fault (btrfs_real_readdir)

On Wed, May 18, 2016 at 01:21:14PM +0100, Al Viro wrote: > On Wed, May 18, 2016 at 01:31:40PM +0200, Markus Trippelsdorf wrote: > > I'm running the latest Linus git tree and the parallel filesystem directory > > handling update seems to cause the following issue: > > > Call Trace: > > [] ?

[PATCH] usb: echi-hcd: Add register access check in shutdown

This patch adds a check in ehci_shutdown(), to make sure that the register access is available before accessing registers. The use case is simple, for boards like DB410c where the usb host or device functionality is decided based on the micro-usb cable presence. If the board boots up with

[PATCH] usb: echi-hcd: Add register access check in shutdown

This patch adds a check in ehci_shutdown(), to make sure that the register access is available before accessing registers. The use case is simple, for boards like DB410c where the usb host or device functionality is decided based on the micro-usb cable presence. If the board boots up with

[PATCH] crypto: public_key: select CRYPTO_AKCIPHER2

In some rare randconfig builds, we can end up with ASYMMETRIC_PUBLIC_KEY_SUBTYPE enabled but CRYPTO_AKCIPHER2 disabled, which fails to link because of the reference to crypto_alloc_akcipher: crypto/built-in.o: In function `public_key_verify_signature': :(.text+0x110e4): undefined reference to

[PATCH] crypto: public_key: select CRYPTO_AKCIPHER2

In some rare randconfig builds, we can end up with ASYMMETRIC_PUBLIC_KEY_SUBTYPE enabled but CRYPTO_AKCIPHER2 disabled, which fails to link because of the reference to crypto_alloc_akcipher: crypto/built-in.o: In function `public_key_verify_signature': :(.text+0x110e4): undefined reference to

Re: [RFC PATCH 1/3] asm-generic: io: Add exec versions of ioremap

Hi, On 05/12/2016 11:37 AM, Russell King - ARM Linux wrote: On Mon, May 09, 2016 at 04:41:49PM -0500, Dave Gerlach wrote: diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c index 66a978d05958..c6eef3c98074 100644 --- a/arch/arm/mm/ioremap.c +++ b/arch/arm/mm/ioremap.c @@ -400,6 +400,20

Re: [RFC PATCH 1/3] asm-generic: io: Add exec versions of ioremap

Hi, On 05/12/2016 11:37 AM, Russell King - ARM Linux wrote: On Mon, May 09, 2016 at 04:41:49PM -0500, Dave Gerlach wrote: diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c index 66a978d05958..c6eef3c98074 100644 --- a/arch/arm/mm/ioremap.c +++ b/arch/arm/mm/ioremap.c @@ -400,6 +400,20

Re: [PATCH V2] drm/tegra: Fix crash caused by reference count imbalance

On Wed, May 18, 2016 at 12:11:29PM +0100, Jon Hunter wrote: > Commit d2307dea14a4 ("drm/atomic: use connector references (v3)") added > reference counting for DRM connectors and this caused a crash when > exercising system suspend on Tegra114 Dalmore. > > The Tegra DSI driver implements a Tegra

Re: [PATCH V2] drm/tegra: Fix crash caused by reference count imbalance

On Wed, May 18, 2016 at 12:11:29PM +0100, Jon Hunter wrote: > Commit d2307dea14a4 ("drm/atomic: use connector references (v3)") added > reference counting for DRM connectors and this caused a crash when > exercising system suspend on Tegra114 Dalmore. > > The Tegra DSI driver implements a Tegra

Re: [PATCH] x86/boot: Refuse to build with data relocations

On Wed, May 18, 2016 at 4:29 AM, Ingo Molnar wrote: > > * Kees Cook wrote: > >> > I think there is something way more subtle going on here, and it bothers me >> > exactly because it is subtle. It may be that it is OK right now, but there >> > are alarm

Re: [PATCH] x86/boot: Refuse to build with data relocations

On Wed, May 18, 2016 at 4:29 AM, Ingo Molnar wrote: > > * Kees Cook wrote: > >> > I think there is something way more subtle going on here, and it bothers me >> > exactly because it is subtle. It may be that it is OK right now, but there >> > are alarm bells going on all over my brain on this.

Re: [PATCH] remove unused blkdev_dax_capable() function

On Wed, 2016-05-18 at 09:54 +0200, Arnd Bergmann wrote: > The change from blkdev_dax_capable() to bdev_dax_capable() removed the > only user of the former, so we now get a build warning: > > fs/block_dev.c:1244:13: error: 'blkdev_dax_capable' defined but not used > [-Werror=unused-function] >  

Re: [PATCH] remove unused blkdev_dax_capable() function

On Wed, 2016-05-18 at 09:54 +0200, Arnd Bergmann wrote: > The change from blkdev_dax_capable() to bdev_dax_capable() removed the > only user of the former, so we now get a build warning: > > fs/block_dev.c:1244:13: error: 'blkdev_dax_capable' defined but not used > [-Werror=unused-function] >  

Re: [PATCH v2] mm: check_new_page_bad() directly returns in __PG_HWPOISON case

On Wed, May 18, 2016 at 10:09:50AM +, Naoya Horiguchi wrote: > From c600b1ee6c36b3df6973f5365b4179c92f3c08e3 Mon Sep 17 00:00:00 2001 > From: Naoya Horiguchi > Date: Wed, 18 May 2016 18:42:57 +0900 > Subject: [PATCH v2] mm: check_new_page_bad() directly returns in

Re: [PATCH v2] mm: check_new_page_bad() directly returns in __PG_HWPOISON case

On Wed, May 18, 2016 at 10:09:50AM +, Naoya Horiguchi wrote: > From c600b1ee6c36b3df6973f5365b4179c92f3c08e3 Mon Sep 17 00:00:00 2001 > From: Naoya Horiguchi > Date: Wed, 18 May 2016 18:42:57 +0900 > Subject: [PATCH v2] mm: check_new_page_bad() directly returns in __PG_HWPOISON > case > >

Re: CQ and RDMA READ/WRITE APIs

On 05/17/2016 10:48 PM, Parav Pandit wrote: > Hi Doug, > > On Tue, May 17, 2016 at 11:02 PM, Doug Ledford wrote: >> Nice catch there Bart. That was well before my role as maintainer and >> so settles things well enough for me. IOW, I don't feel I need to worry >> about

Re: CQ and RDMA READ/WRITE APIs

On 05/17/2016 10:48 PM, Parav Pandit wrote: > Hi Doug, > > On Tue, May 17, 2016 at 11:02 PM, Doug Ledford wrote: >> Nice catch there Bart. That was well before my role as maintainer and >> so settles things well enough for me. IOW, I don't feel I need to worry >> about trying to maintain the

Re: [PATCH v4 2/5] locking/rwsem: Protect all writes to owner by WRITE_ONCE()

On Tue, 17 May 2016, Waiman Long wrote: Without using WRITE_ONCE(), the compiler can potentially break a write into multiple smaller ones (store tearing). So a read from the same data by another task concurrently may return a partial result. This can result in a kernel crash if the data is a

Re: [PATCH v4 2/5] locking/rwsem: Protect all writes to owner by WRITE_ONCE()

On Tue, 17 May 2016, Waiman Long wrote: Without using WRITE_ONCE(), the compiler can potentially break a write into multiple smaller ones (store tearing). So a read from the same data by another task concurrently may return a partial result. This can result in a kernel crash if the data is a

Re: [PATCH 12/16] page-flags: define PG_mlocked behavior on compound pages

On Mon, Apr 18, 2016 at 03:44:59PM -0400, Sasha Levin wrote: > On 09/24/2015 10:51 AM, Kirill A. Shutemov wrote: > > Transparent huge pages can be mlocked -- whole compund page at once. > > Something went wrong if we're trying to mlock() tail page. > > Let's use PF_NO_TAIL. > > Kirill, Hugh, > >

Re: [PATCH 12/16] page-flags: define PG_mlocked behavior on compound pages

On Mon, Apr 18, 2016 at 03:44:59PM -0400, Sasha Levin wrote: > On 09/24/2015 10:51 AM, Kirill A. Shutemov wrote: > > Transparent huge pages can be mlocked -- whole compund page at once. > > Something went wrong if we're trying to mlock() tail page. > > Let's use PF_NO_TAIL. > > Kirill, Hugh, > >

Re: [RFT PATCH] iio: magn: Add support for BMM150 magnetometer

On Wed, May 4, 2016 at 1:26 PM, Jonathan Cameron wrote: > On 27/04/16 15:55, Lucas De Marchi wrote: >> On Tue, Apr 26, 2016 at 9:39 AM, Daniel Baluta >> wrote: >>> BMM150 is register compatible with magnetometer part of >>> BMC156. >>> >>> Datasheet is

Re: [RFT PATCH] iio: magn: Add support for BMM150 magnetometer

On Wed, May 4, 2016 at 1:26 PM, Jonathan Cameron wrote: > On 27/04/16 15:55, Lucas De Marchi wrote: >> On Tue, Apr 26, 2016 at 9:39 AM, Daniel Baluta >> wrote: >>> BMM150 is register compatible with magnetometer part of >>> BMC156. >>> >>> Datasheet is at: >>>

[PATCH 02/14] clk: twl6040: Register the clock as of_clk_provider

In order ot be able to use the pdmclk clock via DT it need to be registered as of_clk_provide. Since the twl6040 clock driver does not have it's own DT node, use the parent's node for registering. Signed-off-by: Peter Ujfalusi --- drivers/clk/clk-twl6040.c | 3 ++- 1 file

[PATCH 02/14] clk: twl6040: Register the clock as of_clk_provider

In order ot be able to use the pdmclk clock via DT it need to be registered as of_clk_provide. Since the twl6040 clock driver does not have it's own DT node, use the parent's node for registering. Signed-off-by: Peter Ujfalusi --- drivers/clk/clk-twl6040.c | 3 ++- 1 file changed, 2

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