From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Oliver Hartkopp <socketcan@hartkopp.net>, linux-can@vger.kernel.org
Subject: Re: [PATCH v3 5/5] can: allow to change the device mtu for CAN FD capable devices
Date: Tue, 18 Feb 2014 12:09:49 +0100 [thread overview]
Message-ID: <53033F7D.9090805@pengutronix.de> (raw)
In-Reply-To: <52FFA3EB.7060902@hartkopp.net>
[-- Attachment #1: Type: text/plain, Size: 2135 bytes --]
On 02/15/2014 06:29 PM, Oliver Hartkopp wrote:
>> On 02/15/2014 05:32 PM, Oliver Hartkopp wrote:
>>> The configuration for CAN FD depends on CAN_CTRLMODE_FD enabled in the driver
>>> specific ctrlmode_supported capabilities.
>>>
>>> The configuration can be done either with the 'fd { on | off }' option in the
>>> 'ip' tool from iproute2 or by setting the CAN netdevice MTU to CAN_MTU (16) or
>>> to CANFD_MTU (72).
>>
>> Please don't add two possibilities to activate canfd on a CAN network
>> card. There should only be one.
>
> Yes it /should/ be like this.
> I thought about it some time but I didn't find a better solution.
>
> The problem is that dev->mtu is the switch for the skb->len whether CAN frames
> or CAN FD frames are generated or received.
>
> The MTU can be modified by 'ip' (independently from CAN specific settings).
It _can_ be modified (directly by the userspace) _if_ the change mtu
callback is implemented. Maybe we don't need the callback?
> OTOH the only way the CAN devices provide their capabilities is the
> ctrlmode_supported bitfield - and it does not make sense to provide
> CAN_CTRLMODE_FD in ctrlmode_supported and do not provide the configuration for it.
>
> If you would skip the CAN_CTRLMODE_FD bit in ctrlmode_supported there's no way
> to identify a CAN FD capable device. You could only try to set the MTU to
> CANFD_MTU and see, if it fails. Not a good solution either.
>
>
>>> +EXPORT_SYMBOL_GPL(can_change_mtu);
>>
>> Who will be the user of this function? The individual network drivers?
>>
>
> Yes. It manages the MTU and CAN_CTRLMODE_FD consistency and only allows the
> CANFD_MTU when the driver supports it.
And it has to be assigned by a FD capable driver to the net_device_ops,
right?
> Any other things to look at - or is the rest ok so far?
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 242 bytes --]
next prev parent reply other threads:[~2014-02-18 11:09 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-15 16:32 [PATCH v3 1/5] can: preserve skbuff protocol in can_put_echo_skb Oliver Hartkopp
2014-02-15 16:32 ` [PATCH v3 2/5] can: netlink send bittiming data only when a bitrate is available Oliver Hartkopp
2014-02-15 16:32 ` [PATCH v3 3/5] can: provide a separate bittiming_const parameter to bittiming functions Oliver Hartkopp
2014-02-15 16:32 ` [PATCH v3 4/5] can: introduce the data bitrate configuration for CAN FD Oliver Hartkopp
2014-02-21 8:27 ` Stephane Grosjean
2014-02-15 16:32 ` [PATCH v3 5/5] can: allow to change the device mtu for CAN FD capable devices Oliver Hartkopp
2014-02-15 16:59 ` Marc Kleine-Budde
2014-02-15 17:00 ` Marc Kleine-Budde
2014-02-15 17:29 ` Oliver Hartkopp
2014-02-18 11:09 ` Marc Kleine-Budde [this message]
2014-02-18 13:08 ` Oliver Hartkopp
2014-02-19 18:25 ` Oliver Hartkopp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53033F7D.9090805@pengutronix.de \
--to=mkl@pengutronix.de \
--cc=linux-can@vger.kernel.org \
--cc=socketcan@hartkopp.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.