All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Maxime Chevallier <maxime.chevallier@bootlin.com>
Cc: davem@davemloft.net, Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org, thomas.petazzoni@bootlin.com,
	Florian Fainelli <f.fainelli@gmail.com>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	linux-arm-kernel@lists.infradead.org,
	Vladimir Oltean <vladimir.oltean@nxp.com>,
	Luka Perkov <luka.perkov@sartura.hr>,
	Robert Marko <robert.marko@sartura.hr>
Subject: Re: [PATCH net-next v5 2/5] net: ipqess: introduce the Qualcomm IPQESS driver
Date: Fri, 21 Oct 2022 16:39:40 +0200	[thread overview]
Message-ID: <Y1KvLP39QFyvbARB@lunn.ch> (raw)
In-Reply-To: <20221021124556.100445-3-maxime.chevallier@bootlin.com>

> +static int ipqess_axi_remove(struct platform_device *pdev)
> +{
> +	const struct net_device *netdev = platform_get_drvdata(pdev);
> +	struct ipqess *ess = netdev_priv(netdev);
> +
> +	ipqess_hw_stop(ess);
> +	unregister_netdev(ess->netdev);

Should the unregister come first? What happens if the network stack
tries to use the interface during/after ipqess_hw_stop()? It just
seems like it would be safer to first unregister the interface, and
then stop it?

> +struct ipqess_tx_desc {
> +	__le16  len;
> +	__le16  svlan_tag;
> +	__le32  word1;
> +	__le32  addr;
> +	__le32  word3;
> +} __aligned(16) __packed;
> +
> +struct ipqess_rx_desc {
> +	u16 rrd0;
> +	u16 rrd1;
> +	u16 rrd2;
> +	u16 rrd3;
> +	u16 rrd4;
> +	u16 rrd5;
> +	u16 rrd6;
> +	u16 rrd7;
> +} __aligned(16) __packed;

The TX descriptor is little endian, but the RX descriptor is host
endian?

	Andrew

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Lunn <andrew@lunn.ch>
To: Maxime Chevallier <maxime.chevallier@bootlin.com>
Cc: davem@davemloft.net, Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org, thomas.petazzoni@bootlin.com,
	Florian Fainelli <f.fainelli@gmail.com>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	linux-arm-kernel@lists.infradead.org,
	Vladimir Oltean <vladimir.oltean@nxp.com>,
	Luka Perkov <luka.perkov@sartura.hr>,
	Robert Marko <robert.marko@sartura.hr>
Subject: Re: [PATCH net-next v5 2/5] net: ipqess: introduce the Qualcomm IPQESS driver
Date: Fri, 21 Oct 2022 16:39:40 +0200	[thread overview]
Message-ID: <Y1KvLP39QFyvbARB@lunn.ch> (raw)
In-Reply-To: <20221021124556.100445-3-maxime.chevallier@bootlin.com>

> +static int ipqess_axi_remove(struct platform_device *pdev)
> +{
> +	const struct net_device *netdev = platform_get_drvdata(pdev);
> +	struct ipqess *ess = netdev_priv(netdev);
> +
> +	ipqess_hw_stop(ess);
> +	unregister_netdev(ess->netdev);

Should the unregister come first? What happens if the network stack
tries to use the interface during/after ipqess_hw_stop()? It just
seems like it would be safer to first unregister the interface, and
then stop it?

> +struct ipqess_tx_desc {
> +	__le16  len;
> +	__le16  svlan_tag;
> +	__le32  word1;
> +	__le32  addr;
> +	__le32  word3;
> +} __aligned(16) __packed;
> +
> +struct ipqess_rx_desc {
> +	u16 rrd0;
> +	u16 rrd1;
> +	u16 rrd2;
> +	u16 rrd3;
> +	u16 rrd4;
> +	u16 rrd5;
> +	u16 rrd6;
> +	u16 rrd7;
> +} __aligned(16) __packed;

The TX descriptor is little endian, but the RX descriptor is host
endian?

	Andrew

  parent reply	other threads:[~2022-10-21 14:41 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-21 12:45 [PATCH net-next v5 0/5] [PATCH net-next v4 0/5] net: ipqess: introduce Qualcomm IPQESS driver Maxime Chevallier
2022-10-21 12:45 ` Maxime Chevallier
2022-10-21 12:45 ` [PATCH net-next v5 1/5] net: dt-bindings: Introduce the Qualcomm IPQESS Ethernet controller Maxime Chevallier
2022-10-21 12:45   ` Maxime Chevallier
2022-10-21 13:33   ` Krzysztof Kozlowski
2022-10-21 13:33     ` Krzysztof Kozlowski
2022-10-21 14:30   ` Vladimir Oltean
2022-10-21 14:30     ` Vladimir Oltean
2022-10-21 14:53   ` Rob Herring
2022-10-21 14:53     ` Rob Herring
2022-10-21 12:45 ` [PATCH net-next v5 2/5] net: ipqess: introduce the Qualcomm IPQESS driver Maxime Chevallier
2022-10-21 12:45   ` Maxime Chevallier
2022-10-21 13:38   ` Krzysztof Kozlowski
2022-10-21 13:38     ` Krzysztof Kozlowski
2022-10-21 14:39   ` Andrew Lunn [this message]
2022-10-21 14:39     ` Andrew Lunn
2022-10-21 17:49   ` kernel test robot
2022-10-21 17:59   ` kernel test robot
2022-10-21 12:45 ` [PATCH net-next v5 3/5] net: dsa: add out-of-band tagging protocol Maxime Chevallier
2022-10-21 12:45   ` Maxime Chevallier
2022-10-21 14:01   ` Vladimir Oltean
2022-10-21 14:01     ` Vladimir Oltean
2022-10-21 14:43   ` Andrew Lunn
2022-10-21 14:43     ` Andrew Lunn
2022-10-21 14:46   ` Andrew Lunn
2022-10-21 14:46     ` Andrew Lunn
2022-10-21 19:51   ` kernel test robot
2022-10-21 12:45 ` [PATCH net-next v5 4/5] net: ipqess: Add out-of-band DSA tagging support Maxime Chevallier
2022-10-21 12:45   ` Maxime Chevallier
2022-10-21 14:12   ` Vladimir Oltean
2022-10-21 14:12     ` Vladimir Oltean
2022-10-21 12:45 ` [PATCH net-next v5 5/5] ARM: dts: qcom: ipq4019: Add description for the IPQESS Ethernet controller Maxime Chevallier
2022-10-21 12:45   ` Maxime Chevallier
2022-10-21 14:20   ` Vladimir Oltean
2022-10-21 14:20     ` Vladimir Oltean
2022-10-21 14:29     ` Krzysztof Kozlowski
2022-10-21 14:29       ` Krzysztof Kozlowski

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=Y1KvLP39QFyvbARB@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=luka.perkov@sartura.hr \
    --cc=maxime.chevallier@bootlin.com \
    --cc=netdev@vger.kernel.org \
    --cc=robert.marko@sartura.hr \
    --cc=robh+dt@kernel.org \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=vladimir.oltean@nxp.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 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.