Re: [GIT PULL 2/2] arm64 dts: exynos: Last round for v4.12

On Thu, Apr 27, 2017 at 09:46:03PM +0200, Arnd Bergmann wrote: > On Fri, Apr 21, 2017 at 6:40 PM, Krzysztof Kozlowski wrote: > > The following changes since commit e3c07546747cdec07ff15c984bc6cebc9c9f788c: > > > > arm64: dts: exynos: Add the burst and esc clock frequency

Re: [GIT PULL 2/2] arm64 dts: exynos: Last round for v4.12

On Thu, Apr 27, 2017 at 09:46:03PM +0200, Arnd Bergmann wrote: > On Fri, Apr 21, 2017 at 6:40 PM, Krzysztof Kozlowski wrote: > > The following changes since commit e3c07546747cdec07ff15c984bc6cebc9c9f788c: > > > > arm64: dts: exynos: Add the burst and esc clock frequency properties to > > DSI

[PATCH 2/2] of_coresight: Use devm_kcalloc() in of_coresight_alloc_memory()

From: Markus Elfring Date: Thu, 27 Apr 2017 21:29:12 +0200 Multiplications for the size determination of memory allocations indicated that array data structures should be processed. Thus use the corresponding function "devm_kcalloc". This issue was detected by

[PATCH 2/2] of_coresight: Use devm_kcalloc() in of_coresight_alloc_memory()

From: Markus Elfring Date: Thu, 27 Apr 2017 21:29:12 +0200 Multiplications for the size determination of memory allocations indicated that array data structures should be processed. Thus use the corresponding function "devm_kcalloc". This issue was detected by using the Coccinelle software.

[PATCH 1/2] coresight-stm: Use devm_kcalloc() in stm_probe()

From: Markus Elfring Date: Thu, 27 Apr 2017 21:18:57 +0200 * A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "devm_kcalloc". This issue was

[PATCH 1/2] coresight-stm: Use devm_kcalloc() in stm_probe()

From: Markus Elfring Date: Thu, 27 Apr 2017 21:18:57 +0200 * A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "devm_kcalloc". This issue was detected by using the Coccinelle

Re: [GIT PULL 2/2] arm64 dts: exynos: Last round for v4.12

On Fri, Apr 21, 2017 at 6:40 PM, Krzysztof Kozlowski wrote: > The following changes since commit e3c07546747cdec07ff15c984bc6cebc9c9f788c: > > arm64: dts: exynos: Add the burst and esc clock frequency properties to DSI > node (2017-03-08 08:55:39 +0200) > > are available in

Re: [GIT PULL 2/2] arm64 dts: exynos: Last round for v4.12

On Fri, Apr 21, 2017 at 6:40 PM, Krzysztof Kozlowski wrote: > The following changes since commit e3c07546747cdec07ff15c984bc6cebc9c9f788c: > > arm64: dts: exynos: Add the burst and esc clock frequency properties to DSI > node (2017-03-08 08:55:39 +0200) > > are available in the git repository

[PATCH 0/2] hwtracing-coresight: Fine-tuning for two function implementations

From: Markus Elfring Date: Thu, 27 Apr 2017 21:34:32 +0200 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Use devm_kcalloc() in stm_probe() Use devm_kcalloc() in of_coresight_alloc_memory()

[PATCH 0/2] hwtracing-coresight: Fine-tuning for two function implementations

From: Markus Elfring Date: Thu, 27 Apr 2017 21:34:32 +0200 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Use devm_kcalloc() in stm_probe() Use devm_kcalloc() in of_coresight_alloc_memory() drivers/hwtracing/coresight/coresight-stm.c |

Re: [PATCH v3] libnvdimm, region: sysfs trigger for nvdimm_flush()

Dan Williams writes: > We also still seem to need a discovery mechanism as I've had questions > about "how do I tell if my system supports deep flush?". That's where > sysfs is much better than an ioctl. The need for deep flush discovery > tips the scales, at least for

Re: [PATCH v3] libnvdimm, region: sysfs trigger for nvdimm_flush()

Dan Williams writes: > We also still seem to need a discovery mechanism as I've had questions > about "how do I tell if my system supports deep flush?". That's where > sysfs is much better than an ioctl. The need for deep flush discovery > tips the scales, at least for me, to also do deep flush

Re: [PATCH net-next 10/18] net: dsa: mv88e6xxx: move STU GetNext operation

On Wed, Apr 26, 2017 at 11:53:28AM -0400, Vivien Didelot wrote: > Extract the generic portion of code to issue an STU GetNext operation, > which will be used in other implementations. > > Signed-off-by: Vivien Didelot Reviewed-by: Andrew Lunn

Re: [PATCH net-next 10/18] net: dsa: mv88e6xxx: move STU GetNext operation

