Re: [PATCH 06/10] iio: adc: stm32: add ext attrs to configure sampling time

On 25/10/16 17:25, Fabrice Gasnier wrote: > Add per channel "smpr" IIO extended attribute, to allow sampling > time configuration. > > Signed-off-by: Fabrice Gasnier First thing is that any attributes need to be documented in Documentation/ABI/testing/sysfs-bus-iio-*

Re: [PATCH 06/10] iio: adc: stm32: add ext attrs to configure sampling time

On 25/10/16 17:25, Fabrice Gasnier wrote: > Add per channel "smpr" IIO extended attribute, to allow sampling > time configuration. > > Signed-off-by: Fabrice Gasnier First thing is that any attributes need to be documented in Documentation/ABI/testing/sysfs-bus-iio-* Secondly this feels rather

Re: [PULL] bcache: multiple updates

On Sat, Oct 29, 2016 at 06:32:38PM -0700, Eric Wheeler wrote: > On Thu, 27 Oct 2016, Jens Axboe wrote: > > > On 10/27/2016 05:27 PM, Eric Wheeler wrote: > > > Hi Jens, > > > > > > Please pull this v4.9-rc2 based series of bcache updates for v4.9-rc3: > > > (You may disregard the previous

Re: [PULL] bcache: multiple updates

On Sat, Oct 29, 2016 at 06:32:38PM -0700, Eric Wheeler wrote: > On Thu, 27 Oct 2016, Jens Axboe wrote: > > > On 10/27/2016 05:27 PM, Eric Wheeler wrote: > > > Hi Jens, > > > > > > Please pull this v4.9-rc2 based series of bcache updates for v4.9-rc3: > > > (You may disregard the previous

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

Thanks for your reply. The code was tested on a Cube i9 which has an internal rtl8723bu. No other devices were tested. I am happy to accept in an ideal context hard coding macpower is undesirable, the comment is undesirable and it is wrong to assume the issue is not unique to the rtl8723bu.

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

Thanks for your reply. The code was tested on a Cube i9 which has an internal rtl8723bu. No other devices were tested. I am happy to accept in an ideal context hard coding macpower is undesirable, the comment is undesirable and it is wrong to assume the issue is not unique to the rtl8723bu.

[PATCH] drm/bridge: dw-hdmi: Set sink_is_hdmi and sink_has_audio in mode_set

These were previously set in dw_hdmi_connector_get_modes but this isn't called when the EDID is overridden. This can be seen in drm_helper_probe_single_connector_modes. Using the drm_kms_helper.edid_firmware parameter therefore always resulted in silence, even when providing the very same EDID

[PATCH] drm/bridge: dw-hdmi: Set sink_is_hdmi and sink_has_audio in mode_set

These were previously set in dw_hdmi_connector_get_modes but this isn't called when the EDID is overridden. This can be seen in drm_helper_probe_single_connector_modes. Using the drm_kms_helper.edid_firmware parameter therefore always resulted in silence, even when providing the very same EDID

Re: [PATCH v3 8/8] iio: envelope-detector: ADC driver based on a DAC and a comparator

On 23/10/16 23:39, Peter Rosin wrote: > The DAC is used to find the peak level of an alternating voltage input > signal by a binary search using the output of a comparator wired to > an interrupt pin. Like so: > _ > | \ > input

Re: [PATCH v3 8/8] iio: envelope-detector: ADC driver based on a DAC and a comparator

On 23/10/16 23:39, Peter Rosin wrote: > The DAC is used to find the peak level of an alternating voltage input > signal by a binary search using the output of a comparator wired to > an interrupt pin. Like so: > _ > | \ > input

Re: [PATCH 3/3] s390: char: make slp_ctl explicitly non-modular

On Sat, 29 Oct 2016 16:38:43 -0400 Paul Gortmaker wrote: > The Makefile currently controlling compilation of this code is obj-y, > meaning that it currently is not being built as a module by anyone. > > Lets remove the couple traces of modular usage, so that when

Re: [PATCH 3/3] s390: char: make slp_ctl explicitly non-modular

On Sat, 29 Oct 2016 16:38:43 -0400 Paul Gortmaker wrote: > The Makefile currently controlling compilation of this code is obj-y, > meaning that it currently is not being built as a module by anyone. > > Lets remove the couple traces of modular usage, so that when reading > the driver there is

Re: [PATCH v3 2/4] usb: musb: core: added helper function for parsing DT

Alexandre Bailon writes: > From: Petr Kulhavy > > This adds the function musb_get_mode() to get the DT property "dr_mode" > > Signed-off-by: Petr Kulhavy > Acked-by: Sergei Shtylyov > Signed-off-by: Alexandre

Re: [PATCH v3 2/4] usb: musb: core: added helper function for parsing DT

Alexandre Bailon writes: > From: Petr Kulhavy > > This adds the function musb_get_mode() to get the DT property "dr_mode" > > Signed-off-by: Petr Kulhavy > Acked-by: Sergei Shtylyov > Signed-off-by: Alexandre Bailon > Tested-by: David Lechner > --- > drivers/usb/musb/musb_core.c | 19

Re: [PATCH v3 7/8] dt-bindings: iio: document envelope-detector bindings

On 23/10/16 23:39, Peter Rosin wrote: > Signed-off-by: Peter Rosin I'm happy with this, but again it's odd enough I'd like some input from a device tree bindings maintainer. Thanks, Jonathan > --- > .../bindings/iio/adc/envelope-detector.txt | 54 >

Re: [PATCH v3 7/8] dt-bindings: iio: document envelope-detector bindings

On 23/10/16 23:39, Peter Rosin wrote: > Signed-off-by: Peter Rosin I'm happy with this, but again it's odd enough I'd like some input from a device tree bindings maintainer. Thanks, Jonathan > --- > .../bindings/iio/adc/envelope-detector.txt | 54 > ++ >

Re: [PATCH v3 6/8] iio: dpot-dac: DAC driver based on a digital potentiometer

On 23/10/16 23:39, Peter Rosin wrote: > It is assumed that the dpot is used as a voltage divider between the > current dpot wiper setting and the maximum resistance of the dpot. The > divided voltage is provided by a vref regulator. > > .--. >.---. | | >

Re: [PATCH v3 6/8] iio: dpot-dac: DAC driver based on a digital potentiometer

On 23/10/16 23:39, Peter Rosin wrote: > It is assumed that the dpot is used as a voltage divider between the > current dpot wiper setting and the maximum resistance of the dpot. The > divided voltage is provided by a vref regulator. > > .--. >.---. | | >

Re: [PATCH v3 5/8] dt-bindings: iio: document dpot-dac bindings

On 23/10/16 23:39, Peter Rosin wrote: > Signed-off-by: Peter Rosin I'm happy with this, but it's odd enough I'd like some devicetree maintainer feedback ideally. Thanks, Jonathan > --- > .../devicetree/bindings/iio/dac/dpot-dac.txt | 41 > ++ >

Re: [PATCH v3 5/8] dt-bindings: iio: document dpot-dac bindings

On 23/10/16 23:39, Peter Rosin wrote: > Signed-off-by: Peter Rosin I'm happy with this, but it's odd enough I'd like some devicetree maintainer feedback ideally. Thanks, Jonathan > --- > .../devicetree/bindings/iio/dac/dpot-dac.txt | 41 > ++ > MAINTAINERS

Re: [PATCH v3 3/8] iio: mcp4531: provide range of available raw values

On 23/10/16 23:39, Peter Rosin wrote: > Example: > > $ cat '/sys/bus/iio/devices/iio:device0/out_resistance_raw_available' > [0 1 256] > > Meaning: min 0, step 1 and max 256. > > Signed-off-by: Peter Rosin Looks good. On comment inline, but nothing to change. This series is

Re: [PATCH v3 3/8] iio: mcp4531: provide range of available raw values

On 23/10/16 23:39, Peter Rosin wrote: > Example: > > $ cat '/sys/bus/iio/devices/iio:device0/out_resistance_raw_available' > [0 1 256] > > Meaning: min 0, step 1 and max 256. > > Signed-off-by: Peter Rosin Looks good. On comment inline, but nothing to change. This series is likely to just be

Re: [PATCH v3 2/8] iio: inkern: add helpers to query available values from channels

On 23/10/16 23:39, Peter Rosin wrote: > Specifically a helper for reading the available maximum raw value of a > channel and a helper for forwarding read_avail requests for raw values > from one iio driver to an iio channel that is consumed. > > These rather specific helpers are in turn built

Linux 4.9: Reported regressions as of Sunday, 2016-10-30

Hi! Here is my second regression report for Linux 4.9. It lists 14 regressions I'm aware of. 4 of them are new; 3 got fixed since last weeks report. As always: Are you aware of any other regressions? Then please let me know (simply CC regressi...@leemhuis.info). And please tell me if there is

Re: [PATCH v3 2/8] iio: inkern: add helpers to query available values from channels

On 23/10/16 23:39, Peter Rosin wrote: > Specifically a helper for reading the available maximum raw value of a > channel and a helper for forwarding read_avail requests for raw values > from one iio driver to an iio channel that is consumed. > > These rather specific helpers are in turn built

Linux 4.9: Reported regressions as of Sunday, 2016-10-30

Hi! Here is my second regression report for Linux 4.9. It lists 14 regressions I'm aware of. 4 of them are new; 3 got fixed since last weeks report. As always: Are you aware of any other regressions? Then please let me know (simply CC regressi...@leemhuis.info). And please tell me if there is

Re: net/dccp: warning in dccp_feat_clone_sp_val/__might_sleep

On Sun, 2016-10-30 at 05:41 +0100, Andrey Konovalov wrote: > Sorry, the warning is still there. > > I'm not sure adding sched_annotate_sleep() does anything, since it's > defined as (in case CONFIG_DEBUG_ATOMIC_SLEEP is not set): > # define sched_annotate_sleep() do { } while (0) Thanks again

Re: net/dccp: warning in dccp_feat_clone_sp_val/__might_sleep

On Sun, 2016-10-30 at 05:41 +0100, Andrey Konovalov wrote: > Sorry, the warning is still there. > > I'm not sure adding sched_annotate_sleep() does anything, since it's > defined as (in case CONFIG_DEBUG_ATOMIC_SLEEP is not set): > # define sched_annotate_sleep() do { } while (0) Thanks again

Re: [PATCH v3 1/8] iio:core: add a callback to allow drivers to provide _available attributes

On 23/10/16 23:39, Peter Rosin wrote: > From: Jonathan Cameron > > A large number of attributes can only take a limited range of values. > Currently in IIO this is handled by directly registering additional > *_available attributes thus providing this information to userspace.

Re: [PATCH v3 1/8] iio:core: add a callback to allow drivers to provide _available attributes

On 23/10/16 23:39, Peter Rosin wrote: > From: Jonathan Cameron > > A large number of attributes can only take a limited range of values. > Currently in IIO this is handled by directly registering additional > *_available attributes thus providing this information to userspace. > > It is

Re: [PATCH net-next 5/5] ipv6: Compute multipath hash for forwarded ICMP errors from offending packet

On Fri, Oct 28, 2016 at 02:25 PM GMT, Tom Herbert wrote: > On Fri, Oct 28, 2016 at 1:32 AM, Jakub Sitnicki wrote: >> On Thu, Oct 27, 2016 at 10:35 PM GMT, Tom Herbert wrote: >>> On Mon, Oct 24, 2016 at 2:28 AM, Jakub Sitnicki wrote: Same as for the transmit

Re: [PATCH net-next 5/5] ipv6: Compute multipath hash for forwarded ICMP errors from offending packet

On Fri, Oct 28, 2016 at 02:25 PM GMT, Tom Herbert wrote: > On Fri, Oct 28, 2016 at 1:32 AM, Jakub Sitnicki wrote: >> On Thu, Oct 27, 2016 at 10:35 PM GMT, Tom Herbert wrote: >>> On Mon, Oct 24, 2016 at 2:28 AM, Jakub Sitnicki wrote: Same as for the transmit path, let's do our best to ensure

Re: Build regressions/improvements in v4.9-rc3

On Sun, Oct 30, 2016 at 1:08 PM, Geert Uytterhoeven wrote: > Below is the list of build error/warning regressions/improvements in > v4.9-rc3[1] compared to v4.8[2]. > > Summarized: > - build errors: +176/-3 + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error:

Re: Build regressions/improvements in v4.9-rc3

On Sun, Oct 30, 2016 at 1:08 PM, Geert Uytterhoeven wrote: > Below is the list of build error/warning regressions/improvements in > v4.9-rc3[1] compared to v4.8[2]. > > Summarized: > - build errors: +176/-3 + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llock

[PATCH] staging: vc04_services: remove vchiq_copy_from_user

The vchiq_copy_from_user function is not portable and is consider "bad practice." Replace this function with a callback based mechanism that is passed downward on the stack. When it is actually time to copy the data, the callback is called to copy the data into the message. This callback is

[PATCH] staging: vc04_services: remove vchiq_copy_from_user

The vchiq_copy_from_user function is not portable and is consider "bad practice." Replace this function with a callback based mechanism that is passed downward on the stack. When it is actually time to copy the data, the callback is called to copy the data into the message. This callback is

Re: [PATCH -next] brd: make symbol rd_size static

On 10/30/2016 11:57 AM, Jens Axboe wrote: > On 10/29/2016 10:10 AM, Wei Yongjun wrote: >> From: Wei Yongjun >> >> Fixes the following sparse warning: >> >> drivers/block/brd.c:411:15: warning: >> symbol 'rd_size' was not declared. Should it be static? > > We just tried

Re: [PATCH -next] brd: make symbol rd_size static

On 10/30/2016 11:57 AM, Jens Axboe wrote: > On 10/29/2016 10:10 AM, Wei Yongjun wrote: >> From: Wei Yongjun >> >> Fixes the following sparse warning: >> >> drivers/block/brd.c:411:15: warning: >> symbol 'rd_size' was not declared. Should it be static? > > We just tried this, it's used in arm: >

RFC if==else in i40iw_virtchnl.

Hi Faisal ! your commit 4097351a47c5 ("i40iw: virtual channel handling files") adds the following lines in i40iw_vchnl_recv_pf() + if (vchnl_msg->iw_op_ver != I40IW_VCHNL_OP_GET_VER_V0) + vchnl_pf_send_get_ver_resp(dev, vf_id, vchnl_msg); +

RFC if==else in i40iw_virtchnl.

Hi Faisal ! your commit 4097351a47c5 ("i40iw: virtual channel handling files") adds the following lines in i40iw_vchnl_recv_pf() + if (vchnl_msg->iw_op_ver != I40IW_VCHNL_OP_GET_VER_V0) + vchnl_pf_send_get_ver_resp(dev, vf_id, vchnl_msg); +

Build regressions/improvements in v4.9-rc3

Below is the list of build error/warning regressions/improvements in v4.9-rc3[1] compared to v4.8[2]. Summarized: - build errors: +176/-3 - build warnings: +1671/-1232 JFYI, when comparing v4.9-rc3[1] to v4.9-rc2[3], the summaries are: - build errors: +175/-38 - build warnings: +356/-420

Re: 4.9-rc1 boot regression, ambiguous bisect result

JFYI: I added this report to the list of regressions for Linux 4.9. I'll watch this thread for further updates on this issue to document progress in my weekly reports. Please let me know via regressi...@leemhuis.info in case the discussion moves to a different place (bugzilla or another mail

Build regressions/improvements in v4.9-rc3

Below is the list of build error/warning regressions/improvements in v4.9-rc3[1] compared to v4.8[2]. Summarized: - build errors: +176/-3 - build warnings: +1671/-1232 JFYI, when comparing v4.9-rc3[1] to v4.9-rc2[3], the summaries are: - build errors: +175/-38 - build warnings: +356/-420

Re: 4.9-rc1 boot regression, ambiguous bisect result

JFYI: I added this report to the list of regressions for Linux 4.9. I'll watch this thread for further updates on this issue to document progress in my weekly reports. Please let me know via regressi...@leemhuis.info in case the discussion moves to a different place (bugzilla or another mail

Re: [RFC 1/3] regulator: core: Add over current changed event

Hi Mark, On Sat, Oct 29, 2016 at 8:40 PM, Mark Brown wrote: > On Fri, Oct 28, 2016 at 09:41:44PM +0200, Axel Haslam wrote: > >> i think today each time an event occurs a notification is sent with the >> corresponding flag(s) set. > > Right, so I think the problem here is

Re: [RFC 1/3] regulator: core: Add over current changed event

Hi Mark, On Sat, Oct 29, 2016 at 8:40 PM, Mark Brown wrote: > On Fri, Oct 28, 2016 at 09:41:44PM +0200, Axel Haslam wrote: > >> i think today each time an event occurs a notification is sent with the >> corresponding flag(s) set. > > Right, so I think the problem here is actually that you called

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

John Heenan writes: > Code tests show data returned by rtl8xxxu_read8(priv, REG_CR), used to set > macpower, is never 0xea. It is only ever 0x01 (first time after modprobe) > using wpa_supplicant and 0x00 thereafter using wpa_supplicant. These results > occurs with 'Fix for

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

John Heenan writes: > Code tests show data returned by rtl8xxxu_read8(priv, REG_CR), used to set > macpower, is never 0xea. It is only ever 0x01 (first time after modprobe) > using wpa_supplicant and 0x00 thereafter using wpa_supplicant. These results > occurs with 'Fix for authentication

Re: [PATCH] drm/sun4i: Fix error handling

Hi, BTW, memory allocation in 'sun4i_layers_init()' looks spurious, especially the use of 'layer' in the for loop. Just my 2 cents. I also forgot to say that we could propagate the error code returned by sun4i_layers_init instead of returning -EINVAL unconditionally CJ Le 30/10/2016 à

Re: [PATCH] drm/sun4i: Fix error handling

Hi, BTW, memory allocation in 'sun4i_layers_init()' looks spurious, especially the use of 'layer' in the for loop. Just my 2 cents. I also forgot to say that we could propagate the error code returned by sun4i_layers_init instead of returning -EINVAL unconditionally CJ Le 30/10/2016 à

Re: [PATCH 10/15] ASoC: omap-mcbsp: use permission-specific DEVICE_ATTR variants

On Sun, 30 Oct 2016, Jarkko Nikula wrote: > Hi > > On Sat, 29 Oct 2016 21:37:04 +0200 > Julia Lawall wrote: > > > Use DEVICE_ATTR_RW for read-write attributes. This simplifies the > > source code, improves readbility, and reduces the chance of > > inconsistencies. > > >

Re: [PATCH 10/15] ASoC: omap-mcbsp: use permission-specific DEVICE_ATTR variants

On Sun, 30 Oct 2016, Jarkko Nikula wrote: > Hi > > On Sat, 29 Oct 2016 21:37:04 +0200 > Julia Lawall wrote: > > > Use DEVICE_ATTR_RW for read-write attributes. This simplifies the > > source code, improves readbility, and reduces the chance of > > inconsistencies. > > > ... > > > > -

{standard input}:108: Error: unknown opcode

Hi Rich, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 2a26d99b251b8625d27aed14e97fc10707a3a81f commit: b4214e41b7152b1964a3421a40251d202ae2d2c0 sh: add SMP support for J2 date: 3 months ago config:

{standard input}:108: Error: unknown opcode

Hi Rich, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 2a26d99b251b8625d27aed14e97fc10707a3a81f commit: b4214e41b7152b1964a3421a40251d202ae2d2c0 sh: add SMP support for J2 date: 3 months ago config:

[PATCH] idle/i7300: Add CONFIG_PCI dependency

From: Borislav Petkov ... in order to fix this randconfig build warning: drivers/idle/i7300_idle.c: In function ‘i7300_idle_stop’: ./include/asm-generic/bug.h:117:24: warning: ‘got_ctl’ is used uninitialized in this function [-Wuninitialized] int __ret_warn_once =

[PATCH] idle/i7300: Add CONFIG_PCI dependency

From: Borislav Petkov ... in order to fix this randconfig build warning: drivers/idle/i7300_idle.c: In function ‘i7300_idle_stop’: ./include/asm-generic/bug.h:117:24: warning: ‘got_ctl’ is used uninitialized in this function [-Wuninitialized] int __ret_warn_once = !!(condition); \

Re: [PATCH 10/15] ASoC: omap-mcbsp: use permission-specific DEVICE_ATTR variants

Hi On Sat, 29 Oct 2016 21:37:04 +0200 Julia Lawall wrote: > Use DEVICE_ATTR_RW for read-write attributes. This simplifies the > source code, improves readbility, and reduces the chance of > inconsistencies. > ... > > - DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\), x_show,

Re: [PATCH 10/15] ASoC: omap-mcbsp: use permission-specific DEVICE_ATTR variants

Hi On Sat, 29 Oct 2016 21:37:04 +0200 Julia Lawall wrote: > Use DEVICE_ATTR_RW for read-write attributes. This simplifies the > source code, improves readbility, and reduces the chance of > inconsistencies. > ... > > - DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\), x_show, x_store); > +

