netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ansuel Smith <ansuelsmth@gmail.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Vladimir Oltean <olteanv@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [net-next RFC PATCH v4 12/15] net: dsa: qca8k: add support for mdio read/write in Ethernet packet
Date: Sun, 12 Dec 2021 18:41:07 +0100	[thread overview]
Message-ID: <61b63435.1c69fb81.c034e.3f94@mx.google.com> (raw)
In-Reply-To: <1776b726-6a96-d522-e625-f0f6b108782a@gmail.com>

On Sat, Dec 11, 2021 at 08:12:51PM -0800, Florian Fainelli wrote:
> 
> 
> On 12/11/2021 11:57 AM, Ansuel Smith wrote:
> > Add qca8k side support for mdio read/write in Ethernet packet.
> > qca8k supports some specially crafted Ethernet packet that can be used
> > for mdio read/write instead of the legacy method uart/internal mdio.
> > This add support for the qca8k side to craft the packet and enqueue it.
> > Each port and the qca8k_priv have a special struct to put data in it.
> > The completion API is used to wait for the packet to be received back
> > with the requested data.
> > 
> > The various steps are:
> > 1. Craft the special packet with the qca hdr set to mdio read/write
> >     mode.
> > 2. Set the lock in the dedicated mdio struct.
> > 3. Reinit the completion.
> > 4. Enqueue the packet.
> > 5. Wait the packet to be received.
> > 6. Use the data set by the tagger to complete the mdio operation.
> > 
> > If the completion timeouts or the ack value is not true, the legacy
> > mdio way is used.
> > 
> > It has to be considered that in the initial setup mdio is still used and
> > mdio is still used until DSA is ready to accept and tag packet.
> > 
> > tag_proto_connect() is used to fill the required handler for the tagger
> > to correctly parse and elaborate the special Ethernet mdio packet.
> > 
> > Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> > ---
> 
> [snip]
> 
> > +
> > +static struct sk_buff *qca8k_alloc_mdio_header(enum mdio_cmd cmd, u32 reg, u32 *val,
> > +					       int seq_num)
> > +{
> > +	struct mdio_ethhdr *mdio_ethhdr;
> > +	struct sk_buff *skb;
> > +	u16 hdr;
> > +
> > +	skb = dev_alloc_skb(QCA_HDR_MDIO_PKG_LEN);
> 
> No out of memory condition handling?
>

Will add.

> > +
> > +	prefetchw(skb->data);
> 
> What's the point you are going to dirty the cache lines right below with
> your skb_push().
> 

Will drop.

> > +
> > +	skb_reset_mac_header(skb);
> > +	skb_set_network_header(skb, skb->len);
> > +
> > +	mdio_ethhdr = skb_push(skb, QCA_HDR_MDIO_HEADER_LEN + QCA_HDR_LEN);
> > +
> > +	hdr = FIELD_PREP(QCA_HDR_XMIT_VERSION, QCA_HDR_VERSION);
> > +	hdr |= QCA_HDR_XMIT_FROM_CPU;
> > +	hdr |= FIELD_PREP(QCA_HDR_XMIT_DP_BIT, BIT(0));
> > +	hdr |= FIELD_PREP(QCA_HDR_XMIT_CONTROL, QCA_HDR_XMIT_TYPE_RW_REG);
> > +
> > +	mdio_ethhdr->seq = FIELD_PREP(QCA_HDR_MDIO_SEQ_NUM, seq_num);
> > +
> > +	mdio_ethhdr->command = FIELD_PREP(QCA_HDR_MDIO_ADDR, reg);
> > +	mdio_ethhdr->command |= FIELD_PREP(QCA_HDR_MDIO_LENGTH, 4);
> > +	mdio_ethhdr->command |= FIELD_PREP(QCA_HDR_MDIO_CMD, cmd);
> > +	mdio_ethhdr->command |= FIELD_PREP(QCA_HDR_MDIO_CHECK_CODE, MDIO_CHECK_CODE_VAL);
> > +
> > +	if (cmd == MDIO_WRITE)
> > +		mdio_ethhdr->mdio_data = *val;
> > +
> > +	mdio_ethhdr->hdr = htons(hdr);
> > +
> > +	skb_put_zero(skb, QCA_HDR_MDIO_DATA2_LEN);
> > +	skb_put_zero(skb, QCA_HDR_MDIO_PADDING_LEN);
> > +
> > +	return skb;
> > +}
> > +
> > +static int qca8k_read_eth(struct qca8k_priv *priv, u32 reg, u32 *val)
> > +{
> > +	struct qca8k_mdio_hdr_data *mdio_hdr_data = &priv->mdio_hdr_data;
> > +	struct sk_buff *skb;
> > +	bool ack;
> > +	int ret;
> > +
> > +	skb = qca8k_alloc_mdio_header(MDIO_READ, reg, NULL, 200);
> > +	skb->dev = dsa_to_port(priv->ds, 0)->master;
> 
> Surely you should be checking that this is the CPU port and obtain it from
> DSA instead of hard coding it to 0.
> 

You are right as we can also have port6 as cpu port.

> > +
> > +	mutex_lock(&mdio_hdr_data->mutex);
> > +
> > +	reinit_completion(&mdio_hdr_data->rw_done);
> > +	mdio_hdr_data->seq = 200;
> > +	mdio_hdr_data->ack = false;
> > +
> > +	dev_queue_xmit(skb);
> > +
> > +	ret = wait_for_completion_timeout(&mdio_hdr_data->rw_done, QCA8K_ETHERNET_TIMEOUT);
> 
> msec_to_jiffies(QCA8K_ETHERNET_TIMEOUT) at least?

Sorry got it work and misread that the conversion was implicit.

> -- 
> Florian

-- 
	Ansuel

  reply	other threads:[~2021-12-12 17:41 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-11 19:57 [net-next RFC PATCH v4 00/15] Add support for qca8k mdio rw in Ethernet packet Ansuel Smith
2021-12-11 19:57 ` [net-next RFC PATCH v4 01/15] net: dsa: provide switch operations for tracking the master state Ansuel Smith
2021-12-12  4:22   ` Florian Fainelli
2021-12-12 18:19     ` Ansuel Smith
2021-12-12 18:19     ` Vladimir Oltean
2021-12-11 19:57 ` [net-next RFC PATCH v4 02/15] net: dsa: stop updating master MTU from master.c Ansuel Smith
2021-12-12  4:23   ` Florian Fainelli
2021-12-11 19:57 ` [net-next RFC PATCH v4 03/15] net: dsa: hold rtnl_mutex when calling dsa_master_{setup,teardown} Ansuel Smith
2021-12-12  4:24   ` Florian Fainelli
2021-12-11 19:57 ` [net-next RFC PATCH v4 04/15] net: dsa: replay master state events in dsa_tree_{setup,teardown}_master Ansuel Smith
2021-12-12  4:25   ` Florian Fainelli
2021-12-11 19:57 ` [net-next RFC PATCH v4 05/15] net: dsa: tag_qca: convert to FIELD macro Ansuel Smith
2021-12-11 19:57 ` [net-next RFC PATCH v4 06/15] net: dsa: tag_qca: move define to include linux/dsa Ansuel Smith
2021-12-11 19:57 ` [net-next RFC PATCH v4 07/15] net: da: tag_qca: enable promisc_on_master flag Ansuel Smith
2021-12-11 19:57 ` [net-next RFC PATCH v4 08/15] net: dsa: tag_qca: add define for handling mdio Ethernet packet Ansuel Smith
2021-12-11 19:57 ` [net-next RFC PATCH v4 09/15] net: dsa: tag_qca: add define for handling MIB packet Ansuel Smith
2021-12-11 19:57 ` [net-next RFC PATCH v4 10/15] net: dsa: tag_qca: add support for handling mdio Ethernet and " Ansuel Smith
2021-12-11 19:57 ` [net-next RFC PATCH v4 11/15] net: dsa: qca8k: add tracking state of master port Ansuel Smith
2021-12-11 19:57 ` [net-next RFC PATCH v4 12/15] net: dsa: qca8k: add support for mdio read/write in Ethernet packet Ansuel Smith
2021-12-12  4:12   ` Florian Fainelli
2021-12-12 17:41     ` Ansuel Smith [this message]
2021-12-11 19:57 ` [net-next RFC PATCH v4 13/15] net: dsa: qca8k: add support for mib autocast " Ansuel Smith
2021-12-11 19:57 ` [net-next RFC PATCH v4 14/15] net: dsa: qca8k: add support for phy read/write with mdio Ethernet Ansuel Smith
2021-12-11 19:57 ` [net-next RFC PATCH v4 15/15] net: dsa: qca8k: cache lo and hi for mdio write Ansuel Smith
2021-12-12  4:04   ` Florian Fainelli
2021-12-12 17:43     ` Ansuel Smith

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=61b63435.1c69fb81.c034e.3f94@mx.google.com \
    --to=ansuelsmth@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=vivien.didelot@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).