* About sysfs usage by socket-can drivers
[not found] <VI1PR03MB5053976465B2A1EAB995BA02D6760@VI1PR03MB5053.eurprd03.prod.outlook.com>
@ 2020-07-23 9:18 ` Stéphane Grosjean
2020-07-23 13:37 ` Marc Kleine-Budde
0 siblings, 1 reply; 10+ messages in thread
From: Stéphane Grosjean @ 2020-07-23 9:18 UTC (permalink / raw)
To: linux-can
Hello,
Are there rules for using network interface sysfs, in particular, can a socket-can driver add its own attributes, please?
Regards,
--- Stephane
--
PEAK-System Technik GmbH
Sitz der Gesellschaft Darmstadt - HRB 9183
Geschaeftsfuehrung: Alexander Gach / Uwe Wilhelm
Unsere Datenschutzerklaerung mit wichtigen Hinweisen
zur Behandlung personenbezogener Daten finden Sie unter
www.peak-system.com/Datenschutz.483.0.html
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: About sysfs usage by socket-can drivers
2020-07-23 9:18 ` About sysfs usage by socket-can drivers Stéphane Grosjean
@ 2020-07-23 13:37 ` Marc Kleine-Budde
0 siblings, 0 replies; 10+ messages in thread
From: Marc Kleine-Budde @ 2020-07-23 13:37 UTC (permalink / raw)
To: Stéphane Grosjean, linux-can
[-- Attachment #1.1: Type: text/plain, Size: 655 bytes --]
On 7/23/20 11:18 AM, Stéphane Grosjean wrote:
> Are there rules for using network interface sysfs, in particular, can a
> socket-can driver add its own attributes, please?
First let's discuss, why you need a sysfs attribute?
Is there a better way to do this?
Then you have to describe the sysfs entry, e.g.:
Documentation/ABI/testing/sysfs-platform-at91
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: About sysfs usage by socket-can drivers
2020-07-28 7:31 ` Stéphane Grosjean
@ 2020-07-28 11:20 ` Kurt Van Dijck
0 siblings, 0 replies; 10+ messages in thread
From: Kurt Van Dijck @ 2020-07-28 11:20 UTC (permalink / raw)
To: Stéphane Grosjean; +Cc: Marc Kleine-Budde, linux-can
On 28 July 2020 09:31:52 GMT+02:00, "Stéphane Grosjean" <s.grosjean@peak-system.com> wrote:
>Thx for your answer Kurt! Even if properties are channel related, this
>could be a solution...
>
>But... creating a (new) channel tree under /devices looks weird,
>doesn't it?
/sys/class/net/.... are symlinks to /sys/devices/..., not weird IMO
>And why it should be "easier" to add attributes there rather than under
>each /sys/class/net/can?
Equally easy to add, much simpler to use in udev without race conditions.
>
>-- Stéphane
>
>
>De : Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>
>Envoyé : vendredi 24 juillet 2020 11:45
>À : Stéphane Grosjean <s.grosjean@peak-system.com>
>Cc : Marc Kleine-Budde <mkl@pengutronix.de>; linux-can@vger.kernel.org
><linux-can@vger.kernel.org>
>Objet : Re: About sysfs usage by socket-can drivers
>
>> We've several pending requests regarding:
>> - changing the default clock value,
>> - reading the bus load value,
>> - using a flashed device id. to better control the can interface
>number,
>> - identifying the (USB) channel
>> - ...
>
>I tend to look in the (in your case) usb device, and add properties
>there.
>After all, those are device-related properties, not?
>
>You could reach them via /sys/class/net/canX/device/...
>
>If you add them before the netdev is registered, you can use them in
>udev rules without race conditions.
>
>Kurt
>
>--
>PEAK-System Technik GmbH
>Sitz der Gesellschaft Darmstadt - HRB 9183
>Geschaeftsfuehrung: Alexander Gach / Uwe Wilhelm
>Unsere Datenschutzerklaerung mit wichtigen Hinweisen
>zur Behandlung personenbezogener Daten finden Sie unter
>www.peak-system.com/Datenschutz.483.0.html
Sent from a small mobile device
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: About sysfs usage by socket-can drivers
@ 2020-07-28 7:53 Stéphane Grosjean
0 siblings, 0 replies; 10+ messages in thread
From: Stéphane Grosjean @ 2020-07-28 7:53 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: linux-can
> Can you query the possible clock rates? Either add to ethtool
Yes the available clock rates list can be provided (by the driver). How to do that through ethtool please?
> or make it a CAN specific callback.
Do you propose to extend "struct can_priv" so that the clock could be selectect from netlink?
-- Stéphane
De: Marc Kleine-Budde
Envoyé: Jeudi 23 juillet 2020 22:13
À: Stéphane Grosjean
Cc: linux-can@vger.kernel.org
Objet: Re: About sysfs usage by socket-can drivers
On 7/23/20 9:39 PM, Stéphane Grosjean wrote:
>>> - changing the default clock value,
>
>> The input clock rate for the CAN IP Core?
> Yes
Can you query the possible clock rates? Either add to ethtool or make it a CAN
specific callback.
>>> - reading the bus load value,
>> ..as calculated by the USB device?
>
> or by the IP core, yes.
maybe we can add this to ethtool's stats, otherwise to the CAN stats.
>>> - using a flashed device id. to better control the can interface number,
>
>> Can you make use of dev_id/dev_port
>> https://elixir.bootlin.com/linux/latest/source/include/linux/netdevice.h#L1687
>
> Ok. I'll check that, thanks.
>
>
>>> - identifying the (USB) channel
>
>> Does udev offer all needed information? E.g.:
>
> Sorry, nope: identify the USB adapter <=> flash the LED (which USB device corresponds to which canX)
Use ethtool's set_phys_id for this:
https://elixir.bootlin.com/linux/latest/source/drivers/net/can/usb/gs_usb.c#L762
You can either implement a "activate blink", "deactivate blink" or "switch LED
on", "switch LED off" (and I think the core will take care of blinking).
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
--
PEAK-System Technik GmbH
Sitz der Gesellschaft Darmstadt - HRB 9183
Geschaeftsfuehrung: Alexander Gach / Uwe Wilhelm
Unsere Datenschutzerklaerung mit wichtigen Hinweisen
zur Behandlung personenbezogener Daten finden Sie unter
www.peak-system.com/Datenschutz.483.0.html
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: About sysfs usage by socket-can drivers
2020-07-24 9:45 ` Kurt Van Dijck
@ 2020-07-28 7:31 ` Stéphane Grosjean
2020-07-28 11:20 ` Kurt Van Dijck
0 siblings, 1 reply; 10+ messages in thread
From: Stéphane Grosjean @ 2020-07-28 7:31 UTC (permalink / raw)
To: Kurt Van Dijck; +Cc: Marc Kleine-Budde, linux-can
Thx for your answer Kurt! Even if properties are channel related, this could be a solution...
But... creating a (new) channel tree under /devices looks weird, doesn't it?
And why it should be "easier" to add attributes there rather than under each /sys/class/net/can?
-- Stéphane
De : Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>
Envoyé : vendredi 24 juillet 2020 11:45
À : Stéphane Grosjean <s.grosjean@peak-system.com>
Cc : Marc Kleine-Budde <mkl@pengutronix.de>; linux-can@vger.kernel.org <linux-can@vger.kernel.org>
Objet : Re: About sysfs usage by socket-can drivers
> We've several pending requests regarding:
> - changing the default clock value,
> - reading the bus load value,
> - using a flashed device id. to better control the can interface number,
> - identifying the (USB) channel
> - ...
I tend to look in the (in your case) usb device, and add properties there.
After all, those are device-related properties, not?
You could reach them via /sys/class/net/canX/device/...
If you add them before the netdev is registered, you can use them in
udev rules without race conditions.
Kurt
--
PEAK-System Technik GmbH
Sitz der Gesellschaft Darmstadt - HRB 9183
Geschaeftsfuehrung: Alexander Gach / Uwe Wilhelm
Unsere Datenschutzerklaerung mit wichtigen Hinweisen
zur Behandlung personenbezogener Daten finden Sie unter
www.peak-system.com/Datenschutz.483.0.html
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: About sysfs usage by socket-can drivers
2020-07-23 14:50 Stéphane Grosjean
2020-07-23 15:23 ` Marc Kleine-Budde
@ 2020-07-24 9:45 ` Kurt Van Dijck
2020-07-28 7:31 ` Stéphane Grosjean
1 sibling, 1 reply; 10+ messages in thread
From: Kurt Van Dijck @ 2020-07-24 9:45 UTC (permalink / raw)
To: Stéphane Grosjean; +Cc: Marc Kleine-Budde, linux-can
> We've several pending requests regarding:
> - changing the default clock value,
> - reading the bus load value,
> - using a flashed device id. to better control the can interface number,
> - identifying the (USB) channel
> - ...
I tend to look in the (in your case) usb device, and add properties there.
After all, those are device-related properties, not?
You could reach them via /sys/class/net/canX/device/...
If you add them before the netdev is registered, you can use them in
udev rules without race conditions.
Kurt
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: About sysfs usage by socket-can drivers
2020-07-23 19:39 Stéphane Grosjean
@ 2020-07-23 20:13 ` Marc Kleine-Budde
0 siblings, 0 replies; 10+ messages in thread
From: Marc Kleine-Budde @ 2020-07-23 20:13 UTC (permalink / raw)
To: Stéphane Grosjean; +Cc: linux-can
[-- Attachment #1.1: Type: text/plain, Size: 1437 bytes --]
On 7/23/20 9:39 PM, Stéphane Grosjean wrote:
>>> - changing the default clock value,
>
>> The input clock rate for the CAN IP Core?
> Yes
Can you query the possible clock rates? Either add to ethtool or make it a CAN
specific callback.
>>> - reading the bus load value,
>> ..as calculated by the USB device?
>
> or by the IP core, yes.
maybe we can add this to ethtool's stats, otherwise to the CAN stats.
>>> - using a flashed device id. to better control the can interface number,
>
>> Can you make use of dev_id/dev_port
>> https://elixir.bootlin.com/linux/latest/source/include/linux/netdevice.h#L1687
>
> Ok. I'll check that, thanks.
>
>
>>> - identifying the (USB) channel
>
>> Does udev offer all needed information? E.g.:
>
> Sorry, nope: identify the USB adapter <=> flash the LED (which USB device corresponds to which canX)
Use ethtool's set_phys_id for this:
https://elixir.bootlin.com/linux/latest/source/drivers/net/can/usb/gs_usb.c#L762
You can either implement a "activate blink", "deactivate blink" or "switch LED
on", "switch LED off" (and I think the core will take care of blinking).
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: About sysfs usage by socket-can drivers
@ 2020-07-23 19:39 Stéphane Grosjean
2020-07-23 20:13 ` Marc Kleine-Budde
0 siblings, 1 reply; 10+ messages in thread
From: Stéphane Grosjean @ 2020-07-23 19:39 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: linux-can
Hi,
>> We've several pending requests regarding:
>> - changing the default clock value,
> The input clock rate for the CAN IP Core?
Yes
>> - reading the bus load value,
>..as calculated by the USB device?
or by the IP core, yes.
>> - using a flashed device id. to better control the can interface number,
>Can you make use of dev_id/dev_port
>https://elixir.bootlin.com/linux/latest/source/include/linux/netdevice.h#L1687
Ok. I'll check that, thanks.
>> - identifying the (USB) channel
>Does udev offer all needed information? E.g.:
Sorry, nope: identify the USB adapter <=> flash the LED (which USB device corresponds to which canX)
>> Adding attributes under /sys/class/net/canX (or into a specific/private group) could be a solution.
>Marc
---
Stéphane Grosjean
PEAK-System France
132, rue André Bisiaux
F-54320 MAXEVILLE
Tél : +(33) 9.72.54.51.97
De: Marc Kleine-Budde
Envoyé: Jeudi 23 juillet 2020 17:23
À: Stéphane Grosjean
Cc: linux-can@vger.kernel.org
Objet: Re: About sysfs usage by socket-can drivers
On 7/23/20 4:50 PM, Stéphane Grosjean wrote:
> We've several pending requests regarding:
> - changing the default clock value,
The input clock rate for the CAN IP Core?
> - reading the bus load value,
..as calculated by the USB device?
> - using a flashed device id. to better control the can interface number,
Can you make use of dev_id/dev_port
https://elixir.bootlin.com/linux/latest/source/include/linux/netdevice.h#L1687
> - identifying the (USB) channel
Does udev offer all needed information? E.g.:
udevadm test /sys/class/net/can0
> Adding attributes under /sys/class/net/canX (or into a specific/private group) could be a solution.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
--
PEAK-System Technik GmbH
Sitz der Gesellschaft Darmstadt - HRB 9183
Geschaeftsfuehrung: Alexander Gach / Uwe Wilhelm
Unsere Datenschutzerklaerung mit wichtigen Hinweisen
zur Behandlung personenbezogener Daten finden Sie unter
www.peak-system.com/Datenschutz.483.0.html
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: About sysfs usage by socket-can drivers
2020-07-23 14:50 Stéphane Grosjean
@ 2020-07-23 15:23 ` Marc Kleine-Budde
2020-07-24 9:45 ` Kurt Van Dijck
1 sibling, 0 replies; 10+ messages in thread
From: Marc Kleine-Budde @ 2020-07-23 15:23 UTC (permalink / raw)
To: Stéphane Grosjean; +Cc: linux-can
[-- Attachment #1.1: Type: text/plain, Size: 958 bytes --]
On 7/23/20 4:50 PM, Stéphane Grosjean wrote:
> We've several pending requests regarding:
> - changing the default clock value,
The input clock rate for the CAN IP Core?
> - reading the bus load value,
..as calculated by the USB device?
> - using a flashed device id. to better control the can interface number,
Can you make use of dev_id/dev_port
https://elixir.bootlin.com/linux/latest/source/include/linux/netdevice.h#L1687
> - identifying the (USB) channel
Does udev offer all needed information? E.g.:
udevadm test /sys/class/net/can0
> Adding attributes under /sys/class/net/canX (or into a specific/private group) could be a solution.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: About sysfs usage by socket-can drivers
@ 2020-07-23 14:50 Stéphane Grosjean
2020-07-23 15:23 ` Marc Kleine-Budde
2020-07-24 9:45 ` Kurt Van Dijck
0 siblings, 2 replies; 10+ messages in thread
From: Stéphane Grosjean @ 2020-07-23 14:50 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: linux-can
Hello Mark,
Thank you for your answer.
We've several pending requests regarding:
- changing the default clock value,
- reading the bus load value,
- using a flashed device id. to better control the can interface number,
- identifying the (USB) channel
- ...
Adding attributes under /sys/class/net/canX (or into a specific/private group) could be a solution.
---
Stéphane Grosjean
PEAK-System France
132, rue André Bisiaux
F-54320 MAXEVILLE
Tél : +(33) 9.72.54.51.97
De: Marc Kleine-Budde
Envoyé: Jeudi 23 juillet 2020 15:37
À: Stéphane Grosjean; linux-can@vger.kernel.org
Objet: Re: About sysfs usage by socket-can drivers
On 7/23/20 11:18 AM, Stéphane Grosjean wrote:
> Are there rules for using network interface sysfs, in particular, can a
> socket-can driver add its own attributes, please?
First let's discuss, why you need a sysfs attribute?
Is there a better way to do this?
Then you have to describe the sysfs entry, e.g.:
Documentation/ABI/testing/sysfs-platform-at91
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
--
PEAK-System Technik GmbH
Sitz der Gesellschaft Darmstadt - HRB 9183
Geschaeftsfuehrung: Alexander Gach / Uwe Wilhelm
Unsere Datenschutzerklaerung mit wichtigen Hinweisen
zur Behandlung personenbezogener Daten finden Sie unter
www.peak-system.com/Datenschutz.483.0.html
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2020-07-28 11:20 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <VI1PR03MB5053976465B2A1EAB995BA02D6760@VI1PR03MB5053.eurprd03.prod.outlook.com>
2020-07-23 9:18 ` About sysfs usage by socket-can drivers Stéphane Grosjean
2020-07-23 13:37 ` Marc Kleine-Budde
2020-07-23 14:50 Stéphane Grosjean
2020-07-23 15:23 ` Marc Kleine-Budde
2020-07-24 9:45 ` Kurt Van Dijck
2020-07-28 7:31 ` Stéphane Grosjean
2020-07-28 11:20 ` Kurt Van Dijck
2020-07-23 19:39 Stéphane Grosjean
2020-07-23 20:13 ` Marc Kleine-Budde
2020-07-28 7:53 Stéphane Grosjean
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.