Re: [PATCH v2] rtc: add support for rtc NXP pca21125

Hi Venkat, On 19 October 2016 at 19:41, VENKAT PRASHANTH B U wrote: > This is a patch to add support for > NXP rtc pca21125 The register layout PCA21125 looks similar to PCF8563 which already has a driver. Would it be possible to support the PCA21125 device with

Re: [PATCH v2] rtc: add support for rtc NXP pca21125

Hi Venkat, On 19 October 2016 at 19:41, VENKAT PRASHANTH B U wrote: > This is a patch to add support for > NXP rtc pca21125 The register layout PCA21125 looks similar to PCF8563 which already has a driver. Would it be possible to support the PCA21125 device with the rtc-pcf8563 driver? You

RFC if==else in halbtc8723b1ant.c

Hi ! in your commit f5b586909581 ("rtlwifi: btcoexist: Modify driver to support BT coexistence in rtl8723be") you introduced a if/else where both branches are the same but the comment in the else branch suggests that this might be unintended. from code review only I can´t say what the

RFC if==else in halbtc8723b1ant.c

Hi ! in your commit f5b586909581 ("rtlwifi: btcoexist: Modify driver to support BT coexistence in rtl8723be") you introduced a if/else where both branches are the same but the comment in the else branch suggests that this might be unintended. from code review only I can´t say what the

Re: [REGRESSION, bisect] pci: artpec-6: imprecise external abort

FYI: I added this report to the list of regressions for Linux 4.9. I'll watch this thread for further updates on this issue to document progress in my weekly reports. Please let me know via regressi...@leemhuis.info in case the discussion moves to a different place (bugzilla or another mail thread

Re: [REGRESSION, bisect] pci: artpec-6: imprecise external abort

FYI: I added this report to the list of regressions for Linux 4.9. I'll watch this thread for further updates on this issue to document progress in my weekly reports. Please let me know via regressi...@leemhuis.info in case the discussion moves to a different place (bugzilla or another mail thread

Re: [PATCH] rtc: add support for rtc NXP pca8565

Hi Venkat, On 30 October 2016 at 09:03, VENKAT PRASHANTH B U wrote: > This is a patch to add support for > NXP rtc pca8565 >From a quick look the PCA8565 register layout looks very similar to PCF8563 which already has a driver (rtc-pcf8563). Can you use that

Re: [PATCH] rtc: add support for rtc NXP pca8565

Hi Venkat, On 30 October 2016 at 09:03, VENKAT PRASHANTH B U wrote: > This is a patch to add support for > NXP rtc pca8565 >From a quick look the PCA8565 register layout looks very similar to PCF8563 which already has a driver (rtc-pcf8563). Can you use that driver instead of creating a new

