[net-next,v2,0/5] Support for RollBall 10G copper SFP modules

Hello,

this is v2 of series adding support for RollBall/Hilink SFP modules.

Checked with:
  checkpatch.pl --max-line-length=80

Changes from v1:
- wrapped to 80 columns as per Russell's request
- initialization of RollBall MDIO I2C protocol moved from sfp.c to
  mdio-i2c.c as per Russell's request
- second patch removes the 802.3z check also from phylink_sfp_config
  as suggested by Russell
- creation/destruction of mdiobus for SFP now occurs before probing
  for PHY/after releasing PHY (as suggested by Russell)
- the last patch became a little simpler after the above was done

Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Russell King <rmk+kernel@armlinux.org.uk>

Marek Behún (5):
  net: phy: mdio-i2c: support I2C MDIO protocol for RollBall SFP modules
  net: phylink: allow attaching phy for SFP modules on 802.3z mode
  net: sfp: create/destroy I2C mdiobus before PHY probe/after PHY
    release
  net: phy: marvell10g: change MACTYPE if underlying MAC does not
    support it
  net: sfp: add support for multigig RollBall transceivers

 drivers/net/mdio/mdio-i2c.c   | 232 +++++++++++++++++++++++++++++++++-
 drivers/net/phy/marvell10g.c  |  31 +++++
 drivers/net/phy/phylink.c     |   5 +-
 drivers/net/phy/sfp.c         |  67 ++++++++--
 include/linux/mdio/mdio-i2c.h |   8 +-
 5 files changed, 322 insertions(+), 21 deletions(-)


base-commit: cd29296fdfca919590e4004a7e4905544f4c4a32

A general point: please have me in the To: line rather than the Cc:
line so that I can find emails better; I've just spent quite a while
trying to find this series you posted last night amongst all the
other emails that I'm Cc'd on.

(The difference between To: and Cc: is that you expect those in the To:
header to be the primary recipients who you expect action from, and
those in the Cc: to be secondary recipients for information.)

https://blog.thedigitalgroup.com/to-vs-cc-vs-bcc-how-to-use-them-correctly
https://www.writebetteremails.com/to-cc.htm
https://thinkproductive.co.uk/email-using-cc-bcc-to/
... etc ...

Thanks.

On Thu, Oct 29, 2020 at 11:25:04PM +0100, Marek Behún wrote:
> Hello,
> 
> this is v2 of series adding support for RollBall/Hilink SFP modules.
> 
> Checked with:
>   checkpatch.pl --max-line-length=80
> 
> Changes from v1:
> - wrapped to 80 columns as per Russell's request
> - initialization of RollBall MDIO I2C protocol moved from sfp.c to
>   mdio-i2c.c as per Russell's request
> - second patch removes the 802.3z check also from phylink_sfp_config
>   as suggested by Russell
> - creation/destruction of mdiobus for SFP now occurs before probing
>   for PHY/after releasing PHY (as suggested by Russell)
> - the last patch became a little simpler after the above was done
> 
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Russell King <rmk+kernel@armlinux.org.uk>
> 
> Marek Behún (5):
>   net: phy: mdio-i2c: support I2C MDIO protocol for RollBall SFP modules
>   net: phylink: allow attaching phy for SFP modules on 802.3z mode
>   net: sfp: create/destroy I2C mdiobus before PHY probe/after PHY
>     release
>   net: phy: marvell10g: change MACTYPE if underlying MAC does not
>     support it
>   net: sfp: add support for multigig RollBall transceivers
> 
>  drivers/net/mdio/mdio-i2c.c   | 232 +++++++++++++++++++++++++++++++++-
>  drivers/net/phy/marvell10g.c  |  31 +++++
>  drivers/net/phy/phylink.c     |   5 +-
>  drivers/net/phy/sfp.c         |  67 ++++++++--
>  include/linux/mdio/mdio-i2c.h |   8 +-
>  5 files changed, 322 insertions(+), 21 deletions(-)
> 
> 
> base-commit: cd29296fdfca919590e4004a7e4905544f4c4a32
> -- 
> 2.26.2
> 
>

On Fri, Oct 30, 2020 at 03:01:38PM +0000, Russell King - ARM Linux admin wrote:
> https://blog.thedigitalgroup.com/to-vs-cc-vs-bcc-how-to-use-them-correctly

I have to disagree about some of the information provided in this link:

------------------------------[cut here]------------------------------
Using the BCC Field:

BCC is for Blind Carbon Copy. It sends copies of the email to multiple
recipients, the only difference being that none of the recipients are
made aware of who else has received the email.

The BCC field is used when you want to send an email to multiple
recipients but do not want any of them to know about the other people
you have sent them to. There can be many scenarios where the BCC field
might be used, and the purpose might be a desire to keep the names of
the recipients a secret to one another and also protect the privacy of
recipients.

The most common application is for sending an email to a long list of
people who do not know each other, such as mailing lists. This protects
the privacy of the recipients as they are not able to view each other’s
email addresses.
------------------------------[cut here]------------------------------

It's plain stupid to put a mailing list in Bcc. I have filters that move
inbound emails from Inbox to separate folders based on the mailing list
from To: or CC:, except for emails where my address is also in To: or Cc:.
But when the mailing list is in Bcc, that email evades the filter and
arrives directly in my inbox, regardless of whether I'm even an intended
recipient or not.