[PATCH 2/2] staging: ccree: use sizeof(*var) in kmalloc

Fix the following checkpatch warning: CHECK: Prefer kmalloc(sizeof(*buff_mgr_handle)...) over kmalloc(sizeof(struct buff_mgr_handle)...) Signed-off-by: Gustavo A. R. Silva --- drivers/staging/ccree/ssi_buffer_mgr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH 2/2] staging: ccree: use sizeof(*var) in kmalloc

Fix the following checkpatch warning: CHECK: Prefer kmalloc(sizeof(*buff_mgr_handle)...) over kmalloc(sizeof(struct buff_mgr_handle)...) Signed-off-by: Gustavo A. R. Silva --- drivers/staging/ccree/ssi_buffer_mgr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 1/2] staging: ccree: remove unnecessary cast on kmalloc

The assignment operator implicitly converts a void pointer to the type of the pointer it is assigned to. This issue was detected using Coccinelle and the following semantic patch: @@ expression * e; expression arg1, arg2; type T; @@ - e=(T*) + e= kmalloc(arg1, arg2); Signed-off-by: Gustavo A.

[PATCH 1/2] staging: ccree: remove unnecessary cast on kmalloc

The assignment operator implicitly converts a void pointer to the type of the pointer it is assigned to. This issue was detected using Coccinelle and the following semantic patch: @@ expression * e; expression arg1, arg2; type T; @@ - e=(T*) + e= kmalloc(arg1, arg2); Signed-off-by: Gustavo A.

Re: [PATCH 1/3] ASoC: codec: cpcap: new codec

* Sebastian Reichel [170707 09:43]: > Motorola CPCAP is a PMIC with audio functionality, that can be > found on Motorola Droid 4 and probably a few other phones from > Motorola's Droid series. > > The driver has been written from scratch using Motorola's

Re: [PATCH 1/3] ASoC: codec: cpcap: new codec

* Sebastian Reichel [170707 09:43]: > Motorola CPCAP is a PMIC with audio functionality, that can be > found on Motorola Droid 4 and probably a few other phones from > Motorola's Droid series. > > The driver has been written from scratch using Motorola's Android > driver, register dumps from

Re: [PATCH v3 1/1] usb:host:xhci support option to disable the xHCI USB2 HW LPM

On Fri, Jun 23, 2017 at 10:02 AM, Thang Q. Nguyen wrote: > XHCI specification 1.1 does not require xHCI-compliant controllers > to always enable hardware USB2 LPM. However, the current xHCI > driver always enable it when seeing HLC=1. > This patch supports an option for users to

Re: [PATCH v3 1/1] usb:host:xhci support option to disable the xHCI USB2 HW LPM

On Fri, Jun 23, 2017 at 10:02 AM, Thang Q. Nguyen wrote: > XHCI specification 1.1 does not require xHCI-compliant controllers > to always enable hardware USB2 LPM. However, the current xHCI > driver always enable it when seeing HLC=1. > This patch supports an option for users to control disabling

Re: [PATCH 0/3] Motorola Droid 4 Audio Support

* Sebastian Reichel [170708 04:34]: > Hi, > > On Fri, Jul 07, 2017 at 10:27:53PM -0700, Tony Lindgren wrote: > > * Sebastian Reichel [170707 09:43]: > > > I got working sound on Droid 4 with mainline \o/. The codec is > > >

Re: [PATCH 0/3] Motorola Droid 4 Audio Support

* Sebastian Reichel [170708 04:34]: > Hi, > > On Fri, Jul 07, 2017 at 10:27:53PM -0700, Tony Lindgren wrote: > > * Sebastian Reichel [170707 09:43]: > > > I got working sound on Droid 4 with mainline \o/. The codec is > > > currently missing support for detecting if something has been > > >

[RFC PATCH] x86: enable dead code and data elimination (LTO)

Allow x86 to select DCDE option under CONFIG_EXPERT to reduce binary size. This is an RFC only for ~4.14/15 kernel. Sending as a single patch to make it easy to review and test for x86, and give other archs a base to look at. This is a _relatively_ simple and low overhead first step to getting

[RFC PATCH] x86: enable dead code and data elimination (LTO)

Allow x86 to select DCDE option under CONFIG_EXPERT to reduce binary size. This is an RFC only for ~4.14/15 kernel. Sending as a single patch to make it easy to review and test for x86, and give other archs a base to look at. This is a _relatively_ simple and low overhead first step to getting

[git pull] vfs.git waitid(2) fix

