Re: [PATCH] iio: imu: mpu6050: Fix FIFO layout for ICM20602

Hi Jean-Baptiste, That's a good catch. I didn't realize the accel-only configuration included temperature data as well. I've confirmed this behavior and will send out a v2 shortly. Thanks! -Steve

Re: [PATCH v2] EDAC: Add ARM64 EDAC

>>> +++ b/drivers/edac/cortex_arm64_edac.c >>> @@ -0,0 +1,457 @@ >>> +/* >>> + * Cortex ARM64 EDAC >>> + * >>> + * Copyright (c) 2015, Advanced Micro Devices >>> + * Author: Brijesh Singh >>> + * Hi Brijesh, Your ARM64 EDAC driver seems rather similar to the existing driver that is linked

Re: [PATCH v2] EDAC: Add ARM64 EDAC

>>> +++ b/drivers/edac/cortex_arm64_edac.c >>> @@ -0,0 +1,457 @@ >>> +/* >>> + * Cortex ARM64 EDAC >>> + * >>> + * Copyright (c) 2015, Advanced Micro Devices >>> + * Author: Brijesh Singh >>> + * Hi Brijesh, Your ARM64 EDAC driver seems rather similar to the

[PATCH v2] of: Deep-copy names of platform devices

to dev_set_name() that might made by drivers to rename the embedded 'struct device'. Signed-off-by: Stepan Moskovchenko --- * v2 - swap cleanup order drivers/of/device.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/of/device.c b/drivers/of/device.c index f685e55..e9beae6

[PATCH] of: Deep-copy names of platform devices

to dev_set_name() that might made by drivers to rename the embedded 'struct device'. Signed-off-by: Stepan Moskovchenko --- This is technically a 'v2' patch, but it looks like I used an old version of MAINTAINERS, so I'll just re-send this as a new patch to avoid confusion for people who missed

Re: [PATCH] of: Deep-copy names of platform devices

On 8/12/2014 9:12 AM, Kumar Gala wrote: On Aug 11, 2014, at 9:42 PM, Stepan Moskovchenko wrote: When we parse the device tree and allocate platform devices, the 'name' of the newly-created platform_device is set to point to the 'name' field of the 'struct device' embedded within

Re: [PATCH] of: Deep-copy names of platform devices

On 8/12/2014 9:12 AM, Kumar Gala wrote: On Aug 11, 2014, at 9:42 PM, Stepan Moskovchenko step...@codeaurora.org wrote: When we parse the device tree and allocate platform devices, the 'name' of the newly-created platform_device is set to point to the 'name' field of the 'struct device

[PATCH] of: Deep-copy names of platform devices

to dev_set_name() that might made by drivers to rename the embedded 'struct device'. Signed-off-by: Stepan Moskovchenko step...@codeaurora.org --- This is technically a 'v2' patch, but it looks like I used an old version of MAINTAINERS, so I'll just re-send this as a new patch to avoid confusion for people

[PATCH v2] of: Deep-copy names of platform devices

to dev_set_name() that might made by drivers to rename the embedded 'struct device'. Signed-off-by: Stepan Moskovchenko step...@codeaurora.org --- * v2 - swap cleanup order drivers/of/device.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/of/device.c b/drivers/of/device.c

[PATCH] of: Deep-copy names of platform devices

to dev_set_name() that might made by drivers to rename the embedded 'struct device'. Signed-off-by: Stepan Moskovchenko --- I suppose creating a 'pdev_set_name' API may seem like another possibility, but I feel that dev.name and pdev.name have two different meanings. One is used for device/driver binding

[PATCH] of: Deep-copy names of platform devices

to dev_set_name() that might made by drivers to rename the embedded 'struct device'. Signed-off-by: Stepan Moskovchenko step...@codeaurora.org --- I suppose creating a 'pdev_set_name' API may seem like another possibility, but I feel that dev.name and pdev.name have two different meanings. One is used

[PATCH] ARM: dts: Fix memory node in skeleton64.dtsi

Update the reg property of the memory node in skeleton64.dtsi to reflect the fact that the root node uses address-cells=2 and size-cells=2. Change-Id: Ie9b61166143969e020ceebc51e9a384405d8c0f2 Signed-off-by: Stepan Moskovchenko --- arch/arm/boot/dts/skeleton64.dtsi |2 +- 1 files changed, 1

[PATCH] ARM: dts: Fix memory node in skeleton64.dtsi

Update the reg property of the memory node in skeleton64.dtsi to reflect the fact that the root node uses address-cells=2 and size-cells=2. Change-Id: Ie9b61166143969e020ceebc51e9a384405d8c0f2 Signed-off-by: Stepan Moskovchenko step...@codeaurora.org --- arch/arm/boot/dts/skeleton64.dtsi |2

Re: [PATCH] arm: Prevent memory aliasing on non-LPAE kernels

On 5/30/2013 3:24 PM, Arnd Bergmann wrote: + if (size > ((phys_addr_t)~0)) + size = ((phys_addr_t)~0); + + /* arm_add_memory() already checks for the case of base + size > 4GB */ +#endif arm_add_memory(base, size); } This looks wrong for the case where

