Re: [PATCH 1/2] procfs: use an enum for possible hidepid values

On Thu, Nov 3, 2016 at 9:30 AM, Lafcadio Wluiki wrote: > (Third, rebased submission, since first two submissions yielded no replies.) Hm, I didn't see this series before, for some reason. > Previously, the hidepid parameter was checked by comparing literal > integers 0, 1, 2.

Re: net/ipv6: null-ptr-deref in inet6_bind

Hi Eric, It seems that your patch fixes the issue, I'm not seeing the report any more. Tested-by: Andrey Konovalov Thanks! On Thu, Nov 3, 2016 at 4:39 PM, Eric Dumazet wrote: > On Wed, Nov 2, 2016 at 2:14 PM, Andrey Konovalov

Re: [PATCH 1/2] procfs: use an enum for possible hidepid values

On Thu, Nov 3, 2016 at 9:30 AM, Lafcadio Wluiki wrote: > (Third, rebased submission, since first two submissions yielded no replies.) Hm, I didn't see this series before, for some reason. > Previously, the hidepid parameter was checked by comparing literal > integers 0, 1, 2. Let's add a proper

Re: net/ipv6: null-ptr-deref in inet6_bind

Hi Eric, It seems that your patch fixes the issue, I'm not seeing the report any more. Tested-by: Andrey Konovalov Thanks! On Thu, Nov 3, 2016 at 4:39 PM, Eric Dumazet wrote: > On Wed, Nov 2, 2016 at 2:14 PM, Andrey Konovalov > wrote: >> Hi, >> >> I've got the following error report while

Re: [RFC] make kmemleak scan __ro_after_init section (was: Re: [PATCH 0/5] genetlink improvements)

Hi, Sorry for not chipping in earlier - LPC is taking my time. > > > > Looks like we are missing a kfree(family->attrbuf); on error > > > > path, but it is not related to Johannes' recent patches. Actually, I think it *is* related to my patch - I inserted the code there in the wrong place or

Re: [RFC] make kmemleak scan __ro_after_init section (was: Re: [PATCH 0/5] genetlink improvements)

Hi, Sorry for not chipping in earlier - LPC is taking my time. > > > > Looks like we are missing a kfree(family->attrbuf); on error > > > > path, but it is not related to Johannes' recent patches. Actually, I think it *is* related to my patch - I inserted the code there in the wrong place or

Re: [PATCH v4 10/10] IB/mlx5: Simplify completion into a wait_event

On Wed, Oct 26, 2016 at 11:59 PM, Binoy Jayan wrote: > Convert the completion 'mlx5_ib_umr_context:done' to a wait_event as it > just waits for the return value to be filled. This is wrong. Since that "umr_context" variable is on the stack, and you are waiting for it to

Re: [PATCH v4 10/10] IB/mlx5: Simplify completion into a wait_event

On Wed, Oct 26, 2016 at 11:59 PM, Binoy Jayan wrote: > Convert the completion 'mlx5_ib_umr_context:done' to a wait_event as it > just waits for the return value to be filled. This is wrong. Since that "umr_context" variable is on the stack, and you are waiting for it to be fully done, it really

[PATCH 1/2] drm/i915: Remove redundant reprobe in i915_drm_resume

Weine's investigation on benchmarking the suspend/resume process pointed out a lot of the time in suspend/resume is being spent reprobing. While the reprobing process is a lengthy one for good reason, we don't need to hold up the entire suspend/resume process while we wait for it to finish.

[PATCH 1/2] drm/i915: Remove redundant reprobe in i915_drm_resume

Weine's investigation on benchmarking the suspend/resume process pointed out a lot of the time in suspend/resume is being spent reprobing. While the reprobing process is a lengthy one for good reason, we don't need to hold up the entire suspend/resume process while we wait for it to finish.

[PATCH 2/2] drm/i915: Reinit polling before hpd when resuming

Now that we don't run the connector reprobing from i915_drm_resume(), we need to make it so we don't have to wait for reprobing to finish so that we actually speed things up. In order to do this, we need to make sure that i915_drm_resume() doesn't get blocked by i915_hpd_poll_init_work() while

[PATCH 2/2] drm/i915: Reinit polling before hpd when resuming

Now that we don't run the connector reprobing from i915_drm_resume(), we need to make it so we don't have to wait for reprobing to finish so that we actually speed things up. In order to do this, we need to make sure that i915_drm_resume() doesn't get blocked by i915_hpd_poll_init_work() while

Applied "spi: sun6i: Support Allwinner H3 SPI controller" to the spi tree

The patch spi: sun6i: Support Allwinner H3 SPI controller has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to

Applied "spi: sun6i: Support Allwinner H3 SPI controller" to the spi tree