Re: [PATCH] aio: fix a user triggered use after free (and fix freeze protection of aio writes)

On Sun 30-10-16 10:44:37, Jan Kara wrote: > On Sat 29-10-16 13:09:25, Linus Torvalds wrote: > > On Sat, Oct 29, 2016 at 12:17 PM, Al Viro wrote: > > > > > > AFAICS, the possibility of dropping the last reference to struct file > > > before ->write_iter() has returned is

Re: [PATCH] aio: fix a user triggered use after free (and fix freeze protection of aio writes)

On Sun 30-10-16 10:44:37, Jan Kara wrote: > On Sat 29-10-16 13:09:25, Linus Torvalds wrote: > > On Sat, Oct 29, 2016 at 12:17 PM, Al Viro wrote: > > > > > > AFAICS, the possibility of dropping the last reference to struct file > > > before ->write_iter() has returned is fundamentally broken. I

Re: [GIT PULL] kbuild changes for v4.9-rc1

On 27.10.2016 10:10, Kalle Valo wrote: > (Adding Thorsten because of a serious regression and Steven because he > tried to fix something in the same commit) Many thx. I added this report to the list of regressions for Linux 4.9. I'll watch this thread for further updates on this issue to

Re: [GIT PULL] kbuild changes for v4.9-rc1

