Netdev List
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Magnus Lindholm <linmag7@gmail.com>
Cc: pavan.chebbi@broadcom.com, mchan@broadcom.com,
	andrew+netdev@lunn.ch, edumazet@google.com, kuba@kernel.org,
	pabeni@redhat.com, netdev@vger.kernel.org,
	sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next] tg3: normalize inherited M3000 register byte order
Date: Fri, 9 Oct 2026 03:13:12 +0200	[thread overview]
Message-ID: <038bffb2-e40d-44bb-b7ce-53e9de32e50d@lunn.ch> (raw)
In-Reply-To: <20261008220433.965791-1-linmag7@gmail.com>

On Fri, Oct 09, 2026 at 12:04:03AM +0200, Magnus Lindholm wrote:
> M3000 firmware can leave BCM5718 vendor registers byte-swapped while
> standard PCI fields retain normal byte order. Match the Fujitsu 10cf:165a
> subsystem, IKKAKU model and swapped revision/product signature before
> restoring host control; reject failed PCI accesses or register readbacks.
> 
> Keep this in probe so failures can abort initialization; SPARC firmware
> enumeration skips PCI_FIXUP_EARLY. Normal rebinds and other platforms
> retain their existing path.
> 
> Use tg3.h's MISC_HOST_CTRL_BYTE_SWAP and TG3PCI_GEN2_PRODID_ASICREV;
> the inherited state was observed on M3000 hardware.
> 
> Signed-off-by: Magnus Lindholm <linmag7@gmail.com>

> +/* M3000 firmware can leave the on-board BCM5718 registers byte-swapped. */
> +static bool tg3_is_m3000(struct pci_dev *pdev)
> +{
> +	struct device_node *root;
> +	const char *model;
> +	bool match;
> +
> +	if (pdev->vendor != PCI_VENDOR_ID_BROADCOM ||
> +	    pdev->device != TG3PCI_DEVICE_TIGON3_5718 ||
> +	    pdev->subsystem_vendor != 0x10cf ||
> +	    pdev->subsystem_device != 0x165a)
> +		return false;
> +
> +	root = of_find_node_by_path("/");
> +	match = !of_property_read_string(root, "model", &model) &&
> +		!strcmp(model, "IKKAKU");

The DT Maintainers generally don't like this.

Is there a legitimate reason you would want the bytes are swapped?

Can you not just probe the registers, and if they are swapped undo it?
Does it really need to be conditional on the machine?

	Andrew

  reply	other threads:[~2026-10-09  1:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-08 22:04 [PATCH net-next] tg3: normalize inherited M3000 register byte order Magnus Lindholm
2026-10-09  1:13 ` Andrew Lunn [this message]
2026-10-09  6:28   ` Magnus Lindholm

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=038bffb2-e40d-44bb-b7ce-53e9de32e50d@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=andrew+netdev@lunn.ch \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=linmag7@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pavan.chebbi@broadcom.com \
    --cc=sparclinux@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox