Re: RK3288 USB Issues

Hello, did you try without your patches, to see if you can reproduce the problem? I can fix my issues if I disable usb autosuspend To narrow down the causes I can think of: *) Some hardware issue only on my side -> please try to reproduce it with an unpached kernel *) Some other stuff I modified

Re: RK3288 USB Issues

Hello, did you try without your patches, to see if you can reproduce the problem? I can fix my issues if I disable usb autosuspend To narrow down the causes I can think of: *) Some hardware issue only on my side -> please try to reproduce it with an unpached kernel *) Some other stuff I modified

[PATCH] drm/tegra: sor: No need to free devm_ allocated memory

'brick' has been allocated by 'devm_kzalloc', so there is no need here to free it explicitly. There is only one caller of 'tegra_clk_sor_brick_register()'. This function is a probe function which correctly checks and handles the return value of 'tegra_clk_sor_brick_register()'. Signed-off-by:

[PATCH] drm/tegra: sor: No need to free devm_ allocated memory

'brick' has been allocated by 'devm_kzalloc', so there is no need here to free it explicitly. There is only one caller of 'tegra_clk_sor_brick_register()'. This function is a probe function which correctly checks and handles the return value of 'tegra_clk_sor_brick_register()'. Signed-off-by:

[PATCH v6 1/3] ASoC: sun4i-codec: Rename sun4i_codec_widgets for consistency

Rename "sun4i_codec_widgets" to "sun4i_codec_controls" for consistency with the struct field name. Signed-off-by: Danny Milosavljevic --- sound/soc/sunxi/sun4i-codec.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/soc/sunxi/sun4i-codec.c

[PATCH v6 1/3] ASoC: sun4i-codec: Rename sun4i_codec_widgets for consistency

Rename "sun4i_codec_widgets" to "sun4i_codec_controls" for consistency with the struct field name. Signed-off-by: Danny Milosavljevic --- sound/soc/sunxi/sun4i-codec.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/soc/sunxi/sun4i-codec.c

[PATCH v6 0/3] ASoC: sun4i-codec: Distinguish sun4i from sun7i

Introduce mechanism to detect sun7i and provide a different regmap (different compared to sun4i Allwinner A10). The controls will be extended in a forthcoming patch - it is necessary to distinguish between sun4i and sun7i controls because they have different registers. Rename

[PATCH v6 0/3] ASoC: sun4i-codec: Distinguish sun4i from sun7i

Introduce mechanism to detect sun7i and provide a different regmap (different compared to sun4i Allwinner A10). The controls will be extended in a forthcoming patch - it is necessary to distinguish between sun4i and sun7i controls because they have different registers. Rename

[PATCH v6 2/3] ASoC: sun4i-codec: Rename some sun7i-only registers

Some of the registers defined in the driver are only usable on the A20. Rename these registers. Signed-off-by: Danny Milosavljevic --- sound/soc/sunxi/sun4i-codec.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/soc/sunxi/sun4i-codec.c

[PATCH v6 3/3] ASoC: sun4i-codec: Add custom regmap configs

The A20 has a few extra registers that the A10 doesn't have. Therefore, use different regmaps for A10 as compared to A20. Signed-off-by: Danny Milosavljevic --- sound/soc/sunxi/sun4i-codec.c | 38 +++--- 1 file changed, 35 insertions(+), 3

[PATCH v6 2/3] ASoC: sun4i-codec: Rename some sun7i-only registers

Some of the registers defined in the driver are only usable on the A20. Rename these registers. Signed-off-by: Danny Milosavljevic --- sound/soc/sunxi/sun4i-codec.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/soc/sunxi/sun4i-codec.c

[PATCH v6 3/3] ASoC: sun4i-codec: Add custom regmap configs

The A20 has a few extra registers that the A10 doesn't have. Therefore, use different regmaps for A10 as compared to A20. Signed-off-by: Danny Milosavljevic --- sound/soc/sunxi/sun4i-codec.c | 38 +++--- 1 file changed, 35 insertions(+), 3 deletions(-) diff

Huge static buffer in liquidio

Hello, I would like to discuss this commit: commit d3d7e6c65f75de18ced10a98595a847f9f95f0ce Author: Raghu Vatsavayi Date: Tue Jun 21 22:53:07 2016 -0700 liquidio: Firmware image download This patch has firmware image related changes for: firmware

Huge static buffer in liquidio

Hello, I would like to discuss this commit: commit d3d7e6c65f75de18ced10a98595a847f9f95f0ce Author: Raghu Vatsavayi Date: Tue Jun 21 22:53:07 2016 -0700 liquidio: Firmware image download This patch has firmware image related changes for: firmware release upon failure, support