[I hoped to throw RWF_... annotations into the same pull request, but since hch still hasn't replied with s-o-b...] The following changes since commit da029c11e6b12f321f36dac8771e833b65cec962: exec: Limit arg stack to at most 75% of _STK_LIM (2017-07-07 20:05:08 -0700) are available in the

[git pull] vfs.git waitid(2) fix

[I hoped to throw RWF_... annotations into the same pull request, but since hch still hasn't replied with s-o-b...] The following changes since commit da029c11e6b12f321f36dac8771e833b65cec962: exec: Limit arg stack to at most 75% of _STK_LIM (2017-07-07 20:05:08 -0700) are available in the

[GIT PULL] ext4 updates for 4.13

The following changes since commit 67a7d5f561f469ad2fa5154d2888258ab8e6df7c: ext4: fix fdatasync(2) after extent manipulation operations (2017-05-29 13:24:55 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git tags/ext4_for_linus

[GIT PULL] ext4 updates for 4.13

The following changes since commit 67a7d5f561f469ad2fa5154d2888258ab8e6df7c: ext4: fix fdatasync(2) after extent manipulation operations (2017-05-29 13:24:55 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git tags/ext4_for_linus

[GIT PULL] fscrypt updates for 4.13

The following changes since commit 3c2993b8c6143d8a5793746a54eba8f86f95240f: Linux 4.12-rc4 (2017-06-04 16:47:43 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/fscrypt.git tags/fscrypt_for_linus for you to fetch changes up to

[GIT PULL] fscrypt updates for 4.13

The following changes since commit 3c2993b8c6143d8a5793746a54eba8f86f95240f: Linux 4.12-rc4 (2017-06-04 16:47:43 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/fscrypt.git tags/fscrypt_for_linus for you to fetch changes up to

Re: [PATCH 2/2] afs: Add metadata xattrs

On 7/8/2017 9:01 PM, Theodore Ts'o wrote: > On Sat, Jul 08, 2017 at 12:44:54PM -0700, Linus Torvalds wrote: >> Yeah, I think attributes are likely much better than some random crazy >> ioctl interface. They can be listed with generic tools, and have >> various scripting interfaces in ways that

Re: [PATCH 2/2] afs: Add metadata xattrs

On 7/8/2017 9:01 PM, Theodore Ts'o wrote: > On Sat, Jul 08, 2017 at 12:44:54PM -0700, Linus Torvalds wrote: >> Yeah, I think attributes are likely much better than some random crazy >> ioctl interface. They can be listed with generic tools, and have >> various scripting interfaces in ways that

Re: block: hung task writing to device

On 07/08/2017 01:06 PM, Levin, Alexander (Sasha Levin) wrote: > Hi all, > > syzkaller seems to be hitting a lockup with the reproducer below: Thanks for the reproducer, but this is missing a lot of detail that we need to debug this issue. Is this a regression since 4.12? What storage device is

Re: block: hung task writing to device

On 07/08/2017 01:06 PM, Levin, Alexander (Sasha Levin) wrote: > Hi all, > > syzkaller seems to be hitting a lockup with the reproducer below: Thanks for the reproducer, but this is missing a lot of detail that we need to debug this issue. Is this a regression since 4.12? What storage device is

Re: [PATCH] MIPS: Fix minimum alignment requirement of IRQ stack

Hi Matt, [auto build test WARNING on linus/master] [also build test WARNING on v4.12 next-20170707] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] MIPS: Fix minimum alignment requirement of IRQ stack

Hi Matt, [auto build test WARNING on linus/master] [also build test WARNING on v4.12 next-20170707] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 2/2] afs: Add metadata xattrs

On Sat, Jul 08, 2017 at 12:44:54PM -0700, Linus Torvalds wrote: > Yeah, I think attributes are likely much better than some random crazy > ioctl interface. They can be listed with generic tools, and have > various scripting interfaces in ways that ioctl's do not sanely have. I personally don't

Re: [PATCH 2/2] afs: Add metadata xattrs

On Sat, Jul 08, 2017 at 12:44:54PM -0700, Linus Torvalds wrote: > Yeah, I think attributes are likely much better than some random crazy > ioctl interface. They can be listed with generic tools, and have > various scripting interfaces in ways that ioctl's do not sanely have. I personally don't

Re: [PATCH] MIPS: Fix minimum alignment requirement of IRQ stack

Hi Matt, [auto build test ERROR on linus/master] [also build test ERROR on v4.12 next-20170707] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] MIPS: Fix minimum alignment requirement of IRQ stack

Hi Matt, [auto build test ERROR on linus/master] [also build test ERROR on v4.12 next-20170707] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [CIFS] Upgrade default dialect to SMB3 from cifs (SMB1) for improved security

I had missed a review comment from Pavel - now included, and the first patch updated to include that minor change. https://git.samba.org/?p=sfrench/cifs-2.6.git;a=commit;h=2a38e12053b760a8f5e85030eb89512660077c15 and

Re: [CIFS] Upgrade default dialect to SMB3 from cifs (SMB1) for improved security

I had missed a review comment from Pavel - now included, and the first patch updated to include that minor change. https://git.samba.org/?p=sfrench/cifs-2.6.git;a=commit;h=2a38e12053b760a8f5e85030eb89512660077c15 and

[no subject]

Good Day, I am Mr. Alfred Cheuk Yu Chow, the Director for Credit & Marketing Chong Hing Bank, Hong Kong, Chong Hing Bank Centre, 24 Des Voeux Road Central, Hong Kong. I have a business proposal of $38,980,369.00. All confirmable documents to back up the claims will be made available

[no subject]

Good Day, I am Mr. Alfred Cheuk Yu Chow, the Director for Credit & Marketing Chong Hing Bank, Hong Kong, Chong Hing Bank Centre, 24 Des Voeux Road Central, Hong Kong. I have a business proposal of $38,980,369.00. All confirmable documents to back up the claims will be made available

Re: [PATCH v1 1/1] mux: Add new API to get mux_control ref by device name.

Hi Andy, On 7/8/2017 2:26 PM, Andy Shevchenko wrote: On Sun, Jul 9, 2017 at 12:12 AM, Peter Rosin wrote: On 2017-07-08 00:03, sathyanarayanan.kuppusw...@linux.intel.com wrote: From: Kuppuswamy Sathyanarayanan Currently this

Re: [PATCH v1 1/1] mux: Add new API to get mux_control ref by device name.

Hi Andy, On 7/8/2017 2:26 PM, Andy Shevchenko wrote: On Sun, Jul 9, 2017 at 12:12 AM, Peter Rosin wrote: On 2017-07-08 00:03, sathyanarayanan.kuppusw...@linux.intel.com wrote: From: Kuppuswamy Sathyanarayanan Currently this driver only provides a single API, mux_control_get() to get

Re: [PATCH] ARM: dts: at91: sama5d2_xplained: use pin macros instead of numbers

Hi Ludovic, [auto build test ERROR on at91/at91-next] [also build test ERROR on v4.12 next-20170707] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] ARM: dts: at91: sama5d2_xplained: use pin macros instead of numbers

Hi Ludovic, [auto build test ERROR on at91/at91-next] [also build test ERROR on v4.12 next-20170707] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v1 1/1] mux: Add new API to get mux_control ref by device name.

Hi Peter, On 7/8/2017 2:12 PM, Peter Rosin wrote: On 2017-07-08 00:03, sathyanarayanan.kuppusw...@linux.intel.com wrote: From: Kuppuswamy Sathyanarayanan Currently this driver only provides a single API, mux_control_get() to get mux_control

Re: [PATCH v1 1/1] mux: Add new API to get mux_control ref by device name.

Hi Peter, On 7/8/2017 2:12 PM, Peter Rosin wrote: On 2017-07-08 00:03, sathyanarayanan.kuppusw...@linux.intel.com wrote: From: Kuppuswamy Sathyanarayanan Currently this driver only provides a single API, mux_control_get() to get mux_control reference based on mux_name, and also this API has

Re: [PATCH v2 1/1] mux: mux-core: Add NULL check for dev->of_node

Hi Peter, On 7/8/2017 2:00 PM, Peter Rosin wrote: On 2017-07-07 23:46, sathyanarayanan.kuppusw...@linux.intel.com wrote: From: Kuppuswamy Sathyanarayanan If dev->of_node is NULL, then calling mux_control_get() function can lead to NULL pointer

Re: [PATCH v2 1/1] mux: mux-core: Add NULL check for dev->of_node

Hi Peter, On 7/8/2017 2:00 PM, Peter Rosin wrote: On 2017-07-07 23:46, sathyanarayanan.kuppusw...@linux.intel.com wrote: From: Kuppuswamy Sathyanarayanan If dev->of_node is NULL, then calling mux_control_get() function can lead to NULL pointer exception. So adding a NULL check for

Re: [PATCH v2 4/7] [media] ov9650: use write_array() for resolution sequences

On Mon, Jul 03, 2017 at 11:16:05AM +0200, Hugues Fruchet wrote: > Align resolution sequences on initialization sequence using > i2c_rv structure NULL terminated .This add flexibility > on resolution sequence size. > Document resolution related registers by using corresponding > define instead of

Re: [PATCH v2 4/7] [media] ov9650: use write_array() for resolution sequences

On Mon, Jul 03, 2017 at 11:16:05AM +0200, Hugues Fruchet wrote: > Align resolution sequences on initialization sequence using > i2c_rv structure NULL terminated .This add flexibility > on resolution sequence size. > Document resolution related registers by using corresponding > define instead of

Re: [PATCH v2 3/7] [media] ov9650: add device tree support

Hi Hugues, On Mon, Jul 03, 2017 at 11:16:04AM +0200, Hugues Fruchet wrote: > Allows use of device tree configuration data. > If no device tree data is there, configuration is taken from platform data. > In order to keep GPIOs configuration compatible between both way of doing, > GPIOs are

Re: [PATCH v2 3/7] [media] ov9650: add device tree support

Hi Hugues, On Mon, Jul 03, 2017 at 11:16:04AM +0200, Hugues Fruchet wrote: > Allows use of device tree configuration data. > If no device tree data is there, configuration is taken from platform data. > In order to keep GPIOs configuration compatible between both way of doing, > GPIOs are

[PATCH] fs: show frozen status in mountinfo

Putting this in the mountinfo makes it non contractual, and purely available for the sake of helping out an administrator seeing blocking behavior. Signed-off-by: Florian Margaine --- fs/proc_namespace.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH] fs: show frozen status in mountinfo

