[RFC PATCH 0/5] Minor bugfixes for Tegra kernels

[RFC PATCH 0/5] Minor bugfixes for Tegra kernels

[Jeremy C. Andrus]

From: "Jeremy C. Andrus" <jeremya-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>

In the course of my research here at Columbia University, I have been
doing some kernel development on the Google Nexus 7 device. I took the
time to address most of the compile-time warnings while building the
Tegra kernel tree using the cross-compiler shipped with Android
(gcc-4.7), and in doing so I came across a few minor issues.

This RFC series addresses several minor bugs that I was able to fix
while suppressing compile warnings. Not knowing exactly where
to send the patches, I decided to send them primarily to the Tegra
list serv in hopes that they will find their way to the correct place.

All 5 patches apply cleanly the kernel/tegra repository hosted by
Google. I used the commit hash referenced in the Android device tree
git logs as my HEAD revision: 22b4fcde206e96f57bf0a111403fc3d75532918a
I belive that this is the revision which corresponds to the prebuilt
kernel provided in the Jelly Bean release.

I would appreciate your feedback, and/or redirection!

Best,

        -Jeremy

Jeremy C. Andrus (5):
  arm: tegra: Fix build under Android cross-compiler
  arm: tegra: Fix modem_reset_flag assignment
  power: smb347: Fix stack corruption
  input: lid: Fix init function ignores sysfs retval
  input: touchscreen: Fix rmi4 sysfs and driver removal

 arch/arm/mach-tegra/baseband-xmm-power.c | 2 +-
 arch/arm/mach-tegra/sleep.S              | 2 ++
 drivers/input/lid.c                      | 4 +++-
 drivers/input/touchscreen/rmi4/rmi_f09.c | 7 +------
 drivers/power/smb347-charger.c           | 2 +-
 5 files changed, 8 insertions(+), 9 deletions(-)

-- 
1.8.1

[RFC PATCH 1/5] arm: tegra: Fix build under Android cross-compiler

[Jeremy C. Andrus]

From: "Jeremy C. Andrus" <jeremya-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>

This patch explicitly enables ARM security extensions in sleep.S.
This fixes kernel builds with Android provided ARM cross-compilers
which do not assume the presence of the security extensions.

Signed-off-by: Jeremy C. Andrus <jeremya-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>

Change-Id: Id079d54ad0cecf9145b9d51aaeebf4e6a22e80a2
Cc: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
Cc: Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>
---
 arch/arm/mach-tegra/sleep.S | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/mach-tegra/sleep.S b/arch/arm/mach-tegra/sleep.S
