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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 16 Sep 2020 22:32:03 +0100
From:   David Bilsby <d.bilsby@...gin.net>
To:     Petko Manolov <petkan@...leusys.com>,
        Thor Thayer <thor.thayer@...ux.intel.com>
Cc:     netdev@...r.kernel.org
Subject: Re: Re: Altera TSE driver not working in 100mbps mode

Hi

Would you consider making the PhyLink modifications to the Altera TSE 
driver public as this would be very useful for a board we have which 
uses an SFP PHY connected to the TSE core via I2C. Currently we are 
using a fibre SFP and fixing the speed to 1G but would really like to be 
able to use a copper SFP which needs to do negotiation.

Cheers

David

On 03/12/2019 09:29, Petko Manolov wrote:
> All right, the first message got ignored so this is my take two. :)
>
> Has anyone stumbled on the same problem as me?
>
>
> cheers,
> Petko
>
>
> On 19-11-27 15:54:19, Petko Manolov wrote:
>> 	Hi Thor,
>>
>> In my effort to move Altera TSE driver from PHYLIB to PHYLINK i ran into a
>> problem.  The driver would not work properly on 100Mbit/s links.  This is true
>> for the original driver in linux-5.4.y as well as for my PHYLINK/SFP enabled
>> version.
>>
>> This is a DT fragment of what i've been trying with 5.4.y kernels and the
>> stock driver:
>>
>>                  tse_sub_2: ethernet@...0300000 {
>>                          status = "disabled";
>>
>>                          compatible = "altr,tse-msgdma-1.0";
>>                          reg =   <0xc0300000 0x00000400>,
>>                                  <0xc0301000 0x00000020>,
>>                                  <0xc0302000 0x00000020>,
>>                                  <0xc0303000 0x00000008>,
>>                                  <0xc0304000 0x00000020>,
>>                                  <0xc0305000 0x00000020>;
>>                          reg-names = "control_port", "rx_csr", "rx_desc", "rx_resp", "tx_csr", "tx_desc";
>>                          interrupt-parent =< &intc >;
>>                          interrupts = <0 54 4>, <0 55 4>;
>>                          interrupt-names = "rx_irq", "tx_irq";
>>                          rx-fifo-depth = <2048>;
>>                          tx-fifo-depth = <2048>;
>>                          address-bits = <48>;
>>                          max-frame-size = <1500>;
>>                          local-mac-address = [ 00 0C ED 00 00 06 ];
>>                          altr,has-supplementary-unicast;
>>                          altr,has-hash-multicast-filter;
>>                          phy-handle = <0>;
>>                          fixed-link {
>>                                  speed = <1000>;
>>                                  full-duplex;
>>                          };
>>                  };
>>
>> Trying "speed = <100>;" above also doesn't change much, except that the link is
>> reported (as expected) as 100Mbps.
>>
>> With the PHYLINK code the above fragment is pretty much the same except for:
>>
>>                          sfp = <&sfp0>;
>>                          phy-mode = "sgmii";
>>                          managed = "in-band-status";
>>
>> Both (old and new) drivers are working fine on 1Gbps links with optics and
>> copper SFPs.  With PHYLINK code (and in auto-negotiation mode) the link speed
>> and duplex is properly detected as 100Mbps.  MAC and PCS also look correctly set
>> up, but the device is still unable to receive or transmit packages.
>>
>>
>> Please let me know should you need more details.
>>
>>
>> thanks,
>> Petko
>>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