Re: [PATCH] arm: Prevent memory aliasing on non-LPAE kernels

On 5/30/2013 3:24 PM, Arnd Bergmann wrote: + if (size ((phys_addr_t)~0)) + size = ((phys_addr_t)~0); + + /* arm_add_memory() already checks for the case of base + size 4GB */ +#endif arm_add_memory(base, size); } This looks wrong for the case where 'base'

[PATCH] arm: Prevent memory aliasing on non-LPAE kernels

truncated and aliasing with physical addresses below the 4GB boundary. Signed-off-by: Stepan Moskovchenko --- arch/arm/kernel/devtree.c | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c index bee7f9d..24bc80b

[PATCH] arm: Prevent memory aliasing on non-LPAE kernels

truncated and aliasing with physical addresses below the 4GB boundary. Signed-off-by: Stepan Moskovchenko step...@codeaurora.org --- arch/arm/kernel/devtree.c | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c index

Reusing DTSI files across trees with differing numbers of address-cells

Hello. I am creating a DTS file for an ARM (Qualcomm MSM) target which supports LPAE, meaning that the target is capable of addressing memory beyond the standard 4GB boundary. To account for the fact that the memory node can contain reg addresses that exceed 32 bits, I am setting

Reusing DTSI files across trees with differing numbers of address-cells

Hello. I am creating a DTS file for an ARM (Qualcomm MSM) target which supports LPAE, meaning that the target is capable of addressing memory beyond the standard 4GB boundary. To account for the fact that the memory node can contain reg addresses that exceed 32 bits, I am setting

Re: [PATCH] lib: vsprintf: Add %pa format specifier for phys_addr_t types

On Tue, 2013-01-22 at 23:26 +0100, Geert Uytterhoeven wrote: On Tue, Jan 22, 2013 at 6:47 AM, Stepan Moskovchenko wrote: > Add the %pa format specifier for printing a phys_addr_t > type, since the physical address size on some platforms > can vary based on build options, r

Re: [PATCH] lib: vsprintf: Add %pa format specifier for phys_addr_t types

On Tue, 2013-01-22 at 23:26 +0100, Geert Uytterhoeven wrote: On Tue, Jan 22, 2013 at 6:47 AM, Stepan Moskovchenko step...@codeaurora.org wrote: Add the %pa format specifier for printing a phys_addr_t type, since the physical address size on some platforms can vary based on build options

[PATCH v2] lib: vsprintf: Add %pa format specifier for phys_addr_t types

Add the %pa format specifier for printing a phys_addr_t type and its derivative types (such as resource_size_t), since the physical address size on some platforms can vary based on build options, regardless of the native integer type. Signed-off-by: Stepan Moskovchenko --- v2: - Update field

Re: [PATCH] lib: vsprintf: Add %pa format specifier for phys_addr_t types

On 1/21/2013 11:52 PM, Joe Perches wrote: I believe this should be: spec.field_width = sizeof(phys_addr_t) * 2 + 2; Ah yes, I believe you are right. I had only added the SPECIAL flag after writing this. Will fix in v2. -- The Qualcomm Innovation Center, Inc. is a member of Code