index 18b8799..4e898b8 100644
--- a/arch/arm/mach-tegra/sleep.S
+++ b/arch/arm/mach-tegra/sleep.S
@@ -50,6 +50,15 @@
 #define TEGRA_CLK_RESET_VIRT	(TEGRA_CLK_RESET_BASE - IO_PPSB_PHYS + IO_PPSB_VIRT)
 
 /*
+ * ARM security extensions are required when compiling TRUSTED_FOUNDATIONS code,
+ * and this explicit arch_extension line fixes the build on compilers where the
+ * as-instr Makefile function fails. The Android cross-compiler is an example.
+ */
+#ifdef CONFIG_TRUSTED_FOUNDATIONS
+.arch_extension sec
+#endif
+
+/*
  * tegra_pen_lock
  *
  * spinlock implementation with no atomic test-and-set and no coherence
-- 
1.8.1

[RFC PATCH 2/5] arm: tegra: Fix modem_reset_flag assignment

[Jeremy C. Andrus]

From: "Jeremy C. Andrus" <jeremya-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>

The modem_reset_flag should be assigned to 0
(not checked for equality to 0)

Signed-off-by: Jeremy C. Andrus <jeremya-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>

Change-Id: I39043807644861e2ba4219723d763298c3b41203
Cc: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
Cc: Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>
---
 arch/arm/mach-tegra/baseband-xmm-power.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/baseband-xmm-power.c b/arch/arm/mach-tegra/baseband-xmm-power.c
index 11d9b3f..40ef4e1 100755
--- a/arch/arm/mach-tegra/baseband-xmm-power.c
+++ b/arch/arm/mach-tegra/baseband-xmm-power.c
@@ -807,7 +807,7 @@ static void baseband_xmm_power_init2_work(struct work_struct *work)
 		} else
 			pr_err("%s: hsic_register is missing\n", __func__);
 		register_hsic_device = false;
-		modem_reset_flag == 0;
+		modem_reset_flag = 0;
 	}
 
 }
-- 
1.8.1

[RFC PATCH 3/5] power: smb347: Fix stack corruption

[Jeremy C. Andrus]

From: "Jeremy C. Andrus" <jeremya-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>

Stack array variables declared in smb347_reg_show() were one element too
short. This patch increases the arrays to their proper size.

Signed-off-by: Jeremy C. Andrus <jeremya-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>

Change-Id: I1db786a473cf176899050eb671309af463a9878d
Cc: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
Cc: Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>
---
 drivers/power/smb347-charger.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/power/smb347-charger.c b/drivers/power/smb347-charger.c
index ff3d233..504c5c6 100755
--- a/drivers/power/smb347-charger.c
+++ b/drivers/power/smb347-charger.c
@@ -1016,7 +1016,7 @@ static void dockin_isr_work_function(struct work_struct *dat)
 static ssize_t smb347_reg_show(struct device *dev, struct device_attribute *attr, char *buf)
 {
 	struct i2c_client *client = charger->client;
-	uint8_t config_reg[14], cmd_reg[1], status_reg[10];
+	uint8_t config_reg[14], cmd_reg[2], status_reg[11];
 	int i, ret = 0;
 
 	ret += i2c_smbus_read_i2c_block_data(client, smb347_CHARGE, 15, config_reg)
-- 
1.8.1

[RFC PATCH 4/5] input: lid: Fix init function ignores sysfs retval

[Jeremy C. Andrus]

From: "Jeremy C. Andrus" <jeremya-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>

Don't ignore the sysfs_create_group return value in the lid_init()
function. This suppresses a compiler warning and results in more robust
code for free :-)

Signed-off-by: Jeremy C. Andrus <jeremya-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>

Change-Id: I2fef38736d39fbd5f60ef5a658f14d917122b942
Cc: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
Cc: Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>
---
 drivers/input/lid.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/input/lid.c b/drivers/input/lid.c
index 1d27609..26e3d64 100644
--- a/drivers/input/lid.c
+++ b/drivers/input/lid.c
@@ -163,7 +163,9 @@ static int __init lid_init(void)
                 return -ENOMEM;
         }
 
-	sysfs_create_group((struct kobject*)&lid_dev->dev.kobj, &lid_attr_group);
+	err_code = sysfs_create_group((struct kobject*)&lid_dev->dev.kobj, &lid_attr_group);
+	if (err_code != 0)
+		return err_code;
 
 	err_code = lid_input_device_create();
 	if(err_code != 0)
-- 
1.8.1

[RFC PATCH 5/5] input: touchscreen: Fix rmi4 sysfs and driver removal

[Jeremy C. Andrus]

From: "Jeremy C. Andrus" <jeremya-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>

The "InternalLimits" sysfs entry used the "Limit_Register_Count" show
function. This has been changed to the correct "InternalLimits" function.

The rmi_f09_remove function tries to kfree u8 values which could never
hold memory pointers. I have removed the offending code, but would
appreciate feedback from one more knowledgeable than myself.

Signed-off-by: Jeremy C. Andrus <jeremya-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>

Change-Id: I54ca675af8eae19f7dfb3494d531baaab0281dfb
Cc: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
Cc: Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>
---
 drivers/input/touchscreen/rmi4/rmi_f09.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/input/touchscreen/rmi4/rmi_f09.c b/drivers/input/touchscreen/rmi4/rmi_f09.c
index 0ec980d..f1f0d01 100644
--- a/drivers/input/touchscreen/rmi4/rmi_f09.c
+++ b/drivers/input/touchscreen/rmi4/rmi_f09.c
@@ -107,7 +107,7 @@ static struct device_attribute attrs[] = {
 	__ATTR(HostTestEn, RMI_RW_ATTR,
 	       rmi_f09_HostTestEn_show, rmi_f09_HostTestEn_store),
 	__ATTR(InternalLimits, RMI_RO_ATTR,
-	       rmi_f09_Limit_Register_Count_show, rmi_store_error),
+	       rmi_f09_InternalLimits_show, rmi_store_error),
 	__ATTR(Result_Register_Count, RMI_RO_ATTR,
 	       rmi_f09_Result_Register_Count_show, rmi_store_error),
 };
@@ -169,11 +169,6 @@ error_exit:
 
 static void rmi_f09_remove(struct rmi_function_container *fc)
 {
-	struct rmi_fn_09_data *data = fc->data;
-	if (data) {
-		kfree(data->query.Limit_Register_Count);
-		kfree(data->query.f09_bist_query1);
-	}
 	kfree(fc->data);
 }
 
-- 
1.8.1

Re: [RFC PATCH 0/5] Minor bugfixes for Tegra kernels

[Stephen Warren]

On 01/16/2013 12:56 PM, Jeremy C. Andrus wrote:
> From: "Jeremy C. Andrus" <jeremya-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
> 
> In the course of my research here at Columbia University, I have been
> doing some kernel development on the Google Nexus 7 device. I took the
> time to address most of the compile-time warnings while building the
> Tegra kernel tree using the cross-compiler shipped with Android
> (gcc-4.7), and in doing so I came across a few minor issues.
> 
> This RFC series addresses several minor bugs that I was able to fix
> while suppressing compile warnings. Not knowing exactly where
> to send the patches, I decided to send them primarily to the Tegra
> list serv in hopes that they will find their way to the correct place.
> 
> All 5 patches apply cleanly the kernel/tegra repository hosted by
> Google. I used the commit hash referenced in the Android device tree
> git logs as my HEAD revision: 22b4fcde206e96f57bf0a111403fc3d75532918a
> I belive that this is the revision which corresponds to the prebuilt
> kernel provided in the Jelly Bean release.

I honestly don't know where you should send these patches. I've CC'd
Colin Cross who works on Android in case he can clue us in. I assume
there's a Gerrit instance somewhere for Android that you need to push
these into...

Laxman, can you please check if any of these patches should be applied
to our internal/downstream kernels?

Jeremy, do patches 3 or 4 need to be applied to the mainline kernel? It
may be useful for you to resend those directly to the relevant upstream
subsystem maintainers, after rebasing them onto the latest upstream
code. See Documentation/SubmittingPatches in the mainline kernel.

Thanks for the contributions!

Re: [RFC PATCH 0/5] Minor bugfixes for Tegra kernels

[Jeremy Andrus]

On Jan 16, 2013, at 4:45 PM, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote:

> On 01/16/2013 12:56 PM, Jeremy C. Andrus wrote:
>> From: "Jeremy C. Andrus" <jeremya-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
>> 
>> In the course of my research here at Columbia University, I have been
>> doing some kernel development on the Google Nexus 7 device. I took the
>> time to address most of the compile-time warnings while building the
>> Tegra kernel tree using the cross-compiler shipped with Android
>> (gcc-4.7), and in doing so I came across a few minor issues.
>> 
>> This RFC series addresses several minor bugs that I was able to fix
>> while suppressing compile warnings. Not knowing exactly where
>> to send the patches, I decided to send them primarily to the Tegra
>> list serv in hopes that they will find their way to the correct place.
>> 
>> All 5 patches apply cleanly the kernel/tegra repository hosted by
>> Google. I used the commit hash referenced in the Android device tree
>> git logs as my HEAD revision: 22b4fcde206e96f57bf0a111403fc3d75532918a
>> I belive that this is the revision which corresponds to the prebuilt
>> kernel provided in the Jelly Bean release.
> 
> I honestly don't know where you should send these patches. I've CC'd
> Colin Cross who works on Android in case he can clue us in. I assume
> there's a Gerrit instance somewhere for Android that you need to push
> these into...
> 
> Laxman, can you please check if any of these patches should be applied
> to our internal/downstream kernels?

The first patch actually fixed my build! When using the prebuilt toolchains
provided by google (as per Android build instructions), the build failed on
arch/arm/mach-tegra/sleep.S. This seems to be because the Makefile
function $(call as-instr,…) didn't function properly. I would think that some
sort of fix to make the Tegra tree build-able using Android toolchains
would be appropriate here...

> Jeremy, do patches 3 or 4 need to be applied to the mainline kernel? It
> may be useful for you to resend those directly to the relevant upstream
> subsystem maintainers, after rebasing them onto the latest upstream
> code. See Documentation/SubmittingPatches in the mainline kernel.

OK. I will send those patches out to subsystem maintainers (assuming that
they are not already fixed). 

> Thanks for the contributions!


You're welcome! This was my first experience with git-format-patch, and
it was kind of fun to re-contribute in a small way.

I actually have another set of patches that fix all the build warnings. Is
there a repo / branch that I should rebase these on and then send them
out? It was definitely worth the effort to eliminate all the warnings - it
made it a lot easier to spot my own mistakes :-)

Best,

        -Jeremy

Re: [RFC PATCH 0/5] Minor bugfixes for Tegra kernels

[Colin Cross]

On Wed, Jan 16, 2013 at 6:07 PM, Jeremy Andrus <jeremya-eQaUEPhvms7ENvBUuze7eA@public.gmane.org> wrote:
> On Jan 16, 2013, at 4:45 PM, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote:
>
>> On 01/16/2013 12:56 PM, Jeremy C. Andrus wrote:
>>> From: "Jeremy C. Andrus" <jeremya-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
>>>
>>> In the course of my research here at Columbia University, I have been
>>> doing some kernel development on the Google Nexus 7 device. I took the
>>> time to address most of the compile-time warnings while building the
>>> Tegra kernel tree using the cross-compiler shipped with Android
>>> (gcc-4.7), and in doing so I came across a few minor issues.
>>>
>>> This RFC series addresses several minor bugs that I was able to fix
>>> while suppressing compile warnings. Not knowing exactly where
>>> to send the patches, I decided to send them primarily to the Tegra
>>> list serv in hopes that they will find their way to the correct place.
>>>
>>> All 5 patches apply cleanly the kernel/tegra repository hosted by
>>> Google. I used the commit hash referenced in the Android device tree
>>> git logs as my HEAD revision: 22b4fcde206e96f57bf0a111403fc3d75532918a
>>> I belive that this is the revision which corresponds to the prebuilt
>>> kernel provided in the Jelly Bean release.
>>
>> I honestly don't know where you should send these patches. I've CC'd
>> Colin Cross who works on Android in case he can clue us in. I assume
>> there's a Gerrit instance somewhere for Android that you need to push
>> these into...
>>
>> Laxman, can you please check if any of these patches should be applied
>> to our internal/downstream kernels?
>
> The first patch actually fixed my build! When using the prebuilt toolchains
> provided by google (as per Android build instructions), the build failed on
> arch/arm/mach-tegra/sleep.S. This seems to be because the Makefile
> function $(call as-instr,…) didn't function properly. I would think that some
> sort of fix to make the Tegra tree build-able using Android toolchains
> would be appropriate here...

I don't think this has anything to do with Android except that the
toolchain shipped with Android moved to a newer version of binutils.
The as-instr in the Makefile should work fine and I believe is the
preferable solution over adding the arch_extension to sleep.S, maybe
it has a typo?

>> Jeremy, do patches 3 or 4 need to be applied to the mainline kernel? It
>> may be useful for you to resend those directly to the relevant upstream
>> subsystem maintainers, after rebasing them onto the latest upstream
>> code. See Documentation/SubmittingPatches in the mainline kernel.
>
> OK. I will send those patches out to subsystem maintainers (assuming that
> they are not already fixed).
>
>> Thanks for the contributions!
>
>
> You're welcome! This was my first experience with git-format-patch, and
> it was kind of fun to re-contribute in a small way.
>
> I actually have another set of patches that fix all the build warnings. Is
> there a repo / branch that I should rebase these on and then send them
> out? It was definitely worth the effort to eliminate all the warnings - it
> made it a lot easier to spot my own mistakes :-)
>
> Best,
>
>         -Jeremy
>

Re: [RFC PATCH 0/5] Minor bugfixes for Tegra kernels

[Jeremy Andrus]

On Jan 16, 2013, at 9:37 PM, Colin Cross <ccross-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org> wrote:

> On Wed, Jan 16, 2013 at 6:07 PM, Jeremy Andrus <jeremya-eQaUEPhvms5yEmSbqHaMZw@public.gmane.orgdu> wrote:
>> On Jan 16, 2013, at 4:45 PM, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote:
>> 
>>> On 01/16/2013 12:56 PM, Jeremy C. Andrus wrote:
>>>> From: "Jeremy C. Andrus" <jeremya-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
>>>> 
>>>> In the course of my research here at Columbia University, I have been
>>>> doing some kernel development on the Google Nexus 7 device. I took the
>>>> time to address most of the compile-time warnings while building the
>>>> Tegra kernel tree using the cross-compiler shipped with Android
>>>> (gcc-4.7), and in doing so I came across a few minor issues.
>>>> 
>>>> This RFC series addresses several minor bugs that I was able to fix
>>>> while suppressing compile warnings. Not knowing exactly where
>>>> to send the patches, I decided to send them primarily to the Tegra
>>>> list serv in hopes that they will find their way to the correct place.
>>>> 
>>>> All 5 patches apply cleanly the kernel/tegra repository hosted by
>>>> Google. I used the commit hash referenced in the Android device tree
>>>> git logs as my HEAD revision: 22b4fcde206e96f57bf0a111403fc3d75532918a
>>>> I belive that this is the revision which corresponds to the prebuilt
>>>> kernel provided in the Jelly Bean release.
>>> 
>>> I honestly don't know where you should send these patches. I've CC'd
>>> Colin Cross who works on Android in case he can clue us in. I assume
>>> there's a Gerrit instance somewhere for Android that you need to push
>>> these into...
>>> 
>>> Laxman, can you please check if any of these patches should be applied
>>> to our internal/downstream kernels?
>> 
>> The first patch actually fixed my build! When using the prebuilt toolchains
>> provided by google (as per Android build instructions), the build failed on
>> arch/arm/mach-tegra/sleep.S. This seems to be because the Makefile
>> function $(call as-instr,…) didn't function properly. I would think that some
>> sort of fix to make the Tegra tree build-able using Android toolchains
>> would be appropriate here...
> 
> I don't think this has anything to do with Android except that the
> toolchain shipped with Android moved to a newer version of binutils.
> The as-instr in the Makefile should work fine and I believe is the
> preferable solution over adding the arch_extension to sleep.S, maybe
> it has a typo?

I can take a look. I would agree that a Makefile solution slightly more clean.
Unfortunately, the tree available from Google which corresponds to the
Jelly Bean release won't build with the Android toolchain. I tried both the gcc-4.6
and gcc-4.7 prebuilts. It seems like the define in the file isn't a horrible solution
though - the code obviously requires the extension...


>>> Jeremy, do patches 3 or 4 need to be applied to the mainline kernel? It
>>> may be useful for you to resend those directly to the relevant upstream
>>> subsystem maintainers, after rebasing them onto the latest upstream
>>> code. See Documentation/SubmittingPatches in the mainline kernel.
>> 
>> OK. I will send those patches out to subsystem maintainers (assuming that
>> they are not already fixed).
>> 
>>> Thanks for the contributions!
>> 
>> 
>> You're welcome! This was my first experience with git-format-patch, and
>> it was kind of fun to re-contribute in a small way.
>> 
>> I actually have another set of patches that fix all the build warnings. Is
>> there a repo / branch that I should rebase these on and then send them
>> out? It was definitely worth the effort to eliminate all the warnings - it
>> made it a lot easier to spot my own mistakes :-)
>> 
>> Best,
>> 
>>        -Jeremy
>> 

-- 
--------------------------------------------------
Jeremy C. Andrus

e: jchristian.andrus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
w: http://jeremya.com/
l: New York, NY
p: 616,439,0522
--------------------------------------------------