On Wed, Apr 26, 2017 at 11:53:28AM -0400, Vivien Didelot wrote: > Extract the generic portion of code to issue an STU GetNext operation, > which will be used in other implementations. > > Signed-off-by: Vivien Didelot Reviewed-by: Andrew Lunn Andrew

Re: [PATCH v3] libnvdimm, region: sysfs trigger for nvdimm_flush()

Dan Williams writes: > On Thu, Apr 27, 2017 at 11:41 AM, Jeff Moyer wrote: >> Dan Williams writes: >> The sentiment is that programs shouldn't have to grovel around in sysfs to do stuff related to an open file

Re: [PATCH v3] libnvdimm, region: sysfs trigger for nvdimm_flush()

Dan Williams writes: > On Thu, Apr 27, 2017 at 11:41 AM, Jeff Moyer wrote: >> Dan Williams writes: >> The sentiment is that programs shouldn't have to grovel around in sysfs to do stuff related to an open file descriptor or mapping. I don't take issue with the name. I do worry

Re: [PATCH] ubifs: Return -ENOKEY from rename if encryption keys are missing

Hi David, On Thu, Apr 27, 2017 at 10:59:15AM +0200, David Oberhollenzer wrote: > > Are you sure? I just tried rebasing my ubifs support patches for xfstests > > and > > xfstests-bld onto the latest xfstests and xfstests-bld respectively, then > > building a new kvm-xfstests appliance and the

Re: [PATCH] ubifs: Return -ENOKEY from rename if encryption keys are missing

Hi David, On Thu, Apr 27, 2017 at 10:59:15AM +0200, David Oberhollenzer wrote: > > Are you sure? I just tried rebasing my ubifs support patches for xfstests > > and > > xfstests-bld onto the latest xfstests and xfstests-bld respectively, then > > building a new kvm-xfstests appliance and the

Re: AMD IOMMU causing filesystem corruption

On 04/26/2017 02:43 PM, Joerg Roedel wrote: On Wed, Apr 26, 2017 at 02:31:40PM -0700, Samuel Sieb wrote: This test was done with the patch that always disables ATS. Which is the current patch to selectively disable it? The last patch I tried didn't seem to work. Its [PATCH v2] PCI:

Re: AMD IOMMU causing filesystem corruption

On 04/26/2017 02:43 PM, Joerg Roedel wrote: On Wed, Apr 26, 2017 at 02:31:40PM -0700, Samuel Sieb wrote: This test was done with the patch that always disables ATS. Which is the current patch to selectively disable it? The last patch I tried didn't seem to work. Its [PATCH v2] PCI:

Re: [PATCH v3] libnvdimm, region: sysfs trigger for nvdimm_flush()

On Thu, Apr 27, 2017 at 12:17 PM, Dan Williams wrote: > On Thu, Apr 27, 2017 at 11:41 AM, Jeff Moyer wrote: >> Dan Williams writes: >> The sentiment is that programs shouldn't have to grovel around in sysfs to do

Re: [PATCH v3] libnvdimm, region: sysfs trigger for nvdimm_flush()

On Thu, Apr 27, 2017 at 12:17 PM, Dan Williams wrote: > On Thu, Apr 27, 2017 at 11:41 AM, Jeff Moyer wrote: >> Dan Williams writes: >> The sentiment is that programs shouldn't have to grovel around in sysfs to do stuff related to an open file descriptor or mapping. I don't take

Re: [PATCH net-next 09/18] net: dsa: mv88e6xxx: move VTU Data accessors

On Wed, Apr 26, 2017 at 11:53:27AM -0400, Vivien Didelot wrote: > The code to access the VTU Data registers currently only supports the > 88E6185 family and alike: 2-bit membership adjacent to 2-bit port state. > > Even though the 88E6352 family introduced an indirect table to program > the VLAN

Re: [PATCH net-next 09/18] net: dsa: mv88e6xxx: move VTU Data accessors

On Wed, Apr 26, 2017 at 11:53:27AM -0400, Vivien Didelot wrote: > The code to access the VTU Data registers currently only supports the > 88E6185 family and alike: 2-bit membership adjacent to 2-bit port state. > > Even though the 88E6352 family introduced an indirect table to program > the VLAN

Re: [PATCH v3] libnvdimm, region: sysfs trigger for nvdimm_flush()

On Thu, Apr 27, 2017 at 11:41 AM, Jeff Moyer wrote: > Dan Williams writes: > >>> The sentiment is that programs shouldn't have to grovel around in sysfs >>> to do stuff related to an open file descriptor or mapping. I don't take >>> issue with the

Re: [PATCH v3] libnvdimm, region: sysfs trigger for nvdimm_flush()

On Thu, Apr 27, 2017 at 11:41 AM, Jeff Moyer wrote: > Dan Williams writes: > >>> The sentiment is that programs shouldn't have to grovel around in sysfs >>> to do stuff related to an open file descriptor or mapping. I don't take >>> issue with the name. I do worry that something like