Putting this in the mountinfo makes it non contractual, and purely available for the sake of helping out an administrator seeing blocking behavior. Signed-off-by: Florian Margaine --- fs/proc_namespace.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/proc_namespace.c

Re: [PATCH v1 1/1] mux: consumer: Add dummy functions for !CONFIG_MULTIPLEXER case

Hi Peter, On 7/8/2017 1:55 PM, Peter Rosin wrote: On 2017-07-07 23:41, sathyanarayanan.kuppusw...@linux.intel.com wrote: From: Kuppuswamy Sathyanarayanan Add dummy functions to avoid compile time issues when CONFIG_MULTIPLEXER is not enabled. Hi!

Re: [PATCH v1 1/1] mux: consumer: Add dummy functions for !CONFIG_MULTIPLEXER case

Hi Peter, On 7/8/2017 1:55 PM, Peter Rosin wrote: On 2017-07-07 23:41, sathyanarayanan.kuppusw...@linux.intel.com wrote: From: Kuppuswamy Sathyanarayanan Add dummy functions to avoid compile time issues when CONFIG_MULTIPLEXER is not enabled. Hi! Consumers should "select MULTIPLEXER", If

Re: [PATCH 2/2] staging: media: atomisp2: Replace kfree()/vfree() with kvfree()

