All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net, lethal@linux-sh.org,
	linux-sh@vger.kernel.org
Subject: Re: [PATCH 2/2] sh_eth: remove 'register_type' field from 'struct sh_eth_plat_data'
Date: Tue, 20 Aug 2013 14:27:33 +0000	[thread overview]
Message-ID: <52137CD5.1040902@cogentembedded.com> (raw)
In-Reply-To: <3069255.T0Cvttgz9W@avalon>

Hello.

On 20-08-2013 14:51, Laurent Pinchart wrote:

>> Now that the 'register_type' field of the 'sh_eth' driver's platform data is
>> not used by the driver anymore, it's time to remove it and  its
>> initializers from the SH platform code. Also  move *enum* declaring values
>> for this  field from <linux/sh_eth.h>  to  the  local driver's  header file
>> as they're only needed by the driver itself  now...

>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

>> ---
>>   arch/arm/mach-shmobile/board-armadillo800eva.c |    1 -
>>   arch/arm/mach-shmobile/board-bockw.c           |    1 -
>>   arch/sh/boards/board-espt.c                    |    1 -
>>   arch/sh/boards/board-sh7757lcr.c               |    4 ----
>>   arch/sh/boards/mach-ecovec24/setup.c           |    1 -
>>   arch/sh/boards/mach-se/7724/setup.c            |    1 -
>>   arch/sh/boards/mach-sh7763rdp/setup.c          |    1 -
>>   arch/sh/kernel/cpu/sh2/setup-sh7619.c          |    1 -
>>   drivers/net/ethernet/renesas/sh_eth.h          |    7 +++++++
>>   include/linux/sh_eth.h                         |    7 -------
>>   10 files changed, 7 insertions(+), 18 deletions(-)

> [snip]

>> Index: net-next/drivers/net/ethernet/renesas/sh_eth.h
>> =================================>> --- net-next.orig/drivers/net/ethernet/renesas/sh_eth.h
>> +++ net-next/drivers/net/ethernet/renesas/sh_eth.h
>> @@ -157,6 +157,13 @@ enum {
>>   	SH_ETH_MAX_REGISTER_OFFSET,
>>   };
>>
>> +enum {
>> +	SH_ETH_REG_GIGABIT,
>> +	SH_ETH_REG_FAST_RCAR,
>> +	SH_ETH_REG_FAST_SH4,
>> +	SH_ETH_REG_FAST_SH3_SH2
>> +};
>> +

> Would it make sense to move this change and the one below to a separate patch
> to be merged through the net tree ?

    I'm intending to merge these patches thru the net-next tree.

