netdev - Re: [PATCH v2 net-next 10/12] net: aquantia: add support for Phy access

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 16 Oct 2019 13:12:54 +0000
From:   Igor Russkikh <Igor.Russkikh@...antia.com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "richardcochran@...il.com" <richardcochran@...il.com>,
        Egor Pomozov <Egor.Pomozov@...antia.com>,
        Dmitry Bezrukov <Dmitry.Bezrukov@...antia.com>,
        Simon Edelhaus <sedelhaus@...vell.com>,
        Nikita Danilov <Nikita.Danilov@...antia.com>
Subject: Re: [PATCH v2 net-next 10/12] net: aquantia: add support for Phy
 access


> Hi Igor
> 
> Is the Atlantic a combined MAC and PHY in one silicon, or are there
> two devices? Could the Atlantic MAC be used in combination with for
> example a Marvell PHY?

Hi Andrew,
No it can't. This is a monolitic MAC+Phy solution.
We do have MAC only NIC (AQC100 with SFP+ connector) - but even there SFP Phy is
controlled by MAC firmware and this is totally transparent for driver/OS.

>> +	aq_mdio_write_word(aq_hw, mmd, address, data);
>> +	hw_atl_reg_glb_cpu_sem_set(aq_hw, 1U, HW_ATL_FW_SM_MDIO);
>> +}
> 
> You have here the code needed to implement a real Linux MDIO bus
> driver. Are the MDIO pins exposed? Could somebody combine the chip
> with say a Marvell Ethernet switch? You then need access to the MDIO
> bus to control the switch. So by using a Linux MDIO bus driver, you
> make it easy for somebody to do that. You can keep with your firmware
> mostly driving the PHY.

No, these are not exposed as far as I know. Therefore it makes no sense
to expose that to linux.

>> +		aq_hw->phy_id = HW_ATL_PHY_ID_MAX;
>> +		return false;
>> +	}
> 
> For future proofing, should you not check it is actually one of your
> PHYs?

I don't think that makes sense, since that'll always be a hardcoded mac/phy pair.

Regards,
  Igor