On Sat, Jul 8, 2017 at 4:58 AM, Bernd Petrovitsch wrote: > On Fri, 2017-07-07 at 20:41 -0400, Amitoj Kaur Chawla wrote: > [...] >> --- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c >> +++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c >> @@

Re: [PATCH 2/2] staging: media: atomisp2: Replace kfree()/vfree() with kvfree()

On Sat, Jul 8, 2017 at 4:58 AM, Bernd Petrovitsch wrote: > On Fri, 2017-07-07 at 20:41 -0400, Amitoj Kaur Chawla wrote: > [...] >> --- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c >> +++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c >> @@ -117,11 +117,7 @@ void

[CIFS] Upgrade default dialect to SMB3 from cifs (SMB1) for improved security

Due to recent publicity about security vulnerabilities in the much older CIFS dialect, these patches move the default dialect to the widely accepted (and quite secure) SMB3.0 dialect from the old default of the CIFS dialect. We do not want to be encouraging use of less secure dialects, and both

[CIFS] Upgrade default dialect to SMB3 from cifs (SMB1) for improved security

Due to recent publicity about security vulnerabilities in the much older CIFS dialect, these patches move the default dialect to the widely accepted (and quite secure) SMB3.0 dialect from the old default of the CIFS dialect. We do not want to be encouraging use of less secure dialects, and both

[RFC/RFT PATCH 2/3] gpio: pxa: remove gpio_to_irq() from hw irq handlers

gpio_to_irq() API expected to be used by GPIO consumers and not drivers and there are no guarantee that its gpiolib implementation is irq safe. Signed-off-by: Grygorii Strashko --- drivers/gpio/gpio-pxa.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-)

[RFC/RFT PATCH 2/3] gpio: pxa: remove gpio_to_irq() from hw irq handlers