The patch spi: sun6i: Support Allwinner H3 SPI controller has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to

[PATCH 0/2] Small fixes to speed up resume

Recently David Weinehall has been investigating how we can make the resume process in i915 faster, and poked me to take a look at why we were taking so long while reprobing. As it turns out the main issue is just that we hold up the entire resume process while we reprobe connectors, which isn't

Re: [PATCH] usb: musb: da8xx: Don't print phy error on -EPROBE_DEFER

On Wed, Nov 02, 2016 at 10:45:59PM +0100, Ladislav Michl wrote: > Hi, > > On Tue, Oct 25, 2016 at 02:02:50PM -0500, David Lechner wrote: > > This suppresses printing the error message "failed to get phy" in the > > kernel log when the error is -EPROBE_DEFER. This prevents usless noise > > in the

Applied "spi: sun6i: Add binding for Allwinner H3 SPI controller" to the spi tree

The patch spi: sun6i: Add binding for Allwinner H3 SPI controller has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

[PATCH 0/2] Small fixes to speed up resume

Recently David Weinehall has been investigating how we can make the resume process in i915 faster, and poked me to take a look at why we were taking so long while reprobing. As it turns out the main issue is just that we hold up the entire resume process while we reprobe connectors, which isn't

Re: [PATCH] usb: musb: da8xx: Don't print phy error on -EPROBE_DEFER

On Wed, Nov 02, 2016 at 10:45:59PM +0100, Ladislav Michl wrote: > Hi, > > On Tue, Oct 25, 2016 at 02:02:50PM -0500, David Lechner wrote: > > This suppresses printing the error message "failed to get phy" in the > > kernel log when the error is -EPROBE_DEFER. This prevents usless noise > > in the

Applied "spi: sun6i: Add binding for Allwinner H3 SPI controller" to the spi tree

The patch spi: sun6i: Add binding for Allwinner H3 SPI controller has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Applied "ASoC: bcm: add depends on HAS_DMA" to the asoc tree

The patch ASoC: bcm: add depends on HAS_DMA has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during

Applied "ASoC: bcm: add depends on HAS_DMA" to the asoc tree

The patch ASoC: bcm: add depends on HAS_DMA has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during

Re: [PATCH 2/2] rtl8xxxu: Fix for bogus data used to determine macpower