Re: [PATCH] realtek: Add switch variable to 'switch case not processed' messages

Larry Finger writes: > On 09/24/2016 12:32 PM, Joe Perches wrote: >> Is there any value in that or is Jes' work going to make >> doing any or all of this unnecessary and futile? > > That is not yet determined. The only driver that is to be replaced at > this point is

Re: [PATCH] realtek: Add switch variable to 'switch case not processed' messages

Larry Finger writes: > On 09/24/2016 12:32 PM, Joe Perches wrote: >> Is there any value in that or is Jes' work going to make >> doing any or all of this unnecessary and futile? > > That is not yet determined. The only driver that is to be replaced at > this point is rtl8192cu. Jes only has USB

Re: Input-gameport: Replace some printk() calls by pr_info() in joydump_connect()

>> Should the desired output be the same when the relevant data are passed by a >> single function call >> (instead of three as before)? > > Adding a singleton for a pr_fmt #define constant string and > updating the printk subsystem to prepend that constant string > to each use of a pr_ at

Re: Input-gameport: Replace some printk() calls by pr_info() in joydump_connect()

>> Should the desired output be the same when the relevant data are passed by a >> single function call >> (instead of three as before)? > > Adding a singleton for a pr_fmt #define constant string and > updating the printk subsystem to prepend that constant string > to each use of a pr_ at

[PATCH 1/3] g_NCR5380: Remove deprecated __setup

Remove deprecated __setup for parsing command line parameters. g_NCR5380.* parameters could be used instead. Signed-off-by: Ondrej Zary --- drivers/scsi/g_NCR5380.c | 135 -- 1 file changed, 135 deletions(-) diff --git

[PATCH 2/3] g_NCR5380: Reduce overrides[] from array to struct

Remove compile-time card type definition GENERIC_NCR5380_OVERRIDE. Then remove all code iterating the overrides[] array and reduce it to struct card. Signed-off-by: Ondrej Zary --- drivers/scsi/g_NCR5380.c | 351 ++ 1 file

[PATCH 1/3] g_NCR5380: Remove deprecated __setup

Remove deprecated __setup for parsing command line parameters. g_NCR5380.* parameters could be used instead. Signed-off-by: Ondrej Zary --- drivers/scsi/g_NCR5380.c | 135 -- 1 file changed, 135 deletions(-) diff --git a/drivers/scsi/g_NCR5380.c

[PATCH 2/3] g_NCR5380: Reduce overrides[] from array to struct

Remove compile-time card type definition GENERIC_NCR5380_OVERRIDE. Then remove all code iterating the overrides[] array and reduce it to struct card. Signed-off-by: Ondrej Zary --- drivers/scsi/g_NCR5380.c | 351 ++ 1 file changed, 167 insertions(+),

[PATCH 0/3] g_NCR5380: Modernization

This small patch series removes deprecated code from g_NCR5380 driver and converts it from scsi_module.c to scsi_add_host(). Tested with: HP C2502 (53C400A chip) Canon FG2-5202 (53C400 chip, memory-mapped) DTC-3181L (DTCT-436P chip, PnP) P.S. I don't like the ifdef mess needed for

[PATCH 0/3] g_NCR5380: Modernization

This small patch series removes deprecated code from g_NCR5380 driver and converts it from scsi_module.c to scsi_add_host(). Tested with: HP C2502 (53C400A chip) Canon FG2-5202 (53C400 chip, memory-mapped) DTC-3181L (DTCT-436P chip, PnP) P.S. I don't like the ifdef mess needed for

[PATCH 3/3] g_NCR5380: Stop using scsi_module.c

Convert g_NCR5380 to use scsi_add_host instead of scsi_module.c Use pnp_driver and isa_driver to manage cards. Signed-off-by: Ondrej Zary --- drivers/scsi/g_NCR5380.c | 310 +- drivers/scsi/g_NCR5380.h |8 -- 2 files

[PATCH 3/3] g_NCR5380: Stop using scsi_module.c

Convert g_NCR5380 to use scsi_add_host instead of scsi_module.c Use pnp_driver and isa_driver to manage cards. Signed-off-by: Ondrej Zary --- drivers/scsi/g_NCR5380.c | 310 +- drivers/scsi/g_NCR5380.h |8 -- 2 files changed, 169 insertions(+),

Re: [PATCH] HSI: omap_ssi_core: move function declaration to header file