gpio_to_irq() API expected to be used by GPIO consumers and not drivers and there are no guarantee that its gpiolib implementation is irq safe. Signed-off-by: Grygorii Strashko --- drivers/gpio/gpio-pxa.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git

[RFC/RFT PATCH 3/3] gpiolib: make gpio irqchip compatible with sparse_irq

Now IRQ mappings are always created for all (allowed) GPIOs in gpio irqchip in gpiochip_irqchip_add_key() which goes against the idea of SPARSE_IRQ and, as result, leads to: - increasing of memory consumption because of allocated IRQ descriptors most of which will never ever be used (especially

[RFC/RFT PATCH 3/3] gpiolib: make gpio irqchip compatible with sparse_irq

Now IRQ mappings are always created for all (allowed) GPIOs in gpio irqchip in gpiochip_irqchip_add_key() which goes against the idea of SPARSE_IRQ and, as result, leads to: - increasing of memory consumption because of allocated IRQ descriptors most of which will never ever be used (especially

[PATCH] staging: wilc1000: add parameter name to function definition

Add missing parameter name to fix the following checkpatch.pl warning: WARNING: function definition argument 'struct device *' should also have an identifier name Signed-off-by: Dmitriy Cherkasov --- drivers/staging/wilc1000/wilc_wfi_netdevice.h | 4 ++-- 1 file changed,

[RFC/RFT PATCH 0/3] gpiolib: make gpio irqchip compatible with sparse_irq

The idea of this changes was inspired by discussion [1]. Now IRQ mappings are always created for all (allowed) GPIOs in GPIO irqchip in gpiochip_irqchip_add_key() and this goes against the idea of SPARSE_IRQ and, as result, leads to: - increasing of memory consumption because of allocated IRQ

[RFC/RFT PATCH 0/3] gpiolib: make gpio irqchip compatible with sparse_irq

The idea of this changes was inspired by discussion [1]. Now IRQ mappings are always created for all (allowed) GPIOs in GPIO irqchip in gpiochip_irqchip_add_key() and this goes against the idea of SPARSE_IRQ and, as result, leads to: - increasing of memory consumption because of allocated IRQ

[PATCH] staging: wilc1000: add parameter name to function definition

Add missing parameter name to fix the following checkpatch.pl warning: WARNING: function definition argument 'struct device *' should also have an identifier name Signed-off-by: Dmitriy Cherkasov --- drivers/staging/wilc1000/wilc_wfi_netdevice.h | 4 ++-- 1 file changed, 2 insertions(+), 2

[RFC/RFT PATCH 1/3] gpio: tegra: remove gpio_to_irq() from hw irq handlers

gpio_to_irq() API expected to be used by GPIO consumers and not drivers and there are no guarantee that its gpiolib implementation is irq safe. Signed-off-by: Grygorii Strashko --- drivers/gpio/gpio-tegra.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff

[RFC/RFT PATCH 1/3] gpio: tegra: remove gpio_to_irq() from hw irq handlers

gpio_to_irq() API expected to be used by GPIO consumers and not drivers and there are no guarantee that its gpiolib implementation is irq safe. Signed-off-by: Grygorii Strashko --- drivers/gpio/gpio-tegra.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[PATCH] staging: rtl8192u: Use __func__ instead of function name in strings

Replace hard-coded function names in strings with '"%s...", __func__' in the r8190_rtl8256.c file. Issue found by checkpatch.pl. Signed-off-by: Chris Coffey --- Patch generated on staging tree, staging-testing branch. drivers/staging/rtl8192u/r8190_rtl8256.c | 10

[PATCH] staging: rtl8192u: Use __func__ instead of function name in strings

Replace hard-coded function names in strings with '"%s...", __func__' in the r8190_rtl8256.c file. Issue found by checkpatch.pl. Signed-off-by: Chris Coffey --- Patch generated on staging tree, staging-testing branch. drivers/staging/rtl8192u/r8190_rtl8256.c | 10 +- 1 file changed, 5

Re: [PATCH] staging: atomisp: gc0310: constify acpi_device_id.

On Fri, Jul 07, 2017 at 11:47:43AM +0100, Alan Cox wrote: > On Thu, 2017-07-06 at 21:50 +0530, Arvind Yadav wrote: > > acpi_device_id are not supposed to change at runtime. All functions > > working with acpi_device_id provided by work with > > const acpi_device_id. So mark the non-const structs

Re: [PATCH] staging: atomisp: gc0310: constify acpi_device_id.

On Fri, Jul 07, 2017 at 11:47:43AM +0100, Alan Cox wrote: > On Thu, 2017-07-06 at 21:50 +0530, Arvind Yadav wrote: > > acpi_device_id are not supposed to change at runtime. All functions > > working with acpi_device_id provided by work with > > const acpi_device_id. So mark the non-const structs

Re: [PATCH] spi: pxa2xx: Only claim CS GPIOs when the slave device is created

On Sat, Jul 8, 2017 at 11:41 AM, Jan Kiszka wrote: > From: Jan Kiszka > > Avoid hogging chip select GPIOs just because they are listed for the > master. They might be mulitplexed and, if no slave device is attached, > used for different purposes.

Re: [PATCH] spi: pxa2xx: Only claim CS GPIOs when the slave device is created

On Sat, Jul 8, 2017 at 11:41 AM, Jan Kiszka wrote: > From: Jan Kiszka > > Avoid hogging chip select GPIOs just because they are listed for the > master. They might be mulitplexed and, if no slave device is attached, > used for different purposes. Moreover, this strategy avoids having to >

Re: [musl] [PATCHv2] uapi libc compat: add fallback for unsupported libcs

Hauke Mehrtens wrote: > > > On 07/08/2017 10:27 PM, Felix Janda wrote: > > libc-compat.h aims to prevent symbol collisions between uapi and libc > > headers for each supported libc. This requires continuous coordination > > between them. > > > > The goal of this commit is to improve the

Re: [musl] [PATCHv2] uapi libc compat: add fallback for unsupported libcs

Hauke Mehrtens wrote: > > > On 07/08/2017 10:27 PM, Felix Janda wrote: > > libc-compat.h aims to prevent symbol collisions between uapi and libc > > headers for each supported libc. This requires continuous coordination > > between them. > > > > The goal of this commit is to improve the

[PATCH] drm: inhibit drm drivers register to uninitialized drm core

If the DRM core fails to init for whatever reason, ensure that no driver ever calls drm_dev_register(). This is best done at drm_dev_init() as it covers drivers that call drm_dev_alloc() as well as drivers that prefer to embed struct drm_device into their own device struct and call drm_dev_init()

[PATCH] drm: inhibit drm drivers register to uninitialized drm core

If the DRM core fails to init for whatever reason, ensure that no driver ever calls drm_dev_register(). This is best done at drm_dev_init() as it covers drivers that call drm_dev_alloc() as well as drivers that prefer to embed struct drm_device into their own device struct and call drm_dev_init()

Re: [PATCHv4 3/3] i2c: altera: Add Altera I2C Controller driver

On Sat, Jul 8, 2017 at 12:08 AM, Thor Thayer wrote: > On 07/07/2017 11:25 AM, Andy Shevchenko wrote: >> On Mon, Jun 19, 2017 at 11:36 PM, wrote: >>> + while (bytes_to_transfer-- > 0) { >>> + *idev->buf++ =

Re: [PATCHv4 3/3] i2c: altera: Add Altera I2C Controller driver

On Sat, Jul 8, 2017 at 12:08 AM, Thor Thayer wrote: > On 07/07/2017 11:25 AM, Andy Shevchenko wrote: >> On Mon, Jun 19, 2017 at 11:36 PM, wrote: >>> + while (bytes_to_transfer-- > 0) { >>> + *idev->buf++ = readl(idev->base + ALTR_I2C_RX_DATA); >>> + if

Re: [PATCH v1 1/1] mux: Add new API to get mux_control ref by device name.

On Sun, Jul 9, 2017 at 12:12 AM, Peter Rosin wrote: > On 2017-07-08 00:03, sathyanarayanan.kuppusw...@linux.intel.com wrote: >> From: Kuppuswamy Sathyanarayanan >> >> Currently this driver only provides a single API, mux_control_get()

Re: [PATCH v1 1/1] mux: Add new API to get mux_control ref by device name.

On Sun, Jul 9, 2017 at 12:12 AM, Peter Rosin wrote: > On 2017-07-08 00:03, sathyanarayanan.kuppusw...@linux.intel.com wrote: >> From: Kuppuswamy Sathyanarayanan >> >> Currently this driver only provides a single API, mux_control_get() to >> get mux_control reference based on mux_name, and also

Re: [PATCH v2 1/1] mux: consumer: Add dummy functions for !CONFIG_MULTIPLEXER case

On Sat, Jul 8, 2017 at 9:12 PM, wrote: > From: Kuppuswamy Sathyanarayanan > > Add dummy functions to avoid compile time issues when CONFIG_MULTIPLEXER > is not enabled. > I don't think the error return code

Re: [PATCH v2 1/1] mux: consumer: Add dummy functions for !CONFIG_MULTIPLEXER case

On Sat, Jul 8, 2017 at 9:12 PM, wrote: > From: Kuppuswamy Sathyanarayanan > > Add dummy functions to avoid compile time issues when CONFIG_MULTIPLEXER > is not enabled. > I don't think the error return code is okay to all of them. The return value should be choosen carefully (for some functions

Re: [musl] [PATCHv2] uapi libc compat: add fallback for unsupported libcs

On 07/08/2017 10:27 PM, Felix Janda wrote: > libc-compat.h aims to prevent symbol collisions between uapi and libc > headers for each supported libc. This requires continuous coordination > between them. > > The goal of this commit is to improve the situation for libcs (such as > musl) which

Re: [musl] [PATCHv2] uapi libc compat: add fallback for unsupported libcs

On 07/08/2017 10:27 PM, Felix Janda wrote: > libc-compat.h aims to prevent symbol collisions between uapi and libc > headers for each supported libc. This requires continuous coordination > between them. > > The goal of this commit is to improve the situation for libcs (such as > musl) which

Re: [PATCH v1 1/1] mux: Add new API to get mux_control ref by device name.

On 2017-07-08 00:03, sathyanarayanan.kuppusw...@linux.intel.com wrote: > From: Kuppuswamy Sathyanarayanan > > Currently this driver only provides a single API, mux_control_get() to > get mux_control reference based on mux_name, and also this API has

Re: [PATCH v1 1/1] mux: Add new API to get mux_control ref by device name.

On 2017-07-08 00:03, sathyanarayanan.kuppusw...@linux.intel.com wrote: > From: Kuppuswamy Sathyanarayanan > > Currently this driver only provides a single API, mux_control_get() to > get mux_control reference based on mux_name, and also this API has tight > dependency on device tree node. For

Re: [PATCH v2 1/1] mux: mux-core: Add NULL check for dev->of_node

On 2017-07-07 23:46, sathyanarayanan.kuppusw...@linux.intel.com wrote: > From: Kuppuswamy Sathyanarayanan > > If dev->of_node is NULL, then calling mux_control_get() > function can lead to NULL pointer exception. So adding > a NULL check for

Re: [PATCH v2 1/1] mux: mux-core: Add NULL check for dev->of_node

On 2017-07-07 23:46, sathyanarayanan.kuppusw...@linux.intel.com wrote: > From: Kuppuswamy Sathyanarayanan > > If dev->of_node is NULL, then calling mux_control_get() > function can lead to NULL pointer exception. So adding > a NULL check for dev->of_node. > > Signed-off-by: Kuppuswamy

Re: [PATCH v1 1/1] mux: mux-core: Unregister mux_class in mux_exit()

On 2017-07-07 23:50, sathyanarayanan.kuppusw...@linux.intel.com wrote: > From: Kuppuswamy Sathyanarayanan > > Signed-off-by: Kuppuswamy Sathyanarayanan > Good catch! However, I do not like the empty

Re: [PATCH v1 1/1] mux: mux-core: Unregister mux_class in mux_exit()

On 2017-07-07 23:50, sathyanarayanan.kuppusw...@linux.intel.com wrote: > From: Kuppuswamy Sathyanarayanan > > Signed-off-by: Kuppuswamy Sathyanarayanan > Good catch! However, I do not like the empty commit message, please add a sentence about how this fixes a typo or something, and also

[PATCH] cachefiles: Remove unnecessary comparisons in daemon.c

Remove unnecessary comparisons of unsigned variables with zero. Signed-off-by: Christos Gkekas --- fs/cachefiles/daemon.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/cachefiles/daemon.c b/fs/cachefiles/daemon.c index 1ee54ff..ce072ce

[PATCH] cachefiles: Remove unnecessary comparisons in daemon.c

Remove unnecessary comparisons of unsigned variables with zero. Signed-off-by: Christos Gkekas --- fs/cachefiles/daemon.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/cachefiles/daemon.c b/fs/cachefiles/daemon.c index 1ee54ff..ce072ce 100644 ---

Re: [PATCH v1 0/6] Add support of OV9655 camera

Hi Nikolaus, On Wed, Jul 05, 2017 at 04:02:04PM +0200, H. Nikolaus Schaller wrote: > Hi Sakari, > > > Am 03.07.2017 um 14:23 schrieb H. Nikolaus Schaller : > > > > Hi Hugues, > > > >> Am 03.07.2017 um 14:03 schrieb Hugues FRUCHET : > >> > >> Hi

Re: [PATCH v1 0/6] Add support of OV9655 camera

Hi Nikolaus, On Wed, Jul 05, 2017 at 04:02:04PM +0200, H. Nikolaus Schaller wrote: > Hi Sakari, > > > Am 03.07.2017 um 14:23 schrieb H. Nikolaus Schaller : > > > > Hi Hugues, > > > >> Am 03.07.2017 um 14:03 schrieb Hugues FRUCHET : > >> > >> Hi Nikolaus, > >> > >> nothing really strange in

Re: [PATCH v1 1/1] mux: consumer: Add dummy functions for !CONFIG_MULTIPLEXER case

On 2017-07-07 23:41, sathyanarayanan.kuppusw...@linux.intel.com wrote: > From: Kuppuswamy Sathyanarayanan > > Add dummy functions to avoid compile time issues when CONFIG_MULTIPLEXER > is not enabled. Hi! Consumers should "select MULTIPLEXER", so

Re: [PATCH v1 1/1] mux: consumer: Add dummy functions for !CONFIG_MULTIPLEXER case

On 2017-07-07 23:41, sathyanarayanan.kuppusw...@linux.intel.com wrote: > From: Kuppuswamy Sathyanarayanan > > Add dummy functions to avoid compile time issues when CONFIG_MULTIPLEXER > is not enabled. Hi! Consumers should "select MULTIPLEXER", so this does not make sense. Or do you have a

[GIT PULL] PCI changes for v4.13

PCI changes: - add sysfs max_link_speed/width, current_link_speed/width (Wong Vee Khee) - make host bridge IRQ mapping much more generic (Matthew Minter, Lorenzo Pieralisi) - convert most drivers to pci_scan_root_bus_bridge() (Lorenzo Pieralisi) - mutex sriov_configure() (Jakub

[GIT PULL] PCI changes for v4.13

PCI changes: - add sysfs max_link_speed/width, current_link_speed/width (Wong Vee Khee) - make host bridge IRQ mapping much more generic (Matthew Minter, Lorenzo Pieralisi) - convert most drivers to pci_scan_root_bus_bridge() (Lorenzo Pieralisi) - mutex sriov_configure() (Jakub

Re: [PATCH 3/4] percpu: expose statistics about percpu memory via debugfs

On Fri, Jul 07, 2017 at 10:16:01AM +0200, Geert Uytterhoeven wrote: > Hi Dennis, > > On Tue, Jun 20, 2017 at 1:28 AM, Dennis Zhou wrote: > > Just wondering: does this option make sense to enable on !SMP? > > If not, you may want to make it depend on SMP. > > Thanks! > >

Re: [PATCH 3/4] percpu: expose statistics about percpu memory via debugfs

On Fri, Jul 07, 2017 at 10:16:01AM +0200, Geert Uytterhoeven wrote: > Hi Dennis, > > On Tue, Jun 20, 2017 at 1:28 AM, Dennis Zhou wrote: > > Just wondering: does this option make sense to enable on !SMP? > > If not, you may want to make it depend on SMP. > > Thanks! > > Gr{oetje,eeting}s, >

[PATCHv2] uapi libc compat: add fallback for unsupported libcs

libc-compat.h aims to prevent symbol collisions between uapi and libc headers for each supported libc. This requires continuous coordination between them. The goal of this commit is to improve the situation for libcs (such as musl) which are not yet supported and/or do not wish to be explicitly

Re: [musl] Re: [PATCH resent] uapi libc compat: allow non-glibc to opt out of uapi definitions

Carlos O'Donell wrote: > On 04/25/2017 02:37 AM, Hauke Mehrtens wrote: > > > > > > On 03/08/2017 01:46 PM, David Woodhouse wrote: > >> On Fri, 2016-11-11 at 07:08 -0500, Felix Janda wrote: > >>> Currently, libc-compat.h detects inclusion of specific glibc headers, > >>> and defines corresponding

[PATCHv2] uapi libc compat: add fallback for unsupported libcs

libc-compat.h aims to prevent symbol collisions between uapi and libc headers for each supported libc. This requires continuous coordination between them. The goal of this commit is to improve the situation for libcs (such as musl) which are not yet supported and/or do not wish to be explicitly

Re: [musl] Re: [PATCH resent] uapi libc compat: allow non-glibc to opt out of uapi definitions

Carlos O'Donell wrote: > On 04/25/2017 02:37 AM, Hauke Mehrtens wrote: > > > > > > On 03/08/2017 01:46 PM, David Woodhouse wrote: > >> On Fri, 2016-11-11 at 07:08 -0500, Felix Janda wrote: > >>> Currently, libc-compat.h detects inclusion of specific glibc headers, > >>> and defines corresponding

  1   2   3   4   >