Staging: cpc-usb CAN driver TODO list

Staging: cpc-usb CAN driver TODO list

[Oliver Hartkopp]

Hello Greg and Sebastian,

i just looked around in the linux-next tree for the cpc-usb driver.

http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=tree;f=drivers/staging/cpc-usb;hb=HEAD

IMHO the sja2m16c* files are completely obsolete as the setting of the CAN
bittimings needs to be done by separate functions (one for the SJA1000 and one
for the M16C). For both of them a separate can_bittiming_const is needed, like
it is defined in drivers/net/can/sja1000/sja1000.c:

static struct can_bittiming_const sja1000_bittiming_const = {
	.name = DRV_NAME,
	.tseg1_min = 1,
	.tseg1_max = 16,
	.tseg2_min = 1,
	.tseg2_max = 8,
	.sjw_max = 4,
	.brp_min = 1,
	.brp_max = 64,
	.brp_inc = 1,
};

Also a separate function to determine the register values from the calculated
bittiming values is needed for both hardware types (SJA1000(LPC2119)/M16C) of
the cpc-usb. How this is done can be checked in linux/drivers/net/can/* or in
the source code of upcoming drivers in

http://svn.berlios.de/svnroot/repos/socketcan/trunk/kernel/2.6/drivers/net/can/

I wondered about the following items in the TODO list:

	- tie into CAN socket interfaces if possible
	- figure out sane userspace api

This is definitely a no go! IMO there is no real alternative to make this
cpc-usb driver a real CAN network driver.

The CAN driver interface has a sane configuration API via netlink and brings
everything to configure CAN specific bitrates, error counters, recovery, etc.

The missing thing is to connect the usb-device to a netdevice (can%d), remove
all the chardev file-I/O stuff and adapt the cpc-usb to use the
bitrate-settings, error counters and whatever - which is already well-defined
and provided by the CAN driver interface library contributed by Wolfgang
Grandegger ( drivers/net/can/dev.c and include/linux/can/[dev.h|netlink.h] ).

Unfortunately i'm not an expert in USB programming and i don't have that
hardware - but if you need some ideas from the CAN driver peoples like
Wolfgang, questions are always welcome, e.g. on the socketcan-core ML:

http://developer.berlios.de/projects/socketcan

I don't think it's a big effort for people that know USB & CAN to clean up the
cpc-usb and make it a slim CAN netdev. Believe me, it took years to figure out
a sane userspace api for CAN interfaces, which is now provided by the netlink
interface ;-)

Best regards,
Oliver

Re: Staging: cpc-usb CAN driver TODO list

[Sebastian Haas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Oliver,

I'm not yet sure how to actually start the development. There is so much
to do, and I've not much time to spend on this, unfortunately. Because
of this I can't rewrite the whole driver on my own in order to get a
Socket-CAN driver but I can provide support, review patches, rent
devices and make tests here.

Oliver, you are not familiar with USB and I'm not very familiar with CAN
netdev internals, why not combining these twos. You are writing the CAN
part and write the USB part.

I'll also write a specification which contains any information you need
to develop a CAN driver for the device (commands, sequences, error
handling).

- --
Mit freundlichen Gruessen/Best Regards,

Sebastian Haas
Software Entwicklung/Software Development

Phone: +49-9451-9432-22
Fax  : +49-9451-9432-12
Email: haas@ems-wuensche.com
Web  : www.ems-wuensche.com


Oliver Hartkopp schrieb:
> Hello Greg and Sebastian,
> 
> i just looked around in the linux-next tree for the cpc-usb driver.
> 
> http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=tree;f=drivers/staging/cpc-usb;hb=HEAD
> 
> IMHO the sja2m16c* files are completely obsolete as the setting of the CAN
> bittimings needs to be done by separate functions (one for the SJA1000 and one
> for the M16C). For both of them a separate can_bittiming_const is needed, like
> it is defined in drivers/net/can/sja1000/sja1000.c:
> 
> static struct can_bittiming_const sja1000_bittiming_const = {
> 	.name = DRV_NAME,
> 	.tseg1_min = 1,
> 	.tseg1_max = 16,
> 	.tseg2_min = 1,
> 	.tseg2_max = 8,
> 	.sjw_max = 4,
> 	.brp_min = 1,
> 	.brp_max = 64,
> 	.brp_inc = 1,
> };
> 
> Also a separate function to determine the register values from the calculated
> bittiming values is needed for both hardware types (SJA1000(LPC2119)/M16C) of
> the cpc-usb. How this is done can be checked in linux/drivers/net/can/* or in
> the source code of upcoming drivers in
> 
> http://svn.berlios.de/svnroot/repos/socketcan/trunk/kernel/2.6/drivers/net/can/
> 
> I wondered about the following items in the TODO list:
> 
> 	- tie into CAN socket interfaces if possible
> 	- figure out sane userspace api
> 
> This is definitely a no go! IMO there is no real alternative to make this
> cpc-usb driver a real CAN network driver.
> 
> The CAN driver interface has a sane configuration API via netlink and brings
> everything to configure CAN specific bitrates, error counters, recovery, etc.
> 
> The missing thing is to connect the usb-device to a netdevice (can%d), remove
> all the chardev file-I/O stuff and adapt the cpc-usb to use the
> bitrate-settings, error counters and whatever - which is already well-defined
> and provided by the CAN driver interface library contributed by Wolfgang
> Grandegger ( drivers/net/can/dev.c and include/linux/can/[dev.h|netlink.h] ).
> 
> Unfortunately i'm not an expert in USB programming and i don't have that
> hardware - but if you need some ideas from the CAN driver peoples like
> Wolfgang, questions are always welcome, e.g. on the socketcan-core ML:
> 
> http://developer.berlios.de/projects/socketcan
> 
> I don't think it's a big effort for people that know USB & CAN to clean up the
> cpc-usb and make it a slim CAN netdev. Believe me, it took years to figure out
> a sane userspace api for CAN interfaces, which is now provided by the netlink
> interface ;-)
> 
> Best regards,
> Oliver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqkoJoACgkQpqRB8PJG7XxF/ACgjza8eG3U+ypyA0qCj60wDhmN
8oQAnir3YRmXU7CTlaKXpbecPyitJHqX
=hyD4
-----END PGP SIGNATURE-----
-- 
EMS Dr. Thomas Wuensche e.K.
Sonnenhang 3
85304 Ilmmuenster
HRA Neuburg a.d. Donau, HR-Nr. 70.106
Phone: +49-8441-490260
Fax  : +49-8441-81860
http://www.ems-wuensche.com

Re: Staging: cpc-usb CAN driver TODO list

[Wolfgang Grandegger]

Hi Sebastian,

On 09/07/2009 07:56 AM, Sebastian Haas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Oliver,
>
> I'm not yet sure how to actually start the development. There is so much
> to do, and I've not much time to spend on this, unfortunately. Because
> of this I can't rewrite the whole driver on my own in order to get a
> Socket-CAN driver but I can provide support, review patches, rent
> devices and make tests here.
>
> Oliver, you are not familiar with USB and I'm not very familiar with CAN
> netdev internals, why not combining these twos. You are writing the CAN
> part and write the USB part.
>
> I'll also write a specification which contains any information you need
> to develop a CAN driver for the device (commands, sequences, error
> handling).

Alternatively, EMS Wuensche could also hire an expert doing the job ;-). 
Note that we do a lot of Socket-CAN work in our free time, which is a 
limited resource. Progress depends on funding to a certain extend.

Wolfgang.

Re: Staging: cpc-usb CAN driver TODO list

[Sebastian Haas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wolfgang,

Wolfgang Grandegger schrieb:
> Hi Sebastian,
> 
> On 09/07/2009 07:56 AM, Sebastian Haas wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Oliver,
>>
>> I'm not yet sure how to actually start the development. There is so much
>> to do, and I've not much time to spend on this, unfortunately. Because
>> of this I can't rewrite the whole driver on my own in order to get a
>> Socket-CAN driver but I can provide support, review patches, rent
>> devices and make tests here.
>>
>> Oliver, you are not familiar with USB and I'm not very familiar with CAN
>> netdev internals, why not combining these twos. You are writing the CAN
>> part and write the USB part.
>>
>> I'll also write a specification which contains any information you need
>> to develop a CAN driver for the device (commands, sequences, error
>> handling).
> 
> Alternatively, EMS Wuensche could also hire an expert doing the job ;-).
> Note that we do a lot of Socket-CAN work in our free time, which is a
> limited resource. Progress depends on funding to a certain extend.
Money is also a limited resource. ;-)

Let's become serious again, I know and respect that many of Socket-CAN
and the Staging developers spend their free time working on it. We will
of course work on the driver, but since we've not much time it may take
several months. If someone wants to help, we would be very glad and
happy to support the person as far as we can with devices, answers and
tests.

Sebastian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqkveMACgkQpqRB8PJG7Xyu3ACeMhuOoVMQ043tib6HH9NhQPBw
uTQAnjCFIqzv6dQl9iRiWopVYWAirdKb
=MRvL
-----END PGP SIGNATURE-----
-- 
EMS Dr. Thomas Wuensche e.K.
Sonnenhang 3
85304 Ilmmuenster
HRA Neuburg a.d. Donau, HR-Nr. 70.106
Phone: +49-8441-490260
Fax  : +49-8441-81860
http://www.ems-wuensche.com

Re: Staging: cpc-usb CAN driver TODO list

[Wolfgang Grandegger]

On 09/07/2009 10:01 AM, Sebastian Haas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Wolfgang,
>
> Wolfgang Grandegger schrieb:
>> Hi Sebastian,
>>
>> On 09/07/2009 07:56 AM, Sebastian Haas wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Oliver,
>>>
>>> I'm not yet sure how to actually start the development. There is so much
>>> to do, and I've not much time to spend on this, unfortunately. Because
>>> of this I can't rewrite the whole driver on my own in order to get a
>>> Socket-CAN driver but I can provide support, review patches, rent
>>> devices and make tests here.
>>>
>>> Oliver, you are not familiar with USB and I'm not very familiar with CAN
>>> netdev internals, why not combining these twos. You are writing the CAN
>>> part and write the USB part.
>>>
>>> I'll also write a specification which contains any information you need
>>> to develop a CAN driver for the device (commands, sequences, error
>>> handling).
>>
>> Alternatively, EMS Wuensche could also hire an expert doing the job ;-).
>> Note that we do a lot of Socket-CAN work in our free time, which is a
>> limited resource. Progress depends on funding to a certain extend.
> Money is also a limited resource. ;-)
>
> Let's become serious again, I know and respect that many of Socket-CAN
> and the Staging developers spend their free time working on it. We will
> of course work on the driver, but since we've not much time it may take
> several months. If someone wants to help, we would be very glad and
> happy to support the person as far as we can with devices, answers and
> tests.

OK, no problem. I really appreciate your support for Socket-CAN so far.

Thanks,

Wolfgang.

Re: Staging: cpc-usb CAN driver TODO list

[Oliver Hartkopp]

Wolfgang Grandegger wrote:
> On 09/07/2009 10:01 AM, Sebastian Haas wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Wolfgang,
>>
>> Wolfgang Grandegger schrieb:
>>> Hi Sebastian,
>>>
>>> On 09/07/2009 07:56 AM, Sebastian Haas wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Oliver,
>>>>
>>>> I'm not yet sure how to actually start the development. There is so
>>>> much
>>>> to do, and I've not much time to spend on this, unfortunately. Because
>>>> of this I can't rewrite the whole driver on my own in order to get a
>>>> Socket-CAN driver but I can provide support, review patches, rent
>>>> devices and make tests here.
>>>>
>>>> Oliver, you are not familiar with USB and I'm not very familiar with
>>>> CAN
>>>> netdev internals, why not combining these twos. You are writing the CAN
>>>> part and write the USB part.
>>>>
>>>> I'll also write a specification which contains any information you need
>>>> to develop a CAN driver for the device (commands, sequences, error
>>>> handling).
>>>
>>> Alternatively, EMS Wuensche could also hire an expert doing the job ;-).
>>> Note that we do a lot of Socket-CAN work in our free time, which is a
>>> limited resource. Progress depends on funding to a certain extend.
>> Money is also a limited resource. ;-)
>>
>> Let's become serious again, I know and respect that many of Socket-CAN
>> and the Staging developers spend their free time working on it. We will
>> of course work on the driver, but since we've not much time it may take
>> several months. If someone wants to help, we would be very glad and
>> happy to support the person as far as we can with devices, answers and
>> tests.
> 
> OK, no problem. I really appreciate your support for Socket-CAN so far.

Indeed. Me too.

I tried to take a second look into cpc-usb_drv.c and i would suggest to remove
all the procfs and the chardev stuff and then create a CAN netdev when you
identified an USB node analogue to

        /* Detect available channels */
        for (i = 0; i < EMS_PCMCIA_MAX_CHAN; i++) {
                dev = alloc_sja1000dev(0);
                if (dev == NULL) {
                        err = -ENOMEM;
                        goto failure_cleanup;
                }

                card->net_dev[i] = dev;
                priv = netdev_priv(dev);
                priv->priv = card;
                SET_NETDEV_DEV(dev, &pdev->dev);

as you know from your ems_pcmcia.c driver

and

struct net_device *alloc_sja1000dev(int sizeof_priv)
{
        struct net_device *dev;
        struct sja1000_priv *priv;

        dev = alloc_candev(sizeof(struct sja1000_priv) + sizeof_priv);
        if (!dev)
                return NULL;

        priv = netdev_priv(dev);

        priv->dev = dev;
        priv->can.bittiming_const = &sja1000_bittiming_const;
        priv->can.do_set_bittiming = sja1000_set_bittiming;
        priv->can.do_set_mode = sja1000_set_mode;

        if (sizeof_priv)
                priv->priv = (void *)priv + sizeof(struct sja1000_priv);

        return dev;
}

as you know from the sja1000.c (which can probably be used for the
LPC2119_PRODUCT_ID we should try to implement first).

Then we need something like this stuff

static const struct net_device_ops sja1000_netdev_ops = {
        .ndo_open               = sja1000_open,
        .ndo_stop               = sja1000_close,
        .ndo_start_xmit         = sja1000_start_xmit,
};

int register_sja1000dev(struct net_device *dev)
{
        if (!sja1000_probe_chip(dev))
                return -ENODEV;

        dev->netdev_ops = &sja1000_netdev_ops;

        dev->flags |= IFF_ECHO; /* we support local echo */

        set_reset_mode(dev);
        chipset_init(dev);

        return register_candev(dev);
}

from sja1000.c

And then we have an USB CAN node that has a belonging CAN netdevice (maybe
there is something else we can look at that's used in other USB ethernet
adapters).

I know from the PEAK USB driver at

http://www.peak-system.com/fileadmin/media/linux/files/peak-linux-driver.6.11.tar.gz

that i just needed to duplicate and modify the usb rx/tx stuff and redirect
the CAN frames into the network stack. But this PEAK driver does not have a
netlink configuration interface and can only be taken as a limited example ...

I assume, when the driver (cpc_usb.c or ems_usb.c analogue to the ems_pcmcia.c
?) is prepared as described above, one can go and connect the rx/tx dataflow
and the netlink configuration.

Unfortunately i'm short of time the next two weeks but maybe you can start and
create such a new C-file (probably based on ems_pcmcia.c) ?

Best regards,
Oliver

Re: Staging: cpc-usb CAN driver TODO list

[Wolfgang Grandegger]

On 09/07/2009 12:10 PM, Oliver Hartkopp wrote:
> Wolfgang Grandegger wrote:
>> On 09/07/2009 10:01 AM, Sebastian Haas wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Wolfgang,
>>>
>>> Wolfgang Grandegger schrieb:
>>>> Hi Sebastian,
>>>>
>>>> On 09/07/2009 07:56 AM, Sebastian Haas wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> Oliver,
>>>>>
>>>>> I'm not yet sure how to actually start the development. There is so
>>>>> much
>>>>> to do, and I've not much time to spend on this, unfortunately. Because
>>>>> of this I can't rewrite the whole driver on my own in order to get a
>>>>> Socket-CAN driver but I can provide support, review patches, rent
>>>>> devices and make tests here.
>>>>>
>>>>> Oliver, you are not familiar with USB and I'm not very familiar with
>>>>> CAN
>>>>> netdev internals, why not combining these twos. You are writing the CAN
>>>>> part and write the USB part.
>>>>>
>>>>> I'll also write a specification which contains any information you need
>>>>> to develop a CAN driver for the device (commands, sequences, error
>>>>> handling).
>>>>
>>>> Alternatively, EMS Wuensche could also hire an expert doing the job ;-).
>>>> Note that we do a lot of Socket-CAN work in our free time, which is a
>>>> limited resource. Progress depends on funding to a certain extend.
>>> Money is also a limited resource. ;-)
>>>
>>> Let's become serious again, I know and respect that many of Socket-CAN
>>> and the Staging developers spend their free time working on it. We will
>>> of course work on the driver, but since we've not much time it may take
>>> several months. If someone wants to help, we would be very glad and
>>> happy to support the person as far as we can with devices, answers and
>>> tests.
>>
>> OK, no problem. I really appreciate your support for Socket-CAN so far.
>
> Indeed. Me too.
>
> I tried to take a second look into cpc-usb_drv.c and i would suggest to remove
> all the procfs and the chardev stuff and then create a CAN netdev when you
> identified an USB node analogue to
>
>          /* Detect available channels */
>          for (i = 0; i<  EMS_PCMCIA_MAX_CHAN; i++) {
>                  dev = alloc_sja1000dev(0);
>                  if (dev == NULL) {
>                          err = -ENOMEM;
>                          goto failure_cleanup;
>                  }
>
>                  card->net_dev[i] = dev;
>                  priv = netdev_priv(dev);
>                  priv->priv = card;
>                  SET_NETDEV_DEV(dev,&pdev->dev);
>
> as you know from your ems_pcmcia.c driver
>
> and
>
> struct net_device *alloc_sja1000dev(int sizeof_priv)
> {
>          struct net_device *dev;
>          struct sja1000_priv *priv;
>
>          dev = alloc_candev(sizeof(struct sja1000_priv) + sizeof_priv);
>          if (!dev)
>                  return NULL;
>
>          priv = netdev_priv(dev);
>
>          priv->dev = dev;
>          priv->can.bittiming_const =&sja1000_bittiming_const;
>          priv->can.do_set_bittiming = sja1000_set_bittiming;
>          priv->can.do_set_mode = sja1000_set_mode;
>
>          if (sizeof_priv)
>                  priv->priv = (void *)priv + sizeof(struct sja1000_priv);
>
>          return dev;
> }
>
> as you know from the sja1000.c (which can probably be used for the
> LPC2119_PRODUCT_ID we should try to implement first).
>
> Then we need something like this stuff
>
> static const struct net_device_ops sja1000_netdev_ops = {
>          .ndo_open               = sja1000_open,
>          .ndo_stop               = sja1000_close,
>          .ndo_start_xmit         = sja1000_start_xmit,
> };
>
> int register_sja1000dev(struct net_device *dev)
> {
>          if (!sja1000_probe_chip(dev))
>                  return -ENODEV;
>
>          dev->netdev_ops =&sja1000_netdev_ops;
>
>          dev->flags |= IFF_ECHO; /* we support local echo */
>
>          set_reset_mode(dev);
>          chipset_init(dev);
>
>          return register_candev(dev);
> }
>
> from sja1000.c
>
> And then we have an USB CAN node that has a belonging CAN netdevice (maybe
> there is something else we can look at that's used in other USB ethernet
> adapters).
>
> I know from the PEAK USB driver at
>
> http://www.peak-system.com/fileadmin/media/linux/files/peak-linux-driver.6.11.tar.gz
>
> that i just needed to duplicate and modify the usb rx/tx stuff and redirect
> the CAN frames into the network stack. But this PEAK driver does not have a
> netlink configuration interface and can only be taken as a limited example ...
>
> I assume, when the driver (cpc_usb.c or ems_usb.c analogue to the ems_pcmcia.c
> ?) is prepared as described above, one can go and connect the rx/tx dataflow
> and the netlink configuration.
>
> Unfortunately i'm short of time the next two weeks but maybe you can start and
> create such a new C-file (probably based on ems_pcmcia.c) ?

Also, there are USB network driver in "drivers/net/usb/" which might 
serve as examples.

Wolfgang.

Re: Staging: cpc-usb CAN driver TODO list

[Sebastian Haas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Okay, thanks for the tips. Lets see what I can create today.

Sebastian

Oliver Hartkopp schrieb:
> Wolfgang Grandegger wrote:
>> On 09/07/2009 10:01 AM, Sebastian Haas wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Wolfgang,
>>>
>>> Wolfgang Grandegger schrieb:
>>>> Hi Sebastian,
>>>>
>>>> On 09/07/2009 07:56 AM, Sebastian Haas wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> Oliver,
>>>>>
>>>>> I'm not yet sure how to actually start the development. There is so
>>>>> much
>>>>> to do, and I've not much time to spend on this, unfortunately. Because
>>>>> of this I can't rewrite the whole driver on my own in order to get a
>>>>> Socket-CAN driver but I can provide support, review patches, rent
>>>>> devices and make tests here.
>>>>>
>>>>> Oliver, you are not familiar with USB and I'm not very familiar with
>>>>> CAN
>>>>> netdev internals, why not combining these twos. You are writing the CAN
>>>>> part and write the USB part.
>>>>>
>>>>> I'll also write a specification which contains any information you need
>>>>> to develop a CAN driver for the device (commands, sequences, error
>>>>> handling).
>>>> Alternatively, EMS Wuensche could also hire an expert doing the job ;-).
>>>> Note that we do a lot of Socket-CAN work in our free time, which is a
>>>> limited resource. Progress depends on funding to a certain extend.
>>> Money is also a limited resource. ;-)
>>>
>>> Let's become serious again, I know and respect that many of Socket-CAN
>>> and the Staging developers spend their free time working on it. We will
>>> of course work on the driver, but since we've not much time it may take
>>> several months. If someone wants to help, we would be very glad and
>>> happy to support the person as far as we can with devices, answers and
>>> tests.
>> OK, no problem. I really appreciate your support for Socket-CAN so far.
> 
> Indeed. Me too.
> 
> I tried to take a second look into cpc-usb_drv.c and i would suggest to remove
> all the procfs and the chardev stuff and then create a CAN netdev when you
> identified an USB node analogue to
> 
>         /* Detect available channels */
>         for (i = 0; i < EMS_PCMCIA_MAX_CHAN; i++) {
>                 dev = alloc_sja1000dev(0);
>                 if (dev == NULL) {
>                         err = -ENOMEM;
>                         goto failure_cleanup;
>                 }
> 
>                 card->net_dev[i] = dev;
>                 priv = netdev_priv(dev);
>                 priv->priv = card;
>                 SET_NETDEV_DEV(dev, &pdev->dev);
> 
> as you know from your ems_pcmcia.c driver
> 
> and
> 
> struct net_device *alloc_sja1000dev(int sizeof_priv)
> {
>         struct net_device *dev;
>         struct sja1000_priv *priv;
> 
>         dev = alloc_candev(sizeof(struct sja1000_priv) + sizeof_priv);
>         if (!dev)
>                 return NULL;
> 
>         priv = netdev_priv(dev);
> 
>         priv->dev = dev;
>         priv->can.bittiming_const = &sja1000_bittiming_const;
>         priv->can.do_set_bittiming = sja1000_set_bittiming;
>         priv->can.do_set_mode = sja1000_set_mode;
> 
>         if (sizeof_priv)
>                 priv->priv = (void *)priv + sizeof(struct sja1000_priv);
> 
>         return dev;
> }
> 
> as you know from the sja1000.c (which can probably be used for the
> LPC2119_PRODUCT_ID we should try to implement first).
> 
> Then we need something like this stuff
> 
> static const struct net_device_ops sja1000_netdev_ops = {
>         .ndo_open               = sja1000_open,
>         .ndo_stop               = sja1000_close,
>         .ndo_start_xmit         = sja1000_start_xmit,
> };
> 
> int register_sja1000dev(struct net_device *dev)
> {
>         if (!sja1000_probe_chip(dev))
>                 return -ENODEV;
> 
>         dev->netdev_ops = &sja1000_netdev_ops;
> 
>         dev->flags |= IFF_ECHO; /* we support local echo */
> 
>         set_reset_mode(dev);
>         chipset_init(dev);
> 
>         return register_candev(dev);
> }
> 
> from sja1000.c
> 
> And then we have an USB CAN node that has a belonging CAN netdevice (maybe
> there is something else we can look at that's used in other USB ethernet
> adapters).
> 
> I know from the PEAK USB driver at
> 
> http://www.peak-system.com/fileadmin/media/linux/files/peak-linux-driver.6.11.tar.gz
> 
> that i just needed to duplicate and modify the usb rx/tx stuff and redirect
> the CAN frames into the network stack. But this PEAK driver does not have a
> netlink configuration interface and can only be taken as a limited example ...
> 
> I assume, when the driver (cpc_usb.c or ems_usb.c analogue to the ems_pcmcia.c
> ?) is prepared as described above, one can go and connect the rx/tx dataflow
> and the netlink configuration.
> 
> Unfortunately i'm short of time the next two weeks but maybe you can start and
> create such a new C-file (probably based on ems_pcmcia.c) ?
> 
> Best regards,
> Oliver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqk6TcACgkQpqRB8PJG7XzpQACePuMXFX6pSg7EyssTNnDfVomv
Lm0AnA7WKWLHfRny2iF5krEaT966WmPJ
=07pa
-----END PGP SIGNATURE-----
-- 
EMS Dr. Thomas Wuensche e.K.
Sonnenhang 3
85304 Ilmmuenster
HRA Neuburg a.d. Donau, HR-Nr. 70.106
Phone: +49-8441-490260
Fax  : +49-8441-81860
http://www.ems-wuensche.com

Re: Staging: cpc-usb CAN driver TODO list

[Sebastian Haas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Oliver,

Okay, I've just finished the first version today. It is much less effort
 as I previously thought. 95% is written and compiles fine. Just the
sending part is missing and optimization (it is just a basic
implementation without USB anchors and stuff like that).

I think the further development should proceed at the Socket-CAN mailing
list, cause of things needs to be clarified specific to the core.

Cheers,
Sebastian

Sebastian Haas schrieb:
> Okay, thanks for the tips. Lets see what I can create today.
> 
> Sebastian
> 
> Oliver Hartkopp schrieb:
>> Wolfgang Grandegger wrote:
>>> On 09/07/2009 10:01 AM, Sebastian Haas wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Wolfgang,
>>>>
>>>> Wolfgang Grandegger schrieb:
>>>>> Hi Sebastian,
>>>>>
>>>>> On 09/07/2009 07:56 AM, Sebastian Haas wrote:
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA1
>>>>>>
>>>>>> Oliver,
>>>>>>
>>>>>> I'm not yet sure how to actually start the development. There is so
>>>>>> much
>>>>>> to do, and I've not much time to spend on this, unfortunately. Because
>>>>>> of this I can't rewrite the whole driver on my own in order to get a
>>>>>> Socket-CAN driver but I can provide support, review patches, rent
>>>>>> devices and make tests here.
>>>>>>
>>>>>> Oliver, you are not familiar with USB and I'm not very familiar with
>>>>>> CAN
>>>>>> netdev internals, why not combining these twos. You are writing the CAN
>>>>>> part and write the USB part.
>>>>>>
>>>>>> I'll also write a specification which contains any information you need
>>>>>> to develop a CAN driver for the device (commands, sequences, error
>>>>>> handling).
>>>>> Alternatively, EMS Wuensche could also hire an expert doing the job ;-).
>>>>> Note that we do a lot of Socket-CAN work in our free time, which is a
>>>>> limited resource. Progress depends on funding to a certain extend.
>>>> Money is also a limited resource. ;-)
>>>>
>>>> Let's become serious again, I know and respect that many of Socket-CAN
>>>> and the Staging developers spend their free time working on it. We will
>>>> of course work on the driver, but since we've not much time it may take
>>>> several months. If someone wants to help, we would be very glad and
>>>> happy to support the person as far as we can with devices, answers and
>>>> tests.
>>> OK, no problem. I really appreciate your support for Socket-CAN so far.
>> Indeed. Me too.
> 
>> I tried to take a second look into cpc-usb_drv.c and i would suggest to remove
>> all the procfs and the chardev stuff and then create a CAN netdev when you
>> identified an USB node analogue to
> 
>>         /* Detect available channels */
>>         for (i = 0; i < EMS_PCMCIA_MAX_CHAN; i++) {
>>                 dev = alloc_sja1000dev(0);
>>                 if (dev == NULL) {
>>                         err = -ENOMEM;
>>                         goto failure_cleanup;
>>                 }
> 
>>                 card->net_dev[i] = dev;
>>                 priv = netdev_priv(dev);
>>                 priv->priv = card;
>>                 SET_NETDEV_DEV(dev, &pdev->dev);
> 
>> as you know from your ems_pcmcia.c driver
> 
>> and
> 
>> struct net_device *alloc_sja1000dev(int sizeof_priv)
>> {
>>         struct net_device *dev;
>>         struct sja1000_priv *priv;
> 
>>         dev = alloc_candev(sizeof(struct sja1000_priv) + sizeof_priv);
>>         if (!dev)
>>                 return NULL;
> 
>>         priv = netdev_priv(dev);
> 
>>         priv->dev = dev;
>>         priv->can.bittiming_const = &sja1000_bittiming_const;
>>         priv->can.do_set_bittiming = sja1000_set_bittiming;
>>         priv->can.do_set_mode = sja1000_set_mode;
> 
>>         if (sizeof_priv)
>>                 priv->priv = (void *)priv + sizeof(struct sja1000_priv);
> 
>>         return dev;
>> }
> 
>> as you know from the sja1000.c (which can probably be used for the
>> LPC2119_PRODUCT_ID we should try to implement first).
> 
>> Then we need something like this stuff
> 
>> static const struct net_device_ops sja1000_netdev_ops = {
>>         .ndo_open               = sja1000_open,
>>         .ndo_stop               = sja1000_close,
>>         .ndo_start_xmit         = sja1000_start_xmit,
>> };
> 
>> int register_sja1000dev(struct net_device *dev)
>> {
>>         if (!sja1000_probe_chip(dev))
>>                 return -ENODEV;
> 
>>         dev->netdev_ops = &sja1000_netdev_ops;
> 
>>         dev->flags |= IFF_ECHO; /* we support local echo */
> 
>>         set_reset_mode(dev);
>>         chipset_init(dev);
> 
>>         return register_candev(dev);
>> }
> 
>> from sja1000.c
> 
>> And then we have an USB CAN node that has a belonging CAN netdevice (maybe
>> there is something else we can look at that's used in other USB ethernet
>> adapters).
> 
>> I know from the PEAK USB driver at
> 
>> http://www.peak-system.com/fileadmin/media/linux/files/peak-linux-driver.6.11.tar.gz
> 
>> that i just needed to duplicate and modify the usb rx/tx stuff and redirect
>> the CAN frames into the network stack. But this PEAK driver does not have a
>> netlink configuration interface and can only be taken as a limited example ...
> 
>> I assume, when the driver (cpc_usb.c or ems_usb.c analogue to the ems_pcmcia.c
>> ?) is prepared as described above, one can go and connect the rx/tx dataflow
>> and the netlink configuration.
> 
>> Unfortunately i'm short of time the next two weeks but maybe you can start and
>> create such a new C-file (probably based on ems_pcmcia.c) ?
> 
>> Best regards,
>> Oliver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqlKDsACgkQpqRB8PJG7XwpdgCglYjvGi/z1z5tX1ozgF/YTA1j
9pwAnAkIHScIlic0KZNZEDWT09jUt3N1
=OVN3
-----END PGP SIGNATURE-----
-- 
EMS Dr. Thomas Wuensche e.K.
Sonnenhang 3
85304 Ilmmuenster
HRA Neuburg a.d. Donau, HR-Nr. 70.106
Phone: +49-8441-490260
Fax  : +49-8441-81860
http://www.ems-wuensche.com

Re: Staging: cpc-usb CAN driver TODO list

[Oliver Hartkopp]

Sebastian Haas wrote:


> Okay, I've just finished the first version today. It is much less effort
>  as I previously thought. 95% is written and compiles fine.


Great!


> Just the
> sending part is missing and optimization (it is just a basic
> implementation without USB anchors and stuff like that).
>
> I think the further development should proceed at the Socket-CAN mailing
> list, cause of things needs to be clarified specific to the core.


Yep! Good idea.

Many thanks,
Oliver