Hi, On Sat, Sep 24, 2016 at 10:58:15AM +0200, Arnd Bergmann wrote: > On Saturday, September 24, 2016 1:11:56 PM CEST Baoyou Xie wrote: > > --- > > drivers/hsi/clients/ssi_protocol.c | 2 -- > > include/linux/hsi/hsi.h| 1 + > > 2 files changed, 1 insertion(+), 2 deletions(-) > > > >

Re: [PATCH] HSI: omap_ssi_core: move function declaration to header file

Hi, On Sat, Sep 24, 2016 at 10:58:15AM +0200, Arnd Bergmann wrote: > On Saturday, September 24, 2016 1:11:56 PM CEST Baoyou Xie wrote: > > --- > > drivers/hsi/clients/ssi_protocol.c | 2 -- > > include/linux/hsi/hsi.h| 1 + > > 2 files changed, 1 insertion(+), 2 deletions(-) > > > >

[GIT pull] perf fixes for 4.8

Linus, please pull the latest perf-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf-urgent-for-linus Three fixlets for perf: - Add a missing NULL pointer check in the intel BTS driver. - Make BTS an exclusive PMU because BTS can only

[GIT pull] perf fixes for 4.8

Linus, please pull the latest perf-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf-urgent-for-linus Three fixlets for perf: - Add a missing NULL pointer check in the intel BTS driver. - Make BTS an exclusive PMU because BTS can only

[GIT pull] locking fixes for 4.8

Linus, please pull the latest locking-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking-urgent-for-linus Two smallish fixes: - Use the proper asm constraint in the Super-H atomic_fetch_ops - A trivial typo fix in the Kconfig help text

[GIT pull] locking fixes for 4.8

Linus, please pull the latest locking-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking-urgent-for-linus Two smallish fixes: - Use the proper asm constraint in the Super-H atomic_fetch_ops - A trivial typo fix in the Kconfig help text

[GIT pull] efi fixes for 4.8

Linus, please pull the latest efi-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi-urgent-for-linus Two fixes for EFI/PAT: - A 32bit overflow bug in the PAT code which was unearthed by the large EFI mappings - Prevent a boot hang on large

[GIT pull] efi fixes for 4.8

Linus, please pull the latest efi-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi-urgent-for-linus Two fixes for EFI/PAT: - A 32bit overflow bug in the PAT code which was unearthed by the large EFI mappings - Prevent a boot hang on large

[GIT pull] irq fixes for 4.8

Linus, please pull the latest irq-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-urgent-for-linus Three fixes for irq core and irq chip drivers - Do not set the irq type if type is NONE. Fixes a boot regression on various SoCs - Use

[GIT pull] irq fixes for 4.8

Linus, please pull the latest irq-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-urgent-for-linus Three fixes for irq core and irq chip drivers - Do not set the irq type if type is NONE. Fixes a boot regression on various SoCs - Use

Re: iio: Rename a jump label in iio_buffer_store_watermark()

> I'm not necessarily against this change which does perhaps clarify the code > ever so slightly, Thanks for another bit of positive feedback. > but I am interested to know where 'current Linux coding style convention' > comes from? How often do you check the status of a document like

Re: iio: Rename a jump label in iio_buffer_store_watermark()

> I'm not necessarily against this change which does perhaps clarify the code > ever so slightly, Thanks for another bit of positive feedback. > but I am interested to know where 'current Linux coding style convention' > comes from? How often do you check the status of a document like

Re: [PATCH v3 1/2] leds: ncp5623: Add device tree binding documentation