Re: [RESEND PATCH 1/2] arc: axs10x: Add DT bindings for I2S audio playback

On 04/27/2017 11:42 AM, Jose Abreu wrote: > Hi Vineet, > > > On 27-04-2017 00:31, Vineet Gupta wrote: >> On 04/26/2017 01:55 AM, Jose Abreu wrote: >>> Hi Vineet, >>> >>> >>> On 24-04-2017 18:36, Vineet Gupta wrote: On 04/21/2017 03:15 AM, Jose Abreu wrote: > This patch adds the necessary

Re: [RESEND PATCH 1/2] arc: axs10x: Add DT bindings for I2S audio playback

On 04/27/2017 11:42 AM, Jose Abreu wrote: > Hi Vineet, > > > On 27-04-2017 00:31, Vineet Gupta wrote: >> On 04/26/2017 01:55 AM, Jose Abreu wrote: >>> Hi Vineet, >>> >>> >>> On 24-04-2017 18:36, Vineet Gupta wrote: On 04/21/2017 03:15 AM, Jose Abreu wrote: > This patch adds the necessary

[PATCH] power: supply: axp20x_usb_power: add IIO dependency

When CONFIG_IIO=m and the axp20x_usb_power driver is built-in, we get a link time error: drivers/power/built-in.o: In function `axp20x_usb_power_get_property': undefined reference to `iio_read_channel_processed' drivers/power/built-in.o: In function `axp20x_usb_power_probe': undefined reference

[PATCH] power: supply: axp20x_usb_power: add IIO dependency

When CONFIG_IIO=m and the axp20x_usb_power driver is built-in, we get a link time error: drivers/power/built-in.o: In function `axp20x_usb_power_get_property': undefined reference to `iio_read_channel_processed' drivers/power/built-in.o: In function `axp20x_usb_power_probe': undefined reference

[PATCH net-next] igb: mark PM functions as __maybe_unused

The new wake function is only used by the suspend/resume handlers that are defined in inside of an #ifdef, which can cause this harmless warning: drivers/net/ethernet/intel/igb/igb_main.c:7988:13: warning: 'igb_deliver_wake_packet' defined but not used [-Wunused-function] Removing the #ifdef,

[PATCH net-next] igb: mark PM functions as __maybe_unused

The new wake function is only used by the suspend/resume handlers that are defined in inside of an #ifdef, which can cause this harmless warning: drivers/net/ethernet/intel/igb/igb_main.c:7988:13: warning: 'igb_deliver_wake_packet' defined but not used [-Wunused-function] Removing the #ifdef,

Re: [PATCH v4 3/4] KEYS: Support for inserting a certificate into x86 bzImage

> On Apr 27, 2017, at 9:54 AM, David Howells wrote: > > Mehmet Kayaalp wrote: > >> +/* TODO: update CRC */ > > Is this bit missing? I didn't add it, since I wasn't sure it was still used with secure boot. The CRC code is implemented in

Re: [PATCH v2] leds-pca963x: add bindings to invert polarity

Hi Anders, On 04/27/2017 08:37 AM, Anders Darander wrote: > Add a new DT property, nxp,inverted-out, to invert the polarity of the output. > > Tested on PCA9634. > > Signed-off-by: Anders Darander > --- > Documentation/devicetree/bindings/leds/pca963x.txt | 1 + >

Re: [PATCH v4 3/4] KEYS: Support for inserting a certificate into x86 bzImage

> On Apr 27, 2017, at 9:54 AM, David Howells wrote: > > Mehmet Kayaalp wrote: > >> +/* TODO: update CRC */ > > Is this bit missing? I didn't add it, since I wasn't sure it was still used with secure boot. The CRC code is implemented in multiple places, but not exposed to the

Re: [PATCH v2] leds-pca963x: add bindings to invert polarity

Hi Anders, On 04/27/2017 08:37 AM, Anders Darander wrote: > Add a new DT property, nxp,inverted-out, to invert the polarity of the output. > > Tested on PCA9634. > > Signed-off-by: Anders Darander > --- > Documentation/devicetree/bindings/leds/pca963x.txt | 1 + > drivers/leds/leds-pca963x.c

Re: [PATCH net-next 08/18] net: dsa: mv88e6xxx: move generic VTU GetNext

On Wed, Apr 26, 2017 at 11:53:26AM -0400, Vivien Didelot wrote: > Even though every switch model has a different way to access the VTU > Data bits, the base implementation of the VTU GetNext operation remains > the same: wait, write the first VID to iterate from, start the > operation, and read

Re: [PATCH net-next 08/18] net: dsa: mv88e6xxx: move generic VTU GetNext

On Wed, Apr 26, 2017 at 11:53:26AM -0400, Vivien Didelot wrote: > Even though every switch model has a different way to access the VTU > Data bits, the base implementation of the VTU GetNext operation remains > the same: wait, write the first VID to iterate from, start the > operation, and read

