* [PATCH 0/3] media:st-rc: Misc fixes.
@ 2014-09-22 22:21 ` Srinivas Kandagatla
0 siblings, 0 replies; 22+ messages in thread
From: Srinivas Kandagatla @ 2014-09-22 22:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi Mauro,
Thankyou for the "[media] enable COMPILE_TEST for media drivers" patch
which picked up few things in st-rc driver in linux-next testing.
Here is a few minor fixes to the driver, could you consider them for
the next merge window.
Thanks,
srini
Srinivas Kandagatla (3):
media: st-rc: move to using reset_control_get_optional
media: st-rc: move pm ops setup out of conditional compilation.
media: st-rc: Remove .owner field for driver
drivers/media/rc/st_rc.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
--
1.9.1
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 1/3] media: st-rc: move to using reset_control_get_optional
2014-09-22 22:21 ` Srinivas Kandagatla
@ 2014-09-22 22:22 ` Srinivas Kandagatla
-1 siblings, 0 replies; 22+ messages in thread
From: Srinivas Kandagatla @ 2014-09-22 22:22 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Maxime Coquelin, Patrice Chotard, linux-arm-kernel, kernel,
linux-media, linux-kernel, Srinivas Kandagatla
This patch fixes a compilation error while building with the
random kernel configuration.
drivers/media/rc/st_rc.c: In function 'st_rc_probe':
drivers/media/rc/st_rc.c:281:2: error: implicit declaration of
function 'reset_control_get' [-Werror=implicit-function-declaration]
rc_dev->rstc = reset_control_get(dev, NULL);
drivers/media/rc/st_rc.c:281:15: warning: assignment makes pointer
from integer without a cast [enabled by default]
rc_dev->rstc = reset_control_get(dev, NULL);
Reported-by: Jim Davis <jim.epost@gmail.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
drivers/media/rc/st_rc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/rc/st_rc.c b/drivers/media/rc/st_rc.c
index 5c15135..e0f1312 100644
--- a/drivers/media/rc/st_rc.c
+++ b/drivers/media/rc/st_rc.c
@@ -278,7 +278,7 @@ static int st_rc_probe(struct platform_device *pdev)
rc_dev->rx_base = rc_dev->base;
- rc_dev->rstc = reset_control_get(dev, NULL);
+ rc_dev->rstc = reset_control_get_optional(dev, NULL);
if (IS_ERR(rc_dev->rstc))
rc_dev->rstc = NULL;
--
1.9.1
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH 1/3] media: st-rc: move to using reset_control_get_optional
@ 2014-09-22 22:22 ` Srinivas Kandagatla
0 siblings, 0 replies; 22+ messages in thread
From: Srinivas Kandagatla @ 2014-09-22 22:22 UTC (permalink / raw)
To: linux-arm-kernel
This patch fixes a compilation error while building with the
random kernel configuration.
drivers/media/rc/st_rc.c: In function 'st_rc_probe':
drivers/media/rc/st_rc.c:281:2: error: implicit declaration of
function 'reset_control_get' [-Werror=implicit-function-declaration]
rc_dev->rstc = reset_control_get(dev, NULL);
drivers/media/rc/st_rc.c:281:15: warning: assignment makes pointer
from integer without a cast [enabled by default]
rc_dev->rstc = reset_control_get(dev, NULL);
Reported-by: Jim Davis <jim.epost@gmail.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
drivers/media/rc/st_rc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/rc/st_rc.c b/drivers/media/rc/st_rc.c
index 5c15135..e0f1312 100644
--- a/drivers/media/rc/st_rc.c
+++ b/drivers/media/rc/st_rc.c
@@ -278,7 +278,7 @@ static int st_rc_probe(struct platform_device *pdev)
rc_dev->rx_base = rc_dev->base;
- rc_dev->rstc = reset_control_get(dev, NULL);
+ rc_dev->rstc = reset_control_get_optional(dev, NULL);
if (IS_ERR(rc_dev->rstc))
rc_dev->rstc = NULL;
--
1.9.1
^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [STLinux Kernel] [PATCH 1/3] media: st-rc: move to using reset_control_get_optional
2014-09-22 22:22 ` Srinivas Kandagatla
@ 2014-09-23 18:02 ` Peter Griffin
-1 siblings, 0 replies; 22+ messages in thread
From: Peter Griffin @ 2014-09-23 18:02 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: Mauro Carvalho Chehab, kernel, linux-kernel, linux-arm-kernel,
linux-media
Hi Srini,
On Mon, 22 Sep 2014, Srinivas Kandagatla wrote:
> This patch fixes a compilation error while building with the
> random kernel configuration.
>
> drivers/media/rc/st_rc.c: In function 'st_rc_probe':
> drivers/media/rc/st_rc.c:281:2: error: implicit declaration of
> function 'reset_control_get' [-Werror=implicit-function-declaration]
> rc_dev->rstc = reset_control_get(dev, NULL);
>
> drivers/media/rc/st_rc.c:281:15: warning: assignment makes pointer
> from integer without a cast [enabled by default]
> rc_dev->rstc = reset_control_get(dev, NULL);
Is managing the reset line actually optional though? I can't test atm as I don't have
access to my board, but quite often if the IP's aren't taken out of reset reads / writes
to the perhpiheral will hang the SoC.
If managing the reset line isn't optional then I think the correct fix is to add
depends on RESET_CONTROLLER in the kconfig.
This will then do the right thing for randconfig builds as well.
regards,
Peter.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [STLinux Kernel] [PATCH 1/3] media: st-rc: move to using reset_control_get_optional
@ 2014-09-23 18:02 ` Peter Griffin
0 siblings, 0 replies; 22+ messages in thread
From: Peter Griffin @ 2014-09-23 18:02 UTC (permalink / raw)
To: linux-arm-kernel
Hi Srini,
On Mon, 22 Sep 2014, Srinivas Kandagatla wrote:
> This patch fixes a compilation error while building with the
> random kernel configuration.
>
> drivers/media/rc/st_rc.c: In function 'st_rc_probe':
> drivers/media/rc/st_rc.c:281:2: error: implicit declaration of
> function 'reset_control_get' [-Werror=implicit-function-declaration]
> rc_dev->rstc = reset_control_get(dev, NULL);
>
> drivers/media/rc/st_rc.c:281:15: warning: assignment makes pointer
> from integer without a cast [enabled by default]
> rc_dev->rstc = reset_control_get(dev, NULL);
Is managing the reset line actually optional though? I can't test atm as I don't have
access to my board, but quite often if the IP's aren't taken out of reset reads / writes
to the perhpiheral will hang the SoC.
If managing the reset line isn't optional then I think the correct fix is to add
depends on RESET_CONTROLLER in the kconfig.
This will then do the right thing for randconfig builds as well.
regards,
Peter.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [STLinux Kernel] [PATCH 1/3] media: st-rc: move to using reset_control_get_optional
2014-09-23 18:02 ` Peter Griffin
@ 2014-09-24 8:12 ` Srinivas Kandagatla
-1 siblings, 0 replies; 22+ messages in thread
From: Srinivas Kandagatla @ 2014-09-24 8:12 UTC (permalink / raw)
To: Peter Griffin
Cc: Mauro Carvalho Chehab, kernel, linux-kernel, linux-arm-kernel,
linux-media
Hi Pete,
On 23/09/14 19:02, Peter Griffin wrote:
> Hi Srini,
>
> On Mon, 22 Sep 2014, Srinivas Kandagatla wrote:
>
>> This patch fixes a compilation error while building with the
>> random kernel configuration.
>>
>> drivers/media/rc/st_rc.c: In function 'st_rc_probe':
>> drivers/media/rc/st_rc.c:281:2: error: implicit declaration of
>> function 'reset_control_get' [-Werror=implicit-function-declaration]
>> rc_dev->rstc = reset_control_get(dev, NULL);
>>
>> drivers/media/rc/st_rc.c:281:15: warning: assignment makes pointer
>> from integer without a cast [enabled by default]
>> rc_dev->rstc = reset_control_get(dev, NULL);
>
> Is managing the reset line actually optional though? I can't test atm as I don't have
> access to my board, but quite often if the IP's aren't taken out of reset reads / writes
> to the perhpiheral will hang the SoC.
>
Yes and No.
AFAIK reset line is optional on SOCs like 7108, 7141.
I think having the driver function without reset might is a value add in
case we plan to reuse the mainline driver for these SOCs.
On latest ARM SOCs with SBC the IRB IP is moved to SBC and held in reset.
Am not sure, if the reset line is optional in next generation SOCs?
> If managing the reset line isn't optional then I think the correct fix is to add
> depends on RESET_CONTROLLER in the kconfig.
I agree.
This would make the COMPILE_TEST less useful though.
thanks,
srini
>
> This will then do the right thing for randconfig builds as well.
>
> regards,
>
> Peter.
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* [STLinux Kernel] [PATCH 1/3] media: st-rc: move to using reset_control_get_optional
@ 2014-09-24 8:12 ` Srinivas Kandagatla
0 siblings, 0 replies; 22+ messages in thread
From: Srinivas Kandagatla @ 2014-09-24 8:12 UTC (permalink / raw)
To: linux-arm-kernel
Hi Pete,
On 23/09/14 19:02, Peter Griffin wrote:
> Hi Srini,
>
> On Mon, 22 Sep 2014, Srinivas Kandagatla wrote:
>
>> This patch fixes a compilation error while building with the
>> random kernel configuration.
>>
>> drivers/media/rc/st_rc.c: In function 'st_rc_probe':
>> drivers/media/rc/st_rc.c:281:2: error: implicit declaration of
>> function 'reset_control_get' [-Werror=implicit-function-declaration]
>> rc_dev->rstc = reset_control_get(dev, NULL);
>>
>> drivers/media/rc/st_rc.c:281:15: warning: assignment makes pointer
>> from integer without a cast [enabled by default]
>> rc_dev->rstc = reset_control_get(dev, NULL);
>
> Is managing the reset line actually optional though? I can't test atm as I don't have
> access to my board, but quite often if the IP's aren't taken out of reset reads / writes
> to the perhpiheral will hang the SoC.
>
Yes and No.
AFAIK reset line is optional on SOCs like 7108, 7141.
I think having the driver function without reset might is a value add in
case we plan to reuse the mainline driver for these SOCs.
On latest ARM SOCs with SBC the IRB IP is moved to SBC and held in reset.
Am not sure, if the reset line is optional in next generation SOCs?
> If managing the reset line isn't optional then I think the correct fix is to add
> depends on RESET_CONTROLLER in the kconfig.
I agree.
This would make the COMPILE_TEST less useful though.
thanks,
srini
>
> This will then do the right thing for randconfig builds as well.
>
> regards,
>
> Peter.
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [STLinux Kernel] [PATCH 1/3] media: st-rc: move to using reset_control_get_optional
2014-09-24 8:12 ` Srinivas Kandagatla
@ 2014-09-24 8:37 ` Maxime Coquelin
-1 siblings, 0 replies; 22+ messages in thread
From: Maxime Coquelin @ 2014-09-24 8:37 UTC (permalink / raw)
To: Srinivas Kandagatla, Peter Griffin
Cc: linux-kernel, linux-media, kernel, linux-arm-kernel,
Mauro Carvalho Chehab
Hi Srini, Peter,
On 09/24/2014 10:12 AM, Srinivas Kandagatla wrote:
> Hi Pete,
>
> On 23/09/14 19:02, Peter Griffin wrote:
>> Hi Srini,
>>
>> On Mon, 22 Sep 2014, Srinivas Kandagatla wrote:
>>
>>> This patch fixes a compilation error while building with the
>>> random kernel configuration.
>>>
>>> drivers/media/rc/st_rc.c: In function 'st_rc_probe':
>>> drivers/media/rc/st_rc.c:281:2: error: implicit declaration of
>>> function 'reset_control_get' [-Werror=implicit-function-declaration]
>>> rc_dev->rstc = reset_control_get(dev, NULL);
>>>
>>> drivers/media/rc/st_rc.c:281:15: warning: assignment makes pointer
>>> from integer without a cast [enabled by default]
>>> rc_dev->rstc = reset_control_get(dev, NULL);
>>
>> Is managing the reset line actually optional though? I can't test atm
>> as I don't have
>> access to my board, but quite often if the IP's aren't taken out of
>> reset reads / writes
>> to the perhpiheral will hang the SoC.
>>
> Yes and No.
> AFAIK reset line is optional on SOCs like 7108, 7141.
> I think having the driver function without reset might is a value add in
> case we plan to reuse the mainline driver for these SOCs.
>
> On latest ARM SOCs with SBC the IRB IP is moved to SBC and held in reset.
> Am not sure, if the reset line is optional in next generation SOCs?
I don't know for next SoCs, but I think it makes sense to make it optional.
Regards,
Maxime
>
>> If managing the reset line isn't optional then I think the correct fix
>> is to add
>> depends on RESET_CONTROLLER in the kconfig.
> I agree.
> This would make the COMPILE_TEST less useful though.
>
>
> thanks,
> srini
>>
>> This will then do the right thing for randconfig builds as well.
>>
>> regards,
>>
>> Peter.
>>
>
> _______________________________________________
> Kernel mailing list
> Kernel@stlinux.com
> http://www.stlinux.com/mailman/listinfo/kernel
^ permalink raw reply [flat|nested] 22+ messages in thread
* [STLinux Kernel] [PATCH 1/3] media: st-rc: move to using reset_control_get_optional
@ 2014-09-24 8:37 ` Maxime Coquelin
0 siblings, 0 replies; 22+ messages in thread
From: Maxime Coquelin @ 2014-09-24 8:37 UTC (permalink / raw)
To: linux-arm-kernel
Hi Srini, Peter,
On 09/24/2014 10:12 AM, Srinivas Kandagatla wrote:
> Hi Pete,
>
> On 23/09/14 19:02, Peter Griffin wrote:
>> Hi Srini,
>>
>> On Mon, 22 Sep 2014, Srinivas Kandagatla wrote:
>>
>>> This patch fixes a compilation error while building with the
>>> random kernel configuration.
>>>
>>> drivers/media/rc/st_rc.c: In function 'st_rc_probe':
>>> drivers/media/rc/st_rc.c:281:2: error: implicit declaration of
>>> function 'reset_control_get' [-Werror=implicit-function-declaration]
>>> rc_dev->rstc = reset_control_get(dev, NULL);
>>>
>>> drivers/media/rc/st_rc.c:281:15: warning: assignment makes pointer
>>> from integer without a cast [enabled by default]
>>> rc_dev->rstc = reset_control_get(dev, NULL);
>>
>> Is managing the reset line actually optional though? I can't test atm
>> as I don't have
>> access to my board, but quite often if the IP's aren't taken out of
>> reset reads / writes
>> to the perhpiheral will hang the SoC.
>>
> Yes and No.
> AFAIK reset line is optional on SOCs like 7108, 7141.
> I think having the driver function without reset might is a value add in
> case we plan to reuse the mainline driver for these SOCs.
>
> On latest ARM SOCs with SBC the IRB IP is moved to SBC and held in reset.
> Am not sure, if the reset line is optional in next generation SOCs?
I don't know for next SoCs, but I think it makes sense to make it optional.
Regards,
Maxime
>
>> If managing the reset line isn't optional then I think the correct fix
>> is to add
>> depends on RESET_CONTROLLER in the kconfig.
> I agree.
> This would make the COMPILE_TEST less useful though.
>
>
> thanks,
> srini
>>
>> This will then do the right thing for randconfig builds as well.
>>
>> regards,
>>
>> Peter.
>>
>
> _______________________________________________
> Kernel mailing list
> Kernel at stlinux.com
> http://www.stlinux.com/mailman/listinfo/kernel
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [STLinux Kernel] [PATCH 1/3] media: st-rc: move to using reset_control_get_optional
2014-09-24 8:12 ` Srinivas Kandagatla
@ 2014-10-24 8:11 ` Peter Griffin
-1 siblings, 0 replies; 22+ messages in thread
From: Peter Griffin @ 2014-10-24 8:11 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: Mauro Carvalho Chehab, kernel, linux-kernel, linux-arm-kernel,
linux-media
Hi Srini,
Sorry seems I never replied to this.
> >>drivers/media/rc/st_rc.c:281:15: warning: assignment makes pointer
> >>from integer without a cast [enabled by default]
> >> rc_dev->rstc = reset_control_get(dev, NULL);
> >
> >Is managing the reset line actually optional though? I can't test atm as I don't have
> >access to my board, but quite often if the IP's aren't taken out of reset reads / writes
> >to the perhpiheral will hang the SoC.
> >
> Yes and No.
> AFAIK reset line is optional on SOCs like 7108, 7141.
> I think having the driver function without reset might is a value
> add in case we plan to reuse the mainline driver for these SOCs.
Yes that is a good point, for the series: -
Acked-by: Peter Griffin <peter.griffin@linaro.org>
regards,
Peter.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [STLinux Kernel] [PATCH 1/3] media: st-rc: move to using reset_control_get_optional
@ 2014-10-24 8:11 ` Peter Griffin
0 siblings, 0 replies; 22+ messages in thread
From: Peter Griffin @ 2014-10-24 8:11 UTC (permalink / raw)
To: linux-arm-kernel
Hi Srini,
Sorry seems I never replied to this.
> >>drivers/media/rc/st_rc.c:281:15: warning: assignment makes pointer
> >>from integer without a cast [enabled by default]
> >> rc_dev->rstc = reset_control_get(dev, NULL);
> >
> >Is managing the reset line actually optional though? I can't test atm as I don't have
> >access to my board, but quite often if the IP's aren't taken out of reset reads / writes
> >to the perhpiheral will hang the SoC.
> >
> Yes and No.
> AFAIK reset line is optional on SOCs like 7108, 7141.
> I think having the driver function without reset might is a value
> add in case we plan to reuse the mainline driver for these SOCs.
Yes that is a good point, for the series: -
Acked-by: Peter Griffin <peter.griffin@linaro.org>
regards,
Peter.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 2/3] media: st-rc: move pm ops setup out of conditional compilation.
2014-09-22 22:21 ` Srinivas Kandagatla
@ 2014-09-22 22:22 ` Srinivas Kandagatla
-1 siblings, 0 replies; 22+ messages in thread
From: Srinivas Kandagatla @ 2014-09-22 22:22 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Maxime Coquelin, Patrice Chotard, linux-arm-kernel, kernel,
linux-media, linux-kernel, Srinivas Kandagatla
This patch moves setting of pm_ops out of the CONFIG_PM_SLEEP condition.
Setting pm ops under CONFIG_PM_SLEEP does not make any sense.
This patch also remove unnecessary also remove CONFIG_PM condition for pm
member in st_rc_driver structure.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
drivers/media/rc/st_rc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/media/rc/st_rc.c b/drivers/media/rc/st_rc.c
index e0f1312..03bbb09 100644
--- a/drivers/media/rc/st_rc.c
+++ b/drivers/media/rc/st_rc.c
@@ -376,9 +376,10 @@ static int st_rc_resume(struct device *dev)
return 0;
}
-static SIMPLE_DEV_PM_OPS(st_rc_pm_ops, st_rc_suspend, st_rc_resume);
#endif
+static SIMPLE_DEV_PM_OPS(st_rc_pm_ops, st_rc_suspend, st_rc_resume);
+
#ifdef CONFIG_OF
static struct of_device_id st_rc_match[] = {
{ .compatible = "st,comms-irb", },
@@ -393,9 +394,7 @@ static struct platform_driver st_rc_driver = {
.name = IR_ST_NAME,
.owner = THIS_MODULE,
.of_match_table = of_match_ptr(st_rc_match),
-#ifdef CONFIG_PM
.pm = &st_rc_pm_ops,
-#endif
},
.probe = st_rc_probe,
.remove = st_rc_remove,
--
1.9.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PATCH 2/3] media: st-rc: move pm ops setup out of conditional compilation.
@ 2014-09-22 22:22 ` Srinivas Kandagatla
0 siblings, 0 replies; 22+ messages in thread
From: Srinivas Kandagatla @ 2014-09-22 22:22 UTC (permalink / raw)
To: linux-arm-kernel
This patch moves setting of pm_ops out of the CONFIG_PM_SLEEP condition.
Setting pm ops under CONFIG_PM_SLEEP does not make any sense.
This patch also remove unnecessary also remove CONFIG_PM condition for pm
member in st_rc_driver structure.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
drivers/media/rc/st_rc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/media/rc/st_rc.c b/drivers/media/rc/st_rc.c
index e0f1312..03bbb09 100644
--- a/drivers/media/rc/st_rc.c
+++ b/drivers/media/rc/st_rc.c
@@ -376,9 +376,10 @@ static int st_rc_resume(struct device *dev)
return 0;
}
-static SIMPLE_DEV_PM_OPS(st_rc_pm_ops, st_rc_suspend, st_rc_resume);
#endif
+static SIMPLE_DEV_PM_OPS(st_rc_pm_ops, st_rc_suspend, st_rc_resume);
+
#ifdef CONFIG_OF
static struct of_device_id st_rc_match[] = {
{ .compatible = "st,comms-irb", },
@@ -393,9 +394,7 @@ static struct platform_driver st_rc_driver = {
.name = IR_ST_NAME,
.owner = THIS_MODULE,
.of_match_table = of_match_ptr(st_rc_match),
-#ifdef CONFIG_PM
.pm = &st_rc_pm_ops,
-#endif
},
.probe = st_rc_probe,
.remove = st_rc_remove,
--
1.9.1
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH 3/3] media: st-rc: Remove .owner field for driver
2014-09-22 22:21 ` Srinivas Kandagatla
@ 2014-09-22 22:22 ` Srinivas Kandagatla
-1 siblings, 0 replies; 22+ messages in thread
From: Srinivas Kandagatla @ 2014-09-22 22:22 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Maxime Coquelin, Patrice Chotard, linux-arm-kernel, kernel,
linux-media, linux-kernel, Srinivas Kandagatla
There is no need to init .owner field.
Based on the patch from Peter Griffin <peter.griffin@linaro.org>
"mmc: remove .owner field for drivers using module_platform_driver"
This patch removes the superflous .owner field for drivers which
use the module_platform_driver API, as this is overriden in
platform_driver_register anyway."
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
drivers/media/rc/st_rc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/media/rc/st_rc.c b/drivers/media/rc/st_rc.c
index 03bbb09..e309441 100644
--- a/drivers/media/rc/st_rc.c
+++ b/drivers/media/rc/st_rc.c
@@ -392,7 +392,6 @@ MODULE_DEVICE_TABLE(of, st_rc_match);
static struct platform_driver st_rc_driver = {
.driver = {
.name = IR_ST_NAME,
- .owner = THIS_MODULE,
.of_match_table = of_match_ptr(st_rc_match),
.pm = &st_rc_pm_ops,
},
--
1.9.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PATCH 3/3] media: st-rc: Remove .owner field for driver
@ 2014-09-22 22:22 ` Srinivas Kandagatla
0 siblings, 0 replies; 22+ messages in thread
From: Srinivas Kandagatla @ 2014-09-22 22:22 UTC (permalink / raw)
To: linux-arm-kernel
There is no need to init .owner field.
Based on the patch from Peter Griffin <peter.griffin@linaro.org>
"mmc: remove .owner field for drivers using module_platform_driver"
This patch removes the superflous .owner field for drivers which
use the module_platform_driver API, as this is overriden in
platform_driver_register anyway."
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
drivers/media/rc/st_rc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/media/rc/st_rc.c b/drivers/media/rc/st_rc.c
index 03bbb09..e309441 100644
--- a/drivers/media/rc/st_rc.c
+++ b/drivers/media/rc/st_rc.c
@@ -392,7 +392,6 @@ MODULE_DEVICE_TABLE(of, st_rc_match);
static struct platform_driver st_rc_driver = {
.driver = {
.name = IR_ST_NAME,
- .owner = THIS_MODULE,
.of_match_table = of_match_ptr(st_rc_match),
.pm = &st_rc_pm_ops,
},
--
1.9.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* Re: [STLinux Kernel] [PATCH 3/3] media: st-rc: Remove .owner field for driver
2014-09-22 22:22 ` Srinivas Kandagatla
@ 2014-09-23 18:05 ` Peter Griffin
-1 siblings, 0 replies; 22+ messages in thread
From: Peter Griffin @ 2014-09-23 18:05 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: Mauro Carvalho Chehab, kernel, linux-kernel, linux-arm-kernel,
linux-media
On Mon, 22 Sep 2014, Srinivas Kandagatla wrote:
> There is no need to init .owner field.
>
> Based on the patch from Peter Griffin <peter.griffin@linaro.org>
> "mmc: remove .owner field for drivers using module_platform_driver"
>
> This patch removes the superflous .owner field for drivers which
> use the module_platform_driver API, as this is overriden in
> platform_driver_register anyway."
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Acked by:
Acked-by: Peter Griffin <peter.griffin@linaro.org>
^ permalink raw reply [flat|nested] 22+ messages in thread* [STLinux Kernel] [PATCH 3/3] media: st-rc: Remove .owner field for driver
@ 2014-09-23 18:05 ` Peter Griffin
0 siblings, 0 replies; 22+ messages in thread
From: Peter Griffin @ 2014-09-23 18:05 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 22 Sep 2014, Srinivas Kandagatla wrote:
> There is no need to init .owner field.
>
> Based on the patch from Peter Griffin <peter.griffin@linaro.org>
> "mmc: remove .owner field for drivers using module_platform_driver"
>
> This patch removes the superflous .owner field for drivers which
> use the module_platform_driver API, as this is overriden in
> platform_driver_register anyway."
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Acked by:
Acked-by: Peter Griffin <peter.griffin@linaro.org>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/3] media:st-rc: Misc fixes.
2014-09-22 22:21 ` Srinivas Kandagatla
@ 2014-09-22 22:39 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 22+ messages in thread
From: Mauro Carvalho Chehab @ 2014-09-22 22:39 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: Maxime Coquelin, Patrice Chotard, linux-arm-kernel, kernel,
linux-media, linux-kernel
Em Mon, 22 Sep 2014 23:21:41 +0100
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> escreveu:
> Hi Mauro,
>
> Thankyou for the "[media] enable COMPILE_TEST for media drivers" patch
> which picked up few things in st-rc driver in linux-next testing.
Anytime. Yeah, the idea is to let more people to test and check for
hidden issues there.
>
> Here is a few minor fixes to the driver, could you consider them for
> the next merge window.
Applied, thanks!
Btw, there are still lots of warnings there produced with smatch:
$ make ARCH=i386 C=1 CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y W=1 CF=-D__CHECK_ENDIAN__ M=drivers/media
drivers/media/rc/st_rc.c:107:38: warning: incorrect type in argument 1 (different address spaces)
drivers/media/rc/st_rc.c:107:38: expected void const volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:107:38: got void *
drivers/media/rc/st_rc.c:110:53: warning: incorrect type in argument 1 (different address spaces)
drivers/media/rc/st_rc.c:110:53: expected void const volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:110:53: got void *
drivers/media/rc/st_rc.c:116:54: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:116:54: expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:116:54: got void *
drivers/media/rc/st_rc.c:120:45: warning: incorrect type in argument 1 (different address spaces)
drivers/media/rc/st_rc.c:120:45: expected void const volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:120:45: got void *
drivers/media/rc/st_rc.c:121:43: warning: incorrect type in argument 1 (different address spaces)
drivers/media/rc/st_rc.c:121:43: expected void const volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:121:43: got void *
drivers/media/rc/st_rc.c:150:46: warning: incorrect type in argument 1 (different address spaces)
drivers/media/rc/st_rc.c:150:46: expected void const volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:150:46: got void *
drivers/media/rc/st_rc.c:153:42: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:153:42: expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:153:42: got void *
drivers/media/rc/st_rc.c:174:32: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:174:32: expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:174:32: got void *
drivers/media/rc/st_rc.c:177:48: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:177:48: expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:177:48: got void *
drivers/media/rc/st_rc.c:187:48: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:187:48: expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:187:48: got void *
drivers/media/rc/st_rc.c:204:42: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:204:42: expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:204:42: got void *
drivers/media/rc/st_rc.c:205:35: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:205:35: expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:205:35: got void *
drivers/media/rc/st_rc.c:215:35: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:215:35: expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:215:35: got void *
drivers/media/rc/st_rc.c:216:35: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:216:35: expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:216:35: got void *
drivers/media/rc/st_rc.c:269:22: warning: incorrect type in assignment (different address spaces)
drivers/media/rc/st_rc.c:269:22: expected void *base
drivers/media/rc/st_rc.c:269:22: got void [noderef] <asn:2>*
drivers/media/rc/st_rc.c:349:46: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:349:46: expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:349:46: got void *
drivers/media/rc/st_rc.c:350:46: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:350:46: expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:350:46: got void *
drivers/media/rc/st_rc.c:371:61: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:371:61: expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:371:61: got void *
drivers/media/rc/st_rc.c:372:54: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:372:54: expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:372:54: got void *
Regards,
Mauro
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 0/3] media:st-rc: Misc fixes.
@ 2014-09-22 22:39 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 22+ messages in thread
From: Mauro Carvalho Chehab @ 2014-09-22 22:39 UTC (permalink / raw)
To: linux-arm-kernel
Em Mon, 22 Sep 2014 23:21:41 +0100
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> escreveu:
> Hi Mauro,
>
> Thankyou for the "[media] enable COMPILE_TEST for media drivers" patch
> which picked up few things in st-rc driver in linux-next testing.
Anytime. Yeah, the idea is to let more people to test and check for
hidden issues there.
>
> Here is a few minor fixes to the driver, could you consider them for
> the next merge window.
Applied, thanks!
Btw, there are still lots of warnings there produced with smatch:
$ make ARCH=i386 C=1 CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y W=1 CF=-D__CHECK_ENDIAN__ M=drivers/media
drivers/media/rc/st_rc.c:107:38: warning: incorrect type in argument 1 (different address spaces)
drivers/media/rc/st_rc.c:107:38: expected void const volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:107:38: got void *
drivers/media/rc/st_rc.c:110:53: warning: incorrect type in argument 1 (different address spaces)
drivers/media/rc/st_rc.c:110:53: expected void const volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:110:53: got void *
drivers/media/rc/st_rc.c:116:54: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:116:54: expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:116:54: got void *
drivers/media/rc/st_rc.c:120:45: warning: incorrect type in argument 1 (different address spaces)
drivers/media/rc/st_rc.c:120:45: expected void const volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:120:45: got void *
drivers/media/rc/st_rc.c:121:43: warning: incorrect type in argument 1 (different address spaces)
drivers/media/rc/st_rc.c:121:43: expected void const volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:121:43: got void *
drivers/media/rc/st_rc.c:150:46: warning: incorrect type in argument 1 (different address spaces)
drivers/media/rc/st_rc.c:150:46: expected void const volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:150:46: got void *
drivers/media/rc/st_rc.c:153:42: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:153:42: expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:153:42: got void *
drivers/media/rc/st_rc.c:174:32: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:174:32: expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:174:32: got void *
drivers/media/rc/st_rc.c:177:48: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:177:48: expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:177:48: got void *
drivers/media/rc/st_rc.c:187:48: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:187:48: expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:187:48: got void *
drivers/media/rc/st_rc.c:204:42: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:204:42: expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:204:42: got void *
drivers/media/rc/st_rc.c:205:35: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:205:35: expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:205:35: got void *
drivers/media/rc/st_rc.c:215:35: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:215:35: expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:215:35: got void *
drivers/media/rc/st_rc.c:216:35: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:216:35: expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:216:35: got void *
drivers/media/rc/st_rc.c:269:22: warning: incorrect type in assignment (different address spaces)
drivers/media/rc/st_rc.c:269:22: expected void *base
drivers/media/rc/st_rc.c:269:22: got void [noderef] <asn:2>*
drivers/media/rc/st_rc.c:349:46: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:349:46: expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:349:46: got void *
drivers/media/rc/st_rc.c:350:46: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:350:46: expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:350:46: got void *
drivers/media/rc/st_rc.c:371:61: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:371:61: expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:371:61: got void *
drivers/media/rc/st_rc.c:372:54: warning: incorrect type in argument 2 (different address spaces)
drivers/media/rc/st_rc.c:372:54: expected void volatile [noderef] <asn:2>*addr
drivers/media/rc/st_rc.c:372:54: got void *
Regards,
Mauro
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/3] media:st-rc: Misc fixes.
2014-09-22 22:21 ` Srinivas Kandagatla
@ 2014-09-23 7:27 ` Maxime Coquelin
-1 siblings, 0 replies; 22+ messages in thread
From: Maxime Coquelin @ 2014-09-23 7:27 UTC (permalink / raw)
To: Srinivas Kandagatla, Mauro Carvalho Chehab
Cc: Patrice Chotard, linux-arm-kernel, kernel, linux-media, linux-kernel
Hi Srini,
Thanks for sending these fixes.
For the series, you can add my:
Acked-by: Maxime Coquelin <maxime.coquelin@st.com>
Regards,
Maxime
On 09/23/2014 12:21 AM, Srinivas Kandagatla wrote:
> Hi Mauro,
>
> Thankyou for the "[media] enable COMPILE_TEST for media drivers" patch
> which picked up few things in st-rc driver in linux-next testing.
>
> Here is a few minor fixes to the driver, could you consider them for
> the next merge window.
>
> Thanks,
> srini
>
> Srinivas Kandagatla (3):
> media: st-rc: move to using reset_control_get_optional
> media: st-rc: move pm ops setup out of conditional compilation.
> media: st-rc: Remove .owner field for driver
>
> drivers/media/rc/st_rc.c | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 0/3] media:st-rc: Misc fixes.
@ 2014-09-23 7:27 ` Maxime Coquelin
0 siblings, 0 replies; 22+ messages in thread
From: Maxime Coquelin @ 2014-09-23 7:27 UTC (permalink / raw)
To: linux-arm-kernel
Hi Srini,
Thanks for sending these fixes.
For the series, you can add my:
Acked-by: Maxime Coquelin <maxime.coquelin@st.com>
Regards,
Maxime
On 09/23/2014 12:21 AM, Srinivas Kandagatla wrote:
> Hi Mauro,
>
> Thankyou for the "[media] enable COMPILE_TEST for media drivers" patch
> which picked up few things in st-rc driver in linux-next testing.
>
> Here is a few minor fixes to the driver, could you consider them for
> the next merge window.
>
> Thanks,
> srini
>
> Srinivas Kandagatla (3):
> media: st-rc: move to using reset_control_get_optional
> media: st-rc: move pm ops setup out of conditional compilation.
> media: st-rc: Remove .owner field for driver
>
> drivers/media/rc/st_rc.c | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
^ permalink raw reply [flat|nested] 22+ messages in thread