On 09/24/2016 01:58 PM, Pavel Machek wrote: Hi! +Example +=== + +led1: ncp5623@38 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "onnn,ncp5623"; + reg = <0x38>; + onnn,led-iref-microamp = <10>; + + led1r@0 { + label =

Re: [PATCH v3 1/2] leds: ncp5623: Add device tree binding documentation

On 09/24/2016 01:58 PM, Pavel Machek wrote: Hi! +Example +=== + +led1: ncp5623@38 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "onnn,ncp5623"; + reg = <0x38>; + onnn,led-iref-microamp = <10>; + + led1r@0 { + label =

Re: [PATCH] realtek: Add switch variable to 'switch case not processed' messages

On 09/24/2016 12:32 PM, Joe Perches wrote: (adding Jes Sorensen to recipients) On Sat, 2016-09-24 at 11:35 -0500, Larry Finger wrote: I have patches that makes HAL_DEF_WOWLAN be a no-op for the rest of the drivers, and one that sets the enum values for that particular statement to hex values.

Re: [PATCH] realtek: Add switch variable to 'switch case not processed' messages

On 09/24/2016 12:32 PM, Joe Perches wrote: (adding Jes Sorensen to recipients) On Sat, 2016-09-24 at 11:35 -0500, Larry Finger wrote: I have patches that makes HAL_DEF_WOWLAN be a no-op for the rest of the drivers, and one that sets the enum values for that particular statement to hex values.

Re: Input-evdev: Use kmalloc_array() in evdev_handle_get_val()

> Again, what is the purpose of the changes? I came also along a few source code places where their maintainers requested the usage of a function like "kmalloc_array". How do you think about to clarify the consistent use of programming interfaces for Linux a bit more? > Are you working on the

Re: Input-evdev: Use kmalloc_array() in evdev_handle_get_val()

> Again, what is the purpose of the changes? I came also along a few source code places where their maintainers requested the usage of a function like "kmalloc_array". How do you think about to clarify the consistent use of programming interfaces for Linux a bit more? > Are you working on the

Re: RK3288 USB Issues

On 09/23/2016 03:10 PM, Norbert Lange wrote: Hi, I wanted to reply to the Linux mailing List (your patch thread), I dont know exactly where since the addresses are blanked out. Just tell me where I should move this discussion. The board can use both USB peripherals (haven`t tested the OTG

Re: RK3288 USB Issues

On 09/23/2016 03:10 PM, Norbert Lange wrote: Hi, I wanted to reply to the Linux mailing List (your patch thread), I dont know exactly where since the addresses are blanked out. Just tell me where I should move this discussion. The board can use both USB peripherals (haven`t tested the OTG

Re: [PATCH 1/3] devicetree: bindings: scsi: hisi_sas hip07 support

On 23/09/2016 19:36, Rob Herring wrote: On Tue, Sep 20, 2016 at 06:48:58PM +0800, John Garry wrote: Add support for hip07 chipset to bindings. Chipset hip07 has v2 hw. The sas-v2 quirk amt is expanded to cover hip07. Signed-off-by: John Garry Signed-off-by: Xiang Chen

Re: [PATCH 1/3] devicetree: bindings: scsi: hisi_sas hip07 support

On 23/09/2016 19:36, Rob Herring wrote: On Tue, Sep 20, 2016 at 06:48:58PM +0800, John Garry wrote: Add support for hip07 chipset to bindings. Chipset hip07 has v2 hw. The sas-v2 quirk amt is expanded to cover hip07. Signed-off-by: John Garry Signed-off-by: Xiang Chen ---

[PATCH v8 1/3] phy: Add reset callback for not generic phy

I forget to add a dummy function in case the CONFIG_GENERIC_PHY is disabled. Signed-off-by: Randy Li --- include/linux/phy/phy.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h index ee1bed7..78bb0d7 100644 ---

[PATCH v8 3/3] ARM: dts: rockchip: Point rk3288 dwc2 usb at the full PHY reset

The "host1" port (AKA the dwc2 port that isn't the OTG port) on rk3288 has a hardware errata that causes everything to get confused when we get a remote wakeup. We'll use the reset that's in the CRU to reset the port when it's in a bad state. Note that we add the reset to both dwc2 controllers

[PATCH v8 1/3] phy: Add reset callback for not generic phy

I forget to add a dummy function in case the CONFIG_GENERIC_PHY is disabled. Signed-off-by: Randy Li --- include/linux/phy/phy.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h index ee1bed7..78bb0d7 100644 ---

[PATCH v8 3/3] ARM: dts: rockchip: Point rk3288 dwc2 usb at the full PHY reset

The "host1" port (AKA the dwc2 port that isn't the OTG port) on rk3288 has a hardware errata that causes everything to get confused when we get a remote wakeup. We'll use the reset that's in the CRU to reset the port when it's in a bad state. Note that we add the reset to both dwc2 controllers

[PATCH v8 2/3] usb: dwc2: assert phy reset when waking up in rk3288 platform

On the rk3288 USB host-only port (the one that's not the OTG-enabled port) the PHY can get into a bad state when a wakeup is asserted (not just a wakeup from full system suspend but also a wakeup from autosuspend). We can get the PHY out of its bad state by asserting its "port reset", but

[PATCH v8 0/3] the fixup for the USB HOST1 at rk3288 platform

At this stage it is the only "full features" and well verified USB EHCI controller in this platform. More review is always necessary. Although V7 is almost fine but a forget a dummy function for the phy system. changelog: v7 add the forgot dummy phy_reset() for the generic phy is disabled.

[PATCH v8 2/3] usb: dwc2: assert phy reset when waking up in rk3288 platform

On the rk3288 USB host-only port (the one that's not the OTG-enabled port) the PHY can get into a bad state when a wakeup is asserted (not just a wakeup from full system suspend but also a wakeup from autosuspend). We can get the PHY out of its bad state by asserting its "port reset", but

[PATCH v8 0/3] the fixup for the USB HOST1 at rk3288 platform

At this stage it is the only "full features" and well verified USB EHCI controller in this platform. More review is always necessary. Although V7 is almost fine but a forget a dummy function for the phy system. changelog: v7 add the forgot dummy phy_reset() for the generic phy is disabled.

Re: [PATCH v3 2/2] leds: Add driver for NCP5623 3-channel I2C LED driver

On 09/24/2016 02:00 PM, Pavel Machek wrote: Hi! Instead I propose the following: n_iled_max = 31 - (priv->led_iref * 2400 / priv->leds_max_current + !!(priv->led_iref * 2400 % priv->leds_max_current)) div_round_up? Exactly. Thanks. -- Best regards, Jacek Anaszewski

Re: [PATCH v3 2/2] leds: Add driver for NCP5623 3-channel I2C LED driver

On 09/24/2016 02:00 PM, Pavel Machek wrote: Hi! Instead I propose the following: n_iled_max = 31 - (priv->led_iref * 2400 / priv->leds_max_current + !!(priv->led_iref * 2400 % priv->leds_max_current)) div_round_up? Exactly. Thanks. -- Best regards, Jacek Anaszewski

Re: Input-gameport: Add the macro "pr_fmt" for module "joydump"

> When a chorus of voices says to you that you are wasting > their time, perhaps you listen to their song. I am listening to some degree. - I guess that I am making some decisions and conclusions in a way that you would prefer to be different. I know that my update suggestions won't be liked by

Re: Input-gameport: Add the macro "pr_fmt" for module "joydump"

> When a chorus of voices says to you that you are wasting > their time, perhaps you listen to their song. I am listening to some degree. - I guess that I am making some decisions and conclusions in a way that you would prefer to be different. I know that my update suggestions won't be liked by

Re: [PATCH 4/5] input: touchscreen: support Allwinner SoCs' touchscreen

Hi Quentin, On Sat, Sep 24, 2016 at 08:26:08PM +0200, Quentin Schulz wrote: > Hi Dimitry, > > Sorry for the (long) delay, I did not have time to work on it. I'll > mainly work in my free time now. > > On 20/07/2016 19:25, Dmitry Torokhov wrote: > > Hi Quentin, > > > > On Wed, Jul 20, 2016 at

Re: [PATCH 4/5] input: touchscreen: support Allwinner SoCs' touchscreen

Hi Quentin, On Sat, Sep 24, 2016 at 08:26:08PM +0200, Quentin Schulz wrote: > Hi Dimitry, > > Sorry for the (long) delay, I did not have time to work on it. I'll > mainly work in my free time now. > > On 20/07/2016 19:25, Dmitry Torokhov wrote: > > Hi Quentin, > > > > On Wed, Jul 20, 2016 at

Re: Input-evdev: Use kmalloc_array() in evdev_handle_get_val()

On Sat, Sep 24, 2016 at 08:16:16PM +0200, SF Markus Elfring wrote: > > So we have to multiply twice now, once in kmalloc_array, the second > > time in memcpy(). > > It looks so in the source code after the suggested refactoring. > > > > No, thank you. > > Would you like to check any further if

Re: Input-evdev: Use kmalloc_array() in evdev_handle_get_val()

On Sat, Sep 24, 2016 at 08:16:16PM +0200, SF Markus Elfring wrote: > > So we have to multiply twice now, once in kmalloc_array, the second > > time in memcpy(). > > It looks so in the source code after the suggested refactoring. > > > > No, thank you. > > Would you like to check any further if

Re: [PATCH v3] add u64 number parser

On Sat, Sep 24, 2016 at 8:27 AM, James Smart wrote: > > add u64 number parser > > Prior patch revised to use kasprintf. > Modified match_number to use kasprintf as well Why would you do this? It's insane. kasprintf() is not the right thing at all to use for anything

Re: [PATCH v3] add u64 number parser

On Sat, Sep 24, 2016 at 8:27 AM, James Smart wrote: > > add u64 number parser > > Prior patch revised to use kasprintf. > Modified match_number to use kasprintf as well Why would you do this? It's insane. kasprintf() is not the right thing at all to use for anything like this. It appears that

Re: [PATCH 4/5] input: touchscreen: support Allwinner SoCs' touchscreen

Hi Dimitry, Sorry for the (long) delay, I did not have time to work on it. I'll mainly work in my free time now. On 20/07/2016 19:25, Dmitry Torokhov wrote: > Hi Quentin, > > On Wed, Jul 20, 2016 at 10:29:10AM +0200, Quentin Schulz wrote: >> This adds support for Allwinner SoCs' (A10, A13 and

Re: [PATCH 4/5] input: touchscreen: support Allwinner SoCs' touchscreen

Hi Dimitry, Sorry for the (long) delay, I did not have time to work on it. I'll mainly work in my free time now. On 20/07/2016 19:25, Dmitry Torokhov wrote: > Hi Quentin, > > On Wed, Jul 20, 2016 at 10:29:10AM +0200, Quentin Schulz wrote: >> This adds support for Allwinner SoCs' (A10, A13 and

Re: [f2fs-dev] [PATCH 1/2] f2fs: use crc and cp version to determine roll-forward recovery

On Sat, Sep 24, 2016 at 02:00:41PM +0800, Chao Yu wrote: > On 2016/9/21 8:45, Jaegeuk Kim wrote: > > @@ -259,40 +290,26 @@ static inline void fill_node_footer_blkaddr(struct > > page *page, block_t blkaddr) > > { > > struct f2fs_checkpoint *ckpt = F2FS_CKPT(F2FS_P_SB(page)); > > struct

Re: [f2fs-dev] [PATCH 1/2] f2fs: use crc and cp version to determine roll-forward recovery

On Sat, Sep 24, 2016 at 02:00:41PM +0800, Chao Yu wrote: > On 2016/9/21 8:45, Jaegeuk Kim wrote: > > @@ -259,40 +290,26 @@ static inline void fill_node_footer_blkaddr(struct > > page *page, block_t blkaddr) > > { > > struct f2fs_checkpoint *ckpt = F2FS_CKPT(F2FS_P_SB(page)); > > struct

Re: Input-evdev: Use kmalloc_array() in evdev_handle_get_val()

> So we have to multiply twice now, once in kmalloc_array, the second > time in memcpy(). It looks so in the source code after the suggested refactoring. > No, thank you. Would you like to check any further if a specific compiler implementation will still optimise common subexpressions as you

Re: Input-evdev: Use kmalloc_array() in evdev_handle_get_val()

> So we have to multiply twice now, once in kmalloc_array, the second > time in memcpy(). It looks so in the source code after the suggested refactoring. > No, thank you. Would you like to check any further if a specific compiler implementation will still optimise common subexpressions as you

Re: [PATCH 2/3] f2fs: support checkpoint error injection

On Sat, Sep 24, 2016 at 11:32:08AM +0800, Chao Yu wrote: > On 2016/9/24 8:52, Jaegeuk Kim wrote: > > On Sat, Sep 24, 2016 at 08:46:54AM +0800, Chao Yu wrote: > >> Hi Jaegeuk, > >> > >> On 2016/9/24 7:53, Jaegeuk Kim wrote: > >>> Hi Chao, > >>> > >>> The basic rule is to stop every operations once

Re: [PATCH 2/3] f2fs: support checkpoint error injection

On Sat, Sep 24, 2016 at 11:32:08AM +0800, Chao Yu wrote: > On 2016/9/24 8:52, Jaegeuk Kim wrote: > > On Sat, Sep 24, 2016 at 08:46:54AM +0800, Chao Yu wrote: > >> Hi Jaegeuk, > >> > >> On 2016/9/24 7:53, Jaegeuk Kim wrote: > >>> Hi Chao, > >>> > >>> The basic rule is to stop every operations once

[PATCH v3] bpf: Set register type according to is_valid_access()

This prevent future potential pointer leaks when an unprivileged eBPF program will read a pointer value from its context. Even if is_valid_access() returns a pointer type, the eBPF verifier replace it with UNKNOWN_VALUE. The register value that contains a kernel address is then allowed to leak.

[PATCH v3] bpf: Set register type according to is_valid_access()

This prevent future potential pointer leaks when an unprivileged eBPF program will read a pointer value from its context. Even if is_valid_access() returns a pointer type, the eBPF verifier replace it with UNKNOWN_VALUE. The register value that contains a kernel address is then allowed to leak.

Re: Input-gameport: Add the macro "pr_fmt" for module "joydump"

On Sat, 2016-09-24 at 19:45 +0200, SF Markus Elfring wrote: > > It's purposeless, creates unnecessary patches to review > > and generally wastes other people's time. > I have got an other opinion about this. Nice for you, not nice for others that have to act on your patch proposals to get them

Re: Input-gameport: Add the macro "pr_fmt" for module "joydump"

On Sat, 2016-09-24 at 19:45 +0200, SF Markus Elfring wrote: > > It's purposeless, creates unnecessary patches to review > > and generally wastes other people's time. > I have got an other opinion about this. Nice for you, not nice for others that have to act on your patch proposals to get them

Re: [PATCH 1/2] Input-evdev: Use kmalloc_array() in evdev_handle_get_val()

On Sat, Sep 24, 2016 at 4:08 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 24 Sep 2016 12:42:45 +0200 > > * A multiplication for the size determination of a memory allocation > indicated that an array data

Re: [PATCH 1/2] Input-evdev: Use kmalloc_array() in evdev_handle_get_val()

On Sat, Sep 24, 2016 at 4:08 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 24 Sep 2016 12:42:45 +0200 > > * A multiplication for the size determination of a memory allocation > indicated that an array data structure should be processed. > Thus use the corresponding

Re: [PATCH v3 3/8] drivers:input:tsc2007: add iio interface to read external ADC input, temperature and raw conversion values

Hi Dmitry, > Am 24.09.2016 um 19:44 schrieb Dmitry Torokhov : > > On Sat, Sep 24, 2016 at 10:07 AM, H. Nikolaus Schaller > wrote: >> Hi Jonathan, >> >>> Am 24.09.2016 um 18:07 schrieb Jonathan Cameron : >>> >>> On 23/09/16

Re: [PATCH v3 3/8] drivers:input:tsc2007: add iio interface to read external ADC input, temperature and raw conversion values

Hi Dmitry, > Am 24.09.2016 um 19:44 schrieb Dmitry Torokhov : > > On Sat, Sep 24, 2016 at 10:07 AM, H. Nikolaus Schaller > wrote: >> Hi Jonathan, >> >>> Am 24.09.2016 um 18:07 schrieb Jonathan Cameron : >>> >>> On 23/09/16 13:41, H. Nikolaus Schaller wrote: The tsc2007 chip not only has

Re: [PATCH] f2fs: remove dirty inode pages in error path

On Sat, Sep 24, 2016 at 09:02:02AM +0800, Chao Yu wrote: > On 2016/9/24 5:11, Jaegeuk Kim wrote: > > When getting EIO while handling orphan inodes, we can get some dirty node > > pages. Then, f2fs_write_node_pages() called by iput(node_inode) will try > > to flush node pages. But in this case, we

Re: [PATCH] f2fs: remove dirty inode pages in error path

On Sat, Sep 24, 2016 at 09:02:02AM +0800, Chao Yu wrote: > On 2016/9/24 5:11, Jaegeuk Kim wrote: > > When getting EIO while handling orphan inodes, we can get some dirty node > > pages. Then, f2fs_write_node_pages() called by iput(node_inode) will try > > to flush node pages. But in this case, we

Re: [PATCH 2/2] Input-evdev: Rename a jump label in two functions

On Sat, Sep 24, 2016 at 4:10 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 24 Sep 2016 12:50:31 +0200 > > Adjust a jump label according to the current Linux coding style convention. > Thus replace the identifier

Re: [PATCH 2/2] Input-evdev: Rename a jump label in two functions

On Sat, Sep 24, 2016 at 4:10 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 24 Sep 2016 12:50:31 +0200 > > Adjust a jump label according to the current Linux coding style convention. > Thus replace the identifier "out" by "unlock". No, just no. > > Signed-off-by: Markus

Re: Input-gameport: Add the macro "pr_fmt" for module "joydump"

>> I find that it is a preparation. - If this addition could not be accepted, >> the following update step would also be discussed under an other perspective, >> wouldn't it? > > It's purposeless, creates unnecessary patches to review > and generally wastes other people's time. I have got an

Re: Input-gameport: Add the macro "pr_fmt" for module "joydump"

>> I find that it is a preparation. - If this addition could not be accepted, >> the following update step would also be discussed under an other perspective, >> wouldn't it? > > It's purposeless, creates unnecessary patches to review > and generally wastes other people's time. I have got an

Re: [PATCH v3 3/8] drivers:input:tsc2007: add iio interface to read external ADC input, temperature and raw conversion values

On Sat, Sep 24, 2016 at 10:07 AM, H. Nikolaus Schaller wrote: > Hi Jonathan, > >> Am 24.09.2016 um 18:07 schrieb Jonathan Cameron : >> >> On 23/09/16 13:41, H. Nikolaus Schaller wrote: >>> The tsc2007 chip not only has a resistive touch screen controller but

Re: [PATCH v3 3/8] drivers:input:tsc2007: add iio interface to read external ADC input, temperature and raw conversion values

On Sat, Sep 24, 2016 at 10:07 AM, H. Nikolaus Schaller wrote: > Hi Jonathan, > >> Am 24.09.2016 um 18:07 schrieb Jonathan Cameron : >> >> On 23/09/16 13:41, H. Nikolaus Schaller wrote: >>> The tsc2007 chip not only has a resistive touch screen controller but >>> also an external AUX adc imput

Re: [PATCH v3 3/8] drivers:input:tsc2007: add iio interface to read external ADC input, temperature and raw conversion values

Hi Jonathan, > Am 24.09.2016 um 19:26 schrieb Jonathan Cameron : > > On 24/09/16 18:07, H. Nikolaus Schaller wrote: >> Hi Jonathan, >> >>> Am 24.09.2016 um 18:07 schrieb Jonathan Cameron : >>> >>> On 23/09/16 13:41, H. Nikolaus Schaller wrote: The

Re: [PATCH v3 3/8] drivers:input:tsc2007: add iio interface to read external ADC input, temperature and raw conversion values

Hi Jonathan, > Am 24.09.2016 um 19:26 schrieb Jonathan Cameron : > > On 24/09/16 18:07, H. Nikolaus Schaller wrote: >> Hi Jonathan, >> >>> Am 24.09.2016 um 18:07 schrieb Jonathan Cameron : >>> >>> On 23/09/16 13:41, H. Nikolaus Schaller wrote: The tsc2007 chip not only has a resistive

Re: [RFC] fs: add userspace critical mounts event support

On Fri, Sep 23, 2016 at 6:37 PM, Herbert, Marc wrote: > On 03/09/2016 11:10, Dmitry Torokhov wrote: >> I was thinking if we kernel could post >> "conditions" (maybe simple stings) that it waits for, and userspace >> could unlock these "conditions". One of them might be

[PATCH] greybus: audio: fix uninitialized variable errors found by cppcheck

Currently, if info is null, the dev_err message is dereferencing an uninitialized module pointer. Instead, it should use codec->dev pointer in dev_err call and better align with other err msg in this function. Also, ret variable might be used uninitialized in a specific case. Avoid using it this

Re: [RFC] fs: add userspace critical mounts event support

On Fri, Sep 23, 2016 at 6:37 PM, Herbert, Marc wrote: > On 03/09/2016 11:10, Dmitry Torokhov wrote: >> I was thinking if we kernel could post >> "conditions" (maybe simple stings) that it waits for, and userspace >> could unlock these "conditions". One of them might be "firmware >> available". >

[PATCH] greybus: audio: fix uninitialized variable errors found by cppcheck

Currently, if info is null, the dev_err message is dereferencing an uninitialized module pointer. Instead, it should use codec->dev pointer in dev_err call and better align with other err msg in this function. Also, ret variable might be used uninitialized in a specific case. Avoid using it this

Re: [PATCH 3/5] iio: adc: sunxi-gpadc-iio: enable iio_buffers

Hi Jonathan, Sorry for the (long) delay, I did not have time to work on it. I'll mainly work in my free time now. Keep in mind this patch was proposed based on the v2 of the ADC patches. Since then, substantial changes have been made and I'm working on rebasing this series of patches on the v6,

Re: [PATCH 3/5] iio: adc: sunxi-gpadc-iio: enable iio_buffers

Hi Jonathan, Sorry for the (long) delay, I did not have time to work on it. I'll mainly work in my free time now. Keep in mind this patch was proposed based on the v2 of the ADC patches. Since then, substantial changes have been made and I'm working on rebasing this series of patches on the v6,

Re: [PATCH] realtek: Add switch variable to 'switch case not processed' messages

(adding Jes Sorensen to recipients) On Sat, 2016-09-24 at 11:35 -0500, Larry Finger wrote: > I have patches that makes HAL_DEF_WOWLAN be a no-op for the rest of the > drivers,  > and one that sets the enum values for that particular statement to hex > values. I  > also looked at the other large

Re: [PATCH] realtek: Add switch variable to 'switch case not processed' messages

(adding Jes Sorensen to recipients) On Sat, 2016-09-24 at 11:35 -0500, Larry Finger wrote: > I have patches that makes HAL_DEF_WOWLAN be a no-op for the rest of the > drivers,  > and one that sets the enum values for that particular statement to hex > values. I  > also looked at the other large

<    1   2   3   4   5   >