netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Oleksij Rempel <o.rempel@pengutronix.de>
Cc: Arun.Ramadoss@microchip.com, andrew@lunn.ch,
	linux-kernel@vger.kernel.org, UNGLinuxDriver@microchip.com,
	vivien.didelot@gmail.com, san@skov.dk, linux@armlinux.org.uk,
	f.fainelli@gmail.com, kuba@kernel.org, edumazet@google.com,
	pabeni@redhat.com, netdev@vger.kernel.org,
	Woojung.Huh@microchip.com, davem@davemloft.net
Subject: Re: [Patch net-next v2 0/9] net: dsa: microchip: add support for phylink mac config and link up
Date: Thu, 1 Sep 2022 15:47:37 +0300	[thread overview]
Message-ID: <20220901124737.mrfo3fefjsn4scuy@skbuf> (raw)
In-Reply-To: <20220901112721.GB2479@pengutronix.de>

On Thu, Sep 01, 2022 at 01:27:21PM +0200, Oleksij Rempel wrote:
> > The global register 0x06 responsibilities are bit 4 for 10/100mbps
> > speed selection, bit 5 for flow control and bit 6  for duplex
> > operation. Since these three are new features added during refactoring
> > I overlooked it. 
> > To fix this, either I need to return from the ksz_set_100_10mbit &
> > ksz_duplex_flowctrl function if the chip_id is ksz87xx or add
> > dev->dev_ops for this alone.  Kindly suggest on how to proceed.
> 
> I would prefer to got ops way, to clean things up.

I can't say that that one approach is better or worse than the other.
Indirect function calls are going to be more expensive than conditionals
on dev->chip_id, but we aren't in a fast path here, so it doesn't matter
too much.

Having indirect function calls will in theory help simplify the logic of
the main function, but will require good forethought for what constitutes
an atom of functionality, in a high enough level such as to abstract
switch differences. Whereas conditionals don't require thinking that far,
you put them where you need them.

Also, indirect function calls will move the bloat somewhere else. I have
seen complaints in the past about the mv88e6xxx driver's layered structure,
making it difficult to see exactly what gets done for a certain chip.

It is probable that we don't want to mix these styles too much within a
single driver, so if work has already started towards dev_ops for
everything, then dev_ops be it, I guess.

Oleksij, are you going to submit patches with your proposal?

  reply	other threads:[~2022-09-01 12:47 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-24  9:28 [Patch net-next v2 0/9] net: dsa: microchip: add support for phylink mac config and link up Arun Ramadoss
2022-07-24  9:28 ` [Patch net-next v2 1/9] net: dsa: microchip: add common gigabit set and get function Arun Ramadoss
2022-07-24  9:28 ` [Patch net-next v2 2/9] net: dsa: microchip: add common ksz port xmii speed selection function Arun Ramadoss
2022-07-24  9:28 ` [Patch net-next v2 3/9] net: dsa: microchip: add common duplex and flow control function Arun Ramadoss
2022-07-24  9:28 ` [Patch net-next v2 4/9] net: dsa: microchip: add support for common phylink mac link up Arun Ramadoss
2022-07-24  9:28 ` [Patch net-next v2 5/9] net: dsa: microchip: lan937x: add support for configuing xMII register Arun Ramadoss
2022-07-24  9:28 ` [Patch net-next v2 6/9] net: dsa: microchip: apply rgmii tx and rx delay in phylink mac config Arun Ramadoss
2022-07-24  9:28 ` [Patch net-next v2 7/9] net: dsa: microchip: ksz9477: use common xmii function Arun Ramadoss
2022-07-24  9:28 ` [Patch net-next v2 8/9] net: dsa: microchip: ksz8795: " Arun Ramadoss
2022-07-24  9:38 ` [Patch net-next v2 9/9] net: dsa: microchip: add support for phylink mac config Arun Ramadoss
2022-07-24 21:54 ` [Patch net-next v2 0/9] net: dsa: microchip: add support for phylink mac config and link up Vladimir Oltean
2022-07-27  8:50 ` patchwork-bot+netdevbpf
2022-08-30  6:55 ` Oleksij Rempel
2022-08-30  8:15   ` Arun.Ramadoss
2022-08-30  9:58     ` Vladimir Oltean
2022-08-30 16:05       ` Oleksij Rempel
2022-08-31  7:43         ` Oleksij Rempel
2022-08-31 15:18           ` Vladimir Oltean
2022-08-31 16:10             ` Oleksij Rempel
2022-09-01  8:51               ` Arun.Ramadoss
2022-09-01 11:27                 ` Oleksij Rempel
2022-09-01 12:47                   ` Vladimir Oltean [this message]
2022-09-02  9:57                     ` Oleksij Rempel

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=20220901124737.mrfo3fefjsn4scuy@skbuf \
    --to=olteanv@gmail.com \
    --cc=Arun.Ramadoss@microchip.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=Woojung.Huh@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=o.rempel@pengutronix.de \
    --cc=pabeni@redhat.com \
    --cc=san@skov.dk \
    --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).