On 11/03/2016 03:41 AM, Joe Perches wrote: On Sun, 2016-10-30 at 19:02 -0400, Jes Sorensen wrote: Code is 80 characters wide, and comments are /* */ never the ugly C++ crap. You might look at the recent Linus Torvalds authored commit 5e467652ffef (?printk: re-organize log_output() to be more

Re: [RFC PATCH 0/3] ARM64: meson-gxbb: Add support for system suspend

Urrgh, I accidentally sent this when trying to save this to my drafts folder; sorry for the half-finished reply. On Thu, Nov 03, 2016 at 03:25:46PM +, Mark Rutland wrote: > On Thu, Nov 03, 2016 at 03:29:22PM +0100, Neil Armstrong wrote: > > Thie patchset is a very experiment patchset to

Re: [PATCH 2/2] rtl8xxxu: Fix for bogus data used to determine macpower

On 11/03/2016 03:41 AM, Joe Perches wrote: On Sun, 2016-10-30 at 19:02 -0400, Jes Sorensen wrote: Code is 80 characters wide, and comments are /* */ never the ugly C++ crap. You might look at the recent Linus Torvalds authored commit 5e467652ffef (?printk: re-organize log_output() to be more

Re: [RFC PATCH 0/3] ARM64: meson-gxbb: Add support for system suspend

Urrgh, I accidentally sent this when trying to save this to my drafts folder; sorry for the half-finished reply. On Thu, Nov 03, 2016 at 03:25:46PM +, Mark Rutland wrote: > On Thu, Nov 03, 2016 at 03:29:22PM +0100, Neil Armstrong wrote: > > Thie patchset is a very experiment patchset to

Re: scripts/basic/bin2c: Complete error handling in main()

Dne 2.11.2016 v 19:46 SF Markus Elfring napsal(a): >> I like the code as is. > > Do you really prefer to ignore important return values in the discussed > function? You could define an xprintf() macro that checks if the return value is < 0 and simply calls perror() and exit(1) in such case.

Re: scripts/basic/bin2c: Complete error handling in main()

Dne 2.11.2016 v 19:46 SF Markus Elfring napsal(a): >> I like the code as is. > > Do you really prefer to ignore important return values in the discussed > function? You could define an xprintf() macro that checks if the return value is < 0 and simply calls perror() and exit(1) in such case.

Results: Linux Foundation Technical Advisory Board Election 2016

The TAB elections are now complete. Thank you to all the candidates for putting their names forward, and a big thank you to Grant Likely, Shuah Khan, Jes Sorensen, H. Peter Anvin, Chris Mason and the Linux Foundation staff who helped handle the election logistics. With 108 ballots cast, the top 5

Re: net/ipv6: null-ptr-deref in inet6_bind

On Wed, Nov 2, 2016 at 2:14 PM, Andrey Konovalov wrote: > Hi, > > I've got the following error report while running the syzkaller fuzzer: > > BUG: unable to handle kernel NULL pointer dereference at (null) > IP: [< (null)>] (null) > PGD 66b6f067

Results: Linux Foundation Technical Advisory Board Election 2016

The TAB elections are now complete. Thank you to all the candidates for putting their names forward, and a big thank you to Grant Likely, Shuah Khan, Jes Sorensen, H. Peter Anvin, Chris Mason and the Linux Foundation staff who helped handle the election logistics. With 108 ballots cast, the top 5

Re: net/ipv6: null-ptr-deref in inet6_bind

On Wed, Nov 2, 2016 at 2:14 PM, Andrey Konovalov wrote: > Hi, > > I've got the following error report while running the syzkaller fuzzer: > > BUG: unable to handle kernel NULL pointer dereference at (null) > IP: [< (null)>] (null) > PGD 66b6f067 [ 102.549865] PUD

Re: [PATCH 2/2] loop: support 4k physical blocksize

On Thu, Nov 3, 2016 at 10:26 PM, Christoph Hellwig wrote: >> -figure_loop_size(struct loop_device *lo, loff_t offset, loff_t sizelimit) >> +figure_loop_size(struct loop_device *lo, loff_t offset, loff_t sizelimit, >> + loff_t logical_blocksize) >> { >> loff_t size

Re: [PATCH 2/2] loop: support 4k physical blocksize

On Thu, Nov 3, 2016 at 10:26 PM, Christoph Hellwig wrote: >> -figure_loop_size(struct loop_device *lo, loff_t offset, loff_t sizelimit) >> +figure_loop_size(struct loop_device *lo, loff_t offset, loff_t sizelimit, >> + loff_t logical_blocksize) >> { >> loff_t size =

Re: [PATCH 1/2] rtl8xxxu: Fix for authentication failure

On 11/03/2016 02:10 AM, John Heenan wrote: On 3 November 2016 at 11:00, Larry Finger wrote: On 10/30/2016 05:20 AM, John Heenan wrote: This fix enables the same sequence of init behaviour as the alternative working driver for the wireless rtl8723bu IC at

Re: [PATCH 1/2] rtl8xxxu: Fix for authentication failure

On 11/03/2016 02:10 AM, John Heenan wrote: On 3 November 2016 at 11:00, Larry Finger wrote: On 10/30/2016 05:20 AM, John Heenan wrote: This fix enables the same sequence of init behaviour as the alternative working driver for the wireless rtl8723bu IC at https://github.com/lwfinger/rtl8723bu

Re: [RFC PATCH 2/3] rtc: Add Amlogic Virtual Wake RTC

On Thu, Nov 03, 2016 at 03:29:24PM +0100, Neil Armstrong wrote: > The Amlogic Meson GX SoCs uses a special register to store the > time in seconds to wakeup after a system suspend. Where does this register live, exactly? What IP block is it part of? > In order to be able to reuse the RTC

Re: [RFC PATCH 2/3] rtc: Add Amlogic Virtual Wake RTC

On Thu, Nov 03, 2016 at 03:29:24PM +0100, Neil Armstrong wrote: > The Amlogic Meson GX SoCs uses a special register to store the > time in seconds to wakeup after a system suspend. Where does this register live, exactly? What IP block is it part of? > In order to be able to reuse the RTC

Re: [RFC PATCH 0/3] ARM64: meson-gxbb: Add support for system suspend

On Thu, Nov 03, 2016 at 03:29:22PM +0100, Neil Armstrong wrote: > Thie patchset is a very experiment patchset to support the System Suspend > feature of the Amlogic Meson GX SoCs. > > These SoCs implements system suspend using a non-standard PSCI CPU_SUSPEND > parameter to enter system suspend.

[PATCH v3 0/5] usb: musb: da8xx: Fix few issues

Currently, the USB OTG of the da8xx doesn't work. This series intend to fix them. Change in v2: * Fix the error path da8xx_musb_init() Changes in v3: * Remove the host workaround that was not working on every platform * Add a property to the devicetree node of phy to force the phy in a specific

Re: [RFC PATCH 0/3] ARM64: meson-gxbb: Add support for system suspend

On Thu, Nov 03, 2016 at 03:29:22PM +0100, Neil Armstrong wrote: > Thie patchset is a very experiment patchset to support the System Suspend > feature of the Amlogic Meson GX SoCs. > > These SoCs implements system suspend using a non-standard PSCI CPU_SUSPEND > parameter to enter system suspend.

[PATCH v3 0/5] usb: musb: da8xx: Fix few issues

Currently, the USB OTG of the da8xx doesn't work. This series intend to fix them. Change in v2: * Fix the error path da8xx_musb_init() Changes in v3: * Remove the host workaround that was not working on every platform * Add a property to the devicetree node of phy to force the phy in a specific

[PATCH v3 4/5] phy: da8xx-usb: Use usb20_force_mode property to configure the phy mode

The USB PHY is able to operate in OTG, host or peripheral. Some board may be wired to work act only as host or peripheral. In such case, the dr_mode property of controller must be set to host or peripheral. But doing that will also configure the PHY in host or peripheral mode whereas OTG is able

[PATCH v3 4/5] phy: da8xx-usb: Use usb20_force_mode property to configure the phy mode

The USB PHY is able to operate in OTG, host or peripheral. Some board may be wired to work act only as host or peripheral. In such case, the dr_mode property of controller must be set to host or peripheral. But doing that will also configure the PHY in host or peripheral mode whereas OTG is able

Re: [PATCH 1/4] sched: move IO scheduling accounting from io_schedule_timeout() to __schedule()

Hi Tejun, > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > index 94732d1..f6baa38 100644 > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -3336,11 +3336,17 @@ static void __sched notrace __schedule(bool preempt) > unsigned long *switch_count; > struct

Re: [PATCH 1/4] sched: move IO scheduling accounting from io_schedule_timeout() to __schedule()

Hi Tejun, > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > index 94732d1..f6baa38 100644 > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -3336,11 +3336,17 @@ static void __sched notrace __schedule(bool preempt) > unsigned long *switch_count; > struct

Re: [PATCH v2] of, numa: Return NUMA_NO_NODE from disable of_node_to_nid() if nid not possible.

On 11/02/2016 08:37 PM, Rob Herring wrote: On Fri, Oct 28, 2016 at 4:15 PM, David Daney wrote: From: David Daney On arm64 NUMA kernels we can pass "numa=off" on the command line to disable NUMA. A side effect of this is that kmalloc_node()

Re: [PATCH v2] of, numa: Return NUMA_NO_NODE from disable of_node_to_nid() if nid not possible.

On 11/02/2016 08:37 PM, Rob Herring wrote: On Fri, Oct 28, 2016 at 4:15 PM, David Daney wrote: From: David Daney On arm64 NUMA kernels we can pass "numa=off" on the command line to disable NUMA. A side effect of this is that kmalloc_node() calls to non-zero nodes will crash the system with

[PATCH v3 5/5] usb: musb: da8xx: Remove set_mode callback

The USB PHY is able to operate in OTG, host or peripheral. Some board may be wired to work act only as host or peripheral. In such case, the dr_mode property of controller must be set to host or peripheral. But doing that will also configure the PHY in host or peripheral mode whereas OTG is able

[PATCH v3 5/5] usb: musb: da8xx: Remove set_mode callback

The USB PHY is able to operate in OTG, host or peripheral. Some board may be wired to work act only as host or peripheral. In such case, the dr_mode property of controller must be set to host or peripheral. But doing that will also configure the PHY in host or peripheral mode whereas OTG is able

Re: [PATCH] ASoC: sun4i-i2s: Implement capture support

On Thu, Nov 03, 2016 at 11:20:48AM +0100, Maxime Ripard wrote: > The i2s driver was only implementing playback for now. Implement capture to > make sure that's not a limitation anymore. This doesn't apply against current code, please check and resend. signature.asc Description: PGP signature

Re: [PATCH] ASoC: sun4i-i2s: Implement capture support

On Thu, Nov 03, 2016 at 11:20:48AM +0100, Maxime Ripard wrote: > The i2s driver was only implementing playback for now. Implement capture to > make sure that's not a limitation anymore. This doesn't apply against current code, please check and resend. signature.asc Description: PGP signature

Re: [PATCH v7 3/3] iio: adc: add support for Allwinner SoCs ADC

-rc2 > v4.9-rc1 v4.9-rc3] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Quentin-Schulz/add-support-for-Allwinner-SoCs-ADC/20161103-182828 > :: branch date: 2

Re: [PATCH v7 3/3] iio: adc: add support for Allwinner SoCs ADC

-rc2 > v4.9-rc1 v4.9-rc3] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Quentin-Schulz/add-support-for-Allwinner-SoCs-ADC/20161103-182828 > :: branch date: 2

[PATCH 1/2] procfs: use an enum for possible hidepid values

(Third, rebased submission, since first two submissions yielded no replies.) Previously, the hidepid parameter was checked by comparing literal integers 0, 1, 2. Let's add a proper enum for this, to make the checking more expressive: 0 → HIDEPID_OFF 1 → HIDEPID_NO_ACCESS

[PATCH 2/2] procfs/tasks: add a simple per-task procfs hidepid= field

(Third, rebased submission, since first two submissions yielded no replies.) This adds a new per-task hidepid= flag that is honored by procfs when presenting /proc to the user, in addition to the existing hidepid= mount option. So far, hidepid= was exclusively a per-pidns setting. Locking down a

[PATCH 1/2] procfs: use an enum for possible hidepid values

(Third, rebased submission, since first two submissions yielded no replies.) Previously, the hidepid parameter was checked by comparing literal integers 0, 1, 2. Let's add a proper enum for this, to make the checking more expressive: 0 → HIDEPID_OFF 1 → HIDEPID_NO_ACCESS

[PATCH 2/2] procfs/tasks: add a simple per-task procfs hidepid= field

(Third, rebased submission, since first two submissions yielded no replies.) This adds a new per-task hidepid= flag that is honored by procfs when presenting /proc to the user, in addition to the existing hidepid= mount option. So far, hidepid= was exclusively a per-pidns setting. Locking down a

Re: [RFC PATCH 1/3] ARM64: meson: Add Amlogic Meson GX PM Suspend

On Thu, Nov 03, 2016 at 03:29:23PM +0100, Neil Armstrong wrote: > The Amlogic Meson GX SoCs uses a non-standard argument to the > PSCI CPU_SUSPEND call to enter system suspend. > > Implement such call within platform_suspend_ops. While I am very much not happy with platform-specific extensions

Re: [RFC PATCH 1/3] ARM64: meson: Add Amlogic Meson GX PM Suspend

On Thu, Nov 03, 2016 at 03:29:23PM +0100, Neil Armstrong wrote: > The Amlogic Meson GX SoCs uses a non-standard argument to the > PSCI CPU_SUSPEND call to enter system suspend. > > Implement such call within platform_suspend_ops. While I am very much not happy with platform-specific extensions

Re: net/netlink: global-out-of-bounds in genl_family_rcv_msg/validate_nla

Hi Cong, Yes, the last patch fixes the issue. Tested-by: Andrey Konovalov Thanks! On Thu, Nov 3, 2016 at 6:29 AM, Cong Wang wrote: > On Wed, Nov 2, 2016 at 10:25 PM, Cong Wang wrote: >> On Wed, Nov 2, 2016 at 5:25

Re: net/netlink: global-out-of-bounds in genl_family_rcv_msg/validate_nla

Hi Cong, Yes, the last patch fixes the issue. Tested-by: Andrey Konovalov Thanks! On Thu, Nov 3, 2016 at 6:29 AM, Cong Wang wrote: > On Wed, Nov 2, 2016 at 10:25 PM, Cong Wang wrote: >> On Wed, Nov 2, 2016 at 5:25 PM, Andrey Konovalov >> wrote: >>> Hi, >>> >>> I've got the following error

[PATCH v3 3/5] dt/bindings: Add a new property to DA8xx USB PHY

The USB PHY is able to operate in OTG, host or peripheral. Some board may be wired to work act only as host or peripheral. In such case, the dr_mode property of controller must be set to host or peripheral. But doing that will also configure the PHY in host or peripheral mode whereas OTG is able

[PATCH v3 3/5] dt/bindings: Add a new property to DA8xx USB PHY

The USB PHY is able to operate in OTG, host or peripheral. Some board may be wired to work act only as host or peripheral. In such case, the dr_mode property of controller must be set to host or peripheral. But doing that will also configure the PHY in host or peripheral mode whereas OTG is able

[PATCH v3 1/5] usb: musb: da8xx: Call earlier clk_prepare_enable()

The first attempt to read a register may fail because the clock may not be enabled, and then the probe of musb driver will fail. Call clk_prepare_enable() before the first register read. Signed-off-by: Alexandre Bailon --- drivers/usb/musb/da8xx.c | 17 - 1

[PATCH v3 1/5] usb: musb: da8xx: Call earlier clk_prepare_enable()

The first attempt to read a register may fail because the clock may not be enabled, and then the probe of musb driver will fail. Call clk_prepare_enable() before the first register read. Signed-off-by: Alexandre Bailon --- drivers/usb/musb/da8xx.c | 17 - 1 file changed, 8

[PATCH v3 2/5] phy: da8xx-usb: Configure CFGCHIP2 to support OTG workaround

If we configure the da8xx OTG phy in OTG mode, neither device or host mode will work. That is because the PHY is not able to detect and notify the driver that value of ID pin changed. To work despite this hardware limitation, the da8xx glue implement a workaround. But to work, the workaround

[PATCH v3 2/5] phy: da8xx-usb: Configure CFGCHIP2 to support OTG workaround

If we configure the da8xx OTG phy in OTG mode, neither device or host mode will work. That is because the PHY is not able to detect and notify the driver that value of ID pin changed. To work despite this hardware limitation, the da8xx glue implement a workaround. But to work, the workaround

Re: [PATCH v3 04/16] scsi: Unify interfaces of fc_bsg_jobdone and bsg_job_done

On Thu, Oct 13, 2016 at 05:00:20PM +0200, Johannes Thumshirn wrote: > Unify the interfaces of fc_bsg_jobdone and bsg_job_done. This will reduce the > diff when moving from 'struct fc_bsg_job' to a plain 'struct bsg_job' later > on. > > Signed-off-by: Johannes Thumshirn >

Re: [PATCH v3 04/16] scsi: Unify interfaces of fc_bsg_jobdone and bsg_job_done

On Thu, Oct 13, 2016 at 05:00:20PM +0200, Johannes Thumshirn wrote: > Unify the interfaces of fc_bsg_jobdone and bsg_job_done. This will reduce the > diff when moving from 'struct fc_bsg_job' to a plain 'struct bsg_job' later > on. > > Signed-off-by: Johannes Thumshirn > Reviewed-by: Hannes

Re: [PATCH v3 02/16] scsi: don't use fc_bsg_job::request and fc_bsg_job::reply directly

On Fri, Oct 14, 2016 at 09:38:21AM +0200, Johannes Thumshirn wrote: > On Thu, Oct 13, 2016 at 05:55:11PM +0200, Steffen Maier wrote: > > Hm, still behaves for me like I reported for v2: > > http://marc.info/?l=linux-scsi=147637177902937=2 > > Hi Steffen, > > Can you please try the following on

Re: [PATCH v3 02/16] scsi: don't use fc_bsg_job::request and fc_bsg_job::reply directly

On Fri, Oct 14, 2016 at 09:38:21AM +0200, Johannes Thumshirn wrote: > On Thu, Oct 13, 2016 at 05:55:11PM +0200, Steffen Maier wrote: > > Hm, still behaves for me like I reported for v2: > > http://marc.info/?l=linux-scsi=147637177902937=2 > > Hi Steffen, > > Can you please try the following on

Re: [PATCH v3 03/16] scsi: fc: Export fc_bsg_jobdone and use it in FC drivers

On Thu, Oct 13, 2016 at 05:00:19PM +0200, Johannes Thumshirn wrote: > Export fc_bsg_jobdone so drivers can use it directly instead of doing > the round-trip via struct fc_bsg_job::job_done() and use it in the LLDDs. > > As we've converted all LLDDs over to use fc_bsg_jobdone() directly, > we can

Re: [PATCH v3 03/16] scsi: fc: Export fc_bsg_jobdone and use it in FC drivers

On Thu, Oct 13, 2016 at 05:00:19PM +0200, Johannes Thumshirn wrote: > Export fc_bsg_jobdone so drivers can use it directly instead of doing > the round-trip via struct fc_bsg_job::job_done() and use it in the LLDDs. > > As we've converted all LLDDs over to use fc_bsg_jobdone() directly, > we can

Re: [PATCH v3 01/16] scsi: Get rid of struct fc_bsg_buffer

On Thu, Oct 13, 2016 at 05:00:17PM +0200, Johannes Thumshirn wrote: > struct fc_bsg_buffer is just a clone of struct bsg_buffer from bsg-lib, > so use this one instead. > > Signed-off-by: Johannes Thumshirn > Reviewed-by: Hannes Reinecke Looks good,

Re: [PATCH v3 01/16] scsi: Get rid of struct fc_bsg_buffer

On Thu, Oct 13, 2016 at 05:00:17PM +0200, Johannes Thumshirn wrote: > struct fc_bsg_buffer is just a clone of struct bsg_buffer from bsg-lib, > so use this one instead. > > Signed-off-by: Johannes Thumshirn > Reviewed-by: Hannes Reinecke Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH RESEND] media: omap3isp: Use dma_request_chan() to requesting DMA channel

Hi Peter, On Thursday 03 Nov 2016 15:14:19 Peter Ujfalusi wrote: > On 11/03/2016 11:23 AM, Peter Ujfalusi wrote: > > On 11/02/2016 11:19 PM, Laurent Pinchart wrote: > >>> On Wednesday 02 Nov 2016 14:39:59 Peter Ujfalusi wrote: > > With the new dma_request_chan() the client driver does not

Re: [PATCH] userns: suppress kmemleak message

On Thu, 03 Nov 2016 09:54:25 -0500, Eric W. Biederman wrote: > Dmitry Torokhov writes: > > > We do not ever intend to unregister "user" sysctl table, unfortunately > > it leads kmemleak to believe that we are leaking memory: > > Sounds like an issue with kmemleak

Re: [PATCH RESEND] media: omap3isp: Use dma_request_chan() to requesting DMA channel

Hi Peter, On Thursday 03 Nov 2016 15:14:19 Peter Ujfalusi wrote: > On 11/03/2016 11:23 AM, Peter Ujfalusi wrote: > > On 11/02/2016 11:19 PM, Laurent Pinchart wrote: > >>> On Wednesday 02 Nov 2016 14:39:59 Peter Ujfalusi wrote: > > With the new dma_request_chan() the client driver does not

Re: [PATCH] userns: suppress kmemleak message

On Thu, 03 Nov 2016 09:54:25 -0500, Eric W. Biederman wrote: > Dmitry Torokhov writes: > > > We do not ever intend to unregister "user" sysctl table, unfortunately > > it leads kmemleak to believe that we are leaking memory: > > Sounds like an issue with kmemleak because we do retain

Re: [RFC] v4l2 support for thermopile devices

On 03/11/2016 14:21, Attila Kinali wrote: > On Wed, 2 Nov 2016 23:10:41 -0700 > Matt Ranostay wrote: > >> >> So does anyone know of any software that is using V4L2_PIX_FMT_Y12 >> currently? Want to test my driver but seems there isn't anything that >> uses that format

Re: [RFC] v4l2 support for thermopile devices

On 03/11/2016 14:21, Attila Kinali wrote: > On Wed, 2 Nov 2016 23:10:41 -0700 > Matt Ranostay wrote: > >> >> So does anyone know of any software that is using V4L2_PIX_FMT_Y12 >> currently? Want to test my driver but seems there isn't anything that >> uses that format (ffmpeg, mplayer, etc). >>

Re: [PATCH RESEND] media: omap3isp: Use dma_request_chan() to requesting DMA channel

Hi Peter, On Thursday 03 Nov 2016 11:23:50 Peter Ujfalusi wrote: > On 11/02/2016 11:19 PM, Laurent Pinchart wrote: > > On Wednesday 02 Nov 2016 14:39:59 Peter Ujfalusi wrote: > >> With the new dma_request_chan() the client driver does not need to look > >> for the DMA resource and it does not

Re: [PATCH RESEND] media: omap3isp: Use dma_request_chan() to requesting DMA channel

Hi Peter, On Thursday 03 Nov 2016 11:23:50 Peter Ujfalusi wrote: > On 11/02/2016 11:19 PM, Laurent Pinchart wrote: > > On Wednesday 02 Nov 2016 14:39:59 Peter Ujfalusi wrote: > >> With the new dma_request_chan() the client driver does not need to look > >> for the DMA resource and it does not

[PATCH v2] arc: Implement arch-specific dma_map_ops.mmap

We used to use generic implementation of dma_map_ops.mmap which is dma_common_mmap() but that only worked for simpler cached mappings when vaddr = paddr. If a driver requests uncached DMA buffer kernel maps it to virtual address so that MMU gets involved and page uncached status takes into

[PATCH v2] arc: Implement arch-specific dma_map_ops.mmap

We used to use generic implementation of dma_map_ops.mmap which is dma_common_mmap() but that only worked for simpler cached mappings when vaddr = paddr. If a driver requests uncached DMA buffer kernel maps it to virtual address so that MMU gets involved and page uncached status takes into

Re: [PATCH 2/5] KVM: x86: do not scan IRR twice on APICv vmentry

2016-11-03 14:30+0100, Paolo Bonzini: > On 26/10/2016 21:59, Radim Krčmář wrote: >> 2016-10-14 20:21+0200, Paolo Bonzini: >>> Calling apic_find_highest_irr results in IRR being scanned twice, >>> once in vmx_sync_pir_from_irr and once in apic_search_irr. Change >>> sync_pir_from_irr to do the RVI

Re: [PATCH 2/5] KVM: x86: do not scan IRR twice on APICv vmentry

2016-11-03 14:30+0100, Paolo Bonzini: > On 26/10/2016 21:59, Radim Krčmář wrote: >> 2016-10-14 20:21+0200, Paolo Bonzini: >>> Calling apic_find_highest_irr results in IRR being scanned twice, >>> once in vmx_sync_pir_from_irr and once in apic_search_irr. Change >>> sync_pir_from_irr to do the RVI

RE: [mm PATCH v2 01/26] swiotlb: Drop unused functions swiotlb_map_sg and swiotlb_unmap_sg

> -Original Message- > From: Christoph Hellwig [mailto:h...@infradead.org] > Sent: Thursday, November 3, 2016 7:46 AM > To: Konrad Rzeszutek Wilk > Cc: Christoph Hellwig ; Duyck, Alexander H > ; linux...@kvack.org;

RE: [mm PATCH v2 01/26] swiotlb: Drop unused functions swiotlb_map_sg and swiotlb_unmap_sg

> -Original Message- > From: Christoph Hellwig [mailto:h...@infradead.org] > Sent: Thursday, November 3, 2016 7:46 AM > To: Konrad Rzeszutek Wilk > Cc: Christoph Hellwig ; Duyck, Alexander H > ; linux...@kvack.org; akpm@linux- > foundation.org; net...@vger.kernel.org;

[PATCH 02/25] kernel/printk: Convert to hotplug state machine

Install the callbacks via the state machine. Cc: Andrew Morton Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner --- include/linux/cpuhotplug.h | 1 + kernel/printk/printk.c | 27

[PATCH 02/25] kernel/printk: Convert to hotplug state machine

Install the callbacks via the state machine. Cc: Andrew Morton Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner --- include/linux/cpuhotplug.h | 1 + kernel/printk/printk.c | 27 --- 2 files changed, 13 insertions(+), 15 deletions(-) diff

[PATCH 25/25] x86/mcheck: Move CPU_DEAD to hotplug state machine

This moves the last piece of the old hotplug notifier code in MCE to the new hotplug state machine. Cc: Tony Luck Cc: Borislav Petkov Cc: linux-e...@vger.kernel.org Cc: x...@kernel.org Signed-off-by: Sebastian Andrzej Siewior

[PATCH 25/25] x86/mcheck: Move CPU_DEAD to hotplug state machine

This moves the last piece of the old hotplug notifier code in MCE to the new hotplug state machine. Cc: Tony Luck Cc: Borislav Petkov Cc: linux-e...@vger.kernel.org Cc: x...@kernel.org Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner ---

Re: [PATCH 1/4] block: add scalable completion tracking of requests

On Thu, Nov 3, 2016 at 9:38 PM, Jens Axboe wrote: > On 11/03/2016 05:17 AM, Ming Lei wrote: >>> >>> diff --git a/block/blk-core.c b/block/blk-core.c >>> index 0bfaa54d3e9f..ca77c725b4e5 100644 >>> --- a/block/blk-core.c >>> +++ b/block/blk-core.c >>> @@ -2462,6 +2462,8 @@ void

Re: [PATCH 1/4] block: add scalable completion tracking of requests

On Thu, Nov 3, 2016 at 9:38 PM, Jens Axboe wrote: > On 11/03/2016 05:17 AM, Ming Lei wrote: >>> >>> diff --git a/block/blk-core.c b/block/blk-core.c >>> index 0bfaa54d3e9f..ca77c725b4e5 100644 >>> --- a/block/blk-core.c >>> +++ b/block/blk-core.c >>> @@ -2462,6 +2462,8 @@ void

Re: [PATCH v8: 3/4] x86/cpufeature: Add PHIR3MWAIT to CPU features

On Tue, Nov 01, 2016 at 11:14:49AM +0100, Grzegorz Andrejczuk wrote: > Add Intel Xeon Phi x200 (KnightsLanding) cpu feature - ring 3 monitor/mwait @tip guys: s/cpu/CPU/, s!monitor/mwait!MONITOR/MWAIT! and add a fullstop when committing. > Signed-off-by: Grzegorz Andrejczuk

Re: [PATCH] userns: suppress kmemleak message

Dmitry Torokhov writes: > We do not ever intend to unregister "user" sysctl table, unfortunately > it leads kmemleak to believe that we are leaking memory: Sounds like an issue with kmemleak because we do retain references. So no we don't intend to unregister the

Re: [PATCH v8: 3/4] x86/cpufeature: Add PHIR3MWAIT to CPU features

On Tue, Nov 01, 2016 at 11:14:49AM +0100, Grzegorz Andrejczuk wrote: > Add Intel Xeon Phi x200 (KnightsLanding) cpu feature - ring 3 monitor/mwait @tip guys: s/cpu/CPU/, s!monitor/mwait!MONITOR/MWAIT! and add a fullstop when committing. > Signed-off-by: Grzegorz Andrejczuk > --- >

Re: [PATCH] userns: suppress kmemleak message

Dmitry Torokhov writes: > We do not ever intend to unregister "user" sysctl table, unfortunately > it leads kmemleak to believe that we are leaking memory: Sounds like an issue with kmemleak because we do retain references. So no we don't intend to unregister the table. As for the patch.

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