On Friday 23 August 2013 10:16 AM, Daniel Mack wrote:
> In order to support features that are specific to the AM335x IP, we have
> to add hardware types and another compatible string.
>
> Signed-off-by: Daniel Mack <zonque@xxxxxxxxx>
> ---
> Documentation/devicetree/bindings/net/cpsw.txt | 3 ++-
> drivers/net/ethernet/ti/cpsw.c | 32 ++++++++++++++++++++------
> drivers/net/ethernet/ti/cpsw.h | 1 +
> 3 files changed, 28 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/cpsw.txt b/Documentation/devicetree/bindings/net/cpsw.txt
> index 4e5ca54..b717458 100644
> --- a/Documentation/devicetree/bindings/net/cpsw.txt
> +++ b/Documentation/devicetree/bindings/net/cpsw.txt
> @@ -2,7 +2,8 @@ TI SoC Ethernet Switch Controller Device Tree Bindings
> ------------------------------------------------------
>
> Required properties:
> -- compatible : Should be "ti,cpsw"
> +- compatible : Should be "ti,cpsw" for generic cpsw support, or
> + "ti,am3352-cpsw" for AM3352 SoCs
> - reg : physical base address and size of the cpsw
> registers map.
> An optional third memory region can be supplied if
> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
> index 7a25ff4..73c44cb6 100644
> --- a/drivers/net/ethernet/ti/cpsw.c
> +++ b/drivers/net/ethernet/ti/cpsw.c
> @@ -155,6 +155,11 @@ do { \
> ((priv->data.dual_emac) ? priv->emac_port : \
> priv->data.active_slave)
>
> +enum {
> + CPSW_TYPE_GENERIC,
> + CPSW_TYPE_AM33XX
> +};
> +
> static int debug_level;
> module_param(debug_level, int, 0);
> MODULE_PARM_DESC(debug_level, "cpsw debug level (NETIF_MSG bits)");
> @@ -1692,17 +1697,36 @@ static void cpsw_slave_init(struct cpsw_slave *slave, struct cpsw_priv *priv,
> slave->port_vlan = data->dual_emac_res_vlan;
> }
>
> +static const struct of_device_id cpsw_of_mtable[] = {
> + {
> + .compatible = "ti,am3352-cpsw",
I didn't notice this earlier, but can't you use the IP version
as a compatible instead of using a SOC name. Whats really SOC specific
on this IP ? Sorry i have missed any earlier discussion on this but
this approach doesn't seem good. Its like adding SOC checks in the
driver subsystem.
Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
