Fast Loans

Do you need a loan to pay up bill or to start a business? Email Us

Fast Loans

Do you need a loan to pay up bill or to start a business? Email Us

[PATCH 2/2] backlight: gpio: delete pdata inversion

The option to invert the output of the GPIO (active low) is not used by the only platform still using platform data to set up a GPIO backlight (one SH board). Delete the option as we do not expect to expand the use of board files for this driver, and GPIO descriptors intrinsically keep track of

[PATCH 2/2] backlight: gpio: delete pdata inversion

The option to invert the output of the GPIO (active low) is not used by the only platform still using platform data to set up a GPIO backlight (one SH board). Delete the option as we do not expect to expand the use of board files for this driver, and GPIO descriptors intrinsically keep track of

[PATCH 1/2] backlight: gpio: Convert to use GPIO descriptor

This driver is predominantly used by device tree systems, all of which can deal with modern GPIO descriptors. The legacy GPIO API is only used by one SH board so make the GPIO descriptor the default way to deal with it. As an intended side effect we do not need to look around in the device tree

[PATCH 1/2] backlight: gpio: Convert to use GPIO descriptor

This driver is predominantly used by device tree systems, all of which can deal with modern GPIO descriptors. The legacy GPIO API is only used by one SH board so make the GPIO descriptor the default way to deal with it. As an intended side effect we do not need to look around in the device tree

Re: [PATCH] staging/ks7010: Fix type assignment for struct hostif_hdr

On Sat, Apr 29, 2017 at 07:54:30PM +0200, Cezary Gapinski wrote: > Sparse spits out a warnings about __le16 and unsigned short assignment. > Change the type of size and event members of struct hostif_hdr > to __le16 and correct conversion to the proper cpu type. I believe that this patch is

Re: [PATCH] staging/ks7010: Fix type assignment for struct hostif_hdr

On Sat, Apr 29, 2017 at 07:54:30PM +0200, Cezary Gapinski wrote: > Sparse spits out a warnings about __le16 and unsigned short assignment. > Change the type of size and event members of struct hostif_hdr > to __le16 and correct conversion to the proper cpu type. I believe that this patch is

[RFC] fix race in drivers/char/random.c:get_reg()

get_reg() can be reentered on architectures with prioritized interrupts (m68k in this case), causing f->reg_index to be incremented after the range check. Out of bounds memory access past the pt_regs struct results. This will go mostly undetected unless access is beyond end of memory. Prevent the

[RFC] fix race in drivers/char/random.c:get_reg()

get_reg() can be reentered on architectures with prioritized interrupts (m68k in this case), causing f->reg_index to be incremented after the range check. Out of bounds memory access past the pt_regs struct results. This will go mostly undetected unless access is beyond end of memory. Prevent the

Re: [PATCH v6 2/2] tcmu: Add global data block pool support

On 04/26/2017 01:25 AM, lixi...@cmss.chinamobile.com wrote: > From: Xiubo Li > > For each target there will be one ring, when the target number > grows larger and larger, it could eventually runs out of the > system memories. > > In this patch for each target ring,

Re: [PATCH v6 2/2] tcmu: Add global data block pool support

On 04/26/2017 01:25 AM, lixi...@cmss.chinamobile.com wrote: > From: Xiubo Li > > For each target there will be one ring, when the target number > grows larger and larger, it could eventually runs out of the > system memories. > > In this patch for each target ring, currently for the cmd area >

[PATCH] cris: nand: fix a leak in error handling path

If only 1 of the 2 'ioremap' fails, then there is a small leak. Signed-off-by: Christophe JAILLET --- arch/cris/arch-v32/drivers/mach-fs/nandflash.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git

[PATCH] cris: nand: fix a leak in error handling path

If only 1 of the 2 'ioremap' fails, then there is a small leak. Signed-off-by: Christophe JAILLET --- arch/cris/arch-v32/drivers/mach-fs/nandflash.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/arch/cris/arch-v32/drivers/mach-fs/nandflash.c

Re: powerpc/8xx: Adding support of IRQ in MPC8xx GPIO

On Thu, Mar 09, 2017 at 10:42:04AM +0100, Christophe Leroy wrote: > This patch allows the use of IRQ to notify the change of GPIO status > on MPC8xx CPM IO ports. This then allows to associate IRQs to GPIOs > in the Device Tree. > > Ex: > CPM1_PIO_C: gpio-controller@960 { >

Re: powerpc/8xx: Adding support of IRQ in MPC8xx GPIO

On Thu, Mar 09, 2017 at 10:42:04AM +0100, Christophe Leroy wrote: > This patch allows the use of IRQ to notify the change of GPIO status > on MPC8xx CPM IO ports. This then allows to associate IRQs to GPIOs > in the Device Tree. > > Ex: > CPM1_PIO_C: gpio-controller@960 { >

Re: [PATCH] ALSA: ali5451: fix spelling mistake in "ali_capture_preapre"

On Sat, 29 Apr 2017 23:52:55 +0200, Colin King wrote: > > From: Colin Ian King > > trivial fix to spelling mistake in dev_warn message, > "ali_capture_preapre" should be "ali_capture_prepare" > > Signed-off-by: Colin Ian King Applied,

Re: [PATCH] ALSA: ali5451: fix spelling mistake in "ali_capture_preapre"

On Sat, 29 Apr 2017 23:52:55 +0200, Colin King wrote: > > From: Colin Ian King > > trivial fix to spelling mistake in dev_warn message, > "ali_capture_preapre" should be "ali_capture_prepare" > > Signed-off-by: Colin Ian King Applied, thanks. Takashi > --- > sound/pci/ali5451/ali5451.c |

Q. drm/i915 shrinker, synchronize_rcu_expedited() from handlers

Hello, Since v4.11-rc7 I can see the workqueue stops on my development/test system. Git-bisecting tells me the suspicious commit is c053b5a 2017-04-11 drm/i915: Don't call synchronize_rcu_expedited under struct_mutex I am not sure whether this is the real cause or not of my problem, but

Q. drm/i915 shrinker, synchronize_rcu_expedited() from handlers

Hello, Since v4.11-rc7 I can see the workqueue stops on my development/test system. Git-bisecting tells me the suspicious commit is c053b5a 2017-04-11 drm/i915: Don't call synchronize_rcu_expedited under struct_mutex I am not sure whether this is the real cause or not of my problem, but

Re: 4.11.0-rc8+/x86_64 desktop lockup until applications closed

Michal Hocko wrote on 27/04/17 18:56: On Thu 27-04-17 18:36:38, Arthur Marsh wrote: [...] [55363.482931] QXcbEventReader: page allocation stalls for 10048ms, order:0, mode:0x14200ca(GFP_HIGHUSER_MOVABLE), nodemask=(null) Are there more of these stalls? I haven't seen the same kinds of

Re: 4.11.0-rc8+/x86_64 desktop lockup until applications closed

Michal Hocko wrote on 27/04/17 18:56: On Thu 27-04-17 18:36:38, Arthur Marsh wrote: [...] [55363.482931] QXcbEventReader: page allocation stalls for 10048ms, order:0, mode:0x14200ca(GFP_HIGHUSER_MOVABLE), nodemask=(null) Are there more of these stalls? I haven't seen the same kinds of

<    1   2   3   4