Re: [PATCH] lib: vsprintf: Add %pa format specifier for phys_addr_t types

On 1/21/2013 11:52 PM, Joe Perches wrote: I believe this should be: spec.field_width = sizeof(phys_addr_t) * 2 + 2; Ah yes, I believe you are right. I had only added the SPECIAL flag after writing this. Will fix in v2. -- The Qualcomm Innovation Center, Inc. is a member of Code

[PATCH v2] lib: vsprintf: Add %pa format specifier for phys_addr_t types

Add the %pa format specifier for printing a phys_addr_t type and its derivative types (such as resource_size_t), since the physical address size on some platforms can vary based on build options, regardless of the native integer type. Signed-off-by: Stepan Moskovchenko step...@codeaurora.org

[PATCH] lib: vsprintf: Add %pa format specifier for phys_addr_t types

Add the %pa format specifier for printing a phys_addr_t type, since the physical address size on some platforms can vary based on build options, regardless of the native integer type. Signed-off-by: Stepan Moskovchenko --- Documentation/printk-formats.txt | 13 ++--- lib/vsprintf.c

[PATCH] lib: vsprintf: Add %pa format specifier for phys_addr_t types

Add the %pa format specifier for printing a phys_addr_t type, since the physical address size on some platforms can vary based on build options, regardless of the native integer type. Signed-off-by: Stepan Moskovchenko step...@codeaurora.org --- Documentation/printk-formats.txt | 13

[PATCH v3] of: Output devicetree alias names in uevent

en defined for the device. Signed-off-by: Stepan Moskovchenko --- v3: Fix copyright/license message on of_platform.h to match the messages in the file the code came from. I also noticed that some of the comments in the original header might no longer apply, but I copied the header in its entirety.

[PATCH v3] of: Output devicetree alias names in uevent

for the device. Signed-off-by: Stepan Moskovchenko step...@codeaurora.org --- v3: Fix copyright/license message on of_platform.h to match the messages in the file the code came from. I also noticed that some of the comments in the original header might no longer apply, but I copied the header in its

[PATCH v2] of: Output devicetree alias names in uevent

en defined for the device. Signed-off-by: Stepan Moskovchenko --- v2: Create of_private.h and move struct alias_prop there Add alias uevent variables from of_device_uevent Use app->alias instead of app->stem / app->id directly Expose alias_lookup and of_alias_mutex drivers/of/

[PATCH v2] of: Output devicetree alias names in uevent

for the device. Signed-off-by: Stepan Moskovchenko step...@codeaurora.org --- v2: Create of_private.h and move struct alias_prop there Add alias uevent variables from of_device_uevent Use app-alias instead of app-stem / app-id directly Expose alias_lookup and of_alias_mutex drivers/of/base.c

Re: [RFC] dt/platform: Use cell-index for device naming if available

On 11/20/2012 8:19 AM, Grant Likely wrote: What if instead we added something like OF_ALIASES to the uevent attribute? Then userspace would have access to all the aliases for a device. Heck, even a shell script can parse the uevent attribute. There is also precedence for exporting OF data using

[PATCH] of: Output devicetree alias names in uevent

en defined for the device. Signed-off-by: Stepan Moskovchenko --- I have followed the OF_COMPATIBLE convention for adding the uevent variables for the alias names, but I can follow some other convention if people feel something else is more appropriate. drivers/of/base.c

[PATCH] of: Output devicetree alias names in uevent

for the device. Signed-off-by: Stepan Moskovchenko step...@codeaurora.org --- I have followed the OF_COMPATIBLE convention for adding the uevent variables for the alias names, but I can follow some other convention if people feel something else is more appropriate. drivers/of/base.c | 25

Re: [RFC] dt/platform: Use cell-index for device naming if available

On 11/20/2012 8:19 AM, Grant Likely wrote: What if instead we added something like OF_ALIASES to the uevent attribute? Then userspace would have access to all the aliases for a device. Heck, even a shell script can parse the uevent attribute. There is also precedence for exporting OF data using

