@@ -1,6 +1,6 @@-MediaTek MT6397 Multifunction Device Driver+MediaTek MT6397/MT6323 Multifunction Device Driver-MT6397 is a multifunction device with the following sub modules:+MT6397/MT6323 is a multifunction device with the following sub modules: - Regulator - RTC - Audio codec
@@ -8,14 +8,14 @@ MT6397 is a multifunction device with the following sub modules: - Clock It is interfaced to host controller using SPI interface by a proprietary hardware-called PMIC wrapper or pwrap. MT6397 MFD is a child device of pwrap.+called PMIC wrapper or pwrap. MT6397/MT6323 MFD is a child device of pwrap. See the following for pwarp node definitions: Documentation/devicetree/bindings/soc/pwrap.txt This document describes the binding for MFD device and its sub module. Required properties:-compatible: "mediatek,mt6397"+compatible: "mediatek,mt6397" or "mediatek,mt6323" Optional subnodes:
From: John Crispin <hidden> Date: 2016-01-25 10:15:44
MT6323 has the INT_CON and INT_STATUS located at a different position.
Make the registers locations configurable.
Signed-off-by: John Crispin <redacted>
---
drivers/mfd/mt6397-core.c | 27 +++++++++++++++++----------
include/linux/mfd/mt6397/core.h | 2 ++
2 files changed, 19 insertions(+), 10 deletions(-)
From: Lee Jones <hidden> Date: 2016-01-25 12:34:01
On Mon, 25 Jan 2016, John Crispin wrote:
MT6323 has the INT_CON and INT_STATUS located at a different position.
Make the registers locations configurable.
Signed-off-by: John Crispin <redacted>
---
drivers/mfd/mt6397-core.c | 27 +++++++++++++++++----------
include/linux/mfd/mt6397/core.h | 2 ++
2 files changed, 19 insertions(+), 10 deletions(-)
For my own reference:
Acked-by: Lee Jones [off-list ref]
From: Lee Jones <hidden> Date: 2016-01-25 12:41:20
Please honour the subject format of the subsystem you are contributing
to.
`git log --oneline -- $subsystem` gives you this.
On Mon, 25 Jan 2016, John Crispin wrote:
+ * This program is free software; you can redistribute it and/or modify+ * it under the terms of the GNU General Public License version 2 as+ * published by the Free Software Foundation.+ *+ * This program is distributed in the hope that it will be useful,+ * but WITHOUT ANY WARRANTY; without even the implied warranty of+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the+ * GNU General Public License for more details.
@@ -1,6 +1,6 @@-MediaTek MT6397 Multifunction Device Driver+MediaTek MT6397/MT6323 Multifunction Device Driver-MT6397 is a multifunction device with the following sub modules:+MT6397/MT6323 is a multifunction device with the following sub modules: - Regulator - RTC - Audio codec
@@ -8,14 +8,14 @@ MT6397 is a multifunction device with the following sub modules: - Clock It is interfaced to host controller using SPI interface by a proprietary hardware-called PMIC wrapper or pwrap. MT6397 MFD is a child device of pwrap.+called PMIC wrapper or pwrap. MT6397/MT6323 MFD is a child device of pwrap. See the following for pwarp node definitions: Documentation/devicetree/bindings/soc/pwrap.txt This document describes the binding for MFD device and its sub module. Required properties:-compatible: "mediatek,mt6397"+compatible: "mediatek,mt6397" or "mediatek,mt6323" Optional subnodes:
From: John Crispin <hidden> Date: 2016-01-25 15:36:46
Hi,
On 25/01/2016 13:41, Lee Jones wrote:
Please honour the subject format of the subsystem you are contributing
to.
`git log --oneline -- $subsystem` gives you this.
On Mon, 25 Jan 2016, John Crispin wrote:
quoted
Signed-off-by: John Crispin <redacted>
---
[...]
quoted
@@ -261,6 +271,15 @@ static int mt6397_probe(struct platform_device *pdev) } switch (id & 0xff) {+ case MT6323_CID_CODE:+ mt6397->int_con[0] = MT6323_INT_CON0;
This is confusing. You're still using memory allocated for a mt6397
device.
the variable is currently defined as struct mt6397_chip *mt6397;
shall i only change the name or also create a patch to rename the struct ?
John
On Monday 25 Jan 2016 16:36:40 John Crispin wrote:
Hi,
On 25/01/2016 13:41, Lee Jones wrote:
quoted
Please honour the subject format of the subsystem you are contributing
to.
`git log --oneline -- $subsystem` gives you this.
On Mon, 25 Jan 2016, John Crispin wrote:
quoted
Signed-off-by: John Crispin <redacted>
---
[...]
quoted
quoted
@@ -261,6 +271,15 @@ static int mt6397_probe(struct platform_device
*pdev)
}
switch (id & 0xff) {
+ case MT6323_CID_CODE:
+ mt6397->int_con[0] = MT6323_INT_CON0;
This is confusing. You're still using memory allocated for a mt6397
device.
the variable is currently defined as struct mt6397_chip *mt6397;
shall i only change the name or also create a patch to rename the struct ?
I think we should rename the struct and the file as well.
Cheers,
Matthias
From: John Crispin <hidden> Date: 2016-01-25 19:00:01
On 25/01/2016 19:44, Matthias Brugger wrote:
On Monday 25 Jan 2016 16:36:40 John Crispin wrote:
quoted
Hi,
On 25/01/2016 13:41, Lee Jones wrote:
quoted
Please honour the subject format of the subsystem you are contributing
to.
`git log --oneline -- $subsystem` gives you this.
On Mon, 25 Jan 2016, John Crispin wrote:
quoted
Signed-off-by: John Crispin <redacted>
---
[...]
quoted
quoted
@@ -261,6 +271,15 @@ static int mt6397_probe(struct platform_device
*pdev)
}
switch (id & 0xff) {
+ case MT6323_CID_CODE:
+ mt6397->int_con[0] = MT6323_INT_CON0;
This is confusing. You're still using memory allocated for a mt6397
device.
the variable is currently defined as struct mt6397_chip *mt6397;
shall i only change the name or also create a patch to rename the struct ?
I think we should rename the struct and the file as well.
Cheers,
Matthias
Hi,
that would have been my next question. renaming the struct would imply
renaming the driver and the whole namespace contained within. We would
then also need to change the Kconfig and Makefile. I am happy to do this
but want to be sure that is is actually wanted.
John
From: Henry Chen <hidden> Date: 2016-01-26 03:37:27
On Mon, 2016-01-25 at 19:59 +0100, John Crispin wrote:
On 25/01/2016 19:44, Matthias Brugger wrote:
quoted
On Monday 25 Jan 2016 16:36:40 John Crispin wrote:
quoted
Hi,
On 25/01/2016 13:41, Lee Jones wrote:
quoted
Please honour the subject format of the subsystem you are contributing
to.
`git log --oneline -- $subsystem` gives you this.
On Mon, 25 Jan 2016, John Crispin wrote:
quoted
Signed-off-by: John Crispin <redacted>
---
[...]
quoted
quoted
@@ -261,6 +271,15 @@ static int mt6397_probe(struct platform_device
*pdev)
}
switch (id & 0xff) {
+ case MT6323_CID_CODE:
+ mt6397->int_con[0] = MT6323_INT_CON0;
This is confusing. You're still using memory allocated for a mt6397
device.
the variable is currently defined as struct mt6397_chip *mt6397;
shall i only change the name or also create a patch to rename the struct ?
I think we should rename the struct and the file as well.
Cheers,
Matthias
Hi,
that would have been my next question. renaming the struct would imply
renaming the driver and the whole namespace contained within. We would
then also need to change the Kconfig and Makefile. I am happy to do this
but want to be sure that is is actually wanted.
John
Hi,
Since mt6323 was similar with mt6397, I think we can reuse the
mt6397_chip without duplicate code.
Maybe we can rename the local variable name to avoid confusing.
struct mt6397_chip *mt_pmic;
...
...
switch (id & 0xff) {
case MT6323_CID_CODE:
mt_pmic->int_con[0] = MT6323_INT_CON0;
mt_pmic->int_con[1] = MT6323_INT_CON1;
...
...
Henry
From: John Crispin <hidden> Date: 2016-01-26 07:14:59
On 26/01/2016 04:07, Henry Chen wrote:
On Mon, 2016-01-25 at 19:59 +0100, John Crispin wrote:
quoted
On 25/01/2016 19:44, Matthias Brugger wrote:
quoted
On Monday 25 Jan 2016 16:36:40 John Crispin wrote:
quoted
Hi,
On 25/01/2016 13:41, Lee Jones wrote:
quoted
Please honour the subject format of the subsystem you are contributing
to.
`git log --oneline -- $subsystem` gives you this.
On Mon, 25 Jan 2016, John Crispin wrote:
quoted
Signed-off-by: John Crispin <redacted>
---
[...]
quoted
quoted
@@ -261,6 +271,15 @@ static int mt6397_probe(struct platform_device
*pdev)
}
switch (id & 0xff) {
+ case MT6323_CID_CODE:
+ mt6397->int_con[0] = MT6323_INT_CON0;
This is confusing. You're still using memory allocated for a mt6397
device.
the variable is currently defined as struct mt6397_chip *mt6397;
shall i only change the name or also create a patch to rename the struct ?
I think we should rename the struct and the file as well.
Cheers,
Matthias
Hi,
that would have been my next question. renaming the struct would imply
renaming the driver and the whole namespace contained within. We would
then also need to change the Kconfig and Makefile. I am happy to do this
but want to be sure that is is actually wanted.
John
Hi,
Since mt6323 was similar with mt6397, I think we can reuse the
mt6397_chip without duplicate code.
Maybe we can rename the local variable name to avoid confusing.
struct mt6397_chip *mt_pmic;
...
...
switch (id & 0xff) {
case MT6323_CID_CODE:
mt_pmic->int_con[0] = MT6323_INT_CON0;
mt_pmic->int_con[1] = MT6323_INT_CON1;
...
...
Henry
Hi,
IMHO we should either rename the namespace or not. renaming some
variables seems weird as that will just move the confusion/inconsistency
to another place in the code. I am however rather indifferent on this
matter.
John
From: Lee Jones <hidden> Date: 2016-01-26 08:34:43
On Tue, 26 Jan 2016, John Crispin wrote:
On 26/01/2016 04:07, Henry Chen wrote:
quoted
On Mon, 2016-01-25 at 19:59 +0100, John Crispin wrote:
quoted
On 25/01/2016 19:44, Matthias Brugger wrote:
quoted
On Monday 25 Jan 2016 16:36:40 John Crispin wrote:
quoted
Hi,
On 25/01/2016 13:41, Lee Jones wrote:
quoted
Please honour the subject format of the subsystem you are contributing
to.
`git log --oneline -- $subsystem` gives you this.
On Mon, 25 Jan 2016, John Crispin wrote:
quoted
Signed-off-by: John Crispin <redacted>
---
[...]
quoted
quoted
@@ -261,6 +271,15 @@ static int mt6397_probe(struct platform_device
*pdev)
}
switch (id & 0xff) {
+ case MT6323_CID_CODE:
+ mt6397->int_con[0] = MT6323_INT_CON0;
This is confusing. You're still using memory allocated for a mt6397
device.
the variable is currently defined as struct mt6397_chip *mt6397;
shall i only change the name or also create a patch to rename the struct ?
I think we should rename the struct and the file as well.
Cheers,
Matthias
Hi,
that would have been my next question. renaming the struct would imply
renaming the driver and the whole namespace contained within. We would
then also need to change the Kconfig and Makefile. I am happy to do this
but want to be sure that is is actually wanted.
John
Hi,
Since mt6323 was similar with mt6397, I think we can reuse the
mt6397_chip without duplicate code.
Maybe we can rename the local variable name to avoid confusing.
struct mt6397_chip *mt_pmic;
...
...
switch (id & 0xff) {
case MT6323_CID_CODE:
mt_pmic->int_con[0] = MT6323_INT_CON0;
mt_pmic->int_con[1] = MT6323_INT_CON1;
...
...
Henry
Hi,
IMHO we should either rename the namespace or not. renaming some
variables seems weird as that will just move the confusion/inconsistency
to another place in the code. I am however rather indifferent on this
matter.
It's common to name a driver after the device which was enabled first,
so no need to rename the files or CONFIGs; however, it does seem
prudent to generify the struct (both parts).
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
From: John Crispin <hidden> Date: 2016-01-26 08:44:52
On 26/01/2016 09:34, Lee Jones wrote:
On Tue, 26 Jan 2016, John Crispin wrote:
quoted
On 26/01/2016 04:07, Henry Chen wrote:
quoted
On Mon, 2016-01-25 at 19:59 +0100, John Crispin wrote:
quoted
On 25/01/2016 19:44, Matthias Brugger wrote:
quoted
On Monday 25 Jan 2016 16:36:40 John Crispin wrote:
quoted
Hi,
On 25/01/2016 13:41, Lee Jones wrote:
quoted
Please honour the subject format of the subsystem you are contributing
to.
`git log --oneline -- $subsystem` gives you this.
On Mon, 25 Jan 2016, John Crispin wrote:
quoted
Signed-off-by: John Crispin <redacted>
---
[...]
quoted
quoted
@@ -261,6 +271,15 @@ static int mt6397_probe(struct platform_device
*pdev)
}
switch (id & 0xff) {
+ case MT6323_CID_CODE:
+ mt6397->int_con[0] = MT6323_INT_CON0;
This is confusing. You're still using memory allocated for a mt6397
device.
the variable is currently defined as struct mt6397_chip *mt6397;
shall i only change the name or also create a patch to rename the struct ?
I think we should rename the struct and the file as well.
Cheers,
Matthias
Hi,
that would have been my next question. renaming the struct would imply
renaming the driver and the whole namespace contained within. We would
then also need to change the Kconfig and Makefile. I am happy to do this
but want to be sure that is is actually wanted.
John
Hi,
Since mt6323 was similar with mt6397, I think we can reuse the
mt6397_chip without duplicate code.
Maybe we can rename the local variable name to avoid confusing.
struct mt6397_chip *mt_pmic;
...
...
switch (id & 0xff) {
case MT6323_CID_CODE:
mt_pmic->int_con[0] = MT6323_INT_CON0;
mt_pmic->int_con[1] = MT6323_INT_CON1;
...
...
Henry
Hi,
IMHO we should either rename the namespace or not. renaming some
variables seems weird as that will just move the confusion/inconsistency
to another place in the code. I am however rather indifferent on this
matter.
It's common to name a driver after the device which was enabled first,
so no need to rename the files or CONFIGs; however, it does seem
prudent to generify the struct (both parts).
Hi Lee,
fine, how would you like me to name the struct. would
"struct mtk_pmic" be ok ?
John
From: John Crispin <hidden> Date: 2016-01-26 12:05:38
On 26/01/2016 09:34, Lee Jones wrote:
On Tue, 26 Jan 2016, John Crispin wrote:
quoted
On 26/01/2016 04:07, Henry Chen wrote:
quoted
On Mon, 2016-01-25 at 19:59 +0100, John Crispin wrote:
quoted
On 25/01/2016 19:44, Matthias Brugger wrote:
quoted
On Monday 25 Jan 2016 16:36:40 John Crispin wrote:
quoted
Hi,
On 25/01/2016 13:41, Lee Jones wrote:
quoted
Please honour the subject format of the subsystem you are contributing
to.
`git log --oneline -- $subsystem` gives you this.
On Mon, 25 Jan 2016, John Crispin wrote:
quoted
Signed-off-by: John Crispin <redacted>
---
[...]
quoted
quoted
@@ -261,6 +271,15 @@ static int mt6397_probe(struct platform_device
*pdev)
}
switch (id & 0xff) {
+ case MT6323_CID_CODE:
+ mt6397->int_con[0] = MT6323_INT_CON0;
This is confusing. You're still using memory allocated for a mt6397
device.
the variable is currently defined as struct mt6397_chip *mt6397;
shall i only change the name or also create a patch to rename the struct ?
I think we should rename the struct and the file as well.
Cheers,
Matthias
Hi,
that would have been my next question. renaming the struct would imply
renaming the driver and the whole namespace contained within. We would
then also need to change the Kconfig and Makefile. I am happy to do this
but want to be sure that is is actually wanted.
John
Hi,
Since mt6323 was similar with mt6397, I think we can reuse the
mt6397_chip without duplicate code.
Maybe we can rename the local variable name to avoid confusing.
struct mt6397_chip *mt_pmic;
...
...
switch (id & 0xff) {
case MT6323_CID_CODE:
mt_pmic->int_con[0] = MT6323_INT_CON0;
mt_pmic->int_con[1] = MT6323_INT_CON1;
...
...
Henry
Hi,
IMHO we should either rename the namespace or not. renaming some
variables seems weird as that will just move the confusion/inconsistency
to another place in the code. I am however rather indifferent on this
matter.
It's common to name a driver after the device which was enabled first,
so no need to rename the files or CONFIGs; however, it does seem
prudent to generify the struct (both parts).
Hi,
renaming struct mt6397_chip is not as straightforward as it seems as
other drivers such as pinctrl and rtc share the data structure with the
mfd driver.
i have kept the structs name as is for now and only renamed the instance.
If you want i can create a separate series that addresses only the
renaming of the structure. The "rename struct mt6397" patch would need
to do a change to drivers from 3 subsystems in 1 single commit as not to
break compile and merge order.
John
From: Lee Jones <hidden> Date: 2016-01-26 14:00:15
On Tue, 26 Jan 2016, John Crispin wrote:
On 26/01/2016 09:34, Lee Jones wrote:
quoted
On Tue, 26 Jan 2016, John Crispin wrote:
quoted
On 26/01/2016 04:07, Henry Chen wrote:
quoted
On Mon, 2016-01-25 at 19:59 +0100, John Crispin wrote:
quoted
On 25/01/2016 19:44, Matthias Brugger wrote:
quoted
On Monday 25 Jan 2016 16:36:40 John Crispin wrote:
quoted
Hi,
On 25/01/2016 13:41, Lee Jones wrote:
quoted
Please honour the subject format of the subsystem you are contributing
to.
`git log --oneline -- $subsystem` gives you this.
On Mon, 25 Jan 2016, John Crispin wrote:
quoted
Signed-off-by: John Crispin <redacted>
---
[...]
quoted
quoted
@@ -261,6 +271,15 @@ static int mt6397_probe(struct platform_device
*pdev)
}
switch (id & 0xff) {
+ case MT6323_CID_CODE:
+ mt6397->int_con[0] = MT6323_INT_CON0;
This is confusing. You're still using memory allocated for a mt6397
device.
the variable is currently defined as struct mt6397_chip *mt6397;
shall i only change the name or also create a patch to rename the struct ?
I think we should rename the struct and the file as well.
Cheers,
Matthias
Hi,
that would have been my next question. renaming the struct would imply
renaming the driver and the whole namespace contained within. We would
then also need to change the Kconfig and Makefile. I am happy to do this
but want to be sure that is is actually wanted.
John
Hi,
Since mt6323 was similar with mt6397, I think we can reuse the
mt6397_chip without duplicate code.
Maybe we can rename the local variable name to avoid confusing.
struct mt6397_chip *mt_pmic;
...
...
switch (id & 0xff) {
case MT6323_CID_CODE:
mt_pmic->int_con[0] = MT6323_INT_CON0;
mt_pmic->int_con[1] = MT6323_INT_CON1;
...
...
Henry
Hi,
IMHO we should either rename the namespace or not. renaming some
variables seems weird as that will just move the confusion/inconsistency
to another place in the code. I am however rather indifferent on this
matter.
It's common to name a driver after the device which was enabled first,
so no need to rename the files or CONFIGs; however, it does seem
prudent to generify the struct (both parts).
Hi,
renaming struct mt6397_chip is not as straightforward as it seems as
other drivers such as pinctrl and rtc share the data structure with the
mfd driver.
i have kept the structs name as is for now and only renamed the instance.
That's fine.
If you want i can create a separate series that addresses only the
renaming of the structure. The "rename struct mt6397" patch would need
to do a change to drivers from 3 subsystems in 1 single commit as not to
break compile and merge order.
I'll leave this up to you.
The real problem from my PoV was the instance name.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog