[PATCH] realtek: Fix kernel dependencies on CONFIG_MDIO_SMBUS

[Bjørn Mork]

Birger Koblitz <mail at birger-koblitz.de> writes:
> On 15.03.22 15:10, Bjørn Mork wrote:
>> Bjørn Mork <bjorn at mork.no> writes:
>> 
>>> Just drop the unnecssary I2C_SMBUS dependency.  AFAICS, you're only
>>> using i2c_smbus_xfer() which is part of the i2c core.
> The reason for the ifdefs were mdio_smbus_alloc().

I still can't see anything depending on I2C_SMBUS there?  This is the
troublesome one.

Depending on MDIO_SMBUS is fine if you decide to keep that as a separate
module.  But then the sfp driver should select MDIO_SMBUS along with
MDIO_I2C and drop the ifdefs.

In my humble opinion, I should add...  
 
>> Looking further at this, I believe there are good reasons to simply
>> merge the mdio-smbus implementation into mdio-i2c: You seem to have lost
>> some clause 45 specific stuff from commit 6912b712cd75 ("net: mdio-i2c:
>> add support for Clause 45 accesses")
>> 
>> And the i2c_mii_valid_phy_id() tests to avoid eeprom access are also
>> missing.  Maybe not important, but demonstrating the problems with
>> copying code.  Even modules as small as these tend to grow apart over
>> time.
>> 
>> I guess the clause 45 support could be important for multigig copper
>> SFPs?
> Absolutely. I just hope that we will soon have this support. The 10G SFPs
> on the RTL93xx are a nightmare to understand.
>
> I'll pick up your suggestion with merging into mdio-i2c and also ask the original
> author of the patch why it was not upstreamed. Maybe we can learn what still
> would have been necessary.

Great!

This is really stuff that should Just Work, without having to think too
much about driver implementation details.  Varying dependencies are
messy.

(I started playing with the thought that both the sfp driver and the
mdio-i2c bus driver could use SMBus transfers unconditionally, depending
on the automatic fallback to emulated SMBus.  Probably not a good
idea...)


Bjørn