Porting ethernet over spi driver

Porting ethernet over spi driver

[Stefan Wahren]

Hi,

i'm trying to port a ethernet over spi driver to current mainline, which 
originally based on kernel 2.6.

Now i'm searching for some guidelines, checklists, common pitfalls or 
just hints about that.

Is there something about that, which is up to date?

Is there a list or something of legacy function, which shouldn't be used 
anymore?

Are there any new must have features?

Is there a good reference implementation for ethernet over spi?

Thanks in advance.

Kind regards
Stefan Wahren

Re: Porting ethernet over spi driver

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1964 bytes --]

On Fri, 2014-04-18 at 11:17 +0200, Stefan Wahren wrote:
> Hi,
> 
> i'm trying to port a ethernet over spi driver to current mainline, which 
> originally based on kernel 2.6.
> 
> Now i'm searching for some guidelines, checklists, common pitfalls or 
> just hints about that.
> 
> Is there something about that, which is up to date?

I don't think there is.

> Is there a list or something of legacy function, which shouldn't be used 
> anymore?

No but the compiler should tell you about functions that were removed!

> Are there any new must have features?

You don't say which 2.6.y version you started with, but API changes I
can think of that come up when backporting are:

- 2.6.24: NAPI now involves a napi_struct rather than fields in
net_device
- 2.6.29: net device operation pointers moved into struct net_device_ops
- 2.6.29: GRO added (can be useful if you have RX checksum offload)
- 2.6.36: ndo_get_stats64 added as alternative to ndo_get_stats
- 2.6.37: vlan_hwaccel_* functions removed; the driver must attach the
tag and call the regular receive function
- 2.6.39: ethtool feature setting replaced by net device operations
ndo_fix_features & ndo_set_features
- 3.2: ndo_set_multicast_list and ndo_set_rx_mode operations merged
- 3.10: VLAN functions and feature flags changed to allow for both
802.1q and 802.1ad tags

Most of the interesting new features are related to multiqueue and
protocol offloads that I wouldn't expect to exist in an SPI-attached
Ethernet controller.  There are a few other things you can now expose if
the hardware supports it:

- MDI(-X) status and control (through ethtool)
- EEE status and control (through ethtool)
- Feature flags to disable Ethernet FCS insertion, validation and
stripping

> Is there a good reference implementation for ethernet over spi?

Don't know.

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: Porting ethernet over spi driver

[Fabio Estevam]

On Fri, Apr 18, 2014 at 6:17 AM, Stefan Wahren <info@lategoodbye.de> wrote:
> Hi,
>
> i'm trying to port a ethernet over spi driver to current mainline, which
> originally based on kernel 2.6.
>
> Now i'm searching for some guidelines, checklists, common pitfalls or just
> hints about that.
>
> Is there something about that, which is up to date?
>
> Is there a list or something of legacy function, which shouldn't be used
> anymore?
>
> Are there any new must have features?
>
> Is there a good reference implementation for ethernet over spi?

Not sure if it is a good reference, but the only one I am aware of is this one:
drivers/net/ethernet/microchip/enc28j60.c

Regards,

Fabio Estevam

Re: Porting ethernet over spi driver

[Stefan Wahren]

Am 22.04.2014 04:32, schrieb Fabio Estevam:
> On Fri, Apr 18, 2014 at 6:17 AM, Stefan Wahren <info@lategoodbye.de> wrote:
>> Hi,
>>
>> i'm trying to port a ethernet over spi driver to current mainline, which
>> originally based on kernel 2.6.
>>
>> Now i'm searching for some guidelines, checklists, common pitfalls or just
>> hints about that.
>>
>> Is there something about that, which is up to date?
>>
>> Is there a list or something of legacy function, which shouldn't be used
>> anymore?
>>
>> Are there any new must have features?
>>
>> Is there a good reference implementation for ethernet over spi?
> Not sure if it is a good reference, but the only one I am aware of is this one:
> drivers/net/ethernet/microchip/enc28j60.c

Yes, i already found this one and also:
drivers/net/ethernet/micrel/ks8851.c

Unfortunately neither of them have device tree support, so i took some
parts from here:
drivers/net/ethernet/freescale/fec_main.c

>
> Regards,
>
> Fabio Estevam
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

BR Stefan Wahren

Re: Porting ethernet over spi driver

[Stefan Wahren]

Am 22.04.2014 04:22, schrieb Ben Hutchings:
> On Fri, 2014-04-18 at 11:17 +0200, Stefan Wahren wrote:
>> Hi,
>>
>> i'm trying to port a ethernet over spi driver to current mainline, which 
>> originally based on kernel 2.6.
>>
>> Now i'm searching for some guidelines, checklists, common pitfalls or 
>> just hints about that.
>>
>> Is there something about that, which is up to date?
> I don't think there is.
>
>> Is there a list or something of legacy function, which shouldn't be used 
>> anymore?
> No but the compiler should tell you about functions that were removed!
>
>> Are there any new must have features?
> You don't say which 2.6.y version you started with, but API changes I
> can think of that come up when backporting are:

Sorry for being so imprecise, it is 2.6.35.

> - 2.6.24: NAPI now involves a napi_struct rather than fields in
> net_device
> - 2.6.29: net device operation pointers moved into struct net_device_ops
> - 2.6.29: GRO added (can be useful if you have RX checksum offload)
> - 2.6.36: ndo_get_stats64 added as alternative to ndo_get_stats
> - 2.6.37: vlan_hwaccel_* functions removed; the driver must attach the
> tag and call the regular receive function
> - 2.6.39: ethtool feature setting replaced by net device operations
> ndo_fix_features & ndo_set_features
> - 3.2: ndo_set_multicast_list and ndo_set_rx_mode operations merged
> - 3.10: VLAN functions and feature flags changed to allow for both
> 802.1q and 802.1ad tags

Thank you for this list.

> Most of the interesting new features are related to multiqueue and
> protocol offloads that I wouldn't expect to exist in an SPI-attached
> Ethernet controller.  

You are right.

Btw, is simple power management (suspend, resume) a must-have feature?

BR Stefan Wahren

Re: Porting ethernet over spi driver

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 632 bytes --]

On Tue, 2014-04-22 at 12:02 +0200, Stefan Wahren wrote:
> Am 22.04.2014 04:22, schrieb Ben Hutchings:
[..]
> > Most of the interesting new features are related to multiqueue and
> > protocol offloads that I wouldn't expect to exist in an SPI-attached
> > Ethernet controller.  
> 
> You are right.
> 
> Btw, is simple power management (suspend, resume) a must-have feature?

If you're intending to get the driver in-tree, I don't think those are
an absolute requirement but I would certainly recommend implementing
them.

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: Porting ethernet over spi driver (powerline device)

[Stefan Wahren]

Am 22.04.2014 17:21, schrieb Ben Hutchings:
> On Tue, 2014-04-22 at 12:02 +0200, Stefan Wahren wrote:
>> Am 22.04.2014 04:22, schrieb Ben Hutchings:
> [..]
>>> Most of the interesting new features are related to multiqueue and
>>> protocol offloads that I wouldn't expect to exist in an SPI-attached
>>> Ethernet controller.  
>> You are right.
>>
>> Btw, is simple power management (suspend, resume) a must-have feature?
> If you're intending to get the driver in-tree, I don't think those are
> an absolute requirement but I would certainly recommend implementing
> them.
>
> Ben.
>

Yes, that's my intension. The QCA7000 isn't a typical ethernet over spi
device, it's a serial-to-powerline bridge. Acting like a ethernet over
spi device simplifies the implementation. This leads to an important
question.

Should the QCA7000 be handled strict as an ethernet device or a little
bit more distinguished as a powerline device?

I think that would have influence on the following aspects:

* Interface naming scheme in user space

Currently the interface has the interface pattern qca%d instead of
eth%d. I think this won't be acceptable for in-tree. But the interface
pattern pwl%d for powerline could also be possible.

* Node name in devicetree sources

Currently the node is named as qca7000, but from my understanding it's
should be ethernet or powerline.

* Driver directory in kernel sources

In my development i store the sources under drivers/net/ethernet. But
for in-tree i see the following candidates:

drivers/net/ethernet/qca/
drivers/net/ethernet/qualcomm/
drivers/net/powerline/qca/

Any suggestions?

Kind regards
Stefan Wahren

Re: Porting ethernet over spi driver (powerline device)

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1293 bytes --]

On Fri, 2014-04-25 at 09:24 +0200, Stefan Wahren wrote:
> Am 22.04.2014 17:21, schrieb Ben Hutchings:
> > On Tue, 2014-04-22 at 12:02 +0200, Stefan Wahren wrote:
> >> Am 22.04.2014 04:22, schrieb Ben Hutchings:
> > [..]
> >>> Most of the interesting new features are related to multiqueue and
> >>> protocol offloads that I wouldn't expect to exist in an SPI-attached
> >>> Ethernet controller.  
> >> You are right.
> >>
> >> Btw, is simple power management (suspend, resume) a must-have feature?
> > If you're intending to get the driver in-tree, I don't think those are
> > an absolute requirement but I would certainly recommend implementing
> > them.
> >
> > Ben.
> >
> 
> Yes, that's my intension. The QCA7000 isn't a typical ethernet over spi
> device, it's a serial-to-powerline bridge. Acting like a ethernet over
> spi device simplifies the implementation. This leads to an important
> question.
> 
> Should the QCA7000 be handled strict as an ethernet device or a little
> bit more distinguished as a powerline device?
[...]

If it uses Ethernet framing, supports multicast/broadcast, etc. then I
don't think there's any need to distinguish it.

Ben.

-- 
Ben Hutchings
The most exhausting thing in life is being insincere. - Anne Morrow Lindberg

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]