[PATCH net-next 1/2] net: davinci_mdio: don't request io address range

[PATCH net-next 1/2] net: davinci_mdio: don't request io address range

[Murali Karicheri]

From: Grygorii Strashko <grygorii.strashko@ti.com>

Historically Davinci MDIO driver was  created with assumption that
MDIO is standalone device, but for Keystone 2 it's a part
of NETCP module and now NETCP driver requests IO range which
includes MDIO IO range too. This causes Keystone 2 networking stack
failure during the boot.

"netcp-1.0 2620110.netcp: Probe of module(netcp-gbe) failed with -16"

Hence, don't request io address range from Davinci MDIO driver and
just remap it.

Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
---
 drivers/net/ethernet/ti/davinci_mdio.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
index 98655b4..b13ec82 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -371,7 +371,7 @@ static int davinci_mdio_probe(struct platform_device *pdev)
 	spin_lock_init(&data->lock);
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	data->regs = devm_ioremap_resource(dev, res);
+	data->regs = devm_ioremap_nocache(dev, res->start, resource_size(res));
 	if (IS_ERR(data->regs)) {
 		ret = PTR_ERR(data->regs);
 		goto bail_out;
-- 
1.7.9.5

[PATCH net-next 2/2] net: netcp: select davinci_mdio driver by default

[Murali Karicheri]

Keystone netcp driver re-uses davinci mdio driver. So enable it
by default for keystone netcp driver.

Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
---
 drivers/net/ethernet/ti/Kconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index 3bc992c..945a221 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -88,6 +88,7 @@ config TI_CPTS
 config TI_KEYSTONE_NETCP
 	tristate "TI Keystone NETCP Core Support"
 	select TI_CPSW_ALE
+	select TI_DAVINCI_MDIO
 	depends on OF
 	depends on KEYSTONE_NAVIGATOR_DMA && KEYSTONE_NAVIGATOR_QMSS
 	---help---
-- 
1.7.9.5

Re: [PATCH net-next 2/2] net: netcp: select davinci_mdio driver by default

[Tony Lindgren]

* Murali Karicheri <m-karicheri2@ti.com> [150224 13:31]:
> Keystone netcp driver re-uses davinci mdio driver. So enable it
> by default for keystone netcp driver.
> 
> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
> ---
>  drivers/net/ethernet/ti/Kconfig |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
> index 3bc992c..945a221 100644
> --- a/drivers/net/ethernet/ti/Kconfig
> +++ b/drivers/net/ethernet/ti/Kconfig
> @@ -88,6 +88,7 @@ config TI_CPTS
>  config TI_KEYSTONE_NETCP
>  	tristate "TI Keystone NETCP Core Support"
>  	select TI_CPSW_ALE
> +	select TI_DAVINCI_MDIO
>  	depends on OF
>  	depends on KEYSTONE_NAVIGATOR_DMA && KEYSTONE_NAVIGATOR_QMSS
>  	---help---

These options should be silent Kconfig options if we're selecting
them. Or else you should use depends on instead.

In general using select for driver modules will eventually lead into
randconfig build failures as things change.

Regards,

Tony

Re: [PATCH net-next 2/2] net: netcp: select davinci_mdio driver by default

[Murali Karicheri]

On 02/27/2015 11:29 AM, Tony Lindgren wrote:
> * Murali Karicheri<m-karicheri2@ti.com>  [150224 13:31]:
>> Keystone netcp driver re-uses davinci mdio driver. So enable it
>> by default for keystone netcp driver.
>>
>> Signed-off-by: Murali Karicheri<m-karicheri2@ti.com>
>> ---
>>   drivers/net/ethernet/ti/Kconfig |    1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
>> index 3bc992c..945a221 100644
>> --- a/drivers/net/ethernet/ti/Kconfig
>> +++ b/drivers/net/ethernet/ti/Kconfig
>> @@ -88,6 +88,7 @@ config TI_CPTS
>>   config TI_KEYSTONE_NETCP
>>   	tristate "TI Keystone NETCP Core Support"
>>   	select TI_CPSW_ALE
>> +	select TI_DAVINCI_MDIO
>>   	depends on OF
>>   	depends on KEYSTONE_NAVIGATOR_DMA&&  KEYSTONE_NAVIGATOR_QMSS
>>   	---help---
>
> These options should be silent Kconfig options if we're selecting
> them. Or else you should use depends on instead.
>
Just followed the existing implementation as it made sense.

config TI_DAVINCI_EMAC
	tristate "TI DaVinci EMAC Support"
	depends on ARM && ( ARCH_DAVINCI || ARCH_OMAP3 )
	select TI_DAVINCI_MDIO
	select TI_DAVINCI_CPDMA
	select PHYLIB
	---help---
	  This driver supports TI's DaVinci Ethernet .

	  To compile this driver as a module, choose M here: the module
	  will be called davinci_emac_driver.  This is recommended.

config TI_CPSW
	tristate "TI CPSW Switch Support"
	depends on ARCH_DAVINCI || ARCH_OMAP2PLUS
	select TI_DAVINCI_CPDMA
	select TI_DAVINCI_MDIO
	select TI_CPSW_PHY_SEL
	select TI_CPSW_ALE
	select MFD_SYSCON
	select REGMAP
	---help---
	  This driver supports TI's CPSW Ethernet Switch.

	  To compile this driver as a module, choose M here: the module
	  will be called cpsw.

Why it has to be silent options? NetCP driver would require DAVINCI_MDIO 
driver to function. So "select" make sense to me instead of "depend". 
How do you think depend can be used here?

Murali

> In general using select for driver modules will eventually lead into
> randconfig build failures as things change.
>
> Regards,
>
> Tony


-- 
Murali Karicheri
Linux Kernel, Texas Instruments

Re: [PATCH net-next 2/2] net: netcp: select davinci_mdio driver by default

[Tony Lindgren]

* Murali Karicheri <m-karicheri2@ti.com> [150227 12:59]:
> On 02/27/2015 11:29 AM, Tony Lindgren wrote:
> >* Murali Karicheri<m-karicheri2@ti.com>  [150224 13:31]:
> >>Keystone netcp driver re-uses davinci mdio driver. So enable it
> >>by default for keystone netcp driver.
> >>
> >>Signed-off-by: Murali Karicheri<m-karicheri2@ti.com>
> >>---
> >>  drivers/net/ethernet/ti/Kconfig |    1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >>diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
> >>index 3bc992c..945a221 100644
> >>--- a/drivers/net/ethernet/ti/Kconfig
> >>+++ b/drivers/net/ethernet/ti/Kconfig
> >>@@ -88,6 +88,7 @@ config TI_CPTS
> >>  config TI_KEYSTONE_NETCP
> >>  	tristate "TI Keystone NETCP Core Support"
> >>  	select TI_CPSW_ALE
> >>+	select TI_DAVINCI_MDIO
> >>  	depends on OF
> >>  	depends on KEYSTONE_NAVIGATOR_DMA&&  KEYSTONE_NAVIGATOR_QMSS
> >>  	---help---
> >
> >These options should be silent Kconfig options if we're selecting
> >them. Or else you should use depends on instead.
> >
> Just followed the existing implementation as it made sense.
> 
> config TI_DAVINCI_EMAC
> 	tristate "TI DaVinci EMAC Support"
> 	depends on ARM && ( ARCH_DAVINCI || ARCH_OMAP3 )
> 	select TI_DAVINCI_MDIO
> 	select TI_DAVINCI_CPDMA
> 	select PHYLIB
> 	---help---
> 	  This driver supports TI's DaVinci Ethernet .
> 
> 	  To compile this driver as a module, choose M here: the module
> 	  will be called davinci_emac_driver.  This is recommended.
> 
> config TI_CPSW
> 	tristate "TI CPSW Switch Support"
> 	depends on ARCH_DAVINCI || ARCH_OMAP2PLUS
> 	select TI_DAVINCI_CPDMA
> 	select TI_DAVINCI_MDIO
> 	select TI_CPSW_PHY_SEL
> 	select TI_CPSW_ALE
> 	select MFD_SYSCON
> 	select REGMAP
> 	---help---
> 	  This driver supports TI's CPSW Ethernet Switch.
> 
> 	  To compile this driver as a module, choose M here: the module
> 	  will be called cpsw.
> 
> Why it has to be silent options?

Because we are now force selecting items that may have other
dependencies later on that will not be satisfied. That causes
all kinds of make randconfig build errors.

> NetCP driver would require DAVINCI_MDIO driver to function.
> So "select" make sense to me instead of "depend". How do
> you think depend can be used here?

In that case you'd have to have things the other way around:

config TI_CPSW
	tristate "TI CPSW Switch Support"
	depends on ARCH_DAVINCI || ARCH_OMAP2PLUS || \
		TI_DAVINCI_CPDMA || TI_DAVINCI_MDIO || \
		TI_CPSW_PHY_SEL || TI_CPSW_ALE || \
		MFD_SYSCON || REGMAP

But I think it's best to make these options silent Kconfig
options so the consumer drivers can select whatever components
they need to use. There should not be any need for users to
have to select these options.

Regards,

Tony 

Re: [PATCH net-next 2/2] net: netcp: select davinci_mdio driver by default

[Murali Karicheri]

On 03/02/2015 11:11 AM, Tony Lindgren wrote:
> * Murali Karicheri<m-karicheri2@ti.com>  [150227 12:59]:
>> On 02/27/2015 11:29 AM, Tony Lindgren wrote:
>>> * Murali Karicheri<m-karicheri2@ti.com>   [150224 13:31]:
>>>> Keystone netcp driver re-uses davinci mdio driver. So enable it
>>>> by default for keystone netcp driver.
>>>>
>>>> Signed-off-by: Murali Karicheri<m-karicheri2@ti.com>
>>>> ---
>>>>   drivers/net/ethernet/ti/Kconfig |    1 +
>>>>   1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
>>>> index 3bc992c..945a221 100644
>>>> --- a/drivers/net/ethernet/ti/Kconfig
>>>> +++ b/drivers/net/ethernet/ti/Kconfig
>>>> @@ -88,6 +88,7 @@ config TI_CPTS
>>>>   config TI_KEYSTONE_NETCP
>>>>   	tristate "TI Keystone NETCP Core Support"
>>>>   	select TI_CPSW_ALE
>>>> +	select TI_DAVINCI_MDIO
>>>>   	depends on OF
>>>>   	depends on KEYSTONE_NAVIGATOR_DMA&&   KEYSTONE_NAVIGATOR_QMSS
>>>>   	---help---
>>>
>>> These options should be silent Kconfig options if we're selecting
>>> them. Or else you should use depends on instead.
>>>
>> Just followed the existing implementation as it made sense.
>>
>> config TI_DAVINCI_EMAC
>> 	tristate "TI DaVinci EMAC Support"
>> 	depends on ARM&&  ( ARCH_DAVINCI || ARCH_OMAP3 )
>> 	select TI_DAVINCI_MDIO
>> 	select TI_DAVINCI_CPDMA
>> 	select PHYLIB
>> 	---help---
>> 	  This driver supports TI's DaVinci Ethernet .
>>
>> 	  To compile this driver as a module, choose M here: the module
>> 	  will be called davinci_emac_driver.  This is recommended.
>>
>> config TI_CPSW
>> 	tristate "TI CPSW Switch Support"
>> 	depends on ARCH_DAVINCI || ARCH_OMAP2PLUS
>> 	select TI_DAVINCI_CPDMA
>> 	select TI_DAVINCI_MDIO
>> 	select TI_CPSW_PHY_SEL
>> 	select TI_CPSW_ALE
>> 	select MFD_SYSCON
>> 	select REGMAP
>> 	---help---
>> 	  This driver supports TI's CPSW Ethernet Switch.
>>
>> 	  To compile this driver as a module, choose M here: the module
>> 	  will be called cpsw.
>>
>> Why it has to be silent options?
>
> Because we are now force selecting items that may have other
> dependencies later on that will not be satisfied. That causes
> all kinds of make randconfig build errors.
My mistake.  I didn't ask you what is your definition of a silent 
option? An option not selected by any other option? Or an option for 
which default value not defined? Can you clarify this so that I can make 
sense of your comment? I checked Documentation/kbuild/kconfig.txt as 
well as Documentation/kbuild/kconfig-language.txt for defintion, but 
can't find it.

Howeve, I read the warning about using "select" in the above document 
since it blindly select the option without checking dependencies. So 
AFAIK, select becomes an issue if the config option is not the leaf 
option of the config tree as the dependency checking is not in place and 
can cause issues. In this case it is safe as DAVINCI_MDIO is a leaf 
option and only selects PHYLIB which dependents on NETDEVICES and we 
know this is true for NETCP devices. So select is just fine here.

>
>> NetCP driver would require DAVINCI_MDIO driver to function.
>> So "select" make sense to me instead of "depend". How do
>> you think depend can be used here?
>
> In that case you'd have to have things the other way around:
>
> config TI_CPSW
> 	tristate "TI CPSW Switch Support"
> 	depends on ARCH_DAVINCI || ARCH_OMAP2PLUS || \
> 		TI_DAVINCI_CPDMA || TI_DAVINCI_MDIO || \
> 		TI_CPSW_PHY_SEL || TI_CPSW_ALE || \
> 		MFD_SYSCON || REGMAP
>
> But I think it's best to make these options silent Kconfig
> options so the consumer drivers can select whatever components
> they need to use. There should not be any need for users to
> have to select these options.

Users don't select any option other than NETCP. User may not need to 
know what are all the hardware drivers required to enable NETCP device 
on the platform and it is best to describe that through Kconfig instead 
of putting the burden on the user. Though select has limitations, AFAIK 
it doesn't apply here.

Thanks

Murali
>
> Regards,
>
> Tony


-- 
Murali Karicheri
Linux Kernel, Texas Instruments

Re: [PATCH net-next 2/2] net: netcp: select davinci_mdio driver by default

[Tony Lindgren]

* Murali Karicheri <m-karicheri2@ti.com> [150302 13:49]:
> On 03/02/2015 11:11 AM, Tony Lindgren wrote:
> >
> >Because we are now force selecting items that may have other
> >dependencies later on that will not be satisfied. That causes
> >all kinds of make randconfig build errors.
> >
> My mistake.  I didn't ask you what is your definition of a silent option? An
> option not selected by any other option? Or an option for which default
> value not defined? Can you clarify this so that I can make sense of your
> comment? I checked Documentation/kbuild/kconfig.txt as well as
> Documentation/kbuild/kconfig-language.txt for defintion, but can't find it.
> 
> Howeve, I read the warning about using "select" in the above document since
> it blindly select the option without checking dependencies. So AFAIK, select
> becomes an issue if the config option is not the leaf option of the config
> tree as the dependency checking is not in place and can cause issues. In
> this case it is safe as DAVINCI_MDIO is a leaf option and only selects
> PHYLIB which dependents on NETDEVICES and we know this is true for NETCP
> devices. So select is just fine here.

OK I think you're right that in this case it won't cause issues.

But if these cpsw components are never selectable by the user for
any real use case, then you may want to make them silent Kconfig
options:

config TI_DAVINCI_MDIO
	bool
	select PHYLIB

config TI_DAVINCI_CPDMA
	bool

config TI_CPSW_PHY_SEL
	bool

config TI_CPSW_ALE
	bool
...

Regards,

Tony

Re: [PATCH net-next 2/2] net: netcp: select davinci_mdio driver by default

[Murali Karicheri]

On 03/02/2015 07:04 PM, Tony Lindgren wrote:
> * Murali Karicheri<m-karicheri2@ti.com>  [150302 13:49]:
>> On 03/02/2015 11:11 AM, Tony Lindgren wrote:
>>>
>>> Because we are now force selecting items that may have other
>>> dependencies later on that will not be satisfied. That causes
>>> all kinds of make randconfig build errors.
>>>
>> My mistake.  I didn't ask you what is your definition of a silent option? An
>> option not selected by any other option? Or an option for which default
>> value not defined? Can you clarify this so that I can make sense of your
>> comment? I checked Documentation/kbuild/kconfig.txt as well as
>> Documentation/kbuild/kconfig-language.txt for defintion, but can't find it.
>>
>> Howeve, I read the warning about using "select" in the above document since
>> it blindly select the option without checking dependencies. So AFAIK, select
>> becomes an issue if the config option is not the leaf option of the config
>> tree as the dependency checking is not in place and can cause issues. In
>> this case it is safe as DAVINCI_MDIO is a leaf option and only selects
>> PHYLIB which dependents on NETDEVICES and we know this is true for NETCP
>> devices. So select is just fine here.
>
> OK I think you're right that in this case it won't cause issues.
>
> But if these cpsw components are never selectable by the user for
> any real use case, then you may want to make them silent Kconfig
> options:
>
> config TI_DAVINCI_MDIO
> 	bool
> 	select PHYLIB
>
> config TI_DAVINCI_CPDMA
> 	bool
>
> config TI_CPSW_PHY_SEL
> 	bool
>
> config TI_CPSW_ALE
> 	bool
> ...
This clean up can be a separate patch in the future and I can post 
something. But would require help from the affacted platform owners to 
test the patch. For now, I will keep the patch for my next revision.

Murali
>
> Regards,
>
> Tony


-- 
Murali Karicheri
Linux Kernel, Texas Instruments

Re: [PATCH net-next 1/2] net: davinci_mdio: don't request io address range

[Lad, Prabhakar]

On Tue, Feb 24, 2015 at 9:27 PM, Murali Karicheri <m-karicheri2@ti.com> wrote:
> From: Grygorii Strashko <grygorii.strashko@ti.com>
>
> Historically Davinci MDIO driver was  created with assumption that
> MDIO is standalone device, but for Keystone 2 it's a part
> of NETCP module and now NETCP driver requests IO range which
> includes MDIO IO range too. This causes Keystone 2 networking stack
> failure during the boot.
>
> "netcp-1.0 2620110.netcp: Probe of module(netcp-gbe) failed with -16"
>
> Hence, don't request io address range from Davinci MDIO driver and
> just remap it.
>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>

Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>

Cheers,
--Prabhakar Lad

> ---
>  drivers/net/ethernet/ti/davinci_mdio.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
> index 98655b4..b13ec82 100644
> --- a/drivers/net/ethernet/ti/davinci_mdio.c
> +++ b/drivers/net/ethernet/ti/davinci_mdio.c
> @@ -371,7 +371,7 @@ static int davinci_mdio_probe(struct platform_device *pdev)
>         spin_lock_init(&data->lock);
>
>         res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> -       data->regs = devm_ioremap_resource(dev, res);
> +       data->regs = devm_ioremap_nocache(dev, res->start, resource_size(res));
>         if (IS_ERR(data->regs)) {
>                 ret = PTR_ERR(data->regs);
>                 goto bail_out;
> --
> 1.7.9.5
>

Re: [PATCH net-next 1/2] net: davinci_mdio: don't request io address range

[Tony Lindgren]

* Murali Karicheri <m-karicheri2@ti.com> [150224 13:32]:
> From: Grygorii Strashko <grygorii.strashko@ti.com>
> 
> Historically Davinci MDIO driver was  created with assumption that
> MDIO is standalone device, but for Keystone 2 it's a part
> of NETCP module and now NETCP driver requests IO range which
> includes MDIO IO range too. This causes Keystone 2 networking stack
> failure during the boot.
> 
> "netcp-1.0 2620110.netcp: Probe of module(netcp-gbe) failed with -16"
> 
> Hence, don't request io address range from Davinci MDIO driver and
> just remap it.

Best to fix this up properly so you don't have overlapping resources.
You probably want to have the whole hardware driver block defined
in the dts file as a single entry, and then have the modules within
that hardware block use the dt ranges property. This allows you to
do standard Linux drivers without any extra hacks.

Sounds like this following untested imaginary example should do
the trick:

mac: ethernet@deadbeef {
	compatible = "ti,cpsw", "simple-bus";
	reg = <0xdeadbeef 0x1000>;
	ranges = <0 0xdeadbeef 0x2000>;
	...

	davinci_mdio: mdio@1000 {
		reg = <0x1000 0x100>;
		...
	};
};

That allows you to get rid of all the existing code for dealing
with the chilren with for_each_child_of_node(node, slave_node)
in cpsw_probe_dt() as that all happens automatically for you and
does not cause problems with modules being moved around.

Regards,

Tony

Re: [PATCH net-next 1/2] net: davinci_mdio: don't request io address range

[Murali Karicheri]

Tony,

On 02/27/2015 11:51 AM, Tony Lindgren wrote:
> * Murali Karicheri<m-karicheri2@ti.com>  [150224 13:32]:
>> From: Grygorii Strashko<grygorii.strashko@ti.com>
>>
>> Historically Davinci MDIO driver was  created with assumption that
>> MDIO is standalone device, but for Keystone 2 it's a part
>> of NETCP module and now NETCP driver requests IO range which
>> includes MDIO IO range too. This causes Keystone 2 networking stack
>> failure during the boot.
>>
>> "netcp-1.0 2620110.netcp: Probe of module(netcp-gbe) failed with -16"
>>
>> Hence, don't request io address range from Davinci MDIO driver and
>> just remap it.
>
> Best to fix this up properly so you don't have overlapping resources.
> You probably want to have the whole hardware driver block defined
> in the dts file as a single entry, and then have the modules within
> that hardware block use the dt ranges property. This allows you to
> do standard Linux drivers without any extra hacks.
>
> Sounds like this following untested imaginary example should do
> the trick:
>
> mac: ethernet@deadbeef {
> 	compatible = "ti,cpsw", "simple-bus";
> 	reg =<0xdeadbeef 0x1000>;
> 	ranges =<0 0xdeadbeef 0x2000>;
> 	...
>
> 	davinci_mdio: mdio@1000 {
> 		reg =<0x1000 0x100>;
> 		...
> 	};
> };
>
> That allows you to get rid of all the existing code for dealing
> with the chilren with for_each_child_of_node(node, slave_node)
> in cpsw_probe_dt() as that all happens automatically for you and
> does not cause problems with modules being moved around.

This is not for CPSW driver. I am working to add the support for NetCP.
NetCP driver depends on DaVinci MDIO driver to talk to the Phy. So this
can be outside the NetCP device node. I will rework the NetCP driver to 
map only it's register space and let MDIO manage the mapping of its 
register region. I plan to use ranges to define the NetCP address space 
and use reg to refer to individual module reg spaces (Packet 
Accelerator, Ethenet sub system and security accelerator). This way MDIO 
can have its own register space and will not collide with the address 
NetCP driver maps. My v1 will implement this.

Murali
>
> Regards,
>
> Tony


-- 
Murali Karicheri
Linux Kernel, Texas Instruments