>>   /* Driver's parameters */
>>   #if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE)
>>   #define SH4_SKB_RX_ALIGN	32
>> Index: net-next/include/linux/sh_eth.h
>> =================================>> --- net-next.orig/include/linux/sh_eth.h
>> +++ net-next/include/linux/sh_eth.h
>> @@ -5,17 +5,10 @@
>>   #include <linux/if_ether.h>
>>
>>   enum {EDMAC_LITTLE_ENDIAN, EDMAC_BIG_ENDIAN};
>> -enum {
>> -	SH_ETH_REG_GIGABIT,
>> -	SH_ETH_REG_FAST_RCAR,
>> -	SH_ETH_REG_FAST_SH4,
>> -	SH_ETH_REG_FAST_SH3_SH2
>> -};
>>
>>   struct sh_eth_plat_data {
>>   	int phy;
>>   	int edmac_endian;

> Wouldn't it make sense to move the edmac_endian field to sh_eth_cpu_data as
> well ?

    No, it depends on the SoC endianness which is determined by power-on pin 
strapping -- which is board specific.

WBR, Sergei


WARNING: multiple messages have this Message-ID (diff)
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net, lethal@linux-sh.org,
	linux-sh@vger.kernel.org
Subject: Re: [PATCH 2/2] sh_eth: remove 'register_type' field from 'struct sh_eth_plat_data'
Date: Tue, 20 Aug 2013 18:27:33 +0400	[thread overview]
Message-ID: <52137CD5.1040902@cogentembedded.com> (raw)
In-Reply-To: <3069255.T0Cvttgz9W@avalon>

Hello.

On 20-08-2013 14:51, Laurent Pinchart wrote:

>> Now that the 'register_type' field of the 'sh_eth' driver's platform data is
>> not used by the driver anymore, it's time to remove it and  its
>> initializers from the SH platform code. Also  move *enum* declaring values
>> for this  field from <linux/sh_eth.h>  to  the  local driver's  header file
>> as they're only needed by the driver itself  now...

>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

>> ---
>>   arch/arm/mach-shmobile/board-armadillo800eva.c |    1 -
>>   arch/arm/mach-shmobile/board-bockw.c           |    1 -
>>   arch/sh/boards/board-espt.c                    |    1 -
>>   arch/sh/boards/board-sh7757lcr.c               |    4 ----
>>   arch/sh/boards/mach-ecovec24/setup.c           |    1 -
>>   arch/sh/boards/mach-se/7724/setup.c            |    1 -
>>   arch/sh/boards/mach-sh7763rdp/setup.c          |    1 -
>>   arch/sh/kernel/cpu/sh2/setup-sh7619.c          |    1 -
>>   drivers/net/ethernet/renesas/sh_eth.h          |    7 +++++++
>>   include/linux/sh_eth.h                         |    7 -------
>>   10 files changed, 7 insertions(+), 18 deletions(-)

> [snip]

>> Index: net-next/drivers/net/ethernet/renesas/sh_eth.h
>> ===================================================================
>> --- net-next.orig/drivers/net/ethernet/renesas/sh_eth.h
>> +++ net-next/drivers/net/ethernet/renesas/sh_eth.h
>> @@ -157,6 +157,13 @@ enum {
>>   	SH_ETH_MAX_REGISTER_OFFSET,
>>   };
>>
>> +enum {
>> +	SH_ETH_REG_GIGABIT,
>> +	SH_ETH_REG_FAST_RCAR,
>> +	SH_ETH_REG_FAST_SH4,
>> +	SH_ETH_REG_FAST_SH3_SH2
>> +};
>> +

> Would it make sense to move this change and the one below to a separate patch
> to be merged through the net tree ?

    I'm intending to merge these patches thru the net-next tree.

>>   /* Driver's parameters */
>>   #if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE)
>>   #define SH4_SKB_RX_ALIGN	32
>> Index: net-next/include/linux/sh_eth.h
>> ===================================================================
>> --- net-next.orig/include/linux/sh_eth.h
>> +++ net-next/include/linux/sh_eth.h
>> @@ -5,17 +5,10 @@
>>   #include <linux/if_ether.h>
>>
>>   enum {EDMAC_LITTLE_ENDIAN, EDMAC_BIG_ENDIAN};
>> -enum {
>> -	SH_ETH_REG_GIGABIT,
>> -	SH_ETH_REG_FAST_RCAR,
>> -	SH_ETH_REG_FAST_SH4,
>> -	SH_ETH_REG_FAST_SH3_SH2
>> -};
>>
>>   struct sh_eth_plat_data {
>>   	int phy;
>>   	int edmac_endian;

> Wouldn't it make sense to move the edmac_endian field to sh_eth_cpu_data as
> well ?

    No, it depends on the SoC endianness which is determined by power-on pin 
strapping -- which is board specific.

WBR, Sergei

  reply	other threads:[~2013-08-20 14:27 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-17 23:08 [PATCH 0/2] sh_eth: don't get the register layout from platform data Sergei Shtylyov
2013-08-17 23:08 ` Sergei Shtylyov
2013-08-17 23:11 ` [PATCH 1/2] sh_eth: get register layout from 'struct sh_eth_cpu_data' Sergei Shtylyov
2013-08-17 23:11   ` Sergei Shtylyov
2013-08-21  0:05   ` David Miller
2013-08-21  0:05     ` David Miller
2013-08-17 23:13 ` [PATCH 2/2] sh_eth: remove 'register_type' field from 'struct sh_eth_plat_data' Sergei Shtylyov
2013-08-17 23:13   ` Sergei Shtylyov
2013-08-20 10:51   ` Laurent Pinchart
2013-08-20 10:51     ` Laurent Pinchart
2013-08-20 14:27     ` Sergei Shtylyov [this message]
2013-08-20 14:27       ` Sergei Shtylyov
2013-08-20 22:09       ` Sergei Shtylyov
2013-08-20 22:09         ` Sergei Shtylyov
2013-08-20 22:50         ` Laurent Pinchart
2013-08-20 22:50           ` Laurent Pinchart
2013-08-20 23:01           ` Sergei Shtylyov
2013-08-20 23:01             ` Sergei Shtylyov
2013-08-21  0:39             ` Laurent Pinchart
2013-08-21  0:39               ` Laurent Pinchart
2013-08-21 12:49               ` Sergei Shtylyov
2013-08-21 12:49                 ` Sergei Shtylyov
2013-08-21 12:58                 ` Laurent Pinchart
2013-08-21 12:58                   ` Laurent Pinchart
2013-08-26 21:30                   ` Sergei Shtylyov
2013-08-26 21:30                     ` Sergei Shtylyov
2013-08-27  6:41                     ` Laurent Pinchart
2013-08-27  6:41                       ` Laurent Pinchart
2013-08-21  0:05   ` David Miller
2013-08-21  0:05     ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52137CD5.1040902@cogentembedded.com \
    --to=sergei.shtylyov@cogentembedded.com \
    --cc=davem@davemloft.net \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=lethal@linux-sh.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.