Re: [RFC] dt/platform: Use cell-index for device naming if available

On 11/15/2012 8:10 AM, Grant Likely wrote: On Mon, 12 Nov 2012 18:48:43 -0800, Stepan Moskovchenko wrote: On 11/11/2012 5:45 PM, Stepan Moskovchenko wrote: On Sun, Nov 11, 2012 at 2:32 AM, Rob Herring wrote: On 11/09/2012 06:48 PM, Stepan Moskovchenko wrote: Use the cell-index property

Re: [RFC] dt/platform: Use cell-index for device naming if available

On 11/15/2012 8:10 AM, Grant Likely wrote: On Mon, 12 Nov 2012 18:48:43 -0800, Stepan Moskovchenko step...@codeaurora.org wrote: On 11/11/2012 5:45 PM, Stepan Moskovchenko wrote: On Sun, Nov 11, 2012 at 2:32 AM, Rob Herring robherri...@gmail.com wrote: On 11/09/2012 06:48 PM, Stepan

Re: [RFC] dt/platform: Use cell-index for device naming if available

On 11/15/2012 8:10 AM, Grant Likely wrote: On Mon, 12 Nov 2012 18:48:43 -0800, Stepan Moskovchenko wrote: On 11/11/2012 5:45 PM, Stepan Moskovchenko wrote: On Sun, Nov 11, 2012 at 2:32 AM, Rob Herring wrote: On 11/09/2012 06:48 PM, Stepan Moskovchenko wrote: Use the cell-index property

Re: [RFC] dt/platform: Use cell-index for device naming if available

On 11/15/2012 8:10 AM, Grant Likely wrote: On Mon, 12 Nov 2012 18:48:43 -0800, Stepan Moskovchenko step...@codeaurora.org wrote: On 11/11/2012 5:45 PM, Stepan Moskovchenko wrote: On Sun, Nov 11, 2012 at 2:32 AM, Rob Herring robherri...@gmail.com wrote: On 11/09/2012 06:48 PM, Stepan

Re: [RFC] dt/platform: Use cell-index for device naming if available

On 11/11/2012 5:45 PM, Stepan Moskovchenko wrote: On Sun, Nov 11, 2012 at 2:32 AM, Rob Herring wrote: On 11/09/2012 06:48 PM, Stepan Moskovchenko wrote: Use the cell-index property to construct names for platform devices, falling back on the existing scheme of using the device register

Re: [RFC] dt/platform: Use cell-index for device naming if available

On 11/11/2012 5:45 PM, Stepan Moskovchenko wrote: On Sun, Nov 11, 2012 at 2:32 AM, Rob Herring robherri...@gmail.com wrote: On 11/09/2012 06:48 PM, Stepan Moskovchenko wrote: Use the cell-index property to construct names for platform devices, falling back on the existing scheme of using

Re: [RFC] dt/platform: Use cell-index for device naming if available

> On Sun, Nov 11, 2012 at 2:32 AM, Rob Herring > wrote: >> On 11/09/2012 06:48 PM, Stepan Moskovchenko wrote: >>> Use the cell-index property to construct names for platform >>> devices, falling back on the existing scheme of using the >>> device register

Re: [RFC] dt/platform: Use cell-index for device naming if available

On Sun, Nov 11, 2012 at 2:32 AM, Rob Herring robherri...@gmail.com wrote: On 11/09/2012 06:48 PM, Stepan Moskovchenko wrote: Use the cell-index property to construct names for platform devices, falling back on the existing scheme of using the device register address if cell-index

[RFC] dt/platform: Use cell-index for device naming if available

logical instance of a specific hardware block. Signed-off-by: Stepan Moskovchenko --- I had also considered using something like the linux,label property to allow custom names for platform devices without resorting to auxdata, but the cell-index approach seems more in line with what cell-index

[RFC] dt/platform: Use cell-index for device naming if available

to which logical instance of a specific hardware block. Signed-off-by: Stepan Moskovchenko step...@codeaurora.org --- I had also considered using something like the linux,label property to allow custom names for platform devices without resorting to auxdata, but the cell-index approach seems more in line