All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivien Didelot <vivien.didelot@gmail.com>
To: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Rasmus Villemoes <Rasmus.Villemoes@prevas.se>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 1/5] net: dsa: mv88e6xxx: introduce support for two chips using direct smi addressing
Date: Fri, 24 May 2019 13:54:07 -0400	[thread overview]
Message-ID: <20190524135407.GB17138@t480s.localdomain> (raw)
In-Reply-To: <20190524085921.11108-2-rasmus.villemoes@prevas.dk>

Hi Rasmus,

On Fri, 24 May 2019 09:00:24 +0000, Rasmus Villemoes <rasmus.villemoes@prevas.dk> wrote:
> The 88e6250 (as well as 6220, 6071, 6070, 6020) do not support
> multi-chip (indirect) addressing. However, one can still have two of
> them on the same mdio bus, since the device only uses 16 of the 32
> possible addresses, either addresses 0x00-0x0F or 0x10-0x1F depending
> on the ADDR4 pin at reset [since ADDR4 is internally pulled high, the
> latter is the default].
> 
> In order to prepare for supporting the 88e6250 and friends, introduce
> mv88e6xxx_info::dual_chip to allow having a non-zero sw_addr while
> still using direct addressing.
> 
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
> ---
>  drivers/net/dsa/mv88e6xxx/chip.h |  6 ++++++
>  drivers/net/dsa/mv88e6xxx/smi.c  | 25 ++++++++++++++++++++++++-
>  2 files changed, 30 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/dsa/mv88e6xxx/chip.h b/drivers/net/dsa/mv88e6xxx/chip.h
> index faa3fa889f19..74777c3bc313 100644
> --- a/drivers/net/dsa/mv88e6xxx/chip.h
> +++ b/drivers/net/dsa/mv88e6xxx/chip.h
> @@ -112,6 +112,12 @@ struct mv88e6xxx_info {
>  	 * when it is non-zero, and use indirect access to internal registers.
>  	 */
>  	bool multi_chip;
> +	/* Dual-chip Addressing Mode
> +	 * Some chips respond to only half of the 32 SMI addresses,
> +	 * allowing two to coexist on the same SMI interface.
> +	 */
> +	bool dual_chip;
> +
>  	enum dsa_tag_protocol tag_protocol;
>  
>  	/* Mask for FromPort and ToPort value of PortVec used in ATU Move
> diff --git a/drivers/net/dsa/mv88e6xxx/smi.c b/drivers/net/dsa/mv88e6xxx/smi.c
> index 96f7d2685bdc..1151b5b493ea 100644
> --- a/drivers/net/dsa/mv88e6xxx/smi.c
> +++ b/drivers/net/dsa/mv88e6xxx/smi.c
> @@ -24,6 +24,10 @@
>   * When ADDR is non-zero, the chip uses Multi-chip Addressing Mode, allowing
>   * multiple devices to share the SMI interface. In this mode it responds to only
>   * 2 registers, used to indirectly access the internal SMI devices.
> + *
> + * Some chips use a different scheme: Only the ADDR4 pin is used for
> + * configuration, and the device responds to 16 of the 32 SMI
> + * addresses, allowing two to coexist on the same SMI interface.
>   */
>  
>  static int mv88e6xxx_smi_direct_read(struct mv88e6xxx_chip *chip,
> @@ -76,6 +80,23 @@ static const struct mv88e6xxx_bus_ops mv88e6xxx_smi_direct_ops = {
>  	.write = mv88e6xxx_smi_direct_write,
>  };
>  
> +static int mv88e6xxx_smi_dual_direct_read(struct mv88e6xxx_chip *chip,
> +					  int dev, int reg, u16 *data)
> +{
> +	return mv88e6xxx_smi_direct_read(chip, dev + chip->sw_addr, reg, data);

Using chip->sw_addr + dev seems more idiomatic to me than dev + chip->sw_addr.

> +}
> +
> +static int mv88e6xxx_smi_dual_direct_write(struct mv88e6xxx_chip *chip,
> +					   int dev, int reg, u16 data)
> +{
> +	return mv88e6xxx_smi_direct_write(chip, dev + chip->sw_addr, reg, data);
> +}
> +
> +static const struct mv88e6xxx_bus_ops mv88e6xxx_smi_dual_direct_ops = {
> +	.read = mv88e6xxx_smi_dual_direct_read,
> +	.write = mv88e6xxx_smi_dual_direct_write,
> +};
> +
>  /* Offset 0x00: SMI Command Register
>   * Offset 0x01: SMI Data Register
>   */
> @@ -144,7 +165,9 @@ static const struct mv88e6xxx_bus_ops mv88e6xxx_smi_indirect_ops = {
>  int mv88e6xxx_smi_init(struct mv88e6xxx_chip *chip,
>  		       struct mii_bus *bus, int sw_addr)
>  {
> -	if (sw_addr == 0)
> +	if (chip->info->dual_chip)
> +		chip->smi_ops = &mv88e6xxx_smi_dual_direct_ops;
> +	else if (sw_addr == 0)
>  		chip->smi_ops = &mv88e6xxx_smi_direct_ops;
>  	else if (chip->info->multi_chip)
>  		chip->smi_ops = &mv88e6xxx_smi_indirect_ops;

Please submit respins (v2, v3, and so on) as independent threads,
not as a reply to the previous version.

Otherwise this looks good to me:

Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com>

Thanks,
Vivien

  parent reply	other threads:[~2019-05-24 17:54 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-01 19:32 [RFC PATCH 0/5] net: dsa: POC support for mv88e6250 Rasmus Villemoes
2019-05-01 19:32 ` [RFC PATCH 1/5] net: dsa: mv88e6xxx: introduce support for two chips using direct smi addressing Rasmus Villemoes
2019-05-01 20:19   ` Andrew Lunn
2019-05-08  7:57     ` Rasmus Villemoes
2019-05-08 11:47       ` Andrew Lunn
2019-05-08 13:41         ` Vivien Didelot
2019-05-01 19:32 ` [RFC PATCH 2/5] net: dsa: mv88e6xxx: rename smi read/write functions Rasmus Villemoes
2019-05-03 21:57   ` Vivien Didelot
2019-05-06  5:57     ` Rasmus Villemoes
2019-05-06 14:51       ` Vivien Didelot
2019-05-01 19:32 ` [RFC PATCH 3/5] net: dsa: prepare mv88e6xxx_g1_atu_op() for the mv88e6250 Rasmus Villemoes
2019-05-01 20:22   ` Andrew Lunn
2019-05-01 19:32 ` [RFC PATCH 4/5] net: dsa: implement vtu_getnext and vtu_loadpurge for mv88e6250 Rasmus Villemoes
2019-05-01 20:25   ` Andrew Lunn
2019-05-01 19:32 ` [RFC PATCH 5/5] net: dsa: add support " Rasmus Villemoes
2019-05-01 20:29   ` Andrew Lunn
2019-05-24  9:00 ` [PATCH v2 0/5] net: dsa: " Rasmus Villemoes
2019-05-24  9:00   ` [PATCH v2 1/5] net: dsa: mv88e6xxx: introduce support for two chips using direct smi addressing Rasmus Villemoes
2019-05-24 14:13     ` Andrew Lunn
2019-05-24 17:54     ` Vivien Didelot [this message]
2019-05-24  9:00   ` [PATCH v2 2/5] net: dsa: prepare mv88e6xxx_g1_atu_op() for the mv88e6250 Rasmus Villemoes
2019-05-24 17:57     ` Vivien Didelot
2019-05-24  9:00   ` [PATCH v2 3/5] net: dsa: implement vtu_getnext and vtu_loadpurge for mv88e6250 Rasmus Villemoes
2019-05-24 18:02     ` Vivien Didelot
2019-05-24  9:00   ` [PATCH v2 4/5] net: dsa: mv88e6xxx: implement watchdog_ops " Rasmus Villemoes
2019-05-24 14:20     ` Andrew Lunn
2019-05-24 18:05     ` Vivien Didelot
2019-05-24  9:00   ` [PATCH v2 5/5] net: dsa: add support " Rasmus Villemoes
2019-05-24 14:27     ` Andrew Lunn
2019-06-03  8:52       ` Rasmus Villemoes
2019-06-03 12:45         ` Andrew Lunn
2019-05-24 18:11     ` Vivien Didelot

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=20190524135407.GB17138@t480s.localdomain \
    --to=vivien.didelot@gmail.com \
    --cc=Rasmus.Villemoes@prevas.se \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=rasmus.villemoes@prevas.dk \
    /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.