Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1520469 > unrolled thread

Gigabit ethernet driver for Alacritechs SLIC devices

Back to article view | Back to linux.kernel

Contents

  Gigabit ethernet driver for Alacritechs SLIC devices Lino Sanfilippo <LinoSanfilippo@gmx.de> - 2016-11-13 05:50 +0100
    Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit  ethernet driver Andrew Lunn <andrew@lunn.ch> - 2016-11-13 21:00 +0100
      Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit  ethernet driver Lino Sanfilippo <LinoSanfilippo@gmx.de> - 2016-11-15 21:50 +0100
        Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit  ethernet driver Florian Fainelli <f.fainelli@gmail.com> - 2016-11-15 22:00 +0100
          Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit  ethernet driver Lino Sanfilippo <LinoSanfilippo@gmx.de> - 2016-11-15 22:30 +0100
            Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit  ethernet driver Andrew Lunn <andrew@lunn.ch> - 2016-11-15 23:00 +0100
              Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit  ethernet driver Florian Fainelli <f.fainelli@gmail.com> - 2016-11-15 23:40 +0100
                Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit  ethernet driver Lino Sanfilippo <LinoSanfilippo@gmx.de> - 2016-11-16 00:00 +0100
                  Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit  ethernet driver Andrew Lunn <andrew@lunn.ch> - 2016-11-16 00:10 +0100
                    Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit  ethernet driver Lino Sanfilippo <LinoSanfilippo@gmx.de> - 2016-11-16 00:20 +0100
              Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit  ethernet driver Lino Sanfilippo <LinoSanfilippo@gmx.de> - 2016-11-15 23:40 +0100
                Aw: Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit  ethernet driver "Lino Sanfilippo" <LinoSanfilippo@gmx.de> - 2016-11-24 13:40 +0100

#1520469 — Gigabit ethernet driver for Alacritechs SLIC devices

Hi,

this is a rework of the slicoss gigabit ethernet driver from Alacritech 
that is currently part of the staging area. The driver is supposed to 
support Mojave, Oasis and Kalahari cards, for both copper and fiber.

If this code is accepted the staging version can be removed (as Greg 
told me by email, he would do this himself so this is not part of these
patches).

The driver is tested on a SEN2104ET card (4 Port PCIe copper).

Regards,
Lino

[toc] | [next] | [standalone]

#1520652 — Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver

> +static const char slic_stats_strings[][ETH_GSTRING_LEN] = {
> +	"rx_packets     ",
> +	"rx_bytes       ",
> +	"rx_multicasts  ",
> +	"rx_errors      ",
> +	"rx_buff_miss   ",
> +	"rx_tp_csum     ",
> +	"rx_tp_oflow    ",
> +	"rx_tp_hlen     ",
> +	"rx_ip_csum     ",
> +	"rx_ip_len      ",

Are there any other drivers which pad the statistics strings?

> +static void slic_set_link_autoneg(struct slic_device *sdev)
> +{
> +	unsigned int subid = sdev->pdev->subsystem_device;
> +	u32 val;
> +
> +	if (sdev->is_fiber) {
> +		/* We've got a fiber gigabit interface, and register 4 is
> +		 * different in fiber mode than in copper mode.
> +		 */
> +		/* advertise FD only @1000 Mb */
> +		val = MII_ADVERTISE << 16 | SLIC_PAR_ADV1000XFD |
> +		      SLIC_PAR_ASYMPAUSE_FIBER;
> +		/* enable PAUSE frames */
> +		slic_write(sdev, SLIC_REG_WPHY, val);
> +		/* reset phy, enable auto-neg  */
> +		val = MII_BMCR << 16 | SLIC_PCR_RESET | SLIC_PCR_AUTONEG |
> +		      SLIC_PCR_AUTONEG_RST;
> +		slic_write(sdev, SLIC_REG_WPHY, val);
> +	} else {	/* copper gigabit */
> +		/* We've got a copper gigabit interface, and register 4 is
> +		 * different in copper mode than in fiber mode.
> +		 */
> +		/* advertise 10/100 Mb modes   */
> +		val = MII_ADVERTISE << 16 | SLIC_PAR_ADV100FD |
> +		      SLIC_PAR_ADV100HD | SLIC_PAR_ADV10FD | SLIC_PAR_ADV10HD;
> +		/* enable PAUSE frames  */
> +		val |= SLIC_PAR_ASYMPAUSE;
> +		/* required by the Cicada PHY  */
> +		val |= SLIC_PAR_802_3;
> +		slic_write(sdev, SLIC_REG_WPHY, val);
> +
> +		/* advertise FD only @1000 Mb  */
> +		val = MII_CTRL1000 << 16 | SLIC_PGC_ADV1000FD;
> +		slic_write(sdev, SLIC_REG_WPHY, val);
> +
> +		if (subid != PCI_SUBDEVICE_ID_ALACRITECH_CICADA) {
> +			 /* if a Marvell PHY enable auto crossover */
> +			val = SLIC_MIICR_REG_16 | SLIC_MRV_REG16_XOVERON;
> +			slic_write(sdev, SLIC_REG_WPHY, val);
> +
> +			/* reset phy, enable auto-neg  */
> +			val = MII_BMCR << 16 | SLIC_PCR_RESET |
> +			      SLIC_PCR_AUTONEG | SLIC_PCR_AUTONEG_RST;
> +			slic_write(sdev, SLIC_REG_WPHY, val);
> +		} else {
> +			/* enable and restart auto-neg (don't reset)  */
> +			val = MII_BMCR << 16 | SLIC_PCR_AUTONEG |
> +			      SLIC_PCR_AUTONEG_RST;
> +			slic_write(sdev, SLIC_REG_WPHY, val);
> +		}
> +	}
> +	sdev->autoneg = true;
> +}

Could this be pulled out into a standard PHY driver? All the SLIC
SLIC_PCR_ defines seems to be the same as those in mii.h. This could
be a standard PHY hidden behind a single register.

   Andrew

[toc] | [prev] | [next] | [standalone]

#1523057 — Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver

Hi,


On 13.11.2016 20:55, Andrew Lunn wrote:
>> +static const char slic_stats_strings[][ETH_GSTRING_LEN] = {
>> +	"rx_packets     ",
>> +	"rx_bytes       ",
>> +	"rx_multicasts  ",
>> +	"rx_errors      ",
>> +	"rx_buff_miss   ",
>> +	"rx_tp_csum     ",
>> +	"rx_tp_oflow    ",
>> +	"rx_tp_hlen     ",
>> +	"rx_ip_csum     ",
>> +	"rx_ip_len      ",
> 
> Are there any other drivers which pad the statistics strings?
> 

First off, thank you for the review!

I took a look into a few drivers and most of them do not pad the statistic strings.
Actually there are some that do (e.g. the chelsio drivers cxgb4, cxgb3, xcgb4v), 
but this seems to be rather the minority, so I will remove it. Thank you for the hint.

>> +static void slic_set_link_autoneg(struct slic_device *sdev)
>> +{
>> +	unsigned int subid = sdev->pdev->subsystem_device;
>> +	u32 val;
>> +
>> +	if (sdev->is_fiber) {
>> +		/* We've got a fiber gigabit interface, and register 4 is
>> +		 * different in fiber mode than in copper mode.
>> +		 */
>> +		/* advertise FD only @1000 Mb */
>> +		val = MII_ADVERTISE << 16 | SLIC_PAR_ADV1000XFD |
>> +		      SLIC_PAR_ASYMPAUSE_FIBER;
>> +		/* enable PAUSE frames */
>> +		slic_write(sdev, SLIC_REG_WPHY, val);
>> +		/* reset phy, enable auto-neg  */
>> +		val = MII_BMCR << 16 | SLIC_PCR_RESET | SLIC_PCR_AUTONEG |
>> +		      SLIC_PCR_AUTONEG_RST;
>> +		slic_write(sdev, SLIC_REG_WPHY, val);
>> +	} else {	/* copper gigabit */
>> +		/* We've got a copper gigabit interface, and register 4 is
>> +		 * different in copper mode than in fiber mode.
>> +		 */
>> +		/* advertise 10/100 Mb modes   */
>> +		val = MII_ADVERTISE << 16 | SLIC_PAR_ADV100FD |
>> +		      SLIC_PAR_ADV100HD | SLIC_PAR_ADV10FD | SLIC_PAR_ADV10HD;
>> +		/* enable PAUSE frames  */
>> +		val |= SLIC_PAR_ASYMPAUSE;
>> +		/* required by the Cicada PHY  */
>> +		val |= SLIC_PAR_802_3;
>> +		slic_write(sdev, SLIC_REG_WPHY, val);
>> +
>> +		/* advertise FD only @1000 Mb  */
>> +		val = MII_CTRL1000 << 16 | SLIC_PGC_ADV1000FD;
>> +		slic_write(sdev, SLIC_REG_WPHY, val);
>> +
>> +		if (subid != PCI_SUBDEVICE_ID_ALACRITECH_CICADA) {
>> +			 /* if a Marvell PHY enable auto crossover */
>> +			val = SLIC_MIICR_REG_16 | SLIC_MRV_REG16_XOVERON;
>> +			slic_write(sdev, SLIC_REG_WPHY, val);
>> +
>> +			/* reset phy, enable auto-neg  */
>> +			val = MII_BMCR << 16 | SLIC_PCR_RESET |
>> +			      SLIC_PCR_AUTONEG | SLIC_PCR_AUTONEG_RST;
>> +			slic_write(sdev, SLIC_REG_WPHY, val);
>> +		} else {
>> +			/* enable and restart auto-neg (don't reset)  */
>> +			val = MII_BMCR << 16 | SLIC_PCR_AUTONEG |
>> +			      SLIC_PCR_AUTONEG_RST;
>> +			slic_write(sdev, SLIC_REG_WPHY, val);
>> +		}
>> +	}
>> +	sdev->autoneg = true;
>> +}
> 
> Could this be pulled out into a standard PHY driver? All the SLIC
> SLIC_PCR_ defines seems to be the same as those in mii.h. This could
> be a standard PHY hidden behind a single register.
> 
>    Andrew

You are right, the driver should really use the defines in mii.h. I will fix this in
 a v2.

Concerning the use of the PHY API: What would be the advantage of using it? Note that the
 phy is always internal and not interchangeable. Is not the interchangeability of PHYs
the main reason for using this API?

Regards,
Lino

[toc] | [prev] | [next] | [standalone]

#1523061 — Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver

On 11/15/2016 12:46 PM, Lino Sanfilippo wrote:
>> Could this be pulled out into a standard PHY driver? All the SLIC
>> SLIC_PCR_ defines seems to be the same as those in mii.h. This could
>> be a standard PHY hidden behind a single register.
>>
>>    Andrew
> 
> You are right, the driver should really use the defines in mii.h. I will fix this in
>  a v2.
> 
> Concerning the use of the PHY API: What would be the advantage of using it? Note that the
>  phy is always internal and not interchangeable. Is not the interchangeability of PHYs
> the main reason for using this API?

Not reinventing the wheel primarily, while PHYLIB also solves the plug &
play aspect of external PHYs, it also solves the basic link management,
and consistent and reasonably well defined interface to user-space and
drivers (statistics reporting, link, auto-negotiation, EEE etc.).
-- 
Florian

[toc] | [prev] | [next] | [standalone]

#1523071 — Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver

Hi,

On 15.11.2016 21:54, Florian Fainelli wrote:
> On 11/15/2016 12:46 PM, Lino Sanfilippo wrote:
>>> Could this be pulled out into a standard PHY driver? All the SLIC
>>> SLIC_PCR_ defines seems to be the same as those in mii.h. This could
>>> be a standard PHY hidden behind a single register.
>>>
>>>    Andrew
>> 
>> You are right, the driver should really use the defines in mii.h. I will fix this in
>>  a v2.
>> 
>> Concerning the use of the PHY API: What would be the advantage of using it? Note that the
>>  phy is always internal and not interchangeable. Is not the interchangeability of PHYs
>> the main reason for using this API?
> 
> Not reinventing the wheel primarily, while PHYLIB also solves the plug &
> play aspect of external PHYs, it also solves the basic link management,
> and consistent and reasonably well defined interface to user-space and
> drivers (statistics reporting, link, auto-negotiation, EEE etc.).
> 

Sure I see this point. But currently all the driver does concerning the phy is to
configure it for auto negotiation when the interface is brought up, nothing else.

The link state is retrieved by a command to the application processor that is running 
on the network card. Also the register to set the phy configuration is write-only, so
it is not even possible to do the usual mdio bit-banging in the Phy read() and write()
functions (however there seems to be another application processor command reserved 
for retrieving the PHY settings, but I have not tried it yet). 
Please also note that I do not have any datasheets or other documentation for the hardware, 
all I have as a reference is the driver code in staging. So I do not know which 
PHYs are actually used (the comments in the code mention Marvell and Cicada but this is
not very specific).

Regards,
Lino

[toc] | [prev] | [next] | [standalone]

#1523079 — Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver

> The link state is retrieved by a command to the application processor that is running 
> on the network card. Also the register to set the phy configuration is write-only, so
> it is not even possible to do the usual mdio bit-banging in the Phy read() and write()
> functions (however there seems to be another application processor command reserved 
> for retrieving the PHY settings, but I have not tried it yet). 

>> +  			val = MII_BMCR << 16 | SLIC_PCR_AUTONEG |
>> +		     	         SLIC_PCR_AUTONEG_RST;
>> +			slic_write(sdev, SLIC_REG_WPHY, val);

This actually looks a lot like an MDIO write operation. The upper 16
bits are the register, and the lower 16 bits are the data. What you
don't have is the address. But maybe it is limited to one address.

If the processor command reserved for read works in a similar way, you
have enough to do an MDIO bus.

> Please also note that I do not have any datasheets or other documentation for the hardware, 
> all I have as a reference is the driver code in staging. So I do not know which 
> PHYs are actually used (the comments in the code mention Marvell and Cicada but this is
> not very specific).

If you can get the read working look at registers 2 and 3. Compare
what you get with the values at the end of marvell.c.

     Andrew

[toc] | [prev] | [next] | [standalone]

#1523101 — Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver

On 11/15/2016 02:34 PM, Lino Sanfilippo wrote:
> On 15.11.2016 22:59, Andrew Lunn wrote:
>>> The link state is retrieved by a command to the application processor that is running 
>>> on the network card. Also the register to set the phy configuration is write-only, so
>>> it is not even possible to do the usual mdio bit-banging in the Phy read() and write()
>>> functions (however there seems to be another application processor command reserved 
>>> for retrieving the PHY settings, but I have not tried it yet). 
>>
>>>> +  			val = MII_BMCR << 16 | SLIC_PCR_AUTONEG |
>>>> +		     	         SLIC_PCR_AUTONEG_RST;
>>>> +			slic_write(sdev, SLIC_REG_WPHY, val);
>>
>> This actually looks a lot like an MDIO write operation. The upper 16
>> bits are the register, and the lower 16 bits are the data. What you
>> don't have is the address. But maybe it is limited to one address.
>>
>> If the processor command reserved for read works in a similar way, you
>> have enough to do an MDIO bus.
>>
> 
> Ok, I will give it a try. Reading values via the application processor
> is a bit awkward though, since it requires an address to a dma area as part of
> the command and then the AP informs the driver via irq that the dma memory has 
> been written. So probably the irq handler will have to set some flag and
> the mdio_read() function will have to poll for that flag in place of doing 
> bit-banging a register. 

That's a bit unusual compared to typical controllers that are usually
memory-mapped and that you can either write to, read/poll to know about
completion. I suppose that you could still have a mdiobus implementation
that is able to read to/from PHYs by submitting a command to the AP,
wait on a completion structure, and have the interrupt handler do the
completion of the command?
-- 
Florian

[toc] | [prev] | [next] | [standalone]

#1523113 — Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver

On 15.11.2016 23:39, Florian Fainelli wrote:
> On 11/15/2016 02:34 PM, Lino Sanfilippo wrote:
>> On 15.11.2016 22:59, Andrew Lunn wrote:
>>>> The link state is retrieved by a command to the application processor that is running 
>>>> on the network card. Also the register to set the phy configuration is write-only, so
>>>> it is not even possible to do the usual mdio bit-banging in the Phy read() and write()
>>>> functions (however there seems to be another application processor command reserved 
>>>> for retrieving the PHY settings, but I have not tried it yet). 
>>>
>>>>> +  			val = MII_BMCR << 16 | SLIC_PCR_AUTONEG |
>>>>> +		     	         SLIC_PCR_AUTONEG_RST;
>>>>> +			slic_write(sdev, SLIC_REG_WPHY, val);
>>>
>>> This actually looks a lot like an MDIO write operation. The upper 16
>>> bits are the register, and the lower 16 bits are the data. What you
>>> don't have is the address. But maybe it is limited to one address.
>>>
>>> If the processor command reserved for read works in a similar way, you
>>> have enough to do an MDIO bus.
>>>
>> 
>> Ok, I will give it a try. Reading values via the application processor
>> is a bit awkward though, since it requires an address to a dma area as part of
>> the command and then the AP informs the driver via irq that the dma memory has 
>> been written. So probably the irq handler will have to set some flag and
>> the mdio_read() function will have to poll for that flag in place of doing 
>> bit-banging a register. 
> 
> That's a bit unusual compared to typical controllers that are usually
> memory-mapped and that you can either write to, read/poll to know about
> completion. I suppose that you could still have a mdiobus implementation
> that is able to read to/from PHYs by submitting a command to the AP,
> wait on a completion structure, and have the interrupt handler do the
> completion of the command?
> 

Thats essentially what I meant by setting a flag in the irq handler. The mdio
function would have to check somehow if the irq has been fired (be it by means
of a flag or a completion that is set by the irq handler and checked by the 
mdio function). So I agree that it should work (if reading via the AP command
is actually possible).

Lino 

[toc] | [prev] | [next] | [standalone]

#1523115 — Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver

> >>>>> +  			val = MII_BMCR << 16 | SLIC_PCR_AUTONEG |
> >>>>> +		     	         SLIC_PCR_AUTONEG_RST;
> >>>>> +			slic_write(sdev, SLIC_REG_WPHY, val);

> Thats essentially what I meant by setting a flag in the irq handler. The mdio
> function would have to check somehow if the irq has been fired (be it by means
> of a flag or a completion that is set by the irq handler and checked by the 
> mdio function). So I agree that it should work (if reading via the AP command
> is actually possible).

It seems odd you have a nice simple way to do writes, but reads are
very complex. There might be a simple read method hiding somewhere.

     Andrew

[toc] | [prev] | [next] | [standalone]

#1523119 — Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver

On 16.11.2016 00:03, Andrew Lunn wrote:
>> >>>>> +  			val = MII_BMCR << 16 | SLIC_PCR_AUTONEG |
>> >>>>> +		     	         SLIC_PCR_AUTONEG_RST;
>> >>>>> +			slic_write(sdev, SLIC_REG_WPHY, val);
> 
>> Thats essentially what I meant by setting a flag in the irq handler. The mdio
>> function would have to check somehow if the irq has been fired (be it by means
>> of a flag or a completion that is set by the irq handler and checked by the 
>> mdio function). So I agree that it should work (if reading via the AP command
>> is actually possible).
> 
> It seems odd you have a nice simple way to do writes, but reads are
> very complex. There might be a simple read method hiding somewhere.
> 
>      Andrew
> 

I agree, it IS odd :). 
But concerning reading the phy this is all I can see in the original source code:

http://lxr.free-electrons.com/source/drivers/staging/slicoss/slichw.h#L516

I strongly suspect that "RPHY" stand for "read phy". The only one who may
know for sure if there is another/better way is Christopher Harrer. He is also on CC
but I am not sure if he actually follows this discussion.

Lino

[toc] | [prev] | [next] | [standalone]

#1523103 — Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver

On 15.11.2016 22:59, Andrew Lunn wrote:
>> The link state is retrieved by a command to the application processor that is running 
>> on the network card. Also the register to set the phy configuration is write-only, so
>> it is not even possible to do the usual mdio bit-banging in the Phy read() and write()
>> functions (however there seems to be another application processor command reserved 
>> for retrieving the PHY settings, but I have not tried it yet). 
> 
>>> +  			val = MII_BMCR << 16 | SLIC_PCR_AUTONEG |
>>> +		     	         SLIC_PCR_AUTONEG_RST;
>>> +			slic_write(sdev, SLIC_REG_WPHY, val);
> 
> This actually looks a lot like an MDIO write operation. The upper 16
> bits are the register, and the lower 16 bits are the data. What you
> don't have is the address. But maybe it is limited to one address.
> 
> If the processor command reserved for read works in a similar way, you
> have enough to do an MDIO bus.
> 

Ok, I will give it a try. Reading values via the application processor
is a bit awkward though, since it requires an address to a dma area as part of
the command and then the AP informs the driver via irq that the dma memory has 
been written. So probably the irq handler will have to set some flag and
the mdio_read() function will have to poll for that flag in place of doing 
bit-banging a register. 

> If you can get the read working look at registers 2 and 3. Compare
> what you get with the values at the end of marvell.c.
> 

Will do, thank you!

Lino

[toc] | [prev] | [next] | [standalone]

#1529247 — Aw: Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver

Hi Andrew, Hi Florian

> Gesendet: Dienstag, 15. November 2016 um 23:34 Uhr
> Von: "Lino Sanfilippo" <LinoSanfilippo@gmx.de>
> An: "Andrew Lunn" <andrew@lunn.ch>
> Cc: "Florian Fainelli" <f.fainelli@gmail.com>, davem@davemloft.net, charrer@alacritech.com, liodot@gmail.com, gregkh@linuxfoundation.org, devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org
> Betreff: Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver
>
> On 15.11.2016 22:59, Andrew Lunn wrote:
> >> The link state is retrieved by a command to the application processor that is running 
> >> on the network card. Also the register to set the phy configuration is write-only, so
> >> it is not even possible to do the usual mdio bit-banging in the Phy read() and write()
> >> functions (however there seems to be another application processor command reserved 
> >> for retrieving the PHY settings, but I have not tried it yet). 
> > 
> >>> +  			val = MII_BMCR << 16 | SLIC_PCR_AUTONEG |
> >>> +		     	         SLIC_PCR_AUTONEG_RST;
> >>> +			slic_write(sdev, SLIC_REG_WPHY, val);
> > 
> > This actually looks a lot like an MDIO write operation. The upper 16
> > bits are the register, and the lower 16 bits are the data. What you
> > don't have is the address. But maybe it is limited to one address.
> > 
> > If the processor command reserved for read works in a similar way, you
> > have enough to do an MDIO bus.
> > 
> 
> Ok, I will give it a try. Reading values via the application processor
> is a bit awkward though, since it requires an address to a dma area as part of
> the command and then the AP informs the driver via irq that the dma memory has 
> been written. So probably the irq handler will have to set some flag and
> the mdio_read() function will have to poll for that flag in place of doing 
> bit-banging a register. 
> 
> > If you can get the read working look at registers 2 and 3. Compare
> > what you get with the values at the end of marvell.c.
> > 
> 
> Will do, thank you!
> 

unfortunately I was not able to figure out how to read the phy. My hope was to find
a hidden register that I can use to request the phy status from the cards utility processor.
I actually found two more registers that seem to be reserved for the communication
with the UP. At least they cause the UPR irq to be fired but there is no data written to
the provided dma address. I assume that they are not meant to be used for the this purpose.
So I am afraid I am not able to use the phy API in this driver for now. 
However I will send a v2 of the driver shortly that will include the other
changes suggested by Andrew along with some further small improvements.
Thanks for your help so far!

Regards,
Lino

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web