On 27.10.2016 10:10, Kalle Valo wrote: > (Adding Thorsten because of a serious regression and Steven because he > tried to fix something in the same commit) Many thx. I added this report to the list of regressions for Linux 4.9. I'll watch this thread for further updates on this issue to

[PATCH 1/2] NCR5380: Use probe_irq_*() for IRQ probing

Use standard probe_irq_on() and probe_irq_off() functions instead of own implementation. This prevents warning messages like this in the kernel log: genirq: Flags mismatch irq 1. (NCR-probe) vs. 0080 (i8042) Move the IRQ trigger code to a separate function so it can be used for other

[PATCH 1/2] NCR5380: Use probe_irq_*() for IRQ probing

Use standard probe_irq_on() and probe_irq_off() functions instead of own implementation. This prevents warning messages like this in the kernel log: genirq: Flags mismatch irq 1. (NCR-probe) vs. 0080 (i8042) Move the IRQ trigger code to a separate function so it can be used for other

[PATCH 2/2] g_NCR5380: Test the IRQ before accepting it

Trigger an IRQ first with a test IRQ handler to find out if it really works. Disable the IRQ if not. This prevents hang when incorrect IRQ was specified by user. Signed-off-by: Ondrej Zary --- drivers/scsi/g_NCR5380.c | 31 +-- 1 file