Re: [PATCH 1/2] PCI: mediatek: Add Mediatek PCIe host controller support

On Wed, Apr 26, 2017 at 10:10 AM, Ryder Lee wrote: > On Tue, 2017-04-25 at 14:38 +0200, Arnd Bergmann wrote: >> On Sun, Apr 23, 2017 at 10:19 AM, Ryder Lee wrote: >> > +static int mtk_pcie_enable_ports(struct mtk_pcie *pcie) >> > +{ >> > +

Re: [PATCH 1/2] PCI: mediatek: Add Mediatek PCIe host controller support

On Wed, Apr 26, 2017 at 10:10 AM, Ryder Lee wrote: > On Tue, 2017-04-25 at 14:38 +0200, Arnd Bergmann wrote: >> On Sun, Apr 23, 2017 at 10:19 AM, Ryder Lee wrote: >> > +static int mtk_pcie_enable_ports(struct mtk_pcie *pcie) >> > +{ >> > + struct device *dev = pcie->dev; >> > +

Re: [PATCH net-next 07/18] net: dsa: mv88e6xxx: move VTU VID accessors

> @@ -1464,13 +1457,16 @@ static int _mv88e6xxx_vtu_loadpurge(struct > mv88e6xxx_chip *chip, > struct mv88e6xxx_vtu_entry *entry) > { > u16 op = GLOBAL_VTU_OP_VTU_LOAD_PURGE; > - u16 reg = 0; > int err; > > err =

Re: [PATCH net-next 07/18] net: dsa: mv88e6xxx: move VTU VID accessors

> @@ -1464,13 +1457,16 @@ static int _mv88e6xxx_vtu_loadpurge(struct > mv88e6xxx_chip *chip, > struct mv88e6xxx_vtu_entry *entry) > { > u16 op = GLOBAL_VTU_OP_VTU_LOAD_PURGE; > - u16 reg = 0; > int err; > > err =

Re: [alsa-devel] [PATCH] ASoC: dwc: disallow building designware_pcm as a module

Hi, On 21-04-2017 11:49, Mark Brown wrote: > On Fri, Apr 21, 2017 at 12:39:30PM +0200, Takashi Iwai wrote: >> Jose Abreu wrote: >>> Maybe rename to "dwc-i2s.c" and "dwc-pcm.c" (as the folder is >>> called "dwc") and let the module still be called "designware-i2s"? >> Lubomir's patch keeps the

Re: [alsa-devel] [PATCH] ASoC: dwc: disallow building designware_pcm as a module

Hi, On 21-04-2017 11:49, Mark Brown wrote: > On Fri, Apr 21, 2017 at 12:39:30PM +0200, Takashi Iwai wrote: >> Jose Abreu wrote: >>> Maybe rename to "dwc-i2s.c" and "dwc-pcm.c" (as the folder is >>> called "dwc") and let the module still be called "designware-i2s"? >> Lubomir's patch keeps the

Re: [PATCH 2/3] selinux: add checksum to policydb

On Thu, 2017-04-27 at 19:12 +0200, Sebastien Buisson wrote: > 2017-04-27 17:18 GMT+02:00 Stephen Smalley : > > Ok, that should work as long as you just want to validate that all > > the > > clients loaded the same policy file, and aren't concerned about > > non- > > persistent

Re: [PATCH 2/3] selinux: add checksum to policydb

On Thu, 2017-04-27 at 19:12 +0200, Sebastien Buisson wrote: > 2017-04-27 17:18 GMT+02:00 Stephen Smalley : > > Ok, that should work as long as you just want to validate that all > > the > > clients loaded the same policy file, and aren't concerned about > > non- > > persistent policy boolean

Re: [RESEND PATCH 1/2] arc: axs10x: Add DT bindings for I2S audio playback

Hi Vineet, On 27-04-2017 00:31, Vineet Gupta wrote: > On 04/26/2017 01:55 AM, Jose Abreu wrote: >> Hi Vineet, >> >> >> On 24-04-2017 18:36, Vineet Gupta wrote: >>> On 04/21/2017 03:15 AM, Jose Abreu wrote: This patch adds the necessary DT bindings to get HDMI audio output in ARC AXS10x

Re: [RESEND PATCH 1/2] arc: axs10x: Add DT bindings for I2S audio playback

Hi Vineet, On 27-04-2017 00:31, Vineet Gupta wrote: > On 04/26/2017 01:55 AM, Jose Abreu wrote: >> Hi Vineet, >> >> >> On 24-04-2017 18:36, Vineet Gupta wrote: >>> On 04/21/2017 03:15 AM, Jose Abreu wrote: This patch adds the necessary DT bindings to get HDMI audio output in ARC AXS10x

Re: [PATCH v3] libnvdimm, region: sysfs trigger for nvdimm_flush()

Dan Williams writes: >> The sentiment is that programs shouldn't have to grovel around in sysfs >> to do stuff related to an open file descriptor or mapping. I don't take >> issue with the name. I do worry that something like 'wpq_drain' may be >> too platform

Re: [PATCH v3] libnvdimm, region: sysfs trigger for nvdimm_flush()

Dan Williams writes: >> The sentiment is that programs shouldn't have to grovel around in sysfs >> to do stuff related to an open file descriptor or mapping. I don't take >> issue with the name. I do worry that something like 'wpq_drain' may be >> too platform specific, though. The NVM

Re: [PATCH] led: ledtrig-transient: replace timer_list with hrtimer

On 04/27/2017 05:48 AM, David Lin wrote: > On Tue, Apr 25, 2017 at 1:15 PM, Jacek Anaszewski > wrote: >>> However, there's a need to >>> support hrtimer if the LED subsystem claims support the use case of >>> vibrator (please see

Re: [PATCH] led: ledtrig-transient: replace timer_list with hrtimer

On 04/27/2017 05:48 AM, David Lin wrote: > On Tue, Apr 25, 2017 at 1:15 PM, Jacek Anaszewski > wrote: >>> However, there's a need to >>> support hrtimer if the LED subsystem claims support the use case of >>> vibrator (please see Documentation/leds/ledtrig-transient.txt) as even >>> a 5ms of

Re: [PATCH net-next 06/18] net: dsa: mv88e6xxx: move VTU SID accessors

On Wed, Apr 26, 2017 at 11:53:24AM -0400, Vivien Didelot wrote: > Add helpers to access the VTU SID register in the global1_vtu.c file. > > Signed-off-by: Vivien Didelot Reviewed-by: Andrew Lunn Andrew

Re: [PATCH net-next 06/18] net: dsa: mv88e6xxx: move VTU SID accessors

On Wed, Apr 26, 2017 at 11:53:24AM -0400, Vivien Didelot wrote: > Add helpers to access the VTU SID register in the global1_vtu.c file. > > Signed-off-by: Vivien Didelot Reviewed-by: Andrew Lunn Andrew

Re: [PATCH net-next 05/18] net: dsa: mv88e6xxx: move VTU FID accessors

On Wed, Apr 26, 2017 at 11:53:23AM -0400, Vivien Didelot wrote: > Add helpers to access the VTU FID register in the global1_vtu.c file. > > Signed-off-by: Vivien Didelot Reviewed-by: Andrew Lunn Andrew

Re: [PATCH net-next 05/18] net: dsa: mv88e6xxx: move VTU FID accessors

On Wed, Apr 26, 2017 at 11:53:23AM -0400, Vivien Didelot wrote: > Add helpers to access the VTU FID register in the global1_vtu.c file. > > Signed-off-by: Vivien Didelot Reviewed-by: Andrew Lunn Andrew

Re: [PATCH 0/3 v3] ARM/ARM64: silence large module first time allocation

On 04/27/2017 11:24 AM, Ard Biesheuvel wrote: > >> On 27 Apr 2017, at 19:18, Florian Fainelli wrote: >> >> With kernels built with CONFIG_ARM{,64}_MODULES_PLTS=y, the first allocation >> done from module space will fail, produce a general OOM allocation and also a >> vmap

Re: [PATCH 0/3 v3] ARM/ARM64: silence large module first time allocation

On 04/27/2017 11:24 AM, Ard Biesheuvel wrote: > >> On 27 Apr 2017, at 19:18, Florian Fainelli wrote: >> >> With kernels built with CONFIG_ARM{,64}_MODULES_PLTS=y, the first allocation >> done from module space will fail, produce a general OOM allocation and also a >> vmap warning. The second

Re: [PATCH net-next 04/18] net: dsa: mv88e6xxx: move VTU flush

On Wed, Apr 26, 2017 at 11:53:22AM -0400, Vivien Didelot wrote: > Move the VTU flush operation to global1_vtu.c and call it from a > mv88e6xxx_vtu_setup helper, similarly to the ATU and PVT setup. > > Signed-off-by: Vivien Didelot Reviewed-by: Andrew Lunn

Re: [PATCH net-next 04/18] net: dsa: mv88e6xxx: move VTU flush

On Wed, Apr 26, 2017 at 11:53:22AM -0400, Vivien Didelot wrote: > Move the VTU flush operation to global1_vtu.c and call it from a > mv88e6xxx_vtu_setup helper, similarly to the ATU and PVT setup. > > Signed-off-by: Vivien Didelot Reviewed-by: Andrew Lunn Andrew

Re: [PATCH net-next 03/18] net: dsa: mv88e6xxx: move VTU Operation accessors

On Wed, Apr 26, 2017 at 11:53:21AM -0400, Vivien Didelot wrote: > Move the helper functions to access the Global 1 VTU Operation register > to a new global1_vtu.c file, and get rid of the old underscore prefix > naming convention. This file will be extended will all VTU/STU related > code. > >

Re: [PATCH net-next 03/18] net: dsa: mv88e6xxx: move VTU Operation accessors

On Wed, Apr 26, 2017 at 11:53:21AM -0400, Vivien Didelot wrote: > Move the helper functions to access the Global 1 VTU Operation register > to a new global1_vtu.c file, and get rid of the old underscore prefix > naming convention. This file will be extended will all VTU/STU related > code. > >

Re: [PATCH net-next 03/18] net: dsa: mv88e6xxx: move VTU Operation accessors

On Wed, Apr 26, 2017 at 11:53:21AM -0400, Vivien Didelot wrote: > Move the helper functions to access the Global 1 VTU Operation register > to a new global1_vtu.c file, and get rid of the old underscore prefix > naming convention. This file will be extended will all VTU/STU related > code. > >

Re: [PATCH net-next 03/18] net: dsa: mv88e6xxx: move VTU Operation accessors

On Wed, Apr 26, 2017 at 11:53:21AM -0400, Vivien Didelot wrote: > Move the helper functions to access the Global 1 VTU Operation register > to a new global1_vtu.c file, and get rid of the old underscore prefix > naming convention. This file will be extended will all VTU/STU related > code. > >

Re: [RFC v3 05/17] RCU free VMAs

On Thu, Apr 27, 2017 at 05:52:44PM +0200, Laurent Dufour wrote: > From: Peter Zijlstra > > Manage the VMAs with SRCU such that we can do a lockless VMA lookup. > > We put the fput(vma->vm_file) in the SRCU callback, this keeps files > valid during speculative faults, this

Re: [RFC v3 05/17] RCU free VMAs

On Thu, Apr 27, 2017 at 05:52:44PM +0200, Laurent Dufour wrote: > From: Peter Zijlstra > > Manage the VMAs with SRCU such that we can do a lockless VMA lookup. > > We put the fput(vma->vm_file) in the SRCU callback, this keeps files > valid during speculative faults, this is possible due to the

Re: [PATCH 1/2] dt/bindings: Add bindings for Broadcom STB DRAM Sensors

On 25 April 2017 at 12:29, Markus Mayer wrote: > Hi Rob, > > On 18 April 2017 at 13:17, Markus Mayer wrote: >> From: Markus Mayer >> >> Provide bindings for the Broadcom STB DDR PHY Front End (DPFE). > > Would you be able to have

Re: [PATCH 1/2] dt/bindings: Add bindings for Broadcom STB DRAM Sensors

On 25 April 2017 at 12:29, Markus Mayer wrote: > Hi Rob, > > On 18 April 2017 at 13:17, Markus Mayer wrote: >> From: Markus Mayer >> >> Provide bindings for the Broadcom STB DDR PHY Front End (DPFE). > > Would you be able to have a look at this binding? The driver won't be > upstreamed as hwmon

[PATCH 4/5] arm64: dts: r8a7795: salvator-x: enable VIN, CSI and ADV7482

From: Kieran Bingham Provide bindings between the VIN, CSI and the ADV7482 on the r8a7795. Signed-off-by: Kieran Bingham --- arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 129 + 1 file

[PATCH 4/5] arm64: dts: r8a7795: salvator-x: enable VIN, CSI and ADV7482

From: Kieran Bingham Provide bindings between the VIN, CSI and the ADV7482 on the r8a7795. Signed-off-by: Kieran Bingham --- arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 129 + 1 file changed, 129 insertions(+) diff --git

[PATCH 2/5] rcar-vin: Match sources against ports if specified.

From: Kieran Bingham If an endpoint source specifies a port number, then it may have multiple entities provided by one DT node. In this event, match against both the DT node and it's relevant port. Signed-off-by: Kieran Bingham

[PATCH 2/5] rcar-vin: Match sources against ports if specified.

From: Kieran Bingham If an endpoint source specifies a port number, then it may have multiple entities provided by one DT node. In this event, match against both the DT node and it's relevant port. Signed-off-by: Kieran Bingham --- drivers/media/platform/rcar-vin/rcar-core.c | 15

[PATCH 3/5] media: i2c: adv748x: add adv748x driver

From: Kieran Bingham Provide basic support for the ADV7481 and ADV7482. The driver is modelled with 2 subdevices to allow simultaneous streaming from the AFE (Analog front end) and HDMI inputs. Presently the HDMI is hardcoded to link to the TXA CSI bus,

[PATCH 3/5] media: i2c: adv748x: add adv748x driver

From: Kieran Bingham Provide basic support for the ADV7481 and ADV7482. The driver is modelled with 2 subdevices to allow simultaneous streaming from the AFE (Analog front end) and HDMI inputs. Presently the HDMI is hardcoded to link to the TXA CSI bus, whilst the AFE is linked to the TXB CSI

[PATCH 5/5] arm64: dts: r8a7796: salvator-x: enable VIN, CSI and ADV7482

From: Kieran Bingham Provide bindings between the VIN, CSI and the ADV7482 on the r8a7796. Signed-off-by: Kieran Bingham --- arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 129 + 1 file

[PATCH 5/5] arm64: dts: r8a7796: salvator-x: enable VIN, CSI and ADV7482

From: Kieran Bingham Provide bindings between the VIN, CSI and the ADV7482 on the r8a7796. Signed-off-by: Kieran Bingham --- arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 129 + 1 file changed, 129 insertions(+) diff --git

[PATCH 1/5] v4l2-subdev: Provide a port mapping for asynchronous subdevs

From: Kieran Bingham Devices such as the the ADV748x support multiple parallel stream routes through a single chip. This leads towards needing to provide multiple distinct entities and subdevs from a single device-tree node. To distinguish these separate

[PATCH 1/5] v4l2-subdev: Provide a port mapping for asynchronous subdevs

From: Kieran Bingham Devices such as the the ADV748x support multiple parallel stream routes through a single chip. This leads towards needing to provide multiple distinct entities and subdevs from a single device-tree node. To distinguish these separate outputs, the device-tree binding must

[PATCH 0/5] RFC: ADV748x HDMI/Analog video receiver

From: Kieran Bingham This is an RFC for the Analog Devices ADV748x driver, and follows on from a previous posting by Niklas Söderlund [0] of an earlier incarnation of this driver. This is an early posting of the driver following the release early,

[PATCH 0/5] RFC: ADV748x HDMI/Analog video receiver

From: Kieran Bingham This is an RFC for the Analog Devices ADV748x driver, and follows on from a previous posting by Niklas Söderlund [0] of an earlier incarnation of this driver. This is an early posting of the driver following the release early, release often method after quite a bit of

Re: [PATCH net-next 02/18] net: dsa: mv88e6xxx: split VTU entry data member

On Wed, Apr 26, 2017 at 11:53:20AM -0400, Vivien Didelot wrote: > VLAN aware Marvell chips can program 802.1Q VLAN membership as well as > 802.1s per VLAN Spanning Tree state using the same 3 VTU Data registers. > > Some chips such as 88E6185 use different Data registers offsets for > ports state

Re: [PATCH net-next 02/18] net: dsa: mv88e6xxx: split VTU entry data member

On Wed, Apr 26, 2017 at 11:53:20AM -0400, Vivien Didelot wrote: > VLAN aware Marvell chips can program 802.1Q VLAN membership as well as > 802.1s per VLAN Spanning Tree state using the same 3 VTU Data registers. > > Some chips such as 88E6185 use different Data registers offsets for > ports state

Re: [PATCH 0/3 v3] ARM/ARM64: silence large module first time allocation

> On 27 Apr 2017, at 19:18, Florian Fainelli wrote: > > With kernels built with CONFIG_ARM{,64}_MODULES_PLTS=y, the first allocation > done from module space will fail, produce a general OOM allocation and also a > vmap warning. The second allocation from vmalloc space may

Re: [PATCH 0/3 v3] ARM/ARM64: silence large module first time allocation

> On 27 Apr 2017, at 19:18, Florian Fainelli wrote: > > With kernels built with CONFIG_ARM{,64}_MODULES_PLTS=y, the first allocation > done from module space will fail, produce a general OOM allocation and also a > vmap warning. The second allocation from vmalloc space may or may not be >

Re: [PATCH v2 1/3] mm: Silence vmap() allocation failures based on caller gfp_flags

On 04/27/2017 11:20 AM, Michal Hocko wrote: >>> would be shorter and you wouldn't need the goto and a label. >> >> Do you want me to resubmit with that change included? > > Up to you. As I've said this is a nit at best. I just sent a v3 based on feedback from Ard, thanks! -- Florian

Re: [PATCH v2 1/3] mm: Silence vmap() allocation failures based on caller gfp_flags

On 04/27/2017 11:20 AM, Michal Hocko wrote: >>> would be shorter and you wouldn't need the goto and a label. >> >> Do you want me to resubmit with that change included? > > Up to you. As I've said this is a nit at best. I just sent a v3 based on feedback from Ard, thanks! -- Florian

Re: [PATCH v2 1/3] mm: Silence vmap() allocation failures based on caller gfp_flags

On Thu 27-04-17 11:03:31, Florian Fainelli wrote: > On 04/27/2017 10:56 AM, Michal Hocko wrote: > > On Thu 27-04-17 10:38:58, Florian Fainelli wrote: > >> If the caller has set __GFP_NOWARN don't print the following message: > >> vmap allocation for size 15736832 failed: use vmalloc= to increase >

Re: [PATCH v2 1/3] mm: Silence vmap() allocation failures based on caller gfp_flags

On Thu 27-04-17 11:03:31, Florian Fainelli wrote: > On 04/27/2017 10:56 AM, Michal Hocko wrote: > > On Thu 27-04-17 10:38:58, Florian Fainelli wrote: > >> If the caller has set __GFP_NOWARN don't print the following message: > >> vmap allocation for size 15736832 failed: use vmalloc= to increase >

[PATCH v3 1/3] mm: Silence vmap() allocation failures based on caller gfp_flags

If the caller has set __GFP_NOWARN don't print the following message: vmap allocation for size 15736832 failed: use vmalloc= to increase size. This can happen with the ARM/Linux or ARM64/Linux module loader built with CONFIG_ARM{,64}_MODULE_PLTS=y which does a first attempt at loading a large

[PATCH v3 1/3] mm: Silence vmap() allocation failures based on caller gfp_flags

If the caller has set __GFP_NOWARN don't print the following message: vmap allocation for size 15736832 failed: use vmalloc= to increase size. This can happen with the ARM/Linux or ARM64/Linux module loader built with CONFIG_ARM{,64}_MODULE_PLTS=y which does a first attempt at loading a large

[PATCH v3 3/3] arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y

When CONFIG_ARM64_MODULE_PLTS is enabled, the first allocation using the module space fails, because the module is too big, and then the module allocation is attempted from vmalloc space. Silence the first allocation failure in that case by setting __GFP_NOWARN. Reviewed-by: Ard Biesheuvel

[PATCH v3 2/3] ARM: Silence first allocation with CONFIG_ARM_MODULE_PLTS=y

When CONFIG_ARM_MODULE_PLTS is enabled, the first allocation using the module space fails, because the module is too big, and then the module allocation is attempted from vmalloc space. Silence the first allocation failure in that case by setting __GFP_NOWARN. Signed-off-by: Florian Fainelli

[PATCH v3 3/3] arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y

When CONFIG_ARM64_MODULE_PLTS is enabled, the first allocation using the module space fails, because the module is too big, and then the module allocation is attempted from vmalloc space. Silence the first allocation failure in that case by setting __GFP_NOWARN. Reviewed-by: Ard Biesheuvel

[PATCH v3 2/3] ARM: Silence first allocation with CONFIG_ARM_MODULE_PLTS=y

When CONFIG_ARM_MODULE_PLTS is enabled, the first allocation using the module space fails, because the module is too big, and then the module allocation is attempted from vmalloc space. Silence the first allocation failure in that case by setting __GFP_NOWARN. Signed-off-by: Florian Fainelli ---

[PATCH 0/3 v3] ARM/ARM64: silence large module first time allocation

With kernels built with CONFIG_ARM{,64}_MODULES_PLTS=y, the first allocation done from module space will fail, produce a general OOM allocation and also a vmap warning. The second allocation from vmalloc space may or may not be successful, but is actually the one we are interested about in these

[PATCH 0/3 v3] ARM/ARM64: silence large module first time allocation

With kernels built with CONFIG_ARM{,64}_MODULES_PLTS=y, the first allocation done from module space will fail, produce a general OOM allocation and also a vmap warning. The second allocation from vmalloc space may or may not be successful, but is actually the one we are interested about in these

Re: HID: sensor-hub: Delete error messages for failed memory allocations in sensor_hub_probe()

> WARNING: Possible unnecessary 'out of memory' message I have noticed a moment ago that a similar change is also contained in the update suggestion “HID: Remove unnecessary OOM messages” by Joe Perches from 2017-03-01. https://patchwork.kernel.org/patch/9598997/

Re: HID: sensor-hub: Delete error messages for failed memory allocations in sensor_hub_probe()

> WARNING: Possible unnecessary 'out of memory' message I have noticed a moment ago that a similar change is also contained in the update suggestion “HID: Remove unnecessary OOM messages” by Joe Perches from 2017-03-01. https://patchwork.kernel.org/patch/9598997/

Re: [PATCH 2/2] f2fs: introduce CP_TRIMMED_FLAG to avoid unneeded discard

Hi Chao, Could you add this state in print_cp_state() of f2fs-tools as well? Thanks, On 04/27, Chao Yu wrote: > Introduce CP_TRIMMED_FLAG to indicate all invalid block were trimmed > before umount, so once we do mount with image which contain the flag, > we don't record invalid blocks as

Re: [PATCH 2/2] f2fs: introduce CP_TRIMMED_FLAG to avoid unneeded discard

Hi Chao, Could you add this state in print_cp_state() of f2fs-tools as well? Thanks, On 04/27, Chao Yu wrote: > Introduce CP_TRIMMED_FLAG to indicate all invalid block were trimmed > before umount, so once we do mount with image which contain the flag, > we don't record invalid blocks as

<    1   2   3   4   5   6   7   8   9   10   >