All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ladislav Michl <oss-lists@triops.cz>
To: Andrew Lunn <andrew@lunn.ch>
Cc: linux-staging@lists.linux.dev, netdev@vger.kernel.org,
	linux-mips@vger.kernel.org,
	Chris Packham <chris.packham@alliedtelesis.co.nz>
Subject: Re: [PATCH 2/3] staging: octeon: avoid needless device allocation
Date: Thu, 13 Apr 2023 18:43:41 +0200	[thread overview]
Message-ID: <ZDgxPet9RIDC9Oz1@lenoch> (raw)
In-Reply-To: <543bfbb6-af60-4b5d-abf8-0274ab0b713f@lunn.ch>

Hi Andrew,

On Thu, Apr 13, 2023 at 06:12:28PM +0200, Andrew Lunn wrote:
> >  	num_interfaces = cvmx_helper_get_number_of_interfaces();
> >  	for (interface = 0; interface < num_interfaces; interface++) {
> > +		int num_ports, port_index;
> > +		const struct net_device_ops *ops;
> > +		const char *name;
> > +		phy_interface_t phy_mode = PHY_INTERFACE_MODE_NA;
> >  		cvmx_helper_interface_mode_t imode =
> > -		    cvmx_helper_interface_get_mode(interface);
> > -		int num_ports = cvmx_helper_ports_on_interface(interface);
> > -		int port_index;
> > +			cvmx_helper_interface_get_mode(interface);
> > +
> > +		switch (imode) {
> > +		case CVMX_HELPER_INTERFACE_MODE_NPI:
> > +			ops = &cvm_oct_npi_netdev_ops;
> > +			name = "npi%d";
> 
> In general, the kernel does not give the interface names other than
> ethX. userspace can rename them, e.g. systemd with its persistent
> names. So as part of getting this driver out of staging, i would throw
> this naming code away.

That would break all userspace (which is often running vendor's kernel).
But since driver is in staging and noone cares about vendor's kernel
I guess it is okay...

> > +		num_ports = cvmx_helper_ports_on_interface(interface);
> >  		for (port_index = 0,
> >  		     port = cvmx_helper_get_ipd_port(interface, 0);
> >  		     port < cvmx_helper_get_ipd_port(interface, num_ports);
> >  		     port_index++, port++) {
> >  			struct octeon_ethernet *priv;
> >  			struct net_device *dev =
> > -			    alloc_etherdev(sizeof(struct octeon_ethernet));
> > +				alloc_etherdev(sizeof(struct octeon_ethernet));
> 
> Please try to avoid white space changed. Put such white space changes
> into a patch of their own, with a commit message saying it just
> contains whitespace cleanup.

Sorry, I overlooked this.

> >  			if (!dev) {
> >  				pr_err("Failed to allocate ethernet device for port %d\n",
> >  				       port);
> > @@ -830,7 +875,12 @@ static int cvm_oct_probe(struct platform_device *pdev)
> >  			priv->port = port;
> >  			priv->queue = cvmx_pko_get_base_queue(priv->port);
> >  			priv->fau = fau - cvmx_pko_get_num_queues(port) * 4;
> > -			priv->phy_mode = PHY_INTERFACE_MODE_NA;
> > +			priv->phy_mode = phy_mode;
> 
> You should be getting phy_mode from DT.
> 
> Ideally, you want lots of small patches which are obviously
> correct. So i would try to break this up into smaller changes.
> 
> I also wounder if you are addresses issues in the correct order. This
> driver is in staging for a reason. It needs a lot of work. You might
> be better off first cleaning it up. And then consider moving it to
> phylink.

I was asking this question myself and then came to this:
Converting driver to phylink makes separating different macs easier as
this driver is splitted between staging and arch/mips/cavium-octeon/executive/
However I'll provide changes spotted previously as separate preparational
patches. Would that work for you?

> 	 Andrew

Thank you,
	ladis

  reply	other threads:[~2023-04-13 16:43 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-13 14:11 [PATCH 0/3] staging: octeon: Convert to use phylink Ladislav Michl
2023-04-13 14:13 ` [PATCH 1/3] staging: octeon: don't panic Ladislav Michl
2023-04-13 15:57   ` Andrew Lunn
2023-04-13 16:14     ` Ladislav Michl
2023-04-13 16:28       ` Andrew Lunn
2023-04-13 14:14 ` [PATCH 2/3] staging: octeon: avoid needless device allocation Ladislav Michl
2023-04-13 16:12   ` Andrew Lunn
2023-04-13 16:43     ` Ladislav Michl [this message]
2023-04-13 17:20       ` Andrew Lunn
2023-04-13 17:51         ` Ladislav Michl
2023-04-15  0:21         ` Ladislav Michl
2023-04-17  8:37         ` Dan Carpenter
2023-04-17  9:37           ` Ladislav Michl
2023-04-17 13:27             ` Andrew Lunn
2023-04-13 14:15 ` [RFC 3/3] staging: octeon: convert to use phylink Ladislav Michl
2023-04-13 15:35   ` Dan Carpenter
2023-04-13 16:04     ` Ladislav Michl
2023-04-13 16:10       ` Dan Carpenter
2023-04-13 16:17         ` Ladislav Michl
2023-04-13 15:45 ` [PATCH 0/3] staging: octeon: Convert " Andrew Lunn
2023-04-13 16:35   ` Ladislav Michl
2023-04-13 17:12     ` Andrew Lunn
2023-04-13 17:29       ` Ladislav Michl

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=ZDgxPet9RIDC9Oz1@lenoch \
    --to=oss-lists@triops.cz \
    --cc=andrew@lunn.ch \
    --cc=chris.packham@alliedtelesis.co.nz \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --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.