[PATCH 2/2] g_NCR5380: Test the IRQ before accepting it

Trigger an IRQ first with a test IRQ handler to find out if it really works. Disable the IRQ if not. This prevents hang when incorrect IRQ was specified by user. Signed-off-by: Ondrej Zary --- drivers/scsi/g_NCR5380.c | 31 +-- 1 file changed, 29 insertions(+), 2

Re: tpm_tis regression in 4.9?

FYI: I added this report to the list of regressions for Linux 4.9. I'll watch this thread for further updates on this issue to document progress in my weekly reports. Please let me know via regressi...@leemhuis.info in case the discussion moves to a different place (bugzilla or another mail thread

Re: tpm_tis regression in 4.9?

FYI: I added this report to the list of regressions for Linux 4.9. I'll watch this thread for further updates on this issue to document progress in my weekly reports. Please let me know via regressi...@leemhuis.info in case the discussion moves to a different place (bugzilla or another mail thread

Re: [PATCH 4.8 000/125] 4.8.6-stable review

On Sat, Oct 29, 2016 at 05:07:44PM -0600, Shuah Khan wrote: > On 10/29/2016 07:48 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.8.6 release. > > There are 125 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 4.8 000/125] 4.8.6-stable review

On Sat, Oct 29, 2016 at 05:44:38PM -0700, Guenter Roeck wrote: > On 10/29/2016 06:48 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.8.6 release. > > There are 125 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 4.8 000/125] 4.8.6-stable review

On Sat, Oct 29, 2016 at 05:07:44PM -0600, Shuah Khan wrote: > On 10/29/2016 07:48 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.8.6 release. > > There are 125 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 4.8 000/125] 4.8.6-stable review

On Sat, Oct 29, 2016 at 05:44:38PM -0700, Guenter Roeck wrote: > On 10/29/2016 06:48 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.8.6 release. > > There are 125 patches in this series, all will be posted as a response > > to this one. If anyone has any

[PATCH] sched, cgroup: enclose root_task_group with macro CONFIG_CGROUP_SCHED.

root_task_group defined in sched/core.c is enclosed by CONFIG_CGROUP_SCHED, so the export declaration should also be enclosed. Signed-off-by: Haishuang Yan --- include/linux/init_task.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

[PATCH] sched, cgroup: enclose root_task_group with macro CONFIG_CGROUP_SCHED.

root_task_group defined in sched/core.c is enclosed by CONFIG_CGROUP_SCHED, so the export declaration should also be enclosed. Signed-off-by: Haishuang Yan --- include/linux/init_task.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/include/linux/init_task.h

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

Code tests show data returned by rtl8xxxu_read8(priv, REG_CR), used to set macpower, is never 0xea. It is only ever 0x01 (first time after modprobe) using wpa_supplicant and 0x00 thereafter using wpa_supplicant. These results occurs with 'Fix for authentication failure' [PATCH 1/2] in place.

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

Code tests show data returned by rtl8xxxu_read8(priv, REG_CR), used to set macpower, is never 0xea. It is only ever 0x01 (first time after modprobe) using wpa_supplicant and 0x00 thereafter using wpa_supplicant. These results occurs with 'Fix for authentication failure' [PATCH 1/2] in place.

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

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 For exampe rtl8xxxu_init_device is now called each time userspace wpa_supplicant is executed instead of just once when modprobe is

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

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 For exampe rtl8xxxu_init_device is now called each time userspace wpa_supplicant is executed instead of just once when modprobe is

[PATCH 0/2] rtl8xxxu: Fix allows wpa_supplicant to authenticate

With the current kernel release, wpa_supplicant results in authentication failure with a Cube i9 tablet (a Surface Pro like device): Successfully initialized wpa_supplicant wlp0s20f0u7i2: SME: Trying to authenticate with 10:fe:ed:62:7a:78 (SSID='localre' freq=2417 MHz) wlp0s20f0u7i2: SME:

[PATCH 0/2] rtl8xxxu: Fix allows wpa_supplicant to authenticate

With the current kernel release, wpa_supplicant results in authentication failure with a Cube i9 tablet (a Surface Pro like device): Successfully initialized wpa_supplicant wlp0s20f0u7i2: SME: Trying to authenticate with 10:fe:ed:62:7a:78 (SSID='localre' freq=2417 MHz) wlp0s20f0u7i2: SME:

Re: [PATCH -next] brd: make symbol rd_size static

On Sat 29-10-16 16:10:27, Wei Yongjun wrote: > From: Wei Yongjun > > Fixes the following sparse warning: > > drivers/block/brd.c:411:15: warning: > symbol 'rd_size' was not declared. Should it be static? It should not. It is used in arch/arm/.

Re: [PATCH -next] brd: make symbol rd_size static

On Sat 29-10-16 16:10:27, Wei Yongjun wrote: > From: Wei Yongjun > > Fixes the following sparse warning: > > drivers/block/brd.c:411:15: warning: > symbol 'rd_size' was not declared. Should it be static? It should not. It is used in arch/arm/.

Re: [PATCH] console: use first console if stdout-path device doesn't appear

Any news? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."

Re: [PATCH] console: use first console if stdout-path device doesn't appear

Any news? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."

Re: [PATCH] aio: fix a user triggered use after free (and fix freeze protection of aio writes)

On Sat 29-10-16 13:09:25, Linus Torvalds wrote: > On Sat, Oct 29, 2016 at 12:17 PM, Al Viro wrote: > > > > AFAICS, the possibility of dropping the last reference to struct file > > before ->write_iter() has returned is fundamentally broken. I might be > > missing

Re: [PATCH] aio: fix a user triggered use after free (and fix freeze protection of aio writes)

On Sat 29-10-16 13:09:25, Linus Torvalds wrote: > On Sat, Oct 29, 2016 at 12:17 PM, Al Viro wrote: > > > > AFAICS, the possibility of dropping the last reference to struct file > > before ->write_iter() has returned is fundamentally broken. I might be > > missing something subtle here, but... >

cc1: error: '-march=r3000' requires '-mfp32'

Hi James, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 2a26d99b251b8625d27aed14e97fc10707a3a81f commit: 034827c727f7f3946a18355b63995b402c226c82 MIPS: Fix -mabi=64 build of vdso.lds date: 3 weeks ago config:

cc1: error: '-march=r3000' requires '-mfp32'

Hi James, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 2a26d99b251b8625d27aed14e97fc10707a3a81f commit: 034827c727f7f3946a18355b63995b402c226c82 MIPS: Fix -mabi=64 build of vdso.lds date: 3 weeks ago config:

pull-request: wireless-drivers-next 2016-10-30

Hi Dave, few fixes for 4.9. I tagged this on the plane over a slow mosh connection while travelling to Plumbers so I might have done something wrong, please check more carefully than usually. For example I had to redo the signed tag because of some whitespace damage. Please let me know if there

pull-request: wireless-drivers-next 2016-10-30

Hi Dave, few fixes for 4.9. I tagged this on the plane over a slow mosh connection while travelling to Plumbers so I might have done something wrong, please check more carefully than usually. For example I had to redo the signed tag because of some whitespace damage. Please let me know if there

Re: [PATCH 5/5] tty: amba-pl011: Add earlycon support for SBSA UART

On 2016/10/27 23:18, Greg Kroah-Hartman wrote: > On Mon, Oct 24, 2016 at 11:59:20AM +0800, Kefeng Wang wrote: >> Hi Greg, any more comments, thanks. > > Never wait, just resend if you have comments and you know you have to > fix them up... > Hi Greg, as I mentioned in previous mail,

Re: [PATCH 5/5] tty: amba-pl011: Add earlycon support for SBSA UART

On 2016/10/27 23:18, Greg Kroah-Hartman wrote: > On Mon, Oct 24, 2016 at 11:59:20AM +0800, Kefeng Wang wrote: >> Hi Greg, any more comments, thanks. > > Never wait, just resend if you have comments and you know you have to > fix them up... > Hi Greg, as I mentioned in previous mail,

<    2   3   4   5   6   7   8   >